Title: wetten.nl - Regeling - Regeling specificaties en typegoedkeuring boordcomputer taxi - BWBR0027945

Source: https://wetten.overheid.nl/BWBR0027945/

Content:
{"title": "wetten.nl - Regeling - Regeling specificaties en typegoedkeuring boordcomputer taxi - BWBR0027945", "content": "Regeling specificaties en typegoedkeuring boordcomputer taxi\n\nDe Minister van Verkeer en Waterstaat,\n\nGelet op de artikelen artikel 22, eerste en derde lid, 23, derde lid, en 24 van de Wegenverkeerswet 1994;\n\nBesluit:\n\nIn deze regeling wordt verstaan onder:\n\nactivering: handeling waarmee de boordcomputer in geactiveerde toestand wordt gebracht;\n\nauthenticiteit: eigenschap dat informatie afkomstig is van een persoon of inrichting, waarvan de\n                                             identiteit kan worden geverifieerd;\n\nauto: auto waarmee taxivervoer wordt verricht;\n\nbedrijfsvergrendeling: vergrendeling waarmee de in de boordcomputer opgeslagen gegevens herleidbaar zijn\n                                             naar de vervoerder waarvoor deze opgeslagen zijn;\n\nbeproeving: test, of serie tests, die door de boordcomputer kan worden uitgevoerd om fouten te\n                                             ontdekken en die automatisch of door de gebruiker van de boordcomputer kan worden\n                                             ge\u00efnitieerd;\n\nbeschikbaarheid: mate waarin de boordcomputer of componenten van de boordcomputer zonder belemmering\n                                             toegankelijk zijn voor geautoriseerde gebruikers;\n\nbestuurder: bestuurder die taxivervoer verricht;\n\nbeveiligingsgegevens: specifieke gegevens ter ondersteuning van de beveiligingsfuncties;\n\nbewegingsgegevens: gegevens betreffende snelheid en afgelegde afstand van de auto die door de bewegingsopnemer\n                                             of de positiebepalingssensor aan de boordcomputer worden aangeleverd;\n\nbewegingsopnemer: instrument, of een deel ervan, gekoppeld aan de boordcomputer dat een signaal in\n                                             de vorm van een impuls afgeeft over de beweging van de auto op basis waarvan de boordcomputer\n                                             de afgelegde afstand van de auto kan bepalen;\n\nboordcomputer: apparaat ten behoeve van de registratie van de gegevens, bedoeld in artikel 79, derde, vierde en vijfde lid, van het Besluit personenvervoer 2000;\n\nboordcomputereenheid: boordcomputer zonder systeemkaart;\n\nboordcomputerkaart: een geheugenkaart als bedoeld in artikel 1, onderdeel h, van het Besluit personenvervoer 2000;\n\nCEN: door het Comit\u00e9 Europ\u00e9en de Normalisation uitgegeven norm;\n\nchauffeurskaart: kaart als bedoeld in artikel 1, onderdeel i, van het Besluit personenvervoer 2000;\n\nconstante van de boordcomputer: getal dat de waarde aangeeft van het ingangssignaal van de bewegingsopnemer dat nodig\n                                             is ter aanwijzing en registratie van een afgelegde afstand van \u00e9\u00e9n kilometer, uitgedrukt\n                                             in impulsen per kilometer;\n\nco\u00f6rdinaten: een aanduiding om de positie van de auto op de aarde vast te leggen ten opzichte\n                                             van het World Geodetic System 1984 co\u00f6rdinatenstelsel;\n\ndeactivering: handeling waarmee de boordcomputer in niet-geactiveerde toe stand wordt gebracht;\n\neerste systeemkaart: voor een boordcomputer met een bepaald typegoedkeuringsnummer aan diens fabrikant\n                                             afgegeven processorkaart waarvan de functie voor het genereren van elektronische handtekeningen\n                                             nog niet actief is;\n\nelektronische handtekening: een elektronische handtekening die voldoet aan de bij of krachtens verordening (EU)\n                                             nr. 910/2014 van het Europees Parlement en de Raad van 23\u00a0juli 2014 betreffende elektronische\n                                             identificatie en vertrouwensdiensten voor elektronische transacties in de interne\n                                             markt en tot intrekking van richtlijn 1999/93/EG (PbEU 2014, L 257) gestelde eisen\n                                             aan een gekwalificeerde elektronische handtekening als bedoeld in artikel 3, onderdeel\n                                             12, van die verordening;\n\nETSI: door de European Telecommunications Standards Institute uitgegeven norm;\n\nfabrikant: marktdeelnemer die verantwoordelijk is voor alle aspecten van een goedkeuringsprocedure\n                                             als bedoeld in artikel 21, tweede lid, onderdeel b, van de Wegenverkeerswet 1994, waar het de goedkeuring van een boordcomputer betreft;\n\nFIPS PUB: een Federal Information Processing Standards Publication;\n\ngeaccrediteerde Common Criteria testinstelling: een testinstelling die beschikt over een accreditatie op grond van de Common Criteria\n                                             for Information Technology Evaluation delen 1, 2 en 3, versie 3.1, in combinatie met\n                                             de Common Methodology for Information Technology Evaluation versie 3.1.;\n\ngebruikersgegevens: door de boordcomputer geregistreerde en opgeslagen gegevens, anders dan beveiligingsgegevens\n                                             en systeemgegevens;\n\ngeheugen: niet-volatiel elektronisch geheugenmedium dat in de boordcomputer is ingebouwd;\n\nHDOP-waarde: Horizontal Dilution Of Precision waarde;\n\nIETF: door de Internet Engineering Taskforce uitgegeven norm;\n\ninspectiekaart: aan de met het toezicht op de naleving belaste persoon afgegeven boordcomputerkaart\n                                             die de desbetreffende persoon identificeert en waarmee de controlemodus van de boordcomputer\n                                             kan worden geactiveerd;\n\nISO: door de International Organisation for Standardisation uitgegeven norm;\n\nISO-IEC: door de International Organisation for Standardisation en de International Electrotechnical\n                                             Commission uitgegeven norm;\n\nkaartsessie: periode tussen het ingeven van de boordcomputerkaart en het wegschrijven van de afsluitende\n                                             gegevens op de boordcomputerkaart door de boordcomputer;\n\nkeuringskaart: kaart als bedoeld in artikel 1, onderdeel j, van het Besluit personenvervoer 2000;\n\nkilometerstand: de door de boordcomputer getotaliseerde afgelegde afstand met de auto, zowel bij\n                                             vooruitrijden als bij achteruitrijden, overeenkomend met de totale door de auto afgelegde\n                                             afstand;\n\nminister: Minister van Infrastructuur en Waterstaat;\n\nNEN: door de Stichting Nederlands Normalisatie-instituut uitgegeven norm;\n\nNEN-EN: door de European Committee for Electrotechnical Standardisation uitgegeven norm die\n                                             door de Stichting Nederlands Normalisatie-instituut is aanvaard als Nederlandse norm;\n\nNEN-ISO: door de International Organisation for Standardisation uitgegeven norm die door de\n                                             Stichting Nederlands Normalisatie-instituut is aanvaard als Nederlandse norm;\n\nondernemerskaart: door de minister aan een vervoerder afgegeven boordcomputerkaart die de desbetreffende\n                                             vervoerder identificeert en waarmee de bedrijfsmodus van de boordcomputer kan worden\n                                             geactiveerd;\n\nongeldige boordcomputerkaart: ingetrokken boordcomputerkaart, defecte boordcomputerkaart, of een boordcomputerkaart\n                                             waarvan de geldigheidsduur nog niet is begonnen of reeds is verstreken;\n\noverbrengen: kopi\u00ebren van de gegevens, of een gedeelte daarvan, en het kopi\u00ebren van de bijbehorende\n                                             elektronische handtekening die in het geheugen van de boordcomputer of op de chauffeurskaart\n                                             zijn opgeslagen;\n\nplaatselijke tijd: UTC gecorrigeerd met een in te geven aantal uren voor de tijdzone en een automatische\n                                             correctie voor de zomertijd;\n\npositiebepalingssensor: instrument, of een deel ervan, gekoppeld aan de boordcomputer dat een signaal afgeeft\n                                             aan de boordcomputer over de locatie van de auto op basis van verkregen informatie\n                                             van een satelliet positiebepalingsysteem;\n\nprogrammatuur: de combinatie van uitvoerbare code van de boordcomputer en bijbehorende programmatuurgegevens;\n\nprogrammatuurgegevens: vaste attributen van programmatuur of een programmatuurrevisie;\n\nprogrammatuurrevisie: nieuwere versie van programmatuur;\n\nprogrammatuurversienummer: vast attribuut van programmatuur of programmatuurrevisie, zijnde een nummer waarmee\n                                             de versie van programmatuur respectievelijk de programmatuurrevisie uniek ge\u00efdentificeerd\n                                             kan worden;\n\nregistreren: in het geheugen van de boordcomputer vastleggen van gegevens en gebeurtenissen;\n\nritadministratie: gegevens, bedoeld in artikel 79, derde en vierde lid, van het Besluit personenvervoer 2000;\n\nsensor: eenheid die onderdeel uitmaakt van de boordcomputer of rechtstreeks gekoppeld is\n                                             aan de boordcomputer en die informatie automatisch aanlevert aan de boordcomputer;\n\nsysteemgegevens: specifieke gegevens ter ondersteuning of noodzakelijk voor het functioneren van de\n                                             boordcomputer of voor identificatie en instellingen van de boordcomputerfuncties;\n\nsysteemkaart: door de minister afgegeven geheugenkaart met chip die de boordcomputer in staat stelt\n                                             een elektronische handtekening te plaatsen;\n\nUTC: Universal Time Coordinated;\n\nverplaatsingsopnemer: instrument, onderdeel uitmakende van de boordcomputer dat de boordcomputer in staat\n                                             stelt autonoom een verplaatsing van de auto waar te nemen;\n\nvervangende systeemkaart: door de minister voor de vervanging van de systeemkaart van een specifieke boordcomputer\n                                             aan de vervoerder of fabrikant afgegeven nieuwe processorkaart waarvan de functie\n                                             voor het genereren van elektronische handtekeningen nog niet actief is;\n\nverordening (EU) 2018/858: verordening (EU) nr. 2018/858 van het Europees Parlement en de Raad van 30\u00a0mei 2018\n                                             betreffende de goedkeuring van en het markttoezicht op motorvoertuigen en aanhangwagens\n                                             daarvan en systemen, onderdelen en technische eenheden die voor dergelijke voertuigen\n                                             zijn bestemd, tot wijziging van Verordeningen (EG) nr. 715/2007 en (EG) nr. 595/2009 en tot intrekking van Richtlijn 2007/46/EG (PbEU 2018, L 151);\n\nvervoerder: vervoerder als bedoeld in artikel 1, onderdeel k, van de Wet personenvervoer 2000 en werkgever als bedoeld in artikel 1:1, eerste lid, onderdeel a, van de Arbeidstijdenwet, die taxivervoer verricht.\n\nwerkplaats: werkplaats als bedoeld in artikel 1 van de Regeling erkenning werk plaatsen boordcomputer\n                                             taxi.\n\nDeze regeling berust op artikel 21, tweede lid, onderdeel b, en 23, eerste en tweede lid, van de Wegenverkeerswet 1994.\n\n1 De boordcomputer bestaat uit ten minste:\n\na. een verwerkingseenheid;\n\nb. een geheugen;\n\nc. een tijdklok;\n\nd. een ISO 7816 kaartinterface;\n\ne. een systeemkaart, verzegeld in een ISO 7810 ID-000 kaartinterface;\n\nf. een positiebepalingssensor of een interface voor de positiebepalingssensor;\n\ng. een verplaatsingsopnemer, een interface voor de bewegingsopnemer;\n\nh. een gegevensoverbrengingsinterface als beschreven in bijlage 2;\n\ni. een interface voor de taxameter als beschreven in bijlage 3;\n\nj. een leesvenster;\n\nk. voorzieningen voor de invoer van gebruikersgegevens.\n\n2 De boordcomputer kan door middel van additionele verbindingen aan andere inrichtingen\n                                                worden gekoppeld, of daarmee ge\u00efntegreerd worden.\n\n3 Een verbinding of integratie met de boordcomputer, als bedoeld in het tweede lid,\n                                                leidt er niet toe dat de boordcomputer niet langer voldoet aan deze regeling.\n\n4 De boordcomputer voldoet aan de bij deze regeling behorende bijlagen.\n\n1 De boordcomputer beschikt over een interne autonome tijdklok. Deze is voortdurend\n                                                operationeel en levert de UTC, met een maximale onnauwkeurigheid van tachtig delen\n                                                per miljoen.\n\n2 De UTC wordt gebruikt voor datering in de boordcomputer.\n\n3 Indien ingeschakeld, controleert en corrigeert de boordcomputer ten minste eenmaal\n                                                per uur automatisch de eigen UTC met behulp van een extern signaal, waarbij de eerste\n                                                controle binnen vijf minuten na inschakelen plaatsvindt.\n\n4 De resolutie van de tijdklok is \u00e9\u00e9n seconde of nauwkeuriger.\n\n5 De boordcomputer hanteert ISO-8601 voor de numerieke presentatie van datum en tijd.\n\n6 Om de plaatselijke tijd zichtbaar te maken kan in de activerings- en keuringsmodus\n                                                met stappen van een half uur het verschil worden ingegeven ten opzichte van de UTC.\n\n7 Bij een externe stroomonderbreking van minder dan twaalf maanden blijft de interne\n                                                autonome tijdklok functioneren.\n\n1 De boordcomputer heeft vier werkingsmodi:\n\na. operationele modus;\n\nb. controlemodus;\n\nc. activerings- en keuringsmodus;\n\nd. bedrijfsmodus.\n\n2 De operationele modus, bedoeld in het eerste lid, onderdeel a, heeft drie werkingsniveaus:\n\na. basis;\n\nb. arbeidstijd;\n\nc. taxivervoer.\n\n3 Het werkingsniveau basis is tevens een ge\u00efntegreerd onderdeel van de controlemodus,\n                                                activerings- en keuringsmodus, en de bedrijfsmodus.\n\n4 De boordcomputer wisselt naar de volgende werkingsmodus afhankelijk van het type boordcomputerkaart\n                                                dat in de kaartinterface is ingebracht en koppelt hier een gebruikersgroep aan overeenkomstig\n                                                de volgende tabel:\n\nType boordcomputerkaart\n\nWerkingsmodus\n\nGebruikersgroep\n\nGeen\n\nOperationele modus: Basis\n\nONBEKEND\n\nChauffeurskaart\n\nOperationele modus: Arbeidstijd\n\nBESTUURDER\n\nInspectiekaart\n\nControlemodus\n\nTOEZICHTHOUDER\n\nKeuringskaart\n\nActiverings- en keuringsmodus\n\nWERKPLAATS\n\nOndernemerskaart\n\nBedrijfsmodus\n\nVERVOERDER\n\n5 In afwijking van de tabel, bedoeld in het vierde lid, leidt het invoeren van een inspectiekaart\n                                                tijdens de deactivering, bedoeld in artikel 23, niet tot het automatisch selecteren van de controlemodus.\n\n6 De boordcomputer wisselt na een handmatig verzoek van de bestuurder daartoe tussen\n                                                de werkingsniveaus van de operationele modus. Het werkingsniveau basis is daarbij\n                                                altijd ingeschakeld.\n\n7 Indien het werkingsniveau taxivervoer is ingeschakeld, is tevens het werkingsniveau\n                                                arbeidstijd ingeschakeld.\n\n8 Indien er geen chauffeurskaart aanwezig is stelt de boordcomputer de bestuurder in\n                                                staat om bij het inschakelen van het werkingsniveau arbeidstijd handmatig het burgerservicenummer,\n                                                bedoeld in de Wet algemene bepalingen burgerservicenummer, invoeren.\n\n9 De boordcomputer gebruikt de werkingsmodi om de voor die modi geldende toegangsregels\n                                                voor toegangsrechten tot functies, objecten en gegevens toe te passen.\n\n10 Indien in de operationele modus het werkingsniveau arbeidstijd of taxivoer actief\n                                                is, leidt het invoeren van de inspectiekaart tot het pauzeren van de operationele\n                                                modus, inclusief de betreffende kaartsessie. Na het afsluiten van de controlemodus\n                                                wordt de operationele modus hervat.\n\n1 De bewegingsopnemer levert impulsen aan de boordcomputer.\n\n2 Het opnemen van de afgelegde afstand vindt automatisch plaats op basis van impulsen\n                                                en de constante van de boordcomputer.\n\n3 De afgelegde afstand, bedoeld in het tweede lid vertoont tijdens gebruik per duizend\n                                                meter ten hoogste een afwijking van plus of min twee procent ten opzichte van de werkelijk\n                                                afgelegde afstand.\n\n4 De auto wordt verondersteld zich in de toestand rijden te bevinden wanneer gedurende\n                                                een periode van vijf seconden door de boordcomputer, op basis van de bewegingsopnemer,\n                                                ten minste een verplaatsing van veertien meter wordt waargenomen.\n\n5 De verplaatsingsopnemer is binnen de behuizing van de boordcomputer aangebracht en\n                                                is van buitenaf niet bereikbaar.\n\n6 De verplaatsingsopnemer meet de resulterende versnelling die de boordcomputer in verschillende\n                                                richtingen ondervindt.\n\n7 De auto wordt verondersteld zich in de toestand verplaatsen te bevinden wanneer er\n                                                door de boordcomputer, op basis van de verplaatsingsopnemer, gedurende een periode\n                                                van ten minste drie seconden een versnelling van ten minste 2 m/s2 wordt waargenomen.\n\n1 Als de boordcomputer is ingeschakeld bepaalt de positiebepalingsensor continue de\n                                                positie van de auto.\n\n2 De positiebepalingsensor levert met vaste intervallen de positiegegevens van de auto\n                                                aan de boordcomputer.\n\n3 De positiegegevens, bedoeld in het tweede lid, bevatten ten minste de volgende gegevens:\n\na. de co\u00f6rdinaten;\n\nb. of er een positie bepaald is;\n\nc. het aantal satellieten op basis waarvan de positie van de auto bepaald is;\n\nd. de HDOP-waarde uitgedrukt in een getal tussen nul en vijftig;\n\ne. het tijdstip van de positiebepaling.\n\n4 De twee-dimensionale wortel uit het gemiddelde kwadraat van de afstand tussen door\n                                                de positiebepalingssensor geleverde co\u00f6rdinaten en de werkelijke positie is kleiner\n                                                dan 10 meter.\n\n5 De boordcomputer stelt op basis van de door de positiebepalingsensor geleverde informatie\n                                                eenmaal per minuut de positie van de auto vast en registreert deze positie.\n\n6 De positiegegevens, bedoeld in het vijfde lid worden zodanig opgeslagen dat zij alleen\n                                                overeenkomstig artikel 23, derde lid, overgebracht kunnen worden.\n\n1 De boordcomputer stelt op basis van gegevens van de bewegingsopnemer en de constante\n                                                van de boordcomputer continu de kilometerstand beschikbaar.\n\n2 De resolutie van de kilometerstand is 100 meter of nauwkeuriger.\n\n3 De boordcomputer gebruikt de gemeten posities van de positiebepalingsensor om afstanden\n                                                te meten en daarmee de afstandsbepaling met de bewegingsopnemer te controleren.\n\n4 De controle tussen beide afstandsbepalingen, bedoeld in het derde lid, vindt steeds\n                                                plaats op basis van de positiegegevens van een traject van 1000 meter waarbij de snelheid\n                                                van de auto steeds hoger was dan tien kilometer per uur.\n\n5 Het verschil tussen de door beide sensoren berekende afstand bedraagt hierbij minder\n                                                dan vijf procent.\n\n1 De boordcomputer verwerkt en registreert gegevens op zodanige wijze dat de vertrouwelijkheid,\n                                                integriteit en beschikbaarheid van de gegevens gewaarborgd zijn.\n\n2 De authenticiteit, integriteit en onweerlegbaarheid van de in het geheugen opgeslagen\n                                                gegevens wordt gegarandeerd aan de hand van een elektronische handtekening.\n\n1 De boordcomputer registreert in de operationele modus, werkingsniveau arbeidstijd,\n                                                de arbeids-, rij- en rusttijden, bedoeld in de artikelen 5:4, tweede en derde lid, 5:6, en 5:9, van de Arbeidstijdenwet en de artikelen 2.5:1, 2.5:2, 2.5:3, 2.5:4, 2.5:5, 2.5:6, eerste lid, en 2.5:7, van het Arbeidstijdenbesluit vervoer van de bestuurder en maakt daarbij het volgende onderscheid:\n\na. rijtijd;\n\nb. andere werkzaamheden dan rijden;\n\nc. pauze.\n\n2 De boordcomputer registreert iedere wijziging in het arbeidstijdpatroon, het tijdstip\n                                                en de datum van deze wijzigingen en de aanwezigheid van een boordcomputerkaart in\n                                                de kaartlezer.\n\n3 De bestuurder kan in de operationele modus, werkingsniveau arbeidstijd, handmatig\n                                                de aanvang en het einde van een pauze aangeven. Een bij de aanvang van de pauze actief\n                                                werkingsniveau taxivervoer wordt hiermee automatisch afgesloten.\n\n4 De bestuurder kan aan het begin van een kaartsessie handmatig aangeven dat hij nadat\n                                                de voorgaande kaartsessie is afgesloten nog andere werkzaamheden dan rijden heeft\n                                                uitgevoerd, of pauze heeft genoten. De boordcomputer legt hierbij vast of het andere\n                                                werkzaamheden dan rijden of pauze betreft, en de datum en tijd van het begin en het\n                                                einde hiervan.\n\n5 De boordcomputer zorgt er bij het afsluiten van een kaartsessie voor dat over de gegevens,\n                                                bedoeld in het eerste lid, een elektronische handtekening wordt geplaatst door de\n                                                chauffeurskaart en dat deze gegevens worden gekopieerd naar de chauffeurskaart.\n\n6 Indien er geen chauffeurskaart in de boordcomputer aanwezig is, wordt de elektronische\n                                                handtekening door de boordcomputer geplaatst met behulp van de systeemkaart.\n\n7 De boordcomputer toont de gegevens waarover een elektronische handtekening geplaatst\n                                                wordt. Deze omvatten ten minste de totalen van de aan de in het eerste lid bedoelde\n                                                activiteiten bestede tijd.\n\n1 De boordcomputer registreert in de operationele modus, werkingsniveau taxivervoer,\n                                                per rit de ritadministratie en draagt zorg voor een aantoonbaar volledige registratie.\n\n2 De boordcomputer kan de ritadministratie per zitplaats gelijktijdig bijhouden.\n\n3 De boordcomputer registreert op het moment van optreden het beginpunt en het eindpunt\n                                                van de rit in co\u00f6rdinaten.\n\n4 Indien de co\u00f6rdinaten van het beginpunt of het eindpunt van de rit niet beschikbaar\n                                                zijn op het moment van optreden, vindt deze registratie alsnog plaats zodra deze co\u00f6rdinaten\n                                                beschikbaar komen.\n\n5 De boordcomputer neemt de prijs van het vervoer per rit en eventuele toeslagen over\n                                                uit de in de auto aanwezige taxameter.\n\n6 Indien het niet mogelijk is om de prijs van het vervoer per rit of de in rekening\n                                                gebrachte toeslagen over te nemen uit de in de auto aanwezige taxameter, kunnen de\n                                                prijs van het vervoer per rit of de toeslagen handmatig door de bestuurder in de boordcomputer\n                                                worden ingevoerd.\n\n7 In de boordcomputer kan in de operationele modus, werkingsniveau taxivervoer, handmatig\n                                                de aanvang en het einde van de rit worden ingegeven en kan worden aangegeven of sprake\n                                                is van een beladen of een onbeladen rit.\n\n8 Direct na de be\u00ebindiging van een rit wordt door de boordcomputer met de systeemkaart\n                                                een elektronische handtekening geplaatst over de ritadministratie voor de desbetreffende\n                                                rit.\n\nDe boordcomputer stelt in de operationele modus, werkingsniveau taxivervoer, ten behoeve\n                                          van het afdrukken van een ritbewijs ten minste de volgende gegevens, inclusief een\n                                          korte aanduiding van het gegeven, ter beschikking:\n\na. het personenvervoernummer dat staat aangegeven op de vergunning, bedoeld in artikel 4, derde lid, van de Wet personenvervoer 2000;\n\nb. het kenteken van de auto;\n\nc. het telefoonnummer van de vervoerder, dan wel het telefoonnummer van de instantie\n                                                waarmee de vervoerder is overeengekomen dat klachten over taxivervoer door deze instantie\n                                                in behandeling worden genomen;\n\nd. het telefoonnummer van het Landelijk Klachtenmeldpunt Taxivervoer;\n\ne. het nummer van de chauffeurskaart van de bestuurder;\n\nf. de plaatselijke datum en tijd bij het vertrek en de aankomst van de rit;\n\ng. de co\u00f6rdinaten van de vertrek- en de aankomstplaats van de rit;\n\nh. de afgelegde afstand van de rit in kilometers;\n\ni. het ritbedrag;\n\nj. opbouw van het ritbedrag, per tariefsoort bestaande uit het aantal eenheden en het\n                                                bedrag per eenheid;\n\nk. de eventueel in rekening gebrachte toeslagen, en\n\nl. de totaalprijs.\n\n1 In de bedrijfs-, controle- en activerings- en keuringsmodus kan de boordcomputer op\n                                                verzoek vanuit het geheugen gegevens overbrengen naar externe gegevensdragers via\n                                                een overbrengingsinterface.\n\n2 In de bedrijfsmodus kunnen alleen de gegevens die zijn vastgelegd behorende bij de\n                                                actieve bedrijfsvergrendeling worden overgebracht.\n\n3 De overbrenging van deze gegevens en de overbrengingsinterface, bedoeld in het eerste\n                                                lid, voldoen aan de eisen die zijn vastgelegd in bijlage 2.\n\n4 In de bedrijfsmodus kan de overbrenging van deze gegevens tevens via een andere overbrengingsinterface\n                                                plaatsvinden.\n\n5 Opgeslagen gegevens worden door de overbrenging niet verwijderd of veranderd.\n\n1 Onverminderd artikel 12 is het toegestaan om in elke modus gegevens via een andere verbinding naar een voor\n                                                deze verbinding geautoriseerd bedrijf over te brengen, dan wel een opdracht voor het\n                                                overbrengen van gegevens aan de boordcomputer te verzenden buiten een fysieke verbinding\n                                                tussen ondernemerskaart en boordcomputer.\n\n2 Ingeval van verzending buiten een fysieke verbinding tussen ondernemerskaart en boordcomputer\n                                                kan de boordcomputer zelfstandig vaststellen dat de opdracht door een daartoe geautoriseerde\n                                                ondernemerskaart is gegeven in de bedrijfsmodus en door de ondernemerskaart is voorzien\n                                                van een elektronische handtekening.\n\n3 De in het tweede lid bedoelde autorisatie heeft een door de ondernemer in te stellen\n                                                geldigheidsduur, die echter door de boordcomputer moet worden be\u00ebindigd bij verandering\n                                                van de bedrijfsvergrendeling.\n\n4 Op een overbrenging als bedoeld in het eerste lid, zijn de gegevenstoegangsrechten\n                                                van de bedrijfsmodus van toepassing.\n\n1 Direct nadat het contact van de auto ingeschakeld is, wordt de boordcomputer automatisch\n                                                ingeschakeld, tenzij de boordcomputer al ingeschakeld is.\n\n2 De boordcomputer kan uitsluitend handmatig uitgeschakeld worden nadat het contact\n                                                is uitgeschakeld.\n\n3 De boordcomputer wordt uitsluitend automatisch uitgeschakeld indien:\n\na. zij zich bevindt in het werkingsniveau, bedoeld in artikel 4, tweede lid, onder a;\n\nb. het contact is uitgeschakeld;\n\nc. er gedurende meer dan twee uur geen activiteit is geweest van de kaartinterface en\n                                                      van het invoerscherm, en\n\nd. gedurende meer dan twee uur geen toestand rijden of verplaatsen is gedetecteerd.\n\n4 Indien een stroomonderbreking heeft plaatsgevonden en de stroomvoorziening is hersteld,\n                                                wordt de boordcomputer automatisch teruggebracht in de staat waarin de boordcomputer\n                                                zich bevond voordat de stroomonderbreking optrad.\n\n1 Het vergaren van gegevens vindt plaats met behulp van sensoren, tenzij de verplichte\n                                                informatie niet via een sensor kan worden verkregen.\n\n2 Indien het vergaren van gegevens niet automatisch plaatsvindt met behulp van sensoren\n                                                wordt de bestuurder in staat gesteld om de desbetreffende informatie handmatig in\n                                                te voeren ofwel kan de verplichte informatie via een externe inrichting worden ingevoerd\n                                                waarna de bestuurder de informatie handmatig kan accepteren.\n\n3 Uitsluitend de laatste handmatig ingevoerde en geaccepteerde informatie kan door de\n                                                bestuurder worden geannuleerd. Deze handeling wordt door de boordcomputer geregistreerd.\n\n4 De sensoren die worden gebruikt voor de automatische gegevensregistratie genereren\n                                                en communiceren de benodigde gegevens op betrouwbare wijze.\n\n1 De tijd dat de auto rijdt, terwijl in de operationele modus het werkingsniveau arbeidstijd\n                                                is geselecteerd, wordt automatisch geregistreerd als rijtijd, tenzij er sprake is\n                                                van een pauze.\n\n2 De tijd waarin de auto stilstaat terwijl in de operationele modus het werkingsniveau\n                                                arbeidstijd is geselecteerd, wordt automatisch geregistreerd als andere werkzaamheden\n                                                dan rijden, tenzij er sprake is van een pauze.\n\n1 De boordcomputer:\n\na. detecteert het inbrengen en uitnemen van boordcomputerkaarten en de aanwezigheid van\n                                                      een boordcomputerkaart in de kaartinterface;\n\nb. negeert ingebrachte ongeldige boordcomputerkaarten;\n\nc. leest bij het inbrengen van een boordcomputerkaart binnen vijf seconden de noodzakelijke\n                                                      gegevens af om het kaarttype, de kaarthouder en de geldigheid van de kaart vast te\n                                                      stellen en registreert deze gegevens onmiddellijk;\n\nd. leest van de chauffeurskaart binnen vijf seconden de noodzakelijke gegevens af om\n                                                      de eerder gebruikte auto, de datum en het tijdstip van het einde van de laatste kaartsessie\n                                                      en de op dat moment geselecteerde activiteit te identificeren en om te controleren\n                                                      of de laatste kaartsessie correct is afgesloten en registreert deze gegevens onmiddellijk;\n\ne. authenticeert de houder van de boordcomputerkaart direct bij het inbrengen van de\n                                                      boordcomputerkaart op basis van een persoonlijk identificatie nummer;\n\nf. geeft selectieve toegangsrechten tot gegevens en functies op basis van het type boordcomputerkaart\n                                                      dat wordt ingevoerd, zoals beschreven in bijlage 1;\n\ng. blokkeert een kaartsessie als bedoeld in artikel 6.2 van bijlage 1 indien een boordcomputerkaart wordt uitgenomen zonder dat door de gebruiker is aangegeven\n                                                      dat de sessie be\u00ebindigd dient te worden;\n\nh. werkt op het moment van optreden de gegevens die op een geldige chauffeurskaart zijn\n                                                      opgeslagen bij met de gegevens, bedoeld in artikel 9, eerste lid;\n\ni. stelt de bestuurder in staat de op de chauffeurskaart opgeslagen gegevens, bedoeld\n                                                      in artikel 9, eerste lid, over te brengen naar de boordcomputer conform artikel 8 van bijlage 2;\n\nj. selecteert, leest en schrijft gegevens op de chauffeurskaart op de wijze zoals gespecificeerd\n                                                      in de hoofdstukken 5 en 6 en de paragrafen 8.9 tot en met 8.16 en 8.19 tot en met\n                                                      8.21 van bijlage 4;\n\nk. onderhoudt kaartsessies met chauffeurskaarten op de wijze zoals gespecificeerd in\n                                                      hoofdstuk 7 van bijlage 4;\n\nl. laat een chauffeurs- of inspectiekaart elektronische handtekeningen genereren op de\n                                                      wijze zoals gespecificeerd in paragraaf 8.5 van bijlage 4;\n\nm. laat een boordcomputerkaart authenticiteit handtekeningen genereren op de wijze zoals\n                                                      gespecificeerd in paragraaf 8.7 van bijlage 4;\n\nn. laat een boordcomputerkaart zich aan de boordcomputer authenticiteren op de wijze\n                                                      zoals gespecificeerd in paragraaf 8.8 van bijlage 4;\n\no. controleert op de chauffeurskaart geregistreerde gegevens en verwijdert gecorrumpeerde\n                                                      delen daarvan op de wijze zoals gespecificeerd in paragrafen 8.17 en 8.18 van bijlage 4;\n\np. onderhoudt het op de chauffeurskaart aanwezige logboek van de door de bestuurder uitgevoerde\n                                                      gegevensleveringen van chauffeurskaartdata (zoals gedefinieerd in artikel 8 van bijlage 2) op de wijze zoals gespecificeerd in de paragrafen 8.22 en 8.23 van bijlage 4;\n\nq. functioneert op correcte wijze met de systeemkaart;\n\nr. gaat tijdens de inschakeling na of het serienummer, bedoeld in artikel 22, tweede lid, onderdeel b, overeenkomt met het serienummer van de boordcomputer, zoals vastgelegd op de chip\n                                                      van de systeemkaart;\n\ns. koppelt zich, onder verantwoordelijkheid van de fabrikant, aan een vervangende systeemkaart\n                                                      op de wijze zoals gespecificeerd in hoofdstuk 3, in het bijzonder overeenkomstig het\n                                                      in paragraaf 3.1.2 gestelde, en overeenkomstig paragraaf 8.2 van bijlage 4;\n\nt. biedt, ter ondersteuning van het vervangingsproces, bedoeld in onderdeel s, een gebruikersinterface\n                                                      die faciliteert dat de vervanging van de systeemkaart, ongeacht de locatie, ook kan\n                                                      worden uitgevoerd door de fabrikant of werkplaats;\n\nu. communiceert met zijn systeemkaart op de wijze zoals gespecificeerd in hoofdstuk 4\n                                                      van bijlage 4;\n\nv. laat zijn systeemkaart elektronische handtekeningen genereren op de wijze zoals gespecificeerd\n                                                      in paragraaf 8.6 van bijlage 4;\n\nw. koppelt zich, onder verantwoordelijkheid van de fabrikant en in diens productiefaciliteit\n                                                      dan wel bij reeds in gebruik zijnde boordcomputers volgens een door de fabrikant opgesteld\n                                                      beveiligingsconcept dat naar het oordeel van de Dienst Wegverkeer minstens dezelfde\n                                                      bescherming waarborgt, aan een eerste systeemkaart op de wijze zoals gespecificeerd\n                                                      in hoofdstuk 3, in het bijzonder overeenkomstig het in paragraaf 3.1.1 gestelde, en\n                                                      overeenkomstig paragraaf 8.2 van bijlage 4.\n\n2 Voor het vaststellen van de geldigheid van de boordcomputerkaart, als bedoeld in het\n                                                eerste lid, onder c, verifieert de boordcomputer dat het boordcomputerkaartcertificaat\n                                                is uitgegeven door een certificatieautoriteit die daarvoor door de minister is geautoriseerd\n                                                en valideert de boordcomputer daarbij de geldigheid van het volledige certificeringspad\n                                                tot en met het relevante stamcertificaat van de Staat der Nederlanden.\n\n3 Indien zich een fout voordoet bij het lezen of het schrijven van gegevens naar de\n                                                boordcomputerkaart, voert de boordcomputer dezelfde leesopdracht onderscheidenlijk\n                                                schrijfopdracht maximaal drie keer uit.\n\n4 Nadat een kaartsessie is gestart werkt de boordcomputer de gegevens die op een geldige\n                                                chauffeurskaart zijn opgeslagen bij met de volgende gegevens:\n\na. het kenteken van de auto, en\n\nb. het nummer van de ondernemerskaart van de vervoerder zoals vastgelegd in de ingeschakelde\n                                                      bedrijfsvergrendeling.\n\n1 Voordat een kaart wordt uitgenomen zorgt de boordcomputer ervoor dat de kaartsessie\n                                                volledig en succesvol wordt be\u00ebindigd.\n\n2 Het be\u00ebindigen van de kaartsessie vereist de aanwezigheid van de boordcomputerkaart\n                                                in de kaartlezer en is alleen mogelijk indien de auto niet rijdt.\n\n3 Na het be\u00ebindigen van een kaartsessie schakelt de boordcomputer automatisch over naar\n                                                de operationele modus, werkingsniveau basis.\n\n4 De handelingen, bedoeld in het eerste en derde lid, nemen maximaal vijf seconden in\n                                                beslag.\n\n1 De boordcomputer beheert de bedrijfsvergrendelingen die een vervoerder aanbrengt in\n                                                de bedrijfsmodus.\n\n2 De bedrijfsvergrendeling verhindert inzage in de geregistreerde gegevens voor anderen\n                                                dan de vervoerder voor wie de gegevens zijn geregistreerd, met uitzondering van de\n                                                houder van een inspectie- of werkplaatskaart.\n\n3 Indien de ondernemerskaart in de kaartlezer wordt ingebracht wordt de bedrijfsvergrendeling\n                                                automatisch ingeschakeld, waarna de ondernemerskaart kan worden uitgenomen.\n\n4 Een bedrijfsvergrendeling bestaat uit de registratie van het personenvervoernummer\n                                                dat staat aangegeven op de vergunning, bedoeld in artikel 4, derde lid, van de Wet personenvervoer 2000, het aan de vervoerder toegekende unieke nummer, als bedoeld in artikel 9, onderdeel a, van de Handelsregisterwet 2007, het nummer van de ondernemerskaart, de datum en het tijdstip van de inschakeling\n                                                en, voor zover van toepassing, de datum en het tijdstip van de uitschakeling van de\n                                                bedrijfsvergrendeling.\n\n5 Een bedrijfsvergrendeling schakelt automatisch uit wanneer een andere vervoerder de\n                                                vergrendeling inschakelt.\n\n6 Bij de eerste bedrijfsvergrendeling voor de betreffende vervoerder stelt de boordcomputer\n                                                de ondernemer in staat handmatig de gegevens, bedoeld in artikel 11, onderdelen c en d, in te voeren.\n\n7 De boordcomputer stelt de vervoerder in staat om via de bedrijfsvergrendeling de gegevens,\n                                                bedoeld in het zesde lid, te wijzigen.\n\n1 De boordcomputer kan alle geregistreerde gegevens lezen.\n\n2 Het geheugen houdt bij normaal gebruik alle geregistreerde gegevens ten minste 26\n                                                weken vast, met uitzondering van de gegevens, bedoeld in de artikelen 22, tweede en vijfde lid, en 25, zesde lid.\n\n3 Wanneer de geheugencapaciteit volledig gebruikt is komen de meest recente gegevens\n                                                in de plaats van de oudste gegevens, met uitzondering van de gegevens bedoeld in artikel 22, tweede en vijfde lid.\n\n4 Een stroomonderbreking van minder dan twaalf maanden be\u00efnvloedt de in het geheugen\n                                                opgeslagen gegevens niet.\n\n5 De identificatiegegevens, bedoeld in het artikel 22, tweede en vijfde lid, worden nooit be\u00efnvloed door een stroomonderbreking.\n\n1 Indien op basis van deze regeling geen andere informatie getoond behoeft te worden,\n                                                toont de boordcomputer standaard de volgende gegevens:\n\na. de werkingsmodus en eventueel het werkingsniveau, bedoeld in artikel 4, eerste en tweede lid;\n\nb. de kilometerstand, en\n\nc. de plaatselijke datum en tijd.\n\n2 Op verzoek van de gebruiker toont de boordcomputer de actuele waarden van de gegevens,\n                                                bedoeld in artikel 22 tweede en vijfde lid.\n\n3 Op verzoek van de gebruiker toont de boordcomputer, naast de gegevens bedoeld in het\n                                                eerste lid en tweede lid, gegevens waarvoor de gebruiker geautoriseerd is.\n\n4 Getoonde gegevens komen overeen met geregistreerde gegevens.\n\n5 Het leesvenster is ingeschakeld indien de boordcomputer is ingeschakeld.\n\n1 In niet-geactiveerde toestand registreert de boordcomputer, uitgezonderd de gegevens,\n                                                bedoeld in het tweede lid, geen gegevens en kan de boordcomputer uitsluitend de functies\n                                                voor activering danwel deactivering uitvoeren.\n\n2 De boordcomputer registreert de volgende identificatiegegevens van de boordcomputer\n                                                voor de levensduur van de boordcomputer:\n\na. de naam van de fabrikant;\n\nb. het serienummer van de boordcomputer;\n\nc. het versienummer en de datum van installatie van de programmatuur;\n\nd. het versienummer en de datum van installatie van programmatuurrevisies;\n\ne. het bouwjaar, en\n\nf. het goedkeuringsnummer.\n\n3 De activering van de boordcomputer vindt plaats in de activerings- en keuringsmodus.\n\n4 Wanneer de boordcomputer zich in de niet-geactiveerde toestand bevindt wordt de activeringsfunctie\n                                                van de boordcomputer automatisch opgestart bij de eerste invoer van een keuringskaart.\n\n5 Bij de activering van de boordcomputer worden de volgende gegevens tot het moment\n                                                van deactivering geregistreerd:\n\na. het kenteken van de auto;\n\nb. de kilometerstand van de auto bij activering;\n\nc. de datum en het tijdstip van de activering;\n\nd. het nummer van de keuringskaart;\n\ne. de constante van de boordcomputer in impulsen per kilometer;\n\nf. de effectieve omtrek van de wielbanden in millimeters;\n\ng. de bandenmaat van de auto;\n\nh. de aanwezigheid van een koppeling met de taxameter, en\n\ni. resultaat van het activeringsonderzoek en eventuele opmerkingen.\n\n6 De boordcomputer stelt de gebruiker tijdens de activering in staat de impulsen te\n                                                tellen om te komen tot de constante van de boordcomputer.\n\n7 Na activering is de boordcomputer volledig operationeel en kan deze, uitgezonderd\n                                                activering zelf, alle functies uitvoeren.\n\n1 De deactivering van de boordcomputer vindt plaats in de activerings- en keuringsmodus.\n\n2 Bij de deactivering van de boordcomputer worden alle in het geheugen geregistreerde\n                                                gegevens overgebracht naar een externe gegevensdrager, met uitzondering van de gegevens,\n                                                bedoeld in artikel 6, vijfde lid.\n\n3 Onverminderd het tweede lid kunnen de gegevens, bedoeld in artikel 6, vijfde lid, na een verzoek daartoe, uitsluitend bij deactivering worden overgebracht nadat naast\n                                                de authenticatie op basis van een keuringskaart tevens een authenticatie op basis\n                                                van een inspectiekaart heeft plaatsgevonden.\n\n4 De ingevolge het tweede en derde lid overgebrachte gegevens worden na een succesvolle\n                                                overbrenging ervan gewist, met uitzondering van de gegevens, bedoeld in artikel 22, tweede lid.\n\n5 De boordcomputer geraakt na deactivering in inactieve toestand en kan van daaruit\n                                                uitsluitend de activeringsmodus en de keuringsmodus aannemen.\n\n1 Het onderzoek van de boordcomputer vindt plaats in de activerings- en keuringsmodus.\n\n2 Tijdens het onderzoek registreert de boordcomputer de volgende gegevens tot deactivering:\n\na. de datum en het tijdstip waarop het onderzoek wordt uitgevoerd;\n\nb. het nummer van de keuringskaart, en\n\nc. het resultaat van het onderzoek en eventuele opmerkingen.\n\n3 Tijdens het onderzoek kunnen de gegevens, bedoeld in artikel 22, vijfde lid, onderdelen e tot en met h, aangepast worden. De nieuw ingevoerde gegevens worden tot deactivering geregistreerd\n                                                en door de boordcomputer gebruikt.\n\n4 Indien de gegevens, bedoeld in artikel 22, vijfde lid, onderdelen e tot en met g, worden aangepast, worden de oude gegevens niet overschreven.\n\n1 De boordcomputer is voorzien van een diagnosemechanisme dat ten minste het volgende\n                                                vaststelt:\n\na. gebeurtenissen als bedoeld in bijlage 1, artikel 6.5, onderdeel FAU_GEN1.1;\n\nb. fouten als bedoeld in artikel 26, eerste lid;\n\nc. storingen als bedoeld in artikel 26, derde lid.\n\n2 Het diagnosemechanisme is niet toegankelijk voor de gebruiker of uitschakelbaar door\n                                                de gebruiker.\n\n3 Bij het opstarten voert de boordcomputer een zelfbeproeving uit. De zelfbeproeving\n                                                bevat ten minste een verificatie van de integriteit van de uitvoercode van de boordcomputer,\n                                                een verificatie van de integriteit van geregistreerde systeemgegevens en het bestaan\n                                                van storingen als bedoeld in artikel 26, zevende lid.\n\n4 Naast de zelfbeproeving als bedoeld in het derde lid, kan op ieder gewenst moment\n                                                een ingebouwde beproeving worden gestart. De ingebouwde beproeving stelt de gebruiker\n                                                in staat vast te stellen of de boordcomputer op correcte wijze functioneert.\n\n5 Op het moment van optreden registreert de boordcomputer de gebeurtenis, fout of storing,\n                                                waarbij per optreden ten minste de gegevens worden vastgelegd zoals beschreven in\n                                                bijlage 1, artikel 6.5, onderdeel FAU_GEN.1.2.\n\n6 De boordcomputer beschikt bij normaal gebruik over voldoende opslagcapaciteit voor\n                                                het vastleggen van gebeurtenissen, fouten en storingen over een periode van ten minste\n                                                52 weken.\n\n1 Een fout treedt op wanneer de correcte werking van de boordcomputer gedurende korte\n                                                tijd wordt onderbroken.\n\n2 De boordcomputer detecteert ten minste de volgende fouten:\n\na. een integriteitfout in de uitvoercode;\n\nb. een integriteitfout in de systeemgegevens;\n\nc. een integriteitfout in de opgeslagen gebruikersgegevens;\n\nd. een integriteitfout bij de gegevensuitvoer naar de chauffeurskaart;\n\ne. een fout in de registratiefunctie;\n\nf. een fout die de beveiliging, bedoeld in artikel 31, van de boordcomputer in gevaar brengt;\n\ng. een fout bij de gegevensuitvoer naar externe inrichtingen;\n\nh. een fout bij het gebruik van de systeemkaart;\n\ni. een fout bij het gebruik van de boordcomputerkaart;\n\nj. een fout in de bewegingsensor;\n\nk. een fout in de positiebepalingsensor;\n\nl. een fout in de koppeling met de taxameter.\n\n3 Een storing treedt op wanneer een onderbreking in de correcte werking van de boordcomputer\n                                                door een gebeurtenis of fout een permanent karakter heeft.\n\n4 De boordcomputer detecteert ten minste de volgende storingen:\n\na. een storing in de werking van de registratiefunctie;\n\nb. een storing in de werking van de beveiligingsfuncties;\n\nc. een storing in de werking van de sensoren;\n\nd. een storing in de overbrenging naar een externe interface zoals beschreven in bijlage\n                                                      2;\n\ne. een storing in de werking van de systeemkaart;\n\nf. een storing in de werking van de boordcomputerkaarten.\n\n5 Bij het vastleggen van gebeurtenissen, fouten en storingen koppelt de boordcomputer\n                                                daar een code aan, zoals beschreven in bijlage 2, artikel 6, zevende lid.\n\n6 Zolang de correcte werking van de beveiligingsfuncties, bedoeld in artikel 31, gegarandeerd is, blijft de boordcomputer na het detecteren van een fout doorgaan\n                                                met het registreren van gegevens. Deze gegevens worden zodanig in de boordcomputer\n                                                geregistreerd dat ze herkenbaar zijn als zijnde geregistreerd gedurende een periode\n                                                waarin zich \u00e9\u00e9n of meerdere fouten hebben voorgedaan.\n\n7 De boordcomputer staakt het uitvoeren van verdere handelingen wanneer een storing\n                                                wordt gedetecteerd als bedoeld in het vierde lid, onderdelen a, b, c en e.\n\n1 Het optreden van de onderstaande gebeurtenissen leidt tot een fout als bedoeld in\n                                                artikel 26, tweede lid, onderdeel i:\n\na. het inbrengen van een ongeldige boordcomputerkaart;\n\nb. het inbrengen van een chauffeurskaart waarvan blijkt dat de datum en het tijdstip\n                                                      van de laatste registratie op de chauffeurskaart, op een later tijdstip valt dan de\n                                                      actuele datum en het tijdstip van de boordcomputer;\n\nc. het niet op een juiste wijze afsluiten van een kaartsessie;\n\nd. het inbrengen van een chauffeurskaart waarvan blijkt dat de laatste kaartsessie niet\n                                                      juist is afgesloten;\n\ne. het ontstaan van onvoldoende opslagcapaciteit op de chauffeurskaart;\n\nf. een niet-succesvolle authenticatiepoging;\n\ng. het gedurende een periode van 28 kalenderdagen gebruiken van de operationele modus,\n                                                      werkingsniveau arbeidstijd, zonder geldige boordcomputerkaart.\n\n2 .*Het optreden van de onderstaande gebeurtenissen leidt tot een fout als bedoeld in\n                                                artikel 26, tweede lid, onderdeel e:\n\na. het ontstaan van onvoldoende opslagcapaciteit op het geheugen van de boordcomputer,\n                                                      en\n\nb. een onderbreking van ten minste vijf seconden in de stroomvoorziening van de boordcomputer.\n\n3 Het optreden van een toestand verplaatsen zonder dat er een toestand rijden wordt\n                                                waargenomen leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel j, tenzij er een toestand rijden is vastgesteld in de 20 seconden voor of na het optreden\n                                                van de toestand verplaatsen.\n\n4 Het gedurende vijf minuten niet kunnen verkrijgen van positiegegevens leidt tot een\n                                                fout als bedoeld in artikel 26, tweede lid, onderdeel k.\n\n5 Een afwijking die de waarden, bedoeld in artikel 7, vijfde lid, overschrijdt leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdelen j en k.\n\n6 Het optreden van gebeurtenissen die kunnen duiden op het in gevaar brengen van de\n                                                beveiliging van de boordcomputer, bedoeld in artikel 31, leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel f.\n\n7 Het vanuit de bedrijfsmodus gedurende 365 kalenderdagen niet overbrengen van gegevens\n                                                bedoeld in artikel 12, leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel g.\n\n1 Het optreden van fouten als bedoeld in artikel 26 tweede lid onderdelen a, b, of c, leidt tot een storing bedoeld in artikel 26 vierde lid, onderdeel b.\n\n2 Het meer dan tien maal optreden binnen 30 kalenderdagen van een gebeurtenis als bedoeld\n                                                in artikel 27, tweede lid, onderdeel b, leidt tot een storing als bedoeld in artikel 26 vierde lid, onderdeel a.\n\n3 Het langer dan 24 uur bestaan van de fout, bedoeld in artikel 26, tweede lid, onderdeel j of onderdeel k, leidt tot een storing als bedoeld in artikel 26, vierde lid, onderdeel c.\n\n4 Het optreden van de fout, bedoeld in artikel 26, tweede lid, onderdeel f, leidt tot een storing als bedoeld in artikel 26, vierde lid, onderdeel b.\n\n5 Het meer dan 100 maal optreden binnen een kalenderdag van een gebeurtenis als bedoeld\n                                                in artikel 26, tweede lid, onderdeel j of k, leidt tot een storing als bedoeld in artikel 26, vierde lid, onderdeel c.\n\n1 De boordcomputer waarschuwt de gebruiker zodra het volgende wordt gedetecteerd:\n\na. het optreden en eindigen van fouten in de werking van de boordcomputer genoemd in\n                                                      artikel 26, tweede lid;\n\nb. het optreden en eindigen van storingen in de werking van de boordcomputer genoemd\n                                                      in artikel 26, vierde lid.\n\n2 De waarschuwingssignalen worden in ieder geval in visuele vorm weergegeven.\n\n3 De waarschuwingssignalen zijn zowel overdag als \u2019s nachts duidelijk afleesbaar en\n                                                herkenbaar en bevinden zich binnen het gezichtsveld van de bestuurder.\n\n4 Indien zich een fout of gebeurtenis voordoet als bedoeld in het eerste lid, onderdelen\n                                                a en b, wordt de reden van de waarschuwing getoond. Behoudens het vijfde lid blijft\n                                                de waarschuwing zichtbaar zo lang de fout of gebeurtenis voortduurt met een maximum\n                                                van dertig seconden na het optreden daarvan.\n\n5 De waarschuwing, bedoeld in het vierde lid, blijft zichtbaar totdat de gebruiker handmatig\n                                                bevestigt de waarschuwing te hebben opgemerkt:\n\na. ingeval van een storing;\n\nb. na de tweede, vierde, zesde en achtste onderbreking van ten minste vijf seconden in\n                                                      de stroomvoorziening van de boordcomputer;\n\nc. na het verstrijken van het zesde, twaalfde en achttiende uur na detectie van een fout in de bewegingsensor of de positiebepalingsensor; en\n\nd. na de vijfentwintigste, vijftigste en vijfenzeventigste detectie binnen een kalenderdag\n                                                      van een fout in de bewegingsensor of de positiebepalingsensor.\n\n1 De boordcomputer voldoet aan de eisen die zijn neergelegd in NEN-ISO 10605 Severity\n                                                level III. Met ESD contact ontladingen met 7 kV, ESD lucht ontladingen met 14 kV en\n                                                Functional Status Classification A.\n\n2 De boordcomputer voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-1\n                                                en NEN-EN-IEC 60068-2-2 en functioneert naar behoren binnen het temperatuurbereik\n                                                van -20 \u00b0C tot +70 \u00b0C waarbij:\n\na. Conformiteit aan IEC 60068-2-1 wordt aangetoond volgens testtype Ad gedurende 16 uur,\n                                                      en\n\nb. Conformiteit aan IEC 60068-2-2 wordt aangetoond volgens testtype Bd gedurende 16 uur.\n\n3 De boordcomputer voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-30\n                                                en functioneert naar behoren binnen het vochtigheidsbereik van 10% tot 90% relatieve\n                                                vochtigheid, aangetoond volgens testtype Db gedurende 24 uur met 6 cycli.\n\n4 De boordcomputer is beveiligd tegen kortsluiting, overspanning en polariteitomkering.\n\n5 De boordcomputer is bestand tegen kortstondige onderbrekingen of voedingspanningvariaties\n                                                die worden veroorzaakt door het starten van de auto.\n\n1 De boordcomputer is voorzien van beveiligingsfuncties die de juiste en betrouwbare\n                                                werking van de boordcomputer waarborgen.\n\n2 De beveiligingsfuncties, bedoeld in het eerste lid, voldoen aan de beveiligings-doelstellingen\n                                                en de beveiligingseisen bedoeld in bijlage 1.\n\n3 De boordcomputer verifieert programmatuurrevisies door middel van een programmatuur\n                                                veiligheidscertificatie, voordat deze in de boordcomputer ge\u00efmplementeerd worden.\n\n4 De boordcomputer vereist activerings- en keuringsmodus voor het implementeren van\n                                                programmatuurrevisies die op aangeven van de fabrikant door de Dienst Wegverkeer zijn\n                                                aangemerkt als revisies die werkzaamheden vereisen als bedoeld in artikel 13, onder b van de Regeling erkenning werkplaatsen boordcomputer taxi.\n\n5 Implementeren van programmatuurrevisies als bedoeld in het vierde lid vindt uitsluitend\n                                                in een erkende werkplaats plaats.\n\n6 De boordcomputer biedt de mogelijkheid om informatie meer dan \u00e9\u00e9n keer te voorzien\n                                                van een elektronische handtekening.\n\n7 Bij het plaatsen van de elektronische handtekening blijft de informatie in de oorspronkelijke\n                                                vorm behouden. De handtekening wordt als bijlage aan de ondertekende informatie toegevoegd,\n                                                zodat de oorspronkelijke gegevens leesbaar zijn voor applicaties die geen elektronische\n                                                handtekening ondersteunen.\n\nDe fabrikant voorziet erin dat de pin-code van de boordcomputerkaart gedeblokkeerd\n                                          en gewijzigd kan worden op de wijze zoals gespecificeerd in de paragrafen 8.1, 8.3\n                                          en 8.4 van bijlage 4.\n\n1 De Dienst Wegverkeer verleent een nationale typegoedkeuring voor een boordcomputer\n                                             die voldoet aan de in paragraaf 2 opgenomen eisen.\n\n2 Tenzij in deze regeling anders is bepaald, is afdeling 1 van hoofdstuk 3 van de Regeling voertuigen van overeenkomstige toepassing op alle aspecten van de nationale typegoedkeuring\n                                             van een boordcomputer en wijzigingen daarvan.\n\n1 Bij een aanvraag als bedoeld in artikel 32, eerste lid, overlegt de fabrikant in elk geval de volgende bescheiden in de Nederlandse of Engelse\n                                             taal:\n\na. de specificaties volgens welke de boordcomputer is gebouwd;\n\nb. een evaluatierapport waaruit blijkt dat het voldoen aan de eisen uit bijlage 1 bij deze regeling is getoetst door een laboratorium dat door een bij het Common Criteria\n                                                   Recognition Agreement aangesloten accreditatie-instelling is geaccrediteerd voor het\n                                                   uitvoeren van Common Criteria evaluaties;\n\nc. de documenten die behoren bij het in onderdeel b bedoelde certificaat waarin de beveiligingsdoelstellingen\n                                                   en de door de certificerende instelling gemaakte opmerkingen zijn opgenomen;\n\nd. \u00e9\u00e9n of meerdere testrapporten die zijn opgesteld door een testinstelling die werkt\n                                                   overeenkomstig ISO-IEC 17025, dan wel overeenkomstig kwaliteitsstandaarden die aantoonbaar\n                                                   een vergelijkbaar beschermingsniveau bieden, waaruit eenduidig blijkt:\n\n1\u00b0. dat de boordcomputer voldoet aan de in paragraaf 2 opgenomen eisen voor zover deze eisen niet vallen onder het certificaat als bedoeld\n                                                         in onderdeel b, en\n\n2\u00b0. op welke wijze dat is vastgesteld;\n\ne. een schriftelijke en ondertekende verklaring van de fabrikant waarin deze verklaart\n                                                   dat hij de boordcomputer gaat produceren en dat de ingevolge onderdeel a overgelegde\n                                                   technische specificaties identiek zijn aan de technische specificaties waarvoor het\n                                                   beveiligingscertificaat en de in onderdeel d bedoelde testrapporten zijn afgegeven;\n\nf. een beschrijving van de organisatorische maatregelen die zijn of zullen worden getroffen\n                                                   teneinde te borgen dat de te produceren boordcomputers zullen overeenstemmen met het\n                                                   goedgekeurde type, en\n\ng. een gebruikers- en installatiehandleiding.\n\n2 Bij een aanvraag als bedoeld in artikel 32, eerste lid, wordt door de fabrikant voor de keuring een exemplaar van de boordcomputer ter beschikking\n                                             van de Dienst Wegverkeer gesteld.\n\n3 De Dienst Wegverkeer kan in verband met de uitvoering van de typegoedkeuring bij de\n                                             testinstelling die \u00e9\u00e9n of meerdere door de fabrikant overgelegde testrapporten, bedoeld\n                                             in het eerste lid, onderdeel d, heeft opgesteld, nadere gegevens opvragen of een onderzoek\n                                             ter plaatse uitvoeren voor zover dit nodig is voor de beoordeling van deze testrapporten.\n\n4 De fabrikant draagt zorg voor de medewerking van de door hem ingeschakelde testinstellingen\n                                             aan het in het vorige lid bedoelde opvragen van gegevens of uit te voeren nader onderzoek.\n\n5 Na verlening van typegoedkeuring door de Dienst Wegverkeer, verstrekt de minister\n                                             op aanvraag en na betaling van het daarvoor verschuldigde tarief, aan de betreffende\n                                             fabrikant systeemkaarten die alleen ten behoeve van inbouw in de te produceren typegoedgekeurde\n                                             boordcomputers mogen worden aangewend.\n\n[Vervallen per 19-12-2020]\n\n1 In de bij de programmatuur behorende programmatuurgegevens neemt de fabrikant ten\n                                             minste de volgende gegevens op:\n\na. een programmatuurversienummer waarmee de combinatie van programmatuur en bijbehorende\n                                                   progammatuurgegevens uniek identificeerbaar is, en\n\nb. de certificaten of publieke sleutels van alle certificatieautoriteiten waarmee de\n                                                   authenticiteit en geldigheid van de certificaten van boordcomputerkaarten en systeemkaarten\n                                                   kan worden geverifieerd.\n\n2 In de bij een programmatuurrevisie behorende programmatuurgegevens neemt de fabrikant\n                                             ten minste de volgende gegevens op:\n\na. een programmatuurversienummer waarmee de combinatie van programmatuurrevisie en bijbehorende\n                                                   progammatuurgegevens uniek identificeerbaar is,\n\nb. eventuele aanvullende of vervangende certificaten of publieke sleutels als bedoeld\n                                                   in het tweede lid onder b, en\n\nc. een attribuut dat aanduidt of implementeren van de betreffende programmatuurrevisie\n                                                   al dan niet gevolgd moet worden door werkzaamheden als bedoeld in artikel 13, onder b, van de Regeling erkenning werkplaatsen boordcomputer taxi.\n\n3 De fabrikant distribueert de programmatuurrevisie inclusief de bijbehorende programmatuurgegevens\n                                             niet eerder dan na een positieve beoordeling door de Dienst Wegverkeer.\n\n4 De boordcomputer vervangt de programmatuur met een programmatuurrevisie uitsluitend\n                                             nadat de authenticiteit van de programmatuurrevisie is geverifieerd en uitsluitend\n                                             in een van de volgende twee situaties:\n\na. indien de boordcomputer zich in de operationele modus, werkingsniveau basis, bevindt\n                                                   en het attribuut, bedoeld in het derde lid, onder c, aanduidt dat het implementeren\n                                                   van de programmatuurrevisie niet gevolgd hoeft te worden door werkzaamheden als bedoeld\n                                                   in artikel 13, onder b, van de Regeling erkenning werkplaatsen boordcomputer taxi;\n\nb. indien de boordcomputer zich in de activerings- en keuringsmodus bevindt.\n\n5 Na vervanging van de programmatuur met een programmatuurrevisie neemt de boordcomputer\n                                             het programmatuurversienummer van de programmatuurrevisie over als het programmatuurversienummer\n                                             van de programmatuur.\n\n[Vervallen per 19-12-2020]\n\n1 Van een wijziging van de normbladen waarnaar in deze regeling verwezen wordt, doet\n                                             de minister mededeling in de Staatscourant.\n\n2 Een wijziging in een normblad heeft voor deze regeling pas rechtsgevolgen op 1 januari\n                                             van het jaar volgende op dat waarin de mededeling bedoeld in het eerste lid heeft\n                                             plaatsgevonden.\n\n[Vervallen per 19-12-2020]\n\nDe Regeling boordcomputer taxi wordt ingetrokken.\n\nDeze regeling wordt aangehaald als: Regeling specificaties en typegoedkeuring boordcomputer\n                                       taxi.\n\nDeze regeling treedt in werking met ingang van 1 oktober 2010.\n\nDeze regeling zal met de toelichting in de Staatscourant worden geplaatst.\n\nMinister\n\nC.M.P.S. Eurlings\n\nVersie 1.8\n\nDatum 6\u00a0februari 205\n\nStatus Defnitief\n\nArtikel 1\n\nIntroductie\n\n8\n\nArtikel 2\n\nAfkortingen, acroniemen, definities en referenties\n\n8\n\nArtikel 2.1\n\nPP Referentie\n\n8\n\nArtikel 2.2\n\nClaim voor voldoen aan de Common Criteria\n\n9\n\nArtikel 2.3\n\nNotities\n\n9\n\nArtikel 2.4\n\nAfkortingen en acroniemen\n\n9\n\nArtikel 2.5\n\nReferentienormen\n\n9\n\nArtikel 3\n\nOverzicht van de TOE\n\n10\n\nArtikel 3.1\n\nBeschrijving van de TOE\n\n10\n\nArtikel 3.2\n\nLevenscyclus van de TOE\n\n11\n\nArtikel 3.3\n\nEntiteiten\n\n13\n\nArtikel 3.3.1\n\nSubjecten \u2013 middelen\n\n13\n\nArtikel 3.3.2\n\nSubjecten \u2013 gebruikers\n\n14\n\nArtikel 3.3.3\n\nObjecten\n\n14\n\nArtikel 3.4\n\nBegrenzingen van de TOE\n\n16\n\nArtikel 4\n\nBeveiligingsprobleem\n\n17\n\nArtikel 4.1\n\nBeveiligingsbeleid\n\n17\n\nArtikel 4.2\n\nAannames\n\n19\n\nArtikel 5\n\nBeveiligingsdoelstellingen\n\n19\n\nArtikel 5.1\n\nBeveiligingsdoelen voor de TOE\n\n19\n\nArtikel 5.2\n\nBeveiligingsdoelen voor de omgeving\n\n20\n\nArtikel 6\n\nFunctionele beveiligingseisen\n\n21\n\nArtikel 6.1\n\nBeveiligingsrollen\n\n22\n\nArtikel 6.2\n\nIdentificatie en Authenticatie\n\n22\n\nArtikel 6.3\n\nBCT-toegangsbeleid\n\n23\n\nArtikel 6.4\n\nHandtekeningen\n\n25\n\nArtikel 6.5\n\nBeveiligingsaudit\n\n26\n\nArtikel 6.6\n\nBescherming van de BCT\n\n28\n\nArtikel 7\n\nGarantieniveau\n\n28\n\nArtikel 8\n\nRationale\n\n29\n\nArtikel 8.1\n\nBeveiligingsdoelstellingen\n\n29\n\nArtikel 8.1.1\n\nBeveiligingsbeleid\n\n29\n\nArtikel 8.1.2\n\nAannames\n\n30\n\nArtikel 8.2\n\nBeveiligingsdoelstellingen voor de TOE\n\n30\n\nArtikel 8.3\n\nAfhankelijkheden\n\n31\n\nDeze bijlage is een beveiligingsprofiel (Protection Profile) voor de voertuigcomponenten\n                                       van de boordcomputer in overeenstemming met de Common Criteria versie 3.1. Het beveiligingsprofiel\n                                       geeft een beschrijving van het door de boordcomputer te implementeren beleid, de te\n                                       realiseren beveiligingsdoelstellingen, en de te behalen beveiligingseisen, alsmede\n                                       het vereiste garantieniveau voor de boordcomputer, zoals afgeleid is bij een eerdere\n                                       afhankelijkheids- en kwetsbaarheidsanalyse.\n\nDit beveiligingsprofiel voor de boordcomputer is opgesteld voor de Inspectie Leefomgeving\n                                       en Transport van het Ministerie van Infrastructuur en Milieu.\n\nDit document is het \u2018Beveiligingsprofiel Boordcomputer Taxi\u2019 (PP-BCT) Versie 1.8,\n                                          6\u00a0februari 2015.\n\nDit beveiligingsprofiel voldoet aan Common Criteria versie 3.1 Revisie 4. Hoewel de\n                                          \u2018International English\u2019 versie is gebruikt voor het ontwikkelen van dit beveiligingsprofiel,\n                                          is (met toestemming van het certificeringsschema) dit profiel in het Nederlands.\n\nDit beveiligingsprofiel:\n\n\u25cb is CC Deel 2 conform;\n\n\u25cb is CC Deel 3 conform;\n\n\u25cb is EAL3 conform;\n\n\u25cb claimt niet te voldoen aan andere beveiligingsprofielen;\n\n\u25cb vereist strikte conformering van andere beveiligingsprofielen (PPs) of beveiligingsspecificaties\n                                                (STs) die aan dit beveiligingsprofiel willen voldoen.\n\nDit document volgt de naamgeving en notaties voor beveiligingsprofielen volgens de\n                                          Common Criteria standaard. Er zijn unieke labels toegewezen aan entiteiten zodat deze\n                                          gemakkelijk terug te vinden zijn. De labels beginnen met \u00e9\u00e9n van de onderstaande karakters:\n\nA\n\nAssumption (aanname)\n\nO\n\nObject (object)\n\nOE\n\nSecurity objective for the Environment (omgevingsdoelstellingen)\n\nOT\n\nSecurity objective for the TOE (beveiligingsdoelstelling)\n\nP\n\nOrganisational Security Policy (beleid)\n\nS\n\nSubject (persoon, middel of een proces)\n\nCA\n\nCertificatieautoriteit\n\nCC\n\nCommon Criteria (referentienorm)\n\nCEN\n\nEuropean Committee for Standardization\n\nCWA\n\nCENWorkshop Agreements\n\nEAL\n\nEvaluation Assurance Level (garantieniveau)\n\nEH\n\nElektronische handtekening\n\nEPROM\n\nErasable Programmable Read Only Memory\n\nETSI\n\nEuropean Telecommunications Standards Institute\n\nFIPS\n\nFederal Information Processing Standards\n\nGNSS\n\nGlobal Navigation Satellite System\n\nIEC\n\nInternational Electrotechnical Commission\n\nIETF\n\nInternet Engineering Task Force\n\nISO\n\nInternational Organisation for Standardisation\n\nPIN\n\nPersonal identification number (PIN-code)\n\nPP\n\nProtection Profile (Beveiligingsprofiel)\n\nPKI\n\nPublic Key Infrastructure (publieke sleutel methodiek)\n\nPUB\n\nPublic\n\nROM\n\nRead Only Memory (ROM-geheugen)\n\nRFC\n\nRequest for Comments\n\nSFP\n\nSecurity Function Policy\n\nSFR\n\nSecurity Functional Requirement (Beveiligingseis)\n\nSHA\n\nSecure Hash Algorithm\n\nST\n\nSecurity Target (Beveiligingsspecificatie)\n\nTOE\n\nTarget of Evaluation (onderwerp van de evaluatie)\n\nTS\n\nTechnical Standard\n\nTSF\n\nTOE Security Functionality\n\nTSFI\n\nTSF Interface\n\nDe TOE wordt getoetst conform het normenkader van Common Criteria for Information\n                                          Technology Security Evaluation, versie 3.1, revisie 3, July 2009.\n\nDe TOE ondersteunt de volgende standaarden wanneer cryptografische bewerkingen dienen\n                                          te worden uitgevoerd:\n\n\u25cb Het SHA cryptografische algoritme voor hash functies zoals gedefinieerd in de ISO/IEC\n                                                10118-3, FIPS PUB 180-2 en ETSI TS 102 176-1 standaarden;\n\n\u25cb ETSI TS 101 733 Electronic Signature Formats en de FIPS PUB 186-2 standaarden voor\n                                                elektronische handtekeningen;\n\nDe TOE is een controleapparaat bedoeld voor installatie in auto\u2019s gebruikt voor taxivervoer.\n                                          Het doel is om handhavingprocessen te helpen uitvoeren door de elektronische registratie\n                                          van de ritadministratie en de arbeids-, rij- en rusttijden en het op aanvraag ter\n                                          beschikking stellen van deze informatie aan bevoegde personen ter controle.\n\nDe TOE kent vier werkingsmodi, te weten: operationele modus, controle modus, activering/keuringsmodus\n                                          en bedrijfsmodus. De operationele modus kent drie werkingsniveaus: basis, arbeidstijd\n                                          en taxivervoer. Wanneer taxivervoer wordt aangeboden of arbeidstijd plaatsheeft, selecteert\n                                          de bestuurder handmatig het corresponderende werkingsniveau. In de operationele modus,\n                                          werkingsniveau arbeidstijd of taxivervoer, worden gegevens geregistreerd over de uitgevoerde\n                                          taxiritten en de arbeids-, rij-, en rusttijden van de bestuurder. De aanvang en het\n                                          be\u00ebindigen van een rit wordt door een actieve bedieningshandeling van de bestuurder\n                                          bij de TOE kenbaar gemaakt. Hierbij dient de beladingtoestand (beladen/onbeladen)\n                                          te worden aangegeven.\n\nDaarnaast draagt de TOE in alle modi zorg voor het beschikbaar stellen van de basisgegevens\n                                          tijd en afgelegde afstand, en de positie van het voertuig. In het werkingsniveau basis\n                                          wordt ook de registratie van gebeurtenissen gevoerd. In de operationele modus is het\n                                          werkingsniveau basis een apart werkingsniveau. In de overige modi integreert de TOE\n                                          de basis functionaliteit met de overige functionaliteit van de betreffende modus.\n\nDe TOE bestaat ten minste uit een verwerkingseenheid, een geheugen, een tijdklok,\n                                          een ISO 7816 kaartinterface, een ISO 7810 ID-000 kaartinterface ten behoeve van de\n                                          systeemkaart, een positiebepalingssensor of een interface voor de positiebepalingssensor,\n                                          een verplaatsingsopnemer, een interface voor de bewegingsopnemer, een gegevensoverbrengingsinterface,\n                                          een interface voor de taxameter, een leesvenster en voorzieningen voor de invoer van\n                                          gebruikersgegevens.\n\nDe TOE kan door middel van additionele verbindingen aan andere inrichtingen worden\n                                          gekoppeld, of daarmee ge\u00efntegreerd worden.\n\nToegang tot de TOE wordt verleend door middel van een boordcomputerkaart met PIN-code\n                                          en voorzien van een (authenticatie)certificaat. Er worden vier gebruikersrollen voorzien,\n                                          te weten bestuurder, toezichthouder, werkplaats en vervoerder. De omschakeling tussen\n                                          werkingsmodi gebeurt door het plaatsen van de correcte boordcomputerkaart in de TOE.\n                                          Er worden vier verschillende kaarten onderscheiden, te weten: chauffeurskaart, inspectiekaart,\n                                          keuringskaart en ondernemerskaart. Boordcomputerkaarten maken geen onderdeel uit van\n                                          de TOE.\n\nBij aanvang van de dienst dient een chauffeurskaart in de TOE te zijn geplaatst. De\n                                          bestuurder meldt zich aan met de chauffeurskaart en een persoonlijk identificatie\n                                          code (PIN-code). De TOE registreert de persoonlijke arbeids-, rij- en rusttijden van\n                                          de bestuurder en slaat deze op in het interne geheugen van de TOE en op de chauffeurskaart.\n\nIn voorkomende gevallen heeft een chauffeur geen kaart en dan dient hij zijn burgerservicenummer\n                                          in te voeren. Dit burgerservicenummer dient alleen voor identificatie, en wordt door\n                                          de TOE verder niet gecontroleerd.\n\nDe boordcomputerkaarten voor de bestuurder zijn voorzien van een certificaat voor\n                                          het elektronisch identificeren van de persoon en het ondertekenen van geregistreerde\n                                          gegevens.\n\nDe TOE gebruikt een systeemkaart welke is voorzien van certificaten voor identificatie\n                                          van de TOE en het plaatsen van elektronische handtekeningen. Het certificaat ten behoeve\n                                          van de TOE wordt in de productiefase in de vorm van de systeemkaart ge\u00efmplementeerd\n                                          in de TOE. Deze certificaten worden uitgegeven onder verantwoordelijkheid van de Minister\n                                          van Infrastructuur en Milieu. Systeemkaarten zijn geen onderdeel van de TOE.\n\nDe TOE voert gegevens uit naar een leesvenster en kan gegevens ter beschikking stellen\n                                          ten behoeve van een externe printer en externe inrichtingen.\n\nDe operationele omgeving van de TOE ge\u00efnstalleerd in de auto is weergegeven in onderstaande\n                                          figuur.\n\nDe systeemkaart plaatst een elektronische handtekening (EH) per uitgevoerde rit over\n                                          alle ritgegevens terstond nadat de bestuurder heeft aangegeven dat de rit teneinde\n                                          is.\n\nDe chauffeurskaart plaatst een elektronische handtekening bij het einde van de dienst\n                                          van de bestuurder over de arbeids-, rij- en rusttijden van de bestuurder gedurende\n                                          de dienst. Hiervoor wordt het persoonsgebonden certificaat van de chauffeurkaart gebruikt\n                                          waarbij de bestuurder vooraf zijn goedkeuring verleent door het ingeven van de PIN-code\n                                          van de chauffeurskaart.\n\nDe systeemkaart plaatst een elektronische handtekening over de geregistreerde gegevens\n                                          wanneer deze worden opgeslagen en wanneer deze worden uitgevoerd naar een externe\n                                          gegevensdrager.\n\nDe koppeling van bestuurder aan de geregistreerde gegevens en de waarborging van de\n                                          integriteit en authenticiteit van de gegevens wordt in onderstaande figuur ge\u00efllustreerd:\n\nDe typische levenscyclus van een TOE wordt ge\u00efllustreerd door onderstaande figuur.\n                                          Het verkrijgen van een typegoedkeuring is een verantwoordelijkheid van de fabrikant.\n                                          Eventuele reparaties worden uitgevoerd door, of onder verantwoordelijkheid van, de\n                                          fabrikant. Installatie van eventuele nieuwere versies van programmatuur mogen door\n                                          erkende werkplaatsen met een programmatuurrevisie worden uitgevoerd na een succesvolle\n                                          authenticatie met een keuringskaart.\n\nIndien naar het oordeel van de Dienst Wegverkeer bij/na het implementeren van een\n                                          bepaalde programmatuurrevisie geen kalibratie van de boordcomputer benodigd is, dan\n                                          mag die programmatuurrevisie ook buiten een erkende werkplaats door eenieder op de\n                                          boordcomputer ge\u00efmplementeerd worden indien deze zich in operationele modus met werkingsniveau\n                                          basis bevindt en er geen gebruikerssessie actief is.\n\nTeneinde de blijvend correcte werking van de boordcomputer te kunnen waarborgen, moet\n                                          de boordcomputer ten aanzien van het implementeren van programmatuurrevisies de volgende\n                                          acties uitvoeren:\n\n\u25cb De boordcomputer moet verhinderen dat een programmatuurrevisie die wel gevolgd moet\n                                                worden door kalibratie kan worden ge\u00efnstalleerd zonder een voorafgaande succesvolle\n                                                authenticatie met een keuringskaart.\n\n\u25cb De boordcomputer moet van elke aangeboden programmatuurrevisie en daarin opgenomen\n                                                programmatuur vaststellen dat deze integer en authentiek is, alvorens deze te installeren.\n\n\u25cb De boordcomputer moet van elke aangeboden programmatuurrevisie middels een door de\n                                                Dienst Wegverkeer goedgekeurde op versienummers gebaseerde controle vaststellen dat\n                                                de programmatuurrevisie geschikt is voor het vervangen van de op de boordcomputer\n                                                operationele programmatuur, alvorens de programmatuurrevisie te installeren.\n\n\u25cb De boordcomputer moet elke succesvol ge\u00efnstalleerde programmatuurrevisie direct na\n                                                installatie in zijn geheugen registreren onder vermelding van de na installatie geldende\n                                                basisgegevens, gebeurtenisgegevens en systeemgegevens.\n\nVoor de TOE zijn de volgende types van entiteiten (subjecten en objecten) relevant:\n\nS.BEWEGINGSOPNEMER\n\nHet instrument, of een deel ervan, gekoppeld aan de TOE dat een signaal in de vorm\n                                             van een impuls afgeeft over de beweging van de auto op basis waarvan de TOE de afgelegde\n                                             afstand van de auto kan bepalen.\n\nS.POSITIEBEPALINGSSENSOR\n\nHet instrument, of een deel ervan, gekoppeld aan de TOE dat een signaal afgeeft aan\n                                             de TOE over de locatie van de auto op basis van verkregen informatie van een satelliet\n                                             positiebepalingsysteem.\n\nS.BOORDCOMPUTERKAART\n\nDe geheugenkaart met chip voor gebruik in de TOE waarmee de TOE de identiteit van\n                                             de kaarthouder kan vaststellen en waarop gegevens kunnen worden opgeslagen.\n\nS.SYSTEEMKAART\n\nDe geheugenkaart met chip die de TOE in staat stelt een elektronische handtekening\n                                             te plaatsen.\n\nS.PRINTER\n\nEen externe inrichting waaraan gegevens beschikbaar kunnen worden gesteld voor het\n                                             afdrukken op papier.\n\nS.TAXAMETER\n\nDe geijkte externe inrichting voor het bepalen van de ritprijs op basis van een tarievenstructuur.\n\nS.HANDHAVINGSMIDDELEN\n\nFysiek aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers en ook\n                                             te beschouwen als externe gegevensdragers, t.b.v. toezichthouders voor het uitlezen\n                                             en eventueel verwerken van gegevens.\n\nS.KALIBRATIEMIDDELEN\n\nFysiek aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers en ook\n                                             te beschouwen als externe gegevensdragers, t.b.v. een erkende werkplaats voor het\n                                             uitlezen van gegevens en/of het ijken, kalibreren, activeren en deactiveren van de\n                                             TOE.\n\nS.BEDRIJFSMIDDELEN\n\nFysiek of logisch aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers\n                                             en ook te beschouwen als externe gegevensdragers, t.b.v. de vervoerder voor de overdracht\n                                             van gegevens van en naar de bedrijfsadministratie.\n\nS.UPDATEMIDDELEN\n\nFysiek of logisch aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers\n                                             en ook te beschouwen als externe gegevensdragers, voor de overdracht van programmatuurrevisies\n                                             naar de TOE.\n\nS.CHAUFFEURSKAART\n\nEen aan de bestuurder afgegeven boordcomputerkaart waarmee de boordcomputer de identiteit\n                                             van de desbetreffende bestuurder kan vaststellen, een elektronische handtekening kan\n                                             plaatsen, en waarmee de operationele modus van de TOE kan worden geactiveerd.\n\nS.INSPECTIEKAART\n\nEen aan de met het toezicht op de naleving belaste persoon afgegeven boordcomputerkaart\n                                             die de desbetreffende persoon identificeert en waarmee de controlemodus van de boordcomputer\n                                             kan worden geactiveerd.\n\nS.KEURINGSKAART\n\nEen aan een erkende werkplaats afgegeven boordcomputerkaart die de desbetreffende\n                                             werkplaats identificeert en waarmee de activerings- en keuringsmodus van de boordcomputer\n                                             kan worden geactiveerd.\n\nS.ONDERNEMERSKAART\n\nEen aan een vervoerder afgegeven boordcomputerkaart die de desbetreffende vervoerder\n                                             identificeert en waarmee de bedrijfsmodus van de boordcomputer kan worden geactiveerd.\n\nO.BASISGEGEVENS\n\nDe tijd, afgelegde afstand en gegevens betreffende verplaatsing zoals bijgehouden\n                                             door de TOE.\n\nO.ARBEIDSTIJDGEGEVENS\n\nDe arbeids-, rij- en rusttijden gegevens van de bestuurder zijnde de rijtijd, pauze\n                                             en andere werkzaamheden dan rijden geregistreerd door de TOE.\n\nO.RITGEGEVENS\n\nDe gegevens per individuele rit bestaande uit ten minste de begin- en eindlocatie,\n                                             de begin- en einddatum en tijd, afgelegde afstand, de ritprijs, de beladingstoestand\n                                             en identiteit van de bestuurder geregistreerd door de TOE.\n\nO.BEDRIJFSGEGEVENS\n\nGegevens over de vervoerder, waaronder autorisaties voor het gedurende een bepaalde\n                                             periode onafhankelijk van een kaartsessie uitlezen van de TOE, zoals zijn vastgelegd\n                                             op de TOE.\n\nO.KAARTHOUDERGEGEVENS\n\nGegevens opgeslagen op de boordcomputerkaart ingebracht in de TOE.\n\nO.POSITIEGEGEVENS\n\nGegevens betreffende de locatie van de auto die door de S.POSITIEBEPALINGSSENSOR aan\n                                             de TOE worden aangeleverd.\n\nO.BEWEGINGSGEGEVENS\n\nGegevens betreffende snelheid en afgelegde afstand die door S.BEWEGINGSOPNEMER of\n                                             S.POSITIEBEPALINGSSENSOR aan de TOE worden aangeleverd.\n\nO.GEBEURTENISGEGEVENS\n\nGegevens geregistreerd door de TOE met betrekking tot routinematige en uitzonderlijke\n                                             gebeurtenissen op basis waarvan analyses mogelijk zijn en de verantwoordelijke gebruiker\n                                             of proces kan worden bepaald.\n\nO.SYSTEEMGEGEVENS\n\nSpecifieke gegevens ter ondersteuning of noodzakelijk voor het functioneren van de\n                                             TOE of voor identificatie en instellingen van de TOE functies, bestaande uit O.VASTE_SYSTEEMGEGEVENS,\n                                             O.VARIABELE_SYSTEEMGEGEVENS en O.PROGRAMMATUURGEGEVENS.\n\nO.VASTE_SYSTEEMGEGEVENS\n\nVaste gegevens van de TOE, zoals de naam van diens fabrikant, het serienummer en het\n                                             bouwjaar.\n\nO.VARIABELE_SYSTEEMGEGEVENS\n\nWijzigbare gegevens van de TOE, waaronder het kenteken van de auto en O.INSTELLINGSGEGEVENS.\n\nO.INSTELLINGSGEGEVENS\n\nDie subset van O.VARIABELE_SYSTEEMGEGEVENS die aan kalibratie onderhevig is.\n\nO.PROGRAMMATUUR\n\nDe combinatie van TOE uitvoerbare code en gegevens zoals de CA certificaathi\u00ebrarchie(\u00ebn)\n                                             nodig voor het verifi\u00ebren van de geldigheid en authenticiteit van certificaten van\n                                             boordcomputer- en systeemkaarten, alsmede de bij dat geheel behorende O.PROGRAMMATUURGEGEVENS.\n\nO.PROGRAMMATUURGEGEVENS\n\nVersie-identificerende (vaste) gegevens van O.PROGRAMMATUUR, waaronder een versienummer\n                                             en een goedkeuringsnummer. De O.PROGRAMMATUURGEGEVENS van de op de TOE operationele\n                                             O.PROGRAMMATUUR vormen eveneens een subset van O.SYSTEEMGEGEVENS.\n\nO.PROGRAMMATUURREVISIE\n\nDe combinatie van een versie van O.PROGRAMMATUUR die is bedoeld om de op de TOE operationele\n                                             O.PROGRAMMATUUR of delen daarvan te vervangen, een O.KALIBRATIEINDICATIE en een O.VERVANGBARE_VERSIES.\n\nO.KALIBRATIEINDICATIE\n\nEen vast attribuut van een O.PROGRAMMATUURREVISIE dat aanduidt of het vervangen van\n                                             de op de TOE operationele O.PROGRAMMATUUR met de in de O.PROGRAMMATUURREVISIE opgenomen\n                                             O.PROGRAMMATUUR wel (positief) of niet (negatief) gevolgd moet worden door kalibratie\n                                             van O.INSTELLINGSGEGEVENS.\n\nO.VERVANGBARE_VERSIES\n\nEen in een O.PROGRAMMATUURREVISIE opgenomen criterium (zoals een lijst of wildcard)\n                                             waarmee een versienummer kan worden vergeleken om te bepalen of het met dat criterium\n                                             correspondeert.\n\nTer verduidelijking is in de onderstaande figuur de samenhang van de op de TOE aanwezige\n                                             O.SYSTEEMGEGEVENS en de op de TOE operationele O.PROGRAMMATUUR en hun subobjecten\n                                             / attributen grafisch weergegeven.\n\nEveneens ter verduidelijking is in de onderstaande figuur de opbouw van een O.PROGRAMMATUURREVISIE\n                                             opgenomen.\n\nDe TOE (Target of Evaluation) is de selectie van hardware en software en bijbehorende\n                                          handleidingen die uiteindelijk wordt ge\u00ebvalueerd. De TOE moet alle functionaliteit\n                                          omvatten die nodig is om aan de eisen in dit profiel te voldoen, maar mag daarnaast\n                                          ook andere zaken bevatten, zoals een routeplanningsapplicatie.\n\nDe minimale omvang van de TOE wordt schematisch weergegeven in onderstaande figuur:\n\nAlle onderdelen die in deze afbeelding binnen de grijze omheining worden weergegeven\n                                          moeten onderdeel zijn van de TOE. Dus bijvoorbeeld de (voertuig) sensor voor bewegingsgegevens\n                                          (bewegingsopnemer) en de positiebepalingssensor (GNSS) hoeven geen deel uit te maken\n                                          van de TOE maar de aansluiting van deze sensoren weer wel\n\nAndere zaken die in deze figuur zijn weergegeven (zoals de taxameter en de printer),\n                                          mogen onderdeel zijn van de TOE, hoewel dit niet altijd praktisch is. Ook extra software\n                                          en hardware die niet in deze figuur zijn weergegeven (zoals de bovengenoemde routeplanningsapplicatie)\n                                          mogen deel uitmaken van de TOE.\n\nDaarnaast is het toegestaan om extra hardware of software binnen de fysieke behuizing\n                                          van de TOE op te nemen, zonder dat deze hardware of software meteen onderdeel worden\n                                          van de TOE. Het is echter niet toegestaan om tijdens de evaluatie van de TOE aan te\n                                          nemen dat deze extra hardware of software vertrouwd of goedaardig is: de evaluatie\n                                          van de TOE dient ondubbelzinnig aan te tonen dat de TOE nog steeds voldoet aan dit\n                                          Beschermingsprofiel als deze opgenomen hardware of software niet vertrouwd of goedaardig\n                                          is.\n\nP.VASTLEGGEN\n\nDe TOE legt de volgende gegevens vast, afhankelijk van de werkingsmodus en het actieve\n                                          werkingsniveau:\n\n\u25cb Operationele modus basis: In ingeschakelde toestand registreert de TOE altijd de positie-\n                                                en gebeurtenisgegevens. Direct na installatie van een programmatuurrevisie registreert\n                                                de TOE de na installatie geldende basisgegevens, gebeurtenisgegevens en systeemgegevens.\n                                                Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de\n                                                kaarthouder;\n\n\u25cb Operationele modus arbeidstijd: Na een handmatige selectie van het werkingsniveau\n                                                arbeidstijd, registreert de TOE de positie- en gebeurtenisgegevens en de arbeidstijdgegevens.\n                                                Het werkingsniveau arbeidstijd wordt automatisch geselecteerd door het inbrengen van\n                                                de chauffeurskaart, en kan zonder chauffeurskaart handmatig geselecteerd worden na\n                                                het invoeren van een burgerservicenummer. Indien een boordcomputerkaart is ingebracht\n                                                registreert de TOE de identiteit van de kaarthouder, indien identificatie plaatsvindt\n                                                met een burgerservicenummer, dan registreert de TOE dit burgerservicenummer;\n\n\u25cb Operationele modus taxivervoer: Na een handmatige selectie van het werkingsniveau\n                                                taxivervoer, registreert de TOE de positie- en gebeurtenisgegevens, de arbeidstijdgegevens\n                                                en de ritgegevens. Indien een boordcomputerkaart is ingebracht registreert de TOE\n                                                de identiteit van de kaarthouder, indien identificatie plaatsvindt met een burgerservicenummer,\n                                                dan registreert de TOE dit burgerservicenummer;\n\n\u25cb Controlemodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit\n                                                van de kaarthouder;\n\n\u25cb Activering/keuringsmodus: De TOE registreert de positie- en gebeurtenisgegevens en\n                                                de identiteit van de kaarthouder. Direct na installatie van een programmatuurrevisie\n                                                registreert de TOE de na installatie geldende basisgegevens, gebeurtenisgegevens en\n                                                systeemgegevens;\n\n\u25cb Bedrijfsmodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit\n                                                van de kaarthouder.\n\nP.BEWAREN_EN_BORGEN\n\nDe TOE bewaart de vastgelegde gegevens zodat:\n\n\u25cb wijzigingen van de gegevens detecteerbaar zijn;\n\n\u25cb de gegevens onweerlegbaar gekoppeld zijn aan de TOE;\n\n\u25cb de gegevens onweerlegbaar gekoppeld zijn aan de houder van een boordcomputerkaart.\n\nP.ACTIES\n\nDe TOE kan de volgende acties uitvoeren, afhankelijk van de werkingsmodus, het actieve\n                                          werkingsniveau en de ingebrachte en geauthenticeerde boordcomputerkaart:\n\n\u25cb Selecteren van de juiste werkingsmodus;\n\n\u25cb Activering, deactivering en onderzoek van de TOE;\n\n\u25cb Instellen van de bedrijfsvergrendeling;\n\n\u25cb Detecteren en registreren van storingen1;\n\n\u25cb Detecteren en registeren van fouten2;\n\n\u25cb Detecteren en registeren van gebeurtenissen;\n\n\u25cb Gegevens tonen op een leesvenster;\n\n\u25cb Gegevens overbrengen van en naar een externe gegevensdrager;\n\n\u25cb Gegevens overbrengen van de chauffeurskaart naar de TOE;\n\n\u25cb Gegevens overbrengen naar een externe inrichting;\n\n\u25cb Gegevens beschikbaar stellen t.b.v. een printer;\n\n\u25cb Geven van waarschuwingssignalen\n\n\u25cb Programmatuurrevisies overbrengen van externe updatemiddelen naar de TOE;\n\n\u25cb Programmatuur van de TOE updaten met programmatuur uit een programmatuurrevisie.\n\nP.UITVOEREN_GEGEVENS\n\nDe TOE kan de geregistreerde gegevens uitvoeren, afhankelijk van de ingebrachte boordcomputerkaart:\n\n\u25cb Geen kaart, geen andere authenticatie:\n\n\u25cb systeemgegevens naar een leesvenster.\n\n\u25cb Geen kaart, authenticatie op basis van burgerservicenummer:\n\n\u25cb systeemgegevens naar een leesvenster;\n\n\u25cb ritgegevens van de huidige sessie naar een leesvenster;\n\n\u25cb arbeids-, rij- en rusttijden van de huidige sessie naar een leesvenster;\n\n\u25cb ritgegevens van de huidige sessie naar een uitvoerinterface voor een printer;\n\n\u25cb arbeids-, rij- en rusttijden van de huidige sessie naar een uitvoerinterface voor\n                                                      een printer;\n\n\u25cb Chauffeurskaart:\n\n\u25cb systeemgegevens naar een leesvenster;\n\n\u25cb eigen ritgegevens naar een leesvenster;\n\n\u25cb eigen arbeids-, rij- en rusttijden naar een leesvenster;\n\n\u25cb eigen arbeids-, rij- en rusttijden naar de chauffeurskaart;\n\n\u25cb eigen ritgegevens naar een uitvoerinterface voor een printer;\n\n\u25cb eigen arbeids-, rij- en rusttijden naar een uitvoerinterface voor een printer.\n\n\u25cb Inspectiekaart: alle gegevens met uitzondering van positiegegevens en beveiligingsgegevens,\n\n\u25cb naar een leesvenster;\n\n\u25cb naar een uitvoerinterface voor een printer;\n\n\u25cb naar een extern handhavingsmiddel.\n\n\u25cb Keuringskaart: alle gegevens met uitzondering van positiegegevens en beveiligingsgegevens,\n\n\u25cb naar een leesvenster;\n\n\u25cb naar een uitvoerinterface voor een printer;\n\n\u25cb naar een extern kalibratiemiddel.\n\n\u25cb Keuringskaart, na actieve handeling gevolgd door Inspectiekaart: de positiegegevens\n                                                naar een extern handhavingsmiddel.\n\n\u25cb Ondernemerskaart: alle gegevens vastgelegd in de bedrijfsvergrendeling voor de desbetreffende\n                                                vervoerder met uitzondering van positiegegevens en beveiligingsgegevens,\n\n\u25cb naar een leesvenster;\n\n\u25cb naar een uitvoerinterface voor een printer;\n\n\u25cb naar een extern bedrijfsmiddel.\n\n\u25cb Ondernemerskaart: systeemgegevens\n\n\u25cb naar een leesvenster;\n\n\u25cb naar een uitvoerinterface voor een printer;\n\n\u25cb naar een extern bedrijfsmiddel.\n\nDe TOE kan\n\n\u25cb de systeemgegevens en\n\n\u25cb alle gegevens vastgelegd in de bedrijfsvergrendeling voor een bepaalde vervoerder\n                                                met uitzondering van positiegegevens en beveiligingsgegevens\n\nuitvoeren naar een extern bedrijfsmiddel (op afstand of lokaal) indien\n\n\u25cb de TOE voor de betreffende vervoerder vergrendeld is en\n\n\u25cb de TOE, als onderdeel van de bedrijfsgegevens, beschikt over een unieke autorisatie\n                                                voor deze uitvoer die\n\n\u25cb een nog niet verstreken geldigheidsperiode voor deze uitvoer vermeldt.\n\nP.INVOEREN_GEGEVENS\n\nDe TOE kan gegevens invoeren, afhankelijk van de ingebrachte boordcomputerkaart:\n\n\u25cb Keuringskaart:\n\n\u25cb variabele systeemgegevens van het bedieningspaneel;\n\n\u25cb variabele systeemgegevens van een extern kalibratiemiddel.\n\n\u25cb Ondernemerskaart:\n\n\u25cb bedrijfsgegevens van het bedieningspaneel;\n\n\u25cb bedrijfsgegevens van een extern bedrijfsmiddel.\n\nDe TOE kan, onafhankelijk van het bestaan van een gebruikerssessie:\n\n\u25cb Programmatuurrevisies invoeren van een extern updatemiddel;\n\n\u25cb Bedrijfsgegevens,\n\nwaaronder unieke autorisaties voor gegevensuitvoer zoals vermeld onder P.UITVOEREN_GEGEVENS,\n\ninvoeren van een extern bedrijfsmiddel (op afstand of lokaal), indien\n\n\u25cb de TOE voor de betreffende vervoerder vergrendeld is en\n\n\u25cb de bedrijfsgegevens zijn ondertekend door een ondernemerskaart van die vervoerder.\n\nP.VEILIG_UPDATEN\n\nDe TOE kan zijn operationele programmatuur updaten met de programmatuur uit een (van\n                                          een extern updatemiddel afkomstige) programmatuurrevisie indien de TOE heeft vastgesteld\n                                          dat\n\n\u25cb de programmatuurrevisie integer en authentiek is,\n\n\u25cb uit het corresponderen van het versienummer van de op de TOE operationele programmatuur\n                                                met de door de Dienst Wegverkeer goedgekeurde invulling van O.VERVANGBARE_VERSIES\n                                                blijkt dat de programmatuur uit de programmatuurrevisie geschikt is voor het updaten\n                                                van de in de TOE operationele programmatuur en\n\n\u25cb een van de volgende situaties van toepassing is:\n\n\u25cb op de TOE is een werkplaatssessie actief of\n\n\u25cb op de TOE is geen gebruikerssessie actief en uit de door de Dienst Wegverkeer goedgekeurde\n                                                      invulling van O.KALIBRATIEINDICATIE blijkt dat het updaten niet gevolgd hoeft te worden\n                                                      door kalibratie van de TOE.\n\nP.DEACTIVERING\n\nDe TOE kan met behulp van een keuringskaart worden gedeactiveerd. Alle gegevens opgeslagen\n                                          op de TOE tijdens de deactivering worden overgebracht naar een extern kalibratiemiddel\n                                          met uitzondering van positiegegevens. Positiegegevens kunnen alleen worden overgebracht\n                                          naar extern handhavingsmiddel als er tijdens P.DEACTIVERING op de TOE wordt aangemeld\n                                          met achtereenvolgens S.KEURINGSKAART en S.INSPECTIEKAART.\n\nA.BEDIENING\n\nEr wordt verondersteld dat de bestuurder van de auto de TOE juist bedient en correct\n                                          het werkingsniveau, de beladingtoestand en het moment van aanvang en be\u00ebindiging van\n                                          een rit selecteert.\n\nA.SENSOREN\n\nEr wordt verondersteld dat de gegevens aangeboden op de sensorinterface(s) correct\n                                          zijn.\n\nA.SYSTEEMKAART\n\nEr wordt verondersteld dat de systeemkaart een certificaat bevat welk onweerlegbaar\n                                          is gekoppeld met de TOE; alle gegevens die door de TOE worden aangeboden correct ondertekent;\n                                          de handtekening terugstuurt naar de TOE.\n\nA.BOORDCOMPUTERKAART\n\nEr wordt verondersteld dat een ingebrachte boordcomputerkaart een certificaat bevat\n                                          welk onweerlegbaar is gekoppeld met de boordcomputerkaarthouder; alle gegevens die\n                                          door de TOE worden aangeboden correct ondertekent; de handtekening terugstuurt naar\n                                          de TOE.\n\nA.BOORDCOMPUTERKAARTHOUDER\n\nEr wordt verondersteld dat boordcomputerkaarthouders hun boordcomputerkaart niet aan\n                                          derden uitreiken en hun PIN-code geheim houden.\n\nA.PRINTER\n\nEr wordt verondersteld dat gegevens die worden aangeboden ten behoeve van een aangesloten\n                                          printer, correct worden afgedrukt door die printer.\n\nA.VOOR_ACTIVERING\n\nDe TOE wordt in inactieve toestand geleverd aan voertuigfabrikanten, installateurs\n                                          en/of erkende werkplaatsen. Deze zullen de TOE installeren waarna een erkende werkplaats\n                                          de TOE zal kalibreren en vervolgens activeren. Na activering kan de TOE door een erkende\n                                          werkplaats middels deactivering weer in inactieve toestand worden teruggebracht. De\n                                          cyclus van activering en deactivering door erkende werkplaatsen kan zich gedurende\n                                          de levensduur van de TOE meerdere keren herhalen.\n\nVoertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit\n                                          van de TOE beschermen zolang de TOE zich niet in actieve toestand bevindt.\n\nOT.AUDIT\n\nDe TOE legt beveiligingsrelevante gebeurtenisgegevens vast en toont deze op het beeldscherm.\n\nOT.AUTHENTICATIE_BOORDCOMPUTERKAART\n\nDe TOE zal een ingebrachte boordcomputerkaart authenticeren door middel van zowel:\n\n\u25cb een door de eigenaar van de boordcomputerkaart in te brengen PIN;\n\n\u25cb een op de boordcomputerkaart aanwezig geldig en authentiek certificaat.\n\nOT.VASTLEGGEN\n\nDe TOE legt gegevens vast volgens de regels van P.VASTLEGGEN en zodanig dat de geregistreerde\n                                          gegevens een correcte afspiegeling zijn van de waarden aangeboden op de sensorinterface(s).\n\nOT.KOPPELEN_AAN_SYSTEEMKAART\n\nDe TOE zal gegevens die geregistreerd dienen te worden aan de systeemkaart aanbieden\n                                          ter ondertekening met een elektronische handtekening.\n\nOT.KOPPELEN_AAN_BOORDCOMPUTERKAART\n\nDe TOE zal arbeids-, rij- en rusttijden van de bestuurder die geregistreerd dienen\n                                          te worden, aan de chauffeurskaart aanbieden ter ondertekening met een elektronische\n                                          handtekening.\n\nOT.OPSLAAN\n\nDe TOE zal gegevens die geregistreerd dienen te worden opslaan. De gegevens zullen\n                                          gezamenlijk worden opgeslagen met de elektronische handtekeningen over deze gegevens.\n\nOT.UITVOEREN_GEGEVENS\n\nDe TOE kan geregistreerde gegevens uitvoeren volgens de regels van P.UITVOEREN_GEGEVENS.\n                                          Tenzij gegevens worden uitgevoerd naar printer of leesvenster worden de bij de gegevens\n                                          opgeslagen elektronische handtekeningen eveneens uitgevoerd.\n\nOT.INVOEREN_GEGEVENS\n\nDe TOE kan gegevens invoeren volgens de regels van P.INVOEREN_GEGEVENS.\n\nOT.FYSIEKE_BEVEILIGING\n\nDe TOE biedt fysieke weerstand zodanig dat het openmaken van de TOE in een laboratorium\n                                          kan worden vastgesteld.\n\nOT.BEWAKING_INTEGRITEIT\n\nDe TOE zal de integriteit van de gegevens ten minste bewaken door:\n\n\u25cb Het testen van de integriteit van opgeslagen gegevens bij het opstarten van de TOE\n                                                (O.SYSTEEMGEGEVENS), op verzoek van een gebruiker of bij het overbrengen van gegevens;\n\n\u25cb Het testen van de integriteit van de op de TOE operationele O.PROGRAMMATUUR bij het\n                                                opstarten van de TOE of op verzoek van een gebruiker;\n\n\u25cb Het testen van de correcte werking van de TOE en de S.SYSTEEMKAART bij het opstarten\n                                                van de TOE of op verzoek van een gebruiker.\n\nOT.VEILIG_UPDATEN\n\nDe TOE kan zijn operationele programmatuur updaten met de programmatuur uit een (van\n                                          een extern updatemiddel afkomstige) programmatuurrevisie indien de TOE heeft vastgesteld\n                                          dat\n\n\u25cb de programmatuurrevisie integer en authentiek is,\n\n\u25cb het versienummer van de op de TOE operationele programmatuur correspondeert met het\n                                                criterium in O.VERVANGBARE_VERSIES en\n\n\u25cb een van de volgende situaties van toepassing is:\n\n\u25cb op de TOE is een werkplaatssessie actief of\n\n\u25cb op de TOE is geen gebruikerssessie actief en O.KALIBRATIEINDICATIE is negatief.\n\nOE.VOOR_ACTIVERING\n\nDe TOE wordt in inactieve toestand geleverd aan voertuigfabrikanten, installateurs\n                                          en/of erkende werkplaatsen. Deze zullen de TOE installeren waarna een erkende werkplaats\n                                          de TOE zal kalibreren en vervolgens activeren. Na activering kan de TOE door een erkende\n                                          werkplaats middels deactivering weer in inactieve toestand worden teruggebracht. De\n                                          cyclus van activering en deactivering door erkende werkplaatsen kan zich gedurende\n                                          de levensduur van de TOE meerdere keren herhalen.\n\nVoertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit\n                                          van de TOE beschermen zolang de TOE zich niet in actieve toestand bevindt.\n\nOE.SENSOREN\n\nDe omgeving van de TOE dient ervoor zorg te dragen dat de gegevens die worden aangeboden\n                                          op de sensorinterface(s) correct zijn. Dit kan bijvoorbeeld door:\n\n\u25cb correcte installatie van TOE en sensoren in het voertuig;\n\n\u25cb controle van het voertuig op manipulatie van sensoren en/of aansluiting.\n\nOE.PRINTER\n\nDe omgeving van de TOE dient ervoor zorg te dragen dat de gegevens die worden aangeboden\n                                          door de TOE aan de printer correct worden afgedrukt. Dit kan bijvoorbeeld door:\n\n\u25cb correcte installatie van TOE en printer in het voertuig;\n\n\u25cb controle van het voertuig op manipulatie van printer en/of aansluiting.\n\nOE.BEDIENING\n\nDe omgeving van de TOE dient ervoor zorg te dragen dat de bestuurder van de auto correct\n                                          gebruik maakt van de mogelijkheden om het werkingsniveau, de beladingtoestand, het\n                                          begin en einde van een rit en de aanvang en einde van de dienst te selecteren. Dit\n                                          kan bijvoorbeeld door:\n\n\u25cb handleidingen en instructies;\n\n\u25cb opleiding en training;\n\n\u25cb ergonomisch ontwerp van de TOE en montage in de auto.\n\nOE.SYSTEEMKAART\n\nDe omgeving van de TOE dient een systeemkaart te bevatten die:\n\n\u25cb een certificaat bevat welk onweerlegbaar is gekoppeld met de TOE;\n\n\u25cb alle gegevens die door de TOE worden aangeboden correct ondertekent;\n\n\u25cb de handtekening terugstuurt naar de TOE.\n\nOE.BOORDCOMPUTERKAART\n\nDe omgeving van de TOE dient boordcomputerkaarten te bevatten die:\n\n\u25cb een certificaat bevat welk onweerlegbaar is gekoppeld met de boordcomputerkaarthouder;\n\n\u25cb alle gegevens die door de TOE worden aangeboden correct ondertekent;\n\n\u25cb de handtekening terugstuurt naar de TOE.\n\nOE.BOORDCOMPUTERKAARTHOUDER\n\nBoordcomputerkaarthouders dienen hun boordcomputerkaart niet aan derden uit te reiken\n                                          en hun PIN-code geheim te houden. Bestuurders mogen maar \u00e9\u00e9n geldige chauffeurskaart\n                                          in hun bezit hebben.\n\nOE.DEACTIVERING\n\nDe TOE wordt buiten gebruik gesteld (deactivering) door erkende werkplaatsen. De opgeslagen\n                                          gegevens worden hierbij verwijderd met uitzondering van O.SYSTEEMGEGEVENS, O.PROGRAMMATUUR\n                                          en O.POSITIEGEGEVENS.\n\nOE.VEILIG_UPDATEN\n\nDe omgeving van de TOE dient programmatuurrevisies aan te leveren waarvan, voorafgaand\n                                          aan het door de fabrikant aan de programmatuurrevisie aanbrengen van enig integriteits-\n                                          en authenticiteitskenmerk,\n\n\u25cb de door de fabrikant gekozen invulling van O.VERVANGBARE_VERSIES zodanig is dat deze\n                                                door de TOE wordt gebruikt om vast te stellen of de programmatuur uit de desbetreffende\n                                                programmatuurrevisie geschikt is voor het updaten van de op de TOE operationele programmatuur\n                                                en\n\n\u25cb de door de fabrikant gekozen invulling van O.KALIBRATIEINDICATIE en O.VERVANGBARE_VERSIES\n                                                is goedgekeurd door de Dienst Wegverkeer.\n\nDe functionele beveiligingseisen zijn verdeeld in een aantal functionele groepen.\n                                       Iedere groep bevat \u00e9\u00e9n of meer onderling samenhangende eisen. De groepen zijn:\n\n\u25cb Beveiligingsrollen: Deze defini\u00ebren de verschillende rollen en modi van de TOE, en\n                                             hoe deze rollen worden aangenomen.\n\n\u25cb Identificatie en Authenticatie: Deze defini\u00ebren hoe boordcomputerkaarten en andere\n                                             randapparatuur worden ge\u00efdentificeerd en waar nodig geauthenticeerd.\n\n\u25cb BCT-toegangsbeleid: Hier wordt beschreven wat wordt vastgelegd, en wie daar wat mee\n                                             mag doen.\n\n\u25cb Handtekeningen: Hier wordt beschreven hoe handtekeningen worden gevraagd aan Systeemkaart\n                                             en Boordcomputerkaart\n\n\u25cb Beveiligingsaudit: Hier wordt beschreven hoe welke systeemgebeurtenissen worden geregistreerd\n                                             en hoe deze zijn beschermd\n\n\u25cb Bescherming van de BCT: Hier wordt beschreven hoe de fysieke beveiliging van de BCT\n                                             werkt en hoe de integriteit wordt gewaarborgd.\n\nFMT_SMR.2 Restricties op gebruikersrollen\n\nFMT_SMR.2.1 De TSF kent de volgende gebruikersrollen:\n\n\u25cb BESTUURDER\n\n\u25cb TOEZICHTHOUDER\n\n\u25cb WERKPLAATS\n\n\u25cb VERVOERDER\n\n\u25cb ONBEKEND\n\nFMT_SMR.2.2 De TSF kan rollen met gebruikers associ\u00ebren\n\nFMT_SMR.2.3 De TSF zal de volgende regels afdwingen:\n\n\u25cb De rol BESTUURDER wordt aangenomen (en de werkingsmodus wordt Operationele Modus Arbeidstijd)\n                                                als S.CHAUFFEURSKAART is ingebracht en geauthenticeerd, of als geen S.BOORDCOMPUTERKAART\n                                                is ingebracht en de gebruiker met het burgerservicenummer is ge\u00efdentificeerd.\n\n\u25cb De rol TOEZICHTHOUDER wordt aangenomen (en de werkingsmodus wordt Controle Modus)\n                                                als S.INSPECTIEKAART is ingebracht en geauthenticeerd\n\n\u25cb De rol WERKPLAATS wordt aangenomen (en de werkingsmodus wordt Activerings/Keuringsmodus)\n                                                als S.KEURINGSKAART is ingebracht en geauthenticeerd\n\n\u25cb De rol VERVOERDER wordt aangenomen (en de werkingsmodus wordt Bedrijfsmodus) als S.ONDERNEMERSKAART\n                                                is ingebracht en geauthenticeerd\n\n\u25cb De rol ONBEKEND wordt aangenomen (en de werkingsmode wordt Operationele Modus Basis)\n                                                als:\n\n\u25cb Geen kaart is ingebracht en de gebruiker heeft zich niet met burgerservicenummer ge\u00efdentificeerd\n\n\u25cb Wel een kaart is ingebracht maar de authenticatie faalt\n\nFIA_UID.1 Tijd van identificatie (Boordcomputerkaarten)\n\nFIA_UID.1.1 De TSF staat het registreren van de O.POSITIEGEGEVENS, en O.GEBEURTENISGEGEVENS namens\n                                          de gebruikersrol ONBEKEND toe, voordat een gebruiker is ge\u00efdentificeerd.\n\nFIA_UID.1.2 De TSF eist dat S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART, en S.ONDERNEMERSKAART\n                                          succesvol zijn ge\u00efdentificeerd op basis van de identiteit weergegeven in het certificaat\n                                          op die boordcomputerkaart, alvorens andere handelingen te verrichten namens de desbetreffende\n                                          gebruiker.\n\nFIA_UAU.1 Tijd van authenticatie (Boordcomputerkaarten)\n\nFIA_UAU.1.1 De TSF staat het registreren van de O.BASISGEGEVENS, O.ARBEIDSTIJDGEGEVENS, O.RITGEGEVENS,\n                                          O.POSITIEGEGEVENS, O.BEWEGINGSGEGEVENS en O.GEBEURTENISGEGEVENS namens de gebruikersrol\n                                          ONBEKEND toe, voordat een gebruiker is geauthenticeerd.\n\nFIA_UAU.1.2 De TSF eist dat S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART\n                                          succesvol zijn geauthenticeerd op basis van:\n\n\u25cb Een minimaal 4 karakter lange PIN (deze authenticatie wordt door S.CHAUFFEURSKAART,\n                                                S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART uitgevoerd en het resultaat\n                                                wordt door deze aan de TSF gerapporteerd), en\n\n\u25cb Verificatie dat het certificaat op de boordcomputerkaart geldig en authentiek is.\n\nFIA_AFL.1 Falen van authenticatie (FIA_AFL)\n\nFIA_AFL.1.1 De TSF detecteert wanneer vijf (5) opeenvolgende niet-succesvolle authenticatiepogingen\n                                          plaatsvinden gerelateerd aan het authenticeren van dezelfde S.CHAUFFEURSKAART, S.INSPECTIEKAART,\n                                             S.KEURINGSKAART of S.ONDERNEMERSKAART\n\nFIA_AFL.1.2 Als er vijf (5) opeenvolgende niet-succesvolle authenticatiepogingen zijn\n                                          gedetecteerd, dan zal de TSF:\n\n\u25cb een gebeurtenis genereren;\n\n\u25cb de gebruiker waarschuwen;\n\n\u25cb aannemen dat de gebruikersrol ONBEKEND is.\n\nFIA_UAU.6 Herauthenticeren\n\nFIA_UAU.6.1 De TSF zal S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART\n                                          herauthenticeren onder de volgende condities:\n\n\u25cb bij het plaatsen van een elektronische handtekening door een boordcomputerkaart;\n\n\u25cb bij het invoeren van de boordcomputerkaart;\n\n\u25cb bij het opheffen van een geblokkeerde kaartsessie;\n\n\u25cb bij herstel van de stroomvoorziening na een onderbreking\n\nFTA_SSL.2 Blokkeren van een sessie op initiatief van een gebruiker\n\nFTA_SSL.2.1 De TSF zal S.BOORDCOMPUTERKAART toestaan een sessie te blokkeren door het uitnemen\n                                          van S.BOORDCOMPUTERKAART zonder dat is aangegeven dat de sessie van de gebruiker is\n                                          be\u00ebindigd en als de auto zich in de toestand stilstaan bevindt door middel van:\n\n\u25cb het wissen van het scherm\n\n\u25cb het blokkeren van alle invoerapparatuur behalve die benodigd is voor het opheffen\n                                                van de blokkering\n\nFTA_SSL.2.2 De TSF eist dat de volgende handelingen plaatsvinden alvorens de blokkering op te\n                                          heffen:\n\n\u25cb het opnieuw inbrengen van dezelfde S.CHAUFFEURSKAART waarvoor de kaartsessie is geblokkeerd.\n\nFTA_SSL.3 Automatisch be\u00ebindigen van een sessie\n\nFTA_SSL.3.1 De TSF be\u00ebindigt een kaartsessie:\n\n\u25cb als een geblokkeerde S.CHAUFFEURSKAART sessie niet binnen 60 minuten wordt hervat;\n\n\u25cb meteen als een andere S.BOORDCOMPUTERKAART wordt ingebracht dan waarvoor de TSF is\n                                                geblokkeerd, tenzij\n\n\u25cb de TSF in de toestand P.DEACTIVERING is geplaatst door een S.KEURINGSKAART waarna\n                                                      een S.INSPECTIEKAART wordt aangeboden, of;\n\n\u25cb in de Operationele Modus Arbeidstijd of Operationele Modus Taxivervoer een S.INSPECTIEKAART\n                                                      wordt aangeboden;\n\n\u25cb als in een sessie van een S.ONDERNEMERSKAART, S.INSPECTIEKAART of S.KEURINGSKAART\n                                                gedurende 5 minuten geen handelingen aan de TSF verricht.\n\nFIA_UID.2 Identificatie voor enige actie (Systeemkaart)\n\nFIA_UID.2.1 De TSF identificeert S.SYSTEEMKAART op basis van de identiteit weergegeven in het\n                                          machine-gebonden certificaat zoals vastgelegd op de systeemkaart verbonden met de\n                                          TOE, alvorens handelingen te verrichten namens S.SYSTEEMKAART.\n\nFIA_UID.2 Identificatie voor enige actie (Overigen)\n\nFIA_UID.2.1 De TSF identificeert S.BEWEGINGSOPNEMER, S.POSITIEBEPALINGSSENSOR, S.PRINTER, S.TAXAMETER,\n                                          S.HANDHAVINGSMIDDELEN, S.KALIBRATIEMIDDELEN, S.BEDRIJFSMIDDELEN en S.UPDATEMIDDELEN\n                                          op basis van hun aanwezigheid op de daarvoor bestemde interface, alvorens handelingen\n                                          te verrichten namens de desbetreffende subjecten.\n\nFDP_ACC.2 Volledige toegangscontrole\n\nFDP_ACC.2.1 De TSF dwingt het toepassen van het BCT-toegangsbeleid af voor alle subjecten, alle\n                                          objecten en alle handelingen4.\n\nFDP_ACC.2.2 De TSF garandeert dat alle verrichtingen tussen een subject gecontroleerd door de\n                                          TSF en een object gecontroleerd door de TSF zijn onderworpen aan een toegangscontrole\n                                          SFP.\n\nFDP_ACF.1 Toegangscontrole op basis van attributen\n\nFDP_ACF.1.1 De TSF dwingt het toepassen van het BCT-toegangsbeleid af voor objecten voor alle\n                                          subjecten en alle objecten.\n\nFDP_ACF.1.2 De TSF dwingt de volgende regels af om te bepalen of een verrichting tussen gecontroleerde\n                                          subjecten en gecontroleerde objecten is toegestaan:\n\n\u25cb TSF zal:\n\n\u25cb Altijd O.BEWEGINGSGEGEVENS inlezen, samenvatten, en samen met de tijd5 en de gegevens betreffende verplaatsing beschikbaar stellen als O. BASISGEGEVENS;\n\n\u25cb Altijd O.POSITIEGEGEVENS inlezen en vastleggen;\n\n\u25cb O.ARBEIDSTIJDGEGEVENS vastleggen in Operationele Modus Arbeidstijd en Operationele\n                                                      Modus Taxivervoer;\n\n\u25cb O.RITGEGEVENS vastleggen in Operationele Modus Taxivervoer.\n\n\u25cb Altijd O.PROGRAMMATUURREVISIEs (kunnen) inlezen van S.UPDATEMIDDELEN en (t.b.v. een\n                                                      eventuele update) vastleggen;\n\n\u25cb Direct na het uitvoeren van een software update met een O.PROGRAMMATUURREVISIE de\n                                                      na de update geldende O.BASISGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS\n                                                      vastleggen in Operationele Modus Basis c.q. Activerings- en Keuringsmodus;\n\n\u25cb O.BEDRIJFSGEGEVENS van een bepaalde vervoerder (kunnen) inlezen van S.BEDRIJFSMIDDELEN,\n                                                      indien:\n\n\u25cb de TSF voor de desbetreffende vervoerder is vergrendeld en\n\n\u25cb de O.BEDRIJFSGEGEVENS zijn ondertekend door een S.ONDERNEMERSKAART van de desbetreffende\n                                                            vervoerder;\n\n\u25cb De volgende gegevens:\n\n\u25cb O.SYSTEEMGEGEVENS en\n\n\u25cb alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS,\n                                                            O.KAARTHOUDERGEGEVENS en O.GEBEURTENISGEGEVENS geregistreerd gedurende de periode\n                                                            dat de TSF voor de desbetreffende vervoerder is vergrendeld of vergrendeld geweest\n                                                            (bedrijfsvergrendeling)\n\n(kunnen) uitvoeren naar S.BEDRIJFSMIDDELEN, indien:\n\n\u25cb de TSF voor de desbetreffende vervoerder is vergrendeld en\n\n\u25cb de TSF, als onderdeel van O.BEDRIJFSGEGEVENS, beschikt over een unieke autorisatie\n                                                            voor deze uitvoer die\n\n\u25cb een nog niet verstreken geldigheidsperiode voor deze uitvoer vermeldt.\n\n\u25cb NB: Als gegevens worden vastgelegd dan is dat inclusief de elektronische handtekening6.\n\n\u25cb ONBEKEND mag de in de TOE operationele O.PROGRAMMATUUR door de O.PROGRAMMATUUR uit\n                                                een (van S.UPDATEMIDDELEN afkomstige) O.PROGRAMMATUURREVISIE vervangen indien:\n\n\u25cb de O.PROGRAMMATUURREVISIE integer en authentiek is,\n\n\u25cb het versienummer van de in de TOE operationele O.PROGRAMMATUUR correspondeert met\n                                                      het criterium in O.VERVANGBARE_VERSIES uit de O.PROGRAMMATUURREVISIE en\n\n\u25cb de O.KALIBRATIEINDICATIE uit de O.PROGRAMMATUURREVISIE negatief is.\n\n\u25cb ONBEKEND mag O.SYSTEEMGEGEVENS tonen op een leesvenster.\n\n\u25cb BESTUURDER mag de eigen:\n\n\u25cb O.RITGEGEVENS, O.ARBEIDSTIJDENGEGEVENS en O.KAARTHOUDERGEGEVENS tonen op een leesvenster;\n\n\u25cb O.ARBEIDSTIJDENGEGEVENS opslaan op de S.CHAUFFEURSKAART;\n\n\u25cb O.ARBEIDSTIJDENGEGEVENS van de S.CHAUFFEURSKAART overbrengen naar de TOE;\n\n\u25cb O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS uitvoeren naar S.PRINTER.\n\n\u25cb BESTUURDER mag O.SYSTEEMGEGEVENS tonen op een leesvenster.\n\n\u25cb TOEZICHTHOUDER mag alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS,\n                                                O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS\n\n\u25cb tonen op een leesvenster;\n\n\u25cb uitvoeren naar S.PRINTER;\n\n\u25cb uitvoeren naar S.HANDHAVINGSMIDDELEN.\n\n\u25cb TOEZICHTHOUDER mag, mits de TOE is gedeactiveerd, O.POSITIEGEGEVENS\n\n\u25cb uitvoeren naar S.HANDHAVINGSMIDDELEN.\n\n\u25cb WERKPLAATS mag de TOE deactiveren.\n\n\u25cb WERKPLAATS mag O.VARIABELE_SYSTEEMGEGEVENS aanpassen\n\n\u25cb vanaf het bedieningspaneel;\n\n\u25cb vanaf S.KALIBRATIEMIDDELEN.\n\n\u25cb WERKPLAATS mag de in de TOE operationele O.PROGRAMMATUUR door de O.PROGRAMMATUUR uit\n                                                een (van S.UPDATEMIDDELEN afkomstige) O.PROGRAMMATUURREVISIE vervangen indien:\n\n\u25cb de O.PROGRAMMATUURREVISIE integer en authentiek is en\n\n\u25cb het versienummer van de in de TOE operationele O.PROGRAMMATUUR correspondeert met\n                                                      het criterium in O.VERVANGBARE_VERSIES uit de O.PROGRAMMATUURREVISIE.\n\n\u25cb WERKPLAATS mag alle O.BASISGEGEVENS, O.RITGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.BEDRIJFSGEGEVENS,\n                                                O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS\n\n\u25cb tonen op een leesvenster;\n\n\u25cb uitvoeren naar S.PRINTER;\n\n\u25cb uitvoeren naar S.KALIBRATIEMIDDELEN.\n\n\u25cb VERVOERDER mag alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS,\n                                                O.KAARTHOUDERGEGEVENS en O.GEBEURTENISGEGEVENS geregistreerd gedurende de periode\n                                                dat de TSF voor de desbetreffende vervoerder is vergrendeld of vergrendeld geweest\n                                                (bedrijfsvergrendeling)\n\n\u25cb tonen op een leesvenster;\n\n\u25cb uitvoeren naar S.PRINTER;\n\n\u25cb uitvoeren naar S.BEDRIJFSMIDDELEN.\n\n\u25cb VERVOERDER mag alle O.SYSTEEMGEGEVENS\n\n\u25cb tonen op een leesvenster;\n\n\u25cb uitvoeren naar S.PRINTER;\n\n\u25cb uitvoeren naar S.BEDRIJFSMIDDELEN.\n\n\u25cb VERVOERDER mag O.BEDRIJFSGEGEVENS aanpassen\n\n\u25cb vanaf het bedieningspaneel;\n\n\u25cb vanaf S.BEDRIJFSMIDDELEN.\n\nFDP_ACF.1.3 -7\n\nFDP_ACF.1.4 De TSF zal expliciet toegang van subjecten naar objecten weigeren gebaseerd op de\n                                          volgende regel:\n\n\u25cb Alle niet in FDP_ACF.1.2 genoemde toegang is niet toegestaan\n\nFDP_ETC.2 Export van gegevens met attributen\n\nFDP_ETC.2.1 De TSF dwingt het gebruik van het BCT-toegangsbeleid af wanneer O.BASISGEGEVENS,\n                                          O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEDRIJFSGEGEVENS, O.GEBEURTENISGEGEVENS\n                                          en O.SYSTEEMGEGEVENS gegevens worden overgebracht naar externe gegevensdragers of\n                                          inrichtingen buiten de TSF.\n\nFDP_ETC.2.2 De TSF exporteert gegevens inclusief de bijbehorende elektronische handtekening over\n                                          deze gegevens, behalve als deze naar S.PRINTER of het leesvenster worden ge\u00ebxporteerd.\n\nFDP_ETC.2.3 De TSF garandeert dat de elektronische handtekening onlosmakelijk is geassocieerd\n                                          met de ge\u00ebxporteerde gegevens.\n\nFDP_ETC.2.4 De TSF dwingt de volgende regels af wanneer gegevens worden ge\u00ebxporteerd van de TSF:\n\n\u25cb De TSF handhaaft de rangschikking van gegevens (berichtvolgorde) bij gegevensoverdracht\n                                                naar externe gegevensdragers of inrichtingen;\n\nFDP_ITC.1 Import van gegevens zonder attributen\n\nFDP_ITC.1.1 De TSF dwingt het gebruik van het BCT-toegangsbeleid af wanneer gegevens worden ingelezen\n                                          van S.BOORDCOMPUTERKAARTEN, S.BEWEGINGSOPNEMER, S.POSITIEBEPALINGSSENSOR, S.HANDHAVINGSMIDDELEN,\n                                          S.KALIBRATIEMIDDELEN, S.BEDRIJFSMIDDELEN, S.UPDATEMIDDELEN of S.TAXAMETER.FDP_ITC.1.2 De TSF negeert attributen wanneer gegevens worden ingelezen door de TSF.\n\nFDP_ITC.1.3 De TSF dwingt de volgende regels af wanneer gegevens worden ingelezen door de TSF:\n\n\u25cb De TSF verwerkt gegevens alleen wanneer deze afkomstig zijn van:\n\n\u25cb de interne tijdklok van de TSF;\n\n\u25cb de interne verplaatsingsopnemer van de TSF;\n\n\u25cb contact signaal (ignition sense);\n\n\u25cb invoer door de gebruiker via het bedieningspaneel;\n\n\u25cb S.BEWEGINGSOPNEMER;\n\n\u25cb S.POSITIEBEPALINGSSENSOR;\n\n\u25cb S.BOORDCOMPUTERKAARTEN;\n\n\u25cb S.SYSTEEMKAART;\n\n\u25cb S.TAXAMETER;\n\n\u25cb S.BEDRIJFSMIDDELEN;\n\n\u25cb S.UPDATEMIDDELEN.\n\nFDP_DAU.2 Data authenticatie met identiteit\n\nFDP_DAU.2.1 De TSF kan een bewijs van de validiteit van gegevens genereren als volgt:\n\n\u25cb Een hash van O.RITGEGEVENS wordt ondertekend door de S.SYSTEEMKAART over de volledige\n                                                set van desbetreffende O.RITGEGEVENS direct bij het registreren van deze gegevens\n                                                per individuele rit;\n\n\u25cb Een hash van O.ARBEIDSTIJDGEGEVENS wordt ondertekend door S.CHAUFFEURSKAART direct\n                                                bij het registreren van deze gegevens bij het be\u00ebindigen van de dienst van de bestuurder\n                                                of het afsluiten van de kaartsessie;\n\n\u25cb Een hash van O.ARBEIDSTIJDGEGEVENS wordt ondertekend door S.SYSTEEMKAART direct bij\n                                                het registreren van deze gegevens indien de S.CHAUFFEURSKAART niet beschikbaar is;\n\n\u25cb Een hash van alle gegevens overgebracht naar S.HANDHAVINGSMIDDELEN, S.BEDRIJFSMIDDELEN,\n                                                S.KALIBRATIEMIDDELEN wordt ondertekend door de S.SYSTEEMKAART op het moment van de\n                                                overdracht;\n\n\u25cb Hashes van alle geregistreerde O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS,\n                                                O.POSITIEGEGEVENS, O.BEDRIJFSGEGEVENS en O.GEBEURTENISGEGEVENS worden ondertekend\n                                                door S.SYSTEEMKAART.\n\nFDP_DAU.2.2 De TSF levert S.BOORDCOMPUTERKAART een mogelijkheid om het bewijs van de integriteit\n                                          en authenticiteit van de gegevens en de identiteit van de gebruiker die de gegevens\n                                          heeft ondertekend te verifi\u00ebren.\n\nFTP_ITC.1 Vertrouwd kanaal tussen TSFs\n\nFTP_ITC.1.1 De TSF levert een communicatiekanaal tussen de TSF en de S.SYSTEEMKAART. Dit communicatiekanaal\n                                          is gescheiden van andere communicatiekanalen, levert zekere identificatie van de eindpunten,\n                                          en beschermt de data op het kanaal tegen wijzigen of lekken.\n\nFTP_ITC.1.2 De TSF mag alleen zelf communicatie initi\u00ebren over het vertrouwde kanaal.\n\nFTP_ITC.1.3 De TSF zal communicatie initi\u00ebren over het vertrouwde kanaal voor het door S.SYSTEEMKAART\n                                          laten zetten van handtekeningen en het ontvangen van deze handtekeningen.\n\nFCS_COP.1 Cryptografische operaties\n\nFCS_COP.1.1 De TSF zal hash-operaties uitvoeren volgens zowel het SHA-1 en het SHA-256 cryptografische\n                                          algoritme zoals gedefinieerd in de ISO/IEC 10118-3, FIPS PUB 180-2 en ETSI TS 102\n                                          176-1 standaarden.\n\nFAU_GEN.1 Genereren van gebeurtenisgegevens8\n\nFAU_GEN.1.1 De TSF genereert een gebeurtenis record van de volgende gebeurtenissen:\n\n\u25cb het aanzetten van de TOE;\n\n\u2013 het uitzetten van de TOE;\n\n\u2013 het optreden van storingen9 in de werking van de TSF;\n\na. een storing in de werking van de registratiefunctie;\n\nb. een storing in de werking van de beveiligingsfuncties;\n\nc. een storing in de werking van de sensoren;\n\nd. een storing in de overbrenging naar een externe interface\n\ne. een storing in de werking van de systeemkaart;\n\nf. een storing in de werking van de boordcomputerkaarten.\n\n\u2013 het optreden van fouten10 in de werking van de TSF;\n\na. een integriteitfout in de programmatuur;\n\nb. een integriteitfout in de systeemgegevens;\n\nc. een integriteitfout in de opgeslagen gebruikersgegevens;\n\nd. een integriteitfout bij de gegevensuitvoer naar de chauffeurskaart;\n\ne. een fout in de registratiefunctie;\n\nf. een fout die de beveiliging van de boordcomputer in gevaar brengt;\n\ng. een fout bij de gegevensuitvoer naar externe inrichtingen;\n\nh. een fout bij het gebruik van de systeemkaart;\n\ni. een fout bij het gebruik van de boordcomputerkaart;\n\nj. een fout in de bewegingsensor;\n\nk. een fout in de positiebepalingsensor;\n\nl. een fout in de koppeling met de taxameter.\n\n\u25cb het inbrengen van S.BOORDCOMPUTERKAART;\n\n\u25cb het uitnemen van S.BOORDCOMPUTERKAART;\n\n\u2013 het inbrengen van een ongeldige S.BOORDCOMPUTERKAART;\n\n\u2013 het inbrengen van een S.CHAUFFEURSKAART waarvan blijkt dat de datum en het tijdstip\n                                                van de laatste registratie op S.CHAUFFEURSKAART op een later tijdstip valt dan de\n                                                actuele datum en tijdstip volgens de tijdwaarneming van de TSF;\n\n\u2013 het niet juist afsluiten van de kaartsessie;\n\n\u2013 het inbrengen van S.CHAUFFEURSKAART waarvan blijkt dat de laatste kaartsessie niet\n                                                juist is afgesloten;\n\n\u2013 het ontstaan van onvoldoende opslagcapaciteit;\n\n\u2013 het verdwijnen van onvoldoende opslagcapaciteit;\n\n\u2013 het ontstaan van onvoldoende opslagcapaciteit op de S.CHAUFFEURSKAART;\n\n\u2013 het verdwijnen van onvoldoende opslagcapaciteit op de S.CHAUFFEURSKAART;\n\n\u2013 het ontstaan van een onderbreking van ten minste 5 seconden in de stroomvoorziening\n                                                van de TOE;\n\n\u2013 het verdwijnen van een onderbreking van ten minste 5 seconden in de stroomvoorziening\n                                                van de TOE;\n\n\u2013 het begin van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld\n                                                in de toestand rijden;\n\n\u2013 het einde van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld\n                                                in de toestand rijden;\n\n\u2013 het vaststellen van een toestand verplaatsen door de verplaatsingsopnemer van de TOE\n                                                wanneer er geen O.BEWEGINGSGEGEVENS van de S.BEWEGINGSOPNEMER worden verkregen;\n\n\u2013 het begin van het niet kunnen verkrijgen van O.POSITIEGEGEVENS gedurende 5 minuten;\n\n\u2013 het einde van het niet kunnen verkrijgen van O.POSITIEGEGEVENS gedurende 5 minuten;\n\n\u2013 een afwijking van meer dan twee procent tussen de, met behulp van O.BEWEGINGSGEGEVENS\n                                                en de constante van de boordcomputer in de O.SYSTEEMGEGEVENS, berekende afstand en\n                                                de werkelijke afstand;\n\n\u2013 een afwijking van meer dan vijf procent tussen de O.BEWEGINGSGEGEVENS en de O.POSITIEGEGEVENS;\n\n\u2013 het ontstaan van een onderbreking in de koppeling met S.TAXAMETER;\n\n\u2013 het verdwijnen van een onderbreking in de koppeling met S.TAXAMETER;\n\n\u25cb het overbrengen van gegevens inclusief de naam van de gebruikte interface;\n\n\u2013 het activeren van de TSF;\n\n\u2013 het keuren van de TSF;\n\n\u2013 het deactiveren van de TSF;\n\n\u2013 het vergrendelen van de TSF;\n\n\u2013 het inschakelen van een werkingsmodus inclusief naam werkingsmodus;\n\n\u2013 het uitschakelen van een werkingsmodus inclusief naam werkingsmodus;\n\n\u2013 het begin van rijden in de operationele modus werkingsniveau taxivervoer zonder S.CHAUFFEURSKAART;\n\n\u2013 het einde van rijden in de operationele modus werkingsniveau taxivervoer zonder S.CHAUFFEURSKAART;\n\n\u2013 het detecteren van een niet-succesvolle authenticatiepoging;\n\n\u2013 het installeren van een programmatuurrevisie;\n\n\u2013 starten of stoppen van audit- en beveiligingsfuncties;\n\n\u2013 het uitblijven of weigeren van een elektronische handtekening door S.CHAUFFEURSKAART\n                                                of S.SYSTEEMKAART;\n\n\u2013 het detecteren van een niet-geautoriseerde (poging tot) wijziging van de TSF configuratie,\n                                                waaronder het detecteren van een (of meer) van de volgende aan het installeren van\n                                                een programmatuurrevisie gerelateerde situaties:\n\na. een integriteit- of authenticiteitfout in de aangeboden O.PROGRAMMATUURREVISIE;\n\nb. het versienummer van de in de TOE operationele O.PROGRAMMATUUR correspondeert niet\n                                                      met het criterium in O.VERVANGBARE_VERSIES uit de aangeboden O.PROGRAMMATUURREVISIE;\n\nc. het aanbieden van een O.PROGRAMMATUURREVISIE met een positieve O.KALIBRATIEINDICATIE\n                                                      terwijl de TOE zich niet in activerings- en keuringsmodus bevindt;\n\n\u2013 toegang tot het gebeurtenissenlogboek.\n\nFAU_GEN.1.2 De TSF legt per gebeurtenis ten minste de volgende informatie vast zoals die geldt\n                                          op het moment van optreden:\n\n\u25cb een automatisch gegenereerd oplopend volgnummer;\n\n\u25cb type van de gebeurtenis (de gebeurteniscode);\n\n\u25cb de datum en het tijdstip als geco\u00f6rdineerde wereldtijd;\n\n\u25cb de kilometerstand;\n\n\u25cb de verplaatsingstoestand van de auto (rijden/stilstaan);\n\n\u25cb de werkingsmodus en werkingsniveau van de TOE;\n\n\u25cb waar relevant, de uitkomst van de gebeurtenis;\n\n\u25cb waar relevant, aanvullende relevante informatie, waaronder, bij detectie van een niet\n                                                geautoriseerde (poging tot) installeren van een programmatuurrevisie, vermelding van\n                                                de specifieke reden waarom dit niet geautoriseerd is;\n\nals een storing of fout is opgetreden tevens:\n\n\u25cb de gebeurteniscode van de aanleiding voor de storing of fout;\n\nals een S.BOORDCOMPUTERKAART is ingebracht in de TSF tevens:\n\n\u25cb het kaartnummer en kaartsoort;\n\n\u25cb de gebruikeridentificatiecode;\n\nals geen S.BOORDCOMPUTERKAART is ingebracht, maar de gebruiker is ge\u00efdentificeerd\n                                          met een burgerservicenummer:\n\n\u25cb het burgerservicenummer.\n\nFAU_SAA.1 Detectie van potenti\u00eble inbreuk op beveiliging\n\nFAU_SAA.1.1 De TSF beschouwt de in FAU_GEN.1.1 met een \u2013 gemarkeerde gebeurtenissen als beveiligingsrelevant.\n\nFAU_ARP.1 Automatische respons op gebeurtenissen\n\nFAU_ARP.1.1 De TSF geeft een waarschuwingsignaal op het leesvenster wanneer een beveiligingsrelevante\n                                          gebeurtenis wordt gedetecteerd.\n\nFAU_STG.1 Bescherming van gebeurtenisgegevens\n\nFAU_STG.1.1 De TSF beschermt de opgeslagen gebeurtenis records in O.GEBEURTENISGEGEVENS tegen\n                                          ongeautoriseerd verwijderen.\n\nFAU_STG.1.2 De TSF voorkomt ongeautoriseerde aanpassingen in de opgeslagen gebeurtenis records\n                                          in O.GEBEURTENISGEGEVENS.\n\nFAU_STG.4 Voorkomen van verlies van gebeurtenisgegevens\n\nFAU_STG.4.1 De TSF overschrijft de oudste gebeurtenis records met nieuwere wanneer de opslagcapaciteit\n                                          voor de O.GEBEURTENISGEGEVENS vol is.\n\nFRU_RSA.2 Maximum en minimum quotas\n\nFRU_RSA.2.1 -11\n\nFRU_RSA.2.2 De TSF garandeert een minimum hoeveelheid opslagcapaciteit voldoende voor 365 dagen\n                                          van normaal gebruik tegelijkertijd te gebruiken voor:\n\n\u25cb O.BASISGEGEVENS;\n\n\u25cb O.RITGEGEVENS;\n\n\u25cb O.POSITIEGEGEVENS;\n\n\u25cb O.BEDRIJFSGEGEVENS;\n\n\u25cb O.GEBEURTENISGEGEVENS;\n\nFPT_STM.1 Tijd\n\nFPT_STM.1.1 De TSF is in staat om betrouwbare tijdsregistraties uit te voeren in de Universal\n                                          Time Coordinated met een afwijking van ten hoogste \u00e9\u00e9n (1) seconde en een resolutie\n                                          van \u00e9\u00e9n (1) seconde of nauwkeuriger.\n\nFPT_PHP.1 Passieve detectie van fysieke aanvallen\n\nFPT_PHP.1.1 De TSF zal een laboratorium in staat stellen om fysieke aanvallen ondubbelzinnig\n                                          te detecteren12.\n\nFPT_PHP.1.2 De TSF zal het mogelijk maken om te bepalen dat fysieke aanvallen op de TSF, de S.SYSTEEMKAART\n                                          of de verbinding tussen TSF en de S.SYSTEEMKAART hebben plaatsgevonden.\n\nFPT_TST.1 Testen van de TSF\n\nFPT_TST.1.1 De TSF zal een verzameling zelf-testen doen bij het opstarten om de correcte werking\n                                          van de TSF te demonstreren.\n\nFPT_TST.1.2 De TSF zal TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden om de\n                                          integriteit van de TSF data te verifi\u00ebren.\n\nFPT_TST.1.3 De TSF zal ONBEKEND, TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden\n                                          om de integriteit van de op de TOE operationele O.PROGRAMMATUUR, waaronder de TSF\n                                          uitvoerbare programmatuurcode (executables), te verifi\u00ebren.\n\nVoor de typegoedkeuring van de boordcomputer wordt een Common Criteria garantieniveau\n                                       vereist van ten minste EAL3. Dit niveau analyseert de geclaimde beveiligingsfuncties\n                                       door middel van een analyse van functionele en interface specificatie, (gebruikers)documentatie\n                                       en een beschrijving van de architectuur van de boordcomputer. De analyse wordt ondersteund\n                                       met onafhankelijk testen, verificatie van de testresultaten van de ontwikkelaar een\n                                       beperkt onderzoek naar zwakheden. Daarnaast worden aspecten van de gebruikte ontwerpmiddelen,\n                                       configuratiebeheer en leveringsprocedures beschouwd.\n\nIn combinatie met een uitgebreid en formeel ge\u00ebvalueerd beveiligingsprofiel (Protection\n                                       Profile), een periodiek onderzoek en actieve handhaving, kan aannemelijk worden gemaakt\n                                       dat goedgekeurde boordcomputers voldoende weerstand zullen bieden tegen de onderkende\n                                       dreigingen en dat gebrekkig functionerende boordcomputers kunnen worden opgespoord.\n\nDeze sectie bevat een uitleg dat de beveiligingsdoelstellingen het gehele beveiligingsprobleem\n                                          adresseren. Dit beveiligingsprobleem bestaat uit drie delen:\n\n\u25cb Dreigingen: Dit profiel bevat geen dreigingen, dus er is ook geen uitleg\n\n\u25cb Beveiligingsbeleid: Zie sectie 8.1.1\n\n\u25cb Aannames: Zie sectie 8.1.2\n\nDeze sectie bevat een uitleg dat de beveiligingsdoelstellingen alle delen van het\n                                             beveiligingsbeleid implementeren.\n\nP.VASTLEGGEN\n\nDeze wordt direct ondervangen door OT.VASTLEGGEN. Daarnaast vindt indirecte ondersteuning\n                                             plaats door OT.FYSIEKE_BEVEILIGING en OT.AUTHENTICATIE_BOORDCOMPUTERKAART.\n\nP.BEWAREN_EN_BORGEN\n\nHet bewaren van de gegevens wordt ondervangen door:\n\n\u25cb OT.OPSLAAN, wat de gegevens en alle elektronische handtekeningen opslaat.\n\nHet detecteren van de wijzigingen in de vastgelegde gegevens wordt ondervangen door:\n\n\u25cb Het aanbieden van de gegevens aan de systeemkaart (OT.KOPPELEN_AAN_SYSTEEMKAART) en\n                                                   het door deze ondertekenen van de gegevens (OE.SYSTEEMKAART);\n\n\u25cb Het aanbieden van gegevens aan de boordcomputerkaart (OT.KOPPELEN_AAN_BOORDCOMPUTERKAART)\n                                                   en het door deze ondertekenen van de gegevens (OE.BOORDCOMPUTERKAART).\n\nHet onweerlegbaar koppelen aan de TOE wordt ondervangen door:\n\n\u25cb Het aanbieden van de gegevens aan de systeemkaart (OT.KOPPELEN_AAN_SYSTEEMKAART) en\n                                                   het door deze ondertekenen van de gegevens (OE.SYSTEEMKAART);\n\n\u25cb Dat de systeemkaart een certificaat bevat welk onweerlegbaar is gekoppeld aan de TOE\n                                                   (OE.SYSTEEMKAART).\n\nHet onweerlegbaar koppelen aan de boordcomputerkaarthouder wordt ondervangen door:\n\n\u25cb Het aanbieden van gegevens aan de boordcomputerkaart (OT.KOPPELEN_AAN_BOORDCOMPUTERKAART)\n                                                   en het door deze ondertekenen van de gegevens (OE.BOORDCOMPUTERKAART);\n\n\u25cb Dat de boordcomputerkaart een certificaat bevat welk onweerlegbaar is gekoppeld aan\n                                                   de boordcomputerkaarthouder (OE.BOORDCOMPUTERKAART);\n\n\u25cb Dat de boordcomputerkaarthouder zich authenticeert met een PIN bij het insteken van\n                                                   de kaart (OT.AUTHENTICATIE_BOORDCOMPUTERKAART);\n\n\u25cb Dat de boordcomputerkaarthouder zijn kaart veilig bewaart en zijn PIN geheim houdt.\n                                                   (OE.BOORDCOMPUTERKAARTHOUDER).\n\nDaarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING, OT.AUDIT\n                                             en OT.BEWAKING_INTEGRITEIT.\n\nP.ACTIES\n\nDeze wordt direct ondervangen door OT.AUDIT, OT.UITVOEREN_GEGEVENS, OT.INVOEREN_GEGEVENS,\n                                             OT_VEILIG_UPDATEN, OT.AUTHENTICATIE_BOORDCOMPUTERKAART en OE.BEDIENING. Daarnaast\n                                             vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING en OT.BEWAKING_INTEGRITEIT.\n\nP.UITVOEREN_GEGEVENS\n\nDeze wordt direct ondervangen door OT.UITVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART\n                                             en OE.BEDIENING. Daarnaast vindt indirecte ondersteuning plaats door OE.PRINTER.\n\nP.INVOEREN_GEGEVENS\n\nDeze wordt direct ondervangen door OT.INVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART\n                                             en OE.BEDIENING.\n\nP.VEILIG_UPDATEN\n\nDeze wordt direct ondervangen door OT.VEILIG_UPDATEN, OE.VEILIG_UPDATEN, OT.AUTHENTICATIE_BOORDCOMPUTERKAART\n                                             en OE.BEDIENING. Daarnaast vindt indirecte ondersteuning plaats door OT.INVOEREN_GEGEVENS.\n\nP.DEACTIVERING\n\nDeze wordt direct ondervangen door OE.DEACTIVERING (voor deactivering en verwijderen\n                                             gegevens), OT.UITVOEREN_GEGEVENS (voor wat betreft het uitvoeren van gegevens) en\n                                             OT.AUTHENTICATIE_BOORDCOMPUTERKAART.\n\nDeze sectie bevat een uitleg dat de beveiligingsdoelstellingen alle aannames implementeren.\n\nA.BEDIENING\n\nDeze wordt direct ondervangen door OE.BEDIENING.\n\nA.SENSOREN\n\nDeze wordt direct ondervangen door OE.SENSOREN.\n\nA.SYSTEEMKAART\n\nDeze wordt direct ondervangen door OE.SYSTEEMKAART.\n\nA.BOORDCOMPUTERKAART\n\nDeze wordt direct ondervangen door OE.BOORDCOMPUTERKAART.\n\nA.BOORDCOMPUTERKAARTHOUDER\n\nDeze wordt direct ondervangen door OE.BOORDCOMPUTERKAARTHOUDER.\n\nA.PRINTER\n\nDeze wordt direct ondervangen door OE.PRINTER.\n\nA.VOOR_ACTIVERING\n\nDeze wordt direct ondervangen door OE.VOOR_ACTIVERING.\n\nOT.AUDIT\n\nDeze wordt gerealiseerd door FAU_GEN.1 die specificeert welke gegevens er van welke\n                                          gebeurtenissen worden vastgelegd.\n\nDit wordt ondersteund door:\n\n\u25cb FPT_STM.1 die aangeeft dat er een klok is die nauwkeurig de tijd aangeeft (zodat de\n                                                juiste datum en tijd wordt opgeslagen bij de gebeurtenisgegevens)\n\n\u25cb FAU_SAA.1 die aangeeft welke van de gebeurtenissen beveiligingsrelevant zijn\n\n\u25cb FAU_ARP.1 die aangeeft dat beveiligingsrelevante gegevens ook allemaal worden getoond\n                                                op het leesvenster\n\n\u25cb FAU_STG.1 die aangeeft dat de gegevens niet zo maar kunnen worden verwijderd of veranderd\n\n\u25cb FRU_RSA.2 dat vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal\n                                                gebruik\n\n\u25cb FAU_STG.4 dat vastlegt dat oude gegevens worden overschreven als de opslagruimte vol\n                                                raakt\n\nOT.AUTHENTICATIE_BOORDCOMPUTERKAART\n\nDeze wordt gerealiseerd door FIA_UID.1 (Boordcomputerkaarten) en FIA_UAU.1 (Boordcomputerkaarten)\n                                          welke de I&A regels voor boordcomputerkaarten geven\n\nDit wordt ondersteund door:\n\n\u25cb FIA_AFL.1 die aangeeft wat er gebeurt bij falende authenticatie\n\n\u25cb FIA_UAU.6 die aangeeft dat er onder sommige omstandigheden nogmaals moet worden geauthenticeerd\n\n\u25cb FTA_SSL.2 die tijdelijke blokkade van een sessie toelaat\n\n\u25cb FTA_SSL.3 die aangeeft wanneer een sessie wordt afgebroken\n\nOT.VASTLEGGEN\n\nDeze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.VASTLEGGEN\n                                          implementeren.\n\nDit wordt ondersteund door:\n\n\u25cb FIA_UID.2 (Overigen) die S.BEWEGINGSSENSOR en S.POSITIEBEPALINGSSENSOR identificeren;\n\n\u25cb FDP_ITC.1 die vastlegt dat gegevens mogen worden ingelezen van S.BEWEGINGSSENSOR en\n                                                S.POSITIEBEPALINGSSENSOR;\n\n\u25cb FRU_RSA.2 die vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal\n                                                gebruik;\n\n\u25cb FIA_UID.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART identificeert;\n\n\u25cb FIA_UAU.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART authenticeert.\n\nOT.KOPPELEN_AAN_SYSTEEMKAART\n\nDeze wordt gerealiseerd door FDP_DAU.2 die het zetten van een handtekening implementeert.\n                                          Dit wordt ondersteund door:\n\n\u25cb FIA_UID.2 (Systeemkaart) die S.SYSTEEMKAART identificeert.\n\n\u25cb FCS_COP.1 die een hash genereert (de hash wordt getekend in plaats van de gegevens)\n\n\u25cb FTP_ITC.1 die ervoor zorgdraagt dat de hash niet wordt veranderd voordat deze wordt\n                                                getekend\n\n\u25cb FDP_ACF.1 die specificeert dat de handtekening ook wordt opgeslagen\n\nOT.KOPPELEN_AAN_BOORDCOMPUTERKAART\n\nDeze wordt gerealiseerd door FDP_DAU.2 die het zetten van een handtekening implementeert.\n                                          Dit wordt ondersteund door:\n\n\u25cb FIA_UID.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART identificeert.\n\n\u25cb FIA_UAU.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART authenticeert.\n\n\u25cb FCS_COP.1 die een hash genereert (de hash wordt getekend in plaats van de gegevens)\n\n\u25cb FDP_ACF.1 die specificeert dat de handtekening ook wordt opgeslagen\n\n\u25cb FMT_SMR.2 die de verschillende rollen specificeert die bij de verschillende boordcomputerkaarten\n                                                horen\n\nOT.OPSLAAN\n\nZie OT.VASTLEGGEN, OT.KOPPELEN_AAN_SYSTEEMKAART en OT.KOPPELEN_AAN_BOORDCOMPUTERKAART.\n                                          Daarnaast wordt dit ondersteund door:\n\n\u25cb FRU_RSA.2 die vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal\n                                                gebruik\n\nOT.UITVOEREN_GEGEVENS\n\nDeze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.UITVOEREN_GEGEVENS\n                                          implementeren. Dit wordt ondersteund door:\n\n\u25cb FIA_UID.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART identificeert.\n\n\u25cb FIA_UAU.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART authenticeert.\n\n\u25cb FMT_SMR.2 die de verschillende rollen definieert;\n\n\u25cb FIA_UID.2 (Overigen) die de verschillende soorten randapparatuur identificeert waar\n                                                naar toe kan worden uitgevoerd;\n\n\u25cb FDP_ETC.2 die ervoor zorg draagt dat de elektronische handtekening mee wordt uitgevoerd.\n\nOT.INVOEREN_GEGEVENS\n\nDeze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.INVOEREN_GEGEVENS\n                                          implementeren. Dit wordt ondersteund door:\n\n\u25cb FIA_UID.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART identificeert.\n\n\u25cb FIA_UAU.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART authenticeert.\n\n\u25cb FMT_SMR.2 die de verschillende rollen definieert;\n\n\u25cb FIA_UID.2 (Overigen) die de verschillende soorten randapparatuur identificeert waarvandaan\n                                                kan worden ingevoerd;\n\n\u25cb FDP_ITC.1 die regels voor het invoeren vastlegt.\n\nOT.FYSIEKE_BEVEILIGING\n\nDeze wordt direct gerealiseerd door FPT_PHP.1.\n\nOT.BEWAKING_INTEGRITEIT\n\nDeze wordt direct gerealiseerd door FPT_TST.1.\n\nOT.VEILIG_UPDATEN\n\nDeze wordt direct gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.VEILIG_UPDATEN\n                                          implementeren. Dit wordt ondersteund door:\n\n\u25cb FIA_UID.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART identificeert.\n\n\u25cb FIA_UAU.1 (Boordcomputerkaarten) die S.BOORDCOMPUTERKAART authenticeert.\n\n\u25cb FMT_SMR.2 die de verschillende rollen definieert;\n\n\u25cb FIA_UID.2 (Overigen) die de verschillende soorten randapparatuur identificeert waarvandaan\n                                                kan worden ingevoerd;\n\n\u25cb FDP_ITC.1 die regels voor het invoeren definieert;\n\n\u25cb FAU_GEN.1 die gebeurtenissen m.b.t. P.VEILIG_UPDATEN definieert.\n\nDe volgende afhankelijkheden zijn niet vervuld:\n\n\u25cb FMT_MSA.3 (van FDP_ACF.1 en FDP_ITC.1): aangezien er geen attributen worden gebruikt,\n                                                hoeven de attributen ook niet te worden ge\u00efnitialiseerd;\n\n\u25cb FDP.ITC.1 of FDP_ITC.2 of FCS_CKM.1 (van FCS.COP.1): aangezien hashing geen sleutels\n                                                gebruikt, hoeven de sleutels ook niet te worden ge\u00efmporteerd of gegenereerd;\n\n\u25cb FCS_CKM.4 (van FCS_COP.1): aangezien hashing geen sleutels gebruikt, hoeven de sleutels\n                                                ook niet te worden vernietigd.\n\nVersie 2.2\n\nDatum 8\u00a0december 2014\n\nStatus DEFINITIEF\n\nArtikel 1\n\nDefinities\n\n34\n\nArtikel 2\n\nAlgemeen\n\n34\n\nArtikel 2.1\n\nDoel 6\n\n34\n\nArtikel 2.2\n\nHardware koppeling 6\n\n34\n\nArtikel 2.3\n\nSnelheidseis gegevenslevering 6\n\n34\n\nArtikel 2.4\n\nBestandsformaat 7\n\n35\n\nArtikel 2.5\n\nOverbrengingsprotocol 7\n\n35\n\nArtikel 2.6\n\nTotstandkoming gegevenslevering 7\n\n35\n\nArtikel 2.6.1\n\nPeriode gegevenslevering 7\n\n35\n\nArtikel 2.6.2\n\nVerwerking gegevenslevering 9\n\n37\n\nArtikel 2.7\n\nAuthenticatie en autorisatie 10\n\n37\n\nArtikel 2.8\n\nIntegriteit 10\n\n38\n\nArtikel 2.8.1\n\nIntegriteit exportbericht 10\n\n38\n\nArtikel 2.8.2\n\nIntegriteit geregistreerde gegevens 14\n\n41\n\nArtikel 2.8.3\n\nProcesschema\u2019s 15\n\n42\n\nArtikel 2.9\n\nFoutafhandeling 19\n\n44\n\nArtikel 2.9.1\n\nFunctionele fouten 19\n\n45\n\nArtikel 2.9.2\n\nTechnische fouten 19\n\n45\n\nArtikel 2.9.3\n\nOnvolledige gegevens 19\n\n45\n\nArtikel 2.10\n\nOverige kenmerken 19\n\n45\n\nArtikel 3\n\nRitadministratie 20\n\n45\n\nArtikel 3.1\n\nGegevens en functionele en technische berichtstructuur 20\n\n45\n\nArtikel 3.2\n\nRitadministratie.xsd 22\n\n47\n\nArtikel 3.3\n\nVolgorde gegevens 24\n\n49\n\nArtikel 3.4\n\nIntegriteit gegevens 24\n\n50\n\nArtikel 3.5\n\nOverige kenmerken 25\n\n50\n\nArtikel 3.5.1\n\nNaamgeving 25\n\n50\n\nArtikel 3.5.2\n\nBerichtgrootte 25\n\n50\n\nArtikel 4\n\nArbeids-, rij- en rusttijden 25\n\n50\n\nArtikel 4.1\n\nGegevens en functionele en technische berichtstructuur 25\n\n50\n\nArtikel 4.2\n\nArbeidstijden.xsd 27\n\n53\n\nArtikel 4.3\n\nVolgorde gegevens 29\n\n56\n\nArtikel 4.4\n\nIntegriteit gegevens 30\n\n56\n\nArtikel 4.5\n\nOverige kenmerken 30\n\n57\n\nArtikel 4.5.1\n\nNaamgeving 30\n\n57\n\nArtikel 4.5.2\n\nBerichtgrootte 31\n\n57\n\nArtikel 5\n\nCo\u00f6rdinaten 31\n\n57\n\nArtikel 5.1\n\nGegevens en functionele en technische berichtstructuur 31\n\n57\n\nArtikel 5.2\n\nCoordinaten.xsd 32\n\n58\n\nArtikel 5.3\n\nVolgorde gegevens 33\n\n60\n\nArtikel 5.4\n\nIntegriteit gegevens 33\n\n60\n\nArtikel 5.5\n\nOverige kenmerken 33\n\n60\n\nArtikel 5.5.1\n\nNaamgeving 33\n\n60\n\nArtikel 5.5.2\n\nBerichtgrootte 33\n\n60\n\nArtikel 6\n\nGebeurtenis 34\n\n60\n\nArtikel 6.1\n\nGegevens en functionele en technische berichtstructuur 34\n\n60\n\nArtikel 6.2\n\nGebeurtenis.xsd 35\n\n62\n\nArtikel 6.3\n\nVolgorde gegevens 37\n\n63\n\nArtikel 6.4\n\nIntegriteit gegevens 37\n\n64\n\nArtikel 6.5\n\nCodetabel 37\n\n64\n\nArtikel 6.6\n\nOverige kenmerken 39\n\n65\n\nArtikel 6.6.1\n\nNaamgeving 39\n\n65\n\nArtikel 6.6.2\n\nBerichtgrootte 39\n\n65\n\nArtikel 7\n\nOnderzoek 39\n\n66\n\nArtikel 7.1\n\nGegevens en functionele en technische berichtstructuur 39\n\n66\n\nArtikel 7.2\n\nOnderzoek.xsd 41\n\n68\n\nArtikel 7.3\n\nVolgorde gegevens 43\n\n71\n\nArtikel 7.4\n\nIntegriteit gegevens 43\n\n71\n\nArtikel 7.5\n\nOverige kenmerken 44\n\n71\n\nArtikel 7.5.1\n\nNaamgeving 44\n\n71\n\nArtikel 7.5.2\n\nBerichtgrootte 44\n\n72\n\nArtikel 8\n\nChauffeurskaartdata 44\n\n72\n\nArtikel 8.1\n\nGegevens en functionele en technische berichtstructuur 44\n\n72\n\nArtikel 8.2\n\nChauffeurskaartdata.xsd 45\n\n73\n\nArtikel 8.3\n\nVolgorde gegevens 47\n\n74\n\nArtikel 8.4\n\nIntegriteit gegevens 47\n\n75\n\nArtikel 8.5\n\nOverige kenmerken 47\n\n75\n\nArtikel 8.5.1\n\nNaamgeving 47\n\n75\n\nArtikel 8.5.2\n\nBerichtgrootte 47\n\n75\n\nArtikel 9\n\nToelichting specificaties gegevensleveringen en algemene XSD 48\n\n75\n\nArtikel 9.1\n\nToelichting bij specificaties van gegevensleveringen 48\n\n75\n\nArtikel 9.2\n\nAlgemene XML schema definities in bcttypes.xsd 48\n\n77\n\nIn deze bijlage wordt verstaan onder:\n\na. \nXML: eXtensible Markup Language;\n\nb. \nUSB: Universal Serial Bus;\n\nc. \nritadministratie.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering ritadministratie;\n\nd. \narbeidstijden.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering Arbeids-, rij\n                                             en rusttijden;\n\ne. \ncoordinaten.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering co\u00f6rdinaten;\n\nf. \ngebeurtenis.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering gebeurtenis;\n\ng. \nonderzoek.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering onderzoek;\n\nh. \nchauffeurskaartdata.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering chauffeurskaartdata;\n\ni. \nbcttypes.xsd: XML schema definitie van de gegevenstypen die in de XML schema definities genoemd\n                                             onder c. t/m h. worden gebruikt.\n\nAan dit document wordt gerefereerd als \u2018Gegevensoverbrengingsinterface Boordcomputer\n                                       Taxi Versie 2.2\u2019. Deze versie dateert van 8\u00a0december 2014\u2019.\n\nIn dit artikel worden de gemeenschappelijke kenmerken beschreven die gelden voor de\n                                          gegevensleveringen \u2018Ritadministratie\u2019, \u2018Arbeids-, rij- en rusttijden\u2019, \u2018Co\u00f6rdinaten\u2019,\n                                          \u2018Gebeurtenis\u2019, \u2018Onderzoek\u2019 en \u2018Chauffeurskaartdata\u2019.\n\nDe overbrengingsinterface die gebruikt wordt voor de gegevensoverbrenging naar een\n                                          externe gegevensdrager is een USB poort. Er geldt:\n\na. de USB poort moet aantoonbaar compliant zijn met de specificaties zoals opgesteld\n                                                door het USB Implementers Forum, Inc.;\n\nb. de USB poort is een USB type A connector.\n\nDe snelheidseis, als beschreven in artikel 2.3, is leidend bij de keuze van USB 1.1\n                                          of hoger. Als de snelheidseis van alle gegevensleveringen (\u2018Ritadministratie\u2019, \u2018Arbeids-, rij- en rusttijden\u2019, \u2018Co\u00f6rdinaten\u2019, \u2018Gebeurtenis\u2019 \u2018Onderzoek\u2019\n                                             en \u2018Chauffeurskaartdata\u2019) beschreven in deze bijlage gehaald kan worden met USB 1.1 (12 Mbit/s) dan is USB\n                                          1.1 toegestaan, zo niet dan moet USB 2.0 (480 Mbit/s) of hoger gebruikt worden.\n\nNa opvragen van een gegevenslevering moet het corresponderende XML bericht binnen\n                                          de volgende termijnen beschikbaar zijn op het externe gegevensdrager:\n\na. Bestand tot 3 Mbyte binnen 10 seconden;\n\nb. Voor iedere Mbyte die het bestand groter is kan de termijn met 3 seconden worden vergroot.\n\nVoor externe opslagmedia moet het bestandssysteem FAT32 ondersteund worden.\n\nDe boordcomputer fungeert als host en neemt het initiatief voor gegevensoverdracht\n                                          naar de externe gegevensdrager.\n\nOm een gegevenslevering tot stand te laten komen, stelt de boordcomputer de houder\n                                          van een boordcomputerkaart in staat om:\n\na. zich met de boordcomputerkaart te authenticeren;\n\nb. de externe gegevensdrager met de overbrengingsinterface van de boordcomputer te verbinden;\n\nc. op de boordcomputer \u00e9\u00e9n of meerdere gegevensleveringen te selecteren. Standaard zijn\n                                                alle gegevensleveringen waarvoor de gebruiker is geautoriseerd geselecteerd;\n\nd. op de boordcomputer een periode in te voeren waarover gegevens opgevraagd moeten worden\n                                                voor de betreffende gegevenslevering(en).\n\ne. op de boordcomputer de betreffende gegevenslevering(en) over de ingevoerde periode\n                                                met \u00e9\u00e9n gebruikershandeling starten.\n\nNadat alle geselecteerde gegevensleveringen succesvol zijn afgerond en de berichten\n                                          met de gegevens beschikbaar zijn op de externe gegevensdrager, toont de boordcomputer\n                                          een melding dat de gegevens beschikbaar zijn.\n\nDe periode, als bedoeld in artikel 2.6, onderdeel d, bedraagt per levering maximaal\n                                             1 jaar, met uitzondering van de gegevenslevering \u2018Onderzoek\u2019 die geen maximum periode\n                                             kent, en de gegevenslevering \u2018Chauffeurskaartdata\u2019 die de periode van de arbeids-,\n                                             rij- en rusttijdendata van de chauffeurskaart overneemt.\n\nDe standaardwaarde voor \u2018Datumtijd begin periode\u2019 is het tijdstip van opvragen minus\n                                             29 kalenderdagen, met uitzondering van de gegevenslevering \u2018Onderzoek\u2019, waar \u2018Datumtijd\n                                             begin periode\u2019 standaard leeg is, en de gegevenslevering \u2018Chauffeurskaartdata\u2019, waar\n                                             de standaarwaarde voor \u2018Datumtijd begin periode\u2019 overeenkomt met het oudste record\n                                             op de chauffeurskaart. \u2018Datumtijd einde periode\u2019 is standaard leeg. Als bij opvragen\n                                             van een gegevenslevering \u2018Datumtijd begin periode\u2019 leeg is, wordt deze gevuld met\n                                             de datum en het tijdstip van de activering. Is \u2018Datumtijd einde periode\u2019 leeg, dan\n                                             wordt \u2018Datumtijd einde periode\u2019 gevuld met de datum en het tijdstip waarop het bericht\n                                             wordt samengesteld;\n\nIn de gegevenslevering \u2018Co\u00f6rdinaten\u2019, \u2018Gebeurtenis\u2019 en \u2018Onderzoek\u2019 worden alle gegevens\n                                             opgenomen die binnen de opgevraagde periode vallen.\n\nIn de gegevenslevering \u2018Ritadministratie\u2019, \u2018Arbeidstijd\u2019 en \u2018Chauffeurskaartdata\u2019\n                                             worden alle gegevensets opgenomen die de gevraagde periode, inclusief grenzen, overlappen.\n                                             In de onderstaande tabel is de selectie voor deze gegevensleveringen verder uitgewerkt.\n                                             Alle gegevensets worden opgenomen die voldoen aan \u00e9\u00e9n van de onderstaande condities:\n\nConditie 1\n\nDatumtijd begin gegevenset ligt v\u00f3\u00f3r Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset is gelijk aan Datumtijd begin periode\n\nConditie 2\n\nDatumtijd begin gegevenset ligt v\u00f3\u00f3r Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt n\u00e1 Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt v\u00f3\u00f3r Datumtijd einde periode\n\nConditie 3\n\nDatumtijd begin gegevenset ligt v\u00f3\u00f3r Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt n\u00e1 Datumtijd einde periode\n\nConditie 4\n\nDatumtijd begin gegevenset is gelijk aan Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt n\u00e1 Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt v\u00f3\u00f3r Datumtijd einde periode\n\nConditie 5\n\nDatumtijd begin gegevenset is gelijk aan Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset is gelijk aan Datumtijd einde periode\n\nConditie 6\n\nDatumtijd begin gegevenset is gelijk aan Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt na Datumtijd einde periode\n\nConditie 7\n\nDatumtijd begin gegevenset ligt na Datumtijd begin periode\n\nen\n\nDatumtijd begin gegevenset ligt voor Datumtijd einde periode\n\nen\n\nDatumtijd einde gegevenset ligt na Datumtijd begin periode\n\nen\n\nDatumtijd einde gegevenset ligt voor Datumtijd einde periode\n\nConditie 8\n\nDatumtijd begin gegevenset ligt na Datumtijd begin periode\n\nen\n\nDatumtijd begin gegevenset ligt voor Datumtijd einde periode\n\nen\n\nDatumtijd einde gegevenset is gelijk aan Datumtijd einde periode\n\nConditie 9\n\nDatumtijd begin gegevenset ligt na Datumtijd begin periode\n\nen\n\nDatumtijd begin gegevenset ligt voor Datumtijd einde periode\n\nen\n\nDatumtijd einde gegevenset ligt na Datumtijd einde periode\n\nConditie 10\n\nDatumtijd begin gegevenset is gelijk aan Datumtijd einde periode\n\nen\n\nDatumtijd einde gegevenset ligt na Datumtijd einde periode\n\nDe tabel kan als volgt gevisualiseerd worden. Alle gegevenssets behalve gegevensset\n                                             11 en 12 worden in het bericht opgenomen.\n\nAanvragen van een gegevenslevering is een synchrone aanvraag die direct verwerkt moet\n                                             worden.\n\nAls de boordcomputer bezig is met de verwerking van een aanvraag voor een gegevenslevering,\n                                             dan is het niet mogelijk om dezelfde gegevenslevering of een andere gegevenslevering\n                                             aan te vragen zolang de huidige aanvraag niet is afgerond.\n\nHet is wel eenvoudig mogelijk om een aanvraag te onderbreken. Na onderbreken van de\n                                             huidige aanvraag is een nieuwe aanvraag van een gegevenslevering direct (< 1\u00a0seconde\n                                             wachten) mogelijk.\n\nDe overige functies van de boordcomputer blijven functioneren als de boordcomputer\n                                             bezig is met het verwerken van een aanvraag voor een gegevenslevering \u2018Ritadministratie\u2019, \u2018Arbeids-, rij- en rusttijden\u2019, \u2018Co\u00f6rdinaten\u2019, \u2018Gebeurtenis\u2019,\n                                                \u2018Onderzoek\u2019 of \u2018Chauffeurskaartdata\u2019.\n\nOverschrijven van een bericht op de externe gegevensdrager met dezelfde naam, is alleen\n                                             toegestaan na een bevestiging van de gebruiker.\n\nAanvragen van de gegevensleveringen \u2018Ritadministratie\u2019, \u2018Arbeids-, rij- en rusttijden\u2019, \u2018Co\u00f6rdinaten\u2019, \u2018Gebeurtenis\u2019,\n                                             \u2018Onderzoek\u2019 en \u2018Chauffeurskaartdata\u2019 moet alleen mogelijk zijn voor daartoe geauthenticeerde en geautoriseerde gebruikers.\n\nDe door de boordcomputer geregistreerde gegevens worden voorzien van een elektronische\n                                          handtekening zodat achteraf de authenticiteit en integriteit van deze gegevens kan\n                                          worden vastgesteld. Voor het aanmaken van de elektronische handtekeningen worden de\n                                          boordcomputerkaarten gebruikt.\n\nDe integriteit van gegevens wordt onderverdeeld in \u2018integriteit exportbericht\u2019 en\n                                          \u2018integriteit geregistreerde gegevens\u2019.\n\nDe boordcomputer kent zes gegevensleveringen, te weten \u2018Ritadministratie\u2019, \u2018Arbeids-, rij- en rusttijden\u2019, \u2018Co\u00f6rdinaten\u2019, \u2018Gebeurtenis\u2019,\n                                                \u2018Onderzoek\u2019 en \u2018Chauffeurskaartdata\u2019. Deze gegevensleveringen worden elk in een exportbericht vanuit de boordcomputer\n                                             overgebracht. Dit exportbericht is een XML bericht dat bestaat uit een gegevenslevering-element\n                                             zoals gespecificeerd in \u00e9\u00e9n van de artikelen 3 t/m 8, gevolgd door een element met\n                                             een elektronische handtekening berekend over het gegevenslevering-element en de identificatie\n                                             van de sleutel gebruikt voor het berekenen van de elektronische handtekening.\n\nVoor het genereren en de opmaak van de elektronische handtekening wordt gebruik gemaakt\n                                             van de W3C Recommendation \u2018XML Signature Syntax and Processing Version 1.1\u2019 (XMLDSIG11)\n                                             van 11\u00a0april 2013. De XMLDSIG11 specificatie (http://www.w3.org/TR/xmldsig-core1/)\n                                             is een door het World Wide Web Consortium (W3C) ontworpen standaard voor de XML syntax\n                                             en het genereren van elektronische handtekeningen.\n\nHet XML exportbericht bestaat uit een <Envelope>-element met daarin een van de gegevenslevering-elementen\n                                             <Ritadministratie>, <Arbeidstijden>, <Coordinaten>, <Gebeurtenis>, <Onderzoek> of\n                                             <Chauffeurskaartdata>, gevolgd door een <Signature>-element. Het gegevenslevering-element\n                                             bevat een resultaatbericht van een gegevenslevering zoals gespecificeerd in \u00e9\u00e9n van\n                                             de artikelen 3 t/m 8. Het <Signature>-element is opgebouwd conform de XMLDSIG11 specificatie\n                                             en bevat achtereenvolgens de elementen\n\na. <SignedInfo> met daarin o.a. verwijzingen naar en de \u2018message digests\u2019 van het gegevenslevering-element\n                                                   respectievelijk het <KeyInfo> element,\n\nb. <SignatureValue> met daarin de elektronische handtekening over het <SignedInfo> element\n                                                   en\n\nc. <KeyInfo> met daarin een representatie van het certificaat behorende bij de sleutel\n                                                   die voor de handtekening werd gebruikt.\n\nHet XML exportbericht kent, afhankelijk van de omsloten gegevenslevering, een van\n                                             de volgende structuren:\n\nHet <Signature> element in eender welke van de zes bovenstaande XML exportberichten\n                                             heeft altijd de volgende, aan de XMLDSIG11 conformerende, opbouw:\n\nToelichting:\n\na. de waarden op een gele achtergrond betreffen voorbeelden; deze waarden moeten door de boordcomputer berekend\n                                                   en/of bepaald worden;\n\nb. het gegevenslevering-element uit de omvattende <Envelop> bevat het resultaat bericht\n                                                   van een gegevenslevering en heeft een Id gelijk aan \u2018idGegevenslevering\u2019;\n\nc. het <KeyInfo> heeft een Id gelijk aan \u2018idKeyInfo\u2019;\n\nd. het <SignedInfo> element verwijst met twee <Reference> elementen naar twee te ondertekenen\n                                                   elementen op basisvan hun Id (zie de tekst op een blauwe achtergrond);\n\ne. zowel het gegevenlevering-element als het <KeyInfo>-element worden als volgt getransformeerd:\n                                                   eerst gecanonicaliseerd en daarna van alle overbodige witruimte ontdaan:\n\n1. de witruimte van alle text() nodes worden genormaliseerd met normalize-space(.);\n\n2. de (enige) text() node van elk element met Base64 gecodeerde inhoud wordt bovendien\n                                                         van alle (resterende) spaties ontdaan met translate(..., \u2018 \u2019, \u2018\u2019) (zie de tekst op\n                                                         een groene achtergrond).\n\nf. het <DigestValue> element van het eerste <Reference> element moet worden gevuld met\n                                                   de Base64 codering van de SHA-256 hash van het (volgens e. getransformeerde) gegevenslevering-element;\n\ng. het <DigestValue> element van het tweede <Reference> element moet worden gevuld met\n                                                   de Base64 codering van de SHA-256 hash van het (volgens e. getransformeerde) <KeyInfo>-element;\n\nh. het <SignedInfo> element moet, zoals hierboven weergegeven, ontdaan van alle overbodige\n                                                   witruimte in de envelop worden opgenomen, omdat de XMLDSIG11 standaard niet voorziet\n                                                   in het toepassen van enige andere transformatie dan canonicaliseren van dit element;\n\ni. het <SignatureValue> element moet worden gevuld met de Base64 codering van de RSA-SHA256\n                                                   (PKCS#1 v1.5) handtekening die berekend is over het (volgens h. opgemaakte en daarna\n                                                   gecanocaliseerde) <SignedInfo> element. Voor het opbouwen van deze handtekening wordt\n                                                   verwezen naar sectie 6.4.2 van XMLDSIG11;\n\nj. het <X509Certificate> element moet worden gevuld met de Base64 codering van het DER-gecodeerde\n                                                   certificaat behorende bij de RSA-sleutel waarmee de <SignatureValue> is berekend (in\n                                                   dit geval het boordcomputercertificaat);\n\nk. Alle canonicalisatie moet plaatsvinden conform \u2018Exclusive XML Canonicalization Version\n                                                   1.0, 18 July 2002\u2019 (XML-EXC-C14N) met identifier http://www.w3.org/2001/10/xml-exc-c14n#;\n\nl. Alle XSL transformaties moeten plaatsvinden conform \u2018XSL Transformations (XSLT) Version\n                                                   1.0, 16 November 1999\u2019 (XSLT) met identifier http://www.w3.org/TR/1999/REC-xslt-19991116\n                                                   en de daaraan gerelateerde standaard \u2018XML Path Language (XPath) Version 1.0, 16 November\n                                                   1999\u2019 met identifier http://www.w3.org/TR/1999/REC-xpath-19991116;\n\nm. Alle Base64 codering vindt in eerste instantie plaats op basis van de specificatie\n                                                   in XMLDSIG11;\n\nn. Voorafgaand aan hashing en/of ondertekening van een XML node moet die node worden\n                                                   gecanonicaliseerd volgens XML-EXC-C14N en moet:\n\n1. elke text-node worden genormaliseerd volgens de XPath normalize-space functie;\n\n2. elke text-node die Base64 gecodeerd is bovendien worden ontdaan van alle resterende\n                                                         spaties conform de XPath functie translate(string, \u2018 \u2019, \u2018\u2019).\n\nDe keuze van het algoritme voor de Digest en de Signature is afhankelijk van het certificaat\n                                             op de kaart waarmee de handtekening wordt gezet. Als dit in de toekomst anders wordt\n                                             dan SHA-256 respectievelijk RSA-SHA256\u2019 zullen de algoritmes voor Digest en Signature\n                                             meeveranderen.\n\nBepaalde gegevenssets, die door de boordcomputer taxi worden geregistreerd, dienen\n                                             vanaf het moment van vastleggen de waarborg van integriteit en authenticiteit te bevatten.\n                                             In de specificatie van elke soort gegevenslevering in artikel 3 t/m 8 wordt aangegeven\n                                             welke gegevensset dit betreft, op welke momenten deze gegevensset met een elektronische\n                                             handtekening worden ondertekend en als zodanig moeten worden vastgelegd en met welke\n                                             private sleutel die ondertekening moet gebeuren.\n\nVoor een gegevensset die bij vastleggen elektronisch ondertekend wordt, wordt een\n                                             tekenbericht gegenereerd. Dit tekenbericht is, op enkele uitzonderingen na, gelijk\n                                             aan het (corresponderende) XML exportbericht:\n\nVoor de namespace en de structuur van het betreffende <Data> element wordt verwezen\n                                             naar de artikelen 3.4, 4.4, 6.4, 7.4, respectievelijk 8.4.\n\nOok het <Signature> element van het tekenbericht wijkt op slechts enkele onderdelen\n                                             af van die van het XML exportbericht:\n\na. Het eerste <Reference> element heeft een andere URI, namelijk \u2018#idData\u2019;\n\nb. De inhoud van het <X509Certificate> element representeert, afhankelijk van het gestelde\n                                                   in de artikelen 3.1, 4.1, 6.1, 7.1, respectievelijk 8.1, ofwel het boordcomputercertificaat\n                                                   ofwel het chauffeurskaartcertificaat.\n\nNa generatie van het tekenbericht wordt de waarde van het element <SignatureValue>\n                                             als <Integriteit> element opgeslagen bij de gegevens waarover de elektronische handtekening\n                                             is berekend. Het tekenbericht zelf hoeft niet te worden opgeslagen, zolang de getekende\n                                             gegevens in de vorm waarin zij werden getekend kunnen worden gereproduceerd. Dat betekent\n                                             dat de boordcomputer, behalve de gegevens die het <Data> element vormen, het certificaat\n                                             dat voor ondertekening werd gebruikt, moet vastleggen.\n\nHet genereren en vastleggen van de elektronische handtekening over het <Data> element\n                                             vindt plaats bij het vastleggen van de gegevens die het <Data> element vormen.\n\nBij het samenstellen van een exportbericht worden de gegevens van het <Data> element\n                                             onveranderd overgenomen uit de administratie op de boordcomputer. Het <Data> element\n                                             wordt opnieuw geproduceerd, en moet exact gelijk zijn aan het <Data> element waarvoor\n                                             een elektronische handtekening is berekend bij vastleggen van het gegeven. De geregistreerde\n                                             elektronische handtekening moet worden overgenomen in het <Integriteit> element, het\n                                             is niet toegestaan om de elektronische handtekening opnieuw te berekenen. Ook moet\n                                             per <Integriteit> element het voor de betreffende handtekening gebruikte certificaat\n                                             onveranderd worden overgenomen uit de administratie op de boordcomputer.\n\nEen mogelijk proces voor samenstellen van de elementen voor een tekenbericht en het\n                                             genereren van de elektronische handtekening over die elementen is weergegeven in figuur\n                                             2.\n\nVan de output van de groen gekleurde deelprocessen kan het tekenbericht (zonder <SignatureValue>)\n                                             worden samengesteld. De 256-bytes RSA handtekening zou daarna gebruikt kunnen worden\n                                             voor het completeren van het tekenbericht, maar moet in ieder geval worden gearchiveerd\n                                             in de boordcomputer.\n\nFiguur 3 geeft een mogelijk proces voor samenstellen van de elementen van een exportbericht\n                                             weer. Het exportbericht kan worden geassembleerd met de output van de groen gekleurde\n                                             deelprocessen.\n\nBij het opvragen van de gegevensleveringen kunnen foutsituaties optreden. Hierbij\n                                          kan onderscheid gemaakt worden tussen functionele fouten, technische fouten en niet\n                                          volledige gegevens.\n\nBij onderstaande foutsituaties moet de boordcomputer de bijbehorende foutmelding tonen:\n\nFoutsituatie\n\nAfhandeling\n\nBoordcomputer is niet vergrendeld sinds laatste activering.\n\nVerwerking gegevenslevering(en) stopt en de boordcomputer toont de melding \u2018Boordcomputer\n                                                            is niet vergrendeld sinds laatste activering\u2019.\n\nEr is geen externe gegevensdrager verbonden met de overbrengingsinterface van de boordcomputer\n                                                            als de gebruiker een gegevenslevering start.\n\nVerwerking gegevenslevering(en) stopt en de boordcomputer toont de melding \u2018Geen externe\n                                                            gegevensdrager beschikbaar\u2019.\n\n\u2018Datumtijd begin periode\u2019 bevat geen geldige waarde als de gebruiker een gegevenslevering start. \u2018Datumtijd\n                                                            begin periode\u2019 is verplicht.\n\nVerwerking gegevenslevering(en) stopt en de boordcomputer toont de melding \u2018Datumtijd\n                                                            begin periode bevat geen geldige waarde\u2019.\n\n\u2018Datumtijd einde periode\u2019 bevat geen geldige waarde als de gebruiker een gegevenslevering start. \u2018Datumtijd\n                                                            einde periode\u2019 mag leeg zijn.\n\nVerwerking gegevenslevering(en) stopt en de boordcomputer toont de melding \u2018Datumtijd\n                                                            einde periode bevat geen geldige waarde\u2019.\n\n\u2018Datumtijd einde periode\u2019 ligt voor \u2018Datumtijd begin periode\u2019 als de gebruiker een gegevenslevering start.\n\nVerwerking gegevenslevering(en) stopt en de boordcomputer toont de melding \u2018Datumtijd\n                                                            einde periode ligt voor Datumtijd begin periode\u2019.\n\nOverige functionele foutsituaties\n\nVerwerking gegevenslevering stopt en de boordcomputer toont een foutmelding.\n\nFoutsituatie\n\nAfhandeling\n\nExporteren van een bericht naar de externe gegevensdrager gaat fout.\n\nVerwerking gegevenslevering(en) stopt en de boordcomputer toont de melding \u2018Exporteren\n                                                            van een bericht naar de externe gegevensdrager is niet gelukt\u2019.\n\nOverige technische foutsituaties.\n\nVerwerking gegevenslevering stopt en de boordcomputer toont een foutmelding.\n\nHet niet volledig zijn van gegevens op de boordcomputer mag geen reden zijn om een\n                                             resultaat bericht niet te exporteren.\n\nKenmerk\n\nInvulling\n\nTekenset bericht\n\nDe Unicode tekensets \u2018Basic Latin\u2019, \u2018Latin-1 Supplement\u2019 en \u2018Latin Extended-A\u2019, alsmede\n                                                         de controle karakters tab, linefeed en carriage return karakters.\n\nCode points: U+0009, U+000A, U+000D, U+0020 t/m U+007E en U+00A0 t/m U+017F.\n\nCodering bericht\n\nUTF-8\n\nVoor het bericht \u2018Ritadministratie\u2019 worden de volgende gegevens en functionele en\n                                          technische berichtstructuur onderkend:\n\nEntiteit / attribuut\n\nXML element\n\nInhoud\n\nG\n\nC\n\nBERICHT\n\nRitadministratie;\n\nId=\u201didGegevenslevering\u201d\n\nSEQ\n\nV\n\n1\n\nDatumtijd samenstellen bericht\n\nDatTdSmBr\n\nDT\n\nV\n\n1\n\nKORTE IDENTIFICATIE BOORDCOMPUTER\n\nKortIdBCT\n\nSEQ\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nProgrammatuur versienummer\n\nProgVrNr\n\nC50\n\nV\n\n1\n\nPERIODE\n\nPeriode\n\nSEQ\n\nV\n\n1\n\nDatumtijd begin periode\n\nDatTdBegPr\n\nDT\n\nV\n\n1\n\nDatumtijd einde periode\n\nDatTdEndPr\n\nDT\n\nV\n\n1\n\nAUTO\n\nAuto\n\nSEQ\n\nV\n\n1\n\nKenteken\n\nKntkn\n\nS6\n\nV\n\n1\n\nCERTIFICAAT BOORDCOMPUTER\n\nCertificaatBCT\n\nSEQ\n\nV\n\n1\n\nPublieke sleutel boordcomputer\n\nPubliekeSleutel; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nVERVOERDER\n\nVervoerder\n\nSEQ\n\nV\n\n1..*\n\nKvK-nummer\n\nKvKnr\n\nS12 *)\n\nV\n\n1\n\nP-nummer\n\nPnr\n\nS8 *)\n\nV\n\n1\n\nONDERNEMERSKAART\n\nOndernemerskaart\n\nSEQ\n\nV\n\n1..*\n\nOndernemerskaart volgnummer\n\nOkVgNr\n\nS5 *)\n\nV\n\n1\n\nRIT\n\nRit\n\nSEQ\n\nC\n\n0..*\n\nDATA\n\nData; Id=\u201didData\u201d\n\nSEQ\n\nV\n\n1\n\nRit volgnummer\n\nRtVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nMutatiecode\n\nMtCd\n\n{\u2018I\u2019, \u2018D\u2019, \u2018M\u2019}\n\nV\n\n1\n\nDatumtijd registratie\n\nDatTdReg\n\nDT\n\nV\n\n1\n\nType rit\n\nType\n\n{\u2018B\u2019, \u2018O\u2019}\n\nV\n\n1\n\nCo\u00f6rdinaat beginpunt rit\n\nLocBeg\n\nSEQ\n\nV\n\n1\n\nBreedtegraad\n\nLat\n\nD2.6(-90..+90)\n\nV\n\n1\n\nLengtegraad\n\nLon\n\nD3.6(-180..+180)\n\nV\n\n1\n\nDatumtijd begin rit\n\nDatTdBeg\n\nDT\n\nV\n\n1\n\nKm stand begin rit\n\nKmStdBeg\n\nI8(0..MAX)\n\nV\n\n1\n\nCo\u00f6rdinaat eindpunt rit\n\nLocEnd\n\nSEQ\n\nC\n\n0..1\n\nBreedtegraad\n\nLat\n\nD2.6(-90..+90)\n\nV\n\n1\n\nLengtegraad\n\nLon\n\nD3.6(-180..+180)\n\nV\n\n1\n\nDatumtijd einde rit\n\nDatTdEnd\n\nDT\n\nC\n\n0..1\n\nKm stand einde rit\n\nKmStdEnd\n\nI8(0..MAX)\n\nC\n\n0..1\n\nRitprijs\n\nPrijs\n\nI(0..\u221e)\n\nC\n\n0..1\n\nBESTUURDER\n\nBestuurder\n\nSEQ\n\nV\n\n1\n\nChauffeursidentificatienummer\n\nChIdNr\n\nS9 *)\n\nV\n\n1\n\nChauffeurskaart volgnummer\n\nCkVgNr\n\nS5 *)\n\nV\n\n1\n\nINTEGRITEIT\n\nIntegriteit\n\nSEQ\n\nC\n\n0..1\n\nElektronische handtekening boordcomputer\n\nElHdBc; codering=\u201dbase64\u201d\n\nB\n\nK\n\n1\n\nElektronische handtekening fout\n\nElHdFout\n\nS\n\nDatumtijd handtekening\n\nDatTdHd\n\nDT\n\nV\n\n1\n\nVoor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.\n\nToelichting:\n\na. De PERIODE is het tijdvak waarover de gebruiker de ritadministratie heeft opgevraagd.\n\nb. RIT wordt per BESTUURDER uniek ge\u00efdentificeerd door een volgnummer.\n\nc. Er zijn 2 mogelijke waarden voor \u2018Type rit\u2019: \u2018B\u2019 voor een beladen rit en \u2018O\u2019 voor\n                                                een onbeladen rit.\n\nd. De DATA van een RIT moet ondertekend worden met de elektronische handtekening van\n                                                de boordcomputer om de integriteit van de ritgegevens achteraf te kunnen bepalen.\n                                                Daartoe bevat INTEGRITEIT het attribuut \u2018Elektronische handtekening boordcomputer\u2019.\n                                                Indien bij het genereren van de handtekening een gebeurtenis met foutcode S005 of\n                                                F008 optreedt, wordt, in plaats van de handtekening, deze foutcode geregistreerd in\n                                                het attribuut \u2018Elektronische handtekening fout\u2019.\n\ne. De Ritprijs is in eurocenten.\n\nf. Een kilometerstand wordt opgenomen als een geheel getal, afgerond of afgekapt op een\n                                                hele kilometer.\n\ng. Voor een RIT wordt de bestuurder opgenomen in het bericht.\n\nh. Alleen als de chauffeurskaart niet beschikbaar is tijdens registratie van een RIT\n                                                moet \u2018Chauffeurskaart volgnummer\u2019 van de BESTUURDER volledig gevuld worden met nullen.\n\ni. De attributen \u2018Co\u00f6rdinaat eindpunt rit\u2019, \u2018Datumtijd einde rit\u2019, \u2018Km stand einde rit\u2019,\n                                                \u2018Ritprijs\u2019 en de entiteit INTEGRITEIT zijn verplicht tenzij de RIT nog niet is be\u00ebindigd.\n\nj. De mutatiecode van een RIT is \u2018I\u2019 als het volgnummer van de RIT voor de eerste keer\n                                                wordt geregistreerd. De I staat voor Insert.\n\nk. Annuleren van de laatste handmatig ingevoerde \u2018Aanvang rit\u2019 is mogelijk. Het te annuleren\n                                                record bevat alleen gegevens van het begin van de rit (\u2018Rit volgnummer\u2019, \u2018Mutatiecode\u2019,\n                                                \u2018Datumtijd registratie\u2019, \u2018Type rit\u2019, \u2018Co\u00f6rdinaat beginpunt rit\u2019, \u2018Datumtijd begin\n                                                rit\u2019 en \u2018Km stand begin rit\u2019). Annuleren moet op de volgende manier worden aangegeven:\n\n1. De gegevens van het te annuleren record worden ongewijzigd ondertekend met de elektronische\n                                                      handtekening van de boordcomputer.\n\n2. Een nieuwe record wordt geregistreerd met de volgende gegevens: het volgnummer is\n                                                      gelijk aan het volgnummer van het te annuleren record uit k.1, mutatiecode is \u2018D\u2019,\n                                                      \u2018Datumtijd registratie\u2019 is het tijdstip van registreren van dit nieuwe record, en\n                                                      de waarden van de overige attributen zijn gelijk aan de waarden van de overeenkomstige\n                                                      attributen van het te annuleren record. Ook dit record moet ondertekend worden met\n                                                      de elektronische handtekening van de boordcomputer.\n\nl. Annuleren van de laatste handmatig ingevoerde \u2018Einde rit\u2019 is mogelijk. Het te annuleren\n                                                record bevat zowel gegevens van het begin van de rit (\u2018Volgnummer\u2019, \u2018Mutatiecode\u2019,\n                                                \u2018Datumtijd registratie\u2019, \u2018Type rit\u2019, \u2018Co\u00f6rdinaat beginpunt rit\u2019, \u2018Datumtijd begin\n                                                rit\u2019 en \u2018Km stand begin rit\u2019) als einde van de rit (\u2018Co\u00f6rdinaat einde rit\u2019, \u2018Datumtijd\n                                                einde rit\u2019, \u2018Km stand einde rit\u2019, \u2018Ritprijs\u2019). Annuleren moet op de volgende manier\n                                                worden aangegeven:\n\n1. De gegevens van het te annuleren record worden ongewijzigd ondertekend met de elektronische\n                                                      handtekening van de boordcomputer als dit nog niet is gebeurd.\n\n2. Een nieuwe record wordt geregistreerd met de volgende gegevens: het volgnummer is\n                                                      gelijk aan het volgnummer van het te annuleren record uit l.1, mutatiecode is \u2018D\u2019,\n                                                      \u2018Datumtijd registratie\u2019 is het tijdstip van registreren van dit nieuwe record, en\n                                                      de waarden van de overige attributen zijn gelijk aan de waarden van de overeenkomstige\n                                                      attributen van het te annuleren record. Ook dit record moet ondertekend worden met\n                                                      de elektronische handtekening van de boordcomputer.\n\n3. Een volgend nieuw record wordt geregistreerd met de volgende gegevens: het volgnummer\n                                                      is gelijk aan het volgnummer van het te annuleren record uit l.1, mutatiecode is \u2018M\u2019,\n                                                      \u2018Datumtijd registratie\u2019 is het tijdstip van registreren van dit nieuwe record, de\n                                                      waarden van de attributen \u2018Type rit\u2019, \u2018Co\u00f6rdinaat begin rit\u2019, \u2018Datumtijd begin rit\u2019\n                                                      en \u2018Km stand begin rit\u2019 zijn gelijk aan de waarden van de overeenkomstige attributen\n                                                      van het te annuleren record, en de attributen \u2018Co\u00f6rdinaat einde rit\u2019, \u2018Datumtijd einde\n                                                      rit\u2019, \u2018Km stand einde rit\u2019 en \u2018Ritprijs\u2019 zijn initieel leeg om gevuld te worden bij\n                                                      het opnieuw uitvoeren van de handmatige actie \u2018Einde rit\u2019.\n\nm. het attribuut \u2018Publieke sleutel boordcomputer\u2019 dient te worden gevuld met het gehele\n                                                X509 certificaat van de boordcomputer.\n\nDe onderstaande Ritadministratie.xsd wordt gebruikt.\n\nVoor de definitie van bcttypes.xsd wordt verwezen naar artikel 9.\n\nDe geselecteerde ritten moeten gegroepeerd per vervoerder, en daarbinnen per ondernemerskaart,\n                                          in oplopende volgorde van volgnummer worden opgenomen in de ritadministratie.\n\nAlle ritten worden ondertekend worden met een elektronische handtekening op basis\n                                          van de private sleutel van de systeemkaart.\n\nDe ritadministratie bevat een element <Rit> en <Rit> bevat de elementen <Data> en\n                                          <Integriteit>. Het <Data> element bevat de volgende ritgegevens:\n\na. RtVgNr\n\nb. MtCd\n\nc. DatTdReg\n\nd. Type\n\ne. LocBeg.Lat en LocBeg.Lon\n\nf. DatTdBeg\n\ng. KmStdBeg\n\nh. LocEnd.Lat en LocEnd.Lon\n\ni. DatTdEnd\n\nj. KmStdEnd\n\nk. Prijs\n\nl. Bestuurder.ChIdNr\n\nm. Bestuurder.CkVgNr\n\nHet <Integriteit> element bevat de elektronische handtekening van het bijbehorende\n                                          Data element.\n\nBij het samenstellen van de ritadministratie moeten de gegevens van het <Data> element\n                                          onveranderd worden overgenomen uit de ritadministratie op de boordcomputer. Het berekenen\n                                          van de \u2018Elektronische handtekening boordcomputer\u2019 van het <Data> element van een <Rit>\n                                          wordt gedaan bij het be\u00ebindigen van de rit. De vastgelegde \u2018Elektronische handtekening\n                                          boordcomputer\u2019 wordt per <Rit> onveranderd overgenomen in het onderliggende <Integriteit>\n                                          element.\n\nDe naamgeving van de gegevenslevering \u2018Ritadministratie\u2019 is als volgt:\n\nHierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde.\n                                             De volgende formaten worden hierbij gebruikt:\n\nGegeven\n\nFormaat\n\nKenteken\n\nZoals opgenomen in de gegevenslevering zelf\n\nDatumtijdSamenstellenBericht\n\nCCYYMMDDHHMMSS\n\nDatumtijdBeginPeriode\n\nCCYYMMDDHHMM\n\nDatumtijdEindePeriode\n\nCCYYMMDDHHMM\n\nBij 100 ritten is het bericht \u2018ritadministratie\u2019 maximaal 100 Kbyte groot.\n\nVoor het bericht \u2018Arbeids-, rij- en rusttijden\u2019 worden de volgende gegevens en functionele\n                                          en technische berichtstructuur onderkend:\n\nEntiteit / attribuut\n\nXML element\n\nInhoud\n\nG\n\nC\n\nBERICHT\n\nArbeidstijden;\n\nId=\u201didGegevenslevering\u201d\n\nSEQ\n\nV\n\n1\n\nDatumtijd samenstellen bericht\n\nDatTdSmBr\n\nDT\n\nV\n\n1\n\nKORTE IDENTIFICATIE BOORDCOMPUTER\n\nKortIdBCT\n\nSEQ\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nProgrammatuur versienummer\n\nProgVrNr\n\nC50\n\nV\n\n1\n\nPERIODE\n\nPeriode\n\nSEQ\n\nV\n\n1\n\nDatumtijd begin periode\n\nDatTdBegPr\n\nDT\n\nV\n\n1\n\nDatumtijd einde periode\n\nDatTdEndPr\n\nDT\n\nV\n\n1\n\nAUTO\n\nAuto\n\nSEQ\n\nV\n\n1\n\nKenteken\n\nKntkn\n\nS6\n\nV\n\n1\n\nVERVOERDER\n\nVervoerder\n\nSEQ\n\nV\n\n1..*\n\nKvK-nummer\n\nKvKnr\n\nS12 *)\n\nV\n\n1\n\nP-nummer\n\nPnr\n\nS8 *)\n\nV\n\n1\n\nONDERNEMERSKAART\n\nOndernemerskaart\n\nSEQ\n\nC\n\n0..*\n\nOndernemerskaart volgnummer\n\nOkVgNr\n\nS5 *)\n\nV\n\n1\n\nBESTUURDER\n\nBestuurder\n\nSEQ\n\nC\n\n0..*\n\nChauffeursidentificatienummer\n\nChIdNr\n\nS9 *)\n\nV\n\n1\n\nChauffeurskaart volgnummer\n\nCkVgNr\n\nS5 *)\n\nV\n\n1\n\nCERTIFICAAT\n\nCertificaat\n\nCHOICE\n\nV\n\n1\n\nCERTIFICAAT CHAUFFEUR\n\nCertificaatChauffeur\n\nSEQ\n\nK\n\n1\n\nPublieke sleutel chauffeur\n\nPubliekeSleutel; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nCERTIFICAAT BOORDCOMPUTER\n\nCertificaatBCT\n\nSEQ\n\nK\n\n1\n\nPublieke sleutel boordcomputer\n\nPubliekeSleutel; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nARBEIDSTIJD\n\nArbeidstijd\n\nSEQ\n\nC\n\n0..*\n\nDATA\n\nData; Id=\u201didData\u201d\n\nSEQ\n\nV\n\n1\n\nArbeidstijd volgnummer\n\nArVgNr\n\nI(1..\u221e)\n\nV\n\nDatumtijd registratie\n\nDatTdReg\n\nDT\n\nV\n\nDatumtijd begin arbeidstijd\n\nDatTdBeg\n\nDT\n\nV\n\nDatumtijd einde arbeidstijd\n\nDatTdEnd\n\nDT\n\nV\n\nonbenoemde keuze uit een van de volgende 3 attributen\n\nCHOICE\n\nC\n\n0..*\n\nRIJTIJD\n\nRijtijd\n\nSEQ\n\nC\n\n0..1\n\nRijtijd volgnummer\n\nRtVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nDatumtijd registratie\n\nDatTdReg\n\nDT\n\nV\n\n1\n\nDatumtijd begin rijtijd\n\nDatTdBeg\n\nDT\n\nV\n\n1\n\nDatumtijd einde rijtijd\n\nDatTdEnd\n\nDT\n\nV\n\n1\n\nPAUZE\n\nPauze\n\nSEQ\n\nC\n\n0..1\n\nPauze volgnummer\n\nPzVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nMutatiecode\n\nMtCd\n\n{\u2018I\u2019, \u2018D\u2019}\n\nV\n\n1\n\nDatumtijd registratie\n\nDatTdReg\n\nDT\n\nV\n\n1\n\nDatumtijd begin pauze\n\nDatTdBeg\n\nDT\n\nV\n\n1\n\nDatumtijd einde pauze\n\nDatTdEnd\n\nDT\n\nV\n\n1\n\nANDERE WERKZAAMHEDEN\n\nAdrWrkzmhdn\n\nSEQ\n\nC\n\n0..1\n\nAndere werkzaamheden volgnummer\n\nAwVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nMutatiecode\n\nMtCd\n\n{\u2018I\u2019, \u2018D\u2019}\n\nV\n\n1\n\nDatumtijd registratie\n\nDatTdReg\n\nDT\n\nV\n\n1\n\nDatumtijd begin andere werkzaamhd.\n\nDatTdBeg\n\nDT\n\nV\n\n1\n\nDatumtijd einde andere werkzaamhd.\n\nDatTdEnd\n\nDT\n\nV\n\n1\n\nINTEGRITEIT\n\nIntegriteit\n\nSEQ\n\nV\n\n1\n\nElektronische handtekening chauffeur\n\nElHdCh; codering=\u201dbase64\u201d\n\nB\n\nK\n\n1\n\nElektronische handtekening boordcomputer\n\nElHdBc; codering=\u201dbase64\u201d\n\nB\n\nElektronische handtekening fout\n\nElHdFout\n\nS\n\nDatumtijd handtekening\n\nDatTdHd\n\nDT\n\nV\n\n1\n\nVoor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.\n\nToelichting:\n\na. De PERIODE is het tijdvak waarover de gebruiker de ritadministratie heeft opgevraagd.\n\nb. ARBEIDSTIJD wordt per BESTUURDER uniek ge\u00efdentificeerd door een volgnummer.\n\nc. RIJTIJD wordt per BESTUURDER uniek ge\u00efdentificeerd door een volgnummer.\n\nd. PAUZE wordt per BESTUURDER uniek ge\u00efdentificeerd door een volgnummer.\n\ne. ANDERE WERKZAAMHEDEN wordt per BESTUURDER uniek ge\u00efdentificeerd door een volgnummer.\n\nf. De DATA van ARBEIDSTIJD, inclusief bijbehorende voorkomens van RIJTIJD, PAUZE en ANDERE\n                                                WERKZAAMHEDEN, moet ondertekend worden met een elektronische handtekening om de integriteit\n                                                van de gegevens achteraf te kunnen bepalen. Indien de chauffeurskaart aanwezig is\n                                                wordt getekend met de elektronische handtekening van de chauffeur, indien de chauffeurskaart\n                                                niet aanwezig is wordt getekend met de elektronische handtekening van de boordcomputer.\n                                                Indien bij het genereren van de handtekening een gebeurtenis met foutcode S005, S006,\n                                                F008 of F009 optreedt, wordt, in plaats van de handtekening, deze foutcode geregistreerd\n                                                in het attribuut \u2018Elektronische handtekening fout\u2019.\n\ng. De mutatiecode van een PAUZE of ANDERE WERKZAAMHEDEN is \u2018I\u2019 als het volgnummer van\n                                                de PAUZE of ANDERE WERKZAAMHEDEN voor de eerste keer wordt geregistreerd. De I staat\n                                                voor Insert.\n\nh. Annuleren van de laatste handmatige actie is mogelijk. Voor PAUZE en ANDERE WERKZAAMHEDEN\n                                                moet dit op volgende manier worden aangegeven:\n\n1. De bestaande PAUZE of ANDERE WERKZAAMHEDEN wordt niet gewijzigd.\n\n2. Een nieuwe PAUZE of ANDERE WERKZAAMHEDEN wordt geregistreerd met het volgnummer van\n                                                      de PAUZE of ANDERE WERKZAAMHEDEN die geannuleerd moet worden.\n\n3. Datumtijd registratie van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN is het tijdstip\n                                                      van registratie van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN.\n\n4. Mutatiecode van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN is \u2018D\u2019 om aan te geven dat\n                                                      de PAUZE of ANDERE WERKZAAMHEDEN met dit specifieke volgnummer geannuleerd moet worden.\n\ni. Ook in de taxivervoermodus zonder chauffeurskaart moeten ARBEIDSTIJD, RIJTIJD, PAUZE\n                                                en ANDERE WERKZAAMHEDEN worden vastgelegd. Alle voorkomens van ARBEIDSTIJD, RIJTIJD,\n                                                PAUZE en ANDERE WERKZAAMHEDEN die zijn vastgelegd zonder chauffeurskaart worden per\n                                                VERVOERDER uitgeleverd voor een BESTUURDER met het handmatig ingegeven Chauffeursidentificatienummer\n                                                en het Chauffeurskaart volgnummer gevuld met nullen.\n\nj. Een bericht bevat per BESTUURDER de optionele attributen \u2018Publieke sleutel chauffeur\u2019\n                                                en \u2018Publieke sleutel boordcomputer\u2019 waarvan precies 1 attribuut verplicht gevuld moet\n                                                worden. Als de BESTUURDER bekend is moet het attribuut \u2018Publieke sleutel chauffeur\u2019\n                                                gevuld worden met het gehele X509 handtekeningcertificaat van de chauffeur, als de\n                                                bestuurder onbekend is moet het attribuut \u2018Publieke sleutel boordcomputer\u2019 gevuld\n                                                worden met het gehele X509 certificaat van de boordcomputer.\n\nk. Een bericht bevat per ARBEIDSTIJD de optionele attributen \u2018Elektronische handtekening\n                                                chauffeur\u2019 en \u2018Elektronische handtekening boordcomputer\u2019 waarvan precies 1 attribuut\n                                                verplicht gevuld moet worden. Als de bijbehorende BESTUURDER bekend is moet het attribuut\n                                                \u2018Elektronische handtekening chauffeur\u2019 gevuld worden, als de bestuurder onbekend is\n                                                moet het attribuut \u2018Elektronische handtekening boordcomputer\u2019 gevuld worden.\n\nDe onderstaande Arbeidstijden.xsd wordt gebruikt.\n\nDe geselecteerde arbeidstijden moeten gegroepeerd per vervoerder, en daarbinnen per\n                                          ondernemerskaart, en daarbinnen per bestuurder in oplopende volgorde van volgnummer\n                                          worden opgenomen. Binnen een arbeidstijd moeten de rijtijd, pauze en andere werkzaamheden\n                                          elk in oplopende volgorde van volgnummer worden opgenomen.\n\nAlle arbeidstijden worden ondertekend met een elektronische handtekening. Voor het\n                                          plaatsen van de elektronische handtekening wordt gebruik gemaakt van de private sleutel\n                                          van de chauffeurskaart indien deze aanwezig is, en van de private sleutel van de systeemkaart\n                                          indien de chauffeurskaart niet aanwezig is.\n\nDe \u2018Arbeids-, rij- en rusttijden\u2019 bevat een element <Arbeidstijd> en <Arbeidstijd>\n                                          bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende arbeidstijd\n                                          gegevens:\n\na. ArVgNr\n\nb. DatTdReg\n\nc. DatTdBeg\n\nd. DatTdEnd\n\ne. Rijtijd\n\nf. RtVgNr\n\ng. DatTdReg\n\nh. DatTdBeg\n\ni. DatTdEnd\n\nj. Pauze\n\nk. PzVgNr\n\nl. MtCd\n\nm. DatTdReg\n\nn. DatTdBeg\n\no. DatTdEnd\n\np. AdrWrkzmhdn\n\nq. AwVgNr\n\nr. MtCd\n\ns. DatTdReg\n\nt. DatTdBeg\n\nu. DatTdEnd\n\nHet <Integriteit> element bevat de elektronische handtekening chauffeur of elektronische\n                                          handtekening boordcomputer van het bijbehorende <Data> element.\n\nBij het samenstellen van bericht \u2018Arbeids-, rij- en rusttijden\u2019 moeten de gegevens\n                                          van het <Data> element onveranderd worden overgenomen uit de boordcomputer. Het berekenen\n                                          van de \u2018Elektronische handtekening chauffeur\u2019 of \u2018Elektronische handtekening boordcomputer\u2019\n                                          van het <Data> element moet gebeuren bij het be\u00ebindigen van een arbeidstijd. De vastgelegde\n                                          \u2018Elektronische handtekening chauffeur\u2019 of \u2018Elektronische handtekening boordcomputer\u2019\n                                          moeten per arbeidstijd onveranderd worden overgenomen in het onderliggende <Integriteit>\n                                          element.\n\nDe naamgeving van de gegevenslevering \u2018Arbeidstijd\u2019 is als volgt:\n\nHierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde.\n                                             De volgende formaten worden hierbij gebruikt:\n\nGegeven\n\nFormaat\n\nKenteken\n\nZoals opgenomen in de gegevenslevering zelf\n\nDatumtijdSamenstellenBericht\n\nCCYYMMDDHHMMSS\n\nDatumtijdBeginPeriode\n\nCCYYMMDDHHMM\n\nDatumtijdEindePeriode\n\nCCYYMMDDHHMM\n\nBij 100 arbeidstijden is het bericht \u2018arbeidstijd\u2019 maximaal 120 Kbyte groot.\n\nVoor het bericht \u2018Co\u00f6rdinaten\u2019 worden de volgende gegevens en functionele en technische\n                                          berichtstructuur onderkend:\n\nEntiteit / attribuut\n\nXML element\n\nInhoud\n\nG\n\nC\n\nBERICHT\n\nArbeidstijden;\n\nId=\u201didGegevenslevering\u201d\n\nSEQ\n\nV\n\n1\n\nDatumtijd samenstellen bericht\n\nDatTdSmBr\n\nDT\n\nV\n\n1\n\nKORTE IDENTIFICATIE BOORDCOMPUTER\n\nKortIdBCT\n\nSEQ\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nProgrammatuur versienummer\n\nProgVrNr\n\nC50\n\nV\n\n1\n\nPERIODE\n\nPeriode\n\nSEQ\n\nV\n\n1\n\nDatumtijd begin periode\n\nDatTdBegPr\n\nDT\n\nV\n\n1\n\nDatumtijd einde periode\n\nDatTdEndPr\n\nDT\n\nV\n\n1\n\nAUTO\n\nAuto\n\nSEQ\n\nV\n\n1..2\n\nKenteken\n\nKntkn\n\nS6\n\nV\n\n1\n\nVERVOERDER\n\nVervoerder\n\nSEQ\n\nV\n\n1..*\n\nKvK-nummer\n\nKvKnr\n\nS12 *)\n\nV\n\n1\n\nP-nummer\n\nPnr\n\nS8 *)\n\nV\n\n1\n\nONDERNEMERSKAART\n\nOndernemerskaart\n\nSEQ\n\nV\n\n1..*\n\nOndernemerskaart volgnummer\n\nOkVgNr\n\nS5 *)\n\nV\n\n1\n\nCOORDINAAT\n\nCOORD\n\nSEQ\n\nC\n\n0..*\n\nCo\u00f6rdinaat volgnummer\n\nVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nDatumtijd registratie\n\nDt\n\nDT\n\nV\n\n1\n\nBreedtegraad\n\nLat\n\nD2.6(-90..+90)\n\nV\n\n1\n\nLengtegraad\n\nLon\n\nD3.6(-180..+180)\n\nV\n\n1\n\nWerkingsmodus\n\nMd\n\n{\u2018O\u2019, \u2018C\u2019, \u2018B\u2019, \u2018K\u2019}\n\nV\n\n1\n\nWerkingsniveau\n\nNv\n\n{\u2018T\u2019, \u2018A\u2019, \u2018B\u2019}\n\nC\n\n0..1\n\nVoor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.\n\nToelichting:\n\na. De PERIODE is het tijdvak waarover de gebruiker de co\u00f6rdinaten heeft opgevraagd.\n\nb. COORDINAAT wordt per VERVOERDER uniek ge\u00efdentificeerd door een volgnummer.\n\nc. In werkingsmodus \u2018Operationele modus\u2019 is het attribuut \u2018Werkingsniveau\u2019 verplicht.\n\nd. Alle co\u00f6rdinaten met een datumtijd registratie die ligt voor het tijdstip van de laatste\n                                                activering van de boordcomputer worden gegroepeerd bij dezelfde AUTO \u2013 VERVOERDER\n                                                \u2013 ONDERNEMERSKAART combinatie waarbij \u2018Kenteken\u2019, \u2018KvK-nummer\u2019, \u2018P-nummer\u2019 en \u2018Ondernemerskaart\n                                                volgnummer\u2019 worden gevuld met de lege string (\u2018\u2019).\n\ne. Alle co\u00f6rdinaten die zijn geregistreerd na het tijdstip van de laatste activering\n                                                worden geleverd met het kenteken van de auto, het KvK-nummer en P-nummer van de vervoerder\n                                                en het volgnummer van de ondernemerskaart waarvoor de co\u00f6rdinaten zijn geregistreerd.\n\nf. Alleen de werkingsmodus \u2018Operationele Modus\u2019 kent meerdere werkingsniveaus. Bij de\n                                                overige modi wordt werkingsniveau \u2018Basis\u2019 aangehouden.\n\nDe onderstaande Coordinaten.xsd wordt gebruikt.\n\nDe geselecteerde co\u00f6rdinaten moeten gegroepeerd per kenteken, en daarbinnen per vervoerder,\n                                          en daarbinnen per ondernemerskaart, in oplopende volgorde van volgnummer, in het bericht\n                                          worden opgenomen.\n\nHet bericht \u2018Co\u00f6rdinaten\u2019 wordt ondertekend met een elektronische handtekening van\n                                          de boordcomputer. De afzonderlijke co\u00f6rdinaten worden niet ondertekend.\n\nDe naamgeving van de gegevenslevering \u2018Co\u00f6rdinaten\u2019 is als volgt:\n\nHierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde.\n                                             De volgende formaten worden hierbij gebruikt:\n\nGegeven\n\nFormaat\n\nKenteken\n\nHet kenteken van de auto waarin de boordcomputer als laatste is geactiveerd.\n\nDatumtijdSamenstellenBericht\n\nCCYYMMDDHHMMSS\n\nDatumtijdBeginPeriode\n\nCCYYMMDDHHMM\n\nDatumtijdEindePeriode\n\nCCYYMMDDHHMM\n\nEen bericht \u2018Co\u00f6rdinaten\u2019 bevat maximum 1.440 co\u00f6rdinaten per dag, wanneer de auto\n                                             continu rijdt en 1 co\u00f6rdinaat per minuut wordt vastgelegd. Voor de periode van een\n                                             dag geeft dat een bericht van maximaal 236 Kbyte. Per jaar is het bericht \u2018Co\u00f6rdinaten\u2019\n                                             maximaal 84 Mbyte groot.\n\nVoor het bericht \u2018Gebeurtenis\u2019 worden de volgende gegevens en functionele en technische\n                                          berichtstructuur onderkend:\n\nEntiteit / attribuut\n\nXML element\n\nInhoud\n\nG\n\nC\n\nBERICHT\n\nGebeurtenis;\n\nId=\u201didGegevenslevering\u201d\n\nSEQ\n\nV\n\n1\n\nDatumtijd samenstellen bericht\n\nDatTdSmBr\n\nDT\n\nV\n\n1\n\nKORTE IDENTIFICATIE BOORDCOMPUTER\n\nKortIdBCT\n\nSEQ\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nProgrammatuur versienummer\n\nProgVrNr\n\nC50\n\nV\n\n1\n\nPERIODE\n\nPeriode\n\nSEQ\n\nV\n\n1\n\nDatumtijd begin periode\n\nDatTdBegPr\n\nDT\n\nV\n\n1\n\nDatumtijd einde periode\n\nDatTdEndPr\n\nDT\n\nV\n\n1\n\nAUTO\n\nAuto\n\nSEQ\n\nV\n\n1\n\nKenteken\n\nKntkn\n\nS6\n\nV\n\n1\n\nCERTIFICAAT BOORDCOMPUTER\n\nCertificaatBCT\n\nSEQ\n\nK\n\n1\n\nPublieke sleutel boordcomputer\n\nPubliekeSleutel; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nVERVOERDER\n\nVervoerder\n\nSEQ\n\nV\n\n1..*\n\nKvK-nummer\n\nKvKnr\n\nS12 *)\n\nV\n\n1\n\nP-nummer\n\nPnr\n\nS8 *)\n\nV\n\n1\n\nONDERNEMERSKAART\n\nOndernemerskaart\n\nSEQ\n\nV\n\n1..*\n\nOndernemerskaart volgnummer\n\nOkVgNr\n\nS5 *)\n\nV\n\n1\n\nGEBEURTENIS\n\nGbrtns\n\nSEQ\n\nC\n\n0..*\n\nDATA\n\nData\n\nSEQ\n\nV\n\n1\n\nGebeurtenis volgnummer\n\nGbVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nCode\n\nCode\n\nS4\n\nV\n\n1\n\nDatumtijd registratie\n\nDatTdReg\n\nDT\n\nV\n\n1\n\nKm stand\n\nKmStd\n\nI8(0..MAX)\n\nV\n\n1\n\nStatus rijden auto\n\nStRdnAt\n\n{\u2018R\u2019, \u2018S\u2019}\n\nV\n\n1\n\nWerkingsmodus\n\nWrkngsMds\n\n{\u2018O\u2019, \u2018C\u2019, \u2018B\u2019, \u2018K\u2019}\n\nV\n\n1\n\nWerkingsniveau\n\nWrkngsNv\n\n{\u2018T\u2019, \u2018A\u2019, \u2018B\u2019}\n\nV\n\n1\n\nAanvullende relevante informatie\n\nAanvInfo\n\nS100\n\nO\n\n0..1\n\nBESTUURDER\n\nBestuurder\n\nSEQ\n\nC\n\n0..1\n\nChauffeursidentificatienummer\n\nChIdNr\n\nS9 *)\n\nV\n\n1\n\nChauffeurskaart volgnummer\n\nCkVgNr\n\nS5 *)\n\nV\n\n1\n\nINTEGRITEIT\n\nIntegriteit\n\nSEQ\n\nV\n\n1\n\nElektronische handtekening boordcomputer\n\nElHdBc; codering=\u201dbase64\u201d\n\nB\n\nK\n\n1\n\nElektronische handtekening fout\n\nElHdFout\n\nS\n\nDatumtijd handtekening\n\nDatTdHd\n\nDT\n\nV\n\n1\n\nVoor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.\n\nToelichting:\n\na. de PERIODE is het tijdvak waarover de gebruiker de gebeurtenissen heeft opgevraagd.\n\nb. GEBEURTENIS wordt per VERVOERDER uniek ge\u00efdentificeerd door een volgnummer.\n\nc. BESTUURDER is verplicht als tijdens het optreden van de gebeurtenis de werkingsmodus\n                                                \u2018Operationele Modus\u2019 actief is in het werkingsniveau \u2018Arbeidstijd\u2019 of \u2018Taxivervoer\u2019.\n\nd. Alleen de werkingsmodus \u2018Operationele Modus\u2019 kent meerdere werkingsniveaus. Bij de\n                                                overige modi wordt werkingsniveau \u2018Basis\u2019 aangehouden.\n\ne. De DATA van een GEBEURTENIS moet ondertekend worden met de elektronische handtekening\n                                                van de boordcomputer om de integriteit van de gegevens achteraf te kunnen bepalen.\n                                                Daartoe bevat INTEGRITEIT het attribuut \u2018Elektronische handtekening boordcomputer\u2019.\n                                                Indien bij het genereren van de handtekening een gebeurtenis met foutcode S005 of\n                                                F008 optreedt, wordt, in plaats van de handtekening, deze foutcode geregistreerd in\n                                                het attribuut \u2018Elektronische handtekening fout\u2019.\n\nf. Het attribuut \u2018Status rijden auto\u2019 wordt ingevuld op basis van gegevens van de verplaatsingsopnemer.\n\ng. Een kilometerstand wordt opgenomen als een geheel getal, afgerond of afgekapt op een\n                                                hele kilometer.\n\nh. Door het vullen van het attribuut \u2018Aanvullende relevante informatie\u2019 kan waar relevant\n                                                aanvullende informatie worden toegevoegd voor een bepaalde code.\n\ni. Indien er geen bestuurder actief is tijdens registratie van een gebeurtenis moet BESTUURDER\n                                                niet worden opgenomen in de registratie.\n\nj. Alleen als er een bestuurder actief, maar de chauffeurskaart niet beschikbaar is tijdens\n                                                registratie van een GEBEURTENIS moet \u2018Chauffeurskaart volgnummer\u2019 van de BESTUURDER\n                                                gevuld worden met nullen.\n\nk. Het attribuut \u2018Publieke sleutel boordcomputer\u2019 dient te worden gevuld met het gehele\n                                                X509 certificaat van de boordcomputer.\n\nDe onderstaande Gebeurtenis.xsd wordt gebruikt.\n\nDe geselecteerde gebeurtenissen moeten gegroepeerd per vervoerder, en daarbinnen per\n                                          ondernemerskaart, in oplopende volgorde van volgnummer, in het bericht worden opgenomen.\n\nAlle gebeurtenissen worden ondertekend op basis van de private sleutel van de boordcomputer.\n\nHet bericht Gebeurtenis bevat een element <Gebeurtenis> en het element <Gebeurtenis>\n                                          bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende gegevens:\n\na. GbVgNr\n\nb. Code\n\nc. DatTdReg\n\nd. KmStd\n\ne. StRdnAt\n\nf. WrkngsMds\n\ng. WrkngsNv\n\nh. AanvInfo\n\ni. Bestuurder.ChIdNr\n\nj. Bestuurder.CkVgNr\n\nHet <Integriteit> element bevat de elektronische handtekening boordcomputer van het\n                                          bijbehorende <Data> element.\n\nBij het samenstellen van het bericht \u2018Gebeurtenis\u2019 moeten de gegevens van het <Data>\n                                          element onveranderd worden overgenomen uit de administratie op de boordcomputer. Het\n                                          berekenen van de \u2018Elektronische handtekening boordcomputer\u2019 van het Data element van\n                                          een Rit moet gebeuren bij het optreden van de gebeurtenis. De vastgelegde \u2018Elektronische\n                                          handtekening boordcomputer\u2019 moet per gebeurtenis onveranderd worden overgenomen in\n                                          het onderliggende <Integriteit> element.\n\nIn de onderstaande tabel staat de in het bericht op te nemen code per gebeurtenis\n                                          vermeld.\n\nCode\n\nOmschrijving\n\nS001\n\neen storing in de werking van de registratiefuntie\n\nS002\n\neen storing in de werking van de beveiligingsfuncties\n\nS003\n\neen storing in de werking van de sensoren\n\nS004\n\neen storing in de overbrenging van gegevens naar een externe interface zoals beschreven\n                                                         in deze bijlage\n\nS005\n\neen storing in de werking van de systeemkaart\n\nS006\n\neen storing in de werking van de boordcomputerkaart\n\nS007 t/m S999\n\ngereserveerd voor overheidsdoeleinden\n\nF001\n\neen integriteitsfout in de uitvoercode\n\nF002\n\neen integriteistfout in de systeemgegevens\n\nF003\n\neen integriteitfout in de opgeslagen gebruikersgegevens\n\nF004\n\neen integriteitfout bij de gegevensuitvoer naar de chauffeurskaart\n\nF005\n\neen fout in de registratiefunctie\n\nF006\n\neen fout die de beveiliging van de boordcomputer in gevaar brengen\n\nF007\n\neen fout bij de gegevensuitvoer naar externe inrichtingen\n\nF008\n\neen fout bij het gebruik van de systeemkaart\n\nF009\n\neen fout bij het gebruik van de boordcomputerkaart\n\nF010\n\neen fout in de bewegingsensor\n\nF011\n\neen fout in de positiebepalingsensor\n\nF012\n\neen fout in de koppeling met de taxameter\n\nF013 t/m F999\n\ngereserveerd voor overheidsdoeleinden\n\nM001\n\nhet aanzetten van de boordcomputer\n\nM002\n\nhet uitzetten van de boordcomputer\n\nM003\n\nhet inbrengen van een boordcomputerkaart\n\nM004\n\nhet uitnemen van een boordcomputerkaart\n\nM005\n\nhet inbrengen van een ongeldige boordcomputerkaart\n\nM006\n\nhet inbrengen van een chauffeurskaart waarvan blijkt dat de datum en het tijdstip\n                                                         van de laatste registratie op de chauffeurskaart, op een later tijdstip valt dan de\n                                                         actuele datum en het tijdstip van de boordcomputer\n\nM007\n\nhet niet op een juiste wijze afsluiten van een kaartsessie\n\nM008\n\nhet inbrengen van een chauffeurskaart waarvan blijkt dat de laatste kaartsessie niet\n                                                         juist is afgesloten\n\nM009\n\nhet ontstaan van onvoldoende opslagcapaciteit op het geheugen van de boordcomputer\n\nM010\n\nhet verdwijnen van onvoldoende opslagcapaciteit op het geheugen van de boordcomputer\n\nM011\n\nhet ontstaan van onvoldoende opslagcapaciteit op de chauffeurskaart\n\nM012\n\nhet verdwijnen van onvoldoende opslagcapaciteit op de chauffeurskaart\n\nM013\n\nhet ontstaan van een onderbreking van ten minste 5 seconden in de stroomvoorziening\n                                                         van de boordcomputer\n\nM014\n\nhet verdwijnen van een onderbreking van ten minste 5 seconden in de stroomvoorziening\n                                                         van de boordcomputer\n\nM015\n\nhet begin van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld\n                                                         in de toestand rijden\n\nM016\n\nhet einde van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld\n                                                         in de toestand rijden\n\nM017\n\nhet optreden van een toestand verplaatsen zonder dat er sprake is van een toestand\n                                                         rijden\n\nM019\n\nhet begin van het niet kunnen verkrijgen van positiegegevens gedurende 5 minuten\n\nM020\n\nhet einde van het niet kunnen verkrijgen van positiegegevens gedurende 5 minuten\n\nM021\n\neen afwijking van meer dan twee procent tussen de, met behulp van bewegingsgegevens\n                                                         van de bewegingsopnemer en de constante van de boordcomputer, berekende afstand en\n                                                         de werkelijke afstand\n\nM022\n\neen afwijking van meer dan vijf procent tussen de berekende afstand op basis van gegevens\n                                                         van de bewegingsopnemer en positiebepalingsensor\n\nM023\n\nhet overbrengen van gegevens inclusief de naam van de externe interface\n\nM024\n\ngebeurtenissen die kunnen duiden op het in gevaar brengen van de beveiliging van de\n                                                         boordcomputer\n\nM025\n\nhet activeren van de boordcomputer\n\nM026\n\nhet keuren van de boordcomputer\n\nM027\n\nhet deactiveren van de boordcomputer\n\nM028\n\nhet inschakelen van een bedrijfsvergrendeling van de boordcomputer\n\nM029\n\ninschakelen van een werkingsmodus inclusief naam werkingsmodus\n\nM030\n\nhet uitschakelen van een werkingsmodus inclusief naam werkingsmodus\n\nM031\n\nhet begin van rijden in de operationele modus werkingsniveau taxivervoer zonder chauffeurskaart\n\nM032\n\nhet einde van rijden in de operationele modus werkingsniveau taxivervoer zonder chauffeurskaart\n\nM033\n\nhet detecteren van een niet-succesvolle authenticatiepoging\n\nM034\n\ninstalleren van een programmatuurrevisie\n\nM035\n\nstarten van audit- en beveiligingsfuncties\n\nM036\n\nstoppen van audit- en beveiligingsfuncties\n\nM037\n\nhet uitblijven of weigeren van een elektronische handtekening\n\nM038\n\nniet-geautoriseerde wijziging in de configuratie van de boordcomputer\n\nM039\n\ntoegang tot het gebeurtenissenlogboek\n\nM040 t/m M999\n\ngereserveerd voor overheidsdoeleinden\n\nEen fabrikant is vrij om voor eigen doeleinden codes aan de bovenstaande reeks toe\n                                          te voegen. Elke code moet bestaan uit een hoofdletter gevolgd door drie cijfers.\n\nDe naamgeving van de gegevenslevering \u2018Gebeurtenis\u2019 is als volgt:\n\nHierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde.\n                                             De volgende formaten worden hierbij gebruikt:\n\nGegeven\n\nFormaat\n\nKenteken\n\nZoals opgenomen in de gegevenslevering zelf\n\nDatumtijdSamenstellenBericht\n\nCCYYMMDDHHMMSS\n\nDatumtijdBeginPeriode\n\nCCYYMMDDHHMM\n\nDatumtijdEindePeriode\n\nCCYYMMDDHHMM\n\nBij 100 gebeurtenissen is het bericht \u2018Gebeurtenis\u2019 maximaal 100 Kbyte groot.\n\nVoor het bericht \u2018Onderzoek\u2019 worden de volgende gegevens en functionele en technische\n                                          berichtstructuur onderkend:\n\nEntiteit / attribuut\n\nXML element\n\nInhoud\n\nG\n\nC\n\nBERICHT\n\nOnderzoek;\n\nId=\u201didGegevenslevering\u201d\n\nSEQ\n\nV\n\n1\n\nDatumtijd samenstellen bericht\n\nDatTdSmBr\n\nDT\n\nV\n\n1\n\nKORTE IDENTIFICATIE BOORDCOMPUTER\n\nKortIdBCT\n\nSEQ\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nProgrammatuur versienummer\n\nProgVrNr\n\nC50\n\nV\n\n1\n\nPERIODE\n\nPeriode\n\nSEQ\n\nV\n\n1\n\nDatumtijd begin periode\n\nDatTdBegPr\n\nDT\n\nV\n\n1\n\nDatumtijd einde periode\n\nDatTdEndPr\n\nDT\n\nV\n\n1\n\nAUTO\n\nAuto\n\nSEQ\n\nV\n\n1\n\nKenteken\n\nKntkn\n\nS6\n\nV\n\n1\n\nCERTIFICAAT BOORDCOMPUTER\n\nCertificaatBCT\n\nSEQ\n\nK\n\n1\n\nPublieke sleutel boordcomputer\n\nPubliekeSleutel; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nIDENTIFICATIE BOORDCOMPUTER\n\nIdentificatieBCT\n\nSEQ\n\nV\n\n1\n\nNaam fabrikant\n\nNmFb\n\nS *)\n\nV\n\n1\n\nSerienummer\n\nSrNr\n\nC50 *)\n\nV\n\n1\n\nVersienummer\n\nVrNr\n\nC50\n\nV\n\n1\n\nBouwjaar\n\nBwJr\n\nI(1..\u221e)\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nPROGRAMMATUUR\n\nProgrammatuur\n\nSEQ\n\nV\n\n1..*\n\nVersienummer\n\nVrNr\n\nC50\n\nV\n\n1\n\nDatumtijd installatie\n\nDatTdIns\n\nDT\n\nV\n\n1\n\nACTIVERINGSONDERZOEK\n\nActiveringsOnderzoek\n\nSEQ\n\nV\n\n1\n\nDATA\n\nData\n\nSEQ\n\nV\n\n1\n\nVolgnummer\n\nVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nKm stand\n\nKmStd\n\nI8(1..MAX)\n\nV\n\n1\n\nDatumtijd onderzoek\n\nDatTdOndrzk\n\nDT\n\nV\n\n1\n\nConstante boordcomputer\n\nCnstBCT\n\nI(0..\u221e)\n\nV\n\n1\n\nEffectieve omtrek wielband\n\nEffOmtrkWlbd\n\nI(0..\u221e)\n\nV\n\n1\n\nBandenmaat\n\nBdMt\n\nS(min 1 karakter, maar geen spaties)\n\nV\n\n1\n\nKoppeling taxameter\n\nKpTxMtr\n\n{\u2018Aanwezig\u2019, \u2018Afwezig\u2019}\n\nV\n\n1\n\nResultaat\n\nRslt\n\n{\u2018Positief\u2019, \u2018Negatief\u2019}\n\nV\n\n1\n\nOpmerking\n\nOpm\n\nS100\n\nV\n\n1\n\nWERKPLAATS\n\nWerkplaats\n\nSEQ\n\nV\n\n1\n\nErkenningsnummer\n\nErkNr\n\nS20 *)\n\nV\n\n1\n\nKeuringskaart volgnummer\n\nKkVgNr\n\nS5 *)\n\nV\n\n1\n\nINTEGRITEIT\n\nIntegriteit\n\nSEQ\n\nV\n\n1\n\nElektronische handtekening boordcomputer\n\nElHdBc; codering=\u201dbase64\u201d\n\nB\n\nK\n\n1\n\nElektronische handtekening fout\n\nElHdFout\n\nS\n\nDatumtijd handtekening\n\nDatTdHd\n\nDT\n\nV\n\n1\n\nPERIODIEK ONDERZOEK\n\nPeriodiekOnderzoek\n\nSEQ\n\nC\n\n0..*\n\nDATA\n\nData\n\nSEQ\n\nV\n\n1\n\nVolgnummer\n\nVgNr\n\nI(1..\u221e)\n\nV\n\n1\n\nKm stand\n\nKmStd\n\nI8(1..MAX)\n\nV\n\n1\n\nDatumtijd onderzoek\n\nDatTdOndrzk\n\nDT\n\nV\n\n1\n\nConstante boordcomputer\n\nCnstBCT\n\nI(0..\u221e)\n\nV\n\n1\n\nEffectieve omtrek wielband\n\nEffOmtrkWlbd\n\nI(0..\u221e)\n\nV\n\n1\n\nBandenmaat\n\nBdMt\n\nS(min 1 karakter, maar geen spaties)\n\nV\n\n1\n\nKoppeling taxameter\n\nKpTxMtr\n\n{\u2018Aanwezig\u2019, \u2018Afwezig\u2019}\n\nV\n\n1\n\nResultaat\n\nRslt\n\n{\u2018Positief\u2019, \u2018Negatief\u2019}\n\nV\n\n1\n\nOpmerking\n\nOpm\n\nS100\n\nV\n\n1\n\nWERKPLAATS\n\nWerkplaats\n\nSEQ\n\nV\n\n1\n\nErkenningsnummer\n\nErkNr\n\nS20 *)\n\nV\n\n1\n\nKeuringskaart volgnummer\n\nKkVgNr\n\nS5 *)\n\nV\n\n1\n\nINTEGRITEIT\n\nIntegriteit\n\nSEQ\n\nV\n\n1\n\nElektronische handtekening boordcomputer\n\nElHdBc; codering=\u201dbase64\u201d\n\nB\n\nK\n\n1\n\nElektronische handtekening fout\n\nElHdFout\n\nS\n\nDatumtijd handtekening\n\nDatTdHd\n\nDT\n\nV\n\n1\n\nVoor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.\n\nToelichting:\n\na. De PERIODE is het tijdvak waarover de gebruiker de gebeurtenissen heeft opgevraagd.\n\nb. ACTIVERINGSONDERZOEK wordt uniek ge\u00efdentificeerd door een volgnummer.\n\nc. PERIODIEK ONDERZOEK wordt uniek ge\u00efdentificeerd door een volgnummer.\n\nd. Constante boordcomputer is in impulsen per kilometer.\n\ne. Effectieve omtrek wielband is in millimeters.\n\nf. Bandenmaat is in inches.\n\ng. De DATA van een ACTIVERINGSONDERZOEK c.q. een PERIODIEK ONDERZOEK moet ondertekend\n                                                worden met de elektronische handtekening van de boordcomputer om de integriteit van\n                                                de gegevens achteraf te kunnen bepalen. Daartoe bevat INTEGRITEIT het attribuut \u2018Elektronische\n                                                handtekening boordcomputer\u2019. Indien bij het genereren van de handtekening een gebeurtenis\n                                                met foutcode S005 of F008 optreedt, wordt, in plaats van de handtekening, deze foutcode\n                                                geregistreerd in het attribuut \u2018Elektronische handtekening fout\u2019.\n\nh. Een kilometerstand wordt opgenomen als een geheel getal, afgerond of afgekapt op een\n                                                hele kilometer.\n\ni. Het attribuut \u2018Publieke sleutel boordcomputer\u2019 dient te worden gevuld met het gehele\n                                                X509 certificaat van de boordcomputer.\n\nDe onderstaande Onderzoek.xsd dient te worden gebruikt.\n\nAls eerste wordt het geselecteerde activeringsonderzoek in het bericht opgenomen.\n                                          Daarna worden de geselecteerde periodieke onderzoeken in oplopende volgorde van volgnummer\n                                          in het bericht opgenomen.\n\nHet activeringsonderzoek en de periodieke onderzoeken worden ondertekend op basis\n                                          van de private sleutel van de boordcomputer.\n\nHet bericht \u2018Onderzoek\u2019 bevat het element <ActiveringsOnderzoek> en nul of meer <PeriodiekOnderzoek>\n                                          elementen. Elke instantie van een van beide elementen bevat de elementen <Data> en\n                                          <Integriteit>. Het <Data> element bevat elk van deze gevallen dezelfde gegevens:\n\na. VgNr\n\nb. KmStd\n\nc. DatTdOndrzk\n\nd. CnstBCT\n\ne. EffOmtrkWlbd\n\nf. BdMt\n\ng. KpTxMtr\n\nh. Rslt\n\ni. Opm\n\nj. Werkplaats.ErkNr\n\nk. Werkplaats.KkVgNr\n\nHet <Integriteit> element bevat de elektronische handtekening van het bijbehorende\n                                          <Data> element.\n\nBij het samenstellen van het bericht \u2018Onderzoek\u2019 moeten de gegevens van het <Data>\n                                          element onveranderd worden overgenomen uit de registratie op de boordcomputer. Het\n                                          berekenen van de elektronische handtekening van het <Data> element van een \u2018Onderzoek\u2019\n                                          wordt gedaan bij het afronden van een onderzoek. De vastgelegde elektronische handtekening\n                                          wordt per onderzoek overgenomen in het onderliggende <Integriteit> element.\n\nDe naamgeving van de gegevenslevering \u2018Onderzoek\u2019 is als volgt:\n\nHierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde.\n                                             De volgende formaten worden hierbij gebruikt:\n\nGegeven\n\nFormaat\n\nKenteken\n\nZoals opgenomen in de gegevenslevering zelf\n\nDatumtijdSamenstellenBericht\n\nCCYYMMDDHHMMSS\n\nDatumtijdBeginPeriode\n\nCCYYMMDDHHMM\n\nDatumtijdEindePeriode\n\nCCYYMMDDHHMM\n\nBij 10 onderzoeken is het bericht \u2018onderzoek\u2019 maximaal 10 Kbyte groot.\n\nVoor het bericht \u2018Chauffeurskaartdata\u2019 worden de volgende gegevens en functionele\n                                          en technische berichtstructuur onderkend:\n\nEntiteit / attribuut\n\nXML element\n\nInhoud\n\nG\n\nC\n\nBERICHT\n\nChauffeurskaartdata;\n\nId=\u201didGegevenslevering\u201d\n\nSEQ\n\nV\n\n1\n\nDatumtijd samenstellen bericht\n\nDatTdSmBr\n\nDT\n\nV\n\n1\n\nKORTE IDENTIFICATIE BOORDCOMPUTER\n\nKortIdBCT\n\nSEQ\n\nV\n\n1\n\nGoedkeuringsnummer\n\nGdKrgsNr\n\nS28 *)\n\nV\n\n1\n\nProgrammatuur versienummer\n\nProgVrNr\n\nC50\n\nV\n\n1\n\nPERIODE\n\nPeriode\n\nSEQ\n\nV\n\n1\n\nDatumtijd begin periode\n\nDatTdBegPr\n\nDT\n\nV\n\n1\n\nDatumtijd einde periode\n\nDatTdEndPr\n\nDT\n\nV\n\n1\n\nBESTUURDER\n\nBestuurder\n\nSEQ\n\nV\n\n1\n\nChauffeursidentificatienummer\n\nChIdNr\n\nS9 *)\n\nV\n\n1\n\nChauffeurskaart volgnummer\n\nCkVgNr\n\nS5 *)\n\nV\n\n1\n\nCERTIFICAAT\n\nCertificaat\n\nSEQ\n\nV\n\n1\n\nCERTIFICAAT CHAUFFEUR\n\nCertificaatChauffeur\n\nSEQ\n\nV\n\n1\n\nPublieke sleutel chauffeur\n\nPubliekeSleutel; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nCHAUFFEURSKAARTDATA\n\nChKrtData\n\nSEQ\n\nC\n\n0..1\n\nDATA\n\nData; Id=\u201didData\u201d\n\nSEQ\n\nV\n\n1\n\nChauffeursactiviteiten\n\nChauffeursActiviteiten; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nBoordcomputercertificaten\n\nBCTCertificaten; codering=\u201dbase64\u201d\n\nB *)\n\nV\n\n1\n\nINTEGRITEIT\n\nIntegriteit\n\nSEQ\n\nV\n\n1\n\nElektronische handtekening chauffeur\n\nElHdCh; codering=\u201dbase64\u201d\n\nB\n\nK\n\n1\n\nElektronische handtekening fout\n\nElHdFout\n\nS\n\nDatumtijd handtekening\n\nDatTdHd\n\nDT\n\nV\n\n1\n\nVoor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.\n\nToelichting:\n\na. De PERIODE bestrijkt het eerste tot en met het laatste record op de chauffeurskaart.\n                                                De \u2018Datumtijd begin periode\u2019 en \u2018Datumtijd einde periode\u2019 in de gegevenslevering worden\n                                                overgenomen uit \u2018Chauffeursactiviteiten\u2019 in de CHAUFFEURSKAARTDATA.\n\nb. \u2018Chauffeursactiviteiten\u2019 bevat de Base64 gecodeerde weergave van de binaire inhoud\n                                                van het bestand \u2018EF.Driver_Activity_Data\u2019, overgenomen van de chauffeurskaart.\n\nc. \u2018Boordcomputercertificaten\u2019 bevat de Base64 gecodeerde weergave van de binaire inhoud\n                                                van het bestand \u2018EF.BCT_Certificates\u2019, overgenomen van de chauffeurskaart.\n\nd. De DATA van CHAUFFEURSKAARTDATA moet ondertekend worden met de elektronische handtekening\n                                                van de chauffeur om de integriteit van de gegevens achteraf te kunnen bepalen. Daartoe\n                                                bevat INTEGRITEIT het attribuut \u2018Elektronische handtekening chauffeur\u2019. Indien bij\n                                                het genereren van de handtekening een gebeurtenis met foutcode S006 of F009 optreedt,\n                                                wordt, in plaats van de handtekening, deze foutcode geregistreerd in het attribuut\n                                                \u2018Elektronische handtekening fout\u2019.\n\ne. Het attribuut \u2018Publieke sleutel chauffeur\u2019 dient te worden gevuld met het gehele X509\n                                                handtekeningcertificaat van de chauffeur.\n\nDe onderstaande Chauffeurskaartdata.xsd wordt gebruikt.\n\nDe chauffeurskaartdata wordt overgenomen zoals deze wordt aangetroffen op de chauffeurskaart.\n\nChauffeurskaartdata wordt ondertekend met een elektronische handtekening. Voor het\n                                          plaatsen van de elektronische handtekening wordt gebruik gemaakt van de private sleutel\n                                          behorende bij het handtekeningcertificaat van de chauffeurskaart.\n\nHet bericht \u2018Chauffeurskaartdata\u2019 bevat een element <ChKrtData> en <ChKrtData> bevat\n                                          de elementen <Data> en <Integriteit>. Het <Data> element bevat de base64 representaties\n                                          van de binaire inhoud van de chip-bestanden \u2018EF.Driver_Activity_Data\u2019 en \u2018EF.BCT_Certificates\u2019,\n                                          zoals overgenomen uit de chauffeurskaart, in de volgende respectievelijke elementen:\n\na. ChauffeursActiviteiten\n\nb. BCTCertificaten\n\nHet <Integriteit> element bevat de elektronische handtekening chauffeur van het bijbehorende\n                                          <Data> element.\n\nBij het samenstellen van bericht \u2018Chauffeurskaartdata\u2019 moeten de gegevens van het\n                                          <Data> element zoals hierboven gespecificeerd worden overgenomen uit de chauffeurskaart.\n                                          Het berekenen van de \u2018Elektronische handtekening chauffeur\u2019 moet gebeuren zodra deze\n                                          data van de chauffeurskaart is overgenomen. De vastgelegde \u2018Elektronische handtekening\n                                          chauffeur\u2019 moet onveranderd worden overgenomen in het onderliggende <Integriteit>\n                                          element.\n\nDe naamgeving van de gegevenslevering \u2018Chauffeurskaartdata\u2019 is als volgt:\n\nHierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde.\n                                             De volgende formaten worden hierbij gebruikt:\n\nGegeven\n\nFormaat\n\nChauffeursidentificatienummer\n\nZoals opgenomen in de gegevenslevering zelf\n\nChauffeurskaartvolgnummer\n\nZoals opgenomen in de gegevenslevering zelf\n\nDatumtijdSamenstellenBericht\n\nCCYYMMDDHHMMSS\n\nDatumtijdBeginPeriode\n\nCCYYMMDDHHMM\n\nDatumtijdEindePeriode\n\nCCYYMMDDHHMM\n\nHet bericht \u2018Chauffeurskaartdata\u2019 is maximaal 200 Kbyte groot.\n\nDe toelichting bij elk van de functioneel/technische specificaties van een gegevenslevering\n                                          uit artikelen 3 t/m 8 bestaat uit de navolgende legenda:\n\nKolomkop / waarde\n\nBetekenis\n\nEntiteit / attribuut:\n\nFunctionele beschrijving van het gegeven. De visuele groepering van entiteiten en\n                                                         attributen representeert de hi\u00ebrarchische structuur van het bericht.\n\nXML element:\n\nDe technische berichtstructuur is XML. In deze kolom wordt de naam van het XML element\n                                                         waarin het betreffende gegeven wordt opgeslagen vermeld. Indien het betreffende element\n                                                         een XML attribuut kent, dan is diens naam en waarde bij de elementnaam opgenomen (bijv.\n                                                         codering=\u201dbase64\u201d).\n\nInhoud:\n\nDatatype, lengte en vorm van de inhoud van het XML element:\n\n*)\n\nWaarde zoals overgenomen uit de betreffende boordcomputerkaart.\n\n{lijst}\n\nE\u00e9n van de waarden in de lijst.\n\nB\n\nBinaire data gecodeerd als Base64.\n\nC#\n\nEen reeks van maximaal # karakters beginnend en eindigend met een letter of cijfer\n                                                         met daartussenin optioneel een of meer letters, cijfers, punten (\u2018.\u2019) en/of liggende\n                                                         streepjes (\u2018-\u2019).\n\nCHOICE\n\nWordt gebruikt wanneer de inhoud van een entiteit naar keuze of conditie \u00e9\u00e9n van twee\n                                                         of meer onderliggende entiteiten/attributen moet bevatten. Gebruik wordt nader toegelicht.\n\nD#.#\n\nEen re\u00ebel getal met de vermelde precisie (de # links van de punt representeert het\n                                                         maximale aantal cijfers van het gehele deel en de # rechts van de punt representeert\n                                                         het maximale aantal decimalen).\n\nD#.#(bereik)\n\nEen re\u00ebel getal met de vermelde precisie (zie D#.#) en binnen het vermelde bereik\n                                                         inclusief de vermelde eindwaarden.\n\nDT\n\nTijdstip gecodeerd als een datum en een tijd in UTC.\n\nI\n\nEen geheel getal in het bereik -oneindig tot +oneindig.\n\nI#\n\nEen geheel getal van maximaal # cijfers.\n\nI#(bereik)\n\nEen geheel getal van maximaal # cijfers binnen het vermelde bereik inclusief de vermelde\n                                                         eindwaarden. Het symbool MAX staat hierbij voor het getal bestaande uit even zo veel\n                                                         9\u2019s als # aangeeft.\n\nI(bereik)\n\nEen geheel getal binnen het vermelde bereik inclusief de vermelde eindwaarden. Het\n                                                         symbool \u2018\u221e\u2019 staat hierbij voor oneindig.\n\nS\n\nEen onbepaald lange reeks van willekeurige karakters.\n\nS#\n\nEen reeks van maximaal # willekeurige karakters.\n\nSEQ\n\nEen geordende groep van onderliggende elementen.\n\nG:\n\nGebruik van het gegeven:\n\nC\n\nConditioneel. Gebruik wordt nader toegelicht.\n\nK\n\nKeuze. Wordt gebruikt wanneer er naar keuze of conditie \u00e9\u00e9n van twee of meer elementen\n                                                         moet worden gebruikt. Gebruik wordt nader toegelicht.\n\nO\n\nOptioneel. Gebruik naar keuze.\n\nV\n\nVerplicht.\n\nC:\n\nCardinaliteit: specificeert hoe veel keer het element wordt herhaald. Hierbij staat\n                                                         \u221e voor een onbeperkt aantal keren.\n\nDe berichtstructuren uit artikelen 3 t/m 8 maken allen gebruik van een algemene XSD:\n                                          bcttypes.xsd. Dit is een XML schema definitie zonder default namespace en zonder targetNamespace.\n                                          Daardoor neemt het de default namespace en targetNamespace van elke XML schema definitie\n                                          die bcttypes.xsd \u2019include\u2019 aan. Dit effect heet: \u2018chameleon include\u2019.\n\nDe inhoud van bcttypes.xsd is als volgt:\n\nIn deze bijlage wordt verstaan onder:\n\na.\n\nd (achtervoegsel)\n\nGeeft aan dat een getal in decimale notatie is.\n\nb.\n\nETX\n\nTeken dat het einde van een bericht aangeeft (03h).\n\nc.\n\nh (achtervoegsel)\n\nGeeft aan dat een getal in hexadecimale notatie is.\n\nd.\n\nSTX\n\nTeken dat het begin van een bericht aangeeft (02h).\n\nEen overzicht van de complete interface is te zien in Figuur 1 hieronder.\n\nHierin zijn twee niveaus te onderscheiden:\n\n1. Fysieke interface (FI)\n\nDe fysieke interface bestaat uit een RS-232 verbinding.\n\n2. Logische interface (LI)\n\nDeze interface is een directe communicatie-interface.\n\nEIS-AL-1\n\nDe indeling van de interfaces volgens het OSI model is als in Tabel 1:\n\nOSI laag\n\nInvulling\n\nLaag 1: Fysiek\n\nRS-232 verbinding\n\nLaag 2: Data\n\nSerieel, 8N1, 9600 baud\n\nLaag 3: Netwerk\n\nNiet aanwezig\n\nLaag 4: Transport\n\nSTX, lengte, berichtdata, CRC, ETX, byte stuffing\n\nLaag 5: Sessie\n\nNiet aanwezig\n\nLaag 6: Presentatie\n\nNiet aanwezig\n\nLaag 7: Applicatie\n\nberichtdata = [berichttype, data]\n\nEIS-FI-1\n\nDe interface is gebaseerd op een RS-232 interface.\n\nEIS-FI-2\n\nDe interface is bestand tegen kortsluiting\n\nEIS-FI-3\n\nDe interface voldoet aan richtlijn 2004/104/EC voor elektromagnetische compatibiliteit.\n\nEIS-FI-4\n\nDe interface voldoet aan de eisen die zijn neergelegd in NEN-ISO 10605 met betrekking\n                                                      tot elektrostatische ontlading.\n\nEIS-FI-5\n\nDe interface voldoet aan mechanische omgevingsklasse M3 zoals beschreven in Europese\n                                                      Richtlijn 2004/22/EG.\n\nEIS-FI-6\n\nDe fysieke interface voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-1\n                                                      en NEN-EN-IEC 60068-2-2 en functioneert naar behoren binnen een temperatuursbereik\n                                                      van -20\u00b0 C tot 70\u00b0 C.\n\nEIS-FI-7\n\nDe fysieke interface voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-30\n                                                      en functioneert naar behoren bij een relatieve luchtvochtigheid van minimaal 10% en\n                                                      maximaal 90%.\n\nEIS-FI-8\n\nDe boordcomputer is voorzien van een door de fabrikant te kiezen connector, waarmee\n                                                      de aansluitwijze van de bekabeling zoals gespecificeerd in Tabel 2 kan worden ondersteund.\n                                                      De connector dient in de markt vrij verkrijgbaar te zijn. Zowel de connector als de\n                                                      kabel voldoet ook aan 0.\n\nEIS-FI-9\n\nVoor aansluiting van de Taxameter op de boordcomputer wordt gebruik gemaakt van bekabeling\n                                                      waarmee de elektrische signalen van de fysieke interface worden aangesloten zoals\n                                                      gespecificeerd in Tabel 2, waarbij de standaard pinbezetting van de gekozen connector\n                                                      moet worden gebruikt.\n\nFunctie aan zijde boordcomputer\n\nFunctie aan zijde taxameter\n\nOpmerking\n\nTx+\n\nRx+\n\nData van boordcomputer naar Taxameter.\n\nTx-\n\nRx-\n\nRx+\n\nTx+\n\nData van Taxameter naar boordcomputer\n\nRx-\n\nTx-\n\nSignal Ground\n\nSignal Ground\n\nEIS-FI-10\n\nVoor het aansluiten van TX+/TX- op RX+/RX- (data van boordcomputer naar Taxameter\n                                                      en omgekeerd) wordt in de bekabeling gebruik gemaakt van Twisted Pair verbindingen.\n\nEIS-FI-11\n\nVoor apparaten met zowel de functie boordcomputer als taxameter is het toegestaan\n                                                      intern een afwijkende interface toe te passen, indien de in dit document gespecificeerde\n                                                      interface ook op het apparaat ge\u00efmplementeerd is.\n\nEIS-LI-1\n\nAlle berichten over de logische interface zijn in binair formaat. De byte order is\n                                                         zoals in Tabel 3 hieronder aangegeven, waar het getal 32597d (=7F55h) met datatype\n                                                         integer wordt verstuurd. Hierbij geeft de volgorde aan welke byte als eerste wordt\n                                                         verstuurd.\n\nVolgorde\n\nWaarde van het voorbeeld\n\n1e byte\n\n7Fh\n\n2e byte\n\n55h\n\nEIS-LI-2\n\nDe berichtenstroom bestaat uit een vraag- en antwoordproces. Van de zijde van de boordcomputer\n                                                         worden uitsluitend vraagberichten, dus berichttypen 4 t/m 49 gestuurd. Van de zijde\n                                                         van de taxameter worden uitsluitend berichttypen > 50 gestuurd, dus alleen antwoordberichten\n                                                         of foutberichten.\n\nEIS-LI-3\n\nIndien er een fout optreedt in het vraag- en antwoordproces wordt in plaats van een\n                                                         antwoordbericht een foutmeldingsbericht gestuurd, waarbij het berichttype de desbetreffende\n                                                         foutmelding beschrijft. Indien dit niet toereikend is kan bericht F_NIET_STANDAARD\n                                                         gebruikt worden. Indien er meerdere foutmeldingen tegelijkertijd optreden dient de\n                                                         meest ernstige fout te worden gekozen. Een bericht bevat altijd \u00e9\u00e9n vraag of \u00e9\u00e9n antwoord\n                                                         (of foutmelding).\n\nEIS-LI-4\n\nAlle berichten over deze interface zullen beginnen met startteken 02h (hierna aangeduid\n                                                         met STX) en eindigen met stopteken 03h (hierna aangeduid met ETX). In de rest van\n                                                         het bericht komt teken 02h en 03h niet voor. Om deze tekens toch in data mogelijk\n                                                         te maken is escape teken 1Bh beschikbaar. De escape waarden van de gereserveerde tekens\n                                                         zijn:\n\nTeken\n\nEscape waarde\n\n02h\n\n1B12h\n\n03h\n\n1B13h\n\n1Bh\n\n1B1Bh\n\nEIS-LI-5\n\nEen veld is \u00e9\u00e9n van de volgende datatypen:\n\nDatatype\n\nBereik\n\nToelichting\n\nByte\n\n[0..255]\n\nDatum en tijd\n\n[1 jan 2000 0:00:00 31\u00a0dec 2225 23:59:59]\n\nYY\n\nAantal jaar vanaf het jaar 2000, byte. Eerste byte in dit veld\n\nMM\n\nMaand, [1..12], byte, na YY\n\nDD\n\nDag, [1..31], byte, na MM\n\nHH\n\nUur, [0..23], byte, na DD\n\nMM\n\nMinuut, [0..59], byte, na HH\n\nSS\n\nSeconden, [0..59], byte. Laatste byte in dit veld\n\nInteger\n\n[\u201332768 , 32767]\n\n2 bytes, hoogste byte eerst.\n\nLong\n\n[\u20132147483648, 2147483647]\n\n4 bytes, hoogste byte eerst, gevolgd door de \u00e9\u00e9n na hoogste byte etc.\n\nSingle\n\nVolgens IEEE 754-1985\n\n4 bytes, hoogste byte eerst, gevolgd door de \u00e9\u00e9n na hoogste byte etc.\n\nString\n\nLengte [0..255], gevolgd door karakters met bereik [32..126]\n\nTekenreeks van maximaal 256 karakters. Eerst dient de lengte opgegeven te worden,\n                                                         gevolgd door de karakters. Er is geen 0h eindteken. De karakters zijn 8-bits ASCII,\n                                                         met de restrictie tot karakters 32 t/m 126.\n\nEIS-LI-6\n\nEen bericht heeft het volgende formaat:\n\nByte\n\nNaam\n\nWaarde\n\nToelichting\n\n1\n\nStart of text (STX)\n\n02h\n\nIdentificatie van de start van een bericht\n\n2,3\n\nLengte bericht\n\n0..65535\n\nAantal bytes van de berichtdata van het bericht, plus het berichttype en de CRC. Hoogste\n                                                         byte eerst.\n\n4\n\nberichttype\n\n4..255\n\n5+n\n\nData\n\n0..255\n\nData is optioneel voor enkele typen berichten.\n\n(5,6)+n\n\nCRC\n\n0..65535\n\nCRC16 van de data en het berichttype. Hoogste byte eerst.\n\n7+n\n\nEnd of text (ETX)\n\n03h\n\nIdentificatie einde bericht\n\nEIS-LI-7\n\nDe berichtlengte is gelijk aan het aantal bytes tussen STX en ETX, waarbij het bericht\n                                                         zonder byte stuffing wordt beoordeeld. Indien een bericht ontvangen is dient eerst\n                                                         byte stuffing verwijderd te worden alvorens de berichtlengte te berekenen.\n\nEIS-LI-8\n\nDe gebruikte CRC methode is 16 bits CRC-CCITT, met als polynoom x16 + x12 + x5 + 1. De CRC wordt berekend over byte 4 tot byte 5+n, dus over het berichttype en\n                                                         de data. De CRC is berekend voordat byte stuffing toegepast, vergelijkbaar met 0.\n\nEIS-LI-9\n\nEen berichttype wordt gekenmerkt door een getal van 4 t/m 255. Een overzicht van berichttypes\n                                                         is hieronder gegeven (decimaal).\n\nBerichttype (decimaal)\n\nNaam\n\nToelichting\n\nVraagberichten\n\n4\n\nVR_STATUS\n\nDatum en tijd, Functiestand, Tarief identificatie\n\n5\n\nVR_TARIEFINFO\n\nDatum en tijd, Tarief informatie\n\n6\n\nVR_RITBEDRAG\n\nDatum en tijd, Functiestand, Ritbedrag\n\n7\n\nVR_TOTALEN\n\nDatum en tijd, Totalisatordata\n\n8\n\nVR_TAXAMETER_INFO\n\nDatum en tijd, Constante afstandssignaalgenerator, Beveiligingsdatum, Identificatie\n                                                         taxi\n\nAntwoordenberichten\n\n54\n\nA_STATUS\n\nDatum en tijd, Functiestand, Tarief identificatie\n\n55\n\nA_TARIEFINFO\n\nDatum en tijd, Tarief informatie\n\n56\n\nA_RITBEDRAG\n\nDatum en tijd, Functiestand, Ritbedrag\n\n57\n\nA_TOTALEN\n\nDatum en tijd, Totalisatordata\n\n58\n\nA_TAXAMETER_INFO\n\nDatum en tijd, Constante afstandssignaalgenerator, Beveiligingsdatum, Identificatie\n                                                         taxi\n\nFoutberichten\n\n100\n\nF_BERICHT_ONBEKEND\n\nFout: berichtnummer onbekend\n\n101\n\nF_CRC_INCORRECT\n\nFout: CRC niet correct\n\n102\n\nF_LENGTE_INCORRECT\n\nFout: berichtlengte niet correct. Wordt gestuurd indien:\n\n\u2022 het veld lengte ontbreekt in een bericht\n\n\u2022 de waarde van het veld lengte niet correct is\n\n\u2022 de minimale berichtlengte onjuist is\n\n\u2022 het bericht uit meer bytes bestaat dan is toegestaan\n\n103\n\nF_GEEN_STX\n\nFout: Begin van bericht niet gedetecteerd (2x ETX gedetecteerd zonder STX)\n\n104\n\nF_GEEN_ETX\n\nFout: Einde van bericht niet gedetecteerd (2x STX gedetecteerd zonder ETX)\n\n105\n\nF_NIET_STANDAARD\n\nFout: Niet gedefinieerde fout, bevat aanvullende informatie\n\n106\n\nF_VELD_ONGELDIG\n\nFout: Een opgegeven veld is ongeldig.\n\nHet bericht VR_STATUS wordt gebruikt om de status van de taxameter op te vragen. Voor\n                                             de situatie waarin de taxameter ingesteld is om niet te functioneren indien de interface\n                                             niet functioneert is er een extra veld beschikbaar. Dit veld is om aan de taxameter\n                                             duidelijk te maken of de interface softwarematig inactief dan wel operationeel is.\n                                             Zo kan er gecontroleerd worden of de fysieke interface in beide richtingen correct\n                                             functioneert zonder dat de taxameter deze controle hoeft te interpreteren als goed\n                                             werkende verbinding.\n\nEIS-LI-10\n\nDe data in het bericht VR_STATUS heeft het volgende formaat:\n\nStatus interface\n\nByte\n\n[10h = interface inactief, 11h = interface operationeel]\n\nTotale berichtgrootte: 8 bytes\n\nEIS-LI-11\n\nHet veld \u2018status interface\u2019 mag alleen de status \u2018operationeel\u2019 bevatten indien:\n\n\u2022 Dit door de boordcomputer gewenst is\n\n\u00e9n\n\n\u2022 Er gedurende de laatste 15 seconden ten minste \u00e9\u00e9n geldig antwoordbericht van de\n                                                            taxameter is ontvangen.\n\nEIS-LI-12\n\nEr zal vanuit de richting van de boordcomputer minimaal eens per 5 seconden een VR_STATUS\n                                                            bericht gestuurd worden over de interface.\n\nToelichting: dit is ten behoeve van de functionaliteit van het automatisch uitschakelen\n                                             van de taxameter. De taxameter dient uit te vallen indien er 15 seconden geen statusbericht\n                                             is ontvangen met \u2018Status interface\u2019 = \u2018interface operationeel\u2019.\n\nHet antwoord op het bericht VR_STATUS. Hierin geeft de taxameter de functiestand aan\n                                             en de identificatie van het huidige tarief. Dit TARIEF_ID dient overeen te komen met\n                                             de tariefgroepen die met bericht VR_TARIEFINFO kunnen worden opgevraagd. De informatie\n                                             in dit bericht kan door de boordcomputer gebruikt worden om een overgang van de functiestand\n                                             te detecteren.\n\nEIS-LI-13\n\nDe data in het bericht A_STATUS heeft het volgende formaat:\n\nDATUM_EN_TIJD\n\nDatum\n\nHuidige datum en tijd in de taxameter\n\nFUNCTIESTAND\n\nByte\n\n[10h = \u2018vrij\u2019, 11h = \u2018tarief\u2019, 12h = \u2018te betalen\u2019]\n\nTARIEF_ID\n\nByte [0..255]\n\nIdentificatie van het huidige tarief\n\nTotale berichtgrootte: 15 bytes\n\nDit bericht is voor het opvragen van tariefinformatie. Totale berichtgrootte: 7 bytes\n\nEIS-LI-14\n\nHet bericht VR_TARIEFINFO bevat geen \u2018data\u2019.\n\nHet bericht A_TARIEFINFO is het antwoord op het bericht VR_TARIEFINFO. Hierin is per\n                                             tarief een identificatienummer, een omschrijving, een tarief per eenheid en een omschrijving\n                                             van de eenheid aangegeven. Deze gegevens worden per tarief verstrekt.\n\nOok BTW kan gezien worden als een tarief.\n\nEIS-LI-15\n\nDe data in het bericht A_TARIEFINFO heeft het volgende formaat:\n\nDATUM_EN_TIJD\n\nDatum\n\nHuidige datum en tijd in de taxameter\n\nTARIEF_AANTAL\n\nByte [0..255]\n\nAantal tarieven\n\nHerhalen per tarief, dus TARIEF_AANTAL keer\n\ntariefX\n\nId\n\nByte\n\nIdentificatie tariefX\n\ntariefX\n\nomschrijving\n\nString\n\nOmschrijving van tariefX, bijvoorbeeld 'kilometerprijs' of 'BTW laag tarief'\n\ntariefX\n\ntarief per eenheid\n\nSingle\n\nTarief per eenheid\n\ntariefX\n\nomschrijving eenheid\n\nString\n\nOmschrijving eenheid van tariefX, bijvoorbeeld \u2018km\u2019 of \u2018Eurocent'\n\ntariefX\n\nPercentage\n\nByte\n\n0 = nee, 1 = ja, zie toelichting\n\nEinde herhalen per tarief\n\nTotale berichtgrootte: variabel, 14 bytes + (5 + tekstlengte) * TARIEF_AANTAL\n\nIndien het tarief een percentage betreft dient bij de berekening het tarief per eenheid\n                                             door 100 gedeeld te worden.\n\nDit bericht is bedoeld om het ritbedrag op te vragen, bijvoorbeeld nadat er een functiestand\n                                             overgang van de taxameter is gedetecteerd. Totale berichtgrootte: 7 bytes\n\nEIS-LI-16\n\nHet bericht VR_RITBEDRAG bevat geen \u2018data\u2019.\n\nHet bericht A_RITBEDRAG is het antwoord op het bericht VR_RITBEDRAG. Hierin staat\n                                             de functiestand en het ritbedrag vermeld. De functiestand is hier nogmaals opgenomen\n                                             zodat er zekerheid is dat op het moment van opvragen de functiestand en het ritbedrag\n                                             op het zelfde moment zijn uitgelezen.\n\nEIS-LI-17\n\nDe data in het bericht A_RITBEDRAG heeft het volgende formaat:\n\nDATUM_EN_TIJD\n\nDatum\n\nHuidige datum en tijd in de taxameter\n\nFUNCTIESTAND\n\nByte\n\n[10h = \u2018vrij\u2019, 11h = \u2018tarief\u2019, 12h = \u2018te betalen\u2019]\n\nTOTAALBEDRAG\n\nSingle\n\nTotaal ritbedrag in Eurocenten inclusief toeslagen\n\nRITBEDRAG\n\nSingle\n\nRitbedrag in Eurocenten\n\nRIT_VERTREKTIJD\n\nDatum\n\nDatum en tijd van het vertrek van de rit\n\nRIT_AANKOMSTTIJD\n\nDatum\n\nDatum en tijd van de aankomst van de rit\n\nAFSTAND_RIT\n\nLong\n\nTotale door de taxi afgelegde afstand in honderden meters voor de betreffende rit\n\nTARIEF_AANTAL\n\nByte\n\nAantal toegepaste tarieven in ritbedrag\n\nHerhalen per tarief, dus TARIEF_AANTAL keer\n\nTARIEF_ID\n\nbyte\n\nIdentificatie tariefX, overeenkomstig de tarieven in A_TARIEFINFO\n\nTARIEF_EENH\n\nSingle\n\nAantal eenheden tariefX\n\nEinde herhalen per tarief\n\nTOESLAG_AANTAL\n\nbyte\n\nAantal toegepaste toeslagen in ritbedrag\n\nHerhalen per toeslag, dus TOESLAG_AANTAL keer\n\nTOESLAG_OMSCHR\n\nString\n\nOmschrijving toeslag\n\nTOESLAG_BEDR\n\nSingle\n\nToeslag bedrag in Eurocenten\n\nEinde herhalen per toeslag\n\nTotale berichtgrootte: variabel, minimaal 29 bytes, maximaal 65535 bytes\n\nEen korting wordt als negatief TOESLAG_BEDR weergegeven.\n\nDit bericht is voor het opvragen van de totalisatordata. Totale berichtgrootte: 7\n                                             bytes\n\nEIS-LI-18\n\nHet bericht VR_TOTALEN bevat geen \u2018data\u2019.\n\nHet bericht A_TOTALEN is het antwoord op het bericht VR_TOTALEN. Het bericht bevat\n                                             de totalisatordata.\n\nEIS-LI-19\n\nDe data in het bericht A_TOTALEN heeft het volgende formaat:\n\nDATUM_EN_TIJD\n\nDatum\n\nHuidige datum en tijd in de taxameter\n\nAFSTAND_TOT\n\nLong\n\nTotale door de taxi afgelegde afstand in honderden meters\n\nAFSTAND_TAR\n\nLong\n\nTotale door de taxi afgelegde afstand in honderden meters in de stand tarief\n\nAANT_RIT_BET\n\nLong\n\nTotaal aantal betaalde ritten\n\nBEDR_TOESLAG\n\nLong\n\nTotaal geldbedrag in Eurocenten dat in rekening is gebracht als toeslag\n\nBEDR_RITBEDR\n\nLong\n\nTotaal geldbedrag in Eurocenten dat in rekening is gebracht als ritbedrag\n\nTotale berichtgrootte: 33 bytes\n\nDit bericht is voor het opvragen van de constante van de afstandssignaalgenerator,\n                                             de beveiligingsdatum en de identificatie van de taxi. Totale berichtgrootte: 7 bytes\n\nEIS-LI-20\n\nHet bericht VR_TAXAMETER_INFO bevat geen \u2018data\u2019.\n\nHet bericht A_TAXAMETER_INFO is het antwoord op het bericht VR_TAXAMETER_INFO. Het\n                                             bericht bevat de constante van de afstandssignaalgenerator, de beveiligingsdatum en\n                                             de identificatie van de taxi. Dit bericht is bedoeld om de taxameter te identificeren.\n\nEIS-LI-21\n\nDe data in het bericht A_TAXAMETER_INFO heeft het volgende formaat:\n\nDATUM_EN_TIJD\n\nDatum\n\nHuidige datum en tijd in de taxameter\n\nCONSTANTE_SG\n\nInteger\n\nAantal impulsen per km\n\nBEVEILIGINGS_D\n\nDatum\n\nDatum en tijd waarop de taxameter is beveiligd\n\nTAXI_ID\n\nString\n\nTekst ter identificatie van de taxi\n\nTotale berichtgrootte: variabel, minimaal 22 bytes, maximaal 278 bytes\n\nHet bericht F_BERICHT_ONBEKEND is een foutmelding die gestuurd wordt bij het ontvangen\n                                             van een vraagbericht met een onbekend berichttype. Totale berichtgrootte: 7 bytes.\n\nEIS-LI-22\n\nHet bericht F_BERICHT_ONBEKEND bevat geen \u2018data\u2019.\n\nHet bericht F_CRC_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen\n                                             van een vraagbericht met een onjuiste CRC. Totale berichtgrootte: 7 bytes.\n\nEIS-LI-23\n\nHet bericht F_CRC_INCORRECT bevat geen \u2018data\u2019.\n\nHet bericht F_LENGTE_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen\n                                             van een vraagbericht met een onjuiste minimale of maximale berichtlengte. Totale berichtgrootte:\n                                             7 bytes.\n\nEIS-LI-24\n\nHet bericht F_LENGTE_INCORRECT bevat geen \u2018data\u2019.\n\nHet bericht F_GEEN_STX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal\n                                             een ETX teken zonder het tussentijds ontvangen van een STX teken. Totale berichtgrootte:\n                                             7 bytes\n\nEIS-LI-25\n\nHet bericht F_GEEN_STX bevat geen \u2018data\u2019.\n\nHet bericht F_GEEN_ETX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal\n                                             een STX teken zonder het tussentijds ontvangen van een ETX teken. Totale berichtgrootte:\n                                             7 bytes\n\nEIS-LI-26\n\nHet bericht F_GEEN_ETX bevat geen \u2018data\u2019.\n\nHet bericht F_NIET_STANDAARD is een foutmelding die gestuurd wordt indien er een fout\n                                             optreedt die niet gedefinieerd is in een van de overige foutberichten. Er wordt een\n                                             omschrijving van de fout meegestuurd.\n\nEIS-LI-27\n\nDe data in het bericht F_NIET_STANDAARD heef het volgende formaat:\n\nFOUT_OMSCHR\n\nString\n\nTekst met omschrijving van de opgetreden fout.\n\nTotale berichtgrootte: variabel, minimaal 8 bytes, maximaal 264 bytes\n\nHet bericht F_VELD_ONGELDIG is een foutmelding die gestuurd wordt indien er een ongeldig\n                                             veld gedetecteerd is in het vraagbericht. Bijvoorbeeld voor een ongeldige waarde in\n                                             het veld \u2018Status interface\u2019 van het bericht VR_STATUS. Totale berichtgrootte: 7 bytes\n\nEIS-LI-28\n\nHet bericht F_VELD_ONGELDIG bevat geen \u2018data\u2019.\n\nEIS-LI-29\n\nNa het ontvangen van een vraagbericht dient het begin van een antwoord binnen 0,5\n                                                         seconden verstuurd te zijn. De maximale verzendduur van een bericht bedraagt het dubbele\n                                                         van de tijd van het verzenden van een bericht op maximale snelheid.\n\nEIS-LI-30\n\nOpeenvolgende bytes worden met een tussentijd van maximaal 100ms verstuurd.\n\nEIS-LI-31\n\nIndien een vraagbericht is ontvangen wordt binnen de tijd als gespecificeerd in 0\n                                                         een antwoordbericht (of indien van toepassing een foutbericht) teruggestuurd.\n\nPrioriteit 1 is de hoogste, 3 de laagste.\n\nPrioriteit\n\nEisen\n\n1\n\nAlle EIS-AL\n\n2\n\nAlle EIS-FI\n\n3\n\nAlle EIS-LI\n\nOPENBAAR\n\nVersie 1.7\n\nDatum 25\u00a0april 2012\n\nStatus DEFINITIEF\n\nProjectnaam\n\nBoordcomputer Taxi\n\nDocumenttitel\n\nTechnische specificaties gebruik boordcomputer- en systeemkaarten\n\nClassificatie\n\nOPENBAAR\n\nVersienummer\n\n1.7\n\nStatus\n\nDEFINITIEF\n\nDatum\n\n25\u00a0april 2012\n\nContactpersoon\n\nInspectie Leefomgeving en Transport\n\nProject Boordcomputer Taxi\n\nNieuwe Uitleg 1 | 2514 BP Den Haag\n\nPostbus 90653 | 2509 LR Den Haag\n\nBijlage(n)\n\nGeen\n\nAuteur(s)\n\nPeter G.J. Breur\n\nPiet E. Pieters\n\nVersie\n\nDatum\n\nOmschrijving\n\n1.2\n\n4\u00a0mei 2010\n\nEerste versie voor publicatie\n\n1.3c2\n\n14\u00a0okt 2010\n\nWijzigingen naar aanleiding van door Morpho en Collis uitgevoerde tests met gepersonaliseerde\n                                                      exemplaren van de geselecteerde contactchip:\n\n1)\n\nKaart blijkt geen ondersteuning te bieden voor het selecteren van de DF.CIA op basis\n                                                      van een File Identifier (voorheen 5015h). Selectie van de DF.CIA kan uitsluitend op\n                                                      basis van de Application Identifier plaatsvinden. De APDU\u2019s van de desbetreffende\n                                                      SELECT FILE commando\u2019s zijn aangepast in \u00a7 8.9 t/m \u00a7 8.21.\n\n2)\n\nDe APDU\u2019s voor het lezen en schrijven van EF\u2019s waren door offsets in P1P2 te plaatsen,\n                                                      impliciet gebaseerd op de EVEN variant van READ BINARY, respectievelijk UPDATE BINARY.\n                                                      Deze variant biedt echter geen ondersteuning voor offsets groter dan 32767. Vooral\n                                                      voor het lezen en schrijven van EF.Driver_Activity_Data is dit relevant. In \u00a7 8.9\n                                                      t/m \u00a7 8.21 zijn de desbetreffende \u201cP1P2\u201d vermeldingen dan ook veranderd in het meer\n                                                      generieke woord \u201coffset\u201d. Met aanvullende teksten in hoofdstuk 9 wordt de lezer op\n                                                      het bestaan van een ODD variant, die hogere offsets ondersteunt, gewezen.\n\n3)\n\nDe opslagcapaciteit van de kaart blijkt kleiner dan verwacht. Daarom is er gekozen\n                                                      voor het kunnen opslaan van maximaal 3 (in plaats van 4) Systeemkaartcertificaten\n                                                      in EF.BCT_Certificates. Wijzigingen in \u00a7 6.1 en \u00a7 8.18 t/m \u00a7 8.21\n\n4)\n\nDe kaart blijkt onvoldoende capaciteit te hebben voor het opslaan van een EF.Driver_Activity_Data\n                                                      van 64KB (65536 bytes). Tijdens personalisatie zal echter per kaart een zo groot mogelijke\n                                                      ruimte voor deze EF worden gereserveerd. Per kaart is die grootte dus verschillend.\n                                                      Hoe hiermee om te gaan, is nu vermeld in \u00a7 7.1 en \u00a7 9.5. Daarnaast is de vermelding\n                                                      van 64K in hoofdstuk 5, alinea 1 aangepast.\n\n5)\n\nIn hoofdstuk 10 Referenties [8] t/m [12] bijgewerkt.\n\n1.3c3\n\n15\u00a0okt 2010\n\nEen boordcomputer dient een bestuurder (tijdig) te waarschuwen dat de momenteel op\n                                                      de chauffeurskaart opgeslagen arbeids-, rij- en rusttijden moeten worden ge\u00ebxporteerd.\n                                                      Voorheen bood de chauffeurskaart de boordcomputer hiertoe geen informatie. Dergelijke\n                                                      informatie is nu toegevoegd:\n\n1)\n\nAan hoofdstuk 6 is bovenstaande rationale toegevoegd.\n\n2)\n\nAan EF.BCT_Certificates in \u00a7 6.1 is een gegevensstructuur toegevoegd die vermeldt\n                                                      wanneer en naar welke boordcomputer welke dailyrecords zijn ge\u00ebxporteerd.\n\n3)\n\nAan \u00a7 7.3 \u201cAfsluiten van een kaartsessie\u201d zijn extra processtappen toegevoegd.\n\n4)\n\nAan hoofdstuk 8 zijn nieuwe paragrafen (\u00a7 8.22 t/m \u00a7 8.23) met de extra benodigde\n                                                      functies toegevoegd\n\n1.3c4\n\n28\u00a0okt 2010\n\nMeer wijzigingen naar aanleiding van door Morpho en Collis uitgevoerde tests:\n\n1)\n\nDe Kaartstructuur documenten bevatten kleine fouten en zijn bijgewerkt van versie\n                                                      1.5 naar 1.6. In hoofdstuk 10 zijn de betreffende Referenties ([8] t/m [12]) geactualiseerd.\n\n2)\n\nIn \u00a7 8.5, 8.6 en 8.7 werd gesproken over een \u201cPSO Hash commando met \u20186C\u2019h in Lc om\n                                                      SHA256 aan te duiden\u201d. Omdat dat niet correct is, zijn er tekstverbeteringen in deze\n                                                      paragrafen aangebracht. Ook \u00a7 8.8 is met deze aanvullingen in lijn gebracht.\n\n1.3c5\n\n5\u00a0nov 2010\n\nWijzigingen naar aanleiding van interne review IVW:\n\n1)\n\nEerste alinea van de Inleiding geactualiseerd.\n\n2)\n\nIn \u00a7 2.5 een grammaticale verbetering aangebracht.\n\n3)\n\nIn \u00a7 5.1 de noodzaak van een correct gevuld DriverCardNumber verklaard.\n\n4)\n\nIn \u00a7 5.1.2 expliciet vermeld dat het tijdformaat van een 24-uurs klok uitgaat.\n\n5)\n\nIn \u00a7 5.2 de referentie naar hoofdstuk 7 hersteld.\n\n6)\n\nIn \u00a7 5.2.7 een grammaticale verbetering aangebracht.\n\n7)\n\nIn \u00a7 6.1 de zin onder Figuur 10 verbeterd.\n\n8)\n\nIn \u00a7 7.1, puntje 1 een referentie opgenomen.\n\n9)\n\nIn \u00a7 7.1, punt 4, 2e aandachtsstreepje grammaticale verbeteringen aangebracht.\n\n10)\n\nIn \u00a7 7.3 de eerste twee alinea\u2019s duidelijker verwoord.\n\n11)\n\nIn hoofdstuk 10 de omschrijving van referentie [14] gecorrigeerd.\n\n12)\n\nIn scenario A.6 ontbrekende teksten toegevoegd.\n\n1.3c6\n\n11\u00a0nov 2010\n\nWijzigingen naar aanleiding van document review door Collis:\n\n1)\n\nIn \u00a7 8.7, puntje 4 de tekst \u201cvan minimaal 1 en maximaal 64 bytes\u201d ingevoegd.\n\n2)\n\nIn \u00a7 9.4 het voorbeeld aangepast aan hetgeen in tabel 29 in referentie [7] staat:\n                                                      Bij een Read Binary Odd kan voor P1P2 alleen een SFI meegegeven worden en geen file\n                                                      id\n\n1.4\n\n6\u00a0dec 2010\n\nDoorvoeren naamswijziging ministerie\n\n1.5\n\n29\u00a0jun 2011\n\nWijzigingen met betrekking tot het refereren aan private sleutelobjecten:\n\n1)\n\nIn \u00a7 8.5 twee keer de tekst \u201c06\u201d veranderd in \u201c86\u201d en voetnoot aangepast\n\n2)\n\nIn \u00a7 8.6 twee keer de tekst \u201c05\u201d veranderd in \u201c85\u201d en voetnoot aangepast\n\n3)\n\nIn \u00a7 8.7 twee keer de tekst \u201c05\u201d veranderd in \u201c85\u201d en voetnoot aangepast\n\n4)\n\nIn \u00a7 8.8 twee keer de tekst \u201c05\u201d veranderd in \u201c85\u201d en voetnoot aangepast\n\n1.6\n\n12\u00a0dec 2011\n\nAanpassing \u00a74.6 Authenticatiescenario Systeemkaart-Boordcomputer\n\n1.7\n\n25\u00a0apr 2012\n\nWijzigingen naar aanleiding van uitgevoerde tests:\n\n1)\n\nIn \u00a7 8.5 stap toegevoegd voor selectie hash template en algoritme\n\n2)\n\nIn \u00a7 8.6 stap toegevoegd voor selectie hash template en algoritme\n\n3)\n\nIn \u00a7 8.7 stap toegevoegd voor selectie hash template en algoritme\n\n4)\n\nBijlage B toegevoegd met uitgewerkte voorbeelden van een aantal functies\n\n2.0\n\njan 2020\n\nWijzigingen naar aanleiding van transitie naar een nieuwe BCT-chip:\n\n1)\n\nIn \u00a7 8.5 een tweede variant voor het zetten van een handtekening toegevoegd\n\n2)\n\nIn \u00a7 8.6 een tweede variant voor het zetten van een handtekening toegevoegd\n\n3)\n\nIn \u00a7 8.7 een tweede variant voor het zetten van een handtekening toegevoegd\n\n1\n\nInleiding\n\n84\n\n1.1\n\nBereik van dit document\n\n85\n\n2\n\nOpbouw boordcomputer- en systeemkaarten\n\n85\n\n2.1\n\nISO/IEC 7816-15 structuur\n\n85\n\n2.2\n\nCertificaten\n\n85\n\n2.3\n\nAsymmetrische sleutels\n\n85\n\n2.4\n\nPIN/PUK\n\n85\n\n2.5\n\nGegevens\n\n85\n\n2.5.1\n\nSysteemkaart\n\n85\n\n2.5.2\n\nChauffeurskaart\n\n86\n\n2.5.3\n\nRelatie gegevens boordcomputer \u2013 chauffeurskaart\n\n86\n\n2.6\n\nToegangscondities\n\n86\n\n3\n\nKoppelen Systeemkaart\n\n86\n\n3.1\n\nCommunicatiebeveiliging tussen boordcomputerunits en systeemkaarten\n\n86\n\n3.1.1\n\nBoordcomputerproductie\n\n87\n\n3.1.2\n\nSysteemkaartvervanging\n\n88\n\n4\n\nBeveiligde gegevensoverdracht\n\n89\n\n4.1\n\nStructuur van commando\u2019s en antwoorden bij beveiligde gegevensoverdracht\n\n90\n\n4.2\n\nFouten bij de beveiligde gegevensoverdracht\n\n90\n\n4.3\n\nSessiesleutels\n\n91\n\n4.4\n\nZendsequentieteller (SSC)\n\n91\n\n4.5\n\nAlgoritmes\n\n91\n\n4.6\n\nAuthenticatiescenario Systeemkaart-Boordcomputer\n\n91\n\n5\n\nGegevens op chauffeurskaart (EF.Driver_Activity_Data)\n\n91\n\n5.1\n\nOpbouw van EF.Driver_Activity_Data\n\n91\n\n5.1.1\n\nDailyRecord\n\n92\n\n5.1.2\n\nSessionRecord\n\n93\n\n5.1.3\n\nActivityRecord\n\n94\n\n5.1.4\n\nOverzicht\n\n95\n\n5.2\n\nSchrijven naar EF.Driver_Activity_Data\n\n96\n\n5.2.1\n\nToevoegen van de eerste activiteit binnen een SessionRecord\n\n96\n\n5.2.2\n\nToevoegen \u201cLogin\u201d activiteit\n\n96\n\n5.2.3\n\nToevoegen \u201cStart pauze\u201d activiteit\n\n97\n\n5.2.4\n\nToevoegen \u201cStart werk\u201d activiteit\n\n97\n\n5.2.5\n\nToevoegen \u201cAfsluiting\u201d activiteit\n\n97\n\n5.2.6\n\nToevoegen \u201cNieuwe eindtijd\u201d (=handmatige Afsluiting) activiteit\n\n98\n\n5.2.7\n\nToevoegen \u201cDagovergang (handmatig/automatisch)\u201d activiteit\n\n98\n\n5.3\n\nAlgemene opmerkingen bij lezen en schrijven naar EF.Driver_Activity_Data\n\n99\n\n5.4\n\nDigitale handtekening\n\n99\n\n6\n\nGegevens op chauffeurskaart (EF.BCT_Certificates)\n\n100\n\n6.1\n\nOpbouw van EF.BCT_Certificates\n\n101\n\n7\n\nKaartsessie\n\n102\n\n7.1\n\nBegin van een kaartsessie\n\n103\n\n7.2\n\nTijdens een kaartsessie\n\n104\n\n7.3\n\nAfsluiten van een kaartsessie\n\n105\n\n7.4\n\nNiet afgesloten kaartsessie\n\n105\n\n7.5\n\nDagoverschrijdende kaartsessie\n\n105\n\n8\n\nFuncties\n\n106\n\n8.1\n\nPIN wijzigen\n\n106\n\n8.2\n\nSM keyset wijzigen\n\n106\n\n8.3\n\nPIN deblokkeren\n\n107\n\n8.4\n\nPIN deblokkeren en wijzigen\n\n107\n\n8.5\n\nElektronische handtekening zetten met een chauffeurs- of inspectiekaart\n\n107\n\n8.6\n\nElektronische handtekening zetten met een systeemkaart\n\n108\n\n8.7\n\nAuthenticiteit handtekening zetten met een boordcomputerkaart\n\n108\n\n8.8\n\nAuthenticeren boordcomputerkaart aan boordcomputer\n\n109\n\n8.9\n\nSchrijf nieuw ActivityRecord\n\n110\n\n8.10\n\nSchrijf nieuw SessionRecord\n\n112\n\n8.11\n\nSchrijf nieuw DailyRecord\n\n112\n\n8.12\n\nSelecteer laatste (nieuwste) DailyRecord\n\n113\n\n8.13\n\nSelecteer oudste (eerste) DailyRecord\n\n113\n\n8.14\n\nSelecteer vorige DailyRecord\n\n113\n\n8.15\n\nSelecteer volgende DailyRecord\n\n114\n\n8.16\n\nLees huidige / geselecteerde DailyRecord\n\n115\n\n8.17\n\nControleer EF.Driver_Activity_Data structuur\n\n115\n\n8.18\n\nControleren op opgeslagen boordcomputercertificaat\n\n116\n\n8.19\n\nVolgorde bijwerken van opgeslagen boordcomputercertificaten\n\n117\n\n8.20\n\nGeef opgeslagen boordcomputercertificaat\n\n117\n\n8.21\n\nSla boordcomputercertificaat op\n\n117\n\n8.22\n\nGeef meest recente DownloadLog\n\n118\n\n8.23\n\nSla DownloadLog op\n\n118\n\n9\n\nCommando\u2019s\n\n118\n\n9.1\n\nSelecteren van EF\u2019s\n\n119\n\n9.2\n\nUitlezen van een nog niet geselecteerde EF vanaf een offset < 256\n\n119\n\n9.3\n\nUitlezen van de huidige EF vanaf een offset kleiner 32768\n\n120\n\n9.4\n\nIn de huidige DF Uitlezen van een EF vanaf een offset groter dan 32767\n\n120\n\n9.5\n\nOpvragen van de FCP\u2019s o.a. voor de grootte van EF.Driver_Activity_Data\n\n120\n\n10\n\nReferenties\n\n121\n\n11\n\nBegrippen en afkortingen\n\n121\n\nBijlage A\n\nScenario\u2019s kaartsessies\n\n122\n\nA.1\n\nScenario 1: Normale kaartsessie\n\n122\n\nA.2\n\nScenario 2: Sessie afgesloten met pauze, nieuwe sessie met einde pauze\n\n122\n\nA.3\n\nScenario 3: Sessie afgesloten met pauze, nieuwe sessie met einde pauze en andere werkzaamheden\n\n123\n\nA.4\n\nScenario 4: Sessie afgesloten, volgende dag toevoegen van andere werkzaamheden aan\n                                                         de vorige dag\n\n124\n\nA.5\n\nScenario 5: Sessie afgesloten, pauze vervangen door andere werkzaamheden\n\n124\n\nA.6\n\nScenario 6: Sessie niet afgesloten, vervolg zelfde werkzaamheden\n\n125\n\nA.7\n\nScenario 7: Sessie niet afgesloten, andere activiteiten ertussendoor\n\n126\n\nA.8\n\nScenario 8: Sessie niet afgesloten, later automatisch be\u00ebindigd\n\n127\n\nA.9\n\nScenario 9: Sessie niet afgesloten, kaart tussendoor in ander voertuig\n\n127\n\nBijlage B\n\nReferentie data\n\n129\n\nB.1\n\nHet opzetten van Secure Messaging\n\n129\n\nB.2\n\nHet sturen van commando\u2019s met Secure Messaging\n\n131\n\nB.3\n\nHet zetten van een handtekening met een boordcomputerkaart\n\n132\n\nB.3.1\n\nSignDataLegally\n\n132\n\nB.3.2\n\nSignDataForAuthenticity\n\n134\n\nB.4\n\nHet zetten van een handtekening met een systeemkaart\n\n136\n\nMet de inwerkingtreding van de \u2018Ministeriele Regeling specificaties en typegoedkeuring boordcomputer taxi\u2019 zijn de specificaties van de \u2018Boordcomputer Taxi\u2019 (BCT) van kracht geworden. Met\n                                       deze regelgeving wordt elke taxi in Nederland voorzien van een boordcomputer, die\n                                       zowel de arbeids-, rij- en rusttijden van de taxichauffeur als de rittenstaat behorend\n                                       bij de taxi vastlegt.\n\nOm de authenticiteit en integriteit van de vastgelegde data te waarborgen, voorziet\n                                       de boordcomputer deze data van elektronische handtekeningen. Daartoe wordt een zogeheten\n                                       \u2018Public Key Infrastructure\u2019 worden opgezet. De boordcomputer wordt voorzien van een\n                                       certificaat en een sleutelpaar (publieke- en private sleutels), zodat hij in staat\n                                       is data elektronisch te ondertekenen en de authenticiteit van aangeboden gebruikerskaarten\n                                       vast te stellen. Het certificaat en het sleutelpaar van de boordcomputer worden hiertoe\n                                       opgeslagen op een chipkaart, de zogeheten systeemkaart, die in een speciaal kaartslot\n                                       van de boordcomputer wordt geplaatst.\n\nAlle gebruikers van de boordcomputer worden voorzien van gebruikerskaarten, de zogeheten\n                                       boordcomputerkaarten. Deze kaarten bevatten evenals de systeemkaart certificaten en\n                                       sleutelparen. Toegang tot de boordcomputer is alleen mogelijk na authenticatie van\n                                       een boordcomputerkaart door (de logica van) de boordcomputer.\n\nBinnen de groep gebruikers van de boordcomputer zijn vier rollen te onderscheiden,\n                                       namelijk die van bestuurder, vervoerder, werkplaats en toezichthouder. Elk van deze\n                                       rollen is gebonden aan een apart type boordcomputerkaart. Elke rol heeft zijn eigen\n                                       autorisatieniveau, bijvoorbeeld waar het gaat om toegang tot de op de boordcomputer\n                                       vastgelegde data.\n\nBinnen BCT zijn dus vijf verschillende chipkaarten te onderscheiden:\n\n\u2022 Een apparaatgebonden systeemkaart behorend bij een boordcomputer;\n\n\u2022 Een persoonsgebonden chauffeurskaart behorend bij een bestuurder;\n\n\u2022 Een organisatiegebonden ondernemerskaart behorend bij een vervoerder;\n\n\u2022 Een organisatiegebonden keuringskaart behorend bij een werkplaats;\n\n\u2022 Een persoonsgebonden inspectiekaart behorend bij een toezichthouder.\n\nDit document bevat technische specificaties en richtlijnen voor het gebruik van de\n                                          hierboven genoemde chipkaarten. Dit document is primair bedoeld voor fabrikanten van\n                                          boordcomputers. De hoofdstukken 2 en 5 t/m 8, alsmede bijlage A, zijn echter ook interessant\n                                          voor ontwikkelaars van toepassingen bedoeld om chauffeurskaarten uit te lezen.\n\nDe boordcomputer- en systeemkaarten zijn uitgevoerd als ISO/IEC 7816-15 kaarten. De\n                                          algemene opbouw van ISO/IEC 7816-15 kaarten staat beschreven in Referentie [3]. De\n                                          opbouw per kaart wordt in de specificatie documenten van de afzonderlijke kaarten\n                                          beschreven (Referenties [8] t/m [12]).\n\nDe op de boordcomputer- en systeemkaarten gebruikte certificaten zijn X.509 certificaten\n                                          uitgegeven conform het vigerende Programma van Eisen (PvE) van PKIoverheid. Er worden\n                                          verschillende X.509 certificaten gebruikt, zoals voor authenticatie, handtekening\n                                          en vertrouwelijkheid. Zie verder Referentie [13] in hoofdstuk 10.\n\nAsymmetrische sleutels worden gebruikt voor authenticatie, vertrouwelijkheid en handtekening.\n                                          De publieke sleutels zijn opgeslagen in de X.509 certificaten (zie \u00a7 2.2) en de private\n                                          sleutels intern in de kaarten.\n\nDe asymmetrische sleutels die in de kaarten gebruikt worden zijn RSA sleutels met\n                                          een lengte van 2048 bits.\n\nDe eigenschappen van de PIN en PUK (PIN Unblock Key) per kaart worden in de specificatie\n                                          documenten van de afzonderlijke kaarten beschreven (Referenties [8] t/m [12] in hoofdstuk\n                                          10).\n\nDe PIN wordt algemeen gebruikt voor de authenticatie van de kaarthouder en bij persoonsgebonden\n                                          boordcomputerkaarten voor het zetten van elektronische handtekeningen. De PUK kan\n                                          gebruikt worden om de PIN te deblokkeren.\n\nOp alle kaarten zijn gegevens zoals voorgeschreven in ISO/IEC 7816-15 opgeslagen.\n                                          Er zijn echter twee typen kaarten waarop ook andere gegevens toegevoegd kunnen worden:\n                                          de systeemkaart en de chauffeurskaart.\n\nOp de systeemkaart kan eenmalig het serienummer van de boordcomputer opgeslagen worden.\n                                             Dit staat beschreven in hoofdstuk 3. Verder worden er (tijdens de gebruiksfase) op\n                                             de systeemkaart geen gegevens opgeslagen.\n\nOp de chauffeurskaart worden de arbeids-, rij- en rusttijden van de chauffeur, alsmede\n                                             de systeemkaartcertificaten van de laatst gebruikte boordcomputers opgeslagen. Dit\n                                             wordt beschreven in hoofdstuk 5.\n\nVoor de boordcomputer is het niet vastgelegd hoe de gegevens opgeslagen moeten worden.\n                                             Wel is vastgelegd welke gegevens er opgeslagen moeten worden en hoe en in welk formaat\n                                             ze beschikbaar moeten zijn voor gegevenslevering.\n\nVanwege beperkingen voor wat betreft het formaat en de mogelijkheden voor controle\n                                             en uitlezen van de gegevens, is voor de chauffeurskaart wel exact vastgelegd hoe de\n                                             gegevens opgeslagen moeten worden. Dit staat beschreven in hoofdstuk 5.\n\nSpecifieke toegangscondities worden gegeven in de specificatiedocumenten van de afzonderlijke\n                                          boordcomputerkaarten.\n\nAlgemeen geldt voor de toegangscondities:\n\n\u2022 Lezen PIN, PUK en RSA sleutels: niet toegestaan.\n\n\u2022 Lezen gegevens: geen beperking.\n\n\u2022 Schrijven van de RSA sleutels: niet toegestaan.\n\n\u2022 Gebruik van de RSA sleutels voor authenticiteit en elektronische handtekeningen: alleen\n                                                mogelijk na een succesvolle verificatie van de PIN. Bij systeemkaarten wordt Secure\n                                                Messaging in plaats van een PIN gebruikt.\n\n\u2022 Gebruik van de PIN (alleen op boordcomputerkaarten): geen beperkingen.\n\n\u2022 Deblokkeren van de PIN (alleen op boordcomputerkaarten): alleen mogelijk na een succesvolle\n                                                verificatie van de PUK.\n\n\u2022 Wijzigen van de PIN (alleen op boordcomputerkaarten): alleen mogelijk na een succesvolle\n                                                verificatie van de (huidige) PIN of, als aanvulling op deblokkeren, na succesvolle\n                                                verificatie van de PUK.\n\n\u2022 Gebruik van de PUK (alleen op boordcomputerkaarten): geen beperkingen.\n\n\u2022 Schrijven: bij systeemkaarten alleen mogelijk in Secure Messaging en bij chauffeurskaarten\n                                                alleen mogelijk na een succesvolle verificatie van de PIN.\n\nDe systeemkaart moet initieel aan de boordcomputer gekoppeld worden om de boordcomputer\n                                       te laten functioneren. Onderstaande paragrafen geven een nadere specificatie van boordcomputerproductie,\n                                       respectievelijk systeemkaartvervanging.\n\nEen boordcomputer wordt gevormd door de combinatie van een boordcomputerunit en een\n                                          systeemkaart. De boordcomputerunit wordt hierbij beschouwd als de gebruiker/houder\n                                          van de systeemkaart. Net zoals een boordcomputerkaart uitsluitend door zijn rechtmatige\n                                          houder mag worden gebruikt (voor het plaatsen van elektronische handtekeningen), mag\n                                          ook een systeemkaart uitsluitend door zijn rechtmatige \u201chouder\u201d worden gebruikt. Om\n                                          dit rechtmatige gebruik te waarborgen wordt elke systeemkaart voorzien van een geheime\n                                          sleutel die in de boordcomputerunit dient te worden voorgeprogrammeerd.\n\nHet communicatiekanaal (voor het plaatsen van elektronische handtekeningen) tussen\n                                          een boordcomputerunit en zijn gekoppelde systeemkaart moet beveiligd zijn om de integriteit,\n                                          authenticiteit en vertrouwelijkheid van de uitgewisselde gegevens te beschermen. Omdat\n                                          de koppeling tussen een boordcomputerunit en \u201czijn\u201d systeemkaart een-op-een is, is\n                                          er voor het opzetten van een veilig communicatiekanaal geen noodzaak voor asymmetrische\n                                          cryptografie, maar kan met symmetrische cryptografie worden volstaan. De symmetrische\n                                          sleutel(set) die voor deze communicatiebeveiliging wordt gebruikt is per boordcomputer\n                                          uniek; elke systeemkaart wordt voorzien van een symmetrische communicatiesleutel(set)\n                                          die in de bijbehorende boordcomputerunit dient te worden voorgeprogrammeerd.\n\nEr bestaan vijf soorten combinaties van boordcomputerunits en systeemkaarten:\n\n1. Niet-gekoppelde boordcomputerunit \u2013 niet-gekoppelde eerste systeemkaart;\n\n2. Boordcomputerunit gekoppeld aan eerste systeemkaart (= boordcomputer);\n\n3. Boordcomputerunit \u2013 ontkoppelde/onklaar gemaakte systeemkaart;\n\n4. Boordcomputer \u2013 niet-gekoppelde vervangende systeemkaart;\n\n5. Boordcomputerunit gekoppeld aan vervangende systeemkaart (= boordcomputer);\n\nCombinatie 1 is van toepassing in de fabriek waar de boordcomputerunit wordt geproduceerd.\n                                          Combinatie 2 wordt gemaakt bij de boordcomputerfabrikant voorafgaand aan de distributie\n                                          van de resulterende boordcomputer. Combinaties 1 en 2 vallen daarmee onder de noemer\n                                          \u201cboordcomputerproductie\u201d.\n\nCombinaties 3, 4 en 5 betreffen het \u201cin het veld\u201d (buiten de fabriek) op een boordcomputer\n                                          vervangen van de huidige gekoppelde systeemkaart door een andere systeemkaart. Deze\n                                          combinaties vallen onder de noemer \u201csysteemkaartvervanging\u201d.\n\nOnderstaande subparagrafen geven een nadere specificatie van boordcomputerproductie,\n                                          respectievelijk systeemkaartvervanging.\n\nElke boordcomputerfabrikant die een typegoedkeuring heeft verkregen kan, per typegoedkeuringsnummer,\n                                             bij de Kaartuitgever een verzoek voor een transportkey indienen. De Kaartuitgever\n                                             zal, na verificatie van het typegoedkeuringsnummer, via de Personalisator een transportkey\n                                             voor het typegoedkeuringsnummer genereren. Deze transportkey zal op een pinmailer\n                                             aan de fabrikant worden verzonden.\n\nWanneer de fabrikant boordcomputers van het desbetreffende type wil gaan produceren,\n                                             zal de fabrikant op basis van het typegoedkeuringsnummer een of meer batches van systeemkaarten\n                                             bestellen bij de Kaartuitgever. De Kaartuitgever / Personalisator gebruikt de eerder\n                                             vastgelegde transportkey (zie voorgaande alinea) om de te produceren systeemkaarten\n                                             mee te beschermen. De door de fabrikant geproduceerde boordcomputerunits dienen door\n                                             de fabrikant te worden voorgeprogrammeerd met diezelfde transportkey.\n\nMet het bovenstaande scenario kan elke nieuw geproduceerde boordcomputerunit (van\n                                             een specifiek type) communiceren met elke gepersonaliseerde eerste systeemkaart (voor\n                                             datzelfde boordcomputertype).\n\nNadat de operator bij de fabrikant een boordcomputerunit van een nieuwe systeemkaart\n                                             (uit de bij de fabrikant aanwezige voorraad) heeft voorzien, dient die operator de\n                                             \u201ckoppelfunctie\u201d van de boordcomputerunit te gebruiken. Die koppelfunctie dient de\n                                             typespecifieke transportkey te vervangen met een door de boordcomputerunit gegenereerde\n                                             \u201ctrue random\u201d waarde. Deze sleutelvervanging dient uiteraard zowel in de boordcomputerunit\n                                             als in de systeemkaart te gebeuren. Hierna kan de betreffende boordcomputerunit uitsluitend\n                                             nog met de betreffende systeemkaart werken.\n\nDe onderstaande tabel geeft een overzicht van de toegangscondities en de inhoud van\n                                             de verschillende security objecten van systeemkaart en boordcomputerunit zowel voor\n                                             als na het koppelproces.\n\nTabel 1. Toegangscondities/inhoud van objecten bij eerste systeemkaarten\n\nSecurity / Data Object\n\nAccess Condition\n\nGeproduceerd\n\nGekoppeld\n\nRead\n\nWrite\n\nUse\n\nReset\n\nSTK1.RSA.Private\n\nnever\n\nnever\n\nSM\n\nn.a.\n\nrsakey1\n\nrsakey1\n\nSTK1.DO.NextKey\n\nSM\n\nSM\n\nn.a.\n\nn.a.\n\ntransportkey2\n\ntransportkey2\n\nSTK1.DO.BC.Serial\n\nAlways\n\nSM\n\nn.a.\n\nn.a.\n\nLeeg\n\nSerienr. BCT\n\nSTK1.SMkeyset\n\nnever\n\nSM\n\nalways\n\nn.a.\n\ntransportkey1\n\nuniquekey1\n\nBCT.Secret\n\nBCT custom access conditions\n\ntransportkey1\n\nuniquekey1\n\nNB. De constructie en/of logica van de boordcomputer dient het object BCT.SECRET op adequate\n                                                wijze te beschermen tegen ontvreemding (dit geheim mag uitsluitend toegankelijk zijn\n                                                voor de boordcomputerlogica en uitsluitend voor de in dit document beschreven doelen\n                                                worden toegepast.\n\nDe Personalisator levert een systeemkaart op met de volgende waarden:\n\n\u2022 Een per kaart unieke en nergens onthouden waarde in het RSA private key object;\n\n\u2022 Een per typegoedkeuringsnummer unieke en bij de Personalisator en fabrikant bekende,\n                                                   bewaarde en geheimgehouden waarde \u201ctransportkey1\u201d in het object SMkeyset;\n\n\u2022 Een per kaart unieke en bij de Personalisator bewaarde waarde \u201ctransportkey2\u201d in het\n                                                   dataobject NextKey;\n\n\u2022 Een lege string in het dataobject BC.Serial.\n\nOmdat de waarde \u201ctransportkey1\u201d geheimgehouden is, is een gepersonaliseerde niet-gekoppelde\n                                             kaart tijdens distributie onbruikbaar voor:\n\n\u2022 Het gebruik van de RSA private key\n\n(nodig voor het zetten van elektronische handtekeningen);\n\n\u2022 Het uitlezen van het object NextKey\n\n(nodig voor het koppelen aan een vervangende systeemkaart);\n\n\u2022 Het beschrijven van het object BC.Serial\n\n(nodig als onderdeel van het koppelproces).\n\nOmdat de waarde \u201ctransportkey1\u201d wel bij de fabrikant bekend is, is die waarde voorgeprogrammeerd\n                                             in het \u201cSecret\u201d object van elke nieuw geproduceerde boordcomputerunit. Hiermee kan\n                                             een boordcomputerunit het koppelproces doorlopen:\n\n1. Lees de waarde \u201ctransportkey1\u201d uit de variabele Secret;\n\n2. Genereer een nieuwe unieke (random) waarde \u201cuniquekey1\u201d;\n\n3. Gebruik \u201ctransportkey1\u201d als een 3DES sleutelset om via een MUTUAL AUTHENTICATE een\n                                                   veilig kanaal (MAC_ENC Secure Messaging kanaal) op te zetten met de systeemkaart (zie\n                                                   \u00a7 4.6);\n\n4. Gebruik een PUT DATA om de SMkeyset te wijzigen in \u201cuniquekey1\u201d, gebruikmakend van\n                                                   het SM kanaal;\n\n5. Gebruik het SM kanaal om het dataobject BC.SERIAL te beschrijven met het serienummer\n                                                   van de boordcomputer.\n\nHet dataobject BC.SERIAL is 64 bytes groot. In de eerste byte dient de lengte van\n                                                   het serienummer in bytes te worden opgeslagen als een (unsigned) byte. Het serienummer,\n                                                   weergegeven als een (8-bits) ASCII string, wordt vanaf de tweede byte opgeslagen.\n                                                   De maximale lengte van een serienummer is hiermee 63 karakters (bytes);\n\n6. Overschrijf de variabele Secret met \u201cuniquekey1\u201d en vernietig daarbij de kennis van\n                                                   \u201ctransportkey1\u201d;\n\n7. Sluit de kaartsessie.\n\nNB. Het initi\u00ebren van het koppelproces kan, naar keuze van de fabrikant, een (beschermde)\n                                                menugestuurde optie zijn of automatisch gebeuren als gevolg van het herkennen van\n                                                een nog niet gekoppelde systeemkaart in het systeemkaartslot.\n\nDe systeemkaart is nu een-op-een gekoppeld aan de boordcomputerunit die met zijn kennis\n                                             van \u201cuniquekey1\u201d een MAC_ENC SM kanaal kan opzetten en daarmee het volgende kan doen:\n\n\u2022 Zetten van elektronische handtekeningen;\n\n\u2022 Uitlezen van NextKey voor het koppelen van een vervangende systeemkaart;\n\n\u2022 Opnieuw doorlopen van het koppelproces om de waarde \u201cuniquekey1\u201d te wijzigen in een\n                                                   nieuwe waarde.\n\nOndersteuning van de laatstgenoemde mogelijkheid is niet voorgeschreven, maar kan\n                                             als extra veiligheidsmaatregel periodiek worden gedaan.\n\nDit beveiligingsconcept voorziet, teneinde reguliere certificaatvervanging te ondersteunen,\n                                             in de mogelijkheid om de systeemkaart van een boordcomputer te vervangen door een\n                                             andere.\n\nOm dit \u201cin het veld\u201d door een werkplaats te kunnen laten doen is het concept voor\n                                             vervanging dusdanig dat er geen kennis van enig geheim vereist is bij degene die de\n                                             vervanging uitvoert. Hiertoe is met de Personalisator afgesproken:\n\n1. dat elke eerste systeemkaart een dataobject NextKey bevat met daarin een unieke waarde\n                                                   \u201ctransportkey2\u201d,\n\n2. dat de Personalisator die waarde voor elke systeemkaart in escrow houdt en\n\n3. dat de Personalisator het SMkeyset object van de desbetreffende vervangende systeemkaart\n                                                   vult met die onthouden waarde.\n\nUiteraard zal het NextKey dataobject van de vervangende systeemkaart ook weer worden\n                                             gevuld met een nieuwe unieke waarde (\u201ctransportkey3\u201d), zodat een volgende vervanging\n                                             ook weer kan worden uitgevoerd.\n\nZoals in de vorige paragraaf is uitgelegd, worden nieuw geproduceerde boordcomputerunits\n                                             in de fabriek voorgeprogrammeerd met de (typespecifieke) \u201ctransportkey1\u201d. In die veilige\n                                             omgeving kan elke willekeurige nieuwe boordcomputerunit (van een bepaald type) dan\n                                             ook gekoppeld worden aan elke willekeurige gepersonaliseerde \u201ceerste systeemkaart\u201d\n                                             (voor datzelfde boordcomputertype).\n\nBij het vervangen van een systeemkaart wordt de oude systeemkaart gebruikt om de boordcomputerunit\n                                             te voorzien van de transportkey die nodig is voor de koppeling aan de vervangende\n                                             systeemkaart. Hierbij blijft die transportkey onzichtbaar voor degene die de vervanging\n                                             uitvoert. Omdat bovendien geldt dat de transportkey van elke vervangende systeemkaart\n                                             uniek is voor die kaart, is bovendien gewaarborgd dat een vervangende systeemkaart\n                                             uitsluitend in \u00e9\u00e9n (1) specifieke boordcomputer zal kunnen werken.\n\nNB. Bij het bestellen van een vervangende systeemkaart wordt aan de Personalisator aangeduid\n                                             om welke \u201cvoorloper\u201d het gaat. Hiervoor wordt het systeemkaartnummer gebruikt dat\n                                             als volgt is opgebouwd: \u201cS\u201d + boordcomputernummer (hetzelfde als dat van de voorloper)\n                                             + kaartvolgnummer (1 hoger dan dat van de voorloper).\n\nDe onderstaande tabel geeft een overzicht van de toegangscondities en de inhoud van\n                                             de verschillende security objecten van systeemkaart 1 en 2 en van de boordcomputerunit\n                                             zowel voor als na het koppelproces.\n\nSecurity / Data Object\n\nAccess Condition\n\nGekoppeld 1\n\nOntkoppeld 1 / Geprod. 2\n\nGekoppeld 2\n\nRead\n\nWrite\n\nUse\n\nReset\n\nSTK1.RSA.Private\n\nnever\n\nnever\n\nSM\n\nn.a.\n\nrsakey1\n\nrsakey1\n\nn.a.\n\nSTK1.DO.NextKey\n\nSM\n\nSM\n\nn.a.\n\nn.a.\n\ntransportkey2\n\nrandom\n\nn.a.\n\nSTK1.DO.BC.Serial\n\nAlways\n\nSM\n\nn.a.\n\nn.a.\n\nSerienr. BCT\n\nLeeg\n\nSTK1.SMkeyset\n\nnever\n\nSM\n\nalways\n\nn.a.\n\nuniquekey1\n\nrandom/blocked\n\nn.a.\n\nBCT.Secret\n\nBCT custom access conditions\n\nuniquekey1\n\ntransportkey2\n\nuniquekey2\n\nSTK2.RSA.Private\n\nnever\n\nnever\n\nSM\n\nn.a.\n\nn.a.\n\nrsakey2\n\nrsakey2\n\nSTK2.DO.NextKey\n\nSM\n\nSM\n\nn.a.\n\nn.a.\n\nn.a.\n\ntransportkey3\n\ntransportkey3\n\nSTK2.DO.BC.Serial\n\nAlways\n\nSM\n\nn.a.\n\nn.a.\n\nn.a.\n\nLeeg\n\nSerienr. BCT\n\nSTK2.SMkeyset\n\nnever\n\nSM\n\nalways\n\nn.a.\n\nn.a.\n\ntransportkey2\n\nuniquekey2\n\nHet koppelen van de boordcomputerunit aan de vervangende systeemkaart volgt dezelfde\n                                             stappen als bij het koppelen aan de eerste (of voorgaande) systeemkaart zoals beschreven\n                                             in \u00a7 3.1.1. Het verschil zit hem in de volgende voorbereidende stappen:\n\n1. Initieer de vervanging door het aanroepen van de desbetreffende functie op de boordcomputer;\n\n2. Lees de waarde \u201cuniquekey1\u201d uit de variabele Secret;\n\n3. Gebruik (indien er nog geen MAC_ENC Secure Messaging kanaal bestaat) \u201cuniquekey1\u201d\n                                                   als een 3DES sleutelset om via een MUTUAL AUTHENTICATE een veilig kanaal (MAC_ENC\n                                                   Secure Messaging kanaal) op te zetten met de huidige systeemkaart;\n\n4. Lees, gebruikmakend van het SM kanaal, de waarde \u201ctransportkey2\u201d uit het dataobject\n                                                   NextKey;\n\n5. Maak, gebruikmakend van het SM kanaal, de huidige systeemkaart onklaar:\n\n6. Overschrijf het NextKey data object met een random waarde;\n\n7. Overschrijf het SMkeyset object met een random waarde;\n\n8. Overschrijf het BC.Serial object met een random of een lege waarde;\n\n9. Overschrijf de variabele Secret met \u201ctransportkey2\u201d en vernietig daarbij de kennis\n                                                   die de boordcomputerunit van de huidige systeemkaart had;\n\n10. Sluit de kaartsessie;\n\n11. Vervang systeemkaart 1 fysiek voor systeemkaart 2.\n\n12. Hierna dezelfde 7 stappen als bij 1e koppelproces.\n\n13.\n\nNB. Stap 1 kan, naar keuze van de fabrikant, ge\u00efnitieerd worden door een (beschermde)\n                                                menugestuurde optie of automatisch starten wanneer het systeemkaartslot geopend wordt\n                                                (maar voorafgaand aan het verbreken van de elektrische verbinding tussen boordcomputereenheid\n                                                en systeemkaart). Hierbij geniet de laatste methode de voorkeur omdat dit een effectieve\n                                                bescherming tegen misbruik van de systeemkaart biedt.\n\nOvereenkomstig het gestelde in Referentie [14] hoeft de gegevensoverdracht tussen\n                                       boordcomputer en boordcomputerkaart niet te worden beveiligd. Volgens diezelfde referenties\n                                       dient de gegevensoverdracht tussen boordcomputerlogica en systeemkaart wel beveiligd\n                                       te zijn.\n\nDeze beveiligde gegevensoverdracht wordt bereikt door het versleutelen van de gegevens\n                                       en het toevoegen van een cryptografische controlesom (MAC) aan de binnen het commando\n                                       of het antwoord gezonden gegevensobjecten (MAC-ENC mode).\n\nDe MAC van binnen een commando gezonden gegevens moet de commando-kop en alle gezonden\n                                       gegevensobjecten integreren (=> CLA = '0C', en alle gegevensobjecten moeten worden\n                                       ingekapseld met tags waarin b1 = 1).\n\nDe MAC moet door de ontvanger geverifieerd worden.\n\nDe bytes van de statusinformatie van het antwoord moeten altijd door een MAC worden\n                                       beveiligd, met uitzondering van de gevallen beschreven in paragraaf 4.2.\n\nIn de onderstaande figuren zijn schematisch een beveiligd commando en een beveiligd\n                                          antwoord weergegeven. Voor een verdere beschrijving hiervan wordt verwezen naar Referentie\n                                          [7], section 7.1.9 en section 7.1.10.\n\nWanneer de systeemkaart tijdens het verwerken van een commando een Secure Messaging-fout\n                                          ontdekt, dan moeten de statuswoorden zonder Secure Messaging teruggezonden worden.\n                                          Overeenkomstig ISO/IEC 7816-4 moeten de onderstaande statuswoorden gebruikt worden\n                                          om Secure Messaging-fouten aan te geven:\n\n'69 82' Veiligheids toestand voldoet niet,\n\n'69 85' Sessiesleutels zijn niet beschikbaar,\n\n'69 87' Verwachte Secure Messaging-gegevensobjecten ontbreken,\n\n'69 88' Secure Messaging-gegevensobjecten onjuist.\n\nWanneer de systeemkaart statuswoorden zonder Secure Messaging gegevensobjecten of\n                                          met een foutieve Secure Messaging gegevensobjecten terugzendt, moet de sessie door\n                                          de boordcomputerlogica afgebroken worden.\n\nIn het geval van een Secure Messaging-fout vervallen de sessiesleutels en SSC.\n\nVoor beveiligde gegevensoverdracht tussen de boordcomputerlogica en de systeemkaart\n                                          worden twee 16 bytes lange sessiesleutels gebruikt. De methode om deze sessiesleutels\n                                          SKENC en SKMAC te genereren wordt beschreven in Referentie [7], section 7.1.4.\n\nTijdens de authenticatie procedure wordt er door zowel de systeemkaart als door de\n                                          boordcomputerlogica een 8 bytes random gegenereerd, RND.BCT resp. RND.ICC.\n\nDe vier minst significante bytes (LSB) van beiden worden gebruikt om de initi\u00eble waarde\n                                          voor de SSC te bepalen: SSC = RND.ICC (4 LSB) || RND.BCT (4 LSB).\n\nDe SSC wordt iedere keer voordat een MAC berekend wordt met 1 verhoogd, dus voor de\n                                          eerste MAC-berekening wordt de waarde SSC + 1 gebruikt.\n\nHet algoritme dat gebruikt wordt voor het berekenen van cryptogrammen wordt beschreven\n                                          in Referentie [7], section 7.1.9 en section 7.1.10.\n\nHet algoritme dat gebruikt wordt voor het berekenen van cryptografische controlesommen\n                                          (MACs) wordt beschreven in Referentie [7], section 7.1.12.\n\nDe MAC is 8 bytes lang.\n\nIedere keer voordat er een MAC berekend wordt, wordt de zendsequentieteller (SSC)\n                                          met 1 verhoogd.\n\nHet authenticatiescenario tussen systeemkaart en boordcomputer wordt uitgevoerd zoals\n                                          beschreven is in Referentie [7], section 5.2.2.\n\nHierbij moet gelet worden op de volgende punten:\n\n1. Er wordt gebruik gemaakt van symmetrische sleutels (zie hoofdstuk 3). De initi\u00eble\n                                                sleutels worden afgeleid van \u201ctransportkey1\u201d:\n\n\u2022 KS.KMAC bestaat uit de eerste 16 bytes van \u201ctransportkey1\u201d,\n\n\u2022 KS.KENC bestaat uit de laatste 16 bytes van \u201ctransportkey1\u201d.\n\n2. Na het uitlezen van EF.SN.ICC worden de laatste 8 bytes hiervan gebruikt voor SN.ICC.\n\n3. Bij het berekenen van de MAC moet gebruik gemaakt worden van padding, zoals beschreven\n                                                is in Referentie [7], section 10.1.\n\nNa een succesvolle uitvoering van de Mutual Authenticate kunnen de sessiesleutels\n                                          en de SSC berekend worden, zoals beschreven is in Referentie [7], section 7.1.4 en\n                                          7.1.5.\n\nEr is dan een secure messaging kanaal tussen de systeemkaart en de boordcomputer (MAC-ENC\n                                          mode) en alle volgende commando\u2019s en antwoorden moeten beveiligde gegevensoverdracht\n                                          gebruiken.\n\nOp de chauffeurskaart worden de arbeids- rij- en rusttijden van een chauffeur opgeslagen\n                                       in de bestandsstructuur EF.Driver_Activity_Data. De grootte van die bestandsstructuur\n                                       wordt door de Personalisator op elke chauffeurskaart gemaximeerd (zie ook \u00a7 7.1, \u00a7\n                                       9.5 en Referentie [9] in hoofdstuk 10).\n\nNaam\n\nGrootte (bytes)\n\nPointerOldestDayRecord\n\n2\n\nPointerLastDayRecord\n\n2\n\nDriverCardNumber\n\n16\n\nDailyRecords\n\nvariabel\n\nEF.Driver_Activity_Data is opgebouwd uit de volgende elementen:\n\n\u2022 \nPointerOldestDayRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data)\n                                                van de oudste volledige dagregistratie in DailyRecords.\n\nDe initi\u00eble waarde (na personalisatie) is \u201800 00\u2019H (0) wat betekent dat er nog geen\n                                                DailyRecords bestaan.\n\nNa toevoeging van het eerste DailyRecord moet de waarde \u201800 14\u2019H (20) zijn.\n\nDe maximale waarde wordt door de lengte van EF.Driver_Activity_Data bepaald.\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nPointerLastDayRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data)\n                                                van de meest recente dagregistratie in DailyRecords.\n\nDe initi\u00eble waarde (na personalisatie) is \u201800 00\u2019H (0) wat betekent dat er nog geen\n                                                DailyRecords bestaan.\n\nNa toevoeging van het eerste DailyRecord moet de waarde \u201800 14\u2019H (20) zijn.\n\nDe maximale waarde wordt door de lengte van EF.Driver_Activity_Data bepaald.\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nDriverCardNumber: betreft een kopie van het chauffeurskaartnummer zoals dat ook aanwezig is in het\n                                                subjectSerialNumber-veld van het (\u201cread-only\u201d) authenticiteitcertificaat van de chauffeurskaart.\n                                                Na personalisatie zal dit element gevuld zijn met het chauffeurskaartnummer. Handhavingsapplicaties\n                                                downloaden in principe uitsluitend EF_Driver_Activity_Data van een chauffeurskaart.\n                                                Om die applicaties te informeren over het chauffeurskaartnummer, dient een boord\u00accomputer\n                                                de correcte invulling van dit veld telkens na een succesvolle login te verifi\u00ebren\n                                                en zo nodig te herstellen (zie ook \u00a7\u00a07.1).\n\nGegevenssoort: PrintableString (16 bytes)\n\n\u2022 \nDailyRecords: de records waarin de gegevens van de activiteiten van de chauffeur opgeslagen worden\n                                                (zie Figuur 4). Voor iedere dag dat de kaart gebruikt wordt, wordt een DailyRecord\n                                                aangemaakt. De gegevens van minimaal de laatste 31 kalenderdagen worden op de kaart\n                                                bewaard.\n\nEen DailyRecord bevat alle gegevens van de activiteiten van de chauffeur op een bepaalde\n                                             dag. Na personaliseren bestaat er nog geen enkel DailyRecord.\n\nNaam\n\nGrootte (bytes)\n\nDayRecordLength\n\n2\n\nPointerLastSessionRecord\n\n2\n\nPreviousDayRecordLength\n\n2\n\nDayRecordDate\n\n4\n\nSessionRecords\n\nvariabel\n\nEen DailyRecord bestaat uit de volgende elementen:\n\n\u2022 \nDayRecordLength: de lengte van het huidige DailyRecord.\n\nDe initi\u00eble waarde bij een nieuw DailyRecord (dat nog geen enkel SessionRecord omvat)\n                                                   is \u201800 0A\u2019H (10); de lengte van de kop van dit DailyRecord (zonder de SessionRecords).\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nPointerLastSessionRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data)\n                                                   van de meest recente sessie in dit DailyRecord.\n\nDe initi\u00eble waarde bij een nieuw DailyRecord (dat nog geen enkel SessionRecord bevat)\n                                                   is \u201800 00\u2019H (0).\n\nNadat aan dit DailyRecord het eerste SessionRecord is toegevoegd, moet de waarde 10\n                                                   hoger zijn dan het startadres van dit DailyRecord; bij het eerste SessionRecord van\n                                                   het eerstgeboekte DailyRecord zal dit 20 + 10 = 30 (\u201900 1E'H) zijn.\n\nUitgezonderd de waarde 0, zal de waarde van PointerLastSessionRecord nooit kleiner\n                                                   zijn dan 30 (\u201900 1E\u2019H).\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nDayPreviousRecordLength: de lengte van het vorige DailyRecord. Is er geen vorige DailyRecord omdat deze de\n                                                   oudste is, dan is de waarde \u201800 00\u2019H (0).\n\nUitgezonderd de waarde 0, zal de waarde van DayPreviousRecordLength nooit kleiner\n                                                   zijn dan 10 (\u201900 0A\u2019H).\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nDayRecordDate: de datum waarvoor dit DailyRecord is. Dit is in het formaat JJJJMMDD.\n\nGegevenssoort: BCD\n\n\u2022 \nSessionRecords: een of meerdere SessionRecords (zie Figuur 5) voor deze dag.\n\nEen SessionRecord bevat de gegevens van de activiteiten van de chauffeur voor een\n                                             kaartsessie. Indien er meerdere kaartsessies op een dag zijn, zijn er voor die dag\n                                             ook meerdere SessionRecords. Na personaliseren bestaat er nog geen enkel SessionRecord.\n\nNaam\n\nGrootte (bytes)\n\nPointerLastActivityRecord\n\n2\n\n299\n\nPointerLastPWActivityRecord\n\n2\n\nSignatureDateTime\n\nSignatureDate\n\n8 nibbles\n\nSignatureTime\n\n6 nibbles\n\nSessionSignature\n\n256\n\nSessionCreationDateTime\n\nSessionCreationDate\n\n8 nibbles\n\nSessionCreationTime\n\n6 nibbles\n\nSystemCardNumber\n\nBoordcomputernr\n\n9 nibbles\n\nKaartvolgnummer\n\n5 nibbles\n\nKenteken\n\n6\n\nCompanyCardNumber\n\nKvKnummer\n\n12 nibbles\n\nKaartvolgnummer\n\n5 nibbles\n\nPnummer\n\n7 nibbles\n\nActivityRecords\n\nvariabel\n\nvariabel\n\nDe lengte van een SessionRecord kop (zonder de ActivityRecords) is 299 bytes.\n\nEen SessionRecord bestaat uit de volgende elementen:\n\n\u2022 \nPointerLastActivityRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data)\n                                                   van de het laatste ActivityRecord in deze SessionRecords.\n\nDe initi\u00eble waarde bij een nieuw SessionRecord (nog zonder ActivityRecords) is \u201800\n                                                   00\u2019H (0).\n\nUitgezonderd de waarde 0, zal de waarde van PointerLastActivityRecord nooit kleiner\n                                                   zijn dan 20+10+299 = 329 (\u201901 49\u2019H).\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nPointerLastPWActivityRecord: specificeert het begin van de geheugenplaats (aantal bytes vanaf het begin van EF.Driver_Activity_Data)\n                                                   van het laatste ActivityRecord met een activiteit \u201cStart pauze\u201d of \u201cStart werk\u201d.\n\nDe initi\u00eble waarde bij een nieuw SessionRecord (nog zonder ActivityRecords) is \u201800\n                                                   00\u2019H (0).\n\nZo lang er nog geen \u201cStart pauze\u201d of \u201cStart werk\u201d ActivityRecord in dit SessionRecord\n                                                   aanwezig is, blijft de waarde gelijk aan 0.\n\nUitgezonderd de waarde 0, zal de waarde van PointerLastPWActivityRecord nooit kleiner\n                                                   zijn dan 20+10+299 = 329 (\u201901 49\u2019H).\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nSignatureDateTime: het tijdstip direct voorafgaand aan het berekenen van de SessionSignature. Voor verdere\n                                                   informatie over de handtekening zetten, zie 5.4.\n\nDit veld bestaat uit twee delen:\n\n\u2013 \nSignatureDate:\n\nformaat JJJJMMDD,\n\niniti\u00eble waarde bij een nieuw SessionRecord: \u201800000000\u2019H,\n\ngegevenssoort BCD.\n\n\u2013 \nSignatureTime:\n\nformaat hhmmss (24-uurs klok)\n\niniti\u00eble waarde bij een nieuw SessionRecord: \u2018000000\u2019H,\n\ngegevenssoort BCD.\n\n\u2022 \nSessionSignature: de door de boordcomputer gezette handtekening over de gegevens zoals gespecificeerd\n                                                   in \u00a7 5.4.\n\nDe initi\u00eble waarde bij een nieuw SessionRecord is \u201congedefinieerd\u201d.\n\nGegevenssoort: OCTET_STRING(SIZE(256))\n\n\u2022 \nSessionCreationDateTime: het tijdstip waarop dit SessionRecord werd gecre\u00eberd.\n\nDit veld bestaat uit twee delen:\n\n\u2013 \nSignatureDate:\n\nformaat JJJJMMDD,\n\niniti\u00eble waarde bij een nieuw SessionRecord: de datum waarop dit SessionRecord werd\n                                                         gecre\u00eberd,\n\ngegevenssoort BCD.\n\n\u2013 \nSignatureTime:\n\nformaat hhmmss\n\niniti\u00eble waarde bij een nieuw SessionRecord: het tijdstip waarop dit SessionRecord\n                                                         werd gecre\u00eberd,\n\ngegevenssoort BCD.\n\n\u2022 \nSystemCardNumber: bestaat uit 2 delen:\n\n\u2013 \n Boordcomputernr: het nummer van de systeemkaart zoals op het moment van cre\u00ebren van dit SessionRecord\n                                                         bekend in de boordcomputer (9 digits BCD)\n\n\u2013 \nKaartvolgnummer: het volgnummer van de systeemkaart zoals op het moment van cre\u00ebren van dit SessionRecord\n                                                         bekend in de boordcomputer (5 digits BCD)\n\n\u2022 \nKenteken: het kenteken van het voertuig zoals op het moment van cre\u00ebren van dit SessionRecord\n                                                   bekend in de boordcomputer (6 bytes ASCII)\n\n\u2022 \nCompanyCardNumber: bestaat uit 2 delen:\n\n\u2013 \nKvKnummer: Kamer van Koophandel nummer van de ondernemer zoals op het moment van cre\u00ebren van\n                                                         dit SessionRecord bekend in de boordcomputer (12 digits BCD)\n\n\u2013 \nKaartvolgnummer: volgnummer van de ondernemerskaart zoals op het moment van cre\u00ebren van dit SessionRecord\n                                                         bekend in de boordcomputer (5 digits BCD)\n\n\u2022 \nPnummer: personenvervoernummer van de ondernemer zoals op het moment van cre\u00ebren van dit SessionRecord\n                                                   bekend in de boordcomputer (7 digits BCD)\n\n\u2022 \nActivityRecords: een of meerdere ActivityRecords (zie Figuur 6).\n\nEr wordt een aantal types ActivityRecords onderscheiden aan de hand van de activiteit.\n\nActiviteit\n\nType\n\nKop\n\nGegevens\n\nOpmerking\n\nactiviteit\n\nhandm.\n\nrijden\n\ntijdstip\n\nVeld 1\n\nVeld 2\n\nLogin\n\n\u201800001\u2019B\n\n\u20180\u2019B\n\n\u20180\u2019/\u20191\u2019B\n\nhh:mm:ss\n\ngeen\n\ngeen\n\nHet tijdstip waarop de BCT het inloggen constateerde.\n\n\u20181\u2019B\n\nEen login kan geen handmatig ingesteld tijdstip hebben. Deze combinatie komt dus niet\n                                                            voor.\n\n(Start) pauze\n\n\u201800010\u2019B\n\n\u20180\u2019B\n\n\u20180\u2019/\u20191\u2019B\n\nhh:mm:ss\n\ngeen\n\ngeen\n\nHet tijdstip waarop de BCT de start van de pauze constateerde. Recordvorm indien dit\n                                                            record niet het laatste ActivityRecord van de sessie is.\n\naantal secondes pauze\n\nHet tijdstip waarop de BCT de start van de pauze constateerde. Recordvorm indien dit\n                                                            record het laatste ActivityRecord van de sessie is.\n\n\u20181\u2019B\n\ngeen\n\nHet handmatig opgegeven tijdstip dat de pauze aanving. Recordvorm indien dit record\n                                                            niet het laatste ActivityRecord van de sessie is.\n\naantal secondes pauze\n\nHet handmatig opgegeven tijdstip dat de pauze aanving. Recordvorm indien dit record\n                                                            het laatste ActivityRecord van de sessie is.\n\n(Start) werk\n\n\u201800011\u2019B\n\n\u20180\u2019B\n\n\u20180\u2019/\u20191\u2019B\n\nhh:mm:ss\n\naantal secondes rijden\n\ngeen\n\nHet tijdstip waarop de BCT de start van werk constateerde. Recordvorm indien dit record\n                                                            niet het laatste ActivityRecord van de sessie is.\n\naantal secondes werk\n\nHet tijdstip waarop de BCT de start van werk constateerde. Recordvorm indien dit record\n                                                            het laatste ActivityRecord van de sessie is.\n\n\u20181\u2019B\n\ngeen\n\nHet handmatig opgegeven tijdstip dat werk aanving. Recordvorm indien dit record niet\n                                                            het laatste ActivityRecord van de sessie is.\n\naantal secondes werk\n\nHet handmatig opgegeven tijdstip dat werk aanving. Recordvorm indien dit record het\n                                                            laatste ActivityRecord van de sessie is.\n\nAfsluiting\n\n\u201800100\u2019B\n\n\u20180\u2019B\n\n\u20180\u2019/\u20191\u2019B\n\nhh:mm:ss\n\ngeen\n\ngeen\n\nreguliere Afsluiting: Het tijdstip waarop de BCT het afsluiten en aftekenen van de\n                                                            sessie constateerde.\n\nNieuwe eindtijd\n\n\u20181\u2019B\n\nhandmatige Afsluting / Nieuwe eindtijd: Het handmatig opgegeven tijdstip dat een sessie\n                                                            (\u201cwerkdag\u201d) stopte.\n\nDagovergang\n\n\u201800101\u2019B\n\n\u20180\u2019B\n\n\u20180\u2019/\u20191\u2019B\n\n23:59:59\n\ngeen\n\ngeen\n\nMiddernacht automatisch: Een dagovergang geconstateerd tijdens normale modus.\n\n\u20181\u2019B\n\nMiddernacht handmatig: Een dagovergang geconstateerd tijdens handmatige invoer.\n\nEen ActivityRecord heeft een kop van 24 bits (3 bytes) groot die de volgende elementen\n                                             bevat:\n\n\u2022 \nactiviteit: geeft het type activiteit aan (5 bits).\n\n\u2022 \nhandmatig: geeft aan of het tijdstip van de activiteit handmatig of automatisch is geboekt (1\n                                                   bit).\n\n\u2022 \nrijden: geeft aan of de activiteit tijdens het rijden of stilstaan is geboekt (1 bit).\n\n\u2022 \ntijdstip: geeft het starttijdstip van de activiteit aan in het formaat hhmmss. Dit formaat\n                                                   is als volgt opgebouwd:\n\n\u2013 \nhh: 5 bits\n\n\u2013 \nmm: 6 bits\n\n\u2013 \nss: 6 bits\n\nNoot 1: Bij de activiteit \u201cStart werk\u201d wordt een Rijtijdveld aan de kop toegevoegd. Dit\n                                             werkt als volgt:\n\n\u2022 gedurende het werk wordt volautomatisch bijgehouden hoeveel secondes er gereden worden\n                                                   (3 bytes INTEGER (unsigned)). Wanneer (na een periode van rijden gedurende werktijd)\n                                                   het aantal secondes gewijzigd is, wordt hetzelfde record opnieuw geschreven, waarbij\n                                                   de kop gelijk blijft en het aantal secondes aangepast. Dit bijwerken van rijtijd moet\n                                                   ook plaatsvinden indien de laatste keer bijwerken (meer dan) vijf minuten geleden\n                                                   was. Er wordt dus geen nieuw record aangemaakt.\n\nNoot 2: Bij zowel de activiteit \u201cStart werk\u201d als \u201cStart pauze\u201d wordt een Tijdsduurveld aan\n                                             de kop toegevoegd. Dit werkt als volgt:\n\n\u2022 gedurende het werk / de pauze wordt volautomatisch bijgehouden hoeveel secondes er\n                                                   verstreken zijn sinds de activiteit startte (3 bytes INTEGER (unsigned)). Telkens\n                                                   wanneer de auto stopt en telkens vijf minuten na de vorige vastlegging van de tijdsduur\n                                                   worden de laatste 3 bytes van hetzelfde record opnieuw geschreven, waarbij de voorgaande\n                                                   bytes gelijk blijven en het aantal secondes aangepast. Er wordt dus geen nieuw record\n                                                   aangemaakt.\n\n\u2022 Het eerstvolgende toe te voegen ActivityRecord overschrijft deze laatste 3 bytes (de\n                                                   daadwerkelijke tijdsduur van de dan voorafgaande \u201cStart werk\u201d / \u201cStart pauze\u201d activiteit\n                                                   wordt met de starttijd van de nieuwe activiteit definitief vastgelegd).\n\nNoot 3: Bij iedere toevoeging van een ActivityRecord bestaat de mogelijkheid dat er een\n                                             nieuw DailyRecord en/of nieuw SessionRecord aangemaakt moet worden. Zie hiervoor ook\n                                             \u00a7 7.5 en \u00a7 0.\n\nDe gegevens worden per dag vastgelegd en moeten minimaal 31 kalenderdagen beschikbaar\n                                             blijven op de kaart. Voor iedere dag dat er gegevens op de chauffeurskaart vastgelegd\n                                             moeten worden, wordt er een DailyRecord aangemaakt.\n\nNaast de arbeids- rij- en rusttijden zelf moet ook vastgelegd worden voor welke ondernemer\n                                             en in welk voertuig deze tijden gemaakt zijn en welke boordcomputer er gebruikt is.\n                                             Dit wordt per sessie vastgelegd in het SessionRecord.\n\nIn Figuur 7 staat een overzicht van EF.Driver_Activity_Data en hoe de verschillende\n                                             records hier onder vallen.\n\nActiviteiten van de chauffeur worden opgeslagen in ActivityRecords. In Figuur 6 worden\n                                          de verschillende typen van ActivityRecords genoemd. Het verloop van een sessie staat\n                                          in hoofdstuk 7 beschreven. Het exacte verloop van het toevoegen van een ActivityRecord\n                                          staat in \u00a7 0.\n\nElk van de navolgende subparagrafen (5.2.2 t/m 5.2.7) gaat er van uit dat de toe te\n                                             voegen activiteit niet de eerste activiteit binnen het betreffende SessionRecord is. Indien dat echter w\u00e9l het geval\n                                             is, moeten de instructies voor het overschrijven van de PointerLastActivityRecord\n                                             en de DayRecordLength velden telkens worden vervangen door de volgende:\n\n1. In het SessionRecord dient PointerLastActivityRecord gezet te worden op PointerLastSessionRecord\n                                                   + 299;\n\n2. In het huidige DailyRecord dient de DayRecordLength verhoogd te worden met de (ongecorrigeerde)\n                                                   lengte van het toe te voegen ActivityRecord:\n\n\u2013 Voor een \u201cStart werk\u201d, verhogen met 9;\n\n\u2013 Voor een \u201cStart pauze\u201d, verhogen met 6;\n\n\u2013 Voor elke andere activiteit, verhogen met 3.\n\nDe \u201cLogin\u201d activiteit geeft de werkelijke tijd aan dat de chauffeurskaart in de boordcomputer\n                                             ingebracht is en de authenticatie plaatsgevonden heeft. Dit is het login-tijdstip.\n                                             Dit staat beschreven in 7.1.\n\nBij een \u201cLogin\u201d wordt er een nieuw ActivityRecord aangemaakt.\n\nPointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.\n\nIn dit SessionRecord wordt\n\n1. PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd\n                                                   met 3 indien het huidige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\n2. het ActivityRecord \u201cLogin\u201d toegevoegd op de plaats die aangegeven wordt door de verhoogde\n                                                   PointerLastActivityRecord. Dit record bestaat uit 3 bytes (alleen een kop). De handmatig\n                                                   bit staat altijd op \u20180\u2019B.\n\n3. SessionSignature = de tussentijdse handtekening (zie 5.4).\n\nIn het huidige DailyRecord wordt\n\n1. DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels)\n                                                   vorige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\n2. Direct na het toevoegen van de \u201cLogin\u201d activiteit wordt een (automatisch) geklokte\n                                                   \u201cStart werk\u201d activiteit toegevoegd.\n\nBij een \u201cStart pauze\u201d wordt er een nieuw ActivityRecord aangemaakt.\n\nPointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.\n\nIn dit SessionRecord wordt\n\n1. PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd\n                                                   met 3 indien het huidige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\n2. PointerLastPWActivityRecord wordt gelijkgesteld aan de zojuist verhoogde PointerLastActivityRecord.\n\n3. het ActivityRecord \u201cStart pauze\u201d toegevoegd op de plaats die aangegeven wordt door\n                                                   de verhoogde PointerLastActivityRecord. Dit record bestaat uit 6 bytes (een kop +\n                                                   een tijdsduurteller), waarbij de tijdsduurteller initieel wordt gevuld met \u201800 00\n                                                   00\u2019H en daarna periodiek wordt bijgewerkt volgens Noot 2 in \u00a7 5.1.3.\n\n4. SessionSignature = de tussentijdse handtekening (zie 5.4).\n\nIn het huidige DailyRecord wordt\n\n1. DayRecordLength = oude waarde DayRecordLength + 6 (verminderd met 3 indien het (inmiddels)\n                                                   vorige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\nBij een \u201cStart werk\u201d wordt er een nieuw ActivityRecord aangemaakt.\n\n\u201cStart werk\u201d wijkt af van de andere activiteiten. Hierin wordt bijgehouden hoeveel\n                                             secondes het voertuig gereden heeft gedurende deze activiteit. Zolang de chauffeur\n                                             nog aan het werk is en het voertuig afwisselend rijdt en stilstaat, wordt iedere keer\n                                             zodra het voertuig stopt het aantal secondes dat er gereden is bijgewerkt. Er wordt\n                                             dus niet iedere keer een nieuw ActivityRecord aangemaakt.\n\nPointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.\n\nIn dit SessionRecord wordt\n\n1. PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd\n                                                   met 3 indien het huidige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\n2. PointerLastPWActivityRecord wordt gelijkgesteld aan de zojuist verhoogde PointerLastActivityRecord.\n\n3. het ActivityRecord \u201cStart werk\u201d toegevoegd op de plaats die aangegeven wordt door\n                                                   de verhoogde PointerLastActivityRecord.\n\nDit record bestaat uit een kop van 3 bytes gevolgd door 2 x 3 bytes data.\n\nDe data geeft het aantal secondes aan dat er met het voertuig gereden is en het aantal\n                                                   secondes dat deze activiteit in totaal duurde. Bij het begin van \u201cStart werk\u201d zijn\n                                                   beiden \u201800 00 00\u2019H. Deze waardes worden conform Noten 1 en 2 in \u00a7 5.1.3 tussentijds\n                                                   bijgewerkt tot er een andere activiteit plaats vindt.\n\n4. SessionSignature = de tussentijdse handtekening (zie 5.4).\n\nIn het huidige DailyRecord wordt\n\n1. DayRecordLength = oude waarde DayRecordLength + 9 (verminderd met 3 indien het (inmiddels)\n                                                   vorige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\nBij een normale afsluiting door de chauffeur, \u201cAfsluiting\u201d, wordt er een nieuw ActivityRecord\n                                             aangemaakt.\n\nPointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.\n\nIn dit SessionRecord wordt\n\n1. PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd\n                                                   met 3 indien het huidige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\n2. het ActivityRecord \u201cAfsluiting\u201d toegevoegd op de plaats die aangegeven wordt door\n                                                   de verhoogde PointerLastActivityRecord. Dit record bestaat uit 3 bytes (alleen een\n                                                   kop).\n\n3. SessionSignature = de definitieve handtekening (zie 5.4).\n\nIn het huidige DailyRecord wordt\n\n1. DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels)\n                                                   vorige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\nWanneer er bij een sessie nog activiteiten toegevoegd worden, kan het voorkomen dat\n                                             de eindtijd aangepast moet worden. Dit wordt gedaan met een \u201cNieuwe eindtijd\u201d activiteit.\n                                             Hierbij wordt er een nieuwe ActivityRecord aangemaakt.\n\nPointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.\n\nIn dit SessionRecord wordt\n\n1. PointerLastActivityRecord verhoogd met de lengte van de laatste ActivityRecord (verminderd\n                                                   met 3 indien het huidige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\n2. het ActivityRecord \u201cNieuwe eindtijd\u201d toegevoegd op de plaats die aangegeven wordt\n                                                   door de verhoogde PointerLastActivityRecord. De handmatig-bit staat hier altijd op\n                                                   \u20181\u2019B. Dit record bestaat uit 3 bytes (alleen een kop).\n\n3. SessionSignature = de definitieve handtekening (zie 5.4).\n\nIn het huidige DailyRecord wordt\n\n1. DayRecordLength = oude waarde DayRecordLength + 3 (verminderd met 3 indien het (inmiddels)\n                                                   vorige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft).\n\nWanneer er een sessie actief is, de laatstgeboekte activiteit een \u201cStart werk\u201d of\n                                             \u201cStart pauze\u201d is en:\n\n\u2022 (situatie 1) het betreft een automatische activiteit en de BCT-klok geeft 0:00:00u\n                                                   aan OF;\n\n\u2022 (situatie 2) er wordt een handmatige activiteit toegevoegd met een tijdstip op of\n                                                   na 0:00:00u van de dag volgend op het huidige DailyRecord,\n\ndan moet:\n\n\u2022 de rijtijdteller worden bijgewerkt indien de laatstgeboekte activiteit een \u201cStart\n                                                   werk\u201d betreft,\n\n\u2022 de huidige sessie gestopt worden door toevoeging van een \u201cDagovergang\u201d activiteit\n                                                   met:\n\n\u25cb het tijdstip 23:59:59u\n\n\u25cb het handmatig bit op \u20180\u2019B indien het situatie 1 betreft OF\n\n\u25cb het handmatig bit op \u20181\u2019B indien het situatie 2 betreft,\n\n\u2022 de huidige sessie worden \u201cafgetekend\u201d door de boordcomputer\n\n\u2022 EN een nieuw DailyRecord voor de volgende kalenderdag worden aangemaakt met een nieuw\n                                                   SessionRecord en een eerste ActivityRecord met\n\n\u25cb hetzelfde ActivityType als de laatstgeboekte activiteit EN\n\n\u25cb het tijdstip op 00:00:00u\n\n\u25cb het handmatig bit op \u20180\u2019B indien het situatie 1 betreft OF\n\n\u25cb het handmatig bit op \u20181\u2019B indien het situatie 2 betreft\n\nHet toevoegen van het nieuwe DailyRecord met een nieuw SessionRecord en een eerste\n                                             \u201cStart pauze\u201d of \u201cStart werk\u201d activiteit wordt beschreven in respectievelijk \u00a7 8.11,\n                                             \u00a7 8.10, \u00a7 5.2.1 en \u00a7 5.2.3 / 5.2.4. Hier wordt uitsluitend toevoeging van de \u201cDagovergang\u201d\n                                             aan het huidige SessionRecord beschreven.\n\nPointerLastSessionRecord geeft het begin van het huidige SessionRecord aan.\n\nIn dit SessionRecord wordt\n\n1. PointerLastActivityRecord verhoogd met de lengte van het laatste ActivityRecord verminderd\n                                                   met 3 omdat het huidige ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft.\n\n2. het ActivityRecord \u201cDagovergang\u201d toegevoegd op de plaats die aangegeven wordt door\n                                                   de verhoogde PointerLastActivityRecord. De handmatig-bit en het tijdstip worden gevuld\n                                                   zoals hierboven beschreven. Dit record bestaat uit 3 bytes (alleen een kop).\n\n3. SessionSignature = de definitieve handtekening (zie 5.4).\n\nIn het huidige DailyRecord blijft DayRecordLength gelijk, omdat het (inmiddels) vorige\n                                             ActivityRecord een \u201cStart werk\u201d of \u201cStart pauze\u201d betreft.\n\nNB. Indien de invoeging van de dagovergang en de nieuwe kalenderdag het gevolg is van\n                                             het toevoegen van een handmatige activiteit, dan k\u00e1n het zo zijn dat er meer dan \u00e9\u00e9n\n                                             kalenderdag tussen de huidige activiteit en de toe te voegen activiteit bestaat. Indien\n                                             dat zo blijkt te zijn dan dienen de instructies in deze paragraaf te worden herhaald\n                                             voor iedere betreffende (kalender)dagovergang.\n\nBij lees- en schrijfacties (Read Binary en Update Binary) dient met de volgende punten\n                                          rekening te worden gehouden:\n\n1. EF.Driver_Activity_Data kan records bevatten vanaf positie \u201800 14\u2019H tot aan het eind\n                                                (Length_EF.Driver_Activity_Data). De eerste 20 bytes van EF.Driver_Activity_Data worden\n                                                in beslag genomen worden door twee 16-bits pointers en een 16-bytes veld voor het\n                                                chauffeurskaartnummer.\n\n2. Wanneer er voor een toevoeging niet meer voldoende ruimte aan het eind van EF.Driver_Activity_Data\n                                                is, wordt eerst de resterende ruimte benut en daarna gaat het toevoegen verder vanaf\n                                                het begin van de EF.Driver_Activity_Data. Dit is dan vanaf positie \u201800 14\u2019H.\n\n3. De lengte van een te lezen of te schrijven record kan nooit langer zijn dan Length_EF.Driver_Activity_Data\n                                                \u2013 20 (\u201814\u2019H).\n\n4. De offset bij een Read Binary of Update Binary (Pointer_1) moet kleiner zijn dan Length_EF.Driver_Activity_Data.\n                                                Indien dit niet het geval is, moet de offset vervangen worden door de Pointer_1 \u2013\n                                                Length_EF.Driver_Activity_Data + 20 (\u201814\u2019H).\n\n5. Indien bij een Read Binary de offset (Pointer_1) + het verwachte aantal bytes in de\n                                                response (Length_1) groter is dan Length_EF.Driver_Activity_Data, dan moet de Read\n                                                Binary in twee\u00ebn gesplitst worden: 1 Read Binary tot aan het eind van EF.Driver_Activity_Data\n                                                en 1 Read Binary vanaf positie \u201800 14\u2019H tot aan Pointer_1 + Length_1 \u2013 Length_EF.Driver_Activity_Data\n                                                + 20 (\u201814\u2019H).\n\n6. Indien bij een Update Binary de offset (Pointer_1) + het aantal weg te schrijven bytes\n                                                (Length_1) groter is dan Length_EF.Driver_Activity_Data, dan moet de Update Binary\n                                                in twee\u00ebn gesplitst worden: 1 Update Binary tot aan het eind van EF.Driver_Activity_Data\n                                                en 1 Update Binary vanaf positie \u201800 14\u2019H tot aan Pointer_1 + Length_1 \u2013 Length_EF.Driver_Activity_Data\n                                                + 20 (\u201814\u2019H).\n\n7. Bij een Update Binary bestaat de mogelijkheid dat de oudste dagregistratie overschreven\n                                                wordt. Dit is het geval wanneer data voorbij PointerOldestDayRecord geschreven zou\n                                                worden. Hier moet dus bij iedere schrijfactie op getest worden.\n\nOm te voorkomen dat voorbij PointerOldestDayRecord geschreven wordt, moet het oudste\n                                                DailyRecord weggehaald worden.\n\nDit wordt op de volgende manier gedaan:\n\n1. PointerOldestDayRecord wijst naar het oudste DailyRecord. In dit DailyRecord staat\n                                                      de lengte van dit record (DayRecordLength). Uit deze pointer en lengte kan de positie\n                                                      van het volgende DailyRecord bepaald worden.\n\n2. In dit volgende DailyRecord wordt de PreviousDayRecordLength op \u201800 00\u2019H gezet.\n\n3. PointerOldestDayRecord wordt op de positie van dit volgende DailyRecord gezet.\n\n4. Wanneer er nog niet genoeg ruimte is voor de toevoeging, moeten de bovenstaande punten\n                                                      herhaald worden.\n\nOm de integriteit van gegevens te waarborgen, worden digitale handtekeningen gebruikt.\n                                          Er worden twee soorten digitale handtekeningen onderscheiden:\n\n1. De handtekening die door de chauffeurskaart over de gegevens van de kaartsessie gezet\n                                                wordt in de boordcomputer.\n\n2. De handtekening die door de boordcomputer gezet wordt over de kaartsessie gegevens\n                                                op de chauffeurskaart.\n\nIn dit document gaat het om de tweede soort, waarbij de handtekeningen op de chauffeurskaart\n                                          worden opgeslagen. De handtekeningen die op de boordcomputer opgeslagen worden, worden\n                                          hier verder buiten beschouwing gelaten.\n\nDe digitale handtekening wordt berekend over het DriverCardNumber, de DayRecordDate\n                                          en een deel van het SessionRecord (zie 5.1.2) en wordt opgeslagen in het veld SessionSignature\n                                          in het betreffende SessionRecord. Daarbij worden de mogelijke vorige SignatureDateTime\n                                          en handtekening in dit SessionRecord overschreven. Het te ondertekenen DriverCardNumber\n                                          is een 16-karakter PrintableString zoals die aansluitend op het inloggen van de chauffeur\n                                          door de boordcomputer uit de eerste 16 bytes van het subject.serialNumber van het\n                                          authenticiteitcertificaat van de chauffeurskaart is gelezen. De kopie van het DriverCardNumber die is opgeslagen in bytes \u201800 04\u2019H t/m \u201800 13\u2019H van EF.Driver_Activity_Data\n                                          mag NIET worden gebruikt bij de berekening van de handtekening.\n\nOm het verlies van gegevens zoveel mogelijk te voorkomen wanneer de chauffeurskaart\n                                          voortijdig uitgenomen wordt, wordt er na iedere toevoeging van een ActivityRecord (zie 5.1.3) een digitale handtekening berekend en opgeslagen.\n\nBij de berekening van de handtekening wordt van het laatst toegevoegde ActivityRecord\n                                          alleen de kop van 3 bytes meegenomen. De reden hiervoor is gelegen in de activiteiten\n                                          \u201cStart werk\u201d en \u201cStart pauze\u201d. De 6 respectievelijk 3 gegevensbytes die bij deze activiteitsoorten\n                                          horen worden te vaak bijgewerkt (voor het telkens herberekenen van handtekeningen)\n                                          en de laatste 3 gegevensbytes worden sowieso overschreven door de vervolgactiviteit.\n                                          De rijtijdteller van een \u201cStart werk\u201d activiteit wordt hiermee pas meegenomen in de\n                                          handtekening nadat een vervolgactiviteit wordt gestart.\n\nOm een handtekening te kunnen berekenen, moet eerst de SignatureDateTime worden bijgewerkt\n                                          met de huidige datum en tijd volgens BCT-klok, dan moet een hashcode berekend worden.\n                                          Deze hashcode wordt dan gebruikt als input voor het berekenen van de handtekening.\n                                          De gegevens voor het berekenen van de hashcode moeten in de hieronder genoemde volgorde\n                                          staan:\n\n1. DriverCardNumber\n\n16 bytes ASCII\n\n2. DayRecordDate\n\n4 bytes BCD\n\n3. SessionCreationDateTime\n\n4 + 3 bytes BCD\n\n4. SystemCardNumber\n\n4\u00bd + 2\u00bd bytes BCD\n\n5. Kenteken\n\n6 bytes ASCII\n\n6. CompanyCardNumber\n\n6 + 2\u00bd bytes BCD\n\n7. Pnummer\n\n3\u00bd bytes BCD\n\n8. ActivityRecords*)\n\nvariable\n\n9. PointerLastActivityRecord\n\n2 bytes INTEGER\n\n10. PointerLastPWActivityRecord\n\n2 bytes INTEGER\n\n11. SignatureDateTime\n\n4 + 3 bytes BCD\n\n*) Van het laatste ActivityRecord wordt alleen de kop (3 bytes) meegenomen.\n\nDe berekening van de handtekening wordt volledig door de boordcomputer uitgevoerd\n                                          en gebeurt als volgt:\n\n\u2022 Over de gegevens, als hierboven vermeld, wordt met behulp van de private sleutel voor\n                                                authenticiteit van de boordcomputer een handtekening gegenereerd volgens PKCS#1 v1.5\n                                                met SHA-256.\n\n\u2022 De handtekening wordt opgeslagen in het SessionSignature veld van het huidige SessionRecord.\n\nNB. Telkens bij het berekenen van de SHA-256 hash dient de boordcomputerlogica het eerste\n                                          en grootste deel van de berekening (de hash over de data vanaf het DriverCardNumber\n                                          t/m de ActivityRecords) uit te voeren, waarna het laatste deel van de hashberekening\n                                          (over de PointerLastActivitityRecord t/m de SignatureDateTime) door de systeemkaart\n                                          dient te worden berekend. Ook de PKCS#1 v1.5 handtekening dient door de systeemkaart\n                                          te worden berekend.\n\nNB2. Met behulp van het certificaat behorende bij de private sleutel voor authenticiteit\n                                          van de boordcomputer (het boordcomputercertificaat) kan gecontroleerd worden of de\n                                          gegevens in een SessionRecord authentiek zijn. Behalve het boordcomputercertificaat\n                                          en het SessionRecord zelf, zijn voor zo\u2019n validatie het DriverCardNumber en de DayRecordDate\n                                          benodigd. Die twee gegevens staan elders in EF.Driver_Activity_Data opgeslagen. Welk\n                                          boordcomputercertificaat voor een bepaalde SessionRecord-validatie moet worden gebruikt,\n                                          kan worden achterhaald door het SystemCardNumber in de SessionRecord-kop uit te lezen.\n\nNB3. Indien bij het valideren van de SessionRecord-data de betreffende EF.BCT_Certificates\n                                          aanwezig is en het betreffende boordcomputercertificaat is daarin ook (nog) aanwezig,\n                                          kan de validatie direct worden uitgevoerd. Indien het betreffende boordcomputercertificaat\n                                          niet (meer) in EF.BCT_Certificates is opgeslagen of indien EF.BCT_Certificates niet\n                                          voorhanden is, dan kan het betreffende boordcomputercertificaat via de Kaartuitgever\n                                          worden verkregen.\n\nDe certificaten van de boordcomputer die gebruikt zijn bij het berekenen van de handtekeningen\n                                       op de chauffeurskaart worden opgeslagen in EF.BCT_Certificates. Hierin is plaats voor\n                                       de systeemkaartcertificaten van de 3 verschillende boordcomputers waarin de chauffeurskaart\n                                       het laatst is gebruikt.\n\nEen boordcomputer dient een bestuurder (tijdig) te waarschuwen dat de momenteel op\n                                       de chauffeurskaart opgeslagen arbeids-, rij- en rusttijden moeten worden ge\u00ebxporteerd\n                                       (ook wel \u201cgedownload\u201d). Aan EF.BCT_Certificates is daarom een extra gegevensstructuur\n                                       toegevoegd die vermeldt wanneer en naar welke boordcomputer welke dailyrecords zijn\n                                       ge\u00ebxporteerd.\n\nNaam\n\nGrootte (bytes)\n\nRank\n\n3\n\nIndex\n\n3 x 7\n\nCertificates\n\n3 x 2100\n\nIndexOldestDL\n\n1\n\nDownloadLogs\n\n8 x 33\n\nFILLER\n\n11\n\nTotaal\n\n6600\n\nEF.BCT_Certificates is opgebouwd uit de volgende elementen:\n\n\u2022 \nRank: Hierin wordt aangegeven in welke volgorde (van meest naar minst recent) de navolgende\n                                                certificaten zijn gebruikt. Iedere byte correspondeert met een van de certificaten\n                                                in Certificates (byte 1 <-> certificaat 1 en dergelijke). De (initi\u00eble) waarde 0 geeft\n                                                aan dat er geen certificaat op die plaats staat en de waarde 1 \u2013 3 hoe recent het\n                                                bijbehorende certificaat is (waarbij de waarde 1 het meest recent is).\n\nGegevenssoort: INTEGER (unsigned)\n\n\u2022 \nIndex: Een index bestaat uit een systeemkaartnummer (het boordcomputernummer (BCD-9) gevolgd\n                                                door het kaartvolgnummer (BCD-5)), voor ieder opgeslagen certificaat (3x). Iedere\n                                                index correspondeert met een van de certificaten in Certificates (index 1 <-> certificaat\n                                                1 en verder).\n\nDe initi\u00eble waarde voor iedere index is \u201800 00 00 00 00 00 00\u2019.\n\nGegevenssoort: BCD\n\n\u2022 \nCertificates: Hierin worden de 3 meest recente certificaten van boordcomputers opgeslagen. In Rank\n                                                is te vinden hoe recent een bepaald certificaat is en in Index staat het bijbehorende\n                                                boordcomputernummer en kaartvolgnummer. Initieel zijn de certificaten gevuld met nullen\n                                                (\u201800\u2019).\n\nIndien een certificaat korter is dan 2100 bytes, wordt de resterende ruimte opgevuld\n                                                met \u201800\u2019-bytes.\n\nGegevenssoort: OCTET STRING\n\nNB. Een certificaat is een ASN.1 DER gecodeerde TLV-gegevensstructuur die voor BCT certificaten\n                                                begint met een 8-bits Tag (30h), een byte dat aangeeft dat er 2 lengte bytes volgen\n                                                (82h) en een 16-bits Length en gevolgd wordt door een Value van zoveel bytes als aangegeven\n                                                door Length.\n\n\u2022 \nIndexOldestDL: Hierin wordt aangegeven welke van de navolgende (8) DownloadLog items het oudste\n                                                is en dus als eerste overschreven zal worden. Initieel zal dit veld gevuld worden\n                                                met de waarde 0 (\u201800\u2019H) en de maximale waarde zal 7 (\u201807\u2019H) zijn (0 wijst naar DownloadLog_1\n                                                en 7 wijst naar DownloadLog_8). Na het overschrijven van DownloadLog_8 zal IndexOldestDL\n                                                gereset moeten worden naar 0.\n\nDe initiele vulling zal volledig uit nullen (\u201800\u2019H) bestaan.\n\nGegevenssoort: OCTET STRING\n\n\u2022 \nDownloadLogs: Hierin wordt informatie bijgehouden van de 8 meest recente keren dat de bestuurder\n                                                de inhoud van EF.Driver_Activity_Data naar een boord\u00accomputer heeft gedownload. Elk\n                                                van deze log items (DownloadLog_1 t/m DownloadLog_8) bestaat uit 33 bytes.\n\nGegevenssoort: INTEGER (unsigned)\n\nIn Figuur 9 wordt een overzicht van EF.BCT_Certificates gegeven met de initi\u00eble waardes.\n\nPositie\n\nGegevens\n\nBytes\n\nBenaming\n\n00 00\n\n00\n\n1\n\nRank_1\n\nRank\n\n00 01\n\n00\n\n1\n\nRank_2\n\n00 02\n\n00\n\n1\n\nRank_3\n\n00 03\n\n00 \u2013 00\n\n7\n\nIndex_1\n\nIndex\n\n00 0A\n\n00 \u2013 00\n\n7\n\nIndex_2\n\n00 11\n\n00 \u2013 00\n\n7\n\nIndex_3\n\n00 18\n\n00 \u2013 00\n\n2100\n\nCertificate_1\n\nCertificates\n\n08 4C\n\n00 \u2013 00\n\n2100\n\nCertificate_2\n\n10 80\n\n00 \u2013 00\n\n2100\n\nCertificate_3\n\n18 B4\n\n00\n\n1\n\nIndexOldestDL\n\nIndexOldestDL\n\n18 B5\n\n00 \u2013 00\n\n33\n\nDownloadLog_1\n\nDownloadLogs\n\n18 D6\n\n00 \u2013 00\n\n33\n\nDownloadLog_2\n\n18 F7\n\n00 \u2013 00\n\n33\n\nDownloadLog_3\n\n19 18\n\n00 \u2013 00\n\n33\n\nDownloadLog_4\n\n19 39\n\n00 \u2013 00\n\n33\n\nDownloadLog_5\n\n19 5A\n\n00 \u2013 00\n\n33\n\nDownloadLog_6\n\n19 7B\n\n00 \u2013 00\n\n33\n\nDownloadLog_7\n\n19 9C\n\n00 \u2013 00\n\n33\n\nDownloadLog_8\n\n19 BD\n\n00 \u2013 00\n\n11\n\nFILLER\n\nFILLER\n\n19 C8\n\nend of file (6600 bytes totaal)\n\nNoot: Positie en gegevens zijn in hexadecimale notatie weergegeven\n\nNoot: CertLength = 2100 (\u201808 34\u2019H)\n\nDe opbouw van een DownloadLog_X gegevensstructuur is opgenomen in de onderstaande\n                                          figuur.\n\nNaam\n\nGrootte\n\nDownloadLog_X\n\n33 bytes\n\nCarAndCompany\n\n25 bytes\n\nSystemCardNumber\n\n7 bytes\n\nBoordcomputernr\n\n9 nibbles\n\nKaartvolgnummer\n\n5 nibbles\n\nKenteken\n\n6 bytes\n\nCompanyCardNumber\n\n17 nibbles\n\nKvKnummer\n\n12 nibbles\n\nKaartvolgnummer\n\n5 nibbles\n\nPnummer\n\n7 nibbles\n\nDownloadPeriod\n\n8 bytes\n\nOldestDate\n\n8 nibbles\n\nDownloadDate\n\n8 nibbles\n\nEen kaartsessie is de periode tussen het ingeven van de chauffeurskaart en het wegschrijven\n                                       van de afsluitende gegevens op de chauffeurskaart door de boordcomputer. In Figuur\n                                       10 is het overzicht van een kaartsessie weergegeven.\n\nDe wijzigingen in de arbeids- rij- en rusttijden worden tijdens een kaartsessie op\n                                       de chauffeurskaart opgeslagen in ActivityRecords (zie Figuur 6 en paragrafen 5.2 en\n                                       0). Hieronder wordt aangegeven welke informatie op welk ogenblik opgeslagen wordt.\n                                       Voor voorbeelden van kaartsessies wordt verwezen naar Bijlage A.\n\nHet begin van een kaartsessie gaat als volgt:\n\n1. De chauffeurskaart wordt in de boordcomputer ingebracht en er vindt een authenticatie\n                                                van de chauffeurskaart plaats. Zie hiervoor \u00a7 0. Dit ogenblik bepaalt het login-tijdstip\n                                                wat in stap 5 als activiteitrecord wordt toegevoegd.\n\n2. Direct na het inloggen moet worden geverifieerd of in posities \u201800 04\u2019H t/m \u201800 13\u2019H\n                                                van de EF.Driver_Activity_Data het chauffeurskaartnummer nog steeds overeenstemt met\n                                                het chauffeurskaartnummer zoals dat in (de eerste 16 bytes van) het subject.serialNumber\n                                                van het authenticiteitcertificaat is opgeslagen. Indien het niet meer overeenstemt,\n                                                dienen de genoemde byteposities in EF.Driver_Activity_Data te worden bijgewerkt en\n                                                dient de gebruiker te worden gewaarschuwd.\n\nOok dient in deze stap de daadwerkelijke grootte van EF.Driver_Activity_Data te worden\n                                                vastgesteld. Zie hiervoor \u00a7 9.5.\n\n3. Er wordt dan gecontroleerd of het certificaat van deze boordcomputer al op deze chauffeurskaart\n                                                staat en zo niet, dan wordt dit toegevoegd (zie 6 Gegevens op chauffeurskaart (EF.BCT_Certificates)).\n                                                In beide gevallen wordt dit certificaat als meest recente gemarkeerd. Eventueel andere,\n                                                reeds bestaande certificaatentries worden gemarkeerd als minder recente. Indien er\n                                                geen ruimte meer is vervalt de oudste entry.\n\n4. Er wordt gecontroleerd of er op de boordcomputer nog een geblokkeerde sessie voor\n                                                deze kaart is (zie 7.4):\n\n\u2013 Is er geen geblokkeerde sessie voor deze kaart op de boordcomputer of is de kaart\n                                                      inmiddels in een andere boordcomputer gebruikt, dan wordt gecontroleerd of op de kaart\n                                                      de vorige sessie correct afgesloten was.\n\nHiervoor moet de laatste activiteit in het huidige SessionRecord \u201cAfsluiting\u201d, \u201cNieuwe\n                                                      eindtijd\u201d of \u201cDagovergang\u201d zijn. Is dit niet het geval, dan wordt de gebruiker er\n                                                      op geattendeerd dat deze vorige sessie niet correct was afgesloten.\n\n\u2013 Is de laatste activiteit in het laatste SessionRecord een \u201cAfsluiting\u201d, \u201cDagovergang\u201d\n                                                      of \u201cNieuwe eindtijd\u201d en wijst de PointerLastPWActivityRecord van dat SessionRecord\n                                                      naar een \u201cStart pauze\u201d activiteit, dan is er iets bijzonders aan de hand. Een arbeidsperiode\n                                                      lijkt dan te eindigen met een pauze. In dit geval dient de boordcomputer de bestuurder\n                                                      er extra op te attenderen dat er mogelijk een handmatige aanvulling / correctie benodigd\n                                                      is die met stap 5 kan worden gedaan.\n\n\u2013 Is er nog een geblokkeerde sessie voor deze kaart op de boordcomputer en is de kaart\n                                                      tussentijds niet in een andere boordcomputer gebruikt, dan vervalt de blokkering en\n                                                      wordt de sessie vervolgd.\n\n5. Zijn er, tussen de laatst op de kaart geboekte \u201cStart werk\u201d of \u201cStart pauze\u201d activiteit\n                                                en het onthouden login-tijdstip, nog activiteiten toe te voegen, dan kan dat nu gebeuren\n                                                (zie vooral ook het tweede aandachtsstreepje van de vorige stap).\n\nBepaal hiertoe de start-datumtijd en de eventuele eind-datumtijd van die laatstgeboekte\n                                                \u201cStart pauze\u201d of \u201cStart werk\u201d activiteit, waarbij de eindtijd hetzij kan worden gelezen\n                                                uit de afsluitingsactiviteit die volgt op de \u201cStart werk\u201d / \u201cStart pauze\u201d, hetzij\n                                                kan worden berekend m.b.v. de tijdsduurteller van de \u201cStart werk\u201d / \u201cStart pauze\u201d\n                                                zelf.\n\nIn dat geval,\n\n\u2013 Presenteer de laatstgeboekte \u201cStart werk\u201d / \u201cStart pauze\u201d inclusief diens uitgelezen\n                                                      start- en eind-datumtijd.\n\n\u2013 Dan kan er een \u201cStart werk\u201d of een \u201cStart pauze\u201d activiteit toegevoegd worden.\n\nDe standaard (start)datumtijd hiervoor is de eind-datumtijd van de laatste \u201cStart\n                                                      werk\u201d of \u201cStart pauze\u201d activiteit; dit kan de gebruiker veranderen in een waarde tussen\n                                                      minimaal de start-datumtijd van die laatste \u201cStart werk\u201d of \u201cStart pauze\u201d activiteit\n                                                      en maximaal het login-tijdstip. De \u201chandmatig\u201d-bit wordt op \u20181\u2019B gezet.\n\nEen start die eerder is dan het einde van de vorige \u201cStart werk\u201d of \u201cStart pauze\u201d\n                                                      activiteit, zal die eerdere activiteit geheel of gedeeltelijk veranderen.\n\nEen start die gelijk is dan het einde van de vorige \u201cStart werk\u201d of \u201cStart pauze\u201d\n                                                      activiteit, zal direct op die eerdere activiteit aansluiten.\n\nEen start die later is dan het einde van de vorige \u201cStart werk\u201d of \u201cStart pauze\u201d activiteit,\n                                                      zal een rustperiode inlassen.\n\nGebruik voor het toevoegen van deze handmatige activiteit de logica beschreven in\n                                                      \u00a7 0 en geef daarbij door of een kaartsessie al dan niet gecontinueerd mocht worden.\n\n\u2013 Ook kan er voor gekozen worden om handmatig een \u201cNieuwe eindtijd\u201d op te geven.\n\nOok daarvan kan de datumtijd ingesteld worden tussen minimaal de start-datumtijd van\n                                                      de laatste activiteit en maximaal het login-tijdstip.\n\nDe \u201chandmatig\u201d-bit wordt op \u20181\u2019B gezet.\n\nEen nieuw einde dat gelijk is aan de start van de vorige \u201cStart werk\u201d of \u201cStart pauze\u201d\n                                                      activiteit, zal die eerdere activiteit effectief verwijderen.\n\nEen nieuw einde tussen de start en het (momenteel geldende) einde van de vorige \u201cStart\n                                                      werk\u201d of \u201cStart pauze\u201d activiteit, zal die eerdere activiteit effectief inkorten.\n\nEen nieuw einde later dan het (momenteel geldende) einde van de vorige activiteit,\n                                                      zal die eerdere activiteit effectief verlengen.\n\nGebruik voor het toevoegen van deze handmatige activiteit de logica beschreven in\n                                                      \u00a7 0 en geef daarbij door of een kaartsessie al dan niet gecontinueerd mocht worden.\n\n\u2013 Toevoegen kan meerdere keren uitgevoerd worden. De laatst (handmatig) toegevoegde\n                                                      activiteit geldt dan telkens als de \u201cvorige\u201d.\n\n\u2013 De mogelijkheid bestaat dat dit toevoegen over meerdere dagen gaat. In dat geval zal\n                                                      de logica beschreven in \u00a7 0 de eventuele aanmaak van nieuwe DailyRecords en/of SessionRecords\n                                                      verzorgen.\n\n\u2013 Hoeft er niets meer toegevoegd te worden, dan kan met de volgende stap worden verder\n                                                      gegaan.\n\n6. Vervolgens wordt het login-tijdstip middels een \u201cLogin\u201d activiteit toegevoegd (zie\n                                                5.2.1), waarna direct een \u201cStart werk\u201d (zie 5.2.4) zal worden toegevoegd. Beide ActivityRecords\n                                                zullen de handmatig bit op \u20180\u2019B hebben staan.\n\nook nu zullen de toevoegingen gedaan worden conform de logica beschreven in \u00a7 0\n\nVanaf dit punt begint de reguliere vastlegging van activiteiten.\n\nTijdens een kaartsessie zijn er twee activiteiten mogelijk: \u201cStart pauze\u201d en \u201cStart\n                                          werk\u201d. Voor het toevoegen van deze activiteiten, zie 5.2.1 respectievelijk 5.2.4.\n\n\u201cStart werk\u201d moet regelmatig bijgewerkt worden met het aantal secondes dat er met\n                                          het voertuig gereden is (zie Noot 1 in \u00a7 5.1.3). \u201cStart werk\u201d en \u201cStart pauze\u201d moeten\n                                          regelmatig bijgewerkt worden met het aantal secondes dat de betreffende activiteit\n                                          duurt (zie Noot 2 in \u00a7 5.1.3).\n\nBij het beeindigen van een kaartsessie dient de chauffeur de kaartsessie af te sluiten,\n                                          voordat hij de chauffeur zijn kaart uit de boordcomputer neemt. Zou hij de sessie\n                                          niet afsluiten wordt deze geblokkeerd.\n\nBij het afsluiten van een kaartsessie wordt een \u201cAfsluiting\u201d activiteit toegevoegd,\n                                          zie 5.2.5.\n\nDirect nadat de \u201cAfsluiting\u201d activiteit is toegevoegd en nog voordat de chauffeur\n                                          zijn kaart uitneemt, dient de boordcomputer:\n\n1. in EF.BCT_Certificates het DownloadLog controleren en vast te stellen of de laatste\n                                                download van EF.Driver_Activity_Data naar een boordcomputer al dan niet te lang geleden\n                                                is of lijkt. Indien dat zo blijkt te zijn, dan dient de boordcomputer de bestuurder\n                                                hierop te attenderen;\n\n2. de chauffeur de gelegenheid te bieden om de volledige inhoud van EF.Driver_Activity_Data\n                                                naar het geheugen van de boordcomputer te downloaden. Indien de chauffeur hierop ingaat,\n                                                dan dient de boordcomputer:\n\na. Aan de chauffeur een waarschuwing te tonen dat de kaart (nog) niet mag worden uitgenomen;\n\nb. De volledige inhoud van EF.Driver_Activity_Data te downloaden naar het geheugen van\n                                                      de boordcomputer;\n\nc. In EF.BCT_Certificates het DownloadLog bij te werken;\n\nd. Aan de chauffeur te melden dat de kaart nu mag worden uitgenomen.\n\nHet is mogelijk dat de chauffeur zijn kaart uit de boordcomputer haalt zonder dat\n                                          hij de kaartsessie afgesloten heeft. In dat geval is er dus geen ActivityRecord aangemaakt\n                                          voor het afsluiten van de kaartsessie. De boordcomputer constateert dat de kaart is\n                                          uitgenomen zonder dat de sessie is afgesloten en blokkeert deze kaartsessie.\n\nDe op de boordcomputer geblokkeerde kaartsessie wordt be\u00ebindigd door:\n\n\u2022 binnen 60 minuten dezelfde chauffeurskaart weer in te brengen in de boordcomputer.\n                                                Zijn er in de tussentijd activiteiten op de boordcomputer geregistreerd geweest, dan\n                                                worden die allereerst op de chauffeurskaart bijgewerkt.\n\n\u2022 binnen 60 minuten dezelfde chauffeurskaart weer in te brengen en er blijkt dat de\n                                                kaart in de tussentijd in een andere boordcomputer heeft gezeten. Eventuele tussentijdse\n                                                activiteiten die op deze boordcomputer waren geregistreerd worden niet meer op de\n                                                kaart geplaatst.\n\n\u2022 een andere boordcomputerkaart in te brengen, uitgezonderd een inspectiekaart.\n\n\u2022 een time-out van 60 minuten.\n\nDe eerstvolgende keer dat een chauffeurskaart met een niet afgesloten kaartsessie\n                                          weer in een boordcomputer wordt ingebracht, krijgt de chauffeur een melding dat de\n                                          kaartsessie niet goed afgesloten was. De uitzondering hierop is het eerste punt hierboven,\n                                          waarbij de kaartsessie voortgezet wordt.\n\nIn alle gevallen wordt na het inloggen de chauffeur de mogelijkheid geboden voor het\n                                          handmatig toevoegen van activiteiten die hebben plaatsgevonden tussen de laatstgeboekte\n                                          \u201cStart werk\u201d of \u201cStart pauze\u201d activiteit en het login-tijdstip. Pas nadat dergelijke\n                                          handmatige boekingen op de kaart zijn bijgeschreven, wordt het Login-tijdstip vastgelegd\n                                          door het toevoegen van een \u201cLogin\u201d ActivityRecord die aangeeft wanneer de kaart weer\n                                          in de boordcomputer ingebracht is (zie 5.2.1). Direct aansluitend wordt (met hetzelfde\n                                          tijdstempel) een \u201cStart werk\u201d activiteit toegevoegd.\n\nHet is mogelijk dat een kaartsessie actief is om 12 uur \u2019s nachts. Ook kan dat het\n                                          geval blijken te zijn tijdens het handmatig invoegen van activiteiten (de laatst geboekte\n                                          activiteit blijkt \u201cStart werk\u201d of \u201cStart pauze\u201d te zijn en de toe te voegen activiteit\n                                          blijkt te moeten starten in de kalenderdag na die van zijn voorganger). Omdat de activiteiten\n                                          per dag opgeslagen worden, moet de kaartsessie hier gesplitst worden.\n\nHiervoor wordt\n\n1. Indien de huidige activiteit een (automatische) \u201cStart werk\u201d is, het aantal secondes\n                                                rijden bijgewerkt.\n\n2. Een interne kopie gemaakt van de huidige activiteit (\u201cStart werk\u201d of \u201cStart pauze\u201d).\n                                                In die kopie wordt het tijdstipveld op 00:00:00 gezet en de handmatig bit dient te\n                                                reflecteren of deze dagovergang tijdens het handmatig bijwerken van de administratie\n                                                dan wel tijdens de normale operatie van de boordcomputer werd geconstateerd.\n\n3. Een \u201cDagovergang\u201d activiteit toegevoegd aan het huidige SessionRecord om 23:59:59\n                                                (zie 5.2.7). Het handmatig bit dient ook hierbij te reflecteren of deze dagovergang\n                                                tijdens het handmatig bijwerken van de administratie dan wel tijdens de normale operatie\n                                                van de boordcomputer werd geconstateerd.\n\n4. De interne kopie van de voort te zetten activiteit toegevoegd op de eerstvolgende\n                                                kalenderdag. Omdat dit de eerste activiteit in die volgende kalenderdag betreft, worden\n                                                er eerst een nieuw DailyRecord en SessionRecord aangemaakt.\n\n5. Indien de splitsing het gevolg van een handmatige toevoeging was:\n\na. wordt eerst gecontroleerd of die toevoeging wellicht n\u00f3g een of meer kalenderdagen\n                                                      vooruit betreft en indien dat zo is, worden de bovenstaande stappen herhaald,\n\nb. wordt pas daarna de opgegeven activiteit toegevoegd.\n\nDe commando-antwoord paren (zie hoofdstuk 9) vormen het laagste niveau van communicatie\n                                       met de boordcomputerkaarten.\n\nMet behulp van \u00e9\u00e9n of meerdere commando\u2019s kunnen functies benoemd worden die een logische\n                                       actie vertegenwoordigen, zoals het wijzigen of deblokkeren van een pincode.\n\nBij deze functies moeten ook de punten uit 5.3 (Algemene opmerkingen bij lezen en\n                                       schrijven) in acht worden genomen.\n\nNaam\n\nGebruik\n\nChangePIN\n\nBoordcomputerkaarten\n\nInput gegevens\n\nOude PIN || Nieuwe PIN\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van Change Reference Data, afhankelijk van de implementatie\n\nVoor het wijzigen van een PIN moet de oude PIN bekend zijn, anders is dit niet mogelijk.\n\nVoor de oude en nieuwe PIN wordt het PIN formaat 2 gebruikt. Dit is 8 bytes lang en\n                                          is als volgt opgebouwd:\n\nC\n\nN\n\nP\n\nP\n\nP\n\nP\n\nP/F\n\nP/F\n\nP/F\n\nP/F\n\nP/F\n\nP/F\n\nP/F\n\nP/F\n\nF\n\nF\n\nWaarin:\n\nNaam\n\nWaarde\n\nC\n\nControle veld\n\n4 bits binair getal \u20180010\u2019B\n\nN\n\nPIN lengte\n\n4 bits binair getal tussen \u20180100\u2019B en \u20181100\u2019B\n\nP\n\nPIN cijfer\n\n4 bits binair getal tussen \u20180000\u2019B en \u20181001\u2019B\n\nP/F\n\nPIN cijfer / Vulteken\n\nAfhankelijk van PIN lengte\n\nF\n\nVulteken\n\n4 bits binair getal \u20181111\u2019B\n\nDe PIN is dus maximaal 12 cijfers lang.\n\nHet gebruikte commando is Change Reference Data, waarbij de PIN reference de waarde\n                                          \u201801\u2019H heeft en oude PIN || nieuwe PIN als data meegegeven wordt.\n\nNaam\n\nChangeSMKeySet\n\nGebruik\n\nSysteemkaart\n\nInput gegevens\n\nNieuwe Key Set\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van Put Data (SDO), afhankelijk van de implementatie\n\nOp de systeemkaart mag deze functie alleen uitgevoerd worden onder beveiligde gegevensoverdracht\n                                          (zie Hoofdstuk 4).\n\nVoor het wijzigen van een SM key set moet er een Secure Messaging kanaal bestaan en\n                                          daarmee moet de oude SM key set bekend zijn, anders is dit niet mogelijk.\n\nHet gebruikte commando is Put Data, waarbij de nieuwe (symmetrische) key set als data\n                                          meegegeven wordt. Het volledige data veld heeft de vorm\n\n\u201870 2A BF 8A 03 26 A2 24 90 10\u2019 || Kmac || \u201891 10\u2019 || Kenc\n\nwaarbij Kmac en Kenc de 16 bytes sleutels zijn voor de MAC resp. de ENC.\n\nNaam\n\nDeblockPIN\n\nGebruik\n\nBoordcomputerkaarten\n\nInput gegevens\n\nGeen\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van Reset Retry Counter, afhankelijk van de implementatie\n\nHierbij wordt de bestaande PIN gedeblokkeerd.\n\nHet gebruikte commando is Reset Retry Counter, waarbij P1 de waarde \u201803\u2019H heeft en\n                                          P2 (de PIN reference) de waarde \u201801\u2019H heeft.\n\nVoorafgaand aan dit commando moet een succesvol Verify commando uitgevoerd worden\n                                          met P1 = \u201800\u2019H en P2 = \u201802\u2019H (de PUK reference). Voor de PUK wordt PIN formaat 2 gebruikt\n                                          (zie onder 8.1).\n\nNaam\n\nDeblockAndChangePIN\n\nGebruik\n\nBoordcomputerkaarten\n\nInput gegevens\n\nNieuwe PIN\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van Reset Retry Counter, afhankelijk van de implementatie\n\nHierbij wordt de bestaande PIN gedeblokkeerd en gewijzigd in de Nieuwe PIN.\n\nHet gebruikte commando is Reset Retry Counter, waarbij P1 de waarde \u201802\u2019H heeft en\n                                          P2 (de PIN reference) de waarde \u201801\u2019H heeft.\n\nVoorafgaand aan dit commando moet een succesvol Verify commando uitgevoerd worden\n                                          met P1 = \u201800\u2019H en P2 = \u201802\u2019H (de PUK reference). Voor de PUK wordt PIN formaat 2 gebruikt\n                                          (zie onder 8.1).\n\nNaam\n\nGebruik\n\nSignDataLegally\n\nChauffeurskaart, Inspectiekaart\n\nInput gegevens\n\nGegevens waarover handtekening berekend moet worden\n\nResultaat\n\nHandtekening || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nDeze functie wordt gebruikt voor het door een natuurlijke persoon zetten van een rechtsgeldige\n                                          elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.DS die uitsluitend\n                                          op chauffeurs- en inspectiekaarten bestaat.\n\nElke boordcomputerkaart (chip) ondersteunt minimaal een van de twee navolgende procedures\n                                          voor het uitvoeren van deze functie. De boordcomputer moet op basis van het door de\n                                          chip geleverde Answer To Reset (ATR) bepalen welke van de twee procedures met de betreffende\n                                          chip gebruikt moet worden. Bij chips die beide procedures ondersteunen is de boordcomputer\n                                          vrij om een van beide procedures te kiezen.\n\nVoor deze functie bestaat procedure 1 uit de volgende stappen:\n\n1. Selectie hash template en algoritme: alvorens de digitale handtekening berekend kan\n                                                worden, moet het hash template geselecteerd worden en het te gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018AA\u2019H. De data bij dit commando is \u201880 01 40\u2019H (\u201840\u2019H om de algoritme\n                                                identifier voor SHA-256 aan te geven).\n\n2. Selectie private key en algoritme: de private key van de BCT Handtekening moet geselecteerd\n                                                worden met het te gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018B6\u2019H. De data bij dit commando is \u201880 01 42 84 01 86\u2019H (\u201842\u2019H om\n                                                \u2018PKCS#1 v1.5 \u2013 SHA-256\u2019 aan te duiden en \u201886\u2019H om het Security Data Object (SDO) van\n                                                PKI.CH.DS aan te duiden).\n\n3. PIN valideren: de private key van de BCT Handtekening mag pas gebruikt worden nadat\n                                                de PIN gevalideerd is. Dit is nodig voor iedere keer dat deze key gebruikt wordt.\n\nDit wordt gedaan met het commando Verify, waarbij P2 (de PIN reference) de waarde\n                                                \u201801\u2019H heeft. Voor de PIN wordt PIN formaat 2 gebruikt (zie onder 8.1).\n\n4. Berekenen van de intermediate hash (SHA256) over de input gegevens door de boordcomputerlogica.\n                                                Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash\n                                                en het aantal gehashte bits onthouden voor de volgende stap.\n\nNB. Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen\n                                                intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.\n\n5. Berekenen van de uiteindelijke hash (SHA256) door de boordcomputerkaart. Hiervoor\n                                                wordt het commando PSO Hash gebruikt. Hierbij worden de \u2018intermediate hash value\u2019,\n                                                het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en\n                                                maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde\n                                                PSO HASH zal de uiteindelijke hash waarde in het geheugen van de boordcomputerkaart\n                                                (chip) achterblijven ten behoeve van de volgende en laatste stap.\n\n6. Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend\n                                                over de in het chipgeheugen aanwezige hashwaarde en geeft de kaart die handtekening\n                                                terug aan de boordcomputerlogica.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte\n                                                aantal bytes in de response, moet daarbij op \u201800\u2019H staan.\n\nVoor deze functie bestaat procedure 2 uit de volgende stappen (nummering gelijk aan\n                                          die van procedure 1):\n\n1. Niet van toepassing.\n\n2. Gelijk aan stap 2 van procedure 1.\n\n3. Gelijk aan stap 3 van procedure 1.\n\n4. Berekenen van de volledige hash (SHA256) over de input gegevens door de boordcomputerlogica.\n\n5. Niet van toepassing.\n\n6. Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend\n                                                over de in stap 4 berekende hashwaarde en geeft de kaart die handtekening terug aan\n                                                de boordcomputerlogica.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Daarbij moet Lc,\n                                                het aantal bytes van de input data, op \u201820\u2019H staan, het DATA veld worden gevuld met\n                                                de hashwaarde uit stap 4 (32 bytes) en Le, het verwachte aantal bytes in de response,\n                                                op \u201800\u2019H staan.\n\nZie ook PSO Hash en PSO Compute Digital Signature in Referentie [7].\n\nVoor de vermelde SDO ID wordt verwezen naar de kaartstructuur documenten in Referenties\n                                          [9] en [12]. Omdat dit SDO een lokaal object is, moet de in de kaartstructuur documenten\n                                          gespecificeerde keyReference niet letterlijk worden overgenomen, maar met bit8 hoog\n                                          (dus \u201886\u2019H in plaats van \u201806\u2019H).\n\nNaam\n\nGebruik\n\nSignDataSystem\n\nSysteemkaart\n\nInput gegevens\n\nGegevens waarover handtekening berekend moet worden\n\nResultaat\n\nHandtekening || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nDeze functie wordt gebruikt voor het door een boordcomputer zetten van een elektronische\n                                          handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT van de systeemkaart.\n\nOp de systeemkaart mag deze functie alleen uitgevoerd worden onder beveiligde gegevensoverdracht\n                                          (zie Hoofdstuk 4), gebruikmakend van de sleutelset SM.ICC.\n\nElke systeemkaart (chip) ondersteunt minimaal een van de twee navolgende procedures\n                                          voor het uitvoeren van deze functie. De boordcomputer moet op basis van het door de\n                                          chip geleverde Answer To Reset (ATR) bepalen welke van de twee procedures met de betreffende\n                                          chip gebruikt moet worden. Bij chips die beide procedures ondersteunen is de boordcomputer\n                                          vrij om een van beide procedures te kiezen.\n\nVoor deze functie bestaat procedure 1 uit de volgende stappen:\n\n1. Selectie hash template en algoritme: alvorens de digitale handtekening berekend kan\n                                                worden, moet het hash template geselecteerd worden en het te gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018AA\u2019H. De data bij dit commando is \u201880 01 40\u2019H (\u201840\u2019H om de algoritme\n                                                identifier voor SHA-256 aan te geven).\n\n2. Selectie private key en algoritme: de private key van de BCT Authenticiteit moet geselecteerd\n                                                worden met het te gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018B6\u2019H. De data bij dit commando is \u201880 01 42 84 01 85\u2019H (\u201842\u2019H om\n                                                \u2018PKCS#1 v1.5 \u2013 SHA-256\u2019 aan te duiden en \u201885\u2019H om het Security Data Object (SDO) van\n                                                PKI.CH.AUT aan te duiden).\n\n3. Berekenen van de intermediate hash (SHA256) over de input gegevens door de boordcomputerlogica.\n                                                Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash\n                                                en het aantal gehashte bits onthouden voor de volgende stap.\n\nNB. Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen\n                                                intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.\n\n4. Berekenen van de uiteindelijke hash (SHA256) door de systeemkaart. Hiervoor wordt\n                                                het commando PSO Hash gebruikt. Hierbij worden de \u2018intermediate hash value\u2019, het aantal\n                                                gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en maximaal\n                                                64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde\n                                                PSO HASH zal de uiteindelijke hash waarde in het geheugen van de systeemkaart (chip)\n                                                achterblijven ten behoeve van de volgende en laatste stap.\n\n5. Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend\n                                                over de in het chipgeheugen aanwezige hashwaarde en geeft de kaart die handtekening\n                                                terug aan de boordcomputerlogica.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte\n                                                aantal bytes in de response, moet daarbij op \u201800\u2019H staan.\n\nVoor deze functie bestaat procedure 2 uit de volgende stappen (nummering gelijk aan\n                                          die van procedure 1):\n\n1. Niet van toepassing.\n\n2. Gelijk aan stap 2 van procedure 1.\n\n3. Berekenen van de volledige hash (SHA256) over de input gegevens door de boordcomputerlogica.\n\n4. Niet van toepassing.\n\n5. Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend\n                                                over de in stap 3 berekende hashwaarde en geeft de kaart die handtekening terug aan\n                                                de boordcomputerlogica.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Daarbij moet Lc,\n                                                het aantal bytes van de input data, op \u201820\u2019H staan, het DATA veld worden gevuld met\n                                                de hashwaarde uit stap 3 (32 bytes) en Le, het verwachte aantal bytes in de response,\n                                                op \u201800\u2019H staan.\n\nZie ook PSO Hash en PSO Compute Digital Signature in Referentie [7]).\n\nVoor de vermelde SDO ID wordt verwezen naar het kaartstructuur documenten in Referentie\n                                          [8]. Omdat dit SDO een lokaal object is, moet de in het kaartstructuur document gespecificeerde\n                                          keyReference niet letterlijk worden overgenomen, maar met bit8 hoog (dus \u201885\u2019H in\n                                          plaats van \u201805\u2019H).\n\nNoot: Zie ook 5.4 (digitale handtekening).\n\nNaam\n\nGebruik\n\nSignDataForAuthenticity\n\nChauffeurskaart, Ondernemerskaart, Keuringskaart, Inspectiekaart\n\nInput gegevens\n\nGegevens waarover handtekening berekend moet worden\n\nResultaat\n\nHandtekening || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nDeze functie wordt gebruikt voor het door een boordcomputerkaarthouder zetten van\n                                          een elektronische handtekening met de sleutel-certificaatcombinatie PKI.CH.AUT die\n                                          op elke boordcomputerkaart bestaat.\n\nElke boordcomputerkaart (chip) ondersteunt minimaal een van de twee navolgende procedures\n                                          voor het uitvoeren van deze functie. De boordcomputer moet op basis van het door de\n                                          chip geleverde Answer To Reset (ATR) bepalen welke van de twee procedures met de betreffende\n                                          chip gebruikt moet worden. Bij chips die beide procedures ondersteunen is de boordcomputer\n                                          vrij om een van beide procedures te kiezen.\n\nVoor deze functie bestaat procedure 1 uit de volgende stappen:\n\n1. Selectie hash template en algoritme: alvorens de digitale handtekening berekend kan\n                                                worden, moet het hash template geselecteerd worden en het te gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018AA\u2019H. De data bij dit commando is \u201880 01 40\u2019H (\u201840\u2019H om de algoritme\n                                                identifier voor SHA-256 aan te geven).\n\n2. Selectie private key en algoritme: de private key van de BCT Authenticiteit moet geselecteerd\n                                                worden met het te gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018B6\u2019H. De data bij dit commando is \u201880 01 42 84 01 85\u2019H (\u201842\u2019H om\n                                                \u2018PKCS#1 v1.5 \u2013 SHA-256\u2019 aan te duiden en \u201885\u2019H om het Security Data Object (SDO) van\n                                                PKI.CH.AUT aan te duiden).\n\n3. PIN valideren: de private key van de BCT Authenticiteit mag pas gebruikt worden nadat\n                                                de PIN gevalideerd is. Een eenmaal uitgevoerde PIN validatie mag \u2013 zo lang de kaart\n                                                in de boordcomputer aanwezig blijft \u2013 worden \u2018herbruikt\u2019 bij elke volgende keer dat\n                                                deze key gebruikt wordt.\n\nDit wordt gedaan met het commando Verify, waarbij P2 (de PIN reference) de waarde\n                                                \u201801\u2019H heeft. Voor de PIN wordt PIN formaat 2 gebruikt (zie onder 8.1).\n\n4. Berekenen van de intermediate hash (SHA256) over de input gegevens door de boordcomputerlogica.\n                                                Hierbij wordt het laatste gegevensblok niet gehashed, maar wordt de intermediate hash\n                                                en het aantal gehashte bits onthouden voor de volgende stap.\n\nNB. Wanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen\n                                                intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.\n\n5. Berekenen van de uiteindelijke hash (SHA256) door de boordcomputerkaart. Hiervoor\n                                                wordt het commando PSO Hash gebruikt. Hierbij worden de \u2018intermediate hash value\u2019,\n                                                het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal 1 en\n                                                maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol uitgevoerde\n                                                PSO HASH zal de uiteindelijke hash waarde in het geheugen van de boordcomputerkaart\n                                                (chip) achterblijven ten behoeve van de volgende en laatste stap.\n\n6. Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend\n                                                over de in het chipgeheugen aanwezige hashwaarde en geeft de kaart die handtekening\n                                                terug aan de boordcomputerlogica.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte\n                                                aantal bytes in de response, moet daarbij op \u201800\u2019H staan.\n\nVoor deze functie bestaat procedure 2 uit de volgende stappen (nummering gelijk aan\n                                          die van procedure 1):\n\n1. Niet van toepassing.\n\n2. Gelijk aan stap 2 van procedure 1.\n\n3. Gelijk aan stap 3 van procedure 1.\n\n4. Berekenen van de volledige hash (SHA256) over de input gegevens door de boordcomputerlogica.\n\n5. Niet van toepassing.\n\n6. Handtekening berekenen: hierbij wordt met de gekozen private key de handtekening berekend\n                                                over de in stap 4 berekende hashwaarde en geeft de kaart die handtekening terug aan\n                                                de boordcomputerlogica.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Daarbij moet Lc,\n                                                het aantal bytes van de input data, op \u201820\u2019H staan, het DATA veld worden gevuld met\n                                                de hashwaarde uit stap 4 (32 bytes) en Le, het verwachte aantal bytes in de response,\n                                                op \u201800\u2019H staan.\n\nZie ook PSO Hash en PSO Compute Digital Signature in Referentie [7].\n\nVoor de vermelde SDO ID wordt verwezen naar de kaartstructuur documenten in Referenties\n                                          [9] t/m [12]. Omdat dit SDO een lokaal object is, moet de in de kaartstructuur documenten\n                                          gespecificeerde keyReference niet letterlijk worden overgenomen, maar met bit8 hoog\n                                          (dus \u201885\u2019H in plaats van \u201805\u2019H).\n\nNaam\n\nAuthenticateCardToBCT\n\nGebruik\n\nBoordcomputerkaarten\n\nInput gegevens\n\nRandom waarde (16 bytes)\n\nResultaat\n\nHandtekening || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nOm te controleren of een boordcomputerkaart authentiek is, wordt er een Client/Server\n                                          authenticatie uitgevoerd (zie Referentie [7]). Hierbij wordt een boordcomputer challenge\n                                          ondertekend met behulp van de sleutel-certificaatcombinatie PKI.CH.AUT van de een\n                                          boordcomputerkaart. Deze functie is analoog aan SignDataForAuthenticity, maar wordt\n                                          hier uitsluitend voor authenticatiedoeleinden gebruikt.\n\nVoor deze functie moeten een aantal stappen doorlopen worden:\n\n1. Selectie private key en algoritme: alvorens de digitale handtekening berekend kan\n                                                worden, moet de private key van de BCT Authenticiteit geselecteerd worden en het te\n                                                gebruiken algoritme.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde \u201841\u2019H\n                                                en P2 de waarde \u2018A4\u2019H. De data bij dit commando is \u201880 01 02 84 01 85\u2019H (\u201802\u2019H om\n                                                \u201cC/S RSA with DSI according to PKCS#1, parameter Digestinfo\u201d aan te duiden en \u201885\u2019H\n                                                om het Security Data Object (SDO) van PKI.CH.AUT aan te duiden).\n\n2. PIN valideren: de private key van de BCT Authenticiteit mag pas gebruikt worden nadat\n                                                de PIN gevalideerd is. Dit is nodig voor de eerste keer dat deze key gebruikt wordt,\n                                                maar een eenmaal uitgevoerde PIN validatie mag \u2013 zo lang de kaart in de boordcomputer\n                                                aanwezig blijft \u2013 worden \u201cherbruikt\u201d bij elke volgende keer dat deze key gebruikt\n                                                wordt.\n\nDit wordt gedaan met het commando Verify waarbij P2 (de PIN reference) de waarde \u201801\u2019H\n                                                heeft. Voor de PIN wordt PIN formaat 2 gebruikt (zie onder 8.1).\n\n3. De boordcomputer stuurt een Internal Authenticate commando naar de boordcomputerkaart.\n                                                P1 P2 = \u201800 00\u2019 en de data = 16 bytes random.\n\n4. Het antwoord hiervan wordt teruggestuurd naar de boordcomputer en deze controleert\n                                                met behulp van de publieke key en een padvalidatie van het authenticiteitcertificaat\n                                                of de boordcomputerkaart authentiek is.\n\n5. Ook de geldigheid van het authenticiteitcertificaat dient te worden gecontroleerd\n                                                middels minimaal een padvalidatie en een controle van de attributen validity.notBefore\n                                                en validity.notAfter.\n\n6. Met behulp van het eerste karakter van het kaartnummer, zoals dat in het subject.serialNumber\n                                                of in de subject.title van het authenticiteitcertificaat is opgeslagen, kan de boordcomputer\n                                                het kaarttype en daarmee de gebruikerssoort (bestuurder, vervoerder, werkplaats, dan\n                                                wel toezichthouder) herkennen.\n\nNB. De boordcomputerkaarten ondersteunen Windows/Kerberos smartcard logon. Ook deze\n                                          wijze van authenticeren is toegestaan, mits ook hier de geldigheid van het authenticiteitcertificaat\n                                          middels een padvalidatie wordt gevalideerd.\n\nVoor de vermelde SDO ID wordt verwezen naar de kaartstructuur documenten in Referenties\n                                          [9] t/m [12]. Omdat dit SDO een lokaal object is, moet de in de kaartstructuur documenten\n                                          gespecificeerde keyReference niet letterlijk worden overgenomen, maar met bit8 hoog\n                                          (dus \u201885\u2019H in plaats van \u201805\u2019H).\n\nNaam\n\nWriteNewActivityRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nActivityRecord, ActivityDate\n\nResultaat\n\n90h 00h OK\n\nxxh xxh Foutcode van een van de gebruikte commando\u2019s, afhankelijk van smartcard implementatie\n\nDeze functie wordt gebruikt om een ActivityRecord toe te voegen in EF.Driver_Activity_Data.\n\nDe functie moet gevoed worden met de volgende argumenten met betrekking tot het toe\n                                          te voegen ActivityRecord:\n\n1. \nActivityDate de datum (JJJJMMDD) waarop de activiteit startte c.q. gebeurtenis plaatsvond;\n\n2. \nActivityTime het tijdstip (hhmmss) waarop de activiteit startte c.q. gebeurtenis plaatsvond;\n\n3. \nActivityType: het type activiteit / gebeurtenis;\n\n4. \nManualBit: de handmatig-bit die weergeeft of het tijdstempel (datum en tijd) handmatig dan\n                                                wel automatisch werd bepaald.\n\nDeze functie moet, voorafgaand aan het daadwerkelijk toevoegen van het ActivityRecord,\n                                          aan de hand van meegestuurde argumenten, het laatst in EF.Driver_Activity_Data geboekte\n                                          ActivityRecord en de status van de boordcomputer bepalen of voor het ActivityRecord\n                                          al dan niet een nieuw DailyRecord en/of SessionRecord moet worden aangemaakt en op\n                                          welke geheugenpositie het nieuwe ActivityRecord moet worden toegevoegd. Stapsgewijs\n                                          is de daarvoor te volgen logica als volgt:\n\n1. Selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 01\u2019H.\n\n2. Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is en het verwachte aantal bytes\n                                                in de response 2.\n\nIndien PointerLastDayRecord gelijk aan \u201800 00\u2019H is, dan bestaat er (nog) geen enkel DailyRecord:\n\na. Roep de functie voor het toevoegen van een nieuw DailyRecord aan met ActivityDate als argument.\n\nb. Herhaal de stappen vanaf stap 2.\n\nIndien PointerLastDayRecord niet gelijk aan \u201800 00\u2019H is:\n\na. Lees de DayRecordLength met het commando Read Binary, waarbij de offset PointerLastDayRecord is en het verwachte aantal bytes in de response 2.\n\nb. Lees de DayRecordDate met het commando Read Binary, waarbij de offset PointerLastDayRecord + 6 is en het verwachte aantal bytes in de response 4.\n\nIndien DayRecordDate groter is dan ActivityDate,\n\ndan betreft dit een foutsituatie en stopt verdere verwerking.\n\nIndien DayRecordDate kleiner is dan ActivityDate,\n\ndan ontbreekt de gewenste DailyRecord\n\n(hou hier ook rekening met Dagovergangen zoals beschreven in \u00a7 5.2.7 en \u00a7 7.5):\n\na. Roep de functie voor het toevoegen van een nieuw DailyRecord aan met ActivityDate als argument.\n\nb. Herhaal de stappen vanaf stap 2.\n\nIndien DayRecordDate gelijk is aan ActivityDate:\n\na. Lees de PointerLastSessionRecord met het commando Read Binary, waarbij de offset PointerLastDayRecord + 2 is en het verwachte aantal bytes in de response 2.\n\nIndien de PointerLastSessionRecord gelijk aan \u201800 00\u2019H is,\n\ndan bevat het DailyRecord (nog) geen enkel SessionRecord:\n\ni. Roep de functie voor het toevoegen van een nieuw SessionRecord aan.\n\nii. Herhaal de stappen vanaf het lezen van PointerLastSessionRecord.\n\nIndien de PointerLastSessionRecord niet gelijk aan \u201800 00\u2019H is:\n\ni. Lees de PointerLastActivityRecord met het commando Read_Binary, waarbij de offset PointerLastSessionRecord is en het verwachte aantal bytes in de response 2.\n\nIndien de PointerLastActivityRecord gelijk aan \u201800 00\u2019H is,\n\ndan wordt nu het eerste ActivityRecord aan het SessionRecord toegevoegd: zet de NewActivityPointer dus op PointerLastSessionRecord + Length(SessionRecordHeader).\n\nIndien de PointerLastActivityRecord niet gelijk aan \u201800 00\u2019H is,\n\ndan bestaat er een eerder ActivityRecord:\n\na. Lees de LastActivityRecordHeader met het commando Read_Binary, waarbij de offset PointerLastActivityRecord is en het verwachte aantal bytes in de response 3.\n\nb. Bepaal uit de eerste 5 bits van de LastActivityRecordHeader de LastActivityType.\n\nIndien de LastActivityType gelijk is aan \u201cAfsluiting\u201d of \u201cNieuwe eindtijd\u201d,\n\ndan moet er een nieuwe sessie worden geboekt:\n\ni. Roep de functie voor het toevoegen van een nieuw SessionRecord aan.\n\nii. Herhaal de stappen vanaf het lezen van PointerLastSessionRecord.\n\nIndien de LastActivityType gelijk is aan \u201cLogin\u201d, \u201cStart werk\u201d of \u201cStart pauze\u201d, maar de boordcomputer heeft\n                                                                        geen kaartsessie meer actief of geblokkeerd,\n\ndan moet er ook een nieuwe sessie worden geboekt:\n\ni. Roep de functie voor het toevoegen van een nieuw SessionRecord aan.\n\nii. Herhaal de stappen vanaf het lezen van PointerLastSessionRecord.\n\nIndien de LastActivityType gelijk is aan \u201cStart werk\u201d,\n\nWerk dan diens Rijtijdteller voor de laatste maal bij: voer een Update Binary commando\n                                                                        uit, waarbij de offset PointerLastActivityRecord + 3 is en de data de door de boordcomputer bijgehouden rijtijdteller; reset die laatste\n                                                                        ook direct naar nul (0).\n\nZet NewActivityPointer = PointerLastActivityRecord + 6\n\nIndien de LastActivityType NIET gelijk is aan \u201cStart werk\u201d,\n\nZet NewActivityPointer = PointerLastActivityRecord + 3\n\nNB1. NewActivityPointer, LastActivityRecordHeader en NewActivityLength maken g\u00e9\u00e9n onderdeel\n                                          van de structuur uit, maar zijn tijdelijke waardes in het geheugen van de boordcomputer.\n\nNB2. Indien het LastActivityRecord een \u201c(Start) werk\u201d of \u201c(Start) pauze\u201d betreft worden\n                                          met het bovenstaande algoritme de laatste 3 bytes (waarin de tijdsduur van de activiteit\n                                          tijdelijk werd bijgehouden) overschreven door het nieuw toe te voegen ActivityRecord.\n\nVoeg nu het nieuwe ActivityRecord toe in het in het huidige SessionRecord:\n\n1. Bepaal eerst aan de hand van de ActivityType de lengte van het nieuwe ActivityRecord:\n\na. Indien \u201c(Start) werk\u201d, dan NewActivityLength = 9;\n\nb. Indien \u201c(Start) pauze\u201d, dan NewActivityLength = 6;\n\nc. Indien anders, dan NewActivityLength = 3;\n\n2. Bepaal dan aan de hand van NewActivityPointer + NewActivityLength of er nog voldoende vrije ruimte resteert in EF.Driver_Activity_Data en ruim zo nodig\n                                                een of meer van de oudste DailyRecords op (zie ook 5.3).\n\n3. Voer een Update Binary commando uit, waarbij de offset PointerLastSessionRecord is en de data NewActivityPointer (hiermee wordt PointerLastActivityRecord bijgewerkt).\n\n4. Voer een Update Binary commando uit, waarbij de offset NewActivityPointer is en de data bestaat uit 3 bytes:\n\na. 5 bits ActivityType: het als argument gegeven type activiteit / gebeurtenis;\n\nb. 1 bit ManualBit: de als argument gegeven handmatig-bit;\n\nc. 1 bit RijdenBit: de bit die aangeeft of de auto NU rijdt (\u20181\u2019B) of stilstaat (\u20180\u2019B);\n\nd. 17 bits ActivityTime: het als argument gegeven (start)tijdstip.\n\n5. Indien de nieuwe activiteit een \u201c(Start) werk\u201d of \u201c(Start) pauze\u201d betreft:\n\na. Voer een Update Binary commando uit, waarbij de offset PointerLastSessionRecord + 2 is en de data NewActivityPointer (hiermee wordt PointerLastPWActivityRecord bijgewerkt);\n\nb. Voer een Update Binary commando uit, waarbij de offset NewActivityPointer + 3 is en de data bestaat uit 3 bytes gelijk aan \u201800 00 00\u2019H;\n\nc. Reset op de boordcomputer de tijdsduurteller naar nul (0) seconden;\n\nd. Indien de nieuwe activiteit een \u201c(Start) werk\u201d betreft:\n\ni. Voer een Update Binary commando uit, waarbij de offset NewActivityPointer + 6 is en de data bestaat uit 3 bytes gelijk aan \u201800 00 00\u2019H;\n\nii. Reset op de boordcomputer de rijtijdteller naar nul (0) seconden.\n\n6. Voer een Update Binary commando uit met offset is PointerLastDayRecord en als data DayRecordLength + NewActivityLength (hiermee wordt DayRecordLength bijgewerkt).\n\nVoer tot slot nog de procedure uit voor het door de boordcomputer ondertekenen van\n                                          het aangepaste SessionRecord, zoals beschreven in \u00a7 5.4.\n\nNaam\n\nWriteNewSessionRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nStartSessionData\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nDeze functie wordt gebruikt om een nieuw leeg SessionRecord aan het huidige DailyRecord\n                                          toe te voegen. Deze functie wordt altijd aangeroepen vanuit de functie voor het toevoegen\n                                          van een ActivityRecord (zie 0)\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 01\u2019H.\n\n2. Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is\n                                                en het verwachte aantal bytes in de response 2. Dit levert de pointer voor het meest\n                                                recente DailyRecord (Pointer_1).\n\n3. Lees in deze DailyRecord de DayRecordLength met Read Binary, de offset is Pointer_1\n                                                en het verwachte aantal bytes in de response is 2. Dit levert de lengte van dit DailyRecord\n                                                (Length_1). Daarmee wordt de pointer waar het SessionRecord weggeschreven kan worden:\n                                                Pointer_2 = Pointer_1 + Length_1.\n\n4. Maak een nieuw SessionRecord (alleen de kop) aan met\n\n\u2013 PointerLastActivityRecord = \u201800 00\u2019H (0).\n\n\u2013 PointerLastPWActivityRecord = \u201800 00\u2019H (0).\n\n\u2013 SignatureDateTime = \u201800000000 000000\u2019H\n\n\u2013 SessionSignature = 256 willekeurige bytes.\n\n\u2013 SessionCreationDateTime = de huidige datum en tijd volgens de BCT klok in BCD en geformatteerd\n                                                      als \u2018JJJJMMDDhhmmss\u2019H\n\n\u2013 SystemCardNumber, Kenteken, CompanyCardNumber en Pnummer zoals die in de boordcomputer\n                                                      bekend zijn.\n\nVoer een Update Binary commando uit, waarbij de offset Pointer_2 is en de data de\n                                                weg te schrijven SessionRecord kop.\n\n5. Verhoog DayRecordLength door een Update Binary commando met offset is Pointer_1 en\n                                                als data Length_1 + 299.\n\n6. Wijzig de PointerLastSessionRecord door een Update Binary commando, waarbij de offset\n                                                Pointer_1 + 2 is en de data Pointer_2.\n\nNoot: Zie 5.3, aangezien de mogelijkheid bestaat dat de te schrijven data niet aan het\n                                          eind van EF.Driver_Activity_Data past.\n\nNaam\n\nWriteNewDailyRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nDatum (BCD)\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nDeze functie wordt gebruikt om een nieuw leeg DailyRecord toe te voegen. Dit wordt\n                                          gedaan voor de eerste registratie van een dag. Dit nieuwe DailyRecord bevat nog geen\n                                          SessionRecords.\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 01\u2019H.\n\n2. Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is\n                                                en het verwachte aantal bytes in de response 2. Dit levert de pointer voor de meest\n                                                recente DailyRecord (Pointer_1).\n\n3. Lees in deze DailyRecord de DayRecordLength met Read Binary, offset is Pointer_1 en\n                                                het verwachte aantal bytes in de response is 2. Dit levert de lengte van het DailyRecord\n                                                (Length_1).\n\nDaarmee is de pointer bekend waar de nieuwe DailyRecord weggeschreven kan worden:\n                                                Pointer_2 = Pointer_1 + Length_1.\n\n4. Maak een nieuwe DailyRecord kop aan met\n\n\u2013 DayRecordLength = \u201800 0A\u2019H (10)\n\n\u2013 PointerLastSessionRecord = \u201800 00\u2019H (0)\n\n\u2013 PreviousDayRecordLength = Length_1\n\n\u2013 DayRecordDate = datum in BCD formaat.\n\nen voer een Update Binary commando uit, waarbij de offset Pointer_2 is en de data\n                                                de weg te schrijven DailyRecord kop.\n\n5. Verzet de PointerLastDayRecord naar het nieuwe DailyRecord met een Update Binary,\n                                                waarbij de offset 2 is en de data Pointer_2 is.\n\nNoot: Zie 5.3, aangezien de mogelijkheid bestaat dat de te schrijven data niet aan het\n                                          eind van EF.Driver_Activity_Data past.\n\nNaam\n\nSelectLastDailyRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nGeen\n\nResultaat\n\nDailyRecordPointer || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data\n                                                met het commando Select met P1P2 = \u201804 0C\u2019H en data = \u2018E8 28 BD 08 0F A0 00 00 01\n                                                67 45 53 49 47 4E\u2019H, gevolgd door het commando Select met P1P2 = \u201802 0C\u2019H en data\n                                                = \u201844 01\u2019H.\n\n2. Lees de PointerLastDayRecord met het commando Read Binary, waarbij de offset 2 is\n                                                en het verwachte aantal bytes in de response 2. Dit levert de pointer voor de meest\n                                                recente DailyRecord (DailyRecordPointer).\n\nNaam\n\nSelectOldestDailyRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nGeen\n\nResultaat\n\nDailyRecordPointer || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data\n                                                met het commando Select met P1P2 = \u201804 0C\u2019H en data = \u2018E8 28 BD 08 0F A0 00 00 01\n                                                67 45 53 49 47 4E\u2019H, gevolgd door het commando Select met P1P2 = \u201802 0C\u2019H en data\n                                                = \u201844 01\u2019H.\n\n2. Lees de PointerOldestDayRecord met het commando Read Binary, waarbij de offset 0 is\n                                                en het verwachte aantal bytes in de response 2. Dit levert de pointer voor de oudst\n                                                bekende DailyRecord (DailyRecordPointer).\n\nNaam\n\nSelectPreviousDailyRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nCurrentDailyRecordPointer (bereik \u201800 14\u2019H t/m (Length_EF.Driver_Activitiy_Data \u2013\n                                                         1))\n\nPointerOldestDayRecord\n\nResultaat\n\nDailyRecordPointer || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data\n                                                met het commando Select met P1P2 = \u201804 0C\u2019H en data = \u2018E8 28 BD 08 0F A0 00 00 01\n                                                67 45 53 49 47 4E\u2019H, gevolgd door het commando Select met P1P2 = \u201802 0C\u2019H en data\n                                                = \u201844 01\u2019H.\n\n2. Indien PointerOldestDayRecord niet was meegegeven als inputgegeven, lees dan PointerOldestDayRecord\n                                                met het commando Read Binary met offset = 0 en het verwachte aantal bytes in de respons\n                                                2.\n\n3. Als CurrentDailyRecordPointer gelijk is aan PointerOldestDayRecord, dan is de geselecteerde\n                                                DailyRecord de eerste (oudste) en is er geen vorige DailyRecord aanwezig. Breek dan\n                                                deze functie af.\n\n4. Zet Pointer_1 = CurrentDailyRecordPointer + 4 om de pointer naar PreviousDayRecordLength\n                                                te verkrijgen.\n\n5. Als Pointer_1 >= Length_EF.Driver_Activity_Data herbereken dan de positie met de formule:\n                                                Pointer_1 = (Pointer_1 modulo Length_EF.Driver_Activity_Data) + \u201800 14\u2019H (20)\n\n6. Als nu Pointer_1 precies gelijk is aan (Length_EF.Driver_Activity_Data \u2013 1), dan staat\n                                                de MSB van PreviousDayRecordLength in de laatste byte van EF.Driver_Activity_Data\n                                                en de LSB op positie \u201800 14\u2019H (20). Voer dan twee keer het commando Read Binary uit\n                                                met het verwachte aantal bytes in de response gelijk aan 1; \u00e9\u00e9n keer met offset =\n                                                (Length_EF.Driver_Activity_Data \u2013 1) voor Length_1_MSB en \u00e9\u00e9n keer met offset = 20\n                                                (\u201800 14\u2019H) voor Length_1_LSB. Bereken dan PreviousDayRecordLength = 256 x Length_1_MSB\n                                                + Length_1_LSB.\n\n7. Als \u201800 14\u2019H <= Pointer_1 < (Length_EF.Driver_Activity_Data \u2013 1) is, dan kan PreviousDayRecordLength\n                                                in \u00e9\u00e9n keer worden uitgelezen met het commando Read Binary met offset = Pointer_1\n                                                en het verwachte aantal bytes in de response 2.\n\n8. Als PreviousDayRecordLength gelijk is aan \u201800 00\u2019H, dan is er geen vorig DailyRecord\n                                                en dan moet de functie hier worden afgebroken.\n\n9. Bereken nu voorlopig Pointer_2 = CurrentDailyRecordPointer \u2013 PreviousDayRecordLength.\n\n10. Indien Pointer_2 kleiner is dan \u201800 14\u2019H (20), voer dan nog de volgende correctie\n                                                uit:\n\nPointer_2 = Length_EF.Driver_Activity_Data \u2013 (20 \u2013 Pointer_2).\n\n11. Geef nu de gevraagde DailyRecordPointer = Pointer_2 terug.\n\nNaam\n\nSelectNextDailyRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nCurrentDailyRecordPointer (bereik \u201800 14\u2019H t/m (Length_EF.Driver_Activitiy_Data \u2013\n                                                         1))\n\nPointerLastDayRecord\n\nResultaat\n\nDailyRecordPointer || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data\n                                                met het commando Select met P1P2 = \u201804 0C\u2019H en data = \u2018E8 28 BD 08 0F A0 00 00 01\n                                                67 45 53 49 47 4E\u2019H, gevolgd door het commando Select met P1P2 = \u201802 0C\u2019H en data\n                                                = \u201844 01\u2019H.\n\n2. Indien PointerLastDayRecord niet was meegegeven als inputgegeven, lees dan PointerLastDayRecord\n                                                met het commando Read Binary met offset = 2 en het verwachte aantal bytes in de respons\n                                                2.\n\n3. Als CurrentDailyRecordPointer gelijk is aan PointerLastDayRecord, dan is de geselecteerde\n                                                DailyRecord de laatste (meest recente) en is er geen volgende DailyRecord aanwezig.\n                                                Breek dan deze functie af.\n\n4. Zet Pointer_1 = CurrentDailyRecordPointer om de pointer naar DayRecordLength te verkrijgen.\n\n5. Als Pointer_1 precies gelijk is aan (Length_EF.Driver_Activity_Data \u2013 1), dan staat\n                                                de MSB van DayRecordLength in de laatste byte van EF.Driver_Activity_Data en de LSB\n                                                op positie \u201800 14\u2019H (20). Voer dan twee keer het commando Read Binary uit met het\n                                                verwachte aantal bytes in de response gelijk aan 1; \u00e9\u00e9n keer met offset = (Length_EF.Driver_Activity_Data\n                                                \u2013 1) voor Length_1_MSB en \u00e9\u00e9n keer met offset = 20 (\u201800 14\u2019H) voor Length_1_LSB. Bereken\n                                                dan DayRecordLength = 256 x Length_1_MSB + Length_1_LSB.\n\n6. Als \u201800 14\u2019H <= Pointer_1 < (Length_EF.Driver_Activity_Data \u2013 1) is, dan kan DayRecordLength\n                                                in \u00e9\u00e9n keer worden uitgelezen met het commando Read Binary met offset = Pointer_1\n                                                en het verwachte aantal bytes in de response 2.\n\n7. Bereken nu voorlopig Pointer_2 = CurrentDailyRecordPointer + DayRecordLength.\n\n8. Als Pointer_2 >= Length_EF.Driver_Activity_Data herbereken dan de positie met de formule:\n                                                Pointer_2 = (Pointer_2 modulo Length_EF.Driver_Activity_Data) + \u201800 14\u2019H (20)\n\n9. Geef nu de gevraagde DailyRecordPointer = Pointer_2 terug.\n\nNaam\n\nReadSelectedDailyRecord\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nCurrentDailyRecordPointer (bereik \u201800 14\u2019H t/m (Length_EF.Driver_Activitiy_Data \u2013\n                                                         1))\n\nResultaat\n\nData || \u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van de implementatie\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Indien EF.Driver_Activity_Data nog niet geselecteerd is, selecteer EF.Driver_Activity_Data\n                                                met het commando Select met P1P2 = \u201804 0C\u2019H en data = \u2018E8 28 BD 08 0F A0 00 00 01\n                                                67 45 53 49 47 4E\u2019H, gevolgd door het commando Select met P1P2 = \u201802 0C\u2019H en data\n                                                = \u201844 01\u2019H.\n\n2. Zet Pointer_1 = CurrentDailyRecordPointer om de pointer naar DayRecordLength te verkrijgen.\n\n3. Als Pointer_1 precies gelijk is aan (Length_EF.Driver_Activity_Data \u2013 1), dan staat\n                                                de MSB van DayRecordLength in de laatste byte van EF.Driver_Activity_Data en de LSB\n                                                op positie \u201800 14\u2019H (20). Voer dan twee keer het commando Read Binary uit met het\n                                                verwachte aantal bytes in de response gelijk aan 1; \u00e9\u00e9n keer met offset = (Length_EF.Driver_Activity_Data\n                                                \u2013 1) voor Length_1_MSB en \u00e9\u00e9n keer met offset = 20 (\u201800 14\u2019H) voor Length_1_LSB. Bereken\n                                                dan DayRecordLength = 256 x Length_1_MSB + Length_1_LSB.\n\n4. Als \u201800 14\u2019H <= Pointer_1 < (Length_EF.Driver_Activity_Data \u2013 1) is, dan kan DayRecordLength\n                                                in \u00e9\u00e9n keer worden uitgelezen met het commando Read Binary met offset = Pointer_1\n                                                en het verwachte aantal bytes in de response 2.\n\n5. Onthou de DayRecordLength nu voorlopig als Length_1.\n\n6. Voer Read Binary commando\u2019s uit tot Length_1 bytes gelezen zijn. Per Read Binary kan\n                                                een maximaal aantal bytes gelezen worden. Dit maximum is van een aantal factoren afhankelijk\n                                                (zie referentie [7]) en wordt hier max_read genoemd. De eerste Read Binary heeft als\n                                                offset Pointer_1 en het verwachte aantal bytes \u201800\u2019H (in het geval dat Length_1 <\n                                                max_read, dan wordt het verwachte aantal bytes Length_1). Voor iedere volgende Read\n                                                Binary wordt de offset met max_read verhoogd. Het verwachte aantal bytes in de response\n                                                is \u201800\u2019H, behalve bij de laatste Read Binary, daar is het Length_1 modulo max_read.\n\nNB. Voorafgaand aan elke Read Binary moet worden gecontroleerd of de te lezen bytes\n                                                verder zouden doorlopen dan EF.Driver_Activity_Data groot is. In zo\u2019n geval dient\n                                                de betreffende Read Binary in twee slagen te worden uitgevoerd:\n\na. De eerste keer met een ongewijzigde offset en een aangepast verwacht aantal_bytes\n                                                      (aantal_bytes_a), zijnde (Length_EF.DriverActivity_Data \u2013 offset_a);\n\nb. De tweede keer met een gecorrigeerde offset gelijk aan 20 (\u201800 14\u2019H) en het restant\n                                                      van het verwachte aantal_bytes, zijnde aantal_bytes_b = aantal_bytes \u2013 aantal_bytes_a.\n\nc. Hierna kan vanaf offset (\u201800 14\u2019H + aantal_bytes_b) worden vervolgd met de eerstvolgende\n                                                      reguliere Read Binary.\n\nNaam\n\nCheckEFDriverActivityStructure\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nGeen\n\nResultaat\n\n00 OK\n\n01 Invalid Pointer Value\n\n02 Wrong Length\n\n03 Length Not Matching\n\n04 Record Not Closed\n\n05 Invalid PW Pointer\n\n06 DayRecordLength Wrong\n\n07 DriverCardNumber was overwritten\n\nHiervoor moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.Driver_Activity_Data met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 01\u2019H.\n\n2. Lees PointerOldestDayRecord en PointerLastDayRecord.\n\n3. Controleer:\n\n20 (\u201800 14\u2019H) <= PointerOldestDayRecord < Length_EF.Driver_Activity_Data of\n\nPointerOldestDayRecord == 0.\n\nWanneer dit niet het geval is, geef dan \u201cInvalid Pointer Value\u201d terug.\n\n4. Controleer:\n\n20 (\u201800 14\u2019H) <= PointerLastDayRecord < Length_EF.Driver_Activity_Data of\n\nPointerLastDayRecord == 0.\n\nWanneer dit niet het geval is, geef dan \u201cInvalid Pointer Value\u201d terug.\n\n5. Controleer of DriverCardNumber gelijk is aan de eerste 20 bytes (karakters) van het\n                                                subject.SerialNumber van het authenticiteitcertificaat.\n\nWanneer dit niet het geval is, geef dan \u201cDriverCardNumber was overwritten\u201d terug (en\n                                                herstel de fout).\n\n6. Controleer de DailyRecord structuur (voorwaarts):\n\na. Ga met de PointerOldestDayRecord naar de oudste DailyRecord.\n\nb. Controleer of PreviousDayRecordLength = \u201800 00\u2019H.\n\nWanneer dit niet het geval is, geef dan \u201cWrong Length\u201d terug.\n\nc. Bepaal mbv de DayRecordLength de positie van het volgende DailyRecord.\n\nd. Controleer of de PreviousDayRecordLength in dit record gelijk is aan de DayRecordLength\n                                                      van het vorige record.\n\nWanneer dit niet het geval is, geef dan \u201cLength Not Matching\u201d terug.\n\ne. Herhaal de vorige 2 punten totdat\n\n\u2013 het beginpunt van een record gelijk is aan PointerLastDayRecord, of\n\n\u2013 de referenties DayRecordLength/PreviousDayRecordLength niet meer kloppen. Beschouw\n                                                            dan het DailyRecord waar dit nog wel correct was als laatste record. Pas in dit geval\n                                                            ook de PointerLastDayRecord aan.\n\n7. Controleer de DailyRecord structuur (terugwaarts):\n\na. Ga met de PointerLastDayRecord naar de laatste DailyRecord.\n\nb. Bepaal mbv de PreviousDayRecordLength de positie van het vorige DailyRecord.\n\nc. Controleer of de DayRecordLength in dit record gelijk is aan de PreviousDayRecordLength\n                                                      van het volgende record.\n\nWanneer dit niet het geval is, geef dan \u201cLength Not Matching\u201d terug.\n\nd. Herhaal de vorige 2 punten totdat\n\n\u2013 het beginpunt van een record gelijk is aan PointerOldestDayRecord, of\n\n\u2013 de referenties DayRecordLength/PreviousDayRecordLength niet meer kloppen.\n\nIn het eerste geval moet de PreviousDayRecordLength = \u201800 00\u2019H. Wanneer dit niet het\n                                                      geval is, geef dan \u201cWrong Length\u201d terug.\n\nBeschouw in het tweede geval het DailyRecord waar dit nog wel correct was als oudste\n                                                      record. Pas in dat geval ook PointerOldestDayRecord en PreviousDayRecordLength aan.\n\n8. Controleer de laatste DailyRecord:\n\na. Ga met de PointerLastDayRecord naar de laatste DailyRecord.\n\nb. Ga naar het eerste SessionRecord in het DailyRecord (PointerLastDayRecord + 10).\n\nc. Controleer of dit SessionRecord het laatste is door de beginpositie hiervan te vergelijken\n                                                      met de PointerLastSessionRecord.\n\nd. Is dit niet het laatste SessionRecord, controleer dan met PointerLastActivityRecord\n                                                      of de laatste activiteit een \u201cAfsluiting\u201d of een \u201cDagovergang\u201d is. Is dit niet het\n                                                      geval, geef dan \u201dRecord Not Closed\u201d terug.\n\nGa met behulp van PointerLastActivityRecord + de lengte van de laatste activiteit\n                                                      naar het volgende SessionRecord en herhaal het vorige punt.\n\ne. Controleer in het laatste SessionRecord of de PointerLastPWActivityRecord verwijst\n                                                      naar een \u201cStart pauze\u201d of \u201cStart werk\u201d activiteit.\n\nIs dit niet het geval, geef dan een \u201cInvalid PW Pointer\u201d terug.\n\nf. Controleer of de lengte van alle SessionRecords in dit DailyRecord samen gelijk is\n                                                      aan de DayRecordLength \u2013 10.\n\nIs dit niet het geval, geef dan \u201cDayRecordLength Wrong\u201d terug.\n\n9. Bij alle controles en leesacties moet rekening gehouden worden met de lengte van EF.Driver_Activity_Data.\n\nNaam\n\nIsCertificatePresent\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nSysteemkaartnummer\n\nResultaat\n\nRecent||\u201890 00\u2019H Certificaat aanwezig met ranking Recent (\u201801\u2019H-\u201803\u2019H)\n\n\u20186A 82\u2019H Certificaat niet aanwezig op chauffeurskaart\n\nIn deze functie wordt gecontroleerd of het certificaat behorende bij het systeemkaartnummer\n                                          al opgeslagen is in EF.BCT_Certificates.\n\nVoor deze functie moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.BCT_Certificates met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 02\u2019H.\n\n2. Lees Index_1 t/m Index_3 met het commando Read Binary met offset = 3 (\u201800 03\u2019H) en\n                                                het aantal verwachte bytes in de response 21 (\u201815\u2019H), en controleer of Index_x overeenkomt\n                                                met het systeemkaartnummer.\n\nZo ja, lees dan de bijbehorende Rank_x met het commando Read Binary met offset = de\n                                                offset voor Rank_x en het aantal verwachte bytes in de response 1 en geef het resultaat\n                                                || \u201890 00\u2019H terug.\n\nKomt het systeemkaartnummer niet voor, geef dan de foutcode dat het certificaat niet\n                                                gevonden is.\n\nNaam\n\nUpdateRanking\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nSysteemkaartnummer\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u20186A 82\u2019H Certificaat niet aanwezig op chauffeurskaart\n\nIndien het certificaat behorende bij het systeemkaartnummer aanwezig is in EF.BCT_Certificates,\n                                          wordt deze als meest recente in de Rank gezet.\n\nVoor deze functie moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.BCT_Certificates met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 02\u2019H.\n\n2. Lees Index_1 t/m Index_3 met het commando Read Binary met offset = 3 (\u201800 03\u2019H) en\n                                                het aantal verwachte bytes in de response 21 (\u201815\u2019H) en controleer of \u00e9\u00e9n hiervan\n                                                overeenkomt met het systeemkaartnummer.\n\nZo niet, geef dan de foutcode terug dat het bijbehorende certificaat niet aanwezig\n                                                is.\n\nZo ja, lees dan de bijbehorende Rank_Highest\n\n\u2013 Voor Rank_1 t/m Rank_3, met uitzondering van Rank_Highest: als de inhoud van Rank_x\n                                                      < inhoud Rank_Highest en > 0, verhoog dan de inhoud van Rank_x dan met 1. Maak Rank_Highest\n                                                      = \u201801\u2019.\n\n\u2013 Geef \u201890 00\u2019H terug.\n\nNaam\n\nGetCertificate\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nSysteemkaartnummer\n\nResultaat\n\nCertificate||\u201890 00\u2019H OK\n\n\u20186A 82\u2019H Certificaat niet aanwezig op chauffeurskaart\n\nIndien het certificaat behorende bij het systeemkaartnummer aanwezig is in EF.BCT_Certificates,\n                                          wordt dit als resultaat terug gegeven.\n\nVoor deze functie moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.BCT_Certificates met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 02\u2019H.\n\n2. Lees Index_1 t/m Index_3 met het commando Read Binary met offset = 3 (\u201800 03\u2019H) en\n                                                het aantal verwachte bytes in de response 21 (\u201815\u2019H) en controleer of \u00e9\u00e9n hiervan\n                                                overeenkomt met het systeemkaartnummer.\n\nZo niet, geef dan de foutcode terug dat het bijbehorende certificaat niet aanwezig\n                                                is.\n\nZo ja, ga dan door met stap 3.\n\n3. Voer Read Binary commando\u2019s uit tot Length_1 (de certificaatlengte) bytes gelezen\n                                                zijn. Per Read Binary kan een maximaal aantal bytes gelezen worden. Dit maximum is\n                                                van een aantal factoren afhankelijk (zie referentie [7]) en wordt hier max_read genoemd.\n                                                De eerste Read Binary heeft als offset de offset voor Certificate_x en het verwachte\n                                                aantal bytes \u201800\u2019H (in het geval dat Length_1 < max_read, dan wordt het verwachte\n                                                aantal bytes Length_1). Voor iedere volgende Read Binary wordt de offset met max_read\n                                                verhoogd. Het verwachte aantal bytes in de response is \u201800\u2019H, behalve bij de laatste\n                                                Read Binary, daar is het Length_1 modulo max_read.\n\n4. geef het resultaat || \u201890 00\u2019H terug.\n\nNaam\n\nStoreCertificate\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nSysteemkaartnummer, certificaat\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van smartcard implementatie\n\nHet systeemkaartnummer wordt met het bijbehorende certificaat als meest recente opgeslagen\n                                          in EF.BCT_Certificates. Hierbij wordt de plaats van het minst recente certificaat\n                                          overschreven.\n\nVoor deze functie moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.BCT_Certificates met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 02\u2019H.\n\n2. Lees Rank_1 t/m Rank_3 met het commando Read Binary met offset = 0 en het aantal verwachte\n                                                bytes in de response 3, en zoek de eerste waarde \u201800\u2019 of \u201803\u2019. Dit is Rank_target.\n\n3. Sla het systeemkaartnummer op in Index_target met het commando Update Binary met offset\n                                                = de offset voor Index_target en het systeemkaartnummer als data.\n\n4. Sla het certificaat op in Certificate_target met een reeks Update Binary commando\u2019s\n                                                met de offset van het eerste commando gelijkgezet aan de offset voor Certificate_target\n                                                en telkens de volgende max_write bytes van het certificaat als data. Indien het certificaat\n                                                korter is dan de gereserveerde lengte voor het certificaat, vul bij het laatste Update\n                                                Binary commando de rest dan aan met nullen (\u201800\u2019).\n\nNB. de hoogte van max_write is van een aantal factoren afhankelijk (zie referentie\n                                                [7]).\n\n5. Voor Rank_1 t/m Rank_3, met uitzondering van Rank_target: als de inhoud van Rank_x\n                                                > 0, verhoog de inhoud dan met 1. Maak Rank_target = \u201801\u2019.\n\n6. Geef \u201890 00\u2019H terug.\n\nNaam\n\nGetLastDownloadLog\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\ngeen\n\nResultaat\n\nDownloadLog || \u201890 00\u2019H OK\n\n\u20186A 82\u2019H DownloadLog niet aanwezig op chauffeurskaart\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van smartcard implementatie\n\nVoor deze functie moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.BCT_Certificates met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 02\u2019H.\n\n2. Lees IndexOldestDL met het commando Read Binary met offset = \u201818 B4\u2019H en het aantal\n                                                verwachte bytes in de response 1\n\n3. Indien de gelezen waarde \u201800\u2019H is, zet dan de IndexNewestDL (variabele in het geheugen)\n                                                op 7, anders wordt de IndexNewestDL gelijkgesteld aan IndexOldestDL \u2013 1.\n\n4. Bereken nu de offset van de (meest recente) DownloadLog_X behorende bij IndexNewestDL\n                                                als volgt: offset_x = \u201818 B5\u2019H + 33 x IndexNewestDL.\n\n5. Lees de aangeduide DownloadLog_X met het commando Read Binary met offset = offset_x\n                                                en het verwachte aantal bytes in de respons 33.\n\n6. Indien de respons uit 33 nullen (\u201800\u2019H) bestaat, geef dan de foutcode terug dat er\n                                                geen DownloadLog records aanwezig zijn, retourneer anders de gelezen respons || \u201890\n                                                00\u2019H.\n\nNaam\n\nStoreDownloadLog\n\nGebruik\n\nChauffeurskaart\n\nInput gegevens\n\nDownloadLog\n\nResultaat\n\n\u201890 00\u2019H OK\n\n\u2018xx xx\u2019H Foutcode van een van de gebruikte commando\u2019s, afhankelijk van smartcard implementatie\n\nHet in de Input opgegeven DownloadLog wordt als het meest recente opgeslagen in DownloadLogs\n                                          van EF.BCT_Certificates. Hierbij wordt de plaats van het minst recente DownloadLog\n                                          overschreven.\n\nVoor deze functie moeten de volgende stappen doorlopen worden:\n\n1. Selecteer EF.BCT_Certificates met het commando Select met P1P2 = \u201804 0C\u2019H en data\n                                                = \u2018E8 28 BD 08 0F A0 00 00 01 67 45 53 49 47 4E\u2019H, gevolgd door het commando Select\n                                                met P1P2 = \u201802 0C\u2019H en data = \u201844 02\u2019H.\n\n2. Lees IndexOldestDL met het commando Read Binary met offset = \u201818 B4\u2019H en het aantal\n                                                verwachte bytes in de response 1\n\n3. Sla het gegeven DownloadLog op in DownloadLogs met het commando Update Binary met\n                                                offset = \u201818 B5\u2019H + 33 x IndexOldestDL. en het DownloadLog als data.\n\n4. Indien de gelezen IndexOldestDL \u201807\u2019H is, zet dan index_new = \u201800\u2019H, zet anders index_new\n                                                op IndexOldestDL + 1.\n\n5. Sla de bijgewerkte index op met het commando Update Binary met offset = \u201818 B4\u2019H en\n                                                index_new (1 byte) als data.\n\n6. Geef \u201890 00\u2019H terug.\n\nDe communicatie met de boordcomputerkaarten gebeurt door middel van commando-antwoord\n                                       paren. Het commando wordt naar de boordcomputerkaart toegestuurd en daarop komt een\n                                       antwoord terug.\n\nEen commando bestaat uit:\n\n\u2022 een Class byte (CLA),\n\n\u2022 een Instruction byte (INS),\n\n\u2022 een Parameter 1 byte (P1),\n\n\u2022 een Parameter 2 byte (P2),\n\n\u2022 een Lengte gegevens byte (Lc) in het geval er gegevens zijn,\n\n\u2022 gegevens (Data), optioneel\n\n\u2022 een verwachte lengte antwoord byte (Le), optioneel.\n\nEen antwoord bestaat uit:\n\n\u2022 gegevens (Data), optioneel\n\n\u2022 statuswoorden (SW1-SW2)\n\nDit hoofdstuk geeft enkele tips voor het gebruik van de commando\u2019s voor het selecteren,\n                                       uitlezen en beschrijven van transparante elementaire files (transparent EF\u2019s). Voor\n                                       de exacte opbouw van de commando-antwoord paren wordt echter verwezen naar Referentie\n                                       [7].\n\nDe paragrafen hieronder vermelden bepaalde file identifiers en short EF identifiers.\n                                       Voor een volledig overzicht van de beschikbare short EF identifiers (SFIDs) wordt\n                                       verwezen naar Referenties [8] t/m [12].\n\nVoordat een EF kan worden uitgelezen of beschreven, dient deze geselecteerd te worden.\n                                          Voordat een EF geselecteerd kan worden, dient eerst de Dedicated File (DF) waar deze\n                                          EF onderdeel van uitmaakt te worden geselecteerd. Conform Referenties [8] t/m [12]\n                                          bevat elke BCT kaart de volgende twee DF\u2019s:\n\n1. De Master File (MF)\n\nte selecteren met INS P1 P2 Lc Data = \u2018A0 00 0C 02 3F00\u2019H\n\n2. De Application DF (DF.CIA)\n\nte selecteren met INS P1 P2 Lc Data = \u2018A4 04 0C 0F E828BD080FA000000167455349474E\u2019H\n\nDe verwachte respons op elk van de bovenstaande commando\u2019s is SW1-SW2 = \u201990 00\u2019H.\n\nNadat de betreffende DF is geselecteerd, kan elke daarin opgenomen EF op een van de\n                                          volgende wijzen worden geselecteerd:\n\n1. Met een expliciete SELECT op basis van de 2-bytes file identifier (FID):\n\nINS P1 P2 Lc Data = \u2018A4 02 0C 02 (FID)\n\n2. Met een expliciete SELECT inclusief opvragen van de file control parameters:\n\nINS P1 P2 Lc Data Le = \u2018A4 02 04 02 (FID) 00\n\n3. Met een impliciete SELECT als onderdeel van het data handling commando:\n\na. Voor offsets < 256:\n\nINS = INS met bit1 = 0 (EVEN instruction)\n\nP1 = bit8 t/m bit6 = 100b || bit5 t/m bit1 = short EF id\n\nP2 = offset [0...255]\n\nLc Data Le = afhankelijk van de instructie\n\nb. Voor 0 <= offsets < \u221e:\n\nINS = INS met bit1 = 1 (ODD instruction)\n\nP1P2 = bit16 t/m bit6 = 0...0b || bit5 t/m bit1 = short EF id\n\nof\n\nP1P2 = file identifier\n\nLc = de lengte van Data\n\nData = minimaal een \u201coffset data object\u201d met tag = 54h\n\nLe = afhankelijk van de instructie\n\nAls voorbeeld van effici\u00ebnt coderen volgt hier de kleinste commandoreeks waarmee de\n                                          4e t/m 7e byte (willekeurig voorbeeld) van EF.BCT_Certificates kunnen worden uitgelezen:\n\nINS\n\nP1\n\nP2\n\nLc\n\nData\n\nLe\n\nBetekenis\n\nA4\n\n04\n\n0C\n\n0F\n\nE828BD080F\n\nA000000167\n\n455349474E\n\nSelecteer de DF.CIA obv de AID\n\nB0\n\n94\n\n03\n\n04\n\nImpliciete SELECT van SFID = 14h, gevolgd door uitlezen van 4 bytes vanaf offset 3\n\nAls voorbeeld van effici\u00ebnt coderen volgt hier het kleinste commando waarmee de 4000e t/m 4050e byte (willekeurig voorbeeld) van de momenteel geselecteerde EF kunnen worden uitgelezen:\n\nINS\n\nP1\n\nP2\n\nLc\n\nData\n\nLe\n\nBetekenis\n\nB0\n\n1F\n\n3F\n\n33\n\nLees 51 (33h) bytes vanaf offset 7999 (1F3Fh) uit de momenteel geselecteerde EF.\n\nAls voorbeeld van effici\u00ebnt coderen volgt hier de kleinste commandoreeks waarmee de\n                                          40000e t/m 40001e byte en dan de 40002e t/m 40003e byte (willekeurig voorbeeld) van de nog niet eerder geselecteerde EF.Driver_Activity_Data\n                                          kunnen worden uitgelezen (uitgangspunt is dat de DF.CIA wel al geselecteerd is):\n\nINS\n\nP1\n\nP2\n\nLc\n\nData\n\nLe\n\nBetekenis\n\nB1\n\n00\n\n13\n\n04\n\n54 02 9C3F\n\n02\n\nSelecteer de EF met short file identifier (SFI) 13h en lees 2 (02h) bytes vanaf offset\n                                                         39999 (9C3Fh) uit die EF.\n\nB1\n\n00\n\n00\n\n04\n\n54 02 9C41\n\n02\n\nLees de volgende 2 bytes uit diezelfde EF.\n\nOmdat EF.Driver_Activity_Data per chauffeurskaart een eigen grootte heeft, is het\n                                          noodzakelijk om minimaal \u00e9\u00e9n keer per kaartsessie te achterhalen wat die grootte exact\n                                          is. Hiervoor biedt de chip (conform referentie [7]) en diens personalisatie de mogelijkheid\n                                          om van EF\u2019s de file control parameters (FCP) op te vragen. Er van uitgaande dat de\n                                          DF.CAI reeds is geselecteerd, is het betreffende commando voor de EF.Driver_Activity_Data\n                                          als volgt:\n\nINS\n\nP1\n\nP2\n\nLc\n\nData\n\nLe\n\nBetekenis\n\nA4\n\n02\n\n04\n\n02\n\n4401\n\n00\n\nA4 = SELECT\n\n02 = selecteer een EF\n\n04 = vraag ook om FCP\n\n02 = lengte van Data\n\n4401 = EF file identifier\n\n00 = retourneer alle beschikbare bytes\n\nDe chips zijn zodanig geprogrammeerd dat dit resulteert in de volgende respons (voorbeeld):\n\n62 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\n                                          05 90 00\n\nDe betekenis van deze respons is hieronder uitgewerkt:\n\nBytes\n\nBetekenis\n\n62 1B\n\nHier volgen 27 (1Bh) bytes met FCP informatie\n\n80 02 xx xx\n\nDe lengte van de file is gecodeerd in 2 bytes en bedraagt xxxx\n\n82 01 01\n\nHet file descriptor byte is 01h; het betreft een transparante EF\n\n83 02 44 01\n\nDe file identifier van deze file is 4401h\n\n88 01 98\n\nDe short file identifier van deze file is 13h\n\n(deze is gecodeerd in b8 t/m b4 van het derde byte, omdat b3 t/m b1 0 zijn):\n\n10011000\n\nA1 08\n\nHier volgen 8 bytes met proprietary security attributen (dit zijn voorbeelden. Voor\n                                                         daadwerkelijke invulling zie Referentie [7])\n\n8C 02 01 00\n\n2 bytes met proprietary security attributen voor contactchip\n\n9C 02 01 00\n\n2 bytes met proprietary security attributen voor contactloze chip\n\n8A 01 05\n\nHet life cycle status byte van deze EF is 05h (operational state \u2013 activated)\n\n90 00\n\nSW1-SW2 geeft \u201cNormal processing\u201d aan\n\nVoor een compleet overzicht van FCP wordt verwezen naar \u00a7 3.3.4.1 van Referentie [7].\n\nDe onderstaande referenties worden in dit document gebruikt:\n\n[1] [1] ISO/IEC 7816-4 Identification cards \u2013 Integrated circuit cards \u2013 Part 4: Organization,\n                                             security and commands for interchange. Edition: 2005.\n\n[2] ISO/IEC 7816-8 Identification cards \u2013 Integrated circuit cards \u2013 Part 8: Commands\n                                             for security operations. Edition: 2004.\n\n[3] ISO/IEC 7816-15 Identification cards \u2013 Integrated circuit cards with contacts \u2013 Part\n                                             15: Cryptographic information application (2004-01-15).\n\n[4] ISO/IEC 9797-1 Information technology \u2013 Security techniques \u2013 Message Authentication\n                                             Codes (MACs) \u2013 Part 1: Mechanisms using a block cipher.\n\n[5] [9] ISO/IEC 9797-2 Information technology \u2013 Security techniques \u2013 Message Authentication\n                                             Codes (MACs) \u2013 Part 2: Mechanisms using a dedicated hash-function.\n\n[6] [11] CWA 14890-1 Application Interface for smart cards used as Secure Signature Creation\n                                             Devices \u2013 Part 1: Basic requirements. March 2004.\n\n[7] [13] European card for e-services and national e-ID applications (IAS ECC) \u2013 Technical\n                                             Specifications \u2013 Revision 1.0.1 \u2013 February 2009.\n\n[8] BCT Kaartstructuur Systeemkaart v1.6. Inspectie Verkeer en Waterstaat.\n\n[9] BCT Kaartstructuur Chauffeurskaart v1.6. Inspectie Verkeer en Waterstaat.\n\n[10] BCT Kaartstructuur Ondernemerskaart v1.6. Inspectie Verkeer en Waterstaat.\n\n[11] BCT Kaartstructuur Keuringskaart v1.6. Inspectie Verkeer en Waterstaat.\n\n[12] BCT Kaartstructuur Inspectiekaart v1.6. Inspectie Verkeer en Waterstaat.\n\n[13] BCT Certificaatprofielen en CRL model BCT kaarten v1.2. Inspectie Verkeer en Waterstaat.\n\n[14] \n                                             Regeling specificaties en typegoedkeuring boordcomputer taxi. Inspectie Verkeer en\n                                             Waterstaat.\n\n[15] Certificaatprofielen BCT Kaart CA's v1.0. Inspectie Verkeer en Waterstaat.\n\n[16] Generieke certificaatprofielen MinVenW PKIoverheid CSP v1.1, Ministerie van Verkeer\n                                             en Waterstaat\n\nDe onderstaande begrippen en afkortingen worden in dit document gebruikt:\n\nATR\n\nAntwoord op terugstellen\n\nBCT\n\nBoordComputer Taxi\n\nCBC\n\nCipher Block Chaining\n\nCC\n\nCryptografische controlesom\n\nCG\n\nCryptogram\n\nCH\n\nCommando-kop\n\nCLA\n\nKlasse byte in CH\n\nD()\n\nDecodering met DES\n\nDES\n\nData encryptie standaard\n\nDO\n\nGegevensobject\n\nE()\n\nCodering met DES\n\nHash\n\nHashing\n\nINS\n\nInstructie byte in CH\n\nIVW\n\nInspectie Verkeer en Waterstaat\n\nLc\n\nLengte van de data in een commando\n\nLe\n\nLengte van het verwachte antwoord in een commando\n\nMAC\n\nMessage Authentication Code\n\nPB\n\nPadding bytes\n\nPI\n\nPadding indicatorbyte (voor gebruik bij cryptogram voor vertrouwelijkheid DO)\n\nPIN\n\nPersoonlijk identificatie nummer\n\nPKCS\n\nPublic Key Cryptography Standards\n\nPUK\n\nPIN unblock key\n\nPV\n\nOngecodeerde waarde\n\nP1\n\nParameter 1 byte in CH\n\nP2\n\nParameter 2 byte in CH\n\nRSA\n\nAsymmetrisch encryptiealgoritme\n\nSSC\n\nZendsequentieteller\n\nSM\n\nBeveiligde overbrenging\n\nSW\n\nStatus woord (2 bytes) in een antwoord\n\nTLV\n\nLabel \u2013 lengte \u2013 waarde\n\nXOR\n\nExclusieve disjunctie\n\n\u2018xx'B\n\nBit waarde\n\n\u2018xx'H\n\nHexadecimale waarde\n\n3DES\n\nDrievoudig DES algoritme\n\n||\n\nVerbindingsoperator\n\nHieronder volgt een aantal scenario\u2019s die het wegschrijven van gegevens op de chauffeurskaart\n                                       tijdens een kaartsessie toelichten.\n\n\u2022 De kaartsessie wordt begonnen met het inbrengen van de chauffeurskaart in de boordcomputer.\n\n\u2022 Er zijn geen wijzigingen of aanvullingen sinds de vorige kaartsessie.\n\n\u2022 Diverse activiteiten vinden plaats en worden op de chauffeurskaart opgeslagen.\n\n\u2022 De kaartsessie wordt normaal afgesloten waarna de chauffeurskaart uit de boordcomputer\n                                                genomen kan worden.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nLogin\n\n8:00:00\n\n\u20180\u2019B\n\nStart werk\n\n8:00:00\n\n\u20180\u2019B\n\nStart pauze\n\n10:30:00\n\n\u20180\u2019B\n\nStart werk\n\n11:00:00\n\n\u20180\u2019B\n\nAfsluiting\n\n13:15:00\n\n\u20180\u2019B\n\n\u2022 Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint.\n                                                Hierna wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer\n                                                genomen.\n\n\u2022 Na het opnieuw inbrengen van de chauffeurskaart constateert de boordcomputer dat de\n                                                vorige sessie na een \u201cStart pauze\u201d werd afgesloten. Omdat een arbeidsperiode hiermee\n                                                lijkt te eindigen met een pauze, wordt de chauffeur hier extra op geattendeerd. Sowieso\n                                                vraagt de boordcomputer of er nog activiteiten moeten worden toegevoegd sinds de laatste\n                                                activiteit. De chauffeur besluit zijn bezigheden (pauze genieten) tussen die laatste\n                                                afsluiting en het huidige inlogmoment handmatig te boeken, om te voorkomen dat hij\n                                                de periode tussen afsluiten en inloggen niet kan verantwoorden.\n\n\u2022 Omdat bij het inbrengen van de chauffeurskaart standaard een \u201cStart werk\u201d toegevoegd\n                                                wordt, hoeft de chauffeur, na de handmatige toevoeging, het hervatten van werk niet\n                                                expliciet aan te geven.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart pauze\n\n13:14:30\n\n\u20180\u2019B\n\nn\n\nAfsluiting\n\n13:15:00\n\n\u20180\u2019B\n\nn\n\nStart pauze\n\n13:15:00\n\n\u20181\u2019B\n\nn+1\n\nLogin\n\n13:45:00\n\n\u20180\u2019B\n\nn+1\n\nStart werk\n\n13:45:00\n\n\u20180\u2019B\n\nn+1\n\n...\n\nn+1\n\n\u2022 Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint.\n                                                Hierna wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer\n                                                genomen.\n\n\u2022 Na het opnieuw inbrengen van de chauffeurskaart constateert de boordcomputer dat de\n                                                vorige sessie na een \u201cStart pauze\u201d werd afgesloten. Omdat een arbeidsperiode hiermee\n                                                lijkt te eindigen met een pauze, wordt de chauffeur hier extra op geattendeerd. Sowieso\n                                                vraagt de boordcomputer of er nog activiteiten moeten worden toegevoegd sinds de laatste\n                                                activiteit. De chauffeur besluit zijn bezigheden (pauze genieten) na die laatste afsluiting\n                                                handmatig te boeken.\n\n\u2022 De werkzaamheden waren in werkelijkheid echter eerder gestart dan het moment van inloggen,\n                                                daarom wordt voorafgaand aan het inlogmoment ook nog handmatig een \u201cStart werk\u201d toegevoegd.\n                                                De pauze stopt hiermee dus eerder dan het inlogmoment.\n\n\u2022 De boordcomputer boekt zelf ook nog een \u201cStart werk\u201d na de inlogboeking.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart pauze\n\n13:14:30\n\n\u20180\u2019B\n\nn\n\nAfsluiting\n\n13:15:00\n\n\u20180\u2019B\n\nn\n\nStart pauze\n\n13:15:00\n\n\u20181\u2019B\n\nn+1\n\nStart werk\n\n13:30:00\n\n\u20181\u2019B\n\nn+1\n\nLogin\n\n13:45:00\n\n\u20180\u2019B\n\nn+1\n\nStart werk\n\n13:45:00\n\n\u20180\u2019B\n\nn+1\n\n...\n\nn+1\n\n\u2022 Na de laatste activiteit wordt de kaartsessie afgesloten en de chauffeurskaart uit\n                                                de boordcomputer genomen.\n\n\u2022 Bij het inbrengen van de chauffeurskaart in de boordcomputer de volgende dag, wordt\n                                                gevraagd of er nog activiteiten sinds het einde van de vorige kaartsessie zijn geweest.\n                                                Dat is het geval, want er zijn de vorige dag, na het verlaten van de auto, nog andere\n                                                werkzaamheden verricht. Dit wordt eerst toegevoegd.\n\n\u2022 Daarna kunnen de activiteiten voor de nieuwe dag beginnen.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart werk\n\n13:00:00\n\n\u20180\u2019B\n\nn\n\nAfsluiting\n\n15:15:00\n\n\u20180\u2019B\n\nn\n\nStart werk\n\n15:15:00\n\n\u20181\u2019B\n\nn+1\n\nNieuwe eindtijd\n\n16:15:00\n\n\u20181\u2019B\n\nn+1\n\nHier wordt ook een nieuw DailyRecord met een eerste SessionRecord ingevoegd\n\nLogin\n\n9:00:00\n\n\u20180\u2019B\n\nn+2\n\nStart werk\n\n9:01:00\n\n\u20180\u2019B\n\nn+2\n\n...\n\nn+2\n\n\u2022 Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint.\n                                                Hierna wordt de kaartsessie afgesloten en de chauffeurskaart uit de boordcomputer\n                                                genomen.\n\n\u2022 Later blijkt dat de pauze niet doorgegaan is en dat in plaats daarvan andere werkzaamheden\n                                                verricht zijn tot het huidige tijdstip.\n\n\u2022 Bij het inbrengen van de chauffeurskaart in de boordcomputer moet dit gecorrigeerd\n                                                worden. De boordcomputer zal de bestuurder attenderen op het feit dat de laatstgeboekte\n                                                en afgesloten activiteit een pauze was. Na het bevestigen van de vraag of er nog handmatig\n                                                activiteiten moeten worden toegevoegd, kan de chauffeur een \u201cStart werk\u201d laten ingaan\n                                                op hetzelfde moment dat de \u201cStart pauze\u201d begon. De pauze wordt hiermee in feite overschreven\n                                                door andere werkzaamheden.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart pauze\n\n16:40:00\n\n\u20180\u2019B\n\nn\n\nAfsluiting\n\n16:41:00\n\n\u20180\u2019B\n\nn\n\nStart werk\n\n16:40:00\n\n\u20181\u2019B\n\nn+1\n\nLogin\n\n17:10:00\n\n\u20180\u2019B\n\nn+1\n\nStart werk\n\n17:11:00\n\n\u20180\u2019B\n\nn+1\n\n...\n\nn+1\n\n\u2022 Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint.\n                                                De chauffeur neemt de kaart uit zonder dat de kaartsessie is afgesloten. Hierop blokkeert\n                                                de boordcomputer deze kaartsessie.\n\n\u2022 Enige tijd later (binnen de 60 minuten) wordt de chauffeurskaart weer in de boordcomputer\n                                                ingebracht. Omdat het dezelfde kaart is als waarvan de kaartsessie geblokkeerd is,\n                                                zal de boordcomputer deze blokkering opheffen.\n\n\u2022 Omdat de kaart wel even verwijderd is geweest, zal de boordcomputer de chauffeur vragen\n                                                of er sinds de \u201cStart pauze\u201d nog (andere) activiteiten zijn geweest. Aangezien dit\n                                                niet het geval was, maakt de chauffeur geen gebruik van de mogelijkheid tot het handmatig\n                                                toevoegen van activiteiten.\n\n\u2022 De boordcomputer boekt nu de login automatisch gevolgd door een \u201cStart werk\u201d (na inloggen\n                                                moet een boordcomputer namelijk altijd in werkniveau terechtkomen). Gezien het echter\n                                                nog pauze is, zal de chauffeur direct ingeven dat het (nog steeds/weer) pauze is.\n                                                Vanaf nu is het echter pauze met de kaart in de boordcomputer.\n\n\u2022 De chauffeur be\u00ebindigt de pauze op het ogenblik dat hij weer gaat werken.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\nOpmerking\n\n...\n\nn\n\nStart pauze\n\n15:00:00\n\n\u20180\u2019B\n\nn\n\n(kaart uitnemen)\n\nn\n\nSessie geblokkeerd op BCT\n\nn\n\nSessie geblokkeerd op BCT\n\n(kaart inbrengen)\n\nn\n\nGeen handm. toevoegingen\n\nLogin\n\n15:30:00\n\n\u20180\u2019B\n\nn\n\nIngevoegd door BCT\n\nStart werk\n\n15:30:00\n\n\u20180\u2019B\n\nn\n\nIngevoegd door BCT\n\nStart pauze\n\n15:30:30\n\n\u20180\u2019B\n\nn\n\n(terug)gezet door bestuurder\n\nStart werk\n\n15:40:00\n\n\u20180\u2019B\n\nn\n\nAangegeven door bestuurder\n\n...\n\nn\n\n\u2022 Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint.\n                                                De chauffeur neemt zijn kaart uit de boordcomputer zonder af te sluiten. Hierop blokkeert\n                                                de boordcomputer de kaartsessie.\n\n\u2022 Daarna wordt er met het voertuig gereden, zonder een chauffeurskaart (in zijn pauze\n                                                is dit toegestaan).\n\n\u2022 Binnen 60 minuten na het uitnemen wordt de chauffeurskaart weer in de boordcomputer\n                                                gebracht, dus de kaartsessie is nog geblokkeerd. Het is dezelfde kaart die ingebracht\n                                                wordt als die waarvan de kaartsessie geblokkeerd is en dus wordt de blokkering opgeheven.\n\n\u2022 De chauffeur begint weer met werken.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart pauze\n\n16:00:00\n\n\u20180\u2019B\n\nn\n\n(kaart uitnemen)\n\nn\n\nn\n\n(rijden zonder chauffeurskaart)\n\nn\n\nn\n\n(kaart inbrengen)\n\nn\n\nLogin\n\n16:25:00\n\n\u20180\u2019B\n\nn\n\nStart werk\n\n16:25:00\n\n\u20180\u2019B\n\nn\n\n...\n\nn\n\n\u2022 Bij een bestaande kaartsessie wordt op de boordcomputer ingegeven dat de pauze begint.\n                                                De chauffeur neemt zijn kaart uit de boordcomputer zonder af te sluiten. Hierop blokkeert\n                                                de boordcomputer de kaartsessie.\n\n\u2022 Aangezien er na 60 minuten nog niets gebeurd is, wordt op de boordcomputer de geblokkeerde\n                                                kaartsessie automatisch afgesloten.\n\n\u2022 Als de chauffeur daarna zijn kaart weer in de boordcomputer brengt, wordt gesignaleerd\n                                                dat de sessie op de kaart niet goed afgesloten was.\n\n\u2022 Verder wordt gevraagd of er nog activiteiten sinds het einde van de vorige kaartsessie\n                                                zijn geweest. Dat is zo, want de pauze was eigenlijk binnen de 60 minuten afgelopen\n                                                waarna andere werkzaamheden zijn begonnen.\n\n\u2022 Omdat op de boordcomputer de sessie al be\u00ebindigd was, wordt een nieuwe kaartsessie\n                                                begonnen.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart pauze\n\n16:00:00\n\n\u20180\u2019B\n\nn\n\n(kaart uitnemen om 16:00:02)\n\n(sessie time-out om 17:00:02)\n\n(kaart inbrengen om 17:25:00)\n\n(nieuw sessierecord)\n\nStart werk\n\n16:30:00\n\n\u20181\u2019B\n\nn+1\n\nLogin\n\n17:25:00\n\n\u20180\u2019B\n\nn+1\n\nStart werk\n\n17:26:00\n\n\u20180\u2019B\n\nn+1\n\n...\n\n\u2022 Boordcomputer A: de laatstgeboekte activiteit is \u201cStart werk\u201d en de chauffeur neemt\n                                                zijn kaart uit de boordcomputer zonder af te sluiten. Hierop blokkeert de boordcomputer\n                                                de kaartsessie (n). Er vinden voorlopig geen andere activiteiten plaats.\n\n\u2022 Boordcomputer B: de chauffeurskaart wordt binnen de 60 minuten na het uitnemen uit\n                                                boordcomputer A ingebracht in B:\n\n\u2022 Er wordt geconstateerd dat de vorige sessie (op A) niet goed afgesloten is.\n\n\u2022 Er wordt een nieuwe kaartsessie (n+1) gestart.\n\n\u2022 Er wordt gevraagd of er nog andere werkzaamheden of pauze moeten worden toegevoegd\n                                                      of aangepast. Hierbij geeft de chauffeur aan dat hij 10 minuten voor het inloggen\n                                                      met pauze ging, waarmee de periode tussen uitnemen van de kaart en de start van die\n                                                      pauze kan worden beschouwd als een voortzetting van het werk (buiten de auto). Hierna\n                                                      worden geen andere handmatige activiteiten opgevoerd, waardoor de boordcomputer het\n                                                      inloggen zal boeken en in werkniveau zal gaan staan.\n\n\u2022 Nieuwe activiteiten worden opgeslagen op de kaart.\n\n\u2022 De kaartsessie wordt afgesloten binnen de 60 minuten na het uitnemen uit boordcomputer\n                                                      A.\n\n\u2022 Hierna werkt de chauffeur een kwartiertje buiten de auto.\n\n\u2022 Boordcomputer A: de chauffeurskaart wordt ingebracht na het kwartiertje werk, maar\n                                                nog steeds binnen 60 minuten na het uitnemen uit boordcomputer A. Op boordcomputer\n                                                A is de kaartsessie dus nog steeds geblokkeerd:\n\n\u2022 Het is dezelfde kaart die ingebracht wordt als die waarvan de kaartsessie geblokkeerd\n                                                      is en dus wordt de blokkering opgeheven.\n\n\u2022 Aangezien bij het uitlezen van de kaart gezien wordt dat er in de tussentijd een kaartsessie\n                                                      op een andere boordcomputer is geweest, kan de gedeblokkeerde sessie niet worden voortgezet,\n                                                      maar zal op boordcomputer A een nieuwe sessie (n+2) starten.\n\n\u2022 De boordcomputer biedt de chauffeur de mogelijkheid om de laatste activiteit van de\n                                                      vorige sessie (n+1) te vervangen, te wijzigen of aan te vullen. Hiervan maakt de chauffeur\n                                                      gebruik door een handmatige \u201cStart werk\u201d op te voeren die start op het tijdstip dat\n                                                      die vorige sessie (n+1) werd afgesloten. Het \u201ckwartiertje werk\u201d is hiermee verantwoord.\n\n\u2022 Dan boekt boordcomputer A het nieuwste login tijdstip en gaat over tot niveau werken.\n\n\u2022 De nieuwe kaartsessie (n+2) verloopt verder normaal.\n\nActiviteit\n\nTijdstip\n\nHandm.\n\nSessionRecord\n\n...\n\nn\n\nStart werk\n\n16:00:00\n\n\u20180\u2019B\n\nn\n\n(kaart uitnemen uit A om 17:00)\n\nn\n\n(kaart inbrengen in B om 17:25)\n\n(nieuw sessierecord)\n\nStart pauze (10 min pauze gehad)\n\n17:15:00\n\n\u20181\u2019B\n\nn+1\n\nLogin\n\n17:25:00\n\n\u20180\u2019B\n\nn+1\n\nStart werk\n\n17:25:00\n\n\u20180\u2019B\n\nn+1\n\nAfsluiting\n\n17:40:00\n\n\u20180\u2019B\n\nn+1\n\n(kaart inbrengen in A om 17:55)\n\n(nieuw sessierecord)\n\nStart werk (opvullen van 15 min)\n\n17:40:00\n\n\u20181\u2019B\n\nn+2\n\nLogin\n\n17:55:00\n\n\u20180\u2019B\n\nn+2\n\nStart werk\n\n17:55:00\n\n\u20180\u2019B\n\nn+2\n\n...\n\nn+2\n\nHieronder volgt een aantal voorbeelden van functies met de uitgewerkte hexadecimale\n                                       codes. Dit geeft een beter inzicht in het toepassen van deze functies in de Boordcomputer\n                                       Taxi.\n\nVoor het opzetten van Secure Messaging, zoals beschreven staat in 4.6, worden de volgende\n                                          stappen uitgevoerd:\n\n1. Lees de inhoud van EF.SN.ICC door middel van een read binary met SFI '1C'h en een\n                                                offset '00'h.\n\nDe laatste 8 bytes van de response data wordt gebruikt als SN.ICC.\n\n2. Selecteer het te gebruiken algoritme voor de mutual authenticate en de symmetrische\n                                                sleutel referentie.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde 'C1'h\n                                                en P2 de waarde 'A4'h. De data bij dit commando is '80 01 8C 83 01 03'h ('8C'h om\n                                                \u201csymmetric mutual authentication algorithm with SHA-256\u201d aan te duiden en '03'h om\n                                                het Security Data Object (SDO) van PKI.KS.SM.ICC aan te duiden).\n\n3. Vraag om een random waarde door middel van Get Challenge.\n\nDe response data is de RND.ICC.\n\n4. Genereer een random waarde van 8 bytes voor RND.IFD, een random waarde van 32 bytes\n                                                voor K.IFD en bepaal een serienummer SN.IFD van 8 bytes.\n\n5. Stel het bericht S samen:\n\nS = RND.IFD || SN.IFD || RND.ICC || SN.ICC || K.IFD.\n\n6. Bereken de encrypted waarde van S met CBC Triple DES encryptie, ICV '00'h en de encryptie\n                                                sleutel ENC.KEY (laatste 16 bytes van transportkey1):\n\nENC = CBCTDes('00', S, ENC.KEY).\n\n7. Bereken de Retail MAC over de encrypted waarde van S met ICV '00'h en de MAC sleutel\n                                                MAC.KEY (eerste 16 bytes van transportkey1):\n\nMAC = RMac('00', ENC || '80', MAC.KEY).\n\nNB. Gebruik altijd padding met '80 ...' achter de data.\n\n8. Voer een Mutual Authenticate commando uit met als data ENC || MAC.\n\n9. Wanneer de status van de response '90 00'h is, is er ook response data beschikbaar.\n\na. Haal de encrypted data ENC_R en de MAC uit deze data.\n\nb. Bereken de Retail MAC over ENC_R met ICV '00'h en de MAC sleutel MAC.KEY:\n\nMAC_R = RMac('00', ENC_R || '80', MAC.KEY).\n\nOok hier moet weer de padding met '80 ...' gebruikt worden.\n\nc. Bereken de decrypted waarde van ENC_R met Inverse CBC Triple DES encryptie, ICV '00'h\n                                                      en de encryptie sleutel ENC.KEY:\n\nDEC_S = InvCBCTDes('00', ENC_R, ENC.KEY).\n\n10. Wanneer de berekende MAC_R gelijk is aan de MAC uit de response data van de Mutual\n                                                Authenticate, dan is DEC_S gelijk aan\n\nRND.ICC || SN.ICC || RND.IFD || SN.IFD || K.ICC.\n\n11. Hieruit kunnen de volgende waardes berekend worden:\n\n\u2022 K_ICC_IFD = K.IFD xor K.ICC\n\n\u2022 SK_ENC = 1e 16 bytes van SHA256(K_ICC_IFD || '00 00 00 01')\n\n\u2022 SK_MAC = 1e 16 bytes van SHA256(K_ICC_IFD || '00 00 00 02')\n\n\u2022 SSC = laatste 4 bytes RND.ICC || laatste 4 bytes RND.IFD\n\nNa het opzetten van de secure messaging verbinding, moeten alle volgende commando's\n                                          met secure messaging uitgevoerd worden. Dit staat beschreven in 4.1 t/m 4.5.\n\nHierbij worden de SK_ENC, SK_MAC en SSC gebruikt die na het opzetten van de secure\n                                          messaging verbinding te berekenen zijn (zie hierboven).\n\nOm te komen van een normaal commando tot een commando onder secure messaging, moeten\n                                          de volgende stappen doorlopen worden:\n\n1. Verhoog de SSC met 1.\n\n2. De Cla byte 'xx' wordt 'xC' (Cla').\n\n3. Als het commando data bevat (Lc > 0), dan moet deze data encrypt worden. Bereken de\n                                                encrypted waarde van de data met CBC Triple DES encryptie, ICV '00'h en de encryptie\n                                                sleutel SK_ENC:\n\nENC = CBCTDes('00', data || '80', SK_ENC).\n\nOok hier moet weer de padding met '80 ...' gebruikt worden.\n\n4. De SecuredData waarover een Retail MAC berekend moet worden is afhankelijk van Lc\n                                                en Le:\n\n\u2022 \nLc > 0, Le > 0\n\nSSC || Cla || Ins || P1 || P2 || '80' || '87' || Length(ENC)+1 || '01' || ENC || '97'\n                                                      || Length(Le) || Le || '80'\n\n\u2022 \nLc > 0, Le = 0\n\nSSC || Cla || Ins || P1 || P2 || '80' || '87' || Length(ENC)+1 || '01' || ENC || '80'\n\n\u2022 \nLc = 0, Le > 0\n\nSSC || Cla || Ins || P1 || P2 || '80' || '97' || Length(Le) || Le || '80'\n\n\u2022 \nLc = 0, Le = 0\n\nSSC || Cla || Ins || P1 || P2 || '80'\n\nLet op dat er padding met '80 ...' gebruikt moet worden na P2 en, indien Lc > 0 of\n                                                Le > 0, aan het eind van de data.\n\nDe te gebruiken ICV is '00'h en de te gebruiken sleutel is SK_MAC.\n\n5. Het te versturen commando ziet er dan als volgt uit:\n\nCla' || Ins || P1 || P2 || Length(SecuredData) + 10 || SecuredData || '8E 08'|| MAC\n                                                || '00'\n\n6. Het formaat van de response onder secure messaging is afhankelijk van het terug krijgen\n                                                van data:\n\n\u2022 \ndata terug (even Ins)\n\n'87' || Length(EncryptedData) + 1 || '01'|| EncryptedData || '99 02' || SW || '8E\n                                                      08' || MAC || SW\n\n\u2022 \ndata terug (oneven Ins)\n\n'85' || Length(EncryptedData) || EncryptedData || '99 02' || SW || '8E 08' || MAC\n                                                      || SW\n\n\u2022 \ngeen data terug\n\n'99 02' || SW || '8E 08' || MAC || SW\n\n7. Verhoog de SSC met 1.\n\n8. Bereken een Retail MAC over de volgende data, afhankelijk van het formaat van de response:\n\n\u2022 \ndata terug (even Ins)\n\nSSC || '87' || Length(EncryptedData) + 1 || '01'|| EncryptedData || '99 02' || SW\n                                                      || '80'\n\n\u2022 \ndata terug (oneven Ins)\n\nSSC || '85' || Length(EncryptedData) || EncryptedData || '99 02' || SW || '80'\n\n\u2022 \ngeen data terug\n\nSSC || '99 02' || SW || '80'\n\nIn alle gevallen wordt er op het eind padding met '80' gebruikt.\n\nDe te gebruiken ICV is '00'h en de te gebruiken sleutel is SK_MAC.\n\n9. Vergelijk de berekende Retail MAC met de MAC uit de response. Deze moeten gelijk aan\n                                                elkaar zijn.\n\n10. Zijn de ontvangen en berekende MAC gelijk aan elkaar, dan kan de EncryptedData, indien\n                                                aanwezig, decrypted worden.\n\nBereken de decrypted waarde van EncryptedData met Inverse CBC Triple DES encryptie,\n                                                ICV '00'h en de encryptie sleutel SK_ENC:\n\nDecryptedData = InvCBCTDes('00', EncryptedData, SK_ENC).\n\nZie de tabel hieronder voor een voorbeeld van een commando, het commando met secure\n                                          messaging en het antwoord met secure messaging.\n\nVoor het zetten van een elektronische handtekening met een boordcomputerkaart, zoals\n                                             beschreven staat in 8.5, worden de volgende stappen uitgevoerd:\n\n1. Allereerst moet het hash template met het te gebruiken algoritme geselecteerd worden.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h\n                                                   en P2 de waarde 'AA'h. De data bij dit commando is '80 01 40'h ('40'h om de algoritme\n                                                   identifier voor SHA-256 aan te geven).\n\n2. Selecteer het te gebruiken algoritme en de private sleutel van de BCT Handtekening.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h\n                                                   en P2 de waarde 'B6'h. De data bij dit commando is '80 01 42 84 01 86'h ('42'h om\n                                                   \u201cPKCS#1 v1.5 \u2013 SHA-256\u201d aan te duiden en '86'h om het Security Data Object (SDO) van\n                                                   PKI.CH.DS aan te duiden).\n\n3. De private sleutel van de BCT Handtekening mag pas gebruikt worden nadat de PIN gevalideerd\n                                                   is. Dit is nodig voor iedere keer dat deze sleutel gebruikt wordt. Dit wordt gedaan\n                                                   met het commando Verify, waarbij P2 (de PIN reference) de waarde '01'h heeft. Voor\n                                                   de PIN wordt PIN formaat 2 gebruikt.\n\n4. Wanneer de input gegevens uit meer dan 64 bytes bestaan, moet er een intermediate\n                                                   hash met SHA-256 berekend worden door de boordcomputerlogica. Hierbij wordt het laatste\n                                                   gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte\n                                                   bits onthouden voor de volgende stap.\n\nWanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen\n                                                   intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.\n\n5. Het berekenen van de uiteindelijke hash met SHA-256 wordt door de boordcomputerkaart\n                                                   gedaan. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de \u201cintermediate\n                                                   hash value\u201d, het aantal gehashte bits en het laatste (of enige) blok inputdata van\n                                                   minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een\n                                                   succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het chipgeheugen\n                                                   van de boordcomputerkaart achterblijven ten behoeve van de volgende en laatste stap.\n\n6. Met de gekozen private sleutel wordt de handtekening berekend over de in het chipgeheugen\n                                                   aanwezige hashwaarde.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte\n                                                   aantal bytes in de response, moet daarbij op '00'h staan.\n\n7. Een elektronische handtekening kan gecontroleerd worden op de volgende manier:\n\na. Selecteer het certificaat EF.C.PKI.CH.DS op de boordcomputerkaart.\n\nb. Lees het certificaat met behulp van (meerdere) Read Binary.\n\nc. Haal de Public Exponent en de Modulus uit het certificaat.\n\nd. Voer een RSA decryptie uit van de response data van Compute Digital Signature met\n                                                         de Public Exponent en de Modulus.\n\ne. De decrypted data moet overeenkomen met:\n\n\u201900 01 FF .. FF 00\u2019 || SHA_256_Digest || SHA256(input data),\n\nwaarbij SHA_256_Digest = '30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20'h.\n\nVoor het zetten van een elektronische handtekening met de sleutel-certificaatcombinatie\n                                             PKI.CH.AUT van een boordcomputerkaart, zoals beschreven staat in 8.7, worden de volgende\n                                             stappen uitgevoerd:\n\n1. Allereerst moet het hash template met het te gebruiken algoritme geselecteerd worden.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h\n                                                   en P2 de waarde 'AA'h. De data bij dit commando is '80 01 40'h ('40'h om de algoritme\n                                                   identifier voor SHA-256 aan te geven).\n\n2. Selecteer het te gebruiken algoritme en de private sleutel van de BCT Authenticiteit.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h\n                                                   en P2 de waarde 'B6'h. De data bij dit commando is '80 01 42 84 01 85'h ('42'h om\n                                                   \u201cPKCS#1 v1.5 \u2013 SHA-256\u201d aan te duiden en '85'h om het Security Data Object (SDO) van\n                                                   PKI.CH.AUT aan te duiden).\n\n3. De private sleutel van de BCT Authenticiteit mag pas gebruikt worden nadat de PIN\n                                                   gevalideerd is. Een eenmaal uitgevoerde PIN validatie mag \u2013 zo lang de kaart in de\n                                                   boordcomputer aanwezig blijft \u2013 worden \u201cherbruikt\u201d bij elke volgende keer dat deze\n                                                   sleutel gebruikt word. Dit wordt gedaan met het commando Verify, waarbij P2 (de PIN\n                                                   reference) de waarde '01'h heeft. Voor de PIN wordt PIN formaat 2 gebruikt.\n\n4. Wanneer de input gegevens uit meer dan 64 bytes bestaan, moet er een intermediate\n                                                   hash met SHA-256 berekend worden door de boordcomputerlogica. Hierbij wordt het laatste\n                                                   gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte\n                                                   bits onthouden voor de volgende stap.\n\nWanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen\n                                                   intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.\n\n5. Het berekenen van de uiteindelijke hash met SHA-256 wordt door de boordcomputerkaart\n                                                   gedaan. Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de \u201cintermediate\n                                                   hash value\u201d, het aantal gehashte bits en het laatste (of enige) blok inputdata van\n                                                   minimaal 1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een\n                                                   succesvol uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het chipgeheugen\n                                                   van de boordcomputerkaart achterblijven ten behoeve van de volgende en laatste stap.\n\n6. Met de gekozen private sleutel wordt de handtekening berekend over de in het chipgeheugen\n                                                   aanwezige hashwaarde.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte\n                                                   aantal bytes in de response, moet daarbij op '00'h staan.\n\n7. Een elektronische handtekening kan gecontroleerd worden op de volgende manier:\n\na. Selecteer het certificaat EF.C.PKI.CH.AUT op de boordcomputerkaart.\n\nb. Lees het certificaat met behulp van (meerdere) Read Binary.\n\nc. Haal de Public Exponent en de Modulus uit het certificaat.\n\nd. Voer een RSA decryptie uit van de response data van Compute Digital Signature met\n                                                         de Public Exponent en de Modulus.\n\ne. De decrypted data moet overeenkomen met:\n\n\u201900 01 FF .. FF 00\u2019 || SHA_256_Digest || SHA256(input data),\n\nwaarbij SHA_256_Digest = '30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20'h.\n\nNB. Deze functie moet uitgevoerd worden onder secure messaging, zoals beschreven is in\n                                          B.2. Voor het overzicht worden onderstaande commando\u2019s en responses echter zonder\n                                          deze secure messaging weergegeven.\n\nVoor het zetten van een elektronische handtekening met een systeemkaart, zoals beschreven\n                                          staat in 8.6, worden de volgende stappen uitgevoerd:\n\n1. Allereerst moet het hash template met het te gebruiken algoritme geselecteerd worden.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h\n                                                en P2 de waarde 'AA'h. De data bij dit commando is '80 01 40'h ('40'h om de algoritme\n                                                identifier voor SHA-256 aan te geven).\n\n2. Selecteer het te gebruiken algoritme en de private sleutel van de BCT Authenticiteit.\n\nDit wordt gedaan met het commando Manage Security Environment, met P1 de waarde '41'h\n                                                en P2 de waarde 'B6'h. De data bij dit commando is '80 01 42 84 01 85'h ('42'h om\n                                                \u201cPKCS#1 v1.5 \u2013 SHA-256\u201d aan te duiden en '85'h om het Security Data Object (SDO) van\n                                                PKI.CH.AUT aan te duiden).\n\n3. Wanneer de input gegevens uit meer dan 64 bytes bestaan, moet er een intermediate\n                                                hash met SHA-256 berekend worden door de boordcomputerlogica. Hierbij wordt het laatste\n                                                gegevensblok niet gehashed, maar wordt de intermediate hash en het aantal gehashte\n                                                bits onthouden voor de volgende stap.\n\nWanneer het totaal aan input gegevens uit maximaal 64 bytes bestaat, wordt er geen\n                                                intermediate hash berekend en worden alle inputgegevens in de volgende stap gebruikt.\n\n4. Het berekenen van de uiteindelijke hash met SHA-256 wordt door de systeemkaart gedaan.\n                                                Hiervoor wordt het commando PSO Hash gebruikt. Hierbij worden de \u201cintermediate hash\n                                                value\u201d, het aantal gehashte bits en het laatste (of enige) blok inputdata van minimaal\n                                                1 en maximaal 64 bytes opgenomen in het Dataveld van het commando. Bij een succesvol\n                                                uitgevoerde PSO HASH zal de uiteindelijke hash waarde in het chipgeheugen van de systeemkaart\n                                                achterblijven ten behoeve van de volgende en laatste stap.\n\n5. Met de gekozen private sleutel wordt de handtekening berekend over de in het chipgeheugen\n                                                aanwezige hashwaarde.\n\nDit wordt gedaan met het commando PSO Compute Digital Signature. Le, het verwachte\n                                                aantal bytes in de response, moet daarbij op '00'h staan.\n\n6. Een elektronische handtekening kan gecontroleerd worden op de volgende manier:\n\na. Selecteer het certificaat EF.C.PKI.CH.AUT op de systeemkaart.\n\nb. Lees het certificaat met behulp van (meerdere) Read Binary.\n\nc. Haal de Public Exponent en de Modulus uit het certificaat.\n\nd. Voer een RSA decryptie uit van de response data van Compute Digital Signature met\n                                                      de Public Exponent en de Modulus.\n\ne. De decrypted data moet overeenkomen met:\n\n\u201900 01 FF .. FF 00\u2019 || SHA_256_Digest || SHA256(input data),\n\nwaarbij SHA_256_Digest = '30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20'h."}