ETSI TS 102 484 V11.2.0 (2019-04)

Smart Cards; Secure channel between a UICC and an end-point terminal (Release 11)

RTS/SCP-T0312vb20

General Information

• Status: Published
• Publication Date: 01-Apr-2019
• Technical Committee: SET TEC - SET-TEC
• Current Stage: 12 - Completion
• Due Date: 15-Apr-2019
• Completion Date: 02-Apr-2019

Standards Content (Sample)

TECHNICAL SPECIFICATION
Smart Cards;
Secure channel between a UICC and an end-point terminal
(Release 11)
Release 11 2 ETSI TS 102 484 V11.2.0 (2019-04)

Reference
RTS/SCP-T0312vb20
Keywords
security, smart card
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
Release 11 3 ETSI TS 102 484 V11.2.0 (2019-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Overview . 9
5 Secure channel properties . 10
5.0 General . 10
5.1 Secure Channel Lifecycle . 10
5.1.0 General . 10
5.1.1 Secure channel support discovery . 11
5.1.2 Discovery of available endpoints . 11
5.1.3 Negotiate secure channel parameters . 11
5.1.3.0 General . 11
5.1.3.1 Security Associations . 11
5.1.3.2 Master SA . 11
5.1.3.3 Connection SA . 12
5.1.4 Key Agreement . 12
5.1.4.0 General . 12
5.1.4.1 Strong Pre-shared Keys - GBA . 13
5.1.4.2 Strong Pre-shared Keys - Proprietary Pre-agreed keys . 14
5.1.4.3 Weak Pre-shared Keys - Proprietary Pre-agreed keys. 14
5.1.4.4 Certificate exchange . 14
5.1.4.5 Expiration values and Counter Limits for Key Material . 14
5.1.5 Secure Channel Operation . 15
5.1.6 Secure Channel Suspension and Resumption . 15
5.1.7 Secure Channel Termination. 15
5.2 Use of multiple secure channels . 15
5.3 Security Policy Enforcement . 15
6 TLS - Application to Application lifecycle . 16
6.0 General . 16
6.1 Discovery of available endpoints . 16
6.2 Master SA setup . 16
6.2.0 General . 16
6.2.1 Setup using a Pre-shared Key . 16
6.2.2 Setup using Certificates . 16
6.3 Connection SA setup . 17
6.4 Secure Connection Initiation and Data Transmission. 17
6.5 Secure Connection Termination and Resumption . 18
6.6 Master Security Association Termination . 18
7 Secured APDU - Application to Application lifecycle . 18
7.0 General . 18
7.1 Discovery of available endpoints . 18
7.2 Master SA setup . 18
7.3 Connection SA setup . 19
7.4 Secure Connection Initiation and Data Transmission. 20
ETSI
Release 11 4 ETSI TS 102 484 V11.2.0 (2019-04)
7.5 SA Termination and Resumption . 21
8 Ipsec - USB class to USB class lifecycle . 21
8.0 General . 21
8.1 Discovery of available endpoints . 22
8.2 Master Security Association . 22
8.3 Secure Connections . 22
8.4 Secure Connection Initiation and Data Transmission. 22
8.5 Secure Connection Termination and Resumption . 23
8.6 Master Security Association Termination . 23
9 Platform to Platform APDU secure channel lifecycle . 23
9.1 Platform to Platform APDU secure channel . 23
9.2 Platform to Platform CAT APDU secure channel . 24
10 Encrypted data coding . 24
10.0 General . 24
10.1 Mapping Data from the Terminal to the UICC . 25
10.1.1 Structure of the data to be encrypted . 25
10.1.2 Definition of the encrypted blob TLV when sending data to the UICC . 26
10.1.3 Mapping of the encrypted blob TLV to C-APDUs . 26
10.2 Mapping response from the UICC to the Terminal . 27
10.2.1 Structure of the data to be encrypted . 27
10.2.2 Definition of the encrypted blob TLV when receiving data from the UICC . 28
10.2.3 Mapping of the encrypted blob TLV to C-APDUs . 28
11 Key Expansion Function Definition . 28
12 eCAT Secure Channel . 28
12.0 General . 28
12.1 Discovery of available endpoints . 29
12.2 Master SA setup . 29
12.3 Connection SA setup . 29
12.4 Secure Connection Initiation and Data Transmission. 30
12.5 SA Termination and Resumption . 31
Annex A (informative): Change history . 32
History . 33

ETSI
Release 11 5 ETSI TS 102 484 V11.2.0 (2019-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP).
The contents of the present document are subject to continuing work within TC SCP and may change following formal
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with
an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
0 early working draft;
1 presented to TC SCP for information;
2 presented to TC SCP for approval;
3 or greater indicates TC SCP approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
Release 11 6 ETSI TS 102 484 V11.2.0 (2019-04)
1 Scope
The present document specifies the technical implementation of the secure channel requirements specified in
ETSI TS 102 412 [8].
The present document includes the architecture, functional capabilities and characteristics of the Secure Channel
protocol and its associated interfaces transported over the UICC interface specified in ETSI TS 102 221 [1] and over the
UICC USB interface specified in ETSI TS 102 600 [15].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version
of that document in the same Release as the present document.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".
[2] IETF RFC 4346 (2006): "The Transport Layer Security (TLS) Protocol Version 1.1".
NOTE: The reference to IETF RFC 4346 is intentional, even though the RFC is obsolete.
[3] IETF RFC 4366 (2003): "Transport Layer Security (TLS) Extensions".
NOTE: The reference to IETF RFC 4366 is intentional, even though the RFC is obsolete.
[4] IETF RFC 4279 (2005): "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)".
[5] Void.
[6] Void.
[7] ETSI TS 133 110: "Universal Mobile Telecommunications System (UMTS); LTE; Key
establishment between a Universal Integrated Circuit Card (UICC) and a terminal (3GPP
TS 33.110)".
[8] ETSI TS 102 412: "Smart Cards; Smart Card Platform Requirements Stage 1".
[9] ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)".
[10] ETSI TS 124 008: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3 (3GPP TS 24.008)".
[11] IETF RFC 6234: "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)".
[12] IETF RFC 2104 (1997): "HMAC: Keyed-Hashing for Message Authentication".
[13] FIPS PUB 180-2: "Secure Hash Standard (SHS)".
ETSI
Release 11 7 ETSI TS 102 484 V11.2.0 (2019-04)
[14] ETSI TS 102 225 (V7.3.0): "Smart Cards; Secured packet structure for UICC based applications
(Release 7)".
[15] ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface".
[16] ISO/IEC 9797-1: "Information technology -- Security techniques -- Message Authentication Codes
(MACs) -- Part 1: Mechanisms using a block cipher".
[17] Void.
[18] IETF RFC 3268 (2002): "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
Security (TLS)".
NOTE: The reference to IETF RFC 3268 is intentional, even though the RFC is obsolete.
[19] IETF RFC 5996: "Internet Key Exchange Protocol Version 2 (IKEv2)".
[20] IETF RFC 4301 (2005): "Security Architecture for the Internet Protocol".
[21] IETF RFC 4307 (2005): "Cryptographic Algorithms for Use in the Internet Key Exchange
Version 2 (IKEv2)".
NOTE: The reference to IETF RFC 4307 is intentional, even though the RFC is obsolete.
[22] Void.
[23] IETF RFC 4303 (2005): "IP Encapsulating Security Payload (ESP)".
[24] ETSI TS 102 483: "Smart cards; UICC-Terminal interface; Internet Protocol connectivity between
UICC and terminal".
[25] IETF RFC 4835 (2007): "Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)".
NOTE: The reference to RFC 4835 is intentional, even though the RFC is obsolete.
[26] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[27] IETF RFC 6960: "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol –
OCSP".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version
of that document in the same Release as the present document.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
Not applicable.
ETSI
Release 11 8 ETSI TS 102 484 V11.2.0 (2019-04)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
encrypted blob: Binary Large Object resulting from encrypting plain data
endpoint: application or platform handler on either the terminal or UICC that is capable of being an end of a secure
channel
nonce: number used once
NOTE: Random value that is used only once in a cryptographic message to protect against replay attacks.
security association: set of information required for the channel endpoints to start communicating securely
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3DES Triple DES
AES Advanced Encryption Standard
AH Authentication Header
APDU Application Protocol Data Unit
ASCII American Standard Code for Information Interchange
ATR Answer To Reset
BCD Binary Coded Decimal
BER Basic Encoding Rules
BIP Bearer Independent Protocol
CAT Card Application Toolkit
CBC Cipher Block Chaining
CL Counter Limit
CMAC Cipher-based Message Authentication Code
CRL Certificate Revocation List
CSA Connection Security Association
CSAMAC Connection Security Association Message Authentication Code
DES Data Encryption Standard
ESP Encapsulating Security Payload
FFS For Further Study
FIPS Federal Information Processing Standard
GBA Generic Bootstrap Architecture
HMAC Hash Message Authentication Code
ICCID Integrated Circuit Card Identification
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IKE_SA Internet Key Exchange - Security Association
IMEI International Mobile Equipment Identity
IP Internet Protocol
IPsec Internet Protocol security
KIC Key and algorithm Identifier for ciphering
KID Key and algorithm IDentifier for RC/CC/DS
MAC Message Authentication Code
MF Master File
MODP MODular exPonential
ETSI
Release 11 9 ETSI TS 102 484 V11.2.0 (2019-04)
MS Master Secret
MSA Master Security Association
OCSP Online Certificate Status Protocol
PPS Protocol and Parameter Selection
PSK Pre-Shared Key
SA Security Association
SHA Secure Hash Algorithm
SSCMAC Start Secure Channel Message Authentication Code
TCP Transmission Control Protocol
TLS Transport Layer Security
TLV Tag Length Value
TSCA Terminal-Supported Ciphering Algorithms
TSIM Terminal-Supported Integrity Mechanisms
UCA UICC Ciphering Algorithm
UIM UICC Integrity Mechanism
USB Universal Serial Bus
UTF Universal Character Set Transformation Format
4 Overview
The present document defines several types of secured data transport protocols that can be used to deliver the secure
channel usecases and requirements specified in ETSI TS 102 412 [8] and the associated mechanisms that can be used to
setup these protocols.
The secured data transport protocols are:
• TLS - Application to Application: This protocol secures IP communication between an application in the
UICC and an application in the terminal or in a device connected to the terminal. Using this protocol, IP
communication by other applications to the UICC may be unsecured. This protocol may be used over the
APDU interface specified in ETSI TS 102 221 [1] using the BIP - UICC Server mode commands specified in
ETSI TS 102 223 [9] or over the Ethernet emulation class of the USB interface specified in ETSI
TS 102 600 [15]. Support for this type of secure channel shall be indicated on per application basis.
• Secured APDU - Application to Application: This protocol secures the APDU communication between an
application in the UICC and an application in the terminal or in a device connected to the terminal. Using this
protocol, APDU communication by other applications to the UICC may be unsecured. This protocol may be
used over the APDU interface specified in ETSI TS 102 221 [1] or the APDU class of the USB interface
specified in ETSI TS 102 600 [15]. Support for this type of secure channel shall be indicated on per
application basis.
• IPsec - USB class to USB class: This protocol secures all IP communication between the UICC and the
terminal when ETSI TS 102 483 [24] is supported over the Ethernet emulation class of the USB interface
specified in ETSI TS 102 600 [15].
• Secured APDU - Platform to Platform: This protocol secures all APDU communication between the UICC
and the terminal. This protocol may be used over the APDU interface specified in ETSI TS 102 221 [1] or the
APDU class of the USB interface specified in ETSI TS 102 600 [15]. Support for this type of secure channel
shall be indicated in the ATR.
• Secured APDU - Platform to Platform CAT: This protocol secures all CAT APDU communication between
the UICC and the terminal and is reusing the Secured APDU - Platform to Platform mechanism but restricted
to CAT related APDUs. This protocol may be used over the APDU interface specified in ETSI TS 102 221 [1]
or the APDU class of the USB interface specified in ETSI TS 102 600 [15]. Support for this type of secure
channel shall be indicated in the MF file control parameters. A terminal and a UICC claiming conformance to
the present document may support this secured data transport protocol.
• eCAT Secure Channel: This protocol secures the eCAT communication between the UICC and an eCAT
client in the terminal as specified in ETSI TS 102 223 [9]. Support for this type of secure channel shall be
indicated on per application basis.
ETSI
Release 11 10 ETSI TS 102 484 V11.2.0 (2019-04)
Terminals/applications in the terminal/eCAT clients and UICCs/UICC applications claiming conformance to the present
document shall explicitly state which of these secured data transport protocols they support.
Secured platform to platform channels between the Terminal and a device connected to the terminal are out of scope of
the present document.
To manage the security aspects of these secure channel protocols, Security Contexts are setup which contain security
settings and key material. The present document defines four mechanisms to agree key material using:
• Strong Pre-shared Keys - GBA: Key material is agreed using the GBA procedures specified in ETSI
TS 133 110 [7]. The UICC and the terminal shall support this mechanism if GBA is supported.
• Strong Pre-shared Keys - Proprietary Pre-agreed keys: These are keys with an entropy of at least 128 bits.
The UICC and the terminal may support this mechanism. An eCAT client and the related application on the
UICC using the eCAT secure channel shall support this mechanism.
• Weak Pre-shared Keys - Proprietary Pre-agreed keys: These are keys with an entropy of less than 128 bits
(such as password based keys). The UICC and the terminal may support this mechanism.
• Certificate exchange: A UICC or a terminal that does not support the GBA mechanism shall support this
mechanism. A UICC or a terminal that does support the GBA mechanism may support this mechanism.
5 Secure channel properties
5.0 General
This clause defines common properties for secure channels and details the secure channel lifecycle of each secure
channel type defined in the present document.
A secure channel, within the present document, is characterized as having:
• an endpoint on a terminal or connected device;
• an endpoint on a UICC;
• a means of secure bidirectional communication between these endpoints;
• security policy management at each endpoint that prevents insecure communication between these two points.
5.1 Secure Channel Lifecycle
5.1.0 General
The lifecycle of each secure channel will include the following steps:
• Discovery of support for secure channels by the terminal and the UICC as detailed in the present document.
• Discover endpoints that can communicate securely on the UICC.
• Negotiate secure channel parameters.
• Create a secure channel.
• Communicate over a secure channel.
• Suspend and resume a secure channel.
• Terminate a secure channel.
ETSI
Release 11 11 ETSI TS 102 484 V11.2.0 (2019-04)
5.1.1 Secure channel support discovery
Support for the mandatory procedures defined in the present document and support for the Secured APDU - Platform to
Platform secure channel shall be indicated in the ATR as defined in ETSI TS 102 221 [1].
Support for the Secured APDU - Platform to Platform CAT secure channel shall be indicated in the MF file control
parameters as defined in ETSI TS 102 221 [1].
A terminal shall only indicate that it supports the procedures in the present document if it is able to execute applications
as a trusted platform. Definition of a trusted platform is out of scope of the present document.
5.1.2 Discovery of available endpoints
Each secure channel type defines the mechanisms by which the terminal or the UICC can dynamically discover the
available endpoints on the other entity.
NOTE: By their nature, endpoints can dynamically change their availability depending on the activation state of
their associated applications.
5.1.3 Negotiate secure channel parameters
5.1.3.0 General
For a secure channel to be setup, both ends of the secure channel shall agree on the parameters to be used for this
channel. The present document defines these parameters as a "Security Association".
5.1.3.1 Security Associations
A Security Association has the following parameters:
• Identified and authenticated endpoints for both the terminal and the UICC.
• Cryptographic keys.
• Protection algorithms.
• Any additional parameters to be used for securing data transmissions.
• Mechanisms and parameters for identifying secure connections and managing the secure channel.
There are two types of Security Association defined in the present document:
• Master SA.
• Connection SA.
Each secure channel shall have one Master SA and at least one Connection SA.
The terminal and the UICC shall be able to securely store all of the parameters for a minimum of 4 Master SAs and
4 Connection SAs. These Security Association parameters shall not be visible or editable by any process outside of the
present document.
5.1.3.2 Master SA
The main security association set up between the channel endpoints is the Master SA. This SA records the following
information:
• Channel endpoints.
• Master SA identifier.
• Master SA cryptographic keys (defined as the Master Secret (MS)).
ETSI
Release 11 12 ETSI TS 102 484 V11.2.0 (2019-04)
• The algorithms used to establish secure connections.
• Expiration information for the Master SA.
The definition of the Master SA parameters is specific to the type of channel being opened (e.g. Secured APDU -
Application to Application).
A Master SA is specific to the endpoints being used and the type of channel being used. If two endpoints need to
communicate over a different secure channel type or a secure channel is required to a different endpoint (even if it is on
the same device), then a new Master SA shall be used.
The UICC may indicate that there is an existing agreed pre-shared key that can be used to setup this Master_SA.
Master SA's shall exist until they expire or until they are terminated.
A Master SA is used to setup one or more Connection SAs. This enables the setup of a new Connection SA for a secure
channel to be negotiated before the current Connection SA expires.
A Master SA shall not be used to directly setup a secure channel.
5.1.3.3 Connection SA
Each Connection SA contains the operational security parameters for a specific secure channel, these parameters are
specific to each secure channel type. Connection SAs derive their parameters from a Master SA and have their own
lifetime limit.
Connection SAs shall be active until one of the following occurs:
• UICC Power is removed.
• The UICC is reset.
• The Connection SA is terminated.
• The Master SA that the Connection SA is derived from is terminated.
• The terminal determines that the lifetime of the SA has expired.
• The UICC determines that the Connection SA usage counter has reached its limit.
The endpoint may indicate that it supports multiple concurrent connection SAs. The terminal shall use this indication
when attempting to setup more than one active Connection SA for that Master SA. For security reasons and for resource
consumption optimization, the amount of time during which concurrent Connection SAs exist should be minimized.
5.1.4 Key Agreement
5.1.4.0 General
For a Master SA to be setup, a mechanism is needed to share key material between the two endpoints. The present
document defines four mechanisms for key agreement that can be used irrespectively as to which secure channel type is
used:
• Strong Pre-shared Keys - GBA.
• Strong Pre-shared Keys - Proprietary Pre-agreed keys.
• Weak Pre-shared Keys - Proprietary Pre-agreed keys.
• Certificate exchange.
All pre-shared key agreement mechanisms shall produce values for the following parameters:
• Ks_local: This is the secret key used to secure the data transmission between the two endpoints.
ETSI
Release 11 13 ETSI TS 102 484 V11.2.0 (2019-04)
• UICC_ID: This is a unique identifier for the UICC. This may be the ICCID for the UICC as defined in ETSI
TS 102 221 [1].
• UICC_appli_ID: This is a unique identifier for the UICC application that hosts the UICC endpoint. If
Ks_local is intended to be used for 'Secured APDU - Platform to Platform' or 'IPsec - USB class to USB class'
secure channel types then UICC_appli_ID shall be set to the ASCII encoded string "platform".
• Terminal_ID: This is a unique identifier for the terminal or device connected to the terminal where the
terminal endpoint is. This may be the IMEI of the terminal as defined in ETSI TS 124 008 [10].
• Terminal_appli_ID: This is a unique identifier for the application that hosts the terminal endpoint. If
Ks_local is intended to be used for 'Secured APDU - Platform to Platform' or 'IPsec - USB class to USB class'
secure channel types then Terminal_appli_ID shall be set to the ASCII encoded string "platform".
• Weak Key: This indicates the strength of Ks_local. Weak Key shall be set to 1 if the pre-shared key is based
on a low entropy key (i.e. a key of less than 128 bits of entropy such as a user entered PIN or password),
otherwise it shall be set to 0.
• Key Lifetime: This is the date and time that the key is valid until.
• Key Counter Limit (CL): This is the maximum number of times that the key and any derived keys can be
used. This is 16 bytes defined as follows:
Bytes 1 to 2: Reserved for future use.
Bytes 3 to 4: Number of Master SAs that can be created from this pre-shared key.
Bytes 5 to 8: Number of Connection SAs that can be derived from each Master SA using this pre-
shared key.
Bytes 9 to 16: Number of individual secure transactions that can be made before the Connection SA,
derived from a Master SA using this pre-shared key, shall expire.
The terminal and UICC shall create a value, Ks_Local_Ref, to reference Ks_local where:
Ks_Local_Ref = Terminal_ID || Terminal_appli_ID || UICC_ID || UICC_appli_ID.
The UICC shall reject the setup of a Master SA if the values Terminal_ID and Terminal_appli_ID do not match the
intended terminal (and terminal application) that the UICC wishes to securely communicate with.
The terminal shall terminate a Master SA if the values UICC_ID and UICC_appli_ID do not match the intended UICC
(and UICC application) that the terminal wishes to securely communicate with.
5.1.4.1 Strong Pre-shared Keys - GBA
A method for establishing a pre-shared key using GBA is defined in ETSI TS 133 110 [7].
This method agrees the following values between the UICC and the terminal or connected device:
• A 256 bit shared secret key Ks_local.
• A 10 byte UICC identifier UICC_ID encoded as for ICCID as defined in ETSI TS 102 221 [1].
• A 16 byte UICC application identifier UICC_appli_ID (up to 16 bytes).
• A 10 byte terminal identifier Terminal_ID encoded using BCD coding as defined in ETSI TS 124 008 [10].
• A terminal application Identifier Terminal_appli_ID (up to 32 bytes).
• A variable length Ks_local Key Lifetime (for use in the terminal).
• A 16 byte Ks_local Counter (for use in the UICC).
For GBA agreed keys, WeakKey shall be set to 0.
ETSI
Release 11 14 ETSI TS 102 484 V11.2.0 (2019-04)
Only one GBA key shall be allowed per individual Ks_Local_Ref. If GBA is run again for the same Ks_Local_Ref then
the GBA key for that Ks_Local_Ref shall be overwritten by the new key generated and any Master SA or Connection
SAs that were setup using the old key shall be terminated.
5.1.4.2 Strong Pre-shared Keys - Proprietary Pre-agreed keys
The terminal and UICC may share strong pre-shared keys (with an entropy of 128 bits or greater) using a proprietary
mechanism known to both devices.
The proprietary mechanism used shall agree values for the parameters defined in clause 5.1.4.
5.1.4.3 Weak Pre-shared Keys - Proprietary Pre-agreed keys
The terminal and UICC may share weak pre-shared keys (with an entropy of less than 128 bits) using a proprietary
mechanism known to both devices such as password exchange.
The proprietary mechanism used shall agree values for the parameters defined in clause 5.1.4.
Both the UICC and the terminal shall be able to restrict the use of secure channels that are based on a weak pre-shared
key.
NOTE: Use of a weak pre-shared key to create a Master SA is not recommended.
5.1.4.4 Certificate exchange
Appropriate key agreement protocols for certificate exchange are defined or referenced as part of the Master SA
establishment for each channel type.
5.1.4.5 Expiration values and Counter Limits for Key Material
To maintain the security of keys used by secure channels, all used keys shall have a defined lifetime. The lifetime of a
key and a counter limit are set as part of the key agreement and is specific to the strength of the key, how many times it
can be used and what it is being used for.
The UICC shall count the following for each pre-shared key:
• The number of Master SAs derived from that key.
• The number of Connection SAs derived from a Master SA.
• The number of transactions handled within a Connection SA.
The UICC shall use the agreed Counter Limit (CL) for each key (as the UICC is not time aware and therefore cannot
expire keys using a time-based method) to determine when one of the following conditions has been reached:
• The maximum number of Master SAs have been derived from that pre-shared key. Once this limit is reached
the pre-shared key shall be deleted and all Master SAs and Connection SAs based on it shall be terminated by
the UICC.
• The maximum number of Connection SAs have been derived from a Master SA. Once this limit is reached the
Master SA and Connection SAs based on it shall be terminated by the UICC.
• The maximum number of secure data transactions have occurred for a Connection SA. Once this limit is
reached the Connection SA shall be terminated by the UICC.
The terminal or connected device shall have a key lifetime for each key and may have a counter limit for each key.
Once either the key lifetime limit or the counter limit is reached for that key, the terminal or connected device shall
delete that key and refuse all transactions based on that key. The terminal or connected device shall terminate all
security associations that rely on the expired key (including any derived Security Associations).
NOTE: The terminal should not allow the user to manipulate the timing mechanism used to calculate the lifetime
of these keys.
ETSI
Release 11 15 ETSI TS 102 484 V11.2.0 (2019-04)
5.1.5 Secure Channel Operation
Once a Connection SA has been established (from a Master SA), data may be securely transmitted using the keys and
cryptographic algorithms agreed in the Connection SA.
This is specific to each channel type.
5.1.6 Secure Channel Suspension and Resumption
A secure channel shall be considered 'suspended' if all of the Connection SAs for that secure channel have been
terminated.
A suspended secure channel shall be resumed when a Connection SA is created using the Master SA for that secure
channel.
It is up to the applications using the secure channel to determine the effect that suspension and resumption will have on
their communication.
NOTE: It is anticipated that communication over a secure channel are not to be affected by suspension and
resumption of a secure channel.
5.1.7 Secure Channel Termination
A secure channel is terminated when the Master SA for that secure channel is terminated. This could either be as a
result of a MANAGE SECURE CHANNEL - Terminate secure channel SA command or due to the expirati
...