1. IS511 Introduction to Information Security Lecture 3 Public Key Cryptography and Key Management
Yongdae Kim

2. Encryption Why do we use key? Alice Bob
Adversary
Encryption
Ee(m) = c c
insecure channel
Decryption
Dd(c) = m m m
Plaintext source
destination
Alice
Bob
Why do we use key?
Or why not use just a shared encryption function?

3. SKE with Secure channel
Adversary
d Secure channel
Key source e
Encryption
Ee(m) = c c
Insecure channel
Decryption
Dd(c) = m m m
Plaintext source
destination
Alice
Bob

4. PKE with insecure channel
Passive
Adversary
e Insecure channel
Key source d
Encryption
Ee(m) = c c
Insecure channel
Decryption
Dd(c) = m m m
Plaintext source
destination
Alice
Bob

5. Public key should be authentic!
Ee’(m)
Ee(m) e
Ee(m)
Need to authenticate public keys

6. Digital Signatures Primitive in authentication and non-repudiation
Process of transforming the message and some secret information into a tag
Nomenclature
M is set of messages
S is set of signatures
SA: M ! S for A, kept private
VA is verification transformation from M to S for A, publicly known

7. Key Establishment, Management
Process to whereby a shared secret key becomes available to two or more parties
Subdivided into key agreement and key transport.
Key management
The set of processes and mechanisms which support key establishment
The maintenance of ongoing keying relationships between parties

8. Symmetric vs. Public key
Pros
Cons
SKE
High data throughput
Relatively short key size
The key must remain secret at both ends
O(n2) keys to be managed
Relatively short lifetime of the key
PKE
O(n) keys
Only the private key must be kept secret
longer key life time
digital signature
Low data throughput
Much larger key sizes

9. Digital Signature WJ Clinton Integrity Authentication Non-repudiation
I did not have intimate relations with that woman,…, Ms. Lewinsky
WJ Clinton

10. Digital Signature with Appendix
Schemes with appendix
Requires the message as input to verification algorithm
Rely on cryptographic hash functions rather than customized redundancy functions
DSA, ElGamal, Schnorr etc.
More commonly used

11. Digital Signature with AppendixM Mh S
SA,k h m mh s*
An entity A should obtain a public and private key. A should select an element k if the algorithm is randomized. Compute h(m) mapping m to the hash value space and apply the signing algorithm using A’s private key on this value to obtain s*.
A’s signature for m is s* which are both made available to entities which may wish to verify the signature
Verification involves obtaining A’s authentic public key VA, compute h(m) and apply the verification algorithm to h(m) and s*, if this results in true the signature is valid. If it results in false, the signature is invalid.
Mh x S
u 2{True, False} VA
s* = SA,k(mh)
u = VA(mh, s*)

12. Authentication How to prove your identity?
Prove that you know a secret information
When key K is shared between A and Server
A  S: HMACK(M) where M can provide freshness
Why freshness?
Digital signature?
A  S: SigSK(M) where M can provide freshness
Comparison?

13. Encryption and Authentication
EK(M)
Redundancy-then-Encrypt: EK(M, R(M))
Hash-then-Encrypt: EK(M, h(M))
Hash and Encrypt: EK(M), h(M)
MAC and Encrypt: Eh1(K)(M), HMACh2(K)(M)
MAC-then-Encrypt: Eh1(K)(M, HMACh2(K)(M))
Encrypt-then-MAC: Eh1(K)(M), HMACh2(K)(Eh1(K)(M))

14. Challenge-response authentication
Alice is identified by a secret she possesses
Bob needs to know that Alice does indeed possess this secret
Alice provides response to a time-variant challenge
Response depends on both secret and challenge
Using
Symmetric encryption
One way functions

15. Challenge Response using SKE
Alice and Bob share a key K
Taxonomy
Unidirectional authentication using timestamps
Unidirectional authentication using random numbers
Mutual authentication using random numbers
Unilateral authentication using timestamps
Alice  Bob: EK(tA, B)
Bob decrypts and verified that timestamp is OK
Parameter B prevents replay of same message in B  A direction

16. Challenge Response using SKE
Unilateral authentication using random numbers
Bob  Alice: rb
Alice  Bob: EK(rb, B)
Bob checks to see if rb is the one it sent out
Also checks “B” - prevents reflection attack
rb must be non-repeating
Mutual authentication using random numbers
Alice  Bob: EK(ra, rb, B)
Bob  Alice: EK(ra, rb)
Alice checks that ra, rb are the ones used earlier

17. Challenge-response using OWF
Instead of encryption, used keyed MAC hK
Check: compute MAC from known quantities, and check with message
SKID3
Bob  Alice: rb
Alice  Bob: ra, hK(ra, rb, B)
Bob  Alice: hK(ra, rb, A)

18. Key Establishment, Management
Process to whereby a shared secret key becomes available to two or more parties
Subdivided into key agreement and key transport.
Key management
The set of processes and mechanisms which support key establishment
The maintenance of ongoing keying relationships between parties

19. Kerberos vs. PKI vs. IBE
Still debating 
Let’s see one by one!

20. Kerberos (cnt.) T A B EKBT(k, A, L): Token for B
EKAT(k, NA, L, B): Token for A
L: Life-time
NA?
A, B, NA
EKBT(k, A, L), EKAT(k, NA, L, B)
Ek(A, TA, Asubkey): To prove B that A knows k
TA: Time-stamp
Ek(B, TA, Bsubkey): To prove A that B knows k
EKBT(k, A, L), Ek(A, TA, Asubkey) A B
Ek(TA, Bsubkey)

21. Kerberos (Scalable) T (AS) G (TGS) A B
EKGT(kAG, A, L), EKAT(kAG, NA, L, G)
A, G, NA
EKGT(kAG, A, L), EkAG(A, TA), B, NA’
EKAG(kAB, NA’, L, B), EkGB(kAB, A, L, NA’), B, NA’
EKGB (kAB, A, L, NA’), EkAB(A, TA’, Asubkey) A B
Ek(TA’, Bsubkey)

22. Public Key Certificate
Public-key certificates are a vehicle
public keys may be stored, distributed or forwarded over unsecured media
The objective
make one entity’s public key available to others such that its authenticity and validity are verifiable.
A public-key certificate is a data structure
data part
cleartext data including a public key and a string identifying the party (subject entity) to be associated therewith.
signature part
digital signature of a certification authority over the data part
binding the subject entity’s identity to the specified public key.

23. CA
a trusted third party whose signature on the certificate vouches for the authenticity of the public key bound to the subject entity
The significance of this binding must be provided by additional means, such as an attribute certificate or policy statement.
the subject entity must be a unique name within the system (distinguished name)
The CA requires its own signature key pair, the authentic public key.
Can be off-line!

24. ID-based Cryptography
No public key
Public key = ID ( , name, etc.)
PKG
Private key generation center
SKID = PKGS(ID)
PKG’s public key is public.
distributes private key associated with the ID
Encryption: C= EID(M)
Decryption: DSK(C) = M

25. Discussion (PKI vs. Kerberos vs. IBE)
On-line vs. off-line TTP
Implication?
Non-reputation?
Revocation?
Scalability?
Trust issue?

26. Point-to-Point Key Update
Key Transport with one pass
A  B: EK(rA)
Implicit key authentication
Additional field
timestamp, sequence number: freshness
redundancy: explicit key authentication, message modification
target identifier: prevent undetectable message replay
Hence A  B: EK(rA, tA, B)
Mutual authentication: B  A: EK(rB, tB, A): K = f(rA, rB)
Key Transport with challenge-response
B  A: nB : for freshness
A  B: EK(rA, nA, nB, B)
B  A: EK(rB, nB, nA, A)
Cannot provide PFS
Authenticated Key Update Protocol
A  B: rA
B  A: (B, A, rA, rB), hK(B, A, rA, rB)
A  B: (A, rB), hK(A, rB)
W = h’K’(rB)

27. Key Transport using PKC
Needham-Schroeder
Algorithm
A  B: PB(k1, A)
B  A: PA(k2, B)
A  B: PB(k2)
Properties: Mutual authentication, mutual key transport
Modified NS
A  B: PB(k1, A, r1)
B  A: PA(k2, r1, r2)
A  B: r2
Removing third encryption

28. Key Transport using PKC
Needham-Schroeder
Algorithm
A  B: PB(k1, A)
B  A: PA(k1, k2, B)
A  B: PB(k2)
Modified NS
A  B: PB(k1, A, r1)
B  A: PA(k2, r1, r2)
A  B: r2
Removing third encryption
Encrypting signed keys
A  B: PB(k, tA, SA(B, k, tA))
Data for encryption is too large
Encrypting and signing separately
A  B: PB(k, tA), SA(B, k, tA)
Acceptable only if no information regarding plaintext data can be deduced from the signature
Signing encrypted keys
A  B: tA, PB(A, k), SA(B, tA, PB(A, k))
Prevent the above problem
Can provide mutual authentication

29. Combining PKE and DS Assurances of X.509 strong authentication
identity of A, and the token received by B was constructed by A
the token received by B was specifically intended for B;
the token received by B has “freshness”
the mutual secrecy of the transferred key.
X.509 strong authentication
DA=(tA, rA, B, data1, PB(k1)), DB=(tB, rB, A, rA, data2, PA(k2)),
A  B: certA, DA, SA(DA)
B  A: certB, DB, SB(DB)
Comments
Since protocol does not specify inclusion of an identifier within the scope of the encryption PB within DA, one cannot guarantee that the signing party actually knows (or was the source of) plaintext key

30. Attack strategies and classic flaws
“man-in-the-middle” attack on unauthenticated DH
Reflection attack
Original protocol
A  B : rA
B  A : Ek(rA, rB)
A  B : rB
Attack
A  E : rA
E  A : rA : Starting a new session
A  E : Ek(rA, rA’) : Reply of (2)
E  A : Ek(rA, rA’) : Reply of (1)
A  E : rA’
prevented by using different keys for different sessions

31. Attack strategies and classic flaws
Interleaving attacks
To provide freshness and entity authentication
Flawed protocol
A  B : rA
B  A : rB, SB(rB, rA, A)
A  B : rA’, SA(rA’, rB, B)
Attack
E  B : rA
B  E : rB, SB(rB, rA, A)
E  A : rB
A  E : rA’, SA(rA’, rB, B)
E  B : rA’, SA(rA’, rB, B)
Due to symmetric messages (2), (3)