L’invention se situe dans le domaine de la protection des données, et en particulier le domaine de la sécurité dans les réseaux informatiques ou les réseaux de télécommunications à connectivité intermittente, indisponible, ou coûteuse. Des exemples de ces réseaux sont les réseaux à faibles ressources émergents avec des communications machine-à-machine, l’Internet des objets, les réseaux de capteurs sans-fil, et les réseaux véhiculaires, où les dispositifs contraints qui fournissent des ressources ou des services protégés sont déployés et laissés sans surveillance dans des emplacements difficiles d’accès. L’invention s’applique aussi à des réseaux d’urgence pour les systèmes de protection du public et de secours en cas de catastrophe (en anglais, Public Protection and Disaster Relief ou PPDR) quand l'infrastructure des réseaux et des communications n’est plus fiable à cause d’un désastre.

Plus précisément, l’invention porte sur une méthode d’établissement de clés permettant le contrôle d’accès à un service ou une ressource en utilisant les mécanismes de chiffrement basés sur les attributs ou ABE ("attribute-based encryption", en anglais).

Un des points clés pour garantir la sécurité des applications informatiques est la protection des données sensibles. Les données peuvent être protégées au moyen d’algorithmes cryptographiques de chiffrement de données, nécessitant des clés cryptographiques pour déchiffrer les données. Les clés doivent être distribuées aux utilisateurs autorisés à déchiffrer les données. Pour gérer d’une manière sélective différents types d’utilisateurs qui réalisent différentes tâches sur les données, un contrôle d’accès aux données fin et flexible est nécessaire. Les mécanismes de chiffrement basés sur les attributs permettent de fournir à la fois la confidentialité des données et le contrôle d’accès aux données, en combinant de manière cryptographique les clés de déchiffrement aux permissions d’accès aux données. Les données ainsi chiffrées ne nécessitent pas d’être transmises sur un canal sûr ou d’être stockées dans un serveur de confiance. Pour déchiffrer les données chiffrées, les utilisateurs doivent désormais satisfaire une politique d’accès qui est définie sur des attributs qui peuvent être associés aux utilisateurs des données, aux éléments de données, et à l’environnement. A titre d’exemple, un attribut peut concerner le rôle d’un utilisateur, par exemple sa profession, ou des caractéristiques personnelles de l’utilisateur, par exemple sa fonction ou un niveau de priorité qui lui est assigné pour l’accès aux données sensibles.

La publication de Bethencourt et autres [1 ] décrit une méthode de chiffrement basée sur les attributs particulière, appelée méthode de chiffrement CP-ABE « Ciphertext-Policy Attribute-Based Encryption ».

Cette méthode est une construction d’une méthode de chiffrement basée sur les attributs ayant la politique d’accès incorporée dans les données chiffrées et les attributs détenus par les utilisateurs de données. De cette façon, si la politique d’accès change régulièrement, le contrôle d’accès est plus flexible que le schéma de base ABE, puisqu’il est nécessaire seulement de changer la politique d’accès qui sera incorporée dans les données chiffrées, plutôt que de distribuer de nouvelles clés aux utilisateurs.

Le document [2] décrit une autre méthode de chiffrement basée sur les attributs, appelée méthode de chiffrement KP-ABE «Key-Policy Attribute- Based Encryption ». Cette méthode utilise un ensemble d’attributs pour décrire la donnée chiffrée et construit la politique de sécurité dans la clé privée de l’utilisateur. Si les attributs de la donnée chiffrée satisfont la structure d’accès définie dans la clé privée de l’utilisateur, l’utilisateur peut déchiffrer la donnée chiffrée. L’algorithme considère principalement trois acteurs : l’expéditeur (p. ex., le propriétaire des données), le récepteur (p. ex. l’utilisateur des données), et l’autorité (également, appelée service de gestion des clés) dont le rôle est de générer les clés publiques et privées du récepteur. Ainsi, seules les personnes qui ont les attributs qui satisfont à la politique d’accès peuvent accéder aux données chiffrées.

L’invention est compatible à la fois des méthodes de chiffrement CP- ABE et KP-ABE.

Assurer l’authentification et l'autorisation est primordial pour sécuriser l’accès à des ressources et services protégés. Généralement, les deux fonctions de sécurité sont réalisées en s'appuyant sur une ou plusieurs autorités de confiance en ligne. Les autorités de confiance contrôlent l’accès aux ressources et services conformément à une politique de sécurité, en particulier en participant directement à la procédure d’authentification pour établir un canal sécurisé, ou en distribuant des jetons d’accès temporaires aux utilisateurs autorisés permettant l’accès aux ressources et services. Cependant, l'indisponibilité de ces autorités de confiance ou leurs coûts importants associés rend difficile l'authentification et la mise en application des politiques d'autorisation sur des ressources et services protégés.

Tout comme les schémas à clés publiques (p. ex., les signatures numériques) qui peuvent être utilisés comme primitives pour élaborer des protocoles d'authentification sans avoir à recourir à une autorité de confiance en ligne, les schémas de chiffrement à base d'attributs de type ABE peuvent aussi être utilisés pour construire des protocoles d'autorisation, puisque ces schémas permettent à la fois de garantir la confidentialité, mais aussi un contrôle d'accès de granularité fine sur les données chiffrées. Les protocoles d’autorisation basés sur ABE permettent donc de se passer d’une autorité de confiance en ligne.

Cependant, ces mécanismes ne permettent pas de sécuriser les échanges confidentiels des utilisateurs d’un même groupe qui partagent les mêmes attributs. Ainsi, plusieurs utilisateurs qui sont autorisés à accéder à une même ressource ou un même service, selon ce mécanisme ABE, ne seront pas protégés en confidentialité les uns vis-à-vis des autres.

Il existe des protocoles d'échange de clés de chiffrement conçus en utilisant le mécanisme ABE. Le protocole de Gorantla et autres décrit dans le document [3] permet à un groupe de pairs associés à des ensembles d'attributs satisfaisants à la même politique d'accès, de partager une clé de session. Dans la même optique, le protocole de Steinwandt et autres décrit dans le document [4] permet à un groupe de pairs ayant tous des attributs qui satisfont la même politique de sécurité de partager une clé commune.

Un inconvénient commun à ces deux protocoles est que n’importe quel pair qui n’appartient pas au groupe mais qui détient le bon ensemble d'attributs peut récupérer la clé de groupe établie. Le protocole de Kolesnikov et autres décrit dans le document [5] est basé sur des interactions client / serveur qui permettent à un serveur d'établir une clé partagée avec un client uniquement lorsque les attributs de ce dernier satisfont une politique d'accès. Pour ce faire, le protocole combine des notions de chiffrement ABE avec des éléments des circuits brouillés (en anglais, garbled circuits). Le protocole n'utilise pas le chiffrement ABE en soi, mais un nouveau concept, appelé chiffrement sélectif d'attributs, qui permet au client de déchiffrer uniquement les valeurs brouillées des fils d'entrée du circuit brouillé, qui sont associées à ses attributs. Le protocole de Kolesnikov et autres offre des garanties de confidentialité fortes à la fois pour le client et le serveur, y compris la confidentialité des attributs du client et la non associativité (en anglais, unlinkability) de ses sessions. Le protocole vise à cacher l’identité des utilisateurs des données, et nécessite au minimum deux échanges de messages (i.e., 4 messages), sans tenir compte de la phase d’établissement de clés qui est basée sur un protocole de tirage au sort bit- par-bit (en anglais, coin tossing). L’invention propose de résoudre les inconvénients précités en proposant un mécanisme cryptographique basé sur les attributs mais qui comprend en outre un protocole d’échanges de clés permettant de garantir la confidentialité des échanges entre un utilisateur et un fournisseur de services.

L’invention apporte plusieurs avantages, notamment en termes de sécurité et de performance. L’invention permet d’établir une clé de session tout en contrôlant l’accès aux ressources et services. L’invention permet de réaliser l’établissement de clés et de contrôler l’accès selon une politique d’accès en un seul échange de messages. Ceci permet de réaliser un contrôle d’accès rapide et avec un coût d’implémentation limité.

L’invention permet de dispenser l’utilisateur de s’authentifier et ainsi d’accéder aux ressources ou services d’une manière anonyme (protégeant ainsi la vie privée de l’utilisateur vis-à-vis du fournisseur) mais autorisée.

Une variante de l’invention permet à l’utilisateur de vérifier si les ressources ou services accédés sont légitimes en rapport à un ensemble d’attributs ou à une politique d’accès. L’invention a pour objet une méthode, mise en oeuvre par ordinateur, d’établissement d’au moins une clé commune, à la manière de Diffie- Hellman, pour le contrôle d’accès à un service ou une ressource proposé par un fournisseur pour des utilisateurs ayant des clés privées associées à au moins un attribut appartenant à un premier ensemble prédéterminé d’attributs utilisateurs ou associées à une politique d’accès composée d’au moins un attribut appartenant à un premier ensemble prédéterminé d’attributs utilisateurs, la méthode étant exécutée par le fournisseur et comprenant les étapes de :

- Générer simultanément d’une part une première clé partielle de fournisseur K ¹ _F à partir d’une opération entre un générateur g d’un groupe et une première variable aléatoire secrète s _F du fournisseur et d’autre part une version chiffrée CÎ _F de la première clé partielle, à l’aide d’un algorithme d’encapsulation de clés basé sur les attributs,

- Transmettre, à l’utilisateur, la version chiffrée de la première clé partielle de fournisseur CÎF,

- Recevoir, de l’utilisateur, une première clé partielle d’utilisateur K ¹ u,

- Déterminer, à partir d’une opération entre la première clé partielle d’utilisateur K ¹ u et une variable aléatoire secrète SF,X du fournisseur, une première clé K ¹ _DH commune au fournisseur et à l’utilisateur,

- Etablir un canal de communication sécurisé entre le fournisseur et l’utilisateur à partir de la première clé K ¹ _DH commune à la manière de Diffie-Hellman.

Selon un aspect particulier de l’invention, la première clé partielle d’utilisateur est une clé chiffrée ctu et la méthode comprend en outre une étape de déchiffrer la première clé partielle d’utilisateur chiffrée ctu à partir d’une clé sk _F associée à au moins un attribut fournisseur ou à une politique d’accès composée d’au moins un attribut fournisseur, en utilisant un algorithme de décapsulation de clés basé sur les attributs.

Dans une variante particulière de réalisation, la méthode selon l’invention comprend en outre les étapes de :

- Générer une seconde clé partielle de fournisseur K ² _F et la transmettre à l’utilisateur,

- Recevoir, de l’utilisateur, une seconde clé partielle d’utilisateur K ² u,

- Déterminer, à partir de la seconde clé partielle d’utilisateur K ² u, une seconde clé K ² _DH commune au fournisseur et à l’utilisateur,

- Etablir un canal de communication sécurisé entre le fournisseur et l’utilisateur à partir de la première clé K ¹ _DH commune et de la seconde clé K ² _DH commune à la manière de Diffie-Hellman. Selon un aspect particulier de l’invention :

- la première clé partielle de fournisseur K ¹ _F est obtenue à partir d’une opération entre un générateur g _F d’un premier groupe et une première variable aléatoire secrète s _F du fournisseur,

- la première clé K ¹ _DH commune est obtenue à partir d’une opération entre la première clé partielle d’utilisateur K ¹ u et une seconde variable aléatoire secrète x du fournisseur,

- la seconde clé partielle de fournisseur K ² _F est obtenue à partir d’une opération entre un générateur gu d’un second groupe et la seconde variable aléatoire x secrète du fournisseur et,

- la seconde clé K ² _DH commune est obtenue à partir d’une opération entre la seconde clé partielle d’utilisateur K ² u et la première variable aléatoire secrète s _F du fournisseur, à la manière de Diffie- Hellman.

L’invention a aussi pour objet une méthode, mise en oeuvre par ordinateur, d’établissement d’au moins une clé commune, à la manière de Diffie-Hellman, pour le contrôle d’accès à un service ou une ressource proposé par un fournisseur pour des utilisateurs ayant des clés privées associées à au moins un attribut appartenant à un premier ensemble prédéterminé d’attributs utilisateurs ou associées à une politique d’accès composée d’au moins un attribut appartenant à un premier ensemble prédéterminé d’attributs utilisateurs, la méthode étant exécutée par un utilisateur possédant au moins une clé privée associée à au moins un attribut utilisateur ou à une politique d’accès composée d’au moins un attribut utilisateur, et comprenant les étapes de :

- Générer une première clé partielle d’utilisateur K ¹ u à partir d’une opération entre un générateur d’un groupe g _F et une première variable aléatoire secrète Su de l’utilisateur et la transmettre au fournisseur, - Recevoir, du fournisseur, une version chiffrée d’une première clé partielle de fournisseur ct _F ,

- Déchiffrer la première clé partielle de fournisseur chiffrée ct _F pour obtenir une première clé partielle de fournisseur K ¹ _F , en utilisant un algorithme de décapsulation de clés basé sur les attributs,

- Déterminer, à partir d’une opération entre la première clé partielle de fournisseur K ¹ _F et une variable aléatoire secrète Su,y de l’utilisateur, une première clé K ¹ _DH, K ² _DH commune au fournisseur et à l’utilisateur,

- Etablir un canal de communication sécurisé entre le fournisseur et l’utilisateur à partir de la première clé K ¹ _DH, K ² _DH commune à la manière de Diffie-Hellman.

Dans une variante particulière de réalisation, la méthode selon l’invention comprend en outre une étape générer simultanément la première clé partielle d’utilisateur K ¹ u et sa version chiffrée à partir d’une clé dérivée d’un second ensemble d’attributs fournisseur ou d’une politique d’accès fournisseur composée d’attributs fournisseur, avant de la transmettre au fournisseur.

Dans une variante particulière de réalisation, la méthode selon l’invention comprend en outre les étapes de :

- Générer une seconde clé partielle d’utilisateur K ² u et la transmettre au fournisseur,

- Recevoir, du fournisseur, une seconde clé partielle de fournisseur

K ² _f ,

- Déterminer, à partir de la seconde clé partielle de fournisseur K ² _F , une seconde clé K ¹ _DH commune au fournisseur et à l’utilisateur,

- Etablir un canal de communication sécurisé entre le fournisseur et l’utilisateur à partir de la première clé K ¹ _DH commune et de la seconde clé K ² _DH commune à la manière de Diffie-Hellman.

Selon un aspect particulier de l’invention : - la première clé partielle d’utilisateur K ¹ u est obtenue à partir d’une opération entre un générateur gu d’un premier groupe et une première variable aléatoire secrète Su de l’utilisateur,

- la première clé K ² _DH commune est obtenue à partir d’une opération entre la première clé partielle de fournisseur K ¹ _F et une seconde variable aléatoire secrète y de l’utilisateur,

- la seconde clé partielle d’utilisateur K ² u est obtenue à partir d’une opération entre un générateur g _F d’un second groupe et la seconde variable aléatoire secrète y du fournisseur et,

- la seconde clé K ¹ _DH commune est obtenue à partir d’une opération entre la seconde clé partielle de fournisseur K ² _F et la première variable aléatoire secrète Su du fournisseur.

Selon un aspect particulier de l’invention, l’opération est un calcul d’exponentiation modulaire et le groupe est un groupe multiplicatif fini.

L’invention a aussi pour objet un programme d'ordinateur comportant des instructions pour l'exécution de l’une des méthodes d’établissement d’au moins une clé commune selon l’invention, lorsque le programme est exécuté par un processeur.

L’invention a aussi pour objet un support d'enregistrement lisible par un processeur sur lequel est enregistré un programme comportant des instructions pour l'exécution de l’une des méthodes d’établissement d’au moins une clé commune selon l’invention, lorsque le programme est exécuté par un processeur.

L’invention a aussi pour objet un dispositif de chiffrement comprenant un calculateur configuré pour exécuter les étapes de l’une quelconque des méthodes d’établissement d’au moins une clé commune selon l’invention.

D’autres caractéristiques et avantages de la présente invention apparaîtront mieux à la lecture de la description qui suit en relation aux dessins annexés qui représentent : La figure 1 , un schéma illustrant un protocole de contrôle d’accès par un utilisateur à un service proposé par un fournisseur, selon un premier mode de réalisation de l’invention,

La figure 2, un organigramme des étapes d’une méthode d’établissement de clés de chiffrement, exécutée par le fournisseur, au cours d’un protocole de contrôle d’accès selon le premier mode de réalisation de l’invention,

La figure 3, un organigramme des étapes d’une méthode d’établissement de clés de chiffrement, exécutée par l’utilisateur, au cours d’un protocole de contrôle d’accès selon le premier mode de réalisation de l’invention,

La figure 4, un schéma illustrant un protocole de contrôle d’accès par un utilisateur à un service proposé par un fournisseur et de contrôle de la légitimité du fournisseur, selon un deuxième mode de réalisation de l’invention,

La figure 5, un organigramme des étapes d’une méthode d’établissement de clés de chiffrement, exécutée par le fournisseur, au cours d’un protocole de contrôle d’accès et de contrôle de légitimité selon le deuxième mode de réalisation de l’invention,

La figure 6, un organigramme des étapes d’une méthode d’établissement de clés de chiffrement, exécutée par l’utilisateur, au cours d’un protocole de contrôle d’accès et de contrôle de légitimité selon le deuxième mode de réalisation de l’invention,

La figure 7, un schéma illustrant un protocole de contrôle d’accès par un utilisateur à un service proposé par un fournisseur et de contrôle de la légitimité du fournisseur, selon un troisième mode de réalisation de l’invention,

La figure 8, un organigramme des étapes d’une méthode d’établissement de clés de chiffrement, exécutée par le fournisseur, au cours d’un protocole de contrôle d’accès et de contrôle de légitimité selon le troisième mode de réalisation de l’invention, - La figure 9, un organigramme des étapes d’une méthode d’établissement de clés de chiffrement, exécutée par l’utilisateur, au cours d’un protocole de contrôle d’accès et de contrôle de légitimité selon le troisième mode de réalisation de l’invention.

Les figures 1 ,2 et 3 schématisent un mécanisme de contrôle d’accès selon un premier mode de réalisation de l’invention.

L’invention permet à un fournisseur de services ou de ressources de contrôler l’accès à ces services ou ressources par un utilisateur non authentifié. Le contrôle d’accès est réalisé en fonction d’une politique d’accès. Un utilisateur est autorisé s’il possède des attributs qui satisfont la politique d’accès. On rappelle qu’un attribut peut concerner l’utilisateur, les ressources ou services protégés, ou le contexte (p. ex., date, lieu, etc.). La notion d’attribut permet de définir des groupes d’utilisateurs qui possèdent un attribut commun. Chaque utilisateur peut appartenir à un ou plusieurs groupes. Une politique d’accès est définie comme une combinaison de portes logiques de seuil sur des attributs. Un attribut peut être affecté à un utilisateur temporairement ou de façon permanente. A son niveau le plus simple, une politique d’accès peut consister à autoriser l’accès aux individus possédant un attribut prédéterminé. Par exemple, dans le contexte d’un incendie dans un bâtiment intelligent, les primo-intervenants (p. ex. pompiers, police, ...) possède des attributs i.e., des matériels cryptographiques : les attributs « A » leur permettant d’accéder à tout le bâtiment, les attributs « B » permettant de contrôler les actionneurs du système CVC (i.e., chauffage, ventilation et climatisation), et les attributs « C » permettant de réinitialiser le système d’alarme incendie après l’extinction de l’incendie. En revanche, les compagnies d'électricité et d'approvisionnement auront juste les attributs « B » leur permettant de contrôler les actionneurs du système CVC qu’ils gèrent, mais aussi des attributs « D » permettant de lire les compteurs du système CVC à distance. Ce dernier service fournit par système CVC demande des attributs qui vérifient la politique (« B » ET « D »).

L’invention se base sur un mécanisme de chiffrement basé sur les attributs. Elle est compatible à la fois d’un mécanisme de chiffrement de type CP-ABE pour lequel un fournisseur contrôle l’accès aux ressources/services qu’il propose selon une politique d’accès, mais aussi d’un mécanisme de chiffrement de type KP-ABE pour lequel un fournisseur contrôle l’accès aux ressources/services qu’il propose directement en fonction d'une liste d’attributs autorisés.

Dans ce premier mode de réalisation de l’invention, le fournisseur et l’utilisateur connaissent les paramètres publics du mécanisme de chiffrement ABE utilisé. Par ailleurs, l’utilisateur possède un ensemble de clés secrètes associées à une liste d’attributs qu’il possède (pour un mécanisme de type CP-ABE) ou à une politique de sécurité (pour un mécanisme de type KP- ABE).

Dans la suite de la description, le terme « utilisateur » est utilisé pour désigner un terminal utilisé par un utilisateur pour accéder au service ou à la ressource proposé(e) par le fournisseur. Le terme « fournisseur » est utilisé pour désigner l’équipement qui met en oeuvre le service ou héberge la ressource. Un service peut être un service hébergé sur un serveur distant et proposé par un fournisseur sur Internet. Il peut s’agir d’une application logicielle. Une ressource peut être un calculateur ou un processeur ou une mémoire dans un serveur distant ou sur le terminal de l’utilisateur lui-même. Par exemple, l’invention peut être utilisée pour permettre à un utilisateur de déverrouiller son ordinateur ou pour lui permettre d’accéder à une ressource particulière de la machine qu’il utilise. On décrit à présent, en préalable à la description de l’invention, deux exemples de protocoles d’échanges de clés de chiffrement sur lesquels l’invention peut se baser.

Le document [3] introduit un mécanisme d’encapsulation de clés basé sur les attributs avec une politique d’encapsulation (en anglais, encapsulation-policy attribute-based key encapsulation mechanism, ou EP- AB-KEM). Un protocole de type EP-AB-KEM est une technique de chiffrement conçue pour générer et sécuriser la transmission d’une clé symétrique par le biais d’algorithmes de chiffrement basés sur les attributs et avec une politique associée au texte chiffré. Un protocole de type EP-AB- KEM est composé d’au moins les quatre algorithmes suivants.

Un algorithme de configuration, Configuration (1 ^x ) ® (pk, msk) génère une clé publique pk et une clé secrète maître msk, qui sont retournées en sortie.

Un algorithme de génération de clés, Génération des clés ( msk, S) ®sk : à partir de la clé secrète maître msk et d’un ensemble d’attributs S associés à un utilisateur, cet algorithme retourne l’ensemble sk des clés correspondant aux attributs dans l’ensemble S. Ces clés sont fournies aux utilisateurs qui possèdent les attributs correspondants.

Un algorithme d’encapsulation de clés, Encapsulation ( k, r) ® (ct, K ) qui génère à la fois une clé aléatoire K comme élément de G _T et la même clé chiffrée et, l’opération de chiffrement étant associée à une politique d’accès G. Les deux sont retournés en sortie. L’opération d’encapsulation comprend donc la génération d’une clé aléatoire et son chiffrement pour produire une clé chiffrée.

Un algorithme de décapsulation de clés, Décapsulation (pk, et, sk) ® {K', ±}. Cet algorithme est exécuté par un utilisateur possédant certains attributs S et les clés secrètes sk associées. Si l’ensemble S des attributs associés à la clé secrète sk ne satisfait pas la politique d’accès utilisée pour chiffrer la clé et, alors l’algorithme retourne une constante 1 associée à l’évènement “faux”. Autrement dit, cette constante 1 est retournée par l’algorithme pour signifier que l’utilisateur n’est pas autorisé à accéder aux ressources ou services définis par la politique d’accès. Sinon, il déchiffre et pour retrouver la clé symétrique K’ et la retourner en sortie. Le protocole d’échange de clés proposé dans le document [3] permet à un groupe d’utilisateurs ayant des attributs qui satisfont une politique d’accès donnée, de partager une clé de groupe commune. Le protocole se déroule de la manière suivante. Tout d’abord, chaque utilisateur i exécute l’algorithme d’encapsulation Encapsulation(pk, G)® (ct^ Ki) pour générer une clé symétrique et son chiffré selon la politique d’accès G, et ensuite diffuse le texte chiffré cti. A la réception d’un texte chiffré ctj , chaque utilisateur i exécute l’algorithme de décapsulation Décapsulation (pk, ctj, sk^) ® Kj pour retrouver la clé associée en utilisant sa clé secrète ski qui vérifie la politique d’accès. Finalement, chaque utilisateur calcule l’identifiant de la session sid = (ct ... | ct _n ) et la clé du groupe composé de n utilisateurs : K = f _Ki (sid) 0 ...0 f _Kn (sid) où f est une fonction pseudo-aléatoire à clé.

Le protocole proposé dans le document [3] est destiné à sécuriser les communications de groupe et n’offre pas une solution permettant un contrôle d’accès individuel et protégé en confidentialité vis-à-vis d’autres utilisateurs ayant des attributs satisfaisant la politique d’accès associée aux communications protégées, ainsi que vis-à-vis de l’autorité de séquestre qui génère les clés secrètes ABE. Un autre exemple de protocole de type EP-AB-KEM est dérivé du schéma de Waters décrit dans le document [6]. Dans cet exemple, le protocole est composé des algorithmes suivants par défaut avec une variation apportée aux paramètres de sortie de l’algorithme d’encapsulation.

Un algorithme de configuration Configuration (1 ^l ) ® (pk, msk): cet algorithme définit trois groupes G _1; G ₂ , et G _T d’ordre premier p = Q(l) avec G- _L et G ₂ ayant respectivement deux générateurs P et Q, et supportant une application bilinéaire non dégénérée, efficace et calculable e ^; x G ₂ ® G _T . L’algorithme choisit deux valeurs aléatoires et, a e Z _P , ainsi qu’un ensemble d’éléments aléatoires H ₁ , H ₂ , .. , H _U qui seront associés à l’ensemble de U attributs. Par la suite, l’algorithme calcule une clé publique pk = (P, Q, a. P, e(P, Q) ^a , H ₁ , .., H _u ) et une clé secrète maître msk = (a. P), qui sont retournées en sortie.

Un algorithme de génération de clés Génération des clés (msk, S) ®sk\ cet algorithme choisit une valeur aléatoire t e TL _P . Ensuite, à partir de la clé secrète maître msk et d’un ensemble d’attributs S associés à un utilisateur, l’algorithme calcule K = a. P + 1. (a. P), L = t. Q, et Vy e S Q U: K _y = t. H _y comme étant la clé secrète sk qui est retournée en sortie.

Un algorithme d’encapsulation de clés, Encapsulation (pk, r) ® (ct, s) \ cet algorithme convertit la politique d’accès en une matrice MSP (en anglais, Monotone Span Program), (M, p), où p est une fonction qui fait correspondre chaque ligne de la matrice M à un attribut de U. Un exemple de techniques de conversion est décrit dans l’annexe G du document [7] Pour une matrice M de m lignes et d colonnes, l’algorithme choisit les valeurs aléatoires . Considérant le vecteur v = (s,y ₂ , ... ,y _m ), l’algorithme calcule VI < i < m: m _ί =< (M)i,v > où (M) _r est la iième ligne de M et dénote un produit scalaire. Ensuite, l’algorithme calcule C' = s. Q et VI < i < m: C _j = m _ί . (a. P) + (- ). H _r(ί) et D _j = r _j . Q comme étant le texte chiffré et. L’algorithme retourne en sortie (et = ((M, p), C',vl < i < m: C _j , D _j ), s).

Un algorithme de décapsulation de clés chiffrées Décapsulation (pk, et, sk) ® {K', 1}: si l’ensemble S des attributs associés à la clé secrète sk ne satisfait pas la politique d’accès utilisée pour chiffrer la clé et, alors l’algorithme retourne la constante 1 signifiant l’information logique « faux » Sinon, il existe un ensemble de constantes {yi} _iei tel que åieiYi- (M)i = (1, 0, ... , 0) où 1 est un ensemble d’indices de lignes de la matrice M qui correspondent à des attributs dans S. Par la suite, l’algorithme calcule la clé symétrique:

et retourne K’ en sortie.

La figure 1 schématise une vue d’ensemble des échanges intervenant entre un fournisseur F proposant un service et un utilisateur U souhaitant utiliser ce service. La figure 2 décrit, sur un organigramme, les étapes de la méthode selon l’invention exécutées par le fournisseur. La figure 3 décrit, sur un organigramme, les étapes de la méthode selon l’invention exécutées par l’utilisateur.

Dans ce premier mode de réalisation de l’invention, le fournisseur et l’utilisateur connaissent et utilisent les mêmes paramètres publics p _k du mécanisme de chiffrement ABE.

Le fournisseur définit une politique d’accès G ou une liste d’attributs

{attr} pour lesquels l’accès au service ou à la ressource qu’il propose est autorisé. Selon cette politique d’accès, le fournisseur génère, dans une première étape 201 , une clé partielle K ¹ _F et la chiffre en utilisant, par exemple, un algorithme d’encapsulation de clés tel que décrit dans l’un des deux exemples précédents. La clé partielle K ¹ _F est générée en effectuant une exponentiation modulaire entre le générateur g=e(P,Q) ^a d’un groupe compris dans les paramètres publics partagés par l’utilisateur et le fournisseur, et une valeur aléatoire secrète s générée par le fournisseur : K _p = e(P, Q) ^as = g ^s . Le groupe utilisé est un groupe fini qui peut être, par exemple, un groupe multiplicatif ou un groupe additif.

Ainsi, le fournisseur génère une clé partielle K ¹ _F et sa version chiffrée ct _F . Il transmet ensuite, dans une étape 202, la clé partielle chiffrée ct _F à l’utilisateur. A réception 303 de la clé CÎF, l’utilisateur exécute un algorithme de décapsulation 304 (par exemple l’un des algorithmes décrit précédemment) pour déchiffrer la clé ct _F en utilisant les paramètres publics p _k et la clé secrète sk _u associée aux attributs qu’il possède. Si les attributs que possède l’utilisateur vérifient la politique d’accès du fournisseur, alors la clé est déchiffrée et l’utilisateur récupère la clé partielle K ¹ _F du fournisseur.

Dans une autre étape 301 , l’utilisateur génère une valeur aléatoire y et calcule une autre clé partielle K ¹ u à partir de cette valeur aléatoire et du générateur g=e(P,Q) ^a du groupe en effectuant une exponentiation modulaire.

Ku ⁼ e(P, Q) ^ay = g ^y

L’utilisateur transmet 302 la clé partielle K ¹ u au fournisseur.

A réception 203 de la clé partielle K ¹ u de l’utilisateur, le fournisseur calcule 204 une clé commune KD _H = Kj _j ^S en effectuant une exponentiation modulaire entre cette clé et la valeur aléatoire secrète s utilisée pour générer la clé partielle K ¹ _F du fournisseur.

De façon similaire, l’utilisateur calcule 305 la même clé commune ^K DH = ^K _F ^{y en} effectuant une exponentiation modulaire entre la clé partielle du fournisseur et la valeur aléatoire secrète y.

A partir de la clé commune K _rH , le fournisseur et l’utilisateur peuvent établir 205,306 un canal de communication sécurisé.

Par exemple, ils peuvent générer chacun, à partir de cette clé commune, des clés de session pour protéger le canal de communication à travers lequel les ressources ou services seront accédés. La protection est possible en intégrité et en confidentialité.

Une méthode possible pour dériver des clés de session à partir d’une clé commune est proposée dans le document [8]. L’établissement d’une clé commune à partir de clés partielles se base sur le protocole d’échange de clés Diffie-Hellman décrit dans [9]. Ainsi, la méthode selon l’invention est basée sur l’établissement d’une clé commune à partir de clés partielles, à la manière de Diffie-Hellman. La clé commune est généralement une clé maître utilisée pour dériver d’autres clés de chiffrement qui sont utilisées pour garantir la confidentialité ou l’intégrité. Ce protocole permet à deux parties d’établir une clé commune. Pour cela, les deux parties choisissent un groupe fini (p. ex. un groupe multiplicatif) et un générateur g de ce groupe. La première partie choisit un nombre aléatoire x, calcule g ^x , et envoie g ^x . Respectivement, la deuxième partie choisit un nombre aléatoire y, calcule g ^y , et envoie g ^y . Les deux parties calculent ensuite la clé commune g ^xy -

Un avantage de la méthode selon l’invention est qu’elle permet de protéger les échanges entre un fournisseur et un utilisateur, en intégrité et en confidentialité, vis-à-vis des utilisateurs du même groupe possédant les mêmes attributs et aussi vis-à-vis de l’autorité qui délivre les paramètres publics.

Un autre avantage est que l’invention permet d’avoir une confidentialité persistante. En effet, dans le cas où les paramètres publics sont récupérés par un tiers non autorisé, ce tiers ne pourra pas retrouver la clé commune simplement en ayant accès aux échanges entre le fournisseur et l’utilisateur. En effet, l’accès à la clé partielle chiffrée ct _F permet, en connaissant les paramètres publics, de retrouver la clé partielle K ¹ _F du fournisseur mais la connaissance des deux clés symétriques partielles K ¹ _F et K ¹ u ne permet pas de retrouver la clé commune K _DH -

Aussi, l’invention permet également une confidentialité vis-à-vis de l’autorité de séquestre qui délivre les paramètres publics.

L’invention conserve par ailleurs l’avantage d’un mécanisme de chiffrement basé sur les attributs qui permet d’accéder à un service en étant authentifié sur la base de ses attributs sans être identifié personnellement. Les figures 4,5 et 6 décrivent un deuxième mode de réalisation de l’invention. La figure 4 schématise une vue d’ensemble des échanges intervenant entre un fournisseur F proposant un service et un utilisateur U souhaitant utiliser ce service. La figure 5 décrit, sur un organigramme, les étapes de la méthode selon le deuxième mode de réalisation de l’invention exécutées par le fournisseur. La figure 6 décrit, sur un organigramme, les étapes de la méthode selon le deuxième mode de réalisation de l’invention exécutées par l’utilisateur.

Le deuxième mode de réalisation de l’invention permet à la fois à un fournisseur de ressources ou services associés à une politique d’accès de contrôler l’accès par un utilisateur non authentifié mais également à l’utilisateur de vérifier si le fournisseur est légitime à fournir le service ou les ressources.

Ainsi, dans cette variante de réalisation, l’invention comprend un mécanisme d’authentification, par l’utilisateur, de la légitimité du fournisseur. Le fournisseur et l’utilisateur partagent toujours les mêmes paramètres publics p _k utilisés pour générer les clés symétriques partielles, qui sont connus d’eux et fournis par une autorité tierce.

Dans ce deuxième mode de réalisation, l’utilisateur exécute en outre une étape de chiffrement 601 de la clé partielle K ¹ u générée à l’étape 301. Cette étape de chiffrement 601 peut être réalisée au moyen d’un algorithme d’encapsulation identique à celui utilisé par le fournisseur et qui produit en sortie une clé chiffrée ctu- L’encapsulation 601 est effectuée à partir d’une politique l ^~ u permettant de vérifier la légitimité du fournisseur de service pour assurer le service ou proposer les ressources. Cette politique Gu est, par exemple, une combinaison logique de plusieurs attributs que doit vérifier un fournisseur légitime. Si le mécanisme de chiffrement KP-ABE est utilisé, la politique G u est remplacée par une liste d’attributs {attru}. A réception 203 de la clé chiffrée ctu, le fournisseur exécute un algorithme de décapsulation 501 pour retrouver la clé partielle K ¹ u de l’utilisateur. Cette opération n’est possible que si le fournisseur possède les attributs qui satisfont la politique de sécurité l ^~ u de l’utilisateur.

Les autres étapes de la méthode sont identiques à celles décrites pour le premier mode de réalisation de l’invention.

Un avantage de ce deuxième mode de réalisation est qu’il permet à l’utilisateur d’authentifier le fournisseur pour être sur que celui-ci est bien légitime à proposer le service ou fournir les ressources.

Les figures 7,8 et 9 décrivent un troisième mode de réalisation de l’invention. La figure 7 schématise une vue d’ensemble des échanges intervenant entre un fournisseur F proposant un service et un utilisateur U souhaitant utiliser ce service. La figure 8 décrit, sur un organigramme, les étapes de la méthode selon le troisième mode de réalisation de l’invention exécutées par le fournisseur. La figure 9 décrit, sur un organigramme, les étapes de la méthode selon le troisième mode de réalisation de l’invention exécutées par l’utilisateur.

Ce troisième mode de réalisation est une variante du deuxième mode de réalisation décrit ci-dessus. Dans ce troisième mode de réalisation de l’invention, le processus d’authentification de l’utilisateur par le fournisseur utilise un premier ensemble de paramètres publics associés à un premier ensemble de clés publiques pk _F , tandis que le processus de vérification de la légitimité du fournisseur par l’utilisateur utilise un second ensemble de paramètres publics associés à un second ensemble de clés publiques pku.

Les deux ensembles de paramètres publics sont, par exemple, fournis respectivement au fournisseur et à l’utilisateur par deux autorités tierces différentes. Ainsi, les groupes utilisés respectivement pour générer des clés partielles sont différents respectivement pour le processus d’authentification (décrit dans le premier mode de réalisation de l’invention) et pour le processus de vérification de légitimité (décrit dans le second mode de réalisation de l’invention).

Dans ce cas, le fonctionnement du mécanisme d’établissement de clés doit être modifié par rapport au fonctionnement décrit aux figures 4,5,6 car il n’est plus possible pour le fournisseur et l’utilisateur de calculer une seule clé commune.

Dans une première étape 201 , le fournisseur génère, selon la politique d’accès ou la liste d’attributs qu’il possède, une première clé partielle K ¹ _F et la chiffre en utilisant, par exemple, un algorithme d’encapsulation de clés. La clé partielle K ¹ _F est générée à partir d’un premier ensemble de paramètres publics {P _F ,Q _F ,a _F } en réalisant par exemple une exponentiation modulaire entre le générateur g _F =e(P _F ,Q _F ) ^a _F d’un groupe compris dans ce premier ensemble et une première valeur aléatoire secrète s _F générée par le fournisseur : = e(P _F ,Q _F ) ^a _F ^s _F = g _F ^s _F . Le premier ensemble de paramètres publics est utilisée pour le mécanisme d’authentification de l’utilisateur.

Dans une étape supplémentaire 801 , le fournisseur génère aussi une seconde clé partielle K ² _F à partir d’un second ensemble de paramètres publics {Pu, Qu, au} en réalisant par exemple une exponentiation modulaire entre le générateur gu=e(Pu,Qu) ^a u d’un groupe compris dans ce premier ensemble et une seconde valeur aléatoire secrète x générée par le fournisseur : K ² _{F =} e(Pu,Qu) ^a u ^x = gu ^x -

Le second ensemble de paramètres publics est utilisé pour le mécanisme de vérification de la légitimité du fournisseur.

Ensuite, le fournisseur transmet 202, la première clé chiffrée ct _F et la seconde clé partielle K ² _F à l’utilisateur.

A réception 303 des deux clés, l’utilisateur exécute un algorithme de décapsulation 304 (par exemple l’un des algorithmes décrit précédemment) pour déchiffrer la clé ct _F en utilisant les clés publiques pk _F du premier ensemble de paramètres publics et la clé secrète sk _u associée aux attributs qu’il possède. Si les attributs que possède l’utilisateur vérifient la politique d’accès du fournisseur, alors la clé est déchiffrée et l’utilisateur récupère la première clé partielle K ¹ _F du fournisseur. Il détient par ailleurs la seconde clé partielle K ² _F qu’il a reçu.

Dans une autre étape 301 , l’utilisateur génère une première clé partielle K ¹ u à partir de paramètres publics du second ensemble et d’une valeur aléatoire Su : = eCP^ Qu) ⁰ ^ ⁰ = gu ^Su . Cette première clé est destinée au mécanisme de vérification de la légitimité du fournisseur. Cette première clé partielle est ensuite chiffrée 601 via un algorithme d’encapsulation pour produire une clé chiffrée ctu.

Dans une autre étape 901 , l’utilisateur génère aussi une seconde clé partielle K ² u à partir de paramètres publics du premier ensemble et d’une valeur aléatoire y : K¾ = e(P _F , Q _F ) ^airy = g _F ^y . Cette seconde clé partielle est destinée au mécanisme d’authentification de l’utilisateur.

L’utilisateur transmet ensuite 302 la première clé chiffrée ctu et la seconde clé partielle K ² u au fournisseur.

A réception 203 des deux clés, le fournisseur déchiffre 501 la clé chiffrée ctu via un algorithme de décapsulation.

Le fournisseur détermine 803 ensuite une première clé partielle commune K _rH = Ku en effectuant une exponentiation modulaire entre la première clé partielle déchiffrée K ¹ u et la variable aléatoire secrète x utilisée pour calculer la seconde clé partielle du fournisseur K ² _F . Cette première clé commune est calculée à partir de paramètres publics du second ensemble et sert à vérifier la légitimité du fournisseur. Le fournisseur détermine 802 par ailleurs une seconde clé commune ^K DH = K¾ ^SF en effectuant une exponentiation modulaire entre la seconde clé symétrique K ² u reçue et la variable aléatoire S _F secrète utilisée pour calculer la première clé partielle du fournisseur K ¹ _F - Cette seconde clé commune est calculée à partir de paramètres publics du premier ensemble et sert à authentifier l’utilisateur.

De façon similaire, l’utilisateur calcule également 902 la première clé commune Kr _H = Kp ^Su en effectuant une exponentiation modulaire entre la seconde clé partielle reçue K ² _F et la variable aléatoire secrète Su utilisée pour calculer la première clé partielle de l’utilisateur K ¹ u. Cette première clé commune est calculée à partir de paramètres publics du second ensemble et sert à vérifier la légitimité du fournisseur.

L’utilisateur détermine aussi 305 par ailleurs une seconde clé commune K¾ _H = Kp ^V en effectuant une exponentiation modulaire entre la première clé symétrique K ¹ _F déchiffrée et la variable aléatoire y secrète utilisée pour calculer la seconde clé partielle de l’utilisateur K ² u. Cette seconde clé commune est calculée à partir de paramètres publics du premier ensemble et sert à authentifier l’utilisateur.

A partir de la première clé commune K _DH , l’utilisateur peut vérifier la légitimité du fournisseur. A partir de la seconde clé commune K¾ _H , le fournisseur peut authentifier l’utilisateur. A l’aide de ces deux clés de chiffrement communes, le fournisseur et l’utilisateur peuvent établir 903 un canal sécurisé pour échanger.

Un avantage de ce troisième mode de réalisation de l’invention est qu’il permet d’adapter la méthode d’établissement de clés communes dans le cas où l’utilisateur et le fournisseur ne partagent pas les mêmes paramètres publics pour réaliser d’une part la vérification de légitimité du fournisseur et d’autre part l’authentification de l’utilisateur. Cela est le cas, par exemple, lorsque les paramètres publics sont fournis par deux autorités tierces distinctes.

Dans une variante de réalisation du troisième mode de réalisation, la méthode comprend une phase de négociation préalable entre le fournisseur et l’utilisateur pour qu’ils échangent les paramètres publics respectifs qu’ils vont utiliser.

Dans une autre variante de réalisation de l’invention, applicable à tous ses modes de réalisation, la méthode comprend en outre une étape d’identification de l’utilisateur par le fournisseur et/ou du fournisseur par l’utilisateur par exemple au moyen d’une signature numérique par certificat numérique. Le protocole utilisant la technique SIGMA décrite dans le document [10] peut être utilisé à cette fin.

Cette variante offre une fonction supplémentaire d’établissement de la responsabilité par identification et journalisation des accès. En effet, l’invention permet uniquement l’authentification d’un utilisateur sur la base d’attributs qu’il possède mais ne permet pas son identification précise et la traçabilité des accès de cet utilisateur au service proposé par le fournisseur. Cette variante de réalisation permet d’ajouter une fonction d’identification supplémentaire à l’invention. La présente invention peut s’implémenter à partir d’éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d’ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique ou électromagnétique.

En particulier, le dispositif « fournisseur » et le dispositif « utilisateur » peuvent utiliser un ou plusieurs circuits électroniques dédiés ou un circuit à usage général. La technique de l'invention peut se réaliser sur une machine de calcul reprogrammable (un processeur ou un micro contrôleur par exemple) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Selon un mode de réalisation, le dispositif « fournisseur » et le dispositif « utilisateur » comprennent au moins un support de stockage lisible par ordinateur (RAM, ROM, EEPROM, mémoire flash ou une autre technologie de mémoire, CD-ROM, DVD ou un autre support à disque optique, cassette magnétique, bande magnétique, disque de stockage magnétique ou un autre dispositif de stockage, ou un autre support de stockage non transitoire lisible par ordinateur) codé avec un programme d'ordinateur (c'est-à-dire plusieurs instructions exécutables) qui, lorsqu'il est exécuté sur un processeur ou plusieurs processeurs, effectue les fonctions des modes de réalisation décrits précédemment.

A titre d'exemple d'architecture matérielle adaptée à mettre en œuvre l'invention, un dispositif selon l’invention peut comporter un bus de communication auquel sont reliés une unité centrale de traitement ou microprocesseur (CPU, acronyme de « Central Processing Unit » en anglais), lequel processeur peut être " multi-core " ou " many-core une mémoire morte (ROM, acronyme de « Read Only Memory » en anglais) pouvant comporter les programmes nécessaires à la mise en œuvre de l'invention; une mémoire vive ou mémoire cache (RAM, acronyme de « Random Access Memory » en anglais) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et une interface de communication ou E/S (I/O acronyme de « Input/ouput » en anglais) adaptée à transmettre et à recevoir des données.

Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) peut être stocké dans ou sur un médium de stockage amovible (par exemple une carte SD, un DVD ou Bluray, un moyen de stockage de masse tel que un disque dur e.g. un SSD) ou non-amovible, volatile ou non- volatile, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. Le support lisible par ordinateur peut être transportable ou communicable ou mobile ou transmissible (i.e. par un réseau de télécommunication 2G, 3G, 4G, Wifi, BLE, fibre optique ou autre).

L’invention peut également être implémentée en tant que produit programme d’ordinateur.

La référence à un programme d'ordinateur qui, lorsqu'il est exécuté, effectue l'une quelconque des fonctions décrites précédemment, ne se limite pas à un programme d'application s'exécutant sur un ordinateur hôte unique. Au contraire, les termes programme d'ordinateur et logiciel sont utilisés ici dans un sens général pour faire référence à tout type de code informatique (par exemple, un logiciel d'application, un micro logiciel, un microcode, ou toute autre forme d'instruction d'ordinateur) qui peut être utilisé pour programmer un ou plusieurs processeurs pour mettre en oeuvre des aspects des techniques décrites ici. Les moyens ou ressources informatiques peuvent notamment être distribués (" Cloud computing”), éventuellement selon des technologies de pair-à-pair. Le code logiciel peut être exécuté sur n'importe quel processeur approprié (par exemple, un microprocesseur) ou cœur de processeur ou un ensemble de processeurs, qu'ils soient prévus dans un dispositif de calcul unique ou répartis entre plusieurs dispositifs de calcul (par exemple tels qu’éventuellement accessibles dans l’environnement du dispositif). Le code exécutable de chaque programme permettant au dispositif programmable de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur ou en mémoire morte. De manière générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif avant d'être exécutés. L'unité centrale peut commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur ou dans la mémoire morte ou bien dans les autres éléments de stockage précités. Le code exécutable peut également être téléchargeable depuis un serveur distant.

Le programme d’ordinateur peut comprendre un code source, un code objet, un code source intermédiaire ou un code objet partiellement compilé ou toute autre forme d’instructions de code de programme adaptées pour mettre en oeuvre l’invention sous la forme d’un programme d’ordinateur.

Un tel programme peut présenter diverses architectures fonctionnelles. Par exemple, un programme d’ordinateur selon l’invention peut être décomposé en une ou plusieurs routines qui peuvent être adaptées à exécuter une ou plusieurs fonctions de l’invention telles que décrites précédemment. Les routines peuvent être enregistrées ensemble dans un même fichier exécutable mais peuvent également être sauvegardées dans un ou plusieurs fichiers externes sous la forme de librairies qui sont associées à un programme principal de façon statique ou dynamique. Les routines peuvent être appelées depuis le programme principal mais peuvent également comprendre des appels à d’autres routines ou sous-routines.

Tous les procédés ou étapes de procédés, programmes ou sous- programmes décrits sous la forme d’organigrammes doivent être interprétés comme correspondant à des modules, segments ou portions de code de programme qui incluent une ou plusieurs instructions de code pour implémenter les fonctions logiques et les étapes de l’invention décrites.

L’invention s’applique au contexte général des réseaux à faibles ressources dans lequel un dispositif contraint en ressources (p. ex. CPU, mémoire, batterie) contrôle l’accès aux ressources ou services qu’il héberge. Ces réseaux peuvent être déployés dans des lieux distants difficiles d’accès où une connexion régulière à une autorité d’authentification et d’autorisation n’est pas réalisable. Dans ces conditions, le protocole proposé dans l’invention permet au dispositif d’appliquer la politique d’accès associée aux ressources ou services sans passer par l’autorité de confiance et sans relation de confiance préalablement établie avec les utilisateurs.

L’invention peut également s’appliquer dans le contexte des réseaux d’urgence pour les systèmes de protection du public et de secours en cas de catastrophe. Dans ce type de réseaux, la connexion à une autorité de confiance peut être endommagée, perturbée, ou soumise à des contraintes techniques (p.ex., trafic très important). La solution proposée dans l’invention permet aux utilisateurs, notamment les primo-intervenants, d’accéder aux ressources et services déployés dans la zone sinistrée d’une manière sécurisée.

Dans un cadre général de la gestion fédérée des identités dans le domaine des technologies d’information (en anglais, federated identity) dans un ensemble d’organisations, l’invention peut permettre de simplifier la gestion des accès par des utilisateurs d’une organisation aux ressources ou services offerts par une autre organisation de l’ensemble. Ainsi, le fournisseur de ressources ou services de l’organisation n’exige plus de l’organisation de l’utilisateur, lors de la requête d’accès de l’utilisateur, d’authentifier ce dernier et de fournir des informations relatives à ses droits d’accès.

Références

[1] J. Bethencourt, A. Sahai, and B. Waters. Ciphertext-Policy Attribute- Based Encryption. In Proceedings of the 2007 IEEE Symposium on Security and Privacy (SP Ό7). 2007.

[2] V. Goyal, O. Pandey, A. Sahai, and B. Waters, "Attribute-based encryption for fine-grained access control of encrypted data,” in Proceedings of the 13th ACM conférence on Computer and communications security, pp. 89-98, 2006.

[3] M. C. Gorantla, C. Boyd, et J. M. G. Nieto, « Attribute-based authenticated key exchange », ACISP 2010.

[4] R Steinwandt et AS Corona, « Attribute-based group key establishment », Advances in Mathematics of Communications 4 (3), 381 -398.

[5] Kolesnikov, H. Krawczyk, Y. Lindell, A. Malozemoff, et T. Rabin, « Attribute-based Key Exchange with General Policies », CCS 2016.

[6] B. Waters, « Ciphertext-policy attribute-based encryption: an expressive, efficient, and provably secure realization », Public Key Cryptography 201 1 : 53-70.

[7] A. Lewko et B. Waters, « Decentralizing attribute-based encryption », EUROCRYPT'1 1.

[8] NIST SP 800-108 « Recommendation for Key Dérivation Using Pseudorandom Functions », octobre 2009.

[9] W. Diffie et M. Hellman, « New directions in cryptography », IEEE Transactions on Information Theory, vol. 22, no 6, 1976.

[10] H. Krawczyk, « SIGMA: The‘SIGn-and-MAc’ Approach to Authenticated

Diffie-Hellman and Its Use in the IKE Protocols », CRYPTO 2003.