De veiligheid van internetbankieren is verre van vanzelfsprekend. Banken maken geen cijfers bekend met betrekking tot het aantal fraudegevallen, noch over de hoeveelheid geld die gemoeid is met het schadeloos stellen van de slachtoffers. Maar er komen steeds meer berichten in de media over succesvolle aanvallen op het door de banken zo veilig gepropageerde internetbankieren.

De zwakke plek in de beveiliging ligt bij de computer van de eindgebruiker. Vooralsnog zeggen de banken zich nog niet al te veel zorgen te maken over de proporties van de fraude. Maar de Nederlandse Vereniging van Banken heeft desondanks de ‘3x kloppen’-campagne gelanceerd (zie kader), die als doel heeft om klanten bewust te maken van alle zaken die zij altijd eerst zelf zouden moeten contoleren om veilig te kunnen internetbankieren. Bovendien zeggen specialisten dat de gevallen die nu bekend zijn, slechts de aanloop zijn van een grote golf aanvallen van professioneel georganiseerde computercriminelen, die gebruikmaken van zeer geavanceerde malware.
De vraag is dan: Moeten we met de huidige stand van zaken tevreden zijn en dus de risico’s op de koop toe nemen, of moeten we streven naar een fundamenteel betere beveiliging. En is dat eigenlijk wel mogelijk?

Er moet gewerkt worden aan een fundamenteel betere beveiliging, omdat vrijwel alle door banken gebruikte beveiliging gevoelig is voor ‘man-in-the-middle’- en ‘man-in-the-browser’-aanvallen. Bij een ‘man-in-the-middle’-aanval wordt gebruikgemaakt van een imitatie-bankwebsite die zich voordoet als de authentieke bankwebsite. Deze imitatiebankwebsites zijn in principe te herkennen aan het ontbreken van een (juist) SSL-certificaat. Maar de meeste gebruikers hebben niet de kennis of de wil om het certificaat van een website te valideren (en dit kan mijns inziens ook niet van een gebruiker verlangd worden). Moeilijker te herkennen is de ‘man-in-the-browser’-aanval. De gebruiker werkt hier namelijk met de echte bankwebsite (en dus met geldig certificaat), maar malware die zich in de browser heeft genesteld, manipuleert de door de gebruiker aangemaakte transacties en de gebruiker autoriseert nietsvermoedend de gemanipuleerde transacties.

De infrastructuur om deze aanvallen zeer grootschalig uit te voeren, is aanwezig in de vorm van zogenaamde botnets – netwerken van honderdduizenden, soms zelfs miljoenen, geïnfecteerde computers die op afstand bestuurd kunnen worden. Een vrij eenvoudige manier om misbruik via een ‘man-in-the-middle’- of een ‘man-in-the-browser’-aanval te voorkomen, is om het rekeningnummer van de begunstigde (of de laatste paar cijfers daarvan) in de sleutel voor de opdrachtautorisatie op te nemen. Mocht een transactie gemanipuleerd zijn (en dus een ander begunstigderekeningnummer hebben gekregen), dan werkt de autorisatiesleutel niet meer voor de gemanipuleerde transactie. Het komt er dan bijvoorbeeld op neer dat de gebruiker (de laatste paar cijfers van) het begunstigderekeningnummer invoert op een calculator die daarmee de opdrachtautorisatiesleutel berekent.

Het ‘actieve’ element van het invoeren op een calculator (de gebruiker moet het juiste begunstigderekeningnummer intoetsen om een autorisatiecode te verkrijgen voor de overschrijving) heeft de voorkeur boven het ‘passief’ vermelden van dit gegeven ter controle door de gebruiker in bijvoorbeeld een sms, omdat dit laatste genegeerd kan worden door de gebruiker (‘Het zal wel kloppen, want het klopt anders ook altijd’; dat slijt er in bij vrijwel iedereen die vaker van dezelfde functionaliteit gebruikmaakt). De calculator die gebruikt wordt voor het berekenen van de autorisatiecodes, moet het liefst geen verbinding hebben met de computer (bijvoorbeeld via USB), om manipulatie van het dataverkeer van en naar de calculator of de calculator zelf te voorkomen. Het is hierbij overigens van belang dat iedere transactie zijn eigen sleutel krijgt en er niet één sleutel wordt gegenereerd voor een aantal transacties tegelijk (zoals nu vaak gebruikelijk is). In theorie zou je wel een getal kunnen invoeren dat is afgeleid van meerdere transacties, maar dat is door de gebruiker zelf niet meer herkenbaar als een begunstigderekeningnummer en dit maakt het gevoelig voor manipulatie.

Het inboeten aan gebruiksgemak blijft beperkt; het komt bij particulieren niet zo heel vaak voor dat er meer dan één overschrijving tegelijk wordt uitgevoerd. Het verzamelscherm voor het versturen van overschrijvingen (‘verzendlijst’) is dan overbodig geworden, wat het uitvoeren van enkelvoudige overschrijvingen eenvoudiger maakt.
Dit principe wordt nu al door een aantal banken toegepast, maar pas bij transacties voor grotere bedragen (bijvoorbeeld vanaf duizend euro). Maar vanwege de mogelijkheid van een aanval met behulp van botnets, wat aanvallen mogelijk maakt van miljoenen kleinere transacties (van onder de grens waar deze extra beveiliging wordt toegepast) in korte tijd, wordt het wellicht noodzakelijk om deze beveiliging ook voor transacties met kleinere bedragen toe te passen.
De hoogte van het bedrag waarbij de gebruiker deze vorm van authenticatie moet toepassen, zou bij de internetbankapplicaties dynamisch instelbaar moeten zijn, om een aanval in de kiem te kunnen smoren.

Ruud Kous (ruud.kous@nl.ibm.com) is als IT-architect werkzaam bij IBM Nederland.

Ultieme oplossing Mocht in de toekomst blijken dat de browser­applicatie niet afdoende is te beveiligen, dan kan worden overwogen om van de ‘normale’ browserapplicatie af te stappen. Te denken valt dan bijvoorbeeld aan een browserapplicatie die draait in een omgeving die de applicatie beschermt tegen elke vorm van manipulatie van buitenaf (een soort omgekeerd ‘sandbox’-principe: een ‘sandbox’ beschermt de computer tegen mogelijk malafide applicaties in de browser, maar wat we hier willen is dat de applicatie beschermd wordt tegen mogelijke malware op een geïnfecteerde computer). Nadeel bij dit principe is de afhankelijkheid van de ‘waterdichtheid’ van deze beschermende omgeving. Een rigoureuzere mogelijkheid is om de bank­applicatie te draaien vanaf een onbeschrijfbaar medium (bijvoorbeeld een cd-rom) en de computer daarvan te laten opstarten – dus niet van de harde schijf – zodat de computer altijd vrij is van malware als de bankapplicatie draait. Gebruikers zullen het echter niet op prijs stellen als ze hun computer opnieuw moeten opstarten, elke keer als ze willen internetbankieren. Een alternatief hiervoor zou zijn om deze schone omgeving in een ‘virtual machine’ (VM) op te starten, zodat de pc niet opnieuw gestart hoeft te worden. De vraag is echter hoe lang de VM veilig zal blijven, want VM-manipulatietechnieken worden steeds geraffineerder, zowel in positieve als in negatieve zin. De bank zou daarom kunnen overwegen om de applicatie niet meer op de (mogelijk geïnfecteerde) computer van de gebruiker te draaien, maar op de server van de bank zelf. Deze heeft de bank zelf onder controle. De gebruiker kan de applicatie dan bedienen via een ‘terminal-client’. Een dergelijke client doet niets meer dan het weergeven van wat er op de server draait en het doorgeven van de interactie van de gebruiker met de applicatie naar de server. De applicatielogica kan daarom niet via deze client gemanipuleerd worden. Wat wel mogelijk zou zijn, is dat malware op de computer van de gebruiker de weergave van de terminal-client naar de gebruiker en de actie van de gebruiker naar de server zou manipuleren. Maar een terminal-client leent zich daar wat minder voor dan een browser. De ultieme oplossing is misschien wel een apparaat dat speciaal en uitsluitend geschikt is voor digitaal bankieren. Te denken valt aan een pda-achtig apparaat, dat niet door de gebruiker aan te passen is. Dit apparaat zou de pc en de calculator combineren in één apparaat. De gebruiker kan het overal mee naartoe nemen en zodoende overal ter wereld digitaal bankieren, zolang er maar een (mobiele) netwerkverbinding is met het internet.

Drie regels voor consumenten De ‘3x kloppen’-campagne van de Nederlandse Vereniging van Banken (NVB) wil gebruikers van internetbankieren bewust maken van drie regels waar de consument zich aan moet houden bij het internetbankieren: ▪ De pc-beveiliging dient up-to-date te zijn. ▪ De gebruiker dient te controleren of de website waarop wordt ingelogd ook echt van de bank is. ▪ De gebruiker dient betalingen, gedaan via internetbankieren, altijd te controleren. Het eerste punt heeft betrekking op het besturingssysteem, (draadloos) netwerk, browser, firewall, antivirus en antispyware. Het besturingssysteem en de browser worden tegenwoordig vaak automatisch geüpdatet en antivirus is ook behoorlijk ingeburgerd, evenals de firewall (dankzij Windows XP SP2). Maar de beveiliging van het draadloze netwerk en antispyware zijn nog lang geen gemeengoed. Mogen we van een gemiddelde consument verlangen dat hij al deze zaken voor elkaar heeft? Hetzelfde geldt voor het tweede punt: Is het raar als een internetgebruiker er niet op let of het adres van de website begint met https in plaats van http? Laat staan of een gebruiker het digitale certificaat van een website verifieert. En als het inlogproces anders verloopt dan anders, dan is er wellicht een nieuwe versie van de internetbankapplicatie beschikbaar gekomen, toch? Wat betreft het derde punt: een gebruiker die zelden een betaling via internetbankieren doet, zal deze waarschijnlijk nauwgezet controleren. Maar iemand die dat zeer regelmatig doet, zal niet iedere keer alle schermen bestuderen. Vroeger waren computers voor techneuten en hobbyisten, van wie je dit soort zaken mocht verwachten. Maar tegenwoordig gebruikt bijna iedereen een pc of laptop en de meeste computergebruikers bankieren ook via internet. Het zijn echter niet meer het type mensen dat zich bekommert om firewalls, netwerkbeveiliging, internetcertificaten en dergelijke.