Etikettarkiv: SecWorks

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.

SipHash i assembler för MOS 6502

I ett anfall av programmeringsklåda har jag (Joachim) implementerat den nyckelstyrda, kryptografiska hashfunktionen SipHash i assembler för den gamla 8-bitars processorn MOS 6502.

MOS 6502
MOS 6502

Resultatet, siphash_6502 finns i ett öppet repo på Gitorious.

Jag förväntar mig inte att koden kommer att få någon större spridning. Däremot var det en intressant övning att implementera 64-bitarsoperationer på en 8-bitarsprocessor med få instruktioner och än färre register. Koden, som är byggd med makron, borde även kunna gå att porta relativt lätt.

Storleksmässigt tar den nuvarande implementationen 677 Bytes i kod och 103 Bytes för datastrukturer inklusive lagring av nyckel samt datablock. Genom att ändra om de stora makrona till funktioner som återanvänds skulle det gå att banta koden en aning. Det finns i dag ett utkast till en kompakt version i repot, men den är inte färdig än. Men att få in en komplett MAC-funktionalitet på under 1 kByte på en sådan här processor visar att SipHash går att använda även i riktigt små system.

Prestandamässigt tar en kompressionsoperation knappt 5000 cykler, vilket ger ungefär 600 cykler/Byte för ett långt meddelande. I värsta fallet, med ett meddelande på ett enda block tar det ungefär 15000 cykler. En gammal Commomodore 64:a klarar ungefär 200 stycken sådana bearbetningar/s. För ett litet Internet of Things-system borde det i många fall vara mer än tillräckligt för att kunna autenticera meddelanden i realtid.

På Gitorious finns även den hårdvaruimplementation av SipHash som Secworks tidigare släppt.

Ny version av SipHash-core med högre prestanda

Den öppna hårdvaruimplementation av den kryptografiska hashfunktionen SipHash som Secworks utvecklat finns nu i en ny version.

I den nya versionen har antalet adderare dubblerats så att den den inre iterationen nu kan utföras på en cykel. Detta gör att antalet cykler för att bearbeta ett meddelande om upp till 8 Bytes (ett block) minskat från 28 till 10 cykler. För långa meddelanden går latenstiden mot 0,5 cykler/Byte.

Storleksmässigt har SipHash-core krympt något och kräver nu Alteras Cyclone IV-teknologi 1088 LE:s, en minskning med 25%. Däremot har maximala klockfrekvensen minskad till 90 MHz. Detta gör att SipHash-core i Alteras teknologi för långa meddelanden kan hantera datatakter på mer än 1 Gbps.

Altera Cyclone IV

Den nya versionen finns i det publika repot för SipHash-core hos Gitorious.

Kirei släpper handledning om IP-baserade kommunikationsprotokoll

Det svenska IT-säkerhetsföretaget Kirei har släppt en handledning om IP-baserade kommunikationsprotokoll.

Kireis logga.

Handledningen är utvecklad på uppdrag av en större kund under förra året. Handledningen beskriver olika typer av IP-baserade tillämpningar samt hur tillämpningarnas egenskaper påverkas beroende på hur den underliggande anslutningen. Hur väl fungerar exempelvis en realtidstillämpning över en anslutning med lång fördröjning, och spelar det för tillämpningens användbarhet att öka anslutningens överföringskapacitet är exempel på frågor handledningen försöker besvara.

Handledningen vänder sig i första hand till ansvariga för utveckling av IT-stöd, t.ex. IT-chefer, IT-arkitekter och verksamhetsansvariga, men innehåller även en fördjupningsdel med mycket matnyttig information för systemspecialister, nätverksansvariga, utvecklare och andra tekniker.

Secworks har under året arbetat för Kirei med att utveckla handledningen. Att arbeta tillsammans med några av Sveriges vassaste IT-säkerhetsexperter har varit både spännande och kul.

Handledningen är släppt under Creative Common-licens.

CC-licensen CC BY-NC-ND

Vi som skrivit handledningen tar väldigt gärna emot kommentarer och synpunkter samt förslag på ändringar och förbättringar.

SipHash som öppen hårdvara

Hashtabeller är en av de verkliga arbetshästarna bland datastrukturer. Hashtabeller används bland annat i databaser, i mellanlagring av webbtjänster (webcache), DNS-uppslagningar och inte minst som viktig datastruktur i språk som Perl, Python, PHP, Ruby etc.

Hashtabell där en hashfunktion givet en nyckel skapar index in i tabellen.
Hashtabell där en hashfunktion givet en nyckel skapar index in i tabellen. (Bild från Wikipedi)

En Hashtabell gör det möjligt att givet ett värde (ofta kallad nyckel) direkt få fram ett dataelement. Till skillnad mot exempelvis ett sökträd ger en hashtabell ofta kortare och framförallt konstant tid att lagra och hitta element i strukturen. Detta under förutsättning att inte flera nycklar pekar på samma plats i datastrukturen, ett situation som kallas en kollision. När en kollision uppstår finns det flera strategier för att hantera detta, en är att använda närmaste positionerna i tabellen (uppåt/nedåt om man ser tabellen som en vertikal tabell). Effekten av en sådan strategi är att kollisioner omvandlas till långsam linjär sökning.

En förutsättning för att antalet kollisioner hålls låg är att fördelningen av värden i datastrukturen givet alla möjliga nycklar sker på ett likafördelat sätt. Det vill säga, det är lika stor sannolikhet att en position i tabellen pekas ut som alla andra. Och det som avgör fördelningen i tabellen är hashfunktionen, den funktion som tar en nyckel och räknar ut positionen (även kallat index) i hashtabellen.

Traditionellt har kraven på hashfunktionen varit två:

  1. Den ska ge en likafördelning
  2. Den ska vara snabb

Att den är snabb innebär att den inte kan vara speciellt komplicerad. I min gamla algoritmkursbok, den utmärkta Introduction to Algorihms, är ett av de hashfunktioner som presenteras den här:

Enkel hashfunktion från kursbok.
Enkel hashfunktion från kursbok.

Detta är en enkel och snabb hashfunktion som ger hygglig likafördelning. Nackdelen med den här typen av funktion är att det är enkelt att räkna ut vad en given nyckel ska kompletteras med för att få fram ett givet index. Om en tredje person kan påverka nyckeln in kan denne tvinga fram kollisioner som gör att hashtabellen omvandlas till linjära sökningar som till och med kan sänka en tjänst.

Utslagningsattacker mot hashfunktioner
Ett exempel på detta är den attack på ramverk för webbtjänster som Alexander Klink och Julian Wälde presenterade 2011. Dom kunde visa hur dom med enkel indata kunde sänka kraftiga webbservrar genom att tvinga fram kollisioner i webbplatformens hashtabeller. Författarna demonstrerade fungerande attacker på PHP, ASP.Net, Python, Perl, Java m.m, vilket och ledde fram till utslagningsattacker mot ett stort antal ramverk och applikationer.

Det finns mer avancerade hashfunktioner som försöker kombinera snabbhet, bra likafördelning och samtidigt göra det svårare för den typ av attack som Alexander och Julian visade på. Två av dessa är Cityhash och MurmurHash. Tyvärr har båda dessa funktioner visats sig gå att attackera och räkna ut hur man ska agera för att orsaka en kollision.

Det finns en typ av hashfunktioner som ger ett bra skydd mot attacker av den ovan, och det är kryptografiska hashfunktioner exempelvis MD5 (som dock INTE ska användas) SHA-1 och SHA-256.

Dessa funktioner uppfyller väl kraven på likafördelning och funktionerna ger ett bra skydd mot att tvinga fram kollisioner genom att modifiera nyckeln. Det går helt enkelt inte bestämma vad som skall läggas till nyckeln för att få fram ett givet index (snabbare än att pröva ett enormt antal kombinationer, i fallet SHA-1 är det 2**80 försök). Så vad är då problemet, varför inte byta till en kryptografisk funktion. Prestandan, eller snarare avsaknaden av prestanda.

Kryptografiska hashfunktioner är mycket mer komplicerade än exempelvis Cityhash och består oftast av en funktion som upprepas ett stort antal gånger (kallas iterationer eller rounds). I SHA-1 sker 80 iterationer. Att byta ut hashfunktionerna som använts i exempelvis Python och Perl till SHA-1 anses orealistiskt då det skulle göra hashtabellerna mycket, mycket långsammare och därmed negativt påverka prestandan hos applikationer skrivna i dessa språk

Ett annat problem med de hashfunktioner som använts är att dom är gemensamma för alla instanser. Kan du hitta ett sätt att tvinga fram kollisioner i Cityhash kan du attackera alla system där Cityhash används. Hade hashfunktionen varit unik för varje instans skulle effekten av ett sätt att göra kollisioner blir mycket mindre.

Det vi behöver är alltså en hashfunktion som är:

  1. Mycket snabb, helst inte mycket långsammare än dagens hashfunktioner.
  2. Ger minst lika bra likafördelning
  3. Ger ett starkt skydd mot avsktliga kollisioner
  4. Enkelt går att göra unik för en given instans – program, installation, process

SipHash
En sådan funktion som nyligen presenterades är SipHash, skapad av kryptoexperterna Jean-Philippe Aumasson och Daniel J. Bernstein.

SipHash beter sig mycket som en kryptografisk hashfunktion i det att den iterativt kan beräkna ett värde (kondensat) för ett meddelande genom att tugga i sig meddelandet uppdelat i block med en fix storlek. I SipHash är blocken 64 bitar. Siphash tar även emot en nyckel om 128 bitar som gör beräkningen unik.

Den huvudsakliga operationen i SipHash är SipRound. SipRound består av additioner, logiskt XOR samt bitmässig rotation och dessa operationer appliceras på fyra stycken interna 64-bitars variabler (v0, v1, v2, v3) tillsammans med det givna meddelandeblocket (mi). Figuren nedan visar beräkningskedjan för SipRound:

Beräkningskedjan i SipRound.
Beräkningskedjan i SipRound.

Ringarna med kors är XOR-operationer, kvadraterna är addition och vänsterpilarna är bitmässig rotation. Totalt sker fyra additioner, fyra XOR och fyra rotationer per SipRound.

Att bearbeta ett block sker genom att upprepat applicera ett SipRound ett antal gånger. Efter att alla block har beatbetas sker en avslutande fas där SipRound upprepat applicerat ett antal gånger till. Hur många gånger som SipRound utförs för att bearbeta ett block samt under avslut styr hur säker SipHash är. Skaparna av SipHash har föreslagit Siphash-2-4, vilket innebär två SipRounds för varje block samt fyra SipRounds som avslutning.

Skaparna av SipHash ger i sin artikel som presenterar SipHash motivering till designen hos SipHash, en genomgång av säkerheten samt prestandajämförelser. Enligt skaparna bör SipHash ge ett skydd motsvarande att uttömmande pröva samtliga nycklar till funktionen. Prestandamässigt är SipHash inte mycket långsammare än exempelvis Cityhash och mycket snabbare än MD5. Figuren nedan är från artikeln.

Prestanda för SipHash.
Prestanda för SipHash.

Notera att SipHash prestanda skalar linjärt, till skillnad från MD5 som har en kostsam initieringsfas.

En viktig poäng med SipHash som dess skapare framhåller är att eftersom den har en nyckel och ger kryptografiskt starkt skydd går den även att använda för att beräkna äkthetskoder för meddelanden (Message Authentication Code – MAC) på ett mycket snabbare sätt än exempelvis HMAC. Detta gär SipHash mycket intressant för inbyggda system där äkthetsskydd av meddelanden är mycket viktigt.

Det finns redan i dag ett antal programvaruimplementationer av SipHash och SipHash har även integrerats in i flera projekt projekt bland annat OpenDNS, Perl och Ruby. (Tyvärr har Python ännu inte gjort detta och diskussionen om problemet med kollisioner och hur man vill lösa det i Python är en delvis tråkig läsning.)

Siphash_core
Det som ännu inte funnits är en hårdvaruimplementation av SipHash. Secworks har därför utvecklat en hårdvaruimplementation av SipHash avsedd att integreras i FPGA- eller ASIC-konstruktioner kallad siphash_core. Vår implementation är skriven i relativt konservativ Verilog 2001 och bör vara mycket enkel att integrera. Implementationen är släppt som öppen kod under BSD-licens. Vår implementation av SipHash, siphash_core finns för nedladdning på Gitorious.

Den implementation av siphash_core som finns i dag är en semikompakt lösning där SipRound utförs i fyra steg. I varje steg uppdateras tre eller fyra av tillståndsregistren (v0_reg..v3_reg). Den resursmässigt dyraste operationen är 64-bitars addition och implementationen innehåller två adderare som återanvänds under utförandet av SipRound.

Det skulle gå att göra än en mer kompakt implementation där fler av operationerna använder samma hårdvarurs. En sådan implementation skulle dock knappast ge speciellt mycket bättre prestanda än en programimplementation även på en 16- eller 32-bitars processor.

Det skulle även gå att göra en större implementation där flera av stegen i SipRound utförs i samma cykel. På grund av adderarnas djup är det dock tveksamt om det går att nå speciellt hög klockfrekvens för en sådan lösning. Risken är stor att kostnaden i form av lägre klockfrekvens är större än minskningen i latens.

Vi kommer att testa dessa varianter av implementationer, men känslan just nu är att den version av siphash_core som finns i repot på Gitorious i dag ger bra balans mellan storlek, klockfrekvens och antalet cykler för att processa ett meddelandeblock.

I värsta fallet, för ett meddelande om på exakt 64 bitar krävs det med vår implementation 28 cykler, eller ungefär 3,5 cykler/Byte. Detta kan jämföras med MD5 som kräver minst 64 cykler (om man utför en iteration/cykel) eller 8 cykler/Byte.

Vi har testat att implementera siphash_core i en av Alteras FPGA:er, en Cyclone IV GX. I denna krets kräver siphash_core 1451 LEs (Alteras benämning på sina logiska element) samt 332 register. Inga minnen eller andra resurser används. Den klockfrekvens vi når är 117 MHz. Om vi jämför med den implementation av MD5 som finns på OpenCores så kräver den i samma FPGA-krets 1883 LEs, 910 register och når en klockfrekvens på 62 MHz.

Vi kommer att göra en del modifieringar och utökningar av implementationen. Bland annat kommer vi att som tidigare beskrivit skapa några nya versioner för att täcka in fler designtyper. Vi kommer även att utöka med fler testfall samt ta fram en toppnivåwrapper med ett enkelt 32-bitars gränssnitt som underlättar för integration med WISHBONE eller AMBA.

Om ni har några frågor om SipHash och/eller Secworks implementation siphash_core är det bara att höra av sig.

Referat från föredrag på SEE 2012

Elektroniktidingen har publicerat en artikel om Secworks föredrag på SEE 2012 förra veckan.

Secworks Joachim Strömbergson pratar på SEE 2012.
Secworks Joachim Strömbergson pratar på SEE 2012.

Poängen vi i presentationen försöker göra är att säkerhet är en stödfunktion avsedd att skydda den affär som är kopplad till ett inbyggt system. För att få få fram den säkerhet affären kräver gäller det att identifiera vad i affären som måste skyddas, mot vem (fiende, motståndare) skyddet ska hålla och under vilka förutsättningar skyddet fungerar. Efter detta går det att identifiera komponenter och tekniker för att skapa detta skydd. Och till sist, inte glömma bort att verifiera att man verkligen fick det skydd som affären krävde.

Gör man inte på detta sätt riskerar man att få ett skydd för fel sak, skydd mot en annan motståndare och ett skydd som inte fungerar. Ett sådant skydd är förhoppningsvis bara onödigt dyrt och onödigt, men kan i värsta fall hota din affär och verksamhet.

Tre steg till bättre säkerhet

Vill du veta hur du hittar rätt säkerhet för ditt inbyggda system eller tjänst är du välkommen till mässan Scandinavian Electronics Event 2012 i morgon bitti.

Scandinavian Electronics Event 2012

Då kommer Secworks Joachim Strömbergson att hålla en presentation om hur du genom tre steg kan identifiera vilken säkerhet du behöver, hur du får tag på rätt säkerhet och hur du kontrollerar att du fick den säkerhet du behövde. Presentationen börjar 09:30.

Välkommen!