03. JWE et composition des protections

Comprendre le mécanisme

JWE définit une représentation chiffrée avec des paramètres de gestion de clé et de chiffrement du contenu. Une forme compacte possède cinq segments, dont certains peuvent être vides selon l’algorithme. Cette structure ne constitue pas une preuve de validité. Un destinataire capable de déchiffrer doit encore déterminer l’origine attendue et les règles du profil ; le chiffrement avec une clé publique de destinataire ne prouve pas qui a envoyé le contenu.

Raisonner et vérifier

Lorsqu’un profil compose signature et chiffrement, vérifiez toutes les couches requises avec une bibliothèque adaptée. Ne retournez pas de diagnostics publics détaillant les étapes cryptographiques. Évaluez aussi les métadonnées et longueurs visibles : chiffrer le contenu ne cache pas toute information de trafic. N’activez pas une compression sensible sans analyse des fuites possibles et des limites de décompression.

Cinq segments

La forme compacte JWE comporte cinq segments. La structure doit encore être validée cryptographiquement. La forme compacte JWE sépare notamment en-tête protégé, clé chiffrée, vecteur, contenu chiffré et tag. Cette structure permet un parsing, mais cinq morceaux arbitraires ne constituent pas une JWE valide.

Expéditeur

Le chiffrement vers une clé publique ne prouve pas l’expéditeur. Le caractère public permet à d’autres de chiffrer vers le destinataire. Une personne qui connaît la clé publique d’un destinataire peut généralement chiffrer pour lui. Le succès du déchiffrement ne désigne donc pas à lui seul un expéditeur autorisé.

Signature interne

Un profil peut exiger une signature interne. Toutes les couches requises doivent être vérifiées. Si le profil impose une composition signée puis chiffrée, vérifiez aussi la signature interne et ses claims. Le déchiffrement réussi n’autorise pas à sauter une opération explicitement exigée.

Deux familles d’algorithmes

Les algorithmes de gestion de clé et de contenu ont des rôles distincts. La construction possède plusieurs paramètres de protection. alg décrit la gestion de clé et enc la protection du contenu dans le profil JOSE. Imposez les combinaisons admises et les capacités de clé correspondantes, au lieu d’accepter toute valeur reconnue.

Erreurs maîtrisées

Les erreurs publiques doivent rester contrôlées. Des diagnostics détaillés peuvent fournir des informations sensibles. Les détails cryptographiques peuvent aider un attaquant ou révéler des informations internes. Retournez un refus public contrôlé et gardez des diagnostics privés minimisés, sans plaintext ni clé dans les logs.

Clé destinataire

Le destinataire doit disposer de la clé prévue. Décodage et déchiffrement sont différents. La clé de déchiffrement doit correspondre au destinataire et à l’usage configurés. Une résolution par kid reste une sélection contrôlée ; elle ne doit pas autoriser des lectures de fichiers arbitraires.

Longueur observable

La longueur peut rester observable. Le contenu secret ne supprime pas toutes les informations visibles. Le chiffrement peut laisser visibles taille, moment et fréquence des échanges. Déterminez si ces métadonnées sont sensibles dans votre modèle avant d’annoncer une confidentialité qui dépasserait le contenu protégé.

Compression

La compression sensible demande une analyse. La taille peut devenir un canal d’information. Compresser un secret avec des données contrôlées peut révéler des corrélations de longueur selon le contexte. Évitez d’activer une compression sensible sans analyse de l’attaquant, des observations et des répétitions possibles.

Parsing borné

Un parseur doit borner les entrées. Le traitement doit protéger ses ressources. Fixez taille totale et limites de décompression lorsqu’elle existe. Une entrée finalement invalide ne doit pas pouvoir consommer sans limite les ressources du service avant la décision de refus.

Après déchiffrement

L’autorisation reste nécessaire après déchiffrement. La protection cryptographique n’épuise pas la décision d’accès. Un contenu déchiffré peut demander une opération interdite au compte. Appliquez validation de profil et autorisation métier ; la confidentialité du transport d’une affirmation ne lui donne pas un droit universel.

Atelier guidé : lire, expliquer et vérifier le code

{
  "profile": "signed-then-encrypted",
  "decryption": "ok",
  "innerSignature": "not-checked"
}

Le profil annoncé exige une signature interne, tandis que l’état montre seulement un déchiffrement réussi. La décision correcte reste le refus tant que la signature requise n’est pas validée. Ajoutez des fixtures pour déchiffrement invalide, signature interne invalide et composition entièrement conforme.

Les contrôles de claims restent nécessaires. La longueur n’est pas la propriété manquante. Toutes les opérations exigées par le profil doivent réussir. La confidentialité ne donne pas ces permissions.

Travail pratique : Testez le profil avec JWS seule, JWE sans signature interne et objet imbriqué complet.

Critères de correction : Refusez les formats incomplets avant le métier. Vérifiez que l’erreur publique ne distingue pas des détails internes sensibles, tout en conservant un diagnostic privé minimal.