EP2153613A2 - Method for securing information exchange, and corresponding device and computer software product - Google Patents

Method for securing information exchange, and corresponding device and computer software product

Info

Publication number
EP2153613A2
EP2153613A2 EP08750344A EP08750344A EP2153613A2 EP 2153613 A2 EP2153613 A2 EP 2153613A2 EP 08750344 A EP08750344 A EP 08750344A EP 08750344 A EP08750344 A EP 08750344A EP 2153613 A2 EP2153613 A2 EP 2153613A2
Authority
EP
European Patent Office
Prior art keywords
entity
session
secure
keys
tls
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08750344A
Other languages
German (de)
French (fr)
Inventor
Pascal Urien
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GROUPE DES ECOLES DE TELECOMMUNICATIONS - ECOLE NA
Original Assignee
Groupe de Ecoles de Telecommunications Ecole National Superieure des Telecommunications
Groupe des Ecoles de Telecommunications Ecole National Superieure des Telecommunications
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 Groupe de Ecoles de Telecommunications Ecole National Superieure des Telecommunications, Groupe des Ecoles de Telecommunications Ecole National Superieure des Telecommunications filed Critical Groupe de Ecoles de Telecommunications Ecole National Superieure des Telecommunications
Publication of EP2153613A2 publication Critical patent/EP2153613A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority

Definitions

  • the present invention relates to the field of information exchange management performed between two entities of a communication network.
  • the present invention relates to securing such exchanges.
  • the implementation of a secure connection between two entities of a communication network requires the initiation of a secure session based on either the SSL protocol or the TLS protocol.
  • the two entities use mechanisms that are supposed to ensure that the created session can not be hacked or spied.
  • the operation of the SSL and TLS protocols is described later. Although this description is more specifically dedicated to the TLS protocol, it also applies to the SSL protocol.
  • the TLS protocol is organized on the basis of a set of five cooperating software entities: APPLICATION, HANDSHAKE, CCS, ALERT and RECORD.
  • entity “APPLICATION” refers to a software application that wishes to implement a secure communication session (layer 7 of the OSI model).
  • Entities “HANDSHAKE”, “CCS”, “ALERT” and “RECORD” are entities that are implemented as part of a TLS application, a detailed description of which will be found under the reference “RFC 2246" through the IETF Committee (" Internet Engineering Task Force "for” Internet Engineering Task Force ").
  • Such an application of the TLS protocol is carried out at layer 5 of the OSI model.
  • the layer managed by the entity "RECORD” (also called “RECORD” layer) carries the messages produced by the entities “APPLICATION” "HANDSHAKE” "CCS” and “ALERT", using a 5-byte header that specifies the entity that generates the message, the version of the TLS protocol used, and the length of the message.
  • the messages themselves also include a header that indicates the type of the message and the length of the associated data.
  • the structure of the "APPLICATION” messages is not defined by the TLS standard. Indeed, each application exchanges messages whose structure is defined by the application protocol, such as in the context of Hypertext Transfer Protocol Secured (HTTPS) protocol messages for "secure hypertext transfer protocol”.
  • HTTPS Hypertext Transfer Protocol Secured
  • an "APPLICATION" application uses the services offered by the TLS protocol which achieves the confidentiality (encryption) and the confidentiality of the data transported by means of the TCP (transmission control protocol) protocol for control protocol transmissions ") acting at the transport layer.
  • the implementation of the secure channel by TLS is carried out in two steps, an authentication and key calculation phase, followed, if successful, by a phase of use of a secure communication channel, which uses the set of keys previously determined.
  • the "HANDSHAKE” layer entity (also known as the “HANDSHAKE” layer) performs the authentication and key calculation procedures. There are two modes of authentication the complete mode (called “FuIl Session”) and a quick mode (called “Session Resumption”). These two modes will be more precisely described later.
  • the layer “HANDSHAKE” negotiates the encryption and integrity algorithms implemented by the entity of the RECORD layer (also called “RECORD” layer), which are identified by a number called “cipher_suite”.
  • the layer At the end of a successful authentication procedure, the layer
  • PRF Physical Random Function
  • the keys block parameter is a pair of two key pairs (KcRx, KiRx) and (KcTx, KiTx) used respectively for the encryption (prefix Kc) and the integrity (prefix Ki) of the received data (suffix Rx). and issued (suffix Tx).
  • the Change Cipher Spec (CCS) layer reports to the "RECORD” entity the changes to the security settings. It enables encryption and data integrity procedures, using the "keys_bloc" and "cipher_suite” parameters.
  • the entity of the ALERT layer reports errors detected by the entity “HANDSHAKE” (in case of authentication failure), or by the “RECORD” layer (detection of a lack of integrity, or an end of session).
  • the "RECORD" layer performs four types of operations: fragmentation of the data into blocks whose maximum size is 2 14 bytes; optional compression of the data; this service is generally not insured; a signature generation (based on the HMAC algorithm, defined by RFC 2104); - data encryption.
  • the messages exchanged between the application layer and the TCP layer are encrypted and decrypted by the "RECORD" layer using a set of two key pairs (KcRx, KiRx) and (KcTx, KiTx) previously described.
  • the messages received by the "RECORD" layer are encrypted by the key KcRx ((M) KcRx) and provided with an HMAC signature (KiRx, M) associated with the key KiRx.
  • KcRx (M) KcRx
  • HMAC signature KerRx, M
  • the messages sent by the application layer are encrypted by the "RECORD" layer using the KcTx key ((M) KcTx) and provided with an HMAC signature (M 5 KiTx) associated with the KiTx key.
  • a "MESSAGE” sent / received by an entity such as "HANDSHAKE” or “APPLICATION” is provided with a header comprising three parameters: type, version , length.
  • the set “MESSAGE”, “HMAC signature” and “stuffing bytes” is encrypted using the algorithm negotiated during the authentication phase and a key Kc.
  • the signature "HMAC” is calculated from the header, the "MESSAGE” and a frame number (seq_num) (initialized to the value 0 and incremented with each use of the layer "RECORD") according to the following relation :
  • the client entity verifies the validity of the server's certificate, extracts its public RSA key, and then sends it a value called "pre_master_secret” encrypted of this key.
  • the "master _secret” is calculated from the “Client-Random”, “Server-Random” and “pre-master-secret” elements.
  • the "CertificateVerify” message contains a signature made with the client's RSA private key, which proves the identity of the latter (his certificate present in the "Certifi- cate” message).
  • the client entity and the server entity have a new value "master _secret” from which the keys of the "keys_bloc" are deduced.
  • a "SessionID” parameter passed in the "ServerHello” message provides an index of the "master _secr and”.
  • the data generated by the "APPLICATION” layer is transported by the "RECORD” entity, which ensures the confidentiality and the integrity thereof by means of the keys Kc and Ki.
  • Keys_block PRF (master_secret, "key expansion", server _random ⁇ client _random).
  • the "Session Resumption” mechanism simplifies the exchange of information during a TLS session.
  • a first "FuIl Session” performs simple or mutual authentication of both ends (client and server) and produces a “master _secret”.
  • TLS stack i.e., the sequence of steps leading to the exchange information
  • the invention proposes a new solution that makes it possible to solve these disadvantages of the prior art, in the form of a method for producing security data, enabling the implementation of a secure session between a first and at least one second entity, according to a protocol for establishing secure sessions.
  • a method for producing security data comprises: a step of initialization of a third secure entity, linked to said first entity; a step of generating at least a portion of said security data within said third entity; a step of transmitting said security data from said third secure entity to said first entity.
  • the invention allows the production of such data within a third entity different from the first.
  • This third entity can be attached either mechanically to the first entity or through an interface of a network, such as a local area network.
  • the generation of the data enabling the implementation of the secure session is therefore no longer performed by the entity implementing the secure session, but by a third entity, thus avoiding the various attacks that can be conducted vis-à- vis of the first entity.
  • the method according to the invention thus makes it possible to replace the first entity during the production of secure session data.
  • Such a substitution authorizes the conduct of at least a part of the data definition operations allowing the establishment of the session within the third entity which can therefore take the place of the first and thus secure the procedure of creating the data at within a safe environment.
  • said third entity is a "JavaCard” type smart card.
  • the invention makes it possible to dissociate the device which is responsible for implementing the security protocol of the device wishing to have a secure connection.
  • the use of a "JavaCard" type smart card ensures that this entity responsible for implementing the security protocol is inviolable and completely secure.
  • An additional level of security, resulting from the work carried out by the inventors, is therefore added to the entire security protocol.
  • said secure session establishment protocol is the SSL protocol.
  • the invention supports the establishment of a secure session respecting the SSL protocol, which is one of the major protocols in this area.
  • said secure session establishment protocol is the TLS protocol.
  • said production method also comprises: a step of transmission, by said first entity, of at least one message intended for a "RECORD" layer implemented within said third entity; a step of reception, by said first entity, of at least one message coming from said "RECORD" layer; a step of calculating a set of keys by said third entity; a step of collecting said set of keys available from said first entity to said third entity; a step of recovering a secure communication session identifier.
  • the invention makes it possible to maintain the conformity of the existing installations by carrying out a transfer of messages instead of the execution of the production steps on the first entity, which may be subject to attacks.
  • the invention also relates to a device for producing security data, enabling the implementation of a secure session between a first and at least a second entity, according to a secure session establishment protocol.
  • a device for producing security data comprises: initialization means, attached to said first entity; means for generating at least a part of said data of security; means for transmitting said security data to said first entity.
  • such a device comprises means enabling it to implement the steps of the production method as described above.
  • said generation means and said transmission means are grouped together in a smart card.
  • Such a device according to the invention has means of resistance to malicious attacks.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • a computer program product comprises program code instructions for executing the production method as described above. 4 LIST OF FIGURES
  • FIG. 1 presents a block diagram of the method for producing secure data according to the invention
  • FIG. 2 illustrates an exemplary implementation of the production method within a security module according to the invention
  • FIG. 3 describes a mode of implementation of the production method by two entities using two security modules in a mode known as
  • FIG. 4 describes a mode of implementation of the production method by two entities using two security modules in a mode called
  • FIG. 5 also describes a mode of implementation of the production method by two entities using two security modules in a so-called “Session Resumption” mode;
  • FIG. 6 describes an architecture of a device for producing security data, also called a security module. DETAILED DESCRIPTION OF THE INVENTION
  • the invention thus makes it possible to solve the problems related to the intrinsic insecurity of the entities on which the SSL and TLS protocols are implemented.
  • these entities are, in general, servers running on proprietary operating systems or from the free world or personal computers of conventional users. While most of the time is given relatively broad trust in the "server” category, the personal computers of individual users do not have the same level of security as the servers and are therefore more often (but not exclusively) subject to the risks. attacks.
  • the communication session security protocols such as TLS and SSL perform their functions correctly, it is very likely that an attack on a workstation or a server entity using malicious software could occur. introduce into a "software stack" or modify operating system files.
  • the invention makes it possible to implement at least certain authentication steps in a third party entity of the entity that generally implements this authentication phase.
  • a third entity which is a device for producing security information according to the invention, is also called a "security module”. This entity puts then available the information necessary to continue the authentication session.
  • Such information can be, for example, the session keys (keys_bloc) or the "master_secret” (depending on the required security level) for software that needs secure information exchange through SSL / TLS protocols.
  • the general principle of the invention relies on delocalization, within a trusted entity, such as a security module, of at least some steps of a protocol, such as an authentication protocol, to enforce. Indeed, although the application data is exchanged between the client and server entities, the authentication phase is the most critical process and establishes the identity of both parties, verifies their certificates and calculates the cryptographic keys.
  • the invention differs from the techniques of the prior art, which implement smart cards, in that these prior mechanisms do not offer, within the card in question, a software execution, but a simple storage data such as certificates or keys.
  • An entity according to the invention does not contain, in its primary function, data, but a set of mechanisms allowing the execution, independently, of at least some steps of a secure protocol.
  • the method for producing secure data comprises: an initialization step (100) of the security module (for example a smart card), attached to a first entity (for example a personal computer); a step of generating (101) a portion of the security data within the security module; a step of transmitting (102) the securing data of the security module to the first entity.
  • an initialization step (100) of the security module for example a smart card
  • a first entity for example a personal computer
  • generating (101) a portion of the security data within the security module
  • a security module implementing the method according to the invention for the SSL / TLS protocol authentication steps. It is clear, however, that the invention is not limited to this particular application, but can also be implemented in many other fields, and for example in entities that could implement initialization or start-up mechanisms.
  • a smart card carrying means for executing computer programs (security module).
  • security module can for example be a "JavaCard” that is to say a smart card that integrates a Java virtual machine.
  • Such smart cards have the advantage of being resistant to attacks. This means that these cards have physical characteristics that drastically reduce the risks and possibilities of hacking. They are therefore particularly well suited for the implementation of secure procedures.
  • the method according to the invention makes it possible to "delocalize” the implementation of the SSL or TLS protocol within this security module.
  • the TLS stack (that is to say the sequence of steps of the process leading to the authentication) is entirely executed on the same computer and thus does not allow to separate the procedures of Authentication and exchange of information.
  • a security module implementing the method according to the invention therefore comprises original features that enable it to perform the authentication phase of the TLS protocol, and to transfer the right to an application to use the previously established secure tunnel. .
  • a security module implementing the method according to the invention performs the functions of client or TLS server entity.
  • the method according to the invention implements the entities "HANDSHAKE”, “ALERT”, “CCS” and “RECORD” described above.
  • FIG. 2 shows a security module (210) implementing the TLS protocol according to the production method of the invention and a user entity (200), that is to say an application (2000). ) comprising a subset of the TLS stack, namely the layers “RECORD” (2004) and “ALERT” (2002) and optionally the layers “CCS” (2003) and “HANDSHAKE” (2001).
  • the "RECORD” layer (2004) presents a communication interface with the "TCP” layer (2005).
  • such a security module provides a functional interface (220) which comprises eight commands: “SET-Credentials”, “Start”, “Process-TLS”, “GET-Keys_bloc”, “Compute-Keys_bloc” , “GET- Cipher_suite”, “GET-SessionID”, “GET-Master_secret”.
  • commands can be performed according to the ISO 7816 standard according to a coding commonly called “APDUs” (of the English “Application Protocol Data Unit” for "Data Unit (PDU) of the layer seven (Application) of the OSI model” ).
  • the security module (210) which implements the production method according to the invention comprises the entities necessary for the implementation of the method the "RECORD” (2104) and "ALERT” (2102) layers and optionally the "CCS” (2103) and "HANDSHAKE” (2101) layers.
  • the functional interface (220) allows the user entity (200) to call the security module (210) for the production of security data.
  • the role of the module that is to say its behavior client or server entity and the various parameters necessary for its operation, usually qualified letters of credit or "credentials" in English (X509 certificates, RSA private key) is enabled by SET-Credentials () command, SET-Credentials (role)
  • a "Start" command initializes a session
  • TLS since the security modules do not generally include a clock, it also informs the GMT time in the so-called UNIX format, that is to say a number of 32 bits which measures the number of seconds elapsed since January 1, 1970. .
  • TLS packets that is, messages generated by a RECORD entity, are transmitted to the security module using the Process-TLS (Record-Packets) command that returns one or more RECORD messages.
  • Record-Packets Process-TLS (Record-Packets)
  • the user of the services of the security module can then manage autonomously (without the help of the security module) his own layer RECORD. Indeed it knows the keys of the secure channel (keys_bloc) and the current value of the parameter seq_num equal to 1 (the value 0 was used for the calculation of HMAC integrity of the message FINISHED).
  • Compute-Keys_bloc () command associated with the random numbers generated by the client entity and the server entity (Client-Random and Server-Random) makes it possible to calculate the "keys_bloc" parameter. It is useful during a session of type "Session Resumption", or the user of the security module uses the latter, only to obtain keys_bloc.
  • keys_bloc Compute-Keys_bloc (Client-Random, Server-Random)
  • the GET-SessionID command returns the "SessionID" parameter associated with the current session or the previous session. This is useful information for the user who wants to partially manage a Session Resumption.
  • SessionID GET-SessionID ()
  • the GET-Master_secret () command collects the "master_secret” associated with the "SessionID" of the current or previous session. It is optional and corresponds to a "Session Resumption" management policy for which the user does not use the "keys_bloc" calculation service.
  • master_secret GET-Master_secret () 5.4 Implementation of the protocol
  • a first mode is illustrated in FIG. 3. It concerns the implementation of the method according to the invention applied to a "full session” mode login using the RSA algorithm, with mutual authentication (" Client Authentication Handshake ").
  • a client entity (350) initiates the latter with a ClientHello message (301).
  • a server entity entity (360) responds with a set of ServerHello (302), Certificate (303), CertificateRequest (304), ServerHelloDone (305) messages.
  • the client entity then delivers the messages Certificate (306), CertificateVerify (307), ClientKeyExchange (308), ChangeCipherSpec (309), and Finished (310).
  • the client entity verifies the validity of the server certificate, extracts its public RSA key, and then sends it a value called encrypted pre_master_secret of this key.
  • the master_secret is calculated from the Client-Random, Server-Random and pre-master-secret elements.
  • the CertificateVerify message (307) contains a signature made with the RSA private key of the client, which proves the identity of the latter (its certificate present in the message Certificate (306)).
  • the client entity and the server entity have a new value master_secret from which the keys of the keys_bloc are deduced.
  • a SessionID parameter passed in the ServerHello message provides an index of the master_secret.
  • the data generated by the APPLICATION layer is transported by the RECORD entity (313) (313), which ensures the confidentiality and integrity thereof by means of the keys Kc and Ki.
  • the previously described steps are implemented within security modules: one for the client entity (35) and one for the entity server entity (36). As shown in FIG. 3, the previously described steps are not implemented within client entities (350) and entity entities server (360) but only "transit” through these entities). The actual implementation is carried out with the security modules using commands of the functional interface of the module.
  • Cipher_suite (3005, 3006) indicates the list of cryptographic algorithms used for managing the secure channel.
  • the client entity opens a TLS session with a server entity typically listening on TCP port 443.
  • a security module is implemented on the client entity side
  • a second mode is shown in Figure 4.
  • a previous session type "FuIl Session” has obtained a "master_secret” identified by a "SessionID” index.
  • the authentication phase is simplified and consists of both parties (client entity and server) to prove their knowledge of the master_secret value.
  • the client entity (440) opens the TLS session with a ClientHello message (401) containing the index (SessionID) of a previous session.
  • the server entity (460) responds with a set of messages "ServerHello” (402), “ChangeCipherSpec” (403), and "Finished” (404).
  • PRF master_secret, "key expansion", server_random
  • Session Resumption mechanism simplifies the exchange of information during a TLS session.
  • a first session FuIl performs simple or mutual authentication of both ends (client entity and server) and produces a master_secret.
  • a Session Resumption session is negotiated between a client entity and a server entity.
  • the value of the "master_secret" is protected by the security module on the client entity and / or server side.
  • Session Resumption is negotiated between a client entity (550) and a server entity (560).
  • the value of the "master_secret” is stored by the client-side (55) and / or server (56) security module.
  • a security module in the form of a silicon integrated circuit (600), usually referred to as "Tamper Resistant Device”, literally a “component that resists attacks”, such as for example the ST22 component (produced by the company ST Microelectronics) and available in different formats such as PVC cards, (smart cards, SIM card, ...) integrated into USB tokens, or in MMC (MultiMedia Card) memories.
  • ST22 component produced by the company ST Microelectronics
  • PVC cards smart cards, SIM card, ...) integrated into USB tokens, or in MMC (MultiMedia Card) memories.
  • MMC MultiMedia Card
  • Such a security module incorporates all secure means of data storage, and also allows the execution of software in a secure and protected environment. More precisely, it comprises a central unit (CPU, 601), a memory
  • ROM storing operating system code (602), RAM memory (603), and nonvolatile memory (NVR, 604), used as a hard disk-like storage device, and which contains, for example, software embedded TLS.
  • a system bus (610) connects the various members of the secure module.
  • the interface to the outside world (620) is provided by an IO input / output port (605), compliant with standards such as ISO6816, USB, USB-OTG, ISO6816-12, MMC, IEEE 802.3, IEEE 802.11 etc.
  • JAVA smart cards commonly referred to as JAVACARD, are a special class of security module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to a method for producing securing data for implementing a secured session between a first and at least a second entity based on a protocol for establishing secured sessions. According to the invention, the method comprises: the step of setting up a third secured entity related to said first entity; the step of generating at least a portion of said securing data within said third entity; the step of transmitting said securing data from said secured third entity to said first entity.

Description

Procédé de sécurisation d'échange d'information, dispositif, et produit programme d'ordinateur correspondant. Method of securing information exchange, device, and corresponding computer program product.
1 DOMAINE DE L'INVENTION1 FIELD OF THE INVENTION
La présente invention se rapporte au domaine de la gestion des échanges d'informations réalisées entre deux entités d'un réseau de communication.The present invention relates to the field of information exchange management performed between two entities of a communication network.
Plus particulièrement, la présente invention se rapporte à la sécurisation de tels échanges. De nombreuses applications, notamment de commerce ou d'accès à des informations confidentielles, utilisent les protocoles SSL (de l'anglaisMore particularly, the present invention relates to securing such exchanges. Many applications, including trading or access to confidential information, use SSL (from English).
« Secure Socket Layer » pour « Couche d'encapsulation sécurisée ») ou TLS (de l'anglais « Transport Layer Security » pour « couche de transport sécurisée ») pour échanger des données de manière sécurisée. Bien que des preuves mathématiques existent pour ces protocoles, leur réalisation intégrale par des systèmes informatiques peu sure, permet des attaques qui diminuent la confiance que l'on doit légitimement apporter aux procédures d'échange mettant en œuvre ces protocoles."Secure Socket Layer" for "Secure Encapsulation Layer") or TLS ("Transport Layer Security" for "secure transport layer") to exchange data in a secure manner. Although mathematical proofs exist for these protocols, their complete realization by insecure computer systems, allows attacks that diminish the confidence that one must legitimately bring to the exchange procedures implementing these protocols.
2 SOLUTIONS DE L'ART ANTERIEUR2 SOLUTIONS OF THE PRIOR ART
2.1 Art antérieur2.1 Prior Art
La mise en œuvre d'une connexion sécurisée entre deux entités d'un réseau de communication passe par l'initiation d'une session sécurisée basée soit sur le protocole SSL, soit sur le protocole TLS.The implementation of a secure connection between two entities of a communication network requires the initiation of a secure session based on either the SSL protocol or the TLS protocol.
Ainsi, pour l'établissement d'une telle session, les deux entités utilisent des mécanismes qui sont censés assurer que la session crée ne pourra pas faire l'objet d'un piratage ou d'un espionnage. On décrit par la suite le fonctionnement des protocoles SSL et TLS. Bien que cette description soit plus particulièrement dédiée au protocole TLS, elle s'applique également au protocole SSL.Thus, for the establishment of such a session, the two entities use mechanisms that are supposed to ensure that the created session can not be hacked or spied. The operation of the SSL and TLS protocols is described later. Although this description is more specifically dedicated to the TLS protocol, it also applies to the SSL protocol.
Le protocole TLS est organisé sur la base d'un ensemble de cinq entités logicielles coopérant entre elles : APPLICATION, HANDSHAKE, CCS, ALERT et RECORD. L'entité « APPLICATION » fait référence à une application logicielle qui désire mettre en œuvre une session de communication sécurisée (couche 7 du modèle OSI). Les entités « HANDSHAKE », « CCS », « ALERT » et « RECORD » (également appelées couches) sont des entités qui sont mises en œuvre dans le cadre d'une application du protocole TLS, dont une description détaillée sera trouvée sous la référence « RFC 2246 » par l'intermédiaire du comité IETF (« Internet Engineering Task Force » pour « Groupe de Travail d'Ingénierie de l'Internet »). Une telle application du protocole TLS est réalisée au niveau de la couche 5 du modèle OSI.The TLS protocol is organized on the basis of a set of five cooperating software entities: APPLICATION, HANDSHAKE, CCS, ALERT and RECORD. The entity "APPLICATION" refers to a software application that wishes to implement a secure communication session (layer 7 of the OSI model). Entities "HANDSHAKE", "CCS", "ALERT" and "RECORD" (also called layers) are entities that are implemented as part of a TLS application, a detailed description of which will be found under the reference "RFC 2246" through the IETF Committee (" Internet Engineering Task Force "for" Internet Engineering Task Force "). Such an application of the TLS protocol is carried out at layer 5 of the OSI model.
L'architecture d'une « pile » TLS peut être décrite ainsi : la couche gérée par l'entité « RECORD » (également appelée couche « RECORD ») transporte les messages produits par les entités « APPLICATION » « HANDSHAKE » « CCS » et « ALERT », à l'aide d'un entête de 5 octets qui précise l'entité qui génère le message, la version du protocole TLS utilisé, et la longueur du message. Les messages en tant que tels comportent également un entête qui indique le type du message et la longueur des données associées. Cependant la structure des messages « APPLICATION » n'est pas définie par le standard TLS. En effet, chaque application échange des messages dont la structure est définie par le protocole applicatif, tel que dans le cadre des messages du protocole HTTPS (de l'anglais « Hypertext Transfer Protocol Secured » pour « protocole de transfert hypertexte sécurisé »).The architecture of a "stack" TLS can be described as follows: the layer managed by the entity "RECORD" (also called "RECORD" layer) carries the messages produced by the entities "APPLICATION" "HANDSHAKE" "CCS" and "ALERT", using a 5-byte header that specifies the entity that generates the message, the version of the TLS protocol used, and the length of the message. The messages themselves also include a header that indicates the type of the message and the length of the associated data. However, the structure of the "APPLICATION" messages is not defined by the TLS standard. Indeed, each application exchanges messages whose structure is defined by the application protocol, such as in the context of Hypertext Transfer Protocol Secured (HTTPS) protocol messages for "secure hypertext transfer protocol".
Ainsi, une application « APPLICATION » utilise les services offerts par le protocole TLS qui réalise la confidentialité (chiffrement) et la confidentialité des données transportées à l'aide du protocole TCP (de l'anglais « Transmission Control Protocol » pour « protocole de contrôle de transmissions ») qui agit au niveau de la couche transport.Thus, an "APPLICATION" application uses the services offered by the TLS protocol which achieves the confidentiality (encryption) and the confidentiality of the data transported by means of the TCP (transmission control protocol) protocol for control protocol transmissions ") acting at the transport layer.
La mise en œuvre du canal sécurisé par TLS s'effectue en deux étapes, une phase d'authentifïcation et de calcul de clés, suivie en cas de succès, d'une phase d'usage d'un canal de communication sécurisé, qui utilise le jeu de clés précédemment déterminées.The implementation of the secure channel by TLS is carried out in two steps, an authentication and key calculation phase, followed, if successful, by a phase of use of a secure communication channel, which uses the set of keys previously determined.
L'entité de la couche « HANDSHAKE » (également appelée couche « HANDSHAKE ») réalise les procédures d'authentifïcation et de calcul des clés. II existe deux modes d'authentifïcation le mode complet (appelé « FuIl Session ») et un mode rapide (appelé « Session Resumption »). Ces deux modes seront plus précisément décrits ultérieurement.The "HANDSHAKE" layer entity (also known as the "HANDSHAKE" layer) performs the authentication and key calculation procedures. There are two modes of authentication the complete mode (called "FuIl Session") and a quick mode (called "Session Resumption"). These two modes will be more precisely described later.
La couche « HANDSHAKE » négocie les algorithmes de chiffrement et d'intégrité mis en œuvre par l'entité de la couche RECORD (également appelée couche « RECORD »), qui sont identifiés par un nombre dénommé « cipher_suite ».The layer "HANDSHAKE" negotiates the encryption and integrity algorithms implemented by the entity of the RECORD layer (also called "RECORD" layer), which are identified by a number called "cipher_suite".
Au terme d'une procédure d'authentifîcation réussie, la coucheAt the end of a successful authentication procedure, the layer
« RECORD » détermine une valeur appelée master_secret. A l'aide de deux nombres aléatoires produits par l'entité cliente {client _random) et l'entité serveur (server _random) elle calcule un ensemble de clés (le keysjbloc), utilisées pour le chiffrement et l'intégrité des données reçues et émises : keys_block = PRF(master_secret, "key expansion", server _random client _random);"RECORD" determines a value called master_secret. Using two random numbers generated by the client entity {client _random) and the server entity (server _random) it calculates a set of keys (the keysjbloc), used for the encryption and the integrity of the received data and issued: keys_block = PRF (master_secret, "key expansion", server _random client _random);
PRF (Pseudo Random Function) est une fonction générant des données pseudo aléatoire; le symbole « | » indique une opération de concaténation.PRF (Pseudo Random Function) is a function generating pseudo-random data; the symbol «| Indicates a concatenation operation.
De manière simplifiée le paramètre keys bloc est un couple de deux paires de clés (KcRx, KiRx) et (KcTx, KiTx) utilisées respectivement pour le chiffrement (préfixe Kc) et l'intégrité (préfixe Ki) des données reçues (suffixe Rx) et émises (suffixe Tx). La couche « CCS » (Change Cipher Spec) signale à l'entité « RECORD » les modifications des paramètres de sécurité. Elle active la mise en fonction des procédures de chiffrement et d'intégrité des données, utilisant les paramètres « keys_bloc » et « cipher _suite ».In a simplified way, the keys block parameter is a pair of two key pairs (KcRx, KiRx) and (KcTx, KiTx) used respectively for the encryption (prefix Kc) and the integrity (prefix Ki) of the received data (suffix Rx). and issued (suffix Tx). The Change Cipher Spec (CCS) layer reports to the "RECORD" entity the changes to the security settings. It enables encryption and data integrity procedures, using the "keys_bloc" and "cipher_suite" parameters.
L'entité de la couche ALERT (également appelée couche « ALERT ») signale des erreurs détectées par l'entité « HANDSHAKE » (en cas d'échec de l'authentification), ou par la couche « RECORD » (détection d'un défaut d'intégrité, ou une fin de session).The entity of the ALERT layer (also called "ALERT" layer) reports errors detected by the entity "HANDSHAKE" (in case of authentication failure), or by the "RECORD" layer (detection of a lack of integrity, or an end of session).
La couche « RECORD » assure quatre types d'opérations : une fragmentation des données en blocs dont la taille maximum est de 214 octets ; une compression optionnelle des données; ce service n'est généralement pas assuré ; une génération de signatures (basée sur l'algorithme HMAC, défini par la RFC 2104) ; - un chiffrement des données.The "RECORD" layer performs four types of operations: fragmentation of the data into blocks whose maximum size is 2 14 bytes; optional compression of the data; this service is generally not insured; a signature generation (based on the HMAC algorithm, defined by RFC 2104); - data encryption.
L'ensemble des paramètres nécessaires au fonctionnement de la couche « RECORD » est dénommé « security jparameters » et comporte entre autre les valeurs du « keys_bloc » produit par l'entité HANDSHAKE.All the parameters necessary for the functioning of the "RECORD" layer are called "security jparameters" and include among others the values of the "keys_bloc" produced by the HANDSHAKE entity.
Les messages échangés entre la couche application et la couche TCP sont chiffrés et déchiffrés par la couche « RECORD » à l'aide d'un jeu de deux paires de clés (KcRx, KiRx) et (KcTx, KiTx) préalablement décrit.The messages exchanged between the application layer and the TCP layer are encrypted and decrypted by the "RECORD" layer using a set of two key pairs (KcRx, KiRx) and (KcTx, KiTx) previously described.
Les messages reçus par la couche « RECORD » sont chiffrés par la clé KcRx ((M)KcRx) et muni d'une signature HMAC(KiRx, M) associée à la clé KiRx. Cette dernière vérifie la signature HMAC et restitue la valeur déchiffrée à la couche application.The messages received by the "RECORD" layer are encrypted by the key KcRx ((M) KcRx) and provided with an HMAC signature (KiRx, M) associated with the key KiRx. The latter checks the HMAC signature and restores the decrypted value to the application layer.
Les messages émis par la couche application sont chiffrés par la couche « RECORD » à l'aide de la clé KcTx ((M)KcTx) et muni d'une signature HMAC(M5KiTx) associée à la clé KiTx.The messages sent by the application layer are encrypted by the "RECORD" layer using the KcTx key ((M) KcTx) and provided with an HMAC signature (M 5 KiTx) associated with the KiTx key.
Lorsque le mode de chiffrement est activé, le fonctionnement de la couche RECORD est le suivant : un « MESSAGE » émis/reçu par une entité telle que « HANDSHAKE » ou « APPLICATION » est muni d'un entête comportant trois paramètres : type, version, longueur. L'ensemble « MESSAGE », « signature HMAC » et « octets de bourrage » est chiffré à l'aide de l'algorithme négocié durant la phase d'authentifïcation et d'une clé Kc. La signature « HMAC » est calculée à partir de l'entête, du « MESSAGE » et d'un numéro de trame (seq_num) (initialisé à la valeur 0 et incrémenté à chaque usage de la couche « RECORD ») selon la relation suivante :When the encryption mode is activated, the operation of the RECORD layer is as follows: a "MESSAGE" sent / received by an entity such as "HANDSHAKE" or "APPLICATION" is provided with a header comprising three parameters: type, version , length. The set "MESSAGE", "HMAC signature" and "stuffing bytes" is encrypted using the algorithm negotiated during the authentication phase and a key Kc. The signature "HMAC" is calculated from the header, the "MESSAGE" and a frame number (seq_num) (initialized to the value 0 and incremented with each use of the layer "RECORD") according to the following relation :
HMAC (Ki, seqjium \ Type \ Version \ Longueur \ MESSAGE ) Ainsi que cela a été évoqué précédemment, il existe deux modes d'ouverture de session TLS appelés « FuIl Session » et « Session Resumption ». Ainsi, par exemple, dans le cas de l'ouverture d'une session « FuIl Session », utilisant l'algorithme RSA, avec mutuelle authentifîcation (" 'Client Authentication Handshake"), entre une entité cliente et une entité serveur, l'entité cliente initie cette dernière par un message « ClientHello ». L'entité serveur répond par un ensemble de messages « ServerHello », « Certifîcate », « CertifîcateRequest », « ServerHelloDone ». L'entité cliente délivre alors les messages « Certifîcate », « CertifîcateVerify », « ClientKeyExchange », « ChangeCipherSpec », et « Finished ».HMAC (Ki, seqjium \ Type \ Version \ Length \ MESSAGE) As mentioned above, there are two TLS logon modes called "FuIl Session" and "Session Resumption". Thus, for example, in the case of opening a "FuIl Session" session, using the RSA algorithm, with mutual authentication ("Client Authentication Handshake"), between a client entity and a server entity, the client entity initiates the latter with a "ClientHello" message. The server entity responds with a set of messages "ServerHello", "Certifîcate", "CertifîcateRequest", "ServerHelloDone". The client entity then delivers the "Certifîcate", "CertifîcateVerify", "ClientKeyExchange", "ChangeCipherSpec", and "Finished" messages.
Dans cette procédure l'entité cliente vérifie la validité du certificat du serveur, en extrait sa clé publique RSA, puis lui transmet une valeur baptisée « pre_master_secret » chiffrée de cette clé. Le « master _secret » est calculé partir des éléments « Client-Random », « Server-Random » et « pre-master-secret » . Le message « CertificateVerify » contient une signature réalisée avec la clé privée RSA du client, qui prouve l'identité de ce dernier (son certificat présent dans le message « Certifîcate »).In this procedure, the client entity verifies the validity of the server's certificate, extracts its public RSA key, and then sends it a value called "pre_master_secret" encrypted of this key. The "master _secret" is calculated from the "Client-Random", "Server-Random" and "pre-master-secret" elements. The "CertificateVerify" message contains a signature made with the client's RSA private key, which proves the identity of the latter (his certificate present in the "Certifi- cate" message).
Au terme de cette procédure d' authentifîcation l'entité cliente et l'entité serveur disposent d'une nouvelle valeur « master _secret » à partir de laquelle sont déduites les clés du « keys_bloc ». Un paramètre « SessionID » transmis dans le message « ServerHello » fournit un index du « master _secr et ». Par la suite les données générées par la couche « APPLICATION » sont transportées par l'entité « RECORD », qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki.At the end of this authentication procedure, the client entity and the server entity have a new value "master _secret" from which the keys of the "keys_bloc" are deduced. A "SessionID" parameter passed in the "ServerHello" message provides an index of the "master _secr and". Subsequently, the data generated by the "APPLICATION" layer is transported by the "RECORD" entity, which ensures the confidentiality and the integrity thereof by means of the keys Kc and Ki.
Dans le cas d'une ouverture d'une session « Session Resumption », une procédure précédente « FuIl Session » a déjà permis d'obtenir un « master _secret » identifié par un index « SessionID ». La phase d' authentifîcation est simplifiée et consiste pour les deux parties (l'entité cliente et l'entité serveur) à prouver leur connaissance de la valeur « master _secr et ». L'entité cliente ouvre la session TLS par un message « ClientHello » contenant l'index (« SessionID ») d'une session précédente. L'entité serveur répond par un ensemble de messages « ServerHello », « ChangeCipherSpec », et « Finished ». Il indique la reprise de session en insérant une valeur « SessionID » dans le message « ServerHello » identique à celle contenue dans le message « ClientHello ». L'entité cliente délivre alors les messages « ChangeCipherSpec », et « Finished ».In the case of opening a Session Resumption session, a previous "FuIl Session" procedure has already resulted in a "master_secret" identified by a "SessionID" index. The authentication phase is simplified and consists for both parties (the client entity and the server entity) to prove their knowledge of the value "master _secr and". The client entity opens the TLS session with a "ClientHello" message containing the index ("SessionID") of a previous session. The server entity responds with a set of "ServerHello", "ChangeCipherSpec", and "Finished" messages. he indicates the session restart by inserting a "SessionID" value in the "ServerHello" message identical to that contained in the "ClientHello" message. The client entity then delivers the messages "ChangeCipherSpec" and "Finished".
Le « master_secret » n'est pas recalculé, cependant un nouvel ensemble « keys_bloc » est obtenu à partir des éléments « master_secret »,The "master_secret" is not recalculated, however a new set "keys_bloc" is obtained from the elements "master_secret",
« ClientRandom » et « ServerRandom » par l'application de la fonction suivante :"ClientRandom" and "ServerRandom" by applying the following function:
Keys_block = PRF(master_secret, "key expansion", server _random \ client _random).Keys_block = PRF (master_secret, "key expansion", server _random \ client _random).
Par la suite les données générées par la couche « APPLICATION » sont transportées par l'entité « RECORD », qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki.Subsequently, the data generated by the "APPLICATION" layer is transported by the "RECORD" entity, which ensures the confidentiality and the integrity thereof by means of the keys Kc and Ki.
Le mécanisme de « Session Resumption » simplifie l'échange d'information lors d'une session TLS. Une première « FuIl Session » effectue l'authentification simple ou mutuelle des deux extrémités (client et serveur) et produit un « master _secret ». Les sessions suivantes, basée sur le mécanisme de « Session Resumption » réutilisent le « master _secret » pour le calcul de nouvelles clés de chiffrement et d'intégrité.The "Session Resumption" mechanism simplifies the exchange of information during a TLS session. A first "FuIl Session" performs simple or mutual authentication of both ends (client and server) and produces a "master _secret". The following sessions, based on the "Session Resumption" mechanism, reuse the "master _secret" for the calculation of new encryption and integrity keys.
2.2 Inconvénients de l'art antérieur2.2 Disadvantages of the Prior Art
Ainsi décrit les mécanismes d'établissement de session TLS, il a été mis en évidence deux étapes pour l'échange d'information sécurisée : une étape d'authentifîcation permettant l'obtention du master _secret et le calcul des clés de session (keysjbloc) ; et une étape de transfert d'informations protégées par la couche « RECORD » en mode chiffré. Bien que les données applicatives soient échangées entre les entités client et serveur, la phase d'authentifîcation est le processus le plus critique puis qu'il établit l'identité des deux parties, vérifie leurs certificats et calcule les clés cryptographiques.Thus describes the mechanisms of TLS session establishment, it has been highlighted two steps for the exchange of secure information: an authentication step allowing the obtaining of the master _secret and the calculation of session keys (keysjbloc) ; and a step of transferring information protected by the "RECORD" layer in encrypted mode. Although the application data is exchanged between the client and server entities, the authentication phase is the most critical process and establishes the identity of both parties, verifies their certificates and calculates the cryptographic keys.
Un inconvénient de cette technique de l'art antérieur est lié au fait que la pile TLS (c'est-à-dire l'enchaînement des étapes menant à l'échange d'informations) est intégralement exécutée sur le même ordinateur et ne permet donc pas de séparer les procédures d'authentification et d'échange d'informations.A disadvantage of this prior art technique is that the TLS stack (i.e., the sequence of steps leading to the exchange information) is fully executed on the same computer and thus does not allow to separate the procedures of authentication and information exchange.
Il n'y a donc pas d'assurance que l'ordinateur sur lequel est exécutée cette pile TLS soit entièrement sécurisé et qu'une usurpation de clés ne puisse pas se produire durant les phases critiques d'authentification et de transfert d'informations protégées.There is no assurance that the computer running this TLS stack is fully secure and that key spoofing can not occur during critical authentication and secure information transfer phases. .
Or de nombreuses applications, par exemple les réseaux virtuels (VPN) basés sur SSL/TLS, les grilles de calculs, ou les réseaux de type overlays, nécessite des garanties de sécurité particulières, afin d'interdire les usurpations d'identité, c'est-à-dire l'usage illicite de services par des pirates informatiques (ou hackers).However, many applications, for example SSL / TLS-based virtual networks (VPNs), computing grids, or overlays-type networks, require special security guarantees in order to prevent identity theft. that is, the unlawful use of services by hackers.
Les systèmes d'exploitation complexes des ordinateurs actuels permettent l'exécution de logiciels malveillants tels que chevaux de Troie, vers, virus, capables de collecter les identités et les clés RSA des utilisateurs. Pour pallier ces problèmes, il a été proposé de nombreuses solutions basées notamment sur des cartes à puce ou des dispositifs externes qui contiennent des preuves de l'identité physique de l'utilisateur ou de la machine qui souhaite établir une session sécurisée (par l'intermédiaire notamment du stockage, au sein de la carte à puce de clés privées et publiques). De telles solutions permettent effectivement de s'assurer de l'identité de l'entité qui souhaite se connecter, mais ne sécurisent en rien la machine sur laquelle la procédure d'authentification est réalisée. 3 RESUME DE L'INVENTIONThe complex operating systems of today's computers allow the execution of malware such as Trojans, worms, viruses, which can collect RSA identities and RSA keys. To overcome these problems, it has been proposed many solutions based in particular on smart cards or external devices that contain evidence of the physical identity of the user or the machine who wishes to establish a secure session (by the intermediary including storage, within the smart card of private and public keys). Such solutions can effectively ensure the identity of the entity that wants to connect, but do not secure the machine on which the authentication procedure is performed. 3 SUMMARY OF THE INVENTION
L'invention propose une solution nouvelle qui permet de résoudre ces inconvénients de l'art antérieur, sous la forme d'un procédé de production de données de sécurisation, permettant la mise en œuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées. Selon l'invention, un tel procédé comprend : - une étape d'initialisation d'une troisième entité sécurisée, liée à ladite première entité ; une étape de génération d'au moins une partie desdites données de sécurisation au sein de ladite troisième entité ; une étape de transmission desdites données de sécurisation de ladite troisième entité sécurisée vers ladite première entité.The invention proposes a new solution that makes it possible to solve these disadvantages of the prior art, in the form of a method for producing security data, enabling the implementation of a secure session between a first and at least one second entity, according to a protocol for establishing secure sessions. According to the invention, such a method comprises: a step of initialization of a third secure entity, linked to said first entity; a step of generating at least a portion of said security data within said third entity; a step of transmitting said security data from said third secure entity to said first entity.
Ainsi, à la différence des techniques de l'art antérieur qui ne permettent la production des données de session que sur l'entité qui va effectivement mettre en œuvre la session sécurisée, l'invention autorise la production de telles données au sein d'une troisième entité différente de la première. Cette troisième entité peut être attachée soit mécaniquement à la première, soit par le biais d'une interface d'un réseau, tel qu'un réseau local. La génération des données permettant la mise en œuvre de la session sécurisée n'est donc plus réalisée par l'entité qui met en œuvre la session sécurisée, mais par une entité tierce, évitant ainsi les différentes attaques qui peuvent être conduites vis-à-vis de la première entité. Le procédé selon l'invention permet donc de remplacer la première entité lors de la production de données de sessions sécurisée. Une telle substitution autorise la conduite d'au moins une partie des opérations de définition des données permettant l'établissement de la session au sein de la troisième entité qui peut donc prendre la place de la première et ainsi sécuriser la procédure de création des données au sein d'un environnement sûr.Thus, unlike techniques of the prior art that only allow the production of session data on the entity that will actually implement the secure session, the invention allows the production of such data within a third entity different from the first. This third entity can be attached either mechanically to the first entity or through an interface of a network, such as a local area network. The generation of the data enabling the implementation of the secure session is therefore no longer performed by the entity implementing the secure session, but by a third entity, thus avoiding the various attacks that can be conducted vis-à- vis of the first entity. The method according to the invention thus makes it possible to replace the first entity during the production of secure session data. Such a substitution authorizes the conduct of at least a part of the data definition operations allowing the establishment of the session within the third entity which can therefore take the place of the first and thus secure the procedure of creating the data at within a safe environment.
Selon un mode de réalisation original de l'invention, ladite troisième entité est une carte à puce de type « JavaCard ».According to an original embodiment of the invention, said third entity is a "JavaCard" type smart card.
Ainsi, l'invention permet de dissocier le dispositif qui est chargé de mettre en œuvre le protocole de sécurité du dispositif souhaitant disposer d'une connexion sécurisée. De plus, l'utilisation d'une carte à puce de type « JavaCard » assure que cette entité chargée de mettre en œuvre le protocole de sécurité est inviolable et totalement sécurisée. Un niveau de sécurisation supplémentaire, issu des travaux menés par les inventeurs, est donc ajouté à l'ensemble du protocole de sécurité. Selon une caractéristique particulière de l'invention, ledit protocole d'établissement de sessions sécurisées est le protocole SSL.Thus, the invention makes it possible to dissociate the device which is responsible for implementing the security protocol of the device wishing to have a secure connection. In addition, the use of a "JavaCard" type smart card ensures that this entity responsible for implementing the security protocol is inviolable and completely secure. An additional level of security, resulting from the work carried out by the inventors, is therefore added to the entire security protocol. According to a particular characteristic of the invention, said secure session establishment protocol is the SSL protocol.
Ainsi, l'invention prend en charge l'établissement d'une session sécurisée respectant le protocole SSL, qui est un des protocoles majeurs dans ce domaine. Selon une caractéristique particulière de l'invention, ledit protocole d'établissement de sessions sécurisées est le protocole TLS.Thus, the invention supports the establishment of a secure session respecting the SSL protocol, which is one of the major protocols in this area. According to a particular characteristic of the invention, said secure session establishment protocol is the TLS protocol.
Ainsi, l'invention prend en charge l'établissement d'une session sécurisée respectant le protocole TLS, qui est un des protocoles les plus utilisés dans ce domaine. Selon un mode de réalisation particulier de l'invention, ledit procédé de production comprend en outre : une étape de transmission, par ladite première entité, d'au moins un message à destination d'une couche « RECORD » mise en œuvre au sein de ladite troisième entité ; - une étape de réception, par ladite première entité, d'au moins un message en provenance de ladite couche « RECORD » ; une étape de calcul d'un ensemble de clés par ladite troisième entité ; une étape de collecte dudit ensemble de clés disponibles par ladite première entité auprès de ladite troisième entité ; - une étape de récupération d'un identifiant de session de communication sécurisée.Thus, the invention supports the establishment of a secure session respecting the TLS protocol, which is one of the most used protocols in this field. According to a particular embodiment of the invention, said production method also comprises: a step of transmission, by said first entity, of at least one message intended for a "RECORD" layer implemented within said third entity; a step of reception, by said first entity, of at least one message coming from said "RECORD" layer; a step of calculating a set of keys by said third entity; a step of collecting said set of keys available from said first entity to said third entity; a step of recovering a secure communication session identifier.
Ainsi, l'invention permet de conserver la conformité des installations existantes en réalisant un transfert de messages en lieu et place de l'exécution des étapes de production sur la première entité, qui peut être soumise aux attaques. L'invention concerne également un dispositif de production de données de sécurisation, permettant la mise en œuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées. Selon l'invention, un tel dispositif comprend : des moyens d'initialisation, attachée à ladite première entité ; - des moyens de génération d'au moins une partie desdites données de sécurisation ; des moyens de transmission desdites données de sécurisation vers ladite première entité.Thus, the invention makes it possible to maintain the conformity of the existing installations by carrying out a transfer of messages instead of the execution of the production steps on the first entity, which may be subject to attacks. The invention also relates to a device for producing security data, enabling the implementation of a secure session between a first and at least a second entity, according to a secure session establishment protocol. According to the invention, such a device comprises: initialization means, attached to said first entity; means for generating at least a part of said data of security; means for transmitting said security data to said first entity.
De façon générale, un tel dispositif comprend des moyens lui permettant de mettre en œuvre les étapes du procédé de production tel que décrit précédemment.In general, such a device comprises means enabling it to implement the steps of the production method as described above.
Selon un mode de réalisation original de l'invention, lesdits moyens de génération et lesdits moyens de transmission sont regroupés dans une carte à puce.According to an original embodiment of the invention, said generation means and said transmission means are grouped together in a smart card.
Ainsi, un tel dispositif selon l'invention dispose de moyens de résistance aux attaques malveillantes.Thus, such a device according to the invention has means of resistance to malicious attacks.
Dans un autre mode de réalisation, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de production tel que décrit précédemment. 4 LISTE DES FIGURESIn another embodiment, the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor. According to the invention, in at least one embodiment, such a computer program product comprises program code instructions for executing the production method as described above. 4 LIST OF FIGURES
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique du procédé de production de données sécurisées selon l'invention ; - la figure 2 illustre un exemple de mise en œuvre du procédé de production au sein d'un module de sécurité selon l'invention ; la figure 3 décrit un mode de mise en œuvre du procédé de production par deux entités à l'aide de deux modules de sécurité dans un mode dit deOther features and advantages of the invention will emerge more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and nonlimiting example, and the appended drawings, among which: FIG. 1 presents a block diagram of the method for producing secure data according to the invention; FIG. 2 illustrates an exemplary implementation of the production method within a security module according to the invention; FIG. 3 describes a mode of implementation of the production method by two entities using two security modules in a mode known as
« full session » ; - la figure 4 décrit un mode de mise en œuvre du procédé de production par deux entités à l'aide de deux modules de sécurité dans un mode dit de"Full session"; FIG. 4 describes a mode of implementation of the production method by two entities using two security modules in a mode called
« Session Resumption » ; la figure 5 décrit également un mode de mise en œuvre du procédé de production par deux entités à l'aide de deux modules de sécurité dans un mode dit de « Session Resumption » ; la figure 6 décrit une architecture d'un dispositif de production de données de sécurisation, également appelé module de sécurité. 5 DESCRIPTION DETAILLEE DE L'INVENTION"Session Resumption"; FIG. 5 also describes a mode of implementation of the production method by two entities using two security modules in a so-called "Session Resumption" mode; FIG. 6 describes an architecture of a device for producing security data, also called a security module. DETAILED DESCRIPTION OF THE INVENTION
5.1 Rappel du principe de l'invention L'invention permet donc de résoudre les problèmes liés à l'insécurité intrinsèque des entités sur lesquelles sont mis en œuvre les protocoles SSL et TLS. En effet, ces entités sont, de manière générale, des serveurs fonctionnant sur des systèmes d'exploitation propriétaires ou issus du monde libre ou des ordinateurs personnels d'utilisateurs classiques. Si on accorde la plupart du temps une confiance relativement large dans la catégorie des « serveurs », les ordinateurs personnels des utilisateurs individuels n'ont pas le même niveau de sécurisation que les serveurs et sont donc plus souvent (mais non exclusivement) soumis aux risques d'attaques. Ainsi, quand bien même les protocoles de sécurisation de session de communication tels que TLS et SSL remplissent correctement leurs fonctions, il est fort probable qu'une attaque visant un poste de travail ou un entité serveur à l'aide de logiciels malfaisant puisse s'introduire dans une « pile logicielle » ou encore modifier des fichiers du système d'exploitation. Une telle introduction est alors réalisée dans l'objectif de pouvoir prendre le contrôle ultérieur de sessions initiées par des utilisateurs. Pour éviter ces attaques ultérieures, l'invention permet de mettre en œuvre au moins certaines étapes d'authentifïcation dans une entité tierce solidaire de l'entité qui met généralement en œuvre cette phase d'authentifïcation. Une telle entité tierce, qui est un dispositif de production d'informations de sécurisation selon l'invention, est également appelée « module de sécurité ». Cette entité met ensuite à disposition les informations nécessaires à la poursuite de la session d' authentification.5.1 Reminder of the Principle of the Invention The invention thus makes it possible to solve the problems related to the intrinsic insecurity of the entities on which the SSL and TLS protocols are implemented. Indeed, these entities are, in general, servers running on proprietary operating systems or from the free world or personal computers of conventional users. While most of the time is given relatively broad trust in the "server" category, the personal computers of individual users do not have the same level of security as the servers and are therefore more often (but not exclusively) subject to the risks. attacks. Thus, even if the communication session security protocols such as TLS and SSL perform their functions correctly, it is very likely that an attack on a workstation or a server entity using malicious software could occur. introduce into a "software stack" or modify operating system files. Such an introduction is then carried out with the aim of being able to take subsequent control of sessions initiated by users. To avoid these subsequent attacks, the invention makes it possible to implement at least certain authentication steps in a third party entity of the entity that generally implements this authentication phase. Such a third entity, which is a device for producing security information according to the invention, is also called a "security module". This entity puts then available the information necessary to continue the authentication session.
De telles informations peuvent par exemple, être les clés de session (keys_bloc) ou le « master_secret » (selon le niveau de sécurité requis) pour un logiciel qui a besoin d'un échange d'information sécurisée par les protocoles SSL/TLS.Such information can be, for example, the session keys (keys_bloc) or the "master_secret" (depending on the required security level) for software that needs secure information exchange through SSL / TLS protocols.
Le principe général de l'invention repose sur une délocalisation, au sein d'une entité de confiance, tel qu'un module de sécurité, d'au moins certaines étapes d'un protocole, tel qu'un protocole d' authentification, à mettre en oeuvre. En effet, bien que les données applicatives soient échangées entre les entités client et serveur, la phase d' authentification est le processus le plus critique puis qu'il établit l'identité des deux parties, vérifie leurs certificats et calcule les clés cryptographiques.The general principle of the invention relies on delocalization, within a trusted entity, such as a security module, of at least some steps of a protocol, such as an authentication protocol, to enforce. Indeed, although the application data is exchanged between the client and server entities, the authentication phase is the most critical process and establishes the identity of both parties, verifies their certificates and calculates the cryptographic keys.
L'invention se distingue des techniques de l'art antérieur, qui mettent en œuvre des cartes à puce, par le fait que ces mécanismes antérieurs ne proposent pas, au sein de la carte en question, une exécution de logiciels, mais un simple stockage de données telles que des certificats ou des clés. Une entité selon l'invention, au contraire, ne renferme pas, dans sa fonction première, des données, mais un ensemble de mécanismes permettant l'exécution, de manière indépendante, d'au moins certaines étapes d'un protocole sécurisé.The invention differs from the techniques of the prior art, which implement smart cards, in that these prior mechanisms do not offer, within the card in question, a software execution, but a simple storage data such as certificates or keys. An entity according to the invention, on the contrary, does not contain, in its primary function, data, but a set of mechanisms allowing the execution, independently, of at least some steps of a secure protocol.
On présente, en relation avec la figure 1, le procédé de production de données sécurisées selon l'invention. Il comprend : une étape d'initialisation (100) du module de sécurité (par exemple une carte à puce), attachée à une première entité (par exemple un ordinateur personnel) ; une étape de génération (101) d'une partie des données de sécurisation au sein du module de sécurité ; une étape de transmission (102) des données de sécurisation du module de sécurité vers la première entité. Par la suite, on présente notamment le cas d'un module de sécurité mettant en œuvre le procédé selon l'invention pour les étapes d'authentification des protocoles SSL/TLS. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en œuvre dans de nombreux autres domaines, et par exemple dans des entités qui pourraient mettre en œuvre des mécanismes d'initialisation ou de démarrage d'autres entités, tels que des véhicules par exemple et plus généralement dans tous les cas où les avantages procurés par l'invention sont intéressants. 5.2 Description d'un mode de réalisation On présente dans ce mode de réalisation, la mise en œuvre du procédé selon l'invention au sein d'une carte à puce embarquant des moyens d'exécution de programmes d'ordinateurs (module de sécurité). Il peut par exemple s'agir d'une « JavaCard » c'est-à-dire d'une carte à puce qui intègre une machine virtuelle Java. De telles cartes à puce présentent l'avantage d'être résistantes aux attaques. Cela signifie que ces cartes possèdent des caractéristiques physiques qui diminuent de manière drastiques les risques et les possibilités de piratage. Elles sont donc particulièrement bien indiquées pour la mise en œuvre de procédures sécurisées.With reference to FIG. 1, the method for producing secure data according to the invention is presented. It comprises: an initialization step (100) of the security module (for example a smart card), attached to a first entity (for example a personal computer); a step of generating (101) a portion of the security data within the security module; a step of transmitting (102) the securing data of the security module to the first entity. Subsequently, there is presented in particular the case of a security module implementing the method according to the invention for the SSL / TLS protocol authentication steps. It is clear, however, that the invention is not limited to this particular application, but can also be implemented in many other fields, and for example in entities that could implement initialization or start-up mechanisms. other entities, such as vehicles for example and more generally in all cases where the benefits provided by the invention are interesting. 5.2 Description of an Embodiment In this embodiment, the implementation of the method according to the invention is presented in a smart card carrying means for executing computer programs (security module). . It can for example be a "JavaCard" that is to say a smart card that integrates a Java virtual machine. Such smart cards have the advantage of being resistant to attacks. This means that these cards have physical characteristics that drastically reduce the risks and possibilities of hacking. They are therefore particularly well suited for the implementation of secure procedures.
Dans ce mode de réalisation, le procédé selon l'invention permet de « délocaliser » la mise en œuvre du protocole SSL ou TLS au sein de ce module de sécurité.In this embodiment, the method according to the invention makes it possible to "delocalize" the implementation of the SSL or TLS protocol within this security module.
Dans l'état de l'art actuel la pile TLS (c'est-à-dire l'enchaînement des étapes du processus conduisant à l'authentification) est intégralement exécutée sur le même ordinateur et ne permet donc pas de séparer les procédures d ' authentif ication et d ' échange d ' informations .In the current state of the art the TLS stack (that is to say the sequence of steps of the process leading to the authentication) is entirely executed on the same computer and thus does not allow to separate the procedures of Authentication and exchange of information.
Cependant de nombreuses applications, par exemple les réseaux virtuels (VPN) basés sur SSL/TLS, les grilles de calculs, ou les réseaux de type « overlays » (de l'anglais, pour « recouvrement »), nécessite des garanties de sécurité particulières, afin d'interdire les usurpations d'identité, c'est-à-dire l'usage illicite de services par des pirates informatiques (ou « hackers »). Les systèmes d'exploitation complexes des ordinateurs actuels permettent l'exécution de logiciels malveillants tels que chevaux de Troie, vers, virus, capables de collecter les identités et les clés RSA des utilisateurs.However, many applications, such as SSL / TLS-based virtual networks (VPNs), computing grids, or overlays networks (for "recovery"), require special security safeguards. , to prohibit identity theft, that is, the unlawful use of services by hackers (or "hackers"). The Complex computer operating systems today allow the execution of malware such as Trojans, worms, viruses, able to collect identities and RSA keys from users.
Un module de sécurité mettant en œuvre le procédé selon l'invention comprend donc des fonctionnalités originales qui lui permettent de réaliser la phase d'authentification du protocole TLS, et de transférer le droit, à une application, d'utiliser le tunnel sécurisé préalablement établi.A security module implementing the method according to the invention therefore comprises original features that enable it to perform the authentication phase of the TLS protocol, and to transfer the right to an application to use the previously established secure tunnel. .
Un module de sécurité mettant en œuvre le procédé selon l'invention réalise les fonctions de client ou de entité serveur TLS. Ainsi, Dans ce mode de réalisation particulier, le procédé selon l'invention met en œuvre les entités « HANDSHAKE », « ALERT », « CCS » et « RECORD » décrites précédemment.A security module implementing the method according to the invention performs the functions of client or TLS server entity. Thus, in this particular embodiment, the method according to the invention implements the entities "HANDSHAKE", "ALERT", "CCS" and "RECORD" described above.
On présente, en relation avec la figure 2 un module de sécurité (210) mettant en œuvre le protocole TLS selon le procédé de production de l'invention et une entité utilisatrice (200), c'est-à-dire une application (2000) comprenant un sous ensemble de la pile TLS, a savoir de manière obligatoire les couches « RECORD » (2004) et « ALERT » (2002) et de manière optionnelle les couches « CCS » (2003) et « HANDSHAKE » (2001). La couche « RECORD » (2004) présente une interface de communication avec la couche « TCP » (2005). Dans ce mode de réalisation, un tel module de sécurité offre une interface fonctionnelle (220) qui comprend huit commandes : « SET-Credentials », « Start », « Process-TLS », « GET-Keys_bloc », « Compute-Keys_bloc », « GET- Cipher_suite », « GET-SessionID », « GET-Master_secret ». De telles commandes peuvent être réalisées en suivant la norme ISO 7816 selon un codage couramment dénommé « APDUs » (de l'anglais « Application Protocol Data Unit » pour « Unité de données (PDU) de la couche sept (Application) du modèle OSI »).FIG. 2 shows a security module (210) implementing the TLS protocol according to the production method of the invention and a user entity (200), that is to say an application (2000). ) comprising a subset of the TLS stack, namely the layers "RECORD" (2004) and "ALERT" (2002) and optionally the layers "CCS" (2003) and "HANDSHAKE" (2001). The "RECORD" layer (2004) presents a communication interface with the "TCP" layer (2005). In this embodiment, such a security module provides a functional interface (220) which comprises eight commands: "SET-Credentials", "Start", "Process-TLS", "GET-Keys_bloc", "Compute-Keys_bloc" , "GET- Cipher_suite", "GET-SessionID", "GET-Master_secret". Such commands can be performed according to the ISO 7816 standard according to a coding commonly called "APDUs" (of the English "Application Protocol Data Unit" for "Data Unit (PDU) of the layer seven (Application) of the OSI model" ).
Le module de sécurité (210) qui met en œuvre le procédé de production selon l'invention comprend les entités nécessaires à la mise en œuvre du procédé de sécurisation à savoir les couches « RECORD » (2104) et « ALERT » (2102) et de manière optionnelle les couches « CCS » (2103) et « HANDSHAKE » (2101).The security module (210) which implements the production method according to the invention comprises the entities necessary for the implementation of the method the "RECORD" (2104) and "ALERT" (2102) layers and optionally the "CCS" (2103) and "HANDSHAKE" (2101) layers.
L'interface fonctionnelle (220) permet à l'entité utilisatrice (200) de faire appel au module de sécurité (210) pour la production de données de sécurisation. 5.3 Description des commandesThe functional interface (220) allows the user entity (200) to call the security module (210) for the production of security data. 5.3 Description of the orders
5.3.1 Commande SET-Credentials5.3.1 SET-Credentials Command
Le rôle du module, c'est-à-dire son comportement client ou entité serveur ainsi que les différents paramètres nécessaires à son fonctionnement, qualifiés usuellement de lettres de crédits ou « credentials » en langue anglaise (certificats X509, clé privé RSA) est activé par la commande SET-Credentials(), SET-Credentials ( Credentials , rôle )The role of the module, that is to say its behavior client or server entity and the various parameters necessary for its operation, usually qualified letters of credit or "credentials" in English (X509 certificates, RSA private key) is enabled by SET-Credentials () command, SET-Credentials (role)
5.3.2 StartCUnix-Time)5.3.2 StartCUnix-Time)
Dans ce mode de réalisation, une commande « Start » initialise une sessionIn this embodiment, a "Start" command initializes a session
TLS; puisque les modules de sécurité ne comportent pas en règle générale d'horloge elle renseigne également l'heure GMT au format dit UNIX, c'est-à-dire un nombre de 32 bits qui mesure le nombre de secondes écoulées depuis le lier janvier 1970.TLS; since the security modules do not generally include a clock, it also informs the GMT time in the so-called UNIX format, that is to say a number of 32 bits which measures the number of seconds elapsed since January 1, 1970. .
5.3.3 Process-TLS5.3.3 Process-TLS
Les paquets TLS, c'est-à-dire les messages produits par une l'entité RECORD, sont transmis au module de sécurité à l'aide de la commande Process- TLS (Record-Packets) qui retourne un ou plusieurs messages RECORD. Record-Packets = Process-TLS ( Record-Packets )TLS packets, that is, messages generated by a RECORD entity, are transmitted to the security module using the Process-TLS (Record-Packets) command that returns one or more RECORD messages. Record-Packets = Process-TLS (Record-Packets)
5.3.4 GET-Kevs bloc5.3.4 GET-Kevs block
Lorsque un module de sécurité TLS a conduit avec succès l'authentification de son interlocuteur il calcule le keys_bloc, la couche RECORD bascule en mode chiffré, et délivre les messages CCS et FINISHED. La commande GET-Keys_bloc collecte alors l'ensemble des clés disponibles, keys_bloc = GET-Keys_bloc ( )When a TLS security module has successfully passed the authentication of its interlocutor it calculates the keys_bloc, the RECORD layer switches to encrypted mode, and delivers the messages CCS and FINISHED. The GET-Keys_bloc command then collects all available keys, keys_bloc = GET-Keys_bloc ()
L'utilisateur des services du module de sécurité peut alors gérer de manière autonome (sans l'aide du module de sécurité) sa propre couche RECORD. En effet il connaît les clés du canal sécurisé (keys_bloc) et la valeur courante du paramètre seq_num égale à 1 (la valeur 0 a été utilisé pour le calcul d'intégrité HMAC du message FINISHED).The user of the services of the security module can then manage autonomously (without the help of the security module) his own layer RECORD. Indeed it knows the keys of the secure channel (keys_bloc) and the current value of the parameter seq_num equal to 1 (the value 0 was used for the calculation of HMAC integrity of the message FINISHED).
5.3.5 Compute-Keys bloc La commande Compute-Keys_bloc() associée aux nombres aléatoires générés par l'entité cliente et l'entité serveur (Client-Random et Server-Random) permet de calculer le paramètre « keys_bloc » . Elle est utile lors d'une session de type « Session Resumption », ou l'utilisateur du module de sécurité emploie ce dernier, uniquement pour l'obtention du keys_bloc. keys_bloc = Compute-Keys_bloc ( Client-Random, Server-Random)5.3.5 Compute-Keys block The Compute-Keys_bloc () command associated with the random numbers generated by the client entity and the server entity (Client-Random and Server-Random) makes it possible to calculate the "keys_bloc" parameter. It is useful during a session of type "Session Resumption", or the user of the security module uses the latter, only to obtain keys_bloc. keys_bloc = Compute-Keys_bloc (Client-Random, Server-Random)
II est important de remarquer que dans ce cas le module de sécurité n'exporte pas la valeur du « master_secret ». Il est donc impossible de conduire une session de type « Session Resumption » en l'absence du module de sécurité, qui garantit donc la bonne foi de l'usager du service. 5.3.6 GET-Cipher suiteIt is important to note that in this case the security module does not export the value of the "master_secret". It is therefore impossible to conduct a Session Resumption session in the absence of the security module, which guarantees the good faith of the service user. 5.3.6 GET-Cipher suite
Une commande GET-Cipher_suite permet de connaître les paramètres de sécurité, indexés par le nombre cipher_suite, associé à l'entité RECORD cipher_suite = Get-Cipher_suite ( )A command GET-Cipher_suite makes it possible to know the security parameters, indexed by the number cipher_suite, associated with the entity RECORD cipher_suite = Get-Cipher_suite ()
5.3.7 GET-SessionID La commande GET-SessionID retourne le paramètre « SessionID » associé à la session courante ou à la session précédente. C'est une information utile pour l'utilisateur qui désire gérer partiellement un « Session Resumption ».5.3.7 GET-SessionID The GET-SessionID command returns the "SessionID" parameter associated with the current session or the previous session. This is useful information for the user who wants to partially manage a Session Resumption.
SessionID = GET-SessionID( )SessionID = GET-SessionID ()
5.3.8 GET- Master secret La commande GET-Master_secret() collecte le « master_secret » associé au « SessionID » de la session courante ou précédente. Elle est optionnelle et correspond à une politique de gestion des « Session Resumption » pour laquelle l'utilisateur n'utilise pas le service de calcul du « keys_bloc ». master_secret = GET-Master_secret ( ) 5.4 Mises en œuyre du protocole5.3.8 GET- Secret Master The GET-Master_secret () command collects the "master_secret" associated with the "SessionID" of the current or previous session. It is optional and corresponds to a "Session Resumption" management policy for which the user does not use the "keys_bloc" calculation service. master_secret = GET-Master_secret () 5.4 Implementation of the protocol
A l'aide des huit commandes décrites précédemment il est possible mettre en œuvre au moins trois modes principaux d'usage, par un utilisateur, d'un module de sécurité TLS. Un premier mode est illustré par la figure 3. Il s'agit de la mise en œuvre du procédé selon l'invention appliqué à une ouverture de session en mode dit de « full session » utilisant l'algorithme RSA, avec mutuelle authentification ("Client Authentication Handshake"). Une entité cliente (350) initie cette dernière par un message ClientHello (301). Une entité entité serveur (360) répond par un ensemble de messages ServerHello (302), Certificate (303), CertificateRequest (304), ServerHelloDone (305). L'entité cliente délivre alors les messages Certificate (306), CertificateVerify (307), ClientKeyExchange (308), ChangeCipherSpec (309), et Finished (310).Using the eight commands described above it is possible to implement at least three main modes of use by a user of a TLS security module. A first mode is illustrated in FIG. 3. It concerns the implementation of the method according to the invention applied to a "full session" mode login using the RSA algorithm, with mutual authentication (" Client Authentication Handshake "). A client entity (350) initiates the latter with a ClientHello message (301). A server entity entity (360) responds with a set of ServerHello (302), Certificate (303), CertificateRequest (304), ServerHelloDone (305) messages. The client entity then delivers the messages Certificate (306), CertificateVerify (307), ClientKeyExchange (308), ChangeCipherSpec (309), and Finished (310).
Dans cette procédure l'entité cliente vérifie la validité du certificat du serveur, en extrait sa clé publique RSA, puis lui transmet une valeur baptisée pre_master_secret chiffrée de cette clé. Le master_secret est calculé partir des éléments Client-Random, Server-Random et pre-master-secret. Le message CertificateVerify (307) contient une signature réalisée avec la clé privée RSA du client, qui prouve l'identité de ce dernier (son certificat présent dans le message Certificate (306)).In this procedure, the client entity verifies the validity of the server certificate, extracts its public RSA key, and then sends it a value called encrypted pre_master_secret of this key. The master_secret is calculated from the Client-Random, Server-Random and pre-master-secret elements. The CertificateVerify message (307) contains a signature made with the RSA private key of the client, which proves the identity of the latter (its certificate present in the message Certificate (306)).
Au terme de cette procédure d' authentification l'entité cliente et l'entité serveur disposent d'une nouvelle valeur master_secret à partir de laquelle sont déduites les clés du keys_bloc. Un paramètre SessionID transmis dans le message ServerHello fournit un index du master_secret. Par la suite les données générées par la couche APPLICATION sont transportées par l'entité RECORD (313) (313), qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki.At the end of this authentication procedure, the client entity and the server entity have a new value master_secret from which the keys of the keys_bloc are deduced. A SessionID parameter passed in the ServerHello message provides an index of the master_secret. Subsequently, the data generated by the APPLICATION layer is transported by the RECORD entity (313) (313), which ensures the confidentiality and integrity thereof by means of the keys Kc and Ki.
Les étapes précédemment décrites sont mise en œuvre au sein de modules de sécurité : un pour l'entité cliente (35) et un pour l'entité entité serveur (36). Ainsi que cela est représenté sur la figure 3, les étapes précédemment décrites ne sont pas mises en œuvre au sein des entités clientes (350) et des entités entité serveur (360) mais ne font que « transiter » par ces entités). La mise en œuvre effective est réalisée au sien des modules de sécurité à l'aide de commandes de l'interface fonctionnelle du module.The previously described steps are implemented within security modules: one for the client entity (35) and one for the entity server entity (36). As shown in FIG. 3, the previously described steps are not implemented within client entities (350) and entity entities server (360) but only "transit" through these entities). The actual implementation is carried out with the security modules using commands of the functional interface of the module.
Dans chacun des deux modules de sécurité mis en œuvre, quatre commandes sont utilisées : « Start » (3001, 3002) pour l'initialisation d'une session TLS, « Process-TLS » traite les paquets TLS (non représentée), « GET- keys_bloc » (3003, 3004) collecte les clés de la couche RECORD et « GET-In each of the two security modules implemented, four commands are used: "Start" (3001, 3002) for the initialization of a TLS session, "Process-TLS" processes the TLS packets (not shown), "GET - keys_bloc "(3003, 3004) collects the keys of the RECORD layer and" GET-
Cipher_suite » (3005, 3006) indique la liste des algorithmes cryptographiques employés pour la gestion du canal sécurisé. L'entité cliente ouvre une session TLS avec une entité serveur écoutant typiquement sur le port TCP 443. Dans cette illustration, un module de sécurité est mis en œuvre du côté de l'entité clienteCipher_suite "(3005, 3006) indicates the list of cryptographic algorithms used for managing the secure channel. The client entity opens a TLS session with a server entity typically listening on TCP port 443. In this illustration, a security module is implemented on the client entity side
(350) et du côté de l'entité entité serveur (360).(350) and on the server entity entity side (360).
Un deuxième mode est présenté à la figure 4. Dans ce cas une précédente session de type « FuIl Session » a permis d'obtenir un « master_secret » identifié par un index « SessionID ». La phase d'authentification est simplifiée et consiste pour les deux parties (entité cliente et serveur) à prouver leur connaissance de la valeur master_secret. L'entité cliente (440) ouvre la session TLS par un message ClientHello (401) contenant l'index (SessionID) d'une session précédente. L'entité serveur (460) répond par un ensemble de messages « ServerHello » (402), « ChangeCipherSpec » (403), et « Finished » (404). Il indique la reprise de session en insérant une valeur « SessionID » dans le message « ServerHello » identique à celle contenue dans le message « ClientHello ». L'entité cliente délivre alors les messages, « ChangeCipherSpec » (405), et « Finished » (406).A second mode is shown in Figure 4. In this case a previous session type "FuIl Session" has obtained a "master_secret" identified by a "SessionID" index. The authentication phase is simplified and consists of both parties (client entity and server) to prove their knowledge of the master_secret value. The client entity (440) opens the TLS session with a ClientHello message (401) containing the index (SessionID) of a previous session. The server entity (460) responds with a set of messages "ServerHello" (402), "ChangeCipherSpec" (403), and "Finished" (404). It indicates the session restart by inserting a "SessionID" value in the "ServerHello" message identical to that contained in the "ClientHello" message. The client entity then delivers the messages, "ChangeCipherSpec" (405), and "Finished" (406).
Le « master_secret » n'est pas recalculé, cependant un nouvel ensemble « keys_bloc » est obtenu à partir des éléments « master_secret », « ClientRandom » et « ServerRandom ».The "master_secret" is not recalculated, however a new set "keys_bloc" is obtained from the elements "master_secret", "ClientRandom" and "ServerRandom".
Keys_block =Keys_block =
PRF(master_secret, "key expansion", server_random | client_random) . Par la suite les données générées par la couche APPLICATION sont transportées par l'entité RECORD (407) (408), qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki.PRF (master_secret, "key expansion", server_random | client_random). Subsequently, the data generated by the APPLICATION layer is transported by the RECORD entity (407) (408), which ensures the confidentiality and integrity thereof by means of the keys Kc and Ki.
Le mécanisme dit de « Session Resumption » simplifie l'échange d'information lors d'une session TLS. Une première FuIl Session effectue l'authentification simple ou mutuelle des deux extrémités (entité cliente et serveur) et produit un master_secret. Les sessions suivantes, basées sur le mécanisme de reprise de session réutilisent le master_secret pour le calcul de nouvelles clés de chiffrement et d'intégrité. Dans ce mode de réalisation, une session de type « Session Resumption » est négociée entre une entité cliente et une entité serveur. La valeur du « master_secret » est protégée par le module de sécurité côté entité cliente et/ou serveur.The so-called Session Resumption mechanism simplifies the exchange of information during a TLS session. A first session FuIl performs simple or mutual authentication of both ends (client entity and server) and produces a master_secret. The following sessions, based on the session recovery mechanism, reuse the master_secret for the calculation of new encryption and integrity keys. In this embodiment, a Session Resumption session is negotiated between a client entity and a server entity. The value of the "master_secret" is protected by the security module on the client entity and / or server side.
Trois commandes sont nécessaires; « Start » (4001, 4002) initialise un module de sécurité; « GET-SessionID » (4003, 4005) récupère le « SessionID » d'un précédente session qui peut être inséré dans le message « Client-Hello » (4001) ou permettre la vérification de l'existence d'un « master_secret » côté serveur (4003) «Compute-Keys_bloc() » calcule le « keys_bloc » à l'aide des nombres aléatoires échangés par l'entité cliente (4004) et l'entité serveur (4006). Un troisième mode est explicité par la figure 5. Une session de typeThree commands are needed; "Start" (4001, 4002) initializes a security module; "GET-SessionID" (4003, 4005) retrieves the "SessionID" from a previous session that can be inserted into the "Client-Hello" message (4001) or allows verification of the existence of a "master_secret" side server (4003) "Compute-Keys_bloc ()" calculates the "keys_bloc" using the random numbers exchanged by the client entity (4004) and the server entity (4006). A third mode is explained in Figure 5. A typical session
« Session Resumption » est négociée entre une entité cliente (550) et une entité serveur (560). La valeur du « master_secret » est stockée par le module de sécurité côté client (55) et/ou serveur (56)."Session Resumption" is negotiated between a client entity (550) and a server entity (560). The value of the "master_secret" is stored by the client-side (55) and / or server (56) security module.
Trois commandes sont nécessaires; « Start » (5001, 5002) initialise un module de sécurité; « GET-SessionID » récupère le « SessionID » d'un précédente session qui peut être inséré dans le message « ClientHello » (5003) ou permettre la vérification de l'existence d'un « master_secret » côté serveur (5005). « GET-Master-secret » retourne la valeur du « master-secret » (5004, 5006). Ce mode de fonctionnement est compatible avec des logiciels tels que « OpenSSL » qui utilisent des objets « SESSION » stockés dans des fichiers. Le module de sécurité joue dans ce cas un rôle de cache amovible de la valeur du « master_secret ». Les étapes 401 à 408 sont identiques à celle décrites en relation avec la figure 4.Three commands are needed; "Start" (5001, 5002) initializes a security module; "GET-SessionID" retrieves the "SessionID" from a previous session that can be inserted into the "ClientHello" message (5003) or allows verification of the existence of a "master_secret" on the server side (5005). "GET-Master-secret" returns the value of the "master-secret" (5004, 5006). This mode of operation is compatible with software such as "OpenSSL" that uses "SESSION" objects stored in files. The module security plays in this case a removable cache role of the value of the "master_secret". Steps 401 to 408 are identical to those described in relation to FIG. 4.
5.5 Description d'un module de sécurité selon l'invention On présente, en relation avec la figure 6, un module de sécurité sous la forme d'un circuit intégré de silicium (600), qualifié usuellement de "Tamper Résistant Device", littéralement un "composant qui résiste aux attaques", tel que par exemple le composant ST22 (produit par la société ST Microelectronics) et disponible sous différents formats tels que des cartes en PVC, (cartes à puce, carte SIM,...) intégrées dans des jetons USB, ou dans des mémoires MMC (MultiMedia Card).5.5 Description of a security module according to the invention In connection with FIG. 6, a security module in the form of a silicon integrated circuit (600), usually referred to as "Tamper Resistant Device", literally a "component that resists attacks", such as for example the ST22 component (produced by the company ST Microelectronics) and available in different formats such as PVC cards, (smart cards, SIM card, ...) integrated into USB tokens, or in MMC (MultiMedia Card) memories.
Un tel module de sécurité incorpore tous les moyens sécurisés de stockage de données, et permet également l'exécution de logiciels dans un environnement sûr et protégé. Plus précisément il comporte une unité centrale (CPU, 601), une mémoireSuch a security module incorporates all secure means of data storage, and also allows the execution of software in a secure and protected environment. More precisely, it comprises a central unit (CPU, 601), a memory
ROM stockant le code du système d'exploitation (602), de la mémoire RAM (603), et une mémoire non volatile (NVR, 604), utilisée comme dispositif de stockage analogue à une disque dur, et qui contient par exemple un logiciel embarqué TLS. Un bus système (610) relie les différents organes du module sécurisé. L'interface avec le monde extérieur (620) est assuré par un port IO d'entrée/sortie (605), conforme à des standards tels que ISO6816, USB, USB- OTG, ISO6816-12, MMC, IEEE 802.3, IEEE 802.11, etc.ROM storing operating system code (602), RAM memory (603), and nonvolatile memory (NVR, 604), used as a hard disk-like storage device, and which contains, for example, software embedded TLS. A system bus (610) connects the various members of the secure module. The interface to the outside world (620) is provided by an IO input / output port (605), compliant with standards such as ISO6816, USB, USB-OTG, ISO6816-12, MMC, IEEE 802.3, IEEE 802.11 etc.
Les cartes à puces JAVA, communément désignées par le terme JAVACARD, sont une classe particulière de module de sécurité. JAVA smart cards, commonly referred to as JAVACARD, are a special class of security module.

Claims

REVENDICATIONS
1. Procédé de production de données de sécurisation, permettant la mise en œuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées, caractérisé en ce que lesdites données de sécurisation sont des données de mise en oeuvre d'un protocole SSL ou TLS et en ce que ledit procédé comprend :A method for producing security data, enabling the implementation of a secure session between a first and at least a second entity, according to a secure session establishment protocol, characterized in that said security data is implementation data of an SSL or TLS protocol and in that said method comprises:
- une étape d'initialisation d'une troisième entité sécurisée, liée à ladite première entité ; - une étape de génération d'au moins une partie desdites données de sécurisation au sein de ladite troisième entité ;a step of initializing a third secure entity, linked to said first entity; a step of generating at least a part of said security data within said third entity;
- une étape de transmission desdites données de sécurisation de ladite troisième entité sécurisée vers ladite première entité.a step of transmitting said security data from said third secure entity to said first entity.
2. Procédé de production selon la revendication 1, caractérisé en ce que ladite troisième entité est une carte à puce de type « JavaCard ».2. Production method according to claim 1, characterized in that said third entity is a "JavaCard" type smart card.
3. Procédé de production selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite en ce qu'il comprend en outre :3. Production method according to any one of claims 1 and 2, characterized in that said in that it further comprises:
- une étape de transmission, par ladite première entité, d'au moins un message à destination d'une couche « RECORD » mise en œuvre au sein de ladite troisième entité ;a step of transmission, by said first entity, of at least one message intended for a "RECORD" layer implemented within said third entity;
- une étape de réception, par ladite première entité, d'au moins un message en provenance de ladite couche « RECORD » ;a step of reception, by said first entity, of at least one message coming from said "RECORD" layer;
- une étape de calcul d'un ensemble de clés par ladite troisième entité ;a step of calculating a set of keys by said third entity;
- une étape de collecte dudit ensemble de clés disponibles par ladite première entité auprès de ladite troisième entité ;a step of collecting said set of keys available by said first entity from said third entity;
- une étape de récupération d'un identifiant de session de communication sécurisée.a step of recovering a secure communication session identifier.
4. Dispositif de production de données de sécurisation, permettant la mise en œuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées, caractérisé en ce qu'il comprend :4. Device for producing security data, enabling the implementation of a secure session between a first and at least a second entity, according to a secure session establishment protocol, characterized in that it comprises:
- des moyens d'initialisation, attachée à ladite première entité ;initialization means, attached to said first entity;
- des moyens de génération d'au moins une partie desdites données de sécurisation ; - des moyens de transmission desdites données de sécurisation vers ladite première entité.means for generating at least part of said security data; means for transmitting said security data to said first entity.
5. Dispositif de production de données de sécurisation selon la revendication 4, caractérisé en ce que lesdits moyens de génération et lesdits moyens de transmission sont regroupés dans une carte à puce. 5. Device for producing security data according to claim 4, characterized in that said generating means and said transmission means are grouped in a smart card.
6. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de production selon l'une au moins des revendications 1 à 3, lorsqu'il est exécuté sur un ordinateur. 6. Computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of the method production system according to at least one of claims 1 to 3 when executed on a computer.
EP08750344A 2007-05-25 2008-05-19 Method for securing information exchange, and corresponding device and computer software product Withdrawn EP2153613A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0703743A FR2916592B1 (en) 2007-05-25 2007-05-25 INFORMATION EXCHANGE SECURING METHOD, DEVICE, AND CORRESPONDING COMPUTER PROGRAM PRODUCT
PCT/EP2008/056136 WO2008145558A2 (en) 2007-05-25 2008-05-19 Method for securing information exchange, and corresponding device and computer software product

Publications (1)

Publication Number Publication Date
EP2153613A2 true EP2153613A2 (en) 2010-02-17

Family

ID=38690408

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08750344A Withdrawn EP2153613A2 (en) 2007-05-25 2008-05-19 Method for securing information exchange, and corresponding device and computer software product

Country Status (7)

Country Link
US (1) US8646041B2 (en)
EP (1) EP2153613A2 (en)
CN (1) CN101809964A (en)
CA (1) CA2689015A1 (en)
FR (1) FR2916592B1 (en)
RU (1) RU2487482C2 (en)
WO (1) WO2008145558A2 (en)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2943198B1 (en) 2009-03-16 2011-05-20 Groupe Des Ecoles De Telecommunications Get Ecole Nationale Superieure Des Telecommunications Enst METHOD FOR PRODUCING SECURITY DATA, APPARATUS AND CORRESPONDING COMPUTER PROGRAM
FR2945650B1 (en) * 2009-05-13 2011-05-06 Groupe Ecoles Telecomm METHOD FOR SECURING DOCUMENTS BY APPLYING A CLEAN IDENTIFICATION NUMBER AND APPARATUS FOR AUTHENTICATING SAID NUMBER.
US8875219B2 (en) * 2009-07-30 2014-10-28 Blackberry Limited Apparatus and method for controlled sharing of personal information
JP5923161B2 (en) 2011-03-29 2016-05-24 ヴィフォール （インターナショナル） アクチェンゲゼルシャフトＶｉｆｏｒ （Ｉｎｔｅｒｎａｔｉｏｎａｌ） ＡＧ Iron (III) complex compounds for the treatment and prevention of iron deficiency symptoms and iron deficiency anemia
US20140248342A1 (en) 2011-05-31 2014-09-04 Vifor (International) Ag Fe(III) 2,4-Dioxo-1-Carbonyl Complexes For Treatment And Prophylaxis Of Iron Deficiency Symptoms And Iron Deficiency Anaemias
CN102930847B (en) * 2011-08-09 2015-03-18 锋厚科技股份有限公司 Multi-switching display control device, matrix type display control device and control method thereof
US9537899B2 (en) 2012-02-29 2017-01-03 Microsoft Technology Licensing, Llc Dynamic selection of security protocol
RU2641030C2 (en) 2012-12-21 2018-01-15 Вифор (Интернациональ) Аг Complex compounds of ferric iron for treatment and prevention of symptoms of iron deficiency and iron deficiency anemia
CN103618726A (en) * 2013-12-04 2014-03-05 北京中创信测科技股份有限公司 Method for recognizing mobile data service based on HTTPS
US11399019B2 (en) * 2014-10-24 2022-07-26 Netflix, Inc. Failure recovery mechanism to re-establish secured communications
US11533297B2 (en) 2014-10-24 2022-12-20 Netflix, Inc. Secure communication channel with token renewal mechanism
US10050955B2 (en) 2014-10-24 2018-08-14 Netflix, Inc. Efficient start-up for secured connections and related services
US10129031B2 (en) * 2014-10-31 2018-11-13 Convida Wireless, Llc End-to-end service layer authentication
US9854000B2 (en) 2014-11-06 2017-12-26 Cisco Technology, Inc. Method and apparatus for detecting malicious software using handshake information
KR102001753B1 (en) 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 End-to-end authentication at the service layer using public keying mechanisms
US9955199B2 (en) * 2015-07-23 2018-04-24 Panasonic Avionics Corporation Transfer of consumable data to vehicles
US10635370B2 (en) * 2016-03-31 2020-04-28 Tanita Corporation Image forming apparatus that acquires data from an activity amount meter
DE102017202953A1 (en) * 2017-02-23 2018-08-23 Bundesdruckerei Gmbh Access control device and method for authentication of an access authorization
US20200389322A1 (en) * 2017-12-07 2020-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Security for group communication
US11165824B2 (en) * 2019-10-18 2021-11-02 Cisco Technology, Inc. Transport layer security extension for hybrid information centric networking

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046544A1 (en) * 2001-09-06 2003-03-06 Roskind James Anthony Digital certificate proxy

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
UA53651C2 (en) * 1996-06-05 2003-02-17 Сіменс Акцієнгезельшафт Method of cryptographic coded data communication between two computers
AU4781899A (en) * 1998-07-03 2000-01-24 Nokia Mobile Phones Limited Secure session set up based on the wireless application protocol
FR2805062B1 (en) * 2000-02-10 2005-04-08 Bull Cp8 METHOD FOR TRANSMITTING HIGH-FLOW DATA STREAMS OVER AN INTERNET-TYPE NETWORK BETWEEN A SERVER AND A CHIP-CARD TERMINAL, IN PARTICULAR A MULTIMEDIA DATA STREAM
CA2305249A1 (en) * 2000-04-14 2001-10-14 Branko Sarcanin Virtual safe
US20040218762A1 (en) * 2003-04-29 2004-11-04 Eric Le Saint Universal secure messaging for cryptographic modules
US7996888B2 (en) * 2002-01-11 2011-08-09 Nokia Corporation Virtual identity apparatus and method for using same
EP1349032B1 (en) * 2002-03-18 2003-11-19 Ubs Ag Secure user authentication over a communication network
US7246236B2 (en) * 2002-04-18 2007-07-17 Nokia Corporation Method and apparatus for providing peer authentication for a transport layer session
US7007163B2 (en) * 2002-05-31 2006-02-28 Broadcom Corporation Methods and apparatus for accelerating secure session processing
RU2295200C2 (en) * 2002-08-16 2007-03-10 Тогева Холдинг Аг Method and system for gsm-authentication during roaming in wireless local networks
US7373500B2 (en) * 2003-04-15 2008-05-13 Sun Microsystems, Inc. Secure network processing
US20040210663A1 (en) * 2003-04-15 2004-10-21 Paul Phillips Object-aware transport-layer network processing engine
US20050181875A1 (en) * 2004-02-18 2005-08-18 Coin Mechanisms, Inc. Mobile lottery, gaming and wagering system and method
WO2006021865A1 (en) * 2004-08-24 2006-03-02 Axalto Sa A personal token and a method for controlled authentication.
US7451921B2 (en) * 2004-09-01 2008-11-18 Eric Morgan Dowling Methods, smart cards, and systems for providing portable computer, VoIP, and application services
US7565536B2 (en) * 2005-09-02 2009-07-21 Gemalto Inc Method for secure delegation of trust from a security device to a host computer application for enabling secure access to a resource on the web
US7725928B2 (en) * 2005-12-02 2010-05-25 Palo Alto Research Center Incorporated System and method for establishing temporary and permanent credentials for secure online commerce
US20080022374A1 (en) * 2006-06-29 2008-01-24 Research In Motion Limited System and method for securely communicating with a server

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046544A1 (en) * 2001-09-06 2003-03-06 Roskind James Anthony Digital certificate proxy

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2008145558A3 (en) 2009-03-19
US20100257588A1 (en) 2010-10-07
FR2916592B1 (en) 2017-04-14
CA2689015A1 (en) 2008-12-04
CN101809964A (en) 2010-08-18
WO2008145558A2 (en) 2008-12-04
RU2487482C2 (en) 2013-07-10
FR2916592A1 (en) 2008-11-28
US8646041B2 (en) 2014-02-04
RU2009147315A (en) 2011-06-27

Similar Documents

Publication Publication Date Title
EP2153613A2 (en) Method for securing information exchange, and corresponding device and computer software product
US11477037B2 (en) Providing forward secrecy in a terminating SSL/TLS connection proxy using ephemeral Diffie-Hellman key exchange
US10091240B2 (en) Providing forward secrecy in a terminating TLS connection proxy
CN114651421B (en) Forward security in transport layer security using temporary keys
US7899185B2 (en) Real privacy management authentication system
EP3232632A1 (en) Method and system for acquiring plaintext of network secret data
EP2012907A2 (en) Identity protection method, devices and corresponding computer programme product
FR2906661A1 (en) METHOD FOR PROVIDING AUTHENTICATION PARAMETERS AND SOFTWARE IMAGES IN SECURE NETWORK ENVIRONMENTS
EP3375133B1 (en) Method for securing and authenticating a telecommunication
CN113950802B (en) Gateway device and method for performing site-to-site communication
EP3216163B1 (en) Providing forward secrecy in a terminating ssl/tls connection proxy using ephemeral diffie-hellman key exchange
WO2010142740A1 (en) Device and method for secure access to a remote server
EP1227640A1 (en) Method and system for communicating a certificate between a security module and a server
EP2409474A1 (en) Method for generating security data, and corresponding device and computer program
EP3266148B1 (en) Device and method for administering a digital escrow server
FR2899750A1 (en) Common encryption key generating method for e.g. voice over Internet protocol application, involves verifying correspondence between control data displayed on terminal of one user and control data received from another user by latter user
WO2012156365A1 (en) Method for securing an authentication platform, and corresponding hardware and software
FR2901084A1 (en) User`s identity protecting method for e.g. mobile telephone, involves ensuring protection of identity of client device user, and deriving encryption key from less weightage bits of key generated from premaster secret and random values
WO2023175253A1 (en) Method for the authentication of a slave device by a host device
EP4160987A1 (en) Method for generating an electronic signature using fido

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20091124

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130306

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GROUPE DES ECOLES DE TELECOMMUNICATIONS - ECOLE NA

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

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

18D Application deemed to be withdrawn

Effective date: 20161201