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

Archive for October, 2007

Kryptoblog drabbad av Mac-attack

October 30th, 2007

Snabb status: Nej, Kryptoblog har inte dött, men det gick inte så bra för mig vad gäller rapporteringen från RSA Conference.

Kvällen innan jag skulle åka iväg slutade min MacBook att ladda batteriet och jag blev tvungen att övergå till papper och penna. Detta funkade bra för att ta anteckningar, men det funkar sämre som bloggverktyg.

Jag hoppas att MacForum kan fÃ¥ fason pÃ¥ min maskin igen, och sÃ¥ snart det sker kommer en rapport frÃ¥n RSA Conference + en massa andra spännande saker. Just nu är jag mest frustrerad och fast i atomvärlden…

/Joachim

Stepic – Steganografi med Python

October 21st, 2007

Jag satt och letade efter Pythonbibliotek för att generera och manipulera bilder och grafik, och sprang då på en artikel om ett bibliotek kallat Stepic. (Ja, artikeln är från februari så den är inte purfärsk.)

Stepic är ett Pythonbibliotek (och applikation) för bildbaserad steganografi. Bibliotekets enda class Steganographer har två publika metoder encode och decode för att gömma och extrahera information lagrad i bilder. Artikeln innehåller ett par exempelbilder:

Bild innan data från Stepic
Bild 1: Orginalbild innan data gömts i bilden.

Data har sedan gömts i bilden som då ser ut så här:

Bild med steganografiskt lagrad data.
Bild 2: Samma bild, men med steganografiskt lagrad data.

Ser du skillnaden?

Jag körde en enkel md5-hash på bilderna för att se att dom skiljer:

MD5 (stepic-demo-before.png) =
ce5e5482d3ba9c5ed59f00820825f71a

MD5 (stepic-demo-after.png) =
b9cb6c127423fe82e08b40348a4ba116

(Bilderna skiljer även i storlek sÃ¥ egentligen säger inte md5 sÃ¥ mycket mer…)

Källkoden till Stepic finns pÃ¥ nätet och tittar man i koden ser det ut som att datat lagras med start i början bilden och sedan pÃ¥verkas sÃ¥ mÃ¥nga pixels som krävs för att koda in datat. Själva kodningen ser ut att vara en enkel/linjär förändring av intensiteten applicerad pÃ¥ 3×3 pixel stora kernels.

Mer om SRAM för ID och slumptalsgenerering

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… 😉

Kryptoblog @ RSA Conference Europe

October 19th, 2007

En kort blänkare: Jag hår fått chansen att vara med på RSA Conference Europe som går på Excel i London nästa vecka.

RSA-bild.

Jag skall försöka blogga så mycket jag kan direkt från konferensen. Jag kommer bla att gå på dragningar om fuzzing, keynote med Bruce Schneier samt vara med på ett möte med Frank Abagnale. Otroligt spännande och coolt.

Peter Gutmann om Microsofts Cipher.exe

October 19th, 2007

För några dagar sedan hamnade jag i en diskussion om hur man bäst åstadkommer säker radering av minnet i en mobiltelefon. Nu kom vi inte fram till någon entydigt bra lösning. Magnus Lindqvist på Microsoft tipsade dock om att man i Windows kan använda programmet Cipher.exe för att rensa en hårddisk. Mer exakt skall man i Windows köra Cipher /W.

Då jag inte kände till vad Cipher.exe gör bad jag om att få lite mer information om applikationen och fick länkar till två sidor:

På dessa sidor beskrivs funktionen i Cipher.exe och hur applikationen kan användas för att säkert radera en hårddisk på följande sätt:


Cipher.exe erases residual data on the formatted disk by writing the disk with all 0s, then with all 1s, then with random numbers. The original data on the disk will now be very difficult to salvage; however, it may still be possible to salvage original data. For additional security, run the Cipher.exe command multiple times.

Jag tyckte att detta lät väldigt mycket som den metodik för att säkert radera hårddiskar och minnen som Peter Gutmann publicerade för ett antal år sedan. Jag skickade därför ett mail till Peter för att kolla om han tittat på Micrsofts metod. Jag bad även att få publicera Peters svar. Och här kommer det:


For a general comment on this, see the Epilogue section at the end of
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html.

> Have you looked at Microsofts Cipher.exe strategy? And what is your opinion?

Hmm, I’m not sure if it’d get everything because if it just uses the big-file strategy (create a file that entirely fills the volume and write data to it) it won’t touch reserved disk areas (the MS pages say “Data that is not allocated to files or folders will be overwritten”, which implies that it uses the big-file strategy). If it does indeed do this then metadata won’t be deleted, and in particular the NTFS log will (presumably) be left intact, containing a pile of information about recent file operations.

I’d use something like DBAN, http://dban.sourceforge.net/, which uses a stripped-down Linux kernel as a host for erasing storage media. Since it just access the raw block device, it gets everything on there, including metadata and whatnot.

So cipher.exe is probably fine for just a general wiping of the disk (although I’d use Eraser, http://www.heidi.ie/eraser/, which has a nicer interface and does try and sanitise any metadata it can get to), but to really get everything I’d use DBAN.

SÃ¥ Microsofts metod är antagligen helt ok enligt Peter Gutmann. En kommentar man kanske inte hade väntat sig… 😉

Vi flytt int till IDG.se

October 18th, 2007

Jag har nu fattat ett beslut om den eventuella flytten av Kryptoblog till IDG.se. Och Kryptoblog stannar kvar precis här där vi är.

För mig var det två saker som avgjorde frågan:

  1. Det fantastiska stöd och alla kommentarer som ni som läsare gav. Att döma av kommentarerna skall Kryptoblog fortsätta på egen hand och inte ens riskera att uppfattas som icke oberoende.
  2. Rent tekniskt skulle bloggen gå från en WordPress-blogg till att vara baserad på community-systemet Xcap. Jag frågade runt och Xcap verkar inte vara ett speciellt bra system. Och att döma av de kommentarer ni läsare hade är tekniska funktioner som RSS mycket viktigt.

Tack alla läsare för hjälpen! Kul att se att det gick att lyfta frÃ¥gan om bloggen till bloggen och direkt fÃ¥ Ã¥termatning – väldigt spännande och inspirerande.

Nu kör vi pÃ¥ hÃ¥rdare än nÃ¥gonsin själva istället. Snart hoppas jag bla att kunna presentera lite egenproducerade kryptoprylar… (Om jag bara kan fÃ¥ min Pythonbaserade core-generator att fungera.)

Rätt Ingvar på FRA

October 17th, 2007

Fick just ett påpekande från signaturen Jonas om att jag satt in fel gubbe som illustration på FRA:s generaldirektör Ingvar Åkesson i en artikel här på Kryptoblog. Det här skall vara en korrekt bild på Ingvar Åkesson:
Ingvar Ã…kesson

Personen jag hade en bild på var tydligen överdirektör Anders Wiik. Jag ber Anders och Ingvar om ursäkt för sammanblandningen och tack till Jonas som påpekade felet.

Säkerhetsnyheter i Leopard

October 17th, 2007

Apple har börjat släppa en massa information om nästa version av MacOS X kallad Leopard. MacOS X 10.5 som OS:et även kallas kommer enligt Apple att släppas 2007-10-26. Den nya versionen skall enligt Apple ha mer än 300 nya funktioner. Jag tittade igenom listan med nya funktioner och blev överraskad över att så många saker har med säkerhet att göra:

  • Authenticated Printing. Kerberos-autenticierad utskrift.

  • Tagging Downloaded Applications. Applikationer som laddas ner frÃ¥n Internet hÃ¥ller OS:et reda pÃ¥ och första gÃ¥ngen det skall köras mÃ¥ste du som användare godkänna att detta sker.

  • Signed Applications. Applikationer är signerade (oklart hur).

  • Application-Based Firewall. Brandväggen kan ställas in för olika applikationer, gissningsvis pÃ¥ motvarande sätt som Litte Snitch.

  • Stronger Encryption for Disk Images. Nu kan man välja att använda AES-256 för kryptering. Förut var det bara AES-128.

  • Enhanced VPN Client Compatibility. VPN-klienten stödjer nu Cisco Group Filtering och DHCP över PPP.

  • Sharing and Collaboration Configuration. Dela data i foldrar skyddade med accesslistor för kontroll.

  • Sandboxing. Applikationer kan placeras i en sandlÃ¥da. Mycket bra, även om det är oklart om det gÃ¥r att göra med valfri applikation. Vad Apple skriver är att Bonjour, Quick Look och Spotlight indexer är sanboxade.

  • Library Randomization. Leopard fÃ¥r samma stöd som OpenBSD introducerade (om jag fattat historien rätt) och som även Windows Vista dvs att adresser/pekarna till bibliotek etc som applikationer använder slumpmässigt flyttas om sÃ¥ att det inte skall gÃ¥ att gissa (ASLR). För Vista har det förekommit mycket diskussioner om sättet detta sker i Vista är säkert nog eller ej. FrÃ¥gan är hur Apple gjort det är säkert nog. Värt att hÃ¥lla ögonen pÃ¥.

  • Windows SMB Packet Signing. Stöd för signerat data i Windowsnätverk.

  • Multiple User Certificates. En användare kan ha mer än ett certifikat och koppla dessa till olika emailadresser.

  • Enhanced Smart Card Capabilities. Utökat stöd för Smart Cards. Bla kan man nu lÃ¥sa/lÃ¥sa upp FileVault-enheter med Smart Card.

  • Kerberized NFS. Säkra upp NFS med Kerberos.

Leopard kommer även med ett rejält utbyggt stöd för Parental Control, dvs olika funktioner som gör det möjligt för föräldrar att kontrollera och övervaka sina barns datoranvändande.

Som icke-förälder ser jag ganska snett på den här typen av datorsäkerhet, men tydligen tror Apple att det är en bra sak att peta in. Nya Parental Control-funktionerna inkluderar saker som:

  • Time Limits and Bedtimes. Styr hur länge barnet fÃ¥r använda datorn och mellan vilka tider.

  • Dynamic Web Filter. Webbfilter för att som Apple uttrycker det: Protect your children from websites with unsuitable content.

  • Activity Logging. Logga vad dina barn sysslar med pÃ¥ datorn och Internet.

  • Remote Control & Monitoring. Kontrollera ditt barns datoranvändning pÃ¥ avstÃ¥nd (borde ha vissa säkerhetsimplikationer skulle man kunna tänka sig.)

  • Wikipedia Content Filter. Ett specifikt filter för Wikipedia(!) som enligt Apple: Limit access to profanity in Wikipedia. (Jösses!)

  • Curfew. Oklart vad det innebär, men det lÃ¥ter som den typiskt Amerikanska bestraffningsmetoden att under en begränsad tid begränsa användning eller rörelsen hos en person. Ex att ett barn skall vara hemma vid en viss tid. Nu har det alltsÃ¥ kommit till datorernas värld.

En mer udda säkerhetsdetalj i Leopard är kanske det här: Microsoft WHCL-Certified Windows Drivers. Drivare för iSight-kamera, trackpad, keyboard backlighting etc är certifierade för Windows

Slutligen innehåller Leopard flera spännande nyheter som kan sägas vara kopplade till säkerhet, men som inte är specifika säkerhetsfunktioner:

  • DTrace. Suns fantastiska teknik Dtrace för att proba i ett OS. Kallas tydligen även för Instruments i Leopard.

  • Time Machine. En vad det verkar ganska unik typ av backup-program som om inte annat förhoppningsvis gör att mängden data som gÃ¥r förlorad i världen minskar.

Sedan får man se hur det verkligen fungerar. En sista sak värd att notera är dock följande lilla notis:


UNIX® Certification

Mac OS X is now a fully certified UNIX operating system, conforming to both the Single UNIX Specification (SUSv3) and POSIX 1003.1. Deploy Leopard in environments that demand full UNIX conformance and enjoy expanded support for open standards popular in the UNIX community such as the OASIS Open Document Format (ODF) or ECMA’s Office XML.

Jag som tyckte att jag precis läste att analysföretaget Gartner hävdade att UNIX var dött både som OS och som applikationsplattform. Lite märkligt dock att Apple nämner ECMA Office XML som populärt format. Finns det något Open Source-projekt som använder det formatet?

129 USD skall det nya OS:et kosta när det släpps i USA (det går att förbeställa) Detta borde innebära att det hamnar runt 800-900 SEK i Sverige. Shoppar nog inte samma dag det kommer ut, men det verkar finnas mycket spännande under huven så det blir nog Leopard i höst. (Leopard is the new black.)

Är Kryptoblog på IDG.se en bra idé?

October 17th, 2007

Jag har fått en förfrågan om att börja köra Kryptoblog på IDG.se. Jag har ingen aning om vad det egentligen innebär. Men en sak jag funderar på är hur DU som läser Kryptoblog skulle reagera?

Hur skulle din uppfattning om Kryptoblog ändras om den hamnade som en del av IDG.se? Skulle det stärka ditt förtroende, eller göra dig mer tveksam till det jag skriver? Skulle du tycka det var mer eller mindre intressant att läsa Kryptoblog?

Det jag kan säga är att jag inte avser att flytta Kryptoblog om jag inte är 100% säker på att jag fortsatt kan skriva vad jag vill. Även om jag det ibland kanske hade varit bra med en redaktör som stoppade de värsta dumheterna, har många av er läsare (hej Linus!) gjort ett ypperligt jobb att korrigera mig i efterhand (när jag står med byxorna nere.)

Har du som läser Kryptoblog tid och ork att läma en kommentar om hur du skulle se på en sådan här flykt skulle jag uppskatta det mycket.

Tack!

/Joachim – Kryptoblogmaster

SpadFS

October 16th, 2007

Såg precis att IDG har publicerat en av mina gamla artiklar för TechWorld på webben. Artikeln handlar om filsystemet SpadFS till GNU/Linux
SpadFS-illustration
För att citera mig själv:


Den andra november förra året presenterade Mikulas Patocka filsystemet Spad FS genom att posta det till mejllistan Linux kernel. Mikulas Patocka är doktorand vid fakulteten för matematik och fysik vid Charles universitet i Prag. Han forskar på filsystem och Spad FS är plattformen för nya mekanismer och strukturer.

Spad FS är alltså i högsta grad ett experimentellt filsystem, men Mikulas Patocka har valt att göra det tillgängligt för andra, både för att sprida sina idéer och för att få återkoppling på sina forskningsresultat.

Spad FS orsakade en hel del diskussioner, inte minst för att Andrew Morton i stort sett samtidigt presenterade ext 4. En person som tyckte att Spad FS verkade intressant var Linus Torvalds, som efter att ha tittat på det sa: ”It doesn’t look horrible to me.” Linus Torvalds kommentar gällde i första hand källkoden, men han har även sagt att Spad FS innehåller flera designval han ser som intressanta för framtida filsystem.

Läs resten av artikeln på IDGs webbplats.