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



--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782