For assignment 5, you'll be conducting a design review of another group's solution to Assignment 4. We will email you the solution they submitted for Assignment 4, as well as the output of the autograder as run on their code. See this page for more details on reading the autograder output.
Your report should focus primarily on whether the design allows an adversary to get more votes than more votes than the number of times a smartcard is inserted into the legitimate encoder under the set of assumptions from homework 4.
As a secondary task, you should also consider the vulnerability of the design to more sophisticated attacks than allowed in homework 4. For example, a more sophisticated adversary might employ a shim that can intercept or modify traffic between legitimate devices. With such a shim, the adversary will be able to log transactions between legitimate devices, pre-emptively abort communication, or alter some small set of bits being passed betwen devices. An especially well equipped adversary may have a bogus smartcard with wifi connectivity, allowing them to remotely interact with the real machines in real time. An adversary with even more time and money may be able to steal a real smartcard and extract the contents of persistent memory using a technique such as those discussed in this paper. In the worst case, an adversary might even be able to steal an Encoder or Voting Machine and be able to extract all of its secrets.
As part of this secondary task, design the simplest possible attack that would allow the adversary to get more votes than insertions into a legitimate encoder. For the purposes of this exercise, assume that reading a SmartCard's persistent memory is the 2nd most difficult attack, and that getting access to MachineSecrets and EncoderSecrets is the most difficult attack. You might also consider how difficult it would be to react to a one-time compromise (e.g. would you have to reprogram every single encoder, voting machine, and smartcard in the whole country?).
Other things to look out for include unnecessary usage of slow algorithms (e.g. unnecessarily using RSA instead of symmetric kry cryptography), unrealistic usage of TrueRandomness (e.g. having the SmartCard call RSAKey's encrypt method, which requires a call to TrueRandomness), and exploits that allow an adversary to crash the encoder or voting machine. Note that we will not be counting off for these things when grading assignment 4.
An example design review from the Fall 2010 offering of this course can be found here.
Your solution should be submitted in either pdf or HTML format. If you're using pdf format, please name your report submit5.pdf. If you're using HTML, please package everything you're submitting into a single zip-file, called submit5.zip. Also, as per the design review description above, please post your meeting time as a private note on Piazza with the tag "#hw5meeting" and please note that all design meetings should be facilitated by an instructor.
If you're using HTML, the report should be an HTML file named index.html. (It may contain images, links to other files, etc. if you include those files in your submission.) Your solution will be graded on the basis of content alone (e.g. you do not have to: design something really nice looking, use css, include images, have MIDI files playing in the background, etc.).
For this assignment, you must work in the same group that you worked in for assignment 4. You may not collaborate with anyone outside your group.
Your report can be submitted using this link.