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.

[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

[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.