11. Security Considerations (Considérations de sécurité)
Tous les problèmes de sécurité pertinents pour toute application cryptographique sont pertinents pour les agents JWS/JWE/JWK. Ces problèmes incluent la protection des clés privées asymétriques et des clés secrètes symétriques de l'utilisateur, ainsi que l'emploi de contre-mesures contre diverses attaques.
Toutes les considérations de sécurité de la spécification JWS s'appliquent également à cette spécification. De même, toutes les considérations de sécurité dans XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] s'appliquent également, à l'exception de celles spécifiques à XML.
11.1 Key Entropy and Random Values (Entropie de clé et valeurs aléatoires)
Voir la section 10.1 de [JWS] pour les considérations de sécurité sur l'entropie des clés et les valeurs aléatoires. En plus des utilisations de valeurs aléatoires répertoriées là-bas, notez que des valeurs aléatoires sont également utilisées pour les clés de chiffrement de contenu (CEK) et les vecteurs d'initialisation (IV) lors de l'exécution du chiffrement.
11.2 Key Protection (Protection de clé)
Voir la section 10.2 de [JWS] pour les considérations de sécurité sur la protection des clés. En plus des clés qui doivent être protégées répertoriées là-bas, les implémentations effectuant le chiffrement doivent également protéger les clés de chiffrement de clé et les clés de chiffrement de contenu. La compromission d'une clé de chiffrement de clé peut entraîner la compromission de tout le contenu protégé avec cette clé. De même, la compromission d'une clé de chiffrement de contenu peut entraîner la compromission du contenu chiffré associé.
11.3 Using Matching Algorithm Strengths (Utilisation de forces d'algorithme correspondantes)
Des algorithmes de forces correspondantes doivent être utilisés ensemble dans la mesure du possible. Par exemple, lorsque AES Key Wrap est utilisé avec une taille de clé donnée, il est recommandé d'utiliser AES GCM avec la même taille de clé s'il est également utilisé. Si les algorithmes de chiffrement de clé et de chiffrement de contenu sont différents, la sécurité effective est déterminée par le plus faible des deux algorithmes.
De plus, consultez RFC 3766 [RFC3766] pour des informations sur la détermination des forces des clés publiques utilisées pour l'échange de clés symétriques.
11.4 Adaptive Chosen-Ciphertext Attacks (Attaques adaptatives par texte chiffré choisi)
Lors du déchiffrement, un soin particulier doit être pris pour ne pas permettre au destinataire JWE d'être utilisé comme un oracle pour déchiffrer des messages. RFC 3218 [RFC3218] doit être consulté pour des contre-mesures spécifiques aux attaques sur RSAES-PKCS1-v1_5. Un attaquant pourrait modifier le contenu du paramètre d'en-tête "alg" de "RSA-OAEP" à "RSA1_5" afin de générer une erreur de formatage qui peut être détectée et utilisée pour récupérer la CEK même si la CEK a été chiffrée en utilisant RSAES-OAEP. Il est donc particulièrement important de signaler toutes les erreurs de formatage, de clé de chiffrement de contenu, de données authentifiées supplémentaires ou de texte chiffré comme une seule erreur lorsque le contenu chiffré est rejeté.
De plus, ce type d'attaque peut être empêché en restreignant l'utilisation d'une clé à un ensemble limité d'algorithmes - généralement un. Par exemple, cela signifie que, si une clé est marquée comme étant uniquement pour "RSA-OAEP", toute tentative de déchiffrer un message utilisant cette clé avec l'algorithme "RSA1_5" doit échouer immédiatement en raison d'une utilisation invalide de la clé.
11.5 Timing Attacks (Attaques temporelles)
Pour atténuer les attaques décrites dans RFC 3218 [RFC3218], le destinataire ne doit pas (MUST NOT) distinguer entre les erreurs de format, de rembourrage et de longueur sur la clé de chiffrement. Il est fortement recommandé qu'à la réception d'une clé mal formée, le destinataire substitue une CEK générée aléatoirement et procède à l'étape suivante, pour atténuer les attaques temporelles.