1 chapter 9: key management all algorithms we have introduced are based on one assumption: keys have...
Post on 20-Dec-2015
218 views
TRANSCRIPT
1
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)
2
Overview
• Key exchange– Session vs. interchange keys– Classical, public key methods
• Cryptographic key infrastructure– Certificates
• Key revocation• Digital signatures
3
Notation
• X Y : { Z || W } kX,Y
– X sends Y the message produced by concatenating Z and W enciphered by key kX,Y, which is shared by users X and Y
• A T : { Z } kA || { W } kA,T
– A sends T a message consisting of the concatenation of Z enciphered using kA (A’s key), and W enciphered using kA,T, the key shared by A and T
• r1, r2: nonces (non-repeating random numbers)
4
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
5
Session, Interchange Keys
• Alice wants to send a message m to Bob– Alice generates a random cryptographic key kA,B and
uses it to encipher m• To be used for this message only• Called a session key
– She enciphers kA,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 } kA,B || { kA,B } kpub_B
6
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”
7
• 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
8
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
9
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 kA,C
– Bob and Cathy share secret key kB,C
• Use this to exchange shared key kA,B
10
Simple Protocol
Alice Cathy{request for session key to Bob } kA,C
Alice Cathy{ kA,B } kA,C || { kA,B } kB,C
Alice BobAlice, { kA,B } kB,C
11
Problems
• Now let us look at Bob:– Does Bob knows the other party? Not really– Does Bob knows the key is for him: Yes– Does the other party actually know the key? Not sure– Is the key fresh? Not sure
• Some attacks may exist– Session key reuse: Eve talked to Bob and got a
session key. She replays this message and pretends to be Alice to talk to Bob
12
• 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
13
Otway-Rees Protocol
• Does not use timestamps– Does not need clocks to be synchronized
• Uses integer n to associate all messages with particular exchange
14
The Protocol
Alice Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA
Cathy Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA ||
{ r2 || n || Alice || Bob } kB
Cathy Bobn || { r1 || ks } kA || { r2 || ks } kB
Alice Bobn || { r1 || ks } kA
15
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 r1 is linked to this connection b/w Alice and Bob. Only Cathy can open the 2nd message and see it.
– The key is fresh• Because of the random number r1
– The other party actually knows the key• Not guaranteed in the protocol, but will see in the following
data communication
16
Argument: Alice talking to Bob
• How does Bob make sure:– This is b/w him and Alice
• The random number r2 is linked to this connection b/w Alice and Bob. Only Cathy can open the 2nd message and see it.
– The key is fresh• Because of the random number r2
– The other party actually knows the key• Not guaranteed in the protocol, but will show in the
following data communication
17
Replay Attack
• Possible attack– Eve acquires old ks and the message in the third step
– The message is: n || { r1 || ks } kA || { r2 || ks } kB
– Eve resends the message to Alice• Alice has no ongoing key exchange with Bob: n matches
nothing, so is rejected• Alice has ongoing key exchange with Bob: r1 does not
match, so is again rejected
18
Public Key Key Exchange
• Here interchange keys are known to everyone– eA, eB: Alice and Bob’s public keys known to all
– dA, dB: 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 Bob{ ks } eB
19
Problem and Solution
• Vulnerable to forgery or replay– Because eB 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 Bob{ { ks } dA } eB
20
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
21
Man-in-the-Middle Attack
Alice CathyI need Bob’s public key
Eve CathyI need Bob’s public key
Eve CathyBob’s pub key eB
AliceBob’s pub key eE Eve
Alice Bob{ ks } eE
Eve Bob{ ks } eB
Eve intercepts request
Eve intercepts message
22
Cryptographic Key Infrastructure
• Goal: bind identity to key• Classical: not possible as all keys are shared
– Use protocols to agree on a shared 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
23
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 = { eA || Alice || T } dC
24
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: VeriSign signs certificate for EBay, EBay signs Alice, now you get Alice’s public key if you trust VeriSign
• Signature chains: friend tells friend
25
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
26
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
27
X.509 Validation and Cross-Certifying
• Certificates:– Cathy<<Alice>>– Dan<<Bob>– Cathy<<Dan>>– Dan<<Cathy>>
• Alice validates Bob’s certificate– Alice obtains Cathy<<Dan>>– Alice uses (known) public key of Cathy to validate
Cathy<<Dan>>– Alice uses Dan’s public key to validate Dan<<Bob>>
28
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!)
29
Validating Certificates
• Alice needs to validate Bob’s certificate– Alice does not know Fred,
Giselle, or Ellen
• Alice gets Giselle’s cert– Knows Henry slightly, but
his signature is at “casual” level of trust
• Alice gets Ellen’s cert– Knows Jack, so uses his
cert to validate Ellen’s, then hers to validate Bob’s
Bob
Fred
Giselle
EllenIrene
Henry
Jack
Arrows show signaturesSelf signatures not shown
30
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
31
CRLs
• Certificate revocation list 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
32
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
33
Common Error
• Classical: Alice, Bob share key k– Alice sends m || { m } k to Bob
This is not a digital signature– Why? Third party cannot determine whether
Alice or Bob generated message
34
Public Key Digital Signatures
• Alice’s keys are dAlice, eAlice
• Alice sends Bobm || { m } dAlice
• In case of dispute, judge computes{ { m } dAlice } eAlice
• and if it is m, Alice signed the message– She’s the only one who knows dAlice!
35
RSA Digital Signatures
• Use private key to encipher message
• 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
36
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