Bijlage 4 Regeling specificaties en typegoedkeuring boordcomputer taxi

Regeling specificaties en typegoedkeuring boordcomputer taxi

OPENBAAR Versie 1.7 Datum 25 april 2012 Status DEFINITIEF 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 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 mogelijk

• • 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.
• • 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.
• 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);
• • 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.
• • 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).
• 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.
• • 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.
• 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.
• 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.
• 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.
• • 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.
• • 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.
• • 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).
• • 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
• • 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.
• • 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).
• 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.
• 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).
• 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.
• 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).
• 1. DayRecordLength = oude waarde DayRecordLength + 6 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een “Start werk” of “Start pauze” betreft).
• 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).
• 1. DayRecordLength = oude waarde DayRecordLength + 9 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een “Start werk” of “Start pauze” betreft).
• 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).
• 1. DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een “Start werk” of “Start pauze” betreft).
• 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).
• 1. DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels) vorige ActivityRecord een “Start werk” of “Start pauze” betreft).
• • (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,
• • 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
• 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).
• 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.
• 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.
• • 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.
• • 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)
• 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.
• 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.
• • 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.
• 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.
• 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.
• 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.