Lecture 3: Cryptography Support Services:
Key Management
Anish Arora
CSE5473
Introduction to Network Security
Outline
A.
Distribution via symmetric keys
B.
Distribution via public keys
C.
I.
of public keys
II.
of session keys
Group Key Management
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
A key distribution protocol
Another protocol (for connection-oriented networks)
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›
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
More on Merkle’s Puzzle
Alice: for i=1, …, 232 choose random Pi ∈{0,1}32 ; xi,ki∈{0,1}128
set
 Send
puzzlei
⟵
E096 ll Pi (“Puzzle # xi” ll
puzzle1 , … , puzzle232
ki )
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]
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
I. Distribution of public keys
•
via one of:
 public announcement
 publicly available directory
 public-key authority
 public-key certificates
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
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
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
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
Man-in-the-middle attack
Recall the attack
jk:
B.j
Mal  k :
B.Mal
kj :
B.k
Mal  j :
B.Mal
j k:
B.Mal ‹m›
intercepted by Mal
intercepted by Mal
“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
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
Public-key authority
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
Public-key certificates
Light-weight public key certificates
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
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
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
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
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 ›
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
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 !
Foiling replay attacks: use nonce exchange
•
To deal with freshness, assuming securely exchanged
public-keys:
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
Diffie-Hellman key exchange
•
shared session key for users A & B is KAB:
x
x
KAB = α A. B mod q
x
= yA B mod q (which B can compute)
x
= yB A 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
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
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
each user makes public that key yA
mod q
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:
97

yA=3

yB=3
233
(Alice)
mod 353 = 40
mod 353 = 248
(Bob)
compute shared session key as:
xA
mod 353 = 248
xB
mod 353 = 40
KAB= yB
KAB= yA
97
233
= 160
(Alice)
= 160
(Bob)
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
xj
jk:
α
Mal  j :
α
Mal  k :
α
kj :
α
j k:
α
xj xMal
mod q ‹m›
Mal  k :
α
xk xMal
mod q ‹m›
mod q
xMal
mod q
xMal
mod q
xk
mod q
intercepted by Mal
intercepted by Mal
intercepted by Mal
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
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
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
C. Group Key Management
A.
Distribution via symmetric keys
B.
Distribution via public keys
C.
I.
of public keys
II.
of session keys
Distribution via “group” key
I.
The key-tree approach
II.
The grid approach (for sensor networks)
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
u1
u2
k2
u3
u4
u5
k3
u6
u7
u8
u9
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
u1
u2
k2
u3
u4
u5
k3
u6
u7
u8
u9
Scalability of Key Trees
•
Change kG with 3 messages:
E(k’G,k1), E(k’G,k2), E(k’G,k’3)
kG
k1
u1
u2
k’3
k2
u3
u4
u5
u6
u7
u8
u9
User-Oriented Rekeying
Encryption Cost
•
 Join: 1 + 2 + … + h-1 + h-1
 Leave: (d-1)(1+2+…+h-1)
k9
Rekey Messages
•
 Join: h
u9
•
Join rekey messages
 Leave: (d-1)(h-1)
•
Leave rekey messages
Key-Oriented Rekeying
•
Encryption Cost
 Join: 2(h-1)
 Leave: d(h-1)
k9
•
 Join: 2(h-1)
 Leave: (d-1)(h-1)
u9
•
Join rekey messages
Rekey Messages
•
Leave rekey messages
Group-Oriented Rekeying

k9
Two rekey messages for join:

Encryption cost : 2(h-1)
u9

Leave Operation:

Encryption cost: d(h-1)

Rekey messages: 1
Grid Protocol (Kulkarni, Gouda, Arora)
•
•
•
= user + secret
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
Grid Protocol (Continued)
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
= user + secret
= communicating users
= secrets used
• Maintain a secret that is shared
between only those two users