Application de commerce électronique

Etape 5 - Sécurité du support de communication

F. Boyer, S. Chassande, D. Feliot, S. Krakowiak, D. Donsez
Projet de DESS-GI option SRR  et RICM3 option SR
Année Universitaire 2001-2002
Université Joseph Fourier, Grenoble
PLAN
1. Introduction
2. Clés
3. Certificats
4. Protocole SSL
5. HTTP et IIOP sur SSL

1. Introduction

    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.

    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).
     

    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 etre 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. 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 / decrypter) 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.

    Modeles à clés secrètes partagées
    < a faire >
    Kerberos

    Modeles à clés publiques (algorithmes de chiffrement asymétrique)

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

      Le principe des algorithmes a chiffrement asymetrique est qu'ils mettent en jeu un couple de cles, dont l'une sert au chiffrement et l'autre au dechiffrement. La cle de chiffrement est la cle publique, c'est a dire que tout le monde peut demander a une entite sa cle publique (ou bien a un annuaire), et utiliser cette cle pour envoyer un message confidentiel a E en chiffrant le message selon un algorithme standart (RSA, DSA, ..).  Seul E pourra dechiffrer le message a l'aide de sa cle privee.
      Remarquons qu'il est necessaire d'avoir confiance en la cle publique du destinataire du message, et pour ce faire, on utilise une tierce autorite delivrant 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 pusque toutes les entites connaissant la cle publique de E2 peuvent le dechiffrer. Il existe des extensions au protocole permettant le renvoi de messages confidentiels de E2 vers E1.


     
     


    Figure 1. Principe du mecanisme a clé publique

      Dans cette organisation, rien ne garantit bien sur que l'annuaire est sur, et que l'entite E1 qui s'est enregistree 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 asymetriques sont assez lents au regard des algorithmes symetriques. De plus, ils utilisent des cles plus grandes. En general, ces algorithmes sont utilises pour echanger entre un client et un serveur une cle secrete qui servira a communiquer au travers d'un algorithme de chiffrement symetriques.

3. 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 precisement, le role du certificat est d'associer de facon non equivoque une cle publique avec une entite.
    Lorsque l'on recoit un message signe d'une entite E, le certificat permet de verifier que le message a bien ete emis par E. La verification de la signature avec la cle publique de E (KpE) ne permet pas d'affirmer que c'est bien E qui a envoye le message. Il faut en effet verifier que KpE est bien la cle publique de E.

    Un certificat doit etre 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 :

    1. une suite d'informations non chiffrées contenant entre autres le nom et  la clé publique de l'entité possédant le certificat
    2. le nom de l'algorithme de signature choisi (ex : md5 With RSA Encryption)
    3. l'emetteur du certificat (l'autorite qui a signe le certificat)
    4. la cle publique du sujet, et l'algorithme au travers duquel elle peut etre utilisee
    5. 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 a considerer que pour un message signe, l'origine et l'integrite des donnees sont garanties.


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



    Pour pouvoir etre 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, apres verification de l'identite du demandeur, renvoie une signature contenant le certificat GICOM (soit C), ainsi qu'un résumé de C encrypté avec la clé secrete 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 cle secrete partagee qui pourra etre utilise pour assurer la confidentialite des donnees qui vont etre echangees entre le client et le serveur au travers d'un modele a cle secrete.


    Figure 3. Authentification initiale


     

4. Protocole SSL

    Le protocole SSL met en oeuvre une communication sécurisée au niveau de la couche Transport. Il utilise : Etant donne qu'il existe plusieurs algorithmes pour chaque point, le client et le serveur doivent s'accorder avant de commencer tout transfert de donnees. Cette phase de negociation porte le nom de handshake.

    4.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.

    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 cle secrete. 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.

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

    Plusieurs algorithmes peuvent être utilisés :
    1. Diffie-Hellman : le serveur envoit au client un message contenant deux grands nombres premiers (p et g) et le résultat gx mod p, x étant un grand nombre secret (server key exchange message). Le client choisit à son tour un grand nombre secret y et envoit au serveur le résultat gy mod p (client key exchange message). Chacun élève ensuite le résultat de l'autre à la puissance de son nombre secret pour obtenir gxy 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.
    2. 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).
    3. 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 suffisament 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.

    4.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 chainage 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.
     

    4.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))
     

    1. identificateur de session : une séquence d'octets arbitrairement choisie pour identifier l'état d'une session active ou réactivable.
    2. certificat de l'entité E (X509.v3)
    3. méthode de compression : algorithme utilisé pour compresser les données avant chiffrement
    4. 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.
    5. master secret : clé secrète de 48 octets partagée entre le client et le serveur.
    6. 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 :

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

5. Mise en oeuvre des protocoles HTTP et IOP sur SSL

  1. HTTP Sécurisé

    2. Un client désirant établir une connexion SSL avec un serveur web utilise l'URL de type https (protocole HTTP securise). 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 un serveur Apache-SSL, dont l'installation et la configuration sont décrites a l'URL  http://www.apache-ssl.org .
     
     

  2. SSLIOP

    3. L'architecture d'ORBacus sépare l'implémentation de GIOP (General Inter-Object protocol) en deux parties. La première, indépendante de la couche transport, respecte la spécification de GIOP (représentation commune des données, format des messages). La seconde est spécifique au protocole de transport.

    La communication entre ces deux parties utilise une interface (Open Communication Interface) indépendante de la couche de transport utilisée. Cette interface permet de " brancher " facilement de nouveaux protocoles sur l'ORB. Par exemple, la couche IIOP située au-dessus de TCP implémente l'interface OCI.
    Le protocole SSL est intégré à l'aide de l'interface OCI.

    Les schémas ci-dessous représentent les différentes couches :

    Un serveur CORBA peut accepter des connexions normales (IIOP) ou sécurisées (SSLIOP). Deux points d'accès (ports) doivent donc être attribués. Les références IOR des objets situés sur un tel serveur possèdent deux profiles chacun indiquant le point d'accès correspondant au service désiré.
    Le point d'accès IIOP peut être supprimé pour un serveur n'acceptant que des connexions sécurisées.

    Lorsqu'un client CORBA obtient la référence IOR d'un objet ayant deux profiles (IIOP et SSLIOP) la connexion peut être établie selon l'un ou l'autre de ces profiles. L'interface ConnectPolicy permet au client de choisir un profil sécurisé ou non.

    Ci-apres, nous donnons le schéma des instructions a exécuter pour mettre en oeuvre un serveur Corba sécurisé. L'authentification de ce serveur repose sur le fait qu'un certificat a été généré préalablement, et placé dans les fichiers de nom siteRSA1024.der et caRSA1024.der.  Ces fichiers ont ete generes avec un programme  specifique, permettant de creer des certificats signes par nous-memes. Vous devez rapatrier ce programme.

    -----------------------------------------------------------------------------------
     Corba Server initialization with SSL
    -----------------------------------------------------------------------------------
        orb = ORB.init(args, new java,new java.util.properties());
        BOA boa = orb.BOA_init(args, new java.util.properties());

        // naming server is unsecure, so we have to connect here in an unsecure way
        // before SSL initializations
        ///// naming server connections - get object references

        // initializez the SSL pluggins
        com.ooc.SSL.SSL.init(orb, boa, args);
        com.ooc.SSL.Config ssl =com.ooc.SSL.ConfigHelper.narrow(
                                        orb.resolve_initial_references("SSLConfig");

        // get the certificates generated with Iaik
        // suppose they are accessible in the current directory
        String files = new String[2];
        files[0] = "siteRSA1024.der";
        files[1] = "caRSA1024.der";

        // set the certificates as a client if needed
        ssl.setCertificateAndKey(com.ooc.SSL.ConfigPackage.ServerOrClient.SET_CLIENT,
                                 files,
                                 "blabla");
        // set the certificate as a server if needed
        ssl.setCertificateAndKey(com.ooc.SSL.ConfigPackage.ServerOrClient.SET_SERVER,
                                 files,
                                 "blabla");

       // get current reference to SSL object
       static private  sslCurrent = com.ooc.SSL.CurrentHelper.narrow(
                                           orb.resolve_initial_reference("SSLCurrent");

       // we have to check the identity of the clients of the current server
       ssl.requestPeerCertificate(true);

       // create distributed objects and connect them with both IIOP & SSLIOP
       XXX xxx = new XXX(...);
       ((com.ooc.CORBA.ORB)orb).connect(xxx, <pid>);

       // run implementation
       orb.impl_is_ready();


 
  1. Services sous-jacents