Differences
This shows you the differences between two versions of the page.
|
ac:laboratoare:08 [2024/11/07 12:50] dimitrie.valu |
ac:laboratoare:08 [2024/11/14 13:05] (current) dimitrie.valu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Lab 08 - TOFU-based Authenticated Key Exchange ===== | + | ===== Lab 08 - Whatsapp End-to-end Encryption (part 2) ===== |
| - | For this lab, you will find useful the documentation for openssl, available [[https://www.openssl.org/docs/manmaster/man3/|here]]. | + | In this lab you will continue the implementation of the Signal Protocol, which is the basis for WhatsApp's end-to-end encryption. |
| - | For older versions, such as 1.0.2 you can find it [[https://www.openssl.org/docs/man1.0.2/man3/|here]]. | + | |
| - | ==== Task 1: Generate a pair of RSA public/private keys ==== | + | The protocol is described [[https://cryptome.org/2016/04/whatsapp-crypto.pdf|here]]. |
| + | For more details you can also check [[https://s3.amazonaws.com/files.douglas.stebila.ca/files/research/papers/EuroSP-CCDGS17-full.pdf|this]] paper. | ||
| - | Use these commands to generate a pair of public/private keys: | + | For the Elliptic Curves, you can use [[https://github.com/Muterra/donna25519|this]] library. |
| + | |||
| + | If you solved the previous lab, use your previous setup (replace the files with the ones from the ''%%.zip%%'' below to prevent any issues). If you are starting out with these labs, follow the steps below (NOTE: **you can use your ''%%fep%%'' instance via Python3 environments**): | ||
| + | * Install the necessary tools (not necessary on ''%%fep%%''): | ||
| + | <code> | ||
| + | sudo apt install build-essential python3-dev | ||
| + | sudo apt install python3-pip | ||
| + | </code> | ||
| + | * Use ''%%wget%%'' to download the required zip (find it below) | ||
| + | * Create a Python3 environment, make sure PyPI is up to date and install the required packages: | ||
| <code> | <code> | ||
| - | openssl genrsa -out private.pem 2048 | + | python3 -m venv create env |
| - | openssl rsa -in private.pem -outform PEM -pubout -out public.pem | + | source ./env/bin/activate |
| + | pip install --upgrade pip | ||
| + | pip install cryptography donna25519 | ||
| </code> | </code> | ||
| - | ==== Task 2: Implement DH + RSA signature === | + | **If local installation does not work, use your ''%%fep%%'' instance.** |
| - | Modify your DH key exchange implementation (see [[https://ocw.cs.pub.ro/courses/ac/laboratoare/04|lab 4]]) such that when one of the parties (the server) sends its public DH share, | ||
| - | it also sends a signature over this share using its private RSA key (generated in the previous task). The other party (the client) should have access to the server's public key (e.g. just write it on a file). | ||
| - | On reception of the public DH share from the server, the client should verify the signature from the server by using its public key and should also store this public key and associate it with the IP of the server. | + | === Task - Vertical & Horizontal ratcheting === |
| - | Initial files | + | See the previous lab for how to create a common ''%%master_secret%%'' for two clients which communicate through a server. |
| - | {{:ac:laboratoare:lab_dh_tofu.zip|}} | + | |
| - | Note on Makefile. You might need to update the Makefile to suit your openssl version and/or path, e.g.: | + | Then, send messages with different keys each time, by recalculating the Chain Key according to the Signal Protocol. |
| - | <code> | + | |
| - | gcc dhe.c -o dhe -L/usr/bin/openssl -lcrypto | + | |
| - | gcc dhe_server.c -o dhe_server -L/usr/bin/openssl -lcrypto | + | |
| - | </code> | + | |
| - | or | + | |
| - | <code> | + | |
| - | gcc dhe.c -lcrypto -L/usr/lib -o dhe | + | |
| - | gcc dhe_server.c -lcrypto -L/usr/lib -o dhe_server | + | |
| - | </code> | + | |
| - | Notes: make sure you initialize all objects before use (e.g. the RSA object in the client) and check them after initialization. | + | Recalculate the Root Key for each round trip with the new DH public keys sent in messages. |
| - | For example with this code: | + | |
| - | <code C> | + | |
| - | CHECK(object!=NULL, "error_on_init_function_x") | + | |
| - | </code> | + | |
| - | You might find these methods useful (some of them are given in the provided files, some are part of OpenSSL): | + | For this task you need to embed a new ephemeral public key in each message, in order to create a new RootKey. |
| - | <code> | + | |
| - | EVP_PKEY_set1_RSA | + | |
| - | RSASign | + | |
| - | my_receive | + | |
| - | EVP_PKEY_get1_RSA | + | |
| - | RSAVerifySignature | + | |
| - | </code> | + | |
| + | You can find a good description of the ratcheting protocol [[https://signal.org/docs/specifications/doubleratchet/|here]]. | ||
| - | ==== Task 3: Implement DH + RSA + TOFU (bonus) === | + | For the sake of simplicity, we will consider that all messages are in-order and none of them is lost. |
| - | Perform the RSA-based authenticated DH key exchange between the client and server implemented earlier several times. On the first connection, the client should store the public key of the server and associate it with the IP of the server. Then, on subsequent connections, the client must check that the public key of the server matches the one that is stored (if the client already has a public key for the given IP of the server). If it matches, it will use that key for verification of the signature over the DH share of the server. If it doesn't match, it should print an error message and exit. | + | You may start this lab from {{:ac:laboratoare:lab08.zip|this}} code. |
| - | This is very similar to what SSH does when connecting to a server using a pair of public/private keys and is known as Trust On First Use (TOFU) authentication. | + | <note> |
| + | To generate the root keys and chain keys (e.g. in the method update_keys) you need to basically apply | ||
| + | the HKDF method provided (hkdf) with a 64 byte output (512 bits), | ||
| + | which is then split into the root key (first 32 bytes) and chain key (last 32 bytes) | ||
| + | |||
| + | You should do the same also in the method record_new_client_session, for the case when the client is the initiator. | ||
| + | When the client is not the initiator both chain keys (chain_key_s and chain_key_r) will be initialized after receiving a message, | ||
| + | so you can keep them as 'None'. As initiator you should only initialize root_key and chain_key_s as explained above, | ||
| + | while chain_key_r can be left as 'None' for now. | ||
| + | </note> | ||
| + | |||
| + | == How to run == | ||
| + | Open three different terminals. | ||
| + | |||
| + | First terminal (start the server): | ||
| + | <code>python main_server.py</code> | ||
| + | |||
| + | Second terminal (start the first client and enter ''%%RECV%%'' mode: | ||
| + | <code> | ||
| + | python main_client.py | ||
| + | RECV | ||
| + | </code> | ||
| + | |||
| + | Third terminal (start the second client and send a message): | ||
| + | <code> | ||
| + | python main_client.py | ||
| + | MSG <id_other_client> Hello! | ||
| + | </code> | ||
