Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/80—Wireless
• • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
• • 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/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols

Definitions

• the present invention relates to the field of identity protection in its network.
• the invention relates to a method for protecting the identity of a network user.
• the invention relates in particular to security modules, for example smart cards, enabling the secure implementation of this method, which can be used on the terminal of the user and / or on the server performing the authentication of the user. 'user of a network.
• the invention also relates to a method of managing a plurality of security modules by an authentication server.
• network In the context of the invention the term network must be understood in the most general sense. It designates home networks, based on ADSL modem
• Wi-Fi hotspots public networks equipped with base stations (UMTS, HSDPA) or hotspots (Wi-Fi, WiMax, ...), corporate networks or networks. administrations using LAN (Local Area Network), PLAN (Personal LAN), WLAN (Wireless LAN)
• LAN Local Area Network
• PLAN Personal LAN
• WLAN Wireless LAN
• terminal must be understood in the most general sense. It can for example designate a computer managed by an operating system.
• a computer may be equipped with one or more communication interfaces described by multiple standards such as IEEE 802.3 (“Ethernet” standard), IEEE 802.11 (“Wi-Fi” standard) and IEEE 802.16 (“WiMax” standard).
• IEEE 802.16e (“WiMobile” standard). It may also designate terminals mobile communications such as cell phones, personal assistants.
• authentication server must also be understood in the most general sense. It designates a computer managed by an operating system, comprising at least one communication interface and capable of rendering authentication services. 2 SOLUTIONS OF THE PRIOR ART
• the IETF Committee (“Internet Engineering Task Force") refers to the means required for the "Authentication Authorization Account” (AAA). the implementation of secure services that can be optionally billed in an IP-based communication infrastructure.
• the authentication process of a user usually consists in the presentation of an identity by a user to an authentication authority, and then in the production, always by this user, of proof establishing the real property of that user. identity and associated rights.
• An authentication protocol carries out all the operations required for the presentation phases of the identity and for obtaining proof of this identity.
• IP layer Internet Portocol
• UDP / TCP transport User Datagram Protocol
• IKE v2 authentication protocol
• EAP Extensible Authentication Protocol
• the EAP-TLS protocol is a transparent encapsulation of Transport Layer Security (TLS) specifically detailed in RFC 2716.
• EAP protocols can be applied to control access to MAC-level services (PPP in accordance with RFC 2284, Ethernet and Wi-Fi in accordance with IEEE 802. Ix, WiMax in accordance with IEEE 802.16 and IEEE 802.16e) but also VPN (IKEv2 described by RFC 4306, PPTP Point -to- Point Tunneling Protocol described by RFC 2637, L2F Cisco Layer Two Forwarding Protocol described by RFC 2341).
• TLS is an improved and non-proprietary version of the SSL ("Secure Socket Layer") protocol, patented by Netscape (US 5,657,390), which released version 2 at the end of 1994 and version 3 in November 1996.
• SSL Secure Socket Layer
• Netscape US 5,657,390
• a web server (301) presents to the remote client (typically a web browser, 201) its identity (inserted in a Certif ⁇ cate message 103) in the form of an X509 certificate.
• the client scans the server certificate, in particular, it verifies its signature using the public key of a CA (K P ⁇ CA ) that it trusts. If this check is successful, the client extracts the public key contained in the certificate (103, Kp u bs), and chooses a random number of 48 bytes, named PreMasterSecret (107), which is transmitted to the server using the key Kp u bs (in a ClientKeyExchange message 107).
• a disadvantage of this prior art technique is that the EAP-TLS protocol does not guarantee the confidentiality of the client's identity. Indeed, although the EAP-TLS protocol is widely deployed for controlling access to WLAN services (Wi-Fi, WiMax) or VPN (IKE v2, 7), the lack of identity protection For example, the client can obtain the list of people present outside the walls of a company or an administration. The unencrypted presentation of the identity also allows the observation of the movements of a client of wireless networks, and therefore an invasion of privacy.
• the knowledge of the identity of the clients on a network using the EAP-TLS protocol is realized by a passive attack or by an active attack.
• a trivial passive attack consists of listening to authentication exchanges, and noting the list of clients present in the network.
• a client's terminal is equipped with a Wi-Fi interface, and uses the EAP-TLS protocol. It then behaves like an RFID ("Radio Frequency Identification”) electronic tag that can be read at a distance of about 100m, and that allows to know the presence of a particular user.
• RFID Radio Frequency Identification
• An access point (AP, 301) hacker periodically broadcasts an identifier
• SSID Service Set Identifier
• Service Set Identifier for "Service Set Identifier”
• the client issues an "EAP-Start” packet (102)
• the AP issues an "EAP-Identity.request” message (104)
• the client responds with the message “EAP-Identity.response” (104).
• the AP sends a message “EAP-TLS. Start “(105).
• the client then produces a response "EAP-TLS. response "which contains the TLS message” ClientHello "(106).
• the malicious AP builds a "ServerHello” (107) message, which includes a certificate, that is, an authentication server identity in which the client has confidence.
• This identity can be obtained by listening and analyzing EAP-TLS messages, or by knowing server certificates that are by nature non-confidential.
• server certificates that are by nature non-confidential.
• ServerHello (107) has no security attributes, and can be forged easily, provided that a valid server identity is inserted. This message is sent to the client in an EAP-TLS message. request "(107). The client verifies the server certificate and passes its identity in an "EAP-
• the attacker has reached his goal, he has remotely obtained the identity of a client (109).
• the solution proposed by the invention overcomes these disadvantages of the prior art, with a method of authenticating a client terminal with an authentication server, said client terminal having an authentication certificate;
• such a method comprises the following phases: obtaining at least one encryption parameter by said client terminal; encrypting said authentication certificate by said client terminal, from said at least one encryption parameter, delivering an encrypted authentication certificate; transmitting said encrypted authentication certificate to said server; obtaining said at least one encryption parameter by said server; decrypting said encrypted authentication certificate from said at least one encryption parameter; - authentication and issuance of an authentication assertion if the authentication is positive.
• the invention is based on a completely new and inventive approach to client authentication within a network. Indeed, unlike the conventional approaches of the prior art, the invention proposes to encrypt the authentication certificate of the client before the latter is transferred to the server. The server then, using encryption parameters known to both the server and the client, to decrypt this certificate and certify the validity of the authentication of the client.
• said phase of encryption of said authentication certificate by said client terminal comprises the steps of: computation, by said client terminal, of a certificate encryption key according to said at least one parameter of encryption; encrypting said authentication certificate using said certificate encryption key.
• the client terminal is able to calculate an encryption key according to a calculation function, from the encryption parameters. He can then encrypt his certificate using this key that he has calculated to obtain an encrypted certificate. The encryption of the certificate is done on the client terminal.
• said phase of obtaining said at least one encryption parameter by said server comprises the steps of: encrypting said at least one encryption parameter by said client terminal as a function of at least one public key transmitted by said server to said terminal; transmission of said at least one encryption parameter encrypted by said client terminal to the server; decryption of said at least one encryption parameter encrypted by said server as a function of at least one asymmetric encryption private key to said at least one public encryption key.
• the terminal encrypts, using the public key of the server, the encryption parameters that were used to calculate the encryption key of the certificate. Subsequently, the terminal transmits these encrypted parameters to the server.
• the server decrypts these settings using its private key.
• said server is the only one able to decrypt these parameters (which have been encrypted using its public key). It is thus not possible for a third party to intercept these unencrypted parameters.
• a powerful mechanism for protecting encryption data is thus provided by a dual mechanism: transmission of an encrypted authentication certificate and transmission of the parameters used to encrypt the certificate, also in encrypted form.
• said at least one encryption parameter belongs to the group comprising at least: information representative of a random number obtained by said authentication server; information representative of a random number obtained by said client terminal; information representative of an encrypted number with said public key of said authentication server;
• the parameters used for certification encryption can have several origins: a random number coming from the server, a random number coming from the client, a number with the public key of the authentication server, for example.
• a random number coming from the server a random number coming from the client
• a number with the public key of the authentication server for example.
• said method is implemented within the EAP protocol.
• the identity protection method can be imbedded within known authentication methods, by providing new functionalities.
• the invention also relates to a method of encryption of identity by a client terminal having an authentication certificate, when an authentication of said terminal with an authentication server.
• a method of encryption of identity by a client terminal having an authentication certificate comprises the steps of: obtaining at least one encryption parameter by said client terminal; encrypting said authentication certificate by said client terminal, from said at least one encryption parameter; transmitting said encrypted authentication certificate to said server;
• the client terminal implementing the invention is able to encrypt its identity before it is transmitted to the authentication server.
• Such a method ensures that the identity of the terminal will not be transmitted in clear by means of a communication network.
• the invention also relates to a device for encrypting the identity of a client terminal having an authentication certificate, when an authentication of said terminal with an authentication server.
• such a device comprises means for: obtaining at least one encryption parameter; encrypting said authentication certificate from said at least one encryption parameter; transmitting said encrypted authentication certificate to said server;
• a device is allowed to encrypt the identity of a client terminal before it is transmitted to the server.
• said identity encryption device is implemented within a smart card implementing a virtual machine.
• this identity encryption device can be installed within a smart card, implementing an operating system, for example a virtual machine.
• this virtual machine can be of Java type and the smart card can be a "javacard”.
• the invention also relates to a method for decrypting the identity of a client terminal having an authentication certificate, by an authentication server during an authentication of said terminal with said authentication server.
• such a method comprises the steps of: receiving an encrypted authentication certificate from said client terminal; obtaining at least one encryption parameter by said server; decrypting said encrypted authentication certificate from said at least one encryption parameter; authentication and issuance of an authentication assertion if the authentication is positive.
• the invention also relates to a device for decrypting the identity of a client terminal having an authentication certificate, when an authentication of said terminal with an authentication server, according to the invention
• a device for decrypting the identity of a client terminal having an authentication certificate comprises means of: receiving an encrypted authentication certificate from said client terminal; obtaining at least one encryption parameter by said server; decrypting said encrypted authentication certificate from said at least one encryption parameter; authentication and issuance of an authentication assertion if the authentication is positive.
• a device is enabled to decrypt the identity of a client terminal that has been transmitted to a server.
• said decryption device is implemented within a smart card implementing a virtual machine.
• this device for decrypting identity can be installed within a smart card, implementing an operating system, for example a virtual machine.
• this virtual machine can be of Java type and the smart card can be a "javacard”.
• the invention 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 a client terminal authentication method with an authentication server such as previously described.
• 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.
• such a computer program product comprises program code instructions for the execution of the method of encryption of identity by a client terminal 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.
• a computer program product comprises program code instructions for executing the method of decrypting the identity of a client terminal as described above. 4 LIST OF FIGURES
• FIG. 1 already commented, presents a sequence diagram illustrating the messages exchanged during a TLS session;
• Figure 2 also already described, shows a sequence flow diagram of the steps of an attack to collect the identity of a client;
• FIG. 3 presents a sequence diagram implementing the identity protection method according to the invention;
• Figure 4 details the structure of a security module;
• Figure 5 illustrates a practical realization of an EAP-TLS application in a JAVA smart card context;
• FIG. 6 is a sequence diagram showing the use of a client security module according to the invention in the authentication of a client;
• FIG. 7 is a sequence diagram showing the use of a server security module according to the invention in the authentication of a client
• FIG. 8 shows a secure network architecture in which a RADIUS server, equipped with multiple security modules, manages multiple clients, also equipped with security modules.
• Figure 9 details the messages exchanged between a NAS and a RADIUS authentication server equipped with an EAP-TLS security module.
• FIG. 10 illustrates the notion of session identifier ("Session-Id") constructed from certain attributes of an "Access-Request" packet, and of its use for the processing of the EAP message by a particular security module .
• Session-Id session identifier
• the invention therefore proposes to protect the identity of the clients during the authentication process. This protection is all the more important as the identity of the users has become a real challenge, both for operators and access providers, and for the customers themselves, who do not want to not be monitored in their daily lives.
• the general principle of the invention relies on the encryption of the identity by a security module.
• FIG. 3 an embodiment of the invention applied to the EAP-TLS protocol is described.
• the authentication method according to the invention can be implemented in all the authentication methods where the client communicates his identity to the server.
• the messages are exchanged in accordance with the TLS protocol.
• Client Authentication Handshake the client (201) initiates the latter with a "ClientHello” message.
• the server responds with a set of messages "ServerHello” (102), "Certif ⁇ cate” (103), "CertificateRequest”
• the message "* Certificate” (106) is an encrypted form of the client certificate. More specifically, and in accordance with the TLS protocol, the message content is a succession of certificates, the first of which is assigned to the client, and the following of which (optionally present) are associated with one or more certification authorities.
• An illustrative method for calculating the key used (“KeyClientCertif ⁇ cate") for the encryption of the client certificate "* Certif ⁇ cate” (106) is then described. However, other methods, based on secret formulas, making attacks more difficult, can be used for this operation.
• the cryptographic keys can be generated using a function marked PRF for "Pseudo Random Function” (for "Pseudo Random Function”).
• the shared secret “MasterSecret” is calculated from the parameter “PreMas ter Secret” and two random numbers (“ClientRandom” and “ServerRandom”) exchanged in the messages “ClientHello” (101) and “ServerHello” (102).
• the key “MasterSecret” can be defined by:
• PRF PreMasterSecret, "master secret”, ClientRandom
• In this case refers to a concatenation operation.
• other cryptographic keys are obtained using the parameter "MasterSecret” and a label (an ASCII string). These other keys also use the PRF function:
• the "KeyClientCertif ⁇ cate" encryption key of the client's certificate is obtained by a relation of the type (106):
• F is a function that uses “PreMas ter Secret”, “ServerRandom”, “ClientRandom” and other "OtherParameters” calculation parameters. For example, it is possible to use the following function:
• PRF MasterSecret, "certified client”, ClientRandom
• the client therefore protects his identity by encrypting his X509 certificate, using a part of an encryption algorithm, for example on the fly and secondly the key "KeyClientCertificate” associated with this cryptographic algorithm, for example RC4 or AES in "Counter Mode” mode.
• the fingerprint values MD5 and SHAl functions
• the fingerprint values used in messages such as "CertficateVerify” (108) and "Finished” (110, 112) are then calculated taking into account the contents of the client certificate. (106) encrypted. Indeed, this certificate appears in the "Certficate” message in encrypted form (106).
• the server receives the messages "* Certificate” (106), "CertificateVerify”
• PRF MasterSecret, "client certificate”, ClientRandom
• the server can then decrypt the client's certificate.
• the server then completes the opening phase of the TLS session by producing the two messages "ChangeCipherSpec" (111) and "Finished” (112).
• PreMas terSecret can only be decrypted by the server, since only the latter has the private key capable of decrypting it.
• "PreMaster Secret” was encrypted, by the client, using the public key of the server "K pu bs", transmitted to the client, by the server, during the transmission of the certificate (103). But only the holder of the private key "Kp ⁇ v s" can decode the encrypted messages with this public key "K pu bs".
• security module designates a silicon integrated circuit
• Tamper Resistant Device usually referred to as "Tamper Resistant Device”, literally an “attack resistant component”, such as for example an ST22 component, produced by the company ST Microelectronics (registered trademark) and available in different formats such as PVC, (smart cards, SIM card, ...) integrated in USB tokens, or in memories MMC (MultiMedia Card).
• ST22 component produced by the company ST Microelectronics (registered trademark) and available in different formats such as PVC, (smart cards, SIM card, 7) integrated in USB tokens, or in memories MMC (MultiMedia Card).
• MMC MultiMedia Card
• such a security module comprises a central unit (CPU, 201), a ROM memory storing the operating system code (202), RAM memory (203), and a non-volatile memory (NVR, 204). ), used as a storage device analogous to a hard disk, and which contains for example an embedded software TLS or EAP-TLS.
• a system bus (200) connects the different components of the secure module.
• the interface with the outside world (301) is provided by an IO input / output port (205), conforming to standards such as
• JAVA smart cards commonly referred to as
• JAVACARD can constitute a particular class of security module.
• TLS protocol specifications compliant with the TLS protocol specifications, in client and server mode.
• client and server mode compliant with the acronym
• Such a component (100) commonly has a communication interface compliant with ISO 7816 (201), an embedded JAVA machine (202), and a set of JAVA classes (203) defined by the JavaCard Forum allowing in particular the use a library of cryptographic functions (204).
• the EAP-TLS application (300) is then defined as a set of JAVA modules.
• the so-called EAP Engine class, "EapEngine.class” (301) provides four basic services:
• the personalization (404) of the security module ie all the operations necessary for writing the data of the cardholder, in the memory of the component.
• the interface with the network (405) which analyzes the received EAP packets and transmits them to the EAP-TLS method.
• the EAP-TLS authentication method is performed by the "Method.class” module (303). It is initialized with the data associated with a particular context (certificate of the CA, client certificate, RSA private key, etc.) using an "Init” procedure (501), whose the argument an object
• the EAP messages (600) analyzed by the network interface (405) are processed by the "ProcessEap” procedure (502) of the "Method.class” module (303).
• the JAVA interface "Auth.class” (304) provides the logical link between the modules “EapEngine.class” (301) and “Method.class” (303).
• a security module (201) containing client EAP-TLS software (101) is described in connection with FIG. This program realizes the protocol
• the module receives through an input / output communication port ( Figure 4, 205) EAP-TLS messages and produces the appropriate responses.
• the module stores the certificate of at least one CA (102) and its RSA public key (103).
• the identity of the module ie the client's certificate (104), is also stored securely. However, this certificate is not never communicated in unencrypted form to the outside world.
• the public (107) and private (106) RSA keys are also managed by the security module.
• an "MSK" key (108) is available for the user entity of the module, typically an operating system.
• the EAP-TLS authentication dialogue is described more precisely from the point of view of the client security module (201) implementing the identity protection protocol according to the invention.
• An access point (401) indicates to the client the occurrence of a new authentication session by producing an "EAP-Identity.request” message (301).
• the security module inserts its identifier (EAP-ID) in an "EAP-Identity.response” message (302). It is recommended, without this being limiting, that this identifier provides information relating to the authentication server and not the client.
• the authentication server transmits a packet "EAP-TLS. Start “(303) which marks the beginning of an EAP-TLS session.
• the client issues an EAP-TLS message which carries a TLS packet of type "ClientHello" (304).
• the server produces a suite (305) of messages ("ServerHello”, “Certificate”, “CertificateRequest”, “ServerHelloDone”) that define in particular the server certificate, its public key, the certificate the CA (Certifying Authority), and the type (s) of client certificates recognized by the server.
• the client When receiving the EAP-TLS message (305), the client analyzes the validity of the server certificate, retrieves the associated public key, chooses a random value "PreMas ter Secret” and encrypts this value (with the public key of the server) in a "ClientKeyExchange” message.
• the client's certificate is encrypted with the "KeyClientCertificate” key previously described, according to the identity protection process.
• the TLS message suite (307), "Certificate”, “ClientKeyExchange”, “CertificateVerify", "Finished” is inserted into an EAP-TLS packet and sent to the server.
• the server verifies this message list and notifies the smooth running of this operation by the messages (308) "ChangeCipherSpec” and "Finished” encapsulated in an EAP-TLS packet.
• the customer confirms receipt of (308) by an EAP-TLS acknowledgment (309).
• the server ends the EAP-TLS session with an "EAP-Success" message
• the client After receiving this indication, the client calculates a master key "MSK" (108). The latter is made available to the client's operating system, using a command of the specific security module (311). The execution, by a security module (201), of a TLS client software or
• EAP-TLS (101), equipped according to the invention with an identity protection mechanism, provides the following advantages:
• the server certificate (305) is verified in a secure computing environment; -
• the client software (101) communicates its identity (104) encrypted (106) to a server entity that he trusts, and who is the only one to decipher this information;
• the TLS messages exchanged between server and client can be read and analyzed by any observer of the network.
• the only information obtained by an observer will be the identity of the server.
• the latter is not critical data in the case of an authentication procedure.
• a security module (401) which contains a server EAP-TLS software (101). This program realizes the protocol
• the TLS receives EAP-TLS packets through an I / O communication port ( Figure 4, 205) and produces the appropriate messages.
• the module stores the certificate of at least one CA (102) and its RSA public key (103).
• the server certificate (107) along with its public (109) and private (108) RSA keys are also managed by the security module.
• an MSK key (108) is available for the user entity of the module, such as for example a RADIUS authentication server.
• the EAP-TLS authentication dialogue is described in detail below from the point of view of the server security module (101).
• This module is connected physically or logically to an authentication server, for example of the "RADIUS" type (201) or to any other device using a server EAP entity.
• the EAP server receives an "EAP-Identity.request” message (301) that marks the initialization of an EAP session. It issues an "EAP- TLS.Start” message (303) that indicates the start of an EAP-TLS session.
• the remote client sends an EAP-TLS packet (305) which carries a TLS message "ClientHello” (304).
• the server then produces a series of TLS messages, "ServerHello”, “Certificate”, “CertificateRequest”, “ServerHelloDone”.
• the client analyzes the validity of the server certificate, retrieves the associated public key, chooses a random value "PreMas ter Secret” and encrypts this value (with the public key of the server) in a "ClientKeyExchange” message .
• the client certificate is encrypted (307) with the key "KeyClientCertificate” described above.
• the suite (306) of TLS messages "Certificate”, “ClientKeyExchange”, “CertificateVerify", "Finished” is inserted into an EAP-TLS packet and sent to the server.
• the server checks this list of messages, in particular it finds the value "PreMas ter Secret” with the help of its private key Kp ⁇ v s. It then calculates "KeyClientCertificate” and obtains the client's certificate in clear. It notifies the smooth running of this operation by the messages (308) "ChangeCipherSpec” and "Finished” encapsulated in an EAP-TLS package.
• the customer confirms receipt of (308) "ChangeCipherSpec” and "Finished” by an EAP-TLS acknowledgment (309).
• the security module ends the EAP-TLS session by an "EAP-Success” message (310) and calculates an "MSK” master key (108).
• the latter is made available to the operating system of the server (201) using a specific command (311) of the security module.
• EAP-TLS (101), equipped with an identity protection mechanism according to the invention, provides the following advantages:
• the server security module which is the only one to know and use the private key Kp ⁇ v s (108) is the only entity that knows the identity of the client;
• Validation of this identity is indicated by a cryptographic method in the last "Finished” message (309) issued by the server.
• an authentication server for example of the "RADIUS” type
• a server security module the latter makes available an "MSK” key (109), used, for example, to ensure the security of communications.
• MSK “MSK” key
• the invention thus provides an innovative technical solution for managing the connection of a client and then providing the security infrastructure key "MSK" of this client, without making his identity public.
• An embodiment of the invention is presented in a RADIUS authentication infrastructure. We therefore consider a network infrastructure that supports a large number of customers, equipped with security modules
• EAP-TLS according to the invention. These clients are managed by one or more RADIUS servers according to the constraints of the network.
• the invention makes it possible to obtain a level of confidence that is optimal when the authentication sessions are performed by pairs of security modules EAP client and server.
• each server is capable of handling multiple simultaneous EAP-TLS sessions.
• the operating systems of the security modules usually supervise countermeasures, intended to counter logical and physical intrusion attacks. These countermeasures significantly reduce the computational performance of these components.
• a RADIUS infrastructure implemented to take advantage of the identity protection method according to the invention is presented.
• a set of clients (201, 202, 203) optionally provided with security modules (101, 102, 103) are controlled by NAS ("Network Administration Server” for "Network Administration Server”) ( 301, 302, 303), located for example in access points of this network.
• NAS Network Administration Server
• Each of them is associated, via the Internet 401, a single authentication server RADIUS (501), made by software (502), executed by a computer system with an operating system.
• This RADIUS server is also capable of exchanging, via physical and / or logical interfaces 503, information with a plurality of server security modules (601, 602, 603).
• many free software such as
• OPENRADIUS or "FREERADIUS” offer RADIUS authentication services.
• the integration of security modules in these software is performed using physical interfaces (503) and / or logical supported by many operating systems, for example USB or PC / SC (Personal Computer / SmartCard). 5.5.2 Messages exchanged
• FIG. 9 shows the details of the information exchanged, in the form of messages, between a NAS, presented in the form of an access point (101), a RADIUS authentication server (201). and an EAP-TLS security module (301).
• the latter comprises, in accordance with the preceding descriptions, an RSA private key and X509 certificate issued by a CA certification authority.
• RADIUS session denotes a sequence of packets exchanged between the NAS and the RADIUS authentication server. These packets convey information exchanged between an EAP client and an EAP server.
• a session begins with the receipt of an "EAP-Identity.response” message (601), includes an “Access-Request” (501) packet, and ends with the generation of a notification, typically a " EAP-Success "(610) in an” Access-Accept "package (510).
• An "EAP-Identity.response” message is carried by a packet
• RADIUS "Acces-Request” (501).
• a message “E AP-TLS. request “, named” EAP-TLS. Start “(602) is transmitted to the access point in a RADIUS" Access-Challenge “packet (502).
• the EAP-TLS message encapsulating the TLS protocol element "ClientHello” (603) is carried by the RADIUS packet "Access-Request” (503).
• the TLS packet comprising the following messages "ServerHello, Certificate”, “CertificateRequest”, “ServerHelloDone” is typically split according to the rules of the EAP-TLS protocol into two fragments (604) (606). Each of them is carried in a RADIUS package “Access-Challenge” (504) (506). The first fragment is acknowledged by an EAP-TLS message (605) carried by a RADIUS packet (505). After receiving the second and last fragment (606), the client (who wishes to be identified and authenticated) analyzes the re-assembled message.
• the client Upon receiving the second fragment (606), the client analyzes the validity of the server certificate, retrieves the associated public key, chooses a value Random “PreMas ter Secret” and encrypts this value (with the public key of the server) in a "ClientKeyExchange” message.
• the client certificate is encrypted with the key "KeyClientCertificate” described above.
• the suite of TLS messages, "Certificate”, “ClientKeyExchange”, “CertificateVerify", "Finished” is inserted in an EAP-TLS packet (607), then in a RADIUS "Access-Request" (507) packet and sent to the server .
• the server checks this message list, in particular it finds the value
• PreMas ter Secret calculates "KeyClientCertificate” and obtains the client's certificate in clear. If this operation succeeds, the messages (608) "ChangeCipherSpec” and "Finished” are encapsulated in an EAP-TLS packet, then in a RADIUS message "Access-Challenge” (508).
• An EAP-TLS acknowledgment message (609) is carried in a RADIUS "Access-Request" packet (509).
• the security module then indicates the success of the authentication using the "EAP-Success” message.
• the RADIUS server reads the MSK key using a specific command (611) and makes the final RADIUS message "Access-
• the server security module notifies the success of an authentication and delivers an MSK key to the RADIUS server without revealing the identity (the certificate without encryption) of the client.
• a RADIUS packet of the "Access-Request” type are presented. Such messages are transmitted by multiple NAS (from “Network Access Server” for “Network Access Server”) to a RADIUS authentication server ( Figure 8, 501).
• An Access-Request packet carries, among other information, an EAP response.
• a RADIUS server that receives this packet produces in return a message of the type "Access-Challenge", “Access- Accept” or “Access-Reject", encapsulating as a rule an EAP request or notification.
• IP User Datagram Protocol
• UDP communication stacks User Datagram Protocol
• the header comprises the code of the message (201) or "Access-Request" in our example, a label (202) such that the value of a response is equal to the value of a request, the length of the packet (203). ) and a random number of 16 bytes (204).
• a RADIUS message carries a variable number of attributes (205, 206, 207, 207, 209, 210, 211, 212, 213, 214, 215) that are identified in Figure 10 by a name allocated by RFC 2865 and RFC 3559.
• a session is identified on the one hand by a list of information relating to the remote client (205, 208) and on the other hand by a list of information relating to the SIN used by the client (206). , 207, 207, 209, 210, 213).
• Each session is associated with a unique identifier ("Session-Id") obtained by the concatenation of attributes included in an "Access-Request" message.
• Session-Id a unique identifier obtained by the concatenation of attributes included in an "Access-Request" message.
• the value of the "Session-Id" (301) can be constructed by concatenating the two following attributes:
• Session-Id NAS-Identifier
• NAS-Identifier (209) (RADIUS attribute number 32) represents a unique identifier of the NAS issued by the network administrator or hardware manufacturer.
• “Calling-Station-Id” (208) (RADIUS attribute number 31) represents a unique identifier of the client, for example the unique MAC address of the network adapter that it uses.
• the authentication server assigns each session, uniquely identified by the value "Session-Id", a security module.
• Session-Id a security module.
• the "Access-Request” package is ignored by the software RADIUS, the remote NAS therefore receives no notification of this event.
• An EAP message is encapsulated, based on its size, in one or more attributes (214) whose useful length is 254 bytes.
• the RADIUS server software checks the correct value of the attribute
• the server security module implementing the identity protection method according to the invention, is able to deliver the identity of the client terminal to the RADIUS server in order to obtain an authentication assertion of the from the latter.
• the maximum number of authentication sessions managed simultaneously by a server RADIUS software is equal to the number of security modules.
• technological progress especially in terms of performance, make it possible to consider the simultaneous management of several authentication sessions by a security module.
• the RADIUS software can assign multiple sessions to each security module.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer And Data Communications (AREA)
• Storage Device Security (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=37772855

Family Applications (1)

Country Status (7)

Families Citing this family (21)

Family Cites Families (9)

• 2006
  • 2006-04-07 FR FR0603114A patent/FR2899749B1/fr not_active Expired - Fee Related
• 2007
  • 2007-04-03 EP EP07727739A patent/EP2012907A2/de not_active Withdrawn
  • 2007-04-03 CN CN200780019624A patent/CN101657992A/zh active Pending
  • 2007-04-03 CA CA002648377A patent/CA2648377A1/en not_active Abandoned
  • 2007-04-03 US US12/296,392 patent/US20100005290A1/en not_active Abandoned
  • 2007-04-03 RU RU2008142008/08A patent/RU2451398C2/ru not_active IP Right Cessation
  • 2007-04-03 WO PCT/EP2007/053268 patent/WO2007115982A2/fr active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events