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

Magazine
Marque
GNU/Linux Magazine
Numéro
135
Mois de parution
février 2011


Résumé
Lorsqu'il s'agit de protéger des données sensibles telles que les transactions bancaires, les courriels entre collaborateurs ou les données sur la partition de votre disque dur, il faut utiliser des bibliothèques cryptographiques. Leur utilisation est transparente, mais pourtant déterminante dans la sécurité des systèmes d'information. Le développeur qui a besoin de cryptographie a le choix de la bibliothèque à utiliser. Cet article, d'une série de deux, aborde l'intégration d'un nouvel algorithme dans deux bibliothèques très populaires : OpenSSL et NSS. La mise en œuvre du nouvel algorithme est présentée dans l'article [MEO_MYC].

Body

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.

Une erreur courante est d'appeler le chiffrement « cryptage ». Le chiffrement est le procédé qui consiste à rendre un texte inintelligible à la personne qui ne possède pas la clé de déchiffrement. Le terme cryptage est un anglicisme du mot encryption, qui ne figure pas dans le dictionnaire français. Toutefois, on peut utiliser le mot « crypter » dans le cadre de la télévision à péage. De la même façon, le décryptage est l'action de déchiffrer un texte dont on ne possède pas la clé, alors que le déchiffrage est le décodage d'un message légitime.

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.

Absurde

Figure 1 : Cryptographie symétrique si la même clé est employée par tous les visiteurs d'un site web.

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.

VraieVie

Figure 2 : Utilisation de la cryptographie asymétrique avec authentification du serveur pour gérer plusieurs visiteurs.

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.

OSI

Figure 3 : Le modèle OSI

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.

Les licences d'OpenSSL le rendent incompatible avec la GPL. Pour contourner ce problème, il est permis d'ajouter une exception à la licence pour pouvoir distribuer un programme lié à cette bibliothèque. Exemple d'exception pour le programme wget, consultable dans le fichier /usr/share/doc/wget/copyright, où on peut y lire le paragraphe suivant : « In addition, as a special exception, the Free Software Foundation gives permission to link the code of its release of Wget with the OpenSSL project's "OpenSSL" library (or with modified versions of it that use the same license as the « OpenSSL » library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than « OpenSSL ». If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. »

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 blocn forme le texte chiffré.

Ecb_encryption

Figure 4 : ECB en mode chiffrement. Source : http://en.wikipedia.org/wiki/File:Ecb_encryption.png

Ecb_decryption

Figure 5 : ECB en mode déchiffrement. Source : http://en.wikipedia.org/wiki/File:Ecb_decryption.png

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.

JOHN__105000

JACK__500000

Le chiffrement sur le premier message donne ceci :

JO|HN|__|10|50|00

Q9|2D|FP|VX|C9|IO

Et sur le deuxième message, on obtient :

JA|CK|__|50|00|00

LD|AS|FP|C9|IO|IO

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 :

Q9|2D|FP|VX|C9|IO

LD|AS|FP|C9|IO|IO

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

Table de vérité de XOR

A

B

R = A xor B

0

0

0

0

1

1

1

0

1

1

1

0

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.

Cbc_encryption

Figure 6 : CBC en mode chiffrement. Source : http://en.wikipedia.org/wiki/File:Cbc_encryption.png

Cbc_decryption

Figure 7 : CBC en mode déchiffrement. Source : http://en.wikipedia.org/wiki/File:Cbc_decryption.png

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.

No_ecb_mode_picture

Figure 8 : Image originale. Auteur: Dake. Source : http://fr.wikipedia.org/wiki/Fichier:No_ecb_mode_picture.png

Ecb_mode_pic

Figure 9 : Chiffrement en mode ECB. Auteur: Dake. Source : http://fr.wikipedia.org/wiki/Fichier:Ecb_mode_pic.png

Cbc_mode_pic

Figure 10 : Chiffrement en mode CBC. Auteur: Dake. Source: http://fr.wikipedia.org/wiki/Fichier:Cbc_mode_pic.png

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 :

Modes opératoires

Notations à points

Notations hexadécimales

MYC-ECB

1.2.3.123.45.6.7.1

0x2a,0x03,0x7b,0x2d,0x06,0x07,0x01

MYC-CBC

1.2.3.123.45.6.7.2

0x2a,0x03,0x7b,0x2d,0x06,0x07,0x02

MYC-CFB

1.2.3.123.45.6.7.3

0x2a,0x03,0x7b,0x2d,0x06,0x07,0x03

MYC-OFB

1.2.3.123.45.6.7.4

0x2a,0x03,0x7b,0x2d,0x06,0x07,0x04

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.

$ grep -ir camellia openssl-0.9.8o | cut -d :
-f1 | sort -u
openssl-0.9.8o/apps/cms.c
openssl-0.9.8o/apps/dsa.c
openssl-0.9.8o/apps/gendsa.c
openssl-0.9.8o/apps/genrsa.c
openssl-0.9.8o/apps/pkcs12.c
openssl-0.9.8o/apps/progs.pl
openssl-0.9.8o/apps/rsa.c
openssl-0.9.8o/apps/smime.c
openssl-0.9.8o/apps/speed.c
openssl-0.9.8o/config
openssl-0.9.8o/crypto/camellia/camellia.c
openssl-0.9.8o/crypto/camellia/camellia.h
openssl-0.9.8o/crypto/camellia/cmll_cbc.c
openssl-0.9.8o/crypto/camellia/cmll_cfb.c
openssl-0.9.8o/crypto/camellia/cmll_ctr.c
openssl-0.9.8o/crypto/camellia/cmll_ecb.c

openssl-0.9.8o/crypto/camellia/cmll_locl.h
openssl-0.9.8o/crypto/camellia/cmll_misc.c
openssl-0.9.8o/crypto/camellia/cmll_ofb.c
openssl-0.9.8o/crypto/camellia/Makefile
openssl-0.9.8o/crypto/crypto-lib.com
openssl-0.9.8o/crypto/evp/c_allc.c
openssl-0.9.8o/crypto/evp/e_camellia.c
openssl-0.9.8o/crypto/evp/evp_err.c
openssl-0.9.8o/crypto/evp/evp.h
openssl-0.9.8o/crypto/evp/evp_test.c
openssl-0.9.8o/crypto/evp/evptests.txt
openssl-0.9.8o/crypto/evp/Makefile
openssl-0.9.8o/crypto/install.com
openssl-0.9.8o/crypto/objects/objects.txt
openssl-0.9.8o/crypto/objects/obj_mac.num
openssl-0.9.8o/doc/apps/ciphers.pod
openssl-0.9.8o/Makefile.org
openssl-0.9.8o/makevms.com
openssl-0.9.8o/ssl/s3_lib.c
openssl-0.9.8o/ssl/ssl_algs.c
openssl-0.9.8o/ssl/ssl_ciph.c
openssl-0.9.8o/ssl/ssl.h
openssl-0.9.8o/ssl/ssl_locl.h
openssl-0.9.8o/ssl/tls1.h
openssl-0.9.8o/test/evptests.txt
openssl-0.9.8o/util/libeay.num
openssl-0.9.8o/util/mk1mf.pl
openssl-0.9.8o/util/mkdef.pl
openssl-0.9.8o/util/mkfiles.pl
[...]

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 :

openssl-0.9.8o/crypto$ ls myc
Makefile myc.c myc_cbc.c myc_cfb.c myc_ecb.c myc.h myc_locl.h myc_ofb.c

ou leur contenu :

openssl-0.9.8o/crypto/myc$ sed -i s/SEED/MYC/g *
openssl-0.9.8o/crypto/myc$ sed -i s/seed/myc/g *

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

openssl-0.9.8o/crypto/evp$ sed -i s/SEED/MYC/g e_myc.c
openssl-0.9.8o/crypto/evp$ sed -i s/seed/myc/g e_myc.c

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

195 #ifndef OPENSSL_NO_DES

196 else if (!strcmp (*args, "-des3"))

197 cipher = EVP_des_ede3_cbc();

198 else if (!strcmp (*args, "-des"))

199 cipher = EVP_des_cbc();

200 #endif

201 #ifndef OPENSSL_NO_SEED

202 else if (!strcmp (*args, "-seed"))

203 cipher = EVP_seed_cbc();

204 #endif

205 #ifndef OPENSSL_NO_MYC

206 else if (!strcmp (*args, "-myc"))

207 cipher = EVP_myc_cbc();

208 #endif

[...]

587 #ifndef OPENSSL_NO_DES

588 BIO_printf (bio_err, "-des3 encrypt with triple DES\n");

589 BIO_printf (bio_err, "-des encrypt with DES\n");

590 #endif

591 #ifndef OPENSSL_NO_SEED

592 BIO_printf (bio_err, "-seed encrypt with SEED\n");

593 #endif

594 #ifndef OPENSSL_NO_MYC

595 BIO_printf (bio_err, "-myc encrypt with MYC\n");

596 #endif

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

291 #define ALGOR_NUM 29

[...]

299 static const char *names[ALGOR_NUM]={

300 "md2","mdc2","md4","md5","hmac(md5)","sha1","rmd160","rc4",

301 "des cbc","des ede3","idea cbc","seed cbc",

302 "rc2 cbc","rc5-32/12 cbc","blowfish cbc","cast cbc",

303 "aes-128 cbc","aes-192 cbc","aes-256 cbc",

304 "camellia-128 cbc","camellia-192 cbc","camellia-256 cbc",

305 "evp","sha256","sha512",

306 "aes-128 ige","aes-192 ige","aes-256 ige", "myc cbc"};

[...]

616 #define D_MD2 0

617 #define D_MDC2 1

618 #define D_MD4 2

619 #define D_MD5 3

[...]

627 #define D_CBC_SEED 11

[...]

632 #define D_CBC_128_AES 16

633 #define D_CBC_192_AES 17

634 #define D_CBC_256_AES 18

[...]

644 #define D_CBC_MYC 28

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 :

306 e_seed.o: ../../include/openssl/asn1.h ../../include/openssl/bio.h

307 e_seed.o: ../../include/openssl/crypto.h ../../include/openssl/e_os2.h

308 e_seed.o: ../../include/openssl/err.h ../../include/openssl/evp.h

309 e_seed.o: ../../include/openssl/fips.h ../../include/openssl/lhash.h

310 e_seed.o: ../../include/openssl/obj_mac.h ../../include/openssl/objects.h

311 e_seed.o: ../../include/openssl/opensslconf.h ../../include/openssl/opensslv.h

312 e_seed.o: ../../include/openssl/ossl_typ.h ../../include/openssl/safestack.h

313 e_seed.o: ../../include/openssl/stack.h ../../include/openssl/symhacks.h

314 e_seed.o: e_seed.c

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

1247 # Definitions for SEED cipher - ECB, CBC, OFB mode

1248

1249 member-body 410 200004 : KISA : kisa

1250 kisa 1 3 : SEED-ECB : seed-ecb

1251 kisa 1 4 : SEED-CBC : seed-cbc

1252 !Cname seed-cfb128

1253 kisa 1 5 : SEED-CFB : seed-cfb

1254 !Cname seed-ofb128

1255 kisa 1 6 : SEED-OFB : seed-ofb

1256

1257 # Definitions for MYC cipher - ECB, CBC, OFB mode

1258

1259 1 2 3 123 45 6 7 1 : MYC-ECB : myc-ecb

1260 1 2 3 123 45 6 7 2 : MYC-CBC : myc-cbc

1261 !Cname myc-cfb128

1262 1 2 3 123 45 6 7 3 : MYC-CFB : myc-cfb

1263 !Cname myc-ofb128

1264 1 2 3 123 45 6 7 4 : MYC-OFB : myc-ofb

Attention ! Si, comme moi, vous travaillez dans un répertoire propre où vous n'effectuez pas de compilation et préférez copier le répertoire de travail pour compiler dedans, alors cette note vous concerne. Deux scripts s'appuient sur crypto/objects/objects.txt et crypto/objects/obj_mac.num pour générer automatiquement les fichiers obj_dat.h et obj_mac.h. Bien que générés automatiquement, ces fichiers sont présents et renseignés dans l'archive livrée. Puisque ces fichiers sont générés automatiquement, il n'est pas nécessaire de les compléter. La copie du répertoire de travail vers un répertoire de compilation implique que tous les fichiers du répertoire de compilation auront la même date. À cause d'une date identique, les scripts de génération de fichiers ne lisent pas objects.txt, ce qui provoque une erreur de compilation.
Il y a 2 façons de régler ce problème :
- faire une modification à la main dans le fichier pour qu'il ait une date plus récente (avec la commande touch par exemple);
et obj_mac.h, ce qui forcera le script à s'exécuter.

- copiez les fichiers avec l'option -a (archive) de la commande cp.

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.

893 myc_ecb 893

894 myc_cbc 894

895 myc_ofb128 895

896 myc_cfb128 896

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.

199 $ CONFIG_LOGICALS := NO_ASM,NO_RSA,NO_DSA,NO_DH,NO_MD2,NO_MD5,NO_RIPEMD,-

200 NO_SHA,NO_SHA0,NO_SHA1,NO_DES/NO_MDC2;NO_MDC2,NO_RC2,NO_RC4,NO_RC5, -

201 NO_IDEA,NO_BF,NO_CAST,NO_CAMELLIA,NO_SEED,NO_HMAC,NO_SSL2

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

135 #define SSL_ENC_SEED_IDX 11

136 #define SSL_ENC_MYC_IDX 12

137 #define SSL_ENC_NUM_IDX 13

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

320 /* The following cipher list is used by default.

321 * It also is substituted when an application-defined cipher list string

322 * starts with 'DEFAULT'. */

323 #define SSL_DEFAULT_CIPHER_LIST "MYC:AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH" /* low priority for RC4 */

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

283 #define SSL_ENC_MASK 0x3C3F8000L /* ancienne valeur: 0x1C3F8000L */

284 #define SSL_DES 0x00008000L

285 #define SSL_3DES 0x00010000L

286 #define SSL_RC4 0x00020000L

287 #define SSL_RC2 0x00040000L

288 #define SSL_IDEA 0x00080000L

289 #define SSL_eFZA 0x00100000L

290 #define SSL_eNULL 0x00200000L

291 #define SSL_AES 0x04000000L

292 #define SSL_CAMELLIA 0x08000000L

293 #define SSL_SEED 0x10000000L

294 #define SSL_MYC 0x20000000L

[...]

306 /* we have used 3fffffff - 2 bits left to go. (anciennement 1fffffff et 3 bits) */

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 :

241 /* MYC ciphersuites */

242 #define TLS1_CK_RSA_WITH_MYC_SHA 0x03000100

243 #define TLS1_CK_DH_DSS_WITH_MYC_SHA 0x03000101

244 #define TLS1_CK_DH_RSA_WITH_MYC_SHA 0x03000102

245 #define TLS1_CK_DHE_DSS_WITH_MYC_SHA 0x03000103

246 #define TLS1_CK_DHE_RSA_WITH_MYC_SHA 0x03000104

247 #define TLS1_CK_ADH_WITH_MYC_SHA 0x03000105

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 :

$ ls
openssl-0.9.8o OpenSSL-0.9.8o_add_myc_cipher.patch Packaging_Debian_Lenny_OpenSSL-0.9.8o_MYC.patch
$ patch -p0 < \
Packaging_Debian_Lenny_OpenSSL-0.9.8o_MYC.patch

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 :

openssl-0.9.8o$ chmod +x debian/rules
# aptitude install fakeroot
$ dpkg-buildpackage

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] :

libcrypto0.9.8-udeb_0.9.8o-1+lenny1-MYC1_i386.udeb

libssl0.9.8_0.9.8o-1+lenny1-MYC1_i386.deb

libssl0.9.8-dbg_0.9.8o-1+lenny1-MYC1_i386.deb

libssl-dev_0.9.8o-1+lenny1-MYC1_i386.deb

openssl_0.9.8o-1+lenny1-MYC1.dsc

openssl_0.9.8o-1+lenny1-MYC1_i386.changes

openssl_0.9.8o-1+lenny1-MYC1_i386.deb

openssl_0.9.8o-1+lenny1-MYC1.tar.gz

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.

# aptitude install zlib1g-dev
# dpkg -i *.deb

6.6.2 Vérifications

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

# aptitude show openssl
Paquet : openssl
État: installé
Automatiquement installé: non
Version : 0.9.8o-1+lenny1-MYC1
Priorité : optionnel
Section : utils

Responsable : Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org>
Taille décompressée : 2421k
Dépend: libc6 (>= 2.7-1), libssl0.9.8 (>= 0.9.8f-5), zlib1g (>= 1:1.1.4)
Suggère: ca-certificates
Est en conflit: ssleay (< 0.9.2b)
Description : Secure Socket Layer (SSL) binary and related cryptographic tools
This package contains the openssl binary and related tools.
It is part of the OpenSSL implementation of SSL.
You need it to perform certain cryptographic actions like:
* Creation of RSA, DH and DSA key parameters;
* Creation of X.509 certificates, CSRs and CRLs;
* Calculation of message digests;
* Encryption and decryption with ciphers;
* SSL/TLS client and server tests;
* Handling of S/MIME signed or encrypted mail.

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.

# aptitude install dpkg-dev fakeroot
# aptitude build-depends libnss3-dev
$ apt-get source libnss3-dev

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

$ grep -ir camellia nss-3.12.3.1 | cut -d ‘:’ -f1 | sort -u
mozilla/security/nss/cmd/bltest/blapitest.c
mozilla/security/nss/cmd/lib/pk11table.c
mozilla/security/nss/cmd/modutil/modutil.c
mozilla/security/nss/cmd/modutil/pk11.c
mozilla/security/nss/cmd/ssltap/ssltap.c
mozilla/security/nss/cmd/symkeyutil/symkey.man
mozilla/security/nss/cmd/symkeyutil/symkeyutil.c
mozilla/security/nss/lib/freebl/blapi.h
mozilla/security/nss/lib/freebl/blapit.h
mozilla/security/nss/lib/freebl/camellia.c
mozilla/security/nss/lib/freebl/camellia.h
mozilla/security/nss/lib/freebl/ldvector.c
mozilla/security/nss/lib/freebl/loader.c
mozilla/security/nss/lib/freebl/loader.h
mozilla/security/nss/lib/freebl/manifest.mn
mozilla/security/nss/lib/pk11wrap/debug_module.c
mozilla/security/nss/lib/pk11wrap/pk11mech.c
mozilla/security/nss/lib/pk11wrap/pk11slot.c
mozilla/security/nss/lib/pk11wrap/secmod.h
mozilla/security/nss/lib/softoken/pk11pars.h
mozilla/security/nss/lib/softoken/pkcs11.c
mozilla/security/nss/lib/softoken/pkcs11c.c
mozilla/security/nss/lib/softoken/secmodt.h
mozilla/security/nss/lib/ssl/ssl3con.c
mozilla/security/nss/lib/ssl/sslenum.c
mozilla/security/nss/lib/ssl/sslimpl.h
mozilla/security/nss/lib/ssl/sslinfo.c
mozilla/security/nss/lib/ssl/sslproto.h
mozilla/security/nss/lib/ssl/sslsock.c
mozilla/security/nss/lib/ssl/sslt.h
mozilla/security/nss/lib/util/pkcs11t.h
mozilla/security/nss/lib/util/secoid.c
mozilla/security/nss/lib/util/secoidt.h
mozilla/security/nss/tests/cipher/cipher.txt
mozilla/security/nss/tests/cipher/symmkey.txt
mozilla/security/nss/tests/ssl/sslcov.txt
mozilla/security/nss/tests/tools/tools.sh

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

422: case 0x000100: cs_str = "TLS/RSA/MYC-CBC/SHA"; break;

423: case 0x000101: cs_str = "TLS/DH-DSS/MYC-CBC/SHA"; break;

424: case 0x000102: cs_str = "TLS/DH-RSA/MYC-CBC/SHA"; break;

425: case 0x000103: cs_str = "TLS/DHE-DSS/MYC-CBC/SHA"; break;

426: case 0x000104: cs_str = "TLS/DHE-RSA/MYC-CBC/SHA"; break;

427: case 0x000105: cs_str = "TLS/DH-ANON/MYC-CBC/SHA"; break;

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

57 #define PUBLIC_MECH_TLS_FLAG 0x00001000ul

58 #define PUBLIC_MECH_AES_FLAG 0x00002000ul

59 #define PUBLIC_MECH_SHA256_FLAG 0x00004000ul

60 #define PUBLIC_MECH_SHA512_FLAG 0x00008000ul

61 #define PUBLIC_MECH_CAMELLIA_FLAG 0x00010000ul

62 #define PUBLIC_MECH_SEED_FLAG 0x00020000ul

63 #define PUBLIC_MECH_MYC_FLAG 0x00040000ul

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.

103 static ssl3CipherSuiteCfg cipherSuites[ssl_V3_SUITES_IMPLEMENTED] = {

104 /* cipher_suite policy enabled is_present*/

[...]

109 { TLS_DHE_RSA_WITH_MYC_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

110 { TLS_DHE_DSS_WITH_MYC_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

111 { TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

112 { TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

113 { TLS_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

114 { TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

[...]

139 { TLS_RSA_WITH_MYC_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

140 { TLS_RSA_WITH_SEED_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

141 { TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, SSL_NOT_ALLOWED, PR_FALSE,PR_FALSE},

[...]

331 {TLS_RSA_WITH_MYC_CBC_SHA, cipher_myc, mac_sha, kea_rsa},

332 {TLS_DHE_DSS_WITH_MYC_CBC_SHA, cipher_myc, mac_sha, kea_dhe_dss},

333 {TLS_DHE_RSA_WITH_MYC_CBC_SHA, cipher_myc, mac_sha, kea_dhe_rsa},

334

335 {TLS_RSA_WITH_SEED_CBC_SHA, cipher_seed, mac_sha, kea_rsa},

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 :

173 /* number of wrap mechanisms potentially used to wrap master secrets. */

174 #define SSL_NUM_WRAP_MECHS 17 /* ancienne valeur: 16 */

[...]

314 #ifdef NSS_ENABLE_ECC

315 #define ssl_V3_SUITES_IMPLEMENTED 53 /* ancienne valeur: 50 */

316 #else

317 #define ssl_V3_SUITES_IMPLEMENTED 33 /* ancienne valeur: 30 */

318 #endif /* NSS_ENABLE_ECC */

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 :

182 #define TLS_RSA_WITH_SEED_CBC_SHA 0x0096

183

184 #define TLS_RSA_WITH_MYC_CBC_SHA 0x0100

185 #define TLS_DH_DSS_WITH_MYC_CBC_SHA 0x0101

186 #define TLS_DH_RSA_WITH_MYC_CBC_SHA 0x0102

187 #define TLS_DHE_DSS_WITH_MYC_CBC_SHA 0x0103

188 #define TLS_DHE_RSA_WITH_MYC_CBC_SHA 0x0104

189 #define TLS_DH_ANON_WITH_MYC_CBC_SHA 0x0105

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

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

101 { TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

102 { TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

103 { TLS_RSA_WITH_CAMELLIA_256_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

104 { TLS_RSA_WITH_SEED_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

105 { TLS_DHE_DSS_WITH_MYC_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

106 { TLS_DHE_RSA_WITH_MYC_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

107 { TLS_RSA_WITH_MYC_CBC_SHA, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED },

7.3.14 mozilla/security/nss/lib/util/pkcs11t.h

Imitez les autres chiffres :

432 #define CKK_SEED 0x00000026

433

434 #define CKK_MYC 0x00000027

[...]

940 #define CKM_SEED_KEY_GEN 0x00000650

941 #define CKM_SEED_ECB 0x00000651

[...]

946 #define CKM_SEED_ECB_ENCRYPT_DATA 0x00000656

947 #define CKM_SEED_CBC_ENCRYPT_DATA 0x00000657

948

949 #define CKM_MYC_KEY_GEN 0x00000750

950 #define CKM_MYC_ECB 0x00000751

[...]

955 #define CKM_MYC_ECB_ENCRYPT_DATA 0x00000756

956 #define CKM_MYC_CBC_ENCRYPT_DATA 0x00000757

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 :

184 #define MYC_OID 0x2a,0x03,0x7b,0x2d,0x06,0x07

[...]

578 CONST_OID seed_CBC[] = { SEED_OID, 4 };

579

580 CONST_OID myc_ECB[] = { MYC_OID , 1 };

581 CONST_OID myc_CBC[] = { MYC_OID , 2 };

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.

595 /*

596 * NOTE: the order of these entries must mach the SECOidTag enum in secoidt.h!

597 */

598 const static SECOidData oids[SEC_OID_TOTAL] = {

[...]

1591 /* SEED algorithm OIDs */

1592 OD( seed_CBC, SEC_OID_SEED_CBC,

1593 "SEED-CBC", CKM_SEED_CBC, INVALID_CERT_EXTENSION),

1594

1595 /* MYC algorithm OIDs */

1596 OD( myc_ECB, SEC_OID_MYC_ECB,

1597 "MYC-ECB", CKM_MYC_ECB, INVALID_CERT_EXTENSION),

1598

1599 OD( myc_CBC, SEC_OID_MYC_CBC,

1600 "MYC-CBC", CKM_MYC_CBC, INVALID_CERT_EXTENSION),

1601 };

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 :

410 /* If the user has the Fortezza preference turned on, make

411 * that the strong cipher. Otherwise, use triple-DES. */

412 strong_mapi = smime_mapi_by_cipher (SMIME_DES_EDE3_168);

Selon la RFC n°2311 [SMIME_3DES] : « 2.6 ContentEncryptionAlgorithmIdentifier Receiving agents MUST support decryption using the RC2 or a compatible algorithm at a key size of 40 bits, hereinafter called « RC2/40 ». Receiving agents SHOULD support decryption using DES EDE3 CBC, hereinafter called « tripleDES ». Sending agents SHOULD support encryption with RC2/40 and tripleDES. »

Ce paragraphe stipule qu'il est recommandé pour les programmes expéditeurs de courriels de supporter le chiffrement avec le RC2 ou le Triple DES. Pour les programmes récepteurs de courriels, ceux qui déchiffrent, le support du RC2 ou un chiffre compatible avec une clé de 40 bits est obligatoire. En réception, le 3DES est recommandé. On pourrait être surpris de ne pas utiliser un chiffre plus fort que le 3DES pour faire du S/Mime, mais NSS ne fait que suivre les recommandations de la RFC.

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.

$ diff -N -U 8 -p -r nss-3.12.3.1 nss-3.12.3.1_myc > NSS_3.12.3.1_MYC_cipher.diff
$ rm -rf nss-3.12.3.1 /* On supprime le dossier NSS qui contient les sources déjà patchés et qui est dépourvu du dossier debian */
$ cp -R <quelquepart>/nss-3.12.3.1_du_depot_debian nss-3.12.3.1 /* On reprend le dossier NSS issu du dépôt (et non patché) et qui contient le dossier debian */
$ dpatch patch-template -p "99_myc_cipher" "Add MYC Cipher" < NSS_3.12.3.1_MYC_cipher.diff > nss-3.12.3.1/debian/patches/99_myc_cipher.dpatch /* Converti le fichier diff au format dpatch et l’ajoute dans le dossiers patches*/
$ echo "99_myc_cipher.dpatch" >> nss-3.12.3.1/debian/patches/00list /* Ajoute le patch à la liste des patches à prendre en compte pour la création du paquet */

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