Flera länkar innebär nödvändigtvis inte en fungerande kedja

2010-02-28

De under den senaste tiden uppmärksammade säkerhetsproblem som finns hos bankkort tillverkade enligt EMV-standarden kan knappast ha undgått någon. Kortfattat så kan man med hjälp av en manipulerad kortterminal instruera kortchipet att inte kräva PIN-kod för den aktuella transaktionen. Ett stulet kort kan på så vis användas utan kunskap om koden. Eftersom huvuddelen av de svenska terminalerna kopplar upp sig mot kortinnehavarens bank för att verifiera kortgiltighet är detta i praktiken inte ett så stort problem (inom Sverige).

I sig är problemet kanske inte så revolutionerande, IT-säkerhetsproblem finns det gott om. Det som är fascinerande är de systemproblem som döljer sig bakom. Ofta skyller man säkerhetsproblem på ovilja att betala för den bästa lösningen. Här har den resursstarka bank- och kortindustrin satsat mycket stora belopp på att ta fram EMV men ändå når man inte ända fram. Vad var det egentligen som gick fel och finns det något att lära sig här?

För att kasta lite ljus över detta har jag försökt identifiera några tankevurpor som man gjort på vägen och koppla dem mot vanliga problem som uppkommer vid säkerhetsdesign. Man kan urskilja flera separata problem:

  • Kortet litar på att terminalen är vänligt sinnad.
  • Systemet används inte på det sätt som man föreställt sig när designen tagits fram.
  • Specifikationerna är skrivna av olika parter utan en övergripande ansvarig funktion.
  • Man har fokuserat på mätbara säkerhetsfrågor som stark kryptering och tvåfaktors-autentisering men har missat att verifiera helhetsdesignen på alla protokollnivåer.

 

Det första misstaget är ett uttryck för ett av de vanligaste problemen vid systemdesign, nämligen obefogad förtroende för att externa komponenter kommer att bete sig som förväntat. Tanken att en illasinnad kortterminal skulle välja att inte autentisera kortanvändaren har förmodligen inte slagit den som skrev kommunikationsprotokollet. Läxan är att inte lita på att externa komponenter kommer att bete sig som förväntat och alltid betrakta indata med en sund portion misstro.

Vad gäller det andra problemet så är det inte första gången bankindustrin använder en lösning utanför sitt sammanhang (någon som hört talas om kreditkortsbetalningar på internet). Här är skillnaderna i användning dock mer subtila. Varje av de ingående specifikationerna är helt korrekt inom sin domän men ingen av dem reglerar de bakomliggande kontroller som krävs för att skapa ett säkert sammansatt system. Således har man landat i en de facto-användning som inte överrensstämmer med ursprungstanken. Problemen hade kunnat undvikas om man initialt tänkt igenom hela systemarkitekturen och sedan kontinuerligt verifierat att systemet används som det är tänkt.

Den sista läxan är att inte stirra sig blind på långa nyckellängder och användning av starka autentiseringsmetoder. Om inte gränsytor och oväntat användarbeteende hanteras på ett bra sätt hjälper ingen kryptering i världen. Ett typiskt exempel på detta tänk är Schweiz som övertygades att köpa in kvantkryptering för säker kommunikation mellan vallokaler och den centrala databasen vid valet 2007. Det finns många kända säkerhetsproblem med elektronisk rösthantering huvudsakligen centrerade kring mjukvaran i själva rösträknaren varav kvantkryptering löser exakt inget. En angripare kommer alltid välja den enklaste vägen och angripa den svagaste länken i en kedja. Istället för att se över hela systemet gjorde man enskild länk mycket säker. Självklart försämrar detta inte systemet men punktanvändning av mycket säker teknik kan lätt skapa en falsk känsla av säkerhet.

Det går ganska lätt att dra paralleller från diskussionen ovan till andra utmaningar vi står inför på IT-säkerhetsområdet. Fler och fler tjänster exponeras över internet och vi måste designa och bygga autentiserings- och samarbetslösningar som fungerar på ett säkert sätt hela vägen. Många organisationer står idag i begrepp att implementera eller köpa in lösningar för tvåfaktors-autentisering, identitetsfederationer, eller för all del molntjänster. I många fall uppkommer en helt ny typ av problematik där en organisation plötsligt blir beroende av externa parters säkerhetslösningar. I sådana fall är det ännu viktigare att ha ett helhetstänkande kring systemet, analysera samtliga gränsytor där känslig information exponeras samt inte lita på att extern indata är godartad.

Det enda vi bevisligen har lärt oss av historien är att det svårt att lära sig av historien men det skadar ju inte att åtminstone försöka. Så när vi nu bygger nästa generations autentiseringslösningar tycker jag att vi ska ta chansen och tänka lite längre än den som bestämde sig för att det bästa sättet att godkänna en betalning över internet är kunskap om ett 16 siffror långt kortnummer.

© 2010 Andreas Nilsson, Certezza AB