Optimalisatie van een trusted state voor een gedistribueerd logging concept. Bart Sallaerts

Optimalisatie van een trusted state voor een gedistribueerd logging concept ¨ ¨ Ozer Unal Bart Sallaerts 27 december 2012

Voorwoord Wanneer ons gevraagd werd om een masterproef uit te kiezen was onze keuze snel gemaakt. Het gedistribueerde logging concept was iets dat we beiden interessant vonden en een mogelijkheid om ons hier meer in te verdiepen was mooi meegenomen. Een andere reden was dat we te weinig vertrouwd waren met de hardware beschrijvende taal VHDL en dit dan een ideaal leerplatform was. Buiten een paar zeer irritante foutjes, die volledig onze schuld waren, viel het werken aan deze masterproef goed mee. We hebben veel bijgeleerd. Niet alleen qua technische vaardigheden maar ook het werken met twee personen aan één project, alsook het werken met deadlines en het belang van mijlpalen opstellen. Dit zou natuurlijk helemaal niet mogelijk zijn zonder de hulp van onze promotoren en docenten. Graag zouden we dan Ing. Jo Vliegen willen bedanken voor al zijn hulp. Dr. Karel Wouters willen we bedanken voor het mogelijk maken van deze masterproef. Ook willen we Dr. Ir. Nele Mentens bedanken voor al de uitleg die ze ons gegeven heeft.

INHOUDSOPGAVE

Inhoudsopgave Lijst van tabellen

4

Lijst van tabellen

4

Lijst van figuren

5

Lijst van figuren

5

Verklarende Woordenlijst

6

Abstract

7

Summary

8

Inleiding

9

1 Logging 1.1 Waarom logging? . . . . . . . . . . . . . 1.2 Gedistribueerd loggen . . . . . . . . . . . 1.3 Privacy . . . . . . . . . . . . . . . . . . . 1.4 De scheme . . . . . . . . . . . . . . . . . 1.5 Het softwarematig logging principe . . . 1.6 Verbeterd logging concept met hardware

. . . . . .

. . . . . .

2 Trusted state 2.1 Inleiding . . . . . . . . . . . . . . . . . . . . 2.2 Trusted state component . . . . . . . . . . . 2.3 Onderdelen van het trusted state component 2.3.1 MicroBlaze . . . . . . . . . . . . . . 2.3.2 Passthrough memory . . . . . . . . . 2.3.3 AES . . . . . . . . . . . . . . . . . . 2.3.4 ECC µP . . . . . . . . . . . . . . . . 2.3.5 SHA256 . . . . . . . . . . . . . . . . 2.3.6 RNG . . . . . . . . . . . . . . . . . . 2.3.7 Trusted state memory component . . 2.3.8 FSM . . . . . . . . . . . . . . . . . . KHLim

Departement IWT

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . .

9 9 9 10 11 12 14

. . . . . . . . . . .

16 16 16 17 17 18 18 21 23 24 25 25 2

2.4

Trusted state component API 2.4.1 Create processor state 2.4.2 Create subject state . 2.4.3 Create entry . . . . . . 2.4.4 Delete state . . . . . . 2.4.5 Get state . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

25 25 26 26 27 27

. . . . . . . . . . . . . . . . . . . . . .

29 29 29 30 31 31 31 32 32 32 33 34 34 35 36 36 36 37 37 37 37 38 39

4 Vastgestelde problemen 4.1 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 DCM en AES-buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42 42 45

5 Besluit

48

3 Performantie verbeteren 3.1 Analyseren van de oorspronkelijke performantie . . . . . . . 3.2 Zoeken van de bottleneck . . . . . . . . . . . . . . . . . . . . 3.2.1 Meten van acties . . . . . . . . . . . . . . . . . . . . 3.2.2 Kritisch pad zoeken . . . . . . . . . . . . . . . . . . . Wat is een kritisch pad? . . . . . . . . . . . . . . . . Waar ligt het kritisch pad? . . . . . . . . . . . . . . . 3.3 Mogelijke oplossingen . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Paralleliseren . . . . . . . . . . . . . . . . . . . . . . CreateProcessor parallel flowchart . . . . . . . . . . . CreateSubject parallel flowchart . . . . . . . . . . . . CreateEntry parallel flowchart . . . . . . . . . . . . . DeleteState flowchart . . . . . . . . . . . . . . . . . . GetState flowchart . . . . . . . . . . . . . . . . . . . 3.3.2 Verplaatsen van microblaze naar vhdl . . . . . . . . . 3.3.3 Kritische paden wegwerken . . . . . . . . . . . . . . . 3.3.4 Optimaliseren van componenten . . . . . . . . . . . . 3.4 Implementaties en hun performance gain . . . . . . . . . . . 3.4.1 CheckExisting functie . . . . . . . . . . . . . . . . . CheckExisting functie - Origineel . . . . . . . . . . . CheckExisting functie - Verbetering . . . . . . . . . . CheckExisting functie - Overzetten naar trusted state 3.4.2 AES kritisch pad . . . . . . . . . . . . . . . . . . . .

Appendix: A Bibliografie

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . .

i ii

Lĳst van tabellen 3.1 3.2 3.3 3.4 3.5

Prestaties HW vs SW . . . . . . . . . . . . . . . . . . . . Tijden voor bepaalde acties . . . . . . . . . . . . . . . . Prestaties na verbetering . . . . . . . . . . . . . . . . . . Prestaties na overzetten naar FSM . . . . . . . . . . . . Prestaties van cryptocore met oude AES vs nieuwe AES

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

29 30 38 39 40

Lĳst van figuren 1.1 1.2 1.3

Principe gedistribueerde logging . . . . . . . . . . . . . . . . . . . . . . . . . Blokschema van de softwarematige logserver . . . . . . . . . . . . . . . . . . State hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 13 14

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

Het totale systeem op de fpga . . . . . . Addroundkey . . . . . . . . . . . . . . . Subbytes . . . . . . . . . . . . . . . . . . Shiftrows . . . . . . . . . . . . . . . . . . Mixcolumns . . . . . . . . . . . . . . . . 4x4 matrix voor mixcolumn bij encryptie 4x4 matrix voor mixcolumn bij decryptie Cipher Block Chaining . . . . . . . . . . Elliptische curve cryptografie adding . . Elliptische curve cryptografie doubling . Pseudo-random number generator . . . . Flowchart microblaze . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

17 18 19 19 19 20 20 20 22 23 24 28

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Pipelining principe . . . . . . . . . Parallel versie van CreateProcessor Parallel versie van CreateSubject . Parallel versie van CreateEntry . . Parallel versie van DeleteState . . . Parallel versie van GetState . . . . Flowchart verbeterde AES . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

31 32 33 34 34 35 40

4.1

AES flowchart met ILA componenten . . . . . . . . . . . . . . . . . . . . . .

45

. . . . . . .

. . . . . . .

. . . . . . .

Verklarende Woordenlijst

Abstract Eén van de vele projecten van de Embedded-Systems afdeling van ACRO in Diepenbeek, gaat over gedistribueerd loggen. Omdat dit project ge¨ımplementeerd is in software, willen ze deze een stuk veiliger maken door het te versterken met hardware. Het probleem is dat de hardware versterkte versie trager is dan de software versie. Deze masterproef heeft twee doelen die behaald moeten worden. Het opsporen van de bottleneck en deze wegwerken. De hardware versie moet minstens even snel zijn als de software versie. De proof-of-concept versie van de hardware variant is gemaakt met een FPGA waarin een MicroBlaze micro-processor draait. De verschillende componenten die zich in deze FPGA bevinden zijn geoptimaliseerd voor oppervlakte i.p.v. snelheid. Deze componenten worden dan aangepast en geanalyseerd of het voldoet aan de eisen. Na het analyseren zien we dat er verscheidene bottlenecks zijn. Door een kritisch pad dat te groot is, wordt de klokfrequentie van het gehele hardware blok omlaag getrokken. Er wordt ook veel tijd verloren door de interface tussen de verschillende hardware componenten. Na het oplossen van deze bottlenecks constateren we dat vier van de vijf API commands even snel zijn als de software versie. Eén command is nog altijd trager omdat we hier te veel tijd verliezen met inlezen en uitlezen van de data.

Summary One of the many projects of the Embedded-Systems departement of ACRO in Diepenbeek, is about distributed logging. This design is implemented in software. To increase the safety and privacy, this design is being hardware strengthened. The problem now is that the hardware strengthened version is slower than the software version. In this thesis we have two goals. To locate the bottleneck and remove it. The hardware version must be atleast as fast as the software version. A proof-of-concept of the hardware version has been made in an FPGA with a MicroBlaze micro-processor. The different components that are situated in the FPGA are optimized for area instead of speed. This means that, altough the components are small, the speed is very low. These components will be modified and analyzed to verify that the demands are met. After analysis we have seen that there is more then one bottleneck. One of these is a critical path in one of the components, that reduces the maximum clock frequency of the entire hardware block. There is also alot of time wasted in the interface between the various hardware components. After relieving the design of these bottlenecks, we realize that only four of the five API commands are as fast as the software version. One command is still slower because alot of time is being wasted with the reading and writing of the data.

Inleiding In de virtuele wereld wordt er meer en meer persoonlijke data van gebruikers opgeslagen. Dit gebeurd onder andere door online service providers zoals bv. facebook en google. De gebruikers van deze diensten veronderstellen dat hun privacy gerespecteerd wordt en er niets met hun data gebeurd. Echter zijn online diensten in het verleden al meermaals slachtoffer geweest van hackers. Wachtwoorden, rekeningnummers en fotos zijn enkele van de vele voorbeelden die open en bloot gesteld worden door deze kwaadwilligen. Een manier om na te gaan wat er met de data gebeurd is om alle acties te loggen. Er moet dan worden bijgehouden wie iets veranderd en wat er veranderd is of wie toegang gekregen heeft. De bedoeling is dan dat de aanbieder van de dienst weet wat er gebeurd en actie kan ondernemen. Ook kunnen deze logbestanden publiek gemaakt worden zodat de gebruikers zelf kunnen controleren of alles naar wens verloopt. Dit schept vertrouwen en zorgt voor een veiligere online ervaring. Deze logging gebeurd tegenwoordig softwarematig en heeft hierdoor enkele nadelen ten opzichte van een hardwarematige versie. Enerzijds is een softwarematige versie minder veilig omdat er makkelijker toegang tot verkregen kan worden door kwaadwilligen. Anderzijds is het relatief traag onder meer door de rekenintensieve bewerkingen die gedaan moeten worden. In deze thesis maken we een hardwarematige versie die deze nadelen aanpakt. Zowel de veiligheid maar vooral de snelheid worden verbeterd. Dit systeem maakt tevens gebruik van het gedistribueerd logging principe.

Hoofdstuk 1. Logging

Hoofdstuk 1 Logging 1.1

Waarom logging?

Logging is een concept dat in leven werd geroepen, omdat het een vereiste werd in grotere stukjes code. Wanneer een systeem operationeel is, waarin zich een fout voordoet, moet je de fout zo snel mogelijk weten op te lossen. Je hebt namelijk de luxe niet om het systeem uit te zetten en er uitbundig testen op uit te voeren met een debugger. Ook zal het werken met een function/method trace nutteloos zijn. Weten welke functie opgeroepen werd is niet genoeg. Je moet exact weten welke parameters er werden meegegeven en welke return waarde werd teruggegeven om de fout te kunnen reproduceren. Daarom begon men te werken met datalogging. Dit is dan een soort van tijdlijn van alle ondernomen acties in een chronologische volgorde. Alles dat de maken heeft met de fout werd dan opgeschreven en kan men dan ook gebruiken om het zo snel mogelijk op te lossen. Deze logs helpen ook met het opsporen van onregelmatigheden. Dit zijn zaken waar men niet op rekent en de efficientie van uw systeem kan verlagen. Alhoewel dit de reden is waarom datalogging in het leven werd geroepen, begon men het ook te gebruiken voor andere zaken. Het oplossen van eventuele fouten werd een mooi meegenomen pluspunt en het eigenlijk doel werd het verzamelen van de ondernomen acties. Facebook en dergelijke maken hier bijvoorbeeld gebruiken van. Het spreekt voor zich dat wanneer al deze data zich op éé plaats bevindt, dat er zich problemen zouden kunnen voordoen.

1.2

Gedistribueerd loggen

Het gebruiken van gedistribueerde systemen vindt zijn oorsprong in de eerste operating system architecturen. De eerste algemeen aanvaarde gedistribueerde systemen zijn de Local-Area Networks zoals Ethernet dat werd uitgevonden in de jaren 1970. Er zijn twee hoofdredenen om gebruik te maken van een gedistribueerd logserver. Ten eerste, kan het zijn dat een vereiste is dat de server kan communiceren met andere servers. Bijvoorbeeld omdat data gegenereerd in één systeem, nodig kan zijn in het andere. Ten tweede, kan het wel zijn dat men toekomt met één server, maar is het veel voordeliger KHLim

Departement IWT

9

Hoofdstuk 1. Logging om te werken met meerdere servers omwille van praktische redenen. Het kan bijvoorbeeld kost-efficiënter zijn om te werken met een cluster van meerdere low-end servers, i.p.v. één high-end server. Het kan betrouwbaarder zijn dan een niet-gedistribueerd server omwille van het feit dat je single point failures (fouten die de hele systeem doen inklappen) uitsluit. Ook zijn deze veel makkelijker om uit te breiden indien men dit nodig heeft. Alle acties die dus ondernomen worden, zullen verspreid opgeslagen worden in de verschillende logservers. Er is dus een speciale methode voor nodig om ervoor te zorgen dat men weet, welke stukjes data bij mekaar hoort. Hoe dit in zijn werk gaat, wordt verder in detail uitgelegd.

1.3

Privacy

Tegenwoordig maken de mensen meer en meer gebruik van online services zoals onder andere facebook en google. Deze twee bedrijven gaan we als voorbeeld nemen. Beide vertrouw je je persoonlijke data en gegevens toe. Men verwacht dat zulke grote bedrijven je privacy respecteren, maar hoe kan je dat bewijzen of nagaan? Stel je gebruikt gmail als e-maildienst. Al je e-mails worden op een server opgeslagen en zijn onderhevig aan kwaadwillige gebruikers. Je wilt niet dat deze e-mails door hackers of personeel van google bekeken kunnen worden. Dit moet beveiligd zijn en alle toegang moet gelogd worden. Google heeft een logging systeem dat open is naar de gebruiker toe. Wanneer er ongewone activiteit op je gmail account is wordt dit opgemerkt en aan je gemeld. Deze soort van logging schept vertrouwen bij de klanten. Een ander voorbeeld is facebook die een hoop persoonlijke gegevens van de gebruiker bezit waaronder hun fotos. Je wilt niet dat deze fotos gebruikt worden in advertenties of door onbevoegden bekeken worden. Hier is echter geen open communicatie naar de gebruiker toe. De gebruiker kan geen ongewone activiteit opmerken. Op internet heerst dan ook een negatief gevoel omtrend de privacy van de facebookgebruikers. Het is duidelijk dat privacy op de eerste plaats staat. Ons hardware component moet hier dan ook rekening mee houden. Men kan het vermogenverbruik van de fpga meten, de tijd opnemen die de fpga nodig heeft voor bepaalde instructies en nog tal van andere aanvallen. Hierdoor kan je bv een patroon herkennen in de data zonder de data te begrijpen. Stel dat een patient zich wekelijks aanmeld in het ziekenhuis voor een scan. Dan kan iemand in de log bestanden zien dat bepaalde data wekelijks voorkomt. Ook kan door middel van tijdsmetingen de plaats van deze data in het geheugen gevonden worden. Dit is privacy gevoelige informatie en dient voorkomen te worden. Bij de implementatie van bepaalde componenten zullen wij in deze thesis dan ook vermelden welke maatregelen wij hebben getroffen om de privacy te garanderen.

KHLim

Departement IWT

10


1.4

De scheme

Hoe dit allemaal gemplementeerd wordt, wordt hieronder beschreven. De data processor (service provider) verzamelt data (acties die uitgevoerd werden) van een data subject (gebruiker) en stuurt deze naar een log server zodat de server deze kan loggen. De log server zal niet op 1 fysieke plaats staan, maar verdeeld over meerdere servers. Dit is dus een gedistribueerde log server. Dit wordt duidelijk gemaakt in fig. 1.1.

Figuur 1.1: Principe gedistribueerde logging Een data subject voert een actie uit die gelogd moet worden. De data processor stuurt informatie van het data subject naar de log server. Op de log server wordt een log entry gemaakt en meta-data wordt gegenereerd om deze entries te linken in twee kettingen. Enerzijds voor de data subject en anderzijds voor de data processor. Naderhand kan de gebruiker de kettingen die betrekking hebben op hem, na maken. Dit op voorwaarde als hij de correcte geheime sleutel heeft. Om dan nog eens de inhoud te kunnen bekijken zal hij nog een tweede private sleutel nodig hebben. Soms zijn verschillende instanties betrokken bij het verwerken van data. Dus zijn er log servers die op verschillende plaatsen staan, maar toch moet er communicatie tussen deze servers plaatsvinden op een veilige manier. Hoe dit in zijn werk gaat wordt door het volgende stappen voorbeeld duidelijk gemaakt. 1. Het data subject voert een actie uit die gelogd moet worden. Data processor 1 kiest de dichtstbijzijnde log server. In dit geval is dat log server 1. 2. De volgende actie wordt door data processor 2 uitgevoerd. Die zijn dichtstbijzijnde log server is log server 2. Dan wordt er op deze server een log entry gemaakt. 3. Nu moeten beide log servers op een veilige manier gelinkt worden. Daarom wordt er gebruik gemaakt van een symmetrische sleutel. Log server 2 heeft een andere sleutel dan log server 1. Log server 2 zal die sleutel delen met log server 1 via de data KHLim

Departement IWT

11

Hoofdstuk 1. Logging processors. In log server 1 wordt een speciale entry gemaakt die verwijst naar log server 2. 4. Bij het reconstrueren van de log trail zal in log server 1 de speciale entry tegengekomen worden. Daarin staat de verwijzing naar de sleutel van log server 2. Daar wordt de log trail verder afgewerkt.

1.5

Het softwarematig logging principe

Vanaf nu zullen we refereren naar de gebruiker als de data subject, en naar de service provider als de data processor. De data processor zal data van een data subject beginnen verzamelen en de log server gebruiken om deze handelingen, uitgevoerd op die data, op te slaan. Een essentile component voor deze hele gebeuren is de state component. Deze bestaat uit een set van data velden voor elke data subject en elke data processor. Een state component wordt bijgehouden door de log server zoals gezien in fig. 1.2.

KHLim

Departement IWT

12


Figuur 1.2: Blokschema van de softwarematige logserver Waneer een log server nu een log event genereert voor een data processor die data aan het loggen is over een data subject, zal de data en de meta-data aan mekaar gelinkt worden. Er worden kettingen gemaakt voor de gebruiker en een voor de service provider. Achteraf kan de gebruiker de ketting heropbouwen door gebruik te maken van de meta-data die de log server toegevoegd heeft. Deze metadata is gebaseerd op een met de gebruiker gedeelde geheime sleutel. De log entries zijn op zo een manier gemaakt dat ze niet verwijsbaar zijn naar de gebruiker. Dit wordt bekomen door cryptografische versleuteling. Deze entries bevatten de volgende gegevens : • Subject identifier chain IC(S); • Subject data chain DC(S); • Processor identifier chain ID(P); KHLim

Departement IWT

13

Hoofdstuk 1. Logging • Processor data chain DC(P); • Authentication Key AK; • Data Deze gegevens zijn enkel toegankelijk voor entiteiten die beschikken over volgende items : • De correcte geheime sleutel die gebruikt wordt om de metadata te genereren; • De priv sleutel om de inhoud van de log entry te decoderen. De regels van het concept leggen op dat de log server de huidige waarde van de geheime gedeelde sleutel onherstelbaar overschrijft met zijn hashwaarde. Dit moet elke keer gebeuren als er een nieuwe log entry voor dezelfde gebruiker aangemaakt wordt. Dit wordt duidelijk gemaakt in fig. 1.3.

Figuur 1.3: State hashing

1.6

Verbeterd logging concept met hardware

Het logging systeem hierboven is volledig softwarematig. Dit geeft enkele problemen : • Het is relatief makkelijk om toegang te krijgen tot software en om data aan te passen. KHLim

Departement IWT

14

Hoofdstuk 1. Logging • Alhoewel de data encrypted is en dus geen betekenis heeft voor de log server, kan je wel patronen herkennen. Als een patient zich elke dag moet aanmelden voor een chemokuur dan kan je in de logs zien dat een data subject zijn data aangepast wordt. Uit dat patroon kan je uitmaken dat deze persoon een chemokuur moet volgen. Dit mag dus niet gebeuren. Daarom wordt het state component volledig in de hardware gestopt. Dit maakt het ook een heel stuk moeilijker om de data te beinvloeden omdat je niet zo makkelijk toegang kunt krijgen tot een fpga in tegenstelling tot software. Daarnaast brengen we alle rekenintensieve onderdelen over naar de hardware omdat hierin berekeningen veel sneller gaan. De data processor communiceert met de log server. Enkel de log server kan ons hardware component aanspreken. In dit hardware component wordt de toestand van het data subject en de data processor opgeslagen in het geheugen (BRAM). De data processor stuurt data naar de log server. De log server geeft dan bv een commando aan het hardware component om de toestand van een data subject aan te passen. Het hardware component zal dan een antwoord geven wanneer dit voltooid is. Dit vereist dus een aanpassing aan de api van de log server. De hardware wordt met 5 commandos aangestuurt, en zal enkel op deze commandos reageren. • InitialiseProcessorIdentifier - Initialiseert een processor identifier in de state van de logserver. • InitialiseSubjectIdentifier - Initialiseert een subject identifier in de state van de logserver. • CreateEntry - Creëert een entry voor de log, dit resulteert in een update van de trusted state. • EndEntityIdentifier - Verwijderd de entry voor de identifier in de state. • GetStateIC - Dit laat de log server toe om de inhoud van de trusted state te lezen. Dit is vereist om een auditeerbaar systeem te voorzien.

KHLim

Departement IWT

15

Hoofdstuk 2. Trusted state

Hoofdstuk 2 Trusted state 2.1

Inleiding

Dit project omvat een trusted state logging component ter vervanging van een softwarematige versie. Deze hardware wordt gebruikt door een log server met als gevolg dat de hoeveelheid vertrouwen dat nodig is in deze laatste verminderd wordt. Het hardware component dat in deze thesis besproken wordt zorgt voor een vertrouwde toestand oftewel een trusted state door aan volgende voorwaarden te voldoen : • Alle verwerking moet op dit extra hardware component gebeuren waarvan de informatie niet toegankelijk mag zijn voor de log server. Dit zorgt voor bijkomende beveiliging van het component. • Zo weinig mogelijk toegang verlenen aan operaties op de trusted state zodat de log server die dit hardware component gebruikt nog steeds de rol vervult als log server. Dit component mag dus de rol van de log server niet benvloeden. • Voorkomen dat de log server informatie over de data subject te weten kan komen. De log server mag niet weten wie en wat er gelogd wordt. Dit heeft extra privacy beveiliging tot gevolg. Het trusted state component verwerkt dus alle data en gebruikt hierbij MAC, hash functies en AES encryptie. De data die van dit component naar de log server gestuurd wordt heeft bijgevolg voor deze laatste geen enkele betekenis. Deze data is enkel te reconstrueren met behulp van een key die in het bezit is van de persoon die gelogd wordt. Er is moeilijker toegang te verkrijgen tot een hardware component ten opzichte van een softwarematige versie. Dit alles zorgt voor een zeer veilig logging concept.

2.2

Trusted state component

Figuur 2.1 geeft een beeld van hoe het totale systeem er uit ziet.

KHLim

Departement IWT

16


Figuur 2.1: Het totale systeem op de fpga De communicatie tussen de logserver en het hardware component gebeurd via ethernet. Om die reden hebben we ook de microblaze nodig die het ethernet pakket inleest. De microblaze zet de data van het pakket dan op de juiste plaats in het geheugen.

2.3 2.3.1

Onderdelen van het trusted state component MicroBlaze

De microblaze is een embedded softcore processor, met een RISC (Reduced Instruction Set Computer) architectuur, ontworpen voor Xilinx FPGAs. Softcore wilt zeggen dat deze er niet eigenlijk in zit, maar er in wordt geprogrammeerd. Deze bevindt zich dus volledig in het deel van configureerbare logica in de FPGA’s. De hardgebakken versie van een microblaze, is de PowerPC. De PowerPC zit in de FPGA en is niet te verwijderen. Het verschil tussen deze twee, zit in het feit van hoeveel je nu exact nodig hebt. De PowerPC is vast en kan niet gewijzigd worden. Dit kan als nadeel hebben dat je voor uw project een te grote microprocessor gaat hebben. De microblaze daarentegen kan zo ontworpen worden zodat het exact de nodige hoeveelheid plaats inneemt. Zo kan je kiezen hoeveel general purpose registers je nodig hebt, of je flash gaat gebruiken en of je UART nodig hebt. In ons project dient de microblaze als interface tussen de logserver en de trusted state. De logserver zal commando’s sturen naar de microblaze in de vorm van ethernet pakketten. De microblaze zal dan op zijn beurt deze packetten ontleden en de nodige instructies doorsturen naar de trusted state. De trusted state zal dan een van zijn hardware componenten starten. Nadat de trusted state gedaan heeft met berekenen zal hij aan de microblaze laten weten dat hij gedaan heeft. De microblaze zal dan zelf een ethernet pakket opstellen en deze opsturen naar de logserver om te laten weten dat hij gedaan heeft. Voor de test versie zal de microblaze ook nog via de UART (serieële poort) laten zien hoeveel cycli de verschillende functies in beslag nemen.

KHLim

Departement IWT

17


2.3.2

Passthrough memory

Het passthrough memory is een geheugen blok opgebouwd uit BRAMs (Block Random Acces Memory). De BRAM controller hiervan heeft twee poorten. Poort A is voor de microblaze, zodat deze de ontvangen data, van de logserver, kan schrijven in de passthrough. Hierna zal de trusted state door middel van poort B deze data kunnen lezen, gebruiken en daarna opnieuw schrijven in de passthrough met behulp van poort B. Hierna zal de microblaze, door poort A, de data van de trusted state kunnen lezen. Daarna zal hij zijn pakketten opstellen om door te sturen naar de logserver. Omdat we werken met ’dual controlled BRAMs’ is het heel belangrijk dat we niet gelijktijdig proberen te schrijven, of proberen te schrijven en lezen, van hetzelfde adres. Het passthrough memory is 32-bit * 511 groot. Dat wilt zeggen dat we 16352 bits, of 2044 bytes, kunnen schrijven in het passthrough memory. Meer als genoeg voor wat we nodig hebben.

2.3.3

AES

AES, Advanced Encryption Standard, is een encryptie algoritme voor elektronische data. Het werd eerst Rijndael genoemd, naar de 2 mensen die het algoritme hadden uitgevonden: Joan Daemen en Vincent Rijmen. De voorganger was de DEC, Data Encryption Standard. De reden dat DEC niet meer gebruikt wordt, is omdat de keys bij DEC maar maximaal 56 bits kunnen zijn. Deze kunnen heel gemakkelijk gekraakt worden met een ’brute force attack’. Dit is een soort aanval waarbij ze systematisch elke mogelijkheid afgaan. Bij AES zijn de keys 128-, 192- of 256-bit. Het is dus duidelijk dat alleen op vlak van encryptie de AES al veel beter is, ook is deze veel efficiënter en sneller. De AES werkt als volgt: je hebt eerst je key expansion nodig. Deze zal de 128-bit sleutel bijvoorbeeld uitbreiden naar tien 128-bit sleutels omdat bij een 128-bit sleutel er 10 rondes nodig zullen zijn. Je hebt dan nog de keuze om deze ’on the fly’ te verwerken of niet. Dit wilt zeggen dat wanneer je aan het versleutelen bent, je gelijkertijd de keys uitbreid om zo weinig mogelijk tijd te verliezen. Na de key expansion zal je 4 hoofdblokken nodig hebben om de AES standaard te bekomen, namelijk:

Figuur 2.2: Addroundkey In de addroundkey stap, wordt de roundkey gecombineerd met de data. Voor elke ronde KHLim

Departement IWT

18

Hoofdstuk 2. Trusted state wordt er een roundkey gebruikt, die we hebben verkregen door te sleutel uit te breiden. Deze roundkey wordt gecombineerd met de data door een bitgewijze XOR te gebruiken.

Figuur 2.3: Subbytes In de subbytes stap, zal elke byte in de data-matrix vervangen worden door een sub-byte door gebruik te maken van een 8-bit subsitution-box, de Rijndael S-box. Deze stap zorgt voor de niet-lineariteit in de encryptie standaard. Om aanvallen gebaseerd op simpele algebra¨ısche eigenschappen te voorkomen, wordt de S-box voor encryptie gemaakt door de vermenigvuldigbare inverse functie gevolgd door een ’affine transformation’. Voor decryptie wordt de S-box gemaakt door de ’inverse affine transformation’ gevolgd door een vermenigvuldigbare inverse functie.

Figuur 2.4: Shiftrows De shiftrows stap zal, zoals de naam doet vermoeden, werken met rijoperaties. Systematisch zullen de rijen met een bepaalde, voorop afgesproken, offset verschuiven. De eerste rij zal ongewijzigd blijven. De tweede, derde en vierde rij zullen respectievelijk verschuiven met een offset van één, twee en drie. Deze stap en de subbytes stap zijn commutatief. Dat wilt zeggen dat het niet uitmaakt in welke volgorde je deze twee uitvoert. Bij encryptie wordt er naar links geschoven, bij decryptie naar rechts.

Figuur 2.5: Mixcolumns De mixcolumns stap zal een kolom operatie uitvoeren. De vier bytes van elk kolom worden gecombineerd door een inverteerbare lineaire transformatie. De mixcolumns functie heeft KHLim

Departement IWT

19

Hoofdstuk 2. Trusted state vier bytes als ingang en vier bytes als uitgang. Elke byte aan de ingang heeft invloed op de vier uitgang bytes. Samen met de shiftrows, zorgt de mixcolumns ervoor dat er diffusie zit in het cijfer. Dit wilt zeggen, dat als één bit verandert in de verzonden boodschap, de versleutelde boodschap compleet anders zal zijn. In deze stap zal elk kolom vermenigvuldigd worden met de gekende matrix:

Figuur 2.6: 4x4 matrix voor mixcolumn bij encryptie De vermenigvuldiging operatie is gedefinieerd als volgt: een vermenigvuldiging met één wilt zeggen geen verandering, vermenigvuldiging met twee wilt zeggen naar links schuiven en vermenigvuldigen met drie wilt zeggen dat er naar links wordt geschoven alsook een XOR met de initiële waarde. Na het schuiven, moet er nog een conditionele XOR uitgevoerd worden met de waarde 0x1B als de meest beduidende bit een ’1’ is. Voor decryptie moeten we een andere matrix gebruiken. Zie fig 2.7. De berekeningen van deze matrix staan in hoofdstuk 5.

Figuur 2.7: 4x4 matrix voor mixcolumn bij decryptie In ons project, wordt het AES component in CBC (cipher block chaining) geschakeld. Dit omwille van het feit dat, alhoewel de sleutel maar 128-bit is, de data meer dan 128-bit is. Met CBC zorgen we ervoor, dat we niet voor elk stukje 128-bit data een nieuwe sleutel genereren maar dezelfde sleutel gebruiken.

Figuur 2.8: Cipher Block Chaining KHLim

Departement IWT

20

Hoofdstuk 2. Trusted state Zoals te zien op 2.8 kunnen we dan, drie keer 128-bit data versleutelen met dezelfde sleutel. Er moet wel een verschil gemaakt worden tussen de initiële encryptie of decryptie stap, en de daarop volgende. Bij de eerste stap moet namelijk nog de data geXORed worden met de initialisatie vector. Bij de volgende stappen moet de data geXORed worden met de uitgang van de vorige stap.

2.3.4

ECC µP

Bij Elliptic Curve Cryptography (ECC) wordt er gebruik gemaakt van twee sleutels, een publieke en een private sleutel. Hoe dit systeem werkt kan je het beste vergelijken met een brief sturen. Iedereen heeft je adres, dus je publieke sleutel. Iedereen kan dus een brief naar uw adres sturen. Maar alleen jij kan je brievenbus openen omdat alleen jij de sleutel hebt, dus de private sleutel. In de cryptocore gebruiken we de ECC voor Signature generation en point multiplication. Deze nemen heel veel tijd in beslag. Om dit uit te leggen moeten we eerst begrijpen wat deze modes doen. Elliptic curve cryptography wordt gebruikt voor public-key cryptography met behulp van een elliptische kromme op een eindig veld. Niet alle elliptische krommes zijn geschikt voor cryptografie. Er zijn een aantal beschikbaar gesteld die hiervoor geschikt zijn. Naast een kromme heb je ook een generatorpunt nodig dat op de kromme ligt en een random getal dat we een scalar noemen. Met behulp van het generatorpunt en de scalar kunnen we een public key genereren. Puntvermenigvuldiging wordt bekomen door twee basis operaties. Ten eerste, punt optelling. Figuur 2.9 stelt dit grafisch voor. Hier telt men twee punten, j en k, op. Deze liggen op een elliptische kromme. Als je een lijn door deze punten trekt kruis je de elliptische curve op een bepaald punt -L. De spiegeling op de x-as van dit punt geeft het punt L. Dit punt is het resultaat van de optelling. K mag niet gelijk zijn aan -J. Dan krijg je een punt op oneindig wat rechts afgebeeld staat. Ten tweede, punt verdubbeling. Figuur 2.10 stelt dit grafisch voor. Stel we hebben het punt J. Als J niet gelijk is aan nul, dan zal de tangens van punt J op precies n punt snijden met de elliptische curve. Dit punt is -L. Als we dit punt weer spiegelen ten opzichte van de x-as, dan krijgen we punt L. Dit is het resultaat van de verdubbeling. Als het Y coordinaat van J nul is, dan snijdt de tangens op het punt oneindig met de curve. Om aan te tonen waarom deze berekening lang duurt tonen we hier een rekenvoorbeeld. Stel B is de public key, b is de scalar en P is het generatorpunt. Dan doen we de volgende bewerking B=b*P. Allereerst, als je de public key B en het generatorpunt bezit, kan je de scalar of private key b niet berekenen omdat de benodigde processorkracht simpelweg niet bestaat. Voor de punt vermenigvuldiging heb je double en add nodig. Bij 1 doe je double en add, bij 0 doe je enkel double. Een binaire verdubbeling wordt heel snel gedaan door de bits n plaats naar links te schuiven. De meeste tijd zit dus in het optellen. Stel dat de scalar 5 is,

KHLim

Departement IWT

21

Hoofdstuk 2. Trusted state bv 5*P : 5= 0b101 1: 2*0+P = P 0: 2*P = 2P 1: 2*2P+P = 5P Stel dat je vermenigvuldigd met 0b10000000, dan worden alle bits afgelopen. Stel dat je vermenigvuldigd met 0b00000001, dan worden alle nullen overgeslagen en wordt enkel de laatste bit vermenigvuldigd. De point multiplication en signature verification hangen dus volledig af van de grootte van de scalar. Hoe groter deze scalar is hoe langer de berekening zal duren. Aangezien deze scalar een random getal is zullen de tijden verschillen bij het opmeten van de rekentijd. Figuur ??

Figuur 2.9: Elliptische curve cryptografie adding Figuur ??

KHLim

Departement IWT

22


Figuur 2.10: Elliptische curve cryptografie doubling

2.3.5

SHA256

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)

De SHA-256 is een deel van de SHA-2 standaard. Deze staat voor Secure Hash Algorithm. De SHA-2 bestaat uit SHA-224, SHA-256, SHA-384 en SHA-512. Deze staan respectievelijk voor 224, 256, 384 en 512 bits. In 2005 werden er gebreken ontdekt in de SHA-1 standaard, namelijk dat er mathematische zwakke punten bestonden en dat er een sterkere HASH functie nodig was. Alhoewel de SHA-2 gelijkenissen toont met de SHA-1, zijn de aanvallen op de SHA-2 toch niet succesvol. Een cryptografische hash functie, is een algoritme dat ervoor zorgt, dat een blok data wordt omgezet naar een bit string met een vaste grootte. De data die geëncodeerd moet worden noemt men de message en de gehashede data noemt men de digest. Een ideale cryptografische hash functie heeft vier hoofd eigenschappen: • de hash value van een message is gemakkelijk te maken, • het is quasi onmogelijk om een message op te maken van een gegeven hash, • het is quasi onmogelijk om een message te veranderen zonder dat de hash verandert, • het is quasi onmogelijk om dezelfde hash te vinden voor verschillende messages. Met behulp van deze hash functie kunnen we dan een gegeven data fingerprinten. Dit wilt zeggen dat we een blok data uniek maken en ervoor zorgen dat deze niet dupliceerbaar is. Ook kunnen we zien of er met de data geprutst is. Omdat één bit verschil in data al ervoor zorgt dat de hash compleet anders is.

KHLim

Departement IWT

23


2.3.6

RNG

In de trusted state hebben we een willekeurig getal nodig voor twee toepassingen. • Een willekeurig getal als authentication key bij het hashen. • Een willekeurig getal als scalar voor point multiplication en signature generation in de ECC. De getallen die wij genereren zijn pseudo-random. Dit wil zeggen dat ze random lijken maar dat eigenlijk niet zijn. Met behulp van logica genereren wij deze getallen. Er bestaat dus een mogelijkheid dat een aanvaller de opbouw van deze logica te weten kan komen en bijgevolg deze willekeurige getallen kan reproduceren. Als de pseudo-random getallen willekeurig genoeg zijn zal het echter wel heel moeilijk zijn om patronen te herkennen en bijgevolg veilig genoeg zijn. Er is voor pseudo-random gekozen omdat dit snel is en eenvoudiger om te produceren dan true-random. Om true-random getallen te genereren heb je een random seed nodig. Een paar voorbeelden van seeds worden hieronder opgesomd. • White noise van de atmosfeer opvangen. • Tijd tussen twee toetsaanslagen van een keyboard gebruiken. Zoals eerder gezegd gebruiken wij logica om het pseudo-random getal te genereren. De opbouw van deze logica wordt in figuur 2.11 getoond. Er worden drie invertoren in serie gezet om een ketting te vormen. Zo zijn er 50 kettingen in parallel. De outputs van deze kettingen gaan naar een xor blok. De uitgang van deze laatste wordt via een flip-flop in een shiftregister geschoven. Wanneer we een random getal nodig hebben lezen we de volledige 256bit parallel uit het shiftregister. Bij het starten en bij het resetten wordt er een nul in de eerste invertor gezet van elke ketting. Omdat de verbindingen in de fpga tussen de invertoren niet allemaal een gelijke lengte hebben zullen de uitgangen van de kettingen niet op elk moment gelijk zijn. Dit draagt bij tot een goede kwaliteit van de willekeurigheid van de random number generator. CLK

1

SR CLK

CLK

256bit 50

Figuur 2.11: Pseudo-random number generator KHLim

Departement IWT

24


2.3.7

Trusted state memory component

De trusted state memory component is vergelijkbaar met het passthrough memory. Ook deze bestaat uit BRAMs maar is een heel stuk groter. Daar waar de passthrough maar 32*512 bits was, is het trusted state memory 1024*1024 bits. Dit is zo opgesteld, om de eerste 512 plaatsten te reserveren voor processor states en de laatste 512 plaatsen voor de subject states. Het onderscheid in addressering is dan heel simpel. De meest beduidende bit in de 10 bit adressen zorgt ervoor dat we meteen bij de subjects of processors kunnen lezen of schrijven. Op elk adres staat er 1024-bit data. Dit zijn: de IDx, IDy, DC, IC en de AK. Allemaal 256 bit die samen 1024-bit zijn. Alhoewel de passthrough en trusted state memory gelijkaardig zijn aan mekaar, bestaat er een zeer grote verschil tussen deze twee. De passthrough BRAM controller moet maar 32-bit per keer schrijven of lezen terwijl de trusted state memory 256-bit per keer moet schrijven. In de virtex-5 FPGA die wij gebruiken is de maximale ingang grootte van de BRAM controllers maar 32-bit. Dus moet er bij de trusted state memory 8 bram controllers in cascade geschakeld worden. Deze worden dan zo ingesteld dat het lijkt alsof je maar één BRAM controller gebruikt. Ook wordt hier maar enkel gebruik gemaakt van één poort.

2.3.8

FSM

FSM staat voor finite state machine. FSM’s worden gebruikt om computer programma’s en sequentiële logica te maken. Het wordt beschouwd als een abstract machine dat zich maar in een bepaald eindig hoeveelheid ’states’ kan bevinden. De machine kan zich dus maar in één state tegelijk bevinden en die state noemt men de huidige state. Wanneer zich dan een conditie voordoet, zal deze wisselen van state en zo zijn routine doorlopen. In ons project heeft elk component een FSM die ervoor zorgt dat alles tot een goed eind wordt gebracht. Ze werken quasi allemaal op hetzelfde principe. Tijdens de eerste states wordt er uitgelezen van het passthrough memory om de data klaar te zetten in verschillende registers. Wanneer actie gedaan is, zal het eigenlijke component gestart worden. Wanneer deze laat weten dat hij gedaan heeft, zal de data terug geschreven worden in het passthrough memory. Hierna zal er een ’done’ signaal gestuurd worden om te laten weten dat alles gedaan is.

2.4

Trusted state component API

De trusted state heeft vijf hoofdcommando’s waarop hij moet reageren. Elk command heeft een andere combinatie van componenten die dienen gebruikt te worden.

2.4.1

Create processor state

Bij createProcessorState wordt er als input 520 bits gestuurd naar het trusted state. Acht bits hiervan zijn, om aan te geven dat het gaat om de commando createProcessorState, de letter ’P’. De rest zijn de IDx en IDy van de processor state. Deze worden verstuurd via ethernetpakketten en gekopieerd in het passthrough memory. Van daaruit wordt op deze KHLim

Departement IWT

25

Hoofdstuk 2. Trusted state IDx en IDy drie controles uitgevoerd. Bij de eerste controle wordt er gekeken of de IDx niet gelijk is aan nul en IDy niet gelijk is aan één. Anders kan hij niet op de elliptische curve liggen maar op een punt in de oneindigheid. Daarna zal er gekeken worden of IDx en IDy groter zijn dan een voorop ingestelde priemgetal. Als laatste controle wordt er gekeken of deze twee daadwerkelijk op de elliptische curve liggen. Wanneer één van deze voorwaarden niet voldaan zijn, zal de trusted state onmiddellijk stoppen en zeggen dat deze processor state niet kan bestaan. Indien de voorwaarden wel voldaan zijn, zal de trusted state doorgaan met het controleren of de trusted state al bestaat. Indien deze bestaat zal de trusted meteen stoppen, daar het geen nut heeft om 2 dezelfde processor states te hebben. Wanneer deze niet bestaat zal een processor state aangemaakt worden als er nog plaats is in het geheugen. Wanneer dit gedaan is, zal er een antwoord teruggestuurd worden naar de logserver.

2.4.2

Create subject state

De createSubjectState is gelijkaardig aan de createProcessorState. Hier is de input wel 1032-bits. Acht bits zijn het letter ’S’ om aan te geven dat het gaat om createSubjectState. 512-bits zijn de IDx en IDy van de processor state waaraan de subject state behoort. De andere 512-bits zijn de geëncrypteerde IDx en IDy van de subject state. Ook hier zullen een reeks controles op gevoerd worden. Om te beginnen met het controleren of de processor state al bestaat. Indien deze niet bestaat zal de subject state ook niet aangemaakt worden. Wanneer de processor state wel bestaat, zal de IDx en IDy van de subject state gedecrypteerd worden. Daarna zal ook hier de drie controles op uitgevoerd worden: punt op oneindigheid, groter als het opgegeven priemgetal en of hij op de elliptische curve ligt. Daarna wordt er gekeken of hij al bestaat. Indien niet, zal de subject state aangemaakt worden. Als laatst zal er dan een antwoord bericht opgesteld en teruggestuurd worden naar de logserver.

2.4.3

Create entry

Voor de createEntry, ook wel update state genoemd, wordt er 1288 bits data verstuurd. Acht bits voor de letter ’C’ en 1024 voor de IDx en IDy van de processor en subject state. Ook hier zijn die van de subject state encrypted. Hier komt dan nog eens 256-bits bij. Dit is de gehashte data, de activiteit dat gelogd moet worden. Als eerste zal er moeten gekeken worden of de processor wel bestaat. Dan zal de IDx en IDy gedecrypteerd worden en wordt nagekeken of de subject wel bestaat. Indien deze twee states wel bestaan wordt er een entry gemaakt. Dit wordt gedaan door de gehashte data opnieuw te hashen en zo op te slaan. Daarna wordt er weer een antwoord gemaakt en doorgestuurd naar de logserver. De create entry is het commando dat het meest opgeroepen zal worden. Voor elk subject state dat bestaat wordt er namelijk meerdere entries gemaakt.

KHLim

Departement IWT

26


2.4.4

Delete state

Delete state is quasi hetzelfde als de create entry commando. Als input krijgt hij 1032-bits. Om aan te geven dat we met delete state te maken hebben, zijn de 8-bits voor de letter ’D’. De rest van de data zijn weer de IDx en IDy van de processor state en subject state. Na het controleren of deze twee wel voorkomen in de trusted state memory, zal de gekozen subject verwijderd worden. Hierna zal er een antwoord opgesteld worden om naar de logserver te sturen.

2.4.5

Get state

Met getstate kunnen we een processor state of subject state ophalen om deze louter te bekijken. De input hiervoor is 520 bits. Acht bits voor de letter ’G’. De rest zijn de IDx en IDy van ofwel de processor state, ofwel de subject state. Na de nodige controles, om te kijken of de opgevraagde state wel bestaat, zal de trusted state een antwoord opstellen en deze terug sturen naar de logserver. Het grote verschil met de andere commandos, is dat de getstate door iedereen opgeroepen kan worden. Deze dient om de gebruiker te laten controleren wat er exact over hem gelogd wordt. Maar omdat dit dan door iedereen gebruikbaar is, zal er een extra voorzorgsmaatregel getroffen moeten worden. Namelijk, wanneer de opgevraagde state niet bestaat, zal er niet meteen gestopt worden. Er zal integendeel een valse state aangemaakt worden en deze als antwoord terug sturen. Dit heeft als doel, dat wanneer men ’timing attacks’ uitvoert bij het gebruiken van dit commando, men niet het onderscheid zal kunnen maken tussen een bestaande en niet bestaande state. Zo zal de gebruiker met malafide bedoelingen dan ook weten of hij nu een bestaande state te pakken heeft of niet. Het getstate commando is diegene die, na het create entry commando, het meeste gebruikt zal worden. Onderstaande fig. 2.12 geeft weer wat er precies gebeurd in de trusted state bij elk commando.

KHLim

Departement IWT

27


Figuur 2.12: Flowchart microblaze

KHLim

Departement IWT

28

Hoofdstuk 3. Performantie verbeteren

Hoofdstuk 3 Performantie verbeteren 3.1

Analyseren van de oorspronkelijke performantie

Zoals in de inleiding al vermeld werd, is het doel van deze thesis om de snelheid van het hardware component te verbeteren. Om onze verbeteringen te kunnen aantonen hebben we een nulpuntmeting gedaan.

Commando

Target at [ms] CreateProcessorState 166.65 166.86 CreateSubjectState CreateEntry 1.25 GetStateIC 108,16 0.36 DeleteSubject

HW SW 0 Target at 511 [ms] [ms] 177.91 59 189.31 60 23.62 0.062 120,25 41 22.73 0.020

Tabel 3.1: Prestaties HW vs SW Wat we meteen zien is dat de hardware een heel stuk trager is dan de software. De software is geschreven in java en draait op een AMD Turion X2 ultra dual-core mobile ZM-82 2.2GHz processor. Dit is een budget processor dus de prestaties van de software zouden nog beter kunnen door een high-end processor te gebruiken. Wij gebruiken een Virtex 5 XC5VFX70T 1C fpga met een maximale frequentie van 550MHz. Verder in deze thesis zullen we opmerken dat deze frequentie niet gehaald wordt.

3.2

Zoeken van de bottleneck

Normaal gezien zou hardware sneller moeten zijn dan software. Ergens in het design zitten dus een of meerdere bottlenecks. Eerst moeten we de code overlopen en achterhalen wat er gebeurd en meten waar we tijd verliezen.

KHLim

Departement IWT

29


3.2.1

Meten van acties

Wat opvalt is dat de commands waar de elliptic curve processor in gebruikt wordt het traagst zijn. We gaan daarom het aantal cycles tellen dat bepaalde onderdelen van de code nodig hebben. Zo vormen we een beeld van wat precies het meeste tijd nodig heeft. In tabel 3.2 laten we de tijden zien voor de acties die volgens ons het meeste tijd in beslag zouden nemen. Actie Check if PuKp exists pos0 Check if PuKp exists pos511 EcP pv EcP pv met copyword EcP sig gen EcP pm RNG AES HASH HMAC

Tijd [ms] 0.00075 2.3365 0.0977 0.1317 58.199 53.956 0.00186 0.25587 0.03959 0.1455

Tabel 3.2: Tijden voor bepaalde acties In ”Check if PukP exists” wordt er gecontroleerd of de ontvangen publieke sleutel bestaat. Dit gebeurd met een aantal stappen : • Een commando wordt gestuurd van de microblaze naar de FSM om data van een bepaalde geheugenplaats te lezen. • De data wordt van het trusted state geheugen naar het passthrough geheugen verplaatst. • Vervolgens wordt de data van het passthrough geheugen over de PLB bus naar de microblaze verstuurt. • Er wordt vergeleken tussen de ontvange publieke sleutel en de net gekopieerde sleutel. • Dit wordt herhaald tot er een match is of het geheugen volledig afgelopen is. Uit de tabel kunnen we zien dat het kopieren zelf verrassend genoeg niet zo lang duurt. Maar omdat het vaak voorkomt toch al snel kan oplopen. Daarnaast hebben we nog drie modussen van de elliptic curve processor (EcP). • Point validation • Signature generation • Point multiplication

KHLim

Departement IWT

30


3.2.2

Kritisch pad zoeken

Wat is een kritisch pad? Nu dat we weten welke elementen het meeste tijd in beslag nemen gaan we zoeken naar een kritisch pad. Een kritisch pad is het langste pad tussen twee registers. Logica zoals and, or, etc... hebben een bepaalde delay. Als je een ketting van logica vormt dan neemt het een bepaalde tijd in beslag voordat de uitgang veranderd nadat je data op de ingang hebt aangelegd. Deze doorlooptijd bepaald de maximale clock van je systeem. Door op bepaalde plaatsen een register toe te voegen kan je de clocksnelheid verhogen. Dit principe heet pipelining en wordt in fig. 3.1 duidelijk gemaakt.

1s

0.5s

0.5s

Figuur 3.1: Pipelining principe Door het kritisch pad in twee te delen kunnen we al nieuwe data aanleggen als de vorige data halfweg is. Op de tekening staat dat de doorlooptijd dan twee keer een halve second is, maar eigenlijk moet je nog een delay toevoegen van het extra register dat we hebben toegevoegd. Deze delay is echter klein en weegt niet op tegen het voordeel van de verdubbelde throughput. Waar ligt het kritisch pad? De xilinx design suite heeft een programma, genaamd planahead, waarin het kritiek pad van je design in een schema aangeduid wordt. Daarnaast kan je ook in xilinx ISE het kritiek pad aflezen. Het schema van het kritiek pad in de trusted state is veel te groot om in deze thesis bij te voegen. Toen we de gegevens overliepen hebben we gemerkt dat het probleem zich in de AES blok bevindt. Daarom hebben we dit component in een apart project gezet en met trial and error de maximaal haalbare frequentie gezocht. Dit hebben we gedaan door de clockcyclus met een precisie van 1ns te verlagen tot dit problemen gaf. In de vhdl code is een Digital Clock Manager (DCM) ge¨ımplementeerd die de 100MHz clockfrequentie van de microblaze deelt door vijf voor de cryptocore. Dit wordt gedaan omdat de AES blok niet op 100MHz kan werken. Bij een clockcyclus van 12ns oftewel KHLim

Departement IWT

31

Hoofdstuk 3. Performantie verbeteren frequentie van 83MHz werkte de AES blok nog zonder problemen. Merk op dat deze frequentie nog door vijf gedeeld wordt waardoor alle VHDL componenten op een maximale frequentie van 16,6MHz werken. Dit zorgt er dus grofweg voor dat de trusted state zes keer trager werkt.

3.3 3.3.1

Mogelijke oplossingen Paralleliseren

We hebben gezien dat bepaalde componenten zoals de elliptic curve processor veel tijd in beslag kunnen nemen. Alles wordt nu serieel uitgevoerd of aangestuurd door de microblaze. Een oplossing om de snelheid te verhogen is paralleliseren. We gaan alle stappen af en zoeken of we deze tegelijk kunnen uitvoeren. CreateProcessor parallel flowchart Figuur 3.2 geeft de geparallelliseerde versie van CreateProcessor weer.

Figuur 3.2: Parallel versie van CreateProcessor Eerst lezen we de public key in via ethernet en kopieren we de data naar het passthrough geheugen. Daarna moeten we controleren of deze key geldig is en al bestaat in de trusted memory state. Check if exists en check if valid kunnen we gelijktijdig uitvoeren omdat ze geen data van elkaar nodig hebben. Stel dat de key niet valid is dan stopt het programma. Maar als de key wel valid is dan hebben we ineens ook gezocht of de key bestaat en hebben we tijd kunnen winnen. In parallel kunnen we ook nog eens ´’ prepare ic´’ uitvoeren. Hierin zetten we de identifier chain value klaar. In deze stap is er hashing nodig. Pas als de key geldig is en bestaat mag de data van ´’prepare ic´’ doorgegeven worden naar de volgende stap. KHLim

Departement IWT

32

Hoofdstuk 3. Performantie verbeteren Dan maken we een processor state aan. Dit is vooral kopieer werk en ook een random getal aanmaken met de random number generator. Vanaf nu volgen veel bewerkingen. Eerst werd de elliptische curve processor drie keer in serie uitgevoerd. Zoals we eerder al hebben gezien neemt deze bewerking veel tijd in beslag. Door dit in parallel uit te voeren kunnen we de verwerkingstijd van CreateProcessor grofweg drie keer sneller maken. Deze processors hebben een random getal nodig die in parallel met de hash berekend kan worden. Als laatste hebben we een HMAC bewerking die min of meer parallel loopt met de AES blok. Oorspronkelijk moest de HMAC blok wachten tot de AES blok klaar was. Nu gebruiken we al tussenresultaten van de AES blok om zo sneller tot een uitkomst te komen en dus extra tijd te besparen. Als laatste wordt dan een response opgesteld en via ethernet teruggestuurd. CreateSubject parallel flowchart Figuur 3.3 geeft de geparallelliseerde versie van CreateSubjectState weer.

Figuur 3.3: Parallel versie van CreateSubject De ethernetpakketten worden ontleed en geschreven in de passthrough. Nadat we dit hebben gedaan, kunnen we drie stappen tegelijk doen. Namelijk kijken of de processor state bestaat, de IDx en IDy van de subject state decrypteren. Dit decrypteren wordt in 4 stappen gedaan. Na elk stap gaan we dan ook al de eerste controle uitvoeren, namelijk of de IDx niet gelijk is aan nul en de IDy niet gelijk aan één. De volgende stap doen we dan vier stappen tegelijk: controleren of de subject state al bestaat, de IC hashen, controleren of de subject IDs groter zijn dan de vooropafgestelde priemgetal en of de IDs op de elliptische curve ligt. De volgende stap doen we dan weer twee stappen tegelijk: we beginnen met de subject state aan te maken en we beginnen met het antwoord voor de logserver op te stellen. Nadat we de RNGs en de hash hebben gedaan, kunnen we dan de drie ecc P’s starten. Hierna starten we met hashen. Na het hashen kunnen we de HMAC KHLim

Departement IWT

33

Hoofdstuk 3. Performantie verbeteren en de AES encryptie tegelijk starten. De HMAC heeft wel 6 stappen nodig, en de laatste stap heeft de output van de AES nodig. Dus de HMAC moet sowieso wachten op de AES. Als dit allemaal gedaan is, is ons antwoord opgesteld en kunnen we deze terug opsturen naar de logserver. CreateEntry parallel flowchart Figuur 3.4 geeft de geparallelliseerde versie van CreateEntry weer.

Figuur 3.4: Parallel versie van CreateEntry Eerst moeten we alle data van het ethernet packet inlezen en in het passthrough geheugen schrijven. Dan gaan we na of de public key van de processor bestaat. Tegelijk beginnen we al met de decryptie van de public key van de subject. Als de public key van de processor niet bestaat dan stoppen we de decryptie, als de key wel bestaat dan hebben we tijd gewonnen. Als de decryptie van PuKs gedaan is dan pas kunnen we controleren of deze geregistreerd is. Tegelijk starten we het hashen. Dan updaten we de states in het trusted state geheugen. DeleteState flowchart Figuur 3.5 geeft de geparallelliseerde versie van CreateEntry weer.

Figuur 3.5: Parallel versie van DeleteState KHLim

Departement IWT

34

Hoofdstuk 3. Performantie verbeteren Eerst halen we de data uit het ethernet packet en schrijven dit naar het passthrough geheugen. Dan gaan we kijken of PuKp geregistreerd is en tegelijk decrypten we PuKs. Als PuKp niet bestaat dan stoppen we. Als PuKp wel bestaat dan hebben we tijd gewonnen. Pas na de decryptie van PuKs kunnen we nagaan of deze geregistreerd is. Dan overschrijven we de state met nullen in het trusted state memory en sturen we een packet terug. GetState flowchart Figuur 3.6 geeft de geparallelliseerde versie van GetState weer.

Figuur 3.6: Parallel versie van GetState In de geparallelliseerde versie van de getState command zullen we beginnen met de ontvangen data te kopieren naar de passthrough en tegelijk al een controle er op uitvoeren. De eerste controle is of de IDx en IDy op oneindigheid liggen. Daarna worden er een hele resem stappen tegelijk gedaan: het antwoord naar de logserver wordt samengesteld door de RNG te laten werken, controleren of het opgevraagde een processor state is, of het een subject state is, of de IDs groter zijn dan de priemgetal en of het wel op de elliptische curve ligt. Hierna worden twee ecc P tegelijk gestart met de instelling van ’eliptic curve point multiplication’. Nadat deze twee gedaan zijn, zal deze data gehashed worden. De HMAC en de AES zullen dan tegelijk gestart worden en de HMAC zal op de AES moeten wachten eer hij zijn taak kan vervolledigen. Na dit alles, zal de antwoord opgesteld zijn en worden opgestuurd naar de logserver. KHLim

Departement IWT

35


3.3.2

Verplaatsen van microblaze naar vhdl

De aansturing van de componenten gebeurd vanuit de microblaze. Vaak moet er data klaar gezet worden voor deze componenten. De microblaze geeft dan kopieer instructies om data uit het trusted state geheugen te lezen of data in het passthrough geheugen rond te kopieren. Soms wordt er zelfs iets gekopieerd van het trusted state geheugen naar het passthrough geheugen. Daarna van het passthrough geheugen naar de microblaze. dan wordt er iets op deze data uitgevoerd. En in het slechtste geval moet heel het geheugen af gegaan worden, dit is dan 512 keer. Een kopieer actie op zichzelf neemt relatief weinig tijd in. Maar als dit heel vaak uitgevoerd wordt kan deze tijd al snel oplopen. Er zijn drie plannen om dit te verbeteren. • We maken een tweede FSM in het trusted state component die alle aansturingen overneemt. • We gaan niet meer kopieren als dit niet nodig is. Zoveel mogelijk rechtstreeks uit het geheugen lezen. • Gebruik maken van de dual-port eigenschap van het BRAM geheugen. Het BRAM geheugen heeft ondersteuning voor dual-port. Dit betekend dat elke BRAM blok twee poorten heeft. elke poort heeft zijn eigen data in, data out, adress bus, clock en enable/write-enable controle lijnen. Door dit op een slimme manier te gebruiken kunnen bepaalde functies dubbel zo snel het geheugen overlopen.

3.3.3

Kritische paden wegwerken

Het AES component dat gebruikt is in het trusted state component is geoptimaliseerd voor area. Dit betekend dat deze AES zo klein mogelijk gemaakt is. Dit heeft wel gevolgen voor de snelheid. De throughput is heel laag omdat er zo weinig mogelijk geparalleliseerd wordt. Omdat er veel in serie gebeurd en omdat er meerdere rondes dezelfde componenten gebruikt worden ontstaat er ook een enorm lang kritisch pad. Het oorspronkelijke AES component kan ongeveer op 17MHz werken. Dit is zijn maximaal haalbare frequentie. Zoals in 3.2.2 uitgelegd wordt is er een DCM ge¨ımplementeerd die de frequentie door vijf deelt. Door dit kritiek pad te verkorten kunnen we de DCM weglaten. Daardoor kan de hele trusted state minstens vijf keer sneller werken.

3.3.4

Optimaliseren van componenten

In de trusted state wordt er gebruik gemaakt van AES, HASH/HMAC en elliptic curve processing. Door deze componenten efficienter te laten werken kunnen we ook tijd winnen. Zo kunnen we de AES 128bit in parallel laten verwerken en met pipelining zijn kritisch pad verkorten. Het hashen gebeurd nu volledig serieel maar sommige onderdelen kunnen parallel werken. De elliptic curve processing neemt veel tijd in beslag. De elliptic curve point multiplication wordt vooral in createProcessor en createSubject gebruikt. En deze KHLim

Departement IWT

36

Hoofdstuk 3. Performantie verbeteren worden veel minder uitgevoerd dan createEntry. Daarom is het misschien minder dringend om de elliptic curve processor te optimaliseren.

3.4 3.4.1

Implementaties en hun performance gain CheckExisting functie

De checkExisting functie hebben we in de loop van onze masterproef twee keer aangepast. De eerste keer was omdat we bij het analyseren een fout hadden opgemerkt en hebben opgelost. De tweede keer was de aanpassing, zoals vooropgesteld door scenario B, de checkExisting functie verplaatsen naar de trusted state. Er bestaan twee checkExisting functies. Eén is de checkExistingID en de andere is checkExistingIC. Omdat we de createEntry commando prioriteit hebben gegeven, hebben we het overzetten naar de trusted state enkel voorbehouden aan de checkExistingID. De checkExisting functie, werkt eigenlijk samen met een andere functie, namelijk: loadProcessorInPT of loadSubjectInPT. Deze functie zal van de states, subject of processor, alle data overzetten naar de passthrough. Dit is dan 1280-bits aan data die per 32-bit ingeladen worden. CheckExisting functie - Origineel Deze functie controleert of de IC of ID van een state al dan niet voorkomt. Met andere woorden, of de state bestaat of niet. Wanneer de functie loadInPT afgelopen is, zal de functie checkExisting 16 keer, per 32 bit (256 bit voor IDx en 256bit voor IDy), controleren of de IDs of IC voorkomt. checkExist en loadInPT wordt dan evenveel keer gedaan als de hoeveelheid states in de trusted state memory. CheckExisting functie - Verbetering Het werkingsprincipe van de originele checkExisting en de verbetering ervan is hetzelfde, maar bij het analyseren van de code kwamen we uit op een fout in de functie. Namelijk, dat bij het vergelijken van de 32-bits, er meteen uit de functie werd gesprongen van het moment dat de twee 32-bits gelijk waren aan mekaar. Dit is niet goed omdat het kan zijn dat de eerste 32-bits gelijk zijn, maar de volgende niet meer. Omdat de gehele 512 bits niet werden gecontroleerd kun je niet zeker zijn. Ook was het zo, dat wanneer de functie twee 32-bit data vond die niet gelijk waren aan mekaar, deze dan bleef doorgaan met nakijken. Dit is zinloos, omdat als de eerste 32-bit niet overeenkomen, dan weet je dat je al verder kan gaan met het vergelijken van de volgende IDs of ICs. Wij hebben deze functie dan zo aangepast, dat het eigenlijk omgekeerd werkt. We beginnen te controleren en als de eerste 32-bits overeenkomen, vergelijk we ook de overige 480 bits. Als ze dan echt allemaal gelijk zijn, kunnen we met zekerheid zeggen dat de state bestaat. In het andere geval, van het moment dat de functie twee 32-bits heeft gevonden die niet overeenkomen, gaat de functie door met andere IDs of ICs vergelijken. Het resultaat van deze aanpassing zien we in tabel 3.3. KHLim

Departement IWT

37

Hoofdstuk 3. Performantie verbeteren Origineel Verbetering Commando Target at 0 Target at 511 Target at 0 Target at 511 [ms] [ms] [ms] [ms] CreateProcessorState 166.65 177.91 166,49 168,83 CreateSubjectState 166.86 189.31 167,18 171,97 CreateEntry 1.25 23.62 1,29 5,96 GetStateIC 108,16 120,25 108,18 110,67 DeleteSubject 0.36 22.73 0,39 5,06 Tabel 3.3: Prestaties na verbetering Wanneer we de resultaten bekijken van tabel 3.3, krijgen we wat gemengde gevoelens. We zien bij target at 0, dit is wanneer er maar één state zit in de trusted state memory, dat we zelfs trager werken dan voordat we de verbetering hebben toegepast. Dit komt natuurlijk omdat, bij het origineel, van het moment dat de eerste 32-bit goed was, de rest niet meer gecontroleerd werd. We zien wel dat bij target at 511, er een heel groot verschil is. We zien dat we dan ongeveer 15ms sneller zijn. Dit is zeer veel bij createEntry. Deze hoge tijdswinst komt natuurlijk door het feit, dat van het moment er 32-bits data niet overeenkomt we stoppen met zoeken. Zo sparen we heel veel tijd uit als de state die we zoeken op plaats 511 zit. CheckExisting functie - Overzetten naar trusted state Wanneer we na het analyseren begonnen met het versnellen van de cryptocore, was het ons duidelijk dat in de checkExisting functie heel veel tijd verloren werd. Er werd namelijk elke keer 1280-bits overgezet naar de passthrough memory, in stukken van 32-bit. Hierna werd dan per 32-bit vergeleken. Veel te tijdrovend. Wat wij nu hebben gedaan, is deze functie overgezet naar de cryptocore. De FSM die hiervoor verantwoordelijk is, wordt zo gemaakt dat deze rechtstreeks met het trusted state memory kan communiceren. Door gebruik te maken van de dual-port eigenschap van de BRAM controllers is dit heel simpel gedaan. De werking is dan als volgt: De ID’s, samen 512-bits, van de te vergelijken state zitten in het passthrough memory. Deze moeten nog altijd 32-bits per keer ingelezen worden door de FSM en in een register geplaatst. Dit wordt maar één keer gedaan. Daarna wordt de ID’s van de states in de trusted state opgehaald. Dit is 512-bits in één keer dat opgehaald wordt. Hierna is het vergelijken simpel, elke klok cyclus zal de gehele 512-bits vergeleken worden. Dit in contrast met het origineel, waar het per 32-bit, in totaal 16x gedaan werd. In de microblaze duurt dat twee klok cycli per vergelijking, dus 32 klok cycli. We sparen hiermee veel uit. Maar niet enkel met het vergelijken, want de 1280-bits aan data, die voor elke state dat in de trusted state memory zit, dat in het passthrough werd geschreven wordt niet meer gedaan. Nu wordt enkel de data van de opgevraagde state in de passthrough geschreven. De resultaten hiervan staan in tabel 3.4.

KHLim

Departement IWT

38

Hoofdstuk 3. Performantie verbeteren Origineel Verbetering Overgezet naar FSM Target at 0 Target at 511 Target at 0 Target at 511 Target at 0 Target at 511 [ms] [ms] [ms] [ms] [ms] [ms] CreateProcessorState 166.65 177.91 166,49 168,83 166,49 168,83 CreateSubjectState 166.86 189.31 167,18 171,97 167,18 171,97 1.25 23.62 1,29 5,96 1,25 1,30 CreateEntry 108,16 120,25 108,18 110,67 108,18 110,67 GetStateIC DeleteSubject 0.36 22.73 0,39 5,06 0,39 5,06 Commando

Tabel 3.4: Prestaties na overzetten naar FSM in tabel 3.4 tonen we alle resultaten. Het origineel, de verbeterde versie en de naar FSM overgezette versie. We moeten wel opmerken, dat we de overzetting naar FSM enkel hebben toegepast op het commando createEntry. Daar we weinig tijd hebben, geven we deze commando prioriteit. We zien bij target at 0 dat we met de FSM versie even snel zijn geworden als de originele versie. Bij target at 511 zien we een zeer groot tijdverschil. Deze is namelijk bijna hetzelfde als op target at 0. Door deze optimalisatie zijn we niet radicaal sneller wanneer we maar één state hebben in de trusted state memory, maar wel een pak sneller als we 511 states hebben. De tijdswinst hier zal ook groter worden naarmate de trusted state memory uitgebreid wordt.

3.4.2

AES kritisch pad

Om het kritisch pad weg te werken, moeten we op bepaalde plaatsen in het design buffers plaatsen. De originele AES is gemaakt om zoveel mogelijk plaats te besparen in de FPGA. Om dit te bereiken wordt de breedte van het datapad verkleind en worden blokken opnieuw gebruikt. Deze blokken zitten dan in loops, wat een groter combinatorisch pad oplevert. De originele AES heeft drie blokken om te timing te regelen. Als we in dit design buffers plaatsen is de timing helemaal om zeep. Het vereist dan ook te veel aanpassingen om de timing correct te krijgen. Deze AES verwerkt de data in blokken van 32 bit. Wij hebben een volledig nieuwe AES blok geschreven. Deze verwerkt de data in blokken van 128 bit waardoor we alles parallel kunnen verwerken. Hierdoor minimaliseren we het aantal loops. Figuur 3.7 geeft de flowchart van de verbeterde AES weer. Zoals u ziet zijn er drie buffers geplaatst. De maximale klokfrequentie is daardoor ongeveer 75MHz. We hebben dan naar het kritisch pad gekeken. Het midden van dat pad bevind zich in de subbytes blok. Daarom hebben we in de subbytes ook een buffer geplaatst. Hierdoor is de maximale frequentie ongeveer 120MHz. Voor decryptie hebben we het equivalent schema gebruikt. Dan kan je hetzelfde schema gebruiken voor zowel encryptie als decryptie. Maar de keyscheduler moet dan aangepast worden. Als er gedecrypt moet worden, moet de data van de keyscheduler nog door een mixedcolumn blok gaan. Deze mixedcolumn blok zit in de keyscheduler zelf en is dus niet zichtbaar in de flowchart. De verbeterde AES heeft 424 cycles nodig om alle data te verwerken. De oude AES had 3200 cycles nodig.

KHLim

Departement IWT

39

Hoofdstuk 3. Performantie verbeteren Data Key

Data out

Figuur 3.7: Flowchart verbeterde AES De DCM hebben we aangepast zodat de elliptic-curve processor op een klokfrequentie van 50MHz werkt en de rest van de cryptocore op 100MHz. Tabel 3.5 geeft de prestatiewinst weer van elke API command met de nieuwe AES. De metingen zijn opgemeten na de verbetering van de checkExisting functie, maar voor het overzetten naar trusted state. HW oude AES HW nieuwe AES SW Commando Target at 0 Target at 511 Target at 0 Target at 511 [ms] [ms] [ms] [ms] [ms] CreateProcessorState 166.65 177.91 67.19 68.77 59 CreateSubjectState 166.86 189.31 67.23 70.51 60 CreateEntry 1.25 23.62 1.09 4.33 0.062 GetStateIC 108.16 120.25 43.57 45.19 41 DeleteSubject 0.36 22.73 0.27 3.51 0.020 Tabel 3.5: Prestaties van cryptocore met oude AES vs nieuwe AES Zoals we kunnen zien zijn de API commands die gebruik maken van de ECC, 2,5 keer sneller geworden. De andere commands gebruiken blokken die allemaal op 100MHz werken. Deze commands zijn tot onze verbazing niet vijf keer sneller geworden. We hebben createEntry volledig getimed. Alle tijd die we verliezen zit in het kopieren van data, het KHLim

Departement IWT

40

Hoofdstuk 3. Performantie verbeteren inlezen van ethernet pakketten en het uitlezen van ethernet pakketten. Deze acties werden niet benvloed door de hogere klokfrequentie.

KHLim

Departement IWT

41

Hoofdstuk 4. Vastgestelde problemen

Hoofdstuk 4 Vastgestelde problemen 4.1

AES

Bij het verbeteren van het AES component hebben we de meeste problemen ondervonden. Onze verbeterde versie werkte theoretisch volledig. In de simulatie was zowel de encryptie als de decryptie correct. Dan hebben we onze AES component in de volledige cryptocore ge¨ımplementeerd en in de fpga geprogrammeerd. Als volgt lieten we de logserver bepaalde commando’s sturen naar de fpga. Normaal gezien krijgt de logserver dan een response van de fpga maar die response kwam niet. Om zeker te zijn dat alles klopt hebben we de simulatie van de AES nog eens overlopen en alle signalen gecontroleerd. Hier bleek niets mis te zijn. Als volgt hebben we alle verbindingen van de AES met de CBC en de cryptocore nagekeken, ook hier bleek niets mis te zijn. Dan hebben we de code opnieuw in de fpga geprogrammeerd en in de logserver op bepaalde plaatsen assert errors geplaatst. Van het moment dat er dan iets misloopt krijgen we één van deze errors in de console van eclipse te zien. Op die manier komen we te weten waar het ongeveer misloopt. Vervolgens hebben we commando’s van de logserver naar de cryptocore gestuurd. Door de eerder geplaatste assert errors zagen we dat de teruggestuurde data niet klopte. Dit kwam doordat de AES de data foutief versleutelde. Dan hebben we de originele code weer in de fpga geprogrammeerd om de teruggestuurde data te vergelijken. Bleek dat deze ook niet meer klopte. Soms wordt de data foutief in de fpga geprogrammeerd. Dus hebben we alle projecten volledig gecleaned en opnieuw gebuild waarna de originele code weer correct werkte. Daarna hebben we een testbench gemaakt voor de volledige cryptocore om te testen of alle verbindingen met de AES correct waren. Maar ook deze simulatie was volledig correct. Dan hebben we bepaalde signalen zoals done en enable op de leds van het development bord weergegeven. Ook hebben we print commands geplaatst om alle tussenresultaten en het eindresultaat van de AES in de console te printen. We hebben ervoor gezorgt dat alle inputs constant bleven zodat de output van de AES altijd constant zou moeten zijn. Nu zagen we dat in de cryptocore met originele AES de data inderdaad constant bleef. Maar in de cryptocore met aangepaste AES was de data altijd anders. Op dit punt konden we niet meer verder met deze manier van debuggen. Timing simulaties

KHLim

Departement IWT

42

Hoofdstuk 4. Vastgestelde problemen namen dagen in beslag dus dit was niet zo handig om mee te werken. Dan hebben we leren debuggen met chipscope. Dan plaats je ILA componenten op de plaatsen waar je de data wil bekijken in de fpga. Deze ILA componenten nemen samples van de gekozen data met een op voorhand bepaalde kloksnelheid. Zo kan je zien wat er zich in de fpga afspeelt. Deze manier van werken is ook veel sneller dan een timing simulatie. Figuur 4.1 toont de flowchart van de AES met ILA componenten. Er is ook nog een ICON component nodig die controle signalen naar de ILA componenten stuurt. Dit ICON component voorziet een interface tussen chipscope en chipscope target cores waaronder de ILA componenten. Per ICON component kan je 15 target cores gebruiken. Bij het debuggen, met behulp van chipscope, zagen we dat de counter van de FSM niet correct telde. In de keyscheduler werden componenten getrimd en xilinx gaf hier geen errors over, enkel warnings. Wij namen aan dat als er geen errors zijn, dat alles correct is. Hieruit hebben we dus al een les geleerd. Na het debuggen kwamen we tot de conclusie dat xilinx een multiplexer niet correct naar hardware kon vertalen. Deze mux schakelde het ontwerp tussen encryptie en decryptie. Wij hebben de keyscheduler aangepast zodat hetzelfde schema gebruikt kan worden voor zowel encryptie als decryptie. Na dit herschrijven hebben we enkel de AES in de fpga geprogrammeerd en getest met chipscope. Uiteindelijk werkte de AES wel. Zowel encryptie als decryptie gaven de juiste output. Daarna staken we onze AES in de cryptocore en programmeerde we de fpga opnieuw. We stuurde commands van de logserver naar de fpga. Maar de logserver bleef wachten op een done die nooit aan leek te komen. Er klopte dus nog iets niet. Dan hebben we de AES weer apart in de fpga geprogrammeerd, maar deze keer klopte de output niet meer. Uit dit random gedrag konden wij niet afleiden waar het probleem zich precies situeerde. Als oplossing hebben we de AES aangepast zodat we met dipswitches kunnen kiezen op welke ronde de AES moet stoppen. Op die manier kunnen we de AES stilzetten en zoeken waar het random gedrag begint. Dit leek te beginnen bij de mixed columns. Dus hebben we de multiplexer vereenvoudigd, de rest van de code is combinatorisch en zou geen enkel probleem mogen vormen. Na deze aanpassing werkte de encryptie weer. Decryptie heeft dan even gewerkt maar dat was toevallig. De volgende dag werkte de encryptie weer niet, dan hebben we een parameter opgegeven om de nieuwere parser te gebruiken. Bijgevolg werkte de encryptie weer. In de decryptie kregen we vreemde resultaten. De output van de multiplexer was correct maar de input van de mixedcolumns niet. Dit zou betekenen dat de data be/¨ınvloed werd op een wire. Dit kan niet en is een teken dat xilinx nog steeds bepaalde code niet kan vertalen naar hardware. Dan hebben we de code weer eens volledig overlopen maar we vonden geen stukken meer die fout interpreteerbaar kunnen zijn. We wisten op dit punt niet meer wat we nog konden doen. Onze promotor, dhr. Ing. Jo Vliegen, heeft onze code dan ook eens overlopen, maar heeft geen fouten kunnen vinden. Hij heeft de code wat opgeruimd en zelf getest in een andere fpga. Bleek dat de code bij hem wel werkte. Dan hebben we diezelfde code gecompiled voor onze fpga. Decryptie werkte maar encryptie niet. Bij encryptie werd er 1 ronde te weinig gedaan. We hebben de ILA componenten aangepast en de fpga opnieuw geprogrammeerd. Nu werkte niets meer, KHLim

Departement IWT

43

Hoofdstuk 4. Vastgestelde problemen terwijl de ILA componenten geen invloed zouden mogen hebben op de data. Dan hebben we nog eens, samen met onze promotor, alles overlopen. Toen bleek dat we de ucf file op een verkeerde manier gebruikte. Wij stelden een klokperiode in, in de ucf file. En wij dachten dat dan die klokperiode gebruikt werd in de fpga. Maar de fpga gebruikt altijd zijn standaard klokfrequentie van 100MHz, tenzij je een DCM gebruikt. Onze AES kon op dat moment net geen 100MHz halen waardoor we een random gedrag kregen. Dat verklaarde ook waarom de data meer random werd naar mate we de klokperiode in de ucf file groter instelde. Want dan doet de synthese tool minder moeite om de elektronica te routen. Om dit probleem op te lossen hebben we het kritiek pad bekeken en ongeveer in de helft van dat pad een buffer geplaatst. Dit probleem hadden we sneller kunnen oplossen indien we meer ervaring hadden met xilinx en de ucf files. Hoe dan ook hebben we hieruit veel geleerd. Wij hebben, door dit probleem, isim en chipscope onder de knie gekregen. Daarnaast hebben we geleerd om de code zo te schrijven dat xilinx er zo weinig mogelijk problemen mee heeft om naar hardware te vertalen.

KHLim

Departement IWT

44

Hoofdstuk 4. Vastgestelde problemen

Data Key

Data out

Figuur 4.1: AES flowchart met ILA componenten

4.2

DCM en AES-buffer

Omdat de AES geen 100MHz aankon hebben we een buffer geplaatst in het midden van het kritiek pad. Dit midden lag in de subbytes blok. Na het plaatsen van deze buffer hebben we de werking geverifieerd in de simulatie. Dan hebben we deze AES blok in het

KHLim

Departement IWT

45

Hoofdstuk 4. Vastgestelde problemen geheel gemplementeerd. De DCM in het top-level van de cryptocore hebben we aangepast zodat deze een klokfrequentie van 70MHz gaf. Deze frequentie hebben we bekomen door de clkfx uitgang te gebruiken van de DCM. Dan stel je een breuk in, zodat je de uitgangsfrequentie nauwkeuriger kunt instellen. Maar op deze manier kreeg Xilinx de cryptocore niet geroute. De maximaal haalbare frequentie was dan ongeveer 20MHz. Daarom hebben we de gewone clock divide gebruikt die de 100MHz klokfrequentie van het development board, deelt naar een klokfrequentie van 50MHz. De bedoeling hiervan is om de elliptic-curve processor op 50MHz te laten werken en de rest van het systeem op 100MHz. Na deze aanpassingen hebben we de bitstream van het systeem gegenereerd en in de fpga geprogrammeerd. Bij het testen bleek dat er iets mis liep. De logserver bleef telkens wachten op het done-signaal van de elliptic-curve processor. Wij dachten dat het misschien aan de DCM lag die we hebben aangepast. Hadden we de originele DCM weer gebruikt, het project gecleaned en dan de bitstream gegenereerd. Nu bleek de cryptocore nog steeds niet te werken, we kregen nog steeds dezelfde fout. Dan hebben we de IP-core van onze cryptocore uit het XPS project verwijdert. Vervolgens alles gecleaned en dan de IP-core opnieuw toegevoegd. Bij het testen bleef de logserver niet meer op de done wachten, dit signaal werkte weer. Op dat moment kregen we een andere fout. In de logserver kregen we assert error 3. Deze error krijg je als de teruggestuurde data niet correct is door bv. foutieve encryptie. Om dit te testen hebben we onze AES wrapper als top-level gezet. Deze gebruikt uart om de uitkomst naar onze terminal te sturen. Maar bij het compilen kregen we vreemde errors. Zo kon xilinx uart rx vinden maar uart tx niet. Na wat zoekwerk hebben we dit kunnen oplossen door in de synthese opties ädd IO buffersäan te vinken. Bij het testen van de AES wrapper bleek de output foutief te zijn. Daarom hadden we besloten om met ILA componenten te debuggen. Maar toen we dit deden leek de output wel correct. Dus kon de fout zich nog bevinden in de CBC. Dus hebben we de ILA componenten verplaatst naar de CBC en opnieuw getest. Ook nu leek de output correct. Als volgt hadden we de cryptocore dan maar opnieuw gecompiled. Nu gaf Xilinx een andere error, error 22 point not on curve. De data die de logserver stuurt is correct dus dit zou betekenen dat de elliptic-curve processor niet meer correct zou werken. Maar aan deze processor was niets gewijzigd. Als volgt hebben we alle instellingen van synthesis en mapping nagekeken en op default gezet. Opnieuw gecompiled en nu kregen we geen error 22 meer maar wel foutieve data. Nu dat ”trim unconnected signals¨ uitgevinkt staat, geeft Xilinx een aantal warnings over de microprocessor. Zo hebben bepaalde signalen geen load en staat er een signaal niet in de sensitivity list. Deze fouten hebben we opgelost. Opnieuw hebben we de cryptocore gecompiled en getest. Nu kregen we weer geen done signaal. Op dit moment dachten we dat onze aangepaste AES op een of andere manier de elliptic-curve processor benvloed. We hebben dan een backup project getest en met de originele AES werkt alles. Met onze aangepaste AES werkte het niet meer. Als volgt hebben we de AES opnieuw met ILA componenten getest. Nu was de output wel KHLim

Departement IWT

46

Hoofdstuk 4. Vastgestelde problemen foutief. Het probleem bevind zich al bij de eerste key die wordt gegenereerd. Blijkbaar was de output bij de eerste test toevallig wel correct. De fout moet zich dan bevinden in de laatst gewijzigde code, die we hebben geschreven om het kritiek pad te verkleinen. Want daarvoor hadden we de AES zeer goed getest, en deze werkte volledig correct. In de keyscheduler hebben we dan een lus herschreven. Deze lus keek naar het inverse signaal wat niet nodig was, misschien dat Xilinx dit verkeerd interpreteerde. Bij het debuggen waren de keys nog steeds foutief. Voor de rest is de code in de keyscheduler hetzelfde als in de werkende versie. Hier hebben we dus niets meer aangepast. Als we in de warnings gaan kijken staat nu dat er 1-bit latches zijn. Deze hebben we weggewerkt en vervolgens de AES gesimuleerd om zeker te zijn dat de werking nog correct is. Dan hebben we opnieuw gedebugged, maar de keys kloppen nog altijd niet. In de warnings stond dat een aantal signalen een combinatorische loop vormden. Er zat dus een combinatorische loop in ons ontwerp. Maar als we de signalen nakeken zagen we deze loop niet. Daarom hebben we ”view RTL schematic”geopend. Hierin kan je het schema van de volledige AES bekijken, maar dit is te groot en dan crasht het programma. We hebben daarom enkel de signalen van de combinatorische loop opgegeven. Nu zagen we dat enable s eigenlijk het inverse is van done s. En deze twee signalen vormden een combinatorische loop. In de code was er een process waar we de done beschrijven afhankelijk van de enable. Maar in de FSM wordt de enable geschreven afhankelijk van die done. Dus hebben we dit herschreven en opnieuw gecompiled. Er waren geen warnings meer buiten signalen die niet gebruikt werden. Maar de AES werkte nog steeds niet. Als volgt hebben we ook nog een done genuine signaal volledig herschreven. Hier stond niets van in de warnings, maar de code leek voor ons problematisch om te vertalen naar hardware. Uiteindelijk werkte de AES volledig bij het debuggen. We hebben de AES in de cryptocore geplaatst en ook de cryptocore werkt nu. Dankzij onze eerder opgedane ervaring bij het debuggen van de AES, hebben we dit probleem veel sneller kunnen oplossen.

KHLim

Departement IWT

47

Hoofdstuk 5. Besluit

Hoofdstuk 5 Besluit

KHLim

Departement IWT

48

Hoofdstuk 5. Appendix: A

Appendix: A See in [?] for xxxxxx

KHLim

Departement IWT

i

Hoofdstuk 5. Bibliografie

Bibliografie

KHLim

Departement IWT

ii

Optimalisatie van een trusted state voor een gedistribueerd logging concept. Bart Sallaerts

Recommend Documents