[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP3238200A1 - Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée - Google Patents

Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée

Info

Publication number
EP3238200A1
EP3238200A1 EP15828654.2A EP15828654A EP3238200A1 EP 3238200 A1 EP3238200 A1 EP 3238200A1 EP 15828654 A EP15828654 A EP 15828654A EP 3238200 A1 EP3238200 A1 EP 3238200A1
Authority
EP
European Patent Office
Prior art keywords
secure electronic
electronic entity
integrity
secure
data
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
EP15828654.2A
Other languages
German (de)
English (en)
Inventor
Emmanuelle Dottax
Florian GALDO
Christophe Giraud
Jean-Philippe Vallieres
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.)
Idemia France SAS
Original Assignee
Oberthur Technologies 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 Oberthur Technologies SA filed Critical Oberthur Technologies SA
Publication of EP3238200A1 publication Critical patent/EP3238200A1/fr
Withdrawn legal-status Critical Current

Links

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/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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • 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/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity

Definitions

  • Secure electronic entity electronic apparatus and method for verifying the integrity of data stored in such a secure electronic entity
  • the present invention relates to the verification of the integrity of data stored in a secure electronic entity.
  • It relates more particularly to a secure electronic entity, an electronic device and a method for verifying the integrity of data stored in such a secure electronic entity.
  • the invention applies particularly advantageously in the case where the stored data are at least partially secret and must therefore be encrypted when they are stored outside the secure electronic entity.
  • secure electronic entities such as integrated microcircuit cards or secure elements, which store confidential data, for example secret cryptographic keys, used, for example, in applications for encrypting electronic messages, electronic signature or encryption. identification.
  • the present invention provides a secure electronic entity comprising a memory storing data in the form of bytes and a processing module adapted to receive data from an electronic device, characterized in that the processing module is designed to determine an integrity evidence item based on the received data and at least a portion of the stored bytes, and to issue the integrity evidence item to the electronic device.
  • the secure electronic entity is designed to return a piece of evidence of integrity determined by combining the received data and memorized bytes.
  • Such evidence proves that stored data (in the form of bytes) at the time when the electronic entity receives the data from the external electronic device (for example a third-party auditor) are indeed those expected, otherwise secure electronic entity could not produce the correct evidence.
  • the received data represent a random value (generated for example by the electronic device);
  • the received data designate regions of the memory
  • the processing module is designed to determine the integrity proof element as a function of the multiplets stored in the regions designated by the received data;
  • the processing module is designed to determine the proof of integrity element partly by means (that is to say by means in particular) of an encryption of the stored bytes;
  • the secure electronic entity comprises a module for implementing the encryption as a function of a secret key stored in the electronic entity
  • the processing module is adapted to determine the proof of integrity element by means of a signature function or a hash function or a message authentication code generation function;
  • said secure electronic entity is an access card to a mobile telephone network.
  • the invention also proposes a cellular telephone comprising a secure electronic entity as proposed above, for example soldered to the cellular telephone.
  • the invention also proposes a power supply counter comprising a secure electronic entity as proposed above, for example soldered to said counter.
  • the invention also proposes an on-board electronic system for a vehicle (for example for a motor vehicle) comprising a secure electronic entity as proposed above, possibly welded to the electronic system.
  • the invention further provides an electronic apparatus comprising a near-field communication module and a secure electronic entity as proposed above connected to the near field communication module.
  • the invention also proposes a method for verifying the integrity of data stored in a secure electronic entity, characterized in that it comprises the following steps:
  • Such a method may further comprise a step of determining at least part of the data transmitted by random draw (for example within the electronic device).
  • the received data can represent a random value used as a parameter during the application of a function.
  • the received data can designate regions of the memory; the determination of the integrity proof element can in this case be carried out according to the multiplets stored in the regions designated by the received data.
  • the determination of the integrity proof element comprises encryption of the memorized bytes
  • the encryption of the stored bytes uses a secret key stored in the secure electronic entity
  • the proof of integrity element is determined by applying a signature function or a hash function or a message authentication code generation function;
  • said electronic device is a third party listener.
  • FIG. 1 shows a system in which is used a secure electronic entity according to the invention
  • FIG. 2 schematically shows the information stored in a server of a third party auditor and in a non-volatile memory of the secure electronic entity according to a first embodiment of the invention
  • FIG. 3 represents the main steps of a first exemplary method implemented in the context of the invention
  • FIG. 4 represents the main steps of a second exemplary method implemented in the context of the invention.
  • FIGS. 5 to 7 schematically represent algorithms that can be used in the context of the method of FIG. 4;
  • FIG. 8 represents the main steps of a third exemplary method implemented in the context of the invention.
  • FIG. 9 represents the main steps of a fourth exemplary method implemented in the context of the invention.
  • Figure 1 shows schematically the main elements of a system in which the invention can be implemented.
  • Such a system comprises an electronic apparatus A provided with a communication module COM for exchanging data with other electronic devices, as described hereinafter.
  • the electronic device A may be a cellular and / or smart phone (in English: "smartphone”), a digital tablet or any other electronic device which it is desired that it may exchange data with external electronic devices, for example a energy supply meter, an appliance or an electronic system embedded in a motor vehicle.
  • smart phone in English: "smartphone”
  • digital tablet or any other electronic device which it is desired that it may exchange data with external electronic devices, for example a energy supply meter, an appliance or an electronic system embedded in a motor vehicle.
  • the communication module COM makes it possible to establish two-way communication (here wireless) with an N network architecture, which is itself connected to the Internet network INT.
  • the network architecture N can be a mobile telephone network, in which case the communication module COM is designed to communicate with a base station of the mobile network.
  • the network architecture N can be an access point of a wireless local area network (WLAN), in which case the communication module COM is designed to join this local network.
  • WLAN wireless local area network
  • the communication module COM makes it possible to access the Internet network INT through the network architecture N.
  • a processor P of the electronic apparatus A (for example a microprocessor) connected to the communication module COM can exchange data with electronic devices (such as computers or servers) connected to the Internet network, in particular a third party auditor ( or TPA for "Third Party Auditor") TP and ISS electronic entity transmitter.
  • electronic devices such as computers or servers
  • TPA Third Party auditor
  • the electronic apparatus A also comprises a secure electronic entity E, for example a microcircuit card, possibly universal (or UICC for "Universal Integrated Circuit Card”) as referred to in the technical specification ETSI TS 102 221, an integrated secure element ( or eSE for "embedded Secure Element” as referred to in the "GlobalPIatform Card Specification version 2.2.1” specification or other type of secure element.
  • a secure electronic entity E for example a microcircuit card, possibly universal (or UICC for "Universal Integrated Circuit Card") as referred to in the technical specification ETSI TS 102 221, an integrated secure element ( or eSE for "embedded Secure Element” as referred to in the "GlobalPIatform Card Specification version 2.2.1” specification or other type of secure element.
  • the secure electronic entity E is a microcircuit card
  • it may be for example an access card to a mobile telephone network, such as a USIM type card (for "Universal Subscriber Identity Module "), or a secure token (in English:” secure token ").
  • the secure electronic entity E can be mounted in the device A removably (as is the case for a microcircuit card made in one of the formats 2FF, 3FF or 4FF, or, in general, according to a format smaller than those of the 2FF format), or immovably (for example welded) as in the case of an integrated secure element (eSE already mentioned above) or an integrated microcircuit card (also called eUICC for " embedded Universal Integrated Circuit Card ").
  • the secure electronic entity E is here connected to the processor P of the electronic device A and thus has access, via this processor P, to the communication module COM.
  • the secure electronic entity E could be directly connected to the COM communication module.
  • the secure electronic entity itself comprises a microprocessor M, a random access memory V and at least one nonvolatile memory NV, for example a rewritable non-volatile memory of the EEPROM type (for "Electrically Erasable and Programmable Read-Only Memory ”) or Flash.
  • NV nonvolatile memory
  • EEPROM Electrically Erasable and Programmable Read-Only Memory
  • the nonvolatile memory NV stores computer program instructions which, when executed by the microprocessor M, allow the implementation of methods, such as the methods given below by way of example.
  • the secure electronic entity E also stores data, in particular confidential data such as secret keys (for example in particular the cryptographic keys ⁇ , K2 used in the examples given below).
  • confidential data such as secret keys (for example in particular the cryptographic keys ⁇ , K2 used in the examples given below).
  • the secure electronic entity E can thus implement (as already indicated, because of the execution, by its microprocessor M, of instructions stored in the non-volatile memory NV, or even in the RAM V) a method of cryptographic key encryption and / or a cryptographic key decryption method and / or a cryptographic key signing method and / or an authentication code generating method using secret data and / or a method of generating a response to a challenge by using secret data
  • the cryptographic key or the secret data concerned is for example stored in the non-volatile memory NV.
  • the secure electronic entity E can also implement methods for initiating and establishing a remote communication via the communication module COM implanted in the electronic device A which hosts the secure electronic entity E, for example by means of mechanisms such as those commonly referred to as "SIM Toolkits".
  • SIM Toolkits mechanisms for initiating an exchange with remote electronic devices, such as the third party auditor TP and the issuer ISS.
  • the program instructions and the data are stored (here in NV nonvolatile memory) as bytes (for example bytes).
  • the secure electronic entity E is also designed, because of its physical construction and the design of the computer programs that it memorizes, so as to make it very difficult or impossible for an attacker to access (by reading and / or modification) to the confidential data that it stores.
  • the secure electronic entity E has for example an assurance level EAL greater than 4 in the sense of the Common Criteria (ISO15408 standard), for example a level EAL4 + (VAN5) or higher, and / or a level greater than 3 according to FIPS 140-2 (for "Federal Information Processing Standard").
  • the electronic apparatus A may also comprise a near field communication module COM ', such as a communication module NFC (for "Near Field Communication”).
  • a wireless communication module of another type for example Bluetooth, ZigBee, or other.
  • Such a near field communication module COM ' is here directly connected to the secure electronic entity E, for example by means of a connection of the SWP type (for "Single Wire Protocol")
  • the field communication module close COM 'could be connected to the processor P of the electronic device A and could in this case exchange data with the secure electronic entity E via the processor P.
  • the near field communication module COM ' is designed to enter into communication with a reader (here an NFC reader) when this COM' module (as well as consequently the electronic device A) is positioned at a distance from the reader lower than a predetermined threshold, for example a threshold less than 0.3 m.
  • the reader and the secure electronic entity E can thus exchange data according to a wireless communication protocol, for example according to the ISO 14443 standard.
  • the reader can issue commands (such as ADPU commands for "Application"). Protocol Data Unit ") over the wireless link; the near-field communication module COM 'receives these commands and transmits them to the secure electronic entity E (here via the SWP link).
  • the secure electronic entity E processes these commands (in particular by means of the methods implemented in the secure electronic entity as described above) and transmits responses (generated by the aforementioned processing) via the near-field communication module COM and to destination of the reader.
  • the electronic device A can thus notably be used, thanks to the confidential data stored in the secure electronic entity E and to the exchange possibilities provided by the near-field communication module COM ', as a means of identifying its carrier, for example in payment (payment authorization), transport (access to the transport network via an automatic gateway controlled by the reader), identity, loyalty, etc. applications.
  • the non-volatile memory NV of the secure electronic entity E stores firstly a fixed operating system ROS and a modifiable operating system FOS.
  • the fixed operating system ROS is registered in the non-volatile memory NV during the production of the secure electronic entity E, for example during a personalization phase during which program instructions and personalization data are written in the non-volatile memory NV, here without the possibility of subsequent modification.
  • the modifiable operating system FOS is also written in the non-volatile memory NV during the personalization phase, but can be modified subsequently, for example remotely according to a predefined procedure during which the microprocessor M of the electronic entity secure E communicates with a remote server (for example via the COM communication module) and writes data received from the remote server to the non-volatile memory NV, for example after a step of authentication of the remote server.
  • a remote server for example via the COM communication module
  • such an operating system could be loaded into RAM for its execution.
  • the third party listener TP stores a plurality of random values n, r n and a plurality of verification values Mi, M n respectively associated with the aforementioned random values.
  • the verification values M are not communicated to the secure electronic entity E.
  • the random values ⁇ are successively communicated to the secure electronic entity E, distributed over the period of use of the secure electronic entity E, as explained below. For example, a number n of random values n (and associated verification values M) such that the secure electronic entity E can not memorize the set of these values ⁇ , M, is used.
  • the function F is such that it is impossible to determine F (n, FOS) without having knowledge of all the data forming the modifiable operating system FOS and that the verification values M, do not give any information on the data. forming the editable operating system FOS.
  • the hash function H used is for example of the SHA-256, SHA-512 or SHA-3 type.
  • the function F could be a message authentication code generation function MAC, using a secret key K 2 and, here again, applied for example to the concatenation of the random value ⁇ and data forming the authentication system.
  • modifiable operation FOS: F (n, FOS) MAC (K 2 , n
  • the MAC function used is for example of HMAC type (based for example on SHA-256), CMAC or CBC-MAC (based for example on the AES algorithm).
  • the secret key K 2 is stored by the third party auditor TP to perform the calculation of the verification values M, as it has just been indicated and by the secure electronic entity E for calculating an item of evidence as explained below.
  • a signature produced by means of a private key of a public key infrastructure (PKI).
  • FIG. 3 represents a method of exchanging data between the third party auditor TP and the secure electronic entity E in order to verify that the modifiable operating system FOS is in conformity with that which has been evaluated (for example with a view to certification) in the evaluation phase. It is understood that after this evaluation phase, the third party auditor TP generally no longer has access to the modifiable operating system FOS.
  • This exchange of data between the third party auditor TP and the secure electronic entity E is for example carried out via the Internet network INT, the network architecture N, the communication module COM and the processor P of the electronic device A, as explained above with reference to FIG.
  • the method starts in step E2 by the third party listener TP transmitting one of the random numbers n to the secure electronic entity.
  • Such a step is for example periodically implemented.
  • the random number n emitted during the step E2 is randomly chosen from among the plurality of random numbers n, r n stored in the third party listener TP (this can be done in practice by determining by drawing random, among the integers between 1 and n, the index i used).
  • the random numbers n, r n are used sequentially, one after the other.
  • the secure electronic entity E receives the random number n at the step
  • the secure electronic entity E determines in step E6 the verification value associated with the random number n received, according to the same process as that used by the third party auditor TP during the evaluation phase, here by applying the function F to the random number received n and the data forming the modifiable operating system FOS.
  • M * the verification value thus calculated by the secure electronic entity:
  • the calculated verification value M * is sent to the third party auditor TP in step E8 as evidence to attest that the modifiable operating system FOS has not been modified.
  • the third party auditor TP receives the verification value M * in the step E10 and compares it with the step E12 to that calculated during the evaluation phase.
  • step E16 Due to the properties of the function F indicated above, if the verification value M * calculated by the secure electronic entity E is equal to the verification value M, stored by the third party auditor TP, the corresponding memory image the modifiable operating system FOS is the expected one and the operation of the secure electronic entity can continue normally (step E16).
  • step E14 is performed in which the problem encountered is addressed, for example by sending a message to the ISS transmitter of the secure electronic entity E, which may, for example, revoke the rights associated with the secure electronic entity E.
  • the secure electronic entity E can not calculate and store previously the associated verification value M (which would allow the secure electronic entity E to return the expected value even if the FOS operating system was later modified).
  • the data of the operating system FOS stored in the non-volatile memory NV when receiving the unpredictable value (here random) ⁇ must be in conformity with those present during the evaluation phase so that the entity secure electronics E can calculate a verification value M * equal to the expected value M ,.
  • the secure electronic entity E can not memorize all the random values n and verification M ,, and can not therefore respond to the third party auditor TP using a determined verification value. at an earlier time then stored (which would allow it to make changes to the FOS operating system after processing all the random values ⁇ , r n and stored the verification values Mi, M n associated).
  • FIG. 4 A second embodiment of the invention will now be described with reference to FIG. 4.
  • This embodiment also relates to the case where an editable operating system FOS stored in the non-volatile memory NV of a secure electronic entity E is verified by a third party auditor TP, as schematically represented in FIG.
  • the third party auditor TP does not at any time know (in plain text) data forming the modifiable operating system FOS, but only has an encrypted version C of these data, such as explained now. Note, however, that when the third party auditor TP also has a certifying role, provision can be made for the encrypted version C of the data to be generated during an initial audit phase, under the supervision of the certifier.
  • FIG. 4 represents the main steps of a second exemplary method implemented in the context of the invention.
  • This method thus begins at step E20 with a data encryption step forming the modifiable operating system FOS by the ISS transmitter of the secure electronic entity ISS.
  • This encryption step is for example carried out by applying to the data forming the modifiable operating system FOS an encryption algorithm (here symmetrical) ENC using a secret key Ki stored by the issuer ISS and by the secure electronic entity E (and known only to these two entities).
  • the modifiable operating system FOS is for example divided into ordered blocks FOS j of predetermined size (here 16 bytes).
  • the encryption algorithm ENC is of the CBC (for "Cipher Block Chaining") type and is applied as represented in FIG. 5: the first block FOSi is combined with an initialization vector IV (predetermined or determined during the calculation, for example by random draw) by application of an operator "or exclusive (or XOR), that is to say by Boolean sum, then we apply an encryption algorithm AES with the secret key Ki the result of the combination to obtain the first encrypted block Ci, for the other data blocks of the modifiable operating system FOS, the concerned block FOS j and the preceding encrypted block C j _i are combined by means of an operation of "or exclusive (Boolean sum), then the AES encryption algorithm with the secret key Ki the result of the combination to obtain the encrypted version Cj of the current block.
  • the ENC encryption algorithm is of ECB type (for "Encoded CodeBook") and is applied as shown in FIG. 6: an AES encryption algorithm using the encryption key Ki is applied separately to each block FOS j in order to obtain the encrypted version Cj of the block concerned.
  • the encryption algorithm is of the CTR ("broker") type: an incremented block block counter is encrypted by means of an encryption algorithm, such as the AES encryption algorithm, using a secret key (eg key Ki); the encrypted version Cj of the block concerned is obtained by Boolean sum of the corresponding FOS block j and the encrypted counter.
  • an encryption algorithm such as the AES encryption algorithm, using a secret key (eg key Ki)
  • the encrypted version Cj of the block concerned is obtained by Boolean sum of the corresponding FOS block j and the encrypted counter.
  • the concatenation of the obtained encrypted blocks Cj forms the encrypted version C of the modifiable operating system FOS.
  • the encrypted version C of the modifiable operating system FOS obtained in step E20 is sent to step E22 to the third party auditor TP.
  • the third party auditor TP thus receives, during a step E24, the encrypted version C of the modifiable operating system FOS, for example as already indicated in the form of encrypted blocks Cj.
  • the third party listener TP determines in step E26 a plurality of numbers r ⁇ , r n by random draw.
  • the third party auditor TP determines in step E28 a verification value M, associated, for example by application of a function F to the random number concerned n and to the encrypted version
  • the function F has properties identical to that used in the first embodiment. Moreover, as indicated for the first embodiment, it is possible to use a number n of random values n and of verification values M, such that the secure electronic entity E can not memorize all of these values n, M ,.
  • CBC-MAC for "Cipher Block Chaining - Message Authentication Code" taking as the initialisation vector the random value n and as a cryptographic function the encryption algorithm AES using a secret key
  • the random values ⁇ and the associated verification values M are stored by the third party listener (step E30), as shown in FIG.
  • FOS Since FOS is stored by the third party auditor TP in encrypted form, it can store this data in memory throughout the use of the secure electronic entity E.
  • the third party auditor TP When the secure electronic entity E is used (which the third party auditor TP can be informed by receiving - not shown in Figure 4 - of a message from the issuer ISS), the third party auditor TP periodically checks the FOS editable operating system integrity as described now.
  • step E34 a value n is then determined by random selection in step E34 (this step not being naturally performed when it was first carried out beforehand. step E26).
  • the random value ⁇ is sent by the third party auditor TP in step E36 to of the secure electronic entity E.
  • the secure electronic entity E receives the random value n at the step
  • the secure electronic entity E stores for this purpose the secret key (or cryptographic key) Ki and, in the case where the function F is of type CBC-MAC as indicated above, the secret key (or cryptographic key) K2.
  • the initialization vector IV used by the issuer ISS to encrypt the data forming the operating system FOS is obtained by random draw, this initialization vector IV is also stored in the secure electronic entity E.
  • the third party listener TP determines in step E40 (or possibly before sending the random value n to step E36).
  • the function F is applied to all the modifiable data of the non-volatile memory NV (that is to say in some cases to all the data of the nonvolatile memory NV).
  • steps E40 and E42 it is also possible during steps E40 and E42 to apply the function F to only part of the non-volatile memory NV or the modifiable operating system FOS, for example to only part of the FOS blocks forming the system. Modifiable operating system FOS.
  • the third party auditor TP can send to the secure electronic entity E when the step E36 a designation of the FOS blocks, to which the function F must be applied, by example in the form of a list ⁇ k (1), k (l) ⁇ indices i of these blocks (determined for example by random draw) and the checking words M ,, M * can then be determined by concatenating the blocks concerned:
  • M F (n, Ck (i)
  • the secure electronic entity E sends in step E44 the verification value M * determined in step E42, as evidence of the integrity of the modifiable operating system FOS (or part of it) to the third party auditor TP.
  • the third party auditor TP can thus compare in step E48 the verification value M, determined by him (step E28 or E40) to the verification value M * received from the secure electronic entity E.
  • the modifiable operating system FOS stored in the secure electronic entity E corresponds to that expected and the third party auditor TP can wait a predetermined time (time of the step E50) before increment the index i (step E52) and loop in step E36 (or E34 according to the variant mentioned above) to check again the integrity of the modifiable operating system FOS.
  • the modifiable operating system FOS (or, in general, the memory area covered by the verification) has been modified and the third party auditor TP for example sends an alert message to the destination. of the ISS transmitter (step E54).
  • the ISS issuer On receipt of this alert message, the ISS issuer for example takes steps to disable the secure electronic entity, such as the revocation of certificates stored in the secure electronic entity (step E56).
  • FIG. 8 represents the main steps of a third exemplary method implemented in the context of the invention.
  • the issuer ISS transmits an IM memory image to the secure electronic entity E.
  • This IM memory image contains all the data and instructions to be stored in the non-volatile memory NV of the secure electronic entity E to enable its operation.
  • the secure electronic entity E receives the memory image IM at the step E102 and stores it in its non-volatile memory NV.
  • the secure electronic entity is then ready to be used for the functionality for which it is designed, for example as a means of payment, means of access to a mobile telephone network, means of identification, etc.
  • the steps E100 and E102 can be performed in the context of FIG. 1, in which case a mechanism for securing the exchanges is previously implemented between the issuer ISS and the secure electronic entity E in order to perform the personalization remotely.
  • the steps E100 and E102 can be performed within an establishment dedicated to the personalization of secure electronic entities, in which case the secure electronic entity E communicates (via a wired link or short-range wireless or other) with a ISS transmitter customization machine (the personalization machine then implementing step E100).
  • the memory image IM is secured by the issuer ISS, for example by encryption using a cryptographic algorithm using a SECST cryptographic key, which makes it possible to obtain a secure version (here encrypted ) IMSEC of the IM memory image.
  • the issuer ISS may optionally further generate a signature or authentication code (or MAC for "Message Authentication Code") of the memory image IM.
  • the secure memory image IMSEC and the cryptographic key SECST (and possibly the signature or the authentication code) are emitted by the issuer ISS in step E106, for the third party auditor TP.
  • the SECST cryptographic key being a secret shared between the issuer ISS and the third party auditor TP (or, alternatively, between the issuer ISS and a hardware security module held by the third party auditor TP), it is transmitted using a mechanism preventing its disclosure, for example by means of a secure channel established between the issuer ISS and the third party auditor TP.
  • the third party listener TP receives and stores in step E108 the secure memory image IMSEC and the cryptographic key SECST (and possibly the signature or the authentication code).
  • the cryptographic key SECST is for example stored in a hardware security module (or HSM for "Hardware Security Module") of the issuer ISS, for example a microcircuit card or an integrated secure element.
  • the third party listener generates a secret SECINT (for example by random draw) and memorizes this SECINT secret, for example within the hardware security module mentioned above.
  • the secret SECINT generated in step E1 is transmitted to the secure electronic entity E, for example by means of a secure communication channel established between the third party auditor TP and the secure electronic entity E, then stored in the memory.
  • secure electronic entity E (step E1 12), for example in an area of the non-volatile memory NV not covered by the integrity check.
  • the secret SECINT is generated by the third party auditor TP.
  • the secret SECINT could be generated by the issuer ISS, transmitted to the third party auditor ISS (for example during the step E106 described above) and stored in the secure electronic entity E during the customization (for example in step E102 described above).
  • the third party auditor TP can then check the integrity of parts of the memory image IM stored in non-volatile memory NV, as now described.
  • the third party listener TP generates in step E1 14 an unpredictable (ordered) list L of regions of the memory area whose integrity is to be checked, here the non-volatile memory NV (which contains in normal operation the IM memory image received and stored in step E102).
  • Each region of the list L is here defined by an address, which designates the beginning of the region concerned (that is to say, for example, the first byte of the region concerned), and by a length (expressed for example in number of words bits, here in number of bytes).
  • the address and the length defining this region are for example determined by random draw.
  • certain particular parts of the memory concerned in this case the non-volatile memory NV
  • parts containing instructions or critical or sensitive data are more frequently targeted by the regions of the list.
  • certain addresses are determined by random selection among the addresses located in these particular parts of the memory concerned, while other addresses are determined by random selection among all the possible addresses for the memory concerned.
  • the list of regions could be predetermined (while still preferably unpredictable).
  • the third party auditor TP may indeed in practice use a large number of predetermined lists so that the secure electronic entity E will not be able to memorize the expected response (VALINT integrity value mentioned below) to each of these lists.
  • the third party listener TP can choose the list L by random draw among a large number of predetermined lists.
  • the number of regions listed in the list L can be fixed or variable, for example determined by random draw between a minimum value and a maximum value.
  • the third party auditor TP then sends in step E1 16 the list L (generated in step E1 14) to the secure electronic entity E.
  • the unpredictable list L is received by the secure electronic entity E in step E1 18.
  • the secure electronic entity E then builds in step E120 a byte structure by reading the bytes stored in the memory regions (here non-volatile memory NV) designated in the list L received, for example by concatenation of the bytes read in the regions of the list L.
  • a byte structure by reading the bytes stored in the memory regions (here non-volatile memory NV) designated in the list L received, for example by concatenation of the bytes read in the regions of the list L.
  • the secure electronic entity E can thus determine in step E122 a value of integrity VALINT (OR verification value) by applying a function f to the byte structure produced in step E120, using here in besides the secret SECINT-
  • the function f is for example a cryptographic function of signature or generation of message authentication code using as the cryptographic key the secret SECINT and as a message (to sign or to authenticate) the aforementioned byte structure.
  • the function f can be of one of the types proposed above (in the context of the first two exemplary embodiments) for the function F.
  • the function f is applied considering the raw form of the bytes (here bytes) of the structure, regardless of what these multiplets represent when using the electronic entity secure E
  • the function f can optionally use other parameters (for example a random value) which are in this case transmitted from the third party auditor TP to the secure electronic entity E with the list L in step E1 16, or as a variant of the secure electronic entity E to the third party auditor TP with the integrity value VALINT in step E124 (described below).
  • These other parameters comprise for example an initialization vector used by the function f (especially when the function f is of CBC-MAC type).
  • the integrity value VALINT calculated by the secure electronic entity E in step E122 is transmitted to the third party auditor TP during step E124.
  • the third party listener TP receives and stores this integrity value VALINT in step E126.
  • the third party listener TP then proceeds to read in the secure memory image IM S EC the parts corresponding to the regions of the list L and the decryption of these parts read by means of the cryptographic key SECST (step E128).
  • the decryption is performed by the hardware security module (within it) so that the third party listener TP is not aware of the decrypted versions.
  • the third party auditor TP may on this occasion possibly carry out the verification of the signature or the associated authentication code, when such an element has been transmitted during the step E106 as mentioned above.
  • the third party auditor TP (or, alternatively, the hardware security module held by the third party auditor TP) can thus produce in step E130 a byte structure from the bytes contained in the decrypted parts, according to the process used by the secure electronic entity E in step E120, here by concatenation of these bytes.
  • the data structure obtained in step E130 is normally (that is to say, in normal operation, without modification of the memory image IM) identical to that obtained in step E120.
  • the third party auditor TP determines in step E132 a value of integrity VALINT * from the byte structure obtained in the step E130, according to the same process as that used in step E122, that is, by applying the function f to this byte structure produced in step E130, again using here the secret SECINT-
  • the third party auditor TP (or, alternatively, the hardware security module held by the third party auditor TP) can thus check in step E1 34 whether the value of integrity VALINT calculated by the secure electronic entity E is indeed equal to the integrity value VALINT * calculated in step E1 32.
  • a message indicative of the result of the comparison is transmitted from the hardware security module to the third party auditor TP.
  • the memory image IM stored in the non-volatile memory NV of the secure electronic entity E has not been altered and the secure electronic entity E can therefore continue to be used normally.
  • the method therefore continues in this case by a delay step E1 36, before the implementation of a new iteration of the verification of the integrity of the memory image IM from step E1 14 as described herein. -above.
  • step E134 If the verification of step E134 is negative, the process continues on the contrary in step E1 38 during which an action is set up to deal with the lack of integrity of the memory image thus detected.
  • This action is for example the transmission (not represented in FIG. 8) of a message indicating this lack of integrity to the issuer ISS, which can then, for example, revoke the rights associated with the secure electronic entity E or alternatively, requiring a remote update of the memory image of the NV nonvolatile memory.
  • the integrity verification iteration described above only makes it possible to verify the integrity of the data contained in the regions of the list L used during this iteration. However, as iterations proceed, a larger part of the memory concerned will have been verified. Note further that the secure electronic entity E can not predict the regions used during a given iteration and can not anticipate the integrity value transmitted in response to the third party auditor TP.
  • Figure 9 shows the main steps of a fourth example of process implemented in the context of the invention.
  • the third party listener TP stores a derived memory image IM D ER obtained from the memory image IM (stored in the non-volatile memory NV of the secure electronic entity E), for example at means of an encryption cryptographic algorithm (such as an ECB type algorithm as mentioned above).
  • an encryption cryptographic algorithm such as an ECB type algorithm as mentioned above.
  • the secure electronic entity E stores the encryption cryptographic key used to obtain the IMDER derivative memory image.
  • the third party listener TP generates in step E200 an unpredictable (ordered) list L of regions of the memory area whose integrity is to be checked, here the non-volatile memory NV.
  • each region of the list L is here defined by an address and by a length.
  • the list L of the regions is generated according to one of the possibilities envisaged above in the context of the third exemplary embodiment.
  • the third party auditor TP issues the list L to the secure electronic entity E (step E202) and the unpredictable list L is therefore received by the secure electronic entity E in step E204.
  • the secure electronic entity E then reads the stored data (in the form of bytes, here bytes) in the regions designated in the list L and generates in step E206 corresponding derived data, by applying the algorithm used to obtain the IMDER derived image stored by the third party auditor TP as indicated above (here an encryption algorithm, for example of the EBC type, using the encryption cryptographic key stored by the secure electronic entity E).
  • the algorithm used to obtain the IMDER derived image stored by the third party auditor TP here an encryption algorithm, for example of the EBC type, using the encryption cryptographic key stored by the secure electronic entity E).
  • the electronic entity then builds in step E208 a structure of data to be processed (or byte structure) using the derived data obtained in step E206, for example by concatenation of these derived data.
  • the secure electronic entity E can thus determine in step E210 a value of integrity VALINT (OR verification value) by applying a function f to the data structure produced in step E208, for example by using in addition to a SECINT secret shared between the secure electronic entity E and the third party auditors TP, as in the third example described with reference to FIG. 8.
  • the function f can be of one of the types proposed above (in the framework of the first three examples of implementation).
  • the integrity value VALINT calculated by the secure electronic entity E in step E210 is transmitted to the third party auditor TP during step E21 2 and received by it in step E214, which stores it.
  • the third party listener TP then proceeds to read the parts corresponding to the regions of the list L in the derived memory image IM D ER and produces in a step E216 a data structure from the read data, according to the process used by the secure electronic entity E in step E208, here by concatenation of the read data.
  • the data structure obtained in step E21 6 is normally (that is to say, in normal operation, without modification of the memory image IM) identical to that obtained in step E208.
  • the third party listener TP determines in step E21 8 a value of integrity VALINT * from the data structure obtained in step E21 6, according to the same process as that used in step E21 0, c ' that is, by applying the function f to this data structure produced in step E21 6, again using the shared secret SECINT-
  • the third party auditor TP can thus verify in step E220 whether the value of integrity VALINT calculated by the secure electronic entity E is equal to the value of integrity VALINT * calculated in step E21 8.
  • step E222 the memory image IM stored in the non-volatile memory NV of the secure electronic entity E has not been altered and the secure electronic entity E can therefore continue to be used normally (step E222) .
  • step E220 If the verification of the step E220 is negative, the process continues on the contrary at the step E224 during which an action is put in place to to treat the lack of integrity of the IM memory image thus detected.
  • This action is of the same type as that of step E138 described above with reference to FIG. 8.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne une entité électronique sécurisée (E) comprenant une mémoire (NV) mémorisant des données sous forme de multiplets et un module de traitement (M) conçu pour recevoir des données en provenance d'un dispositif électronique (TP). Le module de traitement (M) est conçu pour déterminer un élément de preuve d'intégrité en fonction des données reçues et d'une partie au moins des multiplets mémorisés, et pour émettre l'élément de preuve d'intégrité à destination du dispositif électronique (TP). Un procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée (E) est également décrit.

Description

Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne la vérification de l'intégrité de données mémorisées dans une entité électronique sécurisée.
Elle concerne plus particulièrement une entité électronique sécurisée, un appareil électronique et un procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée.
L'invention s'applique particulièrement avantageusement dans le cas où les données mémorisées sont au moins en partie secrètes et doivent donc être chiffrées lorsqu'elles sont mémorisées en dehors de l'entité électronique sécurisée.
ARRIERE-PLAN TECHNOLOGIQUE
On connaît des entités électroniques sécurisées, telles que des cartes à microcircuit ou des éléments sécurisés intégrés, qui mémorisent des données confidentielles, par exemple des clés cryptographiques secrètes, utilisées par exemple dans des applications de chiffrement de message électronique, de signature électronique ou d'identification.
Bien que ces entités électroniques sécurisées soit conçues pour rendre quasiment impossible toute intrusion dans leur fonctionnement, il est souhaitable de vérifier de temps à autre, par exemple périodiquement, que les données mémorisées dans une entité électronique donnée sont intègres (c'est-à-dire qu'elles n'ont pas été altérées).
OBJET DE L'INVENTION
Dans ce contexte, la présente invention propose une entité électronique sécurisée comprenant une mémoire mémorisant des données sous forme de multiplets et un module de traitement conçu pour recevoir des données en provenance d'un dispositif électronique, caractérisée en ce que le module de traitement est conçu pour déterminer un élément de preuve d'intégrité en fonction des données reçues et d'une partie au moins des multiplets mémorisés, et pour émettre l'élément de preuve d'intégrité à destination du dispositif électronique.
Ainsi, l'entité électronique sécurisée est conçue pour renvoyer un élément de preuve d'intégrité déterminé par combinaison des données reçues et des multiplets mémorisés. Un tel élément de preuve permet d'attester que les données mémorisées (sous forme de multiplets) au moment où l'entité électronique reçoit les données en provenance du dispositif électronique extérieur (par exemple un auditeur tiers) sont bien celles attendues, sans quoi l'entité électronique sécurisée ne pourrait pas produire l'élément de preuve correct.
Selon des caractéristiques optionnelles (et donc non limitatives) :
- les données reçues représentent une valeur aléatoire (générée par exemple par le dispositif électronique) ;
- les données reçues désignent des régions de la mémoire ;
- le module de traitement est conçu pour déterminer l'élément de preuve d'intégrité en fonction des multiplets mémorisés dans les régions désignées par les données reçues ;
- le module de traitement est conçu pour déterminer l'élément de preuve d'intégrité en partie au moyen (c'est-à-dire au moyen notamment) d'un chiffrement des multiplets mémorisés ;
- l'entité électronique sécurisée comprend un module de mise en œuvre du chiffrement en fonction d'une clé secrète mémorisée dans l'entité électronique ;
- le module de traitement est conçu pour déterminer l'élément de preuve d'intégrité au moyen d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message ;
- ladite entité électronique sécurisée est une carte d'accès à un réseau de téléphonie mobile.
L'invention propose également un téléphone cellulaire comprenant une entité électronique sécurisée telle que proposée ci-dessus, par exemple soudée au téléphone cellulaire.
L'invention propose aussi un compteur de fourniture d'énergie comprenant une entité électronique sécurisée telle que proposée ci-dessus, par exemple soudée audit compteur.
L'invention propose par ailleurs un système électronique embarqué pour véhicule (par exemple pour véhicule automobile) comprenant une entité électronique sécurisée telle que proposée ci-dessus, éventuellement soudée au système électronique.
L'invention propose en outre un appareil électronique comprenant un module de communication en champ proche et une entité électronique sécurisée telle que proposée ci-dessus reliée au module de communication en champ proche.
L'invention propose également un procédé de vérification de l'intégrité de données mémorisées dans une entité électronique sécurisée, caractérisé en ce qu'il comprend les étapes suivantes :
- émission, par un dispositif électronique, de données à destination de l'entité électronique sécurisée ;
- réception des données par l'entité électronique sécurisée ;
- détermination d'un élément de preuve d'intégrité en fonction des données reçues et d'une partie au moins des multiplets mémorisés dans une mémoire de l'entité électronique sécurisée ;
- émission, par l'entité électronique sécurisée, de l'élément de preuve d'intégrité à destination du dispositif électronique.
Un tel procédé peut comprendre en outre une étape de détermination d'une partie au moins des données émises par tirage aléatoire (par exemple au sein du dispositif électronique).
Selon une première possibilité de réalisation, les données reçues peuvent représenter une valeur aléatoire utilisée en tant que paramètre lors de l'application d'une fonction.
Selon une seconde possibilité de réalisation, les données reçues peuvent désigner des régions de la mémoire ; la détermination de l'élément de preuve d'intégrité peut dans ce cas être réalisée en fonction des multiplets mémorisés dans les régions désignées par les données reçues.
Selon d'autres caractéristiques optionnelles :
- la détermination de l'élément de preuve d'intégrité comprend un chiffrement des multiplets mémorisés ;
- le chiffrement des multiplets mémorisés utilise une clé secrète mémorisée dans l'entité électronique sécurisée ;
- l'élément de preuve d'intégrité est déterminé par application d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message ;
- ledit dispositif électronique est un auditeur tiers.
DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
Sur les dessins annexés :
- la figure 1 représente un système dans lequel est utilisée une entité électronique sécurisée conforme à l'invention ;
- la figure 2 représente schématiquement les informations mémorisées dans un serveur d'un auditeur tiers et dans une mémoire non volatile de l'entité électronique sécurisée conformément à un premier mode de réalisation de l'invention ;
- la figure 3 représente les étapes principales d'un premier exemple de procédé mis en œuvre dans le cadre de l'invention ;
- la figure 4 représente les étapes principales d'un second exemple de procédé mis en œuvre dans le cadre de l'invention ;
- les figures 5 à 7 représentent schématiquement des algorithmes utilisables dans le cadre du procédé de la figure 4 ;
- la figure 8 représente les étapes principales d'un troisième exemple de procédé mis en œuvre dans le cadre de l'invention ; et
- la figure 9 représente les étapes principales d'un quatrième exemple de procédé mis en œuvre dans le cadre de l'invention.
La figure 1 représente schématiquement les éléments principaux d'un système dans lequel peut être mise en œuvre l'invention.
Un tel système comprend un appareil électronique A pourvu d'un module de communication COM afin d'échanger des données avec d'autres dispositifs électroniques, comme décrit ci-après.
L'appareil électronique A peut être un téléphone cellulaire et/ou intelligent (en anglais : "smartphone"), une tablette numérique ou tout autre appareil électronique dont on souhaite qu'il puisse échanger des données avec des dispositifs électroniques extérieurs, par exemple un compteur de fourniture d'énergie, un appareil électroménager ou un système électronique embarqué dans un véhicule automobile.
Le module de communication COM permet d'établir une communication bidirectionnelle (ici sans fil) avec une architecture de réseau N, qui est elle-même connectée au réseau Internet INT.
Selon une première possibilité de réalisation, l'architecture de réseau N peut être un réseau de téléphonie mobile, auquel cas le module de communication COM est conçu pour entrer en communication avec une station de base du réseau de téléphonie mobile.
Selon une seconde possibilité de réalisation, l'architecture de réseau N peut être un point d'accès d'un réseau local sans fil ou WLAN (pour "Wireless Local Area Network"), auquel cas le module de communication COM est conçu pour rejoindre ce réseau local.
Dans les deux cas, le module de communication COM permet d'accéder au réseau Internet INT à travers l'architecture de réseau N.
Ainsi, un processeur P de l'appareil électronique A (par exemple un microprocesseur) relié au module de communication COM peut échanger des données avec des dispositifs électroniques (tels que des ordinateurs ou des serveurs) connectés au réseau Internet, notamment un auditeur tiers (ou TPA pour "Third Party Auditor") TP et un émetteur d'entités électroniques ISS.
L'appareil électronique A comprend également une entité électronique sécurisée E, par exemple une carte à microcircuit, éventuellement universelle (ou UICC pour "Universal Integrated Circuit Card') telle que visée dans la spécification technique ETSI TS 102 221 , un élément sécurisé intégré (ou eSE pour "embedded Secure Elément') tel que visé dans la spécification "GlobalPIatform Card Spécification version 2.2.1" ou un autre type d'élément sécurisé.
Dans le cas où l'entité électronique sécurisée E est une carte à microcircuit, il peut s'agir par exemple d'une carte d'accès à un réseau de téléphonie mobile, tel qu'une carte de type USIM (pour "Universal Subscriber Identity Module"), ou d'un jeton sécurisé (en anglais : "secure token").
L'entité électronique sécurisée E peut être montée dans l'appareil A de manière amovible (comme c'est le cas pour une carte à microcircuit réalisée selon l'un des formats 2FF, 3FF ou 4FF, ou, de manière générale, selon un format de dimensions inférieures à celles du format 2FF), ou de manière inamovible (par exemple soudée) comme dans le cas d'un élément sécurisé intégré (eSE déjà mentionné ci-dessus) ou une carte à microcircuit intégré (également dénommée eUICC pour "embedded Universal Integrated Circuit Card").
L'entité électronique sécurisée E est ici reliée au processeur P de l'appareil électronique A et a ainsi accès, via ce processeur P, au module de communication COM. En variante, l'entité électronique sécurisée E pourrait être directement reliée au module de communication COM.
Comme illustré en figure 1 , l'entité électronique sécurisée comprend elle- même un microprocesseur M, une mémoire vive V et au moins une mémoire non- volatile NV, par exemple une mémoire non volatile réinscriptible de type EEPROM (pour "Electrically Erasable and Programmable Read-Only Memory") ou Flash.
La mémoire non-volatile NV mémorise des instructions de programme d'ordinateur qui, lorsqu'elles sont exécutées par le microprocesseur M, permettent la mise en œuvre de procédés, tels que les procédés donnés ci-dessous à titre d'exemple.
L'entité électronique sécurisée E mémorise également des données, notamment des données confidentielles telles que des clés secrètes (par exemple notamment les clés cryptographiques Κι , K2 utilisées dans les exemples donnés ci-dessous).
L'entité électronique sécurisée E peut ainsi mettre en œuvre (comme déjà indiqué, du fait de l'exécution, par son microprocesseur M, d'instructions mémorisées dans la mémoire non-volatile NV, voire dans la mémoire vive V) un procédé de chiffrement au moyen d'une clé cryptographique et/ou un procédé de déchiffrement au moyen d'une clé cryptographique et/ou un procédé de signature au moyen d'une clé cryptographique et/ou un procédé de génération d'un code d'authentification utilisant une donnée secrète et/ou un procédé de génération d'une réponse à un défi par utilisation d'une donnée secrète
Pour chacun de ces procédés, la clé cryptographique ou la donnée secrète concernée est par exemple mémorisée dans la mémoire non-volatile NV.
Dans certains cas, comme le cas déjà mentionné d'une carte à microcircuit universelle ou UICC, l'entité électronique sécurisée E peut également mettre en œuvre des procédés d'initiation et d'établissement d'une communication distante via le module de communication COM implanté dans l'appareil électronique A qui héberge l'entité électronique sécurisée E, par exemple au moyen de mécanismes tels que ceux communément désignés "SIM Toolkits". L'entité électronique sécurisée E peut alors avoir l'initiative du lancement d'un échange avec des dispositifs électroniques distants, tels que l'auditeur tiers TP et l'émetteur ISS.
Les instructions de programme et les données sont mémorisées (ici dans la mémoire non-volatile NV) sous forme de multiplets (par exemple d'octets). L'entité électronique sécurisée E est par ailleurs conçue, du fait de sa construction physique et de la conception des programmes d'ordinateur qu'elle mémorise, de façon à rendre très difficile, voire impossible, pour un attaquant l'accès (par lecture et/ou modification) aux données confidentielles qu'elle mémorise. Ainsi, l'entité électronique sécurisée E a par exemple un niveau d'assurance EAL supérieur à 4 au sens des Critères Communs (norme ISO15408), par exemple une niveau EAL4+ (VAN5) ou supérieur, et/ou un niveau supérieur à 3 selon la norme FIPS 140-2 (pour "Fédéral Information Processing Standard').
L'appareil électronique A peut également comprendre un module de communication en champ proche COM', tel qu'un module de communication NFC (pour "Near Field Communication"). En variante, on pourrait utiliser un module de communication sans fil d'un autre type, par exemple Bluetooth, ZigBee, ou autre. Un tel module de communication en champ proche COM' est ici directement relié à l'entité électronique sécurisée E, par exemple au moyen d'une liaison de type SWP (pour "Single Wire Protocof). En variante, le module de communication en champ proche COM' pourrait être relié au processeur P de l'appareil électronique A et pourrait dans ce cas échanger des données avec l'entité électronique sécurisée E via le processeur P.
Le module de communication en champ proche COM' est conçu pour entrer en communication avec un lecteur (ici un lecteur NFC) lorsque ce module COM' (de même que par conséquent l'appareil électronique A) est positionné à une distance du lecteur inférieure à un seuil prédéterminé, par exemple un seuil inférieur à 0,3 m.
Le lecteur et l'entité électronique sécurisée E peuvent ainsi échanger des données selon un protocole de communication sans fil, par exemple selon la norme ISO 14443. En particulier, le lecteur peut émettre des commandes (telles que des commandes de type ADPU pour "Application Protocol Data Unit") via la liaison sans fil ; le module de communication en champ proche COM' reçoit ces commandes et les transmet à l'entité électronique sécurisée E (ici via la liaison SWP). L'entité électronique sécurisée E traite ces commandes (au moyen notamment des procédés mis en œuvre dans l'entité électronique sécurisée comme décrit ci-dessus) et émet des réponses (générées par le traitement précité) via le module de communication en champ proche COM' et à destination du lecteur.
L'appareil électronique A peut ainsi notamment être utilisé, grâce aux données confidentielles mémorisées dans l'entité électronique sécurisée E et aux possibilités d'échanges fournies par le module de communication en champ proche COM', comme moyen d'identification de son porteur, par exemple dans des applications de paiement (autorisation de paiement), de transport (accès au réseau de transport via un portillon automatique commandé par le lecteur), d'identité, de fidélité, etc.
On décrit à présent un premier mode de réalisation de l'invention en référence aux figures 2 et 3.
Comme visible en figure 2, dans ce premier mode de réalisation, la mémoire non-volatile NV de l'entité électronique sécurisée E mémorise d'une part un système d'exploitation fixe ROS et un système d'exploitation modifiable FOS.
Le système d'exploitation fixe ROS est inscrit dans la mémoire non- volatile NV lors de la production de l'entité électronique sécurisée E, par exemple lors d'une phase de personnalisation au cours de laquelle des instructions de programme et des données de personnalisation sont écrites dans la mémoire non- volatile NV, ici sans possibilité de modification ultérieure.
Le système d'exploitation modifiable FOS est également inscrit dans la mémoire non-volatile NV lors de la phase de personnalisation, mais peut être modifié ultérieurement, par exemple à distance selon une procédure prédéfinie au cours de laquelle le microprocesseur M de l'entité électronique sécurisée E entre en communication avec un serveur distant (par exemple via le module de communication COM) et écrit dans la mémoire non-volatile NV des données reçues du serveur distant, par exemple après une étape d'authentification du serveur distant. Selon une variante envisageable, un tel système d'exploitation pourrait être chargé en mémoire vive pour son exécution.
Comme également visible en figure 2 , l'auditeur tiers TP mémorise une pluralité de valeurs aléatoires n , rn et une pluralité de valeurs de vérification Mi , Mn respectivement associées aux valeurs aléatoires précitées. Les valeurs de vérification M, ne sont pas communiquées à l'entité électronique sécurisée E. Les valeurs aléatoires η sont successivement communiquées à l'entité électronique sécurisée E, de façon répartie sur la durée d'utilisation de l'entité électronique sécurisée E, comme expliqué ci-après. On utilise par exemple un nombre n de valeurs aléatoires n (et de valeurs de vérification M, associées) tel que l'entité électronique sécurisée E ne puisse pas mémoriser l'ensemble de ces valeurs η, M,.
Par exemple, lors d'une phase d'évaluation du système d'exploitation modifiable FOS au cours de laquelle l'auditeur tiers TP a connaissance des données formant le système d'exploitation modifiable FOS, il détermine successivement par tirage aléatoire chacune des valeurs aléatoires η et calcule la valeur de vérification associée M, par application d'une fonction F à cette valeur aléatoire η et aux données qui forment le système d'exploitation modifiable FOS :
Mi = F(n,FOS).
La fonction F est telle qu'il est impossible de déterminer F(n,FOS) sans avoir connaissance de l'ensemble des données formant le système d'exploitation modifiable FOS et que les valeurs de vérification M, ne donnent aucune information sur les données formant le système d'exploitation modifiable FOS.
La fonction F est par exemple basée sur une fonction de hachage H, appliquée à la concaténation de la valeur aléatoire n et des données formant le système d'exploitation modifiable FOS : F(n,FOS) = Η(η || FOS), où || est l'opérateur de concaténation. La fonction de hachage H utilisée est par exemple de type SHA-256, SHA-512 ou SHA-3.
En variante, la fonction F pourrait être une fonction MAC de génération de code d'authentification de message, utilisant une clé secrète K2 et, ici encore, appliquée par exemple à la concaténation de la valeur aléatoire η et des données formant le système d'exploitation modifiable FOS : F(n,FOS) = MAC(K2,n || FOS). La fonction MAC utilisée est par exemple de type HMAC (basé par exemple sur SHA-256), CMAC ou CBC-MAC (basé par exemple sur l'algorithme AES).
Dans le cas de l'utilisation d'une fonction de génération de code d'authentification de message, la clé secrète K2 est mémorisée par l'auditeur tiers TP pour effectuer le calcul des valeurs de vérification M, comme il vient d'être indiqué et par l'entité électronique sécurisée E pour le calcul d'un élément de preuve comme expliqué plus bas. Selon une variante envisageable, on pourrait utiliser (plutôt qu'un code d'authentification de message) une signature produite au moyen d'une clé privée d'une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure").
On remarque que, pour l'application de la fonction F, on considère la forme brute des multiplets mémorisés dans la zone concernée (notamment les données formant le système d'exploitation modifiable FOS), indépendamment de ce que représentent ces multiplets lors de l'utilisation de l'entité électronique sécurisée E (les multiplets pouvant par exemple représenter comme déjà indiqué des instructions exécutables par le microprocesseur M, des données de personnalisation, des données confidentielles telles que des clés secrètes, voire des données non utilisées).
La figure 3 représente un procédé d'échange de données entre l'auditeur tiers TP et l'entité électronique sécurisée E afin de vérifier que le système d'exploitation modifiable FOS est bien conforme à celui qui a été évalué (par exemple en vue de sa certification) dans la phase d'évaluation. On comprend qu'après cette phase d'évaluation, l'auditeur tiers TP n'a généralement plus accès au système d'exploitation modifiable FOS.
Cet échange de données entre l'auditeur tiers TP et l'entité électronique sécurisée E est par exemple réalisé via le réseau Internet INT, l'architecture de réseau N, le module de communication COM et le processeur P de l'appareil électronique A, comme expliqué ci-dessus en référence à la figure 1 .
Le procédé débute à l'étape E2 par l'émission par l'auditeur tiers TP de l'un des nombres aléatoires n à destination de l'entité électronique sécurisée. Une telle étape est par exemple mise en œuvre périodiquement.
Selon une première possibilité de réalisation, le nombre aléatoire n émis lors de l'étape E2 est choisi aléatoirement parmi la pluralité de nombres aléatoires n , rn mémorisés dans l'auditeur tiers TP (ce qui peut être réalisé en pratique en déterminant par tirage aléatoire, parmi les entiers compris entre 1 et n, l'indice i utilisé). Selon une seconde possibilité de réalisation, les nombres aléatoires n , rn sont utilisés séquentiellement, l'un après l'autre.
L'entité électronique sécurisée E reçoit le nombre aléatoire n à l'étape
E4.
L'entité électronique sécurisée E (en pratique son microprocesseur M, qui utilise pour ce faire la mémoire vive V) détermine alors à l'étape E6 la valeur de vérification associée au nombre aléatoire n reçu, selon le même processus que celui utilisé par l'auditeur tiers TP lors de la phase d'évaluation, ici par application de la fonction F au nombre aléatoire reçu n et aux données formant le système d'exploitation modifiable FOS. On note M* la valeur de vérification ainsi calculée par l'entité électronique sécurisée :
M* = F(n,FOS).
La valeur de vérification calculée M* est envoyée à l'auditeur tiers TP à l'étape E8 en tant qu'élément de preuve visant à attester que le système d'exploitation modifiable FOS n'a pas été modifié.
L'auditeur tiers TP reçoit la valeur de vérification M* à l'étape E10 et la compare à l'étape E12 à celle calculée lors de la phase d'évaluation.
Du fait des propriétés de la fonction F indiquées ci-dessus, si la valeur de vérification M* calculée par l'entité électronique sécurisée E est égale à la valeur de vérification M, mémorisée par l'auditeur tiers TP, l'image mémoire correspondant au système d'exploitation modifiable FOS est bien celle attendue et le fonctionnement de l'entité électronique sécurisée peut continuer normalement (étape E16).
Au contraire, si la valeur de vérification M* calculée par l'entité électronique sécurisée E diffère de la valeur de vérification M, mémorisée par l'auditeur tiers TP, ceci signifie que le système d'exploitation modifiable FOS n'est pas conforme à celui qui a été évalué. On procède dans ce cas à l'étape E14 à laquelle on traite le problème rencontré, par exemple en émettant un message à destination de l'émetteur ISS de l'entité électronique sécurisée E, lequel peut par exemple révoquer les droits associés à l'entité électronique sécurisée E.
On remarque que, la valeur n n'étant pas prévisible, l'entité électronique sécurisée E ne peut pas calculer et mémoriser au préalable la valeur de vérification M, associée (ce qui permettrait à l'entité électronique sécurisée E de renvoyer la valeur attendue même si le système d'exploitation FOS était ensuite modifié). Autrement dit, les données du système d'exploitation FOS mémorisées dans la mémoire non-volatile NV lors de la réception de la valeur imprévisible (ici aléatoire) η doivent être conformes à celles présentes lors de la phase d'évaluation pour que l'entité électronique sécurisée E puisse calculer une valeur de vérification M* égale à la valeur attendue M,.
On remarque en outre que l'ensemble des données mémorisées dans la zone modifiable de la mémoire non-volatile NV (zone où est mémorisé le système d'exploitation modifiable FOS) est utilisé dans le calcul de chaque valeur de vérification M, afin que l'entité électronique sécurisée E ne puisse pas mémoriser une copie du système d'exploitation modifiable qui lui permettrait de calculer une valeur de vérification M, correcte même après modification (non autorisée) du système d'exploitation modifiable FOS.
Enfin, comme indiqué ci-dessus, l'entité électronique sécurisée E ne peut pas mémoriser l'ensemble des valeurs aléatoires n et de vérification M,, et ne peut donc pas répondre à l'auditeur tiers TP en utilisant une valeur de vérification déterminée à un moment antérieur puis mémorisée (ce qui lui permettrait d'apporter des modifications au système d'exploitation modifiable FOS après avoir traité l'ensemble des valeur aléatoires η , rn et mémorisé les valeurs de vérification Mi, Mn associées).
On décrit à présent un second mode de réalisation de l'invention en référence à la figure 4. Ce mode de réalisation concerne également le cas où un système d'exploitation modifiable FOS mémorisé dans la mémoire non-volatile NV d'une entité électronique sécurisée E est vérifié par un auditeur tiers TP, comme schématiquement représenté en figure 2.
Dans ce second mode de réalisation, l'auditeur tiers TP n'a toutefois à aucun moment connaissance (en clair) des données formant le système d'exploitation modifiable FOS, mais ne dispose que d'une version chiffrée C de ces données, comme expliqué à présent. On remarque que l'on peut toutefois prévoir, lorsque l'auditeur tiers TP a également un rôle de certificateur, que la version chiffrée C des données soit générée pendant un phase initiale d'audit, sous la surveillance du certificateur.
La figure 4 représente les étapes principales d'un second exemple de procédé mis en œuvre dans le cadre de l'invention.
Ce procédé débute ainsi à l'étape E20 par une étape de chiffrement des données formant le système d'exploitation modifiable FOS par l'émetteur ISS de l'entité électronique sécurisée ISS. Cette étape de chiffrement est par exemple réalisée en appliquant aux données formant le système d'exploitation modifiable FOS un algorithme de chiffrement (ici symétrique) ENC utilisant une clé secrète Ki mémorisée par l'émetteur ISS et par l'entité électronique sécurisée E (et connue seulement de ces deux entités).
Dans le cadre de son chiffrement, le système d'exploitation modifiable FOS est par exemple découpé en blocs ordonnés FOSj de taille prédéterminée (ici de 16 octets).
Selon une première possibilité de réalisation, l'algorithme de chiffrement ENC est de type CBC (pour "Cipher Block Chaining") et est appliqué comme représenté en figure 5 : le premier bloc FOSi est combiné à un vecteur d'initialisation IV (prédéterminé ou déterminé lors du calcul, par exemple par tirage aléatoire) par application d'un opérateur "ou exclusif (ou XOR), c'est-à-dire par somme booléenne, puis on applique un algorithme de chiffrement AES avec la clé secrète Ki au résultat de la combinaison afin d'obtenir le premier bloc chiffré Ci ; pour les autres blocs de données du système d'exploitation modifiable FOS, on combine le bloc concerné FOSj et le bloc chiffré précédent Cj_i au moyen d'une opération de "ou exclusif (somme booléenne), puis on applique l'algorithme de chiffrement AES avec la clé secrète Ki au résultat de la combinaison afin d'obtenir la version chiffrée Cj du bloc courant.
Selon une seconde possibilité de réalisation, l'algorithme de chiffrement ENC est de type ECB (pour "Encoded CodeBook") et est appliqué comme représenté en figure 6 : un algorithme de chiffrement AES utilisant la clé de chiffrement Ki est appliqué séparément à chaque bloc FOSj afin d'obtenir la version chiffrée Cj du bloc concerné.
Selon une troisième possibilité de réalisation, l'algorithme de chiffrement est de type CTR (de l'anglais "courtier" : compteur) : un compteur incrémenté de bloc en bloc est chiffré au moyen d'un algorithme de chiffrement, tel que l'algorithme de chiffrement AES, utilisant une clé secrète (par exemple la clé Ki) ; la version chiffrée Cj du bloc concerné est obtenue par somme booléenne du bloc FOSj correspondant et du compteur chiffré.
Quelle que soit la possibilité de réalisation utilisée, la concaténation des blocs chiffrés Cj obtenus forme la version chiffrée C du système d'exploitation modifiable FOS.
La version chiffrée C du système d'exploitation modifiable FOS obtenue à l'étape E20 est envoyée à l'étape E22 à l'auditeur tiers TP.
L'auditeur tiers TP reçoit ainsi lors d'une étape E24 la version chiffrée C du système d'exploitation modifiable FOS, par exemple comme déjà indiqué sous forme de blocs chiffrés Cj.
L'auditeur tiers TP détermine alors à l'étape E26 une pluralité de nombres r^ , rn par tirage aléatoire.
Pour chaque nombre aléatoire n ainsi déterminé, l'auditeur tiers TP détermine à l'étape E28 une valeur de vérification M, associée, par exemple par application d'une fonction F au nombre aléatoire concerné n et à la version chiffrée
C du système d'exploitation modifiable FOS.
La fonction F a des propriétés identiques à celle utilisée dans le premier mode de réalisation. Par ailleurs, comme indiqué pour le premier mode de réalisation, on peut utiliser un nombre n de valeurs aléatoires n et de valeurs de vérification M, tel que l'entité électronique sécurisée E ne peut pas mémoriser l'ensemble de ces valeurs n, M,.
On utilise par exemple en tant que fonction F un algorithme de type
CBC-MAC (pour "Cipher Block Chaining - Message Authentication Code") en prenant en tant que vecteur d'initialisation la valeur aléatoire n et en tant que fonction cryptographique l'algorithme de chiffrement AES utilisant une clé secrète
K2, comme représenté en figure 7.
Les valeurs aléatoires η et les valeurs de vérification associées M, sont mémorisées par l'auditeur tiers (étape E30), comme représenté à la figure 2.
On remarque qu'on pourrait ici en variante s'abstenir de déterminer au préalable les valeurs aléatoires n et de vérification M, et de les mémoriser (voir plus bas les étapes E34 et E40). En effet, le système d'exploitation modifiable
FOS étant mémorisé par l'auditeur tiers TP sous forme chiffrée, il peut conserver ces données en mémoire tout au long de l'utilisation de l'entité électronique sécurisée E.
Lorsque l'entité électronique sécurisée E est utilisée (ce dont l'auditeur tiers TP peut être informé par réception - non représentée sur la figure 4 - d'un message provenant de l'émetteur ISS), l'auditeur tiers TP vérifie périodiquement l'intégrité du système d'exploitation modifiable FOS comme décrit à présent.
Dans l'exemple décrit ici, on initialise tout d'abord à 0 un indice i (étape
E32).
Dans la variante susmentionnée où les valeurs aléatoires η n'ont pas été déterminées au préalable, on détermine alors une valeur n par tirage aléatoire à l'étape E34 (cette étape n'étant naturellement pas réalisée lorsque l'on a procédé au préalable à l'étape E26).
Quel que soit le moment où la valeur aléatoire n est déterminée (au préalable à l'étape E26 ou sur le champ à l'étape E34), la valeur aléatoire η est émise par l'auditeur tiers TP à l'étape E36 à destination de l'entité électronique sécurisée E. L'entité électronique sécurisée E reçoit la valeur aléatoire n à l'étape
E38.
L'entité électronique sécurisée E détermine alors à l'étape E42 une valeur de vérification M* sur la base de la valeur aléatoire n et des données formant le système d'exploitation modifiable FOS, en chiffrant les données formant le système d'exploitation modifiable FOS au moyen de l'algorithme de chiffrement ENC et de la clé secrète KÏ utilisés à l'étape E20, et en utilisant la fonction F utilisée à l'étape E28 : M* = F ^ENC^FOS)).
On rappelle que l'entité électronique sécurisée E mémorise pour ce faire la clé secrète (ou clé cryptographique) Ki et, dans le cas où la fonction F est de type CBC-MAC comme indiqué plus haut, la clé secrète (ou clé cryptographique) K2. Par ailleurs, lorsque le vecteur d'initialisation IV utilisé par l'émetteur ISS pour chiffrer les données formant le système d'exploitation FOS (voir ci-dessus l'étape E20) est obtenu par tirage aléatoire, ce vecteur d'initialisation IV est également mémorisé dans l'entité électronique sécurisée E.
Dans la variante susmentionnée où les valeurs de vérification M, n'ont pas été déterminées au préalable, l'auditeur tiers TP détermine pendant ce temps à l'étape E40 (ou éventuellement avant envoi de la valeur aléatoire n à l'étape E36) la valeur de vérification M, associée à la valeur aléatoire n obtenue à l'étape E34, par application de la fonction F à cette valeur aléatoire n et à la version chiffrée C du système d'exploitation modifiable FOS : M, = F(n,C). Cette étape n'est naturellement pas réalisée lorsque l'on a procédé au préalable à l'étape E28.
Comme indiqué ci-dessus, dans les exemples qui précèdent, la fonction F est appliquée à l'ensemble des données modifiables de la mémoire non-volatile NV (c'est-à-dire dans certains cas à l'ensemble des données de la mémoire non- volatile NV).
Il est toutefois également envisageable lors des étapes E40 et E42 d'appliquer la fonction F à une partie seulement de la mémoire non-volatile NV ou du système d'exploitation modifiable FOS, par exemple à une partie seulement des blocs FOS, formant le système d'exploitation modifiable FOS.
Ainsi par exemple lorsque le système d'exploitation modifiable FOS est chiffré à l'étape E20 au moyen d'un algorithme de type ECB (ou CTR), l'auditeur tiers TP peut envoyer à l'entité électronique sécurisée E lors de l'étape E36 une désignation des blocs FOS, auxquels la fonction F doit être appliquée, par exemple sous forme d'une liste {k(1 ), k(l)} des indices i de ces blocs (déterminée par exemple par tirage aléatoire) et les mots de vérification M,, M* peuvent alors être déterminés en concaténant les blocs concernés :
- du côté de l'auditeur tiers TP (étape E40), M, = F(n,Ck(i )||- - - l|Ck(i)) ;
- du côté de l'entité électronique sécurisée E (étape E42),
M* = F(rijENC(K1 jFOSk(i))||... ||ENC(K1 jFOSk(i))).
Dans tous les cas, l'entité électronique sécurisée E envoie à l'étape E44 la valeur de vérification M* déterminée à l'étape E42, en tant qu'élément de preuve de l'intégrité du système d'exploitation modifiable FOS (ou d'une partie de celui-ci) à destination de l'auditeur tiers TP.
L'auditeur tiers TP peut ainsi comparer à l'étape E48 la valeur de vérification M, déterminée par ses soins (étape E28 ou E40) à la valeur de vérification M* reçue de l'entité électronique sécurisée E.
Si le résultat de la comparaison est positif, le système d'exploitation modifiable FOS mémorisé dans l'entité électronique sécurisée E correspond à celui attendu et l'auditeur tiers TP peut attendre une durée prédéterminée (temporisation de l'étape E50) avant d'incrémenter l'indice i (étape E52) et de boucler à l'étape E36 (ou E34 selon la variante mentionnée plus haut) afin de vérifier à nouveau l'intégrité du système d'exploitation modifiable FOS.
Si le résultat de la comparaison est négatif, le système d'exploitation modifiable FOS (ou, de manière générale, la zone mémoire couverte par la vérification) a été modifié et l'auditeur tiers TP émet par exemple un message d'alerte à destination de l'émetteur ISS (étape E54). À réception de ce message d'alerte, l'émetteur ISS prend par exemple des mesures pour désactiver l'entité électronique sécurisée, telles que la révocation des certificats mémorisés dans l'entité électronique sécurisée (étape E56).
La figure 8 représente les étapes principales d'un troisième exemple de procédé mis en œuvre dans le cadre de l'invention.
Au cours d'une étape E100, l'émetteur ISS transmet une image mémoire IM à destination de l'entité électronique sécurisée E. Cette image mémoire IM contient l'ensemble des données et instructions à mémoriser dans la mémoire non-volatile NV de l'entité électronique sécurisée E pour permettre son fonctionnement.
L'entité électronique sécurisée E reçoit l'image mémoire IM à l'étape E102 et la mémorise dans sa mémoire non-volatile NV. L'entité électronique sécurisée est alors prête à être utilisée pour la fonctionnalité pour laquelle elle est conçue, par exemple en tant que moyen de paiement, moyen d'accès à un réseau de téléphonie mobile, moyen d'identification, etc.
Les étapes E100 et E102 peuvent être réalisées dans le contexte de la figure 1 , auquel cas un mécanisme de sécurisation des échanges est au préalable mis en œuvre entre l'émetteur ISS et l'entité électronique sécurisée E afin d'effectuer à distance la personnalisation de l'entité électronique sécurisée E. En variante, les étapes E100 et E102 peuvent être réalisées au sein d'un établissement dédié à la personnalisation d'entités électroniques sécurisées, auquel cas l'entité électronique sécurisée E communique (par une liaison filaire ou sans fil courte portée ou autre) avec une machine de personnalisation de l'émetteur ISS (la machine de personnalisation mettant alors en œuvre l'étape E100).
Au cours d'une étape E104, l'image mémoire IM est sécurisée par l'émetteur ISS, par exemple par chiffrement au moyen d'un algorithme cryptographique utilisant une clé cryptographique SECST, ce qui permet d'obtenir une version sécurisée (ici chiffrée) IMSEC de l'image mémoire IM. L'émetteur ISS peut éventuellement générer en outre une signature ou un code d'authentification (ou MAC pour "Message Authentication Code") de l'image mémoire IM.
L'image mémoire sécurisée IMSEC et la clé cryptographique SECST (ainsi éventuellement que la signature ou le code d'authentification) sont émises par l'émetteur ISS à l'étape E106, à destination de l'auditeur tiers TP. La clé cryptographique SECST étant un secret partagé entre l'émetteur ISS et l'auditeur tiers TP (ou, en variante, entre l'émetteur ISS et un module de sécurité matériel détenu par l'auditeur tiers TP), elle est transmise en utilisant un mécanisme empêchant sa divulgation, par exemple au moyen d'un canal sécurisé établi entre l'émetteur ISS et l'auditeur tiers TP.
L'auditeur tiers TP reçoit et mémorise à l'étape E108 l'image mémoire sécurisée IMSEC et la clé cryptographique SECST (ainsi éventuellement que la signature ou le code d'authentification). En pratique, la clé cryptographique SECST est par exemple mémorisée dans un module de sécurité matériel (ou HSM pour "Hardware Security Module") de l'émetteur ISS, par exemple une carte à microcircuit ou un élément sécurisé intégré. Ensuite, au cours d'une étape E1 10, l'auditeur tiers génère un secret SECINT (par exemple par tirage aléatoire) et mémorise ce secret SECINT, par exemple au sein du module de sécurité matériel précité.
Le secret SECINT généré à l'étape E1 10 est transmis à l'entité électronique sécurisée E, par exemple au moyen d'un canal de communication sécurisé établi entre l'auditeur tiers TP et l'entité électronique sécurisée E, puis mémorisé dans l'entité électronique sécurisée E (étape E1 12), par exemple dans une zone de la mémoire non-volatile NV non couverte par la vérification d'intégrité.
Dans l'exemple qui vient d'être donné, le secret SECINT est généré par l'auditeur tiers TP. En variante, le secret SECINT pourrait être généré par l'émetteur ISS, transmis à l'auditeur tiers ISS (par exemple lors de l'étape E106 décrite ci- dessus) et mémorisé dans l'entité électronique sécurisée E lors de la phase de personnalisation (par exemple à l'étape E102 décrite ci-dessus).
De manière périodique au cours de l'utilisation de l'entité électronique sécurisée E, l'auditeur tiers TP peut alors vérifier l'intégrité de parties de l'image mémoire IM mémorisée en mémoire non-volatile NV, comme décrit à présent.
L'auditeur tiers TP génère à l'étape E1 14 une liste (ordonnée) non- prévisible L de régions de la zone mémoire dont on souhaite vérifier l'intégrité, ici la mémoire non-volatile NV (qui contient en fonctionnement normal l'image mémoire IM reçue et mémorisée à l'étape E102).
Chaque région de la liste L est ici définie par une adresse, qui désigne le début de la région concernée (autrement dit, qui vise par exemple le premier octet de la région concernée), et par une longueur (exprimée par exemple en nombre de mots de bits, ici en nombre d'octets).
Pour chaque région de la liste L, l'adresse et la longueur définissant cette région sont par exemple déterminées par tirage aléatoire. On peut toutefois prévoir dans ce cas que certaines parties particulières de la mémoire concernée (ici la mémoire non-volatile NV), par exemple des parties contenant des instructions ou des données critiques ou sensibles, soient plus fréquemment visées par les régions de la liste. Pour ce faire, on prévoit par exemple que certaines adresses soient déterminées par tirage aléatoire parmi les adresses situées dans ces parties particulières de la mémoire concernée, tandis que d'autres adresses sont déterminées par tirage aléatoire parmi toutes les adresses envisageables pour la mémoire concernée. En variante, la liste des régions pourrait être prédéterminée (tout en restant de préférence imprévisible). L'auditeur tiers TP peut en effet en pratique utiliser un grand nombre de listes prédéterminées de telle sorte que l'entité électronique sécurisée E ne pourra pas mémoriser la réponse attendue (valeur d'intégrité VALINT mentionnée plus bas) à chacune de ces listes.
Selon une autre possibilité de réalisation, l'auditeur tiers TP peut choisir la liste L par tirage aléatoire parmi un grand nombre de listes prédéterminées.
Dans le cas décrit ici où la liste n'est pas prédéterminée, le nombre de régions listées dans la liste L peut être fixe ou variable, par exemple déterminé par tirage aléatoire entre une valeur minimale et une valeur maximale.
On remarque par ailleurs que les différentes régions de la liste L peuvent éventuellement se chevaucher (/'.e. se recouper) sans que cela ne pose de difficultés dans la suite du processus.
L'auditeur tiers TP émet alors à l'étape E1 16 la liste L (générée à l'étape E1 14) à destination de l'entité électronique sécurisée E.
La liste non-prévisible L est reçue par l'entité électronique sécurisée E à l'étape E1 18.
L'entité électronique sécurisée E construit alors à l'étape E120 une structure d'octets par lecture des octets mémorisés dans les régions de mémoire (ici de la mémoire non-volatile NV) désignées dans la liste L reçue, par exemple par concaténation des octets lus dans les régions de la liste L.
L'entité électronique sécurisée E peut ainsi déterminer à l'étape E122 une valeur d'intégrité VALINT (OU valeur de vérification) par application d'une fonction f à la structure d'octets produite à l'étape E120, en utilisant ici en outre le secret SECINT-
La fonction f est par exemple une fonction cryptographique de signature ou de génération de code d'authentification de message utilisant en tant que clé cryptographique le secret SECINT et en tant que message (à signer ou à authentifier) la structure d'octets précitée. La fonction f peut être de l'un des types proposés ci-dessus (dans le cadre des deux premiers exemples de réalisation) pour la fonction F.
Comme pour la fonction F, la fonction f est appliquée en considérant la forme brute des multiplets (ici des octets) de la structure, indépendamment de ce que représentent ces multiplets lors de l'utilisation de l'entité électronique sécurisée E
On remarque que la fonction f peut éventuellement utiliser d'autres paramètres (par exemple une valeur aléatoire) qui sont dans ce cas transmis de l'auditeur tiers TP à l'entité électronique sécurisée E avec la liste L à l'étape E1 16, ou en variante de l'entité électronique sécurisée E à l'auditeur tiers TP avec la valeur d'intégrité VALINT à l'étape E124 (décrite ci-dessous). Ces autres paramètres comprennent par exemple un vecteur d'initialisation utilisé par la fonction f (notamment lorsque la fonction f est de type CBC-MAC).
La valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E à l'étape E122 est transmise à l'auditeur tiers TP lors de l'étape E124.
L'auditeur tiers TP reçoit et mémorise cette valeur d'intégrité VALINT à l'étape E126.
L'auditeur tiers TP procède alors à la lecture dans l'image mémoire sécurisée IMSEC des parties correspondant aux régions de la liste L et au déchiffrement de ces parties lues au moyen de la clé cryptographique SECST (étape E128). En variante, le déchiffrement est réalisé par le module de sécurité matériel (à l'intérieur de celui-ci) de sorte que l'auditeur tiers TP n'a pas connaissance des versions déchiffrées.
L'auditeur tiers TP (ou, le cas échéant, le module de sécurité matériel) peut éventuellement à cette occasion procéder à la vérification de la signature ou du code d'authentification associé, lorsqu'un tel élément a été transmis lors de l'étape E106 comme mentionné ci-dessus.
L'auditeur tiers TP (ou, en variante, le module de sécurité matériel détenu par l'auditeur tiers TP) peut ainsi produire à l'étape E130 une structure d'octets à partir des octets contenus dans les parties déchiffrées, selon le processus utilisé par l'entité électronique sécurisée E à l'étape E120, ici par concaténation de ces octets. La structure de données obtenue à l'étape E130 est normalement (c'est-à-dire en cas de fonctionnement normal, sans modification de l'image mémoire IM) identique à celle obtenue à l'étape E120.
L'auditeur tiers TP (ou, en variante, le module de sécurité matériel détenu par l'auditeur tiers TP) détermine à l'étape E132 une valeur d'intégrité VALINT* à partir de la structure d'octets obtenue à l'étape E130, selon le même processus que celui utilisé à l'étape E122, c'est-à-dire par application de la fonction f à cette structure d'octets produite à l'étape E130, en utilisant ici en outre le secret SECINT-
L'auditeur tiers TP (ou, en variante, le module de sécurité matériel détenu par l'auditeur tiers TP) peut ainsi vérifier à l'étape E1 34 si la valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E est bien égale à la valeur d'intégrité VALINT* calculée à l'étape E1 32. Lorsque les étapes qui viennent d'être décrites sont réalisées par le module de sécurité matériel détenu par l'auditeur tiers TP (afin que l'auditeur tiers TP lui-même ne puisse avoir connaissance du contenu de la mémoire vérifiée), un message indicatif du résultat de la comparaison est transmis du module de sécurité matériel à l'auditeur tiers TP.
Si la vérification est positive, l'image mémoire IM mémorisée dans la mémoire non-volatile NV de l'entité électronique sécurisée E n'a pas été altérée et l'entité électronique sécurisée E peut donc continuer à être utilisée normalement.
Le procédé se poursuit donc dans ce cas par une étape E1 36 de temporisation, avant la mise en œuvre d'une nouvelle itération de la vérification de l'intégrité de l'image mémoire IM à partir de l'étape E1 14 comme décrit ci-dessus.
Si la vérification de l'étape E134 est négative, le procédé se poursuit au contraire à l'étape E1 38 au cours de laquelle une action est mise en place pour traiter le défaut d'intégrité de l'image mémoire ainsi détecté. Cette action est par exemple l'émission (non représentée en figure 8) d'un message indiquant ce défaut d'intégrité à destination de l'émetteur ISS, qui peut alors par exemple révoquer les droits associés à l'entité électronique sécurisée E ou, en variante, imposer une mise à jour à distance de l'image mémoire de la mémoire non-volatile NV.
L'itération de vérification d'intégrité décrite ci-dessus ne permet de vérifier que l'intégrité des données contenues dans les régions de la liste L utilisée durant cette itération. Toutefois, au fur et à mesure des itérations, une partie plus importante de la mémoire concernée aura été vérifiée. On remarque en outre que l'entité électronique sécurisée E ne peut pas prévoir les régions utilisées lors d'une itération donnée et ne peut donc pas anticiper sur la valeur d'intégrité transmise en réponse à l'auditeur tiers TP.
La seule possibilité pour que l'entité électronique sécurisée E calcule la réponse attendue est donc qu'elle maintienne l'intégrité de la mémoire concernée.
La figure 9 représente les étapes principales d'un quatrième exemple de procédé mis en œuvre dans le cadre de l'invention.
Dans cet exemple, l'auditeur tiers TP mémorise une image mémoire dérivée IMDER obtenue à partir de l'image mémoire IM (mémorisée quant à elle dans la mémoire non-volatile NV de l'entité électronique sécurisée E), par exemple au moyen d'un algorithme cryptographique de chiffrement (tel qu'un algorithme de type ECB comme mentionné plus haut). Cette situation est par exemple obtenue par un procédé du même type que celui des étapes E20 à E24 décrit ci-dessus en référence à la figure 4.
L'entité électronique sécurisée E mémorise quant à elle la clé cryptographique de chiffrement utilisée pour obtenir l'image mémoire dérivée IMDER.
On décrit ci-dessous une itération d'un procédé de vérification de l'intégrité de l'image mémoire IM . Une telle itération est répétée périodiquement afin de couvrir au fur et à mesure une part de plus en plus importante de la mémoire concernée, comme décrit ci-dessus en référence à la figure 8 pour le troisième exemple de réalisation.
L'auditeur tiers TP génère à l'étape E200 une liste (ordonnée) non- prévisible L de régions de la zone mémoire dont on souhaite vérifier l'intégrité, ici la mémoire non-volatile NV.
Comme dans le troisième exemple décrit ci-dessus en référence à la figure 8, chaque région de la liste L est ici définie par une adresse et par une longueur. La liste L des régions est générée selon l'une des possibilités envisagées ci-dessus dans le cadre du troisième exemple de réalisation.
L'auditeur tiers TP émet la liste L à destination de l'entité électronique sécurisée E (étape E202) et la liste non-prévisible L est donc reçue par l'entité électronique sécurisée E à l'étape E204.
L'entité électronique sécurisée E lit alors les données mémorisées (sous forme de multiplets, ici d'octets) dans les régions désignées dans la liste L et génère à l'étape E206 des données dérivées correspondantes, en appliquant l'algorithme utilisé pour obtenir l'image dérivée IMDER mémorisée par l'auditeur tiers TP comme indiqué ci-dessus (ici un algorithme de chiffrement, par exemple de type EBC, utilisant la clé cryptographique de chiffrement mémorisée par l'entité électronique sécurisée E).
L'entité électronique construit ensuite à l'étape E208 une structure de données à traiter (ou structure d'octets) en utilisant les données dérivées obtenues à l'étape E206, par exemple par concaténation de ces données dérivées.
L'entité électronique sécurisée E peut ainsi déterminer à l'étape E210 une valeur d'intégrité VALINT (OU valeur de vérification) par application d'une fonction f à la structure de données produite à l'étape E208, en utilisant par exemple en outre un secret SECINT partagé entre l'entité électronique sécurisée E et l'auditeurs tiers TP, comme dans le troisième exemple décrit en référence à la figure 8. La fonction f peut être de l'un des types proposés ci-dessus (dans le cadre des trois premiers exemples de réalisation).
La valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E à l'étape E210 est transmise à l'auditeur tiers TP lors de l'étape E21 2 et reçue par celui-ci à l'étape E214, qui la mémorise.
L'auditeur tiers TP procède alors à la lecture dans l'image mémoire dérivée IMDER des parties correspondant aux régions de la liste L et produit à l'étape E216 une structure de données à partir des données lues, selon le processus utilisé par l'entité électronique sécurisée E à l'étape E208, ici par concaténation des données lues. La structure de données obtenue à l'étape E21 6 est normalement (c'est-à-dire en cas de fonctionnement normal, sans modification de l'image mémoire IM) identique à celle obtenue à l'étape E208.
L'auditeur tiers TP détermine à l'étape E21 8 une valeur d'intégrité VALINT* à partir de la structure de données obtenue à l'étape E21 6, selon le même processus que celui utilisé à l'étape E21 0, c'est-à-dire par application de la fonction f à cette structure de données produite à l'étape E21 6, en utilisant ici en outre le secret partagé SECINT-
L'auditeur tiers TP peut ainsi vérifier à l'étape E220 si la valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E est bien égale à la valeur d'intégrité VALINT* calculée à l'étape E21 8.
Si la vérification est positive, l'image mémoire IM mémorisée dans la mémoire non-volatile NV de l'entité électronique sécurisée E n'a pas été altérée et l'entité électronique sécurisée E peut donc continuer à être utilisée normalement (étape E222).
Si la vérification de l'étape E220 est négative, le procédé se poursuit au contraire à l'étape E224 au cours de laquelle une action est mise en place pour traiter le défaut d'intégrité de l'image mémoire IM ainsi détecté. Cette action est du même type que celle de l'étape E138 décrite plus haut en référence à la figure 8.

Claims

REVENDICATIONS
1 . Entité électronique sécurisée (E) comprenant :
- une mémoire (NV) mémorisant des données sous forme de multiplets ;
- un module de traitement (M) conçu pour recevoir des données (n ; L) en provenance d'un dispositif électronique (TP) ;
caractérisée en ce que le module de traitement (M) est conçu pour déterminer un élément de preuve d'intégrité (M* ; VALINT) en fonction des données reçues (η ; L) et d'une partie au moins des multiplets mémorisés, et pour émettre l'élément de preuve d'intégrité (M* ; VALINT) à destination du dispositif électronique (TP).
2. Entité électronique sécurisée selon la revendication 1 , dans laquelle les données reçues représentent une valeur aléatoire (η).
3. Entité électronique sécurisée selon la revendication 1 , dans laquelle les données reçues (L) désignent des régions de la mémoire (NV) et dans laquelle le module de traitement (M) est conçu pour déterminer l'élément de preuve d'intégrité (VALINT) en fonction des multiplets mémorisés dans les régions désignées par les données reçues (L).
4. Entité électronique sécurisée selon l'une des revendications 1 à 3, dans laquelle le module de traitement (M) est conçu pour déterminer l'élément de preuve d'intégrité (M* ; VALINT) en partie au moyen d'un chiffrement des multiplets mémorisés.
5. Entité électronique sécurisée selon la revendication 4, comprenant un module de mise en œuvre du chiffrement en fonction d'une clé secrète (Ki) mémorisée dans l'entité électronique sécurisée (E).
6. Entité électronique sécurisée selon l'une des revendications 1 à 5, dans laquelle le module de traitement (M) est conçu pour déterminer l'élément de preuve d'intégrité (M* ; VALINT) au moyen d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message.
7. Entité électronique sécurisée selon l'une des revendications 1 à 6, ladite entité électronique sécurisée étant une carte d'accès à un réseau de téléphonie mobile.
8. Téléphone cellulaire comprenant une entité électronique sécurisée selon l'une des revendications 1 à 7.
9. Téléphone cellulaire selon la revendication 8, dans lequel l'entité électronique sécurisée est soudée au téléphone cellulaire.
10. Compteur de fourniture d'énergie comprenant une entité électronique sécurisée selon l'une des revendications 1 à 7.
1 1 . Compteur de fourniture d'énergie selon la revendication 10, dans lequel l'entité électronique sécurisée est soudée audit compteur.
12. Système électronique embarqué pour véhicule comprenant une entité électronique sécurisée selon l'une des revendications 1 à 7.
13. Système électronique embarqué selon la revendication 12, dans lequel l'entité électronique sécurisée est soudée au système électronique.
14. Appareil électronique comprenant un module de communication en champ proche et une entité électronique sécurisée selon l'une des revendications 1 à 7 reliée au module de communication en champ proche.
15. Procédé de vérification de l'intégrité de données mémorisées dans une entité électronique sécurisée (E), caractérisé en ce qu'il comprend les étapes suivantes :
- émission, par un dispositif électronique (TP), de données (η ; L) à destination de l'entité électronique sécurisée (E) ;
- réception des données (n ; L) par l'entité électronique sécurisée (E) ; - détermination d'un élément de preuve d'intégrité (M* ; VALINT) en fonction des données reçues (n ; L) et d'une partie au moins des multiplets mémorisés dans une mémoire (NV) de l'entité électronique sécurisée (E) ;
- émission, par l'entité électronique sécurisée (E), de l'élément de preuve d'intégrité (M* ; VALINT) à destination du dispositif électronique (TP).
16. Procédé de vérification selon la revendication 15, comprenant une étape de détermination (E26 ; E34 ; E1 14 ; E200) d'une partie au moins des données (η ; L) émises par tirage aléatoire.
17. Procédé de vérification selon la revendication 15 ou 16, dans lequel les données reçues représentent une valeur aléatoire (n) utilisée en tant que paramètre lors de l'application d'une fonction (E6 ; E42).
18. Procédé de vérification selon la revendication 15 ou 16, dans lequel les données reçues (L) désignent des régions de la mémoire (NV) et dans lequel la détermination de l'élément de preuve d'intégrité (VALINT) est réalisée en fonction des multiplets mémorisés dans les régions désignées par les données reçues (L).
19. Procédé de vérification selon l'une des revendications 15 à 18, dans lequel la détermination de l'élément de preuve d'intégrité comprend un chiffrement (E42 ; E206) des multiplets mémorisés.
20. Procédé de vérification selon la revendication 19, dans lequel le chiffrement des multiplets mémorisés utilise une clé secrète (Ki ) mémorisée dans l'entité électronique sécurisée (E).
21 . Procédé de vérification selon l'une des revendications 15 à 20, dans lequel l'élément de preuve d'intégrité (M* ; VALINT) est déterminé par application d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message.
22. Procédé de vérification selon l'une des revendications 15 à 21 , dans lequel ledit dispositif électronique est un auditeur tiers (TPA).
EP15828654.2A 2014-12-23 2015-12-17 Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée Withdrawn EP3238200A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463256A FR3030831B1 (fr) 2014-12-23 2014-12-23 Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee
PCT/FR2015/053595 WO2016102833A1 (fr) 2014-12-23 2015-12-17 Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée

Publications (1)

Publication Number Publication Date
EP3238200A1 true EP3238200A1 (fr) 2017-11-01

Family

ID=53059209

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15828654.2A Withdrawn EP3238200A1 (fr) 2014-12-23 2015-12-17 Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée

Country Status (5)

Country Link
US (1) US20170353315A1 (fr)
EP (1) EP3238200A1 (fr)
KR (1) KR20170097771A (fr)
FR (1) FR3030831B1 (fr)
WO (1) WO2016102833A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6260067B1 (ja) * 2016-08-09 2018-01-17 Kddi株式会社 管理システム、鍵生成装置、車載コンピュータ、管理方法、及びコンピュータプログラム
FR3060806B1 (fr) * 2016-12-20 2019-05-24 Idemia France Procede de verification de l'integrite de donnees, entite electronique associee et appareil electronique comprenant une telle entite electronique
FR3060807B1 (fr) * 2016-12-20 2019-05-24 Idemia France Procede de verification de l'integrite d'un programme, entite electronique associee et appareil electronique comprenant une telle entite electronique
GB2564878B (en) * 2017-07-25 2020-02-26 Advanced Risc Mach Ltd Parallel processing of fetch blocks of data
CN114223233A (zh) * 2019-08-13 2022-03-22 上海诺基亚贝尔股份有限公司 用于网络切片管理的数据安全性
US11416639B2 (en) * 2020-06-29 2022-08-16 Nuvoton Technology Corporation PQA unlock
CN114080016B (zh) * 2020-08-12 2023-06-27 大唐移动通信设备有限公司 用户设备上下文信息的同步方法、装置和网络侧设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120290870A1 (en) * 2010-11-05 2012-11-15 Interdigital Patent Holdings, Inc. Device validation, distress indication, and remediation

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442645A (en) * 1989-06-06 1995-08-15 Bull Cp8 Method for checking the integrity of a program or data, and apparatus for implementing this method
US9805196B2 (en) * 2009-02-27 2017-10-31 Microsoft Technology Licensing, Llc Trusted entity based anti-cheating mechanism

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120290870A1 (en) * 2010-11-05 2012-11-15 Interdigital Patent Holdings, Inc. Device validation, distress indication, and remediation

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DWAINE CLARKE ET AL: "Checking the Integrity of Memory in a Snooping-Based Symmetric Multiprocessor (SMP) System", 26 July 2004 (2004-07-26), XP055517576, Retrieved from the Internet <URL:http://csg.csail.mit.edu/pubs/memos/Memo-470/smpMemoryMemo.pdf> *
See also references of WO2016102833A1 *
TCG: "TCG Specification Architecture Overview, Specification Revision 1.2", TCG SPECIFICATION ARCHITECTURE OVERVIEW, TRUSTED COMPUTING GROUP, US, 28 April 2004 (2004-04-28), pages 1 - 54, XP002413737 *

Also Published As

Publication number Publication date
US20170353315A1 (en) 2017-12-07
WO2016102833A1 (fr) 2016-06-30
KR20170097771A (ko) 2017-08-28
FR3030831B1 (fr) 2018-03-02
FR3030831A1 (fr) 2016-06-24

Similar Documents

Publication Publication Date Title
EP3152860B1 (fr) Procédé d&#39;authentification d&#39;une première entité électronique par une seconde entité électronique et entité électronique mettant en oeuvre un tel procédé
EP1427231B1 (fr) Procédé d&#39;établissement et de gestion d&#39;un modèle de confiance entre une carte à puce et un terminal radio
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l&#39;intégrité de données mémorisées dans une telle entité électronique sécurisée
EP3010175B1 (fr) Rejeu d&#39;un batch de commandes sécurisees dans un canal sécurisé
EP3238474B1 (fr) Procédé de sécurisation de transactions sans contact
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
EP2242229A1 (fr) Procédé pour authentifier un terminal mobile client auprès d&#39;un serveur distant
EP3308564B1 (fr) Procédé de chargement d&#39;une clé virtuelle et terminal utilisateur associé
FR3066666A1 (fr) Procede de securisation d&#39;une communication sans gestion d&#39;etats
EP2795833B1 (fr) Procede d&#39;authentification entre un lecteur et une etiquette radio
EP3185468B1 (fr) Procédé de transmission de données, procédé de réception de données, dispositifs et programmes correspondants
EP1514377A1 (fr) Procede et dispositif d&#39;interface pour echanger de maniere protegee des donnees de contenu en ligne
EP3840324B1 (fr) Liaison série asynchrone sécurisée
FR3113800A1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
WO2021074527A1 (fr) Procede de gestion d&#39;une base de donnees de cles publiques, procede d&#39;authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
CN112350920A (zh) 基于区块链的即时通讯系统
EP3021515B1 (fr) Amélioration de l&#39;intégrité authentique de données à l&#39;aide du dernier bloc chiffrant ces données en mode cbc
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
EP2084679A1 (fr) Entite electronique portable et procede de blocage, a distance, d&#39;une fonctionnalite d&#39;une telle entite electronique portable
FR2853785A1 (fr) Entite electronique securisee avec compteur modifiable d&#39;utilisations d&#39;une donnee secrete
WO2006072746A1 (fr) Procede de securisation d’une communication entre une carte sim et un terminal mobile
WO2023041863A1 (fr) Procedes et dispositifs d&#39;authentification et de verification de non-revocation
WO2007125263A2 (fr) Procede de securisation de donnees
WO2015170057A1 (fr) Entité électronique et procédé de génération de clé de session
WO2016034812A1 (fr) Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé

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

17P Request for examination filed

Effective date: 20170720

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

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: IDEMIA FRANCE

17Q First examination report despatched

Effective date: 20181026

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: IDEMIA FRANCE

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: 20191203