ISO/IEC 19566-4:2020
(Main)Information technologies — JPEG systems — Part 4: Privacy and security
Information technologies — JPEG systems — Part 4: Privacy and security
This document specifies privacy and security features which contribute to a system layer for JPEG standards. It defines generic structures that can be applied in all JPEG box-based file formats. In particular, this document specifies a signalling syntax supporting privacy and security features. The framework in this document is backwards-compatible with existing JPEG standards.
Titre manque — Partie 4: Titre manque
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 19566-4
First edition
2020-03
Information technologies — JPEG
systems —
Part 4:
Privacy and security
Reference number
ISO/IEC 19566-4:2020(E)
©
ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC 19566-4:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2020
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 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 19566-4:2020(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Definitions . 1
3.2 Abbreviated terms . 2
4 Conventions . 2
4.1 Conformance language . 2
4.2 Naming conventions for numerical values . 3
4.3 Boxes and superboxes. 3
4.4 Graphical descriptions . 4
5 Organization of the document . 4
Annex A (normative) Content protection and replacement . 5
Annex B (informative) Usage examples .14
Bibliography .29
© ISO/IEC 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 19566-4:2020(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 19566 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.
iv © ISO/IEC 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 19566-4:2020(E)
Introduction
This document contributes to the specification of system-level functionalities. In particular, it
specifies functionalities to provide a degree of trust while sharing image content and metadata, which
simultaneously also allow the signalling of the associated access policies.
A huge number of images are distributed over the internet on a daily basis. For social media alone,
this already accounts for over 3 billion pictures. These photos are often shared with many people
without protection for personal information or access control. In addition, many portable devices have
communication functionality that allows for the immediate distribution of photos after capturing them.
In combination with the potential inclusion of GPS information in the file format, for example, the photo
might expose private and geo-location information to the world.
In order to avoid such undesirable situations, the framework in this document provides protection
mechanisms to the JPEG family of standards. For instance, encryption can be used to protect image data
The particular focus of this document is to provide codestream and file format syntax support to enable
security and privacy functionality for JPEG standards, not only in support of ISO/IEC 10918-1, but also
for standards such as ISO/IEC 15444 and ISO/IEC 18477.
© ISO/IEC 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 19566-4:2020(E)
Information technologies — JPEG systems —
Part 4:
Privacy and security
1 Scope
This document specifies privacy and security features which contribute to a system layer for JPEG
standards. It defines generic structures that can be applied in all JPEG box-based file formats. In
particular, this document specifies a signalling syntax supporting privacy and security features. The
framework in this document is backwards-compatible with existing JPEG standards.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ITU-T T.81 | ISO/IEC 10918-1, Information technology — Digital compression and coding of continuous-
tone still images: Requirements and guidelines
ISO/IEC 18477-3, Information technology — Scalable compression and coding of continuous-tone still
images box file format
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
ISO/IEC 19566-5, Information technology — JPEG systems — Part 5: JPEG universal metadata box format
3 Terms and definitions
3.1 Definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1.1
box
binary structure that encapsulates an object embedded in a file
[SOURCE: ISO/IEC 19566-5:2019, 3.1.1]
3.1.2
codestream
sequence of bits representing a compressed image and associated metadata
[SOURCE: ISO/IEC 19566-5:2019, 3.1.2]
© ISO/IEC 2020 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 19566-4:2020(E)
3.1.3
decrypted content
resulting data after applying the signalled decryption process on the encrypted content
3.1.4
master image
image file in which the box (3.1.1) is embedded
3.1.5
JPEG-1 image
image encoded in JPEG file format
Note 1 to entry: The image shall be encoded in compliance to ISO/IEC 10918-1.
3.1.6
box-based file format
file format whose composing elements are boxes containing structured data in compliance with ISO-
based media file format
3.1.7
JPEG XT image
image encoded in the JPEG XT file format
Note 1 to entry: the images shall be encoded in compliance to ISO/IEC 18477.
3.1.8
Replacement Data box
sequence of boxes (3.1.1) of any type embedded in a JUMBF Replacement box
3.2 Abbreviated terms
JPEG joint photographic experts group
JUMBF JPEG universal metadata box format
P&S privacy and security
ROI region of interest
TOG toggles
4 Conventions
4.1 Conformance language
In this document, the following verbal forms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission;
— “can” indicates a possibility or a capability.
Information marked as “NOTE” is intended to assist the understanding or use of the document. “Notes
to entry” used in Clause 3 provide additional information that supplements the terminological data and
can contain provisions relating to the use of a term.
2 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 19566-4:2020(E)
The keyword "reserved" indicates a provision that is not specified at this time, shall not be used, and
may be specified in the future. The keyword "forbidden" indicates "reserved" and in addition indicates
that the provision will never be specified in the future.
4.2 Naming conventions for numerical values
Integer numbers are expressed as bit patterns, hexadecimal values, or decimal numbers. Bit patterns
and hexadecimal values have both a numerical value and an associated particular length in bits.
Hexadecimal notation, indicated by prefixing the hexadecimal number by "0x", may be used instead of
binary notation to denote a bit pattern having a length that is an integer multiple of 4. For example, 0x41
represents an eight-bit pattern having only its second most significant bit and its least significant bit
equal to 1. Numerical values that are indicated as "binary" are bit pattern values (specified as a string
of digits equal to 0, 1 or x in which the left-most bit is considered the most-significant bit and 'x' means
either 0 or 1). Other numerical values not prefixed by "0x" are decimal values. When used in expressions,
a hexadecimal value is interpreted as having a value equal to the value of the corresponding bit pattern
evaluated as a binary representation of an unsigned integer (i.e., as the value of the number formed by
prefixing the bit pattern with a sign bit equal to 0 and interpreting the result as a two's complement
representation of an integer value). For example, the hexadecimal value 0xF is equivalent to the 4-bit
pattern '1111' and is interpreted in expressions as being equal to the decimal number 15.
4.3 Boxes and superboxes
Annex A shall be used for the specification of boxes. The details for embedding boxes in specific file
formats are defined in the particular specifications, for example, ISO/IEC 15444-1 for JPEG 2000,
ISO/IEC 18477-3 for JPEG-1 and JPEG XT or the more generic ISO/IEC 14496-12 ISO base media file
format (ISOBMFF).
In general, each object in the file is encapsulated within a binary structure called a box. A box that only
contains other boxes is called a superbox. The binary structure is given in Figure 1.
Figure 1 — Binary structure of a box
— LBox: Box length. This field specifies the length of the box, stored as a 4-byte big-endian unsigned
integer. This value includes all of the fields of the box, including the length and type. If the value of
this field is 1, then the XLBox field shall exist and the value of that field shall be the actual length of
the box. If the value of this field is 0, then the length of the box was not known when the LBox field
was written. In this case, this box contains all bytes up to the end of the file. If a box of length 0 is
contained within another box (its superbox), then the length of that superbox shall also be 0. This
means that this box is the last box in the file. The values 2-7 are reserved for ITU-T | ISO use.
— TBox: Box type. This field specifies the type of information found in the Payload Data field. The value
of this field is encoded as a 4-byte big-endian unsigned integer. However, boxes are generally referred
to by an ISO/IEC 646 character string translation of the integer value. For all box types defined
within this document, box types will be indicated as both character string and as 4-byte hexadecimal
integers. Also, a space character is shown in the character string translation of the box type as "\040".
All values of TBox not defined within this document are reserved for ITU-T | ISO/IEC use.
— XLBox: Box extended length. This field specifies the actual length of the box if the value of the LBox
field is 1. This field is stored as an 8-byte big-endian unsigned integer. The value includes all of the
fields of the box, including the LBox, TBox and XLBox fields.
© ISO/IEC 2020 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 19566-4:2020(E)
— Payload Data: Box contents. This field contains the actual information contained within this box. The
format of the box contents depends on the box type and will be defined individually for each type.
4.4 Graphical descriptions
Box definitions contain graphical description figures to illustrate the structure of the box. These figures
should be interpreted as follows:
— The figures do not include box type and length fields.
— A sequence of rectangles is used to indicate the remaining fields of the box and their order.
— The width of the rectangle indicates the length of the field, a square rectangle indicates a 16-bit field.
— A grey background indicates a variable length field.
— Optional fields have a dashed border.
Figure 2 shows an illustrative example of a box with four fields:
— A: 8-bit required field;
— B: 16-bit required field;
— C: variable length required field;
— D: optional 32-bit field.
Figure 2 — Box with four fields
5 Organization of the document
This document is organized as follows:
— Annex A specifies the mechanisms for content protection and replacement to support privacy and
security features.
— Annex B provides several illustrative usage examples.
4 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 19566-4:2020(E)
Annex A
(normative)
Content protection and replacement
A.1 General
This annex specifies mechanisms for content protection and replacement. Content protection and
replacement can be combined to support partial image protection. This annex builds upon the
JPEG universal metadata box format (JUMBF), hence all implementations shall be compliant with
ISO/IEC 19566-5.
A.2 Content protection
A.2.1 General
Content protection enables the protection of parts of an image file by encryption. When decoding
an image file with protected content, the protected content shall be decrypted using the signalled
encryption method, provided that the encryption method is supported by the decoder and authorization
is granted. In case the protected content cannot be decrypted, the entire protected content shall be
ignored. The process is illustrated in Figure A.1.
Figure A.1 — Content protection decoding process
The protected content is embedded in the master image file as a JUMBF box with Content Type
“Protection”, as specified in A.2.2.
© ISO/IEC 2020 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 19566-4:2020(E)
A.2.2 JUMBF Protection box
The JUMBF Protection box is a JUMBF box with Content Type Protection (UUID: 74B11BBF-F21D-4EEA-
98C1-0BEBF23AEFD3). The structure of the JUMBF Protection box is given in Figure A.2.
Figure A.2 — Structure of the JUMBF Protection box
In addition to the JUMBF Description box, the JUMBF Protection box contains a Protection Description
box and one Binary Data box. The Binary Data box encapsulates data which is encrypted according
to the scheme signalled in the Protection Description box. The resulting decrypted content shall
encompass any binary data, provided that when the entire JUMBF Protection box is replaced with the
decrypted content, the resulting image file shall be a valid image according to the specification of the
master image. More specifically, the decrypted content can be one instance or a sequence of APP marker
segments (JPEG-1 and JPEG XT only) or boxes.
A.2.3 Protection Description box
The Protection Description box signals additional information about the protected content.
The type of a Protection Description box shall be 'pspd' (0x7073 7064). The binary structure of the
Protection Description box is illustrated in Figure A.3, the field values are summarized in Table A.2.
Figure A.3 — Structure of the Protection Description box
— METHOD: The values of the METHOD parameter and corresponding meanings are given in Table A.1.
6 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 19566-4:2020(E)
Table A.1 — METHOD field specification
METHOD binary
Meaning Details
value
000x 0000 External Information about the used encryption method is provided in a
referenced JUMBF box. The METHOD field shall be followed by the ENC
LABEL field that contains the label of the JUMBF box as null terminated
ISO/IEC 10646 characters in the UTF-8 encoding.
000x 0001 AES 256 CBC The content of the Binary Data box is encrypted using AES 256 using
the CBC cipher mode (in accordance with ISO/IEC 18033-3).
000x 0010 AES 256 CBC with The content of the Binary Data box is encrypted using AES 256 using
IV the CBC cipher mode (in accordance with ISO/IEC 18033-3). The
Initialisation Vector (IV) is signalled after the METHOD field and
optional AR LABEL field in the 128-bit length IV field.
0001 xxxx access rules Access rules are provided in a referenced JUMBF box. The METHOD
field, and optionally the ENC LABEL, are followed by an AR LABEL
field. The AR LABEL (for referencing the access rules) shall contain the
label of a JUMBF box as null terminated ISO/IEC 10646 characters in
the UTF-8 encoding.
All other values are reserved for future use.
— ENC LABEL: optional label referencing to a JUMBF Box that signals the used encryption method
of the data in the Binary Data box. Its presence is indicated by the value of the METHOD field as
specified in Table A.1.
— AR LABEL: optional label referencing to a JUMBF Box that signals the access policy rules of the data
in the Binary Data box. Its presence is indicated by the value of the METHOD field as specified in
Table A.1.
— IV: initialisation vector used to encrypt the data in the Binary Data box. Its presence is indicated by
the value of the METHOD field as specified in Table A.1.
Table A.2 — Format of the contents of the Protection Description box
Parameter Size (bits) Value
METHOD 8 See Table A.1
ENC LABEL variable Optional null terminated
UTF-8 string.
AR LABEL variable Optional null terminated
UTF-8 string.
IV 128 Optional 128 bit initialisation
vector
A.2.4 Binary Data box
The Binary Data box encapsulates binary data. The type of the binary data shall be implied by its
context, otherwise the binary data shall be ignored. For example, in the context of the JUMBF Protection
box the type of binary data is encrypted data as signalled in the Protection Description box. The type
of a Binary Data box shall be 'bidb' (0x6269 6462). The contents of the box shall be as in Figure A.4, the
fields are summarized in Table A.3.
Figure A.4 — Organization of the contents of the Binary Data box
© ISO/IEC 2020 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 19566-4:2020(E)
— DATA: This field contains binary data.
Table A.3 — Format of the contents of the Binary Data box
Field name Size (bits) Value
Data Variable Variable length binary
data
A.2.5 Decoding procedure
When a JUMBF Protection box is encountered, the encapsulated encrypted content shall be decrypted
using the signalled encryption method, provided that the encryption method is supported by the
decoder and authorization is granted. If the encrypted data is successfully decrypted, the resulting
decrypted content replaces the entire JUMBF Protection box. In case the data cannot be decrypted,
the entire JUMBF Protection box is ignored. Thereafter, in both cases decoding proceeds as usual. The
process is illustrated in Figure A.1.
A.3 Replacements
A.3.1 General
Replacements allow to replace part of an image file or the entire image file with different content. Four
types of replacements can be distinguished:
— box replacement type: replaces a box with one or more boxes:
— app marker segment replacement type: replaces an app marker segment with one or more app
marker segments (can only be used with JPEG-1 and JPEG XT);
— region of interest replacement type: replaces a region of interest in the image stream with
another image;
— File replacement type: replaces the entire file.
When a JUMBF Replacement box is encountered, the associated replacement shall be applied first.
Thereafter, the resulting file is decoded as usual. Except in case of a ROI replacement the image stream
and ROI are first decoded individually. Subsequently the ROI is inserted in the signalled region of the
decoded image. The process is illustrated in Figure A.5.
8 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 19566-4:2020(E)
Figure A.5 — Replacement process
In case multiple replacements occur in a single file, the replacements should be applied sequentially in
the order that they appear in the file.
A.3.2 JUMBF Replacement box
The JUMBF Replacement box is a JUMBF box with Content Type Replacement (UUID: DC28B95F-B68A-
498E-8064-0FCA845D6B0E). The structure of the JUMBF Replacement box is given in Figure A.6.
© ISO/IEC 2020 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/IEC 19566-4:2020(E)
Figure A.6 — Structure of the JUMBF Replacement box
In addition to the JUMBF Description box the JUMBF Replacement box contains a Replacement
Description box and one or more boxes referred to as Replacement Data Boxes. The valid box types of
the Replacement Data Boxes are determined by the type.
A.3.3 Replacement Description box
The Replacement Description box signals additional information about the behaviour and type of the
replacement.
The type of a Replacement Description box shall be 'psrd' (0x7073 7264). The binary structure of the
Replacement Description box is illustrated in Figure A.7 and summarized in Table A.7.
Figure A.7 — Structure of the Replacement Description box
The allowed values and meanings of the TYPE and TOG(GLES) fields are described in Table A.4 and
Table A.5 respectively.
Table A.4 — TYPE specification
TYPE binary
Meaning Details
value
0000 0000 TYPE BOX Box replacement type.
0000 0001 TYPE APP App marker segment replacement type.
0000 0010 TYPE ROI Region of interest replacement type.
0000 0011 TYPE FILE File replacement type.
All other values are reserved for future use.
10 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 15 ----------------------
ISO/IEC 19566-4:2020(E)
Table A.5 — TOG(GLES) specification
TOG(GLES)
Meaning Details
binary value
0000 0000 Auto apply Auto apply. Signals if the replacement should be applied by default
or ignored. If auto apply is disabled, the replacement can be triggered
0000 0001 Do not auto
on demand.
apply
All other values are reserved for future use.
The structure of the PARAM field is determined by the replacement TYPE. Figure A.8 gives an overview
of the structure of the Replacement Description box per Replacement TYPE.
Figure A.8 — Structure of the Replacement Description box per TYPE
Table A.6 gives an overview of the field values and meanings.
Table A.6 — Description of the PARAM fields per TYPE
Replacement Size (bits) and
Parameter Value and details
TYPE type
BOX OFFSET 64; Unsigned 64-bit value of the byte offset of the position of the
Integer Replacement target box counting from the
beginning of the file.
When set to 0, replace the successive box.
64
When set to 2 -1 (0xFFFFFFFFFFFFFFFF), replace
the JUMBF box with the label specified in the
LABEL field.
LABEL Variable; Null Label of the Replacement target JUMBF box.
terminated
UTF-8 string.
APP OFFSET 64; Unsigned 64-bit value of the byte offset of the position of the
Integer Replacement target app marker segment counting
from the beginning of the file.
When set to 0, replace the successive APP marker
segment.
© ISO/IEC 2020 – All rights reserved 11
---------------------- Page: 16 ----------------------
ISO/IEC 19566-4:2020(E)
Table A.6 (continued)
Replacement Size (bits) and
Parameter Value and details
TYPE type
ROI OFFSET X 32; Unsigned Vertical offset from the top in pixels.
Integer
OFFSET Y 32; Unsigned Horizontal offset from the left in pixels.
Integer
Table A.7 — Format of the contents of the JUMBF Description box
Parameter Size (bits) Value
TYPE 8 See Table A.4
TOGGLES (TOG) 8 See Table A.5
PARAM variable See Table A.6
A.3.4 Box replacement
The referenced box is replaced with all Replacement Data Boxes. The box is either referenced by offset,
JUMBF label, or position of the JUMBF Replacement box, as specified in Table A.6.
A.3.5 APP marker segment replacement
With the APP marker segment replacement type the Replacement Data boxes shall be exactly one
Binary Data box. The referenced APP marker segment is replaced with the content of the Binary Data
box. The APP marker segment is either referenced by offset or position of the JUMBF Replacement box if
the offset is set to 0, as specified in Table A.6.
A.3.6 ROI replacement
Replaces a region of interest (ROI) in the parent image. The replacement is applied after decoding the
parent image. The Replacement Data boxes shall contain exactly one Contiguous Codestream box.
NOTE In ISO/IEC 10918-1 (JPEG-1) and ISO/IEC 18477 (JPEG XT) images the replacement ROI may be a JPEG
XT image with a transparency layer.
The position of the ROI is determined by the vertical and horizontal offsets x and y as illustrated in
Figure A.9. The height of the ROI should be smaller than the size of the parent image minus offset x and
the width smaller than width master image minus offset y.
Figure A.9 — Illustration of the x and y offsets of the ROI relative to the master image
12 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 17 ----------------------
ISO/IEC 19566-4:2020(E)
A.3.7 File replacement
Replaces the entire file. The Replacement Data boxes shall contain exactly one Contiguous Codestream
box that contains the replacing image.
© ISO/IEC 2020 – All rights reserved 13
---------------------- Page: 18 ----------------------
ISO/IEC 19566-4:2020(E)
Annex B
(informative)
Usage examples
B.1 General
Usage examples in B
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.