Kategoriarkiv: Okategoriserade

Capstone – ett ramverk för disassemblering

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
Testprogram med Capstone
Testkörning 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.

Publika entropikällor och behovet av av bra slumptalsgeneratorer

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.

NIST visar hur Randomness Beacon fungerar.

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.

processorbaserade entropikällor

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.

Entropi från Haveged.

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.

SSL für alle

På kvällen den 28:e november kommer jag och säkerhetsexperten Peter Magnusson från Omegapoint att prata om SSL. Dragningen är arrangerad av OWASP-Göteborg och öppet för OWASP-medlemmar, bara att anmäla sig. Dragningen startar och sker i Omegapoints lokaler. Jag och Peter kommer bland annat att prata om:

  • Vad SSL är, hur protokollet ser ut och vad det används till.
  • Attacker och svagheter i SSL/TLS. CRIME, BEAST bland annat.
  • Kryptoalgoritmer och vad man kan lita på efter Snowdens avslöjanden
  • Hur SSL/TLS används i praktiken. Vanliga fel och brister.
  • Vad man ska tänk på när man bygger in stöd för SSL/TLS i sina applikationer

Välkomna!

Identifiera mobiler och användare med mobilen sensorer

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.
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ång för mikrofon i mobil.
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.

Nätbedrägerier och ersättning från banken

Linus Larsson har skrivit en mycket bra artikel om nätbedrägerier och vilka krav banker ställer på dig som konsument för att ersätta uppkommen förlust. I de fall som refereras har ARN dömt till bankens förmån och konsumenten fått stå för förlusten. I korthet:

  • Betrakta säkerhetsdosor som värdehandling på samma sätt som ett kort. Du behöver därför se till att förvara dosan på ett säkert sätt. Förvara inte PIN-kod till dosan tillsammans med dosan. Och om dosan försvinner ska du direkt anmäla det till banken så att dosan kan spärras.
  • Kontouppgifter, PIN-koder etc bör inte förvaras öppet på din mobil. Och se till att ha ett lås på mobilen.
  • Var ytterst försiktigt med att ge någon kontouppgifter och koder. Att ge det till någon på Facebook är ingen bra idé.
  • Din bank kommer (ska) aldrig, aldrig, aldrig skicka mail till dig och be dig klicka på en länk för att komma till en sida där du ska mata in kontouppgifter och koder.

Det här är inga nyheter egentligen. Det intressanta och viktiga med artikeln är att bankerna och ARN anser att dessa problem är så vanliga och har varnats för så länge att du som konsument nu anses måste känna till dem och inte begå dessa misstag.

Uppdatering om testvevtorer för ChaCha

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_testvectorsGithub. Kommentarer, synpunkter och patchar högeligen välkomna.

Testvektorer för strömkryptot ChaCha och verifiering av kryptofunktioner

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

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.

Avlyssna tangentbord med mobilen

Förra veckans tveklöst mest spännande säkerhetsartikel är (sp)iPhone: Decoding Vibrations From Nearby Keyboards With Mobile Phone Accelerometers (pdf).

I artikeln beskriver författarna Philip Marquardt, Philip Marquardt, Henry Carter och Patrick Traynor hur dom med hjälp av accelerometrar i en mobiltelefon kan detektera och tolka vad som skrivs på ett tangentbord som befinner sig på samma bord/yta som mobilen. Typ så här:

Mobilen bredvid tangentbordet.
Mobilen bredvid tangentbordet.

Med hjälp av träningsdata bygger författarna upp en databas med tolkade mönster. När sedan detektering sker matchar insamlade vibrationer med tidigare mönster.

Exempel på mönster
Exempel på mönster

Man använder både mönster för enskilda tecken, kombinationer av tecken och meningar.

Exempel på avkodad text
Exempel på avkodad text

Författarna når på detta sätt en förmåga att tolka 80% av texten som skrivs på tangentbordet.

Intressant nog gör nyare generationer av accelerometrar att attacken blir bättre. Figuren nedan visar hur det med en iPhone 3GS (övre kurvan) inte går att identifiera enskilda knapptryckningar. Men med en iPhone 4S (nedre kurvan) går det bra.

Kvalitet hos accelerometrarna
Kvalitet hos accelerometrarna

Författarna har valt att bara använda accelerometrarna. Det hade varit intressant att se hur mycket bättre tolkningen blivit om även mikrofonen användes för att samla in information till analysen. Gissningsvis kommer vi få se fler undersökningar av den här typen av mobilbaserade TEMPEST/RÖS-attacker.

En annan sak som författarna inte tar upp i texten är möjligheten att identifiera personen som skriver på tangentbordet. Att det finns biometrisk information som gör det möjligt att identifiera en person i rytmen, mönstret personen skapar genom att skriva på ett tangentbord är känt sedan länge. Svenska startupföretaget BehavioSec (Behaviometrics) bygger produkter runt idén och har skapat mobilappar med tekniken.

BehavioSecs mobillösning
BehavioSecs mobillösning använder både mönster när man skriver och/eller ritar på skärmen.

BehavioSec använder tekniken för att identifiera korrekt användare, men visar anser jag att tekniken inte bara kan tolka vad dom skrivs, utan vem som skriver. Nu vet man kanske vem som sitter och skriver på ett tangentbord om man sitter bredvid. Men om mobilen kapats (och attacken sker på distans), eller som ett sätt att skapa metainformation om en användare är detta ändå inte helt otroligt.

Så hur skyddar man sig mot den här typen av attacker? Författarna själva pekar på en svaghet i metoden – avståndet mellan tangentbord och mobil. Mycket över 30-40 cm verkar i deras undersökning göra det praktiskt omöjligt. Man kan dock anta att material i bordsskivan (något författarna även diskuterar – kakel ger bättre skydd än trä), hur tangentbordet står på bordet, samt vad bordet står på borde påverka.

Ett förslag som dök upp i diskussionerna på Hacker News (HN) var att vibrera bordet. Men antagligen behöver man vara smartare än så – annars är det bara att filtrera ut störningarna. Vad man vill göra är något liknande Danny Hillis maskin Babble som skyddar ett rum mot avlyssning genom att generera nonsensljud som låter skrämmande likt en konversation. Här skulle man istället vibrera skrivbordet som om det skrevs text (ex Lorem Ipsum – men inte just den texten då den går att identifiera och filtrera bort). Helst skulle man mappa vibrationerna med mönstret hos den riktiga användaren av skrivbordet så att det blir riktigt svårt att särskilja skyddsvibrationerna med de riktiga vibrationerna. En riktigt kul idé.

Men att inte ha mobiler på bordet, utan i en ficka, helst avstängt eller utanför rummet borde vara det som enkelt faktiskt fungerar som skydd.

För den som vill läsa lite mer rekommenderas diskussionen på HN om artikeln som är väl värd att läsa.