EP3842976A1 - Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité - Google Patents

Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité Download PDF

Info

Publication number
EP3842976A1
EP3842976A1 EP19306767.5A EP19306767A EP3842976A1 EP 3842976 A1 EP3842976 A1 EP 3842976A1 EP 19306767 A EP19306767 A EP 19306767A EP 3842976 A1 EP3842976 A1 EP 3842976A1
Authority
EP
European Patent Office
Prior art keywords
chip
data
data sequence
received
cryptogram
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.)
Withdrawn
Application number
EP19306767.5A
Other languages
German (de)
English (en)
Inventor
Naveed Ahmed
Sandeep Kumar KORI
Jean-Roch Coulon
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
Thales DIS France 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 Thales DIS France SA filed Critical Thales DIS France SA
Priority to EP19306767.5A priority Critical patent/EP3842976A1/fr
Priority to PCT/EP2020/076940 priority patent/WO2021129961A1/fr
Publication of EP3842976A1 publication Critical patent/EP3842976A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/72—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 in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/81—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer by operating on the power supply, e.g. enabling or disabling power-on, sleep or resume operations

Definitions

  • the invention relates generally to a method for securely accessing at least one feature of a chip.
  • the chip may be included in a Secure Element (or SE).
  • SE Secure Element
  • an SE is a smart object that includes a chip(s) that protect(s), as a tamper resistant component(s), access to stored data and that is intended to communicate data with an external device(s), like e.g., an SE host device, such as a mobile (tele)phone or a Personal Computer (or PC).
  • an SE host device such as a mobile (tele)phone or a Personal Computer (or PC).
  • the SE chip as a chip incorporated in an SE host device, includes notably an embedded SE (or eSE), an embedded Universal Integrated Circuit Card (or eUICC), an embedded Subscriber Identity Module (or eSIM) and a Trusted Execution Environment (or TEE), as a secure area of a (SE host device) processor and a secured runtime environment, within the SE host device.
  • eSE embedded SE
  • eUICC embedded Universal Integrated Circuit Card
  • eSIM embedded Subscriber Identity Module
  • TEE Trusted Execution Environment
  • the SE host device may include a mobile (tele)phone, a Personal Computer (or PC), a user terminal, a terminal, a Hardware Security Module (or HSM) type device and a server.
  • a mobile (tele)phone may include a mobile (tele)phone, a Personal Computer (or PC), a user terminal, a terminal, a Hardware Security Module (or HSM) type device and a server.
  • HSM Hardware Security Module
  • the invention also pertains to a corresponding system for securely accessing at least one feature of a chip.
  • WO 2019120991 A1 describes a technique, based on an operating voltage modulation scheme, to communicate, to a chip, a predefined pattern that allows, when detected by the chip, activating a chip feature.
  • the invention proposes a solution for satisfying the just herein above specified need by providing a method for securely accessing at least one feature of a chip.
  • the method comprises:
  • the principle of the invention consists in performing, by a device, one or several first predefined cryptographic operations, onto a data sequence, and transmitting, to a chip, the resulting secure data sequence or cryptogram.
  • the chip detects, in data received from or in the chip, a presence of a predefined trigger signal.
  • the trigger signal allows the chip to know that the chip has received the cryptogram.
  • the chip triggers an execution of one or several second predefined cryptographic operations onto the received cryptogram.
  • the chip therefore executes one or several second cryptographic operations onto the received cryptogram and gets the received data sequence.
  • the chip checks whether the received data sequence does or does not include a predefined pattern. And, only in the affirmative, the chip authorizes the device to access a chip feature(s). In other words, the device thus establishes a secure communication link to a chip feature(s).
  • the device firstly processes a data sequence by carrying out the first cryptographic operation(s), such as a data encryption and/or a data signature, onto the data sequence.
  • first cryptographic operation(s) such as a data encryption and/or a data signature
  • the device transmits, to the chip, the resulting secure data sequence or cryptogram, as encrypted data and/or signed data.
  • the chip receives, indirectly caused by or directly from the device, a predefined trigger signal.
  • the chip can determine, based on the received cryptogram, a corresponding original data sequence by launching an execution of a data signature verification and/or a data decryption, as the second cryptographic operation(s).
  • the chip identifies, within the data sequence, a predefined pattern.
  • the chip authorizes the device to access, i.e. read from and/or write into, one or several chip features.
  • the chip feature(s) may include one or several HardWare (or HW) features, like e.g., a particular chip memory(ies), and/or one or several SoftWare (or SW) features, such as an Operating System (or OS).
  • HW HardWare
  • SW SoftWare
  • the invention solution is more secure than the aforementioned solution since a data sequence to be transmitted by the device has undergone one or several first cryptographic operations that allow securing a further data sequence processing.
  • the invention solution is secure at the chip side, since an attacker has further to know that a trigger signal is to be firstly identified prior to carrying out one or several second cryptographic operations to retrieve the corresponding received data sequence.
  • the invention solution thus provides security to access one or several chip features.
  • the invention solution may provide several protection levels, such as e.g., an authorization of the pattern, a confidentiality of the pattern, an authentication of the device that has sent the pattern, an anti-cloning solution and/or an anti-replay solution.
  • protection levels such as e.g., an authorization of the pattern, a confidentiality of the pattern, an authentication of the device that has sent the pattern, an anti-cloning solution and/or an anti-replay solution.
  • the invention solution may allow notably:
  • the invention is a system for securely accessing at least one feature of a chip.
  • the system includes a device and the chip that is connected to the device.
  • the device is configured to:
  • the device includes, among other computing devices, a terminal, a mobile phone, a PC, an HSM type device, a (local or remote) server, a laptop and a user terminal.
  • the invention method for securely accessing at least one feature of an eUICC is implemented by, locally at the eUICC side, a phone and the eUICC.
  • the phone as a device, cooperates with the eUICC, as the chip, so as to improve the security to access, from the device, a chip feature(s).
  • the invention method for securely accessing at least one feature of a chip is implemented by a remote server, through a chip host entity (like e.g., a phone), and the chip.
  • a chip host entity like e.g., a phone
  • the server as a device, carries out the functions that are described infra and that are carried out by the phone.
  • the invention does not impose any constraint as to a kind of the SE type that includes the chip.
  • FIG. 1 shows schematically a TE 10, as a system, that includes a phone 12 and an eUICC 14.
  • the phone 12 and the eUICC 14 may both belong to a subscriber to a wireless service(s).
  • the phone 12 and the eUICC 14 are adapted to implement, according to the invention, a method for securely accessing one or several features of the eUICC 14.
  • the phone 12 hosts the eUICC 14, as a chip.
  • the device may include a server, an HSM type device, a user terminal, a terminal, a PC, a desktop computer, a tablet, a laptop (computer), a media-player, a game console, a netbook, a smart watch, a smart jewel (or jewelry), a headset, a handset, a Personal Digital Assistance (or PDA), a machine in a Machine-to-Machine (or M2M), an Internet of Thing (or loT), any stationary or mobile (electronic) device and/or another chip.
  • the device may include any other computing device that includes means for processing data, means for exchanging data with outside and that includes and/or is connected to means for storing data.
  • the phone 12 includes one or several (micro)processors (and/or a (micro)controller(s)), as data processing means (not represented), one or several memories, as data storing means, and several Input/Output (or I/O) interfaces that are internally all connected, through an internal bidirectional data bus.
  • microprocessors and/or a (micro)controller(s)
  • memories as data storing means
  • I/O Input/Output
  • the phone I/O interfaces include or are connected to a ContacT (or CT) interface(s), to exchange, over a CT link(s) 13, with the eUICC 14, as an internal interlocutor entity.
  • CT link(s) 13 is(are) at least mono-directional, i.e. from the device to the chip, and is preferably bi-directional.
  • the phone I/O interfaces includes at least one output interface.
  • the output interface corresponds to an input interface that is described in relation with figure 2 .
  • the output interface includes at least two power pins that allow sending data through an operating voltage modulation.
  • the phone I/O interfaces may include or be connected to means for interfacing with a user, such as a Man Machine Interface (or MMI).
  • MMI Man Machine Interface
  • the phone 12 may include a keyboard 122, a display screen 124, a loudspeaker(s) (not represented), a microphone(s) (not represented), a camera(s) (not represented) and/or (an)other interface(s), as an internal MMI.
  • the phone 12 MMI allows a user(s) to interact with the phone 12.
  • the phone 12 MMI may be used for presenting information to its user, like e.g., a message(s) for prompting the user to enter or provide user authentication data, such as "Please enter your password", "Please enter your PIN” and/or "Please enter your biometric data”.
  • the phone 12 MMI may be used for getting data entered or provided by the concerned user, such as user authentication data, like e.g., a password, a Personal Identification Number (or PIN) and/or user biometric data (like e.g., a fingerprint(s), a facial print(s), a voice print(s) and/or an iris print(s)).
  • user authentication data like e.g., a password, a Personal Identification Number (or PIN) and/or user biometric data (like e.g., a fingerprint(s), a facial print(s), a voice print(s) and/or an iris print(s)).
  • the phone 12 MMI may be used for inputting data to be stored in or through the phone 12, and/or for outputting data, such as data read from the phone 12, that may be securely stored in either the phone 12 or an entity(ies) cooperating with the phone 12, such as an SE chip, like e.g., the eUICC 14.
  • the phone I/O interfaces may include or be connected to are connected to an antenna 126.
  • the antenna 126 allows exchanging data, through a Long Range (or LR) RadioFrequency (or RF) link(s), as a wireless link(s), via a communication network(s) (not represented), with an external interlocutor(s), such as (an)other phone(s) or a remote server(s) (not represented).
  • LR Long Range
  • RF RadioFrequency
  • the LR RF may be fixed at several hundreds of MHz, e.g., around 850, 900, 1800, 1900 and/or 2100 MHz, as an LR type RF(s).
  • the communication network(s) may include a mobile radio-communication network(s), like e.g., a Global System for Mobile Communications (or GSM), a General Packet Radio Service (or GPRS), a Universal Mobile Telecommunications System (or UMTS), an EDGE (acronym for "Enhanced Data rates for GSM Evolution"), a Code Division Multiple Access (or CDMA) and/or a Long Term Evolution (or LTE) type network(s).
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • UMTS Universal Mobile Telecommunications System
  • EDGE acronym for "Enhanced Data rates for GSM Evolution”
  • CDMA Code Division Multiple Access
  • LTE Long Term Evolution
  • the communication network(s) may include a WLAN (acronym for "Wireless Local Area Network”), an Internet and/or an Intranet type network(s).
  • a communication network(s) may be accessed, from the phone 12, through a Short Range (or SR) radio-communication link(s), like e.g., a Bluetooth (or BTH), a Bluetooth Low Energy (or BLE), a Wi-Fi, a ZigBee, a Near Field Communication (or NFC) type link(s), as a ContacT-Less (or CTL) link(s).
  • a Short Range (or SR) radio-communication link(s) like e.g., a Bluetooth (or BTH), a Bluetooth Low Energy (or BLE), a Wi-Fi, a ZigBee, a Near Field Communication (or NFC) type link(s), as a ContacT-Less (or CTL) link(s).
  • the phone memory(ies) include one or several Non-Volatile Memories (or NVM) and/or one or several Volatile Memories (or VM).
  • NVM Non-Volatile Memories
  • VM Volatile Memories
  • the phone memory(ies) may include one or several EEPROMs (acronym for "Electrically Erasable Programmable Read-Only Memory”), one or several ROMs (acronym for "Read Only Memory”), one or several Flash memories, as an NVM(s), and/or any other memories of different types, like e.g., one or several RAMs (acronym for "Random Access Memory”), as a VM(s).
  • EEPROMs electrically Erasable Programmable Read-Only Memory
  • ROMs acronym for "Read Only Memory”
  • Flash memories as an NVM(s)
  • any other memories of different types like e.g., one or several RAMs (acronym for "Random Access Memory"), as a VM(s).
  • the phone memory(ies) 124 stores an OS and an inVention application (or Vapp) for securely accessing one or several eUICC features.
  • the Vapp may be compatible with any OS, such as, among others, an Android, an Iphone or a Windows type OS.
  • the Vapp is preferably able to use an operating voltage modulation scheme to send, to the eUICC 14, a cryptogram that is to be provided by the phone 12 to the eUICC 14 to access one or several chip features.
  • the Vapp includes one or several first cryptographic functions, as security functions.
  • the security functions include preferably a data encryption.
  • the data encryption is to be used prior to sending data, such as at least a predefined pattern, to the eUICC 14, as a phone interlocutor or addressee, so as to protect access to the data to be sent.
  • the phone 12 uses an encryption key ke and an encryption algorithm, such as an Advanced Encryption Standard (or AES), a Data Encryption Standard (or DES), a Rivest-Shamir-Adleman (or RSA) or the like, that the phone 12 (or an entity, like e.g., a server or a chip that is preferably distinct from the eUICC 14, that cooperates with the phone 12) stores.
  • AES Advanced Encryption Standard
  • DES Data Encryption Standard
  • RSA Rivest-Shamir-Adleman
  • the ke constitutes preferably a symmetric key that is shared between the phone 12 and the eUICC 14 while choosing a symmetric encryption algorithm, such as AES or DES.
  • the shared key may be derived from data that is shared between the phone 12 and the eUICC 14.
  • the ke is a public key relating to the eUICC 14 that is shared between the phone 12 and the eUICC 14 while choosing an asymmetric encryption algorithm, such as RSA.
  • the security functions include preferentially a data signature.
  • the data signature is to be used prior to sending data, like e.g., at least a predefined pattern, to the phone interlocutor, so as to prove an origin of data originating from the phone 12.
  • the phone 12 uses a predetermined signature algorithm, such as an AES, a DES, an RSA, a Cipher-based Message Authentication Code (or CMAC), an Elliptic Curve Digital Signature Algorithm (or ECDSA) or the like, and a predetermined signature key that are both stored within the phone 12 or an entity, like e.g., a chip that may be distinct from the eUICC 14 or a server, that cooperates with the phone 12.
  • a predetermined signature algorithm such as an AES, a DES, an RSA, a Cipher-based Message Authentication Code (or CMAC), an Elliptic Curve Digital Signature Algorithm (or ECDSA) or the like
  • a predetermined signature key that are both stored within the phone 12 or an entity, like
  • the signature key ks is preferably a private key kp relating to the phone 12 while choosing an asymmetric signature algorithm, such as RSA or ECDSA.
  • the phone 12 stores preferably a corresponding public key kpub that is shared with the eUICC 14, as the phone interlocutor.
  • the ks constitutes a symmetric key that is shared between the phone 12 and the eUICC 14 while choosing a symmetric signature algorithm, such as AES, DES or CMAC.
  • the data signature allows generating corresponding signed data, prior to its secure sending (i.e. in an authenticated manner while proving its integrity) to the eUICC 14, as the phone interlocutor.
  • the phone memory(ies) stores preferably an International Mobile Equipment Identity (or IMEI), a Mobile Subscriber Integrated Services Digital Network number (or MSISDN), an Internet Protocol (or IP) address, a Media Access Control (or MAC) address, an email address(es), as an IDentifier(s) relating to the phone 12, an International Mobile Subscriber Identity (or IMSI), an Integrated Circuit Card IDentifier (or ICCID) and/or the like, as a unique ID(s) relating to the eUICC 14.
  • IMEI International Mobile Equipment Identity
  • MSISDN Mobile Subscriber Integrated Services Digital Network number
  • IP Internet Protocol
  • IP Media Access Control
  • email address(es) preferably an email address(es), as an IDentifier(s) relating to the phone 12, an International Mobile Subscriber Identity (or IMSI), an Integrated Circuit Card IDentifier (or ICCID) and/or the like, as a unique ID(s) relating to the eUICC 14.
  • the phone memory(ies) stores, preferably in a secure manner, a predetermined pattern.
  • the pattern may have been provided by an entity, such as a chip distinct from the eUICC 14 or a server, that cooperates with the phone 12.
  • the pattern that is to be recognized by the eUICC 14 is used for accessing securely one or several features of the eUICC 14.
  • the phone memory(ies) stores, preferably in a secure manner, a predetermined counter.
  • the counter may have been provided by an entity, such as a server or a chip that cooperates with the phone 12, like e.g., the eUICC 14.
  • the counter is used for diversifying the pattern from a session to another session for securely accessing an eUICC feature(s).
  • the counter is used for preventing replaying the same pattern or the same corresponding cryptogram at another session for securely accessing one or several features of the eUICC 14.
  • the counter value is shared between the phone 12 and the eUICC 14.
  • the phone memory(ies) stores, preferably in a secure manner, a predetermined unique ID relating to the eUICC 14, such as a Chip Serial Number or CSN, and/or a predefined unique ID relating to the eUICC product (or batch), as a fleet of chips that includes the concerned chip.
  • a predetermined unique ID relating to the eUICC 14 such as a Chip Serial Number or CSN, and/or a predefined unique ID relating to the eUICC product (or batch), as a fleet of chips that includes the concerned chip.
  • the eUICC 14 is used for protecting the concerned solution against a cloning attack.
  • the phone 12 may have been provided by an entity, such as a server or the eUICC 14, that cooperates with the phone 12, with an ID relating to the eUICC 14 and/or an ID relating to the eUICC product that is associated with the phone 12.
  • entity such as a server or the eUICC 14 that cooperates with the phone 12, with an ID relating to the eUICC 14 and/or an ID relating to the eUICC product that is associated with the phone 12.
  • the server may access a database that registers, for each ID relating to a (chip host) device, an ID relating to a chip product and/or an ID relating to a chip which the identified device is associated with.
  • the server may have provided, once the phone 12 and/or the phone user has(have) preferably authenticated successfully, a registered phone with an ID relating to a chip product and/or an ID relating to the chip which the phone 12 is associated with.
  • the phone 12 is arranged to apply one or several first predetermined cryptographic operations, such as a data encryption and/or a data signature, to a data sequence.
  • first predetermined cryptographic operations such as a data encryption and/or a data signature
  • the phone 12 thus obtains a corresponding cryptogram, namely a data sequence that is encrypted and/or signed, as a secure data sequence.
  • the phone 12 is further able to send, to the eUICC 14, the cryptogram.
  • the phone 12 may be configured to send, to the eUICC 14, a predetermined trigger signal.
  • the phone 12 as a chip host device, is connected to the eUICC 14, as the chip.
  • the chip 14 is incorporated, possibly in a removable manner, within a Printed Circuit Board (or PCB) of the host device 12.
  • the chip 14 may also include at least part of the phone component(s), like e.g., a baseband processor, an application processor(s) and/or other electronic component(s).
  • the phone component(s) like e.g., a baseband processor, an application processor(s) and/or other electronic component(s).
  • the (SE) chip includes a TEE, as a secure area of a chip host device processor and a secured runtime environment.
  • the SE chip may be removable from the host phone 12, as the chip host device.
  • the chip 14 includes a (micro)processor(s) and/or a (micro)controller(s) 142, as data processing means, a memory(ies) 144, as data storing means, and one or several I/O interfaces 146 that are internally all connected, through an internal control and data bus 143, to each other.
  • a (micro)processor(s) and/or a (micro)controller(s) 142 as data processing means
  • a memory(ies) 144 as data storing means
  • I/O interfaces 146 that are internally all connected, through an internal control and data bus 143, to each other.
  • the chip I/O interface(s) 146 includes at least one input interface that is described in relation with figure 2 .
  • the input interface includes at least two power pins that allow receiving data through an operating voltage modulation.
  • the chip I/O interface(s) 146 allow(s) communicating data at least from the chip 14 exterior to the internal chip 14 components and preferably vice versa, namely from the internal chip 14 components to the chip 14 exterior.
  • the chip data processing means includes a (main) Central Processing Unit (or CPU).
  • the CPU 122 processes, controls and communicates internally data with all the other components incorporated within the chip 14 and, through the I/O interface(s) 146, with the chip exterior.
  • the CPU 122 executes or runs one or several applications, like e.g., a SIM type application that allows to identify and authenticate to a network(s).
  • applications like e.g., a SIM type application that allows to identify and authenticate to a network(s).
  • the CPU 122 executes, in a preferred manner, one or several security functions, like e.g., a chip user authentication function through a PIN, biometric data and/or the like, as user reference data, that is stored, preferably in a secure manner, within the chip memory(ies) 144.
  • security functions like e.g., a chip user authentication function through a PIN, biometric data and/or the like, as user reference data, that is stored, preferably in a secure manner, within the chip memory(ies) 144.
  • the chip memory(ies) 144 includes preferably one or several NVMs and one or several VMs.
  • the chip memory(ies) 144 stores, preferably in a ROM type memory(ies), an OS and an inVention application (or Vappli) for securely accessing one or several chip features.
  • the concerned chip features may include an access to a memory(ies), a loading of a new OS source code, a writing of user data and/or system data in a secure way.
  • the Vappli includes one or several second cryptographic functions, as security functions.
  • the security functions include preferentially a data signature verification.
  • the data signature verification is to be used after having received data, like e.g., at least a cryptogram, from the chip interlocutor, so as to prove an origin of data received by the chip 14.
  • the chip 14 uses a predetermined signature verification algorithm, such as an AES, a DES, an RSA, an ECDSA, a CMAC or the like, and a predetermined signature verification key kv that are both stored within the chip 14.
  • the kv is preferably a public key kpub relating to the device 12, as the data sender, and that is shared between the phone 12 and the eUICC 14 while choosing an asymmetric signature verification algorithm, such as RSA or ECDSA.
  • the kv constitutes a symmetric key that is shared between the phone 12 and the eUICC 14 while choosing a symmetric signature algorithm, such as AES, DES or CMAC.
  • the data signature allows the eUICC 14, as its receiver, to authenticate the phone 12, as its sender and to prove the integrity of the signed data (i.e. the received signed data has not been modified).
  • the chip 14 stores preferably the kpub relating to the device, as the chip interlocutor.
  • the security functions include preferably a data decryption.
  • the data decryption is to be used after having received data, such as at least a cryptogram, as encrypted data, from the chip interlocutor, so as to protect access to the received data that is encrypted.
  • the chip 14 uses a decryption key kd and a decryption algorithm, such as an AES, a DES, an RSA or the like, that the chip 14 stores.
  • the kd used for the data decryption is preferably the ke used for the data encryption.
  • the kd thus constitutes preferably the symmetric key that is shared between the device 12, as a chip interlocutor, and the chip 14 while choosing a symmetric decryption algorithm, such as AES or DES.
  • the shared key may be derived from data that is shared between the device 12 and the chip 14.
  • the chip 14 is, apart from the device 12, the sole entity that is able to decrypt the received encrypted data if the chip interlocutor has effectively the concerned shared data and thus the corresponding shared key.
  • the kd is a private key relating to the eUICC 14 while choosing an asymmetric decryption algorithm, such as RSA.
  • the data decryption allows accessing corresponding decrypted encrypted data, i.e. data in plain text, after its secure reception (i.e. in an encrypted manner) from the chip interlocutor, as the encrypted data originator.
  • the chip memory(ies) stores preferably an IMSI, an ICCID, a CSN and/or the like, as a unique ID(s) relating to the chip 14 and a chip 14 ID.
  • the chip memory(ies) may store a unique ID relating to the product (or batch) of the chips, as a chip 14 product ID that includes the chip 14.
  • the chip memory(ies) stores, preferably in a secure manner, a predetermined pattern.
  • the pattern may have been provided by an entity, such as a chip distinct from the eUICC 14 or a server, that cooperates with the chip 14.
  • the pattern that is to be recognized by the chip 14 is used for authorizing access to one or several features of the chip 14.
  • the chip memory(ies) may store a plurality of patterns corresponding, each, to a feature(s) of the chip 14 to be accessed, when applicable.
  • the chip memory(ies) stores, preferably in a secure manner, a predetermined counter.
  • the counter may have been provided by an entity, such as a server, that cooperates with the chip 14.
  • the counter value has to be maintained in a synchronized manner between the device 12 and the chip 14.
  • the chip is preferably arranged to change the counter value for the next secure chip feature access session.
  • the chip 14 is able to increment or decrement the current counter value by a predetermined increment or decrement value respectively, so as to get a next counter value that is valid for the next secure chip feature access session.
  • a chip input interface that is described infra in relation with the figure 2 and that includes two pads (or pins)
  • receives, through a signal that is modulated on an operating voltage, data the chip 14 stores the received data in a (chip) VM.
  • the VM is used notably for storing data that is thus received by the chip 14.
  • the VM has a predetermined fixed size, such as a size that is expressed in a number of byte(s), that corresponds to a power of two (i.e. a number of the form 2 n where n is an exponent integer).
  • the length of the data to be received is adjusted to the VM size.
  • the chip (and, more exactly, its CPU) is adapted to verify, among data received by or within the chip 14, whether a predetermined trigger signal is or is not present.
  • the trigger signal may originate from either, as an internal trigger signal, a chip memory, as an internal chip component, or, as an external trigger signal, through an operating voltage modulation scheme, the device, as an external entity.
  • the chip CPU receives a predefined interrupt signal, as an internal trigger signal, from a chip VM that has received, through an operating voltage modulation scheme, data from the chip exterior, when the chip VM becomes full (or complete) (i.e. the VM stores as much data that the VM size), as described in relation with the figure 2 .
  • the chip 14 is configured to receive, through an operating voltage modulation scheme, an external trigger signal.
  • the trigger signal (be it internal or external) allows notifying the chip 14 to launch an application of one or several second predetermined cryptographic operations to a cryptogram received through an operating voltage modulation scheme.
  • the chip 14 is adapted to apply, only if the trigger signal is present, one or several second cryptographic operations, such as a data signature verification and/or a data decryption, to the received cryptogram and thus obtain the received data sequence (in plain text).
  • second cryptographic operations such as a data signature verification and/or a data decryption
  • the chip 14 is arranged to verify whether the received data sequence does or does not include a predetermined pattern.
  • the chip 14 is configured to authorize, only if the received data sequence includes the pattern, access to the feature(s) of the chip 14.
  • Figure 2 shows schematically an exemplary embodiment of an architecture of the chip 14.
  • the chip 14 includes an (electrical) communication interface 20, a CPU 220, as data processing means, and data storing means 230 that includes a VM 232 and a NVM 234.
  • contents of a VM are erased when the power is turned off or interrupted.
  • Contents of an NVM are persistent and survive even after that the power is turned off or interrupted (once or several times).
  • the communication interface 20 includes six pads or pins: a GrouND (or GND) pin 22, as a first reference voltage power input, a VCC pin 24, as a second reference voltage power input, an I/O pin 26, as Input/Output for serial data, a CLocK (or CLK) pin 28, as a clock signal input, a ReSeT (or RST) pin 210, an a Vpp pin 212, as a programming power input.
  • the chip 14 comprises, preferably in a ROM, an agent.
  • the agent is preferably a SW component, as the Vappli.
  • the agent is a HW component or a combination of HW and SW components.
  • the agent is preferably able to measure a series of voltage values between the GND pin 22 and the VCC pin 24, as two power supply inputs.
  • the agent is also able to detect a series of sync signals which are interleaved with the voltage values.
  • the sync signals are distinct from a CLK signal(s) which may be received on the CLK pin 28.
  • the chip 14 receives preferably data through the received series of voltage values between the GND pin 22 and the VCC pin 24, as two power supply inputs.
  • the VM(s) is(are) adapted to store data that is received by the chip 14.
  • the VM(s) is(are) configured to send, to the CPU 220, when the VM(s) is(are) full, a predefined interrupt signal, as an internal trigger signal.
  • the VM(s) store(s), when the VM(s) is(are) full, at least the received cryptogram.
  • the agent (or the chip 14) is configured to verify, among data that is received by the chip 14, whether a predetermined trigger signal is or is not present.
  • the trigger signal as an external trigger signal, includes a predefined voltage between the two power supply inputs for a predetermined number of one or several CPU clock cycles.
  • the trigger signal when the presence is detected by the CPU 220, allows to trigger an execution, by the CPU 220, of one or several second cryptographic functions onto the received data.
  • Figure 3 presents schematically a cryptogram and a trigger signal that the device 12 sends to the chip 14 by using an operating voltage modulation scheme.
  • the agent spies only the two power supply pins 22 and 24.
  • the agent is configured to detect different classes of operating conditions, namely class A, class B and class C, that are defined by, for instance, the International Organization for Standardization (or ISO)/IEC 7816-3 third edition dated 2006-11-01.
  • the nominal supply voltage provided to the VCC pin 24 is:
  • the chip 14 receives a signal 31.
  • a signal of class B that is detected on the VCC pin is interpreted by the agent, as a sync signal.
  • the sync signal is implemented by a predefined difference between the two power supply inputs.
  • the chip 14 is adapted to detect, within a received series of measured voltage values between the two power supply inputs, a predefined trigger signal 35. In other words, the chip 14 is configured to verify, among data received by the chip 14, whether a predefined trigger signal 35 is or is not present.
  • the trigger signal 35 shall arrive at the end of the received secure data sequence to notify a chip security layer to start one or several second cryptographic operations, namely a data signature verification and/or a data decryption, on the secure data sequence.
  • the length of the secure data sequence may vary depending on the chip 14 feature(s) that is(are) to be accessed.
  • the length of the secure data sequence is preferably large when the chip feature(s) that is(are) to be accessed is(are) sensitive in terms of security.
  • a signal 34 that is detected on the VCC pin is interpreted by the agent, as a trigger signal 35.
  • the trigger signal 35 as an external trigger signal, includes e.g., a predefined voltage, such as 4V, as a voltage between the class A voltage and the class B voltage, between the two power supply inputs, for a predetermined number of one or several CPU clock cycles, such as between e.g., one and 16 clock cycles.
  • the number of the CPU clock cycles may be adapted to a used CPU architecture.
  • the occurrence of the trigger signal 35 allows the chip 14 to know that the chip 14 has effectively received, through an operating voltage modulation scheme, a secure data sequence, as a cryptogram.
  • the secure data sequence includes encrypted and/or signed data relating to the pattern.
  • the secure data sequence is constituted by the following sequence or series of bits or bytes "0" 36, "0” 38, "1" 310 and "0" 312.
  • the chip 14 stores the received secure data sequence in its VM(s), such as one or several flip-flops.
  • Figure 4 depicts an exemplary embodiment of a message flow 40 that involves the device 12 and the chip 14, so that the chip 14 securely detects a predefined pattern and, when detected, authorizes access to a chip 14 feature(s).
  • the device 12 and the chip 14 are in the field, i.e. at a post-issuance stage.
  • the device 12 retrieves 42, from a device memory, a predefined pattern.
  • the device 12 reads preferably a device NVM that stores the pattern.
  • the pattern has preferably a variable size.
  • the pattern size may vary between e.g., 16 bytes and e.g., 256 bytes.
  • the pattern size depends preferably on the chip feature(s) to be accessed.
  • the pattern in plain text can be encoded using a Length Value (or LV) format, as described in ETSI TS 101 220 (7.1.2 Length encoding) e.g., v.7.0.0 dated 2004-12.
  • the device 12 gets preferably a counter. To get the counter, the device 12 reads preferably the counter from a device NVM that stores the counter.
  • the counter has a fixed size.
  • the counter size may be of e.g., 4 bytes.
  • the device 12 adds 43 preferably (but not mandatorily) the counter to the retrieved pattern by concatenating the counter either before or after the pattern.
  • the device 12 creates a corresponding data sequence.
  • the data sequence relates to the pattern.
  • the device 12 builds 44 a data sequence by concatenating the pattern, possibly the counter and possibly padding bits, so as get a data sequence that has a fixed size.
  • the built data sequence relates to the pattern.
  • the data sequence size may be a multiple of 8 bytes or 16 bytes depending on the block size of the used encryption algorithm and/or the used signature algorithm.
  • the device 12 encrypts 46 preferably the data sequence (preferably with the counter). In other words, the device 12 applies preferably a data encryption to the data sequence (preferably with the counter). The device 12 obtains thus a first cryptogram, as an encrypted data sequence (preferably with the counter). The first cryptogram relates to the pattern.
  • the device 12 retrieves preferably a unique ID relating to the chip 14.
  • the device 12 reads preferably the chip ID from a device NVM that stores the chip ID.
  • the device 12 requests, to the chip 14, through another thus open communication link, such as the ISO 7816-3 communication protocol using Application Protocol Data Unit (or APDU) than the operating voltage modulation link, a chip ID 12.
  • the chip ID request includes or is accompanied preferably with an authentication token or the like.
  • the chip 14 After having preferably authenticated the device 12 by using the provided authentication token or the like, the chip 14 sends, to the device 12, through the open communication link, the chip 14 ID, as a request response.
  • the device 12 retrieves preferably a unique ID relating to the chip 14 product.
  • the device 12 reads preferably the chip product ID from a device NVM that stores the chip product ID.
  • the device 12 does not need to any other communication link than the one used to send the secure data sequence, namely the operating voltage modulation scheme.
  • the device 12 may add 47 the retrieved chip ID either to the first cryptogram (when the data sequence (preferably with the counter) is previously encrypted) or the data sequence (when the data sequence (preferably with the counter) is not previously encrypted) that the device 12 has to send securely to the chip 14.
  • the device 12 instead of a chip ID, the device 12 adds the retrieved chip product ID either to the first cryptogram (when the data sequence (preferably with the counter) is previously encrypted) or the data sequence (when the data sequence (preferably with the counter) is not previously encrypted) that the device 12 has to send securely to the chip 14.
  • the device 12 signs 48 preferably the chip ID (or the chip product ID) and either the first cryptogram (when the data sequence (preferably with the counter) is previously encrypted) or the data sequence (when the data sequence (preferably with the counter) is not previously encrypted). In other words, the device 12 applies preferably to either the first cryptogram or the data sequence, a data signature.
  • the device 12 obtains preferably signed encrypted data sequence (and preferably chip ID or chip product ID), as a second cryptogram (when the data sequence (preferably with the counter) is previously encrypted), or signed data sequence (and preferably chip ID or chip product ID), as a third cryptogram (when the data sequence (preferably with the counter) is not previously encrypted).
  • the data signature has a fixed size.
  • the data signature size may be of e.g., 8 bytes.
  • the device 12 sends 410, to the chip 14, the resulting secure data sequence, as a cryptogram.
  • the resulting cryptogram has preferably a fixed size.
  • the cryptogram size may be adjusted to a chip VM that may store the received cryptogram.
  • the device 12 may also send, to the chip 14, a predetermined trigger signal, as an external trigger signal.
  • the device sends, to the chip, the cryptogram and possibly the trigger signal, by using an operating voltage modulation scheme, as a universal communication link.
  • the universal communication link is common to all of the chips.
  • the device 12 does not need to use any other specific communication channel that may not be available at the chip 14 side.
  • the chip 14 receives 412 data, as a data sequence that is encrypted and/or signed and as a cryptogram relating to the pattern.
  • the chip receives, from the device, the cryptogram and possibly the trigger signal, by using an operating voltage modulation scheme, as a universal communication link.
  • the chip 14 verifies 414, among data received by or in the chip 14, whether a predetermined trigger signal is or is not present.
  • the chip 14 CPU detects, as an external trigger signal, within a received series of measured voltage values between the two power supply inputs, a predefined voltage between the two power supply inputs for a predefined number of one or several CPU clock cycles.
  • the chip 14 CPU receives, from a chip VM, an interrupt signal, as an internal trigger signal, when the chip VM is full.
  • the chip VM stores, when the chip VM is full, at least the received cryptogram.
  • the chip VM size may be configured to adjust to the size of the received cryptogram.
  • the chip 14 CPU continues receiving data by going back to the data reception step 412.
  • the chip 14 CPU may perform simultaneously an(other) usual task(s) avoiding thus to degrade the performance.
  • the chip 14 As soon as the chip 14 CPU has detected the trigger signal presence, the chip 14 is aware that a cryptogram relating to the pattern has been received by the chip 14 through an operating voltage modulation scheme.
  • the chip 14 retrieves, from the chip VM, the received cryptogram.
  • the chip 14 applies, only if the trigger signal is present, one or several second cryptographic operations, to the (retrieved) received cryptogram.
  • the chip 14 retrieves preferably a chip 14 ID.
  • the chip 14 reads preferably the chip ID, from a chip 14 ROM, as an NVM, that stores the chip ID.
  • the chip 14 retrieves preferably a unique ID relating to the chip 14 product.
  • the chip 14 reads preferably the chip product ID from a chip 14 NVM that stores the chip product ID.
  • the chip 14 may add 415 the retrieved chip ID to the received cryptogram.
  • the device 12 adds the retrieved chip product ID to the received cryptogram.
  • the chip 14 verifies 416 preferably whether the signature is or is not valid.
  • the chip 14 infers that the chip 14 is being attacked and sends 417, to a predetermined entity, such as a remote server, an alert signal for informing that the chip 14 is being attacked and/or takes a security measure(s), such as a chip initialisation or reset, so as to erase all of the data stored in the chip.
  • a predetermined entity such as a remote server
  • the chip 14 has authenticated the device 12, as being the chip 14 interlocutor, and continues to carry out the next scheduled step(s) relating to the invention method (for securely accessing a chip feature(s)).
  • the chip 14 decrypts 418 preferably the received cryptogram.
  • the chip 14 decrypts the encrypted data sequence and gets the corresponding data sequence possibly with the counter.
  • the chip 14 verifies (not represented) whether the obtained data sequence does or does not include the counter.
  • the chip 14 In the negative, i.e. if the data sequence does not include the counter, the chip 14 infers that the chip 14 is being attacked and sends 417, to a predetermined entity, such as a remote server, an alert signal for informing that the chip 14 is being attacked and/or takes a security measure(s), such as a chip initialisation or reset, so as to erase all of the data stored in the chip.
  • a predetermined entity such as a remote server
  • the chip 14 verifies 419 whether the counter is or is not valid.
  • the chip 14 infers that the chip 14 is being attacked and sends 417, to a predetermined entity, such as a remote server, an alert signal for informing that the chip 14 is being attacked and/or takes a security measure(s), such as a chip initialisation or reset, so as to erase all of the data stored in the chip.
  • a predetermined entity such as a remote server
  • the chip 14 retrieves or obtains 420 the received data sequence in plain text, i.e. in an unencrypted manner.
  • the chip 14 verifies 422 whether the received data sequence does or does not include a predetermined pattern that is registered in a chip NVM or the like.
  • the chip 14 forbids or refuses 423 the device 12 to access a chip feature(s).
  • the chip 14 authorizes 424 the device 12 to access a corresponding chip feature(s).
  • the chip 14 changes 425 preferably the counter value for a next chip feature access session.
  • the chip 14 may send, to the device 12, through another communication link, such as ISO 7816-3 using APDU, an I2C, an SPI or a USB, than the communication link used to receive the cryptogram relating to the pattern, a message informing the device 12 that the counter value has been changed.
  • another communication link such as ISO 7816-3 using APDU, an I2C, an SPI or a USB
  • the device 12 that shares with the chip 14 one and the same algorithm for determining a next counter value changes also the counter value, so as to be synchronized with the new counter value.
  • the device 12 and the chip 14 shares the new counter value that is valid for a next chip feature access session.
  • the invention solution allows securing access to a chip feature(s).
  • the invention solution allows having a secure, seamless and efficient access to a chip features.
  • the invention solution allows avoiding to use a conventional communication protocol that may not be available to access the chip feature(s).
  • the invention solution allows avoiding to unsolder the chip from the device while using such a secure access to a chip feature(s), so as to analyse/diagnose and possibly debug and recover the chip in the field.
  • a remote server instead of receiving a pattern to be recognized from a local device, a remote server sends, in a wireless manner, through a chip host device, with the chip.
  • a chip host device instead of receiving a pattern to be recognized from a local device, a remote server sends, in a wireless manner, through a chip host device, with the chip.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)
EP19306767.5A 2019-12-24 2019-12-24 Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité Withdrawn EP3842976A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19306767.5A EP3842976A1 (fr) 2019-12-24 2019-12-24 Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité
PCT/EP2020/076940 WO2021129961A1 (fr) 2019-12-24 2020-09-25 Procédé et système correspondant permettant d'accéder de manière sécurisée à au moins une caractéristique d'une puce

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19306767.5A EP3842976A1 (fr) 2019-12-24 2019-12-24 Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité

Publications (1)

Publication Number Publication Date
EP3842976A1 true EP3842976A1 (fr) 2021-06-30

Family

ID=72517069

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19306767.5A Withdrawn EP3842976A1 (fr) 2019-12-24 2019-12-24 Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité

Country Status (2)

Country Link
EP (1) EP3842976A1 (fr)
WO (1) WO2021129961A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11456855B2 (en) * 2019-10-17 2022-09-27 Arm Limited Obfuscating data at-transit

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013023065A1 (fr) * 2011-08-09 2013-02-14 Qualcomm Incorporated Lier un module amovible à un terminal d'accès
EP3502912A1 (fr) * 2017-12-19 2019-06-26 Gemalto Sa Procédé d'activation d'une fonctionnalité d'une puce

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013023065A1 (fr) * 2011-08-09 2013-02-14 Qualcomm Incorporated Lier un module amovible à un terminal d'accès
EP3502912A1 (fr) * 2017-12-19 2019-06-26 Gemalto Sa Procédé d'activation d'une fonctionnalité d'une puce
WO2019120991A1 (fr) 2017-12-19 2019-06-27 Gemalto Sa Procédé d'activation d'une fonction d'une puce

Also Published As

Publication number Publication date
WO2021129961A1 (fr) 2021-07-01

Similar Documents

Publication Publication Date Title
US8295484B2 (en) System and method for securing data from a remote input device
EP2890167B1 (fr) Procédé, terminal et carte de circuit intégré universelle (uicc) permettant de réaliser une fonction de carte de module d'identité d'abonné (sim) dans le terminal
EP2448305A1 (fr) Traitement de données pour sécuriser les ressources locales dans un dispositif mobile
JP2004538584A (ja) 電子装置における情報の処理方法、システム、電子装置及び処理ブロック
KR102453705B1 (ko) 호스트의 정당성 여부에 따라 선택적으로 결제 기능을 온(on)하는 결제 장치의 동작 방법
CN113748698B (zh) 存取网络时的安全通信
KR100847145B1 (ko) 불법 액세스 포인트 검출 방법
US10872327B2 (en) Mobile payment systems and mobile payment methods thereof
US20130073840A1 (en) Apparatus and method for generating and managing an encryption key
EP3842976A1 (fr) Procédé et système correspondant permettant d'accéder à au moins une caractéristique d'une puce en toute sécurité
KR20150101016A (ko) 엔에프씨 기반 종단 간 상호 인증을 이용한 거래수단 제어 방법
KR20140063014A (ko) 생체 인식을 이용한 인증서 비밀번호 대체 방법
JP6790839B2 (ja) セキュアエレメント、ｕｉｍカード、認証方法、及び認証プログラム
KR20150004955A (ko) 유심과 서버 사이의 종단간 인증을 이용한 서버형 인증코드 제공 방법
CN111758243A (zh) 移动存储设备、存储系统和存储方法
KR20160124336A (ko) 보안운영체제를 이용한 전자서명 제공 방법
EP3506559A1 (fr) Procédé, premier dispositif, second dispositif et système permettant d'authentifier un premier dispositif vers un second dispositif
KR101505735B1 (ko) 시간 검증을 이용한 엔에프씨카드 인증 방법
KR101972492B1 (ko) 에스디메모리 기반 다중 오티피 운영 방법
KR20150000081A (ko) 카드와 서버 사이의 종단간 인증을 이용한 일회용코드 제공 방법
Pedraja et al. Offloading cryptographic services to the SIM card
KR101777041B1 (ko) 비동기식 근거리 무선 통신 기반 오티피 구현 방법
KR101866031B1 (ko) 보안운영체제를 이용한 서버형 오티피 제공 방법
KR101513434B1 (ko) 키 입력 보호 방법과 이를 위한 키 보호 모듈
KR101777044B1 (ko) 비동기식 근거리 무선 통신 기반 오티피 카드

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20220104