ETSI TS 102 412 V8.0.0 (2008-01)

Smart Cards; Smart Card Platform Requirements Stage 1 (Release 8)

RTS/SCP-R00002R8r1

General Information

• Status: Published
• Publication Date: 14-Jan-2008
• Technical Committee: SET REQ - SET-REQ
• Current Stage: 12 - Completion
• Due Date: 06-Feb-2008
• Completion Date: 15-Jan-2008

Standards Content (Sample)

Technical Specification
Smart Cards;
Smart Card Platform Requirements Stage 1
(Release 8)
Release 8 2 ETSI TS 102 412 V8.0.0 (2008-01)

Reference
RTS/SCP-R00002R8r1
Keywords
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
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
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
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
Release 8 3 ETSI TS 102 412 V8.0.0 (2008-01)
Contents
Intellectual Property Rights.6
Foreword.6
Introduction .6
1 Scope.7
2 References.7
2.1 Normative references.7
2.2 Informative references.8
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.9
4 Requirements.10
4.1 Run time environment timing constraints .11
4.1.1 Abstract (informative).11
4.1.2 Background (informative).11
4.1.2.1 Use case - Network authentication.11
4.1.3 Requirements.11
4.1.4 Interaction with existing features (informative).11
4.2 Launch Application feature .11
4.2.1 Abstract (informative).11
4.2.2 Background (informative).11
4.2.3 Requirements.12
4.2.4 Interaction with existing features (informative).13
4.3 Mapped file support on the UICC .13
4.3.1 Abstract (informative).13
4.3.2 Background (informative).13
4.3.3 Requirements.13
4.3.4 Interaction with existing features (informative).13
4.4 Extension of logical channels.14
4.4.1 Abstract (informative).14
4.4.2 Background (informative).14
4.4.2.1 Typical problem situation .14
4.4.2.2 Possible problem solution.14
4.4.2.3 Use cases.14
4.4.2.3.1 Use case - JSR 177 applications .14
4.4.2.3.2 Use case - PC connection .14
4.4.3 Requirements.14
4.4.3.1 General requirements.14
4.4.3.2 Backward compatibility requirements.14
4.4.4 Interaction with existing features (informative).15
4.5 Secure channel to secure local terminal interfaces .15
4.5.1 Abstract (informative).15
4.5.2 Background (informative).15
4.5.2.1 Use case - User interface.16
4.5.2.2 Use case - UICC as a control point for device management .16
4.5.2.3 Use case - DRM and distributed applications .18
4.5.3 Requirements.19
4.5.3.1 End point requirements .19
4.5.3.2 Integrity requirements.19
4.5.3.3 Confidentiality requirements.20
4.5.3.4 Authentication requirements.20
4.5.3.5 Audit/Compliance requirements.20
4.5.3.6 Policy requirements.20
4.5.3.7 Transport Protocol requirements.20
ETSI
Release 8 4 ETSI TS 102 412 V8.0.0 (2008-01)
4.5.4 Interaction with existing features (informative).20
4.5.4.1 Logical Channels.20
4.6 Authenticate command longer than 255 bytes.20
4.6.1 Abstract (informative).20
4.6.2 Background (informative).21
4.6.2.1 Use case - EAP packet exchange .21
4.6.3 Requirements.21
4.6.3.1 General requirements.21
4.6.3.2 Backward compatibility requirements.21
4.6.4 Interaction with existing features (informative).21
4.7 CAT mechanisms to indicate the bearer connection status .21
4.7.1 Abstract (informative).21
4.7.2 Background (informative).21
4.7.2.1 Use case - Availability of network bearers .21
4.7.2.2 Use case - Network connection temporarily lost.22
4.7.2.3 Use case - Availability of local bearers.22
4.7.3 Requirements.22
4.7.3.1 Requirement 1 - Network bearer connection status .22
4.7.3.2 Requirement 2 - Local bearer connection status .22
4.7.4 Interaction with existing features (informative).22
4.8 New UICC-Terminal interface .22
4.8.1 Abstract (informative).22
4.8.2 Background (informative).23
4.8.2.1 Use case - multimedia file management.23
4.8.2.2 Use case - MMI on UICC .23
4.8.2.3 Use case - real-time multimedia data encryption/decryption .23
4.8.2.4 Use case - storage of terminal applications on the UICC.23
4.8.2.5 Use case - direct and indirect UICC connection to a PC.23
4.8.2.6 Use case - web server on Smart Card.24
4.8.2.7 Use case - antivirus on UICC.24
4.8.2.8 Use case - big phonebook management from the UICC .24
4.8.2.9 Use case - reduce personalization time .24
4.8.2.10 Use case - generic TCP/IP connectivity.24
4.8.3 Requirements.25
4.8.3.1 General requirements.25
4.8.3.2 Backward compatibility requirements.25
4.8.4 Interaction with existing features (informative).26
4.9 UICC based application acting as a server .26
4.9.1 Abstract (informative).26
4.9.2 Background (informative).26
4.9.3 Requirements.26
4.9.4 Interaction with existing features (informative).26
4.10 API for applications registered to a Smart Card Web Server .26
4.10.1 Abstract (informative).26
4.10.2 Background (informative).26
4.10.2.1 Registration of an application to the SCWS.27
4.10.2.2 Data exchange between SCWS and application.27
4.10.3 Requirements.27
4.10.4 Interaction with existing features (informative).27
4.11 Specific UICC environmental conditions.27
4.11.1 Abstract (informative).27
4.11.2 Background (informative).27
4.11.2.1 Use case - Automotive service .28
4.11.2.2 Use case - Remote monitoring camera.28
4.11.2.3 Use case - Remote stock monitoring for vending machines .28
4.11.2.4 Use case - Online electronic advertising board .28
4.11.3 Considerations (informative).28
4.11.4 Requirements.28
4.11.4.1 Requirement 1: Temperature range.28
4.11.4.2 Requirement 2: Humidity.28
4.11.5 Interaction with existing features (informative).29
4.12 Introduction of high density memory technology in UICC.29
ETSI
Release 8 5 ETSI TS 102 412 V8.0.0 (2008-01)
4.12.1 Abstract (informative).29
4.12.2 Background (informative).29
4.12.2.1 Use case - Enhanced UICC features.29
4.12.3 Requirements.29
4.12.4 Interaction with existing features (informative).29
4.13 Power supply indication mechanism .30
4.13.1 Abstract (informative).30
4.13.2 Background (informative).30
4.13.2.1 Use case - generic situation.30
4.13.2.2 Use case - USIM application with toolkit applications .30
4.13.3 Requirements.31
4.13.3.1 General Requirements.31
4.13.3.2 Backward compatibility requirements.31
4.13.4 Interaction with existing features (informative).31
4.14 Internet Connectivity up to UICC applications .31
4.14.1 Abstract (informative).31
4.14.2 Use Cases (informative).31
4.14.2.1 Use Case - Card OTA management .32
4.14.2.2 Use Case - User local access from the terminal to a card server.32
4.14.2.3 Use Case - Remote access to an identity server in the card .32
4.14.2.4 Use Case - User access from a locally connected device to a card service .33
4.14.3 Requirements.33
4.14.4 Interaction with existing features (informative).33
4.15 Contactless UICC services .33
4.15.1 Abstract (informative).33
4.15.2 Background (informative).33
4.15.2.1 Use case - Access.33
4.15.2.1.1 System aspects of use case .33
4.15.2.1.2 UICC role in use case .34
4.15.2.2 Use case - tickets.35
4.15.2.2.1 System aspects of throughput ticketing scenario.35
4.15.2.2.2 System aspects of high priced ticketing scenario .35
4.15.2.2.3 UICC role in use case .36
4.15.2.3 Use case - digital rights .37
4.15.2.3.1 System aspects of contactless digital rights.37
4.15.2.3.2 UICC role in use case .37
4.15.2.4 Use case - payment application.38
4.15.2.5 Use case - loyalty application.38
4.15.2.6 Use case - health care application .38
4.15.3 Requirements.39
4.15.3.1 Physical interface requirements .39
4.15.3.2 Multi-protocol concurrent operation requirements .39
4.15.3.3 Contactless communication modes requirements .39
4.15.3.4 Compatibility with existing contactless systems requirements .39
4.15.3.5 Parameters to be transported by the CLFIP requirements.39
4.15.3.6 Application integration requirements.40
4.15.3.7 Terminal and user interaction requirements.40
4.15.3.8 Interoperability requirements.40
4.15.4 Interaction with existing features (informative).40
4.16 Administration of the Smart Card Web Server.40
4.16.1 Abstract (informative).40
4.16.2 Background (informative).40
4.16.3 Requirements.40
4.16.4 Interaction with existing features (informative).41
Annex A (informative): Requirement numbering scheme.42
Annex B (informative): Change history .43
History .44

ETSI
Release 8 6 ETSI TS 102 412 V8.0.0 (2008-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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 (http://webapp.etsi.org/IPR/home.asp).
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.
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.
Introduction
The present document specifies the requirements for Release 7onwards of the TC SCP.
ETSI
Release 8 7 ETSI TS 102 412 V8.0.0 (2008-01)
1 Scope
The present document specifies the additional requirements for Release 7 onwards of the TC SCP with respect to earlier
releases.
The present document covers all the Stage 1 requirements which are not covered by other TC SCP stage 1 documents.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics
(Release 7)".
[2] ETSI TS 102 223: "Smart cards; Card Application Toolkit (CAT) (Release 6)".
[3] ETSI TS 122 038: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); USIM Application Toolkit (USAT/SAT); Service
description; Stage 1 (3GPP TS 22.038 Release 7)".
[4] ETSI TS 151 011: "Digital cellular telecommunications system (Phase 2+); Specification of the
Subscriber Identity Module - Mobile Equipment (SIM-ME) interface (3GPP TS 51.011)".
[5] ETSI TS 131 102: "Universal Mobile Telecommunications System (UMTS); Characteristics of the
USIM application (3GPP TS 31.102 Release 6)".
[6] ISO/IEC 7816-4: "Identification cards - Integrated circuit cards - Part 4: Organization, security and
commands for interchange".
ETSI
Release 8 8 ETSI TS 102 412 V8.0.0 (2008-01)
[7] Trusted Computing Group (2003): "TPM Main - Part 1 Design Principles - Specification
version 1.2".
NOTE: Available at
https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part1_Design_Principles.pdf.
[8] ISO/IEC 14443: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards".
[9] ISO/IEC 18092:"Information technology - Telecommunications and information exchange
between systems - Near Field Communication - Interface and Protocol (NFCIP-1)".
[10] ISO/IEC 15693: "Identification cards - Contactless integrated circuit(s) cards - Vicinity cards".
2.2 Informative references
None.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
CLF: ContactLess Front-end, circuitry in the terminal which:
• Handles the analog part of the contactless communication.
• May handle some layers of the contactless protocol.
• May exchange data with the terminal and the UICC.
CLFI (CLF Interface): physical interface between the UICC and the CLF
CLFIP (CLFI Protocol): communication protocol between the UICC and the CLF carried over the CLFI
HSP: high speed protocol running on top of the NUT interface
ME/TE owner: entity having the right to configure or administrate a CAD and/or remote terminal
terminal: entity with which the Smart Card can establish a secure channel
EXAMPLE 1: Card Acceptance Device such as a mobile handset i.e. in the case of a wired Smart Card to
terminal (such as PDA or handset) communication.
EXAMPLE 2: A Remote Terminal is a terminal communicating to a CAD, which can access the UICC resources,
for example a PC connect over a local link to handset.
NOTE: In the present document a distinction will be made between a CAD and a Remote Terminal only where
applicable, in case this distinction is not relevant the generic term terminal will be used.
ETSI
Release 8 9 ETSI TS 102 412 V8.0.0 (2008-01)
terminal end point: point for terminating the secure channel from the UICC point of view, which could be a Mobile
Terminal or a Remote Terminal
EXAMPLE: A remote terminal can be a Set-top box, a PC, or even a Bluetooth earpiece connected to a Mobile
Terminal.
User Equipment
Card Remote
Acceptance Terminal
Device
UICC, with
applications
Figure 1: Possible secure channels with a UICC
trusted device: device which is not infected by malevolent code, whether because it is compliant to the requirements
defined in TCG [7] or because the user/owner/administrator guarantees device integrity by giving verifiable evidence
NOTE: A more exact definition is out of scope of SCP.
UICC powering modes:
• Battery powered:
- Mode where the UICC and the CLF are powered from the battery of the terminal.
• Not Battery powered:
- Mode where the UICC and the CLF are not powered from the battery of the terminal.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADF Application Dedicated File
API Application Program Interface
CAD Card Acceptance Device
CAT Card Application Toolkit
CAT-TP Card Application Toolkit - Transport Protocol
CEK Content Encryption Key
CPU Central Processing Unit
DF Dedicated File
DM Device Management
DRM Digital Rights Management
DRM_UA Digital Rights Management User Agent
EAP Extensible Authentication Protocol
EF Elementary File
GPRS General Packet Radio Service
HTTP HyperText Transfer Protocol
HTTPS Secure HyperText Transfer Protocol
IMS IP Multimedia Services
IP Internet Protocol
ISIM IMS SIM
JSR Java Specification Request
ME Mobile Equipment
ETSI
Release 8 10 ETSI TS 102 412 V8.0.0 (2008-01)
MNO Mobile Network Operator
MO (Device) Management Object
MT Mobile Termination
NUT New UICC-Terminal
OMA Open Mobile Alliance
OTA Over The Air
PDA Personal Digital Assistance
PIN Personal Identification Number
PKI Public Key Infrastructure
POP Post Office Protocol
POS Point Of Sale
RFID Radio Frequency Identification
RO Rights Object
SC Smart Card
SCWS Smart Card Web Server
SMTP Simple Mail Transfer Protocol
TCG Trusted Computing Group
TLS Transport Layer Security
TMP Trusted Media Player
UA (Digital Rights Management) User Agent
UE User Equipment
UMTS Universal Mobile Telecommunications System
URL Uniform Resource Locator
USIM Universal Subscriber Identity Module
USSM UICC Security Service Module
WIM Wireless Identity Module
4 Requirements
The present document specifies:
• run time environment timing constraints;
• launch application command;
• mapped file support on the UICC;
• extension of logical channels;
• secure channel to secure local terminal interfaces;
• authenticate command longer than 255 bytes;
• CAT mechanisms to indicate the bearer connection status;
• New UICC-Terminal (NUT) interface;
• Smart Card Web Server running in UICC;
• API for applications registered to a Smart Card Web Server;
• specific UICC environmental conditions;
• introduction of high density memory technology in UICC;
• power supply indication mechanism;
• Internet Connectivity up to UICC applications;
• Contactless UICC Services.
• Administration of the Smart Card Web Server
ETSI
Release 8 11 ETSI TS 102 412 V8.0.0 (2008-01)
4.1 Run time environment timing constraints
4.1.1 Abstract (informative)
SCP specifications up to Release 6 do not put any restrictions to the run time behaviour of Smart Card applications on
the CAT layer and on the application layer. However, an example for a situation which requires a defined runtime
behaviour of the UICC is given in a note in Release 6 of TS 102 223 [2]: The maximum work time of applications
before sending a MORE TIME proactive command to the terminal should not exceed a certain amount of time. This
remark is made in the context of the network authentication command and it is not normative. To avoid future problems
due to this undefined behaviour, the requirements in this clause aim at providing the infrastructure needed to achieve
standardized behaviour in situations like those described above from Release 7 onwards.
4.1.2 Background (informative)
4.1.2.1 Use case - Network authentication
An application may not block a UICC with a USIM application longer than a well defined period of time in order to be
able to process network authentication commands within a time limit which is a network parameter (TS 102 223 [2]).
4.1.3 Requirements
Identifier Requirement
REQ-7-01-01-01 The UICC shall provide a mechanism to assign a maximum work time to an application. The time
value might be network specific.
REQ-7-01-01-02 The UICC shall not be blocked by an application for an amount of time exceeding the configured
maximum work time.
REQ-7-01-01-03 In addition, the application itself shall be able to assign its own maximum work time value.
REQ-7-01-01-04 The application shall be suspended by the run time environment after the work time has expired and
control shall be given back to run time environment.
REQ-7-01-01-05 The run time environment shall return control to the application if no other task with higher priority
(e.g. network authentication) is pending.
REQ-7-01-01-06 The task switch procedure shall be transparent to the application.
REQ-7-01-01-07 Any security related to the tasks shall not be weakened by the task switch.

4.1.4 Interaction with existing features (informative)
(none).
4.2 Launch Application feature
4.2.1 Abstract (informative)
This feature enables the UICC to discover, launch and communicate with an application on a terminal using proactive
commands.
4.2.2 Background (informative)
The present document presents a stage 1 requirement and high-level description for the Launch Application feature.
The requirements are based on an existing requirement in the 3GPP stage 1 specification for toolkit feature
TS 122 038 [3].
As the applications to be launched are mainly independent of the air interface, it is appropriate to standardize this
feature in TC-SCP rather in 3GPP. This will also make this feature available to other telecom standards.
ETSI
Release 8 12 ETSI TS 102 412 V8.0.0 (2008-01)
Example of terminal applications for such a feature:
• E-mail:
CAT can launch an e-mail client on the terminal, providing parameters such as POP server, SMTP
server, login, password, etc.
• Network management optimization:
CAT launches an application in the mobile that reports to the USIM; channels and application metrics,
for network performance monitoring.
• Proactive synchronization:
CAT application, triggered by suitable events, may command the start of a data synchronization process
(e.g. for subscriber related parameters or ME configuration data) that may involve data entities in the UE
and in a synchronization server.
• Streaming:
CAT may launch a streaming client in the terminal to stream a video clip with the address (e.g. URL)
provided by the CAT.
4.2.3 Requirements
Identifier Requirement
REQ-7-02-01-01 The CAT shall be able to start a terminal application, providing its name and initial parameters.
REQ-7-02-01-02 The terminal shall inform the card (e.g. through events) about the terminal applications that can be
launched by the CAT, with the corresponding information on the needed parameters to launch each
terminal application.
REQ-7-02-01-03 The informing of the card shall be done after each start of card session and as soon as possible after
such an eligible application is added to, or removed from the terminal.
REQ-7-02-01-04 The user of the terminal shall be able to choose when he should be prompted for the issuance of the
CAT LAUNCH APPLICATION command. The prompt possibilities shall be:
• The user is prompted for each application to be launched.
• The user is prompted for those applications only that the user has selected, the other
applications are launched without being prompted.
The user is never prompted, i.e. all the applications are always launched.
REQ-7-02-01-05 Once launched, the application may interact with the user or another application, as though the user
launched the application.
REQ-7-02-01-06 If the handset is not able to launch the requested application, an error mechanism shall be specified to
inform the CAT, which shall include a reason code and details as to whether the error is temporary or
not.
REQ-7-02-01-07 Each application shall have a unique identifier or reference.
REQ-7-02-01-08 The format of the identifier shall be standardized.
REQ-7-02-01-09 There shall be the possibility to provide the application identifier in a standardized way (SCP decides
for the identifier value), or in a proprietary way (application provider decides for the identifier value).
REQ-7-02-01-10 An application parameter shall be uniquely identified.
REQ-7-02-01-11 This requirement shall be implemented as a letter class feature.
REQ-7-02-01-12 The UICC shall have proactive mechanisms that allow it to communicate with an application it has
launched.
REQ-7-02-01-13 Closing the communication with a launched application shall not automatically end the launched
terminal application.
Following are additional information to enhance the general comprehension of the requirements (i
...