Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refine some text regarding the use of encryption #797

Merged
merged 4 commits into from
Aug 12, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 23 additions & 9 deletions notes.md
Original file line number Diff line number Diff line change
Expand Up @@ -675,13 +675,17 @@ Country codes are the [@!BCP47] two-letter region subtag, without the UK excepti

# Encryption

Encryption in Matroska is designed in a very generic style to allow people to
implement whatever form of encryption is best for them. It is possible to use the
encryption framework in Matroska as a type of DRM (Digital Rights Management).

This document does not specify any kind of standard for encrypting elements.
The issue of key scheduling, authorisation, and authentication are out of scope.
External entities have used these elements in proprietary ways.
This Matroska specification provides no interoperable solution for securing the
data container with any assurances of confidentiality, integrity, authenticity,
or to provide authorization. The `ContentEncryption Element` ((#contentencryption-element))
and associated sub-fields ((#contentencalgo-element) to (#aessettingsciphermode-element)) are defined
only for the benefit of implementers to construct their own proprietary solution
or as the basis for further standardization activities. How to use these
fields to secure a Matroska data container is out of scope, as are any related
issues such as key management and distribution.

A `Matroska Reader` who encounters containers that use the fields defined in this
section **MUST** rely on out-of-scope guidance to decode the associated content.

Because encryption occurs within the `Block Element`, it is possible to manipulate
encrypted streams without decrypting them. The streams could potentially be copied,
Expand All @@ -696,12 +700,22 @@ Encryption information is stored in the `ContentEncodings Element` under the `Co
For encryption systems sharing public/private keys, the creation of the keys and the exchange of keys
are not covered by this document. They have to be handled by the system using Matroska.

The algorithms described in (#ContentEncAlgoValues) support
different modes of operations and key sizes. The specification of these
parameters is required for a complete solution, but is out of scope of this
document and left to the proprietary implementations using them or subsequent
profiles of this document.

The `ContentEncodingScope Element` gives an idea of which part of the track are encrypted.
But each `ContentEncAlgo Element` and its sub elements like `AESSettingsCipherMode` really
define how the encrypted should be exactly interpreted.

The AES-CTR system, which corresponds to `ContentEncAlgo` = 5 ((#contentencalgo-element)) and `AESSettingsCipherMode` = 1 ((#aessettingsciphermode-element)),
is defined in the [@?WebM-Enc] document.
An example of an extension that builds upon these security-related fields in this specification is [@?WebM-Enc].
It uses AES-CTR, `ContentEncAlgo` = 5 ((#contentencalgo-element)) and `AESSettingsCipherMode` = 1 ((#aessettingsciphermode-element)).

A `Matroska Writer` **MUST NOT** use insecure cryptographic algorithms to create new
archives or streams, but a `Matroska Reader` **MAY** support these algorithms to read
previously made archives or stream.

# Image Presentation

Expand Down
Loading