Grunden av mycket av säkerheten på Internet i dag hänger på tillgången till bra slumptal som används tillsammans med ett några olika kryptografiska algoritmer för att skydda exempelvis skydda DNS-systemet, routing samt säker inloggning på webbplatser och datorer. På grund av förra årets många avlöjnanden om massavlyssning och försök till manipulation av de säkerhetsmekanismer vi tror oss kunna lita på sker i dag en stor omvärdering av vad som går att lita på. Funktioner med dålig transparens och med liten möjlighet att verifiera och funktionaliteten har i dag svårt att få tillit.

För algoritmer som AES, SHA-256 och RSA pågår diskussioner om vad som går att lita på, men då algoritmerna är öppet definierade och en given implementation oftast går att verifiera är dom fortfarande betrodda. Men när det kommer till nyckeln i säkerheten – slumptalen är det sämre ställt. Oftast genereras dessa slumptal och nycklar med en så kallad HSM – en High Security Module (eller Hardware Security Module). Detta är bokstavligt talat svarta lådor med aktiva skalskydd som hindrar någon att öppna dom.

Ett exempel på en HSM – ett PCIe-kort från SafeNet med en svart låda där säkerhetsfunktionerna bor.

Leverantörerna av dessa maskiner lovar att dom fungerar som dom ska och maskinerna oftast validerade enligt säkerhetsstandarder som NIST FIPS 140-2 (ofta nivå fyra) och Common Criteria. Men kan man lita på att det innebär att maskinerna gör vad som utlovas (och bara det)?

Vi vet i dag att det skapas och genereras nycklar som är mycket sämre än vad man kan förvänta sig. Förra året publicerades en undersökning av certifikat med RSA-nycklar som används i ID-kort i Taiwan. Korten har blivit certifierade av NIST i USA, CSE i Kandada sam en godkänd CC-evaluering i BSI i Tyskland. Trots detta kunde ett forskarteam med bland annat Tanja Lange, Nadia Heninger och Daniel J Bernstein visa att nycklarna på korten är dåligt skapade, att det finns gemensamma primtal i flera av certifikaten och att det går att forcera säkerheten. Inte alls bra.

I ett försök att förbättra säkerheten runt nyckelgenerering och inte minst möjligheten att skapa tillit till HSM:er har det startats ett internationellt projekt för att ta fram en öppen HSM-plattform. Projektet heter Cryptech och Secworks är stolta över att vara med i projektet och arbetar aktivt för att utveckla plattformen.

Syftet med projektet är att få fram de komponenter, verktyg och dokumentation som gör det möjligt för att vem som helst själv ska kunna (eller be någon annan dom litar på) att plocka ihop en HSM dom kan verifiera fungerar som förväntat och därmed kunna lita på. Målet är alltså inte en färdig applikation eller en hårdvaruburk. Däremot kommer vi att ta fram referensimplementationer som mer eller mindre direkt går att använda. Och eftersom alla kod och designunderlag är öppna kan vem som helst som vill faktiskt bygga och sälja färdiga HSM:er baserat på Cryptech. (Koden som utvecklas för Cryptech kommer att vara BSD-licensierad och all dokumentation kommer att vara Creative Commons-licensierad.)

Det finns många fundamentala utmaningar att brottas med i projektet – inte minst hur man skapar öppen hårdvara implementerad i FPGA- eller ASIC-teknik där det finns spårbarhet och kontroll genom verktygsflödet. Att få kontroll på sidokanaler i olika former kräver både kompetens och tekniska resurser som projektet inte har i dag. Men det hindrar oss inte ifrån att försöka.

Just nu pågår mycket arbete med att etablera de första hårdvaruplattformarna för att kunna göra verifiering på verklig hårdvara. I dag används utvecklingskort från TerasIC med Alteras Cyclone IV- och Cyclone V-familjer. Just i dag sker exempelvis verifiering subsystemet för hashfunktioner (med SHA-1 och SHA-256) på ett TerasIC C5G-kort:

TerasICs C5G-kort som via USB pratar med ett värdsystem för att testa hashimplementationer.

Samtidigt pågår både ett underökande arbete, diskussioner och början till definition av pudelns kärna – slumptalsgeneratorn. Vilken eller vilka entropikällor ska vi stödja, hur ska insamling av entropi ske, vilken CSPRNG ska vi använda, hur skapar man transparens i en slumptalsgenerator etc? Många frågor med många möjliga svar och följdfrågor blir det.

Under 2014 ska en första prototyp till HSM tas fram. Och för att driva utvecklingen har en liten uppsättning av användningsfall definierats. Bland annat ska man kunna använda Cryptech i RPKI och DNSSEC. Men detta är inte de enda användningsfall som Cryptech ska kunna stödja. Och vi är mycket intresserade av att höra vilka andra behov som finns. Inte minst är detta viktigt för att definiera bra gränssnitt mot lägre lagers säkerhetsfunktioner. Vilka anrop och datastrukturer krävs för att effektivt kunna använda Cryptech är mycket viktigt att få koll på.

Funktionalitet som kommer att finnas i slutet av 2014 är bla RSA (nyckelgenerering, kryptering/dektyptering, signering/verifiering) med minst 4096 bitars nyckel, en fullt fungerande TRNG, en säker nyckellagring samt symmetrisk med minst AES samt några olika moder. Cryptech är dock inte i första hand en kryptoaccelerator som ger hög prestanda, utan det är säkerhet, kontroll och tillit som är det viktiga. För att kunna prata med applikationer kommer det bland annat att finnas PKCS#11-interface. Det är ambitiöst, men genomförbart tror vi.

Har du frågor och tankar om Cryptech så posta dom gärna här eller på twitter. Men ännu bättre är att posta dom till Cryotechs tech-lista. Listan är öppen för alla. Projektet är öppet och transparent. Alla commits som sker in i projektets repo är exempelvis signerade så att det går att spåra vem som gjort en föränding.

Så, detta blev en ganska lång text. Det finns massor mer att skriva men vi kommer att löpande skriva mer om Cryptech och Secworks arbete i projektet så det är inte slut med det här. Men att det är ett otroligt roligt och spännande projekt kan vi iaf avslöja.

Efter många diskussioner har de olika förslagen (drafts) för att få in ett nytt strömkryto i TLS nu kombinerats till ett förslag. draft-mavrogiannopoulos-chacha-tls definierar nu kryptosviter för TLS som anvönder ChaCha med 20 iterationer i kombination med HMAC-SHA1 respektive Poly1305 som MAC-funktionalitet. Förhoppningsvis kan det sammanslagna förslaget enklare accepteras så att vi kan få igenom ett nytt strömkrypto i TLS och underlätta pensioneringen av RC4.

Nu finns det en uppdaterad hårdvaruimplementation av strömkryptot ChaCha från Secworks. Den nya versionen använder fyra parallella QR-moduler istället för en enda modul i den första versionen av implementationen.

I en Altera Cyclone IV GX ökar prestandan från 870 Mbps till 2,6 Gbps och detta med endast 5% mer hårdvaruresurser.

Skälet till detta är att den ARX-konstruktion (Addition, Rotation och XOR) som utgör kärnan i kryptot och finns i QR-modulen implementeras effektivt i FPGA-strukturen. Detta gör att den ökande mängden logik för de tre nya QR-modulerna i stort sett kompenseras av minskad logik för att välja ut operander (MUX-ar) till den enda QE-modulen. Motsvarande resultat såg vi när vi byggde ut hårdvaruimplementationen av den nyckelstyrda hashfunktionen SipHash från en till fyra parallella ARX-enheter. Men för SipHash minskade till och med totala antalet resurser.

Prestandamässigt ökade inte prestandan fyra gånger utan bara drygt tre gånger. Skälen till detta är att klockfrekvensen minskade något men även att det finns några cykler för att initiera och avsluta processningen. Dessa cykler går inte att parallellisera bort och tar allt större del av den totala latenstiden ju mer QR-processningen parallelliseras.

Det skulle gå att utöka till åtta stycken QR-moduler. Men detta skulle skapa direkta beroenden mellan par av QR-moduler och totala logikdjupet skulle fördubblas. Eftersom den längsta logikvägen går genom QR-modulerna innebär en sådan parallellisering att klockfrekvensen närmast skulle halveras. Resulatet skulle troligen bli en marginellt förbättrad prestanda. Samtidigt skulle det maximala klockfrekvensen bli så låg att implementationen skulle bli svår att använda i konstruktioner utan att bli den modul som begränsar klockfrekvensen för hela konstruktionen.

Implementationen av ChaCha har självtestande testbänkar och i kombination med bra revisionshantering (Git i kombination med Github) har det varit lätt och smidigt att utifrån en första fungerande enkel implementation stegvis bygga ut implementationen för att nå bättre prestanda. Detta utan att riskera att den tidigare versionen inte går sönder. I värsta fall får man köra git checkout på en fil man försökt ändra och börja om.

Lagom till jul är första versionen av Secworks öppna hårdvaruimplementation (en soft core) av strömkryptot ChaCha färdigt. Implementerad i en krets från Alteras FPGA-familj Cyclone IV GX krävs 5628 logikelement (LEs) och 3629 register. En stor del av dessa, inte minst registren härör dock från det 32-bitars gränssnitt som implentationen är utrustad med och som gör det möjligt att dubbelbuffra data så att det går att skriva in ny data samtidigt som föregående block av 64 Bytes processas.

Prestandamässigt når implementationen drygt 60 MHz i Cyclone IV GX vilket ger 870 Mbps rå kryptoprestanda. Den här versionen av implementationen innehåller inga parallella quarterrounds. Vi kommer att lägga till versioner med upp till minst 4 quarterrounds vilket bör lyfta prestandan rejält.

Implementationen som är BSD-licensierad finns att klona på github.

Med detta önskar Secworks en god Jul och ett gott nytt år!

Sprang i dag på ett mycket intressant ramverk för att bygga disassembleringsprogram, dvs program som på olika sätt plockar i sär och analyserar binärfiler fär olika arkitekturer.

Ramverket heter Captstone och släpptes precis i 1.0-version. Capstone kan analysera och disassemblera binärfiler för ARM, ARM64 Mips och x86. Här finns en mer detaljerad lista över varianter på arkitekturer som stödjs. Capstone är alltså inte en debugger eller interaktiv disassemblator som IDA eller OllyDbg.

Däremot kan man använda Capstone för att bygga program som analyserar binärer. Program som kan vara interaktiva. Capstone används bland annat i verktyg för att analysera skadlig kod (eng: malware) exempelvis pyew och radare. Andra användningsområden är att bygga verktyg för att underlätta optimering av kod genom att ta fram användning av olika instruktioner, register m.m. Capstone är skrivet i C men kommer med wrappers för Python (Python2), Ruby, OCaml, C#, Java och Go.

Capstone är BSD-licensierat och är enkelt att installera och komma igång med. Jag testade att klona Capstone-repot samt bygga och installera bibliotek och Pythonwrappers. Följande exempel (från Capstone) visar ett enkelt program som tar in en binär och disassemblerar:

Testprogram med Capstone

Testkörning Capstone

Capstone är inte det enda bilioteket av den här sorten. När jag kollade runt hittade jag bland annat udis86. Men Capstones förmåga att analysera binärer för många arkitekturer och dess (i mitt tycke) rena API och wrappers till högnivåspråk gör Capstone för mig högintressant. Riktigt kul och som det verkar riktigt bra.

Just nu pågår det ett antal diskussioner på olika maillistor och forum om slumptalsgeneratorer. Bakgrunden är det senaste årets alla avslöjanden som skapat frågor om vilka säkerhetsmekanismer vi egentligen kan lita på. Att mekanismerna fungerar som vi tror och ger den säkerhet vi förväntar oss.

Slumptalsgeneratorer är på många sätt basen för all säkerhet. Slumptals används som salt i lösenordsdatabaser, som start för sessionsnummer, ID i databaser (för att undvika DoS-attacker, se ex denna postning om SipHash). De nycklar vi använder för symmetrisk kryptering samt äkthetskoder (MAC) måste vara slumptal av bra kvalitet så att ingen kan gissa dom. Och för att vi ens ska kunna göra ett bra Diffie-Hellman-nyckelutbyte måste vi också ha tillgång till bra slumptal.

Samtidigt är bra, riktiga slumptalsgeneratorer svåra att konstruera och kontrollera. Dessa generatorer kräver tillgång fysiska slumpmässiga processer från vilka entropi samlas in. Dessa processer ska ge mycket entropi, vara billiga och enkla att integrera i digitala system. Och inte vara känsliga för extern manipulation. Ingen lätt kombination. Lägg dessutom till att vi vill att hela kedjan från den fysiska processen till genererade slumptal ska vara transparent och kontrollerbar från en godkänd undersökare blir det hela än mer komplicerat.

Den insamlade entropin används sedan för att initiera en algoritm, en kryptografiskt säker pseudoslumptalsgenerator (Cryptogtphically Safe Pseudo Number Random Generator – CSPRNG). Det är denna algoritm som sedan genererar en mängd med slumptal varefter generatorn initieras om med annan insamlad entropi.

Processortillverkarna Via och Intel har integrerat slumptalsgeneratorer i sina chip. I Vias fall finns det vissa möjligheter att titta på rådatan som samlas in från den integrerade entropikällan. Men i Intels fall finns ingen motsvarande möjlighet. Det går att testa att den CSPRNG som används fungerar enligt specifikation, men det går inte att se varifrån indata – entropin egentligen kommer ifrån. (Jag har tidigare skrivit om Intels slumptalsgenerator Bull Mountain (artikel ett, artikel två) och att jag ser den som ett stort steg framåt för säkerheten. Det tycker jag till viss del fortfarande. Men då i första hand som entropikälla, inte som ersättare för hela slumptalsgeneratorn.)

Avsaknaden av transparens gör att flera nu aktivt letar efter alternativ samt nya sätt att förhålla sig till dessa generatorer. Utvecklarna av operativsystemet FreeBSD har gått ut och sagt att dom inte kommer att använda generatorerna direkt utan använda dom som entropikällor där dom matar CSPRNG:n Yarrow. Äveb bland Linuxytvecklare för stora diskussioner om huruvida RdRand (Intels instruktion för att läsa från slumptalsgeneratorn) ska användas som komplett generator, som entropikälla eller inte alls.

Ett problem med RdRand som entropikälla är att den har mycket stor kapacitet (den kan lätt generera Gbps) och om ytterligare en entropikälla används, men denna källa har mycket lägre kapacitet kommer entropin från RdRand att dominera.

Många kommer med olika förslag att bygga entropikällor med zenerdioder, motkopplade inverterare (på motsvarande sätt som Intel säger att Bull Mountain fungerar). Nackdelen med dessa är att dom kräver extern elektronik samt A/D-omvandlare för att få in entropin i processorn. Att entropikällan är extern kräver också att den är skyddad så den inte går at manipulera.

En intressant grupp av entropikällor är de som försöker använda skillnader i exekveringstid av instruktioner eller andra mätbara effekter från insidan av processorn. Detta tar bort behovet ev externa anslutningar och ger en mer digital miljö som är enklare att observera och kontrollera. Jag har tidigare skrivit om flera av dessa generatorer. Det som är nytt är att det faktiskt ser ut som att flera av dessa generatorer faktiskt ger bra entropi på enkla processorer och för inbyggda system.

För FPGA-baserade system har jag tidigare haft svårt att hitta bra lösningar. Men det finns faktiskt flera publicerade artiklar med exempel på entropikällor och slumptalsgeneratorer i FPGA:er. En av de mer intressanta är ett exjobb som utförts i år på Business Security i Lund. Emma Hilmersson har undersökt flera olika lösningar och skrivit en bra rapport (PDF).

Att testa sin slumptsgenerator är svårt. Väsentligen får man generera en stor mängd värden (En GByte) och sedan släppa lös exempelvis verktyget Dieharder som tar många timmar på sig att analysera värdena på många olika sätt. Sedan får man fundera igenom vad rapporten säger om generatorn.

Att göra dessa tester under drift är svårt. Däremot kan det vara god idé att ha någon slags grundläggande hälsokontroll. Om din generator genererar en miljon nollor på raken, om medelvärdet ligger långt från väntevärdet eller om variansen är mycket mindre än värderymden bör du ta en titt på hälsan hos din generator. Men även för dessa enkla tester krävs rätt mycket värden och fångar inte sekvenser av värden. Därför bör man både under utveckling och under produktens/tjänstens livslängd periodiskt undersöka att generatorn fortfarande fungerar.

En märklig nyhet mitt i alla dessa diskussioner är att NIST har släppt en slumptalstjänst. NISR Randomness Beacon genererar en gång per minut en blobba på 512 bitar med slumptal. Blobban är signerad så att det går att se att den kommer från NIST och blobborna är kopplade till varandra i en hashkedja.

Att döma av beskrivningen är allt kanonsäkert och väl genomtänkt. Men frågan alla ställer sig är varför någon nu skulle använda denna tjänst? Vill du göra din produkt/tjänst och säkerhet beroende av extern entropi över nätet. Entropin är uppenbarligen öppet känd. Och det NIST inte insett är hur mycket organisationen tappat i förtroende. Efter årets stora bråk om SHA-3 och alla avslöjanden är det få som vågar lita på att blobborna faktiskt är genererade på det sätt som NIST säger. Tillit och kontroll. Och just nu vill många få mycket mer kontroll. Om du nu vill använda en tjänst för att få slumptal finns random.org. Nej, jag vet inte riktigt vad man ska med den till heller.

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.