1、 ETSI TR 102 481 V7.0.0 (2007-02)Technical Report Smart Cards; Requirements for UICC - external peripherals data exchange (Release 7)Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 2 Reference DTR/SCP-R00003 Keywords Smart Card ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.
2、: +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 may be made a
3、vailable 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 o
4、n 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 fin
5、d 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
6、 in all media. European Telecommunications Standards Institute 2007. 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 Members. 3
7、GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 3 Definitions and abbreviations.5 3.1 Definitions5 3.2 Abbrevi
8、ations .5 4 Use Cases .5 4.1 Memory Card .5 4.2 GPS 6 4.3 Biometric Sensors.6 4.4 General proprietary device interface 6 5 Preliminary Requirements Considerations.7 5.1 General .7 5.2 Commands Functional Description 7 6 Conclusion7 Annex A: Examples8 A.1 Virtual Peripheral Example8 Change History.10
9、 History 11 Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 4 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-member
10、s, 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.as
11、p). 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 pre
12、sent document. Foreword This Technical Report (TR) 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 decides to modify the contents of t
13、he present document, it will be re-released by EP SPC with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x: the first digit: 1 presented to TC SCP for information; 2 presented to TC SCP for approval; 3 or greater indicates TC SCP approved do
14、cument 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. Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02)
15、5 1 Scope The present document analyses the possibility to define a general mechanism for data exchange between the UICC and different kind of Terminals external peripherals. 2 References For the purposes of this Technical Report (TR), the following references apply: NOTE: While any hyperlinks inclu
16、ded in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 1 ISO/IEC 7816-3: “Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols“. 2 ETSI TS 102 221: “Smart Ca
17、rds; UICC-Terminal interface; Physical and logical characteristics“. 3 ETSI TS 102 223: “Smart Cards; Card Application Toolkit (CAT)“. 4 ETSI TS 102 412: “Smart cards; Smart Card Platform Requirements Stage 1“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document,
18、 the following term and definition applies: external peripherals: device connected or integrated within the handset, such as MMC/SD slot, fingerprint sensors, GPS device 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: APDU Application Protocol Data Unit
19、 API Application Programming Interface CAT Card Application Toolkit GPS Global Positioning System HTTP Hypertext Transfer Protocol MMC MultiMediaCard MMS Multimedia Messaging Service NUT New UICC-Terminal interface SD Secure Digital 4 Use Cases 4.1 Memory Card The UICC shall be able to seamlessly ex
20、change data with Memory Card as a companion device inserted to mobile terminal, for example to access pictures and multimedia files directly from the UICC. Through an appropriate set of commands the UICC could have access to the Memory Card in order to store there some pictures linked to the card ph
21、onebook, MMS, etc. Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 6 4.2 GPS Most of 3G terminals in the field can be able to access a GPS device or will have an integrated GPS. Allowing the UICC to retrieve localization information from this device in a generic way through the Mobile Terminal can p
22、rovide great flexibility for operators in designing services. Within this scenario the UICC shall be able for example to access a standard GPS device connected to the handset reporting positioning information to a secure server. This can be used by a sales force, for example, and authorized personne
23、l only can be able to access the geographical positions of those subscribers. Similarly, a granted server can ask the UICC for the position of the customer and the UICC could request positioning information to the GPS peripheral sending it back encrypted to the server. Summarizing, the UICC shall ha
24、ve the possibility to: ask for GPS localization data (i.e. GPS position, GPS velocity, etc. or GPS code-phase, doppler, etc.) and other GPS parameters; provide data to the GPS device (i.e. GPS Assistance data). 4.3 Biometric Sensors Services requiring mobile payments or anyway a strong security can
25、be accessed after a biometric authentication done with a Mobile Terminal equipped with a biometric sensor (e.g. fingerprint sensor, camera, etc.). In this case an application can ask the user to authenticate itself with a biometric characteristics before accessing the payment service. When the user
26、try to access these kind of services the UICC can exchange data with the biometric sensor through an appropriate set of commands retrieving the information required for the authentication, in case of a matching algorithm running on the UICC, or the authentication response in case of a matching algor
27、ithm running on the Mobile Terminal. This use case requires establishing a secure channel between the UICC biometric application and the biometric sensor on the terminal but also an high speed interface if the matching algorithm runs on the card. 4.4 General proprietary device interface There are ma
28、ny new usecases emerging that are enhanced by allowing the UICC to use a proprietary protocol interface to a device that is connected to the terminal. Examples are: Printer connection. Telemetry device control. Vending machine control. Car system control. Remote control systems. For these usecases a
29、 set of generic commands are needed that allows the UICC to use these proprietary protocols. The UICC will need to be able to discover these devices from the terminal and establish which protocol is to be used. It is expected that the UICC will initiate communication with this device, however some p
30、rotocols may require that the connected device is able to trigger the UICC communication. Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 7 5 Preliminary Requirements Considerations 5.1 General These peripherals management capabilities can be used by applications to store and retrieve data from memo
31、ry cards, to activate a camera, to require biometric authentication using the fingerprint sensor or to exchange data with a GPS device in order to provide enhanced services. It shall be possible to define a mechanism to reach these peripherals with both ISO/IEC 7816-3 1 interface and NUT interface.
32、The mechanism shall exploit the interface capabilites and for this reason it could be different in the two cases (ISO/NUT interfaces). A list of the available peripherals (e.g. GPS device, memory slots, etc.) shall be sent by the Mobile Terminal to the UICC at power on. Moreover if a peripheral is a
33、dded subsequently, the Mobile Terminal shall inform the UICC (i.e. if the user inserts a memory card in the mobile terminal, it shall communicate it to the card). The UICC shall then have the capability to ask for information and status of a particular peripheral and also to ask the Mobile Terminal
34、to set up a connection with a peripheral chosen and to remove it. The physical access between the UICC and the peripherals has to be done through the Mobile Terminal exploiting the standard interfaces for UICC and the peripherals themselves so that only a logical access can be established between th
35、em. 5.2 Commands Functional Description Hereafter there is a functional overview of the commands that could be exchanged between the UICC and the Terminal in order to perform actions on a terminal peripheral. The set of commands has to be implemented in the proper way on different application protoc
36、ols ( i.e. APDU, CAT or HTTP) depending on the UICC-terminal interface. GET PERIPHERAL STATUS: a command is required in order to know if the peripheral is present in the terminal, which type of peripheral is inserted in the terminal and if it is available. OPEN PERIPHERAL: a command is required in o
37、rder to open a connection with the peripheral. PERFORM PERIPHERAL COMMAND: a command (or a set of commands) is required in order to Read/Write data from/to the peripherals and, when necessary, to set parameters on the peripherals. CLOSE PERIPHERAL: a command is required in order to close the connect
38、ion with the peripheral. 6 Conclusion In order to define a mechanism for the UICC-External Peripherals data exchange a unique set of requirements can be specified identifying the commands functional behaviour with a CR to TS 102 412 4. The mechanism implementation should then be studied and specifie
39、d taking into account the different application protocol depending on the adopted UICC-Terminal Interface and requiring CRs to the appropriate Technical Specifications. Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 8 Annex A: Examples A.1 Virtual Peripheral Example The Virtual Peripheral concept c
40、ould be taken as an example in order to minimize the impact on Terminal. In order to standardize a minimal set of commands, allowing the communication with external peripherals, the virtual peripheral concept has been adopted by many operating systems. Virtual peripherals are peripheral devices simu
41、lated by the operating system. An abstraction layer allows the definition of a common interface to control peripheral functionality just using a few APIs. A virtual peripheral implements the software driver, which receives standard APIs and translates them in specific peripheral commands. Open Read
42、Write Control Close Driver Virtual Peripheral Peripheral Figure 1: Virtual peripheral Applications can get information from the peripheral or put some control value to configure/activate functionalities through Control API that can be addressed using a set of unique numbers (one per functionality) a
43、nd that are specified according to the peripheral functionalities. Once specified the APIs set, the interface between applications and virtual peripherals is fixed. To support new peripherals, developers just need to implement the new associated driver according to the peripheral functionality and t
44、he Control parameters (unique numbers and additional arguments) definition. Virtual Peripherals concept could then be used to simplify the definition of the UICCcommands set dealing with the Open, Read, Write, Control and Close API for each terminal peripheral. Lets consider for example the memory c
45、ard use case. Without knowing which kind of memory card is inserted in the terminal an application in the UICC could be able to exchange data trough a simple set of commands such as: GET PERIPHERAL STATUS (peripheral=memory card). OPEN PERIPHERAL (peripheral=memory card). PERFORM PERIPHERAL COMMAND
46、(Control). PERFORM PERIPHERAL COMMAND (Read; data=Data to Read). PERFORM PERIPHERAL COMMAND (Write; data=Data to Write). CLOSE PERIPHERAL (peripheral=memory card). Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 9 The terminal could interpret the meaning of each API (Open, Read, Write, Control and C
47、lose) for the memory card peripheral being able, through a specific driver, to translate this request to the proper protocol for MMC, SD card, Compact Flash or Memory Stick. Another example could be done with a biometric sensor. In this case the advantage of the Virtual Peripherals concept is greate
48、r than the previous one due to the chance to avoid the need to know all the specific interfaces with the different sensors. The command sequence could be the same, but in this case Read command could be the acquisition of the biometric template and the Write command could be used to pass the templat
49、e stored in the UICC to the biometric sensor. The UICC application could use the Control API in order to know which kind of biometric facility it can exploit. Release 7 ETSI ETSI TR 102 481 V7.0.0 (2007-02) 10Change History Change history 0.0.1 2006-07 SCP REQ#10 0.3.0 2006-07 SCP REQ#10 1.0.0 2006-07 SCP #26 1.1.0 2006-09 SCP #27: The reference to TS 102 412 has been added in the References Section 1.2.0 2007-01 SCP#28: Very minor editorial correction: date of the document and “smart quotes“ replaced in added reference. Hanging paragraph
