Kategoriarkiv: Standarder

Ny draft för att få in Salsa20 i TLS och DTLS

Tillsammans med Simon Josefsson och Nikos Mavrogiannopoulos är Secworks involverade i arbetet att skriva en Internet Draft avsedd att få in strömkryptot Salsa20 i TLS och DTLS.

Skälet till arbetet med draften draft-josefsson-salsa20-tls-01 är att vi ser att det behövs ett bra, säkert strömkrypto i TLS och DTLS. I dag finns bara RC4 som strömkrypto, men RC4 är rejält trasigt. Det finns ett antal blockkrypton, inte minst AES, men de senaste årens säkerhetsproblem har gjort att fler använder RC4.

Att få in ett nytt strömkrypto kräver att det finns en RFC som beskriver hur strömkryptot ska användas i TLS och DTLS och draften är arbetsdokumentet till vad som förhoppningsvis blir denna RFC.

Salsa20 är ett strömkrypto som har kort initieringsfas och därmed ger bra prestanda även för korta meddelanden. Salsa20 går att få att ge bra prestanda på ett flertal olika processorarkitekturer. ARX-strukturen gör att Salsa20 inte öppnar upp för informationsläckage via sidokanaler. Slutligen är Salsa20 relativt väl analyserad då den är en av algoritmerna i eSTREAM-portföljen. Vi tror därför att Salsa20 skulle kunna bli en bra ersättare till RC4 i TLS och DTLS.

Om du har några kommentarer och synpunkter på draften skulle vi som författare uppskatta det mycket. Kontakta oss gärna. Själva arbetet med draften sker på Gitorious.

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.

Algoritmerna 128-EEA3 och 128-EIA3 godkända av 3GPP

(Det här är egentligen ingen riktigt nyhet då den är flera månader gammal. Men eftersom det inte uppmärksammats tycker jag att det är värt att ta upp.)

3GPPs 53:e SA-möte i september 2011 beslutade 3GPP att anta algoritmerna 128-AAA3 och 128-EIA3 som säkerhetsstandarder för LTE. Länken pekar på agendan/mötesprotokollet från mötet. Den relevanta sektionen att titta på är sektion 11.16.

Vad är nu detta för algoritmer för något? Jo det är de nya konfidentiltets- och integritetsalgoritmerna som skyddar kommunikationen mellan mobilen och mobilstystemet. Dessa algoritmer är byggda runt strömkryptot ZUC. Beslutet som tagits innebär att även ZUC är en antagen standard. (Jag har tidigare skrivit ett par inlägg om ZUC tidigare och även på gamla Kryptoblog.). Strukturmässigt är ZUC ett strömkrypto med en LFSR-kedja sammankopplad med ett tillståndsmaskin – på många sätt likt Snow och Snow3G.

Strukturen hos ZUC.
Strukturen hos ZUC.

Algoritmen 128-EEA3 använder ZUC som en nyckelströmsgenerator. Algoritmen 128-EIA3 är en generator för äkthetskoder (message authentication code – MAC). Algoritmerna kan användas separat eller tillsammans.

I samband med beslutsmötet i september presenterade även ETSIs säkerhetsgrupp SAGE sin slutliga version av sin utvärderingsrapport för ZUC. Rapporten finns att ladda ner (zipfil) från 3GPP.

För den som vill få tag på specifikationerna för ZUC, 128-EEA3 och 128-EIA3 (version 1.6) finns dom att hämta GSMA. På den sidan finns även specifikationer för äldre algoritmer exempelvis Snow3G, Milenage, Kasumi samt deras kryptomoder så som dom används i GSM, 3G, LTE etc. Letar du efter en referensimplementation av ZUC finns den in specifikationen (i dokumentet). Det kan dock vara värt att notera att namnen som används i koden inte riktigt stämmer med de som används i algoritmbeskrivningen. Hos 3GPP själva är den senaste versionen av specifikationerna intressant nog spärrade/censurerade i avvaktan på beslut om exportkontroll. Företaget Galois, som utvecklar verktyget Cryptol har skapat en implementation av ZUC i Cryptol och använt den för att testa algoritmen.

Det ska bli intressant att se utvecklingen runt ZUC, 128-EEA3 och 128-EIA3 – kommer dom att visa sig starka när användningen av dom börjar öka och därmed intresset för att attackera dom ökar? Och kommer algoritmernas användning att få spridning på global nivå.

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.

DMARC – nytt initiativ för att skydda mot domänförfalskning

Googles Gmailblog finns en beskrivning av ett nytt initiativ mot domänförfalskning (domain spoofing) kallar DMARC. Vid spam och annan icke önskvärd epost är det vanligt att mailen skickas från falska domännamn. Flera olika tekniker har sedan tidigare tagits fram för att stoppa detta – exempelvis Sender Policy Framework (SPF) DomainKeys Identified Mail (DKIM).

Domain-based Message Authentication, Reporting and Conformance (DMARC) bygger vidare på SPF och DKIM genom att tillföra en mekanism för organisationer i sina mail att tala om hur dom autenticerar sina mail och hur mail skall hanteras om autenticeringen inte är korrekt. Bland annat ger DMARC en möjlighet för mottagare att rapportera tillbaka till sändaren om den får mail som den inte litar på. En organisation som använder DMARC använder DNS för att berätta om hur dom avser att autenticera sin domän och policy för att hantera felaktiga mail. Exempelvis kan det se ut så här:

% dig +short TXT _dmarc.example.com.
”v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com\;
ruf=mailto:auth-reports@example.com”

Det finns en organisation skapad för att utveckla och marknadsföra DMARC skapad av bland annat Google. Ett av organisationens mål är att via IETF standardisera DMARC. Enligt organisationen används DMARC redan i dag, bland annat av Gmail, Facebook, LinkedIn och PayPal. På organisationens webbplats finns även specifikationen för DMARC om man vill titta närmare på hur det fungerar.

Jag lyckas dock inte hitta DMARC-policyn för Gmail/Google – bara att dom vill använda SPF. Vidare får jag inte organisationens webbplats, dmarc.org att svara på HTTPS (säker webbaccess). Och domänen dmarc.org verkar inte använda DNSSEC…

Prestandatester av hashfunktioner

Den senaste tiden har jag tittat en del på prestanda och beteende hos olika kryptografiska hashfunktioner. OpenSSL innehåller funktioner och kommandon (kommandot speed) för att utföra prestandatester på den plattform dom körs. Maskinen jag kör på är utrustad med en 2.7 GHz Intel Core i7 och kör ett 64-bitars operativsystem. Den testade versionen av OpenSSL är 0.9.8r. När jag testar på min huvudmaskin får jag följande resultat:

Resultat från prestandatest av OpenSSL
Resultat från prestandatest av OpenSSL

Som förväntat är MD5 snabbast, tätt följt av SHA-1. Men en sak värd att lägga märke till är prestandan för SHA-2-funktionerna SHA-256 och SHA-512. För alla andra testfall än 16 Bytes data är SHA-512 snabbare. Detta kan tyckas underligt, om man tänker sig att göra avvägning mellan prestanda och säkerhet – att SHA-512 ger högre säkerhet till priset av prestanda. SHA-512 utför även 80 iterationer för att bearbeta ett datablock, och SHA-256 bara 64 iterationer. Men SHA-512 använder 64-bitarsoperationer och arbetar på större block än SHA-256 – 128 Bytes kontra 64 Bytes. Detta gör att SHA-512 på en maskin som min blir effektivare.

NIST, organisationen som specificerat SHA-2 (och SHA-1 samt arbetar med att ta fram SHA-3) har insett detta och presenterade i början av 2011 en ny version av specifikationen FIPS 180. Detta dokument specificerar SHA-1 och SHA-2. I den nya versionen finns det två nya funktioner – SHA-512/224 och SHA-512/256. Precis som SHA-384 är dessa funktioner SHA-512, men där det genererade hashvärdet kapas av till den bitstorlek som önskas. Använder du SHA-256 och har prestandaproblem kan det därför vara värt att titta SHA-512/256 på dessa funktioner.

Notera att SHA-384, SHA-512/224 och SHA-512/256 inte är exakt samma funktion som SHA-512. Det som skiljer är initialvärdena i interntillståndet. Dvs att implementera SHA-512/256 kräver lite mer än att köra med SHA-512 och kasta bort den högra halvan av hashvärdet. Koden i implementationen måste ändras, om än i liten grad.

För den som vill titta närmare på prestandan hos många olika hashfunktioner inklusive finalisterna i SHA-3-tävlingen finns det massor med data hos EU-projektet eBASH.

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.

SSH-klient i webbläsaren och bra dokumentation för OpenSSL

Secure Shell (SSH) är ett protokoll för säker anslutning mot datorer över Internet. SSH är även namnet på den terminalapplikation som implementerar protokollet för att ge interaktiv, säker access. SSH används ofta för att tunnla andra protokoll. Bilden nedan visar hur SSH används för att tunnla X11-protkollet så att fönster på fjärrmaskinen visas på den lokala maskinen.

SSH som tunnlar X11-protokollet.

Det finns även flera andra applikationer som implementerar ssh-protokollet. Ofta byggs dessa på bibliotek som libssh2.

Gate one är en implementation av en SSH-klient skriven i HTML5 som körs direkt i webbläsaren. Gate One. Några fördelar med Gate One enligt dess webbplats är:

  • No browser plugins required!
  • Supports multiple simultaneous terminal sessions. As many as your hardware can handle.
  • Users can re-connect to their running terminals whenever they like from anywhere.
  • Can be embedded into other applications.
  • Includes powerful plugin system that supports plugins written in Python, JavaScript, and even CSS (yes, you can write a CSS-only plugin).
  • The Gate One server can be stopped & started without users losing their running terminal applications (even SSH sessions stay connected!). In essence, worry-free upgrades!
  • The SSH plugin allows users to duplicate sessions without having to re-enter their username and password (it re-uses the existing SSH tunnel).
  • Provides users with the ability to play back and save/share their terminal sessions via a self-contained HTML playback file.
  • Similarly, supports server-side logging, recording, and video-like playback of user sessions.
  • It can even log to syslog to support whatever centralized logging system you want.
  • Keberos-based Single Sign-on support is included. It even works with Active Directory. Other authentication options are available as well.

Det finns ingen testsida för Gate One, däremot en demofilm på Vimeo:

Gate One Beta Demo from Dan McDougall on Vimeo.

Gate One är ett exmpel på hur webbläsaren allt mer blir en ersättning för det lokala datorskrivbordet och den grafiska miljön. Men även om Gate One inte beror av några plugins utan bara websockets krävs det en del på serversidan för att få det hela att snurra. Dokumentationen för Gate One beskriver mer om vad som krävs för att sätta upp Gate One som terminalgränssnitt för din webbtjänst.

Ett bibliotek som Gate One använder är OpenSSL (via Python-wrapperns PyOpenSSL.

OpenSSL och dess underliggande bibliotek libssl är en mycket kraftfull verktyslåda som används i applikationer för att skapa säker kommunikation, som implementation av specifika algoritmer (krypto, hashfunktioner, protokoll) samt för som interaktivt verktyg. Behöver du på något sätt arbeta med säkerhet är det en stark rekommendation att lära dig mer om OpenSSL.

En bra start för detta kan vara den här användarhjälpen (HOWTO) som visar hur du kan lösa specifika problem med OpenSSL. Bra, tydlig och klart läsvärd.

STEED – Initiativ för kryptering mellan ändpunkter

Sprang på ett nytt säkerhetsinitiativ kallat STEED. Tanken med STEED är att utveckla kryptering som spänner hela vägen mellan ändpunkterna i en kommunikation och skall vara så enkel att använda att det alltid (ofta) används. Initiativtagarna till STEED skriver:

End-to-end e-mail encryption is still ignored by almost all users. The mails are left in the clear in the mailboxes of the web mail providers, where they are frequently collected by attackers and lead to an escalation of the attack due to the sensitivity of the mail content. We suggest a new and simplified infrastructure to protect mail that is compatible with OpenPGP and S/MIME and relies on an easy-to-use trust model without a central administration.

Initiativtagarna är i det här fallet Marcus Brinkmann och Werner Koch från Tyska företaget g10CODE, kanske mest kända för att driva utvecklingen av GnuPG.

Det SPEED är tänkt att erbjuda är saker som:

  • Automatisk nyckelgenerering
  • Automatisk nyckeldistribution
  • Opportunistisk kryptering
Tillsammans är detta egenskaper avsedda att göra säkehetsanvändningen så osynlig som möjligt som användaren. I första hand verkar STEED vara fokuserat på mailtjänster. Det finns en artikel av Marcus och Werner som närmare beskriver vad de vill åstadkomma med STEED och hur detta är tänkt att ske. Vi får se om STEED flyger eller inte, men initiativ som gör säkerhet enklare att använda och därmed mer utbredd gillar jag.

Säkerhet och management av miljarder Internetsaker

Ett av det mest intressanta trenderna tycker jag är Internet of Things – tanken att enkla saker ges en enkel, digital intelligens, kopplas upp på Internet och blir en del av informationsflödet. Att koppla upp allt på nätet och därmed göra det möjligt att övervaka och styra ger helt nya möjligheter.

Att exempelvis kunna läsa av och styra enskilda lampor i kontor och fabriker gör det möjligt att optimera ljussättning och därmed energianvädningen mycket mer exakt än idag. Cisco har gjort en mycket snygg illustration som förklarar Internet of Things.

Samtidigt, för att detta ska gå att genomföra behöver vi kunna lita på att de saker vi pratar med verkligen är de saker vi tror att det är. Vi behöver även kunna lita på den information som sakerna skickar. Och dessutom måste det gå att begränsa access till sakerna så att bara den som har rätt att styra sakerna får göra det. Vad det handlar om är klassisk IT-säkerhet och client-server-management – men för miljarder av enheter i komplexitet, noll kronor i kostnad och utan att förbruka energi.

Detta låter inte precis enkelt – och det är kanske till och med omöjligt. Naturligtvis kan inte kostnad och energiförbrukning vara exakt noll. Den forsknings- och ingengörsmässiga utmaningen är att hitta mekanismer (protokoll, system, komponenter) kapabla att skala upp till den komplexitet som det stora antalet enheter ställer, men där den lokala komplexiteten (per enhet) är så låg att den möter kostnads- och energibudget. För inbyggda system, och speciellt där det är systemet som skall läggas till en så enkel sak som en lampa, är kostnaden väsentligen noll. Det enda som räknas är funktionaliteten – och säkerhet är inte en del av funktionaliteten, den är bara ett sätt att säkra funktionaliteten.

Jag tycker dock att det låter utmanande, extremt lockande och jag ser att lösa dessa utmaningar är nyckeln till att visioner som Ericssons 50 Billion Connected Devices 2020 ska kunna lyckas. (Tyvärr ser jag inte att Ericsson pratar om dessa utmaningar i sin presentation, men den handlar i första hand om att sälja in visionen – inte beskriva vad som krävs).

En viktig komponent i säkerhetskedjan är tillgången på bra krypton. Nu vill jag direkt säga en sak: Jag stöter ofta på fall där man av olika skäl kommit fram till att systemet och affären runt systemet (produkten och eller tjänsten) kräver någon form av skydd. Och att man därför landat i att man behöver kryptera. Oftast har man dessutom tagit ett steg till och valt AES-256 som kryptolösning. Inte sällan är detta fel.

Hur kan det vara fel, undrar du säkert? Om vi tar glödlampan som exempel igen. Hur viktigt är det att någon utomstående vet att lampa med ID-nummer 31415926535 är tänd eller släkt – vad skulle kunna hända om den informationen kom i orätta händer? Det kan säkert finnas scenarion där det kan vara viktigt.

Det som är antagligen är mycket viktigare är att veta att statusinformationen verkligen kommer från 31415926535 och att du kan lita på att informationen är korrekt. Det som annars skulle kunna hända är att lampa 31415926535 och dess 10000 kompisar som används för att belysa Volvos nybilsparkering är släkta/trasiga och att tjyven kan härja fritt, men att du tror att dom är tända.

Det som oftast krävs är därför pålitliga identiteter och skydd av ett meddelandes integritet (så att ingen kan pilla på meddelandet utan att det upptäcks av mottagaren). Och ibland även att meddelanden inte går att läsa för den som inte är behörig – att meddelandet är konfidentiellt för andra än sändaren och mottagaren.

Ett symmetriskt krypto som AES ger i första hand konfidentialitetsskydd. Det kan även används för att ge integritetsskydd och identitetskontroll och förutsätter att sändare och mottagare på något sätt redan kommit överens om nycklar. Vanligare är att asymmetriska krypton (kallas även krypto med publika nycklar) och hashfunktioner används att etablera identitet och integritet.

Tyvärr är det svårt att hitta bra algoritmer som inte kostar för mycket. Speciellt asymmetriska algoritmer finns det för närvarande inga som egentligen fungerar för Internet of Things. Det som är positivt är att problemet har börjat uppmärksammas. EU-sponsrade ECRYPT II anordnar i november en konferens i ämnet. På konferensen CRYPTO 2011 hölls en rump session där Danilo Gligoroski presenterade del resultat som visar på mycket snabbare/effektivare asymmetriska krypton.

Även protokoll som inte är för komplexa, men samtidigt säkra behöver utvecklas. IETF anordnade i mars en workshop om problemställningarna runt Internet of Things, men än är det långt tills vi har standarder att bygga på.

Secworks gör uppdrag riktat mot utvecklingen av Internet of Things, och kommer att bevaka och försöka bidra till att få fram de teknologier som krävs. Jag kommer därför att posta mer om utvecklingen av säkerhet och management för Internet of Things här. Bland annat om de riktigt kompakta algoritmer och implementationer som faktiskt finns redan i dag. Häng med!