Kryptoblog

eSTREAM-projektet presenterade sin portfölj med strömkrypton i april i år. Portföljen som då presenterades inkluderade fyra krypton i profil ett avsedda i första hand för SW-implementation och fyra krypton i profil två avsedda för inbyggda system och hårdvaruimplementationer. Dessa krypton var:

Profil ett:

• HC-128
• Rabbit
• Salsa 20/12
• Sosemanuk

Profil två:

• F-FCSR-H v2
• Grain v1
• Mickey v2
• Trivium

Sedan april har det hänt en del. Det mest direkta är att eSTREAM-portföljen har uppdaterats med den stora förändringen att F-FCSR-H plockats bort från profil två.

Skälet till detta är att Hell och Johansson skrivit en artikel kallad Breaking the F-FCSR-H stream cipher som tydligen visar en praktiskt genomförbar artikel mot F-FCSR-H. Artikeln skall presenteras på Asiacrypt i december, men tydligen stämmer resultatet då eSTREAM valt att plocka bort F-FCSR-H.

Några andra eSTREAM-krypton som inte ser ut att må speciellt bra är Trivium och Salsa 20, speciellt Trivium ser ut att må dåligt.

I höstas kom Adi Shamirs kubattack som i artikeln innehåller en allvarlig attack mot Trivium. Under hösten har även kommit ett par andra attacker mot Trivium.

I oktober kom artikeln Transforming chosen IV attack into a key differential attack: how to break TRIVIUM and similar designs med en komplexitet på 2**68.

En annan artikel, Slid Pairs in Salsa20 and Trivium, som attackerar både Trivium och Salsa 20 kom i slutet av september. Författarna Deike Priemuth-Schmid och Alex Biryukov skriver:

The stream ciphers Salsa20 and Trivium are two of the finalists of the eSTREAM project which are in the final portfolio of new promising stream ciphers. In this paper we show that initialization and key-stream generation of these ciphers is slidable, i.e. one can find distinct (Key, IV) pairs that produce identical (or closely related) key-streams.

There are 2**256 and more then 2**39 such pairs in Salsa20 and Trivium respectively. We write out and solve the non-linear equations which describe such related (Key, IV) pairs. This allows us to sample the space of such related pairs efficiently as well as detect such pairs in large portions of key-stream very efficiently.

We show that Salsa20 does not have 256-bit security if one considers general birthday and related key distinguishing and key-recovery attacks

Det ser allvarligt ut, men läser man Daniel J Bernsteins svar verkar det inte vara en attack som är bättre än brute force:

These claims are entirely without merit. The “attacks” on Salsa20 are vastly more expensive than the standard brute-force attacks discussed in the original Salsa20 documentation.

Vad gäller Trivium, med tre olika attacker på kort tid, skulle jag inte bli förvånad om den åker ut ur eSTREAM-portföljen och jag skulle vara försiktg att använda den.

Det som gör mig en aning bekymrad är att flera attacker alltså dykt upp strax efter att eSTREAM-projektet avslutats och porföljen presenterats - efter fyra år av utvärderingar.

Om man vore lite konspiratoriskt lagd skulle man kunna få för sig att det är mer prestige och publiceringsvärde i att attackera accepterade och utvalda algoritmer snarare än kandidater. Detta är naturligtvis rent trams, men om det skulle vara så vore det bekymmersamt för forskningen och andra försök att ta fram bra algoritmer - exempelvis för NISTs SHA-3-tävling.

En sista sak om eSTREAM värd att notera är att kryptot Rabbit, enligt en postning av Erik Zenner på eSTREAM-forumet, har fått ändrad licens:

On behalf of Cryptico A/S, the company who designed the Rabbit stream cipher, I’m happy to relay the following:

“Rabbit has been released into the public domain and may be used freely for
any purpose.”

So in retrospect, I think that it was a good decision not to make patent issues a key criterion for the eStream portfolio: The patent status can change, the algorithmic properties can’t.

Tyvärr är inte detta det mest officiella av uttalanden, och dessutom saknar jag information om hur Cryptico avser att agera vad gäller sina patent relaterade till Rabbit. Jag har letat på Cryptico A/S webbplats för att hitta ett mer officiellt uttalande, men där finns inte mycket nyheter.

Jag har kontaktat Erik Zenner för att se om det går att få ett mer officiellt uttalande. Hör jag något publicerar jag det här. eSTREAM-projektets text om licensen för Rabbit har i alla fall inte uppdaterats:

Cryptico A/S currently has patents pending on Rabbit. The algorithm is provided royalty-free for non-commectical use. Licenses for commercial use may be obtained from Cryptico A/S.

Om jag själv skall välja krypton från eSTREAM skulle jag i första hand gå på HC-128 och kanske Salsa 20. I profil två skulle jag välja Grain och Mickey, men då använda versionerna med 128 bit nycklar som inte kostar mer i implementation (bortsett från sex Bytes längre nyckel). Inbyggda system förtjänar lika bra skydd som PC-system.

Jag har gjort en liten uppdatering av min Pythonimplementation av strömkryptot Snow. Det jag har ändrat är två saker:

1. Utökat test/exempelkoden med samtliga testvektorer i specifikationen för Snow 2.0
2. Fixat en bugg i initieringen av kryptot relaterat till initialvektorn (IV)

Helt kort kan man säga att jag insåg att jag varit extremt slarvig och inte testat ordentligt med IV skild från noll. I initieringen av 128-bit nyckel med IV skild från noll genererade min version inte korrekt värden då jag missat IV-ord två (i mängden IV[0..3]). Den buggen är nu fixad.

Den nya versionen av kryptoimplementationen finns på samma plats som förut, men har fått nytt versionsnummer och uppdaterat releasedatum. Naturligtvis är även signatur och filstorlek uppdaterade.

Min nya hobby att implementera krypton i programspråket Python har den senaste veckan gjort att jag pillat med kryptot Snow.

Snow är ett strömkrypto av Thomas Johansson och Patrik Ekdahl vid LTH. Den version av Snow jag implementerat är Snow 2.0 som kom 2002. Snow 2.0 var en av kandidaterna till NESSIE-projektet och har även använts som jämförelse med kandidater i eSTREAM.

Det finns en nyare version av Snow kallad Snow 3G. Snow 3G är det krypto som används som bas i algoritmerna EUA2 och EIA2 för att säkra kommunikationen i 3G. Jag har ännu inte lagt in stöd för Snow 3G. En sådan förändring skulle dock vara relativt enkel - det som krävs är väsentligen att lägga till ett extra register i FSM:en.

Snow arbetar på 32-bitars ord och kryptot består i grunden av ett skiftregister (en LFSR-kedja) med 16 steg samt en tillståndsmaskin (FSM) med två 32 tillståndsregister - R1 och R2.

Uppdateringen av LFSR-kedjan sker genom återmatning av tidigare värden som mixas samman genom två multiplikationer, vilka är implementerade med tabeller. Uppdateringen av R2-registret i FSM:en sker genom en S-box (baserad på S-boxen i AES) där indata är värdet i R1. Totalt sett finns det sex stycken tabeller i den här implementationen av Snow.

Min implementation av Python är en fristående klass med metod load_key() för att ladda nyckel och IV, samt en metod gen_keyword() för att generera nästa nyckelströmsord. Klassen stödjer både 128- och 256-bitars nyckel.

LFSR-kedjan och FSM:en är sammankopplade på ett relativt intrikat sätt och att få ordning på ordningen i uppdateringen i ett sekventiellt program visade sig vara lite klurigt. Men genom att dumpa alla interna tillstånd gick det att få ordning på sekvenserna. Min implementation av Snow inkluderar därför en metod för att dumpa interntillståndet. När ett objekt av Snow skapas går det även att ange hur pratig (verbose) den skall vara när den utför en metod.

Ett litet exempel (hämtat från exempelkoden):

my_snow = Snow(False)
my_key = [0x00000000, 0x00000000, 0x00000000, 0x80000000]
my_iv = [0x00000000, 0x00000000, 0x00000000, 0x00000000]

my_snow.load_key(my_key, my_iv)
my_snow.gen_keyword()

Detta ger (med lite utskrifter och en loop):

key:
[0, 0, 0, 2147483648L]
iv:
[0, 0, 0, 0]
running key 0: 8d590ae9
running key 1: a74a7d05
running key 2: 6dc9ca74
running key 3: b72d1a45
running key 4: 99b0a083
running key 5: fb45d13f
running key 6: cf9411bd
running key 7: 9a503783
running key 8: a98265ae
running key 9: bf2dc77f
running key 10: f2eb41e4
running key 11: aa896508
running key 12: 19d8ab8f
running key 13: 2eb8077f
running key 14: 78f8c1f1
running key 15: 9d4c5ce2

Rent och snyggt gränssnitt om jag får säga det själv, HW-nisse som jag är (så vad vet jag?).

Jag har testkört på min laptop med 2GHz Core 2 Duo-processor. Generering av 10.000.000 värden tar 135 sekunder, vilket ger ungefär 295 kByte/s. Inte kanonsnabbt, men vill man ha en ren Pythonimplementation av en applikation där det finns ett behov av att skydda data med hjälp av ett bra krypto kanske den här implementationen kan vara användbar.

Min implementation av Snow finns på sidan för nedladdning. Det finns ett par korta exempel i main()-funktionen med testvektorer för 128- och 256-bit nycklar hämtade från specifikationen för Snow 2.0.

Koden är BSD-licensierad och jag hoppas att den kommer till nytta. Mycket nöje!

Dörren för kandidater till NISTs hashfunktionstävling stängs om ett par dagar (2008-10-31). Att döma av trafiken på maillistan kommer det att dyka upp ett flertal kandidater. Men än så länge har inte speciellt många blivit officiella.

Först ut var Ron Rivest och hans kollegor som presenterade hashfunktionen MD6, även kallad Pumpkin Hash. MD6 är ett relativt stort steg från den struktur nuvarande SHA-algoritmerna har. MD6 bygger upp en komplext träd med många subnoder. Trädet processas sedan nerifrån och upp - på något sätt. Det ser komplicerat och kostsamt ut. Men enligt Rivest & Co skall det gå att enkelt serialisera processningen för att köra på små processorer, och samtidigt parallellisera för hög prestanda på multicore-maskiner och i hårdvara.

I dag presenterades en annan kandidat kallad Skein. Skein är skapad av Niels Ferguson, Stefan Lucks, Bruce Schneier, Doug Whiting m.fl. Enligt en postningen om Skein på Schneiers webbplats är hafunktionen byggd på ett blockkrypto kallad Threefish (vilket borde betyda släktskap med Blowfish och Twofish). Bruce skriver:

Skein is fast. Skein-512—our primary proposal—hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core—almost twice as fast as SHA-512 and three times faster than SHA-256…

Skein is secure. Its conservative design is based on the Threefish block cipher. Our current best attack on Threefish-512 is on 25 of 72 rounds, for a safety factor of 2.9…

Skein is simple. Using only three primitive operations, the Skein compression function can be easily understood and remembered. The rest of the algorithm is a straightforward iteration of this function.

Skein is flexible. Skein is defined for three different internal state sizes—256 bits, 512 bits, and 1024 bits—and any output size. This allows Skein to be a drop-in replacement for the entire SHA family of hash functions. A completely optional and extendable argument system makes Skein an efficient tool to use for a very large number of functions: a PRNG, a stream cipher, a key derivation function, authentication without the overhead of HMAC, and a personalization capability.

Jag planerar att komma med mer detaljerad information när kandidaterna officiellt publicerat. Men det börjar dra ihop sig och det börjar se spännande ut.

Jag satt och surfade spännande artiklar på fantastiska arXiv och sprang på en märklig artikel.

Artikeln P is not equal to NP av Sten-Åke Tärnlund verkar hävda att den bevisar att P är skilt från NP.

Vad det handlar om är alltså den del av komplexitetsteori som säger att det antagligen finns problem som inte går att beräkna på polynomiell tid, dvs en separat klass med problem som för trivialt antal element inte går att beräkna svaret på. Det har länge spekulerats att NP inte är en del av P och frågan är av sådan betydelse att det finns ett pris på en miljon USD för den som kan visa att NP är skilt från P.

Skälet till att detta är så intressant för IT-säkerhet är att det finns ett antal algoritmer där säkerheten beror på att problemen är NP-hårda. Ett sådant problem är Knapsack-problemet som används i kryptosystem med publika nycklar. Över huvud taget görs ofta antaganden om att algoritmer är NP-hårda, och därmed att NP-problem egentligen inte är P-problem. Wikipedia ger ett bra exempel:

Consider, for instance, the subset-sum problem, an example of a problem which is “easy” to verify, but whose answer is believed (but not proven) to be “difficult” to compute. Given a set of integers, does some nonempty subset of them sum to 0? For instance, does a subset of the set {−2, −3, 15, 14, 7, −10} add up to 0? The answer “yes, because {−2, −3, −10, 15} add up to zero”, can be quickly verified with a few additions. However, finding such a subset in the first place could take much longer. The information needed to verify a positive answer is also called a certificate. Given the right certificates, “yes” answers to our problem can be verified in polynomial time, so this problem is in NP.

An answer to the P = NP question would determine whether problems like the subset-sum problem are as “easy” to compute as to verify. If it turned out P does not equal NP, it would mean that some NP problems are substantially “harder” to compute than to verify.

Jag kan på tok för lite matte för att hänga med i Tärnlunds artikel. Den som fixar matten och kan kolla om det håller och om det gäller generellt eller ej får gärna höra av sig. Artikelns sammanfattning är kort och verkar hävda att generellt sett är P skilt från NP:

SAT !∈P is true, and provable in a simply consistent extension B′ of a first order theory B of computing, with a single finite axiomB characterizing a universal Turing machine. Therefore P !=NP is true, and
provable in a simply consistent extension B′′ of B.

SAT som artikeln hänvisar till är Boolean Satisfiability-problemet som tidigare visat sig vara NP-komplett. Det Sten-Åke verkat visa är hur detta resultat går att generalisera till alla NP-problem. Om jag fattar rätt.

Googlar jag på Sten-Åke Tärnlund hittar jag att han är (har varit?) professor i datalogi vid Uppsala universitet.

För en dryg månad sedan postade jag om Cory Doctorows vigselringar designade av Bruce Schneier och Isabel Rucker samt den tävling i att utveckla krypton baserade på ringarna som de utlyste. Nu har tävlingen avgjorts.

Vinnaren blev Chris Smith och hans Figdet Protocol (länken går till en zipfil med dokumentation, c-kod, exempel samt en fräck simulator som går att bygga med pappersremsor. På andra plats kom Philippe Teuwen. Philippes bidrag, ett polyalfabetiskt substitutionsskiffer beskrivs utförligt på Philippes egen sida och inkluderar exempelkod i Python.

Nummerstationer är radiostationer som sänder sekvenser av nummer, oftast upplästa av en artificialla röster. Källorna bakom dessa radiostationer är generellt sett okända och inte heller syftet med stationerna är kända. Den vanligaste förklaringen är att det är ett sätt för organisationer att skicka meddelanden till agenter som befinner sig på uppdrag på annan ort.

Nummerstationer dök enligt Wikipedia upp redan under första världskriget, men finns även i dag. För den som är nyfiken kommer här lite information om nummerstationer (även om Wikipdias sida i sig är mycket bra). Radion NPR i USA har gjort ett reportage om nummerstationer. Den här sidan skriven av en radioamatör berättar om nummerstationer. Simon Mason har skrivit en bok kallad Shortwave Espionage som berättar om nummerstationer.

Det finns flera projekt som på olika sätt bevakar nummerstationer. The Conet Project innehåller en massa information om olika nummerstationer och där går det även att tanka hem och lyssna på olika inspelade meddelanden utsända av nummerstationer.
‘
Det finns även de som försöker tolka och avkoda, dekryptera de meddelanden som skickas av nummerstationer. Två sådana sidor är Spynumbers samt The Number Stations Crack Challenge på Irdial.

Det finns musiker som tagit fasta på nummerstationer och gör musik av utsändningar från nummerstationer.

Att sitta en kulen och regnig kväll och lyssna på dessa röster är nästan lite kuslig. Ofta kvinnoröster eller vad som låter som barn som utan några variationer i betoning läser upp serier av nummer utan att man begriper varför och vad det betyder. Väldigt märkligt.

Jag 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.

Fö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.

Fö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?