Security fundamentals

Topic 5Using a Public Key Infrastructure

Agenda

• Certificates• Key distribution• Certificate lifecycle• Trust models• Applications of PKI

Public Key Infrastructure basics• Public key encryption depends on key pairs– public key and private key

• Public key is available to others to encrypt and decrypt messages

• When others encrypt messages with your public key only you can decrypt with your private key

• When you sign a message with your private key, it proves you sent it

• Public key infrastructure allows users to securely exchange or distribute public keys in a large environment

Trusts• PKI uses a third party trust model• You trust a third party to perform an identity

check and verify that a public key belongs to the entity that presents it

• The check is performed by a Certificate Authority (CA)

• A CA can be your organisation or a trusted third party

• You trust the CA to vouch for the identity of the public key owner

Certificate components• Certificate, also called a digital certificate• Used for authentication and secure exchange of information over open networks• Certificate binds a public key to the entity that holds the associated private key• CA certifies the validity of all information in the certificate after it has performed

an identify check

• Defined by ISO standard X.509, the certificate contains:

Enrolment

• The process of requesting and receiving a certificate• The requestor (user or computer) generates a key pair• The requestor sends the certificate request to the CA – Includes the public key and requestor information

• A certificate administrator reviews the request– Verifies information

• Upon approval, the CA issues the certificate– CA creates and signs the certificate with a hash to

prevent modification– CA issues the certificate to the applicant

Certificate uses• Authentication, confidentiality, non-repudiation• Secure mail – S/MIME• Secure web communications – SSL or TLS• Secure websites• Custom security solutions• Smart card logon process• Internet Protocol Security (IPSec)• 802.1x• Encrypting File System (EFS)• Software code signing

Components of a PKI• Digital Certificate• CA: Certification Authority

– Commercial: certificates are widely available– Private: for your company’s use only

• CRL: Certificate Revocation List– Lists certificates that have been revoked before expiry date

• Certificate publishing points and distribution points– Users can obtain certificates and CRLs – Made available in directories, via X.500 or LDAP protocol and on

web servers• Certificate and CA management tools

– Publish and configure, import and export, recover keys• Applications and Services use certificates

The certificate lifecycle• User or computer generates key pair and submits certificate request

including public key and information to CA– Certificate request file– Web enrolment

• CA verifies identity and generates a certificate• Certificate is distributed or published to requesting users/computers• User or computer supplies the certificate when using PKI applications• Certificate reaches end of lifetime

– Either expires– Is renewed and replaced with a new certificate which may or may not

use the same public key

Certificate revocation• Certificate can be revoked before it expires – goes onto the

CRL• Certificate revocation is final and revoked certificates can’t be

reinstated. Should occur when:– the certificate’s owner leaves the company they work for– the certificate’s owner changes their name– a private key has been compromised– the certificate owner’s private key is lost– the CA has been compromised– the certificate has been superseded by a new certificate– the CA has ceased operation

Key archival and recovery• If the private key is lost it becomes impossible to decrypt the data• Key archival and recovery system is used to prevent loss of data• When a user generates a key pair, they submit a copy of the private key to the

CA along with the certificate request• CA stores the private key securely• CAs implement stringent security measures for key archival and recovery

– Keys can only be recovered by one or more designated key recovery agents (KRAs). Smart cards also required sometimes

• Key Escrow– A copy of a user’s private key is held by a separate entity. This entity

releases the private key to a third party when a prearranged event takes place

• M of N control– There are a certain number of recovery agents (N), a minimum number of

these recovery agents (M) have to approve access to a private key

Storage of certificates and keys• Access to the private keys is normally secured by a password

or a passphrase that the user must enter to decrypt the private key

• A more secure storage method for private keys is a smart card.

• A smart card is a credit card-sized computer that generates and stores key pairs. The private key never leaves the smart card.

• Access to the private key requires that you enter a personal identification number (PIN) or password

• Smart cards are considered tamperproof and can be removed from a computer

• Private keys can also be stored in specialized hardware devices that destroy the public keys when someone tampers with the hardware device

Certificate authority trust models• To trust a CA, your computer must contain the certificates of one or

more trusted root CAs• This certificate, which has been issued by a root CA, allows your

computer to determine the authenticity of other certificates that were signed by that root CA

• A root certificate is a self-signed certificate• When a certificate is presented to an application, one of the

validation tests that the application performs is to determine whether the certificate was issued by a CA that is chained to a trusted root

• If the certificate was issued by a trusted root CA or the certificate chains to a trusted root CA, the certificate is trusted by a client

• Most Web browsers contain a list of trusted root CAs that the browser vendor has designated as trustworthy

• You can also place additional root CAs, such as your own organization’s root CA, into the certificate store

Trust models• For a PKI, a trust is a relationship that allows a CA to

trust a certificate issued by another CA • A trust path links several CAs together• For a CA to form a trust relationship with another CA,

one CA must obtain a certificate from the other CA: subordinate CAs

• There are three common ways to configure trust paths:– Hierarchical architecture– A mesh architecture – A bridge CA

Hierarchical architecture

• A hierarchical architecture depends on root CAs

• Root CAs can then issue certificates to other CAs and so on

Mesh architecture

• Multiple peer CAs issue certificates to each other

• To certify, they create certificates for each other

Bridge CA architecture

• A bridge CA connects mesh and hierarchical architectures together

• Allows different companies to have their own trust architecture and have a single connection using a bridge CA

• If the trust relationship needs to be broken, there is only a single point to manage

Secure communications using SSL• SSL: most commonly used to verify a web server’s identity to a web client and

to encrypt data between the client and the server• Authentication and encryption are based on certificates• Web server must have a certificate that was issued by a CA that chains to a

root CA that the web client trusts1. The client establishes the connection with https://2. The web server sends its certificate to the client3. The client verifies the information in the certificate.

• Checks that the certificate was issued by a CA that chains to a root CA that the client trusts

• The certificate has not been tampered with• The certificate’s name matches the name of the Web site that the client is

connecting to• The certificate is valid and has not expired• The certificate has been issued for the purpose of server authentication• If the client is configured to check for certificate revocation, the client checks

any valid cached copies of the CRL or retrieves the CRL

Secure communications using SSL4. Displays the security alert box if any check fails. The client extracts the

Web server’s public key from the certificate5. The client creates a pre-master secret, which is a randomly generated

block of data, encrypts it with the web server’s public key, and then sends it to the web server

6. The web server uses its private key to decrypt the pre-master secret7. The web server and the client create a secret session key based on the

pre-master secret8. The web server and the client encrypt all data that they exchange by

using the session key9. When the web server or client closes the connection, both sides discard

the session key10. If the client establishes another connection, the process starts from the

beginning, creating a new session key

Secure emailYou can use certificates when you sign or encrypt email. How certificates areused depends on whether they are used for signing or encryption.

When a user wants to send a signed email, the following process takes place:1. The email program creates a hash from the email message and signs the

hash with the user’s private key2. The user sends the email and the sender’s certificate to the recipient3. The recipient checks the certificate for its validity, checks whether the

certificate was issued by a CA that chains to a trusted root CA, and verifies that the certificate was issued to the email message’s sender

4. The recipient extracts the sender’s public key from the certificate and decrypts the message hash with it

5. The recipient computes a hash from the email message and compares this hash with the hash that the sender created. If both hashes match, the message was signed by the sender and the message has not been altered

Secure emailWhen a user encrypts an email message to ensureconfidentiality, the following process takes place:1. The sender obtains the recipient’s certificate, checks the certificate for

its validity, verifies that the certificate was issued by a CA that chains to a trusted root CA, then verifies that the certificate was issued to the intended recipient of the email message

2. The sender encrypts the email message with a randomly generated secret key

3. The sender extracts the recipient’s public key from the certificate and encrypts the secret key with this public key

4. The sender sends the email message with the encrypted secret key to the recipient

5. The recipient uses her private key to decrypt the secret key. The recipient then uses the secret key to decrypt the email message

Summary

• What digital certificates are• How keys are distributed and recovered in a

PKI• The certificate lifecycle• Various PKI trust models• How PKI and certificates can be applied