FR3122745A1 - procédé pour l’exécution d’un programme chargé 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 chargé dans la mémoire non volatile d’un microcontrôleur en circuit intégré Download PDFInfo
- Publication number
- FR3122745A1 FR3122745A1 FR2104943A FR2104943A FR3122745A1 FR 3122745 A1 FR3122745 A1 FR 3122745A1 FR 2104943 A FR2104943 A FR 2104943A FR 2104943 A FR2104943 A FR 2104943A FR 3122745 A1 FR3122745 A1 FR 3122745A1
- Authority
- FR
- France
- Prior art keywords
- identifier
- microcontroller
- data block
- encrypted
- encryption key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000015654 memory Effects 0.000 title claims abstract description 121
- 238000000034 method Methods 0.000 title claims abstract description 95
- 230000004913 activation Effects 0.000 claims description 59
- 230000000873 masking effect Effects 0.000 claims description 20
- 101001139126 Homo sapiens Krueppel-like factor 6 Proteins 0.000 claims description 10
- 101000710013 Homo sapiens Reversion-inducing cysteine-rich protein with Kazal motifs Proteins 0.000 claims description 10
- 102100022907 Acrosin-binding protein Human genes 0.000 claims description 2
- 101000756551 Homo sapiens Acrosin-binding protein Proteins 0.000 claims 1
- 230000006870 function Effects 0.000 abstract description 73
- 238000010367 cloning Methods 0.000 description 27
- 102100037245 EP300-interacting inhibitor of differentiation 2 Human genes 0.000 description 14
- 101000881675 Homo sapiens EP300-interacting inhibitor of differentiation 2 Proteins 0.000 description 14
- 102100037250 EP300-interacting inhibitor of differentiation 1 Human genes 0.000 description 9
- 101000881670 Homo sapiens EP300-interacting inhibitor of differentiation 1 Proteins 0.000 description 9
- 238000011161 development Methods 0.000 description 8
- 230000001419 dependent effect Effects 0.000 description 6
- 238000004519 manufacturing process Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000005406 washing Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 101100191136 Arabidopsis thaliana PCMP-A2 gene Proteins 0.000 description 2
- 101000661807 Homo sapiens Suppressor of tumorigenicity 14 protein Proteins 0.000 description 2
- 101100422768 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) SUL2 gene Proteins 0.000 description 2
- 101100048260 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) UBX2 gene Proteins 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001131 transforming effect Effects 0.000 description 2
- 102100035087 Ectoderm-neural cortex protein 1 Human genes 0.000 description 1
- 101000911772 Homo sapiens Hsc70-interacting protein Proteins 0.000 description 1
- 101001096365 Homo sapiens Replication factor C subunit 2 Proteins 0.000 description 1
- 101001096355 Homo sapiens Replication factor C subunit 3 Proteins 0.000 description 1
- 102100027800 Kelch-like protein 25 Human genes 0.000 description 1
- 101000765037 Mus musculus Class E basic helix-loop-helix protein 40 Proteins 0.000 description 1
- 102100037851 Replication factor C subunit 2 Human genes 0.000 description 1
- 102100037855 Replication factor C subunit 3 Human genes 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Storage Device Security (AREA)
Abstract
procédé pour l’exécution d’un programme chargé dans la mémoire non volatile d’un microcontrôleur en circuit intégré 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é. Fig. 1
Description
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 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.
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 soutions 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 WO2014014793A1 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 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 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.
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 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 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.
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 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 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 illustre un premier mode de réalisation du procédé selon l’invention,
- la illustre un deuxième mode de réalisation du procédé selon l’invention,
- la illustre un troisième mode de réalisation du procédé selon l’invention,
- la illustre un quatrième mode de réalisation du procédé selon l’invention,
- la illustre un cinquième mode de réalisation du procédé selon l’invention,
- la 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 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 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 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 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,
- la 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 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 montre un mode de réalisation d’une étape représentée sous forme de bloc en .
La montre schématiquement l’architecture d’un microcontrôleur en circuit intégré IC1, 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 (IP1, 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é IC1 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 « 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 (IP1, 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’expression « à partir de » signifie toute forme de combinaison ou d’utilisation d’une part de la clé principale IPKi ou IPKj et d’autre part de l’identifiant ID1 pour chiffrer les blocs de données au moyen de la fonction de chiffrement, de manière que ce chiffrement soit lié à l’identifiant ID1 et pas seulement à la clé principale IPKi ou IPKj, et que le déchiffrement ne puisse pas se faire correctement sans connaissance de l’identifiant ID1.
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. 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, avant de l’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 , l’étape de personnalisation comprend :
- une étape SP0 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 MEM1.
L’étape d’exécution du procédé par le microcontrôleur comprend :
- une étape SE0 de déchiffrement du bloc de données chiffré EIPi à partir de la clé IPKi et de l’identifiant ID1, par exemple au moyen de la fonction réciproque RFC1, 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 , l’étape de personnalisation comprend :
- une étape SP10 consistant à générer les clés de chiffrement symétrique IPKi et CK1,
- 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,
- une étape SP12 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 SP15 de chargement du bloc de données chiffré EIPi, de la clé IPKi et de la clé CK1 dans la mémoire MEM1.
L’étape d’exécution du procédé par le microcontrôleur comprend :
- une étape SE10 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 , 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 MEM1.
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 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 , 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 MEM1.
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 MEM1.
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 , 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,
- 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 MEM1.
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é ACTV1 à 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 , 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.
Le mode de réalisation de la offre le même degré de sécurité contre le clonage que le mode de réalisation de la 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é EIPi. 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 offre le même degré de sécurité contre le clonage que le mode de réalisation de la 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 est similaire à celui de la 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 , 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é ACTIV1’ qui ne pourra jamais être égale à la clé ACTIV2 si celle-ci est, comme il se doit, égale à la clé ACTIV1. Le microcontrôleur cloné ne pourra donc pas déchiffrer correctement le bloc de données chiffré EIPi, 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 ACTIV1 et ACTIV2 n’empêche pas le déchiffrement du bloc de données chiffré EIPi, 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.
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 du procédé de l’invention, il est préférable qu’au moins l’un des identifiants ID1 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 , 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 .
La 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.
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 « Executable 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 transférés à l’entité de personnalisation, ainsi que le firmware FWR et la clé IPKi ou IPKj, les clés CK1, CK2, CK3 et le numéro de série FSN du firmware.
L’étape ST04 comprend diverses autres opérations en soi connues de l‘homme 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 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 firmware. 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 SEL2 55 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 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 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 , 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 ACTIV1. 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.
L’é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é CK1. 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 , comme cela sera vu par la suite en relation avec la . 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 ID1.
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,
- 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 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 RFC1 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 ( ). 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 K1. 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 K1, fournissant les blocs de données chiffrés EIPi. 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 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é K1 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 . 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 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 montre également un mode de réalisation de l’étape ST07. Celle-ci est identique à l’étape ST07 de la , à la différence près qu’elle est appliquée à 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 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 .
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 , symbolise la configuration du microcontrôleur quant au choix des identifiants ID1, ID2. Le bloc ST05B comprend deux sélecteurs SEL1 54 et SEL2 55 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 K1. Au cours d’une étape 124, le microcontrôleur déchiffre le bloc de données chiffré EIPi à partir de la clé K1 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é.
La montre des étapes d’exécution ST14, ST15 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 ST14 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é EID1 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 . 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 illustre une variante du mode de réalisation de la (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, SEL2 55 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 par l’insertion, dans le processus de déchiffrement des blocs de données IPi, d’une étape ST10 de vérification de la clé d’activation ACTIV2. L’étape ST10 comprend :
- 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 ACTIV1.
Le résultat de l’étape 103 est égal à la clé de chiffrement IPKi si la clé ACTIV2 est identique à la clé ACTIV1. 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, ) 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 + ACTIV1. Si les clés ACTIV1 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 K1. 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é K1 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 illustre une variante du mode de réalisation de la (clé OTA IPKj) lorsque la clé d’activation ACTIV1 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 par l’insertion, dans le processus de déchiffrement des blocs de données IPi, d’une étape ST13 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é ACTIV1 par chiffrement de l’identifiant ID3 au moyen de la fonction FC3 et à partir de la clé CK3,
- 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 . 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 ACTIV1 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é ACTIV1 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 PERS ( ). 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 ACTIV1 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 en jeu ces blocs de données IPi.
Claims (29)
- Procédé pour l’exécution d’un programme (FWR, IPi) par un microcontrôleur (CPU) en circuit intégré (IC1), 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 (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),
- 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é. - 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
- charger la première clé de chiffrement secondaire (CK1) dans la mémoire non volatile du microcontrôleur. - 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). - 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 (K1), et
- chiffrer (722) le bloc de données à partir de la clé de chiffrement dérivée (K1), pour obtenir le bloc de données sous sa forme chiffrée (EIPi). - 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 (K1), et
- déchiffrer (124) le bloc de données chiffré (EIPi) à partir de la clé de chiffrement dérivée (K1). - 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 le bloc de données sous sa forme chiffrée chargé dans la mémoire non volatile du microcontrôleur. - 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). - 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. - 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. - 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). - 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),
- 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. - 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). - 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. - 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), - 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).
- 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.
- 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. - Microcontrôleur en circuit intégré (IC1) 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),
- 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é. - 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). - 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 (K1), et
- déchiffrer (124) le bloc de données chiffré (EIPi) à partir de la clé de chiffrement dérivée (K1). - 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). - 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
- 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. - 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). - 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). - 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. - 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),
- 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 (ACTIV1). - 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).
- 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.
- 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.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| 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é |
| 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é |
| 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é |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2104943 | 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 (2)
| Publication Number | Publication Date |
|---|---|
| FR3122745A1 true FR3122745A1 (fr) | 2022-11-11 |
| FR3122745B1 FR3122745B1 (fr) | 2024-03-15 |
Family
ID=77821809
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2104943A Active 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é |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP4338078A1 (fr) |
| FR (1) | FR3122745B1 (fr) |
| WO (1) | WO2022238636A1 (fr) |
Citations (7)
| 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 |
-
2021
- 2021-05-10 FR FR2104943A patent/FR3122745B1/fr active Active
-
2022
- 2022-04-28 WO PCT/FR2022/050813 patent/WO2022238636A1/fr active Application Filing
- 2022-04-28 EP EP22726783.8A patent/EP4338078A1/fr active Pending
Patent Citations (7)
| 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 |
|---|---|
| EP4338078A1 (fr) | 2024-03-20 |
| FR3122745B1 (fr) | 2024-03-15 |
| WO2022238636A1 (fr) | 2022-11-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1570648B1 (fr) | Méthode de sécurisation des mises à jour de logiciels | |
| JP5636371B2 (ja) | 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム | |
| EP3320471B1 (fr) | Systeme et procede d'authentification et de licence ip de modules hardware | |
| FR2767208A1 (fr) | Systeme et procede de memorisation protegee de donnees secretes | |
| 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é | |
| EP1494460A1 (fr) | Procédé et dispositif d'authentification de données numériques par module d'extension d'authentification | |
| EP0720098B1 (fr) | Dispositif de sécurisation de systèmes d'information organisés autour de microprocesseurs | |
| 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 | |
| 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é | |
| FR2899409A1 (fr) | Dispositif de restitution d'un contenu numerique, entite electronique securisee, systeme comprenant ces elements et procede de restitution d'un contenu numerique | |
| CA2988357A1 (fr) | Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants | |
| 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. | |
| EP1291868A1 (fr) | Procédé et dispositif de stockage et de lecture de données numériques sur un support physique | |
| WO2024083849A1 (fr) | Encodage en boite blanche | |
| FR3073998B1 (fr) | Procede numerique de controle d'acces a un objet, une ressource ou service par un utilisateur | |
| EP1494461B1 (fr) | Procédé et dispositif d'authentification de données numériques à partir d'un module d'extension d'authentification | |
| 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 | |
| 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. | |
| FR2856815A1 (fr) | Procede d'authentification de donnees contenues dans un objet a memoire | |
| FR3106909A1 (fr) | Circuit intégré configuré pour réaliser des opérations de chiffrement symétrique avec protection de clé secrète |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20221111 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |