Secworks

Nu finns presentationen från dragningen SSL für alle (pdf) på OWASP-Göteborgs webbplats. Ett stort tack till Omegapoint och speciellt Mattias Jidhage för att sponsra och organisera dragningen. Ett stort även till min medtalare Peter Magnusson som gjorde ett fantastiskt jobb att bena ut alla attacker. Och tack till alla som kom och lyssnade.

Den sista tiden har det varit mycket diskussioner om olika typer av entropikällor för att mata slumptalsgeneratorer. Jag har tidigare tittar på och skrivit om Haveged och DakaRand.

Haveged är en entropikälla som försöker få exekveringstiden av instruktioner i en processor att variera så mycket som möjligt. Exekveringstiden mäts sedan och utgör basen i den genererade entropin.

För några månader sedan dök det upp en ny källa kallad Jytter. Jytter försöker till skillnad från Haveged inte provocera fram varians. Istället försöker den detektera att varians sker och samla in den. I mina mätninga så här långt ger Jytter entropi med bra kvalitet. Men kapaciteten i Jytter är mycket lägre än för Haveged. Jag återkommer förhoppningsvis nästa vecka med mer resultat.

Och nu finns det ännu en entropikälla – CPU Jitter Random Number Generator skapad av Stephan Mueller. Denna källa baseras helt på timing mellan instruktioner. Stephan har gjort massor med körningar på olika processorer (stor PDF) och det ser ut som att man inte behöver provocera fram varians för att få bra entropi.

DakaRand slutligen bygger likt jytter och Stephans lösning på timers, men då flera stycken timers direkt i program.

Forskningsresultat från Stanford om möjligheten att identifiera enskilda mobiler med hjälp av enhetens inbyggda sensorer har fått en del uppmärksamhet i veckan.

Det forskarna har undersökt och kunnat visa är att sensorerna i en mobil, accelerometrar, mikrofoner (och man skulle även tänka sig ljussensorer etc) inte är helt perfekta och ger samma värden i samma situation. En mobil som ligger helt plant på ett borde ge likadant, fixt värde som en annan mobil. Men pga varians vid tillverkning ger mobilernas sensorer lite olika värden. Genom att kombinera variansen från de olika sensorerna i en mobil skapas ett fingeravtryck för den specifika enheten.

Att en sensor inte är perfekt är inte en överraskning och därför anges ofta sensorer med viss tolerans av dess tillverkare. Normalt sett bör man ignorera värden under toleransen, men kan som forskarna visat istället användas för att identifiera en enhet.

Forskarna har använt två typer av sensorer – accelerometer samt mikrofon. Mobiler som testats har lagts på en plan yta och sedan mäter man hur mycket accelerometerns uppfattning av vinkeln varierar mot normalen:

Test av accelerometrar.

För mikrofonen sker närmast ett självtest. Mobilen fås att spela upp ett ljud som sveper över ett frekvensområde och samtidigt samla in ljudet med mobilen skapas en bild av mikrofonens känslighet vid olika frekvenser:

Frekvensgången för mikrofonen i en specifik mobil.

En reflektion är att det naturligtvis kan vara så att varians i mobilens högtalare får den att spela upp ljuden lite olika. Det borde i det här testet framstå som varianser i mikrofonen. Skulle man sedan försöka matcha mikrofonen genom att spela upp ljudet på annat sätt (med en annan högtalare) skulle antagligen mikrofonens frekvensgång se lite annorlunda ut.

Vill du själv testa din mobil har forskarna satt upp en testtjänst.

Den här nyheten fick mig att fundera på biometri och sensorer för att identifiera användaren. Skulle det g att använda exempelvis accelerometern för att identifera användaren när den rör på sig med mobilen i fickan? Lite Citeseer-sökning och Googling visar att japp, det ser ut att gå ganska hyggligt. Jag hittade några artiklar som presenterar hur så kallad gait base biometry kan utföras med en mobil. Vi tittar närmare på en av dessa.

Artikeln Cell Phone-Based Biometric Identification (pdf) beskriver hur man testat att samla in värden från accelerometern från användare som rör sig i vardagen, skapat ett fingeravtryck för användaren. Sedan har man samlat in mätvärden under 10 sekunder och utifrån det försökt matcha/identifiera en användare mot den skapade databasen av fingeravrtyck. I artikeln når man som bäst drygt 90% träffsäkerhet om användaren joggar. I medel med olika rörelser nås ungefär 70% träffsäkerhet. Forskarna själva ser att dom skulle nå mycket bättre resultat om man mätte under längre tid än 10 sekunder.

Den här tekniken skulle kunna användas för att låta mobilen själv identifiera sin användare och därmed försvåra för någon annan att använda mobilen (ex en tjuv). Samtidigt skulle det naturligtvis kunna användas för att avanonymisera och spåra användare utan att användaren är medveten om det. Att det går tycker jag är rätt fräckt. Och lite skrämmande.

En sista reflektion är att det Stanfordforskarna kunnat visa är att sensorerna är så kallade Physically Unclonable Functions (PUF), dvs fysiska saker som inte går att göra exakta kopior av. Dessa PUF:ar används för att stoppa piratkopiering. Ofta försöker man bygga PUF:ar med digital hårdvara, men att en enkel sensor som en mikrofon är intressant. Tycker jag.

Nu är generatorn för testvektorer till strömkryptot ChaCha (se tidigare bloggpostning) i stort sett färdig och genererar vektorer för åtta olika testfall. Första versionen av I-Dn: är klar och inkluderar testvektorerna samt information om hur den slumpmässiga nyckeln samt IV har genererats.

Kod och dokumentation finns i projektet chacha_testvectors på Github. Kommentarer, synpunkter och patchar högeligen välkomna.

(Uppdaterat med länkar till IP-core och draft.)

Den senaste tiden har jag lagt en del tid på att utveckla en hårdvaruimplementation (en så kallad IP-core) av strömkryptot ChaCha. Det finns två skäl till varför jag gör detta. Jag ser att det finns direkta intressen och behov hos några företag av ett strömkrypto med låg fördröjning och mycket hög prestanda. Det andra skälet är för att kunna besvara en fråga som kommit upp i samband med utvecklingen av ett standardförslag (draft-josefsson-salsa20-tls) för att få in strömkryptot Salsa20 som alternativ till strömkryptot RC4. Frågan som kommit upp är huruvida ChaCha är mycket bättre att implementera i hårdvara än Salsa20.

Salsa20s quarterround-funktion. Notera de fyra uppsättningarna med addition, rotation och XOR, så kallad ARX-operation. (Behövde en figur för att lätta upp den här massiva texten.)

ChaCha är en variant av Salsa20. Förändringarna i ChaCha ska enligt dess skapare, Daniel J. Bernstein dels ge förbättrad säkerhet och samtidigt ge något bättre prestanda. Tittar man på prestandaresultaten i eBACS finns det visst fog för att säga att ChaCha ger en aning bättre prestanda än Salsa20. I vilken ordning de olika 16 olika 32-bitars orden som utgör interntillstånden i algoritmerna används vid tillståndsuppdatering ska i ChaCha underlätta parallell bearbetning och då inte minst på vektor eller SIMD-arkitekturer (exempelvis en grafikprocessor). Men när det kommer till en direkt hårdvaruimplementation finns det få (inga) egentliga implementationer. Däremot finns det många gissningar och en hel del uttalanden som saknar stöd. Det är detta stöd jag försöker skapa. Men det visade sig vara lite besvärligare än jag trodde.

Ett problem som alltid uppkommer när man implementerar en kryptografisk funktion är att veta att algoritmen räknar korrekt. Och eftersom algoritmerna är som de är (med lavineffekter) ger minsta fel stora skillnader i funktionalitet. Vet man vad förväntat resultat är för givet indata blir det mycket lättare att se om implementationen fungerar eller ej (Ofta kallat Known Answer Test – KAT). Därför är testvektorer något som alltid behövs, men som tyvärr på tok för ofta saknas. Jag och Simon Josefsson försökte lösa behovet av testvektorer för RC4 genom att skriva RFC 6229 Test Vectors for the Stream Cipher RC4.

För Sals20 finns det testvektorer (om än i ett rätt oläsbart format). För ChaCha däremot finns det inga publicerade testvektorer. Att det behövs för ChaCha har jag sett under arbetet då jag letat efter testvektorer eller referensmodell och hittat tre olika implemenationer av ChaCha som var och en ger olika resultat för samma indata.

Det finns en referensimplementation av ChaCha, men kallar sig själv kodmässigt för salsa20 och innehåller ingen funktionalitet för att direkt testköra och få ut resultat. Koden är istället byggd för att köras som en del av eSTREAMs ramverk. (Salsa20 är en av algoritmerna i eSTREAM-portföljen.)

Så vad göra? Vad jag gjort är att försöka ta tag i saken. Genom att utgå ifrån den referensmodell som finns, få den att kunna bygga helt fristående, städa upp och strippa ner algoritmen till dess kärna och sedan bygga på funktionalitet för att generera testvektorer för olika testfall håller jag på att skapa en generator som samtidigt förhoppningsvis är en enkel och begriplig referensmodell. Under arbetet har jag sett till att min modell inte avviker funktionellt från Bernsteins modell.

Sedan har jag börjat skriva på en Internet Draft (I-D) som förhoppningsvis kan leda fram till en informations-RFC med testvektorer för ChaCha. Eftersom det finns andra I-Ds som specificerar att ChaCha ska användas borde behovet av en sådan RFC finnas.

Min kod och första utkast till I-D finns i projektet chacha_testvectors på Github.

Vad gäller skillnaden mellan Salsa20 och ChaCha hårdvarumässigt är min bedömning efter att ha arbetat med algoritmerna att det på roundsnivå finns skäl att tro att ChaCha kan ge högre prestanda. Värsta logikdjupet (vilket styr hur fort en digital konstruktion kan klockas) genom quarterround-steget är även lägre i ChaCha vilket bör ge bättre prestanda. Däremot är Salsa20:s quarterround en renare ARX-konstruktion och ger därför fler möjligheter till att dela upp i flera klockcykler (pipelina på svengelska) vilket borde göra att Salsa20 ändå kan nå högre klockfrekvens och totalt sett kanske bättre prestanda. Det skulle antagligen gå att göra en mer kompakt version av Salsa20 än av ChaCha. Men huruvida detta stämmer återkommer jag till när jag faktiskt har fakta på bordet.

Min IP-core utvecklas även den på Github i projektet swchacha.

För ett par veckor sedan bloggade jag om krypto och säkerhet i en övervakad värld. En av de saker jag skrev om är standardiserade kurvor (för Elliptic Curve-baserade algoritmer) och behovet av öppet definierade kurvor i exempelvis TLS.

En som inte bara pratar om detta är Simon Josefsson som börjat skriva på draft-josefsson-tls-curve25519, en Internet Draft (I-D) till IETF för att få in Curve25519 som kurva i Diffe-Hellman-baserat nyckelutbyte i TLS. Bra initiativ!