La banque en ligne et le protocole TLS : exemple

Richard MONTBEYRE
Master 2 Professionnel Droit de l’Internet – Administration – Entreprises
La banque en ligne et le protocole TLS : exemple
1
Introduction
Définition du protocole TLS
Transport Layer Security (TLS), peut se traduire littéralement par « sécurisation de la
couche transport ». Il s’agit d’un protocole de sécurisation des échanges de données sur
Internet reposant sur un procédé de cryptographie par clef publique. Son principe consiste à
établir un canal de communication sécurisé chiffré entre deux machines (client et serveur)
après une étape d'authentification
Le cryptage est réalisé à la fois par un chiffrement asymétrique1, qui permet l’authentification,
et par un chiffrement symétrique2, plus léger, qui assure la transmission des données. Le
cryptage asymétrique est en effet assez exigeant en terme de puissance de calcul, et donc
assez lent en comparaison au cryptage symétrique. Les algorithmes à clé publique sont
environ 1000 fois plus lents que les algorithmes à clé secrète, ce qui rend leur usage trop lourd
pour assurer la confidentialité d’échanges volumineux. En pratique, l’utilisation des deux
technologies est combinée : la cryptographie à clé publique sert à échanger une clé secrète,
valable la durée de la session.
En outre, pour garantir que les données transmises ne sont pas corrompues, on emploie
généralement une fonction de hachage.
Définition de la banque en ligne
La banque en ligne désigne l'ensemble des services bancaires assurés par voie
électronique.
« Les services de banque en ligne se sont considérablement développés. Ils permettent
désormais aux particuliers de consulter leurs comptes bancaires, effectuer des virements,
commander des chéquiers, simuler des propositions de crédit, etc.
Cette nouvelle manière d’envisager la relation bancaire n’est pas sans susciter de
nouvelles interrogations de la part des internautes sur la protection de leurs données
personnelles (sécurité des échanges d’information, collecte de nouvelles données, modalités
d’information des personnes, prospection par voie électronique, etc.). »3
Les origines du protocole TLS : de Netscape à l’IETF
1
Au moyen, par exemple, de l’algorithme de chiffrement RSA. Le RSA est un algorithme asymétrique de
cryptographie à clé publique, présenté en 1977 par Ron Rivest, Adi Shamir et Len Adleman, d'où le sigle RSA.
2
Le DES (Data Encryption Standard) par exemple. Le DES est une méthode de chiffrement utilisant des clés de
56 bits.
3
« Opération Audit de la banque en ligne », étude réalisée par la CNIL au 1er semestre 2005, p.2.
2
Le protocole TLS succède au système Secure Sockets Layer4 (SSL), développé à l'origine
par la société Netscape Communications Corporation en collaboration avec Mastercard et
Bank of America, pour le navigateur Netscape Communicator. La dernière version de SSL,
qui demeure utilisée, est SSL v3.0.
Le SSL, dont le brevet a été racheté à Netscape par l’IETF5, a évolué vers un nouveau
protocole : Transport Layer Security (TLS). Un groupe de travail issu de l'IETF a permis la
normalisation du protocole TLS version 1.0 dès 1999, au moyen de la RFC6 2246.
D’un protocole propriétaire, le SSL a ainsi évolué vers une norme officielle sous la forme
du TLS. Dans une certaine mesure, TLS constitue également une nouvelle version de SSL, et
les dernières évolutions apportées aux protocoles de sécurisation se font désormais sur le
TLS. Ainsi, le cryptage AES7 peut être utilisé comme algorithme symétrique après la
négociation TLS.
Il y a assez peu de différence entre la dernière version de SSL (v3.0) et la version 1.0 de
TLS, mais ces deux protocoles demeurent incompatibles. Heureusement, la plupart des
serveurs et des navigateurs web permettent d’utiliser l’un ou l’autre des deux protocoles. En
effet, les mises en oeuvre de TLS acceptent de basculer vers SSL v3.0 quand le partenaire ne
supporte pas TLS, au moyen d’un mécanisme alternatif de compatibilité.
Au titre des différences entre les deux protocoles, il convient de noter celle affectant la
génération des clés symétriques. TLS est plus sécurisé que SSL en la matière, dans la mesure
où aucune étape de son algorithme ne repose uniquement sur MD58. Il a en effet été reproché
à ce dernier de présenter quelques faiblesses en cryptanalyse.
Il convient de noter que, par un abus de langage, SSL et TLS sont souvent assimilés pour
être communément désignés sous le vocable global « SSL ». Dans cet étude, nous les
distinguerons néanmoins les deux protocoles, l’un tendant à remplacer l’autre.
4
Secure Sockets Layers se traduit littéralement par « couches de sockets sécurisée ».
L’IETF, Internet Engineering Task Force, est un groupe international informel ouvert à tout individu, qui
participe à l'élaboration de standards pour Internet. L'IETF produit la plupart des nouveaux standards d'Internet.
6
Request For Comment : ensemble de documents de référence rédigés et proposés par des experts techniques,
décrivant les différents standards et normes en usage sur Internet.
7
L’AES (Advanced Encryption Standard), est un algorithme de chiffrement symétrique, également appelé
Rijndael, du nom de ses deux concepteurs Joan Daemen et Vincent Rijmen. Ses clés peuvent atteindre 256 bits.
8
L'algorithme MD5, pour « Message Digest 5 », est une fonction de hachage cryptographique très populaire, qui
permet d'obtenir pour chaque message une empreinte numérique (séquence de 128 bits ou 32 caractères en
notation hexadécimale) avec une probabilité très forte que, pour deux messages différents, leurs empreintes
soient différentes.
5
3
Quant aux textes de référence du protocole TLS, il convient de citer le premier d’entre
eux est la RFC 2246, issu d’un groupe de travail de l’IETF et publié en 1999. Cette RFC est le
texte de naissance du protocole. Par la suite, ont notamment été élaborées la RFC 2818
(relative au HTTP sur TLS) et la RFC 3268 (relative à l’utilisation du système de chiffrement
AES pour TLS).
Les objectifs du protocole TLS : la sécurisation des échanges de données sur
Internet
Avec le développement d'Internet, de nombreuses sociétés commerciales proposent des
achats en ligne pour les particuliers. Une des meilleures manières de sécuriser les paiements
par cartes bancaires est d'utiliser des protocoles d'authentification et de chiffrement tels que
TLS. La session chiffrée est ainsi généralement utilisée, notamment lors de l'envoi du numéro
de carte bancaire.
TLS fonctionne entre un client et un serveur. I est destiné à remplir quatre objectifs de
sécurité :
-
l'authentification du serveur
-
la confidentialité des données échangées
-
l'intégrité de ces données
-
de manière optionnelle et depuis la version 3.0 de SSL, l'authentification du client au
moyen de certificats.
Le fonctionnement du protocole TLS : une certaine souplesse, à partir d’un
modèle rigide
Le SSL comme le TLS ont pour but de permettre l’établissement d’un « tunnel » sécurisé
entre l’utilisateur et le serveur Web afin de sécuriser leurs échanges. Dans une première
phase, un cryptage asymétrique permet à l’utilisateur et au serveur de s’échanger une clé de
cryptage symétrique. Par la suite, tous leurs échanges sont cryptés avec cette clé symétrique :
le tunnel sécurisé est en place.
A partir de ce mécanisme qui peut paraître assez rigide et rudimentaire, le protocole TLS
permet néanmoins la mise en œuvre de procédés plus élaborés :
-
Si l’utilisateur en dispose, il peut envoyer son certificat de sécurité au site lors de la
négociation.
4
-
Le protocole SSL peut être utilisé pour sécuriser n’importe quel protocole reposant sur
TCP, tels FTP9 (FTPS), SMTP10 (SMTPS), POP311 (POP3S)... Le protocole SSL est en
effet indépendant du protocole transport utilisé, ce qui signifie qu'il peut aussi bien
sécuriser des transactions faites sur le Web par le protocole HTTP que des connexions via
d’autres protocoles. En effet, TLS agit comme une couche supplémentaire, située entre la
couche application et la couche transport, et permet d'assurer la sécurité des données.
-
Lors de la négociation, tout type d’algorithme de cryptage symétrique peut en principe
être négocié entre l’utilisateur et le serveur.
-
Un algorithme de compression peut être utilisé pour réduire la taille des données passant
par le tunnel.
La sécurisation des transactions par TLS est basée sur un échange de clés entre client et
serveur. Le protocole TLS est en effet constitué de deux sous-protocoles : le protocole TLS
Handshake et le protocole TLS Record.
Le protocole TLS Handshake permet d'authentifier les deux parties, de leur permettre de
négocier les algorithmes et les clés de session, tandis que le protocole TLS Record a pour but
de chiffrer les connexions avec un algorithme symétrique et de vérifier leur intégrité.
L’échange se réalise en plusieurs étapes, quasi instantanées pour l’utilisateur :
-
Le client se connecte au site sécurisé par TLS et lui demande de s'authentifier au moyen
d’un certificat. Il envoie également la liste des systèmes de cryptage qu'il supporte, triée
par ordre décroissant selon la longueur des clés.
-
Le serveur hébergeant le site reçoit la requête du client, auquel il envoie un certificat
contenant la clé publique du serveur du site – signée par une autorité de certification (cf
infra). Il renvoie également la référence du système de cryptage avec lequel le client est
compatible, en choisissant le système commun ayant la plus grande longueur de clé.
-
Le client vérifie ensuite la validité du certificat, puis crée de manière aléatoire une clé
secrète. Il chiffre cette clé secrète à l'aide de la clé publique du serveur, puis envoie à ce
dernier la clé résultant de cette manipulation : la « clé de session ».
9
Le FTP (File Transfer Protocol) est un protocole de communication dédié à l'échange de fichiers sur un réseau
TCP/IP. Il permet notamment, depuis un ordinateur, de copier des fichiers depuis ou vers un autre ordinateur du
réseau.
10
Le SMTP (Simple Mail Transfer Protocol) est un protocole de communication utilisé pour transférer le
courrier électronique vers les serveurs de messagerie électronique.
11
Le POP3 (Post Office Protocol Version 3) est un protocole permettant de récupérer les courriers électroniques
situés sur un serveur de messagerie électronique.
5
-
Le serveur est en mesure de déchiffrer la clé de session avec sa clé privée. Ainsi, client et
serveur sont en possession d'une clé commune qu’ils sont seuls à connaître. Les
transactions peuvent dès lors être réalisées, au moyen de la clé de session, ce qui garantit
en principe l'intégrité et la confidentialité des données échangées. Cette première phase
s’appelle le handshake, ou « poignée de main ». Elle permet d’échanger de façon
confidentielle la clé qui permettra de crypter les échanges de données, au cours de la
seconde phase.
-
Dans la seconde phase, les données sont échangées entre le client et le serveur, au moyen
du sous protocole Record.
L’utilisation du protocole TLS par les banques en ligne : l’exemple de la BNP
Paribas
Du côté du client
La plupart des navigateurs affichent un cadenas fermé en bas de la fenêtre du programme,
lors de la connexion à un site sécurisé par TLS (Mozilla Firefox, Microsoft Internet
Explorer...). En outre, les serveurs web sécurisés par SSL ou TLS sont identifiés par une
URL commençant par HTTPS, « s » signifiant secured (sécurisé).
Internet Explorer
Mozilla
Il convient de noter que SSL est « transparent » pour l'utilisateur, qui n’a aucune
manipulation à effectuer pour l’utiliser et peut aller jusqu’à ignorer qu’il l’utilise. Les données
sont envoyées chiffrées, sans intervention de l’utilisateur.
Du côté de la banque
L’implémentation de SSL ou de TLS au sein des navigateurs Internet et des serveurs web
actuels du marché fait de HTTPS le protocole de sécurisation standard des transactions
bancaires. Le protocole est en effet présent dans le code des navigateurs Internet Explorer et
Netscape Communicator, et dans les principaux serveurs HTTP (Iplanet, Microsoft IIS, Lotus
et Apache).
6
Les banques désireuses de réaliser des opérations en ligne achètent le plus souvent un
certificat pour leurs serveurs, afin que l’ensemble des internautes puissent authentifier ce
dernier de manière sûre et participer à des échanges chiffrés. Les banques emploient
essentiellement les certificats proposés par la société Verisign.
L’exemple de la BNP
L'adresse
de
l'espace
sécurisé
de
bnpparibas.net
est
https://www.secure.bnpparibas.net/. Le site repose sur le protocole SSL 128 bits, lequel
correspond au niveau de chiffrement le plus élevé permis par les autorités françaises12.
Le client doit tout d’abord, d’après les recommandations de la banque, s’assurer
qu’il est bien connecté à l’espace sécurisé de bnpparibas.net.
Il doit notamment s’assurer qu’il a bien saisi l’adresse exacte de bnpparibas.net dans la
barre d’adresse de son navigateur Internet (ou à partir de ses favoris, si l’adresse a été
enregistrée au préalable une fois le certificat de sécurité vérifié).
Au contraire, le client ne doit jamais accéder à bnpparibas.net depuis un lien envoyé dans un
e-mail ou figurant sur un site Internet non identifié. Il existe en effet un risque important de
phishing.
Afin de pouvoir récupérer les données de leurs victimes et de les utiliser, les fraudeurs
envoient en effet des emails, en se faisant passer pour la banque de ces victimes et en les
incitant à consulter un site indûment présenté comme le véritable site de cette banque. Cette
usurpation d'identité ou « spoofing » s’accompagne en effet souvent d'une fraude, but de la
manœuvre frauduleuse, et qui vise à récupérer certaines informations confidentielles telles
que les codes secrets de connexion. Cette fraude est communément désignée sous le nom de
« phishing », déformation de fishing (« pêche »).
Pour prévenir de telles atteintes, les banques recommandent à leurs clients de vérifier
systématiquement l’identité de l’émetteur de l’email. Toutefois, il convient de remarquer que
l’identité de l’émetteur peut aisément être maquillée pour ressembler, à s’y méprendre, à
l’identité véritable de la banque.
En tout état de cause, les clients sont invités à ne pas suivre les liens insérés dans les
emails, et à ne se connecter aux sites bancaires qu’en tapant l’url exacte du site dans la barre
12
La fourniture et l’usage des algorithmes de chiffrement sont en effet réglementés : les textes de lois en vigueur
sont les décrets 99-199, 99-200 et l’arrêté du 17 mars 1999. Ils limitent la taille des clés suivant le type d’usage.
En France, c’est la DCSSI (Direction Centrale de la Sécurité des Systèmes d’Information) qui attribue les
autorisations d’utilisation de produits de chiffrement.
7
d’adresse du navigateur Internet. La vérification du certificat de sécurité permet également de
s’assurer, en principe, de la fiabilité du site, dans les conditions suivantes.
Le client doit ensuite vérifier le certificat de sécurité
Les propriétés du site doivent notamment faire figurer l’indication du protocole utilisé par
le site : SSL 3.0 ou TLS 1.0, avec cryptage en 128 bits. Le site fonctionne avec les
navigateurs dotés de la version 2.0 du protocole SSL ou d'un cryptage de 40 bits seulement,
mais la banque recommande à ses clients de mettre à jour leurs navigateurs Internet.
Ensuite, le certificat de sécurité (rubrique « certificats ») doit mentionner les informations
suivantes :
- Délivré à : www.secure.bnpparibas.net
- Délivré par : Secure Server Certification Authority
8
Le "chemin d'accès de certification" doit mentionner :
-
VeriSign/RSA Secure Server CA
-
www.secure.bnpparibas.net
-
Etat du certificat : ce certificat est valide.
9
Le rapport de la CNIL : « Opération audit de la banque en ligne »13
La Commission Nationale de l’Informatique et des Libertés a audité au cours du premier
semestre 2005 les dix principaux sites web de banques françaises, pour vérifier le respect de
la loi Informatique et Libertés. Au-delà de ce contrôle de la conformité des pratiques à la loi
de 1978, la CNIL a également voulu vérifier le degré de protection des données personnelles
et bancaires des internautes clients de banques en ligne.
Si sept banques offraient, à la date de l’étude, un niveau suffisant de sécurité et de
protection des données personnelles, la CNIL conseillait toutefois aux internautes de ne pas
négliger quelques précautions d'usage. Sans citer aucun nom d’établissement financier, elle
estimait que « sept respectent globalement la confidentialité et la sécurité des données, même
si des améliorations restent à prévoir » (p.3 de l’audit). Elle ne citait toutefois aucun nom
d'établissement financier.
L'étude a montré que les internautes disposaient d'un bon niveau d'information, passant
notamment par les recommandations des banques, l’aide en ligne et l’affichage par les
navigateurs Internet du passage en mode sécurisé.
La CNIL considérait que la sécurité de la connexion est « globalement satisfaisante »
(p.3). Les protocoles SSL et TLS étaient d’ores et déjà largement utilisés. Toutefois, sur
les dix services audités, quatre n'utilisaient pas de protocole de sécurisation des échanges dès
l'envoi des identifiant et mot de passe durant l'authentification de l'internaute, « la bascule en
mode sécurisé ne se faisant qu'après l'envoi de ces informations en clair sur le Net » (p.4).
Conclusion : les faiblesses de la sécurisation des échanges de données bancaires
sur Internet
Une difficulté persistante malgré le cryptage asymétrique : les attaques de type Man in
the Middle
Le cryptage asymétrique reste vulnérable aux attaques de type Man in the Middle (ou
MiM). Elle consiste, pour un tiers à l’échange, à s’insérer entre l’émetteur et le récepteur pour
intercepter les données échangées. Lorsque l’émetteur demande sa clé publique au récepteur,
le tiers renvoie alors sa propre clé publique. L’émetteur crypte donc son message avec la clé
du tiers malveillant et envoie le résultat. Il suffit ensuite au pirate de décrypter le message
grâce à sa propre clé privée. Au-delà de cette interception, le tiers peut même crypter le
13
Pour la référence de l’audit, cf supra, note 3.
10
message avec la clé publique du récepteur, et le lui envoyer, éventuellement après l’avoir
modifié. De cette façon, l’interception reste indécelable pour l’émetteur comme pour le
récepteur.
Pour éviter de telles attaques, l’émetteur doit s’assurer que la clé publique qui lui a été
fournie est bien celle du récepteur. Cette garantie peut passer par un échange de clé en main
propre, par une vérification par téléphone ou par écrit. En réalité, l’authentification passe le
plus souvent par un tiers de certification, ainsi que nous l’avons vu dans l’exemple de la BNP
Paribas. Il convient toutefois de remarquer que les intercepteurs n’hésitent pas à fournir au
client un faux certificat, ressemblant au véritable certificat du serveur.
En 2001, Serge Vaudenay14 lance une attaque contre le protocole SSL, en utilisant les
temps de réponse des serveurs, ce qui lui permet de découvrir les dernières données envoyées
et de les récupérer. L'attaque n'est toutefois valable que sous certaines conditions. Elle a
néanmoins pu être utilisée avec succès contre certains webmails, qui envoient plusieurs fois
les mêmes données.
14
Serge Vaudenay est un cryptologue français, ancien élève de l’ENS.
11