9.1.2. Computational Analysis (Analyse computationnelle)
9.1.2. Analyse computationnelle
Il est démontré dans [CS01] qu'un schéma de chiffrement à clé publique hybride essentiellement de la même forme que le mode Base décrit ici est IND-CCA2-sécurisé tant que les schémas KEM et AEAD sous-jacents sont IND-CCA2-sécurisés. De plus, il est démontré dans [HHK06] que la sécurité IND-CCA2 du KEM et du mécanisme d'encapsulation de données sont des conditions nécessaires pour atteindre la sécurité IND-CCA2 pour le chiffrement à clé publique hybride. La principale différence entre le schéma proposé dans [CS01] et le mode Base dans ce document (tous deux nommés HPKE) est que nous interposons quelques appels KDF entre le KEM et l'AEAD. L'analyse de l'instanciation du mode Base HPKE dans ce document nécessite donc de vérifier que les appels KDF supplémentaires ne provoquent pas l'échec de la propriété IND-CCA2, ainsi que de vérifier la propriété supplémentaire de confidentialité de la clé d'exportation.
L'analyse des modes PSK, Auth et AuthPSK définis dans ce document nécessite en outre de vérifier la propriété d'authentification de l'expéditeur. Alors que le mode PSK ajoute simplement du matériel de clé supplémentaire à l'ordonnancement des clés, les modes Auth et AuthPSK utilisent une construction KEM authentifiée non standard. En général, les modes authentifiés de HPKE peuvent être vus et analysés comme des variantes de signcryption [SigncryptionDZ10].
Une analyse computationnelle préliminaire de tous les modes HPKE a été effectuée dans [HPKEAnalysis], indiquant une sécurité asymptotique pour le cas où le KEM est DHKEM, l'AEAD est n'importe quel schéma IND-CPA-sécurisé et INT-CTXT-sécurisé, et le groupe DH et le KDF satisfont les conditions suivantes :
-
Groupe DH : Le problème Diffie-Hellman à écart (GDH) est difficile dans le sous-groupe approprié [GAP].
-
Extract() et Expand() : Extract() peut être modélisé comme un oracle aléatoire. Expand() peut être modélisé comme une fonction pseudo-aléatoire, où le premier argument est la clé.
En particulier, les KDF et les groupes DH définis dans ce document (voir Sections 7.2 et 7.1) satisfont ces propriétés lorsqu'ils sont utilisés comme spécifié. L'analyse dans [HPKEAnalysis] démontre que sous ces contraintes, HPKE continue de fournir la sécurité IND-CCA2 et fournit les propriétés supplémentaires notées ci-dessus. De plus, l'analyse confirme que les propriétés attendues sont valables dans les différents cas de compromission de clé mentionnés ci-dessus. L'analyse considère un expéditeur qui envoie un message en utilisant le contexte de chiffrement, et exporte en outre deux secrets indépendants en utilisant l'interface d'exportation de secrets.
Le tableau ci-dessous résume les principaux résultats de [HPKEAnalysis]. N/A signifie qu'une propriété ne s'applique pas pour le mode donné, tandis que Y signifie que le mode donné satisfait la propriété.
| Variante | Conf. message | Conf. export | Auth. expéditeur |
|---|---|---|---|
| Base | Y | Y | N/A |
| PSK | Y | Y | Y |
| Auth | Y | Y | Y |
| AuthPSK | Y | Y | Y |
Tableau 6 : Propriétés de sécurité des modes HPKE
Si des KEM non basés sur DH doivent être utilisés avec HPKE, une analyse supplémentaire sera nécessaire pour prouver leur sécurité. Les résultats de [CS01] fournissent quelques indications qu'un KEM IND-CCA2-sécurisé suffira ici, mais ne sont pas concluants compte tenu des différences dans les schémas.
Une analyse computationnelle détaillée de l'API de chiffrement à usage unique du mode Auth de HPKE a été effectuée dans [ABHKLR20]. L'article définit des notions de sécurité pour les KEM authentifiés et pour le chiffrement à clé publique authentifié, en utilisant la terminologie de sécurité externe et interne connue de la signcryption [SigncryptionDZ10]. L'analyse prouve que l'interface AuthEncap()/AuthDecap() de DHKEM remplit ces notions pour tous les groupes Diffie-Hellman spécifiés dans ce document. L'analyse fournit également des bornes de sécurité exactes, sous les hypothèses que le problème Diffie-Hellman à écart (GDH) est difficile dans le sous-groupe approprié [GAP], et que HKDF peut être modélisé comme un oracle aléatoire.
De plus, [ABHKLR20] prouve des théorèmes de composition, montrant que le mode Auth de HPKE remplit les notions de sécurité du chiffrement à clé publique authentifié pour tous les KDF et schémas AEAD spécifiés dans ce document, étant donné n'importe quel KEM authentifié satisfaisant les notions de sécurité précédemment définies pour les KEM authentifiés. Les théorèmes supposent que le KEM est parfaitement correct ; ils pourraient facilement être adaptés pour fonctionner avec des KEM qui ont une probabilité non nulle mais négligeable d'échec de déchiffrement. Les hypothèses sur le KDF sont que Extract() et Expand() peuvent être modélisés comme des fonctions pseudo-aléatoires où le premier argument est la clé, respectivement. L'hypothèse pour l'AEAD est la sécurité IND-CPA et IND-CTXT.
En résumé, l'analyse dans [ABHKLR20] prouve que l'API de chiffrement à usage unique du mode Auth de HPKE satisfait les propriétés souhaitées de confidentialité des messages et d'authentification de l'expéditeur énumérées au début de cette section ; elle ne considère pas plusieurs messages, ni l'API d'exportation de secrets.