De Kilometer Heffing

Thu 28-Mar-24
18:56:10

Petities TEGEN de kilometer heffing (tot april 2007).


Column: Kilometerheffing lijkt fraudegevoelig

Datum: Fri 27 November 2009

Door: Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -

Gaan we echt rekeningrijden? Minister Eurlings verdedigt zijn voorstel, voor- en tegenstanders komen aan het woord. Opvallend was het punt van kritiek van de Raad van State. Volgens de raad ademt het voorstel een 'sfeer van onfeilbaarheid van de techniek' die niet onmiddellijk wordt gedeeld. Wellicht dat de Raad van State enige analogie ziet met andere mega-ICT projecten, zoals de OV-chipkaart die initieel eveneens als onfeilbaar gepresenteerd werd en inmiddels storingsgevoelig en lek blijkt.

Kan het kastje voor de kilometerheffing ook falen? Ik besloot tot een mini-beveiligingsonderzoekje. Vooropgesteld: ik heb zo'n kastje niet. Het is dus vooralsnog alleen een literatuuronderzoek. Enkele geïnteresseerde vakbroeders stonden mij hierbij belangeloos bij.

Relevant is het wel, vind ik. Gezien de bedragen waar veel Nederlanders voor geplaatst worden (motief) en het feit dat iedereen straks toegang heeft tot een KMH-kastje (mogelijkheid), moet een beveiliger immers oppassen. De besparing kan voor een hacker leuk oplopen. In tegenstelling tot 'gewone' hackacties kun je in dit geval heel gemakkelijk je technische vaardigheden in geld omzetten. Ik rijd elke dag over de A2 bij Utrecht, met een waarschijnlijk tarief van zo'n 17 cent per kilometer.

Dit onderzoek is bovendien leuk en leerzaam; het bouwen van fraudebestendige systemen is voor de vakidioot in beveiliging het mooiste wat er is. En als dat NXP en IBM gelukt is, wil ik heel graag de kunst afkijken. Zo niet, dan heeft minister Eurlings straks wat uit te leggen.

Op de vele online platformen wordt uitgebreid gespeculeerd hoe de financiële bijwerkingen van het rekening rijden te vermijden. Het betoog van de minister dat de meeste burgers minder gaan betalen wordt blijkbaar door lang niet iedereen geloofd. Niet zo gek overigens - diverse belangrijke financiële aspecten zijn niet belicht. Zoals het volgende: zodra de BPM wegvalt, de catalogusprijs daalt, daalt dus ook de bijtelling. Als die 520.000 leaserijders die bijtelling betalen 35% minder bijtelling hebben met ingang van hun volgende leaseauto, zal (met een gemiddelde auto van 25.000 euro en een verondersteld belastingtarief van 42%), de opbrengst van de inkomstenbelasting dalen met 1.365.000.000 per jaar. Dat zal Financiën niet leuk vinden en die zal de regels voor de bijtelling heus met een (spoed)wetje aanpassen. En ook dat (spoed)besluit zal weer een aantal mensen benadelen, die ook weer op zoek gaan naar compensatie. Nu zijn dit soort berekeningen natuurlijk ook heel lastig; dat de economie niet maakbaar is, zouden we sinds het sovjet-experiment moeten weten. Dat verkeer ook onderhavig is aan de wetten van de economie, is blijkbaar nog minder bekend.

Mochten de baten voor de burger niet het niveau halen dat de minister belooft, zal dat voor genoeg mensen gelden als een vrijbrief om te frauderen. Met de BPM was moeilijk te frauderen. Het nieuwe systeem lijkt wat meer mogelijkheden te bieden. Belastingontduiking is ondanks jaren van normen en waarden nog steeds een volkssport. De fraudekans is veel groter dan met de OV kaart - de meeste Nederlanders reizen zelden of nooit met bus of trein, en zwartreizen geldt als een zwaardere fout dan creatief omgaan met de belastingen. Als bepaalde mensen dieper gaan kijken en laten zien dat - en hoe - fraude mogelijk is en de pakkans gering, dan zal er met dit systeem grootschalig gefraudeerd worden. Het is logisch dat er een boel aandacht voor de beveiliging van het geheel is. De leveranciers zijn ook niet de minst ervaren partijen en zij hebben veel aandacht aan de beveiliging besteed en deze ook extern laten toetsen. Zo wordt er geschermd met een Common Criteria EAL 5+ certificering en dat klopt voor minimaal één onderdeel. Maar omdat een computersysteem zo sterk is als de zwakste schakel, is het geheel maximaal EAL4+. In gewone mensentaal: behoorlijk sterk maar niet beveiligd tegen een lokale aanval. Het is hetzelfde niveau waarop Windows beveiligd is. De externe toetsing is zo te zien uitgevoerd op onderdelen van het systeem. Dat is niet hetzelfde als een toetsing van het geheel; je kunt een schakel vergeten en het kan zelfs gebeuren dat een ketting van louter sterke schakels, toch zwak is. De schakels kunnen immers verkeerd aan elkaar gekoppeld te worden.

Wat hebben we gevonden in ons minionderzoek? Hieronder een korte en theoretische beveiligingsanalyse.

We moesten eerst vaststellen hoe het ding in elkaar zit. Natuurlijk begint de analyse bij de leveranciers. Eurlings zegt dat de leiding bij NXP ligt. NXP meldt vervolgens dat het samenwerkt met het Canadese Skymeter voor rekeningrijden en met Siemens voor het kastje. De samenwerking moet zorgen voor een koppeling tussen NXP's Automotive Telematics On-board unit Platform-chipset (Atop) en Skymeters GNSS-gebaseerde afrekentechnologie. Volgens de partners zal het gezamenlijke systeem voldoen aan de grensoverschrijvende interoperabiliteitseisen zoals voor het European Electronic Tolling System (EETS). Ook bij een experiment van IBM en NXP in rekeningrijden in Leuven wordt de Atop genoemd dus IBM hangt ook nog ergens in de wolk. Het zou immers niet logisch zijn dat NXP meerdere kastjes los van elkaar zou maken.

Gerelateerd aan het rekeningrijden is het door de overheid gesubsidieerde "Hightech Topproject" Spits (Strategic Platform for Intelligent Traffic Systems), waarvan NXP de penvoerder is. Hoofddoel van Spits is om een open hardware-upgradebaar platform te creëren voor intelligente verkeerssystemen. Behalve NXP zijn onder meer Catena, Logica, TNO Automotive en Tomtom bij het project betrokken. Dus het kastje is zeer waarschijnlijk op afstand 'hardware upgradebaar'.

Het kastje is een Atop. Atop is niet alleen bedoeld voor rekeningrijden: "With its multiple interfaces ATOP allows a flexible integration in a wide variety of car architectures". Het is dus een 'open platform' met veel meer mogelijkheden. Dat maakt normaliter de beveiligingsuitdaging nog een maatje groter. Zo ondersteunt het kastje ook de E112 functie. Deze functie wordt in de stukken slechts heel zelden genoemd. Het gaat hier om een door de EU verplichte (COM 1999/539) functionaliteit, waarmee een auto automatisch een aanrijding doorgeeft aan de meldkamer, op termijn 'verrijkt' met " a Full Set of Data (FSD) such as blood type, number of passengers, car brand, etc.". Ook een interessant vraagstuk in verband met de privacy.

We lezen verder: "Using the built-in USB, CAN and UART interfaces, ATOP can be integrated into navigation / infotainment systems or connectivity boxes, allowing design teams to focus on integration of the multiple air interfaces". Da's genieten: iedere extra interface is een extra puntje van aandacht voor de beveiligingsonderzoeker. En dan: "To further ease design challenges, the solution provides an industry standard software interface based on mobile JAVA J2ME CLDC1.1 MIDP2.0 allowing safe, flexible and easy integration of customer applications". Het kastje draait blijkbaar op micro java (J2ME) met MIDlets en Thinlets. In meer detail: CLDC 1.1 (base set of application programming interfaces) en MIDP2.0 (de Java runtime environment). MIDP2.0 betekent UDP/Sockets/Secure Sockets/Server Sockets en seriële poorten, naast ondersteuning voor kopieerbeveiliging voor MIDlet suites.

Nu is er niets mis met Java, al dan niet ingebakken in een kastje of een smartcard. In het smartcard geval zal het IBM JCOP zijn. Java is een prima stukje code, waarmee - zoals met alle code - wel eens beveiligingsproblemen zijn. Er zijn in het verleden al kwetsbaarheden in gevonden en het zou zeer onwaarschijnlijk zijn dat dat de laatsten waren. Zeker gegeven dat het een platform in ontwikkeling is. De enige bij Secunia bekende gaten zijn Highly Critical, en nooit gefixed. Gegeven dat deze in 2004 bekend zijn gemaakt maakt dat het veiligheidsprofiel van J2ME knap beroerd is. Het is natuurlijk niet zeker dat dit oude gat ook speelt in het kastje voor de kilometerheffing of de smartcard. Waarschijnlijk wel, omdat de getroffen bytecode verifier functie wél gebruikt wordt voor de authenticatie van de smartcard, sterker nog, een essentieel beveiligingsmechanisme van de kaart is.

Het Atop kastje wordt dus geactiveerd met een smartcard. Of iedere bestuurder dat kaartje elke dag uit de auto moet halen, of dat de kaart in het kastje blijft zitten - al dan niet in het 'vignet' op de voorruit, roept interessante vragen op. Immers, als je je kaart kwijt bent, zal het kastje niet meer werken. Wat kan een automobilist doen met de (ontvreemde) smartcard van iemand anders? Dat is een hele nieuwe variant op identiteitsdiefstal.

Als je een systeem wilt manipuleren, dan moet je een methode hebben om het systeem te benaderen - een interface. Het ATOP kastje heeft een aantal interfaces nodig. Daarnaast heeft het kastje, omdat het ook in andere rollen inzetbaar is, interfaces die - als het goed is - niet beschikbaar zijn voor de eindgebruiker. Een beveiligingsanalyse kijkt naar al deze interfaces, de functioneel noodzakelijke eerst, om te zien waar er gemanipuleerd kan worden. Maar ook de uitgeschakelde interfaces verdienen enige aandacht, omdat 'uitschakelen' niet altijd goed gebeurt of vergeten wordt, of soms zelfs gewoon niet goed werkt. Alle interfaces moet je minimaal bekijken op in ieder geval de volgende basale beveiligingsfuncties:

  • 1. Identificatie (wie spreekt waarvoor welke interface aan en hoe stelt het systeem vast dat dit alleen door juiste personen/systemen gebeurt)
  • 2. Autorisatie (welke functies mogen door wie via welke interface aangesproken worden)
  • 3. Input Validatie (welke data mag via welke interface binnenkomen en hoe sluit de interface ongewenste input uit)

    Het kastje heeft in ieder geval de volgende interfaces waarop je iets zou kunnen proberen:

  • * Push voor verandering van routeprijzen
  • * Pull voor validatie bij handhavingspoort
  • * Push of Pull voor 'afrekening'
  • * Pull voor extended ritteninformatie
  • * USB voor de gebruiker om ritteninformatie op te halen
  • * UMTS/GPRS voor eGPS (downloaden van satellietinformatie)
  • * UMTS/GPRS voor software updates (SPITS-project)
  • * Contactless smartcard lezer; NFC (Near Field Communication) voor virtuele SIM-kaarten (dit kan dezelfde zijn)
  • * E112 trigger - een fysieke koppeling naar de airbags om botsingen waar te nemen.
  • * eGPS - ATOP gebruikt een duaal positioneringsysteem op basis van GSM en GPS samen. Het GPS signaal wordt aangevuld met satellietgegevens via het UMTS/GPRS netwerk zodat er ook een fix te maken is in stedelijke gebieden.
  • * NFC interface voor RFID "vignet" (op de voorruit)

    Het voert een beetje ver om in deze column de drie functies tegen iedere interface aan te houden. Duidelijk is dat de hoofdsmaken GSM, GPRS/UMTS en NAVSTAR GPS zijn.

    Kort gezegd: GSM is lek. Heel erg lek. Zoals recent nog eens aangetoond op Hacking At Random, maar al in 1998 door de SIM-kaart kloonactie door de Chaos Computer Club. Daar hoeven we verder geen woorden aan vuil te maken; het verkeer kan onderschept en gemanipuleerd worden.

    UMTS/GPRS netwerken maken gebruik van TCP en UDP, protocollen waarvan veel mensen de beveiligingsvraagstukken kennen. De authenticatie van een device op UMTS/GPRS is beveiligd, maar niet sterk (PAP of CHAP), protocollen die al gebroken zijn. Oftewel, ook dit verkeer kan onderschept en gemanipuleerd worden.

    Een GPS ontvanger kan een zender normaliter niet authenticeren; de huidige standaarden voorzien niet in een authenticatiemechanisme. GPS III en Galileo zullen wel een dergelijk mechanisme krijgen maar zo ver is het nog lang niet. Er zijn ook andere veelbelovende ontwikkelingen op dit gebied. De huidige stand van zaken houdt echter in dat de primaire protocollen om met de interfaces te spreken op dit moment onveilig zijn, en de issues in brede kring bekend.

    Dus als je kunt achterhalen hoe het systeem de informatie krijgt waarin gemeld wordt welke tarieven bij welk stuk weg en tijdstip horen, dan kun je zelf wellicht de prijzen prettig aanpassen.

    Het blijkt dat er tal van vectoren zijn. De volgende hebben we nader bekeken:

    Onderzoeksrichting 1: de ATOP ondersteunt contactloze en virtuele SIMs. Beide kunnen wellicht gemanipuleerd worden, maar virtuele het beste. Het doel van dergelijke SIM-spoofing zou zijn de informatie van iemand die weinig rijdt 'om te leiden' en voor je eigen veel rijdende auto te gebruiken. Een mogelijkheid is de telefoonlijst aanpassen in de virtual sim van iemand anders, of het vervangen van de fysieke sim. Daarmee kun je een permanente omleiding van de ritteninformatie maken, zodat je de rekening van iemand anders krijgt en als je eigen rittenadministratie kunt verzenden. De eigenaar van de 'gestolen' informatie zal het nooit merken, zo lang je de originele berichten ook doorstuurt. De Mifare SmartMX controller met de FameX PKI accelerator is zo te zien heel goed beveiligd, en is common criteria EAL 5 gecertificeerd, dus misschien kan dit pas als je op een andere manier toegang hebt geforceerd. Het smartcard OS is echter EAL 4+, dus vergelijkbaar met MS Windows 2003, wat in het kort inhoudt dat het niet bestand hoeft te zijn tegen frontale aanvallen. Het fysieke kaartje is dus heel interessant.

    Onderzoeksrichting 2: Met een zeer significante footprint in de automotive ontstaat een nieuwe monocultuur met een zeer groot aantal identieke computersystemen. Een aantrekkelijk aanvalsdoel voor virusschrijvers. Een botnet op boordcomputers van alle auto's in Nederland is een interessante gedachte. Java-virussen zijn 11 jaar geleden al gesignaleerd. De enige vraag is welke payload het meest aanspreekt. Gegeven de mogelijkheden van Java is de keuze, reuze!

    Onderzoeksrichting 3: manipuleren van het GPS signaal. Alleen GPS storen zal wellicht niet helpen - manipulatie van het ene systeem zal waarschijnlijk een alert triggeren. GPS Spoofing biedt daarentegen meer concrete kansen, mits subtiel toegepast. Er zijn wel mogelijkheden bekend om een GPS een soort intrusion detection te geven, dus het zou mogelijk moeten zijn om deze in het kastje in te bouwen.

    Onderzoeksrichting 4: manipulatie van het update mechanisme. Het systeem zal, als het werkt zoals dit soort systemen meestal werkt, van een centraal systeem de melding krijgen dat een update beschikbaar is. Vervolgens zal deze update 'ontvangen' worden en automatisch uitgevoerd - je kunt niet de user vragen op OK te klikken, immers. De byte code verifier zal de update toetsen, eventueel nog met een controle van de digitale handtekening van de code. De uitdaging is de identiteit van het 'centrale systeem' te kapen, zodat je gericht de software kunt aanpassen. En dat kan van één kastje maar misschien ook wel van alle kastjes in Nederland.

    Naast deze richtingen zijn er nog een reeks andere vectoren voorbijgekomen - zoals het gebruiken van opzettelijk corrupte PKI certificaten om de handshake te manipuleren - die verder uitgewerkt kunnen worden. Ook de logistiek om iedere auto van een gepersonaliseerde kaart met PIN-code te voorzien levert interessante vectoren om te onderzoeken op. Maar dat voert nu iets te ver.

    Conclusie

    De waarschuwing van de Raad van State dat de technologie onder het rekeningrijden wel eens kan falen, is zeer terecht. Het systeem is gebaseerd op technologie die niet ontworpen is om fraudebestendig te zijn. GPS en GSM kennen geen goed authenticatiemechanisme, terwijl er in het besturingssysteem een zeer kritiek gat zit dat al meer dan vijf jaar bekend is. De nodeloze technische complexiteit, mede veroorzaakt omdat de ingezette apparatuur ook andere functies moet kunnen hebben, leidt tot een groot aantal andere mogelijke aanvallen. Zo te zien is er wel veel gedaan om het geheel te beveiligen, maar omdat in ieder geval een behoorlijk aantal mensen een sterke financiële prikkel zal hebben om het systeem aan te vallen, en de kennis daarvoor niet bijzonder moeilijk te verkrijgen is, is een geslaagde aanval op enig moment meer dan hoogstwaarschijnlijk.

    Zonder een echt kastje is het niet mogelijk te stellen welke van de mogelijke aanvalsvectoren succes zullen hebben. Zeker is wel dat het beveiligen van de technische voorzieningen voor het rekeningrijden een zeer grote inspanning zal vergen en zal leiden tot aanzienlijke extra operationele kosten. Omdat het ook goed uitvoerbaar lijkt om niet traceerbare fraude te plegen, zal er ook inkomstenderving voor de overheid optreden. Om van politieke schade maar niet te spreken.

    Nogmaals: bovenstaand is een theoretische exercitie. Ik heb geen kastje, en ik heb oppervlakkig gekeken. Misschien kan er een leuke thematische Hackers at Large uit volgen of zo. De mogelijke aanvalsvectoren worden op dit moment vooral bepaald door de fantasie en niet door technische details van de feitelijke implementatie - er kunnen en zullen meer en andere mogelijkheden zijn. Het overgrote deel van deze onbeveiligde infrastructuur is een gegeven, en de makers van het kastje moeten het er maar mee doen. Wij straks ook.

    Bron: Security.Nl


    Petities TEGEN de kilometer heffing (tot april 2007).