Upload
cyndi
View
63
Download
0
Tags:
Embed Size (px)
DESCRIPTION
ECE454 /599 Computer and Network Security. Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2012. Security Handshake Pitfalls. Login only Mutual authentication Integrity/encryption after authentication Nonce types - PowerPoint PPT Presentation
Citation preview
1
ECE454/599 Computer and Network Security
Dr. Jinyuan (Stella) SunDept. of Electrical Engineering and Computer ScienceUniversity of Tennessee Fall 2012
2
Security Handshake Pitfalls• Login only• Mutual authentication• Integrity/encryption after authentication• Nonce types• Picking random numbers
3
Security Protocol An agreement between communication
parties about the process and the format of security bootstrap, authentication, key establishment, encryption/hashing algorithm and parameter negotiation, etc.
Typically include:- Authentication handshake- Session key negotiation, algorithm/parameter negotiation- Data encryption and/or integrity protection
4
Security Bootstrap Shared secret:Password (for human users)Pre-shared key (between firewalls)Ticket by KDC (among a large number of
participates)Public key:Manually configuredCertificate by CA
5
Login Only: A Bad Idea Alice sends name and password in
clear (across network) to BobBob verifies name and password and
communication proceeds
6
Login Only: A Better Idea Using Shared Secret (1)
f(K,R) can be K{R} or h(K,R) Authentication is one way: impersonation of Bob,
offline password guessing, database reading How to encrypt subsequent conversation?
7
Login Only: A Better Idea Using Shared Secret (2)
Problems: same as the previous one Requires reversible cryptography (hash will not work) If R is a recognizable number, this protocol does
mutual authentication Can make R recognizable but with limited lifetime,
e.g., timestamp. It however requires clock synchronization
8
Login Only: A Better Idea Using Shared Secret (3)
Advantages: It can be easily added to an existing protocol More efficient: it saves two message exchanges Bob is statelessProblems: Replay attack (multiple servers) Reset clock attack
9
Login Only: A Better Idea Using Shared Secret (4)
Same as the previous one, but using a hash Why transmit timestamp in the clear?
10
Login Only: A Better Idea Using PKC (1)
Implications: Compromise of Bob's database will not allow attacker
to impersonate Alice Attacker may be able to trick Alice into signing
anything
11
Login Only: A Better Idea Using PKC (2)
Implications: Compromise of Bob's database will not allow attacker
to impersonate Alice Attacker may be able to trick Alice into decrypting
anything
12
Mutual Authentication (1)
Problem: inefficient
13
Mutual Authentication (2) – Optimized
Implications: More efficient Subject to reflection attack: easy to obtain chosen
plaintext
14
Reflection Attack Trudy opens 1st session to Bob Trudy opens 2nd session to Bob in order to get
information needed to complete 1st session
15
Reflection Attack (Cont’d)Solution:Alice and Bob should not do exactly the same
thing: different keys, different challenges Different keys: have Bob encrypt with KAlice-Bob
and Alice encrypt with KAlice-Bob+1, etc. Different challenges: initiator (Alice) sends
odd R, responder (Bob) sends even R, etc.
16
Mutual Authentication (3) – Less Optimized
Implications: One "extra" message and Trudy cannot obtain chosen
plaintext Rule: the initiator should be the first to prove its
identity (the assumption is that the initiator is more likely the bad guy)
17
Mutual Authentication (4)
Implications: Can be easily added to existing challenge/response
protocols Alice and Bob must encrypt different things Clock synchronization: time is now security-critical Reflection attack
18
Mutual Authentication (5)
Implications: How to obtain public keys? Store Bob’s public key encrypted with Alice’s
password Store Bob’s public key certificate signed by Alice
19
Integrity/Encryption After AuthenticationHow to establish a session key during
authentication?By shared secretBy two-way public keyBy one-way public key
20
Shared Secret
After this authentication: Can we use K{R+1} as the shared session key? How about K XOR R, K{K+R}, K+K{R}, h{K|R}?In general, a good session key is different for each session unguessable by attacker
21
Two Way Public KeyAlice and Bob each has a public/private key pairHow about Alice picks a random R, and sends {R}Bob to
Bob- Trudy can impersonate Alice
How about Alice sends [{R}Bob]Alice to Bob- Trudy can obtain R by overrunning Bob and decrypt old messages
Alice sends Bob [{R1}Bob]Alice, Bob sends Alice [{R2}Bob]Alice, and the session key is R = R1 XOR R2
- Trudy needs to overrun both Alice and BobDiffie-Hellman key establishment: Alice sends Bob [gR1
mod p]Alice, Bob sends Alice [gR2 mod p]Bob, and the session key is R = gR1R2 mod p- Doesn’t help even if Trudy overruns both Alice and Bob
22
One Way Public KeyOnly Server Bob has a public/private key pair,
Client Alice won’t bother having keys and certificate: SSL
Alice picks a random R, and sends {R}Bob to Bob- Trudy can decrypt old messages by overrunning Bob
Diffie-Hellman key establishment: Alice sends Bob gR1 mod p, Bob sends Alice [gR2 mod p]Bob, and the session key is R = gR1R2 mod p
Trudy can impersonate Alice in either case
23
Nonce TypesNonce: a quantity used only once
- Large random number: unguessable, unpredictable, non-reuse w.h.p., makes the best nonce- Timestamp: requires clock synchronization- Sequence number: needs to maintain state
unpredictability is important
unpredictability is not required
24
Picking Random NumbersDifferent applications require different types of
random numbersA common approach for cryptographic
operations: pseudorandom number generator- seed value is critical- common mistakes: seed is from a small space, hashing the current time when a random value is needed, divulging the seed value
25
Authentication Protocol Checklist
Authentication protocols protect againsteavesdropping impersonationdatabase readingmessage modificationcombinations of the above
26
Reading Assignment• [Kaufman] Chapter 11