Brevet FR3049083A1 (20170922)
REVENDICATIONS1. Procédé permettant de dupliquer les données 5 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 10 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: 15 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 20 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 25 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. 3049083 37 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.\n<CLM>\1\tProcédé selon la revendication 1 caractérisé en ce que 20 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 25 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. 3049083 38 - 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.\n<CLM>\1\tProcé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 10 sécurisé.\n<CLM>\1\tProcé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 15 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).\n<CLM>\1\tProcé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).\n<CLM>\1\tProcé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. 3049083 39\n<CLM>\1\tProcé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 5 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), 10 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 15 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 20 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 25 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 30 modulo p. 3049083 40 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é. 5 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 10 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 15 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, 20 - 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. 25 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 30 B qui est alors transmis au MCA. 3049083 41 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: 5 - 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), 10 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 15 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 20 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 25 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 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é. 3049083 42 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 5 "propriétés adéquates" pour la mise en oeuvre 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 10 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, 15 - 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 connaitre la date de l'évènement. Ces données ne devront en aucun cas être supprimées avant la fin de 20 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 25 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 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é. 3049083 43 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 5 "propriétés adéquates" pour la mise en oeuvre 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 10 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 15 - 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 connaitre la date de l'évènement. 20 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) 25 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, 3049083 44 - 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. 5 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 10 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. 15 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, 20 - 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. 25 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 30 message 7 (M7) sera une donnée déjà présente dans le message 5 (M5), 3049083 45 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 5 détecter les rejeux. I) 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. 10 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 15 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 20 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 25 - scellées au moyen de la clé k ou bien d'une clé dérivée de la clé k. 3049083 46 La clé secrète k est la clé qui a été construite durant l'échange de clé DiffieHellmann: 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 5 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 à 10 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. 15 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. 20 A ce stade, le MCB est toujours dans un état non opérationnel. 3049083 47\n<CLM>\1\tProcé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 5 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, 10 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, 15 - 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. 20 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), 25 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, 3049083 48 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). 5 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, 10 - 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 15 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, 20 - 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. 3049083 49 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 5 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 à 10 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. 15 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 à 20 l'état opérationnel et se place alors dans un état opérationnel. 3049083 50\n<CLM>\1\tProcé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 5 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. 10 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, 15 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 20 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 25 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. 3049083 51 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, 5 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, 10 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é et qu'il n'est pas 15 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. 20 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. 3049083 52 Si cette entrée est présente, le SMB récupère : - le certificat de clé publique d'un MCA, - I'URL permettant d'accéder au SMA de rattachement de ce MCA, - la clé publique permettant d'authentifier l'origine des messages 5 é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 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 10 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. 15 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, 20 - 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 25 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. 304 90 83 53 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 5 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, 10 - 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 15 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 20 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: 25 - 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, 3049083 54 - 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 5 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). I) 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 10 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, 15 - 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 20 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 25 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. 30 3049083 55\n<CLM>\1\tProcé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 5 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 10 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. 15 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, 20 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, 3049083 56 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é, 5 - 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é et au moyen des messages 22 (M22) et 23 (M23) qu'il n'est pas 10 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. 15 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 20 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 25 par le SMA de rattachement de ce MCA, et éventuellement, - l'URL permettant d'accéder au SMA de rattachement de ce MCA. 3049083 57 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 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 au 5 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 10 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: 15 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, 20 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 25 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. 3049083 58 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. 5 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 10 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 15 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 20 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 25 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. 3049083 59 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 5 (M24). D 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é. 10 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, 15 - 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 20 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 25\n<CLM>\1\tSi 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. 30 3049083 60\n<CLM>\1\tProcé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 5 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).