AES-256 support in EXT-X-KEY

[jvary]

Hello!

The American government has a 2030 ‘deadline’ to be compliant for the Post-Quantum Cryptography Standardization (NIST).
For video, an easy way to achieve it is with AES-256.

While “within-mp4 ISO/IEC 23001-7” (i.e. HLS EXT-X-KEY ‘SAMPLE-AES’) encryption is handled by the platform/browser video decoders, EXT-X-KEY ‘AES-128’ is handled by the usual browser CryptoAPI (at least with HLS.js).

Given that all browsers natively support AES-256 in their CryptoAPI, I propose to add to HLS.js both “AES-256” (for AES-256 cbc) and "AES-256CTR" to the supported values of #EXT-X-KEY.

New AES-256 .mp4 would not be supported on all embedded players at first, but having a browser option could kick-start the adoption.
(Adding 256bits options to cenc/cbcs is a whole different topic).

Any thoughts ?

Julien Vary, Genetec

(It would be great if DASH ClearKey would also support those modes, but that is irrelevant here 😊)

References:
https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization
https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
https://datatracker.ietf.org/doc/html/rfc8216#section-4.3.2.4 : EXT-X-KEY

CSA_CNSA extracts:

[Quanty22]

Its not * to be compliant* its an advice

[jvary]

Its not * to be compliant* its an advice

You are correct, exact words matter.

NSA recommends:

• "New software and firmware use CNSA 2.0 signing algorithms by 2025"
• "Transitioning all deployed software and firmware to CNSA 2.0-compliant signatures by 2030."

However, with

"NIAP Protection Profile requirements and NSM-10 technology refresh requirements will determine the removal of legacy algorithm support. At that point, legacy equipment and software not refreshed regularly will require a waiver and a plan to bring it into compliance."

it will be 'annoying' being not CNSA 2.0 compliant in a not-so-distant future.

[jvary]

@robwalch : any chance a PR adding those options would be accepted ?
(with related tests, obviously)

[robwalch]

Hi @jvary,

Before accepting, we'd have to review such a PR, considering the implications like library payload increase, browser and device support, and interest from HLS authors and streaming platform vendors.

AES-256 is not one of the EXT-X-KEY METHOD values listed in rfc8216. If this is something you want, you should pursue getting it added to the HLS spec via the IETF HLS-Interest group: https://www.ietf.org/mailman/listinfo/Hls-interest.

[robwalch]

It would help to include more practical use cases for clear AES encryption. You may need to provide more of an argument than the NIST standardization. AES encryption does little to protect content compared to encryption and licensing enforced by a content protection system with HW CDM.

[jvary]

It would help to include more practical use cases

You are right, context always helps :-)
My request is coming from the CCTV cameras world, were a huge number of CCTV cameras produces 24/7h footage (with regular key rotation & encryption at the camera level). Since a lot of those systems are running on governmental premises, legislation matters.

The main concern is not the typical DRM case : the main goal of encryption is to add an extra layer of security/authorization enforcement, not so much preventing 'leak' from someone that has access to the video. (It is still a valid concern, but to a lesser extent).
Having the keys stored in a different storage than the video files is already a big security plus, even if a client has both at some point.

Given that video is continuously produced from many many sources, we haven't found a suitable (and globally available) HW CDM.
Unless I missed something, FairPlay/Widevine/PlayReady key schemes are much more targeted toward 'classic' video streaming content. They also seem to be strongly coupled with "ISO/IEC 23001-7", which I think will take much more time to evolve than having a simple enum asking the browser CryptoAPI to decrypt a whole file in AES-256 instead of AES-128.

I was hoping to kickstart a first AES-256 adoption with HLS.js even if not within the RFC (like Google that pushed SAMPLE-AES-CTR which is not within rfc8216).

In all cases, I will join https://www.ietf.org/mailman/listinfo/Hls-interest and post there, thx for the tip! :-)

Julien Vary

[jvary]

For the records, an informal addendum to rfc8216 (about AES-256 and AES-256-CTR) has been posted on hls-interest.
https://mailarchive.ietf.org/arch/msg/hls-interest/RZBgatOvI4W0M0J5cShuXWzdigg/

[Quanty22]

Dont use AES 256
Instead, use 8(to)7

[jvary]

AES-256 and AES-256-CTR support have been added to the master branch, and is expected to be released in the 1.6.0 milestone.