Kryptoblog » Inbyggda system

Motorola och Ericsson samarbetar om säkra LTE-nät

Joachim Strömbergson — Wed, 08 Sep 2010 18:12:54 +0000

(Mycket LTE-nyheter just nu.)
Elektroniktidningen (ETN) rapporterar att Motorola och Ericsson skall samarbeta om att utveckla säkra LTE-nät, motsvarande TETRA-nät för blåljusmyndigheter. ETN skriver:

Ericsson och Motorola har ingått en allians för att gemensamt ta fram LTE-lösningar för området ”allmän säkerhet”, det område som idag domineras av standarden Tetra och där Motorola är en av de starkaste aktörerna. Tanken är att kombinera Motorolas kompetens inom säkra nät med Ericssons förmågor inom LTE och mobilt bredband.

Ett mål med alliansen är att utveckla en LTE-lösning för mobilt bredband till säkerhetskritiska tillämpningar, som kan fungera tillsammans med säker röst- och datakommunikation. Enligt en gemensam pressrelease ska Motorolas nästa generations plattform för området innehålla LTE-teknik, klara behoven från såväl kommandocentraler, och kunna kommunicera med såväl tålig radioutrustning och terminaler i fordon som handhållna LTE-terminaler.

Som ETN påpekar meddelande även Samsung att dom skall samarbeta med säkerhetsjätten Thales om att utveckla TETRA-mobiler som stödjer LTE. I det fallet är det Thales som står för TETRA-kompetensen och Samsung för LTE-kompetensen (och att bygga mobiler får man anta).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

RFID och integritet – Olja och vatten

Joachim Strömbergson — Sat, 04 Sep 2010 08:23:18 +0000

Igår dök det upp ett par nyheter som återigen visar hur attraktivt radiobaserad identifiering (RFID) verkar vara, och hur blind man är för de problem som finns med tekniken. Detta gäller inte minst politiker och tjänstemän som ofta har lite teknisk kunskap.

Organisationen American Civil Liberties Union (ACLU) kritiserar i ett uttalande en skola i Kalifornien som försökt sätta RFID-taggar på alla elever i en skola. ACLU uppmanar föräldrar att vägra sätta på sina barn RFID-taggar som skolor delar ut.

Enligt en artikel i San José Mercury News är det en skola i Contra Costa County som vid terminstarten delat ut tröjor till alla elever. Tröjorna visade sig dock innehålla RFID-taggar. Det som skrämmer mig mest med denna nyhet är hur taggarna ses som en ren effektivitetslösning. Mercury News skriver:

RICHMOND, Calif.—California officials are outfitting preschoolers in Contra Costa County with tracking devices they say will save staff time and money.

The system was introduced Tuesday. When at the school, students will wear a jersey that has a small radio frequency tag. The tag will send signals to sensors that help track children’s whereabouts, attendance and even whether they’ve eaten or not.

School officials say it will free up teachers and administrators who previously had to note on paper files when a child was absent or had eaten.

Sung Kim of the county’s employment and human services department said the system could save thousands of hours of staff time and pay for itself within a year.

It cost $50,000 and was paid by a federal grant.

Mao, det viktiga är att spara pengar, och det verkar inte finnas några tankar om problem med tekniken. Undrar varför dom inte inför det på alla ställen i kommunen, exempelvis för skolpersonal och kommunens HR-avdelning…

Och när det väl uppdagas problem så blundar man istället. The Local rapporterar om en undersökning av de nya RFID-utrustade ID-korten i Tyskland.

Ett av de nya ID-korten i Tyskland som innehåller ett RFID-chip.

Dom nya ID-korten innehåller ett RFID-chip som bland annat lagrar fingeravtryck från två fingrar. Ett TV-program anlitade kända hacker-gruppen Chaos Communcation Club (CCC) för att testa säkerheten hos kortet. CCC lyckades extrahera information från korten. Men när de ansvariga ställdes inför faktum förnekade man att det ändå var möjligt:

In an interview with the show, Interior Minister Thomas de Maizière said he saw no immediate reason to act on the alleged security issue.

Meanwhile on Tuesday the Federal Office for Information Security (BSI) rejected the Plusminus’ criticism of the new ID card. The agency’s personal identification expert Jens Bender said the card was secure

Rätt skrämmande, inte minst för att det nya systemet är tänkt att användas för kommunikation med myndigheter, dvs det kommer att krävas ett RFID-utrustat kort för att komma åt tjänster som du som medborgare har behov av. Det blir därmed svårt att avstå från systemet. Det skall gå att istället använda en sexsiffrig PIN-kod, men frågan är hur länge det accepteras.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Ny TCP-sekvensgenerator för uIP

Joachim Strömbergson — Sat, 17 Jul 2010 14:35:36 +0000

Tillsammans med Adam Dunkels har jag börjat titta lite försiktigt på att hitta en bättre generator för TCP-sekvensnummer till den miniskula TCP/IP-stacken uIP.

Adam Dunkels – pappa till uIP, bland annat.

Den nuvarande generatorn ger en monotont ökande sekvens som är lätt att prediktera. En ny generator skall ge en bra slumpmässig som inte är lätt (inte går) att prediktera. MEn samtidigt får storleken på stacken inte växa speciellt mycket och skall gå att implementera på en 8-bitars processor. Vidare får vi inte inför en massa nya krav på målsystemet, exempelvis tillgång till bra fysisk entropi. En icke-trivial kombination av krav.

Jag har tänkt, kladdat och sedan postat på Cryptography-listan och fått en del tips. Men jag (vi) tar med stor glädje emot mer klokskap. Här kommer därför min postning till listan. Läs, kommentera. Tack!

uIP [1] is a very compact TCP/IP stack for small, networked connected, embedded devices. (The code size for uIP including TCP and ICMP on the AVR processor is about 5 kBytes.)

Unfortunately, the TCP sequence number generator in uIP is a bit simplistic – basically a monotonically increasing number. In order to reduce the opportunities for TCP Spoofing (like this nice one [2]) we are trying to implement a new TCP sequence number generator.

What we want to find is an algorithm that generates a good (secure) TCP seq numbers, but use very little resources (on 8-bit computing devices).

We have done some preliminary investigations, have some rough ideas and would really appreciate comments and suggestions from the enlightened minds on this list.

As we see it, the two main problems to solve are:
(1) Find a secure PRNG algorithm that have as low implementation complexity as possible.

(2) Add as little system/application requirements on entropy source and persistent storage as possible.

Looking at TinyRNG [3] for example, it seems that a block cipher in CTR mode (or OFB mode) should be sufficient. The question then is what block cipher to use? The XTEA block cipher [4] is very compact, but would it be a wise choice from a security perspective?

But what to feed the PRNG with? Looking again at TinyRNG, it uses a simplistic version of the entropy accumulator from the Fortuna PRNG [5], but with fewer and smaller pools. The pools are processed using a CBC-MAC built around the same block cipher as used in the PRNG.

The combined storage for the pools as well as CBC-MAC state would probably be acceptable for uIP. The question is if the pool feeding operation as such adds operational requirements on uIP that makes it harder to integrate?

A simpler scheme could be to feed the PRNG (CTR-mode) with entropy used as part of Key and IV, that is not use a pool mechanism at all and leave it to user application to provide entropy words when performing a reseed. The Key (and IV?) would also consists of a counter that is monotonically increased.

The problem with this (we guess) is that in order to ensure that KEY+IV is never reused is to keep at least part of KEY or IV as a counter that is stored in persistent memory and increased once (and stored) every time reseed (or boot) is performed. (How bad from a security perspective would this be? Compared to other TCP sequence generators?)

The current version of uIP places few (basically no) demands on the system/application regarding physical resources (besides mem for code and data) and does not use any persistent storage besides code memory. It seems that any good sequence generator that are driven by physical entropy and tries to avoid sequence repetition need to place additional demands on the system. No?

This is basically as far as we have taken this. More or less a bit of Googling, reading and attempts at thinking. The ambition is not to invent something new and unproven but to adapt existing tech and ideas that seem to work. But get it to work with the size, performance and API constraints of uIP.

Any thoughts, comments, suggestions and pointers would be very greatly appreciated.

Thank you!
Joachim Strömbergson

References
—————

[1] A. Dunkels. uIP TCP/IP stack.

http://www.sics.se/~adam/uip/index.php/Main_Page

[1] R. Lawshae. Picking Electronic Locks Using TCP Sequence Prediction
http://www.defcon.org/images/defcon-17/dc-17-presentation/Ricky_Lawshae/defcon-17-ricky_lawshae-picking_electronic_locks-wp.pdf

[3] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random

Number Generator for Wireless Sensors Network Nodes

http://planete.inrialpes.fr/~ccastel/PAPERS/TinyRNG.pdf

[4] R. M. Needham, D. J. Wheeler. Tea extensions.

http://www.cix.co.uk/~klockstone/xtea.pdf

[5] Wikipedia. Fortuna PRNG.

http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

En Duracellkanin? Nej, en Energizer-trojan

Joachim Strömbergson — Fri, 12 Mar 2010 13:21:28 +0000

Batteriföretaget Energizer släppte för ett tag sedan en USB-kopplad batteriladdare kallad Energizer Duo.

Förutom att ladda via USB kunde produkten köra en liten applikationen på datorn som visade laddstatus fäör batterierna.

Men det var nu inte det enda som kördes när laddaren kopplades in. Enligt Symantec kom batteriladdaren med en elak liten trojan. Symantec har en längre beskrivning av Energizertrojanen som bla beskriver vad den kunde göra:

• Download a file
• Execute a file
• Send a directory listing to the remote attacker
• Send files to the remote attacker
• Modify the following registry entry:

Energizer har dragit tillbaka produkten. Det jag undrar över är hur trojanen hittade in i koden till laddaren från första början. Hade det varit ett USB-minne hade det varit en sak, men nu är det inte det och då brukar mängden minne som finns vara högst begränsat. Märkligt.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Svagheter i SHA-3-implementationer

Joachim Strömbergson — Sun, 22 Feb 2009 07:59:05 +0000

Fortify har postat på sin blogg om en undersökning av säkerheten i referensimplementationerna av SHA-3-kandidaterna.

Fortify har använt sitt verktyg Fortify SCA, en linter speciellt utvecklad för att hitta kodmässiga svagheter som buffertöverskrivningar etc. (Det hade antagligen gått bra att använda splint eller liknande säkerhetsinriktade lintverktyg för att hitta svagheterna.)

Vad Fortify upptäckt är att ett antal av SHA-3-kandidaterna har mer eller mindre allvarliga svagheter i sin implementation, mer specifikt i Blender, Crunch, FSB, MD6, Vortex. Några typiska fel är att koden tillåter buffertöverskrivningar, att den läser utanför gränserna i en buffert (indexeringsfel) och minnesläckage. Som ett exempel tar Fortify upp MD6:

One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct:
unsigned char hashval[ (md6_c/2)*(md6_w/8) ];
The buffer size is determined by two constants:
#define w md6_w /* # bits in a word (64) */ #define c md6_c /* # words in compression output (16) */
At several points, this buffer is read or written to using a different bound:
if (z==1) /* save final chaining value in st->hashval */ { memcpy( st->hashval, C, md6_c*(w/8) ); return MD6_SUCCESS; }
Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise.

The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo:
DataLength sourceDataLength2[3];// high order parts of data length ... if (ss.sourceDataLength < (bcount | databitlen)) // overflow if (++ss.sourceDataLength2[0] 0) // increment higher order count if (++ss.sourceDataLength2[1] 0) // and the next higher order ++ss.sourceDataLength2[3]; // and the next one, etc.
The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation.

Att den här typen av programmeringsfel kan få betydelse för SHA-3-tävlingen är uppenbart, och illustreras tydligt med MD6. Dess internbuffert behövde dubbleras i storlek. Detta gör att implementationer av MD6 för inbyggda system kommer att kräva mer minnesresurser än vad tidigare angetts. En av styrkorna med MD6 enligt dess skapare är att den skalar extremt bra ner till mycket små implementationer, och det argumentet fick sig nu nog en liten törn.

Ett annat skäl till varför jag tycker att Fortifys undersökning är bra är att referensimplementationer ofta används i applikationer. Antingen direkt eller som bas (funktionell referens) för en ny implementation. Därmed riskerar svagheter i referensimplementationen att sprida sig. Fortify tar själva upp ett exempel från en svaghet i referensimplementationen av RSA som lett till buggar i olika SSL-implementationer.

I fallet SHA-3, med dess fokus på prestanda, vilket gjort att skaparna av kandidater slitit och sliter med att optimera ut varenda cykel de kan ur sin kod, tror jag att referensimplementationer kommer att få stor användning i applikationskod.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Skydd av FPGA-konstruktioner med PUF:ar

Joachim Strömbergson — Mon, 29 Sep 2008 20:27:49 +0000

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 Oﬄine HW/SW Authentication for Reconﬁgurable 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 conﬁgured 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 conﬁguration 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 ﬁxed 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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Sidokanalsbaserat skydd mot kretskloning

Joachim Strömbergson — Thu, 18 Sep 2008 19:47:39 +0000

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?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Nyckelutbyte genom jonglering

Joachim Strömbergson — Wed, 16 Jul 2008 04:53:47 +0000

(Fixat trasig länk – tack JörgenL.)

På Light Blue Touchpaper, bloggen från säkerhetsguppen vid Cambridge Computer Laboratory har det dykt upp en intressant postning om ett nytt sätt att utföra lösenordsbaserad nyckelutbyte.

Lösenordsbaserad nyckelutbyte (Password Authenticated Key Exchange – PAKE) är en metod för att utbyta sessionsnycklar för säker kommunikation mellan parter baserad på lösenord (delad hemlighet). De två mest kända versionerna av PAKE är Encrypted Key Exchange – EKE och Simple Password Exponential Key Exchange – SPEKE.

Artikeln Password Authenticated Key Exchange by Juggling är skriven av Feng Hao och Peter Ryan. Artikelns sammanfattning förklarar nyttan med J-PAKE:

Password-Authenticated Key Exchange (PAKE) studies how to establish secure communication between two remote parties solely based on their shared password, without requiring a Public Key Infrastructure (PKI). Despite extensive research in the past decade, this problem remains unsolved. Patent has been one of the biggest brakes in deploying PAKE solutions in practice. Besides, even for the patented schemes like EKE and SPEKE, their security is only heuristic; researchers have reported some subtle but worrying security issues. In this paper, we propose to tackle this problem using an approach different from all past solutions.

Our protocol, Password Authenticated Key Exchange by Juggling (J-PAKE), achieves mutual authentication in two steps: ﬁrst, two parties send ephemeral public keys to each other; second, they encrypt the shared password by juggling the public keys in a veriﬁable way. The ﬁrst use of such a juggling technique was seen in solving the Dining Cryptographers problem in 2006. Here, we apply it to solve the PAKE problem, and show that the protocol is zero-knowledge as it reveals nothing except one-bit information: whether the supplied passwords at two sides are the same.

With clear advantages in security, our scheme has comparable efficiency to the EKE and SPEKE protocols.

(Jonglering med nycklar – om din nyckel heter som ditt husdjur…)

Artikeln innehåller en hel del referenser till koncept och metoder jag inte kände till innan, exempelvis Dining Cryptographers. (Det verkar pågå verksamhet på Wikipedia för att skriva om förklaringen av problemet – se den här och den här sidan.)

Implementationsmässigt verkar den nya metoden inte vara så hemsk. Författarna skriver:

Since our protocol involves several zero-knowledge proofs, one might concern about its cost. We now count the number of exponentiations in the protocol and evaluate its computational effciency..in our protocol, each party would need to perform 14 exponentiations in total – including 8 in the ﬁrst step, 4 in the second step, and 2 in computing the session key.

To better assess the cost in real terms, we implement the protocol in Java on a 2.33-GHz laptop running Mac OS X. The modulus p is chosen 1024-bit and the subgroup order q 160-bit
...
The results demonstrate that the protocol – executed only once in a session – runs sufficiently fast. The total computation time is merely 0.075 sec. As compared to the time that the user keys in his password, this latency is negligible at the client.

However, the cost at the server may accumulate to be signiﬁcant if requests are dealt with simultaneously. Therefore, the threat of Denial of Service (DoS) attacks still needs to be properly addressed in practical deployments.

Vad gäller säkerheten skriver författarna att:

EKE requires changing the protocol in its existing form for a secure implementation. As for a SPEKE, it has the drawback that an active attacker may test multiple passwords in one protocol execution. Furthermore, neither protocol – in the original form – accommodates short exponents securely. Finally, neither protocol is provably secure; formal security proofs seem unlikely without introducing new security assumptions or relaxing security requirements.

We choose to solve the PAKE problem using a different approach. The novelty of our design is that we encrypt the password by juggling the public keys in a way that can be veriﬁed. As a result, our scheme is provably secure, allows ﬂexible use of short exponents, and strictly limits an active attacker to test only one password per protocol execution.

För ett tag sedan blev Java-koden till implementationen av J-PAKE tillgänglig. Jag har inte testat den själv. Intressant nog kallas den för JPAKE2, vilket skulle kunna betyda att det funnits en tidigare version av algoritmen som man av någon anledning inte var nöjd med.

Författarna har även skickat in J-PAKE som förslag till en framtida utökning av IEEE P1363.

När J-PAKE uppmärksammades på Cyptography-listan dök det upp referenser till en annan, ny PAKE-algoritm. Det finns en Internet Draft, EAP Authentication Using Only A Password som tydligen är under utvärdering av IEEE för den kommande WLAN-standarden 802.11s.

Bra och enkla och allmänt tillgängliga metoder för nyckelutbyte är klart intressant. Med två stycken nya, säkra och ej patenterade utan öppna algoritmer kanske PAKE kan få bättre spridning. Inte minst för inbyggda system är J-PAKE klart intressant.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

En liten 6502-emulator

Joachim Strömbergson — Tue, 15 Jul 2008 13:22:09 +0000

Vad passar bättre en regntung semesterdag än testkoda en emulator av den gamla processorn 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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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

Joachim Strömbergson — Mon, 14 Jul 2008 13:46:02 +0000

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.

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. Conﬁgure key B as readable and store random information in it. Do not store sensitive information in the ﬁrst 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 modiﬁcation of a data block, an extra authentication on this data could be added. This authentication
is then veriﬁed 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:

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

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

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.

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

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.