Regeling specificaties en typegoedkeuring boordcomputer taxi:Bijlage 4 Technische specificaties gebruik boordcomputer- en systeemkaarten Boordcomputer Taxi

Regeling specificaties en typegoedkeuring boordcomputer taxi

Bijlage 4 Technische specificaties gebruik boordcomputer- en systeemkaarten Boordcomputer Taxi

Geldend

Documentgegevens:

Geldend vanaf 01-02-2020

Bronpublicatie:: 30-01-2020, Stcrt. 2020, 2965 (uitgifte: 31-01-2020, regelingnummer: IENW/BSK-2020/5375)
Inwerkingtreding: 01-02-2020
Bronpublicatie inwerkingtreding:: 30-01-2020, Stcrt. 2020, 2965 (uitgifte: 31-01-2020, regelingnummer: IENW/BSK-2020/5375)
Vakgebied(en): Verkeersrecht / Voertuigeisen

Openbaar

Versie 1.7

Datum 25 april 2012

Status DEFINITIEF

Colofon

Projectnaam	Boordcomputer Taxi
Documenttitel	Technische specificaties gebruik boordcomputer- en systeemkaarten
Classificatie	OPENBAAR
Versienummer	1.7
Status	DEFINITIEF
Datum	25 april 2012

Contactpersoon	Inspectie Leefomgeving en Transport
	Project Boordcomputer Taxi
	Nieuwe Uitleg 1 \| 2514 BP Den Haag
	Postbus 90653 \| 2509 LR Den Haag

Bijlage(n)	Geen

Auteur(s)	Peter G.J. Breur
	Piet E. Pieters

Wijzigingshistorie

Versie	Datum	Omschrijving
1.2	4 mei 2010	Eerste versie voor publicatie
1.3c2	14 okt 2010	Wijzigingen naar aanleiding van door Morpho en Collis uitgevoerde tests met gepersonaliseerde exemplaren van de geselecteerde contactchip:
	1)	Kaart blijkt geen ondersteuning te bieden voor het selecteren van de DF.CIA op basis van een File Identifier (voorheen 5015h). Selectie van de DF.CIA kan uitsluitend op basis van de Application Identifier plaatsvinden. De APDU’s van de desbetreffende SELECT FILE commando’s zijn aangepast in § 8.9 t/m § 8.21.
	2)	De APDU’s voor het lezen en schrijven van EF’s waren door offsets in P1P2 te plaatsen, impliciet gebaseerd op de EVEN variant van READ BINARY, respectievelijk UPDATE BINARY. Deze variant biedt echter geen ondersteuning voor offsets groter dan 32767. Vooral voor het lezen en schrijven van EF.Driver_Activity_Data is dit relevant. In § 8.9 t/m § 8.21 zijn de desbetreffende ‘P1P2’ vermeldingen dan ook veranderd in het meer generieke woord ’offset’. Met aanvullende teksten in hoofdstuk 9 wordt de lezer op het bestaan van een ODD variant, die hogere offsets ondersteunt, gewezen.
	3)	De opslagcapaciteit van de kaart blijkt kleiner dan verwacht. Daarom is er gekozen voor het kunnen opslaan van maximaal 3 (in plaats van 4) Systeemkaartcertificaten in EF.BCT_Certificates. Wijzigingen in § 6.1 en § 8.18 t/m § 8.21.
	4)	De kaart blijkt onvoldoende capaciteit te hebben voor het opslaan van een EF.Driver_Activity_Data van 64KB (65536 bytes). Tijdens personalisatie zal echter per kaart een zo groot mogelijke ruimte voor deze EF worden gereserveerd. Per kaart is die grootte dus verschillend. Hoe hiermee om te gaan, is nu vermeld in § 7.1 en § 9.5. Daarnaast is de vermelding van 64K in hoofdstuk 5, alinea 1 aangepast.
	5)	In hoofdstuk 10 Referenties [8] t/m [12] bijgewerkt.
1.3c3	15 okt 2010	Een boordcomputer dient een bestuurder (tijdig) te waarschuwen dat de momenteel op de chauffeurskaart opgeslagen arbeids-, rij- en rusttijden moeten worden geëxporteerd. Voorheen bood de chauffeurskaart de boordcomputer hiertoe geen informatie. Dergelijke informatie is nu toegevoegd:
	1)	Aan hoofdstuk 6 is bovenstaande rationale toegevoegd.
	2)	Aan EF.BCT_Certificates in § 6.1 is een gegevensstructuur toegevoegd die vermeldt wanneer en naar welke boordcomputer welke dailyrecords zijn geëxporteerd.
	3)	Aan § 7.3 ‘Afsluiten van een kaartsessie’ zijn extra processtappen toegevoegd.
	4)	Aan hoofdstuk 8 zijn nieuwe paragrafen (§ 8.22 t/m § 8.23) met de extra benodigde functies toegevoegd
1.3c4	28 okt 2010	Meer wijzigingen naar aanleiding van door Morpho en Collis uitgevoerde tests:
	1)	De Kaartstructuur documenten bevatten kleine fouten en zijn bijgewerkt van versie 1.5 naar 1.6. In hoofdstuk 10 zijn de betreffende Referenties ([8] t/m [12]) geactualiseerd.
	2)	In § 8.5, 8.6 en 8.7 werd gesproken over een ‘PSO Hash commando met ‘6C’h in Lc om SHA256 aan te duiden’. Omdat dat niet correct is, zijn er tekstverbeteringen in deze paragrafen aangebracht. Ook § 8.8 is met deze aanvullingen in lijn gebracht.
1.3c5	5 nov 2010	Wijzigingen naar aanleiding van interne review IVW:
	1)	Eerste alinea van de Inleiding geactualiseerd.
	2)	In § 2.5 een grammaticale verbetering aangebracht.
	3)	In § 5.1 de noodzaak van een correct gevuld DriverCardNumber verklaard.
	4)	In § 5.1.2 expliciet vermeld dat het tijdformaat van een 24-uurs klok uitgaat.
	5)	In § 5.2 de referentie naar hoofdstuk 7 hersteld.
	6)	In § 5.2.7 een grammaticale verbetering aangebracht.
	7)	In § 6.1 de zin onder Figuur 10 verbeterd.
	8)	In § 7.1, puntje 1 een referentie opgenomen.
	9)	In § 7.1, punt 4, 2^e aandachtsstreepje grammaticale verbeteringen aangebracht.
	10)	In § 7.3 de eerste twee alinea’s duidelijker verwoord.
	11)	In hoofdstuk 10 de omschrijving van referentie [14] gecorrigeerd.
	12)	In scenario A.6 ontbrekende teksten toegevoegd.
1.3c6	11 nov 2010	Wijzigingen naar aanleiding van document review door Collis:
	1)	In § 8.7, puntje 4 de tekst ‘van minimaal 1 en maximaal 64 bytes’ ingevoegd.
	2)	In § 9.4 het voorbeeld aangepast aan hetgeen in tabel 29 in referentie [7] staat: Bij een Read Binary Odd kan voor P1P2 alleen een SFI meegegeven worden en geen file id.
1.4	6 dec 2010	Doorvoeren naamswijziging ministerie
1.5	29 jun 2011	Wijzigingen met betrekking tot het refereren aan private sleutelobjecten:
	1)	In § 8.5 twee keer de tekst ‘06’ veranderd in ‘86’ en voetnoot aangepast
	2)	In § 8.6 twee keer de tekst ‘05’ veranderd in ‘85’ en voetnoot aangepast
	3)	In § 8.7 twee keer de tekst ‘05’ veranderd in ‘85’ en voetnoot aangepast
	4)	In § 8.8 twee keer de tekst ‘05’ veranderd in ‘85’ en voetnoot aangepast
1.6	12 dec 2011	Aanpassing §4.6 Authenticatiescenario Systeemkaart-Boordcomputer
1.7	25 apr 2012	Wijzigingen naar aanleiding van uitgevoerde tests:
	1)	In § 8.5 stap toegevoegd voor selectie hash template en algoritme
	2)	In § 8.6 stap toegevoegd voor selectie hash template en algoritme
	3)	In § 8.7 stap toegevoegd voor selectie hash template en algoritme
	4)	Bijlage B toegevoegd met uitgewerkte voorbeelden van een aantal functies
2.0	jan 2020	Wijzigingen naar aanleiding van transitie naar een nieuwe BCT-chip:
	1)	In § 8.5 een tweede variant voor het zetten van een handtekening toegevoegd
	2)	In § 8.6 een tweede variant voor het zetten van een handtekening toegevoegd
	3)	In § 8.7 een tweede variant voor het zetten van een handtekening toegevoegd

Inhoud

1	Inleiding
1.1	Bereik van dit document
2	Opbouw boordcomputer- en systeemkaarten
2.1	ISO/IEC 7816-15 structuur
2.2	Certificaten
2.3	Asymmetrische sleutels
2.4	PIN/PUK
2.5	Gegevens
	2.5.1	Systeemkaart
	2.5.2	Chauffeurskaart
	2.5.3	Relatie gegevens boordcomputer – chauffeurskaart
2.6	Toegangscondities
3	Koppelen Systeemkaart
3.1	Communicatiebeveiliging tussen boordcomputerunits en systeemkaarten
	3.1.1	Boordcomputerproductie
	3.1.2	Systeemkaartvervanging
4	Beveiligde gegevensoverdracht
4.1	Structuur van commando’s en antwoorden bij beveiligde gegevensoverdracht
4.2	Fouten bij de beveiligde gegevensoverdracht
4.3	Sessiesleutels
4.4	Zendsequentieteller (SSC)
4.5	Algoritmes
4.6	Authenticatiescenario Systeemkaart-Boordcomputer
5	Gegevens op chauffeurskaart (EF.Driver_Activity_Data)
5.1	Opbouw van EF.Driver_Activity_Data
	5.1.1	DailyRecord
	5.1.2	SessionRecord
	5.1.3	ActivityRecord
	5.1.4	Overzicht
5.2	Schrijven naar EF.Driver_Activity_Data
	5.2.1	Toevoegen van de eerste activiteit binnen een SessionRecord
	5.2.2	Toevoegen ‘Login’ activiteit
	5.2.3	Toevoegen ‘Start pauze’ activiteit
	5.2.4	Toevoegen ‘Start werk activiteit
	5.2.5	Toevoegen ‘Afsluiting’ activiteit
	5.2.6	Toevoegen ‘Nieuwe eindtijd’ (=handmatige Afsluiting) activiteit
	5.2.7	Toevoegen ‘Dagovergang (handmatig/automatisch)’ activiteit
5.3	Algemene opmerkingen bij lezen en schrijven naar EF.Driver_Activity_Data
5.4	Digitale handtekening
6	Gegevens op chauffeurskaart (EF.BCT_Certificates)
6.1	Opbouw van EF.BCT_Certificates
7	Kaartsessie
7.1	Begin van een kaartsessie
7.2	Tijdens een kaartsessie
7.3	Afsluiten van een kaartsessie
7.4	Niet afgesloten kaartsessie
7.5	Dagoverschrijdende kaartsessie
8	Functies
8.1	PIN wijzigen
8.2	SM keyset wijzigen
8.3	PIN deblokkeren
8.4	PIN deblokkeren en wijzigen
8.5	Elektronische handtekening zetten met een chauffeurs- of inspectiekaart
8.6	Elektronische handtekening zetten met een systeemkaart
8.7	Authenticiteit handtekening zetten met een boordcomputerkaart
8.8	Authenticeren boordcomputerkaart aan boordcomputer
8.9	Schrijf nieuw ActivityRecord
8.10	Schrijf nieuw SessionRecord
8.11	Schrijf nieuw DailyRecord
8.12	Selecteer laatste (nieuwste) DailyRecord
8.13	Selecteer oudste (eerste) DailyRecord
8.14	Selecteer vorige DailyRecord
8.15	Selecteer volgende DailyRecord
8.16	Lees huidige / geselecteerde DailyRecord
8.17	Controleer EF.Driver_Activity_Data structuur
8.18	Controleren op opgeslagen boordcomputercertificaat
8.19	Volgorde bijwerken van opgeslagen boordcomputercertificaten
8.20	Geef opgeslagen boordcomputercertificaat
8.21	Sla boordcomputercertificaat op
8.22	Geef meest recente DownloadLog
8.23	Sla DownloadLog op
9	Commando’s
9.1	Selecteren van EF’s
9.2	Uitlezen van een nog niet geselecteerde EF vanaf een offset < 256
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
10	Referenties
11	Begrippen en afkortingen
Bijlage A		Scenario’s kaartsessies
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
A.5	Scenario 5: Sessie afgesloten, pauze vervangen door andere werkzaamheden
A.6	Scenario 6: Sessie niet afgesloten, vervolg zelfde werkzaamheden
A.7	Scenario 7: Sessie niet afgesloten, andere activiteiten ertussendoor
A.8	Scenario 8: Sessie niet afgesloten, later automatisch beëindigd
A.9	Scenario 9: Sessie niet afgesloten, kaart tussendoor in ander voertuig
Bijlage B		Referentie data
B.1	Het opzetten van Secure Messaging
B.2	Het sturen van commando’s met Secure Messaging
B.3	Het zetten van een handtekening met een boordcomputerkaart
B.3.1	SignDataLegally
B.3.2	SignDataForAuthenticity
B.4	Het zetten van een handtekening met een systeemkaart

1. Inleiding

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.

Binnen BCT zijn dus vijf verschillende chipkaarten te onderscheiden:

•: Een apparaatgebonden systeemkaart behorend bij een boordcomputer;
•: Een persoonsgebonden chauffeurskaart behorend bij een bestuurder;
•: Een organisatiegebonden ondernemerskaart behorend bij een vervoerder;
•: Een organisatiegebonden keuringskaart behorend bij een werkplaats;
•: Een persoonsgebonden inspectiekaart behorend bij een toezichthouder.

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.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

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.

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

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 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

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.

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

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

Algemeen geldt voor de toegangscondities:

•: Lezen PIN, PUK en RSA sleutels: niet toegestaan.
•: Lezen gegevens: geen beperking.
•: Schrijven van de RSA sleutels: niet toegestaan.
•: Gebruik van de RSA sleutels voor authenticiteit en elektronische handtekeningen: alleen mogelijk na een succesvolle verificatie van de PIN. Bij systeemkaarten wordt Secure Messaging in plaats van een PIN gebruikt.
•: Gebruik van de PIN (alleen op boordcomputerkaarten): geen beperkingen.
•: Deblokkeren van de PIN (alleen op boordcomputerkaarten): alleen mogelijk na een succesvolle verificatie van de PUK.
•: Wijzigen van de PIN (alleen op boordcomputerkaarten): alleen mogelijk na een succesvolle verificatie van de (huidige) PIN of, als aanvulling op deblokkeren, na succesvolle verificatie van de PUK.
•: Gebruik van de PUK (alleen op boordcomputerkaarten): geen beperkingen.
•: Schrijven: bij systeemkaarten alleen mogelijk in Secure Messaging en bij chauffeurskaarten alleen mogelijk na een succesvolle verificatie van de PIN.

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.

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:

1.: Niet-gekoppelde boordcomputerunit – niet-gekoppelde eerste systeemkaart;
2.: Boordcomputerunit gekoppeld aan eerste systeemkaart (= boordcomputer);
3.: Boordcomputerunit – ontkoppelde/onklaar gemaakte systeemkaart;
4.: Boordcomputer – niet-gekoppelde vervangende systeemkaart;
5.: Boordcomputerunit gekoppeld aan vervangende systeemkaart (= boordcomputer);

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’.

Onderstaande subparagrafen geven een nadere specificatie van boordcomputerproductie, respectievelijk 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.

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
Security / Data Object	Access Condition				Geproduceerd	Gekoppeld
Security / Data Object	Read	Write	Use	Reset	Geproduceerd	Gekoppeld
STK1.RSA.Private	never	never	SM	n.a.	rsakey1	rsakey1
STK1.DO.NextKey	SM	SM	n.a.	n.a.	transportkey2	transportkey2
STK1.DO.BC.Serial	Always	SM	n.a.	n.a.	Leeg	Serienr. BCT
STK1.SMkeyset	never	SM	always	n.a.	transportkey1	uniquekey1
BCT.Secret	BCT custom access conditions				transportkey1	uniquekey1

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:

•: Een per kaart unieke en nergens onthouden waarde in het RSA private key object;
•: Een per typegoedkeuringsnummer unieke en bij de Personalisator en fabrikant bekende, bewaarde en geheimgehouden waarde ‘transportkey1’ in het object SMkeyset;
•: Een per kaart unieke en bij de Personalisator bewaarde waarde ‘transportkey2’ in het dataobject NextKey;
•: Een lege string in het dataobject BC.Serial.

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

•: Het gebruik van de RSA private key
(nodig voor het zetten van elektronische handtekeningen);
•: Het uitlezen van het object NextKey
(nodig voor het koppelen aan een vervangende systeemkaart);
•: Het beschrijven van het object BC.Serial
(nodig als onderdeel van het koppelproces).

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:

1.: Lees de waarde ‘transportkey1’ uit de variabele Secret;
2.: Genereer een nieuwe unieke (random) waarde ‘uniquekey1’;
3.: Gebruik ‘transportkey1’ als een 3DES sleutelset om via een MUTUAL AUTHENTICATE een veilig kanaal (MAC_ENC Secure Messaging kanaal) op te zetten met de systeemkaart (zie § 4.6);
4.: Gebruik een PUT DATA om de SMkeyset te wijzigen in ‘uniquekey1’, gebruikmakend van het SM kanaal;
5.: Gebruik het SM kanaal om het dataobject BC.SERIAL te beschrijven met het serienummer van de boordcomputer.
Het dataobject BC.SERIAL is 64 bytes groot. In de eerste byte dient de lengte van het serienummer in bytes te worden opgeslagen als een (unsigned) byte. Het serienummer, weergegeven als een (8-bits) ASCII string, wordt vanaf de tweede byte opgeslagen. De maximale lengte van een serienummer is hiermee 63 karakters (bytes);
6.: Overschrijf de variabele Secret met ‘uniquekey1’ en vernietig daarbij de kennis van ‘transportkey1’;
7.: Sluit de kaartsessie.

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:

•: Zetten van elektronische handtekeningen;
•: Uitlezen van NextKey voor het koppelen van een vervangende systeemkaart;
•: Opnieuw doorlopen van het koppelproces om de waarde ‘uniquekey1’ te wijzigen in een nieuwe waarde.

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

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.

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:

1.: dat elke eerste systeemkaart een dataobject NextKey bevat met daarin een unieke waarde ‘transportkey2’,
2.: dat de Personalisator die waarde voor elke systeemkaart in escrow houdt en
3.: dat de Personalisator het SMkeyset object van de desbetreffende vervangende systeemkaart vult met die onthouden waarde.

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.

Tabel 2. Toegangscondities/inhoud van objecten bij systeemkaartvervanging
Security / Data Object	Access Condition				Gekoppeld 1	Ontkoppeld 1 / Geprod. 2	Gekoppeld 2
Security / Data Object	Read	Write	Use	Reset	Gekoppeld 1	Ontkoppeld 1 / Geprod. 2	Gekoppeld 2
STK1.RSA.Private	never	never	SM	n.a.	rsakey1	rsakey1	n.a.
STK1.DO.NextKey	SM	SM	n.a.	n.a.	transportkey2	random	n.a.
STK1.DO.BC.Serial	Always	SM	n.a.	n.a.	Serienr. BCT	Leeg
STK1.SMkeyset	never	SM	always	n.a.	uniquekey1	random/blocked	n.a.
BCT.Secret	BCT custom access conditions				uniquekey1	transportkey2	uniquekey2
STK2.RSA.Private	never	never	SM	n.a.	n.a.	rsakey2	rsakey2
STK2.DO.NextKey	SM	SM	n.a.	n.a.	n.a.	transportkey3	transportkey3
STK2.DO.BC.Serial	Always	SM	n.a.	n.a.	n.a.	Leeg	Serienr. BCT
STK2.SMkeyset	never	SM	always	n.a.	n.a.	transportkey2	uniquekey2

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:

1.: Initieer de vervanging door het aanroepen van de desbetreffende functie op de boordcomputer;
2.: Lees de waarde ‘uniquekey1’ uit de variabele Secret;
3.: Gebruik (indien er nog geen MAC_ENC Secure Messaging kanaal bestaat) ‘uniquekey1’ als een 3DES sleutelset om via een MUTUAL AUTHENTICATE een veilig kanaal (MAC_ENC Secure Messaging kanaal) op te zetten met de huidige systeemkaart;
4.: Lees, gebruikmakend van het SM kanaal, de waarde ‘transportkey2’ uit het dataobject NextKey;
5.: Maak, gebruikmakend van het SM kanaal, de huidige systeemkaart onklaar;
6.: Overschrijf het NextKey data object met een random waarde;
7.: Overschrijf het SMkeyset object met een random waarde;
8.: Overschrijf het BC.Serial object met een random of een lege waarde;
9.: Overschrijf de variabele Secret met ‘transportkey2’ en vernietig daarbij de kennis die de boordcomputerunit van de huidige systeemkaart had;
10.: Sluit de kaartsessie;
11.: Vervang systeemkaart 1 fysiek voor systeemkaart 2.
12.: Hierna dezelfde 7 stappen als bij 1e koppelproces.
: 13.

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

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.

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

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.

RSTGBTAXI_stc-2015-9656_BIJL4_01

Figuur 1: Beveiligd commando

RSTGBTAXI_stc-2015-9656_BIJL4_02

Figuur 2: Beveiligd antwoord

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:

'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.

In het geval van een Secure Messaging-fout vervallen de sessiesleutels en SSC.

4.3. Sessiesleutels

Voor beveiligde gegevensoverdracht tussen de boordcomputerlogica en de systeemkaart worden twee 16 bytes lange sessiesleutels gebruikt. De methode om deze sessiesleutels SK_ENC en SK_MAC 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.

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).

De SSC wordt iedere keer voordat een MAC berekend wordt met 1 verhoogd, dus voor de eerste MAC-berekening wordt de waarde SSC + 1 gebruikt.

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 cryptografische controlesommen (MACs) wordt beschreven in Referentie [7], section 7.1.12.

De MAC is 8 bytes lang.

Iedere keer voordat er een MAC berekend wordt, wordt de zendsequentieteller (SSC) met 1 verhoogd.

4.6. Authenticatiescenario Systeemkaart-Boordcomputer

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:

1.

Er wordt gebruik gemaakt van symmetrische sleutels (zie hoofdstuk 3). De initiële sleutels worden afgeleid van ‘transportkey1’:

•: KS.KMAC bestaat uit de eerste 16 bytes van ‘transportkey1’,
•: KS.KENC bestaat uit de laatste 16 bytes van ‘transportkey1’.

2.

Na het uitlezen van EF.SN.ICC worden de laatste 8 bytes hiervan gebruikt voor SN.ICC.

3.

Bij het berekenen van de MAC moet gebruik gemaakt worden van padding, zoals beschreven is in Referentie [7], section 10.1.

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.

Er is dan een secure messaging kanaal tussen de systeemkaart en de boordcomputer (MAC-ENC mode) en alle volgende commando’s en antwoorden moeten beveiligde gegevensoverdracht gebruiken.

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

Figuur 3: EF.Driver_Activity_Data
Naam	Grootte (bytes)
PointerOldestDayRecord	2
PointerLastDayRecord	2
DriverCardNumber	16
DailyRecords	variabel

EF.Driver_Activity_Data is opgebouwd uit de volgende elementen:

•: PointerOldestDayRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data) van de oudste volledige dagregistratie in DailyRecords.
De initiële waarde (na personalisatie) is ‘00 00’H (0) wat betekent dat er nog geen DailyRecords bestaan.
Na toevoeging van het eerste DailyRecord moet de waarde ‘00 14’H (20) zijn.
De maximale waarde wordt door de lengte van EF.Driver_Activity_Data bepaald.
Gegevenssoort: INTEGER (unsigned)
•: PointerLastDayRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data) van de meest recente dagregistratie in DailyRecords.
De initiële waarde (na personalisatie) is ‘00 00’H (0) wat betekent dat er nog geen DailyRecords bestaan.
Na toevoeging van het eerste DailyRecord moet de waarde ‘00 14’H (20) zijn.
De maximale waarde wordt door de lengte van EF.Driver_Activity_Data bepaald.
Gegevenssoort: INTEGER (unsigned)
•: DriverCardNumber: betreft een kopie van het chauffeurskaartnummer zoals dat ook aanwezig is in het subjectSerialNumber-veld van het (‘read-only’) authenticiteitcertificaat van de chauffeurskaart. Na personalisatie zal dit element gevuld zijn met het chauffeurskaartnummer. Handhavingsapplicaties downloaden in principe uitsluitend EF_Driver_Activity_Data van een chauffeurskaart. Om die applicaties te informeren over het chauffeurskaartnummer, dient een boord¬computer de correcte invulling van dit veld telkens na een succesvolle login te verifiëren en zo nodig te herstellen (zie ook § 7.1).
Gegevenssoort: PrintableString (16 bytes)
•: DailyRecords: de records waarin de gegevens van de activiteiten van de chauffeur opgeslagen worden (zie Figuur 4). Voor iedere dag dat de kaart gebruikt wordt, wordt een DailyRecord aangemaakt. De gegevens van minimaal de laatste 31 kalenderdagen worden op de kaart bewaard.

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.

Figuur 4: DailyRecord
Naam	Grootte (bytes)
DayRecordLength	2
PointerLastSessionRecord	2
PreviousDayRecordLength	2
DayRecordDate	4
SessionRecords	variabel

Een DailyRecord bestaat uit de volgende elementen:

•: DayRecordLength: de lengte van het huidige DailyRecord.
De initiële waarde bij een nieuw DailyRecord (dat nog geen enkel SessionRecord omvat) is ‘00 0A’H (10); de lengte van de kop van dit DailyRecord (zonder de SessionRecords).
Gegevenssoort: INTEGER (unsigned)
•: PointerLastSessionRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data) van de meest recente sessie in dit DailyRecord.
De initiële waarde bij een nieuw DailyRecord (dat nog geen enkel SessionRecord bevat) is ‘00 00’H (0).
Nadat aan dit DailyRecord het eerste SessionRecord is toegevoegd, moet de waarde 10 hoger zijn dan het startadres van dit DailyRecord; bij het eerste SessionRecord van het eerstgeboekte DailyRecord zal dit 20 + 10 = 30 (’00 1E'H) zijn.
Uitgezonderd de waarde 0, zal de waarde van PointerLastSessionRecord nooit kleiner zijn dan 30 (’00 1E’H).
Gegevenssoort: INTEGER (unsigned)
•: DayPreviousRecordLength: de lengte van het vorige DailyRecord. Is er geen vorige DailyRecord omdat deze de oudste is, dan is de waarde ‘00 00’H (0).
Uitgezonderd de waarde 0, zal de waarde van DayPreviousRecordLength nooit kleiner zijn dan 10 (’00 0A’H).
Gegevenssoort: INTEGER (unsigned)
•: DayRecordDate: de datum waarvoor dit DailyRecord is. Dit is in het formaat JJJJMMDD.
Gegevenssoort: BCD
•: SessionRecords: een of meerdere SessionRecords (zie Figuur 5) voor deze dag.

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.

Figuur 5: SessionRecord
Naam		Grootte (bytes)
PointerLastActivityRecord		2	299
PointerLastPWActivityRecord		2
SignatureDateTime
	SignatureDate	8 nibbles
	SignatureTime	6 nibbles
SessionSignature		256
SessionCreationDateTime
	SessionCreationDate	8 nibbles
	SessionCreationTime	6 nibbles
SystemCardNumber
	Boordcomputernr	9 nibbles
	Kaartvolgnummer	5 nibbles
Kenteken		6
CompanyCardNumber
	KvKnummer	12 nibbles
	Kaartvolgnummer	5 nibbles
Pnummer		7 nibbles
ActivityRecords		variabel	variabel

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

Een SessionRecord bestaat uit de volgende elementen:

•

PointerLastActivityRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data) van de het laatste ActivityRecord in deze SessionRecords.

De initiële waarde bij een nieuw SessionRecord (nog zonder ActivityRecords) is ‘00 00’H (0).

Uitgezonderd de waarde 0, zal de waarde van PointerLastActivityRecord nooit kleiner zijn dan 20+10+299 = 329 (’01 49’H).

Gegevenssoort: INTEGER (unsigned)

•

PointerLastPWActivityRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data) van het laatste ActivityRecord met een activiteit ‘Start pauze’ of ‘Start werk’.

De initiële waarde bij een nieuw SessionRecord (nog zonder ActivityRecords) is ‘00 00’H (0).

Zo lang er nog geen ‘Start pauze’ of ‘Start werk’ ActivityRecord in dit SessionRecord aanwezig is, blijft de waarde gelijk aan 0.

Uitgezonderd de waarde 0, zal de waarde van PointerLastPWActivityRecord nooit kleiner zijn dan 20+10+299 = 329 (’01 49’H).

Gegevenssoort: INTEGER (unsigned)

•

SignatureDateTime: het tijdstip direct voorafgaand aan het berekenen van de SessionSignature. Voor verdere informatie over de handtekening zetten, zie 5.4.

Dit veld bestaat uit twee delen:

–: SignatureDate:
formaat JJJJMMDD,
initiële waarde bij een nieuw SessionRecord: ‘00000000’H,
gegevenssoort BCD.
–: SignatureTime:
formaat hhmmss (24-uurs klok)
initiële waarde bij een nieuw SessionRecord: ‘000000’H,
gegevenssoort BCD.

•

SessionSignature: de door de boordcomputer gezette handtekening over de gegevens zoals gespecificeerd in § 5.4.

De initiële waarde bij een nieuw SessionRecord is ‘ongedefinieerd’.

Gegevenssoort: OCTET_STRING(SIZE(256))

•

SessionCreationDateTime: het tijdstip waarop dit SessionRecord werd gecreëerd.

Dit veld bestaat uit twee delen:

–: SignatureDate:
formaat JJJJMMDD,
initiële waarde bij een nieuw SessionRecord: de datum waarop dit SessionRecord werd gecreëerd,
gegevenssoort BCD.
–: SignatureTime:
formaat hhmmss
initiële waarde bij een nieuw SessionRecord: het tijdstip waarop dit SessionRecord werd gecreëerd,
gegevenssoort BCD.

•

SystemCardNumber: bestaat uit 2 delen:

–: Boordcomputernr:het nummer van de systeemkaart zoals op het moment van creëren van dit SessionRecord bekend in de boordcomputer (9 digits BCD)
–: Kaartvolgnummer: het volgnummer van de systeemkaart zoals op het moment van creëren van dit SessionRecord bekend in de boordcomputer (5 digits BCD)

•

Kenteken: het kenteken van het voertuig zoals op het moment van creëren van dit SessionRecord bekend in de boordcomputer (6 bytes ASCII)

•

CompanyCardNumber: bestaat uit 2 delen:

–: KvKnummer: Kamer van Koophandel nummer van de ondernemer zoals op het moment van creëren van dit SessionRecord bekend in de boordcomputer (12 digits BCD)
–: Kaartvolgnummer: volgnummer van de ondernemerskaart zoals op het moment van creëren van dit SessionRecord bekend in de boordcomputer (5 digits BCD)

•

Pnummer: personenvervoernummer van de ondernemer zoals op het moment van creëren van dit SessionRecord bekend in de boordcomputer (7 digits BCD)

•

ActivityRecords: een of meerdere ActivityRecords (zie Figuur 6).

5.1.3. ActivityRecord

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

Figuur 6: ActivityRecord
Activiteit Type	Kop				Gegevens		Opmerking
Activiteit Type	activiteit	handm.	rijden	tijdstip	Veld 1	Veld 2	Opmerking
Login	‘00001’B	‘0’B	‘0’/’1’B	hh:mm:ss	geen	geen	Het tijdstip waarop de BCT het inloggen constateerde.
Login	‘00001’B	‘1’B	‘0’/’1’B	hh:mm:ss	geen	geen	Een login kan geen handmatig ingesteld tijdstip hebben. Deze combinatie komt dus niet voor.
(Start) pauze	‘00010’B	‘0’B	‘0’/’1’B	hh:mm:ss	geen	geen	Het tijdstip waarop de BCT de start van de pauze constateerde. Recordvorm indien dit record niet het laatste ActivityRecord van de sessie is.
		‘0’B			aantal secondes pauze		Het tijdstip waarop de BCT de start van de pauze constateerde. Recordvorm indien dit record het laatste ActivityRecord van de sessie is.
		‘1’B			geen		Het handmatig opgegeven tijdstip dat de pauze aanving. Recordvorm indien dit record niet het laatste ActivityRecord van de sessie is.
		‘1’B			aantal secondes pauze		Het handmatig opgegeven tijdstip dat de pauze aanving. Recordvorm indien dit record het laatste ActivityRecord van de sessie is.
(Start) werk	‘00011’B	‘0’B	‘0’/’1’B	hh:mm:ss	aantal secondes rijden	geen	Het tijdstip waarop de BCT de start van werk constateerde. Recordvorm indien dit record niet het laatste ActivityRecord van de sessie is.
		‘0’B				aantal secondes werk	Het tijdstip waarop de BCT de start van werk constateerde. Recordvorm indien dit record het laatste ActivityRecord van de sessie is.
		‘1’B				geen	Het handmatig opgegeven tijdstip dat werk aanving. Recordvorm indien dit record niet het laatste ActivityRecord van de sessie is.
		‘1’B				aantal secondes werk	Het handmatig opgegeven tijdstip dat werk aanving. Recordvorm indien dit record het laatste ActivityRecord van de sessie is.
Afsluiting	‘00100’B	‘0’B	‘0’/’1’B	hh:mm:ss	geen	geen	reguliere Afsluiting: Het tijdstip waarop de BCT het afsluiten en aftekenen van de sessie constateerde.
Nieuwe eindtijd	‘00100’B	‘1’B	‘0’/’1’B	hh:mm:ss	geen	geen	handmatige Afsluting / Nieuwe eindtijd: Het handmatig opgegeven tijdstip dat een sessie (‘werkdag’) stopte.
Dagovergang	‘00101’B	‘0’B	‘0’/’1’B	23:59:59	geen	geen	Middernacht automatisch: Een dagovergang geconstateerd tijdens normale modus.
Dagovergang	‘00101’B	‘1’B	‘0’/’1’B	23:59:59	geen	geen	Middernacht handmatig: Een dagovergang geconstateerd tijdens handmatige invoer.

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

•

activiteit: geeft het type activiteit aan (5 bits).

•

handmatig: geeft aan of het tijdstip van de activiteit handmatig of automatisch is geboekt (1 bit).

•

rijden: geeft aan of de activiteit tijdens het rijden of stilstaan is geboekt (1 bit).

•

tijdstip: geeft het starttijdstip van de activiteit aan in het formaat hhmmss. Dit formaat is als volgt opgebouwd:

–: hh: 5 bits
–: mm: 6 bits
–: ss: 6 bits

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

•: gedurende het werk wordt volautomatisch bijgehouden hoeveel secondes er gereden worden (3 bytes INTEGER (unsigned)). Wanneer (na een periode van rijden gedurende werktijd) het aantal secondes gewijzigd is, wordt hetzelfde record opnieuw geschreven, waarbij de kop gelijk blijft en het aantal secondes aangepast. Dit bijwerken van rijtijd moet ook plaatsvinden indien de laatste keer bijwerken (meer dan) vijf minuten geleden was. Er wordt dus geen nieuw record aangemaakt.

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

•: gedurende het werk / de pauze wordt volautomatisch bijgehouden hoeveel secondes er verstreken zijn sinds de activiteit startte (3 bytes INTEGER (unsigned)). Telkens wanneer de auto stopt en telkens vijf minuten na de vorige vastlegging van de tijdsduur worden de laatste 3 bytes van hetzelfde record opnieuw geschreven, waarbij de voorgaande bytes gelijk blijven en het aantal secondes aangepast. Er wordt dus geen nieuw record aangemaakt.
•: Het eerstvolgende toe te voegen ActivityRecord overschrijft deze laatste 3 bytes (de daadwerkelijke tijdsduur van de dan voorafgaande ‘Start werk’ / ‘Start pauze’ activiteit wordt met de starttijd van de nieuwe activiteit definitief vastgelegd).

Noot 3: Bij iedere toevoeging van een ActivityRecord bestaat de mogelijkheid dat er een nieuw DailyRecord en/of nieuw SessionRecord aangemaakt moet worden. Zie hiervoor ook § 7.5 en § 0.

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.

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.

In Figuur 7 staat een overzicht van EF.Driver_Activity_Data en hoe de verschillende records hier onder vallen.

RSTGBTAXI_stc-2015-9656_BIJL4_03

Figuur 7: Overzicht EF.Driver_Activity_Data

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:

1.

In het SessionRecord dient PointerLastActivityRecord gezet te worden op PointerLastSessionRecord + 299;

2.

In het huidige DailyRecord dient de DayRecordLength verhoogd te worden met de (ongecorrigeerde) lengte van het toe te voegen ActivityRecord:

–: Voor een ‘Start werk’, verhogen met 9;
–: Voor een ‘Start pauze’, verhogen met 6;
–: Voor elke andere activiteit, verhogen met 3.

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.

Bij een ‘Login’ wordt er een nieuw ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

1.: PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd met 3 indien het huidige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).
2.: het ActivityRecord ‘Login’ toegevoegd op de plaats die aangegeven wordt door de verhoogde PointerLastActivityRecord. Dit record bestaat uit 3 bytes (alleen een kop). De handmatig bit staat altijd op ‘0’B.
3.: SessionSignature = de tussentijdse handtekening (zie 5.4).

In het huidige DailyRecord wordt

1.: DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).
2.: Direct na het toevoegen van de ‘Login’ activiteit wordt een (automatisch) geklokte ‘Start werk’ activiteit toegevoegd.

5.2.3. Toevoegen ‘Start pauze’ activiteit

Bij een ‘Start pauze’ wordt er een nieuw ActivityRecord aangemaakt.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

1.: PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd met 3 indien het huidige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).
2.: PointerLastPWActivityRecord wordt gelijkgesteld aan de zojuist verhoogde PointerLastActivityRecord.
3.: het ActivityRecord ‘Start pauze’ toegevoegd op de plaats die aangegeven wordt door de verhoogde PointerLastActivityRecord. Dit record bestaat uit 6 bytes (een kop + een tijdsduurteller), waarbij de tijdsduurteller initieel wordt gevuld met ‘00 00 00’H en daarna periodiek wordt bijgewerkt volgens Noot 2 in § 5.1.3.
4.: SessionSignature = de tussentijdse handtekening (zie 5.4).

In het huidige DailyRecord wordt

1.: DayRecordLength = oude waarde DayRecordLength + 6 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).

5.2.4. Toevoegen ‘Start werk’ activiteit

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

1.: PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd met 3 indien het huidige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).
2.: PointerLastPWActivityRecord wordt gelijkgesteld aan de zojuist verhoogde PointerLastActivityRecord.
3.: het ActivityRecord ‘Start werk’ toegevoegd op de plaats die aangegeven wordt door de verhoogde PointerLastActivityRecord.
Dit record bestaat uit een kop van 3 bytes gevolgd door 2 x 3 bytes data.
De data geeft het aantal secondes aan dat er met het voertuig gereden is en het aantal secondes dat deze activiteit in totaal duurde. Bij het begin van ‘Start werk’ zijn beiden ‘00 00 00’H. Deze waardes worden conform Noten 1 en 2 in § 5.1.3 tussentijds bijgewerkt tot er een andere activiteit plaats vindt.
4.: SessionSignature = de tussentijdse handtekening (zie 5.4).

In het huidige DailyRecord wordt

1.: DayRecordLength = oude waarde DayRecordLength + 9 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).

5.2.5. Toevoegen ‘Afsluiting’ activiteit

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

1.: PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd met 3 indien het huidige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).
2.: het ActivityRecord ‘Afsluiting’ toegevoegd op de plaats die aangegeven wordt door de verhoogde PointerLastActivityRecord. Dit record bestaat uit 3 bytes (alleen een kop).
3.: SessionSignature = de definitieve handtekening (zie 5.4).

In het huidige DailyRecord wordt

1.: DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).

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.

PointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.

In dit SessionRecord wordt

1.: PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd met 3 indien het huidige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).
2.: het ActivityRecord ‘Nieuwe eindtijd’ toegevoegd op de plaats die aangegeven wordt door de verhoogde PointerLastActivityRecord. De handmatig-bit staat hier altijd op ‘1’B. Dit record bestaat uit 3 bytes (alleen een kop).
3.: SessionSignature = de definitieve handtekening (zie 5.4).

In het huidige DailyRecord wordt

1.: DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft).

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:

•: (situatie 1) het betreft een automatische activiteit en de BCT-klok geeft 0:00:00u aan OF;
•: (situatie 2) er wordt een handmatige activiteit toegevoegd met een tijdstip op of na 0:00:00u van de dag volgend op het huidige DailyRecord,

dan moet:

•

de rijtijdteller worden bijgewerkt indien de laatstgeboekte activiteit een ‘Start werk’ betreft,

•

de huidige sessie gestopt worden door toevoeging van een ‘Dagovergang’ activiteit met:

○: het tijdstip 23:59:59u
○: het handmatig bit op ‘0’B indien het situatie 1 betreft OF
○: het handmatig bit op ‘1’B indien het situatie 2 betreft,

•

de huidige sessie worden ‘afgetekend’ door de boordcomputer

•

EN een nieuw DailyRecord voor de volgende kalenderdag worden aangemaakt met een nieuw SessionRecord en een eerste ActivityRecord met

○: hetzelfde ActivityType als de laatstgeboekte activiteit EN
○: het tijdstip op 00:00:00u
○: het handmatig bit op ‘0’B indien het situatie 1 betreft OF
○: het handmatig bit op ‘1’B indien het situatie 2 betreft

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

1.: PointerLastActivityRecord verhoogd met de lengte van het laatste ActivityRecord verminderd met 3 omdat het huidige ActivityRecord een ‘Start werk’ of ‘Start pauze’ betreft.
2.: het ActivityRecord ‘Dagovergang’ toegevoegd op de plaats die aangegeven wordt door de verhoogde PointerLastActivityRecord. De handmatig-bit en het tijdstip worden gevuld zoals hierboven beschreven. Dit record bestaat uit 3 bytes (alleen een kop).
3.: SessionSignature = de definitieve handtekening (zie 5.4).

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

NB. Indien de invoeging van de dagovergang en de nieuwe kalenderdag het gevolg is van het toevoegen van een handmatige activiteit, dan kán het zo zijn dat er meer dan één kalenderdag tussen de huidige activiteit en de toe te voegen activiteit bestaat. Indien dat zo blijkt te zijn dan dienen de instructies in deze paragraaf te worden herhaald voor iedere betreffende (kalender)dagovergang.

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:

1.

EF.Driver_Activity_Data kan records bevatten vanaf positie ‘00 14’H tot aan het eind (Length_EF.Driver_Activity_Data). De eerste 20 bytes van EF.Driver_Activity_Data worden in beslag genomen worden door twee 16-bits pointers en een 16-bytes veld voor het chauffeurskaartnummer.

2.

Wanneer er voor een toevoeging niet meer voldoende ruimte aan het eind van EF.Driver_Activity_Data is, wordt eerst de resterende ruimte benut en daarna gaat het toevoegen verder vanaf het begin van de EF.Driver_Activity_Data. Dit is dan vanaf positie ‘00 14’H.

3.

De lengte van een te lezen of te schrijven record kan nooit langer zijn dan Length_EF.Driver_Activity_Data – 20 (‘14’H).

4.

De offset bij een Read Binary of Update Binary (Pointer_1) moet kleiner zijn dan Length_EF.Driver_Activity_Data. Indien dit niet het geval is, moet de offset vervangen worden door de Pointer_1 – Length_EF.Driver_Activity_Data + 20 (‘14’H).

5.

Indien bij een Read Binary de offset (Pointer_1) + het verwachte aantal bytes in de response (Length_1) groter is dan Length_EF.Driver_Activity_Data, dan moet de Read Binary in tweeën gesplitst worden: 1 Read Binary tot aan het eind van EF.Driver_Activity_Data en 1 Read Binary vanaf positie ‘00 14’H tot aan Pointer_1 + Length_1 – Length_EF.Driver_Activity_Data + 20 (‘14’H).

6.

Indien bij een Update Binary de offset (Pointer_1) + het aantal weg te schrijven bytes (Length_1) groter is dan Length_EF.Driver_Activity_Data, dan moet de Update Binary in tweeën gesplitst worden: 1 Update Binary tot aan het eind van EF.Driver_Activity_Data en 1 Update Binary vanaf positie ‘00 14’H tot aan Pointer_1 + Length_1 – Length_EF.Driver_Activity_Data + 20 (‘14’H).

7.

Bij een Update Binary bestaat de mogelijkheid dat de oudste dagregistratie overschreven wordt. Dit is het geval wanneer data voorbij PointerOldestDayRecord geschreven zou worden. Hier moet dus bij iedere schrijfactie op getest worden.

Om te voorkomen dat voorbij PointerOldestDayRecord geschreven wordt, moet het oudste DailyRecord weggehaald worden.

Dit wordt op de volgende manier gedaan:

1.: PointerOldestDayRecord wijst naar het oudste DailyRecord. In dit DailyRecord staat de lengte van dit record (DayRecordLength). Uit deze pointer en lengte kan de positie van het volgende DailyRecord bepaald worden.
2.: In dit volgende DailyRecord wordt de PreviousDayRecordLength op ‘00 00’H gezet.
3.: PointerOldestDayRecord wordt op de positie van dit volgende DailyRecord gezet.
4.: Wanneer er nog niet genoeg ruimte is voor de toevoeging, moeten de bovenstaande punten herhaald worden.

5.4. Digitale handtekening

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

1.: De handtekening die door de chauffeurskaart over de gegevens van de kaartsessie gezet wordt in de boordcomputer.
2.: De handtekening die door de boordcomputer gezet wordt over de kaartsessie gegevens op de chauffeurskaart.

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:

1. DriverCardNumber	16 bytes ASCII
2. DayRecordDate	4 bytes BCD
3. SessionCreationDateTime	4 + 3 bytes BCD
4. SystemCardNumber	4½ + 2½ bytes BCD
5. Kenteken	6 bytes ASCII
6. CompanyCardNumber	6 + 2½ bytes BCD
7. Pnummer	3½ bytes BCD
8. ActivityRecords1.	variable
9. PointerLastActivityRecord	2 bytes INTEGER
10. PointerLastPWActivityRecord	2 bytes INTEGER
11. SignatureDateTime	4 + 3 bytes BCD

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

•: Over de gegevens, als hierboven vermeld, wordt met behulp van de private sleutel voor authenticiteit van de boordcomputer een handtekening gegenereerd volgens PKCS#1 v1.5 met SHA-256.
•: De handtekening wordt opgeslagen in het SessionSignature veld van het huidige SessionRecord.

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.

NB3. Indien bij het valideren van de SessionRecord-data de betreffende EF.BCT_Certificates aanwezig is en het betreffende boordcomputercertificaat is daarin ook (nog) aanwezig, kan de validatie direct worden uitgevoerd. Indien het betreffende boordcomputercertificaat niet (meer) in EF.BCT_Certificates is opgeslagen of indien EF.BCT_Certificates niet voorhanden is, dan kan het betreffende boordcomputercertificaat via de Kaartuitgever worden verkregen.

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.

Een boordcomputer dient een bestuurder (tijdig) te waarschuwen dat de momenteel op de chauffeurskaart opgeslagen arbeids-, rij- en rusttijden moeten worden geëxporteerd (ook wel ‘gedownload’). Aan EF.BCT_Certificates is daarom een extra gegevensstructuur toegevoegd die vermeldt wanneer en naar welke boordcomputer welke dailyrecords zijn geëxporteerd.

6.1. Opbouw van EF.BCT_Certificates

Figuur 8: EF.BCT_Certificates
Naam	Grootte (bytes)
Rank	3
Index	3 x 7
Certificates	3 x 2100
IndexOldestDL	1
DownloadLogs	8 x 33
FILLER	11
Totaal	6600

EF.BCT_Certificates is opgebouwd uit de volgende elementen:

•: Rank: Hierin wordt aangegeven in welke volgorde (van meest naar minst recent) de navolgende certificaten zijn gebruikt. Iedere byte correspondeert met een van de certificaten in Certificates (byte 1 <-> certificaat 1 en dergelijke). De (initiële) waarde 0 geeft aan dat er geen certificaat op die plaats staat en de waarde 1 – 3 hoe recent het bijbehorende certificaat is (waarbij de waarde 1 het meest recent is).
Gegevenssoort: INTEGER (unsigned)
•: Index: Een index bestaat uit een systeemkaartnummer (het boordcomputernummer (BCD-9) gevolgd door het kaartvolgnummer (BCD-5)), voor ieder opgeslagen certificaat (3x). Iedere index correspondeert met een van de certificaten in Certificates (index 1 <-> certificaat 1 en verder).
De initiële waarde voor iedere index is ‘00 00 00 00 00 00 00’.
Gegevenssoort: BCD
•: Certificates: Hierin worden de 3 meest recente certificaten van boordcomputers opgeslagen. In Rank is te vinden hoe recent een bepaald certificaat is en in Index staat het bijbehorende boordcomputernummer en kaartvolgnummer. Initieel zijn de certificaten gevuld met nullen (‘00’).
Indien een certificaat korter is dan 2100 bytes, wordt de resterende ruimte opgevuld met ‘00’-bytes.
Gegevenssoort: OCTET STRING
NB. Een certificaat is een ASN.1 DER gecodeerde TLV-gegevensstructuur die voor BCT certificaten begint met een 8-bits Tag (30h), een byte dat aangeeft dat er 2 lengte bytes volgen (82h) en een 16-bits Length en gevolgd wordt door een Value van zoveel bytes als aangegeven door Length.
•: IndexOldestDL: Hierin wordt aangegeven welke van de navolgende (8) DownloadLog items het oudste is en dus als eerste overschreven zal worden. Initieel zal dit veld gevuld worden met de waarde 0 (‘00’H) en de maximale waarde zal 7 (‘07’H) zijn (0 wijst naar DownloadLog_1 en 7 wijst naar DownloadLog_8). Na het overschrijven van DownloadLog_8 zal IndexOldestDL gereset moeten worden naar 0.
De initiele vulling zal volledig uit nullen (‘00’H) bestaan.
Gegevenssoort: OCTET STRING
•: DownloadLogs: Hierin wordt informatie bijgehouden van de 8 meest recente keren dat de bestuurder de inhoud van EF.Driver_Activity_Data naar een boord¬computer heeft gedownload. Elk van deze log items (DownloadLog_1 t/m DownloadLog_8) bestaat uit 33 bytes.
Gegevenssoort: INTEGER (unsigned)

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

Figuur 9: Initiële waardes EF.BCT_Certificates
Positie	Gegevens	Bytes	Benaming
00 00	00	1	Rank_1	Rank
00 01	00	1	Rank_2
00 02	00	1	Rank_3
00 03	00 – 00	7	Index_1	Index
00 0A	00 – 00	7	Index_2
00 11	00 – 00	7	Index_3
00 18	00 – 00	2100	Certificate_1	Certificates
08 4C	00 – 00	2100	Certificate_2
10 80	00 – 00	2100	Certificate_3
18 B4	00	1	IndexOldestDL	IndexOldestDL
18 B5	00 – 00	33	DownloadLog_1	DownloadLogs
18 D6	00 – 00	33	DownloadLog_2
18 F7	00 – 00	33	DownloadLog_3
19 18	00 – 00	33	DownloadLog_4
19 39	00 – 00	33	DownloadLog_5
19 5A	00 – 00	33	DownloadLog_6
19 7B	00 – 00	33	DownloadLog_7
19 9C	00 – 00	33	DownloadLog_8
19 BD	00 – 00	11	FILLER	FILLER
19 C8	end of file (6600 bytes totaal)
Noot: Positie en gegevens zijn in hexadecimale notatie weergegeven Noot: CertLength = 2100 (‘08 34’H)

De opbouw van een DownloadLog_X gegevensstructuur is opgenomen in de onderstaande figuur.

Naam				Grootte
DownloadLog_X							33 bytes
	CarAndCompany					25 bytes
		SystemCardNumber			7 bytes
			Boordcomputernr	9 nibbles
			Kaartvolgnummer	5 nibbles
		Kenteken			6 bytes
		CompanyCardNumber			17 nibbles
			KvKnummer	12 nibbles
			Kaartvolgnummer	5 nibbles
		Pnummer			7 nibbles
	DownloadPeriod					8 bytes
		OldestDate			8 nibbles
		DownloadDate			8 nibbles

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.

De wijzigingen in de arbeids- rij- en rusttijden worden tijdens een kaartsessie op de chauffeurskaart opgeslagen in ActivityRecords (zie Figuur 6 en paragrafen 5.2 en 0). Hieronder wordt aangegeven welke informatie op welk ogenblik opgeslagen wordt. Voor voorbeelden van kaartsessies wordt verwezen naar Bijlage A.

RSTGBTAXI_stc-2015-9656_BIJL4_04

Figuur 10: Overzicht kaartsessie

7.1. Begin van een kaartsessie

Het begin van een kaartsessie gaat als volgt:

1.

De chauffeurskaart wordt in de boordcomputer ingebracht en er vindt een authenticatie van de chauffeurskaart plaats. Zie hiervoor § 0. Dit ogenblik bepaalt het login-tijdstip wat in stap 5 als activiteitrecord wordt toegevoegd.

2.

Direct na het inloggen moet worden geverifieerd of in posities ‘00 04’H t/m ‘00 13’H van de EF.Driver_Activity_Data het chauffeurskaartnummer nog steeds overeenstemt met het chauffeurskaartnummer zoals dat in (de eerste 16 bytes van) het subject.serialNumber van het authenticiteitcertificaat is opgeslagen. Indien het niet meer overeenstemt, dienen de genoemde byteposities in EF.Driver_Activity_Data te worden bijgewerkt en dient de gebruiker te worden gewaarschuwd.

Ook dient in deze stap de daadwerkelijke grootte van EF.Driver_Activity_Data te worden vastgesteld. Zie hiervoor § 9.5.

3.

Er wordt dan gecontroleerd of het certificaat van deze boordcomputer al op deze chauffeurskaart staat en zo niet, dan wordt dit toegevoegd (zie 6 Gegevens op chauffeurskaart (EF.BCT_Certificates)). In beide gevallen wordt dit certificaat als meest recente gemarkeerd. Eventueel andere, reeds bestaande certificaatentries worden gemarkeerd als minder recente. Indien er geen ruimte meer is vervalt de oudste entry.

4.

Er wordt gecontroleerd of er op de boordcomputer nog een geblokkeerde sessie voor deze kaart is (zie 7.4):

–: Is er geen geblokkeerde sessie voor deze kaart op de boordcomputer of is de kaart inmiddels in een andere boordcomputer gebruikt, dan wordt gecontroleerd of op de kaart de vorige sessie correct afgesloten was.
Hiervoor moet de laatste activiteit in het huidige SessionRecord ‘Afsluiting’, ‘Nieuwe eindtijd’ of ‘Dagovergang’ zijn. Is dit niet het geval, dan wordt de gebruiker er op geattendeerd dat deze vorige sessie niet correct was afgesloten.
–: Is de laatste activiteit in het laatste SessionRecord een ‘Afsluiting’, ‘Dagovergang’ of ‘Nieuwe eindtijd’ en wijst de PointerLastPWActivityRecord van dat SessionRecord naar een ‘Start pauze’ activiteit, dan is er iets bijzonders aan de hand. Een arbeidsperiode lijkt dan te eindigen met een pauze. In dit geval dient de boordcomputer de bestuurder er extra op te attenderen dat er mogelijk een handmatige aanvulling / correctie benodigd is die met stap 5 kan worden gedaan.
–: Is er nog een geblokkeerde sessie voor deze kaart op de boordcomputer en is de kaart tussentijds niet in een andere boordcomputer gebruikt, dan vervalt de blokkering en wordt de sessie vervolgd.

5.

Zijn er, tussen de laatst op de kaart geboekte ‘Start werk’ of ‘Start pauze’ activiteit en het onthouden login-tijdstip, nog activiteiten toe te voegen, dan kan dat nu gebeuren (zie vooral ook het tweede aandachtsstreepje van de vorige stap).

Bepaal hiertoe de start-datumtijd en de eventuele eind-datumtijd van die laatstgeboekte ‘Start pauze’ of ‘Start werk’ activiteit, waarbij de eindtijd hetzij kan worden gelezen uit de afsluitingsactiviteit die volgt op de ‘Start werk’ / ‘Start pauze’, hetzij kan worden berekend m.b.v. de tijdsduurteller van de ‘Start werk’ / ‘Start pauze’ zelf.

In dat geval,

–: Presenteer de laatstgeboekte ‘Start werk’ / ‘Start pauze’ inclusief diens uitgelezen start- en eind-datumtijd.
–: Dan kan er een ‘Start werk’ of een ‘Start pauze’ activiteit toegevoegd worden.
De standaard (start)datumtijd hiervoor is de eind-datumtijd van de laatste ‘Start werk’ of ‘Start pauze’ activiteit; dit kan de gebruiker veranderen in een waarde tussen minimaal de start-datumtijd van die laatste ‘Start werk’ of ‘Start pauze’ activiteit en maximaal het login-tijdstip. De ‘handmatig’-bit wordt op ‘1’B gezet.
Een start die eerder is dan het einde van de vorige ‘Start werk’ of ‘Start pauze’ activiteit, zal die eerdere activiteit geheel of gedeeltelijk veranderen.
Een start die gelijk is dan het einde van de vorige ‘Start werk’ of ‘Start pauze’ activiteit, zal direct op die eerdere activiteit aansluiten.
Een start die later is dan het einde van de vorige ‘Start werk’ of ‘Start pauze’ activiteit, zal een rustperiode inlassen.
Gebruik voor het toevoegen van deze handmatige activiteit de logica beschreven in § 0 en geef daarbij door of een kaartsessie al dan niet gecontinueerd mocht worden.
–: Ook kan er voor gekozen worden om handmatig een ‘Nieuwe eindtijd’ op te geven.
Ook daarvan kan de datumtijd ingesteld worden tussen minimaal de start-datumtijd van de laatste activiteit en maximaal het login-tijdstip.
De ‘handmatig’-bit wordt op ‘1’B gezet.
Een nieuw einde dat gelijk is aan de start van de vorige ‘Start werk’ of ‘Start pauze’ activiteit, zal die eerdere activiteit effectief verwijderen.
Een nieuw einde tussen de start en het (momenteel geldende) einde van de vorige ‘Start werk’ of ‘Start pauze’ activiteit, zal die eerdere activiteit effectief inkorten.
Een nieuw einde later dan het (momenteel geldende) einde van de vorige activiteit, zal die eerdere activiteit effectief verlengen.
Gebruik voor het toevoegen van deze handmatige activiteit de logica beschreven in § 0 en geef daarbij door of een kaartsessie al dan niet gecontinueerd mocht worden.
–: Toevoegen kan meerdere keren uitgevoerd worden. De laatst (handmatig) toegevoegde activiteit geldt dan telkens als de ‘vorige’.
–: De mogelijkheid bestaat dat dit toevoegen over meerdere dagen gaat. In dat geval zal de logica beschreven in § 0 de eventuele aanmaak van nieuwe DailyRecords en/of SessionRecords verzorgen.
–: Hoeft er niets meer toegevoegd te worden, dan kan met de volgende stap worden verder gegaan.

6.

Vervolgens wordt het login-tijdstip middels een ‘Login’ activiteit toegevoegd (zie 5.2.1), waarna direct een ‘Start werk’ (zie 5.2.4) zal worden toegevoegd. Beide ActivityRecords zullen de handmatig bit op ‘0’B hebben staan.

Ook nu zullen de toevoegingen gedaan worden conform de logica beschreven in § 0.

Vanaf dit punt begint de reguliere vastlegging van activiteiten.

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.

‘Start werk’ moet regelmatig bijgewerkt worden met het aantal secondes dat er met het voertuig gereden is (zie Noot 1 in § 5.1.3). ‘Start werk’ en ‘Start pauze’ moeten regelmatig bijgewerkt worden met het aantal secondes dat de betreffende activiteit duurt (zie Noot 2 in § 5.1.3).

7.3. Afsluiten van een kaartsessie

Bij het beëindigen 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.

Direct nadat de ‘Afsluiting’ activiteit is toegevoegd en nog voordat de chauffeur zijn kaart uitneemt, dient de boordcomputer:

1.

in EF.BCT_Certificates het DownloadLog controleren en vast te stellen of de laatste download van EF.Driver_Activity_Data naar een boordcomputer al dan niet te lang geleden is of lijkt. Indien dat zo blijkt te zijn, dan dient de boordcomputer de bestuurder hierop te attenderen;

2.

de chauffeur de gelegenheid te bieden om de volledige inhoud van EF.Driver_Activity_Data naar het geheugen van de boordcomputer te downloaden. Indien de chauffeur hierop ingaat, dan dient de boordcomputer:

a.: Aan de chauffeur een waarschuwing te tonen dat de kaart (nog) niet mag worden uitgenomen;
b.: De volledige inhoud van EF.Driver_Activity_Data te downloaden naar het geheugen van de boordcomputer;
c.: In EF.BCT_Certificates het DownloadLog bij te werken;
d.: Aan de chauffeur te melden dat de kaart nu mag worden uitgenomen.

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.

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

•: binnen 60 minuten dezelfde chauffeurskaart weer in te brengen in de boordcomputer. Zijn er in de tussentijd activiteiten op de boordcomputer geregistreerd geweest, dan worden die allereerst op de chauffeurskaart bijgewerkt.
•: binnen 60 minuten dezelfde chauffeurskaart weer in te brengen en er blijkt dat de kaart in de tussentijd in een andere boordcomputer heeft gezeten. Eventuele tussentijdse activiteiten die op deze boordcomputer waren geregistreerd worden niet meer op de kaart geplaatst.
•: een andere boordcomputerkaart in te brengen, uitgezonderd een inspectiekaart.
•: een time-out van 60 minuten.

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.

In alle gevallen wordt na het inloggen de chauffeur de mogelijkheid geboden voor het handmatig toevoegen van activiteiten die hebben plaatsgevonden tussen de laatstgeboekte ‘Start werk’ of ‘Start pauze’ activiteit en het login-tijdstip. Pas nadat dergelijke handmatige boekingen op de kaart zijn bijgeschreven, wordt het Login-tijdstip vastgelegd door het toevoegen van een ‘Login’ ActivityRecord die aangeeft wanneer de kaart weer in de boordcomputer ingebracht is (zie 5.2.1). Direct aansluitend wordt (met hetzelfde tijdstempel) een ‘Start werk’ activiteit toegevoegd.

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.

Hiervoor wordt

1.

Indien de huidige activiteit een (automatische) ‘Start werk’ is, het aantal secondes rijden bijgewerkt.

2.

Een interne kopie gemaakt van de huidige activiteit (‘Start werk’ of ‘Start pauze’). In die kopie wordt het tijdstipveld op 00:00:00 gezet en de handmatig bit dient te reflecteren of deze dagovergang tijdens het handmatig bijwerken van de administratie dan wel tijdens de normale operatie van de boordcomputer werd geconstateerd.

3.

Een ‘Dagovergang’ activiteit toegevoegd aan het huidige SessionRecord om 23:59:59 (zie 5.2.7). Het handmatig bit dient ook hierbij te reflecteren of deze dagovergang tijdens het handmatig bijwerken van de administratie dan wel tijdens de normale operatie van de boordcomputer werd geconstateerd.

4.

De interne kopie van de voort te zetten activiteit toegevoegd op de eerstvolgende kalenderdag. Omdat dit de eerste activiteit in die volgende kalenderdag betreft, worden er eerst een nieuw DailyRecord en SessionRecord aangemaakt.

5.

Indien de splitsing het gevolg van een handmatige toevoeging was:

a.: wordt eerst gecontroleerd of die toevoeging wellicht nóg een of meer kalenderdagen vooruit betreft en indien dat zo is, worden de bovenstaande stappen herhaald,
b.: wordt pas daarna de opgegeven activiteit toegevoegd.

8. Functies

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.

Bij deze functies moeten ook de punten uit 5.3 (Algemene opmerkingen bij lezen en schrijven) in acht worden genomen.

8.1. PIN wijzigen

Naam Gebruik	ChangePIN Boordcomputerkaarten
Input gegevens	Oude PIN \|\| Nieuwe PIN
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van Change Reference Data, afhankelijk van de implementatie

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:

P/F

Waarin:

Naam		Waarde
C	Controle veld	4 bits binair getal ‘0010’B
N	PIN lengte	4 bits binair getal tussen ‘0100’B en ‘1100’B
P	PIN cijfer	4 bits binair getal tussen ‘0000’B en ‘1001’B
P/F	PIN cijfer / Vulteken	Afhankelijk van PIN lengte
F	Vulteken	4 bits binair getal ‘1111’B

De PIN is dus maximaal 12 cijfers lang.

Het gebruikte commando is Change Reference Data, waarbij de PIN reference de waarde ‘01’H heeft en oude PIN || nieuwe PIN als data meegegeven wordt.

8.2. SM keyset wijzigen

Naam	ChangeSMKeySet
Gebruik	Systeemkaart
Input gegevens	Nieuwe Key Set
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van Put Data (SDO), afhankelijk van de implementatie

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

waarbij Kmac en Kenc de 16 bytes sleutels zijn voor de MAC resp. de ENC.

8.3. PIN deblokkeren

Naam	DeblockPIN
Gebruik	Boordcomputerkaarten
Input gegevens	Geen
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van Reset Retry Counter, afhankelijk van de implementatie

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.

Voorafgaand aan dit commando moet een succesvol Verify commando uitgevoerd worden met P1 = ‘00’H en P2 = ‘02’H (de PUK reference). Voor de PUK wordt PIN formaat 2 gebruikt (zie onder 8.1).

8.4. PIN deblokkeren en wijzigen

Naam	DeblockAndChangePIN
Gebruik	Boordcomputerkaarten
Input gegevens	Nieuwe PIN
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van Reset Retry Counter, afhankelijk van de implementatie

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.

Voorafgaand aan dit commando moet een succesvol Verify commando uitgevoerd worden met P1 = ‘00’H en P2 = ‘02’H (de PUK reference). Voor de PUK wordt PIN formaat 2 gebruikt (zie onder 8.1).

8.5. Elektronische handtekening zetten met een chauffeurs- of inspectiekaart

Naam Gebruik	SignDataLegally Chauffeurskaart, Inspectiekaart
Input gegevens	Gegevens waarover handtekening berekend moet worden
Resultaat	Handtekening \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

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:

1.: Selectie hash template en algoritme: alvorens de digitale handtekening berekend kan worden, moet het hash template geselecteerd worden en het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘AA’H. De data bij dit commando is ‘80 01 40’H (‘40’H om de algoritme identifier voor SHA-256 aan te geven).
2.: Selectie private key en algoritme: de private key van de BCT Handtekening moet geselecteerd worden met het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘B6’H. De data bij dit commando is ‘80 01 42 84 01 86’H (‘42’H om ‘PKCS#1 v1.5 – SHA-256’ aan te duiden en ‘86’H om het Security Data Object (SDO) van PKI.CH.DS aan te duiden).
3.: PIN valideren: de private key van de BCT Handtekening mag pas gebruikt worden nadat de PIN gevalideerd is. Dit is nodig voor iedere keer dat deze key gebruikt wordt.
Dit wordt gedaan met het commando Verify, waarbij P2 (de PIN reference) de waarde ‘01’H heeft. Voor de PIN wordt PIN formaat 2 gebruikt (zie onder 8.1).
4.: Berekenen van de intermediate hash (SHA256) over de input gegevens door de boordcomputerlogica. Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte bits onthouden voor de volgende stap.
NB. Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.
5.: Berekenen van de uiteindelijke hash (SHA256) door de boordcomputerkaart. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de ‘intermediate hash value’, het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het geheugen van de boordcomputerkaart (chip) achterblijven ten behoeve van de volgende en laatste stap.
6.: Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend over de in het chipgeheugen aanwezige hashwaarde en geeft de kaart die handtekening terug aan de boordcomputerlogica.
Dit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte aantal bytes in de response, moet daarbij op ‘00’H staan.

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

1.: Niet van toepassing.
2.: Gelijk aan stap 2 van procedure 1.
3.: Gelijk aan stap 3 van procedure 1.
4.: Berekenen van de volledige hash (SHA256) over de input gegevens door de boordcomputerlogica.
5.: Niet van toepassing.
6.: Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend over de in stap 4 berekende hashwaarde en geeft de kaart die handtekening terug aan de boordcomputerlogica.
Dit wordt gedaan met het commando PSO Compute Digital Signature. Daarbij moet Lc, het aantal bytes van de input data, op ‘20’H staan, het DATA veld worden gevuld met de hashwaarde uit stap 4 (32 bytes) en Le, het verwachte aantal bytes in de response, op ‘00’H staan.

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).

8.6. Elektronische handtekening zetten met een systeemkaart

Naam Gebruik	SignDataSystem Systeemkaart
Input gegevens	Gegevens waarover handtekening berekend moet worden
Resultaat	Handtekening \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

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.

Voor deze functie bestaat procedure 1 uit de volgende stappen:

1.: Selectie hash template en algoritme: alvorens de digitale handtekening berekend kan worden, moet het hash template geselecteerd worden en het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘AA’H. De data bij dit commando is ‘80 01 40’H (‘40’H om de algoritme identifier voor SHA-256 aan te geven).
2.: Selectie private key en algoritme: de private key van de BCT Authenticiteit moet geselecteerd worden met het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘B6’H. De data bij dit commando is ‘80 01 42 84 01 85’H (‘42’H om ‘PKCS#1 v1.5 – SHA-256’ aan te duiden en ‘85’H om het Security Data Object (SDO) van PKI.CH.AUT aan te duiden).
3.: Berekenen van de intermediate hash (SHA256) over de input gegevens door de boordcomputerlogica. Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte bits onthouden voor de volgende stap.
NB. Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.
4.: Berekenen van de uiteindelijke hash (SHA256) door de systeemkaart. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de ‘intermediate hash value’, het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het geheugen van de systeemkaart (chip) achterblijven ten behoeve van de volgende en laatste stap.
5.: Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend over de in het chipgeheugen aanwezige hashwaarde en geeft de kaart die handtekening terug aan de boordcomputerlogica.
Dit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte aantal bytes in de response, moet daarbij op ‘00’H staan.

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

1.: Niet van toepassing.
2.: Gelijk aan stap 2 van procedure 1.
3.: Berekenen van de volledige hash (SHA256) over de input gegevens door de boordcomputerlogica.
4.: Niet van toepassing.
5.: Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend over de in stap 3 berekende hashwaarde en geeft de kaart die handtekening terug aan de boordcomputerlogica.
Dit wordt gedaan met het commando PSO Compute Digital Signature. Daarbij moet Lc, het aantal bytes van de input data, op ‘20’H staan, het DATA veld worden gevuld met de hashwaarde uit stap 3 (32 bytes) en Le, het verwachte aantal bytes in de response, op ‘00’H staan.

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).

8.7. Authenticiteit handtekening zetten met een boordcomputerkaart

Naam Gebruik	SignDataForAuthenticity Chauffeurskaart, Ondernemerskaart, Keuringskaart, Inspectiekaart
Input gegevens	Gegevens waarover handtekening berekend moet worden
Resultaat	Handtekening \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

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.

Voor deze functie bestaat procedure 1 uit de volgende stappen:

1.: Selectie hash template en algoritme: alvorens de digitale handtekening berekend kan worden, moet het hash template geselecteerd worden en het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘AA’H. De data bij dit commando is ‘80 01 40’H (‘40’H om de algoritme identifier voor SHA-256 aan te geven).
2.: Selectie private key en algoritme: de private key van de BCT Authenticiteit moet geselecteerd worden met het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘B6’H. De data bij dit commando is ‘80 01 42 84 01 85’H (‘42’H om ‘PKCS#1 v1.5 – SHA-256’ aan te duiden en ‘85’H om het Security Data Object (SDO) van PKI.CH.AUT aan te duiden).
3.: PIN valideren: de private key van de BCT Authenticiteit mag pas gebruikt worden nadat de PIN gevalideerd is. Een eenmaal uitgevoerde PIN validatie mag – zo lang de kaart in de boordcomputer aanwezig blijft – worden ‘herbruikt’ bij elke volgende keer dat deze key gebruikt wordt.
Dit wordt gedaan met het commando Verify, waarbij P2 (de PIN reference) de waarde ‘01’H heeft. Voor de PIN wordt PIN formaat 2 gebruikt (zie onder 8.1).
4.: Berekenen van de intermediate hash (SHA256) over de input gegevens door de boordcomputerlogica. Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte bits onthouden voor de volgende stap.
NB. Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.
5.: Berekenen van de uiteindelijke hash (SHA256) door de boordcomputerkaart. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de ‘intermediate hash value’, het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het geheugen van de boordcomputerkaart (chip) achterblijven ten behoeve van de volgende en laatste stap.
6.: Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend over de in het chipgeheugen aanwezige hashwaarde en geeft de kaart die handtekening terug aan de boordcomputerlogica.
Dit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte aantal bytes in de response, moet daarbij op ‘00’H staan.

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

1.: Niet van toepassing.
2.: Gelijk aan stap 2 van procedure 1.
3.: Gelijk aan stap 3 van procedure 1.
4.: Berekenen van de volledige hash (SHA256) over de input gegevens door de boordcomputerlogica.
5.: Niet van toepassing.
6.: Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend over de in stap 4 berekende hashwaarde en geeft de kaart die handtekening terug aan de boordcomputerlogica.
Dit wordt gedaan met het commando PSO Compute Digital Signature. Daarbij moet Lc, het aantal bytes van de input data, op ‘20’H staan, het DATA veld worden gevuld met de hashwaarde uit stap 4 (32 bytes) en Le, het verwachte aantal bytes in de response, op ‘00’H staan.

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] 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).

8.8. Authenticeren boordcomputerkaart aan boordcomputer

Naam	AuthenticateCardToBCT
Gebruik	Boordcomputerkaarten
Input gegevens	Random waarde (16 bytes)
Resultaat	Handtekening \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

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:

1.: Selectie private key en algoritme: alvorens de digitale handtekening berekend kan worden, moet de private key van de BCT Authenticiteit geselecteerd worden en het te gebruiken algoritme.
Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde ‘41’H en P2 de waarde ‘A4’H. De data bij dit commando is ‘80 01 02 84 01 85’H (‘02’H om ‘C/S RSA with DSI according to PKCS#1, parameter Digestinfo’ aan te duiden en ‘85’H om het Security Data Object (SDO) van PKI.CH.AUT aan te duiden).
2.: PIN valideren: de private key van de BCT Authenticiteit mag pas gebruikt worden nadat de PIN gevalideerd is. Dit is nodig voor de eerste keer dat deze key gebruikt wordt, maar een eenmaal uitgevoerde PIN validatie mag – zo lang de kaart in de boordcomputer aanwezig blijft – worden ‘herbruikt’ bij elke volgende keer dat deze key gebruikt wordt.
Dit wordt gedaan met het commando Verify waarbij P2 (de PIN reference) de waarde ‘01’H heeft. Voor de PIN wordt PIN formaat 2 gebruikt (zie onder 8.1).
3.: De boordcomputer stuurt een Internal Authenticate commando naar de boordcomputerkaart. P1 P2 = ‘00 00’ en de data = 16 bytes random.
4.: Het antwoord hiervan wordt teruggestuurd naar de boordcomputer en deze controleert met behulp van de publieke key en een padvalidatie van het authenticiteitcertificaat of de boordcomputerkaart authentiek is.
5.: Ook de geldigheid van het authenticiteitcertificaat dient te worden gecontroleerd middels minimaal een padvalidatie en een controle van de attributen validity.notBefore en validity.notAfter.
6.: Met behulp van het eerste karakter van het kaartnummer, zoals dat in het subject.serialNumber of in de subject.title van het authenticiteitcertificaat is opgeslagen, kan de boordcomputer het kaarttype en daarmee de gebruikerssoort (bestuurder, vervoerder, werkplaats, dan wel toezichthouder) herkennen.

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.

8.9. Schrijf nieuw ActivityRecord

Naam	WriteNewActivityRecord
Gebruik	Chauffeurskaart
Input gegevens	ActivityRecord, ActivityDate
Resultaat	90h 00h OK xxh xxh Foutcode van een van de gebruikte commando’s, afhankelijk van smartcard implementatie

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

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

1.: ActivityDate de datum (JJJJMMDD) waarop de activiteit startte c.q. gebeurtenis plaatsvond;
2.: ActivityTime het tijdstip (hhmmss) waarop de activiteit startte c.q. gebeurtenis plaatsvond;
3.: ActivityType: het type activiteit / gebeurtenis;
4.: ManualBit: de handmatig-bit die weergeeft of het tijdstempel (datum en tijd) handmatig dan wel automatisch werd bepaald.

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:

1.

Selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 01’H.

2.

Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is en het verwachte aantal bytes in de response 2.

Indien PointerLastDayRecord gelijk aan ‘00 00’H is, dan bestaat er (nog) geen enkel DailyRecord:

a.: Roep de functie voor het toevoegen van een nieuw DailyRecord aan met ActivityDate als argument.
b.: Herhaal de stappen vanaf stap 2.

Indien PointerLastDayRecord niet gelijk aan ‘00 00’H is:

a.

Lees de DayRecordLength met het commando Read Binary, waarbij de offset PointerLastDayRecord is en het verwachte aantal bytes in de response 2.

b.

Lees de DayRecordDate met het commando Read Binary, waarbij de offset PointerLastDayRecord + 6 is en het verwachte aantal bytes in de response 4.

Indien DayRecordDate groter is dan ActivityDate,

dan betreft dit een foutsituatie en stopt verdere verwerking.

Indien DayRecordDate kleiner is dan ActivityDate,

dan ontbreekt de gewenste DailyRecord

(hou hier ook rekening met Dagovergangen zoals beschreven in § 5.2.7 en § 7.5):

a.: Roep de functie voor het toevoegen van een nieuw DailyRecord aan met ActivityDate als argument.
b.: Herhaal de stappen vanaf stap 2.

Indien DayRecordDate gelijk is aan ActivityDate:

a.

Lees de PointerLastSessionRecord met het commando Read Binary, waarbij de offset PointerLastDayRecord + 2 is en het verwachte aantal bytes in de response 2.

Indien de PointerLastSessionRecord gelijk aan ‘00 00’H is,

dan bevat het DailyRecord (nog) geen enkel SessionRecord:

i.: Roep de functie voor het toevoegen van een nieuw SessionRecord aan.
ii.: Herhaal de stappen vanaf het lezen van PointerLastSessionRecord.

Indien de PointerLastSessionRecord niet gelijk aan ‘00 00’H is:

i. Lees de PointerLastActivityRecord met het commando Read_Binary, waarbij de offset PointerLastSessionRecord is en het verwachte aantal bytes in de response 2.

Indien de PointerLastActivityRecord gelijk aan ‘00 00’H is,

dan wordt nu het eerste ActivityRecord aan het SessionRecord toegevoegd: zet de NewActivityPointer dus op PointerLastSessionRecord + Length (SessionRecordHeader).

Indien de PointerLastActivityRecord niet gelijk aan ‘00 00’H is,

dan bestaat er een eerder ActivityRecord:

a. Lees de LastActivityRecordHeader met het commando Read_Binary, waarbij de offset PointerLastActivityRecord is en het verwachte aantal bytes in de response 3.

b. Bepaal uit de eerste 5 bits van de LastActivityRecordHeader de LastActivityType.

Indien de LastActivityType gelijk is aan ‘Afsluiting’ of ‘Nieuwe eindtijd’,

dan moet er een nieuwe sessie worden geboekt:

i. Roep de functie voor het toevoegen van een nieuw SessionRecord aan.

ii. Herhaal de stappen vanaf het lezen van PointerLastSessionRecord.

Indien de LastActivityType gelijk is aan ‘Login’, ‘Start werk’ of ‘Start pauze’, maar de boordcomputer heeft geen kaartsessie meer actief of geblokkeerd,

dan moet er ook een nieuwe sessie worden geboekt:

i. Roep de functie voor het toevoegen van een nieuw SessionRecord aan.

ii. Herhaal de stappen vanaf het lezen van PointerLastSessionRecord.

Indien de LastActivityType gelijk is aan ‘Start werk’,

Werk dan diens Rijtijdteller voor de laatste maal bij: voer een Update Binary commando uit, waarbij de offset PointerLastActivityRecord + 3 is en de data de door de boordcomputer bijgehouden rijtijdteller; reset die laatste ook direct naar nul (0).

Zet NewActivityPointer = PointerLastActivityRecord + 6

Indien de LastActivityType NIET gelijk is aan ‘Start werk’,

Zet NewActivityPointer = PointerLastActivityRecord + 3

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.

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

1.

Bepaal eerst aan de hand van de ActivityType de lengte van het nieuwe ActivityRecord:

a.: Indien ‘(Start) werk’, dan NewActivityLength = 9;
b.: Indien ‘(Start) pauze’, dan NewActivityLength = 6;
c.: Indien anders, dan NewActivityLength = 3;

2.

Bepaal dan aan de hand van NewActivityPointer + NewActivityLength of er nog voldoende vrije ruimte resteert in EF.Driver_Activity_Data en ruim zo nodig een of meer van de oudste DailyRecords op (zie ook 5.3).

3.

Voer een Update Binary commando uit, waarbij de offset PointerLastSessionRecord is en de data NewActivityPointer (hiermee wordt PointerLastActivityRecord bijgewerkt).

4.

Voer een Update Binary commando uit, waarbij de offset NewActivityPointer is en de data bestaat uit 3 bytes:

a.: 5 bits ActivityType: het als argument gegeven type activiteit / gebeurtenis;
b.: 1 bit ManualBit: de als argument gegeven handmatig-bit;
c.: 1 bit RijdenBit: de bit die aangeeft of de auto NU rijdt (‘1’B) of stilstaat (‘0’B);
d.: 17 bits ActivityTime: het als argument gegeven (start)tijdstip.

5.

Indien de nieuwe activiteit een ‘(Start) werk’ of ‘(Start) pauze’ betreft:

a.

Voer een Update Binary commando uit, waarbij de offset PointerLastSessionRecord + 2 is en de data NewActivityPointer (hiermee wordt PointerLastPWActivityRecord bijgewerkt);

b.

Voer een Update Binary commando uit, waarbij de offset NewActivityPointer + 3 is en de data bestaat uit 3 bytes gelijk aan ‘00 00 00’H;

c.

Reset op de boordcomputer de tijdsduurteller naar nul (0) seconden;

d.

Indien de nieuwe activiteit een ‘(Start) werk’ betreft:

i.: Voer een Update Binary commando uit, waarbij de offset NewActivityPointer + 6 is en de data bestaat uit 3 bytes gelijk aan ‘00 00 00’H;
ii.: Reset op de boordcomputer de rijtijdteller naar nul (0) seconden.

6.

Voer een Update Binary commando uit met offset is PointerLastDayRecord en als data DayRecordLength + NewActivityLength (hiermee wordt DayRecordLength bijgewerkt).

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

8.10. Schrijf nieuw SessionRecord

Naam	WriteNewSessionRecord
Gebruik	Chauffeurskaart
Input gegevens	StartSessionData
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

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)

Hiervoor moeten de volgende stappen doorlopen worden:

1.

2.

Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is en het verwachte aantal bytes in de response 2. Dit levert de pointer voor het meest recente DailyRecord (Pointer_1).

3.

Lees in deze DailyRecord de DayRecordLength met Read Binary, de offset is Pointer_1 en het verwachte aantal bytes in de response is 2. Dit levert de lengte van dit DailyRecord (Length_1). Daarmee wordt de pointer waar het SessionRecord weggeschreven kan worden: Pointer_2 = Pointer_1 + Length_1.

4.

Maak een nieuw SessionRecord (alleen de kop) aan met

–: PointerLastActivityRecord = ‘00 00’H (0).
–: PointerLastPWActivityRecord = ‘00 00’H (0).
–: SignatureDateTime = ‘00000000 000000’H.
–: SessionSignature = 256 willekeurige bytes.
–: SessionCreationDateTime = de huidige datum en tijd volgens de BCT klok in BCD en geformatteerd als ‘JJJJMMDDhhmmss’H.
–: SystemCardNumber, Kenteken, CompanyCardNumber en Pnummer zoals die in de boordcomputer bekend zijn.

Voer een Update Binary commando uit, waarbij de offset Pointer_2 is en de data de weg te schrijven SessionRecord kop.

5.

Verhoog DayRecordLength door een Update Binary commando met offset is Pointer_1 en als data Length_1 + 299.

6.

Wijzig de PointerLastSessionRecord door een Update Binary commando, waarbij de offset Pointer_1 + 2 is en de data Pointer_2.

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

Naam	WriteNewDailyRecord
Gebruik	Chauffeurskaart
Input gegevens	Datum (BCD)
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

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:

1.

2.

Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is en het verwachte aantal bytes in de response 2. Dit levert de pointer voor de meest recente DailyRecord (Pointer_1).

3.

Lees in deze DailyRecord de DayRecordLength met Read Binary, offset is Pointer_1 en het verwachte aantal bytes in de response is 2. Dit levert de lengte van het DailyRecord (Length_1).

Daarmee is de pointer bekend waar de nieuwe DailyRecord weggeschreven kan worden: Pointer_2 = Pointer_1 + Length_1.

4.

Maak een nieuwe DailyRecord kop aan met

–: DayRecordLength = ‘00 0A’H (10)
–: PointerLastSessionRecord = ‘00 00’H (0)
–: PreviousDayRecordLength = Length_1
–: DayRecordDate = datum in BCD formaat.

en voer een Update Binary commando uit, waarbij de offset Pointer_2 is en de data de weg te schrijven DailyRecord kop.

5.

Verzet de PointerLastDayRecord naar het nieuwe DailyRecord met een Update Binary, waarbij de offset 2 is en de data Pointer_2 is.

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

Naam	SelectLastDailyRecord
Gebruik	Chauffeurskaart
Input gegevens	Geen
Resultaat	DailyRecordPointer \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

Hiervoor moeten de volgende stappen doorlopen worden:

1.: Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 01’H.
2.: Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is en het verwachte aantal bytes in de response 2. Dit levert de pointer voor de meest recente DailyRecord (DailyRecordPointer).

8.13. Selecteer oudste (eerste) DailyRecord

Naam	SelectOldestDailyRecord
Gebruik	Chauffeurskaart
Input gegevens	Geen
Resultaat	DailyRecordPointer \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

Hiervoor moeten de volgende stappen doorlopen worden:

1.: Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 01’H.
2.: Lees de PointerOldestDayRecord met het commando Read Binary, waarbij de offset 0 is en het verwachte aantal bytes in de response 2. Dit levert de pointer voor de oudst bekende DailyRecord (DailyRecordPointer).

8.14. Selecteer vorige DailyRecord

Naam	SelectPreviousDailyRecord
Gebruik	Chauffeurskaart
Input gegevens	CurrentDailyRecordPointer (bereik ‘00 14’H t/m (Length_EF.Driver_Activitiy_Data – 1)) PointerOldestDayRecord
Resultaat	DailyRecordPointer \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

Hiervoor moeten de volgende stappen doorlopen worden:

1.: Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 01’H.
2.: Indien PointerOldestDayRecord niet was meegegeven als inputgegeven, lees dan PointerOldestDayRecord met het commando Read Binary met offset = 0 en het verwachte aantal bytes in de respons 2.
3.: Als CurrentDailyRecordPointer gelijk is aan PointerOldestDayRecord, dan is de geselecteerde DailyRecord de eerste (oudste) en is er geen vorige DailyRecord aanwezig. Breek dan deze functie af.
4.: Zet Pointer_1 = CurrentDailyRecordPointer + 4 om de pointer naar PreviousDayRecordLength te verkrijgen.
5.: Als Pointer_1 >= Length_EF.Driver_Activity_Data herbereken dan de positie met de formule: Pointer_1 = (Pointer_1 modulo Length_EF.Driver_Activity_Data) + ‘00 14’H (20)
6.: Als nu Pointer_1 precies gelijk is aan (Length_EF.Driver_Activity_Data – 1), dan staat de MSB van PreviousDayRecordLength in de laatste byte van EF.Driver_Activity_Data en de LSB op positie ‘00 14’H (20). Voer dan twee keer het commando Read Binary uit met het verwachte aantal bytes in de response gelijk aan 1; één keer met offset = (Length_EF.Driver_Activity_Data – 1) voor Length_1_MSB en één keer met offset = 20 (‘00 14’H) voor Length_1_LSB. Bereken dan PreviousDayRecordLength = 256 x Length_1_MSB + Length_1_LSB.
7.: Als ‘00 14’H <= Pointer_1 < (Length_EF.Driver_Activity_Data – 1) is, dan kan PreviousDayRecordLength in één keer worden uitgelezen met het commando Read Binary met offset = Pointer_1 en het verwachte aantal bytes in de response 2.
8.: Als PreviousDayRecordLength gelijk is aan ‘00 00’H, dan is er geen vorig DailyRecord en dan moet de functie hier worden afgebroken.
9.: Bereken nu voorlopig Pointer_2 = CurrentDailyRecordPointer – PreviousDayRecordLength.
10.: Indien Pointer_2 kleiner is dan ‘00 14’H (20), voer dan nog de volgende correctie uit:
Pointer_2 = Length_EF.Driver_Activity_Data – (20 – Pointer_2).
11.: Geef nu de gevraagde DailyRecordPointer = Pointer_2 terug.

8.15. Selecteer volgende DailyRecord

Naam	SelectNextDailyRecord
Gebruik	Chauffeurskaart
Input gegevens	CurrentDailyRecordPointer (bereik ‘00 14’H t/m (Length_EF.Driver_Activitiy_Data – 1)) PointerLastDayRecord
Resultaat	DailyRecordPointer \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

Hiervoor moeten de volgende stappen doorlopen worden:

1.: Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 01’H.
2.: Indien PointerLastDayRecord niet was meegegeven als inputgegeven, lees dan PointerLastDayRecord met het commando Read Binary met offset = 2 en het verwachte aantal bytes in de respons 2.
3.: Als CurrentDailyRecordPointer gelijk is aan PointerLastDayRecord, dan is de geselecteerde DailyRecord de laatste (meest recente) en is er geen volgende DailyRecord aanwezig. Breek dan deze functie af.
4.: Zet Pointer_1 = CurrentDailyRecordPointer om de pointer naar DayRecordLength te verkrijgen.
5.: Als Pointer_1 precies gelijk is aan (Length_EF.Driver_Activity_Data – 1), dan staat de MSB van DayRecordLength in de laatste byte van EF.Driver_Activity_Data en de LSB op positie ‘00 14’H (20). Voer dan twee keer het commando Read Binary uit met het verwachte aantal bytes in de response gelijk aan 1; één keer met offset = (Length_EF.Driver_Activity_Data – 1) voor Length_1_MSB en één keer met offset = 20 (‘00 14’H) voor Length_1_LSB. Bereken dan DayRecordLength = 256 x Length_1_MSB + Length_1_LSB.
6.: Als ‘00 14’H <= Pointer_1 < (Length_EF.Driver_Activity_Data – 1) is, dan kan DayRecordLength in één keer worden uitgelezen met het commando Read Binary met offset = Pointer_1 en het verwachte aantal bytes in de response 2.
7.: Bereken nu voorlopig Pointer_2 = CurrentDailyRecordPointer + DayRecordLength.
8.: Als Pointer_2 >= Length_EF.Driver_Activity_Data herbereken dan de positie met de formule: Pointer_2 = (Pointer_2 modulo Length_EF.Driver_Activity_Data) + ‘00 14’H (20)
9.: Geef nu de gevraagde DailyRecordPointer = Pointer_2 terug.

8.16. Lees huidige / geselecteerde DailyRecord

Naam	ReadSelectedDailyRecord
Gebruik	Chauffeurskaart
Input gegevens	CurrentDailyRecordPointer (bereik ‘00 14’H t/m (Length_EF.Driver_Activitiy_Data – 1))
Resultaat	Data \|\| ‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van de implementatie

Hiervoor moeten de volgende stappen doorlopen worden:

1.

Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 01’H.

2.

Zet Pointer_1 = CurrentDailyRecordPointer om de pointer naar DayRecordLength te verkrijgen.

3.

Als Pointer_1 precies gelijk is aan (Length_EF.Driver_Activity_Data – 1), dan staat de MSB van DayRecordLength in de laatste byte van EF.Driver_Activity_Data en de LSB op positie ‘00 14’H (20). Voer dan twee keer het commando Read Binary uit met het verwachte aantal bytes in de response gelijk aan 1; één keer met offset = (Length_EF.Driver_Activity_Data – 1) voor Length_1_MSB en één keer met offset = 20 (‘00 14’H) voor Length_1_LSB. Bereken dan DayRecordLength = 256 x Length_1_MSB + Length_1_LSB.

4.

Als ‘00 14’H <= Pointer_1 < (Length_EF.Driver_Activity_Data – 1) is, dan kan DayRecordLength in één keer worden uitgelezen met het commando Read Binary met offset = Pointer_1 en het verwachte aantal bytes in de response 2.

5.

Onthou de DayRecordLength nu voorlopig als Length_1.

6.

Voer Read Binary commando’s uit tot Length_1 bytes gelezen zijn. Per Read Binary kan een maximaal aantal bytes gelezen worden. Dit maximum is van een aantal factoren afhankelijk (zie referentie [7]) en wordt hier max_read genoemd. De eerste Read Binary heeft als offset Pointer_1 en het verwachte aantal bytes ‘00’H (in het geval dat Length_1 < max_read, dan wordt het verwachte aantal bytes Length_1). Voor iedere volgende Read Binary wordt de offset met max_read verhoogd. Het verwachte aantal bytes in de response is ‘00’H, behalve bij de laatste Read Binary, daar is het Length_1 modulo max_read.

NB. Voorafgaand aan elke Read Binary moet worden gecontroleerd of de te lezen bytes verder zouden doorlopen dan EF.Driver_Activity_Data groot is. In zo’n geval dient de betreffende Read Binary in twee slagen te worden uitgevoerd:

a.: De eerste keer met een ongewijzigde offset en een aangepast verwacht aantal_bytes (aantal_bytes_a), zijnde (Length_EF.DriverActivity_Data – offset_a);
b.: De tweede keer met een gecorrigeerde offset gelijk aan 20 (‘00 14’H) en het restant van het verwachte aantal_bytes, zijnde aantal_bytes_b = aantal_bytes – aantal_bytes_a.
c.: Hierna kan vanaf offset (‘00 14’H + aantal_bytes_b) worden vervolgd met de eerstvolgende reguliere Read Binary.

8.17. Controleer EF.Driver_Activity_Data structuur

Naam	CheckEFDriverActivityStructure
Gebruik	Chauffeurskaart
Input gegevens	Geen
Resultaat	00 OK 01 Invalid Pointer Value 02 Wrong Length 03 Length Not Matching 04 Record Not Closed 05 Invalid PW Pointer 06 DayRecordLength Wrong 07 DriverCardNumber was overwritten

Hiervoor moeten de volgende stappen doorlopen worden:

1.

2.

Lees PointerOldestDayRecord en PointerLastDayRecord.

3.

Controleer:

20 (‘00 14’H) <= PointerOldestDayRecord < Length_EF.Driver_Activity_Data of

PointerOldestDayRecord == 0.

Wanneer dit niet het geval is, geef dan ‘Invalid Pointer Value’ terug.

4.

Controleer:

20 (‘00 14’H) <= PointerLastDayRecord < Length_EF.Driver_Activity_Data of

PointerLastDayRecord == 0.

Wanneer dit niet het geval is, geef dan ‘Invalid Pointer Value’ terug.

5.

Controleer of DriverCardNumber gelijk is aan de eerste 20 bytes (karakters) van het subject.SerialNumber van het authenticiteitcertificaat.

Wanneer dit niet het geval is, geef dan ‘DriverCardNumber was overwritten’ terug (en herstel de fout).

6.

Controleer de DailyRecord structuur (voorwaarts):

a.

Ga met de PointerOldestDayRecord naar de oudste DailyRecord.

b.

Controleer of PreviousDayRecordLength = ‘00 00’H.

Wanneer dit niet het geval is, geef dan ‘Wrong Length’ terug.

c.

Bepaal mbv de DayRecordLength de positie van het volgende DailyRecord.

d.

Controleer of de PreviousDayRecordLength in dit record gelijk is aan de DayRecordLength van het vorige record.

Wanneer dit niet het geval is, geef dan ‘Length Not Matching’ terug.

e.

Herhaal de vorige 2 punten totdat

–: het beginpunt van een record gelijk is aan PointerLastDayRecord, of
–: de referenties DayRecordLength/PreviousDayRecordLength niet meer kloppen. Beschouw dan het DailyRecord waar dit nog wel correct was als laatste record. Pas in dit geval ook de PointerLastDayRecord aan.

7.

Controleer de DailyRecord structuur (terugwaarts):

a.

Ga met de PointerLastDayRecord naar de laatste DailyRecord.

b.

Bepaal mbv de PreviousDayRecordLength de positie van het vorige DailyRecord.

c.

Controleer of de DayRecordLength in dit record gelijk is aan de PreviousDayRecordLength van het volgende record.

Wanneer dit niet het geval is, geef dan ‘Length Not Matching’ terug.

d.

Herhaal de vorige 2 punten totdat

–: het beginpunt van een record gelijk is aan PointerOldestDayRecord, of
–: de referenties DayRecordLength/PreviousDayRecordLength niet meer kloppen.

In het eerste geval moet de PreviousDayRecordLength = ‘00 00’H. Wanneer dit niet het geval is, geef dan ‘Wrong Length’ terug.

Beschouw in het tweede geval het DailyRecord waar dit nog wel correct was als oudste record. Pas in dat geval ook PointerOldestDayRecord en PreviousDayRecordLength aan.

8.

Controleer de laatste DailyRecord:

a.: Ga met de PointerLastDayRecord naar de laatste DailyRecord.
b.: Ga naar het eerste SessionRecord in het DailyRecord (PointerLastDayRecord + 10).
c.: Controleer of dit SessionRecord het laatste is door de beginpositie hiervan te vergelijken met de PointerLastSessionRecord.
d.: Is dit niet het laatste SessionRecord, controleer dan met PointerLastActivityRecord of de laatste activiteit een ‘Afsluiting’ of een ‘Dagovergang’ is. Is dit niet het geval, geef dan ’Record Not Closed’ terug.
Ga met behulp van PointerLastActivityRecord + de lengte van de laatste activiteit naar het volgende SessionRecord en herhaal het vorige punt.
e.: Controleer in het laatste SessionRecord of de PointerLastPWActivityRecord verwijst naar een ‘Start pauze’ of ‘Start werk’ activiteit.
Is dit niet het geval, geef dan een ‘Invalid PW Pointer’ terug.
f.: Controleer of de lengte van alle SessionRecords in dit DailyRecord samen gelijk is aan de DayRecordLength – 10.
Is dit niet het geval, geef dan ‘DayRecordLength Wrong’ terug.

9.

Bij alle controles en leesacties moet rekening gehouden worden met de lengte van EF.Driver_Activity_Data.

8.18. Controleren op opgeslagen boordcomputercertificaat

Naam	IsCertificatePresent
Gebruik	Chauffeurskaart
Input gegevens	Systeemkaartnummer
Resultaat	Recent\|\|‘90 00’H Certificaat aanwezig met ranking Recent (‘01’H-‘03’H) ‘6A 82’H Certificaat niet aanwezig op chauffeurskaart

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:

1.: Selecteer EF.BCT_Certificates met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 02’H.
2.: Lees Index_1 t/m Index_3 met het commando Read Binary met offset = 3 (‘00 03’H) en het aantal verwachte bytes in de response 21 (‘15’H), en controleer of Index_x overeenkomt met het systeemkaartnummer.
Zo ja, lees dan de bijbehorende Rank_x met het commando Read Binary met offset = de offset voor Rank_x en het aantal verwachte bytes in de response 1 en geef het resultaat || ‘90 00’H terug.
Komt het systeemkaartnummer niet voor, geef dan de foutcode dat het certificaat niet gevonden is.

8.19. Volgorde bijwerken van opgeslagen boordcomputercertificaten

Naam	UpdateRanking
Gebruik	Chauffeurskaart
Input gegevens	Systeemkaartnummer
Resultaat	‘90 00’H OK ‘6A 82’H Certificaat niet aanwezig op chauffeurskaart

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:

1.

Selecteer EF.BCT_Certificates met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 02’H.

2.

Lees Index_1 t/m Index_3 met het commando Read Binary met offset = 3 (‘00 03’H) en het aantal verwachte bytes in de response 21 (‘15’H) en controleer of één hiervan overeenkomt met het systeemkaartnummer.

Zo niet, geef dan de foutcode terug dat het bijbehorende certificaat niet aanwezig is.

Zo ja, lees dan de bijbehorende Rank_Highest

–: Voor Rank_1 t/m Rank_3, met uitzondering van Rank_Highest: als de inhoud van Rank_x < inhoud Rank_Highest en > 0, verhoog dan de inhoud van Rank_x dan met 1. Maak Rank_Highest = ‘01’.
–: Geef ‘90 00’H terug.

8.20. Geef opgeslagen boordcomputercertificaat

Naam	GetCertificate
Gebruik	Chauffeurskaart
Input gegevens	Systeemkaartnummer
Resultaat	Certificate\|\|‘90 00’H OK ‘6A 82’H Certificaat niet aanwezig op chauffeurskaart

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

Voor deze functie moeten de volgende stappen doorlopen worden:

1.: Selecteer EF.BCT_Certificates met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 02’H.
2.: Lees Index_1 t/m Index_3 met het commando Read Binary met offset = 3 (‘00 03’H) en het aantal verwachte bytes in de response 21 (‘15’H) en controleer of één hiervan overeenkomt met het systeemkaartnummer.
Zo niet, geef dan de foutcode terug dat het bijbehorende certificaat niet aanwezig is.
Zo ja, ga dan door met stap 3.
3.: Voer Read Binary commando’s uit tot Length_1 (de certificaatlengte) bytes gelezen zijn. Per Read Binary kan een maximaal aantal bytes gelezen worden. Dit maximum is van een aantal factoren afhankelijk (zie referentie [7]) en wordt hier max_read genoemd. De eerste Read Binary heeft als offset de offset voor Certificate_x en het verwachte aantal bytes ‘00’H (in het geval dat Length_1 < max_read, dan wordt het verwachte aantal bytes Length_1). Voor iedere volgende Read Binary wordt de offset met max_read verhoogd. Het verwachte aantal bytes in de response is ‘00’H, behalve bij de laatste Read Binary, daar is het Length_1 modulo max_read.
4.: geef het resultaat || ‘90 00’H terug.

8.21. Sla boordcomputercertificaat op

Naam	StoreCertificate
Gebruik	Chauffeurskaart
Input gegevens	Systeemkaartnummer, certificaat
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van smartcard implementatie

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.

Voor deze functie moeten de volgende stappen doorlopen worden:

1.: Selecteer EF.BCT_Certificates met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 02’H.
2.: Lees Rank_1 t/m Rank_3 met het commando Read Binary met offset = 0 en het aantal verwachte bytes in de response 3, en zoek de eerste waarde ‘00’ of ‘03’. Dit is Rank_target.
3.: Sla het systeemkaartnummer op in Index_target met het commando Update Binary met offset = de offset voor Index_target en het systeemkaartnummer als data.
4.: Sla het certificaat op in Certificate_target met een reeks Update Binary commando’s met de offset van het eerste commando gelijkgezet aan de offset voor Certificate_target en telkens de volgende max_write bytes van het certificaat als data. Indien het certificaat korter is dan de gereserveerde lengte voor het certificaat, vul bij het laatste Update Binary commando de rest dan aan met nullen (‘00’).
NB. de hoogte van max_write is van een aantal factoren afhankelijk (zie referentie [7]).
5.: Voor Rank_1 t/m Rank_3, met uitzondering van Rank_target: als de inhoud van Rank_x > 0, verhoog de inhoud dan met 1. Maak Rank_target = ‘01’.
6.: Geef ‘90 00’H terug.

8.22. Geef meest recente DownloadLog

Naam	GetLastDownloadLog
Gebruik	Chauffeurskaart
Input gegevens	geen
Resultaat	DownloadLog \|\| ‘90 00’H OK ‘6A 82’H DownloadLog niet aanwezig op chauffeurskaart ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van smartcard implementatie

Voor deze functie moeten de volgende stappen doorlopen worden:

1.: Selecteer EF.BCT_Certificates met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 02’H.
2.: Lees IndexOldestDL met het commando Read Binary met offset = ‘18 B4’H en het aantal verwachte bytes in de response 1
3.: Indien de gelezen waarde ‘00’H is, zet dan de IndexNewestDL (variabele in het geheugen) op 7, anders wordt de IndexNewestDL gelijkgesteld aan IndexOldestDL – 1.
4.: Bereken nu de offset van de (meest recente) DownloadLog_X behorende bij IndexNewestDL als volgt: offset_x = ‘18 B5’H + 33 x IndexNewestDL.
5.: Lees de aangeduide DownloadLog_X met het commando Read Binary met offset = offset_x en het verwachte aantal bytes in de respons 33.
6.: Indien de respons uit 33 nullen (‘00’H) bestaat, geef dan de foutcode terug dat er geen DownloadLog records aanwezig zijn, retourneer anders de gelezen respons || ‘90 00’H.

8.23. Sla DownloadLog op

Naam	StoreDownloadLog
Gebruik	Chauffeurskaart
Input gegevens	DownloadLog
Resultaat	‘90 00’H OK ‘xx xx’H Foutcode van een van de gebruikte commando’s, afhankelijk van smartcard implementatie

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:

1.: Selecteer EF.BCT_Certificates met het commando Select met P1P2 = ‘04 0C’H en data = ‘E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E’H, gevolgd door het commando Select met P1P2 = ‘02 0C’H en data = ‘44 02’H.
2.: Lees IndexOldestDL met het commando Read Binary met offset = ‘18 B4’H en het aantal verwachte bytes in de response 1
3.: Sla het gegeven DownloadLog op in DownloadLogs met het commando Update Binary met offset = ‘18 B5’H + 33 x IndexOldestDL. en het DownloadLog als data.
4.: Indien de gelezen IndexOldestDL ‘07’H is, zet dan index_new = ‘00’H, zet anders index_new op IndexOldestDL + 1.
5.: Sla de bijgewerkte index op met het commando Update Binary met offset = ‘18 B4’H en index_new (1 byte) als data.
6.: Geef ‘90 00’H terug.

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 Class byte (CLA),
•: een Instruction byte (INS),
•: een Parameter 1 byte (P1),
•: een Parameter 2 byte (P2),
•: een Lengte gegevens byte (Lc) in het geval er gegevens zijn,
•: gegevens (Data), optioneel
•: een verwachte lengte antwoord byte (Le), optioneel.

Een antwoord bestaat uit:

•: gegevens (Data), optioneel
•: statuswoorden (SW1-SW2)

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].

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:

1.: De Master File (MF)
te selecteren met INS P1 P2 Lc Data = ‘A0 00 0C 02 3F00’H
2.: De Application DF (DF.CIA)
te selecteren met INS P1 P2 Lc Data = ‘A4 04 0C 0F E828BD080FA000000167455349474E’H

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

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

1.

Met een expliciete SELECT op basis van de 2-bytes file identifier (FID):

INS P1 P2 Lc Data = ‘A4 02 0C 02 (FID)

2.

Met een expliciete SELECT inclusief opvragen van de file control parameters:

INS P1 P2 Lc Data Le = ‘A4 02 04 02 (FID) 00

3.

Met een impliciete SELECT als onderdeel van het data handling commando:

a.: Voor offsets < 256:
INS = INS met bit1 = 0 (EVEN instruction)
P1 = bit8 t/m bit6 = 100b || bit5 t/m bit1 = short EF id
P2 = offset [0...255]
Lc Data Le = afhankelijk van de instructie
b.: Voor 0 <= offsets < ∞:
INS = INS met bit1 = 1 (ODD instruction)
P1P2 = bit16 t/m bit6 = 0...0b || bit5 t/m bit1 = short EF id
of
P1P2 = file identifier
Lc = de lengte van Data
Data = minimaal een ‘offset data object’ met tag = 54h
Le = afhankelijk van de instructie

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 4^e t/m 7^e byte (willekeurig voorbeeld) van EF.BCT_Certificates kunnen worden uitgelezen:

INS	P1	P2	Lc	Data	Le	Betekenis
A4	04	0C	0F	E828BD080F A000000167 455349474E		Selecteer de DF.CIA obv de AID
B0	94	03			04	Impliciete SELECT van SFID = 14h, gevolgd door uitlezen van 4 bytes vanaf offset 3

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

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

INS	P1	P2	Lc	Data	Le	Betekenis
B0	1F	3F			33	Lees 51 (33h) bytes vanaf offset 7999 (1F3Fh) uit de momenteel geselecteerde EF.

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

Als voorbeeld van efficiënt coderen volgt hier de kleinste commandoreeks waarmee de 40000^e t/m 40001^e byte en dan de 40002^e t/m 40003^e 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):

INS	P1	P2	Lc	Data	Le	Betekenis
B1	00	13	04	54 02 9C3F	02	Selecteer de EF met short file identifier (SFI) 13h en lees 2 (02h) bytes vanaf offset 39999 (9C3Fh) uit die EF.
B1	00	00	04	54 02 9C41	02	Lees de volgende 2 bytes uit diezelfde EF.

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:

INS	P1	P2	Lc	Data	Le	Betekenis
A4	02	04	02	4401	00	A4 = SELECT 02 = selecteer een EF 04 = vraag ook om FCP 02 = lengte van Data 4401 = EF file identifier 00 = retourneer alle beschikbare bytes

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

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

De betekenis van deze respons is hieronder uitgewerkt:

Bytes			Betekenis
62 1B			Hier volgen 27 (1Bh) bytes met FCP informatie
	80 02 xx xx		De lengte van de file is gecodeerd in 2 bytes en bedraagt xxxx
	82 01 01		Het file descriptor byte is 01h; het betreft een transparante EF
	83 02 44 01		De file identifier van deze file is 4401h
	88 01 98		De short file identifier van deze file is 13h (deze is gecodeerd in b8 t/m b4 van het derde byte, omdat b3 t/m b1 0 zijn): 10011000
	A1 08		Hier volgen 8 bytes met proprietary security attributen (dit zijn voorbeelden. Voor daadwerkelijke invulling zie Referentie [7])
		8C 02 01 00	2 bytes met proprietary security attributen voor contactchip
		9C 02 01 00	2 bytes met proprietary security attributen voor contactloze chip
	8A 01 05		Het life cycle status byte van deze EF is 05h (operational state – activated)
90 00			SW1-SW2 geeft ‘Normal processing’ aan

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

10. Referenties

De onderstaande referenties worden in dit document gebruikt:

[1]: [1] ISO/IEC 7816-4 Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange. Edition: 2005.
[2]: ISO/IEC 7816-8 Identification cards – Integrated circuit cards – Part 8: Commands for security operations. Edition: 2004.
[3]: ISO/IEC 7816-15 Identification cards – Integrated circuit cards with contacts – Part 15: Cryptographic information application (2004-01-15).
[4]: ISO/IEC 9797-1 Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher.
[5]: [9] ISO/IEC 9797-2 Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function.
[6]: [11] CWA 14890-1 Application Interface for smart cards used as Secure Signature Creation Devices – Part 1: Basic requirements. March 2004.
[7]: [13] European card for e-services and national e-ID applications (IAS ECC) – Technical Specifications – Revision 1.0.1 – February 2009.
[8]: BCT Kaartstructuur Systeemkaart v1.6. Inspectie Verkeer en Waterstaat.
[9]: BCT Kaartstructuur Chauffeurskaart v1.6. Inspectie Verkeer en Waterstaat.
[10]: BCT Kaartstructuur Ondernemerskaart v1.6. Inspectie Verkeer en Waterstaat.
[11]: BCT Kaartstructuur Keuringskaart v1.6. Inspectie Verkeer en Waterstaat.
[12]: BCT Kaartstructuur Inspectiekaart v1.6. Inspectie Verkeer en Waterstaat.
[13]: BCT Certificaatprofielen en CRL model BCT kaarten v1.2. Inspectie Verkeer en Waterstaat.
[14]: Regeling specificaties en typegoedkeuring boordcomputer taxi. Inspectie Verkeer en Waterstaat.
[15]: Certificaatprofielen BCT Kaart CA's v1.0. Inspectie Verkeer en Waterstaat.
[16]: Generieke certificaatprofielen MinVenW PKIoverheid CSP v1.1, Ministerie van Verkeer en Waterstaat

11. Begrippen en afkortingen

De onderstaande begrippen en afkortingen worden in dit document gebruikt:

ATR	Antwoord op terugstellen
BCT	BoordComputer Taxi
CBC	Cipher Block Chaining
CC	Cryptografische controlesom
CG	Cryptogram
CH	Commando-kop
CLA	Klasse byte in CH
D()	Decodering met DES
DES	Data encryptie standaard
DO	Gegevensobject
E()	Codering met DES
Hash	Hashing
INS	Instructie byte in CH
IVW	Inspectie Verkeer en Waterstaat
Lc	Lengte van de data in een commando
Le	Lengte van het verwachte antwoord in een commando
MAC	Message Authentication Code
PB	Padding bytes
PI	Padding indicatorbyte (voor gebruik bij cryptogram voor vertrouwelijkheid DO)
PIN	Persoonlijk identificatie nummer
PKCS	Public Key Cryptography Standards
PUK	PIN unblock key
PV	Ongecodeerde waarde
P1	Parameter 1 byte in CH
P2	Parameter 2 byte in CH
RSA	Asymmetrisch encryptiealgoritme
SSC	Zendsequentieteller
SM	Beveiligde overbrenging
SW	Status woord (2 bytes) in een antwoord
TLV	Label – lengte – waarde
XOR	Exclusieve disjunctie
‘xx’B	Bit waarde
‘xx’H	Hexadecimale waarde
3DES	Drievoudig DES algoritme
\|\|	Verbindingsoperator

Bijlage A. Scenario’s kaartsessies

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

A.1. Scenario 1: Normale kaartsessie

•: De kaartsessie wordt begonnen met het inbrengen van de chauffeurskaart in de boordcomputer.
•: Er zijn geen wijzigingen of aanvullingen sinds de vorige kaartsessie.
•: Diverse activiteiten vinden plaats en worden op de chauffeurskaart opgeslagen.
•: De kaartsessie wordt normaal afgesloten waarna de chauffeurskaart uit de boordcomputer genomen kan worden.

RSTGBTAXI_stc-2015-9656_BIJL4_05

Activiteit	Tijdstip	Handm.
Login	8:00:00	‘0’B
Start werk	8:00:00	‘0’B
Start pauze	10:30:00	‘0’B
Start werk	11:00:00	‘0’B
Afsluiting	13:15:00	‘0’B

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

•: Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint. Hierna wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer genomen.
•: Na het opnieuw inbrengen van de chauffeurskaart constateert de boordcomputer dat de vorige sessie na een ‘Start pauze’ werd afgesloten. Omdat een arbeidsperiode hiermee lijkt te eindigen met een pauze, wordt de chauffeur hier extra op geattendeerd. Sowieso vraagt de boordcomputer of er nog activiteiten moeten worden toegevoegd sinds de laatste activiteit. De chauffeur besluit zijn bezigheden (pauze genieten) tussen die laatste afsluiting en het huidige inlogmoment handmatig te boeken, om te voorkomen dat hij de periode tussen afsluiten en inloggen niet kan verantwoorden.
•: Omdat bij het inbrengen van de chauffeurskaart standaard een ‘Start werk’ toegevoegd wordt, hoeft de chauffeur, na de handmatige toevoeging, het hervatten van werk niet expliciet aan te geven.

RSTGBTAXI_stc-2015-9656_BIJL4_06

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start pauze	13:14:30	‘0’B	n
Afsluiting	13:15:00	‘0’B	n

Start pauze	13:15:00	‘1’B	n+1
Login	13:45:00	‘0’B	n+1
Start werk	13:45:00	‘0’B	n+1
...			n+1

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

•: Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint. Hierna wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer genomen.
•: Na het opnieuw inbrengen van de chauffeurskaart constateert de boordcomputer dat de vorige sessie na een ‘Start pauze’ werd afgesloten. Omdat een arbeidsperiode hiermee lijkt te eindigen met een pauze, wordt de chauffeur hier extra op geattendeerd. Sowieso vraagt de boordcomputer of er nog activiteiten moeten worden toegevoegd sinds de laatste activiteit. De chauffeur besluit zijn bezigheden (pauze genieten) na die laatste afsluiting handmatig te boeken.
•: De werkzaamheden waren in werkelijkheid echter eerder gestart dan het moment van inloggen, daarom wordt voorafgaand aan het inlogmoment ook nog handmatig een ‘Start werk’ toegevoegd. De pauze stopt hiermee dus eerder dan het inlogmoment.
•: De boordcomputer boekt zelf ook nog een ‘Start werk’ na de inlogboeking.

RSTGBTAXI_stc-2015-9656_BIJL4_07

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start pauze	13:14:30	‘0’B	n
Afsluiting	13:15:00	‘0’B	n

Start pauze	13:15:00	‘1’B	n+1
Start werk	13:30:00	‘1’B	n+1
Login	13:45:00	‘0’B	n+1
Start werk	13:45:00	‘0’B	n+1
...			n+1

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

•: Na de laatste activiteit wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer genomen.
•: Bij het inbrengen van de chauffeurskaart in de boordcomputer de volgende dag, wordt gevraagd of er nog activiteiten sinds het einde van de vorige kaartsessie zijn geweest. Dat is het geval, want er zijn de vorige dag, na het verlaten van de auto, nog andere werkzaamheden verricht. Dit wordt eerst toegevoegd.
•: Daarna kunnen de activiteiten voor de nieuwe dag beginnen.

RSTGBTAXI_stc-2015-9656_BIJL4_08

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start werk	13:00:00	‘0’B	n
Afsluiting	15:15:00	‘0’B	n

Start werk	15:15:00	‘1’B	n+1
Nieuwe eindtijd	16:15:00	‘1’B	n+1

Hier wordt ook een nieuw DailyRecord met een eerste SessionRecord ingevoegd

Login	9:00:00	‘0’B	n+2
Start werk	9:01:00	‘0’B	n+2
...			n+2

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

•: Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint. Hierna wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer genomen.
•: Later blijkt dat de pauze niet doorgegaan is en dat in plaats daarvan andere werkzaamheden verricht zijn tot het huidige tijdstip.
•: Bij het inbrengen van de chauffeurskaart in de boordcomputer moet dit gecorrigeerd worden. De boordcomputer zal de bestuurder attenderen op het feit dat de laatstgeboekte en afgesloten activiteit een pauze was. Na het bevestigen van de vraag of er nog handmatig activiteiten moeten worden toegevoegd, kan de chauffeur een ‘Start werk’ laten ingaan op hetzelfde moment dat de ‘Start pauze’ begon. De pauze wordt hiermee in feite overschreven door andere werkzaamheden.

RSTGBTAXI_stc-2015-9656_BIJL4_09

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start pauze	16:40:00	‘0’B	n
Afsluiting	16:41:00	‘0’B	n

Start werk	16:40:00	‘1’B	n+1
Login	17:10:00	‘0’B	n+1
Start werk	17:11:00	‘0’B	n+1
...			n+1

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

•: Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint. De chauffeur neemt de kaart uit zonder dat de kaartsessie is afgesloten. Hierop blokkeert de boordcomputer deze kaartsessie.
•: Enige tijd later (binnen de 60 minuten) wordt de chauffeurskaart weer in de boordcomputer ingebracht. Omdat het dezelfde kaart is als waarvan de kaartsessie geblokkeerd is, zal de boordcomputer deze blokkering opheffen.
•: Omdat de kaart wel even verwijderd is geweest, zal de boordcomputer de chauffeur vragen of er sinds de ‘Start pauze’ nog (andere) activiteiten zijn geweest. Aangezien dit niet het geval was, maakt de chauffeur geen gebruik van de mogelijkheid tot het handmatig toevoegen van activiteiten.
•: De boordcomputer boekt nu de login automatisch gevolgd door een ‘Start werk’ (na inloggen moet een boordcomputer namelijk altijd in werkniveau terechtkomen). Gezien het echter nog pauze is, zal de chauffeur direct ingeven dat het (nog steeds/weer) pauze is. Vanaf nu is het echter pauze met de kaart in de boordcomputer.
•: De chauffeur beëindigt de pauze op het ogenblik dat hij weer gaat werken.

RSTGBTAXI_stc-2015-9656_BIJL4_10

Activiteit	Tijdstip	Handm.	SessionRecord	Opmerking
...			n
Start pauze	15:00:00	‘0’B	n
(kaart uitnemen)			n	Sessie geblokkeerd op BCT
			n	Sessie geblokkeerd op BCT
(kaart inbrengen)			n	Geen handm. toevoegingen
Login	15:30:00	‘0’B	n	Ingevoegd door BCT
Start werk	15:30:00	‘0’B	n	Ingevoegd door BCT
Start pauze	15:30:30	‘0’B	n	(terug)gezet door bestuurder
Start werk	15:40:00	‘0’B	n	Aangegeven door bestuurder
...			n

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

•: Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint. De chauffeur neemt zijn kaart uit de boordcomputer zonder af te sluiten. Hierop blokkeert de boordcomputer de kaartsessie.
•: Daarna wordt er met het voertuig gereden, zonder een chauffeurskaart (in zijn pauze is dit toegestaan).
•: Binnen 60 minuten na het uitnemen wordt de chauffeurskaart weer in de boordcomputer gebracht, dus de kaartsessie is nog geblokkeerd. Het is dezelfde kaart die ingebracht wordt als die waarvan de kaartsessie geblokkeerd is en dus wordt de blokkering opgeheven.
•: De chauffeur begint weer met werken.

RSTGBTAXI_stc-2015-9656_BIJL4_11

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start pauze	16:00:00	‘0’B	n
(kaart uitnemen)			n
			n
(rijden zonder chauffeurskaart)			n
			n
(kaart inbrengen)			n
Login	16:25:00	‘0’B	n
Start werk	16:25:00	‘0’B	n
...			n

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

•: Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint. De chauffeur neemt zijn kaart uit de boordcomputer zonder af te sluiten. Hierop blokkeert de boordcomputer de kaartsessie.
•: Aangezien er na 60 minuten nog niets gebeurd is, wordt op de boordcomputer de geblokkeerde kaartsessie automatisch afgesloten.
•: Als de chauffeur daarna zijn kaart weer in de boordcomputer brengt, wordt gesignaleerd dat de sessie op de kaart niet goed afgesloten was.
•: Verder wordt gevraagd of er nog activiteiten sinds het einde van de vorige kaartsessie zijn geweest. Dat is zo, want de pauze was eigenlijk binnen de 60 minuten afgelopen waarna andere werkzaamheden zijn begonnen.
•: Omdat op de boordcomputer de sessie al beëindigd was, wordt een nieuwe kaartsessie begonnen.

RSTGBTAXI_stc-2015-9656_BIJL4_12

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start pauze	16:00:00	‘0’B	n
(kaart uitnemen om 16:00:02)
(sessie time-out om 17:00:02)
(kaart inbrengen om 17:25:00)
(nieuw sessierecord)
Start werk	16:30:00	‘1’B	n+1
Login	17:25:00	‘0’B	n+1
Start werk	17:26:00	‘0’B	n+1
...

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

•

Boordcomputer A: de laatstgeboekte activiteit is ‘Start werk’ en de chauffeur neemt zijn kaart uit de boordcomputer zonder af te sluiten. Hierop blokkeert de boordcomputer de kaartsessie (n). Er vinden voorlopig geen andere activiteiten plaats.

•

Boordcomputer B: de chauffeurskaart wordt binnen de 60 minuten na het uitnemen uit boordcomputer A ingebracht in B:

•: Er wordt geconstateerd dat de vorige sessie (op A) niet goed afgesloten is.
•: Er wordt een nieuwe kaartsessie (n+1) gestart.
•: Er wordt gevraagd of er nog andere werkzaamheden of pauze moeten worden toegevoegd of aangepast. Hierbij geeft de chauffeur aan dat hij 10 minuten voor het inloggen met pauze ging, waarmee de periode tussen uitnemen van de kaart en de start van die pauze kan worden beschouwd als een voortzetting van het werk (buiten de auto). Hierna worden geen andere handmatige activiteiten opgevoerd, waardoor de boordcomputer het inloggen zal boeken en in werkniveau zal gaan staan.
•: Nieuwe activiteiten worden opgeslagen op de kaart.
•: De kaartsessie wordt afgesloten binnen de 60 minuten na het uitnemen uit boordcomputer A.
•: Hierna werkt de chauffeur een kwartiertje buiten de auto.

•

Boordcomputer A: de chauffeurskaart wordt ingebracht na het kwartiertje werk, maar nog steeds binnen 60 minuten na het uitnemen uit boordcomputer A. Op boordcomputer A is de kaartsessie dus nog steeds geblokkeerd:

•: Het is dezelfde kaart die ingebracht wordt als die waarvan de kaartsessie geblokkeerd is en dus wordt de blokkering opgeheven.
•: Aangezien bij het uitlezen van de kaart gezien wordt dat er in de tussentijd een kaartsessie op een andere boordcomputer is geweest, kan de gedeblokkeerde sessie niet worden voortgezet, maar zal op boordcomputer A een nieuwe sessie (n+2) starten.
•: De boordcomputer biedt de chauffeur de mogelijkheid om de laatste activiteit van de vorige sessie (n+1) te vervangen, te wijzigen of aan te vullen. Hiervan maakt de chauffeur gebruik door een handmatige ‘Start werk’ op te voeren die start op het tijdstip dat die vorige sessie (n+1) werd afgesloten. Het ‘kwartiertje werk’ is hiermee verantwoord.
•: Dan boekt boordcomputer A het nieuwste login tijdstip en gaat over tot niveau werken.

•

De nieuwe kaartsessie (n+2) verloopt verder normaal.

RSTGBTAXI_stc-2015-9656_BIJL4_13

Activiteit	Tijdstip	Handm.	SessionRecord
...			n
Start werk	16:00:00	‘0’B	n
(kaart uitnemen uit A om 17:00)			n

(kaart inbrengen in B om 17:25)
(nieuw sessierecord)

Start pauze (10 min pauze gehad)	17:15:00	‘1’B	n+1
Login	17:25:00	‘0’B	n+1
Start werk	17:25:00	‘0’B	n+1
Afsluiting	17:40:00	‘0’B	n+1

(kaart inbrengen in A om 17:55)
(nieuw sessierecord)

Start werk (opvullen van 15 min)	17:40:00	‘1’B	n+2
Login	17:55:00	‘0’B	n+2
Start werk	17:55:00	‘0’B	n+2
...			n+2

Bijlage B. Referentie data

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.

B.1. Het opzetten van Secure Messaging

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

1.

Lees de inhoud van EF.SN.ICC door middel van een read binary met SFI '1C'h en een offset '00'h.

RSTGBTAXI_stc-2015-9656_BIJL4_14

De laatste 8 bytes van de response data wordt gebruikt als SN.ICC.

2.

Selecteer het te gebruiken algoritme voor de mutual authenticate en de symmetrische sleutel referentie.

Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde 'C1'h en P2 de waarde 'A4'h. De data bij dit commando is '80 01 8C 83 01 03'h ('8C'h om ‘symmetric mutual authentication algorithm with SHA-256’ aan te duiden en '03'h om het Security Data Object (SDO) van PKI.KS.SM.ICC aan te duiden).

RSTGBTAXI_stc-2015-9656_BIJL4_15

3.

Vraag om een random waarde door middel van Get Challenge.

RSTGBTAXI_stc-2015-9656_BIJL4_16

De response data is de RND.ICC.

4.

Genereer een random waarde van 8 bytes voor RND.IFD, een random waarde van 32 bytes voor K.IFD en bepaal een serienummer SN.IFD van 8 bytes.

5.

Stel het bericht S samen:

S = RND.IFD || SN.IFD || RND.ICC || SN.ICC || K.IFD.

6.

Bereken de encrypted waarde van S met CBC Triple DES encryptie, ICV '00'h en de encryptie sleutel ENC.KEY (laatste 16 bytes van transportkey1):

ENC = CBCTDes('00', S, ENC.KEY).

7.

Bereken de Retail MAC over de encrypted waarde van S met ICV '00'h en de MAC sleutel MAC.KEY (eerste 16 bytes van transportkey1):

MAC = RMac('00', ENC || '80', MAC.KEY).

NB. Gebruik altijd padding met '80 ...' achter de data.

8.

Voer een Mutual Authenticate commando uit met als data ENC || MAC.

RSTGBTAXI_stc-2015-9656_BIJL4_17

9.

Wanneer de status van de response '90 00'h is, is er ook response data beschikbaar.

a.: Haal de encrypted data ENC_R en de MAC uit deze data.
b.: Bereken de Retail MAC over ENC_R met ICV '00'h en de MAC sleutel MAC.KEY:
MAC_R = RMac('00', ENC_R || '80', MAC.KEY).
Ook hier moet weer de padding met '80 ...' gebruikt worden.
c.: Bereken de decrypted waarde van ENC_R met Inverse CBC Triple DES encryptie, ICV '00'h en de encryptie sleutel ENC.KEY:
DEC_S = InvCBCTDes('00', ENC_R, ENC.KEY).

10.

Wanneer de berekende MAC_R gelijk is aan de MAC uit de response data van de Mutual Authenticate, dan is DEC_S gelijk aan

RND.ICC || SN.ICC || RND.IFD || SN.IFD || K.ICC.

11.

Hieruit kunnen de volgende waardes berekend worden:

•: K_ICC_IFD = K.IFD xor K.ICC
•: SK_ENC = 1^e 16 bytes van SHA256(K_ICC_IFD || '00 00 00 01')
•: SK_MAC = 1^e 16 bytes van SHA256(K_ICC_IFD || '00 00 00 02')
•: SSC = laatste 4 bytes RND.ICC || laatste 4 bytes RND.IFD

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.

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

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

1.

Verhoog de SSC met 1.

2.

De Cla byte 'xx' wordt 'xC' (Cla').

3.

Als het commando data bevat (Lc > 0), dan moet deze data encrypt worden. Bereken de encrypted waarde van de data met CBC Triple DES encryptie, ICV '00'h en de encryptie sleutel SK_ENC:

ENC = CBCTDes('00', data || '80', SK_ENC).

Ook hier moet weer de padding met '80 ...' gebruikt worden.

4.

De SecuredData waarover een Retail MAC berekend moet worden is afhankelijk van Lc en Le:

•: Lc > 0, Le > 0
SSC || Cla || Ins || P1 || P2 || '80' || '87' || Length(ENC)+1 || '01' || ENC || '97' || Length(Le) || Le || '80'
•: Lc > 0, Le = 0
SSC || Cla || Ins || P1 || P2 || '80' || '87' || Length(ENC)+1 || '01' || ENC || '80'
•: Lc = 0, Le > 0
SSC || Cla || Ins || P1 || P2 || '80' || '97' || Length(Le) || Le || '80'
•: Lc = 0, Le = 0
SSC || Cla || Ins || P1 || P2 || '80'

Let op dat er padding met '80 ...' gebruikt moet worden na P2 en, indien Lc > 0 of Le > 0, aan het eind van de data.

De te gebruiken ICV is '00'h en de te gebruiken sleutel is SK_MAC.

5.

Het te versturen commando ziet er dan als volgt uit:

Cla' || Ins || P1 || P2 || Length(SecuredData) + 10 || SecuredData || '8E 08'|| MAC || '00'

6.

Het formaat van de response onder secure messaging is afhankelijk van het terug krijgen van data:

•: data terug (even Ins)
'87' || Length(EncryptedData) + 1 || '01'|| EncryptedData || '99 02' || SW || '8E 08' || MAC || SW
•: data terug (oneven Ins)
'85' || Length(EncryptedData) || EncryptedData || '99 02' || SW || '8E 08' || MAC || SW
•: geen data terug
'99 02' || SW || '8E 08' || MAC || SW

7.

Verhoog de SSC met 1.

8.

Bereken een Retail MAC over de volgende data, afhankelijk van het formaat van de response:

•: data terug (even Ins)
SSC || '87' || Length(EncryptedData) + 1 || '01'|| EncryptedData || '99 02' || SW || '80'
•: data terug (oneven Ins)
SSC || '85' || Length(EncryptedData) || EncryptedData || '99 02' || SW || '80'
•: geen data terug
SSC || '99 02' || SW || '80'

In alle gevallen wordt er op het eind padding met '80' gebruikt.

De te gebruiken ICV is '00'h en de te gebruiken sleutel is SK_MAC.

9.

Vergelijk de berekende Retail MAC met de MAC uit de response. Deze moeten gelijk aan elkaar zijn.

10.

Zijn de ontvangen en berekende MAC gelijk aan elkaar, dan kan de EncryptedData, indien aanwezig, decrypted worden.

Bereken de decrypted waarde van EncryptedData met Inverse CBC Triple DES encryptie, ICV '00'h en de encryptie sleutel SK_ENC:

DecryptedData = InvCBCTDes('00', EncryptedData, SK_ENC).

Zie de tabel hieronder voor een voorbeeld van een commando, het commando met secure messaging en het antwoord met secure messaging.

RSTGBTAXI_stc-2015-9656_BIJL4_18

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

B.3.1. SignDataLegally

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

1.

Allereerst moet het hash template met het te gebruiken algoritme geselecteerd worden.

Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h en P2 de waarde 'AA'h. De data bij dit commando is '80 01 40'h ('40'h om de algoritme identifier voor SHA-256 aan te geven).

RSTGBTAXI_stc-2015-9656_BIJL4_19

2.

Selecteer het te gebruiken algoritme en de private sleutel van de BCT Handtekening.

Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h en P2 de waarde 'B6'h. De data bij dit commando is '80 01 42 84 01 86'h ('42'h om ‘PKCS#1 v1.5 – SHA-256’ aan te duiden en '86'h om het Security Data Object (SDO) van PKI.CH.DS aan te duiden).

RSTGBTAXI_stc-2015-9656_BIJL4_20

3.

De private sleutel van de BCT Handtekening mag pas gebruikt worden nadat de PIN gevalideerd is. Dit is nodig voor iedere keer dat deze sleutel gebruikt wordt. Dit wordt gedaan met het commando Verify, waarbij P2 (de PIN reference) de waarde '01'h heeft. Voor de PIN wordt PIN formaat 2 gebruikt.

RSTGBTAXI_stc-2015-9656_BIJL4_21

4.

Wanneer de input gegevens uit meer dan 64 bytes bestaan, moet er een intermediate hash met SHA-256 berekend worden door de boordcomputerlogica. Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte bits onthouden voor de volgende stap.

Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.

5.

Het berekenen van de uiteindelijke hash met SHA-256 wordt door de boordcomputerkaart gedaan. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de ‘intermediate hash value’, het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het chipgeheugen van de boordcomputerkaart achterblijven ten behoeve van de volgende en laatste stap.

RSTGBTAXI_stc-2015-9656_BIJL4_22

6.

Met de gekozen private sleutel wordt de handtekening berekend over de in het chipgeheugen aanwezige hashwaarde.

Dit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte aantal bytes in de response, moet daarbij op '00'h staan.

RSTGBTAXI_stc-2015-9656_BIJL4_23

7.

Een elektronische handtekening kan gecontroleerd worden op de volgende manier:

a.: Selecteer het certificaat EF.C.PKI.CH.DS op de boordcomputerkaart.
b.: Lees het certificaat met behulp van (meerdere) Read Binary.
c.: Haal de Public Exponent en de Modulus uit het certificaat.
d.: Voer een RSA decryptie uit van de response data van Compute Digital Signature met de Public Exponent en de Modulus.
e.: De decrypted data moet overeenkomen met:
’00 01 FF .. FF 00’ || SHA_256_Digest || SHA256(input data),
waarbij SHA_256_Digest = '30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20'h.

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:

1.

Allereerst moet het hash template met het te gebruiken algoritme geselecteerd worden.

RSTGBTAXI_stc-2015-9656_BIJL4_24

2.

Selecteer het te gebruiken algoritme en de private sleutel van de BCT Authenticiteit.

Dit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h en P2 de waarde 'B6'h. De data bij dit commando is '80 01 42 84 01 85'h ('42'h om ‘PKCS#1 v1.5 – SHA-256’ aan te duiden en '85'h om het Security Data Object (SDO) van PKI.CH.AUT aan te duiden).

RSTGBTAXI_stc-2015-9656_BIJL4_25

3.

De private sleutel van de BCT Authenticiteit mag pas gebruikt worden nadat de PIN gevalideerd is. Een eenmaal uitgevoerde PIN validatie mag – zo lang de kaart in de boordcomputer aanwezig blijft – worden ‘herbruikt’ bij elke volgende keer dat deze sleutel gebruikt word. Dit wordt gedaan met het commando Verify, waarbij P2 (de PIN reference) de waarde '01'h heeft. Voor de PIN wordt PIN formaat 2 gebruikt.

RSTGBTAXI_stc-2015-9656_BIJL4_26

4.

Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.

5.

RSTGBTAXI_stc-2015-9656_BIJL4_27

6.

Met de gekozen private sleutel wordt de handtekening berekend over de in het chipgeheugen aanwezige hashwaarde.

Dit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte aantal bytes in de response, moet daarbij op '00'h staan.

RSTGBTAXI_stc-2015-9656_BIJL4_28

7.

Een elektronische handtekening kan gecontroleerd worden op de volgende manier:

a.: Selecteer het certificaat EF.C.PKI.CH.AUT op de boordcomputerkaart.
b.: Lees het certificaat met behulp van (meerdere) Read Binary.
c.: Haal de Public Exponent en de Modulus uit het certificaat.
d.: Voer een RSA decryptie uit van de response data van Compute Digital Signature met de Public Exponent en de Modulus.
e.: De decrypted data moet overeenkomen met:
’00 01 FF .. FF 00’ || SHA_256_Digest || SHA256(input data),
waarbij SHA_256_Digest = '30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20'h.

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.

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

1.

Allereerst moet het hash template met het te gebruiken algoritme geselecteerd worden.

RSTGBTAXI_stc-2015-9656_BIJL4_28

2.

Selecteer het te gebruiken algoritme en de private sleutel van de BCT Authenticiteit.

RSTGBTAXI_stc-2015-9656_BIJL4_29

3.

Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.

4.

Het berekenen van de uiteindelijke hash met SHA-256 wordt door de systeemkaart gedaan. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de ‘intermediate hash value’, het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het chipgeheugen van de systeemkaart achterblijven ten behoeve van de volgende en laatste stap.

RSTGBTAXI_stc-2015-9656_BIJL4_30

5.

Met de gekozen private sleutel wordt de handtekening berekend over de in het chipgeheugen aanwezige hashwaarde.

Dit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte aantal bytes in de response, moet daarbij op '00'h staan.

RSTGBTAXI_stc-2015-9656_BIJL4_31

6.

Een elektronische handtekening kan gecontroleerd worden op de volgende manier:

a.: Selecteer het certificaat EF.C.PKI.CH.AUT op de systeemkaart.
b.: Lees het certificaat met behulp van (meerdere) Read Binary.
c.: Haal de Public Exponent en de Modulus uit het certificaat.
d.: Voer een RSA decryptie uit van de response data van Compute Digital Signature met de Public Exponent en de Modulus.
e.: De decrypted data moet overeenkomen met:
’00 01 FF .. FF 00’ || SHA_256_Digest || SHA256(input data),
waarbij SHA_256_Digest = '30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20'h.

Toon alle voetnoten

Voetnoten

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