11 Apr
2024
11 Apr
'24
1:54 a.m.
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(a)sipwise.com> wrote:
On 10/04/2024 17.46, David Cunningham wrote:
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
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