Kategoriarkiv: Om 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.

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 draft för att få in Salsa20 i TLS och DTLS

Tillsammans med Simon Josefsson och Nikos Mavrogiannopoulos är Secworks involverade i arbetet att skriva en Internet Draft avsedd att få in strömkryptot Salsa20 i TLS och DTLS.

Skälet till arbetet med draften draft-josefsson-salsa20-tls-01 är att vi ser att det behövs ett bra, säkert strömkrypto i TLS och DTLS. I dag finns bara RC4 som strömkrypto, men RC4 är rejält trasigt. Det finns ett antal blockkrypton, inte minst AES, men de senaste årens säkerhetsproblem har gjort att fler använder RC4.

Att få in ett nytt strömkrypto kräver att det finns en RFC som beskriver hur strömkryptot ska användas i TLS och DTLS och draften är arbetsdokumentet till vad som förhoppningsvis blir denna RFC.

Salsa20 är ett strömkrypto som har kort initieringsfas och därmed ger bra prestanda även för korta meddelanden. Salsa20 går att få att ge bra prestanda på ett flertal olika processorarkitekturer. ARX-strukturen gör att Salsa20 inte öppnar upp för informationsläckage via sidokanaler. Slutligen är Salsa20 relativt väl analyserad då den är en av algoritmerna i eSTREAM-portföljen. Vi tror därför att Salsa20 skulle kunna bli en bra ersättare till RC4 i TLS och DTLS.

Om du har några kommentarer och synpunkter på draften skulle vi som författare uppskatta det mycket. Kontakta oss gärna. Själva arbetet med draften sker på Gitorious.

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.

Skräprobotornas växande intelligens

Kollar snabbt igenom kommentarer här på bloggen som markerats som skräppost och blir nästan lite impad över vilken intelligens robotarna som postar börjar uppvisa. Här är ett klipp från en postning:

Utdrag ur skräppost
Utdrag ur skräppost

Visst, troligen är texten plockad från en annan webbplats och inte helt generererad. Men det är ändå imponerande att dom lyckas plocka ut som ser relativt relevant ut för den givna målwebbplatsen. De användare som postar den här typen av information har ofta någorlunda trovärdiga namn. Däremot pekar deras info alltid tillbaka på direkta adresser:

Exempel på användare som postar skräppost
Exempel på användare som postar skräppost

Det är en ständigt pågående utveckling av robotar och skydd. Vore hemskt om det som gjorde att singulariteten inträffar är spam-robotar…

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!

Artikel på IDG om asymmetrisk kryptering

TechWorlds webbplats finns sedan några dagar en artikel om asymmetrisk kryptering skriven av Secworks.

Här får du min publika nyckel.
Här får du min publika nyckel.

Artikeln tar upp vad asymmetriska krypton och kryptering med publika nycklar är samt hur dom används och vilka problem som finns. Artikeln beskriver även skillnader i nyckelstyrka mellan symmetriska och asymmetriska algoritmer. Dessutom tittar vi i artikeln närmare på flera olika algoritmer som RSA, El Gamal, Elliptic Curve och Curve25519. Förhoppningsvis ger artikeln lite insikt i hur asymmetrisk kryptering fungerar och används.

Bittester av kryptografiska hashfunktioner

Kryptografiska hashfunktioner (och krypton) har en egenskap kallas lavineffekten. Lavineffekten innebär att små förändringar av indata ger stora förändring på det genererade hashvärdet.

Hashvärden för SHA-256 när S ändras till T.
Hashvärden för SHA-256 när S ändras till T.

Men hur stor är lavineffekten, och finns det indata som ger olika stor lavineffekt? Jag bestämde mig för att testa på de hashfunktioner som finns i biblioteket OpenSSL (version 0.9.8r).

Jag har använt ordlistan från OpenWalls lösenordsknäckare John The Ripper och behandlat varje enskilt ord som ett sepatat meddelande. För varje meddelande har jag beräknat ett hashvärde. Sedan har jag inverterat den första biten i varje ord och genererat ett nytt hashvärde. Sedan räknar jag alla bitar som växlat mellan de två värdena. Sedan gör jag detta för varje hashfunktion och beräknar statistik. Men närmare 4 miljoner ord i listan blir det många hashfunktionsoperationer.

Så här ser resultatet från körningarna ut:

Statistics for md5
Digest size in bits: 128
Number of words tested: 3917116
Min number of bits changed: 36
Min percentage of digest changed: 28.1
Max number of bits changed: 93
Max percentage of digest changed: 72.7
Average number of bits changed 64.0

Statistics for sha1
Digest size in bits: 160
Number of words tested: 3917116
Min number of bits changed: 49
Min percentage of digest changed: 30.6
Max number of bits changed: 112
Max percentage of digest changed: 70.0
Average number of bits changed 80.0

Statistics for sha224
Digest size in bits: 224
Number of words tested: 3917116
Min number of bits changed: 72
Min percentage of digest changed: 32.1
Max number of bits changed: 150
Max percentage of digest changed: 67.0
Average number of bits changed 112.0
Expected average: 896.0

Statistics for sha256
Digest size in bits: 256
Number of words tested: 3917116
Min number of bits changed: 89
Min percentage of digest changed: 34.8
Max number of bits changed: 171
Max percentage of digest changed: 66.8
Average number of bits changed 128.0

Statistics for sha384
Digest size in bits: 384
Number of words tested: 3917116
Min number of bits changed: 144
Min percentage of digest changed: 37.5
Max number of bits changed: 243
Max percentage of digest changed: 63.3
Average number of bits changed 192.0

Statistics for sha512
Digest size in bits: 512
Number of words tested: 3917116
Min number of bits changed: 201
Min percentage of digest changed: 39.3
Max number of bits changed: 316
Max percentage of digest changed: 61.7
Average number of bits changed 256.0

För samtliga testade hashfunktioner växlar i medelfallet hälften av alla bitar. Däremot är variansen för de äldre funktionerna SHA-1 och speciellt MD5 större än för SHA-2-funktionerna. Den snävare variansen för SHA-2 gör att det blir svårare att genom exempelvis sidoattacker försöka säga något om vilka meddelanden hashfunktionen bearbetar. Ingen av funktionerna ger med något av testmeddelandena en förvånande liten eller stor bitväxlingar.

Nästa steg är att testa finalisterna i NISTS SHA-3-tävling samt även jämföra med hashfunktioner som inte kryptografiskt säkra. Då bör vi se större varians och kanske även lite krockar.