6.857: Computer and Network Security (Spring 2018)

Term Project Ideas

Project ideas for Spring 2018

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 us (6.857-tas 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. Also, take a look at the projects from previous years to get ideas for what you can do. It is acceptable to work on a projects which have been done before as long as your project is sufficiently different/ novel.

  1. Container security
  2. "Customs-proof" device security (or: how to get your phone through customs safely)
  3. Encrypted Media Extensions (for DRM) in HTML5
  4. HackerOne bug bounties
  5. Kleptography (planting malware in encryption key generation)
  6. Let's Encrypt (certificate authority) — 4 project suggestions:
    • Measuring web PKI usability
    • Trillian (certificate transparency)
    • Certificate Authority Authorization crawl
  7. Quantum computing
  8. Secure whistleblowing / journalism
  9. Self-driving cars
  10. Toast (that app that many restaurants and cafes use for payments)
  11. TUF: The Update Framework
  12. WhatsApp/Signal
  13. Wikileaks exploits of March 7th, 2017
  14. Wireguard VPN

Slightly more detailed descriptions:

  1. 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.)
  2. "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?
  3. 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).
  4. HackerOne bug bounty program: Investigate how well their bug bounty and vulnerability coordination program works.
  5. 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).
  6. 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?
  7. 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.
  8. 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.
  9. 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).
  10. 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?).
  11. 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!
  12. 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.
  13. 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).
  14. 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