1、 ETSI TS 102 225 V12.1.0 (2014-10) Smart Cards; Secured packet structure for UICC based applications (Release 12) TECHNICAL SPECIFICATION ETSI ETSI TS 102 225 V12.1.0 (2014-10)2Release 12 Reference RTS/SCP-T0284vc10 Keywords security, smart card ETSI 650 Route des Lucioles F-06921 Sophia Antipolis C
2、edex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org The present document may be made avai
3、lable 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 only
4、 prevailing document is the print of the Portable Document Format (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 othe
5、r 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 or utilized in any form
6、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 al
7、l media. European Telecommunications Standards Institute 2014. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organiz
8、ational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 102 225 V12.1.0 (2014-10)3Release 12 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informa
9、tive references 6g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 8g34 Overview of security system 9g34.1 Protocol for generalised secured packets 9g34.2 Protocol for secured messages based on HTTPS . 10g35 Generalized secured packet structure . 10g35.1 Command packet st
10、ructure . 10g35.1.1 Coding of the SPI 12g35.1.2 Coding of the KIc . 13g35.1.3 Coding of the KID 13g35.1.3.1 Coding of the KID for Cryptographic Checksum . 13g35.1.3.2 Coding of the KID for Redundancy Check . 14g35.1.4 Counter Management 15g35.2 Response Packet structure 15g36 Implementation for CAT_
11、TP . 17g37 Implementation for TCP/IP 17g38 Secured message structure for HTTPS . 18g3Annex A (normative): Relation between security layer and GlobalPlatform security architecture. 19g3A.1 Key version - counter association within a Security Domain 19g3A.2 Security keys KIc, KID 19g3Annex B (informati
12、ve): Example for CRC computation 20g3Annex C (informative): Change history . 21g3History 22g3ETSI ETSI TS 102 225 V12.1.0 (2014-10)4Release 12 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to th
13、ese 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. Lates
14、t updates are available on the ETSI Web server (http:/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
15、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). It is based on work originally done in the 3GPP in TSG-terminals WG3 and ETSI SMG. The contents of the p
16、resent 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
17、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, correct
18、ions, 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“, “may not“, “need“, “need not“, “will“, “will not“, “can“ and “cannot“ are to b
19、e 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 ETSI TS 102 225 V12.1.0 (2014-10)5Release 12 1 Scope The present document specifie
20、s the structure of Secured Packets for different transport and security mechanisms. It is applicable to the exchange of secured packets between an entity in a network and an entity in the UICC. Secured Packets contain application messages to which certain mechanisms according to ETSI TS 102 224 1 ha
21、ve been applied. Application messages are commands or data exchanged between an application resident in or behind the network and on the UICC. The Sending/Receiving Entity in the network and the UICC are responsible for applying the security mechanisms to the application messages and thus turning th
22、em into Secured Packets. 2 References References are either specific (identified by date of publication and/or edition number or version number) or References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, onl
23、y the cited version applies. For non-specific references, the latest version of the reference 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 pre
24、sent document. Referenced documents which are not found to be publicly available in the expected location might be found at http:/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. 2.1 No
25、rmative references The following referenced documents are necessary for the application of the present document. 1 ETSI TS 102 224: “Smart Cards; Security mechanisms for UICC based Applications - Functional requirements“. 2 Void. 3 ISO 16609 (2004): “Banking - Requirements for message authentication
26、 using symmetric techniques“. 4 Void. 5 ETSI TS 131 115: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Secured packet structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications (3GPP TS 31.115)“. 6 “GlobalPlatfor
27、m Card Specification“, Version 2.2.1. NOTE: See http:/www.globalplatform.org/. 7 “Applied Cryptography: Protocols, Algorithms, and Source Code in C“, 2nd Edition, Bruce Schneier, John Wiley ETSI numbering system for telecommunication application providers“. 9 ETSI TS 102 226: “Smart Cards; Remote AP
28、DU structure for UICC based applications“. 10 ETSI TS 102 127: “Smart Cards; Transport protocol for CAT applications; Stage 2“. ETSI ETSI TS 102 225 V12.1.0 (2014-10)6Release 12 11 ISO/IEC 13239 (2002): “Information technology - Telecommunications and information exchange between systems - High-leve
29、l data link control (HDLC) procedures“. 12 FIPS-197 (2001): “Advanced Encryption Standard (AES)“. NOTE: See http:/csrc.nist.gov/publications/fips/index.html. 13 NIST Special Publication 800-38A (2001): “Recommendation for Block Cipher Modes of Operation - Methods and Techniques“. NOTE: See http:/csr
30、c.nist.gov/publications/nistpubs/. 14 NIST Special Publication 800-38B (2005): “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication“. NOTE: See http:/csrc.nist.gov/publications/nistpubs/. 15 “GlobalPlatform Card UICC Configuration“, Version 1.0.1. 16 ETSI TS 102 484:
31、 “Smart Cards; Secure channel between a UICC and an end-point terminal“. 17 ETSI TS 102 483: “Smart cards; UICC-Terminal interface; Internet Protocol connectivity between UICC and terminal“. 18 ETSI TS 102 223: “Smart Cards; Card Application Toolkit (CAT)“. 19 “GlobalPlatform Card Specification Vers
32、ion 2.2, Amendment B“ Version 1.1.1. NOTE: See http:/www.globalplatform.org/. 2.2 Informative references 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. 3 Definitions a
33、nd abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Advanced Encryption Standard (AES): standard cryptographic algorithm specified in FIPS-197 12 application layer: layer above the Transport Layer on which the Application Messages are
34、 exchanged between the sending and receiving applications application message: package of commands or data sent from the Sending Application to the Receiving Application, or vice versa, independently of the transport mechanism NOTE: An Application Message is transformed with respect to a chosen Tran
35、sport Layer and chosen level of security into one or more secured packets. card manager: generic term for the 3 card management entities of a GlobalPlatform card i.e. the OPEN, Issuer Security Domain and the Cardholder Verification Method Services provider as defined in the GlobalPlatform Card Speci
36、fication 6 command header: security header of a command packet NOTE: It includes all fields except the Secured Data. ETSI ETSI TS 102 225 V12.1.0 (2014-10)7Release 12 command packet: secured packet transmitted by the Sending Entity to the Receiving Entity, containing a secured Application Message co
37、unter: mechanism or data field used for keeping track of a message sequence NOTE: This could be realized as a sequence oriented or time stamp derived value, maintaining a level of synchronization between the Sending Entity and the Receiving Entity. cryptographic checksum: string of bits derived from
38、 some secret information, (e.g. a secret key), part or all of the Application Message, and possible further information (e.g. part of the Security Header) NOTE: The secret key is known to the Sending Entity and to the Receiving Entity. The Cryptographic Checksum is often referred to as Message Authe
39、ntication Code. Data Encryption Standard (DES): standard cryptographic algorithm specified as DEA in ISO 16609 3 Data Encryption Key (DEK): key identifier for ciphering keys as defined in ETSI TS 102 226 9 digital signature: string of bits derived from some secret information, (e.g. a secret key), t
40、he complete Application Message, and possible further information (e.g. part of the Security Header) NOTE: The secret information is known only to the Sending Entity. Although the authenticity of the Digital Signature can be proved by the Receiving Entity, the Receiving Entity is not able to reprodu
41、ce the Digital Signature without knowledge of the secret information owned by the Sending Entity. issuer security domain: on-card entity providing support for the control, security, and communication requirements of the Card Issuer as defined in the GlobalPlatform Card Specification 6 receiving appl
42、ication: entity to which the Application Message is destined receiving entity: entity where the Secured Packet is received (e.g. SMS-SC, UICC, USSD entry point, or dedicated Toolkit Server) and where the security mechanisms are utilized NOTE: The Receiving Entity processes the Secured Packets. redun
43、dancy check: string of bits derived from the Application Message and possible further information for the purpose of detecting accidental changes to the message, without the use of any secret information response header: security header of a response packet response packet: secured packet transmitte
44、d by the Receiving Entity to the Sending Entity, containing a secured response and possibly application data secured data: this field contains the secured application message and possibly padding octets secured packet: information flow on top of which the level of required security has been applied
45、NOTE: An Application Message is transformed with respect to a chosen Transport Layer and chosen level of security into one or more Secured Packets. security domain: on-card entity providing support for the control, security, and communication requirements of the Application Provider as defined in th
46、e GlobalPlatform Card Specification 6 security header: that part of the secured packet which consists of all security information (e.g. counter, key identification, indication of security level, checksum or Digital Signature) sender identification: simple verification of the identity of the Sending
47、Entity by the Receiving Entity comparing the sender identity with an a priori stored identity of the sender at the Receiving Entity sending application: entity generating an Application Message to be sent sending entity: entity from which the Secured Packet originates (e.g. SMS-SC, UICC, USSD entry
48、point, or dedicated Toolkit Server) and where the security mechanisms are invoked NOTE: The Sending Entity generates the Secured Packets to be sent. status code: indication that a message has been received (correctly or incorrectly, indicating reason for failure) ETSI ETSI TS 102 225 V12.1.0 (2014-1
49、0)8Release 12 transport layer: layer responsible for transporting Secured Packets through the network NOTE: The transport layer implements one or more transport mechanisms, (e.g. SMS or USSD). unsecured acknowledgement: status code included in a response message 3.2 Abbreviations For the purpose of the present document, the following abbreviations apply: AES Advanced Encryption Standard API Application Programming Interface ARD Additional Response Data CBC Cipher Block Chaining CC Cryptographic Checksum CHI Command Head
