Archive for the ‘Om Kryptoblog’ category

Paneldebatt om molnet och IT-säkerheten

January 19th, 2010

I morgon onsdag skall jag vara med i en debattpanel på ICT-mässan i Göteborg om hur molnet påverkar IT-säkerheten. I debatten deltar även Predrag Mitrovic (CIO, MyNethouse), Per Josefsson (Information Security Manager, Telia Sonera), Johan Broman (Teknisk expert, Red Hat), Kaja Narum (Nordisk chef, RSA) och Rosella Carbone (Senior Account Manager, Salesforce).

Jag har aldrig gjort något liknande förut och är just nu lite nervös. Men det skall bli spännande och intressant att träffa de andra och höra vad de har att säga samt vad publiken har för frågor.

  • Share/Bookmark
Print

Mer om GSM-attacken

December 30th, 2009

Det verkar aldrig ta slut på uppmärksamheten kring Karsten Nohls attack på A5/1 (se tidigare bloggpostning ett och bloggpostning två). I dag har Sveriges Radio och Ekot plockat upp tråden och jösses vilket reportage det blev.

Ekots bild till artikeln.

Egentligen är Per Eurenius reportage (webbradio) från 26C3 i Berlin inte så illa, utan det är snarare påannonseringen och SRs nyhetstext som är tokfel:

Hemlig gsm-kod hackad av forskare

En tysk forskare har lyckats avslöja den kod som ska skydda mobiltrafiken i världens största telefonsystem, gsm.

Nej, SR, det är ingen kod som avslöjats, och det är inte hemligt.

Även Cryptome har uppdaterat sitt material In support of Karsten Nohl’s cracking of GSM A5 och den här sidan hos Cryptome är nog den mest kompletta samlingen av information om A5-krypton, säkerhet (eller avsaknad därav) i GSM, GPRS och UMTS.

För den som vill ha Karstens regnbågstabeller finns det nu torrentfiler.

  • Share/Bookmark
Print

Återanvänd text om FPGAer och säkerhet

September 11th, 2009

Myndigheten för samhällsskydd och beredskap (MSB) bildades första januari 2009 och tog då över verksamhet från Räddningsverket, Krisberedskapsmyndigheten samt Styrelsen för psykologiskt försvar. I brist på annat att göra när man ligger med en eventuell svininfluensa slösurfade jag på MSBs webbplats. En sak jag gjorde var att söka på ordet kryptering och fick då upp KBMs gamla rapportserie Nyhetsrapport – omvärldsbevakning ur ett krypteringsperspektiv.

Enligt informationsrutan i rapporterna är:

Nyhetsrapporten är utgiven av Combitech AB på uppdrag av Försvarets materielverk (FMV) och Krisberedskapsmyndigheten (KBM). Nyhetsrapporten kommer ut ungefär tre gånger per år. Tidigare utgåvor kan erhållas genom att kontakta redaktören. Innehållet fokuserar på krypto, men kan även innehålla andra säkerhetsrelaterade notiser. Nivån är övergripande för att ”alla” och inte bara branschfolk skall ha glädje av den.

Intressant nog hävdar webbplatsen ovan att: Nyhetsrapporterna är utgivna av AerotechTelub, men det är nog mest en detaljfråga. Jag tycker att rapporterna är väl värda att läsa med såväl nyheter som förklaringar av kryptografiska funktioner och begrepp. Det är synd att nyhetsrapporten snarare verkar komma ut en gång per år än tre gånger per år som informationsrutan vill göra gällande. (Kommer nyhetsrapporten att komma ut under MSBs regi också, någon som vet?)

En sak i nyhetsrapporten från april 2008 gjorde mig tyvärr lite fundersam. Rapporten innehåller ett stycke om NSA och SRAM-baserade FPGAer för kryptosystem som tar upp det arbete NSA och Xilinx genomfört – ett arbete jag bloggade om i slutet av augusti 2007 med rubriken… NSA och SRAM-baserade FPGAer för kryptosystem

I nyhetsrapportens text läser jag bland annat:

National Security Agency (NSA) och FPGA-tillverkaren Xilinx [1, 3] har genomfört ett intressant projekt vad gäller säkerhetskonstruktioner med hjälp av Field-programmable gate array (FPGA). Vad NSA och Xilinx har gjort är att både analysera säkerheten i SRAM-baserade FPGA:er samt utvecklat metoder och verktyg för att implementera system som möter NSAs säkerhetsklass Fail Safe Design Assurance (FSDA).
...
Att implementera kompletta säkerhetssystem i en FPGA:er har tidigare undvikits av rädsla för att det inte skall gå att upprätthålla röd/svart-separation [2] inne i FPGA:n, med risk för informationsläckage och säkerhetsproblem.
...
Exempel på vad NSA vill kunna implementera i en FPGA är redundanta kryptoenheter, röd/svart-separering internt på chippet och chip med funktioner som arbetar med olika säkerhetsklasser.

Hmmm…. Jag tycker att jag känner igen den där texten. Min egen bloggpostning innehåller texten:

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

Kryptoblog är en blogg – en öppen text. Därmed är det fritt att länka och referera till vad jag skriver, och ingen blir gladare än jag om det jag skriver används för att sprida information om krypto i sverige (förhoppningsvis inte som driftkuku och exempel på tokfrans). Men om ni lånar min text får ni helst se till att tala om att ni lånat den på Kryptoblog. Tack!.

  • Share/Bookmark
Print

En ny kryptohöst

August 31st, 2009

Aloha!

Japp, Kryptoblog lever faktiskt.
Efter en lång, hård och slitsam vår som tyvärr gjorde mig oförmögen att blogga på flera månader börjar det ljusna, hösten till trots. Och det finns faktiskt hur mycket spännande krypto- och IT-säkerhetsprylar att skriva om som helst. Tack alla som skickat tips, kommentarer, uppmaningar och uppskattningar. Dom har värmt, även om jag inte hunnit svara eller posta.

Bloggen kommer den närmaste tiden att förändras utseende- och funktionsmässigt, skrik om du ser något fel som ser märkligt ut. Förhoppningsvis kommer det inte att vara som normalt om ett tag, utan mycket bättre.

Nu kör vi! (lite långsamt ;-)

  • Share/Bookmark
Print

RC4 i programspråket Lua

January 30th, 2009

Tyvärr har jag just nu väldigt lite tid, lust och ork för bloggen. Har dessutom legat sjuk i några dagar.

Det enda jag orkat med är att leka lite med programspråket Lua. Och vad kan vara bättre som kodexempel när man prövar ett nytt språk är strömkryptor RC4?

Så nu finns det en väldigt enkel och ful implementation av RC4 i Lua. Bara att tanka ner från sidan med filer för nedladdning för den som är nyfiken och vill se Lua-fulkod.

Eftersom jag kodar en hel del Python kan jag kanske våga mig på några korta jämförelser mellan Lua och Python:

  • Lua är litet och enkelt. Det går snabbt att greppa grunderna i språket. Ungefär som Python.
  • Att exekvera Lua-program verkar gå fort. Bra prestanda helt enkelt.
  • Kompilering och installation av Lua gick väldigt smidigt. Inga varningar och bra tester för att kontrollera installationen.
  • Debugutskrifter från VM:en när den stöter på fel är inte speciellt tydliga. Python kan dränka dig i kärlek och utskrifter, men det brukar alltid gå att enkelt se var, vad och varför det är fel. Lua ger ibland det något kortfattade “?” som sammanfattning.
  • Lua har inte alls samma mängd med bibliotek med i distributionen som Python. Och de som finns är inte lika välmatade och inte minst lika väldokumenterade som Pythons standardbibliotek.
  • Lua räknar index från ett inte noll. Dock kan man räkna från noll, men tydligen bara ibland. Har man vant sig att allt börjar från noll (typ C, Verilog, Python etc) och dessutom algoritmer är byggda utifrån indexeringar från noll till XYZ blir det lite trixigt att få till det.

(Gissar att jag nu kommer att få massor med ilskna kommentater om Lua…)

  • Share/Bookmark
Print

Implementation av Keccak i FPGA-teknologi

December 17th, 2008

Jag har precis lagt upp en artikel kallad Implementation of the Keccak Hash Function in FPGA Devicessidan med artiklar och dokument.

Artikeln beskriver en del försök jag gjort med att implementera en av SHA-3-kandidaterna, Keccak i olika FPGA-kretsar. Som utgångspunkt har jag använt de referensimplementationer i VHDL som skaparna av Keccak har tagit fram.

Att döma av resultatet verkar Keccak vara en hashfunktion som lämpar sig väl att implementera i FPGA:er. Jag gillar att den går att skala så mycket som den gör. Den minimala low_area_copro-implementationen är verkligen mycket liten ocg ger trots det bra prestanda.

Jag hade dock en del strul med referensimplementationerna vilket till största delen beror på hur VHDL-koden är skriven. Om Keccak skulle bli vald till SHA-3 kommer det att behövas en hel del uppstädning för att få koden till att bli en riktigt bra referensimplementation.

Notera att jag inte i det här läget tar ställning till säkerheten hos Keccak, utan detta är enbart ett försök att utvärdera hur effektivt det går att implementera Keccak i FPGA:er.

Jag tar mycket gärna emot kommentarer och tips.

  • Share/Bookmark
Print

Uppdaterad version av snow.py

November 3rd, 2008

Jag har gjort en liten uppdatering av min Pythonimplementation av strömkryptot Snow. Det jag har ändrat är två saker:

  1. Utökat test/exempelkoden med samtliga testvektorer i specifikationen för Snow 2.0

  2. Fixat en bugg i initieringen av kryptot relaterat till initialvektorn (IV)

Helt kort kan man säga att jag insåg att jag varit extremt slarvig och inte testat ordentligt med IV skild från noll. I initieringen av 128-bit nyckel med IV skild från noll genererade min version inte korrekt värden då jag missat IV-ord två (i mängden IV[0..3]). Den buggen är nu fixad.

Den nya versionen av kryptoimplementationen finns på samma plats som förut, men har fått nytt versionsnummer och uppdaterat releasedatum. Naturligtvis är även signatur och filstorlek uppdaterade.

  • Share/Bookmark
Print

Strömkryptot Snow i Python

October 30th, 2008

Min nya hobby att implementera krypton i programspråket Python har den senaste veckan gjort att jag pillat med kryptot Snow.

Snow är ett strömkrypto av Thomas Johansson och Patrik Ekdahl vid LTH. Den version av Snow jag implementerat är Snow 2.0 som kom 2002. Snow 2.0 var en av kandidaterna till NESSIE-projektet och har även använts som jämförelse med kandidater i eSTREAM.

Det finns en nyare version av Snow kallad Snow 3G. Snow 3G är det krypto som används som bas i algoritmerna EUA2 och EIA2 för att säkra kommunikationen i 3G. Jag har ännu inte lagt in stöd för Snow 3G. En sådan förändring skulle dock vara relativt enkel – det som krävs är väsentligen att lägga till ett extra register i FSM:en.

Snow arbetar på 32-bitars ord och kryptot består i grunden av ett skiftregister (en LFSR-kedja) med 16 steg samt en tillståndsmaskin (FSM) med två 32 tillståndsregister – R1 och R2.

Uppdateringen av LFSR-kedjan sker genom återmatning av tidigare värden som mixas samman genom två multiplikationer, vilka är implementerade med tabeller. Uppdateringen av R2-registret i FSM:en sker genom en S-box (baserad på S-boxen i AES) där indata är värdet i R1. Totalt sett finns det sex stycken tabeller i den här implementationen av Snow.

Min implementation av Python är en fristående klass med metod load_key() för att ladda nyckel och IV, samt en metod gen_keyword() för att generera nästa nyckelströmsord. Klassen stödjer både 128- och 256-bitars nyckel.

LFSR-kedjan och FSM:en är sammankopplade på ett relativt intrikat sätt och att få ordning på ordningen i uppdateringen i ett sekventiellt program visade sig vara lite klurigt. Men genom att dumpa alla interna tillstånd gick det att få ordning på sekvenserna. Min implementation av Snow inkluderar därför en metod för att dumpa interntillståndet. När ett objekt av Snow skapas går det även att ange hur pratig (verbose) den skall vara när den utför en metod.

Ett litet exempel (hämtat från exempelkoden):

my_snow = Snow(False) my_key = [0×00000000, 0×00000000, 0×00000000, 0×80000000] my_iv = [0×00000000, 0×00000000, 0×00000000, 0×00000000] my_snow.load_key(my_key, my_iv) my_snow.gen_keyword()

Detta ger (med lite utskrifter och en loop):


key:
[0, 0, 0, 2147483648L]
iv:
[0, 0, 0, 0]
running key 0: 8d590ae9
running key 1: a74a7d05
running key 2: 6dc9ca74
running key 3: b72d1a45
running key 4: 99b0a083
running key 5: fb45d13f
running key 6: cf9411bd
running key 7: 9a503783
running key 8: a98265ae
running key 9: bf2dc77f
running key 10: f2eb41e4
running key 11: aa896508
running key 12: 19d8ab8f
running key 13: 2eb8077f
running key 14: 78f8c1f1
running key 15: 9d4c5ce2

Rent och snyggt gränssnitt om jag får säga det själv, HW-nisse som jag är (så vad vet jag?).

Jag har testkört på min laptop med 2GHz Core 2 Duo-processor. Generering av 10.000.000 värden tar 135 sekunder, vilket ger ungefär 295 kByte/s. Inte kanonsnabbt, men vill man ha en ren Pythonimplementation av en applikation där det finns ett behov av att skydda data med hjälp av ett bra krypto kanske den här implementationen kan vara användbar.

Min implementation av Snow finns på sidan för nedladdning. Det finns ett par korta exempel i main()funktionen med testvektorer för 128 och 256-bit nycklar hämtade från specifikationen för Snow 2.0.

Koden är BSD-licensierad och jag hoppas att den kommer till nytta. Mycket nöje!

  • Share/Bookmark
Print

rule30.py nu på nedladdningssidan

October 14th, 2008

Jag fick en fråga om jag kunde tänka mig att skicka över den Pythonkod för Stephen Wolframs cellautomat med uppdatering enligt regel 30 jag skrev om för någon dag sedan.

Detta fick mig att kasta ett getöga till på min fulkod. Jag insåg snabbt att koden behövde städas upp, och i samband med det byggde jag om den till att bli objektorienterad.

Koden innehåller en klass CellularAutomata() som tar en godtyckligt lång array med ettor och nollor som representerar initialtillståndet i cellerna i den endimensionella cellautomat arrayen skapar. Klassen tar även array med åtta ettor eller nollor som representerar uppdateringsreglerna för cellerna. I mainfunktionen skapas som ett exempel en liten automat för regel 30 genom instansiering av klassen.

För den som vill testa finns koden nu på nedladdningssidan här på Kryptoblog.

Kommentarer, tips och råd är högst välkomna.

  • Share/Bookmark
Print

MOS6502 – En Pythonbaserad emulator

August 29th, 2008

Jag har precis lagt upp en sida med mitt sommarhack MOS6502. MOS6502 är en enkel, objektorienterad emulator av den gamla processorn MOS 6502 skriven i Python.

MOS 6502

Processormodelln inkluderar i dag alla API-synliga register, flaggor och pekare. Dock finns det ingen egentlig funktionalitet för stack och interrupt. Vidare är inte de mer ortodoxa instruktionspekar, och adressberäkningarna i MOS 6502 med.

Däremot finns det stöd för att räkna cykler och instruktioner samt stega processorn en instruktion i taget. Vidare kan processorn dumpa valfri del av sitt minne. Tanken är att detta skall underlätta profilering och debuggning av assemblerprogram.

MOS6502 klarar i dagsläget av att exekvera en delmängd av alla instruktioner, och av dessa inte alla adesseringsmoder. Dock klarar den i alla fall av att köra en implementation av PRNG-delen av strömkryptot RC4:

js@sotis:>time ./rc4_MOS6502.py
Key byte 0: 2
Key byte 100000: 34
Key byte 200000: 27
Key byte 300000: ba
Key byte 400000: 56
Key byte 500000: ac
Key byte 600000: b
Key byte 700000: 9c
Key byte 800000: 6b
Key byte 900000: 20
Cycles executed: 80000000
i_ptr = 40
j_ptr = 81
acc_reg = 8a
x_reg = 8a
y_reg = 8e
carry = 0
95.658u 0.103s 1:35.97 99.7%0+0k 0+16io 0pf+0w

Körningen ovan är från ett exempelprogram som kör PRNG-delen av RC4 en miljon gånger. Assemblerkoden (som INTE är optimerad) tar 80 cykler per varv. Som synes tar körningen nästan 100 sekunder på min MacBook. Dvs jag får nästan 1 MHz(!) i klockfrekvens och drygt 10 kByte/s i kryptoprestanda. Inte snabbt, men samtidigt inte illa av en emulerad processor som körs i en emulerad miljö (Python VM).

RC4-exemplet finns med i den release som finns att tanka ner på emulatorns sida. Jag tar väldigt gärna emot kommentarer, buggrapporter, patchar och tips för att utveckla emulatorn vidare.

  • Share/Bookmark
Print