Download presentation

Presentation is loading. Please wait.

1
**Public Key Management and X.509 Certificates**

CSCI 5857: Encoding and Encryption

2
**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 KDarthPR, KDarthPU Send the public key KDarthPU 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 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 center Verifies identities of users before registration Stores list of public keys for registered users Has own key pair KTPr, KTPu Will provide public keys upon request, signed by the trusted center with KTPr All 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 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) compare signature E mod n

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 request validate Equifax’s certificate signed with Verisign key Verisign public key validate store Equifax public key Verisign Bob’s certificate signed with Equifax key

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<<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 key Alice extracts the public key of Equifax from Verisign<<Equifax>> Alice validates Equifax<<Bob>> using Eqifax’s public key Alice extracts Bob’s public key from Equifax<<Bob>>

Similar presentations

OK

CS5204 – Operating Systems 1 Authentication. CS 5204 – Operating Systems2 Authentication Digital signature validation proves: message was not altered.

CS5204 – Operating Systems 1 Authentication. CS 5204 – Operating Systems2 Authentication Digital signature validation proves: message was not altered.

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google

Ppt on leadership qualities of bill gates Ppt on cement based materials Cool backgrounds for ppt on social media Ppt on types of rocks Genetics for kids ppt on batteries Ppt on carry save adder Download ppt on environmental degradation Ppt on vitamin d deficiency in india Ppt on chapter 12 electricity providers Ppt on hepatitis b vaccine