Résumé

  • Le mode Base de HPKE donne la confidentialité au détenteur d’une clé privée de destinataire. La réussite de Open() ne prouve ni l’identité ni le mandat de l’émetteur.
  • Les modes PSK, Auth et AuthPSK apportent une preuve limitée de possession d’un secret partagé ou d’une clé KEM. Ils ne transforment pas cette possession en identité institutionnelle, en fraîcheur, en droit d’agir ou en non-répudiation générale.
  • La vraie chaîne de contrôle commence avant le chiffrement — choix et distribution de clé — et se termine après le déchiffrement — cadrage, politique, exécution et preuve d’effet.

Un système de réception signale qu’il a ouvert une charge utile HPKE. La bibliothèque a accepté la valeur encapsulée, reconstitué son contexte puis vérifié le texte chiffré avec ses données associées. Dans beaucoup d’équipes, ce signal devient immédiatement un verdict : « message de confiance ».

Le raccourci est séduisant parce qu’il remplace plusieurs décisions par une seule lumière verte. Il est pourtant plus large que ce que RFC 9180 promet. Le document décrit Hybrid Public Key Encryption, une composition de mécanisme d’encapsulation de clé, de dérivation de clé et de chiffrement authentifié. Il ne définit pas à qui appartient une clé dans une organisation, comment un expéditeur est nommé, comment un message est transporté, ni quelle opération un texte déchiffré peut déclencher.

La distinction se voit le plus nettement en mode Base. Toute partie disposant de la clé publique du destinataire peut établir un chiffrement vers celui-ci. Le détenteur de la clé privée peut ouvrir le résultat. Cette propriété peut être exactement celle qu’il faut pour un dépôt confidentiel. Elle n’est pas une preuve que la partie distante est un partenaire approuvé, un compte identifié ou un agent disposant d’un mandat.

Une équipe peut donc dire avec rigueur : « cette charge a validé dans un contexte construit avec telle clé destinataire ». Elle ne peut pas, sur cette seule base, dire : « telle organisation l’a émise et nous a autorisés à l’exécuter ». Entre les deux phrases se trouvent la distribution de clé, le choix du mode, le lien entre clé et identité, le format externe, le contrôle de fraîcheur, la politique locale et l’observation de l’effet.

Ce que le détenteur de la clé reçoit réellement

Une suite HPKE associe un KEM, un KDF et un AEAD. Le KEM produit et récupère un secret partagé à partir d’une encapsulation ; le KDF en dérive des clés et valeurs de contexte ; l’AEAD scelle et ouvre le contenu avec des données associées. Cette architecture offre une grammaire interopérable. Elle ne crée pas par elle-même une relation commerciale ou administrative.

Dans le chemin Base, l’émetteur appelle la mise en place avec pkR et une valeur info. Le KEM encapsule vers pkR. Le destinataire appelle la procédure correspondante avec la valeur enc reçue et skR. Si les entrées et le chiffrement sont cohérents, les deux côtés arrivent au contexte qui permet de sceller ou d’ouvrir.

Le résultat répond à une question étroite : la clé privée correspondante a-t-elle pu traiter cette encapsulation et ce texte sous la suite et le contexte fournis ? Il ne répond pas à la question de l’auteur humain ou institutionnel du message. La table de propriétés de RFC 9180 réserve d’ailleurs l’authentification d’émetteur aux autres modes ; le mode Base n’en porte pas.

Supposons qu’une plateforme publie la clé publique d’un service destiné à recevoir des demandes privées. Un client légitime peut l’utiliser. Un client non reconnu qui obtient la même clé publique peut également former un texte Base. Si le service ouvre ce texte, la réussite ne choisit pas entre les deux. C’est au protocole environnant de relier l’émetteur à une identité et de décider si cette identité peut employer ce canal.

Les données associées ne changent pas cette limite. Elles permettent de rendre certaines données indissociables du texte chiffré : un identifiant de locataire, une version, un type de requête. Mais HPKE ne choisit ni ces champs ni leur vérité. Un identifiant de compte authentifié comme octets peut rester une déclaration frauduleuse si aucune couche ne prouve que son émetteur avait le droit de le présenter.

Les modes authentifiés ne ferment pas tous les dossiers

RFC 9180 offre trois variantes. PSK permet au destinataire de vérifier que l’émetteur possédait le secret partagé configuré. Auth permet une assurance liée à la possession de la clé privée KEM d’émetteur. AuthPSK utilise les deux formes de matière secrète.

Ces mécanismes comptent. Une application qui a correctement approvisionné ses secrets peut en tirer une preuve cryptographique plus forte que celle du mode Base. Mais le verbe à conserver est « possédait ». Une clé ou un PSK peut être associé à une personne, un service, un rôle collectif, un module ou un environnement. Ce rattachement n’est pas une sortie du KEM. Il dépend de registres d’émission, d’une décision de portée, d’une rotation, d’une révocation et d’un responsable.

RFC 9180 précise aussi que Auth et AuthPSK authentifient la paire de clés de l’émetteur, pas tout autre identifiant. Lorsqu’une application veut lier un nom de domaine, une adresse ou une identité métier, elle doit l’inclure dans info. C’est une instruction de conception importante : le lien doit être délibéré, encodé et interprété par la couche qui possède cette identité.

Même cette assurance a des limites. Les variantes DHKEM Auth et AuthPSK décrites dans le RFC comportent une réserve de compromission de clé permettant l’usurpation dans les conditions précisées pour la clé destinataire. On ne doit donc pas lire un succès Auth comme un acte de non-répudiation intemporel. Il s’agit d’une propriété cryptographique conditionnelle, à une date, pour une configuration et un modèle d’adversaire déterminés.

Le danger de gouvernance arrive lorsque les journaux changent de vocabulaire. auth_mode_success peut être exact. « L’entreprise a autorisé cette instruction » nécessite pourtant au moins trois éléments supplémentaires : quelle entité contrôle la clé, quelle autorité elle avait pour ce type de message et quelle politique locale a accepté le contenu. Renommer une possession de secret en autorisation efface ces étapes au lieu de les réaliser.

info, AAD et l’enveloppe que HPKE ne dessine pas

Le protocole prévoit deux grandes positions pour l’information auxiliaire authentifiée. info accompagne la construction du contexte ; l’AAD accompagne une opération de scellement ou d’ouverture. La fonction d’export possède son propre contexte. Cette répartition aide une application à distinguer les données communes à un contexte des données qui changent par message.

Elle ne constitue pas un format de message. RFC 9180 ne fixe pas de représentation filaire HPKE. Toute application doit définir sans ambiguïté la valeur encapsulée, le ou les textes chiffrés, leur ordre lorsque plusieurs existent et les valeurs info non implicites. Lorsqu’un destinataire possède plusieurs clés publiques, le choix de la clé peut lui aussi devoir être présent dans cette enveloppe externe.

Ce détail est une frontière de contrôle. Le cadrage détermine quelles valeurs appartiennent à une même requête, comment les versions sont reconnues, quel mode et quelle suite sont attendus, et où un récepteur doit trouver le contexte. Une bibliothèque qui déchiffre correctement des octets ne peut pas résoudre une ambiguïté créée autour d’elle.

Le sens reste également extérieur. Une charge peut demander un changement de configuration, annoncer un état ou proposer une simple donnée de diagnostic. HPKE ne donne ni schéma, ni type métier, ni règle de rôle, ni mécanisme d’approbation. Avant toute conséquence, l’application doit analyser la structure, vérifier les champs, associer une identité, vérifier la fraîcheur, appliquer une politique et limiter l’exécution. Le chiffrement protège la route des octets ; il n’attribue pas leur compétence.

La date est aussi une décision d’autorité

Un texte chiffré correct peut être ancien. HPKE ne fournit une protection de rejeu limitée qu’à l’intérieur d’un flux issu du même contexte, lorsque les textes sont ouverts dans l’ordre où ils ont été scellés. En dehors de ce cadre, le RFC ne fournit pas de protection générale contre le rejeu.

Les applications qui utilisent plusieurs messages dans un contexte doivent imposer l’ordre. Une numérotation, une fenêtre, un identifiant immuable ou une clé d’idempotence peuvent servir à le faire, et l’information pertinente doit être liée comme données associées. Mais le choix de l’horloge, de la durée de validité et de la règle de refus est local. Un accord reçu hier peut être parfaitement déchiffrable et pourtant sans effet aujourd’hui.

La négociation de suite demande la même attention. RFC 9180 suppose que les deux côtés s’accordent sur les algorithmes ; selon la manière dont cet accord survient, un intermédiaire peut pousser des options moins bonnes. L’identifiant de suite indique ce qui a été utilisé. Il ne prouve pas que le choix a été protégé ou qu’il respectait une politique de l’organisation.

Enfin, les clés destinataires imposent une mémoire historique. Le RFC indique que les textes HPKE ne bénéficient pas de confidentialité persistante contre la compromission de la clé destinataire : la possession ultérieure du secret de long terme peut permettre de déchiffrer les textes passés destinés à cette clé. Ce n’est pas une accusation contre une installation donnée. C’est une raison de séparer la rotation, la rétention d’archives, l’enquête de compromission et la révocation des autorisations déjà exercées.

Une trace qui ne confond pas la cause et l’effet

Le premier registre doit couvrir le choix de la clé destinataire : identifiant, propriétaire, finalité autorisée, canal de distribution, dates d’émission et de retrait. Une clé publique visible n’accorde pas un droit universel d’envoyer n’importe quel type de message.

Le deuxième couvre la préparation : mode, suite, source du PSK ou de la clé d’émetteur, construction de info, AAD, enveloppe et décision de négociation. Une clé valable peut être utilisée hors de la portée qui lui a été confiée.

Le troisième couvre la réception : empreinte ou identifiant durable de l’encapsulation et du texte, clé destinataire, résultat de contexte, résultat de Open() et erreurs. Il faut nommer ce succès exactement, sans écraser les journaux de l’analyse et de la politique.

Le quatrième couvre l’interprétation : version de schéma, type de message, identité reconnue, état de révocation, fraîcheur, détection de rejeu, décision de politique et motif de rejet. Une charge chiffrée peut passer toutes les vérifications cryptographiques et être justement refusée ici.

Le dernier couvre l’effet : demande exprimée, demande autorisée, opération réalisée, observation indépendante et retour arrière. Une acceptation n’est pas une exécution ; une exécution n’est pas une conséquence vérifiée. La valeur du journal est de permettre de remonter de chaque action au fait qui l’a autorisée.