Kategoriarkiv: Verktyg

Bra samling av bithanteringstrick

Vid konstruktion av digitala tekniska lösningar är det inte ovanligt att man behöver göra olika bitmanipulationer och trick med bitar. Detta gäller inte minst inbyggda system med begränsningar i utrymme och prestanda. Alla erfarna konstruktörer har några favorittrix dom tar till för att effektivt lösa ett problem. Typiska trick är kopiering av data i internregister, hitta mest signifikanta biten som är satt i ett ord eller beräkna paritet.

Sidan Bit Twiddling Hacks har den största samlingen av bithanteringstricks jag sett. Det som gör trixen speciellt intressanta är att i stort sett samtliga tricks formellt verifierats med verktyget UCLID. De flesta trick är mest effektiva på en processor med 32-bitars operatorer (och fungerar ofta bra på mindre arkitekturer). Men vissa av dom är avsedda för maskiner med 64-bitars operatorer eller generellt oavsett bitstorlek.

Jag hittade ett bra trick för att beräkna rank parallellt som i hårdvara fungerade riktigt bra. Du kanske också hittar något matnyttigt?

Rita vågformer med Wavedrom

Vid dokumentation av digitala hårdvarukonstruktioner är vågformsdiagram ofta det bästa sättet att förklara timingberoenden och hur protokoll beter sig på cykelnivå. Ett exempel är den här figuren som visar hur en A/D-omvandlare arbetar:

Timingdiagram för A/D-omvandlare.
Timingdiagram för A/D-omvandlare.

Som konstruktör kan det vara svårt att smidigt skapa bra vågformsdiagram att inkludera i dokumentation. En skärmdump från en vågformsvisare som visar testat beteende ökar sannolikheten att diagrammet stämmer med hur konstruktionen fungerar. Samtidigt kan en skärmdump visa för mycket irrelevant information och även bli svårläst vid utskrift etc. Vilka av följande signaler är relevanta att visa för att entydigt förklara funktionen?

GTKwave med en lite mer komplex vågformsdump.
GTKwave med en lite mer komplex vågformsdump.

Man kan alltid rita med olika verktyg. Jag har genom åren använt ett otal ritprogram som Visio, Star/Open/Libre Office Draw, Excel, yED (ett fantastiskt grafverktyg för övrigt) etc. Detta fungerar och kan ge figurer som skalar snyggt och blir bra vid utskrift. Men det är knappast smidigt och effektivt att rita diagram i rena ritverktyg. En variant av att rita diagrammen för hand är att använda ASCII-grafik.

Sedan finns det flera verktyg som går att använda specifikt för att skapa timingdiagram. TimimgTool är ett sådant verktyg som dessutom kan generera en testbänk för konstruktionen utifrån diagrammet (dvs diagrammet kommer först och är sättet du som konstruktör får beskriva din konstruktion). Ett annat liknande verktyg är TimeGen. Slutligen finns det tillägg/makron för att skapa timingdiagram till typsättningsspråket/systemet TeX. Figurerna som genereras ser jättefina ut, men bieffekten är att man måste använda hårbollen TeX…

Timingdiagram genererat med TeX
Timingdiagram genererat med TeX

Sedan ett tag har Google ett kul, fritt (MIT-licensierat) projekt kallat Wavedrom som i mångt och mycket gör det jag vill kunna göra med timimgdiagram. Utifrån en JSON-beskrivning kan Wavedrom generera diagram i form av SVG-bilder. Fördelen med detta är att det går relativt enkelt att, antingen manuellt i en texteditor, eller verktygsmässigt generera JSON-underlaget för diagrammet. Och eftersom utdata är i SVG-format är det lätt att lyfta in i olika textbehandlare och få figurer som skalar bra och ser snygga ut.

Exempel på diagram med Wavedrom.
Exempel på diagram med Wavedrom.

Wavedrom är byggt med Javascript och HTML5 och det är enkelt lägga in Wavedrom-diagram till en webbsida. Det finns även ett tillägg till Chrome som gör att du kan editera Wavedrom direkt i webbläsaren. Så här ser det ut när jag testar med ett exempel:

Test av Wavedrom i Chrome.
Test av Wavedrom i Chrome.

Om du i ditt jobb sitter och ritar timingdiagram och vill hitta mer effektiva sätt att skapa fungerande snygga diagram hoppas jag att du här hittar några bra alternativ – mitt förslag är att testa Wavedrom.

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…

Artikel på IDG om asymmetrisk kryptering

TechWorlds webbplats finns sedan några dagar en artikel om asymmetrisk kryptering skriven av Secworks.

Här får du min publika nyckel.
Här får du min publika nyckel.

Artikeln tar upp vad asymmetriska krypton och kryptering med publika nycklar är samt hur dom används och vilka problem som finns. Artikeln beskriver även skillnader i nyckelstyrka mellan symmetriska och asymmetriska algoritmer. Dessutom tittar vi i artikeln närmare på flera olika algoritmer som RSA, El Gamal, Elliptic Curve och Curve25519. Förhoppningsvis ger artikeln lite insikt i hur asymmetrisk kryptering fungerar och används.

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.

Kostnaden för att knäcka CAPTCHAs

För en vecka sedan skrev jag om Pensionsmyndighetens beslut att införa en teknisk lösning kallad CAPTCHA för att stoppa robothandel. Det jag försökte visa var att det problem myndigheten sade sig ha inte är en bra lösning – en CAPTCHA stoppar inte datorer, samtidigt som den valda lösningen försvårar för mänskliga användare och slår ut bra tjänster.

reCAPTCHA
reCAPTCHA

En metod för att forcera CAPTCHAs myndigheten öppnar upp sig för som jag beskrev är att använda människor som stödfunktion för datorer. Jag fick efter min postning frågor om hur realistiskt det är  – om det går att göra och om det inte kostar för mycket. Som tur postade Boingboing en artikel om tjänster där människor används för att attackera CAPTCHAs. Och där finns det bra prisinformation. Artikeln handlar om ett ryskt företag, KolotiBablo som kopplar samman arbetare med applikationer som behöver knäcka CAPTCHAs:

Paying clients interface with the service at antigate.com, a site hosted on the same server as kolotibablo.com. Antigate charges clients 70 cents to $1 for each batch of 1,000 CAPTCHAs solved, with the price influenced heavily by volume. KolotiBablo says employees can expect to earn between $0.35 to $1 for every thousand CAPTCHAs they solve.

Dvs maximalt en tusendels dollar för en CAPTCHA. KolotiBablo är lång ifrån den enda tjänsten. Tjänsten med det vackra namnet Deathbycaptcha tar 1.39 USD för 1000 CAPTCHAS och redovisar dessutom lite statistik för sin tjänst. Medeltiden att knäcka en CAPTCHA är 17 sekunder och har 90% chans att lyckas.

För den som vill läsa mer om KolotiBablo finns mer i en artikel om företaget och dess tjänster hos KrebsonSecurity (en artikel som Boingboing pekar på). Det finns även en bra forskningsartikel som tittar närmare på ekonomin för att knäcka CAPTCHAs, en artikel väl värd att läsa om du vill förstå hur denna marknad fungerar.

John Carmack om statisk kodanalys

Programmeraren John Carmack, skaparen av Doom, Quake m.m. har skrivit en mycket läsvärd text om användning av statisk kodanalys för att hitta fel.

John Carmack

John Camrack hackandes Doom.

Att använda statisk kodanalys som del av utvecklingsmetodiken fångar semantiska fel som är svåra eller omöjliga att hitta med kodgranskning, enhetstester eller dynamisk kodanalys, exempelvis minnesövervakning och fuzzing. Vidare, vilket Carmack påpekar, går det inte att undvika att det introduceras fel, oavsett vilka kodregler som skall följas. Speciellt i en stor, levande kodbas kan förutsättningar ändras som gör att fungerande kod påverkas. John Carmack skriver:

A lot of the serious reported errors are due to modifications of code long after it was written.  An incredibly common error pattern is to have some perfectly good code that checks for NULL before doing an operation, but a later code modification changes it so that the pointer is used again without checking.  Examined in isolation, this is a comment on code path complexity, but when you look back at the history, it is clear that it was more a failure to communicate preconditions clearly to the programmer modifying the code.

John tar upp flera exempel på problem där statisk kodanalys hjälpt ID Software att hitta buggar. De två vanligaste buggarna ID Software hittat är hantering av NULL-pekare i C/C++ samt print-formatteringsfel.

Carmack har även testat flera olika verktyg (Coverity, MS/Analyze, PVS-Studio, PC-Lint) och det visar sig att det skiljer mycket vad gäller mängden och typen av buggar olika verktyg hittar. En aspekt på detta, vilket är ett vanligt problem med denna typ av verktyg är att dom ofta genererar stora mängder med varningar, vilket gör det svårt för konstruktören att hitta de viktiga felen och förstå vad som är problemet. Bra verktyg ska inte bara hitta många fel, utan även kunna gradera dom och hjälpa konstruktören till en bra lösning. Inte minst om kodanalys introduceras i en existerande kodbas kan mängden varningar lätt bli övermäktigt. Carmack påpekar att detta var ett problem första gången han försökte använda denna typ av verktyg, men att verktygen förbättrats.

Jag använder det analysverktyg som finns för kompilatorsystemet clang/llvm. Jag tycker att den fångar många buggar och illustrerar dessa på ett relativt bra sätt. Men graderingen av hur allvarlig en bugg är kan helt klart förbättras.

Bild på rapport från clangs analys.
Bild på rapport från clangs analys.

Carmacks slutsats är att statisk kodanalys är ett viktigt tillägg till utvecklingsmetodiken:

It is impossible to do a true control test in software development, but I feel the success that we have had with code analysis has been clear enough that I will say plainly it is irresponsible to not use it.

För den som vill titta närmare på statisk kodanalys har Wikipedia en bra lista med verktyg.

Säkerhetsanalys och Pensionsmyndighetens CAPTCHA

Den första december i år ändrade Pensionsmyndigheten sättet som du som sparare kan få tillgång till ditt PPM-konto. Tidigare kunde olika tredjepartstjänster få rätt att elektroniskt hantera ditt konto åt dig. Men med ett beslut av Sveriges regering och pensionsgruppen stoppades detta.

Skälet till förändringen är att vissa tredjepartstjänster börjat med så kallad robothandel. Datorer sköter förvaltningen och gör massiva mängder av transaktioner, mycket fler än vad en enskild människa klarar av. Tanken med robothandeln är att kunna reagera snabt och tjäna pengar även på små kursrörelser.

Robothandel, även kallad högfrekvenshandel är i sig omtvistat. Tillför robothandel något på börsen eller ej? Ökar riskerna eller ej? Gynnas eller missgynnas olika aktörer för mycket? I Pensionsmyndighetens fall förvärras problemen av att byta värdepapper inte kostar speciellt mycket för spararen, vilket gör att robothandel blir mer attraktivt.

Detta har lett till att volymen transaktioner Pensionsmyndigheten blivit tvungen att hantera drastiskt har ökat, vilket drivit upp kostnaderna för Pensionsmyndigheten. Att få stopp på detta blev därför nödvändigt. Problemet som jag ser det är HUR Pensionsmyndigheten löst problemet. Och här kan vi använda säkerhetsanalys.

Vad är säkerhetsanalys?

När man gör en säkerhetsanalys av ett system försöker man skapa en bild över vilka tillgångar som behöver skyddas, vilka hotbilder (problem) som finns och vilka aktörer aktörerna är. Vidare undersöks vilka metoder (attackvägar) som olika aktörer kan använda och vad dom kan leda
till. Andra ytterst viktiga aspekter att få med i sin bild är att identifiera vilka implicita och explicita antaganden som finns – och vad som händer om dessa antaganden inte gäller.

Med hjälp av den systembild, den beskrivning som arbetats fram plockas sedan motåtgärder fram. De åtgärder som plockas fram behöver sedan analysera utifrån påverkan på systemet. Blir systemet sämre för legitim användning? Ökar kostnaderna för systemet? Ställer åtgärden krav på andra förändringar? Och öppnar åtgärden i sig för andra aktörer och attacker?

Det finns olika typer av åtgärder – en del åtgärder gör det svårare och därmed dyrare att genomföra en attack. Andra åtgärder kan vara att begränsa tiden för att genomföra en lyckad attack eller att göra attacken ointressant.

Om vi tar en butik som exempel kan vi försvåra för en inbrottstjuv genom att:

  1. Försvåra och öka kostnaden för ett inbrott genon att sätta in en starkare dörr som kräver rejäla verktyg att forcera.

  2. Minska den tillgängliga tiden för ett inbrott genom att öka antalet besök av väktare (rondering).

  3. Minska butikens attraktivitet för inbrott genom att ta bort dagskassor och stöldbegärliga varor, exempelvis cigaretter.

Ett exempel på ett antagande är att dörren till butiken är låst när butiken inte är bemannad. Är den inte det faller den säkerhet den starka dörren erbjuder.

En säkerhetsanalys behöver återupprepas för att se hur bilden förändras av införda åtgärder.

Om vi väljer att införa den starkare dörren kan den inte vara låst hela tiden. Är den inte upplåst när kan inte legitima kunder besöka butiken, vilket troligen inverkar negativt på verksamheten.

Analysen behöver även upprepas över tid för att fånga upp förändringar i antaganden, aktörer etc. En bra metod, som Microsoft Security Development Lifecycle (SDL) är ett exempel på hur detta sker kontinuerligt. Den generella utvecklingsmetoden kallas spiralmetoden.

spiralbild

spiralbild

Analys av Pensionsmyndighetens problem

Det problem som Pensionsmyndigheten säger sig ha är att antalet transaktioner som utförs drastiskt har ökat, och överstiger det antal man varit beredd att hantera. Några lösningar på detta hade varit att:

  • Skala upp sin verksamhet för att klara mycket större mängder transaktioner.

  • Begränsa mängden transaktioner en aktör kan göra per tidsenhet.

  • Göra det mindre attraktivt att genomföra högfrekvenshandel.

Men den åtgärd man valt att införa är ingen av dessa, utan att införa en CAPTCHA. CAPTCHA (Completely Automated Public Turing-test to tell Computers and Humans Apart) är en teknisk mekanism avsedd att avgöra om det är en människa eller en maskin som använder tjänsten. Pensionsmyndigheten har alltså fokuserat på att försöka bli av med robotar, inte den stora mängden transaktioner.

CAPTCHAs används av många tjänster på Internet. CAPTCHAs bygger på att ge användaren av tjänsten utmaningar som kräver semantisk analys, bildigenkänning och felkorrektion i text eller bild för att lösa.

Denna typ av problem är människor traditionellt mycket bättre än datorer på att lösa. Men utvecklingen går fort framåt och datorer har flera gånger visats sig klara av att lösa CAPTCHAs som ansetts säkra. CAPTCHAs får heller inte vara för komplicerade, då blir det för svårt för användarna att använda tjänsten.

Många aktörer, exempelvis de som vill skicka SPAM lägger ner mycket pengar och energi på att knäcka CAPTCHAs. Det pågår kort sagt ett kapprustningskrig mellan de som försöker skapa skyddet och de som försöker besegra skyddet. En kapprustning Pensionsmyndigheten nu hoppar rätt in i.

Googling på cracking captcha ger 90 miljoner träffar. Sökning med termer som defeating, cracking, breaking på forskningsajter som Citeseer och Arxiv ger totalt flera hundra artiklar om attacker på olika CAPTCHAs.

I Pensionsmyndighetens fall har man valt att köpa in CAPTCHA-tjänsten genom att använda Googles tjänst reCAPTCHA.

reCAPTCHA

reCAPTCHA

Detta innebär att Pensionsmyndigheten till viss del överlåter åt Google att bevaka att funktionen fungerar, och Google sitter på många personer som kan CAPTCHAs. Men det har publicerats hyggliga försök att knäcka reCAPTCHA.

Slutligen finns det i dag tjänster som gör det möjligt att automatiskt ta hjälp av människor för att lösa problem åt maskiner! I det här fallet innebär det att attackera CAPTCHAs med hjälp av människor som mot betalning kan titta på en CAPTCHA och lösa den åt en dator. Ett exempel
på denna typ av tjänst är Amazons Mechanical Turk. (Namnet kommer av den schackspelande robot som visade sig vara en gömd människa.)

Som jag som utomstående ser det har Pensionsmyndigheten inte löst rätt problem – att få ner mängden transaktioner. Istället har man infört en åtgärd som försöker avgöra om en legitim användare loggar in själv, eller via ett hjälpmedel.

Åtgärden gör det omöjligt för alla att använda elektroniska tjänster för att hantera sitt sparande. Det stoppar alltså inte bara volymhandel, utan aggregeringstjänster, försvårar för rådgivning etc. Det slår ut ett antal fungerande tjänster och produkter som sparare uppenbarligen tycker är bra.

Vidare är risken stor att CAPTCHAn är för komplicerad och att användbarheten i Pensionsmyndighetens tjänst blir för låg. Även om reCAPTCHA har stöd för personer med synprlem genom att omvandla den visuella utmaningen till ljud innebär CAPTCHAn en mer komplicerad användning.

Och kanske mest problematiskt är kanske att åtgärden egentligen inte löser problemet – den gör det svårare att utföra maskinella transaktioner. Men myndigheten kommer att behöva övervaka att den tekniska lösningen fungerar. Vilket kostar pengar.

Eller med andra ord: Fel metod som ger dåligt skydd, blir kostsam att hantera och försämrar användbarheten. Låter som en kanonbra lösning.

Den metod jag tycker att man borde valt är att införa begränsningar i antalet transaktioner som en användare får göra över en viss tidsperiod. Vad som är vettiga värden på antalet transaktioner vet jag inte, men 10 transaktioner per kvartal, per halvår är kanske lagom?

En annan sak. Pensionsmyndigheten påpekar att dom även har problem med att tjänster bara begär ut status för en användares konto – att inte separera statuskontroll och transaktioner. Att kunna hämta ut status kan inte vara lika kostsamt som att göra en transaktion av värdepapper. Även här kunde man infört begränsningar utan att försämra för användarna så fundamentalt som med den metod man valt.

Som säkerhetsanalytiker hoppas jag att myndiheten kommer att undersöka hur åtgärden fungerar, hur den upplevs av kunderna och vilka konsekvenser den fått. Och gärna över tid. Risken är väl att eftersom man (enligt min uppfattning) inte gjort en korrekt analys, inte heller använder en vettig metod.