COMP3334 Project
End-to-end encrypted chat web application
Semester 2, 2023/2024
Nowadays, web services are the most
common form of applications that users are
exposed to. Web browsers become the most
popular application on a computer that
enables users to access those web services.
Ensuring the security of web services is
essential for the Internet. Moreover, privacy
of communications is an important feature of
modern times. Your job is to implement an
end-to-end encrypted chat web application
and secure various aspects of the website.
Overview
Objectives
1. Adapt a basic chat web application to become a secure E2EE chat web app
2. Comply with some of the requirements in NIST Special Publication 800-63B “Digital
Identity Guidelines – Authentication and Lifecycle Management” for US federal
agencies (which is also a reference for other types of systems)
3. Implement a secure MFA mechanism based on passwords and OTP (or FIDO2)
4. Encrypt communications between two users so that the server does not know the
content of the messages (E2E encryption)
5. Protect communications in transit by configuring a modern TLS deployment
6. Package a docker image of your web app
Requirements (authentication)
1. From NIST Special Publication 800-63B:
1. Comply with all SHALL and SHOULD requirements from sections listed below
2. Use the following authenticators:
• User-chosen Memorized Secret (i.e., password/passphrase)
• and Single-Factor OTP Device (e.g., Google Authenticator)
• or Single-Factor Cryptographic Device (e.g., Yubikey) if you have one
• and Look-Up Secrets (recovery keys)
• Comply with related requirements in §5.1 and §4.2.2
• §5.1.1.2: “Memorized secrets SHALL be salted and hashed using a suitable one-way key
derivation function”
• See our Password Security lecture for an appropriate function
• Memorized Secret Verifiers (§5.1.1.2)
• Choose “Passwords obtained from previous breach corpuses” and refer to
https://haveibeenpwned.com/API/v3#PwnedPasswords for the corpus to check against
• §5.2.8 and §5.2.9 are automatically complied
Requirements (authentication)
1. From NIST Special Publication 800-63B:
3. §5.2.2: Implement rate-limiting mechanisms AND image-based CAPTCHAs
4. Implement new account registration and bind authenticators (OTP/Yubikey and recovery keys) at
the same time
• Optional: provide a way to change authenticators after account registration
5. §7.1: Implement proper session binding requirements
6. Exceptions:
• OTP authenticators — particularly software-based OTP generators — SHOULD discourage and
SHALL NOT facilitate the cloning of the secret key onto multiple devices.
• Google Authenticator and related apps are OK
Requirements (E2EE chat)
2. Once users are logged in, secure chat messages between two users in a way so that the server cannot
decrypt the messages
1. Use the ECDH key exchange protocol to establish a shared secret between two users
• Leverage the WebCrypto API, see demo https://webkit.org/demos/webcrypto/ecdh.html
• Exchanged information during the key exchange can be sent through the server
• The server is trusted not to modify messages of the key exchange
• Choose P-384 as the underlying curve
2. Derive two 256-bit AES-GCM encryption keys and two 256-bit MAC keys from the shared secret
using HKDF-SHA256
• One key for encryption between user1 to user2, and another one from user2 to user1
• Using WebCrypto API again, see https://developer.mozilla.org/enUS/docs/Web/API/HkdfParams
• The salt should be unique so another key derivation in the future produces different keys, use
for instance a counter starting at 1
• The info parameter should represent the current context (e.g., “CHAT_KEY_USER1to2” for the
key for user1user2, and “CHAT_MAC_USER1to2” for the MAC key for user1user2)
Requirements (E2EE chat)
2. Once users are logged in, secure chat messages between two users in a way so that the server cannot
decrypt the messages
3. Messages will be encrypted using AES in GCM mode
• 96-bit IVs are counters representing the number of messages encrypted with the same key
• Note: GCM does not require unpredictable IVs, but unique IVs
• Send the IV together with the ciphertext to the recipient
• As a recipient, verify that IV