Cryptography Protocols
Anita Jones
CS451 Information Security
Copyright(C) Anita Jones
Applications for protocols
Key distribution
Confidentiality
Sign message with digital signature
Authentication
Non-repudiation
…..
September, 2006
Protocol
protocol – an agreed upon sequence of
actions to accomplish some task
Numbered sequence of message transmissions
Exchanged by 2 or more parties
Named, but NOT guaranteed to be who they say
they are
Example format
1 A  B: <message1>
2 B  A: <message2>
……..
September, 2006
Illustrate protocol notation
1 A->KDC:
IDA, IDB, ‘need Certificate’
2 KDC->A:
EKa [‘need Certificate’, IDB, CAB]
3 ...
Sequence (strict sequence) of numbered steps
4 ...
A -> B denotes that A sends message to B
5 ...
Message follows the colon
Objective: distribute digital certificate for B …………..
September, 2006
Notation for Keys
Shared secret session key – Ks
A’s public or private key – Ka
B’s public or private key – Kb
EKa[M] – encrypt with A’s key
DKa[M] – A “decrypts” with its key
Since “E” and “D” are the same, I use E, almost always.
Public and private keys – obvious in context.
September, 2006
Key Distribution
Distribute public keys
Distribute secret (session) keys
Back to key distribution
each user generates public/private keys
distributes via:
individual gives out his public key, e.g. append
key to email automatically
insert into public directory (maintained by
reputable party) readable by all
public key authority that requires a request
before returning public key (or certificate)
September, 2006
Key distribution via KDC
Version 1 situation:
A wants to talk to B
A & B need the public key of the other
A & B trust the key distribution center KDC
Users want to be assured that the key came
from KDC (authentication)
September, 2006
Get Public Key from Key Authority
… KDC (Key Distribution Center) knows public key for A,B
Everyone knows KDC’s public key
1 A->KDC: “need key”, IDB
2 KDC->A: EKR-KDC [KUB ,“need key”, IDB]
3 B->KDC: “need key”, IDA
4 KDC->B: EKR-KDC [KUA ,“need key”, IDA]
Authentication: A,B know that keys came from KDC
September, 2006
Key distribution via KDC
Version 2 situation:
A wants to talk to B
A & B need the public key of the other
A & B trust the key distribution center KDC
A already shares a secret key with KDC, Ka
B already shares a secret key with KDC, Kb
September, 2006
Get Public Key from Key Authority
… Exchanges use a shared (secret) key
1 A->KDC: EKa[“need key”, IDB]
2 KDC->A: EKa [KUB ,“need key”, IDB]
3 B->KDC: EKb[“need key”, IDA]
4 KDC->B: EKb[KUA ,“need key”, IDA]
September, 2006
Secret Session Key from KDC
Version 3 situation:
A wants to talk to B (a session)
A & B need a secret key -- shared
A & B trust KDC to create that session key
Protocol:
A asks for session key (to talk to B)
KDC creates the key and sends it to A
KDC sends the same key to B
B receives a key from KDC, associated with A’s
name, so B knows that A wants a session with B
September, 2006
Get Session Key from Key Authority
… KDC (Key Distribution Center) knows public keys of A,B
Everyone knows KDC’s public key
1 A->KDC: EKR-a[“key”, IDB]
2 KDC->A: EKU-a[EKR-KDC [KS ,“key”, IDB]]
3 KDC->B: EKU-b[EKR-KDC [KS ,“key”, IDA]]
One key “authenticates”;
other key keeps the session key confidential
September, 2006
A&B Generate their own Secret
Session Key
Version 4 situation:
A wants to talk to B (a session)
They want to use a shared, secret session key
… for efficiency
A & B already know each other’s public keys
They talk directly – no KDC involvement
September, 2006
Create a secret shared session key
… given a public key mechanism, users can directly
exchange a secret session key
1 A->B: EKU-B [IDA, “start session 88”]
…A says “I want to talk”
2 B->A: EKU-A[Ks, “session 88”]
…ok A, here’s our session key
B creates KS, the shared session key
September, 2006
Introducing the notion of a NONCE
Nonce word is invented or used just for a
particular occasion
used in security protocols to
ensure “sequence” of a set of messages
ensure “freshness” of a message
can be a time stamp, a random number or
a counter value
should be difficult to guess
creators must remember their nonces
September, 2006
Needham Schroeder protocol
Use a trusted third party
KDC - key distribution center is trusted
each user shares secret key with KDC
KDC generates keys to be used for a
session
KDC distributes those session keys
Session uses secret key, not public/private key
September, 2006
Needham Schroeder protocol
1 A->KDC:
A asks for secret key for A & B
2 KDC->A:
here is key & envelope for B
3 A->B:
A sends the envelope (key inside)
4 B->A:
I got particular key k
5 A->B:
I saw that you received key k
Objective: distribute session key securely to A and B
September, 2006
Needham Schroeder protocol
1 A->KDC:
IDA, IDB, N1
2 KDC->A:
EKa [Ks, IDB, N1, EKb [Ks, IDA ]]
3 A->B:
EKb[Ks, IDA]
4 B->A:
EKs[ N2 ]
5 A->B:
EKs[ f(N2) ]
Objective: distribute session key securely to A and B
September, 2006
Issues
step 1 was not encrypted? Any problem?
alternative values of the nonce, f(nonce)
could any intervention in the sequence
allow a masquerade?
replay of step 2
KDC sent message to A, but who
“authenticated” B to A?
September, 2006
Why do we need steps 4 & 5
Stop replay attack where adversary
captures message in step 3 and replays it,
in order to disrupt operations at B
September, 2006
Still a problem …...
Assume that adversary X compromised
an old session key.
OK, not likely but …
Z impersonates A and tricks B into using
the old key by simply replaying step 3
And if Z can intercept the message in step
4, then it can impersonate A’s response
and from then on can impersonate A
September, 2006
Denning’s solution - add timestamps
1 A->KDC: IDA, IDB
2 KDC->A: EKa [Ks, IDB, T, EKb [Ks, IDA, T]]
3 A->B:
EKb [Ks, IDA, T]
4 B->A:
5 A->B:
EKs[ N ]
EKs[ f(N) ]
(Clock - T) cannot exceed clock skew plus network delay
September, 2006
Controlling timing
keeping clocks in synch
theoretically hard to do
in practice, under normal situations, & with no
sabotage, not difficult
require synching with KDC’s clock, or GPS
controlling network overhead is more
difficult
suppress relay attack - sender clock ahead
of receiver’s - replay when receiver catches
up
September, 2006
Digital Signature
September, 2006
Digital signature
Unforgeable: msg M signed by person P:
[M, EKp[P,M]]
Authentic: if person R receives [M, EKp[P,M]],
R must be able to check that the signature
could only have been created by P, and that
it is attached to message M
September, 2006
Distribution protocol -- using certificates
Key authority creates certificate that specifies
public key
users exchange certificates
can verify that certificate originated from the
certificate authority
September, 2006
Distribution protocol -- using certificates
1 A->KDC: KUa
2 KDC->A: EKRkdc [KUa, IDA, time1] = CA
3 B->KDC: KUb
4 KDC->B: EKRkdc [KUb, IDB, time2] = CB
5 users exchange certificates
6 given CB,, A decrypts it to get KUb, IDB, time2
by computing EKUkdc[ EKRkdc [KUb, IDB, time2] ]
September, 2006
Key distribution with certificates
… users simply exchange certificates
1 A->B: CA
2 B->A: CB
September, 2006
Create a secret shared session key
… given certificates, users can directly exchange a secret
session key
1 A->B: “let’s talk”, CA
2 B->A: “ok”, CB
3 A->B: EKU-B[Ks]
September, 2006
…ok, here’s our
session key KS
Backups
September, 2006
Avoids the suppress-replay attacks
1 A->B:
IDA, Na
2 B->KDC: IDB, Nb, IDA, EKb [IDA, Na, Tb]
3 KDC->A: EKa [IDB,Na,Ks,Tb], EKb[IDA,Ks,Tb], Nb
4 A->B: EKb[IDA,Ks,Tb], EKs [Nb]
Assume that A & B share a secret key with KDC.
Tb is a limit on session key usage; only relies on B’s clock
September, 2006