Archive for the ‘Internet’ category

Bra blogpost om Strict Transport Security

August 22nd, 2010

John WilanderOWASP Sweden Blog har skrivet en mycket bra postning om HTTP Strict Transport Security, en teknik (just nu en IETF Internet Draft) för att eliminera man i mitten-attacker i SSL/TLS. Se även till att läsa diskussionerna i kommentarerna.

SEC-T 2010

August 12th, 2010

Säkerhetskonferensen SEC-T anordnas i år för tredje gången och går i år den 9 och 10 September.

SEC-T logga

Arrangörerna har postat agendan för konferensen. Tittar jag på agendan finns det ett par klart spännande presentationer, bland annat en presentation om svagheter i diskkrypteringsprodukter och en presentation om (o)säkerheten hos skrivare.

För den som vill gå på årets SEC-T är det hög tid att anmäla sig.

Intressant analys av Wikileaks-data

August 11th, 2010

På BoingBoing dök det upp en nyhet om en analys av det data från Afghanistan-kriget Wikileaks publicerat. Genom att plocka ut information om var och när strider har skett enligt datat har Drew Conway skapat en sekvens bilder:

Bildsekvens över kriget i Afghanistan.

Rätt skrämmande bildsekvens. Jag kan inte tolka det som att kriget är på väg att avslutas. Bilderna har även lätt till en analys och diskussion av krigets utveckling, ex att Talibanerna ser ut att ha börjat försöka störa den ringväg som tydligen finns i Afghanistan.

Vad gäller Wikileaks har tydligen president Obama bett England, Tydlland, Australien m.fl. länder att åtala Wikileaks Julian Assange för spionage på grund av publiceringen av Afghanistan-informationen.

Wikileaks har svarat med att publicera en stor fil kallad Insurance (finns längst ner på sidan om Afghanistan-kriget). På Bruce Schneiers blog går diskussionerna höga om filen verkligen innehåller vad den misstänks innehålla, om Wikileaks använder rätt strategi etc. Klart intressant läsning iaf.

Ny TCP-sekvensgenerator för uIP

July 17th, 2010

Tillsammans med Adam Dunkels har jag börjat titta lite försiktigt på att hitta en bättre generator för TCP-sekvensnummer till den miniskula TCP/IP-stacken uIP.

Adam Dunkels
Adam Dunkels – pappa till uIP, bland annat.

Den nuvarande generatorn ger en monotont ökande sekvens som är lätt att prediktera. En ny generator skall ge en bra slumpmässig som inte är lätt (inte går) att prediktera. MEn samtidigt får storleken på stacken inte växa speciellt mycket och skall gå att implementera på en 8-bitars processor. Vidare får vi inte inför en massa nya krav på målsystemet, exempelvis tillgång till bra fysisk entropi. En icke-trivial kombination av krav.

Jag har tänkt, kladdat och sedan postat på Cryptography-listan och fått en del tips. Men jag (vi) tar med stor glädje emot mer klokskap. Här kommer därför min postning till listan. Läs, kommentera. Tack!


uIP [1] is a very compact TCP/IP stack for small, networked connected, embedded devices. (The code size for uIP including TCP and ICMP on the AVR processor is about 5 kBytes.)

Unfortunately, the TCP sequence number generator in uIP is a bit simplistic – basically a monotonically increasing number. In order to reduce the opportunities for TCP Spoofing (like this nice one [2]) we are trying to implement a new TCP sequence number generator.

What we want to find is an algorithm that generates a good (secure) TCP seq numbers, but use very little resources (on 8-bit computing devices).

We have done some preliminary investigations, have some rough ideas and would really appreciate comments and suggestions from the enlightened minds on this list.

As we see it, the two main problems to solve are:
(1) Find a secure PRNG algorithm that have as low implementation complexity as possible.

(2) Add as little system/application requirements on entropy source and persistent storage as possible.

Looking at TinyRNG [3] for example, it seems that a block cipher in CTR mode (or OFB mode) should be sufficient. The question then is what block cipher to use? The XTEA block cipher [4] is very compact, but would it be a wise choice from a security perspective?

But what to feed the PRNG with? Looking again at TinyRNG, it uses a simplistic version of the entropy accumulator from the Fortuna PRNG [5], but with fewer and smaller pools. The pools are processed using a CBC-MAC built around the same block cipher as used in the PRNG.

The combined storage for the pools as well as CBC-MAC state would probably be acceptable for uIP. The question is if the pool feeding operation as such adds operational requirements on uIP that makes it harder to integrate?

A simpler scheme could be to feed the PRNG (CTR-mode) with entropy used as part of Key and IV, that is not use a pool mechanism at all and leave it to user application to provide entropy words when performing a reseed. The Key (and IV?) would also consists of a counter that is monotonically increased.

The problem with this (we guess) is that in order to ensure that KEY+IV is never reused is to keep at least part of KEY or IV as a counter that is stored in persistent memory and increased once (and stored) every time reseed (or boot) is performed. (How bad from a security perspective would this be? Compared to other TCP sequence generators?)

The current version of uIP places few (basically no) demands on the system/application regarding physical resources (besides mem for code and data) and does not use any persistent storage besides code memory. It seems that any good sequence generator that are driven by physical entropy and tries to avoid sequence repetition need to place additional demands on the system. No?

This is basically as far as we have taken this. More or less a bit of Googling, reading and attempts at thinking. The ambition is not to invent something new and unproven but to adapt existing tech and ideas that seem to work. But get it to work with the size, performance and API constraints of uIP.

Any thoughts, comments, suggestions and pointers would be very greatly appreciated.

Thank you!
Joachim Strömbergson

References
—————

[1] A. Dunkels. uIP TCP/IP stack.

http://www.sics.se/~adam/uip/index.php/Main_Page

[1] R. Lawshae. Picking Electronic Locks Using TCP Sequence Prediction
http://www.defcon.org/images/defcon-17/dc-17-presentation/Ricky_Lawshae/defcon-17-ricky_lawshae-picking_electronic_locks-wp.pdf

[3] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random

Number Generator for Wireless Sensors Network Nodes

http://planete.inrialpes.fr/~ccastel/PAPERS/TinyRNG.pdf

[4] R. M. Needham, D. J. Wheeler. Tea extensions.

http://www.cix.co.uk/~klockstone/xtea.pdf

[5] Wikipedia. Fortuna PRNG.

http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29

Ny version av Internet Draft för RC4

June 29th, 2010

Vi (Jag och Simon Josefsson) har precis släppt version 01 av vår Internet Draft med testvektorer för strömkryptot RC4.

Den största förändringen i draften är att vi ändrat en av kryptonycklarna och därmed genererat nya vektorer. Draften innehåller två olika slags nycklar med tillhörande testvektorer för olika nyckellängder. En av dessa nycklar är genererad genom att köra strängen Internet Engineering Task Force genom hashfunktionen SHA-256. Tyvärr inkluderade den gamla strängen radbrytning vilket inte syns i strängen. Detta är nu ändrat.

Andra ändringar är att vi nu även har med testvektorer runt nyckelströmspunkten 4096 Bytes. Vidare har vi förtydligat en del referenser och säkerhetsrekommendationer för RC4. Rent krasst skriver vi att:

The RC4 algorithm does not meet the basic criteria required for an encryption algorithm, as its output is distinguishable from random. The use of RC4 continue to be recommended against; in particular, its use in new specifications is discouraged. This note is intended only to aid the interoperability of existing specifications that make use of RC4.

Vi tar gärna emot kommentarer och synpunkter på draften.

Hälsoläget för AES

June 1st, 2010

Eurocrypt 2010 idag tisdag 2010-06-01 presenterade Ali Biham, Orr Dunkelman m.fl. en uppdaterade attack av sin attack på AES: Key Recovery Attacks of Practical Complexity on AES-256 Variants with up to 10 Rounds.

Eurocrypt 2010

Detta är den första stora attacken (som dock snarare är en uppdatering på en attack från förra året) i år. Men sett över de senaste dryga året har vi sett fem, sex större attacker på AES som algoritm, samt ett antal mindre attacker där olika delar av algoritmen analyseras. Och sedan, naturligtvis ett antal attacker på implementationer, inte minst attacker basererade på felinjektering och sidoattacker. Wikipedias sida om AES listar några av dessa attacker, men långt ifrån alla. Bruce Schneier bloggade om dessa attacker ett par gånger i mitten på förra året (ett, två). En av de främsta på att attacker AES är Orr Dunkelmans.

Orr Dunkelman
Orr Dunkelman

Kolla man på Orr Dunkelmans forskningssida hittar man ett flertal artiklar med olika analyser av AES och attacker. Den här om vad som händer om MixColumns-operationen i AES inte fungerar i den sista iterationen är ett typiskt exempel på den typ av analys jag tycker att man ser ofta just nu (en trend inom kryptanalys).

Vad jag försöker säga är att jag upplever det som att AES, efter snart tio år sedan (AES publicerades i november 2001 så det snarare åtta år, men…) utan större säkerhetsproblem med algoritmen nu plötsligt börjar se lite skadeskjuten ut – att den kanske inte är så säker längre. Det är inte dags för panik, men långsiktigt och för nya applikationer bör man nog tänka på att inte låsa fast sig i AES, utan göra det möjligt att byta algoritm.

Till saken hör att AES har varit en formidabel succé och har designats in i alltifrån kommunikation för små sensorsystem (IEEE 802.15.4 – ZigBee) till 10G Ethernet och en oherrans massa saker däromkring. Skulle AES falla och måste bytas ut kommer det inte att bli enkelt.

Det skall bli spännande att se hur det går.

En liten titt på Evernote

June 1st, 2010

Evernote är en väldigt nifty och snygg molntjänst för att hantera anteckningar.

Evernote logo

Med inbyggt stöd för att identifiera text i bilder, snygga till figurer, kopplingar till andra tjänster är det mycket jag gillar med Evernote. Och att döma av kommentarer från de som använder Evernote verkar jag inte vara den enda och att tjänsten faktiskt fungerar. Eftersom det är en molntjänst går det dessutom att komma åt alla sin insamlade information via klienter på mobil, dator, webbläsare etc.

Evernote på iPhone.

Tyvärr måste jag dock, för att citera Tony Irving säga: Men….Kolla in användarvillkoren (Terms of Service) för Evernote:


by using the Service and posting Content, you grant Evernote a license to display, perform and distribute your Content, and to modify and reproduce such Content to enable Evernote to operate and promote the Service. (You also agree that Evernote has the right to elect not to accept, post, store, display, publish or transmit any Content in our sole discretion.)

You agree that these rights and licenses are royalty free, irrevocable and worldwide, and include a right for Evernote to make such Content available to, and pass these rights along to, others with whom Evernote has contractual relationships related to the provision of the Evernote Service, solely for the purpose of providing such services, and to otherwise permit access to your Content to third parties if Evernote determines such access is necessary to comply with its legal obligations.

Jösses, man blir lite tveksam till att använda Evernote – även om det som sagt är en väldigt nifty tjänst.

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.