Thanks Richard. It was "SRTP uses something that OpenSSL doesn't directly support" that our FIPS expert told us, which led us down this line of enquiry. I didn't understand exactly what the something was, but your explanation makes sense.
On Thu, 11 Apr 2024 at 10:41, Richard Fuchs rfuchs@sipwise.com wrote:
On 10/04/2024 17.46, David Cunningham wrote:
I was asking whether OpenSSL was used because of a question we had about FIPS validation. FIPS requires that all cryptography components go through a validation process, which some versions of OpenSSL (but not all) have done.
My understanding is that RTPengine uses OpenSSL for the AES, but not for all of the key functions. Is that right? If so then even if we're using a FIPS validated version of OpenSSL, not all of the cryptography components of RTPengine would be using it, so we wouldn't be fully FIPS validated.
DTLS is entirely provided by OpenSSL, except for the raw network I/O.
Once the DTLS handshake completes, the SRTP keys are extracted out of OpenSSL.
The cipher implementation (AES) as well as the digest implementation (SHA-1) are provided by OpenSSL.
For AEAD-GCM, the entire encryption, decryption, and authentication process is handled by OpenSSL.
For the other cipher suites (AES-CM, AES-F8), OpenSSL is used to create the block key via AES, and then rtpengine has its own implementation of the counter-mode cipher to apply the AES key to the SRTP payload. This is because SRTP uses a peculiar version of AES-CM that OpenSSL doesn't directly support. (This really isn't much more than XOR'ing the AES key onto the SRTP payload and so isn't really doing much cryptography.)
For SRTP in the kernel module, it's more or less exactly the same, except that the kernel's crypto API is used instead of OpenSSL. (DTLS is done in userspace only.)
Cheers