Introduction

Ce document présente le protocole d'accord de clés BlazeQ. BlazeQ permet à deux parties d'établir une clé secrète partagée tout en s'authentifiant mutuellement via des clés publiques. BlazeQ offre une confidentialité persistante résistante quantique.

BlazeQ est conçu pour les environnements asynchrones, où une partie (« Bob ») est hors ligne mais a mis certaines informations à disposition sur un serveur. Une autre partie (« Alice ») peut utiliser ces données publiées pour envoyer des informations chiffrées à Bob en toute sécurité et établir une clé secrète partagée pour les communications futures.

Notations

Ce document utilise les notations suivantes :

X || Y désigne la concaténation des séquences d'octets X et Y.

DH(SK, PK) désigne la séquence d'octets représentant le secret partagé généré par une opération Diffie-Hellman sur courbe elliptique (ECDH), où SK est la clé privée d'une paire de clés et PK est la clé publique d'une paire différente. Le secret partagé est dérivé en combinant ces deux clés.

SIG(SK, M) représente une signature sur le message M générée à l'aide de l'algorithme de signature Ed25519 ou Ed448, où SK est la clé privée. La signature peut être vérifiée à l'aide de la clé publique correspondante dérivée de SK.

ML-DSA-SIG(SK, M) représente une signature sur le message M générée à l'aide de l'un des algorithmes de signature ML-DSA (ML-DSA-44, ML-DSA-65 ou ML-DSA-87), où SK est la clé privée. La signature peut être vérifiée à l'aide de la clé publique correspondante dérivée de SK.

(CT, SS) = ML-KEM-ENC(PK) représente un tuple composé du chiffré KEM CT, généré par l'algorithme ML-KEM (avec les variantes ML-KEM-512, ML-KEM-768 ou ML-KEM-1024 selon les tailles de clés), et du secret partagé SS, encapsulé par le chiffré à l'aide de la clé publique PK.

ML-KEM-DEC(SK, CT) représente le secret partagé SS désencapsulé du chiffré post-quantique CT à l'aide de la clé privée SK, qui est le pendant de la clé publique PK utilisée pour encapsuler le chiffré.

Rôles

Le protocole BlazeQ implique trois participants principaux : Alice, Bob et un serveur.

  • Alice cherche à envoyer des données chiffrées à Bob tout en établissant une clé secrète partagée pour une communication sécurisée et bidirectionnelle.
  • Bob souhaite faciliter une communication sécurisée avec des parties telles qu'Alice, leur permettant d'établir une clé partagée et d'envoyer des données chiffrées. Cependant, Bob peut ne pas être en ligne lorsqu'Alice tente d'initier ce processus. Pour y remédier, Bob entretient une relation avec un serveur.
  • Le serveur remplit deux fonctions principales : il stocke les messages d'Alice à destination de Bob, que Bob peut récupérer ultérieurement lorsqu'il est en ligne, et il permet à Bob de publier des données auxquelles Alice peut accéder lorsqu'elle tente d'établir la clé partagée. Le niveau de confiance requis envers le serveur est un point important à considérer.

Dans notre implémentation, le rôle du serveur est distribué entre plusieurs entités, mais par souci de simplicité, ce protocole suppose un serveur unique qui remplit toutes ces fonctions pour Alice et Bob.

Clés de Courbe Elliptique

BlazeQ utilise les clés de courbe elliptique suivantes :

  • IKa — Clé d'identité sur courbe elliptique d'Alice.
  • IKb — Clé d'identité sur courbe elliptique de Bob.
  • EKa — Clé éphémère sur courbe elliptique d'Alice.
  • LKb — Clé à longue durée de vie sur courbe elliptique de Bob.
  • SPKb — Clé pré-générée à courte durée de vie sur courbe elliptique de Bob.
  • (OPKb1, OPKb2, OPKb3, …) — Ensemble de clés pré-générées à usage unique sur courbe elliptique de Bob.

Clés d'Encapsulation de Clés Post-Quantiques

BlazeQ utilise les clés post-quantiques suivantes :

  • PQIKa — Clé d'identité post-quantique d'Alice.
  • PQIKb — Clé d'identité post-quantique de Bob.
  • PQLKb — Clé à longue durée de vie post-quantique de Bob.
  • PQSPKb — Clé pré-générée à courte durée de vie post-quantique de Bob.
  • (PQOPKb1, PQOPKb2, PQOPKb3, …) — Ensemble de clés pré-générées à usage unique post-quantiques de Bob.

Vue d'Ensemble du Protocole

BlazeQ comporte trois phases :

  • Bob publie sa clé d'identité sur courbe elliptique, sa clé d'identité post-quantique, ses clés pré-générées sur courbe elliptique et ses clés pré-générées post-quantiques sur un serveur.
  • Alice récupère les clés d'identité et un « paquet de clés pré-générées » sur le serveur, et l'utilise pour envoyer un message initial à Bob.
  • Bob reçoit et traite le message initial d'Alice.

Publication des Clés

Bob publie un ensemble de clés de courbe sur le serveur contenant :

  • La clé d'identité sur courbe elliptique de Bob IKb.
  • La clé à longue durée de vie sur courbe elliptique signée de Bob et son identifiant (LKb, Id(LKb)).
  • La signature de Bob sur la clé à longue durée de vie sur courbe elliptique SIG(IKb, LKb).
  • La clé pré-générée à courte durée de vie sur courbe elliptique signée de Bob et son identifiant (SPKb, Id(SPKb)).
  • La signature de Bob sur la clé pré-générée à courte durée de vie sur courbe elliptique SIG(IKb, SPKb).
  • Un ensemble de clés pré-générées à usage unique sur courbe elliptique de Bob (OPKb1, OPKb2, OPKb3, …) avec leurs identifiants.
  • L'ensemble des signatures de Bob sur les clés pré-générées à usage unique signées (SIG(IKb, OPKb1), SIG(IKb, OPKb2), SIG(IKb, OPKb3), …).

Bob publie un ensemble de clés post-quantiques sur le serveur contenant :

  • La clé d'identité post-quantique de Bob PQIKb.
  • La clé à longue durée de vie post-quantique signée de Bob et son identifiant (PQLKb, Id(PQLKb)).
  • La signature de Bob sur la clé à longue durée de vie post-quantique ML-DSA-SIG(PQIKb, PQLKb).
  • La clé pré-générée à courte durée de vie post-quantique signée de Bob et son identifiant (PQSPKb, Id(PQSPKb)).
  • La signature de Bob sur la clé pré-générée à courte durée de vie post-quantique ML-DSA-SIG(PQIKb, PQSPKb).
  • Un ensemble de clés pré-générées à usage unique post-quantiques de Bob (PQOPKb1, PQOPKb2, PQOPKb3, …) avec leurs identifiants.
  • L'ensemble des signatures de Bob sur les clés pré-générées à usage unique post-quantiques signées (ML-DSA-SIG(PQIKb, PQOPKb1), ML-DSA-SIG(PQIKb, PQOPKb2), ML-DSA-SIG(PQIKb, PQOPKb3), …).

Envoi d'un Message

Pour initier un accord de clés BlazeQ avec Bob, Alice contacte le serveur afin de récupérer un « paquet de clés pré-générées ».

Le paquet de clés pré-générées inclut les clés de courbe suivantes :

  • La clé d'identité sur courbe elliptique de Bob (IKb).
  • La clé à longue durée de vie sur courbe elliptique signée de Bob, avec son identifiant : (LKb, Id(LKb)).
  • La signature de Bob sur la clé à longue durée de vie sur courbe elliptique : SIG(IKb, LKb).
  • La clé pré-générée à courte durée de vie sur courbe elliptique signée de Bob, avec son identifiant : (SPKb, Id(SPKb)).
  • La signature de Bob sur la clé pré-générée à courte durée de vie sur courbe elliptique : SIG(IKb, SPKb).
  • La clé pré-générée à usage unique sur courbe elliptique signée de Bob, avec son identifiant : (OPKb, Id(OPKb)).
  • La signature de Bob sur la clé pré-générée à usage unique sur courbe elliptique : SIG(IKb, OPKb).

Le paquet de clés pré-générées inclut les clés post-quantiques suivantes :

  • La clé d'identité post-quantique de Bob (PQIKb).
  • La clé à longue durée de vie post-quantique signée de Bob, avec son identifiant : (PQLKb, Id(PQLKb)).
  • La signature de Bob sur la clé à longue durée de vie post-quantique : ML-DSA-SIG(PQIKb, PQLKb).
  • La clé pré-générée à courte durée de vie post-quantique signée de Bob, avec son identifiant : (PQSPKb, Id(PQSPKb)).
  • La signature de Bob sur la clé pré-générée à courte durée de vie post-quantique : ML-DSA-SIG(PQIKb, PQSPKb).
  • La clé pré-générée à usage unique post-quantique signée de Bob, avec son identifiant : (PQOPKb, Id(PQOPKb)).
  • La signature de Bob sur la clé pré-générée à usage unique post-quantique : ML-DSA-SIG(PQIKb, PQOPKb).

Le serveur doit fournir l'une des clés pré-générées à usage unique disponibles de Bob, le cas échéant, puis supprimer la clé après utilisation. Si toutes les clés pré-générées à usage unique de Bob ont été supprimées, le paquet n'inclura pas d'élément à usage unique.

Alice doit donner la priorité à l'utilisation de l'une des clés pré-générées signées à usage unique disponibles de Bob. Si toutes ces clés sur le serveur ont été utilisées, Alice doit alors utiliser la clé pré-générée signée à courte durée de vie de Bob.

Alice vérifie les signatures sur les clés pré-générées. Si une vérification de signature échoue, Alice abandonne le protocole. Si toutes les vérifications réussissent, Alice génère une clé éphémère sur courbe elliptique EKa, puis calcule :

  • DH1 = DH(LKa, LKb)
  • DH2 = DH(EKa, LKb)
  • DH3 = DH(EKa, OPKb) si OPKb existe, sinon DH3 = DH(EKa, SPKb)
  • DH4 = DH(LKa, OPKb) si OPKb existe, sinon DH4 = DH(LKa, SPKb)

Alice génère un secret partagé post-quantique encapsulé à l'aide de l'une des clés pré-générées à usage unique disponibles de Bob, le cas échéant. Si aucune n'est disponible, elle génère le secret partagé à l'aide de la clé pré-générée à courte durée de vie de Bob. En parallèle, Alice génère également un secret partagé post-quantique encapsulé à l'aide de la clé à longue durée de vie de Bob.

  • (CT1, SS1) = ML-KEM-ENC(PQLKb)
  • (CT2, SS2) = ML-KEM-ENC(PQOPKb) si PQOPKb existe, sinon (CT2, SS2) = ML-KEM-ENC(PQSPKb)

Enfin, Alice calcule la clé partagée SK à l'aide de la fonction de dérivation de clés KDF comme suit :

  • SK = KDF(DH1 || DH2 || DH3 || DH4 || SS1 || SS2)

Alice envoie ensuite à Bob un message initial contenant :

  • La clé d'identité sur courbe elliptique d'Alice IKa.
  • La clé à longue durée de vie sur courbe elliptique d'Alice LKa.
  • La clé éphémère sur courbe elliptique d'Alice EKa.
  • Les chiffrés post-quantiques CT1 et CT2 encapsulant respectivement SS1 et SS2.
  • Les signatures d'Alice sur les chiffrés post-quantiques : ML-DSA-SIG(PQIKa, CT1), ML-DSA-SIG(PQIKa, CT2).
  • Des identifiants indiquant quelles clés pré-générées de Bob Alice a utilisées.
  • Un chiffré initial chiffré avec AES-GCM en utilisant AD comme données associées et une clé de chiffrement dérivée de SK.

Réception d'un Message

Bob récupère les valeurs suivantes du message initial d'Alice :

  • La clé d'identité sur courbe elliptique d'Alice (IKa).
  • La clé à longue durée de vie sur courbe elliptique d'Alice (LKa).
  • La clé éphémère sur courbe elliptique d'Alice (EKa).
  • Les chiffrés post-quantiques (CT1, CT2).
  • Les identifiants des clés pré-générées utilisées par Alice.
  • Le chiffré initial chiffré par AEAD.

Bob vérifie que les clés pré-générées utilisées par Alice correspondent à celles qu'il a fournies au serveur. Si l'identifiant correspond à une clé à usage unique, Bob vérifie que la clé n'a pas déjà été utilisée et la supprime après cette session. Si une clé à usage unique est indisponible, Bob vérifie qu'Alice a utilisé sa clé à courte durée de vie.

Bob calcule les secrets partagés Diffie-Hellman nécessaires :

  • DH1 = DH(LKb, LKa)
  • DH2 = DH(LKb, EKa)
  • DH3 = DH(OPKb, EKa) si OPKb existe, sinon DH3 = DH(SPKb, EKa)
  • DH4 = DH(OPKb, LKa) si OPKb existe, sinon DH4 = DH(SPKb, LKa)

Bob déchiffre les secrets partagés post-quantiques encapsulés :

  • SS1 = ML-KEM-DEC(PQLKb, CT1)
  • SS2 = ML-KEM-DEC(PQOPKb, CT2) si PQOPKb existe, sinon SS2 = ML-KEM-DEC(PQSPKb, CT2)

Bob dérive la clé partagée à l'aide de la fonction de dérivation de clés KDF :

  • SK = KDF(DH1 || DH2 || DH3 || DH4 || SS1 || SS2)

Considérations de Sécurité

La sécurité du protocole BlazeQ a été soigneusement conçue pour garantir un établissement de clé sécurisé et une confidentialité persistante en présence d'adversaires quantiques. Bien que le protocole s'appuie à la fois sur le Diffie-Hellman classique sur courbe elliptique (ECDH) et sur des mécanismes d'encapsulation de clé post-quantiques (PQKEM), il est essentiel de prendre en compte les vecteurs d'attaque potentiels et les hypothèses sous-jacentes à la sécurité du protocole.

BlazeQ garantit la confidentialité persistante post-quantique grâce à une approche hybride, combinant l'échange de clés basé sur la courbe elliptique (ECDH) avec un KEM post-quantique. Le processus d'établissement de clé nécessite de résoudre à la fois le problème Diffie-Hellman classique et l'hypothèse de sécurité post-quantique pour les KEMs, ce qui offre une forte résistance aux attaques quantiques ciblant l'un ou l'autre composant.

Authentification

BlazeQ garantit l'authentification mutuelle entre Alice et Bob en employant une approche de double signature, combinant les signatures sur courbe elliptique avec des signatures cryptographiques post-quantiques. Ce mécanisme hybride assure une authentification robuste, même face à des adversaires disposant de capacités quantiques. Cependant, avant ou après un accord de clé, Alice et Bob devraient s'authentifier mutuellement de manière indépendante via une méthode hors bande (par exemple, comparaison d'empreintes ou scan de code QR).

Si une telle méthode n'est pas employée, le protocole ne garantit pas l'identité des parties, en particulier en présence d'un serveur malveillant ou d'une attaque de l'homme du milieu.

Déni Plausible

BlazeQ supporte le déni plausible cryptographique, ce qui signifie qu'il n'offre pas aux participants de preuve cryptographique du contenu de leur communication ou de la preuve qu'ils ont communiqué.

Le protocole vise le déni hors ligne : si un tiers (par exemple un juge) obtient accès à la clé secrète de l'un des participants, il ne peut pas prouver que la communication a eu lieu sur la seule base de la transcription. Cette propriété est importante lorsque la communication se produit dans une situation où une partie pourrait avoir besoin de nier ultérieurement toute implication.

Le déni plausible face à un adversaire quantique reste un défi. Des révisions futures pourraient introduire des mécanismes offrant un déni plausible résistant quantique.

Confidentialité Persistante

La confidentialité persistante dans BlazeQ est garantie par l'utilisation de clés éphémères et de clés pré-générées à usage unique. Même si la clé privée à long terme d'un participant est compromise dans le futur, les clés de session précédentes (SK) resteront sécurisées. Cela est assuré par la suppression des clés pré-générées à usage unique après chaque utilisation et par l'utilisation de clés éphémères pour établir la clé de session.

En cas de compromission de clé, les clés de session sont protégées tant que les clés éphémères et pré-générées sont correctement gérées. Le protocole offre la confidentialité persistante même si la clé privée d'une partie est compromise ultérieurement, à condition que les clés à usage unique ou éphémères pertinentes ne soient pas réutilisées ou exposées.

Compromission de Clé

Les scénarios de compromission de clé représentent des risques de sécurité significatifs, mais BlazeQ intègre des stratégies pour atténuer ces risques. La compromission de la clé privée d'un participant peut conduire à une usurpation d'identité ou à la divulgation de clés de session de communications passées. Cependant, le protocole garantit que les clés compromises ne compromettent pas immédiatement la sécurité des communications futures.

Compromission des Clés d'Identité : Si la clé d'identité d'un participant (par exemple IKa ou PQIKa) est compromise, sa capacité à s'authentifier dans les sessions futures est affectée. Cependant, les clés de session des sessions précédentes resteront sécurisées tant que les clés éphémères ou pré-générées n'ont pas été exposées.

Compromission des Clés Pré-Générées : La compromission de clés pré-générées (par exemple SPKb, PQSPKb) pourrait potentiellement compromettre les clés de session passées qui ont utilisé ces clés pré-générées. La rotation fréquente des clés pré-générées et l'utilisation d'un protocole de rochet peuvent atténuer ce risque en mettant à jour fréquemment les clés de session.

Compromission des Clés Pré-Générées à Usage Unique : Si un attaquant compromet une clé pré-générée à usage unique (par exemple OPKb ou PQOPKb) pendant ou après une session, cela ne peut affecter que cette session particulière. Cependant, comme ces clés sont supprimées après utilisation, l'attaquant ne peut pas les réutiliser et l'impact est limité à cette unique session.

Adversaires Quantiques Passifs

BlazeQ est spécifiquement conçu pour atténuer le risque d'attaques du type « collecter maintenant, déchiffrer plus tard » par des adversaires disposant d'un ordinateur quantique capable de calculer des logarithmes discrets sur des courbes elliptiques. La sécurité de BlazeQ repose principalement sur le mécanisme d'échange de clés post-quantiques (PQKEM), mais dépend également de la capacité de l'AEAD à fournir une sécurité IND-CPA et INT-CTXT post-quantique.

  • Protection des Clés Publiques Résistantes Quantiques : Si un attaquant a enregistré les données publiques et le message envoyé d'Alice à Bob, l'accès à un ordinateur quantique ne lui permettra pas de compromettre la clé secrète de session (SK).
  • Sécurité des Clés Pré-Générées à Usage Unique : Si une clé pré-générée à usage unique d'encapsulation post-quantique (PQOPKB) est utilisée dans une session de protocole et correctement supprimée après utilisation, tout accès futur à un ordinateur quantique ne permettra pas à l'attaquant de récupérer la SK.
  • Impact de l'Absence de Clés Pré-Générées à Usage Unique : Si une clé pré-générée à usage unique post-quantique n'a pas été utilisée lors de l'exécution du protocole, l'accès à un ordinateur quantique et la compromission de la clé privée de PQSPKB pourraient potentiellement révéler la SK calculée lors de cette session. Une rotation fréquente des clés pré-générées et l'utilisation d'un protocole de rochet sont recommandées pour atténuer ce risque.

Adversaires Quantiques Actifs

BlazeQ est spécifiquement conçu pour protéger contre les adversaires quantiques actifs. Un attaquant actif disposant d'un ordinateur quantique capable de calculer des logarithmes discrets sur des courbes elliptiques peut calculer DH(PK1, PK2) et Sig(PK, M) pour toutes les clés de courbe elliptique. Cependant, BlazeQ intègre des techniques cryptographiques post-quantiques, notamment la signature post-quantique, qui garantissent que même avec un ordinateur quantique, un attaquant ne peut pas usurper l'identité d'Alice ou de Bob.

En cas de tentative d'un serveur malveillant d'usurper l'identité de Bob, BlazeQ permet à Bob d'utiliser une clé d'identité post-quantique pour signer ses clés pré-générées post-quantiques, garantissant qu'Alice peut vérifier cryptographiquement qu'elle communique bien avec Bob. Cela empêche les attaques de l'homme du milieu par un adversaire disposant de capacités quantiques.

De plus, BlazeQ garantit l'authentification mutuelle, ce qui signifie qu'Alice et Bob peuvent tous deux être assurés de l'identité de l'autre. Cette authentification mutuelle est réalisée grâce à l'utilisation de signatures post-quantiques, qui protègent l'intégrité des clés échangées et empêchent les attaquants de falsifier ou d'altérer la communication.