Chapter 9 Key Management All algorithms we

Chapter 9: Key Management • All algorithms we have introduced are based on one assumption: keys have been distributed. But how to do that? • Key generation, distribution, storage, revocation • Bind key to identity (owner) 1

Overview • Key exchange – Session vs. interchange keys – Classical, public key methods • Cryptographic key infrastructure – Certificates • Key revocation • Digital signatures 2

Session, Interchange Keys • Session key: associate with a communication only; is used for a short period of time • Interchange key: associate with a principal; usually is used to establish session keys; is used for a longer period of time 3

Session, Interchange Keys • Alice wants to send a message m to Bob – Alice generates a random cryptographic key k. A, B and uses it to encipher m • To be used for this message only • Called a session key – She enciphers k. A, B with Bob’s public key kpub_B – kpub_B enciphers all session keys that Alice uses to communicate with Bob • Called an interchange key – Alice sends { m } k. A, B || { k. A, B } kpub_B 4

Benefits • Limit the amount of traffic that is enciphered with a single key – Use interchange keys to encrypt session keys – Use session keys to encrypt data – decrease the amount of traffic an attacker can obtain • Prevents some attacks – Example: Alice will send Bob a message that is either “BUY” or “SELL”. Eve computes possible ciphertexts { “BUY” } kpub-B and { “SELL” } kpub-B. Eve intercepts enciphered message, compares, and gets plaintext at once • Called “forward search” 5

• Threats to key distribution/establishment procedures: – Who is the other party of the communication • She says that she is Alice, but is she? – Is the key generated for the communication b/w me and Alice? • Who are the two parties for the key – Does the other party actually know the key? – Is the key fresh? • Two ways to guarantee this 6

Key Exchange Algorithms • Goal: Alice, Bob get shared key – Key cannot be sent in clear • Attacker can listen and get the key • Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper (pre-distributed) – Alice, Bob may trust a third party – All cryptosystems, protocols publicly known • The only secret data are the keys, and some pre-distributed information to Alice and Bob (for key derivation) • Anything transmitted on the network is assumed to be known to attacker 7

Classical Key Exchange • Bootstrap problem: how do Alice, Bob begin? – Alice can’t send the key to Bob in the clear! • Assume a trusted third party, Cathy – Alice and Cathy share secret key k. A, C – Bob and Cathy share secret key k. B, C • Use this to exchange shared key k. A, B 8

Simple Protocol Alice {request for session key to Bob } k. A, C { k. A, B } k. A, C || { k. A, B } k. B, C Alice, { k. A, B } k. B, C Cathy Bob 9

• Methods to fix the problems – About two communication parties: • The names of two parties should be clearly identified in the encrypted messages – The other party needs to show that he/she actually knows the key • Challenge-response – Freshness of the key: • Use time stamp • Or use freshly generated random numbers 10

Otway-Rees Protocol • Does not use timestamps – Does not need clocks to be synchronized • Uses integer n to associate all messages with particular exchange 11

The Protocol Alice n || Alice || Bob || { r 1 || n || Alice || Bob } k. A || Cathy { r 2 || n || Alice || Bob } k. B Cathy Alice n || { r 1 || ks } k. A || { r 2 || ks } k. B n || { r 1 || ks } k. A Bob Bob 12

Argument: Alice talking to Bob • Why a number n – To link all messages of this exchange together • How does Alice make sure: – This is b/w her and Bob • The random number r 1 is linked to this connection b/w Alice and Bob. Only Cathy can open the 2 nd message and see it. – The key is fresh • Because of the random number r 1 – The other party actually knows the key • Not guaranteed in the protocol, but will see in the following data communication 13

Public Key Exchange • Here interchange keys are known to everyone – e. A, e. B: Alice and Bob’s public keys known to all – d. A, d. B: Alice and Bob’s private keys known only to the owner • A simple protocol to establish the session key – ks is the desired session key Alice { ks } e. B Bob 14

Problem and Solution • Vulnerable to forgery or replay – Because e. B is known to everyone, Bob has no assurance that Alice sent the message • Simple fix: uses Alice’s private key to double encrypt the message – Ks: is the desired session key Alice { { ks } d. A } e. B Bob 15

Notes • Assumes Bob has Alice’s public key, and vice versa – If not, they must get the public keys of the other party from a server – If a public key is not bound to an identity, attacker Eve can launch a man-in-the-middle attack (next slide) • Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI) • Man-in-the-middle: Eve pretends to be Alice to Bob, and pretends to be Bob to Alice 16

Man-in-the-Middle Attack I need Bob’s public key Eve intercepts request Alice Cathy I need Bob’s public key Cathy Eve Bob’s pub key e. B Cathy Eve Bob’s pub key e. E Eve Alice { ks } e. E Eve intercepts message Eve { ks } e. B Bob 17

Cryptographic Key Infrastructure • Goal: bind identity to key • Public key: bind identity to public key – It is crucial since people will use the public key to communicate to the principal whose identity is bound to the public key – Erroneous binding means no secrecy between principals – We assume that principal identified by an acceptable name 18

Certificates • A certificate token (message) contains – Identity of principal (here, Alice) – Corresponding public key – Timestamp (when issued, when expire) – Other information (perhaps identity of signer) signed by a trusted authority (here, Cathy) CA = { e. A || Alice || T } d. C 19

Use • Bob gets Alice’s certificate – If he knows Cathy’s public key, he can decipher the certificate • When was the certificate issued? • Is the principal Alice? – Now Bob has Alice’s public key – It does not have to come from Alice • Problem: Bob needs Cathy’s public key to validate certificate – Problem pushed “up” a level – Two approaches: • Certificate hierarchy: Veri. Sign signs certificate for EBay, EBay signs Alice, now you get Alice’s public key if you trust Veri. Sign • Signature chains: friend tells friend 20

Certificate Signature Chains • Create certificate – Generate hash value of the certificate content – Encipher hash with issuer’s private key • Validate – Obtain issuer’s public key – Decipher enciphered hash – Re-compute hash value from certificate and compare • Problem: getting issuer’s public key 21

Issuers • Certification Authority (CA): entity that issues certificates – It will be easy if the whole world has one CA – Multiple issuers pose validation problem – Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s certificate? – Let Cathy and Don cross-certify each other • Each issues certificate for the other 22

X. 509 Validation and Cross. Certifying • Certificates: – – Cathy<> Dan< Cathy<> Dan<> • Alice validates Bob’s certificate – Alice obtains Cathy<> – Alice uses (known) public key of Cathy to validate Cathy<> – Alice uses Dan’s public key to validate Dan<> 23

PGP Chains • Locate a chain of people that trust and issue certificate for the next one in the chain – In PGP, the public key of one principal can be signed by multiple signatures of different people – Notion of “trust” embedded in each signature • Range from “untrusted” to “ultimate trust” • Signer defines meaning of trust level (no standards!) 24

Validating Certificates • Alice needs to validate Bob’s certificate – Alice does not know Fred, Giselle, or Ellen Arrows show signatures Self signatures not shown Jack • Alice gets Giselle’s cert – Knows Henry slightly, but his signature is at “casual” level of trust • Alice gets Ellen’s cert Henry Irene – Knows Jack, so uses his cert to validate Ellen’s, then hers to validate Bob’s Ellen Giselle Fred Bob 25

Key Revocation • Certificates invalidated before expiration – Usually due to compromised key – May be due to change in circumstance (e. g. , someone leaving company) • Problems – Who can revoke certificates: Entities that are authorized to do so – How to let every one know: Revocation information circulates to everyone • Network delays, infrastructure problems may delay information 26

CRLs • Certificate revocation lists certificates that are revoked • X. 509: only certificate issuer can revoke certificate – Added to CRL • PGP: signers can revoke signatures; owners can revoke certificates, or dedicate others to do so 27

Digital Signature • Construct a message that we can prove its origin and integrity of contents to a disinterested third party (“judge”) • Sender cannot deny having sent message (the service is “nonrepudiation”) – Limited to technical proofs • cannot deny one’s cryptographic key was used to sign – One could claim the cryptographic key was stolen or compromised • Legal proofs, etc. , probably required; not dealt with here 28

Public Key Digital Signatures • Alice’s keys are d. Alice, e. Alice • Alice sends Bob m || { m } d. Alice • In case of dispute, judge computes { { m } d. Alice } e. Alice • and if it is m, Alice signed the message – She’s the only one who knows d. Alice! 29

Digital Signatures • Key points: – Never sign random documents, and when signing, always sign the hash of the document • Mathematical properties can be turned against signer – Sign message first, then encipher • Changing public keys causes forgery 30

Key Points • Key management critical to effective use of cryptosystems – Different levels of keys (session vs. interchange) • Keys need infrastructure to identify holders, allow revoking – Key escrowing complicates infrastructure • Digital signatures provide integrity of origin and content – Much easier with public key cryptosystems than with classical cryptosystems • Two types of attacks – Forward search and man-in-the-middle 31