Etikettarkiv: krypto

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!

Krypto och säkerhet i en övervakad värld

Uppdaterad 2013-09-13 om CryptoAPI.

Efter nattens nya avslöjanden om NSAs avlyssning har det kommit mycket frågor om vad som stämmer, vad som kan vara knäckt, vad man kan lita på och hur man kan skydda sig.

Eftersom det trots alla avslöjanden saknas mycket konkret information om vilka algoritmer, protokoll, produkter och tjänster som på olika sätt är svagare än förväntat är det fortfarande klart förvirrande. Men jag tycker att den analys och de rekommendationer som Bruce Schneier publicerat är bra.

En av de stora frågorna är huruvida SSL/TLS faktiskt är säkert. Forskaren Matthew Green har publicerat en bra analys väl värd att läsa. Han och Bruce är relativt samstämmiga i att algoritmerna, inte minst AES är bra. Även om NSA har kryptologer som hittar sätt att reducera styrkan hos AES med ett antal bitar är det inte det som är det konkreta problemet (det är faktiskt det dom förväntas arbeta med).

Nej problemet är att man nu säger att man på olika sätt attackerar implementationerna av ex SSL/TLS. Antingen hittar svagheter som sedan utnyttjas eller mer tveksamt tvingar leverantörerna att införa svagheter. Det vill säga man avsiktligt gör oss alla mer sårbara än nödvändigt, för dessa sårbarheter kan hittas och utnyttjas inte bara av NSA och deras kompisar.

De vanligaste implementationerna av SSL är troligen Microsofts CryptoAPI samt OpenSSL. Den första är stängd för granskning kräver avtal för att få rätt att granska koden och kan därför inte ges samma tilltro som en öppen och fri lösning där alla när som helst kan granska, modifiera, bygga och sedan kommunicera sina observationer och erfarenheter.

OpenSSL är öppen kod, men har en historik med mycket svagheter (som dock högst troligt inte är avsiktliga) vilket visar att säkerheten och tilliten inte med nödvändighet är fantastiskt bara för att koden är öppen. Men just nu är OpenSSL, GnuTLS, Nettle, Sodium och liknande öppna bibliotek antagligen det bästa vi kan använda.

Vad gäller hårdvara är det svårare. Vi kan nog utgå ifrån att en normal processor generellt utför sina beräkningar på ett korrekt och förväntat sätt. Även instruktioner för kryptoacceleration som Intels AES-NI ger verifierbart korrekt kryptering och dekryptering. Däremot vet man inte vad som faktiskt sker med nyckeln som används förutom det förväntade beteendet.

Än mer problematiskt blir det med inbyggda slumptalsgeneratorer som Intels nya RdRand (Bull Mountain). Den går knappast i dagsläget att lita på och använda direkt för nyckelgenerering. Att använda RdRand som en av flera entropikällor som sedan matar en PRNG man litar på bör fortsatt kunna fungera.

En intressant sak som kom fram i natt var att misstankarna om bakdörren i NISTs slumptalsgenerator Dual_EC_DBRG antagligen bekräftades. Detta visar vikten av att standarder utvecklas i en öppen process och att alla detaljer in en specifikation går att härleda. Det är bland annat därför det Kinesiska strömkryptot för mobilsystem ZUC är svårt att lita på eftersom det innehåller konstanter och detaljer som inte går att härleda.

Det enkla vi kan göra är att använda öppna implementationer av algoritmer som tagits fram i en öppen process. Och kan vi välja en längre nyckel så gör det. Det kostar väldigt lite för dig som användare men gör det mycket svårare för motståndaren oavsett vem det är. Och tänk igenom på vilka verktyg du använder för att generera och lagra nycklar. Att använda 1024 bitars RSA-nycklar för egen kommunikation eller i certifikat känns i dag som fel.

Avslutar med ännu en länk. Denna gången till en chatt med säkerhetsexperten Jakob Schlyter på Kirei som tänker bra och klokt.

Introduktion till Bitcoin

För den som vill veta mer om den kryptografiskt baserade, digitala valutan Bitcoin finns det en riktig bra introduktion att läsa.

Bitcoin: A Technical Introduction (pfd), skriven Chris Clark går på ca 40 sidor igenom vad Bitcoin är, hur man använder Bitcoins, den bakomliggande kryptografiska tekniken, digitala valutor inklusive några föregångare. Slutligen tittar den på hur Bitcoin är implementerad samt hur man gräver (mining) efter bitcoins.

Svaga nycklar i strömkryptot RC4

I dag har organisationen IACR, International Association for Cryptologic Research accepterat en artikel av Secworks Joachim Strömbergson samt Simon Josefsson som beskriver en typ av svaga nycklar i strömkryptot RC4.

I artikeln The Perils of Repeating Patterns: Observation of Some Weak Keys in RC4 beskriver vi hur nycklar bestående av ett mönster repeterat två eller flera gånger kan ersättas med en nyckel lika lång som mönstret självt. Följande figur illustrerar vad vi menar:

Olika nycklar i RC4 som genererar samma sekvens
Två olika par med nycklar där nycklarna i varje par får RC4 att generera samma sekvens.

Notera att för de två paren är skillnaden mellan nycklarna att dom är olika långa samt består av olika antal iterationer av samma mönster. I det övre nyckelparet är mönstret 0X55 och i det nedre nyckelparet är mönstret 0X01020304.

Så hur kan det bli så här? Den sekvens RC4 genererar styrs av hur den interna tillståndstabellen S initieras. Detta sker med funktionen KSA (Key Scheduling Algorithm):

RC4:as nyckelberoende initiering.
Den nyckelberoende initieringen i RC4.

Först fylls S med mönstret [0, 1, .. , 255]. Sedan kastas värdena i S om genom att under ett svep över S byta värden på två positioner i taget. Vilka positioner som används är alltid positionerna [0, 1, 2, … 255] (som anges av i) samt positioner som anges av j, vilket beror av nyckeln K. Detta sker på kodrad (5).

Nyckeln består av ett antal bytes och dessa bytes används i tur och ordning för att ge ett positivt bidrag till j. Och när alla bytes i K använts börjar man använda första byten i nyckeln igen tills dess att svepet över S är färdigt.

Boven i dramat är att värdena i nyckeln används på detta cykliska sätt utan att nyckelns längd får vara med och påverka pekaren j. En nyckel som består av två mönster [PP] appliceras på S ger samma bidrag till j som en hälften så lång nyckel som bara består av mönstret [P].

Vi tror inte att vi är dom första som observerat beteendet, det är alldeles för enkelt och dessutom är konstruktionen med att cirkulärt applicera ett mönster relativt vanligt. Det är därför en aning märkligt att vi inte lyckas hitta en beskrivning av beteendet kopplat till RC4. Vi har verkligen försökt så gått vi kan läsa igenom allt om RC4 och nycklar vi kunnat hitta, och det finns rätt många. RC4 är tyvärr ett krypto där det finns många svagheter. Vi har även kontaktat forskare som publicerat några av dessa svagheter men dessa har inte heller känt till beteendet vi beskriver.

Det finns dock en beskrivning av beteendet av Bruce Schneier i sin artikel som introducerar blockkryptot Blowfish. Schneier skriver om hur nyckeln används för att initera Blowfish:

Repeatedly cycle through the key bits until the entire P-array has been XORed with key bits. (For every short key, there is at least one equivalent longer key; for example, if A is a 64-bit key, then AA, AAA, etc., are equivalent keys.)

Vi tycker dock att det är omvänt sätt att beskriva det hela. Problemet är inte att för en given nyckel N finns det längre nycklar n*N där n är ett heltal [2, 3, ..]. Nej problemet är att för en nyckel som består av ett mönster N repeterat x gånger finns det ett antal kortare och därmed svagare nycklar.

I exempelvis SSL/TLS genereras nyckeln av en internfunktion med bra kvalitet och sannolikheten att en nyckel som består av ett repeterat mönster används är därför liten. Även i andra tillämpningar där användaren anger nyckel sker ofta en processning av nyckeln genom att köra nyckeln i en kryptografisk hashfunktion (helst många gånger) eller genom ett systen som PBKDF2, bcrypt (som använder Blowfish internt) eller scrypt.

Men jag har tyvärr sett tillämpningar där RC4 används och nyckeln appliceras direkt. Tillämpningar där nyckeln varit av typen 0X0101010101010101 eller 0X0102030405060701020304050607. För dessa är nyckeln inte 64 eller 128 bitar utan 8 respektive 64 bitar.

Vi räknar med att höra av forskare och andra kunniga människor som pekar ut var beteendet och problemet finns beskrivet. Men om det inte sker hoppas vi att den här artikeln hjälper till att sprida kunskapen om beteendet. Vill du undvika de problem vi observerat när du använder kryptp RC4 bör du helt enkelt inte använda nycklar som består av ett repeterat mönster.

Har du synpunkter och information om artkeln får du mer än gärna höra av dig till mig och Simon.

Matasanos kryptoutmaningar

Det få sätt att effektivt lära sig saker som att faktisk sätta sig ner och praktiskt utföra, öva på den man vill lära sig. Det gäller både saker som kanske är tråkiga, exempelvis glosor på tyska och saker som är desto roligare – spela gitarr eller hacka krypton.

Säkerhetsföretaget Matasano Security har insett detta och har därför skapat en serie spännande krypto och IT-säkerhetsutmaningar. Utmaningarna skickas som mail innehållandes åtta olika problem. Totalt finns sex uppsättningar problem. Problemen sträcker sig från grundläggande kodningar och XOR-krypton till slumptalsgeneratorer, strömkrypton, nyckelsystem och mycket mer. Själva utmaningarna är inte problem avsedda att luras, utan bygger på faktiska attacker och svagheter.

Matasano Security

Jag har precis börjat arbeta mig igenom utmaningarna. För att göra det lite svårare för mig själv försöker jag dessutom implementera mina lösningar inte bara i Python och/eller C, utan även i SystemVerilog. Vi får se hur länge det är realistiskt att göra det. Att implementera RSA i hårdvara kräver en hel del arbete – troligen mer än att lösa själva problemen i utmaningarna. Så här långt har det varit både givande och väldigt roligt.

För mer information om utmaningarna och hur du anmäler dig (du skickar ett mail), se Matasanos sida om utmaningarna. Om du genomför samtliga 48 utmaningar lovar Matasano även att donera 20 USD till välgörande ändamål.

Här finns även en sida skriven av en person som genomfört samtliga utmaningar och berättar lite mer om dom. En krav från Matasano är dock att inte ge beskriva utmaningarna i detalj eller dela med sig av sina lösningar, just för att andra också ska få chansen.

Hacking the Xbox nu som gratis e-bok

Andrew Bunnie Huang, som Secworks tidigare uppmärksammat för sitt projekt att utveckla en egen laptop, har släppt sin bok Hacking the Xbox i PDF-format fri för nedladdning.

Hacking the xbox, som kom 2003 är en fantastisk bok, som inte bara berättar om hur Bunnie som forskarstudent lyckades knäcka skyddet i Xbox. Boken är istället en mycket bra introduktion till metoder och verktyg för att analysera och plocka isär digitala system.

Hacking the xbox

Även om boken har några år på nacken är den fortfarande mycket läsvärd och relativt unik i sitt fokus på praktiskt arbete, inte bara teori.

Skälet till att Bunnie och bokens förlag släpper boken fritt beror på hur hackern Aaron Swartz behandlades. Bunnie skriver bland annat:

No Starch Press and I have decided to release this free ebook version of Hacking the Xbox in honor of Aaron Swartz. As you read this book, I hope that you’ll be reminded of how important freedom is to the hacking community and that you’ll be inclined to support the causes that Aaron believed in.

I agreed to release this book for free in part because Aaron’s treatment by MIT is not unfamiliar to me. In this book, you will find the story of when I was an MIT graduate student, extracting security keys from the original Microsoft Xbox. You’ll also read about the crushing disappointment of receiving a letter from MIT legal repudiating any association with my work, effectively leaving me on my own to face Microsoft.

The difference was that the faculty of my lab, the AI laboratory, were outraged by this treatment. They openly defied MIT legal and vowed to publish my work as an official “AI Lab Memo,” thereby granting me greater negotiating leverage with Microsoft. Microsoft, mindful of the potential backlash from the court of public opinion over suing a legitimate academic researcher, came to a civil understanding with me over the issue.

Här finns hela motivering till varför Bunnie och förlaget släpper boken.

Cryptoparty i Stockholm 2013-02-16

Kryptera.se berättar att den 16:e februari ordnas för första gången ett CryptoParty i Sverige.

cryptopartyposter
cryptopartyposter

Ett CryptoParty är ett möte där intresserade personer kan få lära sig mer om krypto, teknik för integritet m.m.

CryptoParty-logga.

CryptoPartyt i Stockholm arrangeras av organisationen DFRI samt hackerspacet Sparvnästet. Partyt kommer att hållas i .SE:s lokaler på Ringvägen 100 i Stockholm.

På programmet finns än så länge presentationer och workshops om Grundläggande krypto och kryptering, Digitalt Källskydd, Tor och hur filtermekanismer på nätet fungerar. Samt naturligtvis organiserad nyckelsignering (key signing party).

Evenemanget ser mycket intressant ut och organiseras av duktiga och kompetenta personer. Dessutom är det gratis – kan det bli bättre?

Nya kryptotävlingar

Knappt har röken från NISTs SHA-3-tävling lagt sig för det är dags igen.

CAESAR
Daniel J Bernstein har med ekonomiskt stöd från NIST i all korthet utlyst en ny tävling. Den nya tävlingen, CAESAR – Competition for Authenticated Encryption: Security, Applicability, and Robustness syftar till att få fram symmetriska kryptoalgoritmer som även ger autenticering av datat som bearbetas.

I dag är det väldigt tydligt att för den överväldigande mängden kommunikation är kryptering (som ger konfidentialitet) oftast mycket mindre viktigt än att veta att meddelanden kommer från rätt sändare och att det inte modifierats under överföring. Inte minst gäller detta industrisystem och inbyggda system där informationen sällan är känslig, men måste vara korrekt. Tyvärr är det få kryptoalgoritmer som ger både konfidentialitets- och autenticitetsskydd och det är vanligt att se system där bara konfidentialitet används.

Kryptot AES exempelvis kräver en kryptomod som GCM för att ge båda egenskaperna, en kryptomod som är relativt kostsam.

CAESAR avser att försöka standardisera en portfölj med bra ström- och blockkrypton samt kryptomoder som ger båda egenskaperna. Ett mycket bra initiativ.

Tidplanen för CAESAR är att kandidater ska vara inlämnade i början av 2014 och sedan sker utvärderingar under flera år för att slutligen 2017 förhoppningsvis leda till en portfölj med flera algoritmer.

Nya hashfunktioner
Det pågår även ett initiativ att starta en tävling motsvarande eSTREAM sponsrat av EU för att få fram nya hashfunktioner som är både kompakta och mycket snabbare än MD5, inte minst på enklare plattformar. Här finns det dock mindre konkreta planer än.

SHA-3 (Keccak) är en snabb algoritm på 64-bitars processorer. Men på 16- eller 32-bitars processorer samt i hårdvara har den visat sig vara svår att få riktigt snabb och samtidigt kompakt. SHA-2-algoritmerna har inte slagit, mycket på grund av att dom är så mycket långsammare än SHA-1 och MD5.

Många hoppades att SHA-3 skulle få fram radikalt snabbare algoritmer, men så blev det inte. Däremot har det efter SHA-3 dykt upp minst en intressant sådan algoritm. BLAKE2, en ny version av SHA-3-finalisten är mycket snabb och finns dessutom i ett par versioner för att möte krav från begränsade plattformar och för de med höga krav på säkerhet.