A3 Part II

Deadline: Wednesday, 03/15/17, 11:59 pm

This assignment may be done as individuals or with one partner.

In Part II of this assignment, you will implement some core pieces of a secure instant-messaging application, as well as simulate a Dolev-Yao attack against that application. You do not need to submit anything for Part I; we assume that, as you are reading this text, you have successfully solved Part I.

Overview

Your task is to build a collection of four programs named Alice, Bob, Mallory, and Gen:

• Alice: repeatedly prompts the user for a string then sends that string over the network to the recipient.
• Bob: displays strings that are received from the sender.
• Mallory: the Dolev-Yao attacker. Mallory receives a message as input from the network, displays the message, and prompts the user whether to forward the message as is, to modify the message before forwarding it, or to drop the message and not forward it. Mallory can also store and replay old messages. The sophistication of modification and replay that you implement is up to you, as long as you are able to carry out the demo described below.
• Gen: generates public–private key pairs and stores them in files.

Requirements

Requirement 1: Network communication. Alice, Bob, and Mallory communicate with one another over TCP. The communication architecture is that Alice sends messages to Mallory, who sends messages to Bob:

Alice ---> Mallory ---> Bob

Hostnames (or network addresses) and ports must not be hardcoded. They could be specified as command-line arguments, or accepted as program inputs.

The expected workflow is as follows:

1. Run Gen to generate key files, which are then manually distributed to the filesystems from which Alice, Bob, and Mallory will run. Alice receives her public and private keys as well as Bob's public keys. Bob receives his public and private keys as well as Alice's public keys. Mallory receives both Alice and Bob's public keys, but not their private keys.
2. Start Bob.
3. Start Mallory, specifying Bob's address as the recipient.
4. Start Alice, specifying Mallory's address as the recipient.
5. Type strings into Alice, which are sent over the network to Mallory. Use Mallory to read, modify, and/or delete messages. Messages sent by Mallory to Bob should be displayed by Bob. If Bob is able to detect Mallory's actions on messages, then a notification about this action should be displayed.

Requirement 2: Cryptography. At startup, the system should provide the ability to operate in each of four configurations:

1. No cryptography: messages are not protected.
2. Symmetric encryption only: the confidentiality of messages is protected.
3. MACs only: the integrity of messages is protected.
4. Symmetric encryption then MAC: both the confidentiality and integrity of messages is protected with Enc-then-MAC.

Once an instance of the system is started, the configuration need not be changeable. The configuration must not be hardcoded. It could be specified as a command-line argument, or accepted as a program input.

Since Alice and Bob do not initially share any symmetric keys, you need a key establishment protocol; use the protocol provided in the appendix of this writeup.

Every message should be accompanied by a sequence number (aka message number). The system should use these sequence numbers to resist replay attacks, though the success of that countermeasure may depend upon the configuration in use.

The system configuration should determine how Mallory interprets and displays messages. We ask that you make Mallory's display easy for the human grader to interpret. More specifically: 1. No cryptography: Mallory displays the same plaintext message that Alice sent. This should be the same as the string entered at Alice—not (e.g.) some human-unreadable byte array. 2. Symmetric encryption only: Mallory displays the ciphertext. 3. MACs only: Mallory displays both the plaintext message and the tag. 4. Symmetric encryption then MAC: Mallory displays both the ciphertext and the tag.

Requirement 3: Interface. The sophistication of the interface you build is your choice. We are perfectly happy with text-only interfaces that are configured solely by command-line arguments.

Implementation: Choose a programming language and environment with which you are comfortable and that has library support for the cryptographic and networking functionality you will need. Java, C#, and Python are good choices. Use library implementations of encryption schemes, block cipher modes, MACs, digital signatures, and hash functions. Do not use library implementations of higher-level protocols, such as SSL/TLS.

Underspecification: All further details are up to you. Make reasonable choices and be prepared to defend them.

Rationale document

Prepare a rationale document explaining the use of cryptography in your system. The document should include protocol narrations to document the cryptographic protocol used in each of your four configurations. The document should also provide a justification for your choices of key lengths and cryptographic algorithms.

Submission

If you work with a partner, first form a group on CMS; submit as that group, rather than submitting the same solution independently. Submit your rationale document and an archive of your source code.

Demo

You will meet with a grader to demo your system in person on your own computer. It is acceptable to demo on a single physical computer. We will schedule the demos on CMS. The slots have not yet been created in CMS. We will post a message on Piazza after they have been created. Please sign up for a slot in CMS by Wednesday, 03/15/17, 11:59 pm.

Your demo should begin with you downloading your submission (code and rationale document) from CMS, so that the grader is convinced you have not made any later improvements.

During the demo, you will be asked to perform the experiments below. For most of the experiments, the graders will be observing information displayed by Mallory and Bob to assess the correctness of your system. In between experiments, you will be asked to discuss cryptographic protocols in your rationale document, point to implementations of protocols in your code, and justify cryptographic and implementation choices.

Part 1 [20 pts]:

• Run Gen to generate new key files.
• Start Bob, Mallory, and Alice in "no-cryptography" configuration.
• Send messages from Alice to Mallory to Bob.
• Use Mallory to delete a message.
• Use Mallory to modify a message.

Part 2 [26 pts]:

• Start Bob, Mallory, and Alice in "Enc-only" configuration.
• Send messages from Alice to Mallory to Bob.

Part 3 [14 pts]:

• Start Bob, Mallory, and Alice in "Mac-only" configuration.
• Send messages from Alice to Mallory to Bob.
• Use Mallory to replay an old message.
• Use Mallory to delete a message and pass the next message through.
• Use Mallory to modify a message.

Part 4 [7 pts]:

• Start Bob, Mallory, and Alice in "Enc-then-Mac" configuration.
• Send messages from Alice to Mallory to Bob.

We strongly recommend that you practice these experiments before your demo, so that you are relaxed and comfortable, hence better able to answer the grader's questions, and so that you are able to finish your demo during the time allotted.

Evaluation

You will be evaluated on the quality of your submission and demo, and on your adherence to the submission stipulations above. The quality of your source code (documentation, style, etc.) will not explicitly be evaluated.

Appendix: Key transport protocol

The following, known as ISO/IEC 11770-3 Key Transport Mechanism 2, is a key transport protocol based on asymmetric cryptography. It enables A to convey a fresh session key to B by sending a single message.

1. A -> B: B, tA, Enc(A,kAB; K_B), Sign(B, tA, Enc(A,kAB; K_B); k_A)

where

• A and B are identifiers for principals, which in this assignment may simply be strings
• tA is a timestamp sampled from A's local clock and verified by B against B's local clock to be recent, which in this assignment is defined as "within the last two minutes"
• Enc is an asymmetric encryption algorithm
• Sign is a digital signature algorithm
• kAB is a fresh session key generated by A
• K_B is B's public encryption key
• k_A is A's private signing key

Furthermore, Enc must be a non-malleable encryption scheme. Hint: RSA with OAEP padding is non-malleable.