ING mobiel bankieren authenticatie

Op 8 november 2011 introduceerde ING mobiel bankieren. Met een speciale ING Bankieren app kan een Mijn ING account gekoppeld worden aan een smartphone of tablet. Tijdens dit proces wordt een 5-cijferige pin code gekozen die daarna (samen met het device) genoeg is om de rekeningen in te zien, en geld over te maken.

1. De app vraagt om het invullen van de gegevens van de bankpas. Hierna wordt een verbinding gemaakt naar URL https://services.ing.nl/mb/registration/registerProfile waarbij de volgende POST variabelen worden meegegeven:
   1. deviceType: iPhone 4S
   2. profileId: GUID die de app op dit device identificeert
   3. encSymmetricKey: 512 character hex string
   4. deviceBrand: Apple
   5. publicKey: 256 character hex string met daarachter 5 (controle?) bits
   6. osVersion: iOS version
   7. deviceTag: naam die de gebruiker aan het device heeft gegeven (Richard’s iPhone)

   De server antwoordt hierop met een JSON data structuur die oa een sessiesleutel en een signature bevat. Het doorgeven van een publicKey duidt op het genereren van een public/private key paar op het device. De private key blijft op het device staan, de public key slaat ING centraal op zodat in de toekomst het device hiermee kan worden geauthenticeerd.

2. De volgende POST is naar https://services.ing.nl/mb/registration/proveIdentity waarbij de variabelen debitCardExpirationMonth, debitCardCode, accountNumber en dateOfBirth meteen al versleuteld worden verstuurd. Er wordt dus niet vertrouwd op de SSL encryptie, maar men past binnen SSL een eigen encryptie toe op de waarden van de variabelen. De server stuurt een JSON antwoord met een versleutelde apiResponse.

   

3. De gebruiker moet vervolgens met een webbrowser inloggen op mijn.ing.nl en krijgt na het invoeren van een TAN code een controle getal te zien. Dit getal moet worden ingevoerd in de app op het mobiele device. De app vraagt dan https://services.ing.nl/mb/authentication/getVariables op, waarbij de profileId GUID wordt meegegeven. Het antwoord is een JSON structuur met oa srpSalt en serverSrpKey variabelen. Dit duidt op het gebruik van het Secure Remote Password protocol. Hiermee kan een geheime sleutel worden afgesproken zonder dat een eventuele afluisteraar deze te weten komt. Dit vindt dus plaats binnen het SSL protocol dat ook al (enigszins) tegen afluisteren is beveiligd. Het controle getal wordt vervolgens versleuteld verstuurd naar https://services.ing.nl/mb/authentication/checkActivationCode
4. De gebruiker moet in de app de voorwaarden accepteren. Er wordt een hash van de voorwaarden verstuurd naar https://services.ing.nl/mb/authentication/acceptTerms.
5. De gebruiker moet nu een 5-cijferige PIN code kiezen voor beveiliging van de app. Deze code wordt versleuteld verstuurd naar https://services.ing.nl/mb/authentication/registerPin. Vervolgens worden er een aantal sleutels opgevraagd via https://services.ing.nl/mb/authentication/getSymmetricKey en https://services.ing.nl/mb/authentication/getSessionKey.

   

6. Nu de registratie is geslaagd, wordt bij elk volgend gebruik van de app alleen de PIN code gevraagd. Nog voordat die wordt ingevoerd wordt /mb/authentication/getVariables al opgevraagd om het SRP protocol te starten. De PIN wordt daarna versleuteld verstuurd aan /mb/authentication/checkPin waarna weer /mb/authentication/getSymmetricKey en /mb/authentication/getSessionKey worden opgevraagd.

Het authenticatie protocol ziet er goed doordacht uit. Er wordt niet vertrouwd op SSL of TLS. In plaats daarvan gebruikt ING een extra encryptielaag waarvoor het wachtwoord wordt afgesproken via het SRP protocol. Ook genereert elk mobiel device een eigen profileId en een public/private sleutelpaar.

Toch had ik had graag gezien dat de app de uitgever van het SSL certificaat van services.ing.nl had gecontroleerd. Dan was het voor mij (en een eventuele aanvaller) veel moeilijker geweest het protocol te achterhalen. Google Chrome doet dit bijvoorbeeld voor mail.google.com waardoor de man-in-the-middle aanval in Iran en de Diginotar hack werd ontdekt.

Als de registratie eenmaal is gedaan lijkt me dit protocol vrij robuust, ervan uitgaande dat de encryptie sterk is en goed is geïmplementeerd. De grootste kwetsbaarheid zit hem in het registratieproces. Als er tijdens dit proces iemand tussen het mobiele device en de services.ing.nl server in zit (man-in-the-middle), dan is het theoretisch mogelijk om het registratieproces te kapen, en namens de gebruiker de registratie te voltooien. Een aanvaller moet dan wel het hele registratieprotocol inclusief encryptie reverse engineeren en live na weten te bootsen. Ook is een vals SSL certificaat voor services.ing.nl nodig. Deze factoren maken het niet gemakkelijk of zelfs waarschijnlijk dat iemand een man-in-the-middle aanval op een gemiddelde ING klant weet uit te voeren tijdens het registratieproces.