Which version of encryption should we add to Flottform?

[nidhal-labidi]

Description

Task: Encrypting Sensitive Data in the Signaling Server

The current implementation stores data in the signaling server as plain text. This exposes sensitive information, such as session details and ICE candidates of both peers. To secure this information, we need a solution where:

1. The server does not have access to the encrypted content.
2. Peers are confident that the data they receive originates from the legitimate counterpart and not a third party.

Below are two possible encryption solutions that we have identified.

---

1) Symmetric Key Encryption (AES-GCM)

In this solution, the host generates a symmetric key and uses it to encrypt data before storing it in the signaling server. AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) is used because it offers both confidentiality and data integrity through an authentication tag. This means that if any ciphertext is altered, decryption will fail.

However, it is important to note that AES-GCM does not provide sender authentication. Since both peers share the same key, neither can cryptographically prove that a particular message came uniquely from the other—only that it has not been tampered with. An attacker or even the sender could replay or forge messages without detection if they possess the key.

Workflow:

1. The host generates a symmetric key using the Web Crypto API.
2. The link shared with the client includes the encryption key as a fragment (e.g., https://example.com#key=abcdefg).
3. The client extracts the key from the link and uses it to encrypt its data (session and ICE candidates) before storing it in the signaling server.
4. AES-GCM ensures that any modified ciphertext will fail verification on decryption.

Advantages:

• Simplicity: Easy to implement using standard APIs.
• Integrity Protection: The authentication tag of AES-GCM ensures that any tampering with the ciphertext is detected.

Disadvantages:

• Lack of Sender Authentication: Because both parties share the same key, AES-GCM cannot prove the origin of the message.
• Key Exposure Risk: If a third party intercepts the key from the shared link, they can decrypt the sensitive data.

---

2) Elliptic Curve Diffie-Hellman (ECDH) Combined with AES-GCM

This approach uses ECDH to enable the host and client to derive a shared secret key independently, without ever transmitting the key over the network. The shared secret is then used with AES-GCM for encryption and decryption of sensitive data. This method ensures that even if the public keys are intercepted, a third party cannot derive the shared secret.

Note on Sender Authentication:
Even when using ECDH to derive the shared secret, the resulting symmetric key still only provides confidentiality and integrity through AES-GCM. The issue of sender authentication remains unresolved. Since both peers can produce valid ciphertext with the shared key, there is no built-in mechanism to cryptographically bind a message to its sender. If sender authentication is a requirement, additional measures (such as digital signatures) must be implemented.

Workflow:

1. The host and client each generate an ECDH key pair.
2. The host shares its public key with the client via the signaling server.
3. The client shares its public key back with the host.
4. Both peers derive the same shared secret by combining their private keys with the other’s public key.
5. The shared secret is used as the key for AES-GCM to encrypt and decrypt sensitive data.

Advantages:

• Secure Key Exchange: The shared secret is never directly transmitted, protecting it from interception.
• Efficiency: ECDH achieves high security with smaller key sizes compared to traditional Diffie-Hellman.
• Integrity Protection: AES-GCM ensures data integrity by failing decryption if the ciphertext is tampered with.

Disadvantages:

• Complexity: More complex to implement compared to a direct symmetric key approach.
• Lack of Sender Authentication: Similar to the symmetric key approach, while data integrity is ensured, it does not guarantee that the message originated from a specific party. An additional mechanism (e.g., digital signatures) is necessary to achieve true sender authentication.

---

Additional Considerations:

Sender Authentication:
Neither solution inherently authenticates the sender. If your security model requires that each peer be absolutely sure of the sender’s identity (for example, to prevent replay attacks or to ensure non-repudiation), you should consider integrating an asymmetric authentication mechanism.

• Digital Signatures: One approach is to have each peer sign messages with its private key, with the signature verifiable by the other peer’s public key. This separates sender authentication from the encryption process.
• Certificates and TLS: Alternatively, using protocols like TLS with client certificates can provide robust mutual authentication while handling key exchange and encryption transparently.

Why Avoid Asymmetric Solutions for Key Exchange:
Asymmetric (public-key) based key exchange, like Diffie-Hellman or RSA, can be computationally expensive and slower than symmetric encryption, especially when used for bulk data encryption.

---