EP2832034A1 - Methode et systeme d'etablissement d'une cle de session - Google Patents

Methode et systeme d'etablissement d'une cle de session

Info

Publication number
EP2832034A1
EP2832034A1 EP13709249.0A EP13709249A EP2832034A1 EP 2832034 A1 EP2832034 A1 EP 2832034A1 EP 13709249 A EP13709249 A EP 13709249A EP 2832034 A1 EP2832034 A1 EP 2832034A1
Authority
EP
European Patent Office
Prior art keywords
entity
secret
source
entities
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP13709249.0A
Other languages
German (de)
English (en)
Inventor
Yosra BEN SAIED
Christophe Janneteau
Alexis Olivereau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Publication of EP2832034A1 publication Critical patent/EP2832034A1/fr
Withdrawn legal-status Critical Current

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations

Definitions

  • the invention relates to the field of network communications and in particular encrypted communications between the entities of a global communication network.
  • the entities of the network in communication are designated by means of an identifier which is obtained from a cryptographic parameter, such as for example the public key of an asymmetric cryptographic algorithm.
  • an authenticated Authenticated Key Exchange (AKE) exchange protocol is implemented between a source entity and a target entity. This protocol aims to derive a session key, but also establish mutual authentication of the two entities.
  • AKE Authenticated Key Exchange
  • the various state-of-the-art AKE protocols base the authentication of an entity on the proof of its knowledge of the totality of the cryptographic material, i.e. knowledge of a public key and a private key whose identifier is issued.
  • HIP-BEX Host Identity Protocol Base Exchange Protocol
  • the HIP-BEX protocol makes use of the Diffie-Hellman generation and key exchange mechanisms, which makes it expensive in resources.
  • IKE-CGA Internet Key Exchange Cryptographically Generated Addresses
  • the solution provides secure data transmission between low sensor and a more powerful server, by means of a two-segment communication, where the data is first transmitted from the sensor to a collection node, and then from the collection node. to the remote server.
  • the first segment is secured using symmetric algorithms while the second segment relies on asymmetric cryptography.
  • the collection node decrypts the data received from the sensor and re-encrypts them to the server, which does not allow the establishment of secure end-to-end communication between the sensor and the remote server. Indeed, no confidentiality is assured vis-à-vis the collection node.
  • IDO Internet of Things
  • nodes entities with low energy and computing power that must use cryptographically generated identifiers to communicate with remote entities. can have powerful resources.
  • HIP Diet Exchange or (HIP-DEX) in English described in R. Moskowitz's paper, "HIP Diet EXchange (DEX)", IETF work in progress draft- moskowitz-hip-rg-dex-05, March 2011, aims to be used by low resource nodes. It is a lighter version of the key exchange mechanism of the aforementioned HIP protocol.
  • the main changes introduced by HIP-DEX are the use of elliptic curve cryptography, the use of static Diffie-Hellman values, and primitives lighter for hash functions. Despite the performance advantages obtained over the basic protocol, the HIP-DEX protocol remains resource-intensive due to its use of the Diffie-Hellman protocol.
  • An object of the present invention is to provide a method of key exchange in the context of communications whose identifiers are generated cryptographically.
  • Another object of the invention is to allow the use of cryptographically generated identifiers by highly constrained nodes resources.
  • an authenticated key exchange method based on these identifiers is proposed.
  • Another object of the present invention is to allow the generation of a shared secret between two cryptographically generated identifier nodes by means of asymmetric cryptographic operations without using the Diffie-Hellman protocol.
  • the mechanism on which the present invention relies can be implemented in a distributed manner, using the assistance of neighboring nodes to which are delegated the most consuming operations of asymmetric cryptography.
  • the present invention extends to nodes highly constrained in resources, the use of cryptographically generated identifiers to generate a shared secret, whereas this use was hitherto forbidden to them because of the complexity of the key exchange protocols. involving cryptographically generated identifiers.
  • the present invention makes it possible to define, thanks to cryptographically generated identifiers, the same identification scheme, regardless of the resource level of the considered entities.
  • Another object of the present invention is to provide a method that relieves, at the assisting nodes, a highly resource-constrained node, the most resource-intensive cryptographic operations, while ensuring that the assisting nodes can not know the exchanged secret. .
  • a further object of the present invention is thus to create secure contexts between nodes of a network identified cryptographically.
  • Another object of the present invention is to increase the lifetime of battery-operated nodes such as sensors.
  • the present invention will be implemented in the context of the Internet of Things, where entities with highly heterogeneous resources coexist, such as servers, mobile connected objects, and weak sensors.
  • the invention will find applications in industrial fields where protocol stack elements are used for low-resource objects participating in an integrated Internet of Things model.
  • a method as described in independent claim 1 a system as described in independent claim 12 and a computer program product as described in claim 14 are provided.
  • a method for establishing a session key between a source entity and a target entity is claimed.
  • the method includes the steps of:
  • a secret x for the source entity, the secret comprising n secret values ( ⁇ , ⁇ , ⁇ );
  • Figure 1 is a topological representation of a network infrastructure in which to advantageously implement the invention
  • FIG 2 shows the procedures executed between the source, target and assistant entities of the network of Figure 1 in an advantageous implementation of the invention
  • Figure 3 shows the steps performed by the method of the invention to establish a session
  • Figure 4 shows the procedures executed between the source, target and assistant entities of the network of Figure 1 in an alternative implementation of the invention. Detailed description of the invention
  • FIG. 1 illustrates a global network environment (100) in which the invention is advantageously implemented.
  • the example of FIG. 1 only shows a finite number of entities and connections, but the person skilled in the art will extend the principles described to a plurality and a variety of entities and types of connections (wireless, mobile, very high speed).
  • the global network (100) comprises a set of fixed or moving entities forming an object network (102).
  • the object network includes entities with strong resource constraints (102-1, 102-n) and entities with less resource constraint (112-1, 112-m).
  • the entities with strong resource constraints may be wireless sensors or actuators, having limited computing and / or storage capacities. They can also be active tags. However, an entity that is not intrinsically resource-limited may be temporarily so long as it uses a large portion of its CPU resources for another task, or its battery level reaches a critical threshold value. And this entity can be brought to implement less energy-efficient protocols such as that of the invention.
  • Entities with lesser resource constraint can be cell phones with internet connection and camera. It can also be interconnection gateways between a network of constrained entities and the Internet. These entities offer more computing power and storage capacity, can have a higher energy reserve (battery, mains power supply) and can communicate over a network, either directly to an internet network (104) such as illustrated or through gateways and intermediate servers (not shown).
  • an internet network (104) such as illustrated or through gateways and intermediate servers (not shown).
  • the object network (102) may be based on level 2 (e.g., 802.15.4 or 802.11) or level 3 (e.g., IP) communications between the entities of which it is composed. Depending on the protocols on which it is based, multicast or broadcast communication schemes can be used.
  • the global network (100) includes remote entities (106) that do not have resource constraints, compared to entities in the object network (102).
  • the remote entities may be servers (for example, storage server and / or information management relayed by one or more sensors or actuator control server) having significant storage and computing power capacities or any other entity with unconstrained computing, storage and energy capabilities.
  • servers for example, storage server and / or information management relayed by one or more sensors or actuator control server
  • IoT Internet of Things
  • These communications can be established in a limited context (a single protocol used, for example ZigBee and / or a single scenario targeted, for example the Intelligent Electric Network or Smart Grid) and one speaks then about "Intranet of the objects" or may have The aim is to make a large number of different services possible, while relying on numerous communication protocols, and we are talking about the "Internet of Things".
  • the Internet of Things is an architecture that allows the interconnection of the classic Internet with communicating or perceived objects, and which relies on decentralized communication schemes, while implementing autonomous mechanisms.
  • the present invention can be advantageously applied in the environment of FIG. 1 between a highly resource-constrained entity (102-1) that is called an "initiator” and a powerful remote server (106) that is called an “answering machine”. . Both entities need to establish a session key and do not already share a long-term secret between themselves.
  • the method which is described with reference to FIG. 2 takes into account the constraints in terms of resources and uses distributed collaborative techniques to make possible the exchange of session keys between two heterogeneous entities during the same communication.
  • Figure 2 shows the procedures performed between an initiator (202) and an answering machine (206) to establish a session key.
  • the initiator (202) selects assistant entities with less resource constraints than the initiator, and hereinafter referred to as proxies (204-1, 204-n).
  • the selection can be based on the reputations of the entities in the vicinity of the initiator and / or on their available resources such as for example their computing power or their battery level. In the case where the selection is based on the reputations of the nodes in the neighborhood, these can be evaluated locally or by a central server according to their past attitudes. A metric, reputation, is then defined that accounts for the types and proportions of positive (for example, offering a service) and negative (for example, refusing to offer a service) attitudes that a node has manifested in the past .
  • the determination of the number of proxies to which an initiator will use is not described in the present invention, and may be for example a function of the probability that these proxies lead against the node a collusion attack.
  • the Selection process includes a step of discovery in its vicinity of entities with which it can have a shared secret. This discovery can be done dynamically, and can be facilitated by the use of a third entity knowing the entirety of the topology of the network in which the initiator evolves.
  • the initiator may contain a predefined list of usable proxies, and the selection of proxies to be used for the session is made on that list.
  • the initiator (202) sends a message (222) to inform the responder (206) of its identity ID (I), indicate the cryptographic algorithms it supports, and the key establishment method it wishes to use. If the responder (206) accepts the proposed key establishment technique, it responds to the initiator with a message (224) which may contain its identity ID (R) as well as the choice of the selected cryptographic algorithm from those proposed by the initiator.
  • the negotiated key establishment method can for example be based on RSA, ECC the cryptographic algorithms can include the encryption algorithms: RC4, RC2, DES, AES, 3DES and / or the hash functions MD5 and SHA- 1.
  • the initiator and the responder set the connection parameters for their session.
  • a next phase (230) the initiator informs the proxies of the identity of the responder, and a message (232) containing the identity of the responder ID (R) is sent to each proxy selected in phase 210.
  • each message (232) may also contain information PR (Kpi) that will allow each proxy to prove its representativity to the responder.
  • the proxies receive directly from the initiator the proof that they are authorized to act on its behalf.
  • This proof may be, for example, a certificate associating the public key of the proxy with the right "authorized to sign on behalf of the initiator", all signed by the private key of the initiator.
  • This certificate may include other parameters added by the initiator to restrict the ability of proxies to sign on their behalf, such as the responder's identity or an expiration date.
  • this certificate may have been sent by the initiator to the proxy outside the active session .
  • the certificate is sent to the proxy during the session active.
  • the authorization of the proxies to act on behalf of the initiator is managed by a third-party trusted entity.
  • the initiator provides the trusted entity T with a certificate associating rights allowing to give entities of the network, rights to sign on behalf of the initiator, the identity of T, the whole being signed by a private key corresponding to the cryptographically generated identifier.
  • the trusted entity T can be a single physical entity, or it can be a logical entity that is physically instantiated in the form of different physical entities, implementing a redundancy system so as to ensure continuity of service in the event of a crash. .
  • the initiator transmits the list of proxies to the trusted entity which on receipt transmits to each proxy all the cryptographic information necessary to authenticate the message that each proxy sends to the responder.
  • the cryptographic information comprises a public key / private key pair of a signature system.
  • such a single-use signature system may be the "OUT" system described in the paper by L. Reyzin et al. "Better than BiBa: Short One-Time Signatures with Fast Signing and Verifying", LNCS 2384, pp. 144-153, 2002.
  • the trusted entity also provides each proxy with a means that allows the proxy to sign protocol exchange messages on behalf of the initiator, that is, to prove its entitlement to act on behalf of the initiator. initiator.
  • This means can take the form of a message cryptographically associating the right assigned to the proxy to sign on behalf of the initiator, the certificate sent previously by the initiator to the trusted entity, the public part of the cryptographic material provided by the initiator. trusted entity to the proxy, all signed by the private key of the trusted entity.
  • each proxy After sending the message 232 containing the identity of the answering machine and possibly the proof of representativeness, each proxy establishes a connection with the answering machine and optionally sends a message (234) containing the proof of representativeness that it has received from the initiator. or a trusted entity.
  • the answering machine and the proxies established the connection parameters for their session.
  • the next step will be to prepare and exchange initial session key templates between initiator and responder (also called "premaster secrets x and y" in English) to later calculate the shared session key.
  • the initiator gives the answering machine a secret x generated randomly and the answering machine gives the initiator a secret y.
  • the session key will then be calculated from these two secret values.
  • the initiator (202) breaks down (242) its secret x into n secret fragments, where n is the number of proxies selected to support the session. Each secret value is assigned to a proxy.
  • an error correction procedure can be applied to the original secret x before decomposing it, so as to add redundancy to it.
  • This allows the responder to be able to reconstruct the secret sent by the initiator provided that a sufficient number of packets are received from the assisting nodes, but without requiring the reception of all the messages from the host. all the assistant nodes.
  • This system protects our solution against compromising or refusing to collaborate from the helper nodes.
  • it makes it possible not to impose a reliable delivery for each connection between a proxy and the answering machine.
  • the initiator transmits (244) to each proxy the fragment of secret assigned to it.
  • each message is sent in a secure way, using a security association based on a symmetric key (k i_ P i) between the initiator and each proxy.
  • the proxy Upon receipt of its secret fragment, the proxy encrypts the fragment and signs the result using its private key.
  • the proxy advantageously encrypts its fragment using the public key of the server that corresponds to its cryptographically generated identifier, as communicated by the initiator in a previous phase. Then, each proxy transmits (246) to the responder a signed message containing the secret fragment that has been assigned to it, and encrypted.
  • the responder After receiving a sufficient number of fragments, the responder can find the original secret x and reconstruct the secret x of the initiator.
  • the answering machine randomly generates (248) in turn a secret y and transmits it (249) in a message to the proxies.
  • the message is also constructed from the secret x reconstructed by the responder.
  • the proxies support the computing load necessary to verify the message received from the responder and then transmit it (250) to the initiator.
  • each proxy transmits to the initiator a protected message by means of symmetrical keys ki_pi shared between the initiator and each proxy.
  • ki_pi shared between the initiator and each proxy.
  • the latter is encrypted with the secret x previously transmitted to the responder by the initiator.
  • the secret y encrypted by x is provided with a "Message Authent ic ion Code or (MAC) in English" calculated with x as a key.
  • This MAC message assures the initiator that the received encrypted message has been sent by an entity having knowledge of the value x.
  • the receiver sends to all the proxies a message containing y encrypted by x, provided with a MAC calculated from x, the whole being signed by means of the private key of the receiver.
  • the proxies On receipt of this message, the proxies verify the validity of the signature of the receiver and, in the event of a valid message, forward to the initiator the message received without its signature, that is to say: y encrypted by x, equipped with a MAC calculated from x, this message being encrypted by means of the symmetric key ⁇ _ ⁇ 1 .
  • the receiver sends to one or more proxies the message containing y encrypted by x, provided with a MAC calculated from x, the whole being signed by means of the private key of the receiver.
  • the proxies to which the receiver has sent the message verify the validity of the signature of the receiver and, in the event of a valid message, send to the initiator the message received without his signature, that is to say: y encrypted by x, provided with a MAC calculated from x, this message being encrypted by means of the symmetric key k i_ P i.
  • the method calculates the session key.
  • Both Initiator (202) and Responder (206) entities calculate the key final according to the two secrets x and y exchanged and additional parameters.
  • the responder returns a message to the initiator containing the proxies who actually and reliably cooperated during the exchange of secrets, to enable him to refine his future selection of participants and revoke the malicious knots.
  • the messages (232) of the proxies initiator containing the responder's identity and the proof of representativeness are grouped together with the respective messages (244) n to the proxies containing the values of the secret fragments (x1). , xn).
  • Figure 3 unfolds the steps (300) operated by the method of the invention to establish a session in a preferred implementation.
  • a request to establish a secure connection between a source entity and a target entity is issued.
  • the request may be initiated by the resource-constrained entity or at the initiative of a remote server to a resource-constrained entity.
  • the transmission of the request triggers the previously described phase (220) so that the initiator and the responder establish the connection parameters for their session.
  • step (304) the initial pattern of secret x is decomposed into a plurality n of values (x1, ..., xn).
  • step (306) the n secret values (x1, ..., xn) are assigned to n proxies (PI, ..., Pn) selected. Each proxy receives the secret value assigned to it encrypted with a symmetric key.
  • the proxies are informed of the identity of the responder either in step (306) or as described above in an initial step (230) where they receive proof of their representativity to the answering machine.
  • the n secret values are encrypted and signed by the proxies.
  • Step (312) consists in reconstructing the secret x from the secret values received from the proxies. The method waits to receive enough values to recover the initial secret value x and proceed to the next step.
  • step (314) a secret is generated randomly by the responder and is encrypted and signed to transmit it to the proxies with the secret x.
  • step (316) if the signature received by the proxies is verified and validated, the secret is there transmitted to the initiator (step 318), otherwise the process stops.
  • Step (320) consists of calculating the final session key according to the two secrets (x, y) exchanged.
  • FIG. 4 shows the procedures executed between the source, target and assistant entities of the network of FIG. 1 in an implementation variant of the invention applied to the "HIP BEX" protocol.
  • the known puzzle mechanism specified in the HIP BEX protocol is maintained to protect the responder against resource depletion attacks while executing the protocol.
  • the initiator (402) sends a first message 422 to the responder (406) to obtain the HIP association and inform it of the cooperation technique supported. for key exchange.
  • the answering machine responds with a message 424 to begin the exchange of the protocol.
  • the message 424 of the responder contains the identifier of the responder, that is to say, its public key K R , and a puzzle composed of a cryptographic challenge that the initiator must solve before continuing the exchange protocol.
  • the level of difficulty of the puzzle can be adjusted according to the level of confidence of the initiator and its current capacities in terms of resources.
  • the puzzle exchange in the HIP protocol is a way to defense to protect the answering machine against denial of service attacks. The latter remains passive until a valid response is received from the initiator.
  • the initiator calculates the solution of the puzzle received.
  • the initiator transmits (426) the solution to the proxies (404-1, 404-n) in messages I21i ... I21 n . These messages are also used to transmit the n fragments of the secret x to the n proxies.
  • Each connection between the initiator and a proxy is a secure connection with a symmetric key k]; _ pi.
  • the answering machine On receipt of a message 122 ⁇ , the answering machine checks the validity of the puzzle solution. In the absence of a correct solution, the corresponding message is rejected. If a correct solution is found, the answering machine continues the protocol exchange. It sends (430) a message R21i to each proxy containing its secret y encrypted with the secret key x, adding a value
  • MAC Authentication Message Code
  • the initiator decrypts the secret y in order to finalize the implementation of the main session key.
  • the final key "Master Key or (MK) in English" established between the initiator and the responder is calculated as follows:
  • MK H ((P I HIT-I
  • H () is a unidirectional cryptographic hash function
  • P is a parameter of the puzzle, included so
  • HIT-I is the Host Identity Tag of the initiator, that is, a truncated hash of its cryptographically generated identifier
  • HIT-R is the Host Identity Tag of the answering machine; and x and y are the respective secret values of the initiator and the responder.
  • the establishment of the connection between a constrained entity and an unconstrained server is at the initiative of the latter.
  • the first message sent (222, 422) is by the server, and then the method follows the steps previously described.
  • the identities of the nodes to act as proxies can be provided in a secure manner by a trust resolution infrastructure. They also make it possible to simply link nodes based on different technologies, such as active tags, IP nodes, non-IP nodes, since the cryptographic identifiers are used at a higher level than the IP layer.
  • the present invention may be implemented from hardware and / or software elements. It may be available as a computer program product on a computer readable medium.
  • the support can be electronic, magnetic, optical, electromagnetic or be an infrared type of diffusion medium.
  • Such media are, for example, Random Access Memory RAMs (ROMs), magnetic or optical tapes, floppy disks or disks (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read / Write (CD-R / W) and DVD).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un système et une méthode d'établissement de clé de session dans un contexte de communications entre entités dont les identifiants sont générés cryptographiquement et dont l'une des entités est fortement contrainte en ressource. L'invention consiste à assigner à des entités assistantes de l'entité contrainte en ressource, les opérations les plus consommatrices de cryptographie asymétrique.

Description

METHODE ET SYSTEME D'ETABLISSEMENT D'UNE CLE DE
SESSION
Domaine de l'invention
L'invention concerne le domaine des communica- tions réseau et en particulier les communications cryptées entre les entités d'un réseau global de corn- munication . Etat de la Technique
Dans un réseau de communications cryptées, les entités du réseau en communication sont désignées au moyen d'un identifiant qui est obtenu à partir d'un paramètre cryptographique, tel que par exemple la clé publique d'un algorithme cryptographique asymétrique.
Afin de procéder à l'établissement d'une session de communication, un protocole d'échange de clé authentifié « Authenticated Key Exchange (AKE) en anglais » est mis en œuvre entre une entité source et une entité cible. Ce protocole a pour but de dériver une clé de session, mais aussi d'établir 1 ' authentification mutuelle des deux entités. Dans le cas de communications à identifiants générés cryptographiquement , les différents protocoles AKE de l'état de l'art fondent 1 ' authentification d'une entité sur la preuve de sa connaissance de la totalité du matériel cryptographique, c'est-à-dire la connaissance d'une clé publique et d'une clé privée dont son identifiant est issu.
Plusieurs protocoles d'échange de clé authentifié sont connus tels que ceux listés par exemple ci-après.
Le protocole « Host Identity Protocol Base Exchange ou (HIP-BEX) en anglais » décrit dans le papier de [R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, "Host Identity Protocol", IETF RFC 5201, April 2008] propose un système d'échange de clés basé sur le protocole bien connu Diffie-Hellman . Le protocole HIP-BEX fait usage des mécanismes Diffie- Hellman de génération et d'échange de clés, ce qui le rend coûteux en ressources.
Le protocole « Internet Key Exchange Cryptographically Generated Addresses ou (IKE-CGA) en anglais » décrit dans le papier de [J. Laganier, G. Monténégro, A. Kukec, "Using IKE with IPv6 Cryptographically Generated Addresses", IETF draft- laganier-ike-ipv6-cga-02 , July 2007] est un protocole qui permet d'étendre les mécanismes d ' authentification supportés par IKE à 1 ' authentification au moyen d'adresses cryptographiquement générées. Cette solution met en œuvre des identifiants générés cryptographiquement dans le cadre de la sécurisation d'un échange Diffie-Hellman standard, et reste un choix coûteux en ressources. Le brevet EP 2 290 895 Al décrit une solution d'établissement d'association de sécurité entre deux nœuds d'un réseau possédant des identifiants cryptographiquement générés au moyen d'un échange en deux messages. Cette solution permet un établissement de clé de session plus rapide que dans les mécanismes précédents qui peuvent requérir de trois à six messages. Néanmoins, le gain en performance est limité car à cet échange succède une génération de clé au moyen des valeurs publiques Diffie-Hellman de l'initiateur et du répondeur, échangées respectivement dans le premier et le second messages de cette solution .
Une autre approche est définie par Mâche et al. dans le papier de J. Mâche, C.-Y. Wan, and M. Yarvis, "Exploiting heterogeneity for sensor network security, " in Proceedings of IEEE Communications Society Conférence on Sensor, Mesh and Ad Hoc Communications and Networks, June 2008, pp. 591-593. La solution prévoit la transmission sécurisée de données entre en capteur faible et un serveur plus puissant, au moyen d'une communication à deux segments, où les données sont d'abord transmises du capteur à un nœud de collecte, et ensuite du nœud de collecte au serveur distant. Le premier segment est sécurisé au moyen d'algorithmes symétriques alors que le second segment s'appuie sur de la cryptographie asymétrique. Le nœud de collecte décrypte les données reçues du capteur et les ré-encrypte à destination du serveur, ce qui ne permet pas l'établissement d'une communication sécurisée de bout en bout entre le capteur et le serveur distant. En effet, aucune confidentialité n'est assurée vis-à-vis du nœud de collecte .
Les protocoles et solutions cités bien que répondant à des besoins d'échange de clé authentifié prévoient l'utilisation de primitives cryptographiques complexes afin de prouver l'identité des entités de la session, et nécessitent donc que les entités aient les ressources appropriées. Ces approches ne sont pas conçues pour être économes en énergie.
Ainsi, ces protocoles ne sont pas adaptés pour les réseaux où doivent communiquer des entités fortement contraintes en ressources avec des entités plus puissantes. Un tel type de réseau, comme celui connu sous la dénomination de l'Internet des Objets (IDO), comprend des entités (souvent appelées nœuds) à faible énergie et puissance de calcul qui doivent employer des identifiants cryptographiquement générés pour communiquer avec des entités distantes pouvant avoir des ressources puissantes.
Le protocole « HIP Diet Exchange ou (HIP-DEX) en anglais» décrit dans le papier de R. Moskowitz, "HIP Diet EXchange (DEX)", IETF work in progress draft- moskowitz-hip-rg-dex-05, March 2011, vise à être utilisé par des nœuds à faibles ressources. C'est une version allégée du mécanisme d'échange de clés du protocole précité HIP. Les principales modifications introduites par HIP-DEX sont l'emploi de la cryptographie à courbes elliptiques, l'emploi de valeurs Diffie-Hellman statiques, et de primitives plus légères pour les fonctions de hachage . Malgré les avantages en performances obtenus sur le protocole de base, le protocole HIP-DEX reste exigeant en ressources du fait de son emploi du protocole Diffie- Hellman. Par ailleurs, il utilise un mécanisme de génération de secret partagé qui postule que tous les échanges de secrets partagés menés par un nœud sont conduits à partir de la même valeur publique, générée par le nœud une seule fois et lui servant également à construire son identifiant cryptographiquement généré. Ainsi, même si la phase coûteuse en ressources de génération de la valeur publique disparaît, cette économie énergétique se fait au détriment de la propriété de confidentialité persistante « perfect forward secrecy » en anglais, qui permet d'assurer qu'un secret échangé ne pourra être retrouvé par un attaquant, quand bien même les secrets à long terme des participants seraient divulgués. II existe alors le besoin d'une solution qui permette une communication cryptée entre entités ayant des contraintes en ressources différentes et assurant le respect de la confidentialité du secret échangé. La présente invention répond à ce besoin.
Résumé de l'invention Un objet de la présente invention est d'offrir une méthode d'échange de clés dans le contexte de communications dont les identifiants sont générés cryptographiquement .
Un autre objet de l'invention est de permettre l'emploi d'identifiants cryptographiquement générés par des nœuds fortement contraint en ressources. Avantageusement, une méthode d'échange de clé authentifié s 'appuyant sur ces identifiants est proposée .
Un autre objet de la présente invention est de permettre la génération d'un secret partagé entre deux nœuds à identifiants cryptographiquement générés au moyen d'opérations de cryptographie asymétrique sans faire usage du protocole Diffie-Hellman .
Avantageusement, le mécanisme sur lequel la présente invention s'appuie peut être mis en œuvre de manière distribuée, en utilisant l'assistance de nœuds voisins auxquels sont déléguées les opérations les plus consommatrices de cryptographie asymétrique.
Avantageusement, la présente invention étend à des nœuds fortement contraints en ressources, l'usage d'identifiants cryptographiquement générés pour générer un secret partagé, alors que cet usage leur était jusqu'ici interdit du fait de la complexité des protocoles d'échange de clé faisant intervenir les identifiants générés cryptographiquement.
Avantageusement, la présente invention permet de définir, grâce à des identifiants cryptographiquement générés, un même schéma d'identification, indépendamment du niveau de ressources des entités considérées .
Un autre objet de la présente invention est de fournir une méthode qui décharge, auprès de nœuds assistants, un nœud fortement contraint en ressources, des opérations cryptographiques les plus exigeantes en ressources, tout en assurant que les nœuds assistants ne puissent prendre connaissance du secret échangé.
Un objet supplémentaire de la présente invention est ainsi de créer des contextes sécurisés entre des nœuds d'un réseau identifiés cryptographiquement.
Un autre objet de la présente invention est d'augmenter la durée de vie de nœuds fonctionnant sur batterie tels que des capteurs.
Avantageusement, la présente invention s ' implémentera dans le contexte de l'Internet des objets où coexistent des entités aux ressources fortement hétérogènes, tels que des serveurs, des objets connectés mobiles, des capteurs peu puissants.
Toujours avantageusement mais sans limitation, l'invention trouvera des applications dans des domaines industriels où sont utilisés des éléments de pile de protocoles pour des objets à faible ressources participant à un modèle intégré d'Internet des objets. Pour obtenir les résultats recherchés, une méthode telle que décrite dans la revendication indépendante 1, un système tel que décrit dans la revendication indépendante 12 et un produit programme d'ordinateur tel que décrit dans la revendication 14 sont proposés.
En particulier, dans un réseau de communication comprenant une pluralité d'entités communicantes, une méthode pour établir une clé de session entre une entité source et une entité cible est revendiquée. La méthode comprend les étapes de:
- générer un secret x pour l'entité source, le se- cret comprenant n valeurs de secret (χΐ,χί,χη) ;
- assigner chaque valeur de secret (xi) à une enti¬ té assistante (Pi) parmi la pluralité d'entités com¬ municantes ;
chiffrer et signer par chaque entité assistante la valeur de secret assignée (xi) ;
authentifier l'entité source à réception par l'entité cible d'une ou plus valeurs de secret (χΐ,χί,χη) chiffrées et signées ;
- générer un secret y chiffré et signé pour l'entité cible ;
authentifier l'entité cible à réception par au moins une des n entités assistantes (ΡΙ,Ρί,Ρη) de la valeur de secret y chiffré et signé ; et
- générer une clé de session entre l'entité source et l'entité cible à réception par l'entité source de la valeur de secret authentifiée. Différentes variantes d ' implémentations sont dé¬ crites dans les revendications dépendantes.
Description des figures
Différents aspects et avantages de l'invention vont apparaître en appui de la description d'un mode préféré d ' implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous :
La Figure 1 est une représentation topologique d'une infrastructure réseau dans laquelle implémenter avantageusement l'invention ;
La Figure 2 montre les procédures exécutées entre les entités source, cible et assistante du réseau de la figure 1 dans une implémentation avantageuse de 1 ' invention;
La Figure 3 montre les étapes opérées par la méthode de l'invention pour établir une session ;
La Figure 4 montre les procédures exécutées entre les entités source, cible et assistante du réseau de la figure 1 dans une variante d ' implémentation de 1 ' invention . Description détaillée de l'invention
La figure 1 illustre un environnement de réseau global (100) dans lequel l'invention est implémentée avantageusement. Pour des raisons de simplicité de description et non de limitation de l'invention, l'exemple de la figure 1 ne montre qu'un nombre fini d'entités et de connexions, mais l'homme du métier étendra les principes décrits à une pluralité et une variété d'entités et de type de connexions (sans fil, mobile, très haut débit) .
Le réseau global (100) comprend un ensemble d'entités fixes ou mobiles formant un réseau d'objets (102) . Le réseau d'objets comprend des entités à fortes contraintes de ressources (102-1, 102-n) et des entités à moindre contrainte de ressources (112-1, 112-m) .
Les entités à fortes contraintes de ressource peuvent être des capteurs ou actionneurs sans fil, ayant des capacités de calculs et/ou de stockage limitées. Il peut également s'agir de tags actifs. Cependant, une entité qui n'est pas intrinsèquement limitée en ressources peut l'être de façon temporaire dès lors qu'elle emploie une grande part de ses ressources processeur à une autre tâche, ou que son niveau de batterie atteint une valeur seuil critique. Et cette entité peut être amenée à mettre en œuvre des protocoles moins coûteux en énergie comme celui de l'invention.
Les entités à contrainte de ressource moindre peuvent être des téléphones portables munis d'une connexion internet et d'un appareil photo. Il peut également s'agir de passerelles d'interconnexion entre un réseau d'entités contraintes et l'Internet. Ces entités offrent une puissance de calcul et une capacité de stockage plus importantes, peuvent disposer d'une réserve d'énergie (batterie, alimentation sur secteur) plus importante et peuvent communiquer sur un réseau, soit directement à un réseau internet (104) comme illustré ou bien au travers de passerelles et serveurs intermédiaires (non montré) .
Le réseau d'objets (102) peut être basé sur des communications de niveau 2 (par exemple, 802.15.4 ou 802.11) ou de niveau 3 (par exemple, IP) entre les entités qui le composent. Suivant les protocoles sur lesquels il s'appuie, des schémas de communications multicast ou broadcast peuvent y être employés. Le réseau global (100) comprend des entités distantes (106) ne présentant pas de contraintes en ressources, comparativement à celles des entités du réseau d'objets (102).
Les entités distantes peuvent être des serveurs (par exemple, serveur de stockage et/ou management d'informations remontées par un ou plusieurs capteurs ou serveur de contrôle d ' actionneurs ) ayant des capacités de stockage et de puissance de calcul importantes ou toute autre entité présentant des capacités de calcul, de stockage et d'énergie non contraintes . Un tel réseau global forme ce que l'on trouve dénommé comme un internet des objets (IdO) . Il couvre deux types de communication :
· celles d'objet à personne;
• celles d'objet à objet, ou machine à machine (M2M) .
Ces communications peuvent être établies dans un contexte limité (un seul protocole employé, par exemple ZigBee et/ou un seul scénario ciblé, par exemple le Réseau Electrique Intelligent ou Smart Grid) et on parle alors d' «intranet des objets » ou peuvent avoir vocation à rendre possible un grand nombre de services distincts, tout en s ' appuyant sur de nombreux protocoles de communications, et on parle alors d' «internet des objets». Généralement, on entend par Internet des Objets une architecture qui permet l'interconnexion de l'Internet classique avec des objets communicants ou perçus, et qui s'appuie sur des schémas de communication décentralisés, tout en mettant en œuvre des mécanismes autonomes.
La présente invention peut être avantageusement appliquée dans l'environnement de la figure 1 entre une entité fortement contrainte en ressources (102-1) que l'on dénomme 'initiateur' et un serveur distant puissant (106) que l'on dénomme 'répondeur'. Les deux entités ont besoin d'établir une clé de session et ne partagent pas déjà entre elles un secret à long terme. La méthode qui est décrite en référence à la figure 2 prend en compte les contraintes en termes de ressources et utilise des techniques collaboratives distribuées afin de rendre possible l'échange de clé de session entre deux entités hétérogènes lors d'une même communication.
La figure 2 montre les procédures exécutées entre un initiateur (202) et un répondeur (206) pour établir une clé de session.
Dans une première phase d'initialisation (210), l'initiateur (202) sélectionne des entités assistantes moins contraintes en ressources que l'initiateur, et désignées ci-après proxies (204-1, 204-n) .
La sélection peut se baser sur les réputations des entités au voisinage de l'initiateur et/ou sur leurs ressources disponibles telles que par exemple leur puissance de calcul ou leur niveau de batterie. Dans le cas où la sélection se base sur les réputations des nœuds au voisinage, ces derniers peuvent être évalués localement ou par un serveur central selon leurs attitudes passées. Une métrique, la réputation, est alors définie qui rend compte des types et proportions d'attitudes positives (par exemple, offrir un service) et négatives (par exemple, refuser d'offrir un service) qu'un nœud a manifesté par le passé.
La détermination du nombre de proxies auxquels un initiateur va recourir n'est pas décrit dans la présente invention, et peut être par exemple fonction de la probabilité que ces proxies conduisent contre le nœud une attaque par collusion. Dans le cas où l'initiateur est par exemple un équipement mobile, le processus de sélection comprend une étape de découverte à son voisinage d'entités avec lesquelles il peut disposer d'un secret partagé. Cette découverte peut s'effectuer dynamiquement, et peut être facilitée par le recours à une entité tierce connaissant l'intégralité de la topologie du réseau dans laquelle l'initiateur évolue.
Dans une variante, l'initiateur peut contenir une liste prédéfinie de proxies utilisables, et la sélection des proxies à utiliser pour la session est faite sur cette liste.
Dans une phase suivante (220), un échange d'informations relatives à la sécurité supportée par l'initiateur (202) et par le répondeur (206) est opéré .
L'initiateur (202) envoie un message (222) pour informer le répondeur (206) de son identité ID(I), indiquer les algorithmes cryptographiques qu'il supporte, et la méthode d'établissement de clé qu'il souhaite utiliser. Si le répondeur (206) accepte la technique d'établissement de clé proposée, il répond à l'initiateur par un message (224) qui peut contenir son identité ID(R) ainsi que le choix de l'algorithme cryptographique choisi parmi ceux proposés par l'initiateur. En effet, la méthode d'établissement de clé négociée peut par exemple être basée sur RSA, ECC les algorithmes cryptographiques peuvent inclure les algorithmes de chiffrement : RC4, RC2, DES, AES, 3DES et/ou les fonctions de hachage MD5 et SHA-1. A l'issue de la phase 220, l'initiateur et le répondeur ont établi les paramètres de connexion pour leur session.
Dans une phase suivante (230), l'initiateur informe les proxies de l'identité du répondeur, et un message (232) contenant l'identité du répondeur ID(R) est envoyé à chaque proxy sélectionné en phase 210.
Dans une variante d ' implémentation, chaque message (232) peut aussi contenir aussi une information PR(Kpi) qui va permettre à chaque proxy de prouver sa représentativité auprès du répondeur.
Dans une première variante de l'invention, les proxies, munis d'une paire clé publique / clé privée, reçoivent directement de l'initiateur la preuve qu'ils sont autorisés à agir en son nom. Cette preuve peut être, par exemple, un certificat associant la clé publique du proxy au droit « habilité à signer au nom de l'initiateur », le tout étant signé par la clé privée de l'initiateur. Ce certificat peut inclure d'autres paramètres ajoutés par l'initiateur dans le but de restreindre la capacité des proxies à signer en son nom, tels que l'identité du répondeur ou une date d'expiration. Dans le cas d'un certificat n'incluant que l'identité du proxy et son statut d'entité habilitée à signer au nom de l'initiateur, ce certificat peut avoir été envoyé par l'initiateur au proxy en dehors de la session active. Alternativement, dans le cas d'un certificat faisant figurer l'identité du répondeur ou comportant une date d'expiration, le certificat est envoyé au proxy pendant la session active .
Dans une seconde variante de l'invention, l'autorisation des proxies à agir au nom de l'initiateur est gérée par une entité de confiance tierce. L'initiateur fournit à l'entité de confiance T un certificat associant des droits permettant de donner à des entités du réseau, des droits de signer au nom de l'initiateur, l'identité de T, le tout étant signé par une clé privée correspondant à l'identifiant généré cryptographiquement . Avantageusement, l'entité de confiance T peut être une entité physique unique, ou peut être une entité logique physiquement instanciée sous la forme de différentes entités physiques, mettant en œuvre un système de redondance de manière à assurer une continuité de service en cas de crash.
L'initiateur transmet la liste des proxies à l'entité de confiance qui à réception transmet à chaque proxy l'ensemble des informations cryptographiques nécessaire pour authentifier le message que chaque proxy envoie au répondeur.
Dans la réalisation préférentielle de cette seconde variante de l'invention, les informations cryptographiques comprennent une paire clé publique / clé privée d'un système de signature.
Avantageusement, un tel système de signature à usage unique peut être le système dit « HORS » décrit dans le papier de L. Reyzin et al. "Better than BiBa: Short One-Time Signatures with Fast Signing and Verifying", LNCS 2384, pp. 144-153, 2002. L'entité de confiance fournit également à chaque proxy un moyen qui autorise ce dernier à signer des messages d'échange du protocole au nom de l'initiateur, c'est-à-dire de prouver son habilitation à agir au nom de l'initiateur. Ce moyen peut prendre la forme d'un message associant cryptographiquement le droit assigné au proxy de signer au nom de l'initiateur, le certificat envoyé antérieurement par l'initiateur à l'entité de confiance, la partie publique du matériel cryptographique remis par l'entité de confiance au proxy, le tout étant signé par la clé privée de l'entité de confiance.
Après l'envoi du message 232 contenant l'identité du répondeur et éventuellement la preuve de représentativité, chaque proxy établit une connexion avec le répondeur et éventuellement envoie un message (234) contenant la preuve de représentativité qu'il a reçu de l'initiateur ou d'une entité de confiance.
A l'issue de la phase 230, le répondeur et les proxies ont établi les paramètres de connexion pour leur session.
L'étape suivante va consister à préparer et échanger des modèles initiaux de la clé de session entre l'initiateur et le répondeur (aussi appelés « premaster secrets x et y » en anglais) afin de calculer plus tard la clé de session partagée. L'initiateur remet au répondeur un secret x généré aléatoirement et le répondeur remet à l'initiateur un secret y. La clé de session sera calculée ensuite à partir de ces deux valeurs secrètes. Dans la phase suivante (240), l'initiateur (202) décompose (242) son secret x en n fragments de secret, n étant le nombre de proxies sélectionnés pour supporter la session. Chaque valeur de secret est assignée à un proxy.
Avantageusement, une procédure de correction d'erreurs peut être appliquée sur le secret x original avant de le décomposer, de manière à lui rajouter de la redondance. Ceci permet au répondeur d'être en mesure de reconstituer le secret envoyé par l'initiateur à condition qu'un nombre suffisant de paquets soient reçus de la part des nœuds assistants, mais sans requérir la réception de l'ensemble des messages provenant de la totalité des nœuds assistants. Ce système protège notre solution contre la compromission ou le refus de collaborer des nœuds assistants. En outre, il permet de ne pas imposer une livraison fiable pour chaque connexion entre un proxy et le répondeur.
L'initiateur transmet (244) à chaque proxy le fragment de secret qui lui est assigné.
Avantageusement, chaque message est envoyé de façon sécurisée, en utilisant une association de sécurité basée sur une clé symétrique ( k i_Pi ) entre l'initiateur et chaque proxy.
A la réception de son fragment de secret, le proxy chiffre le fragment et signe le résultat en utilisant sa clé privée. Le proxy avantageusement chiffre son fragment en utilisant la clé publique du serveur qui correspond à son identifiant cryptographiquement généré, tel que communiqué par l'initiateur dans une phase précédente. Puis, chaque proxy transmet (246) au répondeur un message signé contenant le fragment de secret qui lui a été assigné, et chiffré.
Après avoir reçu un nombre suffisant de fragments, le répondeur peut retrouver le secret x original et reconstruire le secret x de l'initiateur.
Le répondeur génère aléatoirement (248) à son tour un secret y et le transmet (249) dans un message aux proxies. Le message est également construit à partir du secret x reconstruit par le répondeur. Les proxies supportent la charge de calcul nécessaire pour vérifier le message reçu de la part du répondeur et pour le transmettre (250) ensuite à l'initiateur.
Avantageusement, chaque proxy transmet à l'initiateur un message protégé au moyen de clés symétriques ki_pi partagées entre l'initiateur et chaque proxy. Afin de préserver la confidentialité de y, ce dernier est chiffré avec le secret x préalablement transmis au répondeur par l'initiateur.
Avantageusement, afin d'assurer à l'initiateur que le secret x a bien été reçu, le secret y chiffré par x est muni d'un « Message Authent icat ion Code ou (MAC) en anglais » calculé avec x comme clé. Ce message MAC assure à l'initiateur que le message chiffré reçu a bien été envoyé par une entité ayant connaissance de la valeur x. Dans une variante de l'invention, le récepteur envoie à tous les proxies un message contenant y encrypté par x, muni d'un MAC calculé à partir de x, le tout étant signé au moyen de la clé privée du récepteur. A réception de ce message, les proxies vérifient la validité de la signature du récepteur et, en cas de message valide, font suivre à l'initiateur le message reçu sans sa signature, c'est-à-dire : y encrypté par x, muni d'un MAC calculé à partir de x, ce message étant encrypté au moyen de la clé symétrique ^_Ρ1.
Dans une autre variante de l'invention, le récepteur envoie à un ou plusieurs proxies le message contenant y encrypté par x, muni d'un MAC calculé à partir de x, le tout étant signé au moyen de la clé privée du récepteur. Le ou les proxies auxquels le récepteur a envoyé le message vérifient la validité de la signature du récepteur et, en cas de message valide, font suivre à l'initiateur le message reçu sans sa signature, c'est-à-dire : y encrypté par x, muni d'un MAC calculé à partir de x, ce message étant encrypté au moyen de la clé symétrique k i_Pi .
Dans une phase suivante (260), la méthode procède au calcul de la clé de session. Les deux entités initiateur (202) et répondeur (206) calculent la clé finale en fonction des deux secrets x et y échangés et de paramètres additionnels.
Avantageusement à la fin de l'échange, le répondeur retourne un message à l'initiateur contenant les proxies qui ont réellement et de manière fiable coopéré durant l'échange des secrets, afin de lui permettre d'affiner sa future sélection des participants et de révoquer les nœuds malicieux.
Dans une variante d ' implémentation, les messages (232) de l'initiateur aux proxies contenant l'identité du répondeur et la preuve de représentativité sont regroupés avec les messages (244) respectifs n aux proxies contenant les valeurs des fragments de secret (xl, xn) .
La figure 3 déroule les étapes (300) opérées par la méthode de l'invention pour établir une session dans une implémentation préférentielle.
A l'étape (302), une requête pour établir une connexion sécurisée entre une entité source et une entité cible est émise. La requête peut être à l'initiative de l'entité contrainte en ressources ou à l'initiative d'un serveur distant vers une entité contrainte en ressource. L'émission de la requête déclenche la phase (220) précédemment décrite afin que l'initiateur et le répondeur établissent les paramètres de connexion pour leur session.
A l'étape (304), le modèle initial de secret x est décomposé en une pluralité n de valeurs (xl, ... , xn) .
A l'étape (306), les n valeurs de secret (xl, ... , xn) sont assignées à n proxies (PI, ... , Pn) sélectionnés. Chaque proxy reçoit la valeur de secret qui lui est assignée de manière encryptée avec une clé symétrique .
Les proxies sont informés de l'identité du répondeur soit à l'étape (306), soit comme décrit plus haut dans une étape initiale (230) où ils reçoivent la preuve de leur représentativité auprès du répondeur.
A l'étape suivante (308), les n valeurs de secret sont chiffrées et signées par les proxies.
Chaque valeur chiffrée/signée est transmise au répondeur à l'étape suivante (310). L'étape (312) consiste à reconstruire le secret x à partir des valeurs de secret reçues des proxies. Le procédé attend de recevoir suffisamment de valeurs pour récupérer la valeur de secret initiale x et passer à l'étape suivante.
A l'étape (314), un secret y est généré aléatoirement par le répondeur et est chiffré et signé pour le transmettre aux proxies avec le secret x. A l'étape (316), si la signature reçue par les proxies est vérifiée et validée, le secret y est transmis à l'initiateur (étape 318), sinon le procédé s ' arrête .
L'étape (320) consiste à calculer la clé de session finale en fonction des deux secrets (x,y) échangés .
La Figure 4 montre les procédures exécutées entre les entités source, cible et assistante du réseau de la figure 1 dans une variante d ' implémentation de l'invention appliquée au protocole « HIP BEX ». Le mécanisme connu de puzzle spécifié dans le protocole HIP BEX est maintenu afin de protéger le répondeur contre les attaques d'épuisement de ressources lors de l'exécution du protocole.
Dans une première phase 420 similaire à la phase 220 décrite en référence à la figure 2, l'initiateur (402) envoie un premier message 422 au répondeur (406) pour obtenir l'association HIP et l'informer de la technique de coopération supportée pour l'échange de clé. Le répondeur répond par un message 424 pour commencer l'échange du protocole. Le message 424 du répondeur contient l'identifiant du répondeur, c'est- à-dire sa clé publique KR, et un puzzle composé d'un défi cryptographique que l'initiateur doit résoudre avant de continuer le protocole d'échange. Le niveau de difficulté du puzzle peut être ajusté en fonction du niveau de confiance de l'initiateur et ses capacités actuelles en termes de ressources. L'échange de puzzle dans le protocole HIP est un moyen de défense pour protéger le répondeur contre les attaques par déni de service. Ce dernier demeure passif jusqu'à la réception d'une réponse valide de la part de l'initiateur. L'initiateur calcule la solution du puzzle reçu.
Puis, l'initiateur transmet (426) la solution aux n proxies (404-1, 404-n) dans des messages I21i ... I21n. Ces messages sont également utilisés pour transmettre les n fragments du secret x aux n proxies. Chaque connexion entre l'initiateur et un proxy est une connexion sécurisée par une clé symétrique k];_pi.
Chaque proxy à réception de son message
respectif, le crypte au moyen de la clé publique KR du récepteur et le transmet (428) au répondeur dans un message 122 ±.
A la réception d'un message 122±, le répondeur vérifie la validité de la solution de puzzle. En l'absence d'une solution correcte, le message correspondant est rejeté. Si une solution correcte s'y trouve, le répondeur poursuit l'échange du protocole. Il envoie (430) un message R21i à chaque proxy contenant son secret y encrypté avec la clé secrète x, en y joignant une valeur
d'authentification « Message Authent icat ion Code (MAC) » calculée sur le message avec la clé x. Cette valeur d ' authentification permet à l'initiateur de s'assurer que la valeur reçue provient bien du répondeur, et aussi que le répondeur a bien reçu la clé x initialement transmise. En réception du message (430) du répondeur, le proxy vérifie son intégrité et transmet (432) d'une façon sécurisée le contenu à l'initiateur dans un message R22±. Dès qu'un nombre approprié, typiquement supérieur à n/2, du même contenu est reçu de la part des différents proxies, l'initiateur s'assure de la validité du message transmis par le répondeur.
Consécutivement, il vérifie le MAC afin de s'assurer que le répondeur a obtenu le même secret x et de vérifier l'intégrité du message. Une fois cette intégrité validée, l'initiateur déchiffre le secret y afin de finaliser la mise en place de la clé de session principale.
Avantageusement, la clé finale « Master Key ou (MK) en anglais » établie entre l'initiateur et le répondeur est calculée comme suit:
MK: = H ( (P I HIT-I | HIT-R | x | y) où :
H () est une fonction de hachage cryptographique unidirectionnelle ;
P est un paramètre du puzzle, inclus afin
d'assurer la fraîcheur de la clé de session ;
HIT-I est le Host Identity Tag de l'initiateur, c'est-à-dire un hash tronqué de son identifiant cryptographiquement généré ;
HIT-R est le Host Identity Tag du répondeur ; et x et y sont les valeurs secrètes respectives de l'initiateur et du répondeur.
L'homme de l'art appréciera que des variations peuvent être apportées sur la méthode telle que décrite de manière préférentielle, tout en maintenant les principes de l'invention. Ainsi, il est possible que l'établissement de la connexion entre une entité contrainte en ressources et un serveur non contraint soit à l'initiative de ce dernier. Le premier message envoyé (222, 422) est par le serveur, et ensuite la méthode suit les étapes décrites précédemment. Dans une variante où les entités contraintes sont dans le contexte de l'Internet des Objets, les identités des noeuds devant faire office de proxies peuvent être fournies de façon sécurisée par une infrastructure de résolution de confiance. Ils rendent également possible la mise en relation simple de nœuds basés sur des technologies différentes, telles que des tags actifs, des nœuds IP, des nœuds non-IP, dès lors que les identifiants cryptographiques sont utilisés à un niveau supérieur à la couche IP.
La présente invention peut s ' implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tells supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM) , des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD-ROM) , Compact Disk - Read/Write (CD-R/W) and DVD) .
Ainsi la présente description illustre une implémentation préférentielle de l'invention, mais n'est pas limitative. Un exemple a été choisi pour permettre une bonne compréhension des principes de l'invention, et une application concrète, mais il n'est en rien exhaustif et doit permettre à l'homme du métier d'apporter des modifications et variantes d ' implémentation en gardant les mêmes principes.

Claims

Revendications
1. Dans un réseau de communication comprenant une plura- lité d'entités communicantes, une méthode pour éta¬ blir une clé de session entre une entité source et une entité cible, la méthode comprenant les étapes de :
générer (304) un secret x pour l'entité source, le secret comprenant n valeurs de secret (χΐ,χί,χη) ; assigner (306) chaque valeur de secret (xi) à une entité assistante (Pi) parmi la pluralité d'entités communicantes ;
chiffrer et signer (308) par chaque entité assis- tante la valeur de secret assignée (xi) ;
authentifier (312) l'entité source à réception par l'entité cible d'une ou plus valeurs de secret (χΐ,χί,χη) chiffrées et signées ;
générer (314) un secret y chiffré et signé pour l'entité cible ;
authentifier (316) l'entité cible à réception par au moins une des n entités assistantes (ΡΙ,Ρί,Ρη) de la valeur de secret y chiffré et signé ; et
générer (320) une clé de session entre l'entité source et l'entité cible à réception par l'entité source de la valeur de secret y authentifiée et dudit secret x de l'entité source.
2. La méthode selon la revendication 1 comprenant après l'étape (308) l'étape de transmettre (246,310) à l'entité cible les valeurs de secret chiffrées et signées.
3. La méthode selon la revendication 1 ou 2 comprenant après l'étape (314) l'étape de transmettre (249) à la pluralité d'entités assistantes les valeurs de secret x et y chiffrées et signées.
4. La méthode selon l'une quelconque des revendica- tions 1 à 3 comprenant après l'étape d ' authentification (316) l'étape de transmettre (250,318) la valeur de secret y à l'entité source.
5. La méthode selon l'une quelconque des revendica- tions 1 à 4 comprenant avant l'étape (304) de géné¬ rer un secret x, l'étape de détecter (302) une re¬ quête pour établir une connexion sécurisée entre l'entité source et l'entité cible.
6. La méthode selon la revendication 5 comprenant après l'étape (302) de détection de requête, l'étape (220) de définir un protocole d'échange de données cryptographique entre l'entité source et l'entité cible.
7. La méthode selon la revendication 6 dans laquelle l'étape (220) de définir un protocole d'échange de données cryptographique comprend des étapes d'échange de messages entre les entités source et cible, les messages comprenant au moins des infor¬ mations relatives à la sécurité supportée par chaque entité source et cible, à l'identité des en- tités source et cible, aux algorithmes cryptogra¬ phiques supportés par les entités source et cible, et aux méthodes d'établissement de clé.
8. La méthode selon l'une quelconque des revendica¬ tions 1 à 7 comprenant avant l'étape (306) d'assigner, l'étape de sélectionner n entités assistantes (ΡΙ,Ρί,Ρη), chaque entité assistante (Pi) étant moins contrainte en ressources que l'entité source.
9. La méthode selon l'une quelconque des revendica¬ tions 1 à 8 comprenant après l'étape (306) d'assigner, l'étape (232) de transmettre aux enti- tés assistantes, des éléments de preuve de leur re¬ présentativité de l'entité source.
10. La méthode selon la revendication 9 comprenant avant l'étape (312) d ' authentification, l'étape (234) de transmettre à l'entité cible lesdits élé¬ ments de preuve.
11. La méthode selon l'une quelconque des revendica¬ tions 7 à 10 dans laquelle le système d'établissement de clé est appliqué au protocole
HIP BEX (Base Exchange) .
12. Un système pour établir une clé de session entre une entité source et une entité cible dans un ré¬ seau de communication comprenant une pluralité d'entités communicantes, le système comprenant des moyens pour mettre en œuvre les étapes de la mé- thode selon l'une quelconque des revendications 1 à 11.
13. Le système selon la revendication 12 où l'entité source est contrainte en ressource et l'entité cible est un serveur distant non contraint en res¬ source .
14. Un produit programme d'ordinateur, ledit pro- gramme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes de la mé¬ thode selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un or¬ dinateur .
EP13709249.0A 2012-03-27 2013-03-15 Methode et systeme d'etablissement d'une cle de session Withdrawn EP2832034A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1252737A FR2988942B1 (fr) 2012-03-27 2012-03-27 Methode et systeme d'etablissement d'une cle de session
PCT/EP2013/055436 WO2013143888A1 (fr) 2012-03-27 2013-03-15 Methode et systeme d'etablissement d'une cle de session

Publications (1)

Publication Number Publication Date
EP2832034A1 true EP2832034A1 (fr) 2015-02-04

Family

ID=46826619

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13709249.0A Withdrawn EP2832034A1 (fr) 2012-03-27 2013-03-15 Methode et systeme d'etablissement d'une cle de session

Country Status (4)

Country Link
US (1) US9608967B2 (fr)
EP (1) EP2832034A1 (fr)
FR (1) FR2988942B1 (fr)
WO (1) WO2013143888A1 (fr)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2992509B1 (fr) * 2012-06-21 2017-05-26 Commissariat Energie Atomique Dispositif et procede pour generer une cle de session
US10069811B2 (en) * 2013-10-17 2018-09-04 Arm Ip Limited Registry apparatus, agent device, application providing apparatus and corresponding methods
US9307405B2 (en) 2013-10-17 2016-04-05 Arm Ip Limited Method for assigning an agent device from a first device registry to a second device registry
US9860235B2 (en) * 2013-10-17 2018-01-02 Arm Ip Limited Method of establishing a trusted identity for an agent device
EP3108633B1 (fr) * 2014-02-18 2018-10-31 Nokia Technologies OY Gestion de clé
GB2529838B (en) 2014-09-03 2021-06-30 Advanced Risc Mach Ltd Bootstrap Mechanism For Endpoint Devices
GB2530028B8 (en) 2014-09-08 2021-08-04 Advanced Risc Mach Ltd Registry apparatus, agent device, application providing apparatus and corresponding methods
US9641400B2 (en) 2014-11-21 2017-05-02 Afero, Inc. Internet of things device for registering user selections
US10291595B2 (en) 2014-12-18 2019-05-14 Afero, Inc. System and method for securely connecting network devices
US20160180100A1 (en) 2014-12-18 2016-06-23 Joe Britt System and method for securely connecting network devices using optical labels
US9832173B2 (en) 2014-12-18 2017-11-28 Afero, Inc. System and method for securely connecting network devices
US9704318B2 (en) 2015-03-30 2017-07-11 Afero, Inc. System and method for accurately sensing user location in an IoT system
US10045150B2 (en) 2015-03-30 2018-08-07 Afero, Inc. System and method for accurately sensing user location in an IoT system
US9717012B2 (en) 2015-06-01 2017-07-25 Afero, Inc. Internet of things (IOT) automotive device, system, and method
US9729528B2 (en) * 2015-07-03 2017-08-08 Afero, Inc. Apparatus and method for establishing secure communication channels in an internet of things (IOT) system
US9699814B2 (en) 2015-07-03 2017-07-04 Afero, Inc. Apparatus and method for establishing secure communication channels in an internet of things (IoT) system
US10015766B2 (en) 2015-07-14 2018-07-03 Afero, Inc. Apparatus and method for securely tracking event attendees using IOT devices
GB2540989B (en) 2015-08-03 2018-05-30 Advanced Risc Mach Ltd Server initiated remote device registration
GB2540987B (en) 2015-08-03 2020-05-13 Advanced Risc Mach Ltd Bootstrapping without transferring private key
US9954956B2 (en) * 2015-08-26 2018-04-24 Intel IP Corporation Secure discovery and connection to internet of things devices in a wireless local-area network
US9793937B2 (en) 2015-10-30 2017-10-17 Afero, Inc. Apparatus and method for filtering wireless signals
US10178530B2 (en) 2015-12-14 2019-01-08 Afero, Inc. System and method for performing asset and crowd tracking in an IoT system
US10523437B2 (en) * 2016-01-27 2019-12-31 Lg Electronics Inc. System and method for authentication of things
US10084760B2 (en) 2016-03-11 2018-09-25 Hewlett-Packard Development Company, L. P. Secure messages for internet of things devices
US10158651B1 (en) 2016-04-20 2018-12-18 Wells Fargo Bank, N.A. Verifying secure transactions through distributed nodes
US10574451B2 (en) * 2017-10-19 2020-02-25 Bank Of America Corporation Method and apparatus for perfect forward secrecy using deterministic hierarchy
GB2579571B (en) 2018-12-03 2021-05-12 Advanced Risc Mach Ltd Device bootstrapping
US11475134B2 (en) 2019-04-10 2022-10-18 Arm Limited Bootstrapping a device
US20210111876A1 (en) * 2019-10-11 2021-04-15 Atakama LLC Secure session for decryption
CN111818527A (zh) * 2020-07-01 2020-10-23 华中科技大学 一种数控系统移动设备无线安全联网技术
CN112738038B (zh) * 2020-12-17 2024-05-28 北京握奇智能科技有限公司 一种基于非对称口令认证的密钥协商的方法和装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6151676A (en) * 1997-12-24 2000-11-21 Philips Electronics North America Corporation Administration and utilization of secret fresh random numbers in a networked environment
JP3854954B2 (ja) * 2003-09-05 2006-12-06 キヤノン株式会社 データ共有装置
US7509487B2 (en) * 2003-09-29 2009-03-24 Gemalto Inc. Secure networking using a resource-constrained device
WO2005099170A1 (fr) * 2004-04-05 2005-10-20 Nippon Telegraph And Telephone Corporation Dispositif de substitution de cryptage de paquet, methode de celui-ci et support d’enregistrement de programme
DE102004032057A1 (de) * 2004-07-01 2006-01-26 Francotyp-Postalia Ag & Co. Kg Verfahren und Anordnung zum Generieren eines geheimen Sitzungsschlüssels
GB2442044B8 (en) * 2006-05-11 2011-02-23 Ericsson Telefon Ab L M Addressing and routing mechanism for web server clusters.
US8181227B2 (en) * 2006-08-29 2012-05-15 Akamai Technologies, Inc. System and method for client-side authenticaton for secure internet communications
US20080144836A1 (en) * 2006-12-13 2008-06-19 Barry Sanders Distributed encryption authentication methods and systems
US7849166B1 (en) * 2008-01-11 2010-12-07 Trend Micro Incorporated Creation of secure communication connections through computer networks
US20090239503A1 (en) * 2008-03-20 2009-09-24 Bernard Smeets System and Method for Securely Issuing Subscription Credentials to Communication Devices
CN101626374B (zh) 2008-07-11 2013-08-28 成都市华为赛门铁克科技有限公司 IPv6网络中协商SA的方法、系统和设备
US8155056B2 (en) * 2008-12-11 2012-04-10 Motorola Solutions, Inc. Method and apparatus for controlling traffic congestion in a wireless communication network
US9165158B2 (en) * 2010-08-17 2015-10-20 Hewlett-Packard Development Company, L.P. Encryption key management using distributed storage of encryption-key fragments

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2013143888A1 *

Also Published As

Publication number Publication date
WO2013143888A1 (fr) 2013-10-03
US20150067329A1 (en) 2015-03-05
US9608967B2 (en) 2017-03-28
FR2988942B1 (fr) 2015-08-28
FR2988942A1 (fr) 2013-10-04

Similar Documents

Publication Publication Date Title
EP2832034A1 (fr) Methode et systeme d'etablissement d'une cle de session
Malik et al. A survey of key bootstrapping protocols based on public key cryptography in the Internet of Things
Heer et al. Security Challenges in the IP-based Internet of Things
CN107534658B (zh) 使用公钥机制在服务层的端对端认证
Saied et al. HIP Tiny Exchange (TEX): A distributed key exchange scheme for HIP-based Internet of Things
Mahalle et al. Identity establishment and capability based access control (iecac) scheme for internet of things
FR3004041A1 (fr) Procede et dispositif d'etablissement de cles de session
CN114503507A (zh) 安全的发布-订阅通信方法和设备
WO2013160140A1 (fr) Methode et systeme d' authentification des noeuds d'un reseau
WO2019178942A1 (fr) Procédé et système d'exécution de négociation ssl
WO2013190003A1 (fr) Dispositif et procede pour generer une cle de session entre des entites a faibles ressources
EP3386162A1 (fr) Communication sécurisée de bout en bout pour capteur mobile dans un réseau iot
EP3174241A1 (fr) Méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur et un objet connecté
Marino et al. PKIoT: A public key infrastructure for the Internet of Things
Kumar et al. A lightweight signcryption method for perception layer in Internet-of-Things
Abdmeziem et al. A cooperative end to end key management scheme for e-health applications in the context of internet of things
Srikanth et al. An efficient Key Agreement and Authentication Scheme (KAAS) with enhanced security control for IIoT systems
Singh et al. Cryptanalysis and improvement in user authentication and key agreement scheme for wireless sensor network
EP2186252B1 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
Chellappan et al. Security and privacy in the Internet of Things
Babu et al. Fog‐Sec: Secure end‐to‐end communication in fog‐enabled IoT network using permissioned blockchain system
FR3072238A1 (fr) Dispositif et procede de transmission de donnees
Saied et al. Energy efficiency in M2M networks: A cooperative key establishment system
WO2019165330A1 (fr) Système et procédés de preuve d'un élément de réseau
Fayad et al. A blockchain-based lightweight authentication solution for IoT

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140905

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20180410

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180821