Intégration d'un algorithme cryptographique symétrique dans OpenSSL et NSS

1. Introduction

Il existe plusieurs bibliothèques, mais seules [OpenSSL] et [NSS] sont abordées. Dans une première partie, nous reviendrons sur les besoins qui ont amené à créer la cryptographie asymétrique. En seconde partie, les deux bibliothèques seront présentées avant d'évoquer des rappels sur la cryptographie symétrique, qui sont nécessaires pour comprendre l'intégration de l'algorithme, aussi appelé un chiffre, en troisième et quatrième parties. Les cinquième et sixième parties sont consacrées à l'intégration dans OpenSSL et NSS. En pré-requis, des notions en langage C sont souhaitables.

Cet article ne traite ni du chiffre lui-même, ni du fonctionnement interne des bibliothèques et n'aborde pas non plus en détail le fonctionnement de SSL. Si vous souhaitez en apprendre davantage sur OpenSSL, vous pouvez vous référer à l'article « Comprendre l'architecture de la bibliothèque cryptographique OpenSSL » [MISC32].

2. La cryptographie symétrique et asymétrique

La cryptographie assure la confidentialité, l'authenticité et l'intégrité des messages. Elle recourt à des secrets qui sont bien souvent des clés. Son utilisation remonte à l'antiquité. Un célèbre exemple est le chiffre de César, en référence à Jules César, qui l'utilisait pour protéger ses communications. Mais la cryptographie est bien plus ancienne que cela. De nos jours, son utilisation s'est démocratisée par l'informatique.

On parle d'algorithme symétrique lorsque la même clé sert à chiffrer et déchiffrer un texte. On dit alors que c'est une clé symétrique qui peut être partagée. À titre d'exemple, si le monde utilisait uniquement de la cryptographie symétrique, aller sur des sites web sécurisés impliquerait une infrastructure lourde de distribution de clés symétriques à partager. Il faut utiliser un canal de confiance pour distribuer les clés : de main à la main sur un support physique, par exemple. Il ne serait pas raisonnable que le site web vous envoie sa clé directement en clair sur le réseau (c'est-à-dire sans la protéger) pour ensuite démarrer une session « sécurisée ». Cela n'aurait aucun sens, quiconque serait un intermédiaire sur le réseau entre vous et le site disposerait du secret et pourrait déchiffrer (lire) les informations qui transitent ; c'est l'attaque de l'homme du milieu. De plus, cette clé doit être jetable et non permanente. Si la clé était la même pour tout le monde, vous pourriez déchiffrer les communications d'une tierce personne. Ainsi, la clé doit être utilisée pour une session particulière. Problème : le site web devrait alors générer spécialement pour vous une clé et les deux parties devraient la conserver pour de futurs dialogues. Ce serait coûteux pour les machines qui hébergent un site d'envergure si elles devaient être amenées à conserver toutes les clés de leurs clients. Sans oublier que l'on retomberait dans le problème de distribution de clés.

C'est pourquoi, au cours des années 1970, la cryptographie asymétrique a été mise au point par Whitfield Diffie et Martin Hellman. Le principe de fonctionnement ne repose pas sur une clé partagée, mais sur une paire de clés privée et publique. La seconde est dérivée de la première et peut être distribuée à n'importe qui, y compris sur un canal en clair. En revanche, la première doit rester secrète. Un texte est chiffré par la clé publique et déchiffré par la clé privée, ce qui assure la confidentialité du texte. Ce n'est pas le seul rôle de la clé privée, qui peut signer numériquement un document. La signature est vérifiée par la clé publique, ce qui garantit l'authenticité. La cryptographie asymétrique est adaptée pour des connexions venant d'horizons multiples (cas d'un serveur web), mais elle demande une grosse puissance de calcul. RSA (Rivest Shamir Adleman) [RSA], un algorithme asymétrique, est environ 1000 fois plus lent qu'un chiffre symétrique comme le DES (Data Encryption Standard) [DES]. C'est pourquoi on utilise souvent la cryptographie asymétrique pour débuter le dialogue entre deux machines et établir une connexion sécurisée. On génère un nombre aléatoire qui devient la clé secrète. Cette clé symétrique et dite de session (comprendre jetable) est utilisée pour poursuivre les échanges et alléger la charge des calculs.

C'est ici que l'algorithme symétrique qui va être intégré dans les bibliothèques entre en scène.

3. Présentation des deux bibliothèques

3.1 OpenSSL

OpenSSL comporte un outil en ligne de commandes et deux bibliothèques. La première traite de cryptographie générale et la seconde implémente le protocole SSL/TLS. Les bibliothèques sont écrites en langage C et implémentent les fonctions basiques de cryptographie. Elles peuvent être utilisées au travers de nombreux langages de programmation. Les objectifs d'OpenSSL sont la mise en œuvre de SSL (Secure Socket Layer). SSL, dans ses dernières versions, a été renommé TLS (Transport Layer Security) [TLS]. C'est un abus de langage récurrent de mentionner SSL en faisant allusion à TLS. SSL/TLS vise à sécuriser le protocole réseau TCP/IP et agit à la couche session du modèle OSI (Open Systems Interconnection, Interconnexion de systèmes ouverts), pour des applications spécifiques.

Parmi les standards cryptographiques relatifs à SSL/TLS dans OpenSSL, nous pouvons citer (liste non exhaustive) :

- le chiffrement symétrique : AES (Advanced Encryption Standard) [AES], DES, Triple DES [3DES], [CAMELLIA], [SEED] ;

- le chiffrement asymétrique : RSA, DSA (algorithme de signature numérique, Digital Signature Algorithm) [DSA] ;

- l'encodage : Base64 [BASE64] ;

- le hachage : [MD5], SHA-1 [SHA1] ;

- les certificats X.509 [X509] ;

- le protocole d'échange de clés : Diffie-Hellman ;

- les standards PKCS.

Les bibliothèques associées à OpenSSL sont disponibles pour de nombreuses plateformes telles que : la famille BSD, Linux, Mac OS X et Microsoft Windows. OpenSSL est basé sur SSLeay d'Eric Young et Tim Hudson. Il est sous double licence : la licence OpenSSL et la licence initiale, SSLeay. Cette bibliothèque est utilisée par de nombreuses applications, comme OpenSSH, Apache+mod_ssl, Postfix ou OpenVPN.

3.2 NSS

NSS (Network Security Services) est une bibliothèque cryptographique développée par Mozilla. Elle est disponible sous triple licence : la Mozilla Public License, la GNU General Public License (GPL) et la GNU Lesser General Public license (LGPL). De même qu'OpenSSL, NSS vise à permettre le déploiement de programmes sécurisés à la fois côté client et côté serveur. Cette bibliothèque est née des cendres des bibliothèques de Netscape, l'inventeur du protocole SSL. NSS prend en charge le PKCS #11, une API qui définit une interface générique pour les périphériques cryptographiques pour l'accélération matérielle et les cartes à puce.

Parmi les logiciels qui utilisent NSS, citons :

- les produits Mozilla tels que Firefox et Thunderdird ;

- le navigateur web Google Chrome dans sa version Linux ;

- le module NSS pour Apache ;

- des produits serveurs de Redhat, Sun/Oracle.

4. Quelques rappels autour de la cryptographie symétrique

Ces rappels sont primordiaux pour avoir les notions nécessaires à l'intégration du chiffre dans les bibliothèques. Nous commencerons par distinguer les deux familles de chiffrement : par flot et par bloc, puis nous évoquerons les OID (Object Identifier). Le chiffre qui va être intégré est de type chiffrement par bloc.

4.1 Le chiffrement par flot

Les données sont traitées en flux continu, c'est-à-dire qu'il n'y a ni besoin de lire le message, ni d'avoir sa longueur pour commencer à chiffrer. Pratique plutôt utile pour les réseaux sans fil comme la téléphonie mobile, le WiFi ou le Bluetooth. Les performances des chiffres par flux sont très bonnes en matériel et en logiciel, mais présentent des problèmes de sécurité.

Exemple de chiffrements par flot :

- RC-4, le plus répandu. Conçu en 1987, il est utilisé par le protocole WEP du WiFi ;

- A5/1 publié en 1994, utilisé dans la téléphonie mobile GSM.

4.2 Le chiffrement par bloc

L'AES, le DES et sa variante Triple DES, le Camellia ou encore le SEED, ne sont qu'un exemple des nombreux algorithmes cryptographiques symétriques par bloc. L'Institut national des standards et de la technologie (National Institute of Standards and Technology, NIST) est une agence du Département du Commerce des États-Unis. Au début des années 2000, il organise un concours dont le but est d'élire un nouveau chiffre de référence pour remplacer le vieillissant DES. Le DES est facilement cassable, principalement en raison d'une taille de clé trop petite de 56 bits. Il est de ce fait très sensible aux attaques par force brutale. Ces attaques consistent à tester toutes les combinaisons possibles. À la fin du concours organisé par le NIST, l'AES est déclaré vainqueur. On le retrouve aujourd'hui partout où il y a besoin de chiffrement par bloc.

Un algorithme par bloc ne chiffre qu'un nombre précis d'octets. L'AES, indépendamment de sa longueur de clés (qui peut être de 128, 192 ou 256 bits), chiffre 128 bits (16 octets) de données ; ce qui constitue un bloc (pour rappel, 1 octet = 8 bits). Pour chiffrer des informations de taille bien plus importante, le texte en clair est découpé en blocs de taille fixe : 16 octets. Si le dernier bloc est de taille inférieure à 16 octets, des bits de bourrage ou padding sont ajoutés. Le chiffre est ensuite itéré sur chaque bloc de données entrantes. En sortie, le texte chiffré est de même longueur que le texte en clair en entrée+padding. Lors de la transition de texte en clair à texte chiffré, les blocs ont été manipulés entre eux par un mode opératoire. Il existe plusieurs modes opératoires, tels que :

- ECB, Electronic codebook ou Dictionnaire de codes ;

- CBC, Cipher Block Chaining ou Enchaînement des blocs ;

- CFB, Cipher Feedback ou Chiffrement à rétroaction ;

- OFB, Output Feedback ou Chiffrement à rétroaction de sortie ;

- CTR, CounTeR ou Chiffrement basé sur un compteur ;

pour ne citer que ceux-là. Ces modes opératoires sont les mêmes pour tous les chiffres par bloc. Ils ne sont pas liés à un chiffre précis. Lors de l'intégration du chiffre dans les bibliothèques, vous retrouverez des occurrences de ces modes dans les codes sources. Pour cet article, nous nous intéresserons principalement aux deux premiers.

4.2.1 Le mode ECB (Electronic codebook)

Le mode ECB est le plus simple, mais aussi le plus naïf. Les blocs sont chiffrés les uns après les autres. La concaténation du bloc  jusqu'au bloc_n forme le texte chiffré.

Avec cette méthode, un bloc du texte en clair sera chiffré dans le même bloc correspondant au texte chiffré. Ce qui implique qu'en cherchant des séquences identiques, on peut établir des correspondances entre texte en clair et texte chiffré. Dès lors, on obtient un dictionnaire, d'où le nom de la méthode : codebook (dictionnaire de codes).

Exemple sur du texte [EX_ECB] :

On chiffre les deux messages suivants avec un mode ECB et un algorithme de chiffrement par bloc qui travaille avec un bloc de deux caractères à la fois. Ce type de fichier pourrait correspondre à une liste de salaires.

Le chiffrement sur le premier message donne ceci :

Et sur le deuxième message, on obtient :

On constate que des paires de caractères apparaissent dans les deux messages chiffrés, il en va de même dans les messages en clair :

En partant du principe que John connaît son salaire, il pourrait deviner le salaire de Jack, car la séquence C9 correspond à 50 et IO à 00. John en déduit que le salaire de Jack, chiffré en C9IOIO correspond à 500000.

Le mode ECB est déconseillé. Il est préférable d'utiliser le mode CBC.

4.2.2 Le mode CBC (Cipher Block Chaining)

En mode CBC, chaque bloc de texte en clair est xoré (opération qui consiste à faire un « ou-exclusif ») avec le bloc chiffré précédent avant d'être chiffré.

Pour pouvoir chiffrer le premier bloc, celui-ci doit être xoré avec un vecteur d'initialisation (Initialisation vector, IV) qui fait la taille d'un bloc. L'IV n'a pas besoin d'être tenu secret et est requis pour pouvoir déchiffrer. Tous les modes (sauf l'ECB) ont recours au vecteur d'initialisation qui introduit une forme de hasard. Il ne doit jamais être réemployé avec la même clé.

À noter : si un seul bit est modifié entre une version et une autre d'un texte en clair, alors le résultat chiffré diffère complètement. De la même façon, si un bit est changé dans un texte chiffré, alors le résultat déchiffré est un texte corrompu qui n'a plus aucun rapport avec le texte en clair initial.

4.2.3 Différence entre ECB et CBC en image

Une image vaut souvent mieux qu'un long discours et c'est d'autant plus vrai en cryptographie. Une image est constituée de nombreuses redondances qui en font des blocs chiffrés de la même façon en ECB. En revanche, en CBC, l'information est à première vue plus difficile à obtenir. L'utilisation d'un mode opératoire plutôt qu'un autre ne rend pas un chiffre meilleur s'il est reconnu comme vulnérable.

4.3 Les OID

L'Object IDentifier [OID] est un identifiant unique qui peut référencer (liste non exhaustive) :

- une recommandation ITU-T, un standard ISO international ;

- un pays, une entreprise, un projet ;

- un format de fichier ;

- un module ASN.1, un type ASN.1 ;

- un attribut X.500/LDAP ;

- un certificat X.509 ;

- un algorithme de chiffrement.

Utilisés depuis 1985, sur le principe d'un arbre, les OID sont identifiés par leur chemin depuis la racine jusqu'à un nœud et sont largement déployés dans le commerce en ligne. Ils peuvent être lus dans :

- une notation humaine : {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)} ;

- une notation à points : 1.2.840.113549.1 ;

- une notation URN : urn:oid:1.2.840.113549.1;

- une notation internationalisée (IRI) : oid:/ISO/Member-Body/US/RSADSI/PKCS.

Chaque algorithme de chiffrement a son propre OID. Chacun de ses modes opératoires est une déclinaison de l'OID du chiffre, ce qui en fait un nœud supplémentaire.

Lorsque deux bibliothèques discutent entre elles, l'OID est une base de connaissances communes mises à contribution. Exemple : vous envoyez un courriel et vous le chiffrez avec S/Mime, il contiendra l'identifiant du chiffre qui a servi à chiffrer. Si le récepteur connaît cet OID, il sera en mesure de pouvoir déchiffrer en sélectionnant le chiffre approprié (au sens code source).

5. Le chiffre à intégrer

L'algorithme à intégrer est une copie du SEED, développé par l'agence de sécurité de l'information coréenne (Korea Information Security Agency, KISA). Son utilisation dépasse rarement la frontière de la Corée du Sud. Le SEED est un algorithme de chiffrement reconnu par l'ISO.

Pour l'intégration, le SEED sera copié et la copie sera nommée MYC (pour MY Cipher). Pourquoi le SEED et pas un autre chiffre ? Nous aurions pu intégrer l'AES, par exemple, mais parce qu'il y a beaucoup d'optimisations et une intégration profonde, sa compréhension n'est pas évidente. En revanche, un algorithme comme le Camellia - développé conjointement par Mitsubishi et Nippon Telegraph and Telephone (NTT) - ou le SEED sont plus accessibles. Tout comme l'AES, le Camellia a une taille de bloc de 128 bits et plusieurs longueurs de clés possibles : 128, 192 et 256 bits. Le SEED a une taille de bloc et une longueur de clés de 128 bits (16 octets). Parce que le SEED n'a qu'une seule taille de clé possible, l'intégration de sa copie sera plus simple.

Définition des OID fictifs qui serviront pour OpenSSL et NSS :

6. Intégration dans OpenSSL

La version d'OpenSSL utilisée pour l'intégration est la version 0.9.8o. Le système d'exploitation utilisé est GNU/Linux Debian Lenny.

6.1 Fichiers à modifier

Où commencer ? S'aventurer au sein d'une bibliothèque cryptographique peut paraître périlleux. Doit-on explorer la bibliothèque de fond en comble pour comprendre comment elle fonctionne avant de pouvoir modifier le code ? Non. La bibliothèque est conçue de façon à permettre l'ajout de chiffres sans douleur. Il y a cependant certaines étapes délicates. Une technique simple consiste à effectuer une recherche sur un chiffre déjà intégré. La liste de fichiers retournée constitue une première base de travail.

Effectuons la recherche en prenant le Camellia en critère et non le SEED. Seed est un mot courant en cryptographie et signifie graine en anglais. Le sélectionner en critère de recherche provoquerait des faux-positifs.

La commande retourne les fichiers où le mot Camellia apparaît. Seuls les fichiers dont une modification est nécessaire pour avoir une intégration fonctionnelle du chiffre sont conservés. Parmi les réponses supprimées, on peut citer : des liens symboliques, des fichiers qui concernent seulement le Camellia, de la documentation, des fichiers à ne pas modifier car ils sont générés automatiquement par des scripts, des Makefiles et autres fichiers de configuration dont le but est de permettre la (dés)activation de chiffres. Un algorithme comme le Camellia ou le SEED sont désactivés par défaut. En ce qui nous concerne, nous allons considérer que notre chiffre est très important et l'activer par défaut.

Que peut-on constater à la lecture des fichiers retournés ? Dans un premier temps, la présence des fichiers marqués en rouge attire l'œil. Le dossier crypto recense l'ensemble des chiffres dans un dossier qui leur est propre. Le chiffre est, pour le Camellia, dans le fichier camellia.c. C'est lui qui chiffre et déchiffre un bloc. Il est accompagné de modes opératoires qui sont dans des fichiers séparés. Le sous-dossier evp contient un fichier par chiffre (AES, Camellia, SEED, ...), par hash (md5, sha1, ...), etc. Evp est la contraction d'EnVeloPe. Pour chiffrer un texte, soit on fait appel directement aux fonctions des chiffres, soit on fait appel à des fonctions d'un niveau plus haut comme le permettent les fonctions EVP_EncryptInit(), EVP_EncryptUpdate(), EVP_EncryptFinal(). Plus d'informations à ce sujet dans le [MISC32].

L'intégration du chiffre consiste la plupart du temps à copier/coller les autres chiffres. Par exemple, dans le cas d'un switch, il faut ajouter un case MYC:. Un cas de copier/coller sera traité pour montrer l'exemple. Cependant, il y a quelques intégrations qui demanderont une attention particulière.

6.2 Intégrations simples

La première étape consiste à copier le dossier crypto/seed en crypto/myc et d'y opérer les renommages nécessaires de SEED vers MYC. Que ce soient les fichiers eux-mêmes :

ou leur contenu :

Même chose, copie du fichier crypto/evp/e_seed.c en e_myc.c et substitution du contenu :

La suite paraît moins évidente. Reprenons la liste des fichiers et traitons-les un par un. Commençons par apps/cms.c :

Le code en rouge est ce qui est à ajouter. Ceci est un exemple des copier/coller à effectuer. Je recommande de copier le code de MYC en dessous de SEED de façon à rapidement voir si un copier/coller a déjà été fait. À force de rechercher sur les chaînes « SEED » et « seed », l'ensemble du code d'OpenSSL se ressemble et il est bon d'avoir quelques repères. Il faut un peu de rigueur et s'y tenir pour ne pas s'y perdre. De plus, les remplacements globaux avec sed sont à oublier. Je recommande de le faire à la main. L'utilisation de sed un peu plus tôt était justifiée car nous voulions remplacer les occurrences de SEED et non ajouter un chiffre aux côtés de SEED.

De la même façon que pour apps/cms.c, procédez à l'ajout de MYC dans la bibliothèque en opérant des copier/coller. Mais certains fichiers méritent qu'on s'y attarde un peu plus.

6.3 Intégrations complexes

Ce paragraphe invite le lecteur à prêter attention à des zones d'intégration sur des fichiers particuliers. Cependant, ce sont uniquement des mises en évidence qui ne dispensent pas de faire les insertions comme au paragraphe « Intégrations simples ».

6.3.1 openssl-0.9.8o/apps/speed.c

Jusqu'à présent, nous collions le MYC au plus près de SEED, mais il y a des cas où il vaut mieux ajouter le MYC à la fin d'une liste pour éviter les erreurs d'indice.

C'est pourquoi, malgré les centaines de lignes qui peuvent séparer deux codes correspondants, il faut veiller à placer le MYC au bon endroit dans la liste, lui attribuer le bon numéro correspondant (ici, le 28) et ne pas oublier de mettre à jour le nombre total d'algorithmes qui passe de 28 à 29, ligne 291.

6.3.2 openssl-0.9.8o/crypto/evp/evptests.txt

Ce fichier contient les vecteurs de tests des chiffres. Ces vecteurs sont fournis par le ou les cryptologues qui conçoivent les chiffres. Un test est composé d'une clé, d'un IV (sauf pour l'ECB), d'un bloc de texte en clair et d'un bloc de texte chiffré. Le test est validé dès lors que le texte chiffré obtenu à partir du texte en clair est celui attendu. Même chose pour le déchiffrement.

Ici, le SEED fournit des vecteurs de tests uniquement pour le mode ECB. Copiez-les pour le MYC.

6.3.3 openssl-0.9.8o/crypto/evp/Makefile

Les lignes suivantes n'ont pas besoin d'être dupliquées :

6.3.4 openssl-0.9.8o/crypto/objects/objects.txt

Ici, il faut renseigner les OID de MYC définis au paragraphe « Le chiffre à intégrer ».

6.3.5 openssl-0.9.8o/crypto/objects/obj_mac.num

Le plus simple ici est d'ajouter les quatre modes opératoires du MYC en fin de fichier. L'indice correspond parfaitement avec le numéro de lignes.

6.3.6 openssl-0.9.8o/makevms.com

L'ajout du NO_MYC n'est pas à faire ici pour ne pas le désactiver. En revanche, d'autres parties sont à copier/coller.

6.3.7 openssl-0.9.8o/ssl/s3_lib.c

Copiez le MYC à la suite du SEED. Vous pouvez constater qu'en commentaire, le SEED a été numéroté. Faites-en autant pour le MYC en numérotant de 100 à 105. Ces références seront à reporter plus loin.

6.3.8 openssl-0.9.8o/ssl/ssl_ciph.c

Ne pas oublier d'incrémenter le nombre d'indice de 12 à 13 après avoir ajouté le MYC.

6.3.9 openssl-0.9.8o/ssl/ssl.h

Lors de la mise en œuvre d'un tunnel TLS, le MYC est prioritaire sur les autres chiffres.

6.3.10 openssl-0.9.8o/ssl/ssl_locl.h

6.3.11 openssl-0.9.8o/ssl/tls1.h

C'est ici que l'on reporte les numéros entrés dans ssl/s3_lib.c :

6.3.12 openssl-0.9.8o/util/libeay.num

Tout comme pour crypto/objects/obj_mac.num, ajoutez le MYC à la fin.

6.4 Compilation et tests de validation

Commençons par récupérer les dépendances qui sont nécessaires pour compiler : aptitude build-depends openssl, puis procédons à la compilation. En temps normal, un chiffre comme le MYC serait désactivé par défaut d'OpenSSL et à la compilation, il faudrait explicitement l'activer. Mais puisqu'il a été activé par défaut lors de l'intégration, pour compiler, il suffit de lancer ./config suivie de make.

S'il y a une erreur lors du make, reprenez l'intégration et vérifiez l'ensemble des fichiers. Faites vos recherches dans les fichiers en ne prenant pas compte de la casse. Si vous désespérez, munissez-vous du fichier patch qui intègre le MYC [OPENSSL_MYC_DIFF] et appliquez-le aux sources patch -p0 < OpenSSL-0.9.8o_add_myc_cipher.patch

Lorsque la compilation se déroule correctement, c'est encourageant, mais ce n'est pas encore fini. OpenSSL est muni d'une batterie de tests pour tester la génération de certificats, SSL/TLS ou le chiffrement/déchiffrement. Pour ce dernier, parmi les tests effectués, les vecteurs de tests sont utilisés pour vérifier que les chiffres fonctionnent conformément à ce que les cryptologues ont prévu.

Lancez make test pour tester l'intégration par la batterie de tests.

6.5 Création des paquets

Si le make test est bon, il ne reste plus qu'à créer un paquet de notre OpenSSL modifié. Il convient de faire un paquet plutôt que de faire un make install sauvage qui pourrait avoir de mauvaises conséquences. Si vous installez la bibliothèque sauvagement, votre gestionnaire de paquets ne saura pas qu'elle est installée et les fichiers risquent d'être installés aux mauvais endroits. Le jour où vous déciderez d'installer une application qui dépend d’OpenSSL (postfix par exemple) et en supposant que les fichiers sont installés aux bons endroits, le gestionnaire de paquets ira chercher OpenSSL dans les dépôts et écrasera votre travail. Si vous aviez fait un paquet, la dépendance serait déjà satisfaite. Procéder à la création de paquets est la manière correcte et propre de faire.

Le processus complet de création de paquets ne sera pas traité ici. Vous pouvez vous référer au Guide du nouveau responsable Debian [RESP_DEBIAN]. Pour poursuivre les tests, j'invite le lecteur à se créer son propre paquet ou récupérer le patch qui permet la création du paquet [OPENSSL_DEB_DIFF] et l'appliquer aux sources :

L'application du patch Packaging_Debian_Lenny_OpenSSL-0.9.8o_MYC.patch est à appliquer après avoir intégré le chiffre à la main ou avoir déjà appliqué le patch OpenSSL-0.9.8o_add_myc_cipher.patch aux sources. Le patch de packaging effectue des modifications dans des fichiers Makefile et Configure pour que la bibliothèque s'intègre à l'environnement Debian. Un dossier debian est créé dans le répertoire des sources et contient tous les fichiers nécessaires à la création du paquet.

Parmi les nouveaux fichiers créés, debian/rules contient toutes les directives nécessaires pour la compilation de la bibliothèque. Sa création par le programme patch ne permet pas de lui attribuer les droits d'exécution dont il a besoin. Il faut les rétablir. De plus, pour créer le paquet, nous avons besoin de récupérer des dépôts l'outil fakeroot qui lance des commandes dans un environnement simulant les privilèges du super utilisateur. Enfin, créons le paquet :

Les paquets fournis par les distributions sont signés. À notre niveau, nous ne pouvons pas signer les paquets produits. C'est pourquoi à l'issue de la création des paquets, vous verrez apparaître des avertissements.

Fichiers générés [OPENSSL_MYC_PKG] :

6.6 Déploiement des paquets

6.6.1 Installation

Sur une Debian fraîchement installée, le paquet openssh-client est installé par défaut. Ses dépendances sont aussi installées, dont libssl0.9.8, qui appartient à OpenSSL. Pour installer vos nouveaux paquets, vous ne pouvez pas les récupérer des dépôts, mais vous pouvez utiliser une clé USB, wget ou scp.

Il n'y a pas besoin de tout installer, mais nous allons tout de même le faire pour voir s'il n'y a pas de problème. Le gestionnaire de paquets ne peut pas aider pour résoudre les dépendances. Il faut installer zlib1g-dev, dont le paquet libssl-dev a besoin.

6.6.2 Vérifications

Le gestionnaire a-t-il pris en compte les nouveaux paquets ?

OpenSSL et sa bibliothèque sont correctement installés.

7. Intégration dans NSS

7.1 Préambule

L'intégration dans OpenSSL se basait sur une version upstream. Pour NSS, nous utiliserons la version 3.12.3.1 modifiée par Debian dans Lenny, qui intègre les mises à jour de sécurité et les corrections pour l'intégration au système. Cette intégration suppose que vous disposez d'une Debian Lenny fraîchement installée.

Comme OpenSSL, nous allons rechercher le Camellia sur l'ensemble de la bibliothèque. Avant cela, il faut récupérer les sources et prendre les dépendances nécessaires à la compilation.

Suite au téléchargement des sources, un dossier nss-3.12.3.1 est créé. En sous-répertoires : debian et mozilla. Ce dernier contient les sources de la bibliothèque, tandis que le premier est dédié à la création des paquets. Le dossier debian/patches recense tous les correctifs ajoutés par le mainteneur du paquet. Ces correctifs peuvent être pour mieux intégrer la bibliothèque au système (où l'installer, options de compilation choisies par le mainteneur) ou des correctifs de sécurité dont la bibliothèque a pu faire l'objet lors de rapports de bogues.

Les correctifs sont appliqués dans un ordre précis. Les modifications du dernier patch prennent en compte les modifications faites par les patches précédents. C'est pourquoi, afin de créer notre correctif, celui qui intègre le MYC aux sources de NSS, il faut d'ores et déjà avoir appliqué les patches antérieurs. Le fichier debian/patches/00list définit l'ordre des patches, fichier auquel il faudra ajouter à la fin notre correctif.

Le fichier NSS_Debian_patches.diff [NSS_DEB_DIFF] fournit l'ensemble des correctifs utilisés par Debian depuis la version originale pour arriver jusqu'à ma version de travail. Cette version est celle pour laquelle le MYC est intégré. Pour ceux qui souhaiteraient partir de la version originale, seules quelques lignes seront différentes.

Bien que nous dupliquions le SEED, je juge l'intégration du Camellia meilleure que le SEED. De ce fait, nous copions le SEED, mais en nous inspirant du Camellia.

7.2 Fichiers à modifier

Le chiffre et les modes opératoires sont dans le fichier camellia.c (idem pour seed.c). À noter qu'il n'y a que deux modes opératoires dans NSS : ECB et CBC. Dupliquez les fichiers seed.* en myc.* et substituez les occurrences du SEED par MYC avec sed.

Les vecteurs de tests sont à créer à partir des fichiers du SEED :

- nss-3.12.3.1/mozilla/security/nss/cmd/bltest/tests/myc_ecb ;

- nss-3.12.3.1/mozilla/security/nss/cmd/bltest/tests/myc_cbc.

7.3 Intégrations complexes

7.3.1 mozilla/security/nss/cmd/lib/pk11table.c

Il n'y a pas d'entrée avec CKK_SEED, mais il y en a une pour CKK_CAMELLIA. Ajoutons CKK_MYC. Le reste du fichier est à faire comme le SEED, en ajoutant les entrées CKM.

7.3.2 mozilla/security/nss/cmd/modutil/pk11.c

Le SEED est absent, mais on ajoute le MYC en prenant exemple sur le Camellia.

7.3.3 mozilla/security/nss/cmd/ssltap/ssltap.c

Ces valeurs sont les mêmes que celles inscrites pour OpenSSL.

7.3.4 mozilla/security/nss/cmd/symkeyutil/symkeyutil.c

Le SEED est absent, mais on ajoute le MYC en prenant exemple sur le Camellia.

7.3.5 mozilla/security/nss/lib/freebl/manifest.mn

Le dossier freebl recense les chiffres de la bibliothèque. Le fichier manifest.mn définit les fichiers à compiler. Au premier abord, l'intégration est très simple, puisqu'il suffit d'ajouter myc.c et myc.h. Il faut cependant faire attention à ne pas ajouter involontairement des caractères inutiles, comme des espaces en fin de ligne, qui provoqueraient une erreur à la compilation.

7.3.6 mozilla/security/nss/lib/pk11wrap/debug_module.c

Le SEED est absent, mais on ajoute le MYC en prenant exemple sur le Camellia.

7.3.7 mozilla/security/nss/lib/pk11wrap/secmod.h

Ces flags (drapeaux) sont visibles depuis les autres bibliothèques. Prenez exemple sur les autres entrées.

Veillez à rendre mozilla/security/nss/lib/softoken/secmodt.h cohérent avec ce fichier.

7.3.8 mozilla/security/nss/lib/ssl/ssl3con.c

Attention, les déclarations de chiffres effectuées ici doivent être cohérentes avec sslenum.c. Ici, il vaut mieux s'inspirer de l'intégration du Camellia plutôt que de celle du SEED.

7.3.9 mozilla/security/nss/lib/ssl/sslenum.c

Il est expliqué en commentaires que la priorité des chiffres est définie ici. Les chiffres sont listés dans l'ordre suivant :
- les chiffres les plus forts sont avant les plus faibles ;
- les chiffres nationaux sont avant les chiffres internationaux ;
- les chiffres les plus rapides sont avant les chiffres les plus lents.

C'est pourquoi des chiffres nationaux comme le Camellia sont listés avant les chiffres internationaux comme l'AES ou le RC4. Sinon, lorsqu'un client et un serveur négocieraient le chiffre à utiliser, les internationaux seraient toujours utilisés. Ceci permet d'utiliser le Camellia ou le MYC sans devoir désactiver l'AES.

L'ordre de ssl3con.c est à respecter.

Les chiffres qui utilisent des clés de 256 bits sont en première position, c'est pourquoi le SEED est derrière, avec sa clé de 128 bits. Pour la démonstration uniquement, le MYC est à placer en tête de liste. Il devient alors le chiffre le plus important.

7.3.10 mozilla/security/nss/lib/ssl/sslimpl.h

Ne pas oublier d'incrémenter le compteur du nombre de chiffres utilisables :

Nous avons ajouté 3 méthodes pour SSL : DHE_RSA, DHE_DSS et RSA dans sslenum.c et ssl3con.c, d'où le passage à 53 et 33.

7.3.11 mozilla/security/nss/lib/ssl/sslinfo.c

S'inspirer du Camellia.

7.3.12 mozilla/security/nss/lib/ssl/sslproto.h

Attention à rester cohérent avec ce qui a été entré dans mozilla/security/nss/cmd/ssltap/ssltap.c et de la même façon, avec openssl-0.9.8o/ssl/tls1.h :

7.3.13 mozilla/security/nss/lib/ssl/sslsock.c

S'inspirer du Camellia_256 plutôt que du SEED :

Imitez les autres chiffres :

7.3.15 mozilla/security/nss/lib/util/secoid.c

Il faut entrer l'OID du MYC sous forme hexadécimale (défini au paragraphe « Le chiffre à intégrer »), mais sans le mode opératoire, qui est à renseigner un peu plus loin, ce qui donne :

Il faut veiller à respecter la concordance d'informations entre ce fichier et secoidt.h, comme expliqué en commentaires, mille lignes plutôt au début du tableau. Pour éviter tout problème, on ajoutera le MYC après le SEED, c'est-à-dire à la fin du tableau.

7.4 S/Mime

Si vous souhaitez aller encore plus loin dans l'intégration et utiliser le MYC pour chiffrer le contenu de vos courriels (S/Mime ne chiffre pas les en-têtes, l'objet du courriel reste en clair), les fichiers suivants sont à modifier :

- mozilla/security/nss/lib/pkcs7/secmime.c ;

- mozilla/security/nss/lib/smime/smimeutilc.c ;

- mozilla/security/nss/lib/util/ciferfam.h.

L'utilisation du Triple-DES (3DES) est codé en dur dans NSS. Il n'y pas de choix possible. Pour utiliser le MYC, il faudra à votre tour le coder en dur.

Exemple dans smimeutil.c :

7.5 Création des paquets

Créez le fichier diff entre votre version de la libnss et celle avec les patches de Debian appliqués. Ce diff est à faire sans le sous-dossier debian qui provient des sources du dépôt. Transformez le fichier diff en un fichier dpatch et ajoutez-le à la liste des patches à appliquer aux sources non modifiées de la libnss.

Il ne reste plus qu'à mettre une entrée au fichier debian/changelog et de lancer la procédure de création de paquets : dpkg-buildpackage.

Pour sauter l'étape manuelle d'intégration du MYC, servez-vous du fichier [NSS_MYC_DIFF] ou directement le fichier [NSS_MYC_DPATCH] ou encore les binaires [NSS_MYC_PKG].

Conclusion

Si jusqu'à aujourd'hui, vous utilisiez les bibliothèques cryptographiques sans avoir la moindre idée de leur fonctionnement, vous devriez à présent en avoir une meilleure idée. L'intégration du MYC était l'occasion d'aborder le fonctionnement global d'un chiffre symétrique par bloc. Son intégration a permis d'explorer les bibliothèques cryptographiques, de voir à quoi elles ressemblent et d'avoir une meilleure idée de leurs structures. Vous l'avez remarqué, NSS utilise seulement 2 modes opératoires : l'ECB et le CBC. Si vous recherchez un peu plus de difficultés, amusez-vous dans OpenSSL à intégrer uniquement ces deux modes pour le MYC. Vous verrez que cela complique un peu la tâche. Vous pourriez aussi écrire votre propre chiffre dans un but purement pédagogique et l'intégrer.

Exceptés quelques endroits où il faut faire attention, globalement, un chiffre s'insère en douceur dans ces deux bibliothèques, la plupart des opérations consistant à copier l'existant.

Références

[OPENSSL] OpenSSL: The Open Source toolkit for SSL/TLS, http://www.openssl.org

[NSS] Mozilla, Network Security Services (NSS), http://www.mozilla.org/projects/security/pki/nss/

[MEO_MYC] G.Bellier, « Mise en œuvre d'un algorithme cryptographique symétrique dans OpenSSL et NSS », GNU/Linux Magazine France n°135, Février 2011

[MISC32] A.Apvrille, « Comprendre l'architecture de la bibliothèque cryptographique OpenSSL », MISC n°32, Juillet-Août 2007

[RSA] J. Jonsson, B. Kaliski, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography, RFC 3447, Février 2003, http://www.ietf.org/rfc/rfc3447.txt

[DSA] National Institute of Standards and Technology, Digital Signature Standard, FIPS PUB 186, Mai 1994

[TLS] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, Août 2008, http://www.ietf.org/rfc/rfc5246.txt

[CAMELLIA] M. Matsui, J. Nakajima, S. Moriai, A Description of the Camellia Encryption Algorithm, RFC 3713, Avril 2004, http://www.ietf.org/rfc/rfc3713.txt

[SEED] H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee, The SEED Encryption Algorithm, RFC 4269, Décembre 2005, http://www.ietf.org/rfc/rfc4269.txt

[DES] National Institute of Standards and Technology, Data Encryption Standard (DES), FIPS PUB 46-3, Octobre 1999.

[3DES] National Institute of Standards and Technology, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, NIST Special Publication 800-67, Mai 2004.

[AES] National Institute of Standards and Technology, The Advanced Encryption Standard, Novembre 2001, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

[BASE64] S. Josefsson, The Base16, Base32, and Base64 Data Encodings, RFC 3548, Juillet 2003, http://www.ietf.org/rfc/rfc3548.txt

[MD5] R. Rivest, The MD5 Message-Digest Algorithm, RFC 1321, Avril 1992, http://www.ietf.org/rfc/rfc1321.txt

[SHA1] D. Eastlake, 3rd, US Secure Hash Algorithm 1 (SHA1), RFC 3174, Septembre 2001, http://www.ietf.org/rfc/rfc3174.txt

[X509] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280, Mai 2008, http://www.ietf.org/rfc/rfc5280.txt

[OID] Plus d'informations sur les OID, http://www.oid-info.com/faq.htm

[SMIME_3DES] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, S/MIME Version 2 Message Specification, RFC 2311, Mars 1998, http://www.ietf.org/rfc/rfc2311.txt

[RESP_DEBIAN] DEBIAN, Guide du nouveau responsable Debian, http://www.debian.org/doc/maint-guide/index.fr.html

[EX_ECB] Wikipédia, Mode d'opération (cryptographie), http://fr.wikipedia.org/wiki/Mode_d'opération_(cryptographie)

[OPENSSL_MYC_DIFF] G.Bellier, patch qui intègre le MYC pour OpenSSL 0.9.8o, http://.../openssl/diffs/OpenSSL-0.9.8o_add_myc_cipher.patch

[OPENSSL_DEB_DIFF] G.Bellier, patch qui intègre les ajouts pour la création du paquet Debian, http://.../openssl/diffs/Packaging_Debian_Lenny_OpenSSL-0.9.8o_MYC.patch

[OPENSSL_MYC_PKG] G.Bellier, paquets compilés d'OpenSSL 0.9.8o pour Debian Lenny 32 bits, http://.../openssl/packages/

[NSS_DEB_DIFF] G.Bellier, patch qui intègre les ajouts pour la sécurité et pour la création du paquet Debian de NSS. Mise à niveau vers version de travail pour bonne application du patch [NSS_MYC_DIFF], http://.../nss/diffs/Packaging_Debian_Lenny_NSS-3.12.3.1.diff

[NSS_MYC_DIFF] G.Bellier, patch qui intègre le MYC pour NSS 3.12.3.1 au format diff, http://.../nss/diffs/NSS_3.12.3.1_MYC_cipher.diff

[NSS_MYC_DPATCH] G.Bellier, patch qui intègre le MYC pour NSS 3.12.3.1 au format dpatch, http://.../nss/diffs/99_myc_cipher.dpatch

[NSS_MYC_PKG] G.Bellier, paquets compilés de NSS avec le MYC intégré pour Debian Lenny 32 bits, http://.../nss/packages/

Les sources et paquets binaires en rapport avec cet article sont disponibles via http://www.gnulinuxmag.com/GLMF/OpenSSL_GLMF135.tar.gz