Date post: | 01-Jan-2016 |
Category: |
Documents |
Upload: | howard-holland |
View: | 218 times |
Download: | 0 times |
Cryptography Protocols
Anita JonesCS451 Information Security
Copyright(C) Anita Jones
September, 2006
Applications for protocols
Key distributionConfidentialitySign message with digital signatureAuthenticationNon-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 format1 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 . . .
4 . . .
5 . . .
Objective: distribute digital certificate for B …………..
Sequence (strict sequence) of numbered steps
A -> B denotes that A sends message to B
Message follows the colon
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.
Key Distribution
Distribute public keys
Distribute secret (session) keys
September, 2006
Back to key distribution
each user generates public/private keysdistributes 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 AKDC sends the same key to BB 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 guesscreators must remember their nonces
September, 2006
Needham Schroeder protocolUse 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 sessionKDC 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 2KDC 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: EKs[ N ]
5 A->B: 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 difficultsuppress 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] …ok, here’s our session key KS
September, 2006
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