WO2014154482A1 - Procede et dispositif d'etablissement de cles de session - Google Patents

Procede et dispositif d'etablissement de cles de session Download PDF

Info

Publication number
WO2014154482A1
WO2014154482A1 PCT/EP2014/054791 EP2014054791W WO2014154482A1 WO 2014154482 A1 WO2014154482 A1 WO 2014154482A1 EP 2014054791 W EP2014054791 W EP 2014054791W WO 2014154482 A1 WO2014154482 A1 WO 2014154482A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
key
target
source
message
Prior art date
Application number
PCT/EP2014/054791
Other languages
English (en)
Inventor
Aymen BOUDGUIGA
Nouha OUALHA
Alexis Olivereau
Christophe Janneteau
Original Assignee
Commissariat A L'energie Atomique Et Aux Energies Alternatives
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 L'energie Atomique Et Aux Energies Alternatives filed Critical Commissariat A L'energie Atomique Et Aux Energies Alternatives
Priority to EP14709651.5A priority Critical patent/EP2979390A1/fr
Priority to US14/779,487 priority patent/US9787651B2/en
Priority to CN201480018723.2A priority patent/CN105075175A/zh
Priority to JP2016504550A priority patent/JP2016514913A/ja
Publication of WO2014154482A1 publication Critical patent/WO2014154482A1/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/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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/80—Wireless

Definitions

  • the invention relates to the field of network communications and in particular that of encrypted communications between the entities of a network. State of the art
  • the establishment of a session key between two entities of a communication network is a fundamental prerequisite for the implementation of the vast majority of cryptographic services intended to secure the exchanges between these entities.
  • the protection of data exchanged against attacks intended to modify them or simply to read them is generally based on symmetric cryptographic primitives, in which the entities communicating with each other use the same key when sending (encryption, integrity protection) and receiving (decryption, integrity checking) of a message.
  • a session key is a procedure intended to intervene many times in the lifetime of a communicating entity.
  • a new symmetric key must be used for any secure exchange with any new correspondent.
  • These correspondents are all the more numerous as the entity participates in a scenario favoring interactions between members, for example of the type of sensor network (Wireless Sensor Network, WSN), Machine to Machine (M2M) or Internet of Things (loT ).
  • WSN Wireless Sensor Network
  • M2M Machine to Machine
  • LoT Internet of Things
  • a session key is characterized by a limited life, and should be regularly refreshed. Thus, the procedure implemented to establish a session key is particularly important, and requires a neat design.
  • the security of the protocol must be guaranteed. Thus, the confidentiality of the established key and the mutual authentication of the two correspondents must be ensured. Added to this are other security settings, such as Denial of Service (DDoS) protection that protects entities involved in protocol execution from attacks aimed at depleting their energy resources and / or system resources.
  • DDoS Denial of Service
  • the session key setup protocol must be efficient in terms of bandwidth requirements and power consumption, and in particular from the point of view of the cryptographic computations implemented. This second criterion is particularly important when the session key establishment protocol must be implemented by entities having only low energy resources, such as a battery, or a low computing capacity and / or memory .
  • the protocol can offer additional functionalities, such as the interoperability of the authentication mechanisms between two nodes implementing it or the possibility of a centralized control over the exchange of keys and / or the possibility of a definition. centralized security policies accompanying established keys.
  • Three main approaches have been developed to establish session keys between two nodes.
  • the first family is the key transport, known as Anglicism
  • key transport which consists in securely transporting by encryption one or more secret values from one of the two participants from one session to the other.
  • These secret value transports can be made in one direction only and this mode is known by the Anglicism "one-pass key transport protocol” is to be made in both directions, and this mode is known then under the anglicism "two-pass key transport protocol”.
  • the session key is then derived from these secret values.
  • the second family of session keying solutions is the key agreement, known as the "key agreement”.
  • This approach consists of an exchange of public values between the two nodes from which a common session key is recovered by the two entities participating in the exchange without the public values exchanged having to be decrypted.
  • the main known protocol of "key agreement” is the Diffie-Hellman protocol. In terms of resources consumed, mainly at the level of energy consumed in cryptographic operations, the "key agreement" is a costly approach.
  • a third family of session keying solutions is key distribution, known as key distribution.
  • key distribution In this approach, a third entity often called “trusted third party” intervenes to provide the other two participants a secret value that allows them to calculate the session key or the session key itself.
  • key distribution also involves direct exchanges between the two participants. Indeed, they must prove their involvement in the protocol, establish the freshness of the messages they send and prove their knowledge of the established secret.
  • Key distribution although a simple solution to implement, light in terms of cryptographic operations required and energy consumed, has disadvantages not yet solved by existing solutions.
  • Needham and Schroeder key transport protocol presented in the document "Using encryption for authentication in large networks of computers," Communication of the ACM, Volume 21, Number 12, 1978, contains five message exchanges between two entities, one initiator (I) and an answering machine (R) that each share an encryption key with a trusted third party (TC). The exchange of the five messages is shown in FIG.
  • One of the major issues in the Needham and Schroeder protocol is an impersonation attack by an attacker posing as the initiator and replaying the third message (Message3) between the initiator and the responder.
  • the attacker who can know the key generated by the trusted third party, can then decipher the fourth message and impersonate the session by sending the last message.
  • a disadvantage of the Kerberos protocol is that it is not symmetrical with respect to the initiator and the receiver.
  • the trusted third party has no assurance that the receiver has been contacted or has agreed to participate in the secure transaction.
  • the Kerberos protocol is limited in its applications and rather intended to allow access from a client initiator to a resource supposed not to be subject to malicious behavior, such as a printer or a file server.
  • WO 2009/070075 A1 to Blom et al. Entitled “Key management for secure communication” presents a method for establishing session keys for secure communications between two entities.
  • the method relies on the MIKEY-Ticket key distribution protocol specified in RFC 6043 of Mattsson and Tian, "MIKET-Ticket: Ticket-based modes of key distribution in Multimedia Internet KEYing (MIKEY)".
  • MIKEY Multimedia Internet KEYing
  • this protocol can be the target of denial of service attacks.
  • the skilled person knows the different forms of denial of service attacks.
  • An attacker can create a denial of service by exploiting implementation errors in communication protocols, for example, if the protocol used is implemented to block nodes when they receive unknown data. An attacker can then make a denial of service attack by sending messages containing erroneous fields to the responder, his target.
  • Another way to perform a denial of service is to initiate a communication with the target and then stop sending messages to block the target in an acknowledgment state and saturate its receiving stack.
  • denial of service can be distributed by using several attackers at the same time to saturate the target as quickly as possible and to make it more difficult for the attacker to trace.
  • An object of the present invention is to provide a method for setting session keys that is secure and protected against denial of service attacks.
  • the invention offers both an initiating node and an answering node protection against denial of service attacks.
  • Another object of the present invention is to provide an efficient session key setting method in terms of consumed resources.
  • the method of the invention allows the establishment of a session in four or five message exchanges and relies on the use of symmetric cryptographic primitives.
  • the present invention will be implemented in the fields of machine-to-machine (M2M) communications security, or in the context of networks of nodes constrained in resources such as sensors and / or actuators, which are among the nodes most resource-intensive and may need to dynamically set session keys.
  • M2M machine-to-machine
  • a for the authentication code are derived from an initial key obtained after a step of authenticating the target entity with the third-party trusted entity.
  • the message received from the source entity further comprises a source nonce (Ni) to prove the freshness of the message of the source entity.
  • Ra for the source entity includes the steps of concatenating the key K
  • the message sent to the target entity further comprises the nonce (Ni) and the authentication code based on the second target key K Ra is calculated on the nonce.
  • the message received from the target entity further comprises the source nonce (Ni) and a target nonce (N R ) to prove the freshness of the target message.
  • the message sent to the source entity further comprises the source and target nonces (Ni, N R ).
  • the identifiers of the source and target entities are either IPv6 addresses, MAC addresses or URLs.
  • the nuncio is either a timestamp information, a random number or a counter.
  • the message sent by the third-party trusted entity to the target entity also contains a key encrypted by the keys K
  • the method further comprises a step of sending a message from the source entity to the target entity that contains the identifiers of the source entity and the target entity, the source and target nonces (Ni , N R ) and an authentication code calculated with the key K
  • the invention further relates to a system for establishing a session key between a source entity and a target entity, the source entity sharing with a third-party trusted entity a first source key K
  • the invention may operate in the form of a computer program product that includes code instructions for performing the claimed process steps when the program is run on a computer.
  • Figure 1 illustrates the message exchanges according to the method of Needham and Schroeder
  • Figure 2 illustrates the message exchanges according to the method of
  • FIG. 3 illustrates the message exchanges according to the method of Otway and Rees
  • Figure 4 is a topological representation of a network infrastructure in which to advantageously implement the invention.
  • FIG. 5 shows the procedures executed between the initiator, responder and trusted third party entities of the network of FIG. 4 according to the MIKEY-Ticket method
  • Figure 6 shows the procedures performed between initiator, responder and trusted third party entities of the network of Figure 4 in an advantageous implementation of the invention
  • FIG. 7 shows the procedures executed between the initiator, responder and trusted third party entities of the network of FIG. 1 in an implementation variant of the invention.
  • FIG. 4 illustrates an example of an infrastructure of communication 100 in which advantageously implement the invention.
  • the example of FIG. 4 only shows a finite number of entities (or nodes) 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 communication network (1 00) comprises fixed or mobile entities that can form an object network (102). Entities can be heavily resource constrained (102-1, 102-n) or resource constrained (1 12-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 constraints may be mobile phones equipped with an internet connection and a 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 node network (102) may be based on level 2 (e.g., 802.1 5.4 or 802.11) and / or level 3 (e.g., IP) communications between the entities of which it is composed. Following the protocols on which it relies, multicast or broadcast communication schemes can be used.
  • level 2 e.g., 802.1 5.4 or 802.11
  • level 3 e.g., IP
  • the present invention may be advantageously applied in the environment of FIG. 4 between two nodes of the network, a source entity that is called an 'initiator' and a target entity that is called a 'responder'. Both entities need to establish a security association with each other.
  • a central key distribution server (106) that is known as a trusted third party is responsible for authenticating the nodes. It may be remote and accessible via a third party communications network (104) which may be a cellular network or the Internet.
  • the trusted third party stores cryptographic data necessary for the authentication of each of the nodes.
  • each initiator and responder node authenticates to the central server using its own credentials, identity templates, and independent authentication methods most in accordance with each their own specificities and constraints.
  • two nodes can for example establish a session key and associate with their respective identities while the latter are respectively validated by means of a smart card for one and a biometric authentication for the other.
  • the trusted server distributes the same two-node session key that wants to establish a security association between them, allowing decorrelated authentications for each node, as well as centralized control over the key establishment and / or the policies that accompany it. these last.
  • FIG. 5 shows the procedures performed according to the known Mikey-Ticket protocol between an initiator node (I), a responder node (R) and a trusted third party (TC) of the network of FIG. 4.
  • E ⁇ K, (Datai, Data 2 , ...) ⁇ designates the encryption of the concatenated data (Datai, Data 2 , 7) with an encryption algorithm using a key K.
  • MAC ⁇ K, (Datai, Data 2 , ...) ⁇ designates the Message Authentication Code (MAC) on the concatenated data (Datai, Data 2 , ...) using a K key
  • MIKEY-Ticket protocol has been defined to extend the MIKEY protocol by the use of a trusted third party and is based on the exchange of six messages between the three initiator entities (I), responder (R) and trusted third party (TC).
  • An initiating node sends the trusted third party a first message in the form of an initialization request "Request_init”.
  • the request contains a MAC authentication code which is calculated with its key "Kia”.
  • TC checks the validity of the MAC and the authenticity of the data (Datai) sent by the initiator.
  • This data mainly contains an identifier of the answering node with which the initiator node wants to establish a session, a nonce and information on the MAC encryption and computation algorithms supported by the initiator.
  • the trusted third party generates a "KIR” key and transmits it to the initiator in a "Request_resp” response message.
  • R is encrypted by the encryption key "Ki e " of the initiator.
  • the second message also contains a ticket "Ticketi” for the initiator and a MAC calculated with the key K ! a .
  • the initiator verifies the validity of the MAC and retrieves his key K ! R which will allow him to derive with the answering machine two keys "KiRa" and "K
  • Ra will be used to calculate MACs while the KiRe key will encrypt data.
  • the initiator then sends the responder a message "Transfert_init” which contains its ticket “Ticketi”.
  • This third message contains a MAC calculated with the key K
  • the answering node (R) has not yet received the key K
  • the answering machine On receipt of the fifth message, the answering machine checks the MAC calculated by the trusted third party and retrieves the key K
  • the answering node only checks the MAC sent by the initiator in the third message, after having exchanged the fourth and fifth messages with the trusted third party, it can then be the target of denial of service attack.
  • An attacking node may bombard the answering node with an unlimited number of "Transfe nit” messages (third message) to force him to compute a large number of messages “Resolve_init” (fourth message) and thus exhaust all energy and computing resources of the answering node.
  • Figure 6 shows the procedures performed between entities
  • An important advantage of the invention lies in the energy efficiency of the method implemented which is obtained by means of a reduced number of exchanged messages.
  • the proposed method makes it possible to establish secure communication between an initiating node and an answering node in five message exchanges in the implementation of FIG. 6, or in four message exchanges according to the implementation of FIG. note that the last message described for both examples is exchanged between the initiator and the responder and corresponds to a confirmation of key by the initiator which can be implicit.
  • the secure exchange of data between the initiator and the responder can begin respectively after the fourth and the third message of Figures 6 and 7.
  • the message exchanges give roles equivalent to the initiating node (I) and the receiving node (R) with respect to the trusted third party (TC). Indeed, the interactions are of type (l) e (TC), (TC) el (l), (R) tt (TC) and (TC) al (R) and thus offer the trusted third party a better control of session key establishment.
  • the implementation illustrated in FIG. 6 can advantageously be applied when establishing a secure communication between two nodes that do not share any secret directly, but which each share one or more secrets with a trusted third party (TC) .
  • the trusted third party and the initiator initially share two keys (K
  • K ! E and K ! A can be derived from a master key following authentication of the initiator with the trusted third party.
  • the answering machine (R) also shares a key pair (K Re , K Ra ) with the trusted third party.
  • the initiator and the responder each designate a simple entity, but that in a more general case, it may be a group of initiating nodes and / or a group of answering nodes using individual keys and / or group keys.
  • the initiator (I) contacts the trusted third party (TC) to create one or more keys for them.
  • the trusted third generates a single key KIR for both nodes (I) and (R). Then, the trusted third party sends the encrypted key KIR with the key K
  • the integrity of the messages exchanged is ensured by the addition of MACs, respectively calculated using the keys Kia and K RA .
  • the initiator starts the process by sending a first "Messagel" message to the trusted third party.
  • This message contains the identifiers of the initiator (IDi), the trusted third party (ID T c) and the responder (ID R ). It also contains a nuncio (Ni) that serves to prove the freshness of the session and to avoid replay attacks.
  • the initiator adds to the messagel a MAC (MACn) calculated on (ID ,, ID T c, ID R and N,) with the key K ! A.
  • MACn MAC
  • the identifiers may depend on the technology used and the type of network deployed. These identifiers may be, for example, IPv6 addresses, MAC addresses or URLs. In the particular case of IP networks, the identifiers ID
  • the nonce can be a timestamp information, a random number, or a counter (sequence number). It must be a variable and unique information in time that distinguishes the different executions of the known protocol of Menezes, Van Oorschot and Vanstone, described in the document "Handbook of Applied Cryptography", Chapter 10.
  • the Nuncio can also be formed by the combination of the techniques mentioned above. For example, a nonce can be formed by timestamp information and a random number.
  • the trusted third party On receipt of the first message, the trusted third party checks the freshness of the Nuncio Ni and uses the key K ! A to calculate the MAC (MAC T ci) on (ID
  • MACTC2 MAC
  • the trusted third concatenates the key K
  • This second message also contains the identifiers (IDi, I DTC, I DR), the nonce N, and the MAC (MACTC 2 ).
  • the MAC (MACTC 2 ) is calculated with the key K Ra on the following fields: ID T c, I DR, I DI, NI, and E ⁇ K Re , (K
  • the answering machine On receipt of the second message, the answering machine checks the equality between the received MAC T c2 and its own MAC value (MAC R2 ) which it calculates using the key K RA . If the value of MAC T C2 is good, the answering machine decrypts the content of E ⁇ K Re , (K
  • the answering machine generates a nonce (N R ) and calculates a MAC (MAC R
  • the MAC (MACRI) will be transmitted by the trusted third party to the initiator to enable him to verify that the answering machine has received the
  • the responder uses the nonces (Ni, N R ) and the key K ! R as inputs to a pseudo-random function to generate two keys "K
  • Ra is used for calculating the MACs
  • the KiR e key is used to encrypt data between the initiator and the responder.
  • the trusted third party In a second variant, the trusted third party generates two keys, "K
  • R is subsequently used to designate both the key used to calculate the MACs and for the encryption, independently of the methods which made it possible to generate the keys K
  • the responder generates a third message "Message3" for the trusted third party.
  • the message contains the identifiers (ID R ) and (ID T c), the nuncios (N R ) and (N,), the MAC R
  • the trusted third party checks the freshness of the nonce N R and calculates the MAC T c3 using the key K Ra and the identifier data (ID R , ID T c), of nonces (N R , Ni) and MAC (MACRI).
  • the trusted third party then verifies that the computed MAC T c3 is equal to the MAC R3 received from the receiver. If the value of the MAC T c3 received is valid, the trusted third party generates a message "Message4" to the initiator.
  • the fourth message contains the nonces N R and N
  • the key KIR is concatenated with the identifiers of the responder ID R and the trusted third party ID T c, and the nonces Ni and N R before being encrypted with the key K
  • the message sent by the trusted third party to the initiator also contains a MAC (MAC T c 4 ) calculated with the key K ! A which allows the initiator to check the integrity of the data received.
  • the initiator Upon receipt of the fourth message, the initiator calculates its MAC (MAC
  • the initiator uses the key K
  • the initiator locally calculates a MAC (MACIR) on the same fields as those used by the receiver when calculating the (MACRI), namely the identifiers (ID R , ID T c, ID
  • the initiator compares if there is a tie between his MACIR and the MAC TM. If both MACs are equal, it means that the answering machine has received the key K
  • the initiator sends directly to the responder the fifth message 5 which contains the respective identifiers of the initiator and the responder (I Di and ID R ), their nuncios (N
  • FIG. 7 shows the procedures executed between the initiator, responder and trusted third party entities of the network of FIG. 4 in an implementation variant of the invention consisting of four exchanged messages.
  • the initiator starts the process by sending a first message "Messagel" to the trusted third party.
  • the content of the first message is identical to that described with reference to FIG.
  • the trusted third party TC After receiving the Messagel, the trusted third party TC generates a nonce (N T c), as well as the key K
  • the nonce N T c is an optional parameter that allows to add freshness to the second message in the case where the responder combines the freshness of the message to the receipt of a new nuncio of the initiator but also the trusted third party.
  • N T c The addition of the Nunc (N T c) can be decided during the establishment of the security policy by the network administrator.
  • the trusted third digit with the key K RE , the nuncio, the key KIR, and this same key K
  • the cipher is sent in a second message "Message2bis" to the answering machine.
  • the message further contains a MAC calculated with the key K Ra , to allow the responder to verify the integrity of the data received.
  • the responder After receiving the second message, the responder verifies the integrity and authenticity of the received message using its key K Ra . If the result of the check is positive, the answering machine decrypts the message to retrieve the shared key K
  • the answering machine generates a nunc (N R ) then sends in a third message "Message3bis", the data received from the third party.
  • N R the number of bits
  • the answering machine also sends a calculated MAC with this key KIR.
  • the initiator Upon receipt of the third message, the initiator verifies the integrity of the first part of the message generated by the trusted third party by using the key K
  • the initiator then sends directly to the responder a fourth message which contains the identifiers of the initiator and the responder (ID
  • the answering machine checks the value of the MAC
  • the present invention can 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, floppies or disks (Compact Disk - Read Only Memory (CD-ROM)). 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)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé et un dispositif 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 procédé qui s'appuie sur l'utilisation de primitives cryptographiques symétriques offre à chaque entité de la session une protection contre les attaques par déni de service par l'établissement d'une session en quatre ou cinq échanges de messages.

Description

PROCEDE ET DISPOSITIF D'ETABLISSEMENT DE CLES DE
SESSION
Domaine de l'invention
L'invention concerne le domaine des communications réseau et en particulier celui des communications cryptées entre les entités d'un réseau. Etat de la Technique
L'établissement d'une clé de session entre deux entités d'un réseau de communication est un pré-requis fondamental à la mise en œuvre de la grande majorité des services cryptographiques destinés à sécuriser les échanges entre ces entités. Ainsi, la protection des données échangées contre des attaques visant à les modifier ou simplement à en prendre connaissance s'appuie en général sur des primitives cryptographiques symétriques, dans lesquelles les entités communiquant l'une avec l'autre utilisent la même clé lors de l'envoi (chiffrage, protection d'intégrité) et de la réception (déchiffrement, vérification de l'intégrité) d'un message.
L'établissement d'une clé de session est une procédure destinée à intervenir à de nombreuses reprises dans la durée de vie d'une entité communicante. Une nouvelle clé symétrique doit être utilisée pour tout échange sécurisé avec tout nouveau correspondant. Ces correspondants sont d'autant plus nombreux que l'entité participe d'un scénario favorisant les interactions entre membres, par exemple de type réseau de capteurs (Wireless Sensor Network, WSN), Machine à Machine (M2M) ou Internet des Objets (loT). Par ailleurs, une clé de session est caractérisée par une durée de vie limitée, et doit régulièrement être rafraîchie. Ainsi, la procédure mise en œuvre pour établir une clé de session est particulièrement importante, et requiert un design soigné.
Plusieurs paramètres sont à considérer pour juger de la qualité d'un protocole d'établissement de clé de session. Premièrement, la sécurité du protocole doit être garantie. Ainsi, la confidentialité de la clé établie et l'authentification mutuelle des deux correspondants doivent être assurés. S'ajoutent d'autres paramètres de sécurité, tels que la protection contre les attaques par déni de service qui protège les entités impliquées dans l'exécution du protocole contre des attaques visant à épuiser leurs ressources énergétiques et/ou ressource système. Deuxièmement, le protocole d'établissement de clé de session doit être efficace en termes de bande passante requise et de consommation énergétique, et en particulier du point de vue des calculs cryptographiques mis en œuvre. Ce deuxième critère est particulièrement important lorsque le protocole d'établissement de clé de session doit être mis en œuvre par des entités ne disposant que de faibles ressources énergétiques, telle une batterie, ou que d'une faible capacité de calcul et/ou de mémoire. Enfin, le protocole peut offrir des fonctionnalités supplémentaires, telles que l'interopérabilité des mécanismes d'authentification entre deux nœuds le mettant en œuvre ou la possibilité d'un contrôle centralisé sur l'échange des clés et/ou la possibilité d'une définition centralisée de politiques de sécurité accompagnant les clés établies. II s'est développé principalement trois approches pour établir des clés de session entre deux nœuds.
La première famille est le transport de clé, connu sous l'anglicisme
"key transport" qui consiste à transporter de manière sécurisée par encryption, une ou plusieurs valeurs secrètes depuis un des deux participants d'une session jusqu'à l'autre. Ces transports de valeurs secrètes peuvent soit s'effectuer dans une seule direction et ce mode est connu selon l'anglicisme "one-pass key transport protocol" soit s'effectuer dans les deux directions, et ce mode est connu alors sous l'anglicisme "two-pass key transport protocol". La clé de session est ensuite dérivée à partir de ces valeurs secrètes.
La deuxième famille de solutions d'établissement de clés de session est l'agrément de clé, connu sous l'anglicisme "key agreement". Cette approche consiste en un échange de valeurs publiques entre les deux nœuds à partir desquelles une clé de session commune est recouvrée par les deux entités participant à l'échange sans que les valeurs publiques échangées n'aient à être déchiffrées. Le principal protocole connu de « key agreement » est le protocole Diffie-Hellman. Sur le plan des ressources consommées, principalement au niveau de l'énergie consommée en opérations cryptographiques, le « key agreement » est une approche coûteuse.
Une troisième famille de solutions d'établissement de clé de session est la distribution de clé, connu sous l'anglicisme "key distribution". Dans cette approche, une troisième entité souvent nommée « tiers de confiance » intervient pour fournir aux deux autres participants soit une valeur secrète qui leur permet de calculer la clé de session, soit la clé de session elle-même. Cependant, la distribution de clé fait également intervenir des échanges directs entre les deux participants. En effet, ceux-ci doivent faire la preuve de leur implication dans le protocole, établir la fraîcheur des messages qu'ils envoient et prouver leur connaissance du secret établi. La distribution de clé bien qu'étant une solution simple à mettre en œuvre, légère en termes d'opérations cryptographiques requises et d'énergie consommée, présente des inconvénients non encore résolus par les solutions existantes.
Des solutions de 'distribution de clé' bien connues sont celles de Needham et Schroeder, ou bien le protocole Kerberos ou encore l'approche MIKEY-Ticket. Le protocole de transport de clés de Needham et Schroeder, présenté dans le document « Using encryption for authentication in large networks of computers », Communication of the ACM, volume 21 , number 12, 1978 contient cinq échanges de messages entre deux entités, un initiateur (I) et un répondeur (R) qui partagent, chacun, une clé de chiffrement avec un tiers de confiance (TC). L'échange des cinq messages est représenté sur la figure 1 . Un des problèmes majeurs du protocole de Needham et Schroeder est une attaque par usurpation d'identité par un attaquant se faisant passer pour l'initiateur et rejouant le troisième message (Message3) entre l'initiateur et le répondeur. L'attaquant, qui peut connaître la clé générée par le tiers de confiance, peut alors déchiffrer le quatrième message et usurper la session en envoyant le dernier message.
Le protocole normalisé Kerberos décrit dans le document de Kohi et Neuman « The Kerberos network authentication service », septembre 1993, est illustré sur la figure 2 et se base sur l'échange de quatre messages. Les deux premiers messages sont échangés entre l'initiateur et le tiers de confiance. Les deux derniers messages sont échangés entre l'initiateur et le répondeur. Un inconvénient du protocole Kerberos est qu'il n'est pas symétrique vis-à-vis de l'initiateur et du récepteur. Le tiers de confiance n'a aucune assurance que le récepteur a bien été contacté ou a bien accepté de participer à la transaction sécurisée. De fait, le protocole Kerberos est limité dans ses applications et plutôt destiné à permettre l'accès depuis un client initiateur à une ressource supposée ne pas être sujette à des comportements malicieux, comme par exemple une imprimante ou un serveur de fichiers.
Une amélioration connue du protocole de Needham et Schroeder est le protocole d'Otway et Rees illustré en figure 3 et décrit dans le document des auteurs « Efficient and timely mutual authentication », 1987. Cependant, ce protocole présente toujours l'inconvénient que le tiers de confiance n'a d'interaction directe qu'avec un seul des deux participants, ici le répondeur.
Le brevet WO 2009/070075 A1 de Blom et al. Intitulé « Key management for secure communication » présente un procédé pour établir des clés de session pour des communications sécurisées entre deux entités. Le procédé s'appuie sur le protocole de distribution de clés MIKEY-Ticket spécifié dans la RFC 6043 de Mattsson et Tian, « MIKET-Ticket : Ticket-based modes of key distribution in Multimedia Internet KEYing (MIKEY) ». La gestion de clés est basée sur un service de confiance de gestion de clés centralisé où l'initiateur et le répondeur partagent chacun une clé commune avec un tiers de confiance.
Or de par son design, ce protocole peut être la cible d'attaques par déni de service. L'homme du métier connaît les différentes formes des attaques par déni de service. Un attaquant peut réaliser un déni de service en exploitant les erreurs d'implémentations dans les protocoles de communication, par exemple, si le protocole utilisé est implémenté de façon à bloquer les nœuds lorsqu'ils reçoivent des données inconnues. Un attaquant pourra alors faire une attaque par déni de services en envoyant des messages contenant des champs erronés au répondeur, sa cible. Une autre manière de réaliser un déni de service est d'entamer une communication avec la cible puis d'arrêter l'envoi de messages aux fins de bloquer la cible dans un état d'attente d'acquittement et de saturer sa pile de réception. Enfin, le déni de service peut être distribué en utilisant plusieurs attaquants au même temps aux fins de saturer la cible le plus rapidement possible et de complexifier le retraçage de l'attaquant.
Ainsi, les approches connues bien qu'offrant des solutions alternatives pour établir des clés de session, de par leurs inconvénients ne répondent pas à l'ensemble des besoins de sécurité attendus pour un protocole d'établissement de clés de session.
L'invention proposée permet de répondre à ces besoins. Résumé de l'invention
Un objet de la présente invention est de proposer un procédé d'établissement de clés de session sûr et protégé contre les attaques par déni de service.
Avantageusement, l'invention offre autant à un nœud initiateur qu'à un nœud répondeur, une protection contre les attaques par déni de service.
Un autre objet de la présente invention est de proposer un procédé d'établissement de clés de session efficace en termes de ressources consommées. Ainsi le procédé de l'invention permet l'établissement d'une session en quatre ou cinq échanges de messages et s'appuie sur l'utilisation de primitives cryptographiques symétriques.
Avantageusement, la présente invention s'implémentera dans les domaines de la sécurité des communications machine-à-machine (M2M), ou dans le contexte des réseaux de nœuds contraints en ressources comme ceux de capteurs et/ou actionneurs, qui sont parmi les nœuds les plus contraints en ressources et pouvant être amenés à devoir établir dynamiquement des clés de session.
Pour obtenir les résultats recherchés, un procédé, un dispositif et un produit programme d'ordinateur sont proposés. En particulier, dans un réseau de communication comprenant une pluralité d'entités communicantes, un procédé pour établir une clé de session entre une entité source (I) et une entité cible ( R), l'entité source partageant avec une entité de confiance tierce (TC) une première clé source K|e pour le chiffrement de données et une deuxième clé source K|a pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le procédé comprend les étapes de:
recevoir à l'entité de confiance tierce, un message de l'entité source pour rétablissement d'une session avec l'entité cible, le message contenant au moins des identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé source K|a ;
générer une paire K|R de clés (K|Ra , K|Re) pour l'entité source et pour l'entité cible ;
encrypter la paire K!R de clés (K|Ra , K|Re) par la première clé source Κ|θ et par la première clé cible KRe;
envoyer à l'entité cible un message contenant au moins la clé K|R encryptée et un code d'authentification basé sur la deuxième clé cible KRa;
recevoir de l'entité cible, un message contenant au moins les identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé cible KRa ; et envoyer à l'entité source, un message contenant au moins la clé K|R encryptée et un code d'authentification basé sur la deuxième clé source
Kia-
Avantageusement, la clé source K!e pour le chiffrement de données et la clé source K|a pour le code d'authentification sont dérivées d'une clé initiale obtenue après une étape d'authentification de l'entité cible auprès de l'entité de confiance tierce.
Dans une variante, le message reçu de l'entité source comprend de plus un nonce source (Ni) pour prouver la fraîcheur du message de l'entité source. Dans une autre variante, l'étape de générer la clé K|Ra pour l'entité source comprend les étapes de concaténer la clé K|Ra aux identifiants de l'entité cible, de l'entité de confiance tierce, et du nonce NI, et de chiffrer l'ensemble concaténé avec la première clé cible KRe.
Avantageusement, le message envoyé à l'entité cible comprend de plus le nonce (Ni) et le code d'authentificatlon basé sur la deuxième clé cible KRa est calculé sur le nonce. Avantageusement, le message reçu de l'entité cible comprend de plus le nonce source (Ni) et un nonce cible (NR) pour prouver la fraîcheur du message cible.
Dans une variante d'implémentation, l'étape de calculer un code d'authentificatlon en utilisant la deuxième clé cible KRa, les identifiants, les nonces source et cible (Ni, NR) et le code d'authentificatlon reçu basé sur la deuxième clé cible KRa et l'étape de vérifier si le code d'authentificatlon calculé est égal au code d'authentificatlon reçu. Avantageusement, le message envoyé à l'entité source comprend de plus les nonces source et cible (Ni, NR).
Avantageusement, les identifiants des entités source et cible sont soit des adresses IPv6, des adresses MAC ou des URL.
Selon les variantes, le nonce est soit une information d'horodatage, un nombre aléatoire ou un compteur.
Dans une autre variante, le message envoyé par l'entité de confiance tierce à l'entité cible contient de plus une clé chiffrée par les clés K|e et K|a et où le message reçu de l'entité cible et le message envoyé à l 'entité source sont un seul message envoyé de l'entité cible à l'entité source.
Dans une autre variante, le procédé comprend de plus une étape d'envoyer un message de l'entité source à l'entité cible qui contient les identifiants de l'entité source et de l'entité cible, les nonces source et cible (Ni, NR) et un code d'authentification calculé avec la clé K|Ra partagée entre l'entité source et l'entité cible. L'invention concerne de plus un système pour établir une clé de session entre une entité source et une entité cible, l'entité source partageant avec une entité de confiance tierce une première clé source K|e pour le chiffrement de données et une deuxième clé source K|a pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le système comprenant des moyens pour mettre en œuvre toutes les étapes du procédé revendiqué.
L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer les étapes du procédé revendiqué lorsque le programme est exécuté sur un ordinateur.
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 illustre les échanges de messages selon le procédé de Needham et Schroeder ; La figure 2 illustre les échanges de messages selon le procédé de
Kerberos ;
La figure 3 illustre les échanges de messages selon le procédé d'Otway et Rees ;
La figure 4 est une représentation topologique d'une infrastructure réseau dans laquelle implémenter avantageusement l'invention ;
La figure 5 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 4 selon le procédé de MIKEY-Ticket;
La figure 6 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 4 dans une implémentation avantageuse de l'invention ;
La figure 7 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 1 dans une variante d'implémentation de l'invention.
Description détaillée de l'invention La figure 4 illustre un exemple d'une infrastructure de communication 100 dans laquelle implémenter avantageusement l'invention. Pour des raisons de simplicité de description et non de limitation de l'invention, l'exemple de la figure 4 ne montre qu'un nombre fini d'entités (ou nœuds) 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 de communication (1 00) comprend des entités fixes ou mobiles pouvant former un réseau d'objets (102). Les entités peuvent être à fortes contraintes de ressources (102-1 , 102-n) ou à moindre contrainte de ressources (1 12-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 de noeuds (102) peut être basé sur des communications de niveau 2 (par exemple, 802.1 5.4 ou 802.11 ) et/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.
La présente invention peut être avantageusement appliquée dans l'environnement de la figure 4 entre deux nœuds du réseau, une entité source que l'on dénomme 'initiateur' et une entité cible que l'on dénomme 'répondeur'. Les deux entités ont besoin d'établir une association de sécurité entre elles. Un serveur central de distribution de clés (106) que l'on dénomme tiers de confiance est responsable de l'authentification des nœuds. Il peut être distant et accessible via un réseau de communication tierce (104) qui peut être un réseau cellulaire ou le réseau Internet. Le tiers de confiance stocke des données cryptographiques nécessaires pour l'authentification de chacun des nœuds.
En opération, chaque nœud initiateur et répondeur s'authentifie auprès du serveur central en utilisant ses crédentiels propres, des modèles d'identités et des méthodes d'authentification indépendantes les plus en accord avec chacun leurs propres spécificités et contraintes. Ainsi, deux nœuds peuvent par exemple établir une clé de session et l'associer à leurs identités respectives alors que ces dernières sont respectivement validées au moyen d'une carte à puce pour l'un et d'une authentification biométrique pour l'autre. Le serveur de confiance distribue une même clé de session à deux nœuds souhaitant établir entre eux une association de sécurité, permettant des authentifications décorrélées pour chaque nœud, ainsi qu'un contrôle centralisé sur l'établissement de clés et/ou sur les politiques qui accompagnent ces dernières.
La figure 5 montre les procédures exécutées selon le protocole connu de Mikey- Ticket entre un nœud initiateur (I), un nœud répondeur (R) et un tiers de confiance (TC) du réseau de la figure 4.
Pour faciliter la compréhension de l'invention, des notations identiques sont utilisées pour décrire les figures suivantes 5 à 7. Ainsi, par la suite : Datai, Data2, ... etc désignent respectivement la concaténation des données dans les messages 1 , 2, ... etc. L'homme du métier appréciera que la présente invention ne se limite pas à l'ordre indiqué à titre d'exemple dans la description des messages pour les données concaténées. Ainsi, pour un même message, les transmissions des mêmes données sous la forme (Datai , Data2) et (Data2, Datai) sont équivalentes.
E{K, (Datai , Data2, ...)} désigne le chiffrement des données concaténées (Datai, Data2, ...) avec un algorithme de chiffrement utilisant une clé K.
MAC{K, (Datai , Data2, ...)} désigne le code d'authentification de message « Message Authentication Code » (MAC) sur les données concaténées (Datai , Data2, ...) en utilisant une clé K. Comme il a été expliqué précédemment, le protocole MIKEY-Ticket a été défini pour étendre le protocole MIKEY par l'utilisation d'un tiers de confiance et se base sur l'échange de six messages entre les trois entités initiateur (I), répondeur (R) et tiers de confiance (TC).
Un noeud initiateur envoie au tiers de confiance, un premier message sous forme d'une requête d'initialisation « Request_init ». La requête contient un code d'authentification MAC qui est calculé avec sa clé « Kia ». A la réception de ce premier message, TC vérifie la validité du MAC et l'authenticité des données (Datai) envoyées par l'initiateur. Ces données contiennent principalement un identifiant du nœud répondeur avec lequel le nœud initiateur veut établir une session, un nonce et des informations sur les algorithmes de chiffrement et de calcul de MAC supportés par l'initiateur.
Le tiers de confiance génère une clé « KIR » et la transmet à l'initiateur dans un message de réponse « Request_resp ». La clé K|R est chiffrée par la clé de chiffrement « Kie » de l'initiateur. Le deuxième message contient de plus un ticket « Ticketi » pour l'initiateur et un MAC calculé avec la clé K!a.
A la réception du message, l'initiateur vérifie la validité du MAC et récupère sa clé K!R qui va lui permettre de dériver avec le répondeur deux clés « KiRa >> et « K|Re ». La clé K|Ra servira à calculer des MACs alors que la clé KiRe permettra d'encrypter des données.
L'initiateur envoie ensuite au répondeur un message « Transfert_init » qui contient son ticket « Ticketi ». Ce troisième message contient un MAC calculé avec la clé K|Ra.
Il est à noter qu'à ce niveau de l'exécution du protocole, le nœud répondeur (R) n'a pas encore reçu la clé K|R et donc pas reçu les clés K|Ra et K|Re. Par conséquent, (R) ne peut pas vérifier la validité du MAC qu'il vient de recevoir du nœud initiateur, et doit envoyer au tiers de confiance (TC) un message « Resolve_init » pour lui demander de lui communiquer A la réception du quatrième message, le tiers de confiance vérifie la validité du MAC du répondeur en utilisant la clé KRa. Si le MAC est valide, il envoie au répondeur la clé K!R chiffrée par la clé KRe , dans un cinquième message « Resolve_resp » .
A la réception du cinquième message, le répondeur vérifie le MAC calculé par le tiers de confiance et récupère la clé K|R. Une fois la clé K|R reçue, le répondeur calcule la clé K|Ra et vérifie la valeur du MAC calculé par l'initiateur dans le troisième message « Transfert_init ». Si la valeur du MAC est valide, le répondeur envoie un sixième message « Transfert_resp » à l'initiateur pour accuser de la bonne réception de la clé KIR.
Ainsi, comme il a déjà été discuté précédemment, le nœud répondeur ne vérifie le MAC envoyé par l'initiateur dans le troisième message, qu'après avoir échangé les quatrième et cinquième messages avec le tiers de confiance, il peut alors être la cible d'attaque par déni de service. Un nœud attaquant peut bombarder le nœud répondeur avec un nombre illimité de messages de type « Transfe nit » (troisième message) pour l'obliger à calculer un grand nombre de message « Resolve_init » (quatrième message) et ainsi épuiser toutes les ressources énergétiques et calculatoires du nœud répondeur. La figure 6 montre les procédures exécutées entre des entités
Initiateur (I), Répondeur (R) et Tiers de Confiance (TC) du réseau de la figure 4 dans une implémentation avantageuse de l'invention.
Un bénéfice important de l'invention réside dans l'efficacité énergétique du procédé mis en œuvre qui est obtenue au moyen d'un nombre de messages échangés réduits. Le procédé proposé permet d'établir une communication sécurisée entre un nœud initiateur et un nœud répondeur en cinq échanges de messages dans l'implémentation de la figure 6, ou en quatre échanges de message selon l'implémentation de la figure 7. Il est à noter que le dernier message décrit pour les deux exemples est échangé entre l'initiateur et le répondeur et correspond à une confirmation de clé par l'initiateur qui peut être implicite. L'échange sécurisé des données entre l'initiateur et le répondeur pouvant commencer respectivement après le quatrième et le troisième message des figures 6 et 7.
L'homme de l'art appréciera que les échanges de messages donnent des rôles équivalents au nœud initiateur (I) et au nœud récepteur (R) vis à vis du tiers de confiance (TC). En effet, les interactions sont du type (l)e (TC), (TC)el(l), (R)tt(TC) et (TC)âl(R) et offrent ainsi au tiers de confiance un meilleur contrôle de l'établissement de clé de session.
L'implémentation illustrée par la figure 6 peut être avantageusement appliquée lors de l'établissement d'une communication sécurisée entre deux nœuds qui ne partagent aucun secret directement, mais qui partagent, chacun, un ou plusieurs secrets avec un tiers de confiance (TC). Le tiers de confiance et l'initiateur partagent initialement deux clés (K|e, K|a) où K|e est une clé utilisée pour le chiffrement des données, et où K|a est une clé utilisée pour calculer un code d'authentification de message (MAC). K!e et K!a peuvent être dérivées d'une clé maîtresse à la suite d'une authentification de l'initiateur avec le tiers de confiance. De son coté, le répondeur (R) partage également une paire de clé (KRe, KRa) avec le tiers de confiance.
L'homme de l'art comprendra que par souci de simplification de la description de la variante de la figure 6, l'initiateur et le répondeur désignent chacun une entité simple, mais que dans un cas plus général, il peut s'agir d'un groupe de noeuds initiateurs et/ou un groupe de nœuds répondeurs utilisant des clés individuelles et/ou des clés de groupe.
Afin d'établir un canal de communication sécurisé avec le répondeur (R), l'initiateur (I) contacte le tiers de confiance (TC) pour qu'il leur crée une ou plusieurs clés. Pour simplifier la description du protocole, dans la variante de la figure 6, le tiers de confiance génère une seule clé KIR pour les deux nœuds (I) et (R). Puis, le tiers de confiance envoie la clé KIR encryptée avec la clé K|E à l'initiateur et envoie la clé KIR encryptée avec la clé KRE au répondeur. L'intégrité des messages échangés est assurée par l'ajout de MACs, respectivement calculés au moyen des clés Kia et KRA.
De manière plus détaillée en référence à la figure 6, l'initiateur démarre le procédé en envoyant un premier message « Messagel » au tiers de confiance. Ce message contient les identifiants de l'initiateur (IDi), du tiers de confiance (I DTc) et du répondeur (IDR). Il contient aussi un nonce (Ni) qui sert à prouver la fraîcheur de la session et à éviter les attaques par rejeu. De plus, l'initiateur rajoute au messagel un MAC (MACn) calculé sur (ID,, I DTc, IDR et N,) avec la clé K!a. Le MAC permet de prouver au tiers de confiance l'authenticité des données reçues dans le premier message.
Les identifiants (ID|,IDTc, IDR) peuvent dépendre de la technologie utilisée et du type de réseau déployé. Ces identifiants peuvent être, par exemple, des adresses IPv6, des adresses MAC ou des URL. Dans le cas particulier des réseaux I P, les identifiants ID| et I DTc peuvent correspondre respectivement à l'adresse source et à l'adresse destination du paquet I P.
Le nonce peut être une information d'horodatage, un nombre aléatoire ou un compteur (numéro de séquence). Ce doit être une information variable et unique dans le temps qui permet de distinguer les différentes exécutions du protocole connu de Menezes, Van Oorschot et Vanstone, décrit dans le document « Handbook of applied cryptography » , chapitre 10. Le nonce peut être aussi formé par la combinaison des techniques citées précédemment. Par exemple, un nonce peut être formé par une information d'horodatage et d'un nombre aléatoire.
A la réception du premier message, le tiers de confiance vérifie la fraîcheur du nonce Ni et utilise la clé K!a pour calculer le MAC (MACTci) sur (ID|, I DJC, I DR et Ni). Ensuite, il vérifie l'égalité entre le MACn reçu de l'initiateur et son propre MAC (MACTci) afin de vérifier l'intégrité du message reçu. Si les deux valeurs sont égales, le tiers de confiance va générer un deuxième message « Message2 » pour l'envoyer au récepteur. Le tiers de confiance commence par générer une clé K|R pour l'initiateur et le répondeur. Puis il envoie au répondeur cette clé K|R chiffrée par la clé de chiffrement KRe. Le message envoyé au répondeur contient de plus un MAC (MACTC2) qui permet au répondeur de vérifier l'intégrité des données reçues.
Dans une implémentation préférentielle, le tiers de confiance concatène la clé K|R aux identifiants I D| et IDTc, et le nonce N| avant de chiffrer le tout avec la clé KRe pour obtenir un chiffrement E{KRe, (K|R,IDTc, ID|,N|)}. Ce deuxième message contient aussi les identifiants (IDi, I DTC, I DR), le nonce N, et le MAC (MACTC2). Le MAC (MACTC2) est calculé avec la clé KRa sur les champs suivants : IDTc, I DR, I DI, N I, et E{KRe, (K|R,I DTC,ID|,N|)}.
A la réception du deuxième message, le répondeur vérifie l'égalité entre le MACTc2 reçu et sa propre valeur de MAC (MACR2) qu'il calcule en utilisant la clé KRA. Si la valeur de MACTC2 est bonne, le répondeur déchiffre le contenu de E{KRe, (K|R, IDTc,I D|, N|)} pour récupérer la clé K|R.
Le répondeur génère un nonce (NR) et calcule un MAC (MACR|) avec la clé KIR sur les données d'identifiants (I DR, I DTC, I DI) et de nonce (Ni, N R). Le MAC (MACRI) sera transmis par le tiers de confiance à l'initiateur pour lui permettre de vérifier que le répondeur a bien reçu la
Dans une première variante, le répondeur utilise les nonces (Ni, NR) et la clé K!R comme entrées à une fonction pseudo-aléatoire pour générer deux clés « K|Ra » et « K|Re ». La clé K|Ra est utilisée pour calculer les MACs, la clé KiRe sert à chiffrer les données entre l'initiateur et le répondeur.
Dans une deuxième variante, le tiers de confiance génère deux clés, « K|Ra » et « K|Re » pour l'initiateur et le répondeur. Ces clés seront envoyés par le tiers de confiance à l'initiateur et le répondeur et serviront respectivement à calculer des MACs et à chiffrer les données.
Pour simplifier les notations, la notation K|R est par la suite utilisée pour désigner à la fois la clé servant à calculer les MACs et pour le chiffrement, indépendamment des méthodes qui ont permis de générer les clés K|Ra et K|Re.
Le répondeur génère un troisième message « Message3 » pour le tiers de confiance. Le message contient les identifiants (I DR) et (I DTc), les nonces (NR) et (N,), le MACR| et un nouveau MAC ( MACR3), calculé avec la clé KRa sur toutes les données précédentes.
A la réception du troisième message, le tiers de confiance vérifie la fraîcheur du nonce NR et calcule le MACTc3 en utilisant la clé KRa et les données d'identifiants (I DR, I DTc), de nonces (NR, Ni) et de MAC (MACRI).
Le tiers de confiance vérifie ensuite que le MACTc3 calculé est bien égal au MACR3 reçu du récepteur. Si la valeur du MACTc3 reçu est valide, le tiers de confiance génère un message « Message4 » à destination de l'initiateur. Le quatrième message contient les nonces NR et N|, le MACIR et la clé K!R chiffrée par la clé K!e.
Dans une implémentation préférentielle, la clé KIR est concaténée aux identifiants du répondeur IDR et du tiers de confiance IDTc, et aux nonces Ni et NR avant d'être chiffrée avec la clé K|e en un chiffrement
E{K|e, (K|R, I DR, I DTC, N|, NR)}) .
Le message envoyé par le tiers de confiance à l'initiateur contient de plus un MAC (MACTc4) calculé avec la clé K!a qui permet à l'initiateur de vérifier l'intégrité des données reçues.
A la réception du quatrième message, l'initiateur calcule son MAC (MAC|4) avec sa clé K|a puis le compare au MAC (MACTc4) envoyé par le tiers de confiance. Si les deux MAC sont égaux, l'initiateur déchiffre le contenu de E{K|e, (K|R, IDR,IDTc,N|,NR)} avec sa clé K|e pour récupérer la clé KIR.
Ensuite, l'initiateur utilise la clé K|R pour vérifier la valeur du MAC (MACRI) qui a été calculée et envoyée par le récepteur dans le troisième message. A cet effet, l'initiateur calcule localement un MAC (MACIR) sur les mêmes champs que ceux qui ont été utilisés par le récepteur lors du calcul du (MACRI), à savoir les identifiants (IDR, I DTc, I D|) et les nonces (Ni, NR). Puis, l'initiateur compare s'il y a égalité entre son MACIR et le MAC™. Si les deux MAC sont égaux, cela signifie que le répondeur a bien reçu la clé K|R de la part du tiers de confiance. Pour acquitter la bonne réception du quatrième message, l'initiateur génère un message « Message5 » à destination du répondeur.
L'initiateur envoie directement au répondeur le cinquième message 5 qui contient les identifiants respectifs de l'initiateur et du répondeur (I Di et I DR), leurs nonces (N|, NR) et un MAC (MAC|5) calculé avec la clé K|R.
A la réception du cinquième message, le répondeur vérifie la valeur du MAC reçu (MAC|5) en calculant son propre MAC (MACR5). Si les deux MAC sont égaux, le répondeur R conclut que l'initiateur a bien reçu la clé KIR de la part du tiers de confiance. La figure 7 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 4 dans une variante d'implémentation de l'invention consistant en quatre messages échangés.
L'initiateur démarre le procédé en envoyant un premier message « Messagel » au tiers de confiance. Le contenu du premier message est identique à celui décrit en référence à la figure 6.
Après la réception du Messagel , le tiers de confiance TC génère un nonce (NTc), ainsi que la clé K|R pour l'initiateur et le répondeur. Le nonce NTc est un paramètre optionnel qui permet de rajouter de la fraîcheur au deuxième message dans le cas où le répondeur associe la fraîcheur du message à la réception d'un nouveau nonce de l'initiateur mais aussi du tiers de confiance.
L'ajout du nonce (NTc) peut se décider lors de l'établissement de la politique de sécurité par l'administrateur du réseau.
Le tiers de confiance chiffre, avec la clé KRE, le nonce, la clé KIR, et cette même clé K|R chiffrée et protégée en intégrité par les clés K|e et K!a partagées avec l'initiateur. Le chiffré est envoyé dans un deuxième message « Message2bis » au répondeur. Le message contient de plus un MAC calculé avec la clé KRa, pour permettre au répondeur de vérifier l'intégrité des données reçues.
Après la réception du deuxième message, le répondeur vérifie l'intégrité et l'authenticité du message reçu en utilisant sa clé KRa. Si le résultat de la vérification est positif, le répondeur déchiffre le message pour récupérer la clé partagée K|R.
Ensuite, le répondeur génère un nonce (NR) puis envoie dans un troisième message « Message3bis », les données reçues du tiers de confiance dans le deuxième message TC et contenant la clé K|R chiffrée et authentifiée avec les clés K|e et K|a partagées entre le tiers de confiance et l'initiateur. Pour permettre à l'initiateur de vérifier que le répondeur a bien reçu la clé partagée KIR, le répondeur envoie aussi un MAC calculé avec cette clé KIR.
A la réception du troisième message, l'initiateur vérifie l'intégrité de la première partie du message générée par le tiers de confiance en utilisant la clé K|A. Si la vérification est réussie, l'initiateur récupère la clé partagée K!R en utilisant sa clé K!E. Puis, il vérifie le MAC envoyé par le répondeur en utilisant la clé K|R.
L'initiateur envoie ensuite directement au répondeur un quatrième message qui contient les identifiants de l'initiateur et du répondeur (ID|, IDR), leurs nonces (N|, NR) et un MAC (MAC|5) calculé avec la clé K|R.
A la réception du quatrième message, le répondeur vérifie la valeur du MAC|5 reçu en calculant son propre MACR5. Si les deux MAC sont égaux, le répondeur conclut que l'initiateur a bien reçu la clé K|R de la part du tiers de confiance.
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, les exemples décrits sont basés sur un protocole préférentiel mais il est possible d'utiliser d'autres protocoles d'authentification.
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 tels 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).

Claims

Revendications
Dans un réseau de communication comprenant une pluralité d'entités communicantes, un procédé pour établir une clé de session entre une entité source (I) et une entité cible ( R), l'entité source partageant avec une entité de confiance tierce (TC) une première clé source K|e pour le chiffrement de données et une deuxième clé source K!a pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le procédé comprenant les étapes de:
- recevoir (602) à l'entité de confiance tierce, un message de l'entité source pour l'établissement d'une session avec l'entité cible, le message contenant au moins des identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé source K!a ;
- générer (604) une paire KIR de clés (KRa , K|RE) pour l'entité source et pour l'entité cible ;
- encrypter (604) la paire K|R de clés (K|RA , K|RE) par la première clé source Ke et par la première clé cible KRE;
- envoyer (606) à l'entité cible un message contenant au moins la clé KIR encryptée et un code d'authentification basé sur la deuxième clé cible KRA ;
- recevoir (608) de l'entité cible, un message contenant au moins les identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé cible KRA ; et envoyer (61 0) à l'entité source, un message contenant au moins la clé KIR encryptée et un code d'authentification basé sur la deuxième clé source K!A.
2. Le procédé selon la revendication 1 dans lequel la clé source K|e pour le chiffrement de données et la clé source K!a pour le code d'authentification sont dérivées d'une clé initiale obtenue après une étape d'authentification de l'entité cible auprès de l'entité de confiance tierce.
3. Le procédé selon la revendication 1 ou 2 dans lequel le message reçu de l'entité source comprend de plus un nonce source (N|) pour prouver la fraîcheur du message de l'entité source.
4. Le procédé selon la revendication 3 dans lequel l'étape de générer la clé KiRa pour l'entité source comprend les étapes de concaténer la clé K|Ra aux identifiants de l'entité cible, de l'entité de confiance tierce, et du nonce Ni, et de chiffrer l'ensemble concaténé avec la première clé cible KRe .
Le procédé selon la revendication 4 dans lequel le message envoyé à l'entité cible comprend de plus le nonce (Ni) et le code d'authentification basé sur la deuxième clé cible KR3 est calculé sur le nonce.
Le procédé selon la revendication 5 dans lequel le message reçu de l'entité cible comprend de plus le nonce source (Ni) et un nonce cible (NR) pour prouver la fraîcheur du message cible.
Le procédé selon la revendication 6 comprenant une étape de calculer un code d'authentification en utilisant la deuxième clé cible Kra, les identifiants, les nonces source et cible (Ni, NR) et le code d'authentification reçu basé sur la deuxième clé cible KRa et une étape de vérifier si le code d'authentification calculé est égal au code d'authentification reçu.
8. Le procédé selon la revendication 7 dans lequel le message envoyé à l'entité source comprend de plus les nonces source et cible (Ni, NR).
9. Le procédé selon l'une quelconque des revendications 1 à 8 dans lequel les identifiants des entités source et cible sont soit des adresses IPv6, des adresses MAC ou des URL.
10. Le procédé selon l'une quelconque des revendications 3 à 9 dans lequel le nonce est soit une information d'horodatage, un nombre aléatoire ou un compteur.
1 1 .Le procédé selon l'une quelconque des revendications 1 à 10 dans lequel le message envoyé (706) à l'entité cible contient de plus une clé chiffrée par les clés K!e et K!a et où le message reçu de l'entité cible et le message envoyé à l'entité source sont un seul message (708) envoyé de l'entité cible à l'entité source.
12. Le procédé selon l'une quelconque des revendications 6 à 11 comprenant de plus l'étape d'envoyer (612) un message de l'entité source à l'entité cible qui contient les identifiants de l'entité source et de l'entité cible, les nonces source et cible (Ni, NR) et un code d'authentification calculé avec la paire de clés pour l'entité source et l'entité cible.
13. Un système pour établir une clé de session entre une entité source et une entité cible, l'entité source partageant avec une entité de confiance tierce une première clé source Κ|θ pour le chiffrement de données et une deuxième clé source K!a pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le système comprenant des moyens pour mettre en œuvre les étapes du procédé selon l'une quelconque des revendications 1 à 12.
14. Le système selon la revendication 13 où l'entité source est un groupe de nœuds sources et/ou l'entité cible est un groupe de nœuds cibles utilisant des clés individuelles et/ou des clés de groupe.
15. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur.
PCT/EP2014/054791 2013-03-28 2014-03-12 Procede et dispositif d'etablissement de cles de session WO2014154482A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP14709651.5A EP2979390A1 (fr) 2013-03-28 2014-03-12 Procede et dispositif d'etablissement de cles de session
US14/779,487 US9787651B2 (en) 2013-03-28 2014-03-12 Method and device for establishing session keys
CN201480018723.2A CN105075175A (zh) 2013-03-28 2014-03-12 用于建立会话密钥的方法和设备
JP2016504550A JP2016514913A (ja) 2013-03-28 2014-03-12 セッション鍵を確立する方法および装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1352812 2013-03-28
FR1352812A FR3004041B1 (fr) 2013-03-28 2013-03-28 Procede et dispositif d'etablissement de cles de session

Publications (1)

Publication Number Publication Date
WO2014154482A1 true WO2014154482A1 (fr) 2014-10-02

Family

ID=49231587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/054791 WO2014154482A1 (fr) 2013-03-28 2014-03-12 Procede et dispositif d'etablissement de cles de session

Country Status (6)

Country Link
US (1) US9787651B2 (fr)
EP (1) EP2979390A1 (fr)
JP (1) JP2016514913A (fr)
CN (1) CN105075175A (fr)
FR (1) FR3004041B1 (fr)
WO (1) WO2014154482A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3213488A1 (fr) * 2014-10-31 2017-09-06 Convida Wireless, LLC Authentification de couche de service de bout en bout
EP3248325A1 (fr) * 2015-01-22 2017-11-29 Entit Software LLC Répertoire de clés de session
KR102001753B1 (ko) 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증
CN106452770B (zh) * 2015-08-12 2020-10-13 深圳市腾讯计算机系统有限公司 一种数据加密方法、解密方法、装置和系统
ES2901207T3 (es) * 2017-03-02 2022-03-21 Actility Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación
WO2020000428A1 (fr) * 2018-06-29 2020-01-02 Nokia Shanghai Bell Co., Ltd. Procédés, dispositifs et support lisible par ordinateur de gestion de clés
WO2020093212A1 (fr) * 2018-11-05 2020-05-14 华北电力大学扬中智能电气研究中心 Système et procédé de transmission de données vidéo et dispositif associé
CN110086627B (zh) * 2019-04-22 2023-08-04 如般量子科技有限公司 基于非对称密钥池对和时间戳的量子通信服务站密钥协商方法和系统
CN114553412B (zh) * 2022-02-28 2024-02-23 百果园技术(新加坡)有限公司 一种数据传输方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060053289A1 (en) * 2004-09-09 2006-03-09 International Business Machines Corporation Peer-to-peer communications
US20120191971A1 (en) * 2009-09-30 2012-07-26 France Telecom Method and devices for secure communications in a telecommunications network

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7864731B2 (en) * 2006-01-04 2011-01-04 Nokia Corporation Secure distributed handover signaling
US9178696B2 (en) 2007-11-30 2015-11-03 Telefonaktiebolaget L M Ericsson (Publ) Key management for secure communication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060053289A1 (en) * 2004-09-09 2006-03-09 International Business Machines Corporation Peer-to-peer communications
US20120191971A1 (en) * 2009-09-30 2012-07-26 France Telecom Method and devices for secure communications in a telecommunications network

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
COLIN BOYD: "A Class of Flexible and Efficient Key Management Protocols", 10 June 1996 (1996-06-10) - 12 June 1996 (1996-06-12), Brisbane, Australia, pages 2 - 8, XP002719218, ISSN: 1063-6900, ISBN: 0-8186-7522-5, Retrieved from the Internet <URL:http://dx.doi.org/10.1109/CSFW.1996.503685> [retrieved on 20140123], DOI: 10.1109/CSFW.1996.503685 *
KALVINDER SINGH ET AL: "A Minimal Protocol for Authenticated Key Distribution in Wireless Sensor Networks", INTELLIGENT SENSING AND INFORMATION PROCESSING, 2006. ICISIP 2006. FOU RTH INTERNATIONAL CONFERENCE ON, IEEE, PI, 1 December 2006 (2006-12-01), pages 78 - 83, XP031124309, ISBN: 978-1-4244-0611-1 *
See also references of EP2979390A1 *

Also Published As

Publication number Publication date
CN105075175A (zh) 2015-11-18
US20160044007A1 (en) 2016-02-11
US9787651B2 (en) 2017-10-10
FR3004041B1 (fr) 2015-04-17
FR3004041A1 (fr) 2014-10-03
EP2979390A1 (fr) 2016-02-03
JP2016514913A (ja) 2016-05-23

Similar Documents

Publication Publication Date Title
WO2014154482A1 (fr) Procede et dispositif d&#39;etablissement de cles de session
FR2988942A1 (fr) Methode et systeme d&#39;etablissement d&#39;une cle de session
Kalra et al. Secure authentication scheme for IoT and cloud servers
EP3506556B1 (fr) Méthode d&#39;échange de clés authentifié par chaine de blocs
Mahalle et al. Identity establishment and capability based access control (iecac) scheme for internet of things
WO2013160140A1 (fr) Methode et systeme d&#39; authentification des noeuds d&#39;un reseau
EP3174241B1 (fr) Méthode d&#39;établissement d&#39;une communication sécurisée de bout en bout entre le terminal d&#39;un utilisateur et un objet connecté
EP2484084B1 (fr) Procédé et dispositifs de communications securisées contre les attaques par innondation et denis de service (dos) dans un réseau de télécommunications
US20100306542A1 (en) Password-authenticated asymmetric key exchange
Saied et al. A distributed approach for secure M2M communications
US20220029969A1 (en) Method and Apparatus for Effecting a Data-Based Activity
EP2865128A1 (fr) Dispositif et procede pour generer une cle de session entre des entites a faibles ressources
Kumar et al. A lightweight signcryption method for perception layer in Internet-of-Things
CN113014379B (zh) 支持跨云域数据分享的三方认证和密钥协商方法、系统和计算机存储介质
EP2186252B1 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
EP2294850A1 (fr) Procede pour securiser des echanges entre un noeud demandeur et un noeud destinataire
Chandrakar et al. Blockchain based security protocol for device to device secure communication in internet of things networks
Chung et al. DiscoverFriends: Secure social network communication in mobile ad hoc networks
Schliep et al. Consistent synchronous group off-the-record messaging with sym-gotr
Lin et al. Blockchain-Based Lightweight Certificateless Authenticated Key Agreement Protocol for V2V Communications in IoV
Babu et al. Trust-based permissioned blockchain network for identification and authentication of internet of smart devices: An e-commerce prospective
Durgam et al. Dynamic time assisted authentication protocol (DTAAP) for client-server in WSN-IoT environment
Kumar et al. LiSP: A lightweight signcryption using PHOTON hash for Internet-of-Things infrastructure
KR101190134B1 (ko) 인증을 위한 동적 그룹키 생성 방법
Karthik et al. Energy-Efficient Elliptic Curve Cryptography-Based DTLS Key Establishment Protocol for IoT Communication

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480018723.2

Country of ref document: CN

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

Ref document number: 14709651

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2014709651

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016504550

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14779487

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE