2. Algorithmes de signature
- Algorithmes de signature
La section 8.1 de [RFC9052] contient une description générique des algorithmes de signature. Ce document définit les identifiants d'algorithme de signature pour deux algorithmes de signature.
2.1. ECDSA
L'algorithme de signature numérique à courbe elliptique (ECDSA) [DSS] définit un algorithme de signature utilisant la cryptographie sur les courbes elliptiques (ECC). Les implémentations DEVRAIENT utiliser une version déterministe de l'ECDSA telle que celle définie dans [RFC6979]. L'utilisation d'un algorithme de signature déterministe permet aux systèmes d'éviter de s'appuyer sur des générateurs de nombres aléatoires afin d'éviter de générer la même valeur de "k" (la valeur aléatoire par message). La génération biaisée de la valeur "k" peut être attaquée, et les collisions de cette valeur conduisent à des clés divulguées. Cela permet en outre d'effectuer des tests déterministes pour l'algorithme de signature. L'utilisation de l'ECDSA déterministe ne diminue pas la nécessité d'avoir une bonne génération de nombres aléatoires lors de la création de la clé privée.
L'algorithme de signature ECDSA est paramétré avec une fonction de hachage (h). Dans le cas où la longueur de la sortie de la fonction de hachage est supérieure au groupe de la clé, les octets les plus à gauche de la sortie de hachage sont utilisés.
Les algorithmes définis dans ce document se trouvent dans le tableau 1.
+=======+=======+=========+==================+
| Name | Value | Hash | Description |
+=======+=======+=========+==================+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
+-------+-------+---------+------------------+
| ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 |
+-------+-------+---------+------------------+
| ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+
Tableau 1 : Valeurs de l'algorithme ECDSA
Ce document définit ECDSA comme ne fonctionnant qu'avec les courbes P-256, P-384 et P-521. Ce document exige que les courbes soient encodées à l'aide du type de clé "EC2" (courbe elliptique à deux coordonnées). Les implémentations doivent vérifier que le type de clé et la courbe sont corrects lors de la création et de la vérification d'une signature. Les futurs documents pourront le définir pour fonctionner avec d'autres courbes et types de clés à l'avenir.
Afin de promouvoir l'interopérabilité, il est suggéré que SHA-256 soit utilisé uniquement avec la courbe P-256, SHA-384 uniquement avec la courbe P-384 et SHA-512 uniquement avec la courbe P-521. Ceci est aligné avec la recommandation de la section 4 de [RFC5480].
L'algorithme de signature aboutit à une paire d'entiers (R, S). Ces entiers auront la même longueur que la longueur de la clé utilisée pour le processus de signature. La signature est encodée en convertissant les entiers en chaînes d'octets de la même longueur que la taille de la clé. La longueur est arrondie à l'octet le plus proche et est complétée à gauche par des bits zéro pour obtenir la longueur correcte. Les deux entiers sont ensuite concaténés pour former une chaîne d'octets qui est la signature résultante.
En utilisant la fonction définie dans [RFC8017], la signature est :
Signature = I2OSP(R, n) | I2OSP(S, n)
où n = ceiling(key_length / 8)
Lors de l'utilisation d'une clé COSE pour cet algorithme, les vérifications suivantes sont effectuées :
-
Le champ "kty" DOIT être présent, et il DOIT être "EC2".
-
Si le champ "alg" est présent, il DOIT correspondre à l'algorithme de signature ECDSA utilisé.
-
Si le champ "key_ops" est présent, il DOIT inclure "sign" lors de la création d'une signature ECDSA.
-
Si le champ "key_ops" est présent, il DOIT inclure "verify" lors de la vérification d'une signature ECDSA.
2.1.1. Considérations de sécurité pour ECDSA
La force de sécurité de la signature n'est pas supérieure au minimum de la force de sécurité associée à la longueur en bits de la clé et de la force de sécurité de la fonction de hachage.
Note : L'utilisation d'une technique de signature déterministe est une bonne idée même lorsqu'une bonne génération de nombres aléatoires existe. Cela réduit à la fois la possibilité d'avoir la même valeur de "k" dans deux opérations de signature et permet des valeurs de signature reproductibles, ce qui facilite les tests. Il y a eu des attaques récentes impliquant la mise en défaut de l'appareil afin d'extraire la clé. Cela peut être résolu en combinant à la fois le hasard et le déterminisme [CFRG-DET-SIGS].
Il existe deux attaques par substitution qui peuvent théoriquement être montées contre l'algorithme de signature ECDSA.
-
Changer la courbe utilisée pour valider la signature : Si l'on change la courbe utilisée pour valider la signature, on pourrait potentiellement avoir deux messages avec la même signature, chacun calculé sous une courbe différente. Les seules exigences sur la nouvelle courbe sont que son ordre soit le même que l'ancienne et qu'elle soit acceptable pour le client. Un exemple serait de passer de l'utilisation de la courbe secp256r1 (alias P-256) à l'utilisation de secp256k1. (Les deux sont des courbes de 256 bits.) Nous n'avons actuellement aucun moyen de faire face à cette version de l'attaque, sauf pour restreindre l'ensemble global des courbes qui peuvent être utilisées.
-
Changer la fonction de hachage utilisée pour valider la signature : Si l'on a deux fonctions de hachage différentes de la même longueur ou si l'on peut tronquer une fonction de hachage, on pourrait potentiellement trouver des collisions entre les fonctions de hachage plutôt qu'au sein d'une seule fonction de hachage. Par exemple, tronquer SHA-512 à 256 bits pourrait entrer en collision avec une valeur de hachage de 256 bits de SHA-256. Comme l'algorithme de hachage fait partie de l'identifiant de l'algorithme de signature, cette attaque est atténuée en incluant un identifiant d'algorithme de signature dans le compartiment d'en-tête protégé.
2.2. Algorithme de signature numérique à courbe d'Edwards (EdDSA)
[RFC8032] décrit le schéma de signature à courbe elliptique Edwards-curve Digital Signature Algorithm (EdDSA). Dans ce document, l'algorithme de signature est instancié en utilisant des paramètres pour les courbes edwards25519 et edwards448. Le document décrit en outre deux variantes de l'algorithme EdDSA : Pure EdDSA, où aucune fonction de hachage n'est appliquée au contenu avant la signature, et HashEdDSA, où une fonction de hachage est appliquée au contenu avant la signature et le résultat de cette fonction de hachage est signé. Pour EdDSA, le contenu à signer (soit le message, soit la valeur pré-hachée) est traité deux fois à l'intérieur de l'algorithme de signature. Pour une utilisation avec COSE, seule la version Pure EdDSA est utilisée. C'est parce qu'il n'est pas prévu que des contenus extrêmement volumineux soient nécessaires et, sur la base de l'arrangement de la structure du message, le message entier devra être conservé en mémoire afin de créer ou de vérifier une signature. Par conséquent, il ne semble pas nécessaire de pouvoir effectuer des mises à jour de bloc du hachage, suivies de l'élimination du message de la mémoire. Les applications peuvent fournir les mêmes fonctionnalités en définissant le contenu du message comme une valeur de hachage et en transportant l'objet COSE (avec la valeur de hachage) et le contenu comme des éléments séparés.
L'algorithme défini dans ce document se trouve dans le tableau 2. Un seul algorithme de signature est défini, qui peut être utilisé pour plusieurs courbes.
+=======+=======+=============+
| Name | Value | Description |
+=======+=======+=============+
| EdDSA | -8 | EdDSA |
+-------+-------+-------------+
Tableau 2 : Valeur de l'algorithme EdDSA
[RFC8032] décrit la méthode d'encodage de la valeur de signature.
Lors de l'utilisation d'une clé COSE pour cet algorithme, les vérifications suivantes sont effectuées :
-
Le champ "kty" DOIT être présent, et il DOIT être "OKP" (Paire de clés d'octets).
-
Le champ "crv" DOIT être présent, et il DOIT être une courbe définie pour cet algorithme de signature.
-
Si le champ "alg" est présent, il DOIT correspondre à "EdDSA".
-
Si le champ "key_ops" est présent, il DOIT inclure "sign" lors de la création d'une signature EdDSA.
-
Si le champ "key_ops" est présent, il DOIT inclure "verify" lors de la vérification d'une signature EdDSA.
2.2.1. Considérations de sécurité pour EdDSA
Les valeurs publiques sont calculées différemment dans EdDSA et Elliptic Curve Diffie-Hellman (ECDH) ; pour cette raison, la clé publique de l'un ne doit pas être utilisée avec l'autre algorithme.
Si une vérification de signature par lots est effectuée, un générateur de nombres aléatoires cryptographiques bien initialisé est REQUIS (Section 8.2 de [RFC8032]). La signature et la vérification de signature non par lots sont des opérations déterministes et ne nécessitent aucun nombre aléatoire.