ISO/IEC 23001-7:2016/Amd 1:2019
(Amendment)Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files — Amendment 1: AES-CBC-128 and key rotation
Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files — Amendment 1: AES-CBC-128 and key rotation
Technologies de l'information — Technologies des systèmes MPEG — Partie 7: Cryptage commun des fichiers au format de fichier de médias de la base ISO — Amendement 1: AES-CBC-128 et rotation des clés
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 23001-7
Third edition
2016-02-15
AMENDMENT 1
2019-09
Information technology — MPEG
systems technologies —
Part 7:
Common encryption in ISO base media
file format files
AMENDMENT 1: AES-CBC-128 and key
rotation
Technologies de l'information — Technologies des systèmes MPEG —
Partie 7: Cryptage commun des fichiers au format de fichier de médias
de la base ISO
AMENDEMENT 1: AES-CBC-128 et rotation des clés
Reference number
ISO/IEC 23001-7:2016/Amd.1:2019(E)
©
ISO/IEC 2019
---------------------- Page: 1 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2019 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO/IEC 23001 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
© ISO/IEC 2019 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
Information technology — MPEG systems technologies —
Part 7:
Common encryption in ISO base media file format files
AMENDMENT 1: AES-CBC-128 and key rotation
Clause 2
Add the following new normative references:
ISO/IEC 23008-2, Information technology — High efficiency coding and media delivery in heterogeneous
environments — Part 2: High efficiency video coding
ISO/IEC 23008-12, Information technology — High efficiency coding and media delivery in heterogeneous
environments — Part 12: Image File Format (HEIF)
3.1
Insert a new 3.1.8 and renumber current 3.1.8 as 3.1.9:
3.1.8
sample
media sample when the protection applies to media tracks, or payload of an item when the protection
applies to items
Note 1 to entry: Media sample as defined in 14496-12.
Note 2 to entry: Payload of an item as defined in 14496-12.
4.2
Add the following item to the list:
e) ‘sve1’ – AES-CTR content sensitive encryption, as defined in Annex A.
© ISO/IEC 2019 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
Clause 6
In paragraph 4, replace:
{
unsigned int(8) reserved = 0;
unsigned int(4) crypt_byte_block;
unsigned int(4) skip_byte_block;
unsigned int(8) isProtected;
unsigned int(8) Per_Sample_IV_Size;
unsigned int(8)[16] KID;
if (Per_Sample_IV_Size == 0) {
unsigned int(8) constant_IV_size;
unsigned int(8)[constant_IV_size] constant_IV;
}
}
with
{
unsigned int(1) multi_key_flag;
unsigned int(7) reserved = 0;
unsigned int(4) crypt_byte_block;
unsigned int(4) skip_byte_block;
unsigned int(8) isProtected;
if (multi_key_flag == 1) {
unsigned int(16) key_count;
} else {
key_count = 1;
}
for (i=1; i <= key_count; i++) {
unsigned int(8) Per_Sample_IV_Size;
unsigned int(8)[16] KID;
if (Per_Sample_IV_Size == 0) {
unsigned int(8) constant_IV_size;
unsigned int(8)[constant_IV_size] constant_IV;
2 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
}
}
}
Clause 6
Add a new item to the list in paragraph 5 (insert before semantics of isProtected):
— multi_key_flag indicates that the multiple key version of the sample group description is used. If
this flag is set, multiple keys will be described for this sample group description entry; otherwise, a
single key is described for this sample group description entry.
Add a new item to the list in paragraph 5 (insert after semantics of isProtected):
— key_count indicates the number of keys that may apply to a sample associated to this sample group
description entry. It is not required that a sample associated with this sample group description
entry uses all the keys described.
7.1
Replace the sample auxiliary information in paragraph 3 with:
aligned(8) class CencSampleAuxiliaryDataFormat
{
if (aux_info_type_parameter==0) {
unsigned int(Per_Sample_IV_Size*8) InitializationVector;
if (sample_info_size > Per_Sample_IV_Size ) {
unsigned int(16) subsample_count;
{
unsigned int(16) BytesOfClearData;
unsigned int(32) BytesOfProtectedData;
} [subsample_count ]
}
} else if (aux_info_type_parameter == 1) {
unsigned int(16) multi_IV_count;
for (i=1; i <= multi _IV_count; i++) {
unsigned int(8) multi_subindex_IV;
unsigned int(Per_Sample_IV_Size*8) IV;
}
unsigned int(32) subsample_count;
{
© ISO/IEC 2019 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
unsigned int(16) multi_subindex;
unsigned int(16) BytesOfClearData;
unsigned int(32) BytesOfProtectedData;
} [subsample_count]
}
}
Following the sample auxiliary information, add the following at the end of the 'where' list (after
semantics of BytesOfProtectedData):
multi_IV_count indicates the number of entries in the initialization vector loop;
multi_subindex_IV indicates the index of the associated key entry, where value one is the first entry,
in the associated list; if this data is read for the processing of a track sample, the associated list is
the ’seig’ sample group description entry associated with this sample; otherwise (this data is
read for the processing of an item), the associated list is the list of key definitions in the ‘ienc’
item property of this item. The associated key entry shall have a Per_Sample_IV_Size different
from 0, i.e. key entries using constant IV shall not be present in this loop. If this data is read for
the processing of a track sample and aux_info_type_parameter is set to 1, the associated ‘seig’
sample group description entry shall have the multi_key_flag set to 1;
IV indicates the initialization vector to be used for the first block of protected data for the
associated key entry;
multi_subindex indicates the index of the associated key entry, where value one is the first entry,
in the associated list (see multi_subindex_IV) for the following run of encrypted data.
7.2.2
Replace the content of 7.2.2 with the following:
aligned(8) class SampleEncryptionBox extends FullBox(‘senc’, version, flags)
{
unsigned int(32) sample_count;
{
if (version==0) {
unsigned int(Per_Sample_IV_Size*8) InitializationVector;
if (flags & 0x000002) {
unsigned int(16) subsample_count;
{
unsigned int(16) BytesOfClearData;
unsigned int(32) BytesOfProtectedData;
} [subsample_count ]
}
4 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
} else if (version==1) {
unsigned int(16) multi_IV_count;
for (i=1; i <= multi _IV_count; i++) {
unsigned int(8) multi_subindex_IV;
unsigned int(Per_Sample_IV_Size*8) IV;
}
unsigned int(32) subsample_count;
{
unsigned int(16) multi_subindex;
unsigned int(16) BytesOfClearData;
unsigned int(32) BytesOfProtectedData;
} [subsample_count]
}
}[ sample_count ]
}
7.2.3
Add the following to the list of semantics:
— multi_IV_count, multi_subindex_IV, IV and multi_subindex SHALL conform to the definition
specified in Clause 7.
8.1.1
Replace
Container: Movie (‘moov’) or Movie Fragment (‘moof’)
with
Container: Movie (‘moov’) or Movie Fragment (‘moof’) or ‘meta’ if no Movie (‘moov’)
8.2
Add the following new subclauses after 8.2:
8.3 Item encryption box
8.3.1 Definition
Box Type: `ienc’
Container: Item Properties Box
Mandatory (per item): Yes for protected items using schemes defined in this document
© ISO/IEC 2019 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
Quantity (per item): At most one associated with any item
Quantity: Zero or one
Items as defined in ISO/IEC 14496-12 may be protected using the schemes defined in this document. In
this case, such items shall have an associated ItemEncryptionBox property and an associated auxiliary
item with an aux_info_type matching the protection scheme used, as defined in 8.4. The payload of that
auxiliary item shall be exactly one CencSampleAuxiliaryDataFormat as defined in 7.1.
The ItemEncryptionBox contains default values for the isProtected flag, Per_Sample_IV_Size, and KID
for the item. In the case where pattern-based encryption is in effect, it supplies the pattern and when
Constant IVs are in use, it supplies the Constant IV. These values are used as the encryption parameters
for the item in this meta box. For files with only one key for all items, this property box allows the basic
encryption parameters to be specified once for all items instead of being repeated per item.
Items sharing this property are always protected; consequently, the default value for isProtected field
(see 9.1) is 1.
If the value Per_Sample_IV_Size is 0, then the constant_IV_size for all items that use these settings
SHALL be present. A Constant IV SHALL NOT be used with counter-mode encryption.
ItemEncryptionBox properties shall be marked as essential in ItemPropertyAssociation.
NOTE The version field of the ItemEncryptionBox is set to a value greater than zero when the pattern
encryption defined in 9.6 is used and to zero otherwise.
8.3.2 Syntax
aligned(8) class ItemEncryptionBox extends ItemFullProperty(‘ienc’, version, flags=0)
{
unsigned int(8) reserved = 0;
if (version==0) {
unsigned int(8) reserved = 0;
} else { // version is 1 or greater
unsigned int(4) crypt_byte_block;
unsigned int(4) skip_byte_block;
}
unsigned int(8) num_keys;
for (i=1; i<= num_keys; i++) {
unsigned int(8) Per_Sample_IV_Size;
unsigned int(8)[16] KID;
if (Per_Sample_IV_Size == 0) {
unsigned int(8) constant_IV_size;
unsigned int(8)[ constant_IV_size] constant_IV;
}
}
}
6 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
8.3.3 Semantics
version SHALL be zero unless pattern-based encryption is in use, whereupon it SHALL be 1.
crypt_byte_block specifies the count of the encrypted blocks in the protection pattern, where each
block is of size 16-bytes, for items associated with this key entry. See 9.1 for further details.
skip_byte_block specifies the count of the unencrypted blocks in the protection pattern for items
associated with this key entry. See the skip_byte_block field in 9.1 for further details.
num_keys indicates the number of key definition entries.
Per_Sample_IV_Size is the initialization vector size in bytes for items associated with this key entry.
See the Per_Sample_IV_Size field in 9.1 for further details.
KID is the key identifier used for items associated with this key entry. See the KID field in 9.1 for further
details.
constant_IV_size is the size of a initialization vector for items associated with this key entry.
constant_IV, if present, is the initialization vector for items associated with this key entry. See the
constant_IV field in 9.1 for further details.
8.4 Item auxiliary information box
8.4.1 Definition
Box Type: `iaux’
Container: Item Properties Box
Mandatory (per item): Yes for protected items using schemes defined in this document
Quantity (per item): At most one associated with any item
Quantity: Zero or one
An item may have some auxiliary information associated, similarly to sample of a track having auxiliary
sample information. This information is usually declared through item properties and associations; it
can also be declared through auxiliary information items, to allow sharing the auxiliary info between
items and samples through the extent construction method of the item.
Auxiliary information items shall be declared with an item_type value of `auxi’. Items shall indicate
their auxiliary information items through an item reference of type `auxr’ from the item to the auxiliary
information item(s).
Auxiliary information item may have an ItemAuxiliaryInformationBox property associated, indicating
the type of auxiliary information and its parameter type (aux_info_type and aux_info_type_
parameter).
If no ItemAuxiliaryInformationBox is present for an auxiliary information item, then the implied
value of aux_info_type is either (a) in the case of protected content, the scheme_type included in the
ProtectionSchemeInfoBox of the referring item or otherwise (b) the item_type of the referring item. The
default value of the aux_info_type_parameter is 0. The ItemAuxiliaryInformationBox shall be present
when the referring item is not protected and is not defined using version 2 or higher of ItemInfoEntry.
There shall be at most one auxiliary information item with a given aux_info_type and aux_info_type_
parameter associated with an item.
When present, the ItemAuxiliaryInformationBox property shall be marked as essential in
ItemPropertyAssociation.
8.4.2 Syntax
© ISO/IEC 2019 – All rights reserved 7
---------------------- Page: 10 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
aligned(8) class ItemAuxiliaryInformationBox extends ItemFullProperty(‘iaux’, version=0,
flags=0)
{
unsigned int(32) aux_info_type;
unsigned int(32) aux_info_type_parameter;
}
8.4.3 Semantics
aux_info_type: same semantics as sample auxiliary information in ISO/IEC 14496-12.
aux_info_type_parameter: same semantics as sample auxiliary information in ISO/IEC 14496-12.
9.1
In 9.1, replace the semantics of BytesOfProtectedData by:
BytesOfProtectedData specifies the number of bytes of protected data following the clear data
(this value may be zero if no protected bytes exist for this Subsample). The Subsample encryption
entries SHALL NOT include an entry with a zero value in both the BytesOfClearData field and in
the BytesOfProtectedData field unless a 'tref' box is found for this track with one or more track
references of type ‘scal’ pointing to one or more tracks with sample entry code 'encv', in which case
9.5.2.6 applies. The total length of all BytesOfClearData and BytesOfProtectedData in a sample SHALL
equal the length of the sample. Subsample encryption entries SHOULD be as compactly represented as
possible. For example, instead of two entries with {15 clear, 0 protected}, {17 clear, 500 protected} use
one entry of {32 clear, 500 protected}. If pattern-based encryption is used, then the pattern applies to
the protected byte range, BytesOfProtectedData; otherwise all protected bytes are encrypted.
9.5
Add the following text after 9.5.2.5:
9.5.2.6 Subsample encryption applied to NAL structured video with extractors
In this clause, "sample auxiliary information for cenc" refers to the size of the block of clear data and the
size of the block of protected data, regardless whether this is stored as sample auxiliary information
pointed to by 'saiz' and 'saio' boxes or included in a 'senc' box.
In this clause, "extractor track with cenc" refers to a track with sample entry code 'encv' with
original format, as indicated by the 'frma' box in the 'sinf' box, in which extractors, as defined in
1)
ISO/IEC 14496-15:— , Annex A, may be present.
When a 'tref' box is found in an extractor track with cenc which refers to one or more tracks with
sample entry code 'encv', the following restrictions apply in addition to restrictions defined in 9.5.2.2:
— Extraction process SHALL take place before the decryption process.
— Extractors NAL units SHALL NOT be encrypted.
1) Under preparation.
8 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
— The following applies to the sample auxiliary information for cenc found in an extractor track
with cenc.
— When both values of BytesOfClearData and BytesOfProtectedData are 0, it is a placeholder for
the sample auxiliary information for cenc of the NAL Structured Video samples that result from
resolving the constructors within the extractor NAL unit as defined in ISO/IEC 14496-15:—, A.7.
— Otherwise, the values of BytesOfClearData and BytesOfProtectedData apply to the extracted
sub_sample.
— The sample auxiliary information for cenc SHALL be present for each referenced track in ‘tref’ with
sample entry code 'encv'.
— When an extractor NAL unit as defined in ISO/IEC 14496-15:—, A.7 with associated sample auxiliary
information for cenc contains a value of 0 for both BytesOfClearData and BytesOfProtectedData
points to a track with sample entry code ‘encv’:
— Exactly one VCL NAL unit SHALL be encrypted in each subsample of the referenced track.
— Let RefBytesOfClearData and RefBytesOfProtectedData be the sample auxiliary information
for cenc associated with the subsample of which the byte range is extracted, then the sample
auxiliary information for cenc for the resolved VCL NAL unit is SHALL be replaced by the
following values:
BytesOfClearData = RefBytesOfClearData - SampleConstructor.sample_offset +
InlineConstructor.length
BytesOfProtectedData = RefBytesOfProtectedData
The value SampleConstructor.sample_offset is the value of sample_offset in the
SampleConstructor in the extractor that is processed.
The value InlineConstructor.length is the sum of the values in the length fields inside the
InlineConstructor, if any are found in the extractor that is processed, else 0.
— The resulting subsample information SHALL be conformant to CENC, and the decrypted version
of every sample in the extractor track SHALL comply with the file and/or track brand and track
description entry type.
9.7
Add the following subclauses after 9.7, and renumber subsequent figures:
9.8 Content sensitive encryption
9.8.1 Definition
Content sensitive encryption is a bitstream syntax aware scrambling scheme that modifies media
bitstream in such a way that an unauthorized receiver (i.e. a standard decoder) can normally decode the
ciphered stream, while the displayed content is made non-intelligible by the encryption. This scheme is
currently applicable to AVC and HEVC and defined in Annex A. The scheme can be applied to both media
tracks and image items, in which case media tracks shall be in accordance with ISO/IEC 14496-15 and
image items shall be in accordance with ISO/IEC 23008-12.
The scheme operates in compressed domain based on entropic coder, by identifying the elements of the
stream that can be ciphered without disrupting a standard decoding process. The bits to be encrypted
are chosen with respect to the considered video standard to ensure full compatibility, achieved by
selecting the bits (generally parts of code-words) for which each of the encrypted configurations
modifies the decoding process context but does not create de-synchronization nor lead to non-
compliant bitstream.
© ISO/IEC 2019 – All rights reserved 9
---------------------- Page: 12 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
The selected elements will depend on the video coding specification used:
— A.1 gives the list of elements and possible bit encryption for AVC|H264 CAVLC
— A.2 gives the list of elements and possible bit encryption for AVC|H264 CABAC
— A.3 gives the list of elements and possible bit encryption for HEVC|H265
NOTE For CABAC entropic coding (i.e. in A.2 and A.3), the bits considering as cipherable regarding to Content
Sensitive encryption process are listed as bins since the considered codewords are first binarized before the
bypassed Coded Engine.
9.8.2 Content sensitive encryption applied to a video NAL unit
In content sensitive encryption, 16 bytes block cypher cannot be used directly on the payload.
Consequently, a video parser shall be used to locate bits to cipher/decipher. These bits, listed in Annex A,
depend on the coding standard and potentially the entropic coding mode used.
Content sensitive encryption scheme shall use the AES-CTR mode for its cipher.
The encryption and decryption processes are performed with a simple XOR operation between the
identified bits in the syntax and the cypher blocks, as shown in Figure 10.
Figure 10 — Content Sensitive Encryption scheme
Samples protected with content sensitive scheme shall follow subsample encryption of NAL Structured
Video tracks as defined in 9.5.2. The samples shall be divided into one or more contiguous subsamples.
Each subsample consists of an unprotected part of BytesOfClearData, potentially 0, followed by a
protected part. Bits contained in the clear part of the subsample shall not be selected for the decryption
process. The first bit selectable for the encryption process in the range of protected data shall be XORed
with the first bit of the first encrypted cipher block.
The AES-CTR counter shall be incremented after each completely used encrypted cipher block (128 bits)
or at the subsample boundaries; this implies that if not all bits were consumed on the last cipher block
of a subsample, the block shall be considered as consumed and the counter shall be incremented before
processing any subsequent subsample associated with that cipher.
10.1, 10.2, 10.3 and 10.4.1
Replace all uses of
“Encrypted video tracks using NAL”
10 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
with
“Encrypted video tracks or items using NAL”
10.1 and 10.2
Replace
“The version of the TrackEncryptionBox (‘tenc’) SHALL be 0.”
with
“For tracks, the version of the TrackEncryptionBox (‘tenc’) SHALL be 0. For items, the version of the
ItemEncryptionBox (‘ienc’) SHALL be 0.”
10.1
Replace
"Non-video encrypted tracks SHALL be protected using a full sample encryption as specified in
section 9.4."
with
“When a single key applies to each sample, encrypted tracks or items not using NAL structured video
conforming to ISO/IEC 14496-15 SHALL be protected using full sample encryption as specified in
9.4. When multiple keys apply to samples, encrypted tracks or items not using NAL structured video
conforming to ISO/IEC 14496-15 SHALL be protected using subsample encryption as specified in 9.5.1.”
10.2
Replace
“Other tracks SHALL be protected using full sample encryption as specified in section 9.4.”
with
“When a single key applies to each sample, other tracks or items SHALL be protected using full sample
encryption as specified in 9.4. When multiple keys apply to samples, other tracks or items SHALL be
protected using subsample encryption as specified in 9.5.1.”
10.3 and 10.4
Replace
“The version of the TrackEncryptionBox (‘tenc’) SHALL be 1.”
with
“For tracks, the version of the TrackEncryptionBox (‘tenc’) SHALL be 1. For items, the version of the
ItemEncryptionBox (‘ienc’) SHALL be 1.”
10.3
Replace
© ISO/IEC 2019 – All rights reserved 11
---------------------- Page: 14 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
"Tracks other than video are protected using whole-block full-sample encryption as specified in 9.7,
and hence skip_byte_block SHALL be 0."
with
“When a single key applies to each sample, encrypted tracks or items not using NAL structured video
conforming to ISO/IEC 14496-15 SHALL be protected using whole-block full-sample encryption
as specified in 9.7, and hence skip_byte_block SHALL be 0. When multiple keys apply to samples,
encrypted tracks or items not using NAL structured video conforming to ISO/IEC 14496-15 SHALL be
protected using subsample encryption as specified in 9.5.1.”
10.4
Replace
"Tracks other than video MAY be protected using whole-block full-sample encryption as specified in 9.6
or 9.7, and hence skip_byte_block SHALL be 0."
with
“When a single key applies to each sample, encrypted tracks or items not using NAL structured video
conforming to ISO/IEC 14496-15 MAY be protected using whole-block full-sample encryption as
specified in 9.6 or 9.7, and hence skip_byte_block SHALL be 0. When multiple keys apply to samples,
encrypted tracks or items not using NAL structured video conforming to ISO/IEC 14496-15 SHALL be
protected using subsample encryption as specified in 9.5.1.”
10.4
Add the following subclause after 10.4:
10.5 ‘sve1’ AES-CTR sensitive encryption scheme
Support for the ‘sve1’ scheme is optional.
The scheme_type field of the scheme Type Box (‘schm’) SHALL be set to the four-character code ‘sve1’.
Tracks or items carrying media coding types for which no sensitive encryption mode is defined in
Annex A shall not use this protection scheme.
Encrypted video tracks or items using NAL unit structured video conforming to ISO/IEC 14496-15
SHALL be protected using Subsample encryption specified in 9.5 and SHALL use sensitive encryption
as specified in 9.8. The NAL unit header should be left in the clear part of the subsample.
NOTE In AVC CAVLC, the slice header can be encrypted but can still be parsed.
Pattern encryption SHALL NOT be used. As a result, the fields crypt_byte_block and skip_byte_block
SHALL be 0 and the version of the Track Encryption Box (‘tenc’) SHALL be 0.
Non-video encrypted tracks SHALL be protected using full-sample encryption as specified in 9.4 and
SHALL use sensitive encryption as specified in 9.8.
For tracks, the version of the TrackEncryptionBox (‘tenc’) SHALL be 0. For items, the version of the
ItemEncryptionBox (‘ienc’) SHALL be 0.
Constant IVs SHALL NOT be used; Per_Sample_IV_Size SHALL NOT be 0, except for unencrypted
sample groups.
11.3.4
12 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 15 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
Following 11.3.4, add the following annex:
© ISO/IEC 2019 – All rights reserved 13
---------------------- Page: 16 ----------------------
ISO/IEC 23001-7:2016/Amd.1:2019(E)
Annex A
(normative)
Content sensitive encryption scheme
A.1 Code-words containing bits selected for encryption for MPEG-4/AVC CAVLC
A.1.1 General
This annex gives the list of all VLC tables and code words that shall be encrypted by the content
sensitive encryption process for AVC|H264 CAVLC mode (i.e. entropy_coding_mode is equal to 0 in
ISO/IEC 14496-10 in Picture Parameter set RBSP syntax).
A.1.2 Slice QP Delta
In ISO/IEC 14496-10:2014, 7.3.3 (Slice header syntax), slice_qp_delta is coded in se(v) (i.e. signed
Exponential-Golomb code-word), and the value is given in Table A.1. But the value of slice_qp_delta shall
be limited such that SliceQP is in the range of −QpBdOffset to +51, inclusive. So this code-word is
Y Y
eligible to be cyphered if, and only if, its absolute value is less than:
Floor LogM22in QpBdOffset ++62pici__nitqpm_,inus 625−pici_ nittq__pminus26
()()
( )
Y
2 (1)
Then, the su
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.