kudelskisecurity/cdfOutil de fuzzing différentiel automatisé pour les logiciels cryptographiques, détectant les erreurs d'implémentation, les défauts de conformité et les fuites par canaux auxiliaires grâce à des tests intelligents et parallélisés sur plusieurs langages et plateformes.
CDF est un outil pour tester automatiquement la correction et la sécurité des logiciels cryptographiques. CDF peut détecter des erreurs d'implémentation, des non-conformités, des fuites par canaux auxiliaires, etc.
CDF implémente une combinaison de tests unitaires avec du « fuzzing différentiel », une approche qui compare le comportement de différentes implémentations des mêmes primitives lorsqu'elles sont soumises à des cas limites et à des valeurs maximisant la couverture de code.
Contrairement aux fuzzeurs génériques et aux logiciels de test, CDF est :
Intelligent : CDF sait quel type d'algorithme il teste et s'adapte aux fonctions testées
Rapide : CDF teste uniquement ce qui doit être testé et parallélise ses tests autant que possible
Polyvalent : CDF n'est spécifique à aucun langage ou API, mais prend en charge des programmes ou scripts exécutables arbitraires
Portable : CDF fonctionnera sur toute plateforme Unix ou Windows, car il est écrit en Go sans dépendance spécifique à une plateforme
Le but de CDF est de fournir un outil de test plus efficace aux développeurs et aux chercheurs en sécurité, étant plus efficace que les vecteurs de test et moins coûteux qu'un audit manuel de vérification formelle.
CDF a été présenté pour la première fois à Black Hat USA 2017. Vous pouvez consulter les diapositives de notre présentation, qui contiennent des informations générales sur la raison d'être et la conception de CDF.
CDF est codé en Go, la version actuelle a été développée avec Go 1.8. Il n'a aucune dépendance en dehors de la de Go.
Cependant, nous fournissons des exemples de programmes à tester avec CDF, qui sont en C, Python, C++, Java et Go et nécessitent des bibliothèques cryptographiques spécifiques pour être exécutés. Les bibliothèques actuellement requises sont :
make construira le binaire cdf.
Un ensemble de programmes d'exemple sont disponibles dans example : make examples-all construira tous les exemples, tandis que make examples-go ne construira que les exemples Go.
make test exécutera les tests unitaires (de CDF).
Pour commencer, vous pouvez consulter les informations d'utilisation en exécutant cdf -h.
Vous pouvez ensuite essayer un exemple tel que l'interface rsaenc contre les exemples RSA OAEP Go et CryptoPP. En considérant CryptoPP comme référence, vous pouvez tester l'implémentation Go en faisant :
cdf rsaenc /examples/oaep_rsa2048_go /examples/oaep_rsa2048_cryptopp
Cette commande effectuera divers tests spécifiques à l'interface rsaenc.
Dans cet exemple, CDF devrait signaler un problème concernant la taille maximale de l'exposant public prise en charge par l'implémentation Go : si nous vérifions son code, nous voyons que l'exposant public est stocké comme un entier normal, alors que dans CryptoPP (et la plupart des autres implémentations), il est stocké comme un grand entier. C'est cependant par conception et ne sera probablement pas modifié.
Les paramètres sont définis dans config.json.
La plupart des paramètres sont explicites. Vous pouvez définir d'autres clés privées pour rsaenc et ecdsa (ces interfaces sont testées avec des clés fixes, bien que certains paramètres de clé, comme les exposants, soient modifiés dans certains tests).
Le paramètre seed vous permet de modifier la graine utilisée dans les générateurs pseudo-aléatoires de CDF. (Cependant, le programme testé peut utiliser un PRNG ensemencé autrement, comme les exemples OAEP.) Le paramètre concurrency vous permet de définir le nombre de goroutines concurrentes que CDF doit lancer lors de la duplication des programmes. Notez qu'il est préférable de garder ce nombre en dessous du nombre réel de cœurs. Le paramètre verboseLog, s'il est défini sur true, écrira toutes les entrées et sorties des programmes, même pour les tests réussis, dans un fichier log.txt.
Afin de tester votre logiciel avec CDF, vous devez créer un programme qui lit les entrées et écrit les sorties conformément aux interfaces CDF, et qui appelle en interne le programme testé. Les interfaces CDF sont des abstractions d'une fonctionnalité cryptographique, afin de permettre des tests en boîte noire d'implémentations arbitraires.
Par exemple, si vous avez implémenté le schéma de signature ECDSA, votre programme doit satisfaire l'interface ecdsa et ainsi prendre en entrée 4 ou 5 arguments, respectivement pour signer un message ou vérifier une signature. Ces arguments sont la coordonnée X publique, la coordonnée Y publique, le grand entier D privé et le message que vous voulez signer, puis il doit sortir uniquement les grands entiers R et S, chacun sur une nouvelle ligne. Ou, pour vérifier un message, il doit accepter X, Y, R, S et le message, puis il doit seulement sortir True ou False. Les spécifications des interfaces sont détaillées ci-dessous.
Nos exemples d'implémentations d'interface vous aideront à créer les vôtres.
La gestion des erreurs est laissée au programme testé, cependant pour avoir des erreurs significatives dans CDF, il est préférable de quitter en cas d'échec, de renvoyer un code d'erreur et d'imprimer un message d'erreur.
Le programme d'interface peut être écrit dans n'importe quel langage, il suffit qu'il soit un fichier exécutable conforme à une interface CDF. Un programme d'interface est généralement écrit dans le même langage que le programme testé, mais ce n'est pas obligatoire (il peut s'agir d'un wrapper dans un autre langage, par exemple pour des programmes Java).
CDF supporte actuellement les interfaces suivantes, dans lesquelles les paramètres sont encodés en chaînes hexadécimales ASCII, sauf indication contraire :
L'interface dsa teste les implémentations du Digital Signature Algorithm (DSA). Elle doit prendre en charge les opérations de signature et de vérification :
| Opération | Entrée | Sortie |
|---|---|---|
| Signature | p q g y x m | r s |
| Vérification | p q g y r s m | valeur de vérité |
Ici p, q, g sont les paramètres DSA, y est une clé publique, x est une clé privée, m est un message, r et s forment la signature, qui doit être retournée séparée par une nouvelle ligne. La valeur de vérité, soit « true » ou « false », est représentée par une chaîne.
L'interface dsa prend en charge un test optionnel : le -h permet de contourner le processus de hachage et de fournir directement la valeur de hachage à signer. Cela permet à CDF d'effectuer plus de tests, comme la vérification des débordements ou de la troncature de hachage.
L'interface ecdsa teste les implémentations du Elliptic Curve Digital Signature Algorithm (ECDSA). Elle doit prendre en charge les opérations de signature et de vérification :
| Opération | Entrée | Sortie |
|---|---|---|
| Signature | x y d m | r s |
| Vérification | x y r s m | valeur de vérité |
Ici x et y sont les coordonnées d'une clé publique ECDSA, d est une clé privée, m est un message, et r et s forment la signature, qui doit être retournée séparée par une nouvelle ligne. La valeur de vérité, soit « true » ou « false », est représentée par une chaîne.
Le drapeau -h sert le même objectif qu'avec dsa.
Veuillez noter que notre conception actuelle suppose une courbe fixe, définie dans le programme testé.
Pour obtenir des résultats reproductibles avec ces tests et tirer parti de toutes les capacités de détection de CDF, vous devez soit ensemencer votre générateur aléatoire avec une graine fixe, soit utiliser une variante ECDSA déterministe, sinon CDF ne peut pas détecter automatiquement des problèmes tels que les problèmes de mêmes tags.
L'interface enc teste les opérations de chiffrement et de déchiffrement symétriques, généralement effectuées avec un chiffrement par bloc (les chiffrements par flux peuvent être testés avec l'interface prf). Elle doit prendre en charge le chiffrement et le déchiffrement :
| Opération | Entrée | Sortie |
|---|---|---|
| Chiffrement | k m | c |
| Déchiffrement | k c | r |
Ici k est une clé, m est un message, c est un texte chiffré et r est un texte clair récupéré.
L'interface prf teste le hachage avec clé (fonctions pseudo-aléatoires, MAC), ainsi que les chiffrements par flux :
| Opération | Entrée | Sortie |
|---|---|---|
| Calcul | k m | h |
Ici k est une clé, m est un message (ou nonce dans le cas d'un chiffrement par flux), et h est le résultat du calcul PRF. Notre interface suppose une taille de clé fixe et des longueurs d'entrée variables. Si une clé spécifique doit être spécifiée, il est de la responsabilité du programme testé d'ignorer l'entrée de la clé, ou l'interface xof peut être un meilleur choix.
L'interface rsaenc teste le chiffrement et le déchiffrement RSA, à la fois OAEP (PKCS 2.1) et PKCS 1.5 :
| Opération | Entrée | Sortie |
|---|---|---|
| Chiffrement | n e m | c |
| Déchiffrement | p q e d c | r |
Ici n est un module, e est un exposant public (pour des raisons de compatibilité avec certaines bibliothèques, e est également nécessaire pour le déchiffrement), m est un message, p et q sont les facteurs de n (tels que p > q, car les bibliothèques l'exigent généralement), d est un exposant privé, et r est un texte clair récupéré.
L'interface xof teste les fonctions de hachage, les fonctions à sortie extensible (XOF), les générateurs déterministes de bits aléatoires (DRBG) :
| Opération | Entrée | Sortie |
|---|---|---|
| Calcul | m | h |
Ici m est le message et h est le résultat.
CDF est basé sur les idées initiales de JP Aumasson, divulguées pour la première fois à WarCon 2016, et la majeure partie du code a été écrite par Yolan Romailler.
CDF est protégé par le droit d'auteur (c) 2016-2017 Nagravision SA, tous droits réservés.
CDF est publié sous licence GPLv3.