Projects 4 and 5: Secure Log File

ENEE 457, Fall 2019

Project 4 (Build it) Due 11/25 @10:59am
Project 5 (Break it) Due 12/9 @10:59am

Overview

In this project, you will implement a secure log to describe the state of an art gallery: The guests and employees who have entered and left, and persons that are in rooms. In the setup phase, a cryptographic key will be generated and associated with a particular log. Subsequently, the cryptographic key will be used by the legitimate parties who modify and/or read the log. Specifically, after the setup phase, the log can be accessed by a legitimate party who holds the key via two programs. One program, logappend, will append new information to the log file, and the other, logread, will read from the file and display the state of the art gallery according to a given query over the log. We call the cryptographic key used by both programs the "authentication token," and it is supplied as a command-line argument, by a legitimate party who runs logappend and logread. Specifications for these two programs and the security model are described in more detail below.

You will build the most secure implementation you can; then you will have the opportunity to attack other students' implementations.

You will write your implementation in C. There is some basic starting code available. There are example makefiles available.

Deliverables

Project 4: Build it

You should submit via Canvas:

Your implementation, including all your code files and your makefile in a single .zip file will be submitted through Canvas.
A design document (PDF) in which you:
- Describe your overall system design in sufficient detail for a reader to understand your approach without reading the source code directly. This must include a description of the format of your log file.
- List four specific attacks you have considered, and describe how your implementation counters these threats. (Please note the relevant lines of code for your defense.) If you were not able to completely (or at all) prevent a threat you identified, you may still mention it. In that case, describe any partial mitigation you implemented and explain anything you wanted to implement but were for whatever reason unable to. Please be clear about distinguishing what you have implemented vs. what you would have implemented.
Name the .zip file as x-project4.zip and the design document as x-project4.pdf, where x is your first and last name. For example, if your name is "Jane Doe," you should be handing in two files named "JaneDoe-project4.zip" and "JaneDoe-project4.pdf."

Project 5: Break it

We will assign you three students' implementations to examine. You should submit via Canvas:

A vulnerability analysis document (PDF). Choose one of your assigned implementations and describe:
- Any attacks you found, including a high-level summary and enough detail for someone to replicate the attack
- Any vulnerabilities you found but were unable to exploit for whatever reason.
- If you did not find any attacks or vulnerabilities, describe how you looked for attacks.
Also submit any code you wrote to implement your attack, included in a single .zip file. Make sure the vulnerability analysis explains how to use your code to launch the attack.
Name the .zip file as x-project5.zip and the vulnerability analysis document as x-project5.pdf, where x is your first and last name. For example, if your name is "Jane Doe," you should be handing in two files named "JaneDoe-project4.zip" and "JaneDoe-project4.pdf."

If you demonstrate a working security break, then your vulnerability analysis document only needs to include your description of that one vulnerability, you don't need to go any further.

If one of your assigned implementations doesn't work well enough to analyze, please request an alternate implementation from an instructor.

Grading

Project 4 will be worth 100 points:

30 points for the automated correctness tests.
70 points for your design document:
- 10 points for your description of your approach
- 15 points for each of the four specific vulnerabilities you defend against. For maximum points, your defense should be correct, fully implemented, and well explained. Well explained attacks that are not fully implemented will receive partial credit.
- Extra credit (non-refundable as always) will be permitted for one extra attack/countermeasure beyond the original four.

Project 5 will be worth 100 points:

A successful attack with a well written vulnerability analysis will receieve full credit.
If you do not have a successful attack, then you must write a complete vulnerability analysis for one of the three implementations you were assigned. This analysis must explain either why you could not implement the attack you identified, or provide a convincing argument that there were no exploitable vulnerabilities.

Programs

You will design a log format and implement setup as well as both logappend and logread to use it. Each program's description is linked below.

The setup program generates an authentication token (i.e. a cryptographic key) and an empty log file with a specified name. The program returns the key to the user.
The logappend program receives as input the name of a logfile and an authentication token. The logappend program appends data to a log
The logread program receives as input the name of a logfile and an authentication token. The logread program reads and queries data from the log

logread contains a number of features that are optional. If you do not implement an optional feature, be sure to print unimplemented to standard output.

Look at the page of examples for examples of using the logappend and logread tools together.

Security Model

The system as a whole must guarantee the privacy and integrity of the log in the presence of an adversary that does not know the authentication token. This token is used by both the logappend and logread tools, specified on the command line. Without knowledge of the token an attacker should not be able to:

Query the logs via logread or otherwise learn facts about the names of guests, employees, room numbers, or times by inspecting the log itself
Modify the log via logappend.
Fool logread or logappend into accepting a bogus file. In particular, modifications made to the log by means other than correct use of logappend should be detected by (subsequent calls to) logread or logappend when the correct token is supplied

Formal Security Model

To allow for formal modeling, we assume two types of objects: a token object and a file object. A token object consists of the value of the token. A file object consists of the name of the file and the payload (i.e. the file itself). We assume that the setup algorithm takes as input a file name and outputs a token and file object. The logappend algorithm takes as input a token and file object as well as additional arguments. The logread algorithm takes as input a token and file object as well as additional arguments.

An attacker can break the security of the log in one of two ways:

Integrity Game between an attacker and a challenger

The Attacker specifies a file name "name" and sends (setup, name) to the Challenger.
The Challenger runs setup with argument name and generates a token object T and a file object F (initialized with the correct name). The Challenger sends F back to the Attacker.
The Attacker may issue any number of logappend requests with any file F' and arguments A of its choice by sending (logappend, F', A) to the Challenger. After each request, the Challenger runs logappend with token T, file F' and arguments A. If the output is ``invalid'', the Challenger returns ``invalid'' to the attacker. Otherwise, the Challenger returns the updated file F'' output by logappend.
Let Q denote the set of file objects (including the one generated by Setup) that are returned to the attacker throughout the game.
Finally, the attacker outputs a file F*.

The attacker wins the above game if F* is not contained in Q and if logread or logappend with token T and file F* does not return ``invalid.'' No efficient attacker should be able to win the game with non-negligible probability.

Privacy Game between an Attacker and a Challenger

The Attacker specifies a file name "name" and sends (setup, name) to the Challenger.
The Challenger runs setup with argument name and generates a token object T and a file object F (initialized with the correct name). The Challenger sends F back to the Attacker.
The Challenger chooses a bit b at random from {0,1}.
The Attacker may issue any number of logappend requests with a file object F' and a pair of arguments (A^i_0, A^i_1), by sending (logappend, F', (A^i_0, A^i_1)) to the Challenger. After each request, the Challenger runs logappend with token T, file F' and arguments A^i_b. If the output is ``invalid'', the Challenger returns ``invalid'' to the Attacker. Otherwise, the Challenger returns the updated file F'' output by logappend to the attacker.
Finally, the Attacker outputs a bit b' from {0,1}.

The attacker wins the above game if b' = b. No efficient attacker should be able to win the game with probability significantly better than 1/2. **We also require that for each pair (A^i_0, A^i_1) the information added by the append query has the same length.

**The above security game can actually be strengthened, to allow the attacker to also submit requests to the logread program. These requests will consist of a file F' and additional arguments A' (i.e. logread, F', A') will be sent to the Challenger). The Challenger will run logread with the token T, file F' and the additional arguments A' and return the output to the Attacker. Now, an Attacker can trivially distinguish whether the logappend commands are being run with arguments (A^1_0, A^2_0, ...) or (A^1_1, A^2_1, ...) in the case that the correct (logread output differs with respect to the these sequences of logappend requests. However, the security definition still makes sense if we restrict the attacker to sequences of arguments (A^1_0, A^2_0, ...), (A^1_1, A^2_1, ...) for logappend and sequences of arguments for logread for which in an ideal implementation the output sequence produced from logread would be identical when the logappend sequence is (A^1_0, A^2_0, ...) vs. (A^1_1, A^2_1, ...). In particular, this is the case for any sequence of (A^1_0, A^2_0, ...) and (A^1_1, A^2_1, ...), as long as logread is never called! This is equivalent to the simpler security game we specified above.