Etikettarkiv: Forskning

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.

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.

Fysiker som bygger säkerhet kontra Intels Bull mountain

För några veckor sedan presenterade några fysiker en ny slumptalsgenerator baserad på kvantfenomen. Resultaten har fått viss uppmärksamhet.

Insamlingsutrustningen som används för att fånga kvantfenomenen.
Insamlingsutrustningen som används för att fånga kvantfenomenen.

Det är alltid spännande med nya forskningsresultat som ger oss insikt i hur vår verklighet fungerar. Jag gillar också att man försöker omvandla sina forskningsresultat till något som går att använda. Tyvärr kan jag utifrån ett säkerhetsperspektiv inte bli speciellt intresserad och imponerad. Skälet till detta är att jag återigen upplever att fysikerna tyvärr är blinda för det område de försöker applicera sina resultat. Det är inte första gången fysiker presenterar nya rön som man ser kan användas för krypto, säker kommunikation, eller som slumptalsgeneratorer. Det är i och för sig intressant och bra. Men problemet är att man ofta tror sig löst ett problem som inte längre är ett problem.

När det kommer till krypton och slumptalsgeneratorer har vi i dag lösningar som ger bra mycket skydd och hög prestanda/kapacitet till realistiska kostnader för väsentligen alla problem och användningsfall. Problemen är istället oftast att få till praktiskt fungerande implementationer, få till säker användning, hantera alla buggar, sidoattacker (inklusive social ingejörskonst) och rena misstag. Och för dessa enkla men viktiga problem är sällan rätt svar kvantfenomen som kräver masrar kylda med flytande väte för att fungera.

Tyvärr har fysikerna bakom den nya slumptalsgeneratorn dessutom fel i sak, vilket visar att dom inte kan applikationsomrepdet. Dom säger:

To date, most random number generators are based on computer algorithms. Although computer generated random numbers can be useful, knowing the input conditions to the algorithm will lead to predictable and reproducible output, thus making the numbers not truly random. To overcome this issue, random number generators relying on inherently random physical processes, such as radioactive decay and chaotic behaviour in circuits, have been developed.”

Detta är inte korrekt. Moderna slumptalsgeneratorer i operativsystem bygger inte på algoritmer som är deterministiska. Mer exakt – dom bygger inte bara på deterministiska algoritmer. Algoritm och fysiska slumpmässiga källor är inte ömsesidigt uteslutande. En modern slumptalsgenerator, som finns i alla operativsystem består grovt sett av två delar.

Den första delen är en eller flera entropikällor. Från entropikällorna samlas värden från slumpmässiga, fysiska händelser in. Exempel på entropikällor som används är tid mellan tangentbordstryckningar, skillnad i läshastighet från en hårddisk, digitala ringoscillatorer i chip eller termiskt brus i radiomottagare. Bra entropikällor ger många händelser/tidsenhet och är dessutom svåra eller helst omöjliga att manipulera. Kombinationen hög prestanda och tålig mot påverkan är svår att få till. Därför används ofta mer än en entropikälla och källorna övervakas för att detektera fel.

Den andra delen består ofta av en deterministisk algoritm – en psedudoslumpgenerator (PRNG). Oftast skapas PRNG:n genom att använda kryptografiska hashfunktioner som SHA-256, strömkrypton som RC4 eller Snow, eller blockkrypton som AES i en strömkryptomod som CTR. Den insamlade entropin anvönds för att initiera PRNGn. Efter att PRNG:n genererat ett visst antal värden startas PRNG:n om med nya värden från entropikällan. Ibland sker även en viss filtrering (whitening) mellan entropikällan och PRNG:n, detta för att ta bort värdemässiga vridningar (bias) så att de möjliga initieringsvärdena (ofta kallade frön) är så likafördelade som möjligt.

Kombinationen av flera entropikällor från vilka värden samlas in, och en bra, säker PRNG ger slumptalsgeneratorer som är tåliga mot störningar och med kapacitet att generera stora mängder slumptal med bra kvalitet. Ett bra exempel på detta är Intels nya slumptalsgenerator Bull Mountain som finns i Ivy Bridge-processorerna som släpptes igår 2012-04-23.

Bull Mountain har en entropikälla kapabel att generera flera Gbit/s i rådata. Rådatat filtreras med AES i CBC-mod. Värdena ut från filtreringen används sedan för att initiera en PRNG byggd med AES-CTR. Bull Mountain ger bättre prestanda än fysikernas generator, är kostnadseffektiv (i jämförelse med fysikernas lösning), drar lite ström, finns direkt tillgänglig för applikationer genom RdRand-instruktionen och kommer att finnas i miljontals med datorer, laptops och prylar inom ett par år.

Ivy Bridge-core
Intels Ivy Bridge-processor. De fyra processorkärnorna delar på en Bull Mountain-generator.

Ett annat bra exempel är slumptalsgeneratorn i Yubicos YubiHSM som har två olika entropikällor vilka matar en PRNG byggd med AES. Allt förpackat i en billig och enkel USB-sticka, vilket gör den lätt att integrera.

YubiHSM intui en server.
YubiHSM monterad i en server.

Intels Bull Mountain/RdRand och YubiHSM tycker jag är mycket, mycket mer spännande och viktigare ur ett användbart säkerhetsperspektiv än fysikernas labbutrustning.


Entropikällan i den nya generatorn.

(Fysikerna säger att den nya källan inte går att manipulera. Men jag fungerar på hur svårt det är att störa källan, ex med en annan laser. Även om kvantfenomenet i sig inte går att manipulera är sensorn ofta det som attackeras.)

Och till sist kan jag inte låta bli att sucka lite över hur fysikerna försöker få ut sin nya fina slumptalsgenerartor. Ja, det är jättefint att det finns ett JSON API (Github-projekt som pratar med generartorn), eller att jag kan gå och få några byte data genererat på webbsidan (som är seg). Men det finns ingen som helst säkerhet kopplad till API:t eller webbsidan.

Själva poängen med en bra slumptalsgenerator är ju att du ska kunna lita på den. Om generatorn sitter inuti min processor är det lättare att lita på den än om den befinner sig i Australien och att datat skickas utan något som helst skydd mot manipulation, äkthetskontroll eller avlyssning.

Presentationer från NISTS sista SHA-3-konferens

I slutet av mars anordnade NIST den sista SHA-3-konferensen. Målet med konferensen var att få in så mycket information som möjligt om finalisterna inför NISTs beslut om vilken algoritm som kommer att blir den nya hashfunktionen SHA-3. NIST har en sida för konferensen och där finns nu alla presentationer och artiklar som presenterades.

Det finns ett flertal intressanta presentationer om implementationer, både i hårdvara och i program. För högpresterande hårdvaruimplementationer i FPGA och ASIC ser finalisten Keccak ut att vara överlägsen, både i ren råprestanda och prestanda viktad mot kostnad. På senaste generationer av CPU:er ser dock BLAKE att vara överlägsen rent prestandamässigt.

För små, inbyggda system ser Gröstl och Blake att ge minimala implementationer med där Keccak återigen ger bäst prestanda viktad mot kostnad. Det finns även intressanta resultat vad gäller sidottacker på implementationer och säkerhetsanalyser av algoritmerna.

På konferensen ställde även NIST frågan till deltagarna om vilka kandidater de föredrar genom att humma. Skaparen av BLAKE, JP Aumasson rapporterde resultatet:

Top: Keccak, then BLAKE. Deafening silence: Skein. Ouch.

När skaparna av finalisterna fick frågan vilken algoritm förutom sin egen de föredrog blev resultatet:

  • Skein -> BLAKE
  • Groestl -> JH
  • JH -> Keccak
  • BLAKE -> Skein
  • Keccak -> Groestl

Om man jämför med humm-frågan ser det ut att vara rätt mycket taktik i de valen.

IETF 83 några dagar efter SHA-3-konferensen höll NIST en mycket intressant presentation om SHA-3 (länken pekar på PPT-fil). För att få en känsla av hur NIST resonerar är den här presentationen väl värd att bläddra igenom. I presentationen pekar man ut att SHA-3 inte kommer att ersätta SHA-2, inte minst då SHA-3 knappast kommer att ge mycket bättre prestanda. NIST ser att SHA-2 är effektiv, inte minst i inbyggda system. Däremot kommer SHA-3 att kunna ge mycket högre prestanda för hashbaserade meddelandekoder (MAC). NIST påpekar även i sin presentation att det analysarbete av kryptografiska hashfunktioner som bedrivits sedan 2005 gör att man i dag är mindre orolig för säkerheten hos SHA-256 och andra SHA-2-algoritmer. NIST ber i sin presentation IETF om synpunkter på hur hashfunktioner bör anpassas för olika protokoll och miljöer, detta för att ta med dessa synpunkter i sitt val av vinnande algoritm.

För den som vill bidra till SHA-3-processen vill NIST få in detta innan den första juni. Sedan är det dags för NIST-juryn att överlägga och berätta vem som är vinnare. (Inte säker på att SHA-3-överläggningen skulle göra sig lika bra i TV som Project Runway.). Enligt NIST kommer vinnaren att utses i slutet av året.

Har du information du anser att NIST bör ta med i sin bedömning är det dags att agera. Sedan blir det spännande att sätta tänderna i den nya, fräscha SHA-3. Nästan som en julklapp.

Knäckta satellitkrypton och hemliga algoritmer

Ars Technica skriver om hur forskare i Tyskland lyckats knäcka krypton som används vid satellitkommunikation.

Satellitkommunikation

Eftersom signalen från en satellit täcker så stora ytor är det enkelt att fånga in signalen. För att skydda samtal från avlyssning krävs därför ett bra konfidentialitetsskydd – ett bra krypto.

Det är den internationella standardriseringsorganisationen ETSI som specificerat både kryptona GMR-1 och GMR-2 kryptona samt hur dom ska användas. Hur dom ska användas är öppen information, men själva kryptona är hemliga. ETSI skriver i sin specifikation (pdf):

The internal specification of algorithm A5-GMR-1 is managed under the responsibility of the GSC; it will be made available in response to an appropriate request

Att algoritmerna är hemliga hindrade dock inte forskarna. Genom hacka sönder uppdateringsfiler av programvaran till telefoner samt genom att analysera trafiken vid användande av satellittelefoner från Thuraya och Inmarsat kunde forskarna räkna ut hur algoritmerna fungerar.

Forskarnas analys visar att det skydd kryptona ger är så svagt att det finns en klar risk att satellitbaserad trafik inklusive samtal går att avlyssna. I artikeln Don’t Trust Satellite Phones: A Security Analysis of Two Satphone Standards skriver forskarna:

In this paper, we analyze the encryption systems used in the two existing (and competing) satphone standards, GMR-1 and GMR-2.

We were able to adopt known A5/2 ciphertext-only attacks to the GMR-1 algorithm with an average case complexity of 2**32 steps. With respect to the GMR-2 cipher, we developed a new attack which is powerful in a known-plaintext setting. In this situation, the encryption key for one session, i.e., one phone call, can be ecovered with approximately 50–65 bytes of key stream and a moderate computational complexity.

A major finding of our work is that the stream ciphers of the two existing satellite phone systems are considerably weaker than what is state-of-the-art in symmetric cryptography.

(På forskarnas egna webbplats finns mycket mer information.)

Forskarnas bedömning är att eftersom det skulle kosta så mycket att byta algoritmer kommer dessa inte att ändras. Istället rekommendrar dom att betrakta kommunikationen som öppen och sedan komplettera med ytterligare lager av skydd. Tyvärr kostar dessa extraskydd kapacitet i en förbindelse som redan har ganska begränsad kapacitet. Dessutom kan dessa skydd införa ökad fördröjning och andra trafikala problem. Inmarsat, som även är operatör av satellitkommuninkation har över än så länge inte kommenterat eller gett några officiella råd till sina kunder.

Tyvärr är detta inte första gången ett hemligt krypto visat sig vara svagt och långt ifrån vad man kan förvänta sig av ett krypto som används i befintliga system. I smarta kort av MiFare Classic-typ, som bland annat används för betalning i publika transportsystem i Göteborg och Stockholm, finns ett hemligt krypto kallat Crypto-1. Trots att kryptot var hemligt lyckades forskare klura ut både hur kryptot fungerar, och att dess säkerhet var i stort noll.

Keeloq är ett krypto som används i elektroniska bilnycklar av i stort sett samtliga stora biltillverkare. Även detta krypto var hemligt och även här lyckades forskare räkna ut hur det fungerar samt visa på kryptots monumentala brister.

För ETSI är forskarnas nya resultat ännu ett misslyckande. Deras kryptostandarder för DECT, GSM, 3G och satellitkommunikation har alla visat sig ha stora brister. När det kommer till kryptoalgoritmer är det frågan om ETSI lever upp till sin devis World Class Standards.

Att hålla informationen om vilka kryptografiska algoritmer du använder hemliga är inte ett problem. Du kan helt enkelt strunta att berätta det. Problemet är om säkerheten hos ditt system beror av att denna information är hemlig.

Information som om den kommer ut kan skada din verksamhet ställer krav på skydd som kostar pengar. Du behöver införa mekanismer och metoder för att begränsa tillgången. Skyddet behöver dessutom övervakas så att du vet att det faktiskt fungerar.

Dessutom bör du ta fram en plan för hur du ska agera om informationen trots allt kommer ut. När hemligheten kommit ut måste den troligen bytas ut, alternativt att du måste kasta in handduken och införa andra skyddsåtgärder så som forskarna nu föreslår att användare av satellitkommunikation bör göra. Att byta algoritm kan bli väldigt kostsamt. Är det en algoritm som används i inbyggda system som tillverkas i stora volymer, används i fält och har lång livslängd är innebär bytet eventuellt att du måste byta ut hela systemet.

Hade din hemlighet istället bara varit en kryptonyckel hade bytet troligen handlat om att byta ut en sträng på 16, 32, 64 tecken eller liknande. Säkerheten sitter i nyckeln. Den är allt du egentligen ska behöva skydda.

Bra kryptoalgoritmer försvagas inte av att informationen om hur dom fungerar är känd. Tvärt om beror vår tillit på algoritmerna just av öppenheten. Algoritmen som utgör blockkryptot AES undersöktes ett stort antal gånger på olika sätt innan den accepterades som standard. Och AES fortstt under kontinuerlig undersökning. Det finns generationer av forskare som fixat sin hatt eller årets publiceringar genom att försöka hitta på nya sätt att vara elak mot AES.

Ju fler undersökningar som en algoritm står emot desto större tillit vågar vi sätta till den. Och det är öppenheten, tillgängligheten som gör dessa undersökningar möjliga.

I jämförelse med en öppen algoritm undersöks en hemlig algoritm mer sällan. Dessutom sker undersökningen oftast under en begränsad tid. När en hemlig algoritm bedömts som säker tas den i bruk och sedan sker sällan omvärdering av algoritmens säkerhet.

Det finns användare av hemliga algoritmer som vet vad dom gör, som har den spetskompetens som krävs att göra en bra bedömning. Men när erkända kryptoforskare som medlemmarna i ETSIs säkerhetsgrupp SAGE gör fel och försvagar snarare än förstärker en algoritm (som är fallet med KASUMI, byggt på MISTY-1) är det inte självklart att även en enskild grupp med aldrig så skarpa experter gör en bra bedömning. Den mekanism som har störst chans att ge bra algoritmer är öppna processer med många, oberoende tester över lång tid. Att skynda långsamt och kontinuerligt ompröva resultat.

AES togs fram genom en sådan process, strömkryptona i eSTREAM togs fram genom en sådan process och kommande hashfunktionen SHA-3 tas fram på detta sätt. Det finns inga garantier att detta ger säkra algoritmer, det visar bland annat eSTREAM där några krypton i dag är knäckta. Men detta är den bästa metod vi har i dag och det är en process som förbättras för varje iteration.

Även ETSI verkar till slut ha lärt sig av alla sina misstag och i arbetet med den senaste standarden ZUC har det faktiskt organiserats seminarier, workshops, diskussionsforum på nätet och varit en mycket mer öppen process (även om det finns mindre öppna designval även i ZUC).

Om du oroar dig för att någon ska veta hur ditt system fungerar så strunta att berätta vilket krypto du använder. Men hitta inte på egna algoritmer, utan använd öppna, etablerade standarder som stått emot granskning under lång tid. Gör du det är nyckeln till kostnadseffektiv,fungerande säkerhet din kryptonyckel.

Kollision hittad i MD5-meddelande

(Uppdaterad 2012-01-03 med korrektur)

2010 publicerade säkerhetsforskarna Tao Xie och Dengguo Feng en artikel om att de funnit en kollision hos hasfunktionen MD5 mellan två meddelanden som bara är ett block stort.

En kollision innebär att två olika meddelanden ner dom används som indata till en hashfunktion ger samma hashvärde. MD5, precis som andra kryptografiska hashfunktioner delar upp ett meddelande i ett antal block med en fix storlek. För MD5 är blockstorleken 512 bitar. Innan Xie och Fengs artikel hade det presenterats kollisioner för meddelanden som är större än ett block. Detta är enklare då det ger utrymme för att bygga på ett meddelande med bitmönster som gör att en kollision uppstår. Men för ett meddelande som är exakt ett block finns inte den möjligheten. En kollision på ett block kräver att hashfunktionens förmåga att skydda mot att räkna ut indata från ett givet hashvärde har brutits. Hashfunktionen är inte längre en evägsfunktion.

Xie och Feng presenterade i sin artikel två meddelanden på exakt 512 bitar som gav samma hashvärde:

Xie och Fengs kollision från 2010
Xie och Fengs kollision från 2010

Det Xie och Feng däremot inte gjorde var att berätta hur dom lyckats skapa sin kollision. Författarna hänvisar till att dom av säkerhetsskäl stoppats från att berätta hur dom gjort. Dom skriver:

Today, in the last month (Dec,) of 2010, we have to make public a result of our 1-block collision attacks on MD5 in Table 1 as below, which was actually
obtained at the beginning of 2010, but for security reasons, the techniques are not allowed to be disclosed at the moment.

Intressant nog utmanar istället Xie och Feng sina kollegor i världen att återskapa deras resultat genom att hitta ett annat par av meddelanden ned en storlek på ett block som ger en kollision i MD5:

Here, we are calling for a challenge to the cryptology community that, any one who first gives a new different 1-block collision attack on MD5 will win 10,000 US dollars (about 50,000 RMB in Chinese Yuan) as a reward for his (her) excellent work. This call for challenge will be ended on Jan 1st, 2013. This announcement’s first affiliated unit will be responsible for this amount of reward when a new different 1-block collision attack is received and verified.

Det som hänt nu är att Marc Stevens ser ut att vara den första att möta utmaningen. I en artikel publicerad 29 januari i 2012 presenterar Marc sina meddelanden och den kollision som detta ger:

Marc Stevens meddelanden som ger kollision i MD5
Marc Stevens meddelanden som ger kollision i MD5

Det första man kan lägga märke till är att det är andra meddelanden är de Xie och Feng använt. Notera även att det är två ställen i meddelandena som skiljer. I den första av dessa bytes är det bit två som växlat, 0x00 har blivit 0x02. I den andra byten är det bit åtta som växlat, 0x55 har blivit 0xd5.

Till skillnad från Xie och Feng tvekar inte Marc att berätta hur han gjort och i artikeln finns en redovisning av såväl bakomliggande teori och mekanismer samt den algoritm som Marc använt för att utföra sökningen av kollisionen. Enligt Marc skulle det med hans nya metod krävas 2**49.81, dvs ungefär 987 biljoner MD5-operationer för att hitta en kollision. Marc skattade att detta skulle ta maximalt fem veckors körtid, vilket innebär at han räknade med att kunna göra drygt 300 miljoner MD5-operationer per sekund. Detta var tillräckligt lite tid för att Marc skulle bedöma det som rimligt och startade därför sökningen. Med lite tur fick han träff efter tre veckor.

Skälet till att Marc lyckades och att MD5 är så svag är att lavineffekten hos MD5 är för svag och ojämnt fördelad över bitarna i det genererade hashvärdet. Lavineffekten innebär att en liten förändring av indata snabbt ska påverka många bitar i interntillståndet som i slutändan ger hashvärdet. Eller omvänt, varje bit i det genererade hashvärdet ska bero av många bitar i meddelandet. I fallet att meddelandet är lika stort som hashfunktionen innebär detta att varje bit i hashvärdet ska bero av många bitar i blocket. Tyvärr gäller inte detta för MD5. På grund av att den har så få iterationer sker inte en bra och jämn mixning. Vissa bitar i hashvärdet hos MD5 beror av väldigt få bitar. Detta kallas för en hashtunnel, ett begrepp och fenomen Vlastimil Klima presenterade 2006. Skillnaden i hur lavineffekten förklarar även den större varians jag fick för MD5 när jag gjorde bittester av hashfunktioner.

För den som själv vill pröva på att generera kollisioner hos meddelanden på enstaka block hos MD5 har Marc släppt ett program. Källkoden har Marc ännu inte släppts. Men koden, programmet, artikeln, meddelandena etc finns på Marcs egen sida.

Så vad är kontentan? Det första är att Xie och Fengs tävling har avgjorts och att Marc Stevens är att gratulera till ett bra utfört arbete. Förhoppningsvis får nu Xie och Feng chans att publicera information om hur dom gick tillväga. Att tvinga dom att hålla sin metod hemlig gav ett knappt års fördröjning av en publicerad metod. Att hemlighålla information om svagheter som ändå redan är kända har återigen visat sig inte vara en långsiktigt hållbar. Och någon får dessutom betala 10.000 USD.

För oss alla andra är väl detta bara ännu ett bevis på att MD5 inte skall användas och bör fasas ut till förmån för bättre hashfunktioner (exempelvis SHA-256). SHA-256 har inte bara fler iterationer och en bättre mixningsfunktion, den har även ett hashvärde på fler bitar – 256 bitar gentemot 128 bitar för MD5. Hashvärdet för MD5 är i dag så kort att det är inom gränsen för att praktiskt göra uttömmande sökningar och bygga upp tabeller med meddelanden och deras hashvärden, så kallade regnbågstabeller.

10000 industriella kontrollsystem kopplade till Internet

Ett argument som ofta framförs när det gäller säkerhet för industriella kontrollsystem (på engelska ofta kallade ICS och SCADA) är att det inte finns några riktiga problem, detta för att systemen är isolerade och inte är kopplade till externa nätverk – exempelvis till Internet. Populära isolerande skyddmetoder är så kallade luftgap (på engelska air gap) samt datadioder. Med luftgap avses att det inte finns någon elektrisk förbindelse mellan kontrollsystemets nätverk och andra nätverk. Med datadioder avses mekanismer som gör att  trafiken i nätverket bara kan flöda åt ett håll.

Datadiod

Figuren visar hur en datadiod är tänkt att figuren. Notera att figuren egentligen är åt fel håll. Detta för att datadioder används för att isolera system som hanterar känslig information och där vill man inte att information ska läcka ut. I ett kontrollsystem är det oftast precis tvärt om som är intressant. Det går att skicka över mätdata från kontrollsystemet, men det går inte att skicka styrkommandon till kontrollsystemet. Leverantörer av industriella säkerhetssystem kräver ofta att deras utrustning ska skyddas genom isolering. Men hur fungerar det i verkligheten, och är detta egentligen bra och robusta metoder att hantera säkerhetsproblem?

Wireds säkerhetsblogg Threat Level rapporterar om resultat som säkerhetsforskaren Eireann P. Leverett nyligen presenterade som visar att det finns industriella kontrollsystem kopplade till Internet, mer exakt har Leverett hittat fler än 10000 stycken! Genom att använda nätverksscannern Shodan har Leverett letat efter kända industriella ontrollsystem, och även kunnat identifiera vilka versioner av system som används. Leverett har sedan mappat dessa i en fin graf över världen som visar var systemet finns:

Everetts graf som visar var olika industriella kontrollsystem finns och deras svagheter.
ICS med versioner och dess svagheter.

Av de system Everett hittade visade sig bara 17% över huvud taget använda någon form av enklare accesskontroll, exempelvis lösenord! Undersökningen är en del av den avhandling Everett arbetat med och för den som vill veta mer om Everetts undersökning finns hans avhandling Quantitatively Assessing and Visualising Industrial System Attack Surfaces hos Wired.

Jag anser att resultaten Everett presenterat visar att bara använda isolering som enda säkerhetsmetod för sitt industriella kontrollsystem inte ger ett adekvat skydd. I stora, komplexa kontrollsystem med tusentals mät- och styrnoder finns det stor risk att effektivisering, krav på snabb problemlösning, underhåll utfört av tredje part eller misstag leder till att hela eller delar av systemet kan exponeras mot omvärlden under kortare eller längre tid. Någon kopplar in ett GSM-router för att kunna övervaka en nod som sitter taskigt till rent fysiskt. En leverantör behöver möjlighet att få diagnostik. En del av systemet kopplas temporärt in på kontorsnätet. I dag är det inte heller nyfikna personer som sitter och för hand letar efter märkliga maskiner på Internet. Istället är det robotar, automatiska scannerverktyg som Shodan som periodiskt scannar av Internet. Risken att det exponerade systemet blir upptäckt är därför mycket större än man kanske tror.

Istället bör man räkna med att sitt industriella kontrollsystem kommer att kunna exponeras på olika sätt och börja ställa krav på säkerheten hos de noder och maskiner som är inkopplade i nätet. Att använda isolering är bra, men det bör kompletteras med säkerhet på djupet. Och om det nu finns kommunikationskanaler ut ska dom självklart använda vettiga autenticeringsmekanismer. Att 87% av de system Everett hittade inte ens har lösenordsskydd är väldigt skrämmande.

För den som ändå tror på isolering som fungerande metod bör studera Stuxnet-attacken. Där var kontrollsystemet isolerat. Men det som inträffade var att någon, avsiktligt eller oavsiktligt kopplade in ett USB-minne eller laptop och därmed infekterade systemen innanför luftgapet. Att tekniker tar med sig mätverktyg, laptops när dom ska lösa problem och kopplar in dessa i systemet borde knappast vara otänkbart scenario. Självklart ska det ställas krav på utrustningen som kopplas in, exempelvis uppdaterat virusskydd, men säkerheten måste även finnas inne i kontrollsystemet.

sphlib 3.0

För ett tag sedan släpptes version tre av biblioteket sphlib. Sphlib implementerar samtliga finalister samt flera av de tidigare kandidaterna till hashfunktionstävlingen för att få fram hashfunktionen SHA-3. Om man vill börja underrsöka och testa SHA-3-algoritmer är sphlib trevlig att arbeta med.

Sphlib ger inte maximal prestanda och har därför fått kritik för att kanske inte ge en perfekt bild av vad de olika kandidaterna kan åstadkomma. För den som vill se den typen av resultat finns EBASH-projektet att titta på. Men för den som inte är ute efter prestanda, utan titta på funktion, struktur etc är sphlib bra.

Workshop om lättviktskrypton

Det finns i dag en stark trend mot att allt fler saker runt omkring oss kopplas upp till Internet – Dörrar, kylskåp, båtmotorer, dunjackor, värmeväxlare, plankor på byggvaruhuset, glödlampor, termostater, kranar etc. Allt annat än fräcka och och sexiga saker – men viktiga för att vårt samhälle ska funger och med stor potential till effektivisering när sakerna får digital intelligens och kan börja kommunicera.

För att detta Internet of Things (IoT) ska fungera måste vi kunna säkert identifiera sakerna och utbyta information – kommandon och status med dessa saker. I vissa fall krävs även att kommunikationen är hemlig för alla utom de som har rätt att kommunicera med en given sak – men det är inte lika viktigt. Detta ställer krav på att det finns säkerhetsmekanismer i IoT-sakerna. (Jag har tidigare skrivit om behovet av säkerhetsmekanismer anpassade för IoT). ECRYPT II-Workshopen ECRYPT Workshop on Lightweight Cryptography som anordnades i slutet av november med målsättningen att presentera nya säkerhetslösningar för små, inbyggda system är därför klart relevant och intressant.

Att döma av programmet (pdf) sker det aktiv utveckling av både kompakta symmetriska krypton och hashfunktioner. Oftast är det hårdvaruimplementationer där man mäter antalet grindar (generaliserad till antalet NAND2-grindar) och energiförbrukningen. Ett exempel är blockkryptot Piccolo-128 som bara kräver 60% av storleken hos den minsta implementation av AES-128 som tidigare presenterats. Dock med en prestanda på 40% av AES.

Det jag tycker är mer intressant är presentationen av resultaten från implementationer av 12 standardkrypton (IDEA, DES, AES, KASUMI, TEA m.fl.) på Atmels ATtiny45-processor. Detta är en minimal (även fysiskt) 8-bitars processor med 4 kByte FLASH-minne, 256 Byte EEPROM och 256 Byte SRAM. Det finns inte mycket detaljer om hur implementationerna är uppbyggda, men att döma av det som presenterades lyckades dom implementera alla 12 algoritmer.

Atmel ATtiny45.
En näve ATmel ATtiny45-kretsar.

Et annat arbete som presenterades är försök att implementera autenticerande kryptomoderTexas Instruments processor MSP430. De moder man arbetat med är CCM, GCM, SGCM, OCB3 och Hummingbird-2. Detta är ett i mina tycken klart intressant. Att få konfidentialitet och autenticering samtidigt ger en mer kompakt lösning än separata algoritmer.

Det presenterades även förslag till autenticerat broadcast-protokoll för industribussen CAN samt försök att implementera AES på en 4-bitarsprocessor(!).

Det jag däremot saknar är nya, lättviktiga asymmetriska algoritmer samt försök att befintliga asymmetriska algoritmer. Det spelar ingen roll om vi har högar med blockkrypton anpassade för små processorer om vi inte kan göra bra nyckelutbyten. En bra minimal implementation av ett vältestat krypto som AES (gärna som stödfunktion i processorns hårdvara), en autenticerande kryptomod samt en nyckelutbyte är mycket mer intressant än ännu ett blockkrypto eller hashfunktion.

För den som vill läsa de artiklar som presenterades finns dom samlade i proceedings för konferensen och går att ladda ner (pdf).

En sista sak. ECRYPT II har även en webbplats, ECRYPT Lightweight Cryptography Lounge där information om kryptolösningar för kompakta, begränsade samlas. Är du intresserad så ta en titt där – det gör jag.

Uppdaterad ECRYPT II-rapport om algoritmer och nyckellängder

ECRYPT II har äntligen publicerat den uppdaterade versionen av sitt dokument ECRYPT II Yearly Report on Algorithms and Keysizes (pdf). (Dokumentet var färdigt i juni, men har publicerats först nu.)

Ecrypt II

Jag anser att detta dokument ger en bra vägledning om var vi står forskningsmässigt vad gäller olika algoritmer, styrkan hos nycklar för olika typer av algoritmer samt ger rekommendationer om minimum nyckellängder att använda. Det jag skulle vilja se är en sammanfattning som listar dom stora skillnaderna gentemot förra årets version. Vad har ändrats och varför. Symmetriska och asymmetriska algoritmer, blockmoder, nycklar, protokoll. Allt finns samlat i ett dokument vilket gör det lätt att få grepp om nuläget.

Om du arbetar med säkerhetsfunktioner på något sätt – kravställning, systemdesign, säkerhetspolicy, design och/eller implementation, tes/verifiering etc är detta ett dokument väl värt att läsa igenom.