Sur le caractère aléatoire des données
Choisir un nombre aléatoire peut sembler être une évidence pour nous, les humains. Nous fermons simplement les yeux et prononçons le premier chiffre qui nous vient à l’esprit. Mais est-ce vraiment le cas pour les ordinateurs ? De par leur conception, ils devraient être assez prévisibles. Avec les mêmes données d’entrée et le même programme, l’ordinateur devrait toujours donner des résultats identiques.
Pourtant, le hasard est très crucial en informatique. Par exemple, des données aléatoires sont utilisées pour produire des clés de certificats ou des jetons d’accès. Si le contenu généré pouvait être prédit par des attaquants, la sécurité de l’application serait compromise.
Alors, comment les données aléatoires sont-elles réellement générées ?
Nombres pseudo-aléatoires
Vous avez peut-être entendu parler générateurs de nombres pseudo-aléatoires (PNG). PRNG est un algorithme déterministe qui peut générer une séquence de nombres qui semblent aléatoires.
Le PRNG est initialisé avec la valeur initiale appelée graine. PRNG démarré avec une certaine graine produira toujours la même série de nombres. Il s’agit parfois d’une propriété très peu pratique, par exemple lors des tests unitaires. Si certaines données d’entrée générées par PRNG provoquent l’échec du test, nous pouvons reproduire l’erreur de manière déterministe en transmettant la même graine.
Les nombres dérivés des PRNG doivent avoir des propriétés statistiques appropriées. En pratique, ce n’est pas toujours le cas. Un exemple de défaut de l’algorithme pourrait être une corrélation indésirable ou une distribution inégale des nombres générés.
Pour que l’algorithme PRNG soit adapté à des fins cryptographiques, il doit passer des tests statistiques restrictifs. Une exigence pour un générateur pseudo-aléatoire cryptographiquement sûr est qu’un attaquant n’a qu’un avantage négligeable pour distinguer la séquence de sortie du générateur d’une séquence véritablement aléatoire.
Pourtant, les valeurs générées par une telle source ne sont sûres que si l’adversaire ne connaît pas la valeur initiale. L’utilisation de semences prévisibles peut entraîner de graves problèmes de sécurité. Un exemple d’une telle vulnérabilité vient des débuts d’Internet. En 1994, le cryptage SSL employé par le navigateur Netscape Navigator utilisait les numéros générés par le PRNG. L’implémentation a amorcé l’algorithme à partir de trois sources : un ID du processus, un ID du processus parent et l’heure actuelle. Ces valeurs se sont révélées facilement devinables. En déterminant la valeur initiale utilisée dans PRNG, un attaquant potentiel a pu déchiffrer le trafic.
Il semble donc que pour initialiser en toute sécurité un générateur aléatoire, nous ayons d’abord besoin d’un nombre aléatoire. Alors, comment pouvons-nous l’obtenir?
Générateurs aléatoires cryptographiquement sûrs
Fait intéressant, l’activité humaine est une source très efficace d’aléatoire. Les mouvements de la souris ou les frappes au clavier se produisent à intervalles irréguliers, donc s’ils sont mesurés, ils peuvent être à l’origine de valeurs aléatoires. Linux enregistre toutes les interactions des utilisateurs, les transforme en octets et les place dans le soi-disant piscine d’entropie. En règle générale, nous pouvons dire que plus l’entropie est collectée dans le pool, plus le générateur aléatoire devient robuste.
Les octets aléatoires peuvent être lus ultérieurement en accédant au fichier spécial /dev/random. Si le pool n’a pas accumulé suffisamment d’entropie, la lecture de /dev/random bloquera. Cela peut se produire lorsque le système vient d’être redémarré et n’a pas encore été en mesure de remplir le pool ou que les valeurs sont lues plus rapidement qu’elles ne sont produites et que le pool est épuisé.
Linux offre également une alternative non bloquante appelée /dev/urandom (aléatoire illimité), qui réutilise le pool interne pour produire davantage de bits pseudo-aléatoires. Cela signifie que la lecture de urandum ne bloquera pas, mais la sortie peut contenir moins d’entropie. En théorie, c’est moins sûr, mais au moment où j’écris cet article, il n’y avait aucune mise en œuvre pratique de l’attaque. Il y a aussi /dev/arandomqui ne bloque que jusqu’à ce qu’il y ait suffisamment d’entropie pour initialiser la valeur de départ, puis ne bloque plus jamais car les octets suivants sont générés à l’aide de l’algorithme PRNG.
Des valeurs aléatoires peuvent également être créées via des sources matérielles, appelées générateurs de nombres aléatoires matériels (HRNG), ou vrais générateurs de nombres aléatoires (TRNG). Il s’avère qu’il suffit juste d’observer les événements physiques qui se produisent tout autour de nous pour obtenir des échantillons aléatoires de données. Peu importe qu’il s’agisse du bruit de courant électronique ou de la gigue de la puce d’horloge ; si c’est difficile à prévoir, alors c’est une source viable de hasard. Ainsi, le travail du HRNG consiste simplement à mesurer l’un de ces phénomènes naturels et à remplir son pool d’entropie interne. Les processeurs Ivy Bridge d’Intel fournissent un HRNG intégré, qui échantillonne le bruit thermique du processeur. Les valeurs peuvent ensuite être récupérées à l’aide de RDRAND ou RDSEED instructions.
Un autre exemple étonnant d’utilisation de mesures d’événements physiques pour collecter l’entropie est appliqué dans Cloudflare. Ils utilisent un ensemble de lampes à lave posées sur des étagères. La caméra prend une photo du mur à un intervalle programmé, puis l’image numérisée est utilisée comme source d’octets aléatoires. Étant donné que le mouvement des fluides à l’intérieur de la lampe est impossible à prévoir, ils ont tendance à être une source très efficace d’aléatoire. Les employés de Cloudflare appellent cela un « mur d’entropie ».
Les HRNG sont très utiles dans les environnements où il y a très peu ou même pas de bruit provenant des interactions des utilisateurs, comme les serveurs. Ils ont tendance à être plus lents que les PRNG, donc très souvent, une valeur provenant du générateur matériel n’est utilisée que pour amorcer l’algorithme pseudo-aléatoire, en particulier lorsqu’un volume élevé d’octets aléatoires est requis. Pour augmenter la sécurité, les graines peuvent être tournées de temps en temps.
Pourquoi devrions-nous nous en soucier ?
Il peut sembler que la question d’assurer la bonne qualité des données aléatoires ne nous concerne que si nous traitons directement de la cryptographie, mais ce n’est pas nécessairement le cas.
L’utilisation de générateurs aléatoires sûrs peut être importante si vous générez une valeur qui ne devrait pas être devinable, comme un jeton pour réinitialiser le mot de passe. En utilisant des PRNG faibles ou des graines prévisibles, vous pouvez introduire des vulnérabilités de sécurité dans votre application Web. Pour cette raison, pour de telles applications, n’oubliez pas d’utiliser java.security.SecureRandom à Java, os.urandom() en Python ou des fonctions similaires dans d’autres langages.
Prends soin de toi!