Archive for the ‘Hårdvara’ Category

Dagens säkerhetsdumhet presenteras av….

Thursday, November 15th, 2007

FPGA-leverantören Xilinx.

Var precis inne på Xilinx webbplats och upptäckte att på sidan för att ladda ner utvecklingsverktyg fanns den här uppmaningen till Xilinx användare:

Turn off virus scanner to reduce installation time. Download file will contain installations for multiple platforms. After downloading, unzip the file and run “setup”

Detta på en webbplats som endast är skyddad med ett lösenord. Jag som användare har ingen möjlighet att verifiera att:

  1. Sidan verkligen tillhör Xilinx och är en del av deras webbplats.
  2. Programmet som laddas ned kommer från Xilinx
  3. Programmet som laddats ned inte påverkats på vägen

Att då uppmana sina användare att stänga av viruskontrollen är kort sagt uselt säkerhetstänkande. Xilinx använder SSL/TLS på delar av sin webbplats, men inte på sidan för nedladdning. Och hur svårt är det egentligen att ta fram och publicera information om storlek och signatur för de filer man gör tillgängliga? (Även om en sådan information behöver skyddas den också - om webbplatsen är hackad är antagligen den informationen inte att lita på.)

Jag har skickat en kommentar/uppmaning till Xilinx om att ta bort sin uppmaning och tänka till på säkerheten. Om jag får ett svar återkommer jag.

En kollega kom för övrigt med en bra observation: Varför är det så få kommersiella företag som publicerar signaturer för de filer och program de gör tillgängliga? Ser man MD5-, SHA-signaturer kan man nästan vara säker på att leverantören är ett öppen/fri kod-projekt.

Berusad man vs värmeverk i Trollhättan

Wednesday, November 7th, 2007

(Tipstack till Månster) Det här dök upp på DN.se. En berusad man tog sig tydligen in på fjärrvärmekraftverket i Trollhättan i går morse och lyckades stänga ner verket:

På något sätt tog han sig in i värmeverket och tryckte på alla knappar som reglerar värmeverket han kunde hitta, innan personalen upptäckte hans tilltag, skriver Göteborgs-Postens nättidning.

- Så här får det inte gå till. Vi har ju larmat men efter det här måste vi se över vårt skalskydd, säger Mats Johansson, vd i Trollhättan Energi som driver fjärrvärmeverket, till TT.

Under de tre timmar det tog drevs verket med reservkraft.

Mannen hade tidigare under natten till måndagen suttit hos polisen i Trollhättan misstänkt för narkotikabrott. Direkt efter att han släppts tog han sig till värmeverket. På morgonen var han åter på polisstationen men hade vid lunchtid ännu inte hörts.

Den lokala tidningen TTELA har en de ytterligare information om händelsen:

Intrånget i det obemannade kraftvärmeverket vid Lextorp gjordes vid sjutiden i går morse. De ansvariga på Trollhättan Energi misstänker att mannen tog sig in på området i samband med att grindarna öppnades för en lastbil som skulle lämna flis. Sedan ryckte han upp en dörr till den gamla oljecentralen och fortsatte in i den nya delen av anläggningen via en gångtunnel.

När vi pratar en massa om IT-säkerhet, skydd för SCADA-system etc kan det vara bra att komma ihåg att en vanlig hederlig dörr också kan vara ett bra sätt att ta sig in på. Ett stopp på tre timmar orsakat av en berusad person, vad skulle någon med lite vilja och mindre alkohol i kroppen kunnat åstadkomma?

Verket det handlar om är det här, en klassiskt byggnad i Trollhättan:

Lextorps värmekraftverk
(Värmeverket - Lextorps finest inom industriarkitektur)

För er som inte varit i Trollhättan kan man titta på filmen Fucking Åmål. Den gångbro över vägen som finns med i filmen är där värmeverket ligger i verkligheten. Har för mig att verket syns i filmen.

SRAM för ID och slump del tre

Monday, November 5th, 2007

Jag har tidigare i ett antal omgångar bloggat om en artikel som beskriver en teknik för att använda initialtillståndet i SRAM för att identifiera enheter samt generera slumptal. Jag har under hösten haft en mailkonversation med en av författarna bakom artikeln för att försöka förstå säkerhetsimplikationerna runt tekniken. Nu har jag fått ännu en laddning med svar. Diskussionen den här gången handlar om informationsläckage, hur väl det går att identifiera en enhet och ett minnesblock samt risken för felidentifiering.

(Q1) Have you looked at the minimum number of bits in the memory dump to get good enough Hamming vales for the fingerprints?

(A1) Yes, we explore this further in an upcoming publication. We should that 64 bits of SRAM can be used to differentiate between 5120 blocks of SRAM.

(Q2) My bad: There was a “not” missing in the first sentence. What I meant was, of course if *not* “long-enough” time have lapsed, then wouldn’t you risk exposing application information in the memory dump due to the remanence?

(A2) Ok, I understand now. Yes, it would risk leaking application information in the memory dump. This is not something we have given much thought to yet, but is an interesting implication.

(Q3) The number of samples to create the template depends on how reliable the mem dump of the device is. We found that 3 was reasonable for creating a template, but using more dumps will result in a more accurate template. In fact, the matching can often be done based on a template created from just a single memory dump, with no averaging at all. What is the number of effective bits in the ID in that case? And what are the false acceptance and false recection rates?

(A3) The number of effective bits number is around 90% of the total number of bits. The exact acceptance rates depend on the population size and number of bits used, but the acceptance rates are generally quite good.

(Q4) If the device gets it’s ID from an external device it can no longer reliably state “I’m ID XYZ” but can be told by the external unit a false ID which is then used by the device to perform authentication. I see a potential MITM-attack on this setup. No?

(A4) There may be potential for a MITM attack. We are currently still working on the system level implications of our design.

Mao ser det ut som att man med relativt liten mängd data (64 bitar) kan identifiera ett specifikt SRAM block och därmed en individ på 5120, dvs en på drygt 2**12. Samtidigt säger man att man har en biteffektivitet på 90%.

Men det stora problemet är informationsläckage och möjlighet att lura systemet, vilket författarna går med på är ett problem, men verkar vara problem som ligger på systemnivå.

Jag tror att jag kommit till vägs ände med den här diskussionen och tänker inte fortsätta störa författarna. Det har dock varit mycket intressant att få chans att läsa, fundera ställa frågor, följdfrågor och få chans att diskutera med forskarna. Hoppas att du som läsare också fått ut något konkret.

Jag kommer att bevaka och se när det kommer en uppföljningsartikel från författarna. Återkommer i så fall…

Ekologisk kryptanalys

Monday, November 5th, 2007

För en dryg vecka sedan kom nyheten att ryska Elcomsoft använt grafikprocessorer (GPU:er) för att accelerera knäckning av lösenord. Enligt en artikel på IDG.se använder Elcomsoft kort med Nvidias GPU GeForce 8800 för att få upp till 25 gånger bättre prestanda gentemot ren processorbaserad exekvering.

Nvidia GeForce 8800

Elcomsofts nyhet har även fått en hel del uppmärksamhet på annat håll. Det som framkommer där är att det handlar om en ny version av Elcomsofts Distributed Password Recovery som bla knäcker NTLM-lösenord.

Vad som dock inte varit lika uppmärksammat är att Elcomsoft försöker patentera konceptet med att använda GPU:er för att knäcka lösenord. Elcomsoft skriver i sin pressrelease:

Moscow, Russia - October 22, 2007 - ElcomSoft Co. Ltd. has discovered and filed for a US patent on a breakthrough technology that will decrease the time that it takes to perform password recovery by a factor of up to 25. ElcomSoft has harnessed the
combined power of a PC’s Central Processing Unit (CPU) and its video card’s Graphics Processing Unit (GPU). The resulting hardware/software powerhouse will allow cryptology professionals to build affordable PCs that will work like supercomputers when recovering lost passwords.

Men ett ställe där Elcomsofts planer att patentera tekniken fick en hel del uppmärksamhet var på Cryptologu-listan där flera personer både läst artiklar om, eller själva gjort det Elcomsoft nu gör (använda GPU:er på detta sätt). Några artiklar man hänvisade till var:

Notera: Jag gör ingen bedömning om Elcomsoft har torrt på fötterna vad gäller möjligheten att patentera tekniken eller ej (dvs om de refererade artiklarna är relevant prior art eller ej) - jag är ingen advokat. Däremot tycker jag att det är intressant att läsa artiklar som beskriver användning av GPU:er eller andra typer av specialdesignad hårdvara för andra syften än de var tänkta för, speciellt om den alternativa användningen råkar vara krypto och IT-säkerhet.

Ett exempel som är speciellt intressant och som jag tidigare fått ett tips om (tack LinusN) men inte hunnit med att blogga om innan är projektet NSA @ Home.

NSA @ Home är ett projekt där man tagit kort för HD-video-processing tillverkade av Grass Valley och byggt om innehållet i kortets 2D-array med FPGA:er för att implementera en brute force-knäckare för hashfunktionerna MD5 och SHA-1.

Korten som används är kort som Grass Valley kasserat, men som genom analys av kopplingen på kortet och genom att routa runt problemen gått att återanvända för den nya tillämpningen:

GV kort för NSA @ Home.

Korten är utrustade med tre uppsättningar (en uppsättning för varje videokanal) om fem Xilinx Virtex-II Pro (XC2VP20) vardera. Kortet förbrukar 240 W och ger motsvarande brute force-prestanda som (enl projektet själva) 1500 stycken Athlon FX-60, vilka skulle förbruka ca 250 kW.

Xilinxlogga.

Som HW-konstruktör är jag extremt imponerad av hur Stanislaw Skowronek (skaparen av NSA @ Home) med hjälp av JTAG kommit fram till hur kortet är kopplat, skapa en ny grundplattform med nya interface, kontroll-SW, webbinterface(!) etc för att förvandla skrotade kort till ett system med j-kligt imponerande prestanda.

Det finns ett företag i Sverige kallat Edgeware som bygger ett Video on demand-system. I deras maskin Orbit2x sitter det om jag fattat det rätt massiva mängder med FPGA:er och snabba minnen, detta för att hinna med att processa massor med vidoströmmar.

Orbit2x

Undrar hur bra det skulle gå att använda Edgewares maskin för brute force-attack mot lösenord och hashfunktioner….

Mer om SRAM för ID och slumptalsgenerering

Friday, October 19th, 2007

Jag har fått svar från Dan Holcomb, en av forskarna bakom den artikel där dom beskriver användning av SRAM för ID och slumptalsgenerering jag tidigare bloggat om. Dan svar på mina frågor ger svar på en del av saker jag tidigare tagit upp här på Kryptoblog. (Notera att jag taggat upp frågor och svar för att det skall bli lättare att följa med.)

(Q1) If you communicate the complete SRAM state, this implies that the external host get access to the the RNG sources supposedly to be used by the device for seeding device-internal cryptographic functions. Isn’t that a security problem?

(A1) Our intent is that a given block of SRAM would either be used for TRNG or else for ID, but never used for both on a given power-up. You are correct in observing that our random source would not be useful in TRNG if we transmit it as ID.

Här måste man alltså på något sätt komma på att hålla reda på vilka block i kretsens minne som skall användas för vad. Och hur skall kretsen veta vilka block den skall använda? Om den får order om att leverera ett givet block, hur vet den att det inte är ett av de block som bara skall användas som entropikälla och därmed inte skickas iväg?

(Q2) Have you consider low cost/low complexity methods for the device to determine if “long-enough” have passed? That is allowing the device to check if the SRAM have reached proper initial state, and if not take protective actions? (For example refusing to communicate with an external host.

(A2) We have not yet put much thought into how to prevent this, but do agree that this is an issue that really does need to be addressed.

Här behöver man alltså hitta teknik och metodik för att kontrollera tiden och hantera situationen när för kort tid passerat.

Sedan hade jag flera frågor som till viss del var relaterade till upprepad kommunikation av data, vilket det visade sig att dom inte gör:

(Q3) I didn’t see the info in the paper about this (I might have missed it): How many times do you need to extract the SRAM mem dump from the device (with power cycling and waiting “long-enough” in between) to perform device fingerprint template creation with reasobable accuracy?

(A3) The number of samples to create the template depends on how reliable the mem dump of the device is. We found that 3 was reasonable for creating a template, but using more dumps will result in a more accurate template. In fact, the matching can often be done based on a template created from just a single memory dump, with no averaging at all.

(Q4) How many times do you need to extract the SRAM mem dump from the device (with power cycling and waiting “long-enough” in between) to perform fingerprint device matching (i.e to identify a known device) with reasobable accuracy?

(A4) Once the template is created, the matching is performed based on a single fingerprint collected in the field (a latent print). The averaging is only applied when creating the template (a known print).

(S5) If the complete state is communicatied (x number of times) to get the device ID, given the use of similar communication means as other low cost RFID devices (passiv, back scatter) your method would at least take much longer time, correct? For example 256 Bytes * x dumps vs 4-8 Bytes for stored device ID.

(A5) Only one dump is transmitted. But still it takes longer: with each bit of SRAM providing less identifying ability than EEPROM, a greater number of bits (compared to EEPROM) must be transmitted.

Mao är det vid matchning mycket mindre data som behöver skickas än jag först misstänkte - vilket är bra. Däremot verkar dom använda begreppet latenta fingeravtryck på ett något märkligt sätt. Det dom gör en matchning med en kandidat. Nåja, tillbaka till frågor och svar:

(Q6) Have you looked at the amortized cost of identifying the device though its lifetime using your FERNs technology vs adding (E)PROM/fuses to the device (with additional device and manufacturing cost)? This might be hard to do, but would be interesting to see.

(A6) We have not analyzed this. The EEPROM cells are smaller than RAM cells, but the process costs are higher, and the charge pump adds area overhead. The advantage of using SRAM is that it doesn’t need to be added specifically for our purposes and can be used as general purpose memory.

(S7) Have you considered the change in device identification/authentication protocols your scheme causes? As I understand it, the device doen’t know it’s ID (you stated as much in a previous response), instead it has to rely on an external host to establish the identity. How does this affect things like challenge/response protocols? Any security implications of this?

(A7) When I said that the device doesn’t know its ID, i meant only that it doesn’t need to be programmed to have its ID. In other words, it doesn’t have any recollection of its ID in non-volatile storage. It still contains the ID whenever it is powered on, so it is exactly analogous to how EEPROM always contains its ID. The only difference is that the ID is not fully reliable.

Om jag fattat det rätt pratar alltså Dan om det ID som den externa läsaren tar fram och sedan överlämnar till kretsen, och Dan ser inte att det ändrar förutsättningarna för ID:t.

Jag har skickat några följdfrågor, men jag är rädd för att jag böjar bli jobbig och inte får fler svar… ;-)

Mer om säkerhet i inbyggda system

Tuesday, October 16th, 2007

Det kommer mycket artiklar just nu om säkerhet i inbyggda system. Det känns som att branschen har börjat vakna till och inse att man behöver tänka på säkerheten - speciellt när man börjar gå från lokala system i ett apparatskåp till system med fjärröverkning och kontroll. En iofs gammal men bra översiktsartikel är Securing wireless MCUs is changing embedded system design från Embedded.com.

Artikeln tar upp just problemställningen att allt fler system kopplas upp - ofta med trådlösa kommunikationstekniker, men att det innebär förändrade säkerhetsmodeller:

Inbyggda system - uppkopplade över Internet.
En sak de tar upp i artikeln är hur (illa) krypton är anpassade till inbyggda system. Till våren kommer förhoppningsvis avslutningen av eSTREAM att ge oss mer än ett krypto som fungerar bra även för inbyggda system.

Förra veckan var det Scanautomatic i Göteborg. Jag var där, och det vimlade av olika typer av PLC:er, styrsystem, kontrollplattformar för industriautomation. Jag hittade en (1) leverantör som kunde svara på frågan hur dom skyddade kommunikationen (med SSL) - alla andra undrade vad jag menade.

Även om deras system-modeller ofta var att maskinerna skulle kopplas in på lokalnätet (LAN) var det påfallande många som pratade om publik IP-adress. Och, naturligvis, allt styrt via ett webbgränssnitt. Det finns mer att göra…

Spioninsekten ser dig

Thursday, October 4th, 2007

Enligt en artikel på EE Times håller USAs försvarsforskningsorganisation DARPA på att ta fram cyborginsekter som kan användas för spioneri. Exempelvis den här lilla gynnaren:
En cyberkackerlacka.
(Vet inte om det är en inbyggd reflex att stampa på kackerlackor, men den där triggar mitt stampben iaf…)

Radiostyrda djur kallade Hybrid-Insect MEMS (HI-MEMS) blir bärare av olika typer av tekniska system. Tänkbara applikationer för radiostyrda insekter är naturligtvis övervakning men även spårning, speciellt med hjälp av malar:

Moths are extraordinarily sensitive to sex attractants, so instead of giving bank robbers money treated with dye, they could use sex attractants instead,” said Easton. “Then, a moth-based HI-MEMS could find the robber by following the scent.

Att döma av artikeln verkar DARPA inte se några integritetsmässiga eller etiska problem med HI-MEMS, utan att detta är en förlängning av hur människan tidigare använt djur:

We have used horses for locomotion in wars,” according to Darpa’s description by its program manager, Amit Lal. “The HI-MEMS program is aimed to develop technology that provides more control over insect locomotion, just as saddles on horseshoes are needed for horse-locomotion control.”

Darpa cites that, historically, elephants have also been used for locomotion in wars, that pigeons have been used for sending covert messages, that canaries have been used to detect gases in coal mines, and that bees have been used to locate lands mines. Now it’s the moths and beetles turn to report for duty, just as dogs have already done.

Tekniken som sådan har förekommit i SF-litteraturen, bla av Peter F Hamilton. Men nu ser det ut att pågå ett antal konkreta projekt. Lite skrämmande är det. Fräckt, men skrämmande.

Att det är MEMS-teknik som gör det hela möjligt inser man när man ser den här bilden från Wikipedia:
Liten insekt, mindre kugghjul.
Tekniken krymper och nya möjligheter öppnar sig…

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.

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.

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