Key distribution

1
Key distribution

• Secret key and public key as well
• Two party, multiple parties
• Key distribution is a big problem with secret-key
  system (and group communication)
• Use public-key system to distribute key (called
  session key) and then use session key for fast
  data transmission.
• (for secure group communication), a center key
  server generates a key and distributes the key to
  group members.

2
(Two-party) Diffie-Hellman (DH) key exchange
Based on DLP problem, Suppose p (prime) and g
(generator of Zp) are publicly known
? g a mod p)
(b ? g b mod p)
(a
g a
Bob
Alice
g b
K(ga) bg ab
K(gb) ag ab
Anyone else can compute g a g b g ab but
not g ab
How beautiful it is!!!
a and b are called DH private components. g a and
g b are called DH public components.
Could you think any problem with this protocol?
3
The Man-in-the-middle attack
(a, g a)
(c, g c)
(b, g b)
g a
gc
g b
g c
Bob
Alice
Oscar
K(gc)agac
K(ga)cgac
K(gb)cgbc
K(gc)bgbc
The ways to defend against the man-in-the-middle
attack 1. Use permanent DH components, like
RSA permanent keys. 2. Perform authentication.
4
Key management public key certificate

• Key management
• how to securely and reliably distribute the keys
  used (not only secret key, but also public key).
• not to break algorithms used, but to break the
  key distribution scheme
• have a range of possible key distribution
  techniques
• one of the most critical areas in security
  systems
• absolutely critical to get this right

5
Key management schemes

• Physical Delivery
• by secure courier
• registration name and password for computers
• Authentication Key Server
• have an on-line server trusted by all clients
• server has a unique secret key shared with each
  client
• server negotiates keys on behalf of clients
• use secret key encryption system
• e.g. Kerberos (later)

6
Key management schemes

• 3. Public Notary or Certification Authority
• have an off-line server trusted by all clients
• server has a well known public key
• server signs public key certificates for each
  client
• uses public key encryption
• will consider this next

7
Public Key Certificates

• public key management generally involves the use
  of public key certificates
• There is a public, well-known, trusted
  Certification Authority (CA), users know CAs
  public key.
• bind an identity (i.e. a user) to a public key
• usually with other info such as period of
  validity, rights of use etc.
• with all contents signed by the CA, called public
  key certificate (PKC)
• Any other user can use CAs public key to verify
  the certificate, thus make sure that the public
  key is an authentic public key for the user.
• CA not know the private keys of users. However it
  is possible for CA (or government) to generate
  private and public keys for users.

8
X.509 - Directory Authentication Service

• Widely accepted and used international standard
• defines framework for authentication services
• directory may store public-key certificates
• also defines authentication protocols using these
  certificates
• uses public-key cryptography and digital
  signatures
• RSA is the recommended algorithm.

9
X.509 Certificates

• issued by a Certification Authority (CA)
• each certificate contains
• version (1, 2, or 3)
• serial number (unique within CA) identifying
  certificate
• Signature algorithm identifier
• issuer X.500 name (CA)
• period of validity (from - to dates)
• subject X.500 name (name of owner)
• subject public-key info (algorithm, parameters,
  key)
• issuer unique identifier (v2)
• subject unique identifier (v2)
• extension fields (v3)
• signature (of hash of all fields in certificate)

10
Certificate Properties

• any user with access to CA can get any
  certificate from it
• only the CA can modify a certificate
• because they cannot be forged, certificates can
  be placed in a public directory

11
CA Hierarchy

• if both users share a common CA then they are
  assumed to know CAs public key
• otherwise CAs must form a hierarchy
• use certificates linking members of hierarchy to
  validate other CAs
• each CA has certificates for clients (forward)
  and parent (backward)
• each client trusts parent certificates
• enable verification of any certificate from one
  CA by use of all other CAs in hierarchy

12
CA Hierarchy --example

• A acquires B certificate following chain
• XltltWgtgtWltltVgtgtVltltYgtgtYltltZgtgtZltltBgtgt
• B acquires A certificate following chain
• ZltltYgtgtYltltVgtgtVltltWgtgtWltltXgtgtXltltAgtgt
• Notation CAltltUsergtgt means CA has signed
  certificate details for User