Ok, det börjar bli sent, men jag kan inte låta bli att posta några bilder från en sida med extremt detaljerad beskrivning av rotorerna till den gamla ryska, elektromekaniska kryptomaskinen Fialka. Det här är vackert:
Posts Tagged ‘Hårdvara’
Vackra bilder på Fialka-rotorer
March 10th, 2010Hårdvaruimplementationer av SHA-3-kandidater
February 12th, 2010Den senaste tiden har det kommit flera artiklar som beskriver hårdvaruimplementationer av hashfunktioner som är kandidater till NISTs kommande SHA-3-standard. Några av dessa artiklar är Evaluation of Hardware Performance for the SHA-3 Candidates Using SASEBO-GII och An FPGA Technologies Area Examination of the SHA-3 Hash Candidate Implementations och Compact Hardware Implementations of the SHA-3 Candidates ARIRANG, BLAKE, Gr0stl, and Skein.
Det pågår även flera forskningsprojekt där man bygger upp ramverk för att på olika sätt jämföra implementationer (SW och HW) av olika kryptografiska funktioner – krypton, hashfunktioner etc. Ett sådan projekt är Athena-projektet som fokuserar på hårdvaruimplementationer. Ett annat projekt är ECRYPTs eBASH som mer tittar på SW-implementationer över ett stort antal processorarkitekturer.
Ett bekymmer med alla olika HW-implementationer är att det finns så många design- och teknologimässiga frihetsgrader. Är en given implementation optimerad för maximal prestanda eller minimal storlek? Är målteknologin en ASIC-process (och i så fall vilken processnod) eller en FPGA? Vilka teknologispecifika funktioner utntyttjas etc. Det är lätt att det blir en jämförelse mellan äpplen och päron, och kanske äpplen och köttfärslimpa.
I höstas kom artikeln Artikeln High-Speed Hardware Implementations of BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Gr{o}stl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein där man försökt hantera detta. Genom att välja samma målteknologi, samma verktygsflöde, samma metodik och implementationstategi har man försökt skapa implementationer av kandidater som skall gå att jämföra med varandra.
Rapporten ger en bra översiktlig beskrivning av samtliga HW-implementationer som skapats. Målteknologi är en 180nm Standard Cell-process (ASIC) från Faraday och man har tagit design genom syntes ned till nätlista och där gjort prestandaskattningar.
Utifrån ren prestanda når Keccak 21 Gbit/s och vinner med bred marginal:
En mer intressant blir det om man tittar på prestanda kontra storlek på implementationen:
Det verkar som de flesta kandidater ligger inom 40-60 kGates och där återfinns de fem snabbaste kandidaterna. I diagrammet ser man även hur Keccak och Luffa sticker ut prestandamässigt. Vidare är det värt att notera hur mycket mer komplexa de största kandidaterna är, och att det iaf inte ger någon prestandafördel. Om man skulle gå på dessa siffror (och utgår ifrån att säkerheten är lika hög hos alla kandidater) borde Keccak och Luffa ligga bra till samt att BMW och SIMD samt Skein sitta sämre till.
Det jag saknar nu är en bra jämförelse med SW-implementationer, ex från eBASH samt vad andra får fram för resultat av HW-implementationer (ex Athena). Visserligen riskerar det att bli äpplen och köttfärslimpa, men jag tror att den samlade bilden är viktig.
Kör beräkningar på din PS3:a
March 1st, 2009(Har haft dom här länkarna liggande på tok för länge i min lista med intressanta saker…)
Enligt en artikel på Physorg har några forskare på Dartmouth-universitetet släppt ett system + instruktioner för att köra parallella beräkningar på en Sony PlayStation 3 (PS3).
Jag har inte testat på min egen maskin (än), men att döma av webbsidan för systemet är det ganska rätt fram att installera och köra. Är det någon som testat och har några åsikter skulle jag uppskatta en kommentar.
rule30 IP-core släppt
January 12th, 2009I dag släppte vi på InformAsic den cellautomatbaserade slumptalsgenerator byggd på rule30 jag byggt som öppen IP-core. Det tog lite längre tid att få ut den än jag hade hoppats, men nu blev det en bra start på nya arbetsåret.
För den som vill titta på och använda vår IP-core finns den här. Koden är BSD licensierad. Skriven i Verilog (naturligtvis). Förhoppningsvis kommer den till nytta för att exempelvis driva FPGA-baserad test med kontrollerad, slumpmässiga indata. Det är så jag ex använder den för att testa kryptoimplementationer.
Glädjande nog fick vi en del uppmärksamhet för släppet, bland annat i Elektroniktidningen och Elektronik i Norden. Ett litet förtydligande angående Opencores och Sourceforge är att vi på InformAsic tycker att dessa är mycket bra initiativ.
Dock är Opencores en aning (lite väl) knölig att använda, både för utvecklare och användare av cores. Tittar man på många av de (ex Rudolf Usselman) som var med att starta Opencores bor deras cores i dag på andra platser även om det finns information om deras core på Opencores. En sådan lösning skulle säkert kunna fungera för oss också. Vi får se hur vi gör nästa gång, speciellt när vi snart släpper nästa öppna IP-core.
VISA-kort med inbyggd kodgenerator
December 7th, 2008New York Times skriver om en ny typ av VISA-kort som innehåller en generator för engångskoder. Kortet är utrustat med ett numeriskt tangentbord samt en display.
När en kod skall genereras används tangentbordet för att mata in den PIN-kod som autenticierar dig mot kortet. Kortet genererar en engångskod, vilken visas på displayen. Den genererade koden används för att elektroniskt autenticiera kortet.
Konstruktionen motsvarar alltså det ex SEB och Swedbank åstadkommer med sina dosor från Vasco, men nu behöver man inte släpa runt på dosan (jag har aldrig upplevt att det är speciellt betungande) då den finns i kortet.
Jag tycker att detta är en mycket smutt lösning. Dock tycker jag att jag sett liknande teknik förut, bland annat från svenska Cypak.
Säker kommunikation från förr
November 29th, 2008På Boingboing dök det upp en länk till en sida med en helt fantastisk bild på en utrustning för att fixa säker röstkommunikation från förr:
Man förstår att hon ser så glad ut när man får använda en sån fräck pryl. Och bara 275 USD! Vad är väl Sectras Tigertelefoner mot detta?.
Maskinen verkar vara portabel då den har egen matning. Uppenbarligen används någon slags symmetrisk skramlingsteknik då maskinen behöver paras ihop med en annan maskin för att skapa en säker förbindelse. Att döma av annonsen är det Delcon Division, en gammal del av HP som sätter koden/nyckeln i maskinen. Notera att dom påpekar att koden är inlåst i deras valv.
Sökte lite på Delcon Division och fick bland annat upp länkar till gamla nummer av HP Journal från 1967 med artiklar om ultraljudsutrustning skrivet av folk från Delcon Division.
Dagens HW-hack: Wolframs 30:e regel
October 13th, 2008Jag fick en fråga om kryptorelaterade algoritmer som skulle kunna vara lämpliga att köra som exempel i en kurs om system-modellering. Tanken som jag förstod det var att på TLM-nivå simulera SW-funktioner som sedan flyttas till HW.
Intressanta algoritmer behöver både vara enkla att begripa och kunna ge stor skillnad i prestanda, genomströmning etc när funktionen flyttas från SW till HW. Utifrån detta var mitt förslag RC4 (som är enkel, men inte skalar speciellt bra i HW), XTEA, SHA-1 och SHA-2 (256).
Några andra algoritmer man borde kunna sätta i händerna på studenter är eSTREAM-kryptona Grain och Trivium. Båda dessa krypton är relativt enkla att förstå, har intressanta explicita skalbarhetsegenskaper och är välspecificerade med testvektorer, referensmodeller etc.
Sedan slog det mig att en annan, något annorlunda algoritm som skulle kunna användas är Stephen Wolframs cellautomat Rule 30.
Rule 30 är en endimensionell cellautomat som ger upphov till ett slumpmässigt (PRNG) mönster. Rule 30 används som slumptalsgenerator i Wolfram Research Mathematica. En fördel med att använda en endimensionell cellautomat är att den enkelt går att rita upp och grafiskt verifiera.
De första iterationerna av regel 30 samt de styrande tillståndskombinationerna.
En annan kul egenskap är att algoritmen är trivialt parallelliserbar, detta då alla celler kan uppdateras samtidigt. Antagligen går det att göra bra SW-implementationer, inte minst om man tar till SSE-instruktioner alt GPU-acceleration, men en ren HW-implementation blir väldigt enkel.
Jag blev så inspirerad av Rule 30 att jag satte mig ned och hackade ihop ett par implementationer. Först en version i Python (naturligtvis) för att få koll på att jag tänkte rätt. Det blev inte speciellt många rader kod, ca 20 inkl kommentarer. Och jag är säker på att om man är en riktig Pythonista går algoritmen att stampa ner till ett fåtal rader kod, ex med lite list comprehensions.
Sedan hackade jag ihop en RTL-generator (i Python) som kan generera Verilogkod för en Rule30-automat med godtyckligt antal bitar. Den genererade konstruktionen består väsentligen av ett tillståndsregister med en bit för varje cell. För varje cell finns det sedan en enbitars 8-till-1-MUX som implemeterar uppdateringsregeln.
En sak man behöver fundera på är vad som händer för första resp sista biten i arrayen. Jag har valt att göra en ring av arrayen. Detta innebär att vid uppdatering av den högsta biten tittar vi på bit 0 och tvärs om. Implementationsmässigt innebär detta två separata ledningar som går från kant till kant, inte bara lokalt mellan ett cellregisters närmaste grannar.
Jag genererade några stycken versioner av min Rule 30-konstruktion och använde sedan Alteras verktyg Quartus II för att implementera konstruktionen i en Cyclone II-FPGA. Lite resultat:
256 bitar: 687 LEs, 263 MHz
128 bitar: 344 LEs, 358 MHz
64 bitar: 128 LEs, 420 MHz
32 bitar: 64 LEs, 420 MHz
16 bitar: 32 LEs, 420 MHz
8 bitar: 16 LEs, 420 MHz
(Notera att implementationen kräver lika många register som bitar, jag redovisar dock inte det här.)
En snabb analys ger att varje MUX (samt logik för att ladda in ett användarstyrt initialvärde) implementeras med två logikelement (LE). Mellan 64 och 128 bitar ser det ut som att någon form av replikering behöver införas.
Vad gäller klockfrekvensen är 420 MHz max som Cyclone II är specad för. I en annan FPGA, ex Stratix III går det antagligen att få upp klockfrekvensen ytterliggare en bit. Eftersom uppdateringsfunktionen för resp bit består av en 8-1-MUX med ett grinddjup motsvarande ungefär tre NAND2-grindar eller en LE, blir det transportfördröjningen genom FPGA:ns switchnät som sätter gränsen för klockfrekvensen.
Nu är Rule 30 inte en kryptografiskt säker PRNG, men för att vara en PRNG som ger så bra slumpserier så att den duger för Mathematica förbrukar den väldigt lite resurser. Och med 256 PRNG-bitar varje cykel i 263 MHz får vi 67 Gbit/s! (Vilket skulle vara hopplöst att få ut på ett kort och använda utanför FPGA:n.)
Jag tänker slänga upp en version av Verilogkoden, antigen här eller hos InformAsic. Återkommer med det. Nästa steg är att att bygga ut generatorn med stöd för resursdelning, men det gör jag inte i kväll i alla fall.
Att cellautomater har försökt användas i kryptosammanhang finns det flera artiklar som vittnar om. Jag hittade en färsk sådan med titeln LCASE: Lightweight Cellular Automata-based
Symmetric-key Encryption som just tar upp Rule 30. Värd att läsa om du vill veta mer.
Sectras Tiger XS blir NATO-godkänd
October 12th, 2008Enligt en blänkare på Elektroniktidningen har Sectras säkra mobiltelefon Tiger XS godkänts för användning av kommunikation av säkerhetsklassad information i NATO.
Kul att se framgång för svensk kryptoteknik. Sedan kanske det är värt att påpeka att Tiger XS inte är en mobiltelefon, utan en röstkrypterare som beter sig ungefär som ett Bluetooth-headset gentemot en vanlig mobiltelefon. En i mitt tycke mycket smartare lösning än att utveckla en specifik telefon.
Skydd av FPGA-konstruktioner med PUF:ar
September 29th, 2008För ett tag sedan skrev jag om olika tekniker för att stoppa kloning av konstruktioner. En av dessa byggde på PUF:ar – Physically Unique Functions utvecklade av företaget Verayo.
I samband med det hittade jag artikeln Offline HW/SW Authentication for Reconfigurable Platforms om att använda PUF:ar för att skydda FPGA-konstruktioner. Jag undrade då hur det gick att implementera PUF:ar i en så kontrollerad och reglerad struktur som i en FPGA. Jag hade artikeln sum lunchläsning och vet nu lite mer. Och jag är rätt besviken.
Problemet författarna försöker lösa är att hindra att inköpt SW som exekveras på en processor implementerad i en FPGA kopieras. Själva processorn och annan HW implementerad i FPGA:n skyddas genom krypterad konfigurationsfil. Men SW lagrad i externt minne har inte samma skydd. Författarna skriver:
A hardware platform, designed by a System Developer, will be configured into an FPGA. The System Developer will also use third-party software IPs that execute on top of the platform. The System Developer can apply bitstream encryption to protect the hardware configuration in the FPGA, but an additional hardware-software authentication mechanism is needed to protect the software IPs.
Det är alltså inte systemutvecklarens väl och ve man avser att skydda utan leverantören av programvarukomponenten. Och tricket är att implementera en PUF i FPGAn. Alltså att FPGA-leverantören bygger in en PUF, inte att FPGA:n struktur används för att implementera en PUF. Dvs deras sjyddar inte SW implementerade i system på dagens FPGA:er, utan kräver att FPGA-leverantörerna bygger in en PUF-funktion i sina kretsar.
Då den föreslagna metoden innebär ökade produktionskostnader för karaktärisering av varje FPGA, samt att FPGA-leverantören skall skicka upp information om alla tillverkade kretsar på en server låter detta inte speciellt troligt.
Och när författarna testat sitt nya protokoll har dom inte ens använt en riktig PUF-modell:
We have not yet built a PUF implementation, but have simulated its behavior using another AES block with a fixed key.
En riktigt usel och irriterande artikel. Tur att min lunchlåda var extra smaskens. Dessutom hade jag en annan, mycket bättre artikel att läsa. Mer om den senare.
Sidokanalsbaserat skydd mot kretskloning
September 18th, 2008För några dagar sedan bloggade jag om företaget Verayo och deras PUF-teknologi för att stoppa kretskloning. I dag sprang jag på en artikel på EE Times om en annan teknik för att stoppa kretskloning, och den här är riktigt fräck.
Algotronix har utvecklat en mycket intressant teknik kallad DesignTag som gör det möjligt att skydda konstruktioner byggda med FPGA-kretsar. Problemet med SRAM-baserade FPGA-kretsar är att de tappar sin konfiguration när matningen försvinner. Konfigurationen måste därför laddas in från ett externt minne, exempelvis ett FLASH-minne. Och det gör att vill någon klona konstruktionen är det bara att läsa av konfigurationen mellan minnet och FPGA-kretsen.
(I det här läget skall det påpekas att FPGA-leverantörer som Altera och Xilinx har lösningar baserade på krypterad konfigurationsfil där kryptonyckeln lagras internt i FPGA-kretsen och strömsätts med batteri. Detta gör det även möjligt att bygga aktiva skalskydd.)
Algotronix DesignTag försöker stoppa detta genom att för varje konstruktion generera ett unikt konstruktionsblock som identifierar konstruktionen. Genom att läsa av identiteten går det att avgöra vilken konstruktion det är och därmed avgöra om konstruktionen är stulen eller ej.
Och det fräcka är hur DesignTag kommunicerar kretsens ID. DesignTag kommunicerar genom kretsens värmeutveckling!
När FPGAn startar börjar DesignTag-blocket att göra en massa operationer som ökar och minskar värmeutveckling vilket får temperaturen på utsidan av kapseln att variera. Hur temperaturen varierar beror på identiteten. Genom att läsa av temperaturen går det att få fram kretsens identitet. Fräckt eller hur?!
Enligt artikeln implementerar DesignTag ett enkelt LFSR-baserat strömkrypto där identiteten är nyckeln. LFSR-kedjan ger upphov till en PRNG-sekvens som styr värmegeneratorn. Vet man inte att det finns DesignTag aktivt i kretsen ser variansen (förhoppningsvis) ut som slumpmässiga temperaturvariationer.
Det står inte hur värmegeneratorn fungerar. Gissningsvis är det något som ger upphov till stora registeromslag och aktivitet. Ett antal styrbara T-register och/eller multiplikatorer med operander som ger upphov till långa carry-kedjor.
DesignTag-kommunikationen kan knappast vara speciellt snabb så antalet bitar som skickas är antagligen inte så stor. Enligt artikeln stängs DesignTag-blocket av efter 15 minuter.
DesignTag-blocket behöver antagligen kalibreras för varje familj av FPGA-kretsar den används för att kunna ge en bra varians i temperaturen. Vidare går det säkert att bygga en mekanism som detekterar om det finns DesignTag i en konstruktion eller ej. Dels borde det gå att attackera LFSR-kedjan och särskilja DesignTag-mönstret från normal slumpmässig temperaturvariation. Om inte annat borde det gå att vänta 15 minuter och se om det händer något med temperaturen.
Men att kommunicera genom temperaturen är ett otroligt elegant sätt som gör att DesignTag inte behöver ställa några krav på tillgång till kretsens ben.
Verayos teknik gör det möjligt för en krets att själv avgöra om den är klonad eller ej. Men samtidigt är det enkelt för skurken att kontrollera om han lyckats slå ut Verayos teknik eller ej. Algotronix teknik ger inte kretsen möjlighet att avgöra om den är klonad eller ej, men är desto svårare att upptäcka om man inte letar efter den.
Krypto, FPGA-kretsar och sidoattacker – tre önskningar i ett. Kan det bli bättre?
