Pour commencer voici un principe de chiffrage sous Linux : les clés doivent être générées dans un contexte où la source d’aléa est fiable, ou à défaut dans un environnement où suffisamment d’entropie a été accumulée
On peut donc se demander qu'est-ce que l'entropie ? Pourquoi faut-il une source fiable ? Comment avoir une meilleure entropie ?
Pour faire simple, admettons que l'entropie représente la capacité de votre serveur à générer des nombres "pseudo" aléatoires. En effet, le système génère ces caractères aléatoire à partir des interruptions matérielles, par exemple par le clavier, la souris, le disque ou les E / S réseau.
Sécurité
Mais déjà, pourquoi générer des nombres aléatoires ? Tout simplement parce que cela fait partie de nombreuses bases d'outils cryptographiques, comme par exemple la génération de clés SSH. En effet la cryptographie repose sur deux fondamentaux : les nombres premiers et les nombres aléatoires.
Mais alors ? quel risque prend-on si on ne génère pas assez d'aléa ? il peut devenir possible de générer deux fois le même couple de clés SSH, et par conséquent, que quelqu'un soit en mesure de se connecter à une machine à laquelle il ne devrait pas avoir accès.
Si vous pensez que cela n'arrive jamais, il suffit de se rappeler la vulnérabilité OpenSSH Debian. En 2008, la version Debian d'OpenSSL s'est trouvée modifiée, et a eu pour conséquence un très faible nombre de possibilités pour générer des clés SSH. La preuve ? On peut trouver sur cette page l'intégralité des clés DSA (1024 et 2048 bits) et RSA (1024 à 4096 bits) possibles via cette version vulnérable. J'admets volontiers que c'est un cas extrême, mais il a le mérite d'être assez parlant.
Performance
Au delà d'un problème de sécurité, la qualité du pool d'entropie a un impact direct sur la qualité de vos SSL / TLS et des autres chiffrements par blocs. En effet, Dans les systèmes d'exploitation de type Unix nous utilisons le fichier spécial /dev/random comme générateur. Celui-ci attends que le pool d'entropie soit rempli pour renvoyer des données aléatoires. En cas de timeout, le système utilisera /dev/urandom qui génèrera donc (avec le pool en sa possession) des données aléatoires de qualité inférieure (probablement répétées). le urandom est donc moins sécuritaire et requiert au passage un timeout donc une perte de temps.
En résumé, si votre serveur gère beaucoup de trafic SSL (et de handshakes) comme le fait n'importe quel serveur Web ou serveur de messagerie, deux choses peuvent se produire:
- Le serveur attend que /dev/random soit à nouveau prêt
- Le serveur bascule vers /dev/urandom ou son propre générateur aléatoire (après un timeout)
C'est donc simple, plus on a d'entropie, mieux c'est.
Mesurer la qualité de l'entropie
Pour mesurer la qualité de l'entropie, c'est très simple :
$ cat /proc/sys/kernel/random/entropy_avail 214
Cette commande vous renvoie un nombre, qui désigne la quantité de nombres aléatoires générés. Il s'agit donc de votre réservoir d'entropie. Et donc, plus il est grand, mieux c'est. Considérez qu'en dessous de 1000, votre serveur risque de souffrir notamment si vous utilisez OpenSSL.
On peut aussi constater que le problème d'entropie affecte particulièrement les machines virtuelles. Cela s'explique surtout par le fait qu'elles disposent de beaucoup moins d'éléments qu'une machine physique, et donc moins d'éléments à lire pour espérer y trouver de l'aléa.
Une autre manière de mesurer l'entropie consiste à utiliser l'outil rngtest (disponible dans le paquet rng-tools pour CentOS). Celui-ci va lancer un certain nombre de tests utilisant le standard FIPS-140.
Par exemple :
$ cat /dev/random | rngtest -c 1000
Cela vous donnera une idée du temps nécessaire à votre serveur pour générer ce réservoir et donc à effectuer un grand nombre d'activités de (dé)chiffrage.
Haveged : générateur d'entropie en espace utilisateur
Haveged est un logiciel qui se présente sous la forme d'un démon qui reste en espace utilisateur. Il tire son nom de l'algorithme qu'il utilise, HAVEGE (HArdware Volatile Entropy Gathering and Expansion).
Côté installation, rien de plus simple, il suffit, pour CentOS, d'avoir accès au dépôt Fedora EPEL. Une fois que c'est fait, un simple yum -y install haveged suffit à disposer du logiciel.
Vous pouvez également indiquer une valeur d'entropie à générer en permanence en éditant ce fichier (ou l'équivalent de votre système type /etc/rc.local ) :
# vi /etc/default/haveged
Contenu :
# Configuration file for haveged
# Options to pass to haveged:
# -w sets low entropy watermark (in bits)
DAEMON_ARGS="-w 2048"
Comme il s'agit d'un démon, il faut le démarrer. Sous CentOS 7, cela se fait via systemd :
# systemctl start haveged.service
Essayez donc maintenant de nouveau le rngtest voir même d'afficher votre réservoir d'entropie. La différence devrait être flagrante, non ? la récupération des informations devrait être quasi-instantanée !
Pour ce qui est d'activer haveged au démarrage, il ne faut pas oublier la commande systemctl qui va bien :
# systemctl enable haveged.service Created symlink from /etc/systemd/system/multi-user.target.wants/haveged.service to /usr/lib/systemd/system/haveged.service.
