FR3096161A1 - Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. - Google Patents
Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. Download PDFInfo
- Publication number
- FR3096161A1 FR3096161A1 FR1904983A FR1904983A FR3096161A1 FR 3096161 A1 FR3096161 A1 FR 3096161A1 FR 1904983 A FR1904983 A FR 1904983A FR 1904983 A FR1904983 A FR 1904983A FR 3096161 A1 FR3096161 A1 FR 3096161A1
- Authority
- FR
- France
- Prior art keywords
- key
- encryption key
- security device
- encrypted
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000005540 biological transmission Effects 0.000 claims description 4
- 238000004891 communication Methods 0.000 description 46
- 238000004422 calculation algorithm Methods 0.000 description 25
- 230000007246 mechanism Effects 0.000 description 15
- 238000004590 computer program Methods 0.000 description 11
- 238000012545 processing Methods 0.000 description 8
- 102100039424 Polyadenylate-binding protein 4 Human genes 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 101150053844 APP1 gene Proteins 0.000 description 4
- 101100189105 Homo sapiens PABPC4 gene Proteins 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 101100055496 Arabidopsis thaliana APP2 gene Proteins 0.000 description 3
- 101100016250 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) GYL1 gene Proteins 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000035755 proliferation Effects 0.000 description 2
- 101100241173 Caenorhabditis elegans dat-1 gene Proteins 0.000 description 1
- 101100533725 Mus musculus Smr3a gene Proteins 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/10—Integrity
Abstract
L'invention concerne un procédé, un dispositif et un système de sécurisation d'au moins une donnée d'une application installée sur un dispositif connecté (OBJ) à un réseau de données (RES), le dispositif connecté étant configuré pour communiquer avec un dispositif de sécurité (ESEC) configuré pour chiffrer ou déchiffrer (E55, E69, E76) ladite au moins une donnée à l'aide d'une clé de chiffrement, le procédé de sécurisation est caractérisé en ce qu'il comprend: - l'obtention (E40) par le dispositif connecté de ladite clé de chiffrement sous une forme chiffrée (E37) à l'aide d'une clé de chiffrement de clé mémorisée dans ledit dispositif de sécurité, - la mémorisation (E41) de ladite clé de chiffrement chiffrée dans une mémoire du dispositif connecté, la mémoire dudit dispositif connecté étant distincte de la mémoire du dispositif de sécurité. Figure pour l'abrégé: Figure 3
Description
1. Domaine de l'invention
L'invention concerne le domaine de la sécurisation des données et des clés de chiffrement. Plus particulièrement, l'invention concerne la sécurisation des données d'applications mises en œuvre au sein d'un objet connecté ainsi que la sécurisation des clés de chiffrement associées à ces données.
2. Art Antérieur
Les objets connectés sont de plus en plus nombreux et leur nombre devrait dépasser les 25 milliards à l’horizon 2020. Ces objets communiquent des données ou des informations, pour une grande majorité d’entre eux, soit vers un serveur, soit vers une passerelle, soit vers d’autres objets connectés (par exemple un capteur de température vers un pc, etc.).
On entend ici par objet connecté tout objet ou équipement électronique capable de communiquer avec un autre objet ou équipement, via une connexion réseau. Par exemple, il peut s'agir d'un smartphone (pour téléphone intelligent en anglais), une tablette ou un ordinateur portable, ou autre.
La multiplication des objets connectés implique la multiplication des données collectées, ce qui génère de nouvelles problématiques autour de la sécurité de ces données échangées. Ces informations peuvent donc être interceptées et/ou détournées, potentiellement à des fins malveillantes.
Même si les communications de beaucoup d’objets sont sécurisées, un bon nombre d’entre elles le sont encore insuffisamment. Il existe donc un besoin de sécuriser les communications des objets connectés.
Un objet connecté de type capteur, est souvent mono-applicatif. Autrement dit, une seule application est installée sur le capteur. Toutefois, d'autres objets connectés plus évolués capables d'exécuter plusieurs applications existent également, par exemple, un smartphone, un assistant vocal, etc...
Ainsi, le nombre d'applications installées sur un objet connecté est variable et peut varier au cours de la vie de l'objet connecté en fonction de son utilisation. De plus, chaque application installée sur un objet connecté doit pouvoir établir des communications sécurisées indépendamment des autres applications installées sur le même objet connecté.
Il existe donc un besoin de gérer la sécurisation des communications de plusieurs applications d'un objet connecté de façon différente et de faire évoluer le nombre d’applications gérées par un objet connecté au fil de l’eau.
Sécuriser les communications est une chose, mais lorsque l’objet connecté est susceptible d’être accessible physiquement ou via le chargement involontaire d’un malware, les données stockées sur l’objet connecté par les applications peuvent être récupérées et lisibles.
Il existe donc également un besoin de stocker les données des applications d'un objet connecté de façon sécurisée.
Il existe des éléments de sécurité adaptés pour sécuriser les données stockées ou échangées par des équipements. De tels éléments de sécurité peuvent être intégrés dans l'équipement ou l'objet connecté à sécuriser. Par exemple de tels équipements peuvent être de type « cartes à puce ». Cependant, de tels dispositifs ont en général des capacités de stockage limitées et ne peuvent gérer qu'un nombre limité de clé de chiffrement.
Il existe donc un besoin d'améliorer l'état de la technique.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique. Elle concerne à cet effet un procédé de sécurisation d'au moins une donnée d'une application installée sur un dispositif connecté à un réseau de données. Le dispositif connecté est configuré pour communiquer avec un dispositif de sécurité configuré pour chiffrer ou déchiffrer ladite au moins une donnée à l'aide d'une clé de chiffrement. Avantageusement, le procédé de sécurisation comprend:
- l'obtention par le dispositif connecté de ladite clé de chiffrement sous une forme chiffrée à l'aide d'une clé de chiffrement de clé mémorisée dans ledit dispositif de sécurité,
- la mémorisation de ladite clé de chiffrement chiffrée dans une mémoire du dispositif connecté, la mémoire dudit dispositif connecté étant distincte de la mémoire du dispositif de sécurité.
Selon l'invention, les clés de chiffrement utilisées pour chiffrer les données d'une application exécutée sur un dispositif connecté sont mémorisées dans la mémoire même de l'objet connecté, et non dans la mémoire du dispositif de sécurité qui réalise le chiffrement des données à l'aide des clés de chiffrement.
Ainsi, le nombre de clés de chiffrement pouvant être utilisées pour chiffrer les données de l'application n'est pas limité par la mémoire du dispositif de sécurité mettant en œuvre le chiffrement des données. Les clés de chiffrement sont mémorisées chiffrées afin d'augmenter la sécurité des données.
Ainsi, la sécurité des données d'une ou plusieurs applications n'est pas limitée par la mémoire du dispositif de sécurité.
De plus, selon l'invention, les clés de chiffrement sont mémorisées chiffrées et non en clair dans la mémoire du dispositif connecté. Ainsi, les clés de chiffrement ne sont pas directement accessibles à des applications malveillantes.
De plus, les calculs de chiffrement (calculs cryptographiques) sont réalisés dans le dispositif de sécurité, qui est un support sécurisé.
Selon un mode particulier de réalisation de l'invention, la clé de chiffrement chiffrée est mémorisée dans la mémoire du dispositif connecté en association avec une référence de clé générée par le dispositif de sécurité, ladite référence de clé étant associée, dans le dispositif de sécurité, à la clé de chiffrement de clé ayant servie à chiffrer ladite clé de chiffrement.
Ce mode particulier de réalisation de l'invention procure l'avantage que seul le dispositif de sécurité sait quelle clé de chiffrement de clé a servi à chiffrer une clé de chiffrement mémorisée par le dispositif connecté. Ceci permet d'améliorer la sécurité des clés de chiffrement mémorisées par le dispositif connecté.
Selon un autre mode particulier de réalisation de l'invention, lorsqu'une même clé de chiffrement de clé est utilisée pour chiffrer au moins une première clé de chiffrement et une deuxième clé de chiffrement, la référence de clé générée par le dispositif de sécurité et associée à la première clé de chiffrement est distincte de la référence de clé générée par le dispositif de sécurité et associée à la deuxième clé de chiffrement.
Selon ce mode particulier de réalisation de l'invention, quand bien même une même clé de chiffrement de clé est utilisée pour chiffrer deux clés de chiffrement de données distinctes utilisées pour une même application ou bien pour deux applications distinctes, la référence de clé permettant au dispositif de sécurité d'identifier la clé de chiffrement de clé ayant servi à chiffrer les deux clés de chiffrement est différente pour chaque clé de chiffrement. Ainsi, vu de l'extérieur du dispositif de sécurité, il n'est pas possible de savoir que c'est la même clé de chiffrement de clé qui a servi à chiffrer les deux clés de chiffrement. De plus, une même clé de chiffrement de clé peut ainsi servir à chiffrer plusieurs clés de chiffrement de manière sécurisée.
Selon un autre mode particulier de réalisation de l'invention, le procédé de sécurisation comprend en outre la fourniture au dispositif de sécurité de ladite clé de chiffrement à chiffrer. Ce mode particulier de réalisation de l'invention permet le chiffrement d'une clé qui est par exemple fournie par l'application elle-même ou un service utilisé par l'application. Une telle clé est par exemple une clé dite de communication, utilisée par le dispositif connecté pour des communications externes à l'application. Par exemple, lorsque l'application est une application locale relative à un service fourni pour un serveur via le réseau de données, par exemple une application de type Facebook®, il peut s'agir d'une clé servant à chiffrer les données échangées entre l'application locale installée sur le dispositif connecté et le serveur fournissant le service à l'application locale. Dans ce cas, la clé de chiffrement des données est fournie par le service, ou générée par l'application locale.
Selon un autre mode particulier de réalisation de l'invention, le procédé de sécurisation comprend en outre la génération par le dispositif de sécurité de ladite clé de chiffrement. Ce mode particulier de réalisation de l'invention permet de générer des clés de chiffrement par le dispositif de sécurité. De telles clés de chiffrement sont par exemple utilisées pour chiffrer des données de l'application qui sont destinées à être stockées dans la mémoire du dispositif connecté.
Selon un autre mode particulier de réalisation de l'invention, le procédé de sécurisation comprend en outre, lorsque ladite clé de chiffrement chiffrée est transmise au dispositif connecté, la suppression de ladite clé de chiffrement et de ladite clé de chiffrement chiffrée de la mémoire du dispositif de sécurité. Avantageusement, la clé de chiffrement générée par le dispositif de sécurité n'est pas conservée dans la mémoire du dispositif de sécurité. Il en va de même de la clé de chiffrement chiffrée.
Ainsi, la mémoire est libérée et le nombre de clés de chiffrement générées par le dispositif de sécurité n'est pas limité.
Selon un autre mode particulier de réalisation de l'invention, lorsqu'au moins deux applications sont installées sur ledit dispositif connecté, les données de chacune des au moins deux applications sont chiffrées à l'aide de deux clés de chiffrement distinctes. Ce mode particulier de réalisation de l'invention permet d'éviter que des données sécurisées d’une application de l'objet connecté soit récupérées par une autre application de l'objet connecté.
Selon un autre mode particulier de réalisation de l'invention, le procédé de sécurisation comprend en outre:
- la transmission par le dispositif connecté au dispositif de sécurité, de ladite donnée à chiffrer ou à déchiffrer, de la clé de chiffrement chiffrée et de la référence de clé mémorisée avec la clé de chiffrement chiffrée,
- l'obtention, par le dispositif de sécurité, d'une clé de chiffrement de clé, à l'aide de la référence de clé,
- le déchiffrement, par le dispositif de sécurité, de la clé chiffrée, à l'aide de la clé de chiffrement de clé obtenue,
- le chiffrement ou le déchiffrement, par le dispositif de sécurité, de la donnée à l'aide de la clé déchiffrée,
- la transmission au dispositif connecté par le dispositif de sécurité, de ladite donnée chiffrée ou déchiffrée,
- la suppression de la mémoire du dispositif de sécurité de ladite clé de chiffrement chiffrée.
Ainsi, une grande quantité de clés peut être stockées dans la mémoire du dispositif connecté et utilisées pour sécuriser les données du dispositif connecté. Ces clés de chiffrement sont mémorisées de façon sécurisée (chiffrées). Avantageusement, tous les calculs de chiffrement de données sont réalisés par le dispositif de sécurité sans que le dispositif de sécurité n’ait besoin de connaître les clés de chiffrement et sans que les clés de chiffrement et les calculs cryptographiques ne soient visibles du dispositif connecté.
L'invention concerne également un dispositif connecté à un réseau de données, comprenant au moins une mémoire et un processeur configurés pour exécuter au moins une application. Le dispositif connecté est configuré pour communiquer avec un dispositif de sécurité configuré pour chiffrer ou déchiffrer au moins une donnée de ladite application à l'aide d'une clé de chiffrement. Avantageusement, le dispositif connecté est configuré pour mémoriser ladite clé de chiffrement dans ladite mémoire du dispositif connecté sous une forme chiffrée, ladite clé de chiffrement ayant été chiffrée par ledit dispositif de sécurité à l'aide d'une clé de chiffrement de clé, la clé de chiffrement de clé étant mémorisée dans une mémoire du dispositif de sécurité, ladite mémoire du dispositif connecté étant distincte de ladite mémoire du dispositif de sécurité.
Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité est compris dans le dispositif connecté.
L'invention concerne également un dispositif de sécurité configuré pour communiquer avec un dispositif connecté à un réseau de données. Le dispositif connecté est configuré pour exécuter au moins une application. Le dispositif de sécurité comprend une mémoire et un processeur configurés pour chiffrer ou déchiffrer au moins une donnée de ladite application à l'aide d'une clé de chiffrement. Avantageusement, le dispositif de sécurité est configuré pour mémoriser au moins une clé de chiffrement de clé dans sa mémoire, et la mémoire et le processeur sont configurés pour:
- chiffrer ou déchiffrer au moins ladite clé de chiffrement à l'aide de ladite au moins une clé de chiffrement de clé,
- transmettre ladite clé de chiffrement chiffrée au dispositif connecté.
Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité est compris dans un élément de sécurité physique de type carte à puce.
Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité est un élément sécurisé (SE pour secure element en anglais). Un tel élément sécurisé est par exemple une puce séparée comprenant un processeur sécurisé, un espace de stockage inviolable et une mémoire d'exécution.
Un tel élément sécurisé peut être une puce SIM (pour Subscriber Identification Module en anglais), une carte à puce, une puce SIM virtuelle (e-SIM), ou bien encore un élément sécurisé physique associé au processeur du dispositif connecté.
L'invention concerne également un système de sécurisation d'au moins une donnée d'une application installée sur un dispositif connecté à un réseau de données, le système comprend au moins un dispositif connecté selon l'un quelconque des modes particuliers cités précédemment et au moins un dispositif de sécurité l'un quelconque des modes particuliers cités précédemment.
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de sécurisation ci-dessus selon l'un quelconque des modes particuliers de réalisation cités précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
5. Description d'un mode de réalisation de l'invention
La figure 1 illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention. Un tel environnement comprend un objet connecté OBJ relié à un réseau de données RES, par exemple un réseau Internet, un réseau mobile ou encore un réseau local. L'objet connecté OBJ comprend au moins une application installée sur cet objet connecté permettant de fournir un service à un utilisateur de l'objet connecté. Par exemple, et de manière non limitative, l'objet connecté OBJ peut être un smartphone, un assistant vocal, une radio Internet, un capteur domotique, une borne de contrôle d'accès, ou encore tout type de dispositif électronique adapté.
L'environnement de mise en œuvre comprend également un dispositif de sécurité (ESEC) configuré pour communiquer avec l'objet connecté (OBJ) et notamment pour chiffrer au moins une donnée de l'application installée sur l'objet connecté (OBJ) Dans l'exemple de mise en œuvre décrit ici, le dispositif de sécurité (ESEC) est compris dans un dispositif (DISP) externe à l'objet connecté (OBJ) et communique avec l'objet connecté (OBJ) via le réseau de données RES.
Dans d'autres exemples de mise en œuvre de l'invention, le dispositif de sécurité (ESEC) est intégré dans l'objet connecté (OBJ) lui-même. Par la suite, le dispositif de sécurité (ESEC) peut aussi être appelé élément de sécurité.
Le dispositif de sécurité (ESEC) est par exemple une entité physique telle qu'une carte à puce, carte SIM (pour Subscriber Identification Module en anglais), ou une entité virtuelle telle qu'une carte eSIM, mise en œuvre dans un serveur ou dans un objet connecté.
Le dispositif de sécurité (ESEC) et l'objet connecté (OBJ) sont configurés pour mettre en œuvre le procédé de sécurisation qui sera décrit plus loin en relation avec les figures 2-8 selon différents modes particuliers de réalisation de l'invention. Un tel procédé permet, notamment:
- de faire communiquer les applications présentes sur un objet connecté (OBJ) de manière sécurisée,et quel que soit le mode de communication employé (Zigbee, NFC, Wifi, 4G…),
- de stocker les données applicatives de façon sécurisée sur l’objet connecté (OBJ) grâce au dispositif de sécurité (ESEC),
- d’assurer un stockage sécurisé des clés de chiffrement applicatives et de communication à utiliser par les applications de l’objet connecté (OBJ), grâce au dispositif de sécurité (ESEC), mais sans les stocker dans le dispositif de sécurité (ESEC),
- d’assurer une sécurisation différente (clés de chiffrement différentes et/ou algorithmes de chiffrement différents) quel que soit le nombre d’applications présentes sur l’objet connecté et quel soit le nombre de fonctions d’une même application,
- de pouvoir faire évoluer le nombre d’applications sécurisées par le dispositif de sécurité de façon simple,
- de pouvoir gérer le cycle de vie des différentes clés de chiffrement.
Dans d'autres exemples de mise en œuvre de l'invention, le dispositif de sécurité (ESEC) peut communiquer avec plusieurs autres objets connectés (non représentés) et sécuriser les données utilisées par des applications exécutées par ces objets connectés.
La figure 2 illustre un exemple d'architecture d'un objet connecté selon un mode particulier de réalisation de l'invention. Dans ce mode particulier de réalisation de l'invention, on considère que le dispositif de sécurité est intégré dans l'objet connecté. Toutefois, l'architecture décrite ci-dessous s'applique également au cas où le dispositif de sécurité est externe à l'objet connecté. Il suffit alors d'ajouter une liaison de communication entre les deux dispositifs.
L’architecture générique d’un objet connecté présenté en figure 2 est composée de trois modules:
- un module de communication COM qui permet à l’objet connecté de transmettre des messages sécurisés selon n’importe quel protocole de communication. Le procédé de sécurisation décrit plus loin ne modifie pas le fonctionnement de ce module de communication.
- un module applicatif sur lequel les applications (APP1, APP2) de l’objet connecté sont installées et sur lequel ces applications s'exécutent,
- un module de sécurité (SEC), qui gère la sécurisation des données et des communications des applications de l’objet connecté. Le module de sécurité correspond par exemple au dispositif de sécurité (ESEC) décrit en relation avec la figure 1.
Le module de sécurité (SEC) comprend notamment:
- une partie d'application cryptographique (AppCrypt), cette partie comprend les algorithmes de chiffrement (AES, RSA, etc...), de déchiffrement (AES, RSA, etc, ...), les fonctions de génération de clés de chiffrement, d’ajout de clés de chiffrement et de génération d’aléas. Cette partie d'application cryptographique réalise également les calculs cryptographiques,
- une partie applicative de pilotage du procédé de sécurisation qui s'appuie notamment sur deux tables (Tab App/Cl/Algo et KCK) mémorisées dans une mémoire du dispositif de sécurité (ESEC). La table KCK comprend les clés de chiffrement des clés. Au démarrage, le dispositif de sécurité (ESEC) génère un nombre n (n étant un entier >0) de clés de chiffrement de clés. Ces clés de chiffrement de clés sont générées par le dispositif de sécurité (ESEC) lors du premier démarrage de l’objet connecté ou plus tard, au besoin, selon le nombre d’applications dans l’objet connecté et le nombre d’algorithmes supportés par le dispositif de sécurité. Ces clés de chiffrement de clé vont servir à chiffrer et déchiffrer les clés (RefKey) applicatives ou de communication stockées dans l’objet connecté. Ces clés de chiffrement de clé sont référencées KCKi sur la figure 2, i allant de 1 à n.
La table Tab App/Cl/Algo permet de faire le lien entre les références de clés de chiffrement (RefKey), les applications (IdApp) pour lesquelles les clés de chiffrement sont utilisées, les algorithmes (RefAlgo) utilisés par ces clés de chiffrement et les références de clés de chiffrement de clés (RefKCKi) permettant d'identifier quelle clé (KCKi) de chiffrement de clé a été utilisée pour chiffrer une clé de chiffrement (RefKey).
La table Tab App/Cl/Algo est créée et mise à jour au fur et à mesure des demandes de chiffrement de nouvelles clés initiées par le ou les objets connectés pour lequel le dispositif de sécurité (ESEC) met en œuvre une sécurisation.
Le module applicatif de l'objet connecté comprend au moins une application. Dans l'exemple décrit ici, le module application comprend deux application APP1, et APP2.
Chaque application, une fois installée, outre sa partie exécution, et son identité (IdApp1, IdApp2) s'appuie sur trois tables:
- une tableDCde stockage de données chiffrées : chaque type de données est par exemple chiffré avec une clé différente et chaque donnée (Dat1...Datn) est stockée avec la référence de la clé de chiffrement (RefKey1,..,RefKeyn) ayant servi à chiffrer la donnée. Cette référence est une référence permettant d'identifier la clé de chiffrement (Key1, ...Keyn) qui a servi à chiffrer la donnée. Selon un mode particulier de réalisation de l'invention, lorsqu'au moins deux applications sont installées sur le dispositif connecté, les données de chacune des deux applications sont chiffrées de manière séparée, i.e. les clés de chiffrement (Key1, ...Keyn) utilisées par chaque application ne sont pas partagées entre les applications.
- une tableCl_Ch/KCKde stockage des clés chiffrées avec une clé de chiffrement de clé (KCKn) : toutes les clés de chiffrement (applicatives et de communication, Key1, ...Keyn) sont stockées sous une forme chiffrées, ce chiffrement est réalisé au moyen d'une clé de chiffrement de clé (RefKey KCK) auxquelles seront ajoutées les références d’algorithme (RefAlgo) et les références de chaque clé de chiffrement (RefKey) générées par le dispositif de sécurité (ESEC) lors de l'ajout d'une clé de chiffrement (Key1, ...Keyn) auprès du dispositif de sécurité ESEC. Par exemple, pour l'application APP2, la cléKey0est stockée chiffrée par une clé de chiffrement de clé[Key0]KCKavec une référence à l'algorithme de chiffrement (RefAlgo) et la référenceRefKey0générée par le dispositif de sécurité lors du chiffrement de la cléKey0.
- une tableTab RefCl/Functde référence de clés/fonctions : qui permet d'identifier la clé chiffrée parmi les clés chiffrées ([Key1].... [Keyn]), via la référence de clé (RefKey) associée à cette clé et d'identifier l'algorithme de chiffrement (RefAlgo) et les données adaptées (Comm, Dat, ...), selon que ce soit une donnée à sécuriser pour la stocker sur l'objet connecté, ou un message à envoyer, ou bien de fournir la donnée ou le message au dispositif de sécurité (ESEC) afin qu'il puisse identifier la bonne clé de chiffrement de clé (KCK), et ainsi pouvoir chiffrer ou déchiffrer la clé et le message.
On présente ci-après des étapes du procédé de sécurisation selon des modes particuliers de réalisation de l'invention. L’installation des applications sur un objet connecté n'est pas détaillée ici. Dès lors qu’une application souhaite utiliser les services de sécurisation offerts par le dispositif de sécurité (ESEC), cette application est inscrite automatiquement auprès du dispositif de sécurité, comme nous le verrons par la suite.
Le principe de l'invention pour permettre la sécurisation des données des applications d'un objet connecté repose sur l'obtention par l'objet connecté une clé de chiffrement (Key) chiffrée par le dispositif de sécurité à l'aide d'une clé de chiffrement de clé (KCK) mémorisé dans le dispositif de sécurité et la mémorisation de la clé de chiffrement chiffrée ([Key]) dans la mémoire de l'objet connecté et non dans le dispositif de sécurité. Ainsi, le nombre de clé de chiffrement n'est pas limité par la mémoire du dispositif de sécurité.
Pour cela, chaque clé de chiffrement nécessaire au chiffrement des données d'une application de l'objet connecté doit être ajoutée sur le dispositif de sécurité. Par ajout, on entend un référencement de la clé de chiffrement et de l'application utilisant cette clé de chiffrement et non un stockage de la clé proprement dite sur le dispositif de sécurité.
L’ajout d’une nouvelle clé pour une application peut se faire de deux façons différentes :
- soit la clé que l’on veut ajouter est une clé servant à chiffrer des données (messages) et les communiquer (vers un serveur ou un autre objet connecté),
- soit la clé sert à chiffrer des données pour l’application elle-même (i.e. utilisation de ces données seulement par l’application).
Par convention, les clés servant à chiffrer des messages à communiquer, sont appelées ici les clés de communication, et les clés servant à chiffrer des données utilisées seulement par une application de l'objet connecté sont appelées les clés applicatives.
L'ajout d'une clé applicative ou de communication par le dispositif de sécurité est réalisé selon un même mécanisme. La figure 3 décrite plus loin présente le mécanisme d'ajout d'une clé de communication, la figure 4 présente le mécanisme d'ajout d'une clé applicative. La différence entre ces deux variantes est que dans le cas d'une clé de communication, la clé à chiffrer est fournie au dispositif de sécurité par l'application ou l'objet connecté, elle est connue de l'application. Alors que dans le cas d'une clé applicative, la clé à chiffrer est générée par le dispositif de sécurité.
A noter que, pour le procédé de sécurisation, lors de l’installation d’une application, la fonction d’ajout d’une nouvelle clé va de facto inscrire l’application.
On présente ci-après en relation avec la figure 3, l'ajout d'une nouvelle clé de communication par une application de l'objet connecté.
Il est à noter que dans le cas d’une clé servant à communiquer, il faut que le destinataire, serveur ou autre objet ou passerelle, soit capable de déchiffrer le message. La génération aléatoire n’est donc pas de mise. Il est donc supposé que la clé à ajouter est connue par l’application, via une méthode de saisie sur l’objet, soit par téléchargement par l’application, soit présente dans l’application lors de son installation.
Lors d'une étape E31, l’applicationIdApptransmet le message d’ajout de clé de communication (AddKey) au dispositif de sécurité (ESEC) avec les champs suivants :
- IdApp :identifiant de l’application donné par le dispositif de sécurité lors de l'inscription de l'application auprès du dispositif de sécurité. Dans le cas de l’ajout de la première clé de l’application, l’identifiant n’étant pas connu, ce champ sera égal à 0.
- Algo: référence d’algorithme pour lequel la clé est utilisée. La table des références d’algorithmes n’est pas présentée dans ce procédé.
- Key: la valeur de la clé à ajouter.
Lors d'une étape E32, le dispositif de sécurité vérifie que la valeur de l’identifiant de l’application (IdApp) est différente de zéro. Dans le cas où cette valeur est égale à zéro, cela signifie que l’application n’est pas connue du dispositif de sécurité. Le procédé passe alors à l'étape E33 pour créer l’identifiant de l’application (IdApp) dans le dispositif de sécurité.
Sinon, le procédé passe à l'étape E34 de vérification que l'identifiant (IdApp)est connu.
Lors de l'étape E33, l’application n'étant pas connue par le dispositif de sécurité, un identifiant d’application (IdApp) unique est généré pour cette application. Cet identifiant (IdApp) est stocké dans la table Tab App/Cl/Algo de façon définitive. Le procédé passe ensuite à l'étape E35.
Lors de l'étape E34, il est vérifié que l’identifiant de l’application (IdApp) est bien connu de la table Tab App/Cl/Algo. Si c’est le cas, le procédé passe à l'étape E35, sinon, le procédé s’arrête et un message indiquant que l’identifiant de l’application (IdApp) est inconnu est envoyé à l’application.
Lors de l'étape E35, le dispositif de sécurité vérifie que l’algorithme (Algo) indiqué est bien supporté. Si c’est le cas, le procédé passe ensuite à l'étape E36, sinon le procédé s'arrête et un message indiquant que l’algorithme (Algo) n’est pas supporté est renvoyé à l’application.
Lors d'une étape E36, le dispositif de sécurité sélectionne de façon aléatoire une référence de clé de chiffrement de clé (RefKCK) à utiliser pour chiffrer la clé (Key) envoyée dans le message.
Lors d'une étape E37, la clé reçue dans le message (Key) est chiffrée avec la clé de chiffrement de clé (KCK) correspondant à la référence (RefKCK) sélectionnée à l’étape E36. La clé (Key) chiffrée est par exemple nommée[Key]KCK. La méthode de chiffrement n’est pas imposée par le procédé. Pour des raisons de ressources et de compatibilité avec la grande majorité des dispositifs de sécurité, une méthode symétrique est à privilégier.
Lors d'une étape E38, une référence de clé (RefKey) disponible est allouée par le dispositif de sécurité à la clé chiffrée ([Key]KCK).
Selon un mode particulier de réalisation de l'invention, lorsqu'une même clé de chiffrement (KCK) est utilisée pour chiffrer deux clés (Key) distinctes, la référence de clé de chiffrement de clé (RefKey) associée à chacune des clés (Key) n'est pas la même. Autrement dit, une même clé de chiffrement de clé (KCK) peut être associée à plusieurs chiffrements de clés (Key) mais les références de clés (RefKey) seront distinctes.
Lors d'une étape E39, la référence de clé (RefKey), l’identifiant de l’application (IdApp), l’algorithme (Algo) pour lequel la clé sera utilisée ainsi que la référence de clé de chiffrement de clé (RefKCK) ayant servi à chiffrer la clé (Key) sont stockés dans la table Tab App/Cl/Algo.
Lors d'une étape E40, un message contenant l’identifiant de l’application (IdApp), la référence de clé (RefKey) et la valeur de la clé initiale chiffrée avec une clé de chiffrement de clé([Key]KCK) est renvoyé à l’application pour stockage et utilisation ultérieure.
Lors d'une étape E41, l'application de l'objet connecté mémorise dans la mémoire de l'objet connecté la référence de clé (RefKey), la valeur de la clé initiale chiffrée avec une clé de chiffrement de clé([Key]KCK) comprises dans le message reçu et une référence de l'algorithme (RefAlgo) pour lequel la clé chiffrée sera utilisée ultérieurement.
Il est à noter que, une fois que la clé initiale est reçue chiffrée([Key]KCK), la clé initiale (Key) non chiffrée, ne doit pas rester dans la mémoire de l’application. Autrement dit, suite à la réception du message lors de l'étape E40, l'application supprime de la mémoire de l'objet connecté la clé initiale (Key) non chiffrée.
De la même manière, le dispositif de sécurité ne conserve pas en mémoire la clé initiale chiffrée([Key]KCK).
On présente ci-après en relation avec la figure 4, l'ajout d'une nouvelle clé applicative par une application de l'objet connecté.
Cette clé applicative n’étant pas à utiliser pour des besoins de communication externes à l’application, mais seulement pour sécuriser des données applicatives utilisées par l'application, la clé est générée, en fonction de l’algorithme à utiliser, par le dispositif de sécurité.
Lors d'une étape E42, l'application transmet au dispositif de sécurité un message de génération de clé de chiffrement (GenerateKey) avec les champs suivants :
- IdApp :identifiant de l’application donné par le dispositif de sécurité. Comme dans l'exemple de la figure 3, dans le cas de l’ajout de la première clé de l’application, lorsque l’identifiant n'est pas connu, ce champ est égal à 0.
- Algo: référence d’algorithme pour lequel la clé générée est à utiliser. La table des références d’algorithmes n’est pas présentée dans ce procédé.
Les étapes suivantes E32-E35 sont similaires à celles présentées en relation avec la figure 3 et ne sont pas décrites à nouveau.
Lors d'une étape E43, le dispositif de sécurité génère une clé ou un jeu de clés (Key) correspondant à l’algorithme (Algo) indiqué. Puis les étapes E36-E41 sont mises en œuvre de manière identique à celles présentées en relation avec la figure 3, avec la différence que la clé à chiffrer est ici la clé générée par le dispositif de sécurité lors de l'étape E43.
De plus, selon ce mode particulier de réalisation de l'invention, une fois que la clé générée par le dispositif de sécurité est reçue chiffrée par l'application, la clé générée ne doit pas rester dans la mémoire du dispositif de sécurité. Autrement dit, après l'envoi du message lors de l'étape E40, le dispositif de sécurité supprime de sa mémoire la clé générée (Key). Le dispositif de sécurité ne conserve pas non plus en mémoire la clé générée chiffrée([Key]KCK).
On présente ci-après en relation avec les figures 5, 6 et 7 des exemples d'utilisation des clés ajoutées auprès du dispositif de sécurité par une application.
Les mécanismes présentés ci-dessous peuvent être mis en œuvre aussi pour des clés de communication que pour des clés applicatives. Le mécanisme à utiliser pour une clé est sélectionné en fonction de l'utilisation ou de la fonction à laquelle le message ou la donnée va servir.
Pour les clés de communication, les clés de communication étant utilisées pour les communications externes à l’application, les cas d’utilisation sont par exemple l'envoi d'un message vers l’extérieur ou la réception d'un message en provenance de l’extérieur. Différents mécanismes sont possibles selon que le message à envoyer ou reçu est en clair ou chiffré.
Pour les clés applicatives, les clés applicatives étant utilisées pour des besoins internes à l’application, les cas d’utilisation sont par exemple le stockage ou le traitement d'une donnée, les différents mécanismes sont utilisés selon que l’application a besoin de faire chiffrer une donnée en clair (pour stockage), de chiffrer un message chiffré (cas d’un changement de clé) ou de déchiffrer un message chiffré (pour traitement).
On présente ci-après en relation avec la figure 5 un mécanisme pour chiffrer un message ou une donnée initialement en clair. Par exemple, ce mécanisme peut être utilisé dans le cas d'un message à envoyer chiffré par l'application et qui est initialement en clair, ou dans le cas d'une donnée en clair à chiffrer pour la stocker par exemple. On présente ici le mécanisme dans le cas d'un message sortant chiffré avec une clé de communication. Il s'applique de manière identique au cas d'une donnée de l'application à chiffrer pour stockage par exemple, seule la clé de chiffrement (dans ce cas une clé applicative) change.
Lors d'une étape E50, l’application transmet un message de chiffrement d’un message (CipherMessage) au dispositif de sécurité avec les champs suivants :
- IdApp :identifiant de l’application donné par le dispositif de sécurité.
- RefKeyKCom :référence de la clé de communication fournie par le dispositif de sécurité lors de la création de cette dernière.
- [KCom]KCK :clé de communication (KCom) chiffrée avec une clé de chiffrement de clé (KCK).
- Msg :message à chiffrer.
Lors d'une étape E51, il est vérifié que l’identifiant de l’application (IdApp) est présent dans la table Tab App/Cl/Algo. Si c’est le cas, le procédé passe à l'étape E52, sinon, le procédé s’arrête et un message indiquant que l’identifiant de l’application (IdApp) est inconnu est envoyé à l’application.
Lors de l'étape E52, grâce à la référence de cléRefKeyKComet à l’identifiant de l’application (IdApp), le dispositif de sécurité récupère dans la table Tab App/Cl/Algo, la référence de clé de chiffrement de clé (RefKCK) utilisée pour le chiffrement lors de l’ajout de la cléKCom, et ainsi récupère la clé de chiffrement de clé (KCK).
Lors d'une étape E53, la cléKComest déchiffrée avec la clé de chiffrement de cléKCKassociée.
Lors d'une étape E54, l’algorithme (Algo) associé à la cléKComest récupéré dans la table Tab App/Cl/Algo.
Lors d'une étape E55, le message (Msg)est chiffré en utilisant la cléKComet l’algorithme associés.
Lors d'une étape E56, le message chiffré avec la cléKCom ([Msg]KCom) est renvoyé à l’application.
On présente ci-après en relation avec la figure 6, un mécanisme pour chiffrer avec une clé de communication un message à envoyer qui est stocké chiffré dans la mémoire de l'application.
Lors d'une étape E60, l’application transmet un message de chiffrement d’un message chiffré (CipherSecureMessage) avec une clé applicative au dispositif de sécurité avec les champs suivants :
- IdApp: identifiant de l’application donné par le dipsositif de sécurité.
- RefKeyKMsg: référence de la clé de chiffrement du message fournie par le dispositif de sécurité lors de la création de la clé applicative.
- [KMsg]KCK: clé de chiffrement du message (KCom) chiffrée avec une clé de chiffrement de clé (KCK), à utilisée pour chiffrer le message à envoyer par l'application,
- [Msg]KMsg: message chiffré avec la clé applicativeKMsg, qui doit être retourné chiffré avec la clé de communicationKCom.
- RefKeyKCom: référence de la clé de communication fournie par le dispositif de sécurité lors de l'ajout de la clé de communication auprès du dispositif de sécurité.
- [KCom]KCK: clé de communication (KCom) chiffrée avec une clé de chiffrement de clé (KCK).
Lors d'une étape E61, il est vérifié que l’identifiant de l’application (IdApp) est présent dans la table Tab App/Cl/Algo. Si c’est le cas, le procédé passe à l'étape E62, sinon, le procédé s’arrête et un message indiquant que l’identifiant de l’application (IdApp) est inconnu est envoyé à l’application.
Lors de l'étape E62, grâce à la référence de cléRefKeyKMsget à l’identifiant de l’application (IdApp), le dispositif de sécurité récupère dans la table Tab App/Cl/Algo, la référence de clé de chiffrement de clé (RefKCK) utilisée pour le chiffrement lors de l’ajout de la cléKMsg, et ainsi récupère la clé de chiffrement de clé (KCK).
Lors d'une étape E63, la cléKMsgest déchiffrée avec la clé de chiffrement de cléKCKassociée.
Lors d'une étape E64, l’algorithme (Algo) associé à la cléKMsgest récupéré dans la table Tab App/Cl/Algo.
Lors d'une étape E65, le messageMsgest déchiffré en utilisant la cléKMsget l’algorithme associés.
Lors d'une étape E66, grâce à la référence de cléRefKeyKComet à l’identifiant de l’application (IdApp), le dispositif de sécurité récupère dans la table Tab App/Cl/Algo, la référence de clé de chiffrement de clé (RefKCK) utilisée pour le chiffrement lors de l’ajout de la cléKCom, et ainsi récupère la clé de chiffrement de clé (KCK).
Lors d'une étape E67, la cléKComest déchiffrée avec la clé de chiffrement de cléKCKassociée.
Lors d'une étape E68, l’algorithme (Algo) associé à la cléKComest récupéré dans la table Tab App/Cl/Algo.
Lors d'une étape E69, le messageMsgest chiffré en utilisant la cléKComet l’algorithme associés.
Lors d'une étape E70, le message chiffré avec la cléKCom ([Msg]KCom)est renvoyé à l’application.
Le mécanisme décrit ci-dessus peut également être utilisé avec une clé applicative pour chiffrer un message ou une donnée qui est stocké chiffré dans la mémoire de l'application, par exemple dans le cas d'un changement de clé applicative. Dans ce cas, le message reçu lors de l'étape E60 est un message de déchiffrement (DecipherSecureMessage)comprenant:
- l'identifiant de l’application donné par le dispositif de sécurité (IdApp),
- la référence de la clé applicative (RefKeyKMsg1)fournie par le dispositif de sécurité lors de la création de la clé applicativeKMsg1par le dispositif de sécurité et qui a servi à chiffrer le message ou la donnée utilisé par l'application,
- la clé applicative (KMsg1) chiffrée ([KMsg1]KCK)avec une clé de chiffrement de clé (KCK),
- le message ou la donnée chiffré([Msg1]KMsg1) avec la clé applicativeKMsg1. Le dispositif de sécurité doit déchiffrer ce message ou donnée et le chiffrer avec une nouvelle clé applicativeKMsg2pour le retourner chiffré à l'application,
- la référenceRefKeyKMsg2de la clé applicative fournie par le dispositif de sécurité lors de la création de la clé applicativeKMsg2par le dispositif de sécurité,
- la clé applicative (KMsg2) chiffrée ([KMsg2]KCK) avec une clé de chiffrement de clé (KCK).
Le mécanisme décrit ci-dessus en relation avec la figure 6 peut également s'appliquer dans le cas d'un message reçu chiffré par l'application et à retourner chiffré à l'application pour stockage par exemple. Dans ce cas, le message reçu lors de l'étape E60 est un message de déchiffrement (DecipherSecureMessage)comprenant l'identifiant de l’application donné par le dispositif de sécurité (IdApp), la référence de la clé de communication (RefKeyKCom)fournie par le dispositif de sécurité lors de l'ajout de la clé de communicationKComauprès du dispositif de sécurité et qui a servi à chiffrer le message reçu par l'application, la clé de communication (KCom) chiffrée ([KCom]KCK)avec une clé de chiffrement de clé (KCK), le message reçu chiffré([Msg]KCom) avec la clé de communicationKCom. Le dispositif de sécurité doit déchiffrer le message reçu et le chiffrer avec la clé applicativeKMsgpour le retourner chiffré à l'application, la référenceRefKeyKMsgde la clé applicative fournie par le dispositif de sécurité lors de la création de la clé applicationKMsgpar le dispositif de sécurité, la clé applicative (KMsg) chiffrée ([KMsg]KCK) avec une clé de chiffrement de clé (KCK).
On présente ci-après en relation avec la figure 7, un mécanisme pour déchiffrer un message entrant chiffré, ie. reçu chiffré par l'application, et à retourner en clair (déchiffré) à l'application pour traitement par l'application.
Lors d'une étape E71, l’application transmet un message de déchiffrement d’un message à déchiffrer (DecipherMessage) avec une clé de communication au dispositif de sécurité avec les champs suivants :
- IdApp: identifiant de l’application donné par le dispositif de sécurité.
- RefKeyKCom: référence de la clé de communication fournie par le dispositif de sécurité lors de l'ajout de la clé de communication (KCom)auprès du dispositif de sécurité,
- [KCom]KCK: clé de communication (KCom) chiffrée avec une clé de chiffrement de clé (KCK),
- [Msg]KCom: message chiffré avec la clé de communicationKComà retourner déchiffré à l'application.
Lors d'une étape E72, il est vérifié que l’identifiant de l’application (IdApp) est présent dans la table Tab App/Cl/Algo. Si c’est le cas, le procédé passe à l'étape E73, sinon, le procédé s’arrête et un message indiquant que l’identifiant de l’application (IdApp) est inconnu est envoyé à l’application.
Lors de l'étape E73, grâce à la référence de cléRefKeyKComet à l’identifiant de l’application (IdApp), le dispositif de sécurité récupère dans la table Tab App/Cl/Algo, la référence de clé de chiffrement de clé (RefKCK) utilisée pour le chiffrement lors de l’ajout de la cléKCom, et ainsi récupère la clé de chiffrement de clé (KCK).
Lors d'une étape E74, la cléKComest déchiffrée avec la clé de chiffrement de cléKCKassociée.
Lors d'une étape E75, l’algorithme (Algo) associé à la cléKComest récupéré dans la table Tab App/Cl/Algo.
Lors d'une étape E76, le messageMsgest déchiffré en utilisant la cléKComet l’algorithme associés.
Lors d'une étape E77, le message déchiffréMsgest renvoyé à l’application.
Le mécanisme décrit ci-dessus en relation avec la figure 7 peut également s'appliquer dans le cas d'un message stocké chiffré par l'application et à retourner déchiffré à l'application pour traitement par exemple. Dans ce cas, seule la clé pour déchiffrer le message change, il s'agit ici d'une clé applicative.
La figure 8 illustre de manière simplifiée un exemple d'architecture d'un dispositif connecté selon l'un quelconque des modes particuliers de réalisation de l’invention décrits précédemment.
Selon un mode particulier de réalisation de l'invention, le dispositif OBJ a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions permettant le fonctionnement du dispositif connecté OBJ, lorsque le programme PG est exécuté par le processeur PROC.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC.
La mémoire MEM comprend également au moins un programme d'ordinateur APP1 comprenant des instructions de mise en œuvre d'une application assurant un service fournie à l'utilisateur par le dispositif connectée. L'application APP1 peut être téléchargée depuis un réseau de données par le dispositif de sécurité et installée sur le dispositif de sécurité. Lors du lancement de l'application APP1, au démarrage du dispositif connecté OBJ ou bien sur instruction de l'utilisateur via une interface utilisateur UI du dispositif connecté OBJ, les instructions de code du programme d'ordinateur APP1 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de sécurisation selon l'un quelconque de modes particuliers de réalisation décrits en relation avec les figures 2 à 7, selon les instructions du programme d'ordinateur APP1, et en coopération avec un dispositif de sécurité (ESEC).
Le dispositif OBJ comprend un module de communication COM configuré pour communiquer avec un serveur, ou d'autres objets connectés via un réseau de données.
Selon un mode particulier de réalisation de l'invention, le dispositif OBJ comprend une interface utilisateur UI permettant à un utilisateur d'interagir sur le dispositif OBJ.
Selon un mode particulier de réalisation de l'invention, le dispositif OBJ comprend un dispositif de sécurité (ESEC) tel que décrit ci-dessous.
Selon un mode particulier de réalisation de l'invention, le dispositif connecté OBJ décrit précédemment est compris dans un terminal.
La figure 9 illustre de manière simplifiée un exemple d'architecture d'un dispositif de sécurité selon l'un quelconque des modes particuliers de réalisation de l’invention décrits précédemment.
Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité ESEC comprend notamment une mémoire MSEC, une unité de traitement UT2, équipée par exemple d'un microprocesseur PROC2, et pilotée par le programme d'ordinateur PG2 stocké en mémoire MSEC. Le programme d'ordinateur PG2 comprend des instructions pour mettre en œuvre les étapes du procédé de sécurisation tel que décrit précédemment en coopération avec le dispositif connecté OBJ, lorsque le programme est exécuté par le processeur PROC2.
A l'initialisation, les instructions de code du programme d'ordinateur PG2 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC2. Le processeur PROC2 de l'unité de traitement UT2 met notamment en œuvre les étapes du procédé de sécurisation selon l'un quelconque de modes particuliers de réalisation décrits en relation avec les figures 2-7, selon les instructions du programme d'ordinateur PG2.
Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité ESEC comprend un module de communication COM2 configuré pour communiquer avec le dispositif connecté OBJ via un réseau de données ou une liaison de connexion interne lorsque le dispositif de sécurité est intégré dans le dispositif connecté.
Selon un mode particulier de réalisation de l'invention, le dispositif ESEC décrit précédemment est compris dans un objet connecté, ou une passerelle domestique, ou un terminal.
Selon un mode particulier de réalisation de l'invention, le dispositif ESEC décrit précédemment est de type carte à puce.
Claims (15)
- Procédé de sécurisation d'au moins une donnée d'une application installée sur un dispositif connecté (OBJ) à un réseau de données, le dispositif connecté étant configuré pour communiquer avec un dispositif de sécurité (ESEC) configuré pour chiffrer ou déchiffrer (E55, E69, E76) ladite au moins une donnée à l'aide d'une clé de chiffrement, le procédé de sécurisation est caractérisé en ce qu'il comprend:
- l'obtention (E40) par le dispositif connecté de ladite clé de chiffrement sous une forme chiffrée (E37) à l'aide d'une clé de chiffrement de clé mémorisée dans ledit dispositif de sécurité,
- la mémorisation (E41) de ladite clé de chiffrement chiffrée dans une mémoire du dispositif connecté, la mémoire dudit dispositif connecté étant distincte de la mémoire du dispositif de sécurité. - Procédé de sécurisation selon la revendication 1, dans lequel la clé de chiffrement chiffrée est mémorisée dans la mémoire du dispositif connecté en association avec une référence de clé générée par le dispositif de sécurité, ladite référence de clé étant associée, dans le dispositif de sécurité, à la clé de chiffrement de clé ayant servie à chiffrer ladite clé de chiffrement.
- Procédé de sécurisation selon la revendication 2, dans lequel, lorsqu'une même clé de chiffrement de clé est utilisée pour chiffrer au moins une première clé de chiffrement et une deuxième clé de chiffrement, la référence de clé générée par le dispositif de sécurité et associée à la première clé de chiffrement est distincte de la référence de clé générée par le dispositif de sécurité et associée à la deuxième clé de chiffrement.
- Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, comprenant en outre la fourniture (E31) au dispositif de sécurité de ladite clé de chiffrement à chiffrer.
- Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, comprenant en outre la génération (E43) par le dispositif de sécurité de ladite clé de chiffrement.
- Procédé de sécurisation selon la revendication 5, comprenant en outre, lorsque ladite clé de chiffrement chiffrée est transmise au dispositif connecté, la suppression (E40) de ladite clé de chiffrement et de la clé de chiffrement chiffrée de la mémoire du dispositif de sécurité.
- Procédé de sécurisation selon l'une quelconque des revendications 1 à 6, dans lequel lorsqu'au moins deux applications sont installées sur ledit dispositif connecté, les données de chacune des au moins deux applications sont chiffrées à l'aide de deux clés de chiffrement distinctes.
- Procédé de sécurisation selon l'une quelconque des revendications 2 à 7, comprenant en outre:
- la transmission par le dispositif connecté au dispositif de sécurité, de ladite donnée à chiffrer ou à déchiffrer, de la clé de chiffrement chiffrée et de la référence de clé mémorisée avec la clé de chiffrement chiffrée,
- l'obtention, par le dispositif de sécurité, d'une clé de chiffrement de clé, à l'aide de la référence de clé,
- le déchiffrement, par le dispositif de sécurité, de la clé chiffrée, à l'aide de la clé de chiffrement de clé obtenue,
- le chiffrement ou le déchiffrement, par le dispositif de sécurité, de la donnée à l'aide de la clé déchiffrée,
- la transmission au dispositif connecté par le dispositif de sécurité, de ladite donnée chiffrée ou déchiffrée,
- la suppression de la mémoire du dispositif de sécurité de ladite clé de chiffrement chiffrée. - Dispositif connecté (OBJ) à un réseau de données, le dispositif connecté comprenant au moins une mémoire (MEM) et un processeur (PROC) configurés pour exécuter au moins une application (APP1), le dispositif connecté est configuré pour communiquer avec un dispositif de sécurité (ESEC) configuré pour chiffrer ou déchiffrer au moins une donnée de ladite application à l'aide d'une clé de chiffrement, le dispositif connecté est caractérisé en ce qu'il est configuré pour mémoriser ladite clé de chiffrement dans ladite mémoire du dispositif connecté sous une forme chiffrée, ladite clé de chiffrement ayant été chiffrée par ledit dispositif de sécurité à l'aide d'une clé de chiffrement de clé, la clé de chiffrement de clé étant mémorisée dans une mémoire (MSEC) du dispositif de sécurité (ESEC), ladite mémoire du dispositif connecté étant distincte de ladite mémoire (MEM) du dispositif de sécurité.
- Dispositif connecté selon la revendication 9, dans lequel le dispositif de sécurité est compris dans le dispositif connecté.
- Dispositif de sécurité (ESEC) configuré pour communiquer avec un dispositif connecté (OBJ) à un réseau de données, le dispositif connecté étant configuré pour exécuter au moins une application, le dispositif de sécurité comprend une mémoire (MSEC) et un processeur (PROC2) configurés pour chiffrer ou déchiffrer au moins une donnée de ladite application à l'aide d'une clé de chiffrement, le dispositif de sécurité est caractérisé en ce qu'il est configuré pour mémoriser au moins une clé de chiffrement de clé dans la mémoire (MSEC) du dispositif de sécurité (ESEC) , et en ce que la mémoire (MSEC) et le processeur (PROC2) sont configurés pour:
- chiffrer ou déchiffrer au moins ladite clé de chiffrement à l'aide de ladite au moins une clé de chiffrement de clé,
- transmettre ladite clé de chiffrement chiffrée au dispositif connecté. - Dispositif de sécurité selon la revendication 11, compris dans un élément de sécurité physique de type carte à puce.
- Système de sécurisation d'au moins une donnée d'une application installée sur un dispositif connecté à un réseau de données, le système comprend au moins un dispositif connecté selon la revendication 9 et au moins un dispositif de sécurité selon l'une quelconque des revendications 11 ou 12.
- Programme comportant des instructions pour la mise en œuvre du procédé de sécurisation selon l’une quelconque des revendications 1 à 8, lorsque ledit programme est exécuté par un processeur.
- Support lisible par ordinateur comportant un programme selon la revendication 14.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1904983A FR3096161B1 (fr) | 2019-05-14 | 2019-05-14 | Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1904983A FR3096161B1 (fr) | 2019-05-14 | 2019-05-14 | Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. |
| FR1904983 | 2019-05-14 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3096161A1 true FR3096161A1 (fr) | 2020-11-20 |
| FR3096161B1 FR3096161B1 (fr) | 2021-09-24 |
Family
ID=67742757
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1904983A Active FR3096161B1 (fr) | 2019-05-14 | 2019-05-14 | Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3096161B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112528342A (zh) * | 2020-12-29 | 2021-03-19 | 内蒙古工业大学 | 一种基于编译中间结果的软件保护方法 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110131421A1 (en) * | 2009-12-02 | 2011-06-02 | Fabrice Jogand-Coulomb | Method for installing an application on a sim card |
| US20140037093A1 (en) * | 2012-08-06 | 2014-02-06 | Samsung Electronics Co., Ltd. | Method of managing key for secure storage of data and apparatus therefor |
| US20170279613A1 (en) * | 2016-03-28 | 2017-09-28 | Symantec Corp | Systems and methods for managing encryption keys for single-sign-on applications |
-
2019
- 2019-05-14 FR FR1904983A patent/FR3096161B1/fr active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110131421A1 (en) * | 2009-12-02 | 2011-06-02 | Fabrice Jogand-Coulomb | Method for installing an application on a sim card |
| US20140037093A1 (en) * | 2012-08-06 | 2014-02-06 | Samsung Electronics Co., Ltd. | Method of managing key for secure storage of data and apparatus therefor |
| US20170279613A1 (en) * | 2016-03-28 | 2017-09-28 | Symantec Corp | Systems and methods for managing encryption keys for single-sign-on applications |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112528342A (zh) * | 2020-12-29 | 2021-03-19 | 内蒙古工业大学 | 一种基于编译中间结果的软件保护方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3096161B1 (fr) | 2021-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9537918B2 (en) | File sharing with client side encryption | |
| EP1909462B1 (fr) | Procédé de mise à disposition cloisonnée d'un service électronique | |
| FR3009159A1 (fr) | Procede de traitement de donnees de geolocalisation | |
| EP3308496B1 (fr) | Système, appareil et procédé pour assurer la coordination d'un point de rencontre de dispositifs répartis utilisant le multiplexage d'entropie | |
| FR3044132A1 (fr) | Procede d'identification anonyme d'un module de securite | |
| FR3013541A1 (fr) | Procede et dispositif pour la connexion a un service distant | |
| EP3456025B1 (fr) | Technique d'authentification d'un dispositif utilisateur | |
| EP1958371A2 (fr) | Recouvrement de cles de dechiffrement perimees | |
| EP1883257A1 (fr) | Procédé de synchronisation entre un equipement mobile et une carte a puce | |
| FR3096161A1 (fr) | Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. | |
| EP3278542B1 (fr) | Système et procédé d'exécution d'une application dans un terminal muni d'une carte a puce | |
| WO2019243706A1 (fr) | Procédé de découverte de fonctions intermédiaires et de sélection d'un chemin entre deux équipements de communication | |
| EP3667530A1 (fr) | Accès sécurise à des données chiffrées d'un terminal utilisateur | |
| EP4078922B1 (fr) | Procédé d'obtention d'une commande relative à un profil d'accès réseau d'un module de sécurité de type euicc | |
| EP3824676A1 (fr) | Dispositifs et procedes de gestion d'un attachement d'un dispositif de communication a un reseau d'un operateur | |
| WO2023083770A1 (fr) | Procédé de recherche de données sensibles dans au moins un paquet de données, dispositif et système associés | |
| FR2813151A1 (fr) | Communication securisee dans un equipement d'automatisme | |
| FR3065606A1 (fr) | Procedes pour le partage de donnees de localisation entre un dispositif source et un dispositif destinataire, serveur, dispositifs source et destinataire et programme d'ordinateur correspondants. | |
| US11637819B2 (en) | Establishing connectivity between user devices | |
| WO2023062095A1 (fr) | Procédé et dispositif de transfert d'une communication d'une station de base à une autre | |
| WO2017077201A1 (fr) | Technique d'accès a un dispositif peripherique | |
| FR3037167A1 (fr) | Procede de provisionnement d'un script d'installation a un module securise, module securise et serveur de provisionnement | |
| FR3135805A1 (fr) | Procédé de gestion de profils de service d’un élément sécurisé | |
| EP3110109A1 (fr) | Procédé et dispositif de mise à jour des capacités d'un objet connecté à un réseau de communications | |
| FR3042362A1 (fr) | Moyens de gestion d'acces a des donnees |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20201120 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |