Presentation on theme: "Public Key Management and X.509 Certificates CSCI 5857: Encoding and Encryption."— Presentation transcript:
Public Key Management and X.509 Certificates CSCI 5857: Encoding and Encryption
Outline Public key distribution problems Trusted center solution Certification authority solution X.509 Certificate standard Creating and verifying X.509 certificates Revoking certificates The Public Key Infrastructure
3 Public Key Distribution How does Bob know where a public key comes from? Darth can: –Create a public/private key pair K DarthPR, K DarthPU –Send the public key K DarthPU to Bob, claiming it is from Alice –Ask Bob to send sensitive data encrypted with the public key –Intercept the data and decrypt it with his private key K DarthPR “Here is my public key KAlicePU – Alice” Secure data encrypted with what Bob thinks is Alice’s public key
4 Trusted Third Party Approach Trusted center –Verifies identities of users before registration –Stores list of public keys for registered users –Has own key pair K TPr, K TPu –Will provide public keys upon request, signed by the trusted center with K TPr –All users know Trusted Center’s public key K TPu
5 Trusted Center Alice sends request for Bob’s public key to center –Includes timestamp to prevent replay Trusted Center sends Bob’s key to Alice –Includes timestamp signed with Trusted Center’s private key –Alice verifies with Trusted Center’s public key.
6 Certification Authority Problem: Trusted Center approach very inefficient –Might need to handle millions of requests simultaneously Solution: public key certificates created by certificate authority –Trusted third party (Verisign, Geotrust, Equifax, etc.) –Well known public key Certificate contains user’s public key, signed with CA’s private key Any other user can validate certificate using CA’s public key
7 Certification Authority Bob provides his public key to CA CA verifies Bob’s identity CA creates certificate with Bob’s public key signed with CA’s private key Bob distributes certificate to public
8 X.509 Standard Many known CA’s (Verisign, Geotrust, Equifax, etc.) X.509 Standard provides common format for all certificates –Makes verification much simpler
9 X.509 Standard Serial number: Unique ID assigned to certificate –Bob may have many certificates over time, need to be able to identify each Signature algorithm ID: public key algorithm (RSA, etc.) this CA uses for its signatures –Need to know this to verify signature Issuer name/unique ID: way to uniquely identify issuing CA –Need to know this to decide which CA’s public key to use for verification
10 X.509 Standard Validity period: Expiration date after which certificate not trusted –For security, certificates and subject public key should be changed regularly Subject name/unique ID: Way to uniquely identify subject (Bob) Subject public key: public key + algorithm (RSA, etc.) subject uses –Sender needs to know this to encrypt messages to subject –Not necessarily same as issuer Extensions: Other information subject wants signed –Biometrics, etc.
11 Signing X.509 Certificates Signature created by CA: –Message digest created from all other fields –Signed with CA’s private key –Includes ID for hash algorithm used to create the message digest H(all fields) H(all fields) D mod n
12 Verifying X.509 Certificates Use indicated hash algorithm to create digest from all fields in certificate Use CA’s public key to decrypt signature and get enclosed digest If the two match, certificate is valid and has not been tampered with H(all fields) signature E mod n compare
13 Revoking X.509 Certificates May need to make certificate invalid before expiration date –Subject’s private key compromised –Subject no longer trusted by CA Example: CA issued to company subject no longer works for –CA’s private key compromised Will need to revoke all current certificates issued! Need way to inform all users about revoked certificates “I have you now!”
14 Certificate Revocation List Issuer maintains revocation list –All unexpired certificates revoked (by certificate ID) –Signed by CA so can’t be faked or altered –Updated regularly For greater efficiency, can post delta CRL with just new revocations since last update User can check list before deciding to trust certificate
15 Public Key Infrastructure Problem: Alice and Bob may use different CA’s –Alice uses Verisign, has Verisign public key –Bob uses Equifax, has Equifax public key How can Alice validate Bob’s certificate without the Equifax public key? Bob’s certificate signed with Equifax key Alice’s certificate signed with Verisign key Verisign public key ???
16 Public Key Infrastructure Mesh Solution: Each certificate authority maintains certificates for all other certificate authorities –Can contact your CA to get certificate containing public key for other CAs –Can keep other useful information (revocation lists, etc.)
17 Public Key Infrastructure Alice requests Equifax’s certificate from Verisign Alice uses known Verisign key to validate certificate and extract Equifax key Alice uses Equifax key to validate Bob’s certificate Alice can also store the Equifax key for future use Bob’s certificate signed with Equifax key Verisign public key Verisign request Equifax’s certificate signed with Verisign key validate Equifax public key store
18 Public Key Infrastructure One user can send another a chain of certificates to validate their public key Can send certificates for CA you use, signed by all other major CA’s, along with your certificate –Much more efficient to send in advance than having to request it at time of validation Terminology: X > means authority X has signed certificate for user Y
19 Certificate Chaining Example: Bob sends his certificate to Alice –Bob sends certificates Verisign > and Equifax > –Alice validates Verisign > using Verisign’s public key –Alice extracts the public key of Equifax from Verisign > –Alice validates Equifax > using Eqifax’s public key –Alice extracts Bob’s public key from Equifax >