Presentation on theme: "Public Key Management and X.509 Certificates"— Presentation transcript:
1 Public Key Management and X.509 Certificates CSCI 5857: Encoding and Encryption
2 Outline Public key distribution problems Trusted center solution Certification authority solutionX.509 Certificate standardCreating and verifying X.509 certificatesRevoking certificatesThe 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 KDarthPR, KDarthPUSend the public key KDarthPU to Bob, claiming it is from AliceAsk Bob to send sensitive data encrypted with the public keyIntercept the data and decrypt it with his private key KDarthPR“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 centerVerifies identities of users before registrationStores list of public keys for registered usersHas own key pair KTPr, KTPuWill provide public keys upon request, signed by the trusted center with KTPrAll users know Trusted Center’s public key KTPu
5 Trusted Center Alice sends request for Bob’s public key to center Includes timestamp to prevent replayTrusted Center sends Bob’s key to AliceIncludes timestamp signed with Trusted Center’s private keyAlice verifies with Trusted Center’s public key.
6 Certification Authority Problem: Trusted Center approach very inefficientMight need to handle millions of requests simultaneouslySolution: public key certificates created by certificate authorityTrusted third party (Verisign, Geotrust, Equifax, etc.)Well known public keyCertificate contains user’s public key, signed with CA’s private keyAny other user can validate certificate using CA’s public key
7 Certification Authority Bob provides his public key to CACA verifies Bob’s identityCA creates certificate with Bob’s public key signed with CA’s private keyBob distributes certificate to public
8 X.509 Standard Many known CA’s (Verisign, Geotrust, Equifax, etc.) X.509 Standard provides common format for all certificatesMakes 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 eachSignature algorithm ID: public key algorithm (RSA, etc.) this CA uses for its signaturesNeed to know this to verify signatureIssuer name/unique ID: way to uniquely identify issuing CANeed to know this to decide which CA’s public key to use for verification
10 X.509 StandardValidity period: Expiration date after which certificate not trustedFor security, certificates and subject public key should be changed regularlySubject name/unique ID: Way to uniquely identify subject (Bob)Subject public key: public key + algorithm (RSA, etc.) subject usesSender needs to know this to encrypt messages to subjectNot necessarily same as issuerExtensions: Other information subject wants signedBiometrics, etc.
11 Signing X.509 Certificates Signature created by CA:Message digest created from all other fieldsSigned with CA’s private keyIncludes ID for hash algorithm used to create the message digestH(all fields)H(all fields) D mod n
12 Verifying X.509 Certificates Use indicated hash algorithm to create digest from all fields in certificateUse CA’s public key to decrypt signature and get enclosed digestIf the two match, certificate is valid and has not been tampered withH(all fields)comparesignature E mod n
13 Revoking X.509 Certificates May need to make certificate invalid before expiration dateSubject’s private key compromisedSubject no longer trusted by CAExample: CA issued to company subject no longer works forCA’s private key compromisedWill 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 listAll unexpired certificates revoked (by certificate ID)Signed by CA so can’t be faked or alteredUpdated regularlyFor greater efficiency, can post delta CRL with just new revocations since last updateUser can check list before deciding to trust certificate
15 Public Key Infrastructure Problem:Alice and Bob may use different CA’sAlice uses Verisign, has Verisign public keyBob uses Equifax, has Equifax public keyHow can Alice validate Bob’s certificate without the Equifax public key?Bob’s certificate signed with Equifax keyAlice’s certificate signed with Verisign keyVerisign public key???
16 Public Key Infrastructure Mesh Solution:Each certificate authority maintains certificates for all other certificate authoritiesCan contact your CA to get certificate containing public key for other CAsCan keep other useful information (revocation lists, etc.)
17 Public Key Infrastructure Alice requests Equifax’s certificate from VerisignAlice uses known Verisign key to validate certificate and extract Equifax keyAlice uses Equifax key to validate Bob’s certificateAlice can also store the Equifax key for future userequestvalidateEquifax’s certificate signed with Verisign keyVerisign public keyvalidatestoreEquifax public keyVerisignBob’s certificate signed with Equifax key
18 Public Key Infrastructure One user can send another a chain of certificates to validate their public keyCan send certificates for CA you use, signed by all other major CA’s, along with your certificateMuch more efficient to send in advance than having to request it at time of validationTerminology: X<<Y>> means authority X has signed certificate for user Y
19 Certificate Chaining Example: Bob sends his certificate to Alice Bob sends certificates Verisign<<Equifax>> and Equifax<<Bob>>Alice validates Verisign<<Equifax>> using Verisign’s public keyAlice extracts the public key of Equifax from Verisign<<Equifax>>Alice validates Equifax<<Bob>> using Eqifax’s public keyAlice extracts Bob’s public key from Equifax<<Bob>>