FR3049083A1 - Procede de duplication des donnees d'un microcircuit securise vers un autre microcircuit securise permettant, au plus, a un seul microcircuit securise d'etre operationnel a un instant donne - Google Patents

Abstract

Procédé permettant une copie ou une sauvegarde des données contenues dans un premier microcircuit sécurisé (MCA) vers un autre microcircuit sécurisé (MCB) avec, à tout instant, au maximum, un et un seul microcircuit sécurisé qui puisse être opérationnel à un instant donné. Le procédé permet d'effectuer: - soit une copie des données du microcircuit d'origine dans un autre microcircuit sécurisé (MCB) puis d'enchainer, en mode synchrone, avec un passage à l'état non opérationnel du microcircuit d'origine puis avec un passage à l'état opérationnel de cet autre microcircuit sécurisé. - soit une sauvegarde des données du microcircuit d'origine dans un ou plusieurs autres microcircuits sécurisés (MCB), puis ultérieurement, en mode asynchrone, d'effectuer le passage à l'état non opérationnel du microcircuit d'origine et le passage à l'état opérationnel de l'un de ces autres microcircuits sécurisés. Le procédé requiert la présence d'un serveur de migration (SM) de confiance pour chacun des microcircuits sécurisés, sachant que celui-ci peut être le même pour le microcircuit sécurisé source des données et celui destinataire des données.

Description

Description Domaine technique

La présente invention est applicable à n'importe quel type de microcircuit sécurisé dont on souhaiterait dupliquer le contenu sur un autre microcircuit sécurisé, soit à des fins de sauvegarde pour pouvoir bénéficier ultérieurement du contenu de cet un autre microcircuit sécurisé, par exemple, en cas de perte, de vol ou de détérioration du microcircuit sécurisé, soit pour migrer le contenu d'un microcircuit sécurisé sur un autre microcircuit sécurisé, par exemple, en cas de changement de format physique.

Technique antérieure Généralement, les microcircuits sécurisés sont livrés pré-personnalisés par un fournisseur (ou un "émetteur") et en cas de perte ou de vol un nouveau microcircuit sécurisé est délivré par le même fournisseur. L'inconvénient est que ce remplacement n'est pas immédiat, mais il permet de remplir l'objectif recherché: remettre à son propriétaire légitime, un nouveau microcircuit sécurisé avec le même contenu que celui qui y était présent lors de la remise initiale.

Cela explique pourquoi des techniques de duplications contrôlées des données contenues dans des microcircuits sécurisés n'ont pas été développées.

Cependant certains microcircuits sécurisés accumulent des données (qui ne sont donc pas présentes lors de la remise initiale) ou bien sont livrés sans aucune donnée, les données étant accumulées par le possesseur du microcircuit sécurisé durant son usage. C'est typiquement le cas pour les microcircuits sécurisés qui supportent le standard FIDO (https://fidoalliance.org/specs/) où s'acculent au fil du cycle de vie du microcircuit sécurisé des couples pseudonyme/clé privé.

Si le microcircuit sécurisé qui contient ces données est perdu, volé ou bien endommagé, l'utilisateur n'a plus d'accès aux comptes auxquels il pouvait accéder grâce à ces pseudonymes et à ces clés privées qui ne peuvent donc plus être utilisés dans le cadre du protocole U2F (Universal Second Factor) de FIDO.

Le procédé de copie du contenu d'un microcircuit sécurisé vers un autre microcircuit sécurisé est particulièrement utile en complément d'un "procédé d’accès à un service en ligne au moyen d'un microcircuit sécurisé et de jetons de sécurité, restreignant l'utilisation de ces jetons à leur détenteur légitime" qui fait l'objet d'un brevet en cours d'examen.

En effet, du fait qu'un microcircuit sécurisé, dans le cadre de cet autre brevet, a la possibilité, en particulier, de permettre la délivrance de jetons de sécurité indiquant que le porteur est majeur, il est particulièrement important d'empêcher qu'un autre microcircuit sécurisé contenant les donnés opérationnelles du premier microcircuit sécurisé puisse être créé et placé dans un état opérationnel puis être transmis à une personne qui serait mineure, car alors cette personne mineure pourrait dès lors être bénéficiaire d'un jeton de sécurité indiquant qu'elle est majeure, alors que cela n'est pas le cas.

En d'autres termes, s'il est permis de dupliquer le contenu d'un microcircuit sécurisé, un seul microcircuit sécurisé contenant les données opérationnelles du microcircuit sécurisé d'origine doit pouvoir être opérationnel à un instant donné. Résumé de l'invention L'objectif du procédé est de permettre d'effectuer une ou plusieurs copies des donnés opérationnelles contenues dans un microcircuit sécurisé dans un ou plusieurs autres microcircuits sécurisés mais de n'avoir, à un instant donné, au plus, qu'un et un seul microcircuit sécurisé opérationnel.

Le procédé comprend deux variantes qui permettent de réaliser: - soit une copie des données du microcircuit d'origine dans un autre microcircuit sécurisé (MCB) puis d'enchainer immédiatement avec le passage à l'état non opérationnel du microcircuit d'origine et le passage à l'état opérationnel de cet autre microcircuit sécurisé, - soit une sauvegarde des données du microcircuit d'origine dans un ou plusieurs autres microcircuits sécurisés (MCB), puis en temps différé, le passage à l'état non opérationnel du microcircuit d'origine et le passage à l'état opérationnel de l'un de ces autres microcircuits sécurisés.

La phase de copie des données de la première variante est identique à la phase de sauvegarde des données de la seconde variante.

Un utilisateur donné ne doit pouvoir disposer à un instant donné que d'un seul microcircuit sécurisé opérationnel. L'un des objectifs recherchés est d'empêcher que cet utilisateur soit en mesure de dupliquer les donnés opérationnelles contenues dans son microcircuit sécurisé opérationnel sur un autre opérationnel et de transmettre in fine cet autre microcircuit sécurisé à un autre utilisateur.

Le procédé permet d'effectuer: - d'une part, une copie des donnés opérationnelles contenues dans le premier microcircuit sécurisé dans un autre microcircuit sécurisé, par exemple, en cas de changement du format physique du microcircuit sécurisé. - d'autre part, à titre préventif, une sauvegarde des donnés opérationnelles contenues dans le premier microcircuit sécurisé dans un autre microcircuit sécurisé, par exemple: - en cas de vol ou de perte du microcircuit sécurisé, ou - en cas d'arrêt ou de mauvais de fonctionnement du microcircuit sécurisé.

En outre, en cas du vol à la fois du microcircuit sécurisé et du code PIN permettant son usage par son propriétaire légitime, le processus de copie des données contenues dans le microcircuit ne doit pas pouvoir être effectué par la personne effectuant un vol du premier microcircuit sécurisé et du code PIN à l'insu du propriétaire légitime, afin qu’il ne puisse pas créer un nouveau microcircuit puis restituer le microcircuit d’origine à son utilisateur légitime dans un état opérationnel.

La copie des donnés opérationnelles entre microcircuits sécurisés doit être impossible si l'un des microcircuits sécurisés a été déclaré comme étant volé.

Chaque microcircuit sécurisé est livré par le fournisseur ou par le personnalisateur du microcircuit sécurisé avec les deux données suivantes: - un certificat de clé publique spécifique au microcircuit sécurisé, - une clé privée associée, où la clé privée et la clé publique contenue dans le certificat de clé publique constituent une paire unique.

Nota: Ainsi qu'il en sera expliqué plus tard, au minimum, une donnée supplémentaire doit aussi être est fournie par le fournisseur ou par le personnalisateur du microcircuit sécurisé.

Le certificat de clé publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si la clé publique contenue dans le certificat de clé publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire).

Si le microcircuit sécurisé opérationnel a été déclaré comme étant volé, le certificat de clé publique de ce microcircuit sécurisé doit être révoqué par l'utilisateur dans les plus brefs délais. Cela est valable aussi bien pour le microcircuit sécurisé d'origine que pour les microcircuits sécurisés qui auraient reçu une copie des informations contenues dans le microcircuits sécurisé d'origine.

Cependant, le microcircuit sécurisé destinataire des données n'ayant généralement pas d'horloge fiable, celui-ci est dans l'impossibilité de vérifier par lui-même la date de la révocation. De ce fait, il est obligatoire de faire appel à un serveur "en ligne", appelé en la circonstance un "serveur de migration" (SM) qui lui dispose d'une horloge fiable. L'un des objectifs recherchés est qu'un serveur de migration ne soit pas en mesure de modifier les données échangées entre les microcircuits sécurisés, ni de pouvoir comprendre leur sémantique.

Dans le cadre de ce procédé, le flux de données opérationnelles échangées ne transite pas par les serveurs de migration mais est de plus effectué directement entre les microcircuits sécurisés avec une chiffrement des données et un contrôle de l'intégrité des données échangées.

Le procédé requiert la présence, dans chaque microcircuit sécurisé, d'une donnée supplémentaire qui est fournie par le fournisseur ou par le personnalisâtes du microcircuit sécurisé : - une clé publique permettant d’authentifier l’origine des messages émis par le serveur de migration en charge de ce microcircuit sécurisé, et - en option, une adresse (URL) permettant d'accéder au serveur de migration en charge de ce microcircuit sécurisé.

Nota: L'adresse (URL) permettant d'accéder à un serveur de migration du microcircuit sécurisé est optionnelle car elle peut être déduite du contenu du certificat de clé publique du microcircuit sécurisé ou même intégrée en tant qu'extension dans le certificat de clé publique du microcircuit sécurisé.

Le procédé comprend deux phases: 1. la phase de copie ou de sauvegarde des donnés opérationnelles contenues dans le microcircuit sécurisé opérationnel vers un microcircuit sécurisé non opérationnel, avec une protection en confidentialité des données transférées et une détection d'un manque éventuel d'intégrité des données transférées, 2. la phase de mise en état non opérationnel du microcircuit sécurisé contenant les données opérationnelles d'origine, suivie du passage à l'état opérationnel du microcircuit sécurisé contenant les données opérationnelles qui ont été transférées. Cette seconde phase comporte plusieurs variantes selon qu'elle s'effectue : - en mode synchrone, c'est à dire immédiatement à la suite de la phase de copie précédente ou - en mode asynchrone, c'est à dire après que la phase de sauvegarde des données se soit terminée et que les microcircuits sécurisés aient été déconnectés. 1. Phase de copie ou de sauvegarde des donnés opérationnelles contenues dans un microcircuit sécurisé opérationnel vers un microcircuit sécurisé non opérationnel

Les composants de l'architecture sont précisés sur la figure 1 (Fig. 1 ). Il s'agit - d'un microcircuit sécurisé A (MCA), qui est un microcircuit sécurisé opérationnel contenant des données opérationnelles. Ce composant est numéroté 1. - du serveur ou de la station de travail supportant le MCA (S/STA).

Ce composant est numéroté 2. - d'un microcircuit sécurisé B (MCB), qui est un microcircuit sécurisé non opérationnel ne contenant aucune donnée opérationnelle et qui va recevoir les données opérationnelles du microcircuit sécurisé A (MCA).

Ce composant est numéroté 3. - du serveur ou de la station de travail supportant le MCB (S/STB).

Ce composant est numéroté 4. - du serveur de migration A en charge du MCA (SMA).

Ce composant est numéroté 5. - du serveur de migration A en charge du MCB (SMB).

Ce composant est numéroté 6. - des informations de révocation accessibles aux serveurs de migration (Inf. Rev.). Ce composant est numéroté 7.

Nota: Dans certains cas, il peut n'y avoir qu'un seul serveur ou qu'une seule station de travail supportant les microcircuits sécurisés.

Chaque microcircuit sécurisé est rattaché à un serveur de migration.

Nota: Dans certains cas, il peut n'y avoir qu'un seul et même serveur de migration de rattachement pour les microcircuits sécurisés concernés.

Le rôle de ces serveurs de migration est de s'assurer que chacun des deux microcircuits sécurisés qui va prendre part au transfert des données respecte bien les contraintes liées au transfert et selon le cas: - d'autoriser ou d'interdire la sauvegarde ou la copie des données à caractère opérationnel depuis un microcircuit sécurisé vers un autre microcircuit sécurisé, et - d'autoriser ou d'interdire les changements d'état des microcircuits sécurisés depuis un état opérationnel vers un état non opérationnel et vice-versa.

Chaque microcircuit sécurisé contient au minimum trois données chargées à l'origine par le fabriquant du microcircuit sécurisé ou un personnalisateur de ce microcircuit sécurisé, à savoir: - un certificat de clé publique spécifique au microcircuit sécurisé. Ce certificat de clé publique matérialise le fait que le microcircuit sécurisé dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte. Il est délivré par une autorité de certification reconnue par les serveurs de migration. - une clé privée associée, où la clé privée et la clé publique constituent une paire unique, - une clé publique permettant d’authentifier l’origine des messages émis par le serveur de migration auquel ce microcircuit sécurisé est rattaché, et - en option, une adresse (URL) permettant d'accéder à ce serveur de migration de rattachement.

Une copie ou une sauvegarde des données entre microcircuits sécurisés ne pourra être effectuée qu'à la condition que le microcircuit sécurisé destinataire des données dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte et qu'il est vierge de données transférées au commencement du processus de copie.

Le fait que le microcircuit sécurisé destinataire des données dispose de "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte est matérialisé par le fait qu'il dispose d'un certificat de clé publique ad-hoc délivré par une autorité de certification reconnue, que le certificat est dans sa période de validité et que ce certificat n'est pas révoqué.

Si le microcircuit sécurisé destinataire des données n'est pas vierge de données ou que l'utilisateur ne les a pas préalablement toutes effacées, celles-ci devront être nécessairement effacées avant le début du processus de copie. Le but est d'empêcher de pouvoir ajouter des données transférées à des données qui seraient déjà présentes. De la sorte, en fin de copie, le contenu des données des deux microcircuits sécurisés sera identique.

La phase de copie ou de sauvegarde du contenu du microcircuit sécurisé opérationnel (MCA) vers un microcircuit sécurisé non opérationnel (MCB) ne peut donc commencer que si le microcircuit sécurisé (MCB) est vierge de données opérationnelles.

Le MCB vérifie que la zone qui va servir à accueillir les données communiquées par le MCA est vide. Si la zone n'est pas vide, les données présentes doivent être préalablement effacées. Le MCB dispose aussi d'une donnée spécifique destinée à mémoriser une somme de contrôle cryptographique calculée sur cette zone. Le MCB vérifie qu'il n'est pas dans un état opérationnel. Si cela n'est pas le cas, celui-ci doit être préalablement placé dans un état non opérationnel.

La figure 2 (Fig 2) illustre les échanges entre les différents composants du système.

Le dialogue débute par un échange de clés Diffie-Hellman signé effectué entre le microcircuit sécurisé opérationnel (MCA) et le microcircuit sécurisé non opérationnel (MCB).

Un échange de clé Diffie-Hellman signé comporte trois messages: - message 1 (M1): un nombre aléatoire n et un modulo p sont échangés entre le MCA et le MCB. Ce message est numéroté (M1 ) sur la figure 1, - message 2 (M2): le nombre aléatoire n est élevé à la puissance secrète a par le MCA, réduit au modulo p, une signature numérique calculée sur les données précédentes à l'aide de la clé privée du MCA et le certificat de clé publique du MCA. Ce message est numéroté (M2) sur la figure 1, - message 3 (M3): le nombre aléatoire n est élevé à la puissance secrète b par le MCB, réduit au modulo p, une signature numérique calculée sur les données précédentes à l'aide de la clé lé privée du MCB et le certificat de clé publique du MCB. Ce message est numéroté (M3) sur la figure 1.

Le nombre de messages peut être réduit à deux en combinant les messages 1 (M1) et 2 (M2). Le message 1 (M1) peut être envoyé en même temps que le message 2 (M2) ou bien le message 3 (M3) combiné au message 1 (M1) peut être envoyé avant le message 2 (M2). Selon le microcircuit sécurisé qui prend l'initiative du dialogue, l'ordre des messages 2 (M2) et 3 (M3) peut être inversé.

La clé secrète k construite suite à l'échange de clé Diffie-Hellmann signé est le nombre aléatoire n est élevé à la puissance secrète ab, le tout réduit modulo p. Un observateur intermédiaire (appelé en anglais "man in the middle") sera dans l'incapacité de la calculer.

Chacun des serveurs ou des stations de travail supportant un microcircuit sécurisé extrait ensuite du microcircuit sécurisé l'adresse (URL) permettant d'accéder au serveur de migration du microcircuit sécurisé.

Nota: Si cette adresse est absente, elle peut être fixe et prédéfinie dans le cadre d'une convention ou bien être déduite du contenu du certificat de clé publique du microcircuit sécurisé ou encore être intégrée en tant qu'extension dans le certificat de clé publique du microcircuit sécurisé.

Afin que le serveur de migration puisse détecter les rejeux, un défi est demandé à chaque serveur de migration par le serveur ou par la station de travail supportant le microcircuit sécurisé.

Le serveur ou la station de travail supportant le MCA envoie une demande de défi (DDA) au SMA et reçoit en retour une défi A (DA). Le défi A est ensuite relayé par le serveur ou la station de travail supportant le MCA auprès du serveur ou de la station de travail supportant le MCB.

Le serveur ou la station de travail supportant le MCB envoie une demande de défi (DDB) au SMB et reçoit en retour une défi B (DB). Le défi B est ensuite relayé par le serveur ou la station de travail supportant le MCB auprès du serveur ou de la station de travail supportant le MCA.

Le MCB génère un message 4 (M4) qui est envoyé par le serveur ou la station de travail supportant le MCB au serveur ou à la station de travail supportant le MCA puis qui est relayé auprès du SMA.

Ce message 4 (M4) comprend les données suivantes: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 4, - le défi A obtenu auprès du SMA, - le message 2 (M2) que le MCB a reçu du MCA (qui contient le certificat de clé publique du MCA), - le certificat de clé publique du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée spécifique du MCB.

Nota: le certificat de clé publique du MCB peut aussi être placé après la signature numérique et dans ce cas il n'entre pas dans le calcul de la signature numérique.

Le serveur ou la station de travail supportant le MCA auprès du SMA le microcircuit sécurisé demande un défi au SMB qui fournit en retour un défi B qui est alors transmis au MCA.

Le MCA génère alors un message 5 (M5) qui est envoyé par le serveur ou la station de travail supportant le MCA au serveur ou à la station de travail supportant le MCB puis qui est relayé auprès du SMB.

Ce message 5 (M5) comprend les données suivantes: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 5, - le défi obtenu auprès du SMB, - le message 3 (M3) que le MCA a reçu du MCB (qui contient le certificat de clé publique du MCB), - la clé publique permettant d’authentifier l’origine des messages émis par le SMA, - le certificat de clé publique du MCA, - en option, une URL permettant d'accéder au SMA, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée spécifique du MCA.

Nota: l'URL permettant d'accéder au SMA et/ou le certificat de clé publique du MCA peut aussi être placé après la signature numérique et dans ce cas n'entre pas dans le calcul de la signature numérique.

Ces messages sont envoyés et reçus par le serveur ou la station de travail supportant le microcircuit sécurisé. Il est évident que l'ordre d'envoi des messages 4 (M4) et 5 (M5) peut être inversé.

Chacun des messages est ensuite envoyé par le microcircuit sécurisé à son serveur de migration.

Le serveur SMA vérifie qu'il s'agit bien d'un message de type 4, que le défi qui est présent est identique à celui qu'il vient d'envoyer, que le certificat de clé publique du MCA est délivré par une autorité de certification reconnue, que ce certificat dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué.

Il vérifie aussi que le message 2 (M2) qui est contenu dans ce message 4 (M4) est correctement signé par la clé publique contenue dans le certificat de clé publique du MCB, que le certificat de clé publique du MCB est un certificat délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué.

Il vérifie aussi que l'ensemble des données est correctement signé à l'aide de la clé privée correspondant au certificat de clé publique du MCA.

Le serveur SMA mémorise, suite la réception et à la vérification d'un message de type 4, le certificat de clé publique du MCA et un triplet de données constitué: - du certificat de clé publique du MCB, - de la clé publique permettant d’authentifier l’origine des messages émis par le SMB de rattachement du MCB, - d'un indicateur précisant que ce MCB est dans un état non opérationnel.

Nota: la date de l'écriture ou de la modification de chaque triplet pourra être avantageusement ajoutée afin de pouvoir connaître la date de l'évènement.

Ces données ne devront en aucun cas être supprimées avant la fin de validité du certificat de clé publique du MCA.

Si un triplet est déjà présent, un nouveau triplet est ajouté à la suite du dernier triplet présent. Ces informations permettent d'identifier les microcircuits sécurisés qui sont ou qui ont été bénéficiaires d'une copie des données opérationnelles d'un microcircuit sécurisé donné.

On observera que les données contenues dans un microcircuit sécurisé peuvent être sauvegardées dans plusieurs microcircuits sécurisés.

Ainsi qu'il en sera expliqué plus tard, ces triplets vont permettre de contrôler et d'effectuer le basculement à l'état opérationnel d'un et d'un seul microcircuit sécurisé sur lequel les données du MCA auront été préalablement transférées.

De même, le serveur SMB vérifie qu'il s'agit bien d'un message de type 5, que le défi qui est présent est identique à celui qu'il vient d'envoyer, que le certificat de clé publique du MCB est délivré par une autorité de certification reconnue, que ce certificat dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué. Il vérifie aussi que le message 3 (M3) qui est contenu dans ce message 5 (M5) est correctement signé par la clé publique contenue dans le certificat de clé publique du MCA, que le certificat de clé publique du MCA est un certificat délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué.

Il vérifie aussi que l'ensemble des données est correctement signé à l'aide de la clé privée correspondant au certificat de clé publique du MCB.

Le SMB mémorise, suite la réception et à la vérification d'un message de type 5, le certificat de clé publique du MCB et un doublet ou un triplet de données constitué: - du certificat de clé publique du MCA, - de la clé publique permettant d’authentifier l’origine des messages émis par le serveur de migration du MCA (SMA), et éventuellement - de l'URL permettant d'accéder au serveur de migration du MCA (SMA).

Ces données ne devront en aucun cas être supprimées avant la fin de validité du certificat de clé publique du MCB.

Nota: la date de l'écriture de chaque doublet ou triplet pourra être avantageusement ajoutée afin de pouvoir connaître la date de l'évènement.

Si un doublet ou un triplet est déjà présent, un nouveau doublet ou triplet est ajouté à la suite du dernier doublet ou triplet présent. On observera qu'un même microcircuit sécurisé peut être successivement porteur des données de différents microcircuits sécurisés. Le dernier triplet permet d'identifier l'origine des dernières données copiées dans un microcircuit sécurisé donné.

Cette donnée qui est fondamentale sera utilisée lors de la procédure de changement d'état opérationnel, afin de s'assurer que le MCB qui va être rendu opérationnel est effectivement toujours porteur des données qu'il a reçues du MCA.

Le certificat de clé publique du MCA permettra au SMB de préciser au SMA le microcircuit sécurisé concerné par l'opération de désactivation.

La clé publique permettant d’authentifier l’origine des messages émis par le SMA, et l'URL permettant d'accéder au SMA vont permettre au SMB de contacter le SMA et de s'assurer qu'il est bien en liaison avec le SMA. L'ordre des vérifications des messages 4 (M4) et 5 (M5) peut être inversé.

Le serveur de migration SMA renvoie ensuite au serveur ou à la station de travail supportant le microcircuit sécurisé MCA qui l'a contacté le message 6 (M6) suivant qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 6, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le transfert des données entre les microcircuits sécurisés, et - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA.

La donnée permettant de détecter les rejeux est une donnée à caractère unique. Elle peut être communiquée au moyen d'un échange supplémentaire ou bien afin d'éviter cet échange supplémentaire, cela peut être une donnée unique déjà présente dans un message précédent. A titre d'exemple, une donnée permettant de détecter les rejeux dans le message 6 (M6) sera une donnée déjà présente dans le message 4 (M4), telle la valeur de la signature numérique effectuée à l'aide de la clé privée du MCA. Une convention devra être passée entre le microcircuit sécurisé et son serveur de migration pour déterminer quelle est la donnée permettant de détecter les rejeux.

Le serveur de migration SMB renvoie au serveur ou à la station de travail du microcircuit sécurisé MCB qui l'a contacté le message 7 (M7) suivant qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 7, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le transfert des données entre les microcircuits sécurisés, et - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB.

La donnée permettant de détecter les rejeux est une donnée à caractère unique. Elle peut être communiquée au moyen d'un échange supplémentaire ou bien afin d'éviter cet échange supplémentaire, cela peut être une donnée unique déjà présente dans un message précédent. A titre d'exemple, une donnée permettant de détecter les rejeux dans le message 7 (M7) sera une donnée déjà présente dans le message 5 (M5), telle la valeur de la signature numérique effectuée à l'aide de la clé privée du MCA.

Une convention devra être passée entre le microcircuit sécurisé et son serveur de migration pour déterminer quelle est la donnée permettant de détecter les rejeux.

Le MCA vérifie qu'il s'agit bien d'un message de type 6 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCA vérifie la signature numérique du message au moyen de la clé publique du SMA.

Si la signature numérique est correcte, le MCA s'assure de la présence de l'indicateur d'accord pour le transfert des données entre les microcircuits sécurisés.

De même, le MCB vérifie qu'il s'agit bien d'un message de type 7 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie la signature numérique du message au moyen de la clé publique du SMB.

Si la signature numérique est correcte, le MCB s'assure de la présence de l'indicateur d'accord pour le transfert des données entre les microcircuits sécurisés.

Chaque microcircuit sécurisé annonce à l'autre lorsqu'il est prêt pour débuter le transfert. Le transfert des données est effectué au moyen de messages échangés directement entre les microcircuits sécurisés via les serveurs ou les stations de travail supportant les microcircuits sécurisés.

La figure 3 (Fig.3) illustre les échanges effectués entre les deux microcircuits sécurisés. Il s'agit d'une suite de n échanges numérotés E1, E2, jusqu'à E1n et E2n. Chaque message comporte un identifiant de message permettant de savoir qu'il s'agit d'un message du type "transfert de données opérationnelles".

Les données opérationnelles du MCA sont transférées vers le MCB : - chiffrées au moyen de la clé k ou bien d'une clé dérivée de la clé k, et - scellées au moyen de la clé k ou bien d'une clé dérivée de la clé k.

La clé secrète k est la clé qui a été construite durant l'échange de clé Diffie-Hellmann: c'est le nombre aléatoire n est élevé à la puissance secrète ab, le tout réduit modulo p.

Les données reçues sont déchiffrées par le MCB avant d'être stockées dans le MCB.

Afin de s'assurer qu'aucun message n'est supprimé durant le transfert, une somme de contrôle cryptographique est calculée au fur et à mesure des messages échangés (Fig. 3). Le MCB vérifie que la valeur de chaque somme cryptographique reçue est égale à celle qu'il a lui même calculé.

Si cela n'est pas le cas, l'ensemble des données déjà transférées sur le MCB est automatiquement effacé. Un nouveau transfert de données pourra cependant être tenté.

Si cela est le cas, les données qui étaient présentes dans le MCA sont maintenant présentes dans le MCB.

Afin de pouvoir s'assurer ultérieurement que le transfert des données a été intégralement effectué, le MCB calcule une somme de contrôle cryptographique sur les données transférées qui ont été mémorisées dans sa mémoire non volatile et mémorise cette somme de contrôle cryptographique. A ce stade, le MCB est toujours dans un état non opérationnel. 2. Phase de mise en état non opérationnel du microcircuit sécurisé contenant les données d’origine suivie du passage à l'état opérationnel du microcircuit sécurisé contenant les données copiées

En préalable, il est rappelé que lors d'un transfert des données entre microcircuits sécurisés: - le serveur de migration auquel est rattaché le microcircuit sécurisé origine des données a été en mesure de mémoriser des données permettant de savoir vers quel(s) microcircuit(s) sécurisé(s) les données de ce microcircuit sécurisé origine des données, ont été transférées (à supposer que les opérations de transfert des données se soient terminées avec succès), et - le serveur de migration auquel est rattaché le microcircuit sécurisé destinataire des données a été en mesure de mémoriser des données permettant de savoir depuis quel(s) microcircuit(s) sécurisé(s) des données de ce microcircuit sécurisé destinataire des données, ont été transférées (à supposer que les opérations de transfert des données se soient terminées avec succès).

Dans le premier cas, il s'agit du certificat de clé publique d'un microcircuit sécurisé (MCA) et au moins un triplet de données constitué: - du certificat de clé publique d'un MCB, - de la clé publique permettant d’authentifier l’origine des messages émis par le SMB, - d'un indicateur précisant si ce MCB est dans un état opérationnel on non opérationnel.

Dans le second cas, il s'agit du certificat de clé publique d'un microcircuit sécurisé (MCB) et au moins un doublet (sinon un triplet) de données constitué: - le certificat de clé publique d'un MCA, - la clé publique permettant d’authentifier l’origine des messages émis par le SMA, et éventuellement - de l'URL permettant d'accéder au SMA.

Pour le SMA, chaque triplet permet de savoir vers quel(s) microcircuit(s) sécurisé(s) les données de ce MCA ont été transférées (à supposer que les opérations de transfert des données se soient terminées avec succès).

Pour le SMB, chaque doublet ou triplet permet de savoir depuis quel(s) microcircuit(s) sécurisé(s) des données ont été transférées sur ce MCB (à supposer que les opérations de transfert des données se soient terminées avec succès).

Pour que le MCB puisse passer à l'état opérationnel, il est nécessaire que le MCA soit d'abord placé dans un état non opérationnel. Il y a deux manières pour que le MCA puisse passer d'un état opérationnel à un état non opérationnel: a) effectuer une mise en état non opérationnel du MCA avec un dialogue direct entre le MCA et le MCB (par exemple, en cas de changement de support physique), ou bien b) effectuer une mise en état non opérationnel du MCA sans dialogue avec le MCA (cas du vol ou de la perte du MCA). Dans ce cas, le possesseur du microcircuit sécurisé doit préalablement demander la révocation du certificat de clé publique du microcircuit sécurisé qu'il utilisait.

2.1. Mise en état opérationnel d'un microcircuit sécurisé destinataire de données en mode synchrone avec un dialogue entre le MCA et le MCB

Le procédé qui est décrit ci-dessous et qui comporte deux variantes est effectué immédiatement après la copie des données contenues dans le MCA au profit du MCB, sans mise hors tension du MCA ou du MCB. Il nécessite donc la présence physique du MCA et s'effectue sans la révocation du certificat du MCA (la non révocation du certificat de clé publique du MCA a déjà été vérifié avant le début de la copie des informations du MCA vers le MCB, il n'est donc pas utile de le vérifier une seconde fois).

Dans la première variante, le SMA est directement contacté par le MCA, tandis que dans la seconde variante, le SMA est indirectement contacté par le MCA via le MCB et le SMB.

Il est rappelé que les deux microcircuits sécurisés partagent toujours une clé secrète k qui est le nombre aléatoire n échangé à l'origine qui a été élevé à la puissance secrète ab, le tout réduit modulo p.

2.2.1. Variante 1 : le SMA est directement contacté par le MCA

Les microcircuits sécurisés destinataires des données ne pourront passer à l'état opérationnel qu'après avoir reçu l'aval du serveur de migration de rattachement du microcircuit sécurisé origine des données.

La figure 4 (Fig. 4) qui se place chronologiquement après la figure 3 (Fig.3), illustre les échanges entre les différents composants du système.

Le MCA envoie au SMA un message 12 (M12) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 12, - une donnée permettant de détecter les rejeux, - le certificat de clé publique du MCA, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée spécifique du MCA.

Nota: le certificat de clé publique du MCA peut aussi être placé après la signature numérique et dans ce cas il n'entre pas dans le calcul de la signature numérique.

Il n'est pas indispensable de chiffrer cet échange.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire; par exemple, la signature numérique présente dans le message 10 (M10),

Le SMA vérifie que le message 12 (M12) contient effectivement le défi qu'il vient d'envoyer et que le message est correctement signé parle MCA. Dans l'entrée relative au MCA, il examine le triplet qui lui est attaché à la recherche du triplet qui contient la valeur du certificat de clé publique du MCB,

Le SMA modifie l'indicateur précisant si le microcircuit sécurisé MCB est ou non opérationnel et le positionne à l'état opérationnel.

Dans la réalité, le SMA anticipe ce changement d'état, car le MCB va seulement devenir opérationnel après la bonne réception du message 14 (M14).

Le SMA envoie au MCA un message 13 (M13) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 13, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour la mise en état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 12 (M12).

Le MCA vérifie: - que le message qu'il a reçu est bien d'un message de type 13, - que la donnée permettant de détecter les rejeux a la bonne valeur, - que l'indicateur d'accord pour le passage à l'état opérationnel du MCB est bien présent, - que la signature numérique est valide en utilisant la clé publique du SMA.

Le MCA se positionne alors à l'état non opérationnel et autorise le passage du MCB à l'état opérationnel au moyen du message 14 (M14) qui est constitué de la manière suivante: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 14, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le passage à l'état opérationnel du MCB, - un scellement numérique calculé sur les données précédentes à l'aide de la clé secrète k ou bien d'une clé dérivée de la clé k.

Il n'est pas indispensable de chiffrer cet échange.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique présente dans le dernier message précédent; par exemple, le scellement précédent.

Le MCB vérifie que le message qu'il a reçu est bien d'un message de type 14 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que le message est correctement scellé à l'aide de la clé secrète k. Il vérifie la présence de l'indicateur d'accord pour le passage à l'état opérationnel et se place alors dans un état opérationnel.

Si seul le processus de passage à l'état opérationnel en mode synchrone est supporté par les microcircuits sécurisés destinataires des données, alors il n'est pas indispensable d'informer le SMA du passage à l'état opérationnel du MCB et les messages 12 (M12) et 13 (M13) peuvent alors être omis: un ordre est adressé au MCA qui se place à l'état non opérationnel et le MCA autorise alors le passage du MCB à l'état non opérationnel au moyen du message 14 (M14).

Il est important de noter que cette procédé simplifié présente le désavantage de ne pas permettre d'auditer les changements d'état opérationnel des microcircuits sécurisés au niveau des serveurs de migration de rattachement des microcircuits sécurisés. Ce procédé simplifié ne doit en aucun cas être utilisé dès lors que les microcircuits sécurisés supportent le processus de passage à l'état opérationnel en mode asynchrone.

2.2.2. Variante 2: le SMA est indirectement contacté par le MCA

Les microcircuits sécurisés destinataires des données ne pourront passer à l'état opérationnel qu'après avoir reçu l'aval du serveur de migration de rattachement du microcircuit sécurisé origine des données.

La figure 5 (Fig. 5) qui chronologiquement se place après la figure 3 (Fig.3), illustre les échanges entre les différents composants du système: - un message 16 (M16) envoyé par le MCA au MCB, - un message 17 (M17) envoyé par le MCB au SMB, - un message 18 (M18) envoyé par le SMB au SMA, - un message 19 (M19) envoyé par le SMA au SMB, - un message 20 (M20) envoyé par le SMB au MCB.

Nota: une variante est de faire précéder l'échange 16 (M16) d'un message 15 (M15) où le MCB demande au MCA de se placer dans un état non opérationnel.

Le MCA reçoit l'ordre de se placer dans un état non opérationnel.

Le message 16 (M16) envoyé par le MCA au MCB contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 16, - une donnée permettant de détecter les rejeux, - un indicateur de prise en compte de la mise en état non opérationnel du MCA, - un scellement numérique calculé sur les données précédentes à l'aide de la clé secrète k ou bien d'une clé dérivée de la clé k.

Il n'est pas indispensable de chiffrer cet échange.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique présente dans le dernier message précédent; par exemple, le scellement précédent.

Le MCB vérifie que le message qu'il a reçu est bien d'un message de type 16 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que le message est correctement scellé à l'aide de la clé secrète k et que la donnée permettant de détecter l'absence de rejeu est bien présente.

Les échanges se poursuivent pour signaler au SMA qu'un MCB souhaite son passage à l'état opérationnel. En effet, si le MCB passait immédiatement à l'état opérationnel, le SMA n'en saurait rien, ce qui permettrait de rendre ensuite opérationnel, grâce au processus de passage à l'état opérationnel en mode asynchrone, l'un des microcircuits sécurisés supportant une sauvegarde des données du MCA. Cela aurait pour conséquence de rendre opérationnels deux microcircuits contenant les données du MCA, ce qui est à l'opposé de l'un des objectifs fondamentaux recherchés. Il est donc nécessaire de centraliser au niveau d'un serveur de migration (le SMA) les changements d'état opérationnel des microcircuits sécurisés origine des données. Des messages supplémentaires sont échangés afin de supporter ce cas.

Préalablement à l'envoi du message 17 (M17), le serveur ou la station de travail supportant le MCB se connecte au SMB et demande un défi (challenge en anglais) au SMB. Le serveur ou la station de travail supportant le MCB communique ce défi B au MCB.

Le message 17 (M17) envoyé par le MCB au SMB contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 17, - le défi B, - le certificat de clé publique du MCB, - une signature numérique effectuée sur les données précédentes à l'aide de la clé privée du MCB,

Nota: le certificat de clé publique du MCB peut aussi être placé après la signature numérique et dans ce cas il n'entre pas dans le calcul de la signature numérique.

Le SMB vérifie: - que le message qu'il a reçu est bien d'un message de type 17, - que le défi correspond à celui qui vient d'être envoyé, - que le certificat de clé publique du MCB a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en oeuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité.

Nota: L'état de révocation n'a pas besoin d'être testé, car il l'a déjà été avant la copie des données contenu dans le MCA au profit du MCB, - que la signature numérique est valide à l'aide de la clé publique contenue dans le certificat de clé publique du MCB.

Le SMB consulte les informations qu'il a mémorisées à la recherche d'une entrée contenant le certificat de clé publique du MCB. Si cette entrée est absente, le processus est interrompu.

Si cette entrée est présente, le SMB récupère : - le certificat de clé publique d'un MCA, - la clé publique permettant d’authentifier l’origine des messages émis par le SMA de rattachement de ce MCA, et éventuellement - l'URL permettant d'accéder au SMA de rattachement de ce MCA.

Le SMB vérifie alors que le certificat de clé publique du MCA a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en oeuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué.

Si toutes ces vérifications sont satisfaites alors le serveur SMB se connecte au SMA à l'aide de l'URL permettant d'accéder au SMA de rattachement de ce MCA et demande un défi (challenge en anglais) au SMA.

Le SMB envoie au SMA un message 18 (M18) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 18, - le défi A généré par le SMA, - le certificat de clé publique du MCA, - la clé publique du SMB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB.

Nota: la clé publique du SMB peut aussi être placée après la signature numérique et dans ce cas elle n'entre pas dans le calcul de la signature numérique.

Le SMA vérifie que le message qu'il a reçu est bien d'un message de type 18 et que le défi A contenu dans le message 18 (M18) est identique au défi qu'il avait envoyé. Si cela n'est pas le cas, le processus est interrompu.

Le SMA extrait du message 18 (M18) le certificat de clé publique du MCA et s'assure que le certificat de clé publique du MCA a bien déjà été mémorisé. Si cela n'est pas le cas, le processus est interrompu.

Le SMA examine tous les triplets rattachés au certificat du MCA. Si un triplet contient un indicateur précisant qu'un microcircuit sécurisé est déjà passé dans un état opérationnel, le processus est interrompu.

Le SMA récupère les données associées au certificat du MCA, à savoir un ou plusieurs triplets, chaque triplet étant composé : - du certificat d’un MCB, - d'un indicateur précisant si ce MCB est ou non opérationnel, - de la clé publique permettant d’authentifier l’origine des messages émis par le SMB de ce MCB.

Il recherche le triplet contenant le certificat de ce MCB. Si ce certificat ne figure dans aucun triplet, le processus est interrompu.

Le SMA vérifie la signature numérique du message 18 (M18) à l'aide de la clé publique du SMB contenue dans cette entrée. Si la vérification n'est pas concluante, le processus est interrompu.

Dans le triplet qui contient la valeur du certificat de clé publique du MCB, le SMA modifie l'indicateur précisant si le microcircuit sécurisé est ou non opérationnel pour le positionner à un état opérationnel.

Dans la réalité, le SMA anticipe ce changement d'état, car le MCB va seulement devenir opérationnel après la bonne réception par le MCB du message 20 (M20).

Le message 19 (M19) envoyé par le SMA au SMB contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 19, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour la mise en état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 18 (M18).

Le SMB vérifie que le message qu'il a reçu est bien d'un message de type 19 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que la signature numérique est exacte. Le SMB va alors indiquer au MCB qu'il est autorisé à basculer dans un état opérationnel.

Le message 20 (M20) envoyé par le SMB au MCB contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 20, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le passage à l'état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 17 (M17).

Le MCB vérifie que le message qu'il a reçu est bien d'un message de type 20 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que la signature numérique du message 20 (M20) est exacte. Si cela n'est pas le cas, le processus est interrompu. Si cela est le cas, le MCB peut alors basculer dans un état opérationnel.

2.1. Mise en état opérationnel du microcircuit sécurisé MCB destinataire de données copiées en mode asynchrone sans dialogue avec le MCA

La figure 6 (Fig 6) illustre les échanges entre les différents composants du système.

Le MCB vérifie qu'il contient un transfert complet de données sauvegardées en recalculant une somme de contrôle cryptographique sur les données transférées qu'il a stockées dans sa mémoire et en la comparant avec la somme de contrôle cryptographique qui a été mémorisée. Si le résultat du calcul est différent, alors le processus est interrompu.

Le serveur ou la station de travail supportant le MCB se connecte au SMB et demande un défi (challenge en anglais) au SMB au moyen du message DDB. Le serveur ou la station de travail supportant le MCB communique ce défi B au MCB au moyen du message (DB).

Le MCB génère à l'attention du serveur de migration SMB un message 21 (M21) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 21, - le défi B, - le certificat de clé publique du MCB, - un indicateur précisant si le MCB est dans un état opérationnel ou bien dans un état non opérationnel, - une signature numérique effectuée sur les données précédentes à l'aide de la clé privée du MCB.

Nota: le certificat de clé publique du MCB peut aussi être placé après la signature numérique et dans ce cas il n'entre pas dans le calcul de la signature numérique.

Le SMB vérifie: - que le message qu'il a reçu est bien d'un message de type 21, - que le défi correspond à celui qui vient d'être envoyé, - que le certificat de clé publique du MCB a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et au moyen des messages 22 (M22) et 23 (M23) qu'il n'est pas révoqué, - que le MCB est dans un état non opérationnel, - à l'aide de la clé publique contenue dans le certificat de clé publique du MCB que la signature numérique est valide.

Si l'une de ces conditions n'est pas vérifiée, le processus est interrompu.

Le SMB consulte les informations qu'il a mémorisées à la recherche d'une entrée contenant le certificat de clé publique du MCB. Si cette entrée est absente, le processus est interrompu.

Si cette entrée est présente, le SMB s'assure au moyen des messages 22 (M22) et 23 (M23) que le certificat du MCB n'est pas révoqué. Si cela n'est pas le cas, le processus est interrompu.

Le SMB récupère le dernier triplet rattaché au certificat du MCB. Celui-ci contient: - le certificat de clé publique d'un MCA, - la clé publique permettant d’authentifier l’origine des messages émis par le SMA, et éventuellement de l'URL permettant d'accéder au SMA et éventuellement, - l'URL permettant d'accéder au SMA de rattachement de ce MCA..

Le SMB vérifie alors que le certificat de clé publique du MCA a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et au moyen des messages 22 (M22) et 23 (M23) qu'il est a été révoqué à la demande de son utilisateur légitime. Il vérifie aussi que le certificat de clé publique du MCB n'est pas révoqué.

Si ces vérifications ne sont pas effectuées avec succès alors le processus est interrompu. Si toutes ces vérifications sont satisfaites alors le serveur SMB contacte le SMA à l'aide de l'URL permettant d'accéder au SMA de rattachement de ce MCA.

Le SMB demande un défi (challenge en anglais) DA au SMA. Le SMA communique ce défi A (DA) au SMB.

Le SMB génère pour le SMA un message 24 (M24) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 24, - le défi A généré par le SMA, - le certificat de clé publique du MCA, - la clé publique du SMB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB.

Nota: la clé publique du SMB peut aussi être placée après la signature numérique et dans ce cas elle n'entre pas dans le calcul de la signature numérique.

Le SMA vérifie que le message qu'il a reçu est bien d'un message de type 24 et que le défi contenu dans le message 24 (M24) est identique au défi qu'il avait envoyé. Si cela n'est pas le cas, le processus est interrompu. Le SMA consulte les informations qu'il a mémorisées à la recherche d'une entrée contenant le certificat de clé publique du MCA. Si cette entrée est absente, le processus est interrompu.

Si cette entrée est présente, il s'assure au moyen des messages 25 (M25) et 26 (M26) que le certificat du MCA a bien été révoqué et que celui du MCB n'est pas révoqué. Si cela n'est pas le cas, le processus est interrompu.

Pour que le SMA puisse autoriser le passage du MCB à l'état opérationnel, il faut qu'aucun microcircuit sécurisé contenant les données de ce MCA ne soit déjà passé à un état opérationnel. Pour ce faire, le SMA examine tous les triplets rattachés au certificat du MCA. Si l'un des triplets contient un indicateur précisant qu'un microcircuit sécurisé est déjà passé dans un état opérationnel, le processus est interrompu.

Le SMA recherche le triplet contenant le certificat de ce MCB. Si ce certificat ne figure dans aucun triplet, le processus est interrompu. Si le certificat de ce MCB est trouvé, le SMA vérifie que la clé publique du SMB figurant dans le message 24 (M24) est bien identique à la clé publique figurant dans le triplet. Si cela n'est pas le cas, le processus est interrompu.

Le SMA vérifie l'exactitude du calcul de la signature numérique à l'aide de la clé publique du SMB. Si cela n'est pas le cas, le processus est interrompu.

Dans le triplet qui contient la valeur du certificat de clé publique du MCB, le SMA modifie l'indicateur précisant si le microcircuit sécurisé est ou non à l'état opérationnel et le positionne à l'état "opérationnel". Dans la réalité, le SMA anticipe ce changement d'état, car le MCB va seulement devenir opérationnel après la bonne réception du message 28 (M28).

Le SMA envoie alors au SMB un message 27 (M27) constitué des données suivantes: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 27, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour la mise en état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 24 (M24).

Le SMB vérifie que le message qu'il a reçu est bien d'un message de type 27 et en utilisant la valeur pour détecter les rejeux vérifie la signature numérique du message à l'aide de la clé publique du SMA. Si l'une des vérifications échoue, le processus est abandonné.

Le SMB va alors indiquer au MCB qu'il est autorisé à passer dans un état opérationnel. Pour cela, le SMB génère à l'attention du MCB un message 28 (M28) constitué des données suivantes: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 28, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le passage à l'état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB.

La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 21 (M21).

Le MCB vérifie que le message qu'il a reçu est bien d'un message de type 28. Si cela n'est pas le cas, le processus est interrompu.

Le MCB vérifie à l'aide de la clé publique du SMB qu'en utilisant la valeur pour détecter les rejeux, la signature numérique du message 28 (M28) est exacte. Si cela est le cas, le MCB bascule dans un état opérationnel. 3. Des nouvelles sauvegardes sont alors fortement recommandées

Une fois qu'un MCB est devenu opérationnel, il est fortement recommandé à l'utilisateur d'effectuer dès que possible une sauvegarde des données contenues dans le nouveau microcircuit sécurisé sur un ou plusieurs autres microcircuits sécurisés. En effet, si d'autres sauvegardes du MCA avaient été effectuées sur d'autres microcircuits sécurisés, ces sauvegardes ne seront plus utilisables. 4. Avantages du procédé

Il est possible d'interroger les serveurs de migration et de savoir d'une part: - vers quel(s) microcircuit(s) sécurisé(s) le contenu d'un microcircuit sécurisé a été transféré (à supposer que les opérations de transfert des données se soient terminées avec succès) et si l'état opérationnel de ce microcircuit sécurisé a été ou non transféré à l'un de ces microcircuits sécurisés, et d'autre part - depuis quel(s) microcircuit(s) sécurisé(s) des données ont été transférées sur un microcircuit sécurisé donné (à supposer que les opérations de transfert des données se soient terminées avec succès).

La traçabilité des opérations de sauvegarde, de copie et de transfert d'état opérationnel est ainsi assurée.

Cette traçabilité peut s'avérer particulièrement utile dans les cas suivants:

Cas n° 1 : Si l'un des microcircuits sécurisés contenant une sauvegarde des données d'un propriétaire légitime d'un microcircuit sécurisé est passé en mode opérationnel contre la volonté de son propriétaire légitime (agissement sous la contrainte) alors cet utilisateur légitime pourra ultérieurement contacter le SMA afin d'identifier le SMB qui est devenu opérationnel et demander sa révocation, ce qui aura pour effet de le rendre alors non opérationnel.

Cas n° 2 : Si l'un des microcircuits sécurisés sur lequel une sauvegarde a été effectuée a été perdu ou a été volée, la personne qui a retrouvé ou qui avait volé ce microcircuit sécurisé a la possibilité d'effectuer un changement d'état opérationnel sur le microcircuit sécurisé qui a été perdu ou volé dès l'instant où le certificat de clé publique du microcircuit sécurisé d'origine est révoqué, en engageant une "course contre le montre" vis à vis du propriétaire légitime du microcircuit sécurisé. Si le propriétaire légitime du microcircuit sécurisé perd cette course contre la montre, il pourra alors contacter le SMA afin d'identifier le CMB qui est devenu opérationnel et demander sa révocation, ce qui aura pour effet de le rendre alors non opérationnel.

Description des modes de réalisation

Le microcircuit sécurisé sera réalisé au moyen d'un unique composant électronique ou bien au moyen de plusieurs composants électroniques encapsulés dans un autre composant ou encore au moyen de plusieurs composants électroniques protégés par une enceinte sécurisée, généralement appelée "enceinte cryptographique", l'une ou l'autre de ces réalisations disposant des protections telles que décrites dans l'invention, tandis que ledit "microcircuit sécurisé" s'interfacera avec son environnement extérieur, soit au moyen d'une interface avec contacts, soit au moyen d'une interface sans contact.

Les serveurs ou les postes de travail supportant les microcircuits sécurisés seront reliés entre eux au moyen d'un réseau. Les serveurs de migration seront reliés entre eux et aux serveurs ou postes de travail supportant les microcircuits sécurisés au moyen d'un réseau. Si chaque microcircuit est régi par le même serveur de migration, il n'y a plus alors qu'un seul serveur de migration au lieu de deux.

Brève description des dessins

La Figure 1 illustre l'architecture du système et les dialogues possibles entre les différents composants du système.

La Figure 2 illustre les dialogues pour pouvoir effectuer le transfert des données.La Figure 3 illustre uniquement la phase de transfert des données.

La Figure 4 illustre le passage à l’état opérationnel d’un MCB contenant une copie des données d'un MCA, en mode synchrone, consécutivement à un dialogue avec le MCA où le SMA est directement contacté par le MCA.

La Figure 5 illustre le passage à l’état opérationnel d’un MCB contenant une copie des données d'un MCA, en mode synchrone, consécutivement à un dialogue avec le MCA où le SMA est indirectement contacté par le MCA via le MCB et le SMB.

La Figure 6 illustre le passage à l’état opérationnel d’un MCB contenant une sauvegarde des données d'un MCA, en mode asynchrone, sans dialogue avec le MCA.

Claims (11)

1. Revendications Revendication 1. Procédé permettant de dupliquer les données opérationnelles contenues dans un microcircuit sécurisé dans un autre microcircuit sécurisé et qui, à tout instant, ne permet l'usage opérationnel que d'un seul microcircuit sécurisé, ce procédé étant réalisable selon deux variantes : - soit, en effectuant une copie des donnés opérationnelles contenues dans le premier microcircuit sécurisé dans un autre microcircuit sécurisé, par exemple, en cas de changement du format physique du microcircuit sécurisé, - soit en effectuant une sauvegarde préventive des donnés opérationnelles contenues dans le premier microcircuit sécurisé dans un autre microcircuit sécurisé, par exemple: - en cas de vol ou de perte du microcircuit sécurisé, ou - en cas d'arrêt ou de mauvais de fonctionnement du microcircuit sécurisé. et comprenant deux phases: - une phase de copie ou de sauvegarde des donnés opérationnelles contenues dans le microcircuit sécurisé opérationnel vers un microcircuit sécurisé non opérationnel, avec une protection en confidentialité des données transférées et une détection d'un manque éventuel d'intégrité des données transférées, - une phase de mise en état non opérationnel du contenant les données opérationnelles d'origine, suivie du passage à l'état opérationnel du microcircuit sécurisé contenant les données opérationnelles qui ont été transférées. Cette seconde phase comporte plusieurs variantes selon qu'elle s'effectue : - en mode synchrone, c'est à dire immédiatement à la suite de la phase de copie précédente ou - en mode asynchrone, c'est à dire après que la phase de sauvegarde des données se soit terminée et que les microcircuits sécurisés aient été déconnectés. Chaque microcircuit sécurisé doit préalablement être personnalisé avec une minimum les trois données suivantes: - un certificat de clé publique spécifique au microcircuit sécurisé, - une clé privée associée à ce certificat, - une clé publique permettant d’authentifier l’origine des messages émis par le serveur de migration de ce microcircuit sécurisé, et - en option, une adresse (par exemple une URL) permettant d'accéder à ce serveur de migration. Le procédé requiert l'existence d'informations de révocation des certificats de clé publique des microcircuits sécurisés et leur mise à disposition auprès des serveurs de migration. Revendication
2. 2. Procédé selon la revendication 1 caractérisé en ce que préalablement à une opération de sauvegarde ou de copie : - le microcircuit sécurisé destinataire des données à caractère opérationnel dispose d'une zone pour accueillir les données communiquées par le microcircuit sécurisé contenant les données d'origine et que cette zone doit être vide de données. Si cela n'est pas le cas, les données à caractère opérationnel présentes doivent être préalablement effacées. - le microcircuit sécurisé destinataire des données à caractère opérationnel dispose d'une donnée spécifique destinée à mémoriser une somme de contrôle cryptographique calculée sur la zone. - le microcircuit sécurisé destinataire des données à caractère opérationnel vérifie qu'il n'est pas dans un état opérationnel. Si cela n'est pas le cas, celui-ci doit être préalablement placé dans un état non opérationnel. Revendication
3. 3. Procédé selon la revendication 1 caractérisé en ce que chaque microcircuit sécurisé est rattaché à un serveur de migration et que le rôle de ce serveur de migration pour tous les microcircuits sécurisés supportant ce procédé est d'autoriser ou d'interdire la sauvegarde ou la copie des données à caractère opérationnel depuis un microcircuit sécurisé vers un autre microcircuit sécurisé. Revendication
4. 4. Procédé selon les revendications 1 et 3 caractérisé en ce que le serveur de migration auquel est rattaché un microcircuit sécurisé destinataire des données est en mesure de mémoriser des données permettant de savoir depuis quel(s) microcircuit(s) sécurisé(s) des données de ce microcircuit sécurisé destinataire des données, ont été transférées (à supposer que les opérations de transfert des données se soient terminées avec succès). Revendication
5. 5. Procédé selon les revendications 1 et 3, caractérisé en ce que le serveur de migration auquel est rattaché un microcircuit sécurisé origine des données est en mesure de mémoriser des données permettant de savoir vers quel(s) microcircuit(s) sécurisé(s) les données de ce microcircuit sécurisé origine des données, ont été transférées (à supposer que les opérations de transfert des données se soient terminées avec succès). Revendication
6. 6. Procédé selon les revendications 1,3 et 5, caractérisé en ce que le serveur de migration auquel est rattaché un microcircuit sécurisé origine des données est en mesure de savoir si l'un des microcircuits sécurisés vers lequel les données d'un microcircuit sécurisé origine des données ont été transférées a été autorisé à passer à un état opérationnel. Revendication
7. 7. Procédé selon les revendications 1, 2, 3, 4, 5 et 6, caractérisé en ce que la sauvegarde ou la copie des informations à caractère opérationnel contenues dans un premier microcircuit sécurisé (MCA) dans un autre microcircuit sécurisé (MCB) est effectuée au moyen des échanges protocolaires suivants: a) le dialogue débute par un échange de clés Diffie-Hellman signé qui est effectué entre le microcircuit sécurisé opérationnel (MCA) et le microcircuit sécurisé non opérationnel (MCB), - message 1 (M1): un nombre aléatoire n et un modulo p sont échangés entre le MCA et le MCB. - message 2 (M2): le nombre aléatoire n est élevé à la puissance secrète a par le MCA, réduit au modulo p, une signature numérique calculée sur les données précédentes à l'aide de la clé privée du MCA et le certificat de clé publique du MCA. - message 3 (M3) : le nombre aléatoire n est élevé à la puissance secrète b par le MCB, réduit au modulo p, une signature numérique calculée sur les données précédentes à l'aide de la clé lé privée du MCB et le certificat de clé publique du MCB. Le message 1 (M1) peut être envoyé en même temps que le message 2 (M2) ou bien le message 3 (M3) combiné au message 1 (M1) peut être envoyé avant le message 2 (M2). Selon le microcircuit sécurisé qui prend l'initiative du dialogue, l’ordre des messages 2 (M2) et 3 (M3) peut être inversé. La clé secrète k construite suite à l'échange de clé Diffie-Hellmann signé est le nombre aléatoire n est élevé à la puissance secrète ab, le tout réduit modulo p. b) chacun des serveurs ou des stations de travail supportant un microcircuit sécurisé extrait ensuite du microcircuit sécurisé l'adresse (URL) permettant d'accéder au serveur de migration du microcircuit sécurisé. c) le serveur ou la station de travail supportant le MCA envoie une demande de défi (DDA) au SMA et reçoit en retour une défi A (DA). Le défi A est ensuite relayé par le serveur ou la station de travail supportant le MCA auprès du serveur ou de la station de travail supportant le MCB. d) le serveur ou la station de travail supportant le MCB envoie une demande de défi (DDB) au SMB et reçoit en retour une défi B (DB). Le défi B est ensuite relayé par le serveur ou la station de travail supportant le MCB auprès du serveur ou de la station de travail supportant le MCA. e) le MCB génère un message 4 (M4) qui est envoyé par le serveur ou la station de travail supportant le MCB au serveur ou à la station de travail supportant le MCA puis qui est relayé auprès du SMA. Ce message 4 (M4) comprend les données suivantes: - un identifiant de message permettant de savoir qu’il s'agit d'un message de type 4, - le défi A obtenu auprès du SMA, - le message 2 (M2) que le MCB a reçu du MCA (qui contient le certificat de clé publique du MCA), - le certificat de clé publique du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée spécifique du MCB. Le certificat de clé publique du MCB peut aussi être placé après la signature numérique et dans ce cas il n'entre pas dans le calcul de la signature numérique. f) le serveur ou la station de travail supportant le MCA auprès du SMA le microcircuit sécurisé demande un défi au SMB qui fournit en retour un défi B qui est alors transmis au MCA. g) le MCA génère alors un message 5 (M5) qui est envoyé par le serveur ou la station de travail supportant le MCA au serveur ou à la station de travail supportant le MCB puis qui est relayé auprès du SMB. Ce message 5 (M5) comprend les données suivantes: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 5, - le défi obtenu auprès du SMB, - le message 3 (M3) que le MCA a reçu du MCB (qui contient le certificat de clé publique du MCB), - la clé publique permettant d’authentifier l’origine des messages émis par le SMA, - le certificat de clé publique du MCA, - en option, une URL permettant d'accéder au SMA, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée spécifique du MCA. Le certificat de clé publique du MCA et/ou l'URL permettant d'accéder au SMA peut aussi être placé après la signature numérique et dans ce cas n'entre pas dans le calcul de la signature numérique. Ces messages sont envoyés et reçus par le serveur ou la station de travail supportant le microcircuit sécurisé. Il est évident que l’ordre d'envoi des messages 4 (M4) et 5 (M5) peut être inversé. Chacun des messages est ensuite envoyé par le microcircuit sécurisé à son serveur de migration. h) le serveur SMA vérifie qu'il s'agit bien d'un message de type 4, que le défi qui est présent est identique à celui qu'il vient d'envoyer, que le certificat de clé publique du MCA est délivré par une autorité de certification reconnue, que ce certificat dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué. Il vérifie aussi que le message 2 (M2) qui est contenu dans ce message 4 (M4) est correctement signé par la clé publique contenue dans le certificat de clé publique du MCB, que le certificat de clé publique du MCB est un certificat délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte et qu'il n'est pas révoqué. Il vérifie aussi que l'ensemble des données est correctement signé à l'aide de la clé privée correspondant au certificat de clé publique du MCA. Le serveur SMA mémorise, suite la réception et à la vérification d'un message de type 4, le certificat de clé publique du MCA et un triplet de données constitué: - du certificat de clé publique du MCB, - de la clé publique permettant d’authentifier l’origine des messages émis par le SMB de rattachement du MCB, - d'un indicateur précisant que ce MCB est dans un état non opérationnel. La date de l'écriture ou de la modification de chaque triplet pourra être avantageusement ajoutée afin de pouvoir connaître la date de l'évènement. Ces données ne devront en aucun cas être supprimées avant la fin de validité du certificat de clé publique du MCA. Si un triplet est déjà présent, un nouveau triplet est ajouté à la suite du dernier triplet présent. i) le serveur SMB vérifie qu'il s'agit bien d'un message de type 5, que le défi qui est présent est identique à celui qu'il vient d'envoyer, que le certificat de clé publique du MCB est délivré par une autorité de certification reconnue, que ce certificat dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu’il n'est pas révoqué. Il vérifie aussi que le message 3 (M3) qui est contenu dans ce message 5 (M5) est correctement signé par la clé publique contenue dans le certificat de clé publique du MCA, que le certificat de clé publique du MCA est un certificat délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte et qu'il n'est pas révoqué. Il vérifie aussi que l'ensemble des données est correctement signé à l'aide de la clé privée correspondant au certificat de clé publique du MCB. Le SMB mémorise, suite la réception et à la vérification d'un message de type 5, le certificat de clé publique du MCB et un doublet ou un triplet de données constitué: - du certificat de clé publique du MCA, - de la clé publique permettant d’authentifier l’origine des messages émis par le serveur de migration du MCA (SMA), et éventuellement - de l'URL permettant d'accéder au serveur de migration du MCA (SMA). Ces données ne devront en aucun cas être supprimées avant la fin de validité du certificat de clé publique du MCB. La date de l'écriture de chaque doublet ou triplet pourra être avantageusement ajoutée afin de pouvoir connaître la date de l'évènement. Si un doublet ou un triplet est déjà présent, un nouveau doublet ou triplet est ajouté à la suite du dernier doublet ou triplet présent. L'ordre des vérifications des messages 4 (M4) et 5 (M5) peut être inversé. j) le serveur de migration SMA renvoie ensuite au serveur ou à la station de travail du microcircuit sécurisé MCA qui l'a contacté le message 6 (M6) suivant qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 6, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le transfert des données entre les microcircuits sécurisés, et - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA. La donnée permettant de détecter les rejeux est une donnée à caractère unique. Elle peut être communiquée au moyen d'un échange supplémentaire ou bien afin d'éviter cet échange supplémentaire, cela peut être une donnée unique déjà présente dans un message précédent. A titre d'exemple, une donnée permettant de détecter les rejeux dans le message 6 sera une donnée déjà présente dans le message 4 (M4), telle la valeur de la signature numérique effectuée à l'aide de la clé privée du MCA. Une convention devra être passée entre le microcircuit sécurisé et son serveur de migration pour déterminer quelle est la donnée permettant de détecter les rejeux. k) le serveur de migration SMB renvoie ensuite au serveur ou à la station de travail du microcircuit sécurisé MCB qui l'a contacté le message 7 (M7) suivant qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 7, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le transfert des données entre les microcircuits sécurisés, et - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB. La donnée permettant de détecter les rejeux est une donnée à caractère unique. Elle peut être communiquée au moyen d'un échange supplémentaire ou bien afin d'éviter cet échange supplémentaire, cela peut être une donnée unique déjà présente dans un message précédent. A titre d'exemple, une donnée permettant de détecter les rejeux dans le message 7 (M7) sera une donnée déjà présente dans le message 5 (M5), telle la valeur de la signature numérique effectuée à l'aide de la clé privée du MCA. Une convention devra être passée entre le microcircuit sécurisé et son serveur de migration pour déterminer quelle est la donnée permettant de détecter les rejeux. l) le MCA vérifie que le message qu'il a reçu est bien d'un message de type 6 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCA vérifie la signature numérique du message au moyen de la clé publique du SMA. Si la signature numérique est correcte, le MCA s'assure de la présence de l'indicateur d'accord pour le transfert des données entre les microcircuits sécurisés. m) le MCB vérifie que le message qu'il a reçu est bien d'un message de type 7 et que la valeur permettant de s’assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie la signature numérique du message au moyen de la clé publique du SMB. Si la signature numérique est correcte, le MCB s'assure de la présence de l'indicateur d'accord pour le transfert des données entre les microcircuits sécurisés. n) chaque microcircuit sécurisé annonce à l'autre lorsqu'il est prêt pour débuter le transfert. Le transfert des données est effectué au moyen de messages échangés directement entre les microcircuits sécurisés via les serveurs ou les stations de travail supportant les microcircuits sécurisés. o) les données opérationnelles du MCA sont copiées vers le MCB : - chiffrées au moyen de la clé k ou bien d'une clé dérivée de la clé k, et - scellées au moyen de la clé k ou bien d'une clé dérivée de la clé k. La clé secrète k est la clé qui a été construite durant l'échange de clé Diffie-Hellmann: c'est le nombre aléatoire n est élevé à la puissance secrète ab, le tout réduit modulo p. Les données reçues sont déchiffrées par le MCB avant d'être stockées dans le MCB. Afin de s'assurer qu'aucun message n'est supprimé durant le transfert, une somme de contrôle cryptographique est calculée au fur et à mesure des messages échangés. Le MCB vérifie que la valeur de cette somme cryptographique est égale à celle qu'il a lui même calculé. Si cela n'est pas le cas, l'ensemble des données déjà transférées est automatiquement effacé. Un nouveau transfert de données pourra cependant être tenté. Si cela est le cas, les données qui étaient présentes dans le MCA sont maintenant présentes dans le MCB. Afin de pouvoir s'assurer ultérieurement que le transfert des données a été intégralement effectué, le MCB calcule une somme de contrôle cryptographique sur les données transférées qui ont été mémorisées dans sa mémoire non volatile et mémorise cette somme de contrôle cryptographique. A ce stade, le MCB est toujours dans un état non opérationnel. Revendication
8. 8. Procédé selon les revendications 1, 2, 3, 4, 5, 6 et 7, caractérisé en ce que la mise en état opérationnel d'un microcircuit sécurisé MCB destinataire de données opérationnelles qui viennent juste d'être copiées est effectuée consécutivement à un dialogue avec le MCA où le SMA est directement contacté par le MCA de la manière suivante : a) les messages sont échangés immédiatement après la fin de la copie des données contenues dans le MCA au profit du MCB, sans mise hors tension du MCA ou du MCB, b) le MCA envoie au SMA un message 12 (M12) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 12, - une donnée permettant de détecter les rejeux, - le certificat de clé publique du MCA, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée spécifique du MCA. Le certificat de clé publique du MCA peut aussi être placé après la signature numérique et dans ce cas il n'entre pas dans le calcul de la signature numérique. Il n'est pas indispensable de chiffrer cet échange. La donnée permettant de détecter les rejeux sera une donnée à caractère unique présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire; par exemple, la signature numérique présente dans le message 10 (M10), c) le SMA que le message qu'il a reçu est bien d'un message de type 12 et que le message 12 (M12) contient effectivement le défi qu'il vient d'envoyer et que le message est correctement signé parle MCA. Dans l'entrée relative au MCA, il examine le triplet qui lui est attaché à la recherche du triplet qui contient la valeur du certificat de clé publique du MCB, d) le SMA modifie l'indicateur précisant si le microcircuit sécurisé MCB est ou non à l'état opérationnel et le positionne à l'état "opérationnel". Dans la réalité, le SMA anticipe ce changement d'état, car le MCB va seulement devenir opérationnel après la bonne réception du message 14 (M14). e) le SMA envoie au MCA un message 13 (M13) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 13, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour la mise en état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA. La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 12 (M12). f) le MCA vérifie: - que le message qu'il a reçu est bien d'un message de type 13, - que la donnée permettant de détecter les rejeux a la bonne valeur, - que l'indicateur d'accord pour le passage à l'état opérationnel du MCB est bien présent, - que la signature numérique est valide en utilisant la clé publique du SMA. Le MCA se positionne alors de lui-même à l'état non opérationnel et va autoriser le passage du MCB à l'état non opérationnel au moyen du message 14 (M14) qui est constitué de la manière suivante: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 14, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le passage à l'état opérationnel du MCB, - un scellement numérique calculé sur les données précédentes à l'aide de la clé secrète k ou bien d'une clé dérivée de la clé k. Il n'est pas indispensable de chiffrer cet échange. La donnée permettant de détecter les rejeux sera une donnée à caractère unique présente dans le dernier message précédent; par exemple, le scellement précédent. Le MCB vérifie que le message qu'il a reçu est bien d'un message de type 14 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que le message est correctement scellé à l'aide de la clé secrète k. Il vérifie la présence de l'indicateur d'accord pour le passage à l'état opérationnel et se place alors dans un état opérationnel. Revendication
9. 9. Procédé selon les revendications 1, 2, 3, 4, 5, 6 et 7, caractérisé en ce que la mise en état opérationnel d'un microcircuit sécurisé MCB destinataire de données opérationnelles qui viennent juste d'être copiées est effectuée avec un dialogue entre le MCA où le SMA est indirectement contacté par le MCA via le MCB et le SMB de la manière suivante : a) les messages sont échangés immédiatement après la copie des données contenues dans le MCA au profit du MCB, sans mise hors tension du MCA ou du MCB. b) suite à une commande, le MCA se place dans un état non opérationnel. c) le MCA envoie au MCB un message 16 (M16) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 16, - une donnée permettant de détecter les rejeux, - un indicateur de passage à l'état non opérationnel du MCA, - un scellement numérique calculé sur les données précédentes à l'aide de la clé secrète k ou bien d'une clé dérivée de la clé k. Il n'est pas indispensable de chiffrer cet échange. La donnée permettant de détecter les rejeux sera une donnée à caractère unique présente dans le message précédent; par exemple, le scellement précédent. d) le MCB vérifie que le message qu'il a reçu est bien un message de type 16 et que le message est correctement scellé à l'aide de la clé secrète k et que la donnée permettant de détecter l'absence de rejeu est bien présente. e) le serveur ou la station de travail supportant le MCB se connecte au SMB et demande un défi (challenge en anglais) au SMB. Le serveur ou la station de travail supportant le MCB communique ce défi B au MCB. Le MCB envoie au SMB un message 17 (M17) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 17, - le défi B, - le certificat de clé publique du MCB, une signature numérique effectuée sur les données précédentes à l'aide de la clé privée du MCB, f) le SMB vérifie: - que le message qu'il a reçu est bien d'un message de type 17, - que le défi correspond à celui qui vient d'être envoyé, - que le certificat de clé publique du MCB a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates” pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué, - que la signature numérique est valide à l'aide de la clé publique contenue dans le certificat de clé publique du MCB. Le SMB consulte les informations qu'il a mémorisées à la recherche de l'entrée contenant le certificat de clé publique du MCB. g) le SMB consulte les informations qu'il a mémorisées à la recherche d'une entrée contenant le certificat de clé publique du MCB. Si cette entrée est absente, le processus est interrompu. Si cette entrée est présente, le SMB récupère : - le certificat de clé publique d'un MCA, - l'URL permettant d'accéder au SMA de rattachement de ce MCA, - la clé publique permettant d’authentifier l’origine des messages émis par le SMA de rattachement de ce MCA. h) le SMB vérifie alors que le certificat de clé publique du MCA a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et qu'il n'est pas révoqué. Si toutes ces vérifications sont satisfaites alors le serveur SMB se connecte au SMA à l'aide de l'URL permettant d'accéder au SMA de rattachement de ce MCA et demande un défi (challenge en anglais) au SMA. i) Le SMB envoie au SMA un message 18 (M18) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 18, - le défi A généré par le SMA, - le certificat de clé publique du MCA, - la clé publique du SMB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB. j) Le SMA vérifie que le message qu'il a reçu est bien d’un message de type 18 et que le défi A contenu dans le message 18 (M18) est identique au défi qu’il avait envoyé. Si cela n'est pas le cas, le processus est interrompu. Le SMA extrait du message 18 le certificat de clé publique du MCA et s'assure que le certificat de clé publique du MCA a bien déjà été mémorisé. Si cela n'est pas le cas, le processus est interrompu. Le SMA examine tous les triplets rattachés au certificat du MCA. Si un triplet contient un indicateur précisant qu'un microcircuit sécurisé est déjà passé dans un état opérationnel, le processus est interrompu. Le SMA récupère les données associées au certificat du MCA, à savoir un ou plusieurs triplets, chaque triplet étant composé : - du certificat d’un MCB, - d'un indicateur précisant si ce MCB est ou non opérationnel, - de la clé publique permettant d’authentifier l’origine des messages émis par le SMB de ce MCB. Il recherche le triplet contenant le certificat de ce MCB. Si ce certificat ne figure dans aucun triplet, le processus est interrompu. Le SMA vérifie la signature numérique du message 18 (M18) à l'aide de la clé publique du SMB contenue dans cette entrée. Si la vérification n'est pas concluante, le processus est interrompu Dans le triplet qui contient la valeur du certificat de clé publique du MCB, le SMA modifie l'indicateur précisant si le microcircuit sécurisé est ou non opérationnel pour le positionner à un état opérationnel. Dans la réalité, le SMA anticipe ce changement d'état, car le MCB va seulement devenir opérationnel après la bonne réception par le MCB du message 20 (M20). k) le SMA envoie au SMB un message 19 (M19) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 19, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour la mise en état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA. La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 18 (M18). l) le SMB vérifie que le message qu'il a reçu est bien d'un message de type 19 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que la signature numérique est exacte. m) le SMB envoie au MCB un message 20 (M20) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 20, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le passage à l'état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB. La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 17 (M17). n) le MCB vérifie que le message qu'il a reçu est bien d'un message de type 20 et que la valeur permettant de s'assurer que le message n'est pas un rejeu est bien présente. Le MCB vérifie que la signature numérique du message 20 (M20) est exacte. Si cela n'est pas le cas, le processus est interrompu. Si cela est le cas, le MCB peut alors basculer dans un état opérationnel. Revendication
10. 10. Procédé selon les revendications 1, 2, 3, 4, 5, 6 et 7, caractérisé en ce que la mise en état opérationnel du microcircuit sécurisé MCB destinataire de données opérationnelles est effectuée en mode asynchrone sans dialogue avec le MCA de la manière suivante : a) le MCB vérifie qu'il contient un transfert complet de données sauvegardées en recalculant une somme de contrôle cryptographique sur les données transférées qu'il a stockées dans sa mémoire et en la comparant avec la somme de contrôle cryptographique qui a été mémorisée. Si le résultat du calcul est différent, alors le processus est interrompu. b) le serveur ou la station de travail supportant le MCB se connecte au SMB et demande un défi (challenge en anglais) au SMB au moyen du message DDB. Le serveur ou la station de travail supportant le MCB communique ce défi B au MCB au moyen du message DB. c) le MCB génère à l'attention du serveur de migration SMB un message 21 (M21) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 21, - le défi B, - le certificat de clé publique du MCB, - une signature numérique effectuée sur les données précédentes à l'aide de la clé privée du MCB, d) le SMB vérifie: que le message qu'il a reçu est bien d'un message de type 21, - que le défi B correspond à celui qui vient d'être envoyé, - que le certificat de clé publique du MCB a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et au moyen des messages 22 (M22) et 23 (M23) qu'il n'est pas révoqué, - que le MCB est dans un état non opérationnel, - à l'aide de la clé publique contenue dans le certificat de clé publique du MCB que la signature numérique est valide. Si l'une de ces conditions n'est pas vérifiée, le processus est interrompu. e) le SMB consulte les informations qu'il a mémorisées à la recherche d'une entrée contenant le certificat de clé publique du MCB. Si cette entrée est absente, le processus est interrompu. Si cette entrée est présente, le SMB s'assure au moyen des messages 22 (M22) et 23 (M23) que le certificat du MCB n'est pas révoqué. Si cela n'est pas le cas, le processus est interrompu. Le SMB récupère le dernier triplet rattaché au certificat du MCB. Celui-ci contient: - le certificat de clé publique d'un MCA, - la clé publique permettant d’authentifier l’origine des messages émis par le SMA de rattachement de ce MCA, et éventuellement, - l'URL permettant d'accéder au SMA de rattachement de ce MCA. f) le SMB vérifie alors que le certificat de clé publique du MCA a été délivré par une autorité de certification reconnue, qu'il dispose des "propriétés adéquates" pour la mise en œuvre de ce procédé vis à vis des données opérationnelles qu'il supporte, qu'il est dans sa période de validité et au moyen des messages 22 (M22) et 23 (M23) qu'il est a été révoqué à la demande de son utilisateur légitime. Il vérifie aussi que le certificat de clé publique du MCB n'est pas révoqué. Si ces vérifications ne sont pas effectuées avec succès alors le processus est interrompu. Si toutes ces vérifications sont satisfaites alors le serveur SMB contacte le SMA à l'aide de l'URL permettant d’accéder au SMA de rattachement de ce MCA. g) le SMB demande un défi (challenge en anglais) DA au SMA. Le SMA communique ce défi A (DA) au SMB. Le SMB génère pour le SMA un message 24 (M24) qui contient: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 24, - le défi A généré par le SMA, - le certificat de clé publique du MCA, - la clé publique du SMB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB. h) Le SMA vérifie que le message qu'il a reçu est bien d'un message de type 24 et que le défi contenu dans le message 24 (M24) est identique au défi qu'il avait envoyé. Si cela n'est pas le cas, le processus est interrompu. Le SMA consulte les informations qu'il a mémorisées à la recherche d'une entrée contenant le certificat de clé publique du MCA. Si cette entrée est absente, le processus est interrompu. Si cette entrée est présente, il s'assure au moyen des messages 25 (M25) et 26 (M26) que le certificat du MCA a bien été révoqué et que celui du MCB n'est pas révoqué. Si cela n'est pas le cas, le processus est interrompu. Le SMA examine tous les triplets rattachés au certificat du MCA. Si l'un des triplets contient un indicateur précisant qu'un microcircuit sécurisé est déjà passé dans un état opérationnel, le processus est interrompu. Le SMA recherche le triplet contenant le certificat de ce MCB. Si ce certificat ne figure dans aucun triplet, le processus est interrompu. Si le certificat de ce MCB est trouvé, le SMA vérifie que la clé publique du SMB figurant dans le message 24 (M24) est bien identique à la clé publique figurant dans le triplet. Si cela n'est pas le cas, le processus est interrompu. Le SMA vérifie que l'exactitude du calcul de la signature numérique à l'aide de la clé publique du SMB. Si cela n'est pas le cas, le processus est interrompu. Dans le triplet qui contient la valeur du certificat de clé publique du MCB, le SMA modifie l'indicateur précisant si le microcircuit sécurisé est ou non opérationnel et le positionne à l'état opérationnel. Dans la réalité, le SMA anticipe ce changement d'état, car le MCB va seulement devenir opérationnel après la bonne réception du message 28 (M28). i) Le SMA envoie alors un message 27 (M27) au SMB constitué des données suivantes: un identifiant de message permettant de savoir qu'il s'agit d'un message de type 27, une donnée permettant de détecter les rejeux, un indicateur d'accord pour la mise en état opérationnel du MCB, une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMA. La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 24 (M24). j) le SMB vérifie que le message qu'il a reçu est bien d'un message de type 27 et en utilisant la valeur pour détecter les rejeux vérifie la signature numérique du message à l'aide de la clé publique du SMA. Si l'une des vérifications échoue, le processus est abandonné. Le SMB génère à l'attention du MCB un message 28 (M28) constitué des données suivantes: - un identifiant de message permettant de savoir qu'il s'agit d'un message de type 28, - une donnée permettant de détecter les rejeux, - un indicateur d'accord pour le passage à l'état opérationnel du MCB, - une signature numérique calculée sur les données précédentes à l'aide de la clé privée du SMB. La donnée permettant de détecter les rejeux sera une donnée à caractère unique déjà présente dans le message précédent ou bien une donnée envoyée spécifiquement à cet effet dans un message supplémentaire. A titre d'exemple, la signature numérique présente dans le message 21 (M21 ). k) le MCB vérifie que le message qu'il a reçu est bien d'un message de type 28. Si cela n'est pas le cas, le processus est interrompu. Le MCB vérifie à l'aide de la clé publique du SMB qu'en utilisant la valeur pour détecter les rejeux, la signature numérique du message 28 (M28) est exacte. Si cela n'est pas le cas, le processus est interrompu. Si cela est le cas, alors le MCB bascule dans un état opérationnel. Revendication
11. 11. Procédé selon les revendications 1,2, 3, 4, 6 et 7, caractérisé en ce que, si seul le processus de passage à l'état opérationnel en mode synchrone est supporté par les microcircuits sécurisés destinataires des données, alors il n'est pas indispensable d'informer le SMA du passage à l'état opérationnel du MCB et les messages 12 (M12) et 13 (M13) peuvent alors être omis. Dans ce cas, un ordre est adressé au MCA pour qu'il se place à l'état non opérationnel et le MCA autorise alors le passage du MCB à l'état opérationnel au moyen de l'envoi message 14 (M14).