bettercrypto.org : guide de cryptographie appliquée

Jeudi 6 juin 2013, Edward Snowden commence la publication de documents révélant les pratiques de la NSA. Survient alors une prise de conscience de l'importance de sécuriser les données. Ces révélations confirment que certains algorithmes et protocoles, tels que PGP/GPG ou AES, sont résistants aux attaques.

Le problème suivant se pose alors : comment utiliser correctement ces algorithmes ? Si théoriquement ils sont prouvés mathématiquement, et avérés robustes, leurs mauvaises utilisations peuvent les rendre complètement vulnérables. Et cela sans compter les risques liés à de mauvaises implémentations, ou des bugs oubliés tels que ceux ayant conduit à HeartBleed.

Partant de ce constat, et pour répondre aux nombreuses questions d'administrateurs système, le projet BetterCrypto ([BETTERCRYPTO]) est né. Le principe est simple : réunir un groupe d'experts avec différentes expériences pour écrire, dans un document de référence, les configurations qui leur semblent optimales. Toutes les décisions sont prises en toute transparence et détaillées dans le document afin que tout un chacun puisse les critiquer et décider en connaissance de cause. C'est ce projet que nous allons vous présenter tout au long de cet article.

La vocation du projet est d'atteindre tous ceux qui ont besoin de protéger leurs données. Pour la plupart des entreprises et des particuliers, une utilisation correcte des protocoles standards est suffisante. A contrario, les organisations aux besoins spécifiques, et disposant d'experts capables de comprendre les subtilités de chaque algorithme trouveront certainement certaines recommandations insuffisantes ou incomplètes.

1. Construction du document BetterCrypto

Nous nous sommes écartés du schéma classique dans lequel on commence par un long chapitre discutant des tenants et aboutissants de la cryptographie, des algorithmes et de tous les aspects influençant la sécurité.

Partant de l'hypothèse que ce document sera probablement consulté pour la première fois dans l'urgence, nous l'avons construit de telle sorte que la pratique précède la théorie. Après une brève introduction, les configurations de références sont présentées. Ainsi, nos lecteurs peuvent commencer par copier/coller et obtenir rapidement un système fonctionnel et sécurisé.

Le lecteur est toutefois invité à consulter, par la suite, la partie théorique décrivant les choix établis et les raisons qui nous ont poussés à les faire. Il ne tient qu'à eux de décider si la configuration proposée satisfait à leurs besoins ou si elle doit être amendée. Les utilisateurs plus curieux, ou moins pressés, peuvent commencer par la lecture de la partie théorique.

Dans tous les cas, nous espérons qu'ils consulteront les deux sections, et plus encore, qu'ils critiqueront nos décisions.

 

 

2. Partie théorique

BetterCrypto n'est pas un cours de cryptographie, aussi ne vous attendez pas à y trouver de longues explications sur les algorithmes. Par contre, nos objectifs y sont expliqués et discutés. Nous y présentons en particulier les notions de « Forward Secrecy », de compatibilités, de génération de nombres aléatoires, d'échange de clés…

Prenant en compte les différentes contraintes existantes, nous en sommes arrivés à faire deux propositions de choix d'algorithmes. Une très stricte, la suite A, mais avec quelques désavantages, comme l'incompatibilité avec Java 6 et Windows XP, et une suite d'algorithmes plus souple, la suite B, mais dérogeant à certains de nos souhaits comme nous le verrons par la suite.

2.1. Perfect Forward Secrecy

‪Le perfect forward secrecy ([HAC-FS-CHAP12]) est une propriété qui garantit la confidentialité des échanges passés même si les clés du client et/ou serveur sont compromises.

En pratique, cette propriété est atteinte en générant régulièrement une nouvelle clé, par exemple à l'aide de fonctions non-inversibles, afin de chiffrer le trafic. Dès lors, même si l'attaquant arrive à obtenir la clé d'échange courante, les clés précédentes, et donc le contenu chiffré, ne peuvent pas être retrouvés.‬

Attaché à garantir la confidentialité des communications, c'est un principe important qui n'est malheureusement complètement disponible que dans la suite A.

2.2 Configurations proposées

Dans un monde idéal, seuls les chiffrements permettant de garantir le perfect forward secrecy, c'est-à-dire utilisant un échange de clés avec la version éphémère de Diffie-Helleman (EDH ou EECDH) combiné avec une authentification forte (telle que RSA) devraient être utilisés. Cette version sans compromis est la suite A qui ne contient que 4 algorithmes :

- EDH, aRSA et AES128 ;

- EDH, aRSA et AES256 ;

- EECDH, aRSA et AES128;

- EECDH, aRSA et AES256 .

En notation OpenSSL, nous avons la chaîne de caractères suivante (notez l'exclusion explicite de SSL en version 3) :

En pratique, cette suite va poser problème si vous utilisez des logiciels ne supportant pas TLS 1.2. Il en va de même si vos équipements disposent de ressources limitées, car l'utilisation de TLS 1.2 peut avoir des conséquences non négligeables sur la consommation de ressources matérielles.

Afin de résoudre ce problème, nous avons étendu la suite A avec les versions 1.0 et 1.1 de TLS, et ajouté SHA1 à la liste des protocoles utilisés pour l'authentification des paquets.

Nous obtenons ainsi la suite B, décrite avec la chaîne de caractères suivante pour OpenSSL :

Notez que les protocoles considérés comme faibles ou vulnérables sont explicitement exclus. Nous retrouvons dans cette liste d'exclusion 3DES, MD5, RC4… Cet ajout d'algorithmes supplémentaires permet de supporter Windows XP ainsi que d'autres logiciels ou systèmes d'exploitation vieillissants.

2.3 Longueurs des clés

Quelle est la longueur de clés à recommander ? Cette question nous a occupés pendant quelque temps et de nombreuses discussions ont eu lieu autour d'AES. Si intuitivement AES256 semble mieux que AES128 (même si un article de Bruce Schneier pourrait contredire cette affirmation [SCHNEIER-AES]), la réponse finale concernant AES est venue de Vincent Rijmen – un auteur de l'AES – dans l'affirmation suivante :

« On the choice between AES256 and AES128: I would never consider using AES256, just like I don’t wear a helmet when I sit inside my car. It’s too much bother for the epsilon improvement in security. »

Contenu d'un échange privé de courriel avec Vincent Rijmen en décembre 2013.

Comme aucun de nous ne semblait disposé à conduire nos voitures avec un casque, nous avons suivi sa recommandation et inclus AES128.

De manière plus rigoureuse, nous avons pris en compte le système de comparaison proposé par BlueKrypt sur son site [KEYLENGTH].

 

 

Cette référence compare différentes normes (ANSSI, NIST…) pour faciliter le choix de la longueur de clé idéale selon des critères objectifs comme, par exemple, la durée pendant laquelle les informations devront rester protégées.

Pour notre projet, nous avons pris les recommandations suivantes pour la longueur des clés :

- Chiffrement asymétrique (comme RSA) : 3248 bits (recommandation Ecrypt II) ;

- Chiffrement symétrique (tel que AES) : 128 bits ;

- Chiffrement utilisant les courbes elliptiques (ECC) : 256 bits ;

- Algorithme de hash : minimum SHA2+ (SHA256 par exemple).

2.4 Compatibilité

Le choix entre les suites A et B se fera essentiellement sur base des logiciels qui doivent être supportés. S'ils sont tous récents et sous contrôle, la suite A offrira une sécurité accrue. Si, au contraire, des configurations plus anciennes ou plus exotiques doivent être supportées alors la suite B offrira un compromis acceptable.

De manière générale, pour des systèmes à usage interne et/ou sensible (même si accessible depuis l'Internet), la suite A devra être préférée. A contrario pour un système grand public, la suite B réduira le nombre de clients frustrés par les connexions refusées et les messages d'erreur de leurs navigateurs.

De manière non exhaustive, le tableau suivant compare les configurations supportées par les suites A et B. Avant toute mise en production, certains outils permettent de définir de manière plus précise les configurations compatibles. Nous y reviendrons plus tard.

 

Configuration	Suite A	Suite B
Android 2.3 – Android 4.3	Non	Oui
Android 4.4.2 et supérieur	Oui	Oui
Google Chrome 47	Oui	Oui
Firefox 31.0.3 ESR	Oui	Oui
Firefox 42	Oui	Oui
Internet Explorer 6	Non	Non
Internet Explorer 7	Non	Oui
Internet Explorer 8 à 10	Non	Oui
Internet Explorer 11 et supérieur	Oui	Oui
Windows Phone 8.0	Non	Oui
Windows Phone 8.1 et supérieur	Oui	Oui
Edge	Oui	Oui
Java 6 à 7	Non	Oui (DH limité à 1024 bits)
Java 8	Oui (DH limité à 1024 bits)	Oui (DH limité à 1024 bits)
OpenSSL avant version 1.0	Non	Oui
OpenSSL 1.0 et supérieur	Oui	Oui
Safari 5.1.9 et 6.04	Non	Oui
Safari 7 et supérieur	Oui	Oui
IOS 6.0.1	Oui	Oui

En résumé, les machines exécutant au minimum Windows 7, Mac OS X 10.9 (Mavericks), Android 4.4 (KitKat), Windows Phone 8.1 ou iOS 6 devraient supporter les suites A et B si les logiciels ont bien été mis à jour aux dernières versions disponibles. Les logiciels plus vieux seront incompatibles avec TLS 1.2 et donc avec la suite A.

2.5 Génération de nombres aléatoires

Une des hypothèses de base utilisées en cryptographie est la capacité de générer des nombres aléatoires. Pour ce faire, de multiples techniques sont combinées afin d'obtenir ce qui se rapprochera le plus d'un générateur parfait de nombres aléatoires.

Toutefois, la popularité grandissante des appareils mobiles pose problème. Les clés sont souvent générées au démarrage de l'appareil alors que la réserve d'entropie est faible. Il est dès lors possible de prédire la suite de valeurs aléatoires générées, surtout si tous partagent les mêmes paramètres d'initialisation.

Une bonne pratique est donc de renouveler les clés régulièrement, et surtout, d'éviter de les générer pendant, ou immédiatement après la phase de démarrage. Le but étant d'assurer que votre système dispose de suffisamment d'entropie pour réduire au minimum les risques de prédiction de la suite des nombres aléatoires.

3. Partie pratique

Lister de manière exhaustive tous les logiciels supportés par ce projet serait inutile, car cela serait trop long ou incomplet selon les opinions. Nous avons néanmoins tenté de couvrir un maximum de cas et nous continuerons à le faire dans la mesure du possible.

Citons toutefois les grands classiques tels que :

- les serveurs web : Apache, ligthttpd, nginx et Microsoft IIS ;

- le shell sécurisé : OpenSSH ;

- les serveurs de courriels : Dovecot, Cyrus, Postfix et exim ;

- les VPN : IPSec, OpenVPN, CheckPoint et CISCO ASA ;

- l'encryption des courriels avec PGP/GPG ;

- les serveurs de messagerie instantanée : ejabberd et Charybdis ;

- les gestionnaires de bases de données : Oracle, MySQL, DB2 et PosgreSQL ;

- les proxy : BlueCoat, HAProxy, Pound et stunnel ;

- l'authentification avec Kerberos.

Pour chacun, nous ne pouvons que vous inviter à consulter le projet BetterCrypto. Nous ne nous attarderons ici que sur Apache et Postfix pour la suite de cette partie pratique.

Comme vous le constaterez, les changements à apporter aux configurations sont détaillés. Lorsque la configuration ne doit pas être adaptée, il en est fait mention dans le projet, mais aucune configuration ne sera proposée. À terme, notre rêve serait de pouvoir dire que par défaut, tout est correct et bien configuré. En pratique, on est relativement proche de cette situation idéale pour un certain nombre d'outils commerciaux et open source.

3.1 Apache

Apache est un serveur web open source que l'on rencontre très fréquemment sur la toile, tellement populaire que son nom fait partie des acronymes LAMP (Linux – Apache – MySQL – PHP) ou WAMP (Windows – Apache – MySQL – PHP).

Il sera donc notre cobaye pour cette première démonstration du contenu du projet BetterCrypto.

La première partie de la configuration proposée consiste à fournir la configuration de base pour SSL :

Plusieurs choses sont à noter sur cette configuration :

- Elle fournit les éléments à ajouter à une configuration standard pour obtenir une configuration complète supportant HTTPS. Le but est d'aider à la transition vers HTTPS, pas d'écrire un guide sur Apache. Ces derniers existent déjà en suffisance et en qualité.

- Le paramètre SSLCipherSuite sert à définir la suite de chiffrement. On reconnaît tout de suite la présence de la suite B dans cet exemple.

- HSTS (HTTP Strict Transport Security) [HSTS-Wikipedia], est activé. Cette directive, envoyée par le serveur, demande au navigateur de communiquer avec le serveur uniquement au travers d'une communication sécurisée.

Pour ceux qui veulent laisser le port TCP/80 ouvert, tout en forçant le passage vers HTTPS, la configuration suivante peut être donnée à Apache :

Des configurations équivalentes sont proposées pour les autres serveurs web populaires.

3.2 Postfix

Le cas du serveur de courriels est très intéressant : non seulement il doit être compatible avec les logiciels de messagerie qui viennent recevoir ou envoyer des courriels, mais il doit être capable de servir de relais vers d'autres serveurs. Si on peut parfois accepter qu'un client soit incompatible, afin d'inciter l'utilisateur à mettre à jour son logiciel, cela devient inacceptable lorsque la communication doit être absolument établie entre deux serveurs.

Nous distinguons trois modes de fonctionnement des serveurs de messagerie :

- mode soumission (MSA) : l'utilisateur y envoie ses courriels le plus souvent en utilisant le protocole SMTP ;

- mode transfert (MTA) ou échange (MX) : les courriels sont échangés entre les serveurs source et destination en utilisant également le protocole SMTP ;

- mode réception (MDA) : l'utilisateur vient récupérer ses courriels le plus souvent via les protocoles IMAP ou POP.

Il est également à noter que pour les serveurs de courriels, TLS peut être utilisé à deux niveaux : soit en « emballage » du protocole (POPS, IMAPS et SMTPS), soit dans les protocoles en texte clair, en émettant la commande STARTTLS. Ce second mode, appelé TLS opportuniste, est très intéressant dans les communications entre serveurs, car il permet d'utiliser une communication chiffrée si les deux parties le supportent. Si l'une des deux n'implémente pas la commande, la communication continue sans chiffrement. Ce mode est en cours de déploiement depuis environ deux ans et a provoqué une augmentation massive du chiffrement des échanges SMTP initiant une connexion SSL ([FACEBOOK] [GOOGLE-EMAIL]).

3.2.1 Mode SMTP

Pour les communications via SMTP, nous recommandons de ne pas affecter les suites de chiffrement par défaut de Postfix. Au vu de l'hétérogénéité des configurations sur Internet, il est ici souhaitable d'être capable de supporter tous les cas de figure afin de pouvoir délivrer les courriels de l'utilisateur.

Cela amène d'ailleurs à deux points d'attention :

- D'une part à l'importance d'éduquer les utilisateurs aux risques de transmettre des informations par courriel ;

- D'autre part à l'existence de techniques de chiffrement du contenu des courriels pour en protéger le contenu et/ou en garantir l'intégrité (nous parlons ici des chiffrements S/MIME ou PGP/GPG).

La configuration que nous retrouvons est une configuration standard, si ce n'est qu'elle active le mode opportuniste pour TLS.

3.2.2 Mode MSA

En mode MSA, le client de l'utilisateur communique directement avec le serveur. On peut dès lors se permettre de forcer les algorithmes qui seront employés. Dans le fichier de configuration main.cf, on définit que le chiffrement est obligatoire, que les protocoles faibles sont bannis (SSLv2 et SSLv3) et on précise la suite de chiffrement qui sera proposée à la négociation.

À nouveau, la suite de chiffrement B y a été ici choisie.

Optionnellement, pour les utilisateurs des courbes elliptiques, on peut adapter le paramètre spécifique dans main.cf (il est défini par défaut à « strong ») :

Pour compléter la configuration, il est encore nécessaire de définir les paramètres propres au mode MSA dans le fichier master.cf :

4. Les attaques connues et nos résultats

Depuis les débuts du projet, plusieurs attaques ont été découvertes. Citons, par exemple, HeartBleed, Poodle, Freak, Logjam et, tout récemment, Drown ([TLS-SEC]).

Nous pouvons tirer deux conclusions de ces attaques (méconnues lors de l’écriture de la première version du projet) :

- il est important de valider les implémentations autant que les principes théoriques ;

- si certains paramètres permettaient d'éviter l'attaque, ils faisaient partie des recommandations.

4.1 POODLE

Cette attaque fonctionne en faisant un « man-in-the-middle » pour rétrograder le chiffrement vers SSLv3 ([POODLE]). L'attaquant procède alors à de la duplication de blocs. En moyenne, pour 256 requêtes, il pourra déchiffrer 1 byte.

Pratiquement, cette attaque de 2014 n'est possible que si SSLv3 est autorisé. Notre recommandation de désactiver SSLv3 a rendu l'attaque sur le padding impossible.

Il est à noter que certaines implémentations de TLS étaient quand même vulnérables à POODLE. Le fait que les mises à jour aient corrigé cette faille montre combien il est important de mettre les systèmes d'exploitation à jour.

4.2 TLS Logjam

Cette attaque d'octobre 2015 exploite une vulnérabilité dans le protocole TLS ([WEAKDH]). L'attaque se fait de deux manières différentes au niveau de Diffie-Helleman :

1. Soit en exploitant le support des vieilles suites de chiffrement pour forcer l'utilisation d'algorithmes obsolètes qui utilisent des clés de 512 bits ;

2. Soit en exploitant le fait que, par défaut, des millions de serveurs HTTPS, SSH ou VPN utilisent les mêmes nombres premiers pour l'échange de clés avec Diffie-Helleman.

En configurant la version éphémère de Diffie-Helleman ou des nombres premiers de plus de 1024 bits, l'attaque est évitée. Cela correspond aux recommandations du projet, et cela bien avant l'attaque.

5. Comment tester ?

Après avoir défini de manière théorique les paramètres que nous voulions, de multiples tests ont été effectués pour valider la praticabilité de ceux-ci :

- compatibilité avec les différentes versions de logiciels (les versions testées sont référencées dans le document) ;

- compatibilité de ces choix avec les clients courants ;

- robustesse des choix effectués.

Nous avons testé nos configurations avec de nombreux outils qui sont décrits dans BetterCrypto. Toutefois, l'un d'entre eux mérite d'être mentionné ici. Qualys propose un outil, en ligne, pour tester la robustesse de vos sites Internet. SSLLabs ([SSLLABS]) fait un test exhaustif des algorithmes supportés et produit un rapport incluant les clients qui seront supportés et les éventuelles faiblesses de la configuration choisie. C'est un outil qui devrait être utilisé systématiquement et régulièrement par tous ceux qui déploient des sites Internet.

 

 

L'annexe A du projet BetterCrypto ([BETTERCRYPTO]) propose une liste d'outils pour tester les différents éléments qui feront le succès de la sécurisation des échanges : tests des serveurs et des navigateurs, longueurs des clés et génération de nombres aléatoires.

Conclusion

Si vous consultez le document, vous constaterez que nous avons laissé un marquage « DRAFT ». Même s'il est relativement complet, il continue à évoluer en permanence.

De nombreux projets sont encore sur la table. Nous aimerions écrire un générateur de configurations supportant davantage de logiciels et de versions de ceux-ci. Nous voudrions également ajouter plus de logiciels commerciaux tels que les produits Microsoft par exemple.

Un nouveau format est également envisagé. Nous produisons actuellement un document PDF qui semble ne pas être l'optimum pour copier/coller. Le générateur de configuration serait certes une solution, mais pas complètement satisfaisante. Une réflexion sera probablement entamée sur le meilleur moyen de fournir le contenu pour que son accès soit le plus simple et pratique possible.

Même les choix théoriques sont remis en question régulièrement. Au moment d'écrire ces lignes, des discussions ont lieu sur notre liste de diffusion ([BT-ML]) concernant les suites A et B. La suite A est remise en question, car peu utilisée . Camellia pourrait également être voué à la suppression de la suite B car, autant AES est étudié et attaqué par de nombreux académiques, autant Camellia est pour le moment peu évalué.

Le projet est publié avec une licence Creative Commons Attribution-ShareAlike ([CC BY-SA-3.0]). Vous êtes donc les bienvenus pour apporter votre contribution : que cela soit en utilisant notre projet, en relisant, en proposant de nouvelles sections... Si cela vous tente, n'hésitez pas à rejoindre notre liste de diffusion et à nous contacter.

Finalement, 30 mois après la création du projet, son utilité semble avoir été démontrée à plusieurs reprises. Bien qu’imparfait, il a pour vocation de simplifier l'utilisation correcte de la cryptographie. Si quelques personnes appliquent avec succès nos recommandations, alors ce projet sera un grand succès.

Remerciements

Cet article n'a pu être écrit que grâce à la collaboration de toutes les personnes ayant participé de près ou de loin à ce projet. Et la liste est longue ! Auteurs, lecteurs, critiques, enseignants… nombreux sont ceux qui ont donné leurs avis, leurs commentaires et leurs corrections.

Ce projet est, en particulier, le fruit de la passion d'Aaron Kaplan et Pepi Zawodksy. Ils méritent une mention et un merci tout particulier,

Finalement, impossible de ne pas remercier MISC qui nous offre une opportunité exceptionnelle de présenter notre travail.

Références

[HAC-FS-CHAP12] A. Menezes, P. van Oorschot, and S. Vanstone, Chapitre 12 de «Handbook of Applied Cryptography » ,CRC Press, 1996 : http://cacr.uwaterloo.ca/hac/about/chap12.pdf

[SCHNEIER-AES] Another New AES Attack : https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

[BETTERCRYPTO] Site officiel du projet : https://www.bettercrypto.org

[BC-GIT] Miroir du projet sur GitHub : https://github.com/BetterCrypto/

[KEYLENGH] Cryptographic Key Length Recommendation : http://www.keylenght.com

[JUNIPER_KB] Multiple routers can generate duplicate SSH private keys due to missing entropy : https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10434&actp=search

[HSTS-Wikipedia] HTTP Strict Transport Security : https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[FACEBOOK] The Current State of SMTP STARTTLS Deployment : https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223/

[GOOGLE-EMAIL] Email encryption in transit : https://www.google.com/transparencyreport/saferemail/

[TLS-SEC] An introduction to and survey of TLS Security : http://www.slideshare.net/a_z_e_t/introduction-to-and-survey-of-tls-security-bsideshh-2014

[POODLE] This POODLE Bites: Exploiting The SSL 3.0 Fallback : https://www.openssl.org/~bodo/ssl-poodle.pdf

[WEAKDH] Weak Diffie-Hellman and the Logjam Attack : https://weakÒdh.org

[SSLLABS] Qualys SSL Labs : https://www.ssllabs.com/

[BT-ML] Ach -- Applied Crypto Hardening list : http://lists.cert.at/cgi-bin/mailman/listinfo/ach

[CC BY-SA-3.0] Attribution - Partage dans les Mêmes Conditions 3.0 : https://creativecommons.org/licenses/by-sa/3.0/fr/