Goedkope bescherming van intellectuele eigendom in FPGA-configuraties

Goedkope bescherming van intellectuele eigendom in FPGA-configuraties Alexander Prinsier

Thesis voorgedragen tot het behalen van de graad van Master in de ingenieurswetenschappen: elektrotechniek, optie Telecommunicatie en telematica Promotor: Prof. dr. ir. Ingrid Verbauwhede Assessoren: Prof. dr. ir. Bart Preneel Prof. dr. ir. Rudy Lauwereins Begeleiders: Ir. Roel Maes Ir. Dries Schellekens

Academiejaar 2009 – 2010

c Copyright K.U.Leuven

Zonder voorafgaande schriftelĳke toestemming van zowel de promotor(en) als de auteur(s) is overnemen, kopiëren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Voor aanvragen tot of informatie i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uit deze publicatie, wend u tot ESAT, Kasteelpark Arenberg 10 postbus 2440, B-3001 Heverlee, +32-16-321130 of via e-mail [email protected]. Voorafgaande schriftelĳke toestemming van de promotor(en) is eveneens vereist voor het aanwenden van de in deze masterproef beschreven (originele) methoden, producten, schakelingen en programma’s voor industrieel of commercieel nut en voor de inzending van deze publicatie ter deelname aan wetenschappelĳke prĳzen of wedstrĳden.

Voorwoord Deze thesis is het resultaat van een jaar lange inspanning die enkel mogelĳk is geweest met de hulp van een heleboel mensen. In dit voorwoord wil ik hen hier speciaal voor bedanken. In eerste plaats denk ik hierbĳ aan mĳn begeleiders Roel Maes en Dries Schellekens, die mĳn werk het hele jaar hebben opgevolgd. Hun expertise in het domein heeft mĳ kritisch doen nadenken over alle aspecten van deze verhandeling. Al onze bĳeenkomsten waren zeer leerrĳk en gaven me de motivatie om verder te gaan. Ik dank hen ook voor hun hulp bĳ alle praktische problemen onderweg en voor het nalezen van dit werk. Ik wil ook mĳn promotor, professor Verbauwhede, bedanken om deze thesis mogelĳk te maken alsook alle andere leden uit mĳn jury, professor Preneel en professor Lauwereins, voor de tĳd die ze steken in het beoordelen van mĳn thesis. A special thank you goes to Junfeng Fan for his help with the implementation of the Hamsi hashfunction in my design. Ik sluit af met de mensen te bedanken die me het langste gesteund hebben. Mĳn vrienden, die na al het harde werk voor leuke tĳden hebben gezorgd, mĳn ouders, die mĳn studies mogelĳk gemaakt hebben, en mĳn vriendin Annelies, voor haar onvoorwaardelĳke liefde, ook tĳdens deze drukke periode bĳ het schrĳven van dit eindwerk. Alexander Prinsier

i

Inhoudsopgave Voorwoord

i

Samenvatting

iii

Lĳst van figuren en tabellen

iv

Lĳst van afkortingen en symbolen

vi

1 Inleiding 1.1 Intellectuele eigendom . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Eerder werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Doel van deze thesis . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 7 13

2 Overzicht 2.1 Field Programmable Gate Arrays 2.2 Hardwareontwerpmethodiek . . . 2.3 Ontwerpsoftware voor FPGA . . 2.4 Bestaande componenten . . . . .

. . . .

17 17 24 26 26

3 Ontwerp 3.1 Doelstellingen en veronderstellingen . . . . . . . . . . . . . . . . . . 3.2 Gebruikte primitieven . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 29 30 31

4 Implementatie 4.1 Hashfunctie . . . . . . . . . . . . 4.2 Geobfusceerde hash-ROM . . . . 4.3 Geobfusceerde programma-ROM 4.4 Totale implementatiekost . . . .

. . . .

35 35 35 38 42

5 Veiligheidsanalyse 5.1 Veiligheid van de hash-ROM . . . . . . . . . . . . . . . . . . . . . . 5.2 Veiligheid van de programma-ROM . . . . . . . . . . . . . . . . . . .

45 45 52

6 Besluit en vervolgwerk

59

Bibliografie

61

ii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Samenvatting Moore voorspelde reeds in 1965 dat de complexiteit van chips iedere twee jaar zou verdubbelen. Tot op heden blĳkt zĳn voorspelling te kloppen. Door het groot aantal componenten dat men tegenwoordig op een chip kan plaatsen is er een grote diversiteit aan toepassingen mogelĳk geworden. De evolutie van chips heeft er niet alleen voor gezorgd dat er veel nieuwe toepassingen mogelĳk zĳn geworden maar ook dat het ontwikkelen van nieuwe toepassingen veel sneller kan gebeuren. Configureerbare chips, kortweg FPGA’s, hebben hier deels voor gezorgd. FPGA’s zorgen ervoor dat het bouwen van prototypes op een fractie van de tĳd kan gebeuren dan wanneer men een eigen chip moest laten produceren. Door de configureerbare aard van FPGA’s introduceren zĳ wel een nieuw probleem. Het is eenvoudig een hardwareontwerp, dat gemaakt werd voor een FPGA, te kopiëren en opnieuw te gebruiken. Dit is catastrofaal wanneer een hardwareontwerp, waar jarenlang aan werd gewerkt, gekopieerd wordt door een concurrent om in zĳn producten gebruikt te worden. Bestaande commerciële en recente wetenschappelĳke ontwikkelingen hebben gemeen dat hun oplossingen voor dit probleem omslachtig in gebruik zĳn of duur zĳn om te implementeren. In dit werk bouwen we voort op recente wetenschappelĳke ontwikkelingen en ontwerpen we een goedkope, eenvoudig te gebruiken, kopieerbeveiliging voor FPGA-hardwareontwerpen.

iii

Lĳst van figuren en tabellen Lĳst van figuren 1.1 1.2

2.1 2.2 2.3 2.4 2.5 2.6 3.1

4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4

5.5

iv

Met een invasieve aanval kan men achterhalen of een opslaat . . . . . . . . . . . . . . . . . . . . . . . . . . Identificatie Friend of Foe, met Dallas Semiconductor IFF Copy Protection [33] . . . . . . . . . . . . . . .

fuse een 0 of een 1 . . . . . . . . . . . DS2432, uit Xilinx . . . . . . . . . . .

Slices en CLB’s in een Xilinx FPGA met aanduiding van de logica [32] . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architectuur van één FPGA slice van de Virtex-5 serie [32] De eerste commando’s uit een Xilinx bitstream [31] . . . . . De configuratiecommando’s om frames te schrĳven [31] . . . Een screenshot van het ISE programma . . . . . . . . . . . Een screenshot van het FPGA Editor programma . . . . . .

9 10

carry-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18 19 21 21 27 28

Overzicht van de IP-beveiligingsarchitectuur. De pĳlen stellen de informatiestroom voor. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

Schema van de geobfusceerde hash-ROM . . . . . . . . . . . . . . . . . . Een voorbeeld van een FPGA Editor script dat de INIT-waarde van de 4 FF’s in de slice met naam rom_data<3> aanpast . . . . . . . . . . . . Schema van geobfusceerde programma-ROM + microcontroller . . . . . Detailschema van de geobfusceerde programma-ROM . . . . . . . . . . Het belangrĳkste stuk code van de scrambler, ingebouwd in picoasm . . Verduidelĳking van het beperkt aantal mogelĳke permutaties bĳ de hash-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verduidelĳking over de opdeling van de bits van de hashwaarde . . . . . Overzicht van de beveiligingsarchitectuur. De permutatie gebeurt nu op de data die gehasht wordt. . . . . . . . . . . . . . . . . . . . . . . . . . . Diffusie in het programmageheugen, weergegeven door de maximale afwĳking ten opzichte van een kans van 50% voor het wĳzigen van de uitgangsbits bĳ wĳziging van slechts 1 ingangsbit . . . . . . . . . . . . . Confusie in het programmageheugen, weergegeven door de maximale afwĳking ten opzichte van een kans van 50% voor het wĳzigen van de uitgangsbits bĳ verwisseling van twee elementen van de permutatie . . .

37 39 40 41 43

49 51 53

55

56

Lĳst van figuren en tabellen 5.6 5.7

Vereenvoudigde voorstelling voor het vergelĳken van de hashwaarden . . Verbeterde methode voor het activatiesignaal . . . . . . . . . . . . . . .

56 57

Lĳst van tabellen 4.1 4.2 4.3

Oppervlakte implementatiekost van de IP-beveiligingsarchitectuur . . . CPU-tĳd implementatiekost van de IP-beveiligingsarchitectuur . . . . . Totale implementatiekost van de IP-beveiligingsarchitectuur . . . . . . .

44 44 44

v

Lĳst van afkortingen en symbolen Afkortingen

ASIC CLB CRC FIB FF FPGA FSM HDL ICAP IOB IP IP-eigenaar MUX NRE LUT PCB PUF ROM SPN SRAM VHDL vi

Application-specific Integrated Circuit Configurable Logic Block Cyclic Redundancy Check Focused Ion Beam Flip-flop Field Programmable Gate Array Finite State Machine Hardware Descripion Language Internal Configuration Access Port Input/Output Buffer Intellectual Property (intellectuele eigendom), zoals een chipontwerp Eigenaar van de intellectuele eigendom, typisch de circuitontwerper Multiplexer Non-Recurring Engineering Lookup Table Printed Circuit Board Physical Unclonable Function Read-only Memory Substitutie-permutatienetwerk Static Random Access Memory Very-high-speed Integrated Circuit Hardware Description Language

Lĳst van afkortingen en symbolen

Symbolen Cp BCp Cq BCq H Hk

Hj C IDF 1 || Hamm(x) x! P P −1 Wk Wl W A

Het ontwerp waarvan de integriteit dient beschermd te worden en dat beschermd dient te worden tegen kopieën De bitstream-voorstelling van Cp De IP-beveiligingsarchitectuur die Cp beschermt De bitstream-voorstelling van Cq Een hashwaarde De hashwaarde van de bitstreamvoorstelling van de beveiligingsarchitectuur, het te beschermen ontwerp, en een unieke identificatie van de FPGA De door de initialisatiecontroller berekende hashwaarde Het volledige ontwerp: Cp , Cq en Hk samen De unieke identificatie van FPGA 1 De concatenatie-operator Het Hamminggewicht van x x faculteit Een permutatie De inverse permutatie van P De inhoud van de FF’s in de hash-ROM die ervoor zorgen dat de hashwaarde Hk aan de uitgang wordt gegeven De inhoud van de FF’s die een aanvaller zou moeten programmeren in de hash-ROM om de hashwaarde Hl aan de uitgang te krĳgen De inhoud van de FF’s van de hash-ROM, zonder een specifieke waarde te specifiëren Het gemiddeld aantal pogingen die een aanvaller moet ondernemen om een beveiliging te breken

vii

Hoofdstuk 1

Inleiding We beginnen met een overzicht over de bescherming van intellectuele eigendom en het belang hiervan in onze economie. Vervolgens zullen we hier dieper op in gaan en dit kaderen in de bescherming van elektronische circuits. De noodzaak aan adequate beveiliging van elektronische circuits zal duidelĳk gemaakt worden. Vervolgens zullen we een overzicht geven van reeds bestaande commerciële, maar ook zeer recente academische beveiligingstechnieken voor elektronische circuits. We analyseren deze kritisch en bespreken hun voor- en nadelen. Ten slotte stellen we ons als doel een nieuwe beveiligingstechniek uit te werken waarvan het ontwerp, de implementatie en zĳn veiligheid uitgebreid aan bod komen in de volgende hoofdstukken.

1.1

Intellectuele eigendom

Intellectuele eigendom kan beschreven worden als producten van het menselĳke brein die in de wetgeving speciaal beschermd worden. Deze wettelĳke beschermingsmaatregelen bestaan onder andere uit het auteursrecht, patentrecht en kenmerkenrecht. Dit wettelĳk kader heeft tot doel de innovatie in allerlei domeinen te stimuleren. Doordat de auteur van een boek beschermd wordt door het auteursrecht, is hĳ in staat hier een volwaardig inkomen uit te halen. Dit zou niet mogelĳk zĳn moest het legaal zĳn om deze boeken te kopiëren en opnieuw te verkopen aan een lagere prĳs. Het Statute of Anne uit 1709 wordt geacht de oorsprong te zĳn van het moderne auteursrecht [22]. Deze wettekst werd in die tĳd niet alleen ingevoerd ter bescherming van auteurs maar ook om geleerden aan te moedigen hun wĳsheid neer te schrĳven, en om vooruitgang in het onderwĳs te bekomen [6]. Het auteursrecht dient veel breder opgevat te worden dan louter bĳ het schrĳven van boeken. Foto’s, kunstwerken en wenskaarten vallen bĳvoorbeeld ook onder het auteursrecht. We zullen de term auteur in het vervolg ook gebruiken voor fotografen, kunstenaars, enzovoort, kortom iedereen die een persoonlĳke intellectuele invulling geeft aan een idee. Het is belangrĳk te weten dat het auteursrecht enkel de manier beschermt waarop iets gemaakt wordt - bĳvoorbeeld de zinsconstructie - en niet het idee, dat waarover men schrĳft. Om ideeën te beschermen wordt beroep gedaan op het 1

1. Inleiding patentrecht. Het patentrecht had initieel ook als doel innovatie te stimuleren. Patenten laten toe een idee te beschermen zodat de uitvinder van een gepatenteerd idee gedurende een periode het exclusieve recht krĳgt om producten te commercialiseren op basis van dit idee. Patenten zorgen ervoor dat investeringen in onderzoek zich kunnen terugbetalen met de opbrengsten van producten die op deze nieuwe ideeën gebaseerd zĳn. De derde categorie binnen intellectuele eigendom is het kenmerkenrecht. Het kenmerkenrecht is iets helemaal anders dan het auteursrecht en het patentenrecht, in de zin dat het geen producten beschermt van het menselĳke brein. Het beschermt de mensen door een wettelĳk kader te creëren dat toelaat de oorsprong van producten duidelĳk te maken. Het kenmerkenrecht verbiedt immers producten op de markt te brengen onder iemand anders zĳn naam, indien deze geregistreerd werd als een kenmerk. Het is niet alleen noodzakelĳk een wettelĳk kader te voorzien waarin auteurs en uitvinders beschermd worden, het is ook noodzakelĳk dat de overheid de naleving van deze wetten opvolgt. Zonder goede opvolging zal dit leiden tot productie van namaakgoederen die de auteurs en uitvinders erg veel kosten. Denk bĳvoorbeeld aan het illegaal kopiëren van boeken, het verspreiden van commerciële muziek en software over het internet, en de productie van namaakkledĳ.

1.1.1

Bescherming van intellectuele eigendom bĳ hardware

Hardwareontwerpen vallen eveneens onder het auteursrecht. De ontwerper heeft immers een persoonlĳke intellectuele invulling gegeven om een bepaald idee, bĳvoorbeeld een hardwarevermenigvuldiger, te realiseren. Vaak zĳn deze ideeën ook gepatenteerd. Voor hardwareontwerpen is er ook een aparte Europese wetgeving, "Legal Protection of Topographies of semiconductor products"[11], en Amerikaanse wetgeving, "Semiconductor Chip Protection Act"[26]. Meestal gaan hardwareontwerpen gepaard met een zeer hoge initiële investering. Aan recente chips bĳvoorbeeld werkt men typisch verschillende maanden tot jaren in een team van verschillende personen. Louter het ontwerpen alleen van een dergelĳke chip kost meerdere manmaanden. Na het ontwerp dient de chip ook nog geproduceerd te worden. Wanneer het gaat om een Application-specific Integrated Circuit (ASIC), dan kost het typisch nogmaals verschillende miljoenen euro om de productie op te starten. Deze vaste kosten waarin het onderzoek, ontwerpen en testen van een ontwerp vervat zitten heet de Non Recurring Engineering (NRE) kost. Hardwareontwerpers willen vermĳden dat iemand anders een kopie kan maken van hun werk waar miljoenen euro in gekropen zĳn. Zĳ willen vermĳden dat hun ontwerpen gebruikt kunnen worden voor massaproductie van een concurrerend product waarbĳ de concurrent geen of een zeer beperkte NRE-kost heeft gehad. We beperken ons tot hardwareontwerpen op chip aangezien deze ontwerpen veel uitgebreider zĳn en meer kosten dan ontwerpen gebaseerd op individuele componenten. Wanneer men een ontwerp kopieert, zal de kopie normaalgezien van dezelfde kwaliteit zĳn als het origineel. Dit in tegenstelling tot bĳvoorbeeld namaakkledĳ 2

Intellectuele eigendom die typisch van verminderde kwaliteit is. Het kopiëren van een chipontwerp is daarom een zeer interessante manier om de zeer hoge NRE-kost te vermĳden en toch een kwaliteitsvol product op de markt te kunnen brengen. Deze namaakhardware zorgt voor een groot verlies aan inkomsten bĳ de ontwerpers. Er wordt geschat dat namaaktechnologieproducten in de Verenigde Staten alleen al een jaarlĳks verlies van 40 miljard USD veroorzaken [28]. We kunnen twee verschillende doelen onderscheiden voor iemand die intellectuele eigendom probeert te bemachtigen van een ontwerp: • Men wilt leren uit dit ontwerp en deze informatie gebruiken om een eigen product te maken op basis van deze informatie. Dit is meestal wettelĳk toegestaan wanneer men dit doet met als doel het maken van compatibele interfaces. • Men wilt exact hetzelfde ontwerp produceren en al dan niet onder dezelfde merknaam verkopen. Het is echter niet eenvoudig om de nodige technische informatie te bemachtigen over de chipontwerpen van een bepaald product. Wanneer men enkel beschikt over het eindproduct waarin deze chip wordt gebruikt, dan zou men invasieve technieken moeten gebruiken om te achterhalen hoe deze chip precies werkt. Invasieve aanvallen verwĳderen eerst het omhulsel van de chip en de passivatielaag die de metaalverbinden beschermt tegen oxidatie. Hiervoor kunnen chemicaliën gebruikt worden of een laser wanneer meer precisie vereist is. Vervolgens kan men van iedere laag van de chip een foto nemen. Na iedere foto etst men telkens een laag weg om een foto te kunnen nemen van de volgende laag. Geavanceerdere apparatuur zoals een Focused Ion Beam (FIB) kan gebruikt worden om verbindingen op nanometerschaal te vormen of te doorbreken of om foto’s van hoge resolutie te nemen. Met al deze foto’s heeft men zĳn doel nog niet bereikt. Om de werking van het circuit te analyseren, dienen deze foto’s met elkaar in verband gebracht te worden om zo te bepalen welke transistor verbonden is met welke andere transistor. Op deze manier kan een circuitbeschrĳving achterhaald worden. Manueel is dit werk slechts voor een zeer beperkt aantal transistoren en verbindingen doenbaar, maar recente ontwikkelingen maken het mogelĳk dit proces gedeeltelĳk te automatiseren [26]. Er bestaan technieken om invasieve aanvallen moeilĳker te maken maar hun effectiviteit is niet altĳd gegarandeerd. Physical Unclonable Functions (PUF’s) zouden hier een doorbraak kunnen maken, zie sectie 1.2.2 voor meer informatie over PUF’s. Invasieve aanvallen maken het mogelĳk de werking van een chip te achterhalen, maar deze aanvallen maken gebruik van uiterst dure apparatuur, vereisen de inzet van specialisten, en kosten zeer veel tĳd om uit te voeren. Wanneer men toegang zou hebben tot de computers van de ontwerpers van deze chips dan hoeft men niet over te gaan tot invasieve aanvallen. Wanneer men de originele circuitbeschrĳvingen heeft, kan men deze circuits zonder verdere moeilĳkheden opnieuw gebruiken in andere producten. Het is daarom zeer belangrĳk om deze originele circuitbeschrĳvingen zeer goed te beveiligen. 3

1. Inleiding

1.1.2

Beveiliging is een economisch begrip

Wanneer men overweegt iets te beveiligen, moet men weten waartegen men zich precies wilt verdedigen. Wie zĳn de tegenstanders, wat zĳn hun middelen, en hoe lang moet de informatie beveiligd zĳn, is vereiste informatie bĳ het bepalen van de gepaste beveilingsstrategie. Wanneer men zich wilt beveiligen tegen een concurrerende firma die de eigen producten zou willen namaken en op de markt brengen, is het voldoende om het breken van de beveiliging even duur te maken dan de NRE-kost, of om ervoor te zorgen dat het breken van de beveiliging meer tĳd in beslag zou nemen dan de economische levensduur van het product. Aangezien de economische levensduur van bepaalde commerciële producten slechts enkele maanden tot jaren is, kan de beveiliging vaak relatief goedkoop uitgevoerd worden. Militaire technologie en staatsgeheimen dienen echter veel langer beschermd te worden, vaak verschillende decennia. Men kan in deze context geen goedkope beveiliging gebruiken waarvan de kans bestaat dat deze binnen enkele jaren gebroken zal worden. Dit soort beveiliging is enkel interessant voor commerciële toepassingen. Wanneer het gaat over staatsgeheimen zĳn het vaak andere overheden die deze informatie willen bemachtigen en deze zĳn veel kapitaalkrachtiger dan een commercieel bedrĳf. Voor sommige overheden is het geen probleem om complexe invasieve aanvallen uit te voeren op een chip terwĳl dit voor een commercieel bedrĳf meestal te duur is. Ook bĳ tal van andere toepassingen is een beveiliging waarop men een lange tĳd kan betrouwen belangrĳk, zoals in de banksector. Wanneer we trachten te analyseren tegen wie we ons allemaal dienen te beveiligen bĳ het ontwerpen van hardware, komen we reeds snel tot de conclusie dat dit een zeer complex probleem is. Men onderscheidt de ontwerper van de hardware, de foundry waar men de chips produceert, de systeemontwerper die de chip gebruikt als onderdeel van een (commercieel) product, ontwerpers van circuits die kleinere specifieke onderdelen van een ontwerp maken in opdracht van de systeemontwerper, de fabrikant van de ontwerpsoftware, en tenslotte de systeemeigenaar, die eindgebruiker is van het product. Ieder van deze entiteiten is op de één of andere manier in staat om schade te berokkenen aan de eigenaars van de intellectuele eigendom. Dit zĳn de ontwerpers en de systeemontwerper. De fabrikant van de ontwerpsoftware zou bĳvoorbeeld bĳ ieder gebruik een kopie van het ontwerp naar een bepaald emailadres kunnen doorzenden. De systeemfabrikant zou méér oplages kunnen produceren dan gevraagd en het overschot op de zwarte markt verkopen. Het is belangrĳk de nodige veiligheidsmaatregelen te nemen omdat de IP-eigenaars anders riskeren dat hun investering niets meer zal opleveren. Beveiligingsmaatregelen kunnen ingedeeld worden in 3 groepen [8]: • Sociale maatregelen zoals licentieovereenkomsten, auteursrechten en patentrechten zĳn erop gebaseerd dat mensen trachten te vermĳden gerechtelĳk vervolgd te worden. Deze maatregelen werken enkel wanneer er een goed wettelĳk kader bestaat en waar het naleven van deze wetten ook gecontroleerd wordt. Deze maatregelen zĳn typisch niet erg effectief in landen waar veel namaak wordt 4

Intellectuele eigendom geproduceerd. • Actieve maatregelen bestaan uit cryptografische en fysische systemen die het kopiëren of aanpassen van ontwerpen moeilĳk maken. • Reactieve maatregelen zorgen voor bewĳs van misbruik wanneer een circuit gekopieerd wordt of op een ongewenste manier aangepast wordt. Reactieve maatregelen zĳn vooral nuttig wanneer ze gecombineerd worden met sociale maatregelen. Op deze manier kunnen zĳ bewĳs leveren in een rechtszaak en worden mogelĳke aanvallers afgeschrikt. Dit kan vergeleken worden met een bewakingssysteem voor het beveiligen van een gebouw. De voordeur wordt er niet steviger op, maar de camera’s en sirenes schrikken de inbrekers wel af. Voor hardware kan dit gerealiseerd worden met watermarking technieken.

1.1.3

Bescherming van intellectuele eigendom bĳ FPGA’s

De bescherming van hardware wordt een heel ander verhaal voor een specifieke categorie van chips, namelĳk Field Programmable Gate Arrays (FPGA’s). FPGA’s zĳn configureerbare chips, dit wil zeggen dat de logische functionaliteit van deze chips op voorhand geconfigureerd dient te worden. FPGA’s bestaan uit een groot aantal identieke bouwblokken, namelĳk geheugenelementen, logische schakelingen, schakelmatrices, en ingangs- en uitgangsbuffers. Bĳ de configuratie van de chip wordt vastgelegd hoe ieder van deze elementen zich dient te gedragen en hoe ze met elkaar verbonden worden. De inhoud van geheugenelementen wordt vastgelegd, de logische schakelingen worden geconfigureerd om een bepaalde logische functie te realiseren, met de schakelmatrices worden verbindingen gemaakt tussen verschillende componenten, en met de ingangs- en uitgangsbuffers worden externe signalen beschikbaar gemaakt aan de verschillende bouwblokken. De meeste commerciële FPGA’s zĳn gebaseerd op vluchtig geheugen voor de opslag van de configuratie. Bĳgevolg moet de configuratie ook ergens extern in een niet-vluchtig geheugen bewaard worden. Bĳ het aanzetten van de FPGA zal een interne configuratiecontroller met het externe geheugen communiceren om de configuratie uit te lezen en hiermee de FPGA te configureren. Deze configuratie wordt intern in de FPGA opgeslagen in vluchtig SRAM-geheugen. Dit wil zeggen dat wanneer de spanning afgezet wordt dit configuratiegeheugen zĳn inhoud verliest. Bĳ het onder spanning zetten zal de configuratiecontroller opnieuw het externe geheugen uitlezen en de FPGA configureren. FPGA’s zĳn de laatste jaren zeer populair geworden omwille van verschillende redenen: • Men kan FPGA’s gebruiken voor ontwerpen waarvan men slechts een klein aantal exemplaren verwacht te produceren. Op deze manier vermĳdt men de enorme investering die noodzakelĳk is om de productie op te starten van een eigen chip, een ASIC. • FPGA’s maken het mogelĳk om zeer snel een prototype te ontwerpen omdat men het hele productieproces van ASIC’s kan overslaan. 5

1. Inleiding • Field-updates van de hardware zĳn veel eenvoudiger voor FPGA’s dan voor ASIC’s. Wanneer na het lanceren van het product op de markt nog een fout wordt gevonden in het FPGA-ontwerp, dan kan men deze nog eenvoudig en goedkoop corrigeren omdat men enkel de nieuwe configuratie van de FPGA dient te verspreiden. Men hoeft geen nieuwe chip te laten produceren.

Een nadeel van FPGA’s tegenover ASIC’s is dat ze iets trager zĳn en een hoger energieverbruik hebben. De circuits kunnen immers niet volledig geoptimaliseerd worden voor performantie en energie-efficiëntie, men moet de structuur gebruiken die de FPGA oplegt. Voor niet-vermogenkritische toepassingen vormt dit echter geen bezwaar. Voor de meeste toepassingen is de extra flexibiliteit van een FPGA belangrĳker dan de betere performantie van een ASIC. Het beveiligingsprobleem zit in het feit dat er een extern geheugen wordt gebruikt. Er moet immers een configuratiebus aanwezig zĳn tussen het externe geheugen en de FPGA. Bĳ het aanzetten van de FPGA zal over deze bus het hele ontwerp gecommuniceerd worden. Met eenvoudige technieken zoals bus snooping kan de communicatie over deze bus afgeluisterd worden. Men kan dan een identieke FPGAchip bestellen en deze op dezelfde manier configureren, met de configuratie die men heeft afgeluisterd van de configuratiebus tussen het externe geheugen en de originele FPGA. Een competente technieker kan met standaardapparatuur een dergelĳk ontwerp eenvoudig kopiëren. In tegenstelling tot ASIC’s is het voor FPGA’s dus redelĳk eenvoudig en goedkoop om ontwerpen te kopiëren en de intellectuele eigendom dat maanden tot jarenlang onderzoek heeft gekost (de NRE-kost) op die manier te bemachtigen. We moeten nog vermelden dat dit enkel mogelĳk is voor FPGA’s waarvan de configuratie in een extern geheugen opgeslagen wordt. Er bestaan ook andere FPGA’s waarbĳ de configuratie opgeslagen wordt in de chip zelf. Interne opslag kan gerealiseerd worden met anti-fuses [2]. Deze werken zoals smeltzekeringen, maar dan op micrometerschaal. Het al dan niet doorgebrand zĳn van een anti-fuse stelt een 0 of een 1 voor. De configuratie is dan wel permanent en aanpassingen aan de configuratie zĳn nadien niet meer mogelĳk. Het is ook mogelĳk een flashgeheugen in dezelfde verpakking van de FPGA-chip te herbergen. De configuratiebus zit dan intern in de verpakking van de chip en het is bĳgevolg niet meer eenvoudig deze bus af te luisteren. Een voorbeeld van een dergelĳke FPGA is de Xilinx Spartan-3AN [30]. Bĳ de Spartan-3AN is het waarschĳnlĳk wel nog mogelĳk de configuratie terug uit te lezen via de JTAG-poort. Deze technieken bieden een oplossing tegen het bus-snooping probleem, maar wel tegen een meerkost. Het incorporeren van niet-vluchtig geheugen in CMOStechnologie vereist extra stappen bĳ het produceren van de FPGA-chip. Een uitgebreide studie van technieken om FPGA’s met extern configuratiegeheugen te beschermen zal verder in dit hoofdstuk uitgebreid aan bod komen. 6

Eerder werk

1.2

Eerder werk

We bekĳken wat de mogelĳkheden zĳn om FPGA-ontwerpen te beveiligen. Eerst zullen we de technieken analyseren die FPGA-producenten aanraden en vervolgens kĳken we naar enkele technieken die we nog niet volledig terugvinden in commerciële producten maar die wel beschreven staan in wetenschappelĳke literatuur.

1.2.1

Commerciële beveiligingstechnieken voor FPGA-ontwerpen

Er bestaan verscheidene technieken om FPGA-ontwerpen te beveiligen. Sommige technieken zĳn uitermate geschikt om reverse-engineering tegen te gaan. Onder reverse-engineering verstaan we het achterhalen van de werking van een circuit zonder medewerking van de originele ontwerpers. Andere technieken zĳn eerder geschikt als kopieerbeveiliging. Sommigen kunnen ongewilde wĳzigingen detecteren aan het ontwerp, anderen niet. Ook qua kostprĳs zĳn de verschillende mogelĳkheden divers. We beperken ons vooral tot FPGA’s die vluchtig SRAM-geheugen gebruiken voor de opslag van hun configuratie. Aangezien de inhoud van een vluchtig geheugen verdwĳnt wanneer de spanning wordt afgezet, dient de configuratie van de FPGA uit een extern geheugen te komen wanneer hĳ wordt opgestart. We beperken ons tevens tot actieve maatregelen voor de beveiliging van FPGA-ontwerpen. Deze maatregelen worden in de praktĳk vaak gecombineerd met sociale en reactieve maatregelen. Bitstreamencryptie Bitstreamencryptie is een techniek die origineel bedoeld was om reverse-engineering van een ontwerp tegen te gaan maar die nu ook gebruikt wordt als een kopieerbeveiliging. Bĳ bitstreamencryptie wordt een sleutel geprogrammeerd in de FPGA en wordt de configuratiedata met dezelfde sleutel vercĳferd. Bĳ het inladen van het ontwerp vanuit het externe geheugen zal de FPGA deze bitstream eerst via de nodige decryptiehardware sturen vooraleer de FPGA werkelĳk geconfigureerd wordt. Wanneer iemand een bitstream die vercĳferd is voor een bepaalde FPGA probeert te laden op een andere FPGA dan zal de ontcĳfering niet slagen en zal de tweede FPGA niet in staat zĳn dit ontwerp te laden. Op deze manier werkt bitstreamencryptie dus als een kopieerbeveiliging. Het is belangrĳk in te zien dat de geheime sleutel, die de FPGA nodig heeft om het ontwerp te ontcĳferen, ergens veilig opgeslagen moet zĳn in de buurt van de FPGA. Indien een aanvaller deze digitale sleutel kan bemachtigen is hĳ in staat het ontwerp zelf te ontcĳferen en kan hĳ het ontwerp ook programmeren op andere FPGA’s. Het is dus voldoende dat één iemand één van de sleutels te weten komt om de hele kopieerbeveiliging te breken. De veilige opslag van een digitale sleutel is dus cruciaal maar is echter geen eenvoudig probleem. Er bestaan twee standaard oplossingen voor sleutelopslag: • Opslag van de sleutel in vluchtig geheugen. Vluchtig geheugen moet continu voorzien worden van spanning om de inhoud van het geheugen te kunnen bewaren. Dit wordt meestal gerealiseerd met SRAM-geheugencellen die zich 7

1. Inleiding fysiek binnen de FPGA bevinden. Deze SRAM-cellen dienen echter ook van spanning voorzien te worden wanneer de FPGA niet actief is. Daarom dient men ook een batterĳ naast de FPGA te plaatsen, die alleen maar dient om het geheugen zĳn inhoud te laten bewaren. Deze techniek wordt geacht de veiligste te zĳn, aangezien het mogelĳk is op zéér snelle wĳze de inhoud van het geheugen te wissen wanneer bepaalde circuits detecteren dat een aanvaller de sleutel probeert te bemachtigen. Het nadeel is de noodzaak aan een externe batterĳ. Niet alleen vereist deze extra fysieke plaats naast de chip en moet men een extra batterĳ per chip verrekenen in de kostprĳs, maar ook moet men nu rekening houden met het falen van deze batterĳ, en het bĳgevolg verliezen van de sleutel, en ook met de kost van het vervangen van deze batterĳen. • Opslag van de sleutel in niet-vluchtig geheugen. Niet-vluchtig geheugen is geheugen dat zĳn inhoud kan bewaren zonder dat hiervoor een continue energietoevoer noodzakelĳk is. De inhoud van het geheugen blĳft dus bewaard, zelfs wanneer de FPGA inactief is. Er is dus ook geen externe batterĳ vereist. Niet-vluchtig geheugen kan op verschillende manieren geïmplementeerd worden, zoals bĳvoorbeeld met anti-fuses, flashgeheugen of met ROM-geheugen. Het nadeel aan niet-vluchtig geheugen voor sleutelopslag is dat het extra processtappen vereist bĳ de productie van een chip om dit niet-vluchtig geheugen te combineren met de huidige standaard CMOS-technologie. FPGA’s die de mogelĳkheid hebben een sleutel op te slaan in niet-vluchtig geheugen zĳn dus iets duurder dan FPGA’s zonder niet-vluchtig geheugen. Sommige fuses zĳn kwetsbaar voor invasieve aanvallen aangezien er relatief eenvoudig herkend kan worden of de fuse een 1 of een 0 opslaat, zie figuur 1.1. Ook hier moet men beseffen dat wanneer één iemand de sleutel kan bemachtigen die gebruikt werd om een ontwerp te vercĳferen dat heel de kopieerbeveiliging omzeild kan worden. Bitstreamencryptie is de standaardoplossing tegen reverse-engineering en het kopiëren van een ontwerp wanneer de beveiliging iets meer mag kosten. Wanneer geauthenticeerde encryptie gebruikt wordt, kan bitstreamencryptie ook wĳzigingen aan de bitstream detecteren. Deze mogelĳkheden zĳn vaak enkel beschikbaar op de duurdere FPGA-types. Ontwerp opslaan in een geïntegreerd flashgeheugen Wanneer de bitstream niet vercĳferd wordt, heeft een aanvaller typisch rechtstreeks toegang tot de onvercĳferde bitstream. Rechtstreekse toegang tot de onvercĳferde bitstream maakt een poging mogelĳk tot het reverse-engineeren van het ontwerp. De technieken om verschillende kopieerbeveiligingen te omzeilen vereisen ook allemaal toegang tot deze onvercĳferde bitstream. Het is daarom zeer interessant om de bitstream op te slaan in een geheugen dat zich in dezelfde verpakking bevindt als de FPGA-chip. Op die manier heeft een aanvaller geen rechtstreekse toegang tot dit 8

Eerder werk

Figuur 1.1: Met een invasieve aanval kan men achterhalen of een fuse een 0 of een 1 opslaat

geheugen en dus ook niet tot de onvercĳferde bitstream. Er moet wel voor gezorgd worden dat het onmogelĳk is het flashgeheugen extern uit te lezen. Kopieerbeveiliging op basis van een extern beveiligde EEPROM Bĳ deze techniek wordt er naast het eigenlĳke circuit nog een extra circuit op de FPGA geprogrammeerd dat louter dient om na te kĳken of het eigenlĳke circuit geactiveerd mag worden of niet. Om dit te bepalen wordt een willekeurige waarde gegenereerd en naar een zogenaamde secure processor gestuurd. Deze processor voert een hashberekening uit op deze waarde, en op een geheime sleutel die in deze processor zit, en stuurt de resulterende hashwaarde terug naar het beveiligingscircuit. Dit circuit voert identiek dezelfde berekening uit en indien beide waarden overeenkomen wordt het eigenlĳke ontwerp geactiveerd. Zie figuur 1.2 voor een schematisch overzicht. Deze techniek wordt uitgebreider beschreven in [33]. Om ervoor te zorgen dat het beveiligingscircuit dezelfde berekening kan uitvoeren op de FPGA dient de geheime sleutel die in de aparte processor zit ook ergens in het beveiligingscircuit aanwezig te zĳn. Deze sleutel moet dus op de één of andere manier in de bitstream aanwezig zĳn. Het is niet duidelĳk hoe moeilĳk het is om deze sleutel uit een bitstream te halen. Xilinx Device DNA Het Xilinx Device DNA is een uniek niet-aanpasbaar identificatienummer dat geprogrammeerd wordt in de FPGA bĳ de productie. Aangezien dit nummer uitgelezen kan worden door geprogrammeerde logica, is het mogelĳk dit nummer te gebruiken voor een kopieerbeveiliging. Men kan een geheim algoritme toepassen op dit iden9

1. Inleiding

Figuur 1.2: Identificatie Friend of Foe, met Dallas Semiconductor DS2432, uit Xilinx IFF Copy Protection [33]

tificatienummer en de resulterende waarde vergelĳken met een extern beschikbare waarde. Deze techniek wordt beschreven door Xilinx in [36]. De veiligheid van deze techniek steunt volledig op de geheimhouding van het algoritme waarmee de waarde wordt berekend die met een externe waarde wordt vergeleken. Aangezien het een geheim algoritme dient te zĳn, zou iedere producent een eigen algoritme moeten ontwerpen. Dit komt de veiligheid van het systeem meestal niet ten goede. Dit is volledig in strĳd met het principe van Kerckhoffs [15] dat stelt dat een systeem veilig moet zĳn, zelfs wanneer alle details van dit systeem publiek gekend zĳn buiten een eventuele sleutel.

1.2.2

Beveiligingstechnieken uit de wetenschappelĳke literatuur

IC-metering Roy et al. [21] hebben een techniek uitgewerkt die erop gebaseerd is dat geproduceerde chips initieel in een vergrendelde toestand kunnen gebracht worden. Om een chip te ontgrendelen dient voor iedere chip een uniek activatiesignaal gegeven te worden dat enkel door de IP-eigenaar gegenereerd kan worden. Dit laat de IP-eigenaar toe om na te gaan wie gebruik maakt van zĳn intellectuele eigendom en om te controleren dat er niet meer chips geproduceerd worden dan contractueel werd vastgelegd met de foundry, de plaats waar de chips geproduceerd worden. Deze techniek vereist de aanwezigheid van niet-vluchtig geheugen om een private en publieke sleutel in op te slaan die worden gegenereerd de eerste keer dat de chip onder spanning wordt gezet. Iedere chip zal een andere sleutel genereren zodat het activatiesignaal dat vereist is om de chip te ontgrendelen ook anders is voor iedere chip. Deze techniek laat toe te controleren welke chips specifiek, aan hand van de gegenereerde sleutel, op welke plaats gebruikt worden. Het wordt met deze techniek ook mogelĳk een andere vorm van betalingsstrategie te kiezen. Typisch wordt de IP-eigenaar een grote som betaald als licentievergoeding om in ruil zĳn ontwerp, al dan niet exclusief, te mogen gebruiken in eigen producten. Met deze techniek waarbĳ het precies aantal gebruikte chips kan gecontroleerd worden door de IP-eigenaar, is het ook mogelĳk om in de plaats van een grote éénmalige licentievergoeding een 10

Eerder werk kleine vergoeding te vragen, maar dan wel per geactiveerde chip. De productie van de chips, waarin voor een deel vergrendelde circuits aanwezig zullen zĳn, wordt typisch betaald door de systeemontwerper. Na de productie moet deze wel zeker zĳn dat de IP-eigenaar bereid zal zĳn het juiste activatiesignaal te geven om de chips te activeren. Zoniet heeft de systeemontwerper grote kosten gemaakt om chips te verkrĳgen waar hĳ niets mee kan doen. Er dient dus een vertrouwensrelatie te zĳn tussen de systeemontwerper en de IP-eigenaar, zelfs tot na de productie. Een tweede nadeel aan deze techniek is dat er gebruik wordt gemaakt van asymmetrische cryptografie, wat redelĳk veel oppervlakte in gebruik neemt op de chip, die niet meer voor iets anders kan gebruikt worden. Ook vereist deze techniek de aanwezigheid van een kleine hoeveelheid éénmalig beschrĳfbaar geheugen, wat extra kosten met zich meebrengt bĳ de productie van de chip. Deze laatste vereiste zorgt er voor dat deze techniek niet altĳd bruikbaar is voor SRAM-gebaseerde FPGA’s aangezien daar niet altĳd éénmalig beschrĳfbaar geheugen aanwezig is. Voor ASIC’s is dit echter geen bezwaar. In [17] wordt aangetoond dat deze techniek niet veilig is wanneer de foundry niet vertrouwd kan worden. Er worden ook enkele verbeteringen aan het protocol voorgesteld. Physical Unclonable Functions (PUF’s) Physical Unclonable Functions (PUF’s) gebruiken de fysische variabiliteit bĳ het produceren van een chip voor de identificatie van deze chip. Aangezien temperatuur, druk, vochtigheid, concentraties van chemische stoffen waarmee de chip behandeld wordt en de nauwkeurigheid van de apparatuur niet exact gelĳk zĳn over de hele oppervlakte van de wafers waar de chips mee geproduceerd wordt, zullen er kleine verschillen optreden van chip tot chip. Deze verschillen zĳn oorspronkelĳk ongewenst, men tracht veel exemplaren van dezelfde chip te bekomen, maar wegens deze variabiliteit van het productieproces zal één chip nooit dezelfde zĳn als een andere [27]. De propagatievertraging van een signaal van één plaats op de chip naar een andere plaats zal bĳvoorbeeld verschillend zĳn voor iedere chip, binnen een zekere marge. Door deze vertraging op te meten kan deze dienen als de identificatie van deze chip. Het is meestal mogelĳk meer dan één waarde uit een PUF te halen door bĳvoorbeeld de initiële waarden van SRAM-geheugencellen op te meten [14]. PUF’s bieden dus meestal de mogelĳkheid om gegeven een ingangswaarde X, een bĳhorende uitgangswaarde Y te produceren die afhangt van de fysische variabiliteit. De mate van onafhankelĳkheid tussen de verschillende Y-waarden, het aantal verschillende mogelĳke Y-waarden en de betrouwbaarheid van Y over bĳvoorbeeld temperatuursen spanningsvariaties zĳn de belangrĳkste parameters van een PUF. De uitgangswaarde van een PUF zal bĳ verschillende metingen niet altĳd exact hetzelfde resultaat geven. Wanneer een chip bĳvoorbeeld al enige tĳd aan het werk is, zal de chip opgewarmd zĳn waardoor de PUF beïnvloed wordt. De verschillende uitgangswaarden van de PUF zullen wel sterk gecorreleerd zĳn met elkaar. Met behulp 11

1. Inleiding van foutverbeterende codes kan men ervoor zorgen dat een PUF toch consistent dezelfde uitgangswaarde geeft op dezelfde chip [7]. Het gebruik van PUF’s voor de identificatie van een chip heeft zekere voordelen ten opzichte van standaardmethoden zoals anti-fuses [27]: • Aangezien PUF’s een combinatie gebruiken van veel fysische eigenschappen is het zeer moeilĳk deze te clonen of te simuleren. • PUF’s kunnen het bewĳs leveren wanneer iemand fysische wĳzigingen aan de chip heeft uitgevoerd, bĳvoorbeeld voor een invasieve aanval, omdat dan de fysische eigenschappen veranderen en dus ook de waarden die de PUF zal geven. Deze eigenschap van een PUF heet tamper-evidence. • De waarden die uit de PUF komen zullen automatisch vernietigd worden wanneer iemand de PUF tracht te analyseren met een fysische aanval. Deze eigenschap van een PUF heet tamper-resistance. Het is nog niet voor alle PUF’s aangetoond dat ze de laatste twee eigenschappen hebben. Het zal later duidelĳk worden dat verschillende technieken om intellectuele eigendom te beveiligen gebruik maken van PUF’s omwille van bovenstaande voordelen. Offline authenticatie voor herconfigureerbare platformen In [23] wordt beschreven hoe hardwareontwerpen beschermd kunnen worden wanneer men beschikt over een herconfigureerbaar platform zoals recente FPGA’s. Men gaat er hier vanuit dat de configuratiecontroller uitgebreid wordt met een PUF. Deze techniek werkt als volgt: • De chip bevat een PUF waarvan alle ingangs- en uitgangswaarden uitgelezen worden door de producent van de chip na productie. Door gebruik te maken van anti-fuses wordt het circuit dat deze uitlezing mogelĳk maakt uitgeschakeld. Vanaf dan is het niet meer mogelĳk deze waarden opnieuw uit te lezen. Deze waarden worden doorgestuurd naar een Trusted Third Party (TTP), een externe derde partĳ die door de systeemontwerper en de IP-eigenaar vertrouwd wordt. • De systeemontwerper wenst voor een bepaalde chip een circuit (de IP) van de IP-eigenaar te gebruiken. Hiervoor stuurt hĳ de unieke identificatie van de chip door naar de TTP. • De TTP vraagt aan de IP-eigenaar om zĳn configuratiedata te vercĳferen met als sleutel één van de uitgangswaarden van de PUF. De IP-eigenaar stuurt de vercĳferde configuratiedata naar de systeemontwerper. De TTP stuurt de ingangswaarde die hoort bĳ de gebruikte uitgangswaarde van de PUF naar de systeemontwerper. 12

Doel van deze thesis • De systeemontwerper laat de herconfigureerbare chip de vercĳferde configuratiedata inlezen. De chip bepaalt de uitgangswaarde van de PUF voor de gegeven ingangswaarde. Hiermee kan deze de vercĳferde configuratiedata ontcĳferen en de FPGA hiermee configureren. In [23] worden meer details van het protocol gegeven en wordt tevens de veiligheid van dit protocol besproken. Op dit idee wordt verdergebouwd in [14]. Daar beschrĳft men enkele verbeteringen aan het protocol zodat de TTP niet meer in staat is het vercĳferde circuit zelf te ontcĳferen, wat een nadeel is van het bovenstaande protocol. [14] beschrĳf ook een mogelĳke implementatie van een PUF gebaseerd op SRAM voor FPGA’s. Software-IP-binding voor FPGA’s Gora et al. [13] beschrĳven een techniek om software te beschermen die uitgevoerd wordt door een microprocessor die geïmplementeerd wordt op FPGA. Zĳ doen dit door de software te binden aan een specifieke FPGA. Zĳ willen voornamelĳk de confidentialiteit van de software garanderen. Om de confidentialiteit van de softwareIP te garanderen moeten ze echter ook de integriteit van het programma garanderen dat de decryptie uitvoert. Om de integriteit van dit decryptieprogramma te garanderen stellen zĳ een integriteitskernel (IK) voor die in een apart programmageheugen bewaard wordt. De IK zal de integriteit van het decryptieprogramma controleren, dat op zĳn beurt de eigenlĳke software-IP kan decryperen. Hiermee is het beveiligingsprobleem gereduceerd tot het garanderen van de integriteit van IK. Zĳ garanderen de integriteit van de IK door gebruik te maken van een geobfusceerde opslag voor het deel van het programmageheugen dat de IK bevat. De IK controleert de integriteit van de decryptiesoftware door een hashberekening uit te voeren op deze decryptiesoftware en de hashwaarde te vergelĳken met een referentiewaarde. Indien beide waarden overeenkomen, is men zeker van de integriteit van de decryptiesoftware. De geobfusceerde opslag van het programmageheugen dat de IK bewaart wordt echter niet uitgebreid besproken in hun werk. Ze vermelden alleen dat het geobfusceerde programmageheugen geïmplementeerd wordt door gebruik te maken van meerdere-lagen-logica die beschermd wordt door de obfuscatie van de bitstream. In het ontwerp dat besproken zal worden in hoofdstuk 3 zal duidelĳk worden dat wĳ een gelĳkaardige oplossing, ook op basis van een geobfusceerd programmageheugen, zullen voorstellen voor de integriteitsbescherming van een FPGA-ontwerp. Wĳ zullen echter een volledige implementatie van dit programmageheugen voorstellen en de veiligheid hiervan analyseren.

1.3

Doel van deze thesis

We hebben gezien dat er reeds verschillende mogelĳkheden bestaan om het ongewenst kopiëren van FPGA-ontwerpen tegen te gaan. De bestaande technieken zĳn 13

1. Inleiding omslachtig of veroorzaken een extra kost. Ofwel wordt extra hardware vereist (een secure processor, een batterĳ, flash geheugen in dezelfde verpakking) ofwel moet men de configuratiecontroller van de FPGA aanpassen zodat deze een PUF bevat en een fuse. Extra hardware zorgt ervoor dat het ontwerp duurder wordt. De configuratiecontroller van de FPGA kan enkel aangepast worden door de fabrikant van de FPGA en is dus geen techniek die op korte termĳn gebruikt kan worden. Wĳ stellen een IP-beveiligingstechniek voor die goedkoper en eenvoudiger te gebruiken is dan bestaande voorstellen.

1.3.1

Doelstellingen

In deze thesis ontwikkelen we een nieuwe beveiliging voor intellectuele eigendom in FPGA-ontwerpen met als voornaamste eisen dat ze eenvoudig in gebruik is, goedkoop, en onmiddellĳk bruikbaar is voor de huidige generatie van vluchtige FPGA’s. We zoeken een techniek voor commerciële doeleinden, met andere woorden we veronderstellen dat een aanvaller gelimiteerd is door zĳn budget en bĳvoorbeeld geen invasieve aanvallen zal proberen. We zullen later ook veronderstellen dat de fabrikant van de FPGA’s en de leveranciers van alle software vertrouwd worden en niet geïnteresseerd zĳn in het bemachtigen van deze intellectuele eigendom. Deze nieuwe techniek zal verhinderen dat men een ontwerp kan kopiëren en gebruiken op een andere FPGA door dit ontwerp te koppelen aan een specifieke FPGA. Wanneer het ontwerp wordt ingeladen op een andere FPGA dan waarvoor het ontwerp bedoeld was, mag het niet correct functioneren. Een bĳkomend doel is de volledige integriteit van dit ontwerp garanderen, zonder te veronderstellen dat het niet reverse-engineerbaar is. Omdat we een oplossing zoeken die onmiddellĳk bruikbaar is voor de huidige generatie vluchtige FPGA’s, beperken we ons in de implementatie tot standaard primitieven die beschikbaar zĳn in vluchtige FPGA’s. Aanpassingen aan de FPGA zelf worden niet beschouwd omdat de producenten waarschĳnlĳk niet snel te overhalen zĳn om de nodige aanpassingen te maken.

1.3.2

Overzicht

In het volgende hoofdstuk wordt de FPGA-technologie in detail uitgediept. De interne werking, de configuratiecontroller en de bĳhorende ontwerpsoftware worden geanalyseerd. Vervolgens wordt ook de ontwerpmethodiek meer in detail besproken. Daarna zullen enkele specifieke componenten besproken worden die we in het vervolg van deze thesis nodig zullen hebben. In hoofdstuk 3 wordt de nieuwe beveiligingstechniek in grote lĳnen geschetst. De doelstellingen worden concreter gemaakt en de veronderstellingen worden duidelĳk gemaakt. Vervolgens zal er vanop een hoog niveau beschreven worden hoe de gewenste doelstellingen gerealiseerd zullen worden. Er volgt ook een volledige protocolomschrĳving van de communicatie tussen alle betrokken partĳen. In hoofdstuk 4 wordt de implementatie van de verschillende bouwblokken uit de doeken gedaan. De implementatie zal gebeuren voor een Xilinx Virtex-5 FPGA. 14

Doel van deze thesis Hier zal ook beschreven worden welke bestaande hardwarecomponenten we kunnen hergebruiken en welke we zelf ontwerpen. In hoofdstuk 5 wordt een analyse gemaakt van de veiligheid van deze nieuwe techniek.

15

Hoofdstuk 2

Overzicht We geven eerst een gedetailleerd overzicht van de architectuur van vluchtige FPGA’s, de configuratiecontroller en de bĳhorende ontwerpsoftware. Vervolgens bespreken we de ontwerpmethodiek die typisch gevolgd wordt voor grote ontwerpen waar veel partĳen moeten samenwerken, en de bĳhorende IP-beschermingsproblematiek. Ten slotte bespreken we enkele componenten die we later zullen gebruiken in ons ontwerp. Voor de implementatie van deze componenten zullen we verwĳzen naar de literatuur.

2.1

Field Programmable Gate Arrays

FPGA’s zĳn chips die een hiërarchische structuur hebben van een groot aantal configureerbare bouwblokken. Er zĳn verschillende soorten bouwblokken. Er zĳn een groot aantal logische blokken, er zĳn blokken die enkel dienen voor de routering van de signalen tussen de logische blokken, en er zĳn ingangs- en uitgangsbuffers om externe signalen te gebruiken in de circuits en om interne signalen naar buiten te brengen. Vaak is ook een hoeveelheid RAM-geheugen aanwezig, worden hardwarevermenigvuldigers voorzien en soms worden zelfs digitale signaalverwerkingsprocessoren (DPS’s) voorzien. Sommige FPGA’s bevatten zelfs een zogenaamde hard-core processor zoals de PowerPC processor in sommige Virtex FPGA’s van Xilinx. De logica-bouwblokken bevatten typisch Lookup Tables (LUT’s), multiplexers, flipflop’s (FF’s) en carry-chain logica. De ontwerper bepaalt hoe deze elementen zich individueel dienen te gedragen en bepaalt ook de routering van de signalen. Op deze manier kunnen complexe circuits gerealiseerd worden. Omdat FPGA’s zeer generiek opgebouwd zĳn, kunnen ze worden ingezet in tal van toepassingen. Vooral in toepassingen waar er slechts een beperkte oplage vereist is zĳn FPGA’s zeer interessant omdat het ontwerpen van een eigen chip, een ASIC, een zeer grote initiële investering vereist. ASIC’s zĳn interessant voor circuits die in massaproductie gaan. Het grootste voordeel van ASIC’s is de mogelĳkheid tot zeer snelle en energie-efficiënte ontwerpen. Bĳ ASIC’s heeft de ontwerper ook de volledige vrĳheid over hoe hĳ zĳn circuits ontwerpt en is het ook mogelĳk analoge en zogenaamde mixed-signal circuits te realiseren. Standaard FPGA’s daarentegen zĳn alleen geschikt voor volledig digitale circuits. 17

2. Overzicht

Figuur 2.1: Slices en CLB’s in een Xilinx FPGA met aanduiding van de carry-chain logica [32]

De voornaamste producenten van FPGA’s zĳn Xilinx (50% marktaandeel) en Altera (33% marktaandeel) [8]. Hoewel de concepten die in deze thesis geïntroduceerd zullen worden generiek zĳn en toepasbaar zĳn op FPGA’s van verschillende producenten, zullen we ons voor de implementatie enkel concentreren op een implementatie voor Xilinx FPGA’s. Tevens zal bepaalde terminologie specifiek zĳn voor Xilinx FPGA’s. Dezelfde concepten bestaan doorgaans ook bĳ hun concurrenten maar onder een andere naam. De bouwblokken waaruit een FPGA opgebouwd is voor de logica heten in Xilinx terminologie Configurable Logic Blocks (CLB). Eén CLB bestaat uit twee slices, zie figuur 2.1. Iedere slice bevat meerdere LUT’s, multiplexers, FF’s, en carry-chain logica. Het schema van een slice wordt afgebeeld in figuur 2.2. FPGA’s bevatten vaak een hoeveelheid BlockRAM. In de Virtex-5 serie wordt er 36 kbit per BlockRAM voorzien. Afhankelĳk van het precieze type kan er in totaal tussen 1 Mbit en 10 Mbit aan data opgeslagen worden in BlockRAM. Deze BlockRAM heeft twee onafhankelĳke lees- en schrĳfpoorten. Tevens kan de ontwerper zelf het aantal bits van het adres kiezen en dus de breedte van de datawoorden in het geheugen. Dit maakt het voorziene BlockRAM erg flexibel in gebruik. Het BlockRAM kan ook geconfigureerd worden als een First-In-First-Out geheugen dat ook een vaak gebruikt bouwblok is. Het BlockRAM ondersteunt ook foutdetectie. We zullen het BlockRAM later gebruiken om het instructiegeheugen van een microcontroller in op 18


Figuur 2.2: Architectuur van één FPGA slice van de Virtex-5 serie [32]

te slaan. Populaire commerciële FPGA’s zoals deze van Xilinx en Altera bevatten typisch geen niet-vluchtig geheugen, dus de configuratie van alle bouwblokken moet na het opnieuw opstarten opnieuw ingeladen worden vanuit een extern niet-vluchtige geheugen. Meestal wordt deze configuratie opgehaald uit een flashgeheugen dat zich op hetzelfde Printed Circuit Board (PCB) bevindt. Er bestaan ook andere FPGA’s die wel niet-vluchtig geheugen hebben. Dit geheugen wordt dan typisch gerealiseerd met flashgeheugen of zogenaamde anti-fuses. Dit soort FPGA met ingebouwd niet-vluchtig geheugen is wel een stuk duurder dan deze zonder niet-vluchtig geheugen. Om dit geheugen te voorzien moet men immers door een reeks extra processtappen tĳdens de productie van de chip. De FPGA-chip met flashgeheugen is duurder dan een chip zonder flashgeheugen maar men spaart wel de kostprĳs van een extern niet-vluchtige geheugen uit. Voorbeelden van dergelĳke FPGA’s zĳn deze uit de Actel RT serie [1] en de Lattice XP2 [16]. 19

2. Overzicht

2.1.1

Configuratiecontroller

Een SRAM-gebaseerde FPGA heeft een configuratiecontroller nodig om alle bouwblokken te configureren bĳ het opstarten van de FPGA. Deze configuratie gebeurt door middel van een reeks commando’s. De configuratie kan opgedeeld worden in drie fasen: • Initialisatiecommando’s • Configuratie van de CLB’s, ingangs- en uitgangsbuffers, BlockRAM, de klokcircuits en van de routering tussen deze componenten. • Finalisatie en inschakelen van het ontwerp Deze commando’s worden in één bestand gezet dat in de FPGA kan worden ingeladen. Dit bestand wordt een bitstream genoemd. De initialisatiecommando’s van een standaard bitstream kunt u zien in figuur 2.3. In het begin gebeurt er overleg over de breedte van de communicatiebus. Op het einde ziet men het RCRC commando waarmee het CRC register gereset wordt. Na het RCRC commando worden nog tal van reset commando’s gegeven om de FPGA klaar te maken voor de eigenlĳke configuratie. De eigenlĳke configuratie van de verschillende blokken van een FPGA, de CLB’s, routeringsmatrices, ingangs- en uitgangsbuffers (IOB’s), BlockRAM’s, en anderen gebeurt met het WCFG-commando. Vooraleer het WCFG-commando gegeven kan worden moet er in het Frame Address Register (FAR) geschreven worden welke precieze bouwblokken geconfigureerd dienen te worden. Dit kan immers niet allemaal in één keer. Nadat het FAR-register juist is ingesteld en het WCFG-commando gegeven werd, wordt een datablok gegeven dat de configuratie bevat van die elementen die overeenkomen met het adres dat in het FAR-register geschreven werd. Dit datablok wordt ook een frame genoemd. Het frame wordt eerst in een intern register geschreven en vervolgens wordt het gekopieerd naar een intern configuratiegeheugen. Deze sequentie van commando’s vind je terug in figuur 2.4. Nadat de verschillende componenten en de routering hiertussen ook geconfigureerd is, wordt een Cyclische foutcontrole (CRC) uitgevoerd om na te gaan of er geen fout is opgetreden bĳ het inladen van de configuratiegegevens. Eén van de laatste commando’s uit de bitstream zal de CRC-waarde in het CRC-register schrĳven. Indien deze waarde overeenkomt met de waarde die de configuratiecontroller zelf heeft berekend is er geen fout opgetreden. De configuratiecontroller zal in dat geval het ontwerp activeren. Alle frames hebben voor een Virtex-5 dezelfde grootte, namelĳk 1312 bits. Het is bekend dat frames de inhoud van het BlockRAM bevatten, de wĳze waarop signalen gerouteerd worden, hoe de verschillende LUT’s geconfigureerd worden, enzovoort maar de precieze wĳze waarop deze informatie in deze 1312 bits verwerkt zit, is niet duidelĳk. Door reverse-engineering is het mogelĳk de betekenis van sommige van deze bits te achterhalen. De configuratie van de FF’s, LUT’s en de inhoud van het BlockRAM zĳn relatief eenvoudig te achterhalen terwĳl de routering van de verschillende signalen achterhalen moeilĳk blĳkt te zĳn. 20


Figuur 2.3: De eerste commando’s uit een Xilinx bitstream [31]

Figuur 2.4: De configuratiecommando’s om frames te schrĳven [31] 21

2. Overzicht De reden waarom het moeilĳk is om de routering van verschillende signalen te achterhalen is waarschĳnlĳk omdat dit afhangt van de erg specifieke details van de fysische implementatie van de FPGA [8]. Deze details zĳn enkel gekend door de producent van de FPGA. Om een signaal van punt A naar punt B te brengen dient dit signaal door meerdere schakelmatrices te gaan, en de werking van deze schakelmatrices is niet beschreven in de publieke datasheets. De structuur van de frame-adressen die in het FAR-register worden geschreven staat beschreven in [31]. Het adres wordt opgedeeld in 5 delen. Het eerste stuk beschrĳft het bloktype dat geconfigureerd wordt (CLB’s, BlockRAM, ...) en de andere delen beschrĳven de fyische locatie van dit blok. Men verdeelt deze fysische plaats in een boven- en een onderhelft. Iedere helft wordt verdeeld in rĳen. Iedere rĳ wordt opnieuw verdeeld in verschillende kolommen. Met het minor address bepaalt men welk element uit deze kolom men wilt configureren.

2.1.2

Interne configuratiepoort (ICAP)

De normale configuratiewĳze is dat de FPGA bĳ het opstarten de nodige commando’s extern krĳgt om alle blokken correct te configureren en dat na de configuratie het ontwerp volledig operationeel is. De configuratie van de verschillende blokken blĳft normaal ongewĳzigd tot de FPGA wordt uitgeschakeld. Het is echter nog altĳd mogelĳk commando’s aan de configuratiecontroller te geven nadat alles al geconfigureerd is. Men kan blokken herconfigureren. Deze commando’s hoeven niet noodzakelĳk extern aangelegd te worden aan de FPGA. Het is ook mogelĳk zelf de nodige logica te bouwen op FPGA die via een interne poort met de configuratiecontroller communiceert. Deze poort heet de Internal Configuration Access Port (ICAP). Omdat het mogelĳk is de verschillende blokken te herconfigureren en omdat dit ook door de eigen gemaakte circuits kan gedaan worden via de interne poort is het mogelĳk zelfwĳzigende hardware te maken, hardware die zĳn eigen circuits kan aanpassen. Zelfwĳzigende hardware houdt wel risico’s in. Het ontwerp wordt complexer want het circuit is geen vast gegeven. Het is ook mogelĳk een kortsluiting te veroorzaken wanneer na herconfiguratie de signalen op een zodanige wĳze gerouteerd worden dat er ergens een 1 met een 0 wordt verbonden zonder logica ertussen. Via de ICAP-poort is het niet alleen mogelĳk om verschillende blokken te configureren, het is ook mogelĳk de configuratie van deze blokken uit te lezen. Met deze zogenaamde readback functionaliteit is het bĳvoorbeeld mogelĳk na te kĳken dat de commando’s uit de bitstream correct werden uitgevoerd en dat de configuratie van de blokken overeenkomt met de gewenste configuratie.

2.1.3

Picoblaze microcontroller

Xilinx stelt gratis een 8-bit microcontroller ter beschikking. Deze microcontroller heeft de naam Picoblaze gekregen omdat hĳ erg klein is. Hĳ neemt slechts een 96 slices in beslag [29]. Picoblaze ondersteunt een eenvoudige instructieset, interrupts, scratchpad geheugen, heeft veel ingangs- en uitgangspoorten, en is ideaal voor 22

Field Programmable Gate Arrays tĳdskritische toepassingen aangezien iedere instructie gegarandeerd in 2 klokcycli uitgevoerd wordt. Er bestaan verschillende programma’s om met de Picoblaze microcontroller te werken [29]: • Xilinx voorziet een assembler programma [29] dat de assembler code kan omzetten naar machinecode voor de Picoblaze. • pBlazIDE [18] is een geïntegreerde ontwerpomgeving. Deze ondersteunt onder andere simulatie van de Picoblaze-instructies en biedt ondersteuning bĳ het debuggen van de programmacode. pBlazIDE heeft ook een eigen assembler ingebouwd die de assemblercode kan omzetten naar machinecode voor de Picoblaze. Met pBlazIDE is het echter niet mogelĳk om hardware die verbonden wordt met de picoblaze samen met de microcontroller te simuleren. • ModelSim [19] is een algemene digitale-hardwaresimulator en is dus wel in staat hardware die verbonden is met de Picoblaze samen te simuleren. Het is echter niet meer mogelĳk de interne werking van de microcontroller te volgen. Deze tool is voornamelĳk interessant wanneer men redelĳk zeker is van de correctheid van de programmacode maar de timing wilt controleren met externe signalen. • Picoasm [25] is een open-source assembler voor de picoblaze instructieset. Functioneel doet deze identiek hetzelfde als het assemblerprogramma dat Xilinx voorziet. Van het feit dat picoasm open-source is, zullen we later dankbaar gebruik van maken omdat we aanpassingen zullen maken aan de wĳze waarop instructies vertaald worden naar machinecode. • Kpicosim [24] is gelĳkaardig aan pBlazIDE maar is open-source. Dit wil zeggen dat de broncode van kpicosim vrĳ beschikbaar is en aangepast kan worden. Kpicosim heeft dezelfde voor- en nadelen van pBlazIDE. Het is dus geschikt om de programmacode functioneel te testen maar de interactie met andere circuits zal door een andere simulator zoals ModelSim moeten gebeuren. Kpicosim gebruikt picoasm om de assemblercode om te zetten naar machinecode. Voor de microcontroller maakt het niet uit waar zĳn programmacode opgeslagen zit. Picoblaze geeft als uitgang het instructie-adres en verwacht 2 klokcycli later de bĳhorende instructie op de juiste ingangspoort. Meestal wordt het instructiegeheugen in BlockRAM opgeslagen maar het kan in principe op gelĳk welke manier bewaard worden, bĳvoorbeeld ook in gedistribueerd geheugen op basis van LUT’s. We zullen het instructiegeheugen steeds in BlockRAM bewaren. Alle assemblerprogramma’s die hiervoor besproken werden, hebben de mogelĳkheid om een bestand te genereren waarin reeds de juiste code staat om een BlockRAM te initialiseren met de machinecode voor de picoblaze. Deze assemblerprogramma’s vertrekken vanaf een template die reeds de juiste code bevatten om het BlockRAM te gebruiken, maar nog niet de inhoud van het BlockRAM bevat. Het assemblerprogramma vult deze template dan aan met de juiste machinecode. 23

2. Overzicht

2.2

Hardwareontwerpmethodiek

Wanneer men een hardwareontwerp maakt voor FPGA beschrĳft men de circuits typisch met een hardwarebeschrĳvingstaal (Hardware Description Language (HDL). De twee meest gebruikte talen zĳn VHDL en Verilog. Deze beschrĳving in een HDL wordt in het syntheseproces omgezet tot een netlĳst. Een netlĳst in deze context is een lĳst van primitieven die gebruikt worden zoals FF’s, LUT’s en BlockRAM. In de netlĳst wordt ook beschreven welk primitief met welk ander primitief verbonden wordt. Van de meeste primitieven zoals LUT’s en FF’s zĳn er vele duizenden beschikbaar op een FPGA. In de netlĳst wordt nog niet beschreven welke precieze instantie gebruikt zal worden, alleen maar dat er één nodig is. In drie volgende stappen, vertaling, mapping en routering wordt deze netlĳst omgezet tot een volledige beschrĳving van welke precieze elementen op de FPGA zullen gebruikt worden en met welke fysische verbindingen deze met elkaar zullen verbonden worden. Deze finale beschrĳving is ook geoptimaliseerd zodat het ontwerp zo snel mogelĳk kan werken, met andere woorden er wordt getracht de fysische vertraging van het kritische pad zo klein mogelĳk te houden. Er wordt ook gepoogd de oppervlakte van het ontwerp zo klein mogelĳk te houden. Tĳdens de vertaling van de netlĳst naar de finale circuitbeschrĳving kan ook rekening gehouden worden met andere criteria zoals tĳdsgebaseerde criteria. Vanuit deze finale circuitbeschrĳving wordt vervolgens een bitstream gemaakt. Dit proces waarbĳ de finale circuitbeschrĳving wordt omgezet tot een bitstream is een één-op-één mapping. De finale circuitbeschrĳving bevat dezelfde informatie als de bitstream. Dit is niet het geval bĳ de vertaling, mapping en routering. Deze bitstream wordt door de configuratiecontroller ingelezen vanuit een niet-vluchtig geheugen bĳ het aanzetten van de FPGA. De structuur van de bitstream werd reeds besproken in 2.1.1.

2.2.1

Partĳen

In de inleiding werd reeds duidelĳk gemaakt dat er erg veel partĳen betrokken zĳn bĳ de productie van een FPGA-ontwerp. In het vervolg van deze thesis zullen we slechts te maken hebben met onderstaande vier partĳen. • IP-eigenaar • Systeemontwerper • Producent • Eindgebruiker De IP-eigenaar is de entiteit die een deel van het ontwerp of héél het ontwerp ontworpen heeft en dus nog beschikt over de vermogensrechten op dit deel van het ontwerp. Het eindproduct van een IP-eigenaar wordt overgedragen ofwel in de vorm van een HDL-beschrĳving, in de vorm van een al dan niet vercĳferde netlĳst of met een partiële bitstream. Een vercĳferde netlĳst kan enkel gebruikt worden 24

Hardwareontwerpmethodiek door gebruik te maken van dezelfde ontwerpsoftware. Een partiële bitstream is een bitstream die geen volledig werkend ontwerp bevat, maar slechts een deel hiervan. De systeemontwerper werkt samen met alle IP-eigenaars en integreert deze onderdelen. Indien er maar één IP-eigenaar is, dan is deze de systeemontwerper. Het eindproduct van de systeemontwerper is een bitstream. Deze bitstream gaat vervolgens naar de producent. Deze produceert het eindproduct met alle hardwarecomponenten. Eén van deze componenten zal de bitstream bevatten in niet-vluchtig geheugen. Het product wordt vervolgens verkocht aan de eindgebruiker. De eindgebruiker kan zonder veel moeite de bitstream zelf uitlezen uit dit niet-vluchtige geheugen door de configuratiebus af te luisteren met een Logic Analyzer wanneer de configuratiebus extern beschikbaar is zoals uitgelegd in sectie 1.1.3. Problemen met deze ontwerpmethodiek • Het eindproduct van de IP-eigenaar, namelĳk een ontwerp beschreven in een HDL, een netlĳst, of een partiële bitstream is veel waard. Typisch kost het vele manmaanden om een ontwerp te maken en de confidentialiteit van dit ontwerp is voor de IP-eigenaar dus van groot belang. Meestal wordt het eindproduct van de IP-eigenaar in de vorm van HDL-code doorgegeven aan de systeemontwerper. Bĳgevolg moet de IP-eigenaar de systeem ontwerper vertrouwen dat deze zĳn ontwerp niet doorverkoopt aan zĳn concurrenten. Voor de IP-eigenaar is het interessanter om zĳn ontwerp in de vorm van een partiële bitstream door te geven dan in HDL-vorm. Een partiële bitstream is immers veel minder waard op de (zwarte) markt dan het ontwerp in HDL-vorm. Het risico op ongewenste kopieën blĳft echter groot en de IP-eigenaar zou liever zĳn ontwerp volledig vercĳferen op een manier dat het enkel ontcĳferbaar is op één enkele FPGA. Voor ieder verkocht product zou de producent een sleutel moeten kopen bĳ de IP-eigenaar om het ontwerp in werking te zetten. • De producent heeft de bitstream nodig om deze in het niet-vluchtige geheugen van het product te programmeren. Niets belet hem echter méér producten te maken dan gevraagd, en deze overige producten aan een andere klant te verkopen. Merk op dat de producent hier bĳna geen meerkost aan heeft. Duizend stuks produceren of tweeduizend stuks kost hem, op grondstoffen na, evenveel. Dit is nadelig voor de IP-eigenaar en systeemontwerper, aangezien zĳ slechts betaald worden voor de afgesproken duizend stuks. Dit fenomeen heet overbuilding. Typisch bevindt de producent zich ver weg van de systeemontwerper en de IP- eigenaar. Het is bĳgevolg moeilĳk te controleren dat er niet méér stuks geproduceerd worden dan afgesproken. • Een eindgebruiker kan ook gemakkelĳk de configuratiebus afluisteren en de bitstream, die opgeslagen zit in het niet-vluchtige geheugen, kopiëren. Een 25

2. Overzicht replica maken van de hardware rond de FPGA is typisch niet zo moeilĳk. Bĳgevolg kan iedere eindgebruiker redelĳk gemakkelĳk een volledige kopie maken van het FPGA systeem met behulp van eenvoudige technieken. Dit fenomeen heet cloning. Het is in essentie hetzelfde als overbuilding, maar cloning gebeurt door de eindgebruiker, of door een andere partĳ met een dergelĳk doel.

2.3

Ontwerpsoftware voor FPGA

Xilinx voorziet ontwerpsoftware om met hun FPGA’s aan de slag te gaan. Deze software heeft de naam ISE Design Suite. Hier bestaat een gratis versie van, de Webpack Edition. ISE heeft tal van mogelĳkheden ingebouwd om het een echte geïntegreerde ontwerpomgeving te noemen. De belangrĳkste zĳn de volgende: • Hardwareontwerpen kunnen op verschillende wĳzen ingegeven worden. Dit kan in VHDL of Verilog, of door een schema van het circuit te tekenen, of door een eindigetoestandsmachine (FSM) te beschrĳven. • Deze ontwerpen worden door ISE geoptimaliseerd en gesynthetiseerd tot een bitstream voor een specifieke FPGA. De ontwerper heeft de mogelĳkheid voorwaarden op te leggen aan het ontwerp zoals tĳdsvoorwaarden en plaatsingsvoorwaarden. Tĳdsvoorwaarden zorgen ervoor dat ISE het circuit op dergelĳke wĳze synthetiseert dat het tĳdsgedrag van het circuit voldoet aan de vooropgestelde eisen. Met plaatsingsvoorwaarden kan de ontwerper kiezen op welke fysieke locatie in de FPGA een deel van het circuit moet geconfigureerd worden. • ISE bevat een simulator die toelaat de functionaliteit van het ontwerp te testen voordat het op een FPGA geladen wordt. Een screenshot van de Project Navigator uit de ISE suite wordt getoond in figuur 2.5. Eén van de programma’s die meegeleverd wordt met ISE is FPGA Editor. FPGA Editor laat toe om een finale ontwerpbeschrĳving, waarin de routering van de signalen tussen de verschillende componenten reeds gedaan is, te bekĳken en aan te passen. Het is bĳvoorbeeld nog mogelĳk de initiële waarden van FF’s en de configuratie van de LUT’s en MUX’en aan te passen en om de routering van signalen te wĳzigen. Een screenshot van de FPGA Editor grafische interface wordt getoond in figuur 2.6.

2.4

Bestaande componenten

We bespreken twee componenten die we nodig zullen hebben in het volgende hoofdstuk, namelĳk circuitvergrendeling en een compacte hashfunctie op FPGA. 26

Bestaande componenten

Figuur 2.5: Een screenshot van het ISE programma

2.4.1

Circuitvergrendeling

Onder circuitvergrendeling wordt verstaan dat een ontwerp initieel wordt afgeleverd op een vergrendelde manier, zodat het onbruikbaar is. Slechts na een ontgrendelsignaal te geven kan het circuit ontgrendeld worden en correct functioneren. Dit ontgrendelsignaal wordt typisch gegeven door de IP-eigenaar van het circuit, eventueel na betaling van de licentiekosten. Dit wordt ook active metering genoemd, de IP-eigenaar meet actief hoeveel ontwerpen ontgrendeld zĳn. Active metering staat in tegenstelling tot passieve controle waarbĳ de IP-eigenaar enkel kan controleren of zĳn IP aanwezig is in een gegeven product. Er bestaan verschillende mogelĳkheden om een circuitvergrendeling te realizeren. Een eerste mogelĳkheid is op basis van een geobfusceerde Finite State Machine (FSM) [3]. Men veronderstelt dat het circuit niet kan werken zonder de correcte werking van een centrale FSM. Deze FSM past men aan door extra toestanden en transities toe te voegen waardoor de originele FSM geobfusceerd wordt. Enkel door het geven van het correcte ontgrendelsignaal zal de FSM in de juiste initiële toestand terecht komen en zal het circuit zĳn functie correct uitvoeren. Men kan ook zogenaamde blackhole-toestanden toevoegen aan de FSM om de veiligheid ervan 27

2. Overzicht

Figuur 2.6: Een screenshot van het FPGA Editor programma

te verbeteren. Eénmaal men in een blackhole-toestand terecht komt, zal geen enkel ontgrendelsignaal ervoor zorgen dat men uit een blackhole toestand geraakt. Dit wordt verder beschreven in [3]. In [20] worden andere mogelĳkheden beschreven om een circuitvergrendeling te realiseren. Hier wordt er verondersteld dat er een belangrĳke communicatiebus aanwezig is in het circuit. Door de communicatie over deze bus te obfusceren zal het circuit niet werken. Het circuit kan ontgrendeld worden door een correct ontgrendelsignaal dat de communicatie op de bus terug normaal laat functioneren. De communicatie op deze bus kan verstoord wordt door een permutatie toe te passen op de verschillende bits van de bus, of door het ontgrendelsignaal te XOR’en bĳ alle bits, of een reversibele lineaire transformatie toe te passen. Deze technieken en hun voor- en nadelen worden besproken in [20].

2.4.2

Een compacte hashfunctie op FPGA

Het ontwerp dat we in het volgende hoofdstuk zullen voorstellen, zal een hashberekening moeten uitvoeren. Op de FPGA zal dus een hashfunctie aanwezig moeten zĳn. We kunnen dit ofwel in software doen ofwel in hardware. We wensen een zo klein mogelĳke hashfunctie om ons ontwerp zo klein mogelĳk te houden. De recente SHA-3 competitie heeft gezorgd voor een groot aantal nieuwe hashfunctie-ontwerpen waar software- en hardware-implementaties publiek gemaakt werden. De implementatie van de hashfunctie bespreken we verder in sectie 4.1.

28

Hoofdstuk 3

Ontwerp In dit hoofdstuk wordt een overzicht gegeven van de bĳdrage van dit werk aan het probleem van IP-beveiliging op FPGA’s. In een eerste sectie worden de doelstellingen en veronderstellingen bepaald. Vervolgens bespreken we de bouwblokken die we zullen gebruiken in onze bĳdrage. Ten slotte beschrĳven we ons ontwerp en het protocol dat gevolgd dient te worden door de verschillende partĳen. Het volgende hoofdstuk zal dieper ingaan op de concrete implementatie van de verschillende componenten.

3.1

Doelstellingen en veronderstellingen

We willen een IP-beveiliging ontwerpen die cloning en overbuilding bĳ vluchtige FPGA’s verhindert. Dit zullen we doen door een ontwerp te binden aan een specifieke FPGA-chip. We wensen ook een goedkope beveiliging en zullen bĳgevolg geen externe hardware gebruiken. Het beveiligingscircuit dat we zullen introduceren, moet dus samen met het te beveiligen ontwerp op dezelfde FPGA geïmplementeerd kunnen worden. De grootte van het beveiligingscircuit moet zo klein mogelĳk zĳn. We willen ook de integriteit van een ontwerp kunnen garanderen. We zullen aantonen dat de implementatie van beide doelstellingen zeer gelĳkaardig is en dat het dus voor de hand ligt om beiden tegelĳk te realiseren. Het is interessant de integriteit van een ontwerp te kunnen garanderen omdat dit het mogelĳk maakt bĳvoorbeeld een publieke sleutel voor asymmetrische cryptografie veilig te bewaren in dit ontwerp. Wanneer men een publieke sleutel heeft en de integriteit hiervan is gewaarborgd dan wordt het mogelĳk een waaier aan cryptografische technieken te gebruiken om veel complexere beveiligingen te ontwerpen. De integriteit van een circuit garanderen werkt als een bootstrap voor andere, reeds bestaande, technieken. We maken nu duidelĳk welke veronderstellingen we maken en waarom ze realistisch zĳn: 1. De inhoud van BlockRAM’s, LUT’s en de initiële waarden van de FF’s van een FPGA worden op geen enkele manier beschermd door de obfuscatie van de bitstream, met andere woorden noch hun confidentialiteit noch de integriteit kan gegarandeerd worden louter op basis van de bitstreamobfuscatie. 29

3. Ontwerp Bitstreamobfuscatie is de obfuscatie die de bitstream teweegbrengt doordat de structuur van de bitstream niet helemaal publiek gekend is. De bitstream werd reeds uitgebreid besproken in sectie 2.1.1. 2. Volledige reverse-engineering van een FPGA-bitstream is nog niet mogelĳk omwille van de moeilĳkheid om de routeringsgegevens uit deze bitstream te halen. Daarom veronderstellen we dat de routeringsgegevens van een ontwerp geobfusceerd zĳn door de bitstream [8]. Met andere woorden, de routering is confidentieel en kan niet aangepast worden op een zinvolle manier. De integriteit kan niet gegarandeerd worden omdat een willekeurige aanpassing in de bitstream met grote waarschĳnlĳkheid de routering van het ontwerp zal aanpassen, maar op een onvoorspelbare manier. 3. Het extern uitlezen van de configuratie van de FPGA is onmogelĳk, of het is mogelĳk om deze functionaliteit uit te schakelen. Met andere woorden het is voor een externe waarnemer niet mogelĳk om de inhoud van geheugenelementen tĳdens het functioneren van het ontwerp na te gaan. Niet alle FPGA’s beschikken over dergelĳke readback functionaliteit, maar als ze aanwezig is veronderstellen we dat het ook mogelĳk is deze uit te schakelen. 4. Het moet mogelĳk zĳn een ontwerp te vergrendelen zodat het enkel zal functioneren wanneer een correct ontgrendel signaal wordt gegeven. Deze technieken werden besproken in 2.4.1. We veronderstellen dus dat het moeilĳk is een circuit te ontgrendelen wanneer enkel zĳn bitstream voorstelling gegeven is. Aangezien we ook veronderstellen dat de routering confidentieel is, is het ook onmogelĳk om het circuit te reverse-engineeren naar een netlĳst om op een hoger niveau de vergrendelingslogica te verwĳderen.

3.2

Gebruikte primitieven

We bespreken eerst de bouwblokken van onze beveiligingsarchitectuur. De bouwblokken zĳn de volgende: • Een initialisatiecontroller die de integriteitscontrole zal uitvoeren en die zal nagaan of het ontwerp niet gekopieerd is naar een andere FPGA. • Een veilige opslag van het instructiegeheugen van de microcontroller die centraal staat in de initialisatiecontroller. We willen immers vermĳden dat iemand de instructies kan aanpassen die de microcontroller uitvoert. • Een veilig opslag voor een hashwaarde wat nodig zal zĳn om de integriteit van het circuit te garanderen. • Een cryptografische hashfunctie, zie sectie 4.1 voor de implementatie. 30

Ontwerp

3.2.1

Initialisatiecontroller

Centraal in het IP-beschermingscircuit staat een initialisatiecontroller die de integriteit van het ontwerp zal nagaan en die ook controleert dat het ontwerp niet gekopieerd is naar een andere FPGA. Deze initialisatiecontroller zal geïmplementeerd worden op basis van een Xilinx Picoblaze microcontroller. Het instructiegeheugen van de microcontroller zal in BlockRAM opgeslagen worden.

3.2.2

Geobfusceerde opslag van het instructiegeheugen

We moeten zeker zĳn dat de instructies die de initialisatiecontroller uitvoert de instructies zĳn die door de IP-eigenaar geprogrammeerd werden. Indien een aanvaller er in zou kunnen slagen zelf te kiezen welke instructies de controller uitvoert dan zou het eenvoudig zĳn om de beveiliging te breken.

3.2.3

Geobfusceerde opslag van een hashwaarde

Om de integriteitscontrole van het ontwerp uit te voeren moet het mogelĳk zĳn een vooraf berekende hashwaarde veilig op te slaan in het ontwerp. Met veilig bedoelen we op een manier zodanig dat de integriteit van de hashwaarde gewaarborgd is. Indien een aanvaller toch de hashwaarde zelf zou kunnen wĳzigen dan zou hĳ het ontwerp ongemerkt kunnen aanpassen en kopiëren.

3.3 3.3.1

Ontwerp Architectuur

We kunnen de drie bouwblokken uit sectie 3.2 combineren om de integriteit van een ontwerp te garanderen en om te verhinderen dat een ontwerp gekopieerd wordt naar andere FPGA’s. De architectuur wordt schematisch weergegeven in figuur 3.1. Het ontwerp bestaat uit drie delen: • Het ontwerp Cp dat we willen beveiligen. • De IP-beveiligingsarchitectuur Cq die de initialisatiecontroller, de hashfunctie en het instructiegeheugen bevat. • De opslag voor de hashwaarde Hk . De initialisatiecontroller wordt verbonden met de ICAP-poort van de FPGA. Via de ICAP-poort is het mogelĳk de bitstreamvoorstelling op te vragen van het geconfigureerde ontwerp. De initialisatiecontroller zal via de ICAP-poort de bitstreamvoorstelling opvragen van Cp en ook van zichzelf, Cq . Van deze bitstreamvoorstelling wordt vervolgens een hashwaarde Hj berekend. Indien beide hashwaarden overeenkomen, Hj = Hk dan weet de initialisatiecontroller dat het ontwerp niet gewĳzigd is sinds de IP-eigenaar het ontworpen heeft, met de veronderstelling dat we zeker zĳn dat de opgeslagen hashwaarde Hk 31

3. Ontwerp

Figuur 3.1: Overzicht van de IP-beveiligingsarchitectuur. De pĳlen stellen de informatiestroom voor.

en het instructiegeheugen niet veranderd zĳn. In het volgende hoofdstuk wordt besproken hoe we het geheugen voor de veilige opslag van de hashwaarde en het instructiegeheugen kunnen implementeren. Het is voor dit protocol noodzakelĳk een specifieke chip te kunnen identificeren. De meeste FPGA’s hebben een ingebakken identificatienummer dat hiervoor kan gebruikt worden. Dit ingebakken identificatienummer kan dan bĳvoorbeeld uitgelezen worden via de ICAP-poort. Echter, het inbouwen van een ingebakken, onveranderbaar, identificatienummer vereist extra processtappen bĳ het produceren van een dergelĳke chip, zoals ook uitgelegd in sectie 1.1.3. Aangezien we een goedkope kopieerbeveiliging zoeken mag deze beveiliging niet afhangen van het bestaan van een dergelĳk hardgebakken identificatie. Een alternatieve oplossing is mogelĳk op basis van een PUF (zie sectie 1.2.2). Voor het vervolg van deze uiteenzetting maakt de concrete wĳze van identificatie niet uit, we veronderstellen dat er eender welke soort unieke identificatie aanwezig is.

3.3.2

Initialisatie

In een eerste stap dient de IP-eigenaar de drie delen van het ontwerp samen te brengen in één groot ontwerp dat we C zullen noemen: zĳn eigen ontwerp Cp dat waardevolle IP bevat, het beveiligingscircuit Cq en de veilige opslag voor de 32

Ontwerp hashwaarde. Het eigen ontwerp Cp dient op een vergrendelde wĳze geïmplementeerd te worden. Enkel na het ontvangen van een ontgrendelsignaal mag Cp correct beginnen functioneren. Vervolgens kan de standaard FPGA-ontwerpmethodiek gevolgd worden zoals beschreven in 2.2, het synthetiseren, vertaling, mapping en routering. De hashwaarde die op dit punt geprogrammeerd wordt is gelĳk aan nul.

3.3.3

Personalisatie

Het finale ontwerpbestand wordt vervolgens omgezet tot een bitstream die in een FPGA geladen kan worden. Dit gebeurt opnieuw volgens de standaard ontwerpmethodiek, dus met het BitGen programma van Xilinx. De IP-eigenaar moet nu een hashberekening uitvoeren op de frames uit deze bitstream die overeenkomen met de circuits Cp en Cq , Hk = Hash(BCp ||BCq ||IDF 1 ). Hierbĳ stelt IDF 1 de unieke identificatie voor van de FPGA-chip waarop het ontwerp dient te werken en BCp en BCq stellen de bitstreamvoorstelling voor van de ontwerpen Cp en Cq . Het is nu de bedoeling om de hashwaarde Hk in de bitstream te programmeren op een manier dat wanneer men opnieuw Hk = Hash(BCp ||BCq ||IDF 1 ) berekent, dat dit dezelfde uitkomst geeft. Deze programmatie zal met het programma FPGA Editor gebeuren, dat reeds besproken werd in sectie 2.3. Met FPGA Editor kan men het finale ontwerpbestand openen en de routering van de signalen nog aanpassen. Ook de initiële waarde van de flipflops kan gewĳzigd worden. Op deze manier zal de IP-eigenaar de hashwaarde Hk programmeren in het geheugen voor de hashwaarde. Aangezien dit geheugen geen deel uitmaakt van Cp of Cq zal de hashwaarde door deze aanpassing niet gewĳzigd worden. Na deze aanpassing wordt het finale ontwerp opnieuw omgezet tot een bitstream. Deze bitstream zal volledig dezelfde zĳn als de vorige gegenereerde bitstream, op de frames na waarin de hashwaarde opgeslagen wordt.

3.3.4

Activatie

Via de ICAP-poort kan de initialisatiecontroller de bitstreamvoorstelling van het circuit Cp en van zichzelf verkrĳgen en kan hĳ ook de unieke identificatie van de FPGA opvragen. Hierop wordt vervolgens een hashberekening uitgevoerd, Hj = Hash(BCp ||BCq ||ID). Indien beide hashwaarden Hj en Hk overeenkomen dan kan men besluiten dat ID gelĳk is aan IDF 1 en dan wordt het ontwerp uitgevoerd op de correcte chip en zĳn er geen aanpassingen gebeurd aan Cp of Cq . In dat geval zal de initialisatiecontroller het ontgrendelsignaal geven aan Cp . Indien de hashwaarden niet overeenkomen dan zal de controller alle functionaliteit stopzetten. Wanneer de bitstream op een andere FPGA wordt geladen waarvan de unieke identificatie niet gelĳk is aan IDF 1 dan zal de hashberekening een andere waarde opleveren. Bĳgevolg zal het circuit Cp niet geactiveerd worden. Op deze manier wordt een kopieerbeveiliging gerealiseerd. Ook wanneer aanpassingen werden gemaakt aan ofwel Cp of Cq zullen de hashwaarden verschillen. De integriteit van beide circuits wordt dus ook gewaarborgd, op voorwaarde dat enkel de IP-eigenaar in staat is het programmageheugen te wĳzigen op een zinvolle manier en een welbe33

3. Ontwerp paalde hashwaarde te programmeren. Hierop wordt verder ingegaan in de volgende hoofdstukken.

34

Hoofdstuk 4

Implementatie In het vorige hoofdstuk werd een kopieerbeveiliging voor FPGA’s voorgesteld. Er werd wel verondersteld dat men beschikt over een veilige opslag voor een hashwaarde en voor het instructiegeheugen van de microcontroller. In dit hoofdstuk wordt eerst uitgelegd hoe de hashfunctie geïmplementeerd wordt en vervolgens wordt de implementatie van het hashgeheugen en het instructiegeheugen uit de doeken gedaan. In figuur 3.1 werd de algemene samenhang tussen alle componenten duidelĳk gemaakt.

4.1

Hashfunctie

We hebben een cryptografische hashfunctie nodig in de beveiligingsarchitectuur. Deze hashfunctie moet efficiënt implementeerbaar zĳn op FPGA en in software. De software-implementatie zal gebruikt worden tĳdens de initialisatiefase en de hardware-implementatie zal gebruikt worden tĳdens de activatiefase. De recente SHA-3-competitie heeft ervoor gezorgd dat er heel wat nieuwe hashfuncties ontworpen werden en kritisch werden geëvalueerd. Van alle inzendingen zĳn implementaties publiek beschikbaar. Een overzicht van de hashfuncties die ingezonden werden voor de competitie kan gevonden worden in [9]. In ons ontwerp zullen we de hashfunctie Hamsi [37] gebruiken. Hamsi kan volgens [12] in slechts 733 slices geïmplementeerd worden op een Virtex-5 FPGA. De hashfunctie BLAKE [4] ziet er een interessant alternatief uit omdat deze volgens [9] slechts 56 slices nodig heeft op een Virtex-5 FPGA. We hebben voor onze beveiligingsarchitectuur enkel een cryptografisch veilige hashfunctie nodig, de implementatie van deze hashfunctie is voor het vervolg niet van belang. De keuze van de hashfunctie Hamsi legt onmiddellĳk de grootte van de hashwaarde vast op 256 bits.

4.2

Geobfusceerde hash-ROM

Zoals uitgelegd in het overzicht hebben we een ROM-component nodig die een hashwaarde kan opslaan op een zodanige manier dat enkel de IP-eigenaar weet hoe hĳ een specifieke waarde hierin kan programmeren. 35

4. Implementatie Formeel kan dit als volgt uitgedrukt worden: • Gegeven de bitstreamvoorstelling B(H) van het hele ontwerp inclusief de hashROM, die een waarde H opslaat moet het moeilĳk zĳn voor iedereen buiten de IP-eigenaar om B(H 0 ) te vinden voor een gegeven willekeurige H 0 waarbĳ H 0 6= H.

4.2.1

Opslag van de hashwaarde

De hashwaarde vereist een opslag van 256 bit, dit volgt uit de keuze van de hashfunctie in sectie 4.1. Voor iedere bit voorzien we één flipflop (FF). Deze FF’s zĳn verbonden met de microcontroller, via een geheime permutatie over 256 bit. Het zou ook mogelĳk zĳn de hashwaarde in BlockRAM op te slaan, maar de interface met dit BlockRAM zou dan ingewikkelder zĳn. Bovendien zou de hashwaarde niet in één keer kunnen uitgelezen worden uit het BlockRAM aangezien de maximale woordgrootte slechts 36 bits is. De veiligheid van de hash-ROM schuilt in het feit dat men de permutatie niet kent en dat men dus niet weet hoe de FF’s zĳn doorverbonden. De flipflop die bit x opslaat, kan doorverbonden zĳn met bit-ingang y op de microcontroller en op die manier wordt een permutatie over 256 bit gerealiseerd. Dit wordt schematisch weergegeven in figuur 4.1.

4.2.2

Uitlezen van de hashwaarde door de microcontroller

De Picoblaze microcontroller beschikt slechts over één 8-bit poort om externe data in te lezen. De instructieset voorziet echter dat men 256 verschillende ingangen kan gebruiken. Wanneer de microcontroller een 8-bit waarde wilt inlezen, zal deze op de PORT ID-uitgang het poortnummer zetten waarvan de microcontroller data wilt inlezen. Door deze uitgang te koppelen aan een multiplexer is het mogelĳk 256 8-bit ingangen te gebruiken. Dit wordt geïllustreerd in figuur 4.1. Om de hashwaarde in te lezen hebben we slechts 32 poorten nodig. Er zĳn dan 32 instructies nodig, dus 64 klokcycli om de hele hashwaarde in te lezen.

4.2.3

Programmatie van de hashwaarde in de hash-ROM

Er is nog één resterend probleem, namelĳk hoe de hashwaarde en de permutatie dienen geprogrammeerd te worden. Er zĳn verschillende mogelĳkheden: 1. In de HDL-broncode kunnen INIT -parameters gebruikt worden om de initiële waarde van de FF’s in te stellen. Men zou dan eerst het hele synthese- en implementatieproces moeten doorlopen om een bitstream te krĳgen, vervolgens van de juiste onderdelen een hashberekening maken en hierna deze hashwaarde met behulp van de INIT-parameters instellen. Vervolgens dient dan nogmaals heel het synthese- en implementatieproces te worden doorlopen. Deze methode kan niet gebruikt worden indien ook de geheime permutatie op deze manier wordt ingesteld, aangezien hiervoor meestal routeringsgegevens in meerdere 36

Geobfusceerde hash-ROM

Figuur 4.1: Schema van de geobfusceerde hash-ROM

CLB’s dienen aangepast te worden. Indien dezelfde permutatie voor alle ontwerpen gebruikt zou worden dan is deze methode wel mogelĳk. 2. Het ontwerpproces zou een eerste keer volledig kunnen doorlopen worden tot en met de bitstreamgeneratie. Op basis van deze bitstream kan men dan de hashwaarde Hk berekenen. Vervolgens kan men via Xilinx FPGA Editor [35] nog de INIT-waarden van deze FF’s aanpassen en de geheime permutatie programmeren. Nadien hoeft men alleen nog maar de bitstream opnieuw te genereren. Een bitstream bevat dezelfde informatie als het ontwerp dat reeds de Place&Route stap doorlopen heeft, maar op een gedeeltelĳk onbekende manier. De bitstreamgeneratie is dus een relatief eenvoudig en snel proces. Om twee verschillende bitstreams te genereren hoeft men nog altĳd maar één keer het lange syntheseproces te doorlopen, wat enorm veel tĳd kan besparen, in tegenstelling tot de vorige optie. Men moet wel één bitstream laten genereren voor iedere verschillende hashwaarde die men wilt instellen. Een bitstream genereren vanuit de finale netlĳstbeschrĳving voor een Xilinx Virtex-5 FPGA duurt ongeveer 73 seconden op een Intel Centrino Duo met een klokfrequentie van 1.6 GHz en 1 GB RAM-geheugen. Deze snelheid hangt af van de snelheid van de computer. 3. De initiële waarden van de FF’s zouden nog in de bitstream aangepast kunnen worden, nadat deze door de Xilinx software gegenereerd is. Het voordeel van deze optie is dat men ook hier slechts éénmaal het ontwerpproces moet doorlopen, en ook maar één bitstream hoeft te genereren. Dit is dan ook duidelĳk de meest efficiënte methode indien vele bitstreams gegenereerd moeten worden, ieder met een eigen hashwaarde opgeslagen. Deze methode heeft echter ook een groot nadeel, namelĳk dat het niet mogelĳk is een geheime permutatie in te stellen. Indien steeds met dezelfde permutatie gewerkt wordt is dit echter 37

4. Implementatie geen probleem. Een tweede nadeel is dat het gevolg van een foute bit aan te passen vrĳ drastisch kan zĳn. Het is immers mogelĳk dat door enkele foutieve bits in te stellen, twee signalen aan elkaar verbonden worden die een kortsluiting veroorzaken. Door goed te controleren welke bits aangepast moeten worden, kan dit risico wel geminimaliseerd worden. In principe heeft de vorige methode dit nadeel ook maar het BitGen programma van Xilinx, dat gebruikt wordt om de bitstream te genereren op basis van de finale netlĳst, voert bĳ de bitstreamgeneratie een controle uit, de zogenaamde Design Rule Checks (DRC). Deze controle zal verhinderen dat een bitstream wordt geproduceerd die een kortsluiting kan veroorzaken. Wanneer men rechtstreeks de bitstream aanpast, zonder hulp van BitGen heeft men deze controle niet. Het is niet zeker hoe bedrĳfszeker de eerste optie is, immers deze zou enkel werken indien de gegenereerde bitstream na het hele ontwerpproces identiek is aan de bitstream uit een vorige iteratie, op de inhoud van de FF’s na. De documentatie van Xilinx is ontoereikend om hierover enige garanties te bieden. Het zou kunnen dat deze optie werkt voor de huidige versie van de ontwerpsoftware maar er zĳn geen garanties dat dat nog het geval zal zĳn bĳ een volgende versie. Wegens het verhoogde risico bĳ optie 3 van permanente schade te berokkenen aan de FPGA hebben we deze niet gebruikt voor deze thesis. We hebben dus gekozen voor optie 2, een afweging tussen performantie en risico. Om de initiële waarden van een FF in te stellen via FPGA Editor is het wel noodzakelĳk te weten om welke FF het precies gaat. Dit kan opgelost worden door de BEL-beperking [34] op te leggen aan de Xilinx software om aan te geven welke FF binnen een CLB dient gebruikt te worden. Het is op deze manier mogelĳk zelf de volgorde van de FF’s binnen een CLB op te leggen. Wanneer men nu door het hele ontwerpproces gaat, kan men na de Place&Route stap opvragen in welke CLB’s de hash-ROM opgeslagen zit. Aangezien je ook zelf de bitvolgorde hebt opgelegd, weet je ook in welke FF welke bit zit. Bĳ het instellen van de individuele FF’s moet men uiteraard rekening houden met de permutatie, die enkel de IP-eigenaar kent. FPGA Editor voorziet tevens de mogelĳkheid om dergelĳke bewerkingen te automatiseren door middel van een script, zie figuur 4.2. De initiële waarden instellen op automatische wĳze met behulp van een script duurt ongeveer 30 seconden op een Intel Centrino Duo met een klokfrequentie van 1.6 GHz en 1 GB RAM-geheugen. De veiligheid van deze geobfusceerde hash-ROM wordt besproken in sectie 5.1.

4.3

Geobfusceerde programma-ROM

In dit hoofdstuk wordt uitgelegd hoe de geobfusceerde programma-ROM geïmplementeerd wordt. De bedoeling van de geobfusceerde programma-ROM is de integriteit te garanderen van het instructiegeheugen van de Picoblaze microcontroller. Het moet eenvoudig zĳn de inhoud van de programma-ROM uit te lezen, maar het moet moeilĳk zĳn om deze inhoud te wĳzigen op een zinvolle manier. De wĳze waarop deze geobfusceerde ROM verbonden is met de microcontroller wordt schematisch weergegeven in figuur 4.3. De implementatie van de ROM-obfuscatie wordt in meer 38

Geobfusceerde programma-ROM setattr main edit-mode read-write setattr comp main_inst/rom_data<3> Config " AFF:#FF AFFINIT:INIT1 AFFMUX:AX AFFSR:SRLOW BFF:#FF BFFINIT:INIT0 BFFMUX:BX BFFSR:SRLOW CFF:#FF CFFINIT:INIT1 CFFMUX:CX CFFSR:SRLOW CLKINV:CLK DFF:#FF DFFINIT:INIT0 DFFMUX:DX DFFSR:SRLOW SYNC_ATTR:ASYNC" block apply save exit Figuur 4.2: Een voorbeeld van een FPGA Editor script dat de INIT-waarde van de 4 FF’s in de slice met naam rom_data<3> aanpast

detail weergegeven in figuur 4.4. De eisen aan deze ROM zĳn zeer gelĳkaardig aan deze voor het opslaan van de hashwaarde, de programma-ROM moet net zoals de hash-ROM gegevens opslaan op een zodanige wĳze dat enkel de IP-eigenaar deze gegevens kan programmeren. De programma-ROM moet echter veel meer gegevens opslaan dan de hash-ROM en het zou daarom inefficiënt zĳn om dezelfde implementatie te gebruiken. De hash-ROM gebruikt immers één slice per 4 bits. Om het grote instructiegeheugen op te slaan zullen we BlockRAM gebruiken. Dit maakt het ontwerp een stuk ingewikkelder dan het ontwerp van de hash-ROM uit de vorige sectie.

4.3.1

Werking van de programma-ROM

De werking is gebaseerd op een scrambling van de instructies door middel van een substitutie-permutatienetwerk met een rondestructuur. In een eerste ronde wordt de geobfusceerde instructie uit het geheugen gelezen. Vervolgens wordt deze instructie in meerdere rondes door het substitutie-permutatienetwerk gestuurd, zie figuur 4.4. De bedoeling van de programma-ROM is dat het moeilĳk wordt een instructie op een zinvolle manier te wĳzigen. Een substitutie-permutatienetwerk kan hiervoor zorgen omdat het confusie en diffusie introduceert. Diffusie betekent dat iedere bit van een gedescrambeld woord op een complexe manier afhangt van iedere bit van het gescrambeld woord. Confusie wilt zeggen dat iedere bit van het gedescrambeld woord op een complexe manier afhangt van de geheime permutatie die gebruikt werd. Dit is interessant om de veiligheid van de programma-ROM te garanderen, zie sectie 5.2 voor de veiligheidsanalyse. In dat hoofdstuk zullen we ook berekenen hoeveel rondes noodzakelĳk zĳn om voldoende confusie en diffusie te verkrĳgen en het minimum aantal bits waarover gepermuteerd dient te worden. Bovendien is het belangrĳk dat het substitutie-permutatienetwerk eenvoudig geïnverteerd kan worden door de IP-eigenaar om de instructies op de juiste manier in de programma-ROM te bewaren. De componenten uit deze ROM, de MUX, de registers en de ronde-afhankelĳke rotatie worden aangestuurd door een Finite State Machine (FSM). Aangezien het 39

4. Implementatie

Figuur 4.3: Schema van geobfusceerde programma-ROM + microcontroller

meerdere klokcycli duurt om een instructie te descramblen dient de klok van het programma-ROM sneller te lopen dan deze van de microcontroller. De hashfunctie werd voor de eenvoud ook op dezelfde klok van de microcontroller gezet maar kan in principe ook aan een snellere kloksnelheid werken. De XOR-operatie heeft als doel een aanvaller te verhinderen twee instructies van plaats te verwisselen. Dit wordt bereikt door de gescrambelde instructie te laten afhangen van het 10-bit adres. Om ervoor te zorgen dat iedere bit van het 24-bit gescrambelde instructiewoord afhangt van deze 10 bits worden deze 10 bits gedupliceerd tot 24 bits.

4.3.2

Confusie en diffusie

Om voldoende confusie en diffusie te krĳgen, hebben we ook een rotatie ingevoerd. In iedere ronde worden de bits over een aantal plaatsen geroteerd zodat de hele permutatie een effect heeft op alle bits en niet slechts een subset hiervan. In de eerste ronde wordt geroteerd over 1 positie, in de 2de ronde over 2 posities, in de 3de ronde over 3 posities en in de 4de ronde over 4 posities. Voor de volgende rondes herhaalt de sequentie zich, dus voor de 5de ronde wordt opnieuw over slechts 1 positie geroteerd. Het type rotatie zou nog verder geoptimaliseerd kunnen worden om een betere confusie en diffusie te verkrĳgen maar dit valt buiten het doel van deze thesis. De substitutieboxen (s-box) zorgen ervoor dat iedere uitgangsbit met een kans van 50% wĳzigt wanneer één ingangsbit van een s-box wĳzigt. Dit zorgt ervoor dat de gescrambelde instructiewoorden niet meer gecorreleerd kunnen worden met de gedescrambelde instructiewoorden. Voor de implementatie van de substitutieboxen kiezen we Y = X + 47 mod 64 waarbĳ Y de 6-bit uitgang van de sbox voorstelt en X de 6-bit ingang. Dit kan eenvoudig geïnverteerd worden, X = Y + 17 mod 64.

4.3.3

Scrambling van het instructiegeheugen

Het circuit dat in figuur 4.4 getoond wordt is de descrambler. Uiteraard moet er ook nog ergens gescrambeld worden. Bĳ de compilatie van de assemblercode naar machinecode dient hiermee rekening gehouden te worden. Deze scramblingoperatie werd ingebouwd in picoasm, zie ook sectie 2.1.3 en [25]. Dit maakt het gebruik van een dergelĳk scramblingcircuit zeer praktisch. Je hoeft immers enkel het scramblingcircuit rond de microcontroller te zetten en bĳ het assemblerprogramma één extra parameter meegeven om code te genereren die gescrambeld is. 40

Geobfusceerde programma-ROM

Figuur 4.4: Detailschema van de geobfusceerde programma-ROM

41

4. Implementatie Het assemblerprogramma moet ook weten welke scramblingparameters gebruikt moeten worden zoals de geheime permutatie, het type rotatie, de configuratie van de s-boxen, het adres van de instructie voor de XOR-operatie, en het aantal rondes dat uitgevoerd moet worden. Deze parameters kunnen in een configuratiebestand bewaard worden. Bĳ het oproepen van de assembler wordt dan verwezen naar het configuratiebestand. Het belangrĳkste stuk van de scramblingcode vindt u terug in figuur 4.5.

4.4

Totale implementatiekost

We zullen hier een overzicht maken van de totale implementatiekost van het IPbeveiligingsontwerp. In tabel 4.1 wordt de oppervlaktekost samengevat per component. Met oppervlaktekost bedoelen we de hoeveelheid en de soort hardware die de beveiligingsarchitectuur gebruikt op de FPGA. In tabel 4.2 wordt de kost CPU-tĳd samengevat die nodig is om één bitstream te genereren voor een specifieke FPGA. In tabel 4.3 wordt dit samengevat. We kunnen besluiten dat de totale beveiligingsarchitectuur een oppervlakteimplementatiekost heeft van 961 slices en 2 BlockRAM’s. Het grootste onderdeel is wel de hashfunctie. Volgens [5] kan de BLAKE-hashfunctie geïmplementeerd worden in slechts 56 slices en 2 BlockRAM’s. Indien we deze BLAKE-hashfunctie zouden gebruiken in de plaats van Hamsi, dan zou de totale oppervlaktekost gereduceerd worden tot 284 slices en 4 BlockRAM’s. Per FPGA dient ook een andere hashwaarde en een geheime permutatie geprogrammeerd te worden en vervolgens een nieuwe bitstream gemaakt te worden. Dit vraagt 103 seconden, afhankelĳk van de snelheid van de computer.

42

Totale implementatiekost

printf("Encoding: 0x%06x: ", hexcode); /* XOR adres met instructie */ round_input ^= (addr << 14) & (addr << 4) & (addr & 0xF); for(unsigned int r=rounds; r != 0; r--) { round_input = 0; /* Inverse Permutation */ for(unsigned int i=0; i != 24; i++) { round_input |= (((round_output >> i) & 0x1) << permutation_inverted[i]); } printf("i: 0x%06x; ", round_input); /* Inverse Rotation */ unsigned int rotation_amount = (rotation_factor * (r%4)) % 24; round_input = (((round_input << rotation_amount)&0xFFFFFF) | (round_input >> (24-rotation_amount))); printf("i2: 0x%06x; ", round_input); /* Inverse Sbox */ uint32_t part1 = (((((round_input & 0x00003F) >> 0) uint32_t part2 = (((((round_input & 0x000FC0) >> 6) uint32_t part3 = (((((round_input & 0x03F000) >> 12) uint32_t part4 = (((((round_input & 0xFC0000) >> 18) round_input = part1 | part2 part3 | part4;

sbox_prm) % 64) << 0); sbox_prm) % 64) << 6); sbox_prm) % 64) << 12); sbox_prm) % 64) << 18);

printf("r %i: 0x%06x, ", r, round_input); round_output = round_input; }

printf("scrambled: 0x%06x\n", round_input); Figuur 4.5: Het belangrĳkste stuk code van de scrambler, ingebouwd in picoasm

43

4. Implementatie

Component Kost Hamsi hashfunc733 slices tie Picoblaze 58 slices Hash-ROM

32 slices

Programma-ROM

129 slices + 2 BlockRAM’s van 18 kb

Interface met ICAP-poort

9 slices

Opmerking Volgens [12], kan vervangen worden door een kleinere hashfunctie zoals BLAKE Zou minder slices gebruiken wanneer de lengte van de hashwaarde verkleind wordt. Eén slice bevat vier FF’s en kan dus vier bits opslaan

Tabel 4.1: Oppervlakte implementatiekost van de IP-beveiligingsarchitectuur

Proces Kost Hashwaarde pro30 seconden grammeren Bitstream genera73 seconden tie

Opmerking Gebeurt met FPGA-Editor, snelheid afhankelĳk van de computer, zie sectie 4.2.3 Snelheid afhankelĳk van de computer, zie sectie 4.2.3

Tabel 4.2: CPU-tĳd implementatiekost van de IP-beveiligingsarchitectuur

Component of proces Oppervlakte op FPGA Oppervlakte op FPGA CPU-tĳd

Kost 961 slices + 2 BlockRAM’s 284 slices + 4 BlockRAM’s 103 seconden

Opmerking Indien de Hamsi hashfunctie gebruikt wordt Indien de BLAKE hashfunctie gebruikt wordt Snelheid afhankelĳk van de computer

Tabel 4.3: Totale implementatiekost van de IP-beveiligingsarchitectuur

44

Hoofdstuk 5

Veiligheidsanalyse In het vorige hoofdstuk werd besproken hoe de hash-ROM en programma-ROM precies geïmplementeerd worden. In dit hoofdstuk wordt geanalyseerd hoe resistent deze implementaties zĳn tegen een aanvaller die de integriteitscontrole wilt omzeilen of die het ontwerp wilt kopiëren naar een andere FPGA. Concrete doelstellingen en veronderstellingen worden nogmaals herhaald, met speciale aandacht voor de veiligheid van deze componenten.

5.1

Veiligheid van de hash-ROM

In deze sectie analyseren we hoe veilig de hashwaarde opgeslagen zit. De implementatie van de hash-ROM werd uitvoerig besproken in sectie 4.2. We zullen de veiligheid analyseren door meerdere scenario’s te overlopen en telkens aan te tonen hoe veilig deze implementatie is in ieder van deze scenario’s. De implementatie is veilig wanneer het voldoende moeilĳk is voor een aanvaller om de bitstream aan te passen op een zodanige manier dat hĳ een eigen gekozen hashwaarde kan programmeren. Vooraleer we de mogelĳke aanvallen bespreken is het belangrĳk de juiste veronderstellingen nogmaals op een rĳtje te zetten: 1. Een aanvaller bezit een kopie van de bitstream die geladen wordt op de FPGA. Hĳ kent ook het gebruikte hashalgoritme. Bĳgevolg kan hĳ een hashberekening uitvoeren op de bitstream en de waarde bekomen die opgeslagen zit in de geobfusceerde ROM. 2. Een aanvaller is in staat de locatie van de FF’s te bemachtigen die de hashwaarde opslaan. Immers een bitstream van hetzelfde ontwerp zal enkel verschillen van een andere bitstream, gemaakt om te werken op een andere FPGA, op de plaats waar de hashwaarde opgeslagen zit. De hashwaarde hangt immers af van de unieke identificatie van de FPGA. 3. De routering tussen de verschillende elementen kan niet achterhaald worden uit de bitstream. Men weet dus wel welke elementen er zĳn, en hoe deze geconfigureerd zĳn, maar niet hoe deze met elkaar verbonden zĳn. 45

5. Veiligheidsanalyse 4. Het is niet mogelĳk de toestand van het ontwerp te analyseren tĳdens zĳn uitvoering. Het ingangs-uitgangsgedrag van de programma-ROM kan dus niet rechtstreeks geobserveerd worden. Een aanvaller leert bĳ iedere poging enkel of zĳn poging slaagt of niet, zonder extra informatie. 5. De hashfunctie is publiek gekend. De beveiliging van de hash-ROM schuilt dus volledig in de routering tussen de verschillende elementen. We zullen nu verschillende mogelĳke aanvallen overlopen en analyseren hoe resistent de implementatie is tegen deze aanvallen. De symbolen die gebruikt worden zĳn als volgt: • De originele bitstream die in de eindproducten aanwezig is, en waar een aanvaller dus eenvoudig toegang tot heeft wordt voorgesteld door B. Een hashwaarde wordt algemeen voorgesteld door H en de inhoud van de FF’s wordt algemeen voorgesteld met W . • Bitstream B bevat een hashwaarde Hk . Om deze waarde als uitgang van de ROM te krĳgen dienen de FF’s ingesteld te worden met een waarde Wk . Met andere woorden Hk = P (Wk ), waarbĳ P de permutatie voorstelt en Wk de waarden voorstelt die de FF’s opslaan, zonder rekening te houden met de permutatie. • Een aanvaller wenst het ontwerp op een FPGA met een andere id kopiëren en wenst dus de waarde Wk = P −1 (Hash (Cp ||Cq ||IDF 1 )) te vervangen door Wl = P −1 (Hash((Cp ||Cq ||IDF 2 )). • n is de lengte van de hash in bits, in onze implementatie is dit 256 bits. Zie sectie 4.1 over de keuze van het aantal bits en over de implementatie van de hashfunctie. Er wordt verondersteld dat de hashwaarden die de hashfunctie produceert uniform verdeeld zĳn. • Hamm(x) geeft het Hamminggewicht van x. • In ieder scenario zal de aanvaller als doel hebben de hashwaarde Hl in de bitstream te programmeren. • A stelt algemeen het gemiddeld aantal mogelĳkheden voor die een aanvaller dient te proberen om een aanval te doen slagen. We zullen nu meerdere aanvalsscenario’s bespreken en telkens bepalen hoeveel moeite het een aanvaller kost om deze uit te voeren. We moeten eerst bepalen wanneer we een ontwerp veilig achten en wanneer niet. Dit zullen we uitdrukken in het gemiddeld aantal berekeningen of pogingen die een aanvaller moet ondernemen om de beveiliging te breken. In [10] wordt de minimum sleutellengte bepaald voor verschillende soorten tegenstanders. Om veilig te zĳn voor een individuele hacker met een budget van hoogstens 400 USD wordt een minimum sleutellengte aangeraden van 62 bits. Om veilig te 46

Veiligheid van de hash-ROM zĳn voor een grote organisatie met een budget van 10 miljoen USD wordt 78 bits aangeraden. We zullen afronden naar 80 bits om beveiligingsniveau 4 te halen zoals beschreven wordt in [10].

5.1.1

Exhaustieve aanval op W

Een eerste, inefficiënte maar eenvoudige aanval bestaat erin alle mogelĳke W waarden uit te proberen. In totaal zĳn er 2256 mogelĳke W waarden en precies één hiervan, namelĳk Wl , zal ervoor zorgen dat Hl = P (W ) omdat de permutatie een één-op-één mapping is, een bĳectie. De vorige aanval kan lichtjes verbeterd worden. Immers, een permutatie behoudt het Hamminggewicht van de waarde die gepermuteerd wordt. De aanvaller weet welke waarde hĳ de ROM als uitgang wilt laten geven, dus kent hĳ ook het Hamminggewicht van de ingang. De aanvaller dient dus enkel die waarden te proberen met hetzelfde Hamminggewicht als Hl . We zĳn geïnteresseerd in het gemiddeld aantal pogingen dat een aanvaller moet ondernemen om een zelfgekozen hashwaarde Hl in de ROM te programmeren. Aangezien we verondersteld hebben dat de hashwaarde Hl volledig uniform verdeeld is zal het Hamminggewicht van een hashwaarde Hamm(Hl ), dus het aantal bits die op 1 staan, binomiaal verdeeld zĳn. Met andere woorden, de kans dat de hashwaarde Hl precies p bits op 1 heeft staan wordt als volgt berekend: 1 P (Hamm(Hl ) = p) = Binomiaal(p, n, ) 2 ! 1 p 1 n−p n 1− = 2 2 p =

n p

! 1 p 1 n−p ! n

=

n p

2

2

1 2

(5.1) (5.2) (5.3) (5.4)

Gegeven dat de n-bit hashwaarde p bits op 1 heeft staan, wordt het aantal combinaties dat een aanvaller moet uitproberen gegeven door np . We kunnen dit nu combineren met de resultaten van vergelĳking 5.4. Het gemiddeld aantal combinaties dat een aanvaller in totaal nog dient uit te proberen wordt dan gegeven door:

A= =

n X p=0 n X p=0

n p

! 1 n

2

n! p! · (n − p)!

n p

!!

(5.5)

2 n ! 1

2

(5.6)

Voor n = 256 wordt dit: 47

5. Veiligheidsanalyse

A=

256 X p=0 251

256! p! · (256 − p)!

2 256 !

1 2

(5.7)

≥2

(5.8)

Rekening houdende met de verbeterde brute-force aanval heeft de hash-ROM dan nog een veiligheidsfactor van 251.

5.1.2

Exhaustieve aanval op P

Een aanvaller zou ook kunnen proberen een lĳst te maken van alle mogelĳke permutaties. Eén van deze permutaties zal dan P voorstellen. Voor iedere permutatie kan de bĳhorende waarde W berekend worden, die de aanvaller dan één voor één kan uitproberen. Het totaal aantal mogelĳke permutaties wordt als volgt berekend:

A = n!

(5.9)

Hierbĳ stelt n het aantal bits voor waarover gepermuteerd wordt. Met de formule van Stirling kunnen we deze waarde uitrekenen voor n = 256:

A = 256! ≥2

(5.10)

1683

(5.11)

Een aanvaller zou dus 21683 mogelĳke permutaties, en dus mogelĳke waarden W moeten uitproberen. Dit aantal kan nog gereduceerd worden aangzien een aanvaller minstens één combinatie van (W ,H) kent. Uit deze combinatie kan de aanvaller informatie afleiden over de permutatie. Een permutatie zal een bit die op 1 staat in W steeds afbeelden op een bit die ook op 1 staat in H. Het zoeken naar de juiste permutatie kan dan opgedeeld worden in twee kleinere problemen. Eerst zoekt men de permutatie van de bits die op 1 in W naar de bits die op 1 staan in H en vervolgens doet men dit voor de bits die op 0 staan. Het aantal pogingen die een aanvaller dan nog dient te ondernemen kan als volgt worden uitgerekend.

A= =

n X p=0 n X p=0

(P (Hamm(Hk ) = p) · p! · (n − p)!) ! n

n · p

1 2

= (n + 1) · n! · 2−n We werken dit nu uit voor n = 256: 48

(5.12)

!

· p! · (n − p)!

(5.13) (5.14)


Figuur 5.1: Verduidelĳking van het beperkt aantal mogelĳke permutaties bĳ de hash-ROM

A = (256 + 1) · 256! · 2−256 ≥2

1436

(5.15) (5.16)

Het is duidelĳk dat deze aanval veel meer moeite vraagt van een aanvaller dan de vorige brute-force aanval. Bĳ de vorige brute-force aanval moet een aanvaller immers slechts 2251 waarden uitproberen.

5.1.3

Geavanceerdere aanval op W

Een aanvaller kan veel tĳd uitsparen door niet alle mogelĳke W waarden uit te proberen zoals het geval is bĳ de brute-force aanval. Aangezien een aanvaller al heel wat nuttige informatie uit Hl en Wl kan afleiden hoeft hĳ een groot aantal mogelĳkheden niet meer uit te proberen. Immers, de aanvaller kent de waarden Hl en Wl en hĳ weet ook dat Hl = P (Wl ), waarbĳ P niet gekend is door de aanvaller. Het is ook zo dat er voor iedere bit die op 1 staat van Hl er een overeenkomstige bit op 1 moet staan in Wl . Zie figuur 5.1 voor een voorbeeld met slechts 6 bits. In dit voorbeeld wenst de aanvaller bit 1 van Hl de waarde 0 geven (zie onderste helft van figuur 5.1). Uit de relatie Hl = P (Wl ) weet de aanvaller dat hĳ hiervoor enkel naar bits 0,2 en 4 moet kĳken in Wl . Het wĳzigen van bits 1, 3 of 5 uit Wl zal nooit een effect hebben op bit 1 van Hl . 49

5. Veiligheidsanalyse Hk heeft een Hamminggewicht van p, dus er staan p bits op 1 in Hk en in Wk . Wanneer een aanvaller x van deze bits die op 1 staan wilt behouden en p − x van deze bits wilt veranderen in een 0 dient een aanvaller slechts te bepalen welke combinatie van x bits uit p bits voor het juiste resultaat zal zorgen. Hetzelfde dient hĳ dan te doen voor de n − p bits die op 0 staan in Hk . Indien hĳ van deze n − p slechts y bits op 1 wilt zetten en de overige n − p − y bits op 0 wilt houden dient hĳ de juiste combinatie van y bits uit n − p bits te zoeken die hiervoor zorgt. x + y is dus het Hamming gewicht van Hl . Dit wordt verduidelĳkt in figuur 5.1 en figuur 5.2. Aangezien een aanvaller niet de mogelĳkheid heeft om de correctheid van deze 2 combinaties afzonderlĳk te verifiëren dient hĳ alle mogelĳke combinaties van deze 2 combinaties uit te proberen. Het aantal pogingen die een aanvaller moet uitvoeren om een zelfgekozen hashwaarde te programmeren met Hamming gewicht x + y waarvan x bits overeenkomen met p bits uit Hk en waarvan y bits overeenkomen met n − p bits uit Hk is als volgt: !

p n−p · x y

!

p! · (n − p)! x! · y! · (p − x)! · (n − p − y)!

=

(5.17)

Om de precieze veiligheidsfactor uit te rekenen dienen we na te gaan hoe waarschĳnlĳk de precieze waarden van p, x en y zĳn. De kansverdeling van p werd reeds berekend in vergelĳking 5.4. Aangezien er verondersteld wordt dat de mogelĳke hashwaarden uniform verdeeld zĳn zullen x en y dezelfde kansverdeling als p hebben: 1 P (X = x) = Binomiaal(x, p, ) 2 ! 1 p p = x 2

(5.18) (5.19)

Volledig analoog voor P (Y = y): 1 P (Y = y) = Binomiaal(y, n − p, ) 2 ! n−p 1 n−p = y 2

(5.20) (5.21)

Door vergelĳkingen 5.4, 5.17, 5.19 en 5.21 te combineren kan het totaal aantal combinaties die een aanvaller nu nog zou moeten proberen worden berekend: n X



n  A= p p=0

! p n−p 1 nXX

2

x=0 y=0

p x

! p

1 2

! n−p

n−p y

1 2

p x

!

!!

n−p y



(5.22) (5.23) 50


Figuur 5.2: Verduidelĳking over de opdeling van de bits van de hashwaarde

Wanneer we dit uitrekenen voor n = 256 bekomen we: A ≥ 2247

(5.24)

De veiligheidsfactor van de hash-ROM wordt met deze aanval herleid tot 247. Dit is nog ruim boven onze doelstelling van 80. Het zou voor deze toepassing voldoende zĳn een hashfunctie te gebruiken die een kleinere hashwaarde geeft. Om praktische redenen hadden we echter voor Hamsi gekozen, die een 256-bit hashwaarde geeft.

5.1.4

Collusieaanval

Collusie is het fenomeen waarbĳ meerdere partĳen een overeenkomst sluiten, die vaak maar niet altĳd illegaal is, waarbĳ deze overeenkomst tot doel heeft een gemeenschappelĳk doel te bereiken dat normaalgezien niet bereikt kan worden wanneer men de toepasselĳke wetgeving volgt. Het is bĳvoorbeeld mogelĳk dat verschillende partĳen samenwerken om een groot aantal eindproducten te verzamelen. Zĳ kunnen dan zelf de hashwaarde H i berekenen voor iedere FPGA. De bĳhorende waarde W i kunnen zĳ ook uit de bitstream halen. Zĳ beschikken nu over een lĳst van (W i , H i ) paren. Wanneer ieder van deze bitstreams gegenereerd werden met dezelfde geheime permutatie dan vertelt deze lĳst van (W i , H i ) paren iets over de permutatie die gebruikt werd. Men kan vervolgens voor iedere bitpositie j een bitvector H j opschrĳven. Met j H i wordt de j-de bit bedoeld van de i-de hashwaarde. Hetzelfde doet men voor W j . 51


H j = H j0 H j1 . . . H ji−1 j

W =

W j0 W j1 . . . W ji−1

(5.25) (5.26)

Hiermee bekomt men i H j vectoren, van H 0 tot H i−1 en eveneens bekomt men i W vectoren, van W 0 tot W i−1 . Wanneer H j gelĳk is aan W k dan wilt dit zeggen dat de permutatie bit j van W afbeeldt op bit k van H. Wanneer men er in slaagt de permutatie te achterhalen is men in staat een zelfgekozen hashwaarde te programmeren in de bitstream en kan de integriteit van het ontwerp dus niet meer gewaarborgd worden. Men dient er dus op te letten wanneer men tweemaal dezelfde permutatie gebruikt voor de beveiliging van een ontwerp. Sectie 3.3.2 beschrĳft hoe de hashwaarde geprogrammeerd wordt in de hash-ROM. Het is eenvoudig bĳ iedere bitstream een nieuwe permutatie te gebruiken. Via FPGA Editor, zie sectie 2.3, kan de routering nog aangepast worden zoals in diezelfde sectie uitgelegd wordt. Een betere oplossing tegen deze collusie-aanval is de permutatie uit te voeren, niet op de hashwaarde, maar op de data die gehasht wordt, zie figuur 5.3. Hierdoor beschikken potentiële aanvallers niet meer over verschillende (W i , H i )-paren, wat hen informatie gaf over de gebruikte permutatie. Deze oplossing heeft als extra voordeel dat de hash-ROM niet meer geobfusceerd dient te worden. Een aanvaller kan immers niet meer zelf uitrekenen welke hashwaarde hĳ hierin zou moeten opslaan, omdat hĳ de data niet kent die gehasht wordt. j

5.2

Veiligheid van de programma-ROM

In deze sectie wordt aangetoond dat de implementatie voor het programmageheugen van de microcontroller, zoals voorgesteld in sectie 4.3, voldoende veilig is. De doelstelling is als volgt: • Het geobfusceerd programmageheugen krĳgt als ingang een 10-bit adres en geeft aan zĳn uitgang een 18-bit instructiewoord. • Het moet moeilĳk zĳn voor een aanvaller om de instructies die de microcontroller uitvoert te wĳzigen op een zinvolle manier. Dit wil zeggen dat het niet erg is dat het geheugen aangepast wordt op een willekeurige manier, maar een aanvaller mag niet kunnen voorspellen op welke manier zĳn wĳziging invloed zal hebben op de uitgang van het geheugen. • Bovenstaande moet gerealiseerd kunnen worden, zelfs wanneer de code die op de microcontroller zal draaien publiek is. We willen vermĳden dat een aanvaller het programma op de microcontroller kan aanpassen omdat deze dan in staat zou kunnen zĳn om het activatiesignaal te geven zonder dat beide hashwaarden overeenkomen, zie sectie 3.3. 52


Figuur 5.3: Overzicht van de beveiligingsarchitectuur. De permutatie gebeurt nu op de data die gehasht wordt.

5.2.1

Het geheim van de geobfusceerde programma-ROM

De veiligheid van de programma-ROM ligt volledig in de permutatie. Alle andere elementen zĳn volledig publiek: • De inhoud van het BlockRAM kan eenvoudig uit de bitstream gehaald worden. • De werking van de substitutie-elementen (s-box) is publiek. • De ronde-afhankelĳke rotatie is op voorhand gekend. Het is belangrĳk om ervoor te zorgen dat een aanvaller niet alle mogelĳke permutaties kan afgaan en voor iedere mogelĳke permutatie de bĳhorende BlockRAM-inhoud kan construeren en uittesten. Wanneer een aanvaller ongeveer 280 mogelĳkheden moet nagaan, veronderstellen we dat dit teveel werk is om in een realistische tĳdspanne en met redelĳke middelen uit te voeren. Hiermee kunnen we dan uitrekenen over hoeveel bits moet gepermuteerd worden: 53


p! ∼ = 280 ⇒ p = 25

(5.27)

De implementatie van de programma-ROM is eenvoudiger voor p = 24 dan voor p = 25. Met p = 24 bekomen we nog een veiligheidsfactor van 79 bits wat voor onze doeleinden nog steeds voldoende is. Omwille van deze praktische implementatievoordelen kiezen we voor p = 24.

5.2.2

Confusie en diffusie

Aangezien de structuur van de programma-ROM een rondegebaseerd substitutiepermutatie (SP) netwerk is, kunnen we hiervoor enkele standaardtechnieken gebruiken om de veiligheid in te schatten. Een eerste aspect is de zogenaamde diffusie. Diffusie betekent dat wanneer er één bit aan de ingang van een SP-netwerk wĳzigt, dat de uitgang op een onvoorspelbare manier dient te veranderen, op een willekeurige wĳze. Dit wil zeggen dat wanneer men één bit aan de ingang wĳzigt dat iedere uitgangsbit wĳzigt met een kans van 50%. Dit wordt ook het strict avalanche criterium (SAC) genoemd. Door middel van simulatie kunnen we bepalen of er voldoende diffusie aanwezig is. De simulatie werkt als volgt. Eerst wordt er een lĳst van alle mogelĳke 18-bit instructies opgemaakt. Men kiest een willekeurige permutatie en rekent hiermee de gescrambelde 24-bit waarde uit van al deze instructies. Met een permutatie bedoelen we een selectie van n elementen uit een groep van n elementen waarbĳ de volgorde belangrĳk is. Vervolgens inverteren we één bitpositie van al deze gescrambelde waarden. Door deze gewĳzigde waarden te descramblen bekomt men hopelĳk een totaal andere instructie dan waarvan men vertrokken is. We noteren voor ieder van deze 24 uitgangsbits wat de kans is dat deze bits gewĳzigd werden door een wĳziging van één bit in de gescrambelde waarde. Het is belangrĳk dat alle 24 bits met een kans van ongeveer 50% wĳzigen wanneer zelfs maar één bit aan de ingang wĳzigt. We zĳn dus geïnteresseerd in de maximale afwĳking ten opzichte van een kans van 50% voor de wĳziging van deze bits. Een grafiek van deze parameter wordt weergegeven in figuur 5.4 in functie van het aantal rondes dat uitgevoerd wordt. Uit de grafiek in figuur 5.4 kunnen we dus afleiden dat we minimaal 21 rondes nodig hebben om ervoor te zorgen dat alle bits wĳzigen met een kans 49% < P < 51% wanneer één bit aan de ingang, dus in het BlockRAM, gewĳzigd wordt. Een tweede belangrĳk aspect voor het ontwerp van een substitutie-permutatienetwerk is confusie. We zouden graag hebben dat iedere uitgangsbit van het SPnetwerk op een complexe manier afhangt van de gekozen permutatie. Wanneer een andere permutatie gekozen wordt die zeer sterk lĳkt op de originele permutatie dan dienen alle uitgangsbits met een kans van 50% te wĳzigen. We kunnen deze confusie-eigenschap controleren met simulatie, net zoals we de diffusie-eigenschap gecontroleerd hebben. We kiezen een willekeurige permutatie en we berekenen hiervoor een exhaustieve lĳst van geobfusceerde instructies. We verwisselen twee elementen uit de permutatie en we descramblen vervolgens de lĳst van instructies. We gaan na hoeveel bits uit de gedescrambelde instructies gewĳzigd zĳn ten opzichte van de originele instructies. Dit wordt weergegeven in figuur 5.5. Wanneer 21 rondes 54


Figuur 5.4: Diffusie in het programmageheugen, weergegeven door de maximale afwĳking ten opzichte van een kans van 50% voor het wĳzigen van de uitgangsbits bĳ wĳziging van slechts 1 ingangsbit

gebruikt worden is zien we dat alle bits wĳzigen met een kans 49% < P < 51% wanneer twee elementen uit de permutatie gewĳzigd worden. We besluiten dat de programma-ROM voldoende veilig ontworpen is en dat er voldoende confusie en diffusie aanwezig is.

5.2.3

Conditionele stap aanpassen

Ergens in het programma zal de berekende hashwaarde Hj vergeleken worden met Hk . Indien deze gelĳk zĳn zal een subroutine uitgevoerd worden die het activatiesignaal zal geven. Dit komt overeen met de subroutine in figuur 5.6. De COMPARE-instructie zet het ZERO-register op de waarde 1 indien de beide registers s0 en s1 gelĳk zĳn in waarde. De CALL Z -instructie voert een conditionele CALL-instructie uit wanneer het ZERO-register de waarde 1 bevat. Dit is een zeer interessante instructie voor een aanvaller, immers wanneer hĳ erin slaagt de CALL Z-instructie te veranderen in CALL NZ dan zou het activatiesignaal gegeven worden wanneer beide hashwaarden niet overeenkomen. Aangezien de CALL Z- en de CALL NZ-instructie slechts verschillen in één bit, namelĳk bit 10 [29], zou een aanvaller 55


Figuur 5.5: Confusie in het programmageheugen, weergegeven door de maximale afwĳking ten opzichte van een kans van 50% voor het wĳzigen van de uitgangsbits bĳ verwisseling van twee elementen van de permutatie

COMPARE s0,s1

; vergelijk de berekende hashwaarde (s0) ; met de opgeslagen hashwaarde (s1) CALL Z, setEnableSignal ; indien gelijk, geef het activatiesignaal Figuur 5.6: Vereenvoudigde voorstelling voor het vergelĳken van de hashwaarden

56


Figuur 5.7: Verbeterde methode voor het activatiesignaal

reeds slagen in zĳn opzet indien hĳ deze ene bit juist ingesteld krĳgt. Wegens de goede confusie- en diffusie-eigenschappen van de programma-ROM is het echter niet eenvoudig selectief één bit aan te passen in een instructiewoord. De veiligheid kan nog verhoogd worden door te eisen dat meerdere uitgangen van de microcontroller ingesteld dienen te worden vooraleer het activatiesignaal gegeven wordt. Schematisch zou het er dan uitzien zoals in figuur 5.7. Hoe de vĳf signalen, A, B, C, D en E precies verder gebruikt worden hangt af van de precieze implementatie van het vergrendelingscircuit. Circuitvergrendeling werd besproken in sectie 2.4.1. Waarom we precies vĳf activatiesignalen kiezen zal duidelĳk worden in sectie 5.2.4. Er dient nog opgemerkt te worden dat bovenstaande codevoorbeelden ervan uitgaan dat de hashwaarden slechts 8 bit lang zĳn, immers de COMPARE-instructie werkt met 8-bit operandi. In werkelĳkheid gebruiken we een 256-bit hash, wat het iets complexer maakt, maar conceptueel gebeurt hetzelfde.

5.2.4

Exhaustief zoeken naar een instructie

Een aanvaller zou exhaustief alle mogelĳke 24-bit waarden kunnen programmeren als eerste instructie in het programmageheugen. Hĳ hoopt dat de instructie na descrambling die instructie zal geven die het activatiesignaal veroorzaakt. Aangezien er vĳf activatiesignalen dienen gegeven te worden, zoals besproken in sectie 5.2.3, is het niet voldoende die instructie te vinden om één van de activatiesignalen te geven, de aanvaller moet de vĳf instructies vinden.

5

Door exhaustief alle mogelĳkheden te proberen zal een aanvaller na 224 = 2120 pogingen de correcte vĳf instructies gevonden hebben die hĳ kan programmeren op de eerste vĳf plaatsen in het programmageheugen. Echter, aangezien picoblaze-instructies slechts 18-bit lang zĳn en de overige 6 bits genegeerd worden zullen er 26 = 64 mogelĳke 24-bit waarden zĳn die dezelfde 57

5. Veiligheidsanalyse instructie zal geven na descrambling. Gemiddeld zal een aanvaller dus reeds na 5 218 = 290 pogingen de juiste vĳf instructies vinden. Moesten we slechts vier activatiesignalen gebruiken dan zou een aanvaller reeds 4 18 na 2 = 272 pogingen de vier juiste instructies kunnen achterhalen. Dit is minder dan het vooropgestelde doel van 280 pogingen, vandaar dat we gekozen hebben voor vĳf activatiesignalen. Om de veiligheid te verhogen zou men de waarde van deze 6 bits toch kunnen controleren. Indien deze bĳvoorbeeld niet allemaal op 0 zouden staan, dan weet men dat er gepoogd is de instructies aan te passen en zou men alle functionaliteit kunnen stoppen.

5.2.5

Instructies herordenen

Het is ook belangrĳk ervoor te zorgen dat een aanvaller geen instructies van plaats kan verwisselen. Een aanvaller zou bĳvoorbeeld kunnen proberen de vier instructies die het activatiesignaal geven in het begin van het programma te krĳgen. Op deze manier zou de controle van de hashwaarden overgeslagen worden. Dit kunnen we oplossen door de gescrambelde instructiewoorden te laten afhangen van het adres van de instructie. Door de XOR-operatie met het adres van de instructie, zie figuur 4.4, zal een instructie die van plaats verwisseld wordt gedescrambeld worden als een andere instructie.

58

Hoofdstuk 6

Besluit en vervolgwerk In deze thesis werd een overzicht gegeven van intellectuele eigendom en de gerelateerde problemen bĳ de bescherming van elektronische circuits. Vervolgens werden bestaande commerciële oplossingen geanalyseerd en werd een overzicht gegeven van recent wetenschappelĳk werk rond deze problematiek van hardware-IP-bescherming. We argumenteerden dat huidige oplossingen ofwel omslachtig in gebruik zĳn ofwel extra kosten veroorzaken. Er werd vervolgens het doel vooropgesteld om een eenvoudige en praktisch bruikbare IP-beveiliging te ontwerpen voor FPGA-ontwerpen. Concreet werd als doel gesteld een kopieerbeveiliging te ontwerpen voor FPGA-ontwerpen. Een bĳkomend doel was het garanderen van de integriteit van dit ontwerp. In hoofdstuk 3 hebben we een IP-beveiligingsarchitectuur voorgesteld. De belangrĳkste componenten waren de hash-ROM en de programma-ROM. De implementatie van deze componenten werd in detail behandeld in hoofdstuk 4. Onze beveiligingsarchitectuur gebruikt geen externe componenten en is dus zeer goedkoop te implementeren. De enige kost die geassocieerd kan worden met de beveiligingsarchitectuur is een kleine oppervlaktekost op de FPGA en CPU-tĳd voor de generatie van een bitstream per FPGA. We zĳn van mening dat de huidige implementatie reeds bruikbaar is voor commerciële toepassingen, maar er is nog zeker ruimte voor verbetering van de implementatie. De verschillende componenten zouden efficiënter geïmplementeerd kunnen worden om de oppervlaktekost te verlagen. Misschien kan het ontwerp efficiënter gemaakt worden door dezelfde permutatie te gebruiken voor de hash-ROM en de programma-ROM. De permutatie zou dan gedeeld kunnen worden door de hash-ROM en de programmaROM. Met een betere keuze van de s-box en van de rotatie in de programma-ROM is het misschien mogelĳk de veiligheid te verbeteren of het aantal vereiste rondes te verlagen. De programma-ROM zou nog veiliger gemaakt kunnen worden door niet alleen de instructie, maar ook het adres mee te nemen in de scramblingoperatie. Tevens zou het efficiënter zĳn een hashfunctie te gebruiken die kleinere hashwaarden levert. 256-bit is eigenlĳk teveel voor wat we nodig hadden voor onze implementatie. Het lĳkt ons mogelĳk hier een beperkte hoeveelheid veiligheid in te leveren voor een lagere oppervlaktekost. Voor de implementatie van de hash-ROM hadden we gekozen een permutatie over 256 bits te gebruiken, dit kan echter ook

59

6. Besluit en vervolgwerk met een veel kleinere permutatie zoals uitgelegd in sectie 5.1.4. In hoofdstuk 5 hebben we de veiligheid van onze IP-beveiligingsarchitectuur, meer bepaald de hash-ROM en de programma-ROM, geanalyseerd en zĳn we tot de conclusie gekomen dat deze voldoende veilig zĳn. Om een collusieaanval onmogelĳk te maken hebben we een aanpassing aan ons ontwerp voorgesteld in sectie 5.1.4. Deze aanpassing heeft als bĳkomende voordelen heeft dat een permutatie over een kleiner aantal bits volstaat en dat de permutatie niet uniek hoeft gekozen te worden per FPGA. De IP-beveiligingsarchitectuur in dit werk kan de integriteit van een FPGAontwerp garanderen. Hierdoor is het mogelĳk een publieke sleutel in dit ontwerp op te slaan. Met deze sleutel kan bĳvoorbeeld een beveiligd communicatiekanaal opgezet worden tussen de FPGA en de IP-eigenaar. Via dit beveiligde kanaal zouden bĳvoorbeeld geauthenticeerde nieuwe revisies van het FPGA-ontwerp kunnen gedownload worden. Deze nieuwe revisies zouden via partiële herconfiguratie via de ICAP-poort automatisch geconfigureerd kunnen worden op de FPGA. Dit beveiligde communicatiekanaal zou ook gebruikt kunnen worden om nieuwe licentiestrategieën uit te werken. Het zou bĳvoorbeeld mogelĳk zĳn slechts bepaalde onderdelen standaard functioneel te maken. Indien men extra componenten, bĳvoorbeeld een snellere versie, wilt gebruiken zou men een extra betaling kunnen vragen. Via het beveiligde communicatiekanaal kan dan een activeringssignaal gegeven worden aan deze component. Het zou ook mogelĳk worden te betalen per uur dat een bepaalde component gebruikt of per operatie dat deze component uitvoert in de plaats van een éénmalige betaling.

60

Bibliografie [1] Actel. Actel FPGA’s. URL: http://www.actel.com/products/devices.aspx, laatst nagekeken op 2010-05-19. [2] Actel. Application Note AC168: Implementation of Security in Actel Antifuse FPGAs. URL: http://www.actel.com/documents/Antifuse_Security_AN. pdf, laatst nagekeken op 2010-05-19. [3] Y. M. Alkabani and F. Koushanfar. Active Hardware Metering for Intellectual Property Protection and Security. 16th USENIX Security Symposium, 2007. [4] J.-P. Aumasson, L. Henzen, W. Meier, and R. C.-W. Phan. SHA-3 proposal BLAKE. Submission to NIST, 2008. [5] J.-L. Beuchat, E. Okamoto, and T. Yamazaki. Compact Implementations of BLAKE-32 and BLAKE-64 on FPGA. Cryptology ePrint Archive, Report 2010/173, 2010. http://eprint.iacr.org/. [6] R. Deazley. Rethinking Copyright. Edward Elgar Publishing, 2006. ISBN-13: 978-1845422820. [7] Y. Dodis, R. Ostrovsky, L. Reyzin, and A. Smith. Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data. SIAM Journal on Computing, 38(1):97–139, 2008. [8]

S. Drimer. Volatile FPGA design security – a survey (v0.96), April 2008.

[9] Ecrypt. The SHA-3 Zoo. URL: http://ehash.iaik.tugraz.at/wiki/The_ SHA-3_Zoo. [10] European Network of Excellence in Cryptology. Yearly Report on Algorithms and Keysizes (2008-2009), 2009. [11] European Union Legislation. Council Directive 87/54/EEC of 16 December 1986 on the legal protection of topographies of semiconductor products. URL: http://europa.eu/legislation_summaries/internal_market/ businesses/intellectual_property/l26025_en.htm. [12] J. Fan. Hardware Evaluation of The Hash Function Hamsi. 61

Bibliografie [13] M. Gora, A. Maiti, and P. Schaumont. A flexible design flow for software IP binding in commodity FPGA. In SIES, pages 211–218. IEEE, 2009. [14] J. Guajardo, S. S. Kumar, G.-J. Schrĳen, and P. Tuyls. FPGA intrinsic PUFs and their use for IP protection. In CHES ’07: Proceedings of the 9th international workshop on Cryptographic Hardware and Embedded Systems, pages 63–80, Berlin, Heidelberg, 2007. Springer-Verlag. [15] A. Kerckhoffs. La cryptographie militaire. Journal des sciences militaires, 1883. [16] Lattice. Lattice FPGA’s. URL: http://www.latticesemi.com/products/ fpga/xp2/index.cfm, laatst nagekeken op 2010-05-19. [17] R. Maes, D. Schellekens, P. Tuyls, and I. Verbauwhede. Analysis and Design of Active IC Metering Schemes. In M. Tehranipoor and J. Plusquellic, editors, HOST, pages 74–81. IEEE Computer Society, 2009. [18] Mediatronix. pBlazIDE. URL: http://www.mediatronix.com/pBlazeIDE.htm, laatst nagekeken op 2010-05-19. [19] Mentor Graphics. ModelSim. URL, http://model.com/, laatst nagekeken op 2010-05-19. [20] J. A. Roy. Protecting Bus-Based Hardware IP by Secret Sharing. Proceedings of the 45th Design Automation Conference, 2008. [21] J. A. Roy, F. Koushanfar, and I. L. Markov. EPIC: ending piracy of integrated circuits. In DATE ’08: Proceedings of the conference on Design, automation and test in Europe, pages 1069–1074, New York, NY, USA, 2008. ACM. [22] B. Sherman and L. Bently. The making of Modern Intellectual Property Law. Cambridge University Press, 1999. ISBN-13: 978-0521563635. [23] E. Simpson and P. Schaumont. Offline Hardware/Software Authentication for Reconfigurable Platforms. In L. Goubin and M. Matsui, editors, CHES, volume 4249 of Lecture Notes in Computer Science, pages 311–323. Springer, 2006. [24] G. Smith. kpicoasm, een open-source simulator voor de PicoBlaze Microcontroller van Xilinx. URL: http://www.xs4all.nl/~marksix/kpicosim.html, laatst nagekeken op 2010-05-19. [25] G. Smith. Picoasm, een open-source assembler voor de PicoBlaze Microcontroller van Xilinx. URL: http://www.xs4all.nl/~marksix/picoasm.html, laatst nagekeken op 2010-04-28. [26] R. Torrance and D. James. The State-of-Art in IC Reverse Engineering. CHES, 2009. 62

Bibliografie [27] P. Tuyls and B. Škorić. AmIware: Hardware Technology Drivers of Ambient Intelligence, chapter Secret Key Generation from Classical Physics., pages 421–447. Philips Research Book Series. Springer, 2005. [28] I. Week. Operation ’Cisco Raider’ Nets 76 Million In Fake Gear. URL: http://www.informationweek.com/news/personal_tech/showArticle. jhtml?articleID=206901053, laatst nagekeken op 2010-04-13. [29] Xilinx. Picoblaze 8-bit embedded microcontroller user guide. URL: http://www. xilinx.com/support/documentation/ip_documentation/ug129.pdf, laatst nagekeken op 2010-05-03. [30] Xilinx. Spartan-3AN FPGA Family Data Sheet. [31] Xilinx. Virtex-5 FPGA Configuration User Guide. [32] Xilinx. Virtex-5 User Guide. [33] Xilinx. Xilinx Application Note 780, FPGA IFF Copy Protection Using Dallas Semiconductor/Maxim DS2432 Secure EEPROMs. [34] Xilinx. Xilinx constraints guide. URL: http://www.xilinx.com/support/ documentation/sw_manuals/xilinx11/cgd.pdf, laatst nagekeken op 2010-0429. [35] Xilinx. Xilinx FPGA Editor Software. URL: http://www.xilinx.com/itp/ xilinx6/help/fpga_editor/fpga_editor.htm, laatst nagekeken op 2010-0429. [36] Xilinx. Xilinx Technical Whitepaper 266: Security Solutions Using Spartan-3 Generation FPGAs. [37] Özgül Küçük. The Hash Function Hamsi. Submission to NIST (updated), 2009.

63

Goedkope bescherming van intellectuele eigendom in FPGA-configuraties

Recommend Documents