WO2018087483A1 - Procédé de gestion d'autorisation dans une communauté d'objets connectes - Google Patents

Procédé de gestion d'autorisation dans une communauté d'objets connectes Download PDF

Info

Publication number
WO2018087483A1
WO2018087483A1 PCT/FR2017/053063 FR2017053063W WO2018087483A1 WO 2018087483 A1 WO2018087483 A1 WO 2018087483A1 FR 2017053063 W FR2017053063 W FR 2017053063W WO 2018087483 A1 WO2018087483 A1 WO 2018087483A1
Authority
WO
WIPO (PCT)
Prior art keywords
community
message
action
master
requesting
Prior art date
Application number
PCT/FR2017/053063
Other languages
English (en)
Inventor
Dina HUSSEIN
Emmanuel Bertin
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Priority to US16/345,795 priority Critical patent/US11277396B2/en
Priority to EP17808543.7A priority patent/EP3539272A1/fr
Publication of WO2018087483A1 publication Critical patent/WO2018087483A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present invention relates to the field of authorization management, in particular for connected objects.
  • the Internet of Things (or loT) is a technological trend to connect a large number of everyday objects via the Internet to provide services.
  • These objects can be objects of the domestic environment (boiler, refrigerator, door, lamp, alarm, car %), of the professional environment, or related to specific sectors of activity (health and medicine, well-being be and sport, factory and production tools, smart cities, energy and transport, etc.).
  • These objects are usually called “connected objects” or “smart objects” (“smart objects” (“smart objects” in English). They can be objects of the physical world (eg a watch), but also virtual resources (eg an email account).
  • ACL Access Control List
  • RBAC Role Based Access Control
  • IBAC Identity Based Access Control
  • ABAC Attribute Based Access Control
  • Capability Based Access Control where each object will accept or not the connection with other objects according to their capacity.
  • a capability is a unique key (or token) that is associated only with a requesting object to enable it to perform certain actions on the requested object.
  • This token is typically issued by a centralized entity in a complex manner where the actions authorized by the token and the validity period of the token and other conditions must be manually specified using a certain interface to generate and send this token.
  • the present invention improves the situation.
  • the present invention thus aims at a method of authorization management method in a community of connected objects, a master object being determined in said community, the method comprising:
  • an internal object of the community being distinct from the master object
  • a community is a coherent set of connected objects. This community can be automatic (eg all objects related to music, all objects related to home security, etc.). The community can also be manually defined by the user. In addition, belonging to a community does not exclude membership in another distinct community. To be part of a community, it is often necessary to have been authorized. In any case, a community in the sense of connected objects is a set of objects whose list is defined, this list being stored for example in a local or distributed database (ie it is not only a conceptual set objects). Most of the time, community objects have a special relationship of trust between them.
  • the request for realization of an action targeting the community of connected objects can be in particular the fact of joining the community.
  • the request for carrying out an action aimed at an internal object of the community can be in particular the fact of interacting with this internal object or of accessing one of the services it proposes.
  • Attribute a feature associated with the object. This characteristic is often intrinsic to the object or its situation (eg telephone number, GPS position of the object, type of terminal, etc.). Attributes should not be confused with simple identifiers or roles that would be assigned to the object (see above).
  • a "certified attribute” is an attribute whose accuracy has been certified by a trusted third party, most often called a certification authority. Certification is most often done by affixing a digital signature (eg asymmetrical cryptographic signature).
  • An object's "capacity” is a set of permissions (possibly only one) describing the different actions / rights that this object has in a given context. For example, a given capacity can allow an object: - to broadcast music on a predetermined radio station between 7 am and 8 pm each day, or
  • this ability takes the form of a token (or "token” in English) describing, in the form of bytes, the various actions / rights.
  • This token is usually signed by a trusted authority (eg an attribute management server or more generally an authentication server or AS for “authentication server”).
  • the authentication server can verify the certification of attributes and determine from a set of rules which capability to attribute based on the attributes. These capabilities can be predefined from defined and associated rules.
  • the architecture proposed by the invention allows flexible rights management without excessive centralization.
  • the authority having certified the attributes may be distinct from the authentication server. This thus allows a wide choice of certification authorities (or even the use of a plurality of certification authorities, each authority certifying a subset of the list of attributes transmitted to the authentication server).
  • the invention proposes to avoid direct communication between the authentication server and the requesting object for security reasons. Indeed, it may be useful for a requesting object, third party to the network, not to be able to discover the address of the authentication server by conventional network discovery mechanisms.
  • the method may further comprise:
  • This new reception may occur after the transfer of said authentication token by the master object mentioned above.
  • the requesting object instead of interacting directly with the internal object, the requesting object must address the master object. This is particularly useful if the internal object does not have the cryptographic capability to verify said authentication token containing the capability (eg, the internal object is a low-power door-opening sensor, without a dedicated processor and / or efficient).
  • the "transmission of a message allowing said action in case of positive verification” can be a message sent directly to the internal object (ie activating the service) or a message sent to the requesting object specifying a secret or a code temporary / permanent authorization.
  • This secret authorization code can be used (in a particular embodiment) only to access the internal object requested by the requestor, directly without intervention of the master object.
  • the request for carrying out an action may be directed at joining the community, and the transmission of said message enabling said action may include transmission by the master object of a community token relating to said community.
  • This community token can be used to allow the requesting object to join the community.
  • the method may further comprise:
  • update of a database stored on the master object upon reception of said community token by the master object, update of a database stored on the master object in order to add a new member to said community.
  • This update can also update an attribute database that lists the attributes of the objects in the community.
  • the community token can allow the requester access to internal objects that are public in the community. Some internal objects in the community may also be private: it may be necessary to specify a secret or a temporary / permanent authorization code.
  • the request to perform an action may be to communicate with an internal object of the community and separate from the master object, and the transmission of said message allowing said action may include a transmission by the user. master object of an object token relative to said internal object.
  • the receipt of the request may be from the requesting object.
  • the transmission of said message allowing said action may further comprise an address of the internal object.
  • the requesting object can directly address the internal object after receiving permission to interact with it.
  • the receipt of the list of certified attributes can be done via the master object.
  • receipt of the list of certified attributes can be done via at least one certification server, said certification server having certified at least one attribute of the list of attributes.
  • the method may further comprise:
  • This negotiation can be done via the master object.
  • the method may further comprise:
  • the invention also aims at an authorization management system in a community of connected objects, said system comprising
  • an internal object of the community the internal object being distinct from the master object; in which the master object comprises:
  • the authentication server comprises:
  • the invention also relates to a device able to be connected and to be part of a community of connected objects.
  • the device comprises:
  • the processor is further adapted for:
  • the invention also provides a method for executing an action relating to a device, said device being connected and forming part of a community of connected objects, wherein the method comprises:
  • the invention also relates to a device that can be connected, in which the device comprises: an interface for receiving, from a master object of a community of connected objects, a first message, said first message containing a token of authentication having a capacity of said device determined according to a list of certified attributes;
  • the invention also provides a method for executing an action, wherein the method comprises the following steps implemented by a requesting object:
  • FIGS. 1a, 1b and 1c illustrate three embodiments of the determination of a capacity of a connected object
  • FIGS. 2a, 2b and 2c illustrate three embodiments for using the capacity of a connected object.
  • Figure 1a illustrates a first embodiment of determining a capacity of a connected object.
  • a requesting object 1 01 wishes to interact with:
  • the interaction of the requesting object with the community is typically the fact, for the requesting object, of asking to join the community thus formed.
  • the interaction of the requesting object with another internal object of the community is typically the fact of requesting a content from the internal object (eg recovery of a status) or to access a service proposed by this internal object (eg music broadcast, request the opening of a door, etc.).
  • the requesting object may be outside the community or internal to the community. this.
  • the requesting object When the requesting object wishes to initiate this interaction, it sends a request 1 10 towards a so-called "master" object among the objects of the community 106.
  • This master object has been previously defined either by a user or automatically (ex randomly, depending on availability, as a function of computing power, etc.).
  • the requesting object does not know the master object of the community, it can send a broadcast request to obtain it, or randomly address a community member it already knows to get this information. This query is not represented here.
  • multiple master objects can be defined per community to distribute the network / computing load.
  • the master object 102 can transfer (message 11) the request to an authentication server 107.
  • This authentication server 107 is most often located on the Internet. and can be shared between several communities. Thus, there is no reason, a priori, that this authentication server is formally part of the community 106.
  • the authentication server can provide a list of authorization authorities. certification it accepts or are recognized (message 1 12) to the master object 102. The master object transfers (message 1 13) then this message to the requesting object.
  • the requesting object can thus choose from this list of certification authority an authority which corresponds to it or with which it is already in contact. This choice is concretized by sending the message 1 14 containing the certification authority chosen to the master object.
  • the master object transfers this choice (message 1 15) to the authentication server.
  • the messages 1 1 1 to 1 1 5 (describing the negotiation of the certification authority) are optional here and can also be used in the other embodiments, in particular in those described in FIGS. 1b and 1c.
  • the negotiation of the certification authority between the requesting object and the authentication server can be done directly without passing through the master object. If this choice of implementation makes it possible to avoid overloading the master object, it does not make it possible to preserve the identity of the authentication server.
  • this choice may have been made directly in the message 1 10 in which the requesting object immediately proposes a certification authority without prior negotiation - if this proposal is suitable, the negotiation 1 12, 1 13, 1 14, 1 1 5 may not occur.
  • the choice of the certification authority may consist in choosing a plurality certification authority 108 (eg the authentication server may choose from this plurality, or the authentication server may use each authority among this plurality to certify several different attributes).
  • the authentication server may send a certification request (message 1 16) to the selected certification authority 108 requesting it to certify an attribute (the latter being determinable or indeterminate - that is, indicated in the certification request message or left free, the appropriate attribute then being chosen by the certification authority) relating to the requesting object.
  • This attribute can be, for example, a phone number, a home address, a GPS position of the requesting object, etc.
  • the authentication server wants certification of several attributes, it is possible to approach several different certification authorities (or a single certification authority if it can do so).
  • the (or the, if any) certification authority can then contact the requesting object (message 1 17) to retrieve the attribute to be certified (message 1 1 8). This is especially useful if the attribute is likely to evolve over time. If the attribute is static and the CA already knows it, the messages 17 and 18 become optional.
  • the CA may return the certified attribute (or the certified attributes, if any) to the authentication server (message 1 19).
  • the authentication server can determine which (s) is the capability (capabilities) of the requesting object (the. or the actions allowed for the requesting object) by comparing the attribute or the list of attributes with a database of security rules (eg the database may contain "authorizing the opening of the garage door by objects having as attribute the phone number 06xxxxxxxx and a GPS position located within a radius of 300m around the house ").
  • the requesting object will have the ability to authorize the opening of the garage door if the rule "the phone number is 06xxxxxxxx and the GPS position is within 300m of the house” is verified.
  • Abilities and rules can be prerecorded for a given community. Abilities can be linked to one or more objects in the community to see all objects in the community.
  • the token with the capacity can thus take the form of the following data structure:
  • - id the identifier of the capacity token
  • - ii the date of issue of the token (eg number of seconds since January 1, 1970)
  • - is: the identification of the person who signed the token
  • - ar the rights associated with the capacity
  • - ac the description of the authorized action (eg GET, POST, PUT, DELETE)
  • - c a set of conditions corresponding to the action (eg broadcasting of music only if no music is being broadcast),
  • Figure 1b illustrates a second embodiment of determining a capacity of a connected object.
  • the requesting object contacts a certification authority 108 (message 121) to transmit an attribute or a plurality of attributes to be certified.
  • a certification authority 108 message 121
  • a plurality of certification authorities can be used.
  • the CA signs the attribute and returns it to the requesting object 101 (message Therefore, the requesting object can send its interaction request (message 123 - corresponding to the message 101 in the previous embodiment) to the master object, accompanied by the certified attribute.
  • This request is then transferred (message 124) to the authentication server 107.
  • the authentication server has a relationship of trust with the certification authority having certified the attribute transmitted (eg it has the public key of the certification authority): thus, the authentication server can verify that the signature of the attribute has been done by the certification authority that is indicated in the message 124. If no trust relationship exists between the certification authority and the authentication server, the authentication server: - may refuse the transaction by asking the requesting object to change the certification authority,
  • - may request the CA to authenticate itself and / or communicate its public key in a secure manner (eg via a key management system known in the field of asymmetric encryption / signature).
  • a certification authority may sign / certify one of its attributes (and that it has not changed / the certification is still valid), there is no need to exchange messages 121 and 122.
  • Figure 1c illustrates a third embodiment of determining a capacity of a connected object.
  • the message 130 (respectively 131) is identical / similar to the message 1 1 0 (respectively 1 1 1).
  • the authentication server can request (message 132) from a certification authority 108 to certify an attribute associated with the requesting object (the certification authority in question may have been previously negotiated or be proposed in the message 131).
  • the certification authority 108 addresses (message 133) to the requesting object so that it returns (message 134) the attribute to be certified.
  • the attribute is sent (message 135) to the requesting object.
  • the certified attribute can then be transferred to the authentication server via the master object 102 (messages 136 and 137).
  • the authentication server can then check the signature of the attribute (ie the fact that the certification is correct) and determine the adequate capacity of the requesting object, that is to say the action or actions that it is authorized to perform.
  • Figure 2a illustrates a first embodiment for using the capacity of a connected object.
  • the server d After verification of the list of attributes by the authentication server 1 07 and determination of the capacity of the requesting object (see description relating to FIGS. 1a to 1c) according to said list of attributes, the server d The authentication sends a capacity token to the master object (message 201) and the master object sends it back to the requesting object (message 202). This token is signed by the authentication server.
  • the messages 201 and 202 can be replaced by a single message between the authentication server and the requesting object.
  • the requesting object may address (message 203) to the master object by requesting access to a service provided by a given internal object (eg object 103) or by requesting to join the community 106, joining the message 203 the signed token.
  • a service provided by a given internal object (eg object 103) or by requesting to join the community 106, joining the message 203 the signed token.
  • the master object can then verify that the token is valid and gives the right to perform the requested action (eg verification of the cryptographic / asymmetric signature). If the token is invalid or does not perform the requested action, the master object may send an error message to the requesting object (not shown here). If the request for message 203 is for joining community 106, the master object can update an internal database containing a list of community objects in order to add the requesting object as a new member of that community. . In addition, it is possible to update a database (the same as before or a different database) to indicate the attributes of the new member, for future reuse. Message exchanges can stop at this point.
  • the master object can transfer the request to said internal object 1 03 (message 204) which responds to it (message 205) because the master object is well-known. This response is transferred (message 206) to the requesting object.
  • An ability to join a community can be included in a "community" token.
  • Figure 2b illustrates a second embodiment for using the capacity of a connected object.
  • the message 21 1 (respectively 212, 213) is identical / similar to the message 201 (respectively 202, 203).
  • the master object can verify that the capacity is valid and correctly confers the rights indicated therein. If the capacity is invalid or does not perform the requested action, the master object may send an error message to the requesting object (not shown here).
  • the master object can indicate to the requesting object the address of the internal object 103 that is the subject of an interaction request.
  • This address may be accompanied, for example, by a password (eg temporary) or an authentication token (eg certificate) to activate the service with the internal object.
  • the requesting object can connect (message 215) to the internal object 103 using the password or the authentication token and thereby obtain the requested information (message 216).
  • Fig. 2c illustrates a third embodiment for using the capacity of a connected object.
  • the message 221 (respectively 222) is identical / similar to the message 201 (respectively 202).
  • the requesting object connects directly (message 223) to the internal object 103, wishing to interact with the service of this internal object.
  • message 223 the requesting object joins the object token (describing its transmitted capability in message 222).
  • the internal object can ask the master object to check for it (message 224). Once verified, the result of this check is sent to the internal object (message 225), which then decides whether the requested interaction should be performed (message 226).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé de gestion d'autorisation dans une communauté (106) d'objets connectés (103, 104, 105), un objet maître étant déterminé dans ladite communauté, le procédé comportant : - réception par l'objet maître (102) 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 (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 vers ledit objet demandeur (101).

Description

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 nombre d'objets augmente.
- un contrôle d'accès par rôle (ou RBAC pour « Rôle 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 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 (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 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 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 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. 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 maître é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 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 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. 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é 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 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 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). 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 : - 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 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 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 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.
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. 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 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. 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 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é. 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é. 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 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 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 une adresse de l'objet interne. 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é.
La réception de la liste d'attributs certifiés peut se faire via l'objet maître.
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 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 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 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é ; - 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 : - 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
- 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
- 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.
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 une capacité autorisant une action relative audit dispositif ;
- transmettre, en cas de détermination positive, ledit message à un objet maître de ladite communauté, ledit objet maître pouvant vérifier une validité dudit jeton d'authentification,
- une interface pour recevoir un message réponse 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.
- transmettre un résultat de l'action à l'objet demandeur. 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 ; - 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 maître de ladite communauté, ledit objet maître pouvant vérifier une validité dudit jeton d'authentification,
- recevoir un message réponse dudit objet maître ; - 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 : - une interface pour recevoir, d'un objet maître 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 é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 maître;
- une interface pour recevoir un troisième message permettant ladite action ou indiquant un 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 maître d'une communauté d'objets connectés, un premier message, 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 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 communauté, l'objet interne étant distinct de l'objet maître;
- recevoir un troisième message permettant ladite action ou indiquant un résultat de ladite action.
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é ; - 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é. Dans ce mode de réalisation, un objet demandeur 1 01 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. 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 interne de la communauté, l'objet demandeur peut être extérieur à la communauté ou interne à celle- ci.
Lorsque l'objet demandeur souhaite initier cette interaction, il émet une demande 1 10 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é, en fonction d'une puissance de calcul, etc.).
Si l'objet demandeur ne connaît 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 connaît 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 répartir la charge réseau/de calcul.
Une fois la demande 1 10 reçue par l'objet maître 102, celui-ci peut transférer (message 1 1 1 ) la demande à un serveur d'authentification 107. Ce serveur d'authentification 1 07 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. Une fois le message 1 1 1 reçu, le serveur d'authentification peut fournir une liste d'autorités de certification qu'il accepte ou qui sont reconnues (message 1 12) à l'objet maître 102. L'objet maître transfère (message 1 13) 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 1 14 contenant l'autorité de certification choisie à l'objet maître.
L'objet maître transfère ce choix (message 1 15) au serveur d'authentification.
Les messages 1 1 1 à 1 1 5 (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 1 c. 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 1 10 dans lequel l'objet demandeur propose immédiatement une autorité de certification sans négociation préalable - si cette proposition convient, la négociation 1 12, 1 13, 1 14, 1 1 5 peut ne pas avoir lieu.
Bien entendu, le choix de l'autorité de certification peut consister dans le choix d'une pluralité 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 peut envoyer une demande de certification (message 1 16) à 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. 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 1 17) afin de récupérer l'attribut à certifier (message 1 1 8). Cela est notamment utile si l'attribut est susceptible d'évoluer avec le temps. Si l'attribut est statique et que l'autorité de certification le connaît déjà, les messages 1 17 et 1 18 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 1 19).
Sur la base de l'attribut reçu (ou d'une liste d'attributs reçue), le serveur d'authentification peut déterminer quelle(s) est(sont) la capacité (les capacités) de l'objet demandeur (Le. 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 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 communauté.
Le jeton comportant la capacité peut ainsi prendre la forme de la structure de données suivante :
{
"id": "7g3vfT_0q2x-7", "ii": 1415174237,
"is" : "issuer@TrustedSharing . orange . corn" , "su" : "zNwS5FetB4rwzSKsWwSBAx=",
"co": "coap://aaaa : : 7/" : [
{
"de" : "coap : / /sensorgâte . parking" , "si" : "SbUudG4zuXswFBxDeHB87N6t9hl=",
ac": "PUT"
se": "door
"de" : "coap: / / sensorlight . floorl .Bob", "si" : "SbUudG4zuXswFBxDeHB87N6t9h=", "ar": [
{
"ac": "GET" ,
"re": "température",
'nb": 1415174237, "na": 1415175381
} avec notamment les variables suivantes :
- id: l'identifiant du jeton de capacité, - 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 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é, - 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),
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 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 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 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 : - 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). 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 1 c illustre un troisième mode de réalisation de la détermination d'une capacité d'un objet connecté.
Dans ce mode de réalisation, le message 130 (respectivement 131 ) est identique/similaire au message 1 1 0 (respectivement 1 1 1 ).
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 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. 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 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 connecté.
Après vérification de la liste d'attributs par le serveur d'authentification 1 07 et détermination de la capacité de l'objet demandeur (voir description relative aux figures 1 a à 1 c) 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 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 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). 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 é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 1 03 (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 communauté ».
Une capacité permettant d'interagir avec un objet interne peut être comprise dans un jeton dit « d'objet». 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 21 1 (respectivement 212, 213) est identique/similaire au 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 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).
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). 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 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 à titre d'exemples ; elle s'étend à d'autres variantes.
D'autres réalisations sont possibles.

Claims

REVENDICATIONS
1 . Procédé de gestion d'autorisation dans une communauté (106) d'objets connectés (103, 1 04, 1 05), un objet maître étant déterminé dans ladite communauté, le procédé comportant :
- réception par l'objet maître (102) depuis un objet demandeur (1 01 ) d'une demande (1 10, 123, 130) de réalisation d'une action visant :
- la communauté (106) des objets connectés (103, 1 04, 105) ou
- un objet interne de la communauté (1 06), l'objet interne étant distinct de l'objet maître (102) ;
- réception (1 19, 124, 137) d'une liste d'attributs certifiés et associés à l'objet demandeur (1 01 ) 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 , 21 1 , 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 (1 10, 123, 130) de réalisation d'une action vise le fait de rejoindre la communauté (1 06), 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).
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 communauté (106).
5. Procédé selon la revendication 2, dans lequel la demande (1 10, 123, 130) de réalisation d'une action vise le fait de communiquer avec un objet interne (1 03) de la communauté (106) et distinct de l'objet maître (102), et dans lequel la transmission dudit message permettant ladite action comporte une transmission (214) par l'objet maître (1 02) 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 (1 10, 123, 130) est en provenance de l'objet demandeur (101 ).
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 maître (102).
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 (1 08) ayant certifié au moins un attribut de la liste d'attributs.
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 (1 08) apte à certifier au moins un attribut de la liste d'attributs.
1 1 . Procédé selon l'une des revendications précédentes, dans lequel le procédé comporte en outre :
- envoi par l'objet demandeur (1 01 ) à un serveur de certification (108) d'une demande (1 10, 123, 130) de certification d'au moins un attribut.
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 ; - 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 maître de ladite communauté, ledit objet maître pouvant vérifier une validité dudit 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 ;
- 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é (1 06) d'objets connectés, dans lequel la méthode comprend : - 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 maître de ladite communauté, ledit objet maître pouvant vérifier une validité dudit jeton d'authentification, - recevoir un message réponse (225) dudit objet maître ; - 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.
14. Dispositif (101 ) apte à être connecté, dans lequel le dispositif comprend :
- une interface pour recevoir, d'un objet maître 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; - 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 communauté, l'objet interne étant distinct de l'objet maître;
- 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 mises en oeuvre par un objet demandeur:
- recevoir, d'un objet maître 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 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 maître; - recevoir un troisième message (206, 214, 226) permettant ladite action ou indiquant un résultat de ladite action.
PCT/FR2017/053063 2016-11-10 2017-11-09 Procédé de gestion d'autorisation dans une communauté d'objets connectes WO2018087483A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/345,795 US11277396B2 (en) 2016-11-10 2017-11-09 Method for authorization management in a community of connected objects
EP17808543.7A EP3539272A1 (fr) 2016-11-10 2017-11-09 Procédé de gestion d'autorisation dans une communauté d'objets connectes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1660889 2016-11-10
FR1660889A FR3058540A1 (fr) 2016-11-10 2016-11-10 Procede de gestion d'autorisation dans une communaute d'objets connectes

Publications (1)

Publication Number Publication Date
WO2018087483A1 true WO2018087483A1 (fr) 2018-05-17

Family

ID=58314370

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/053063 WO2018087483A1 (fr) 2016-11-10 2017-11-09 Procédé de gestion d'autorisation dans une communauté d'objets connectes

Country Status (4)

Country Link
US (1) US11277396B2 (fr)
EP (1) EP3539272A1 (fr)
FR (1) FR3058540A1 (fr)
WO (1) WO2018087483A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE1850155A1 (en) * 2018-02-13 2019-08-14 Fingerprint Cards Ab Registration of data at a sensor reader and request of data at the sensor reader
JP7289111B2 (ja) * 2019-06-26 2023-06-09 パナソニックＩｐマネジメント株式会社 通信装置、認証方法およびコンピュータプログラム
US11580239B2 (en) * 2019-10-22 2023-02-14 Microsoft Technology Licensing, Llc Controlling access to cloud resources in data using cloud-enabled data tagging and a dynamic access control policy engine
US11627138B2 (en) * 2019-10-31 2023-04-11 Microsoft Technology Licensing, Llc Client readiness system
US11310235B1 (en) * 2021-08-04 2022-04-19 Netfay Inc. Internet of things system based on security orientation and group sharing

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150143471A1 (en) * 2012-05-30 2015-05-21 Modacom Co.,Ltd. Method for establishing resource access authorization in m2m communication
EP2890073A1 (fr) * 2013-12-31 2015-07-01 Gemalto SA Système et procédé pour sécuriser des communications machine-machine
US20160044719A1 (en) * 2014-08-07 2016-02-11 Belkin International, Inc. Location and pairing of devices on a local area network using a unique identifier

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9832026B2 (en) * 2010-04-30 2017-11-28 T-Central, Inc. System and method from Internet of Things (IoT) security and management
US20150121470A1 (en) * 2013-10-25 2015-04-30 Qualcomm Incorporated Peer-to-peer onboarding of internet of things (iot) devices over various communication interfaces
US9801044B2 (en) * 2014-05-13 2017-10-24 Samsung Electronics Co., Ltd. Apparatus and method for accessing wireless network
US9699659B2 (en) * 2014-07-31 2017-07-04 Qualcomm Incorporated On-boarding a device to a secure local network
US10001759B2 (en) * 2014-08-11 2018-06-19 Qualcomm Incorporated Method and apparatus for automatically generating an events dictionary in an internet of things (IOT) network
US10756964B2 (en) * 2015-05-29 2020-08-25 Espressif Systems (Shanghai) Co., Ltd. Internet of things configuration method and system for secure low-power-consumption proxy device
US10044674B2 (en) * 2016-01-04 2018-08-07 Afero, Inc. System and method for automatic wireless network authentication in an internet of things (IOT) system
US10694557B2 (en) * 2016-08-11 2020-06-23 Reliance Jio Infocomm Limited Methods and systems for secure onboarding of devices over a wireless network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150143471A1 (en) * 2012-05-30 2015-05-21 Modacom Co.,Ltd. Method for establishing resource access authorization in m2m communication
EP2890073A1 (fr) * 2013-12-31 2015-07-01 Gemalto SA Système et procédé pour sécuriser des communications machine-machine
US20160044719A1 (en) * 2014-08-07 2016-02-11 Belkin International, Inc. Location and pairing of devices on a local area network using a unique identifier

Also Published As

Publication number Publication date
US20190268328A1 (en) 2019-08-29
US11277396B2 (en) 2022-03-15
FR3058540A1 (fr) 2018-05-11
EP3539272A1 (fr) 2019-09-18

Similar Documents

Publication Publication Date Title
WO2018087483A1 (fr) Procédé de gestion d'autorisation dans une communauté d'objets connectes
Fan et al. Diam-iot: A decentralized identity and access management framework for internet of things
EP2491735B1 (fr) Dispositif et procédé de gestion des droits d'accès à un réseau sans fil
US20130061055A1 (en) Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones
CA2971647A1 (fr) Methode de traitement d'une autorisation de mise en oeuvre d'un service, dispositifs et programme d'ordinateur correspondant
EP0800300A1 (fr) Vérification d'intégrité des réquêtes dans un réseau client serveur
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
FR2864289A1 (fr) Controle d'acces biometrique utilisant un terminal de telephonie mobile
EP1646176A2 (fr) Attribution d'une autorisation d'accès à une ressource
CN116980163A (zh) 基于可信执行环境的数据处理方法、装置、设备及介质
EP3568965A1 (fr) Procédé d'authentification en deux étapes, dispositif et programme d'ordinateur correspondant
EP1393272A1 (fr) Proc d et dispositif de certification d'une transaction
EP3857413A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3479325B1 (fr) Procédé d'authentification de données de paiement, dispositifs et programmes correspondants.
EP3829101B1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
FR2898423A1 (fr) Procede securise de configuration d'un dispositif de generation de signature electronique.
FR3073998B1 (fr) Procede numerique de controle d'acces a un objet, une ressource ou service par un utilisateur
WO2024096914A1 (fr) Partage de documents et de données basé sur une chaîne de blocs
CN115967495A (zh) 基于区块链的公益应用管理方法和装置
OA20002A (fr) Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé.
FR2880488A1 (fr) Procede d'authentification d'un terminal
Laginski Peer to peer role based authentication within JXTA
WO2017060624A1 (fr) Moyens de gestion d'accès à des données
WO2013045793A1 (fr) Procede de distribution de contenus, dispositif d'obtention et programme d'ordinateur correspondant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17808543

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017808543

Country of ref document: EP

Effective date: 20190611