© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Secure IP Telephony Understanding PKIs

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Key Distribution Issues Secure and scalable key exchange is the main issue when deploying cryptography: Symmetric cryptography: –Keys should be changed frequently. –Distribution of the keys to the peers is needed. –Confidentiality of key exchange is needed. Asymmetric cryptography: –Public keys need to be known at all devices. –Distribution of public keys is needed. –Authenticity of key exchange is needed.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Key Exchange in Symmetric Cryptography Out-of-band manual exchange: –Over the phone, by mail, or on media, such as CDs –Does not scale Two options for automated exchange: –Diffie-Hellman algorithm –Exchange of keys protected by asymmetric encryption algorithm Key Transfer over the Telephone (by Reading)

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Key Exchange Protected by Asymmetric Encryption 1. Symmetric key is generated by one peer. 2. Key is encrypted with the public key of the receiver and sent over the network. 3. Only the receiver can decrypt the message by using its private key. 4. Process relies on knowledge of public keys of all possible peers. A RSA AES Key RSA Public Key of User B Private Key of User B B

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Key Exchange in Asymmetric Cryptography All entities have to know public keys of all other entities. Although the key is not secret, exchange of public keys has to be secured: –Authenticity is needed. –Otherwise a man-in-the- middle attack can replace a public key in transit with its own. –This problem is addressed by PKIs. A Public Key of User A Public Key of User B B

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI as a Trusted Third-Party Protocol Does not eliminate the need for authenticity of public keys Solves scalability issues: –Uses a single trusted introducer –Only public key of the introducer has to be initially known and verified (for instance, out of band) by all other entities –Introducer will then guarantee authenticity of public keys of other entities –Uses certificates for each entity, signed by the introducer

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Trusted Introducing in PKIs Locally Generated Key Pairs Every entity, including the trusted introducer, has its own public and private key pair. AC Public Key of User A Private Key of User A Public Key of User C Private Key of User C Private Key of Trusted Introducer Trusted Introducer Public Key of Trusted Introducer

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Distribution of the Public Key of the Trusted Introducer Every entity gets the public key of the trusted introducer and verifies its authenticity (usually out of band). AC Public Key of Trusted Introducer Public Key of User A Private Key of User A Public Key of User C Private Key of User C Private Key of Trusted Introducer Trusted Introducer Public Key of Trusted Introducer

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Request for Signature of Public Keys of Entities Every entity submits its public key to the trusted introducer. A Trusted Introducer C Public Key of User A Private Key of User A Public Key of User C Private Key of User C Private Key of Trusted Introducer Public Key of Trusted Introducer Public Key of User A Public Key of User C

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Trusted Introducer Signing of Public Keys The trusted introducer digitally signs the submitted public keys. Trusted Introducer Private Key of Trusted Introducer A Public Key of User A RSA Content Signing Key Sign Public Key of Trusted Introducer Public Key of User A Public Key of User A Signed by the Trusted Introducer

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Trusted Introducer Public Key of User C Providing Entities with Their Signed Public Keys Signed public keys are returned to the entities. Trusted Introducer Public Key of User A AC Public Key of Trusted Introducer Public Key of User A Private Key of User A Public Key of User C Private Key of User C Private Key of Trusted Introducer Trusted Introducer Public Key of Trusted Introducer

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Public Key Exchange Between Entities Using Their Signed Public Keys Entities can now exchange their signed public keys with each other over an untrusted network. A received public key is verified with the public key of the trusted introducer, which each entity has available locally. Trusted Introducer Public Key of User A AC Public Key of Trusted Introducer Public Key of User A Private Key of User A Public Key of User C Private Key of User C Untrusted Network Trusted Introducer Public Key of User C

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI Entities TermFunction CAThe certification authority (acting as the trusted introducer) Signs public keys of associated entities (PKI users) PKI UsersDevices, users, or applications that want to safely distribute their public keys CertificatesInclude the identity of a PKI entity, its public key, and a signature (created by the CA) Use standard format (X.509v3) CRLA list of certificates that should not be trusted anymorecertificate revocation list

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v X.509v3 Certificates Certificate Format VersionVersion 3 Certificate Serial Number Signature Algorithm Identifier for CA RSA with SHA-1 Issuer X.500 NameC = US O = Cisco CN = CA Validity Period Start = 04/01/04 Expire = 04/01/09 Subject X.500 Name C = US O = Cisco CN = CCMCluster001 Subject Public Key Information756ECE0C9ADC Extension(s) (v3) CA Signature2C086C7FE0B6E90DA396AB…

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Self-Signed Certificates CA, as the root of a PKI, signs its own certificate (self-signed CA certificate). Sometimes entities issue self-signed certificates: –If they are not part of a PKI (not associated with a CA) but use PKI-enabled applications –Cannot be verified automatically –Need additional methods of verification (such as manual verification)

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI Enrollment Enrollment is the procedure of adding a new user to the PKI: –The PKI user has to receive the CA certificate. –The CA needs to receive the identity and public key of the user, sign them, and return a signed certificate to the user. Procedure is vulnerable to man-in-the-middle attacksneeds to be secured.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Man-in-the-Middle Attack During PKI Enrollment Attacker can replace public key of the user by its own public key when asking real CA for a certificate (pretends to be the user to the CA) Attacker can replace CA certificate by a self- generated certificate (pretends to be the CA to the user) A Fraudulent Public Key of CA Public Key of User A Public Key of CA Fraudulent Public Key of User A CA Attacker

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Secure PKI Enrollment Authentication is needed for secure PKI enrollment: –User needs to verify certificate of the CA –CA needs to verify certificate of the user –Enrollment cannot be automated –Sent and received fingerprints of messages (certificates) have to be compared Authentication is not needed if enrollment is done over a secure network channel (physically separated network or network protected by IPsec).

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Authentication of PKI Enrollment Out-of-band verification (for example, over the telephone) of local fingerprint (hash) and remote fingerprint is needed. A Public Key of User A Public Key of CA Public Key of User A Public Key of CA CA Untrusted Network SHA-1 C99fe50B24p e7cD25k4L8...

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI Revocation Certificates (and associated public and private keys) have a lifetime, which is usually relatively long (up to one year or more). Sometimes keys become invalid before expiration: –If the private key is compromised or lost –If the contract with the PKI user is terminated Certificate revocation is used in such casesan announcement that a private key is no longer trusted.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI Revocation Methods Manual revocation: –Deleting the compromised certificates or keys on affected systems –Does not scale Automatic revocation: –Publishing a list of revoked certificates using a CRL, downloaded by PKI users –Providing an online service answering certificate status queries in real time using OCSP

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Key Storage Private or shared secret keys should be considered at least as sensitive as the messages protected with the keys –Ideally, keys are never stored anywhere in cleartext form or in user-accessible storage. Keys with long lifetimes, such as asymmetric keys, should be protected especially well –Ideally, they are stored on smart cards or tokens.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Smart Cards and Smart Tokens Small computers: Providing tamper-resistant storage for protecting cryptographic keys and other information Allowing portability of private information between devices Isolating security-related functions involving authentication, digital signatures, and key exchange from other parts of the system Actual signing inside the smart device with the private key never leaving it

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI Examples SSL: –Designed for secured HTTP browsing –Used by sensitive web servers (for example, e-banking and e-commerce) TLS: –Successor of SSL –Application-independent IPsec

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v VeriSign PKI and SSL or TLS Used for sensitive web applications The web server has a private and public key The web server has a certificate, usually issued by a public Internet CA (such as VeriSign) VeriSign Web Server Public Key of Web Server Private Key of VeriSign Public Key of Web Server Private Key of Web Server

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Browser-Embedded CA Certificates A client operating systems or browser has more than 100 Internet CA certificates already embedded.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Web Browser VeriSign Web Server VeriSign Web Server Certificate Verification The server passes its certificate to the client at connection startup. The client verifies the certificate using the embedded certificate of the CA that has issued the certificate of the web server. The client extracts the public key of the web server from the certificate. Public Key of Web Server Private Key of Web Server Public Key of Web Server Public Key of VeriSign Internet Verify Signature

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Web ServerWeb Browser Web Server Authentication The client sends random data to the web server. The web server uses its private key to sign the data and sends it back. The client verifies the returned data using the public key of the web server retrieved from the certificate. If returned data matches the sent data, the web server has the correct private key, and therefore it is authentic. Private Key of Web Server Public Key of Web Server Internet RSA p2CksD1f3r... Challenge Response Sign Random String

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Web ServerWeb Browser Exchange of Session Keys The client generates symmetric session keys for encryption and HMAC algorithms to provide session protection. The client encrypts the keys using the public key of the web server and sends them to the web server. The web server (only) can decrypt the session keys using its private key. Private Key of Web Server Internet RSA ke4P6d23Le... Public Key of Web Server Session Keys Generate Session Keys

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Internet Web ServerWeb Browser Session Encryption Packets between web server and client can now be signed (using HMAC, such as keyed MD5 or keyed SHA-1) and encrypted (using encryption algorithms, such as 3DES, AES, or RC4). 3DES Ss199le4... Session Keys Data from Browser Session Keys 3DES Data from Server 3DES Data from Server dV46ax7... Data from Browser

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v PKI and IPsec IPsec can protect any IP packets (operates at network layer). IKE protocol is used for key management. PKI can be used during IKE for peer authentication and to ensure integrity of Diffie-Hellman exchange. Each IPsec peer has a private and public key. Each IPsec peer has its own certificate (issued by a CA) and a certificate of the CA (obtained during enrollment).

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Mutual Certificate Verification Peers mutually exchange certificates. Each peer verifies the certificate of the other peer using the certificate of the CA. Each peer extracts the public key of the other peer from the received certificate.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Mutual Authentication Each peer challenges the other peer, sending random data to the other peer. Each peer uses its private key to sign the received data and sends it back. Each peer verifies the returned data using the public key of the peer retrieved from the peers certificate. If returned data matches the sent data, the peer has the correct private key, and therefore it is authentic.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Protected DH Exchange and Session Key Generation Each peer runs DH algorithm generating (different) public information to be exchanged. Each peer signs its public DH information using its own private key and and sends it. Each peer verifies the signature of the received DH information. Each peer finishes DH algorithm using local (secret) information and other peers public information. As a result peers, have a shared secret from which they create session keys.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Session Encryption IP packets between peers can now be signed (using HMAC, such as keyed MD5 or keyed SHA-1) and encrypted (using encryption algorithms, such as 3DES, AES, or RC4).

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v Summary PKI is needed for secure, scalable key exchange. PKI uses the concept of a single trusted introducer to eliminate the need for any-to-any authentication. PKI entities, such as the CA and its associated users, have certificates issued by the CA. PKI enrollment is the process of adding new users to the system. PKI enrollment always needs separate authentication. PKI revocation allows certificates to be announced as invalid before the lifetime has expired. PKI revocation is needed when private keys become compromised and therefore cannot be trusted anymore. SSL, TLS, and S/MIME are common examples of PKI-enabled protocols.

© 2006 Cisco Systems, Inc. All rights reserved.CIPT2 v