lecture 3: cryptography support services: key management anish arora cse5473 introduction to network...
TRANSCRIPT
![Page 1: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/1.jpg)
Lecture 3: Cryptography Support Services: Key Management
Anish Arora
CSE5473
Introduction to Network Security
![Page 2: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/2.jpg)
Outline
A. Distribution via symmetric keys
B. Distribution via public keysI. of public keys
II. of session keys
C. Group Key Management
![Page 3: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/3.jpg)
A. Key distribution assuming symmetric keys
• how to securely distribute this key is an issue
• often security failure is due to a break in key distribution scheme
• given parties A and B have various key distribution alternatives:
1. A can select key and physically deliver to B
2. third party can select & deliver key to A & B
3. if A & B have communicated previously can use previous key to
encrypt a new key
4. if A & B have secure communications with a third party C, C can
relay key between A & B
![Page 4: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/4.jpg)
A key distribution protocol
![Page 5: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/5.jpg)
Another protocol (for connection-oriented networks)
![Page 6: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/6.jpg)
A decentralized key distribution protocol
Assume a master key is known to principals j and k :
j k : request, n
k j : Smaster ‹ S , request , k , n+1 , m ›
j k : S ‹m+1›
![Page 7: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/7.jpg)
Merkle’s puzzles
• Each puzzle requires O(n) work
• Alice sends O(n) puzzles to Bob, puzzle=EP(“message”)
• Bob chooses one, and spends O(n) effort to break it and get key
• Bob communicates choice index (which was encrypted by Alice) to Alice
• Eve has to perform O(n2) work to guess the key
![Page 8: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/8.jpg)
More on Merkle’s Puzzle
Alice: for i=1, …, 232 choose random Pi ∈{0,1}32 ; xi,ki∈{0,1}128
set puzzlei ⟵ E096 ll Pi (“Puzzle # xi” ll ki)
Send puzzle1 , … , puzzle232 to Bob
Bob: choose a random puzzlej and solve it. Obtain (xj, kj ) .
Send xj to Alice
Alice: lookup puzzle with number xj, use kj as shared secret
[Dan Boneh]
![Page 9: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/9.jpg)
B. Public key management
• public-key encryption helps address key distribution problems
• two aspects:
I. distribution of public keys
II. use of public-key encryption to distribute secret keys
![Page 10: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/10.jpg)
I. Distribution of public keys
• via one of:
public announcement
publicly available directory
public-key authority
public-key certificates
![Page 11: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/11.jpg)
Public announcement
• users distribute public keys to recipients or broadcast to
community at large
e.g. 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
masquerade as claimed user until forgery is discovered
![Page 12: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/12.jpg)
Publicly available directory
• users obtain greater security by registering keys with a public directory
• directory must be trusted, and with these 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, if channel or access to directory is vulnerable
![Page 13: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/13.jpg)
Public-key authority
• improves security by tightening control over distribution of keys from directory
• has same properties as 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
![Page 14: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/14.jpg)
Deriving a protocol for authority based distribution
Consider the basic protocol:
j k : B.j
k j : B.k
j k : B.k ‹m›
k j : B.j ‹m’›
Subject to man-in-the-middle attack
![Page 15: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/15.jpg)
Man-in-the-middle attack
Recall the attack
j k : B.j intercepted by Mal
Mal k : B.Mal
k j : B.k intercepted by Mal
Mal j : B.Mal
j k : B.Mal ‹m›
“Mallory”-in-the-middle can now passively receive the messages sent by j to k and vice versa
To foil attack: get Trent to sign & send public keys of one to other
![Page 16: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/16.jpg)
Foiling the attack: use signatures
One solution: get Trent to sign and send public keys of the
one to the other
T k : R.T ‹ B.j ›
T j : R.T ‹ B.k ›
But freshness of exchange remains an issue:
how to tolerate replay attacks
![Page 17: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/17.jpg)
Public-key authority
![Page 18: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/18.jpg)
Public-key certificates
• certificates allow key exchange without real-time access to public-key authority
• users contact authority only on behalf of self as opposed to others
• a certificate binds identity to public key usually with other info such as period of validity
with all contents signed by a trusted Public-Key or Certificate Authority (CA)
• certificates can be verified by anyone who knows the public-key authorities public-key
![Page 19: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/19.jpg)
Public-key certificates
![Page 20: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/20.jpg)
Light-weight public key certificates
![Page 21: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/21.jpg)
CA structures
• One universally trusted authority issues: monopoly pricing, risk of all eggs in one basket, cost of getting
certificate in first place could have local registration authorities (RAs) to simplify getting
certificate initially could replace one with many (monopoly -> oligarchy; as in trusted
roots of IE) but less secure, since one “weak” CA compromises all
• Top-down hierarchy, starting from universally trusted authority
certificate chains, a CA certifies a public key to below to subordinate CA need to verify multiple certificates at user end but don’t have to go to original CA to get certificate in first place
![Page 22: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/22.jpg)
Organizing CAs
alternatively, assume name subordination: each CA only responsible for its name subspace more secure in practice
bottom-up version (as opposed to building trust from the top-down): extend to traverse up and down intranet namespace hierarchy & across
extranet namespaces security within organization (intranet) is controlled by organization easy configuration: start with own public key
• Many independent CAs: configure which ones to trust issue: anarchy doesn’t scale either
• X.509 is an IEEE standard for certificate syntax, PKIX is an extension to this standard, SPKI is a competing IETF standard
![Page 23: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/23.jpg)
Revoking certificates
• If certificate compromised, notify CA and ask for a new certificate
• How to revoke certificate: Supplement certificate lifetimes with certificate revocation lists (CRLs) or a black list server (OLRS)
• These can be maintained on-line
![Page 24: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/24.jpg)
II. Public-key distribution of secret keys
• use previous methods to obtain public-key
• then use public-key for secrecy or authentication is slow
• so use private-key encryption to protect message contents
• hence need a session key
• have several alternatives for negotiating a suitable session
![Page 25: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/25.jpg)
Simple secret key distribution
• proposed by Merkle in 1979
j generates a new temporary public key pair
j sends k the public key and its identity
k generates a session key S & sends it to j encrypted using the
supplied public key
j decrypts the session key and both use the key
j k : B.j
k j : B.j ‹ S ›
![Page 26: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/26.jpg)
Man-in-the-middle attack
Here’s one attack:
j k : B.j intercepted by Mal
Mal j : B.j ‹S›
Mal k : B.Mal
k j : B.Mal ‹S’› intercepted by Mal
j k : S‹m› intercepted by Mal
Mal k : S’‹m›
“Mallory”-in-the-middle can now actively receive the messages sent by j to k and vice versa
![Page 27: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/27.jpg)
Foiling the attack: use signatures
One solution: get Trent to sign and send public keys of the one to
the other
T k : R.T ‹ B.j ›
T j : R.T ‹ B.k ›
j k : R.j ‹ S.jk ‹m›, B.k ‹S.jk› ›
But freshness of exchange remains an issue !
![Page 28: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/28.jpg)
Foiling replay attacks: use nonce exchange
• To deal with freshness, assuming securely exchanged public-keys:
![Page 29: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/29.jpg)
Diffie-Hellman key exchange
• first public-key scheme proposed
• by Diffie & Hellman in 1976, along with exposition of public key concepts
• is a practical method for public exchange of a secret key as opposed to secure communication of messages
• used in a number of commercial products
![Page 30: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/30.jpg)
Diffie-Hellman key exchange
• shared session key for users A & B is KAB:
KAB = αxA.xB mod q
= yA
xB mod q (which B can compute)
= yB
xA mod q (which A can compute)
• KAB is used as session key in private-key encryption scheme between Alice and Bob
• if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys
• attacker needs an x, must solve discrete log
![Page 31: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/31.jpg)
Diffie-Hellman key exchange
• value of key depends on the participants (and their private and public key information)
• based on exponentiation in a finite (Galois) field (modulo a prime or a polynomial) – easy
• security relies on the difficulty of computing discrete logarithms (similar to factoring) – hard i.e., given α, q, y = α
x mod q computing x is hard
discrete log computation takes more time than factoring a
composite of magnitude of q
![Page 32: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/32.jpg)
Diffie-Hellman setup
• all users agree on global parameters: large prime q α a primitive root mod q
powers of α generate all numbers 1..q-1
• each user (e.g. A) generates their key chooses a secret key (number): xA < q
Computes its public key: yA = αxA mod q
• each user makes public that key yA
![Page 33: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/33.jpg)
Diffie-Hellman example
Users Alice & Bob who wish to swap keys:
• agree on prime q=353 and α=3
• select random secret keys: A chooses xA=97, B chooses xB=233
• compute public keys: yA=3
97 mod 353 = 40 (Alice)
yB=3233 mod 353 = 248 (Bob)
• compute shared session key as:
KAB= yB
xA mod 353 = 24897 = 160 (Alice)
KAB= yA
xB mod 353 = 40233 = 160 (Bob)
![Page 34: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/34.jpg)
Man-in-the-Middle attack for D-H
• Mallory intercepts exchange with Alice and sets up key with her, likewise sets up key with Bob
traps all exchanges of data and faithfully forwards after decrypting with one key and then re-encrpyting with other key
can now actively enable communications between Alice and Bob
j k : αxj mod q intercepted by Mal
Mal j : αxMal mod q
Mal k : αxMal mod q
k j : αxk mod q intercepted by Mal
j k : α xj
xMal mod q ‹m› intercepted by Mal
Mal k : α xk
xMal mod q ‹m›
![Page 35: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/35.jpg)
Dealing with Man-in-the-Middle attack for D-H
• Avoided by sending messages not in the clear, but encrypted: with private keys with public keys and signed (in reverse order) by only one side
• But if private keys already exist, then why have D-H to begin with? “Forward secrecy”: if former private key compromised, latter
keys not deducible
![Page 36: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/36.jpg)
Denial-of-Service protection for D-H
• Mallory may send too many request for key exchanges to Bob
• To avoid this, add a preliminary message Bob first sends a cookie Alice’s response includes her public key and the cookie Bob verifies cookie before sending his public key in response
![Page 37: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/37.jpg)
Key distribution systems issues
• hierarchies of KDC’s required for large networks, but must trust each other
• session key lifetimes should be limited for greater security
• use of automatic key distribution on behalf of users, but must trust system
• controlling purposes keys are used for
![Page 38: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/38.jpg)
C. Group Key Management
A. Distribution via symmetric keys
B. Distribution via public keysI. of public keys
II. of session keys
C. Distribution via “group” keyI. The key-tree approach
II. The grid approach (for sensor networks)
![Page 39: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/39.jpg)
The Key Tree Approach (Wong, Gouda, Lam)
• Keys represented as nodes Group key is the root Auxiliary keys are internal nodes Individual keys are leaves
• Member u holds all keys in ancestor nodes Example: u1 holds keys k1 and kG
kG
k1
u2u1 u3
k2
u5u4 u6
k3
u8u7 u9
![Page 40: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/40.jpg)
Scalability of Key Trees
• Reduces DELETE(u) communication costs from O(n) to O(log n)
• Example: DELETE(u9)
Must change 2 shared keys: kG and k3
Keys are changed bottom up in the tree
Change k3 with 2 messages: E(k’3,u7), E(k’3,u8)kG
k1
u2u1 u3
k2
u5u4 u6
k3
u8u7 u9
![Page 41: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/41.jpg)
Scalability of Key Trees
• Change kG with 3 messages:
E(k’G,k1), E(k’G,k2), E(k’G,k’3)
kG
k1
u2u1 u3
k2
u5u4 u6
k’3
u8u7
u9
![Page 42: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/42.jpg)
User-Oriented Rekeying
• Encryption Cost Join: 1 + 2 + … + h-1 + h-1 Leave: (d-1)(1+2+…+h-1)
• Rekey Messages Join: h Leave: (d-1)(h-1)
k9
u9
• Join rekey messages • Leave rekey messages
![Page 43: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/43.jpg)
Key-Oriented Rekeying
• Encryption Cost Join: 2(h-1) Leave: d(h-1)
• Rekey Messages Join: 2(h-1) Leave: (d-1)(h-1)
k9
u9
• Join rekey messages • Leave rekey messages
![Page 44: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/44.jpg)
Group-Oriented Rekeying
k9
u9
Two rekey messages for join:
Encryption cost : 2(h-1)
Leave Operation:
Encryption cost: d(h-1)
Rekey messages: 1
![Page 45: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/45.jpg)
Grid Protocol (Kulkarni, Gouda, Arora)
• Arrange the secrets in a grid
• Each user is also assigned to some location in the grid
• Each user gets secrets in its row and in its column
= user + secret
![Page 46: Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security](https://reader035.vdocuments.us/reader035/viewer/2022062516/56649e545503460f94b4a7f4/html5/thumbnails/46.jpg)
Grid Protocol (Continued)
= user + secret= communicating users= secrets used
When two users in different rows and different columns communicate
• Consider the rectangle formed by those two users
• Choose secrets at the other two corners of the rectangle
When users is same row (or column) communicate
• Maintain a secret that is shared between only those two users