WO2010106042A1 - Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant - Google Patents

Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant Download PDF

Info

Publication number
WO2010106042A1
WO2010106042A1 PCT/EP2010/053334 EP2010053334W WO2010106042A1 WO 2010106042 A1 WO2010106042 A1 WO 2010106042A1 EP 2010053334 W EP2010053334 W EP 2010053334W WO 2010106042 A1 WO2010106042 A1 WO 2010106042A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
secure
security
session
security data
Prior art date
Application number
PCT/EP2010/053334
Other languages
English (en)
Inventor
Pascal Urien
Original Assignee
Institut Telecom / Telecom Paristech
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 Institut Telecom / Telecom Paristech filed Critical Institut Telecom / Telecom Paristech
Priority to CA2754895A priority Critical patent/CA2754895A1/fr
Priority to CN2010800123317A priority patent/CN102356621A/zh
Priority to RU2011139616/08A priority patent/RU2011139616A/ru
Priority to US13/257,221 priority patent/US20120072994A1/en
Priority to EP10711036A priority patent/EP2409474A1/fr
Publication of WO2010106042A1 publication Critical patent/WO2010106042A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • 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

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 published patent application WO 2008/145558 describes a method for securing exchanges in which a production of security data is performed for the implementation of a secure session between a first and a second entity, according to an establishment protocol.
  • secure sessions such as SSL or TLS.
  • This method makes it possible to partially solve the disadvantages posed by the implementation of the SSL and TLS protocols by non-secure entities.
  • This method comprises an initialization of a third party secure entity, linked to the first entity, a generation of a part of the security data within the third entity and a transmission of the security data of the third secure entity to said first entity .
  • the third entity is for example a JavaCard-type smart card that carries out part of the calculations necessary to establish the secure session.
  • WO 2008/145558 makes it possible to initiate an exchange of data between two entities while having the assurance that the crypto graphics material necessary to establish the session has been designed in a secure manner.
  • WO 2008/145558 can not be used alone when high performance is required and many secure sessions must run in parallel.
  • the invention does not have these disadvantages of the prior art. Indeed, the invention relates to a method for producing security data, allowing the implementation of a secure session between a first and at least a second entity, according to a secure session establishment protocol.
  • such a method comprises: 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; a first step of transmitting said generated security data from said third secure entity to said first entity; a second step of transmitting at least a portion of said security data generated within said third entity secure to at least a fourth secure entity previously initialized and linked to said third secure entity.
  • the invention allows different secure entities, such as for example chips, smart cards, "dongles" to have security data, such as encryption data while not having the need to generate they themselves these data.
  • security data such as encryption data while not having the need to generate they themselves these data. This data is generated through another secure entity and transmitted after creation to be reused thereafter.
  • said third entity said master entity, generates at least a portion of a shared secret between said first and said second entity.
  • said at least part of said generated security data transmitted to said at least one fourth entity, said slave entity comprises said shared secret in an encrypted form and at least one secure communication session identifier.
  • said secure session establishment protocol is the SSL protocol.
  • said secure session establishment protocol is the TLS protocol.
  • said production method further comprises: a step of transmission, by said first entity, of at least one message to a functional unit "RECORD" implemented within said third entity; a step of receiving, by said first entity, at least one message from said functional unit "RECORD”; a step of calculating a set of keys by said third entity; a step of collecting said set of keys available by said first entity to said third entity.
  • the invention is able to generate secrets shared by several secure entities, such as for example several smart cards, because the set of keys is calculated by the third entity.
  • said second transmission step is implemented by a security module manager which obtains said security data from said third entity.
  • said second transmission step is implemented during a recovery phase of said secure session.
  • the invention also relates to a method of establishing a secure communication session between a first and at least a second entity, according to a secure session establishment protocol.
  • a method of establishing a secure communication session between a first and at least a second entity comprises: a step of obtaining a session identifier and an ephemeral secret calculated during a previous secure communication session by a third secure entity linked to said first entity; a step of transmitting said session identifier and said ephemeral secret to a fourth secure entity, previously initialized and linked to said third secure entity; a step of establishing said secure communication session using said fourth secure entity.
  • the invention makes it possible to use other secure entities, such as smart cards or javacards for the establishment of secure communication sessions that have been previously initialized by another secure entity. Accordingly, the invention allows parallel processing of multiple transactions, such as file downloads, using the services of multiple secure entities, while minimizing the time required for session establishment, while providing excellent security level.
  • 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 protocol for establishing security data. secure sessions.
  • a device for producing security data comprises: means for initializing a third secure entity, attached to said first entity; means for generating at least a part of said security data; means for transmitting said security data to said first entity; means for transmitting at least a portion of said security data generated within said third secure entity to at least a fourth secure entity previously initialized and linked to said third secure entity.
  • said generation means and said transmission means are grouped together in a smart card.
  • the invention also relates to a portable device, such as a USB token, comprising means for storing a security module manager and at least two card readers in SIM format and a device for production of security data as described above.
  • 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, and comprising program code instructions for the computer. execution of the production method as described above.
  • 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, and comprising program code instructions for the computer. execution of the session establishment 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 security method using a security module grid according to the invention
  • FIG. 3 presents the logical architecture of a grid of security modules according to the invention
  • FIG. 4 describes an architecture of a device for producing security data, also called a security module.
  • the general principle of the invention is based on a joint implementation of a set comprising several security modules, and called security module grid.
  • This grid of security modules thus comprises several secure entities involved in the establishment of the secure communication session.
  • the invention solves the performance problems inherent in the use of external secure entities.
  • the invention raises the level of security during the establishment of the secure session while maintaining the general performance of the authentication system consisting of entities wishing to establish a secure session (for example a client and a server ) and the security module grid (comprising the third and fourth entities) which is for example linked to the customer.
  • the security module grid may be embodied in the form of one or more smart cards to be inserted in a specific card reader, of a "dongle” type module, for example to be inserted into a slot.
  • type “USB” of the “Universal Serial Bus” of a computer or any other form allowing communication between the entity that wishes to establish the secure session and the security module grid.
  • the grid of security modules can be dedicated to the implementation of a particular protocol such as SSL and / or TLS. However, this is not the only possible embodiment of the invention. It is indeed quite possible that the grid of security modules can implement several protocols to ensure greater interoperability.
  • a security module designates, in the context of the invention, a chip usually qualified as "Tamper Resistant Device ", literally a” component that resists attacks ", which is able to handle physical and logical countermeasures.
  • This security module includes an SSL / TLS software stack comprising the functional units HANDSHAKE, ALERT, CCS and RECORD which are well known to those skilled in the art.
  • This security module communicates with a user entity (client or server) using a functional interface for exchanging SSL / TLS protocol messages and for obtaining at least four types of parameters: "keys_bloc", “cipher_suite” ",” SessionID "and the numerical value of the" master _secret ".
  • the encrypted value of the "master-secret” ⁇ Master _secr and *) is obtained by means of a secret key shared between the different security modules and a public value knows, according to the relation,
  • the user entity of the security module manages a communication layer and integrates the functional units ALERT and RECORD and optionally the functional units HANDSHAKE and CCS.
  • the information from the APPLICATION layer is secured by the RECORD layer.
  • the invention proposes to jointly implement the user entity and the security module grid to establish a secure session with a server. Cleverly, some of the steps necessary to establish the session is performed through the security module grid while the other part is performed by the user entity. It may be, in a particular embodiment of the invention, that the steps implemented by the user entity and by the security module grid differ each time a new secure session is created. In this way, it is more difficult to predict the general operation of the system and to attempt to force the security mechanism offered by the invention.
  • a slave security module depends on a master security module without which it can not operate. More particularly, according to the invention, a master module is the only one capable of calculating a particular ephemeral secret (the "mastersecret", the latter term being used later). It will be recalled that the "mastersecret”, in the context for example of the implementation of the TLS protocol, is calculated during the so-called "Ml mode" phase. During this phase, the exchanges between the client and the server make it possible to calculate a common secret, shared between the client and the server and which serves as a basis for the creation of all the other encryption data necessary for the secure session.
  • a slave module can use the "mastersecret" calculated by its master module to continue a session secure or to perform other operations during the secure session.
  • a slave module enters into possession of the "mastersecret” via the master module with which it is associated. To do this, the master module distributes, according to the invention, this "mastersecret” to the slave modules, but in a secure manner.
  • the distribution of the "mastersecret” is performed according to a particular protocol governing data exchanges between the master module and the slave module to which it is associated.
  • a protocol can take the form of commands that are transmitted to these modules to enable the exchange.
  • the identity of the user entity is linked only to the master module. This means that in the process of establishing the secure session, the user entity is not aware of the presence of the slave modules.
  • the method for producing secure data comprises: an initialization step (100) of a security module 1001 (for example a smart card), attached to a first entity 1002 (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. a step of transmitting (103) at least a portion of said data of security generated within the security module 1001 to a second security module 1003 previously initialized and linked to the first security module 1001, thus forming a security module grid 1004 in which at least some security data is shared.
  • a security module 1001 for example a smart card
  • a first entity 1002 for example a personal computer
  • generating (101) a portion of the security data within the security module
  • the invention proposes a grid of security modules, used to establish secure data transmission sessions and which share data to establish these secure transmission sessions.
  • a security module performs the functions of client or TLS server, its embedded software thus includes the functional units HANDSHAKE, ALERT, CCS and RECORD.
  • FIG. 2 shows the TLS security module and its user, that is to say an application provided with a subset of the TLS stack, that is to say the RECORD and ALERT layers and optionally the CCS layers and HANDSHAKE.
  • This user entity can be a client (for example a web browser client application) or a server (for example a web server managing secure sessions).
  • a security module provides a functional interface that includes nine commands, SET-Credentials, Start, Process-TLS, GET-Keys Block, Compute-Keys Block, GET-Cipher Suite, GET-SessionID, GE T-Master_secret, SET-Master - Secret.
  • Such commands can be realized by following the ISO 7816 standard according to a coding commonly called “APDUs” (from the English “Application Protocol Data Unit” for “Data Unit (PDU) Application Layer”).
  • the security module (210) which implements the production method according to the invention comprises the functional units necessary for the implementation of the security method, namely the "RECORD" layers (2104) and
  • the functional interface (220) allows the user entity (200) to call the security module (210) for the production of security data.
  • SET-Credentials command 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 (certificates X509, RSA private key) is enabled by the SET-Credentials () command:
  • 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. :
  • Such a command allows, as it were, to prepare the security module to perform the calculations required in the context of the invention.
  • Process-TLS TLS packets that is messages produced by a RECORD functional unit, are transmitted to the security module using the Process-TLS (Record-Packets) command. returns one or more RECORD messages.
  • a TLS security module When a TLS security module has successfully conducted the authentication of its interlocutor it calculates the keys block, the RECORD layer switches to encrypted mode, and delivers the messages CCS and FINISHED.
  • the user of the services of the security module can then manage autonomously (without the help of the security module) his own layer
  • the Compute-Keys_bloc () command associated with the random numbers generated by the client entity and the server entity makes it possible to calculate the "keys block” parameter. It is useful during a session of type "Session Resumption", or the user of the security module uses the latter, only to obtain the keys block.
  • keys_bloc Compute-Keys_bloc (Client-Random, Server-Random) It 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.
  • a command GET-Cipher suite allows to know the security parameters, indexed by the number cipher suite, associated with the functional unit RECORD.
  • cipher_suite Get-Cipher_suite ()
  • the GET-SessionID command returns the "SessionID" parameter associated with the previous session associated with a particular mastersecret. This is useful information for the security module grid that allows slave modules to perform a Session Resumption phase.
  • SessionID GET-SessionID ()
  • the GET-Master_secret () command collects an encrypted value of the master_secret (master _secret *) as well as a set of parameters (knows) that can be used to decrypt this information.
  • knows GET-Master_secret ()
  • the secret master is encrypted using a symmetric or asymmetric secret key (Key_Module), shared by a set of security modules, and associated with an encryption algorithm (such as AES, Triple DES, RSA) and a random number knows generated by the security module.
  • Key_Module a symmetric or asymmetric secret key
  • an encryption algorithm such as AES, Triple DES, RSA
  • the Set-Master_Secret command (Master_Secret *
  • the invention thus also relates to any smart card or secure entity of this type which comprises the preceding commands for reading, transferring and initializing a secure session from an ephemeral secret (the "mastersecret") calculated by another secure entity.
  • mastersecret an ephemeral secret
  • the invention also relates to a method of establishing a communication session using a secure entity that retrieves the ephemeral secret and the identifier of a session that was previously initialized by another secure entity.
  • These two secure entities are preferably linked together so that they are either present within the same smart card, or they communicate via a specific module that will manage interactions (eg the execution of some of the previously described commands) between the secured entities.
  • a management module also called security module manager, of the type hosting and executing a software providing in particular management and control functions.
  • said software comprising means for executing recovery, storage and transmission commands, for example sent to the software by at least one client software and belonging to a set of recovery, storage and predetermined transmission (GET-Session_ID, GET-Master_Secret, Set-Master_Secret, etc.).
  • GET-Session_ID GET-Master_Secret
  • Set-Master_Secret etc.
  • FIG. 3 presents the logical architecture of a grid of security modules according to the invention.
  • a functional unit called Security Module Manager controls a plurality of security modules.
  • the master modules are identified by indexes ranging from 1 to p.
  • the slave modules are identified by indexes strictly greater than p.
  • a master module stores an X509 certificate but also the private key
  • the master modules share a KeyModule key, used for the encryption and decryption operations of the mastersecret.
  • a slave module shares a KeyModule cryptographic key with the master modules, but does not store the client's private key.
  • p being greater than or equal to 1
  • k n-p slave modules (k may be equal to zero).
  • the Security Module Manager When opening a TCP session, the Security Module Manager first selects a master security module. If this operation is impossible, ie all the master modules are assigned to sessions being opened, a slave module is chosen. If no module is free, the Security Module Manager will wait for the availability of a module.
  • the Security Modules Manager updates the parameters (SessionID, MasterSecrei) used by a previous session using, according to the invention, the Set-Master Secret command. With this procedure it allows a module (master or slave) to manage a session in Resumption mode.
  • a slave module fails in an attempt to open a session in Resumption mode using the data sent by the security module manager, that is, if the server imposes a session in FuIl mode (for example, because the lifetime of the "summarize" session has expired), it completes the current session.
  • the Security Modules Manager collects the SessionID and Master Secret parameters) using the Get-SessionID and Get-MasterSecret commands introduced by the invention. So, the Module Manager Security is able to provide, in a next session, the data collected, both to the master modules and to the slave modules.
  • This grid of security modules 300 comprises a component hosting a security module manager (GMS)
  • the security module gate 300 also includes master modules 302 to 305 that generate at least a portion of the security data related to the entity to which the security module gate is connected.
  • the master modules calculate the value of the MasterSecret for a session in "FuIl" mode.
  • the gate also includes slave security modules 307 to 318.
  • the master modules can be associated with a predetermined number of slave modules (for example three in the example of FIG. 3) thus forming a group of security modules 306. This pre-association is not mandatory.
  • the security module manager 301 can dynamically, as needed, associate the slave security modules according to the number of security sessions required using a functional unit comprising means for obtaining a number of security modules. connection or a number of elements to download, if it is for example an "http" communication session requiring the downloading of images or other elements from a web server.
  • TF and 77? the time required to complete a FULL and RESUMPTION session in a security module. For theoretical reasons mentioned in several scientific publications 77? is less than TF (TR ⁇ TF), for example 77? is about half of TF. This property is detailed for example in the article entitled “The OpenEapSmartcard Platform", written by Pascal Urien and Mesmin Dandjinou, which is available under the reference “Network Control and Engineering for QoS, Security and Mobility," IV: Fourth IFIP International Conference on Network Control and Engineering for QoS, Security, and Mobility, Lannion, France, November 14-18, 2005, by Anthony Ga ⁇ ti, Edition: illusîraîed, Springer, 2007, ISBN 0387496890, 9780387496894.
  • WEB servers largely use the RESUMPTION mode to limit the load of asymmetric calculations (RSA, etc.).
  • a browser downloads, via an HTTPS request, a first file (an HTML page) in FULL mode, then it keeps the same MasterSecret (and thus allows the RESUMPTION mode) for a predefined period of time, for example 10 minutes.
  • HTTP 1.1 (RFC 2616) standard recommends the use of two or more TCP connections between a browser and a WEB server.
  • commercial browsers such as Internet Explorer, use up to four simultaneous TCP connections.
  • the use of a single security module allows the download of up to I / TF files per second in FULL mode and at most I / TR files per second in RESUMPTION mode.
  • N security modules does not allow to exceed the limit of N / TF files per second. Indeed, as the security modules do not share data, they are obliged to initiate, independently, secure sessions. However, such an initialization must be performed in FULL mode, and not in RESUMPTION mode. Therefore, the maximum number of files transmitted per second can not exceed the N / TF limit.
  • One of the advantageous features of the invention is to set up the secure exchange of the "MasterSecret" between security modules. In this case the implementation of TV security modules allows the download of up to N / TR files per second.
  • the modules Slaves may be allowed to initiate a session in RESUMPTION mode.
  • FIG. 4 shows a security module in the form of a silicon integrated circuit (400), 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, card
  • SIM Single SIM
  • 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.
  • CPU central unit
  • ROM read-only memory
  • RAM random access memory
  • a system bus (410) connects the different members of the secure module.
  • the interface with the outside world (420) is provided by an input / output port IO (405), compliant with standards such as ISO 7816, USB, USB-
  • JAVA smart cards commonly referred to as JAVACARD, are a special class of security module.
  • a device embodying the method of the invention is in the form of a portable device, such as a token or a USB key.
  • This device comprises, on the one hand, storage means, in particular a "Security Module Manager” software according to the invention and at least two SIM card readers.
  • the storage of the security module manager according to the invention can be realized on a specific electronic component of the FPGA type ("field-programmable trick array" for "programmable gate network”)
  • the smart card readers can respectively accommodate master security modules and slave security modules to compose a grid of security modules.
  • the device When connected, for example to a personal computer, the device acts as a provider of security resources.
  • the Security Module Manager provides an interface between the personal computer and the security modules. It is particularly capable of transmitting the secret key creation commands to the master module and the secret key transmission commands previously calculated to the slave module.
  • the invention makes it possible to provide, in a very simple manner, a strong security solution without the need to make numerous modifications in the existing communication architectures: at worst, it is necessary to install a device-specific driver on the computer on which this device is to be connected: this will be valid, for example, for computers with a rather old operating system.
  • the device of the invention is recognized as being a standard smart card reader, requiring no additional installation.
  • the component "Manager Security Modules” is responsible for the interface between the security module grid and the terminal in which the device is plugged.

Abstract

L'invention concerne un procédé de production de données de sécurisation, permettant la mise en oeuvre 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 première étape de transmission desdites données de sécurisation générées de ladite troisième entité sécurisée vers ladite première entité; une deuxième étape de transmission d'au moins une partie desdites données de sécurisation générées au sein de ladite troisième entité sécurisée à destination d' au moins une quatrième entité sécurisée préalablement initialisée et liée à ladite troisième entité sécurisée.

Description

Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant.
1 DOMAINE DE L'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.
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'anglais
« 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 surs peut permettre des attaques qui diminuent la confiance que l'on doit légitimement apporter aux procédures d'échange mettant en œuvre ces protocoles.
2 SOLUTIONS DE L'ART ANTERIEUR
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. 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. Or, les entités en question sont bien souvent vulnérables et non sécurisées de sorte que même si elles produisent des données de sécurisation (par exemple des certificats, des clés de cryptographie ou des secrets partagés) conformément aux protocoles de sécurisation (SSL ou TLS par exemple), rien n'assure que ces entités n'ont pas préalablement fait l'objet d'une attaque et que ces données de sécurisation ne sont pas récupérées directement lors de leurs calculs.
La demande de brevet publiée WO 2008/145558 décrit une méthode de sécurisation des échanges dans laquelle une production de données de sécurisation est réalisée pour la mise en œuvre d'une session sécurisée entre une première et une deuxième entité, selon un protocole d'établissement de sessions sécurisées tel que SSL ou TLS. Cette méthode permet de résoudre en partie les inconvénients posés par la mise en œuvre des protocoles SSL et TLS par des entités non sécurisées. Cette méthode comprend une initialisation d'une entité sécurisée tierce, liée à la première entité, une génération d'une partie des données de sécurisation au sein de la troisième entité et une transmission des données de sécurisation de la troisième entité sécurisée vers ladite première entité. Typiquement, la troisième entité est par exemple une carte à puce de type JavaCard qui réalise une partie des calculs nécessaires à l'établissement de la session sécurisée.
Ainsi, la méthode de WO 2008/145558 permet d'initier un échange de données entre deux entités tout en ayant l ' assurance que le matériel crypto graphique nécessaire à l'établissement de la session aura été conçu de manière sécurisée.
Cependant, dans le cas où plusieurs échanges de fichiers différents sont obligatoires, il est nécessaire de recourir à la méthode de WO 2008/145558 autant de fois qu'il y a de fichiers à échanger.
Or les capacités de traitement et d'entrée/sortie des entités sécurisées, telles que les cartes à puces ou les java cards, sont souvent faibles : il n'est pas réaliste, en termes de performances, d'utiliser une telle entité de sécurisation pour réaliser des traitements cryptographiques intensifs. Ainsi, la méthode décrite dans
WO 2008/145558 ne peut pas être employée seule lorsque des performances importantes sont requises et que de nombreuses sessions sécurisées doivent se dérouler en parallèle.
3 RESUME DE L'INVENTION
L'invention ne présente pas ces inconvénients de l'art antérieur. En effet, l'invention concerne 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 première étape de transmission desdites données de sécurisation générées de ladite troisième entité sécurisée vers ladite première entité ; une deuxième étape de transmission d'au moins une partie desdites données de sécurisation générées au sein de ladite troisième entité sécurisée à destination d'au moins une quatrième entité sécurisée préalablement initialisée et liée à ladite troisième entité sécurisée.
Ainsi, l'invention permet à différentes entités sécurisées, telles que par exemple des puces, des cartes à puce, des « dongles » de disposer de données de sécurisation, telles que des données de chiffrement tout en n'ayant pas le besoin de générer elles mêmes ces données. Ces données sont générées par l'intermédiaire d'une autre entité sécurisée et transmises après leur création pour être réutilisées par la suite.
Selon un mode de réalisation particulier de l'invention, ladite troisième entité, dite entité maître, génère au moins une partie d'un secret partagé entre ladite première et ladite deuxième entité.
Ainsi, le secret est partagé également avec toutes les entités sécurisées. Elles peuvent donc le réutiliser par la suite pour, par exemple, entamer une nouvelle session sécurisée si le besoin s'en fait sentir. Plus particulièrement, ladite au moins une partie desdites données de sécurisation générées transmise à ladite au moins une quatrième entité, dite entité esclave, comprend ledit secret partagé sous une forme chiffrée et au moins un identifiant de session de communication sécurisée.
Ainsi, le fait de transmettre les données de sécurisation sous une forme chiffrée au module esclave permet de se prémunir d'éventuels vols ou tentatives de vol de ces données de sécurisation.
Selon un mode de réalisation particulier de l'invention, ledit protocole d'établissement de sessions sécurisées est le protocole SSL.
Selon un mode de réalisation particulier de l'invention, ledit protocole d'établissement de sessions sécurisées est le protocole TLS.
Selon une caractéristique particulière 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 unité fonctionnelle « 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 unité fonctionnelle « 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é. Ainsi, l'invention est à même de générer des secrets partagés par plusieurs entités sécurisées, comme par exemple plusieurs cartes à puce, car l'ensemble de clés est calculé par la troisième entité.
Plus particulièrement, ladite deuxième étape de transmission est mise en œuvre par un gestionnaire de modules de sécurités qui obtient lesdites données de sécurisation à partir de ladite troisième entité.
Selon une caractéristique particulière de l'invention, ladite deuxième étape de transmission est mise en œuvre lors d'une phase de reprise de ladite session sécurisée. Ainsi, l'invention permet de gérer, de manière centralisée, le partage des clés entre les entités sécurisées et augmente ainsi le niveau de sécurité de l'ensemble du système.
Selon un autre aspect, l'invention concerne également un procédé d'établissement d'une session de communication 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'obtention d'un identifiant de session et d'un secret éphémère calculé lors d'une précédente session de communication sécurisée par une troisième entité sécurisée liée à ladite première entité ; - une étape de transmission dudit identifiant de session et dudit secret éphémère à une quatrième entité sécurisée, préalablement initialisée et liée à ladite troisième entité sécurisée ; une étape d'établissement de ladite session de communication sécurisée en utilisant ladite quatrième entité sécurisée. Ainsi, l'invention permet d'utiliser d'autres entités sécurisées, telles que des cartes à puce ou des javacard pour l' établissement de sessions de communication sécurisées qui on été précédemment initialisées par une autre entité sécurisée. En conséquence, l'invention permet le traitement en parallèle de plusieurs transactions, comme par exemple des téléchargements de fichiers, en utilisant les services de plusieurs entités sécurisées, tout en minimisant le temps nécessaire à l'établissement de session, tout en offrant un excellent niveau de sécurisation.
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 d'une troisième entité sécurisée, 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é ; des moyens de transmission d'au moins une partie desdites données de sécurisation générées au sein de ladite troisième entité sécurisée à destination d'au moins une quatrième entité sécurisée préalablement initialisée et liée à ladite troisième entité sécurisée.
Selon un mode de réalisation particulier de l'invention, lesdits moyens de génération et lesdits moyens de transmission sont regroupés dans une carte à puce.
Selon un mode de réalisation particulier, l'invention concerne également un dispositif portable, tel qu'un jeton USB, comprenant un moyen de stockage d'un gestionnaire de modules de sécurité et au moins deux lecteurs de cartes au format SIM et un dispositif de production de donnée de sécurisation tel que décrit précédemment.
Selon un autre aspect, 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, et comprenant des instructions de code de programme pour l'exécution du procédé de production tel que décrit précédemment.
Selon un autre aspect, 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, et comprenant des instructions de code de programme pour l'exécution du procédé d'établissement de session tel que décrit précédemment. 4 LISTE DES 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 sécurisation à l'aide d'une grille de modules de sécurité selon l'invention ;
La figure 3 présente l'architecture logique d'une grille de modules de sécurité selon l'invention ; - la figure 4 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
5.1 Rappel du principe de l'invention
Le principe général de l'invention repose sur une mise en œuvre conjointe d'un ensemble comprenant plusieurs modules de sécurité, et appelé grille de modules de sécurité. Cette grille de modules de sécurité comprend ainsi plusieurs entités sécurisées qui interviennent dans l'établissement de la session de communication sécurisée. Ainsi, à la différence de la méthode décrite dans le document WO 2008/145558, l'invention permet de résoudre les problèmes de performance inhérents à l'utilisation d'entités sécurisées externes.
De cette façon, l'invention élève le niveau de sécurité lors de l'établissement de la session sécurisée tout en assurant un maintien des performances générales du système d'authentifîcation constitué des entités souhaitant établir une session sécurisée (par exemple un client et un serveur) et de la grille de modules de sécurité (comprenant les troisième et quatrième entités) qui est par exemple liée au client.
De manière générale, la grille de modules de sécurité peut être matérialisée sous la forme d'une ou plusieurs cartes à puce à insérer dans un lecteur de carte spécifique, d'un module de type « dongle », à insérer par exemple dans un emplacement de type « USB » (de l'anglais « Universal Sériai Bus ») d'un ordinateur ou toute autre forme permettant une communication entre l'entité qui souhaite établir la session sécurisée et la grille de module de sécurité.
La grille de modules de sécurité peut être dédiée à la mise en œuvre d'un protocole particulier tel que SSL et/ou TLS. Ce n'est cependant pas le seul mode de réalisation possible de l'invention. Il est en effet tout à fait envisageable que la grille de modules de sécurité puisse mettre en œuvre plusieurs protocoles afin de garantir une plus grande interopérabilité.
Il est rappelé qu'un module de sécurité désigne, dans le cadre de l'invention, une puce électronique qualifiée usuellement de "Tamper Résistant Device", littéralement un "composant qui résiste aux attaques", qui est à même de gérer des contre mesures physiques et logiques.
Ce module de sécurité comprend notamment une pile logicielle SSL/TLS comportant les unités fonctionnelles HANDSHAKE, ALERT, CCS et RECORD qui sont bien connues de l'homme du métier. Ce module de sécurité communique avec une entité utilisatrice (client ou serveur) à l'aide d'une interface fonctionnelle permettant d'échanger des messages protocolaires SSL/TLS et d'obtenir au moins quatre types de paramètres : « keys_bloc », « cipher_suite », « SessionID » et la valeur chiffrée du « master _secret ». La valeur chiffrée du « master-secret » {Master _secr et*) est obtenue à l'aide d'une clé secrète partagée entre les différents modules de sécurité et une valeur publique sait, selon la relation,
Master _secret* = F(Key_Module,salt, MasterSecret)
L'entité utilisatrice du module de sécurité gère une couche de communication et intègre les unités fonctionnelles ALERT et RECORD et de manière optionnelle les unités fonctionnelles HANDSHAKE et CCS. Les informations issues de la couche APPLICATION sont sécurisées par la couche RECORD.
L'invention propose de mettre en œuvre conjointement l'entité utilisatrice et la grille de modules de sécurités pour établir une session sécurisée avec un serveur. Astucieusement, une partie des étapes nécessaires à l'établissement de la session est réalisée par l'intermédiaire de la grille de module de sécurité tandis que l'autre partie est réalisée par l'entité utilisatrice. Il se peut, dans un mode de réalisation particulier de l'invention, que les étapes mises en œuvre par l'entité utilisatrice et par la grille de module de sécurité diffèrent à chaque création d'une nouvelle session sécurisée. De cette manière, il est plus difficile de prévoir le fonctionnement général du système et de tenter de forcer le mécanisme de sécurisation offert par l'invention.
Dans un mode de réalisation particulier de l'invention, au sein de la grille de modules de sécurité, on distingue deux types de modules de sécurité différents : les modules maîtres et les modules esclaves. Un module de sécurité esclave dépend d'un module de sécurité maître sans lequel il ne peut pas fonctionner. Plus particulièrement, selon l'invention, un module maître est le seul capable de calculer un secret particulier éphémère (le « mastersecret », ce dernier terme étant utilisé par la suite). On rappelle que le « mastersecret », dans le cadre par exemple de la mise en œuvre du protocole TLS, est calculé lors de la phase dite « Ml mode ». Lors de cette phase, les échanges entre le client et le serveur permettent de calculer un secret commun, partagé entre le client et le serveur et qui sert de base à la création de toutes les autres données de chiffrement nécessaire à la session sécurisée.
Dans une grille de modules de sécurité selon l'invention seul un module maître peut participer, avec l'entité utilisatrice, au calcul de ce « mastersecret ».
Par la suite, afin de permettre un mécanisme de reprise de session plus rapide, par exemple dans le cadre d'une phase dite de « Resumed mode», un module esclave peut utiliser le « mastersecret » calculé par son module maître pour poursuivre une session sécurisée ou pour réaliser d'autres opérations lors de la session sécurisée.
Selon l'invention, un module esclave entre en possession du « mastersecret » par l'intermédiaire du module maître auquel il est associé. Pour ce faire, le module maître distribue, selon l'invention, ce « mastersecret » aux modules esclaves, mais de manière sécurisée.
Cela signifie que, selon l'invention, la distribution du « mastersecret » est réalisée selon un protocole particulier régissant les échanges de données entre le module maître et le module esclave auquel il est associé. Un tel protocole peut prendre la forme de commandes qui sont transmises à ces modules pour permettre l'échange.
Toujours selon l'invention, d'un point de vue logique l'identité de l'entité utilisatrice est liée uniquement au module maître. Cela signifie que dans le processus d'établissement de la session sécurisée, l'entité utilisatrice n'a pas connaissance de la présence des modules esclaves.
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) d'un module de sécurité 1001 (par exemple une carte à puce), attachée à une première entité 1002 (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é. - une étape de transmission (103) d'au moins une partie desdites données de sécurisation générées au sein du module de sécurité 1001 à destination d'un deuxième module de sécurité 1003 préalablement initialisée et lié au premier module de sécurité 1001, formant ainsi une grille de modules de sécurité 1004 dans laquelle au moins certaines données de sécurisation sont partagées.
En d'autres termes, l'invention propose une grille de modules de sécurité, servant à établir des sessions sécurisées de transmission de données et qui partagent des données pour établir ces sessions sécurisées de transmission.
Par la suite, on présente un mode de réalisation de l'invention dans lequel un gestionnaire de modules de sécurité, intégrée à la grille de modules de sécurité, gère le fonctionnement général de celle-ci. Il est clair cependant que l'invention ne se limite pas à cette mise en oeuvre particulière.
5.2 Description d'un mode de réalisation
On présente dans ce mode de réalisation, la mise en œuvre d'une grille de modules de sécurité selon l'invention.
On décrit les fonctionnalités originales d'une grille de modules de sécurité qui selon l'invention réalise la phase d'authentifïcation du protocole TLS, puis permet à une application d'utiliser le tunnel sécurisé préalablement établi.
Comme cela a déjà été évoqué, un module de sécurité réalise les fonctions de client ou de serveur TLS, son logiciel embarqué comporte donc les unités fonctionnelles HANDSHAKE, ALERT, CCS et RECORD.
La figure 2 présente le module de sécurité TLS et son utilisateur, c'est-à- dire une application munie d'un sous ensemble de la pile TLS, soit de manière obligatoire les couches RECORD et ALERT et de manière optionnelle les couches CCS et HANDSHAKE. Cette entité utilisatrice peut être un client (par exemple une application cliente de type navigateur web) ou un serveur (par exemple un serveur web gérant les sessions sécurisées).
Un module de sécurité offre une interface fonctionnelle qui comprend neuf commandes, SET-Credentials, Start, Process-TLS, GET-Keys bloc, Compute- Keys bloc, GET-Cipher suite, GET-SessionID , G E T-Master_secret, SET- 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 Application »). Le module de sécurité (210) qui met en œuvre le procédé de production selon l'invention comprend les unités fonctionnelles 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).
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 commandes
5.3.1 Commande SET-Credentials 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ée RSA) est activé par la commande SET-Credentials() :
SET-Credential s ( Credential s , rôle ) 5.3.2 StartCUnix-Time)
Dans ce mode de réalisation, une commande « Start » initialise une 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 :
Start ( Unix-Time )
Une telle commande permet, en quelque sorte, de préparer le module de sécurité à effectuer les calculs nécessaires dans le cadre de l'invention.
5.3.3 Process-TLS Les paquets TLS, c'est-à-dire les messages produits par une l'unité fonctionnelle 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) 5.3.4 GET-Kevs bloc
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() 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ée pour le calcul d'intégrité HMAC du 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) 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 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'unité fonctionnelle RECORD. cipher_suite = Get-Cipher_suite ( )
5.3.7 GET-SessionID
La commande GET-SessionID retourne le paramètre « SessionID » associé à la session précédente associée à un mastersecret particulier. C'est une information utile pour la grille de modules sécurité qui permet à des modules esclaves de réaliser une phase de « Session Resumption ».
SessionID = GET-SessionID ()
5.3.8 GET-Master secret
La commande GET-Master_secret() collecte une valeur chiffrée du master_secret (master _secret*) ainsi qu'un ensemble de paramètres (sait) permettant de réaliser le déchiffrement de cette information. master_secret* | sait = GET-Master_secret ( ) Le master secret est chiffré à l'aide d'une clé secrète symétrique ou asymétrique (Key_Module), partagée par un ensemble de modules de sécurité, et associée à un algorithme de chiffrement (tel que AES, Triple DES, RSA) et d'un nombre aléatoire sait généré par le module de sécurité.
Master_secret* = F (Key_Module, sait, MasterSecret)
5.3.9 Set-Master Secret La commande Set-Master_Secret(Master_Secret* | Sait, SessionID) réalise la mise jour d'un master secret, associé à un index SessionID dans un module de sécurité de type esclave par exemple.
L'invention concerne ainsi également toute carte à puce ou entité sécurisée de ce type qui comprend les commandes précédentes permettant la lecture, le transfert et l'initialisation d'une session sécurisée à partir d'un secret éphémère (le « mastersecret ») calculé par une autre entité sécurisée.
En d'autres termes, l'invention concerne également une méthode d'établissement d'une session de communication à l'aide d'une entité sécurisée qui récupère le secret éphémère et l'identifiant d'une session qui a été précédemment initialisée par une autre entité sécurisée. Ces deux entités sécurisées sont de préférence liées entre elles de sorte qu'elles sont soit présente au sein d'une même carte à puce, soit qu'elles communique par l'intermédiaire d'un module spécifique qui va gérer des interactions (par exemple l'exécution de certaines des commandes précédemment décrites) entre les entités sécurisées. Ainsi, les objectifs de sécurisation des données sont atteints, selon l'invention, à l'aide d'un module de gestion, également appelé gestionnaire de modules de sécurité, du type hébergeant et exécutant un logiciel assurant notamment des fonctions de gestion et de mémorisation de données de sécurisation, ledit logiciel comprenant des moyens d'exécution de commandes de récupération, de mémorisation et de transmission, par exemple envoyées au logiciel par au moins un logiciel client et appartenant à un jeu de commandes de récupération, de mémorisation et de transmission prédéterminé (GET-Session_ID, GET-Master_Secret, Set-Master_Secret, etc.). 5.4 Mise en œuyre du protocole A l'aide des neuf commandes décrites précédemment il est possible de mettre en œuvre une grille de modules de sécurité.
La figure 3 présente l'architecture logique d'une grille de modules de sécurité selon l'invention. Une unité fonctionnelle dite Gestionnaire de Modules de Sécurité contrôle une pluralité de modules de sécurité. Selon l'invention, il existe deux classes de modules de sécurité les modules dit maître et les modules dit esclaves.
Les modules maîtres sont identifiés par des index variant de 1 à p. Les modules esclaves sont identifiés par des index strictement supérieurs à p. Un module maître stocke un certificat X509 mais également la clé privée
RSA nécessaire à l'authentifïcation du client. Les modules maîtres partagent une clé KeyModule, utilisée pour les opérations de chiffrement et de déchiffrement du mastersecret.
Un module esclave partage avec les modules maîtres une clé crypto graphique commune KeyModule, mais ne stocke pas la clé privée du client. Le Gestionnaire de Modules de Sécurité est associé à au moins un module maître, les configurations à n modules comportent en conséquence p modules maître (p étant supérieur ou égal à 1) et k=n-p modules esclaves (k pouvant être égal à zéro). Par exemple, une configuration de grille comprenant n=16 modules, dont p= 4 modules maîtres, comprendra k=12 modules esclaves.
Lors de l'ouverture d'une session TCP, le Gestionnaire de Module de Sécurité sélectionne de manière prioritaire un module de sécurité maître. Si cette opération est impossible, c'est-à-dire que tous les modules maîtres sont affectés à des sessions en cours d'ouverture, un module esclave est choisi. Si aucun module n'est libre le Gestionnaire de Module de Sécurité se met alors en attente de la disponibilité d'un module.
Selon l'invention, au début de chaque session le Gestionnaire de Modules de Sécurité met à jour les paramètres (SessionID, MasterSecrei) utilisées par une précédente session à l'aide, selon l'invention, de la commande Set-Master Secret. Grâce à cette procédure il permet à un module (maître ou esclave) de gérer une session en mode Resumption.
Si un module esclave échoue dans une tentative d'ouverture d'une session en mode Resumption à l'aide des données transmises par le gestionnaire de modules de sécurité, c'est-à-dire si le serveur impose une session en mode FuIl (par exemple parce que la durée de vie de la session « résume » a expiré), il termine la session courante.
A la fin de chaque ouverture de session (quand la procédure de
HANDSHAKE est terminée), le Gestionnaire de Modules de Sécurité collecte les paramètres SessionID et Master Secret) grâce aux commandes Get-SessionID et Get-MasterSecret introduites par l'invention. Ainsi, le Gestionnaire de Modules de Sécurité est à même de fournir, lors d'une prochaine session, les données collectées, aussi bien aux modules maîtres qu'aux modules esclaves.
On présente, en relation avec la figure 3, une vue schématique d'une grille de modules de sécurité selon l'invention. Cette grille de modules de sécurité 300, comprend un composant hébergeant un gestionnaire de module de sécurité (GMS)
301, chargé de mémoriser d'une part et de distribuer d'autre part les données générées par les modules maîtres.
La grille de module de sécurité 300 comprend également des modules maîtres 302 à 305 qui génèrent au moins une partie des données de sécurisation en lien avec l'entité à laquelle la grille de modules de sécurité est connectée. Dans les modes de réalisation de l'invention présentés précédemment, les modules maîtres calculent la valeur du MasterSecret pour une session en mode « FuIl ». La grille comprend également des modules de sécurité esclaves 307 à 318.
Les modules maîtres peuvent être associés à un nombre prédéterminé de modules esclaves (par exemple trois dans l'exemple de la figure 3) formant ainsi un groupe de modules de sécurité 306. Cette préassociation n'est pas obligatoire. Le gestionnaire de modules de sécurité 301 peut dynamiquement, en fonction des besoins, associer les modules de sécurité esclave en fonction du nombre de sessions de sécurisation requises à l'aide d'une unité fonctionnelle comprenant des moyens d'obtention d'un nombre de connexion ou d'un nombre d'éléments à télécharger, s'il s'agit par exemple d'une session de communication « http » requérant le téléchargement d'images ou d'autres éléments en provenance d'un serveur Web.
Une telle mise en place des sessions sécurisées grâce au procédé et à l'architecture de grille de modules de sécurité de l'invention présente de nombreux avantages.
Si l'on note respectivement TF et 77? les temps nécessaires pour réaliser une session FULL et RESUMPTION dans un module de sécurité. Pour des raisons théoriques évoquées dans plusieurs publications scientifiques 77? est inférieur à TF (TR<TF), par exemple 77? est de l'ordre de la moitié de TF. Cette propriété est détaillée par exemple dans l'article intitulé «The OpenEapSmartcard Platform», écrit par Pascal Urien et Mesmin Dandjinou, qui est disponible sous la référence «Network Control and Engineering for QoS, Security and Mobility, IV: Fourth IFIP International Conférence on Network Control and Engineering for QoS, Security, and Mobility, Lannion, France, November 14-18, 2005, par Dominique Gaïti, Edition: illusîraîed, Springer, 2007, ISBN 0387496890, 9780387496894».
Dans l'état de l'art actuel les serveurs WEB utilisent largement le mode RESUMPTION afin de limiter la charge des calculs asymétriques (RSA, etc). Typiquement un navigateur télécharge, via une requête HTTPS, un premier fichier (une page HTML) en mode FULL, puis il conserve le même MasterSecret (et donc autorise le mode RESUMPTION) durant une période de temps prédéfinie, par exemple 10 minutes.
La norme HTTP 1.1 (RFC 2616) recommande l'usage de deux connexions TCP au plus entre un navigateur et un serveur WEB. Cependant des navigateurs commerciaux, tels que Internet Explorer utilisent jusqu'à quatre connexions TCP simultanées.
L'utilisation d'un seul module de sécurité permet le téléchargement d'au plus I /TF fichiers par seconde en mode FULL et d'au plus I /TR fichier par seconde en mode RESUMPTION.
En l'absence de procédure assurant le transfert du « MasterSecret » entre modules de sécurité, tel que le propose l'invention, la mise en œuvre de N modules de sécurité ne permet pas de dépasser la limite de N/TF fichiers par seconde. En effet, comme les modules de sécurité ne partagent pas de données, ils sont obligés d'initialiser, de manière indépendante, les sessions sécurisées. Or, une telle initialisation doit être réalisée en mode FULL, et non pas en mode RESUMPTION. Donc, le nombre maximum de fichiers transmis par seconde ne peut pas dépasser la limite N/TF. Une des caractéristiques avantageuse de l'invention est de mettre en place l'échange sécurisé du « MasterSecret » entre modules de sécurité. Dans ce cas la mise en œuvre de TV modules de sécurité permet le téléchargement d'au plus N/TR fichiers par seconde. En effet, comme les modules de la grille de modules de sécurité selon l'invention partagent le « MasterSecret » (dont il convient de rappeler qu'il sert à la composition de tout autre matériel cryptographique ou de chiffrement ultérieur au HANDSHAKE), les modules esclaves peuvent être autorisés à initier une session en mode RESUMPTION.
Ainsi, si le nombre de connexions TCP utilisées par le navigateur est limité à NS, le nombre optimal de module de sécurité N est égal à cette valeur (N = NS). On en déduit la limite de téléchargement de fichiers, en utilisant l'architecture de grille de sécurité selon l'invention : NS/TF.
5.5 Description d'une grille de modules de sécurité selon l'invention
On présente, en relation avec la figure 4 un module de sécurité sous la forme d'un circuit intégré de silicium (400), 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).
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, 401), une mémoire ROM stockant le code du système d'exploitation (402), de la mémoire RAM
(403), et une mémoire non volatile (NVR, 404), utilisée comme dispositif de stockage analogue à un disque dur, et qui contient par exemple un logiciel embarqué TLS. Un bus système (410) relie les différents organes du module sécurisé. L'interface avec le monde extérieur (420) est assurée par un port IO d'entrée/sortie (405), conforme à des standards tels que ISO 7816, USB, USB-
OTG, ISO 7816-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é.
Dans au moins un mode de réalisation, un dispositif mettant en œuvre le procédé de l'invention se présente sous la forme dispositif portable, tel qu'un jeton ou une clé USB. Ce dispositif comprend, d'une part un moyen de stockage notamment d'un logiciel de type « Gestionnaire de Modules de Sécurité » selon l'invention et au moins deux lecteurs de cartes au format SIM. Le stockage du gestionnaire de modules de sécurité selon l'invention peut être réalisé sur un composant électronique spécifique du type FPGA («field-programmable gâte array » pour « réseau de portes programmables »)
Les lecteurs de carte à puce peuvent accueillir respectivement des modules de sécurité maîtres et des modules de sécurité esclaves pour composer une grille de modules de sécurité. Lorsqu'il est branché, par exemple à un ordinateur personnel le dispositif joue le rôle de fournisseur de ressources de sécurisation. Le Gestionnaire de Modules de Sécurité réalise une interface entre l'ordinateur personnel et les modules de sécurité. Il est notamment capable de transmettre les commandes de création de clé secrète au module maître et les commandes de transmission de clé secrète préalablement calculée au module esclave.
Ainsi, dans ce mode de réalisation, l'invention permet de fournir, de manière très simple, une solution de sécurisation forte sans qu'il soit nécessaire de réaliser de nombreuses modifications dans les architectures de communication existantes : au pire, il est nécessaire d'installer un driver spécifique au dispositif sur l'ordinateur sur lequel ce dispositif doit être branché : ceci sera valable par exemple pour les ordinateurs disposant de système d'exploitation plutôt ancien. Au mieux, le dispositif de l'invention est reconnu comme étant un lecteur de carte à puce standard, ne nécessitant aucune installation supplémentaire.
Dans ce mode de réalisation et dans tous les cas, le composant « Gestionnaire de Modules de Sécurité » est chargé de faire l'interface entre la grille de module de sécurité et le terminal dans lequel le dispositif est enfiché.

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 qu'il 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 première étape de transmission desdites données de sécurisation générées de ladite troisième entité sécurisée vers ladite première entité ; une deuxième étape de transmission d'au moins une partie desdites données de sécurisation générées au sein de ladite troisième entité sécurisée à destination d'au moins une quatrième entité sécurisée préalablement initialisée et liée à ladite troisième entité sécurisée.
2. Procédé de production selon la revendication 1 , caractérisé en ce que ladite troisième entité, dite entité maître, génère au moins une partie d'un secret partagé entre ladite première et ladite deuxième entité.
3. Procédé de production selon la revendication 2, caractérisé en ce que ladite au moins une partie desdites données de sécurisation générées transmise à ladite au moins une quatrième entité, dite entité esclave, comprend ledit secret partagé sous une forme chiffrée et au moins un identifiant de session de communication sécurisée.
4. Procédé de production selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit protocole d'établissement de sessions sécurisées est le protocole SSL.
5. Procédé de production selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit protocole d'établissement de sessions sécurisées est le protocole TLS.
6. Procédé de production selon la revendication 5, caractérisé en ce qu'il comprend en outre : une étape de transmission, par ladite première entité, d'au moins un message à destination d'une unité fonctionnelle « 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 unité fonctionnelle « 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é.
7. Procédé de production selon la revendication 1, caractérisé en ce que ladite deuxième étape de transmission est mise en œuvre par un gestionnaire de modules de sécurités qui obtient lesdites données de sécurisation à partir de ladite troisième entité.
8. Procédé de production selon la revendication 1 , caractérisé en ce que ladite deuxième étape de transmission est mise en œuvre lors d'une phase de reprise de ladite session sécurisée.
9. Procédé d'établissement d'une session de communication 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 : - une étape d'obtention d'un identifiant de session et d'un secret éphémère calculé lors d'une précédente session de communication sécurisée par une troisième entité sécurisée liée à ladite première entité ; une étape de transmission dudit identifiant de session et dudit secret éphémère à une quatrième entité sécurisée, préalablement initialisée et liée à ladite troisième entité sécurisée ; une étape d'établissement de ladite session de communication sécurisée en utilisant ladite quatrième entité sécurisée.
10. 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 : 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é ; des moyens de transmission d'au moins une partie desdites données de sécurisation générées au sein de ladite troisième entité sécurisée à destination d'au moins une quatrième entité sécurisée préalablement initialisée et liée à ladite troisième entité sécurisée.
11. Dispositif de production de données de sécurisation selon la revendication 10, caractérisé en ce que lesdits moyens de génération et lesdits moyens de transmission sont regroupés dans une carte à puce.
12. Dispositif portable, tel qu'un jeton USB, caractérisé en ce qu'il comprend un moyen de stockage d'un gestionnaire de modules de sécurité et au moins deux lecteurs de cartes au format SIM et un dispositif de production de donnée de sécurisation selon la revendication 10.
13. 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 à 8, lorsqu'il est exécuté sur un ordinateur.
14. Procédé de production selon la revendication 1, caractérisé en ce que lesdites données transmises à ladite au moins une entité sécurisée sont mises en œuvre lors d'une reprise d'une session de communication sécurisée.
PCT/EP2010/053334 2009-03-16 2010-03-16 Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant WO2010106042A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CA2754895A CA2754895A1 (fr) 2009-03-16 2010-03-16 Procede de production de donnees de securisation, dispositif et programme d'ordinateur correspondant
CN2010800123317A CN102356621A (zh) 2009-03-16 2010-03-16 一种产生安全数据的方法以及其对应装置和计算机程序
RU2011139616/08A RU2011139616A (ru) 2009-03-16 2010-03-16 Способ и устройство получения защищенных данных
US13/257,221 US20120072994A1 (en) 2009-03-16 2010-03-16 Method to produce securing data, corresponding device and computer program
EP10711036A EP2409474A1 (fr) 2009-03-16 2010-03-16 Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0951646 2009-03-16
FR0951646A FR2943198B1 (fr) 2009-03-16 2009-03-16 Procede de production de donnees de securisation, dispositif et programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
WO2010106042A1 true WO2010106042A1 (fr) 2010-09-23

Family

ID=41402590

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/053334 WO2010106042A1 (fr) 2009-03-16 2010-03-16 Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant

Country Status (7)

Country Link
US (1) US20120072994A1 (fr)
EP (1) EP2409474A1 (fr)
CN (1) CN102356621A (fr)
CA (1) CA2754895A1 (fr)
FR (1) FR2943198B1 (fr)
RU (1) RU2011139616A (fr)
WO (1) WO2010106042A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106330692B (zh) * 2016-08-30 2019-10-08 泉州台商投资区钰宝商贸有限公司 轻量级高性能虚拟专用网软件的设计和实现
US10599849B2 (en) * 2018-05-03 2020-03-24 Dell Products L.P. Security module authentication system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999039475A1 (fr) * 1998-02-03 1999-08-05 Tandem Computers, Inc. Systeme de chiffrement
WO2001060040A2 (fr) * 2000-02-10 2001-08-16 Bull Cp8 Procede de transmission de donnees sur un reseau internet entre un serveur et un terminal a carte a puce, qui contient des agents intelligents
EP1349032A1 (fr) * 2002-03-18 2003-10-01 Ubs Ag Authentification securisée d'un utilisateur dans un réseau d'ordinateurs
WO2006021865A1 (fr) * 2004-08-24 2006-03-02 Axalto Sa Jeton personnel et procede d'authentification commandee
WO2008145558A2 (fr) 2007-05-25 2008-12-04 Groupe Des Ecoles Des Telecommunications / Ecole Nationale Superieure Des Telecommunications Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7360075B2 (en) * 2001-02-12 2008-04-15 Aventail Corporation, A Wholly Owned Subsidiary Of Sonicwall, Inc. Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols
US7529933B2 (en) * 2002-05-30 2009-05-05 Microsoft Corporation TLS tunneling
US7587598B2 (en) * 2002-11-19 2009-09-08 Toshiba America Research, Inc. Interlayer fast authentication or re-authentication for network communication
US8190895B2 (en) * 2005-08-18 2012-05-29 Microsoft Corporation Authenticated key exchange with derived ephemeral keys
US8578159B2 (en) * 2006-09-07 2013-11-05 Motorola Solutions, Inc. Method and apparatus for establishing security association between nodes of an AD HOC wireless network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999039475A1 (fr) * 1998-02-03 1999-08-05 Tandem Computers, Inc. Systeme de chiffrement
WO2001060040A2 (fr) * 2000-02-10 2001-08-16 Bull Cp8 Procede de transmission de donnees sur un reseau internet entre un serveur et un terminal a carte a puce, qui contient des agents intelligents
EP1349032A1 (fr) * 2002-03-18 2003-10-01 Ubs Ag Authentification securisée d'un utilisateur dans un réseau d'ordinateurs
WO2006021865A1 (fr) * 2004-08-24 2006-03-02 Axalto Sa Jeton personnel et procede d'authentification commandee
WO2008145558A2 (fr) 2007-05-25 2008-12-04 Groupe Des Ecoles Des Telecommunications / Ecole Nationale Superieure Des Telecommunications Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DOMINIQUE GAI'TI: "Network Control and Engineering for QoS, Security and Mobility, 1V· Fourth IFIP International Conference on Network Contrai and Engineering for QoS, Security, and Mobility", 14 November 2005, SPRINGER

Also Published As

Publication number Publication date
CA2754895A1 (fr) 2010-09-23
CN102356621A (zh) 2012-02-15
FR2943198A1 (fr) 2010-09-17
RU2011139616A (ru) 2013-04-27
EP2409474A1 (fr) 2012-01-25
US20120072994A1 (en) 2012-03-22
FR2943198B1 (fr) 2011-05-20

Similar Documents

Publication Publication Date Title
WO2008145558A2 (fr) Procede de securisation d&#39;echange d&#39;information, dispositif, et produit programme d&#39;ordinateur correspondant
EP2614458B1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP2279581A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
FR2906661A1 (fr) Procede pour fournir des parametres d&#39;authentification et des images logicielles dans des environnements de reseaux securises
FR2899749A1 (fr) Procede de protection d&#39;identite, dispositifs, et produit programme d&#39;ordinateur correspondants.
WO2007012584A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d&#39;ordinateur correspondants
FR2822002A1 (fr) Authentification cryptographique par modules ephemeres
EP1911194A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
WO2009130088A1 (fr) Terminal d&#39;authentification forte d&#39;un utilisateur
WO2017081208A1 (fr) Procede de securisation et d&#39;authentification d&#39;une telecommunication
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
WO2010106042A1 (fr) Procédé de production de données de sécurisation, dispositif et programme d&#39;ordinateur correspondant
EP3673633B1 (fr) Procédé d&#39;authentification d&#39;un utilisateur auprès d&#39;un serveur d&#39;authentification
EP2710779A1 (fr) Procede de securisation d&#39;une platforme d&#39;authentification, dispositifs materiels et logiciels correspondants
EP3266148B1 (fr) Dispositif et procédé d&#39;administration d&#39;un serveur de séquestres numériques
FR2946822A1 (fr) Dispositif et procede d&#39;acces securise a un service distant.
EP3825882A1 (fr) Procede et systeme pour le provisionnement ou remplacement securise d&#39;un secret dans au moins un dispositif de communication portable
CA3206749A1 (fr) Procede d&#39;echanges securises entre un lecteur de controle d&#39;acces, concentrateur iot et une unite de traitement de donnees
FR2901438A1 (fr) Un procede d&#39;embarquement d&#39;un protocole securise dans des cartes a puces, des capteurs et des objets intelligents
EP3679499A1 (fr) Enrôlement perfectionné d&#39;un équipement dans un réseau sécurisé
FR3025341A1 (fr) Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise
WO2014140456A1 (fr) Procédé, dispositif et programme d&#39;ordinateur pour optimiser la création d&#39;un domaine applicatif sécurisé entre un système informatique et une entité électronique

Legal Events

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

Ref document number: 201080012331.7

Country of ref document: CN

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

Ref document number: 10711036

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2010711036

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2754895

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 7072/DELNP/2011

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2011139616

Country of ref document: RU

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13257221

Country of ref document: US