FR2901084A1 - Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions - Google Patents
Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions Download PDFInfo
- Publication number
- FR2901084A1 FR2901084A1 FR0604277A FR0604277A FR2901084A1 FR 2901084 A1 FR2901084 A1 FR 2901084A1 FR 0604277 A FR0604277 A FR 0604277A FR 0604277 A FR0604277 A FR 0604277A FR 2901084 A1 FR2901084 A1 FR 2901084A1
- Authority
- FR
- France
- Prior art keywords
- identity
- tls
- client
- server
- key
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
L'invention concerne un procédé d'intégration de CipherSuites au protocole TLS et à ses versions (DTLS, TLS-PSK, SSL, ...) afin d'établir des sessions sécurisées avec une authentification mutuelle entre un usager des réseaux et un serveur, tout en assurant la protection de l'identité de l'usager.
Description
-1- Une méthode de protection de l'identité avec TLS (Transport Layer
Security) ou avec une des ses versions
s La présente invention concerne un procédé de protection de l'identité de l'usager des réseaux utilisant TLS (Tansport Layer Security) ou une des ses versions (SSL (Secure Sockets Layer), DTLS (Datagram TLS), TLSPSK (Pre-Shared-Key), ...).
10 Dans le cadre de l'invention, le terme "client" doit être compris dans le sens le plus général. Il désigne un ordinateur ou un appareil informatique (PDA, portable, téléphone mobile, carte à puce, porte USB, MMC,...) géré par un système d'exploitation ou d'information. II est équipé d'une ou plusieurs interfaces de communication, par exemple Ethernet, sans fil, 15 mobile ou radio.
Le terme "serveur" 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 et comportant au moins une interface de communication. Enfin, et dans le cadre de l'invention, le terme "réseau" englobe les réseaux privés d'entreprises ou similaires, les réseaux Internet, les réseaux sans fil et mobiles, les réseaux locaux et les réseaux "extranets". 25 -2- Plusieurs technologies sont disponibles pour établir des sessions sécurisées entre un client et un serveur. Nous citons ici le protocole TLS (Transport Layer Security).
Basé sur SSL (Secure Sockets Layer) qui est développé par Netscape, le protocole TLS, défini par le RFC 2246 est le principal protocole de sécurité au niveau Transport (couche OSI numéro 4). Diverses applications telles que le commerce électronique sur Internet, les navigateurs WEB et les transactions bancaires supportent la sécurisation des transactions en utilisant le protocole TLS (ou une des ses versions).
TLS fournit un canal transparent. C'est-à-dire qu'il est simple de sécuriser le protocole d'application en insérant TLS entre la couche Application (couche OSI numéro 7) et celle du Réseau (couche OSI numéro 3). Cependant, TLS nécessite un protocole fiable de transport comme TCP.
TLS est adapté à la sécurisation de différents types de trafic et d'échange. Parmi ces types, nous citons le transfert de fichiers, la transmission des emails, l'accès à distance, l'accès aux répertoires, l'accès aux objets, etc. Cependant, une version TLS adaptée aux protocoles de transport non fiables comme UDP est disponible. Cette version est appelée DTLS (Datagram TLS) et elle est décrite par le RFC 4347.
Un autre contexte d'usage du protocole TLS est le contexte des réseaux sans fil et mobiles, tels que WiFi, la famille de 802 et le WiMax. Par exemple, la série de 802 définit le protocole EAP (Extensible Authentication Protocol) comme un protocole d'authentification générique qui supporte plusieurs mécanismes d'authentification. L'extensibilité du EAP permet d'encapsuler tout mécanisme d'authentification à l'intérieur du message EAP. L'intégration de TLS avec EAP, définie par le RFC 2716, est devenue une solution pour l'authentification et la distribution des clés dans les réseaux qui utilisent EAP dans leurs piles protocolaires. EAPTLS est utilisé plus particulièrement pour l'authentification et le contrôle de l'accès au niveau Liaison ou MAC (couche OSI numéro 2).
Les points forts de TLS lui permettent de s'intégrer facilement dans d'autres environnements de communication ; notamment les réseaux de communications mobiles 3GPP et 802.11 sans fil. TLS fournit un cadre extensible pour l'intégration de nouveaux services et des nouvelles méthodes de chiffrement et d'authentification en utilisant le RFC 3546.40 -3- TLS définit des mécanismes d'authentification basés sur l'échange de certificats. Durant la phase de la négociation TLS, le serveur envoie son certificat au terminal qui doit, à son tour, vérifier si ce certificat est valide et non révoqué. La consultation de la liste de révocation nécessite une connexion Internet. L'usage de ces certificats nécessite des infrastructures à clés publiques qui servent à établir une chaîne de certification ou de confiance entre les entités communicantes. Durant cette phase d'authentification, le client envoie son certificat afin d'être authentifié auprès du serveur. Un homme au milieu peut, par conséquent, lire l'identité lo du client. Cela est un inconvénient majeur surtout dans le cas de l'utilisation de TLS ou de SSL dans les réseaux mobiles et sans fil.
Pour chaque session TLS ou SSL, il y a un ensemble de paramètres à négocier entre le client et le serveur ; notamment le paramètre 15 cipher specs. Ce paramètre transporte les CipherSuites supportés par le client dans un ordre décroissant de préférence. Le serveur doit supporter au moins un parmi ces CipherSuites pour continuer la procédure de la négociation de TLS avec le client. Le CipherSuite est défini par les éléments suivants: l'algorithme d'échange de clé (RSA, DH, etc.), 20 l'algorithme de chiffrement (RC2, 3DES, AES, etc.) en mode stream ou block, et la fonction de hachage (MD5, SHA, etc.). Chaque CipherSuite est identifié par un numéro codé sur deux octets.
A titre d'exemple non limitatif, le CipherSuite 25 TLS_RSA_WITH_RC4_128_MD5 (identifié par { 0x00,0x04 }) signifie que le client et le serveur utilisent l'algorithme RSA comme un algorithme d'échange de clés, l'algorithme RC4 avec une taille de clé de 128 bits pour le chiffrement (en mode stream) et MD5 comme fonction d'hachage.
30 TLS et SSL définissent des CipherSuites (non anonymes) qui nécessitent l'utilisation de certificats mais ils définissent aussi de CipherSuites anonymes. Dans ce dernier cas, le client et le serveur n'utilisent pas de certificats. Cependant, les CipherSuites anonymes sont rarement utilisés car ils ne protégent pas contre les attaques de l'homme 35 au milieu et contre les attaques passives et actives.
Afin de protéger l'identité du client durant la phase de la négociation TLS ou SSL, nous définissons une nouvelle liste de CipherSuites permettant le chiffrement du certificat du client TLS ou SSL. La figure 1 illustre la phase de la négociation (Handshake) du TLS entre un client (121) et un serveur (131). Nous divisons cette phase en trois étapes. 40 2901084 -4-Dans une première étape (101, 102, 103, 104, 105, 106), le client et le serveur négocient les paramètres de sécurité (comme les valeurs aléatoires, l'algorithme d'échange de clés, l'algorithme de chiffrement, la fonction de hachage, etc.) afin d'établir une session sécurisée. 5 La deuxième étape (107, 108, 109) consiste à authentifier le client auprès du serveur et à générer les clés cryptographiques de la session en utilisant la fonction PRF (Pseudo Random Function). Ces clés seront utilisées dans les opérations cryptographiques afin de protéger les données durant leur transfert. Les opérations cryptographiques utilisent les algorithmes cryptographiques négociés durant la première étape.
Durant la troisième étape (110, 111, 112, 113), le client et le serveur vérifient l'intégrité de leurs échanges en calculant le condensât de tous les messages transmis et reçus et en chiffrant le résultat avec la clé de chiffrement calculée durant la deuxième étape. Durant cette troisième phase, le serveur sera implicitement authentifié auprès du client. En effet, le client génère durant la deuxième phase une valeur aléatoire de 46 octets appelée "premaster secret" (108) et il la concatène avec la version négociée de TLS. Ensuite il chiffre le résultat avec la clé publique du serveur envoyée dans le message "Certificate" (103). La valeur chiffrée est envoyée au serveur qui la déchiffre en utilisant sa clé privée pour obtenir le "premaster secret". Ce secret est utilisé à la fois par le client et le serveur pour générer le même secret "master secret". Le "master secret" est utilisé dans la génération des clés symétriques utilisées dans le chiffrement et dans le calcul du MAC (Message Authentication Code). Les premiers messages chiffrés et signés avec les clés générées sont les messages "Finished" (111, 113). Par conséquent, il est impossible pour une entité n'ayant pas la clé privée correspondante à la clé publique envoyée par le serveur durant la deuxième étape, de découvrir le "premaster secret" en clair et de générer les mêmes clés.
En référence à la figure 2, le client peut demander la protection de son identité en envoyant une liste de CipherSuites spécifique à cette 35 protection.
Le client envoie cette liste de ces CipherSuites en conformité avec le protocole TLS, tel que décrit par les RFC 2246, 3546 et 4279. Cette liste est transportée par le message "ClientHello". Elle est définie de la manière 40 suivante :
Selon l'invention, pour chaque CipherSuite non anonyme utilisé par TLS, nous réassocions un nouveau identifiant (sur deux octets) pour ce CipherSuite afin de permettre au client d'indiquer au serveur qu'il souhaite 45 établir une session TLS avec une protection de l'identité du client.
A titre d'exemple non limitatif, le CipherSuite TLS RSA WITH RC4 128 MD5 est identifié par { 0x00,0x04 } par IANA (Internet Assigned Numbers Authority). Afin de protéger l'identité du client en utilisant ce même CipherSuite, nous réassocions un identifiant différent que celui normalisé ou choisi par IANA. A titre d'illustration, ce CipherSuite sera TLS IP RSA WITH RC4 128 MD5 (IP est l'abréviation de Identity Protection) identifié avec un identificateur différent de { 0x00,0x04 } (par exemple { OXAO,0x04 }) et non attribué par IANA.
Les clés de session sont générées en utilisant la fonction PRF. La taille de ces clés dépend du CipherSuite choisi.
Le client et le serveur continuent cette première phase de la manière 15 définie dans la figure 1.
La deuxième étape (207, 208, 209) consiste à authentifier le client auprès du serveur et à générer les clés cryptographiques de la session en utilisant la fonction PRF (Pseudo Random Function). Ces clés seront 20 utilisées dans les opérations cryptographiques afin de protéger les données durant leur transfert. Les opérations cryptographiques utilisent les algorithmes cryptographiques négociés durant la première étape.
Durant cette deuxième phase et avant d'envoyer son certificat (207), 25 le client a tous les paramètres de sécurité qui seront utilisés ensuite pour chiffrer (symétriquement) et signer (HMAC) les données échangées entre le client et le serveur. Parmi ces paramètres, nous citons le Ciphersuite, le "premaster secret", le "ClientHello.random" et le "ServerHello.random".
30 Si le serveur a accepté l'usage d'un CipherSuite avec une protection d'identité du client, le client chiffre alors son certificat avec une clé dérivée du "premaster secret" en utilisant l'algorithme de chiffrement symétrique négocié par le paramètre cipher spec.
35 A titre d'exemple non limitatif, si le CipherSuite TLS IP RSA WITH RC4 128 MD5 a été choisi par le serveur, le client et le serveur utiliseront RC4 avec une clé de 128 bits comme algorithme de chiffrement symétrique. Le client chiffre alors son certificat (207) avec RC4 en utilisant les 128 derniers bits de poids faible du "premaster secret". Les 40 128 bits de poids faible du "premaster secret" sont les 128 bits le plus à gauche. Par exemple, les 4 bits de poids faible de la valeur 0101001111 sont 1111.
Le serveur reçoit les messages "Certificate" (207) (chiffré avec une 45 clé dérivée du "premaster secret"), "ClientKeyExchange" (208), -6-"CertificateVerify' (209), "ChangeCipherSpec" (210) et "Finished" (211). Ensuite, il déchiffre le message "ClientKeyExchange" (208) en utilisant sa clé privée pour récupérer la valeur de "premaster secret'. II utilise l'algorithme symétrique négocié et une clé de déchiffrement symétrique calculée de la même manière que le client pour déchiffrer le message "Certificate" (207).
Le "premaster secret", "ClientHello.random" et le "Serve rHello.randorn" sont ensuite utilisés à la fois par le client et le lo serveur pour générer le même secret "master secret".
La troisième étape (210, 211, 212, 213) est répété par le client et le serveur de la même manière que celle décrit auparavant.
15 Nous nous référons à présent à la figure 3.
Le RFC 4279 (Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)) définit une liste de CipherSuites avec une authentification basée sur l'usage des clés partagées (PSK, Pre-Shared Key) à la place de 20 certificats. Chaque clé partagée est identifiée par un identifiant (PSK identity). Durant l'établissement de la session TLS, le client envoi l'identité du PSK au serveur. Ensuite, le client et le serveur utilisent le PSK pour générer les clés de la session.
25 Parmi les CipherSuites définis, nous avons une liste spécifiée à l'usage du PSK avec l'algorithme RSA. A titre d'exemple non limitatif, le CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA (identifié par { 0x00, 0x92 }) est un CipherSuite qui utilise l'algorithme RSA pour l'échange de clés et le PSK pour l'authentification mutuelle. 30 Cependant, durant la session TLS basée sur l'usage de PSK, le client envoi l'identité du PSK en clair. Dans le cadre de cette invention, nous réassocions un nouveau identifiant (sur deux octets) pour chaque CipherSuite basée sur le PSK et sur l'usage de l'algorithme RSA et cela 35 afin de permettre au client d'indiquer au serveur qu'il souhaite établir une session TLS basée sur PSK (TLS-PSK) avec une protection de l'identité de PSK.
A titre d'exemple non limitatif, le CipherSuite 40 TLS RSA PSK WITH RC4 128 SHA est identifié par { 0x00, 0x92 }. Afin de protéger l'identité du PSK en utilisant ce même CipherSuite, nous réassocions à ce CipherSuite un identifiant différent que celui normalisé ou choisi par IANA. A titre d'illustration, ce même CipherSuite sera identifié avec un identificateur différent de { 0x00, 0x92 } (par exemple { OXAO,Ox92 45 }) et non attribué par IANA.
Si un CipherSuite basée sur l'usage du PSK avec une protection de l'identifiant du PSK sera utilisé, le client concatène l'identifiant du PSK avec le "premaster secret' avant de chiffrer le résultat avec la clé publique du serveur (340). Le résultat chiffré sera envoyé en utilisant le message "ClientKeyExchange" (336). A la réception, le serveur utilise sa clé privée pour déchiffrer les données chiffrées et utilise l'identifiant du PSK pour trouver le PSK correspondant. Ensuite, le client et le serveur utilise le même mécanisme décrit par le RFC 4279 pour générer les clés de la lo session. -8- Nous allons à présent décrire un moyen de mise en oeuvre du procédé d'authentification du client TLS avec une protection de son identité.
Nous nous référons à présent à la figure 4.
Nous considérons un client (301, 302, 303) et un serveur RADIUS (306) qui implémentent le protocole EAP-TLS et nous supposons que l'authentification du client est obligatoire pour accéder au serveur. EAPTLS est utilisé pour l'authentification et le contrôle de l'accès au niveau Liaison ou MAC (couche OSI numéro 2) et il est basé sur TLS. En effet, c'est une encapsulation des messages TLS dans le protocole EAP.
Avec EAP-TLS, l'usage de certificats est obligatoire sur le client et le 15 serveur.
Le serveur et le client utilisent la phase "Handshake" de TLS afin de s'authentifier en utilisant des certificats de type X.509 et un CipherSuite qui permet le chiffrement du certificat du client. Durant leur transport, les 20 messages TLS seront fragmentés et encapsulés dans des paquets EAPTLS. Le NAS (304) (Network Access Servers) est responsable du transfert des informations envoyées par le client vers le serveur RADIUS et vice versa.
25 Nous nous référons à présent à la figure 5.
Les messages TLS sont encapsulés dans des paires de messages EAP-Request et EAP-Response (405, 406, 407, 408, 409) entre le client (300a) et le NAS (300b) et sont transmis par des paquets RADIUS Access- 30 Challenge et Access-Request (505, 506, 507, 508, 509) entre le NAS et le serveur (300b).
- Après la phase d'association (401) avec le NAS, ce dernier envoie au client une requête d'identité EAP-Request/Identity (403). - Le client produit en retour une réponse EAP-Response/Identity (403). Cette réponse comporte l'identité du client et les méthodes d'authentification supportées.
40 - A ce moment, le point d'accès transmet au serveur le message EAP-Response/Identity (504) encapsulé dans une requête RADIUS nommée Access-Request. Durant l'échange des messages EAP (requêtes et réponses) entre le serveur et le client, le NAS agit comme un simple relais passif. Les réponses du serveur sont encapsulés dans des paquets 45 RADIUS de type Access-Challenge (505, 507, 509). 35 - Le serveur prend la décision d'accepter ou de refuser l'accès au réseau et il indique le succès ou l'échec de la procédure d'authentification via le message EAP-Success (411) ou EAP-Failure. Ces messages sont encapsulés respectivement dans les messages RADIUS Access-Accept (511) et Access-Reject.
Claims (3)
1) Procédé de protection de l'identité de client dans le cadre d'une liaison client/serveur établie par le protocole TLS ou par une de ses versions, notamment DTLS, EAP-TLS, TLS-PSK, SSL, spécifiant un ou plusieurs CipherSuites, caractérisé en ce que : - la protection de l'identité est assurée par le chiffrement du certificat avec l'algorithme symétrique négocié par le paramètre cipher_specs et ; - la clé de chiffrement est dérivée des bits de poids faibles d'une clé lo générée à partir du " premaster secret " et de deux valeurs aléatoires et sa taille est déterminée selon l'algorithme de chiffrement symétrique choisi ;
2) Dispositif serveur pour la mise en oeuvre du procédé selon la revendication 1 caractérisé en ce qu'il implémente le protocole TLS ou 15 l'une de ses versions et qu'il est muni d'au moins une interface de communication.
3) Dispositif client pour la mise en oeuvre du procédé selon la revendication 1 caractérisé en ce qu'il implémente le protocole TLS ou 20 l'une de ses versions et qu'il est muni d'au moins une interface de communication.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0604277A FR2901084B1 (fr) | 2006-05-15 | 2006-05-15 | Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0604277A FR2901084B1 (fr) | 2006-05-15 | 2006-05-15 | Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2901084A1 true FR2901084A1 (fr) | 2007-11-16 |
| FR2901084B1 FR2901084B1 (fr) | 2013-06-21 |
Family
ID=37726524
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0604277A Expired - Fee Related FR2901084B1 (fr) | 2006-05-15 | 2006-05-15 | Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2901084B1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012022992A2 (fr) * | 2010-08-16 | 2012-02-23 | Kovacs Zoltan | Système de chiffrement pour la protection d'appels téléphoniques |
| US20200366718A1 (en) * | 2018-07-12 | 2020-11-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Security information exchange between a client and a server |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6189098B1 (en) * | 1996-05-15 | 2001-02-13 | Rsa Security Inc. | Client/server protocol for proving authenticity |
| WO2005109745A1 (fr) * | 2004-04-16 | 2005-11-17 | Audiosmartcard International Sa | Procede de securisation d’operations sur un reseau et dispositifs associes |
-
2006
- 2006-05-15 FR FR0604277A patent/FR2901084B1/fr not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6189098B1 (en) * | 1996-05-15 | 2001-02-13 | Rsa Security Inc. | Client/server protocol for proving authenticity |
| WO2005109745A1 (fr) * | 2004-04-16 | 2005-11-17 | Audiosmartcard International Sa | Procede de securisation d’operations sur un reseau et dispositifs associes |
Non-Patent Citations (2)
| Title |
|---|
| BELLER M J ET AL: "Security for personal communications services: public-key vs. private key approaches", PERSONAL, INDOOR AND MOBILE RADIO COMMUNICATIONS, 1992. PROCEEDINGS, PIMRC '92., THIRD IEEE INTERNATIONAL SYMPOSIUM ON BOSTON, MA, USA 19-21 OCT. 1992, NEW YORK, NY, USA,IEEE, US, 19 October 1992 (1992-10-19), pages 26 - 31, XP010107132, ISBN: 0-7803-0841-7 * |
| MENEZES A ET AL: "Handbook of applied cryptograpy", HANDBOOK OF APPLIED CRYPTOGRAPHY, CRC PRESS SERIES ON DISCRETE MATHEMATICES AND ITS APPLICATIONS, BOCA RATON, FL, CRC PRESS, US, 1997, pages 37 - 39,428, XP002204463, ISBN: 0-8493-8523-7 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012022992A2 (fr) * | 2010-08-16 | 2012-02-23 | Kovacs Zoltan | Système de chiffrement pour la protection d'appels téléphoniques |
| WO2012022992A3 (fr) * | 2010-08-16 | 2012-04-05 | Kovacs Zoltan | Système de chiffrement pour la protection d'appels téléphoniques |
| US20200366718A1 (en) * | 2018-07-12 | 2020-11-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Security information exchange between a client and a server |
| US11916970B2 (en) * | 2018-07-12 | 2024-02-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Security information exchange between a client and a server |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2901084B1 (fr) | 2013-06-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11477037B2 (en) | Providing forward secrecy in a terminating SSL/TLS connection proxy using ephemeral Diffie-Hellman key exchange | |
| JP4707992B2 (ja) | 暗号化通信システム | |
| EP2561663B1 (fr) | Serveur et procédé permettant d'offrir un accès sècurisé à des service | |
| US20040236965A1 (en) | System for cryptographical authentication | |
| FR2899749A1 (fr) | Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants. | |
| CN111756529B (zh) | 一种量子会话密钥分发方法及系统 | |
| CN111935213B (zh) | 一种基于分布式的可信认证虚拟组网系统及方法 | |
| EP3375133B1 (fr) | Procede de securisation et d'authentification d'une telecommunication | |
| CN111756528B (zh) | 一种量子会话密钥分发方法、装置及通信架构 | |
| KR100948604B1 (ko) | 서버 기반 이동 인터넷 프로토콜 시스템에 있어서 보안방법 | |
| Rongyu et al. | A PK-SIM card based end-to-end security framework for SMS | |
| CN104735037B (zh) | 一种网络认证方法、装置及系统 | |
| WO2009018510A1 (fr) | Systèmes et procédés visant à mettre en oeuvre des protocoles internet de sécurité en mutation | |
| EP3216163B1 (fr) | Confidentialité de transmission dans un mandataire de connexion ssl/tls de terminaison utilisant un échange de clés diffie-hellman éphémère | |
| US20240106811A1 (en) | Systems and methods for network privacy | |
| Kampanakis et al. | Do we need to change some things? Open questions posed by the upcoming post-quantum migration to existing standards and deployments | |
| FR2901084A1 (fr) | Une methode de protection de l'identite avec tls (transport layer security) ou avec une de ses versions | |
| Urien et al. | Tandem smart cards: enforcing trust for TLS-based network services | |
| CN114245332A (zh) | 一种物联网设备的dtls连接建立方法及系统 | |
| Gaur | VPN: Problem relates with security of data in tunneling process and requirements | |
| EP3200420B1 (fr) | Providing communications security to an end-to-end communication connection | |
| Badra et al. | Adding identity protection to eap-tls smartcards | |
| Du et al. | A CSK based SSL handshake protocol | |
| Badra et al. | A lightweight identity authentication protocol for wireless networks | |
| FR2901438A1 (fr) | Un procede d'embarquement d'un protocole securise dans des cartes a puces, des capteurs et des objets intelligents |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20160129 |