10. Considérations de sécurité

Tous les enjeux de sécurité pertinents pour toute application cryptographique doivent être pris en compte par les agents JWS/JWE/JWK. Parmi ces enjeux figurent la protection des clés asymétriques privées et des clés secrètes symétriques de l'utilisateur, ainsi que la mise en place de contre-mesures contre diverses attaques.

L'ensemble des considérations de sécurité figurant dans « XML Signature Syntax and Processing Version 2.0 » [W3C.NOTE-xmldsig-core2-20130411] s'appliquent également à cette spécification, à l'exception de celles qui sont propres à XML. De même, de nombreuses bonnes pratiques décrites dans « XML Signature Best Practices » [W3C.NOTE-xmldsig-bestpractices-20130411] s'appliquent ici, à l'exception de celles qui sont spécifiques à XML.

10.1 Entropie des clés et valeurs aléatoires

La force d'une clé est limitée par la quantité d'entropie utilisée pour la générer. Un minimum de 128 bits d'entropie devrait être utilisé pour toutes les clés, et selon le contexte applicatif, davantage peut être nécessaire.

Les implémentations doivent générer aléatoirement les paires de clés publiques/privées, les clés de MAC et les valeurs de bourrage. L'utilisation de générateurs pseudo-aléatoires (PRNG) inadéquats pour générer des clés cryptographiques peut entraîner une sécurité faible, voire inexistante. Un attaquant peut alors trouver bien plus facile de reproduire l'environnement du PRNG ayant produit les clés et de chercher dans le petit ensemble de possibilités résultant, plutôt que d'attaquer par force brute l'espace complet des clés. Générer des nombres aléatoires de qualité est difficile. La RFC 4086 [RFC4086] fournit des conseils importants en la matière.

10.2 Protection des clés

Les implémentations doivent protéger la clé privée du signataire. La compromission de cette clé permet à un attaquant de se faire passer pour le signataire.

Les implémentations doivent protéger la clé MAC. La compromission de la clé MAC peut entraîner une modification indétectable du contenu authentifié.

10.3 Authentification de l'origine de la clé

La technique de gestion des clés employée pour obtenir des clés publiques doit authentifier l'origine de la clé ; sinon, on ignore quelle partie a signé le message.

De même, la technique de gestion des clés employée pour distribuer des clés MAC doit fournir une authentification de l'origine des données ; sinon, le contenu est livré avec intégrité mais d'une source inconnue.

10.4 Agilité cryptographique

Voir la section 8.1 de [JWA] pour les considérations de sécurité relatives à l'agilité cryptographique.

10.5 Différences entre signatures numériques et MAC

Les MAC et les signatures numériques peuvent tous deux être utilisés pour vérifier l'intégrité, mais il existe des différences significatives entre les propriétés de sécurité qu'ils offrent. Ces différences doivent être prises en compte lors de la conception des protocoles et du choix des algorithmes.

Les signatures et les MAC offrent tous deux la vérification d'intégrité, c'est-à-dire la vérification que le message n'a pas été modifié depuis le calcul de la valeur d'intégrité. Toutefois, les MAC ne fournissent une identification de l'origine que dans des conditions précises. On peut généralement supposer qu'une clé privée utilisée pour une signature n'est qu'entre les mains d'une seule entité (éventuellement distribuée, dans le cas de serveurs répliqués) ; en revanche, une clé MAC doit être détenue par toutes les entités qui s'en servent pour calculer et vérifier l'intégrité. La validation d'un MAC ne fournit qu'une corroboration : le message a été généré par l'une des parties qui connaissent la clé MAC symétrique. Cela signifie que l'origine ne peut être déterminée que si une clé MAC n'est connue que de deux entités et que le destinataire sait qu'il n'a pas créé le message lui-même. La validation d'un MAC ne peut servir à prouver l'origine à un tiers.

10.6 Validation de l'algorithme

Les représentations de signatures numériques pour certains algorithmes contiennent des informations sur l'algorithme utilisé à l'intérieur de la valeur de signature. Par exemple, les signatures produites avec RSASSA-PKCS1-v1_5 [RFC3447] encodent la fonction de hachage utilisée, et de nombreuses bibliothèques utilisent réellement l'algorithme de hachage spécifié à l'intérieur de la signature lors de la vérification. Lors de l'utilisation de telles bibliothèques, dans le cadre de la validation de l'algorithme, les implémentations DOIVENT vérifier que l'information d'algorithme encodée dans la signature correspond à celle indiquée par le paramètre d'en-tête « alg ». À défaut, un attaquant pourrait prétendre avoir utilisé un algorithme de hachage fort tout en utilisant en réalité un algorithme faible représenté dans la valeur de signature.

10.7 Protection de l'algorithme

Dans certains usages de JWS, il existe un risque d'attaques par substitution d'algorithme, dans lesquelles un attaquant peut utiliser une valeur de signature numérique existante avec un algorithme de signature différent, pour faire croire qu'un signataire a signé quelque chose qu'il n'a pas signé. Ces attaques ont été discutées en détail dans le contexte de Cryptographic Message Syntax (CMS) [RFC6211]. Ce risque apparaît lorsque toutes les conditions suivantes sont réunies :

Les vérificateurs de signature prennent en charge plusieurs algorithmes.
Pour une signature existante, un attaquant peut trouver une autre charge utile produisant la même valeur de signature avec un algorithme différent.
La charge utile fabriquée par l'attaquant est valide dans le contexte applicatif.

Plusieurs moyens permettent à une application d'atténuer les attaques par substitution d'algorithme :

N'utiliser que des algorithmes de signature numérique non vulnérables aux attaques par substitution. Ces attaques ne sont possibles que si un attaquant peut calculer des préimages pour une fonction de hachage acceptée par le destinataire. Tous les algorithmes de signature définis dans JWA utilisent des hachages SHA-2, pour lesquels aucune attaque préimage n'est connue à ce jour.
Exiger que le paramètre d'en-tête « alg » soit transporté dans le JWS Protected Header. (C'est toujours le cas avec la sérialisation compacte JWS et c'est l'approche retenue par CMS [RFC6211].)
Inclure un champ contenant l'algorithme dans la charge utile applicative et exiger qu'il corresponde au paramètre d'en-tête « alg » lors de la vérification. (C'est l'approche adoptée par PKIX [RFC5280].)

10.8 Attaques à texte clair choisi

Les créateurs de JWS ne devraient pas permettre à des tiers d'insérer un contenu arbitraire dans le message sans ajouter une entropie qui ne soit pas contrôlée par ces tiers.

10.9 Attaques par mesure du temps

Lorsque les algorithmes cryptographiques sont implémentés de manière à ce que les opérations réussies prennent un temps différent des opérations échouées, des attaquants peuvent exploiter cette différence pour obtenir des informations sur les clés employées. De telles différences de temps doivent donc être évitées.

10.10 Protection contre la rejouabilité

Bien que cela ne soit pas directement dans le périmètre de cette spécification, notez que les applications utilisant des objets JWS (ou JWE) peuvent contrer les attaques par rejeu en incluant un identifiant de message unique comme contenu protégé en intégrité dans le message JWS (ou JWE), et en faisant vérifier au destinataire que le message n'a pas déjà été reçu ni traité.

10.11 Empreintes de certificats SHA-1

Un hachage SHA-1 est utilisé lors du calcul des valeurs « x5t » (empreinte SHA-1 d'un certificat X.509), pour des raisons de compatibilité. Si une méthode efficace de production de collisions SHA-1 venait à être développée et qu'un attaquant souhaitait perturber l'usage d'un certificat connu sur un système donné, il pourrait y parvenir en créant un autre certificat dont la valeur de hachage SHA-1 est identique et en l'ajoutant au magasin de certificats utilisé par la victime visée. Une condition préalable au succès de cette attaque est que l'attaquant ait accès en écriture au magasin de certificats de la victime.

À titre alternatif, on pourrait utiliser le paramètre d'en-tête « x5t#S256 » (empreinte SHA-256 d'un certificat X.509) à la place de « x5t ». Toutefois, à l'heure de la rédaction de ce document, aucune plateforme de développement n'est connue pour prendre en charge les empreintes de certificats SHA-256.

10.12 Considérations de sécurité JSON

La validation stricte du JSON [RFC7159] est une exigence de sécurité. Si un JSON malformé est reçu, l'intention du producteur est impossible à discerner de manière fiable. Des situations ambiguës et potentiellement exploitables peuvent survenir si le parseur JSON utilisé ne rejette pas la syntaxe JSON malformée. En particulier, toute entrée JSON non conforme à la syntaxe JSON-text définie dans la RFC 7159 DOIT être rejetée intégralement par les parseurs JSON.

La section 4 de « The JavaScript Object Notation (JSON) Data Interchange Format » [RFC7159] précise que « les noms au sein d'un objet DEVRAIENT être uniques », tandis que la présente spécification précise que :

Les noms des paramètres d'en-tête au sein du JOSE Header DOIVENT être uniques ; les parseurs JWS DOIVENT soit rejeter les JWS comportant des noms de paramètres d'en-tête en double, soit utiliser un parseur JSON qui ne renvoie que le dernier nom de membre dupliqué dans l'ordre lexical, comme spécifié à la section 15.12 (« The JSON Object ») d'ECMAScript 5.1 [ECMAScript].

Ainsi, la présente spécification exige que le « SHOULD » de la section 4 de [RFC7159] soit traité comme un « MUST » par les producteurs et qu'il soit, soit traité comme un « MUST », soit traité de la manière décrite dans ECMAScript 5.1 par les consommateurs. Des situations ambiguës et potentiellement exploitables peuvent survenir si le parseur JSON utilisé ne fait pas respecter l'unicité des noms de membres ou s'il renvoie une valeur imprévisible pour des noms de membres en double.

Certains parseurs JSON peuvent ne pas rejeter une entrée contenant des caractères significatifs supplémentaires après une entrée valide. Par exemple, l'entrée « {"tag":"value"}ABCD » contient un objet JSON-text valide suivi des caractères supplémentaires « ABCD ». Les implémentations DOIVENT considérer comme invalides les JWS contenant de telles entrées.

10.13 Considérations de sécurité liées à la comparaison Unicode

Les noms de paramètres d'en-tête et les noms d'algorithmes sont des chaînes Unicode. Pour des raisons de sécurité, la représentation de ces noms doit être comparée à l'identique après tout traitement d'échappement (conformément à la section 8.3 de la RFC 7159 [RFC7159]). Cela signifie, par exemple, que ces chaînes JSON doivent être considérées comme égales (« sig », « \u0073ig »), tandis que celles-ci doivent toutes être considérées comme différentes du premier ensemble et différentes les unes des autres (« SIG », « Sig », « si\u0047 »).

Les chaînes JSON peuvent contenir des caractères en dehors du Plan Multilingue de Base d'Unicode. Par exemple, le caractère clé de sol (U+1D11E) peut être représenté dans une chaîne JSON par « \uD834\uDD1E ». Idéalement, les implémentations JWS DEVRAIENT veiller à ce que les caractères hors du Plan Multilingue de Base soient préservés et comparés correctement ; à défaut, si cela est impossible en raison de limitations de l'implémentation JSON sous-jacente, les entrées contenant ces caractères DOIVENT être rejetées.