💻 computer science

Controller Datapath Aware Verification of Masked Hardware Generated via High Level Synthesis

Dit artikel introduceert MaskedHLSVerif, een verificatiestroom die specifiek is ontworpen om de beveiliging van gemaskerde hardware gegenereerd via High Level Synthesis te valideren door staatsgebaseerde formele verificatie toe te passen en zo vals-positieve resultaten te voorkomen die ontstaan door gedeelde datapaden in controller-datapath-architecturen.

Oorspronkelijke auteurs: Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

Gepubliceerd 2026-03-20

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer geheim recept voor een taart hebt. Dit recept is zo belangrijk dat als iemand het leest, ze je hele bedrijf kunnen overnemen. Om dit geheim te beschermen, gebruik je een trucje: je verdeelt het recept in drie losse stukjes (de "delen" of shares). Niemand van de drie mensen die elk stukje houden, kan het volledige recept aflezen. Ze moeten samenwerken, maar op een heel specifieke manier, zodat ze het geheim niet per ongeluk onthullen terwijl ze werken.

In de wereld van computers en cryptografie noemen we dit maskering (masking). Het is een schild tegen "Power Side-Channel Attacks". Dat klinkt ingewikkeld, maar het is eigenlijk simpel: een hacker meet hoe veel stroom een apparaat verbruikt terwijl het het recept berekent. Uit die stroompieken kan de hacker soms het geheime recept reconstrueren. Maskering zorgt ervoor dat die stroompieken niets zeggen over het geheim.

Het Probleem: De Snelle Bouwer die te snel gaat

Vroeger bouwden mensen deze beveiligde computerchips handmatig. Dat is als het bouwen van een kasteel steen voor steen. Het kost veel tijd, is lastig, en als je één steen verkeerd zet, is het hele kasteel onveilig.

Tegenwoordig gebruiken ingenieurs een soort "AI-bouwer" genaamd High-Level Synthesis (HLS). Je geeft de AI het recept in een simpele taal (C-code), en de AI bouwt automatisch de complexe computerchip (RTL) voor je. Het is snel en handig!

Maar hier zit de addertje onder het gras:
Deze AI-bouwer is getraind om snel en klein te bouwen. Hij denkt niet na over geheimen. Hij gebruikt slimme trucs om ruimte te besparen.

De Analogie: Stel je voor dat je drie mensen hebt die elk een stukje van het recept moeten verwerken. De AI-bouwer zegt: "Waarom drie aparte keukens bouwen? Laten we één grote keuken gebruiken en de drie mensen om de beurt laten werken."
Het Gevaar: In de theorie werkt dit prima. Maar de AI bouwt de keuken zo dat de mensen soms per ongeluk ingrediënten van elkaar kunnen zien, of dat de volgorde van werken verandert. De AI denkt: "Dat is veilig, want ze doen het niet tegelijk." Maar voor een hacker die naar de stroomverbruik kijkt, is dat verschil soms net genoeg om het geheim te stelen.

De Oude Controleurs (De "REBECCA" Tool)

Er zijn al bestaande controleurs (zoals een tool genaamd REBECCA) die controleren of zo'n chip veilig is. Maar deze controleurs kijken naar de blauwdrukken alsof het een statisch gebouw is. Ze denken: "Als er een deur is, kan iedereen erdoorheen."

In onze keuken-analogie kijken ze naar de blauwdruk en zien ze een deur tussen de drie mensen. Ze zeggen: "Aha! Als Mens A en Mens B tegelijk door die deur lopen, kunnen ze elkaar zien! Gevaar!"
Het probleem is dat in de echte chip (die door de AI is gebouwd) die deur nooit tegelijk open gaat. De AI zorgt ervoor dat Mens A eerst gaat, en dan pas Mens B. De oude controleur ziet dit niet en roept ten onrechte: "Gevaar!" Dit noemen we een valse alarm (false positive). Omdat ze zo vaak fout alarm slaan, vertrouwen ingenieurs ze niet meer voor deze nieuwe, snelle chips.

De Nieuwe Oplossing: "MaskedHLSVerif"

De auteurs van dit paper hebben een nieuwe controleur bedacht, genaamd MaskedHLSVerif. In plaats van naar het hele gebouw tegelijk te kijken, kijken ze stap voor stap.

De Analogie van de Regisseur:
Stel je voor dat je een toneelstuk bekijkt.

De oude controleur (REBECCA) kijkt naar het script en zegt: "In dit script kunnen acteur A en acteur B op hetzelfde moment op het podium staan. Dat is gevaar!"
De nieuwe controleur (MaskedHLSVerif) kijkt naar de regisseur (de FSM - Finite State Machine). De regisseur houdt een strikte tijdlijn bij.
- Stap 1: Alleen acteur A is op het podium. De deur naar B is dicht. Alles is veilig.
- Stap 2: Acteur A is weg, nu is alleen B op het podium. De deur naar A is dicht. Alles is veilig.

De nieuwe tool splitst de chip op in deze kleine "stappen" (states). Ze controleren elke stap apart. Ze weten precies welke deur op dat moment open is en welke dicht. Zo weten ze zeker dat ze geen valse alarmen slaan. Ze kijken alleen naar de situaties die echt kunnen gebeuren.

Wat hebben ze bewezen?

Geen Valse Alarmen meer: Ze hebben getest met zes verschillende cryptografische ontwerpen (zoals een slot die veel gebruikt wordt, genaamd PRESENT). De oude tool (REBECCA) zei bij al deze ontwerpen: "Onveilig!" (terwijl ze veilig waren). De nieuwe tool zei: "Veilig!" en had gelijk.
Het Vangt Eigenlijke Fouten: Soms maakt de AI-bouwer (HLS) écht een fout. Bijvoorbeeld, als de AI de volgorde van het recept verandert om tijd te besparen. De nieuwe tool zag dit ook! Ze vonden een fout in een ontwerp waar de AI de volgorde van de berekening had omgedraaid, waardoor het geheim toch kon lekken. De oude tool zou dit misschien gemist hebben of weer een valse alarm hebben gegeven.

Conclusie in Eén Zin

Dit paper introduceert een slimme nieuwe manier om te controleren of computerchips, die automatisch door AI zijn gebouwd om geheime data te beschermen, echt veilig zijn. Ze doen dit door niet naar het hele gebouw te kijken, maar door de bouwstap voor bouwstap te controleren, zodat ze weten welke deuren op welk moment echt open kunnen staan. Hierdoor stoppen ze met het geven van valse alarmen en kunnen ze echte lekken vinden.

Titel

Controller–Datapath Aware Verification of Masked Hardware Generated via High-Level Synthesis
(Verificatie van gemaskerde hardware gegenereerd via High-Level Synthesis, bewust van controller en datapad)

1. Het Probleem

Cryptografische algoritmen in embedded systemen zijn kwetsbaar voor Power Side-Channel Attacks (PSCA), waarbij aanvallers geheime sleutels extraheren uit het stroomverbruik. Een veelgebruikte tegenmaatregel is maskering, waarbij geheime data wordt opgesplitst in willekeurige delen (shares).

Huidige uitdaging: Het handmatig ontwerpen van gemaskerde hardware is tijdrovend en foutgevoelig. Daarom wordt er steeds vaker gebruikgemaakt van High-Level Synthesis (HLS) om automatisch gemaskerde Register-Transfer Level (RTL) hardware te genereren vanuit geverifieerde software.
Het veiligheidsrisico: HLS-tools zijn ontworpen voor functionaliteit en optimalisatie (oppervlakte/latentie), niet voor beveiliging. HLS-optimalisaties (zoals resource sharing, re-associatie en expression balancing) kunnen onbedoeld kwetsbaarheden introduceren die maskering omzeilen.
De beperking van bestaande tools: Bestaande formele verificatietools (zoals REBECCA) gaan er vaak vanuit dat alle syntactisch mogelijke datapad-paden actief kunnen zijn. Bij HLS-gegenereerd ontwerp wordt echter vaak gebruikgemaakt van een Finite State Machine (FSM) en resource sharing (tijdgedeelde multiplexing). Hierdoor worden bepaalde combinaties van invoer nooit daadwerkelijk uitgevoerd.
- Bestaande tools controleren echter alle theoretisch mogelijke combinaties, inclusief die welke nooit voorkomen. Dit leidt tot false positives (onterechte waarschuwingen voor lekken), waardoor het onmogelijk is om te bepalen of een HLS-ontwerp daadwerkelijk veilig is of niet.

2. Methodologie: MaskedHLSVerif

De auteurs stellen een nieuwe verificatiestroom voor, genaamd MaskedHLSVerif, die specifiek is ontworpen om de beperkingen van bestaande tools bij HLS-ontwerpen te overwinnen. De kern van de methode is state-wise verificatie (verificatie per toestand).

De stappen in de workflow:

Ontleding van het ontwerp: Het volledige RTL-ontwerp (gegenereerd door HLS) wordt opgesplitst in kleinere, onafhankelijke sub-ontwerpen, één voor elke toestand van de FSM.
Behoud van afhankelijkheden: Voor elke staat $S_x$ wordt een sub-ontwerp $D_x$ gemaakt. Cruciaal hierbij is dat $D_x$ niet alleen de operaties van die specifieke staat bevat, maar ook alle recursief afhankelijke operaties uit voorgaande staten. Dit is noodzakelijk om de labels (shares, masks, public values) correct te kunnen doorgeven en te verifiëren.
Labeling: De invoersignalen van elk sub-ontwerp worden gelabeld op basis van de oorspronkelijke invoer van het totale ontwerp (Shares, Masks, Public).
Formele verificatie: Elk sub-ontwerp $D_x$ wordt individueel ingevoerd in de bestaande verificatietool REBECCA. Omdat REBECCA nu slechts de actieve datapad voor een specifieke staat ziet, worden er geen onbereikbare combinaties gecontroleerd.
Samenvoeging van resultaten: Als alle sub-ontwerpen veilig zijn, is het totale ontwerp veilig. Als een sub-ontwerp faalt, wordt de fout gelokaliseerd in die specifieke staat en de oorzaak (afhankelijkheid of onafhankelijke fout) geanalyseerd.

Theoretische onderbouwing:
De auteurs bewijzen de soundness (betrouwbaarheid) van hun methode via twee lemma's:

De state-wise splitsing vangt elke mogelijke uitvoeringstrace van het originele ontwerp.
Als REBECCA sound is voor vaste datapaden, dan is MaskedHLSVerif sound voor HLS-gegenereerde ontwerpen.

3. Belangrijkste Bijdragen

Identificatie van beperkingen: Het paper toont aan dat State-of-the-Art (SOTA) tools zoals REBECCA falen bij HLS-ontwerpen vanwege hun onvermogen om rekening te houden met FSM-gestuurde resource sharing, wat leidt tot false positives.
Impactanalyse: Het document analyseert hoe specifieke HLS-optimalisaties (zoals re-associatie en expression balancing in de front-end, en resource binding in de back-end) de beveiliging van maskering kunnen ondermijnen.
Nieuwe Toolflow (MaskedHLSVerif): Een geautomatiseerde flow die bestaande verificatietools hergebruikt door deze te combineren met een state-aware abstractie van het datapad.
Detectie van HLS-geïnduceerde fouten: De tool is niet alleen in staat om false positives te elimineren, maar ook om echte beveiligingsfouten te detecteren die door HLS-optimalisaties zijn veroorzaakt.

4. Resultaten

De auteurs hebben hun methode getest op zes cryptografische benchmarks, gegenereerd met de Vitis HLS tool:

Benchmarks: Gekaskadeerde gemaskerde multipliers (DOM, COMAR, HPC1, HPC2) en de PRESENT S-box (gemaskerd met DOM en HPC1).
Experiment 1 (Validatie van bestaande ontwerpen):
- Bestaande tools (REBECCA) rapporteerden false positives voor alle zes de HLS-gegenereerde ontwerpen (ze vonden lekken die er niet waren).
- MaskedHLSVerif verifieerde alle ontwerpen correct als veilig.
- De resultaten werden bevestigd via TVLA (Test Vector Leakage Assessment) met Synopsys PrimeTime, wat aantoont dat de hardware inderdaad veilig is en dat de eerdere waarschuwingen van REBECCA onterecht waren.
Experiment 2 (Detectie van fouten):
- De auteurs activeerden een agressieve optimalisatie (expression balancing) in de HLS-tool, wat leidde tot een re-associatie van operaties.
- Dit veroorzaakte een echte beveiligingsfout (een lek van een eerste orde).
- MaskedHLSVerif detecteerde deze fout correct in de tweede staat van het ontwerp, terwijl de fout door de optimalisatie was geïntroduceerd.

5. Significantie

Dit paper is een mijlpaal in het veld van side-channel beveiliging en hardware-ontwerp:

Eerste werk van zijn soort: Het is de eerste studie die zich specifiek richt op de formele verificatie van gemaskerde hardware die gegenereerd is via High-Level Synthesis.
Oplossing voor een kritiek probleem: Het lost het probleem van false positives op bij het verifiëren van resource-gedeelde ontwerpen, wat essentieel is voor het vertrouwen in geautomatiseerde ontwerpprocessen.
Ontwerpcyclus: Het stelt ontwerpers in staat om veilig gebruik te maken van HLS voor cryptografie, wat de ontwerptijd verkort en Design-Space Exploration (DSE) mogelijk maakt zonder in te leveren op beveiliging.
Toekomstperspectief: Het onderstreept dat HLS-optimalisaties een onbekend risico vormen voor PSCA-beveiliging en biedt een instrument om deze risico's actief te monitoren.

Kortom, MaskedHLSVerif maakt het mogelijk om de voordelen van geautomatiseerd hardware-ontwerp (HLS) te combineren met strikte beveiligingsgaranties, door de beperkingen van bestaande verificatietools te omzeilen via een slimme, toestand-gebaseerde aanpak.