Abstract:
The invention is a method of personalizing an application embedded in a secured electronic token which is able to manage first and second channels that allow to convey personalization data exchanged with a distant machine. Said first and second channels are of different types. The application is of Javacard™ type and comprises at least a function which is invoked when personalization data is received from the distant machine regardless of the channel used for conveying the personalization data.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to the methods of personalizing an application embedded in a secured electronic token. It relates particularly to methods of personalizing applications which are embedded in Javacard™ tokens. 
       PRIOR ART 
       [0002]    A secured electronic token such as a smart card may contain applications in the form of applets. On SIM cards, the applets may be accessed by a remote server via an over the air channel, known as OTA. OTA mechanism is defined by the ETSI SCP 102.225, ETSI-SCP 102.226, 3GPP 31.115, 3GPP 31.116 and GlobalPlatform (GP) version 2.2 for RAM standards. The OTA channel allows accessing data and applications which have been specifically developed for SIM cards. For example, smart cards intended to be used in Telecom domain or Machine To Machine (M2M) domain are able to manage an OTA communication. In particular SIM cards offer OTA features. These smart cards may also be accessed through the HyperText Transfer Protocol, usually called HTTP. In particular, the OMA-SCWS standard versions 1.0 and later define an administration protocol for the OTA administration of the Smart Card Web Server (SCWS) resources. This protocol is based on a HTTP POST message sent by an Admin Agent application to the OTA server. The Admin Agent application is located in the smart card. As a response, the OTA server sends back a SCWS administration command in the body of the HTTP POST response. According to the standard, a fixed Content-Type is specified in the header of this HTTP POST response. At the reception of this message, and thanks to the Content-Type, the Admin Agent application forwards the body of the HTTP POST response to the SCWS for the execution of the administration commands it contains. Then, once these administrative commands have been executed by the SCWS, another HTTP POST request is sent by the Admin Agent application in order to notify the OTA server of the commands execution results. This result data is put in the body of this HTTP POST message, and a specific Content-Type is set in the header of this HTTP POST. Using a similar principle, the GlobalPlatform® 2.2 standard (Amendment B “RAM over HTTP”) and the ETSI 102 226 standard (“RFM over HTTP”) have defined an administration protocol for the OTA administration of the Smart Card content. This channel is well suited for the Remote Applet Management (RAM) mechanism, for the administration of Security Domains, packages and applets. The GlobalPlatform® 2.2 standard specifies a fixed pattern of Content-Type to be used in HTTP POST request messages and HTTP POST response messages. 
         [0003]    An application embedded in a smart card may be personalized through several channels. In particular, the application may be reached via the I/O mode as defined by ISO7816 standard. In this case, APDU commands are sent to the cards. APDU stands for Application Protocol Data Unit in accordance with the ISO 7816-4 standard. The application may also be remotely reached over Short Message Service (SMS) and CATTP (Card Application Toolkit Transport Protocol). This mechanism is well-suited for Remote Applet Management (RAM) and Remote File Management (RFM). Additionally, the application may also be remotely reached through HTTP over Bearer Independent Protocol (BIP) or Internet Protocol (IP). 
         [0004]    When an application is intended to be reached through several kinds of channel, the application must comprise as many specific pieces of software as supported channel types. In other words, when personalizing an application, the part of the application which is activated depends on the type of the used channel. The mechanism of channel management requires the development of several pieces of software (also named methods) which are dedicated to a single channel type. The development of several pieces of software is costly and requires several testing steps. In addition, the development of several pieces of software increases the size of the application. 
         [0005]    There is a need for providing a transparent mechanism allowing to personalize an application embedded in a secure electronic token in an unified way whatever the used channel. 
       SUMMARY OF THE INVENTION 
       [0006]    An object of the invention is to solve the above mentioned technical problem. 
         [0007]    The object of the present invention is a method of personalizing an application embedded in a secured electronic token. The secure token is capable of managing first and second channels which allow to convey personalization data that are exchanged with a distant machine. Said first and second channels are of different types. The application is of Javacard™ type and comprises at least a function. The function is invoked when a personalization data is received from the distant machine whatever the channel used for conveying said personalization data is. 
         [0000]    In particular, the function may be a method of Javacard™ type. 
         [0008]    Advantageously, the first channel may be the I/O mode as defined by ISO7816 standard and the function may be the Process(APDU) method as defined in Javacard™ standard. 
         [0009]    In a preferred embodiment, the second channel may be the SMS over Card Application Toolkit Transport Protocol. 
         [0010]    Advantageously, the personalization data may be comprised in a message that contains an identifier meaning that the function is to be invoked. 
         [0011]    The message may comprise a TP-PID field which comprises the identifier. 
         [0012]    In another embodiment, the second channel may be one of HTTP or HTTPs over Bearer Independent Protocol or Internet Protocol. 
         [0013]    Advantageously, the personalization data may be comprised in a message that contains an identifier which means that the function is to be invoked. 
         [0014]    Advantageously, the message may comprise a content type field and the identifier may be a preset value of the content type field. 
         [0015]    Another object of the invention is a secure electronic token capable of managing first and second channels allowing to convey personalization data that is exchanged with a distant machine. Said first and second channels are of different types. The secure electronic token comprises an application of Javacard™ type. The application comprises at least a function. The secure electronic token comprises a means capable of invoking said function when a personalization data is received from the distant machine whatever the channel used for conveying the personalization data is. 
         [0016]    Advantageously, the first channel may be the I/O mode as defined by ISO7816 standard and the function may be the Process(APDU) method as defined in Javacard™ standard. 
         [0017]    Advantageously, the second channel may be the SMS over Card Application Toolkit Transport Protocol. 
         [0018]    In one embodiment, the personalization data may be comprised in a message. The message may comprise a TP-PID field and the secure token may comprise a second means capable of checking a value of a preset part of the TP-PID field. 
         [0019]    The second channel may be one of HTTP or HTTPs over Bearer Independent Protocol or Internet Protocol. 
         [0020]    Advantageously, the personalization data may be comprised in a message which contains a content type field. The secure token may comprise a second means capable of checking the value of the content type field. 
         [0021]    In a preferred embodiment, the secure electronic token may be a smart card. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0022]    Other characteristics and advantages of the present invention will emerge more clearly from a reading of the following description of a number of preferred embodiments of the invention with reference to the corresponding accompanying drawings in which: 
           [0023]      FIG. 1  depicts schematically an example of architecture of a secured electronic token which communicate with a distant server via a host machine according to the invention; 
           [0024]      FIG. 2  is a first example of message exchanges between a distant server and an application embedded in a secure token according to the invention; and 
           [0025]      FIG. 3  is a second example of message exchanges between a distant server and an application embedded in a secure token according to the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0026]    The invention may apply to any types of secured electronic token intended to contain applications which are compliant with the Javacard™ standard. The present invention may also apply to secure electronic tokens using the HyperText Transfer Protocol Secure, usually called HTTPS. In this specification, the secured electronic token is a SIM card but it could be any other kind of secured electronic device able to receive personalization data through several types of channel. A secured electronic token may be portable and may contain one or several memories, a microprocessor and a communication interface. In this specification, the secured electronic token is connected to a host machine. In particular, the host machine may be a mobile phone or telecom terminal. The secure electronic token accesses a remote server through the host machine. Alternatively, messages may be directly exchanged between the secure electronic token and the server machine without any intermediate host machine. 
         [0027]    The present invention relies on the fact that a unique method is invoked in the application to be personalized whatever the channel used for sending personalization data to the token which comprises the application. 
         [0028]    Thanks to the invention, a distant server may perform a remote unified personalization of applications that were not designed for. The invention allows managing legacy applications. 
         [0029]    An advantage of the invention is to allow to use the same personalization script whatever the origin of the script. In other words, the same personalization script may be used through I/O, TS-31.115 SMS or HTTP channel. 
         [0030]      FIG. 1  shows the architecture of a secure electronic token SC of SIM card type according to a preferred embodiment of the invention. The token SC communicates with a distant server SR via a host machine HM. 
         [0031]    The secure electronic token SC comprises a working memory MEM 1  of RAM type, two non volatile memories MEM 2  and MEM 3 , a microprocessor MP and a communication interface IN. 
         [0032]    The non volatile memory MEM 3  comprises one applet AP 1  which has a method MT 1 . The method MT 1  is the Process(APDU) method as defined in Javacard™ standard. 
         [0033]    The non volatile memory MEM 2  comprises an operating system OS, a Java Virtual Machine VM and two means M 1  and M 2 . The Virtual Machine VM may be a part of the operating system OS. The two means M 1  and M 2  may be a part of the operating system OS. 
         [0034]    The two memories MEM 2  and MEM 3  may be implemented as any combinations of one, two or more memories. These memories may be NAND flash or EEPROM memory or another type of non volatile memory. 
         [0035]    The host machine HM is a mobile phone. The SIM card SC is intended to exchange messages with the telecom handset HM through the communication interface IN. The telecom handset HM is intended to exchange messages with a distant server SR via the OTA mechanism. Thus the SIM card SC may exchange messages with the distant server SR through the connected mobile phone HM. 
         [0036]    The applet AP 1  is an application that may be personalized thanks to personalization data DA 1  or DA 2  provided by the distant machine SR. 
         [0037]    The means M 1  is capable of invoking the method MT 1  when the personalization data DA 1  or DA 2  is received from the distant machine SR. The means M 1  call the method MT 1  regardless of the channel that has been used for conveying the personalization data. 
         [0038]    The personalization data is received by the token SC through a message which comprises several fields. The means M 2  is able to check the value of a preset field of the received message. The behavior of means M 2  is described in the examples of  FIG. 2  and  FIG. 3 . 
         [0039]      FIG. 2  shows an example of a sequence of messages received and sent by the token SC according to the invention. In this first embodiment, the personalization messages are sent through the SMS mechanism. 
         [0040]    At first step S 1  the token SC receives a SMS-MT (Short Message Service-Mobile Terminated) comprising three elements: a TAR, a TP-Protocol-Identifier field PID and a personalization script DA 1 . 
         [0041]    The TAR contains an identifier of the targeted applet AP 1 . For example the TAR may contain the value “456912” which corresponds to the applet AP 1 . The TAR is coded with 3 bytes which belong to the applet AID. 
         [0042]    The personalization script DA 1  contains a list of APDU commands C_APDU_ 01 , C_APDU_ 02 , . . . , C_APDU_XX which are intended to be executed in the targeted applet. 
         [0043]    The field PID is a Protocol Identifier (also named TP-PID) field as defined by the 3GPP TS 23.040 standard. The field PID contains a bit which is set to the value &lt;&lt;1&gt;&gt;. This value means that the method MT 1  must be invoked in the targeted applet for personalization purpose. In another embodiment, the value &lt;&lt;0&gt;&gt; may mean that the method MT 1  must be called in the targeted applet for personalization purpose. 
         [0044]    Alternatively, a preset value of the whole field PID may be used instead of a single bit value. For example, the preset value “011000000b” may be used. The preset value may be selected in the following range [011000000b, 01111011 b]. 
         [0045]    The means M 2  checks the value of the preset bit in the field PID. 
         [0046]    Since the preset bit contains the value &lt;&lt;1&gt;&gt;, the method MT 1  is invoked in the targeted applet AP 1  at step S 2 . In the embodiment of  FIG. 2 , the method MT 1  is the Process(APDU) method. The method MT 1  is called for each APDU command of the personalization script DA 1 . Thus a first invocation Process(APDU, C_APDU_ 01 ) is performed. Then a second invocation Process(APDU, C_APDU_ 02 ) is performed and so on, until the last invocation Process(APDU, C_APDU_XX). The applet AP 1  executes all APDU commands of the script DA 1  in succession. This way the full personalization script DA 1  is executed into the targeted applet AP 1 . 
         [0047]    At a third step S 3  the token SC builds a SMS-MO (SMS-Mobile Originated) and sends the SMS-MO in response to the SMS-MT. The SMS-MO comprises three elements: the TAR, the TP-Protocol-Identifier field PID and result of the personalization script DA 1 . 
         [0048]    The TAR and the PID of the SMS-MO are similar to the TAR and PID of the corresponding SMS-MT. 
         [0049]    The result of the personalization script DA 1  contains a list of responses for each APDU command of the personalization script DA 1 : R_APDU_ 01 , R_APDU_ 02 , . . . , R_APDU_XX. Thus there are list of couples command/response (e.g. C_APDU_YY/R_APDU_YY). The SMS-MO is sent to the distant server SR thanks to the Telecom handset HM. 
         [0050]    Alternatively, the generation of the SMS-MO may be performed progressively as and when executing APDU commands. 
         [0051]    Alternatively, the checking of step S 2  may show that the preset bit does not contain the value corresponding to the request of method MT 1  call. In this case, the personalization script DA 1  is managed in a legacy manner for the applet AP 1 . Since the personalization script DA 1  has been received through SMS, the script content is executed in the applet AP 1  thanks to processToolkit(short event) with event set to ENVELOPE_DATA_DOWNLOAD (not drawn at  FIG. 2 ). 
         [0052]      FIG. 3  shows another example of a sequence of messages received and sent by the token SC according to the invention. In this second embodiment, the personalization messages are sent through the HTTP mechanism. In particular, the messages may be conveyed thanks to IP/HTTP mechanism. 
         [0053]    At first step S 1  the token SC receives a HTTP response comprising four elements: a X-Admin-Protocol, a X-Targeted-Application, a Content-Type and a personalization script DA 2 . 
         [0054]    The X-Admin-Protocol contains “globalplatform-remote-admin/1.0”. The X-Admin-Protocol field is defined in the GP 2.2 Amendment B RAM over http. 
         [0055]    The X-Admin-Targeted-Application contains an identifier of the targeted applet AP 1 . For example the X-Targeted-Application may contain the value “//aid/A000000018/03090” which corresponds to the applet AP 1 . 
         [0056]    The personalization script DA 2  contains a list of APDU commands C_APDU_ 01 , C_APDU_ 02 , . . . , C_APDU_XX which are intended to be executed in the targeted applet. 
         [0057]    The field Content-Type contains the value “vnd.process.c_apdus”. This value means that the method MT 1  must be invoked in the targeted applet for personalization purpose. 
         [0058]    The means M 2  checks the value of the field Content-Type. 
         [0059]    Since the Content-Type contains the value &lt;&lt;vnd.process.c_apdus&gt;&gt;, the method MT 1  is called in the targeted applet AP 1  at step S 2 . In the embodiment of  FIG. 3 , the method MT 1  is the Process(APDU) method. The method MT 1  is invoked for each APDU command comprised in the personalization script DA 2 . Thus a first call Process(APDU, C_APDU_ 01 ) is performed. Then a second call Process(APDU, C_APDU_ 02 ) is performed and so on until the last call Process(APDU, C_APDU_XX). The applet AP 1  successively executes all APDU commands of the script DA 2 . This way the full personalization script DA 2  is executed into the targeted applet AP 1 . 
         [0060]    At a third step S 3  the token SC sends a HTTP Post request in response to the HTTP response. The HTTP Post comprises three elements: a X-Admin-Protocol, a Content-Type and the result of the personalization script DA 2 . 
         [0061]    The X-Admin-Protocol contains “globalplatform-remote-admin/1.0”. The field Content-Type contains the value “vnd.process.r_apdus”. This value of the Content-Type field allows the distant server SR to analyze the content of the HTTP Post request. 
         [0062]    The result of the personalization script DA 2  contains a list of responses for each APDU command of the personalization script DA 2 : R_APDU_ 01 , R_APDU_ 02 , . . . , R_APDU_XX. The HTTP Post message is sent to the distant server SR thanks to the mobile phone HM. 
         [0063]    Advantageously, the HTTP-TLS mechanism may be used for exchanging personalization messages between the token SC and the distant machine SR. 
         [0064]    Thanks to the invention, an application embedded in a secure electronic token may be managed or personalized in a unified way. In particular, the application may be reached through I/O contact mode or remotely through 2G or 3G or CDMA networks. The application may also be remotely reached through IP network and Long Term Evolution (LTE also called 4G) network.