Brevet FR3058540A1 — publié le 20180511

PROCÉDÉ DE GESTION D'AUTORISATION DANS UNE COMMUNAUTÉ D'OBJETS CONNECTES La présente invention concerne le domaine de la gestion des autorisations, en particulier pour les objets connectés. L'Internet des objets (ou loT pour « Internet of things » en anglais) est une tendance technologique visant à connecter un grand nombre d'objets utilisés au quotidien via le réseau Internet afin de fournir des services. Ces objets peuvent être des objets de l'environnement domestique (chaudière, réfrigérateur, porte, lampe, alarme, voiture...), de l'environnement professionnel, ou liés à des secteurs d'activité spécifiques (santé et médecine, bien-être et sport, usine et outils de production, villes intelligentes, énergie et transports, etc.). Ces objets sont habituellement appelés « objets connectés » ou « objets intelligents » (« smart objects » en anglais). Ils peuvent être des objets du monde physique (ex. une montre), mais également des ressources virtuelles (ex. un compte email). L'interconnexion et la collaboration de ces objets permet de rendre des services évolués. Il est avantageux que cette collaboration se fasse le plus possible directement entre les objets, c'est-à-dire sans passer par une intelligence centralisée qui aurait la connaissance de tous les objets d'un domaine, ce qui ne sera pas réalisable en préservant la diversité des objets, des fournisseurs et des cas d'utilisation. Afin que les objets puissent s'interconnecter facilement et collaborer, la question du contrôle d'accès (ou de la gestion des autorisations) est essentielle. De nombreuses architectures ont précédemment été proposées : - un appariement des objets par un utilisateur humain, qui configure manuellement chaque objet pour interagir avec un autre. Ce modèle est souvent trop complexe d'usage pour l'utilisateur, car ce dernier doit interagir avec l'ensemble des objets connectés de son environnement (ex. de sa maison), ces objets ayant des interfaces de configuration différentes et possiblement complexes. - un contrôle d'accès par liste d'accès (ou ACL pour « Access Control List » en anglais), où un utilisateur indique à chaque objet (directement ou via un serveur centralisé) la liste des objets qui peuvent se connecter à lui. Ce modèle pose des problèmes de scalabilité quand le 3058540 2 nombre d'objets augmente. - un contrôle d'accès par rôle (ou RBAC pour « Role Based Access Control » en anglais), où chaque objet est configuré pour accepter ou non la connexion d'un autre objet suivant le rôle qui a été attribué à cet autre objet. Ici aussi se pose la question de la scalabilité, et de 5 gestion dynamique de la reconfiguration des rôles en fonction du contexte. - un contrôle d'accès par l'identité (ou IBAC pour « Identity Based Access Control » en anglais), où chaque objet acceptera ou non la connexion avec d'autres objets en fonction de leur identité. Soit cette identité est intrinsèquement liée à l'objet (ex. adresse MAC) et ce modèle se rapproche des ACL, soit cette identité est fournie par un tiers de confiance 10 (Identity Provider) et le modèle est alors très centralisé. - un contrôle d'accès par attribut (ou ABAC pour Attribute Based Access Control), où chaque objet est autorisé ou non à se connecter à un autre objet en fonction de ses attributs. Si ce modèle permet de spécifier des règles générales dont la combinaison donnera un résultat différent en fonction du contexte précis de leur invocation, ce modèle est néanmoins 15 implémenté soit de façon centralisée (avec les inconvénients décrits plus haut), soit de façon complètement décentralisée (ce qui induit d'autres inconvénients en termes de scalabilité et de complexité de configuration). - un contrôle d'accès par capacité (OU CapBAC pour « Capability Based Access Control» en anglais), où chaque objet acceptera ou non la connexion avec d'autres objets en fonction de 20 leur capacité. Une capacité est une clé unique (ou jeton) qui est associée uniquement à un objet demandeur pour lui permettre d'effectuer certaines actions sur l'objet demandé. Ce jeton est émis généralement par une entité centralisée d'une manière complexe où les actions autorisées par le jeton et la durée de validité du jeton et d'autres conditions doivent être spécifiées manuellement à l'aide d'une certaine interface pour générer et envoyer ce 25 jeton. Il y a ainsi un besoin pour proposer une méthode de gestion des autorisations automatisée, scalable et simple de configuration dans le cadre des objets connectés. La présente invention vient améliorer la situation. 30 La présente invention vise alors un procédé de procédé de gestion d'autorisation dans une communauté d'objets connectés, un objet maitre étant déterminé dans ladite communauté, le procédé comportant : - réception par l'objet maître depuis un objet demandeur d'une demande de réalisation d'une 3058540 3 action visant : - la communauté des objets connectés ou - un objet interne de la communauté, l'objet interne étant distinct de l'objet maître ; - réception d'une liste d'attributs certifiés et associés à l'objet demandeur par un serveur 5 d'authentification distinct de l'objet maître ; - après vérification de la liste d'attributs par le serveur d'authentification et détermination d'une capacité de l'objet demandeur en fonction de ladite liste d'attributs, réception par l'objet maître d'un jeton d'authentification comportant ladite capacité ; - transfert dudit jeton d'authentification par l'objet maître vers ledit objet demandeur. 10 On appelle communauté un ensemble cohérent d'objets connectés. Cette communauté peut être automatique (ex. tous les objets ayant trait à la musique, tous les objets ayant trait à la sécurité du domicile, etc.). La communauté peut être également manuellement définie par l'utilisateur. Par ailleurs, le fait d'appartenir à une communauté n'exclut pas une appartenance à une autre communauté distincte. Pour faire partie d'une communauté, il est souvent nécessaire d'y avoir été 15 autorisé. En tout état de cause, une communauté au sens des objets connectés est un ensemble d'objets dont la liste est définie, cette liste étant stockée par exemple dans une base de données locale ou distribuée (i.e. ce n'est pas seulement un ensemble conceptuel d'objets). La plupart du temps, les objets de la communauté possèdent une relation de confiance particulière entre eux. La demande de réalisation d'une action visant la communauté des objets connectés peut être en 20 particulier le fait de rejoindre la communauté. La demande de réalisation d'une action visant un objet interne de la communauté, peut être en particulier le fait d'interagir avec cet objet interne ou d'accéder à l'un des services qu'il propose. On appelle « attribut » une caractéristique associée à l'objet. Cette caractéristique est souvent intrinsèque à l'objet ou à sa situation (ex. numéro de téléphone, position GPS de l'objet, type de 25 terminal, etc.). Il convient de ne pas confondre les attributs avec des simples identifiants ou des rôles qui seraient attribués à l'objet (voir supra). Un « attribut certifié » est un attribut dont l'exactitude a été certifiée par un tiers de confiance, le plus souvent appelée autorité de certification. La certification consiste le plus souvent dans l'apposition d'une signature numérique (ex. signature cryptographique asymétrique). 30 On appelle « capacité » d'un objet un ensemble d'autorisations (éventuellement une seule) décrivant les différentes actions/droits que cet objet possède dans un contexte donné. Par exemple, une capacité donnée peut permettre à un objet : 3058540 4 - de diffuser de la musique sur un poste de radio prédéterminé entre 7h et 20h chaque jour, ou - d'ouvrir une porte connectée pendant 10 minutes à partir de l'attribution de cette capacité. Le plus souvent, cette capacité prend la forme d'un jeton (ou « token » en anglais) décrivant, sous forme d'octets les différentes actions/droits. Ce jeton est généralement signé par une autorité de 5 confiance (ex. un serveur de gestion d'attributs ou plus généralement un serveur d'authentification ou AS pour « authentication server » en anglais). Pour déterminer une capacité ou un ensemble de capacités à partir d'attributs, le serveur d'authentification peut vérifier la certification des attributs et déterminer à partir d'un ensemble de règles quelle capacité il convient d'attribuer en fonction des attributs. Ces capacités peuvent être 10 prédéfinies à partir de règles déterminées et associées. L'architecture proposée par l'invention permet une gestion des droits souple, sans une centralisation excessive. Ainsi, l'autorité ayant certifié les attributs peut être distincte du serveur d'authentification. Cela permet ainsi un choix large d'autorités de certification (voire même l'utilisation d'une pluralité d'autorités de certification, chaque autorité certifiant un sous-ensemble de la liste 15 d'attributs transmise au serveur d'authentification). Par ailleurs, l'invention propose d'éviter les communications directes entre le serveur d'authentification et l'objet demandeur pour des raisons de sécurité. En effet, il peut être utile qu'un objet demandeur, tiers au réseau, n'ait pas la capacité de découvrir l'adresse du serveur d'authentification, par des mécanismes de découvertes réseau classiques. 20 Le procédé peut comporter en outre : - réception dudit jeton d'authentification par l'objet maître ; - vérification par l'objet maître que le jeton d'authentification permet ladite action ; - transmission d'un message permettant ladite action en cas de vérification positive. 25 Cette nouvelle réception peut survenir après le transfert dudit jeton d'authentification par l'objet maître mentionné plus haut. Ainsi, au lieu d'interagir directement avec l'objet interne, l'objet demandeur doit s'adresser à l'objet maître. Cela est particulièrement utile si l'objet interne n'a pas la capacité cryptographique de vérifier ledit jeton d'authentification contenant la capacité (ex. l'objet interne est un capteur basse 30 consommation d'ouverture de porte, sans processeur dédié et/ou performant). Dès lors, la vérification des autorisations au sein de la communauté est déléguée à l'objet maître. 30 5 85 40 5 La « transmission d'un message permettant ladite action en cas de vérification positive » peut être un message envoyé directement à l'objet interne (i.e. activant ainsi le service) ou être un message envoyé à l'objet demandeur précisant un secret ou un code d'autorisation temporaire/permanent. Ce code d'autorisation secret peut être utilisé (dans un mode de réalisation particulier) uniquement pour 5 accéder à l'objet interne demandé par le demandeur, directement sans intervention de l'objet maître. En outre, la demande de réalisation d'une action peut viser le fait de rejoindre la communauté, et la transmission dudit message permettant ladite action peut comporter une transmission par l'objet maître d'un jeton de communauté relatif à ladite communauté. 10 Ce jeton de communauté peut permettre d'autoriser l'objet demandeur à rejoindre la communauté. Par ailleurs, le procédé peut comporter en outre : - sur réception dudit jeton de communauté par l'objet maître, mise à jour d'une base de données stockée sur l'objet maître afin d'ajouter un nouveau membre à ladite communauté. 15 Cette mise à jour peut mettre également à jour une base d'attributs répertoriant les attributs des objets de la communauté. Le jeton de communauté peut permettre au demandeur d'accéder aux objets internes qui sont publics dans la communauté. Certains objets internes de la communauté peuvent également être privés : il peut alors être nécessaire de préciser un secret ou un code d'autorisation 20 temporaire/permanent. Dans un autre mode de réalisation, la demande de réalisation d'une action peut viser le fait de communiquer avec un objet interne de la communauté et distinct de l'objet maître, et la transmission dudit message permettant ladite action peut comporter une transmission par l'objet maître d'un jeton 25 d'objet relatif audit objet interne. La réception de la demande peut être en provenance de l'objet demandeur. Spécifiquement, la transmission dudit message permettant ladite action peut comporter en outre 30 une adresse de l'objet interne. 3 0 5 8 5 40 6 Ainsi, l'objet demandeur peut s'adresser directement à l'objet interne après avoir reçu l'autorisation d'interagir avec lui. Cela est notamment utile si l'objet interne est privé dans la communauté. 5 La réception de la liste d'attributs certifiés peut se faire via l'objet maitre. Ainsi, les échanges entre le serveur d'authentification et les autorités de certifications peuvent être limités. Dans un mode de réalisation, la réception de la liste d'attributs certifiés peut se faire via au moins 10 un serveur de certification, ledit serveur de certification ayant certifié au moins un attribut de la liste d'attributs. Par ailleurs, le procédé peut comporter en outre : - négociation entre l'objet demandeur et le serveur d'authentification afin de définir au moins 15 un serveur de certification apte à certifier au moins un attribut de la liste d'attributs. Cette négociation peut être réalisée via l'objet maître. Le procédé peut comporter en outre : - envoi par l'objet demandeur à un serveur de certification d'une demande de certification d'au 20 moins un attribut. L'invention vise également un système de gestion d'autorisation dans une communauté d'objets connectés, ledit système comportant - un objet maître parmi ladite communauté ; 25 - un objet demandeur ; - un serveur d'authentification distinct de l'objet maître ; dans lequel l'objet demandeur comporte : - une interface pour l'émission d'une demande de réalisation d'une action visant : 3058540 7 - la communauté des objets connectés ou - un objet interne de la communauté, l'objet interne étant distinct de l'objet maître ; dans lequel l'objet maître comporte : - une interface pour la réception de ladite demande 5 - un circuit pour le transfert d'un jeton d'authentification provenant du serveur d'authentification vers ledit objet demandeur. dans lequel le serveur d'authentification comporte : - une interface pour la réception d'une liste d'attributs certifiés et associés à l'objet demandeur 10 - un circuit pour la vérification de la liste d'attributs et pour la détermination d'une capacité de l'objet demandeur en fonction de ladite liste d'attributs, - une interface pour l'émission dudit jeton d'authentification comportant ladite capacité vers l'objet maître. 15 L'invention vise également un dispositif apte à être connecté et à faire partie d'une communauté d'objets connectés. Le dispositif comprend : - une interface pour recevoir un message depuis un objet demandeur ; - un processeur adapté pour : - déterminer si ledit message reçu comporte un jeton d'authentification comportant 20 une capacité autorisant une action relative audit dispositif ; - transmettre, en cas de détermination positive, ledit message à un objet maitre de ladite communauté, ledit objet maitre pouvant vérifier une validité dudit jeton d'authentification, - une interface pour recevoir un message réponse dudit objet maître. 25 Le processeur étant en outre adapté pour : - exécuter ladite action relative audit dispositif si le message réponse comporte une indication validant ledit jeton d'authentification. - transmettre un résultat de l'action à l'objet demandeur. 3058540 8 L'invention vise également une méthode pour l'exécution d'une action relative à un dispositif, ledit dispositif étant connecté et faisant partie d'une communauté d'objets connectés, dans lequel la méthode comprend : - recevoir un message depuis un objet demandeur ; 5 - déterminer si ledit message reçu comporte un jeton d'authentification comportant une capacité autorisant l'action relative audit dispositif ; - transmettre, en cas de détermination positive, ledit message à un objet maitre de ladite communauté, ledit objet maitre pouvant vérifier une validité dudit jeton d'authentification, - recevoir un message réponse dudit objet maître ; 10 - exécuter ladite action relative audit dispositif si le message réponse comporte une indication validant ledit jeton d'authentification ; - transmettre un résultat de l'action à l'objet demandeur. L'invention vise également un dispositif apte à être connecté, dans lequel le dispositif comprend : 15 - une interface pour recevoir, d'un objet maitre d'une communauté d'objets connectés, un premier message, ledit premier message contenant un jeton d'authentification comportant une capacité dudit dispositif déterminée en fonction d'une liste d'attributs certifiés; - une interface pour émettre un deuxième message vers un objet de ladite communauté, ledit message contenant ledit jeton et une demande de réalisation d'une action, ladite action 20 étant : - une demande pour rejoindre ladite communauté ou - une demande d'accès à un service proposé par un objet interne de ladite communauté, l'objet interne étant distinct de l'objet maitre; - une interface pour recevoir un troisième message permettant ladite action ou indiquant un 25 résultat de ladite action. L'invention vise également une méthode pour l'exécution d'une action, dans lequel la méthode comprend les étapes suivantes mises en oeuvre par un objet demandeur: - recevoir, d'un objet maitre d'une communauté d'objets connectés, un premier message, ledit 30 premier message contenant un jeton d'authentification comportant une capacité dudit objet 3 0 5 8 5 40 9 demandeur déterminée en fonction d'une liste d'attributs certifiés; - émettre un deuxième message vers un objet de ladite communauté, ledit message contenant ledit jeton et une demande de réalisation d'une action, ladite action étant : - une demande pour rejoindre ladite communauté ou 5 - une demande d'accès à un service proposé par un objet interne de ladite communauté, l'objet interne étant distinct de l'objet maitre; - recevoir un troisième message permettant ladite action ou indiquant un résultat de ladite action. 10 D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - les figures 1 a, 1 b et 1 c illustrent trois modes de réalisation de la détermination d'une capacité d'un objet connecté ; 15 - les figures 2a, 2b et 2c illustrent trois modes de réalisation pour l'utilisation de la capacité d'un objet connecté. La figure 1 a illustre un premier mode de réalisation de la détermination d'une capacité d'un objet connecté. 20 Dans ce mode de réalisation, un objet demandeur 101 souhaite interagir avec : - une communauté 106 d'objets connectés (103, 104, 105) ou - un objet interne de la communauté 106. L'interaction de l'objet demandeur avec la communauté est typiquement le fait, pour l'objet demandeur, de demander de rejoindre la communauté ainsi formée. 25 L'interaction de l'objet demandeur avec un autre objet interne de la communauté est typiquement le fait de demander un contenu à l'objet interne (ex. récupération d'un statut) ou d'accéder à un service proposé par cet objet interne (ex. diffusion de musique, demander l'ouverture d'une porte, etc.). A ce stade, et notamment dans le cas où l'objet demandeur demande d'interagir avec un objet 30 interne de la communauté, l'objet demandeur peut être extérieur à la communauté ou interne à celle- 3058540 10 ci. Lorsque l'objet demandeur souhaite initier cette interaction, il émet une demande 110 en direction d'un objet dit « maître » parmi les objets de la communauté 106. Cet objet maître a été préalablement défini soit par un utilisateur, soit automatiquement (ex. aléatoirement, en fonction d'une disponibilité, 5 en fonction d'une puissance de calcul, etc.). Si l'objet demandeur ne connait pas l'objet maître de la communauté, il peut envoyer une requête « broadcast » pour l'obtenir, ou s'adresser aléatoirement à un membre de la communauté qu'il connait déjà pour obtenir cette information. Cette requête n'est pas représentée ici. Dans un mode particulier, plusieurs objets maîtres peuvent être définis par communauté afin de 10 répartir la charge réseau/de calcul. Une fois la demande 110 reçue par l'objet maître 102, celui-ci peut transférer (message 111) la demande à un serveur d'authentification 107. Ce serveur d'authentification 107 est le plus souvent situé sur Internet, et peut être mutualisé entre plusieurs communautés. Ainsi, il n'y a pas de raison, a priori, que ce serveur d'authentification fasse partie formellement de la communauté 106. 15 Une fois le message 111 reçu, le serveur d'authentification peut fournir une liste d'autorités de certification qu'il accepte ou qui sont reconnues (message 112) à l'objet maître 102. L'objet maître transfère (message 113) alors ce message à l'objet demandeur. L'objet demandeur peut ainsi choisir parmi cette liste d'autorité de certification une autorité qui lui correspond ou avec laquelle il est déjà en contact. Ce choix est concrétisé par l'envoi du message 114 20 contenant l'autorité de certification choisie à l'objet maître. L'objet maître transfère ce choix (message 115) au serveur d'authentification. Les messages 111 à 115 (décrivant la négociation de l'autorité de certification) sont optionnels ici et peuvent être également utilisés dans les autres modes de réalisation, notamment dans ceux décrits par les figures 1 b et lc. 25 Bien entendu, la négociation de l'autorité de certification entre l'objet demandeur et le serveur d'authentification peut se faire directement sans passer par l'objet maître. Si ce choix d'implémentation permet d'éviter de surcharger l'objet maître, il ne permet pas de préserver l'identité du serveur d'authentification. Dans un mode de réalisation, ce choix peut avoir été fait directement dans le message 110 dans 30 lequel l'objet demandeur propose immédiatement une autorité de certification sans négociation préalable - si cette proposition convient, la négociation 112, 113, 114, 115 peut ne pas avoir lieu. Bien entendu, le choix de l'autorité de certification peut consister dans le choix d'une pluralité 3058540 11 d'autorité de certification 108 (ex. le serveur d'authentification peut choisir dans cette pluralité, ou le serveur d'authentification peut faire appel à chaque autorité parmi cette pluralité afin de certifier plusieurs attributs différents). Sur la base de la connaissance de l'autorité de certification choisie, le serveur d'authentification 5 peut envoyer une demande de certification (message 116) à ladite autorité de certification 108 choisie en lui demandant de certifier un attribut (ce dernier pouvant être déterminé ou indéterminé - c'est-à-dire indiqué dans le message de demande de certification ou laissé libre, l'attribut adéquat étant alors choisi par l'autorité de certification) relatif à l'objet demandeur. Cet attribut peut être, par exemple, un numéro de téléphone, une adresse de domicile, une position GPS de l'objet demandeur, etc. 10 Bien entendu, si le serveur d'authentification veut une certification de plusieurs attributs, il est possible de s'adresser à plusieurs autorités de certification différentes (ou à une unique autorité de certification si elle peut le faire). L' (ou les, le cas échéant) autorité de certification peut alors contacter l'objet demandeur (message 117) afin de récupérer l'attribut à certifier (message 118). Cela est notamment utile si l'attribut est 15 susceptible d'évoluer avec le temps. Si l'attribut est statique et que l'autorité de certification le connait déjà, les messages 117 et 118 deviennent optionnels. Une fois l'attribut certifié, l'autorité de certification peut retourner l'attribut certifié (ou les attributs certifiés, le cas échéant) au serveur d'authentification (message 119). Sur la base de l'attribut reçu (ou d'une liste d'attributs reçue), le serveur d'authentification peut 20 déterminer quelle(s) est(sont) la capacité (les capacités) de l'objet demandeur (i.e. la ou les actions autorisées pour l'objet demandeur) en comparant l'attribut ou la liste d'attributs avec une base de données de règles de sécurité (ex. la base de données peut contenir « autoriser l'ouverture de la porte du garage par les objets ayant comme attribut le numéro de téléphone 06xxxxxxxx et une position GPS située dans un rayon de 300m autour de la maison »). Dans cet exemple, l'objet 25 demandeur aura la capacité d'autoriser l'ouverture de la porte du garage si la règle « le numéro de téléphone est le 06xxxxxxxx et la position GPS est située dans un rayon de 300m autour de la maison » est vérifiée. Les capacités et les règles peuvent être préenregistrées pour une communauté donnée. Les capacités peuvent être liées à un ou plusieurs objets de la communauté voir à tous les objets de la 30 communauté. Le jeton comportant la capacité peut ainsi prendre la forme de la structure de données suivante : "id": "7g3vfT 0q2x-7", 3058540 12 "ii": 1415174237, "is": "issuer@TrustedSharing.orange.com", "su": "zNwS5FetB4rwzSKsWwSBAx=", "co": "coap://aaaa : : 7/" : [ 5 { "de": "coap://sensorgate.parking", "si": "SbUudG4zuXswFBxDeHB87N6t9h1=", "ar": [ { 10 "ac": "PUT", "se": "door", "c": } ] 15 "de": "coap://sensorlight.floorl.Bob", "si": "SbUudG4zuXswFBxDeHB87N6t9h=", "ar": [ { "ac": "GET", 20 "re": "temperature", "c": 25 } "nb": 1415174237, 305 85 40 13 "na" : 1415175381 avec notamment les variables suivantes : - id: l'identifiant du jeton de capacité, 5 - ii : la date d'émission du jeton (ex. nombre de secondes depuis le 1 er janvier 1970), - is : l'identification de la personne qui a signé le jeton ; - nb : la date minimale d'utilisation du jeton (ex. nombre de secondes depuis le 1 er janvier 1970), - na : la date maximale d'utilisation du jeton (ex. nombre de secondes depuis le 1 er janvier 10 1970), - de : l'identification de l'objet interne visé par la capacité, - co : le nom de la communauté, - si : la signature du jeton, - ar : les droits associés à la capacité, 15 - ac : la description de l'action autorisée (ex. GET, POST, PUT, DELETE), - se: le service fourni par l'objet interne, - c: un ensemble de conditions correspondant à l'action (ex. diffusion de la musique que si aucune musique n'est en cours de diffusion), 20 La figure 1 b illustre un deuxième mode de réalisation de la détermination d'une capacité d'un objet connecté. Dans ce mode de réalisation, les échanges entre le serveur d'authentification et les autorités de certifications sont limités. Pour autant, l'esprit de l'invention reste identique. Tout d'abord, l'objet demandeur contacte une autorité de certification 108 (message 121) afin de lui 25 transmettre un attribut ou une pluralité d'attributs à certifier. Bien entendu, et comme précédemment, une pluralité d'autorités de certification peut être utilisée. L'autorité de certification signe l'attribut et retourne celui-ci à l'objet demandeur 101 (message 122). 3058540 14 Dès lors, l'objet demandeur peut envoyer sa demande d'interaction (message 123 - correspondant au message 101 dans le mode de réalisation précédent) à l'objet maître, accompagné de l'attribut certifié. Cette demande est alors transférée (message 124) au serveur d'authentification 107. Bien 5 entendu, le serveur d'authentification possède une relation de confiance avec l'autorité de certification ayant certifié l'attribut transmis (ex. il possède la clef publique de l'autorité de certification) : ainsi, le serveur d'authentification peut vérifier que la signature de l'attribut a bien été effectuée par l'autorité de certification qui est indiquée dans le message 124. Si aucune relation de confiance n'existe entre l'autorité de certification et le serveur d'authentification, le serveur d'authentification : 10 - peut refuser la transaction en demandant à l'objet demandeur de changer d'autorité de certification, - peut demander à l'autorité de certification de s'authentifier et/ou de lui communiquer sa clef publique de manière sécurisée (ex. via un système de gestion de clefs connu dans le domaine du chiffrement/signature asymétrique). 15 Bien entendu, si l'objet demandeur a déjà demandé à une autorité de certification de signer/certifier un de ses attributs (et que celui-ci n'a pas changé / que la certification est toujours valable), il n'est nul besoin d'échanger les messages 121 et 122. La figure 1c illustre un troisième mode de réalisation de la détermination d'une capacité d'un objet 20 connecté. Dans ce mode de réalisation, le message 130 (respectivement 131) est identique/similaire au message 110 (respectivement 111). Une fois la demande reçue par le serveur d'authentification, celui-ci peut demander (message 132) à une autorité de certification 108 de certifier un attribut associé à l'objet demandeur (l'autorité de 25 certification en question peut avoir été préalablement négociée ou être proposée dans le message 131). Ainsi, l'autorité de certification 108 s'adresse (message 133) à l'objet demandeur afin que celui-ci renvoie (message 134) l'attribut à certifier. Une fois certifié, l'attribut est envoyé (message 135) à l'objet demandeur. 30 L'attribut certifié peut alors être transféré au serveur d'authentification via l'objet maître 102 (messages 136 et 137). De la même manière que les modes de réalisation précédents, le serveur d'authentification peut 3 0 5 8 5 40 15 alors vérifier la signature de l'attribut (i.e. le fait que la certification est correcte) et déterminer la capacité adéquate de l'objet demandeur, c'est-à-dire la ou les actions qu'il est autorisé à réaliser. La figure 2a illustre un premier mode de réalisation pour l'utilisation de la capacité d'un objet 5 connecté. Après vérification de la liste d'attributs par le serveur d'authentification 107 et détermination de la capacité de l'objet demandeur (voir description relative aux figures 1 a à 1c) en fonction de ladite liste d'attributs, le serveur d'authentification envoie un jeton de capacité à l'objet maître (message 201) et l'objet maître le renvoie à l'objet demandeur (message 202). Ce jeton est signé par le serveur 10 d'authentification. Bien entendu, les messages 201 et 202 peuvent être remplacés par un unique message entre le serveur d'authentification et l'objet demandeur. Une fois reçu, l'objet demandeur peut s'adresser (message 203) à l'objet maître en demandant un accès à un service proposé par un objet interne donné (ex. objet 103) ou en demandant à rejoindre la 15 communauté 106, en joignant au message 203 le jeton signé. L'objet maître peut alors vérifier que le jeton est valide et confère bien les droits permettant la réalisation de l'action demandée (ex. vérification de la signature cryptographique / asymétrique). Si le jeton n'est pas valable ou ne permet pas d'effectuer l'action demandée, l'objet maître peut envoyer un message d'erreur à l'objet demandeur (non représenté ici). 20 Si la demande du message 203 concerne le fait de rejoindre la communauté 106, l'objet maître peut mettre à jour une base de données interne contenant une liste des objets de la communauté afin d'ajouter l'objet demandeur comme nouveau membre de cette communauté. Par ailleurs, il est possible de mettre à jour une base de données (la même que précédemment ou une base de données différente) afin d'indiquer les attributs du nouveau membre, pour une réutilisation future. Les 25 échanges de messages peuvent s'arrêter à ce stade. Si la demande concerne le fait d'accéder à un service d'un objet interne à la communauté, l'objet maître peut transférer la demande audit objet interne 103 (message 204) qui y répond (message 205) car l'objet maître est reconnu. Cette réponse est transférée (message 206) à l'objet demandeur. Une capacité permettant de rejoindre une communauté peut être comprise dans un jeton dit « de 30 communauté ». Une capacité permettant d'interagir avec un objet interne peut être comprise dans un jeton dit « d'objet». 3 0 5 8 5 40 16 La figure 2b illustre un deuxième mode de réalisation pour l'utilisation de la capacité d'un objet connecté. Dans ce mode de réalisation, le message 211 (respectivement 212, 213) est identique/similaire au 5 message 201 (respectivement 202, 203). Une fois le message 213 reçu, l'objet maître peut vérifier que la capacité est valide et confère bien les droits qui y sont indiqués. Si la capacité n'est pas valable ou ne permet pas d'effectuer l'action demandée, l'objet maître peut envoyer un message d'erreur à l'objet demandeur (non représenté ici). Une fois la capacité vérifiée, l'objet maître peut indiquer à l'objet demandeur l'adresse de l'objet 10 interne 103 faisant l'objet d'une demande d'interaction. Cette adresse peut être accompagnée, par exemple, d'un mot de passe (ex. temporaire) ou d'un jeton d'authentification (ex. certificat) permettant d'activer le service auprès de l'objet interne. Ainsi, l'objet demandeur peut se connecter (message 215) sur l'objet interne 103 en utilisant le mot de passe ou le jeton d'authentification et ainsi obtenir les informations demandées (message 216). 15 La figure 2c illustre un troisième mode de réalisation pour l'utilisation de la capacité d'un objet connecté. Dans ce mode de réalisation, le message 221 (respectivement 222) est identique/similaire au message 201 (respectivement 202). 20 Dans ce mode de réalisation, l'objet demandeur se connecte directement (message 223) à l'objet interne 103, souhaitant interagir avec le service de cet objet interne. Dans le message 223, l'objet demandeur joint le jeton d'objet (décrivant sa capacité transmise dans le message 222). N'ayant pas la capacité technique, la capacité en termes de puissance ou simplement ne souhaitant pas vérifier ce jeton d'objet / cette capacité, l'objet interne peut demander à l'objet maître 25 de la vérifier pour lui (message 224). Une fois vérifié, le résultat de cette vérification est envoyé à l'objet interne (message 225), qui décide alors si l'interaction demandée doit être réalisée (message 226). Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à 30 titre d'exemples ; elle s'étend à d'autres variantes. D'autres réalisations sont possibles. REVENDICATIONS1. Procédé de gestion d'autorisation dans une communauté (106) d'objets connectés (103, 104, 105), un objet maitre étant déterminé dans ladite communauté, le procédé comportant : - réception par l'objet maître (102) depuis un objet demandeur (101) d'une demande (110, 123, 130) de réalisation d'une action visant : - la communauté (106) des objets connectés (103, 104, 105) ou - un objet interne de la communauté (106), l'objet interne étant distinct de l'objet maître (102); - réception (119, 124, 137) d'une liste d'attributs certifiés et associés à l'objet demandeur (101) par un serveur d'authentification (107) distinct de l'objet maître (102) ; - après vérification de la liste d'attributs par le serveur d'authentification (107) et détermination d'une capacité de l'objet demandeur (101) en fonction de ladite liste d'attributs, réception (201, 211, 221) par l'objet maître (102) d'un jeton d'authentification comportant ladite capacité ; - transfert (202, 212, 222) dudit jeton d'authentification par l'objet maître (102) vers ledit objet demandeur (101). 2. Procédé selon la revendication 1, dans lequel le procédé comporte en outre : - réception (203, 213, 224) dudit jeton d'authentification par l'objet maître (102) ; - vérification par l'objet maître (102) que le jeton d'authentification permet ladite action ; - transmission (206, 214, 225) d'un message permettant ladite action en cas de vérification positive. 3. Procédé selon la revendication 2, dans lequel la demande (110, 123, 130) de réalisation d'une action vise le fait de rejoindre la communauté (106), et dans lequel la transmission (206, 214, 225) dudit message permettant ladite action comporte une transmission par l'objet maître (102) d'un jeton de communauté relatif à ladite communauté (106). 3 0 5 8 5 40 18 4. Procédé selon la revendication 3, dans lequel le procédé comporte en outre : - sur réception dudit jeton de communauté par l'objet maître (102), mise à jour d'une base de données stockée sur l'objet maître (102) afin d'ajouter un nouveau membre à ladite 5 communauté (106). 5. Procédé selon la revendication 2, dans lequel la demande (110, 123, 130) de réalisation d'une action vise le fait de communiquer avec un objet interne (103) de la communauté (106) et distinct de l'objet maître (102), et dans lequel la transmission dudit message permettant ladite action comporte 10 une transmission (214) par l'objet maître (102) d'un jeton d'objet relatif audit objet interne. 6. Procédé selon l'une des revendications précédentes, dans lequel la réception de la demande (110, 123, 130) est en provenance de l'objet demandeur (101). 15 7. Procédé selon la revendication 5 ou 6, dans lequel la transmission dudit message permettant ladite action comporte en outre une adresse de l'objet interne (103). 8. Procédé selon l'une des revendications précédentes dans lequel la réception de la liste d'attributs certifiés se fait via l'objet maitre (102). 20 9. Procédé selon l'une des revendications précédentes, dans lequel la réception de la liste d'attributs certifiés se fait via au moins un serveur de certification (108), ledit serveur de certification (108) ayant certifié au moins un attribut de la liste d'attributs. 25 10. Procédé selon l'une des revendications précédentes, dans lequel le procédé comporte en outre : - négociation entre l'objet demandeur (101) et le serveur d'authentification (107) afin de définir au moins un serveur de certification (108) apte à certifier au moins un attribut de la liste d'attributs. 3058540 19 11. Procédé selon l'une des revendications précédentes, dans lequel le procédé comporte en outre : - envoi par l'objet demandeur (101) à un serveur de certification (108) d'une demande (110, 123, 130) de certification d'au moins un attribut. 5 12. Dispositif (103) apte à être connecté et à faire partie d'une communauté (106) d'objets connectés, dans lequel le dispositif comprend : - une interface pour recevoir un message (223) depuis un objet demandeur ; 10 - un processeur adapté pour : - déterminer si ledit message (223) reçu comporte un jeton d'authentification comportant une capacité autorisant une action relative audit dispositif ; - transmettre (224), en cas de détermination positive, ledit message à un objet maitre de ladite communauté, ledit objet maitre pouvant vérifier une validité dudit 15 jeton d'authentification, - une interface pour recevoir un message réponse (225) dudit objet maître ; le processeur étant en outre adapté pour : - exécuter ladite action relative audit dispositif si le message réponse comporte une indication validant ledit jeton d'authentification ; 20 - transmettre (226) un résultat de l'action à l'objet demandeur. 13. Méthode pour l'exécution d'une action relative à un dispositif (103), ledit dispositif étant connecté et faisant partie d'une communauté (106) d'objets connectés, dans lequel la méthode comprend : 25 - recevoir un message (223) depuis un objet demandeur ; - déterminer si ledit message (223) reçu comporte un jeton d'authentification comportant une capacité autorisant l'action relative audit dispositif ; - transmettre (224), en cas de détermination positive, ledit message à un objet maitre de ladite communauté, ledit objet maitre pouvant vérifier une validité dudit jeton d'authentification, 30 - recevoir un message réponse (225) dudit objet maître ; 3058540 20 - exécuter ladite action relative audit dispositif si le message réponse comporte une indication validant ledit jeton d'authentification ; - transmettre (226) un résultat de l'action à l'objet demandeur. 5 14. Dispositif (101) apte à être connecté, dans lequel le dispositif comprend : - une interface pour recevoir, d'un objet maitre d'une communauté d'objets connectés, un premier message (202, 212, 222), ledit premier message contenant un jeton d'authentification comportant une capacité dudit dispositif déterminée en fonction d'une liste d'attributs certifiés; 10 - une interface pour émettre un deuxième message (203, 213, 223) vers un objet de ladite communauté, ledit message contenant ledit jeton et une demande de réalisation d'une action, ladite action étant : - une demande pour rejoindre ladite communauté ou - une demande d'accès à un service proposé par un objet interne de ladite 15 communauté, l'objet interne étant distinct de l'objet maitre; - une interface pour recevoir un troisième message (206, 214, 226) permettant ladite action ou indiquant un résultat de ladite action. 15. Méthode pour l'exécution d'une action, dans lequel la méthode comprend les étapes suivantes 20 mises en oeuvre par un objet demandeur: - recevoir, d'un objet maitre d'une communauté d'objets connectés, un premier message (202, 212, 222), ledit premier message contenant un jeton d'authentification comportant une capacité dudit objet demandeur déterminée en fonction d'une liste d'attributs certifiés; - émettre un deuxième message (203, 213, 223) vers un objet de ladite communauté, ledit 25 message contenant ledit jeton et une demande de réalisation d'une action, ladite action étant : - une demande pour rejoindre ladite communauté ou - une demande d'accès à un service proposé par un objet interne de ladite communauté, l'objet interne étant distinct de l'objet maitre; 30 - recevoir un troisième message (206, 214, 226) permettant ladite action ou indiquant un 3058540 résultat de ladite action. 21