MSF supports end-to-end encryption of media content using MoQ Secure Objects [SecureObjects]. When encryption is enabled, the payload of LOC-packaged media objects is encrypted and authenticated, while relays can still route content based on unencrypted header information.
4.3.1. Encryption scheme signaling
The encryption scheme and parameters are signaled in the catalog using the following track-level fields:
-
encryptionScheme Section 5.2.38 - identifies the encryption mechanism
-
cipherSuite Section 5.2.39 - specifies the AEAD algorithm
-
keyId Section 5.2.40 - identifies the key material for decryption
-
trackBaseKey Section 5.2.41 - the base key material for this track
When the encryptionScheme field is present in a track definition, subscribers MUST decrypt the object payload using the specified scheme before processing.
4.3.2. Key management
The keyId and trackBaseKey values are obtained from an external key management system and the mechanism for obtaining these values is out of scope for this specification. Examples of key management systems include MLS-based key distribution [E2EE-MLS] or other out-of-band key exchange mechanisms.
Depending on the key management mechanism in use, a keyId MAY be scoped to:
-
A single track
-
A single MoQ Session
-
Multiple tracks across one or more MoQ sessions
Publishers and subscribers MUST use the same key management system and agree on the keyId scope semantics for interoperable operation.
4.3.3. Recommended encryption scheme
The RECOMMENDED encryption scheme for MSF is "moq-secure-objects". Implementations supporting content encryption MUST implement the "moq-secure-objects" scheme as defined in [SecureObjects].
When using the "moq-secure-objects" scheme:
-
The cipherSuite field MUST be present and set to a supported cipher suite value
-
The keyId field MUST be present to identify the key material
-
The trackBaseKey field MUST be present to provide the base key material
4.3.4. Encrypted object structure
For LOC-packaged tracks with encryption enabled (see [SecureObjects], Section 4):
-
The immutable header extensions (including Group ID and Object ID) remain in plaintext and are authenticated
-
The object payload is encrypted and authenticated using the specified cipher
-
Private header extensions (type 0xA) are encrypted alongside the payload