CY 2550 - Foundations of Cybersecurity

Project: Cryptography

This project is due at 11:59pm on Friday, February 12, 2021.

Description and Deliverables

Every self-respecting infosec person should have a PGP (Pretty Good Privacy) keypair, so that other infosec people can send them strongly encrypted messages. In this project, you will generate a keypair for yourself, and learn the basics of how to generate, sign, and manage PGP keys, as well as encrypt and sign messages.

To receive full credit for this project, you will turn in two files and complete two actions online:

  1. A file named project2/key.pub that includes your public key in ASCII format. Your public key must meet the following four requirements:
    1. Use RSA encryption and be 4096 bits long
    2. Include your name and Northeastern email address
    3. Be signed by at least two of your classmates
    4. Include your picture.
  2. A file named project2/message.txt.asc that is encrypted using the class public key and signed by your private key. The unencrypted message.txt file should be in plain ASCII format (no Word or PDF docs), and contain (1) your first and last name, (2) your Github username, and (3) the string "CY2550". For example, a valid message.txt might look like this:
    Christo Wilson bowlinearl CY2550
  3. Create a Keybase profile that has the your PGP key from item (1) and follows at least two people in the class.
  4. Add an SSH public key to your Github profile.

Phase 1: GPG

There are many tools that support the PGP standard. In the remainder of this document we will provide a brief tutorial for using GNU Privacy Guard (GnuPG, or simply GPG), which is a free, open-source, command line implementation of PGP. You are welcome to use other tools if you wish, so long as they offer the necessary features to complete all the requirements of the project.

To install GPG under a Debian-based Linux distro, simply run:

$ sudo apt install gnupg
On recent Linux distributions, such as Ubuntu 20.04, this will install GPG version 2, which is what this assignment will assume you are using. On older Linux distributions, such as Ubuntu 16.04, version 2 of GPG can be installed via the "gnupg2" package instead (note that this method also changes the command to invoke GPG from "gpg" to "gpg2"). Other installation options for Linux, Windows, and macOS are available on the GnuPG homepage.

GPG Tutorial

There are a number of useful command line arguments for GPG that you will need to complete this assignment. If you ever get stuck, you can always type

$ gpg --help
to see a list of common command line arguments, or
$ man gpg
to open up the manual page for GPG. Alternatively, you can Google "man gpg" to find an online version of the manual page.

$ gpg --full-gen-key
is the command to generate a new keypair. The --full modifier lets you choose your encryption algorithm and key length; if you use the abbreviated --gen-key command you will not be given these options and the default algorithm/key length will be used. Note: you are welcome to choose an expiration date for your keypair if you want to, but make sure your keypair will not expire until the end of the semester at least!

$ gpg --edit-key <UID>
allows you to change aspects of the key with given UID. This commands drops you into an interactive mode with many commands, which can be listed by typing "help". Commands that might be useful for this project include "addphoto" and "sign". When you're done editing a key, type "quit". You'll probably want to edit your key before you export it and get it signed by your classmates.

$ gpg --list-keys
$ gpg --list-sigs
$ gpg --check-sigs
all show the keys in your keyring. The first shows the keys, the second also shows their signatures (if they have any), and the last attempts to verify the signatures. Of course, you can only verify a signature from user X if you have imported a copy of X's public key.

$ gpg --import <file>
is the command to import key material from the given file. This will be very useful, since you'll need to import the class GPG public key, as well as public keys from your classmates (so you can sign them).

$ gpg --armor --export <UID>
is the command to export the public key with the given UID from your keyring. You'll need to export your public key so that you can give it to your classmates and receive their signatures. You'll also need to export your classmates' public keys after you sign them. Strangely, GPG prefers to output things in binary format, which is not particularly useful, so you almost always want to add the ASCII "armor" command line option.

$ gpg --armor --export-secret-keys
is the command to export all of your private keys. YOU SHOULD NEVER SHARE YOUR PRIVATE KEYS WITH ANYONE. THAT IS WHY THEY ARE CALLED PRIVATE KEYS. However, backing up your private keys is a good idea, possibly to a removable USB drive that you keep in a locked safe, or to a Yubikey.

$ gpg --armor --sign <file>
is the command to sign the given file using your private key. By default, GPG creates a new file with a ".asc" extension containing the ASCII armored, signed message.

$ gpg --armor --recipient <UID> --encrypt <file>
is the command to encrypt the given file for the given recipient. Obviously, you can't encrypt something for someone if you don't have their public key. Just as with signing, GPG produces a new file with a ".asc" extension containing the ASCII armored, encrypted file. Note that in this assignment you will need to sign and encrypt a file for me, which means you may need to combine command line arguments to produce the correct output.

$ gpg --decrypt <file>
is the command to decrypt the given file (and verify its signature, if one is present). Obviously, you can only decrypt a file if you hold the corresponding private key.

$ gpg --default-key <UID>
By default, GPG always uses the first private key in the keyring for signing, encryption, and decryption. If you have multiple private keys, this is the optional command line argument you need to select one other than the default when performing operations.

WARNING: Back Up Your GPG Private Key

In the past, over 1/3 of students in the course lost access to their private key throughout the semester. This happened for a variety of reasons, including people choosing short expiration times for their keys, or because they used GPG inside a VM and the VM failed/became unbootable. You will need the GPG keypair you generate during this project multiple times over the course of the semester. Thus, it is critical that you not lose your keys! You should make a backup of your private key, using the gpg --armor --export-secret-keys command, and store the backup in a secure, reliable location. Do not store your backup inside a VM!.

What You Need to Do

  1. Create a keypair for yourself that uses RSA encryption, uses 4096 bit key, and includes your name and @northeastern.edu email address.
  2. Add your picture to your keypair.
  3. Export your public key in ASCII armor format to a file and get two of your classmates to sign it. Don't forget to import these signatures!
  4. You will probably need to sign your classmates public keys as well. This involves getting a copy of their public key, importing it into GPG, signing it, exporting it in ASCII Armor format, and sending the signed key back to them.
  5. Export your public key in ASCII Armor format one last time (i.e., after it has been signed by two of your classmates) to a file named key.pub. You will turn in this file.
  6. Produce a file named message.txt.asc that is encrypted to the class public key and signed by your private key. The unencrypted message.txt file should be in plain ASCII format that contains (1) your first and last name, (2) your Github user name, and (3) the string "CY2550". For example, a valid message.txt might look like this:
    Christo Wilson bowlinearl CY2550
    Note, your file needs to be "signed and encrypted" in the terminology of GPG. Be careful how you do this step; you will need to carefully read the GPG documentation to figure out how to do this. Use man gpg and gpg --help as well as internet resources to figure out how to do this. Part of this assignment's goal is to encourage you to learn how to use these programs given only the documentation.

Phase 2: Keybase

The first part of this project introduced you to the classical way of setting up your public key using a "web of trust" to help bind your identity to your key by having your friends sign your key. But can such a scheme scale to handle billions of people on the internet?

The Keybase platform is a modern take on how to establish internet-scale identity. Keybase is an application platform that augments PGP with the ability to bind your key to public identities such as (a) your Twitter account, (b) your Github account, (c) a Reddit account, etc. Keybase makes it simple to download someone else's key, verify that it is them by checking their Twitter/Github/etc. account, and then send them encrypted or signed messages. Recently, it uses this infrastructure to build applications such as secure group chat, secure git hosting, and secure file sharing.

You can see Professor Wilson's Keybase profile at https://keybase.io/christowilson and import his PGP key using:

$ curl https://keybase.io/christowilson/pgp_keys.asc | gpg --import

What You Need to Do

  1. If you don't already have one, create an account for yourself on Keybase.
  2. Add your PGP public key from Phase 1 to your account.
  3. Link your Keybase account to your Github account (and your other accounts, if you want to).
  4. Follow at least two other people in the class on Keybase and verify that their PGP keys correspond to their identity. For example, you could follow Professor Wilson.

Phase 3: SSH and Github

The ssh program is a "secure shell" that allows you to remotely access another machine over an encrypted channel. SSH uses public key cryptography to authenticate the remote user and to encrypt the communication channel between the remote user and the machine (i.e., so that the commands you type and the responses are encrypted). SSH can also be used to authenticate and submit a commit to Github.

In this part of the project, you will create an SSH key and submit it to Github so that your future commits can be authenticated by your key instead of your username/password.You can do this on your local operating system or in your Linux VM. Later assignments will require you to ssh into machines using your key, so it is critical that you not lose your SSH keypair.

WARNING: Back Up Your SSH Keypair

You will need the SSH keypair you generate during this project multiple times over the course of the semester. Thus, it is critical that you not lose your keys! You should make a backup of your keys by copying them to a secure, reliable location. Do not store your backup inside a VM!.

The first step is to generate a new SSH key locally. Use the ssh-keygen program to do this:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cbw/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/cbw/.ssh/id_rsa.
Your public key has been saved in /home/cbw/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:BUDkayXlQGAMiw4RXPaJuiCPEqjQAbfeu7GEZo2W/sM cbw@x1-laptop
The key's randomart image is:
+---[RSA 3072]----+
|=.+=o=*.o        |
| *.++..+ .       |
|o +. oo o .      |
|+o.o   + .       |
|*oo . o S        |
|=+.= o           |
|+.O.=            |
|.= .E+           |
|  ..+.           |
+----[SHA256]-----+
You will be creating an RSA key. You do not need to set a passphrase (not having a passphrase makes SSH much more convenient, but does make your key less secure). ssh-keygen will ask you where to save the key (it is fine to use the default value here and press "Enter"). Note that the default location is in a folder named .ssh in your home directory.

Your next step is to install your public SSH key into your Github account. To do this, log in to your Github account, click on your login picture on the top-right corner, click on "Settings", then select the "SSH and GPG keys" menu on the left. Click the green "New SSH key" button on the top, and then you will be prompted to enter a title and key. Please use the words "cy2550 key" (without quotes) as the title so that we can find your key. Copy/paste your public SSH key into the key area. Recall that, by default, your public SSH key is stored at /home/your-username/.ssh/id_rsa.pub. It looks like this:

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDXxRZ/LofJkr0SP1bA91lXyLMDdmcI8Tw4nvXIDOpft0+VHJFWjtR3k6ll+bHNHEoEZJlnPZ7/hrXvct21l1ZM/OYx12CmCl5zwoTGXkFW0aYn/C41TGWWlBfvWiFCtzy27/ZmbSvW+uWv/48laBj84BJ4S3rIMPvEzmXrZ40TbyhS4vZvAZmixGbzM+4DBxCie8Py7XN9UTsU7Z0M4qda1yIxj47h3AXniDJSNTNb5y+Nn5C/cLZNiZ0HRj8aTmNR1klhHlAYkxt4ZeMlG/Ahymu+yBxyNuDIQrBuHnPl161ciIKLLWe0V9QmTastBxZPqxctv7Xje8SaixJBsimsFC8qxriv8tmtumy1ifhfj6ahxaeII9vXULsK7eT6GtgjToMA4znxWbgdufjWYtJko4xgmWioSefjzKO2mXimhC+rLzHNKIptwHGf13dlaz/aGPW/AyurhJQFr9NO3aaO0S1HFSIis+gqcbcVHvBeAx15/ajXAsh99mY5uiztV3YaNPweOvtd9J0rkZxvPy9hm9Lk8wlMPCqFETDQPKaBebm1JfqoLayFFtq06u/wLnNA403grBBRBQbN/917pL7KG5sK8hiivzW1jtzyTlLzfgulGM/51BeVLAa2nog0RxdwO/MveLjMyY1tIk3WCoVjn+5c0gVeuyOavvgt9xnehw== cbw@ativ9
Copy your own SSH public key into the window and then click "Add Key". This will enable you to access your Github via SSH without having to supply your username/password. To test whether this worked, from the shell, you can try the following:
$ ssh -T git@github.com
Hi bowlinearl! You've successfully authenticated, but GitHub does not provide shell access.

Submitting Your Project

  1. Create a directory ~/cy2550/project2 in the folder corresponding to your git repository.
  2. Copy the files key.pub (i.e., your signed GPG public key) and message.txt.asc to the ~/cy2550/project2 directory.
  3. Add these files to your repository, commit them, and push the committed files to Github.
  4. Submit your repository to Gradescope.
You can update your files as many times as you like before the deadline. Just makes your changes locally, add them to another commit, and push to GitHub.

Grading

This project is worth 5% of your final grade, broken down as follows (out of 100): Points can be lost for turning in files in incorrect formats (e.g. not ASCII), failing to follow specified formatting or naming conventions, having signatures that do not verify, encrypting messages using the wrong keys, etc.

Tips