Possesseur d’une carte OpenPGP, je cherchais un moyen d’exploiter le générateur de nombres aléatoires dont elle est équipée.
Une rapide recherche m’a immédiatement emmené vers TokenTools, qui semble faire exactement ce que je veux. Malheureusement, ce programme ne peut pas cohabiter harmonieusement avec Scdaemon, le démon de GnuPG chargé d’interagir avec les cartes à puce : TokenTools ne peut pas accéder à la carte tant que scdaemon tourne — or j’ai besoin de scdaemon pour l’utilisation routinière de ma carte OpenPGP (signer, déchiffrer, m’authentifier).
La deuxième partie décrit le programme que l'auteur a écrit pour remplacer Token Tools.
Plutôt que d’envisager une alternance fastidieuse entre scdaemon et TokenTools, j’ai donc entrepris d’écrire un petit programme similaire à TokenTools, mais qui accède à la carte par l’intermédiaire de scdaemon plutôt qu’en concurrence de ce dernier.
Voici donc scdrand, un programme qui obtient quelques octets aléatoires (de 1 à 256) à partir d’une carte à puce compatible¹, et qui les utilise pour approvisionner le pool d’entropie du noyau (le pool qui alimente à son tour /dev/random et /dev/urandom).
L’utilisation est supposée être simple, dès l’instant où un agent GPG et scdaemon sont disponibles et en cours d’utilisation (ce qui devrait probablement être le cas si vous êtes déjà utilisateur d’une carte OpenPGP). Par exemple :
$ scdrand 64
Demande 64 octets aléatoires à la carte, les fournit au noyau et se termine.
Une utilisation un peu plus poussée est la suivante :
$ scdrand -l -i 2 -t 512 256
Ici, scdrand va vérifier toutes les deux secondes s’il y a au moins 512 bits d’entropie disponible dans le pool du noyau, et dans le cas contraire, approvisionner celui-ci avec 256 octets aléatoires en provenance de la carte.
Pour visualiser l’effet de scdrand, j’ai suivi l’état du pool d’entropie du noyau (nombre de bits d’entropie disponibles, consultable dans /proc/sys/kernel/random/entropy_avail) pendant la génération d’une paire de clefs RSA par GnuPG, d’abord sans, puis avec scdrand.
Comme on peut le voir sur le graphe ci-dessus, la génération d’une paire de clefs vide instantanément le pool d’entropie et le maintient à un niveau très bas tant que la paire n’est pas générée. Sans sources d’entropie supplémentaire (GnuPG conseille à ce moment-là de bouger la souris, de saisir n’importe quoi sur le clavier ou de solliciter les disques durs — ce que je n’ai pas fait pour cet exemple), cela a pris ici une quarantaine de secondes, après quoi le noyau a encore besoin d’une trentaine de secondes pour ramener le pool d’entropie au niveau basal.
La deuxième paire de clefs, générée avec scdrand tournant dans un autre terminal, vide tout aussi le pool d’entropie. Mais cette fois-ci, au bout de deux secondes le pool est réapprovisionné par scdrand. En conséquence, trois secondes suffisent à GnuPG pour générer la paire de clefs, et le pool d’entropie revient à son niveau de base en moins de vingt secondes.
Évidemment, si vous ne passez pas votre temps à créer de nouvelles clefs toutes les cinq minutes, l’intérêt de tout celà est sans doute assez limité… Mais si ça vous intéresse tout de même, le code est là :
- Dépôt Git:
git://git.incenp.org/scdrand.gitou via gitweb - tarball: scdrand-0.1.0.tar.gz
¹ La commande GET CHALLENGE permettant la génération de données aléatoires est spécifiée dans le standard ISO 7816-6 et n’est pas spécifique à l’application OpenPGP, donc scdrand devrait pouvoir utiliser d’autres types de carte. Mais je n’ai pu tester qu’avec une carte OpenPGP 2.0.
Aller plus loin
- Journal à l'origine de la dépêche (192 clics)
- Dépôt Git (65 clics)
# Carte OpenPGP
Posté par Wawet76 . Évalué à 10.
« l’utilisation routinière de ma carte OpenPGP (signer, déchiffrer, m’authentifier) »
Tu devrais faire une dépêche la dessus :)
# Vitesse d'utilisation seulement ou aussi sécurité?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
C'est vachement intéressant, mais je me demandais si le but est seulement d'améliorer la vitesse d'utilisation des logiciels qui utilisent /dev/random et /dev/urandom ou si cela en améliorait aussi la "qualité" d'aléatoire. De l'aléa de meilleur qualité que ce qu'il y a en général dans ces interfaces.
Aussi quand tu crées une clé, pour reprendre ton exemple, la clé peut-elle être plus "sûre" avec du bon aléa? Y a-t-il une notion de qualité d'une clé, deux clés de la même taille peuvent-elles avoir intrinsèquement une sécurité différente?
Sinon oui, comme le commentaire au dessus, je suis curieux de connaître l'utilité générale d'une telle carte, car je n'ai jamais eu affaire à quiconque qui en avait une. Comment ça s'utilise, etc.
En tous cas, ton outil a quand même l'air extra et améliore grandement l'utilité existante de ces cartes en les rendant utile génériquement (transparent pour toute application qui utilise /dev/(u?)random et qui utilisera donc la carte indirectement sans le savoir). C'est génial. Si ce n'est déjà fait, tu devrais t'associer avec un projet plus gros, probablement GNUPG, et leur soumettre ton utilitaire pour que cela soit installé par défaut chez toute autre personne qui aurait une telle carte.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par gouttegd . Évalué à 10.
Je ne pense pas que ça en améliore la qualité.
Dans le meilleur des cas (si le générateur de nombres aléatoires de la carte est correct), logiquement la qualité est la même. Un bit d’entropie en provenance de la carte revient au même qu’un bit d’entropie en provenance des autres sources utilisées normalement par le noyau, c’est juste que la carte est capable d’en délivrer plus rapidement.
Dans le pire des cas (si le générateur de la carte est mauvais — ce que je suis incapable de déterminer, mais qui peut arriver), la qualité serait a priori réduite, mais l’effet devrait être mitigé par les traitements réalisés aussi bien en entrée qu’en sortie du pool.
À noter que dans le noyau Linux, c’est à celui qui ajoute de l’aléa dans le pool qu’il revient d’estimer quelle est l’entropie réellement ajoutée. Pour cette première version de scdrand, je suis parti du principe que le générateur de la carte est correct et produit bien des octets complètement aléatoires. En conséquence, scdrand estime qu’un octet en provenance de la carte = 8 bits d’entropie. Une évolution possible de scdrand serait de permettre à l’utilisateur de modifier ce comportement et d’estimer lui-même la « valeur » des octets générés par la carte.
Oui.
Une clef se doit d’être unique. L’unicité est normalement assurée par le fait de tirer la clef au hasard dans un très grand espace, la probabilité que deux personnes tirent la même clef étant virtuellement nulle. Mais si les clefs sont générés avec une entropie insuffisante, cette probabilité augmente, et avec elle le risque d’avoir des clefs dupliquées dans la nature. Ce risque n’est pas que théorique.
Les clefs RSA sont particulièrement vulnérables, car leur génération nécessite non pas un mais deux grands nombres premiers. Ces deux nombres sont supposés être uniques à chaque clef. Si, en raison d’un mauvais RNG, plusieurs clefs RSA partagent un même facteur, elles sont toutes trivialement cassables.
Il y a l’air d’avoir du monde intéressé (je vois que le commentaire du dessus est à 10…), je vais voir si je peux écrire quelque chose là-dessus.
Pour bien rendre à César ce qui lui appartient, l’idée géniale d’alimenter le pool d’entropie du noyau vient de l’auteur de TokenTools. Je n’ai écrit scdrand que parce qu’une utilisation simultanée de GnuPG (donc de scdaemon) et de TokenTools semble impossible.
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par jben . Évalué à 9. Dernière modification le 15 août 2014 à 02:17.
Un exemple très marquant pour illustrer cela c'est le bug introduit dans la version openssl de Debian. L'espace des clef était au final si faible qu'obtenir un doublon devenait possible sans problèmes.
Si tu as envie de partir sur une dépêche collaborative, j'en suis. En fait je penserai même à une dépêche générale GnuPG, avec clefs, certifications, signatures, chiffrement, sous-clefs, et smartcard. Si ça te tente, vas-y, j'arrive.
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par gouttegd . Évalué à 4.
Why not? OK, je vais commencer quelque chose dans mon coin (probablement ce week-end) et initier une dépêche avec.
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Mais ce type de carte ne marche qu'avec GNUPG? J'imagine que c'est quand même plus générique et que cela peut avoir d'autre usage, non? Parce que si c'est le cas, je préférerai un article sur ce type de carte et ses différents usage, à quoi ça sert, à quoi ça ne sert pas (par ex si j'ai bien compris, cela ne rend pas les choses plus sûrs, mais plus rapides, etc.), quels logiciels peuvent en tirer profit, etc.
Ça empêche pas de faire aussi un article séparé sur GNUPG si vous voulez, mais je ne voudrais pas que cela éclipse le sujet de ce type de carte, perso. Donc 2 articles, c'est peut-être mieux. Un qui focalise sur les cartes, l'autres sur GNUPG. Car GNUPG, bon je suis pas expert, mais je connais déjà un peu. Par contre ces cartes, ça m'intrigue. Je savais que ça existait, mais c'est la première fois que je lis un cas d'utilisation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par gouttegd . Évalué à 3. Dernière modification le 15 août 2014 à 22:26.
Non. Les cartes cryptographiques obéissent généralement au standard PKCS#15 de RSA Laboratories. N’importe qui peut écrire un programme interagissant avec une carte de ce genre.
La carte OpenPGP est une application spécialement conçue pour fonctionner avec GnuPG (ce sont les mêmes développeurs qui en sont à l’origine), mais à ma connaissance elle est aussi conforme au standard PKCS#15 et devrait donc pouvoir être utilisée avec tout programme supportant ce standard.
Inversement, GnuPG supporte aussi les cartes PKCS#15 standards et non pas seulement « sa » carte spécialisée.
Je comprends, mais pour ma part mon expérience avec les smartcards cryptographiques se limite à la carte OpenPGP couplée à GnuPG…
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par jben . Évalué à 3.
Idem pour moi. Même si je suis d'accord sur le fait que faire un article spécialisé sur les smartcard PKCS#15 serait interessant, je n'ai les compétences que pour participer à la rédaction d'une article sur les smartcard OpenPGP. Après il faut aussi voir, qu'à l'aide des outils fournis les utilisations sont tout de même variés, en effet, il est courant de l'utiliser pour l'authentification via ssh ou en local, donc l'utilisation ne se limite pas à signer ou à chiffrer avec OpenPGP.
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par tao popus . Évalué à 1.
Les processeurs ARM ont généralement une unité de chiffrement intégrée (cryptoprocesseur). Pour prendre les processeurs tout récents et abordables, le Rockchip RK3288, très bien géré par Linux (bonne communauté de libriste pour libérer + efforts de la société Rockchip plus récemment si j'ai bien suivit) permet de traiter les algorithmes AES 128bits, DES, 3DES, SHA-1, SHA-256, MD5 et PRNG 160bits. C'est pareil sur les processeurs Allwinner et Samsung (pour citer les plus répandus).
Est-ce que ces logiciels sont adaptés à l'utilisation de ces unités cryptographiques ? Est-ce qu'il existe des outils permettant d'analyser et d'auditer la fiabilité de ces unités de calcul (benchmark de fiabilité ?)
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par fmaz fmaz . Évalué à 10.
Ce qui rend les choses encore plus compliquée avec RSA, c'est que si on veut des clefs de bonne qualité, il ne faut pas simplement prendre deux nombres premier p et q au hasard.
Petit rappel, n=pq est un élément des clefs publiques et privées. Si on sait factoriser n, on est mort. Or, si il existe des algorithmes de factorisation qui fonctionnent bien dans des cas particuliers. Exemples:
Si p ou q est petit, c'est mort. Même le crible d'Ératosthène devient utilisable. Mais c'est aussi le cas de méthodes plus sophistiquée.
Si p-q est petit, c'est mort aussi. Preuve. On pose n=pq et k=p-q.
Comme (p+q)²=k²+4n, on a p+q=\sqrt(k²+4n). Donc 2p=\sqrt(k²+4n)-k. Il ne reste plus qu'à tester toutes les « petites » valeurs de k.
Bref, générer de bonnes clefs RSA, c'est TRÈS compliqué.
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par khivapia . Évalué à 2.
p ou q est petit (…) Si p-q est petit
Ça arrive avec probabilité (cryptographiquement) faible si les nombres sont sur un nombre de bits correct. Par exemple, si on tire p et q premiers aléatoires sur 512 bits (soit une clef RSA de 1024 bits, déjà non recommandée car bien trop petite) correctement (c'est-à-dire qu'on les tire comme des nombres aléatoires sur 512 bits, puis s'ils ne sont pas premiers on recommence avec un nouveau nombre aléatoire sur 512 bits), alors la probabilité que p soit inférieur à 2256 est inférieure à 2-256. La probabilité que p - q soit inférieure à 2256 est inférieure à 2-128 (il faut que les deux nombres p et q coïncident sur leurs 256 bits de poids fort).
Cela dit générer une clef RSA reste piégeux : outre l'absence de biais sur l'aléa utilisé, il ne faut pas que p-1 ou q-1 aient trop de facteurs petits, et bien d'autres vérifications sont à faire.
# pilote noyau
Posté par Krunch (site web personnel) . Évalué à 3.
Est-ce que ce type de projet n'aurait pas plutôt sa place en tant que driver kernel ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: pilote noyau
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
C'est vrai, y a de quoi se poser la question. D'ailleurs quelque chose d'autre m'a intrigué: pour les utilisations "routinières" dont tu parles (signer, déchiffrer, authentifier), s'il n'y avait pas la carte, les logiciels de cryptage (GnuPG en tête donc) tirerait profit de /dev/(u?)random, non? Donc finalement, ton programme ne pourrait-il pas tout simplement remplacer Scdaemon de manière transparente? GnuPG ne communiquerait plus directement avec la carte, mais en cherchant de l'aléa dans les /dev/(u?)random, il utiliserait indirectement la carte en fait, sans même avoir à le savoir.
Ou alors la carte a d'autres fonctionnalités et son rôle n'est pas uniquement de produire de l'aléa rapidement. Y a un processeur dédié pour accélérer des calculs de crypto aussi, peut-être?
Comme je le disais, je connais rien à ces cartes, donc ces questions sont peut-être un peu ridicules, mais bon. C'est bien pour ça qu'on demande un article supplémentaire dessus. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 9.
Non. Quand GnuPG a besoin de nombres aléatoires, il va toujours les chercher dans
/dev/(u)random, présence d’une smartcard ou pas. C’est justement pour ça qu’il faut un programme comme scdrand si on veut tirer profit du générateur de nombres aléatoires embarqués sur la carte.L’utilité principale d’une smartcard cryptographique est de stocker des clefs privées, pas de générer des nombres aléatoires. Il se trouve qu’une carte de ce genre contient un générateur matériel de nombres aléatoires, pour deux raisons : pour pouvoir générer des clefs directement sur la carte, et pour pouvoir générer des « challenges » utilisés dans les protocoles d’authentification.
Non. scdaemon est le démon en charge de communiquer avec la smartcard. Il interagit directement avec le lecteur de carte, transmets les messages APDU à destination de la carte et reçoit les réponses. Il permet aux programmes voulant exploiter une smartcard (que ce soit GnuPG ou scdrand) de ne pas avoir à se soucier des pilotes de lecteurs de carte ni du protocole APDU, en exposant une API assez simple.
scdrand pourrait faire tout ça et remplacer complètement scdaemon, mais quel serait l’intérêt ? scdaemon fait très bien le job.
Comme dit ci-dessus, GnuPG va toujours chercher l’aléa dont il a besoin dans
/dev/random, jamais sur la carte. Lorsque GnuPG communique avec la carte (ce qu’il ne fait jamais directement, mais par l’intermédiaire de scdaemon), ce n’est pas pour obtenir de l’aléa mais pour lui confier les opérations cryptographiques que seule la carte peut faire, c’est-à-dire les opérations qui nécessitent les clefs privées.C’est presque ça, sauf que les calculs de crypto sont fait sur la carte non pas pour les accélérer (c’est peut-être plus rapide sur la carte, je n’ai pas vérifié mais ce n’est pas le but premier), mais pour protéger les clefs privées : en réalisant les opérations cryptographiques sur la carte, on évite d’avoir à faire sortir les clefs de la carte, même temporairement.
[^] # Re: pilote noyau
Posté par Krunch (site web personnel) . Évalué à 3.
L'intérêt que je vois de faire ça au niveau noyau serait surtout de pouvoir éviter le polling de /proc/sys/kernel/random/entropy_avail. Tu pourrait t'arranger pour rajouter de l'entropie directement au fur et a mesure qu'elle est consommée et éviter ou grandement réduire les trous dans ton graph sans avoir a poller sans arret.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 8.
En quelques mots, pourquoi je n’ai pas fait ni n’envisage de faire de scdrand un module noyau.
Vouloir faire ce que fait scdrand dans le noyau impliquerait, entre autres choses, de déplacer les pilotes de lecteurs de carte dans le noyau (actuellement, ils sont en espace utilisateur, gérés par le projet pcsc-lite notamment), ainsi que toute la logique de communication avec les cartes. C’est faisable, certes, mais c’est pas mal de boulot. Si je suis passé par scdaemon, c’est justement pour ne pas avoir à implémenter tout ce qu’il fait moi-même.
Ensuite, si c’est un module qui prend désormais en charge la communication avec les cartes à puce, ça veut dire que les programmes en espace utilisateur ne peuvent plus le faire directement. Tous les projets concernés par les cartes à puce (comme GnuPG et son programme scdaemon) devraient revoir complètement leur architecture pour utiliser une interface exportée par le noyau plutôt que d’utiliser l’API de pcsc-lite.
Ça fait de gros changements juste pour éviter à un programme d’interroger régulièrement l’état du pool d’entropie…
Par ailleurs, même à l’intérieur du noyau, il n’y a pas de mécanisme prévu pour informer automatiquement un module que l’entropie disponible dans le pool tombe en-dessous d’un certain seuil, ce serait encore une autre chose à changer.
Enfin, une considération un peu moins technique : la carte à puce appartient à un utilisateur donné, ce n’est pas un périphérique appartenant à l’ordinateur. J’estime que ce n’est pas au noyau de décider arbitrairement de solliciter ma carte quand bon lui semble.
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 4.
Correction, je viens de voir qu’un tel mécanisme existe et est même accessible depuis l’espace utilisateur. Il faut ouvrir
/dev/randomen écriture et utiliser poll(2) ou select(2) sur le descripteur de fichier, le noyau signalera alors au processus (par retour de poll ou select) dès que l’entropie disponible tombe en-deça du seuil défini dans/proc/sys/kernel/random/write_wakeup_treshold(896 par défaut, chez moi).Ce qui est dommage, c’est que ce seuil, même s’il est modifiable, est défini pour tout le système, il n’est pas possible de le modifier pour un seul processus. Du coup je ne pense pas utiliser ce mécanisme, il ne me paraît pas approprié que scdrand modifie un paramètre system-wide pour son seul bénéfice.
[^] # Re: pilote noyau
Posté par Krunch (site web personnel) . Évalué à 4.
La nature de /dev/u?random est system-wide. Comment est-ce que tu imaginerais un système qui permettrait d'avoir un write_wakeup_treshold par processus ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 2.
Je sais bien que ce n’est pas possible, c’est pour ça que ce n’est pas adapté à la situation. Je préfère poller « manuellement » plutôt que de toucher un paramètre affectant le système entier.
[^] # Re: pilote noyau
Posté par Yann Hodique (site web personnel) . Évalué à 4. Dernière modification le 19 août 2014 à 06:22.
Je pense qu'il voulait dire que bien que le pool soit global, le niveau d'épuisement auquel réagir pourrait varier suivant le processus qui pourrait être utilisé pour réapprovisionner (le processus en question pourrait par exemple créer son fichier treshold propre, et l'enregistrer auprès du sous-système random). On pourrait notamment imaginer des sources d'entropie plus ou moins coûteuses/efficaces, qui seraient mises à contribution suivant l'urgence de la situation. Mais ça reste un peu artificiel.
Ceci dit, ça ne me semblerait pas délirant que scdrand respecte cette constante, qui est supposée représenter le seuil à partir duquel "quelqu'un" doit réapprovisionner le pool si possible, au lieu d'avoir son propre seuil.
Même si le seuil est relativement bas, le simple fait de réagir à une notification au lieu de vérifier périodiquement devrait permettre d'éviter encore plus les trous dans le niveau d'entropie.
Au passage, légèrement hors-sujet, je viens de tomber sur ce projet qui m'a l'air fort intéressant (mutualisation des sources d'entropie): http://www.vanheusden.com/entropybroker/
Justement les pertes de performance liées à la rareté de l'entropie en environnements virtualisés sont un de mes problèmes actuels, je suis content :)
Ça soulève pas mal de questions, bien sûr (notamment quant à la notion de distribution de confiance), mais c'est sympa de voir qu'il y a des tentatives de solution.
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 3.
Je trouve au contraire que le seuil est un peu trop haut.
Chez moi, il est à 896 (valeur par défaut, je n’y ai pas touché). Or d’après ce que j’ai constaté, il arrive très régulièrement que l’entropie disponible tombe légèrement en-deça, même si ça ne dure jamais très longtemps. En fait, en utilisation « normale » de la machine (i.e., même en l’absence de gros consommateurs d’entropie comme GnuPG), l’entropie disponible oscille constamment quelque part entre 800 et 1000, comme on le voit d’ailleurs sur le graphe inclus dans le journal.
Mais comme on le voit aussi, l’entropie disponible remonte toujours assez rapidement, donc déclencher une intervention de scdrand à chaque petite « excursion » en dessous du seuil de 896 me paraît exagéré.
Cela étant, utiliser la valeur de
write_wakeup_tresholdcomme seuil d’intervention pourrait très bien être un comportement optionel (à la discrétion de l’utilisateur), je vais envisager ça.[^] # Re: pilote noyau
Posté par Yann Hodique (site web personnel) . Évalué à 2.
Ah oui, intéressant, je n'avais pas relevé cette valeur qui est effectivement assez haute. Si je ne m'abuse, la valeur par défaut du noyau est 128, read_wakeup_threshold étant lui à 64.
Par curiosité, c'est quelle distribution ? (Google semble me suggérer que ça pourrait être redhat, mais je n'en ai pas sous la main)
Aussi, je pense qu'il faut prendre en considération le delta entre read_wakeup_threshold et write_wakeup_threshold pour se faire une idée plus précise, puisque c'est la "zone" dans laquelle le kernel souhaite maintenir l'entropie (puisque seul un "gros" consommateur d'entropie va être en mesure de faire descendre en dessous de read_wakeup_threshold). Au vu du comportement que tu observes, je soupçonne que read_wakeup_threshold est configuré relativement haut aussi ?
Mais effectivement avec des niveaux aussi hauts, ça peut être un peu overkill d'aller taper le userland pour restaurer de l'entropie alors qu'on n'est pas forcément vraiment en manque. Aux valeurs de base que je mentionnais plus haut, ça se justifierait davantage peut-être.
En y réflechissant un peu plus, ça me semblerait d'ailleurs étrange de configurer des valeurs aussi hautes pour les seuils. J'ai l'impression que ça rendrait l'ensemble des consommateurs plus à la merci des pics d'un gros consommateur: dans un cas où on a N petits consommateurs et 1 gros, dès que le gros passe tous les petits vont devoir attendre que l'entropie remonte à un niveau très élevé. Au contraire quand les seuils sont plus bas, on va réveiller tout le monde régulièrement, et probablement en pratique ralentir le gros au bénéfice des petits.
Bon en même temps il semblerait que certains consommateurs ajustent leur consommation en fonction du niveau disponible, pour rendre les choses encore plus complexes…
Ça semble pas trivial à ajuster proprement au profil d'utilisation tout ça :)
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 2.
Dans la version que j’utilise actuellement (3.15.2), c’est bien 896, définie dans
drivers/char/random.c:Slackware, mais elle ne touche pas à cette valeur.
Non, 64. Là encore, c’est la valeur par défaut du noyau.
[^] # Re: pilote noyau
Posté par Tonton Th (Mastodon) . Évalué à 3.
Question peut-être idiote : pourquoi 28 ?
[^] # Re: pilote noyau
Posté par gouttegd . Évalué à 3.
Bonne question, mais c’est à Theodore Ts’o qu’il faudrait la poser.
De ce que je comprends du patch qui a introduit ce changement, le seuil
random_write_wakeup_thres(ancien nom derandom_write_wakeup_bits, la variable a été renommée peu de temps après ce patch) a en fait deux rôles distincts :si l’entropie est inférieure à ce seuil, on réveille les processus en attente d’écriture dans
/dev/random(c’est la raison d’être initiale de cette variable) ;si l’entropie est supérieure à ce seuil, ça indique que le pool d’entrée commence à être raisonnablement rempli, suffisamment en tout cas pour qu’on puisse commencer à taper dedans pour approvisionner les pools de sortie.
Cette seconde signification, introduite par ce patch, est probablement la raison pour laquelle le seuil a été relevé de 128 à 896 bits.
[P.S. : Quelle est la logique qui fait apparaître ce strip lors de la prévisualisation ? Une discussion qui dure est forcément présumée être un débat enflammé ?]
[^] # Re: pilote noyau
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Profondeur du fil et non mais ça indique un débat en tout cas.
[^] # Re: pilote noyau
Posté par Yann Hodique (site web personnel) . Évalué à 1.
Je ne pense pas que ce soit nécessaire (et clairement ça ne serait pas souhaitable, pour les raisons que tu décris). Le kernel est tout à fait capable d'aller discuter avec le userland, en utilisant le usermode-helper.
Après la question est effectivement de savoir si le (super) user prête un token au noyau en prenant la responsabilité de la qualité de l'entropie, ou si le noyau décide de lui-même d'aller utiliser tout ce qui ressemble à du PKCS#15.
Je pense que les 2 scénarios ont du sens, en particulier je serais tenté d'utiliser l'approche module pour un scénario type "datacenter", où la sécurité physique est supposément gérée, et où les serveurs pourraient être "équipés" de smartcards (pour pallier l'absence de TPM peut-être ?), qui appartiendraient de ce fait au système
# Comment la puce fait-elle pour générer des nombres vraiment aléatoires ?
Posté par Ludo . Évalué à 5.
Tout est dans le sujet, je me demande pourquoi si c'est si facile de faire ceci via une smartcard, pourquoi ce n'est pas directement intégré dans nos ordinateurs ?
[^] # Re: Comment la puce fait-elle pour générer des nombres vraiment aléatoires ?
Posté par gouttegd . Évalué à 7.
C’est déjà (parfois) « intégré dans nos ordinateurs » :
Le noyau Linux utilise automatiquement l’instruction RDRAND si elle est supportée par le processeur (dans ce cas c’est une des sources d’entropie alimentant les pools derrière
/dev/randomet/dev/urandom). S’il y a un RNG sur la carte mère ou dans le TPM, le noyau le met à disposition directe de l’espace utilisateur via/dev/hw_random, mais ne l’utilise pas lui-même.Quant aux principes de fonctionnement des RNG matériels, tout ce que je sais, c’est que ça repose sur la mesure de phénomènes physiques imprévisibles (quantiques notamment). Si quelqu’un d’autre dans le coin est capable d’en dire plus…
[^] # Re: Comment la puce fait-elle pour générer des nombres vraiment aléatoires ?
Posté par khivapia . Évalué à 4.
Linux utilise automatiquement l’instruction RDRAND si elle est supportée par le processeur
S’il y a un RNG sur la carte mère ou dans le TPM, le noyau (…) ne l’utilise pas lui-même.
Pourquoi une telle différence de traitement ? On fait plus confiance à Intel qu'aux fabricants de TPM ?!?
[^] # Re: Comment la puce fait-elle pour générer des nombres vraiment aléatoires ?
Posté par aiolos . Évalué à 1.
Les cartes à puce ne produisent pas de nombres vraiment aléatoires : pour faire du "vrai" aléa, il faut une source physique que n'ont pas les cartes (et encore, les sources physiques sont filtrées).
L'avantage d'une carte pour ce genre de chose, c'est que c'est le cœur de métier des fondeurs que d'implémenter de la crypto efficace, qu'ils ont des processeurs disposant des instructions qui vont bien. Tu as donc des chances d'avoir une implémentation efficace et fiable (la plupart des cartes sur le marché sont auditées).
[^] # Re: Comment la puce fait-elle pour générer des nombres vraiment aléatoires ?
Posté par wagaf . Évalué à 1.
L'instruction RDRAND d'Intel se base, à ma connaissance, sur le bruit électronique du CPU qui est assimilable à du vrai aléatoire car à ces échelles (22nm) les effets quantiques ont une grande importance.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.