Key Management and Distribution

Class 5

Stallings: Ch 14

CIS-5373: 10.February.2020 1
 Announcement

 Homework 1 due today

 Still waiting for paper assignments

CIS-5373: 10.February.2020 2
 Key Distribution: The Problem

C= Encrypt(pubKeyB, M)

Alice
2
Has message M Bob
Intercept C
pubKeyB - public
privKeyB - private
Cannot Infer privKeyB
from pubKeyB ! M= Decrypt(privKeyB, C)

Malory Cannot Obtain M !

CIS-5373: 10.February.2020 3
 Key Distribution: Symmetric Key Scenario

 Deliver a key to two parties that need to

communicate securely
 Delivery needs to be secure: only the two
parties have access to the key

CIS-5373: 10.February.2020 4
 Symmetric Key Scenario

 Two parties A and B

 Symmetric encryption: most efficient way to send
encrypted data
 Both parties need to share a secret
 For N parties, this means N(N-1)/2 secrets !
 Not all are needed

 How to securely and efficiently establish pairwise

secrets

CIS-5373: 10.February.2020 5
 How To Distribute Keys

 Session key distribution with symmetric crypto

 Session key distribution with public key crypto
 Distribution of authentic public keys
 X.509 certificates

CIS-5373: 10.February.2020 6
 Symmetric Crypto Notations

 Alice shares key KA with KDC

 Encryption: EA(M) = E(KA, M) = C
 Decryption: DA(M) = D(KA, C)

CIS-5373: 10.February.2020 7
 Symmetric Key Based Distribution
A and B share secret key A: KA
with KDC ! B: KB
1

“Hi”, A, B
Trent T
2
(KDC)
EA(KAB), EB(KAB)

EB(KAB)
6

EAB(M)
Alice A
3 5
Bob B
DA(EA(KAB)) =KAB DB(EB(KAB)) = KAB

CIS-5373: 10.February.2020 8
 Key Distribution Problems

 Trent (the KDC) is absolutely trusted

 If Malory corrupts KDC, all is gone
 Malory can read all user communication
 Why ?
 Trent is a bottleneck
 If Trent fails, the entire system is disrupted

CIS-5373: 10.February.2020 9
 How To Distribute Keys

 Session key distribution with symmetric crypto

 Session key distribution with public key crypto
 Distribution of authentic public keys
 X.509 certificates

CIS-5373: 10.February.2020 10
 Public Key Based Distribution

 A and B use public key crypto

 To agree on a session key
 Session key is used to encrypt communications
 How do A and B know each other’s public keys?

CIS-5373: 10.February.2020 11
 Public Key Crypto Notations

 Alice has key pair (pkA, prA)

 pkA is the public key
 prA is the private key
 Encryption/Decryption
 C = EA(Msg) = E(pkA, Msg) – anyone can do
 DA(C) = D(prA, C) – only Alice can do this

CIS-5373: 10.February.2020 12
 KD with Public Key – Direct Exchange

Merkle proposed this very simple scheme

Hi, A, pkA
2

E(pkA, KAB)
3
Alice A EAB(M)
Bob B

CIS-5373: 10.February.2020 13
 Man-in-the-Middle Attack

Hi, A, pkA

Alice A Bob B
2
Intercept/Block
5

E(pkA, KAM) 3

“Hi”, A, pkM
6’
EAM(Msg’) 4

E(pkM, KBM)
6
From then on EBM(Msg)
Bob talks to Malory
Malory M
thinking it is Alice !

CIS-5373: 10.February.2020 14
 Key Distribution with Public Key and KDC

A: pkA
B: pkB
1

“Hi”, A, B Do you see the problem ?

Trent T
2
(KDC)
B, pkB

E(pkB, KAB)
6

EAB(M)
Alice A
3
5
Bob B
Generate session D(prB, E(pkB, KAB)) = KAB
key KAB

CIS-5373: 10.February.2020 15
 How To Distribute Keys

 Session key distribution with symmetric crypto

 Session key distribution with public key crypto
 Distribution of authentic public keys
 X.509 certificates

CIS-5373: 10.February.2020 16
 Distribution of Public Keys !

 How are they distributed in the first place ?

 Remember Merkle’s solution
 … and the Man-in-the-Middle Attack
 Need an authentic way to distribute keys !
 Alternatives
 Public announcement
 Publicly available directory
 Public-key authority
 Public-key certificates

CIS-5373: 10.February.2020 17
 Public Announcement

 Similar to Merkle’s first step …

 Users distribute public keys to recipients or
broadcast to community at large
 Append keys to email messages
 Post to news groups or email list
 Major weakness is man-in-the-middle
 Anyone can create a key claiming to be someone else and
broadcast it
 Until forgery is discovered can masquerade as claimed
user

CIS-5373: 10.February.2020 18
 Publicly Available Directory

 Register keys with a public directory

 Directory contains {name,public-key} entries
 Participants register securely with directory
 In person or using secure authentication
 Participants can replace key at any time
 Directory can be accessed electronically
 Needs secure, authentic communication to directory
 Vulnerable to tampering or forgery

CIS-5373: 10.February.2020 19
 Public Key Authority

 Has properties of directory plus

 Requires users to know public key of authority
 Users interact with directory to obtain any desired
public key securely
 Requires real-time access to directory when keys are
needed
 May be vulnerable to tampering

CIS-5373: 10.February.2020 20
 Public Key Crypto Notations
 Alice has key pair (pkA, prA)
 pkA is the public key
 prA is the private key
 Encryption/Decryption
 EA(M) = E(pkA,M) – anyone can do this
 DA(M) = D(prA,M) – only Alice can do this
 Signature/Verification
 SA(M) : sign message M with private key of A
 VA(M, S) : verify that S is a signature for M
 Uses A’s public key

CIS-5373: 10.February.2020 21
 Public Key Authority (Needham-Schroeder
with Public Keys)
T1 is timestamp A: pkA
prevents replay
attacks ! B: pkB
5
ST(A, pkA ,T2)
1

Req, B, T1 4

Trent T Req, A, T2
2 (KDC)
ST(B, pkB ,T1)
== ?

EB(A, NA)
6

EA(NA, NB)
7
Alice A Bob B
EB(NB)
== ?

CIS-5373: 10.February.2020 22
 Public Key Authority Use (cont’d)

 Why do we need T’s signature ?

 A and B can be sure of the other’s public key
 Why do we need steps 6 and 7 ?
 A makes sure B knows its private key
 Makes sure Mallory cannot impersonate B
 … and vice-versa

CIS-5373: 10.February.2020 23
 How To Distribute Keys

 Session key distribution with symmetric crypto

 Session key distribution with public key crypto
 Distribution of authentic public keys
 X.509 certificates

CIS-5373: 10.February.2020 24
 Public Key Certificates

 Allow key exchange without real-time access to

public-key authority
 Bind identity to public key
 Plus other info: period of validity, rights of use etc
 All contents signed by a trusted Public-Key or
Certificate Authority (CA)
 Can be verified by anyone who knows the public-key
authority’s public-key

CIS-5373: 10.February.2020 25
 Certificate Requirements

 Anyone can read the name and public key from a

certificate
 Only the CA can create and update certificates
 Anyone can verify the validity of the certificate

CIS-5373: 10.February.2020 26
 How are Certificates Used ?

Using authenticated
channel !
2’
C(B)=ST(B,pkB,T2)
1

Req, pkA 1’

Trent T Req, pkB

2 (CA)
C(A)=ST(A,pkA,T1)

C(A)
4
C(B)

Alice A Bob B

CIS-5373: 10.February.2020 27
 How are Certificates Used ? (cont’d)

 Certificates issued
 Over authenticated channels
 In person
 Certificates are re-issued infrequently
 Steps 1 and 2 are done once
 Certificates contain timestamp and validity period
 User can verify certificate validity
 Example CAs: Symantec (VeriSign), Comodo, GoDaddy

CIS-5373: 10.February.2020 28
 Symantec (former VeriSign)

 For websites
 Examines
 Traditional documents like articles of incorporation and
business licenses
 Digital verification of each site operated by the
organization

CIS-5373: 10.February.2020 29
 WebTrust https://cert.webtrust.org

CIS-5373: 10.February.2020 30
 X.509 Certificates

 Part of CCITT X.500 directory service standards

 Distributed servers maintaining user info database
 Defines framework for authentication services
 Directory may store public-key certificates
 Public key of user signed by certification authority
 Defines authentication protocols
 Uses public-key crypto & digital signatures
 Algorithms not standardised, but RSA recommended
 X.509 certificates are widely used
 have 3 versions

CIS-5373: 10.February.2020 31
 X.509 Certificate Generation

CA Priv. Key
Alice ID

Public Key

CA info
Alice ID

Public Key

CA info

Hash H Signature
Algorithm

Alice’s certificate

CIS-5373: 10.February.2020 32
 X.509 Certificate Verification

Alice ID

Public Key
Hash H Hash value h1
CA info

CA Pub. Key

Valid?

Verification
Algorithm
Alice’s certificate

CIS-5373: 10.February.2020 33
 X.509 Certificate Format
 Issued by a Certification Authority (CA), containing:
 version (1, 2, or 3)
 serial number (unique within CA) identifying certificate
 signature algorithm identifier
 issuer X.500 name
 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)

 Notation: CCA(A) is certificate for A signed by CA

CIS-5373: 10.February.2020 34
 X.509 Certificate Format (cont’d)

From Stallings book

CIS-5373: 10.February.2020 35
 X.509 Version 3

 Additional information may be needed in a

certificate
 E-mail/URL, policy details, usage constraints
 Hard to explicitly name new fields
 Backward compatibility issues
 Define a general extension method
 Extension identifier
 Criticality indicator
 Extension value

CIS-5373: 10.February.2020 36
 Obtaining a Certificate

 Any user with access to CA can get any certificate

from it
 Only the CA can modify a certificate
 Certificates can be placed in a public directory
 Certificates cannot be forged

CIS-5373: 10.February.2020 37
 Certificate Revocation

 Certificates have a period of validity

 May need to be revoked before expiry:
1. User's private key is compromised
2. User is no longer certified by this CA
3. CA's certificate is compromised
4. User behaves badly
 CA maintains list of revoked certificates
 Certificate Revocation List (CRL)
 Users should check certificates with CA’s CRL

CIS-5373: 10.February.2020 38
 Certificate Revocation (cont’d)

 When Alice obtains Bob’s

certificate
 Contact CA
 Check that certificate is not
revoked (in CRL) !

 CA needs to maintain a
certificate in CRL until
certificate expires

From Stallings book

CIS-5373: 10.February.2020 39
 Certificate Revocation Problem

 Alice does something bad at time T1

 CA finds out and revokes A’s certificate at T2
 Place A certificate into CRL
 Alice can continue to misbehave and be
authenticated between T1 and T2 !

CIS-5373: 10.February.2020 40
 CA Hierarchy

 What if A and B do not share a CA ?

 Solution: CA's must form a hierarchy
 Use certificates linking members of hierarchy to
validate other CA's
 Each CA has certificates for itself (from parent CA) and for
parent (backward)
 Each client trusts parents certificates

CIS-5373: 10.February.2020 41
 CA Hierarchy Example
 A obtains B’s certificate
 CU(V)
V
 CV(W)
 CW(B)

Own: CV(U)
Parent: CU(V) CV(W)
U CW(V)
W

Own: CU(A) Own: CW(B)

Alice A Bob B

CIS-5373: 10.February.2020 42
 Certificate Types

 Root certificate (Trust anchor)

 Self-signed certificate used to sign other certificates
 E.g., Google Trust Services (https://pki.goog/)
 Intermediate certificate
 Used to sign other certificates
 Must be signed by intermediate or root certificate
 End-entity or leaf certificate
 Cannot be used to sign other certificates
 TLS/SSL server and client certificates
 Email certificates

CIS-5373: 10.February.2020 43