Archive for the ‘Inbyggda system’ Category

Atmels säkerhetsminne CryptoMemory

Tuesday, October 2nd, 2007

Kretsföretaget Atmel har precis släppt en ny säkerhetsprodukt. Den här gången är det ett säkert minne kallat CryptoMemory. CryptoMemory är till för att säkert lagra information i olika produkter och dessutom skapa autenticiering med hjälp av Challenge/Response:

A CryptoMemory uses the authentication keys and a random number to generate a unique 56-bit highly encrypted identity, called a cryptogram, and a unique 64-bit session encryption key, every time a transaction occurs…

Each crypto memory chip contains a unique serial number and the user can optionally assign one of four unique 64-bit encryption keys to each zone. The host knows how to generate these keys using the serial number and a special “secret” that it stores. During mutual authentication, the CryptoMemory sends its serial number and encrypted identity to the host. The host then computes a 64-bit number, called a “challenge”, based on a random number and its own encryption key. It sends the random number and the “challenge” to the device…

No Cryptography Expertise Required. Atmel offers a CryptoMemory design kit with a library of simple API calls that execute the most complex host operations, including building a software model of the host-side cryptographic engine, computing challenges, performing data encryption and decryption, computing encrypted passwords and message authentication codes, and keeping the host model of the cryptographic engine in synchrony with that in the device…

Atmel’s CryptoMemory devices are available now in memory densities of 1-kbit up to 256-kbits. They have standard memory interfaces to microcontrollers and off-the-shelf readers that include a two-wire interface (TWI), ISO 7816-3 interface in T=0 Mode for wired asynchronous communications. CryptoMemory devices can be used as drop-in replacements for non-secure EEPROMs to protect software IP.

Package options include 8-lead SOIC or PDIP plastic packages and modules for smartcard applications.

CryptoMemory devices cost about 10 cents more than conventional EEPROM-based security solutions – a negligible amount when compared to the $500 handbag or a $100 container of prescription medication they protect. Prices start under 30 cents for unit quantities of 10,000 units.

Priset på minneskretsarna pekar på att det är i konsumentprodukter som Atmel ser att CryptoMemory skall användas.
Atmels fina bild för CryptoMemory.
(Observera den fräcka Palm III:an!)

Det finns en finfin presentationsfilm från Atmel (ca 60 MByte) som beskriver en del tillämpningar för CryptoMemory. Bland annat tar filmen upp stöldskydd för airbags, autenticiering i glukosmätare och DRM-skydd för kabel-TV.

Men vilket krypto är det som används?

Presentationen pekar på att det skall komma ett datablad för CryptoMemory, och när det kommer får vi säkert reda på hur CryptoMemory fungerar. Men tills dess får vi leva med att det är ett krypto. Jag återkommer i frågan.

Bra text om design av säkra inbyggda system

Thursday, September 27th, 2007

Webbplatsen Embedded System Design har en artikel med undertiteln Encryption is not Security som, anser jag, ger en bra introduktion till hur man skall resonera vid design av säkra inbyggda system.

Ett skäl till varför jag tycker att artikeln är bra är att den tar upp ett fenomen jag stöter på ibland, ett fenomen som artikeln beskriver så här:

Ask some developers and device makers about the security of their mobile and embedded devices and they’re likely to tell you about their encryption strength. Then they will probably stop talking.

Artikeln övergår sedan till att beskriva hur man på ett praktiskt sätt kan göra en säkerhetsanalys av sitt system, de användningsfall och den miljö systemet är avsett att fungera i. Artikeln använder en smartphone som exempel:

Attackträd för smartphone
(Bilden är av rätt kass kvalitet, även i artikeln.)

När analysen är gjord kan man sedan identifiera de komponenter och delsystem som behövs för att säkra systemet. Bland dessa komponenter kan krypton finnas med, men det är inte givet på förhand.

En sak jag gillar med artikeln är att den betonar fokus på applikationen och affärsnyttan. Säkerhetsproblem kostar pengar när de inträffar och därför är det viktigt att börja med att identifiera vilka dessa kostnader är:

ying the threat to a business issue makes it much easier to communicate. If top managers don’t understand the threat, it will be much harder for you to win funding and other resources you need to address it. Also, writing the threat from a business perspective helps make sure it gets appropriate attention.

If the description at the base of your threat tree is complicated and/or vague, it can be tough to determine how much attention that issue really needs. Anybody, regardless of technical background, should be able to understand the root threat.

Med tanke på den debatt som pågår om behovet av kompetens, bland konstruktörer, projektledare etc vad gäller att kunna bygga säkra system är den här artikeln en utmärkt, kortfattad introduktion. Ett klart lästips från Kryptoblog.

SRAM för ID och slumptalsgenerering

Wednesday, September 26th, 2007

För några veckor sedan dök det upp en spännande artikel av Daniel Holcomb, Wayne Burlesson och Kevin Fu med titeln Initial SRAM State as a Fingerprint and Source of True Random Numbers for RFID Tags. Artikeln presenterades på Conference on RFID Security 2007 och artikelns sammanfattning lyder så här:

RFID applications create a need for low-cost security and privacy in potentially hostile environments. Our measurements show that initialization of SRAM produces a physical fingerprint. We propose a system of Fingerprint Extraction and Random Numbers in SRAM (FERNS) that harvests static identity and randomness from existing volatile CMOS storage.

The identity results from manufacture-time physically random device threshold mismatch, and the random numbers result from run-time physically random noise. We use experimental data from virtual tags, microcontroller memory, and the WISP UHF RFID tag to validate the principles behind FERNS. We show that a 256byte SRAM can be used to identify circuits among a population of 160 virtual tags, and can potentially produce 128bit random numbers capable of passing cryptographic statistical tests.

Vad artikelns författare alltså försöker göra är att titta på innehållet i ett SRAM-minne som precis blivit strömsatt (initialtillståndet), och utifrån detta skapa två saker:

  1. Ett sätt att identifiera kretsen
  2. Extrahera slumptal (entropi)

På artikelförfattaren Daniel Holcombs webbplats finns en film som visar att den i artikeln presenterade FERNS-tekniken fungerar. Artikelförfattarna ger följande motiveringen till att behovet av ett nytt sätt att identifiera enheter:

In the most general terms, RFID circuits can be identified either through the use of non-volatile memories or the use of some identifying physical characteristic, which we call fingerprinting. The non-volatile approach involves programming an identity into a tag at the time of manufacture using EPROM, EEPROM, flash, fuse, or more exotic strategies.

While non-volatile identities are static and fully reliable, they have drawbacks in terms of the process cost and the area cost of supporting circuitry. Even if only a small amount of non-volatile storage is used, the process cost must be paid across the entire chip area. Additionally, supporting circuitry such as charge pumps for tunneling oxide devices, and programming transistors for fuse devices, are needed.

CMOS-teknik, krypto, RFID, hårdvara och säkerhet - kan det bli bättre? Som ämne för Kryptoblog, antagligen inte. Men tyvärr är det säkerhetsmässigt inte så bra som man först kan tro. Men vi börjar med en beskrivning av tekniken. Utgångspunkten är CMOS-teknik, mer exakt hur en enskild SRAM-cell är uppbyggd och hur den beter sig när matningen kopplas in. (Jag låter här artikeln förklara.)

SRAM-cell
(Figuren är inte från artikeln, men visar samma typ av SRAM-cell med sex transistorer. Q och Q-tak motsvarar artikelns A och B.)

Each bit of SRAM is a 6 transistor storage cell, consisting of cross coupled inverters and access transistors. Each of the inverters drives one of the two state nodes, labeled A and B. When the circuit is unpowered, both state nodes are low (AB=00). Once power is applied, this unstable state will immediately transition to one of the two stable states, either ’0’ (AB=01) or ’1’ (AB=10).

The choice between the two stable states depends on threshold mismatch and thermal and shot noise. Because the stabilization depends only on mismatch between local devices, the impacts of common mode process variations such as lithography, and common mode noise such as substrate temperature and supply fluctuations, are minimized…

RAM cells with large threshold mismatches are heavily skewed toward one state, and are immune to the small disturbances of noise. Because these cells consistently stabilize to the same state, and vary across chips, they can be used to identify the tag. RAM cells that happen to have well matched thresholds are highly sensitive to noise. In these cells, physically random noise will determine the outcome.

För att utnyttja denna effekt extraheras SRAM-minnet från kretsen (dvs en komplett minnesdump). Detta sker ett upprepat antal gånger och mellan varje extraktion slås matningen till kretsen av och på igen. Utifrån minnesdumparna identifieras sedan vilka bitar som antar ett givet värde (noll eller ett). Eftersom dessa styrkan på entydigheten i initialtillstånd är statistiskt använder artikelförfattarna Hammingavstånd för att skapa ett fingeravtryck för kretsen.

Vid identifiering läser man sedan återigen ut minnet och matchar det mot en databas av skapade fingeravtryck (eller template på biometrispråk). Precis som för biometri kan denna teknik man komma fram till fel ID, så kallade false positives och false negatives, något artikeln påpekar.

Ett uppenbart problem är att SRAM-minnen har minne, dvs att det tar tid för att information lagrad i ett SRAM-minne försvinner efter att strömmen till minnet kopplats bort. Första gången jag såg denna minneseffekt (remanence på engelska) var när jag som finnig tonåring hackade kod på Commodore 64:an, en brödburk fylld med SRAM-kretsar:

Commodore 64

En sak som då var lätt att se var att om man hade ett program i minnet och slog om strömknappen (på-av-på) och tittade i minnet med en maskinkodsmonitor kunde man se att det fanns rester av det gamla programmet kvar. Ju längre tid strömmen var av desto mindre fanns det kvar av programmet. Denna minneseffekt fanns då, och den finns i dag också.

Det finns flera olika artiklar etc som tar upp minneseffekten i SRAM-kretsar:

Jag kontaktade författarna av artikeln för att se om dom tagit minneseffekten i beaktande. Svaret jag fick visar att det inte var något man tagit med i sin analys av tekniken:

We did not formally study data-remanence and read frequency, but are certainly aware of the work of Gutmann and Skorobogatov. These works collectively seem to indicate that long-term remanence is not a problem in modern chips (Gutmann), but that short term remanence is (Skorobogatov).

In our experiments, we simply made sure to wait “long-enough” between power-ups that the short term remanence would have died out and verified this by checking that correlation between successive trials had reached a minimum. With the SRAM chip “long enough” was less than a second, with the MSP430, it was much longer due seemingly to the design and external capacitors on the power lines. We intend for our method to be applied to chips that have been powered off for a while before use, and not for high throughput of random numbers.

Ett annat problem med tekniken artikeln beskriver är att bitarnas initiala beteende kommer att påverkas av kretsens miljö, exempelvis av temperatur. Ett annat bekymmer är om det finns krypströmmar som kan råka mata minnet eller på annat sätt inducera fält i minnet. Och naturligtvis är flera av dessa yttre effekter är sådana att den som vill kan påverka dom och därmed vilket ID och slump som extraheras. Slutligen åldras CMOS-kretsar (mer eller mindre långsamt - beroende på miljö, användning etc), och då ändras även beteendet.

Dessa bekymmer gjorde att flera personer på Crypography-listan reagerade när artikeln dök upp. En av de som reagerade var Peter Gutmann som bland annat skrev:

The problem with using device state in this manner is that it’s *completely* dependent on the device technology and environment in which it’s used. Anychange in the manufacturing process can change the results. Any change in the environment (temperature, supply voltage, etc) can change the results.

A deliberate attack, for example irradiating the device to change the RAM cell threshold, can change the results. Even without deliberate modification, SRAM cells that store a constant value tend to acquire a set over time in which they’ll come up in that state when powered on (this has happened with crypto hardware storing keys over long periods of time in SRAM)… ECC memory scrubbing may set the RAM into a predetermined state. A slow memory test during POST (which writes all cells rather than doing a quick test with a large stride) would have the same effect. The list goes on and on…

The worst case is a change in the environment or manufacturing process, which typically occurs without the end user even knowing about it. You simply can’t guarantee anything about RAM state as an RNG source, you’d have to prove a negative (no change in manufacturing technology or the environment will affect the quality of the source) in order to succeed. It’s like the thread-timing-based RNGs, you can never prove that some current variation of or future change to the scheduler won’t result in totally predictable “random” numbers.

So RAM state is entropy chicken soup, you may as well use it because it can’t make things any worse, but I wouldn’t trust it as the sole source of entropy.

Även James A. Donald såg klara problem med tekniken i artikeln:

Using SRAM as a source of either randomness or unique device ID is fragile. It might well work, but one cannot know with any great confidence that it is going to work. It might work fine for every device for a year, and then next batch arrives, and it completely fails. Worse still, it might work fine on the test batch, and then on the production run fail in ways that are subtle and not immediately obvious.

Men jag ser ännu fler problem:

  • Konceptet att skicka iväg en minnesdump och sedan låta en extern enhet komma fram till vilket ID en krets har förändrar flera protokoll. Inte minst challenge/respons-baserad autenticering, vilket används för RFID blir extremt konstig om RFID:n måste prata (i klartext) med en extern enhet för att veta vem den själv är.
  • Artikeln förslår att kretsen skall använda minnets initialtillstånd som grund för att exempelvis generera kryptonycklar. Men om initialtillståndet skickas iväg till en extern enhet exponeras basen för nyckelgenerering.
  • Om inte kretsen kan kontrollera att long-enoung tid har gått och skickar iväg innehållet i minnet riskerar kretsen att skicka iväg potentiellt känslig applikationsinformation från föregående operation. Informationsläckage alltså.

Slutligen har jag svårt att se att man med samma kommunikationsresurser som man har i enkel RFID (passiv backscatter) skall hinna med att skicka över multipla kopior av minnet utan att det påverkar applikationen RFID-enheten används i. Vidare innebär den större mängden data som skall överföras och den mer komplexa identifieringen ökade systemkostnader. Med detta i beaktande tror jag inte att det finns någon som är beredd att byta ut en enkel process för att få ett entydigt chip-ID mot en komplicerad process som till slut ger ett statistikt ID med risk för felidentifiering.

Min slutsats är att artikeln visar på spännande nytänkande vad gäller att använda fysikaliska fenomen kopplade till tillverkningsprocessen i digital CMOS-kretsar. Vidare görs i artikeln intressanta kopplingar mellan biometriska signaturer och fysikaliska mönster i integrerade kretsar.

Men jag ser på tok för stora säkerhetsmässiga problem med minneseffekter, möjlighet att påverka kretsen och andra osäkerheter för att jag skulle vilja använda SRAM-minnet som entropikälla. Vidare känns ID-metoden både på tok för komplicerad och resultatet är för svagt för att jag skall se att det finns en praktisk nytta av tekniken.

Jag har dock skickat ett antal följdfrågor till författarna av artikeln. När jag får svar på dom frågorna återkommer jag.

Säkerhet och behovet av beställarkompetens

Monday, September 24th, 2007

Computer Sweden har en artikel om att det brister vad gäller säkerhetstänkande i utvecklingsprojekt.

I artikeln intervjuas bla Ann-Marie Eklund Löwinder som säger:

Säkerhet finns med i metoder för utveckling, men när det väl kommer till kritan får säkerhet ofta stryka på foten för att tidplaner och budgetar ska kunna hållas. Det tar tid att jobba med säkerhet, säger Anne-Marie Eklund Löwinder, ansvarig för informationssäkerhet på Stiftelsen för internetinfrastruktur och en av Sveriges ledande experter.

Ann-Marie fortsätter med:

Många utvecklare har inte drillats i säkerhet, säger Anne-Marie Eklund Löwinder.

En annan person som intervjuas i artikeln är Tomas Cardell, arkitekt på IT-Huset i Stockholm som säger:

Tekniska projektledare måste vara tuffare och börja jobba med säkerhet tidigare, även om utvecklarna inte gillar det.

Jag kan inte annat än hålla med. Att i dag som konstruktör inte ha läst böcker som Security Engineering och reflektera över säkerhetsaspekter borde vara närmast tjänstefel. Tyvärr träffar jag extremt sällan på vare sig konstruktörer eller projektledare som tänker på säkerhetsaspekter runt sina konstruktioner.

Att det exempelvis finns potentiella säkerhetsproblem med att exponera sitt inbyggda system mot omvärlden via en öppen IP-adress. Och att då utgå ifrån att inkommande data och kommandon alltid är korrekta och tom från en vänlig part är skrämmande nog helt normalt och vardag.

Men jag anser att artikeln och de som blir intervjuade missar en väsentlig sak: Beställarkompetens.

Om inte den som beställer projektet kräver att systemet som skall utvecklas blir säkert, och man som beställare tar höjd i budgeten för ökade utvecklingskostnader för att säkra konstruktionen kommer det aldrig att ske. Man kan skylla på konstruktörer och projektledare för att slarva med säkerhetsaspekterna, men ges dom inte krav och resurser så går det inte att i efterhand komma och kräva att detta jobb skall utföras.

Vidare måste de utvecklingsprocesser som används utökas, detta för att säkerhet inte bara är nya funktioner, utan i hög grad handlar om att analysera vad som kan gå fel (både slumpmässiga fel och avsiktliga fel - attacker) och bestämma hur systemet då skall reagera. Vidare måste verifieringen och granskningen av implementationen utökas med flera nya aktiviteter.

När detta blir vardag kommer (tror jag) utveckling av säkra (säkrare) system inte att upplevas som ett extra bekymmer.

Frågan är hur vi får beställarna att börja ställa dessa krav? Min gissning är att snabbaste vägen är via deras plånböcker.

Synkproblem och osäkra trådlösa bilnycklar

Friday, September 14th, 2007

I en kommentar till Bruce Schneiers artikel om knäckningen av KeeLoq, något jag bloggat om tidigare, dök det upp ett annat intressant problem med trådlösa bilnycklar.

En ful Chrysler Sebring

Bloggen Restlessobsessive beskriver att det iaf för den trådlösa bilnyckeln till hans Chrysler Sebring finns ett problem hur många gånger bilnyckeln kan aktiveras när den inte är i närheten av bilen - och hur Chrysler hanterat detta problem:

The transmitter is matched to the car at the factory, but it has some kind of internal limitation on how many new unique codes can be generated without communication. According to the owner’s manual, if the keyless entry is keyed “more than 250 times” when not within range of the car, this pairing is lost. I suspect they really mean more than 255 times, but that’s a nit. Anyway, since there is a way the customer can lose the pairing, there has to be a way to resync.

The way to resync, on my car, is simply this: Lock the doors (using the door-lock switch on the door, of course, because your remote doesn’t work), then press the buttons on the remote in a particular way (which I will skip here to maintain a little security through obscurity). The remote resyncs and then can be used to unlock the door again.

Så vad är problemet? Jo, det här:

If you haven’t figured out the exploit by now, it is simply that if the owner of the car has locked his doors with the door-lock switch, any schmoe with the same remote can then press the appropriate sequence on his remote and get into the car.

Oops!

Ett enkelt sätt för Chrysler att fixa detta hade varit att kräva att nyckeln används för att starta tändningen i bilen för att synkroniseringen skall genomföras, vilket gör att den fysiskt korrekta nyckeln användas.

(Tipstack till Leif.)

NSA och SRAM-baserade FPGAer för kryptosystem

Thursday, August 30th, 2007

(Det här blev en stor text…)

En sak som dök upp bland informationen om NSAs moderniseringsprogram är att NSA och FPGA-tillverkaren Xilinx genomfört ett i mitt tycke extremt intressant projekt. Vad NSA och Xilinx har gjort är att både analysera säkerheten i SRAM-baserade FPGAer samt utvecklat metodik och verktyg för att implementera system som möter NSAs säkerhetsklass FSDA - Fail Safe Design Assurance.

Projektet inkluderar saker som FPGAer, rekonfigurerbara arkitekturer, metodik och system på chip i kombination med kryptoimpementationer och säkerhet - det kan inte bli mer Kryptoblog än så här! ;-)

(Brasklapp: Ja, NSA och Xilinx publicerade information om detta projekt i Februari i år och jag borde naturligtvis sett detta då, men bättre sent än aldrig. Och jag ser inte att detta uppmärksammats tidigare, speciellt inte i Sverige.)

FPGAer används sedan tidigare i säkerhetssystem för att realisera olika typer av funktioner - typiskt acceleration av kryptofunktioner. Men de FPGAer som används är förhållandevis små och dyra. Dessa FPGAer är baserade på antingen FLASH-minnesteknik eller antifuse (dvs säkringar av Tungsten som bränns av och därmed konfigurerar FPGAn).

Att implementera kompletta säkerhetssystem i en FPGA har även det undvikits av rädsla för att det inte skall gå att upprätthålla röd/svart-separation inne i FPGA:n, med risk för informationsläckage och säkerhetsproblem.

Röd/Svart-separation

Resultatet blir maskiner med fler än en FPGA - FPGAer som är små, dyra och sitter monterade på mönsterkort i maskiner som därmed rent fysiskt blir stora och klumpiga. Inte alls bra - men med kontrollerbar och verifierbar säkerhet.

SRAM-baserade FPGAer (från i första hand Xilinx och Altera) å sin sida har kapacitetsmäsigt snabbt växt till att i dag vara kapabla att implementera massiva datorsystem (med CPUer, minnen och applikationsspecifika funktioner) på ett enda chip (SRAM-FPGAer används i dag som testchip vid utveckling av nya kiselprocesser, ligger i framkant på Moores lag och är bland de första kretsarna som kommer ut i volym när en ny processnod startas upp.)

Den snabba utvecklingen driver ner priset på SRAM-baserade FPGAer och gör det möjligt att implementera allt större, kompletta inbyggda system på ett chip som går att bygga in i fysiskt små, allt mer mobila applikationer. Att kunna använda SRAM-baserade FPGAer även för implementation även kompletta system avsedda för de högsta säkerhetsklasserna vore mycket välkommet. (En personlig reflektion är att utvecklingsverktygen för SRAM-baserade FPGAer ofta är både billigare och bättre, detta för att det finns en större användarbas och fler leverantörer)

Exempel på vad NSA vill kunna implementera i en FPGA är redundanta kryptoenheter, röd/svart-separering intern på chippet och chip med funktioner som arbetar med olika säkerhetsklass.

Det NSA och Xilinx gjort är att analysera säkerheten och sedan utveckla metoder för bygga säkra systemimplementationer på Xilinx FPGA-familj Virtex-4

Xilinxs FPGA Virtex-4

En Virtex-4 består av ett rutmönster med rader och kolumner av funktionsblock som upprepas över hela kretsytan. Typiska funktionsblock är logikblock, minnen, multiplikatorer samt block för acceleration av signalbehandling (DSP) och tom hela PowerPC-processorer.

Virtex-4 die
(Bilden visar kiselbrickan i en Virtex-4 och man kan tydligt se kolumner och rader med olika funktionsblock, bland annat DPS-funktioner.)

Det grundläggande funktionsblocken är ett block för implementation kallat Configurable Logic Block (CLB) samt ett block som implementerar kommunikationen mellan de olika funktionsblocken på chippet kallat Global Switch Matrix (GSM). Xilinx och NSAs analys utgick från CLB- och GSM-enheterna för att se hur man skall kunna implementera en funktion i FPGA:n som är isolerad från resten av FPGA:ns funktionsblock. Figuren nedan visar uppbyggnaden ev en CLB:

CLB

Det man kom fram till är att det räcker med att omgärda den specifika funktionen med en ram av CLB:er som är en CLB-bred. Min gissning till varför man vill ha en CLB:s separation är att CLB:er är tätt kopplade till sin närmaste grannar, ex genom carry-kedjor. Om man då ser till att allokera döda CLB:er bryts dessa kedjor. Men detta räcker dock inte, utan man måste även titta på kommunikationen - både matriselementen (GSM) och de fysiska ledarna.

Kommunikationen på en FPGA som Virtex-4 består av ett antal ledare som från en given punkt (en CLB) sträcker sig olika antal steg bort. Exempelvis finns en ledartyp kallad HEX som sträcker sig till en CLB tre och sex steg bort.

Det man kom fram till är att det krävs en metodik för att märka upp de ledare som används så att även om bara en del av ledningen används får ingen annan funktion implementeras i en CLB som är kopplad på längs hela ledaren. Detta löstes genom att Xilinx införde ett direktiv NOBOUNDARYCROSS i sitt Place & Route-verktyg.

Xilinx PAR

Vidare utvecklades ett verktyg kallat IVT (Isolation Verification Tool) som utifrån mappningsinformation går in och verifierar att alla isoleringsramar (de tomma CLB:erna) är kompletta och att inga ledningar som allokerats för en funktion passerar genom en isoleringsram. (Verktyget IVT ser inte ut att vara tillgängligt, men då all information går att extrahera från designverktygen borde det bara vara en fråga om programmering att skapa sin egen version av IVT.)

Det som krävs för att lyckas med det Xilinx och NSA genomfört är att konstruktören har möjlighet att styra/kontrollera hur sina funktioner placeras på chipytan. Xilinx och NSA utnyttjar att Xilinx i sina FPGAer stödjer partiell rekonfiguration, dvs att bara delar av FPGAns funktionsblock konfigureras. Detta gör det även möjligt att i en Xilinx-FPGA dynamiskt byta ut olika funktioner, exempelvis kryptoacceleratorer.

För att kunna åstadkomma kompletta system på chip behöver funktionsblocken kommunicera med varandra. För detta implementerades speciella generatorer för specifika kommunikationsbussar. De genererade kommunikationsbussarna integreras i den totala FPGA-konstruktionen. Slutligen implementerade NSA även en säkerhetsmonitor som kan läggas in i en FPGA och övervaka säkerheten för resten av systemet, och om så krävs vidta åtgärder - exempelvis konfigurera om en del av FPGA:n.

En viktig implementationsaspekt som tas upp är att externa I/O:n från separata funktioner inte bara inte skall dela samma fysiska I/O (pinne eller boll), utan att dom inte heller skall dela samma I/O-bank. (I/O:n i en FPGA är uppdelade i olika bankar där I/O:n i en bank har gemensam matning - vilket skulle kunna öppna upp för sidoattacksbaserat informationsläckage). Vidare är det vanligt att I/O:n på en FPGA har multipla funktioner, vilket man som konstruktör måste hålla reda på och om så krävs undvika dessa I/O:n.

Den genomförda analysen av Virtex-4 som krets inkluderade känslighet för olika typer sidoattacker samt JTAG-baserade attacker. NSA och Xilinx genomförde även en intressant analys av hur länge en SRAM-FPGA bibehåller konfiguration samt data i register och minnen när matningen kopplas ifrån (remenance). Det saknas information om vad man kom fram till, men tydligen var det tillräckligt bra. Troligen finns det dock krav på hur FPGA:n skall kapslas för att tillräcklig med tid hinner passera innan det går att fysiskt komma åt SRAM-cellerna.

Slutsatsen från Xilinx och NSA är att det med rätt metodik och verktyg går att använda Xilinx Viirtex-4 i applikationer med hög säkerhet.

Hela Xilinx och NSAs arbete finns beskrivet i relativt hög detalj i en artikel publicerad i Military Embedded Systems - Läs den!

Några detaljer som går att utläsa från artikeln är att testkonstruktionen troligen inkluderade en implementation av blockkryptot AES. Samt att NSA använder det hårdvarubeskrivande konstruktionsspråket Verilog (kloka människor).

Det som inte är klart är hur konfigurationsinformationen skyddas. Xilinx-4 inkluderar en AES-motor för kryptering av konfigurationen (där nyckeln är lagrad i register med separat matning från resten av chippet) och möjligtvis skulle man kunna dra slutsatsen att NSA anser att detta skydd är tillräckligt bra.

Konspirationsteoretikern kan ju invända att detta bara är bluff och båg, och ett sätt att få de NSA anser vara skurkar att börja använda Xilinx SRAM-baserade FPGAer för att implementera sina kryptosystem. Men jag tror inte att det är speciellt sannolikt. Ett skäl är att Xilinx bara tillverkar SRAM-baserade FPGAer och tidigare inte kunnat konkurrera med leverantörer som Actel och QuickLogic inom segmentet säkerhet av högsta klass.

Nyttigt och ojojoj så spännande är det i alla fall!

Praktiskt genomförbar attack mot kryptot i bilnycklar

Friday, August 24th, 2007

Eli Biham, Bart Preneel & Co presenterade på CRYPTO 2007 en praktiskt genomförbar attack KeeLoq, det krypto som bland annat sitter i elektroniska bilnycklar. KeeLoq är ett företagsspecifikt krypto utvecklat av Microchip (mest kända för sina PIC-processorer)

KeeLoq

KeeLoq ett NLFSR-baserat (Non Linear Shift Register) blockkrypto med en blockstorlek på 32 bitar och en nyckellängd på 64 bitar:

KeeLoq-kryptering
(Bild lånad från Wikipedia)

Tidigare attacker mot KeeLoq har haft en tidkomplexitet på 2**37 (vilket är en praktiskt sett orimligt lång tid) och krävt ca 16 GByte utrymme. Det Biham & Co nu gjort är att de hittat en attack som kräver insamling av data från en KeeLoq-enhet under ca en timmes tid (65 minuter), samt ca två dagars körtid på 50 stycken Dual Core-maskiner. Författarna estimerar attacken till att vara ca 500 ggr snabbare än tidigare publicerade resultat, och ligger helt inom en praktiskt genomförbar tidsrymd.

Än mer besvärande är att det protokoll som används i KeeLoq-systemet med en IFF-funktion (Indentification Friend or Foe) gör att det går att locka av en KeeLoq-enhet det data som behövs för att utföra en attack om man bara kommer i närheten av enheten.

Ett annat graverande problem för KeeLoq är nyckelhanteringen. KeeLoq består av en huvudnyckel samt individuella nycklar. Huvunyckeln XOR:as med det individuella nyckeln. Detta gör att om man kommer över individuella nycklar går det att enkelt räkna ut huvudnyckeln, och därmed exponeras inte bara en eller två enheter utan alla individer inom en nyckelgrupp.

KeeLoq används i dag av ett antal olika bilmärken, exempelvis Volvo, GM, Jaguar, Toyota och Honda. KeeLoq används även i ett otal andra applikationer, exempelvis fjärrstyrda garagedörrar och larmsystem.

Just nu är det svårt att säga hur Microchip och dess kunder (ex Volvo) kommer att reagera på detta, men en gissning är väl att man kommer att börja med att förneka att det finns ett problem. Avsett utgången visar detta att hemmasnickrade algoritmer och protokoll oftast inte är speciellt bra - inte minst för att det inte blir ordentligt undersökt innan det finns implementerat i miljontals produkter.

Det jag är rädd för är att folk kommer att få sina bilar stulna, och att försäkringsbolagen tror på leverantörernas försäkran om att KeeLoq är säkert.

Eller som Bihan & Co lite skämtsamt uttrycker det: Soon, cryptographers will all drive expensive cars.

RFID-baserad utslagningsattack mot pass-system

Thursday, August 23rd, 2007

Wired har publicerat en (kort) artikel om den tyska säkerhetsforskaren Lukas Grunwald
Lukas Grunwald
Artikeln berättar att Lukas, som tidigare visat att han kan klona RFID-chip i pass nu utvecklat en RFID-baserad attack mot pass-systemen.

Enligt artikeln lagras bildinformation på RFID-chippet i passet i JPEG200-format. Datat i en JPEG200-bild är komprimerat med en aritmetisk kompressor. Lukas attack går ut på att konstruera en speciell, patalogisk JPEG2000-bild, som när den expanderas, sväller över alla bredder och spränger det minne som används för dekompressionen. En klassisk buffertöverskrivningsattack som resulterar i att RFID-läsaren (eller det bakomliggande pass-systemet) slås ut.

Lukas Grunewald hävdar att det faktum att RFID-läsaren slås ut innebär att RFID-läsaren går att injektera med elak kod, exempelvis för att få den att istället använda en gammal bild och därmed sätta säkerheten i ett pass-system med RFID-utrustade pass ur spel.

Jag håller inte med om att en buffertöverskrivning som leder till en utslagning automatiskt implicerar en möjlighet att injektera kod eller på annat sätt manipulera det attackerade systemet, och Wireds artikel är för kort och luddig för att dra några egentliga slutsatser om vad Lukas åstadkommer i det attackerade systemet.

Men, bara det faktum att det går att gravt påverka/slå ut de nya pass-systemen på detta sätt tycker jag är mycket intressant i sig. Jag tycker att detta visar, och här delar jag Lukas åsikt, är att inbyggda system i allt för liten grad implementeras utifrån en kravställning som tittar på IT-säkerhet och hantering av felfall. Precis som Lukas säger har man antagligen tagit ett standardbibliotek för JPEG200-hantering och sedan helt struntat i att övervaka bildexpansionen. Indata från externa källor, speciellt i ett publikt säkerhetssystem som ett pass-system är, skall betraktas som potentiellt fientlig och behandlas därefter.

Och, det viktigaste, så länge som beställarna/kravställarna av inbyggda system inte tar med krav på säkerhet i sina beställningar kommer de allra flesta konstruktörer (de som inte är IT-säkerhetsparanoida redan innan) att implementera för att uppfylla de funktionella kraven och minimera implementationen i den normala kostnadsjakten. Det är så inbyggda system konstruerats i årtionden, men det börjar bli hög tid att vakna upp. Buffertöverskrivningsattacker är ingen nyhet precis, och bara för att man bygger inbyggda system får man inte vara omedveten om dessa problem.

SSH-bakdörr i ReadyNAS

Friday, August 10th, 2007

Infrant (numera Netgear) är tillverkare av den populära nätverkslagringsenheten ReadyNAS.
En ReadyNAS
Enligt en pressrelease från tillverkaren visar det sig att det finns en funktion i ReadyNAS OS RADIiator som gör det möjligt för Infrant/Netgear att få rootaccess på en ReadyNAS:

Each ReadyNAS system incorporates a different root password that can be used by NETGEAR Support to understand and/or fix a ReadyNAS system remotely using the ReadyNAS serial number as a key.

An attacker that has obtained the algorithm (and your serial number) to generate the root password would be able to remotely access the ReadyNAS and view, change, or delete data on the ReadyNAS.

Infrant har nu släppt verktyget ToggleSSH som gör det möjligt att slå av SSH-bakdörren. Har du en ReadyNAS bör du nog tanka ner och applicera det verktyget. Bakdörren har dock skapat en hel del upprördhet, inte bara för att tillverkaren har ansett sig ha ett behov av denna möjlighet, utan för att man mörkat om att fuktionen har funnits.

Liten och smidig VPN-burk

Tuesday, August 7th, 2007

IDG har publicerat en recension av Zyxel Zywall P1, en bärbar VPN-burk som ser liten och smidig ut:
Zywall P1 i ett filofax-fodral.
En bra sak med maskinen är att den får sin strömförsörjning från USB-porten, vilket gör att man slipper att släppa på en transformatorklump till. Zywall P1 är nu inte den enda lilla brandväggs- och VPN-lösningen som dykt upp på marknaden och jag gillar trenden mot små, enkla HW-baserade säkerhetslösningar. Mer sånt här!