Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1291
May » 2010 » Kryptoblog

Archive for May, 2010

Hackers Wanted – nu på Internet

May 21st, 2010

Wired skriver att filmen Hackers Wanted har smitit ut på nätet.

Hackers Wanted (2008) from hannah commodore on Vimeo.

Filmen är en dokumentär från 2003 om hackaren Adrian Lamo (kallad The Homeless Hacker), som bland annat tog sig in i New York Times datasystem – vilket han blev dömd för 2004.

Adrian Lamo från en arresteringsbild.
Adrian Lamo – från tiden som efterlyst.

Wired har även en annan historia om Adrian Lamo och hur han nyligen blivit tvångsomhändertagen för att han har Aspergers syndrom.

Adrian Lamo idag, hemma.

Två artiklar om så kallad kvantkryptering

May 18th, 2010

Idag publicerade CSO två artiklar som båda på olika sätt handlar om så kallad kvantkryptering där jag fick chans att uttala mig (göra bort mig).

Nytt krypto fungerar bara där du förväntas vara tar upp ett iofs intressant fenomen där det går att koppla ett visst kvantfenomen till en given position. Idén är att använda detta för att skapa ett nyckelutbyte mellan två parter och att detta därmed skulle öka säkerheten. Jag tycker att det är ett intressant forskningsresultat, men har svårt att se den praktiska nyttan med tekniken.

Kommersiell kvantkrypterare knäckt handlar om hur några forskare lyckats attackera ett befintligt system för kvantbaserad kommunikation. Jag tycker att artikeln visar att kvantkryptering inte är den perfekta säkra kommunikationslösningen som kommer att stoppa alla attacker. Som vi sett tidigare (tack för tipset, Måns) har andra sedan tidigare (på C26C3) presenterat fungerande avlyssning på den här typen av system.

Och, jag är rätt allergisk mot begreppet kvantkryptering. Det må vara en metod för att kommunicera konfidentiellt genom att kvantkommunikationen störs om någon försöker avlyssna. Men det är inte en krypteringsmetod där en delad hemlighet används för att transformera meddelandet på ett sådant sätt att ingen utomstående kan förstå meddelandet. Det senare är vad iaf uppfattar som betydelsen av kryptering.

Busiga säkerhetsfrågor

May 14th, 2010

Bruce Schneier postade för några dagar sedan om att hitta på bus med säkerhetsfrågor – den typ av frågor man måste ge ett svar på för att sedan kunna användas för att autenticera sig om det skulle behövas. Några av Schneiers förslag på frågor och svar är:

Q: Do you know why I think you’re so sexy?
A: Probably because you’re totally in love with me.

Q: Need any weed? Grass? Kind bud? Shrooms?
A: No thanks hippie, I’d just like to do some banking.

Q: The Penis shoots Seeds, and makes new Life to poison the Earth with a plague of men.
A: Go forth, and kill. Zardoz has spoken.

Q: What the hell is your fucking problem, sir?
A: This is completely inappropriate and I’d like to speak to your supervisor.

Q: I’ve been embezzling hundreds of thousands of dollars from my employer, and I don’t care who knows it.
A: It’s a good thing they’re recording this call, because I’m going to have to report you.

Q: Are you really who you say you are?
A: No, I am a Russian identity thief.

Naturligtvis hakar en massa läsare på och kommentarerna till Schneiers postning innehåller en del riktigt roliga – och en del riktigt bra frågor. För själva poängen är att om dessa frågor och svar skall vara bra säkerhetsmässigt skall dom inte vara enkla att gissa.

Naturligtvis var det mer än en som kom på att man skulle kunna använda dessa frågor som ett sätt att försöka attackera en tjänst, detta då det man matar in antagligen skickas rätt in i en databas. En som redan tänkt i dessa banor är Randall Munroe, skaparen av serien XKCD:
XKCD - Litte Bobby Tables.

Men nu visar det sig att detta antagligen hänt i verkligheten. BoingBoing har en postning om att banken The Sacramento Credit Union har följande information om vad som gäller för hemliga fraser:

The answers to your Security Questions are case sensitive and cannot contain special characters like an apostrophe, or the words “insert,” “delete,” “drop,” “update,” “null,” or “select.”

Gissningsvis har dom lärt sig detta den hårda vägen…

Phonekey – phoney säkerhet

May 13th, 2010

(Tipstack till Jakob.)

Computer Sweden skriver om Phonekey, ett svenskt företag som har en ny säkerhetslösning.

Enligt artikeln fungerar Phonekeys säkerhetslösning så här:

Tekniken innebär att du måste ringa ett speciellt nummer från din telefon innan det går att använda ditt betalkort, logga in på ditt konto på den sociala nätverkssajten eller komma åt någon annan tjänst som använder sig av det hänglås Phonekey innebär.

– Tekniken säkrar enkelt all korthantering och inloggning, säger Tonie Söderström, mannen bakom tekniken och en av grundarna.

Det företag som vill använda säkerhetsmekanismen installerar Phonekeys mjukvara på en server, låter användarna registrera sina telefonnummer och ger sedan användarna varsitt speciellt nummer att ringa när de vill använda företagets tjänster.

Användaren ringer två signaler till det anvisade numret och lägger på. Ett tidsfönster öppnas och användaren kan logga in eller använda sitt betalkort.

Enligt artikeln kan tekniken användas som en extra säkerhetsfunktion, eller som ersättning för lösenord eller pin-koder.

Visst låter det bra? Eller kanske inte. Låt oss göra en analys. (Jag vill poängtera att jag inte sett Phonekeys patent, utan bara det som står i artikeln.)

Vid en säkerhetsanalys gäller det att identifiera vilka premisser, förutsättningar och (ofta implicita) antaganden säkerheten bygger på. Och sedan funderar man på vad som händer om dessa premisser inte gäller – när det skiter sig (för att tala Dalsländska.)

Om vi tolkar artikeln rätt skall man innan man använder en tjänst som skyddas av Phonekeys lösning första gången, först registrera ett visst telefonnummer, exempelvis din mobil. Du får även ett speciellt telefonnummer att ringa upp med ditt registrerade telefonnummer för att aktivera den tjänst du vill använda när du vill använda den.

Man kan se denna mekanism som en separat autenticeringskanal för tjänsten. Att tjänsten inte är aktiv för en given användare om den först inte autenticerat sig via den separata kanalen är det som skall ge den extra säkerheten. Den som vill attackera en sådan tjänst behöver alltså både kunna ringa upp med det korrekta numret till den speciella numret innan det går att komma åt tjänsten (som i sin tur kanske skyddas av en identitetskod tillsammans med PIN-kod eller lösenord).

Pudelns kärna är att man litar på att det telefonnummer som ringer upp ett givet annat telefonnummer går att lita på. Tyvärr är det kanske inte något som är skrivet i sten. I USA är det relativt enkelt att utföra Caller ID Spoofing, dvs förfalska det uppringande numret. I Sverige är det svårare, men att det finns folk (som jobbar hos teleoperatörer) med kunskap, förmåga och möjlighet att förfalska ett uppringande nummer är nog inget falskt påstående.

Vidare, det nummer man får att ringa upp kan man knappast utgå ifrån att det är en hemlighet. Även om det är så att alla användare får ett eget, unikt nummer, vilket låter otroligt, är det svårt att se att det numret skulle kunna betraktas som en hemlighet att lita på.

Men det mest bekymmersamma med hela systemet är att det (att döma av artikeln) blir svårt att hantera säkerhetsproblem. Vad skall man göra om något så trivialt som att en användares mobil vars nummer har registrerats för en tjänst blir stulen? Att en användares mobil någon gång blir stulen är inte bara ett mer troligt scenario än att någon fejkar caller-ID, det är antagligen något som kommer att vara relativt vanligt.

Jag anser att bra säkerhet bygger på så få hemligheter som möjligt – och att dessa hemligheter är så lätta att byta ut som möjligt. En PIN-kod eller ett lösenord är bara en sekvens av tecken. Kan du inte lita på dom är det relativt lätt att byta ut dom. Att byta telefonnummer för att du inte kan lita på den längre för att logga in på din tjänst är inte alls lika enkelt.

Det vore intressant att veta hur Phonekey tänkt lösa dessa problem – hur spärrar man, byter nummer. Kan någon annan enkelt skicka in ett meddelande om att telefonen blivit snodd och att nu gäller ett annat nummer? Kan man säga att en given telefon blivit stulen och därmed orsaka ett DoS-problem för en användare?

Phonekeys mekanism kan ses som ett sätt att försöka krångla till accessen till en given tjänst genom att införa ett extra moment. Men att ersätta en PIN-kod med detta förfarande är fel. Det är snarare så att för att Phonekeys teknik över huvud taget skall ge en ökad säkerhet skulle dom behöva införa en PIN-kod som kopplar ett givet nummer (något du ev har) till kunskap om något (något du vet). Detta blir en så kallad tvåfaktors säkerhetslösning.

Och om det nu skulle visa sig gå fel – att caller-ID inte går att lita på, kommer Phonekey att täcka upp – vilka garantier lämnar dom?

Så tyvärr, jag tror inte på Phonekeys säkerhetslösning. Att dom får patent på den är ok, det finns många dumheter som patenterats. Det som vore tråkigt är om Phonekeys lösning används istället för bra, väl fungerande säkerhetsmekanismer. Att Fredrik Åhgren, VD för säkerhetsföretaget SE46 inte kan göra en vettig bedömning av Phonekeys hemmasnickrade säkerhetslösning är tyvärr lite skrämmande.

Draft med referensbeskrivning för ECC

May 11th, 2010

Det finns en intressant Internet Draft (I-D) av (David) McGrew från Cisco och Igoe från USAs National Security Agency.

David McGrew
David McGrew.

Draften Fundamental Elliptic Curve Cryptography Algorithms (draft-mcgrew-fundamental-ecc-02.txt) ger en referensbeskrivning av Elliptic Curve-krypto (ECC).

Varför är nu detta intressant? Jo – som författarna själva skriver:

The adoption of ECC has been slower than had been anticipated, perhaps due to the lack of freely available normative documents and uncertainty over intellectual property rights.
...
...
This note contains a description of the fundamental algorithms of ECC over fields with characteristic greater than three, based directly on original references. Its intent is to provide the Internet community with a summary of the basic algorithms that predate any specialized or optimized algorithms, which can be used as a normative specification. The original descriptions and notations were followed as closely as possible.
...
...
These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.
(Notera att jag flyttat om ordningen på styckena.)

Jag håller med om att det länge behövts en bra beskrivning av ECC. Men att det Just är patenträttigheter på ECC som hållit tillbaka utvecklingen verkar de flesta vara överens om. Som någon på Cryptography-listan konstaterade ger draften inte bara en normativ beskrivning av ECC, den sammanställer även en referens som är mer än 15 år gammal och föregår därmed de patent som idag finns på ECC.

Längd på nycklar och säkerhet

May 10th, 2010

Jag har den senaste tiden fått flera frågor om längder på kryptonycklar – frågor om vad som är säkert, hur lång en assymetrisk nyckel skall vara för att motsvara en symmetrisk nyckel av en viss längd osv.

Det finns flera källor för information om nyckellängder. Den som ofta förekommer är den i idag något gamla boken Applied Cryptography av Bruce Schneier som i kapitel sju har ett längre resonemang om olika nycklar och längder.

Vidare har NIST publicerat rekommendationer om nyckellängder, deras rekommendationer är dock från 2007. Även IETF har publicerat en RFC, RFC 3766 - Determining Strengths For Public Keys Used For Exchanging Symmetric Keys som innehåller ett längre resonemang om nycklars styrka, hur nyckellängder behöver skala med tiden, samt rekommendationer för assymetriska nycklar.

Det många av dessa källor tyvärr har gemensamt är att dom inte uppdateras speciellt ofta (alls). Webb-baserade källor borde därför vara av intresse att titta närmare på.

WIkipedia har förvirrande nog (minst) två sidor i ämnet, dels en sida om nyckellängder och en sida om kryptonycklar, båda med text om nycklar och längder. Borde nog slås samman och städas upp för att det skall bli användbart.

När jag letat runt efter olika referenser hittade jag att belgiska konsultfirman BlueKrypt har en fin sida som sammanställer rekommendationer om nyckellängder.

Den i mitt tycke bästa källan är dock en rapport. ECRYPT Yearly Report on Algorithms and Key Lengths, utgiven av det EU-finansierade ECRYPT II-projektet.

Som namnet antyder är det här en rapport som uppdateras en gång om året. Den senaste versionen kom ut sommaren 2009. Rapporten innehåller ett ordentligt resonemang om hur nycklars styrkor bör värderas (inklusive diskussioner om metoder som NIST, IETF och andra använder). Resonemanget leder så småningom fram till ett antal rekommendationer.

En viktig sak man gör i ECRYPT II-dokumentet är att sätta in styrkan i nycklar i hur kostsamt (rent ekonomiskt) det är att attackera en viss längd:
Bild 2

Jämför dom sedan olika typer av nycklar – symmetriska, assymetriska baserade på RSA, logaritmer eller ellitic curves får kommer dom med följande rekommendationer:
Bild 3

Slutligen sätter dom in längderna i ett tidsperspektiv – hur lång tid kan man anta att en nyckel med en viss längd ger ett skydd:
Bild 1

Vill du skydda något i 10 år från idag bör du alltså välja minst 96 bitars symmetrisk nyckel eller en RSA-nyckel på drygt 2400 bitar.

Allt detta förutsätter dock att algoritmerna som används inte har några svagheter. Den andra delen av ECRYPTS rapport innehåller en genomgång av de vanligaste algoritmerna inom olika kategorier – krypton, hashfunktioner, signaturer etc (DES, 3DES, AES, RSA, MD5, SHA etc). För varje kategori och specifik algoritm presenterar ECRYPT aktuell status vad gäller säkerhet och kommer med rekommendationer om vad man bör och inte bör använda. Mycket bra läsning.

En sista sak: exportreglerna för krypto i Sverige säger maximalt 56 bitar symmetrisk kryptering och maximalt 512 bitars assymetrisk kryptering (antagligen RSA) eller 112 bitar (antagligen elliptic curve).

Sectra får order på höghastighetskrypto

May 6th, 2010

Elektronik i Norden rapporterar att Sectra fått en order från FMV på att utveckla linjekrypto för 10 Gbit/s.

Sectra logga.

Sectra ska på uppdrag av Försvarets materielverk (FMV), utveckla ett höghastighetskrypto för kryptering av känslig information i de nationella nät som används av myndigheter och försvar.

Hastigheten uppges till 10 Gbit/s, vilket är avsevärt snabbare än den kryptering som används idag. Ordervärdet uppgår till 23 miljoner kronor

Höghastighetskryptot ska skydda tal, data och video och säkerhetsnivån är den högsta, Hemlig/Top Secret.

Sectra har tidigare leverarat såväl linjekrypton, truppkrypton, flyg etc och även kryptomoduler som den här:
Sectras kryptomodul KM4-M

Ny Internet Draft: Test vectors for the stream cipher RC4

May 4th, 2010

Igår kväll släppte Simon Josefsson och jag den första versionen av en ny Internet Draft vi hackat på ett litet tag.

Test vectors for the stream cipher RC4 (draft-josefsson-rc4-test-vectors-00) försöker lösa ett problem vi ser finns när man försöker implementera varianter av strömkryptot RC4.

Eftersom RC4 från början inte är en öppen standard har det inte funnits en tydlig specifikation med testvektorer att använda för att verifiera att implementationen är funktionellt korrekt. Vidare, då RC4 har en del säkerhetsproblem – inte minst problemet med att den läcker nyckelinformation under de första genererade värdena efter initiering finns det ett antal versioner av RC4 där ett visst antal värden skall kastas bort.

Ett exempel på en sådan standard är Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol (RFC 4345). Denna standard beskriver två versioner av RC4, arcfour128 och arcfour256. För dessa versioner skall de första 1536 värdena kastas bort.

Vår draft innehåller testvektorer genererade med två olika typer av nycklar med längder från 40 till 256 bitar. För varje nyckel och nyckellängd specificerar vi 32 Bytes runt ett flertal punkter i nyckelströmmen, exempelvis just 1536. Under arbetet har vi testat ett flertal implementationer av RC4 i exempelvis libgcrypt och andra bibliotek så väl som fristående implementationer, detta för att få så stor konfidens i att vektorerna är korrekta som möjligt.

Vi skulle uppskatta kommentarer och synpunkter på draften så om du läst igenom, ser något fel som strular, kommer på något som borde vara med, tas bort eller ändras – hör av dig till mig eller Simon!

Tack!