TLS à  la rescousse

essaient de les
surmonter par l’utilisation astucieuse de TLS en arrière-plan de la transaction,
entre le vendeur et la banque. On pourrait utiliser certaines de ces mêmes techniques
pour le commerce électronique sur AS/400, même si, comme nous le verrons bientôt,
il manque à  l’OS/400 quelques-uns des principaux composants nécessaires pour le
faire facilement.

La solution des problèmes de TLS commence par le stockage des informations d’identification
de l’acheteur sur le site du vendeur. La solution de facilité consiste à  ne pas
stocker du tout les informations, et à  les transmettre simplement à  la banque
puis à  les oublier. Mais, c’est le vendeur qui risque alors d’être en difficulté
si on lui demande plus tard de prouver qu’un numéro de carte de crédit particulier
a été utilisé pour une transaction. Donc, plutôt que le non-stockage pur et simple
du numéro de carte de crédit, une solution consiste à  stocker une version cryptée
des informations. Un vendeur peut le faire sans peine à  l’aide des fonctions de
cryptage bidirectionnel présentes dans la plupart des systèmes d’exploitation
(y compris l’AS/400). Mais le vendeur court alors le risque de voir sa propre
clé de cryptage compromise, entraînant la divulgation de milliers de numéros de
cartes de crédit.

Il est préférable d’utiliser un cryptage unidirectionnel, comme l’algorithme MD-5.
Ce cryptage produit un code de hachage unique pour un bloc donné de texte ordinaire,
comme l’ensemble des valeurs d’identification de la carte de crédit pour un acheteur.
Dans ce système, le vendeur va calculer le hachage MD-5 des informations de carte
de crédit de l’utilisateur et va stocker ce hachage plutôt que les valeurs elles-mêmes.
Le jour où il devra prouver qu’une certaine carte a servi pour une transaction,
le vendeur pourra comparer un hachage nouvellement calculé des informations de
test, au hachage stocké. Il est probablement préférable de calculer trois hachages
distincts de chaque valeur, plutôt qu’un seul hachage combiné, afin que les vendeurs
puissent détecter les correspondances, comme le numéro et la date d’expiration,
mais pas le nom du possesseur de la carte. L’OS/400 supporte la fonction de hachage
MD-5 dans son API CIPHER. Pour des instructions complètes sur l’utilisation de
cette API, et des exemples pratiques, voir l’article  » Intégrité des données avec
les fonctions de hachage unidirectionnel « .

La seconde partie du problème des transactions TLS est la communication entre
le vendeur et la banque. Aujourd’hui, les vendeurs peuvent utiliser une ligne
commutée pour authentifier chaque transaction individuellement, ou des circuits
spécialisés haute vitesse utilisant un matériel spécialisé coûteux pour se connecter
directement au centre des cartes de crédit sur une ligne privée sécurisée. D’autres
vendeurs peuvent se contenter d’imprimer les commandes et de les télécopier à 
la banque. Est-ce vraiment fiable ?

Une meilleure solution pour protéger cette transaction consiste à  utiliser TLS
exactement comme on l’a fait entre l’acheteur et le vendeur. Mais, cela suppose
que le vendeur soit capable de fonctionner comme un client authentifié par certificat
auprès du serveur de la banque, sans intervention humaine. En bref, le serveur
du vendeur agira comme un client équipé de TLS, se connectant au serveur équipé
de TLS de la banque, en utilisant les informations stockées concernant la transaction
bancaire, pour générer une demande d’authentification de carte de crédit et recevoir
une réponse. C’est ainsi que de nombreuses banques abordent le problème, même
s’il en résulte une dépendance entre le vendeur et la banque sur le format de
la transaction bancaire. Un standard XML (Extensible Markup Language) est en cours
de développement pour formaliser ces transactions d’autorisation de cartes de
crédit sur HTTP crypté par TLS. La possibilité qu’a XML de coder des types de
données de manière transparente afin que les deux côtés d’une transaction HTTP
puissent travailler avec les données, indépendamment de l’ordre, élimine les problèmes
de dépendance des données. Pour avoir un aperçu de XML, voir l’article  » XML :
Au-delà  des frontières « , NEWSMAGAZINE, septembre 2000.

Il existe de nombreux serveurs et clients FTP, SMTP et LDAP supportant
TLS

L’OS/400 supporte le fonctionnement client TLS, même si le vendeur doit écrire
l’application client conformément au propre format de transaction HTML de la banque.
La banque génèrera un certificat d’authentification unique pour le vendeur que
les administrateurs pourront enregistrer sur l’AS/400 à  l’aide de l’API Register
Application for Certificate Use (pour OPM, QSYRGAP ; pour ILE, QsyRegisterAppForCertUse).
Cette API est documentée dans les manuels d’API au chapitre OS/400 Security APIs.
Les administrateurs peuvent alors attribuer le certificat à  l’application en utilisant
le DCM (Digital Certificate Manager) de l’OS/400. Pour plus de détails sur l’utilisation
du DCM, voir la documentation en ligne d’IBM.

Comme TLS n’est pas lié à  un protocole particulier, comme HTTP, on peut l’utiliser
pour sécuriser d’autres protocoles, comme FTP, SMTP (e-mail) et LDAP. Il existe
de nombreux serveurs et clients FTP, SMTP et LDAP supportant TLS sur le marché,
mais aucun ne fonctionne sur l’AS/400. La situation devrait s’améliorer puisqu’IBM
déclare qu’ils figureront dans une future release de l’OS/400.