10. Security Considerations (Considérations de sécurité)

Toutes les considérations de sécurité qui s'appliquent aux algorithmes cryptographiques d'une manière générale et celles qui s'appliquent spécifiquement aux algorithmes utilisés dans cette spécification s'appliquent à cette spécification.

Toutes les considérations de sécurité dans [JWA] (JSON Web Algorithms) s'appliquent également à cette spécification. Les implémenteurs devraient particulièrement prêter attention aux considérations de sécurité sur la cryptographie, en particulier les avertissements concernant les longueurs de clé minimales dans la section 3.5 de [JWA].

Les considérations de sécurité suivantes s'appliquent aux objets JSON Web Signature (JWS) :

10.1 Key Entropy and Random Values (Entropie des clés et valeurs aléatoires)

Voir la section 10.1 de [JWA] pour les considérations sur l'entropie des clés et les valeurs aléatoires.

La solidité de toute signature ou MAC dépend de manière critique de l'entropie de la clé cryptographique utilisée. Par conséquent, il est de la plus haute importance que les clés soient générées avec l'entropie suffisante. RFC 4086 [RFC4086] fournit des directives sur la génération de valeurs aléatoires avec l'entropie suffisante.

10.2 Key Protection (Protection des clés)

Les clés doivent être protégées contre la divulgation et l'utilisation non autorisée. En particulier, les clés privées utilisées pour les signatures numériques doivent être protégées contre la divulgation et l'utilisation non autorisée. Les clés secrètes utilisées pour les MACs doivent être protégées contre la divulgation et l'utilisation non autorisée.

Des méthodes pour protéger les clés incluent :

• Stockage des clés dans des modules de sécurité matériels (HSM, Hardware Security Modules)
• Chiffrement des clés lorsqu'elles sont stockées
• Limitation de l'accès aux clés en utilisant des mécanismes de contrôle d'accès
• Utilisation de processus de gestion de cycle de vie de clés appropriés

10.3 Key Origin Authentication (Authentification de l'origine de la clé)

Lorsqu'une clé est utilisée pour vérifier une signature ou un MAC, le destinataire doit avoir confiance que la clé provient réellement de l'émetteur prévu. Les mécanismes pour établir la confiance dans l'origine de la clé incluent :

• Utilisation de certificats X.509
• Utilisation de protocoles d'établissement de clés avec authentification
• Utilisation de clés prépartagées avec authentification de la source
• Récupération de clés à partir d'un ensemble de clés de confiance (JWK Set)

10.4 Cryptographic Agility (Agilité cryptographique)

Voir la section 10.4 de [JWA] pour les considérations sur l'agilité cryptographique.

Les implémentations devraient être conçues pour permettre la migration vers de nouveaux algorithmes cryptographiques selon les besoins. Cela peut être accompli en :

• Prenant en charge plusieurs algorithmes
• Permettant la configuration facile des algorithmes pris en charge
• Fournissant des mécanismes de mise à niveau clairs

10.5 Differences between Digital Signatures and MACs (Différences entre les signatures numériques et les MACs)

Les signatures numériques fournissent l'authentification et la non-répudiation ; elles utilisent la cryptographie à clé publique. Les MACs fournissent l'authentification mais pas la non-répudiation ; ils utilisent des clés secrètes partagées.

Dans les applications où la non-répudiation est requise, des signatures numériques doivent (MUST) être utilisées. Dans les applications où la non-répudiation n'est pas requise, l'une ou l'autre peut être utilisée, mais les MACs sont souvent plus efficaces.

10.6 Algorithm Validation (Validation de l'algorithme)

La valeur du paramètre d'en-tête « alg » (algorithm, algorithme) doit (MUST) être vérifiée pour s'assurer qu'elle correspond à l'algorithme attendu par l'application. Cela prévient les attaques où un attaquant change la valeur « alg » pour inciter le destinataire à utiliser un algorithme plus faible ou un algorithme que l'attaquant peut exploiter.

Les implémentations devraient :

• Rejeter les valeurs « alg » inattendues
• Maintenir une liste blanche d'algorithmes acceptables
• Ne jamais faire confiance aveuglément à la valeur « alg » reçue

10.7 Algorithm Protection (Protection de l'algorithme)

Dans les applications où l'algorithme utilisé pour protéger le JWS est critique pour la sécurité, l'algorithme devrait (SHOULD) être inclus dans le JWS Protected Header plutôt que dans le JWS Unprotected Header. De cette façon, l'algorithme est protégé en intégrité.

Voir aussi la section 10.6 de [JWA] et RFC 6211 [RFC6211] pour plus d'informations sur la protection de l'algorithme.

10.8 Chosen Plaintext Attacks (Attaques à texte clair choisi)

Les implémentations JWS peuvent être vulnérables aux attaques à texte clair choisi si un attaquant peut inciter le système à signer ou à générer un MAC pour des charges utiles arbitraires. Les implémentations devraient :

• Limiter quelles charges utiles peuvent être signées ou protégées par MAC
• Valider les charges utiles avant de les signer ou de les protéger par MAC
• Mettre en œuvre des contrôles d'accès appropriés

10.9 Timing Attacks (Attaques temporelles)

Les implémentations doivent être conçues pour être résistantes aux attaques temporelles. En particulier, les opérations de vérification de signature et de MAC devraient prendre un temps constant, indépendamment du fait que la vérification réussisse ou échoue.

Les techniques pour atténuer les attaques temporelles incluent :

• Utilisation d'algorithmes à temps constant pour la comparaison de signatures/MACs
• Éviter les sorties anticipées sur les échecs de vérification
• Éviter la variation du comportement en fonction des valeurs des clés

10.10 Replay Protection (Protection contre la relecture)

JWS ne fournit pas intrinsèquement de protection contre la relecture. Les applications qui nécessitent une protection contre la relecture doivent l'implémenter au niveau de l'application. Les mécanismes pour prévenir la relecture incluent :

• Inclusion d'un numéro unique (nonce) dans la charge utile
• Inclusion d'un horodatage et vérification de la fraîcheur
• Utilisation de mécanismes de fenêtre coulissante
• Maintien d'un cache de JWS vus récemment

10.11 SHA-1 Certificate Thumbprints (Empreintes de certificat SHA-1)

Le paramètre d'en-tête « x5t » (X.509 certificate SHA-1 thumbprint, empreinte SHA-1 du certificat X.509) est inclus pour la compatibilité ascendante uniquement et n'est pas recommandé pour une nouvelle utilisation. Les implémentations devraient plutôt utiliser le paramètre d'en-tête « x5t#S256 » (X.509 certificate SHA-256 thumbprint, empreinte SHA-256 du certificat X.509).

10.12 JSON Security Considerations (Considérations de sécurité JSON)

Les implémentations doivent être conscientes des problèmes de sécurité liés au traitement JSON, incluant :

• Attaques par injection JSON
• Problèmes de normalisation Unicode
• Problèmes de duplication de clés JSON
• Problèmes d'analyse JSON (par exemple, nombres très grands)

Voir RFC 7159 [RFC7159] pour plus d'informations sur la sécurité JSON.

10.13 Unicode Comparison Security Issues (Problèmes de sécurité de comparaison Unicode)

Les noms de paramètres d'en-tête et les valeurs de chaîne doivent être comparés en utilisant la comparaison de chaînes de valeurs Unicode exacte. Les implémentations ne doivent pas effectuer de normalisation Unicode ou d'autres transformations avant la comparaison, car cela pourrait conduire à des vulnérabilités de sécurité.