par Mel Beckman
Sécurisez vos transactions électroniques en suivant de près l'évolution des protocoles
de sécurité du commerce électronique
Lorsque le protocole SSL (Secure Sockets Layer) est arrivé sur le marché il y
a 6 ans, les experts y ont vu la solution au problème de sécurité du commerce
électronique. Et il est vrai que SSL a beaucoup contribué à rassurer les internautes
utilisant leurs numéros de cartes de crédit pour les achats en ligne, faisant
ainsi exploser les ventes grand public sur le Web. SSL remplit bien sa fonction
de cryptage des données circulant entre l'acheteur et le vendeur, pour déjouer
l'interception par les voleurs des informations contenues sur les cartes de crédit.
Si la sécurité du commerce électronique se limitait à cela, SSL aurait donc résolu
la totalité des problèmes. Mais si la protection des numéros de cartes de crédit
et d'autres informations sensibles dans les transactions HTTP est le problème
le plus visible, ce n'est que le sommet de l'iceberg. Toutes les composantes d'une
transaction de paiement électronique ne passent pas par HTTP. Le vendeur peut
utiliser d'autres protocoles (courrier électronique, FTP (File Transfer Protocol),
LDAP (Lightweight Directory Access Protocol) par exemple) comme moyen de règlement
et pour s'assurer que l'argent aboutit bien dans son compte en banque. Une fois
le numéro de carte de crédit reçu par le vendeur, il faut valider le numéro, faire
approuver l'achat par l'organisme émetteur de la carte, et débiter l'organisme
financier de l'acheteur (figure 1).
L'ensemble du processus de transaction n'a pas de protection standard. Pis encore,
une faille du dispositif de sécurité peut intervenir dans l'une des étapes suivant
la commande HTTP sans que l'acheteur n'en ait connaissance. Les acheteurs en ligne
se croient donc plus en sécurité qu'ils ne le sont réellement.
Heureusement, les standards des protocoles Internet sont en train de changer pour
combler ces lacunes en matière de sécurité. Malheureusement, ils ne changent pas
assez vite et aucun standard de sécurité à lui seul ne répond aujourd'hui à tous
les besoins. SSL est en train de devenir un transport multiprotocoles et a été
rebaptisé TLS (Transport Layer Security) mais son adaptation au cryptage autre
que HTTP pose des problèmes. L'autre principal protocole de sécurité, SET (Secure
Electronic Transactions), est très efficace mais tellement lourd à mettre en oeuvre
que peu d'entreprises l'utilisent.
Pour arriver à une bonne sécurité des transactions, il est important de bien comprendre
les avantages et les limites de chaque protocole. De plus, une petite connaissance
de l'historique de chaque protocole donne un peu plus d'éclairage et peut aider
à choisir le cryptage le mieux adapté au commerce électronique. Enfin, il est
bon de savoir ce que l'AS/400 propose dans ce domaine.
Protocoles de sécurité : un état des lieux
Ni SSL ni SET n’ont atteint la perfection par enchantement. Des organismes privés
ont conçu les deux protocoles et les ont proposés à l’usage public sans droits
de licence. Mais les protocoles avaient également des objectifs initiaux modestes
qui se sont bien étendus depuis.
TLS et SET donnent tous deux satisfaction quand on les utilise dans l’esprit
de leurs concepteurs
Protocole SSL (Secure Sockets Layer)
En 1993, Netscape Communications a conçu et mis en oeuvre SSL. La version 1.0 n’existait
que sur papier. C’est en 1994 que Netscape a livré la première mouture à grande
diffusion, basée sur la version 2.0 du protocole. SSL a tout de suite rempli sa
mission, cryptant les sessions entre un navigateur Web d’un acheteur et le serveur
Web d’un vendeur. Après quelques années d’expérience, Netscape a lancé la version
3.0 en 1996, qui corrigeait quelques failles de sécurité théoriques et améliorait
les performances.
Comme son nom l’indique, SSL est destiné à travailler au niveau du socket (ce
qui se situe au niveau de la demande de connexion entre un et un serveur). Généralement,
le client (au sens client/serveur du terme) est le navigateur HTML du client (au
sens acheteur du terme), et le serveur est un serveur HTTP du vendeur. Au moyen
de certificats digitaux publics (le processus d’authentification qui utilise le
cryptage à clé publique pour vérifier l’identité d’un serveur), SSL authentifie
le vendeur auprès de l’acheteur. De son côté, le vendeur doit authentifier l’acheteur
par d’autres moyens si c’est nécessaire, comme la validation de la carte de crédit
(cette étape ne fait pas partie du protocole SSL). A défaut, on suppose que le
client est anonyme (figure 2). Pour une description détaillée de SSL et des certificats
digitaux, voir l’article » Une introduction à SSL « , NEWSMAGAZINE, décembre 1997.
Le serveur détermine ce que SSL doit protéger dans la transaction, et seule une
partie de la transaction est cryptée. Généralement, le serveur crypte au moins
le numéro de la carte de crédit, le nom du possesseur et la date d’expiration,
en veillant à ce qu’aucune oreille indiscrète ne puisse voler ces informations
pendant l’échange.
L’AS/400 accepte SSL version 3.0 quel que soit le serveur Web installé. L’OS/400
offre gratuitement tout ce qui est nécessaire pour SSL sur HTTP, même s’il n’est
pas si simple de rendre SSL opérationnel. Pour une explication plus détaillée
sur la mise en place de SSL sur AS/400, voir les articles » Création et mise en
service d’un site Web AS/400 « , NEWSMAGAZINE, juin 1999 et » Configurer les serveurs
TCP/IP de l’AS/400 pour SSL « , NEWSMAGAZINE, janvier 2000.
En 1999, Netscape a remis SSL à l’IETF (Internet Engineering Task Force) afin
qu’il puisse devenir un standard public. L’IETF a quelque peu modifié SSL et l’a
rebaptisé Transport Layer Security. La RFC (Request For Comments) correspondante,
qui est un document de normalisation, est la RFC 2246 (www.rfc.net). Dans cet
article, nous ne de SSL que sous le nom de TLS.
Protocole SET (Secure Electronic Transactions)
En 1995, deux grandes sociétés de cartes de crédit, Visa et Mastercard, en collaboration
avec plusieurs éditeurs de logiciels, ont développé SET. Le but était de limiter
la fraude à la carte de crédit dans toutes les transactions électroniques, tant
sur le Web que sur un autre support. Contrairement à TLS, capable de crypter des
données entre un client et un serveur, SET ne protège que la transaction de paiement
proprement dite. De même, contrairement à TLS, SET protège le paiement jusqu’à
son arrivée à la banque, en surveillant de près la fraude à la carte de crédit
à plusieurs niveaux.
SET repose sur l’idée d’un porte-monnaie électronique détenu par le client. Ce
porte-monnaie contient des informations d’authentification sous la forme d’un
certificat digital et d’un numéro de carte de crédit. Tous deux sont cryptés et
signés numériquement pour empêcher qu’on ne puisse subrepticement les divulguer
ou les altérer. Une transaction SET implique trois intervenants : l’acheteur,
le vendeur et la banque (figure 3). Une fois que l’acheteur et le vendeur se sont
mutuellement authentifiés, l’acheteur transmet sa commande au vendeur en y incluant
le numéro de sa carte de crédit crypté au moyen de la clé publique de la banque.
Le vendeur retransmet le certificat digital et le numéro de carte de crédit crypté
de l’acheteur à la banque, laquelle autorise ou refuse le paiement.
Le cryptage garantit qu’aucun intrus n’intercepte les détails du paiement pour
s’en servir frauduleusement plus tard. Le vendeur ne voit jamais le numéro de
carte de crédit de son client, ce qui élimine l’une des sources les plus courantes
de transactions frauduleuses : la malhonnêteté du commerçant ou d’un des ses employés.
Pour une description détaillée de SET, voir le Redbook SG24-4978 : Secure Electronic
Transactions: Credit Card Payment on the Web in Theory and Practice.
TLS et SET donnent tous deux satisfaction quand on les utilise dans l’esprit de
leurs concepteurs. Malheureusement, une grande partie du commerce électronique
sur Internet ne peut pas utiliser l’un ou l’autre de ces protocoles en respectant
strictement l’intention des concepteurs. Voyons de plus près les problèmes de
chacun d’eux et avançons quelques solutions possibles.
Téléchargez cette ressource
Travail à distance – Guide complet pour les Directions IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
