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
