1. Introduction
1. Introduction
DSA [FIPS-186-4] et ECDSA [X9.62] sont deux schémas de signature numérique standard. Ils fournissent l'intégrité des données et l'authenticité vérifiable dans divers protocoles.
Une caractéristique de DSA et ECDSA est qu'ils doivent produire, pour chaque génération de signature, une valeur aléatoire fraîche (ci-après désignée par k). Pour une sécurité efficace, k DOIT être choisi de manière aléatoire et uniforme parmi un ensemble d'entiers modulaires, en utilisant un processus cryptographiquement sécurisé. Même de légers biais dans ce processus peuvent être transformés en attaques contre les schémas de signature.
La nécessité d'une source cryptographiquement sécurisée de randomité s'avère être un obstacle au déploiement des schémas de signature DSA et ECDSA dans certaines architectures dans lesquelles la génération de nombres aléatoires sécurisés est difficile, en particulier les systèmes embarqués tels que les cartes à puce. Dans ces systèmes, l'algorithme de signature RSA, utilisé comme spécifié dans Public-Key Cryptography Standards (PKCS) #1 [RFC3447] (avec le rembourrage "type 1", pas le Probabilistic Signature Scheme (PSS)) et ISO 9796-2 [ISO-9796-2], est souvent préféré, même s'il est plus coûteux en calcul, car RSA (avec de tels schémas de rembourrage) est déterministe et ne nécessite donc pas de source de randomité.
La nature randomisée de DSA et ECDSA rend également les implémentations plus difficiles à tester. Les tests automatiques ne peuvent pas détecter de manière fiable si l'implémentation utilise une source de randomité de qualité suffisamment élevée. Cela rend le processus d'implémentation plus vulnérable aux échecs catastrophiques, souvent découverts après que le système a été déployé et attaqué avec succès.
Il est possible de transformer DSA et ECDSA en schémas déterministes en utilisant un processus déterministe pour générer la valeur "aléatoire" k. Ce processus DOIT remplir certaines caractéristiques cryptographiques afin de maintenir les propriétés de vérifiabilité et d'infalsifiabilité attendues des schémas de signature; à savoir, pour quiconque ne connaît pas la clé privée de signature, le mappage des messages d'entrée aux valeurs k correspondantes DOIT être computationnellement indiscernable de ce qu'une fonction choisie aléatoirement et uniformément (de l'ensemble des messages à l'ensemble des valeurs k possibles) retournerait.
Ce document décrit une telle procédure. Elle présente les caractéristiques suivantes:
-
Les signatures produites restent entièrement compatibles avec DSA et ECDSA ordinaires. Les entités qui vérifient les signatures n'ont pas besoin d'être modifiées ou même d'être au courant du processus utilisé pour générer k.
-
La génération de paires de clés n'est pas modifiée. Les clés privées existantes peuvent être utilisées avec DSA et ECDSA déterministes.
-
L'utilisation de DSA et ECDSA déterministes n'implique aucune exigence de stockage supplémentaire de valeur secrète ou publique.
-
DSA et ECDSA déterministes peuvent être appliqués sur les mêmes entrées que DSA et ECDSA ordinaires, à savoir une valeur de hachage calculée sur le message qui doit être signé, avec une fonction de hachage cryptographiquement sécurisée.
Certains choix relativement arbitraires ont été pris dans la définition de (EC)DSA déterministe tel que spécifié dans ce document; cela a été fait afin de le rendre aussi universellement applicable que possible, de manière à maximiser l'utilité des vecteurs de test inclus. Voir la section 3.6 pour une discussion de certaines variantes possibles.
Il convient de noter que la génération de paires de clés nécessite toujours une source de randomité. Dans les systèmes embarqués où la qualité de la randomité est un problème, il peut souvent être organisé que la génération de paires de clés se produise dans des conditions plus contrôlées (par exemple, lors d'une procédure d'initialisation spéciale de carte à puce ou sous le contrôle physique d'agents assermentés) ou la clé pourrait même être générée ailleurs et importée dans le dispositif. DSA et ECDSA déterministes ne traitent que du besoin de randomité au moment de la génération de signature.
1.1. Langage des exigences
Les mots-clés "DOIT" (MUST), "NE DOIT PAS" (MUST NOT), "REQUIS" (REQUIRED), "DEVRA" (SHALL), "NE DEVRA PAS" (SHALL NOT), "DEVRAIT" (SHOULD), "NE DEVRAIT PAS" (SHOULD NOT), "RECOMMANDÉ" (RECOMMENDED), "PEUT" (MAY) et "OPTIONNEL" (OPTIONAL) dans ce document doivent être interprétés comme décrit dans RFC 2119 [RFC2119].