1 / 34

6. Public Key Infrastructure

King Mongkut’s University of Technology Faculty of Information Technology Network Security Prof. Reuven Aviv. 6. Public Key Infrastructure. OUTLINE. 1. Party Authentication via certificates 2. Models for Public Key Infrastructure 3. Appendix: EFS – file encryption in WinXP.

tirzah
Download Presentation

6. Public Key Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. King Mongkut’s University of TechnologyFaculty of Information TechnologyNetwork SecurityProf. Reuven Aviv 6. Public Key Infrastructure Public Key Cryptography

  2. OUTLINE • 1. Party Authentication via certificates • 2. Models for Public Key Infrastructure • 3. Appendix: EFS – file encryption in WinXP Public Key Cryptography and PKI

  3. 1. Party authentication by certificates Cryptography Short

  4. Party authentication (X.509) • Party A present an X.509 certificates to party B • B validated the certificate of A • B knows a pair (IDA, KUA) • B learns the identity of A (B authenticates A) • By receiving a proof from A that it knows the private key KRA associated with the public key presented in the certificate • Proof: A signs some data; B verifies the signature Public Key Cryptography and PKI

  5. X.509 Single message Authentication • Single message from A to B, establishing: • Identity of A: message originated from A • Message intended for B; Integrity of message • Originality (no replay) of message • Message: valid-period, B id, nonce, Data, sigA • AB: A{tA, rA, B id, Data} • Nonce rA kept by receiver for future use. Why? • Message may include session key (Kab) why? • encrypted by B public key why? Public Key Cryptography and PKI

  6. X.509 One Way Authentication • Why do we have • both • Timestamp and nonce? • Again: How does B knows that the sender is A? • How does A knows that B received the message? Public Key Cryptography and PKI

  7. X.509 two way authentication • Two messages exchanged between A and B • Establishing same as in one-way, and • That message from A received correctly by B • Identity of B; reply originated from B • That reply was intended to A • Integrity and originality of reply • AB: A{tA, rA, B id, Data, EKUB[Kab]} • BA: B{tB, rB, A id, rA, Data, EKUB[Kba]} What does a M.I.M know or change? Public Key Cryptography and PKI

  8. Digital signing of the certificate:Notations • Two notations • CA<<A>> = CA{V, SN, AI, CA, TA, A, Ap} • LHS: <<A>> signed by CA • RHS: {…} signed by CA Public Key Cryptography and PKI

  9. X.509 Two-way authentication Public Key Cryptography and PKI

  10. X.509 Three-way authentication • Echoing signed nonces guarantee no-replay • Required if clock synchronization is not good Public Key Cryptography and PKI

  11. A one-time session key usage scenario • A and B present their certificates to each other • A creates a one-time random session key Ks • A B 3 parts message • Data encrypted (e.g by AES) using one-time Ks • Ks encrypted by KUB • sigA • B verifies A signature how? • If verified, B knows his party ID is IDA • B, and Only B, can decrypt the session key why? • only B can correctly decrypt the message Public Key Cryptography and PKI

  12. 2. Models for Public Key Infrastructure (PKI) Public Key Cryptography and PKI

  13. How many CAs do we need? • Monopoly Trust Model • All use one, trusted CA, know its public key • How do they know it? • Parties can send certificates directly to others • Party B can verify authenticity of a certificate by decrypting the signature of the CA • What are the problems? Public Key Cryptography and PKI

  14. Monopoly Trust Model: Problems • There is no single trusted organization • all OS include with CA’s KUCA – hard to change • How a remote CA can validate your identity? • solution: monopoly + Registration Authorities (RAs) in charge of mapping names to KU • The monopoly will charge whatever it wants Public Key Cryptography and PKI

  15. Chains of certificates • A obtained certificate issued/signed by X1 • B obtained certificate issued/signed by X2 • X1, X2 obtained certificates issued/signed by each other • X1<<A>> X2<<B>> X1<<X2>> X2<<X1>> • A gets the X2<<B>> certificate (from B) • A gets the X1<<X2>> certificate (from X2) • A extracts from X1<<X2>> the X2 public key • A extracts from X2<<B>> the public key of B • Summarizing: A got the chain X1<<X2>> X2<<B>> • More generally: X1<<X2>> X2<<X3>> …XN<<B>> • Each pair must have issued certificates for each other How A (and B) find the chains? Public Key Cryptography and PKI

  16. Certificate Path Public Key Cryptography and PKI

  17. Monopoly with delegated CAs Trust Model • One root CA issues certificates to other CAs • Certificates authorize holders to issue certs • A tree of CAs • Each certificate is the end of a chain of certs • Root CA also called trust anchor • Who issues the certificate of the trust anchor? • Problems? Public Key Cryptography and PKI

  18. Oligarchy Trust model • OS preconfigured with a list of trusted root CAs • Their self issued certificates added to the OS • OS also include list of certs of intermediaries • All certificates form a forest • User can add or delete entries from lists • Very common in practice • Browser rely on these lists Public Key Cryptography and PKI

  19. Trusted Root Certificates in my computer Tool: mmc Public Key Cryptography and PKI

  20. oligarchy more secure than monopoly? • Monopoly: corruption  risks world security • Oligarchy: Corruption in one root CA  same • More likely to happen in oligarchy! • Oligarchy: CAschosen by vendor, so what? • Easy to trick users to add new “trusted” CAs • Malicious users can change lists in a public host • Hardly noticeable in long lists Public Key Cryptography and PKI

  21. Anarchy Trust Model • users responsible for configuring root CAs • People he/she trusts • then anyone can issue certificates • Volunteers keep certificates in a database • To find a cert: search for a chain in the DB • Can we really trust a chain of certificates? • Not scalable • idea: several chains lead to cert –> trusted cert • Used in Pretty Good Privacy (PGP) software Public Key Cryptography and PKI

  22. Bottom UP hierarchy • Hierarchical namespace • Like A, A/B/X, A/B/X/Y • According to organizational structure • Namespace is a forest • Each node associated with a CA • Each organization node issue its own certificates • Each CA signs certs of children and parent • Also cross signature (links) within the forest • Each certificate has a root CA • A: find a cert of B: go up in forest, look for cross Public Key Cryptography and PKI

  23. CA Hierarchy • A wants to get B public key. He gets the following certificates (right to left) • X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B> Is this structure Fixed? Public Key Cryptography and PKI

  24. Revocation of Certificates • Reasons for revocation: • secret key is assumed to be compromised. • The user is no longer certified by this CA. • CA’s certificate is assumed compromised. • CA issues a Certificate Revocation List (CRL) • cert identified by its issuer and the serial num • User that gets a certificate should consult that list • User maintains cache of certificates and CRLs • how the integrity of list is kept? Public Key Cryptography and PKI

  25. Certificate Revocation List Public Key Cryptography and PKI

  26. Revocation List Public Key Cryptography and PKI

  27. 3. Appendix Storage of Secret Keys by Public Key Encryption in the EFS system of Windows XP Public Key Cryptography and PKI

  28. EFS: Encrypting a directory/file in WinXP • Users can encrypt file, directories • Encryption by DES or 3DES • Key (FEK) created during encryption Public Key Cryptography and PKI

  29. File Encryption in WinXP Public Key Cryptography and PKI

  30. Encrypting the File Encryption Key (FEK) • The Operating System creates for the User a Public and Private keys • using information in the User account, including his/her password • (the keys are created once) • The FEK is then encrypted by RSA using the User’s public key Public Key Cryptography and PKI

  31. Encrypting The File Encryption Key (FEK) • The encrypted FEK is written into to the file header, in the Data Decryption Field (DDF) Public Key Cryptography and PKI

  32. Automatic creation of a my cert during encryption Tool: Microsoft Management Console (mmc) Certificate Snap in Public Key Cryptography and PKI

  33. Personal certificate Public Key Cryptography and PKI

  34. Data Recovery Agents • OS Assign Recovery Agents (e.g. admin) also have (different) private and public keys. • For each RA the encrypted FEK is written into the Data Recovery Field (DRF) in the File header Public Key Cryptography and PKI

More Related