Kryptoblog

Det arrangeras en ny säkerhetskonferens i Sverige om ett par veckor kallad Sec-T

Konferensen riktar sig enligt arrangörerna riktar till:

The conference is organised for anyone with a interest in information security, hacking and malware related threats. So whether you are “head of security”, security consultant, developer or IS student this will be a great conference for you.

Huvudtemat för konferensen är olika typer av hot. Arrangörerna skriver:

Our aim is to cover emerging information security and hacking related threats all across the board. So expect to hear presentations covering most layers in the OSI model and then some. From hardware hacking via networks, operating systems, applications and social interaction.

Bland de mer kända talarna på konferensen återfinns Mikko Hypponen från F-Secure och Patrik Fältström. Andra presentationer jag tycker verkar intressanta är SÄPOs Bosse Norgren som skall prata om IT-relaterad rättsteknik samt Patrik Karlsson som säkert kommer att presentera nya verktygshack (hans blogg är bra). Tittar man i konferensagendan finns ett antal andra presentationer till som ser spännande ut.

Jag gillar konferenser där folk från företag, myndigheter, akademisk verksamhet samt entusiaster och representanter för andra typer av grupper kan mötas, diskutera, lära nytt och dela erfarenheter. Inte minst är korridorsnacket efter presentationer och under fika, lunch etc ofta intressanta.

Jag hinner tyvärr inte åka till Sec-T, men tar väldigt gärna emot kommentarer och referat från konferensen. Vill du skriva ett gästblogginlägg på Kryptoblog från Sec-T så hör av dig.

IDG publicerade i dag en artikel om att Flashdiskar är en säkerhetsrisk. I artikeln är jag intervjuad, men allt jag sa i intervjun fanns det naturligtvis inte plats för. Jag vill därför här på min egen blog (där jag kan bladdra på) förtydliga det jag sa samt ta upp något av det som inte kom med i artikeln.

Det stämmer att jag anser att det är enklare att sprätta upp en Flashbaserad hårddisk (Solid State Drive - SSD) och läsa ut innehållet ur minneskretsarna än vad det skulle vara att försöka plocka ut informationen direkt från skivorna i en traditionell hårddisk. Det senare kräver bland annat klart mer avancerad utrustning och renare miljö.

Intel presenterade för några dagar sedan på IDF att de kommer med specialutvecklade FLASH-minnen för att bygga en riktigt snabb SSD, men de flesta SSD-diskar på marknaden innehåller i dag vanliga FLASH-minnen som går att proba (dvs koppla in sig direkt på kretsens ben) och läsa ut innehållet ifrån med enkel och billig utrustning.

En SSD med flera stycken FLASH-kretsar.

MEN för att någon skall sprätta upp din SSD och läsa ut minnesinnehållet måste du blivit av med din hårddisk. Du är kort sagt redan rökt, något jag påpekade i intervjun. Vidare bör det vara så att skälet för att en skurk skulle ge sig på kretsarna är antagligen för att det lösenordsskydd som finns i ATA-standarden (ATA Security Feature Set) är aktiverat. Men det lösenordsskyddet finns det enklare sätt att ta sig runt.

Vad det handlar om är alltså att om man gör en ren jämförelse mellan de två typerna av hårddiskar så finns det en säkerhetsteknisk skillnad. Men den här skillnaden i säkerhet mellan Flashbaserade hårddiskar och traditionella hårddiskar är marginell, troligen inte den väg en attack skulle ta och rent praktiskt inte ett hot värt att förlora speciellt mycket sömn över.

Vad som kom med i artikeln och jag tycker är bra är att jag tycker att diskkryptering är bra. Både den typ som implementeras direkt i disken och i den som finns i operativsystem (FreeBSD, Mac OS X, Windows Vista, Solaris med flera) samt via fristående applikationer exempelvis TrueCrypt.

Informationsförluster på grund av stulna eller förlorade datorer är i dag ett stort och verkligt problem, men går att i stort sett eliminera genom diskkryptering och vettig nyckelhantering. Och den dag gammal utrustning skall rensas ut behöver inte de redan hårt belastade sysadministratörerna ägna tid åt att köra scrubbing-program för att förstöra data. Dumpa nycklarna och problemet är löst. Mycket mer ekonomiskt och enklare att metodiskt hantera i en organisation.

Jag anser att om du står i valet mellan en minnesbaserad hårddisk eller en traditionell hårddisk finns det viktigare parametrar att skillnad i säkerhet. Men oavsett vilken typ av hårddisk du väljer är det bra att använda diskkryptering.

EE Times har publicerat ännu en artikel som beskriver en effektiv implementation av AES på en Blackfin-DSP. Fokus i artikeln Implementation of the AES algorithm on Deeply Pipelined DSP/RISC Processor är som namnet antyder att försöka utnyttja processorns pipeline.

Artikeln är en aning underlig då den presenterar AES på en något annorlunda sätt. Bland annat tar artikeln de olika delstegen i AES i en annan ordning än vad AES-specifikationen gör. AddRoundKey kommer normalt sist, inte först. Vidare brukar S-box-steget kallas SubBytes, inte SubstituteBytes.

Artikeln innehåller dock en del dataflödesbeskrivningar som kan vara värda att läsa igenom för den som vill implementera AES på en pipelinad processor. Lösningen som presenteras i artikeln är i slutändan en tabell-baserad, konkatenerad implementation. Figuren nedan visar flödet genom algoritmen.

Detta är alltså den andra artikeln (som jag sett) om effektiv implementation av AES på Blackfin. Den första artikeln använder även den en konkatenerad lösning. Att båda artiklarna påminner om varandra kan bero på att ADI-medarbetaren Yosi Stein har varit med och skrivit båda artiklarna.

Google har släppt ett verktyg för att hantera nycklar kallat KeyCzar.

Nyckelhantering är en av de riktigt svåra momenten när det kommer till kommunikationssäkerhet (både design och implementation). Tanken med KeyCzar är att underlätta för applikationsutvecklare genom att tillhandahålla ett bibliotek som sköter nyckelhanteringen på ett bra sätt. Några av funktionerna som KeyCzar erbjuder är:

• Nyckelrotation och versionshantering av nycklar inkl att återkalla (döda) nycklar.
• Implementation av bra algoritmer och vettiga nyckellängder.
• Generering av initialvektorer (IV) och signaturer.
• Stöd för att kryptera/dekryptera och verifiera.
• Stöd för applikationer skrivna i Java eller Python.

Bra algoritmer och vettiga längder är vad Google själva skriver, och det låter fluffigt. Men tittar man i den utmärkta designdokumentationen för KeyCzar ser man att de använder 1024-bit DSA med SHA-1 för signering. KeyCzar stödjer även RSA OAEP med 512-2048 bitar för publik kryptering och RSA SHA-1 med 512-2048 bitar för publik signering. Vidare används AES 128, 192 och 256 med CBC-mod för symmetrisk kryptering och HMAC med SHA-1 och 256 bit nyckel för symmetrisk signering.

KeyCzar genererar X.509-fält och allt annat pill som brukar ställa till det vid implementationer. Allt du behöver göra är att skapa ett KeyCzar-objekt och sedan lita på att KeyCzar gör rätt.

Enligt Google har KeyCzar ett enkelt API. Om det är enkelt eller ej är en bedömningsfråga, men jag hade iaf inga problem att på några få minuter ladda ner, installera och sparka igång KeyCzar i en testapplikation. Google påpekar även att:

Keyczar sacrifices some flexibility in favor of safety and ease of use. Protecting developers from mistakes and handling details for them may also hide useful underlying features. Please see the NonGoals wiki page for a description of things that Keyczar is not.

Av de saker KeyCzar inte är listar Google bla att det inte är en ersättning för OpenSSL eller vara en komplett PKI-lösning.

KeyCzar började som Ben Lauris startprojekt när han började på Google. Projektet togs sedan över av Googles säkerhetsteam som nu ansvarar för utvecklingen.

KeyCzar är Apache 2.0-licensierad och finns att ladda ner (Java, Python). Här finns Java-dokumentationen och här finns Python-dokumentationen. Slutligen finns det även ett diskussionforum (en grupp) för KeyCzar. Än så länge är det dock med KeyCzar-skaparna som postat i gruppen.

Jag tycker att KeyCzar är ett bra initiativ av Google och om det fungerer som det står i dokumentationen och det inte finns en massa fel i KeyCzar är det ett bra tillskott i verktygslådan för att bygga IT-säkerhet.

En fundering: I USA är det populärt att utnämna Tsarer för olika saker. Ex finns det en cybersäkerhets-tsar. Med tanke på alla starka signaler och liknande begrepp och koncept som verkar lånas in friskt, när får Sverige sin första tsar-någonting? Eller blir den svenska varianten hertig eller baron?)

Aloha!

Efter några veckors sommarstiltje har hösten kommit till Kryptoblog. Inget mer sol och bad, utan nu blir det full fart som vanligt igen. Jag har under sommaren roat mig med att läsa en hel del intressanta böcker och forskningsartiklar (finns det något mysigare att läsa i hängmattan än en forskningsartikel om kryptomoder?) och jag kommer bland annat att skriva en del om detta den närmaste tiden.

En sak jag precis lade till är en länk till Googles säkerhetsblog som jag tycker innehåller en hel del intressant information.

SvD skriver om USAs nya elektroniska system Electronic System for Travel Authority (ESTA).

Enligt SvD:s artikel är ESTA ett nytt system för att samla in information om de personer som avser att resa in i USA. Mer exakt kräver USA att få in information om:

sin mentala och fysiska hälsa, kriminella belastning, droghistoria och andra mer eller mindre känsliga data

Som Bruce Schneier brukar skriva - det intressanta med ett säkerhetssystem är inte när det fungerar, utan vad som händer när det inte fungerar. Vilka typer av informationsläckage och skador kan uppstå när systemet skiter sig?

Enligt artikeln handlar det väsentligen om samma sorts information som man i dag fyller i när man sitter i luften över Atlanten på konstiga gröna lappar med staketrutor. (Jag brukar alltid hamna halvvägs in i min mammas förnamn eftersom blanketterna inte precis är anpassade för personer med många och långa namn.) Men nu får systemet alltså ett publikt webbgränssnitt.

Även om ESTA initierats av Department of Homeland Security (DHS) och sköts av en avdelning kallad Customs and Border Protection (CPB). På CPB finns en presentation med mer information om ESTA.

I presentationen finns bilder på hur webbplatsen kommer att se ut och vilka fält som man kommer att vara tvungen att fylla i. En liten detalj är att att webbplatsen ser ut att använda en relativt simpel CAPTCHA för att skydda mot automatiserade registreringar. Vad skulle hända om ESTA utsattes för en DDoS-attack? Eller blev fylld med berg av snarlika registreringar?

Vidare finns den webbplats som det är tänkt att du som passagerare skall besöka för att lämna känslig information om dig själv.

Jag gjorde ett försök - och hoppsan vad Firefox protesterade!

Säker anslutning misslyckades

esta.cbp.dhs.gov använder ett ogiltigt säkerhetscertifikat.

Certifikatet är inte betrott eftersom utfärdarcertifikatet är okänt.

(Felkod: sec_error_unknown_issuer)

En liten titt på certifikatet visar att det är utställt av organisationen… CPB! Självsignerat certifikat allstå - extremt pålitligt. Dessutom pekar kontaktinformationen för certifikatetet på en användare hos en helt annan organisation nämligen National Technical Information Service (NTIS), en organisation som hävdar att dom är:

the largest central resource for government-funded scientific, technical, engineering, and business related information available today. For more than 60 years NTIS has assured businesses, universities, and the public timely access to approximately 3 million publications covering over 350 subject areas.

Vad f-n har det med certifikat för utländska medborgares privata information att göra?

Vad gäller val av kryptering för att skydda en session mot ESTAs webbplats får jag när jag testar RC4-128, men jag tillåter å andra sidan inte FF att använda svagare krypton.

Är du säker på att du litar på att ESTA tar väl hand om din privata information? (Skall man vara helt ärlig är nuvarande hanteringen av privat information, där kabinpersonalen springer omkring med papperslapparna rätt usel den också.)

JanJ tog i en diskussion upp den mycket intressanta frågan om vad man som anställd kan tvingas att göra för att utföra sitt uppdrag. Om du i ditt jobb blir beordrad att flyga till USA, måste du i och med ESTA som en konsekvens lämna över privat information till en tredje part. Jag är ingen jurist, men det låter som att detta är något som borde regleras i anställningsavtal. Vad händer om jag som anställd vägrar att resa till USA med hänvisning till ESTA?

Enligt SvDs artikel har EU försökt bråka med USA för att medborgare i EU skall slippa att lämna över information. Tydligen har man bla hotat med att USAs medborgare skulle behöva lämna över motsvarande information när de flyger till EU.

Ryggmärgen säger att det vore bra att tvinga USAs medborgare att hosta upp info dom också. Men det är egentligen inte en bra lösning. Mer privat information som skickas runt över världen kan knappast förbättra situationen. Lösningen måste vara att få stopp på denna informationsinsamlings- och kontrolliver.

Och bara för att förtydliga. Japp, detta gäller Svenska resenärer från årsskiftet. Skall du till USA skall du senast 72 timmar innan logga in och hosta upp info om dig själv. Lycka till.

Jerry Proc har byggt upp en sida kallad Crypto Machines med massor av information om olika gamla kryptomaskiner. Sidan innehåller ett antal fina bilder och beskrivningar om ett otal maskiner. En av de maskiner jag sprang på är Sphinx. Sphinx är en fickkryptomaskin från 1934. Tillverkad i USA och förpackad i ett vackert backelitskal. Några bilder:

Locket till Sphinx.

Insidan av Sphinx med de olika alfabeten som används för att kryptera meddelandet.

Sidan innehåller naturligtvis en massa bilder på Enigma-maskiner, Hagelin-maskiner och Transvertex. Är du intresserad av kryptohistoria och fina kryptomaskiner är den här webbsidan väl värd att besöka.

För ett tag sedan skrev jag att kretsföretaget NXP stämt ett antal forskare i ett försök att stoppa publiceringen av svagheter i MiFare. Domstolen har kommit med sitt beslut, och NXP fick på pälsen.

Jag tycker att domstolen i sitt beslut sammanfattade situationen elegant: Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings.

Dark Reading rapporterar att funktionen för att gömma filer och hela filsystem i krypteringsprogrammet TrueCrypt knäckts (eller vad man skall kalla det).

Funktionen i TrueCrypt kallas Plausible Deniability gör det möjligt att skapa gömda volymer (Deniable File System - DFS) avsedda att ej gå att detektera och därmed undvika problemet med att behöva uppge ett lösenord. TrueCrypts beskrivning av DFS är:

In case an adversary forces you to reveal your password, TrueCrypt provides and supports two kinds of plausible deniability:

1. Hidden volumes (for more information, see the section Hidden Volume).

2. It is impossible to identify a TrueCrypt volume. Until decrypted, a TrueCrypt volume appears to consist of nothing more than random data (it does not contain any kind of “signature”). Therefore, it is impossible to prove that a file, a partition or a device is a TrueCrypt volume or that it has been encrypted. However, note that for system encryption, the first drive track contains the (unencrypted) TrueCrypt Boot Loader, which can be easily identified as such (for more information, see the chapter System Encryption). In such cases, plausible deniability can be achieved by creating a hidden operating system (see the section Hidden Operating System).

TrueCrypt containers (file-hosted volumes) can have any file extension you like (for example, .raw, .iso, .img, .dat, .rnd, .tc) or they can have no file extension at all. TrueCrypt ignores file extensions. If you need plausible deniability, make sure your TrueCrypt volumes do not have the .tc file extension (this file extension is officially associated with TrueCrypt).

Nu har Bruce Schneier & Co attackerat DFS och kommer att presentera en artikel där dom visar att det i en normal datormiljö går att identifiera och komma åt en DFS-volym. Schneier & Co skriver:

We examine the security requirements for creating a Deniable File System (DFS), and the efficacy with which the TrueCrypt disk-encryption software meets those requirements. We find that the Windows Vista operating system itself, Microsoft Word, and Google Desktop all compromise the deniability of a TrueCrypt DFS.

While staged in the context of TrueCrypt, our research highlights several fundamental challenges to the creation and use of any DFS: even when the file system may be deniable in the pure, mathematical sense, we find that the environment surrounding that file system can undermine its deniability, as well as its contents. Finally, we suggest approaches for overcoming these challenges on modern operating systems like Windows.

Notera att det alltså inte är brister i TrueCrypts algoritmer, utan snarare svårigheten att skapa en DFS i ett datorsystem med OS och andra applikationer.

Enligt Dark Reading hävdar TrueCrypts skapare att den nyligen släppta 6.0-versionen fixar problemen, vilket dock Bruce Schneier tvivlar på.

(Fixat trasig länk - tack JörgenL.)

På Light Blue Touchpaper, bloggen från säkerhetsguppen vid Cambridge Computer Laboratory har det dykt upp en intressant postning om ett nytt sätt att utföra lösenordsbaserad nyckelutbyte.

Lösenordsbaserad nyckelutbyte (Password Authenticated Key Exchange - PAKE) är en metod för att utbyta sessionsnycklar för säker kommunikation mellan parter baserad på lösenord (delad hemlighet). De två mest kända versionerna av PAKE är Encrypted Key Exchange - EKE och Simple Password Exponential Key Exchange - SPEKE.

Artikeln Password Authenticated Key Exchange by Juggling är skriven av Feng Hao och Peter Ryan. Artikelns sammanfattning förklarar nyttan med J-PAKE:

Password-Authenticated Key Exchange (PAKE) studies how to establish secure communication between two remote parties solely based on their shared password, without requiring a Public Key Infrastructure (PKI). Despite extensive research in the past decade, this problem remains unsolved. Patent has been one of the biggest brakes in deploying PAKE solutions in practice. Besides, even for the patented schemes like EKE and SPEKE, their security is only heuristic; researchers have reported some subtle but worrying security issues. In this paper, we propose to tackle this problem using an approach different from all past solutions.

Our protocol, Password Authenticated Key Exchange by Juggling (J-PAKE), achieves mutual authentication in two steps: first, two parties send ephemeral public keys to each other; second, they encrypt the shared password by juggling the public keys in a verifiable way. The first use of such a juggling technique was seen in solving the Dining Cryptographers problem in 2006. Here, we apply it to solve the PAKE problem, and show that the protocol is zero-knowledge as it reveals nothing except one-bit information: whether the supplied passwords at two sides are the same.

With clear advantages in security, our scheme has comparable efficiency to the EKE and SPEKE protocols.

(Jonglering med nycklar - om din nyckel heter som ditt husdjur…)

Artikeln innehåller en hel del referenser till koncept och metoder jag inte kände till innan, exempelvis Dining Cryptographers. (Det verkar pågå verksamhet på Wikipedia för att skriva om förklaringen av problemet - se den här och den här sidan.)

Implementationsmässigt verkar den nya metoden inte vara så hemsk. Författarna skriver:

Since our protocol involves several zero-knowledge proofs, one might concern about its cost. We now count the number of exponentiations in the protocol and evaluate its computational effciency..in our protocol, each party would need to perform 14 exponentiations in total – including 8 in the first step, 4 in the second step, and 2 in computing the session key.

To better assess the cost in real terms, we implement the protocol in Java on a 2.33-GHz laptop running Mac OS X. The modulus p is chosen 1024-bit and the subgroup order q 160-bit
…
The results demonstrate that the protocol – executed only once in a session – runs sufficiently fast. The total computation time is merely 0.075 sec. As compared to the time that the user keys in his password, this latency is negligible at the client.

However, the cost at the server may accumulate to be significant if requests are dealt with simultaneously. Therefore, the threat of Denial of Service (DoS) attacks still needs to be properly addressed in practical deployments.

Vad gäller säkerheten skriver författarna att:

EKE requires changing the protocol in its existing form for a secure implementation. As for a SPEKE, it has the drawback that an active attacker may test multiple passwords in one protocol execution. Furthermore, neither protocol – in the original form – accommodates short exponents securely. Finally, neither protocol is provably secure; formal security proofs seem unlikely without introducing new security assumptions or relaxing security requirements.

We choose to solve the PAKE problem using a different approach. The novelty of our design is that we encrypt the password by juggling the public keys in a way that can be verified. As a result, our scheme is provably secure, allows flexible use of short exponents, and strictly limits an active attacker to test only one password per protocol execution.

För ett tag sedan blev Java-koden till implementationen av J-PAKE tillgänglig. Jag har inte testat den själv. Intressant nog kallas den för JPAKE2, vilket skulle kunna betyda att det funnits en tidigare version av algoritmen som man av någon anledning inte var nöjd med.

Författarna har även skickat in J-PAKE som förslag till en framtida utökning av IEEE P1363.

När J-PAKE uppmärksammades på Cyptography-listan dök det upp referenser till en annan, ny PAKE-algoritm. Det finns en Internet Draft, EAP Authentication Using Only A Password som tydligen är under utvärdering av IEEE för den kommande WLAN-standarden 802.11s.

Bra och enkla och allmänt tillgängliga metoder för nyckelutbyte är klart intressant. Med två stycken nya, säkra och ej patenterade utan öppna algoritmer kanske PAKE kan få bättre spridning. Inte minst för inbyggda system är J-PAKE klart intressant.