Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1222
Inbyggda system » Kryptoblog

Archive for the ‘Inbyggda system’ category

En liten 6502-emulator

July 15th, 2008

Vad passar bättre en regntung semesterdag än testkoda en emulator av den gamla processorn MOS 6502?

MOS 6502

Jag kunde i alla fall inte komma på något bättre och hackade lite Python nu på eftermiddagen. 176 rader senare inklusive kommentarer, filhuvud och testfall kan jag i alla fall köra några instruktioner:


js@sotis:/Users/js/tmp>./6502.py
MOS 6502: CPU initializing.
MOS 6502: Dumping memory from 100 to 111
100: ea
101: ea
102: ea
103: ea
104: ea
105: ea
106: ea
107: ea
108: ea
109: ea
10a: ea
10b: ea
10c: ea
10d: ea
10e: ea
10f: ea
110: 60
111: 0
MOS 6502: Running program from start address 100
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing RTS
Cycles executed: 34

(Japp, min emulator räknar bland annat även cykler. Har alltid velat ha den funktionen. Tänk vad många cykler man räknade i sin finniga ungdom när man kodade på C64:an.)

Det saknas en massa instruktioner och jag är inte säker på om jag verkligen skall ha en separat decode-funktion och en exekverings-funktion. Det blir väldigt mycket upprepning av if-elsif-elsif-else i de två funktionerna.

En intressant (nåja) observation är att min emulator, skriven i ett intepreterande språk, antagligen är flera gånger snabbare än den verkliga processorn. Dock inte lika snabb som den variant av 6502 vi byggde in i InformAsics VPN-chip, den går i upp till 33 MHz.

NXP försöker stoppa publicering av MiFare-analys

July 14th, 2008

Jag har postat ett par gånger tidigare om kretstillverkaren NXPs MiFare-system och det egenutvecklade och rejält trasiga kryptot CRYPTO1 som används i Classic-varianter av systemet. MiFare Classic används bland annat av Lokaltrafiken i London och kallas där Oyster Card.

Ett Oyster Card.

Boingboing rapporterar nu att NXP satt press på forskare vid Radboud University i Nijmegen, Holland för att stoppa publiceringen av sina forskningsresultat som visar ännu fler svagheter i MiFare. NXP har helt enkelt stämt forskarna och åberopar säkerhet som skäl att stoppa publiceringen.

Och självklart innebar detta att artikeln NXP försöker stoppa har smitit ut på nätet. Ett tag fanns artikeln på Wikileaks, men försvann. Däremot har den dykt upp både på Cryptome och på ArXiv.

Artikeln A Practical Attack on the MIFARE Classic beskriver enligt sammanfattninen:


The MIFARE Classic is the most widely used contactless smart card in the market. Its design and implementation details are kept secret by its manufacturer.

This paper studies the architecture of the card and the communication protocol between card and reader. Then it gives a practical, low-cost, attack that recovers secret information from the memory of the card.

Due to a weakness in the pseudo-random generator, we are able to recover the keystream generated by the CRYPTO1 stream cipher. We exploit the malleability of the stream cipher to read all memory blocks of the first sector of the card. Moreover, we are able to read any sector of the memory of the card, provided that we know one memory block within this sector. Finally, and perhaps more damaging, the same holds for modifying memory blocks.

Värt att notera att attacken sker över radiogränssnittet (RFID-standarden ISO 14443). Dvs det är inte så att man plockat isär ett MiFare-kort och attackerat chipet, utan försöker efterlikna ett troligt scenario där någon trådlöst försöker klona ett kort.

Artikeln är rejält matig och innehåller en pedagogisk och bra genomgång av hur MiFare Classic fungerar. Då det finns svenska användare av MiFare är det värt att upprepa artikelns rekommendationer:


For short term improvements we recommend not to use sector zero to store secret information. Configure key B as readable and store random information in it. Do not store sensitive information in the first 6 bytes of any sector. Use multiple sector authentications in one transaction to thwart attackers in an attempt to recover plaintext. This is only helpful when value block commands are not allowed. Value block commands are shorter than a read command and will enable a shift of the keystream.

Another possibility, that might be viable for some applications, is to employ another encryption scheme like AES in the backoffice, and store only encrypted information on the tags. To prevent unauthorized modification of a data block, an extra authentication on this data could be added. This authentication
is then verified in the backoffice.

Proper fraud detection mechanisms and extra security features in the backoffice are necessary to signal or even prevent the types of attacks described above. In general, the backoffice systems collecting and processing data that comes from the readers are a very important second line of defense.

On the long term these countermeasures will not be sufficient. The mifare Classic card has a closed design. Security by obscurity has shown several times that at some point the details of the system will be revealed compromising security. Therefore we recommend to migrate to more advanced cards with an open design architecture.

Forskarna har även gjort en fin film som visar hur deras attack går till. Om deras scanning är så snabb som filmen visar är det här riktigt skrämmande:

Vad skall man säga om NXPs agerande? Istället för att arbeta tillsammans med forskarna och exempelvis i samband med publiceringen ordna seminarier för sina kunder om hur de skall agera för att skydda sig och sina kunder lyckas NXP med att:

  1. Reta upp forskarna och förstöra möjligheterna till samarbete

  2. Garantera att artikeln och information om hur MiFare Classic skall attackeras kommer ut på ett okontrollerat sätt

  3. Framstå som ett otrevligt, aggressivt och ett säkerhetsmässigt inkompetent företag

Tre dumheter på samma gång, det är nästan bättre än ett Kinderägg.

Kinderägg.
(Ett Mifare-Kinderägg. Öppna och bli överraskad av NXP)

Slutligen noterar jag att BBC rapporterar att Londons lokaltrafik har problem med sitt Oyster card-system. Oklart om det har att göra med en attack mot CRYPTO1 dock.

En mycket liten AES-implementation

May 6th, 2008

I en diskussion på maillistan för NISTs AES-tävling dök det i helgen upp en länk till en söt implementation av AES skriven av Ilya O. Levin.

Ilyas implementation av AES är Byte-orienterad, vilket gör att den enkelt går att kompilera för 8-bits MCU:er. En annan udda sak med den här implementationen är att den inte innehåller en tabell för S-boxen. Istället räknar programmet ut korrekt substitutionsbyte under körning. Detta tar naturligvis tid, men eliminerar 256 Bytes. Tyvärr öppnar detta troligen även för sidoattacker.

Däremot innehåller koden funktioner för att expandera nyckeln, både för kryptering och dekryptering, och dessa räknas ut i förväg. För kryptering går det att räkna fram round-nyckeln inför respektive round, vilket skulle spara ett antal Bytes till. Och om man inte kör ECB-mod, utan en ström-mod ex CTR-mod behöver man inte ha stöd för dekryptering.

Jag har testat att kompilera koden och det gÃ¥r finfint i vanilj-GCC. Implementationen blir som jag förväntar mig – liten och ganska lÃ¥ngsam. Men vill du fÃ¥ tag pÃ¥ en riktigt liten implementation av AES till ett inbyggt system, eller bara titta pÃ¥ hur krÃ¥nglig AES blir om man försöker göra den sÃ¥ liten som möjligt, kan jag rekommendera att titta pÃ¥ den här implementationen.

MiFare är riktigt trasigt

April 22nd, 2008

Jag har tidigare skrivit om MiFaresystemet 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 48bit 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…

Och eSTREAM-vinnarna är….

April 19th, 2008

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

Kreditkort med RFID – utan skyddmekanismer!

March 20th, 2008

Boing Boing TV (BBtv) har ett reportage frÃ¥n O’Reillys Emerging Technology-konferens som visar hur American Express nya kreditkort med inbyggt RFID-chip visar sig släppa i frÃ¥n sig kortnummer, namn pÃ¥ personen kortet är utställt till och giltighetstiden – detta utan nÃ¥gra som helst krav pÃ¥ autentisering frÃ¥n läsaren eller andra skydd av informationen.

Minst sagt skrämmande. Skrämmande att ett företag som sysslar med krediter 2008 kan släppa en sådan här osäker produkt och skrämande att man uppenbarligen bryr sig så lite om sina kunders säkerhet.

Pablos Holman mannen i videon som demonstrerar attacken, använder en RFID-läsare han enligt egen utsago köpt på Ebay för 8 USD, så mycket är American Express kunder säkerhet värd.

En ny attack mot KeeLoq

February 14th, 2008

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-bild

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…

Kryptanalys av Philips CRYPTO1 på CCC

January 1st, 2008

(Den här nyheten kom på den utmärkta bloggen Cryptanalysis som jag kommer att lägga in i blogrollen.)

På den 24:e CCC-konferensen (Chaos Computer Club) presenterade Karsten Nohl (från University of Virginia) och Henryk Plötz detaljer om Philips proprietära strömkrypto CRYPTO1 som de fått fram genom kryptanalys.

CRYPTO1 är ett krypto som används i kontaktlösa smartcards som följer standarden ISO 14443. Kryptot används för att skydda luftgränssnittet vid kommunikationen mellan läsaren och kortet. Ett exempel på ett kort som implementerar CRYPTO1 är MiFare-kortet från NXP. (NXP är resterna av kretsföretaget VLSI Technology som köptes upp av Philips.)

MiFare

Ganska lite har tidigare varit känt om CRYPTO1 och bland annat har det spekulerats att kryptot är en variant på 3DES. Det Nohl och Plötz nu visar är att CRYPTO1 istället är ett LFSR-baserat strömkrypto. LFSR-kedjan i CRYPTO1 är på 48 bitar med 20 tappar.

Bild från presentationen

Bilder från presentationen på CCC-konferensen finns här.

Som jag fattat det innebär inte detta att kryptot är helt knäckt, och tydligen har det sedan tidigare funnits brute force-attacker. Men att detta antagligen leder till snabbare attacker är nog en inte allt för vild gissning. Vi lär få återkomma.

Uppdatering 2008-01-03:
Albert påpekar i en kommentar att videon nu finns, både hos Google och hos CCC.

Ruptor påpekar i en kommentar att han tidigare publicerat källkod innehållande en attack av HiTag2-kryptot.

Jag blir inte helt klok på om det är samma krypto i HiTag2 och MiFare. Kryptot i källkoden har iaf en 48-bits LFSR-kedja. Någon som vet?

Mer uppdatering 2008-01-03:
Ruptor har även på cryptanalysis sida om den på CCC presenterade attacken länkat till sin kod och även till en PDF med specen för Hitag2. Karsten (som gjort analysen av CRYPTO1) verkar ha tittat på Ruptors kod och kommit fram till att det inte är samma krypto.

Ny biometriprocessor från FPC

December 22nd, 2007

Biometriföretaget Fingerprint Cards (FPC) frÃ¥n Göteborg har släppt en en ny biometriprocessor till sina sensorer. (Ja, för en mÃ¥nad sedan – jag är inte sÃ¥ snabb.)

FPC2020

FPC2020 är anpassad för att fungera med FPCs areasensor FPC1011C.

FPCs areasensor

FPC2020 integrerar hårdvara för bildbehandling, acceleration av biometriska algoritmer och en kontrollprocessor.

Detta gör att man inte som tidigare behöver någon extern processor, ex en ARM eller en AVR. Utan det man behöver för att bygga in en biometrifunktion är en sensor, ett seriellt FLASH-minne, en kristall och FPC2020. (FPC skriver inget om innehållet i FLASH-minnet är skyddat och hur.)

Det finns ett datablad med detaljerad information om FPC2020 inklusive API:t för att använda kretsen. I det kan man bland annat hitta följande information.

Antalet användare som kan hanteras beror på storleken på externa FLASH-minnet. Med 2 Mbit klarar FPC2020 att hantera 223 olika templates. Största FLASH-minnet FPC2020 verkar stödja är 8 Mbit vilket ger kapacitet för 991 templates, men FPC skriver att man bör hålla nere antalet templates till mindre än 500.

Verifiering mot en enskild template tar ca 0.2 sekunder. Registrering (Enrolment) tar däremot hela sju sekunder. Normalt sett gör varje användare en eller ett fåtal registreringar och massor med verifieringar så verifieringstiden är det som är viktigt att få snabbt. Men sju sekunder är ändå tillräckligt lång tid för att man skall börja fundera på om det gick bra eller ej.

Vad gäller säkerheten skriver FPC att False-Rejection-Rate (FRR, dvs man godkänner inte ett tidigare registrerat fingeravtryck) går att justera och beror på indata. Även False-Acceptance-Rate (FAR, dvs man accepterar ett icke registrerat fingeravtryck) är ställbar från 1/1000 till 1/100.000. Vid 1/100.000 får man en FRR på mindre än 7 %.

Säkerhetsmässigt är ett lågt FAR-värde mycket viktigt. Däremot är ett lågt FRR-värde viktigt för att systemet inte skall kännas bökigt att använda.

En liten märklig detalj. Jag hittar ingen information på FPCs webbplats vad som hänt deras sweepsensorer FPC1030 och FPC1031.

Krokodilen?

Bilden ovan hittade jag på den här webbplatsen. På den sidan står det att FPCs sensorer utvecklats av ett företag i Holland kallat Xensor. En annan märklig detalj är att bilden ovan heter Krokodilen?!

Personligen föredrar jag sweepsensorer före areasensorer. Jag tyckte att FPCs sweepsensorer i förhållande till areasensorn var mycket trevligare att arbeta med, tog mindre plats och dessutom inte kan ha några problem med kvarlämnade (latenta) fingeravtryck på sensorn.

FPC2020 kommer kapslad i en liten och trevlig 64-bens QFN-kapsel. FPC2020 klarar matning från 2.5V till 3.3V och kommunicerar mot omvärlden via RS-232 (vilket FPC kallar UART) eller SPI-interface.

Robert Malmgren om säkerhetsproblem med VoIP

December 7th, 2007

Robert Malmgren en av sveriges duktigaste IT-säkerhetsexperter pratar i en intervju på IDG om säkerhetsproblem med VoIP.
Lilla Romab


– Säkerheten är fortfarande omogen på ip-telefoniområdet, men många företag stoppar huvudet i sanden och satsar ändå, vilket är en farlig kombination, säger säkerhetsexperten Robert Malmgren.

Det senaste tecknet på omogenheten är att Ciscos ip-telefoner kan avlyssnas på grund av att det har en inbyggd webbserver som inte krypteras och dessutom är påslagen som standard.

Artikeln innehåller även kommentarer från några andra personer:


– Leverantörerna pratar bara om möjligheterna, ingenting om riskerna. Därför ser företagen bara möjligheterna och underskattar riskerna, säger Ulf Eriksson, it-chef på Alcro-Beckers.

– Dagens ip-telefoner är inga dumma terminaler utan liknar mer en vanlig pc med en webbläsare. Det får stora konsekvenser för säkerheten, säger Ulf Eriksson.

Ytterligare en dimension på hotet mot ip-telefonin är att växlarna numera installeras på vanliga servrar.

– Det innebär att växlarna är lika sårbara för skadlig kod och attacker från hackare som vilken annan server som helst, säger Niklas Eklöv, systemingenjör på McAfee.

Jag tycker att det är bra att säkerhetsaspekter runt VoIP uppmärksammas. Jag betraktar VoIP som små, inbyggda system som kopplas upp över nätverk och antingen via lokal server eller direkt pratar ut mot omvärlden. Att detta innebär en förändring i säkerhetsmodellen i det lokala nätverket borde vara uppenbart. Men jag upplever att många organisationer stirrar sig blinda på de samtalskostnader man kan kapa genom att byta ut sitt gamla POTS-system.

En bra jämförelse tror jag är skrivare och kopiatorer som sitter på nätverket. Hur många tänker på att dessa maskiner i dag är en nätverksansluten dator? Rent psykologiskt betraktas nog den telefon som står på skrivbordet som en telefon oavsett om den har en Ethernetport i baken eller inte.

Att Robert som alltid är stabil, klok och sansad tar upp VoIP som ett växande problem tar jag som en seriös varning om att allt inte bara är sol och parasolldrink med VoIP.

På RSA-konferensen pratade jag bland annatmed en ansvarig för telefoni på Deutche Postbank. Dom hade räknat på VoIP-lösningar varje år de senaste tre åren. Hans slutsats var att med kostnaden för separata servrar för VoIP, administration av alla VoIP-telefoner, VLAN-separering eller tom helt separat nätverk blev kostnaden högre för VoIP än med traditionell telefoni. Även om samtalskostnaden kapades rejält gick det inte att räkna hem vinsten inom rimlig tid för systemet.

För den som vill läsa mer om olika säkerhetsproblem med VoIP finns det ett dokument kallat VoIP Security and Privacy
Threat Taxonomy
från Voice over IP Security Alliance (VOIPSA) som är väl värd att läsa igenom.

Och när vi ändå är inne på VoIP och säkerhet kanske vi inte skall glömma bort Skype, som oavsett hur enkel den är att använda säkerhetsmässigt är något av det mest skrämmande jag känner till. Jag har tidigare tagit upp Philippe Binondi och Fabrice Desclaux presentation Silver Needle in the Skype från Black Hat Europe 2006. Har du inte tittat igenom den presentationen så gör det.