Kryptoblog

Svenska Yubico som utvecklar den fräcka OpenID-nyckeln Yubikey har valt att öppnat upp sin källkod.

På Yubicos sida för utvecklare finns information och länkar till bland annat hur man sätter upp OpenID-server som använder Yubico samt API:er i .Net, Ruby, Java, PHP samt en PAM-modul för att bygga webbtjänster som kan använda Yubico för autenticiering. Slutligen finns det ett grundbibliotek i Java och C för att dekryptera och tolka de OTP-lösenord som Yubico genererar.

En kul detalj är att Yubico valt att lägga upp koden på Google Code. Vidare har Yubico valt att inte försöka vara smarta och klura till en egen, förvirrande och avskräckande licens, utan det är BSD-licens rätt av.

Yubico har även publicerat en säkerhetsanalys av Yubico utförd av Simon Josefsson, av en av Sveriges duktigaste säkerhetstekniker som arbetat mycket med design och implementation av exempelvis DNSSEC, Kerberos, OpenPGP. Väl värd att läsa.

Jag är generellt tveksam till hembyggda säkerhetsalgoritmer. Men Yubico gör nog så bra man som ett företag kan göra. Publicera inte bara resultat utan hela analyser. Inte försöka låsa in teknologin utan öppna upp API:er, kod och använda licenser som ger stor frihet. Då blir andra intresserade att titta närmare på, analysera och använda teknologin.

Jag gillar YubiKey för att den för mig som användare är så enkel att använda. Och nu är det enkelt även för utvecklare och säkerhetsanalytiker att integrera och bedöma YubiKey-teknologin. Att döma av Yubicos webbplats är deras affärsmodell att sälja YubiKey-nycklar och tjänster kring dessa, att då öppna upp teknologin borde borde vara i samklang med affärsmodellen.

Smart, bra och kul att se ett företag som grokkat hur Internet, säkerhet och öppen kod-världen fungerar.

På USENIX-konferensen Large-Scale Exploits and Emergent Threats 08 (LEET08!) presenterade Samuel T. King, Joseph Tucek, Anthony Cozzie, Chris Grier, Weihang Jiang och Yuanyuan Zhou en mycket intressant artikel om hårdvarubaserade trojaner.

Artikeln Designing and Implementing Malicious Hardware, som utsågs till konferensen bästa artikel, är något av det mest intressanta och skrämmande jag läst på länge. Artikelns sammanfattning beskriver väl vad den handlar om:

Hidden malicious circuits provide an attacker with a stealthy attack vector. As they occupy a layer below the entire software stack, malicious circuits can bypass traditional defensive techniques. Yet current work on trojan circuits considers only simple attacks against the hardware itself, and straightforward defenses. More complex designs that attack the software are unexplored, as are the countermeasures an attacker may take to bypass proposed defenses.

We present the design and implementation of Illinois Malicious Processors (IMPs). There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one specific attack, can instead design hardware to support attacks. Such flexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware.

We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well.

Malicious processors are more practical, more flexible, and harder to detect than an initial analysis would suggest.

Författarna börjar med att beskriva hur olika attacker rört sig nedåt från applikation och OS till firmware och till virtualiseringssystem. Men, frågar sig författarna, hur svårt är det att modifiera en hårdvarukonstruktion, en processor, så att den dels gör systemet som kör på hårdvaran osäkert, och om det går att göra så att systemet inte märker av modifieringen.

Författarna har valt att modifiera open-source-processorn LEON3 från Göteborgsbaserade Gaisler Research.

LEON3-processorn är placerad i ett högst ordinärt och typiskt HW-system med USB-kontroller, VGA-kontroller m.m. På LEON3-processorn kör man sedan ett normalr GNU/Linux-system. Hela klabbet har realiserats på en Xilinx-FPGA.

I LEON3 har man sedan implementerat olika attacker. Den första attacken är en modifiering till LEON3-processorns MMU som gör att en process som känner till modifieringen kan trigga procesorn att ignorera minnesskydd och låta processen ge sig själv rootaccess. Författarna förklarar:

Our memory access mechanism provides hardware support for unprivileged malicious software by allowing access to privileged memory regions. Malicious software triggers the attack by forcing a sequence of bytes on the data bus to enable the memory access circuits. This sequence can be arbitrarily long to avoid false positives, and the particular sequence must be agreed upon before deployment.

Once the sequence is observed, the MMU in the data cache ignores CPU privilege levels for memory accesses, thus granting unprivileged software access to all memory, including privileged memory regions like the operating system’s internal memory. In other words, loading a magic value on the data bus will disable protection checking.

We implement this technique by modifying the data cache of our processor to include a small state machine that looks for the spe-cial sequence of bytes, plus some additional logic in the MMU to ignore privilege levels when malicious software

Författarna beskriver även en shadow-mod som gör det möjligt att gömma trojan genom att skapa en extra processormod, och kod som körs i denna mod döljs från resten av systemet. Denna shadow-mod används sedan av författarna för att implementera en funktion som snor lösenord samt ett sätt att implementera en bakdörr rätt in i OS:et. Mycket imponerande, fräckt och skrämmande.

Det författarna visar är hur lite som krävs för att implementera den här typen av funktioner. Författarna lade till mindre än 200 rader kod till VHDL-koden LEON3 består av. Minnesmodifieringen krävde knappt 1000 gates och shadow-funktionen drygt 1300 gates. Närmast avrundningsfel i en modern HW-konstruktion.

Författarna avslutar sin artikel med en diksussion om hur man kan skydda sig mot den här typen av attacker. Bla om man kan använda sidoeffekter för att detektera om en krets utför operationer man inte tänkt. Författarna konstaterar att det i dag antagligen finns få/inga vettiga skyddmekanismer, vilket jag håller med om.

Frågan man bör ställa sig i det här läget är dock: Men hur stor är risken egentligen?

Som exempel på ett ökande risk för trojaner i hårdvarukonstruktioner citerar författarna en rapport från USAs Department of Defence Science Board som bland annat skriver att

First, it has become economically infeasible to procure high performance ICs other than through commercial suppliers. Second, these commercial suppliers are increasingly moving the design, manufacturing, and testing stages of IC production to a diverse set of countries, making securing the IC supply chain infeasible. Together, commercial-off-the-shelf (COTS) procurement and global production lead to an “enormous and increasing” opportunity for attack

Att det finns problem med äktheten hos kretsar visar om inte annat att det nu bildas organisationef för att försöka stävja den snabbt ökande förekomsten av piratkopierade kretsar.

Det är inte så svårt att tänka sig att dessa kretsar skulle kunna innehålla mer än den piratkopierade konstruktionen. Man får ett mervärde man kanske inte hade tänkt sig. (Tomas Gilså uppmärksammade detta i en artikel om risker med piratkopierade routrar och switchar - ja jag är citerad.

På Cryptography-listan kommenterade Karsten Nohl trenden mot snabbt ökande komplexitet på chipnivå och användningen av IP-cores med:

Hardware designs currently move away from what in software would be open source. Chip obfuscation meant to protect IP combined with the ever increasing size of chips makes it almost impossible to reverse-engineer an entire chip.

Helt sant. I dag bygger man chip med allt fler och allt större IP-cores. Men hur vet man att dom faktiskt bara gör det dom säger att dom gör. Att kontrollera att konstruktionen följer en spec är en sak, men att visa att den även kan göra något mer?

Så möjligheten att modifiera konstruktioner, och den vägen få in en elak HW-funktion finns, frågan är om det finns kompetens och motivation? Kompetens kan man tyvärr köpa, så frågan är om någon är intresserad. Skall man döma av den snabbt ökande ekonomiska IT-brottsligheten finns det en hel del som är beredda att jobba hårt och lägga mycket pengar på att vara elaka.

Den här artikeln har uppmärksammats en del på krypto- och säkerhetslistor. Även Matt Blaze har bloggat kloka tankar som är värda att läsa. I diskussionen på Cryptography påpekades det att mikrokoden i Intels och AMDs processorer går att uppdatera. Hur kontrolleras att den mikrokod som laddas ner är ok? Någon som vet?

Jag tycker att artikeln som presenterades på LEET08 är mycket, mycket intressant. Och jag hoppas att artikeln får uppföljning i form av metodik och verktyg för att inspektera HW-konstruktioner och chip. Jag tror att vi kommer att behöva återkomma till den här frågan.

Picasa-användaren Dribbel har postat några fina bilder på en gammal kryptomaskin från 80-talet.

TexTell är som namnet säger en maskin som omvandlar text till ljud och från ljud till text. Man håller tydligen maskinen mot telefonen och skickar krypterade meddelanden precis som med ett gammalt 300 bauds modem (eller antagligen mer som 75 baud). Själva hörlusmojen är integrerad i baksidan av enheten:

På baksidan finns även instruktioner som förklarar hur man kommunicerar säkert med hjälp av TexTell:

Att döma av texten är maskinen byggd av West-Tec LTD på Irland. Google ger bara en firma kallad Burglar Alarms & Security Systems West-Tec Security Systems på Irland, inget mer (som jag hittar).

Enligt en postning blev TexTell stoppad att visas på CeBIT-mässan i Hannover 1983. Ingen information om hur kryptodelen i TexTell fungerar (fungerade). Är det någon läsare som vet mer om TexTell så posta gärna!

Söt liten 0ldsk00l-maskin är det i alla fall…

Jag har tidigare skrivit om MiFare-systemet och dess uppenbarligen urusla säkerhet. Sedan dess har det kommit ytterligare en attack där forskare från Holland visade att de genom att samla in en mängd data och sedan bearbeta dessa offline kunde återvinna den 48-bit långa nyckeln i MiFare Classics krypto CRYPTO1. Men nu har det kommit ett resultat till.

I en artikel på IACR av Nicolas T. Courtois, Karsten Nohl och Sean O’Neil kallad Algebraic Attacks on the Crypto-1 Stream Cipher in MiFare Classic and Oyster Cards visar författarna att säkerheten i MiFare är riktigt, riktigt trasig. Författarna skriver:

MiFare Crypto 1 is a lightweight stream cipher used in London’s Oyster card, Netherland’s OV-Chipcard, US Boston’s CharlieCard, and in numerous wireless access control and ticketing systems worldwide. Recently, researchers have been able to recover this algorithm by reverse engineering [11, 13].

We have examined MiFare from the point of view of the so called algebraic attacks. We can recover the full 48-bit key of the MiFare algorithm in 200 seconds on a PC, given 1 known IV (from one single encryption).

The security of this cipher is therefore close to zero. This is particularly shocking, given the fact that, according to the Dutch press, 1 billion of MiFare Classic chips are used worldwide, including many government security systems.

Som en läsare på Kryptoblog tidigare påpekat används även MiFare Classic i GL:s nya kontaktlösa biljettsystem här i Göteborg.

Egenhackade krypton är ofta en riktig usel idé, Ett egenhackat krypto med 48-bit nyckel känns riktigt brunt. Men det här kanske leder till bättre kravställning vid upphandling av den här typen av system. Man kan väl hoppas i alla fall…

HC-128, Rabbit, Salsa20/12, SOSEMANUK, F-FCSR-H v2, Grain v1, Mickey v2 och Trivium!

För ett par dagar sedan skrev jag en bloggpostning om slutspurten i eSTREAM och avslutade med att nu är det bara att vänta och se vad de kloka kryptologerna kommer fram till. Det visade sig att väntan blev kort.

Samtidigt som jag skrev min postning blev eSTREAM klar och dagen samtidigt med att jag postade uppdaterades eSTREAM. Så kan det gå. Och tack till den läsare som påpekade att resultatet var klart - jag hängde inte alls med.

Nå, resultatet är klart och vad skall vi då säga om det? Massor!

En första spontan kommentar är att det är kul att det blev så många algoritmer som fick en plats i den slutgiltiga eSTREAM-portföljen. Det blev inte en algoritm i vardera profilen (profil ett - snabba SW-algoritmer och profil två - effektiva i HW och inbyggda system), nej vi fick fyra algoritmer i respektive profil!

Detta gör iofs att det inte blir en algoritm som alla kommer att använda (jämför med AES), men samtidigt öppnar det upp att kunna välja utifrån krav och preferenser. Om man exempelvis inte kan leva med att Rabbit bara får användas fritt i icke-kommersiella tillämpningar finns det tre andra algoritmer i profil ett.

De ansvariga, kloka kryptologer som organiserat eSTEAM har publicerat en rapport kallad The eSTREAM Portfolio som beskriver arbetet som utförts i eSTREAM, varför de algoritmer som inkluderats i portföljen har valts samt varför andra algoritmer inte valdes. Vad gäller eSTREAM som aktivitet skriver de att:

The goal of eSTREAM was to stimulate work in the area of stream ciphers. In this, undoubtedly, the project has been a success. While eSTREAM has much of the appearance of a competition such as that used to establish the AES (or the forthcoming SHA-3) this comparison should be resisted.

We prefer not to use the word “winners”, or to necessarily pick one (or even two) algorithms as the sole outcome of eSTREAM. Rather, we are conscious that most of the stream ciphers in the portfolio are very new and while we believe them to be promising—for a variety of reasons—we must leave it to others to decide when analysis is sufficiently mature for an algorithm to be considered in standards or used in a deployment.

Jag personligen vill ändå kalla algoritmerna som valdes in i portföljen som vinnare. De har genomgått ett ganska rejält stålbad och bland de 30+ kandidater blivit en av åtta som tog sig hela vägen fram. Vad gäller Profil ett-algoritmerna skriver eSTREAM-arrangörerna att:

The goal for ciphers submitted to Profile 1 was that they should be “good” in software. By this we meant that they should significantly outperform the AES when used in a suitable stream cipher mode and all the final phase ciphers in Profile 1 achieve this.

Our vision wasn’t necessarily of a stream cipher that had a good all-round profile; our focus was on raw encryption speed with a bias towards encrypting large amounts of data after a single initialisation. Our intended security level was set to 128 bits which we believe to be adequate for contemporary applications.

Det man lyckats med bland profil ett-algoritmerna är att få en bra spridning på typen av algoritm, dvs basen för hur kryptot fungerar. HC-128 är ett extremt snabbt krypto som arbetar med stora tabeller (som iofs tar lång tid att initiera) vilket gör den intressant för bulk-kryptering.

Rabbit är ett gammalt krypto (visades publikt på FSE 2003) och har klarat sig utan större problem sedan dess. Rabbit är även ett snabbt krypto, och utan omfattande initieringsfaser.

Salsa20/12 är ett snabbt och skalbart krypto, men bygger på delvis nya principer - även om det klarat sig bra genom eSTREAM. Sosemanuk å sin sida bygger på delar från gamla krypton.

Vad gäller Profil två-algoritmerna skriver eSTREAN-organisatörerna att:

The goal for ciphers submitted to Profile 2 was that they should be “good” in constrained hardware environments. By this we meant that ciphers should significantly out-perform the AES in a restricted environment in at least one significant regard. The final phase candidates in Profile 2 were chosen because we believed they had the potential to achieve this.

We were anticipating that ciphers in Profile 2 might be suitable for deployment on passive RFID tags or low-cost devices such as might be used in sensor networks. Such devices are exceptionally constrained in computing potential because of the number of logic gates available or the amount of power that might realistically be available.

Our intended security level for this profile was 80 bits which we believe to be adequate for the lower-security applications where such devices might be used.

Som jag skrivit tidigare tycker jag att det är bra att man hade en separat profil för inbyggda system och att HW-implementationer togs i beaktande. Men jag tycker att det var synd att man hade 80 bitar som säkerhetsnivå för denna profil, något som många andra uttryckt som ett problem under hela eSTEAM-arbetet.

Jag ser inte att inbyggda system klarar sig med sämre säkerhet. Snarare är det så att dessa system är i användning under längre tid och uppdateras mycket mer sällan än PC-system. Detta, anser jag talar snarare för att inbyggda system behöver högre säkerhet, inte minst för att många av dessa system används för att automatisera, dvs styra och reglera den infrastruktur vi alla är beroende av.

Slutligen, att 48 bitar dvs sex Bytes skulle kosta för mycket för ett inbyggt system köper jag inte. Det som är intressant är hur många bitar som interntillståndet i kryptot kräver - RC4 som exempel kräver 256 Bytes (plus minst 16 bitar till för pekare).

Av de algoritmer som till slut hamnade i portföljen är det dock bara Trivium som har en nyckellängd på 80 bitar, de andra (F-FCSR, Grain och Mickey) har alla 128 bitars nycklar. Bra.

Bland profil två-algoritmerna är spridningen av nytänkande och konservatism stor. F-FCSR-H bygger på principer som testats sedan 90-talet. Grain å sin sida är imponerande, både i sin grundläggande enkelhet och sin skalbarhet (något jag gillar skarpt). Mickey är väsentligen två (stora) skiftregister, men har stått upp bra mot alla attacker som kastats mot den. Trivium slutligen är ett experiment i enkelhet och nytänkande som visade sig hålla hela vägen. Kul!

Det jag kan tycka är lite synd är ingen av de kandidater som skickades in till båda profilerna fick vara kvar hela vägen. Salsa20 skickades in som kandidat till båda profilerna, men fick bara fortsätta som profil ett-algoritm, även om den går bra att implementera i HW. Grain å sin sida är mycket snabb även i SW, och Grain borde (anser jag) fått vara med som profil ett-krypto.

eSTREAM har lett till en stor hög med forskning, undersökningar och artiklar. Bara eSTREAMs egen artikelsida listar 205 olika artiklar, och till det skall läggas allt som publicerats på konferenser och andra ställen. På eSTREAMs diskussionsforum har det varit aktivitet under hela arbetet, ett forum där diskussionerna (speciellt när DJB varit inblandad) gått höga. Jag inbillar mig att detta varit bra för kryptoforskningen över huvud taget.

En sak jag noterar är att fyra av vinnar-algoritmerna är representerade bland de som organiserat eSTREAM. Steve Babbage (Mickey), Christophe De Canniére (Trivium), Anne Canteaut (SOSEMANUK), Henri Gilbert (SOSEMANUK), Thomas Johansson (Grain) och Bart Preneel (Trivium). Jag tror inte att det handlar om att eSTREAM letts av några av de bästa kryptologerna, vilka naturligvis har rätt att skicka in kandidater.

En annan sak jag noterar är att forskningsorganisationen COSIC är starkt representerad, både i organisationskommitén (med bland annat Vincent Rijmen och Bart Preneel) i de vinnande bidragen. Hongjun Wu (HC), Bart Preneel (Trivium), har alla COSIC som arbetsplats. COSIC är antagligen Europas, kanske världens just nu bästa institution för kryptoforskning.

Hur var det då med den internationella aspekten på eSTREAM? Rätt bra tycker jag att det ser ut som. De krypton som hamnade i portföljen kommer från Frankrike (SOSEMANUK, F-FCSR), Belgien (HC, Trivium), England (Mickey), Danmark (Rabbit), Sverige (Grain), Schweiz (Grain) och USA (Salsa20/12). Inga från Asien och få personer från USA.

Så, eSTREAM är över. Vad skall man göra nu? Jag tänker göra två saker: Bevaka NISTs AHS-tävling samt börja jobba med att göra bra HW-implementationer av eSTREAM-algoritmerna.

Jag har tidigare byggt testimplementationer av Salsa20, Grain, Mickey och Trivium och tycker att de är trevliga algoritmer. Jag skall försöka bygga implementationer av de andra algoritmerna i portföljen. Men Rabbit skuttar jag över - på grund av dess licens.

Vad jag har sett är Salsa20 är något problematisk vid routing (dra ledningar på chip). Min erfarenhet är även att Mickey är mycket lättare att skala än vad de flesta som beskrivit HW-implementationer för eSTEAM hävdar. Förhoppningsvis kan jag publicera lite siffror på implementationsresultat för eSTREAM-algoritmer senare under 2008.

Det var det hele. Tack eSTREAM för den tid som varit! Nu skall jag äta frukost.

(BTW: Nu är även Wikipedias sida om eSTREAM uppdaterad.)

Just nu finns det en Hagelin C-36 kryptomaskin till salu på eBay.

Maskinen till salu på eBay.

Boris Hagelins C-36 är en mekanisk kryptomaskin från tiden för andra världskriget. Maskinen är byggd i Stockholm av A.B Cryptoteknik

Är du kryptofantast och har en massa pengar du inte vet vad du skall göra av med är det bara att kasta in ett bud.

Ulrich Drepper, pappa till glibc, har skrivit ett imponerande dokument om minnessystem kallat What Every Programmer Should Know About Memory.

Dokumentet är en genomgång av väsentligen allt du som programmerare (och andra) skulle kunna vara intresserad av vad gäller minnessystem.

Från grundläggande koncept som vad en minneshierarki är, vad som menas med sidor, rader och block och vad ett cacheminne är till information om hur ett DD3-minne arbetar, cache trashing i multicore-system, olika typer av uppdateringspolicy för cacheminnen, minnessystem med icke-uniform access (NUMA, COMA) och mycket, mycket mer.

Det här dokumentet innehåller material motsvarande en rejäl högskolekurs i datorarkitektur och jag önskat att jag hade haft det här dokumentet när jag började arbeta med processor- och datorarkitektur. Och jag är glad att jag har det nu.

Dokumentet är inte utan sina fel och brister, det erkänner Drepper själv utan omsvep i sin blog. Men av det jag har läst tycker jag att han inte bara har bra koll på såväl övergripande koncept såsom detaljer, utan har även en förmåga att uttycka dom.

Och varför skall du nu läsa detta dokument? Speciellt med tanke på IT-säkerhet? Jo, därför att dokumentet bland annat förklarar varför varianser i accesstid till en tabell med data (exempelvis en S-box i ett krypto) kan uppstå, vilket kan leda till oönskade sidoeffekter.

I en tid när antalet processorkärnor går upp (kärnor som på olika sätt är kopplade till varandra via ett delvis gemensamt minnessystem) blir det allt svårare att gissa hur minnesaccesser och därmed exekveringstiden för ett program kommer att fungera. Att som programmera då kunna läsa på vilka effekter som kan uppstå och hur man kan mäta och hantera dessa effekter är helt klart ett steg framåt.

.SE (Stiftelsen för Internetinfrastruktur) har testat tolv routrar för hem/konsumenter och då fokuserat på routrarnas förmåga att hantera säker DNS-uppslagning. Av de tolv fick tre stycken godkänt, sju befanns ha märkbara problem med DNS och två hade så grava problem att de inte gick att testa på ett vettigt sätt. Patrik Wallström, projektledare för forskning och utveckling på .SE förklarar:

Det stora problemet ur ett DNSSEC-perspektiv är att majoriteten av hemmaroutrarna inte har klarat av DNSSEC ner på applikationsnivå på datorn. Det är inget problem så länge valideringen sköts av till exempel Internetlevantörens DNS-resolver, men däremot när en applikation på klienten kräver egen DNSSEC-validering.

Läser man i testrapporten hittar man bland annat den här närmare beskrivningen av problemen man funnit:

De vanligaste felen har varit frågor och svar över TCP, problem med AD-biten i svaret samt när klienten vill validera DNSSEC själv (DO-biten satt i frågan).

Resultatet av testerna är nedslående. Vad som står ut mest är andelen routrar som inte klarar av DNS-frågor över TCP. Men det stora problemet ur DNSSEC-perspektiv är att majoriteten inte klarar av DNSSEC ner till applikationsnivå på datorn.

Det är inget problem så länge valideringen sköts av t.ex. Internetleverantörens DNS-resolver, men när det tillkommer en applikation på klienten som begär egen DNSSEC-validering fungerar det i de flesta fall inte alls.

.SE kontaktade tillverkarna för att få deras kommenterar och fann att:

Några har återkommit med varierande grad av engagemang, och en har faktiskt tagit problemet på allvar och kommit med åtgärder.

Testerna inkluderar maskiner från D-Link, Netgear, Linksys, Zyxel, FON, Zonet och Gigabyte. Enligt uppgift är Zyxel den leverantör som tog problemet på allvar.

För mer information rekommenderas läsning av .SE:s testrapport.

Det har dykt upp än ny attack mot KeeLoq.

I höstas blev det en hel del uppmärksamhet om den attack som Biham & Co lyckades genomföra mot kryptot i KeeLoq. Jag postade flera gånger om denna attack, bland annat om att KeeLoq-användaren Volvo noga följde utvecklingen.

KeeLoq är alltså en krets från Microchip som används i trådlösa autenticieringsmekaniser och KeeLoq är väldigt vanlig i trådlösa lås på bilar, speciellt dyrare bilar exempelvis från Jaguar och Volvo.

Det Biham & Co visade var att det finns fundamentala brister i kryptomekanismerna som gör att det går att räkna ut nycklar, både enskilda nycklar och de huvudnycklar som används i samtliga bilar av en viss modell. Den här attacken krävde inte heller årtionden av beräkningstid, utan går så fort att man bör kunna anse attacken som praktiskt genomförbar.

Och som det brukar vara i sådana här sammanhang - hittar någon en brist, ett fult sår och varböld dyker det raskt upp fler som vill dit och peta och rota. Eftersom någon visat att det finns något värt att publicera och få uppmärksamhet kring finns det säkert mer att gräva fram och få del av uppmärksamheten. Liknande beteende tycker jag mig bla se vad gäller attacker mot hashfunktioner.

Några som inte tvekade att peta på KeeLoq är Thomas Eisenbarth, Timo Kasper, Amir Moradi, Christof Paar, Mahmoud Salmasizadeh och Mohammad T. Manzuri Shalmani. Vad de upptäckte var att det finns problem med inte bara de bakomliggande algoritmerna hos KeeLoq, utan det brister även i implementationen. Mer specifikt finns det brister som öppnar upp för sidoattacker.

Deras artikel Physical Cryptanalysis of KeeLoq Code Hopping Applications beskriver det här:

Recently, some mathematical weaknesses of the KeeLoq algorithm have been reported. All of the proposed attacks need at least $2^{16}$ known or chosen plaintexts.

In real-world applications of KeeLoq, especially in remote keyless entry systems using a so-called code hopping mechanism, obtaining this amount of plaintext-ciphertext pairs is rather impractical.

We present the first successful DPA attacks on numerous commercially available products employing KeeLoq code hopping. Using our proposed techniques we are able to reveal not only the secret key of remote transmitters in less that one hour, but also the manufacturer key of receivers in less than one day. Knowing the manufacture

(Notera att artikeln ligger på IACR och den behöver därmed inte varit granskad.)

Författarna skriver om tidigare presenterade attacker mot KeeLoq att:

To our knowledge, most of the commercial implementations of KeeLoq as a remote keyless entry system employ the code hopping mechanism. Thus, the described attacks are not considered as a big threat for their security.

Artikeln beskriver två olika attacker. Båda attackerna bygger på att man mäter förändringar i strömförbrukningen som en effekt av att kretsarna utför sina KeeLoq-operationer.

In 1999, Kocher et. al [5] proposed several methods for analyzing the information leakage of implementations of security related systems. The most powerful attack in this area is called DPA (Differential Power Analysis) and exploits power consumption traces of cryptographic hardware to reveal confidential information.

Almost ten years later, DPA remains an attack mostly performed in smart card evaluation labs and universities, only targeting their own known implementations.

…

We introduce two DPA attacks on KeeLoq code hopping systems. The first reveals the secret device key from an integrated circuit that performs the encryption in a transmitter. The second attack is executed on the receiver to recover the manufacturer key from a software implementation running on a microcontroller.

För det första artikeln skriver författarna:

By analyzing the power traces, we found out that there is a specific hardware inside the chip to perform the KeeLoq encryption.

…

We performed this attack on several chips with different part numbers in DIP or SOIC packages. We are able to recover the secret key of KeeLoq encoders in DIP packages from only 10 power traces. Clearly, SOIC packages benefit from a smaller process technology so the power consumption values are smaller than DIP packages. Hence, the SNR (signal-to-noise ratio) is decreased and we need more power traces. Still, at most 50 power traces are sufficient to reveal the secret key of a device in an SOIC package.

Författarna går sedan vidare och visar hur de kan attackera frekvenshoppsmekanismen även i mottagaren. Författarnas slutsats är klar:

lthough some theoretical attacks on the KeeLoq algorithm have recently been reported, none of them is able to break the code hopping systems in a reasonable time. We illustrated the difficulties of those attacks in the presence of different key derivation schemes.

…

In this paper we presented the first successful practical attacks on KeeLoq code hopping systems. These very effective attacks represent a real practical threat for many commercial applications employing the KeeLoq algorithm.

Alltså attacker mot verkliga implementationer av KeeLoq som går på rimlig tid och fungerar i verkligheten.

Jag hoppas att Volvo inte bara följer detta med intresse, utan även arbetar med att lösa problemet. Det lär nog behövas…

Kretsanalysföretaget FlyLogic Engineering har precis publicerat att man hittat en bakdörr i ett par av Atmels CryptoMemory-kretsar, mer specifikt AT88SC153 och AT88SC1608.

Atmels CryptoMemory är ett litet minne med autenticiering och säkerhetsmekanismer avsedda att skydda innehållet i minnet. Tyvärr har det varit lite skralt med informationen om hur säkerhetsmekanismerna egentligen fungerar. Jag har därför varit nyfiken på att få se en analys som visar om kretsarna är säkra eller ej.

Nu visar FlyLogic att minnena inte bara är svaga vad gäller skyddet av minnet mot fysiska attacker, utan att det för ett par av kretsarna även verkar finnas avsiktliga brister. FlyLogic skriver:

Section 5 of the datasheet labled, “Fuses” clearly states, “Once blown, these EEPROM fuses can not be reset.“

This statement is absolutely false. UV light will erase the fuses back to a ‘1′ state. Care must be used to not expose the main
memory to the UV or else it too will erase itself.

…

Reading deeper into the datasheet under Table 5-1, Atmel writes, “When the fuses are all “1″s, read and write are allowed in the entire memory.“

As strange as it reads, they really do mean even if you have setup security rules in the configuration memory, it doesn’t matter. The fuses override everything and all memory areas are readable in the clear without the need for authentication or encrypted channel! The attacker can even see what the “Secure Code” was (it is not given out in the public documentation, nor with samples). Atmel was even kind enough to leave test pads everywhere so various levels of attackers can learn (entry to expert).

…

Of all the other CryptoMemory products, only the AT88SC153/1608 has this backdoor. We have successfully analyzed the entire CryptoMemory product line and can say that the backdoor doesn’t exist in any other CryptoMemory part.

Dvs, det finns alltså EEPROM-säkringar på kretsen som Atmel säger inte skall gå att återställa efter att de bränts av. Men det går dom att göra. Och, här kommer det hemska,: om man gör det spelar det i de här kretsmodellerna ingen roll vilka säkerhetsmekanismer (som CryptoMemory erbjuder), det går att läsa ut innehållet i alla fall. Oops!

Nu brukar man säga att man inte tro att något är gjort av elakhet, när dumhet mycket väl kan ligga bakom. Men att som FlyLogic skriver bara dessa två modellerna i kretsfamiljen har detta problem är märkligt. Vem var/är målkunden? Eller vem fick Atmel att göra detta - och varför i så fall just dessa modeller? (Känns nästan som det är dags för ett foliehatt-party!)

Vad gäller säkerheten för CryptoMemory i sin helhet är FlyLogics bedömning:

None of the CryptoMemory parts are actually as “secure” as they make it seem. The words, “Smoke n’ Mirrors” comes to mind (It is almost always like that).