Computer Security Coursework Exercise 2
February 16, 2021
In this coursework we will touch upon a number of security-related topics, namely encrypting and decrypting with GPG, spoofing the sender of an email and performing a MitM attack. The deadline is 8 March 2020, 16:00.
1 Asymmetric Encryption with GPG
In this section you will learn to use GPG for day-to-day usage, most importantly including signing and verifying signatures. You will also have to prove your knowledge by solving a challenge. GPG (sometimes written as GnuPG) is the GNU Privacy Guard. GPG is an open source implementation of the OpenPGP standard for asymmetric encryption.
1.1 Introduction to GPG
The purpose of this part is to familiarise yourself with the GPG tool. You will see how to receive the public keys of other people and use them for encryption and signature verification. You will also learn how to generate private keys and use them for signing and decryption. The instructions that follow are specific for DICE machines, but should work on any Linux machine with slight variations. They should also work on MacOS machines with minimal adaptation. There exist some ports of GPG for Windows, but they are not supported in this coursework. If you prefer you can solve the exercise using only the terminal, so access to DICE using ssh should be sufficient.
1.1.1 Verifying Signatures
Verifying the integrity of software you download is important to ensure that your software hasn’t been tampered with. This section will show you how to verify signatures if they are available. Your task is to download the Alpine Linux mini root filesystem armv71 and the corresponding signature2 and verify it. Save the contents of the second link to a file. You should place both files in the same directory. The names of the files are important: the signature must have the same name as the file it signs, with the added extension ‘.asc’.
Before you can verify the signature however, you need to import the public key which was used to make it. These are also available from the Alpine Linux download page3. The fingerprint of the signing public key is 0482 D840 22F5 2DF1 C4E7 CD43 293A CD09 07D9 495A. More on what a fingerprint is later. To receive the public key, execute:
This could take a while. You should see a report of the key which was imported. Next, to verify the file itself, go to the directory where you downloaded the files and run:
1 http://dl- cdn.alpinelinux.org/alpine/v3.11/releases/armv7/alpine- minirootfs- 3.11.3- armv7.tar. gz
2 http://dl- cdn.alpinelinux.org/alpine/v3.11/releases/armv7/alpine- minirootfs- 3.11.3- armv7.tar. gz.asc
3 https://alpinelinux.org/downloads/
gpg –recv-key ‘0482 D840 22F5 2DF1 C4E7 CD43 293A CD09 07D9 495A’
1
gpg –verify alpine-minirootfs-3.11.3-armv7.tar.gz.asc
Youshouldseealinestating‘Good signature from
Keep in mind that the aforementioned steps do not rule out completely the possibility of a Man in the Middle attack. An attacker could hijack the legitimate site, replace the original public keys with his own, put a backdoor in the provided source code and sign it with his key. GPG itself can only rule out such attacks if you have out-of-band reasons to trust the validity of the provided fingerprint. Such an out-of-band reason is the acknowledgement that the website itself is valid through TLS security.
1.1.2 Generating a Keypair
In order to sign or receive encrypted messages, you will need your own key pair. To generate one, run:
Complete the command line dialogue, and wait for the key to be generated. The default option for key type (RSA both for encrypting and signing) is sufficient. Note that, after the key generation phase, the underlying algorithms are handled by gpg under the hood, so you should never run into problems because of the key type of others. A key length of 4096 and an expiration date after one year are recommended, and the comment field should be left empty. Note that it is highly recommended to secure the key with a strong passphrase. Your private key is your digital identity, do not treat it lightly.
1.1.3 Key IDs
Many commands in GPG need to identify the key to use. The public keys available can be listed with the command ‘gpg -k’,andtheprivatekeyswith‘gpg -K’.Eachkeyisassociatedwithalong(160bits)hexadecimalID,which can be used to refer to it, known as the fingerprint of the key. Add the option ‘–fingerprint‘ to the previous commands to display it. More conveniently, keys can also be referred to by their email address.
1.1.4 Key Management
Once you’ve generated a key, there are a few maintenance operations you may need to do from time to time.
1. Uploadyourpublickeytothekeyserverat‘hkp://keys.gnupg.net’.Youwillhavetosetthe‘keyserver’
optionin‘~/.gnupg/gpg.conf’,andthenrun‘gpg –send-keys
2. Makesureyoucanreceiveacoursemate’spublickey.Aftertheyhaveuploadedtheirs,run‘gpg –recv-keys
3. Generate a revocation certificate for your key, using the command ‘gpg –gen-revoke
4. You can export your keys with the command ‘gpg –export > gpg.keys’. This will create a binary file ‘gpg.keys’, containing all public keys in your database. It is also possible to export private keys, using the command ‘gpg –export-secret-keys > gpg private.keys’. When exported in this way, the keys are still encrypted with your passphrase.
4OnaDICEmachine,youwillfirsthavetoissuethecommandgpg-agent –daemon –no-use-standard-socketandthenexecute the command that is returned in order for the key generation to function properly.
gpg –gen-key4
2
1.1.5 Signing Messages
GPGsignaturesoperateonfiles.Themostbasicwaytosignafileistoexecute‘gpg -b
Itisalsopossibletopackagethedatatogetherwiththesignature,byrunning‘gpg -s
1.1.6 Encrypting and Decrypting Messages
To encrypt a message, double check that you have a coursemate’s public key. Create a plain text file containing your message, and then encrypt it with ‘gpg -e
Hopefully you will have received an encrypted message from one of your coursemates. If not, ask someone to sendyouone.Todecryptthemessage,simplyrun‘gpg -d
1.2 Encrypted email exercise
In this exercise you will have to prove your ability to encrypt and decrypt messages correctly. This is the only marked exercise in the GPG section.
2
1. 2.
3.
4. 5.
6.
Generateakeypairifyoudon’talreadyhaveoneanduploadthepublickeytothekeyserverasexplainedabove5.
Send an email from your student address with subject “fingerprint
Youwillreceivethroughemailthechallenge,encryptedwiththepublickeycorrespondingtothefingerprintyou uploaded. Decrypt it and solve the challenge. Note that due to technical difficulties on our end, the challenge may be arrive with a delay of some hours (especially at night).
Receive the key with fingerprint 96CB 3DC2 AFCA 575F EA2A AB3F 000B 2EDC 21F6 F23D. Create a file containing only the answer and encrypt it using the public key that you just received. Rename the
resulting ciphertext to response.gpg.
Submit the encrypted answer using the “GPG” link in BlackBoard Learn. The link should lead you to the
CodeGrade submission platform, where you can submit your file.
Spoofing email sender
For this exercise, you will send us an email with a spoofed email sender field: • The subject line of your email should be your student id
• The sender of your email should be darth.vader@starwars.com • You will send your email to cw-2@ed.ac.uk.
One way of doing this is by using the mailx utility program. You are free to try this amongst yourselves before you actually send your email to us. Spoofing is probably easier from a DICE machine than from your computer. (You won’t have to submit anything through Learn for this.)
5The key does not necessarily have to be tied with your student email account, but you will have to have access to your student email account in order to complete the exercise.
3
3 (wo)Man in the Middle Attack
You are asked to mount a (wo)Man-in-the-Middle (MitM) attack against the toy implementation of an encrypted chat between terminals provided in /afs/inf.ed.ac.uk/group/teaching/compsec/cw2/mitm/.
3.1 High-level overview
When Alice and Bob hear about encryption, they immediately set out to implement an encrypted chat client so that they are sure no one eavesdrops their intimate discussions. They decide to use AES6 to encrypt their messages, since everyone says it’s the best. They also hear of the Diffie-Hellman key exchange7 (DHKE) and figure it would be cool to use a new secret key for AES every time they connect.
3.1.1 AES
Just like every symmetric encryption scheme, AES consists of two algorithms:
• The encryption algorithm takes a key K1 and a message M1 as input and returns a ciphertext C1 as output:
C1 = Enc(K1, M1)
• The decryption algorithm takes a key K2 and a ciphertext C2 as input and returns a message M2 as output:
M2 =Dec(K2,M2)
If a message M is encrypted with key K and the resulting ciphertext C is decrypted with the same key K, the result of the decryption will be the original message M: ∀K∀M,M = Dec(K,Enc(K,M))
A simple library for encrypting and decrypting using pyaes is provided in symmetric.py.
3.1.2 Diffie-Hellman Key Exchange
This is a protocol between two parties (say Alice and Bob) that want to obtain a common key that is unknown to anybody else. Their communication takes place over an insecure channel that anyone can eavesdrop.
A physical-world equivalent is the following: A group of people sit around a table and two of them want to speak in private. They can have a brief exchange (of very long numbers) which everybody hears. After that they will possess a common secret that no one else knows. They can use this secret as the key for encrypting, sending and decrypting private messages in plain sight.
We assume that both parties have agreed beforehand on a finite cyclic group G and a generator g of G. For production software, these parameters are standardised by cryptographers and hardcoded in the implementation by the developers.
These are the steps of the protocol:
• Alice chooses a random number x and calculates a = gx. • Alice sends a to Bob.
• Bob chooses a random number y and calculates b = gy.
• Bob sends b to Alice.
– Now all eavesdroppers know a and b, but not x and y.
• Alice derives the common secret bx.
• Bob derives the common secret ay .
6 https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
7 https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
4
Given that (gx)y = (gy)x, both Alice and Bob have derived the same common secret. Assuming that an eavesdropper cannot find x from a or y from b, we conclude that no one else can derive the common secret.
A simple library for doing the necessary steps of DHKE is provided in diffie hellman.py. You can see how to use it in the do Diffie Hellman() function in util.py.
3.1.3 Putting it all together
The entire process of chatting is then as follows:
1. Alice and Bob establish a communication socket
2. They do DHKE over this socket
3. Bob encrypts his message under the derived key (with AES) 4. Bob sends the resulting ciphertext through the socket
5. Alice decrypts the ciphertext using the derived key
6. Alice reads the message
Steps 3–6 can be repeated as many times as desired, possibly with changed roles. (In our implementation, the process is repeated only twice, so Bob sends first, then Alice, then both parties terminate.)
3.1.4 MitM attack
The described approach sounds very reasonable. Unfortunately Alice and Bob overlooked a fatal flaw: When com- municating over the internet (or even locally), one cannot know with certainty that they are speaking to the intended party, at least not without using some form of cryptographic authentication8.
Going back to our round-table example, consider the case where every member of the group wears a different mask, uses a voice jammer and sits at random seats. Alice would be unable to recognize Bob. In an even worse scenario, if Bob happens to be missing from the table, someone with a good disguise could impersonate him and fool Alice into performing DHKE with him. This is why Alice and Bob should have agreed to only speak to each other after authenticating themselves.
Given that no authentication takes place, Eve the attacker is now able to do the following: After Alice opens his end of the socket and before Bob connects, Eve connects and performs a DHKE with Alice. Eve then opens a new socket and waits for Bob to connect. When Bob and Eve connect, they perform another DHKE. Now Eve can decrypt messages from one party, read them and reencrypt them for the other party. If she so wishes she can even send arbitrary messages, completely unrelated to the original ones. In short, she has complete control of the channel while Alice and Bob think they communicate with each other privately.
3.2 Implementation details
3.2.1 How to use the provided code
Open two terminals and navigate to the directory with the scripts. First run python3 alice.py in one and then python3 bob.py in the other (the order is important). You should see secure channel establishment, a couple of messages being exchanged and finally the channel closing.
8 https://en.wikipedia.org/wiki/Message_authentication_code
5
3.3 Code overview
Open both aforementioned scripts with your favourite editor. Each of the two scripts calls setup() with its name and the name of the pre-agreed buffer file over which communication happens. This name is set in const.py. Then Alice waits for a message, while Bob sends it. Alice then prints the message and the roles are reversed. Finally both parties close their sockets.
Familiarise yourself with the scripts and understand which lines correspond to each of the steps above. You can optionally dive in the code of the various supporting sources as well.
3.4 Exercise
You will have to implement and submit eve.py via CodeGrade – use the “MitM” link to the submission platform in BlackBoard Learn. The attack should execute correctly when first alice.py is started in one terminal, then eve.py in a second and last bob.py in a third. eve.py should be followed by exactly one of the following three flags: –relay, –break-heart or –custom.
• If the flag is –relay, Eve should just relay the two messages from Alice to Bob and from Bob to Alice. In this case, the outputs of both alice.py and bob.py in the terminals should be identical to the case when the MitM attack isn’t executed.
• Withthe–break-heartflag,EveshouldchangethemessagessothatAlicereceivesthemessage”I hate you!” and Bob receives ”You broke my heart…”. Remember, Eve still has to encrypt both messages correctly.
• As for the –custom flag, after receiving Bob’s messsage, Eve must prompt the user to input a message to the terminal and then must send this message to Alice instead. The same should happen for Alice’s message; Eve must prompt the user for a second message and this time send it to Bob.
Hint: Your solution will have to use the buffer file somehow. The function os.rename() will prove helpful.
Note: It may happen that a script dies without closing its socket gracefully. In that case, you should manually remove the remaining buffer file (by default called buffer) before restarting the scripts.
6
Figure 1: The output of your eve.py does not have to match the example, but that of alice.py and bob.py have to.
7