K.U.Leuven Faculteit Toegepaste Wetenschappen 2e Kand. Burg. Ir. 2003-2004 PROJECTWERK Sleutels kraken met een chronometer (E9) Ontwerpverslag Uitgevoerd door: Onder leiding van: Groep 20 Lejla Batina, Christophe De Canniere Ostes Kristel ESAT Wu Ling SCD/COSIC Wuille Pieter Lokaal ESAT 01.58 en 01.69
Inhoudstafel 1. Analyse van het probleem 3 1.1 Algemene situering 1.2 Doelstelling van dit project 1.3 Data Encryption Standard 1.4 Smartcards 2. Verschillende oplossingswijzen en argumenten 4 2.1 Waarom zelf DES schrijven? 2.2 Waarom werd ons de programmeertaal C voorgesteld? 3. Beschrijving van de gekozen oplossing 5 3.1 DES-implementatie 3.2 Analyse uitvoeringstijden 4. Experimenten en resultaten 6 4.1 Uitgevoerde experimenten 4.2 Geplande experimenten Referenties 6 2
1. Analyse van het probleem 1.1 Algemene situering Naarmate computers (en hun toepassingen) een belangrijker plaats innemen in onze hedendaagse samenleving, wordt het beveiligen van data communicatie steeds meer essentieel. In het kader hiervan heeft er zich een tak in de wetenschap ontwikkeld, nl. de cryptografie, die zich bezig houdt met het opstellen van algoritmes (en sleutels) en ander technieken voor het versleutelen van gegevens. Er zijn verschillende factoren die een rol spelen bij de zoektocht naar algoritmes: - Snelheid: het algoritme mag niet te ingewikkeld zijn omdat er anders te veel tijd wordt gestoken in het coderen/decoderen en het moet ook inverteerbaar zijn, vandaar dat men vanuit dit standpunt zou kunnen opteren voor het gebruik van lineaire vergelijkingen - Veiligheid: men wil dat het algoritme niet gemakkelijk te kraken valt (op wiskundige basis). Er zijn 2 fundamentele technieken die hiervoor gebruikt worden: confusion (bedoeld om de relatie tussen sleutel en versleutelde tekst zo complex mogelijk te maken) en diffusion (zodat een willekeurige bit wijzigen in de plaintext op zoveel mogelijk bits in de ciphertext invloed heeft). Men begrijpt alvast dat men vanuit dit opzicht wil opteren voor niet-lineaire vergelijkingen. In ieder geval zou het de bedoeling moeten zijn om geen statistisch verband tussen plaintext en ciphertext te kunnen vinden. Een algoritme moet zo gekozen worden dat de bovengenoemde factoren optimaal in rekening worden gebracht. Er is ook nood aan gestandaardiseerde algoritmes, aangezien dezelfde tekst moet kunnen geencrypteerd/gedecrypteerd worden door verschillende mensen. Een voorbeeld hiervan is DES (Data Encryption Standard). Tot enkele jaren geleden was DES het meest verspreide publieke cryptografische systeem in de wereld. Het werd gebruikt voor elektronisch geldverkeer, bescherming van niet militaire communicatiesatellieten en een variant van DES wordt nu gebruikt voor het UNIX paswoordbeveiligingssysteem. De wiskundige algoritmen die gebruikt worden om gegevens te versleutelen zijn echter zelden perfect, en naargelang nieuwe aanvallen worden ontdekt, worden steeds betere en veiligere algoritmen voorgesteld. Toch is een veilig algoritme op zich nog geen garantie voor een goed beveiligd systeem. Zo is de laatste jaren gebleken dat de praktische implementatie van cryptografische algoritmen, zowel in software als in hardware, in vele gevallen onverwachte achterpoortjes opent. Aanvallen die hiervan gebruik maken worden gewoonlijk "side-channel attacks" ("nevenkanaal aanvallen") genoemd en een typisch voorbeeld is het kraken van chipkaarten door nauwkeurig het stroomverbruik op te meten. Ook door tijdsvariaties te bestuderen valt er informatie over de sleutel te achterhalen. 1.2 Doelstelling van dit project De bedoeling van dit project is het bestuderen van side-channel attacks. Meer specifiek voeren wij een timing-attack uit: moderne processoren beschikken over een cache, dat bedoeld is om geheugentoegangen te versnellen. Dit introduceert tijdsvariaties aangezien er zgn. cache-hit en cache-mis kunnen optreden. Hieruit kan informatie omtrent de geheime sleutel ontfutseld worden, waardoor op een zeer goedkope manier (in vergelijking met andere methodes zoals brute-force attacks) de sleutel in theorie achterhaald kan worden. We gaan in dit project na wat de praktische haalbaarheid van deze timing-attacks is door een simulatie te maken op PC. 3
We zullen ons vooral concentreren op het encryptie-algoritme DES, gezien het een relatief eenvoudig algoritme is waarvan er reeds zwaktes zijn aangetoond (toch wel jammer dat DES nauwelijks nog gebruikt wordt, tenzij in de vorm van een slimme hack die DES 3x na elkaar toepast met 2 verschillende sleutels, genaamd Triple-DES). 1.3 Data Encryption Standard DES encrypteert blokken van 64-bits (of 16 hexadecimale cijfers), gebruik makend van 64- bits sleutels (waarvan in feite enkel 56 bits gebruikt worden). In DES wordt confusie verwezenlijkt door gebruik te maken van S-Box substituties (dit zijn verschillende tabellen met permutaties waarin weinig of geen patroon te herkennen valt), dit zorgt tevens voor de niet-lineariteit. De diffusie daarentegen wordt gerealiseerd d.m.v. opeenvolgende eenvoudige translocaties. In totaal worden 16 rondes doorlopen om eventuele regelmatigheden te minimaliseren. 1.4 Smartcards Dit onderzoeksdomein heeft vooral zijn praktische toepassingen bij smartcards (eenvoudige veilige cryptoprocessors, die ingebed zitten in kredietkaarten of nog kleiner - zoals de GSM SIM-kaarten). Een volgende generatie zal gebruik maken van cache-geheugen, zodat ze kwetsbaar kunnen worden voor timing-attacks. 2. Verschillende oplossingswijzen en argumenten De voorgeschreven oplossingsmethode is zelf een DES-implementatie schrijven op PC en daarop analyses uitvoeren qua rekentijd. 2.1 Waarom zelf DES schrijven? Er zijn hopen DES-implementaties te vinden in de literatuur en op internet, deze zijn echter ofwel voor educatieve doeleinden (niet voldoende op de praktijk toegespitst) ofwel veel te specifiek geoptimaliseerd (dus moeilijk te doorgronden in een beperkte tijd). Bovendien hebben we hierdoor het voordeel om vertrouwd te geraken met enerzijds het DES-algoritme zelf en anderzijds met de programmeertaal en -omgeving. 2.2 Waarom werd ons de programmeertaal C voorgesteld? - C is een relatief eenvoudige taal (en we beschikten reeds over een minimale kennis Java, wat qua syntax vergelijkbaar is) - C is erg snel (het compileert onmiddellijk na vele optimalisaties tot machinetaal die direct op de processor uitgevoerd kan worden), bovendien biedt het voldoende mogelijkheden voor het inbouwen van low-level routines (zoals assembler-instructies) - Hoewel de object-geörienteerde structuur van C++ erg aanlokkelijk is, is deze niet vereist voor het schrijven van encryptie-algoritmes die vooral snel moeten zijn. - Er zijn reeds veel DES-implementaties in C beschikbaar, waaruit we eventueel inspiratie kunnen halen. - C is in theorie platform-onafhankelijk (wij hebben echter low-level routines nodig die ons zullen dwingen één specifieke omgeving te kiezen). 4
3. Beschrijving van de gekozen oplossing 3.1 DES-implementatie Zoals reeds vermeld gaan we voor de simulatie gebruik maken van een zelfgeschreven implementatie van DES in C (die op moment van schrijven reeds functioneel is). We zijn vertrokken van een uiterst simplistische benadering (di. zonder optimalisaties), wat een snelle weg tot een functioneel algoritme was. Onze opdracht bestaat er in DES te kraken door meten van snelheden, zodat het geheel meer zin heeft als we een realistischer (lees: sneller) algoritme aanwenden. Daarom hebben we vrijwel alle onderdelen reeds (1 of meerdere malen) vervangen door efficiëntere varianten, waarbij in eerste plaats tabellen eenvoudiger toegankelijk werden gemaakt, samengevoegd met andere tabellen, of vervangen door functies die rekening houden met de specifieke orde die in deze tabellen voorkomt (en dus sneller zijn). Een probleem waar we reeds mee geconfronteerd werden, zijn de bitvolgordes. Intern gebruikt het IA-32 platform (Intel Pentium, opvolgers & afgeleiden) een zogenaamde Little-Endian (of LSB) notatie, doch de specificaties van DES gaan uit van vrij - op z'n minst - eigenaardige volgordes. Voorlopig is dat probleem opgelost door bij de in- en uitvoer routines een gepaste permutatie van de bits toe te passen. Dit is geen probleem, aangezien we onze metingen kunnen beperken tot specifieke stukken code. Om die reden zijn ook de routines die de subkeys initialiseren weinig geoptimaliseerd, ze dragen niet echt bij tot de snelheidsvariaties die we willen meten, nl. in de encryptierondes. Nog even opmerken dat er verschillende encryptiemodes zijn (zoals ECB en CBC), die bepalen op welke manieren de block cipher aangewend wordt om datastromen van langer dan 1 blok te coderen. Wij werken op het niveau van de block-cipher zelf, en hoeven ons daar dus weinig van aan te trekken. 3.2 Analyse uitvoeringstijden Voor het meten van uitvoeringstijden hebben we een heel nauwkeurige methode nodig (aangezien DES-encryptierondes in minieme tijden uitgevoerd worden op de processoren van de PC's waarop we onze aanvallen gaan simuleren). Deze metingen zullen een nauwkeurigheid tot op nanoseconden vereisen, wat een platform-specifiek probleem is. Gezien onze eigen computers op het IA32-platform gebaseerd zijn, ligt het voor de hand om voor dit platform te kiezen. Vanaf de Pentium-processor is de 'rdtsc' instructie, die het aantal uitgevoerde cpu-cyclussen sinds het opstarten opvraagt, beschikbaar. Hiermee is het mogelijk zulke precieze tijdsmetingen uit te voeren op stukken code. Deze instructie kan niet zonder meer vanuit C aangeroepen worden, en er is dus nood aan een asm -blok. De syntaxis van zulk een blok is echter ver van gestandaardiseerd, en we hebben voor de opensource C-compiler GCC gekozen. Deze platform-afhankelijke code is echter wel in een aparte sourcefile geplaatst, wat het porten (omzetten naar een ander platform) vergemakkelijkt. 5
4. Geplande experimenten en verwachte resultaten 4.1 Uitgevoerde experimenten Omdat onze implementatie, voor zover we konden nagaan, correcte resultaten gaf (we hebben onze uitvoer gecontroleerd aan de hand van verschillende testvectoren), hebben we besloten om reeds over te stappen tot het feitelijke probleem: het analyseren van uitvoeringstijden. De eerste test die we gedaan hebben, is verschillende plaintexts encrypteren met behulp van dezelfde sleutel (elke plaintext wel meerdere malen) en de variaties in encryptieduur opmeten m.b.v. de hierboven genoemde rdtsc instructie (terwijl af en toe de cache gewist werd). Op de geteste processoren was de opgemeten tijd tussen de 900 en de 1500 cyclussen (per 64-bit blok), wat vrij aanvaardbare resultaten zijn. Er waren duidelijke verschillen waar te nemen tussen verschillende computers. Op sommigen verschenen mooie patronen na enkele encrypties (verschillende encryptieduur voor verschillende plaintexts en soms zelfs gelijke encryptieduur voor gelijke berichten), terwijl andere steeds weer exact hetzelfde resultaat gaven. De tweede test bestond erin eenzelfde rij van verschillende plaintext enkele malen opnieuw te encrypteren, zonder de cache ondertussen te wissen. Ook hier vertoonden sommige processoren deterministische variaties (ook blijken sommige berichten langer te duren dan anderen, onafhankelijk van wanneer de encryptie gebeurt), terwijl anderen halsstarrig vasthielden aan die ene zelfde duur... 4.2 Geplande experimenten De volgende stap zal zijn het volgen van enkele van de hieronder gespecifieerde artikels om te proberen hun resultaten te reproduceren. We mogen hopen dat we daarna in staat zijn een functioneel algoritme te vinden dat in staat is een bekende sleutel te achterhalen. Misschien is het daarna mogelijk een uiteindelijke test als volgt te doen: de computer genereert een willekeurige DES-sleutel, codeert hiermee een bekende plaintext, zonder dat de sleutel getoond wordt. Daarna zou een timing-attack mogelijk zijn met de geheime sleutel die zich nog steeds in het geheugen verschuilt. Als dat zou slagen, kan ze geverifieerd worden door de ciphertext te decoderen. Referenties 1. Y. Tsunoo, T. Saito, T. Suzaki, M. Shigeri, H. Miyauchi, Cryptanalysis of DES Implemented on Computers with Cache, Springer-Verlag 2003 2. D. Page, Theoretical Use of Cache Memory as a Cryptanalytic Side-Channel, http://www.cs.bris.ac.uk/tools/reports/abstracts/2002-page.html 3. A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography, pag. 250-259 4. J. Orlin Grabbe, The Des Algorithm Illustrated, http://www.orlingrabbe.com/des.htm 5. S. Keller, M. Smid, NIST Special Publication 800-17, Modes of Operation Validation System (MOVS): Requirements and Procedures, http://www.nist.gov 6. FIPS PUB 46-2 Data Encryption Standard, http://www.nist.gov 7. Using the RDTSC Instruction for Performance Monitoring", http://developer.intel.com/drg/pentiumii/appnotes/rdtscpm1.htm 8. S. Landau, Standing the Test of Time: The Data Encryption Standard 6