CERT IFICATES & PKI

1. CERTIFICATES & PKI BCIS 4630 Fundamentals of IT Security Dr. Andy Wu

2. Overview • Digital signature • PKI • Public Key Applications • Digital certificate • Secure Socket Layer

3. Non-Repudiation • Non-repudiation means that someone cannot later deny something that he/she agreed to earlier. • To establish non-repudiation, one must prove two things: • Authentication: the other person was the person who signed (Use the “Authentication” utilization of asymmetric encryption to prove it). • Integrity of document: the document the other person signed has not been modified since it leaves him/her (Use hash to prove it).

4. Non-Repudiation • Hash + Asymmetric Encryption = Digital Signature • Digital Signature • The message to be digitally signed is first hashed and then the message digest is encrypted with the sender’s private key. • It’s one step further than integrity by authenticating the identity of the sender. • The sender cannot deny sending the file because she supposedly is the only person having access to her private key. • The sender cannot deny the document in your possession wasn’t the one she signed if the hash value hasn’t changed.

5. Digital Signature - Signing • The sender digitally signs the message by • Calculating the hash value of the message. • Encrypting the hash with the sender’s private key. • Optionally, the sender may encrypt the message after the hash is run, but this is not a required part of the signing.

6. Digital Signature - Signing Source: Tom Austin, PKI, A Wiley Tech Brief.

7. Digital Signature - Verification • The recipient verifies the digital signature by: • Obtaining the sender’s public key and using it to decrypt the encrypted hash value. • Using the same hash algorithm used by the sender, calculating the hash value of the message. • Comparing the locally computed hash value to the decrypted hash value.

8. Digital Signature - Verification Source: Tom Austin, PKI, A Wiley Tech Brief.

9. Digital Signature - Verification • The recipient verifies that: • The message has not been tempered with since it was signed (integrity). • The person who supposedly sent the message really did (authentication).

10. Why PKI? If anyone can upload a public key on behalf of someone else…

11. Why PKI? • John and Diane want to communicate securely. • John can generate his own public/private key pair and send his public key to Diane or place it in a directory that is available to everyone (a key depository). • Without a PKI, Katie also can generate her own key pair, and place her public under Diane’s name. This in effect allows Katie to steal Diane’s identity.

12. Public Key Infrastructure • Uses symmetric and asymmetric cryptographic technologies. These technologies can be used by: • E-mail clients • Virtual private network products • Web server components • Domain controllers • Etc. • A Framework for different products and technologies to integrate with each other to supply various security services.

13. Components of PKI • PKI is made up of: • Hardware • Applications • Policies • Services • Programming interfaces • Cryptographic algorithms • Protocols • Users • Utilities

14. What Does PKI Do? • It provides third-party (institutional) trust. • It binds people’s public key to their identity. • Before a person’s public key is placed in a key depository, his/her public key must be bound to his/her identity.

15. What Does PKI Do?

16. Who Stands Behind PKI? • In PKI environments, entities called certificate authorities (Cas) provide a service similar to that of the Department of Motor Vehicles (DMV). • A CA issues a digital certificate containing necessary identification information about an entity, combines the entity’s public key with the certificate, and digitally signed it with the CA’s private key.

17. Certificate Authorities • The trusted authority for certifying an entity’s identity and creating an electronic document indicating that entities are who they claim to be. • The electronic document is referred to as a digital certificate. • It establishes an association between the entity’s identity and the entity’s public key. • The entity keeps the corresponding private key separately. • The CA signs an entity’s public key with the CA’s private key. • If you can decrypt the certificate with the CA’s public key (most popular ones stored on your computer as Windows was installed), you can trust the entity’s public key. • If not, the entity’s public key (and identity too) is suspicious.

18. Registration Authority • The registration authority (RA) is the component that accepts a request for a digital certificate. • They performs the necessary steps of registering and authenticating the entity requesting a certificate. • RAs cannot generate certificates. • Once they finish processing the request and verifying the individual’s identity, the request is sent to the CA.

19. Fields in A Certificate • Version Number • The version of the X.509 standard that was followed to create the certificate. • Serial number • A unique number identifying a specific certificate issued by a particular CA. • Signature algorithm • The hashing algorithm and the digital signature algorithm used to digitally sign the certificate. • Issuer • The CA that generated and digitally signed the certificate. • Validity • The period during which the certificate is valid. • Defined by the “Valid from” and “Valid to” dates.

20. Fields in A Certificate • Subject • Owner of the certificate. • Can be a network device, an application, a department, a company, or a person. • Public key • The public key being bound to the certified subject. • Also identifies the algorithm used to create the key pair. • Extensions • Allow additional data to be encoded into the certificate to expand the functionality of the certificate. • CA digital signature • Hash (thumbprint) algorithm used for the signature. • The signature itself.

21. Certificate Examples

28. Certificate Revocation • A certificates is revoked when its validity needs to be ended before its actual expiration date. • A certificate has to be revoked if: • The private key that is related to the public key in the certificate has been or may have been compromised. • The subscriber has breached or unable to exercise a material obligation stipulated in the contract. • The frequency with which revocation information (in the form of a certificate revocation list, or CRL) is updated and distributed is an extremely important consideration.

29. Certificate Revocation • Examples of situations where a certificate needs to be revoked: • A user loses a laptop or a smart card that stored a private key. • An improper software implementation has been uncovered that directly affected the security of a private key. • A user has fallen victim to a social engineering attack and inadvertently given up a private key. • Data held within the certificate no longer apply to the specified individual. • An employee has left a company.

30. Certificate Suspension • Instead of being revoked, a certificate is sometimes suspended, meaning it is temporarily put on hold. • The CRL would list this certificate and its serial number, and in the field that describes why a certificate was revoked, it would instead indicate a hold state. • Suspension may be removed later. • It is not wise to trust a suspended certificate.

31. Reasons for Suspension • A certificate may be suspended due to some temporary problems • The key might have been compromised, but the investigation is still under way. • The subscriber has not paid annual service fee to the CA. • An individual is on vacation and wants to ensure that the certificate will not be compromised or used during that time • Once the temporary problems are resolved, a request can be made to the CA to remove the certificate from the CRL.

32. Chain of Trust • A CA vouches for other entities’ identity. But who vouches for the CA? • A CA can have its identity endorsed by another CA. • That other CA can, in turn, be endorsed by yet another CA. • This creates a hierarchical chain of trust. • Ultimately, however, there will be CA(s) whose identity we must accept by faith for the whole PKI system to work. • Windows and other OSes trust a number of root CAs when the OS is installed.

33. Chain of Trust

34. Chain of Trust

35. Web Communication Encryption • Secure Sockets Layer (SSL) is a general-purpose protocol developed by Netscape for managing the encryption of information being transmitted over the Internet. • SSL is the most common public key application.Itprovides: • Authentication • Allows the client to make sure it is talking to the correct server. • Confidentiality • Establishes a strong, cryptographically protected connection between the client and the server.

36. Secure Socket Layer • HTTP is used for the transfer of hyperlinked data over the Internet, from web servers to browsers. • One of the primary drivers behind the development of SSL/TLS was the desire to hide the complexities of cryptography from end users. • When using an SSL/TLS-enabled browser, this can be done simply by requesting a secure connection from a web server instead of a nonsecure connection. • When a secure connection is needed, SSL/TLS is used and appears in the address as https://.

37. SSL - Authentication • SSL uses digital certificate for authenticating the server to the client. This is mandatory. • Authenticating the client to the server can be desirable in high security environments. But this is not the mandatory (default) setting of SSL. • The certificate only tells the user that a server is what it claims to be, based on his/her trust placed in the CA that issues the certificate. • It does not say anything about the contents of the communication, e.g., the certificate for a program’s installer only says that it was made by the entity shown on the certificate. It doesn’t guarantee that the program is safe.

38. SSL - Confidentiality • For the client and server to communicate, both sides must agree on a commonly held protocol (SSL v1, v2, v3, or TLS v1) and encryption algorithm. • Commonly available cryptographic algorithms include Diffie-Hellman and RSA. • The channel is protected by encryption against eavesdropping. • Each packet is encrypted using the symmetric key before transfer across the network, and then decrypted by the receiver.

39. SSL Handshake

40. SSL Handshake • ClientHello: Ask the server to begin negotiating security services by using SSL. • Contains a CipherSuite field that states the cryptographic services the client can support. • ServerHello: Contains a CipherSuite field that states the exact cryptographic parameters, algorithms, key sizes, etc. to be used for the session. • It is chosen from the options in the ClientHello message. • ServerKeyExchange: Contains the server’s public key embedded in a certificate (server certificate). • ServerHelloDone: Indicates that the server has finished its initial negotiation messages.

41. SSL Handshake • ClientKeyExchange: Client tells the server its key information – the symmetric keys encrypted using the server’s public key. • One key is used to encrypt data the client sends to the server. The other for encrypting the opposite data flow. • ChangeCipherSpec: It explicitly indicates that the security services should now be invoked. • Symmetric encryption algorithm, message integrity algorithm, etc. • Client and server now take the cue and exchange data securely.

42. SSL Handshake • Finished: Both systems verify the success of negotiation. • Client may be required by the server to authenticate itself to the server. • The server sends CertificateRequest after its own ServerKeyExchange message. • The client responds with a Certificate message after ServerHelloDone. • The client also sends a CertificateVerify message that contains signed hashes of data that the client and the server both possess at this point. • The server then can verify the client’s certificate.

43. SSL with Client Authentication

44. Common Errors in SSL

46. Common Errors in SSL