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 car 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 en 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 toute restriction. Autrefois, nos binaires étaient créés au Canada, en Suède et en Allemagne.

OpenBSD est fourni avec Kerberos V. La base du code que nous utilisons est la version exportable Heimdal de Suède. Nos sources X11 ont été étendues afin de pouvoir utiliser Kerberos IV.

OpenBSD a été le premier système d'exploitation à être fourni avec une pile IPsec. Nous avons fourni IPsec depuis la version 2.1 d'OpenBSD en 1997. Notre pile IPsec dans le noyau est totalement conforme aux standards, avec support de l'accélération matérielle s'appuyant sur plusieurs cartes, ainsi que notre démon ISAKMP libre. Elle est utilisée dans une des machines du test de conformité IPsec organisé par VPNC.

Aujourd'hui la cryptographie est un moyen important pour 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

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 sous licence 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 et le "ticket passing".
• supporte l'authentification "one-time password" avec skey.

En résumé, nous avons pris une version de ssh avec une licence libre et l'avons adapté à OpenBSD. Environ un an plus tard, nous avons étendu OpenSSH en ajoutant le support du protocole SSH 2, si bien que les trois protocoles SSH majeurs sont désormais supportés : 1.3, 1.5 et 2.0.

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 provoquées par 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 vers les 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 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 utilisables une seule fois.
• Dans IPsec et isakmpd(8) pour authentifier l'origine des données et assurer l'intégrité du paquet.
• Pour les mots de passe MD5 comme dans FreeBSD (non activé par défaut), voir login.conf(5)
• 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 isakmpd pour protéger les échanges lorsque des clés IPsec sont négociées.
• 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 i.e., la Soekris VPN1201 ou VPN1211 (pour l'acheter) ou PowerCrypt. Les performances actuelles en utilisant une carte comportant un seul processeur Hifn 7751 à chaque bout d'un tunnel sont de 64Mbit/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 des standards de l'industrie et de nombreux fournisseurs ont des processeurs plus rapides (même Hifn a maintenant un processeur plus rapide mais plus cher). Les performances maximales obtenues avec du 3DES SHA1 ESP sont aux environs de 64MBit/sec.

  Après la sortie de la 2.9, le support de la puce Hifn 7951 fut ajouté, une version simplifiée du 7751 qui ajoute un accélérateur de cryptographie à clés publiques (non supporté) et un générateur de nombres aléatoires (supporté). Les cartes ont été données par Soekris Engineering.

  Après la sortie de la 3.0, le support de la puce Hifn 7811 fut ajouté, une version plus rapide du 7751 (aux alentours de 130 Mbit/s) avec un générateur de nombres aléatoires. Une carte a été donnée par GTGI.

  Après la sortie de la version 3.2, le support de l'algorithme de compression LZS, utilisé par ipcomp(4), fut ajouté.

  Après la sortie de la version 3.4, le support des puces 7955 et 7956 a été ajouté. En plus de toutes les fonctionnalités de la puce précédente 7951, celles-ci ajoutent la fonctionnalité AES.

  Hifn était initialement une société avec laquelle il fut difficile de travailler (ils nous ont menacé de poursuites judiciaires concernant notre "reverse-engineering" non américain de leur algorithme de déblocage cryptographique).

• Hifn 6500
  Cette carte est une unité de cryptographie asymétrique. Elle supporte les algorithmes RSA, DSA et DH, en plus d'un certains nombres de fonctions de gestion des grands nombres. Elle contient aussi un générateur de nombres aléatoires de très haute performance. Nous avons une carte, toute la documentation et quelques exemples de codes. À partir d'OpenBSD 3.1, le générateur de nombres aléatoires et l'unité grands nombres sont fonctionnels.

• Hifn 7814/7851/7854
  Cette carte est un processeur de paquets et une unité de cryptographie asymétrique. Elle supporte les algorithmes RSA, DSA, et DH, en plus d'un certains nombres de fonctions de gestion des grands nombres. Elle contient aussi un générateur de nombres aléatoires. Pour le moment, seulement le générateur de nombres aléatoires et l'unité grands nombres sont fonctionnels (pas de transformations de paquets).

• Broadcom BCM5801/BCM5802/BCM5805/BCM5820/BCM5821/BCM5822/5823/5825/5860/5861/5862 (ou le betachip Bluesteelnet 5501/5601)
  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.

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

  Après la sortie de la 2.8, ce pilote a été modifié afin de pouvoir générer des nombres aléatoires sur les BCM5805 et les modèles similaires, et ainsi d'alimenter la source d'entropie du noyau.

  Après la 2.9, le support pour le BCM5820 a été ajouté, qui est principalement une version plus rapide (64 bits, vitesse d'horloge plus rapide) de la BCM5805. Un support non testé pour la BCM5821 a également été ajouté après la 3.0.

  À partir de 3.1, l'unité grands nombres est supportée et les opérations RSA/DH/DSA peuvent être accélérées.

  Le support pour le BCM5801, BCM5802, BCM5821 et BCM5822 a été ajouté avant OpenBSD 3.2 (le support non testé de BCM5821 sous 3.1 ne fonctionnait pas à cause de pré-requis de gestion des interruptions).

  Un support partiel de la BCM5823 a été ajouté en 3.4.

  Le support pour les BCM5825, BCM5860, BCM5861 et BCM5862 incluant le support pour l'AES avec le BCM5823 ou plus récent a été ajouté après la 4.5.

• Securealink 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, et le travail sur ce pilote est en cours. Pour le moment, le pilote est capable de générer des nombres aléatoires afin d'alimenter la source d'entropie du noyau.

• SafeNet SafeXcel 1141/1741
  Suite à la sortie de la version 3.4, le support de ces deux chipsets (qu'on peut trouver sur des cartes crypto SafeNet) a été ajouté. Ces chipsets supportent les algorithmes DES, Triple-DES, AES, MD5 et SHA-1, RNG, les opérations à clé publique, et le traitement complet de paquets IPsec.

• SafeNet SafeXcel 1840
  Nous avons de la documentation et des exemplaires du matériel pour le chipset crypto SafeNet 1840. Un effort pour supporter au moins le RNG et la cryptographie symétrique de ces périphériques a été initié.

• SafeNet SafeXcel 2141
  Nous avons de la documentation et des exemplaires du matériel pour le chipset crypto SafeNet 2141. Un effort pour supporter au moins la cryptographie symétrique de ces périphériques a été initié.

• 3com 3cr990
  3Com nous a donné un pilote pour supporter la partie Ethernet de leur Chipset, et à partir de celui-ci, nous avons écrit notre propre pilote ethernet. Le pilote a été intégré depuis que nous avons reçu une licence libre sur le microcode. À cause d'une mauvaise documentation et d'un manque de coopération (partiellement à cause du taux élevé de démissions chez 3Com), les fonctions IPsec de ce processeur ne sont pas supportées... Cet exercice a donc été d'un très faible intérêt.

• Carte Intel IPsec
  Un peu comme pour tous ces composants venant de la division réseau, et à l'inverse des autres vendeurs, Intel refuse 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é pour ce que nous avons fait. Mais ils ont les mains liées par la direction qui ne comprend pas les bénéfices qu'ils pourraient retirer en nous fournissant la documentation. Oubliez Intel. (si vous voulez acheter du gigabit ethernet, nous recommandons n'importe quoi d'autre... pour la même raison : la plupart des pilotes pour le matériel réseau Intel sont écrits sans documentation).

• Intel 82802AB/82802AC Firmware Hub RNG
  Le processeur 82802 FWH (qui se trouve sur les carte mères i810, i820, i840, i850 et i860) 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 RNGs trouvés dans les processeurs de cryptographie.

• VIA C3 RNG
  Le nouveau processeur VIA C3 contient un générateur de nombres aléatoires en tant qu'instruction. À partir de la version 3.3, ce générateur de nombres aléatoires est utilisé par le noyau pour fournir de l'entropie.

• Instructions AES du VIA C3
  Les processeurs VIA C3 avec un noyau Nehemiah step 8 ou ultérieur comportent une implémentation AES accessible à travers de simples instructions. Dans la version 3.4, le noyau supporte ces instructions dans un contexte d'utilisation IPsec. Ces instructions sont exportées par /dev/crypto. À partir de la version 3.5, les performances ont été améliorées de manière significative. OpenSSL utilise maintenant les nouvelles instructions directement dès lors que celles-ci sont disponibles sans avoir besoin de passer par le noyau ce qui se traduit par des vitesses de traitement largement améliorées (AES-128 a été mesuré à une vitesse de 780Mo/s) pour les applications utilisant OpenSSL pour effectuer des opérations de chiffrement AES.

• OpenSSL
  Voici quelques années, nous avions de grands projets pour le support de cartes cryptographiques implémentant RSA/DH/DSA automatiquement à travers des appels OpenSSL. À partir d'OpenBSD 3.2, ce support est fonctionnel, et toute carte supportée et disposant d'une telle fonctionnalité utilise automatiquement le matériel y compris OpenSSH et httpd en mode SSL. Aucun changement au niveau applicatif n'est nécessaire.

S'il y a des personnes intéressé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 documents 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.

• The Design of the OpenBSD Cryptographic Framework.
  Usenix 2003, par Angelos D. Keromytis, Jason L. Wright, et Theo de Raadt.
  papier.

• Cryptography As an Operating System Service: A Case Study.
  ACM Transactions on Computer Systems, Février 2006, par Angelos D. Keromytis, Jason L. Wright, and Theo de Raadt.
  papier.