key management and identity cs461/ece422 spring 2012
TRANSCRIPT
![Page 1: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/1.jpg)
Key Management and Identity
CS461/ECE422Spring 2012
![Page 2: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/2.jpg)
Reading Material
• Chapters 2 and 23 from text• Handbook of Applied Cryptography– http://www.cacr.math.uwaterloo.ca/hac/– Chapter 5 for information on Pseudorandom
sequences– Chapter 12 for Needham-Schroeder protocol
• The Gnu Privacy Handbook– http://www.gnupg.org/gph/en/manual.html
![Page 3: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/3.jpg)
Overview
• Digital Signatures• Key Exchange• Key/Identity Management– Kerberos– PKI• Hierarchical – X.509• Web of Trust
![Page 4: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/4.jpg)
Digital Signatures
• Alice wants Bob to know that she sent message, m– Sends digital signature along with message– m || {h(m)}eA
• How would Bob verify signature?• Could Eve intercept and change message?• How does Bob know that Alice is the sender?
![Page 5: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/5.jpg)
5
Session and Interchange Keys
• Long lived Interchange Keys only exist to boot strap• Short lived session keys used for bulk encryption
Kb,KaKa,Kb
{Ka,b}Ka{m1}Ka,b
Ka,bKa,b
![Page 6: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/6.jpg)
6
Picking Good Session Keys
• Goal: generate keys that are difficult to guess• Problem statement: given a set of K potential keys,
choose one randomly– Equivalent to selecting a random number between 0 and K–
1 inclusive– Uniform distribution – Use entire space– Independence – Should not be able to predict next selection
• Why is this hard: generating random numbers– Actually, numbers are usually pseudo-random, that is,
generated by an algorithm
![Page 7: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/7.jpg)
7
What is “Random”?
• Sequence of cryptographically random numbers: a sequence of numbers n1, n2, … such that for any integer k > 0, an observer cannot predict nk even if all of n1, …, nk–1 are known– Best: physical source of randomness
• Random pulses• Electromagnetic phenomena• Characteristics of computing environment such as disk latency• Ambient background noise
![Page 8: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/8.jpg)
8
What is “Pseudorandom”?
• Sequence of cryptographically pseudorandom numbers: sequence of numbers intended to simulate a sequence of cryptographically random numbers but generated by an algorithm– Very difficult to do this well
• Linear congruential generators [nk = (ank–1 + b) mod n] broken
• Polynomial congruential generators [nk = (ajnk–1j + … + a1nk–1 a0)
mod n] broken too• Here, “broken” means next number in sequence can be
determined
![Page 9: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/9.jpg)
9
Best Pseudorandom Numbers
• Strong mixing function: function of 2 or more inputs with each bit of output depending on some nonlinear function of all input bits– Examples: DES, MD5, SHA-1, avalanche effect– Use on UNIX-based systems:
(date; ps gaux) | md5
where “ps gaux” lists all information about all processes on system
![Page 10: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/10.jpg)
10
Separate Channel
• Ideally you have separate secure channel for exchanging Interchange keys– Direct secret sharing grows at N2
Telephone, separate data network, ESP, sneaker net
Regular data network
![Page 11: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/11.jpg)
11
Shared Channel: Trusted Third Party
• Generally separate channel is not practical– No trustworthy separate channel– Want to scale linearly with additional users
Regular data network
Key Exchange
KA,KB, … KZ
KA
KB
![Page 12: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/12.jpg)
12
Classical Key Exchange
• Bootstrap problem: how do Alice, Bob begin?– Alice can’t send it to Bob in the clear!
• Assume trusted third party, Cathy– Alice and Cathy share secret key kA
– Bob and Cathy share secret key kB
• Use this to exchange shared key ks
![Page 13: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/13.jpg)
13
Simple Protocol
Alice Cathy{ request for session key to Bob } kA
Alice Cathy{ ks } kA || { ks } kB
Alice Bob{ ks } kB
Eve Bob{ ks } kB
![Page 14: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/14.jpg)
14
Problems
• How does Bob know he is talking to Alice?– Replay attack: Eve records message from Alice
to Bob, later replays it; Bob may think he’s talking to Alice, but he isn’t
– Session key reuse: Eve replays message from Alice to Bob, so Bob re-uses session key
• Protocols must provide authentication and defense against replay
![Page 15: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/15.jpg)
Needham-Schroeder
Alice CathyAlice||Bob||R1
Alice Cathy{Alice||Bob||r1||ks {Alice|| ks} kB} kA
Alice Bob{Alice|| ks} kB
BobAlice{r2}ks
BobAlice{r2-1}ks
![Page 16: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/16.jpg)
16
Argument: Alice talking to Bob
• Second message– Encrypted using key only she, Cathy knows
• So Cathy encrypted it
– Response to first message• As r1 in it matches r1 in first message
• Third message– Alice knows only Bob can read it
• As only Bob can derive session key from message
– Any messages encrypted with that key are from Bob
![Page 17: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/17.jpg)
17
Argument: Bob talking to Alice
• Third message– Encrypted using key only he, Cathy know
• So Cathy encrypted it
– Names Alice, session key• Cathy provided session key, says Alice is other party
• Fourth message– Uses session key to determine if it is replay from Eve
• If not, Alice will respond correctly in fifth message• If so, Eve can’t decrypt r2 and so can’t respond, or responds
incorrectly
![Page 18: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/18.jpg)
Kerberos
![Page 19: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/19.jpg)
19
Kerberos
• Authentication system– Based on Needham-Schroeder with Denning-Sacco modification– Central server plays role of trusted third party (“Cathy”)
• Ticket– Issuer vouches for identity of requester of service
• Authenticator– Identifies sender
• Two Competing Versions: 4 and 5– Version 4 discussed here
![Page 20: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/20.jpg)
20
Idea
• User u authenticates to Kerberos AS– Obtains ticket (TGT) Tu,TGS for ticket granting service
(TGS)
• User u wants to use service s:– User sends authenticator Au, ticket Tu,TGS to TGS asking
for ticket for service– TGS sends ticket Tu,s to user
– User sends Au, Tu,s to server as request to use s
• Details follow
![Page 21: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/21.jpg)
Public Key: key exchange
• Bob picks session key, ksession
• Encrypts it with Alice’s public key eA
• Sends to Alice• Problems?
{ksession}eA
![Page 22: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/22.jpg)
28
Problem and Solution
• Vulnerable to forgery or replay– Because eA known to anyone, Alice has no assurance
that Bob sent message
• Simple fix uses Bob’s private key– ks is desired session key
– Are we ok now?
{{ksession}dB}eA
{{ksession} eA}dB
![Page 23: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/23.jpg)
29
Notes
• Can include message enciphered with ks
• Assumes Alice has Bob’s public key, and vice versa– If not, each must get it from public server– If keys not bound to identity of owner, attacker Eve can
launch a man-in-the-middle attack (next slide; Cathy is public server providing public keys)
• Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI)
![Page 24: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/24.jpg)
30
Man-in-the-Middle Attack
Alice CathySend Bob’s public key
Eve Cathysend Bob’s public key
Eve CathyeB
AliceeE Eve
Alice Bob{ ks } eE
Eve Bob{ ks } eB
Eve intercepts request
Eve intercepts message
![Page 25: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/25.jpg)
31
Cryptographic Key Infrastructure
• Goal: bind identity to key• Classical: not possible as all keys are shared
– Use protocols to agree on a shared key (see earlier)
• Public key: bind identity to public key– Crucial as people will use key to communicate with
principal whose identity is bound to key– Erroneous binding means no secrecy between
principals– Assume principal identified by an acceptable name
![Page 26: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/26.jpg)
32
Certificates
• Create token (message) containing– Identity of principal (here, Alice)– Corresponding public key– Timestamp (when issued)– Other information (perhaps identity of signer)– Compute hash (message digest) of token
Hash encrypted by trusted authority (here, Cathy) using private key: called a “signature”
CA = eA || Alice || T || {h(eA || Alice || T )} dC
![Page 27: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/27.jpg)
33
X.509 Certificates
• Some certificate components in X.509v3:– Version– Serial number– Signature algorithm identifier: hash algorithm– Issuer’s name; uniquely identifies issuer– Interval of validity– Subject’s name; uniquely identifies subject– Subject’s public key– Signature: encrypted hash
![Page 28: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/28.jpg)
34
Use
• Bob gets Alice’s certificate– If he knows Cathy’s public key, he can validate the certificate
• Decrypt encrypted hash using Cathy’s public key• Re-compute hash from certificate and compare• Check validity• Is the principal Alice?
– Now Bob has Alice’s public key• Problem: Bob needs Cathy’s public key to validate
certificate– That is, secure distribution of public keys– Solution: Public Key Infrastructure (PKI) using trust anchors called
Certificate Authorities (CAs) that issue certificates
![Page 29: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/29.jpg)
PKI Trust Models
• Single Global CA– Unmanageable– Who is the universally
trusted root?
• Hierarchical CA– Tree of CA’s– But still need to be
rooted somewhere
![Page 30: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/30.jpg)
36
PKI Trust Models
• Hierarchical CAs with cross-certification– Multiple root CAs that are cross-certified– Cross-certification at lower levels for efficiency
• Web Model– Browsers come pre-configured with multiple trust
anchor certificates– New certificates can be added
• Distributed (e.g., PGP)– No CA; instead, users certify each other to build a “web
of trust”
![Page 31: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/31.jpg)
37
Validation and Cross-Certifying• Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s
certificate?– Have Cathy and Don cross-certify– Each issues certificate for the other
• 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 Cathy<<Dan>> to validate Dan<<Bob>>
![Page 32: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/32.jpg)
38
PGP Chains
• OpenPGP certificates structured into packets– One public key packet– Zero or more signature packets
• Public key packet:– Version (3 or 4; 3 compatible with all versions of PGP, 4
not compatible with older versions of PGP)– Creation time– Validity period (not present in version 3)– Public key algorithm, associated parameters– Public key
![Page 33: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/33.jpg)
39
OpenPGP Signature Packet
• Version 3 signature packet– Version (3)– Signature type (level of trust)– Creation time (when next fields hashed)– Signer’s key identifier (identifies key to encrypt hash)– Public key algorithm (used to encrypt hash)– Hash algorithm– Part of signed hash (used for quick check)– Signature (encrypted hash)
• Version 4 packet more complex
![Page 34: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/34.jpg)
40
Signing
• Single certificate may have multiple signatures• Notion of “trust” embedded in each signature
– Range from “untrusted” to “ultimate trust”– Signer defines meaning of trust level (no standards!)– Few implementations support this
• All version 4 keys signed by subject– Called “self-signing”
![Page 35: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/35.jpg)
41
Trust in GPG
Owner TrustGPG enables assignment of trust in entity
• Unknown, Not Trusted, Marginal, Full• How much do you trusted signatures by that entity
Key ValidityHow much do you trust that the key corresponds to the
owner?• Unknown, Not trusted, Marginal Full
Configurable• X full paths or Y marginal paths
![Page 36: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/36.jpg)
42
Web of Trust Example
From GPG manual, arrows show key signatures
![Page 37: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/37.jpg)
43
Web of Trust Scenarios
In all cases the key is valid given 1 full or 2 marginal paths. Always fully trust directly signed keys
Fully Trust Dharma Marginally Trust Dharma and Blake Marginally Trust Dharma and Chloe Marginally Trust Dharma, Blake, and Chloe Fully Trust Blake, Chloe, and Elena
![Page 38: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/38.jpg)
44
Key Revocation
• Certificates invalidated before expiration– Usually due to compromised key– May be due to change in circumstance (e.g., someone
leaving company)• Problems
– Verify that entity revoking certificate authorized to do so
– Revocation information circulates to everyone fast enough
• Network delays, infrastructure problems may delay information
![Page 39: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/39.jpg)
45
GPG: Revocation Certificate
Use the –gen-revoke option to create a revocation certification.
When you suspect that your certificate has been compromised
Send revocation certificate to all your friends
Or send the revocation certificate to a GPG key server
![Page 40: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/40.jpg)
46
CRLs
• Certificate revocation list lists certificates that are revoked
• X.509: only certificate issuer can revoke certificate– Added to CRL
![Page 41: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/41.jpg)
Recent Root Certificate Issues
• Vast numbers of Root certifiers in web browsers
• How strenuous is the background check of the certificate providers?
• How strong is the internal security of the certificate providers?
• What goes wrong with bad root certificates appear?
![Page 42: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/42.jpg)
Network Perspectives
• Ask several notifiers throughout the network what they get for the target server’s certificate.
![Page 43: Key Management and Identity CS461/ECE422 Spring 2012](https://reader035.vdocuments.mx/reader035/viewer/2022062517/56649ef45503460f94c076b1/html5/thumbnails/43.jpg)
Summary
• Tracking identity is important – Key negotiation– Digital signatures
• Managing the root of trust is a very hard practical problem