FR3043291A1 - COMMUNICATION BETWEEN TWO SECURITY ELEMENTS INSERTED IN TWO COMMUNICATING OBJECTS - Google Patents

Abstract

The invention relates to a method of communication between two devices (A, B) to which are respectively associated two security elements (SEA, SEB) comprising respective secret security keys (KA, KB), the method comprising an authentication step of the two devices using a session key (KS). The method is characterized in that this step is preceded by a step of obtaining (E0) by the two devices (A, B) of the session key (KS) encrypted by the secret security key (KA, KB ) of their respective security elements (SEA, SEB).

Description

Communication between two security elements inserted in two communicating objects

TECHNICAL FIELD 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.

State of the art

The direct mode of communication between two machines, known as machine-to-machine (M2M), also known as Peer-to-Peer, is becoming more and more common, for example in the context of a machine. communication between the mobile phone and the on-board computer of a user's automobile. These communications are now vulnerable to hacker attacks that could take control of such an object (in this example, the vehicle). A need therefore exists to secure peer-to-peer communications between machines. For this purpose, certain machine-to-machine radio communication standards have encryption and key establishment functions between the two communicating entities. For example, 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. However, there are cases of use (in the fields of automobile, health, etc.) where it is necessary to ensure a high level of security. The hardware integration of a communication module (for example ZigBee, NFC, etc.) into a security element, for example a SIM card (of the English Subscriber Identification Module), is known. This type of architecture offers a high level of security. However, such security features including radio technology are more expensive than conventional security features. In addition, if several services are targeted, such 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.

It is therefore desirable to benefit from a technology that is both generic and ensures the maximum level of security, that is to say that offered by a security element.

It is also known a method of authentication between two electronic devices, provided or not with a security element, based on the generation of two random numbers, transmitted on both devices and encrypted on each of them by a secret key known from both, so that the comparison of the two cryptograms ensures the mutual identification of the two devices. European Patent EP0631408 gives an example of such a method. However such a system is not entirely satisfactory, because beyond mutual authentication, the two electronic devices do not have the assurance of being able to exchange data with a high level of security. In addition, these principles are not adapted to make the two devices interoperable in a multiservice environment, since the same secret key is used for all the services implemented by the devices. The invention offers a solution that does not have the drawbacks of the state of the art. The invention For this purpose, according to a functional aspect, the subject of the invention is a method of communication between two devices to which two security elements are respectively associated with respective secret security keys, the method comprising a mutual authentication step. both devices using a session key, characterized in that this step is preceded by a step of obtaining by the two devices the key of the session encrypted by the secret security key of their respective security elements.

Mutual authentication is understood to mean all the steps that are conventionally performed so that machine A authenticates machine B and vice versa. Advantageously according to the invention, 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. Thus, only the devices (A, B) initially targeted by the server can establish the communication session, since they will be the only ones able to decrypt the session key, by means of their secret key, and therefore use this session key .

Advantageously, compared to the state-of-the-art systems, only the authorized devices, that is to say those which have received from a service server the session key encrypted by their own secret key, will be able to use the service between them. In addition, the use of the secret key specific to each device makes it possible to encrypt session keys for different services. These principles are usable whatever the radio technology and advantageously adaptable as to the level of security achieved: the encryption can be performed by a simple key associated with the microprocessor of the object, or by a security element of SIM card type, passing by all the intermediate possibilities.

According to a particular embodiment of the invention, a method as described above is further characterized in that it comprises the following steps: - transmission, from the first device to the second device, a first data verification generated by the security element of the first device; reception by the second device of the first verification data item; - transmitting, from the second device to the first device, a second verification data generated by the security element of the second device and the first verification data encrypted by the security element of the second device by means of a session key; - Receiving by the first device of the second verification data and the first verification data encrypted by the security element of the second device; - Authentication of the second device by the first device using the first encrypted verification data; - Generation by the security element of the first device of a first encryption key for the exchange of encrypted data between the two devices on the session; - transmitting, from the first device to the second device, the second verification data encrypted by the security element of the first device using said session key; - Authentication of the first device by the second device using the second encrypted verification data; - Generating, by the security element of the second device, a second encryption key for the exchange of encrypted data between the two devices on the session, said second encryption key being identical to the first encryption key.

The session key is necessary, according to this embodiment, for the mutual authentication of the two devices: if the first security element (SEA) is able to decrypt the randomly previously issued, 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). Symmetrically, if the second security element (SEB) succeeds in deciphering the previously generated randomness, 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).

According to a variant of this particular mode of implementation of the invention, 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 the same time. less a secret datum.

According to this variant, 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. Such 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. Preferably, this secret data has been encrypted by the secret key of the security element.

Thanks to the advantageous use of the two hazards and the secret data, 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. In addition, it is not necessary to implement additional exchanges, in addition to the exchanges required for prior authentication.

According to another variant of this variant, a method as described above is further characterized in that the secret data is the session key.

Advantageously according to this mode, 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 devices in question can decrypt it. The use of the session key and the two hazards is particularly interesting to obtain a robust construction of the key.

According to a second variant, which can be implemented alternatively or cumulatively with the previous one, a method as described above is further characterized in that the steps of generating an encryption key for the exchange of encrypted data between the two devices on the session are preceded by a step of obtaining, by each device, an initial encryption key independent of the session key and protected (encrypted) by a secret key known only to its security element and in that the secret data is said initial encryption key

According to this variant, 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. Thus, only the devices (A, B) originally targeted by the server will be able to communicate, since they will be the only ones able to decipher it. In this mode, 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.

According to a second particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous one, 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. One can thus imagine a first service running between two machines A and B on a Wi-Fi session, a second service running between the two machines A and B in Zigbee, and a third service running in NFC between In this case, the device A will have every interest in storing three distinct session identifiers.

If the device must process in parallel several session institutions, the session identifier can advantageously serve as an index in a table stored for example in the security element, which gives quick access to the identifier of the service and the session in the service being set up. Thus 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 session keys so that they can be accessed quickly and unambiguously by the two machines.

According to another functional aspect, the invention also relates to a key delivery method for the exchange of data between a first and a second device according to the communication method as described above, characterized in that it comprises the following steps on a communication server: - obtaining an encrypted session key using a secret key; transmission to the devices of the encrypted session key by a secret key known only to their respective security elements.

According to another material aspect, the invention also relates to a communication server comprising a module for providing, for at least one device equipped with a security element, at least one session key encrypted by a secret key known only to said security element.

The term 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 any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, 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. .).

According to another material aspect, the invention also relates to a communication system comprising: a server as described above; two devices which are respectively associated two security elements comprising respective secret security keys, the two devices being able to mutually authenticate using a session key, the system being characterized in that the two devices further comprise a module for obtaining the key of the session encrypted by the secret key of their respective security elements and a module for decrypting said session key using their respective secret keys. The security element of these devices may be a SIM card.

It is recalled that a 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. 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. By "trusted environment" (in English "TEE" for Trusted Execution Environment), it refers here to a secure area and isolated from other environments executions, located in a device (cellphone type), ensuring that Sensitive data is stored, processed and protected in a trusted environment. The applications in the TEE, called Trusted Applications (TA), or trusted applications, benefit from a set of security services such as secure storage of data, management of keys and cryptographic algorithms, etc.

According to another material aspect, the invention also relates to a communication device as described above, characterized in that the device is a mobile phone.

According to another material aspect, the invention also relates to a computer program adapted to be implemented in a device and 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 method of establishing a communication session.

According to another material aspect, 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.

According to another material aspect, 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.

These device, server, system and computer programs have characteristics and advantages similar to those described above in connection with the communication method.

According to still another material aspect, the invention relates to a recording medium readable by a data processor on which is recorded one of the programs comprising program code instructions for the execution of the steps of the one methods defined above. The invention will be better understood on reading the description which follows, given by way of example and with reference to the accompanying drawings.

The figures:

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.

Detailed description of an exemplary embodiment illustrating 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.

According to this example, 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. For example, 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. Note that 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 of Near Field Communication (NFC) type, a technology based mainly on International Standard Organization (ISO) 14443, to allow wireless information exchange between two peripherals a short distance apart, 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.

Each of the two machines or communicating objects (A, B) 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 (resp.AUA and AUB), 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). By "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. 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). In the case of a terminal supporting Android-type applications (it is recalled that an Android application is a mobile application specifically developed for mobile terminals using the Android application system developed by Google), applications can also be used. 'run with a security mainly based on software, in the Android terminal itself (from version 4.4. "KitKat"), thanks to the technology "HCE" ("Host Card Emulation") that allows NFC communication with other equipment. More generally, 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.

Subsequently, the terms "security element" and "SIM card" will be used interchangeably.

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. 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 the session keys in both machines.

The trusted server (SC) has the knowledge of the secret keys installed in the security elements of the two devices. In the example described here, 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). In another example, 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.

According to one embodiment of the invention, which will be detailed later in support of FIG. 2, the application server is in charge of delivering session keys on both devices. 1) The application server transmits initially to the trusted server a message comprising the following information: the identity of the machine A and the identity of the machine B; - the session key (KS) which will then be used by the two machines to authenticate each other; - Possibly an index (IDS) 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. Note that 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. - optionally an initial encryption key (KSZ) which will be used to generate the final encryption key (KC) which will be used by both machines to exchange data confidentially on the session. 2) The trusted server (SC) 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; 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). 3) The application server delivers to the machine A (respectively B) these data encrypted by the secret key of its security element SEA (or SEB). Any mode of communication is possible for this communication (SMS, HTTP over 3G / 4G, etc ...). 4) The application in the machine A, APA (respectively B, APB) stores (preferentially according to this embodiment, in its authenticator), the previously received elements. At the end of this step, 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 an EO step, as previously explained in support of FIG. 1, 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).

According to this embodiment, 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 other communication sessions that can be established between the two machines, and also to reference the encrypted session keys so that they can be accessed by both 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 preferable, for security reasons, for this key to be independent of the session key, which in turn is used for authentication.

According to this embodiment, 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. In the example of Figure 2, the authenticator (AUTH) and the application (AP) are merged.

In this example, 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.

During a step El, 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.

According to a variant, 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.

During a symmetrical step E2, 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.

It should be noted that in an embodiment where 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. Especially if the security element is a SIM card, it is not multitasking in its operation. It does not need to receive IDS or add it in its response, because the authenticator knows that the answer necessarily refers to the last command.

During a step E3, 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):

According to a variant, if there were several trusted servers associated with the application server, there could be several keys KA, it would then be necessary to pass a secret key identifier KA. This variant is not described further.

During a 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):

During a step E10, 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:

Then 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.

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.

According to one variant, 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.

During a step E40, 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:

In 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).

During a step E42, the security element SEB also generates a hazard for this session, AL_B · It adds this hazard in its referencing table TABSB, and returns it to the application (or the authenticator). The state of his painting is then the following:

Naturally, according to one variant, the 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.

During a step E32, 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 these data (IDS, {AL_A} ks, AL_B ) at its security element SEA during a step E21.

During a step Eli, 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:

Then during step Eli, SEA decrypts the encrypted random received {AL_A} ks; 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).

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.

According to one variant, less secure, the session key KS is used as secret data instead of the key KSZ.

According to one variant, it is 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. In this case, 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.

In a step E14, the security element SEA encrypts AL_B with KS and returns the result to the application (or authenticator).

Naturally, according to one variant, the steps E12, E13 and E14 could be concatenated, which would notably make it possible to gain two exchanges with the security element.

During a step E24, 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.

During a step E43, 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:

Then SEB decrypts the received encrypted random {AL_B} ks; 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).

During a step E45, 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.

According to one variant, 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.

Naturally, according to one variant, steps E44 and E45 could be concatenated, which would notably make it possible to gain an exchange with the security element.

During a step E36, 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.

Optionally, the application A (resp., B) relays the information (IDS, OK) to its authenticator, so that it updates its state machine.

It goes without saying that the embodiment which has been described above has been given for purely indicative and not limiting, and that many modifications can be easily made by those skilled in the art without departing from the scope of the invention.

Claims (10)

claims A method of communication between two devices (A, B) to which are respectively associated two security elements (SEA, SEB) comprising respective secret security keys (ΚΑ, ΚΒ), the method comprising a step of mutual authentication of the two devices using a session key (KS), characterized in that this step is preceded by a obtaining step (EO) by the two devices (A, B) of the session key (KS) encrypted by the secret security key (KA, KB) of their respective security elements (SEA, SEB). 2. The communication method as claimed in claim 1, the method comprising the following steps: transmission (E20) of the first device (A) to the second device (B) of a first verification data item (AL_A) generated (E10) by the security element of the first device (SEA); - receiving (E30) by the second device (B) of the first verification data (AL_A); - transmitting (E32), the second device (B) to the first device (A), a second verification data (AL_B) generated (E42) by the security element of the second device (SEB) and the first data item; verification ({AL_A} ks) encrypted (E41) by the security element of the second device (SEB) using a session key (KS); receiving (E21) by the first device (A) of the second verification data (AL_B) and the first verification data ({AL_A} ks) encrypted by the security element of the second device; - Authentication (Eli, E12) of the second device (B) by the first device (A) using the first verification data ({AL_A} ks) encrypted. - Generation (E13) by the security element of the first device (A) of a first encryption key (KC) for the exchange of encrypted data between the two devices (A, B) on the session; - transmitting (E24), from the first device to the second device, the second verification data item ({AL_B} ks) encrypted (E14) by the security element of the first device using said session key (KS) ; - Authentication (E43, E44) of the first device (A) by the second device (B) using the second verification data ({AL_B} ks) encrypted; - generation (E45), by the security element of the second device (B) of a second encryption key (KC) for the exchange of encrypted data between the two devices on the session, said second encryption key being identical to the first encryption key (KC). 3. The communication method as claimed in claim 2, characterized in that the encryption key (KC) is generated by a security element by using the verification data (AL_A, AL_B) and at least one secret data item (KS, KSZ). . 4. Communication method according to claim 3, characterized in that the secret data is the session key (KS). 5. The communication method as claimed in claim 3, characterized in that the steps of generating (E13, E45) an encryption key (KC) for exchanging encrypted data between the two devices on the session are preceded by a step of obtaining (EO) by each device (A, B), an initial encryption key (KSZ) independent of the session key (KS) and encrypted by a secret key (KA, KB) known only to its security element (SEA, SEB) and in that the secret data is said initial encryption key (KSZ). 6. A communication method according to claim 1, characterized in that it comprises in step a step of obtaining, respectively, each device (A, B), a session identifier (IDS) corresponding to the key. session (KS). 7. Key delivery method for the exchange of data on a session between a first and a second device according to the method of claim 1, characterized in that it comprises the following steps on a communication server: an encrypted session key (KS) ({KS} ka, (KS) kb) using a secret key (KA, KB); - transmission to the devices (A, B) of the encrypted session key by a secret key (KA, KB) known only to their respective security elements. 8. Communication system comprising: - a communication server (SAP) comprising a supply module, for at least one device equipped with a security element (SEA, SEB), of at least one session key (KS) encrypted by a secret key (KA, KB) known only to said security element; two devices (A, B) to which are respectively associated two security elements (SEA, SEB) comprising respective secret security keys (ΚΑ, ΚΒ), the system being characterized in that the two devices further comprise: - a obtaining module (E1, E2, E3, E4) of the session key (KS) encrypted by the secret key (KA, KB) of their respective security elements (SEA, SEB); a module for decrypting said session key using their respective secret keys; an authentication module to allow the two devices to mutually authenticate using the session key (KS) provided by the communication server (SAP) 9. Computer program comprising code instructions for implementing the communication method according to claim 1, when the latter is executed by a processor. A computer program comprising code instructions for implementing the key delivery method according to claim 7, when executed by a processor.