Brevet FR3096161A1 — publié le 20201120

Description Titre de l'invention : Procédé, dispositif et système de sécurisation de données et de clés de chiffrement d'un objet connecté. [0001] 1. Domaine de l'invention [0002] 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 oeuvre au sein d'un objet connecté ainsi que la sécurisation des clés de chiffrement associées à ces données. [0003] 2. Art Antérieur [0004] 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 cux, 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.). [0005] 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. [0006] 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. [0007] 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. [0008] 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... [0009] 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é. [0010] Il existe donc un besoin de gérer la sécurisation des communications de plusieurs ap- plications d'un objet connecté de façon différente et de faire évoluer le nombre 2 d'applications gérées par un objet connecté au fil de l'eau. [0011] Sécuriser les communications est une chose, mais lorsque l'objet connecté est sus- ceptible d'être accessible physiquement ou via le chargement involontaire d'un malwarc, les données stockées sur l'objet connecté par les applications peuvent être récupérées et lisibles. [0012] Il existe donc également un besoin de stocker les données des applications d'un objet connecté de façon sécurisée. [0013] 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 dc 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. [0014] Il existe donc un besoin d'améliorer l'état de la technique. [0015] 3. Exposé de l'invention [0016] 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 dc sécurité configuré pour chiffrer ou déchiffrer ladite au moins une donnée à l'aide d'une clé dc chiffrement. Avantageusement, le procédé de sécurisation comprend: [0017] - 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é, [0018] - 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é. [0019] Selon l'invention, les clés de chiffrement utilisées pour chiffrer les données d'une ap- plication 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. [0020] 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 oeuvre 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. [0021] 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é. [0022] De plus, selon l'invention, les clés de chiffrement sont mémorisées chiffrées et non 3 en clair dans la mémoire du dispositif connecté. Ainsi, les clés de chiffrement ne sont pas directement accessibles à des applications malveillantes. [0023] De plus, les calculs de chiffrement (calculs cryptographiques) sont réalisés dans le dispositif de sécurité, qui est un support sécurisé. [0024] 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. [0025] 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é. [0026] 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. [0027] 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. [0028] Selon un autre mode particulier de réalisation de l'invention, le procédé de sécu- risation 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. [0029] Selon un autre mode particulier de réalisation de l'invention, le procédé de sécu- risation 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é. [0030] Selon un autre mode particulier de réalisation de l'invention, le procédé de sécu- risation 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. [0031] 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é. [0032] 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é. [0033] Selon un autre mode particulier de réalisation de l'invention, le procédé de sécu- risation comprend en outre: [0034] - 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, [0035] - l'obtention, par le dispositif de sécurité, d'une clé de chiffrement de clé, à l'aide de la référence de clé, [0036] - le déchiffrement, par le dispositif de sécurité, de la clé chiffrée, à l'aide de la clé de chiffrement de clé obtenue, [0037] - le chiffrement ou le déchiffrement, par le dispositif de sécurité, de la donnée à l'aide de la clé déchiffrée, [0038] - la transmission au dispositif connecté par le dispositif de sécurité, de ladite donnée chiffrée ou déchiffrée, [0039] - la suppression de la mémoire du dispositif de sécurité de ladite clé de chiffrement chiffrée. [0040] 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é. [0041] 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é. [0042] Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité est compris dans le dispositif connecté. [0043] L'invention concerne également un dispositif de sécurité configuré pour com- muniquer 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: [0044] - chiffrer ou déchiffrer au moins ladite clé de chiffrement à l'aide de ladite au moins une clé de chiffrement de clé, [0045] - transmettre ladite clé de chiffrement chiffrée au dispositif connecté. [0046] 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. [0047] 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. [0048] 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é. 6 [0049] 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. [0050] L'invention concerne également un programme d'ordinateur comportant des ins- tructions pour la mise en oeuvre 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 oeuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. [0051] Cc 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. [0052] 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. [0053] 4. Liste des figures [0054] 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 : [0055] [fig.1] La figure 1 illustre un environnement de mise en oeuvre de l'invention selon un mode particulier de réalisation de l'invention, [0056] [fig.2] La figure 2 illustre un exemple d'architecture d'un objet connecté selon un mode particulier de réalisation de l'invention, [0057] [fig.3] La figure 3 illustre des étapes du procédé de sécurisation selon un mode par- ticulier de réalisation de l'invention, 7 [0058] [fig.4] La figure 4 illustre des étapes du procédé de sécurisation selon un autre mode particulier de réalisation de l'invention, [0059] [fig.5] La figure 5 illustre des étapes du procédé de sécurisation selon un autre mode particulier de réalisation de l'invention, [0060] [fig.6] La figure 6 illustre des étapes du procédé de sécurisation selon un autre mode particulier de réalisation de l'invention, [0061] [fig.7] La figure 7 illustre des étapes du procédé de sécurisation selon un autre mode particulier de réalisation de l'invention, [0062] [fig.8] La figure 8 illustre de manière simplifiée un exemple d'architecture d'un dispositif connecté selon un mode particulier de réalisation de l'invention, [0063] [fig.9] La figure 9 illustre de manière simplifiée un exemple d'architecture d'un dispositif de sécurité selon un mode particulier de réalisation de l'invention. [0064] 5. Description d'un mode de réalisation de l'invention [0065] La figure 1 illustre un exemple d'environnement de mise en oeuvre 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 stnartphone, 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é. [0066] L'environnement de mise en oeuvre 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 oeuvre 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. [0067] Dans d'autres exemples de mise en oeuvre 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é. [0068] 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 oeuvre dans un serveur ou dans un objet connecté. [0069] Le dispositif de sécurité (ESEC) et l'objet connecté (OBJ) sont configurés pour mettre en oeuvre 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 8 procédé permet, notamment: [0070] - de faire communiquer les applications présentes sur un objet connecté (OBJ) dc manière sécurisée, et quel que soit le mode de communication employé (Ziglice, NEC, Wifi, 4G...), [0071] - 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), [0072] - d'assurer un stockage sécurisé des clés de chiffrement applicativcs et de commu- nication à utiliser par les applications de l'objet connecté (OBJ), grâce au dispositif de sécurité (ESEC), mais sans les stocker dans le dispositif dc sécurité (ESEC), [0073] - d'assurer une sécurisation différente (clés de chiffrement différentes et/ou al- gorithmes 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, [0074] - de pouvoir faire évoluer le nombre d'applications sécurisées par le dispositif de sécurité de façon simple, [0075] - de pouvoir gérer le cycle de vie des différentes clés de chiffrement. [0076] Dans d'autres exemples de mise en oeuvre 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. [0077] La figure 2 illustre un exemple d'architecture d'un objet connecté selon un mode par- ticulier 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. [0078] L'architecture générique d'un objet connecté présenté en figure 2 est composée de trois modules: [0079] - 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é con-espond par exemple au dispositif de sécurité (ESEC) décrit en relation avec la figure 1. [0080] Le module de sécurité (SEC) comprend notamment: [0081] - une partie d'application cryptographique (AppCrypt), cette partie comprend les al- 9 gorithmcs de chiffrement (AES, RSA, dc déchiffrement (AES, RSA, etc, ...), les fonctions de génération de clés de chiffrement, d'ajout de clés de chiffrement et dc génération d'aléas. Cette partie d'application cryptographique réalise également les calculs cryptographiques, [0082] - une partie applicativc 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) dc clés de chiffrement de clés. Ces clés de chiffrement de clés sont générées par le dispositif dc 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 dc 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. [0083] La table Tab App/Cl/Algo permet de faire le lien entre les références de clés de chiffrement (RefKcy), 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 (RcfKCKi) permettant d'identifier quelle clé (KCKi) de chiffrement de clé a été utilisée pour chiffrer une clé de chiffrement (RefKey). [0084] 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 oeuvre une sécurisation. [0085] Le module applicatif de l'objet connecté comprend au moins une application. Dans l'exemple décrit ici, le module application comprend deux application APPI, et APP2. [0086] Chaque application, une fois installée, outre sa partie exécution, et son identité (IdAppl, IdApp2) s'appuie sur trois tables: [0087] une table DC de stockage de données chiffrées : chaque type de données est par exemple chiffré avec une clé différente et chaque donnée (Datl...Datn) est stockée avec la référence de la clé de chiffrement (RefKeyl,..,RefKeyn) ayant servi à chiffrer la donnée. Cette référence est une référence permettant d'identifier la clé de chiffrement (Key 1, ...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 (Keyl, ...Keyn) utilisées par chaque application ne sont pas partagées entre les applications. une table Cl Ch/KCK de stockage des clés chiffrées avec une clé de chiffrement de clé (KCKn) : toutes les clés de chiffrement (applicativcs et de communication, Kcyl, ...Kcyn) 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 (Kcyl, ...Kcyn) auprès du dispositif de sécurité ESEC. Par exemple, pour l'application APP2, la clé Key() est stockée chiffrée par une clé de chiffrement de clé [KeyO]KCK avec une référence à l'algorithme de chiffrement (RefAlgo) et la référence RefKey0 générée par le dispositif de sécurité lors du chiffrement de la clé KeyO. une table Tab RefCl/Funct de référence de clés/fonctions : qui permet d'identifier la clé chiffrée parmi les clés chiffrées ([Kcyl].... [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. [0088] On présente ci-après des étapes du procédé de sécurisation selon des modes par- ticuliers 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. [0089] 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é. [0090] Pour cela, chaque clé de chiffrement nécessaire au chiffrement des données d'une ap- plication 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é. [0091] L'ajout d'une nouvelle clé pour une application peut se faire de deux façons dif- férentes : 11 [0092] - 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.c. utilisation de ces données seulement par l'application). [0093] 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. [0094] 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é. [0095] 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. [0096] On présente ci-après en relation avec la figure 3, l'ajout d'une nouvelle clé de com- munication par une application de l'objet connecté. [0097] Il est à noter que dans le cas d'une clé servant à communiquer, il faut que le des- tinataire, 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. [0098] Lors d'une étape E31, l'application IdApp transmet le message d'ajout de clé de com- munication (AddKey) au dispositif de sécurité (ESEC) avec les champs suivants : [0099] 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. Afro : 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. [0100] 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é. 12 [0101] Sinon, le procédé passe à l'étape E34 de vérification que l'identifiant (IdApp) est connu. [0102] 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/C1/Algo de façon définitive. Le procédé passe ensuite à l'étape E35. [0103] 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. [0104] 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. [0105] 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. [0106] 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 [KeyJKCK. 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. [0107] Lors d'une étape E38, une référence de clé (RetKey) disponible est allouée par le dispositif de sécurité à la clé chiffrée ([KeyJKCK). [0108] 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é (RdKey) 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 (RelKey) seront distinctes. [0109] Lors d'une étape E39, la référence de clé (RelKey), 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. [0110] Lors d'une étape E40, un message contenant l'identifiant de l'application (IdApp), la référence de clé (RelKey) et la valeur de la clé initiale chiffrée avec une clé de chiffrement de clé a KevIKCK) est renvoyé à l'application pour stockage et utilisation 13 ultérieure. [0111] 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é ([Key1KCK) 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. [0112] Tl 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. [0113] De la même manière, le dispositif de sécurité ne conserve pas en mémoire la clé initiale chiffrée ([Key1KCK). [0114] On présente ci-après en relation avec la figure 4, l'ajout d'une nouvelle clé applicativc par une application de l'objet connecté. [0115] Cette clé applicativc n'étant pas à utiliser pour des besoins de communication externes à l'application, mais seulement pour sécuriser des données applicativcs utilisées par l'application, la clé est générée, en fonction de l'algorithme à utiliser, par le dispositif de sécurité. [0116] 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 : [0117] 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é. [0118] Les étapes suivantes E32-E35 sont similaires à celles présentées en relation avec la figure 3 et ne sont pas décrites à nouveau. [0119] 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 oeuvre 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. [0120] 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 ([KeyJKCK). 14 [0121] 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. [0122] Les mécanismes présentés ci-dessous peuvent être mis en oeuvre aussi pour des clés de communication que pour des clés applicativcs. 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. [0123] 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é. [0124] Pour les clés applicativcs, les clés applicativcs é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). [0125] 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. [0126] 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 : [0127] - IdApp : identifiant de l'application donné par le dispositif de sécurité. RelKeyKCom : 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 [0128] Lors d'une étape E51, il est vérifié que l'identifiant de l'application (IdApp) est présent dans la table Tab App/CUAlgo. 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. [0129] Lors de l'étape E52, grâce à la référence de clé RefKeyKCom et à l'identifiant de l'application (IdApp), le dispositif de sécurité récupère dans la table Tah App/CUAlgo, 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). [0130] Lors d'une étape E53, la clé KCom est déchiffrée avec la clé de chiffrement de clé KCK associée. [0131] Lors d'une étape E54, l'algorithme (Algo) associé à la clé KCom est récupéré dans la table Tab App/CUAlgo. [0132] Lors d'une étape E55, le message (Msg) est chiffré en utilisant la clé KCom et l'algorithme associés. [0133] Lors d'une étape E56, le message chiffré avec la clé KCorn((M.sgIKCom) est renvoyé à l'application. [0134] 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. [0135] Lors d'une étape E60, l'application transmet un message de chiffrement d'un message chiffré (CipherSeeureMessage) avec une clé applicative au dispositif de sécurité avec les champs suivants : [0136] 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é applicativc. [KMsgJKCK : 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é applicative KMsg, qui doit être retourné chiffré avec la clé de communication KCom. RelKeyKCom : 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). [0137] Lors d'une étape E61, il est vérifié que l'identifiant de l'application (IdApp) est présent dans la table Tab App/CUAlgo. 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. [0138] Lors de l'étape E62, grâce à la référence de clé RefKeyKMsg et à l'identifiant de l'application (IdApp), le dispositif de sécurité récupère dans la table Tab App/CUAlgo, la référence de clé de chiffrement de clé (RetKCK) 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). 16 [0139] Lors d'une étape E63, la clé KMsg est déchiffrée avec la clé de chiffrement de clé KCK associée. [0140] Lors d'une étape E64, l'algorithme (Algo) associé à la clé KMsg est récupéré dans la table Tab App/Cl/Algo. [0141] Lors d'une étape E65, le message Msg est déchiffré en utilisant la clé KMsg et l'algorithme associés. [0142] Lors d'une étape E66, grâce à la référence de clé RefKeyKCont et à l'identifiant de l'application (IclApp), le dispositif de sécurité récupère dans la table Tah 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). [0143] Lors d'une étape E67, la clé KCom est déchiffrée avec la clé de chiffrement de clé KCK associée. [0144] Lors d'une étape E68, l'algorithme (Algo) associé à la clé KCom est récupéré dans la table Tab App/Cl/Algo. [0145] Lors d'une étape E69, le message Msg est chiffré en utilisant la clé KCom et l'algorithme associés. [0146] Lors d'une étape E70, le message chiffré avec la clé KCom([Msg.IKCoin) est renvoyé à l'application. [0147] 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: [0148] - l'identifiant de l'application donné par le dispositif de sécurité (IdApp), [0149] - la référence de la clé applicative (RelKeyKMsgl ) fournie par le dispositif de sécurité lors de la création de la clé applicative KMsgl par le dispositif de sécurité et qui a servi à chiffrer le message ou la donnée utilisé par l'application, [0150] - la clé applicative (KMsgl) chiffrée ([KMsgl JKCK) avec une clé de chiffrement de clé (KCK), [0151] - le message ou la donnée chiffré ([Msgl JKMsg1) avec la clé applicative KMsgl. Le dispositif de sécurité doit déchiffrer ce message ou donnée et le chiffrer avec une nouvelle clé applicative KMsg2 pour le retourner chiffré à l'application, [0152] - la référence RefKeyKMsg2 de la clé applicative fournie par le dispositif de sécurité lors de la création de la clé applicative KMsg2 par le dispositif de sécurité, [0153] - la clé applicative (KMsg2) chiffrée ([KMsg2JKCK) avec une clé de chiffrement de clé (KCK). [0154] 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é pal- l'application et à retourner chiffré à 17 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 (RefKeyKConz) fournie par le dispositif de sécurité lors de l'ajout de la clé de communication KCom auprè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 ( [KComJICCK) avec une clé de chiffrement de clé (KCK), le message reçu chiffré ((Msg1KCom) avec la clé de communication KCom. Le dispositif de sécurité doit déchiffrer le message reçu et le chiffrer avec la clé applicative KMsg pour le retourner chiffré à l'application, la référence RefKeyKMsg de la clé applicative fournie par le dispositif de sécurité lors de la création de la clé application KMsg par le dispositif de sécurité, la clé applicative (KMsg) chiffrée ((KMsglICCK) avec une clé de chiffrement de clé (KCK). [0155] 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. [0156] 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 : [0157] IdApp : identifiant de l'application donné par le dispositif de sécurité. RelKeyKCom : 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), [MsgIKCom : message chiffré avec la clé de communication KCom à retourner déchiffré à l'application. [0158] Lors d'une étape E72, il est vérifié que l'identifiant de l'application (IdApp) est présent dans la table Tab App/CUAlgo. 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. [0159] Lors de l'étape E73, grâce à la référence de clé RefKeyKCom et à l'identifiant de l'application (IdApp), le dispositif de sécurité récupère dans la table Tab App/CUAlgo, la référence de clé de chiffrement de clé (RetKCK) 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). [0160] Lors d'une étape E74, la clé KCom est déchiffrée avec la clé de chiffrement de clé KCK associée. [0161] Lors d'une étape E75, l'algorithme (Algo) associé à la clé KCom est récupéré dans la 18 table Tab App/Cl/Algo. [0162] Lors d'une étape E76, le message Msg est déchiffré en utilisant la clé KCorn et l'algorithme associés. [0163] Lors d'une étape E77, le message déchiffré Msg est renvoyé à l'application. [0164] 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. [0165] 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. [0166] 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. [0167] 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. [0168] La mémoire MEM comprend également au moins un programme d'ordinateur APPI comprenant des instructions de mise en oeuvre d'une application assurant un service fournie à l'utilisateur par le dispositif connectée. L'application APPI 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 APPI, 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 oeuvre 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 APPI, et en coopération avec un dispositif de sécurité (ESEC). [0169] 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. [0170] 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. [0171] 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. 19 [0172] Selon un mode particulier de réalisation de l'invention, le dispositif connecté OBJ décrit précédemment est compris dans un terminal. [0173] 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. [0174] Selon un mode particulier de réalisation de l'invention, le dispositif de sécurité ESEC comprend notamment unc mémoire MSEC, unc 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 oeuvre 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. [0175] 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 oeuvre 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. [0176] 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é. [0177] 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. [0178] Selon un mode particulier de réalisation de l'invention, le dispositif ESEC décrit pré- cédemment est de type carte à puce. 20 REVENDICATIONS[Revendication I] 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é. [Revendication 2] 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. [Revendication 3] 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. [Revendication 4] 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. [Revendication 5] 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. [Revendication 6] 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é. [Revendication 7] 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 21 [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] 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 ca- [Revendication 12] ractérisé en cc qu'il est configure pour mémoriser au moins une clé de chiffrement de clé dans la mémoire (MSEC) du dispositif de sécurité (ESEC) , et en cc que la mémoire (MSEC) et le processeur (PROC2) sont configurés pour: [Revendication 13] - chiffrer ou déchiffrer au moins ladite clé de chiffrement à l'aide de ladite au moins une clé de chiffrement de clé, [Revendication 14] - 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. [Revendication 15] 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 oeuvre 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.