18-733 Spring 2016 Homework 4 Review · Session Key From Shared Secret • Adversary guesses...

Post on 23-May-2020

6 views 0 download

Transcript of 18-733 Spring 2016 Homework 4 Review · Session Key From Shared Secret • Adversary guesses...

18-733 Spring 2016 Homework 4 Review

Kyle Soska

April 1, 2016

0

0.5

1

1.5

2

2.5

3

3.5

10 10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.5 16 16.5 17 17.5 18 18.5 19 19.5 20

HW 4 Grade Distribution - Overall

0

0.5

1

1.5

2

2.5

10 10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.5 16 16.5 17 17.5 18 18.5 19 19.5 20

HW 4 Grade Distribution - By Lateness

On Time

Late

Key Exchange Protocols

• Pretty strait forward

• Confusion about what does it mean to be Complete vs Secure

• 𝑥 ←𝑅 ℤ𝑞 means randomly sample 𝑥 from ℤ𝑞

Key Exchange Protocols

• Is it possible to simultaneously satisfy receiver authentication, client authentication, and client privacy in two messages? – Tricky part is client authentication and privacy

– The material for authenticating the client needs to be encrypted

– Can use server public key, but then there are replay attacks

– Can use nonce but then the server needs to keep state about nonces it has seen, gets messy

Key Exchange Protocols

Question: What is the deal with the 𝑁𝐼′, 𝑁𝐼?

Answer: Don’t want an adversary to send messages in step 3 that cause the server to do lots of work without the adversary doing work. Need some ‘check’ that is cheap that can prevent the server from doing modular exponentiation

Key Exchange Protocols

• Generically, how do you mitigate against DDOS?

– If it is network DDOS, you add network filters, flow detection, etc

– If it is resource DDOS, you can use computational puzzles and proof of work / proof of storage

SSL / TLS Part 1

• Carry out the attack by pinning fake certificate into H1’s web browser

• Can’t detect the attack if using server authentication only since the server is exactly who it should be

• Can detect the attack if using client authentication

• Can detect the attack if you get a point of view outside of the company network • Notary servers provide a way for doing this. These

servers exist on the web and just request the certificates of websites that you can lookup and compare against your own view

• If TLS allowed you to resume your old session by providing

a hash of the old session id and the server public key, it would be useless since the attacker wouldn’t know the session key

SSL / TLS Part 2

• Anonymous Diffie-Hellman (128-bit AES, MD5) – Broken due to MitM attack

• Ephemeral Diffie-Hellman (128-bit AES, MD5) – Secure

• Ephemeral Diffie-Hellman (40-bit DES) – Insecure due to weak symmetric key

• Fixed Diffie-Hellman (128-bit AES, MD5) – Insecure due to broken PFS

• Fixed Diffie-Hellman (40-bit DES) – Broken due to weak symmetric key and PFS

Session Key From Shared Secret

• Typically:

– Let 𝑘 ←𝑅 0, 1 128 be some random session key

– Encrypt with password: 𝑃(𝑘)

– Attacker now has to guess the password

• 𝑃′−1 𝑃 𝑘 = 𝑘? Check: 𝐷𝑒𝑐𝑘 𝐸𝑛𝑐𝑘 𝑘𝑛𝑜𝑤𝑛

• Passwords are bad, can guess easiest 25% rapidly

Session Key From Shared Secret

• Better:

– 𝑃 𝐸𝐴 where 𝐸𝐴 is a randomly generated public key, with a corresponding decryption key

– Server gets 𝑃 𝐸𝐴 , computes 𝐸𝐴 and sends back 𝑃 𝐸𝐴 𝑘

– Client computes DA 𝑃−1 𝑃 𝐸𝐴 𝑘 , gets 𝑘

– Adversary guesses 𝑃′, computes 𝑃′−1 𝑃 𝐸𝐴

Session Key From Shared Secret

• Adversary guesses 𝑃′, computes 𝑃′−1 𝑃 𝐸𝐴 – If 𝑃′ ≠ 𝑃, it will look like random bits – If 𝑃′ = 𝑃, still not clear that the adversary is correct

• Problem: 𝐸𝐴 is a public key, and looks different from the failed attempts that look like random bits, adversary can efficiently test if the result is a valid public key

• Solution: For RSA, only encrypt the encryption exponent 𝑒, and do some tricks so that it looks like a random string

Session Key From Shared Secret

• Major Problem

– Keys are stored in plaintext on the server !

– Password databases get stolen all the time, the current standard is to only store a hash of the passwords which is less bad

– Employees could be corrupt or want to steal passwords

Discrete Log Meet In Middle Attack

• Not really a problem in practice, typical discrete log instantiations are ~2048 bits, attack reduces complexity to 1024 bits

• There are ways to tradeoff the size of the table and the number of computations to minimize cost, not super important since this attack is not that strong