Friday, March 04, 2011

Gekraakte OV-chipkaart: de oplossing

EDIT 09-03-2011: Op verzoek van een collega, nu met plaatjes!


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.
Toen de veiligheidsproblemen van DNS aan het licht kwamen, is bewust niet gekozen voor SSL, TLS of een andere vorm van encryptie. De voornaamste reden hiervoor is dat, aangezien vrijwel het gehele internet afhankelijk is van DNSSEC, er gekozen moest worden voor een backwards-compatible oplossing. Daarnaast zou encryptie alleen maar meer overhead creëren, waardoor DNS requests veel langer zouden duren, en veel meer wereldwijde traffic zouden genereren. Sowieso is encryptie overkill als je bedenkt dat DNS records gewoon publieke informatie zijn.
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.
Nu terug naar de OV-chipkaart. We hebben hetzelfde man-in-the-middle probleem. We hebben ook gezien dat (betere) encryptie, hoewel de persoonlijke OV-chipkaart wel degelijk persoonlijke informatie als naam en geboortedatum bevat, niet de oplossing is. -Nieuwe chips met nieuwe vormen van encryptie zullen in een kwestie van weken ook gekraakt zijn.- Uiteindelijk draait het nog maar om één ding: dat te achterhalen moet zijn of de gegevens op de kaart een legitieme oorsprong hebben.

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.

18 comments:

Quirinius said...

Klint goed. Doen!

CtrlSPATIE said...

Ik vraag me af of de kern van het probleem in de techniek zit.

Een aantal weken terug zei het apparaat van de conducteur dat mijn kortingskaart reeds een half jaar verlopen was. Bij een NS-balie bleek er een uur later niets aan de hand te zijn.

In het oude systeem kochten ik een kaartje uit de automaat. In de trein kwam er een conducteur en dan had ik een bewijs van betaling, aan toonder.

In het OV-chipkaart systeem zijn we nog steeds verplicht te bewijzen dat we een geldig vervoerbewijs hebben. Voor het leveren van dat bewijs zijn we wel afhankelijk van een systeem van de vervoerder.

In mijn geval zat ik dus formeel zonder vervoerbewijs in de trein. De conducteur overtrad formeel de regels door me te laten zitten.

Huuf said...

Hiermee zitten ook een aantal haken en ogen aan, het zal dan nog steeds mogelijk zijn om een kaart uit te lezen en deze meerdere keren te kopiëren naar andere kaarten. Dan zijn we weer terug bij af.

Hierbij moet je ook nog gaan opletten dat je niet al te lang mag doen bij een checkin.

Het oplossen van het probleem kan alleen door encryptie + verificatie van gegevens dmv uid.

Yogarine said...

@CtrlSPATIE
Dat is idd een inherent probleem van electronisch vervoersbewijs. Het idee erachter is uiteindelijk dat OV-chipkaart het leven van de reizigers makkelijker zou moeten maken. (Dat het in de praktijk daar niet op uitkomt komt door de slechte implementatie van TLS. ;-) )

@Huuf
Terguzetten van gekopieerde gegevens naar de kaart blijft inderdaad nog mogelijk, maar het terugzetten van gekopieerde gegevens is één van de makkelijkst te detecteren truuks. (Aan de serverkant dan.)
Ik weet niet of elke OV-chipkaart een, niet te wijzigenm, unieke ID heeft, maar zo ja, als je die dan meeneemt in de signature, is de data niet meer bruikbaar op andere kaarten.
Verder is het signen van 4KB aan data met een 384-bit key milisecondenwerk. Performance zal het probleem niet zijn.

BTHV said...

En wat nu met een nóg eenvoudiger oplossing? Die conducteurs hebben een PDA met een GPRS verbinding, dan is het toch zo te controleren of er wel of geen check-in heeft plaatsgevonden met de TLS systemen of een eigen systeem?

Even de TLS database kietelen...?

Dus de cirkel gesloten maken?

Yogarine said...

@BTHV Even kijken, in een normale trein heb je denk ik zo'n ~30 passagiers per wagon.
Nu is de conducteur bij de meeste OV-chipkaart gebruikers 5 seconden per passagier kwijt. Als dan ook nog eens over GPRS (dat is op zijn snelst 80 kbit/s als je een goede ontvangst / device hebt) elke kaart moet verifiëren (met SSL/TLS!) ben je voor elke controle al gauw 10 seconde meer kwijt. En dat is bij een gunstige verbinding.

Oftewel, het controleren duurt veel langer. Bovendien is het niet gegarandeerd dat je een GPRS verbinding hebt. Én check-ins worden volgens mij ook niet real-time naar de centrale van TLS gestuurd.
Daar komt nog eens bij dat dat alleen in de trein zou werken. Andere apparaten die geen real-time verbinding hebben kunnen er niks mee.

Het is ook niet "eenvoudiger". Gegevens zouden dan overal en altijd real-time naar de centrale server moeten worden gestuurd. Dus je moet rekening houden met concurrency, error-checking, race-condities, etc.

Het mooie van signatures is dat het ontzettend robuust is. Je bent niet afhankelijk van een internet verbinding, en of de data op je kaart klopt kan binnen een tiende van een seconde worden gecontrolleerd.

Anonymous said...

Hier wat leesvoer...
http://cr.yp.to/talks/2009.08.10/slides.pdf
Wellicht dat je daarna wat minder euforistisch opkijkt tegen OOK een NIET-oplossing van DNS problemen.

leo at dns-lab .com

Yogarine said...

@leo
Die talk gaat over vijf problemen van DNSSEC:
1.) Adoptie
2.) Potentiele DoS aanvallen.
3.) NSEC walking
4.) _potentiele_ softwaregaten
5.) Het "negeren" van signatures door DNS clients

Geen van die punten is verder relevant met mijn verhaal:
1.) Adoptie is niet afhankelijk van derde partijen, aangezien de leden van TLS zelf verantwoordelijk zijn voor het uitrollen van de software op de apparaten.
2.) DoS is sowieso irrelevant aangezien we nooit meer dan één OV-chipkaart verwerken.
3.) NSEC walking is sowieso irrelevant omdat we niet DNS records aan het signen zijn maar de inhoud van een OV-chipkaart die sowieso in zijn geheel door de kaartlezer ingelezen wordt.
4.) Potentiele veiligheidsgaten zal je altijd houden. Zelfs de veiligste besturingsystemen op aarde hebben veiligheidsgaten. Moeten we nu oppeens gaan stoppen betere beveiligingsmethodes te ontwikkelen?
5.) Het _negeren_ van signatures is ook geen issue als je niet te maken hebt met derde partijen.

Met andere woorden. Het enige waar die presentatie over gaat zijn de implementatieproblemen die DNSSEC momenteel ondergaat. Maar de onderliggende techniek van het signen van gegevens, gebruikmakend van een chain of trust, staat nog steeds als een huis.

Wat ik voorstel is geen ook OV-chipkaart-DNSSEC. Ik stel een manier voor om OV-chipkaarten van signatures te voorzien, op een manier dat is geïnspireerd door DNSSEC. Hierbij gaat het enkel om de manier van signen en keys beheren. Een OV-chipkaart bevat geen DNS-records...

patrick said...

Wat mij een oplosing lijk is wat al zo lang op bankbiljetten vremeld staat in de kleine letters betreft valsmunter 7 jaar celstaf

... de ov met kleine leters.....
en het fatsoen voor een betere wereld
het is er zo mooi voor gemaakt
Petjepitermintje

Anonymous said...

zolang er meer geld word verdient aan de niet oplossing dan aan de oplossing zal het niet gebeuren...
kijk voor de lol een zeitgeist , en je leert hoe de economie werkt. :)
Een probleem oplossen is het laaste wat je wilt als je de economie wilt laten groeien......

Anonymous said...

he AJ je maakt een denkfout...
DNS heeft zijn certificaten maar op 1 plek....
hier moet elk paaltje zijn cert hebben,
dus men neme een paaltje conducteurs ap[aratatjes etc
zie http://tls.etv.cx
en je probleem is opgelost.
maw nee het KAN niet veilig ,,,,
maar goed t is leuk ge probeerd :)

Yogarine said...

@Anonymous 1:
Economie groeit als mensen meer koopkracht hebben... Als mijn belastingcenten verspild worden aan een waardeloos OV-systeem (wat grotendeels eigendom is van de overheid) blijft er minder geld om uit te geven aan nuttige producten. Wat ik wil zeggen: het geld gaat toch de economie wel in.

@Anonymous 2:
Je snapt volgens mij niet precies hoe de chain of trust en key rollovering werkt. (Of ik begrijp jou niet.)

Elk paaltje heeft een key, die weer gesigned moet worden met een key signing key, die gerollovered kan worden.

Oftewel, als je een paaltje/apparaatje jat, wordt er gewoon een nieuwe key uitgerold, en kan je maar een aantal dagen de oude keys gebruiken. Dan moet je een nieuw apparaat gaan jatten. :-)

Je bewering dat DNS(Sec) zijn certificaten op 1 plek heeft is ook simpelweg onjuist. Lees het anders even rustig na: http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

Anonymous said...

@Yogarine
Key roleover kan dus al niet.
want dat betekend omdat er dus transactioes zijn met geld...
je dus een key uit het verleden kan gebruiken , en er onstaan problemen met tickets uit het verleden.
er zijn mensen die dan een ander kaartje moten kopen of ze worden ineens geblokeerd omdat de key is vervangen.
dit zijn allemaal dingen die in een klinishe omgeving goed werken maar niet in een omgeving waar mensen met tickets werken die rustig 3 jaar oud kunnen zijn ..
word je ineens geconfronteerd met het "canal plus" probleem :)
namelijk dat je kaart een update key mist.
zo kan ik nog wel een paar problemen noemen.
Want wat doe je met niet live stystemen zoals de bus.
Bij DNS sec is het aantal keys beperkt en ook het aantal hosts afhankelijk van deze key is hoggstens 100 tot 200 maar geen 5.000.000+ kaartjes.

Anonymous said...

P.S
Paaltjes jat je natuurlijk niet je kan ook een conduteurs apparaatje jatten of meerdere , je kan ook een sniffer in het paaltje bouwen , die de key braaf naar je toe stuurt als je een commando geeft via BT...
nee er zijn legio methodes daar omheen te komen.
Verder is de vraag of de overheid zon systeem wel wil..
Misschien zijn deze gatjes wel heel gewenst...
Wat d8 je , hoveel geld je kan witwassen in een lek viritueel geld systeem , de bouwfraude is er niets bij , jullie gaan er wel vanuit dat het allemaal perongeluk zo brak gemaakt is maar is het wel zo "per ongeluk"????? mijn deel over de economie ook op.
kijk dit eens...
http://www.youtube.com/watch?v=GlrmeFGYYNk
http://www.youtube.com/watch?v=1l_OH5ANZsk
http://www.youtube.com/watch?v=BU10Y2cCnfE
http://www.youtube.com/watch?v=ojIrPhSTUo8
http://www.youtube.com/watch?v=Rz4t2xtanck
het gaat over de werking van de economie perverse prikkels etc etc...
het gaat niet om jouw belasting centjes het gaat om de aandeelhouder die zijn winst kan maximaliseren en coor zijn colega evt wat weg kan sluizen.
je kent vast die precentatie van 27c3 over de EMV chip niet?
http://www.youtube.com/watch?v=gv3dxjvqk7Y
kijk het en zie de paralellen..
er is niet zo lucratief als viritueel geld!

Yogarine said...

@Anonymous 1
Ik weet het niet zeker hoor, maar volgens mij moeten mensen met een abbo nog steeds in- en uitchecken.

Niet de abbo wordt gesigned, maar de check-in.

Het enige doel dat het signen heeft, is de mogelijkheid bieden om te verifieren of iemand legitiem ingecheckt is. Niet perse om de abbo zelf te verifieren. (Dus je moet dan wel echt inchecken, en zo kan je kaart dus gewoon geblokkeerd worden als je bijvoorbeeld een fake abbo gebruikt.)

Je bewering dat maar 100 tot 200 DNS entries afhankelijk zouden zijn van één key is ook onjuist. De root zones worden namelijk ook gewoon gesigned met een enkele key (daar is de hele chain of trust op gebaseerd). De .com zone bevat maar liefst 80.000.000 domains. Nu jij weer. :-)

@Anonymous 2:
Een conducteur apparaatje zal geen private keys bevatten, enkel een public key om de signature te verifiëren. Dus daar heb je niks aan.
Aan een sniffer in het paaltje heb je ook niets omdat het signen in de software op het paaltje gebeurt. Om aan een private key te komen _moet_ je een paaltje jatten, en een dump maken van de gegevens die erop staan en daar de private key uit trekken. Te omslachtig om elke paar dagen vol te houden lijkt me zo. ;-)

En over de beweegredenen van TLS ga ik niet eens in discussie. De oplossing ligt hier in ieder geval klaar. Als ze er geen gebruik van maken, tja, dan niet. :-)

Anonymous said...

Als je aleen het inchecken beveiligd betekend nog niet dat je daarmee alles hebt.
Het inchecken alleen beveiligen heeft geen enkele zin.
daar los je het probleem niet mee op.

Yogarine said...

Het zelf inchecken is de enige manier van ov-chipkaart fraude dat momenteel niet te detecteren is.

Maar de methode die ik hier uit de doeken doe kan gebruikt worden om de gehele kaart te signen. Het zij minder waterdicht omdat je dan, zoals je al aangaf, unrevocable keys moet gebruiken. Dus als de private key dan naar buiten komt kan je er ook niets meer aan doen. (Overigens kan je wel van de check-in paaltjes de gegevens encrypten. Dat zal het al een stuk lastiger maken de private key te achterhalen.)

Ik bedoel, uiteindelijk heeft het ook jaren geduurd voordat de private key van de PS3 werd gekraakt. En dat systeem zat vol gaten.

Zelfs alle gebreken in acht genomen is het nog stukken beter dan de puinhoop die TLS er nu van heeft gemaakt.

Anonymous said...

Overigens kan je wel van de check-in paaltjes de gegevens encrypten. Dat zal het al een stuk lastiger maken de private key te achterhalen.

Jaah maar dat verhelpt niet het probleem als je een paaltje jat.
Het OS (windows ce) onderzoekt en er tools voor maakt je hebt immers een emulator al in huis :)
De aardigheid van keys in het geheugen is dat ze niet gecrypt kunnen zijn.
als je dus een programma laat inbreken op bepaalde processen kan je de key vrij makkelijk achterhalen...
MAW Preceptie - werklijkheid = onzin.