Security fundamentals Topic 5 Using 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: – The subject of the certificate (name of the computer or user who requested the certificate) – The public key – The certificate’s validity period – of owner – Signed hash of the certificate (signed with the private key of the CA) – Uses of the certificate – Details of CA

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 trusts 1. The client establishes the connection with 2. The web server sends its certificate to the client 3. 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 SSL 4.Displays the security alert box if any check fails. The client extracts the Web server’s public key from the certificate 5.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 secret 7.The web server and the client create a secret session key based on the pre-master secret 8.The web server and the client encrypt all data that they exchange by using the session key 9.When the web server or client closes the connection, both sides discard the session key 10.If the client establishes another connection, the process starts from the beginning, creating a new session key

Secure You can use certificates when you sign or encrypt . How certificates are used depends on whether they are used for signing or encryption. When a user wants to send a signed , the following process takes place: 1.The program creates a hash from the message and signs the hash with the user’s private key 2.The user sends the and the sender’s certificate to the recipient 3.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 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 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 When a user encrypts an message to ensure confidentiality, 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 message 2.The sender encrypts the 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 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 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