Brevet FR3148102A1 — publié le 20241025

La présente invention présente un procédé pour une sauvegarde et une restauration sécurisées de données dans un dispositif avec un traitement de données spécifique qui implémente les normes BIP39, BIP32 & BIP44 ou des implémentations similaires pour initier la génération des clés de sécurisation des opérations de la sauvegarde/restauration de données. Il s'agit des données de plusieurs applications résidant dans l'appareil. La sauvegarde d'un appareil précédent est nécessaire pour permettre sa restauration dans un nouvel appareil Une méthode sécurisée de sauvegarde et de restauration des données dans un appareil La présente invention présente un procédé pour une sauvegarde et une restauration sécurisées de données dans un dispositif avec un traitement de données spécifique qui implémente les normes BIP39, BIP32 & BIP44 ou des implémentations similaires pour initier la génération des clés de sécurisation des opérations de la sauvegarde/restauration de données. Il s'agit des données de plusieurs applications résidant dans l'appareil. La sauvegarde d'un appareil précédent est nécessaire pour permettre sa restauration dans un nouvel appareil. Les normes BIP39, BIP32 et BIP44 proposent une méthode pour restaurer plusieurs clés de différentes applications qui gèrent des clés (par exemple, les portefeuilles (Wallets)) au sein d'un appareil. Cette solution permet de restituer toutes ces clés uniquement en mémorisant une graine initiale qui est représentée par une liste de mots (par exemple, 24 mots). Ces mots doivent être conservées précieusement par l'utilisateur et utilisées uniquement dans le cadre d'une restauration dans un nouvel appareil. Cette solution présente un avantage important, qui est d'éviter de déplacer les clés privées à l'extérieur de l'appareil. Elle élimine complètement le besoin d'une sauvegarde et le remplace par le fait de simplement mémoriser la liste de mots initiale. Elle élimine également le besoin d'une chaîne de confiance hiérarchique (par exemple, PKI) comme les certificats numériques X.509 (RFC 5280). La présente invention propose d'étendre cette solution pour gérer de manière sécurisée la sauvegarde/restauration des données internes au sein du dispositif. Il peut s'agir de données d'applications, de données de configuration ou de tout autre type de données qui doivent être restaurées lors de la migration vers un nouvel appareil qui doit contenir les mêmes données que le premier. L'appareil peut contenir deux processeurs: Le MCU (Microcontroller Unit) qui gère la communication avec les périphériques externes et contient les données légèrement sécurisées (LSD) liées aux applications et leurs métadonnées (MD). Au moins un élément sécurisé (Secure Element ) qui gère les secrets et les applications associées et contient des données hautement sécurisées (HSD). Le HSD peut être crypté et exporté vers le MCU, puis ils sont appelés données sécurisées exportées (ESD). Les ESD peuvent également être importées et décryptées dans l’élément sécurisé. Les unités de traitement précitées peuvent être: dans un circuit intégré unique (par exemple, System On Chip) dans lequel l'élément sécurisé est intégré. dans deux circuits intégrés différents communiquant via une interface de communication. Plusieurs options sont possibles selon les exigences de sécurité des applications : Nous pouvons avoir un MCU exposant un niveau de sécurité conforme. Nous pouvons avoir un MCU intégrant un élément sécurisé. Nous pouvons avoir un élément sécurisé intégrant les fonctionnalités d'un MCU. Un élément sécurisé (Secure Element) peut être : Une puce indépendante amovible ou soudée sur une carte mère d'un appareil électronique plus gros. Un élément sécurisé/protégé contre des altérations(Tamper-Resistant) intégré dans un System On Chip (SoC), composé de matériel et de logiciels de bas niveau offrant une résistance contre les attaques logiques et physiques. La plate-forme matérielle de l'élément sécurisé comprend : Au moins un microprocesseur sécurisé avec une mémoire volatile et non volatile, souvent un crypto-processeur et un circuit matériel dédié à la sécurité. La plate-forme matérielle est protégé contre des altérations en offrant une protection contre les attaques par canal latéral (par exemple, l'analyse de puissance différentielle, les attaques différentielles par défaut et les attaques par défaut (invasives ou non invasives). Fonctions de sécurité offrant : Facilités et protection pour la gestion des clés telles que KDF (Key Derivation Function). Générateurs de nombres aléatoires conformes aux exigences de sécurité. Les caractéristiques et les propriétés des éléments sécurisés (Secure Elements) sont bien répertoriées dans Global Platform Virtual Primary Platform (connu comme, VPP). Le but de l'invention est de sauvegarder/restaurer LSD et ESD vers/depuis n'importe quel moyen de stockage en utilisant un système de clés tel que défini dans les normes BIP. Les normes BIP39, BIP32 & BIP44 définissent le concept de portefeuille (Wallet) qui est une application gérant des clés telles que le portefeuille Bitcoin, le portefeuille Ethereum et d'autres portefeuilles de crypto-monnaie. Nous devons d'abord présenter un résumé des normes BIP associées avant de décrire l'invention elle-même. La norme BIP39 décrit la mise en œuvre d'un code mnémonique ou d'une phrase mnémonique, qui est un groupe de mots standards faciles à retenir, pour la génération d'une graine initiale pour diversifier les clés déterministes (voir les références aux normes BIP ci-dessous). Il se compose de deux parties : générer le mnémonique puis le convertir en une graine binaire. Un code ou une phrase mnémonique est supérieur pour l'interaction humaine par rapport à la gestion des représentations binaires ou hexadécimales brutes d'une graine initiale d’un portefeuille (Wallet). La phrase peut être écrite sur papier ou parlée au téléphone. C'est un moyen de transporter une graine aléatoire généré par ordinateur avec une transcription lisible par l'homme. Les normes BIP32 et BIP44 décrivent les portefeuilles Déterministes Hiérarchiques (c'est-à-dire les "Wallets HD"). Les portefeuilles HD peuvent générer un arbre de nœuds à partir d'une graine initiale (comme dans BIP39) de manière déterministe où certains nœuds sont des paires de clés. La Blockchain est une technologie qui permet de suivre un ensemble de transactions de manière décentralisée, sécurisée et transparente. Les chemins des nœuds peuvent être définis comme dans la norme BIP44 qui attribue des préfixes de chemins pour les portefeuilles connus de différentes blockchains (par exemple, Bitcoin, Ethereum, EBSI (European Blockchain Services Infrastructure) etc.). Ces normes permettent la génération de nombreuses clés pour différents portefeuilles des blockchains. En fournissant la graine initiale (représentée par des mots mnémoniques ou d'autres moyens), le même arbre de clés peut être généré dans un nouveau dispositif. Dans cette invention, nous utilisons la structure de nœud BIP32 pour allouer de nouveaux chemins pour les opérations de sauvegarde/restauration. Cela signifie qu’on bénéficie des fonctionnalités associées à cette norme (par exemple, la génération déterministe de paires de clés). L'arbre de clés dérivé étant déterministe, nous ne pouvons pas l'utiliser directement pour les opérations de sauvegarde/restauration. La clé de chiffrement/déchiffrement doit être éphémère pour chaque sauvegarde. illustre un exemple d'arbre de nœuds tel que défini dans la norme BIP32. Une sauvegarde/restauration sécurisée doit prendre en charge les propriétés de sécurité suivantes : L'intégrité et la confidentialité des données. Le Perfect Forward Secrecy (PFS) de données, c’est-à-dire des moyens cryptographiques permettant de ne pas de reconstruire des secrets passés à partir de secrets futures L'anti-rejeu des données qui peut être conditionnelle. L'authenticité des données comme preuve d'origine. Appliquer des règles pour la sauvegarde de la vie privée dès la conception (connu comme, Global Data Procedure Regulation) dans la procédure de randomisation des données résultantes. La procédure de sauvegarde/restauration sécurisée peut être appliquée à une seule application ou à un groupe d'applications. Dans la procédure de sauvegarde/restauration sécurisée nous définissons les notations suivantes : Y = encrypt[K](X) : fonction cryptant les données en clair X en utilisant une clé du jeu de clés K. les données cryptées sont Y. La fonction de cryptage peut être basée sur le chiffrement par bloc GCM tel que défini dans le SP 800-38D Recommandations NIST ou eGCM telles que définies dans la spécification OFL de Global Platform ou toute autre méthode de chiffrement prenant en charge les exigences de sécurité. X = déchiffrer[K](Y) : fonction déchiffrant les données chiffrées Y en utilisant une clé du jeu de clés K. les données en clair sont X. La fonction de déchiffrement peut être basée sur le chiffrement par bloc GCM tel que défini dans le SP 800-38D Recommandations NIST ou eGCM telles que définies dans la spécification OFL de Global Platform ou toute autre méthode de chiffrement prenant en charge les exigences de sécurité. I = compute_icheck[K](X) : fonction générant le code de contrôle I en utilisant une clé du jeu de clés K sur les données en clair X. le code de contrôle est I. La fonction générant le code de contrôle peut être basée sur un HMAC comme défini dans la norme FIPS 198-1 ou intégré dans la fonction de chiffrement comme eGCM. verify_icheck[K](X, I) : Fonction vérifiant le code de contrôle I en utilisant une clé du jeu de clés K sur les données claires X et le code de contrôle attendu I. La fonction échoue si le code de contrôle attendu est différent du code calculé. S = sign[K](A) : Fonction générant la signature des données A en utilisant la clé privée K. La signature est S. La fonction générant la signature peut implémenter la norme BSI TR-03111. vérifier[K](S, A) : Fonction vérifiant la signature S des données A en utilisant la clé publique K. La vérification échoue si la signature calculée est erronée. La fonction vérifiant la signature peut mettre en œuvre la norme BSI TR-03111. C = generate_container(X, Y,…) : Fonction générant un conteneur C contenant une collection de données (X, Y, …) selon une structure contextuelle. La génération de conteneur peut s'appuyer sur des standards comme les règles d'encodage ASN.1 (ISO/IEC 8824-1:2021), CBOR ou JSON. K = dérive(ShS, SI) : Fonction générant une clé ou un ensemble de clés en fonction d'un secret partagé (ShS) et d'une Information partagée (SI). Comme exemple de KDF (Key Derivation Function), nous pouvons utiliser celle définie dans : BSI Technical Guideline TR-03111: Elliptic Curve Cryptography. Version 2.0. BIP32 standard. Dans la procédure de sauvegarde/restauration sécurisée, nous définissons les termes suivants : Matériel de clé : structure de données contenant toutes les informations définissant une clé (par exemple, domaine ECC, type, taille). La séquence d'invocation de la procédure de sauvegarde sécurisée est la suivante dans laquelle chaque numéro de séquence correspond au numéro de séquence de : L'utilisateur via l'interface utilisateur de l'équipement demande une sauvegarde sécurisée sur l'appareil. L'application de sauvegarde sécurisée dans l'appareil demande le consentement de l'utilisateur (par exemple, vérification des empreintes digitales, vérification du code PIN, etc.) pour générer le conteneur de sauvegarde sécurisée (SBK). L'utilisateur accepte la génération de sauvegarde sécurisée. L'application de sauvegarde vérifie le consentement de l'utilisateur. L'application de sauvegarde (Backup Application) sécurisée génère le conteneur de sauvegarde sécurisée (SBK). Le conteneur SBK est envoyé à l'application de sauvegarde au sein de l'équipement de l'utilisateur (User’s Equipment). L'application de sauvegarde encapsule le conteneur SBK dans un conteneur XSBK pour le support de stockage sélectionné. La vérification du consentement de l'utilisateur a échoué. L'utilisateur est averti. La vérification du consentement de l'utilisateur a échoué. L'application de sauvegarde de l'équipement de l'utilisateur est notifiée. L'appareil peut générer un UUID (Universal Unique Identifier) tel que défini dans la RFC 4122 pour identifier le SBK dans le support de stockage. Ledit UUID peut jouer le rôle de pseudonyme pour rechercher le SBK au sein d'un serveur de découverte faisant office de référentiel de SBK anonymes (support RGPD). L'appareil peut générer un URI (Universal Resource Identifier) pour identifier le SBK dans le support de stockage. illustre la séquence liée à la procédure de sauvegarde sécurisée de données illustre les détails fonctionnels de la procédure de sauvegarde sécurisée de données La procédure de sauvegarde sécurisée est la suivante : Générer une graine initiale (Seed) telle que définie dans BIP39 ou en utilisant un autre moyen. Calculer une clé privée déterministe (DPK) à partir de la graine dans le nœud d'application de restauration/sauvegarde tel que défini dans BIP32. Calculer un nombre aléatoire R. Définissez un numéro de version V comme numéro de version actuel reflétant une empreinte ESD/LSD/MD. Il suppose que le numéro de version est monotone et est modifié pour chaque sauvegarde sécurisée. Générer un conteneur H contenant au moins : R, V. Dérivez deux clés IM et EM en utilisant une fonction de dérivation avec les chemins H, DPK et IM, EM comme paramètres. Dérivez une clé privée (KAUTp) en utilisant une fonction de dérivation avec H, DPK dans le nœud d'application de restauration/sauvegarde/authentification comme défini dans BIP32. Collecter les métadonnées (MD) liées à chaque ESD et LSD comme la longueur, l'identification, la version, etc. Générer un conteneur CDC contenant : ESD, LSD et MD Calculer un contrôle d'intégrité (IDC) de CDC en utilisant les données définissant la clé IM. Générer EDC à partir du cryptage de CDC à l'aide de la clé EM. Générer un conteneur B contenant H, EDC et IDC. Générer la signature SIG de B en utilisant la clé privée KAUTp. Générer un conteneur SBK contenant SIG et B La séquence d'invocation de restauration sécurisée est la suivante dans laquelle chaque numéro de séquence correspond au numéro de séquence de : L'application de restauration (Restore Application) collecte le conteneur XSBK à partir du support de stockage. L'application de restauration extrait le conteneur SBK de XSBK. L'application de restauration transfère le SBK à l'application de restauration de l'appareil. Si l'appareil est nouveau, l'utilisateur est invité à introduire la graine initiale. L'utilisateur introduit ses données pour la génération initiale de semences dans l'appareil. L'appareil invite l'utilisateur à donner son consentement. L'utilisateur accepte la procédure de restauration sécurisée. L'application de restauration dans l'appareil vérifie le consentement de l'utilisateur. La vérification du consentement de l'utilisateur est réussie. L'application de restauration de l'appareil invoque la procédure de restauration sécurisée. L'utilisateur est informé de la réussite de la procédure de restauration sécurisée. L'application de restauration est informée de la réussite de la procédure de restauration sécurisée. L'utilisateur est averti de l'échec d'une procédure de restauration sécurisée. L'application de restauration est informée de l'échec d'une procédure de restauration sécurisée. L'utilisateur est informé de l'échec de la vérification du consentement de l'utilisateur. L'application de restauration est informée de l'échec de la vérification du consentement d'un utilisateur. illustre la séquence d'invocation de restauration sécurisée de données illustre la procédure de restauration sécurisée. La procédure de restauration sécurisée est détaillée comme suit : Générer une graine initiale telle que définie dans BIP39 ou en utilisant un autre moyen. Calculer une clé privée déterministe (PDK) à partir de la graine dans le nœud d'application de restauration/sauvegarde tel que défini dans BIP32. Dériver une clé privée (KAUTp) dans le nœud d'application de restauration/sauvegarde/authentification tel que défini dans BIP32 et calculer sa clé publique (KAUTpu) Extraire H, EDC, IDC et SIG de B Vérifiez SIG en utilisant la clé publique KAUTpu et B Extraire la version V de H Vérifiez que V est supérieur (ou inférieur selon le sens de la monotonie (positive/négative) de la version V) à la version V actuelle de l'appareil. Dérivez deux clés IM et EM de H et DPK Déchiffrer EDC en utilisant la clé EM Vérifiez IDC en utilisant le matériel de clé IM et les données en clair d'EDC. Installez le MD, l'ESD et le LSD sur l'appareil. Pour illustrer le besoin et les avantages de cette invention, nous décrivons un dispositif qui peut héberger plusieurs applications qui peuvent être distribuées entre un élément sécurisé (Secure Element) et une MCU pour répondre à différents niveaux de sécurité. Chaque application est utilisée à des fins différentes de manière indépendante et isolée. Parmi toutes ces applications, l'appareil héberge deux applications comme : L'application de sauvegarde sécurisée qui peut sauvegarder toutes les autres applications L'application de restauration sécurisée qui peut restaurer toutes les autres applications à partir d'une sauvegarde sécurisée. Dans cet appareil, nous pouvons héberger plusieurs portefeuilles blockchain (Wallets), par exemple un portefeuille Bitcoin, un portefeuille Ethereum, et éventuellement d'autres portefeuilles supplémentaires de différentes blockchains. Les applications de portefeuille s'appuient sur les normes BIP pour la génération de clés internes et n'ont généralement pas besoin de stocker des données supplémentaires. Les clés des portefeuilles sont restaurées directement en fournissant la graine initiale (par exemple, représentée par des mots mnémoniques). Une autre catégorie d'applications nécessite la gestion des données de l'application et peut également utiliser d'autres mécanismes de génération de clés internes. Nous prendrons comme exemple l'application FIDO2 bien connue et standardisée qui fournit un moyen d'authentifier les utilisateurs sans mot de passe en toute sécurité tout en préservant la vie privée. Les services en ligne (par exemple, les sites Web) peuvent utiliser cette norme en implémentant le côté serveur du protocole FIDO2. Ce protocole et ces applications remplacent le nom d'utilisateur et les mots de passe en utilisant la cryptographie à clé publique d'une manière pratique qui préserve également la vie privée de l'utilisateur. L'application FIDO2 dans l'appareil générera des clés d'authentification pour chaque site auquel l'utilisateur souhaite se connecter (en remplacement des mots de passe) en suivant la norme FIDO2. Pour chaque clé, l'application doit stocker des données associées pour le contexte d'échange entre l'application FIDO2 dans l’appareil et le site distant. En outre, des données supplémentaires peuvent devoir être enregistrées pour chaque site Web pour lequel des clés ont été générées (par exemple, l'URL du site Web, le pseudonyme de l'utilisateur, etc.). Toutes ces données dépendent du site Web et ne peuvent pas être régénérées à partir de la graine initiale. Il est donc clair qu'ils doivent être sauvegardés si nous voulons migrer vers un nouvel appareil et retrouver la même application FIDO2 avec les mêmes données et clés qui ont été générées pour les différents sites Web auxquels l'utilisateur s'est abonné. Considérons, à titre d'exemple, que notre dispositif a trois applications : Un portefeuille Bitcoin, un portefeuille Ethereum et, une application FIDO2. Pour les deux portefeuilles, nous n'avons pas de données d'application internes à sauvegarder car leurs clés seront restaurées lors de l'introduction de la graine initiale (par exemple, générée à partir de mots mnémoniques) dans un nouvel appareil et les données associées peuvent être récupérées à partir de la blockchain pertinente. Pour l'application FIDO2, cependant, nous avons besoin d'une sauvegarde des données d'application internes associées à chaque site Web pour lequel l'utilisateur est passé par un processus d'enregistrement qui a généré les clés d'authentification qui y sont associés. Tout équipement tel qu'un téléphone mobile ou un ordinateur de bureau peut communiquer avec l'appareil à l'aide d'une interface sans fil fiable dédiée telle que Bluetooth, WIFI et NFC ou d'une interface filaire telle que USB, Ethernet, etc. Cet équipement héberge une application qui peut déclencher ou être déclenché vers/depuis le dispositif pour transférer des données de sauvegarde sécurisées vers/depuis un support de stockage. Le support de stockage est sélectionné soit par l'utilisateur lors de l'utilisation de l'application de l'équipement, soit par l'appareil. L'équipement ci-dessus n'a pas besoin d'être sécurisé. La procédure de sauvegarde/restauration sécurisée offre les avantages suivants : Les clés générées ne sont connues que de l'élément exposant le niveau de sécurité le plus élevé (par exemple, l'élément sécurisé dans l'appareil). Les données de la sauvegarde sécurisée (Secure Backup) peuvent être stockées en toute sécurité sur n'importe quel support de stockage externe. Tout nouveau appareil authentique conforme à la procédure de sauvegarde sécurisée peut être restauré (par exemple, la reprise après sinistre ou clonage) Lorsque l'utilisateur souhaite sauvegarder un appareil, il doit suivre les procédures simples ci-dessous : Invoquer l'application de sauvegarde sur l'équipement de l'utilisateur qui : Établie une communication avec l'appareil. Défini l'emplacement du support de stockage. L'appareil invoquera la procédure de sauvegarde sécurisée et enverra les données de sauvegarde sécurisées à l'application de sauvegarde de l'équipement. L'application de sauvegarde de l'équipement stocke les données de sauvegarde sécurisées sur le support de stockage sélectionné. Lorsque l'utilisateur souhaite migrer vers un nouvel appareil, il doit suivre les procédures simples ci-dessous : Introduire la graine (représentée par des mots mnémoniques ou par d'autres moyens) dans le nouvel appareil via une interface utilisateur dédiée sur l'appareil lui-même. Invoquer l'application de restauration sur l'équipement de l'utilisateur qui : établie une communication avec l'appareil. défini l'emplacement des données de sauvegarde sécurisées l'envoyer à l'appareil qui invoquera la procédure de restauration sécurisée. Après cette procédure de restauration, le nouvel appareil aura les mêmes clés et données pour toutes ses applications. Un procédé de clonage de données d'appareil qui utilise la génération d'une ou plusieurs clés dérivées à partir d'une graine unique sans support de chaîne de confiance hiérarchique, qui est introduite dans l'appareil après son déploiement sur le terrain, et qui implémente les normes BIP telles que BIP32 & BIP44 ou dérivation de clé et structure de données hiérarchique similaires ; ces clés dérivées déterministes sont utilisées pour la preuve d'authenticité des données (signature numérique) et pour générer des clés diversifiées éphémères qui sont ensuite utilisées pour assurer la confidentialité (chiffrement), l'intégrité des données (contrôle d'intégrité) et la gestion des versions des données interne de l'appareil et qui sont ensuite utilisées pour protéger et transmettre en toute sécurité un ensemble de données relatives aux applications du dispositif en tant que conteneur de sauvegarde sécurisé (SBK) vers/depuis un environnement non sécurisé. Procédé selon la revendication 1, dans lequel le conteneur de sauvegarde sécurisé est sauvegardé à l'extérieur du dispositif sur un support de stockage externe. Procédé selon la revendication 1, dans lequel le conteneur de sauvegarde sécurisé est extrait d'un support de stockage et envoyé dans le dispositif. Procédé selon la revendication 1 et 2 dans lequel la confidentialité des données est assurée en utilisant un procédé de cryptage des données à clés éphémères ; l'intégrité des données est assurée en utilisant une méthode de contrôle d'intégrité utilisant des clés éphémères ; l'authenticité des données est assurée par une signature numérique pour preuve d'origine à l'aide d'une clé déterministe. Procédé selon la revendication 1 et 3 dans lequel les données confidentielles sont décryptées en utilisant un procédé de cryptage de données utilisant des clés éphémères ; l'intégrité des données est vérifiée en utilisant un procédé de vérification d'intégrité utilisant des clés éphémères ; l'authenticité des données est vérifiée par une signature numérique pour preuve d'origine à l'aide d'une clé déterministe. Procédé selon l'une quelconque des revendications précédentes dans lequel la procédure de sauvegarde/restauration peut être dispatchée entre un MCU (légèrement sécurisé) et un élément sécurisé (hautement sécurisé). Procédé selon la revendication 1, dans lequel le protocole de sécurité garantit que le conteneur de sauvegarde sécurisé apparaît comme des données aléatoires interdisant la corrélation de données pour répondre aux exigences de confidentialité par conception. Une application telle que définie dans les revendications 2 et 3 qui applique le consentement de l'utilisateur pour la sauvegarde et la restauration en utilisant des mécanismes d'authentification de l'utilisateur dans le dispositif tels que l'empreinte digitale, le code PIN ou des moyens équivalents. Procédé selon la revendication 2 & 3 dans lequel le dispositif fournit un URI (Universal Resource Identifier) ou URN (Universal Resource Name) pour désigner la destination du stockage. Procédé selon la revendication 2 & 3 dans lequel le dispositif fournit un UUID (Unique Universal Identifier) pour l'identification du SBK quel que soit le lieu de stockage.