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?
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.
Donc finalement, ton programme ne pourrait-il pas tout simplement remplacer Scdaemon de manière transparente?
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.
GnuPG ne communiquerait plus directement avec la carte, mais en cherchant de l'aléa dans les /dev/(u?)random
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.
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?
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 gouttegd . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. É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.