WO2017167408A1 - Method and device for communication between a mobile device and a secure element - Google Patents

Method and device for communication between a mobile device and a secure element Download PDF

Info

Publication number
WO2017167408A1
WO2017167408A1 PCT/EP2016/068451 EP2016068451W WO2017167408A1 WO 2017167408 A1 WO2017167408 A1 WO 2017167408A1 EP 2016068451 W EP2016068451 W EP 2016068451W WO 2017167408 A1 WO2017167408 A1 WO 2017167408A1
Authority
WO
WIPO (PCT)
Prior art keywords
dat
mobile device
secure element
data file
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2016/068451
Other languages
French (fr)
Inventor
Yanjing Sun
Yuexin ZHOU
Zheng Kan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemalto SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemalto SA filed Critical Gemalto SA
Publication of WO2017167408A1 publication Critical patent/WO2017167408A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/183—Processing at user equipment or user record carrier
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier

Definitions

  • the present invention relates to a method for communication between a mobile device and a secure element of said mobile device.
  • the invention also relates to an associated mobile device.
  • OMAPI of the SIMAIIiance permits a mobile device to communicate with a secure element of said mobile device.
  • Said secure element is for example a SIM ("Subscriber Identity Module”) card or a USIM ("Universal Subscriber identity Module”) card, said mobile device being a NFC ("Near Field Communication”) mobile phone.
  • SIM Subscriber Identity Module
  • USIM Universal Subscriber identity Module
  • NFC Near Field Communication
  • the standard of communication permits in particular to send from said mobile phone some commands to said secure element and to receive by said mobile phone some responses from said secure element.
  • This standard of communication is complex to implement and is only dedicated to NFC mobile devices.
  • a method for communication between a secure element of a mobile device and said mobile device comprising at least a first data file and said mobile device comprising a corresponding first data file, wherein said method for communication comprises:
  • one uses data files which are common to the mobile device and to the secure element to send a command from said mobile device to the secure element and to receive by said mobile device a response of the execution of said command from said secure element. It doesn't need any complex standard of communication. It may be applied to any type of mobile device. Moreover, the invention permits a mobile device to know when an update in a data file of said secure element takes place, and to update accordingly a data file in its own memory, which corresponds to the secure element's updated data file.
  • the method for communication in accordance with the invention further comprises the following characteristics.
  • the command to be executed by said secure element is an APDU command.
  • the first data file is an elementary file.
  • the first data file and the second data file are:
  • the second data file is a data file which is smaller than the first data file.
  • said method for communication further comprises switching by said secure element of the file identifications between an elementary file of said secure element and said smaller data file.
  • said method for communication further comprises:
  • said method for communication further comprises:
  • said secure element is a SIM card, USIM card, an eSE, a micro-SD, an UICC, or an embedded UICC.
  • said mobile device is a mobile phone.
  • said mobile device is an Android device.
  • said method communication further comprises sending by said secure element to said mobile device a proactive refresh command comprising a file identification of said second data file to be read.
  • said mobile device comprises an operating system which is adapted to perform the steps performed by said mobile device.
  • said mobile device further comprises an application and said method for communication further comprises:
  • a mobile device for communicating with a secure element of said mobile device, said secure element comprising at least a first data file and said mobile device comprising a corresponding first data file, wherein said mobile device is adapted to:
  • FIG. 1 illustrates a schematic organization chart of a method for communication according to a first non-limitative embodiment of the invention
  • FIG. 2 illustrates a schematic organization chart of a method for communication according to a second non-limitative embodiment of the invention
  • FIG. 3 illustrates some further steps of the method for communication of Fig. 6;
  • Fig. 4 illustrates a mobile device which is adapted to carry out the method for communication of Fig. 1 to 3. DESCRIPTION OF EMBODIMENTS OF THE INVENTION
  • the present invention relates to a method for communication MTH between a mobile device T and a secure element D of said mobile device T.
  • the mobile device T illustrated in Fig. 4 comprises :
  • the operating system OS is adapted to communicate with the secure element D and with the application APP.
  • an application refers to a set of one or more programs designed to carry out a set of operations sequences to perform specific tasks.
  • the mobile device T is a mobile phone.
  • the mobile device T is an AndroidTM device.
  • the mobile device T is a NFC ("Near Filed Communication") mobile device T or not.
  • the mobile device T comprises :
  • EF files a plurality of data files, which comprises some elementary files, referred as EF files. Said EF files are stored in said cache memory CM.
  • said EF files are:
  • ICCID file ("Integrated Circuit Card ID”) referred as ICCID_EF; - IMSI file ("International Mobile Subscriber Identity”) referred as ICCID_EF; - IMSI file ("International Mobile Subscriber Identity”) referred as ICCID_EF; - IMSI file ("International Mobile Subscriber Identity”) referred as ICCID_EF; - IMSI file ("International Mobile Subscriber Identity”) referred as ICCID_EF; - IMSI file ("International Mobile Subscriber Identity”) referred as
  • MSISDN_EF Mobile Station International Subscriber Directory Number »
  • ADN file (“Abbreviated Dialing Number”) referred as ADN_EF;
  • SMS_EF Short Message Service
  • the mobile device T comprises at least one first data file DAT_EF1 .
  • Said first data file DAT_EF1 is in a non-limitative embodiment an EF file.
  • said first data file DAT_EF1 will be used to receive a command C1 from said application APP or a result RS of the execution of said command C1 from said secure element D.
  • a secure element D is a secured component which may perform cryptographic functionalities and is adapted to store a secret data.
  • the secure element D is a smart card.
  • the smart card is a SIM card or an USIM card.
  • the secure element D is an eSE (embedded secure element), a micro-SD, an UICC.
  • eSE embedded secure element
  • micro-SD embedded secure element
  • UICC embedded secure element
  • communication is performed with the operating system OS of the mobile device T by means of APDU (Application Protocol Data Unit).
  • APDU Application Protocol Data Unit
  • said command C1 is an APDU command and said response RS is an APDU response.
  • said command C1 is an APDU command and said response RS is an APDU response.
  • other formats different from an APDU command/response may be used.
  • the secure element D comprises a plurality of files, which comprises also some elementary files EF.
  • the EF files in common are:
  • ICCID file ("Integrated Circuit Card ID”) referred as ICCID_EF
  • IMSI file International Mobile Subscriber Identity
  • IMSLEF International Mobile Subscriber Identity
  • MSISDN_EF Mobile Station International Subscriber Directory Number »
  • ADN file (“Abbreviated Dialing Number”) referred as ADN_EF;
  • SMS_EF Short Message Service
  • the secure element D comprises at least one first data file DAT_EF1 which corresponds to the first data file of the mobile device T.
  • Said first data file DAT_EF1 is in a non-limitative embodiment an EF file.
  • said first data file DAT_EF1 will be used to receive the command C1 from said mobile device T.
  • the secure element D comprises at least one second data file DAT_EF2, DAT_F2.
  • said second data file DAT_EF2, DAT_F2 will be used to save the result RS of the execution of said command C1 .
  • the secure element D further comprises a secret password PIN1 also referred as stored PIN1 .
  • said secret password is a short secret password, such as a PIN (Password Identification Number").
  • the secret password is a passphrase.
  • the short secret password will be taken in the following as a non- limitative example.
  • the method for communication MTH between the mobile device T and the secure element D will permit data exchange, such as a command C1 and a response RS, between the secure element D and the application APP, via the operating system OS.
  • the method for communication MTH permits to transfer some data from said secure element D to said application APP on the mobile device T by updating an element file EF.
  • said secure element D will send a proactive refresh command APDU_RES to said mobile device T, that is related to the updated element file EF. Then said mobile device T will read the element file EF and updates the image of said element file EF in the cache memory.
  • said proactive refresh command ADPU_RES is a proactive REFRESH ADPU command with a mode "file change notification".
  • APDU_RES a proactive REFRESH ADPU command with a mode "file change notification”.
  • other formats different from an APDU command may be used for such proactive refresh command APDU_RES.
  • This mode advises the mobile device T of the identity of the elementary file DAT_EF2 that has been changed (in structure and/or contents) in the secure element D.
  • This information may be used by the mobile device T if there is an image of said elementary file (e.g. the ADN file) in the mobile device's memory, to determine whether it needs to update this image, DAT_EF1 in this case.
  • a proactive command is used by the secure element D to instruct the mobile device T to do different tasks.
  • the secure element D notifies the mobile device T to read one of its elementary file DAT_EF2, DAT_F2 in order to update its corresponding elementary file DAT_EF1 .
  • the application APP is an application which permits an authentication of a user U of the mobile device D to a remote server (not illustrated) via said mobile device T. Thanks to this application APP, the user U enters a short secret password referred as PIN2 on the mobile device T. Said PIN2 is then verified by the secure element D. The result of the verification is then sent to the remote server.
  • the first data file DAT_EF1 of said mobile device T is an ADN file.
  • the method for communication MTH between the mobile device T and the secure element D is illustrated in Fig. 1 according to a first non- limitative embodiment, and in Fig. 2 and 3 according to a second non- limitative embodiment.
  • the USIM card will be taken in the following as a non-limitative example.
  • step 1) illustrated in Fig. 1 UPDT(T, DAT_EF1 , C1 , CM), said mobile device T updates its first data file DAT_EF1 with at least said one command C1 to be executed by said USIM card D.
  • the ADN file in the cache memory CM of said mobile device T is therefore updated with the verify short secret password command C1 , said command C1 comprising the PIN2 entered by the user U of the mobile phone T.
  • step 2) illustrated in Fig. 1 RQ_UPDT(DAT_EF1 , C1 ), said mobile device T requests said USIM card D to update its corresponding first data file DAT_EF1 with said at least one command C1 .
  • step 3) illustrated in Fig. 1 UPDT(D, DAT_EF1 , C1 ), said USIM card D updates its corresponding first data file DAT_EF1 with said at least one command C1 .
  • the ADN file of said USIM card D is updated with the verify short secret password command C1 , said verify short secret password command comprising the PIN2 entered by the user.
  • step 4) illustrated in Fig. 1 EXTRCT(D, C1 , DAT_EF1 ) said USIM card D extracts the at least one command C1 within the updated first data file DAT_EF1 .
  • the USIM card D extracts it from its ADN file.
  • step 5 illustrated in Fig. 1 EXEC(D, C1 ), said USIM card D executes the at least one command C1 .
  • the USIM card D executes the verify short secret password command: it checks if the short secret password PIN2 entered is equal to its own stored PIN1 .
  • the USIM card D If it is the case, the USIM card D generates a result RS which is "PIN correct", in the other case, the results RS is "PIN wrong". In a non-limitative example, the result RS equal to 1 when the short secret password PIN2 is correct, and equal to 0 when the short secret password PIN2 is wrong.
  • step 6) illustrated in Fig. 1 UPDT(D, RS, DAT_EF2), said USIM card D updates a second data file DAT_EF2 with said result RS of the execution of said at least one command C1 .
  • said second data file DAT_EF2 is an elementary file EF.
  • said second data file DAT_EF2 may be the same as the first data file DAT_EF1 which has been updated with the command C1 , here the ADN file, or may be another EF file, for example the SMS file.
  • these other EF files may be used as a second data file DAT_EF2 to store the result RS:
  • step 7 the USIM card D sends to said mobile device T a proactive refresh command ADPU_RES comprising the file identification ID2 of said second data file DAT EF2 to be read.
  • step 7') illustrated in Fig. 1 RX(T, D, APDU_RES) said mobile device T receives said proactive refresh command APDU_RES.
  • step 8) illustrated in Fig. 1 RD(T, RS, DAT_EF2), said mobile device T reads from said USIM card D the result RS from said second data file DAT_EF2. Hence, the mobile device T reads, in the ADN file of the USM card D, the result RS which is equal to 1 .
  • the mobile phone T is able to retrieve the data which has been updated in the USIM card (in particular in the ADN file in the given example), that is to say, here in non-limitative given example, the result RS.
  • step 9) illustrated in Fig. 1 UPDT(T, DAT_EF1 , RS, CM), said mobile device T re-updates its corresponding first data file DAT_EF1 with said result read RS.
  • step 10 said mobile device T gets the result RS of the execution of said at least one command C1 from said re-updated first data file DAT_EF1 .
  • the result RS that is to say the value 1 in the non-limitative given example, is read from the ADN file in the cache memory CM.
  • the application APP is adapted to launch (step 9' illustrated in Fig. 1 CALL_GT(RS) the getting by the mobile device T of the result RS of the execution of said at least one command C1 from said re- updated first data file DAT_EF1 .
  • step 11) illustrated in Fig. 1 TX(T, APP, RS) said mobile device T sends the result RS to the application APP which receives it in step 11 ') illustrated in Fig. 1 (RX(APP, T, RS).
  • the application APP when receiving this result RS which indicates that the short secret password PIN2 entered by the user U is correct, the application APP is able to sends a response to the remote server to acknowledge that the short secret password PIN2 is correct, in this case, and to display a message related to the result RS of the command executed for the user.
  • the application APP is thereafter closed.
  • a command C1 is transmitted via data files which are common to the mobile device T and the secure element D, and which are here standard EF files.
  • the result RS is transmitted via a data file which already exists in the secure element D, which is here a standard EF file.
  • first data file DAT_EF1 and the second data file DAT_EF2 which are standard EF files usually comprise a huge size (for example 250 records for an ADN file).
  • a data file such as ADN file or SMS file
  • the application APP may have to wait a long time for getting the data updated in the USIM card D, here the result RS.
  • the application APP will have to wait up to 23 seconds, which is too long.
  • a data file called ghost file
  • Said ghost data file referred as DAT_F2 comprises a structure which is smaller than a standard EF file. It comprises less records than the first data file DAT_EF1 .
  • the second data file which will be updated will be the ghost data file DAT_F2.
  • the USIM card D selects the ghost data file DAT_F2 as the second data file to be updated with the result RS, and update it as described in the step 6) in the first embodiment (step 6 illustrated in Fig. 2 UPDT(D, RS, DAT_F2)) .
  • a second data file which is either a standard EF file (in the first embodiment) or the ghost data file DAT_F2 (in these second embodiment) comprises a file identification, here ID2 for the standard EF file DAT_EF2, and ID2' for the ghost data file DAT_F2.
  • step 7) illustrated in Fig. 2 SWP(D, ID2, ID2', DAT_EF2, DAT_F2) the USIM card D switch (also called swap) the file identifications ID2, ID2' between the EF file DAT_EF2 and said second ghost data file DAT_F2.
  • the file identification ID2 of the standard ADN file will be associated with the ghost data file DAT_F2, and the file identification ID2' of the ghost data file DAT_F2 will be associated to the ADN file. It permits the mobile device T to read said ghost data file DAT_F2 instead of the standard ADN file.
  • the USIM card D send a proactive refresh command APDU_RES.
  • Said proactive refresh command APDU_RES comprises the file identification ID2 of said ADN file.
  • said mobile device T receives said proactive refresh command APDU_RES as illustrated in Fig. 2 RX(T, D, APDU_RES).
  • step 9 illustrated in Fig. 2 RD(T, RS, DAT_F2), the mobile device T will read the result RS from said ghost data file DAT_F2 thinking that it reads a standard EF file (as it is described in step 8) of the first embodiment).
  • the mobile device T only recognizes the file identification ID2 of the standard ADN file, it thinks that it reads its content while reading the content of the ghost data file DAT_F2. This is the reason why this smaller data file DAT_F2 is called ghost.
  • the steps 10, 10', 11 , 12 and 12' are respectively the same as the steps 9, 9', 10, 11 and 11 ' described in the first embodiment.
  • the application APP when receiving this result RS which indicates that the short secret password PIN2 entered by the user U is correct, the application APP is able to sends a response to the remote server to acknowledge that the short secret password PIN2 is correct, in this case, and to display a message related to the result RS of the command executed for the user.
  • a command C1 is transmitted via data files which are common to the mobile device T and the secure element D, and which are here standard EF files.
  • the result RS is transmitted via a data file which is smaller than a standard EF file.
  • some data here the command C1 and the result RS
  • some data may be transferred from the application APP to the secure element D of said mobile phone, and vice versa, without need of any dedicated or standard protocol communication between an APP and the secure element D. Only the protocol communication already used between the operating system OS of the mobile phone and its secure element D is used.
  • the previously file identification ID2 should be associated to the ADN file, which is not the case as it has been associated to the ghost data file DAT_F2, and the corresponding first data file DAT_EF1 of said mobile device T should contain the content of said ADN file, that is to say the abbreviated dialed numbers.
  • step 13 illustrated in Fig. 3 RQ_SWPB (T, D, ID2, ID2', DAT_EF2, DAT_F2)
  • the mobile device T requests the USIM card D to switch back the file identifications ID2, ID2'.
  • the mobile device T sends an APDU status command.
  • step 14 illustrated in Fig. 3 SWPB(D, ID2, ID2', DAT_EF2, DAT_F2), the USIM card D switch back the file identifications ID2, ID2' between the elementary file DAT_EF2 of said USIM card D corresponding to the first data file DAT_EF1 of said mobile device T and said second ghost data file DAT_F2.
  • the file identification ID2 is therefore again associated to the standard ADN file and the file identification ID2' to the ghost data file DAT_F2.
  • step 15) illustrated in Fig. 3 TX(D, T, APDU_RES) the USIM card D sends to the mobile device D a proactive refresh command APDU_RES with the file identification ID2 of the elementary file DAT_EF2 to be read.
  • the proactive refresh command APDU_RES comprises the file identification ID2 of the standard ADN file.
  • Said mobile device T receives said proactive refresh command APDU- RES in step 15') illustrated RX(T, D, APDU_RES).
  • the normal ADN file will be read by the mobile device T instead of the ghost data file DAT_F2.
  • step 16) illustrated in Fig. 3 RD(T, DAT2, DAT_F2), the mobile device T reads the data DAT2 from said elementary file DAT_EF2 of said USIM card D.
  • step 17) illustrated in Fig. 3 UPDT(T, DAT_EF1 , DAT2, CM), the mobile device T updates with the data read DAT2 the corresponding first data file DAT_EF1 in the cache memory CM.
  • the previously data which have been recorded in the cache memory CM that is to say the data of the ghost file DAT_F2 and in particular the result RS, are erased by the data of said elementary file, here by the ADN records.
  • the mobile device T receives a request RQ from a user U for reading some data DAT1 , for example a selected abbreviated dialed number, of said first data file DAT_EF1 , here of the ADN file in the cache memory CM, in step 19) illustrated in Fig. 3 GT(T, DAT_EF1 , DAT1 ), the mobile device T gets the requesting data DAT1 from said first data file DAT_EF1 , here, the requested abbreviated dialed number, and in step 20) illustrated in Fig. 3 DISP(T, DAT1 , DAT_EF1 ), the mobile device T displays said requested data DAT1 to said user, for example on a screen.
  • a request RQ from a user U for reading some data DAT1 , for example a selected abbreviated dialed number, of said first data file DAT_EF1 , here of the ADN file in the cache memory CM, in step 19) illustrated in Fig. 3 GT(T, DAT
  • the mobile device T is adapted to carry out a method MTH for performing a communication with its secure element D.
  • the mobile device T is illustrated in Fig. 4. It comprises said secure element D, the operating system OS and the application APP.
  • the mobile device T comprises at least one first data file DAT_EF1 in a cache memory CM and the secure element D comprises a corresponding first data file DAT_EF1 in its own memory.
  • Said memory is for example a non-volatile memory such as an EEPROM. It is to be noted that the same reference is used for the first data file DAT_EF1 in the mobile device T and the one in the secure element D, although they are different data files.
  • the operating system OS of said mobile device T is adapted to:
  • the secure element D of said mobile device T is adapted to:
  • the secure element D of said mobile device T is further adapted to:
  • the operating system OS of said mobile device T is further adapted to: request the switching back of said file identifications ID2, ID2' between said elementary file DAT_EF2 of said secure element D and said smaller data file DAT_F2 (function illustrated in Fig. 4 RQ_SWPB(T, ID2, ID2', DAT_EF2, DAT_F2));
  • the secure element D of said mobile device T is further adapted to send to said mobile device T a proactive refresh command APDU_RES comprising a file identification ID2 of said second data file DAT_EF2, DAT_F2 to be read (function illustrated in Fig. 4 TX(D, T, APDU_RES)), said operating system OS of said mobile device T being adapted to receive said proactive refresh command APDU_RES (function illustrated in Fig. 4 TX(T, D, APDU_RES)).
  • the operating system OS of said mobile device T is further adapted to
  • the application APP of said mobile device T is adapted to: a launch of the update by said mobile device T of said first data file DAT_EF1 of said mobile device T with at least one command C1 (function illustrated in Fig. 4 CALL_UPDT(DAT_EF1 ));
  • the non-limitative given example deals with the secure element D which may be used to provide an identity service as the secure element D stores the secret password PIN1 .
  • the secure element D may further store a user identification.
  • the secure element D may be used to provide email encryption/decryption for a mailbox on the mobile device T.
  • some embodiments of the invention may comprise one or a plurality of the following advantages:
  • the mobile device T after the power-on session of the mobile device T, the mobile device T is able to get the latest file content of the secure element D, if those files are updated in the secure element D, by the user of said mobile device for example ;

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

The present invention relates to a method for communication between a secure element (D) of a mobile device (T) and said mobile device (T), said secure element (D) comprising a first data file (DAT_EF1) and said mobile device (T) comprising a corresponding first data file (DAT_EF1). The method comprises: updating said first data file (DAT_EF1) of said mobile device (T) with a command (C1); requesting by said mobile device (T) to said secure element (D) to update the corresponding first data file (DAT_EF1) with said command (C1); extracting and executing by said secure element (D) the command (C1) within the updated first data file (DAT_EF1) of said secure element (D); updating by said secure element (D) a second data file (DAT_EF2, DAT_F2) with a result (RS) of the execution; re-updating by said mobile device (T) the corresponding first data file (DAT_EF1) of said mobile device (T) with the result.

Description

METHOD AND DEVICE FOR COMMUNICATION BETWEEN A MOBILE DEVICE AND A SECURE ELEMENT
TECHNICAL FIELD
The present invention relates to a method for communication between a mobile device and a secure element of said mobile device. The invention also relates to an associated mobile device.
BAC KG ROU N D OF TH E I NVENTION
A standard of communication such as the Open Mobile API standard
(referred as OMAPI) of the SIMAIIiance permits a mobile device to communicate with a secure element of said mobile device. Said secure element is for example a SIM ("Subscriber Identity Module") card or a USIM ("Universal Subscriber identity Module") card, said mobile device being a NFC ("Near Field Communication") mobile phone. The standard of communication permits in particular to send from said mobile phone some commands to said secure element and to receive by said mobile phone some responses from said secure element. One problem of this prior art is that this standard of communication is complex to implement and is only dedicated to NFC mobile devices.
S U MMARY O F TH E INVENTION
It is an object of the invention to provide a method for communication between a mobile device and a secure element of said mobile device which permits said mobile device to easily communicate with its secure element, and this for any type of mobile device, NFC or not.
To this end, there is provided a method for communication between a secure element of a mobile device and said mobile device, said secure element comprising at least a first data file and said mobile device comprising a corresponding first data file, wherein said method for communication comprises:
updating by said mobile device said first data file of said mobile device with at least one command to be executed by said secure element; requesting by said mobile device to said secure element to update the corresponding first data file of said secure element with said at least one command;
updating by said secure element the corresponding first data file of said secure element with said at least one command;
extracting by said secure element the at least one command within the updated first data file of said secure element;
executing by said secure element the at least one command; updating by said secure element a second data file with a result of the execution of said at least one command;
reading by said mobile device from said secure element the result from said second data file;
re-updating by said mobile device the corresponding first data file of said mobile device with the result read;
- getting by said mobile device the result of the execution of said at least one command from said re-updated first data file.
Hence, as will be described in detailed, one uses data files which are common to the mobile device and to the secure element to send a command from said mobile device to the secure element and to receive by said mobile device a response of the execution of said command from said secure element. It doesn't need any complex standard of communication. It may be applied to any type of mobile device. Moreover, the invention permits a mobile device to know when an update in a data file of said secure element takes place, and to update accordingly a data file in its own memory, which corresponds to the secure element's updated data file.
According to non-limitative embodiments of the invention, the method for communication in accordance with the invention further comprises the following characteristics.
In a non-limitative embodiment, the command to be executed by said secure element is an APDU command.
In a non-limitative embodiment, the first data file is an elementary file. In a non-limitative embodiment, the first data file and the second data file are:
an ADN file; or
- an SMS file; or
an ICCID file; or
an MSISDN file; or
an IMSI file. In a non-limitative embodiment, the second data file is a data file which is smaller than the first data file.
In a non-limitative embodiment, said method for communication further comprises switching by said secure element of the file identifications between an elementary file of said secure element and said smaller data file.
In a non-limitative embodiment, said method for communication further comprises:
switching back by said secure element of the file identifications between an elementary file of said secure element and said smaller data file;
reading by said mobile device from said secure element some data of said elementary file;
updating by said mobile device the first data file of said mobile device with the data read.
In a non-limitative embodiment, said method for communication further comprises:
receiving by said mobile device a request from a user for reading some data of said first data file;
- getting by said mobile device the requested data;
displaying by said mobile device said requested data.
In a non-limitative embodiment, said secure element is a SIM card, USIM card, an eSE, a micro-SD, an UICC, or an embedded UICC. In a non-limitative embodiment, said mobile device is a mobile phone.
In a non-limitative embodiment, said mobile device is an Android device.
In a non-limitative embodiment, in order to indicate the mobile device to read some data in a second data file of said secure element, said method communication further comprises sending by said secure element to said mobile device a proactive refresh command comprising a file identification of said second data file to be read.
In a non-limitative embodiment, said mobile device comprises an operating system which is adapted to perform the steps performed by said mobile device.
In a non-limitative embodiment, said mobile device further comprises an application and said method for communication further comprises:
a launch by said application of the update by said mobile device of said first data file of said mobile device with at least one command;
- a launch by said application of the getting by said mobile device of the result of the execution of said at least one command.
In addition, there is provided a mobile device for communicating with a secure element of said mobile device, said secure element comprising at least a first data file and said mobile device comprising a corresponding first data file, wherein said mobile device is adapted to:
update said first data file of said mobile device with at least one command to be executed by said secure element;
request to said secure element to update the corresponding first data file of said secure element with said at least one command;
update by said secure element the corresponding first data file of said secure element with said at least one command;
extract by said secure element the at least one command within the updated first data file of said secure element;
- execute by said secure element the at least one command; update by said secure element a second data file with a result of the execution of said at least one command;
read from said secure element the result from said second data file;
- re-update the corresponding first data file of said mobile device with the result read;
get the result of the execution of said at least one command from said re-updated first data file. BRIEF DESCRIPTION OF THE FIGURES
Some embodiments of methods and/or apparatus in accordance with embodiments of the present invention are now described, by way of example only, and with reference to the accompanying drawings, in which:
- Fig. 1 illustrates a schematic organization chart of a method for communication according to a first non-limitative embodiment of the invention;
- Fig. 2 illustrates a schematic organization chart of a method for communication according to a second non-limitative embodiment of the invention;
- Fig. 3 illustrates some further steps of the method for communication of Fig. 6;
- Fig. 4 illustrates a mobile device which is adapted to carry out the method for communication of Fig. 1 to 3. DESCRIPTION OF EMBODIMENTS OF THE INVENTION
In the following description, well-known functions or constructions by the man skilled in the art are not described in detail since they would obscure the invention in unnecessary detail. The present invention relates to a method for communication MTH between a mobile device T and a secure element D of said mobile device T.
The mobile device T illustrated in Fig. 4 comprises :
the secure element D;
- an operating system OS; and an application APP.
The operating system OS is adapted to communicate with the secure element D and with the application APP.
It is to be noted that an application refers to a set of one or more programs designed to carry out a set of operations sequences to perform specific tasks. In a non-limitative embodiment, the mobile device T is a mobile phone.
In a non-limitative embodiment, the mobile device T is an Android™ device.
In a non-limitative embodiment, the mobile device T is a NFC ("Near Filed Communication") mobile device T or not.
The mobile device T comprises :
a cache memory CM ;
a plurality of data files, which comprises some elementary files, referred as EF files. Said EF files are stored in said cache memory CM.
These EF files being well-known by the man skilled in the art, there are not described here.
In non-limitative examples, said EF files are:
ICCID file ("Integrated Circuit Card ID") referred as ICCID_EF; - IMSI file ("International Mobile Subscriber Identity") referred as
IMSLEF;
MSISDN file ("Mobile Station International Subscriber Directory Number ») referred as MSISDN_EF;
ADN file ("Abbreviated Dialing Number") referred as ADN_EF; and
SMS file ("Short Message Service") referred as SMS_EF.
The mobile device T comprises at least one first data file DAT_EF1 . Said first data file DAT_EF1 is in a non-limitative embodiment an EF file. As will be described hereinafter, said first data file DAT_EF1 will be used to receive a command C1 from said application APP or a result RS of the execution of said command C1 from said secure element D.
A secure element D is a secured component which may perform cryptographic functionalities and is adapted to store a secret data.
In a non-limitative embodiment, the secure element D is a smart card.
In non-limitative examples, the smart card is a SIM card or an USIM card.
In other non-limitative embodiments, the secure element D is an eSE (embedded secure element), a micro-SD, an UICC. In the non-limitative embodiment of the secure element D which is a smart card, communication is performed with the operating system OS of the mobile device T by means of APDU (Application Protocol Data Unit).
Hence, in a non-limitative embodiment, said command C1 is an APDU command and said response RS is an APDU response. Of course, other formats different from an APDU command/response (recognized by the secure element D and the application APP) may be used.
In a non-limitative embodiment, the secure element D comprises a plurality of files, which comprises also some elementary files EF.
Some of these EF files are common to the ones of said mobile device
T.
In non-limitative examples, the EF files in common are:
ICCID file ("Integrated Circuit Card ID") referred as ICCID_EF; IMSI file ("International Mobile Subscriber Identity") referred as IMSLEF;
MSISDN file ("Mobile Station International Subscriber Directory Number ») referred as MSISDN_EF;
ADN file ("Abbreviated Dialing Number") referred as ADN_EF; and
- SMS file ("Short Message Service") referred as SMS_EF.
The secure element D comprises at least one first data file DAT_EF1 which corresponds to the first data file of the mobile device T. Said first data file DAT_EF1 is in a non-limitative embodiment an EF file. As will be described hereinafter, said first data file DAT_EF1 will be used to receive the command C1 from said mobile device T. The secure element D comprises at least one second data file DAT_EF2, DAT_F2. As will be described hereinafter, said second data file DAT_EF2, DAT_F2 will be used to save the result RS of the execution of said command C1 .
In a non-limitative embodiment, the secure element D further comprises a secret password PIN1 also referred as stored PIN1 . In a non- limitative example, said secret password is a short secret password, such as a PIN (Password Identification Number"). In another non-limitative embodiment, the secret password is a passphrase.
The short secret password will be taken in the following as a non- limitative example. As will be described hereinafter, the method for communication MTH between the mobile device T and the secure element D will permit data exchange, such as a command C1 and a response RS, between the secure element D and the application APP, via the operating system OS. Moreover, the method for communication MTH permits to transfer some data from said secure element D to said application APP on the mobile device T by updating an element file EF. In order for said mobile device T to know that an element file EF of said secure element D has been updated, said secure element D will send a proactive refresh command APDU_RES to said mobile device T, that is related to the updated element file EF. Then said mobile device T will read the element file EF and updates the image of said element file EF in the cache memory.
In a non-limitative embodiment, said proactive refresh command ADPU_RES is a proactive REFRESH ADPU command with a mode "file change notification". Of course, other formats different from an APDU command may be used for such proactive refresh command APDU_RES.
This mode advises the mobile device T of the identity of the elementary file DAT_EF2 that has been changed (in structure and/or contents) in the secure element D. This information may be used by the mobile device T if there is an image of said elementary file (e.g. the ADN file) in the mobile device's memory, to determine whether it needs to update this image, DAT_EF1 in this case. It is to be noted that a proactive command is used by the secure element D to instruct the mobile device T to do different tasks. In the case of the proactive refresh command, the secure element D notifies the mobile device T to read one of its elementary file DAT_EF2, DAT_F2 in order to update its corresponding elementary file DAT_EF1 .
In a non-limitative example, the application APP is an application which permits an authentication of a user U of the mobile device D to a remote server (not illustrated) via said mobile device T. Thanks to this application APP, the user U enters a short secret password referred as PIN2 on the mobile device T. Said PIN2 is then verified by the secure element D. The result of the verification is then sent to the remote server.
In this case, the data exchanged between the application APP and the secure element D will be:
- a verify short secret password command C1 , which will be transferred from the application APP to the USIM card D, via the operating system OS of the mobile device T;
a result RS of the verification of said short secret password, which will be transferred from the USIM card D to the application APP, via the operating system OS of the mobile device T.
This non-limitative example of application APP will be taken in the following description. Furthermore, in a non-limitative example, the first data file DAT_EF1 of said mobile device T is an ADN file.
The method for communication MTH between the mobile device T and the secure element D is illustrated in Fig. 1 according to a first non- limitative embodiment, and in Fig. 2 and 3 according to a second non- limitative embodiment. The USIM card will be taken in the following as a non-limitative example.
These non-limitative embodiments are described hereinafter.
• Fir_sJ_embjDdiment
When the application APP for authenticating the user U to a remote server is open and launched (by the user of the mobile device D for example), said application APP launches (step 0 illustrated in Fig. 1 CALL_UPDT(DAT_EF1 )) the update of a first data file DAT_EF1 of said mobile device T with the command C1 to be executed.
Hence, in step 1) illustrated in Fig. 1 UPDT(T, DAT_EF1 , C1 , CM), said mobile device T updates its first data file DAT_EF1 with at least said one command C1 to be executed by said USIM card D.
In the non-limitative given example, the ADN file in the cache memory CM of said mobile device T is therefore updated with the verify short secret password command C1 , said command C1 comprising the PIN2 entered by the user U of the mobile phone T.
In step 2) illustrated in Fig. 1 RQ_UPDT(DAT_EF1 , C1 ), said mobile device T requests said USIM card D to update its corresponding first data file DAT_EF1 with said at least one command C1 .
Hence, it request the USIM card D to update its own ADN file with the verify short secret password command C1 .
In step 3) illustrated in Fig. 1 UPDT(D, DAT_EF1 , C1 ), said USIM card D updates its corresponding first data file DAT_EF1 with said at least one command C1 .
Hence, the ADN file of said USIM card D is updated with the verify short secret password command C1 , said verify short secret password command comprising the PIN2 entered by the user. In step 4) illustrated in Fig. 1 EXTRCT(D, C1 , DAT_EF1 ), said USIM card D extracts the at least one command C1 within the updated first data file DAT_EF1 .
In order to read the verify short secret password command C1 and therefore here the PIN2, the USIM card D extracts it from its ADN file.
In step 5) illustrated in Fig. 1 EXEC(D, C1 ), said USIM card D executes the at least one command C1 .
In the non-limitative given example, the USIM card D executes the verify short secret password command: it checks if the short secret password PIN2 entered is equal to its own stored PIN1 .
If it is the case, the USIM card D generates a result RS which is "PIN correct", in the other case, the results RS is "PIN wrong". In a non-limitative example, the result RS equal to 1 when the short secret password PIN2 is correct, and equal to 0 when the short secret password PIN2 is wrong.
In the given example, PIN2 is equal to PIN1 , and the result RS is = 1 .
In step 6) illustrated in Fig. 1 UPDT(D, RS, DAT_EF2), said USIM card D updates a second data file DAT_EF2 with said result RS of the execution of said at least one command C1 .
In a non-limitative embodiment, said second data file DAT_EF2 is an elementary file EF.
In a non-limitative embodiment, said second data file DAT_EF2 may be the same as the first data file DAT_EF1 which has been updated with the command C1 , here the ADN file, or may be another EF file, for example the SMS file.
In other non-limitative examples, these other EF files may be used as a second data file DAT_EF2 to store the result RS:
ICCID file ;
- IMSI file ;
MSISDN file.
Said mobile device T will then be able to read said result RS from said second data file DAT_EF2. It is to be noted that in order to make the mobile device T read some data from said second data file DAT_EF2 of said USIM card D, in step 7) illustrated in Fig. 1 TX(D, T, APDU_RES), the USIM card D sends to said mobile device T a proactive refresh command ADPU_RES comprising the file identification ID2 of said second data file DAT EF2 to be read.
In step 7') illustrated in Fig. 1 RX(T, D, APDU_RES), said mobile device T receives said proactive refresh command APDU_RES.
In step 8) illustrated in Fig. 1 RD(T, RS, DAT_EF2), said mobile device T reads from said USIM card D the result RS from said second data file DAT_EF2. Hence, the mobile device T reads, in the ADN file of the USM card D, the result RS which is equal to 1 .
Therefore, the mobile phone T is able to retrieve the data which has been updated in the USIM card (in particular in the ADN file in the given example), that is to say, here in non-limitative given example, the result RS.
In step 9) illustrated in Fig. 1 UPDT(T, DAT_EF1 , RS, CM), said mobile device T re-updates its corresponding first data file DAT_EF1 with said result read RS.
Hence it updates its own ADN file in the cache memory CM with the result RS equal to 1 .
In step 10) illustrated in Fig. 1 GT(T, DAT_EF1 , RS), said mobile device T gets the result RS of the execution of said at least one command C1 from said re-updated first data file DAT_EF1 .
Hence, the result RS that is to say the value 1 in the non-limitative given example, is read from the ADN file in the cache memory CM.
It is to be noted that the application APP is adapted to launch (step 9' illustrated in Fig. 1 CALL_GT(RS) the getting by the mobile device T of the result RS of the execution of said at least one command C1 from said re- updated first data file DAT_EF1 . In step 11) illustrated in Fig. 1 TX(T, APP, RS), said mobile device T sends the result RS to the application APP which receives it in step 11 ') illustrated in Fig. 1 (RX(APP, T, RS).
Hence, the result "PIN2 correct" is sent and received.
It is to be noted that all the steps above-described performed by the mobile device T, are performed by the operating system OS of said mobile device T.
Hence, when receiving this result RS which indicates that the short secret password PIN2 entered by the user U is correct, the application APP is able to sends a response to the remote server to acknowledge that the short secret password PIN2 is correct, in this case, and to display a message related to the result RS of the command executed for the user.
The application APP is thereafter closed.
Hence, thanks to this first embodiment, a command C1 is transmitted via data files which are common to the mobile device T and the secure element D, and which are here standard EF files. The result RS is transmitted via a data file which already exists in the secure element D, which is here a standard EF file.
It is to be noted that the first data file DAT_EF1 and the second data file DAT_EF2 which are standard EF files usually comprise a huge size (for example 250 records for an ADN file).
Hence, after receiving the proactive refresh command ADPU_RES, the reading of an EF file in the USIM card D and the updating of its cache memory CM will take a long time for the mobile device T to perform.
So, if an EF file such as ADN file or SMS file is used for the data exchange, the application APP may have to wait a long time for getting the data updated in the USIM card D, here the result RS. In a non-limitative embodiment, the application APP will have to wait up to 23 seconds, which is too long. Hence, as will be described in the second non-limitative embodiment illustrated in Fig. 2 and 3, a data file, called ghost file, may be used as a second data file for exchanging data between the USIM card D and the application APP. Said ghost data file referred as DAT_F2 comprises a structure which is smaller than a standard EF file. It comprises less records than the first data file DAT_EF1 . Hence, when the mobile device T will read said ghost data file DAT_F2, it will be quicker, because its file size is smaller.
• S_ej ond_enibj^^
The five first steps 1 to 5 above-described for the first embodiment are the same for said second embodiment.
As explained above, the second data file which will be updated will be the ghost data file DAT_F2.
Hence, instead of the second data file referred as DAT_EF2 (here, the standard ADN file) corresponding to the first data file DAT_EF1 of the mobile device T, the USIM card D selects the ghost data file DAT_F2 as the second data file to be updated with the result RS, and update it as described in the step 6) in the first embodiment (step 6 illustrated in Fig. 2 UPDT(D, RS, DAT_F2)) .
It is to be noted a second data file which is either a standard EF file (in the first embodiment) or the ghost data file DAT_F2 (in these second embodiment) comprises a file identification, here ID2 for the standard EF file DAT_EF2, and ID2' for the ghost data file DAT_F2.
In step 7) illustrated in Fig. 2 SWP(D, ID2, ID2', DAT_EF2, DAT_F2) the USIM card D switch (also called swap) the file identifications ID2, ID2' between the EF file DAT_EF2 and said second ghost data file DAT_F2.
Hence, in the non-limitative given example, the file identification ID2 of the standard ADN file will be associated with the ghost data file DAT_F2, and the file identification ID2' of the ghost data file DAT_F2 will be associated to the ADN file. It permits the mobile device T to read said ghost data file DAT_F2 instead of the standard ADN file.
Then, in order to make the mobile device T read some data from said ghost data file DAT_F2 of said USIM card D, in step 8) illustrated in Fig. 2 TX(D, T, APDU_RES), the USIM card D send a proactive refresh command APDU_RES. Said proactive refresh command APDU_RES comprises the file identification ID2 of said ADN file. In step 8'), said mobile device T receives said proactive refresh command APDU_RES as illustrated in Fig. 2 RX(T, D, APDU_RES).
Consequently, in step 9), illustrated in Fig. 2 RD(T, RS, DAT_F2), the mobile device T will read the result RS from said ghost data file DAT_F2 thinking that it reads a standard EF file (as it is described in step 8) of the first embodiment).
As, in the non-limitative given example, the mobile device T only recognizes the file identification ID2 of the standard ADN file, it thinks that it reads its content while reading the content of the ghost data file DAT_F2. This is the reason why this smaller data file DAT_F2 is called ghost.
As the file size of the ghost data file DAT_F2 is smaller than the one of the standard ADN file, the reading is faster. The steps 10, 10', 11 , 12 and 12' are respectively the same as the steps 9, 9', 10, 11 and 11 ' described in the first embodiment.
It is to be noted that all the steps above-described performed by the mobile device T, are performed by the operating system OS of said mobile device T.
Hence, as in the first embodiment, when receiving this result RS which indicates that the short secret password PIN2 entered by the user U is correct, the application APP is able to sends a response to the remote server to acknowledge that the short secret password PIN2 is correct, in this case, and to display a message related to the result RS of the command executed for the user.
The application APP is thereafter closed. Hence, thanks to this second embodiment, a command C1 is transmitted via data files which are common to the mobile device T and the secure element D, and which are here standard EF files. The result RS is transmitted via a data file which is smaller than a standard EF file.
Hence, thanks to this method for communication (first and second non-limitative embodiments), some data (here the command C1 and the result RS) may be transferred from the application APP to the secure element D of said mobile phone, and vice versa, without need of any dedicated or standard protocol communication between an APP and the secure element D. Only the protocol communication already used between the operating system OS of the mobile phone and its secure element D is used.
It is to be noted that if the user U of the mobile device T wants to get some data from the second data file, such as some abbreviated dialed numbers in the ADN file for example, the previously file identification ID2 should be associated to the ADN file, which is not the case as it has been associated to the ghost data file DAT_F2, and the corresponding first data file DAT_EF1 of said mobile device T should contain the content of said ADN file, that is to say the abbreviated dialed numbers.
Therefore, after the application APP is closed, in step 13) illustrated in Fig. 3 RQ_SWPB (T, D, ID2, ID2', DAT_EF2, DAT_F2), the mobile device T requests the USIM card D to switch back the file identifications ID2, ID2'. In a non-limitative embodiment, for said request, the mobile device T sends an APDU status command.
In step 14), illustrated in Fig. 3 SWPB(D, ID2, ID2', DAT_EF2, DAT_F2), the USIM card D switch back the file identifications ID2, ID2' between the elementary file DAT_EF2 of said USIM card D corresponding to the first data file DAT_EF1 of said mobile device T and said second ghost data file DAT_F2.
The file identification ID2 is therefore again associated to the standard ADN file and the file identification ID2' to the ghost data file DAT_F2.
In step 15) illustrated in Fig. 3 TX(D, T, APDU_RES), the USIM card D sends to the mobile device D a proactive refresh command APDU_RES with the file identification ID2 of the elementary file DAT_EF2 to be read.
Hence, in the non-limitative given example, the proactive refresh command APDU_RES comprises the file identification ID2 of the standard ADN file.
Said mobile device T receives said proactive refresh command APDU- RES in step 15') illustrated RX(T, D, APDU_RES).
The normal ADN file will be read by the mobile device T instead of the ghost data file DAT_F2.
In step 16) illustrated in Fig. 3 RD(T, DAT2, DAT_F2), the mobile device T reads the data DAT2 from said elementary file DAT_EF2 of said USIM card D.
In the non-limitative given example, it reads the records of the ADN file, which are the abbreviated dialed numbers which are recorded in the USIM card D.
In step 17) illustrated in Fig. 3 UPDT(T, DAT_EF1 , DAT2, CM), the mobile device T updates with the data read DAT2 the corresponding first data file DAT_EF1 in the cache memory CM. Hence, the previously data which have been recorded in the cache memory CM, that is to say the data of the ghost file DAT_F2 and in particular the result RS, are erased by the data of said elementary file, here by the ADN records. Hence, later, when in step 18) illustrated in Fig. 3 RX(T, U, RQ, DAT1 , DAT_EF1 ), the mobile device T receives a request RQ from a user U for reading some data DAT1 , for example a selected abbreviated dialed number, of said first data file DAT_EF1 , here of the ADN file in the cache memory CM, in step 19) illustrated in Fig. 3 GT(T, DAT_EF1 , DAT1 ), the mobile device T gets the requesting data DAT1 from said first data file DAT_EF1 , here, the requested abbreviated dialed number, and in step 20) illustrated in Fig. 3 DISP(T, DAT1 , DAT_EF1 ), the mobile device T displays said requested data DAT1 to said user, for example on a screen.
Hence, the mobile device T is adapted to carry out a method MTH for performing a communication with its secure element D. The mobile device T is illustrated in Fig. 4. It comprises said secure element D, the operating system OS and the application APP.
As above-described, the mobile device T comprises at least one first data file DAT_EF1 in a cache memory CM and the secure element D comprises a corresponding first data file DAT_EF1 in its own memory. Said memory is for example a non-volatile memory such as an EEPROM. It is to be noted that the same reference is used for the first data file DAT_EF1 in the mobile device T and the one in the secure element D, although they are different data files.
The operating system OS of said mobile device T is adapted to:
- update said first data file DAT_EF1 with at least one command
C1 to be executed by said secure element D (function illustrated in Fig. 4 UPDT(T, DAT_EF1 , C1 , CM));
request to said secure element D to update the corresponding first data file DAT_EF1 of said secure element D with said at least one command C1 (function illustrated in Fig. 4 RQ_APDT(DAT_EF1 , C1 ));
read from said secure element D the result RS from said second data file DAT_EF2, DAT_F2 (function illustrated in Fig. 4 RD(T, RS, DAT_EF2)); re-update the corresponding first data file DAT_EF1 of said mobile device T with the result read RS (function illustrated in Fig. 4 UPDT(T, DAT_EF1 , RS, CM));
get the result RS of the execution of said at least one command C1 from said re-updated first data file DAT_EF1 (function illustrated in Fig. 4 GT(T, DAT_EF1 , RS));
transmit to said application APP the results RS of the execution of aid command C1 ((function illustrated in Fig. 4 TX(T, APP, RS)). The secure element D of said mobile device T is adapted to:
update the corresponding first data file DAT_EF1 of said secure element D with said at least one command C1 (function illustrated in Fig. 4 UPDT(D, DAT_EF1 , C1 );
extract the at least one command C1 within the updated first data file DAT_EF1 of said secure element D (function illustrated in Fig. 4 EXTRCT(D, C1 , DAT_EF1 ));
execute the at least one command C1 (function illustrated in Fig. 4 EXEC(D, C1 ));
update a second data file DAT_EF2, DAT_F2 with a result RS of the execution of said at least one command ADPU_C1 (function illustrated in Fig. 4 UPDT(D, RS, DAT_EF2)).
When a smaller data file DAT_F2 (called ghost data file) is used as the second data file, in a non-limitative embodiment, the secure element D of said mobile device T is further adapted to:
switch the file identifications ID2, ID2' between an elementary file DAT_EF2 of said secure element D and said smaller data file DAT_F2 (function illustrated in Fig. 4 SWP(D, ID2, ID2', DAT_EF2, DAT_F2));
switch back the file identifications ID2, ID2' between an elementary file DAT_EF2 of said secure element D and said smaller data file DAT_F2 (function illustrated in Fig. 4 SWP(D, ID2, ID2', DAT_EF2, DAT_F2)).
In this case, in a non-limitative embodiment, the operating system OS of said mobile device T is further adapted to: request the switching back of said file identifications ID2, ID2' between said elementary file DAT_EF2 of said secure element D and said smaller data file DAT_F2 (function illustrated in Fig. 4 RQ_SWPB(T, ID2, ID2', DAT_EF2, DAT_F2));
- read from said secure element D some data DAT2 of said elementary file DAT_EF2 (which is the ghost data file) (function illustrated in Fig. 4 RD(T, DAT2, DAT_F2);
update the first data file DAT_EF1 of said mobile device T with the data read DAT2 (function illustrated in Fig. 4 UPDT(T, DAT_EF1 , DAT2, CM)).
In a non-limitative embodiment, in order to indicate the mobile device T to read some data DAT2, RS in a second data file DAT_EF2, DAT_F2 of said secure element D, the secure element D of said mobile device T is further adapted to send to said mobile device T a proactive refresh command APDU_RES comprising a file identification ID2 of said second data file DAT_EF2, DAT_F2 to be read (function illustrated in Fig. 4 TX(D, T, APDU_RES)), said operating system OS of said mobile device T being adapted to receive said proactive refresh command APDU_RES (function illustrated in Fig. 4 TX(T, D, APDU_RES)).
In a non-limitative embodiment, the operating system OS of said mobile device T is further adapted to
receive a request RQ from a user U for reading some data DAT1 of said first data file DAT_EF1 (function illustrated in Fig. 4 RX(T, U, RQ, DAT1 , DAT_EF1 ));
get the requested data DAT1 (function illustrated in Fig. 4 GT(T, DAT_EF1 , DAT1 ) );
display said requested data DAT1 (function illustrated in Fig. 4 DISP(T, DAT1 , DAT_EF1 )).
In a non-limitative embodiment, the application APP of said mobile device T is adapted to: a launch of the update by said mobile device T of said first data file DAT_EF1 of said mobile device T with at least one command C1 (function illustrated in Fig. 4 CALL_UPDT(DAT_EF1 ));
a launch of the getting by said mobile device T of the result RS of the execution of said at least one command C1 (function illustrated in Fig. 4 CALL_GT(RS));
receive from the mobile device T the results RS of the execution of aid command C1 ((function illustrated in Fig. 4 RX(APP, T, RS)). It is to be understood that the present invention is not limited to the aforementioned embodiments.
The non-limitative given example deals with the secure element D which may be used to provide an identity service as the secure element D stores the secret password PIN1 . In a non-limitative embodiment, the secure element D may further store a user identification.
In another non-limitative embodiment, the secure element D may be used to provide email encryption/decryption for a mailbox on the mobile device T. Hence, some embodiments of the invention may comprise one or a plurality of the following advantages:
it permits to send some commands from the mobile device T to the secure element D and to receive by said mobile device T a response from said mobile device T without a complex standard of communication;
- it permits a secure element D to transfer data to an application
APP of said mobile device T;
it permits a mobile data T to know that an elementary file of said secure element D has been updated and to recover the data updated and to update the image of said updated elementary file in its own memory ;
- it uses only standard data files which are common to the mobile device T and to the secure element D to transmit/receive the command
C1 /result RS;
thanks to the ghost file, it permits to decrease the time for:
reading the result RS of the execution of the command C1 by the mobile device T; updating the first data file DAT_EF in the cache memory CM by the mobile device T.
it therefore permits to decrease the time of the response displayed to the user or sent by the application APP to a remote server ;
- it provides a simple solution to exchange data between a secure element D of a mobile device T and an application APP of said mobile device T and this for any kind of mobile devices T, which are NFC ("Near Filed Communication") or not;
after the power-on session of the mobile device T, the mobile device T is able to get the latest file content of the secure element D, if those files are updated in the secure element D, by the user of said mobile device for example ;
it avoids adding a supplementary implementation layer in the secure element D and in the mobile device T as it is the case when using a standard of communication such as the SIMAIIiance's standard.

Claims

1 - Method for communication (MTH) between a secure element (D) of a mobile device (T) and said mobile device (T), said secure element (D) comprising at least a first data file (DAT_EF1 ) and said mobile device (T) comprising a corresponding first data file (DAT_EF1 ), wherein said method for communication (MTH) comprises :
updating by said mobile device (T) said first data file (DAT_EF1 ) of said mobile device (T) with at least one command (C1 ) to be executed by said secure element (D);
requesting by said mobile device (T) to said secure element (D) to update the corresponding first data file (DAT_EF1 ) of said secure element (D) with said at least one command (C1 );
updating by said secure element (D) the corresponding first data file (DAT_EF1 ) of said secure element (D) with said at least one command (C1 );
extracting by said secure element (D) the at least one command (C1 ) within the updated first data file (DAT_EF1 ) of said secure element (D);
- executing by said secure element (D) the at least one command (C1 );
updating by said secure element (D) a second data file (DAT_EF2, DAT_F2) with a result (RS) of the execution of said at least one command (ADPU_C1 );
- reading by said mobile device (T) from said secure element (D) the result (RS) from said second data file (DAT_EF2, DAT_F2);
re-updating by said mobile device (T) the corresponding first data file (DAT_EF1 ) of said mobile device (T) with the result read (RS);
getting by said mobile device (T) the result (RS) of the execution of said at least one command (C1 ) from said re-updated first data file (DAT_EF1 ).
2- Method for communication (MTH) according to claim 1 , wherein the command (C1 ) to be executed by said secure element (D) is an APDU command. 3- Method for communication (MTH) according to claim 1 or claim 2, wherein the first data file (DAT_EF1 ) is an elementary file (EF). 4- Method for communication (MTH) according to any one of the previous claims 1 to 3, wherein the first data file (DAT_EF1 ) and the second data file (DAT_EF2) are:
an ADN file; or
an SMS file; or
- an ICCID file; or
an MSISDN file; or
an IMSI file.
5- Method for communication (MTH) according to any one of the previous claims 1 to 4, wherein the second data file (DAT_F2) is a data file which is smaller than the first data file (DAT_EF1 ).
6- Method for communication (MTH) according to the previous claim 5, wherein said method for communication (MTH) further comprises switching by said secure element (D) of the file identifications (ID2, ID2') between an elementary file (DAT_EF2) of said secure element (D) and said smaller data file (DAT_F2).
7- Method for communication (MTH) according to claim 6, wherein said method for communication (MTH) further comprises:
switching back by said secure element (D) of the file identifications (ID2, ID2') between an elementary file (DAT_EF2) of said secure element (D) and said smaller data file (DAT_F2);
reading by said mobile device (T) from said secure element (D) some data (DAT2) of said elementary file (DAT_F2);
updating by said mobile device (T) the first data file (DAT_EF1 ) of said mobile device (T) with the data read (DAT2). 8- Method for communication (MTH) according to any one of the previous claims 1 to 7, wherein said method for communication (MTH) further comprises:
receiving by said mobile device (T) a request (RQ) from a user (U) for reading some data (DAT1 ) of said first data file (DAT_EF1 );
getting by said mobile device (T) the requested data (DAT1 ); displaying by said mobile device (T) said requested data
(DAT1 ). 9- Method for communication (MTH) according to any one of the previous claims 1 to 8, wherein said secure element is a SIM card, USIM card, an eSE, a micro-SD, an UICC, or an embedded UICC.
10- Method for communication (MTH) according to any one of the previous claims 1 to 9, wherein said mobile device (T) is a mobile phone.
1 1 - Method for communication (MTH) according to any one of the previous claims 1 to 10, wherein said mobile device (T) is an Android™ device.
12- Method for communication (MTH) according to any one of the previous claims 1 to 1 1 , wherein in order to indicate the mobile device (T) to read some data (DAT2, RS) in a second data file (DAT_EF2, DAT_F2) of said secure element (D), said method communication (MTH) further comprises sending by said secure element (D) to said mobile device (T) a proactive refresh command (APDU_RES) comprising a file identification (ID2) of said second data file (DAT_EF2, DAT_F2) to be read. 13- Method for communication (MTH) according to any one of the previous claims 1 to 12, wherein said mobile device (T) comprises an operating system (OS) which is adapted to perform the steps performed by said mobile device (T). 14- Method for communication (MTH) according to any one of the previous claims 1 to 12, wherein said mobile device (T) further comprises an application (APP) and said method for communication (MTH) further comprises:
- a launch by said application (APP) of the update by said mobile device (T) of said first data file (DAT_EF1 ) of said mobile device (T) with at least one command (C1 );
a launch by said application (APP) of the getting by said mobile device (T) of the result (RS) of the execution of said at least one command (C1 ).
15- Mobile device (T) for communicating with a secure element (D) of said mobile device (T), said secure element (D) comprising at least a first data file (DAT_EF1 ) and said mobile device (T) comprising a corresponding first data file (DAT_EF1 ), wherein said mobile device (T) is adapted to:
update said first data file (DAT_EF1 ) of said mobile device (T) with at least one command (C1 ) to be executed by said secure element (D);
request to said secure element (D) to update the corresponding first data file (DAT_EF1 ) of said secure element (D) with said at least one command (C1 );
update by said secure element (D) the corresponding first data file (DAT_EF1 ) of said secure element (D) with said at least one command (C1 );
- extract by said secure element (D) the at least one command
(C1 ) within the updated first data file (DAT_EF1 ) of said secure element (D);
execute by said secure element (D) the at least one command
(C1 );
update by said secure element (D) a second data file (DAT_EF2, DAT_F2) with a result (RS) of the execution of said at least one command (ADPU_C1 );
read from said secure element (D) the result (RS) from said second data file (DAT_EF2, DAT_F2);
re-update the corresponding first data file (DAT_EF1 ) of said mobile device (T) with the result read (RS); get the result (RS) of the execution of said at least one command (C1 ) from said re-updated first data file (DAT_EF1 ).
PCT/EP2016/068451 2016-03-29 2016-08-02 Method and device for communication between a mobile device and a secure element Ceased WO2017167408A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610186686.7A CN107241710A (en) 2016-03-29 2016-03-29 Communication means between the safety element of mobile device and the mobile device
CN201610186686.7 2016-03-29

Publications (1)

Publication Number Publication Date
WO2017167408A1 true WO2017167408A1 (en) 2017-10-05

Family

ID=56611256

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/068451 Ceased WO2017167408A1 (en) 2016-03-29 2016-08-02 Method and device for communication between a mobile device and a secure element

Country Status (2)

Country Link
CN (1) CN107241710A (en)
WO (1) WO2017167408A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114982212B (en) * 2020-01-19 2024-12-13 高通股份有限公司 Universal Integrated Circuit Card (UICC) Phonebook Access

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1965596A1 (en) * 2007-02-27 2008-09-03 Gemplus A personal token having enhanced communication abilities for a hosted application
US20140165170A1 (en) * 2012-12-10 2014-06-12 Rawllin International Inc. Client side mobile authentication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1965596A1 (en) * 2007-02-27 2008-09-03 Gemplus A personal token having enhanced communication abilities for a hosted application
US20140165170A1 (en) * 2012-12-10 2014-06-12 Rawllin International Inc. Client side mobile authentication

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Smart Cards; Card Application Toolkit (CAT) (Release 13)", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. SCP TEC, no. V13.0.0, March 2015 (2015-03-01), XP014248245 *
"Smart Cards; UICC-Terminal interface; Physical and logical characteristics (Release 11)", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. SCP TEC, no. V11.1.0, November 2013 (2013-11-01), XP014180137 *

Also Published As

Publication number Publication date
CN107241710A (en) 2017-10-10

Similar Documents

Publication Publication Date Title
JP6871374B2 (en) Profile download method and device
KR102082854B1 (en) Methods, servers, and systems for downloading updated profiles
EP3171622B1 (en) Method and device for installing profile of euicc
US9723549B2 (en) Communication control apparatus, authentication device, central control apparatus and communication system
EP3001713B1 (en) Method, apparatus and system for distributing virtual subscriber identity module data
US20190098000A1 (en) Method and apparatus of constructing secure infra-structure for using embedded universal integrated circuit card
JP6401280B2 (en) Method and apparatus for accessing services
US20130165073A1 (en) Method and apparatus for emulating a plurality of subscriptions
CN104902463A (en) Mobile terminal, multi-card management method for virtual card terminal thereof, and server
EP3155552B1 (en) Mechanisms for controlling tag personalization
EP2876592A1 (en) Method to operate a contactless mobile device as a low cost secured point-of-sale
US20230336970A1 (en) Electronic device performing verification using embedded sim and operating method therefor
EP2727384B1 (en) Method for accessing at least one service and corresponding system
WO2016165444A1 (en) System and method for migrating virtual subscriber identity module (sim) card
GB2524646A (en) Communication apparatus, information processing apparatus, and control method for the same
EP3486827B1 (en) "window-of-time" encryption session key transference
US9332374B2 (en) Communication interface method for SE equipped on mobile terminal and SE using the same
CN107241710A (en) Communication means between the safety element of mobile device and the mobile device
CN105260667A (en) Mobile terminal information confidential method and mobile terminal
CN121126477A (en) Near-field communication routing methods, devices, storage media and electronic equipment
EP2890164A1 (en) Method for accessing a service, corresponding device and system
KR20170044126A (en) Method for consulting the status of a resource of an electronic device, associated electronic entity and electronic device provided with such an electronic entity
JP2014010542A (en) Information terminal and program
KR20150120116A (en) Smart device and method for saving application data using secure element
KR20140054979A (en) System for managing finance micro sd

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16748109

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16748109

Country of ref document: EP

Kind code of ref document: A1