ISO/TS 21219-24:2017

TECHNICAL ISO/TS
SPECIFICATION 21219-24
First edition
2017-02
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 24:
Light encryption (TPEG2-LTE)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 24: Cryptage léger (TPEG2-LTE)
Reference number
©
ISO 2017
© ISO 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2017 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Light Encryption specific constraints . 4
5.1 Version number signalling . 4
5.2 Extendibility . 4
5.3 Endianness . 4
5.4 Supported business models . 4
5.5 Performance requirements . 5
5.5.1 Repetition rate of light encryption parameters . 5
5.5.2 Update rate of light encryption parameters . 5
5.6 License agreement and security requirements . 5
5.6.1 General. 5
5.6.2 Security requirements on service providers . 6
5.6.3 Security requirements on client manufacturers . 6
6 Light encryption method of encryption and operation . 6
6.1 Principles of operation for light encryption . 6
6.2 Overview of the light encryption method . 7
6.2.1 General. 7
6.2.2 TISA secret KeyTable and TISAparameterInConfidence . 8
6.3 Encryption and decryption of service data frame payload data . 9
6.3.1 General. 9
6.3.2 Block cipher mode of operation . 9
6.3.3 Initialisation Vector .11
6.4 Encryption and decryption of transmitted Control Words .11
6.5 Service Key composition .12
6.5.1 General.12
6.5.2 Light Encryption modes 1 and 2 common parameters for Service
Key composition .13
6.5.3 Light Encryption Mode 1 specific parameters for Service Key composition .14
6.5.4 Light Encryption Mode 2 specific parameters for Service Key composition .14
6.5.5 Example Service Key Composition .14
7 Light Encryption structure and embedding in TPEG service data frames .16
7.1 General .16
7.2 Light encryption embedding in TPEG service data frames .16
7.3 Light Encryption components .16
7.4 LTE tables . .18
7.5 Initialisation Vector composition .18
7.6 Service Key composition .18
8 LTE components .19
8.1 LteInformation .19
8.2 LteParameters .19
8.3 LteMode1Parameters .20
8.4 LteMode2Parameters .20
8.5 Mode1EMMessage .21
8.6 Mode2EMMessage .21
9 LTE Datatypes .22
9.1 ControlWord .22
9.2 Nonce .22
10 LTE Tables .23
10.1 lte001:Lig htEncryptionMode .23
Annex A (normative) TPEG application, TPEG-Binary Representation .24
Annex B (normative) TPEG application, TPEG-ML Representation .30
Annex C (informative) Light Encryption Guidelines .33
iv © ISO 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents 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 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).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on 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 the following URL: http:// www .iso .org/ iso/
foreword .html
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
A list of all the parts in the ISO 21219 series can be found on the ISO website.
Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the Syntax,
Semantics and Framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for Road Traffic Messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
Further parts were developed to make the initial set of four parts enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the Service and Network Information
Application used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
Public Transport Information Application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information, was
issued as ISO/TS 18234-6 to be used in association with the other applications parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG Applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of rules
that contain the modelling strategy covered in ISO/TS 21219-2, ISO/TS 21219-3, ISO/TS 21219-4 and
the conversion to two current physical formats: binary and XML; others could be added in the future.
TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word
document file, to minimize drafting errors, that forms the Annex for each physical format.
vi © ISO 2017 – All rights reserved

TPEG2 has a three container conceptual structure: Message Management (ISO/TS 21219-6), Application
1)
(many Parts) and Location Referencing (ISO/TS 21219-7 ). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many Location Referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the Location Referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR
(ISO/TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC
(ISO/TS 21219-6), TPEG2-LRC (ISO/TS 21219-7), TPEG2-LTE (ISO/TS 21219-24);
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10);
2) 3)
— Location referencing: TPEG2-ULR (ISO/TS 21219-11 ), TPEG2-GLR (ISO/TS 21219-21 ), TPEG2-
4)
OLR (ISO/TS 21219-22 );
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO/TS 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This document is based on the TISA specification technical/editorial version reference:
SP14002/1.0/001
1) Under development.
2) To be published.
3) Under development.
4) Under development.
TECHNICAL SPECIFICATION ISO/TS 21219-24:2017(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 24:
Light encryption (TPEG2-LTE)
1 Scope
This document defines the LTE encryption mechanism for TPEG Service Data Frames. It has been
specifically designed for use with Business to Business (B2B) business models.
The objective of this document is to provide a simple to use, yet effective Conditional Access mechanism
for TPEG including encryption for use with both broadcast and/or point-to-point delivery.
For both service providers and device manufacturers, a standardized conditional access mechanism is
beneficial to avoid a proliferation of proprietary methods with multiplied implementation effort and
lead times.
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.
ISO/TS 21219-1, Intelligent transport systems (ITS) — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and version (TPEG2-INV)
ISO/TS 21219-2, Intelligent transport systems (ITS) — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 2: UML modeling rules (TPEG2-UMR)
ISO/TS 21219-3, Intelligent transport systems (ITS) — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules (TPEG2-UBCR)
ISO/TS 21219-4, Intelligent transport systems (ITS) — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 4: UML to XML conversion rules (TPEG2-UXCR)
ISO/TS 21219-5, Traffic and travel information (TTI) via transport protocol experts group, generation 2
(TPEG2) — Part 5: TPEG service framework (TPEG2-SFW)
ISO/TS 21219-9, Traffic and travel information (TTI) via transport protocol experts group, generation 2
(TPEG2) — Part 9: Service and network information (TPEG2-SNI)
Federal Information Processing Standards Publication 197 — Specification for the ADVANCED
ENCRYPTION STANDARD (AES), November 26, 2001
NIST Special Publication 800-38A:2001 Recommendation for Block Cipher Modes of Operation: Methods
and Techniques
3 Terms and 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:
— IEC Electropedia: available at http:// www .electropedia .org/
— ISO Online browsing platform: available at http:// www .iso .org/ obp
3.1
access controlled
conditions for use apply for which permission in writing is required
3.2
block cipher
family of functions and their inverse functions that is parameterized by cryptographic keys
Note 1 to entry: The functions map bit strings of a fixed length to bit strings of the same length.
3.3
block cipher mode of operation
algorithm that uses a block cipher to provide an information service such as confidentiality or
authenticity
3.4
Control Word
cryptographic key used to protect the data stream, i.e. the payload data in a TPEG service data frame,
by means of encryption
3.5
cryptographic key
parameter used in the block cipher algorithm that determines the forward cipher operation and the
inverse cipher operation
3.6
encryption
process of encoding messages (or information) in such a way that only authorized parties can read it
3.7
service key
cryptographic key used to encrypt the transmission of the Control Word
Note 1 to entry: Service keys may be customer specific.
3.8
TPEG application
application layer protocol fulfilling the general TPEG requirements at the highest layer of the ISO OSI
model and standardized by TISA/ISO
Note 1 to entry: A TPEG Application consists of a set of classes and rules for encoding information required to a
traffic information service.
3.9
TPEG service
multiplex of TPEG Service Components with a dedicated Service Identifier
3.10
TPEG service component
virtual channel for messages of a dedicated TPEG Application
3.11
TPEG service multiplex
multiplex of TPEG Services within one data stream or file
2 © ISO 2017 – All rights reserved

3.12
service frame
data structure implementing the TPEG Service in the TPEG binary representation
3.13
service component frame
data structure implementing the TPEG Service Component stream in the TPEG binary representation
3.14
service data frame
service frame of type 1 containing TPEG service data as a multiplexed set of Service Component Frames
3.15
unrestricted access
no conditions for use apply, may be freely used without any permission or authorization
4 Abbreviated terms
AES Advanced Encryption Standard
B2B Business to Business
CRC Cyclic Redundancy Check
CTR Counter (a block cipher mode of operation)
CW Control Word
EBU European Broadcasting Union
ECB Electronic Code Book (a block cipher mode of operation)
EMM Entitlement Management Message
FRAND Fair, Reasonable and Non-Discriminatory
LTE LighT Encryption
ServEncID Service encryption indicator (signalled in a TPEG Service Data Frame)
SID TPEG Service ID
SFW TPEG Service Framework: Modelling and Conversion Rules
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modelling Language
XOR eXclusive OR operation (a bit manipulation technique)
5 Light Encryption specific constraints
5.1 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions may have an impact on client devices.
The version numbering principle is defined in ISO/TS 21219-1.
Table 1 shows the current version numbers for signalling LTE:
Table 1 — Current version numbers for signalling of LTE
major version number 1
minor version number 0
5.2 Extendibility
Light Encryption is based on a TPEG2 style specification of encryption parameters. Light Encryption
information and parameters specifications are specified with a TPEG2 component, in accordance
with the TPEG2 modelling rules in ISO/TS 21219-2 (TPEG2-UMR), ISO/TS 21219-3 (TPEG2-UBCR) and
ISO/TS 21219-4 (TPEG2-UXCR). Future LTE extensions then may insert new components or may replace
existing components by new ones without losing backward compatibility. That means an LTE decoder
shall be able to detect and skip unknown components.
5.3 Endianness
TPEG assumes big endian representation of all multi byte constructs in the TPEG binary representation
defined in ISO/TS 21219-3 (TPEG2-UBCR)), as does the AES standard (Federal Information Processing
Standards Publication 197) and the NIST recommendation for Block Cipher Mode of Operations (NIST
Special Publication 800-38A).
This document also assumes a big endian representation throughout, i.e. the Most Significant Byte/Bit
is transmitted/stored first, and the Least Significant Byte/Bit is transmitted/stored last.
5.4 Supported business models
This document supports a number of common business models with the following two modes of
encryption:
— Light Encryption Mode 1: free to air, yet encrypted transmission of TPEG data;
— Light Encryption Mode 2: controlled access, encrypted transmission of TPEG data, on basis of a
business-2-business contract agreement.
Mode 1 is a generic mode, which does not differentiate between various client devices nor manufacturers.
Mode 2 targets business-to-business (B2B) relations. This mode is able to differentiate various (B2B)
customers.
In mode 2, a service provider is able to activate or revoke access to its service by changing its
transmission scheme. Moreover, in mode 2, access can be separately activated for individual (B2B)
customers.
Conversely, in mode 2, access can also be revoked separately for individual (B2B) customers, through
updates of the transmitted Light Encryption parameters. In this last use case, new encrypted Control
Words will be provided to all customers except the revoked B2B customer. This revoked customer is no
longer able to decrypt TPEG data, due to the lack of the new version of the Control Word.
4 © ISO 2017 – All rights reserved

Table 2 — Supported business models
Business model B2B relation estab- B2B relation established after sale of No relation, unre-
lished before sale device stricted access
of device
Service type Mode 2, Access Controlled Service Mode 1, free Trial Mode 1, Free-to-
Service Air Service
B2B Keys exchanged before sale of device
Activation model B2B Service Keys B2B Service Keys Temporary free Permanent free to
given to established given to potential service; activation air service
customers customers by SP only
(no access rights
On-air Activation On-air Activation (no access rights management
before sale of device only after establish- management required for client
ment B2B relation required for client manufacturer)
manufacturer, free
service kept alive
until Software Up-
date o client devices)
Table 2 shows a number of supported business models. Light Encryption Mode 1 can be used either as a
temporary, free trial service or as a permanent free-to-air service with encrypted content.
Mode 2 supports business-to-business relationships. When a B2B relationship is established before
the sale of the client device, all necessary precautions should be taken such as exchange of needed
“parameters-in-confidence”. Light Encryption provides the means for a service provider to activate
access for the particular customer after the commencement of a contract agreement. In advance,
by pre-allocating and pre-sharing “parameters-in-confidence” with a potential customer, device
manufacturers are able to prepare their devices ahead of service transmissions. In this way, potential
B2B user devices can be prepared in parallel to a contract agreement, reducing or eliminating lead-time
for device implementations.
5.5 Performance requirements
5.5.1 Repetition rate of light encryption parameters
All necessary entitlement parameters for any access-permitted TPEG client (i.e. a client with active
access permissions to the current state of the service) to start using the service and decrypting its
content shall be available with a repetition rate of one minute or less. This is to reduce start-up latency.
Advance information of upcoming changes in entitlement parameters may be distributed at a slower
rate. Clients are recommended to store relevant encryption parameters and Control Words over power-
down cycles for fastest start-up. The Control Word Version ID (attribute CWversionID) signals the
version in use, and clients shall match stored versions with the signalled version before proceeding
with decryption on basis of stored parameters.
5.5.2 Update rate of light encryption parameters
Encryption parameters and consequent Control Word versions should be updated infrequently, but
shall not be updated more than once every 10 min. TPEG clients may receive reliably all necessary
parameters, even under less than perfect reception conditions.
5.6 License agreement and security requirements
5.6.1 General
This document uses two secret pieces of information (cryptographic parameters – see 6.2.1). These are
distributed by TISA under FRAND conditions, but subject to a license agreement. The license agreement
with TISA shall ensure strict confidentiality in handling, storage, and proper use (for intended purposes
only) of these secret cryptographic parameters.
5.6.2 Security requirements on service providers
5.6.2.1 Development
During development of Light Encryption, service providers should limit to a minimum the personnel
having access to the secret cryptographic parameters distributed by TISA, and any customer and
service specific cryptographic parameters. Development artefacts related to these parameters shall be
stored in a protective fashion, to prevent unauthorized access.
5.6.2.2 Operation
During Light Encryption operations (including service key, Control Word and
customerParameterInConfidence generation, and generation of encrypted content) access to server
rooms and servers running Light Encryption operations or storing Light Encryption parameters should
be protected. Physical storage of all cryptographic parameters should be governed by a conditional
access mechanism including encryption. The chosen protection scheme should make it difficult to find,
use, or replace confidential cryptographic parameters.
The Service Provider should limit to a minimum personnel having access to servers running Light
Encryption or storing Light Encryption cryptographic parameters.
5.6.3 Security requirements on client manufacturers
5.6.3.1 Development
During development of Light Encryption, client device manufacturer should limit to a minimum the
personnel having access to the secret cryptographic parameters distributed by TISA, and/or customer
and service specific cryptographic parameters. Development artifacts related to these parameters shall
be stored in a protective fashion, to prevent unauthorized access.
5.6.3.2 Firmware and firmware distribution
The secret cryptographic parameters distributed by TISA, and any further customer and service specific
cryptographic parameters should be stored in encrypted/obfuscated form in a device’s firmware, such
as to prevent security leaks from inspecting firmware or firmware updates. The chosen protection
scheme should make it difficult to find, use, or replace confidential cryptographic parameters. The
chosen protection scheme for storage in a device’s firmware may be proprietary.
6 Light encryption method of encryption and operation
6.1 Principles of operation for light encryption
The objective of Light Encryption for TPEG is to achieve a simple encryption method, while still
allowing effective compression of service frame payload data. To do so, the selected operating principle
is to encrypt the complete service frame payload data in one go (as opposed to encryption of individual
service component frames). This principle affords a single access point for decryption in the TPEG
client, which gets passed a complete TPEG service data frame to process. Efficient transmission can be
achieved, since the service frame payload data can be compressed first, before applying encryption.
Consequently, when a service provider desires mixing unencrypted and encrypted TPEG data, this
provider needs to set up different TPEG services with different TPEG Service IDs and mix these in the
TPEG service multiplex. Access rights management and encryption shall be handled at the TPEG service
multiplex level, where individual TPEG services are either encrypted or clear-to-air.
This scheme allows a TPEG service composition in which clear-to-air content in TPEG service multiplex is
accessible for TPEG clients, without these clients needing to know of any encryption and/or conditional
access system knowledge. Service providers can link content of such various services to each other, by
6 © ISO 2017 – All rights reserved

means of the TPEG concept of “originator” TPEG service ID ISO (TS21219-9). With the “originator” TPEG
service ID, a service provider can inform a TPEG client that content from one clear-to-air TPEG service
is from the same source as the content of an encrypted TPEG service.
Key requirements addressed in this conditional access mechanism are the following:
— The method shall support commonly used business models in TPEG over broadcast delivery;
— The method shall provide an appropriate level of security against unauthorized access and usage in
Traffic and Traveller Information (TTI) context;
— The method shall be license-free to operate;
— The method shall be easy to implement at the TPEG client side and TPEG server side and shall have
minimal overhead;
— The method shall be bearer-independent;
— The method shall allow granting and revoking of access to individual B2B customers.
6.2 Overview of the light encryption method
6.2.1 General
For Light Encryption, the used encryption algorithms are based on the Advanced Encryption Standard
(AES; see Federal Information Processing Standards Publication 197). Light Encryption distinguishes
two modes to support different business models. Technically, the two modes differ only in distribution
of the “parameterInConfidence” with which the service keys are composed.
Figure 1 — Mode 1 encryption method principle
Figure 1 shows the encryption scheme for Light Encryption mode 1. In this mode 1, the service frame
payload data is encrypted with a Control Word. This Control Word (common to all clients) may be
changing over time for security reasons. New Control Words are encrypted with a Service Key before
transmission to a client. The encrypted Control Words are distributed in the service with Entitlement
Messages. In mode 1, a single Entitlement Message is provided for all clients.
The Service Keys are composed of a pre-shared, secret, key table maintained and distributed by TISA
under strict confidentiality. The service key composition selects a substring of the TISA secret table,
and then applies bit manipulation techniques (two XOR operations interspersed with a shift operation).
For symmetry with mode 2, the TISA secret information contains the TISA key table and a generic
“TISAparameterInConfidence”. In mode 1, this parameter shall be used by all clients in the same way
(whereas in mode 2, this “parameterInConfidence” shall be customer specific).
Figure 2 — Mode 2 encryption method principle
Figure 2 shows the encryption scheme for Light Encryption mode 2 which operates in the same fashion
as mode 1. Only when composing the Service Key, instead of the TISAparameterInConfidence, a customer-
specific parameterInConfidence is used to specify the Service Key for a specific customer. This customer
specific “parameterInConfidence” (and allocated “customerID”) shall be pre-shared between a specific
TPEG Service Provider and a specific TPEG Client manufacturer as part of a contract agreement. Once
the Service Key is used to encrypt (at service side) or decrypt (at client side) the transmitted encrypted
Control Word, the rest of the process remains identical.
The encrypted Control Words are distributed in the service with Entitlement Messages. In mode
2, for every (B2B) customer a separate Entitlement Message is provided. The client shall check the
“customerID” attribute contained in the Entitlement Message to obtain its customer-specific entitlement
parameters.
TPEG clients under valid contract with a Service Provider shall be able to decode both Light Encryption
Mode 1 and Mode 2. This enables the Service Provider to switch temporarily to mode 1, when business
reasons would warrant so.
Clients shall ascertain at all times whether they have the correct (decrypted) Control Word for a specific
signalled Light Encryption Mode and Control Word Version Id. Only then they may proceed to decrypt
the encrypted payload data. If not, they shall discard encrypted payload data.
NOTE In Annex C, guidelines (informative) for use of this document are given.
6.2.2 TISA secret KeyTable and TISAparameterInConfidence
This document uses two secret pieces of information which are distributed by TISA under strict
confidentiality rules:
— TISA KeyTable: a several kilobyte, long byte, array containing random numbers;
— TISAparameterInConfidence: a 16 bytes, long byte, array containing random numbers for use in
light encryption mode 1.
For secrecy reasons, this document does not contain these parameters. They can be obtained from TISA
under FRAND conditions. An application shall be made using the request form on the TISA website
(www .tisa .org). After signing and returning the corresponding confidentiality agreement to TISA, this
TISA KeyTable and TISAparameterInConfidence shall be made available in digital form.
8 © ISO 2017 – All rights reserved

6.3 Encryption and decryption of service data frame payload data
6.3.1 General
The service data frame payload is encrypted using the AES standard (Federal Information Processing
Standards Publication 197). The Control Word is used as the cryptographic key in AES for service
payload data encryption. The 128-bit (16 bytes) long version of AES cipher is chosen (referred to as
AES128 in NIST Special Publication 800-38A). Since the length of the service data frame payload is
much longer than this standard 16 or (alternatively 32-byte AES) block cipher length, a block cipher
mode of operation is needed. A mode of operation specifies how to repeatedly apply a block cipher’s
single-block operation to securely transform amounts of data larger than a block.
6.3.2 Block cipher mode of operation
For Light Encryption of service frame payload data, the Counter Mode (CTR) mode of operation is
employed (NIST Special Publication 800-38A). Counter mode is the fastest mode of operation and
processed concurrently by both the Service Provider and the client device.
The CTR mode is applied only for service frame payload encryption. For both Light Encryption modes 1
and 2, the service frame payload data is encrypted with CTR-AES128 (NIST Special Publication 800-38A).
NIST has made available CTR-AES128 test vectors in NIST Special Publication 800-38A, Appendices
F5.1 and F5.2. These test vectors shall be used for validation of implementations of this document.
Payload encryption is performed on blocks of application data. In the CTR-AES128 mode of operation, a
block consists of 16 bytes of service frame payload data as contained in a TPEG Service Data Frame. The
CTR mode ensures that distinct ciphertexts blocks are produced even when the same plaintext block is
encrypted multiple times independently with the same Control Word.
To do so, for each block a new Initialisation Vector (IV) is needed. Information for this IV (a Nonce [A
NONCE is a Number used ONCE], the TPEG SID, and the LTE mode) is transmitted in front of the encrypted
Service Data Frame payload data as part of the Light Encryption Information (“LteInformation”)
component (see Clause 7). These transmitted parameters are complemented by a running counter to
construct the initialisation vector per block of data.
Figure 3 — CTR mode of operation for encryption and decryption of service data frame
payload data
Figure 3 shows the principle of the CTR mode of operation. For each block of data, the constructed
Initialisation Vector is encrypted using the Control Word. The encrypted Initialisation Vector is then
subject to an XOR operation with the plaintext to produce the ciphertext for encryption (top), or
alternatively, the encrypted Initialisation Vector then subject to an XOR operation with the ciphertext
to produce the plaintext for decryption (bottom).
The counter is incremented by one (as an IntUnLi value) for every successive block of service frame
payload data in the Initialisation Vector. The structure of this Initialisation Vector is detailed next.
10 © ISO 2017 – All rights reserved

6.3.3 Initialisation Vector
For Light Encryption mode 1 and mode 2, the binary representation of the 16 byte initialisation vector
IV of the CTR mode is specified as follows:
>:= : 16 byte Initialisation Vector IV for CTR mode.
10 *(nonceValue), : 10 byte value of the Nonce, signalled in the data
structure mode1Nonce or mode2Nonce for mode
1 or mode 2 respectively (see 5.5). The value of
this Nonce shall contain a unique numeric value
for every service frame encrypted with the same
Control Word.
(SID)
...