Cryptographie

---

Pourquoi est ce que nous fournissons de la cryptographie ?

En quelques mots : parce que nous le pouvons.

Le projet OpenBSD est basé au Canada.

La liste de contrôle des exportations du Canada ne place aucune restriction significative sur l'exportation de logiciels cryptographiques, et est même très explicite quant à la libre exportation de logiciels cryptographiques disponibles librement. Marc Plumb a fait quelques recherches pour tester les lois sur la cryptographie.

à partir de là, le projet OpenBSD a intégré de la cryptographie dans de multiples portions du système d'exploitation. Il est indispensable que les logiciels de cryptographie que nous utilisons soient disponibles librement et avec des licences correctes. Nous n'utilisons pas de cryptographie avec des brevets. Il est tout aussi indispensable que ces logiciels soient originaires de pays avec des lois d'exportation sur la cryptographie souples parce que nous ne désirons pas être en désaccord avec les lois de ces pays. Les composants cryptographiques utilisés ont été écrits en Allemagne, Argentine, Australie, Canada, Grèce, Norvège et Suède.

Quand nous créons des versions d'OpenBSD ou des snapshots, ceux-ci sont compilés dans des pays libres pour être sûr que les sources et les binaires que nous fournissons soient libres de toutes restrictions. Autrefois, nos binaires étaient créés au Canada, en Suède et en Allemagne.

OpenBSD est fourni avec Kerberos IV. Le code utilisé est basé sur la version KTH venant de Suède. Notre source X11 a été étendu pour faire usage de Kerberos IV. Le support Kerberos V apparaîtra courant 2000.

Aujourd'hui la cryptographie est un important moyen d'améliorer la sécurité d'un système d'exploitation. La cryptographie incluse dans OpenBSD peut-être classée en plusieurs catégories, comme suit.

OpenSSH

Quelle est la première chose qui est faite après l'installation d'OpenBSD ? L'installation de Secure Shell (ssh) depuis les ports ou à l'aide d'un package sur un site FTP. Jusque là, c'était comme ça.

Depuis la version 2.6, OpenBSD contient OpenSSH, une version de ssh totalement libre et non encombrée de brevets. OpenSSH interopère avec ssh version 1, et possède de nombreuses caractéristiques en plus :

• tous les composants ayant une nature restrictive (comme les brevets, voir ssl) ont été directement enlevés du code source. Tout composant licencié ou breveté utilise des bibliothèques externes.
• a été mis à jour pour supporter la version 1.5 du protocole.
• contient l'ajout du support pour l'authentification kerberos
• support pour l'authentification unique (one-time password) avec skey.

En gros, nous avons pris une version de ssh avec une licence libre et l'avons modifiée. Nous avons contourné le brevet déposé aux USA sur RSA en fournissant une méthode pour télécharger et installer un package RSA contenant les bibliothèques partagées libcrypto et libssl. Ces packages sont basés sur OpenSSL. Les personnes résidant à l'extérieur des USA peuvent utiliser librement le code breveté, tandis que les personnes résidant aux USA ne peuvent que l'utiliser dans un but non commercial. Il apparaît que les compagnies commerciales peuvent utiliser les bibliothèques RSA aussi du moment que ce n'est pas dans un but commercial.

De cette façon, tout le monde peut posséder ssh directement intégré dans le système d'exploitation.

NOUVEAU! OpenSSH supporte le protocole 2.0 !

Récemment, nous avons étendu OpenSSH de façon à pouvoir aussi utiliser le protocole SSH 2. Le démon ssh comprend les trois protocoles SSH utilisés (1.3, 1.5, 2.0), ce qui nous permet beaucoup de flexibilité. Le protocole 2.0 n'utilise pas RSA comme algorithme de cryptographie à clé publique, mais plutôt les algorithmes DH et DSA. Dans OpenBSD 2.7 (qui sera fournit avec le nouveau OpenSSH) vous obtiendrez le support du protocole 2.0 directement ! Si vous désirez obtenir le support pour les protocoles 1.3 et 1.5, il vous suffira juste d'installer le package RSA (comme décrit dans notre page du manuel ssl) et de relancer le démon.

Générateurs de nombres pseudo aléatoires

Un générateur de nombres pseudo aléatoires (Pseudo Random Number Generator: PRNG) fournit aux applications un flot de nombres qui possèdent certaines propriétés importantes en ce qui concerne la sécurité du système :

• Il doit être impossible de prévoir le résultat du générateur de nombres aléatoires même en connaissant le résultat précédent.
• Les nombres générés ne doivent pas avoir de caractères qui se répètent ce qui signifie que le générateur doit avoir un cycle très grand.

Un PRNG est normalement un algorithme où les mêmes variables en entrée donneront les mêmes résultats en sortie. Sur un système multi-utilisateurs, il existe de nombreuses sources qui permettent de fournir des données aléatoires au PRNG. Le noyau OpenBSD utilise le temps entre les interruptions dues à la souris, le temps entre les interruptions dues aux données réseau, le temps entre chaque appui de touches et les informations sur les entrées/sorties des disques pour remplir la réserve d'entropie. Les nombres aléatoires sont accessibles aux routines du noyau et sont exportés aux programmes utilisateurs par l'intermédiaire de périphériques. Les nombres aléatoires sont utilisés dans les endroits suivants :

• Allocation de sin_port dynamiques dans bind(2).
• PID des processus.
• ID des paquets IP.
• Identifiants (ID) des transactions RPC (XID).
• Identifiants (ID) des transactions NFS RPC (XID).
• Identifiants (ID) des requêtes DNS.
• Génération des nombres d'inode, voir getfh(2) et fsirand(8).
• Perturbation temporelle dans traceroute(8).
• Nom temporaire plus aléatoire pour mktemp(3) et mkstemp(3)
• Données aléatoires ajoutées au numéro de séquence TCP pour se protéger des attaques spoofées.
• Bourrage aléatoire dans les paquets IPSEC esp_old.
• Pour générer des graines pour les différents algorithmes de mots de passe.
• Pour générer de faux challenges S/Key.
• Dans photurisd et isakmpd pour assurer la bonne tenue des échanges de clés.

Fonctions de hachages cryptographiques

Une fonction de hachage compresse les données fournies en une chaîne de taille constante. Pour une fonction de hachage cryptographique, il est impossible de trouver :

• Deux entrées qui ont le même résultat (résistant à la collision),
• Une entrée différente pour une entrée donnée avec le même résultat.

Dans OpenBSD MD5, SHA1, et RIPEMD-160 sont utilisés en tant que fonctions de hachage cryptographiques :

• Dans S/Key pour fournir des mots de passe utilisable une seule fois.
• Dans IPsec, photurisd et isakmpd(8) pour authentifier l'origine des données et assurer l'intégrité du paquet.
• Pour les mots de passe MD5 à la FreeBSD (non activé par défaut), voir passwd.conf(5)
• Pour le support des cookies TCP SYN (non activé par défaut), voir options(4)
• Dans libssl pour la signature numérique des messages.

Transformations cryptographiques

Les transformations cryptographiques sont utilisées pour chiffrer et déchiffrer les données. Elles sont normalement utilisées avec une clé de chiffrement pour le chiffrement des données et une clé de déchiffrement pour le déchiffrement des données. La sécurité d'une transformation cryptographique ne doit reposer que sur la clé.

OpenBSD fournit des transformations telles que DES, 3DES, Blowfish et Cast pour le noyau et les programmes utilisateurs, qui sont utilisées dans de nombreux endroits tels que :

• Dans la libc pour créer des mots de passe Blowfish. Voir aussi le document USENIX à ce sujet.
• Dans IPsec pour fournir la confidentialité au niveau de la couche réseau.
• Dans Kerberos et les applications "kerberifiées" telles que telnet, cvs, rsh, rcp, et rlogin.
• Dans photurisd et isakmpd pour protéger les échanges où des clés IPsec sont négociées.
• Dans AFS pour protéger les messages transitant sur le réseau, fournissant la confidentialité pour l'accès au système de fichiers distant.
• Dans libssl pour permettre aux applications de communiquer à l'aide du protocole cryptographique SSL (qui est un standard de fait).

Support de matériels cryptographiques

OpenBSD 2.7 supporte quelques matériels cryptographiques tels que les accélérateurs cryptographiques et les générateurs de nombres aléatoires.

• IPSEC crypto dequeue
  Notre pile IPSEC a été modifiée de façon à ce que les fonctions cryptographiques soient effectuées hors ligne. La plupart des piles IPSEC relativement simples ont besoin d'utiliser la cryptographie à chaque paquet qu'elles traitent. Il en résulte une performance synchrone. Utiliser du matériel correctement et rapidement nécessite de séparer ces deux composants, comme nous l'avons fait. Actuellement, cette méthode permet de gagner en performance même sans utiliser de matériel.

• HiFn 7751
  Les cartes utilisant le processeur HiFn 7751 peuvent être utilisées en tant qu'accélérateur cryptographique symétrique (voir sur le site de PowerCrypt). Les performances actuelles en utilisant une carte comportant un seul processeur Hifn 7751 à chaque bout d'un tunnel sont de 63Mbit/sec pour 3DES/SHA1 ESP, presque 600% d'amélioration par rapport à l'utilisation d'un processeur de type P3/550. De plus amples améliorations sont en cours pour résoudre quelques problèmes, mais depuis le 13 Avril 2000, le code est considéré comme stable. Nous avons écrit notre propre pilote pour supporter le processeur plutôt que d'utiliser le pilote (écrit aux USA) de Powercrypt, et pour permettre à notre périphérique de s'intégrer correctement avec notre pile IPSEC.

  Le 7751 est maintenant considéré comme lent vis à vis de standards de l'industrie et de nombreux fournisseurs ont des processeurs plus rapide (même HiFn a maintenant un processeur plus rapide mais plus cher). Les performances maximales obtenues avec du 3DES SHA1 ESP sont aux environ de 63MBit/sec. (En contrepartie, HiFn est une société avec laquelle il fut difficile de travailler, ils ont même essayé de nous poursuivre en justice à cause de notre reverse-engineering (non américain) de leur algorithme de déblocage de la crypto).

• Hifn 6500
  Ce périphérique est une unité de cryptographie assymétrique. Elle supporte les algorithmes RSA, DSA et DH, en plus d'un certains nombres de functions de gestion des grands nombres. Elle contient aussi un générateur de nombres aléatoires très haute performance. Nous avons une carte, toute la documentation et quelques exemples de codes. Le développement n'a pas encore démarré.

• Broadcom BCM5805 (ou le processeur Bluesteelnet 5501)
  Juste après la version 2.7 d'OpenBSD, nous avons ajouté le support pour les premières parties fournies par le constructeur, en commençant notamment par le 5501. Ces périphériques fournissent les meilleures performances en cryptographie symétrique que nous ayons vues. Bluesteelnet a été racheté par Broadcom et a réalisé d'autres processeurs. Leur nouveau BCM5805 est similaire au précédent, excepté qu'il y a en plus un système asymétrique pour les algorithmes DSA, RSA et autres. Les performances approximatives sont au moins deux fois plus rapides que pour le HiFn.

  Le gens de Broadcom/Bluesteelnet ont été particulièrement sympathiques. Ils nous ont fournit la documentation complète de leurs processeurs, quelques exemples de codes et un nombre suffisant de cartes pour faire des tests.

• Pijnenburg PCC-ISES
  Le PCC-ISES est un nouveau chipset venant des Pays-Bas. Nous avons reçu des exemplaires du matériel et de la documentation, donc le support devrait démarrer bientôt.

• SafeNet 2141
  Cartes crypto SafeNet. Nous avons commencé à travailler sur le support de la cryptographie symétrique pour ces périphériques.

• 3com 3c990
  3Com n'a toujours pas compris comment ils pourraient bénéficier du fait de nous fournir la documentation de leurs cartes cryptographiques, donc vous pouvez les contacter et les inciter à le faire. Nous avons eu de bons rapports avec eux mais les personnes avec qui nous avons parlé ont changé de position. Nous avons abandonné nos discussions avec eux, car c'est une perte de temps.
• Intel IPSEC card
  Un peu comme 3COM, Intel a refusé de nous fournir de la documentation. Nous avons parlé à cinq ingénieurs qui sont impliqués dans le développement de ces produits. Ils ont tous voulus nous fournir la documentation. Ils nous ont félicités pour ce que nous avons fait. Mais ils ont leur mains liées par le management qui ne comprend pas les bénéfices qu'ils pourraient retirer en nous fournissant la documentation.

• Intel 82802AB/82802AC Firmware Hub RNG
  Le processeur 82802 FWH (qui se trouve sur les carte mères i810, i820, et i840) contient un générateur de nombres aléatoires (RNG). L'IPSEC de haute performance nécessite beaucoup d'entropie. Depuis le 10 Avril 2000, nous supportons ce RNG. Nous ajouterons le support aux autres RNG trouvés dans les processeurs de cryptographie.

• OpenSSL
  Nous avons de grands projets pour les cartes supportant RSA ou DSA, de façon à exporter les fonctions des cartes de crypto vers OpenSSL pour que les programmes utilisateurs (comme ssh, apache https, etc...) puissent en bénéficier.

S'il y a des personnes interessées pour nous aider à écrire des pilotes, venez nous aider.

Cherche cryptographes internationaux

Évidemment, notre projet a besoin de personnes pour travailler sur ces systèmes. Si un cryptographe non Américain qui remplit les conditions énoncées précédemment est intéressé pour nous aider sur la cryptographie embarquée dans OpenBSD, qu'il n'hésite pas à nous contacter.

Lectures ultérieures

Un certain nombre de papiers ont été écrits par des membres du projet OpenBSD, au sujet des changements cryptographiques qui ont été faits dans OpenBSD. Les versions PostScript des documents sont disponibles ci-dessous.

• A Future-Adaptable Password Scheme.
  Usenix 1999, par Niels Provos, David Mazieres.
  papier et slides.

• Cryptography in OpenBSD: An Overview.
  Usenix 1999, par Theo de Raadt, Niklas Hallqvist, Artur Grabowski, Angelos D. Keromytis, Niels Provos.
  papier et slides.

• Implementing Internet Key Exchange (IKE).
  Usenix 2000, par Niklas Hallqvist et Angelos D. Keromytis.
  papier et slides.

• Encrypting Virtual Memory
  Usenix Security 2000, Niels Provos.
  papier et slides.