Het Probleem
De recente problemen met de OV-chipkaart zijn een mooi voorbeeld van hoe het ontbreken van IT-professionals in de politiek ons een hele hoop extra belastingcenten kan kosten. De interne cryptografie van de OV-chipkaart is al een poosje (sinds 2005) gekraakt. Dat is ook niet iets waar je verbaasd over moet zijn. Uiteindelijk is met voldoende tijd en moeite elke vaste cryptografische sleutel te kraken.Inmiddels is er al software op internet te vinden waarmee iedereen met een RFID kaartlezer de inhoud van een chipkaart kan kopiëren en aanpassen. Zo kunnen ze dus kunstmatig hun saldo ophogen door het saldo aan te passen of hoog houden door oude kopieën van de gegevens op hun kaart terug te plaatsen.
Ook is het nu mogelijk om je kaart zogenaamd "in te checken" op een station naar keuze. Het apparatuur van de conducteurs beschikt niet over de middelen om te checken met de servers van het hoofdkantoor of de kaart ook daadwerkelijk is ingecheckt, en controleert enkel of de op de kaart zelf staat dat deze is ingecheckt.
Je zal je nu misschien afvragen: hoe is het mogelijk dat éénieder de inhoud van de kaart kan wijzigen, en dat dit vervolgens geaccepteerd wordt door elke kaartlezer. Wel, het is heel simpel. Er valt zoals de kaarten nu gebruikt worden niet te verifiëren door wie de data op de kaart als laatste is aangepast.
De eerstgenoemde methode is nog vrij makkelijk achteraf te detecteren, aangezien elke kaart een ID heeft, en de hoofdcentrale van Trans Link Systems weet hoeveel saldo er op een elke kaart zou moeten staan achteraf worden alle check-ins bij een dagelijkse "sync" gecontroleerd, en zullen kaarten waarbij de aangegeven saldo niet overeenkomt met wat er op zou moeten staan worden geblokkeerd.
De tweede methode is vooralsnog niet te detecteren. Waarschijnlijk omdat de kaartleesapparatuur van de conducteurs nog geen gegevens bijhoudt over hoeveel saldo er stond op elke kaart die ze gelezen hebben, en er ook nog geen procedure is om deze gegevens na elke dienst te uploaden naar de centrale servers van TLS.
De niet-oplossing
Het antwoord van TLS: Ze zijn (betere) fraudedectiestystemen aan het ontwikkelen, en ze willen in de loop van vijf jaar nieuwere, zogenaamd beter beveiligde, SmartMX-chips introduceren...Het is heel erg teleurstellend dat TLS op de proppen komt met zo'n hersenloze oplossing. Ten eerste zijn de oude kaarten nog een lange tijd geldig (tenzij je mensen dwingt over te stappen op de nieuwe kaart, TLS heeft echter zelf aan aangegeven dat ze dat niet van plan zijn) wat dus het probleem de komende vijf jaar nog niet oplost. En ten tweede kan je op je vingers natellen dat deze nieuwe chips net zo rap gekraakt zullen worden als de vorige. Bovendien zijn fraudedectiesystemen enkel in staat de fraude achteraf op te sporen. En het zal niet lang duren voordat fraudeurs nieuwe truuks vinden om om de detectie heen te komen.
Maar waar ik echt boos om maak is het feit dat het probleem met de huidige kaarten net zo makkelijk op te lossen is. Geen nieuwe chips, geen fraudedetectiesystemen, geen vervolgingen, en de huidige kaarten zullen over tien jaar net zo veilig zijn als nu.
Ja, je leest het goed. Jouw belastingcenten worden verspild aan zaken die van het begin af aan al voorkomen hadden kunnen worden, als TLS een beetje snuggere programmeurs in dienst had gehad.
De oplossing
Door aanpassingen in de software kan worden voorkomen dat er überhaupt ooit fraude gepleegd wordt. Het grote probleem van de overheid en de ontwikkelaars van het hele OV-chipkaart systeem is namelijk dat ze teveel focussen op het versleutelen en verbergen van gegevens. Terwijl het probleem een hele andere is: Namelijk het kunnen _verifiëren_ of gegevens op de kaart wel op de kaart zijn gezet door de juiste partij. Geen enkele cryptografie is zo sterk dat deze nooit gebroken kan worden, dus daar moet je ook nooit vanuit gaan. Als je mindset er één is dat je er sowieso vanuit gaat de je cryptografische sleutels gebroken worden, dan word je gedwongen creatievere oplossingen te verzinnen.Terwijl ik het deze week met een collega, die zelf ook in zijn vrije tijd met RFID chips speelt, had over de problemen met de OV-chipkaart, kwam spontaan de oplossing bij me op. Als de check-ins gesigned zouden worden, dat wil zeggen voorzien van een digitale handtekening, zou je makkelijk kunnen controleren of de signature klopt. En Hoe langer ik er over nadacht, des te meer ik ervan overtuigd raakte dat dit _de_ oplossing is, en des te kwader ik werd dat dit niet door de programmeurs, die waarschijnlijk een stuk beter betaald krijgen, en hoger opgeleid zijn dan ik, bij TLS verzonnen had kunnen worden.
Natuurlijk komt mijn idee om de check-ins te signen niet zomaar uit de lucht vallen. In verband met mijn werk bij TransIP zit ik namelijk bovenop de ontwikkelingen ontremt DNSSEC. DNSSEC is een uitbreiding op het DNS protocol waarbij DNS entries voorzien worden van signatures zodat de validiteit van DNS requests kan worden geverifieerd. Dit is nodig omdat het DNS protocol gevoelig is voor zogenaamde man-in-the-middle attacks, waarbij een server van een kwaadwillend persoon zich voordoet als een legitieme DNS server, en zo aangepaste DNS records terugstuurt, waardoor webbrowsers naar andere sites kunnen worden geleid, zoals bijvoorbeeld phishing-sites.
 |
| Hier zie je de normale werking van DNS zonder DNSSEC. De client vraagt om het IP dat bij een domein hoort, en de DNS levert het IP en vervolgens kan de informatie van de webserver horend bij het domein opgehaald worden. |
 |
| Bij een man-in-the-middle aanval doet een aanvaller zich voor als een DNS server, waardoor de de client naar een alternatieve webserver geleid kan worden. |
Wel nu. Vervang de DNS server in voorgaande verhaal met een NS-checkin paal, de webbrowser met de RFID lezer van de conducteur en de man-in-the-middle met een laptop+kaartlezer die nep incheckt, en je ziet al snel heel veel overeenkomsten tussen de twee situaties.
 |
| Dit is de "man-in-the-middle" variant van de OV-chipkaart. Met behulp van een computer kan de inhoud van een OV-chipkaart bijten de checkin-paal om gewijzigd worden, zonder dat de gegevens gevalideerd kunnen worden. |
 |
| Met behulp van DNSSEC kan de validiteit van een DNS record gevalideerd worden aan de hand van de signature. |
 |
| In het geval van een man-in-the-middle aanval zal de aanvaller niet in staat zijn de juiste signature te genereren, aangezien hij niet over de correcte private key beschikt. |
Hoe gaat dit alles in zijn werk? Wel, er zullen enkele aanpassingen gemaakt moeten worden in de software van de incheckapparaten, en de software van de checkapparaten van de conducteurs. Bij het inchecken wordt, naast de gebruikelijke gegevens die op de kaart worden weggeschreven, een digitale handtekening weggeschreven, inclusief een publieke sleutel die gebruikt kan worden om deze te verifieren. Bovendien wordt er nog een extra controle-veld meegeschreven om deze publieke sleutel weer te verifiëren.
Zoals ik al zei: de truuk is om er bij voorbaat vanuit te gaan dat alles gekraakt zal worden. Zelfs signing keys worden op den duur gekraakt. Het mooie van dit systeem is echter dat het niet uit maakt of het gekraakt wordt. Let op:
De check-in informatie wordt immers gesigned aan de hand van een private key op het check-in apparaat. Dit hoeft geen sterke key te zijn, hij zal namelijk sowieso maar, laten we zeggen, twee dagen geldig zijn. (Of minder, ik heb geen idee hoe lang een check-in maximaal geldig kan zijn.) Dat betekent dat, zelfs als het een kraker lukt om binnen die tijd deze sleutel te kraken, hij na die twee dagen weer een nieuwe sleutel moet kraken. Dat is ook de reden dat de publieke key mee moet op de kaart. Deze wordt immers gegenereerd samen met de private key.
De controlehash op de kaart dient om te verifieren of de key _zelf_ wel door een geautoriseerd apparaat is gegenereerd, en niet door iemand thuis. De private/public keys op het check-in apparaat worden namelijk zelf ook gesigned aan de hand van de zogenaamde key signing key (KSK). Deze Key Signing Key is een veel sterkere sleutel (4096-bit of hoger) aangezien deze maximaal een jaar mee moet kunnen gaan.
Wij gaan er echter, zoals het hoort, weer vanuit dat ook deze sleutel op een gegeven moment gekraakt kan worden, of wellicht gestolen (door een check-in paal af te breken een mee te nemen). Wanneer dit gebeurd kan deze echter onmiddellijk een nieuwe sleutel uitgerold worden, en de oude revoked worden. Omdat de check-in key maar zo kort geldig is, is de periode waarin de oude KSK nog onderstuend en dus gebruikt kan worden nooit langer dan 2 dagen. Dan kan onze fraudeur weer een 4096-bit key gaan proberen te kraken, of een andere check-in paal gaan slopen.
Met deze controlegegevens op de kaart is vervolgens altijd te controleren of de data werkelijk is aangepast door een apparaat dat daar de juiste sleutel voor heeft. Zo niet, dan kan deze worden afgewezen.
 |
| Bij een OV-chipkaart met signatures zijn de gegevens op de kaart altijd te valideren, a la DNSSEC. |
 |
| En net als bij DNSSEC zal een |
Je leest het, de onnozelheid van onze overheid en transportbedrijven kost ons weer klauwen met geld. Wel goed. De oplossing voor alle problemen heeft u zojuist kunnen lezen. Misschien dat iemand bij TLS dit ooit leest. Misschien dat hij zelfs nog wel wil toegeven dat dit inderdaad de oplossing zou kunnen zijn. Maar ik heb er een hard hoofd in dat het er ooit nog van komt. Mocht jij er optimistischer over zijn, voel je dan vrij om deze post door te linken, sturen of tweeten. Misschien dat we iemand ergens wakker kunnen schudden en dit OV-chipkaart fiasco eindelijk eens kunnen beëindigen.