Lecture 12 Overview

Key Management public-key encryption helps address key distribution problems have two aspects of this: distribution of public keys use of public-key encryption to distribute secret keys One of the major roles of public-key encryption has been to address the problem of key distribution, with two distinct aspects: the distribution of public keys, and the use of public-key encryption to distribute secret keys. CS 450/650 Lecture 12: Key Exchange

Distribution of Public Keys can be considered as using one of: public announcement publicly available directory public-key authority public-key certificates Several techniques have been proposed for the distribution of public keys, which can mostly be grouped into the categories shown. CS 450/650 Lecture 12: Key Exchange

Public Announcement users distribute public keys to recipients or broadcast to community at large append PGP keys to email messages or post to news groups or email list major weakness is forgery anyone can create a key claiming to be someone else and broadcast it until forgery is discovered attacker can masquerade as claimed user The point of public-key encryption is that the public key is public, hence any participant can send his or her public key to any other participant, or broadcast the key to the community at large. Its major weakness is forgery, anyone can create a key claiming to be someone else and broadcast it, and until the forgery is discovered they can masquerade as the claimed user. CS 450/650 Lecture 12: Key Exchange

Publicly Available Directory can obtain greater security by registering keys with a public directory directory must be trusted with properties: contains {name, public-key} entries participants register securely with directory participants can replace key at any time directory is periodically published directory can be accessed electronically still vulnerable to tampering or forgery A greater degree of security can be achieved by maintaining a publicly available dynamic directory of public keys. Maintenance and distribution of the public directory would have to be the responsibility of some trusted entity or organization. This scheme is clearly more secure than individual public announcements but still has vulnerabilities to tampering or forgery. CS 450/650 Lecture 12: Key Exchange

Public-Key Authority improve security by tightening control over distribution of keys from directory has properties of directory requires users to know public key for the directory users interact with directory to obtain any desired public key securely requires real-time access to directory when keys are needed Stronger security for public-key distribution can be achieved by providing tighter control over the distribution of public keys from the directory. It requires users to know the public key for the directory, and that they interact with directory in real-time to obtain any desired public key securely. Note that a total of seven messages are required, as shown next. CS 450/650 Lecture 12: Key Exchange

Public-Key Authority Stallings Figure 10.3 “Public-Key Authority” illustrates a typical protocol interaction. See text for details of steps in protocol. CS 450/650 Lecture 12: Key Exchange

Public-Key Certificates certificates allow key exchange without real-time access to public-key authority a certificate binds identity to public key usually with other info such as period of validity, rights of use all contents signed by a trusted Public-Key or Certificate Authority (CA) can be verified by anyone who knows the public-key authority’s public-key An further improvement is to use certificates, which can be used to exchange keys without contacting a public-key authority, in a way that is as reliable as if the keys were obtained directly from a public-key authority. A certificate binds an identity to public key, with all contents signed by a trusted Public-Key or Certificate Authority (CA). This can be verified by anyone who knows the public-key authorities public-key. One scheme has become universally accepted for formatting public-key certificates: the X.509 standard. X.509 certificates are used in most network security applications, including IP security, secure sockets layer (SSL), secure electronic transactions (SET), and S/MIME. CS 450/650 Lecture 12: Key Exchange

Public-Key Certificates Stallings Figure 10.4 “Public-Key Certificates” illustrates such a scheme. See text for details of steps in protocol. CS 450/650 Lecture 12: Key Exchange

Distribution of Secret Keys use previous methods to obtain public-key can use for secrecy or authentication public-key algorithms are slow usually prefer to use private-key encryption to protect message contents hence need a session key have several alternatives for negotiating a suitable session Once public keys have been distributed or have become accessible, secure communication that thwarts eavesdropping, tampering, or both, is possible. However, few users will wish to make exclusive use of public-key encryption for communication because of the relatively slow data rates that can be achieved. Accordingly, public-key encryption provides for the distribution of secret keys to be used for conventional encryption. CS 450/650 Lecture 12: Key Exchange

Public-Key Distribution of Secret Keys if have securely exchanged public-keys: Stallings Figure 10.6 “Public-Key Distribution of Secret Keys” illustrates such an exchange. See text for details of steps in protocol. Note that these steps correspond to final 3 of Figure 10.3, hence can get both secret key exchange and authentication in a single protocol. CS 450/650 Lecture 12: Key Exchange

Diffie-Hellman Key Exchange public-key type scheme proposed in 1976 note: now know that Williamson (UK CESG) secretly proposed the concept in 1970 A practical method for public exchange of a secret key Used in a number of commercial products The idea of public key schemes, and the first practical scheme, which was for key distribution only, was published in 1977 by Diffie & Hellman. The concept had been previously described in a classified report in 1970 by Williamson (UK CESG) - and subsequently declassified in 1987, see [ELLI99]. CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

Diffie-Hellman Key Exchange public-key distribution scheme cannot be used to exchange an arbitrary message rather it can establish a common key known only to the two participants based on exponentiation in a finite field modulo a prime or a polynomial security relies on the difficulty of computing discrete logarithms The purpose of the algorithm is to enable two users to securely exchange a key that can then be used for subsequent encryption of messages. The algorithm itself is limited to the exchange of secret values, which depends on the value of the public/private keys of the participants. The Diffie-Hellman algorithm uses exponentiation in a finite (Galois) field (modulo a prime or a polynomial), and depends for its effectiveness on the difficulty of computing discrete logarithms. CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

Diffie-Hellman Setup all users agree on global parameters: large prime integer or polynomial p g = primitive root mod p for every integer a that has gcd(a, p) = 1, there is an integer k such that gk ≡ a (mod p) each user generates their key chooses a secret key (number): a < p compute their public key: A = ga mod p In the Diffie-Hellman key exchange algorithm, there are two publicly known numbers: a prime number p and an integer g that is a primitive root of p. The prime p and primitive root g can be common to all using some instance of the D-H scheme. Note that the primitive root g is a number whose powers successively generate all the elements mod p. Users Alice and Bob choose random secrets a's, and then "protect" them using exponentiation to create their public A's. For an attacker monitoring the exchange of the A's to recover either of the a's, they'd need to solve the discrete logarithm problem, which is hard. CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

Diffie-Hellman Key Exchange shared session key for users is KAB: KAB = gab mod p = Ab mod p (which B can compute) = Ba mod p (which A can compute) g can be small 2 or 5 is common a, b, p should be large attacker needs a or b to obtain the session key must solve discrete log The actual key exchange for either party consists of raising the others "public key' to power of their private key. The resulting number (or as much of as is necessary) is used as the key for a block cipher or other private key scheme. For an attacker to obtain the same value they need at least one of the secret numbers, which means solving a discrete log, which is computationally infeasible given large enough numbers. Note that if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys. CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

Diffie-Hellman Example users Alice & Bob who wish to swap keys agree on prime p=353 and g=3 select random secret keys: A chooses a=97, B chooses b=233 compute respective public keys: A=397 mod 353 = 40 (Alice) B=3233 mod 353 = 248 (Bob) compute shared session key as: KAB = Ba mod 353 = 24897 = 160 (Alice) KAB = Ab mod 353 = 40233 = 160 (Bob) Here is an example of Diffie-Hellman from the text. CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

Key Exchange Protocols users could create random Diffie-Hellman keys each time they communicate users could create a known Diffie-Hellman key and publish in a directory, then consult and use to securely communicate with them both of these are vulnerable to a man-in-the-middle attack authentication of the keys is needed Detail a couple of possible Key Exchange Protocols based on Diffie-Hellman. Note that these are vulnerable to a meet-in-the-Middle Attack, and that authentication of the keys is needed. CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

Lecture 13 Digital Certificates CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Robin Burke

Trusting a Public Key We can't trust We might trust the public key associated with a message We might trust an authoritative source to vouch for Alice CS 450/650 Lecture 13: Digital Certificates

Digital Certificates A digital certificate is a digital file that certifies the identity of an individual an institution a server a router seeking access to computer- based information It is issued by a Certification Authority (CA) CS 450/650 Lecture 13: Digital Certificates

Digital certificates wolfmail.unr.edu name public key X.509 CS 450/650 Lecture 13: Digital Certificates

Trusted third party Certification authority (CA) CA can CA will then issue digital certificates and validate holders’ identity and authority CA can meet with Alice look at her driver's license / birth certificate / etc take her fingerprints CA will then sign her public key CS 450/650 Lecture 13: Digital Certificates

Man-in-the-middle? When Trudy tries to substitute her public key for Alice's Bob will either notice that the key isn't certified or notice that it is certified but not for Alice CS 450/650 Lecture 13: Digital Certificates

Masquerading as CA? Trudy could falsely issue a certificate sign the certificate pretending to be the CA but strong interest in making CA’s correct public key well known Multiple sources to access the CA's public key some public keys are actually bundled with the browser CS 450/650 Lecture 13: Digital Certificates

Public key certificate A public key An identifier Certificate by the CA Embed public key along with other identifying information cryptographically sign it as a tamper-proof seal verifying the integrity of the data within the certificate validating its use CS 450/650 Lecture 13: Digital Certificates

Benefits of certification Alice and Bob can exchange certificates directly no need for a separate way to communicate public keys certificate is self-protecting Many users can participate only need to know CA's public key CS 450/650 Lecture 13: Digital Certificates

Uses of Digital Certificates In a number of Internet applications that include: Secure Socket Layer (SSL) developed by Netscape Communications Corporation Secure Multipurpose Internet Mail Extensions (S/MIME) Standard for securing email and electronic data interchange (EDI). Secure Electronic Transactions (SET) protocol for securing electronic payments Internet Protocol Secure Standard (IPSec) for authenticating networking devices CS 450/650 Lecture 13: Digital Certificates

Issues Trust in the CA Security of the CA's private key issuance policies Security of the CA's private key very important!!! CS 450/650 Lecture 13: Digital Certificates

Multiple CAs If there is only one CA Multiple CAs all is simple Multiple CAs Alice's public key is signed by C1 Bob's public key is signed by C2 How can Bob be confident? maybe C1 is really Trudy in disguise CS 450/650 Lecture 13: Digital Certificates

Solutions Full distribution Cross certification every user has the public key for every CA Impractical Cross certification Suppose Alice presents Bob with C1's public key Signed by C2 Bob can verify the certificate C2 C1's public key can be trusted Therefore Alice's public key can be trusted CS 450/650 Lecture 13: Digital Certificates

Hierarchical trust model Root CA a generally-trusted CA e.g. Federal Reserve Bank all parties trust root Non-root CAs have certificates signed by root CA, or signed by another non-root CA closer to the root CA Certification path the chain of certifications from the root to a particular public key certificate CS 450/650 Lecture 13: Digital Certificates

CA relationships Intra-organization communication The third party CA Bank ATM network Organization can be its own CA The third party CA CA is an independent entity is like a notary public is evaluating the truth of a person's representation may be liable if due diligence is not performed CS 450/650 Lecture 13: Digital Certificates

Validity Public key is not valid forever limits risk associated with key compromise 1 year is typical Certificates have a valid period expired certificate may still be useful non-repudiation new certificate issued when old one expires Possibly the same key re-certified CS 450/650 Lecture 13: Digital Certificates

Certificate assumptions During the valid period public key is valid for use association with identity assumed correct revocation notifications will be published CS 450/650 Lecture 13: Digital Certificates

Non-repudiation Increasing legislation to allow digital signatures to serve as legally binding Non-repudiation of digital signatures Provides proof of the integrity and origin of data both unforgeable, which can be verified by any third party at any time An authentication that with high assurance can be asserted to be genuine and cannot subsequently be refuted CS 450/650 Lecture 13: Digital Certificates

Revocation What if Trudy hacks into Bob's computer and steals his private key? Alice will still be sending encrypted messages, but now Trudy can read Certificate must be revoked can no longer be trusted new certificate issued how does Alice find this out? CS 450/650 Lecture 13: Digital Certificates

Revoking a certificate Reasons for revocation Detected or suspected compromise Change of data e.g. subject name Change of relationship between subject and CA e.g. employee quitting a job from an organization which uses the current CA CS 450/650 Lecture 13: Digital Certificates

Who can revoke? who revokes? the subject the CA an authorized third party e.g. the organization with an employee quitting Authentication of the source of revocation request is needed CS 450/650 Lecture 13: Digital Certificates

Certificate Revocation List CRL is a time-stamped list of revoked certificates digitally signed by the CA available to all users Each revoked cert is identified by a certificate serial number CRL contains digital signatures, thus can be sent via unprotected channels Users of public key certificates should check a suitably-recent CRL CS 450/650 Lecture 13: Digital Certificates

Certificate Revocation List The user of a public key must check the CRL every time the key is used not enough to check when the certificate is originally accepted CA must keep a revoked certificate in the CRL until it expires list could get large CS 450/650 Lecture 13: Digital Certificates

Example Trudy steals Bob's private key Bob discovers break-in requests certificate revocation Trudy sends a forged message to Alice Alice verifies message checks CRL no problems with Bob's public key CA publishes CRL with Bob's revocation too late CS 450/650 Lecture 13: Digital Certificates

CRL Distribution Pull method Push method CA periodically updates CRL depository users check when using a public key Push method broadcast new CRL when it changes Both subject to denial of service attacks CS 450/650 Lecture 13: Digital Certificates

CRLs Problems similar to blacklists with credit card companies Database is periodically pruned, but still very large Time delay between certificate being revoked and revocation being published in CRL Widely-used CRLs have too many verifiers to be able to effectively use the “push” method Susceptible to DOS attacks Is the software default to accept or reject the certificate? CS 450/650 Lecture 13: Digital Certificates

Online Certificate Status Protocol Request / response protocol Verifier receives up-to-the-minute status info Alice checks Bob's public key directly with CA most effective most costly Costs handling traffic for every public key use handling cryptographic operations at high spped maintaining high security in Internet environment Also subject to denial of service attack CS 450/650 Lecture 13: Digital Certificates

Short-Lived Certificates Certificate valid for 1 day at a time re-requested each day possibly the same public key Revocation not necessary Suitable for limited resource systems e.g. mobile wireless systems Assumes efficient certificate generation CS 450/650 Lecture 13: Digital Certificates

Obtaining a certificate Subscriber generates a public\private key pair. Applies to CA for digital certificate with the public key. CA verifies subscriber's identity and issues digital certificate containing the public key.   CA publishes certificate to public, on-line repository.   Subscriber signs message with private key and sends message to second party.   Receiving party verifies digital signature with sender's public key and requests verification of sender's digital certificate from CA's public repository.   Repository reports status of subscriber's certificate. CS 450/650 Lecture 13: Digital Certificates

Obtaining a certificate Digital signature (encrypt) K B + Bob’s public key K B + CA private key - K CA certificate for Bob’s public key, signed by CA Bob’s identifying information CS 450/650 Lecture 13: Digital Certificates

CA's key management CA keys have many uses Short-use private keys But signing (real-time validation) historical validation Short-use private keys better security But a signed certificate can't have a valid period beyond the signer's certificate CA will need multiple keys for different purposes CS 450/650 Lecture 13: Digital Certificates

Certificate distribution Alice sends Bob a two line signed email signature ≈ message size certificate > message size Alice's public key + CA's signature certificate for each CA in certification path Certification info could easily be 10x the message size What if Bob already has Alice's public key? CS 450/650 Lecture 13: Digital Certificates

Certificate + Signature Inefficient Not practical in network environment Different users might need different certification paths can't predict which certificates to include CS 450/650 Lecture 13: Digital Certificates

Directory services General case for public key discovery Online access to a directory request a public key certificate for a given user In this case Alice sends only the signed message Bob is responsible for getting Alice's certificate CS 450/650 Lecture 13: Digital Certificates

Obtaining an Individual’s Public Key When Alice wants Bob’s public key: Alice gets Bob’s certificate (from Bob or elsewhere) apply CA’s public key to Bob’s certificate, get Bob’s public key digital signature (decrypt) K B + Bob’s public key K B + CA public key K CA CS 450/650 Lecture 13: Digital Certificates