Kryptoblog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jag har precis lagt till en ny blog till bloglistan. Den här gången är det Flylogic Engineering’s Analytical Blog från företaget Flylogic.

Flylogic är ett av mycket få företag som har kompetens och utrustning som krävs för att plocka isär och analysera inte integrerade kretsar. Deras blog är fylld med bilder på chip, nedfilade kapslar och isärplockade kort.

Att döma av deras blog är en av Flylogics favoritverksamheter att plocka isär elektronikprodukter som är utrustade med säkerhetsmekanismer eller är avsedda att tillhandahålla olika typer av säkerhet. Bland annat har Flylogic med framgång plockat isär och gått runt säkerheten hos ett flertal säkra USB-minnen. Här är exempelvis MAI:s KEYLOK:

En fin USB-blobba på väg till slaktbänken.

KEYLOK uppsprättad. Notera att det inte finns något mer fysiskt skydd för kretsarna.

MCU:n CY7C63101A isärplockad och färdig att proba.

Närbild på chippet. Notera minnesarrayen till höger.

Och så avslutar man med att läsa ut data direkt från minnet:

We performed some magic and once again we have success to unlock the once protected device. A quick look for ASCII text reveals a bunch of text beginning around address $06CB: .B.P.T. .E.n.t.e.r.p.r.i.s.e.s…D.o.n.g.l.e. .D.o.n.g.l.e. .C.o.m.m.< .E.n.d.P.o.i.n.t.1. .1.0.m.s. .I.n.t.e.r.r.u.p.t. .P.i.p.e.

En annan krets Flylogic attackerat är Atmels CryptoMemory som jag tidigare bloggat om. Här är en bild på sådana chip plockade från sin vanliga miljö för bättre analysmöjligheter:

Som HW-nisse med intresse för IT-säkerhet är det här nästan som julafton, och en hel månad i förväg!

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

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

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…

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.

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:

• Remotely Keyed Cryptographics: Secure Remote Display Access Using (Mostly) Untrusted Hardware
• Ett Peer to Patent-patent om Cipher method and system for verifying a decryption of an encrypted
  user data key
• CryptoGraphics: Secret Key Cryptography Using Graphics Cards

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:

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.

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.

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

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…

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:

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…

Det finns en tidning på Internet om IT-säkerhet kallad Uninformed. Syftet med tidningen är enl tidningens redaktörer:

Uninformed is a technical outlet for research in areas pertaining to security technologies, reverse engineering, and lowlevel programming. The goal, as the name implies, is to act as a medium for informing the uninformed. The research presented here is simply an example of the evolutionary thought that affects all academic and professional disciplines.

Det åttonde numret av Uniformed släpptes för ett par veckor sedan och innehåller artiklar om:

- Covert Communications: Real-time Steganography with RTP
Author: I)ruid

- Engineering in Reverse: PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3
Author: Skywing

- Exploitation Technology: Getting out of Jail: Escaping Internet Explorer Protected Mode
Author: Skywing

- Exploitation Technology: OS X Kernel-mode Exploitation in a Weekend
Author: David Maynor

- Rootkits: A Catalog of Local Windows Kernel-mode Backdoor Techniques
Authors: skape & Skywing

- Static Analysis: Generalizing Data Flow Information
Author: skape

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.

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