Naar aanleiding van mijn blog over de veiligheidsrisico’s van federatieve identiteiten schreef mijn collega Eric Verheul een kritische reactie. Volgens hem maak ik een denkfout en hebben ook niet-federatieve vormen van authenticatie hetzelfde veiligheidsprobleem. Uit zijn reactie maak ik op dat de essentie van mijn kritiek op federatieve authenticatie niet helemaal goed is overgekomen. Bij deze een nieuwe poging.

Eric schrijft:

Allereerst is de tegenstelling tussen beide vormen van authenticatie minder groot dan wat Jaap-Henk lijkt aan te geven. Beide vormen zijn namelijk gebaseerd op een ‘vertrouwde derde partij’ die na zorgvuldige controle van de identiteit van de aanvrager deze het
middel overhandigt.

Dat suggereert een bepaalde vorm van niet-federatieve authenticatie, die ik nadrukkelijk niet voor ogen had toen ik het artikel schreef. Het punt is juist dat er geen ‘vertrouwde derde partij’ moet zijn, die mijn identiteit controleert en het middel dat hij uitgeeft daarover uitspraken zou moeten laten doen.

Ik schreef:

Om dit securityprobleem op te lossen moet de gebruiker weer in de loop geplaatst worden. […] Bijvoorbeeld door een sterke vorm van authenticatie te gebruiken die rechtstreeks plaats vindt tussen de gebruiker en de dienstverlener. Op basis van een smart card, een secure USB-token, of cryptografische sleutels op de smartphone van de gebruiker.

De kernbegrip is hier ‘sterke authenticatie’, gebaseerd op publieke sleutel cryptografie. Hierbij wordt gebruik gemaakt van een privé sleutel die alleen bekend is bij de gebruiker en onder zijn exclusieve controle is, en de bijbehorende publieke sleutel die bekend is bij de dienstverlener en verbonden is met de identiteit/account van de gebruiker bij die dienst. (Voor de kenners onder ons in essentie dus de manier waarop ssh gebruikers authenticeert. Ik ben ook groot voorstander van het TOFU (Trust On First Use) principe. Meestal ben ik niet geïnteresseerd in wie je nou precies bent, maar wil ik gewoon weten of je dezelfde persoon/website/etc. bent die ik de vorige keer tegen kwam.)

Omdat mensen zelf geen privé sleutels kunnen onthouden, laat staan de noodzakelijk complexe berekeningen kunnen uitvoeren, moet de authenticatie afgehandeld worden door een ‘authenticatie-middel’: een smart card, secure USB token, smartphone of laptop. Die moeten inderdaad door iemand gemaakt worden, en de gebruiker moet er op vertrouwen dat de privé sleutel veilig blijft en nooit het middel verlaat. In het bijzonder moet het middel zelf de cryptografische sleutels genereren – dit moet niet door de uitgever van het middel gedaan worden. Dat vertrouwen kan vergroot worden door gebruik te maken van open source en open hardware; maar de gemiddelde gebruiker zegt dit natuurlijk niet zoveel.

Het is dus expliciet niet zo dat, zoals Erik schrijft,

[…] een authenticatiedienst […] ‘zomaar’ een middel [zou] kunnen uitgeven aan
een fraudeur dat op andermans naam staat.

Dat werkt niet, want de naam doet er niet toe. De fraudeur moet mijn privé sleutel kennen, en die weet niemand behalve ikzelf (of, precieser gezegd, mijn middel).

De essentie is dat de toegangsbeslissing niet gemaakt moet worden op basis van een identifier (mijn naam of BSN), maar op basis van de kennis van de privé sleutel die hoort bij het account waar toegang toe gevraagd wordt. Een mooi wetenschappelijk artikel over dit onderwerp is Carl M. Ellison, “The nature of a useable PKI“, Computer Networks 31 (1999), pp 823–830. (Helaas geen open access…)

En IRMA dan?

In mijn artikel rep ik met geen woord over IRMA, onze attribuut gebaseerde authenticatie technologie. Dat was met opzet, want het punt was niet om te suggereren dat IRMA beter is wat dit betreft. Dat is namenlijk ook niet (helemaal) het geval. Maar omdat Eric IRMA in zijn stuk noemt is het wel goed om hier even bij stil te staan.

Toegangsverlening binnen IRMA gebeurt op basis van attributen. Met de juiste set van attributen (naam, leeftijd, o.i.d.) krijg je toegang tot een dienst. Niemand kan zomaar valse credentials of attributen creëren. Je zou dus denken dat de volgende op IRMA gebaseerde oplossing om toegang te krijgen tot je bankrekening veilig is.

Stel je hebt een rekening bij de Rabobank. In de registratie fase geeft de Rabobank een credential uit met daarin je rekeningnummer bij de Rabobank als één van de attributen. Als je vervolgens toegang wilt hebben tot je Rabobank rekening, dan moet je dit credential met dit attribuut laten zien. In dit voorbeeld is de uitgever van het credential ook de dienstverlener die het credential verifieert.

Op deze manier toegang verlenen gaat echter nog steeds in tegen Ellison’s principe: we gebruiken een identifier (het bankrekeningnummer), geen cryptografische sleutel. En die identifier is publiek. Met als gevolg dat het mij wellicht lukt om op een of andere manier (social engineering?) de Rabobank credential issuer er van te overtuigen om een credential met jou Rabobank rekeningnummer uit te geven aan mijn IRMA kaart.

Merk op dat in het Rabobank voorbeeld geen sprake is van een ‘vertrouwde derde partij’ die toegang kan verlenen of nemen tot jou Rabobank rekening. Toegang krijg je alleen met behulp van een door de Rabobank uitgegeven credential. En je zou kunnen zeggen dat het hierboven geschetste risico vergelijkbaar is met het risico dat een goede social engineer via de helpdesk altijd wel toegang kan krijgen tot andermans account. Als je IRMA op de hierboven geschetste manier gebruikt voor toegangsverlening is het dus echt anders dan federatieve vormen van authenticatie. Maar je kunt IRMA zeker ook federatief gebruiken. Bijvoorbeeld als Google IRMA credentials uit zou gaan geven waarin mijn Google account naam staat, waarmee ik vervolgens bij AirBnB in zou kunnen loggen.

Het onderscheid tussen federatief en niet-federatief is dus niet zo relevant voor IRMA.

Tot slot

Ik ben blij met Eric’s kritische analyse. Dit soort discussies helpt om de essentiële zaken helder te krijgen. Zodat we in Nederland een veilige en privacyvriendelijke eID krijgen. En dat is in het belang van iedereen.