Un jeton signé est lisible par quiconque le détient. Quand c’est inacceptable, la RFC 7516 définit JSON Web Encryption.
Cinq parties, pas trois
header . encrypted_key . iv . ciphertext . authentication_tagLes parties supplémentaires existent parce que JWE emploie deux clés, pas une. Une clé symétrique fraîche, la clé de chiffrement de contenu, chiffre la charge utile. Cette clé est elle-même chiffrée pour le destinataire, et le résultat est la deuxième partie du jeton.
Ce n’est pas une complication gratuite. La cryptographie asymétrique est lente et limitée dans la taille qu’elle peut traiter. Chiffrer une courte clé aléatoire en RSA et la charge utile en AES est à la fois plus rapide et sans limite de longueur.
Deux algorithmes à déclarer
alg: comment la clé de chiffrement de contenu est traitée.RSA-OAEP-256,ECDH-ES,A256KW,dir.enc: comment la charge utile elle-même est chiffrée.A128CBC-HS256,A256GCM.
Les deux sont obligatoires et les deux sont dans l’en-tête protégé. Trompez-vous sur l’un et le jeton ne se déchiffrera pas, ce qui est le bon mode de défaillance.
L’étiquette d’authentification n’est pas facultative
Tout algorithme de chiffrement de contenu dans JWE est authentifié : il produit une étiquette qui prouve que le chiffré n’a pas été altéré. Un chiffrement sans authentification laisse un attaquant retourner des bits dans votre charge utile et regarder ce qui se passe.
Ce n’est pas une préoccupation abstraite. Un algorithme expérimental de cette bibliothèque même engendrait son étiquette puis la jetait, dégradant en silence une construction authentifiée en construction qui ne l’était pas.
Ce que le chiffrement ne vous donne pas
Un JWE ne prouve rien sur qui l’a produit. Quiconque a votre clé publique peut chiffrer quelque chose à votre intention. S’il vous faut connaître l’expéditeur, il vous faut aussi une signature, et l’ordre dans lequel vous les combinez compte.