La sécurité comporte trois aspects principaux : la confidentialité, l'intégrité et l'authentification. La confidentialité consiste à s'assurer qu'une information n'est accessible qu'aux entités autorisées à la consulter. L'intégrité est la propriété, pour une information, de rester identique à elle-même si elle n'est pas explicitement modifiée. Dans le cas d'une communication, le message reçu est bien celui qui a été transmis. L'authentification garantit qu'une entité est bien celle qu'elle prétend être.

La connexion du client au serveur de commerce lors de l'émission de l'ordre d'achat doit être sécurisée. En effet, le client doit recevoir la garantie que le serveur de commerce est bien celui qu'il prétend être (authentification) et que les informations transmises (numéro de carte bleue) restent confidentielles. Remarquons que, quelque soient les mesures de sécurité prises, le client n'est pas à l'abri d'une malveillance venant du serveur. Certains protocoles (SET) permettent de résoudre ce problème.

Pratiquement toutes les parties intervenantes dans l'application GICOM doivent pouvoir être authentifiées, et doivent donc posséder un point d'entrée SSL. Dans le cadre de ce projet, seule la partie Serveur de nom, pour laquelle nous ne demandons pas de modification de code, ne sera pas sécurisée.

Les opérations d'authentification seront réalisées au niveau de l'application. Un objet Compte d'une agence bancaire sera chargé d'authentifier les clients des méthodes de préparation et de validation d'opérations de débit/crédit .

De même le serveur de transaction devra authentifier le coordinateur de la transaction comme étant un serveur de commerce. Il vérifiera également que les ressources sont des comptes bancaires.

Enfin, le serveur de commerce devra authentifier le serveur de transactions.

2 Le protocole SSL

Le protocole de sécurité choisi pour mettre en oeuvre cette sécurité est SSL (Secure Socket Layer). Ce protocole a été développé par Netscape Communication Corporation pour permettre le transfert sécurisé de données sur Internet.

SSL opère à l'interface des sockets TCP. En conséquence, tous les protocoles de la couche application comme HTTP, FTP, Telnet, IIOP ... peuvent être protégés par un canal de transmission sécurisée. En utilisant HTTP, une connexion SSL peut être reconnue par l'URL de type https. Autrement dit, https désigne le protocole HTTP mis en oeuvre sur une couche de transport sécurisée.
SSL est implanté dans la plupart des navigateurs (Netscape Navigator, Microsoft Internet Explorer), et également dans les serveurs (Netscape Server, Apache, NCSA).

2.1 Clés

Les mécanismes utilisés pour fournir une communication sécurisée utilisent le principe de clés, qui permettent de chiffrer / déchiffrer (c'est a dire crypter / décrypter) un message qu'en connaissance de la valeur de la clé et de l'algorithme de cryptage. Attention, l'algorithme de cryptage n'est pas secret, seules les clés le sont.

2.1.1 Modèles à clés secrètes partagées

< a faire >

Kerberos

2.1.2 Modèles à clés publiques (algorithmes de chiffrement asymétrique)

Nous expliquons rapidement le principe d'utilisation des modèles a clés publiques. Celui-ci se base sur un couple de valeurs de clés (clé publique Kp, clé secrète Ks), qui garantit que Ks ne peut pas être calculé a partir de Kp, mais par contre Kp peut être déduit de Ks.

Le principe des algorithmes a chiffrement asymétrique est qu'ils mettent en jeu un couple de clés, dont l'une sert au chiffrement et l'autre au déchiffrement. La clé de chiffrement est la clé publique, c'est a dire que tout le monde peut demander a une entité sa clé publique (ou bien a un annuaire), et utiliser cette clé pour envoyer un message confidentiel a E en chiffrant le message selon un algorithme standard (RSA, DSA, ..). Seul E pourra déchiffrer le message a l'aide de sa clé privee.
Remarquons qu'il est nécessaire d'avoir confiance en la clé publique du destinataire du message, et pour ce faire, on utilise une tierce autorité délivrant des certificats (section suivante).

Si la méthode de production des clés satisfait en outre la propriété de commutativité, alors E2 peut également utiliser sa clé privée pour renvoyer un message crypté M' a E1, qui sera décryptable avec la clé publique de E2. Le message M' est par contre non confidentiel puisque toutes les entités connaissant la clé publique de E2 peuvent le déchiffrer. Il existe des extensions au protocole permettant le renvoi de messages confidentiels de E2 vers E1.

Figure 1. Principe du mécanisme à clé publique

Dans cette organisation, rien ne garantit bien sur que l'annuaire est sur, et que l'entite E1 qui s'est enregistrée dans l'annuaire n'est pas un intrus. Pour garantir que les intervenants correspondent bien ceux autorisés, un mécanisme basé sur des certificats est fourni.

Il faut savoir que les algorithmes asymétriques sont assez lents au regard des algorithmes symétriques. De plus, ils utilisent des clés plus grandes. En général, ces algorithmes sont utilises pour échanger entre un client et un serveur une clé secrète qui servira a communiquer au travers d'un algorithme de chiffrement symétriques.

2.2 Certificats

Un certificat est une " carte d'identité numérique " possédant une durée de vie limitée et attestant qu'une clé publique appartient à une entité particulière. Plus précisément, le rôle du certificat est d'associer de façon non équivoque une clé publique avec une entite

Lorsque l'on reçoit un message signe d'une entité E, le certificat permet de vérifier que le message a bien été émis par E. La vérification de la signature avec la clé publique de E (KpE) ne permet pas d'affirmer que c'est bien E qui a envoyé le message. Il faut en effet vérifier que KpE est bien la clé publique de E.

Un certificat doit être signé par une entité qui assure la validité du certificat. Cette entité possède elle-même un certificat signé par une autorité supérieure. Les autorités de certification (CA) sont organisées en structure d'arbre. Au sommet de la hiérarchie se trouve le root qui signe lui-même son certificat. Un certificat X.509 est principalement composé des champs suivants :

une suite d'informations non chiffrées contenant entre autres le nom et la clé publique de l'entité possédant le certificat

le nom de l'algorithme de signature choisi (ex : md5 With RSA Encryption)
l'émetteur du certificat (l'autorité qui a signe le certificat)
la clé publique du sujet, et l'algorithme au travers duquel elle peut être utilisée

la signature du CA (Certificate Authority)

Lorsqu'une entité signe un message M, elle commence par calculer un résumé du message D(M) à l'aide d'une fonction de hachage non inversible D ; puis, elle chiffre ce résumé avec sa clé privée KS pour obtenir {D(M)}_KS. Le principe consiste à considérer que pour un message signe, l'origine et l'intégrité des données sont garanties.

Figure 2. Certificat de Shooping Server signe par le CA Verisign, et certificat de Verisign

Pour pouvoir être authentifié, un serveur (prenons pour exemple le serveur GICOM) doit faire signer son certificat par le serveur Verisign. Pour ce faire, il envoie son certificat ainsi que sa clé publique au serveur Verisign. Ce dernier, après vérification de l'identité du demandeur, renvoie une signature contenant le certificat GICOM (soit C), ainsi qu'un résumé de C encrypté avec la clé secrète de Verisign (fig 2).

C + {D(C)}_{KS Verisign.}

Lorsque le client reçoit le certificat signé du serveur de commerce, il vérifie la signature. Pour ce faire, il calcule :

- { {{D(C)}_{KS Verisign.} } Kp verisign depuis {{D(C)}_KS_Verisign.
- D(C) depuis C

Si { {{D(C)}_KS
Verisign. } Kp verisign = D(C), alors la signature est valide puisqu'elle n'a pu etre produite qu'avec la clé privée de Verisign. Le client a donc la garantie (du CA Verisign) que la clé publique contenue dans le certificat est bien celle du serveur de commerce.
Cette clé publique peut maintenant être utilisée pour transmettre au serveur une clé secrète partagée qui pourra être utilise pour assurer la confidentialité des données qui vont être échangées entre le client et le serveur au travers d'un modèle a clé secrète.

Figure 3. Authentification initiale

2.3 Fonctionnement de SSL

Le protocole SSL met en oeuvre une communication sécurisée au niveau de la couche Transport. Il utilise :

un algorithme a clé publique (RSA) pour l'authentification et l'échange de clé secrète
un algorithme a clé secrète (DES, RC4) pour le chiffrement des données
un algorithme de hachage non réversible (SHA, MD5) pour le calcul des résumes de messages.

Etant donne qu'il existe plusieurs algorithmes pour chaque point, le client et le serveur doivent s'accorder avant de commencer tout transfert de données. Cette phase de négociation porte le nom de handshake.

2.3.1 Exemple de Handshake

Le handshake permet au client et au serveur de s'authentifier mutuellement, et de choisir un algorithme cryptographique qu'ils ont en commun.

Le client envoie au serveur le message "client hello" (demande de certificat).
Le serveur envoie sa clé publique accompagnée de son certificat
Le client renvoie au serveur une clé secrète : il cé publique cette clé secrète qu'il a générée (premaster secret) puis la transmet au serveur (client key exchange) au travers d'un algorithme d'échange de clés.
Le serveur déchiffre cette clé à l'aide de sa clé privée. Ainsi, le client et le serveur partagent une même clé secrète. De plus, le client a la garantie que le serveur est bien celui qu'il prétend être puisqu'il a déchiffré le message avec sa clé privée.

L'authentification du client est une opération optionnelle du protocole. Si le serveur le demande, alors le client doit envoyer son certificat en plus de la clé secrète. Il transmet egalement au serveur une signature {D(M)}_KS(certificate verify). KS est la clé privée du client. M est constitué de l'ensemble des messages échangés ainsi que de la clé secrète partagée. Ainsi, le serveur a la garantie que le client est bien celui qu'il prétend être (identité décrite par le certificat).

Une fois la phase de handshake terminée, l'échange de données chiffrées et signées peut commencer (connexion sécurisée). Une session est créée par une phase de handshake et peut comporter de multiples connexions. Le concept de session est utilisé pour éviter de négocier les paramètres de cryptographie à chaque ouverture de connexion.

Le schéma ci-dessous représente un déroulement possible de la phase de handshake :

Le message certificate request du serveur est optionnel. Le client y répond en envoyant sa clé publique accompagnée de son certificat (certificate). Puis il s'authentifie (certificate verify) comme décrit précédemment, a l'aide d'une signature.

Le message finished est le premier message protégé avec les algorithmes négociés. Aucun acquittement n'est demandé ; les participants peuvent commencer à émettre les données chiffrées immédiatement après avoir envoyé le message finished.

2.3.2 Algorithmes d'échange de clé (Kx)

Plusieurs algorithmes peuvent être utilisés :

4. Diffie-Hellman : le serveur envoie au client un message contenant deux grands nombres premiers (p et g) et le résultat g^x mod p, x étant un grand nombre secret (server key exchange message). Le client choisit à son tour un grand nombre secret y et envoie au serveur le résultat g^y mod p (client key exchange message). Chacun élève ensuite le résultat de l'autre à la puissance de son nombre secret pour obtenir g^xy mod p. Ce protocole connu sous le nom de Diffie-Hellman anonyme (DH_anon) est vulnérable à l'attaque dite du " passeur de seau " (man-in-the-middle attack) et est donc fortement déconseillée. Afin d'assurer le client que les valeurs p et g proposées par le serveur sont réellement les siennes, il les transmet à l'intérieur d'un certificat (l'algorithme de signature étant RSA). On remarque que grâce au certificat, l'échange de clé authentifie le serveur.

5. RSA : cet algorithme utilisé pour la signature des certificats peut être également employé pour l'échange de clé. Dans ce cas, le client génère une clé secrète de 48 octets qu'il chiffre avec la clé publique du serveur (obtenue par certificat, ou par le message optionnel server key exchange).

6. FORTEZZA utilise l'algorithme de cryptographie à clé publique DSS (Digital Signature Standard). Le client génère à partir de la clé publique du serveur et de paramètres privés une clé secrète appelée : Token Encryption Key (TEK). Il communique au serveur les paramètres publiques nécessaires au calcul du TEK. Puis, le client génère plusieurs clés de session chiffrées à l'aide du TEK, qu'il envoie au serveur (client key exchange message).

Les informations utilisées pour l'échange de clé (clé publique RSA, DSS ou paramètres p et g de Diffie-Hellman) doivent être authentifiées à l'aide d'un certificat.

Dans le cas de RSA, le gouvernement Américain limite la taille des clés pour le chiffrement à 512 bits, mais ne fixe aucune limite concernant celles utilisées pour les opérations de signature. En effet, certains certificats ont besoin de clés de taille supérieure à 512 bits car ces dernières ne sont pas suffisamment sûres pour des transactions de valeur importante ou pour des applications nécessitant une sécurité à long terme. Ces certificats (sign-only certificate)sont signés avec des clés de taille supérieure à 512 bits, non autorisées pour le chiffrement des données. En conséquence, après avoir communiqué son certificat au client, le serveur signe une clé RSA de 512 bits, le maximum autorisé (server key exchange message). Cette clé temporaire sert à l'échange de clé secrète. Il est conseillé de changer de clé RSA temporaire toutes les 500 transactions.

2.3.3 Algorithmes à clé secrète du protocole SSL

Le protocole SSL peut utiliser les algorithmes suivants : RC2, RC4, DES (Data Encryption Standard) et IDEA (International Data Encryption Algorithm).

RC2, DES et IDEA sont des algorithmes de chiffrement par blocs (block cipher).

RC2 et RC4 ont été conçus par RSA Data Security. Aucune publication n'existe sur RC2. RC4 est un algorithme de chiffrement en continu (stream cipher) à clé de longueur variable. Il a récemment été dévoilé sur Internet.

DES chiffre un texte par blocs de 64 bits. Les blocs sont chaînés de différentes façons pour que, en remplaçant un bloc par un autre le déchiffrement échoue à l'endroit du remplacement. Un vecteur d'initialisation (VI) permet d'amorcer le chaînage des blocs.

Le DES à clé de 56 bits peut cependant être cassé par une recherche exhaustive en quelques heures, d'où l'idée d'utiliser trois clés de 56 bits (168 bits). DES est dans ce cas largement suffisant pour les applications commerciales actuelles.

IDEA est un autre algorithme de chiffrage par bloc utilisant une clé de 128 bits. Aucune technique ne peut aujourd'hui casser IDEA.

2.3.4 Calcul du MAC

Le calcul des résumés de message est réalisé de la façon suivante.

hash(MAC_write_secret + pad_2 +

hash(MAC_write_secret + pad_1 + seq_num +

Compressed.type + Compressed.length + Compressed.fragment))

pad_x : caractère (0x36 ou 0x5c) répété 48 (MD5) ou 40 pour SHA
seq_num : numéro de séquence du message
hash : algorithme de hachage indiqué par le cipher suite.
Compressed : message compressé non chiffré

2.4 Session et connexion SSL

Le protocole SSL met en oeuvre des sessions composees de connexions.
Pour toute session de communication dans laquelle intervient une entité E, il gere un état constitué de :

identificateur de session : une séquence d'octets arbitrairement choisie pour identifier l'état d'une session active ou réactivable.
certificat de l'entité E (X509.v3)
méthode de compression : algorithme utilisé pour compresser les données avant chiffrement
algorithme de chiffrement (cipher spec) : algorithmes de cryptographie à clé secrète utilisés pour le chiffrement des données échangées (DES, RC2, IDEA) et de calcul de résumé de message (Message Authentification Code MAC) comme MD5 ou SHA.
master secret : clé secrète de 48 octets partagée entre le client et le serveur.
réactivable (is resumable) : un flag indiquant si la session peut être utilisée pour ouvrir de nouvelles connexions.

Si le client désire ouvrir une nouvelle connexion dans le cadre d'une ancienne session, il doit indiquer au serveur l'identificateur de cette session. Le serveur cherche alors dans son cache l'identificateur en question.

L'utilisation de nouvelles clés à chaque session sert à minimiser la quantité de données chiffrées qu'un intrus pourrait obtenir et en conséquence réduire les dommages au cas où une clé de session soit découverte.

L'état d'une connexion est défini par :

deux séquences d'octets aléatoires (client and server random) choisies par le client et le serveur pour chaque connexion.
server (client) write MAC secret, utilisé par le serveur (client) pour le calcul du MAC lors de l'envoi de ses données.
server (client) write key, clé secrète pour le chiffrement des données envoyées par le serveur (client)
Vecteurs d'initialisation (IV) : utilisés pour les algorithme de chiffrement à clé secrète en blocs (RC2, DES)
Numéros de séquence : chaque participant génère une numérotation particulière pour chaque connexion.

3 Mise en oeuvre du protocole HTTPS

Un client désirant établir une connexion SSL avec un serveur Web utilise l'URL de type https (protocole HTTP sécurisé). Le port correspondant est par défaut 443.

Certains navigateurs comme Netscape possèdent initialement un certain nombre de clés publiques de CA (comme Verisign) permettant d'authentifier les certificats envoyés par le serveur web. Si un certificat reçu n'est signé par aucune de ces autorités, le navigateur demande au client s'il accepte le certificat.

Dans le cas où le certificat est accepté, une connexion sécurisée est établie (que Netscape indique par un icône représentant un cadenas fermé). Lorsque le client ouvre par la suite une connexion non sécurisée, il est averti du changement.

Pour mettre en oeuvre cette communication sécurisée entre un browser Netscape et des servlets, on est forcé d'utiliser un vrai serveur Web.

Nous proposons d'utiliser le connecteur HTTPS livré avec Jakarta TomCat

· Pour la partie CustomerServlet, seul le Certificat Serveur est requis

· Pour la partie AdminServlet, les Certificats Client et Serveur sont requis

Pour cela, suivez les indications données dans la documentation suivante

· %CATALINA_HOME%\webapps\tomcat-docs\ssl-howto.html

· %CATALINA_HOME%\webapps\tomcat-docs\config\realm.html

· %CATALINA_HOME%\webapps\tomcat-docs\config\coyote.html

· %JAVA_HOME%\docs\tooldocs\windows\keytool.html

· %JAVA_HOME%\docs\tooldocs\solaris\keytool.html

· Cours sur les PKI http://www-adele.imag.fr/~donsez/cours/pki.pdf

· Cours sur JCE http://www-adele.imag.fr/~donsez/cours/jce.pdf
et des exercices corrigés sur le JCE http://www-adele.imag.fr/~donsez/cours/tpjce.zip

4 Mise en oeuvre du protocole IIOP sur SSL

La procédure pour sécuriser les liaisons IIOP entre clients et serveurs JacORB est décrite dans le le chapitre 12 « IIOP over SSL» du guide de programmation de JacORB (%JACORB_HOME%\doc\ProgrammingGuide\ProgrammingGuide.pdf).

Conformez vous à cette documentation pour sécuriser les liaisons entre les clients et les serveurs bancaires de GICOM.

1 Sécurisation des Web Services

Les relations du serveur eCOM avec les différents Web Services externes (service de conversion de devises, fournisseurs) peuvent être attaquées.

Plusieurs solutions de sécurité sont disponibles pour protéger ces relations :

Sécuriser le transport des messages avec SSL quand ils ont « porté » par http
Sécuriser les messages eux-même (XML Signature, XML Encryption)

Consultez la documentation %AXIS_HOME%\docs\security.html à ce sujet et testez l’exemple %AXIS_HOME%\samples\security

Vous pouvez également consulter le cours http://www-adele.imag.fr/~donsez/cours/xmlsecu.pdf.

2 Documentation

2.1 Présentation des infrastructures à clés publiques

Introduction to Public-Key Infrastructure, http://www.iplanet.com/developer/docs/articlés/security/pki.html
Cours Infrastructures a clés publiques (PKI) http://www-adele.imag.fr/~donsez/cours/pki.pdf

2.2 JCE

Cours sur le Java Cryptography Extension (JCE), http://www-adele.imag.fr/~donsez/cours/jce.pdf
et l'exercice associé http://www-adele.imag.fr/~donsez/cours/tpjce.zip

o ISaSiLk http://jcewww.iaik.tu-graz.ac.at

Société : Institute for Applied Information Processing and Communications (Autriche)
Ce paquetage implémente le protocole SSL pour le langage Java. Il fonctionne au-dessus d'un JCE (Java Cryptography Extension). Nous avons utilisé celui d'IAIK : IAIK-JCE.

o Cryptix http://www.cryptix.org

Open Source Java crypto library

2.3 SSL

la spécification de SSL 3.0 est donnée à www.netscape.com/eng/ssl3/index.html

o Tomcat SSL Configuration ${TOMCAT_HOME}/doc/tomcat-ssl-howto.html

o OpenSSL : http://www.openssl.org

o ModSSL (SSL support for Apache)

o JSSE (Java Secure Socket Extensions) http://java.sun.com/products/jsse, inclut dans le J2SE 1.4

2.4 Serveur Web Apache :

o www.cge-ol.fr/apache (mirroir)

Lors de la phase de développement , le servlet runner est plus approprié pour tester l'application. Cependant, la mise en place d'une liaison HTTP sécurisée nécessite d'utiliser un serveur Web qui implémente ce service (Apache).
Pour le patch sécurité, l'URL est www.apache-ssl.org (Apache utilise une version libre de SSL appelée SSLeay). L'ensemble Apache SSL (le patch) et SSLeay (protocole SSL) peuvent être obtenus à l'URL ftp.ox.ac.uk/pub/crypto/SSL. Des informations complémentaires sur SSLeay sont disponibles à www.ssleay.org. De plus, une notice d'installation d'Apache SSL peut être trouvée à www.cs.tamu.edu/helpdocs/ssl.

2.5 Divers

Informations concernant les certificats, les cookies, SSL sur le site de Netscape

http://www.netscape.com/newsref/std