ASCON sur FPGA — du SystemVerilog à la ZedBoard

Projet de la majeure Systèmes embarqués : concevoir en SystemVerilog le cœur matériel du chiffrement authentifié ASCON-128, le valider en simulation, puis construire autour de lui la couche d'intégration qui le fait tourner et s'afficher sur une carte FPGA réelle.

ASCON est le chiffrement authentifié retenu par le NIST en 2023 pour la cryptographie légère — celle des objets contraints, capteurs et cartes à puce. Son principe tient en un état de 320 bits que l'on malaxe par une permutation, et dont seuls 64 bits (le « rate ») sont exposés à la donnée : le reste, la capacité, ne sort jamais. Quatre phases s'enchaînent sur ce même état — initialisation, absorption des données associées, chiffrement bloc par bloc, finalisation — et le même passage produit à la fois le texte chiffré et un tag d'authentification de 128 bits.

Le cœur de l'implémentation est la permutation. Un tour enchaîne trois couches purement combinatoires : l'addition d'une constante de tour, une couche de substitution faite de 64 boîtes-S de 5 bits instanciées en parallèle par un bloc generate — chacune prenant une tranche verticale de bits à travers les cinq mots de l'état — puis une diffusion linéaire où chaque mot est XORé avec deux copies de lui-même décalées circulairement. J'avais déjà implémenté ASCON intégralement de zéro l'année précédente, dans un autre projet académique ; cette version-ci repart de la base de code distribuée avec le sujet — registres à enable, multiplexeur d'état et compteur fournis — pour concentrer l'effort sur la permutation, sa machine à états, et surtout l'intégration matérielle qui suit.

Le choix d'architecture structurant est de replier ce tour sur lui-même : une seule instance combinatoire, bouclée sur un registre d'état de 320 bits, exécute un tour par coup d'horloge. C'est le compromis classique surface contre débit — déplier les douze tours aurait divisé la latence mais multiplié la logique d'autant. Une machine à états de Moore à vingt-six états séquence les phases et pilote tous les signaux d'activation, pendant qu'un compteur de tours à double initialisation distingue les douze tours de l'initialisation des six tours du traitement des données.

La validation s'est faite en simulation sur un banc de test fourni avec le sujet, avec une clé et un nonce de 128 bits et plusieurs blocs de données. Le chronogramme se lit comme la spécification : les signaux de fin de phase s'allument l'un après l'autre, le bloc chiffré apparaît quand cipher_valid passe à 1, et le tag se fige en fin de finalisation.

La seconde partie du projet consistait à rendre tout cela visible sur une carte réelle, une ZedBoard à Zynq-7020. J'ai écrit autour du cœur une couche d'intégration : un MMCM qui porte l'horloge de carte de 100 à 150 MHz, une mémoire bloc contenant les blocs à chiffrer, un compteur d'adresse, et une seconde machine à états — dix états cette fois — qui orchestre le tout : lire un bloc, le présenter, attendre l'accusé du cœur, incrémenter, recommencer, puis déclencher la finalisation.

Restait le problème d'affichage : comment montrer un chiffré de 64 bits et un tag de 128 bits sur huit LEDs ? La réponse est une cascade de deux multiplexeurs pilotés par les interrupteurs de la carte — le premier choisit entre chiffré et tag, le second sélectionne un octet parmi seize. On parcourt ainsi le résultat octet par octet. L'implémentation tient dans 857 LUT, soit 1,6 % du composant, avec 573 bascules et un seul bloc RAM, et respecte le timing à 150 MHz avec 0,182 ns de marge.