I am preparing an iOS app for distribution including France. App Store Connect requests a “French encryption declaration approval form” when declaring standard encryption outside Apple’s OS and availability in France.
Dependencies:
- LiveKit Swift SDK 2.17.0
- LiveKitWebRTC XCFramework 150.7871.2
- LiveKit UniFFI XCFramework 0.1.9
The app uses the default LiveKit Room configuration for audio/video calls; optional E2EE is not enabled.
Does LiveKit provide an ANSSI declaration or receipt for these components, and does it cover applications embedding them, or must each publisher file a separate declaration? Where can I obtain the exact cryptographic algorithms, maximum key sizes, key exchange mechanisms and relevant export classification documentation for these versions?
I am looking for vendor technical documentation to complete the declaration accurately. Thank you.
I haven’t come across this question before, and I can confirm that LiveKit does not provide any guidance for completing the ANSSI declaration.
Everything is open source, so it should be possible to derive the answers, but I will ask internally to see if anyone has answered this previously.
@Sanjeewa_Dehiwalage, On the technical layer: with E2EE off, your media uses WebRTC’s mandatory transport encryption (DTLS-SRTP); E2EE is only an extra layer the SFU cannot read, and it is opt-in (encryption overview). In the Swift SDK that opt-in is RoomOptions.e2eeOptions / encryptionOptions, both nil by default, so a default-config build uses the transport layer only:
// client-sdk-swift RoomOptions: both opt-in fields default to nil
let options = RoomOptions() // e2eeOptions == nil, encryptionOptions == nil
The exact cipher suites, key sizes, and export classification are properties of the pinned LiveKitWebRTC build, so that manifest is the internal answer already being gathered here.
Hi @Sanjeewa_Dehiwalage here’s a list of algos used across the SDK and its dependencies; let us know if there are any gaps that prevent you from filling the form:
Components. LiveKit Swift SDK 2.17.0 → LiveKitWebRTC 150.7871.02 (libwebrtc m150_release,
BoringSSL rev f91f1447397c6719f9774dfb8e67329378e1f3d3 / 0.20260413.0, non-FIPS; libsrtp 2.8.0)
and LiveKitUniFFI 0.1.9 (Rust). All cryptography is industry-standard, open-source and
statically linked into the app; none is proprietary.
| # |
Function |
Protocol / standard |
Algorithm(s) |
Max key size |
Key exchange / authentication |
Purpose |
Provided by |
Enabled in this app |
| 1 |
Signaling & HTTP to LiveKit server |
TLS (wss://, https://) |
As negotiated by the OS |
As negotiated by the OS |
As negotiated by the OS |
Confidentiality + integrity |
Apple OS (URLSession); no custom TLS stack, no pinning |
Yes |
| 2 |
Media key agreement |
DTLS 1.2 – 1.3 (RFC 6347 / RFC 9147) |
DTLS 1.3: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305. DTLS 1.2: BoringSSL DEFAULT:!NULL:!aNULL:!SHA256:!SHA384:!aECDH:!AESGCM+AES256:!aPSK:!3DES |
256-bit |
ECDHE over X25519, P-256, P-384; peer authenticated by self-signed ECDSA P-256 certificate, SHA-256 fingerprint in SDP (RFC 8122) |
Key establishment |
BoringSSL (LiveKitWebRTC) |
Yes (always on; no SDK switch to disable) |
| 3 |
Media encryption |
SRTP / SRTCP (RFC 3711, RFC 7714) via DTLS-SRTP (RFC 5764) |
AES_CM_128_HMAC_SHA1_80, AEAD_AES_256_GCM, AEAD_AES_128_GCM (offered in that order) |
256-bit |
Keys derived from the DTLS handshake (#2) |
Confidentiality + integrity of audio/video |
libsrtp 2.8.0 + BoringSSL (LiveKitWebRTC) |
Yes (always on) |
| 4 |
Data channels |
SCTP over DTLS (RFC 8831) |
No cipher of its own (CRC32c checksum); protected by #2 |
— |
— |
Transport |
libwebrtc |
Yes |
| 5 |
ICE / STUN connectivity |
STUN (RFC 5389 / RFC 8489) |
HMAC-SHA1 (MESSAGE-INTEGRITY), MD5 (long-term credential), CRC32 (FINGERPRINT) |
160-bit MAC |
Shared credential |
Integrity / authentication only |
BoringSSL (LiveKitWebRTC) |
Yes |
| 6 |
TURN relay over TLS |
TLS 1.2 – 1.3 (turns: URLs only) |
BoringSSL ALL:!SHA256:!SHA384:!aPSK:!ECDSA+SHA1:!ADH:!LOW:!EXP:!MD5:!3DES |
Per negotiated suite (≤ 256-bit) |
ECDHE; server certificate validated against 36 bundled Google roots with Apple SecTrust fallback |
Confidentiality + integrity |
BoringSSL (LiveKitWebRTC) |
No (no turns: server configured) |
| 7 |
Random numbers / digests |
— |
RAND_bytes (BoringSSL); MD5, SHA-1, SHA-256/384/512 |
— |
— |
Supporting primitives |
BoringSSL (LiveKitWebRTC) |
Yes |
| 8 |
End-to-end media/data encryption (optional) |
LiveKit frame encryption |
AES-128-GCM (128-bit tag, 96-bit IV); key derivation PBKDF2-HMAC-SHA256 (100 000 iterations) or HKDF-SHA256 |
128-bit |
Pre-shared key supplied by the application |
Confidentiality + integrity |
LiveKitWebRTC (LKRTCFrameCryptor), configured from Swift |
No (not enabled) |
| 9 |
Access-token (JWT) handling |
RFC 7519 |
HMAC-SHA256/384/512 compiled in; the SDK only parses token claims without verifying the signature |
512-bit MAC key |
— |
Integrity / authentication only (not exercised) |
LiveKitUniFFI 0.1.9 (jsonwebtoken, hmac, sha2) |
Linked, not invoked |
| 10 |
Rust runtime RNG |
— |
ChaCha12-based CSPRNG seeded from CCRandomGenerateBytes |
— |
— |
Non-security identifiers / timestamps |
LiveKitUniFFI 0.1.9 (rand) |
Yes |
Not present: no proprietary algorithms; no RSA/EdDSA; no post-quantum key exchange active
(X25519MLKEM768 is compiled into BoringSSL but gated behind a field trial the SDK never sets);
LiveKitUniFFI links no TLS/DTLS/SRTP/AES stack and opens no network connections of its own.
Export / App Store classification (self-assessment, not legal advice). Uses encryption: Yes.
Exempt: No. Proprietary algorithms: No. Standard algorithms not provided by the Apple OS: Yes
(BoringSSL + libsrtp). ITSAppUsesNonExemptEncryption = YES. Typical US self-classification:
ECCN 5D992.c, License Exception ENC §740.17(b)(1). France: declaration under Décret 2007-663
(Arrêté 29 Jan 2015, Annexe I) filed by the app publisher; no LiveKit declaration exists to cite.