Lecture 3: Cryptography Support Services: Key Management

1
Lecture 3 Cryptography Support Services Key
Management

• Anish Arora
• CSE5473
• Introduction to Network Security

2
Outline

• Distribution via symmetric keys
• Distribution via public keys
• of public keys
• of session keys
• Group Key Management

3
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
• A can select key and physically deliver to B
• third party can select deliver key to A B
• if A B have communicated previously can use
  previous key to encrypt a new key
• if A B have secure communications with a third
  party C, C can relay key between A B

4
A key distribution protocol
5
Another protocol (for connection-oriented
networks)
6
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 , n1 , m
• j ? k S m1

7
Merkles puzzles

• Each puzzle requires O(n) work
• Alice sends O(n) puzzles to Bob,
  puzzleEP(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

8
More on Merkles Puzzle

• Alice for i1, , 232 choose random Pi
  ?0,132 xi,ki?0,1128
• 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

9
B. Public key management

• public-key encryption helps address key
  distribution problems
• two aspects
• distribution of public keys
• use of public-key encryption to distribute secret
  keys

10
I. Distribution of public keys

• via one of
• public announcement
• publicly available directory
• public-key authority
• public-key certificates

11
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

12
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

13
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

14
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
15
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
16
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
17
Public-key authority
18
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

19
Public-key certificates
20
Light-weight public key certificates
21
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 -gt
  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 dont have to go to original CA to get
  certificate in first place

22
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 doesnt scale either
• X.509 is an IEEE standard for certificate syntax,
  PKIX is an extension to this standard, SPKI is a
  competing IETF standard

23
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

24
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

25
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

26
Man-in-the-middle attack
Heres 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 Sm intercepted by Mal Mal ? k
Sm Mallory-in-the-middle can now actively
receive the messages sent by j to k and vice versa
27
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 !
28
Foiling replay attacks use nonce exchange

• To deal with freshness, assuming securely
  exchanged public-keys

29
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

30
Diffie-Hellman key exchange

• shared session key for users A B is KAB
• KAB axA.xB mod q
• yAxB mod q (which B can compute)
• yBxA 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

31
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 a, q, y ax mod q computing x is
  hard
• discrete log computation takes more time than
  factoring a composite of magnitude of q

32
Diffie-Hellman setup

• all users agree on global parameters
• large prime q
• a a primitive root mod q
• powers of a generate all numbers 1..q-1
• each user (e.g. A) generates their key
• chooses a secret key (number) xA lt q
• Computes its public key yA axA mod q
• each user makes public that key yA

33
Diffie-Hellman example

• Users Alice Bob who wish to swap keys
• agree on prime q353 and a3
• select random secret keys
• A chooses xA97, B chooses xB233
• compute public keys
• yA397 mod 353 40 (Alice)
• yB3233 mod 353 248 (Bob)
• compute shared session key as
• KAB yBxA mod 353 24897 160 (Alice)
• KAB yAxB mod 353 40233 160 (Bob)

34
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 axj mod q intercepted by Mal
• Mal ? j axMal mod q
• Mal ? k axMal mod q
• k ? j axk mod q intercepted by Mal
• j ? k a xj xMal mod q m intercepted by Mal
• Mal ? k a xk xMal mod q m

35
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

36
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
• Alices response includes her public key and the
  cookie
• Bob verifies cookie before sending his public key
  in response

37
Key distribution systems issues

• hierarchies of KDCs 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

38
C. Group Key Management

• Distribution via symmetric keys
• Distribution via public keys
• of public keys
• of session keys
• Distribution via group key
• The key-tree approach
• The grid approach (for sensor networks)

39
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

40
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(k3,u7), E(k3,u8)

kG
k1
k2
k3
u2
u1
u3
u5
u4
u6
u8
u7
u9
41
Scalability of Key Trees

• Change kG with 3 messages E(kG,k1), E(kG,k2),
  E(kG,k3)

kG
k1
k2
k3
u9
u2
u1
u3
u5
u4
u6
u8
u7
42
User-Oriented Rekeying

• Encryption Cost
• Join 1 2 h-1 h-1
• Leave (d-1)(12h-1)
• Rekey Messages
• Join h
• Leave (d-1)(h-1)

• Join rekey messages

• Leave rekey messages

43
Key-Oriented Rekeying

• Encryption Cost
• Join 2(h-1)
• Leave d(h-1)
• Rekey Messages
• Join 2(h-1)
• Leave (d-1)(h-1)

• Leave rekey messages

• Join rekey messages

44
Group-Oriented Rekeying

• Two rekey messages for join

• Encryption cost 2(h-1)

• Leave Operation
• Encryption cost d(h-1)
• Rekey messages 1

45
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

46
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
• Maintain a secret that is shared between only
  those two users

user secret