2003_midtermsols

2003_midtermsols - Massachusetts Institute of Technology...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Massachusetts Institute of Technology Handout 15 6.857: Network and Computer Security November 8, 2003 Professor Ronald L. Rivest Take-Home Midterm Solutions Problem M-1. Protocol Design (Courtesy of Megumi Ando.) The most overwhelmingly common (and disappointing) error we saw was in the fixes to the broken client- server authentication scheme. Almost everyone suggested some kind of ad-hoc fix to the protocol, such as: • Making the nonce longer, so the plaintext spans more than one block. • Doing a more complicated operation on the nonce (instead of just incrementing it). • Forcing the client’s IV to be a specific value, or disallowing certain values. • Swapping the order of the (incremented) nonce and client identity. The problem with all these solutions is that they ignore the core issue, which makes the attack possible in the first place: encryption is/may be malleable — it is not the right tool for the job! The authentication protocol is attempting to establish that the client knows the secret key K ; however, as we have seen, it is possible to create a good-looking ciphertext (by mauling another one) without knowing what it means! Therefore, the proper thing to do in this scenario is to include a MAC : this establishes authenticity of the message, and in particular, a valid MAC cannot be generated without knowledge of K . To properly fix the bug, the client should also send a MAC of the response ciphertext. This ensures secrecy of the nonce n , as well as proper authentication of the client. The following solution was submitted by Megumi Ando: (a) If Alice sends Bob ( A, { n 1 } K ), she expects Bob to send her something in the form ( B, { n 2 } K ) to start another initiation, OR ( B, { n 1 + 1 } K ) in response to her initiation. More specifically, if Alice sends Bob an encrypted nonce, and she receives the same nonce from Bob, she assumes that Bob is starting another initiation and sends Bob the correctly encrypted incremented nonce. Let Mallory be a malicious adversary, who does not know K . She waits until Alice (who does knows K ) sends her an encrypted nonce ( A, C 1 ), where C 1 = { n } K . Mallory then sends Alice the same encrypted nonce ( M,C 1 ). Alice, who then assumes that Mallory is starting another initiation, correctly computes C 2 = n + 1 } K and sends Mallory the correctly encrypted incremented nonce { ( A, C 2 ). Mallory then sends Alice ( M, C 2 ). One way to fix this bug is to disallow two instances of the protocol from interleaving. That is, if Alice sends Bob ( A, { n 1 } K ), she expects Bob to send her ( B, { n 1 + 1 } K ) before he sends her ( B, { n 2 } K ). (b) The adversarial client (who does not know K ) waits for the server to send two 128-bit blocks. Let IV be the first block. Let C be the second block....
View Full Document

This note was uploaded on 04/28/2009 for the course CS 6.857 taught by Professor Rivest during the Spring '03 term at MIT.

Page1 / 8

2003_midtermsols - Massachusetts Institute of Technology...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online