This activity consists of four phases: (1) team-up; (2) development; (3) backdoor insertion; and (4) code auditing. The overall schedule can be adjusted based on the progress of the teams.
At a high-level each team will develop a CA service, and insert two backdoors in their own service. One backdoor should be obvious and easy to spot, and the other one should be difficult to find. We are going to call them easy backdoor and difficult backdoor, respectively. After the insertion phase, we will upload each team's code to a public area by deleting all the commit logs. Next, in the code auditing phase, each team will try to find backdoors from other team's services. In the end, each team will submit a proof for each of the backdoors they found.
We distinguish between an easy and a difficult backdoor because we want to make sure that each team can find at least one backdoor from each of the other teams. For easy backdoors, instructors will manually check all of them and adjust their difficult level. For difficult backdoors, each team should try their best to hide them. Each team will get scores based on the number of backdoors found. So as you make your difficult backdoor really difficult to find, you will relatively get better score than the other teams.
You should use C, C++, or Python to develop your system.
Meet your team members. Every team should create their team's PGP key, and every
member of the team should sign the team key. Upload your team key to our
course's main repository with a Pull Request. The key should be placed in the
/TeamKey directory.
Your goal here is to create a CA service, which helps its users publish a certificate through a simple interface (either web or command-line interface is acceptable). In this activity, a certificate is a signed PGP key by the CA service. Users can register their own PGP keys through an interface, and download a signed PGP key from the service. In other words, we consider the CA's key (i.e., your team key), as a root certificate.
The CA should provide at least the following features to its users.
-
A registered user can authenticate to the system interface: you can create any kind of interface, e.g., web interface, RESTful APIs, etc.
-
A registered (and authenticated) user should be able to upload their PGP key. If there is already an existing one, the uploaded one will replace the old one. The service should not throw away old PGP keys though. It should store old the old/new keys in an archive, i.e., a file system or a DB.
-
A registered (and authenticated) user should be able to download a certificate from the service, which basically contains the user's key signed by the CA service and the information about the user. You can create your own format or use an existing certificate format such as PKCS. However, it would be easier to create your own format for the purpose of this activity.
-
A registered (and authenticated) user can change their basic information, such as their email address, which will be stored in the database of the service.
-
A registered (and authenticated) user can revoke their key. The revoked key will be appended to the certificate revocation list (either in a DB or a file system).
-
Any users should be able to see the revocation list.
-
Any user can upload a certificate issued by the CA, and verify whether the certificate is valid. If the provided certificate does not follow the specific format, the service should emit a proper error message. Also the verification process should consider the revocation list.
Each team should create a test script that can test all the features listed
above. For example, if you are creating a web service, then you should provide a
curl-based script that can test all these features.
Each team will use the same registered user dataset to create their DB. This does not mean that you should use a certain method for implementing the database: you are completely free to use any kinds of database. For example, you can simply use your file system as a database. In any case, each team should use the following user dataset.
| UID | LASTNAME | FIRSTNAME | PASSWD | |
|---|---|---|---|---|
| eliz | Elizabeth | Welter | [email protected] | 1a9bb892d2beec91beaf415025f5e109bad6081f |
| seger | Seger | George | [email protected] | 9b08b0357d2f1d34ecf42dfd9bc5001733fca132 |
| kung | Kung | Qiang | [email protected] | 647f8e8c95e4cfc7254cf3dc7bb4f79b97d12712 |
The PASSWD field contains SHA-1 sum of the following passwords:
$ echo -en uNaiph9e | sha1sum
1a9bb892d2beec91beaf415025f5e109bad6081f -
$ echo -en aoBai9yu | sha1sum
9b08b0357d2f1d34ecf42dfd9bc5001733fca132 -
$ echo -en Shoo8pie | sha1sum
647f8e8c95e4cfc7254cf3dc7bb4f79b97d12712 -
You should not modify the above data, but you can freely add more data into your DB if you want.
At the end of the development phase, we expect your repository to include a Dockerfile as well as a build script for creating a Docker image.
Each team insert both easy and difficult backdoor in their own service. Since you are going to work on a private repository and we are not going to open your commit logs, you should clearly indicate how you implement your backdoors in your commit logs.
A backdoor is similar to a vulnerability in that it allows a non-privileged user to access the entire system. However, the main difference is that backdoors are intended by the developer, whereas vulnerabilities are not. In this activity, a backdoor should allow an arbitrary user to get certificate of an arbitrary person (e.g., a certificate of Elizabeth).
In this phase, you will read other teams' code and try to find backdoors (or
vulnerabilities). We expect each team will get at least N backdoors from this
phase, where N is (the number of teams - 1), because there should be at least
one easy backdoor from each team. However, there is no maximum number of
possible backdoors (vulnerabilities) that you can find because we controlled the
number of backdoors, but not the number of vulnerabilities. There may be some
unintended vulnerabilities in the services you created.
You should create a proof for each backdoor (or vulnerability) you found. Specifically, you should show a concrete demonstration (live demo) during your final presentation.
We will give extra points for those team who discovered vulnerabilities. If you found a DoS (Denial Of Service) vulnerability, you will still receive some extra points although you cannot successfully obtain a non-privileged certificate.
We will periodically meet and have a meeting with students. Please read the syllabus carefully. We will add an independent activity document for each scheduled meeting.