ASCON-AEAD128

Contexte & problème résolu

Le chiffrement authentifié à données associées (AEAD) rend un message confidentiel tout en garantissant son intégrité et son authenticité via un tag, à partir d'une clé partagée. ASCON est la famille retenue par le NIST à l'issue de son concours Lightweight Cryptography (2019-2023) comme nouveau standard de cryptographie légère, destiné aux environnements contraints : objets connectés, cartes à puce, capteurs, microcontrôleurs.

Sa conception orientée matériel (permutation à base de portes simples, état compact de 320 bits, absence de tables volumineuses) en fait un candidat idéal pour une implémentation directe en logique. Tech Fox a livré la variante ASCON-AEAD128 sous forme de circuit numérique décrit au niveau RTL, couvrant tout le chemin de chiffrement : initialisation, absorption des données associées, chiffrement en trois blocs, finalisation et extraction du tag.

L'enjeu n'est pas cryptographique (l'algorithme est public et normalisé) mais architectural : traduire fidèlement une spécification mathématique séquentielle en un circuit synchrone cadencé dont chaque bit de sortie doit correspondre exactement à la référence ; la moindre erreur d'un bit rendant le déchiffrement impossible et invalidant le tag.

L'état ASCON et la permutation (structure publique)

Tout ASCON opère sur un état interne de 320 bits, lu selon trois découpages complémentaires : en 5 mots de 64 bits (S0 à S4), en deux parties (rate de 128 bits où entrent/sortent les données, capacity de 192 bits qui porte l'initialisation et l'authentification), et en 64 colonnes de 5 bits (vue exploitée par la couche de substitution).

Le moteur est une permutation appliquée de façon répétée : p12 (12 rondes) pour l'initialisation et la finalisation, p8 (8 rondes) pour les données associées et chaque bloc de texte clair. Chaque ronde enchaîne trois opérations : addition d'une constante de round sur les 8 bits de poids faible de S2, substitution par la S-box de 5 bits appliquée aux 64 colonnes, puis diffusion linéaire (mélange interne de chaque mot par rotations cycliques et XOR).

• Flux complet : Initialisation (IV‖K‖N puis p12, XOR clé) → Données associées (p8 + séparation de domaine) → Chiffrement de 3 blocs (Ci = rate ⊕ Pi, puis p8) → Finalisation (p12 avec réinjection de clé) → extraction du tag.
• Astuce hardware clé : une rotation de n bits ne coûte aucune porte ; c'est un simple réadressage de fils. La couche de diffusion se ramène ainsi à un réseau de XOR câblés sur des bus décalés.

Architecture matérielle : datapath + contrôle

Le circuit est organisé de façon hiérarchique ascendante : chaque brique est décrite, compilée puis testée isolément avant assemblage. Les primitives combinatoires (S-box de 5 bits en table de vérité, instanciée 64 fois en parallèle ; diffusion linéaire ; addition de constante) sont composées en une ronde, elle-même intégrée dans un chemin de données bouclé.

L'astuce de conception centrale est le bypass des deux XOR d'injection : un multiplexeur d'entrée transforme la ronde combinatoire en itération cadencée (à chaque coup d'horloge, l'état repasse dans la permutation), tandis que deux XOR conditionnels (sur le rate (injection des données/texte clair) et sur la capacity (injection de la clé, séparation de domaine)) peuvent être court-circuités. Un unique chemin de données joue ainsi, selon la phase, soit l'enchaînement pur des rondes, soit l'injection d'opérandes, sans dupliquer de logique. Le texte chiffré est capturé dans un registre 128 bits juste après le XOR d'entrée ; le tag est extrait en fin d'algorithme.

Le pilotage est confié à une machine à états finis de Moore (sorties dépendant du seul état courant) : un choix adapté à un processus linéaire et déterministe, plus lisible et plus sûr temporellement. Un compteur de rondes dédié (qui sait s'initialiser à 0 pour p12 ou à 4 pour p8) libère la FSM de la gestion fine des rondes et agit comme un « fusible » ramenant le système à un état sûr en cas d'anomalie.

La machine de Moore ; 18 états

La machine énumère 18 états (encodés sur 5 bits) qui décomposent finement les quatre phases : attente (idle), initialisation p12, données associées p8, chiffrement p8 (deux fois), et finalisation p12 avec capture du tag. Les boucles d'attente testent la valeur du compteur pour rester dans un état tant que la permutation n'est pas terminée.

Un point de contrôle a été déterminant et a d'abord piégé la conception : dans la logique combinatoire, chaque signal de sortie retourne à sa valeur par défaut entre deux états ; un signal forcé à 1 ne « reste » pas à 1 à l'état suivant. La discipline adoptée (bloc de valeurs par défaut en tête, puis surcharge état par état des seuls signaux actifs) garantit qu'aucun signal ne traîne d'un état à l'autre, cause classique de permutations parasites.

Validation bit-exacte sous ModelSim

La méthodologie est ascendante et testée à chaque étage : tout module est accompagné d'un banc de test qui l'instancie, lui applique des stimuli et compare la sortie à la valeur théorique issue des vecteurs officiels ASCON. Deux modes : affichage textuel des valeurs hexadécimales et analyse des chronogrammes. Chaque brique (S-box, addition de constante, substitution, diffusion, permutation, compteur) a été confirmée conforme avant intégration.

La simulation finale du module d'enveloppe exécute automatiquement l'intégralité du chiffrement via la machine de Moore. Les trois blocs de texte chiffré C1, C2, C3 et le tag sortent en correspondance bit à bit avec les valeurs attendues, le rapport ModelSim se concluant par « Errors: 0, Warnings: 0 ». Les chronogrammes confirment visuellement le déroulé : trois captures de ciphertext suivies d'une capture de tag.

• Débogage marquant : un bug de la S-box a résisté des semaines ; une simple erreur de transcription manuelle de la table (une entrée dupliquée). Leçon retenue et documentée : privilégier le copier-coller aux recopies manuelles pour les tables critiques.
• Migration vers une installation locale de ModelSim pilotée par script de compilation, après instabilité du serveur distant.