ECE 454/CS594 Computer and Network Security

1

ECE454/CS594 Computer and Network Security

Dr. Jinyuan (Stella) SunDept. of Electrical Engineering and Computer ScienceUniversity of Tennessee Fall 2011

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 (single server, 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: How to obtain public keys? Store Bob’s public key encrypted with Alice’s

password Store Bob’s public key certificate signed by Alice

18

Mutual Authentication (5)

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

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 reading message modification combinations of the above

26

Reading Assignment• [Kaufman] Chapter 11