WO2022238636A1 - Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré - Google Patents

Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré Download PDF

Info

Publication number
WO2022238636A1
WO2022238636A1 PCT/FR2022/050813 FR2022050813W WO2022238636A1 WO 2022238636 A1 WO2022238636 A1 WO 2022238636A1 FR 2022050813 W FR2022050813 W FR 2022050813W WO 2022238636 A1 WO2022238636 A1 WO 2022238636A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
microcontroller
data block
encrypted
encryption key
Prior art date
Application number
PCT/FR2022/050813
Other languages
English (en)
Inventor
Vincent Dupaquis
Original Assignee
Trusted Objects
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 Trusted Objects filed Critical Trusted Objects
Priority to EP22726783.8A priority Critical patent/EP4338078A1/fr
Publication of WO2022238636A1 publication Critical patent/WO2022238636A1/fr

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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits

Definitions

  • the present invention relates to a method for the execution of a program by an integrated circuit microcontroller, the microcontroller comprising a non-volatile memory and a volatile memory, the program being stored in the non-volatile memory and comprising at least one data block necessary to run a program feature.
  • An application program is a program for controlling a particular device in a particular application. It can be, for example, a program controlling the operation of a drone, a TV decoder, a television, a household appliance, etc.
  • Application program developers generally distinguish, in an application program, a basic program of the microcontroller or "firmware” (also called “firmware”), and advanced functionalities of the application program, generally called “PI blocks” .
  • the term “block of IP” is sometimes taken to mean “block of intellectual property”, thus designating this element as belonging to the person who designed it and intended to be licensed to third parties. In the context of this application, however, this term is used to designate a block of data which may include program data (code) executable by the microcontroller or application data which the microcontroller needs to perform advanced functionality, or even a mixture of these two types of data, without it being necessary to know whether this block of data is subject to intellectual property rights.
  • An application program loaded into a microcontroller can thus comprise, in addition to the firmware, one or more PI blocks, each block corresponding to an advanced functionality of the device or containing data necessary for the execution of an advanced functionality of the device.
  • the firmware can be designed to allow manual piloting of the drone while PI blocks can be provided for advanced drone functionalities such as automatic detection and avoidance. 2 obstacles, carrying out pre-programmed missions using geolocation data provided by an on-board position detection system (e.g. GPS), etc.
  • the firmware alone can ensure certain basic functionalities of the television such as the reception of terrestrial channels, while blocks of PI can ensure more advanced functionalities such as the reception of digital channels and their decoding.
  • the firmware can provide basic washing functionalities, while PI blocks can provide washing functionalities for certain types of laundry or specific washing programs.
  • PI blocks can contain data relating to the synthesis of certain instrument sounds.
  • certain advanced functionalities corresponding to one or more blocks of IP can be activated a posteriori, after the sale and commissioning of the device, by purchasing a functionality unlocking key.
  • the program comprising the firmware accompanied by the PI block(s) that complete it, is loaded into the non-volatile memory of the microcontroller during a personalization phase of the latter, after a program development phase.
  • This personalization phase is generally carried out when the microcontroller has been assembled on an electronic card intended to be mounted in the device for which it is intended.
  • the application program is automatically loaded into the non-volatile memories of a large number of microcontrollers.
  • the document WO2014014793 A1 describes a method for authenticating a software application instance, comprising the transmission, by a user device, of an access request to at least one server device, the request comprising data application identification ("App ID") associated with said software application instance, and steps of transmitting session identification data (session ID) to the user device, of transmitting session identification data and the App ID has an anti-clone engine.
  • the anti-clone engine generates and transmits a challenge token to the user device, receives a response token from the user device, processes the response token to determine whether the software application instance is authentic, and then transmits an authorization message from the user device. server device based on this determination.
  • the document US7539868B2 proposes a computer platform for protecting firmware using a manufacturer's certificate.
  • the manufacturer's certificate binds the system firmware to the computing platform and can store configuration settings and device identification numbers.
  • a secure execution platform data verifier and a secure execution verifier check the system firmware during the operation of the computer platform, to ensure that the system firmware or the information of the manufacturer's certificate have not been modified.
  • Application program files 4 and the data files are linked to the particular computing device by a platform certificate.
  • a key generator can be used to generate a random key and an encrypted key can be generated by encrypting the random key using a secret identification number associated with the particular computing platform. Only the encrypted key is stored in the platform certificate.
  • Document US20030061488A1 proposes a method for preventing the cloning of an electronic device, comprising the steps of generating a first electronic signature from a first identification code and a second identification code, the second identification being suitable for uniquely identifying a hardware component of the electronic device, decrypting an encrypted electronic signature to generate a second electronic signature, comparing the first electronic signature and the second electronic signature, and preventing normal operation of the electronic device if the first electronic signature and the second electronic signature are not identical.
  • the document WO2012033385A2 describes a non-volatile memory for anti-cloning comprising an identification zone which is located in a specific zone of the non-volatile memory, in which is stored an identifier ID for the identification of the non-volatile memory.
  • An identification coder is provided to modify the identifier by a predefined operation with a random error.
  • the identification zone comprises a first zone in which reading and writing by an external device are prevented, and a second zone in which reading is possible by the external device in response to a read command.
  • the ID encoder modifies the ID by a predefined operation using the random error, the ID stored in the first area of the ID area, and a value for the ID encoding received from a host device .
  • the document US8789746B2 proposes a process for authenticating a product using encryption and decryption engines embedded on two integrated circuits, namely an encryption/decryption processor chip or D chip, which accompanies a product, and a reader chip or R chip, which is shipped independently to any authentication point.
  • a unique serial number in encrypted or unencrypted format, is programmed into the D chip, which is then attached to the product.
  • the encrypted and decrypted serial number on board the D chip is transferred to the R chip.
  • the R chip then performs a decryption of the serial number of the first chip if this serial number is in the form encrypted, or an encryption of the serial number of the first chip if this serial number is under 5 unencrypted form.
  • the R-chip compares its decryption or encryption result with the corresponding decrypted or encrypted versions of the serial number received from the D-chip. If the decryption or encryption results for both chips are identical, then the R-chip reports a genuine product, otherwise it rejects the product as fake.
  • the present invention aims at a method for the execution of a program by a microcontroller which makes it possible to implement protection against the cloning of a block of PI which is simple and inexpensive, and a device configured to allow the implementation of this process.
  • the present invention provides a method for the execution of a program by an integrated circuit microcontroller, the microcontroller comprising a non-volatile memory and a volatile memory, the program being stored in the non-volatile memory and comprising at least one block of data necessary for the execution of a functionality of the program, the method comprising the steps of defining a first identifier of the integrated circuit, generating a main encryption key of the block of data, encrypting the block of data from the main encryption key and of the first identifier, loading or downloading, in the non-volatile memory, the block of data in its encrypted form, loading or downloading the main encryption key in the non-volatile memory, and, by means of the microcontroller: decrypt the encrypted data block from the master encryption key and the first identifier, placing the decrypted data block in ns the volatile memory of the microcontroller, and use the decrypted data block present in the volatile memory to execute the functionality.
  • the step consisting in encrypting the data block from the main encryption key and the first identifier comprises the steps consisting in generating a first secondary encryption key, encrypting the first identifier by means of the first secondary encryption key, to obtain a first encrypted identifier, encrypt the block of data from the main encryption key and the first encrypted identifier, and load the first secondary encryption key into the non-volatile memory of the microcontroller.
  • the method comprises the steps consisting in, by means of the microcontroller, decrypting the encrypted data block from the main encryption key, the first identifier, and the first secondary encryption key, and during the decrypting the encrypted block of data, encrypting the first identifier using the first secondary encryption key, to obtain the first encrypted identifier.
  • the step consisting in encrypting the block of data from the main encryption key and the first encrypted identifier comprises the steps consisting in masking the main encryption key by means of the first encrypted identifier, to obtain a derived encryption key, and encrypting the data block from the derived encryption key, to obtain the data block in its encrypted form.
  • the method comprises the steps consisting in, by means of the microcontroller, masking the main encryption key by means of the first encrypted identifier, to obtain the derived encryption key, and decrypting the encrypted data block from the derived encryption key.
  • the step consisting in encrypting the data block from the main encryption key and the first encrypted identifier comprises the steps consisting in encrypting the data block from the main encryption key, for obtaining a pre-encrypted data block, and encrypting the pre-encrypted data block by means of the first encrypted identifier, to obtain an over-encrypted data block forming the data block in its encrypted form loaded into the non-volatile memory of the microcontroller.
  • the method comprises the steps consisting in, by means of the microcontroller, decrypting the over-encrypted data block from the first encrypted identifier, to obtain the pre-encrypted data block, and decrypting the pre-encrypted data block. encrypted from the main encryption key, to obtain the decrypted data block.
  • the first identifier of the integrated circuit is one or other of the following identifiers: a unique identifier of the integrated circuit, such as its serial number, or an identifier common to a plurality of integrated circuits of the same architecture and/or of the same application, such as a serial number of the program loaded into the non-volatile memory of the microcontroller.
  • the method comprises the steps of defining a second identifier of the integrated circuit, masking the main encryption key 7 with the second identifier before loading or downloading it into the non-volatile memory of the microcontroller, and loading or downloading it in its masked form into the non-volatile memory of the microcontroller.
  • the method comprises the steps consisting in, by means of the microcontroller, unmasking the main encryption key masked by means of the second identifier before decrypting the encrypted data block.
  • the step of masking the primary encryption key with the second identifier comprises the steps of generating a second secondary encryption key, encrypting the second identifier using the second secondary encryption key, to obtain a second encrypted identifier, and masking the main encryption key with the second encrypted identifier to obtain the masked form loaded or downloaded into the nonvolatile memory of the microcontroller.
  • the method comprises the steps consisting in, by means of the microcontroller, encrypting the second identifier by means of the second secondary encryption key, to obtain the second encrypted identifier, and unmasking the main encryption key masked by means of of the second encrypted identifier before decrypting the encrypted data block.
  • the second identifier of the integrated circuit is one or other of the following identifiers: a unique identifier of the integrated circuit, such as its serial number, or an identifier common to a plurality of integrated circuits of the same architecture and/or of the same application, such as a serial number of the program loaded into the non-volatile memory of the microcontroller.
  • the method comprises the steps consisting in generating a third secondary encryption key, defining a third identifier of the integrated circuit, generating a first functionality activation key, by encrypting data from the third identifier and the third secondary encryption key, and, by means of the microcontroller, receiving a second activation key, reconstituting the first activation key, not decrypting or incorrectly decrypting the encrypted block of data if the second key activation key is not equal to the first activation key,
  • the method comprises the step consisting in, by means of the microcontroller, injecting the first and second activation keys into steps of decrypting the encrypted data block, so that the result of the 8 decryption of the encrypted data block is erroneous if the second activation key is not equal to the first activation key.
  • the method comprises a step of checking, by the microcontroller, the integrity of the decrypted data block before using it, in the event that the data block has not been decrypted correctly in reason for receiving an incorrect activation key, and a step to configure the microcontroller so that it does not attempt to perform the functionality if the integrity check is not positive.
  • the third identifier of the integrated circuit is one or other of the following identifiers: a unique identifier of the integrated circuit, such as its serial number, or an identifier common to a plurality of integrated circuits of the same architecture and/or of the same application, such as a serial number of the program loaded into the non-volatile memory of the microcontroller.
  • Embodiments of the invention also relate to an integrated circuit microcontroller comprising a non-volatile memory and a volatile memory, the non-volatile memory comprising an executable program comprising at least one block of data necessary for the execution of a functionality of the program.
  • the block of data is stored in the non-volatile memory in an encrypted form generated from a main encryption key and a first identifier of the integrated circuit, the main encryption key being stored in the non-volatile memory of the microcontroller, and the microcontroller is configured to decrypt the encrypted data block from the master encryption key and the first identifier, place the decrypted data block in the volatile memory of the microcontroller, and use the decrypted data block present in the volatile memory to run the feature.
  • the non-volatile memory further comprises a first secondary encryption key, the microcontroller being configured to decrypt the encrypted data block from the main encryption key, the first identifier, and the first encryption key. secondary encryption, and while decrypting the encrypted data block, encrypting the first identifier using the first secondary encryption key, to obtain a first encrypted identifier.
  • the microcontroller is configured to mask the main encryption key by means of the first encrypted identifier, to obtain a derived encryption key, and to decrypt the encrypted block of data from the derived encryption key.
  • the data block is stored in the non-volatile memory in an over-encrypted form, the microcontroller being configured to decrypt the over-encrypted data block from the first encrypted identifier, to obtain a pre-encrypted data block, and decrypting the pre-encrypted data block from the master encryption key to obtain the decrypted data block.
  • the first identifier of the integrated circuit is one or other of the following identifiers: a unique identifier of the integrated circuit, such as its serial number, or an identifier common to a plurality of integrated circuits of the same architecture and/or of the same application, such as a serial number of the program loaded into the non-volatile memory.
  • the main encryption key is stored in the volatile memory in a masked form obtained by masking the key by a second identifier of the integrated circuit, the microcontroller being configured to unmask the masked main encryption key by means of the second identifier before decrypting the encrypted data block.
  • the non-volatile memory further comprises a second secondary encryption key, the microcontroller being configured to encrypt the second identifier by means of the second secondary encryption key, to obtain a second encrypted identifier, and to unmask the key key encryption masked with the second encrypted identifier before decrypting the encrypted data block.
  • the second identifier of the integrated circuit is one or other of the following identifiers: a unique identifier of the integrated circuit, such as its serial number, or an identifier common to a plurality of integrated circuits of the same architecture and/or of the same application, such as a serial number of the program loaded into the non-volatile memory.
  • the microcontroller is configured to generate a first functionality activation key, by encrypting data from the third identifier and the third secondary encryption key, receive a second activation key, not decrypting or incorrectly decrypting the encrypted block of data if the second activation key is not equal to the first activation key.
  • the microcontroller is configured to inject the first and second activation keys into steps for decrypting the block of 10 encrypted data, so that the result of the decryption of the encrypted data block is erroneous if the second activation key is not equal to the first activation key.
  • the microcontroller is configured to check the integrity of the decrypted data block before its use, in the event that the data block has not been decrypted correctly due to the receipt of a key from incorrect activation, and do not attempt to run the feature if the integrity check is not positive.
  • the third identifier of the integrated circuit is one or other of the following identifiers: a unique identifier of the integrated circuit, such as its serial number, or an identifier common to a plurality of integrated circuits of the same architecture and/or of the same application, such as a serial number of the program loaded into the non-volatile memory.
  • FIG. 1 shows an integrated circuit microcontroller configured to implement one or more embodiments of the method according to the invention
  • FIG. 3 illustrates a second embodiment of the method according to the invention
  • FIG. 5 illustrates a fourth embodiment of the method according to the invention
  • FIG. 7 shows general steps for developing an application program and customizing the microcontroller according to the method of the invention
  • FIG. 8 shows in more detail the steps for customizing the microcontroller according to one of the aforementioned embodiments of the method of the invention
  • FIG. 10 shows in more detail the steps of execution of the method of the invention by the microcontroller according to one of the aforementioned embodiments of the method of the invention
  • FIG. 11 shows in more detail the steps of execution of the method of the invention by the microcontroller according to another of the aforementioned embodiments of the method of the invention, 11
  • FIG. 12 shows in more detail the steps of execution of the method of the invention by the microcontroller according to yet another of the aforementioned embodiments of the method of the invention.
  • FIG. 13 shows in more detail the steps of execution of the method of the invention by the microcontroller according to yet another of the aforementioned embodiments of the method of the invention.
  • figure 14 shows an embodiment of a step represented in block form in figure 7.
  • FIG. 1 schematically shows the architecture of an integrated circuit microcontroller ICI, i.e. a microcontroller produced on a semiconductor microchip, used to implement the method according to the invention.
  • the microcontroller conventionally comprises a CPU (central processing unit), a bank of registers RBANK, a non-volatile memory MEM1, for example a FLASH type memory, and a volatile memory MEM2, for example a RAM type memory.
  • the bank of registers RBANK and the memories MEM1, MEM2 are linked to the CPU by an address bus ADB and a data bus DTB.
  • the microcontroller also includes a contactless communication interface circuit CINT allowing the CPU to receive OTA (Over The Air) data, in other words downloaded data.
  • the CINT circuit can use one or more contactless communication technologies, for example NFC, Wifi, 4G, etc.
  • the non-volatile memory MEM1 receives an application program comprising a basic program, or firmware FWR, and blocks of data IPi (IPI, IP2,... IPn).
  • Each IPi data block comprises program data that can be executed by the microcontroller, application data or a mixture of these two types of data, which the CPU must use to execute advanced functionalities of the application program.
  • the RBANK register bank (or any other non-volatile register of the microcontroller) also contains a unique identifier UID of the integrated circuit. This identifier is engraved during the manufacturing process of the integrated circuit ICI or is dynamically regenerated, at startup or at the request of the CPU, by a dedicated hardware circuit.
  • the UID identifier is immutable and uniquely identifies the integrated circuit.
  • the UID identifier can for example be the serial number of the integrated circuit on which the microcontroller has been implanted or an identifier of the PUF type (from the English 12
  • the non-volatile memory MEM1 also comprises at least one symmetric encryption function and its corresponding decryption function, called “reciprocal function” in the following.
  • the encryption function and its reciprocal may be identical, depending on the type of encryption function retained. More particularly, the memory MEM1 here comprises a function FC1 and its reciprocal RFC1, a function FC2 and its reciprocal RFC2, and a function FC3 and its reciprocal RFC3. It also comprises a main encryption key IPKi or IPKj, secondary encryption keys CK1, CK2 and CK3 (secret keys) and a non-unique identifier of the integrated circuit, for example a serial number FSN of the firmware.
  • IPKi designates an encryption key stored in the non-volatile memory during a personalization phase of the integrated circuit
  • IPKj an OTA encryption key, that is to say received by the microcontroller via the communication interface circuit CINT after it is put into service.
  • the data blocks IPi (IPI, IP2...IPn) are stored in the non-volatile memory in an encrypted form EIPi (EIP1, EIP2...EIPn) obtained by means of a known encryption function of the microcontroller, here the function FC1.
  • this encryption is carried out using the main key IPKi or IPKj and an identifier ID1 of the integrated circuit.
  • the identifier ID1 can, depending on the embodiment adopted and depending on the degree of protection against cloning sought, be the unique identifier UID of the integrated circuit or a non-unique identifier such as the serial number FSN of the firmware.
  • the encryption of the IPi data block is therefore linked to the identifier ID1.
  • the CPU decrypts the block of encrypted data EIPi from the identifier ID1 and the key IPKi or IPKj, then loads the decrypted data block IPi into a buffer zone IPBUF of the volatile memory MEM2.
  • the CPU uses this block of data from the volatile memory MEM2, without loading it into the non-volatile memory MEM1, to execute the corresponding functionality.
  • the microcontroller then erases the block of data IPi from the volatile memory or leaves it in the buffer zone IPBUF until it is reused or overwritten by another block of data IPi which has just been decrypted.
  • the CPU can first check the integrity of the IPi data block, 13 before using G, for example by checking that its cyclic redundancy code CRC (Cyclic Redundancy Check) is valid.
  • CRC Cyclic Redundancy Check
  • the method of the invention may be the subject of various embodiments, some of which are illustrated schematically in FIGS. 2 to 6.
  • a personalization phase PERS of the microcontroller and a phase of execution of the method of the invention EXEC during which a functionality requiring the use of a data block IPi is executed by the microcontroller.
  • the customization step includes:
  • step SP1 consisting in defining the identifier ID1, which can be the unique identifier UID or a non-unique identifier such as the serial number FSN of the firmware,
  • step SP2 for encrypting a block IPi from the key IPKi and the identifier ID1, for example by means of the function FC1, to obtain an encrypted data block EIPi linked to the identifier ID1, and
  • the step of execution of the method by the microcontroller comprises: - a step SEO of decrypting the encrypted data block EIPi from the key IPKi and the identifier ID 1 , for example by means of the reciprocal function RFC 1 , and
  • step SE1 for loading the decrypted data block IPi into the buffer zone IPBUF of the memory MEM2, followed by a step for using the data block IPi.
  • This use may be preceded by a step for verifying the IPi data block and followed by a step for erasing it.
  • the customization step includes:
  • step SP 10 consisting in generating the symmetrical encryption keys IPKi and CKl
  • step SP11 consisting in defining the identifier ID1, which as before can be the unique identifier UID or a non-unique identifier such as the serial number FSN of the firmware, 14
  • step SP 12 for encrypting the data block IPi from the key IPKi, the identifier ID1 and the key CK1, for example by means of the function FC1, to obtain an encrypted data block EIPi linked to the identifier ID1, and
  • step SP 15 for loading the encrypted data block EIPi, the key IPKi and the key CK1 into the memory MEME
  • the step of executing the method by the microcontroller includes:
  • step SE 10 for decrypting the encrypted data block EIPi from the key IPKi, the identifier ID1 and the key CK1, for example by means of the reciprocal function RFC1, and
  • step SE11 for loading the decrypted data block IPi into the buffer zone IPBUF, followed by a step for using the data block IPi.
  • this use can be preceded by a step for verifying the block of data IPi and be followed by a step for erasing the block of data.
  • the customization step includes:
  • step SP20 consisting in generating the symmetrical encryption keys IPKi, CK1, and CK2,
  • step SP21 consisting in defining the identifiers ID1, ID2, each of these identifiers being able to be the unique identifier UID or a non-unique identifier such as the serial number FSN of the firmware,
  • step SP22 for encrypting the data block IPi from the key IPKi, the identifier ID1 and the key CK1, for example by means of the function FC1, to obtain an encrypted data block EIPi linked to the identifier ID1,
  • step SP23 for encrypting the key IPKi from the identifier ID2 and the key CK2, for example by means of the function FC2, to obtain an encrypted key EIPKi linked to the identifier ID2, and
  • step SP25 consisting in loading the encrypted data block EIPi, the encrypted key EIPKi and the keys CK1 and CK2 into the memory MEME
  • the step of executing the method by the microcontroller includes:
  • step SE20 for decrypting the encrypted data block EIPi from the encrypted key EIPKi, the identifier ID1, the key CK1, the identifier ID2 and the key CK2, for example by means of the reciprocal function RFC1, and
  • this use can be preceded by a step of verifying the block of data IPi and be followed by a step of erasing the block of data.
  • the personalization step comprises: a step SP30 consisting in generating the symmetrical encryption keys IPKj,
  • step SP31 consisting in defining the identifiers ID1, ID2, each of these identifiers being able, as previously, to be the unique identifier UID or a non-unique identifier such as the serial number FSN of the firmware, - a step SP32 for encrypting the block of data IPi from IPKj, the identifier ID1 and the encryption key CK1, for example by means of the function FC1, to obtain an encrypted data block EIPi linked to the identifier ID1,
  • step SP33 for encrypting the key IPKj from the identifier ID2 and the key CK2, for example by means of the function FC2, to obtain an encrypted key EIPKj linked to the identifier ID2, and
  • step SP35 consisting in loading the encrypted data block EIPi and the keys CK1, CK2 into the memory MEME
  • the personalization step is followed by a step SD00 for receiving the encrypted key EIPKj by downloading it via the circuit CINT (OTA key). The CPU then loads this key into non-volatile memory SAME
  • the step of executing the method by the microcontroller includes:
  • step SE30 for decrypting the encrypted data block EIPi from the encrypted key EIPKj, the identifiers ID1, ID2 and the keys CK1, CK2, for example by means of the reciprocal function RFC1, and - a step SE31 for loading the decrypted data block IPi in the buffer zone IPBUF, followed by a step of using the data block IPi.
  • this use can be preceded by a step for verifying the block of data IPi and be followed by a step for erasing the block of data.
  • the customization step includes:
  • step SP40 consisting in generating the symmetrical encryption keys IPKi, CK1, CK2 and CK3,
  • step SP41 consisting in defining the identifiers ID1, ID2, ID3, each of these identifiers possibly being the unique identifier UID or a non-unique identifier such as the serial number FSN of the firmware, 16
  • step SP42 for encrypting the data block IPi from the key IPKi, the identifier ID1 and the key CK1, for example by means of the function FC1, to obtain an encrypted data block EIPi linked to the identifier ID1,
  • step SP43 for encrypting the key IPKi from the identifier ID2 and the key CK2, for example by means of the function FC2, to obtain an encrypted key
  • step SP44 consisting in generating an activation key ACTIV1 by encrypting a datum DT, for example by means of the function FC3, from the identifier ID3 and the key CK3, to form an activation key ACTIV1 linked to ID3, and
  • step SP45 consisting in loading the encrypted data block EIPi, the encrypted key EIPKj, the keys CK1, CK2 and CK3 into the non-volatile memory MEME
  • the personalization step is followed by an activation phase ACTIV comprising a step SA00 for receiving an activation key ACTIV2 via the contactless communication circuit CINT.
  • the step of executing the method by the microcontroller includes:
  • step SE40 consisting in reconstituting the key ACTV 1 from the data DT, the identifier ID3 and the key CK3, for example by means of the function FC3, and, if the key ACTIV2 is identical to the key ACTIV1, deciphering the encrypted data block EIPi from the encrypted key EIPKj, the identifiers ID1, ID2 and the keys CK1, CK2.
  • the identifier ID1 is preferably the unique identifier UID.
  • the encrypted data block EIPi has been, with the firmware, recopied by cloning into the non-volatile memory of another microcontroller, having a unique identifier UID' different from the identifier UID.
  • the cloned microcontroller will read its own identifier UID' during the decryption step of the encrypted data block EIPi and will not be able to decrypt it correctly, even if it holds the key IPKi (which is assumed to have been copied into its non-volatile memory during cloning).
  • This embodiment therefore offers a high degree of security against cloning but offers an encryption of medium robustness of the block of data IPi. 17
  • the embodiment of figure 3 offers the same degree of security against cloning as the embodiment of figure 2 if ID1 is chosen equal to the unique identifier UID. It offers more robust encryption of the data block IPi by involving the secondary key CK1 in the generation of the encrypted data block EIPî.
  • the CK1 key is for example used to encrypt the UID identifier, after which the encrypted identifier is combined with the IPKi key.
  • the embodiment of figure 4 offers the same degree of security against cloning as the embodiment of figure 3 if ID1 is chosen equal to the unique identifier UID. It offers a higher degree of security against an attack on the IPKi key thanks to the use of the secondary key CK2 and the identifier ID2 to encrypt the IPKi key before it is loaded into the memory MEM1.
  • the CK2 key can for example be used to encrypt the ID2 identifier, after which the encrypted identifier is combined with the IPKi key to obtain the EIPKi key. It may be wise, to maximize the protection of the IPKi key, to choose the unique identifier UID as the ID2 identifier.
  • FIG. 5 is similar to that of FIG. 4 and differs from the latter only in that the key IPKj is an OTA key, received after the personalization of the microcontroller. As will be seen later with the aid of a detailed example of embodiment, this embodiment can also be distinguished from the previous one by a different implementation of the step of encrypting the block of data IPi.
  • the microcontroller reconstitutes the key ACTIV1 from the datum DT, the key CK3 and the identifier ID3. If the identifier ID3 is chosen equal to the unique identifier UID, the use of the activation key ACTIV1 offers maximum security against cloning. Indeed a cloned microcontroller will read its own identifier UID' during the generation step of the ACTIV1 key, and will produce an ACTIVE key which can never be equal to the ACTIV2 key if this one is, as it should be, equal to the ACTIV 1 key. The cloned microcontroller will therefore not be able to correctly decipher the encrypted data block EIPî, even if it holds the key IPKi.
  • an inequality between the two keys ACTIV 1 and ACTIV2 does not prevent the decryption of the encrypted data block EIPî, but distorts the result of this decryption, so that the microcontroller cannot not exploit the decrypted data block.
  • the step of prior verification of the integrity of the decrypted data block IPi can then be provided for and be followed by a ban on using this data block if this verification is not conclusive. 18
  • the identifier ID3 is chosen equal to the unique identifier UID
  • this embodiment using the activation code ACTIV2 therefore offers a high degree of security against the cloning of the IPi data blocks. It can then be envisaged to lower the level of security against cloning offered by the other aspects of the method of the invention.
  • the identifier ID1 involved in the encryption of the IPi data block can, in this case, be a non-unique identifier of the integrated circuit, such as the firmware serial number FSN.
  • At least one of the identifiers ID 1 and ID3 be equal to the unique identifier UID.
  • the identifier ID2 it may be preferred that it be equal to the unique identifier UID for good protection of the key IPKi or IPKj.
  • the master key may be an EIPKj key received by download in an encrypted form, as in step SD00 of Figure 5.
  • FIG. 7 is a general representation of an embodiment of a method for designing and implementing an application program according to the invention. The process includes:
  • the DEV development phase is carried out in the offices of the application program designer, while the PERS personalization phase is carried out in a personalization factory belonging to a third party, or "personalization entity", to which the task of personalizing microcontrollers.
  • personalization entity is granted only a medium degree of trust.
  • the entire process, from development to personalization of the microcontrollers, must therefore be designed in such a way as to limit the risks of cloning by the personalization entity itself.
  • the blocks of data IPi will preferably be provided to it in an encrypted form. 19
  • the DEV development phase begins with the design of an application program in the form of SCODE source code. It comprises steps ST01, ST02 for transforming the source code into a program executable by a microcontroller, which are known per se to those skilled in the art.
  • the DEV development phase also includes a step ST03 for generating encryption keys and a step ST04 aimed at separating the blocks of IPi data to be protected from the rest of the FWR firmware, so that they can be encrypted without having to encrypt the firmware.
  • Step ST01 firstly comprises an operation 11 consisting in transforming the source code SCODE into object code OCODE by means of a compiler COMP.
  • the OCODE object code is then subjected to a 12 EXTRSEC section extraction operation, making it possible to generate a LISTF file (“List File”).
  • the LISTF file is then subjected to a PRELK pre-link operation 14 (“Prelink”) making it possible to generate on the one hand a link file LINKF (“Link File”) and on the other hand a configuration file CONFF (“ Config File”).
  • the link file LINKF and the object code OCODE are supplied to a link means LKR 20 generally called “Linker”, which supplies the application program in an ELF format.
  • the ELF format (Executable and Linkable Format), which is cited here only as an example, is a binary format widely used in the industry that satisfies the majority of needs. It is extensible, easily manipulated and can be used almost identically on many microcontroller architectures.
  • the encryption keys IPKi or IPKj, CK1, CK2, CK3 are generated by means of a random key generator, together with the firmware serial number FSN. The latter can also be generated during one of the previous steps ST01 or ST02.
  • IPKi or IPKj keys can be generated to encrypt several IPi data blocks with different keys. It will be considered in what follows that a single key IPKi or IPKj is generated for all the data blocks IPi, for the sake of simplifying the description.
  • step ST04 the application program in ELF format is subjected to a post-link operation POSTLK 40 (“Post Link”) which makes it possible to isolate the data blocks IPi from the firmware FWR.
  • the data blocks IPi are then encrypted from the key IPKi or IPKj during a step 44, to obtain the pre-encrypted data blocks PEIPi.
  • the PEIPi pre-encrypted data blocks are then 20 transferred to the customization entity, as well as the firmware F WR and the key IPKi or IPKj, the keys CK1, CK2, CK3 and the serial number FSN of the firmware.
  • Step ST04 includes various other operations known per se to those skilled in the art, such as the generation of libraries and tables mentioning the locations of the IPi data blocks inside the application program and the functionalities to which they are attached. These libraries and tables, which are also loaded into the non-volatile memory of the microcontrollers, are not represented in FIG. 7 for the sake of simplicity.
  • the PERS personalization phase includes a step ST06 for encrypting the blocks of data IPi according to the method of the invention, a step ST07 for encrypting the key IPKi or IPKj, and a step ST08 for personalizing the microcontrollers themselves.
  • the PERS personalization step also includes a step ST09 for producing this activation code.
  • a choice must be made as to the nature of the identifiers ID1, ID2, which can here be the unique identifier UID of each microcontroller to be personalized, or the serial number FSN of the firmware .
  • This choice is schematized by a step ST05 which includes:
  • GETUID 50 operation for extracting the UID identifier of the microcontroller to be personalized, for example by sending it a command to supply its UID identifier on an output port,
  • step SEL1 54 for selecting the identifier UID or the serial number FSN, to form the identifier ID1 and
  • step SEL255 for selecting the identifier UID or the serial number FSN, to form the identifier ID2.
  • FIG. 14 shows a particularly simple embodiment of step ST09, in which the identifier ID3 is used as data DT to be encrypted.
  • the identifier ID3 is therefore encrypted, during a step 100, from the key CK3 and by means of the function FC3, to obtain the key ACTIV1.
  • Step 100 is preceded by a step SEL3 56 of selecting the identifier UID or the serial number FSN to form the identifier ID3.
  • the datum DT can be a datum known to the 21 microcontroller, for example data extracted from the firmware or random data specific to the microcontroller, static or dynamically regenerated when it must be used for the calculation of the activation key ACTIV1.
  • identifiers ID1, ID2, ID3 are not made by the customization entity but was made by the designer of the application program during the DEV development step , because it also determines the configuration that the microcontrollers will have to use during execution phases of the method of the invention.
  • This predetermined configuration is schematized by blocks ST05B in FIGS. 10 and 11 described below, which relate to the execution phase of the method of the invention without using the activation code ACTIV1, and by blocks ST05C on the figures 12 and 13 described below, which relate to the execution phase of the method of the invention with use of the ACTIVE activation code.
  • the encryption functions FC1, FC2, FC3 are also defined at the program design stage. involved in the implementation of the method of the invention.
  • Step ST06 aims to link the encryption of the IPi blocks to the identifier ID1. It essentially comprises a step ENC1 72 for encrypting the blocks IPi by means of the function FC1, from the identifier ID1, the key IPKi or IPKj and the key CKl. According to the embodiment of the method of the invention which will be adopted, step 72 may be preceded by a step 70 of decrypting the encrypted blocks EIPi, not shown in FIG. 7, as will be seen later in relation with FIG. 8.
  • the personalization process has encrypted data blocks EPEIPi which are dependent on the identifier ID1, or over-encrypted data blocks EPEIPi which are also dependent on the identifier ID1, the latter being obtained by encrypting PEIPi pre-encrypted data blocks which are not dependent on the IDE identifier
  • the step ST07 essentially comprises a step ENC2 60 for encrypting the main key IPKi or IPKj by means of the function FC2, from the identifier ID2 and the key CK2, and provides an encrypted key EIPKi or EIPKj linked to the identifier ID2.
  • Step ST08 essentially comprises a step LDMEM1 80 for loading, into the non-volatile memory MEM1 of the microcontroller being personalized, the following data:
  • the activation key ACTIV1 for activating one or more IPi data blocks if this option has been selected by the designer of the application program.
  • the configured microcontroller forms a "PROTCHIP" integrated circuit protected against cloning.
  • Steps ST06 to ST08 are repeated for each microcontroller to be configured. In the context of industrial-scale production, these steps can be serialized or parallelized by automated serial or parallel processing of the electronic boards comprising the microcontrollers to be personalized.
  • Step ST06 includes a step 70 before the encryption step 72 previously described.
  • Step 70 is a decryption step, by means of the reciprocal function RLC1 and from the key IPKi, of the pre-encrypted data blocks PEIPi, providing the data blocks IPi in their original form, as found on leaving of step 40 of the DEV development phase ( Figure 7).
  • the data blocks IPi are then encrypted in step 72 to be made dependent on the identifier ID1.
  • Step 72 here comprises steps 720 and 722.
  • Step 720 is a step of encryption of the identifier ID1 by means of the function FC2 and from the key CK1, providing an encrypted identifier EID1.
  • the encrypted identifier EID1 is then combined with the key IPKi by means of an XOR (Exclusive Or) function to obtain a derived encryption key Kl.
  • This step amounts to masking the IPKi key using the encrypted identifier EID1 so that the masking is not easily reversible for a fraudster.
  • Step 722 is a step for encrypting the blocks IPi by means of the function FC1 and from the derived encryption key Kl, providing the encrypted data blocks EIPî. These are loaded into the non-volatile memory MEM1 of the microcontroller being personalized, during step ST08 previously described, which here includes the loading of the non-OTA key IPKi.
  • steps 720, 722 can be implemented in various other ways.
  • the decryption of the blocks of 23 pre-encrypted data PEIPi instead of being done in step 70 before step 722 of encryption linked to the identifier ID1, can be performed after step 722 by an appropriate choice of encryption functions. In this way, it is avoided to go through the production of decrypted data blocks IPi, between step 70 and step 722, on the personalization site managed by the personalization entity, and the data blocks IPi remain under encrypted form throughout the personalization process.
  • the masking of the key IPKi can be done in various other ways and by means of other logical functions than the XOR function, as well as the generation of the key Kl which makes the encrypted data blocks EIPi dependent on the identifier ID1.
  • Step ST07 comprises steps 62 and 63.
  • Step 62 is a step of encryption of the identifier ID2 by means of the function FC2 and at from the CK2 key, which provides an encrypted EID2 identifier.
  • the key IPKi is then masked by the encrypted identifier EID2 during step 63, by combining it therewith by means of an XOR function providing the encrypted key EIPKi.
  • Those skilled in the art may retain various other encryption methods for the EIPKi key, and/or masking functions other than the XOR function.
  • Step ST06 includes an encryption step 72B similar to step 72, but which is not preceded by the decryption step 70.
  • Step 72B is applied to the pre-encrypted data blocks PEIPi, and produces EPEIPi over-encrypted data blocks.
  • Step 72B includes the step 720 of producing the encrypted identifier EID1 previously described, and a step 722B of encryption, by means of the function FC1, of the pre-encrypted data blocks PEIPi.
  • step 721 It does not include the step 721 of prior masking of the key IPKj, so that the encrypted identifier EID1 provided by step 720 is used as encryption key in step 722B, to encrypt the pre-coded data blocks.
  • encrypted PEIPi and provide the over-encrypted EPEIPi data blocks.
  • the EPEIPi over-encrypted data blocks are loaded into the non-volatile memory MEM1 of the microcontroller being personalized, during step ST08 previously described.
  • step ST08 does not include the loading of the IPKj key, this being an OTA key intended to be transmitted later to the microcontroller.
  • FIG 9 also shows an embodiment of step ST07. This is identical to step ST07 in Figure 8, except that it is applied to 24 the key IPKj.
  • Step 62 thus provides the encrypted identifier EID2 and the key IPKj is masked during step 63 by the encrypted identifier EID2 by combining it therewith by means of an XOR function providing the encrypted key EIPKj.
  • FIG. 10 shows execution steps ST11, ST12 of the method of the invention by a microcontroller when the latter has been personalized by means of a non-OTA IPKi key in the manner described above in relation to FIG. 8 .
  • the microcontroller has, in its non-volatile memory MEM1, the encrypted key EIPKi, the secondary keys CK1, CK2, and the serial number FNS of the firmware.
  • the microcontroller also knows the identifiers ID1, ID2, ID.
  • a block ST05B schematized in the same way as step ST05 of figure 7, symbolizes the configuration of the microcontroller as to the choice of identifiers ID1, ID2.
  • Block ST05B includes two selectors SEL1 54 and SEL255 allowing to choose, for each identifier ID1, ID2, a value equal to the unique identifier UID or to the serial number FSN of the firmware.
  • the GETUID 50 operation for extracting the UID identifier from the microcontroller is not shown since the microcontroller has access to this identifier without needing to provide it on one of its outputs.
  • Step ST11 includes a step 110 of encryption of the identifier ID2 by means of the function FC2 and from the key CK2, providing the encrypted identifier EID2. It then includes a step 112 of unmasking the encrypted key EIPKi obtained by combining the encrypted EIPKi and the encrypted identifier EID2 by means of an XOR function. This step therefore constitutes the reciprocal of the masking step of step ST07 previously described.
  • Step ST12 includes a step 120 where the microcontroller encrypts the identifier ID1 by means of the function FC2 and from the key CK1, to obtain the encrypted identifier EID1.
  • the microcontroller then combines, by means of an XOR function, the key IPKi reconstituted in step 112 and the encrypted identifier EID1, to obtain the derived encryption key K1.
  • the microcontroller decrypts the encrypted data block EIPi from the key K1 and by means of the reciprocal function RFC1, then loads the decrypted data block IPi into the volatile memory MEM2.
  • the microcontroller uses the IPi data block to perform the corresponding functionality, then erases the data block or retains it for later reuse or overwriting it by loading another data block just decrypted. 25
  • FIG 11 shows execution steps ST 14, ST 15 of the method of the invention by a microcontroller when the latter has been personalized by means of an OTA key IPKj.
  • the microcontroller has, in its non-volatile memory MEM1, the encrypted key EIPKj received in OTA mode by the CPU, the secondary keys CK1, CK2 and the serial number FNS of the firmware.
  • Block ST05B symbolizes the configuration of the microcontroller as regards the choice of identifiers ID1, ID2.
  • Step ST 14 is identical to step ST11 previously described and includes a step 140 of encryption of the identifier ID2 by means of the function FC2 and from the key CK2, providing the encrypted identifier EID2.
  • Step 140 is followed by a step 142 of unmasking the encrypted key EIPKj by combining the encrypted key EIPKj and the encrypted identifier EID2 by means of an XOR function.
  • Step ST15 includes a step 150 where the microcontroller encrypts the identifier ID1 by means of the function FC2 and from the key CK1, to obtain the encrypted identifier EID1.
  • the microcontroller decrypts the over-encrypted data block EPEIPi by means of the RFC1 function and from the encrypted identifier EID 1 used as decryption key, to obtain the pre-encrypted data block PEIPi, i.e. the operation inverse to that of the personalization step 722 in FIG. 9.
  • the microcontroller decrypts the pre-encrypted data block PEIPi by means of the reciprocal function RFC1, using as the key of decryption the key IPKj provided by step 142.
  • the microcontroller then loads the decrypted data block IPi into the volatile memory MEM2.
  • step USE(IPi) 800 the microcontroller uses the data block IPi in the manner indicated above.
  • Figure 12 illustrates a variant of the embodiment of Figure 10 (IPKi non-OTA encryption key) when the activation key ACTIV1 is used to protect the microcontroller against cloning. It is assumed here that an activation key ACTIV2 has previously been received in OTA mode and loaded into the memory MEM1 by the CPU.
  • a block ST05C symbolizes the configuration of the microcontroller as to the choice of identifiers ID1, ID2, ID3.
  • the block ST05B comprises three selectors SEL1 54, SEL255 and SEL3 56 making it possible to choose, for each identifier ID1, ID2, ID3, a value equal to the unique identifier UID or to the serial number FSN of the firmware.
  • Step ST10 includes: 26
  • step 102 inserted between the steps 110 and 112 previously described, of combining, by means of an XOR function, the encrypted identifier EID2 and the activation key ACTIV2, the result of the combination being combined with the encrypted key EIPKi during step 112, and
  • step 103 carried out with the XOR function, consisting in combining the result of step 112 with the reconstituted key ACTIVE
  • step 103 is equal to the encryption key IPKi if the key ACTIV2 is identical to the key ACTIV 1. Indeed, by designating the XOR function by "+", the result of step 102 is equal to EID2 + ACTIV2.
  • the result of step 112 is equal to EID2 + EIPKi + ACTIV1, or EID2 + IPKi + EID2 + ACTIV2 (step ST07, FIG. 8) or even IPKi + ACTIV2 since the combination of two identical data by means of the XOR function gives a result equal to 0.
  • step 103 is therefore equal to IPKi + ACTIV2 + ACTIVE If the keys ACTIV 1 and ACTIV2 are equal, the result of step 103 is equal to the key IPKi i.e. the value sought for the proper execution of step 122 for generating the derived key K1. If the keys ACTIV1 and ACTIV2 are not equal, the result of step 103 will not be equal to the key IPKi, the key Kl will be erroneous and the decryption of the data blocks EIPi will provide an erroneous data block IPi. As the data block IPi, whether or not it has been correctly decrypted, is here transferred to the non-volatile memory to be used in step 800, it may be recommended, before such use, to carry out step here previously mentioned verification of its integrity.
  • Figure 13 illustrates a variant of the embodiment of figure 11 (OTA key IPKj) when the activation key ACTIV 1 is used to protect the microcontroller against cloning.
  • the previously described block ST05C symbolizes the configuration of the microcontroller as regards the choice of identifiers ID1, ID2, ID3.
  • Step ST13 includes:
  • step 132 inserted between the steps 140 and 142 previously described, of combining, by means of an XOR function, the encrypted identifier EID2 and the activation key ACTIV2, the result of the combination being combined with the encrypted key EIPKi during step 112,
  • step 133 consisting in combining, by means of an XOR function, the result of step 142 with the reconstituted key ACTIV1 during step 130.
  • step 133 is equal to the key IPKj if the key ACTIV2 is identical to the key ACTIV1, for the reasons indicated above in relation to FIG. 13. If the keys ACTIV1 and ACTIV2 are equal, the result of the 'step 103 is equal to IPKj, i.e. the decryption key necessary for the proper conduct of step 154. If the keys ACTIV 1 and ACTIV2 are not equal, the result of step 133 will be false, the key IPKj will be incorrect and the decryption of the PEIPi pre-encrypted data blocks will lead to an erroneous IPi data block. It can also be recommended here, before such use, to carry out the step of verifying the integrity of the IPi data block.
  • the reconstitution of the ACTIV1 key by the microcontroller constitutes an advantageous but optional alternative to an embodiment of the method of the invention in which the ACTIV1 key is loaded into the non-volatile memory MEM1 of the microcontroller during the personalization phase.
  • Other modes of production of the key ACTIV 1 can be provided, in particular according to a secret data located at a particular point of the memory MEM2, from the key CK3 and the identifier ID3.
  • the encryption and decryption steps involved in the method of the invention are susceptible to various variants with regard in particular to their combinations, the choice of a masking function other than the XOR function, and the choice of encryption functions FC1, FC2 and FC3.
  • the function FC1 can be an AES function in counter mode, generally designated “AES-CTR” (“Advanced Encryption Standard in Counter Mode”).
  • the FC2 function can be an AES function.
  • the FC3 function can be a light weight cryptography function LWC in counter mode, generally referred to as LWC-CTR (LightWeight Cryptography in Counter Mode), and be for example be implemented using the PRESENT algorithm.
  • the personalization process of a microcontroller requires knowledge of the identifier UID of each microcontroller concerned by the personalization phase 28
  • an identifier ID1 will be chosen which is not unique to each integrated circuit, such as the serial number FSN of the firmware cited in the foregoing as an example.
  • it will then be advisable to involve the activation key ACTIV 1 to control the process of decrypting the IPi data blocks, and to generate the activation key ACTIV1 from the unique identifier UID .
  • it may be desired that at least one of the two identifiers ID1 and ID3 be equal to the unique identifier UID.
  • the identifier ID1 is equal to the unique identifier UID. In this way, a cloned microcontroller that does not have the same unique identifier UID will be unable to correctly decipher the IPi data blocks when it comes to executing functions involving these IPi data blocks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé pour l'exécution d'un programme (FWR, IPi) par un microcontrôleur (CPU) en circuit intégré (IC1), le programme étant stocké dans la mémoire non volatile (MEM1) et comprenant au moins un bloc de données (IPi) nécessaire à l'exécution d'une fonctionnalité du programme. Le procédé comprend les étapes consistant à définir un premier identifiant (ID1, UID) du circuit intégré, générer une clé de chiffrement principale (IPKi, IPKj) du bloc de données, chiffrer le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant (ID1), puis le charger dans la mémoire non volatile. Pendant l'exécution du programme, le microcontrôleur est configuré pour déchiffrer le bloc de données chiffré (EIPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant (ID1), placer le bloc de données déchiffré dans la mémoire volatile (MEM2) du microcontrôleur, et utiliser le bloc de données déchiffré présent dans la mémoire volatile pour exécuter la fonctionnalité.

Description

1
PROCEDE POUR L’EXÉCUTION D’UN PROGRAMME CHARGE DANS LA MÉMOIRE NON VOLATILE D’UN MICROCONTRÔLEUR EN CIRCUIT
INTEGRE
La présente invention concerne un procédé pour l’exécution d’un programme par un microcontrôleur en circuit intégré, le microcontrôleur comprenant une mémoire non volatile et une mémoire volatile, le programme étant stocké dans la mémoire non volatile et comprenant au moins un bloc de données nécessaire à l’exécution d’une fonctionnalité du programme.
Les développeurs de programmes d’application embarqués dans les microcontrôleurs sont fréquemment confrontés au problème de la protection contre le clonage des programmes qu’ils réalisent. Un programme d’application est un programme permettant de contrôler un dispositif particulier dans une application particulière. Il peut s’agir par exemple d‘un programme contrôlant le fonctionnement d’un drone, d’un décodeur TV, d’un téléviseur, d’un appareil électroménager, etc.
Les développeurs de programmes d’application distinguent généralement, dans un programme d’application, un programme de base du microcontrôleur ou « firmware » (appelé aussi « micrologiciel »), et des fonctionnalités avancées du programme application, appelées généralement « blocs de PI ». Le terme « bloc de PI » est parfois considéré comme signifiant "bloc de propriété intellectuelle", désignant ainsi cet élément comme appartenant à la personne qui l’a conçu et prévu pour être concédé sous licence à des tiers. Dans le cadre de la présente demande, cependant, ce terme est utilisé pour désigner un bloc de données pouvant comprendre des données-programme (code) exécutables par le microcontrôleur ou des données d’application dont le microcontrôleur a besoin pour exécuter une fonctionnalité avancée, ou encore un mélange de ces deux types de données, sans qu’il soit nécessaire de savoir si ce bloc de données est soumis à des droits de propriété intellectuelle.
Un programme application chargé dans un microcontrôleur peut ainsi comprendre, en sus du firmware, un ou plusieurs blocs de PI, chaque bloc correspondant à une fonctionnalité avancée du dispositif ou contenant des données nécessaires à l’exécution d’une fonctionnalité avancée du dispositif. Par exemple, dans un programme embarqué dans un drone, le firmware peut être conçu pour permettre le pilotage manuel du drone tandis que des blocs de PI peuvent être prévus pour des fonctionnalités avancées du drone telles la détection et l’évitement automatique 2 d’obstacles, la réalisation de missions préprogrammées utilisant des données de géolocalisation fournies par un système de détection de position embarqué (par exemple GPS), etc. Dans un téléviseur, le firmware seul peut assurer certaines fonctionnalités de base du téléviseur telles la réception de chaînes hertziennes, tandis que des blocs de PI peuvent assurer des fonctionnalités plus avancées telles la réception de chaînes numériques et leur décodage. Dans un appareil électroménager tel une machine à laver, le firmware peut assurer des fonctionnalités de lavage de base, tandis que des blocs de PI peuvent assurer des fonctionnalités de lavage de certains types de linge ou des programmes de lavage spécifiques. Dans un synthétiseur de notes de musique, des blocs de PI peuvent contenir des données relatives à la synthétisation de certains sons d’instruments. Dans certains cas, certaines fonctionnalités avancées correspondant à un ou plusieurs blocs de PI peuvent être activées a posteriori, après la vente et la mise en service du dispositif, par l’achat d’une clé de déverrouillage de la fonctionnalité.
Le programme comprenant le firmware accompagné du ou des blocs de PI qui le complètent, est chargé dans la mémoire non volatile du microcontrôleur au cours d’une phase de personnalisation de celui- ci, après une phase de développement du programme. Cette phase de personnalisation est généralement réalisée lorsque le microcontrôleur a été assemblé sur une carte électronique destinée à être montée dans le dispositif auquel elle est destinée. Dans le cadre d’une fabrication en série, le programme application est chargé de manière automatisée dans les mémoires non volatiles d’un grand nombre de microcontrôleurs.
Lorsque le microcontrôleur est mis sur le marché, il devient possible, pour un fraudeur, de recopier le programme présent dans la mémoire non volatile du microcontrôleur pour le charger dans d’autres microcontrôleurs, qui vont alors former des clones fonctionnant comme le microcontrôleur original. Ce risque de clonage existe aussi au sein même des locaux de l’entité à laquelle est confiée la personnalisation des microcontrôleurs. Celle-ci peut en effet, une fois que les quantités de cartes électroniques commandées ont été réalisées, continuer à produire secrètement d’autres cartes électroniques destinées au marché clandestin.
Il peut donc être souhaité de prévoir une solution permettant de lutter contre le clonage d’un programme application, et plus particulièrement, selon la présente invention, le clonage de blocs de PI permettant l’exécution de fonctionnalités avancées. 3
Il est connu de chiffrer le programme application résidant dans la mémoire non volatile, celui- ci étant alors déchiffré et exécuté à la volée par le microcontrôleur au moyen d’une clé de déchiffrement présente dans la mémoire non volatile. Une telle solution permet de lutter contre le piratage de logiciel par ingénierie inverse mais ne permet pas de lutter contre le clonage, puisque le clonage de la mémoire non volatile inclut une copie de la clé de déchiffrement, de sorte que le microcontrôleur cloné est lui- même capable de déchiffrer et d’exécuter le programme application.
Le téléchargement d’une clé de déchiffrement après la mise en service du microcontrôleur est également envisageable, cependant un microcontrôleur cloné se comportera comme un microcontrôleur authentique s’il a accès à cette clé. Une telle solution nécessite toutefois une procédure d’authentification préalable du microcontrôleur par un serveur, qui est complexe à mettre en œuvre, contraignante pour l’utilisateur, et ne convient pas à toutes les applications.
D’autres soufrons connues pour protéger des programmes contre le clonage, reposent sur une étape d’authentification du produit en ligne basée sur le numéro de série du produit ou du circuit intégré.
Ainsi, le document WO2014014793 Al décrit un procédé d'authentification d'une instance d'application logicielle, comprenant la transmission, par un dispositif utilisateur, d'une demande d'accès à au moins un dispositif serveur, la demande comprenant des données d'identification d'application (« App ID ») associées à ladite instance d'application logicielle, et des étapes de transmission des données d'identification de session (session ID) au dispositif utilisateur, de transmission des données d'identification de session et l'App ID à un moteur anti-clone. Le moteur anti clone génère et transmet un jeton de défi au dispositif utilisateur, reçoit un jeton de réponse du dispositif utilisateur, traite le jeton de réponse pour déterminer si l'instance d'application logicielle est authentique, puis transmet un message d'autorisation du dispositif serveur en fonction de cette détermination.
Le document US7539868B2 propose une plate-forme informatique de protection d’un micrologiciel utilisant un certificat du fabricant. Le certificat du fabricant lie le micrologiciel du système à la plate-forme informatique et peut stocker des paramètres de configuration et des numéros d'identification de dispositif. Un vérificateur de données de plate-forme d'exécution sécurisée et un vérificateur d'exécution sécurisée vérifient le micrologiciel du système pendant le fonctionnement de la plate-forme informatique, pour s'assurer que le micrologiciel du système ou les informations du certificat du fabricant n'ont pas été modifiés. Les fichiers de programme d'application 4 et les fichiers de données sont liés au dispositif informatique particulier par un certificat de plate-forme. Un générateur de clé peut être utilisé pour générer une clé aléatoire et une clé chiffrée peut être générée en chiffrant la clé aléatoire à l'aide d'un numéro d'identification secret associé à la plate-forme informatique particulière. Seule la clé chiffrée est stockée dans le certificat de plate-forme.
Le document US20030061488A1 propose un procédé pour empêcher le clonage d'un dispositif électronique, comprenant les étapes consistant à générer une première signature électronique à partir d'un premier code d'identification et d'un second code d'identification, le second code d'identification étant approprié pour identifier de manière unique un composant matériel du dispositif électronique, déchiffrer une signature électronique chiffrée pour générer une seconde signature électronique, comparer la première signature électronique et la seconde signature électronique, et empêcher le fonctionnement normal du dispositif électronique si la première signature électronique et la seconde signature électronique ne sont pas identiques.
Le document WO2012033385A2 décrit une mémoire non volatile pour l'anti clonage comprenant une zone d'identification qui est située dans une zone spécifique de la mémoire non volatile, dans laquelle est stocké un identifiant ID pour l'identification de la mémoire non volatile. Un codeur d'identification est prévu pour modifier l'identifiant par une opération prédéfinie avec une erreur aléatoire. La zone d’identification comprend une première zone dans laquelle la lecture et l'écriture par un dispositif externe sont empêchées, et une seconde zone dans laquelle la lecture est possible par le dispositif externe en réponse à une commande de lecture. Le codeur d'identification modifie l'identification par une opération prédéfinie en utilisant l'erreur aléatoire, l'identification stockée dans la première zone de la zone d'identification, et une valeur pour le codage d'identification reçue d'un dispositif hôte.
Le document US8789746B2 propose un procédé d'authentification d'un produit utilisant des moteurs de chiffrement et de déchiffrement embarqués sur deux circuits intégrés, à savoir une puce -processeur de chiffrement/déchiffrement ou puce D, qui accompagne un produit, et une puce lecteur ou puce R, qui est expédiée indépendamment vers tout point d'authentification. Un numéro de série unique, dans un format chiffré ou non, est programmé dans la puce D, qui est ensuite fixé au produit. Pendant la procédure d'authentification, le numéro de série chiffré et déchiffré à bord de la puce D est transféré à la puce R. La puce R effectue ensuite un déchiffrement du numéro de série de la première puce si ce numéro de série est sous forme chiffrée, ou un chiffrement du numéro de série de la première puce si ce numéro de série est sous 5 forme non chiffrée. La puce R compare ensuite son résultat de déchiffrement ou de chiffrement avec les versions correspondantes déchiffrées ou chiffrées du numéro de série reçues de la puce D. Si les résultats du déchiffrement ou du chiffrement pour les deux puces sont identiques, alors la puce R signale un produit authentique, sinon elle rejette le produit comme faux.
De façon générale, ces solutions sont complexes à mettre en œuvre et nécessitent des moyens de connexion au réseau Internet et/ou des programmes et des serveurs de lutte contre le clonage qui sont complexes et coûteux. D’autres s’avèrent insuffisantes pour lutter efficacement contre le clonage. Ainsi, la présente invention vise un procédé pour l’exécution d’un programme par un microcontrôleur qui permette de mettre en œuvre une protection contre le clonage d’un bloc de PI qui soit simple et peu coûteuse, et un dispositif configuré pour permettre la mise en œuvre de ce procédé.
Plus particulièrement, la présente invention prévoit un procédé pour l’exécution d’un programme par un microcontrôleur en circuit intégré, le microcontrôleur comprenant une mémoire non volatile et une mémoire volatile, le programme étant stocké dans la mémoire non volatile et comprenant au moins un bloc de données nécessaire à l’exécution d’une fonctionnalité du programme, le procédé comprenant les étapes consistant à définir un premier identifiant du circuit intégré, générer une clé de chiffrement principale du bloc de données, chiffrer le bloc de données à partir de la clé de chiffrement principale et du premier identifiant, charger ou télécharger, dans la mémoire non volatile, le bloc de données sous sa forme chiffrée, charger ou télécharger la clé de chiffrement principale dans la mémoire non volatile, et, au moyen du microcontrôleur : déchiffrer le bloc de données chiffré à partir de la clé de chiffrement principale et du premier identifiant, placer le bloc de données déchiffré dans la mémoire volatile du microcontrôleur, et utiliser le bloc de données déchiffré présent dans la mémoire volatile pour exécuter la fonctionnalité.
Selon un mode de réalisation, l’étape consistant à chiffrer le bloc de données à partir de la clé de chiffrement principale et du premier identifiant, comprend les étapes consistant à générer une première clé de chiffrement secondaire, chiffrer le premier identifiant au moyen de la première clé de chiffrement secondaire, pour obtenir un premier identifiant chiffré, chiffrer le bloc de données à partir de la clé de chiffrement principale et du premier identifiant chiffré, et charger la première clé de chiffrement secondaire dans la mémoire non volatile du microcontrôleur. 6
Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du microcontrôleur, déchiffrer le bloc de données chiffré à partir de la clé de chiffrement principale, du premier identifiant, et de la première clé de chiffrement secondaire, et pendant le déchiffrement du bloc de données chiffré, chiffrer le premier identifiant au moyen de la première clé de chiffrement secondaire, pour obtenir le premier identifiant chiffré.
Selon un mode de réalisation, l’étape consistant à chiffrer le bloc de données à partir de la clé de chiffrement principale et du premier identifiant chiffré, comprend les étapes consistant à masquer la clé de chiffrement principale au moyen du premier identifiant chiffré, pour obtenir une clé de chiffrement dérivée, et chiffrer le bloc de données à partir de la clé de chiffrement dérivée, pour obtenir le bloc de données sous sa forme chiffrée.
Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du microcontrôleur, masquer la clé de chiffrement principale au moyen du premier identifiant chiffré, pour obtenir la clé de chiffrement dérivée, et déchiffrer le bloc de données chiffré à partir de la clé de chiffrement dérivée.
Selon un mode de réalisation, l’étape consistant à chiffrer le bloc de données à partir de la clé de chiffrement principale et du premier identifiant chiffré, comprend les étapes consistant à chiffrer le bloc de données à partir de la clé de chiffrement principale, pour obtenir un bloc de données pré-chiffré, et chiffrer le bloc de données pré-chiffré au moyen du premier identifiant chiffré, pour obtenir un bloc de données surchiffré formant le bloc de données sous sa forme chiffrée chargé dans la mémoire non volatile du microcontrôleur.
Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du microcontrôleur, déchiffrer le bloc de données surchiffré à partir du premier identifiant chiffré, pour obtenir le bloc de données pré-chiffré, et déchiffrer le bloc de données pré-chiffré à partir de la clé de chiffrement principale, pour obtenir le bloc de donnée déchiffré.
Selon un mode de réalisation, le premier identifiant du circuit intégré est l’un ou l’autre des identifiants suivants : un identifiant unique du circuit intégré, tel son numéro de série, ou un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série du programme chargé dans la mémoire non volatile du microcontrôleur.
Selon un mode de réalisation, le procédé comprend les étapes consistant à définir un deuxième identifiant du circuit intégré, masquer la clé de chiffrement principale 7 avec le deuxième identifiant avant de la charger ou la télécharger dans la mémoire non volatile du microcontrôleur, et la charger ou la télécharger sous sa forme masquée dans la mémoire non volatile du microcontrôleur.
Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du microcontrôleur, démasquer la clé de chiffrement principale masquée au moyen du deuxième identifiant avant de déchiffrer le bloc de données chiffré.
Selon un mode de réalisation, l’étape consistant à masquer la clé de chiffrement principale avec le deuxième identifiant comprend les étapes consistant à générer une deuxième clé de chiffrement secondaire, chiffrer le deuxième identifiant au moyen de la deuxième clé de chiffrement secondaire, pour obtenir un deuxième identifiant chiffré, et masquer la clé de chiffrement principale avec le deuxième identifiant chiffré pour obtenir la forme masquée chargée ou téléchargée dans la mémoire non volatile du microcontrôleur.
Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du microcontrôleur, chiffrer le deuxième identifiant au moyen de la deuxième clé de chiffrement secondaire, pour obtenir le deuxième identifiant chiffré, et démasquer la clé de chiffrement principale masquée au moyen du deuxième identifiant chiffré avant de déchiffrer le bloc de données chiffré.
Selon un mode de réalisation, le deuxième identifiant du circuit intégré est l’un ou l’autre des identifiants suivants : un identifiant unique du circuit intégré, tel son numéro de série, ou un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série du programme chargé dans la mémoire non volatile du microcontrôleur.
Selon un mode de réalisation, le procédé comprend les étapes consistant à générer une troisième clé de chiffrement secondaire, définir un troisième identifiant du circuit intégré, générer une première clé d’activation de la fonctionnalité, par chiffrement d’une donnée à partir du troisième identifiant et de la troisième clé de chiffrement secondaire, et, au moyen du microcontrôleur, recevoir une deuxième clé d’activation, reconstituer la première clé d’activation, ne pas déchiffrer ou déchiffrer de manière incorrecte le bloc de données chiffré si la deuxième clé d’activation n’est pas égale à la première clé d’activation,
Selon un mode de réalisation, le procédé comprend l’étape consistant à, au moyen du microcontrôleur, injecter les première et deuxième clés d’activation dans des étapes de déchiffrement du bloc de données chiffré, de manière que le résultat du 8 déchiffrement du bloc de données chiffré soit erroné si la deuxième clé d’activation n’est pas égale à la première clé d’activation.
Selon un mode de réalisation, le procédé comprend une étape de contrôle, par le microcontrôleur, de l’intégrité du bloc de données déchiffré avant de l’utiliser, dans l’hypothèse où le bloc de données n’aurait pas été déchiffré correctement en raison de la réception d’une clé d’activation incorrecte, et une étape de configuration du microcontrôleur pour qu’il ne tente pas d’exécuter la fonctionnalité si le contrôle d’intégrité n’est pas positif.
Selon un mode de réalisation, le troisième identifiant du circuit intégré est l’un ou l’autre des identifiants suivants : un identifiant unique du circuit intégré, tel son numéro de série, ou un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série du programme chargé dans la mémoire non volatile du microcontrôleur.
Des modes de réalisation de l’invention concernent également un microcontrôleur en circuit intégré comprenant une mémoire non volatile et une mémoire volatile, la mémoire non volatile comprenant un programme exécutable comprenant au moins un bloc de données nécessaire à l’exécution d’une fonctionnalité du programme. Le bloc de données est stocké dans la mémoire non volatile sous une forme chiffrée générée à partir d’une clé de chiffrement principale et d’un premier identifiant du circuit intégré, la clé de chiffrement principale étant stockée dans la mémoire non volatile du microcontrôleur, et le microcontrôleur est configuré pour déchiffrer le bloc de données chiffré à partir de la clé de chiffrement principale et du premier identifiant, placer le bloc de données déchiffré dans la mémoire volatile du microcontrôleur, et utiliser le bloc de données déchiffré présent dans la mémoire volatile pour exécuter la fonctionnalité.
Selon un mode de réalisation, la mémoire non volatile comprend en outre une première clé de chiffrement secondaire, le microcontrôleur étant configuré pour déchiffrer le bloc de données chiffré à partir de la clé de chiffrement principale, du premier identifiant, et de la première clé de chiffrement secondaire, et pendant le déchiffrement du bloc de données chiffré, chiffrer le premier identifiant au moyen de la première clé de chiffrement secondaire, pour obtenir un premier identifiant chiffré.
Selon un mode de réalisation, le microcontrôleur est configuré pour masquer la clé de chiffrement principale au moyen du premier identifiant chiffré, pour obtenir une clé de chiffrement dérivée, et déchiffrer le bloc de données chiffré à partir de la clé de chiffrement dérivée. 9
Selon un mode de réalisation, le bloc de données est stocké dans la mémoire non volatile sous une forme surchiffrée, le microcontrôleur étant configuré pour déchiffrer le bloc de données surchiffré à partir du premier identifiant chiffré, pour obtenir un bloc de données pré-chiffré, et déchiffrer le bloc de données pré-chiffré à partir de la clé de chiffrement principale, pour obtenir le bloc de donnée déchiffré.
Selon un mode de réalisation, le premier identifiant du circuit intégré est l’un ou l’autre des identifiants suivants : un identifiant unique du circuit intégré, tel son numéro de série, ou un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série du programme chargé dans la mémoire non volatile.
Selon un mode de réalisation, la clé de chiffrement principale est stockée dans la mémoire volatile sous une forme masquée obtenue par masquage de la clé par un deuxième identifiant du circuit intégré, le microcontrôleur étant configuré pour démasquer la clé de chiffrement principale masquée au moyen du deuxième identifiant avant de déchiffrer le bloc de données chiffré.
Selon un mode de réalisation, la mémoire non volatile comprend en outre une deuxième clé de chiffrement secondaire, le microcontrôleur étant configuré pour chiffrer le deuxième identifiant au moyen de la deuxième clé de chiffrement secondaire, pour obtenir un deuxième identifiant chiffré, et démasquer la clé de chiffrement principale masquée au moyen du deuxième identifiant chiffré avant de déchiffrer le bloc de données chiffré.
Selon un mode de réalisation, le deuxième identifiant du circuit intégré est l’un ou l’autre des identifiants suivants : un identifiant unique du circuit intégré, tel son numéro de série, ou un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série du programme chargé dans la mémoire non volatile.
Selon un mode de réalisation, le microcontrôleur est configuré pour générer une première clé d’activation de la fonctionnalité, par chiffrement d’une donnée à partir du troisième identifiant et de la troisième clé de chiffrement secondaire, recevoir une deuxième clé d’activation, ne pas déchiffrer ou déchiffrer de manière incorrecte le bloc de données chiffré si la deuxième clé d’activation n’est pas égale à la première clé d’activation.
Selon un mode de réalisation, le microcontrôleur est configuré pour injecter les première et deuxième clés d’activation dans des étapes de déchiffrement du bloc de 10 données chiffré, de manière que le résultat du déchiffrement du bloc de données chiffré soit erroné si la deuxième clé d’activation n’est pas égale à la première clé d’activation.
Selon un mode de réalisation, le microcontrôleur est configuré pour contrôler l’intégrité du bloc de données déchiffré avant son utilisation, dans l’hypothèse où le bloc de données n’aurait pas été déchiffré correctement en raison de la réception d’une clé d’activation incorrecte, et ne pas tenter d’exécuter la fonctionnalité si le contrôle d’intégrité n’est pas positif.
Selon un mode de réalisation, le troisième identifiant du circuit intégré est l’un ou l’autre des identifiants suivants : un identifiant unique du circuit intégré, tel son numéro de série, ou un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série du programme chargé dans la mémoire non volatile.
Ces caractéristiques, ainsi que d’autres de la présente invention, seront mieux comprises à la lecture de la description suivante de divers modes de réalisation d’un procédé selon l’invention, en relation avec les figures jointes parmi lesquelles :
- la figure 1 montre un microcontrôleur en circuit intégré configuré pour mettre en œuvre un ou plusieurs modes de réalisation du procédé selon l’invention,
- la figure 2 illustre un premier mode de réalisation du procédé selon l’invention,
- la figure 3 illustre un deuxième mode de réalisation du procédé selon l’invention,
- la figure 4 illustre un troisième mode de réalisation du procédé selon l’invention,
- la figure 5 illustre un quatrième mode de réalisation du procédé selon l’invention,
- la figure 6 illustre un cinquième mode de réalisation du procédé selon l’invention,
- la figure 7 montre des étapes générales de développement d’un programme application et de personnalisation du microcontrôleur selon le procédé de l’invention,
- la figure 8 montre de manière plus détaillée des étapes de personnalisation du microcontrôleur selon l’un des modes de réalisation précités du procédé de l’invention,
- la figure 9 montre de manière plus détaillée des étapes de personnalisation du microcontrôleur selon un autre des modes de réalisation précités du procédé de l’invention,
- la figure 10 montre de manière plus détaillée des étapes d’exécution du procédé de l’invention par le microcontrôleur selon l’un des modes de réalisation précités du procédé de l’invention,
- la figure 11 montre de manière plus détaillée des étapes d’exécution du procédé de l’invention par le microcontrôleur selon un autre des modes de réalisation précités du procédé de l’invention, 11
- la figure 12 montre de manière plus détaillée des étapes d’exécution du procédé de l’invention par le microcontrôleur selon encore un autre des modes de réalisation précités du procédé de l’invention, et
- la figure 13 montre de manière plus détaillée des étapes d’exécution du procédé de l’invention par le microcontrôleur selon encore un autre des modes de réalisation précités du procédé de l’invention, et
- la figure 14 montre un mode de réalisation d’une étape représentée sous forme de bloc en figure 7.
La figure 1 montre schématiquement l’architecture d’un microcontrôleur en circuit intégré ICI, soit un microcontrôleur réalisé sur une microplaquette de semi- conducteur, utilisé pour mettre en œuvre le procédé selon l’invention. Le microcontrôleur comprend classiquement un CPU (unité centrale), une banque de registres RBANK, une mémoire non volatile MEM1, par exemple une mémoire de type FLASH, et une mémoire volatile MEM2, par exemple une mémoire de type RAM. La banque de registres RBANK et les mémoires MEM1, MEM2 sont reliées au CPU par un bus d’adresse ADB et un bus de données DTB. Le microcontrôleur comprend également un circuit d’interface de communication sans contact CINT permettant au CPU de recevoir des données OTA (de l’anglais « Over The Air »), en d’autres termes des données téléchargées. Le circuit CINT peut utiliser une ou plusieurs technologies de communication sans contact, par exemple NFC, Wifi, 4G, etc.
La mémoire non volatile MEM1 reçoit un programme application comprenant un programme de base, ou firmware FWR, et des blocs de données IPi (IPI, IP2,... IPn). Chaque bloc de données IPi comprend des données-programme exécutables par le microcontrôleur, des données d’application ou un mélange de ces deux types de données, que le CPU doit utiliser pour exécuter des fonctionnalités avancées du programme application. La banque de registre RBANK (ou tout autre registre non volatile du microcontrôleur) contient par ailleurs un identifiant unique UID du circuit intégré. Cet identifiant est gravé pendant le processus de fabrication du circuit intégré ICI ou est régénéré de manière dynamique, au démarrage ou à la demande du CPU, par un circuit matériel dédié. L’identifiant UID, qu’il soit statique ou généré dynamiquement à la demande, est immuable et identifie de manière unique le circuit intégré. L’identifiant UID peut par exemple être le numéro de série du circuit intégré sur lequel le microcontrôleur a été implanté ou un identifiant de type PUF (de l’anglais 12
« Physically Unclonable Function » ou « Fonction Physiquement non Clonable »), ou une combinaison des deux.
La mémoire non volatile MEM1 comprend par ailleurs au moins une fonction de chiffrement symétrique et sa fonction de déchiffrement correspondante, appelée dans ce qui suit « fonction réciproque ». La fonction de chiffrement et sa réciproque peuvent être identiques, selon le type de fonction de chiffrement retenue. Plus particulièrement, la mémoire MEM1 comprend ici une fonction FC1 et sa réciproque RFC1, une fonction FC2 et sa réciproque RFC2, et une fonction FC3 et sa réciproque RFC3. Elle comprend également une clé de chiffrement principale IPKi ou IPKj, des clés de chiffrement secondaires CK1, CK2 et CK3 (clés secrètes) et un identifiant non unique du circuit intégré, par exemple un numéro de série FSN du firmware. On désigne ici par « IPKi » une clé de chiffrement stockée dans la mémoire non volatile lors d’une phase de personnalisation du circuit intégré, et par « IPKj » une clé de chiffrement OTA, c’est-à-dire reçue par le microcontrôleur via le circuit d’interface de communication CINT après sa mise en service.
Selon une caractéristique générale du procédé de l’invention, les blocs de données IPi (IPI, IP2...IPn) sont stockés dans la mémoire non volatile sous une forme chiffrée EIPi (EIP1, EIP2...EIPn) obtenue au moyen d’une fonction de chiffrement connue du microcontrôleur, ici la fonction FC1. Toujours selon une caractéristique générale du procédé de l’invention, ce chiffrement est réalisé à partir de la clé principale IPKi ou IPKj et d’un identifiant ID1 du circuit intégré.
L’identifiant ID1 peut, selon le mode de réalisation retenu et en fonction du degré de protection contre le clonage recherché, être l’identifiant unique UID du circuit intégré ou un identifiant non unique tel que le numéro de série FSN du firmware. Le chiffrement du bloc de données IPi est donc lié à l’identifiant ID1. Lorsque, durant l’exécution du firmware, le CPU doit faire appel à un bloc de données IPi pour exécuter une fonctionnalité, le CPU déchiffre le bloc de données chiffré EIPi à partir de l’identifiant ID1 et de la clé IPKi ou IPKj, puis charge le bloc de données déchiffré IPi dans une zone tampon IPBUF de la mémoire volatile MEM2.
Lorsqu’un bloc de données IPi a été déchiffré, le CPU utilise ce bloc de données à partir de la mémoire volatile MEM2, sans le charger dans la mémoire non volatile MEM1, pour exécuter la fonctionnalité correspondante. Le microcontrôleur efface ensuite le bloc de données IPi de la mémoire volatile ou le laisse dans la zone tampon IPBUF jusqu’à ce qu’il soit réutilisé ou écrasé par un autre bloc de données IPi venant d’être déchiffré. Le CPU peut préalablement vérifier l’intégrité du bloc de données IPi, 13 avant de G utiliser, par exemple en vérifiant que son code de redondance cyclique CRC (Cyclic Redundancy Check) est valide.
Le procédé de l’invention peut faire l’objet de divers modes de réalisation dont certains sont illustrés schématiquement sur les figures 2 à 6. On distingue, dans chaque mode de réalisation, une phase de personnalisation PERS du microcontrôleur, et une phase d’exécution du procédé de l’invention EXEC au cours de laquelle une fonctionnalité nécessitant l’utilisation d’un bloc de données IPi est exécutée par le microcontrôleur.
Dans le mode de réalisation représenté sur la figure 2, l’étape de personnalisation comprend :
- une étape SPO de génération d’une clé de chiffrement symétrique IPKi,
- une étape SP1 consistant à définir l’identifiant ID1, qui peut être l’identifiant unique UID ou un identifiant non unique tel que le numéro de série FSN du firmware,
- une étape SP2 de chiffrement d’un bloc IPi à partir de la clé IPKi et de l’identifiant ID1, par exemple au moyen de la fonction FC1, pour obtenir un bloc de données chiffré EIPi lié à l’identifiant ID1, et
- une étape SP5 de chargement de la clé IPKi et du bloc de données chiffré EIPi dans la mémoire MEME
L’étape d’exécution du procédé par le microcontrôleur comprend : - une étape SEO de déchiffrement du bloc de données chiffré EIPi à partir de la clé IPKi et de l’identifiant ID 1 , par exemple au moyen de la fonction réciproque RFC 1 , et
- une étape SE1 de chargement du bloc de données déchiffré IPi dans la zone tampon IPBUF de la mémoire MEM2, suivie d’une étape d’utilisation du bloc de données IPi. Cette utilisation peut être précédée d’une étape de vérification du bloc de données IPi et suivie d’une étape d’effacement de celui-ci.
Dans le mode de réalisation représenté sur la figure 3, l’étape de personnalisation comprend :
- une étape SP 10 consistant à générer les clés de chiffrement symétrique IPKi et CKl,
- une étape SP11 consistant à définir l’identifiant ID1, qui comme précédemment peut être l’identifiant unique UID ou un identifiant non unique tel que le numéro de série FSN du firmware, 14
- une étape SP 12 de chiffrement du bloc de données IPi à partir de la clé IPKi, de l’identifiant ID1 et de la clé CK1, par exemple au moyen de la fonction FC1, pour obtenir un bloc de données chiffré EIPi lié à l’identifiant ID1, et
- une étape SP 15 de chargement du bloc de données chiffré EIPi, de la clé IPKi et de la clé CK1 dans la mémoire MEME
L’étape d’exécution du procédé par le microcontrôleur comprend :
- une étape SE 10 de déchiffrement du bloc de données chiffré EIPi à partir de la clé IPKi, de l’identifiant ID1 et de la clé CK1, par exemple au moyen de la fonction réciproque RFC1, et
- une étape SE11 de chargement du bloc de données déchiffré IPi dans la zone tampon IPBUF, suivie d’une étape d’utilisation du bloc de données IPi. Comme précédemment, cette utilisation peut être précédée d’une étape de vérification du bloc de données IPi et être suivie d’une étape d’effacement du bloc de données.
Dans le mode de réalisation représenté sur la figure 4, l’étape de personnalisation comprend :
- une étape SP20 consistant à générer les clés de chiffrement symétrique IPKi, CK1, et CK2,
- une étape SP21 consistant à définir les identifiants ID1, ID2, chacun de ces identifiants pouvant être l’identifiant unique UID ou un identifiant non unique tel que le numéro de série FSN du firmware,
- une étape SP22 de chiffrement du bloc de données IPi à partir de la clé IPKi, de l’identifiant ID1 et de la clé CK1, par exemple au moyen de la fonction FC1, pour obtenir un bloc de données chiffré EIPi lié à l’identifiant ID1,
- une étape SP23 de chiffrement de la clé IPKi à partir de l’identifiant ID2 et de la clé CK2, par exemple au moyen de la fonction FC2, pour obtenir une clé chiffrée EIPKi liée à l’identifiant ID2, et
- une étape SP25 consistant à charger le bloc de données chiffré EIPi, la clé chiffrée EIPKi et les clés CK1 et CK2 dans la mémoire MEME
L’étape d’exécution du procédé par le microcontrôleur comprend :
- une étape SE20 de déchiffrement du bloc de données chiffré EIPi à partir de la clé chiffrée EIPKi, de l’identifiant ID1, de la clé CK1, de l’identifiant ID2 et de la clé CK2, par exemple au moyen de la fonction réciproque RFC1, et
- une étape SE21 de chargement du bloc de données déchiffré IPi dans la zone tampon IPBUF, suivie d’une étape d’utilisation du bloc de données IPi. Comme 15 précédemment, cette utilisation peut être précédée d’une étape de vérification du bloc de données IPi et être suivie d’une étape d’effacement du bloc de données.
Dans le mode de réalisation représenté sur la figure 5, l’étape de personnalisation comprend : - une étape SP30 consistant à générer les clés de chiffrement symétrique IPKj,
CK1, et CK2,
- une étape SP31 consistant à définir les identifiants ID1, ID2, chacun de ces identifiants pouvant comme précédemment être l’identifiant unique UID ou un identifiant non unique tel que le numéro de série FSN du firmware, - une étape SP32 de chiffrement du bloc de données IPi à partir de IPKj, l’identifiant ID1 et la clé de chiffrement CK1, par exemple au moyen de la fonction FC1, pour obtenir un bloc de données chiffré EIPi lié à l’identifiant ID1,
- une étape SP33 de chiffrement de la clé IPKj à partir de l’identifiant ID2 et de la clé CK2, par exemple au moyen de la fonction FC2, pour obtenir une clé chiffrée EIPKj liée à l’identifiant ID2, et
- une étape SP35 consistant à charger le bloc de données chiffré EIPi et les clés CK1, CK2 dans la mémoire MEME
L’étape de personnalisation est suivie d’une étape SD00 de réception de la clé chiffrée EIPKj par téléchargement de celle-ci via le circuit CINT (clé OTA). Le CPU charge ensuite cette clé dans la mémoire non volatile MEME
L’étape d’exécution du procédé par le microcontrôleur comprend :
- une étape SE30 de déchiffrement du bloc de données chiffré EIPi à partir de la clé chiffrée EIPKj, les identifiants ID1, ID2 et les clés CK1, CK2, par exemple au moyen de la fonction réciproque RFC1, et - une étape SE31 de chargement du bloc de données déchiffré IPi dans la zone tampon IPBUF, suivie d’une étape d’utilisation du bloc de données IPi. Comme précédemment, cette utilisation peut être précédée d’une étape de vérification du bloc de données IPi et être suivie d’une étape d’effacement du bloc de données.
Dans le mode de réalisation représenté sur la figure 6, l’étape de personnalisation comprend :
- une étape SP40 consistant à générer les clés de chiffrement symétrique IPKi, CK1, CK2 et CK3,
- une étape SP41 consistant à définir les identifiants ID1, ID2, ID3, chacun de ces identifiants pouvant être l’identifiant unique UID ou un identifiant non unique tel que le numéro de série FSN du firmware, 16
- une étape SP42 de chiffrement du bloc de données IPi à partir de la clé IPKi, de l’identifiant ID1 et de la clé CK1, par exemple au moyen de la fonction FC1, pour obtenir un bloc de données chiffré EIPi lié à l’identifiant ID1,
- une étape SP43 de chiffrement de la clé IPKi à partir de l’identifiant ID2 et de la clé CK2, par exemple au moyen de la fonction FC2, pour obtenir une clé chiffrée
EIPKi liée à l’identifiant ID2,
- une étape SP44 consistant à générer une clé d’activation ACTIV1 par chiffrement d’une donnée DT, par exemple au moyen de la fonction FC3, à partir de l’identifiant ID3 et de la clé CK3, pour former une clé d’activation ACTIV1 liée à ID3, et
- une étape SP45 consistant à charger le bloc de données chiffré EIPi, la clé chiffrée EIPKj, les clés CK1, CK2 et CK3 dans la mémoire non volatile MEME
L’étape de personnalisation est suivie d’une phase d’activation ACTIV comprenant une étape SA00 de réception d’une clé d’activation ACTIV2 via le circuit de communication sans contact CINT.
L’étape d’exécution du procédé par le microcontrôleur comprend :
- une étape SE40 consistant à reconstituer la clé ACTV 1 à partir de la donnée DT, l’identifiant ID3 et la clé CK3, par exemple au moyen de la fonction FC3, et, si la clé ACTIV2 est identique à la clé ACTIV1, déchiffrer le bloc de données chiffré EIPi à partir de la clé chiffrée EIPKj, les identifiants ID1, ID2 et les clés CK1, CK2.
- une étape SE41 de chargement du bloc de données déchiffré IPi dans la zone tampon IPBUF, suivie d’une étape d’utilisation du bloc de données IPi. Comme précédemment, cette utilisation peut être précédée d’une étape de vérification du bloc de données IPi et être suivie d’une étape d’effacement du bloc de données. Dans le mode de réalisation de la figure 2, l’identifiant ID1 est de préférence l’identifiant unique UID. Supposons que le bloc de données chiffré EIPi ait été, avec le firmware, recopié par clonage dans la mémoire non volatile d’un autre microcontrôleur, ayant un identifiant unique UID’ différent de l’identifiant UID. Le microcontrôleur cloné lira son propre identifiant UID’ pendant l’étape de déchiffrement du bloc de données chiffré EIPi et ne pourra pas le déchiffrer correctement, et ce même s’il détient la clé IPKi (que l’on suppose avoir été copiée dans sa mémoire non volatile pendant le clonage). Ce mode de réalisation offre donc un haut degré de sécurité contre le clonage mais offre un chiffrement d’un robustesse moyenne du bloc de données IPi. 17
Le mode de réalisation de la figure 3 offre le même degré de sécurité contre le clonage que le mode de réalisation de la figure 2 si ID1 est choisi égal à l’identifiant unique UID. Il offre un chiffrement plus robuste du bloc de données IPi en faisant intervenir la clé secondaire CK1 dans la génération du bloc de données chiffré EIPî. La clé CK1 est par exemple utilisée pour réaliser un chiffrement de l’identifiant UID, après quoi l’identifiant chiffré est combiné à la clé IPKi.
Le mode de réalisation de la figure 4 offre le même degré de sécurité contre le clonage que le mode de réalisation de la figure 3 si ID1 est choisi égal à l’identifiant unique UID. Il offre un degré de sécurité supérieur contre une attaque sur la clé IPKi grâce à l’usage de la clé secondaire CK2 et de l’identifiant ID2 pour chiffrer la clé IPKi avant son chargement dans la mémoire MEM1. La clé CK2 peut par exemple être utilisée pour réaliser un chiffrement de l’identifiant ID2, après quoi l’identifiant chiffré est combiné à la clé IPKi pour obtenir la clé EIPKi. Il peut être judicieux, pour maximaliser la protection de la clé IPKi, de choisir l’identifiant unique UID comme identifiant ID2.
Le mode de réalisation de la figure 5 est similaire à celui de la figure 4 et ne se distingue de celui-ci que par le fait que la clé IPKj est une clé OTA, reçue après la personnalisation du microcontrôleur. Comme on le verra plus loin à l’aide d’un exemple de réalisation détaillé, ce mode de réalisation peut également se distinguer du précédent par une mise en œuvre différente de l’étape de chiffrement du bloc de données IPi.
Dans le mode de réalisation de la figure 6, le microcontrôleur reconstitue la clé ACTIV1 à partir de la donnée DT, la clé CK3 et l’identifiant ID3. Si l’identifiant ID3 est choisi égal à l’identifiant unique UID, l’utilisation de la clé d’activation ACTIV1 offre une sécurité maximale contre le clonage. En effet un microcontrôleur cloné lira son propre identifiant UID’ pendant l’étape de génération de la clé ACTIV1, et produira une clé ACTIVE qui ne pourra jamais être égale à la clé ACTIV2 si celle-ci est, comme il se doit, égale à la clé ACTIV 1. Le microcontrôleur cloné ne pourra donc pas déchiffrer correctement le bloc de données chiffré EIPî, et ce même s’il détient la clé IPKi. Dans un mode de réalisation, il peut être prévu qu’une inégalité entre les deux clés ACTIV 1 et ACTIV2 n’empêche pas le déchiffrement du bloc de données chiffré EIPî, mais fausse le résultat de ce déchiffrement, de manière que le microcontrôleur ne puisse pas exploiter le bloc de données déchiffré. L’étape de vérification préalable de l’intégrité du bloc de données déchiffré IPi peut alors être prévue et être suivie d’une interdiction d’utiliser ce bloc de données si cette vérification n’est pas concluante. 18
Lorsque l’identifiant ID3 est choisi égal à l’identifiant unique UID, ce mode de réalisation utilisant le code d’activation ACTIV2 offre donc un haut degré de sécurité contre le clonage des blocs de données IPi. Il peut alors être envisagé de baisser le niveau de sécurité contre le clonage offert par les autres aspects du procédé de l’invention. Par exemple, l’identifiant ID1 intervenant dans le chiffrement du bloc de données IPi peut, dans ce cas, être un identifiant non unique du circuit intégré, tel le numéro de série FSN du firmware.
De façon générale, pour une bonne protection contre le clonage selon le mode de réalisation de la figure 6 du procédé de l’invention, il est préférable qu’au moins l’un des identifiants ID 1 et ID3 soit égal à l’identifiant unique UID. En ce qui concerne l’identifiant ID2, il peut être préféré qu’il soit égal à l’identifiant unique UID pour une bonne protection de la clé IPKi ou IPKj. Une protection maximale contre le clonage est obtenue lorsque ID1=ID2=ID3=UID.
Il apparaîtra clairement à l’homme de l’art que divers aspects des modes de réalisation qui viennent d’être décrits peuvent être combinés. Par exemple, dans le mode de réalisation de la figure 6, la clé principale peut être une clé EIPKj reçue par téléchargement sous une forme chiffrée, comme à l’étape SD00 de la figure 5.
La figure 7 est une représentation générale d’un mode de réalisation d’un procédé de conception et de mise en œuvre selon l’invention d’un programme application. Le procédé comprend :
- une phase de développement du programme application, schématisée par un bloc DEV, et
- une phase de personnalisation d’une pluralité de microcontrôleurs selon l’un quelconque des modes de réalisation du procédé selon l’invention précédemment décrits, ou une combinaison de ceux-ci, schématisée par un bloc PERS.
La phase de développement DEV est réalisée dans les bureaux du concepteur du programme application, tandis que la phase de personnalisation PERS est réalisée dans une usine de personnalisation appartenant à un tiers, ou « entité de personnalisation », auquel on confie la tâche de personnaliser des microcontrôleurs. On considère dans cet exemple que l’on n’accorde à l’entité de personnalisation qu’un degré de confiance moyen. L’ensemble du procédé, du développement jusqu’à la personnalisation des microcontrôleurs, doit donc être conçu de manière à limiter les risques de clonage par l’entité de personnalisation elle-même. De ce fait, les blocs de données IPi lui seront de préférence fournis sous une forme chiffrée. 19
La phase de développement DEV commence par la conception d’un programme application sous la forme d’un code source SCODE. Elle comprend des étapes ST01, ST02 de transformation du code source en programme exécutable par un microcontrôleur, qui sont en soi connues de l’homme de l’art. La phase de développement DEV comprend également une étape ST03 de génération de clés de chiffrement et une étape ST04 visant à séparer du reste du firmware FWR les blocs de données IPi devant être protégés, pour qu’ils puissent être chiffrés sans pour autant devoir chiffrer le firmware.
L’étape ST01 comprend tout d’abord une opération 11 consistant à transformer le code source SCODE en code objet OCODE au moyen d’un compilateur COMP. Le code objet OCODE est ensuite soumis à une opération 12 EXTRSEC d’extraction de sections, permettant de générer un fichier liste LISTF (« List File »). Le fichier LISTF est ensuite soumis à une opération 14 de pré-liaison PRELK (« Prelink ») permettant de générer d’une part un fichier de liaison LINKF (« Link File ») et d’autre part un fichier de configuration CONFF (« Config File »).
Au cours de l’étape ST02, le fichier de liaison LINKF et le code objet OCODE sont fournis à un moyen de liaison LKR 20 généralement appelé « Linker », qui fournit le programme application dans un format ELF. Le format ELF (de l’anglais « Exécutable and Linkable Format »), qui n’est cité ici qu’à titre d’exemple, est un format binaire largement utilisé dans l’industrie qui satisfait la majorité des besoins. Il est extensible, facilement manipulable et peut être utilisé quasiment à l'identique sur de nombreuses architectures de microcontrôleurs.
Au cours de l’étape ST03, les clés de chiffrement IPKi ou IPKj, CK1, CK2, CK3 sont générées au moyen d’un générateur de clés aléatoires, ainsi que le numéro de série FSN du firmware. Ce dernier peut aussi être généré au cours de l’une des étapes antérieures ST01 ou ST02. Plusieurs clés IPKi ou IPKj peuvent être générées pour chiffrer plusieurs blocs de données IPi avec des clés différentes. On considérera dans ce qui suit qu’une seule clé IPKi ou IPKj est générée pour l’ensemble des blocs de données IPi, dans un souci de simplification de la description.
Au cours de l’étape ST04, le programme application au format ELF est soumis à une opération de post-liaison POSTLK 40 (« Post Link ») qui permet d’isoler les blocs de données IPi du firmware FWR. Les blocs de données IPi sont ensuite chiffrés à partir de la clé IPKi ou IPKj au cours d’une étape 44, pour obtenir les blocs de données pré-chiffrés PEIPi. Les blocs de données pré-chiffrés PEIPi sont ensuite 20 transférés à l’entité de personnalisation, ainsi que le fïrmware F WR et la clé IPKi ou IPKj, les clés CK1, CK2, CK3 et le numéro de série FSN du fïrmware.
L’étape ST04 comprend diverses autres opérations en soi connues de Fhomme de l’art telles que la génération de librairies et de tables mentionnant les emplacements des blocs de données IPi à l’intérieur du programme application et les fonctionnalités auxquelles ils sont rattachés. Ces librairies et tables, qui sont également chargées dans la mémoire non volatile des microcontrôleurs, ne sont pas représentées sur la figure 7 dans un souci de simplicité.
La phase de personnalisation PERS comprend une étape de chiffrement ST06 des blocs de données IPi selon le procédé de l’invention, une étape ST07 de chiffrement de la clé IPKi ou IPKj, et une étape ST08 de personnalisation proprement dite des microcontrôleurs.
Si l’utilisation d’un code d’activation ACTIV1 a été retenue, l’étape de personnalisation PERS comprend également une étape ST09 de production de ce code d’activation.
Pour la mise en œuvre de la phase de personnalisation, un choix doit être fait quant à la nature des identifiants ID1, ID2, qui peuvent ici être l’identifiant unique UID de chaque microcontrôleur devant être personnalisé, ou le numéro de série FSN du fïrmware. Ce choix est schématisé par une étape ST05 qui comprend :
- une opération GETUID 50 d’extraction de l’identifiant UID du microcontrôleur à personnaliser, par exemple en lui adressant une commande de fourniture de son identifiant UID sur un port de sortie,
- une étape SEL1 54 de sélection de l’identifiant UID ou du numéro de série FSN, pour former l’identifiant ID1 et
- une étape SEL255 de sélection de l’identifiant UID ou du numéro de série FSN, pour former l’identifiant ID2.
De même, si la clé d’activation ACTIV1 est utilisée, un choix doit être fait quant à la nature de l’identifiant ID3 et la façon dont la clé d’activation ACTIV1 est générée à partir de la donnée DT, de l’identifiant ID3 et de la clé CK3. La figure 14 montre un mode de réalisation particulièrement simple de l’étape ST09, dans lequel l’identifiant ID3 est utilisé comme donnée DT à chiffrer. L’identifiant ID3 est donc chiffré, au cours d’une étape 100, à partir de la clé CK3 et au moyen de la fonction FC3, pour obtenir la clé ACTIV1. L’étape 100 est précédée d’une étape de sélection SEL3 56 de l’identifiant UID ou du numéro de série FSN pour former l’identifiant ID3. Dans une variante, la donnée DT peut être une donnée connue du 21 microcontrôleur, par exemple une donnée extraite du firmware ou une donnée aléatoire propre au microcontrôleur, statique ou régénérée dynamiquement lorsqu’elle doit être utilisée pour le calcul de la clé d’activation ACTIV1.
De retour à la figure 7, il sera noté que le choix des identifiants ID1, ID2, ID3 n’est pas réalisé par l’entité de personnalisation mais a été fait par le concepteur du programme application au cours de l’étape de développement DEV, car il détermine également la configuration que les microcontrôleurs devront utiliser lors de phases d’exécution du procédé de l’invention. Cette configuration prédéterminée est schématisée par des blocs ST05B sur les figures 10 et 11 décrites plus loin, qui se rapportent à la phase d’exécution du procédé de l’invention sans utiliser le code d’activation ACTIV1, et par des blocs ST05C sur les figures 12 et 13 décrites plus loin, qui se rapportent à la phase d’exécution du procédé de l’invention avec utilisation du code d’activation ACTIVE Sont également définies au stade de la conception du programme les fonctions de chiffrement FC1, FC2, FC3 intervenant dans la mise en œuvre du procédé de l’invention.
F’étape ST06 vise à lier le chiffrement des blocs IPi à l’identifiant ID1. Elle comprend essentiellement une étape ENC1 72 de chiffrement des blocs IPi au moyen de la fonction FC1, à partir de l’identifiant ID1, de la clé IPKi ou IPKj et de la clé CKl. Selon le mode de réalisation du procédé de l’invention qui sera retenu, l’étape 72 peut être précédée d’une étape 70 de déchiffrement des blocs chiffrés EIPi, non représentée sur la figure 7, comme cela sera vu par la suite en relation avec la figure 8. Au terme de l’étape 72, le processus de personnalisation dispose de blocs de données chiffrés EIPi qui sont dépendants de l’identifiant ID1, ou de blocs de données surchiffrés EPEIPi qui sont également dépendants de l’identifiant ID1, ces derniers étant obtenus par chiffrement des blocs de données pré-chiffrés PEIPi qui ne sont pas dépendants de l’identifiant IDE
L’étape ST07 comprend essentiellement une étape ENC2 60 de chiffrement de la clé principale IPKi ou IPKj au moyen de la fonction FC2, à partir de l’identifiant ID2 et de la clé CK2, et fournit une clé chiffrée EIPKi ou EIPKj liée à l'identifiant ID2.
L’étape ST08 comprend essentiellement une étape LDMEM1 80 de chargement, dans la mémoire non volatile MEM1 du microcontrôleur en cours de personnalisation, des données suivantes :
- le firmware FWR, qui n’est pas chiffré,
- les blocs de données chiffrés EIPi ou surchiffrés EPEIPi dépendants de l’identifiant ID1, 22
- la clé chiffrée non-OTA EIPKi qui dépend de l’identifiant ID2, si celle-ci n’est pas destinée à être transmise ultérieurement au microcontrôleur en tant que clé OTA EIPKj,
- les clés CK1, CK2, CK3,
- éventuellement, la clé d’activation ACTIV1 pour l’activation d’un ou de plusieurs blocs de données IPi, si cette option a été retenue par le concepteur du programme application.
A la fin de l’étape 80, le microcontrôleur configuré forme un circuit intégré « PROTCHIP » protégé contre le clonage. Les étapes ST06 à ST08 sont répétées pour chaque microcontrôleur devant être configuré. Dans le cadre d’une production à l’échelle industrielle, ces étapes peuvent être sérialisées ou parallélisées par un traitement en série ou en parallèle automatisé des cartes électroniques comportant les microcontrôleurs à personnaliser.
La figure 8 montre un mode de réalisation de l’étape ST06 lorsque la clé non- OTA IPKi est utilisée pour la personnalisation des microcontrôleurs. L’étape ST06 comprend une étape 70 avant l’étape de chiffrement 72 précédemment décrite. L’étape 70 est une étape de déchiffrement, au moyen de la fonction réciproque RLC1 et à partir de la clé IPKi, des blocs de données pré-chiffrés PEIPi, fournissant les blocs de données IPi dans leur forme originelle, telle que trouvée au sortir de l’étape 40 de la phase de développement DEV (figure 7). Les blocs de données IPi sont ensuite chiffrés à l’étape 72 pour être rendus dépendants de l’identifiant ID1.
L’étape 72 comprend ici des étapes 720 et 722. L’étape 720 est une étape de chiffrement de l’identifiant ID1 au moyen de la fonction FC2 et à partir de la clé CK1, fournissant un identifiant chiffré EID1. L’identifiant chiffré EID1 est ensuite combiné à la clé IPKi au moyen d’une fonction XOR (Ou Exclusif) pour obtenir une clé de chiffrement dérivée Kl. Cette étape revient à masquer la clé IPKi au moyen de l’identifiant chiffré EID1 afin que le masquage ne soit pas aisément réversible pour un fraudeur.
L’étape 722 est une étape de chiffrement des blocs IPi au moyen de la fonction FC1 et à partir de la clé de chiffrement dérivée Kl, fournissant les blocs de données chiffrés EIPî. Ces derniers sont chargés dans la mémoire non volatile MEM1 du microcontrôleur en cours de personnalisation, au cours de l’étape ST08 précédemment décrite, qui inclut ici le chargement de la clé non-OTA IPKi.
Il apparaîtra clairement à l’homme de l’art que les étapes 720, 722 peuvent être mises en œuvre de diverses autres manières. Notamment le déchiffrement des blocs de 23 données pré-chiffré PEIPi, au lieu d’être fait à l’étape 70 avant l’étape 722 de chiffrement lié à l’identifiant ID1, peut être réalisé après l’étape 722 par un choix approprié des fonctions de chiffrement. De cette manière, on évite de passer par la production de blocs de données déchiffrés IPi, entre l’étape 70 et l’étape 722, sur le lieu de personnalisation géré par l’entité de personnalisation, et les blocs de données IPi restent sous forme chiffrée pendant tout le processus de personnalisation.
De même, le masquage de la clé IPKi peut être fait de diverses autres manières et au moyen d’autres fonctions logiques que la fonction XOR, ainsi que la génération de la clé Kl qui rend les blocs de données chiffrés EIPi dépendants de l’identifiant ID1.
Un mode de réalisation de l’étape ST07 est également représenté sur la figure 8. L’étape ST07 comprend des étapes 62 et 63. L’étape 62 est une étape de chiffrement de l’identifiant ID2 au moyen de la fonction FC2 et à partir de la clé CK2, qui fournit un identifiant chiffré EID2. La clé IPKi est ensuite masquée par l’identifiant chiffré EID2 au cours de l’étape 63, en la combinant à celui-ci au moyen d’une fonction XOR fournissant la clé chiffrée EIPKi. L’homme de l’art pourra retenir diverses autres méthodes de chiffrement de la clé EIPKi, et/ou des fonctions de masquage autres que la fonction XOR.
La figure 9 montre un mode de réalisation de l’étape ST06 lorsqu’une clé OTA IPKj est utilisée pour la personnalisation des microcontrôleurs. L’étape ST06 comprend une étape de chiffrement 72B similaire à l’étape 72, mais qui n’est pas précédé par l’étape de déchiffrement 70. L’étape 72B est appliquée aux blocs de données pré-chiffrés PEIPi, et produit des blocs de données surchiffrés EPEIPi. L’étape 72B comprend l’étape 720 de production de l’identifiant chiffré EID1 précédemment décrite, et une étape de chiffrement 722B, au moyen de la fonction FC1, des blocs de données pré-chiffrés PEIPi. Elle ne comprend pas l’étape 721 de masquage préalable de la clé IPKj, de sorte que l’identifiant chiffré EID1 fourni par l’étape 720 est utilisé comme clé de chiffrement à l’étape 722B, pour chiffrer les blocs de données pré-chiffrés PEIPi et fournir les blocs de données surchiffrés EPEIPi. Les blocs de données surchiffrés EPEIPi sont chargés dans la mémoire non volatile MEM1 du microcontrôleur en cours de personnalisation, au cours de l’étape ST08 précédemment décrite. Ici, l’étape ST08 n’inclut pas le chargement de la clé IPKj, celle-ci étant une clé OTA destinée à être transmise ultérieurement au microcontrôleur.
La figure 9 montre également un mode de réalisation de l’étape ST07. Celle-ci est identique à l’étape ST07 de la figure 8, à la différence près qu’elle est appliquée à 24 la clé IPKj. L’étape 62 fournit ainsi l’identifiant chiffré EID2 et la clé IPKj est masquée au cours de l’étape 63 par l’identifiant chiffré EID2 en la combinant à celui-ci au moyen d’une fonction XOR fournissant la clé chiffrée EIPKj.
La figure 10 montre des étapes d’exécution ST11, ST12 du procédé de l’invention par un microcontrôleur lorsque celui-ci a été personnalisé au moyen d’une clé non-OTA IPKi de la manière décrite plus haut en relation avec la figure 8.
Pour l’exécution du procédé de l’invention, le microcontrôleur dispose, dans sa mémoire non volatile MEM1, de la clé chiffrée EIPKi, des clés secondaires CK1, CK2, et du numéro de série FNS du firmware. Le microcontrôleur connaît également les identifiants ID1, ID2, ID. Un bloc ST05B, schématisé de la même manière que l’étape ST05 de la figure 7, symbolise la configuration du microcontrôleur quant au choix des identifiants ID1, ID2. Le bloc ST05B comprend deux sélecteurs SEL1 54 et SEL255 permettant de choisir, pour chaque identifiant ID1, ID2, une valeur égale à l’identifiant unique UID ou au numéro de série FSN du firmware. L’opération GETUID 50 d’extraction de l’identifiant UID du microcontrôleur n’est pas représentée puisque le microcontrôleur a accès à cet identifiant sans avoir besoin de le fournir sur l’une de ses sorties.
L’étape ST11 comprend une étape 110 de chiffrement de l’identifiant ID2 au moyen de la fonction FC2 et à partir de la clé CK2, fournissant l’identifiant chiffré EID2. Elle comprend ensuite une étape 112 de démasquage de la clé chiffrée EIPKi obtenue en combinant la chiffrée EIPKi et l’identifiant chiffré EID2 au moyen d’une fonction XOR. Cette étape constitue donc la réciproque de l’étape de masquage de l’étape ST07 précédemment décrite.
L’étape ST12 comprend une étape 120 où le microcontrôleur chiffre l’identifiant ID1 au moyen de la fonction FC2 et à partir de la clé CK1, pour obtenir l’identifiant chiffré EID1. Au cours d’une étape 122, le microcontrôleur combine ensuite, au moyen d’une fonction XOR, la clé IPKi reconstituée à l’étape 112 et l’identifiant chiffré EID1, pour obtenir la clé de chiffrement dérivée Kl. Au cours d’une étape 124, le microcontrôleur déchiffre le bloc de données chiffré EIPi à partir de la clé Kl et au moyen de la fonction réciproque RFC1, puis charge le bloc de données IPi déchiffré dans la mémoire volatile MEM2. Au cours d’une étape USE(IPi) 800, le microcontrôleur utilise le bloc de données IPi pour exécuter la fonctionnalité correspondante, puis efface le bloc de données ou le conserve pour le réutiliser ultérieurement ou l’écraser par le chargement d’un autre bloc de données venant d’être déchiffré. 25
La figure 11 montre des étapes d’exécution ST 14, ST 15 du procédé de l’invention par un microcontrôleur lorsque celui-ci a été personnalisé au moyen d’une clé OTA IPKj. Comme précédemment le microcontrôleur dispose, dans sa mémoire non volatile MEM1, de la clé chiffrée EIPKj reçue en mode OTA par le CPU, des clés secondaires CK1, CK2 et du numéro de série FNS du firmware. Le bloc ST05B, précédemment décrit, symbolise la configuration du microcontrôleur quant au choix des identifiants ID1, ID2. L’étape ST 14 est identique à l’étape ST11 précédemment décrite et comprend une étape 140 de chiffrement de l’identifiant ID2 au moyen de la fonction FC2 et à partir de la clé CK2, fournissant l’identifiant chiffré EID2. L’étape 140 est suivie d’une étape 142 de démasquage de la clé chiffrée EIPKj en combinant la clé chiffrée EIPKj et l’identifiant chiffré EID2 au moyen d’une fonction XOR.
L’étape ST15 comprend une étape 150 où le microcontrôleur chiffre l’identifiant ID1 au moyen de la fonction FC2 et à partir de la clé CK1, pour obtenir l’identifiant chiffré EID1. Au cours d’une étape 152, le microcontrôleur déchiffre le bloc de données surchiffré EPEIPi au moyen de la fonction RFC1 et à partir de l’identifiant chiffré EID 1 utilisé comme clé de déchiffrement, pour obtenir le bloc de données pré- chiffré PEIPi, soit l’opération inverse de celle de l’étape de personnalisation 722 en figure 9. Au cours d’une étape 154, le microcontrôleur déchiffre le bloc de données pré-chiffré PEIPi au moyen de la fonction réciproque RFC1, en utilisant comme clé de déchiffrement la clé IPKj fournie par l’étape 142. Le microcontrôleur charge ensuite le bloc de données IPi déchiffré dans la mémoire volatile MEM2. Au cours de l’étape USE(IPi) 800, le microcontrôleur utilise le bloc de données IPi de la manière indiquée plus haut.
La figure 12 illustre une variante du mode de réalisation de la figure 10 (clé de chiffrement IPKi non-OTA) lorsque la clé d’activation ACTIV1 est utilisée pour protéger le microcontrôleur contre le clonage. On suppose ici qu’une clé d’activation ACTIV2 a été préalablement reçue en mode OTA et chargée dans la mémoire MEM1 par le CPU.
Un bloc ST05C symbolise la configuration du microcontrôleur quant au choix des identifiants ID1, ID2, ID3. Le bloc ST05B comprend trois sélecteurs SEL1 54, SEL255 et SEL3 56 permettant de choisir, pour chaque identifiant ID1, ID2, ID3, une valeur égale à l’identifiant unique UID ou au numéro de série FSN du firmware.
Cette variante se distingue du mode de réalisation de la figure 10 par l’insertion, dans le processus de déchiffrement des blocs de données IPi, d’une étape ST 10 de vérification de la clé d’activation ACTIV2. L’étape ST10 comprend : 26
- une étape 100 de reconstitution de la clé ACTIV1 par chiffrement de l’identifiant ID3 au moyen de la fonction FC3, à partir de la clé CK3,
- une étape 102, insérée entre les étapes 110 et 112 précédemment décrites, de combinaison, au moyen d’une fonction XOR, de l’identifiant chiffré EID2 et de la clé d’activation ACTIV2, le résultat de la combinaison étant combiné à la clé chiffrée EIPKi au cours de l’étape 112, et
- une étape 103 réalisée avec la fonction XOR, consistant à combiner le résultat de l’étape 112 avec la clé reconstituée ACTIVE
Le résultat de l’étape 103 est égal à la clé de chiffrement IPKi si la clé ACTIV2 est identique à la clé ACTIV 1. En effet, en désignant par « + » la fonction XOR, le résultat de l’étape 102 est égal à EID2 + ACTIV2. Le résultat de l’étape 112 est égal à EID2 + EIPKi + ACTIV1, soit EID2 + IPKi + EID2 + ACTIV2 (étape ST07, figure 8) soit encore IPKi + ACTIV2 puisque la combinaison de deux données identiques au moyen de la fonction XOR donne un résultat égal à 0. Le résultat de l’étape 103 est donc égal à IPKi + ACTIV2 + ACTIVE Si les clés ACTIV 1 et ACTIV2 sont égales, le résultat de l’étape 103 est égal à la clé IPKi soit la valeur recherchée pour la bonne exécution de l’étape 122 de génération de la clé dérivée Kl. Si les clés ACTIV1 et ACTIV2 ne sont pas égales, le résultat de l’étape 103 ne sera pas égal à la clé IPKi, la clé Kl sera erronée et le déchiffrement des blocs de données EIPi fournira un bloc de données IPi erroné. Comme le bloc de données IPi, qu’il ait été ou non correctement déchiffré, est ici transféré dans la mémoire non volatile pour être utilisé à l’étape 800, il peut être recommandé, avant une telle utilisation, de conduire ici l’étape précédemment mentionnée de vérification de son intégrité.
La figure 13 illustre une variante du mode de réalisation de la figure 11 (clé OTA IPKj) lorsque la clé d’activation ACTIV 1 est utilisée pour protéger le microcontrôleur contre le clonage. Le bloc ST05C précédemment décrit symbolise la configuration du microcontrôleur quant au choix des identifiants ID1, ID2, ID3.
On suppose comme précédemment qu’une clé d’activation ACTIV2 a été préalablement reçue en mode OTA et chargée dans la mémoire MEM1 par le CPU. Cette variante se distingue du mode de réalisation de la figure 11 par l’insertion, dans le processus de déchiffrement des blocs de données IPi, d’une étape ST 13 de vérification de la clé d’activation ACTIV2. L’étape ST13 comprend :
- l’étape 130 précédemment décrite de reconstitution de la clé ACTIV 1 par chiffrement de l’identifiant ID3 au moyen de la fonction LC3 et à partir de la clé CK3, 27
- une étape 132, insérée entre les étapes 140 et 142 précédemment décrites, de combinaison, au moyen d’une fonction XOR, de l’identifiant chiffré EID2 et de la clé d’activation ACTIV2, le résultat de la combinaison étant combiné à la clé chiffrée EIPKi au cours de l’étape 112,
- une étape 133 consistant à combiner, au moyen d’une fonction XOR, le résultat de l’étape 142 avec la clé reconstituée ACTIV1 au cours de l’étape 130.
Le résultat de l’étape 133 est égal à la clé IPKj si la clé ACTIV2 est identique à la clé ACTIV1, pour les raisons indiquées plus haut en relation avec la figure 13. Si les clés ACTIV1 et ACTIV2 sont égales, le résultat de l’étape 103 est égal à IPKj soit la clé de déchiffrement nécessaire à la bonne conduite de l’étape 154. Si les clés ACTIV 1 et ACTIV2 ne sont pas égales, le résultat de l’étape 133 sera faux, la clé IPKj sera erronée et le déchiffrement des blocs de données pré-chiffrés PEIPi conduira à un bloc de données IPi erroné. Il peut ici également être recommandé, avant une telle utilisation, de conduire l’étape de vérification de l’intégrité du bloc de données IPi.
Il sera noté que la reconstitution de la clé ACTIV1 par le microcontrôleur constitue une alternative avantageuse mais optionnelle à un mode de réalisation du procédé de l’invention dans lequel la clé ACTIV1 est chargée dans la mémoire non volatile MEM1 du microcontrôleur pendant la phase de personnalisation. D’autres modes de production de la clé ACTIV 1 peuvent être prévus, notamment en fonction d’une donnée secrète située en un point particulier de la mémoire MEM2, à partir de la clé CK3 et de l’identifiant ID3.
Également, il apparaîtra clairement à l’homme du métier que les étapes de chiffrement et déchiffrement intervenant dans le procédé de l’invention sont susceptibles de diverses variantes en ce qui concerne notamment leurs combinaisons, le choix d’une fonction de masquage autre que la fonction XOR, et le choix des fonctions de chiffrement FC1, FC2 et FC3. Dans un exemple de réalisation, la fonction FC1 peut être une fonction AES en mode compteur, généralement désignée « AES- CTR » (« Advanced Encryption Standard in Counter Mode »). La fonction FC2 peut être une fonction AES. La fonction FC3 peut être une fonction de cryptographie légère LWC en mode compteur, généralement désignée LWC-CTR (LightWeight Cryptography in Counter Mode), et être par exemple être implémentée à l’aide de l’algorithme PRESENT.
Lorsque l’identifiant ID1 est l’identifiant unique UID, le processus de personnalisation d’un microcontrôleur selon l’invention nécessite la connaissance de l’identifiant UID de chaque microcontrôleur concerné par la phase de personnalisation 28
PERS (figure 7). On a supposé dans ce qui précède que l’identifiant UID était lu dans le microcontrôleur en cours de personnalisation au moyen d’une commande GETUID (étape ST05). Dans une variante de la phase de personnalisation, une liste d’ identifiants UID est fournie à l’entité de personnalisation en même temps que la pluralité de microcontrôleur à personnaliser, de sorte qu’une telle commande n’est pas nécessaire.
Dans certains modes de réalisation du procédé de l’invention, il peut être souhaité de ne pas avoir à gérer une liste d’ identifiants UID pour conduire l’étape de personnalisation. On choisira dans ce cas un identifiant ID1 qui n’est pas unique à chaque circuit intégré, tel le numéro de série FSN du firmware cité dans ce qui précède à titre d’exemple. Dans un tel mode de réalisation, il sera alors conseillé de faire intervenir la clé d’activation ACTIV 1 pour contrôler le processus de déchiffrement des blocs de données IPi, et de générer la clé d’activation ACTIV1 à partir de l’identifiant unique UID. En résumé, et comme cela a été précédemment indiqué, il pourra être souhaité qu’au moins l’un des deux identifiants ID1 et ID3 soit égal à l’identifiant unique UID. Si aucune clé d’activation n’est utilisée, il pourra être souhaité que l’identifiant ID1 soit égal à l’identifiant unique UID. De cette manière, un microcontrôleur cloné ne possédant pas le même identifiant unique UID sera dans l’incapacité de déchiffrer correctement les blocs de données IPi lorsqu’il s’agira d’exécuter des fonctionnalités mettant enjeu ces blocs de données IPi.

Claims

29 REVENDICATIONS
1. Procédé pour l’exécution d’un programme (FWR, IPi) par un microcontrôleur (CPU) en circuit intégré (ICI), le microcontrôleur comprenant une mémoire non volatile (MEM1) et une mémoire volatile (MEM2), le programme étant stocké dans la mémoire non volatile et comprenant au moins un bloc de données (IPi) nécessaire à l’exécution d’une fonctionnalité du programme, procédé caractérisé en ce qu’il comprend les étapes consistant à :
- définir un premier identifiant (ID1) du circuit intégré,
- générer une clé de chiffrement principale (IPKi, IPKj) du bloc de données,
- chiffrer (SP2, SP12, SP22, SP32, SP42, 44, ST06, 72, 72B, 722, 722B) le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant (ID1),
- charger ou télécharger, dans la mémoire non volatile, le bloc de données sous sa forme chiffrée (EIPi, EPEIPi),
- charger ou télécharger la clé de chiffrement principale (IPKi, IPKj) dans la mémoire non volatile, et, au moyen du microcontrôleur :
- déchiffrer (SEO, SE10, SE20, SE30, SE40 , ST12, ST15) le bloc de données chiffré (EIPi, EPEIPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant (ID1),
- placer (SE1, SE11, SE21, SE31, SE41, ST08) le bloc de données déchiffré (IPi) dans la mémoire volatile (MEM2) du microcontrôleur, et
- utiliser le bloc de données déchiffré présent dans la mémoire volatile pour exécuter la fonctionnalité.
2. Procédé selon la revendication 1, dans lequel l’étape consistant à chiffrer le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant (ID1), comprend les étapes consistant à :
- générer une première clé de chiffrement secondaire (CK1),
- chiffrer (720) le premier identifiant (ID1) au moyen de la première clé de chiffrement secondaire (CK1), pour obtenir un premier identifiant chiffré (EID1),
- chiffrer (72, 72B, 722, 722B) le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant chiffré (EID1), et 30
- charger la première clé de chiffrement secondaire (CK1) dans la mémoire non volatile du microcontrôleur.
3. Procédé selon la revendication 2, comprenant les étapes consistant à, au moyen du microcontrôleur :
- déchiffrer (ST12, 120, 122, 124, ST15, 150, 152, 154) le bloc de données chiffré (EIPi, EPEIPi) à partir de la clé de chiffrement principale (IPKi, IPKj), du premier identifiant (ID1), et de la première clé de chiffrement secondaire (CK1), et
- pendant le déchiffrement du bloc de données chiffré (EIPi, EPEIPi), chiffrer (120, 152) le premier identifiant (ID1) au moyen de la première clé de chiffrement secondaire (CK1), pour obtenir le premier identifiant chiffré (EID1).
4. Procédé selon l’une des revendications 2 et 3, dans lequel l’étape consistant à chiffrer le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKi) et du premier identifiant chiffré (EID1), comprend les étapes consistant à :
- masquer (721) la clé de chiffrement principale (IPKi) au moyen du premier identifiant chiffré (EID1), pour obtenir une clé de chiffrement dérivée (Kl), et
- chiffrer (722) le bloc de données à partir de la clé de chiffrement dérivée (Kl), pour obtenir le bloc de données sous sa forme chiffrée (EIPi).
5. Procédé selon la revendication 4, comprenant les étapes consistant à, au moyen du microcontrôleur :
- masquer (122) la clé de chiffrement principale (IPKi) au moyen du premier identifiant chiffré (EID1), pour obtenir la clé de chiffrement dérivée (Kl), et - déchiffrer (124) le bloc de données chiffré (EIPi) à partir de la clé de chiffrement dérivée (Kl).
6. Procédé selon l’une des revendications 2 et 3, dans lequel l’étape consistant à chiffrer le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKj) et du premier identifiant chiffré (EID1), comprend les étapes consistant à :
- chiffrer (44) le bloc de données (IPi) à partir de la clé de chiffrement principale (IPKj), pour obtenir un bloc de données pré-chiffré (PEIPi), et
- chiffrer (722B) le bloc de données pré-chiffré (PEIPi) au moyen du premier identifiant chiffré (EID1), pour obtenir un bloc de données surchiffré (EPEIPi) formant 31 le bloc de données sous sa forme chiffrée chargé dans la mémoire non volatile du microcontrôleur.
7. Procédé selon la revendication 6, comprenant les étapes consistant à, au moyen du microcontrôleur :
- déchiffrer (152) le bloc de données surchiffré (EPEIPi) à partir du premier identifiant chiffré (EID1), pour obtenir le bloc de données pré-chiffré (PEIPi), et
- déchiffrer (154) le bloc de données pré-chiffré (PEIPi) à partir de la clé de chiffrement principale (IPKj), pour obtenir le bloc de donnée déchiffré (IPi).
8. Procédé selon l’une des revendications 1 à 7, dans lequel le premier identifiant (ID1) du circuit intégré est l’un ou l’autre des identifiants suivants :
- un identifiant unique du circuit intégré (UID), tel son numéro de série, ou
- un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série (FSN) du programme chargé dans la mémoire non volatile du microcontrôleur.
9. Procédé selon l’une des revendications 1 à 8, comprenant les étapes consistant à :
- définir un deuxième identifiant du circuit intégré (ID2),
- masquer (63) la clé de chiffrement principale (IPKi, IPKj) avec le deuxième identifiant (ID2) avant de la charger ou la télécharger dans la mémoire non volatile du microcontrôleur, et la charger ou la télécharger sous sa forme masquée (EIPKi, EIPKj) dans la mémoire non volatile du microcontrôleur.
10. Procédé selon la revendication 9, comprenant les étapes consistant à, au moyen du microcontrôleur :
- démasquer (112, 142) la clé de chiffrement principale masquée (EIPKi, EIPKj) au moyen du deuxième identifiant (ID2) avant de déchiffrer (ST12, 120, 122, 124, ST15, 150, 152, 154) le bloc de données chiffré (EIPI, PEIPi, EPEIPi).
11. Procédé selon l’une des revendications 9 et 10, dans lequel l’étape (63) consistant à masquer la clé de chiffrement principale (IPKi, IPKj) avec le deuxième identifiant (ID2) comprend les étapes consistant à :
- générer une deuxième clé de chiffrement secondaire (CK2), 32
- chiffrer (62) le deuxième identifiant (ID2) au moyen de la deuxième clé de chiffrement secondaire (CK2), pour obtenir un deuxième identifiant chiffré (EID2), et
- masquer (63) la clé de chiffrement principale (IPKi, IPKj) avec le deuxième identifiant chiffré (EID2) pour obtenir la forme masquée (EIPKi, EIPKj) chargée ou téléchargée dans la mémoire non volatile du microcontrôleur.
12. Procédé selon la revendication 11, comprenant les étapes consistant à, au moyen du microcontrôleur :
- chiffrer (110, 140) le deuxième identifiant (ID2) au moyen de la deuxième clé de chiffrement secondaire (CK2), pour obtenir le deuxième identifiant chiffré (EID2), et
- démasquer (112, 142) la clé de chiffrement principale masquée (EIPKi, EIPKj) au moyen du deuxième identifiant chiffré (EID2) avant de déchiffrer (ST12, 120, 122, 124, ST15, 150, 152, 154) le bloc de données chiffré (EIPI, PEIPi, EPEIPi).
13. Procédé selon l’une des revendications 9 à 12, dans lequel le deuxième identifiant (ID2) du circuit intégré est l’un ou l’autre des identifiants suivants :
- un identifiant unique du circuit intégré (UID), tel son numéro de série, ou
- un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série (FSN) du programme chargé dans la mémoire non volatile du microcontrôleur.
14. Procédé selon l’une des revendications 1 à 13, comprenant les étapes consistant à :
- générer une troisième clé de chiffrement secondaire (CK3),
- définir un troisième identifiant (ID3, UID) du circuit intégré,
- générer une première clé d’activation (ACTIV1) de la fonctionnalité, par chiffrement d’une donnée (DT, ID3) à partir du troisième identifiant (ID3, UID) et de la troisième clé de chiffrement secondaire (CK3), et, au moyen du microcontrôleur :
- recevoir une deuxième clé d’activation (ACTIV2),
- reconstituer la première clé d’activation (ACTIV1),
- ne pas déchiffrer ou déchiffrer de manière incorrecte le bloc de données chiffré (EIPi, EPEIPi) si la deuxième clé d’activation (ACTIV2) n’est pas égale à la première clé d’activation (ACTIV1), 33
15. Procédé selon la revendication 14, comprenant l’étape consistant à, au moyen du microcontrôleur, injecter (102, 103, 132,133) les première et deuxième clés d’activation dans des étapes (110, 112, 122, 140, 142, 154) de déchiffrement du bloc de données chiffré (EIPi, EPEIPi), de manière que le résultat du déchiffrement du bloc de données chiffré (EIPi, EPEIPi) soit erroné si la deuxième clé d’activation (ACTIV2) n’est pas égale à la première clé d’activation (ACTIV1).
16. Procédé selon l’une des revendications 14 et 15, comprenant une étape de contrôle, par le microcontrôleur, de l’intégrité du bloc de données déchiffré (IPi) avant de l’utiliser, dans l’hypothèse où le bloc de données n’aurait pas été déchiffré correctement en raison de la réception d’une clé d’activation (ACTIV2) incorrecte, et une étape de configuration du microcontrôleur pour qu’il ne tente pas d’exécuter la fonctionnalité si le contrôle d’intégrité n’est pas positif.
17. Procédé selon l’une des revendications 14 à 16, dans lequel le troisième identifiant (ID3) du circuit intégré est l’un ou l’autre des identifiants suivants :
- un identifiant unique du circuit intégré (UID), tel son numéro de série, ou
- un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série (FSN) du programme chargé dans la mémoire non volatile du microcontrôleur.
18. Microcontrôleur en circuit intégré (ICI) comprenant une mémoire non volatile (MEM1) et une mémoire volatile (MEM2), la mémoire non volatile comprenant un programme (FWR, IPi) exécutable comprenant au moins un bloc de données (IPi) nécessaire à l’exécution d’une fonctionnalité du programme, le microcontrôleur étant caractérisé en ce que :
- le bloc de données (IPi) est stocké dans la mémoire non volatile sous une forme chiffrée (EIPi, EPEIPi) générée à partir d’une clé de chiffrement principale (IPKi, IPKj) et d’un premier identifiant (ID1) du circuit intégré, la clé de chiffrement principale (IPKi, IPKj) étant stockée dans la mémoire non volatile du microcontrôleur, et en ce que
- le microcontrôleur est configuré pour :
- déchiffrer (SE0, SE10, SE20, SE30, SE40 , ST12, ST15) le bloc de données chiffré (EIPi, EPEIPi) à partir de la clé de chiffrement principale (IPKi, IPKj) et du premier identifiant (ID1), 34
- placer le bloc de données déchiffré (IPi) dans la mémoire volatile (MEM2) du microcontrôleur, et
- utiliser le bloc de données déchiffré présent dans la mémoire volatile pour exécuter la fonctionnalité.
19. Microcontrôleur en circuit intégré selon la revendication 18, dans lequel la mémoire non volatile comprend en outre une première clé de chiffrement secondaire (CK1), le microcontrôleur étant configuré pour :
- déchiffrer (ST12, 120, 122, 124, ST15, 150, 152, 154) le bloc de données chiffré (EIPi, EPEIPi) à partir de la clé de chiffrement principale (IPKi, IPKj), du premier identifiant (ID1), et de la première clé de chiffrement secondaire (CK1), et
- pendant le déchiffrement du bloc de données chiffré (EIPi, EPEIPi), chiffrer (120, 152) le premier identifiant (ID1) au moyen de la première clé de chiffrement secondaire (CK1), pour obtenir un premier identifiant chiffré (EID1).
20. Microcontrôleur en circuit intégré selon la revendication 19, dans lequel le microcontrôleur est configuré pour :
- masquer (122) la clé de chiffrement principale (IPKi) au moyen du premier identifiant chiffré (EID1), pour obtenir une clé de chiffrement dérivée (Kl), et - déchiffrer (124) le bloc de données chiffré (EIPi) à partir de la clé de chiffrement dérivée (Kl).
21. Microcontrôleur en circuit intégré selon la revendication 19, dans lequel le bloc de données (IPi) est stocké dans la mémoire non volatile sous une forme surchiffrée (EPEIPi), le microcontrôleur étant configuré pour :
- déchiffrer (152) le bloc de données surchiffré (EPEIPi) à partir du premier identifiant chiffré (EID1), pour obtenir un bloc de données pré-chiffré (PEIPi), et
- déchiffrer (154) le bloc de données pré-chiffré (PEIPi) à partir de la clé de chiffrement principale (IPKj), pour obtenir le bloc de donnée déchiffré (IPi).
22. Microcontrôleur en circuit intégré selon l’une des revendications 18 à 21, dans lequel le premier identifiant (ID1) du circuit intégré est l’un ou l’autre des identifiants suivants :
- un identifiant unique du circuit intégré (UID), tel son numéro de série, ou 35
- un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série (FSN) du programme chargé dans la mémoire non volatile.
23. Microcontrôleur en circuit intégré selon l’une des revendications 18 à 22, dans lequel la clé de chiffrement principale (IPKi, IPKj) est stockée dans la mémoire volatile sous une forme masquée (EIPKi, EIPKj) obtenue par masquage de la clé par un deuxième identifiant (ID2) du circuit intégré, le microcontrôleur étant configuré pour :
- démasquer (112, 142) la clé de chiffrement principale masquée (EIPKi, EIPKj) au moyen du deuxième identifiant (ID2) avant de déchiffrer (ST12, 120, 122, 124, ST15, 150, 152, 154) le bloc de données chiffré (EIPI, PEIPi, EPEIPi).
24. Microcontrôleur en circuit intégré selon la revendication 23, dans lequel la mémoire non volatile comprend en outre une deuxième clé de chiffrement secondaire (CK2), le microcontrôleur étant configuré pour :
- chiffrer (110, 140) le deuxième identifiant (ID2) au moyen de la deuxième clé de chiffrement secondaire (CK2), pour obtenir un deuxième identifiant chiffré (EID2), et
- démasquer (112, 142) la clé de chiffrement principale masquée (EIPKi, EIPKj) au moyen du deuxième identifiant chiffré (EID2) avant de déchiffrer (ST12, 120, 122, 124, ST15, 150, 152, 154) le bloc de données chiffré (EIPI, PEIPi, EPEIPi).
25. Microcontrôleur en circuit intégré selon l’une des revendications 23 et 24, dans lequel le deuxième identifiant (ID2) du circuit intégré est l’un ou l’autre des identifiants suivants :
- un identifiant unique du circuit intégré (UID), tel son numéro de série, ou
- un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série (FSN) du programme chargé dans la mémoire non volatile.
26. Microcontrôleur en circuit intégré selon l’une des revendications 18 à 25, configuré pour :
- générer une première clé d’activation (ACTIV1) de la fonctionnalité, par chiffrement d’une donnée (DT, ID3) à partir du troisième identifiant (ID3, UID) et de la troisième clé de chiffrement secondaire (CK3), 36
- recevoir une deuxième clé d’activation (ACTIV2),
- ne pas déchiffrer ou déchiffrer de manière incorrecte le bloc de données chiffré (EIPi, EPEIPi) si la deuxième clé d’activation (ACTIV2) n’est pas égale à la première clé d ’ activation ( ACTI V 1 ) .
27. Microcontrôleur en circuit intégré selon la revendication 26, configuré pour injecter (102, 103, 132, 133) les première et deuxième clés d’activation dans des étapes (110, 112, 122, 140, 142, 154) de déchiffrement du bloc de données chiffré (EIPi, EPEIPi), de manière que le résultat du déchiffrement du bloc de données chiffré (EIPi, EPEIPi) soit erroné si la deuxième clé d’activation (ACTIV2) n’est pas égale à la première clé d’activation (ACTIV1).
28. Microcontrôleur en circuit intégré selon la revendication 27, configuré pour contrôler l’intégrité du bloc de données déchiffré (IPi) avant son utilisation, dans l’hypothèse où le bloc de données n’aurait pas été déchiffré correctement en raison de la réception d’une clé d’activation (ACTIV2) incorrecte, et ne pas tenter d’exécuter la fonctionnalité si le contrôle d’intégrité n’est pas positif.
29. Microcontrôleur en circuit intégré selon l’une des revendications 26 à 28, dans lequel le troisième identifiant (ID3) du circuit intégré est l’un ou l’autre des identifiants suivants :
- un identifiant unique du circuit intégré (UID), tel son numéro de série, ou
- un identifiant commun à une pluralité de circuits intégrés de même architecture et/ou de même application, tel un numéro de série (FSN) du programme chargé dans la mémoire non volatile.
PCT/FR2022/050813 2021-05-10 2022-04-28 Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré WO2022238636A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22726783.8A EP4338078A1 (fr) 2021-05-10 2022-04-28 Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2104943 2021-05-10
FR2104943A FR3122745B1 (fr) 2021-05-10 2021-05-10 procédé pour l’exécution d’un programme chargé dans la mémoire non volatile d’un microcontrôleur en circuit intégré

Publications (1)

Publication Number Publication Date
WO2022238636A1 true WO2022238636A1 (fr) 2022-11-17

Family

ID=77821809

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2022/050813 WO2022238636A1 (fr) 2021-05-10 2022-04-28 Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré

Country Status (3)

Country Link
EP (1) EP4338078A1 (fr)
FR (1) FR3122745B1 (fr)
WO (1) WO2022238636A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030061488A1 (en) 2001-09-25 2003-03-27 Michael Huebler Cloning protection for electronic equipment
US20090086980A1 (en) * 2007-09-29 2009-04-02 Duncan Glendinning Enabling a secure oem platform feature in a computing environment
US7539868B2 (en) 2002-07-30 2009-05-26 Texas Instruments Incorporated Run-time firmware authentication
WO2012033385A2 (fr) 2010-09-10 2012-03-15 Samsung Electronics Co., Ltd. Mémoire non volatile destinée à un anti-clonage et procédé d'authentification de celle-ci
WO2014014793A1 (fr) 2012-07-17 2014-01-23 CallSign, Inc. Procédé et système anti-clonage
US8789746B2 (en) 2009-01-31 2014-07-29 Solexir Technology Inc. Product authentication using integrated circuits
US20160300064A1 (en) * 2015-04-10 2016-10-13 Vixs Systems Inc. Secure processor for soc initialization

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030061488A1 (en) 2001-09-25 2003-03-27 Michael Huebler Cloning protection for electronic equipment
US7539868B2 (en) 2002-07-30 2009-05-26 Texas Instruments Incorporated Run-time firmware authentication
US20090086980A1 (en) * 2007-09-29 2009-04-02 Duncan Glendinning Enabling a secure oem platform feature in a computing environment
US8789746B2 (en) 2009-01-31 2014-07-29 Solexir Technology Inc. Product authentication using integrated circuits
WO2012033385A2 (fr) 2010-09-10 2012-03-15 Samsung Electronics Co., Ltd. Mémoire non volatile destinée à un anti-clonage et procédé d'authentification de celle-ci
WO2014014793A1 (fr) 2012-07-17 2014-01-23 CallSign, Inc. Procédé et système anti-clonage
US20160300064A1 (en) * 2015-04-10 2016-10-13 Vixs Systems Inc. Secure processor for soc initialization

Also Published As

Publication number Publication date
FR3122745A1 (fr) 2022-11-11
FR3122745B1 (fr) 2024-03-15
EP4338078A1 (fr) 2024-03-20

Similar Documents

Publication Publication Date Title
EP1570648B1 (fr) Méthode de sécurisation des mises à jour de logiciels
EP3320471B1 (fr) Systeme et procede d'authentification et de licence ip de modules hardware
US20080256368A1 (en) Method and Device For Protecting Digital Content in Mobile Applications
WO2004107283A1 (fr) Methode de generation d’une cle de securite
EP1376367A2 (fr) Vérification d'intégrité d'un code logiciel exécuté par un processeur intégré
EP2107808A1 (fr) Module de sécurité (SM) pour unité de traitement de données audio/vidéo
EP2958040A1 (fr) Procédé et dispositif de codage de fichiers sources pour la livraison sécurisée de code source
EP1494460A1 (fr) Procédé et dispositif d'authentification de données numériques par module d'extension d'authentification
FR2728980A1 (fr) Dispositif de securisation de systemes d'information organises autour de microprocesseurs
EP1355446B1 (fr) Chiffrement du contenu d'une mémoire externe à un processeur
WO2022238636A1 (fr) Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré
CA2988357A1 (fr) Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants
FR2899409A1 (fr) Dispositif de restitution d'un contenu numerique, entite electronique securisee, systeme comprenant ces elements et procede de restitution d'un contenu numerique
CH716294A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous conditions d'identification personnelle et de géolocalisation, d'une transaction destinée à une blockchain.
WO2024083849A1 (fr) Encodage en boite blanche
WO2003012604A2 (fr) Procede pour proteger un logiciel a l'aide de 'renommage' contre son utilisation non autorisee de diluant
EP4068681A1 (fr) Procédé et dispositif pour le déchiffrement sécurisé de données chiffrées
FR2867868A1 (fr) Procede de protection de logiciels et de donnees avec methode de gestion de clefs securisees
EP1494461B1 (fr) Procédé et dispositif d'authentification de données numériques à partir d'un module d'extension d'authentification
FR2828304A1 (fr) Procede pour proteger un logiciel a l'aide d'un principe dit de "dissociation temporelle" contre son utilisation non autorisee
CH716287A2 (fr) Procédé de traitement de données biométriques d'un individu, avec phases de calibrage et de contrôle et inscription, dans une blockchain, d'un résultat d'analyse.
FR3106909A1 (fr) Circuit intégré configuré pour réaliser des opérations de chiffrement symétrique avec protection de clé secrète
CH716288A2 (fr) Procédé de traitement de données biométriques d'un individu, avec phases de calibrage et de contrôle et inscription, dans une blockchain, sous condition de géolocalisation, d'un résultat d'analyse.
WO2003012374A2 (fr) Procede pour proteger un logiciel a l'aide de 'branchement conditionnel' contre son utilisation non autorisee
FR2828305A1 (fr) Procede pour proteger un logiciel a l'aide d'un principe dit de "variable" contre son utilisation non autorisee

Legal Events

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

Ref document number: 22726783

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022726783

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022726783

Country of ref document: EP

Effective date: 20231211