6.857: Computer and Network Security (Spring 2017)

Term Project Ideas

Project ideas for Spring 2017

We'd be happy if some of these strike your fancy, but you absolutely don't have to stick to this list. Also, we will be adding to the list as time passes, so check back from time to time. If you have ideas of your own, we'd be excited to hear about them: post them on Piazza or email Sunoo (at mit dot edu) if you want set up a time to chat about your ideas!

You should not consider projects on this list to be "pre-approved" by us (or necessarily more than half-baked). They will require your creativity to develop the ideas and investigate whether they will build up to a solid project. Your project proposal should demonstrate that you've put thought into developing the project beyond the blurbs written on this website!

We really encourage you to start thinking about project ideas early (like now!!), and are totally happy to chat about half-baked ideas too. Note that depending on the type of project, it may be fine for multiple groups to work on the same project. However, in some cases—e.g., when working with companies—there would only be able to be one group per project. In such cases the course staff will allocate projects at our discretion on a roughly first-come first-served basis, so we suggest thinking about project possibilities early, and be sure to let us know as you develop an interest in a specific project. Project suggestions that a team has already expressed interest in (and for which we are not allowing multiple teams) are grayed out in the list below.

Be sure to read the sections beneath the project idea descriptions too, as they contain important information about getting permission to do projects.

  1. Argon2, a memory-hard hash function
  2. Bitcoin Lightning network
  3. Boston Symphony Orchestra app
  4. Censorship-resistant file storage
  5. Container security
  6. "Customs-proof" device security (or: how to get your phone through customs safely)
  7. Encrypted Media Extensions (for DRM) in HTML5
  8. Ethereum smart contract security
  9. HackerOne bug bounties
  10. Internet-of-Things (IoT) security
  11. Kleptography (planting malware in encryption key generation)
  12. [new, 27 Feb] Let's Encrypt (certificate authority) — 4 project suggestions:
    • Measuring web PKI usability
    • Trillian (certificate transparency)
    • Certificate Authority Authorization crawl
    • Bulk GCD computation for finding and rejecting weak RSA keys
  13. Preveil encrypted email
  14. Privacy-preserving loyalty cards
  15. Quantum computing
  16. Ransomware
  17. Secure whistleblowing / journalism
  18. Self-driving cars
  19. [new, 20 Mar] Toast (that app that many restaurants and cafes use for payments)
  20. [new, 20 Mar] TUF: The Update Framework
  21. WhatsApp/Signal
  22. Snapchat
  23. [new, 8 Mar] Wikileaks exploits of March 7th, 2017
  24. Wireguard VPN

Slightly more detailed descriptions:

  1. Argon2, a memory-hard hash function: A memory-hard hash function is supposed to require any algorithm to use certain amount of memory while evaluating the hash function. A little over a year ago, theoretical attacks (i.e., ways to evaluate the function using less memory than intended) were discovered which aren't efficient enough to deploy in practice. There was subsequently some tension between those who believed that existence of a theoretical vulnerability means using or standardizing Argon2 would be inadvisable/dangerous, and others who favored standardizing Argon2, thinking variously that the attack could be mitigated or was not practically relevant. An interesting project would be to see if you can adapt the attacks to make them more efficient (or come up with your own attacks).
  2. Bitcoin Lightning network*: The Lightning network is a set of nodes linked by 2-party payment channels built from Bitcoin smart contracts. The software is currently being built out and initially tested on the Bitcoin Testnet. This project would involve looking for unknown / undocumented vulnerabilities in the lightning software and specifications. There is a wide range of potential vulnerabilities, covering novel cryptographic constructions, DoS-vulnerable communications, synchronization issues, key management, and database integrity issues. There are also novel user experience vulnerabilities due to the novel nature of the system: making backups can cause loss of funds! This project would have support from the current lead programmer who works at the Media Lab and can meet with your team and discuss the code. As the code is currently under development, your contributions would be quickly incorporated into the code and design specifications.
  3. Boston Symphony Orchestra app*: The BSO is in the process of completing development of a tablet app for iPad and Android devices and would like a security analysis of their app. Some key features of the app that you might analyze: user login/authentication; purchasing tickets/subscriptions/donations using credit card; account creation/management; auto-login; "one-click" purchases; app lock feature using a 4-digit PIN; social media features; push notifications using beacons installed within Symphony Hall; and content delivery based on image recognition. BSO is supportive of this project (and in fact, supported a different 6.857 project last year) but cannot provide access to the source code and databases, so this will be an exercise in penetration testing.
  4. Censorship/subpoena-resistant file storage: A judge can issue a subpoena to a company or person within their jurisdiction, compelling the target of the subpoena to produce a document that is known to be in their possession (or within their power to produce), when it is deemed to be in the interest of enforcing the law or national security. This can be worrying in areas that do not respect the rule of law, or where abuses of power are likely. However, it is far more difficult for the judges and courts in one jurisdiction to obtain information that is under the control of an entity that is located in another jurisdiction. Similarly, it is difficult for authorities in one jurisdiction to impose their censorship constraints upon entities in different jurisdictions. How might you design a file-storage system such that no set of entities in a single jurisdiction is empowered to hand over to authorities or take down stored data, while maintaining reasonable availability/integrity/privacy guarantees?
  5. Container security: Many applications are now fielded via "containers", such as that provided by Docker. The security of such containers was initially pretty poor, but has recently gotten much better. How good is container security now? (The course staff may be able to provide a contact within Docker to liaise with.)
  6. "Customs-proof" device security: Especially in the last few weeks, there has been some popular buzz about how to get through customs while protecting your digital data, e.g., this Wired article. (As you read the article, ask yourself how effective you believe the methods would really be, and how feasible for an average phone user to pull off.) Can you come up with innovative / more convenient / more effective solutions for this problem?
  7. Encrypted Media Extensions (EME) in HTML5: EME is a controversial W3C draft spec for integrating digital rights management (DRM) with HTML5, e.g., allowing HTML5 video to play DRM-protected content without third-party plugins like Flash or Silverlight. EME is particularly controversial for introducing a proprietary component into an otherwise open/free software ecosystem. Potential project directions include looking for technical vulnerabilities in the EME proposal, and/or exploring alternative solutions that might address some of the criticism of EME. Further reading: a recent summary from Ars Technica; what W3C has to say about EME (here); and a perspective from EME's opponents (here).
  8. Ethereum smart contracts: Ethereum is the blockchain-based cryptocurrency with second-largest market cap after Bitcoin, and it is known for its flexible smart contracts. Users can set up smart contracts to govern the transfer of their cryptocurrency, and so hacking a smart contract can result in financial gains and losses. Indeed, this happened at an epic scale last year in "The DAO" incident, where a huge crowdfunded project suffered a $60 million hack soon after launch (more details here). Project directions could include surveying potential vulnerabilities of smart contracts and developing methods to insure against failures.
  9. HackerOne bug bounty program: Investigate how well their bug bounty and vulnerability coordination program works.
  10. Internet-of-Things security: Security of Internet-of-Things (IoT) devices is becoming increasingly important as they become more prevalent, and especially because some IoT devices have access to potentially very sensitive streams of data, e.g., inside one's home. Stories of interesting IoT vulnerabilities abound, ranging from getting into a neighbor's house by seeing their iPhone through the living room window and yelling "Siri, open the front door!" from outside, to remotely flickering all the (wifi-connected) lightbulbs in a large office building by flying a drone nearby (article and video here). We'd be interested to see your ideas about security analyses of specific IoT devices. Another interesting project direction could be exploring methods to mitigate the potential for IoT vulnerabilities to explode into massive-scale outages or attacks, given the connectivity and ubiquity of IoT devices.
  11. Kleptography for post-quantum cryptosystems: A kleptographic implementation of a public-key encryption scheme has malware in the key-generation algorithm, so that the adversary can easily figure out the secret key, given only the generated public key (and perhaps knowledge of parameters in the malware). For example, an RSA key generation scheme might use the public exponent e (a 128-bit number, say), as a PRNG seed to generate the primes p and q. The adversary, seeing e, can then figure out p and q. Kleptography was introduced in 1996, but many public-key encryption schemes have been introduced since then, and not all of them have been analyzed for potential kleptographic attacks. The project idea is to analyze recent proposals of encryption schemes that haven't yet been kleptographically analyzed, and try to find kleptographic attacks! Initial reading could include the original paper on kleptography, and the book by the same authors (available in the library).
  12. Let's Encrypt* is a new certificate authority (launched 2016) that aims to provide free and easy-to-use SSL/TLS certificates, changing the pre-existing landscape where it is complex process to set up certificates for a secure website. Sponsored by an array of reputable names (EFF, Mozilla, Cisco, Google, Facebook... to name a few), it's been growing fast and now supports over 20 million active certificates. There is potential for a few different project directions here (which were suggested by and would be supported by folks at Let's Encrypt); each bullet below is a separate project suggestion.
    • Measuring Web PKI usability improvements. Let's Encrypt aims to improve the usability of deploying HTTPS by allowing it to be automated. This is supposed to achieve two things: (a) Making expiration errors rarer by automating renewal, and (b) making configuration errors rarer by providing tools (Certbot) that configure web servers correctly on behalf of the server administrator. Measure success on these two metrics. Because Let's Encrypt logs everything to CT, it's easy to get a list of all issued certificates. You can measure gaps in certificate validity as a proxy for forgetting to renew / failed automation. You can also scan the resulting names on port 443 looking for basic configuration errors, like failing to include an intermediate.
    • Trillian is a next-generation Merkle-tree service for use with Certificate Transparency. It's not yet in production but soon it will be an important part of the Web PKI. Find bugs (security or non-) in it. Performance test it.
    • Fuzz OpenSSL. OpenSSL is the most widely used library for TLS, so vulnerabilities are extremely impactful. There is already some fuzzing code in the repo (here). Run the fuzzer with the goal of (a) finding crashes and test cases, (b) making the fuzzer easier to run, and (c) automating the fuzzer so it runs on every new commit.
    • Certificate Authority Authorization (CAA) was standardized in 2013 but has seen limited use. It will very soon become mandatory for CAs in the Web PKI to check, enforced by a ballot of the CA/Browser Forum. It would be useful to do an Internet-wide scan or crawl determining (a) the prevalence of CAA records today, (b) how many DNS servers are intolerant of CAA queries and return error or timeout (and who manufactures those), and (c) of the CAA records that exist today, what do they specify?
    • Implementing very fast bulk GCD computation for RSA keys: this could provide a way for Let's Encrypt to find and reject more weak keys at request time. The Let's Encrypt team is interested in a Go implementation (the course staff can provide a similar implementation in C).
  13. Preveil*: Preveil is an end-to-end encryption suite encompassing email and file sharing that aims to combine security with usability. The company is in early stages, and was founded by MIT alumna Raluca Popa who is now a professor at UC Berkeley, in collaboration with MIT professor Nickolai Zeldovich and others. The Preveil team would be supportive of a project to do a security review of Preveil and will provide access to the source code under a licensing agreement (to view and analyze but not use or distribute). Note that the analysis would be for secure email (not file-sharing or chat), as the other features are not available yet.
  14. Privacy-preserving loyalty cards: Prototype a privacy-preserving loyalty card scheme, whereby a company could gather certain data useful to them without necessarily tracking every single detail of consumption habits (as is often done today), and customers would get rewards points while having some amount privacy assurance. (Note that the "ten stamps and your next coffee is free" type of loyalty card has great privacy properties, but gives companies little to no useful data about how to improve their services for customers. Perhaps your scheme could allocate different amounts of rewards points depending on the level of privacy that customers choose!)
  15. Quantum computing: IBM has released an "experimental cloud-enabled quantum computing platform". Can you realize some quantum attacks on encryption schemes, or use the platform in other interesting ways to make or break cryptographic schemes? We're open to creative project ideas to "get your feet wet" doing some real quantum computation, not necessarily in a cryptographic context.
  16. Ransomware: Research existing ransomware and see if you can devise novel preventive measures or other solutions to thwart ransomware. (Some initial food for thought: how about ransomware insurance?)
  17. Secure tips for journalists: SecureDrop is an "open-source whistleblower submission system" which is one of the suggested methods to submit sensitive tips to the New York Times. According to the NYT, "SecureDrop is regularly audited by independent security experts. Like all software, it could have security bugs that are exploitable. Ultimately, you use the service at your own risk." Project directions could include examining SecureDrop for vulnerabilities and/or reviewing how SecureDrop (and other available alternatives) work towards developing recommendations or novel solutions for secure and anonymous communication by (non technically expert) journalists and tipsters.
  18. Self-driving cars: Security issues in self-driving cars will become increasingly important as the technology becomes more widespread, and may often be safety-critical. Interaction between cars on the road is also a complex issue. There are many interesting questions to think about in this space. Some examples include the security benefits and risks of automated updates to self-driving cars, how "manual override" mechanisms might work, and the potential for remote access to or control of cars by law enforcement and/or hackers (in a targeted way, or at massive scale).
  19. Toast is a commonly used app for checkout at restaurants and cafes. A security evalutaion of Toast could be an interesting project, both in terms of looking for security vulnerabilities, and analyzing privacy considerations relevant to Toast (e.g., what information is stored? what information is stored when a receipt is requested by phone/email/printout? what information is printed on receipts?).
  20. TUF: The Update Framework is concerned with the security of software updates even when code-signing keys are compromised. A security evaluation of TUF could be an interesting project!
  21. WhatsApp / Signal: We saw in Problem Set 1 that while the Signal protocol has been acclaimed for its end-to-end encryption, WhatsApp's very similar encrypted messaging implementation had a potential vulnerability that went unnoticed for months. A project might further investigate the security properties of either WhatsApp or Signal, or alternatively, examine methods to avoid or flag small variations in implementation that could have (un)intended consequences for security.
  22. Snapchat*: Analyze the Snapchat app for potential security vulnerabilities. This project will have collaboration and support from the Snapchat team.
  23. Wikileaks has just published a trove of CIA hacking tools. It would be an interesting project to test and evaluate one or two of these. If you are interested in this project, let the course staff know and we will provide advice on a specific project plan (with a view to avoiding any potential legal issues).
  24. Wireguard VPN*: Wireguard is a new VPN system interested in a security analysis towards finding any crypto/protocol mistakes. It currently calls itself a "work in progress" but will be going into the next Openwrt/LEDE release and is hoping to someday be in mainline Linux—so they're very interested in getting lots of eyes to look at it while it's still easy to fix any problems! You'll get to work with the source code: all ~4000 lines of it, which are on github.

Important: Getting permission for security analyses

As discussed in the first course handout, it is important when conducting security analyses to obtain the permission of the company or owner. Security analysis projects will not be permitted to go ahead unless you have obtained appropriate permission by the project proposal deadline, March 24th. For the projects listed above which are asterisked, we have already communicated with the relevant companies/organizations and the project ideas are posted with their consent.

If you are thinking of your own security analysis project (or a non-asterisked one from the list), you should contact the relevant organization to get their permission: here is a draft email template to help you. Once you have an idea you're definitely interested in, we suggest sending an email ASAP, so that you have plenty of time to make alternative plans if getting permission doesn't work out! If you are planning to send an email regarding one of the non-asterisked projects above, please inform the course staff first so that we can avoid duplicate emails being sent.

In general, if you're getting really into one of the project ideas, let the course staff know. We may help you find teammates and/or provide links to useful reading or other resources, and it will help us to keep track of who is interested in what.

Other places to look for ideas

You should also check out the references page for inspiration—in particular, online proceedings from the linked conferences.

Topics from previous years

It may also be useful to refer to projects from previous years, which you can view on the corresponding course websites since 2014 (accessible through the "Previous Years" link in the sidebar).

Hints for writing your paper and giving your talk