ETSI TS 102 350-2005 Smart cards Identity Files and Procedures on a UICC Stage 1 (Release 7)《智能卡 关于UICC的识别文件和程序 第1阶段(版本7 0 0 第7次发布)》.pdf

《ETSI TS 102 350-2005 Smart cards Identity Files and Procedures on a UICC Stage 1 (Release 7)《智能卡 关于UICC的识别文件和程序 第1阶段(版本7 0 0 第7次发布)》.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 102 350-2005 Smart cards Identity Files and Procedures on a UICC Stage 1 (Release 7)《智能卡 关于UICC的识别文件和程序 第1阶段(版本7 0 0 第7次发布)》.pdf（15页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 102 350 V7.0.0 (2005-09)Technical Specification Smart cards; Identity Files and Procedures on a UICC; Stage 1 (Release 7) ETSI ETSI TS 102 350 V7.0.0 (2005-09) 2 Release 7 Reference DTS/SCP-R0287 Keywords ID, security, smart card ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex -

2、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 Individual copies of the present document can be downloaded from: http:/www.etsi.org The present document ma

3、y 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 ver

4、sion 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

5、 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 r

6、eproduction in all media. European Telecommunications Standards Institute 2005. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its

7、 Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 350 V7.0.0 (2005-09) 3 Release 7 Contents Intellectual Property Rights4 Foreword.4 Introduction 4 1 Scope 5 2 References 5 3 Definitions and abbreviations.5 3.

8、1 Definitions5 3.2 Abbreviations .6 4 Overview 6 4.1 Basic functionality of a TM6 5 Requirements7 5.1 Description of Requirements7 5.1.1 Deployment Contexts for TMUICC .7 5.2 Secure Communications with the TMUICC 10 5.2.1 Basic Requirements 10 Annex A (informative): Liberty Alliance requirements12 A

9、nnex B (informative): Change history .13 Annex C (informative): Bibliography.14 History 15 ETSI ETSI TS 102 350 V7.0.0 (2005-09) 4 Release 7 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to thes

10、e 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

11、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

12、 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 Project Smart Card Platform (SCP). The present document defines the stage 1 requirements for identity files and procedures on a UICC. The

13、 contents of the present document are subject to continuing work within EP SCP and may change following formal EP SCP approval. If EP 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

14、 follows: Version x.y.z where: x the first digit: 0 early working draft; 1 presented to EP SCP for information; 2 presented to EP SCP for approval; 3 or greater indicates EP SCP approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enh

15、ancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. Introduction There are a number of industry organizations producing authentication, privacy, and payment standards for the enterprise, mobile, financial, and ser

16、vices industries. For example the Liberty Alliance are creating specifications describing how a users digital identity may be “federated“, i.e. shared between (WEB) Service Providers and Identity Providers, to provide single sign-on and other services over mobile and wired networks in both online (c

17、onnected) and offline (standalone) environments. Another example is that the Open Mobile Alliance has produced a set of requirements in order to create a single Identity Management enabler to be used by all OMA enablers. The UICC platform is considered a candidate for a so-called Trusted Module for

18、performing these identification, authentication, authorization and secure storage of personal data. Interoperability considerations require the standardization of the UICC/ME interface for the “identity“ parameters on the card. The present document is intended to collate the functional requirements

19、from the Liberty Alliance and other “identity“ forums that may have similar requirements. ETSI ETSI TS 102 350 V7.0.0 (2005-09) 5 Release 7 1 Scope The present document covers the client environment which typically includes an Identity User Agent (IdUA) and a secure hardware Trusted Module (TM). Ope

20、ration of the TM based on a UICC requires the use of existing standardized functions and applications on the UICC, as well as functions that are unique to the TM. The present document focuses on the requirements for the TMUICC which has emerged from organizations such as Liberty Alliance and other r

21、elevant fora. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific refer

22、ence, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. 1 ETSI TS 102 221: “Smart cards; UICC-Terminal interface; P

23、hysical and logical characteristics“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: authentication assertion: proof of the authentication status of a user that is acceptable to the service provider for which acces

24、s is requested NOTE: An authentication assertion may include information describing the authentication context and cryptographic objects required for communication with the WSP. Identity Provider: entity that creates, maintains and manages identity information for users and provides user authenticat

25、ion to other service providers within a federation of service providers and other identity providers that have business relationship and operational agreements Identity Service: Internet-based service that is invoked by the users identity Identity User Agent (IdUA): software that allows users to ret

26、rieve and render web content, interact with an IdP, a web service provider (WSP) and has an abstracted logical interface to a Trusted Module Signing: in TS 102 350, “signing“ a message refers to the mechanism to create a proof of origin of a message by use of either Digital Signature or Cryptographi

27、c Checksum Trusted Module: accessible storage and processing module available in association with an IdUA NOTE: Functions include storage of personal data and credentials, client provisioning, authentication, secure messaging and application-layer security such as digital signature. ETSI ETSI TS 102

28、 350 V7.0.0 (2005-09) 6 Release 7 Trusted Module on a UICC: removable TM based on a UICC as defined in TS 102 221 1 with at least one authentication application as they appear at its interface, including requirements for an end to end secure interface to the IdP and a secure local interface to the I

29、dUA Web Service: Generically, a service defined in terms of an XML-based protocol, often transported over SOAP, and/or a service whose instances, and possibly data objects managed therein, are concisely addressable via URIs NOTE: Such a generic web service (gWS) may be defined in various proprietary

30、 and/or standardized terms, e.g. security paradigms. Web Service Consumer: a role a system entity acts/performs when it makes a request to a web service Web Service Provider: a role a system entity acts/performs when it provides a web service 3.2 Abbreviations For the purposes of the present documen

31、t, the following abbreviations apply: AP Attribute Provider CAD Card Acceptance Device IdP Identity Provider IdUA Identity User Agent MNO Mobile Network Operator OTA Over The Air SOAP Simple Object Access Protocol SSO Single Sign On TM Trusted Module TMUICC Trusted Module implemented on a UICC URI U

32、niform Resource Identifier WSC Web Service Consumer WSP Web Service Provider XML eXtended Markup Language 4 Overview A TM is a removable, personalized module containing files and executables that provides a secure storage and execution environment for certain operations required by an IdP and a IdUA

33、 in identity services. Functions include storage of personal data and credentials, IdUA provisioning, authentication, secure messaging and application-layer security such as digital signature. The UICC requirements for identity files and procedures are designed to fully support the requirements of t

34、he Liberty Alliance and OMA. For clarity the relevant Liberty Alliance and OMA requirements are provided for information. 4.1 Basic functionality of a TM Basic functionality of the interfaces between identity services and the TMUICC are to: Create and remotely manage Identity provisioning and creden

35、tial storage files on a TMUICC. Use the TMUICC to provide identification, multiple levels of authentication and authorization i.e. signing (some schemes require the TM to sign authorization tokens for proof-of-presence of the user). Achieve end-to-end secure messaging between authorized entities (th

36、e IdP and the IdUA) and files and applications on the TMUICC in non-secure client environments and across insecure networks. TMs shall be able to be deployed in environments where messages originating or terminating at the TMUICC can be subject to replay, eavesdropping or manipulation attacks that m

37、ay not be feasible within a mobile phone or across mobile networks. Typical scenarios include deployment in a PC or in a PC peripheral device, as well as certain types of smart phone equipped with IdUA and an operating system with an open API. ETSI ETSI TS 102 350 V7.0.0 (2005-09) 7 Release 7 Figure

38、 1 shows some of the entities involved in a typical identity service. Only the IdP and the IdUA are allowed to directly interface to the TM. WSPs can interface to applications in the client environment and to the IdUA. IdP-UICC secure interface SP Environment IdP Environment IdUA-UICC secure interfa

39、ce Identity User Agent TM Application IdP Server Authentication Application Signature Application Client Environment UICC WSP User Applications Figure 1: Standardized Interfaces Required to the TMUICC 5 Requirements 5.1 Description of Requirements 5.1.1 Deployment Contexts for TMUICC The Card accept

40、ing device shall assume that the TMUICC will support all context(s) defined in this clause. The simultaneous use of the TMUICC in different contexts at the same time is FFS. (A single set of protocols and functions on the TMUICC that will meet the requirements of all deployment contexts implies a TM

41、UICC-related protocol stack and command set that is common to all deployment contexts). The figures and table below categorize and characterize the deployment contexts. ETSI ETSI TS 102 350 V7.0.0 (2005-09) 8 Release 7 CAD TMUICC PC IdUA ID applications e.g. USB, IrDA, Access Network Internet IdP Au

42、thentication vectors Context 1: TMUICC in a CAD connected to a PC communication of an opaque identifier from the TMUICC to the IdP, to bootstrap the communications and authentication processes; secure distribution of dynamic session keys derived from shared secrets; secure processing of requests and

43、 responses for authentication assertions and for authorization assertions. These messages may need to be signed and verified by the TMUICC or IdP; secure transfer of application commands and responses, e.g. to invoke a challenge/response authentication application or a PIN verification application o

44、n the TMUICC; sending and receiving of authentication vectors inside the secure channels; requesting, sending and receiving of authentication assertions and authorization assertions. Some services require the assertions to be signed by the IdUA (i.e. the TM) before being passed to a WSP - the signat

45、ures being verified by either the IdP or WSP. These are: 1) Authentication. 2) Message integrity. 3) Replay detection and sequence integrity. ETSI ETSI TS 102 350 V7.0.0 (2005-09) 11Release 7 4) Proof of receipt and execution. 5) Message confidentiality. 6) Security management. 7) Exceptional proced

46、ures. The TMUICC will also provide: 8) Signing of authorization assertions using symmetric techniques. 9) Secure storage and management functions for provisioned keys. 10) Secure generation, storage and deletion of temporary symmetric keys. 11) A secure environment for the execution of cryptographic

47、 algorithms, preventing unauthorized monitoring of or interference with such operations. ETSI ETSI TS 102 350 V7.0.0 (2005-09) 12Release 7 Annex A (informative): Liberty Alliance requirements Liberty Alliance requirements for identity services will create corresponding requirements on the TMUICC tha

48、t will be taken into account for standardization in ETSI SCP: IdUA obtains and securely stores pre-issued assertions from the IdP and uses them to access services e.g. when the IdP is not accessible. This includes keeping records of assertions that have been issued and/or stored and reporting back t

49、o the IdP. IdUA acts as an attribute provider, i.e.: - Obtains (e.g. personal) attributes, validates them and stores them securely. - Allows controlled access to attributes by validating service authorization assertions from identity-consuming entities. IdUA acts as a Discovery Service by permitting discovery of its AP services, requiring validation of authorization assertions from WSCs. Pro-active SSO: Enables efficient SSO when the IdUA has behavioural knowledge that an WSP will require authentication in the near future. IdUA announces