Résumé

  • Avec SIV, la répétition d’un nonce ne donne pas à l’attaquant un moyen de forger un message accepté ; elle révèle toutefois si le même clair et les mêmes données associées reviennent sous la même clé.
  • Le mot « résistant » décrit la conséquence d’une faute. Il ne remplace ni l’unicité attendue du nonce, ni la preuve du mode choisi, ni l’interdiction de livrer le clair avant vérification.

La panne a une forme précise

RFC 5297 construit l’IV au lieu de le recevoir comme une valeur indépendante. S2V calcule, avec CMAC, une valeur de 128 bits à partir d’un vecteur de données associées et du texte en clair. Cette valeur synthétique sert ensuite de point de départ à AES en mode compteur. Le résultat publié est l’IV synthétique suivi d’un chiffré de même longueur que le clair.

Ce choix relie intimement l’authentification au contenu. Si deux appels utilisent la même clé, le même nonce, les mêmes données associées et le même clair, ils produisent le même résultat. Si le clair ou les données associées changent, la construction vise à empêcher la catastrophe classique du compteur répété. L’authenticité subsiste ; la confidentialité perd le secret de l’égalité.

Ce n’est ni « aucune fuite », ni « tout est cassé ». Pour une commande à deux états, un jeton dont la valeur se répète, une décision d’accès rare ou une clé issue d’un petit ensemble, l’égalité peut suffire à révéler un rythme, un choix ou la permanence d’une politique. Le bon rapport d’incident doit donc nommer la relation exposée, le nombre de répétitions et la classe des objets, au lieu de conclure à partir du seul succès cryptographique.

Le mode déterministe n’est pas un nonce oublié

SIV offre deux usages distincts. Dans le mode AEAD à nonce, celui-ci occupe la dernière position du vecteur de données associées, juste avant le clair. Un nonce aléatoire devrait compter au moins 128 bits et venir d’une source offrant au moins 128 bits d’entropie. Un compteur ou un horodatage peut également convenir si le protocole garantit l’invariant correspondant.

Dans le mode déterministe, aucun nonce n’est nécessaire. RFC 5297 vise notamment l’enveloppement authentifié d’une clé, c’est-à-dire un clair imprévisible pour l’adversaire. Les données associées peuvent toujours lier l’objet à un destinataire, un usage ou une version.

L’absence de nonce est donc correcte dans un profil et fautive dans l’autre. Une bibliothèque qui expose le même type d’objet de sortie pour les deux cas ne transporte pas l’autorité de choisir. Le reçu doit dire quel profil a été autorisé, pourquoi le clair du mode déterministe était suffisamment imprévisible et quel composant jouait le rôle de nonce dans le mode non déterministe.

Les frontières du vecteur sont authentifiées

S2V traite plusieurs chaînes variables comme des composants distincts. Leur ordre et leur découpage appartiennent au message authentifié. client, objet, version et destination ne forment pas une simple succession de caractères ; ce sont quatre positions dont la signification dépend d’un schéma.

L’interface AEAD de RFC 5116 ne reçoit qu’un bloc de données associées. Pour y faire passer le vecteur de SIV, il faut l’encoder sans ambiguïté. Une concaténation naïve peut confondre deux composants ab et c avec a et bc. Une longueur, un type et une version de schéma doivent rendre la reconstruction unique.

Un tag valide prouve que les mêmes octets ont été vérifiés. Il ne prouve pas qu’un producteur ancien et un consommateur nouveau ont attribué les mêmes champs à ces octets. La migration du schéma AD mérite son propre test de compatibilité et son propre identifiant dans le reçu.

La borne de 126 composants AD n’est pas un détail d’implémentation. S2V ne doit pas dépasser 127 composants au total et le clair en consomme un. Un adaptateur qui fusionne silencieusement des champs, en abandonne un ou modifie leur ordre pour franchir une limite a changé l’affirmation protégée.

Le clair provisoire doit rester sans pouvoir

À la réception, AES-CTR permet d’obtenir des octets candidats. SIV recalcule ensuite S2V avec le même vecteur AD et compare le résultat à l’IV reçu. Si les valeurs diffèrent, l’unique résultat autorisé est FAIL.

Entre les deux étapes existe une tentation d’architecture : envoyer les octets candidats vers un analyseur, un journal ou un cache afin de réduire la latence. Cette optimisation prête une autorité au clair avant l’authentification. La construction peut être correctement codée et l’interface tout de même dangereuse.

La télémétrie utile sépare donc le début du déchiffrement, la quarantaine du candidat, la comparaison, la décision d’authentification et la libération. Elle sépare encore cette libération de l’acceptation par l’application. Une vérification cryptographique n’établit pas que l’objet était conforme au schéma, autorisé ou appliqué sans erreur.

Un registre n’observe pas l’exécution

IANA associe les valeurs 15, 16 et 17 aux trois tailles de clé AES-SIV-CMAC de RFC 5297. Cette coordination évite que deux protocoles donnent des sens différents au même numéro. Elle ne montre pas quel algorithme a réellement tourné, comment la clé a été divisée, si le nonce était unique, si l’AD était bien formée ou si le clair a attendu la vérification.

Le reçu d’exploitation relie l’identifiant d’algorithme et de version ; la génération de clé ; le mode ; le schéma et les condensats des composants AD ; la source et la décision d’unicité du nonce ; le condensat de l’IV synthétique ; le verdict ; la décision de libération ; la détection de doublon ; l’évaluation de fuite d’égalité ; l’acceptation aval ; et les compteurs d’appels par clé. Aucun octet secret n’y figure.

Sources