INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Les vias 32 peuvent présenter un facteur de forme sensiblement supérieur ou égal à 5, et de préférence supérieur ou égal à 10. Par facteur de forme, on entend le rapport entre la dimension la plus longue sur la dimension la plus courte. Ici le facteur de forme F est tel que F = L 32 /D 32 . Ce facteur de forme permet de faciliter la formation d’un organe électriquement conducteur ou semi-conducteur traversant, par exemple une interconnexion traversante par le via 32, lors de la fabrication du dispositif, et d’augmenter la densité des vias 32 sur le substrat, en synergie avec le pas les séparant.
Selon un exemple pouvant être illustré par la , les vias 32 forment une matrice périodique, c’est-à-dire que les vias 32 sont disposés à intervalles réguliers dans le plan d’extension principale des première 30 et deuxième 31 couches. Ainsi, le substrat 3 peut être un substrat générique comprenant une matrice de vias, dans laquelle des vias à graver et à remplir 32’ seront choisis en fonction des organe électriquement conducteur ou semi-conducteur à former, comme décrit plus en détail ultérieurement.
Pour cela, les vias 32 peuvent être séparés deux à deux par un premier pas A selon une première direction contenue dans le plan d’extension principale des première 30 et deuxième 31 couches. Les vias 32 peuvent être séparés deux à deux par un deuxième pas B selon une deuxième direction contenue dans le plan d’extension principale des première 30 et deuxième 31 couches, distincte de la première. De préférence, ces première et deuxième directions sont perpendiculaires. L’un et/ou l’autre de ces pas A et B peuvent être sensiblement compris entre 50 µm et 300 µm, de préférence entre 100 µm et 200 µm. Ces pas peuvent être différents l’un de l’autre ou égaux entre eux, selon la géométrie de matrice désirée. Ce pas est mesuré centre à centre entre deux vias 32 se suivant directement.
Selon un exemple pouvant être illustré par les figures 3A et 3B, le substrat 3 peut comprendre au moins une et de préférence plusieurs rainure(s) 35 configurée(s) pour améliorer l’isolation électrique des vias 32. Le substrat 32 est ainsi particulièrement adapté pour des applications de hautes fréquences et/ou en remplacement de substrat de haute résistivité pour les applications le demandant. Pour cela, au moins un via 32, et de préférence chaque via 32, présente une section transversale intégralement entourée de la rainure 35, prise dans le plan d’extension principale des première 30 et deuxième 31 couches. La rainure 35 peut entourer le via 32 sur au moins une portion de sa dimension longitudinale L 32 . Les rainures 35 sont de préférence disposées de façon à isoler les vias 32 les uns des autres, une rainure 35 entourant de préférence un seul via 32. Les rainures 35 ne se touchent de préférence pas entre elles. La rainure 35 peut plus particulièrement s’étendre depuis la deuxième couche 31 sur une portion de la première couche 30.
Chaque rainure 35 est de préférence enterrée, c’est-à-dire qu’elle ne débouche pas sur l’une ou l’autre des surfaces exposées 3a, 3b du substrat 3. Chaque rainure 35 définit donc un volume clos. Chaque rainure 35 est de préférence creuse, elle n’est pas remplie d’un matériau solide. Chaque rainure 35 est de préférence remplie d’une atmosphère gazeuse telle que de l’air, de l’azote ou de l’argon, éventuellement à une pression inférieure ou égale à la pression ambiante.
Chaque rainure 35 est délimitée par une paroi latérale 350, une paroi de fond 351 et une paroi supérieure 352 opposée à la paroi de fond 351. La paroi de fond 351 est disposée vers la surface arrière 3b du substrat et la paroi supérieure 352 est disposée vers la surface avant 3a du substrat 3. Parmi ces parois, au moins la paroi de fond 351 et la paroi latérale 350 peuvent être en matériau diélectrique, par exemple en SiO 2 . Comme l’illustre la , toutes les parois peuvent être en matériau diélectrique. Selon une variante non représentée sur les dessins, la paroi supérieure 352 peut être dans le même matériau que la deuxième couche 31. On peut également prévoir que la rainure 35 affleure la surface de la première couche 30, comme les vias 32 illustrés en . Selon une autre variante pouvant par exemple être illustrée par la , toutes les parois peuvent être dans le même matériau que la couche dans laquelle ou contre laquelle elles s’étendent, en matériau diélectrique ou semi-conducteur selon la couche considérée.
Dans le cas présent, l’opération de transchiffrement permet de passer d’un chiffré par flot à un chiffré dans le domaine homomorphe. Plus précisément, si l’on note le chiffré homomorphe de au moyen de la clé publique , on obtient :
c’est-à-dire le chiffré homomorphe de la ligne en question.
En pratique, lorsque l’utilisateur A souhaite autoriser l’utilisateur B à interroger sa base de données, il chiffre les masques inverses, c’est-à-dire les mots (les masques étant issus du flux de clé), au moyen de la clé publique du cryptosystème homomorphe additif de B puis les transmet au serveur qui réalise l’opération de démasquage (3) sur les lignes de la base de données. Cette opération de démasquage dans le domaine homomorphe peut être réalisée une fois pour toutes en mode « hors-ligne) ou bien au contraire, à la volée, à chaque fois que l’utilisateur B demande à l’utilisateur A d’accéder à la base de données (détenue par A). On notera que l’opération (3) protège la confidentialité des données vis-à-vis du serveur car ce dernier n’a accès ni au premier terme de l’expression (en raison du masquage) ni au second en raison du chiffrement homomorphe.
Selon une variante de réalisation, en lieu et place de l’opération (3), le serveur peut surchiffrer les valeurs de la base à l’aide de la clé publique pour obtenir le chiffré homomorphe . Le chiffré homomorphe de la ligne peut alors être obtenu au moyen de l’opération d’addition interne :
Revenant à la Fig. 2, on a représenté en 230 la structure de la base après transchiffrement. On remarque que la base est toujours constituée de lignes mais celles-ci sont ici de taille double (les chiffrés ont une taille double de celle des clairs) et contiennent respectivement , . Chaque chiffré est par conséquent constitué de deux mots de , notés et , stockés à la ligne .
L’utilisateur B peut alors transmettre au serveur une requête portant sur la présence d’un enregistrement donné, selon un protocole de type PIR. Pour ce faire, l’utilisateur B calcule l’empreinte numérique de l’enregistrement recherché au moyen de la fonction de hachage publique ayant servi à la construction de la base. On note la valeur entière associée à l’empreinte numérique et la valeur entière associée aux premiers bits de cette empreinte. La requête est formée par un vecteur de chiffrés avec un chiffré de la valeur « 1 » en position , le reste étant constitué par des chiffrés de la valeur «0». Autrement dit :
où est le ème élément du vecteur et est le symbole de Kronecker.
Pour tout , le serveur calcule et , sans prendre en compte le fait que les valeurs et sont des portions de chiffrés, puis calcule les sommes suivantes dans l’espace homomorphe :
(6-1)
(6-2)
en application des expressions (1) et (2). On notera que ces expressions correspondent à une évaluation dans le domaine homomorphe d’un produit scalaire dans le domaine des clairs.
Les chiffrés homomorphe et forment la réponse qui est retournée à l’utilisateur B. On comprendra que le serveur ne peut déterminer en aucun cas la ligne ( ) qui a répondu ni a fortiori le contenu de la réponse.
L’utilisateur B déchiffre alors et au moyen de sa clé privée, , puis concatène les valeurs obtenues et pour former le chiffré de la ligne :
L’étape 410 d’envoi d’une requête de défi, réalisée par l’application de flashage, consiste à envoyer à l’appareil électronique 10 une requête de défi. L’appareil électronique 10 effectue ensuite l’étape 420 de génération d’un défi cryptographique (communément désigné par le terme anglais « challenge »). Lors de cette étape 420, le chargeur d'amorçage (si l’appareil électronique 10 est en mode de chargeur de démarrage MCD) ou le démon (si l’appareil électronique 10 est en mode de système d'exploitation MSE) génère un défi correspondant à la requête de défi reçue. Le démon est un service du système d'exploitation qui tourne en permanence. Le défi est de préférence un défi aléatoire de 28 octets présentant une entropie élevée. Le défi généré est envoyé en réponse à la requête de défi reçue de l’application de flashage.
Dans un mode de réalisation dans lequel l’appareil électronique 10 est connecté (e.g. branché) à un des ports USB du poste de travail 103, la requête de défi de l’étape 410 est compris dans une requête USB envoyée à l’appareil électronique 10 lors du processus automatisé de négociation entre le poste de travail 103 et l’appareil électronique 10. De plus, le défi généré à l’étape 420 est ensuite compris dans une réponse USB envoyée au poste de travail 103 pour répondre à ladite requête USB.
Suite à la réception du défi, l’application de flashage réalise l’étape 430 de signature de défi consistant à générer une signature en signant le défi à l'aide de la clé privée correspondant à l’opérateur. Plus précisément, l’application de flashage chiffre le défi avec la clé privée pour générer la signature. L’application de flashage réalise ensuite l’étape 440 consistant à envoyer à l’appareil électronique 10 une réponse au défi comprenant la signature générée et la clé publique associée à la clé privée.
L’appareil électronique 10 effectue alors l’étape 450 de vérification de la clé publique et de la signature reçues. La vérification de la clé publique est réalisée pour déterminer si la clé publique reçue est reconnue ou acceptée par l’appareil électronique 10. Autrement dit, l’appareil électronique 10 vérifie si l’opérateur associé à la clé publique reçue est un des opérateurs autorisés de mettre à jour l’appareil électronique 10.
S’agissant de l’étape 450, la réponse au défi générée et envoyée par l’application de flashage, est de préférence stockée, comme mentionnée précédemment, dans un attribut que le noyau utilise pour communiquer avec des composants de service du système d'exploitation. De plus, comme décrit ci-dessus, les informations d’authentification préalablement enregistrées dans l’appareil électronique 10 comprennent les clés publiques autorisées ou les valeurs représentatives associées à ces clés publiques autorisées.
Dans un mode de réalisation référentiel où les informations d’authentification préalablement enregistrées dans l’appareil électronique 10 comprennent les valeurs représentatives associées aux clés publiques autorisées, l’appareil électronique 10 calcule une valeur représentative (e.g. une somme de contrôle) de ladite clé publique reçue du poste de travail 103, en utilisant par exemple l’algorithme « SHA256 ». Si la valeur représentative de ladite clé publique reçue est égale à celle d’une des clés publiques autorisées, ou si ladite clé publique reçue est identique à une des clés publiques autorisées, l’appareil électronique 10 reconnaît ou accepte la clé publique reçue. L’opérateur associé à la clé publique reçue est autorisé de mettre à jour l’appareil électronique 10.
Ensuite, la vérification de la signature reçue est réalisée, en fonction du défi correspondant à la signature reçue ainsi que de la clé publique reçue et acceptée, si la signature reçue est signée par l’opérateur associé à la clé publique reçue et acceptée. Plus précisément, l’appareil électronique 10 déchiffre la signature reçue à l’aide de la clé publique reçue pour générer un résultat déchiffré, et compare le résultat déchiffré avec le défi généré à l’étape 420 par l’appareil électronique 10. Si le résultat déchiffré est identique au défi généré, la signature reçue est considérée comme étant signée par l’opérateur au moyen de sa clé privée associée à la clé publique reçue et acceptée. De manière préférentielle, l’algorithme « SHA256 » est utilisé pour calculer une valeur représentative associée au défi (généré et envoyé à l’étape 420) et celle du résultat déchiffré, lors de la vérification de la signature reçue.
Si l’appareil électronique 10 confirme que la signature reçue est signée par l’opérateur au moyen de sa clé privée associée à la clé publique reçue et acceptée, le résultat du mécanisme d'authentification 400 est une confirmation positive. Cette confirmation positive indique que la réalisation du mécanisme de flashage 200 est souhaitée par l’opérateur en charge de la mise à jour de l’appareil électronique 10, et que ledit opérateur est reconnu comme un opérateur autorisé de mettre à jour de l’appareil électronique 10. Ainsi, l’exécution de l’étape 220 de redémarrage de l’appareil électronique 10 ou/et celle de l’étape 230 de déverrouillage peut être effectuée.
Au contraire, aucune des étapes 220 et 230 n’est effectuée si le résultat du mécanisme d'authentification 400 indique que la signature n’est pas signée par l’opérateur au moyen de sa clé privée associée à la clé publique reçue, ou que l’opérateur associé à la clé publique reçue n’est pas reconnu comme un opérateur autorisé à mettre à jour l’appareil électronique 10.
Suite à la confirmation positive obtenue à l’issue de l’étape 450 du mécanisme d'authentification 400, soit l’étape 230 de déverrouillage est effectuée si l’appareil électronique 10 à ce stade est en mode de chargeur de démarrage MCD, soit l’application de flashage demande à l’appareil électronique 10 d’effectuer l’étape 220 de redémarrage si l’appareil électronique 10 à ce stade est en mode de système d'exploitation MSE.
L’étape 220 de redémarrage est réalisée pour redémarrer l’appareil électronique 10 et pour maintenir l’appareil électronique 10 en mode de chargeur de démarrage MCD pendant une période prédéterminée. L’étape 220 de redémarrage est réalisée par une exécution automatique du chargeur d'amorçage sans intervention manuelle. Ensuite, le mécanisme d'authentification 400 est à nouveau réalisé pour générer un nouveau défi et une nouvelle signature et pour les vérifier. Si une nouvelle confirmation positive est obtenue à l’issue de cette deuxième réalisation du mécanisme d'authentification 400, l’étape 230 de déverrouillage est ensuite effectuée. Ainsi, dans un cas où l’appareil électronique 10 est en mode MSE lorsqu’il est connecté (e.g. branché) au poste de travail 103, le mécanisme de flashage 200 consiste à effectuer deux fois le mécanisme d'authentification 400. Alternativement, si l’appareil électronique 10 est en mode MCD lorsqu’il est connecté au poste de travail 103, le mécanisme de flashage 200 consiste à effectuer une seule fois le mécanisme d'authentification 400.
Quand l’appareil électronique 10 est en mode de chargeur de démarrage MCD ainsi que la confirmation positive est obtenue à l’issue du mécanisme d'authentification 400, l’étape 230 de déverrouillage est effectuée pour déverrouiller le chargeur de démarrage afin de permettre aux partitions du composant de mémoire 11 d’être reflashées.
L'étape 240 de flashage, consistant à écrire dans les partitions du composant de mémoire 11 de l’appareil électronique 10 les dernières mises à jour logicielles reçues du poste de travail 103, est réalisée uniquement suite à l’étape 230 de déverrouillage. De manière préférentielle, l’état d’avancement de flashage de l’appareil électronique 10, par exemple une étape du mécanisme de flashage 200 actuellement en cours pour l’appareil électronique 10, peut être affiché sur l’écran du poste de travail 103.
Dans un mode de réalisation où le port d’accès est un port USB, le défi, la clé publique, la signature et les réponses sont transmis entre l’appareil électronique 10 et le poste de travail 103, en utilisant un point de terminaison en bloc USB (« USB BULK endpoint » en anglais) ou un point de terminaison de contrôle USB (« USB CONTROL endpoints » en anglais). Plus précisément, si l’appareil électronique 10 est en mode de chargeur de démarrage MCD, un point de terminaison en bloc USB est utilisé alors que si l’appareil électronique 10 est en mode de système d'exploitation MSE, un point de terminaison de contrôle USB est utilisé.
Dans un cas où plusieurs appareils électroniques 10 sont connectés au poste de travail 103 pour être mis à jour, des dernières mises à jour logicielles correspondant à chacun des appareils électroniques 10 sont proprement identifiées et préalablement récupérées par le poste de travail 103. Ainsi, quand un des appareils électroniques 10 est à l’étape 240 de flashage, les dernières mises à jour logicielles correspondant audit appareil électronique 10 ne sont pas confondues avec celles d’un autre appareil électronique, et sont écrites dans le composant de mémoire 11 dudit appareil électronique 10.
Les appareils électroniques 10 peuvent chacun commencer à réaliser le mécanisme de flashage 200 à différents moments, ou/et passer du temps différent pour réaliser les étapes du mécanisme de flashage 200. Par exemple, les appareils électroniques 10 comprend un premier et un deuxième appareils électroniques, et le deuxième appareil électronique est à l’étape 430 de signature de défi quand le premier appareil électronique est déjà à l’étape 240 de flashage.
Cette fluidité d’usage n’est pourtant pas obtenue au détriment de la sécurité, puisque le profil utilisateur n’est effectivement stocké dans le module sécurisé qu’après vérification que les instructions de code de programme reçues en vue de leur exécution sur l’équipement terminal, bénéficient du droit d’accès ou privilège (de l’anglais, « carrier privilege ») requis, ce droit d’accès étant accordé exclusivement à l’opérateur du réseau de communication mobile qui a généré le profil utilisateur.
Selon un autre aspect de l’invention, lesdites instructions de code de programme sont comprises dans une application logicielle, dite application instantanée, et correspondent à une partie des instructions de code de programme d’une autre application logicielle, dite application native, ladite application native n’étant pas exécutée au cours de la session de communication.
Avantageusement, dans un mode de réalisation, l’invention propose d’appliquer de façon astucieuse le concept d’application logicielle instantanée à la gestion des profils utilisateurs dans un équipement terminal.
Une application logicielle instantanée est liée à une application logicielle native, au sens où elle comprend une partie des instructions de code de programme de cette application native, cette partie permettant la mise en œuvre d’une partie des fonctionnalités de l’application logicielle native. Une application native est une application mobile qui est développée spécifiquement pour un des systèmes d'exploitation utilisé les équipements terminaux de type téléphone intelligent ou tablette. Ce développement spécifique permet généralement d'utiliser toutes les fonctionnalités disponibles dans le système d’exploitation (telles que le GPS, accéléromètre, appareil photo, etc.) et donc de concevoir des applications généralement plus riches que les applications web. Ces applications natives nécessitent d’être téléchargées depuis un magasin d’applications logicielles, puis installées, mais elles peuvent ensuite être utilisées sans connexion Internet. En l’espèce, cette partie des instructions de code de programme correspond à la mise en œuvre de la fonctionnalité de chargement/activation du nouveau profil utilisateur généré par le système d’information du réseau de communication de l’opérateur, dans le module eUICC/eSIM de l’équipement terminal de l’utilisateur.
Or, aujourd’hui, les applications instantanées s’exécutent dans des environnements ouverts mettant en œuvre des interfaces de communication non sécurisées, par exemple pour permettre à un nouvel utilisateur de tester un jeu vidéo, l’application instantanée ne lui permettant d’accéder qu’à un premier niveau de jeu par exemple.
L’invention vient ainsi à contrepied de l’usage courant en proposant ici d’adapter le mécanisme d’application instantanée à un environnement fermé, celui d’un module sécurisé de gestion de profils utilisateurs générés par un ou plusieurs opérateurs de réseaux de communications et de d’une interface de communication sécurisée avec ce module. Selon l’invention, l’application instantanée en question hérite des droits d’accès ou privilèges de l’application native dont elle est issue.
Selon encore un autre aspect de l’invention, le procédé comprend l’émission d’une représentation de l’information d’identification d’accès reçue à l’utilisateur sur une interface utilisateur mise en œuvre au cours de la session de communication et en ce que ladite sélection de l’information d’identification d’accès par l’utilisateur est détectée sur ladite interface utilisateur.
Par exemple, l’interface est une fenêtre d’interaction affichée sur l’écran tactile de l’équipement terminal. Avantageusement, il s’agit de la fenêtre dans laquelle sont affichés les messages successivement échangés entre l’utilisateur et l’agent conversationnel.
Selon un autre aspect de l’invention, le procédé comprend : - l’obtention d’un identifiant de groupe de ladite application instantanée et de ladite première information cryptographique à partir de l’information d’identification d’accès ; - l’obtention et le chargement des instructions de code de programme de l’application instantanée dans une mémoire de l’équipement terminal, à partir de l’identifiant de groupe de l’application, et - la vérification que les instructions de programme reçues sont associées à ladite première information cryptographique. Un avantage est de garantir que l’équipement terminal ne charge pas des instructions de code de programme frauduleuses.
Selon encore un autre aspect de l’invention, l’exécution des instructions de code de programme déclenche l’obtention auprès d’un premier équipement serveur du réseau de communication d’une information d’identification du profil utilisateur et d’une information d’identification d’accès à un deuxième équipement serveur stockant ledit profil utilisateur, l’envoi desdites informations audit module sécurisé dans un message de commande de chargement dudit profil utilisateur, l’obtention par une interface dudit module sécurisé dudit profil utilisateur et d’au moins une information de description associée, ladite information de description associée comprenant une deuxième information cryptographique, ladite deuxième information cryptographique signant le profil utilisateur étant utilisée pour vérifier que la première information cryptographique signant les instructions de code de programme a été obtenue à partir du même certificat de l’opérateur que la deuxième information cryptographique.
Du fait que le module de gestion des profils utilisateur est susceptible de stocker des profils issus de plusieurs opérateurs, il n’est pas censé connaître les systèmes d’information de chacun d’eux. A réception de la commande de chargement d’un nouveau profil utilisateur, il requiert donc auprès d’une plateforme de service de cet opérateur qu’elle lui fournisse l’adresse de l’équipement serveur qui stocke le profil utilisateur et un identifiant du profil en question. Par exemple, ces deux informations sont transmises dans une même chaîne de caractères appelée code d’activation (ou « activation code », en anglais).
Les informations reçues permettent à l’interface sécurisée de vérifier que les instructions de code de programme qui s’exécutent sur l’équipement terminal et lui ont transmis la commande, sont légitimes et bénéficient du droit d’accès
L’invention concerne également un dispositif d’activation d’un profil utilisateur dans un équipement terminal, ledit profil utilisateur ayant été généré par un réseau de communication mobile d’un opérateur et comprenant des informations permettant l’accès de l’utilisateur à au moins un service dudit réseau de communication lorsqu’il est stocké dans un module sécurisé de l’équipement terminal.