INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Chaque ligne dans ces tableaux correspond à l’étape de construction d’une clé QKD, de taille u inférieure à T et indiquée dans la colonne de gauche. La case en deuxième colonne indique comment, pendant cette construction, la séquence {bases} Alice de taille 2T est cryptée (ou non) et la case en troisième colonne indique comment, pendant cette construction, la séquence {bases} Bob de taille 2T est cryptée (ou non). La case en quatrième colonne indique comment, pendant cette construction, est cryptée (ou non) la séquence des bits de parités de taille inférieure à 2T (dans le protocole de détection d’erreur considéré ici, seule D_ALICE 10 transmet les bits de parité à D_BOB 20, ce dernier ne les envoyant pas). Enfin, dans la colonne la plus à droite du tableau, il est indiqué le message utile qui sera transmis cryptée par la clé une fois construite: le message M_i est ainsi crypté par la clé K QKD_ i, i = 1, 2, 3, …N-1, N … La taille du message M_i est inférieure ou égale à la taille de K QKD_ i .
Pendant l’élaboration par protocole QKD de la première clé de session, K QKD_ 1 , les séquences de bases choisies et de valeurs de parité sont transmises en clair. A l’issue de cette construction, la clé K QKD_ 1 est utilisée pour chiffrer un premier message utile, M_1, échangé entre D_ALICE 10 et D_BOB 20.
La seconde clé K QKD_ 2 est générée en cryptant les transmissions sur le canal classique, en utilisant des séquences dérivées de la première clé secrète (concaténation, combinaison logique, permutations des bits). Par exemple, pendant l’élaboration par protocole QKD de la deuxième clé de session, K QKD_ 2 :
- la séquence de bases, {bases} Alice est cryptée en fonction de la clé K QKD_ 1 ; par exemple, une fonction φ’ de concaténation est appliquée à la clé K QKD_ 1 pour générer une clé de chiffrement de la séquence de choix des bases de taille supérieure ou égale à 2T ; par exemple elle effectue la concaténation de 3 fois la clé K QKD_ 1 : K QKD_ 1 І K QKD_ 1 І K QKD_ 1 ;
- la séquence de bases, {bases} Bob est cryptée en fonction de la clé K QKD_ 1 , mais de façon distincte et indépendante (au niveau de chaque bit) par rapport à {bases} Alice ; par exemple, une fonction ψ’ combinant permutation et concaténation est appliquée à la clé K QKD_ 1 pour générer une clé de chiffrement de taille supérieure ou égale à 2T ; par exemple elle effectue une permutation (P) des bits dans K QKD_ 1 puis une concaténation de 3 fois la clé permutée : P(K QKD_ 1 ) І P(K QKD_ 1 ) І P(K QKD_ 1 ) ;
- la séquence des parités est par exemple cryptée avec la même clé de chiffrement que pour la séquence {bases} Alice .
A l’issue de la construction de K QKD_ 2 , la clé K QKD_ 2 est utilisée pour chiffrer un deuxième message utile, M_2, échangé entre D_ALICE 10 et D_BOB 20.
On procède similairement pour générer la troisième clé secrète K QKD_ 3 , en utilisant cette fois des concaténations des premières clés QKD secrètes K QKD_ 1 et K QKD_ 2 pour effectuer le chiffrement des choix de bases et des valeurs de parités.
Après la génération de K QKD_ 3 , on passe en régime établi.
En référence maintenant à la , on s’intéresse à la génération de la clé K QKD_ N dans un mode de réalisation de l’invention, avec N supérieur ou égal à 4, les clés QKD générées antérieurement étant stockées par D_ALICE 10 et D_BOB 20.
Pendant le procédé de génération de K QKD_ N dans un mode de mise en œuvre de l’invention, séquentiellement : un ensemble des dernières clés secrètes partagées par D_ALICE 10 et D_BOB 20 (ici les 3 dernières K QKD_ N-3 , K QKD_ N-2 , et K QKD_ N-1 ) est par exemple utilisé pour construire, par concaténation, des clefs de chiffrement de taille suffisante pour (dé-)crypter les séquences d’information binaire relatives aux bases utilisées par D_ALICE, par D_BOB, et pour crypter les parités ; une permutation sur les clés concaténées par D_BOB par rapport à D_ALICE est effectuée afin de cacher à Eve quels qubits sont retenus/écartés lors du sifting : ainsi par exemple dans le cas présent, la clef de chiffrement symétrique utilisée pour (dé-)chiffrer {bases} Alice (et les bits de parité) est K QKD_N-1 | K QKD_N-2 | K QKD_ N-3 tandis que la clef de chiffrement symétrique utilisée pour (dé-)chiffrer {bases} Bob est K QKD_N-2 | K QKD_N-3 | K QKD_N-1
De plus, le dispositif de calcul 6 est configuré pour mettre en œuvre un module d’installation d’infrastructure à clés publiques pour obtenir des paramètres associés à une instanciation d’une infrastructure à clés publiques, analogue à celui mis en œuvre par le dispositif de calcul 4.
La est un synoptique des principales étapes de la première phase d’un procédé de gestion de clés racines d’une infrastructure PKI selon un mode de réalisation.
Le procédé comprend des étapes mises en œuvre lorsque le dispositif de calcul dans lequel est mis en œuvre le procédé est connecté à un réseau de communication, puis des étapes mises en œuvre lorsque le dispositif de calcul est déconnecté de tout réseau de communications.
En particulier, le procédé comprend une étape 40 d’installation d’un système d’exploitation autonome et sécurisé, par exemple le système d’exploitation Live Linux, qui est exécuté à la volée.
Dans un mode de réalisation l’installation est effectuée par intervention d’un opérateur sur instructions, de manière à assurer la reproductibilité des actions.
En variante, une installation automatisée est également envisageable.
Le procédé comprend ensuite une étape 42 d’installation pour obtenir des paramètres associés à une instanciation d’une infrastructure à clés publiques.
Par exemple, lors de l’étape 42, un script de PKI est obtenu via une liaison de communication du dispositif de calcul mettant en œuvre le procédé.
De préférence, la liaison de communication est une liaison filaire.
L’étape 42 est suivie d’une étape 44 de déconnexion du dispositif de calcul du réseau de communication, par exemple par déconnexion du câble filaire qui assure la liaison par un opérateur. Cela assure une sécurité maximale, l’accès distant au dispositif de calcul mettant en œuvre le procédé étant ainsi rendu impossible.
Les étapes suivantes sont exécutées hors connexion du dispositif de calcul à tout réseau de communication.
L’étape 44 est suivi d’une étape 45 de génération d’une clé secrète de l’instanciation de ladite infrastructure à clés publiques. Une clé secrète K s est une clé générée afin d’afin de chiffrer la sauvegarde de l’instanciation de ladite infrastructure à clé publique lors de l’étape 52 décrite ci-après.
L’étape 45 est suivie d’une étape 46 de génération d’une clé racine K r de l’instanciation de ladite infrastructure à clés publiques.
Une clé racine est une clé générée par la strate hiérarchique la plus haute, également appelée autorité de certification ou CA (pour « Certification Authority »).
La clé racine est un secret de plus haut niveau, dont la confidentialité et l’intégrité sont critiques pour la gestion de l’infrastructure à clés publiques.
De préférence, la clé racine est générée avec un algorithme à entropie élevée, permettant d’assurer un niveau de sécurité satisfaisant.
Le domaine de sécurité racine ISD-R est privilégié en ce qu'il est notamment apte à créer ou supprimer des domaines de sécurité ISD-P dans la mémoire non volatile MEM, et à activer ou désactiver des profils P chargés dans les ISD-P 320 de l’eUICC.
De façon connue des spécifications susvisées, cette gestion est réalisée par l’échange de messages (commandes, réponses) entre l’unité SM-SR 110 (ou le SM-DP+) et le domaine racine ISD-R 310. Les différentes fonctions et commandes de gestion de l’eUICC 300 sont définies dans ces documents SGP.02 pour le mode M2M et SGP.22 pour le mode Consumer. La communication entre l’unité SM-SR 110 et l’ISD-R 310 peut être portée par le protocole http et être assurée et/ou protégée par le protocole SCP80, SCP81 ou CAT-TP.
Le chargement, la mise à jour ou la suppression de façon sécurisée des profils dans les domaines sécurisés ISD-P 320 est réalisée par l’échange de messages (commandes, réponses) entre l’unité SM-DP 120 et chaque domaine sécurisé ISD-P concerné de l’eUICC 300. L’unité SM-DP 120 prépare notamment les packages de profil à charger dans l’eUICC, puis les envoie au domaine ISD-P 320 concerné, via l’unité SM-SR 110 et l’ISD-R 310. A nouveau des messages APDU sont utilisés. La communication entre l’unité SM-DP 120 et l’ISD-P 320 (via le SM-SR 110) peut être portée par le protocole http et être protégée par le protocole SCP02 ou SCP03 ou SCP03t, elle-même « tunnelée » ou encapsulée dans le lien SM-SR – ISD-R protégé par le protocole SCP80, SCP81 ou CAT-TP.
La illustre la communication d’un package de profil à installer en mode Consumer avec un assistant LPAd 220 dans le terminal utilisateur 200. Une connexion sécurisée, libellée ES9+ dans SGP.22, est établie entre la fonction de fourniture de package de profil 122 et l’assistant LPAd 220 (ou LPAe 330 dans la variante où celui-ci est implémenté). Une seconde connexion sécurisée, libellée ES8+ dans SGP.22, est établie entre la fonction de fourniture de génération de profil 121 et l’eUICC 300, plus précisément l’ISD-R 310. La seconde connexion est « tunnelée » au sein de la connexion ES9+ et d’une troisième connexion entre l’assistant LPA et l’ISD-R 310. Les mécanismes de sécurisation des connexions par clé sont décrits dans SGP.22.
Le package de profil ainsi communiqué à l’ISD-R est transmis, dans l’eUICC, à l’ISD-P cible pour installation du profil. L’ISD-P cible est identifié par l’ICCID présent dans les métadonnées de profil.
Des mécanismes similaires sont mis en œuvre dans le mode M2M où la communication avec le SM-DP+ ou SM-SR est réalisée, à l’initiative de ce dernier, directement avec l’ISD-P cible.
Lorsqu’un profil d’abonné P ainsi chargé est activé par le SM-SR 110 ou SM-DP+ (ou en variante par l’utilisateur via un menu sur le terminal utilisateur 200), il est équivalent à une UICC : il permet à l’utilisateur de s’identifier sur le réseau mobile 100 de l’opérateur MNO auquel il a souscrit l’abonnement correspondant au profil afin d’accéder à des services.
L’opérateur MNO 130 peut aussi accéder directement, par OTA (Over The Air – par exemple par SMS), au profil P actif (et notamment à certaines actions prévues par l’opérateur dans ce profil) pour réaliser des actions de diverses natures (notamment la gestion à distance d’un composant du profil 320, par exemple une mise à jour de données ou d’offre ou de règles d'exécution, etc.). De façon réciproque, des applications dans le profil P actif peuvent être configurées pour transmettre des données au MNO 130. Ces échanges sont illustrés sur la par une flèche double sens entre le MNO 130 et le profil P.
La mise à jour d’un profil dans l’eUICC (peu importe le composant de profil visé) est essentielle pour une bonne gestion des eUICCs. La communication OTA est l’unique accès permettant une mise à jour des données de profil. La communication classique depuis le serveur SM-DP 120, pour une mise à jour de profil, requiert en effet une suppression de profil suivi d’une installation d’un nouveau profil mis à jour, ce qui entraîne des communications inutiles.
La communication OTA présente cependant certains inconvénients : d’une part, elle n’est possible que pour un profil actif ; d’autre part, elle requiert l’utilisation d’une plateforme OTA dédiée, ce qui peut s’avérer coûteux pour l’opérateur.
L’invention permet de réutiliser le serveur SM-DP 120 (ou SM-DP+) traditionnellement dédié au chargement et à l’installation de nouveaux profils pour mettre à jour un profil dans l’eUICC. Elle permet de réutiliser les procédures existantes de chargement et installation de profil en limitant leur modification pour signaler qu’il s’agit d’une mise à jour. Elle s’appuie ainsi toujours sur le format de la spécification TCA des packages de profil en limitant son adaptation dans certains modes de réalisation.
La illustre, à l’aide d’un ordinogramme, une réalisation de l’invention selon certains modes de réalisation. Ceux-ci définissent de nouvelles commandes envoyées par le serveur SM-DP pour charger des éléments de profil (PE pour « Profile Element ») de mise à jour, qui sont similaires aux commandes classiques de chargement d’éléments de profil d’un nouveau profil à installer. Ainsi, en identifiant ces nouvelles commandes, l’eUICC 300 est en mesure de distinguer les packages de profil reçus concernant une mise à jour de profil de ceux concernant une opération classique d’installation de profil. L’eUICC peut alors mettre en œuvre une routine dédiée à la mise à jour de profil.
Le serveur SM-DP 120 génère et stocke un package de profil de mise à jour pour l’eUICC concernée, par exemple celle de la . Un package de profil de mise à jour est typiquement « partiel » en ce qu’il comporte un nombre généralement réduit d’éléments de profil PE (ceux à mettre à jour) par rapport à ceux repris dans la spécification TCA.
Un package de profil partiel comporte typiquement la différence (en termes de PEs) entre un profil installé et un profil cible souhaité.
La illustre un package de profil et les différents états d’un tel package entre sa génération et son chargement dans l’eUICC, tels que définis dans SGP.22 (mode Consumer).
Le contenu d’un package de profil 30a est défini dans la spécification TCA susvisée et s’applique tant au mode Consumer qu’au mode M2M. Il comporte une collection d’éléments de profil (PE) qui sont décrits, et peuvent ainsi être traités par l’eUICC, indépendamment les uns des autres. Chaque PE est encodé comme une donnée TLV (type ou tag [étiquette], longueur, valeur) et comporte un entête contenant un identifiant de PE (OID pour « Object Identifier »), un drapeau indiquant si le PE est obligatoire, un type de PE et une longueur de PE.
Exemple 2 Les compositions A et B telles que décrites dans les tableaux 1 et 2 ci-dessous ont été préparées : les quantités sont exprimées en g de matière première en l’état/100g, sauf mention contraire. Dans le tableau ci-dessous, ma signifie matière active.
Composition A Polycarbodiimide (1) 7 ma Ethanol 20 Eau Qsp 100
Composition B Acrylates copolymère (2) 29,2 Oxyde de fer jaune 2,3 Nacre (Mica (and) Iron Oxide) 9,7 Bis-Hydroxy/Méthoxy / Méthyl Amodiméthicone Crosspolymer (and) Trideceth-10 8,8 Copolymère Divinyldiméthicone/diméthicone (and) C 12 - 13 Pareth-3 (and) C 12 - 13 Pareth-23 (3) 10,2 Ethanol 3,75 Conservateur(s) qs Eau Qsp 100
Dans un autre mode de réalisation relatif au mode « Consumer », l’assistant local de profil est embarqué dans l’eUICC. Il est alors dénommé LPAe (référence 330 en pointillés).
La carte eUICC 300 comprend un système d’exploitation OS eUICC (stocké en mémoire non-volatile type morte ou flash par exemple) couplé à une mémoire non volatile MEM. Le système d’exploitation met en œuvre des fonctions (non représentées) dans le domaine télécom (Telecom framework) et pour la gestion des profils, typiquement un interpréteur de package de profile (Profile Package Interpreter) et un moteur de politique de profil (Profile Policy Enabler). D’autres composants classiques présents dans la carte eUICC sont ici non représentés pour des raisons de clarté : interface (et contrôleur associé) de communication avec le terminal hôte, mémoire vive, bus de donnés, processeur, etc.
Conformément aux standards susvisés, la carte eUICC 300 comprend, en mémoire non volatile MEM, plusieurs domaines de sécurité pour la gestion de la carte et de profils d’abonné, chaque domaine de sécurité étant identifié par un AID (Application Identifier) unique:
un domaine de sécurité d'autorité de contrôle de l'eUICC 305 (ECASD pour « Embedded UICC Controlling Authority Security Domain ») responsable du stockage sécurisé d’informations d'identification (credentials) nécessaires aux domaines de sécurité de l'eUICC ;
un domaine racine ou privilégié de sécurité d’émetteur 310 (ISD-R pour « Issuer Security Domain – Root ») défini, à la fabrication de l’eUICC, comme représentatif du propriétaire de la carte 300 et donc accessible (via un jeu de clés cryptographiques particulier) uniquement par lui. Dans le mode Consumer, l’ISD-R 310 comporte des services LPA aptes à établir un dialogue avec l’assistant LPAd 220 ou LPAe 330 ;
un ou plusieurs domaines de sécurité de profil 320 (ISD-P pour « Issuer Security Domain – Profile ») généralement dédiés chacun à un opérateur MNO. Chaque domaine ISD-P est un conteneur sécurisé (protégé par un jeu de clés cryptographiques notamment) prévu pour stocker, de façon sécurisée, un unique profil d’abonné P associé à une souscription de service auprès de l’opérateur MNO correspondant et pour permettre son accès. L’un des ISD-P peut comprendre un profil initial par défaut (dit « provisioning profile ») permettant une connectivité réseau avec l’unité SM-SR 110. Le profil d’abonné est identifié par un identifiant unique ICCID (pour « Integrated Circuit Card IDentifier »).
L'ISD-P comporte une routine utilisée pour le téléchargement et l'installation du profil en collaboration avec l'interpréteur de package de profil pour le décodage et l’interprétation d’un package de profil à installer, reçu dans un canal sécurisé (par exemple selon SCP03t). Un package de profil est notamment conforme à la spécification Trusted Connectivity Alliance : « eUICC Profile Package : Interoperable Format Technical Specification », Version 3.2, dite « spécification TCA » dans la suite du document.
De façon connue, un profil de communication P comporte des données de souscription (par exemple un identifiant IMSI, des clés cryptographiques, des algorithmes d'authentification et application NAA d’accès au réseau, etc.) et peut comporter en outre un système de fichiers, des applications App, et/ou des règles d'exécution prédéterminées.
Selon les standards susvisés, un profil est composé de composants de profil (Profile Components) incluant :
un MNO-SD (domaine de sécurité de l’opérateur) comportant des clés OTA de l’opérateur pour permettre l’établissement d’un canal OTA sécurisé,
des domaines de sécurité supplémentaires (SSD) et d’un domaine de sécurité CASD,
d’applications/applets (App),
d’au moins une application d’accès réseau (NAA pour « Network Access Application »),
d’un système de fichier (File system),
de métadonnées de profil (Profile Metadata) incluant notamment des paramètres de connectivité (Connec Param) et des règles de politique de profil (POL1 par exemple). Ces métadonnées peuvent notamment inclure un identifiant ICCID (pour « Integrated Circuit Card Identifier » ou identifiant de carte à circuit intégré) qui identifie de manière unique le profil.
Bien qu’il soit illustré un unique profile P (ISD-P), la carte eUICC 300 peut comprendre une pluralité de domaines de sécurité ISD-P et ainsi une pluralité de profils chacun pouvant être à l'état actif ou inactif. Chaque profil ou ISD-P correspondant est identifié par un ICCID.
Selon un mode de réalisation de l’invention, le robot de nettoyage autonome comporte un réservoir de liquide de nettoyage. De façon avantageuse, le réservoir de liquide de nettoyage est disposé entre les roues motrices. Ainsi, la variation du niveau de remplissage du réservoir de liquide de nettoyage n’est pas susceptible de déséquilibrer la répartition des masses au sein du robot de nettoyage humide.
Selon un mode de réalisation de l’invention, le dispositif de nettoyage humide comporte au moins un orifice de sortie de liquide qui est configuré pour être relié fluidiquement au réservoir de liquide de nettoyage et qui est configuré pour alimenter en liquide de nettoyage les serpillères montées sur les supports de serpillère.
Selon un mode de réalisation de l’invention, le récipient de collecte de déchets est situé au moins en partie entre les roues motrices.
Selon un mode de réalisation de l’invention, la batterie d’alimentation comporte des cellules de batterie qui sont de forme globalement cylindrique et qui présentent des axes de cellule qui sont sensiblement parallèles entre eux.
Selon un mode de réalisation de l’invention, le plan vertical médian de la batterie d’alimentation s’étend sensiblement perpendiculairement aux axes de cellule des cellules de batterie.
Selon un autre mode de réalisation de l’invention, le plan vertical médian de la batterie d’alimentation s’étend sensiblement parallèlement aux axes de cellule des cellules de batterie.
Selon un mode de réalisation de l’invention, le robot de nettoyage autonome comporte un canal de liaison reliant fluidiquement la chambre d’aspiration au récipient de collecte de déchets.
Selon un mode de réalisation de l’invention, le canal de liaison présente une forme globalement cylindrique et est configuré pour s’étendre sensiblement verticalement lorsque le robot de nettoyage autonome repose sur une surface horizontale.
Selon un mode de réalisation de l’invention, le canal de liaison présente une section circulaire ou oblongue.
Selon un mode de réalisation de l’invention, le canal de liaison débouche dans une partie arrière de la chambre d’aspiration. Une telle disposition du canal de liaison favorise encore le guidage des déchets aspirés vers le récipient de collecte de déchets.
Selon un mode de réalisation de l’invention, le plan longitudinal médian du corps principal est sécant avec le canal de liaison.
Selon un mode de réalisation de l’invention, le corps principal comporte un bord arrière qui est courbé et qui présente, vu de dessus sous une orientation sensiblement verticale, une forme en arc de cercle. De façon avantageuse, le bord arrière présente un rayon de courbure dont le centre correspond au centre géométrique du corps principal.
Selon un mode de réalisation de l’invention, le corps principal présente, vu de dessus sous une orientation sensiblement verticale, une forme générale de D.
Selon un mode de réalisation de l’invention, le dispositif de collecte de déchets est monté de manière amovible sur le corps principal.
Selon un mode de réalisation de l’invention, la bouche d’aspiration est prévue dans une partie avant du corps principal.
Selon un mode de réalisation de l’invention, le robot de nettoyage autonome comporte une brosse de nettoyage rotative logée dans la chambre d’aspiration et montée mobile en rotation autour d’un axe de rotation de brosse.
Dans un mode de réalisation de la présente invention, le produit polymère multicouche (1) comprend un élastomère choisi parmi un latex de polyisoprène-polyisoprène, un latex de polyisoprène-chloroprène, un latex de polyisoprène-nitrile butadiène, un latex de polyisoprène-chloroprène-nitrile butadiène ou une combinaison de ceux-ci, comprenant une épaisseur de 0,5 mm à 1,5 mm au niveau du corps principal (4) et une épaisseur de plus de 0,3 mm au niveau du corps secondaire (5). De plus, le corps secondaire est au moins 50 % plus épais qu’un produit à une seule couche polymère, ce qui permet d’obtenir une meilleure résistance à la déchirure et à la rupture. Bien qu’il soit multicouche, le produit polymère est fin et ne limite pas le mouvement ou la dextérité lorsqu’il est porté.
Dans un mode de réalisation de la présente invention, la couche externe (2) et la couche interne (3) du corps principal (4) peuvent être de couleur différente pour fonctionner comme indicateur de rupture.
Dans d’autres modes de réalisation de la présente invention, ledit produit comprend un gant, un sac, un préservatif ou un bonnet de douche, mais sans s’y limiter. Dans un autre mode de réalisation de la présente invention, le produit peut également être tout produit polymère nécessitant un enfilage.