Je kent het vast wel: je stapt een winkel binnen die je nog niet eerder bezocht, en wanneer je buiten komt, heb je er weer een klantenkaart bij, mooi in de standaard vorm van de vele andere kaarten die je net niet allemaal in je portefeuille krijgt. Binnenkort krijgen er we dan ook nog het nieuwe Europese rijbewijs in bankkaartvorm bij, en voor wie met de trein reist, werd kortgeleden de mobib-kaart ingevoerd, die vroeger enkel voor de metro was bedoeld. We hebben tegenwoordig dus kaarten om te betalen, om korting te krijgen, voor transport, voor identificatie, om deuren te openen, enz. enz. Kortom: er zit meer plastic in onze portefeuille dan geld.

Nochthans zijn er mogelijkheden om de kaartenberg te verminderen. Zo voerde de belgische tak van de oudste bank ter wereld onlangs de paschicombo kaart in. Deze kaart combineert maestro (een zeer courante vorm van debetkaarten, waarmee je quasi overal geld uit de muur kan halen), mastercard (een kredietkaart), een geïntegreerd schermpje waarop éénmalig bruikbare codes komen te staan voor online transacties (eigenlijk een soort eenvoudige digipass), en paypass (een contactloze manier om te betalen door je kaart ergens tegen te “tappen”, en bovendien een online portefeuille). Paypass zit trouwens ook al in een aantal smartphones, die je via Near Field Communication (NFC) op dezelfde manier kan gebruiken.

Ook onze eigen overheid zit niet stil: vanaf 2014 zullen de SIS-kaarten verdwijnen; ze worden vervangen door de belgische eID-kaart, een kaart waarmee België sinds 2003 uitpakt in e-government. We zullen dus niet alleen onze belastingaangifte kunnen doen, maar ook naar de apotheker kunnen gaan met de eID, en dit zijn slechts twee van tientallen toepassingen van de overheid, of honderden andere. Ironisch genoeg kan je via je eID zelfs een online aangekocht treinticket gebruiken, zonder noodzaak aan een mobib-kaart.

Functionaliteiten

Om uit te vissen of we een aantal kaarten kunnen integreren en vervangen door één enkele “superkaart”, kunnen we de meest gebruikte toepassingen, en hoe deze doorgaans worden geïmplementeerd, even overlopen.

• In het gros van de toepassingen van de eID en van de vele lidkaarten van winkels en andere zaken, wordt eigenlijk enkel gebruik gemaakt van identificatie. Dit kan al dan niet met sterke authenticatie (in de zin van: een sterk bewijs van je identiteit, dat alleen door jou kan worden gegeven). Identificatie kan op allerlei manieren: met of zonder gebruik van PIN-code, met of zonder actieve processor op de chip, met of zonder RFID-tag… De meeste handelszaken werken zelfs met een eenvoudige barcode of soms met een QR-code.

In principe hebben we, wat eenvoudige identificatie betreft, genoeg aan één enkele kaart: Het volstaat om de streepjescode op de eID te hergebruiken! Wanneer iets meer beveiliging is vereist, kunnen we NFC gebruiken (“tappen”). Willen we echt op safe spelen, dan moeten we werken met de PIN-code. Al deze zaken kunnen kunnen gemakkelijk in één kaart worden geïntegreerd.

• Naast identificatie is er ook het uitlezen van gegevens. De gegevens staan in dat geval, al dan niet geëncrypteerd, op de chip, en kunnen eventueel zelfs bewerkt worden. Zo staan b.v. ons adres en onze foto op de eID. Het opslaan van gegevens op de kaart zelf is vooral nuttig voor het geval er geen netwerkverbinding mogelijk is.

Voor de meeste eenvoudige toepassingen lijkt gegevensopslag op de kaart mij een overbodige functionaliteit. Alle nodige informatie kan immers in een database worden gezet, gekoppeld worden aan de identiteit van een bepaalde gebruiker en via het netwerk worden opgehaald. Zo werken nu reeds de meeste klantengetrouwheidssystemen: men haalt de kaart langs een barcode scanner en de kassa weet vanzelf of er al genoeg punten werden gespaard voor een korting. Indien nodig kunnen we voor eventuele complexere toepassingen het uitlezen van gegevens altijd nog koppelen aan het gebruik van de chip zelf (waarbij je de kaart ergens in stopt), en dit met PIN-code voor echt gevoelige gegevens.

• Nog een toepassing, vooral in bancaire milieus, is het genereren van antwoorden bij een challenge-response beveiliging. Eigenlijk is dit niet meer dan een sterke vorm van identificatie/authenticatie, maar er is wel geavanceerdere apparatuur voor nodig: meestal moet men de kaart hiervoor in een digipass of andere kaartlezer stoppen. Bovendien is dit vaak een complexe procedure, waarin ook het gebruik van een PIN-code is vereist.

Desalniettemin bewijst de eerder vernoemde paschicombo kaart dat men ook bij deze technologisch uitdagende zaken een verregaande integratie kan bereiken: stop alles gewoon in de kaart (zelfs het numeriek klavier).

• Ten slotte is er nog de digitale handtekening, in de eerste plaats een toepassing van onze eID-kaart. Hiervoor moeten er certificaten op de kaart aanwezig zijn.

Gelukkig komt het gebruik hiervan niet zo vaak voor, en dan nog voornamelijk via de eID. Hier is het herleiden tot één kaart dus reeds een gegeven.

Afsluiter

Het zou dus moeten kunnen om een groot aantal van de vele kaarten die we tegenwoordig moeten rondslepen, te herleiden tot één enkele superkaart (op deze na dan…). Meer nog: onze eigen eID-kaart biedt hiertoe al heel wat mogelijkheden.

Ik laat het aan de lezer om in de comments eventuele problemen te melden, zowel van technologische als van algemeen-praktische aard, die roet in het eten kunnen gooien bij de introductie van een eenheidskaart.

OAuth is een systeem dat toelaat om aan derde partijen een sleutel te geven waarmee ze op een site toegang krijgen tot jouw gegevens.  Typische voorbeelden zijn (web)toepassingen die toegang wensen tot je Facebook- of Twitter-gegevens.
Je geeft deze toepassingen niet je gebruikersnaam en wachtwoord maar een token waarmee ze toegang verkrijgen. De geldigheid van dit token kan beperkt worden in scope en tijd. Je kan dit token ook “revoken”. Op Twitter is er bijvoorbeeld een pagina (in settings / Applications) waar de lijst met applicaties wordt getoond waarvoor er een token bestaat.

Het principe van OAuth is vrij bekend aangezien het sterk lijkt op processen in federatiestandaarden zoals SAML en WS-Trust. Er zijn drie partijen: de client, de resource owner en de server, respectievelijk user, consumer en Salesforce in de figuur. De client is een stuk software of een dienst die toegang wenst tot resources op een server.

Kort gezegd werkt het als volgt, meer uitleg op de OAuth website:

• De server is bekend met de service die de client aanbiedt. De client dient zich op voorhand te registeren (ze beschikken over een “shared secret”).
• Als de client toegang wil tot bepaalde resources dient hij gebruik te maken van een access token.
• Dit access token wordt verkregen door de resource owner zich te laten aanmelden op de server. Hierdoor krijgt de client eerst een request token dat na validatie wordt ingewisseld voor een access token.
• Met dit access token kan de client dan de toegelaten resources opvragen, binnen de voorwaarden van de resource owner.

Merk op dat er directe communicatie is tussen de client en de server voor het verkrijgen van het access token. OAuth is ook niet beperkt tot implementaties voor pure webapplicaties. Het kan ook dienen voor clients op mobiele toestellen of servers die toegang wensen tot bepaalde resources of gegevens.

OAuth heeft reeds heel wat historiek achter zich. Het is ontstaan uit de OpenID community en is als versie 1.0a geïmplementeerd bij een aantal grote spelers (zoals Twitter). OAuth v1 heeft echter met veel kritiek te maken, met name qua complexiteit. Door het gebruik van digitale handtekeningen is het systeem zeer implementatiegevoelig aan de client-zijde. Aangezien OAuth door velen in de REST-wereld werd gezien als een licht alternatief voor ‘zware’ XML-Security implementaties, viel dit niet in goede aarde.

Daarom werd OAuth 2.0 een volledige herziening van de specificatie en ook ingediend bij IETF ter standaardisatie. Er is hierom echter weer kritiek omdat men op veiligheidsvlak een aantal toegevingen doet om de complexiteit te verlagen. Indien er geen gebruik gemaakt wordt van SSL zijn er serieuze veiligheidsrisico’s. Het gebruik van handtekeningen is nog steeds mogelijk maar niet verplicht.

Google en Facebook maken momenteel gebruik van OAuth 2.0 voor de toegang tot hun APIs.

Zijn de andere federatiestandaarden dan nutteloos? Neen, OAuth kan je ook perfect gebruiken in combinatie met standaarden zoals SAML, zoals hier wordt aangetoond.

Moeten we nu met zijn allen overstappen op OAuth? Natuurlijk niet, maar het is wel belangrijk te weten wat voor standaarden opgang maken bij de grote internetspelers.

Het algoritme is natuurlijk maar één onderdeel van de token. Er is immers nog een seed (symmetrische sleutel) en een pincode nodig om het One-Time-password te kunnen berekenen. Die seed is specifiek gebonden aan de token en wordt bijgehouden in een databank. Er is speculatie dat de seed misschien zou kunnen afgeleid worden van het device-number dat achteraan op de token staat. Indien men in slaagt om ook seeds te stelen of af te leiden komt men al snel in een situatie waar aanvallen op bronnen die beveiligd zijn met securID realistisch worden.

Er zijn ook geruchten dat het algoritme een back-door zou bezitten voor de amerikaanse overheid. Momenteel blijft het allemaal wilde speculatie, ook omdat RSA maar heel beperkt communiceert over het incident.

Het belang van deze inbraak moet niet overschat worden maar toont aan dat steunen op geheime algoritmes niet zo een goed idee is. Gesteld dat het algoritme van de securID tokens publiek wordt dan kan de hele ‘black hat’-wereld op zoek gaan naar mogelijke zwakheden.

Concurrenten van RSA laten alleszins niet na om op klanten van RSA te jagen…