On rencontre aujourd'hui deux types d'approche:
La première approche vise à établir une base technique
sur laquelle peuvent prendre place toute une gamme d'applications sécurisées
(paiement ou autres).
La seconde approche est plus immédiate et vise
à employer les techniques disponibles actuellement pour réaliser
un protocole de paiement.
Les principaux représentants de ces
approches sont SSL et S-HTTP d'une
part, SET d'autre part.
Suivant en cela une tendance plus générale pour la conception des systèmes répartis, la sécurité des échanges devient l'affaire d'une couche supérieure, la couche Session (dans le cas de SSL) ou la sous-couche applicative d'implantation du protocole (dans le cas de S-HTTP). Cette couche va intervenir pour mettre en place un échange de messages sécurisé entre les applications. Elle emploie la trousse à outil habituelle:
Le protocole Secure Socket Layer
a été développé par Netscape pour
offrir sécurité et confidentialité sur Internet. Ce
protocole permet d'identifier clients et serveurs dans une connexion de type
socket.
SSL s'inscrit comme une couche intermédiaire du
protocole de communication (niveau Session). Elle n'est pas liée à
une application en particulier. Elle permet donc de sécuriser tout
protocole existant d'application Internet, que ce soit HTTP, FTP ou Telnet et
ce, sans modifier les logiciels.
SSL a bien entendu été
implanté sur le navigateur de
Netscape.
SSL a été présenté pour être
adopté comme standard Internet.
Au démarrage de la session, le protocole SSL identifie le serveur, le
client, puis négocie les paramètres de cryptage. Durant la
session, SSL assure la confidentialité et la fiabilité des échanges,
par des techniques de cryptage et d'identification des messages.
Durant la
phase d'identification, le serveur expédie ses certificats et indique ses
algorithmes de cryptage de prédilection. Le client génère
ensuite une première clef, dite « clef maîtresse », qu'il
crypte par la clef publique du serveur avant de la lui expédier. Le
serveur se fait reconnaître en retournant un message crypté par la
clef maîtresse. Les échanges qui suivent sont cryptés par
des clefs dérivées de la clef maîtresse.
L'identification
du client est facultative. Le serveur expédie au client un message
quelconque et le client s'identifie en retournant sa signature électronique
sur ce message, accompagnée de ses certificats.
SSL ne gère
de signature que sur les messages prévus dans la phase d'identification.
SSL peut employer différents algorithmes de cryptage (aujourd'hui RC2, RC4, IDEA, DES et triple DES). RSA est employé dans la phase d'identification. Les empreintes sont produites par MD5 ou SHA. Les certificats respectent la syntaxe X.509.
Le protocole S-HTTP est une
extension sécurisée du protocole HTTP du Web. Ce protocole a été
développé chez Enterprise Integration Technologies, mais
le développement se poursuit chez Terisa
Systems. Ce protocole est un protocole d'application. Il est conçu
pour offrir les garanties de confidentialité, d'authenticité,
d'intégrité et de non désaveu. Il peut fonctionner avec
différents algorithmes de cryptage et différentes méthodes
d'identification, grâce un protocole de négociation des paramètres
de cryptage entre client et serveur. S-HTTP crypte un à un les messages échangés,
et permet de leur adjoindre une signature. S-HTTP est conçu comme une boîte
à outil pour le Web, pouvant accueillir toutes les applications qui
puisse un jour s'inventer.
S-HTTP a (bien entendu) été
implanté sur les navigateurs Mosaic et dérivés.
S-HTTP a été présenté pour être adopté
comme standard Internet.
S-HTTP peut employer différents algorithmes de cryptage (aujourd'hui: DES, triple DES, DESX, IDEA, RC2 et CDMF). L'identification peut être réalisée par plusieurs méthodes d'identité certifiée (dont RSA), mais également par Kerberos. Les certificats respectent la syntaxe X.509.
SET (Secure Electronic Transaction
) a été développé conjointement par Visa
et MasterCard, avec la participation de ténors de
l'informatique parmi lesquels Microsoft, IBM et Netscape
. La spécification est déposée depuis Février 96
dans le domaine public pour permettre à quiconque de développer
des logiciels conformes. Les différentes expérimentations auront
lieu dans le courant de l'année 96, pour aboutir à une diffusion
en 97.
SET est une spécification technique qui vise à sécuriser
au moindre coût les transactions par carte bancaire sur les réseaux
ouverts tels Internet.
Le protocole SET définit un ensemble de messages que peuvent émettre les systèmes informatiques de l'acheteur (A) et du commerçant (C), pour effectuer notamment les opérations suivantes:
SET est indépendant du transport. Il peut par exemple fonctionner sur le Web en interactif (protocole HTTP) ou par courrier (protocole SMTP). Pour ce faire, les messages de SET sont définis en tant que types MIME (ou types Internet selon la nouvelle terminologie) de la catégorie application/TBD.
Les transactions peuvent être très longues. Elles sont identifiées par un numéro unique repris dans tous les messages. Les messages sont conçus pour être idempotents.
Les participants de SET (commerçants et acheteurs) possèdent deux couples de clefs asymétriques: Un pour la signature des documents, un autre pour l'échange de clefs pendant la phase d'identification. On parle de clefs de signature et de clefs de cryptage. Les concepteurs de SET se sont en effet rendus compte que les deux usages des clefs asymétriques rencontraient des contraintes très différentes. En particulier:
Les certificats de SET représentent respectivement la carte de l'acheteur et l'autocollant apposé sur la vitrine du commerçant. Le certificat de l'acheteur ne mentionne pas le numéro de carte, ni aucun numéro de compte. Ceux-ci sont présents, mais voilés, et seul le banquier peut les dévoiler.
SET innove avec le procédé dit de la signature « duale », qui est employé pour faire une offre d'achat. Grâce a ce procédé, l'acheteur envoie simultanément son offre au commerçant et les instructions de paiement à la banque, en tenant compte des deux contraintes ci-dessous:
Pour éviter des aller retours complexes, une manoeuvre élégante à été créée, qui exploite les propriétés des empreintes électroniques.
Les deux messages (O = offre et I
= instructions) sont réduits en deux empreintes électroniques
E(O) et E(I). Les
empreintes sont concaténées puis réduites en signature
Sc({E(O), E(I)}) par la clef publique (c
) de l'acheteur. C'est la signature duale.
L'acheteur
transmet l'offre au commerçant et les instructions à la banque. Il
joint à chacun des documents l'empreinte de l'autre et la signature
duale. Ainsi, le message {O, E(I), Sc({E(O), E(I)})}
est envoyé au commerçant et {I, E(O),
Sc({E(O), E(I)})} est envoyé à la banque. Les deux
destinataires peuvent s'assurer de l'authenticité du message qu'ils reçoivent.
Si le commerçant accepte l'offre, il transmet son acceptation à
la banque, accompagnée de l'empreinte de l'offre. La banque est donc en
mesure de faire le lien avec les instructions.
Le procédé réellement utilisé par SET est simplifié par rapport au procédé théorique ci-dessus, car aucun message n'est transmis de l'acheteur à la banque. Celle-ci est en mesure de reconstituer les mêmes instructions de paiement (I) à l'aide des informations bancaires sur l'acheteur et du prix présenté par le commerçant. Elle vérifie les intentions de l'acheteur en comparant l'empreinte des instructions E(I).
SET entérine les normes de fait et effectue des choix définitifs. DES est employé pour le cryptage des messages. Les enveloppes électroniques forment une variante du format « PKCS #7 » de RSA. SET compte imposer ce format comme nouveau standard. Les signatures suivent les standards de RSA. Les empreintes sont réalisées par l'algorithme SHA-1. Les certificats sont au format X.509.
[Chapitre précédent], [Chapitre suivant], [Table des matières]