Regeling specificaties en typegoedkeuring boordcomputer taxi

Het bericht F_BERICHT_ONBEKEND is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onbekend berichttype. Totale berichtgrootte: 7 bytes.

Artikel 2.4.3.12. Bericht F_CRC_INCORRECT

Het bericht F_CRC_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onjuiste CRC. Totale berichtgrootte: 7 bytes.

Artikel 2.4.3.13. Bericht F_LENGTE_INCORRECT

Het bericht F_LENGTE_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onjuiste minimale of maximale berichtlengte. Totale berichtgrootte: 7 bytes.

Artikel 2.4.3.14. Bericht F_GEEN_STX

Het bericht F_GEEN_STX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal een ETX teken zonder het tussentijds ontvangen van een STX teken. Totale berichtgrootte: 7 bytes

Artikel 2.4.3.15. Bericht F_GEEN_ETX

Het bericht F_GEEN_ETX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal een STX teken zonder het tussentijds ontvangen van een ETX teken. Totale berichtgrootte: 7 bytes

Artikel 2.4.3.16. Bericht F_NIET_STANDAARD

Het bericht F_NIET_STANDAARD is een foutmelding die gestuurd wordt indien er een fout optreedt die niet gedefinieerd is in een van de overige foutberichten. Er wordt een omschrijving van de fout meegestuurd.

Het bericht F_NIET_STANDAARD is een foutmelding die gestuurd wordt indien er een fout optreedt die niet gedefinieerd is in een van de overige foutberichten. Er wordt een omschrijving van de fout meegestuurd.

Artikel 2.4.3.17. Bericht F_VELD_ONGELDIG

Het bericht F_VELD_ONGELDIG is een foutmelding die gestuurd wordt indien er een ongeldig veld gedetecteerd is in het vraagbericht. Bijvoorbeeld voor een ongeldige waarde in het veld ‘Status interface’ van het bericht VR_STATUS. Totale berichtgrootte: 7 bytes

Artikel 2.4.4. Eisen met betrekking tot de performance

Artikel 2.4.4. Eisen met betrekking tot de performance

Prioriteit 1 is de hoogste, 3 de laagste.

Bijlage 4

OPENBAAR

Technische specificaties gebruik boordcomputer- en systeemkaarten Boordcomputer Taxi

Versie 1.7

Versie 1.7

Datum 25 april 2012

Colofon

Colofon

Wijzigingshistorie

Inhoud

Met de inwerkingtreding van de ‘Ministeriele Regeling specificaties en typegoedkeuring boordcomputer taxi’ zijn de specificaties van de ‘Boordcomputer Taxi’ (BCT) van kracht geworden. Met deze regelgeving wordt elke taxi in Nederland voorzien van een boordcomputer, die zowel de arbeids-, rij- en rusttijden van de taxichauffeur als de rittenstaat behorend bij de taxi vastlegt.

Met de inwerkingtreding van de ‘Ministeriele Regeling specificaties en typegoedkeuring boordcomputer taxi’ zijn de specificaties van de ‘Boordcomputer Taxi’ (BCT) van kracht geworden. Met deze regelgeving wordt elke taxi in Nederland voorzien van een boordcomputer, die zowel de arbeids-, rij- en rusttijden van de taxichauffeur als de rittenstaat behorend bij de taxi vastlegt.

Om de authenticiteit en integriteit van de vastgelegde data te waarborgen, voorziet de boordcomputer deze data van elektronische handtekeningen. Daartoe wordt een zogeheten ‘Public Key Infrastructure’ worden opgezet. De boordcomputer wordt voorzien van een certificaat en een sleutelpaar (publieke- en private sleutels), zodat hij in staat is data elektronisch te ondertekenen en de authenticiteit van aangeboden gebruikerskaarten vast te stellen. Het certificaat en het sleutelpaar van de boordcomputer worden hiertoe opgeslagen op een chipkaart, de zogeheten systeemkaart, die in een speciaal kaartslot van de boordcomputer wordt geplaatst.

Alle gebruikers van de boordcomputer worden voorzien van gebruikerskaarten, de zogeheten boordcomputerkaarten. Deze kaarten bevatten evenals de systeemkaart certificaten en sleutelparen. Toegang tot de boordcomputer is alleen mogelijk na authenticatie van een boordcomputerkaart door (de logica van) de boordcomputer.

Binnen de groep gebruikers van de boordcomputer zijn vier rollen te onderscheiden, namelijk die van bestuurder, vervoerder, werkplaats en toezichthouder. Elk van deze rollen is gebonden aan een apart type boordcomputerkaart. Elke rol heeft zijn eigen autorisatieniveau, bijvoorbeeld waar het gaat om toegang tot de op de boordcomputer vastgelegde data.

1.1. Bereik van dit document

Dit document bevat technische specificaties en richtlijnen voor het gebruik van de hierboven genoemde chipkaarten. Dit document is primair bedoeld voor fabrikanten van boordcomputers. De hoofdstukken 2 en 5 t/m 8, alsmede bijlage A, zijn echter ook interessant voor ontwikkelaars van toepassingen bedoeld om chauffeurskaarten uit te lezen.

2. Opbouw boordcomputer- en systeemkaarten

2. Opbouw boordcomputer- en systeemkaarten

De boordcomputer- en systeemkaarten zijn uitgevoerd als ISO/IEC 7816-15 kaarten. De algemene opbouw van ISO/IEC 7816-15 kaarten staat beschreven in Referentie [3]. De opbouw per kaart wordt in de specificatie documenten van de afzonderlijke kaarten beschreven (Referenties [8] t/m [12]).

2.2. Certificaten

De op de boordcomputer- en systeemkaarten gebruikte certificaten zijn X.509 certificaten uitgegeven conform het vigerende Programma van Eisen (PvE) van PKIoverheid. Er worden verschillende X.509 certificaten gebruikt, zoals voor authenticatie, handtekening en vertrouwelijkheid. Zie verder Referentie [13] in hoofdstuk 10.

2.3. Asymmetrische sleutels

Asymmetrische sleutels worden gebruikt voor authenticatie, vertrouwelijkheid en handtekening. De publieke sleutels zijn opgeslagen in de X.509 certificaten (zie § 2.2) en de private sleutels intern in de kaarten.

Asymmetrische sleutels worden gebruikt voor authenticatie, vertrouwelijkheid en handtekening. De publieke sleutels zijn opgeslagen in de X.509 certificaten (zie § 2.2) en de private sleutels intern in de kaarten.

2.4. PIN/PUK

De eigenschappen van de PIN en PUK (PIN Unblock Key) per kaart worden in de specificatie documenten van de afzonderlijke kaarten beschreven (Referenties [8] t/m [12] in hoofdstuk 10).

De eigenschappen van de PIN en PUK (PIN Unblock Key) per kaart worden in de specificatie documenten van de afzonderlijke kaarten beschreven (Referenties [8] t/m [12] in hoofdstuk 10).

2.5. Gegevens

Op alle kaarten zijn gegevens zoals voorgeschreven in ISO/IEC 7816-15 opgeslagen. Er zijn echter twee typen kaarten waarop ook andere gegevens toegevoegd kunnen worden: de systeemkaart en de chauffeurskaart.

2.5.1. Systeemkaart

Op de systeemkaart kan eenmalig het serienummer van de boordcomputer opgeslagen worden. Dit staat beschreven in hoofdstuk 3. Verder worden er (tijdens de gebruiksfase) op de systeemkaart geen gegevens opgeslagen.

2.5.2. Chauffeurskaart

Op de chauffeurskaart worden de arbeids-, rij- en rusttijden van de chauffeur, alsmede de systeemkaartcertificaten van de laatst gebruikte boordcomputers opgeslagen. Dit wordt beschreven in hoofdstuk 5.

2.5.3. Relatie gegevens boordcomputer – chauffeurskaart

Voor de boordcomputer is het niet vastgelegd hoe de gegevens opgeslagen moeten worden. Wel is vastgelegd welke gegevens er opgeslagen moeten worden en hoe en in welk formaat ze beschikbaar moeten zijn voor gegevenslevering.

Voor de boordcomputer is het niet vastgelegd hoe de gegevens opgeslagen moeten worden. Wel is vastgelegd welke gegevens er opgeslagen moeten worden en hoe en in welk formaat ze beschikbaar moeten zijn voor gegevenslevering.

2.6. Toegangscondities

Specifieke toegangscondities worden gegeven in de specificatiedocumenten van de afzonderlijke boordcomputerkaarten.

Specifieke toegangscondities worden gegeven in de specificatiedocumenten van de afzonderlijke boordcomputerkaarten.

3. Koppelen Systeemkaart

De systeemkaart moet initieel aan de boordcomputer gekoppeld worden om de boordcomputer te laten functioneren. Onderstaande paragrafen geven een nadere specificatie van boordcomputerproductie, respectievelijk systeemkaartvervanging.

3.1. Communicatiebeveiliging tussen boordcomputerunits en systeemkaarten

Een boordcomputer wordt gevormd door de combinatie van een boordcomputerunit en een systeemkaart. De boordcomputerunit wordt hierbij beschouwd als de gebruiker/houder van de systeemkaart. Net zoals een boordcomputerkaart uitsluitend door zijn rechtmatige houder mag worden gebruikt (voor het plaatsen van elektronische handtekeningen), mag ook een systeemkaart uitsluitend door zijn rechtmatige “houder” worden gebruikt. Om dit rechtmatige gebruik te waarborgen wordt elke systeemkaart voorzien van een geheime sleutel die in de boordcomputerunit dient te worden voorgeprogrammeerd.

Een boordcomputer wordt gevormd door de combinatie van een boordcomputerunit en een systeemkaart. De boordcomputerunit wordt hierbij beschouwd als de gebruiker/houder van de systeemkaart. Net zoals een boordcomputerkaart uitsluitend door zijn rechtmatige houder mag worden gebruikt (voor het plaatsen van elektronische handtekeningen), mag ook een systeemkaart uitsluitend door zijn rechtmatige “houder” worden gebruikt. Om dit rechtmatige gebruik te waarborgen wordt elke systeemkaart voorzien van een geheime sleutel die in de boordcomputerunit dient te worden voorgeprogrammeerd.

Het communicatiekanaal (voor het plaatsen van elektronische handtekeningen) tussen een boordcomputerunit en zijn gekoppelde systeemkaart moet beveiligd zijn om de integriteit, authenticiteit en vertrouwelijkheid van de uitgewisselde gegevens te beschermen. Omdat de koppeling tussen een boordcomputerunit en “zijn” systeemkaart een-op-een is, is er voor het opzetten van een veilig communicatiekanaal geen noodzaak voor asymmetrische cryptografie, maar kan met symmetrische cryptografie worden volstaan. De symmetrische sleutel(set) die voor deze communicatiebeveiliging wordt gebruikt is per boordcomputer uniek; elke systeemkaart wordt voorzien van een symmetrische communicatiesleutel(set) die in de bijbehorende boordcomputerunit dient te worden voorgeprogrammeerd.

Er bestaan vijf soorten combinaties van boordcomputerunits en systeemkaarten:

Combinatie 1 is van toepassing in de fabriek waar de boordcomputerunit wordt geproduceerd. Combinatie 2 wordt gemaakt bij de boordcomputerfabrikant voorafgaand aan de distributie van de resulterende boordcomputer. Combinaties 1 en 2 vallen daarmee onder de noemer “boordcomputerproductie”.

Combinaties 3, 4 en 5 betreffen het “in het veld” (buiten de fabriek) op een boordcomputer vervangen van de huidige gekoppelde systeemkaart door een andere systeemkaart. Deze combinaties vallen onder de noemer “systeemkaartvervanging”.

3.1.1. Boordcomputerproductie

Elke boordcomputerfabrikant die een typegoedkeuring heeft verkregen kan, per typegoedkeuringsnummer, bij de Kaartuitgever een verzoek voor een transportkey indienen. De Kaartuitgever zal, na verificatie van het typegoedkeuringsnummer, via de Personalisator een transportkey voor het typegoedkeuringsnummer genereren. Deze transportkey zal op een pinmailer aan de fabrikant worden verzonden.

Elke boordcomputerfabrikant die een typegoedkeuring heeft verkregen kan, per typegoedkeuringsnummer, bij de Kaartuitgever een verzoek voor een transportkey indienen. De Kaartuitgever zal, na verificatie van het typegoedkeuringsnummer, via de Personalisator een transportkey voor het typegoedkeuringsnummer genereren. Deze transportkey zal op een pinmailer aan de fabrikant worden verzonden.

Wanneer de fabrikant boordcomputers van het desbetreffende type wil gaan produceren, zal de fabrikant op basis van het typegoedkeuringsnummer een of meer batches van systeemkaarten bestellen bij de Kaartuitgever. De Kaartuitgever / Personalisator gebruikt de eerder vastgelegde transportkey (zie voorgaande alinea) om de te produceren systeemkaarten mee te beschermen. De door de fabrikant geproduceerde boordcomputerunits dienen door de fabrikant te worden voorgeprogrammeerd met diezelfde transportkey.

Met het bovenstaande scenario kan elke nieuw geproduceerde boordcomputerunit (van een specifiek type) communiceren met elke gepersonaliseerde eerste systeemkaart (voor datzelfde boordcomputertype).

Nadat de operator bij de fabrikant een boordcomputerunit van een nieuwe systeemkaart (uit de bij de fabrikant aanwezige voorraad) heeft voorzien, dient die operator de “koppelfunctie” van de boordcomputerunit te gebruiken. Die koppelfunctie dient de typespecifieke transportkey te vervangen met een door de boordcomputerunit gegenereerde “true random” waarde. Deze sleutelvervanging dient uiteraard zowel in de boordcomputerunit als in de systeemkaart te gebeuren. Hierna kan de betreffende boordcomputerunit uitsluitend nog met de betreffende systeemkaart werken.

De onderstaande tabel geeft een overzicht van de toegangscondities en de inhoud van de verschillende security objecten van systeemkaart en boordcomputerunit zowel voor als na het koppelproces.

Tabel 1. Toegangscondities/inhoud van objecten bij eerste systeemkaarten

NB. De constructie en/of logica van de boordcomputer dient het object BCT.SECRET op adequate wijze te beschermen tegen ontvreemding (dit geheim mag uitsluitend toegankelijk zijn voor de boordcomputerlogica en uitsluitend voor de in dit document beschreven doelen worden toegepast.

De Personalisator levert een systeemkaart op met de volgende waarden:

Omdat de waarde “transportkey1” geheimgehouden is, is een gepersonaliseerde niet-gekoppelde kaart tijdens distributie onbruikbaar voor:

Omdat de waarde “transportkey1” wel bij de fabrikant bekend is, is die waarde voorgeprogrammeerd in het “Secret” object van elke nieuw geproduceerde boordcomputerunit. Hiermee kan een boordcomputerunit het koppelproces doorlopen:

NB. Het initiëren van het koppelproces kan, naar keuze van de fabrikant, een (beschermde) menugestuurde optie zijn of automatisch gebeuren als gevolg van het herkennen van een nog niet gekoppelde systeemkaart in het systeemkaartslot.

De systeemkaart is nu een-op-een gekoppeld aan de boordcomputerunit die met zijn kennis van “uniquekey1” een MAC_ENC SM kanaal kan opzetten en daarmee het volgende kan doen:

3.1.2. Systeemkaartvervanging

Dit beveiligingsconcept voorziet, teneinde reguliere certificaatvervanging te ondersteunen, in de mogelijkheid om de systeemkaart van een boordcomputer te vervangen door een andere.

Dit beveiligingsconcept voorziet, teneinde reguliere certificaatvervanging te ondersteunen, in de mogelijkheid om de systeemkaart van een boordcomputer te vervangen door een andere.

Om dit “in het veld” door een werkplaats te kunnen laten doen is het concept voor vervanging dusdanig dat er geen kennis van enig geheim vereist is bij degene die de vervanging uitvoert. Hiertoe is met de Personalisator afgesproken:

Uiteraard zal het NextKey dataobject van de vervangende systeemkaart ook weer worden gevuld met een nieuwe unieke waarde (“transportkey3”), zodat een volgende vervanging ook weer kan worden uitgevoerd.

Zoals in de vorige paragraaf is uitgelegd, worden nieuw geproduceerde boordcomputerunits in de fabriek voorgeprogrammeerd met de (typespecifieke) “transportkey1”. In die veilige omgeving kan elke willekeurige nieuwe boordcomputerunit (van een bepaald type) dan ook gekoppeld worden aan elke willekeurige gepersonaliseerde “eerste systeemkaart” (voor datzelfde boordcomputertype).

Bij het vervangen van een systeemkaart wordt de oude systeemkaart gebruikt om de boordcomputerunit te voorzien van de transportkey die nodig is voor de koppeling aan de vervangende systeemkaart. Hierbij blijft die transportkey onzichtbaar voor degene die de vervanging uitvoert. Omdat bovendien geldt dat de transportkey van elke vervangende systeemkaart uniek is voor die kaart, is bovendien gewaarborgd dat een vervangende systeemkaart uitsluitend in één (1) specifieke boordcomputer zal kunnen werken.

NB. Bij het bestellen van een vervangende systeemkaart wordt aan de Personalisator aangeduid om welke “voorloper” het gaat. Hiervoor wordt het systeemkaartnummer gebruikt dat als volgt is opgebouwd: “S” + boordcomputernummer (hetzelfde als dat van de voorloper) + kaartvolgnummer (1 hoger dan dat van de voorloper).

De onderstaande tabel geeft een overzicht van de toegangscondities en de inhoud van de verschillende security objecten van systeemkaart 1 en 2 en van de boordcomputerunit zowel voor als na het koppelproces.

Het koppelen van de boordcomputerunit aan de vervangende systeemkaart volgt dezelfde stappen als bij het koppelen aan de eerste (of voorgaande) systeemkaart zoals beschreven in § 3.1.1. Het verschil zit hem in de volgende voorbereidende stappen:

13.

4. Beveiligde gegevensoverdracht

Overeenkomstig het gestelde in Referentie [14] hoeft de gegevensoverdracht tussen boordcomputer en boordcomputerkaart niet te worden beveiligd. Volgens diezelfde referenties dient de gegevensoverdracht tussen boordcomputerlogica en systeemkaart wel beveiligd te zijn.

Overeenkomstig het gestelde in Referentie [14] hoeft de gegevensoverdracht tussen boordcomputer en boordcomputerkaart niet te worden beveiligd. Volgens diezelfde referenties dient de gegevensoverdracht tussen boordcomputerlogica en systeemkaart wel beveiligd te zijn.

Deze beveiligde gegevensoverdracht wordt bereikt door het versleutelen van de gegevens en het toevoegen van een cryptografische controlesom (MAC) aan de binnen het commando of het antwoord gezonden gegevensobjecten (MAC-ENC mode).

De MAC van binnen een commando gezonden gegevens moet de commando-kop en alle gezonden gegevensobjecten integreren (=> CLA = '0C', en alle gegevensobjecten moeten worden ingekapseld met tags waarin b1 = 1).

De MAC moet door de ontvanger geverifieerd worden.

4.1. Structuur van commando’s en antwoorden bij beveiligde gegevensoverdracht

In de onderstaande figuren zijn schematisch een beveiligd commando en een beveiligd antwoord weergegeven. Voor een verdere beschrijving hiervan wordt verwezen naar Referentie [7], section 7.1.9 en section 7.1.10.

4.2. Fouten bij de beveiligde gegevensoverdracht

Wanneer de systeemkaart tijdens het verwerken van een commando een Secure Messaging-fout ontdekt, dan moeten de statuswoorden zonder Secure Messaging teruggezonden worden. Overeenkomstig ISO/IEC 7816-4 moeten de onderstaande statuswoorden gebruikt worden om Secure Messaging-fouten aan te geven:

Wanneer de systeemkaart tijdens het verwerken van een commando een Secure Messaging-fout ontdekt, dan moeten de statuswoorden zonder Secure Messaging teruggezonden worden. Overeenkomstig ISO/IEC 7816-4 moeten de onderstaande statuswoorden gebruikt worden om Secure Messaging-fouten aan te geven:

'69 82' Veiligheids toestand voldoet niet,

'69 85' Sessiesleutels zijn niet beschikbaar,

'69 87' Verwachte Secure Messaging-gegevensobjecten ontbreken,

'69 88' Secure Messaging-gegevensobjecten onjuist.

Wanneer de systeemkaart statuswoorden zonder Secure Messaging gegevensobjecten of met een foutieve Secure Messaging gegevensobjecten terugzendt, moet de sessie door de boordcomputerlogica afgebroken worden.

4.3. Sessiesleutels

Voor beveiligde gegevensoverdracht tussen de boordcomputerlogica en de systeemkaart worden twee 16 bytes lange sessiesleutels gebruikt. De methode om deze sessiesleutels SKENC en SKMAC te genereren wordt beschreven in Referentie [7], section 7.1.4.

4.4. Zendsequentieteller (SSC)

Tijdens de authenticatie procedure wordt er door zowel de systeemkaart als door de boordcomputerlogica een 8 bytes random gegenereerd, RND.BCT resp. RND.ICC.

Tijdens de authenticatie procedure wordt er door zowel de systeemkaart als door de boordcomputerlogica een 8 bytes random gegenereerd, RND.BCT resp. RND.ICC.

De vier minst significante bytes (LSB) van beiden worden gebruikt om de initiële waarde voor de SSC te bepalen: SSC = RND.ICC (4 LSB) || RND.BCT (4 LSB).

4.5. Algoritmes

Het algoritme dat gebruikt wordt voor het berekenen van cryptogrammen wordt beschreven in Referentie [7], section 7.1.9 en section 7.1.10.

Het algoritme dat gebruikt wordt voor het berekenen van cryptogrammen wordt beschreven in Referentie [7], section 7.1.9 en section 7.1.10.

Het algoritme dat gebruikt wordt voor het berekenen van cryptografische controlesommen (MACs) wordt beschreven in Referentie [7], section 7.1.12.

De MAC is 8 bytes lang.

4.6. Authenticatiescenario Systeemkaart-Boordcomputer

Het authenticatiescenario tussen systeemkaart en boordcomputer wordt uitgevoerd zoals beschreven is in Referentie [7], section 5.2.2.

Het authenticatiescenario tussen systeemkaart en boordcomputer wordt uitgevoerd zoals beschreven is in Referentie [7], section 5.2.2.

Hierbij moet gelet worden op de volgende punten:

Na een succesvolle uitvoering van de Mutual Authenticate kunnen de sessiesleutels en de SSC berekend worden, zoals beschreven is in Referentie [7], section 7.1.4 en 7.1.5.

5. Gegevens op chauffeurskaart (EF.Driver_Activity_Data)

Op de chauffeurskaart worden de arbeids- rij- en rusttijden van een chauffeur opgeslagen in de bestandsstructuur EF.Driver_Activity_Data. De grootte van die bestandsstructuur wordt door de Personalisator op elke chauffeurskaart gemaximeerd (zie ook § 7.1, § 9.5 en Referentie [9] in hoofdstuk 10).

5.1. Opbouw van EF.Driver_Activity_Data

EF.Driver_Activity_Data is opgebouwd uit de volgende elementen:

5.1.1. DailyRecord

Een DailyRecord bevat alle gegevens van de activiteiten van de chauffeur op een bepaalde dag. Na personaliseren bestaat er nog geen enkel DailyRecord.

Een DailyRecord bevat alle gegevens van de activiteiten van de chauffeur op een bepaalde dag. Na personaliseren bestaat er nog geen enkel DailyRecord.

5.1.2. SessionRecord

Een SessionRecord bevat de gegevens van de activiteiten van de chauffeur voor een kaartsessie. Indien er meerdere kaartsessies op een dag zijn, zijn er voor die dag ook meerdere SessionRecords. Na personaliseren bestaat er nog geen enkel SessionRecord.

Een SessionRecord bevat de gegevens van de activiteiten van de chauffeur voor een kaartsessie. Indien er meerdere kaartsessies op een dag zijn, zijn er voor die dag ook meerdere SessionRecords. Na personaliseren bestaat er nog geen enkel SessionRecord.

De lengte van een SessionRecord kop (zonder de ActivityRecords) is 299 bytes.

5.1.3. ActivityRecord

Er wordt een aantal types ActivityRecords onderscheiden aan de hand van de activiteit.

Er wordt een aantal types ActivityRecords onderscheiden aan de hand van de activiteit.

Een ActivityRecord heeft een kop van 24 bits (3 bytes) groot die de volgende elementen bevat:

Noot 1: Bij de activiteit “Start werk” wordt een Rijtijdveld aan de kop toegevoegd. Dit werkt als volgt:

Noot 2: Bij zowel de activiteit “Start werk” als “Start pauze” wordt een Tijdsduurveld aan de kop toegevoegd. Dit werkt als volgt:

5.1.4. Overzicht

De gegevens worden per dag vastgelegd en moeten minimaal 31 kalenderdagen beschikbaar blijven op de kaart. Voor iedere dag dat er gegevens op de chauffeurskaart vastgelegd moeten worden, wordt er een DailyRecord aangemaakt.

De gegevens worden per dag vastgelegd en moeten minimaal 31 kalenderdagen beschikbaar blijven op de kaart. Voor iedere dag dat er gegevens op de chauffeurskaart vastgelegd moeten worden, wordt er een DailyRecord aangemaakt.

Naast de arbeids- rij- en rusttijden zelf moet ook vastgelegd worden voor welke ondernemer en in welk voertuig deze tijden gemaakt zijn en welke boordcomputer er gebruikt is. Dit wordt per sessie vastgelegd in het SessionRecord.

5.2. Schrijven naar EF.Driver_Activity_Data

Activiteiten van de chauffeur worden opgeslagen in ActivityRecords. In Figuur 6 worden de verschillende typen van ActivityRecords genoemd. Het verloop van een sessie staat in hoofdstuk 7 beschreven. Het exacte verloop van het toevoegen van een ActivityRecord staat in § 0.

5.2.1. Toevoegen van de eerste activiteit binnen een SessionRecord

Elk van de navolgende subparagrafen (5.2.2 t/m 5.2.7) gaat er van uit dat de toe te voegen activiteit niet de eerste activiteit binnen het betreffende SessionRecord is. Indien dat echter wél het geval is, moeten de instructies voor het overschrijven van de PointerLastActivityRecord en de DayRecordLength velden telkens worden vervangen door de volgende:

5.2.2. Toevoegen “Login” activiteit

De “Login” activiteit geeft de werkelijke tijd aan dat de chauffeurskaart in de boordcomputer ingebracht is en de authenticatie plaatsgevonden heeft. Dit is het login-tijdstip. Dit staat beschreven in 7.1.

De “Login” activiteit geeft de werkelijke tijd aan dat de chauffeurskaart in de boordcomputer ingebracht is en de authenticatie plaatsgevonden heeft. Dit is het login-tijdstip. Dit staat beschreven in 7.1.

Bij een “Login” wordt er een nieuw ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

5.2.3. Toevoegen “Start pauze” activiteit

Bij een “Start pauze” wordt er een nieuw ActivityRecord aangemaakt.

Bij een “Start pauze” wordt er een nieuw ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

5.2.4. Toevoegen “Start werk” activiteit

Bij een “Start werk” wordt er een nieuw ActivityRecord aangemaakt.

Bij een “Start werk” wordt er een nieuw ActivityRecord aangemaakt.

“Start werk” wijkt af van de andere activiteiten. Hierin wordt bijgehouden hoeveel secondes het voertuig gereden heeft gedurende deze activiteit. Zolang de chauffeur nog aan het werk is en het voertuig afwisselend rijdt en stilstaat, wordt iedere keer zodra het voertuig stopt het aantal secondes dat er gereden is bijgewerkt. Er wordt dus niet iedere keer een nieuw ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

5.2.5. Toevoegen “Afsluiting” activiteit

Bij een normale afsluiting door de chauffeur, “Afsluiting”, wordt er een nieuw ActivityRecord aangemaakt.

Bij een normale afsluiting door de chauffeur, “Afsluiting”, wordt er een nieuw ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

5.2.6. Toevoegen “Nieuwe eindtijd” (=handmatige Afsluiting) activiteit

Wanneer er bij een sessie nog activiteiten toegevoegd worden, kan het voorkomen dat de eindtijd aangepast moet worden. Dit wordt gedaan met een “Nieuwe eindtijd” activiteit. Hierbij wordt er een nieuwe ActivityRecord aangemaakt.

Wanneer er bij een sessie nog activiteiten toegevoegd worden, kan het voorkomen dat de eindtijd aangepast moet worden. Dit wordt gedaan met een “Nieuwe eindtijd” activiteit. Hierbij wordt er een nieuwe ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

5.2.7. Toevoegen “Dagovergang (handmatig/automatisch)” activiteit

Wanneer er een sessie actief is, de laatstgeboekte activiteit een “Start werk” of “Start pauze” is en:

Wanneer er een sessie actief is, de laatstgeboekte activiteit een “Start werk” of “Start pauze” is en:

dan moet:

Het toevoegen van het nieuwe DailyRecord met een nieuw SessionRecord en een eerste “Start pauze” of “Start werk” activiteit wordt beschreven in respectievelijk § 8.11, § 8.10, § 5.2.1 en § 5.2.3 / 5.2.4. Hier wordt uitsluitend toevoeging van de “Dagovergang” aan het huidige SessionRecord beschreven.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

In het huidige DailyRecord blijft DayRecordLength gelijk, omdat het (inmiddels) vorige ActivityRecord een “Start werk” of “Start pauze” betreft.

5.3. Algemene opmerkingen bij lezen en schrijven naar EF.Driver_Activity_Data

Bij lees- en schrijfacties (Read Binary en Update Binary) dient met de volgende punten rekening te worden gehouden:

5.4. Digitale handtekening

Om de integriteit van gegevens te waarborgen, worden digitale handtekeningen gebruikt. Er worden twee soorten digitale handtekeningen onderscheiden:

Om de integriteit van gegevens te waarborgen, worden digitale handtekeningen gebruikt. Er worden twee soorten digitale handtekeningen onderscheiden:

In dit document gaat het om de tweede soort, waarbij de handtekeningen op de chauffeurskaart worden opgeslagen. De handtekeningen die op de boordcomputer opgeslagen worden, worden hier verder buiten beschouwing gelaten.

De digitale handtekening wordt berekend over het DriverCardNumber, de DayRecordDate en een deel van het SessionRecord (zie 5.1.2) en wordt opgeslagen in het veld SessionSignature in het betreffende SessionRecord. Daarbij worden de mogelijke vorige SignatureDateTime en handtekening in dit SessionRecord overschreven. Het te ondertekenen DriverCardNumber is een 16-karakter PrintableString zoals die aansluitend op het inloggen van de chauffeur door de boordcomputer uit de eerste 16 bytes van het subject.serialNumber van het authenticiteitcertificaat van de chauffeurskaart is gelezen. De kopie van het DriverCardNumber die is opgeslagen in bytes ‘00 04’H t/m ‘00 13’H van EF.Driver_Activity_Data mag NIET worden gebruikt bij de berekening van de handtekening.

Om het verlies van gegevens zoveel mogelijk te voorkomen wanneer de chauffeurskaart voortijdig uitgenomen wordt, wordt er na iedere toevoeging van een ActivityRecord (zie 5.1.3) een digitale handtekening berekend en opgeslagen.

Bij de berekening van de handtekening wordt van het laatst toegevoegde ActivityRecord alleen de kop van 3 bytes meegenomen. De reden hiervoor is gelegen in de activiteiten “Start werk” en “Start pauze”. De 6 respectievelijk 3 gegevensbytes die bij deze activiteitsoorten horen worden te vaak bijgewerkt (voor het telkens herberekenen van handtekeningen) en de laatste 3 gegevensbytes worden sowieso overschreven door de vervolgactiviteit. De rijtijdteller van een “Start werk” activiteit wordt hiermee pas meegenomen in de handtekening nadat een vervolgactiviteit wordt gestart.

Om een handtekening te kunnen berekenen, moet eerst de SignatureDateTime worden bijgewerkt met de huidige datum en tijd volgens BCT-klok, dan moet een hashcode berekend worden. Deze hashcode wordt dan gebruikt als input voor het berekenen van de handtekening. De gegevens voor het berekenen van de hashcode moeten in de hieronder genoemde volgorde staan:

*) Van het laatste ActivityRecord wordt alleen de kop (3 bytes) meegenomen.

De berekening van de handtekening wordt volledig door de boordcomputer uitgevoerd en gebeurt als volgt:

NB. Telkens bij het berekenen van de SHA-256 hash dient de boordcomputerlogica het eerste en grootste deel van de berekening (de hash over de data vanaf het DriverCardNumber t/m de ActivityRecords) uit te voeren, waarna het laatste deel van de hashberekening (over de PointerLastActivitityRecord t/m de SignatureDateTime) door de systeemkaart dient te worden berekend. Ook de PKCS#1 v1.5 handtekening dient door de systeemkaart te worden berekend.

NB2. Met behulp van het certificaat behorende bij de private sleutel voor authenticiteit van de boordcomputer (het boordcomputercertificaat) kan gecontroleerd worden of de gegevens in een SessionRecord authentiek zijn. Behalve het boordcomputercertificaat en het SessionRecord zelf, zijn voor zo’n validatie het DriverCardNumber en de DayRecordDate benodigd. Die twee gegevens staan elders in EF.Driver_Activity_Data opgeslagen. Welk boordcomputercertificaat voor een bepaalde SessionRecord-validatie moet worden gebruikt, kan worden achterhaald door het SystemCardNumber in de SessionRecord-kop uit te lezen.

6. Gegevens op chauffeurskaart (EF.BCT_Certificates)

De certificaten van de boordcomputer die gebruikt zijn bij het berekenen van de handtekeningen op de chauffeurskaart worden opgeslagen in EF.BCT_Certificates. Hierin is plaats voor de systeemkaartcertificaten van de 3 verschillende boordcomputers waarin de chauffeurskaart het laatst is gebruikt.

De certificaten van de boordcomputer die gebruikt zijn bij het berekenen van de handtekeningen op de chauffeurskaart worden opgeslagen in EF.BCT_Certificates. Hierin is plaats voor de systeemkaartcertificaten van de 3 verschillende boordcomputers waarin de chauffeurskaart het laatst is gebruikt.

6.1. Opbouw van EF.BCT_Certificates

EF.BCT_Certificates is opgebouwd uit de volgende elementen:

EF.BCT_Certificates is opgebouwd uit de volgende elementen:

In Figuur 9 wordt een overzicht van EF.BCT_Certificates gegeven met de initiële waardes.

7. Kaartsessie

Een kaartsessie is de periode tussen het ingeven van de chauffeurskaart en het wegschrijven van de afsluitende gegevens op de chauffeurskaart door de boordcomputer. In Figuur 10 is het overzicht van een kaartsessie weergegeven.

Een kaartsessie is de periode tussen het ingeven van de chauffeurskaart en het wegschrijven van de afsluitende gegevens op de chauffeurskaart door de boordcomputer. In Figuur 10 is het overzicht van een kaartsessie weergegeven.

7.1. Begin van een kaartsessie

Het begin van een kaartsessie gaat als volgt:

7.2. Tijdens een kaartsessie

Tijdens een kaartsessie zijn er twee activiteiten mogelijk: “Start pauze” en “Start werk”. Voor het toevoegen van deze activiteiten, zie 5.2.1 respectievelijk 5.2.4.

Tijdens een kaartsessie zijn er twee activiteiten mogelijk: “Start pauze” en “Start werk”. Voor het toevoegen van deze activiteiten, zie 5.2.1 respectievelijk 5.2.4.

7.3. Afsluiten van een kaartsessie

Bij het beeindigen van een kaartsessie dient de chauffeur de kaartsessie af te sluiten, voordat hij de chauffeur zijn kaart uit de boordcomputer neemt. Zou hij de sessie niet afsluiten wordt deze geblokkeerd.

Bij het beeindigen van een kaartsessie dient de chauffeur de kaartsessie af te sluiten, voordat hij de chauffeur zijn kaart uit de boordcomputer neemt. Zou hij de sessie niet afsluiten wordt deze geblokkeerd.

Bij het afsluiten van een kaartsessie wordt een “Afsluiting” activiteit toegevoegd, zie 5.2.5.

7.4. Niet afgesloten kaartsessie

Het is mogelijk dat de chauffeur zijn kaart uit de boordcomputer haalt zonder dat hij de kaartsessie afgesloten heeft. In dat geval is er dus geen ActivityRecord aangemaakt voor het afsluiten van de kaartsessie. De boordcomputer constateert dat de kaart is uitgenomen zonder dat de sessie is afgesloten en blokkeert deze kaartsessie.

Het is mogelijk dat de chauffeur zijn kaart uit de boordcomputer haalt zonder dat hij de kaartsessie afgesloten heeft. In dat geval is er dus geen ActivityRecord aangemaakt voor het afsluiten van de kaartsessie. De boordcomputer constateert dat de kaart is uitgenomen zonder dat de sessie is afgesloten en blokkeert deze kaartsessie.

De op de boordcomputer geblokkeerde kaartsessie wordt beëindigd door:

De eerstvolgende keer dat een chauffeurskaart met een niet afgesloten kaartsessie weer in een boordcomputer wordt ingebracht, krijgt de chauffeur een melding dat de kaartsessie niet goed afgesloten was. De uitzondering hierop is het eerste punt hierboven, waarbij de kaartsessie voortgezet wordt.

7.5. Dagoverschrijdende kaartsessie

Het is mogelijk dat een kaartsessie actief is om 12 uur ’s nachts. Ook kan dat het geval blijken te zijn tijdens het handmatig invoegen van activiteiten (de laatst geboekte activiteit blijkt “Start werk” of “Start pauze” te zijn en de toe te voegen activiteit blijkt te moeten starten in de kalenderdag na die van zijn voorganger). Omdat de activiteiten per dag opgeslagen worden, moet de kaartsessie hier gesplitst worden.

Het is mogelijk dat een kaartsessie actief is om 12 uur ’s nachts. Ook kan dat het geval blijken te zijn tijdens het handmatig invoegen van activiteiten (de laatst geboekte activiteit blijkt “Start werk” of “Start pauze” te zijn en de toe te voegen activiteit blijkt te moeten starten in de kalenderdag na die van zijn voorganger). Omdat de activiteiten per dag opgeslagen worden, moet de kaartsessie hier gesplitst worden.

8. Functies

De commando-antwoord paren (zie hoofdstuk 9) vormen het laagste niveau van communicatie met de boordcomputerkaarten.

De commando-antwoord paren (zie hoofdstuk 9) vormen het laagste niveau van communicatie met de boordcomputerkaarten.

Met behulp van één of meerdere commando’s kunnen functies benoemd worden die een logische actie vertegenwoordigen, zoals het wijzigen of deblokkeren van een pincode.

8.1. PIN wijzigen

Voor het wijzigen van een PIN moet de oude PIN bekend zijn, anders is dit niet mogelijk.

Voor het wijzigen van een PIN moet de oude PIN bekend zijn, anders is dit niet mogelijk.

Voor de oude en nieuwe PIN wordt het PIN formaat 2 gebruikt. Dit is 8 bytes lang en is als volgt opgebouwd:

Waarin:

De PIN is dus maximaal 12 cijfers lang.

8.2. SM keyset wijzigen

Op de systeemkaart mag deze functie alleen uitgevoerd worden onder beveiligde gegevensoverdracht (zie Hoofdstuk 4).

Op de systeemkaart mag deze functie alleen uitgevoerd worden onder beveiligde gegevensoverdracht (zie Hoofdstuk 4).

Voor het wijzigen van een SM key set moet er een Secure Messaging kanaal bestaan en daarmee moet de oude SM key set bekend zijn, anders is dit niet mogelijk.

Het gebruikte commando is Put Data, waarbij de nieuwe (symmetrische) key set als data meegegeven wordt. Het volledige data veld heeft de vorm

‘70 2A BF 8A 03 26 A2 24 90 10’ || Kmac || ‘91 10’ || Kenc

8.3. PIN deblokkeren

Hierbij wordt de bestaande PIN gedeblokkeerd.

Hierbij wordt de bestaande PIN gedeblokkeerd.

Het gebruikte commando is Reset Retry Counter, waarbij P1 de waarde ‘03’H heeft en P2 (de PIN reference) de waarde ‘01’H heeft.

8.4. PIN deblokkeren en wijzigen

Hierbij wordt de bestaande PIN gedeblokkeerd en gewijzigd in de Nieuwe PIN.

Hierbij wordt de bestaande PIN gedeblokkeerd en gewijzigd in de Nieuwe PIN.

Het gebruikte commando is Reset Retry Counter, waarbij P1 de waarde ‘02’H heeft en P2 (de PIN reference) de waarde ‘01’H heeft.

8.5. Elektronische handtekening zetten met een chauffeurs- of inspectiekaart

Deze functie wordt gebruikt voor het door een natuurlijke persoon zetten van een rechtsgeldige elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.DS die uitsluitend op chauffeurs- en inspectiekaarten bestaat.

Deze functie wordt gebruikt voor het door een natuurlijke persoon zetten van een rechtsgeldige elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.DS die uitsluitend op chauffeurs- en inspectiekaarten bestaat.

Elke boordcomputerkaart (chip) ondersteunt minimaal een van de twee navolgende procedures voor het uitvoeren van deze functie. De boordcomputer moet op basis van het door de chip geleverde Answer To Reset (ATR) bepalen welke van de twee procedures met de betreffende chip gebruikt moet worden. Bij chips die beide procedures ondersteunen is de boordcomputer vrij om een van beide procedures te kiezen.

Voor deze functie bestaat procedure 1 uit de volgende stappen:

8.6. Elektronische handtekening zetten met een systeemkaart

Zie ook PSO Hash en PSO Compute Digital Signature in Referentie [7].

Voor de vermelde SDO ID wordt verwezen naar de kaartstructuur documenten in Referenties [9] en [12]. Omdat dit SDO een lokaal object is, moet de in de kaartstructuur documenten gespecificeerde keyReference niet letterlijk worden overgenomen, maar met bit8 hoog (dus ‘86’H in plaats van ‘06’H).

Deze functie wordt gebruikt voor het door een boordcomputer zetten van een elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT van de systeemkaart.

Deze functie wordt gebruikt voor het door een boordcomputer zetten van een elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT van de systeemkaart.

Op de systeemkaart mag deze functie alleen uitgevoerd worden onder beveiligde gegevensoverdracht (zie Hoofdstuk 4), gebruikmakend van de sleutelset SM.ICC.

Elke systeemkaart (chip) ondersteunt minimaal een van de twee navolgende procedures voor het uitvoeren van deze functie. De boordcomputer moet op basis van het door de chip geleverde Answer To Reset (ATR) bepalen welke van de twee procedures met de betreffende chip gebruikt moet worden. Bij chips die beide procedures ondersteunen is de boordcomputer vrij om een van beide procedures te kiezen.

8.7. Authenticiteit handtekening zetten met een boordcomputerkaart

Voor deze functie bestaat procedure 2 uit de volgende stappen (nummering gelijk aan die van procedure 1):

Zie ook PSO Hash en PSO Compute Digital Signature in Referentie [7]).

Voor de vermelde SDO ID wordt verwezen naar het kaartstructuur documenten in Referentie [8]. Omdat dit SDO een lokaal object is, moet de in het kaartstructuur document gespecificeerde keyReference niet letterlijk worden overgenomen, maar met bit8 hoog (dus ‘85’H in plaats van ‘05’H).

Noot: Zie ook 5.4 (digitale handtekening).

Deze functie wordt gebruikt voor het door een boordcomputerkaarthouder zetten van een elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT die op elke boordcomputerkaart bestaat.

8.8. Authenticeren boordcomputerkaart aan boordcomputer

Elke boordcomputerkaart (chip) ondersteunt minimaal een van de twee navolgende procedures voor het uitvoeren van deze functie. De boordcomputer moet op basis van het door de chip geleverde Answer To Reset (ATR) bepalen welke van de twee procedures met de betreffende chip gebruikt moet worden. Bij chips die beide procedures ondersteunen is de boordcomputer vrij om een van beide procedures te kiezen.

Voor deze functie bestaat procedure 1 uit de volgende stappen:

Voor deze functie bestaat procedure 2 uit de volgende stappen (nummering gelijk aan die van procedure 1):

Zie ook PSO Hash en PSO Compute Digital Signature in Referentie [7].

8.8. Authenticeren boordcomputerkaart aan boordcomputer

Om te controleren of een boordcomputerkaart authentiek is, wordt er een Client/Server authenticatie uitgevoerd (zie Referentie [7]). Hierbij wordt een boordcomputer challenge ondertekend met behulp van de sleutel-certificaatcombinatie PKI.CH.AUT van de een boordcomputerkaart. Deze functie is analoog aan SignDataForAuthenticity, maar wordt hier uitsluitend voor authenticatiedoeleinden gebruikt.

Om te controleren of een boordcomputerkaart authentiek is, wordt er een Client/Server authenticatie uitgevoerd (zie Referentie [7]). Hierbij wordt een boordcomputer challenge ondertekend met behulp van de sleutel-certificaatcombinatie PKI.CH.AUT van de een boordcomputerkaart. Deze functie is analoog aan SignDataForAuthenticity, maar wordt hier uitsluitend voor authenticatiedoeleinden gebruikt.

Voor deze functie moeten een aantal stappen doorlopen worden:

NB. De boordcomputerkaarten ondersteunen Windows/Kerberos smartcard logon. Ook deze wijze van authenticeren is toegestaan, mits ook hier de geldigheid van het authenticiteitcertificaat middels een padvalidatie wordt gevalideerd.

Voor de vermelde SDO ID wordt verwezen naar de kaartstructuur documenten in Referenties [9] t/m [12]. Omdat dit SDO een lokaal object is, moet de in de kaartstructuur documenten gespecificeerde keyReference niet letterlijk worden overgenomen, maar met bit8 hoog (dus ‘85’H in plaats van ‘05’H).

Deze functie wordt gebruikt om een ActivityRecord toe te voegen in EF.Driver_Activity_Data.

Deze functie wordt gebruikt om een ActivityRecord toe te voegen in EF.Driver_Activity_Data.

8.10. Schrijf nieuw SessionRecord

Deze functie moet, voorafgaand aan het daadwerkelijk toevoegen van het ActivityRecord, aan de hand van meegestuurde argumenten, het laatst in EF.Driver_Activity_Data geboekte ActivityRecord en de status van de boordcomputer bepalen of voor het ActivityRecord al dan niet een nieuw DailyRecord en/of SessionRecord moet worden aangemaakt en op welke geheugenpositie het nieuwe ActivityRecord moet worden toegevoegd. Stapsgewijs is de daarvoor te volgen logica als volgt:

NB1. NewActivityPointer, LastActivityRecordHeader en NewActivityLength maken géén onderdeel van de structuur uit, maar zijn tijdelijke waardes in het geheugen van de boordcomputer.

NB2. Indien het LastActivityRecord een “(Start) werk” of “(Start) pauze” betreft worden met het bovenstaande algoritme de laatste 3 bytes (waarin de tijdsduur van de activiteit tijdelijk werd bijgehouden) overschreven door het nieuw toe te voegen ActivityRecord.

8.11. Schrijf nieuw DailyRecord

Voer tot slot nog de procedure uit voor het door de boordcomputer ondertekenen van het aangepaste SessionRecord, zoals beschreven in § 5.4.

Deze functie wordt gebruikt om een nieuw leeg SessionRecord aan het huidige DailyRecord toe te voegen. Deze functie wordt altijd aangeroepen vanuit de functie voor het toevoegen van een ActivityRecord (zie 0)

Deze functie wordt gebruikt om een nieuw leeg SessionRecord aan het huidige DailyRecord toe te voegen. Deze functie wordt altijd aangeroepen vanuit de functie voor het toevoegen van een ActivityRecord (zie 0)

8.12. Selecteer laatste (nieuwste) DailyRecord

Noot: Zie 5.3, aangezien de mogelijkheid bestaat dat de te schrijven data niet aan het eind van EF.Driver_Activity_Data past.

8.11. Schrijf nieuw DailyRecord

Deze functie wordt gebruikt om een nieuw leeg DailyRecord toe te voegen. Dit wordt gedaan voor de eerste registratie van een dag. Dit nieuwe DailyRecord bevat nog geen SessionRecords.

8.14. Selecteer vorige DailyRecord

Noot: Zie 5.3, aangezien de mogelijkheid bestaat dat de te schrijven data niet aan het eind van EF.Driver_Activity_Data past.

8.12. Selecteer laatste (nieuwste) DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.13. Selecteer oudste (eerste) DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.14. Selecteer vorige DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.15. Selecteer volgende DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

Hiervoor moeten de volgende stappen doorlopen worden:

8.17. Controleer EF.Driver_Activity_Data structuur

Hiervoor moeten de volgende stappen doorlopen worden:

Hiervoor moeten de volgende stappen doorlopen worden:

8.18. Controleren op opgeslagen boordcomputercertificaat

In deze functie wordt gecontroleerd of het certificaat behorende bij het systeemkaartnummer al opgeslagen is in EF.BCT_Certificates.

Voor deze functie moeten de volgende stappen doorlopen worden:

8.19. Volgorde bijwerken van opgeslagen boordcomputercertificaten

Indien het certificaat behorende bij het systeemkaartnummer aanwezig is in EF.BCT_Certificates, wordt deze als meest recente in de Rank gezet.

Voor deze functie moeten de volgende stappen doorlopen worden:

8.20. Geef opgeslagen boordcomputercertificaat

Indien het certificaat behorende bij het systeemkaartnummer aanwezig is in EF.BCT_Certificates, wordt dit als resultaat terug gegeven.

8.21. Sla boordcomputercertificaat op

Het systeemkaartnummer wordt met het bijbehorende certificaat als meest recente opgeslagen in EF.BCT_Certificates. Hierbij wordt de plaats van het minst recente certificaat overschreven.

Het systeemkaartnummer wordt met het bijbehorende certificaat als meest recente opgeslagen in EF.BCT_Certificates. Hierbij wordt de plaats van het minst recente certificaat overschreven.

8.22. Geef meest recente DownloadLog

Voor deze functie moeten de volgende stappen doorlopen worden:

Voor deze functie moeten de volgende stappen doorlopen worden:

Het in de Input opgegeven DownloadLog wordt als het meest recente opgeslagen in DownloadLogs van EF.BCT_Certificates. Hierbij wordt de plaats van het minst recente DownloadLog overschreven.

Het in de Input opgegeven DownloadLog wordt als het meest recente opgeslagen in DownloadLogs van EF.BCT_Certificates. Hierbij wordt de plaats van het minst recente DownloadLog overschreven.

Voor deze functie moeten de volgende stappen doorlopen worden:

9. Commando’s

De communicatie met de boordcomputerkaarten gebeurt door middel van commando-antwoord paren. Het commando wordt naar de boordcomputerkaart toegestuurd en daarop komt een antwoord terug.

Een commando bestaat uit:

Een antwoord bestaat uit:

9.2. Uitlezen van een nog niet geselecteerde EF vanaf een offset < 256

De paragrafen hieronder vermelden bepaalde file identifiers en short EF identifiers. Voor een volledig overzicht van de beschikbare short EF identifiers (SFIDs) wordt verwezen naar Referenties [8] t/m [12].

9.1. Selecteren van EF’s

Voordat een EF kan worden uitgelezen of beschreven, dient deze geselecteerd te worden. Voordat een EF geselecteerd kan worden, dient eerst de Dedicated File (DF) waar deze EF onderdeel van uitmaakt te worden geselecteerd. Conform Referenties [8] t/m [12] bevat elke BCT kaart de volgende twee DF’s:

9.4. In de huidige DF Uitlezen van een EF vanaf een offset groter dan 32767

Nadat de betreffende DF is geselecteerd, kan elke daarin opgenomen EF op een van de volgende wijzen worden geselecteerd:

9.2. Uitlezen van een nog niet geselecteerde EF vanaf een offset < 256

Als voorbeeld van efficiënt coderen volgt hier de kleinste commandoreeks waarmee de 4e t/m 7e byte (willekeurig voorbeeld) van EF.BCT_Certificates kunnen worden uitgelezen:

Als voorbeeld van efficiënt coderen volgt hier het kleinste commando waarmee de 4000e t/m 4050e byte (willekeurig voorbeeld) van de momenteel geselecteerde EF kunnen worden uitgelezen:

Als voorbeeld van efficiënt coderen volgt hier het kleinste commando waarmee de 4000e t/m 4050e byte (willekeurig voorbeeld) van de momenteel geselecteerde EF kunnen worden uitgelezen:

Als voorbeeld van efficiënt coderen volgt hier de kleinste commandoreeks waarmee de 40000e t/m 40001e byte en dan de 40002e t/m 40003e byte (willekeurig voorbeeld) van de nog niet eerder geselecteerde EF.Driver_Activity_Data kunnen worden uitgelezen (uitgangspunt is dat de DF.CIA wel al geselecteerd is):

Als voorbeeld van efficiënt coderen volgt hier de kleinste commandoreeks waarmee de 40000e t/m 40001e byte en dan de 40002e t/m 40003e byte (willekeurig voorbeeld) van de nog niet eerder geselecteerde EF.Driver_Activity_Data kunnen worden uitgelezen (uitgangspunt is dat de DF.CIA wel al geselecteerd is):

9.5. Opvragen van de FCP’s o.a. voor de grootte van EF.Driver_Activity_Data

Omdat EF.Driver_Activity_Data per chauffeurskaart een eigen grootte heeft, is het noodzakelijk om minimaal één keer per kaartsessie te achterhalen wat die grootte exact is. Hiervoor biedt de chip (conform referentie [7]) en diens personalisatie de mogelijkheid om van EF’s de file control parameters (FCP) op te vragen. Er van uitgaande dat de DF.CAI reeds is geselecteerd, is het betreffende commando voor de EF.Driver_Activity_Data als volgt:

11. Begrippen en afkortingen

62 1B 80 02 xx xx 82 01 01 83 02 44 01 88 01 98 A1 08 8C 02 01 00 9C 02 01 00 8A 01 05 90 00

Bijlage A. Scenario’s kaartsessies

Voor een compleet overzicht van FCP wordt verwezen naar § 3.3.4.1 van Referentie [7].

10. Referenties

11. Begrippen en afkortingen

11. Begrippen en afkortingen

Bijlage A. Scenario’s kaartsessies

Bijlage A. Scenario’s kaartsessies

A.1. Scenario 1: Normale kaartsessie

A.1. Scenario 1: Normale kaartsessie

A.2. Scenario 2: Sessie afgesloten met pauze, nieuwe sessie met einde pauze

A.3. Scenario 3: Sessie afgesloten met pauze, nieuwe sessie met einde pauze en andere werkzaamheden

A.4. Scenario 4: Sessie afgesloten, volgende dag toevoegen van andere werkzaamheden aan de vorige dag

Hieronder volgt een aantal voorbeelden van functies met de uitgewerkte hexadecimale codes. Dit geeft een beter inzicht in het toepassen van deze functies in de Boordcomputer Taxi.

A.6. Scenario 6: Sessie niet afgesloten, vervolg zelfde werkzaamheden

Voor het opzetten van Secure Messaging, zoals beschreven staat in 4.6, worden de volgende stappen uitgevoerd:

A.8. Scenario 8: Sessie niet afgesloten, later automatisch beëindigd

Na het opzetten van de secure messaging verbinding, moeten alle volgende commando's met secure messaging uitgevoerd worden. Dit staat beschreven in 4.1 t/m 4.5.

Hieronder volgt een aantal voorbeelden van functies met de uitgewerkte hexadecimale codes. Dit geeft een beter inzicht in het toepassen van deze functies in de Boordcomputer Taxi.

Hieronder volgt een aantal voorbeelden van functies met de uitgewerkte hexadecimale codes. Dit geeft een beter inzicht in het toepassen van deze functies in de Boordcomputer Taxi.

Voor het opzetten van Secure Messaging, zoals beschreven staat in 4.6, worden de volgende stappen uitgevoerd:

B.2. Het sturen van commando’s met Secure Messaging

B.2. Het sturen van commando’s met Secure Messaging

Na het opzetten van de secure messaging verbinding, moeten alle volgende commando's met secure messaging uitgevoerd worden. Dit staat beschreven in 4.1 t/m 4.5.

B.3.2. SignDataForAuthenticity

Om te komen van een normaal commando tot een commando onder secure messaging, moeten de volgende stappen doorlopen worden:

B.3. Het zetten van een handtekening met een boordcomputerkaart

NB. Deze functie moet uitgevoerd worden onder secure messaging, zoals beschreven is in B.2. Voor het overzicht worden onderstaande commando’s en responses echter zonder deze secure messaging weergegeven.

Voor het zetten van een elektronische handtekening met een boordcomputerkaart, zoals beschreven staat in 8.5, worden de volgende stappen uitgevoerd:

Deze regeling zal met de toelichting in de Staatscourant worden geplaatst.

Voor deze functie bestaat procedure 2 uit de volgende stappen (nummering gelijk aan die van procedure 1):

8.6. Elektronische handtekening zetten met een systeemkaart

Voor deze functie bestaat procedure 1 uit de volgende stappen:

8.7. Authenticiteit handtekening zetten met een boordcomputerkaart

Deze functie wordt gebruikt voor het door een boordcomputerkaarthouder zetten van een elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT die op elke boordcomputerkaart bestaat.

8.9. Schrijf nieuw ActivityRecord

De functie moet gevoed worden met de volgende argumenten met betrekking tot het toe te voegen ActivityRecord:

Voeg nu het nieuwe ActivityRecord toe in het in het huidige SessionRecord:

8.10. Schrijf nieuw SessionRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.11. Schrijf nieuw DailyRecord

Deze functie wordt gebruikt om een nieuw leeg DailyRecord toe te voegen. Dit wordt gedaan voor de eerste registratie van een dag. Dit nieuwe DailyRecord bevat nog geen SessionRecords.

Hiervoor moeten de volgende stappen doorlopen worden:

8.12. Selecteer laatste (nieuwste) DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.13. Selecteer oudste (eerste) DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.14. Selecteer vorige DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.15. Selecteer volgende DailyRecord

Hiervoor moeten de volgende stappen doorlopen worden:

8.16. Lees huidige / geselecteerde DailyRecord

8.18. Controleren op opgeslagen boordcomputercertificaat

In deze functie wordt gecontroleerd of het certificaat behorende bij het systeemkaartnummer al opgeslagen is in EF.BCT_Certificates.

8.19. Volgorde bijwerken van opgeslagen boordcomputercertificaten

Indien het certificaat behorende bij het systeemkaartnummer aanwezig is in EF.BCT_Certificates, wordt deze als meest recente in de Rank gezet.

8.20. Geef opgeslagen boordcomputercertificaat

Indien het certificaat behorende bij het systeemkaartnummer aanwezig is in EF.BCT_Certificates, wordt dit als resultaat terug gegeven.

8.23. Sla DownloadLog op

9. Commando’s

De communicatie met de boordcomputerkaarten gebeurt door middel van commando-antwoord paren. Het commando wordt naar de boordcomputerkaart toegestuurd en daarop komt een antwoord terug.

Dit hoofdstuk geeft enkele tips voor het gebruik van de commando’s voor het selecteren, uitlezen en beschrijven van transparante elementaire files (transparent EF’s). Voor de exacte opbouw van de commando-antwoord paren wordt echter verwezen naar Referentie [7].

9.1. Selecteren van EF’s

Voordat een EF kan worden uitgelezen of beschreven, dient deze geselecteerd te worden. Voordat een EF geselecteerd kan worden, dient eerst de Dedicated File (DF) waar deze EF onderdeel van uitmaakt te worden geselecteerd. Conform Referenties [8] t/m [12] bevat elke BCT kaart de volgende twee DF’s:

De verwachte respons op elk van de bovenstaande commando’s is SW1-SW2 = ’90 00’H.

9.2. Uitlezen van een nog niet geselecteerde EF vanaf een offset < 256

Als voorbeeld van efficiënt coderen volgt hier de kleinste commandoreeks waarmee de 4e t/m 7e byte (willekeurig voorbeeld) van EF.BCT_Certificates kunnen worden uitgelezen:

9.3. Uitlezen van de huidige EF vanaf een offset kleiner 32768

9.4. In de huidige DF Uitlezen van een EF vanaf een offset groter dan 32767

9.5. Opvragen van de FCP’s o.a. voor de grootte van EF.Driver_Activity_Data

Omdat EF.Driver_Activity_Data per chauffeurskaart een eigen grootte heeft, is het noodzakelijk om minimaal één keer per kaartsessie te achterhalen wat die grootte exact is. Hiervoor biedt de chip (conform referentie [7]) en diens personalisatie de mogelijkheid om van EF’s de file control parameters (FCP) op te vragen. Er van uitgaande dat de DF.CAI reeds is geselecteerd, is het betreffende commando voor de EF.Driver_Activity_Data als volgt:

De chips zijn zodanig geprogrammeerd dat dit resulteert in de volgende respons (voorbeeld):

De betekenis van deze respons is hieronder uitgewerkt:

10. Referenties

De onderstaande referenties worden in dit document gebruikt:

De onderstaande begrippen en afkortingen worden in dit document gebruikt:

Hieronder volgt een aantal scenario’s die het wegschrijven van gegevens op de chauffeurskaart tijdens een kaartsessie toelichten.

A.5. Scenario 5: Sessie afgesloten, pauze vervangen door andere werkzaamheden

A.7. Scenario 7: Sessie niet afgesloten, andere activiteiten ertussendoor

A.9. Scenario 9: Sessie niet afgesloten, kaart tussendoor in ander voertuig

B.1. Het opzetten van Secure Messaging

Na het opzetten van de secure messaging verbinding, moeten alle volgende commando's met secure messaging uitgevoerd worden. Dit staat beschreven in 4.1 t/m 4.5.

Hierbij worden de SK_ENC, SK_MAC en SSC gebruikt die na het opzetten van de secure messaging verbinding te berekenen zijn (zie hierboven).

B.3. Het zetten van een handtekening met een boordcomputerkaart

B.3.2. SignDataForAuthenticity

Voor het zetten van een elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT van een boordcomputerkaart, zoals beschreven staat in 8.7, worden de volgende stappen uitgevoerd:

B.4. Het zetten van een handtekening met een systeemkaart

NB. Deze functie moet uitgevoerd worden onder secure messaging, zoals beschreven is in B.2. Voor het overzicht worden onderstaande commando’s en responses echter zonder deze secure messaging weergegeven.

NB. Deze functie moet uitgevoerd worden onder secure messaging, zoals beschreven is in B.2. Voor het overzicht worden onderstaande commando’s en responses echter zonder deze secure messaging weergegeven.

Deze regeling zal met de toelichting in de Staatscourant worden geplaatst.

Artikel 1a

Deze regeling berust op artikel 21, tweede lid, onderdeel b, en 23, eerste en tweede lid, van de Wegenverkeerswet 1994.

§ 2. Specificaties van de boordcomputer

§ 2.1. De onderdelen van de boordcomputer

§ 2.2. Registratie door de boordcomputer

§ 2.3. Ritbewijs

§ 2.4. De werking van de boordcomputer

§ 2.5. Activering, deactivering en onderzoek van de boordcomputer

§ 2.6. Gebeurtenissen, fouten en storingen

§ 2.7. Eisen aan het functioneren van de boordcomputer

§ 2.8. Beveiligingseisen

§ 3. Nationale typegoedkeuring boordcomputer

§ 4. Overgangs- en slotbepalingen

Bijlage 1. bij de Regeling boordcomputer taxi

Beveiligingsprofiel Boordcomputer Taxi (PP-BCT)

Artikel 1. Introductie

Dit beveiligingsprofiel voor de boordcomputer is opgesteld voor de Inspectie Leefomgeving en Transport van het Ministerie van Infrastructuur en Milieu.

Dit document is het ‘Beveiligingsprofiel Boordcomputer Taxi’ (PP-BCT) Versie 1.8, 6 februari 2015.

Artikel 2.2. Claim voor voldoen aan de Common Criteria

Dit beveiligingsprofiel:

Artikel 2.5. Referentienormen

Artikel 3.1. Beschrijving van de TOE

Artikel 3.2. Levenscyclus van de TOE

Artikel 3.3. Entiteiten

Artikel 3.3.1. Subjecten – middelen

Artikel 3.3.2. Subjecten – gebruikers

Artikel 3.3.3. Objecten

Artikel 3.4. Begrenzingen van de TOE

Daarnaast is het toegestaan om extra hardware of software binnen de fysieke behuizing van de TOE op te nemen, zonder dat deze hardware of software meteen onderdeel worden van de TOE. Het is echter niet toegestaan om tijdens de evaluatie van de TOE aan te nemen dat deze extra hardware of software vertrouwd of goedaardig is: de evaluatie van de TOE dient ondubbelzinnig aan te tonen dat de TOE nog steeds voldoet aan dit Beschermingsprofiel als deze opgenomen hardware of software niet vertrouwd of goedaardig is.

Artikel 4.1. Beveiligingsbeleid

Artikel 5.1. Beveiligingsdoelen voor de TOE

Artikel 5.2. Beveiligingsdoelen voor de omgeving

Artikel 6. Functionele beveiligingseisen

Artikel 6.1. Beveiligingsrollen

Artikel 6.2. Identificatie en Authenticatie

Artikel 6.3. BCT-toegangsbeleid

FDP_ITC.1.3 De TSF dwingt de volgende regels af wanneer gegevens worden ingelezen door de TSF:

Artikel 6.5. Beveiligingsaudit

Artikel 6.6. Bescherming van de BCT

Artikel 7. Garantieniveau

Artikel 8.1. Beveiligingsdoelstellingen

Artikel 8.1.1. Beveiligingsbeleid

Deze wordt direct ondervangen door OE.DEACTIVERING (voor deactivering en verwijderen gegevens), OT.UITVOEREN_GEGEVENS (voor wat betreft het uitvoeren van gegevens) en OT.AUTHENTICATIE_BOORDCOMPUTERKAART.

Artikel 8.1.2. Aannames

Artikel 8.2. Beveiligingsdoelstellingen voor de TOE

Artikel 8.3. Afhankelijkheden

Bijlage 2. bij de Regeling specificaties en typegoedkeuring boordcomputer taxi

Gegevensoverbrengingsinterface Boordcomputer Taxi

Status DEFINITIEF

In deze bijlage wordt verstaan onder:

Artikel 2. Algemeen

Aan dit document wordt gerefereerd als ‘Gegevensoverbrengingsinterface Boordcomputer Taxi Versie 2.2’. Deze versie dateert van 8 december 2014’.

In dit artikel worden de gemeenschappelijke kenmerken beschreven die gelden voor de gegevensleveringen ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ‘Onderzoek’ en ‘Chauffeurskaartdata’.

Artikel 2.2. Hardware koppeling

De snelheidseis, als beschreven in artikel 2.3, is leidend bij de keuze van USB 1.1 of hoger. Als de snelheidseis van alle gegevensleveringen (‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’ ‘Onderzoek’ en ‘Chauffeurskaartdata’) beschreven in deze bijlage gehaald kan worden met USB 1.1 (12 Mbit/s) dan is USB 1.1 toegestaan, zo niet dan moet USB 2.0 (480 Mbit/s) of hoger gebruikt worden.

Artikel 2.3. Snelheidseis gegevenslevering

Artikel 2.4. Bestandsformaat

Voor externe opslagmedia moet het bestandssysteem FAT32 ondersteund worden.

Artikel 2.5. Overbrengingsprotocol

Nadat alle geselecteerde gegevensleveringen succesvol zijn afgerond en de berichten met de gegevens beschikbaar zijn op de externe gegevensdrager, toont de boordcomputer een melding dat de gegevens beschikbaar zijn.

Artikel 2.6.1. Periode gegevenslevering

Overschrijven van een bericht op de externe gegevensdrager met dezelfde naam, is alleen toegestaan na een bevestiging van de gebruiker.

Artikel 2.7. Authenticatie en autorisatie

Aanvragen van de gegevensleveringen ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ‘Onderzoek’ en ‘Chauffeurskaartdata’ moet alleen mogelijk zijn voor daartoe geauthenticeerde en geautoriseerde gebruikers.

Artikel 2.8.1. Integriteit exportbericht

De keuze van het algoritme voor de Digest en de Signature is afhankelijk van het certificaat op de kaart waarmee de handtekening wordt gezet. Als dit in de toekomst anders wordt dan SHA-256 respectievelijk RSA-SHA256’ zullen de algoritmes voor Digest en Signature meeveranderen.

Artikel 2.8.2. Integriteit geregistreerde gegevens

Artikel 2.9. Foutafhandeling

Bij het opvragen van de gegevensleveringen kunnen foutsituaties optreden. Hierbij kan onderscheid gemaakt worden tussen functionele fouten, technische fouten en niet volledige gegevens.

Artikel 2.9.1. Functionele fouten

Bij onderstaande foutsituaties moet de boordcomputer de bijbehorende foutmelding tonen:

Artikel 2.9.3. Onvolledige gegevens

Artikel 3.1. Gegevens en functionele en technische berichtstructuur

Toelichting:

Artikel 3.2. Ritadministratie.xsd

Voor de definitie van bcttypes.xsd wordt verwezen naar artikel 9.

Artikel 3.3. Volgorde gegevens

De geselecteerde ritten moeten gegroepeerd per vervoerder, en daarbinnen per ondernemerskaart, in oplopende volgorde van volgnummer worden opgenomen in de ritadministratie.

Artikel 3.4. Integriteit gegevens

Bij het samenstellen van de ritadministratie moeten de gegevens van het element onveranderd worden overgenomen uit de ritadministratie op de boordcomputer. Het berekenen van de ‘Elektronische handtekening boordcomputer’ van het element van een wordt gedaan bij het beëindigen van de rit. De vastgelegde ‘Elektronische handtekening boordcomputer’ wordt per onveranderd overgenomen in het onderliggende element.

Artikel 3.5.1. Naamgeving

Artikel 4.3. Volgorde gegevens

Artikel 4.5.1. Naamgeving

Artikel 4.5.2. Berichtgrootte

Toelichting:

Artikel 5.2. Coordinaten.xsd

Artikel 5.3. Volgorde gegevens

De geselecteerde coördinaten moeten gegroepeerd per kenteken, en daarbinnen per vervoerder, en daarbinnen per ondernemerskaart, in oplopende volgorde van volgnummer, in het bericht worden opgenomen.

Artikel 5.4. Integriteit gegevens

Het bericht ‘Coördinaten’ wordt ondertekend met een elektronische handtekening van de boordcomputer. De afzonderlijke coördinaten worden niet ondertekend.

Artikel 5.5.1. Naamgeving

Een bericht ‘Coördinaten’ bevat maximum 1.440 coördinaten per dag, wanneer de auto continu rijdt en 1 coördinaat per minuut wordt vastgelegd. Voor de periode van een dag geeft dat een bericht van maximaal 236 Kbyte. Per jaar is het bericht ‘Coördinaten’ maximaal 84 Mbyte groot.

Artikel 6.1. Gegevens en functionele en technische berichtstructuur

Toelichting:

Artikel 6.2. Gebeurtenis.xsd

De onderstaande Gebeurtenis.xsd wordt gebruikt.

Artikel 6.3. Volgorde gegevens

Artikel 6.4. Integriteit gegevens

Artikel 6.5. Codetabel

Een fabrikant is vrij om voor eigen doeleinden codes aan de bovenstaande reeks toe te voegen. Elke code moet bestaan uit een hoofdletter gevolgd door drie cijfers.

Artikel 6.6.2. Berichtgrootte

Artikel 7.1. Gegevens en functionele en technische berichtstructuur

Artikel 7.2. Onderzoek.xsd

De onderstaande Onderzoek.xsd dient te worden gebruikt.

Artikel 7.3. Volgorde gegevens

Als eerste wordt het geselecteerde activeringsonderzoek in het bericht opgenomen. Daarna worden de geselecteerde periodieke onderzoeken in oplopende volgorde van volgnummer in het bericht opgenomen.

Artikel 7.4. Integriteit gegevens

Artikel 7.5.2. Berichtgrootte

Artikel 8.1. Gegevens en functionele en technische berichtstructuur

De onderstaande Chauffeurskaartdata.xsd wordt gebruikt.

Artikel 8.3. Volgorde gegevens

Bij het samenstellen van bericht ‘Chauffeurskaartdata’ moeten de gegevens van het element zoals hierboven gespecificeerd worden overgenomen uit de chauffeurskaart. Het berekenen van de ‘Elektronische handtekening chauffeur’ moet gebeuren zodra deze data van de chauffeurskaart is overgenomen. De vastgelegde ‘Elektronische handtekening chauffeur’ moet onveranderd worden overgenomen in het onderliggende element.

Artikel 8.5.2. Berichtgrootte

Het bericht ‘Chauffeurskaartdata’ is maximaal 200 Kbyte groot.

Artikel 9.1. Toelichting bij specificaties van gegevensleveringen

De toelichting bij elk van de functioneel/technische specificaties van een gegevenslevering uit artikelen 3 t/m 8 bestaat uit de navolgende legenda:

Artikel 9.2. Algemene XML schema definities in bcttypes.xsd

Bijlage 3. bij de Regeling specificaties en typegoedkeuring boordcomputer taxi

Artikel 1. Definities

Artikel 2.1. Interface identificatie en diagrammen

Artikel 2.4.3.1. Bericht VR_STATUS

Toelichting: dit is ten behoeve van de functionaliteit van het automatisch uitschakelen van de taxameter. De taxameter dient uit te vallen indien er 15 seconden geen statusbericht is ontvangen met ‘Status interface’ = ‘interface operationeel’.

Artikel 2.4.3.2. Bericht A_STATUS

Totale berichtgrootte: 15 bytes

Artikel 2.4.3.3. Bericht VR_TARIEFINFO

Dit bericht is voor het opvragen van tariefinformatie. Totale berichtgrootte: 7 bytes

Artikel 2.4.3.4. Bericht A_TARIEFINFO

Een korting wordt als negatief TOESLAG_BEDR weergegeven.

Artikel 2.4.3.7. Bericht VR_TOTALEN

Dit bericht is voor het opvragen van de totalisatordata. Totale berichtgrootte: 7 bytes

Totale berichtgrootte: 33 bytes

Artikel 2.4.3.9. Bericht VR_TAXAMETER_INFO

Dit bericht is voor het opvragen van de constante van de afstandssignaalgenerator, de beveiligingsdatum en de identificatie van de taxi. Totale berichtgrootte: 7 bytes

Artikel 2.4.3.10. Bericht A_TAXAMETER_INFO

Totale berichtgrootte: variabel, minimaal 22 bytes, maximaal 278 bytes

Artikel 2.4.3.11. Bericht F_BERICHT_ONBEKEND

Het bericht F_BERICHT_ONBEKEND is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onbekend berichttype. Totale berichtgrootte: 7 bytes.

Artikel 2.4.3.12. Bericht F_CRC_INCORRECT

Het bericht F_CRC_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onjuiste CRC. Totale berichtgrootte: 7 bytes.

Artikel 2.4.3.13. Bericht F_LENGTE_INCORRECT

Het bericht F_LENGTE_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onjuiste minimale of maximale berichtlengte. Totale berichtgrootte: 7 bytes.

Artikel 2.4.3.14. Bericht F_GEEN_STX

Het bericht F_GEEN_STX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal een ETX teken zonder het tussentijds ontvangen van een STX teken. Totale berichtgrootte: 7 bytes

Artikel 2.4.3.15. Bericht F_GEEN_ETX

Het bericht F_GEEN_ETX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal een STX teken zonder het tussentijds ontvangen van een ETX teken. Totale berichtgrootte: 7 bytes

Artikel 2.4.3.16. Bericht F_NIET_STANDAARD

Totale berichtgrootte: variabel, minimaal 8 bytes, maximaal 264 bytes

Artikel 2.4.3.17. Bericht F_VELD_ONGELDIG

Het bericht F_VELD_ONGELDIG is een foutmelding die gestuurd wordt indien er een ongeldig veld gedetecteerd is in het vraagbericht. Bijvoorbeeld voor een ongeldige waarde in het veld ‘Status interface’ van het bericht VR_STATUS. Totale berichtgrootte: 7 bytes

Artikel 2.5. Prioriteit en afhankelijkheid van eisen

Prioriteit 1 is de hoogste, 3 de laagste.

Bijlage 4

OPENBAAR

Technische specificaties gebruik boordcomputer- en systeemkaarten Boordcomputer Taxi

Status DEFINITIEF

1. Inleiding

Binnen BCT zijn dus vijf verschillende chipkaarten te onderscheiden:

1.1. Bereik van dit document

Dit document bevat technische specificaties en richtlijnen voor het gebruik van de hierboven genoemde chipkaarten. Dit document is primair bedoeld voor fabrikanten van boordcomputers. De hoofdstukken 2 en 5 t/m 8, alsmede bijlage A, zijn echter ook interessant voor ontwikkelaars van toepassingen bedoeld om chauffeurskaarten uit te lezen.

2.1. ISO/IEC 7816-15 structuur

De boordcomputer- en systeemkaarten zijn uitgevoerd als ISO/IEC 7816-15 kaarten. De algemene opbouw van ISO/IEC 7816-15 kaarten staat beschreven in Referentie [3]. De opbouw per kaart wordt in de specificatie documenten van de afzonderlijke kaarten beschreven (Referenties [8] t/m [12]).

2.2. Certificaten

De op de boordcomputer- en systeemkaarten gebruikte certificaten zijn X.509 certificaten uitgegeven conform het vigerende Programma van Eisen (PvE) van PKIoverheid. Er worden verschillende X.509 certificaten gebruikt, zoals voor authenticatie, handtekening en vertrouwelijkheid. Zie verder Referentie [13] in hoofdstuk 10.

2.3. Asymmetrische sleutels

De asymmetrische sleutels die in de kaarten gebruikt worden zijn RSA sleutels met een lengte van 2048 bits.

2.4. PIN/PUK

De PIN wordt algemeen gebruikt voor de authenticatie van de kaarthouder en bij persoonsgebonden boordcomputerkaarten voor het zetten van elektronische handtekeningen. De PUK kan gebruikt worden om de PIN te deblokkeren.

2.5. Gegevens

Op alle kaarten zijn gegevens zoals voorgeschreven in ISO/IEC 7816-15 opgeslagen. Er zijn echter twee typen kaarten waarop ook andere gegevens toegevoegd kunnen worden: de systeemkaart en de chauffeurskaart.

2.5.1. Systeemkaart

Op de systeemkaart kan eenmalig het serienummer van de boordcomputer opgeslagen worden. Dit staat beschreven in hoofdstuk 3. Verder worden er (tijdens de gebruiksfase) op de systeemkaart geen gegevens opgeslagen.

2.5.2. Chauffeurskaart

Op de chauffeurskaart worden de arbeids-, rij- en rusttijden van de chauffeur, alsmede de systeemkaartcertificaten van de laatst gebruikte boordcomputers opgeslagen. Dit wordt beschreven in hoofdstuk 5.

2.5.3. Relatie gegevens boordcomputer – chauffeurskaart

Vanwege beperkingen voor wat betreft het formaat en de mogelijkheden voor controle en uitlezen van de gegevens, is voor de chauffeurskaart wel exact vastgelegd hoe de gegevens opgeslagen moeten worden. Dit staat beschreven in hoofdstuk 5.

2.6. Toegangscondities

Algemeen geldt voor de toegangscondities:

3. Koppelen Systeemkaart

De systeemkaart moet initieel aan de boordcomputer gekoppeld worden om de boordcomputer te laten functioneren. Onderstaande paragrafen geven een nadere specificatie van boordcomputerproductie, respectievelijk systeemkaartvervanging.

3.1. Communicatiebeveiliging tussen boordcomputerunits en systeemkaarten

Onderstaande subparagrafen geven een nadere specificatie van boordcomputerproductie, respectievelijk systeemkaartvervanging.

3.1.1. Boordcomputerproductie

Ondersteuning van de laatstgenoemde mogelijkheid is niet voorgeschreven, maar kan als extra veiligheidsmaatregel periodiek worden gedaan.

3.1.2. Systeemkaartvervanging

NB. Stap 1 kan, naar keuze van de fabrikant, geïnitieerd worden door een (beschermde) menugestuurde optie of automatisch starten wanneer het systeemkaartslot geopend wordt (maar voorafgaand aan het verbreken van de elektrische verbinding tussen boordcomputereenheid en systeemkaart). Hierbij geniet de laatste methode de voorkeur omdat dit een effectieve bescherming tegen misbruik van de systeemkaart biedt.

4. Beveiligde gegevensoverdracht

De bytes van de statusinformatie van het antwoord moeten altijd door een MAC worden beveiligd, met uitzondering van de gevallen beschreven in paragraaf 4.2.

4.1. Structuur van commando’s en antwoorden bij beveiligde gegevensoverdracht