[FR] Authenticated Encryption (AEAD)

[maxsharabayko]

Authenticated-Encryption with Associated-Data (AEAD) schemes provide confidentiality by encrypting the data, and also provide authenticity assurances by creating a MAC tag over the encrypted data. The MAC tag will ensure the data is not accidentally altered or maliciously tampered during transmission and storage [OpenSSL Wiki].

1. Select Supported Algorithms (GCM, CCM, etc.) ✔️

• Selected AES GCM crypto mode.

There are a number of AEAD modes of operation. The modes include EAX, CCM, and GCM (RFC 5647).

AEAD parts [OpenSSL Wiki]:

• Algorithm (currently only AES is supported by OpenSSL)
• Mode (currently only GCM and CCM are supported by OpenSSL)
• Key: keep using PBKDF2
• Initialisation Vector (IV): keep the current algorithm? IV = (MSB(112, Salt) << 2) XOR (PktSeqNo)

2. Encrypt Data Packets

• [core] Use setDataPacketTS to timestamp data packets. #2489.
• See issue (AEAD) Which fields of the data packet are to be authenticated? #2337.
• Support both TSBPD enabled and disabled. See [FR] Change Packet Timestamping in non-live Configuration #2581.
• [api] Socket Options: do not allow AES GCM if TSBPD is disabled. #2573
• Fix bool retransmitted usage for "rexmit" flag restoring. It's not necessarily the same packet.

3. SRT API Changes

• Add AES GCM to the SRT API. #2483
  • Socket option to enable GCM.
  • New rejection reasons: bad crypto mode.
• [API] Crypto mode 'auto' implemented for listener. #2574.

4. SRT Handshake Enhancements: Negotiate Encryption

• [AEAD] Set AES-GCM auth in the KM message. #2492.
• Extend SRT HS v5 to Negotiate the AEAD mode. See issue (AEAD) Handshake Enhancements to negotiate AEAD #2339.
• Implement crypto mode AUTO negotiation.
  • [API] Crypto mode 'auto' implemented for listener. #2574.
  • Caller-listener handshake;
  • Rendezvous handshake.
• Signal support for AEAD via the handshake flags?

5. Maximum Payload Size

AEAD requires placing an authentication tag along with the payload. In the case of GCM mode, the tag takes 16 bytes (CCM: 14 bytes). Thus maximum payload size has to be handled accordingly.
Also, decide if and how should this work with FEC.

6. FEC

Define how FEC and a packet filter, in general, should work with authenticated packets.
Just include the whole data packet?
Should the FEC packet be authenticated? Probably not, it would also complicate things a lot.

7. Integrate into the CRYSPR

The encryption provider library of SRT has to support AEAD (GCM mode).

• [core] Add auth tag to the sender buffer. #2473.
• CRYSPR: Add AES GCM mode with OpenSSL EVP. #2476.

8. Error Handling

• Drop a packet from the receiver buffer. CUDT::processData(..).
• [core] AEAD: don't break a connection on decrypt failure. #2599
• Report an error on a socket?

8. Unit Tests

9. Application-level testing

Test different SRT versions work correctly with each other:

1. Connection establishment w/o AEAD and valid encryption with one peer of an older SRT version.
2. Connection rejection in AEAD configuration with one peer of an older SRT version.
3. etc.

10. Update the IETF SRT Internet Draft.

• Define the version number.
• Update the KM message: KM message now supports AES-GCM. srt-rfc#115.
• Signal support for AEAD via the handshake flags?

[ethouris]

Basing on the possible application, there should be also 3 possibilities provided:

1. Full signature. The whole packet is taken for the signature, the R flag must be set to 0 before checks. The signature cannot be passed through - the SRT re-routing machines would have to authenticate and replace the signature if needed.
2. Payload passthrough. Only the payload is included, all other fields can be potentially altered, but this can be freely passed through and freely decided on timestamp passthrough.
3. Timely payload passthrough. Payload and the timestamp are included. This can be freely passed through with the original unchecked signature, but the re-routing application must preserve the original timestamp.