FR2899749A1 - Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. - Google Patents
Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. Download PDFInfo
- Publication number
- FR2899749A1 FR2899749A1 FR0603114A FR0603114A FR2899749A1 FR 2899749 A1 FR2899749 A1 FR 2899749A1 FR 0603114 A FR0603114 A FR 0603114A FR 0603114 A FR0603114 A FR 0603114A FR 2899749 A1 FR2899749 A1 FR 2899749A1
- Authority
- FR
- France
- Prior art keywords
- authentication
- server
- certificate
- encryption
- client terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/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
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)
Abstract
L'invention concerne un procédé d'authentification d'un terminal client auprès d'un serveur d'authentification, ledit terminal client possédant un certificat d'authentification.Selon l'invention, un tel procédé comprend les phases suivantes :- obtention d'au moins un paramètre de cryptage par ledit terminal client ;- chiffrement dudit certificat d'authentification par ledit terminal client, à partir dudit au moins un paramètre de cryptage, délivrant un certificat d'authentification chiffré ;- transmission dudit certificat d'authentification chiffré audit serveur ;- obtention dudit au moins un paramètre de cryptage par ledit serveur ;- déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ;- authentification et délivrance d'une assertion d'authentification si l'authentification est positive.
Description
Procédé de protection d'identité, dispositifs, et produit programme
d'ordinateur correspondants. 1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de la protection d'identité au sien de réseau. Plus précisément, l'invention concerne un procédé de protection d'identité d'un usager de réseaux. L'invention concerne notamment des modules de sécurité, par exemple des cartes à puce, permettant la mise en oeuvre sécurisée de ce procédé, qui peuvent être utilisés sur le terminal de l'usager et/ou sur le serveur réalisant l'authentification de l'usager d'un réseau. L'invention se rapporte encore à un procédé de gestion d'une pluralité de modules de sécurité par un serveur d'authentification. Dans le cadre de l'invention le terme réseau doit être compris dans le sens le plus général. Il désigne des réseaux domotiques, basés sur des modem ADSL (de l'anglais Asymmetric Digital Subscriber Line pour Ligne d'Abonné Numérique Asymétrique ) et des points d'accès Wi-Fi, des réseaux publics munis de stations de base (UMTS, HSDPA) ou de hotspots (Wi-Fi, WiMax,
.), des réseaux d'entreprises ou d'administrations utilisant des infrastructures de type LAN ( Local Area Network pour Réseau Local ), PLAN ( Personal LAN pour Réseau Local Personnel ), WLAN ( Wireless LAN pour Réseau Local sans File ) ou MAN ( Metropolitan Area Network pour Réseau Métropolitain ) De même le terme terminal doit être compris dans le sens le plus général...DTD: Il peut désigner par exemple un ordinateur géré par un système d'exploitation. De plus un tel ordinateur peut être équipé d'une ou plusieurs interfaces de communication décrites par de multiples normes telles que IEEE 802.3 (norme Ethernet ), IEEE 802.11 (norme Wi-Fi ) IEEE 802.16 (norme WiMax ), IEEE 802.16e (norme WiMobile ). Il peut également désigner des terminaux de communication mobiles tels que des téléphones portables, des assistants personnels. Le terme serveur d'authentification doit être également compris dans le sens le plus général. Il désigne un ordinateur géré par un système d'exploitation, comportant au moins une interface de communication et apte à rendre des services d'authentification. 2 SOLUTIONS DE L'ART ANTERIEUR 2.1 Art antérieur Une préoccupation majeure des particuliers, des organisations privées ou publiques qui utilisent, gèrent ou déploient des services de communication consiste en la fourniture de l'assurance de la sécurité des informations échangées. Cette assurance de sécurité est particulièrement exigée dans le cas de technologies de communication radio dans lesquelles il est possible d'écouter à distance des informations échangées (ce procédé est parfois qualifié de parking lot attack pour Attaque du Parking dans la littérature scientifique Anglo-saxonne). Le comité IETF ( Internet Engineering Task Force pour Groupe de Travail d'Ingénierie de l'Internet ) désigne sous le sigle AAA ( Authentication Authorization Accounting pour Compte d'autorisation d'authentification ) les moyens nécessaires pour la mise en oeuvre de services sécurisés et pouvant être optionnellement facturés dans une infrastructure de communication basée sur le protocole IP. Le processus d'authentification d'un usager consiste de manière habituelle à la présentation d'une identité par un usager à une autorité d'authentification, puis à la production, toujours par cet usager, d'une preuve établissant la réelle propriété de cette identité et des droits associés. Un protocole d'authentification réalise l'ensemble des opérations nécessaires aux phases de présentation de l'identité et à d'obtention d'une preuve de cette identité. Il existe plusieurs protocoles d'authentification. Ils contrôlent les accès aux services offerts par l'intermédiaire de différentes couches du modèle de communication OSI ( Open Systems Interconnection pour Interconnexion de Systèmes Ouverts ) : Contrôle de l'accès au niveau MAC (couche OSI numéro 2) des réseaux locaux. Ce mode d'opération est en particulier mis en oeuvre par les standards PPP ( Point to Point Protocol pour Protocole de Point à Point ) et les normes de communications mobiles ; - Contrôle de l'accès au niveau des couches OSI 3 et 4: couche IP ( Internet Portocol pour Protocole Internet ) et transport UDP/TCP ( User Datagram Protocol pour Protocole de gestion de datagrammes utilisateurs , Transport Control Protocol pour protocole de contrôle de transport dans la terminologie du modèle Internet). Ce mode d'opération est typiquement utilisé pour l'ouverture de connexions qualifiées de VPN ( Virtual Private Network pour Réseau Privé Virtuel ) au moyen du protocole d'authentification IKEv2, par exemple.
En raison de l'importance croissante des problèmes de sécurité induits par l'usage généralisé des réseaux de communication, particulièrement dans des environnements radios, l'IETF a ratifié un standard baptisé EAP ( Extensible Authentication Protocol pour Protocole d'Authentification Extensible ). Cette norme permet le transport de multiples scenarii d'authentification, dont certains sont définis par les spécifications EAP-TLS (RFC 2246), EAP-SIM (RFC 4186), et EAP-AKA (RFC 4187). Le protocole EAP-TLS, introduit par le RFC 2246 est une encapsulation transparente du protocole TLS ( Transport Layer Security pour Sécurité de la Couche de Transport ) précisément détaillée par le document RFC 2716.
Les protocoles EAP peuvent être appliqués au contrôle d'accès de services de niveau MAC (PPP conformément à RFC 2284, Ethernet et Wi-Fi conformément à IEEE 802.1x, WiMax conformément à IEEE 802.16 et IEEE 802.16e) mais également VPN (IKEv2 décrit par le RFC 4306, PPTP Point-to-Point Tunneling Protocol décrit par le RFC 2637, L2F Cisco Layer Two Forwarding Protocol décrit par le RFC 2341).
TLS est: une version améliorée et non propriétaire du protocole SSL ( Secure Socket Layer pour Couche d'encapsulation sécurisée ), breveté par la société Netscape (US 5,657,390) qui a publié la version 2 fin 1994 et la version 3 en Novembre 1996.
On décrit, en relation avec la figure 1, le fonctionnement standard du protocole TLS. Dans un usage classique, un serveur web (301) présente au client distant (typiquement un navigateur web, 201) son identité (insérée dans un message Certificate 103) sous la forme d'un certificat X509. Le client analyse le certificat du serveur, en particulier il vérifie sa signature à l'aide de la clé publique d'une autorité de certification (KpubcA) à qui il fait confiance. En cas de succès de cette vérification, le client extrait la clé publique contenue dans le certificat (103, Kpubs), et choisit un nombre aléatoire de 48 octets, nommé PreMasterSecret (107) qui est transmis au serveur à l'aide de la clé KPäbs (dans un message ClientKeyExchange 107). Tous les matériaux cryptographiques utiles au protocole TLS sont déduits de la connaissance du paramètre PreMasterSecret. On remarquera d'une part que dans ce cas le client ne dévoile pas son identité (c'est une simple authentification), et d'autre part que l'identité du serveur circule en clair, c'est à dire de manière non chiffrée à travers le réseau Internet. Lorsque le protocole TLS est utilisé dans un scénario d'authentification tel que EAP-TLS, l'authentification du client est obligatoire; cette procédure de mutuelle authentification est usuellement nommée Client Authentication handshake pour Authentification du client mutuelle . Le client transmet en clair au serveur son identité (dans un message Certificate 106), c'est à dire son certificat X509. Il réalise la preuve de cette identité en réalisant une signature des messages de type handshake (Poignée de main) préalablement échangés entre les deux entités (client et serveur), à l'aide de sa clé privée Kpriäc. Cette information est transportée par un message appelé CertificateVerify (108). Le serveur vérifie l'identité du serveur grâce à deux opérations : 1. l'analyse du certificat X509 présenté par le client, duquel il extrait en particulier sa clé publique KPubc ; 2. la bonne valeur de la signature contenue dans le message CertificateVerify, contrôlée à l'aide de la clé KPä bc.
L'utilisation du protocole TLS conduit donc le client à dévoiler son identité au cours de la phase d'authentification. 2.2 Inconvénients de l'art antérieur Un inconvénient de cette technique de l'art antérieur est que le protocole EAP-TLS ne garantit pas la confidentialité de l'identité du client.
En effet, bien que le protocole EAP-TLS soit largement déployé pour le contrôle d'accès à des services WLAN (Wi-Fi, WiMax) ou VPN (IKEv2,...), l'absence de protection de l'identité du client permet par exemple d'obtenir à l'extérieur des murs d'une entreprise ou d'une administration la liste des personnes présentes.
La présentation en clair de l'identité autorise également l'observation des déplacements d'un client de réseaux sans fil, et par conséquent une atteinte à la vie privée. La connaissance de l'identité des clients sur un réseau utilisant le protocole EAP-TLS est réalisée par une attaque passive ou par une attaque active. Une attaque passive triviale consiste à écouter les échanges d'authentification, et à noter la liste des clients présents dans le réseau. On décrit, en relation avec la figure 2, une attaque active utilisant le protocole EAP--TLS. Dans ce scénario, le terminal d'un client est équipé d'une interface Wi-Fi, et utilise le protocole EAP-TLS. Il se comporte alors comme une étiquette électronique RFID ( Radio Frequency Identification pour Identification par radio fréquence ) qui peut être lue à une distance de l'ordre de 100m, et qui permet de connaître la présence d'un utilisateur particulier. Un point d'accès (AP, 301) pirate diffuse périodiquement un identifiant SSID ( Service Set Identifier pour Identificateur d'Ensemble de Service ), interprété par le poste client comme l'identifiant d'un AP autorisé. Conformément au protocole IEEE 802.1x une session d'authentification s'engage. Le client émet un paquet EA.P-Start (102), l'AP délivre un message EAP-Identity.request (104), le client répond par le message EAP-Identity.response (104). L'AP transmet un message EAP-TLS.Start (105).
Le client produit alors une réponse EAP-TLS.response qui contient le message TLS ClientHello (106). L'AP malveillant construit un message ServerHello (107), qui comporte un certificat, c'est à dire une identité de serveur d'authentification dans lequel le client a confiance. Cette identité peut être obtenue par l'écoute préalable et l'analyse de messages EAP--TLS, ou bien par la connaissance de certificats serveur qui sont par nature non confidentiels. Conformément au protocole TLS le message ServerHello (107) ne possède aucun attribut de sécurité, et peut être forgé facilement, à condition d'insérer une identité de serveur valide. Ce message est transmis au client dans un message EAP-TLS.request (107). Le client vérifie le certificat du serveur et transmet son identité dans une réponse EAPTLS.response qui transporte un message TLS de type Certificate (108). L'attaquant a atteint son but, il a obtenu à distance l'identité d'un client (109). Cette description d'une attaque active classique permet de mettre en avant l'inconvénient majeur de cette technique d'authentification utilisée par le protocole EAP-TLS, obligeant le client à découvrir son identité. 3 RESUME DE L'INVENTION La solution proposée par l'invention permet de pallier ces inconvénients de l'art antérieur, grâce à un procédé d'authentification d'un terminal client auprès d'un serveur d'authentification, ledit terminal client possédant un certificat d'authentification ; Selon l'invention, un tel procédé comprend les phases suivantes : - obtention d'au moins un paramètre de cryptage par ledit terminal client ; - chiffrement dudit certificat d'authentification par ledit terminal client, à partir dudit au moins un paramètre de cryptage, délivrant un certificat d'authentification chiffré ; - transmission dudit certificat d'authentification chiffré audit serveur ; - obtention dudit au moins un paramètre de cryptage par ledit serveur ; - déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ; - authentification et délivrance d'une assertion d'authentification si l'authentification est positive. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de l'authentification de clients au sein d'un réseau. En effet, à la différence des approches conventionnelles de l'art antérieur, l'invention propose de chiffrer le certificat d'authentification du client avant que ce dernier ne soit transféré au serveur. Le serveur se charge ensuite, à l'aide de paramètres de cryptages connus tant du serveur que du client, de déchiffrer ce certificat et d'attester de la validité de l'authentification du client. Selon un aspect particulier de l'invention, ladite phase de chiffrement dudit 15 certificat d'authentification par ledit terminal client comprend les étapes de : - calcul, par ledit terminal client, d'une clé de chiffrement de certificat en fonction dudit au moins un paramètre de cryptage ; - chiffrement dudit certificat d'authentification à l'aide de ladite clé de chiffrement de certificat. 20 Ainsi, le terminal client est à même de calculer une clé de chiffrement selon une fonction de calcul, à partir des paramètres de cryptage. Il peut alors chiffrer son certificat à l'aide de cette clé qu'il a calculé pour obtenir un certificat chiffré. Le chiffrement du certificat se fait donc sur le terminal client. Selon une caractéristique particulière de l'invention, ladite phase 25 d'obtention dudit au moins un paramètre de cryptage par ledit serveur comprend les étapes de : - chiffrement dudit au moins un paramètre de cryptage par ledit terminal client en fonction d'au moins une clé publique transmise par ledit serveur audit terminal ; 30 -transmission dudit au moins un paramètre de cryptage chiffré par ledit terminal client audit serveur ; - déchiffrement dudit au moins un paramètre de cryptage chiffré par ledit serveur en fonction d'au moins une clé privée de chiffrement asymétrique à ladite au moins une clé publique de chiffrement.
Le terminal chiffre, à l'aide de la clé publique du serveur, les paramètres de cryptage qui ont servi au calcul de la clé de chiffrement du certificat. Par la suite, le terminal transmet ces paramètres chiffrés au serveur. Le serveur déchiffre ces paramètres à l'aide de sa clé privée. Le serveur est donc le seul à pouvoir déchiffrer ces paramètres (qui ont été chiffrés à l'aide de sa clé publique). Il n'est ainsi pas possible, pour un tiers, d'intercepter ces paramètres non chiffrés. On fournit donc un mécanisme puissant de protection de données de cryptage, par un double mécanisme : transmission d'un certificat d'authentification chiffré et transmission des paramètres ayant servi au chiffrement du certificat, également de manière chiffré.
Selon un aspect original de l'invention, ledit au moins un paramètre de cryptage appartient au groupe comprenant au moins : - une information représentative d'un nombre aléatoire obtenu par ledit serveur d'authentification ; - une information représentative d'un nombre aléatoire obtenu par ledit terminal client ; - une information représentative d'un nombre chiffré avec ladite clé publique dudit serveur d'authentification ; Les paramètres servant au cryptage du certification peuvent avoir plusieurs origines : un nombre aléatoire en provenance du serveur, un nombre aléatoire en provenance du client, un nombre avec la clé publique du serveur d'authentification, par exemple. Ainsi, on garantit que les paramètres servant au chiffrement du certificat ne sont pas des constantes ou des nombres facilement reproductibles et qu'ils ne pourront pas faire l'objet d'une découverte par un tiers. De ce fait, on augmente encore la protection de l'identité du client.
Selon une caractéristique particulière de l'invention, ledit procédé est mis en oeuvre au sein du protocole SSL et/ou TLS. Selon un aspect original, ledit procédé est mis en oeuvre au sein du protocole EAP.
Ainsi, le procédé protection d'identité peut s'imbriquer au sein de procédés d'authentification connus, en y apportant de nouvelles fonctionnalités. L'invention concerne également un procédé de chiffrement d'identité par un terminal client possédant un certificat d'authentification, lors d'une authentification dudit terminal auprès d'un serveur d'authentification.
Selon l'invention, un tel procédé comprend les étapes de : - obtention d'au moins un paramètre de cryptage par ledit terminal client ; -chiffrement dudit certificat d'authentification par ledit terminal client, à partir dudit au moins un paramètre de cryptage ; - transmission dudit certificat d'authentification chiffré audit serveur ; Dans ce mode de réalisation, le terminal client mettant en oeuvre l'invention est à même de chiffrer son identité avant qu'elle ne soit transmise au serveur d'authentification. Un tel procédé permet de s'assurer que l'identité du terminal ne sera pas transmise en clair par le biais d'un réseau de communication. L'invention concerne également un dispositif de chiffrement d'identité d'un terminal client possédant un certificat d'authentification, lors d'une authentification dudit terminal auprès d'un serveur d'authentification. Selon l'invention, un tel dispositif comprend des moyens : - d'obtention d'au moins un paramètre de cryptage ; - de chiffrement dudit certificat d'authentification, à partir dudit au moins un paramètre de cryptage ; - de transmission dudit certificat d'authentification chiffré audit serveur ; Dans cet autre mode de réalisation, on permet à un dispositif de chiffrer l'identité d'un terminal client avant qu'elle ne soit transmise au serveur.
Selon un aspect particulier de l'invention, ledit dispositif de chiffrement d'identité est mis en oeuvre au sein d'une carte à puce implémentant une machine virtuelle. Ainsi, ce dispositif de chiffrement d'identité peut être installé au sein d'une carte à puce, mettant en oeuvre un système d'exploitation, par exemple une machine virtuelle. Selon un aspect particulier, cette machine virtuelle peut être de type Java et la carte à puce peut être une javacard . L'invention concerne encore un procédé de déchiffrement d'identité d'un terminal client possédant un certificat d'authentification, par un serveur d'authentification lors d'une authentification dudit terminal auprès dudit serveur d'authentification. Selon l'invention, un tel procédé comprend les étapes de : - réception d'un certificat d'authentification chiffré en provenance dudit terminal client ; - obtention d'au moins un paramètre de cryptage par ledit serveur ; - déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ; -authentification et délivrance d'une assertion d'authentification si l'authentification est positive.
Ce procédé, selon un mode particulier de réalisation de l'invention, permet ainsi de déchiffrer l'identité d'un terminal client qui protège son identité. L'invention concerne également un dispositif de déchiffrement d'identité d'un terminal client possédant un certificat d'authentification, lors d'une authentification dudit terminal auprès d'un serveur d'authentification, Selon l'invention un tel dispositif comprend des moyens de : - réception d'un certificat d'authentification chiffré en provenance dudit terminal client ; - obtention d'au moins un paramètre de cryptage par ledit serveur ; - déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ; - authentification et délivrance d'une assertion d'authentification si l'authentification est positive. Dans cet autre mode de réalisation, on permet à un dispositif de déchiffrer l'identité d'un terminal client qui a été transmise à un serveur.
Selon un aspect particulier de l'invention, ledit dispositif de déchiffrement est mis en oeuvre au sein d'une carte à puce implémentant une machine virtuelle. Ainsi, ce dispositif de déchiffrement d'identité peut être installé au sein d'une carte à puce, mettant en oeuvre un système d'exploitation, par exemple une machine virtuelle. Selon un aspect particulier, cette machine virtuelle peut être de type Java et la carte à puce peut être une javacard . Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur.
Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution procédé d'authentification d'un terminal client auprès d'un serveur d'authentification tel que décrit précédemment. Dans un autre mode de réalisation, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de chiffrement d'identité par un terminal client tel que décrit précédemment. Dans un autre mode de réalisation, l'invention concerne encore un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur.
Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de déchiffrement d'identité d'un terminal client 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, déjà commentée, présente un diagramme de séquence illustrant les messages échangés au cours d'une session TLS ; - La figure 2, également déjà décrite, présente un diagramme de séquence d'enchaînement des étapes d'une attaque visant à collecter l'identité d'un client ; - La figure 3 présente un diagramme de séquence mettant en oeuvre le procédé de protection de l'identité selon l'invention ; - La figure 4 détaille la structure d'un module de sécurité ; - La figure 5 illustre une réalisation pratique d'une application EAP-TLS dans un contexte de carte à puce JAVA ; - La figure 6 est un diagramme de séquence présentant l'utilisation d'un module de sécurité client selon l'invention dans l'authentification d'un client ; - La figure 7 est un diagramme de séquence présentant l'utilisation d'un module de sécurité serveur selon l'invention dans l'authentification d'un 25 client ; - La figure 8 présente une architecture réseau sécurisée dans laquelle un serveur RADIUS, équipé de multiples modules de sécurité, gère de multiples clients, également équipés de modules de sécurité. - La figure 9 détaille les messages échangés entre un NAS et un serveur 30 d'authentification RADIUS équipé d'un module de sécurité EAP-TLS. - La figure 10 illustre la notion d'identifiant de session ( Session-Id ) construit à partir de certain attributs d'un paquet Access-Request , et de son usage pour le traitement du message EAP par un module de sécurité particulier. 5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention L'invention propose donc de protéger l'identité des clients lors de processus d'authentification. Cette protection est d'autant plus importante que l'identité des utilisateurs est devenu un véritable enjeu, tant vis-à-vis des opérateurs que des fournisseurs d'accès ou encore vis-à-vis des clients eux-mêmes, qui ne souhaitent pas faire l'objet de surveillance dans leur vie quotidienne. Le principe général de l'invention repose sur le cryptage de l'identité par un module de sécurité. On décrit, en relation avec la figure 3, un mode de réalisation de l'invention appliqué au protocole EAP-TLS. Cependant, le procédé d'authentification selon l'invention peut être mis en oeuvre dans toutes les méthodes d'authentification où le client fait part de son identité au serveur. Dans un processus d'authentification EAP-TLS, les messages sont échangés en conformité avec le protocole TLS. Durant une session de mutuelle authentification ( Client Authentication Handshake ) le client (201) initie cette dernière par un message ClientHello . Le serveur répond par un ensemble de messages ServerHello (102), Certificate (103), CertificateRequest (104), ServerHelloDone (105). Le client délivre alors les messages *Certificate (106), CertificateVerify (107), ClientKeyExchange (108), ChangeCipherSpec (109), et Finished (110). Le message *Certificate (106) est une forme chiffrée du certificat du client. Plus précisément, et conformément au protocole TLS le contenu de message est une succession de certificats, dont le premier est affecté au client, et dont les suivants (présents de manière optionnelle) sont associés à une ou plusieurs autorités de certification.
On décrit par la suite, à titre d'illustration une méthode pratique de calcul de la clé utilisée ( KeyClientCertificate ) pour le chiffrement du certificat du client *Certificate (106). Cependant d'autres procédés, basés sur des formules secrètes, rendant plus difficiles les attaques, peuvent être utilisés pour cette opération. Dans le protocole TLS, les clés cryptographiques peuvent être générées à l'aide d'une fonction notée PRF pour Pseudo Random Function (pour Fonction Pseudo Aléatoire ). Le secret partagé MasterSecret est calculé à partir du paramètre PreMasterSecret et deux nombres aléatoires ( ClientRandom et ServerRandom ) échangés dans les messages ClientHello (101) et ServerHello (102). La clé MasterSecret peut donc être définie par : MasterSecret= PRF(PreMasterSecret,"master secret",ClientRandomlServerRandom).
Le signe 1 désigne dans ce cas une opération de concaténation. Par la suite, lors de la phase d'authentification, d'autres clés cryptographiques sont obtenues à l'aide du paramètre MasterSecret et d'une étiquette (une chaîne de caractères ASCII). Ces autres clés utilisent également la fonction PRF : Clés = PRF(MasteSecret,Etiquette,ServerRandomlClientRandom) Selon l'invention, la clé de chiffrement KeyClientCertificate du certificat du client est obtenue par une relation du type (106) : KeyClientCertificate = F(PreMasterSecret, ServerRandom,ClientRandom,OtherParameters ) Dans ce cas, F est une fonction qui utilise PreMasterSecret , ServerRandor , ClientRandom et d'autres paramètres de calculs OtherParameters . Par exemple, il est possible d'utiliser la fonction suivante : KeyClientCertificate = PRF(MasterSecret,"client certificate",ClientRandomlServerRandom) Le client protège donc son identité en chiffrant son certificat X509, à l'aide d'une part d'un algorithme de chiffrement, par exemple à la volée et d'autre part de la clé KeyClientCertificate associée à cet algorithme cryptographique, par exemple RC4 ou AES en mode Counter Mode . Conformément aux spécifications du protocole TLS les valeurs d'empreintes (fonctions MD5 et SHA1) utilisées dans des messages tels que CertficateVerify (108) et Finished (110, 112), sont alors calculées en tenant compte du contenu du certificat client (106) chiffré. En effet, ce certificat apparaît dans le message Certficate sous une forme chiffrée (106). Le serveur reçoit les messages *Certificate (106), CertificateVerify (107), ClientKeyExchange (108), ChangeCipherSpec (109), et Finished (110). Il déchiffre la valeur du PreMasterSecret , contenue dans le message ClientKeyExchange (108) à l'aide de sa clé privée Kpris . Il en déduit la clé de chiffrement qui protège le certificat du client (106) en appliquant, à l'aide de la valeur du PreMasterSecret déchiffrée, une fonction de chiffrement identique à celle appliquée de son côté par le client pour obtenir la valeur de KeyClientCertificate . Dans un mode de réalisation particulier, appliqué à la fonction PRF de TLS, on a la formule suivante : KeyClientCertificate = PRF(MasterSecret,"client certificate",ClientRandomlServerRandom) Le serveur peut alors déchiffrer le certificat du client.
Le serveur termine ensuite la phase d'ouverture de la session TLS en produisant les deux messages ChangeCipherSpec (111) et Finished (112). Or, PreMasterSecret ne peut être déchiffré que par le serveur, puisque seul celui-ci possède la clé privée susceptible de la déchiffrer. Par exemple dans la cas l'EAP-TLS, PreMasterSecret a été chiffré, par le client, à l'aide de la clé publique du serveur Kpä bs , transmise au client, par le serveur, lors de la transmission du certificat (103). Or seul le détenteur de la clé privée Kpri,s peut décoder les messages chiffrés avec cette clé publique Kpä bs . On assure ainsi que l'identité du client est conservée secrète et que seul le serveur est à même de décoder cette identité.
On a donc décrit un mode de réalisation du procédé de cryptage de l'identité du client mis en oeuvre dans le cadre d'un processus d'authentification mutuel à l'aide du procédé EAP-TLS. Le client ne partage donc plus son identité en clair sur le réseau. Cette identité fait l'objet d'un chiffrement et seul le serveur possédant les informations de déchiffrement adéquat est à même de s'assurer de l'identité du client à authentifier. En effet, pour trouver la clé de chiffrement du certificat du client KeyClientCertificate le serveur doit détenir les mêmes informations que le client. De manière générale, ces informations sont celles utilisées pour trouver la clé de chiffrement à l'aide de la fonction F .
Dans le mode de réalisation particulier appliqué à EAP-TLS, le serveur doit posséder les mêmes arguments pour la fonction PRF que ceux utilisés par le client : MasterSecret , client certificate , ClientRandom et ServerRandorn . Par la suite, on présente notamment le cas d'un module de sécurité mettant en oeuvre le procédé de protection de l'identité du client, ainsi que l'intégration de tels modules dans un serveur d'authentification de type RADUIS . Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans d'autres types de serveurs d'authentification et plus généralement dans tous les cas où des mécanismes de protection d'identité sont recherchés. 5.2 Description du module de sécurité On présente dans ce mode de réalisation, en relation avec la figure 4, un module de sécurité mettant en oeuvre le procédé de protection de l'identité de l'invention.
On désigne sous le terme module de sécurité un circuit intégré de silicium (101), qualifié usuellement de Tamper Resistant Device , littéralement un composant résistant aux attaques , tel que par exemple un composant ST22, produit par la société ST Microelectronics (marque déposée) et disponible sous différents formats tels que des cartes de PVC, (cartes à puce, carte SIM,...) intégrés 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, un tel module de sécurité comporte une unité centrale (CPU, 201), une mémoire ROM stockant le code du système d'exploitation (202), de la mémoire RAM (203), et une mémoire non volatile (NVR, 204), utilisée comme dispositif de stockage analogue à une disque dur, et qui contient par exemple un logiciel embarqué TLS ou EAP-TLS. Un bus système (200) relie les différents organes du module sécurisé. L'interface avec le monde extérieur (301) est assuré par un port IO d'entrée/sortie (205), conforme à des standards tels que ISO7816, USB, ISO7816-12, MMC, IEEE 802.3, IEEE 802.11, etc. Les cartes à puces JAVA, communément désignées par le terme JAVACARD, peuvent constituer une classe particulière de module de sécurité. En l'état de l'art, il est possible de charger et d'exécuter dans ces composants des programmes conformes aux spécifications du protocole TLS, en mode client et serveur. A titre d'illustration de tels logiciels sont connus sous le sigle OpenEapSmartcard . Des articles scientifiques décrivent d'ors et déjà la réalisation de clients et de serveurs EAP-TLS dans des javacards . Le procédé de protection d'identité préalablement décrit, au vue de la description préalable qui en est faite, pourra aisément être mis en oeuvre par un homme du métier dans un logiciel EAP-TLS client (ou serveur) exécuté dans une Javacard . On décrit, en relation avec la figure 5, une réalisation pratique d'une application EAP-TLS dans un contexte de carte à puce JAVA. Un tel composant (100) possède communément une interface de communication conforme à la norme ISO 7816 (201), une machine JAVA embarquée (202), et un ensemble de classes JAVA (203) définies par le JavaCard Forum permettant en particulier l'usage d'une bibliothèque de fonctions cryptographiques (204). L'application EAP-TLS (300) est alors définie comme un ensemble de modules JAVA.
La classe dite Moteur EAP, EapEngine.class (301) assure quatre services fondamentaux : La gestion (402) des lettres de crédits du porteur de la carte, c'est à dire de données sensibles telles des clés RSA privées ou certificats X509, stockés dans une mémoire non volatile (401) û La personnalisation (404) du module de sécurité, c'est à dire l'ensemble des opérations nécessaires à l'écriture des données du porteur de la carte, dans la mémoire du composant. Le gestion de la sécurité (403) de la carte à puce, dont l'usage est protégé par exemple par un PIN code associé à un mécanisme de blocage après trois présentations erronées. L'interface avec le réseau (405) qui analyse les paquets EAP reçus et les transmet vers la méthode EAP-TLS. La méthode d'authentification EAP-TLS est réalisée par le module Method.class (303). Elle est initialisée avec les données associées à un contexte particulier (Certificat de l'autorité de certification CA , certificat du client, clé privée RSA...) à l'aide d'une procédure Init (501), dont l'argument un objet JAVA Credential.class (302). Les messages EAP (600) analysés par l'interface réseau (405) sont traités par la procédure ProcessEap (502) du module Method.class (303). L'interface JAVA Auth.class (304) assure le lien logique entre les modules EapEngine.class (301) et Method.class (303). 5.3 Module de sécurité client On décrit, en relation avec la figure 6, un module de sécurité (201) qui contient un logiciel EAP-TLS client (101). Ce programme réalise le protocole TLS, il reçoit à travers un port de communication d'entrée/sortie (figure 4, 205) des messages EAP-TLS et produit les réponses appropriées. En outre le module stocke le certificat d'au moins une autorité de certification CA (102) et sa clé publique RSA (103). L'identité du module, c'est à dire le certificat du client (104), est également stockée de manière sécurisée. Cependant ce certificat n'est jamais communiqué sous forme non chiffrée au monde extérieur. Les clés RSA publiques (107) et privée (106) sont également gérées par le module de sécurité. A la fin du protocole EAP-TLS, une clé MSK (108) est disponible pour l'entité utilisatrice du module, typiquement un système d'exploitation.
On décrit plus précisément le dialogue d'authentification EAP-TLS, du point de vue du module de sécurité client (201) mettant en oeuvre le protocole de protection de l'identité selon l'invention. Un point d'accès (401) indique au client l'occurrence d'une nouvelle session d'authentification en produisant un message EAP-Identity.request (301). Le module de sécurité insère son identifiant (EAP-ID) dans un message EAP-Identity.response (302). Il est recommandé, sans que ceci présente un caractère limitatif, que cet identifiant fournisse une information relative au serveur d'authentification et non au client. Le serveur d'authentification transmet un paquet EAP-TLS.Start (303) qui marque le début d'une session EAP-TLS. En réponse à cet événement le client émet un message EAP-TLS qui transporte un paquet TLS de type ClientHello (304). Conformément au protocole TLS, précédemment décrit, le serveur produit une suite (305) de messages ( ServerHello , Certificate , CertificateRequest , ServerHelloDone ) qui définissent en particulier le certificat du serveur, sa clé publique, le certificat du CA (Autorité Certificatrice), et le ou les types de certificats clients reconnus par le serveur. Lors de la réception du message EAP-TLS (305), le client analyse la validité du certificat serveur, extrait la clé publique associée, choisit une valeur aléatoire PreMasterSecret et chiffre cette valeur (avec la clé publique du serveur) dans un message ClientKeyExchange . Le certificat du client est chiffré avec la clé KeyClientCertificate décrite précédemment, selon le procédé de protection de l'identité. La suite (307) de messages TLS, Certificate , ClientKeyExchange , CertificateVerify , Finished est insérée dans un paquet EAP-TLS et envoyée au serveur.
Le serveur vérifie cette liste de message et notifie le bon déroulement de cette opération par les messages (308) ChangeCipherSpec et Finished encapsulés dans un paquet EAP-TLS. Le client confirme la bonne réception de (308) par un acquittement EAP-TLS (309).
Le serveur termine la session EAP-TLS par un message EAP-Success (310). Après réception de cette indication, le client calcule une clé maître MSK (de l'anglais Master Secret Key ) (108). Cette dernière est mise à la disposition du système d'exploitation du client, à l'aide d'une commande du module de sécurité spécifique (311).
L'exécution, par un module de sécurité (201), d'un logiciel client TLS ou EAP-TLS (101), muni selon l'invention d'un mécanisme de protection d'identité, procure les avantages suivants : Le certificat du serveur (305) est vérifié dans un environnement informatique sûr ; - Le logiciel client (101) ne communique son identité (104) chiffrée (106) qu'à une entité serveur a qui il fait confiance, et qui est la seule à pouvoir déchiffrer cette information ; - Il réalise la non répudiation de sa décision à l'aide de la signature, basée sur sa clé RSA privée Knivc (106) contenue dans le message CertificateVerify (307). De par leurs constitutions, les messages TLS échangés entre serveur et client peuvent être lus et analysés par tout observateur du réseau. Dans le cas d'un dialogue avec protection d'identité, tel que le propose l'invention, la seule information obtenue par un observateur sera l'identité du serveur. Cette dernière n'est pas une donnée critique dans le cas d'une procédure d'authentification. 5.4 Module de sécurité serveur On présente, en relation avec la figure 7, un module de sécurité (401) qui contient un logiciel EAP-TLS serveur (101). Ce programme réalise le protocole TLS, il reçoit à travers un port de communication d'entrée/sortie (figure 4, 205) des paquets EAP-TLS et produit les messages appropriés. En outre le module stocke le certificat d'au moins une autorité de certification CA (102) et sa clé publique RSA (103). Le certificat du serveur (107) ainsi que ses clés RSA publique (109) et privée (108) sont également gérés par le module de sécurité. A la fin du protocole EAP-TLS, une clé MSK (108) est disponible pour l'entité utilisatrice du module, tel que par exemple un serveur d'authentification RADIUS. On décrit par la suite de manière détaillée le dialogue d'authentification EAP-TLS, du point de vue du module de sécurité serveur (101). Ce module est connecté physiquement ou logiquement à un serveur d'authentification, par exemple de type RADIUS (201) ou à tout autre dispositif utilisant une entité EAP serveur. Le serveur EAP reçoit un message EAP-Identity.request (301) qui marque l'initialisation d'une session EAP. Il délivre un message EAPTLS.Start (303) qui indique le début d'une session EAP-TLS. Le client distant envoie un paquet EAP-TLS (305) qui transporte un message TLS ClientHello (304). Le serveur produit alors une suite de messages TLS, ServerHello , Certificate , CertificateRequest , ServerHelloDone . Lors de la réception de (305) le client analyse la validité du certificat serveur, extrait la clé publique associée, choisit une valeur aléatoire PreMasterSecret et chiffre cette valeur (avec la clé publique du serveur) dans un message ClientKeyExchange . Le certificat du client est chiffré (307) avec la clé KeyClientCertificate décrite précédemment. La suite (306) de messages TLS Certificate , ClientKeyExchange , CertificateVerify , Finished est insérée dans un paquet EAP-TLS et envoyée au serveur. Le serveur vérifie cette liste de messages, en particulier il retrouve la valeur PreMasterSecret à l'aide de sa clé privée Kp s. Il calcule alors KeyClientCertificate et obtient le certificat du client en clair. Il notifie le bon déroulement de cette opération par les messages (308) ChangeCipherSpec et Finished encapsulés dans un paquet EAP-TLS. Le client confirme la bonne réception de (308) ChangeCipherSpec et 30 Finished par un acquittement EAP-TLS (309). Le module de sécurité termine la session EAP•-TLS par un message EAP-Success (310) et calcule une clé maître MSK (108). Cette dernière est mise à disposition du système d'exploitation du serveur (201) à l'aide d'une commande spécifique (311) du module de sécurité.
L'exécution, par un module de sécurité (201), d'un logiciel serveur TLS ou EAP-TLS (101), muni d'un mécanisme de protection d'identité selon l'invention, procure les avantages suivants : - Le module de sécurité serveur, qui est le seul à connaître et à utiliser la clé privé Kp.j s (108) est l'unique entité qui a connaissance de l'identité du 10 client ; - L'identité du client est de surcroît certifiée par le message CertificateVerify (306) ; - La validation de cette identité est indiquée par un procédé cryptographique dans le dernier message Finished (309) émis par le serveur. 15 Lorsqu'un serveur d'authentification, par exemple de type RADIUS , utilise un module de sécurité serveur, ce dernier met à sa disposition une clé MSK (109), utilisée, par exemple, pour assurer la sécurité des communications d'un couple point d'accès et client d'un réseau sans fil. L'invention apporte donc une solution technique innovante en permettant 20 de gérer la connexion d'un client puis de mettre à disposition de l'infrastructure de sécurité la clé MSK de ce client, sans rendre son identité publique. 5.5 Mise en oeuvre des modules de sécurité dans une infrastructure d'authentification On présente un mode de réalisation de l'invention dans une infrastructure 25 d'authentification de type RADIUS. On considère donc une infrastructure réseau qui supporte un nombre important de clients, équipés de modules de sécurité EAP-TLS selon l'invention. Ces clients sont administrés par un ou plusieurs serveurs RADIUS en fonction des contraintes du réseau. L'invention permet d'obtenir un niveau de confiance est optimal lorsque 30 les sessions d'authentification sont réalisées par des couples de module de sécurité EAP client et serveur. Dans cette infrastructure, chaque serveur est capable de gérer de multiples sessions EAP-TLS simultanées. Dans cette infrastructure, les systèmes d'exploitation des modules de sécurité supervisent usuellement des contre-mesures, destinées à parer les attaques par intrusion logique et physique. Ces contre-mesures diminuent significativement les performances de calculs de ces composants. Nous allons donc décrire un procédé de mise en oeuvre de multiples modules de sécurité, par un serveur d'authentification RADIUS. Ce procédé autorise la gestion de plusieurs sessions simultanées et rend possible l'usage de modules de sécurité serveur, dans des réseaux supportant une grande population d'utilisateurs sans diminution des performances. 5.5.1 Description de l'infrastructure On présente, en relation avec la figure 8, une infrastructure RADIUS mis en oeuvre pour tirer partie du procédé de protection d'identité selon l'invention.
Un ensemble de clients, (201, 202, 203) munis de façon optionnelle de modules de sécurité (101, 102, 103), sont contrôlés par des NAS ( Network Administration Server pour Serveur d'administration de réseau ) (301, 302, 303), situés par exemple dans des points d'accès de ce réseau. Chacun d'entre eux est associé, par le biais du réseau Internet 401, à un unique serveur d'authentification RADIUS (501), réalisé par un logiciel (502), exécuté par un système informatique muni d'un système d'exploitation. Ce serveur RADIUS est capable de surcroît d'échanger, par le biais d'interfaces physiques et/ou logiques 503, des informations avec une pluralité de modules de sécurité serveur (601, 602, 603).
Dans l'état actuel, de nombreux logiciels libres tels que OPENRADIUS ou FREERADIUS offrent des services d'authentification RADIUS. L'intégration de modules de sécurité dans ces logiciels est réalisée à l'aide d'interfaces physiques (503) et/ou logiques supportées par de nombreux systèmes d'exploitation, par exemple USB ou PC/SC (Personal Computer / SmartCard). 5.5.2 Messages échangés On présente, en relation avec la figure 9, le détail des informations échangées, sous la forme de messages, entre un NAS, présenté sous la forme d'un point d'accès (101), un serveur d'authentification RADIUS (201) et un module de sécurité EAP-TLS (301). Ce dernier comporte, conformément aux descriptions précédentes, une clé privée RSA et certificat X509 délivré par une autorité de certification CA. On désigne sous le terme session RADIUS (401) une suite de paquets échangés entre le NAS et le serveur d'authentification RADIUS. Ces paquets véhiculent des informations échangées entre un client EAP et un serveur EAP. Côté serveur RADIUS une session commence par la réception d'un message EAP-Identity.response (601), inclus un paquet Access-Request (501), et se termine par la génération d'une notification, typiquement un EAPSuccess (610) dans un paquet Access-Accept (510).
Un message EAP-Identity.response est transporté par un paquet RADIUS Acces-Request (501). Un message EAP-TLS.request , nommé EAP-TLS.Start (602) est transmis au point d'accès dans un paquet RADIUS Access-Challenge (502). Le message EAP-TLS encapsulant l'élément de protocole TLS ClientHello (603) est transporté par le paquet RADIUS Access-Request (503). Le paquet TLS comportant la suite des messages ServerHello, Certificate , CertificateRequest , ServerHelloDone est typiquement découpé selon les règles du protocole EAP-TLS, en deux fragments (604) (606). Chacun d'entre eux est transporté dans un paquet RADIUS Access-Challenge (504) (506). Le premier fragment est acquitté par un message EAP-TLS (605) transporté par un paquet RADIUS (505). Après réception du deuxième et dernier fragment (606), le client (qui souhaite être identifié et authentifié) analyse le message re-assemblé. Lors de la réception du deuxième fragment (606), le client analyse la validité du certificat serveur, extrait la clé publique associée, choisit une valeur aléatoire PreMasterSecret et chiffre cette valeur (avec la clé publique du serveur) dans un message ClientKeyExchange . Le certificat du client est chiffré avec la clé KeyClientCertificate décrite précédemment. La suite de messages TLS, Certificate , ClientKeyExchange , CertificateVerify , Finished est insérée dans un paquet EAP-TLS (607), puis dans un paquet RADIUS Access-Request (507) et envoyée au serveur. Le serveur vérifie cette liste de message, en particulier il retrouve la valeur PreMasterSecret , calcule KeyClientCertificate et obtient le certificat du client en clair. En cas de succès de cette opération les messages (608) ChangeCipherSpec et Finished sont encapsulés dans un paquet EAP-TLS, puis dans un message RADIUS Access-Challenge (508). Un message d'acquittement EAP-TLS (609) est transporté dans un paquet RADIUS Access-Request (509). Le module de sécurité indique alors le succès de l'authentification à l'aide du message EAP-Success . Le serveur RADIUS lit la clé MSK à l'aide d'une commande spécifique (611) et fabrique l'ultime message RADIUS Access-Accept (510) qui comporte en particulier les deux moitiés MS-MPPESendKey et MS-MPPE-RecvKey de la clé MSK. A la vue de la description précédente on constate que le module de sécurité serveur notifie le succès d'une authentification et délivre une clé MSK au serveur RADIUS sans dévoiler l'identité (le certificat sans chiffrement) du client. On présente, en relation avec la figure 10, le contenu d'un paquet RADIUS, de type Access-Request . De tels messages sont transmis par de multiples NAS (de l'anglais Network Access Server pour Serveur d'Accès Réseau ) vers un serveur d'authentification RADIUS (Figure 8, 501). Un paquet Access-Request transporte, entre autres informations, une réponse EAP. Un serveur RADIUS qui reçoit ce paquet produit en retour un message du type Access-Challenge , Access-Accept ou Access-Reject , encapsulant en règle générale une requête ou une notification EAP.
On présente en détail le contenu d'un paquet Access-Request (101), transporté par les piles de communication W et UDP (de l'anglais User Datagram Protocol pour Protocole d'échange de datagrammes utilisateurs ), qui comporte deux parties un entête (102) et une liste d'attributs (103).
L'entête comporte le code du message (201) soit Access-Request dans notre exemple, une étiquette (202) telle que la valeur d'une réponse soit égale à la valeur d'une requête, la longueur du paquet (203) et un nombre aléatoire de 16 octets (204). Un message RADIUS transporte un nombre variable d'attributs (205, 206, 207, 207, 209, 210, 211, 212, 213, 214, 215) qui sont identifiés dans la figure 10 par un nom alloué par les normes RFC 2865 et RFC 3559. Du point de vue du serveur RADIUS une session est identifiée d'une part par une liste d'information relative au client distant (205, 208) et d'autre part par une liste d'information relative au NAS utilisé par le client (206, 207, 207, 209, 210, 213). Chaque session est associée à un identifiant unique ( Session-Id ) obtenu par la concaténation d'attributs inclus dans un message Access-Request . On peut construire, à titre d'exemple, la valeur du Session-Id (301) grâce à la concaténation des deux attributs suivants : Session-Id = NAS-Identifier I Calling-Station-Id. NAS-Identifier (209) (attribut RADIUS numéro 32) représente un identifiant unique du NAS délivré par l'administrateur du réseau ou le fabricant du matériel. Calling-Station-Id (208) (attribut RADIUS numéro 31) représente un identifiant unique du client, par exemple l'adresse MAC unique de la carte réseau qu'il utilise. En liaison avec le protocole de protection de l'identité selon l'invention, le serveur d'authentification affecte à chaque session, identifiée de manière unique par la valeur Session-Id , un module de sécurité. Lorsque aucun module de sécurité n'est disponible, le paquet Access-Request est ignoré par le logiciel RADIUS, le NAS distant ne reçoit en conséquence aucune notification de cet événement. Un message EAP est encapsulé, en fonction de sa taille, dans un ou plusieurs attributs (214) dont la longueur utile est de 254 octets.
Le logiciel du serveur RADIUS vérifie la valeur correcte de l'attribut (215), un HMAC-MD5 protégé par une clé secrète (appelée le secret RADIUS). En cas de succès le message EAP est re-assemblé puis envoyé vers le module de sécurité (501) associé à la session RADIUS identifiée par (301). Ainsi, le module de sécurité serveur, mettant en oeuvre le procédé de protection de l'identité selon l'invention, est à même de délivrer l'identité du terminal client au serveur RADIUS en vue d'obtenir une assertion d'authentification de la part de ce dernier. Par suite, lorsque chaque module d'authentification gère au plus une session, le nombre maximal de sessions d'authentification gérées simultanément par un logiciel RADIUS serveur est égal au nombre de modules sécurité.
Cependant les progrès technologiques, notamment en terme de performance, permettent d'envisager la gestion simultanée de plusieurs sessions d'authentification par un module de sécurité. Dans ce cas le logiciel RADIUS peut affecter plusieurs sessions à chaque module de sécurité.
Claims (15)
1. Procédé d'authentification d'un terminal client auprès d'un serveur d'authentification, ledit terminal client possédant un certificat d'authentification, caractérisé en ce qu'il comprend les phases suivantes : - obtention d'au moins un paramètre de cryptage par ledit terminal client ; - chiffrement dudit certificat d'authentification par ledit terminal client, à partir dudit au moins un paramètre de cryptage, délivrant un certificat d'authentification chiffré ; - transmission dudit certificat d'authentification chiffré audit serveur ; 10 - obtention dudit au moins un paramètre de cryptage par ledit serveur ; - déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ; - authentification et délivrance d'une assertion d'authentification si l'authentification est positive. 15
2. Procédé d'authentification selon la revendication 1, caractérisé en ce que ladite phase de chiffrement dudit certificat d'authentification par ledit terminal client comprend les étapes de : - calcul, par ledit terminal client, d'une clé de chiffrement de certificat en fonction dudit au moins un paramètre de cryptage ; 20 - chiffrement dudit certificat d'authentification à l'aide de ladite clé de chiffrement de certificat.
3. Procédé d'authentification selon l'une quelconque des revendications 1 et 2 caractérisé en ce que ladite phase d'obtention dudit au moins un paramètre de cryptage par ledit serveur comprend les étapes de : 25 -chiffrement dudit au moins un paramètre de cryptage par ledit terminal client en fonction d'au moins une clé publique transmise par ledit serveur audit terminal ; transmission dudit au moins un paramètre de cryptage chiffré par ledit terminal client audit serveur ; 30 - déchiffrement dudit au moins un paramètre de cryptage chiffré par leditserveur en fonction d'au moins une clé privée de chiffrement asymétrique à ladite au moins une clé publique de chiffrement ;
4. Procédé d'authentification selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit au moins un paramètre de cryptage appartient au groupe comprenant au moins : une information représentative d'un nombre aléatoire obtenu par ledit serveur d'authentification ; - une information représentative d'un nombre aléatoire obtenu par ledit terminal. client ; - une information représentative d'un nombre chiffré avec ladite clé publique dudit serveur d'authentification ;
5. Procédé d'authentification selon l'une quelconque des revendications 1 à 4 caractérisé en ce qu'il est mis en oeuvre au sein du protocole SSL et/ou TLS.
6. Procédé d'authentification selon la revendication 5 caractérisé en ce qu'il est mis en oeuvre au sein du protocole EAP.
7. Procédé de chiffrement d'identité par un terminal client possédant un certificat d'authentification, lors d'une authentification dudit terminal auprès d'un serveur d'authentification, caractérisé qu'il comprend les étapes de : - obtention d'au moins un paramètre de cryptage par ledit terminal client ; - chiffrement dudit certificat d'authentification par ledit terminal client, à partir dudit au moins un paramètre de cryptage ; - transmission dudit certificat d'authentification chiffré audit serveur ;
8. Dispositif de chiffrement d'identité d'un terminal client possédant un certificat d'authentification, lors d'une authentification dudit terminal auprès d'un serveur d'authentification, caractérisé qu'il comprend des moyens : - d'obtention d'au moins un paramètre de cryptage ; - de chiffrement dudit certificat d'authentification, à partir dudit au moins unparamètre de cryptage ; - de transmission dudit certificat d'authentification chiffré audit serveur ;
9. Dispositif de chiffrement d'identité selon la revendication 8, caractérisé en ce qu'il est mis en oeuvre au sein d'une carte à puce implémentant une machine virtuelle.
10. Procédé de déchiffrement d'identité d'un terminal client possédant un certificat d'authentification, par un serveur d'authentification lors d'une authentification dudit terminal auprès dudit serveur d'authentification, caractérisé qu'il comprend les étapes de : - réception d'un certificat d'authentification chiffré en provenance dudit terminal client ; - obtention d'au moins un paramètre de cryptage par ledit serveur ; - déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ; - authentification et délivrance d'une assertion d'authentification si l'authentification est positive.
11. Dispositif de déchiffrement d'identité d'un terminal client possédant un certificat d'authentification, lors d'une authentification dudit terminal auprès d'un serveur d'authentification, caractérisé qu'il comprend des moyens de : - réception d'un certificat d'authentification chiffré en provenance dudit terminal client ; - obtention d'au moins un paramètre de cryptage par ledit serveur ; - déchiffrement dudit certificat d'authentification chiffré, à partir dudit au moins un paramètre de cryptage ; - authentification et délivrance d'une assertion d'authentification si l'authentification est positive.
12. Dispositif de déchiffrement d'identité selon la revendication 11, caractérisé en ce qu'il est mis en oeuvre au sein d'une carte à puce implémentant une machine virtuelle.
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é d'authentification d'un terminal client auprès d'un serveur d'authentification selon l'une au moins des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.
14. 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 chiffrement d'identité par un terminal client selon la revendication 7 lorsqu'il est exécuté sur un ordinateur.
15. 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 déchiffrement d'identité d'un terminal client selon la revendication 10 lorsqu'il est exécuté sur un ordinateur.20
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0603114A FR2899749B1 (fr) | 2006-04-07 | 2006-04-07 | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. |
| CA002648377A CA2648377A1 (fr) | 2006-04-07 | 2007-04-03 | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants |
| CN200780019624A CN101657992A (zh) | 2006-04-07 | 2007-04-03 | 身份保护方法、装置和相应的计算机程序产品 |
| EP07727739A EP2012907A2 (fr) | 2006-04-07 | 2007-04-03 | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants |
| PCT/EP2007/053268 WO2007115982A2 (fr) | 2006-04-07 | 2007-04-03 | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants |
| US12/296,392 US20100005290A1 (en) | 2006-04-07 | 2007-04-03 | Method of identity protection, corresponding devices and computer softwares |
| RU2008142008/08A RU2451398C2 (ru) | 2006-04-07 | 2007-04-03 | Способы аутентификации, шифрования и декодирования идентификатора клиентского терминала и устройства для их реализации |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0603114A FR2899749B1 (fr) | 2006-04-07 | 2006-04-07 | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2899749A1 true FR2899749A1 (fr) | 2007-10-12 |
| FR2899749B1 FR2899749B1 (fr) | 2008-07-04 |
Family
ID=37772855
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0603114A Expired - Fee Related FR2899749B1 (fr) | 2006-04-07 | 2006-04-07 | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20100005290A1 (fr) |
| EP (1) | EP2012907A2 (fr) |
| CN (1) | CN101657992A (fr) |
| CA (1) | CA2648377A1 (fr) |
| FR (1) | FR2899749B1 (fr) |
| RU (1) | RU2451398C2 (fr) |
| WO (1) | WO2007115982A2 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113010880A (zh) * | 2021-02-08 | 2021-06-22 | 上海新时达电气股份有限公司 | 电梯配件认证方法、系统、服务器和存储介质 |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102007009023B4 (de) * | 2007-02-23 | 2011-12-22 | Siemens Ag | Vorrichtung und Verfahren zum Bereitstellen von RFID-Identifizierungsdaten für einen Authentisierungsserver |
| US8176328B2 (en) * | 2008-09-17 | 2012-05-08 | Alcatel Lucent | Authentication of access points in wireless local area networks |
| CN101378358B (zh) * | 2008-09-19 | 2010-12-15 | 成都市华为赛门铁克科技有限公司 | 一种实现安全接入控制的方法及系统、服务器 |
| DE102010044518A1 (de) * | 2010-09-07 | 2012-03-08 | Siemens Aktiengesellschaft | Verfahren zur Zertifikats-basierten Authentisierung |
| GB201116932D0 (en) * | 2011-10-01 | 2011-11-16 | Young Peter J | Device to detect unattended open door or draw |
| US9647835B2 (en) | 2011-12-16 | 2017-05-09 | Akamai Technologies, Inc. | Terminating SSL connections without locally-accessible private keys |
| US9380038B2 (en) * | 2012-03-09 | 2016-06-28 | T-Mobile Usa, Inc. | Bootstrap authentication framework |
| US20140006806A1 (en) * | 2012-06-23 | 2014-01-02 | Pomian & Corella, Llc | Effective data protection for mobile devices |
| RU2541901C2 (ru) * | 2012-08-29 | 2015-02-20 | Общество с ограниченной ответственностью "Гейзер-Телеком" | Способ гарантированной защиты передаваемой по радиоканалу информации от неправомерного доступа с помощью специального кодирования (преобразования) информации при открытом хранении параметров кодирования |
| US10069827B2 (en) * | 2012-10-31 | 2018-09-04 | International Business Machines Corporation | Extending authentication and authorization capabilities of an application without code changes |
| US9173095B2 (en) * | 2013-03-11 | 2015-10-27 | Intel Corporation | Techniques for authenticating a device for wireless docking |
| US10078754B1 (en) * | 2013-09-24 | 2018-09-18 | Amazon Technologies, Inc. | Volume cryptographic key management |
| CN104468124B (zh) * | 2014-12-22 | 2018-04-27 | 联想(北京)有限公司 | 基于ssl的认证方法及电子设备 |
| EP3160176B1 (fr) * | 2015-10-19 | 2019-12-11 | Vodafone GmbH | Usage d'un service d'un réseau central à commutation de paquets mobile sans avoir une carte sim |
| US10116630B2 (en) * | 2016-04-04 | 2018-10-30 | Bitdefender IPR Management Ltd. | Systems and methods for decrypting network traffic in a virtualized environment |
| CN106228070A (zh) * | 2016-06-29 | 2016-12-14 | 江海职业技术学院 | 一种计算机信息处理系统 |
| EA036373B1 (ru) * | 2017-02-07 | 2020-10-30 | Александр Иванович Силаев | Интерактивная игровая система, способ интерактивной игры с удалённым доступом |
| CN109743336B (zh) * | 2019-03-05 | 2021-10-01 | 上海扩博智能技术有限公司 | 无人机安全通信方法及系统 |
| CN110995414B (zh) * | 2019-12-23 | 2023-08-11 | 中金金融认证中心有限公司 | 基于国密算法在tls1_3协议中建立通道的方法 |
| US11838428B2 (en) * | 2021-12-20 | 2023-12-05 | Nokia Technologies Oy | Certificate-based local UE authentication |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1061484A3 (fr) * | 1999-06-11 | 2004-01-07 | Citicorp Development Center, Inc. | Méthode et système pour contrôler les transactions en paiement ouvert basées sur des certificats |
| DE19939281A1 (de) * | 1999-08-19 | 2001-02-22 | Ibm | Verfahren und Vorrichtung zur Zugangskontrolle zu Inhalten von Web-Seiten unter Verwendung eines mobilen Sicherheitsmoduls |
| DE10025626A1 (de) * | 2000-05-24 | 2001-11-29 | Deutsche Telekom Ag | Verschlüsseln von abzuspeichernden Daten in einem IV-System |
| WO2001090850A2 (fr) * | 2000-05-25 | 2001-11-29 | Diebold, Incorporated | Systeme et procede pour machine transactionnelle automatique |
| NO313480B1 (no) * | 2001-01-24 | 2002-10-07 | Telenor Asa | Fremgangsmåte for å åpne hele eller deler av et smartkort |
| US7500100B1 (en) * | 2003-09-10 | 2009-03-03 | Cisco Technology, Inc. | Method and apparatus for verifying revocation status of a digital certificate |
| CA2552987C (fr) * | 2004-03-26 | 2013-05-28 | Bce Inc. | Systeme et procede de securite |
| JP3761557B2 (ja) * | 2004-04-08 | 2006-03-29 | 株式会社日立製作所 | 暗号化通信のための鍵配付方法及びシステム |
| US7900039B2 (en) * | 2005-01-17 | 2011-03-01 | Lg Electronics, Inc. | TLS session management method in SUPL-based positioning system |
-
2006
- 2006-04-07 FR FR0603114A patent/FR2899749B1/fr not_active Expired - Fee Related
-
2007
- 2007-04-03 CA CA002648377A patent/CA2648377A1/fr not_active Abandoned
- 2007-04-03 CN CN200780019624A patent/CN101657992A/zh active Pending
- 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 EP EP07727739A patent/EP2012907A2/fr not_active Withdrawn
- 2007-04-03 WO PCT/EP2007/053268 patent/WO2007115982A2/fr active Application Filing
Non-Patent Citations (3)
| Title |
|---|
| AURA T, ELLISON C: "Privacy and Accountability in Certificate Systems", HELSINKI UNIVERSITY OF TECHNOLOGY, LABORATORY FOR THEORETICAL COMPUTER SCIENCE. RESEARCH REPORTS 61, April 2000 (2000-04-01), pages 1 - 18, XP002423043, ISSN: 0783-5396, ISBN: 951-22-5000-4, Retrieved from the Internet <URL:http://citeseer.ist.psu.edu/cs> [retrieved on 20070302] * |
| PERSIANO P, VISCONTI I: "A Secure and Private System for Subscription-Based Remote Services", ACM TRANSACTIONS ON INFORMATION AND SYSTEMS SECURITY, vol. 6, no. 4, November 2003 (2003-11-01), USA, pages 472 - 500, XP002423044, ISSN: 1094-9224 * |
| SAMFAT D ET AL: "UNTRACEABILITY IN MOBILE NETWORKS", MOBICOM. PROCEEDINGS OF THE ANNUAL INTERNATIONAL CONFERENCE ON MOBILE COMPUTING AND NETWORKING, 13 November 1995 (1995-11-13), pages 26 - 36, XP000197826 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113010880A (zh) * | 2021-02-08 | 2021-06-22 | 上海新时达电气股份有限公司 | 电梯配件认证方法、系统、服务器和存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20100005290A1 (en) | 2010-01-07 |
| EP2012907A2 (fr) | 2009-01-14 |
| WO2007115982A2 (fr) | 2007-10-18 |
| RU2451398C2 (ru) | 2012-05-20 |
| WO2007115982A3 (fr) | 2009-10-15 |
| CN101657992A (zh) | 2010-02-24 |
| FR2899749B1 (fr) | 2008-07-04 |
| CA2648377A1 (fr) | 2007-10-18 |
| RU2008142008A (ru) | 2010-05-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2899749A1 (fr) | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. | |
| EP1371207B1 (fr) | Dispositif portable pour securiser le trafic de paquets dans une plate-forme hote | |
| US20030163704A1 (en) | System, method and computer program product for guaranteeing electronic transactions | |
| FR2916592A1 (fr) | Procede de securisation d'echange d'information,dispositif, et produit programme d'ordinateur correspondant | |
| EP3375133B1 (fr) | Procede de securisation et d'authentification d'une telecommunication | |
| CN104735037B (zh) | 一种网络认证方法、装置及系统 | |
| CN113904767A (zh) | 一种基于ssl建立通信的系统 | |
| EP1514377A1 (fr) | Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne | |
| Badra et al. | Toward SSL integration in SIM smartcards | |
| FR2980063A1 (fr) | Procede d'authentification | |
| Urien et al. | Security and Privacy for the next Wireless Generation | |
| FR2946822A1 (fr) | Dispositif et procede d'acces securise a un service distant. | |
| Urien et al. | Tandem smart cards: enforcing trust for TLS-based network services | |
| Markovic | Data protection techniques, cryptographic protocols and pki systems in modern computer networks | |
| Urien | Personal HSM, Privacy for Subscribers in 5G/6G Networks | |
| Urien et al. | Introducing smartcard enabled radius server | |
| Urien et al. | Designing smartcards for emerging wireless networks | |
| FR2901084A1 (fr) | Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions | |
| Badra et al. | Adding identity protection to eap-tls smartcards | |
| EP2710779A1 (fr) | Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants | |
| EP2409474A1 (fr) | Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant | |
| Badra | Le transport et la sécurisation des échanges sur les réseaux sans fil | |
| FR2901438A1 (fr) | Un procede d'embarquement d'un protocole securise dans des cartes a puces, des capteurs et des objets intelligents | |
| Urien | TLS-Tandem: A collaborative technology for trusted WEB applications | |
| EP1858224A1 (fr) | Méthode de mise en place des réseaux privés virtuels et contrôle d'accès distant |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20151231 |