Kategoriarkiv: Internet

Bruce Schneier om faran med NSAs bakdörrar

Bruce Schneier har skrivit en mycket bra krönika om faran med att NSA (och andra myndigheter) letar efter svagheter i civila system i avsikt att kunna hacka systemet samt tvinga in bakdörrar i civila system. Artikeln formulerar mycket bra det som gör mig och många andra i säkerhetsbranschen så upprörda. Agerandet bryter inte bara den upparbetade metod för att hitta och eliminera svagheter som finns, utan gör det civila samhället svagare.

Wired gräver efter Bitcoins med hårdvara

(Uppdaterad med länk till artikel om KNCminer.)

I en kommentar till en tidigare postning om bitcoins pekade Robert Andersson på en artikel hos Wired. Wired testar just nu en dedikerad Bitcoin-grävare från Butterfly Labs.

Butterfly Labs Bitcoin-grävare
Butterfly Labs Bitcoin-grävare. En snygg liten maskin.

I artikeln sätter Wired fingret på ett viktigt fenomen med Bitcoin – att det blir svårare och svårare att gräva efter bitcoins. I början räckte det med en vanlig dator. I dag krävs det massiva system av datorer, helst utrustade med kraftiga grafikprocessorer.

Därmed går kostnaden för att gräva upp – både att anskaffa utrustningen och att driva utrustningen, i första hand energiförbrukning. Ett sätt att minska den rörliga kostnaden är att använda allt mer effektiv, dvs specialiserad hårdvara. Det finns i dag både FPGA- och ASIC-baserade bitcoingrävare (Wireds maskin från Butterfly Labs är en sådan maskin). Gizmodo har en artikel som visar lite hur Bitcoin-utrustningen har utvecklats på några få år. Den här gamla utrustningen är inte längre speciellt konkurrenskraftig:

Galet stor Bitcoinmaskin
En system för att gräva Bitcoins som borde ge sysadmin magsår.

Några som håller på och utvecklar FPGA-baserade bitcoingrävare är svenska KnCMiner. Daniel Goldberg och Linus Larsson har skrivit en mycket intressant om KnCMiner och deras maskiner.

Men vad göra för att vara mer effektiv än system med specialiserade Bitcoin ASIC:ar? Lägga kostnaden på någon annan. Tyvärr börjar det dyka upp flera tecken på att Botnets används även för att gräva efter Bitcoins. Tidigare i år fick ett Botnet kallat ZeroAccess gräver efter Bitcoins med hjälp kapade datorer. En synnerligen tråkig om än egentligen inte oväntad utveckling med Bitcoins.

Sedan påpekar Wired och Robert att hela systemet med Bitcoins bygger på säkerheten hos hashfunktionen SHA-256. Och så är det, om vi snabbt kan forcera SHA-256 kommer Bitcoin-systemet att kollapsa. Men då har vi troligen större problem med den digitala säkerheten i vårt samhälle och på Internet än att en digital valuta faller samman.

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.

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.

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?

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.

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.

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.

MSB rapporterar trenderna inom informationssäkerhet 2012

MSB – Myndigheten för samhällsskydd och beredskap har gett ut en trendrapport – samhällets informationssäkerhet 2012. Rapporten tittar på olika trender inom användning av IT-system samt olika typer av IT-problem och hur användningen och problemen tillsammans påverkar samhället.

En trend rapporten uppmärksammar är ökad mobilitet i form av smartphones och hur personer och organisationer i allt högre grad använder smarta mobiler och surfplattor både privat och i jobbet. Bring Your Own Devices – att använda sina privata ställer kan ge nya typer av problem och ställer nya krav på hur organisationer hanterar sin information och sina IT-system.

En annan stor trend (som dock pågått längre tid) är mot ökad centralisering och outsourcing av IT-drift och att använda IT-funktioner i verksamheten som inte bygger på lokalt installerade program, utan är tjänster placerade någon helt annan stans i världen med åtkomst via Internet. Ett exempel på detta (som dock inte rapporten pekar på) är Salems kommun som övergick till att använda Google Apps, vilket Datainspektionen såg bröt mot lagen.

MSBs rapport tar även upp saker som spam (som minskat rejält), ökad mängd trojaner, hur IT för tekniska system och industrisystem växer, den ökande användningen av sociala medier även inom offentlig förvaltning. Rapporten innehåller även några fallbeskrivningar inklusive en reflektion över vad fallen innebär trendmässigt.

Är du intresserad av informationssäkerhet och inte minst hur IT-användning och informationssäkerhet påverkar samhällets utveckling är MSBs rapport väl värd att lägga en stund på att läsa.

Testa lösenord via Twitter

Twitter är på många sätt en fantastisk tjänst. En av de bättre är hur enkelt det är att via Twitters programmeringsgränssnitt koppla program och maskiner som kan lyssna på tweets, skicka status och reagera på kommandon.

En sådan tjänst är Hash Cracking Robot. Detta är en tjänst som lyssnar på tweets riktade till sig som innehåller ett kryptografiskt kondensat skapat med olika typer av algoritmer såsom MD5, SHA-1, RIPEMD-160, WHIRLPOOL m.m.

Så här ser det ut när jag testar tjänsten genom att generera kondensat med MD5 för två olika strängar med OpenSSL.

Strängar för test av PlzCrack
Strängar för test av PlzCrack

Sedan postar jag strängarna riktade till @PlzCrack på Twitter (notera att postningarna är i omvändning ordning.):

Test av hashknäckning med Twitter
Test av hashknäckning med Twitter

Lägg märke till vad som händer. PlzCrack svarar mycket snabbt. Men det är bara strängar den känner till den kan knäcka rapportera. Egentligen är tjänsten en Twitterkoppling till regnbågstabeller. Detta innebär att det bara är strängar den känner till och har kondensat för som den kan hitta. Att skicka något till PlzCrack startar inte ett automatiskt försök att uttömmande söka efter en sträng som ger kondensatet, utan det är ren uppslagning i en tabell.

Twitter begränsar hur många tweets man kan göra inom en viss tidsperiod så att använda tjänsten för att testa en stor mängd kondensat går inte. Tjänsten är mer skoj och har nog ett rätt begränsat värde, men en fördel med PlzCrack är att du slipper att själv ha gigantiska regnbågstabeller eller att generera dessa tabeller. Sedan kan man fundera på hur bra det är att på ett bublikt forum leta efter strängar till kondensat…