IS511 Introduction to Information Security Lecture 4 Cryptography 2 Yongdae Kim
Jan 13, 2016
IS511Introduction to
Information Security Lecture 4
Cryptography 2
Yongdae Kim
Digital Signature
IntegrityAuthenticationNon-repudiationI did not
have intimate relations with that woman,…, Ms. Lewinsky
Digital Signature with Appendix
Schemes with appendixRequires the message as input to verification
algorithmRely on cryptographic hash functions rather than
customized redundancy functionsDSA, ElGamal, Schnorr etc.
Digital Signature with Appendix
M
m mh
Mh
h s*
SSA,k
Mh x Su 2{True, False}
VA
s* = SA,k(mh)
u = VA(mh, s*)
Authentication
How to prove your identity?Prove that you know a secret information
When key K is shared between A and ServerA S: HMACK(M) where M can provide freshnessWhy freshness?
Digital signature?A S: SigSK(M) where M can provide freshness
Comparison?
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))
Challenge-response authentication
Alice is identified by a secret she possessesBob needs to know that Alice does indeed possess
this secretAlice provides response to a time-variant
challengeResponse depends on both secret and challenge
UsingSymmetric encryptionOne way functions
Challenge Response using SKE
Alice and Bob share a key KTaxonomy
Unidirectional authentication using timestamps
Unidirectional authentication using random numbers
Mutual authentication using random numbers
Unilateral authentication using timestampsAlice Bob: EK(tA, B)Bob decrypts and verified that timestamp is OKParameter B prevents replay of same message in
B A direction
Challenge Response using SKE
Unilateral authentication using random numbersBob 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 numbersBob Alice: rb
Alice Bob: EK(ra, rb, B)
Bob Alice: EK(ra, rb)
Alice checks that ra, rb are the ones used earlier
Challenge-response using OWF
Instead of encryption, used keyed MAC hK
Check: compute MAC from known quantities, and check with message
SKID3Bob Alice: rb
Alice Bob: ra, hK(ra, rb, B)
Bob Alice: hK(ra, rb, A)
Key Establishment, Management
Key establishmentProcess to whereby a shared secret key becomes
available to two or more partiesSubdivided into key agreement and key transport.
Key managementThe set of processes and mechanisms which
support key establishment The maintenance of ongoing keying relationships
between parties
Kerberos vs. PKI vs. IBE
Still debating Let’s see one by one!
Kerberos (cnt.)
T
A B
A,
B,
NA
EEK
BT
KB
T(k,
A,
L),
E(k
, A
, L)
, E
KA
TK
AT(
k, N
(k,
NAA,
L, B
),
L, B
)
EEKBTKBT(k, A, L), E(k, A, L), Ekk(A, T(A, TAA, A, Asubkeysubkey))
EEkk(T(TAA, B, Bsubkeysubkey))
•EEKBTKBT(k, A, L): Token for B(k, A, L): Token for B•EEKATKAT(k, N(k, NAA, L, B): Token for A, L, B): Token for A•L: Life-timeL: Life-time•NNAA??
•EEkk(A, T(A, TAA, A, Asubkeysubkey): To prove B that A knows k): To prove B that A knows k•TTAA: Time-stamp: Time-stamp
•EEkk(B, T(B, TAA, B, Bsubkeysubkey): To prove A that B knows k): To prove A that B knows k
Kerberos (Scalable)
T (AS)
A B
A,
G,
NA
EEK
GT
KG
T(k(k
AG
AG,
A,
L),
E,
A,
L),
EK
AT
KA
T(k(k
AG
AG,
N,
NAA,
L, G
),
L, G
)
EEKGB KGB (k(kABAB, A, L, N, A, L, NAA ’’), E), EkABkAB(A, T(A, TAA ’’, A, Asubkeysubkey))
EEkk(T(TAA ’’, B, Bsubkeysubkey))
G (TGS)
EE KGTKGT
(k(k AGAG, A
, L),
E
, A, L
), E kA
GkA
G(A
, T(A
, T AA),
B, ),
B,
NN AA’’
EE KAGKAG
(k(k ABAB, N, N
AA’’, L
, B),
E
, L, B
), E kG
BkG
B(k(k ABAB
, A, L
, N
, A, L
, NAA’’),
B, NA
), B, N
A’’
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.
CA
a trusted third party whose signature on the certificate vouches for the authenticity of the public key bound to the subject entityThe 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!
ID-based CryptographyNo public keyPublic key = ID (email, name, etc.)PKG
Private key generation centerSKID = PKGS(ID)PKG’s public key is public.distributes private key associated with the ID
Encryption: C= EID(M)
Decryption: DSK(C) = M
Discussion (PKI vs. Kerberos vs. IBE)
On-line vs. off-line TTP Implication?
Non-reputation?Revocation?Scalability?Trust issue?
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)
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 NSAlgorithm
A B: PB(k1, A, r1) B A: PA(k2, r1, r2) A B: r2
Removing third encryption
Key Transport using PKC Needham-Schroeder
Algorithm A B: PB(k1, A)
B A: PA(k1, k2, B)
A B: PB(k2)
Modified NS Algorithm
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
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
Attack strategies and classic flaws
“man-in-the-middle” attack on unauthenticated DH Reflection attack
Original protocol1. A B : rA
2. B A : Ek(rA, rB)
3. A B : rB
4. Attack4 A E : rA
4 E A : rA : Starting a new session4 A E : Ek(rA, rA’) : Reply of (2)4 E A : Ek(rA, rA’) : Reply of (1)4 A E : rA ’ prevented by using different keys for different sessions
Attack strategies and classic flaws
Interleaving attacks To provide freshness and entity authentication Flawed protocol
1. A B : rA
2. B A : rB, SB(rB, rA, A)
3. A B : rA’, SA(rA’, rB, B)
1. Attack1. E B : rA
2. B E : rB, SB(rB, rA, A)
3. E A : rB
4. A E : rA’, SA(rA’, rB, B)
5. E B : rA’, SA(rA’, rB, B)
2. Due to symmetric messages (2), (3)