Add support for segment encryption

[jflevesque-genetec]

We have tested using the current cloud recording specification to upload encrypted segments and playing them back through an HLS playlist on various devices. We have discovered that frame encryption is not well supported on Apple devices (iPhone, iPad & macbooks) without FairPlay.

For security reasons, some customers are not comfortable with frame encryption since metadata is in clear and for CBCS only 10% of the segment is encrypted.

This proposal adds a different mechanism for encrypting whole segments. It simplifies the whole process, adds compatibility with Apple devices and covers customer concerns about security. This proposal is compatible with both HLS and MPEG-DASH.

[venki5685]

When uploading the segment to the external object storage, the device shall include the following attributes in the metadata: i.e CertThumb, Key, KID, IV, EncAlgo. The listed metadata attributes are necessary in order to be able to decrypt the encoded segment. What is the CertificateID here?How this CertificateID used by the client to decrypt the encrypted segment using the listed meat data attributes. what is significance of KID here?

Member
@venki5685 venki5685 3 days ago
Is object metadata also encrypted along with the segment?

[jflevesque-genetec]

The CertificateID indicates which certificate's public key is used to encrypt the symmetric key that is added to the object store's metadata.
The full mp4 file is encrypted, while the object's store metadata is not encrypted.
The KID can be used by clients to optimize the decryption process. If the client already has a specific KID, it can use it to decrypt the segment. KID could be the same across segments depending on the value of the key rotation.

[venki5685]

@jflevesque-genetec, thanks for the clarification.

[jmelancongen]

Pending work to be done on this PR:

• Require two encryption certificates for redundancy
• Look at the size of the metadata used when using this feature
• Write up the encryption strategy for the "Key" field when using EC certificates

[kieran242]

@jflevesque-genetec I am not an expert on this and I had to perform some research on NLS and "Fairplay" and how it works. I agree with this proposal and don't have any major issues with what you implemented here in the PR.

I read over your response to @venki5685 and feel that this would provide further clarity to this document. Reading it currently without the explanation you provided in the review comments and not having expertise in this area makes it quite difficult to understand. Can I please request a minor update to this PR to address this?

[jmelancongen]

I've updated the PR with the points from the F2F in San Juan. I'm not quite satisfied yet on the completion. Notably, I'd like to add some test vectors primarily about the Elliptic Curve encryption part, since this has quite a few moving parts. But I'm wondering what the other members think about it since this is not something we've done before as far as I'm aware? Also looking for feedback in general to the current shape of it

Concerning the metadata size, here is a rough breakdown of the fields:

• KeyId: ideally a UUID, so 16 bytes
• CertX: Hash of the certificate, SHA-256 ideally, 32 bytes each (2x)
• KeyX: Encrypted key, using an ECC key. This gives: 1 version byte, 2x32 bytes for the ephemeral key, 1x16 bytes for the tag, 1x32 bytes for the actual ciphertext (The recording AES-256 key). Total 113 bytes each (2x)
• IV: 16 bytes

All that, base64 for each value. This gives ~425 bytes of metadata values per file.
This is certainly a bit high, there are possibilities to reduce that, but none seemed appealing:

• Using X25519, which saves 32 bytes per encryption. But that's not (yet) NIST/FIPS compliant
• Truncated cert hashes, since they are known to the client anyway, it's likely fine to truncate the hash to half or less of its length
• Reusing the ephemeral key and blending the two KeyX fields. This is probably Ok from a security standpoint since the Cert1 & Cert2 are distinct, but I'm no cryptographer. It's also a bit ugly from a specification point of view.

[kieran242]

Hi all, I made comment but did not notice that it was "OnHold". So I deleted my comment.