WO2017077211A1 - Communication entre deux éléments de sécurité insérés dans deux objets communicants - Google Patents

Communication entre deux éléments de sécurité insérés dans deux objets communicants Download PDF

Info

Publication number
WO2017077211A1
WO2017077211A1 PCT/FR2016/052713 FR2016052713W WO2017077211A1 WO 2017077211 A1 WO2017077211 A1 WO 2017077211A1 FR 2016052713 W FR2016052713 W FR 2016052713W WO 2017077211 A1 WO2017077211 A1 WO 2017077211A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
security element
encrypted
session
security
Prior art date
Application number
PCT/FR2016/052713
Other languages
English (en)
Inventor
Jean-Luc Grimault
Franck GRUPELI
Philip Michel
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2017077211A1 publication Critical patent/WO2017077211A1/fr

Links

Classifications

    • 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
    • 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
    • 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/0822—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) using key encryption key
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]

Definitions

  • the invention relates to a method of communication between two telecommunication objects. It also relates to a telecommunication object intended for implementing said method.
  • the invention applies to any communication object equipped with a security element. It finds a particularly advantageous application in the field of security of telecommunication services between objects, possibly portable, provided with a security element.
  • M2M machine-to-machine
  • Peer-to-Peer Peer-to-Peer
  • M2M machine-to-machine
  • Peer-to-Peer Peer-to-Peer
  • ZigBee based on the IEEE 802.15.4 standard, defines a set of high-level communications protocols that use low-power radio transmission. ZigBee proposes the use of a symmetric data encryption algorithm.
  • This type of security is however not generic: it remains linked to the radio technology used, in this case Zigbee. Moreover, this type of security is not nearly as high as that offered by a security element. But there are cases of use (in the fields of automobile, health, etc.) where it is necessary to ensure a high level of security.
  • a communication module for example ZigBee, NFC, etc.
  • a security element for example a SIM card (of the English Subscriber Identification Module)
  • This type of architecture offers a high level of security.
  • security features including radio technology are more expensive than conventional security features.
  • security elements which embed elements (hardware or software) specific to each service, are not generic and therefore difficult to use in a multi-application context.
  • the invention offers a solution that does not have the drawbacks of the state of the art.
  • the subject of the invention is a method of communication between two devices to which are respectively associated: two security elements comprising respective secret security keys,
  • the method comprising a mutual authentication step of the two devices, implemented by the two authenticators using their respective security elements to decrypt a session key.
  • each device (A, B) has a session key (KS) encrypted with the security key, or secret key, of its own security element, provided for example by an external server of applications.
  • KS session key
  • the security element performing the decryption can be a microprocessor of the object having the secret key or a SIM card-type security element, passing through all the intermediate possibilities.
  • a method as described above is further characterized in that the mutual authentication step comprises:
  • the present invention clearly separates the functional part of the service (the device and its authenticator) from the generic security part, independent of the services.
  • the security being provided by a security element that the authenticator uses, the two elements being independent, the security element is not related to the service, that is to say that we can address several services of different functionalities while having a unique and generic mechanism in the security element.
  • the security element may advantageously be worn on another device, and if vice versa the security element fails, it can (provided to be removable) be replaced.
  • a method as described above is further characterized in that the mutual authentication step comprises: a step of obtaining, by the two authenticators of the two devices, an initial encryption key encrypted by the secret security key of their respective security element.
  • the encryption key is encrypted with the secret key of the security element specific to each device.
  • the initial encryption key may be completely independent of the session key that is used for authentication, which increases the security of the session key
  • a method as described above is further characterized in that it comprises the following steps:
  • the session key is necessary, according to this embodiment, for the mutual authentication of the two devices: if the first security element (SEA) can decipher the randomly transmitted one, and which has been encrypted by the second security element ( ⁇ ALEA_A ⁇ KS encrypted by B), he knows that the second device has the correct session key (KS) for authentication and therefore the correct encryption key (KC). He deduces that the second device (B) is the one targeted by the service, since the session key (KS) encrypted by KB and delivered by the service on B could only be decrypted by the device B (containing the element B security with KB key).
  • the second security element (SEB) succeeds in deciphering the randomly transmitted one, and which has been encrypted by the first security element ( ⁇ ALEA_B ⁇ KS encrypted by A), it knows that the first device holds the correct session key (KS) for authentication and therefore the correct encryption key (KC). He deduces that the first device (A) is the one targeted by the service, since the session key (KS) encrypted by KA and delivered by the service on A could only be decrypted by the first device A (containing the SEA security element with key KA).
  • a method as described above is further characterized in that the encryption key is generated by a security element using the verification data and at least one secret data.
  • the encryption key (KC) is generated by the security element of each device from the two hazards used for mutual authentication and from a secret data, that is to say known only devices authorized to communicate.
  • secret data common to both devices, is necessary to ensure security, otherwise the encryption key could be guessed by a spy device on the session.
  • this secret data has been encrypted by the secret key of the security element of each device.
  • the encryption key can only be generated by the two security elements of the devices of the session, which considerably increases the security since a third device can not generate.
  • a method as described above is further characterized in that the secret data is the session key.
  • the session key is used as a secret element in combination with the two hazards to generate the encryption key. Since the session key has been previously encrypted by the secret key of the security elements of the devices, only the security elements of the devices in question can decipher it. The use of the session key and the two hazards is particularly interesting to obtain a robust construction of the key.
  • a method as described above is further characterized in that the secret data is the initial encryption key.
  • each device (A, B) has an initial encryption key (KSZ) supplied for example by an external application server, this encryption key being encrypted with the secret key of its own security element.
  • the initial encryption key KSZ is completely independent of the session key KS used for authentication, which increases the security of the session key KS. It is known in fact, according to the rules of the art with regard to cryptography, that it is preferable not to use the same key (or a derived key) for encryption and for authentication, if the key to authentication must be used multiple times, for example if the service allows the two devices (A and B) to reconnect together multiple times by reusing the KS key.
  • a method as described above is further characterized in that it further comprises a step of obtaining, respectively, by each device, an identifier of the session corresponding to the session key.
  • This embodiment of the invention makes it possible to simultaneously or successively manage several services on separate sessions by identifying, for the service and its current session, the good encrypted session key (KS), stored on the device to be used, among the set of encrypted session keys (KS) stored on the device.
  • KS good encrypted session key
  • the session identifier can advantageously serve as an index in a table stored for example in the security element, which makes it possible to identify the session being set up.
  • the machine targeted (machine A in the example above) can easily differentiate between the different sessions of the various services being established.
  • This session identifier advantageously also makes it possible to reference the encrypted session keys so that they can be accessed quickly and unambiguously by the two machines at the time of establishment of the session.
  • the invention also relates to a communication system comprising:
  • a server comprising a module for providing, for each device, at least the session key encrypted by a secret key known only to the security element of the device;
  • a security element comprising a secret security key
  • an authenticator comprising:
  • module may correspond to both a software component and a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally at any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the security element of these devices may be a SIM card.
  • SIM card (acronym for the English Subscriber Identity Module), is an electronic chip with a microcontroller and memories. It is particularly capable of supporting specific applications called “applets”, software programs specified in particular according to the ETSI TS 102 223 recommendation and which make it possible to perform certain functions in a secure manner, because executing precisely within the SIM card.
  • apps software programs specified in particular according to the ETSI TS 102 223 recommendation and which make it possible to perform certain functions in a secure manner, because executing precisely within the SIM card.
  • a SIM card can be included in a mobile phone or other communicating device.
  • the security element may also consist of a trusted execution environment.
  • trusted environment in English “TEE” for Trusted / Execution Environment
  • TEE Trusted / Execution Environment
  • TA Trusted Applications
  • the applications in the TEE benefit from a set of security services such as secure storage of data, management of keys and cryptographic algorithms, etc.
  • the invention also relates to a communication device as described above, characterized in that the device is a mobile phone.
  • the invention also relates to a computer program that can be implemented in a device and in a device. security element as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the method of establishing a communication session.
  • the invention also relates to a computer program adapted to be implemented in a security element as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the key generation method.
  • the invention also relates to a computer program adapted to be implemented in a server as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the method of delivery of the session keys.
  • the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for performing the steps of the method defined above.
  • FIG. 1 represents a system on which is illustrated an exemplary embodiment of the invention for secure communication between two devices equipped with a security element.
  • FIG. 2 represents a flowchart illustrating the various steps of a method according to the invention.
  • FIG. 1 represents a system on which is illustrated an exemplary embodiment of the invention for secure communication between two devices equipped with a security element.
  • the first (A) and second (B) devices are the two machines (or communicating objects) that will be called to mutually authenticate each other, then to exchange data confidentially on a communication link (L).
  • the machine A can for example be a smartphone and the machine B the computer of an automobile.
  • mutual authentication of both machines will allow a Zigbee smartphone to open the doors of the car, and then transmit confidential data to the on-board computer.
  • the machine could be of another type: parking terminal, server in a network, etc.
  • the communication link (L) can be of any type allowing the establishment of a communication, preferably point-to-point, between the two machines: communication in Wi-Fi mode, including "Wi-Fi Direct", a technology developed by the "Wi-Fi Alliance” consortium allowing the sharing of data between different devices via their Wi-Fi connection without intermediate Wi-Fi access point; Bluetooth type communication (BT), a short-distance radio technology intended to simplify connections between electronic devices, developed by the "Bluetooth SIG”association; near field communication, for example NFC (Near Field Communication), a technology based primarily on the International Standard Organization (ISO) 14443, to allow wireless information exchange between two peripherals a short distance away, typically less than ten centimeters; communication based on the Zigbee protocol (a protocol that allows communication in local networks, over a radio link, with reduced consumption), the "DECT" standard, etc.
  • Wi-Fi Direct a technology developed by the "Wi-Fi Alliance” consortium allowing the sharing of data between different devices via their Wi-Fi connection without
  • Each of the two machines or communicating objects has:
  • an application corresponding to the service to be implemented (respectively APA in machine A and APB in machine B) for the service or services considered.
  • an authenticator a software element typically found in a module of the machine less falsifiable than a normal application; the authenticator may for example be a process of the operating system or the modem of the machine. - a security element (resp. SEA and SEB).
  • security element is meant here a data storage and manipulation element to guarantee a user of the device a high security, since the data recorded in the security element are not accessible to an unauthorized user .
  • This security element may for example be constituted by a SIM card (Subscriber Identity Module), used in particular in mobile telephony for storing information specific to the subscriber of a mobile network and applications of the user, of its operator or in certain cases of third parties.
  • SIM card Subscriber Identity Module
  • This security element can still be a removable support type "Secure SD Card” or a security element integrated in the terminal ("Embedded Secure Element”) or a secure area of the application processor through the use of a technology of integrated security in the processor and its peripheral components (for example "TrustZone” technology, registered trademark of the ARM company).
  • Embedded Secure Element a technology of integrated security in the processor and its peripheral components
  • applications can also run with a security mainly based on software, in the Android terminal itself (from version 4.4. "KitKat” ), thanks to the "HCE"("Host Card Emulation”) technology that allows NFC communication with other devices.
  • this type of security mainly based on software can also use technologies known as obfuscation; For example, see the presentation in the article "WHITE-BOX CRYPTOGRAPHY: HIDING KEYS IN SOFTWARE” available at http://www.whiteboxcrypto.com/files/2012_misc.pdf.
  • the two devices are connected to an application server (SAP) responsible for delivering session keys in sequence so that the two machines can then authenticate by the method of the invention.
  • SAP application server
  • This application server can be part of any kind of service requiring dialogue between two machines. It can be a server on an Internet network, a mobile network, etc.
  • the right to use the service is delivered to both devices from the application server, which provided that the two machines meet; this application server has particular role, as will be detailed later, to deliver encrypted session keys in both machines.
  • the trusted server has the knowledge of the secret keys installed in the security elements of the two devices.
  • the security elements being SIM cards
  • this trusted server can belong to the mobile operator who distributes and controls the SIM cards of the two devices. It can in this case have the knowledge of a secret key, or security key, installed in each SIM card (different key for each SIM card).
  • the trusted server could be held for example by a car rental company who would have installed a secret key (different for each car) in the SIM cards (or security elements) contained in the communication equipment of his cars. In such cases, the same legal entity can maintain the application server (SAP) and trusted server (SC) roles.
  • SAP application server
  • SC trusted server
  • the application server is in charge of delivering session keys on both devices.
  • the application server transmits initially to the trusted server a message including the following information:
  • an index identifying the service concerned and the session in the service and which is used here as a reference between the application server and the trusted server for the request / response type of exchange between the two servers.
  • IDS index
  • another reference could alternatively be used between the application server and the trusted server, because the trusted server has no particular interest in knowing the session identifier that will be used later between the two devices.
  • KSK initial encryption key
  • KC final encryption key
  • the trusted server responds to the application server (SAP) with a message that includes:
  • the index (IDS) identifying the service concerned so that the application server can know which request refers to this response
  • the elements encrypted by the secret key (KA, KB) of the security element of each of the machines (respectively A and B); according to one example, the two data (KS and KSZ) are concatenated and encrypted by the secret key of the SIM of the machine A, KA (respectively the machine B, KB).
  • the application server delivers to the machine A (respectively B) these data encrypted by the secret key of its security element SEA (or SEB). All communication mode is possible for this communication (SMS, HTTP over 3G / 4G, etc ...) -
  • APA (respectively B, APB) stores (preferentially according to this embodiment, in its authenticator), the previously received elements.
  • each machine has elements that will enable it to implement the following process according to the invention, in particular the use, by each of the two security elements, the encrypted session key by the secret key specific to each security element.
  • FIG. 2 represents a flowchart illustrating the different steps of the method of the invention. During a step E0, as previously explained in support of the figure
  • the application server delivers to the two devices that are the machine A (A) and the machine B (B) the session key (KS) encrypted respectively by the secret key of their security element (KA, KB).
  • the application server delivers at the same time as the session key KS an initial key for the encryption, KSZ, and a session identifier, IDS:
  • the identifier of the session makes it possible to distinguish the communication session from the other communication sessions that may be established between the two machines, and also to reference the encrypted session keys so that they can be accessed by the two machines.
  • This session identifier is therefore comparable to a session index.
  • the KSZ encryption key is used later to generate the final KC encryption key which will be used for the exchange of encrypted data between the two machines. It is better, for reasons security, that this key is independent of the session key, which in turn serves for authentication.
  • the machine A and the machine B also have an authenticator, that is to say a privileged software element for communication with the security element, responsible in particular for storing the encrypted keys.
  • an authenticator that is to say a privileged software element for communication with the security element, responsible in particular for storing the encrypted keys.
  • the authenticator (AUTH) and the application (AP) are merged.
  • the application A of the machine A takes the initiative of contacting the application B of the machine B.
  • the application A can, for example, in the context of a near-field type communication mode. ZigBee, discover that another machine (Machine B) is nearby.
  • the application APA transmits to its security element SEA the session keys KS and KSZ encryption encrypted by the secret key KA of the security element and the session IDS index.
  • the application A sends the session IDS index to its authenticator and the authenticator A searches in the memory of the machine for what it has stored previously and which corresponds to the IDS index, namely the data (KS, KSZ) encrypted by the secret key of the security element KA, then it sends these elements to its security element SEA.
  • the application APB (or the authenticator of the machine B) transmits to its security element SEB the session keys KS and KSZ encryption encrypted by the secret key KB of the security element as well as the IDS session index.
  • the security element can process only one session establishment at a time (and not several in parallel), it is superfluous to communicate the IDS session index.
  • the security element is a SIM card, it is not multitasking in its operation. So she does not need to receive IDS there to add it in her answer, because the authenticator knows that the answer necessarily refers to the last command.
  • the security element SEA decrypts the received data with its secret key KA, then creates or modifies in its memory a so-called referencing table of the current sessions (TABSA):
  • step E4 similar to step E3, the security element SEB decrypts the received data with its secret key KB, then creates or modifies in its memory a so-called referencing array of the current sessions (TABSB):
  • the security element SEA generates a random for this session, AL_A. Randomness is classically a randomly generated number. Having a different random number each time prevents a person who has succeeded in recovering a signature of an old random number from reusing it. SEA adds this hazard to the line created in its TABSA referencing table:
  • the security element returns the hazard to the application (or authenticator according to this example) of the machine A, which receives it during a step E20.
  • the application (or the authenticator) of the machine A sends to the machine B the session IDS index and the random AL_A that has just been generated. This data is received by the application B of the machine B during a step E30, which retransmits them to its security element SEB.
  • the application B initially sends the index to its authenticator and the latter searches in memory for the elements stored previously in relation with the IDS index, that is to say (KS, KSZ) encrypted by the secret key KB of the security element.
  • the security element SEB receives the data IDS, and AL_A, and completes in its memory the row of the referencing table TABSB of the current sessions by adding AL_A.
  • the state of his painting is then the following:
  • a step E41 the security element of the machine B encrypts this hazard with the session key KS and returns it to the application (or the authenticator).
  • the security element SEB also generates a hazard for this session, AL_B. It adds this hazard to its TABSB referencing table, and returns it to the application (or authenticator). The state of his painting is then the following:
  • steps E4 and E40 could advantageously be concatenated, which would notably make it possible to gain an exchange with the security element. It is the same with steps E41 and E42.
  • the application B sends the data IDS, AL_A encrypted by KS and AL_B to the application A.
  • the application A (via the authenticator) relays this data (IDS,
  • SEA ⁇ AL_A ⁇ KS, AL_B
  • SEA the security element of the machine A, SEA, consults its referencing table of the sessions in progress (if there are several) and determines (via the index IDS) the line of the session concerned, then add AL_B to the table; the state of his painting is then the following:
  • step Eli SEA decrypts the encrypted random received ⁇ AL_A ⁇ K s; if the result found is equal to AL_A in the table, the process continues; SEA returns an acknowledgment message during a step E12 successive to the authenticator and / or the application A. Otherwise the process is interrupted and the two machines can not mutually authenticate.
  • This acknowledgment of the security element SEA indicates that the verification of AL_A encrypted by the machine B is positive. From this moment, the security element SEA knows that the machine B holds the correct session session key KS for the authentication (and also, according to this embodiment, the correct KSZ key for the encryption).
  • the security element During a step E13, the security element generates an encryption key KC which is derived from a data processing KSZ (secret data), AL_A and AL_B (random); according to one embodiment, the generation consists in chopping AL_A concatenated with AL_B then encrypting the result by KSZ, to obtain KC.
  • KSZ secret data
  • AL_A secret data
  • AL_B random
  • the generation consists in chopping AL_A concatenated with AL_B then encrypting the result by KSZ, to obtain KC.
  • the session key KS is used as secret data instead of the key KSZ.
  • the authenticator that receives the data coming from the security element and returns to the application A with the acknowledgment as well as IDS, KC, and AL_B encrypted by the session key.
  • the acknowledgment of the authenticator A to the application A indicates that the authentication of the machine B is positive.
  • Application A may therefore use KC to encrypt the data to Application B.
  • the security element SEA encrypts AL_B with KS and returns the result to the application (or authenticator).
  • steps E12, E13 and E14 could be concatenated, which would notably make it possible to gain two exchanges with the security element.
  • the application A transmits to the application B the information IDS, OK, ⁇ AL_B ⁇ KS.
  • the application B interprets, during the step E33, the field "OK” as indicating that the machine A has authenticated the machine B.
  • the application B (or the authenticator) then relays this data (IDS, ⁇ AL_B ⁇ KS) to its security element SEB.
  • the security element of the machine B SEB, consults its referencing table of the sessions in progress (if there are several) and determines (via the index IDS) the line of the relevant session which takes the form:
  • SEB decrypts the encrypted randomly received ⁇ AL_B ⁇ K s; if the result found is equal to AL_B in the table, the process continues: SEB returns an acknowledgment message during a step E44 successive to the authenticator and / or the application A. Otherwise the process is interrupted and the two machines will not be able to authenticate each other.
  • This acknowledgment of SEB indicates that the verification of AL_B encrypted by machine A is positive. From that moment, SEB knows that machine A has the correct KS session session key for authentication (and according to this embodiment, the correct KSZ session key for encryption).
  • the security element SEB generates an encryption key KC which is derived from a processing of the data KSZ, AL_A and AL_B; according to one embodiment, the generation consists in chopping AL_A concatenated with AL_B then encrypting the result by KSZ, to obtain KC.
  • the key KC obtained in this step is identical to that obtained in step E13.
  • it is the authenticator of B that receives the data coming from the security element and returns to the application B the acknowledgment as well as IDS and KC. The acknowledgment of the authenticator B to the application B indicates in this case that the authentication of the machine A is positive.
  • Application B may therefore use KC to encrypt the data to Application A without resorting to the security element.
  • the security element no longer uses the referencing table of the current sessions.
  • the array can be cleared.
  • steps E44 and E45 could be concatenated, which would notably make it possible to gain an exchange with the security element.
  • the application B sends an acknowledgment in the form of a message (IDS, OK) to the application A.
  • the application A interprets the "OK" field as indicating that the machine B has authenticated machine A.
  • the application A relays the information (IDS, OK) to its authenticator, so that it updates its state machine.

Abstract

L'invention concerne un procédé de communication entre deux dispositifs (A,B) auxquels sont associés respectivement : - deux éléments de sécurité (SEA, SEB) comportant des clés secrètes de sécurité (KA,KB) respectives, - deux authentificateurs (AUA, AUB), Le procédé comporte une étape d'authentification mutuelle des deux dispositifs (E10-E14, E20-25, E30-36, E40-E45), mise en œuvre par les deux authentificateurs (AUA, AUB) faisant appel à leurs éléments de sécurité respectifs (SEA, SEB) pour déchiffrer une clé de session (KS).

Description

COMMUNICATION ENTRE DEUX ÉLÉMENTS DE SÉCURITÉ
INSÉRÉS DANS DEUX OBJETS COMMUNICANTS
Domaine technique
L'invention se rapporte à un procédé de communication entre deux objets de télécommunication. Elle concerne également un objet de télécommunication destiné à la mise en œuvre dudit procédé.
L'invention s'applique à tout objet de communication équipé d'un élément de sécurité. Elle trouve une application particulièrement avantageuse dans le domaine de la sécurité des services de télécommunication entre objets, éventuellement portables, munis d'un élément de sécurité.
Etat de la technique
Le mode de communication direct entre deux machines, dit M2M (de l'anglais Machine To Machiné), aussi appelé pair à pair (ou Peer to Peer en anglais), devient de plus en plus fréquent, par exemple dans le contexte d'une communication entre le téléphone portable et l'ordinateur de bord d'une automobile d'un utilisateur. Ces communications sont aujourd'hui vulnérables aux attaques de pirates qui pourraient prendre le contrôle d'un tel objet (dans cet exemple, le véhicule). Un besoin existe donc de sécuriser les communications de pair à pair entre machines. A cet effet, certaines normes de communication radio de machine à machine disposent de fonctionnalités de chiffrement et d'établissement de clés entre les deux entités communicantes. Par exemple ZigBee, basé sur la norme IEEE 802.15.4, définit un ensemble de protocoles de communications de haut niveau utilisant des transmission radio à faible consommation. ZigBee propose l'utilisation d'un algorithme de chiffrement symétrique des données. Ce type de sécurité n'est cependant pas générique : elle reste liée à la technologie radio utilisée, dans ce cas Zigbee. Par ailleurs ce type de sécurité est loin d'être aussi élevé que celui offert par un élément de sécurité. Or il existe des cas d'usage (dans les domaines de l'automobile, de la santé, etc.) où il est nécessaire d'assurer un fort niveau de sécurité.
L'intégration matérielle d'un module de communication (par exemple ZigBee, NFC, etc.) dans un élément de sécurité, par exemple une carte dite SIM (de l'anglais Subscriber Identification Module), est connu. Ce type d'architecture offre une sécurité de haut niveau. Cependant, de tels éléments de sécurité incluant une technologie radio sont plus coûteux que des éléments de sécurité classiques. De plus, si plusieurs services sont visés, de tels éléments de sécurité, qui embarquent des éléments (hardware ou logiciels) propres à chaque service, ne sont pas génériques et de ce fait difficiles à utiliser dans un contexte multi- applications.
Il est donc souhaitable de bénéficier d'une technologie à la fois générique et assurant le niveau de sécurité maximal, c'est-à-dire celui offert par un élément de sécurité. II est également connu un procédé d'authentification entre deux dispositifs électroniques, munis ou non d'un élément de sécurité, basé sur la génération de deux nombres aléatoires, transmis sur les deux dispositifs et chiffrés sur chacun d'entre eux par une clé secrète connue des deux, de manière à ce que la comparaison des deux cryptogrammes assure l'identification mutuelle des deux dispositifs. Le brevet européen EP0631408 donne un exemple d'un tel procédé.
Il est aussi connu du document « Survey on secure communication protocols for the Internet of Things » (Nguyen K.T. et al, Ad Hoc Networks, vol. 32, 01.09.2015, pages 17-31) un procédé de livraison sur deux dispositifs d'une clé de session chiffrée par la clé secrète respective de chacun des deux dispositifs. Cependant un tel système n'est pas entièrement satisfaisant, car au- delà de l'authentification mutuelle, les deux dispositifs électroniques n'ont pas l'assurance de pouvoir échanger des données avec un haut niveau de sécurité. En outre, ces principes ne sont pas adaptés pour faire inter-fonctionner les deux dispositifs dans un environnement multiservices, car la même clé secrète est utilisée pour tous les services mis en œuvre par les dispositifs.
L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.
L'invention
A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de communication entre deux dispositifs auxquels sont associés respectivement : - deux éléments de sécurité comportant des clés secrètes de sécurité respectives,
deux authentificateurs, le procédé comportant une étape d'authentification mutuelle des deux dispositifs, mise en œuvre par les deux authentificateurs faisant appel à leurs éléments de sécurité respectifs pour déchiffrer une clé de session.
On entend par authentification mutuelle l'ensemble des étapes qui sont classiquement exécutées pour que la machine A authentifie la machine B et vice- versa. Avantageusement selon l'invention, chaque dispositif (A,B) dispose d'une clé de session (KS) chiffrée avec la clé de sécurité, ou clé secrète, de son propre élément de sécurité, fournie par exemple par un serveur externe d'applications. Ainsi, seuls les dispositifs (A,B) visés initialement par le serveur pourront établir la session de communication, puisqu'ils seront les seuls à pouvoir déchiffrer la clé de session, au moyen de leur clé secrète, et donc utiliser cette clé de session.
Avantageusement, par rapport aux systèmes de l'état de l'art, seuls les dispositifs autorisés, c'est-à-dire ceux qui ont reçu d'un serveur de service la clé de session chiffrée par la clé secrète de leur élément de sécurité, vont pouvoir utiliser le service entre eux. De surcroît, l'usage de la clé secrète propre à chaque dispositif permet de chiffrer des clés de session pour différents services. Ces principes sont utilisables quelle que soit la technologie radio et avantageusement adaptables quant au niveau de sécurité réalisé : : l'élément de sécurité effectuant le déchiffrement peut être un microprocesseur de l'objet disposant de la clé secrète ou un élément de sécurité de type carte SIM, en passant par toutes les possibilités intermédiaires. On notera notamment que cette solution surmonte avantageusement les inconvénients du document précité « Survey on secure communication protocols for the Internet of Things », car selon ce document : soit la clé de session chiffrée est livrée dans les deux dispositifs eux-mêmes et dans ce cas les deux dispositifs électroniques n'ont pas l'assurance de pouvoir échanger des données avec un haut niveau de sécurité, puisque les clés de session chiffrées sont déchiffrées et utilisées dans les dispositifs eux- mêmes, soit les clés de session chiffrées sont livrées dans les éléments de sécurité des dispositifs et dans ce cas, dans un environnement multiservices, ces éléments de sécurité sont obligés de stocker et de gérer ces clés de session chiffrées toute la durée où elles sont utilisables, ce qui complexifie les éléments de sécurité et ne permet pas leur l'indépendance vis-à-vis des services.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est en outre caractérisé en ce l'étape d'authentification mutuelle comporte :
- une étape d'obtention, par les deux authentificateurs des deux dispositifs, de la clé de la session chiffrée par la clé secrète de leur élément de sécurité respectif. - une étape de transmission, par chaque authentificateur à son élément de sécurité respectif de la clé de session chiffrée par la clé secrète de l'élément de sécurité respectif ; - une étape de déchiffrement, par les éléments de sécurité respectifs, de la clé de session.
Avantageusement par rapport au système de l'état de l'art précité, la présente invention sépare nettement la partie fonctionnelle du service (le dispositif et son authentificateur) de la partie sécurité générique, indépendante des services. En effet, la sécurité étant assurée par un élément de sécurité auquel fait appel l'authentificateur, les deux éléments étant indépendants, l'élément de sécurité n'est pas lié au service, c'est-à-dire que l'on peut adresser plusieurs services de fonctionnalités différentes tout en ayant un mécanisme unique et générique dans l'élément de sécurité.
Corrélativement, si le dispositif tombe en panne, l'élément de sécurité pourra avantageusement être porté sur un autre dispositif, et si inversement l'élément de sécurité tombe en panne, il pourra (à condition d'être amovible) être remplacé.
Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mise en œuvre alternativement ou cumulativement avec le précédent, un procédé tel que décrit ci-dessus est en outre caractérisé en ce l'étape d'authentification mutuelle comporte : - une étape d'obtention, par les deux authentificateurs des deux dispositifs, d'une clé initiale de chiffrement chiffrée par la clé secrète de sécurité de leur élément de sécurité respectif.
- une étape de transmission par chaque authentificateur à son élément de sécurité respectif, de la clé initiale de chiffrement chiffrée par la clé secrète de l'élément de sécurité respectif ; une étape de déchiffrement, par les éléments de sécurité respectifs, de la clé initiale de chiffrement. Avantageusement selon ce mode, la clé de chiffrement est donc chiffrée avec la clé secrète de l'élément de sécurité propre à chaque dispositif. Ainsi, seuls les dispositifs visés initialement par le serveur pourront communiquer, puisqu'ils seront les seuls à pouvoir la déchiffrer. La clé initiale de chiffrement peut être complètement indépendante de la clé de session qui sert à l'authentification, ce qui augmente la sécurité de la clé de session
Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mise en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit ci-dessus est en outre caractérisé en ce qu'il comporte les étapes suivantes :
- transmission, du premier dispositif au second dispositif, d'une première donnée de vérification générée par l'élément de sécurité du premier dispositif ;
- réception par le second dispositif de la première donnée de vérification ;
- transmission, du second dispositif au premier dispositif, d'une seconde donnée de vérification générée par l'élément de sécurité du second dispositif et de la première donnée de vérification chiffrée par l'élément de sécurité du second dispositif à l'aide d'une clé de session ;
- réception par le premier dispositif de la seconde donnée de vérification et de la première donnée de vérification chiffrée par l'élément de sécurité du second dispositif ;
- authentification du second dispositif par le premier dispositif à l'aide de la première donnée de vérification chiffrée ;
- génération par l'élément de sécurité du premier dispositif d'une première clé de chiffrement pour l'échange de données chiffrées entre les deux dispositifs sur la session ; - transmission, du premier dispositif au second dispositif, de la seconde donnée de vérification chiffrée par l'élément de sécurité du premier dispositif à l'aide de ladite clé de session ;
- authentification du premier dispositif par le second dispositif à l'aide la seconde donnée de vérification chiffrée ;
- génération, par l'élément de sécurité du second dispositif, d'une seconde clé de chiffrement pour l'échange de données chiffrées entre les deux dispositifs sur la session, ladite seconde clé de chiffrement étant identique à la première clé de chiffrement.
La clé de session est nécessaire, selon ce mode de réalisation, à l'authentification mutuelle des deux dispositifs : si le premier élément de sécurité (SEA) parvient à déchiffrer l'aléa qu'il a préalablement transmis, et qui a été chiffré par le second élément de sécurité ({ALEA_A}KS chiffré par B), il sait que le second dispositif détient la bonne clé de session (KS) pour l'authentification et donc la bonne clé de chiffrement (KC). Il en déduit que le second dispositif (B) est bien celui visé par le service, puisque la clé de session (KS) chiffrée par KB et livrée par le service sur B ne pouvait être déchiffrée que par le dispositif B (contenant l'élément de sécurité de B avec la clé KB). Symétriquement, si le second élément de sécurité (SEB) parvient à déchiffrer l'aléa qu'il a préalablement transmis, et qui a été chiffré par le premier élément de sécurité ({ALEA_B}KS chiffré par A), il sait que le premier dispositif détient la bonne clé de session (KS) pour l'authentification et donc la bonne clé de chiffrement (KC). Il en déduit que le premier dispositif (A) est bien celui visé par le service, puisque la clé de session (KS) chiffrée par KA et livrée par le service sur A ne pouvait être déchiffrée que par le premier dispositif A (contenant l'élément de sécurité SEA avec la clé KA).
Selon une variante de ce mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que la clé de chiffrement est générée par un élément de sécurité en utilisant les données de vérification et au moins une donnée secrète.
Selon cette variante, la clé de chiffrement (KC) est générée par l'élément de sécurité de chaque dispositif à partir des deux aléas ayant servi à l'authentification mutuelle et à partir d'une donnée secrète, c'est-à-dire connue seulement des dispositifs autorisés à communiquer. Une telle donnée secrète, commune aux deux dispositifs, est nécessaire pour assurer la sécurité, faute de quoi la clé de chiffrement pourrait être devinée par un dispositif espion sur la session. De préférence, cette donnée secrète a été chiffrée par la clé secrète de l'élément de sécurité de chaque dispositif.
Grâce à l'utilisation avantageuse des deux aléas et de la donnée secrète, la clé de chiffrement ne peut être générée que par les deux éléments de sécurité des dispositifs de la session, ce qui augmente considérablement la sécurité puisqu'un dispositif tiers ne peut la générer. De surcroît, il n'est pas nécessaire de mettre en œuvre des échanges supplémentaires, en plus des échanges nécessaires à l'authentification préalable.
Selon encore une variante de cette variante, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que en ce que la donnée secrète est la clé de session.
Avantageusement selon ce mode, la clé de session est utilisée comme élément secret en combinaison avec les deux aléas pour générer la clé de chiffrement. La clé de session ayant été préalablement chiffrée par la clé secrète des éléments de sécurité des dispositifs, seuls les éléments de sécurité des dispositifs en question peuvent la déchiffrer. L'utilisation de la clé de session et des deux aléas est particulièrement intéressante pour obtenir une construction robuste de la clé. Selon encore une seconde variante, qui pourra être mise en œuvre alternativement ou cumulativement avec la précédente, un procédé tel que décrit plus haut est en outre caractérisé en ce que la donnée secrète est la clé initiale de chiffrement. Selon cette variante, chaque dispositif (A,B) dispose d'une clé de chiffrement initiale (KSZ) fournie par exemple par un serveur externe d'applications, cette clé de chiffrement étant chiffrée avec la clé secrète de son propre élément de sécurité. Ainsi, seuls les dispositifs (A,B) visés initialement par le serveur pourront communiquer, puisqu'ils seront les seuls à pouvoir la déchiffrer. Dans ce mode, la clé initiale de chiffrement KSZ est complètement indépendante de la clé de session KS qui sert à l'authentification, ce qui augmente la sécurité de la clé de session KS. Il est connu en effet, selon les règles de l'art en matière de cryptographie, qu'il est préférable de ne pas utiliser la même clé (ou une clé dérivée) pour le chiffrement et pour l'authentification, si la clé d'authentification doit être utilisée plusieurs fois, par exemple si le service permet que les deux dispositifs (A et B) se reconnectent ensemble plusieurs fois en réutilisant la clé KS.
Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce qu'il comporte en outre une étape d'obtention, respectivement, par chaque dispositif, d'un identifiant de la session correspondant à la clé de session.
Ce mode de réalisation de l'invention permet de gérer simultanément ou successivement plusieurs services sur des sessions distinctes en identifiant, pour le service et sa session courante, la bonne clé de session (KS) chiffrée, stockée sur le dispositif à utiliser, parmi l'ensemble de clés de sessions (KS) chiffrées, stockées sur le dispositif. On peut ainsi imaginer un premier service s'exécutant entre deux machines A et B sur une session Wi-Fi, un second service s'exécutant entre les deux machines A et B en Zigbee, et un troisième service s'exécutant en NFC entre les machines A et C. Dans ce cas, le dispositif A aura tout intérêt à mémoriser trois identifiants de session distincts.
Si le dispositif doit traiter en parallèle plusieurs établissements de session, l'identifiant de session peut servir avantageusement d'index dans un tableau mémorisé par exemple dans l'élément de sécurité, qui permet de repérer la session en cours d'établissement. Ainsi la machine ciblée (la machine A dans l'exemple ci-dessus) pourra-t-elle faire facilement la différence entre les différentes sessions des différents services en cours d'établissement. Cet identifiant de la session permet avantageusement aussi de référencer les clés de session chiffrées afin qu'elles puissent être accédées rapidement et de manière univoque par les deux machines au moment de l'établissement de la session.
Selon un aspect matériel, l'invention concerne également un système de communication comprenant :
- un serveur comprenant un module de fourniture, pour chaque dispositif, d'au moins la clé de session chiffrée par une clé secrète connue seulement de l'élément de sécurité du dispositif ;
- au moins deux dispositifs comportant respectivement :
- un éléments de sécurité comportant une clé secrète de sécurité
- un authentificateur comportant :
- un module d'obtention de la clé de session chiffrée par la clé secrète de son élément de sécurité respectif ;
- un module d'authentification mutuelle faisant appel à son élément de sécurité respectif pour déchiffrer la clé de session.
Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L'élément de sécurité de ces dispositifs peut être une carte SIM.
On rappelle qu'une carte SIM (acronyme de l'anglais Subscriber Identity Module), est une puce électronique comportant un microcontrôleur et des mémoires. Elle est notamment apte à supporter des applications spécifiques appelées "applets", programmes logiciels spécifiés en particulier selon la recommandation ETSI TS 102 223 et qui permettent de réaliser certaines fonctions de manière sécurisée, car s'exécutant justement au sein de la carte SIM. Une carte SIM peut être incluse dans un téléphone mobile ou tout autre dispositif communiquant.
L'élément de sécurité peut aussi être constitué d'un environnement d'exécution de confiance. Par « environnement de confiance » (en Anglais « TEE » pour Trusté / Execution Environnement), on se réfère ici à une zone sécurisée et isolée d'autres environnements d'exécutions, située dans un dispositif (de type téléphone portable), garantissant que des données sensibles sont stockées, traitées et protégées dans un environnement de confiance. Les applications présentes dans le TEE, appelées Trusted Applications (TA), ou applications de confiance, bénéficient d'un ensemble de services de sécurité comme le stockage sécurisé des données, la gestion des clefs et d'algorithmes cryptographiques, etc.
Selon un autre aspect matériel, l'invention concerne également un dispositif de communication tel que décrit ci-dessus, caractérisé en ce que le dispositif est un téléphone mobile.
Selon un autre aspect matériel, l'invention concerne également un programme d'ordinateur apte à être mis en œuvre dans un dispositif et dans un élément de sécurité tels que définis ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé d'établissement d'une session de communication.
Selon un autre aspect matériel, l'invention concerne également un programme d'ordinateur apte à être mis en œuvre dans un élément de sécurité tel que défini ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de génération de clé.
Selon un autre aspect matériel, l'invention concerne également un programme d'ordinateur apte à être mis en œuvre dans un serveur tel que défini ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de livraison des clés de session.
Ces dispositifs, serveur, système et programmes d'ordinateurs présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de communication.
Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programmes comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini ci-dessus.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Les figures: La figure 1 représente un système sur lequel est illustré un exemple de réalisation de l'invention pour la communication sécurisée entre deux dispositifs équipés d'un élément de sécurité.
La figure 2 représente un organigramme illustrant les différentes étapes d'un procédé selon l'invention.
Description détaillée d'un exemple de réalisation illustrant l'invention
La figure 1 représente un système sur lequel est illustré un exemple de réalisation de l'invention pour la communication sécurisée entre deux dispositifs équipés d'un élément de sécurité.
Selon cet exemple, les premier (A) et second (B) dispositifs sont les deux machines (ou objets communicants) qui vont être appelées à s'authentifier mutuellement, puis à échanger des données de manière confidentielle sur un lien de communication (L). La machine A peut par exemple être un smartphone et la machine B l'ordinateur de bord d'une automobile. Par exemple, l'authentification mutuelle des deux machines va permettre à un smartphone Zigbee d'ouvrir les portes de la voiture, puis de transmette ensuite des données confidentielles à l'ordinateur de bord. On notera que la machine pourrait être d'un autre type : borne de parking, serveur dans un réseau, etc.
Le lien de communication (L) peut être de tout type permettant l'établissement d'une communication, de préférence en point à point, entre les deux machines : communication en mode Wi-Fi, notamment «Wi-Fi Direct », une technologie développée par le consortium «Wi-Fi Alliance» permettant le partage de données entre différents périphériques via leur connexion Wi-Fi sans point d'accès Wi-Fi intermédiaire ; communication de type Bluetooth (BT), une technologie radio de courte distance destinée à simplifier les connexions entre les appareils électroniques, développée par l'association « Bluetooth SIG » ; communication en champ proche, par exemple de type NFC (Near Field Communication), une technologie basée principalement sur la norme ISO (International Standard Organisation) 14443, pour permettre un échange d'informations sans fil entre deux périphériques éloignés d'une courte distance, typiquement inférieure à dix centimètres ; communication basée sur le protocole Zigbee (un protocole qui permet la communication dans des réseaux locaux, sur un lien radio, avec une consommation réduite), la norme «DECT», etc.
Chacune des deux machines ou objets communicants (A, B) dispose:
- d'une application correspondant au service à mettre en œuvre (resp. APA dans la machine A et APB dans la machine B) pour le ou les services considérés.
- d'un authentificateur (resp. AUA et AUB), élément logiciel se trouvant typiquement dans un module de la machine moins falsifiable qu'une application normale ; l'authentificateur peut par exemple être un processus du système d'exploitation ou du modem de la machine. - d'un élément de sécurité (resp. SEA et SEB). Par « élément de sécurité », on entend ici un élément de stockage et de manipulation des données permettant de garantir à un utilisateur du dispositif une sécurité élevée, puisque les données enregistrées dans l'élément de sécurité ne sont pas accessibles à un utilisateur non autorisé. Cet élément de sécurité peut par exemple être constitué par une carte SIM (de l'anglais Subscriber Identity Module), utilisée notamment en téléphonie mobile pour stocker les informations spécifiques à l'abonné d'un réseau mobile et des applications de l'utilisateur, de son opérateur ou dans certains cas de tierces parties. Cet élément de sécurité peut encore être un support amovible de type "Secure SD Card" ou un élément de sécurité intégré au terminal ("Embedded Secure Elément") ou encore une zone sécurisée du processeur applicatif grâce à l'utilisation d'une technologie de sécurité intégrée dans le processeur et ses composants périphériques (par exemple la technologie « TrustZone », marque déposée de la société ARM). Dans le cas d'un terminal supportant des applications de type Android (on rappelle qu'une application Android est une application mobile spécifiquement développée pour les terminaux mobiles utilisant le système d'application Android développé par la société Google), des applications peuvent également s'exécuter avec une sécurité principalement basée sur du logiciel, dans le terminal Android lui-même (à partir de la version 4.4. "KitKat"), grâce à la technologie "HCE" ("Host Card Emulation") qui permet la communication NFC avec d'autres équipements. De manière plus générale, ce type de sécurité principalement basé sur du logiciel peut aussi utiliser des technologies connues sous la dénomination d'obfuscation ; on se référera par exemple à la présentation donnée dans la l'article « WHITE-BOX CRYPTOGRAPHY: HIDING KEYS IN SOFTWARE » accessible à l'adresse http://www.whiteboxcrypto.com/files/2012_misc.pdf.
Par la suite, on utilisera indifféremment les termes « élément de sécurité » et « carte SIM ».
Les deux dispositifs sont connectés à un serveur applicatif (SAP) chargé de délivrer au coup par coup des clés de sessions afin que les deux machines puissent ensuite s'authentifier par le procédé de l'invention. Ce serveur applicatif peut relever de toute sorte de service nécessitant de faire dialoguer deux machines. Il peut s'agir d'un serveur sur un réseau Internet, sur un réseau mobile, etc. Le droit d'utiliser le service est livré aux deux dispositifs à partir du serveur applicatif, qui a prévu que les deux machines se rencontrent ; ce serveur applicatif a notamment pour rôle, comme il sera détaillé par la suite, de livrer les clés de session chiffrées dans les deux machines.
Le serveur de confiance (SC) a quant à lui la connaissance des clés secrètes installées dans les éléments de sécurité des deux dispositifs. Dans l'exemple décrit ici, les éléments de sécurité étant des cartes SIM, ce serveur de confiance peut appartenir à l'opérateur mobile qui distribue et contrôle les cartes SIM des deux dispositifs. Il peut dans ce cas avoir la connaissance d'une clé secrète, ou clé de sécurité, installée dans chaque carte SIM (clé différente pour chaque carte SIM). Selon un autre exemple, le serveur de confiance pourrait être tenu par exemple par un loueur d'automobiles qui aurait fait installer une clé secrète (différente pour chaque voiture) dans les cartes SIM (ou éléments de sécurité) contenues dans les équipements de communication de ses voitures. Dans de tels cas, la même entité juridique peut tenir les rôles de serveur applicatif (SAP) et de serveur de confiance (SC).
Selon un mode de réalisation de l'invention, qui sera détaillé par la suite à l'appui de la figure 2, le serveur applicatif est en charge de la livraison des clés de session sur les deux dispositifs.
1) Le serveur applicatif transmet dans un premier temps au serveur de confiance un message comprenant les informations suivantes:
- l'identité de la machine A et l'identité de la machine B ;
- la clé de session (KS) qui servira ensuite aux deux machines pour s'authentifier mutuellement ;
- éventuellement un index (IDS) identifiant le service concerné et la session dans le service et qui sert ici de référence entre le serveur applicatif et le serveur de confiance pour l'échange de type requête/réponse entre les deux serveurs. On notera qu'une autre référence pourrait selon une variante être utilisée entre le serveur applicatif et le serveur de confiance, car le serveur de confiance n'a pas d'intérêt particulier à connaître l'identifiant de session qui sera utilisé ultérieurement entre les deux dispositifs.
- éventuellement une clé de chiffrement initiale (KSZ) qui servira pour générer la clé de chiffrement finale (KC) qui servira aux deux machines pour échanger des données de manière confidentielle sur la session.
2) Le serveur de confiance (SC) répond au serveur applicatif (SAP) par un message qui comprend :
l'index (IDS) identifiant le service concerné pour que le serveur applicatif puisse savoir à quelle requête se réfère cette réponse ;
des éléments chiffrés par la clé secrète (KA, KB) de l'élément de sécurité de chacune des machines (resp. A et B) ; selon un exemple, les deux données (KS et KSZ) sont concaténées et chiffrées par la clé secrète de la SIM de la machine A, KA (resp. la machine B, KB).
3) Le serveur applicatif délivre à la machine A (resp. B) ces données chiffrées par la clé secrète de son élément de sécurité SEA (resp. SEB). Tout mode de communication est envisageable pour cette communication (SMS, HTTP sur 3G/4G, etc...)-
4) L'application dans la machine A, APA (resp. B, APB) stocke (préférentiel lement selon ce mode de réalisation, dans son authentificateur), les éléments reçus précédemment.
A l'issue de cette étape, chaque machine dispose des éléments qui vont lui permettre de mettre en œuvre la suite du procédé selon l'invention, en particulier l'utilisation, par chacun des deux éléments de sécurité, de la clé de session chiffrée par la clé secrète propre à chaque élément de sécurité.
La figure 2 représente un organigramme illustrant les différentes étapes du procédé de l'invention. Lors d'une étape E0, comme expliqué auparavant à l'appui de la figure
1, le serveur applicatif délivre aux deux dispositifs que sont la machine A (A) et la machine B (B) la clé de session (KS) chiffrée respectivement par la clé secrète de leur élément de sécurité (KA, KB).
Selon ce mode de réalisation, le serveur applicatif délivre en même temps que la clé de session KS une clé initiale pour le chiffrage, KSZ, et un identificateur de session, IDS :
- l'identificateur de la session permet de distinguer la session de communication des autres sessions de communication susceptibles d'être établies entre les deux machines, et aussi de référencer les clés de session chiffrées afin qu'elles puissent être accédées par les deux machines. Cet identificateur de session est donc assimilable à un index de session.
- la clé de chiffrage KSZ est utilisée ultérieurement pour générer la clé de chiffrage finale KC qui sera utilisée pour l'échange des données chiffrées entre les deux machines. Il est préférable, pour des raisons de sécurité, que cette clé soit indépendante de la clé de session, qui sert pour sa part à l'authentification.
Selon ce mode de réalisation, la machine A et la machine B disposent également d'un authentificateur, c'est-à-dire un élément logiciel privilégié pour la communication avec l'élément de sécurité, chargé notamment de stocker les clés chiffrées. Sur l'exemple de la figure 2, l'authentificateur (AUTH) et l'application (AP) sont confondus.
Dans cet exemple, l'application A de la machine A prend l'initiative de contacter l'application B de la machine B. L'application A peut, par exemple, dans le contexte d'un mode de communication en champ proche de type ZigBee, découvrir qu'une autre machine (la machine B) est à proximité.
Lors d'une étape El, l'application APA transmet à son élément de sécurité SEA les clés KS de session et KSZ de chiffrement chiffrées par la clé secrète KA de l'élément de sécurité ainsi que l'index IDS de session.
Selon une variante, l'application A envoi à son authentificateur l'index IDS de session et l'authentificateur A cherche dans la mémoire de la machine ce qu'il y a stocké précédemment et qui correspond à l'index IDS, à savoir les données (KS, KSZ) chiffrées par la clé secrète de l'élément de sécurité KA, puis il envoie ces éléments à son élément de sécurité SEA.
Lors d'une étape E2 symétrique, l'application APB (ou l'authentificateur de la machine B) transmet à son élément de sécurité SEB les clés KS de session et KSZ de chiffrement chiffrées par la clé secrète KB de l'élément de sécurité ainsi que l'index de session IDS. On notera que, dans un mode de réalisation où l'élément de sécurité ne sait traiter qu'un seul établissement de session à la fois (et non plusieurs en parallèle), il est superflu de lui communiquer l'index de session IDS. Notamment si l'élément de sécurité est une carte SIM, celle-ci n'est pas multitâche dans son fonctionnement. Elle n'a donc pas besoin de recevoir IDS n'y de l'ajouter dans sa réponse, car l'authentificateur sait que la réponse se réfère forcément à la dernière commande.
Lors d'une étape E3, l'élément de sécurité SEA déchiffre avec sa clé secrète KA les données reçues, puis crée ou modifie dans sa mémoire un tableau dit de référencement des sessions en cours (TABSA):
Figure imgf000021_0001
On notera qu'après authentification, cette table n'est plus utilisée.
Selon une variante, s'il y avait plusieurs serveurs de confiance associés au serveur applicatif, il pourrait y avoir plusieurs clés KA, il faudrait alors passer un identifiant de clé secrète KA. Cette variante n'est pas décrite plus avant.
Lors d'une étape E4 similaire à l'étape E3, l'élément de sécurité SEB déchiffre avec sa clé secrète KB les données reçues, puis crée ou modifie dans sa mémoire un tableau dit de référencement des sessions en cours (TABSB) :
Figure imgf000021_0002
Lors d'une étape E10, l'élément de sécurité SEA génère un aléa pour cette session, AL_A. L'aléa est classiquement un nombre généré aléatoirement. Le fait d'avoir un nombre aléatoire différent à chaque fois permet d'éviter qu'une personne ayant réussi à récupérer une signature d'un ancien nombre aléatoire puisse la réutiliser. SEA ajoute cet aléa dans la ligne créée dans son tableau de référencement TABSA :
IDS KS KSZ AL A
Puis l'élément de sécurité retourne l'aléa à l'application (ou authentificateur selon cet exemple) de la machine A, qui la reçoit lors d'une étape E20.
Lors d'une étape E20, l'application (ou l'authentificateur) de la machine A envoie vers la machine B l'index IDS de session ainsi que l'aléa AL_A qui vient d'être généré. Ces données sont reçues par l'application B de la machine B lors d'une étape E30, qui les retransmet à son élément de sécurité SEB.
Selon une variante, l'application B envoie l'index dans un premier temps à son authentificateur et ce dernier recherche en mémoire les éléments stockés précédemment en relation avec l'index IDS, c'est-à-dire (KS, KSZ) chiffrées par la clé secrète KB de l'élément de sécurité.
Lors d'une étape E40, l'élément de sécurité SEB reçoit les données IDS, et AL_A, et complète dans sa mémoire la ligne du tableau de référencement TABSB des sessions en cours en y ajoutant AL_A. L'état de son tableau est alors le suivant :
IDS KS KSZ AL A
Lors d'une étape E41, l'élément de sécurité de la machine B chiffre cet aléa avec la clé de session KS et le renvoie à l'application (ou à l'authentificateur). Lors d'une étape E42, l'élément de sécurité SEB génère également un aléa pour cette session, AL_B. Il ajoute cet aléa dans son tableau de référencement TABSB, et le renvoie à l'application (ou à l'authentificateur). L'état de son tableau est alors le suivant :
IDS KS KSZ AL B AL A Naturellement, selon une variante, les étapes E4 et E40 pourraient être avantageusement concaténées, ce qui permettrait notamment de gagner un échange avec l'élément de sécurité. Il en est de même des étapes E41 et E42.
Lors d'une étape E32, l'application B envoie les données IDS, AL_A chiffré par KS et AL_B à l'application A. L'application A (via l'authentificateur) relaie ces données (IDS,
{AL_A}KS, AL_B ) à son élément de sécurité SEA au cours d'une étape E21. Au cours d'une étape Eli, l'élément de sécurité de la machine A, SEA, consulte son tableau de référencement des sessions en cours (s'il y en a plusieurs) et détermine (via l'index IDS) la ligne de la session concernée, puis ajoute AL_B dans le tableau ; l'état de son tableau est alors le suivant :
IDS KS KSZ AL A AL B
Puis lors de l'étape Eli, SEA déchiffre l'aléa chiffré reçu {AL_A}Ks ; si le résultat trouvé est égal à AL_A dans le tableau, le procédé continue ; SEA retourne un message d'acquittement au cours d'une étape E12 successive à l'authentificateur et/ou l'application A. Sinon le procédé est interrompu et les deux machines ne pourront pas s'authentifier mutuellement. Cet acquittement de l'élément de sécurité SEA indique que la vérification de AL_A chiffré par la machine B est positive. A partir de ce moment, l'élément de sécurité SEA sait que la machine B détient la bonne clé de session KS de session pour l'authentification (et également, selon ce mode de réalisation, la bonne clé KSZ pour le chiffrement).
Lors d'une étape E13, l'élément de sécurité génère une clé de chiffrement KC qui est issu d'un traitement des données KSZ (donnée secrète), AL_A et AL_B (aléas); selon un mode de réalisation, la génération consiste à hacher AL_A concaténé avec AL_B puis chiffrer le résultat par KSZ, pour obtenir KC.
Selon une variante, moins sécurisée, la clé de session KS est utilisée comme donnée secrète au lieu de la clé KSZ.
Selon une variante, c'est l'authentificateur qui reçoit les données en provenance de l'élément de sécurité et retourne à l'application A l'acquittement ainsi que IDS, KC, et AL_B chiffré par la clé de session. Dans ce cas, l'acquittement de l'authentificateur A à l'application A lui indique que l'authentification de la machine B est positive. L'application A pourra par conséquent utiliser KC pour chiffrer les données vers l'application B. Lors d'une étape E14, l'élément de sécurité SEA chiffre AL_B avec KS et renvoie le résultat à l'application (ou à l'authentificateur).
Naturellement, selon une variante, les étapes E12, E13 et E14 pourraient être concaténées, ce qui permettrait notamment de gagner deux échanges avec l'élément de sécurité.
Lors d'une étape E24, l'application A transmet à l'application B les informations IDS, OK, {AL_B}KS. L'application B interprète, au cours de l'étape E33 le champ "OK" comme indiquant que la machine A a bien authentifié la machine B. L'application B (ou l'authentificateur) relaie ensuite ces données (IDS, {AL_B}KS ) à son élément de sécurité SEB.
Au cours d'une étape E43, l'élément de sécurité de la machine B, SEB, consulte son tableau de référencement des sessions en cours (s'il y en a plusieurs) et détermine (via l'index IDS) la ligne de la session concernée qui prend la forme :
IDS KS KSZ AL A AL B
Puis SEB déchiffre l'aléa chiffré reçu {AL_B}Ks; si le résultat trouvé est égal à AL_B dans le tableau, le procédé continue : SEB retourne un message d'acquittement au cours d'une étape E44 successive à l'authentificateur et/ou l'application A. Sinon le procédé est interrompu et les deux machines ne pourront pas s'authentifier mutuellement. Cet acquittement de SEB indique que la vérification de AL_B chiffré par la machine A est positive. A partir de ce moment, SEB sait que la machine A détient la bonne clé de session KS de session pour l'authentification (et selon ce mode de réalisation, la bonne clé de session KSZ pour le chiffrement).
Lors d'une étape E45, l'élément de sécurité SEB génère une clé de chiffrement KC qui est issue d'un traitement des données KSZ, AL_A et AL_B ; selon un mode de réalisation, la génération consiste à hacher AL_A concaténé avec AL_B puis chiffrer le résultat par KSZ, pour obtenir KC. La clé KC obtenue à cette étape est identique à celle obtenue à l'étape E13. Selon une variante, c'est l'authentificateur de B qui reçoit les données en provenance de l'élément de sécurité et retourne à l'application B l'acquittement ainsi que IDS et KC. L'acquittement de l'authentificateur B à l'application B lui indique dans ce cas que l'authentification de la machine A est positive.
L'application B pourra par conséquent utiliser KC pour chiffrer les données vers l'application A sans avoir recours à l'élément de sécurité. En particulier, pour la session d'authentification qui vient de s'achever, l'élément de sécurité n'utilise plus le tableau de référencement des sessions en cours. En particulier, s'il n'y a pas d'autre session d'authentification en cours d'établissement, le tableau peut être effacé.
Naturellement, selon une variante, les étapes E44 et E45 pourraient être concaténées, ce qui permettrait notamment de gagner un échange avec l'élément de sécurité. Au cours d'une étape E36, l'application B envoie un acquittement sous la forme d'un message (IDS, OK) à l'application A. L'application A interprète le champ "OK" comme indiquant que la machine B a authentifié la machine A.
Optionnellement, l'application A (resp. B) relaie les informations (IDS, OK) à son authentificateur, pour qu'il mette à jour sa machine d'état.
Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention.

Claims

Revendications
1. Procédé de communication entre deux dispositifs (A,B) auxquels sont associés respectivement :
deux éléments de sécurité (SEA, SEB) comportant des clés secrètes de sécurité (ΚΑ,ΚΒ) respectives,
deux authentificateurs (AUA, AUB),
le procédé comportant une étape d'authentification mutuelle des deux dispositifs (E10-E14, E20-25, E30-36, E40-E45), mise en œuvre par les deux authentificateurs (AUA, AUB) faisant appel à leurs éléments de sécurité respectifs (SEA, SEB) pour déchiffrer une clé de session (KS)..
Procédé de communication selon la revendication 1, caractérisé en ce que l'étape d'authentification mutuelle comporte :
- une étape d'obtention (E0), par les deux authentificateurs (AUA, AUB) des deux dispositifs (A,B), de la clé de la session (KS) chiffrée par la clé secrète (KA, KB) de leur élément de sécurité respectif (SEA, SEB).
- une étape de transmission (El, E2) par chaque authentificateur à son élément de sécurité respectif de la clé de session (KS) chiffrée par la clé secrète (KA, KB) de l'élément de sécurité respectif ;
- une étape de déchiffrement (E3, E4), par les éléments de sécurité respectifs, de la clé de session (KS).
Procédé de communication selon la revendication 1, caractérisé en ce que l'étape d'authentification mutuelle comporte en outre :
- une étape d'obtention (E0), par les deux authentificateurs (AUA, AUB) des deux dispositifs (A,B), d'une clé initiale de chiffrement (KSZ) chiffrée par la clé secrète de sécurité (KA, KB) de leurs éléments de sécurité respectifs (SEA, SEB).
- une étape de transmission (El, E2) par chaque authentificateur à son élément de sécurité respectif, de la clé initiale de chiffrement (KSZ) chiffrée par la clé secrète (KA, KB) de l'élément de sécurité respectif ; une étape de déchiffrement (E3, E4), par les éléments de sécurité respectifs, de la clé initiale de chiffrement (KSZ).
Procédé de communication selon la revendication 1, le procédé comportant les étapes suivantes :
- transmission (E20), du premier dispositif (A) au second dispositif (B), d'une première donnée de vérification (AL_A) générée (E10) par l'élément de sécurité du premier dispositif (SEA) ;
- réception (E30) par le second dispositif (B) de la première donnée de vérification (AL_A) ;
- transmission (E32), du second dispositif (B) au premier dispositif (A), d'une seconde donnée de vérification (AL_B) générée (E42) par l'élément de sécurité du second dispositif (SEB) et de la première donnée de vérification ({AL_A}KS) chiffrée (E41) par l'élément de sécurité du second dispositif (SEB) à l'aide d'une clé de session (KS) ;
réception (E21) par le premier dispositif (A) de la seconde donnée de vérification (AL_B) et de la première donnée de vérification ({AL_A}Ks) chiffrée par l'élément de sécurité du second dispositif ;
authentification (Eli, E12) du second dispositif (B) par le premier dispositif (A) à l'aide de la première donnée de vérification ({AL_A}KS) chiffrée.
- génération (E13) par l'élément de sécurité du premier dispositif (A) d'une première clé de chiffrement (KC) pour l'échange de données chiffrées entre les deux dispositifs (A, B) sur la session ;
- transmission (E24), du premier dispositif au second dispositif, de la seconde donnée de vérification ({AL_B}KS) chiffrée (E14) par l'élément de sécurité du premier dispositif à l'aide de ladite clé de session (KS);
- authentification (E43, E44) du premier dispositif (A) par le second dispositif (B) à l'aide la seconde donnée de vérification ({AL_B}Ks) chiffrée ; - génération (E45), par l'élément de sécurité du second dispositif (B) d'une seconde clé de chiffrement (KC) pour l'échange de données chiffrées entre les deux dispositifs sur la session, ladite seconde clé de chiffrement étant identique à la première clé de chiffrement (KC).
Procédé de communication selon la revendication 4, caractérisé en ce que la clé de chiffrement (KC) est générée par un élément de sécurité en utilisant les données de vérification (AL_A, AL_B) et au moins une donnée secrète (KS, KSZ).
Procédé de communication selon la revendication 5, caractérisé en ce que la donnée secrète est la clé de session (KS).
Procédé de communication selon la revendication 5, caractérisé en ce que la donnée secrète est la clé initiale de chiffrement (KSZ).
Procédé de communication selon la revendication 1, caractérisé en ce qu'il comporte en coutre une étape d'obtention, respectivement, par chaque dispositif (A,B), d'un identifiant de la session (IDS) correspondant à la clé de session (KS).
Système de communication comprenant :
- un serveur (SAP) comprenant un module de fourniture, pour chaque dispositif, d'au moins la clé de session (KS) chiffrée par une clé secrète (KA, KB) connue seulement de l'élément de sécurité du dispositif;
- au moins deux dispositifs (A,B) comportant respectivement :
- un éléments de sécurité (SEA, SEB) comportant une clé secrète de sécurité (ΚΑ,ΚΒ),
- un authentificateur (AUA, AUB) comportant
- un module d'obtention (El, E2, E3, E4) de la clé de session (KS) chiffrée par la clé secrète (KA, KB) de son élément de sécurité respectif (SEA, SEB)
- un module d'authentification mutuelle (AUA, AUB) faisant appel à son élément de sécurité respectif (SEA, SEB) pour déchiffrer la clé de session (KS).
10. Programme d'ordinateur comportant des instructions de code pour la mise en œuvre du procédé de communication conforme à la revendication 1, lorsque celle-ci est exécutée par un processeur.
PCT/FR2016/052713 2015-11-04 2016-10-20 Communication entre deux éléments de sécurité insérés dans deux objets communicants WO2017077211A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1560565 2015-11-04
FR1560565A FR3043291A1 (fr) 2015-11-04 2015-11-04 Communication entre deux elements de securite inseres dans deux objets communicants

Publications (1)

Publication Number Publication Date
WO2017077211A1 true WO2017077211A1 (fr) 2017-05-11

Family

ID=55806425

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/052713 WO2017077211A1 (fr) 2015-11-04 2016-10-20 Communication entre deux éléments de sécurité insérés dans deux objets communicants

Country Status (2)

Country Link
FR (1) FR3043291A1 (fr)
WO (1) WO2017077211A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111935166A (zh) * 2020-08-18 2020-11-13 杭州萤石软件有限公司 通信认证方法、系统、电子设备、服务器及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0631408A2 (fr) 1993-05-25 1994-12-28 Siemens Aktiengesellschaft Procédé d'authentification entre deux dispositifs électroniques

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0631408A2 (fr) 1993-05-25 1994-12-28 Siemens Aktiengesellschaft Procédé d'authentification entre deux dispositifs électroniques

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Chapter 12: Key Establishment Protocols ED - Menezes A J; Van Oorschot P C; Vanstone S A", 1 October 1996 (1996-10-01), XP001525012, ISBN: 978-0-8493-8523-0, Retrieved from the Internet <URL:http://www.cacr.math.uwaterloo.ca/hac/> *
"Chapter 13: Key Management Techniques ED - Menezes A J; Van Oorschot P C; Vanstone S A", 1 October 1996 (1996-10-01), XP001525013, ISBN: 978-0-8493-8523-0, Retrieved from the Internet <URL:http://www.cacr.math.uwaterloo.ca/hac/> *
ENDER YUKSEL ET AL: "A secure key establishment protocol for zigbee wireless sensor networks", COMPUTER AND INFORMATION SCIENCES, 2009. ISCIS 2009. 24TH INTERNATIONAL SYMPOSIUM ON, IEEE, PISCATAWAY, NJ, USA, 14 September 2009 (2009-09-14), pages 340 - 345, XP031549459, ISBN: 978-1-4244-5021-3 *
KIM THUAT NGUYEN ET AL: "Survey on secure communication protocols for the Internet of Things", AD HOC NETWORKS, vol. 32, 1 September 2015 (2015-09-01), AMSTERDAM, NL, pages 17 - 31, XP055288290, ISSN: 1570-8705, DOI: 10.1016/j.adhoc.2015.01.006 *
NGUYEN K.T. ET AL.: "Survey on secure communication protocols for the Internet of Things", AD HOC NETWORKS, vol. 32, 1 September 2015 (2015-09-01), pages 17 - 31

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111935166A (zh) * 2020-08-18 2020-11-13 杭州萤石软件有限公司 通信认证方法、系统、电子设备、服务器及存储介质

Also Published As

Publication number Publication date
FR3043291A1 (fr) 2017-05-05

Similar Documents

Publication Publication Date Title
EP1903746B1 (fr) Procédé de sécurisation de sessions entre un terminal radio et un équipement dans un réseau
EP2820795B1 (fr) Procede de verification d&#39;identite d&#39;un utilisateur d&#39;un terminal communiquant et systeme associe
EP3238474B1 (fr) Procédé de sécurisation de transactions sans contact
EP2614458B1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP2249543B1 (fr) Procédé pour autoriser une connexion entre un terminal informatique et un serveur source
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
EP2912594B1 (fr) Procédé de fourniture d&#39;un service sécurisé
EP2242229A1 (fr) Procédé pour authentifier un terminal mobile client auprès d&#39;un serveur distant
WO2006106250A1 (fr) Communication securisee entre un dispositif de traitement de donnees et un module de securite
FR2970612A1 (fr) Procede d&#39;authentification d&#39;un premier equipement de communication par un second equipement de communication
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
WO2017077211A1 (fr) Communication entre deux éléments de sécurité insérés dans deux objets communicants
WO2006072746A1 (fr) Procede de securisation d’une communication entre une carte sim et un terminal mobile
EP2471237B1 (fr) Dispositif électronique nomade configuré pour établir une communication sans fil sécurisé
EP3667530A1 (fr) Accès sécurise à des données chiffrées d&#39;un terminal utilisateur
WO2008053095A1 (fr) Entite electronique portable et procede de blocage, a distance, d&#39;une fonctionnalite d&#39;une telle entite electronique portable
KR100892941B1 (ko) 이동통신단말기를 이용한 보안처리 방법
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
FR2948839A1 (fr) Procede d&#39;authentification securisee d&#39;acces a des donnees chiffrees
WO2013140078A1 (fr) Procede de generation et de verification d&#39;identite portant l&#39;unicite d&#39;un couple porteur-objet

Legal Events

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

Ref document number: 16806215

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16806215

Country of ref document: EP

Kind code of ref document: A1