Deze bijlage is een beveiligingsprofiel (Protection Profile) voor de voertuigcomponenten van de boordcomputer in overeenstemming met de Common Criteria versie 3.1. Het beveiligingsprofiel geeft een beschrijving van het door de boordcomputer te implementeren beleid, de te realiseren beveiligingsdoelstellingen, en de te behalen beveiligingseisen, alsmede het vereiste garantieniveau voor de boordcomputer, zoals afgeleid is bij een eerdere afhankelijkheids- en kwetsbaarheidsanalyse.

Dit beveiligingsprofiel voor de boordcomputer is opgesteld voor de Inspectie Verkeer en Waterstaat van het Ministerie van Verkeer en Waterstaat.

Dit document is het ‘Beveiligingsprofiel Boordcomputer Taxi’ (PP-BCT) versie 1.3, 9 februari 2010.

Dit beveiligingsprofiel voldoet aan Common Criteria versie 3.1 Revisie 2. Hoewel de ‘International English’ versie is gebruikt voor het ontwikkelen van dit beveiligingsprofiel, is (met toestemming van het certificeringsschema) dit profiel in het Nederlands.

Dit beveiligingsprofiel:

1. ○

   is CC Deel 2 conform;

2. ○

   is CC Deel 3 conform;

3. ○

   is EAL3 conform;

4. ○

   claimt niet te voldoen aan andere beveiligingsprofielen;

5. ○

   vereist strikte conformering van andere beveiligingsprofielen (PPs) of beveiligingsspecificaties (STs) die aan dit beveiligingsprofiel willen voldoen.

Dit document volgt de naamgeving en notaties voor beveiligingsprofielen volgens de Common Criteria standaard. Er zijn unieke labels toegewezen aan entiteiten zodat deze gemakkelijk terug te vinden zijn. De labels beginnen met één van de onderstaande karakters:

De TOE wordt getoetst conform het normenkader van Common Criteria for Information Technology Security Evaluation, versie 3.1, revisie 2, September 2007.

De TOE ondersteunt de volgende standaarden wanneer cryptografische bewerkingen dienen te worden uitgevoerd:

1. ○

   Het SHA cryptografische algoritme voor hash functies zoals gedefinieerd in de ISO/IEC 10118-3, FIPS PUB 180-2 en ETSI TS 102 176-1 standaarden;

2. ○

   ETSI TS 101 733 Electronic Signature Formats en de FIPS PUB 186-2 standaarden voor elektronische handtekeningen;

De TOE is een controleapparaat bedoeld voor installatie in auto’s gebruikt voor taxivervoer. Het doel is om handhavingprocessen te helpen uitvoeren door de elektronische registratie van de ritadministratie en de arbeids-, rij- en rusttijden en het op aanvraag ter beschikking stellen van deze informatie aan bevoegde personen ter controle.

De TOE kent vier werkingsmodi, te weten: operationele modus, controle modus, activering/keuringsmodus en bedrijfsmodus. De operationele modus kent drie werkingsniveaus: basis, arbeidstijd en taxivervoer. Wanneer taxivervoer wordt aangeboden of arbeidstijd plaatsheeft, selecteert de bestuurder handmatig het corresponderende werkingsniveau. In de operationele modus, werkingsniveau arbeidstijd of taxivervoer, worden gegevens geregistreerd over de uitgevoerde taxiritten en de arbeids-, rij-, en rusttijden van de bestuurder. De aanvang en het beëindigen van een rit wordt door een actieve bedieningshandeling van de bestuurder bij de TOE kenbaar gemaakt. Hierbij dient de beladingtoestand (beladen/onbeladen) te worden aangegeven.

Daarnaast draagt de TOE in alle modi zorg voor het beschikbaar stellen van de basisgegevens tijd en afgelegde afstand, en de positie van het voertuig. In het werkingsniveau basis wordt ook de registratie van gebeurtenissen gevoerd. In de operationele modus is het werkingsniveau basis een apart werkingsniveau. In de overige modi integreert de TOE de basis functionaliteit met de overige functionaliteit van de betreffende modus.

De TOE bestaat ten minste uit een verwerkingseenheid, een geheugen, een tijdklok, een ISO 7816 kaartinterface, een ISO 7810 ID-000 kaartinterface ten behoeve van de systeemkaart, een positiebepalingssensor of een interface voor de positiebepalingssensor, een verplaatsingsopnemer, een interface voor de bewegingsopnemer, een gegevensoverbrengingsinterface, een interface voor de taxameter, een leesvenster en voorzieningen voor de invoer van gebruikersgegevens.

De TOE kan door middel van additionele verbindingen aan andere inrichtingen worden gekoppeld, of daarmee geïntegreerd worden.

Toegang tot de TOE wordt verleend door middel van een boordcomputerkaart met PIN-code en voorzien van een (authenticatie)certificaat. Er worden vier gebruikersrollen voorzien, te weten bestuurder, toezichthouder, werkplaats en vervoerder. De omschakeling tussen werkingsmodi gebeurt door het plaatsen van de correcte boordcomputerkaart in de TOE. Er worden vier verschillende kaarten onderscheiden, te weten: chauffeurskaart, inspectiekaart, keuringskaart en ondernemerskaart. Boordcomputerkaarten maken geen onderdeel uit van de TOE.

Bij aanvang van de dienst dient een chauffeurskaart in de TOE te zijn geplaatst. De bestuurder meldt zich aan met de chauffeurskaart en een persoonlijk identificatie code (PIN-code). De TOE registreert de persoonlijke arbeids-, rij- en rusttijden van de bestuurder en slaat deze op in het interne geheugen van de TOE en op de chauffeurskaart.

In voorkomende gevallen heeft een chauffeur geen kaart en dan dient hij zijn burgerservicenummer in te voeren. Dit burgerservicenummer dient alleen voor identificatie, en wordt door de TOE verder niet gecontroleerd.

De boordcomputerkaarten voor de bestuurder zijn voorzien van een certificaat voor het elektronisch identificeren van de persoon en het ondertekenen van geregistreerde gegevens.

De TOE gebruikt een systeemkaart welke is voorzien van certificaten voor identificatie van de TOE en het plaatsen van elektronische handtekeningen. Het certificaat ten behoeve van de TOE wordt in de productiefase in de vorm van de systeemkaart geïmplementeerd in de TOE. Deze certificaten worden uitgegeven onder verantwoordelijkheid van de Minister van Verkeer en Waterstaat. Systeemkaarten zijn geen onderdeel van de TOE.

De TOE voert gegevens uit naar een leesvenster en kan gegevens ter beschikking stellen ten behoeve van een externe printer en externe inrichtingen.

De operationele omgeving van de TOE geïnstalleerd in de auto is weergegeven in onderstaande figuur.

De systeemkaart plaatst een elektronische handtekening (EH) per uitgevoerde rit over alle ritgegevens terstond nadat de bestuurder heeft aangegeven dat de rit teneinde is.

De chauffeurskaart plaatst een elektronische handtekening bij het einde van de dienst van de bestuurder over de arbeids-, rij- en rusttijden van de bestuurder gedurende de dienst. Hiervoor wordt het persoonsgebonden certificaat van de chauffeurkaart gebruikt waarbij de bestuurder vooraf zijn goedkeuring verleent door het ingeven van de PIN-code van de chauffeurskaart.

De systeemkaart plaatst een elektronische handtekening over de geregistreerde gegevens wanneer deze worden opgeslagen en wanneer deze worden uitgevoerd naar een externe gegevensdrager.

De koppeling van bestuurder aan de geregistreerde gegevens en de waarborging van de integriteit en authenticiteit van de gegevens wordt in onderstaande figuur geïllustreerd:

De typische levenscyclus van een TOE wordt geïllustreerd door onderstaande figuur. Het verkrijgen van een typegoedkeuring is een verantwoordelijkheid van de fabrikant. Eventuele reparaties worden uitgevoerd door, of onder verantwoordelijkheid van, de fabrikant. Installatie van eventuele nieuwere versies van programmatuur (software updates), mogen door erkende werkplaatsen worden uitgevoerd gedurende een periodieke controle.

Voor de TOE zijn de volgende types van entiteiten (subjecten en objecten) relevant:

S.BEWEGINGSOPNEMER

Het instrument, of een deel ervan, gekoppeld aan de TOE dat een signaal in de vorm van een impuls afgeeft over de beweging van de auto op basis waarvan de TOE de afgelegde afstand van de auto kan bepalen.

S.POSITIEBEPALINGSSENSOR

Het instrument, of een deel ervan, gekoppeld aan de TOE dat een signaal afgeeft aan de TOE over de locatie van de auto op basis van verkregen informatie van een satelliet positiebepalingsysteem.

S.BOORDCOMPUTERKAART

De geheugenkaart met chip voor gebruik in de TOE waarmee de TOE de identiteit van de kaarthouder kan vaststellen en waarop gegevens kunnen worden opgeslagen.

S.SYSTEEMKAART

De geheugenkaart met chip die de TOE in staat stelt een elektronische handtekening te plaatsen.

S.PRINTER

Een externe inrichting waaraan gegevens beschikbaar kunnen worden gesteld voor het afdrukken op papier.

S.TAXAMETER

De geijkte externe inrichting voor het bepalen van de ritprijs op basis van een tarievenstructuur.

S.HANDHAVINGSMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen t.b.v. toezichthouders voor het uitlezen en verwerken van gegevens.

S.KALIBRATIEMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen t.b.v. een erkende werkplaats voor het ijken, kalibreren en activeren van de TOE.

S.BEDRIJFSMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen t.b.v. de vervoerder voor de overdracht van gegevens naar de bedrijfsadministratie.

S.CHAUFFEURSKAART

Een aan de bestuurder afgegeven boordcomputerkaart waarmee de boordcomputer de identiteit van de desbetreffende bestuurder kan vaststellen, een elektronische handtekening kan plaatsen, en waarmee de operationele modus van de TOE kan worden geactiveerd.

S.INSPECTIEKAART

Een aan de met het toezicht op de naleving belaste persoon afgegeven boordcomputerkaart die de desbetreffende persoon identificeert en waarmee de controlemodus van de boordcomputer kan worden geactiveerd.

S.KEURINGSKAART

Een aan een erkende werkplaats afgegeven boordcomputerkaart die de desbetreffende werkplaats identificeert en waarmee de activerings- en keuringsmodus van de boordcomputer kan worden geactiveerd.

S.ONDERNEMERSKAART

Een aan een vervoerder afgegeven boordcomputerkaart die de desbetreffende vervoerder identificeert en waarmee de bedrijfsmodus van de boordcomputer kan worden geactiveerd.

O.BASISGEGEVENS

De tijd, afgelegde afstand en gegevens betreffende verplaatsing zoals bijgehouden door de TOE.

O.ARBEIDSTIJDGEGEVENS

De arbeids-, rij- en rusttijden gegevens van de bestuurder zijnde de rijtijd, pauze en andere werkzaamheden dan rijden geregistreerd door de TOE.

O.RITGEGEVENS

De gegevens per individuele rit bestaande uit ten minste de begin- en eindlocatie, de begin- en einddatum en tijd, afgelegde afstand, de ritprijs, de beladingstoestand en identiteit van de bestuurder geregistreerd door de TOE.

O.BEDRIJFSGEGEVENS

Gegevens over de vervoerder zoals zijn vastgelegd op de TOE.

O.KAARTHOUDERGEGEVENS

Gegevens opgeslagen op de boordcomputerkaart ingebracht in de TOE.

O.POSITIEGEGEVENS

Gegevens betreffende de locatie van de auto die door de S.POSITIEBEPALINGSSENSOR aan de TOE worden aangeleverd.

O.BEWEGINGSGEGEVENS

Gegevens betreffende snelheid en afgelegde afstand die door S.BEWEGINGSOPNEMER of S.POSITIEBEPALINGSSENSOR aan de TOE worden aangeleverd.

O.GEBEURTENISGEGEVENS

Gegevens geregistreerd door de TOE met betrekking tot routinematige en uitzonderlijke gebeurtenissen op basis waarvan analyses mogelijk zijn en de verantwoordelijke gebruiker of proces kan worden bepaald.

O.SYSTEEMGEGEVENS

Specifieke gegevens ter ondersteuning of noodzakelijk voor het functioneren van de TOE of voor identificatie en instellingen van de TOE functies.

De TOE (Target of Evaluation) is de selectie van hardware en software en bijbehorende handleidingen die uiteindelijk wordt geëvalueerd. De TOE moet alle functionaliteit omvatten die nodig is om aan de eisen in dit profiel te voldoen, maar mag daarnaast ook andere zaken bevatten, zoals bijvoorbeeld een routeplanningsapplicatie.

De minimale omvang van de TOE wordt schematisch weergegeven in onderstaande figuur:

Alle onderdelen die in deze afbeelding binnen de grijze omheining worden weergegeven moeten onderdeel zijn van de TOE. Dus bijvoorbeeld de (voertuig) sensor voor bewegingsgegevens (bewegingsopnemer) en de positiebepalingssensor (GNSS) hoeven geen deel uit te maken van de TOE maar de aansluiting van deze sensoren weer wel

Andere zaken die in deze figuur zijn weergegeven (zoals de taxameter en de printer), mogen onderdeel zijn van de TOE, hoewel dit niet altijd praktisch is. Ook extra software en hardware die niet in deze figuur zijn weergegeven (zoals de bovengenoemde routeplanningsapplicatie) mogen deel uitmaken van de TOE.

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

P.VASTLEGGEN

De TOE legt de volgende gegevens vast, afhankelijk van de werkingsmodus en het actieve werkingsniveau:

1. ○

   Operationele modus basis: In ingeschakelde toestand registreert de TOE altijd de positie- en gebeurtenisgegevens. Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de kaarthouder;

2. ○

   Operationele modus arbeidstijd: Na een selectie van het werkingsniveau arbeidstijd registreert de TOE de positie- en gebeurtenisgegevens en de arbeidstijdgegevens. Het werkingsniveau arbeidstijd wordt automatisch geselecteerd door het inbrengen van de chauffeurskaart, en kan zonder chauffeurskaart handmatig geselecteerd worden na het invoeren van een burgerservicenummer. Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de kaarthouder, indien identificatie plaats vindt met een burgerservicenummer, dan registreert de TOE dit burgerservicenummer;

3. ○

   Operationele modus taxivervoer: Na een handmatige selectie van het werkingsniveau taxivervoer, registreert de TOE de positie- en gebeurtenisgegevens, de arbeidstijdgegevens en de ritgegevens. Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de kaarthouder, indien identificatie plaatsvindt met een burgerservicenummer, dan registreert de TOE dit burgerservicenummer;

4. ○

   Controlemodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit van de kaarthouder;

5. ○

   Activering/keuringsmodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit van de kaarthouder;

6. ○

   Bedrijfsmodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit van de kaarthouder.

P.BEWAREN_EN_BORGEN

De TOE bewaart de vastgelegde gegevens zodat:

1. ○

   wijzigingen van de gegevens detecteerbaar zijn;

2. ○

   de gegevens onweerlegbaar gekoppeld zijn aan de TOE;

3. ○

   de gegevens onweerlegbaar gekoppeld zijn aan de boordcomputerkaart.

P.ACTIES

De TOE kan de volgende acties uitvoeren, afhankelijk van de werkingsmodus, het actieve werkingsniveau en de ingebrachte boordcomputerkaart:

1. ○

   Selecteren van de juiste werkingsmodus;

2. ○

   Activering, deactivering en onderzoek van de TOE;

3. ○

   Instellen van de bedrijfsvergrendeling;

4. ○

   Detecteren en registreren van storingen¹;

5. ○

   Detecteren en registeren van fouten²;

6. ○

   Detecteren en registeren van gebeurtenissen;

7. ○

   Gegevens tonen op een leesvenster;

8. ○

   Gegevens overbrengen naar een externe gegevensdrager;

9. ○

   Gegevens overbrengen van de chauffeurskaart naar de TOE;

10. ○

    Gegevens overbrengen naar een externe inrichting;

11. ○

    Gegevens beschikbaar stellen t.b.v. een printer;

12. ○

    Geven van waarschuwingssignalen.

P.UITVOEREN_GEGEVENS

De TOE kan de geregistreerde gegevens uitvoeren, afhankelijk van de ingebrachte boordcomputerkaart:

1. ○

   Geen kaart, authenticatie op basis van burgerservicenummer:

   1. ○

      ritgegevens van de huidige sessie naar een leesvenster;

   2. ○

      arbeids-, rij- en rusttijden van de huidige sessie naar een leesvenster;

   3. ○

      ritgegevens van de huidige sessie naar een uitvoerinterface voor een printer;

   4. ○

      arbeids-, rij- en rusttijden van de huidige sessie naar een uitvoerinterface voor een printer;

2. ○

   Chauffeurskaart:

   1. ○

      eigen ritgegevens naar een leesvenster;

   2. ○

      eigen arbeids-, rij- en rusttijden naar een leesvenster;

   3. ○

      eigen arbeids-, rij- en rusttijden naar de chauffeurskaart;

   4. ○

      eigen ritgegevens naar een uitvoerinterface voor een printer;

   5. ○

      eigen arbeids-, rij- en rusttijden naar een uitvoerinterface voor een printer.

3. ○

   Inspectiekaart: alle gegevens met uitzondering van positiegegevens en beveiligingsgegevens,

   1. ○

      naar een leesvenster;

   2. ○

      naar een uitvoerinterface voor een printer;

   3. ○

      naar een extern handhavingsmiddel of externe gegevensdrager overbrengen.

4. ○

   Keuringskaart: alle gegevens met uitzondering van positiegegevens en beveiligingsgegevens,

   1. ○

      naar een leesvenster;

   2. ○

      naar een uitvoerinterface voor een printer;

   3. ○

      naar een extern kalibratiemiddel of externe gegevensdrager overbrengen.

5. ○

   Keuringskaart, na actieve handeling gevolgd door Inspectiekaart: de positiegegevens naar een extern handhavingsmiddel of externe gegevensdrager overbrengen.

6. ○

   Ondernemerskaart: alle gegevens vastgelegd in de bedrijfsvergrendeling voor de desbetreffende ondernemer met uitzondering van positiegegevens en beveiligingsgegevens,

   1. ○

      naar een leesvenster;

   2. ○

      naar een uitvoerinterface voor een printer;

   3. ○

      naar een extern bedrijfsmiddel of externe gegevensdrager overbrengen.

P.DEACTIVERING

De TOE kan met behulp van een keuringskaart worden gedeactiveerd. Alle gegevens opgeslagen op de TOE tijdens de deactivering worden overgebracht naar een externe gegevensdrager met uitzondering van positiegegevens. Positiegegevens kunnen alleen worden overgebracht naar externe gegevensdrager(s) of externe inrichtingen als er tijdens P.DEACTIVERING op de TOE wordt aangemeld met achtereenvolgens S.KEURINGSKAART als S.INSPECTIEKAART.

A.BEDIENING

Er wordt verondersteld dat de bestuurder van de auto de TOE juist bedient en correct het werkingsniveau, de beladingtoestand en het moment van aanvang en beëindiging van een rit selecteert.

A.SENSOREN

Er wordt verondersteld dat de gegevens aangeboden op de sensorinterface(s) correct zijn.

A.SYSTEEMKAART

Er wordt verondersteld dat de systeemkaart

1. ○

   een certificaat bevat welk onweerlegbaar is gekoppeld met de TOE;

2. ○

   alle gegevens die door de TOE worden aangeboden correct ondertekent;

3. ○

   de handtekening terugstuurt naar de TOE.

A.BOORDCOMPUTERKAART

Er wordt verondersteld dat een ingebrachte boordcomputerkaart

1. ○

   een certificaat bevat welk onweerlegbaar is gekoppeld met de boordcomputerkaarthouder;

2. ○

   alle gegevens die door de TOE worden aangeboden correct ondertekent;

3. ○

   de handtekening terugstuurt naar de TOE.

A.BOORDCOMPUTERKAARTHOUDER

Er wordt verondersteld dat boordcomputerkaarthouders hun boordcomputerkaart niet aan derden uitreiken en hun PIN-code geheim houden.

A.PRINTER

Er wordt verondersteld dat gegevens die worden aangeboden ten behoeve van een aangesloten printer, correct worden afgedrukt door die printer.

A. VOOR_ACTIVERING

De TOE wordt in inactieve toestand geleverd aan voertuigfabrikanten, installateurs en/of erkende werkplaatsen. Deze zullen de TOE installeren waarna een erkende werkplaats de TOE zal kalibreren en vervolgens activeren.

Voertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit van de TOE beschermen totdat de TOE is geactiveerd.

OT.AUDIT

De TOE legt beveiligingsrelevante gebeurtenisgegevens vast en toont deze op het beeldscherm.

OT.AUTHENTICATIE_BOORDCOMPUTERKAART

De TOE zal een ingebrachte boordcomputerkaart authenticeren door middel van zowel:

1. ○

   een door de eigenaar van de boordcomputerkaart in te brengen PIN;

2. ○

   een op de boordcomputerkaart aanwezig certificaat.

OT.VASTLEGGEN

De TOE legt gegevens vast volgens de regels van P.VASTLEGGEN en zodanig dat de geregistreerde gegevens een correcte afspiegeling zijn van de waarden aangeboden op de sensorinterface(s).

OT.KOPPELEN_AAN_SYSTEEMKAART

De TOE zal gegevens die geregistreerd dienen te worden aan de systeemkaart aanbieden ter ondertekening met een elektronische handtekening.

OT.KOPPELEN_AAN_BOORDCOMPUTERKAART

De TOE zal arbeids-, rij- en rusttijden van de bestuurder die geregistreerd dienen te worden, aan de chauffeurskaart aanbieden ter ondertekening met een elektronische handtekening.

OT.OPSLAAN

De TOE zal gegevens die geregistreerd dienen te worden opslaan. De gegevens zullen gezamenlijk worden opgeslagen met de elektronische handtekeningen over deze gegevens.

OT.UITVOEREN_GEGEVENS

De TOE kan geregistreerde gegevens uitvoeren volgens de regels van P.UITVOEREN_GEGEVENS. Tenzij gegevens worden uitgevoerd naar printer of leesvenster worden de bij de gegevens opgeslagen elektronische handtekeningen eveneens uitgevoerd.

OT.FYSIEKE_BEVEILIGING

De TOE biedt fysieke weerstand zodanig dat het openmaken van de TOE in een laboratorium kan worden vastgesteld.

OT.BEWAKING_INTEGRITEIT

De TOE zal de integriteit van de gegevens ten minste bewaken door:

1. ○

   Het testen van de integriteit van opgeslagen gegevens bij het opstarten van de TOE (O.SYSTEEMGEGEVENS), op verzoek van een gebruiker of bij het overbrengen van gegevens;

2. ○

   Het testen van de correcte werking van de TOE en de S.SYSTEEMKAART bij het opstarten van de TOE of op verzoek van een gebruiker.

OE.VOOR_ACTIVERING

De TOE wordt in inactieve toestand geleverd aan voertuigfabrikanten, installateurs en/of erkende werkplaatsen. Deze zullen de TOE installeren waarna een erkende werkplaats de TOE zal kalibreren en vervolgens activeren.

Voertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit van de TOE beschermen totdat de TOE is geactiveerd.

OE.SENSOREN

De omgeving van de TOE dient ervoor zorg te dragen dat de gegevens die worden aangeboden op de sensorinterface(s) correct zijn. Dit kan bijvoorbeeld door:

1. ○

   correcte installatie van TOE en sensoren in het voertuig;

2. ○

   controle van het voertuig op manipulatie van sensoren en/of aansluiting.

OE.PRINTER

De omgeving van de TOE dient ervoor zorg te dragen dat de gegevens die worden aangeboden door de TOE aan de printer correct worden afgedrukt. Dit kan bijvoorbeeld door:

1. ○

   correcte installatie van TOE en printer in het voertuig;

2. ○

   controle van het voertuig op manipulatie van printer en/of aansluiting.

OE.BEDIENING

De omgeving van de TOE dient ervoor zorg te dragen dat de bestuurder van de auto correct gebruik maakt van de mogelijkheden om het werkingsniveau, de beladingtoestand, het begin en einde van een rit en de aanvang en einde van de dienst te selecteren. Dit kan bijvoorbeeld door:

1. ○

   handleidingen en instructies;

2. ○

   opleiding en training;

3. ○

   ergonomisch ontwerp van de TOE en montage in de auto.

OE.SYSTEEMKAART

De omgeving van de TOE dient een systeemkaart te bevatten die:

1. ○

   een certificaat bevat welk onweerlegbaar is gekoppeld met de TOE;

2. ○

   alle gegevens die door de TOE worden aangeboden correct ondertekent;

3. ○

   de handtekening terugstuurt naar de TOE.

OE.BOORDCOMPUTERKAART

De omgeving van de TOE dient boordcomputerkaarten te bevatten die:

1. ○

   een certificaat bevat welk onweerlegbaar is gekoppeld met de boordcomputerkaarthouder;

2. ○

   alle gegevens die door de TOE worden aangeboden correct te ondertekent;

3. ○

   de handtekening terugstuurt naar de TOE.

OE.BOORDCOMPUTERKAARTHOUDER

Boordcomputerkaarthouders dienen hun boordcomputerkaart niet aan derden uit te reiken en hun PIN-code geheim te houden. Bestuurders mogen maar één geldige chauffeurskaart in hun bezit hebben.

OE.DEACTIVERING

De TOE wordt buiten gebruik gesteld (deactivering) door erkende werkplaatsen. De opgeslagen gegevens worden hierbij verwijderd met uitzondering van O.SYSTEEMGEGEVENS en O.POSITIEGEGEVENS.

De functionele beveiligingseisen zijn verdeeld in een aantal functionele groepen. Iedere groep bevat één of meer onderling samenhangende eisen. De groepen zijn:

1. ○

   Beveiligingsrollen: Deze definiëren de verschillende rollen en modussen van de TOE, en hoe deze rollen worden aangenomen.

2. ○

   Identificatie en Authenticatie: Deze definiëren hoe boordcomputerkaarten en andere randapparatuur worden geïdentificeerd en waar nodig geauthenticeerd.

3. ○

   BCT-toegangsbeleid: Hier wordt beschreven wat wordt vastgelegd, en wie daar wat mee mag doen.

4. ○

   Handtekeningen: Hier wordt beschreven hoe handtekeningen worden gevraagd aan Systeemkaart en Boordcomputerkaart

5. ○

   Beveiligingsaudit: Hier wordt beschreven hoe welke systeemgebeurtenissen worden geregistreerd en hoe deze zijn beschermd

6. ○

   Bescherming van de BCT: Hier wordt beschreven hoe de fysieke beveiliging van de BCT werkt en hoe de integriteit wordt gewaarborgd.

FMT_SMR.2 Restricties op gebruikersrollen

FMT_SMR.2.1 De TSF kent de volgende gebruikersrollen:

1. ○

   BESTUURDER

2. ○

   TOEZICHTHOUDER

3. ○

   WERKPLAATS

4. ○

   VERVOERDER

5. ○

   ONBEKEND

FMT_SMR.2.2 De TSF kan rollen met gebruikers associëren

FMT_SMR.2.3 De TSF zal de volgende regels afdwingen:

1. ○

   De rol BESTUURDER wordt aangenomen (en de werkingsmodus wordt Operationele Modus Arbeidstijd) als S.CHAUFFEURSKAART is ingebracht en geauthenticeerd, of als geen S.BOORDCOMPUTERKAART is ingebracht en de gebruiker met het burgerservicenummer is ge-identificeerd.

2. ○

   De rol TOEZICHTHOUDER wordt aangenomen (en de werkingsmodus wordt Controle Modus) als S.INSPECTIEKAART is ingebracht en geauthenticeerd

3. ○

   De rol WERKPLAATS wordt aangenomen (en de werkingsmodus wordt Activerings/Keuringsmodus) als S.KEURINGSKAART is ingebracht en geauthenticeerd

4. ○

   De rol VERVOERDER wordt aangenomen (en de werkingsmodus wordt Bedrijfsmodus) als S.ONDERNEMERSKAART is ingebracht en geauthenticeerd

5. ○

   De rol ONBEKEND wordt aangenomen (en de werkingsmode wordt Operationele Modus Basis) als:

6. ○

   Geen kaart is ingebracht en de gebruiker heeft zich niet met burgerservicenummer ge-identificeerd

7. ○

   Wel een kaart is ingebracht maar de authenticatie faalt

FIA_UID.1 Tijd van identificatie (Boordcomputerkaarten)

FIA_UID.1.1 De TSF staat het registreren van de O.POSITIEGEGEVENS, en O.GEBEURTENISGEGEVENS namens de gebruikersrol ONBEKEND toe, voordat een gebruiker is geïdentificeerd.

FIA_UID.1.2 De TSF eist dat S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART, en S.ONDERNEMERSKAART succesvol zijn geïdentificeerd op basis van de identiteit weergegeven in het certificaat op die boordcomputerkaart, alvorens andere handelingen te verrichten namens de desbetreffende gebruiker.

FIA_UAU.1 Tijd van authenticatie (Boordcomputerkaarten)

FIA_UAU.1.1 De TSF staat het registreren van de O.BASISGEGEVENS, O.ARBEIDSTIJDGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEWEGINGSGEGEVENS en O.GEBEURTENISGEGEVENS namens de gebruikersrol ONBEKEND toe, voordat een gebruiker is geauthenticeerd.

FIA_UAU.1.2 De TSF eist dat S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART succesvol zijn geauthenticeerd op basis van:

1. ○

   Een minimaal 4 karakter lange PIN (deze authenticatie wordt door S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART uitgevoerd en het resultaat wordt door deze aan de TSF gerapporteerd), en

2. ○

   Verificatie van het certificaat op de boordcomputerkaart.

FIA_AFL.1 Falen van authenticatie (FIA_AFL)

FIA_AFL.1.1 De TSF detecteert wanneer vijf (5) opeenvolgende niet-succesvolle authenticatiepogingen plaatsvinden gerelateerd aan het authenticeren van dezelfde S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART of S.ONDERNEMERSKAART

FIA_AFL.1.2 Als er vijf (5) opeenvolgende niet-succesvolle authenticatiepogingen zijn gedetecteerd, dan zal de TSF:

1. ○

   een gebeurtenis genereren ;

2. ○

   de gebruiker waarschuwen;

3. ○

   aannemen dat de gebruikersrol ONBEKEND is.

FIA_UAU.6 Herauthenticeren

FIA_UAU.6.1 De TSF zal S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART herauthenticeren onder de volgende condities:

1. ○

   bij het plaatsen van een elektronische handtekening door een boordcomputerkaart;

2. ○

   bij het invoeren van de boordcomputerkaart;

3. ○

   bij het opheffen van een geblokkeerde kaartsessie;

4. ○

   bij herstel van de stroomvoorziening na een onderbreking

FTA_SSL.2 Blokkeren van een sessie op initiatief van een gebruiker

FTA_SSL.2.1 De TSF zal S.BOORDCOMPUTERKAART toestaan een sessie te blokkeren door het uitnemen van S.BOORDCOMPUTERKAART zonder dat is aangegeven dat de sessie van de gebruiker is beëindigd en als de auto zich in de toestand stilstaan bevindt door middel van:

1. ○

   het wissen van het scherm

2. ○

   het blokkeren van alle invoerapparatuur behalve die benodigd is voor het opheffen van de blokkering

FTA_SSL.2.2 De TSF eist dat de volgende handelingen plaatsvinden alvorens de blokkering op te heffen:

1. ○

   het opnieuw inbrengen van dezelfde S.CHAUFFEURSKAART waarvoor de kaartsessie is geblokkeerd.

FTA_SSL.3 Automatisch beëindigen van een sessie

FTA_SSL.3.1 De TSF beëindigt een kaartsessie:

1. ○

   als een geblokkeerde S.CHAUFFEURSKAART sessie niet binnen 60 minuten wordt hervat;

2. ○

   meteen als een andere S.BOORDCOMPUTERKAART wordt ingebracht dan waarvoor de TSF is geblokkeerd, tenzij

   1. ○

      de TSF in de toestand P.DEACTIVERING is geplaatst door een S.KEURINGSKAART waarna een S.INSPECTIEKAART wordt aangeboden, of

   2. ○

      in de Operationele Modus Arbeidstijd of Operationele Modus Taxivervoer een S.INSPECTIEKAART wordt aangeboden;

3. ○

   als in een sessie van een S.ONDERNEMERSKAART, S.INSPECTIEKAART of S.KEURINGSKAART gedurende 5 minuten geen handelingen aan de TSF verricht.

FIA_UID.2 Identificatie voor enige actie (Systeemkaart)

FIA_UID.2.1 De TSF identificeert S.SYSTEEMKAART op basis van de identiteit weergegeven in het machine-gebonden certificaat zoals vastgelegd op de systeemkaart verbonden met de TOE, alvorens handelingen te verrichten namens S.SYSTEEMKAART.

FIA_UID.2 Identificatie voor enige actie (Overigen)

FIA_UID.2.1 De TSF identificeert S.BEWEGINGSOPNEMER, S.POSITIEBEPALINGSSENSOR, S.PRINTER, S.TAXAMETER, S.HANDHAVINGSMIDDELEN, S.KALIBRATIEMIDDELEN EN S.BEDRIJFSMIDDELEN op basis van hun aanwezigheid op de daarvoor bestemde interface, alvorens handelingen te verrichten namens de desbetreffende subjecten.

FDP_ACC.2 Volledige toegangscontrole

FDP_ACC.2.1 De TSF dwingt het toepassen van het BCT-toegangsbeleid af voor alle subjecten, alle objecten en alle handelingen⁴.

FDP_ACC.2.2 De TSF garandeert dat alle verrichtingen tussen een subject gecontroleerd door de TSF en een object gecontroleerd door de TSF zijn onderworpen aan een toegangscontrole SFP.

FDP_ACF.1 Toegangscontrole op basis van attributen

FDP_ACF.1.1 De TSF dwingt het toepassen van het BCT-toegangsbeleid af voor objecten voor alle subjecten en alle objecten.

FDP_ACF.1.2 De TSF dwingt de volgende regels af om te bepalen of een verrichting tussen gecontroleerde subjecten en gecontroleerde objecten is toegestaan:

1. ○

   TSF zal:

   1. –

      Altijd O.BEWEGINGSGEGEVENS inlezen, samenvatten, en samen met de tijd⁵en de gegevens betreffende verplaatsing beschikbaar stellen als O. BASISGEGEVENS

   2. –

      Altijd O.POSITIEGEGEVENS inlezen en vastleggen;

   3. –

      O.ARBEIDSTIJDGEGEVENS vastleggen in Operationele Modus Arbeidstijd en Operationele Modus Taxivervoer;

   4. –

      O.RITGEGEVENS vastleggen in Operationele Modus Taxivervoer.

   NB: Als gegevens worden vastgelegd dan is dat inclusief de elektronische handtekening⁶

2. ○

   BESTUURDER mag:

   1. –

      de eigen O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS tonen op een leesvenster;

   2. –

      O.ARBEIDSTIJDENGEGEVENS opslaan op de S.CHAUFFEURSKAART;

   3. –

      O.ARBEIDSTIJDENGEGEVENS van de S.CHAUFFEURSKAART overbrengen naar de TOE;

   4. –

      O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS uitvoeren naar S.PRINTER.

3. ○

   TOEZICHTHOUDER mag alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS, O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS

   1. –

      tonen op een leesvenster;

   2. –

      uitvoeren naar S.PRINTER;

   3. –

      uitvoeren naar S.HANDHAVINGSMIDDELEN of externe gegevensdragers.

4. ○

   TOEZICHTHOUDER mag, mits de TOE is gedeactiveerd, O.POSITIEGEGEVENS

   1. –

      uitvoeren naar S.HANDHAVINGSMIDDELEN of externe gegevensdragers.

5. ○

   WERKPLAATS mag de TOE deactiveren.

6. ○

   WERKPLAATS mag O.SYSTEEMGEGEVENS aanpassen

7. ○

   WERKPLAATS mag alle O.BASISGEGEVENS, O.RITGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.BEDRIJFSGEGEVENS, O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS

   1. –

      tonen op een leesvenster;

   2. –

      uitvoeren naar S.PRINTER;

   3. –

      uitvoeren naar S.KALIBRATIEMIDDELEN of externe gegevensdragers.

8. ○

   VERVOERDER mag alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS, O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS geregistreerd gedurende de periode dat de TSF voor de desbetreffende vervoerder is vergrendeld of vergrendeld geweest (bedrijfsvergrendeling)

   1. –

      tonen op een leesvenster;

   2. –

      uitvoeren naar S.PRINTER;

   3. –

      uitvoeren naar S.BEDRIJFSMIDDELEN of externe gegevensdragers.

FDP_ACF.1.3 –⁷

FDP_ACF.1.4 De TSF zal expliciet toegang van subjecten naar objecten weigeren gebaseerd op de volgende regel:

1. ○

   Alle niet in FDP_ACF.1.2 genoemde toegang is niet toegestaan

FDP_ETC.2 Export van gegevens met attributen

FDP_ETC.2.1 De TSF dwingt het gebruik van het BCT-toegangsbeleid af wanneer O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEDRIJFSGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS gegevens worden overgebracht naar externe gegevensdragers of inrichtingen buiten de TSF.

FDP_ETC.2.2 De TSF exporteert gegevens inclusief de bijbehorende elektronische handtekening over deze gegevens, behalve als deze naar S.PRINTER of het leesvenster worden geexporteerd.

FDP_ETC.2.3 De TSF garandeert dat de elektronische handtekening onlosmakelijk is geassocieerd met de geëxporteerde gegevens.

FDP_ETC.2.4 De TSF dwingt de volgende regels af wanneer gegevens worden geëxporteerd van de TSF:

1. ○

   De TSF handhaaft de rangschikking van gegevens (berichtvolgorde) bij gegevensoverdracht naar externe gegevensdragers of inrichtingen;

FDP_ITC.1 Import van gegevens zonder attributen

FDP_ITC.1.1 De TSF dwingt het gebruik van het BCT-toegangsbeleid af wanneer gegevens worden ingelezen van S.BOORDCOMPUTERKAARTEN, S.BEWEGINGSOPNEMER, S.POSITIEBEPALINGSSENSOR, S.HANDHAVINGSMIDDELEN, S.KALIBRATIEMIDDELEN, S.BEDRIJFSMIDDELEN of S.TAXAMETER.

FDP_ITC.1.2 De TSF negeert attributen wanneer gegevens worden ingelezen door de TSF.

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

1. ○

   De TSF verwerkt gegevens alleen wanneer deze afkomstig zijn van:

   1. ○

      de interne tijdklok van de TSF;

   2. ○

      de interne verplaatsingsopnemer van de TSF;

   3. ○

      contact signaal (ignition sense);

   4. ○

      invoer door de gebruiker via het bedieningspaneel;

   5. ○

      S.BEWEGINGSOPNEMER;

   6. ○

      S.POSITIEBEPALINGSSENSOR;

   7. ○

      S.BOORDCOMPUTERKAARTEN;

   8. ○

      S.SYSTEEMKAART;

   9. ○

      S.TAXAMETER.

FDP_DAU.2 Data authenticatie met identiteit

FDP_DAU.2.1 De TSF kan een bewijs van de validiteit van gegevens genereren als volgt:

1. ○

   Een hash van O.RITGEGEVENS wordt ondertekend door de S.SYSTEEMKAART over de volledige set van desbetreffende O.RITGEGEVENS direct bij het registreren van deze gegevens per individuele rit;

2. ○

   Een hash van O.ARBEIDSTIJDGEGEVENS wordt ondertekend door S.CHAUFFEURSKAART direct bij het registreren van deze gegevens bij het beëindigen van de dienst van de bestuurder of het afsluiten van de kaartsessie;

3. ○

   Een hash van O.ARBEIDSTIJDGEGEVENS wordt ondertekend door S.SYSTEEMKAART direct bij het registreren van deze gegevens indien de S.CHAUFFEURSKAART niet beschikbaar is;

4. ○

   Een hash van alle gegevens overgebracht naar S.HANDHAVINGSMIDDELEN, S.BEDRIJFSMIDDELEN, S.KALIBRATIEMIDDELEN of externe gegevensdragers wordt ondertekend door de S.SYSTEEMKAART op het moment van de overdracht;

5. ○

   Hashes van alle geregistreerde O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEDRIJFSGEGEVENS en O.GEBEURTENISGEGEVENS worden ondertekend door S.SYSTEEMKAART.

FDP_DAU.2.2 De TSF levert S.BOORDCOMPUTERKAART een mogelijkheid om het bewijs van de integriteit en authenticiteit van de gegevens en de identiteit van de gebruiker die de gegevens heeft ondertekend te verifiëren.

FTP_ITC.1 Vertrouwd kanaal tussen TSFs

FTP_ITC.1.1 De TSF levert een communicatiekanaal tussen de TSF en de S.SYSTEEMKAART. Dit communicatiekanaal is gescheiden van andere communicatiekanalen, levert zekere identificatie van de eindpunten, en beschermt de data op het kanaal tegen wijzigen of lekken.

FTP_ITC.1.2 De TSF mag alleen zelf communicatie initiëren over het vertrouwde kanaal.

FTP_ITC.1.3 De TSF zal communicatie initiëren over het vertrouwde kanaal voor het door S.SYSTEEMKAART laten zetten van handtekeningen en het ontvangen van deze handtekeningen.

FCS_COP.1 Cryptografische operaties

FCS_COP.1.1 De TSF zal hash-operaties uitvoeren volgens zowel het SHA-1 en het SHA-256 cryptografische algoritme zoals gedefinieerd in de ISO/IEC 10118-3, FIPS PUB 180-2 en ETSI TS 102 176-1 standaarden.

FAU_GEN.1 Genereren van gebeurtenisgegevens⁸

FAU_GEN.1.1 De TSF genereert een gebeurtenis record van de volgende gebeurtenissen:

1. ○

   het aanzetten van de TOE;

2. ○

   het uitzetten van de TOE;

3. ○

   het optreden van storingen⁹in de werking van de TSF;

   1. a.

      een storing in de werking van de registratiefunctie;

   2. b.

      een storing in de werking van de beveiligingsfuncties;

   3. c.

      een storing in de werking van de sensoren;

   4. d.

      een storing in de overbrenging naar een externe interface

   5. e.

      een storing in de werking van de systeemkaart;

   6. f.

      een storing in de werking van de boordcomputerkaarten.

4. ○

   het optreden van fouten¹⁰in de werking van de TSF;

   1. a.

      een integriteitfout in de uitvoercode;

   2. b.

      een integriteitfout in de systeemgegevens;

   3. c.

      een integriteitfout in de opgeslagen gebruikersgegevens;

   4. d.

      een integriteitfout bij de gegevensuitvoer naar de chauffeurskaart;

   5. e.

      een fout in de registratiefunctie;

   6. f.

      een fout die de beveiliging van de boordcomputer in gevaar brengt;

   7. g.

      een fout bij de gegevensuitvoer naar externe inrichtingen;

   8. h.

      een fout bij het gebruik van de systeemkaart;

   9. i.

      een fout bij het gebruik van de boordcomputerkaart;

   10. j.

       een fout in de bewegingsensor;

   11. k.

       een fout in de positiebepalingsensor;

   12. l.

       een fout in de koppeling met de taxameter.

5. ○

   het inbrengen van S.BOORDCOMPUTERKAART;

6. ○

   het uitnemen van S.BOORDCOMPUTERKAART;

7. ○

   het inbrengen van een ongeldige S.BOORDCOMPUTERKAART;

8. ○

   het inbrengen van een S.CHAUFFEURSKAART waarvan blijkt dat de datum en het tijdstip van de laatste registratie op S.CHAUFFEURSKAART op een later tijdstip valt dan de actuele datum en tijdstip volgens de tijdwaarneming van de TSF;

9. ○

   het niet juist afsluiten van de kaartsessie;

10. ○

    het inbrengen van S.CHAUFFEURSKAART waarvan blijkt dat de laatste kaartsessie niet juist is afgesloten;

11. ○

    het ontstaan van onvoldoende opslagcapaciteit;

12. ○

    het verdwijnen van onvoldoende opslagcapaciteit;

13. ○

    het ontstaan van onvoldoende opslagcapaciteit op de S.CHAUFFEURSKAART;

14. ○

    het verdwijnen van onvoldoende opslagcapaciteit op de S.CHAUFFEURSKAART;

15. ○

    het ontstaan van een onderbreking van ten minste 5 seconden in de stroomvoorziening van de TOE;

16. ○

    het verdwijnen van een onderbreking van ten minste 5 seconden in de stroomvoorziening van de TOE;

17. ○

    het begin van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld in de toestand rijden;

18. ○

    het einde van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld in de toestand rijden;

19. ○

    het vaststellen van een toestand verplaatsen door de verplaatsingsopnemer van de TOE wanneer er geen O.BEWEGINGSGEGEVENS van de S.BEWEGINGSOPNEMER worden verkregen;

20. ○

    het begin van het niet kunnen verkrijgen van O.POSITIEGEGEVENS gedurende 5 minuten;

21. ○

    het einde van het niet kunnen verkrijgen van O.POSITIEGEGEVENS gedurende 5 minuten;

22. ○

    een afwijking van meer dan twee procent tussen de, met behulp van O.BEWEGINGSGEGEVENS en de constante van de boordcomputer in de O.SYSTEEMGEGEVENS, berekende afstand en de werkelijke afstand;

23. ○

    een afwijking van meer dan drie procent tussen de O.BEWEGINGSGEGEVENS en de O.POSITIEGEGEVENS;

24. ○

    het ontstaan van een onderbreking in de koppeling met S.TAXAMETER;

25. ○

    het verdwijnen van een onderbreking in de koppeling met S.TAXAMETER;

26. ○

    het overbrengen van gegevens inclusief de naam van de gebruikte interface;

27. ○

    het activeren van de TSF;

28. ○

    het keuren van de TSF;

29. ○

    het deactiveren van de TSF;

30. ○

    het vergrendelen van de TSF;

31. ○

    het inschakelen van een werkingsmodus inclusief naam werkingsmodus;

32. ○

    het uitschakelen van een werkingsmodus inclusief naam werkingsmodus;

33. ○

    het begin van rijden in de operationele modus werkingsniveau taxivervoer zonder S.CHAUFFEURSKAART;

34. ○

    het einde van rijden in de operationele modus werkingsniveau taxivervoer zonder S.CHAUFFEURSKAART;

35. ○

    het detecteren van een niet-succesvolle authenticatiepoging;

36. ○

    het installeren van een programmatuurrevisie.

37. ○

    starten of stoppen van audit- en beveiligingsfuncties;

38. ○

    het uitblijven of weigeren van een elektronische handtekening door S.CHAUFFEURSKAART of S.SYSTEEMKAART;

39. ○

    niet-geautoriseerde wijziging van de TSF configuratie;

40. ○

    toegang tot het gebeurtenissenlogboek.

FAU_GEN.1.2 De TSF legt per gebeurtenis ten minste de volgende informatie vast zoals die geldt op het moment van optreden:

1. ○

   een automatisch gegenereerd oplopend volgnummer;

2. ○

   type van de gebeurtenis (de gebeurteniscode);

3. ○

   de datum en het tijdstip als gecoördineerde wereldtijd;

4. ○

   de kilometerstand;

5. ○

   de verplaatsingstoestand van de auto (rijden/stilstaan);

6. ○

   de werkingsmodus en werkingsniveau van de TOE;

7. ○

   waar relevant, de uitkomst van de gebeurtenis;

8. ○

   waar relevant, aanvullende relevante informatie;

als een storing of fout is opgetreden tevens:

1. ○

   de gebeurteniscode van de aanleiding voor de storing of fout;

als een S.BOORDCOMPUTERKAART is ingebracht in de TSF tevens:

1. ○

   het kaartnummer en kaartsoort;

2. ○

   de gebruikeridentificatiecode;

als geen S.BOORDCOMPUTERKAART is ingebracht, maar de gebruiker is geïdentificeerd met een burgerservicenummer:

1. ○

   het burgerservicenummer.

FAU_ARP.1 Automatische respons op gebeurtenissen

FAU_ARP.1.1 De TSF geeft een waarschuwingsignaal op het leesvenster wanneer een gebeurtenis wordt gedetecteerd.

FAU_STG.1 Bescherming van gebeurtenisgegevens

FAU_STG.1.1 De TSF beschermt de opgeslagen gebeurtenis records in O.GEBEURTENISGEGEVENS tegen ongeautoriseerd verwijderen.

FAU_STG.1.2 De TSF voorkomt ongeautoriseerde aanpassingen in de opgeslagen gebeurtenis records in O.GEBEURTENISGEGEVENS.

FAU_STG.4 Voorkomen van verlies van gebeurtenisgegevens

FAU_STG.4.1 De TSF overschrijft de oudste gebeurtenis records met nieuwere wanneer de opslagcapaciteit voor de O.GEBEURTENISGEGEVENS vol is.

FRU_RSA.2 Maximum en minimum quotas

FRU_RSA.2.1 –¹¹

FRU_RSA.2.2 De TSF garandeert een minimum hoeveelheid opslagcapaciteit voldoende voor 365 dagen van normaal gebruik tegelijkertijd te gebruiken voor:

1. ○

   O.BASISGEGEVENS;

2. ○

   O.RITGEGEVENS;

3. ○

   O.POSITIEGEGEVENS;

4. ○

   O.BEDRIJFSGEGEVENS;

5. ○

   O.GEBEURTENISGEGEVENS;

FPT_STM.1 Tijd

FPT_STM.1.1 De TSF is in staat om betrouwbare tijdsregistraties uit te voeren in de Universal Time Coordinated met een afwijking van ten hoogste één (1) seconde en een resolutie van één (1) seconde of nauwkeuriger.

FPT_PHP.1 Passieve detectie van fysieke aanvallen

FPT_PHP.1.1 De TSF zal een laboratorium in staat stellen om fysieke aanvallen ondubbelzinnig te detecteren¹².

FPT_PHP.1.2 De TSF zal het mogelijk maken om te bepalen dat fysieke aanvallen op de TSF, de S.SYSTEEMKAART of de verbinding tussen TSF en de S.SYSTEEMKAART hebben plaatsgevonden.

FPT_TST.1 Testen van de TSF

FPT_TST.1.1 De TSF zal een verzameling zelf-testen doen bij het opstarten om de correcte werking van de TSF te demonstreren.

FPT_TST.1.2 De TSF zal TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden om de integriteit van de TSF data te verifiëren.

FPT_TST.1.3 De TSF zal TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden om de integriteit van de TSF uitvoerbare programmatuurcode (executables) te verifiëren.

Voor de typegoedkeuring van de boordcomputer wordt een Common Criteria garantieniveau vereist van ten minste EAL3. Dit niveau analyseert de geclaimde beveiligingsfuncties door middel van een analyse van functionele en interface specificatie, (gebruikers)documentatie en een beschrijving van de architectuur van de boordcomputer. De analyse wordt ondersteund met onafhankelijk testen, verificatie van de testresultaten van de ontwikkelaar een beperkt onderzoek naar zwakheden. Daarnaast worden aspecten van de gebruikte ontwerpmiddelen, configuratiebeheer en leveringsprocedures beschouwd.

In combinatie met een uitgebreid en formeel geëvalueerd beveiligingsprofiel (Protection Profile), een periodiek onderzoek en actieve handhaving, kan aannemelijk worden gemaakt dat goedgekeurde boordcomputers voldoende weerstand zullen bieden tegen de onderkende dreigingen en dat gebrekkig functionerende boordcomputers kunnen worden opgespoord.

Deze sectie bevat een uitleg dat de beveiligingsdoelstellingen het gehele beveiligingsprobleem adresseren. Dit beveiligingsprobleem bestaat uit drie delen:

1. ○

   Dreigingen: Dit profiel bevat geen dreigingen, dus er is ook geen uitleg

2. ○

   Beveiligingsbeleid: Zie sectie 8.1.1

3. ○

   Aannames: Zie sectie 8.1.2

Deze sectie bevat een uitleg dat de beveiligingsdoelstellingen alle delen van het beveiligingsbeleid implementeren.

P.VASTLEGGEN

Deze wordt direct ondervangen door OT.VASTLEGGEN. Daarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING.

P.BEWAREN_EN_BORGEN

Het bewaren van de gegevens wordt ondervangen door:

1. ○

   OT.OPSLAAN, wat de gegevens en alle elektronische handtekeningen opslaat.

Het detecteren van de wijzigingen in de vastgelegde gegevens wordt ondervangen door:

1. ○

   Het aanbieden van de gegevens aan de systeemkaart (OT.KOPPELEN_AAN_SYSTEEMKAART) en het door deze ondertekenen van de gegevens (OE.SYSTEEMKAART);

2. ○

   Het aanbieden van gegevens aan de boordcomputerkaart (OT.KOPPELEN_AAN_BOORDCOMPUTERKAART) en het door deze ondertekenen van de gegevens (OE.BOORDCOMPUTERKAART).

Het onweerlegbaar koppelen aan de TOE wordt ondervangen door:

1. ○

   Het aanbieden van de gegevens aan de systeemkaart (OT.KOPPELEN_AAN_SYSTEEMKAART) en het door deze ondertekenen van de gegevens (OE.SYSTEEMKAART);

2. ○

   Dat de systeemkaart een certificaat bevat welk onweerlegbaar is gekoppeld aan de TOE (OE.SYSTEEMKAART).

Het onweerlegbaar koppelen aan de boordcomputerkaarthouder wordt ondervangen door:

1. ○

   Het aanbieden van gegevens aan de boordcomputerkaart (OT.KOPPELEN_AAN_BOORDCOMPUTERKAART) en het door deze ondertekenen van de gegevens (OE.BOORDCOMPUTERKAART);

2. ○

   Dat de boordcomputerkaart een certificaat bevat welk onweerlegbaar is gekoppeld aan de boordcomputerkaarthouder (OE.BOORDCOMPUTERKAART);

3. ○

   Dat de boordcomputerhouder zich authenticeert met een PIN bij het insteken van de kaart (OT.AUTHENTICATIE_BOORDCOMPUTERKAART);

4. ○

   Dat de boordcomputerhouder zijn kaart veilig bewaart en zijn PIN geheim houdt. (OE.BOORDCOMPUTERKAARTHOUDER).

Daarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING, OT.AUDIT en OT.BEWAKING_INTEGRITEIT.

P.ACTIES

Deze wordt direct ondervangen door OT.AUDIT, OT.UITVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART en OE.BEDIENING. Daarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING en OT.BEWAKING_INTEGRITEIT.

P.UITVOEREN_GEGEVENS

Deze wordt direct ondervangen door OT.UITVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART en OE.BEDIENING. Daarnaast vindt indirecte ondersteuning plaats door OE.PRINTER.

P.DEACTIVERING

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

Deze sectie bevat een uitleg dat de beveiligingsdoelstellingen alle aannames implementeren.

A.BEDIENING

Deze wordt direct ondervangen door OE.BEDIENING.

A.SENSOREN

Deze wordt direct ondervangen door OE.SENSOREN.

A.SYSTEEMKAART

Deze wordt direct ondervangen door OE.SYSTEEMKAART.

A.BOORDCOMPUTERKAART

Deze wordt direct ondervangen door OE.BOORDCOMPUTERKAART.

A.BOORDCOMPUTERKAARTHOUDER

Deze wordt direct ondervangen door OE. BOORDCOMPUTERKAARTHOUDER.

A.PRINTER

Deze wordt direct ondervangen door OE.PRINTER.

A. VOOR_ACTIVERING

Deze wordt direct ondervangen door OE.VOOR_ACTIVERING.

OT.AUDIT

Deze wordt gerealiseerd door FAU_GEN.1 wat vastlegt welke gebeurtenisgegevens beveiligingsrelevant zijn, en welke gegevens er daarvoor worden vastgelegd.

Dit wordt ondersteund door:

1. ○

   FPT_STM.1 die aangeeft dat er een klok is die nauwkeurig de tijd aangeeft (zodat de juiste datum en tijd wordt opgeslagen bij de gebeurtenisgegevens)

2. ○

   FAU_ARP.1 die aangeeft dat deze gegevens ook allemaal worden getoond op het display

3. ○

   FAU_STG.1 die aangeeft dat de gegevens niet zo maar kunnen worden verwijderd of veranderd

4. ○

   FRU_RSA.2 dat vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal gebruik

5. ○

   FAU_STG.4 dat vastlegt dat oude gegevens worden overschreven als de opslagruimte vol raakt

OT.AUTHENTICATIE_BOORDCOMPUTERKAART

Deze wordt gerealiseerd door FIA_UID.1 (Boordcomputerkaarten) en FIA_UAU.1 (Boordcomputerkaarten) welke de I&A regels voor boordcomputerkaarten geven

Dit wordt ondersteund door:

1. ○

   FIA_AFL.1 die aangeeft wat er gebeurd bij falende authenticatie

2. ○

   FIA_UAU.6 die aangeeft dat er onder sommige omstandigheden nogmaals moet worden geauthenticeerd

3. ○

   FTA_SSL.2 die tijdelijke blokkade van een sessie toelaat

4. ○

   FTA_SSL.3 die aangeeft wanneer een sessie wordt afgebroken

OT.VASTLEGGEN

Deze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.VASTLEGGEN implementeren.

Dit wordt ondersteund door:

1. ○

   FIA_UID.2 (Overigen) die S.BEWEGINGSSENSOR en S.POSITIEBEPALINGSSENSOR identificeren;

2. ○

   FDP_ITC.1 die vastlegt dat gegevens mogen worden ingelezen van S.BEWEGINGSSENSOR en S.POSITIEBEPALINGSSENSOR

3. ○

   FRU_RSA.2 die vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal gebruik;

OT.KOPPELEN_AAN_SYSTEEMKAART

Deze wordt gerealiseerd door FDP_DAU.2 die het zetten van een handtekening implementeert. Dit wordt ondersteund door:

1. ○

   FIA_UID.2 (Systeemkaart) die S.SYSTEEMKAART identificeert.

2. ○

   FCS_COP.1 die een hash genereert (de hash wordt getekend ipv de gegevens)

3. ○

   FTP_ITC.1 die ervoor zorgdraagt dat de hash niet wordt veranderd voordat deze wordt getekend

4. ○

   FDP_ACF.1 die specificeert dat de handtekening ook wordt opgeslagen

OT.KOPPELEN_AAN_BOORDCOMPUTERKAART

Deze wordt gerealiseerd door FDP_DAU.2 die het zetten van een handtekening implementeert. Dit wordt ondersteund door:

1. ○

   FIA_UID.2 (Boordcomputerkaart) die S.BOORDCOMPUTERKAART identificeert.

2. ○

   FCS_COP.1 die een hash genereert (de hash wordt getekend in plaats van de gegevens)

3. ○

   FDP_ACF.1 die specificeert dat de handtekening ook wordt opgeslagen

4. ○

   FMT_SMR.2 die de verschillende rollen specificeert die bij de verschillende boordcomputerkaarten horen

OT.OPSLAAN

Zie OT.VASTLEGGEN, OT.KOPPELEN_AAN_SYSTEEMKAART en OT.KOPPELEN_AAN_BOORDCOMPUTERKAART. Daarnaast wordt dit ondersteund door:

1. ○

   FRU_RSA.2 die vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal gebruik

OT.UITVOEREN_GEGEVENS

Deze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.UITVOEREN_GEGEVENS implementeren. Dit wordt ondersteund door:

1. ○

   FMT_SMR.2 die de verschillende rollen definieert;

2. ○

   FIA_UID.1 (Overigen) die de verschillende soorten randapparatuur identificeert waar naar toe kan worden uitgevoerd;

3. ○

   FDP_ETC.2 die ervoor zorg draagt dat de elektronische handtekening mee wordt uitgevoerd.

OT.FYSIEKE_BEVEILIGING

Deze wordt direct gerealiseerd door FPT_PHP.1.

OT.BEWAKING_INTEGRITEIT

Deze wordt direct gerealiseerd door FPT_TST.1

De volgende afhankelijkheden zijn niet vervuld:

1. •

   FMT_MSA.3 (van FDP_ACF.1 en FDP_ITC.1): aangezien er geen attributen worden gebruikt, hoeven de attributen ook niet te worden geinitialiseerd;

2. •

   FDP.ITC.1 of FDP_ITC.2 of FCS_CKM.1 (van FCS.COP.1): aangezien hashing geen sleutels gebruikt, hoeven de sleutels ook niet te worden geïmporteerd of gegenereerd;

3. •

   FCS_CKM.4 (van FCS_COP.1): aangezien hashing geen sleutels gebruikt, hoeven de sleutels ook niet te worden vernietigd;

4. •

   FAU_SAA.1 (van FAU_ARP.1): aangezien iedere gebeurtenis op het leesvenster wordt getoond, is FAU_SAA niet nodig aangezien deze bedoeld is om selecties/combinaties van gebeurtenissen te maken.

In deze bijlage wordt verstaan onder:

1. a.

   XML: eXtensible Markup Language;

2. b.

   USB: Universal Serial Bus;

3. c.

   ritadministratie.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering ritadministratie;

4. d.

   arbeidstijden.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering Arbeids-, rij en rusttijden;

5. e.

   coordinaten.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering coördinaten;

6. f.

   gebeurtenis.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering gebeurtenis;

7. g.

   onderzoek.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering onderzoek;

8. h.

   chauffeurskaartdata.xsd: XML schema definitie van het resultaatbericht van de gegevenslevering chauffeurskaartdata.

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

De overbrengingsinterface die gebruikt wordt voor de gegevensoverbrenging naar een externe gegevensdrager is een USB poort. Er geldt:

1. a.

   de USB poort moet aantoonbaar compliant zijn met de specificaties zoals opgesteld door het USB Implementers Forum, Inc.;

2. b.

   de USB poort is een USB type A connector.

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

Na opvragen van een gegevenslevering moet het corresponderende XML bericht binnen de volgende termijnen beschikbaar zijn op het externe gegevensdrager:

1. •

   Bestand tot 3 Mbyte binnen 10 seconden;

2. •

   Voor iedere Mbyte die het bestand groter is kan de termijn met 3 seconden worden vergroot.

Voor externe opslagmedia moet het bestandssysteem FAT32 ondersteund worden.

De boordcomputer fungeert als host en neemt het initiatief voor gegevensoverdracht naar de externe gegevensdrager.

Om een gegevenslevering tot stand te laten komen, stelt de boordcomputer de houder van een boordcomputerkaart in staat om:

1. a.

   zich met de boordcomputerkaart te authenticeren;

2. b.

   de externe gegevensdrager met de overbrengingsinterface van de boordcomputer te verbinden;

3. c.

   op de boordcomputer één of meerdere gegevensleveringen te selecteren. Standaard zijn alle gegevensleveringen waarvoor de gebruiker is geautoriseerd geselecteerd;

4. d.

   op de boordcomputer een periode in te voeren waarover gegevens opgevraagd moeten worden voor de betreffende gegevenslevering(en).

5. e.

   op de boordcomputer de betreffende gegevenslevering(en) over de ingevoerde periode met één gebruikershandeling starten.

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

De periode, als bedoeld in artikel 2.6, onderdeel d, bedraagt per levering maximaal 1 jaar, met uitzondering van de gegevenslevering ‘Onderzoek’ die geen maximum periode kent, en de gegevenslevering ‘Chauffeurskaartdata’ die de periode van de arbeids-, rij- en rusttijdendata van de chauffeurskaart overneemt.

De standaardwaarde voor ‘Datumtijd begin periode’ is het tijdstip van opvragen minus 29 kalenderdagen, met uitzondering van de gegevenslevering ‘Onderzoek’, waar ‘Datumtijd begin periode’ standaard leeg is, en de gegevenslevering ‘Chauffeurskaartdata’, waar de standaarwaarde voor ‘Datumtijd begin periode’ overeenkomt met het oudste record op de chauffeurskaart. ‘Datumtijd einde periode’ is standaard leeg. Als bij opvragen van een gegevenslevering ‘Datumtijd begin periode’ leeg, wordt deze gevuld met de datum en het tijdstip van de activering. Is ‘Datumtijd einde periode’ leeg, dan wordt ‘Datumtijd einde periode’ gevuld met de datum en het tijdstip waarop het bericht wordt samengesteld;

In de gegevenslevering ‘Coordinaten’, ‘Gebeurtenis’ en ‘Onderzoek’ worden alle gegevens opgenomen die binnen de opgevraagde periode vallen.

In de gegevenslevering ‘Ritadministratie’, ‘Arbeidstijd’ en ‘Chauffeurskaartdata’ worden alle gegevensets opgenomen die de gevraagde periode, inclusief grenzen, overlappen. In de onderstaande tabel is de selectie voor deze gegevensleveringen verder uitgewerkt. Alle gegevensets worden opgenomen die voldoen aan één van de onderstaande condities:

De tabel kan als volgt gevisualiseerd worden. Alle gegevenssets behalve gegevensset 11 en 12 worden in het bericht opgenomen.

Aanvragen van een gegevenslevering is een synchrone aanvraag die direct verwerkt moet worden.

Als de boordcomputer bezig is met de verwerking van een aanvraag voor een gegevenslevering, dan is het niet mogelijk om dezelfde gegevenslevering of een andere gegevenslevering aan te vragen zolang de huidige aanvraag niet is afgerond.

Het is wel eenvoudig mogelijk om een aanvraag te onderbreken. Na onderbreken van de huidige aanvraag is een nieuwe aanvraag van een gegevenslevering direct (< 1 seconde wachten) mogelijk.

De overige functies van de boordcomputer blijven functioneren als de boordcomputer bezig is met het verwerken van een aanvraag voor een gegevenslevering ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ‘Onderzoek’ of ‘Chauffeurskaartdata’.

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

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

De door de boordcomputer geregistreerde gegevens worden voorzien van een elektronische handtekening zodat achteraf de authenticiteit en integriteit van deze gegevens kan worden vastgesteld. Voor het aanmaken van de elektronische handtekeningen worden de boordcomputerkaarten gebruikt.

De integriteit van gegevens wordt onderverdeeld in ‘integriteit exportbericht’ en ‘integriteit geregistreerde gegevens’.

De boordcomputer kent zes gegevensleveringen, te weten ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ’Onderzoek’ en ‘Chauffeurskaartdata’. Deze gegevensleveringen worden allen in een exportbericht vanuit de boordcomputer overgebracht. Dit exportbestand bestaat uit een gegevenlevering zoals gespecificeerd in artikel 3 t/m 8, in combinatie met de bijbehorende elektronische handtekening.

Voor het genereren van het exportbericht en de bijbehorende elektronische handtekening wordt gebruik gemaakt van XAdES-BES. De XAdES specificatie (www.w3.org/TR/XAdES) is een door het World Wide Web Consortium (W3C) ontworpen standaard voor de XML syntax van elektronische handtekeningen.

Het XML exportbericht bestaat uit een <Envelope>-element met daarin een <Gegevenslevering>-element en een <Signature>-element. Het <Gegevenslevering>-element bevat een resultaatbericht van een gegevenslevering zoals gespecificeerd in artikel 3 t/m 8. Het <Signature>-tag bevat de corresponderende elektronische handtekening en informatie over de totstandkoming van deze handtekening.

Het XML exportbericht kent, conform de XAdES-BES specificatie, de volgende opbouw:

Toelichting:

1. a.

   de <Gegevenslevering>-tag bevat het resultaat bericht van een gegevenslevering.

2. b.

   de <DigestValue>-tags bevatten de waarden van digests van de elementen Gegevenslevering en KeyInfo. Hierbij wordt gebruik gemaakt van onderstaande algoritmen.

3. c.

   de <SignatureValue>-tag bevat de elektronische handtekening op basis van de digest value en het onderstaande Signature algoritme.

4. d.

   de <X509Certificate>-tag bevat het certificaat met de publieke sleutel van de boordcomputer.

De volgende algoritmen worden voor het genereren van het exportbericht gebruikt:

De keuze van het algoritme voor de Digest en de Signature is afhankelijk van het certificaat op de kaart waarmee de handtekening wordt gezet. Als dit certificaat met ‘RSA met SHA-256’ is ondertekend MOET SHA-256 worden gebruik. In de overige gevallen kan met SHA-1 worden volstaan.

Een aantal gegevens, die door de boordcomputer taxi worden geregistreerd, dienen vanaf het moment van vastleggen de waarborg van integriteit en authenticiteit te bevatten. In de specificatie van de gegevensleveringen in artikel 3 t/m 8 wordt aangegeven of de betreffende gegevens bij het vastleggen met een elektronische handtekening worden ondertekend. Hierbij wordt aangegeven welke private sleutel hiervoor gebruikt moet worden.

Voor een gegeven dat bij vastleggen elektronisch ondertekend wordt, wordt een tekenbericht gegenereerd. Over dit tekenbericht wordt met behulp van XadES-BES een elektronische handtekening geplaatst.

Het tekenbericht bestaat uit een <Envelope>-element met daarin een <Data>-element en een <Signature>-element. Het <Data>-element bevat de XML representatie van het te tekenen gegeven zoals gespecificeerd in de xsd’s in artikel 3 t/m 8. Het <Signature>-tag bevat de corresponderende elektronische handtekening en informatie over de totstandkoming van deze handtekening.

Toelichting:

1. a.

   de <Data>-tag bevat de te tekenen data opgemaakt volgens het corresponderende xsd.

2. b.

   de <DigestValue>-tags bevatten de waarden van digests van de elementen Data en KeyInfo. Hierbij wordt gebruik gemaakt van de algoritmen zoals genoemd in artikel 2.8.1.

3. c.

   de <SignatureValue>-tag bevat de elektronische handtekening op basis van de digest value en het Signature algoritme zoals genoemd in artikel 2.8.1.

Na generatie van het tekenbericht wordt de waarde van het element <SignatureValue> als <Integriteit> element opgeslagen bij de gegevens, die gezamenlijk het <Data> element vormen, en waarover de elektronische handtekening is berekend. Het tekenbericht hoeft niet te worden opgeslagen, zolang het <Data> element dat is getekend kan worden gereproduceerd.

Het genereren en vastleggen van de elektronische handtekening over het <Data> element vindt plaats bij het vastleggen van de gegevens die het Data element vormen.

Bij het samenstellen van een exportbericht worden de gegevens van het <Data> element onveranderd overgenomen uit de administratie op de boordcomputer. Het <Data> element wordt opnieuw geproduceerd, en moet exact gelijk zijn aan het <Data> element waarvoor een elektronische handtekening is berekend bij vastleggen van het gegeven. De geregistreerde elektronische handtekening moet worden overgenomen in het <Integriteit> element, het is niet toegestaan om de elektronische handtekening opnieuw te berekenen.

Een mogelijk proces voor het tekenen van gegevens en het exportbericht is weergegeven in figuur 2.

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

Bij onderstaande foutsituaties moet de boordcomputer de bijbehorende foutmelding tonen:

Het niet volledig zijn van gegevens op de boordcomputer mag geen reden zijn om een resultaat bericht niet te exporteren.

Voor de ritadministratie worden de volgende gegevens onderkend:

Toelichting:

1. a.

   de PERIODE is het tijdvak waarover de gebruiker de ritadministratie heeft opgevraagd

2. b.

   RIT wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

3. c.

   er zijn 2 mogelijke waarden voor ‘Type rit’: ‘Beladen rit’ en Onbeladen rit’.

4. d.

   een RIT moet ondertekend worden met de elektronische handtekening van de boordcomputer om de integriteit van de ritgegevens achteraf te kunnen bepalen. Daartoe bevat INTEGRITEIT het attribuut ‘Elektronische handtekening boordcomputer’.

5. e.

   de Ritprijs is in eurocenten

De functionele berichtstructuur ziet er als volgt uit:

Toelichting:

1. a.

   de linkerkolom beschrijft de hiërarchische structuur van het bericht.

2. b.

   de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel)

3. c.

   voor een RIT wordt de bestuurder opgenomen in het bericht.

Opmerking:

1. a.

   alleen als de chauffeurskaart niet beschikbaar is tijdens registratie van een RIT moet Chauffeurskaart volgnummer van de BESTUURDER gevuld worden met nullen.

2. b.

   de attributen ‘Coordinaat eindpunt rit’, ‘Datumtijd einde rit’, ‘Km stand einde rit’, ‘Ritprijs’ en de entiteit INTEGRITEIT zijn verplicht tenzij de RIT nog niet is beëindigd.

3. c.

   de mutatiecode van een RIT is ‘I’ als het volgnummer van de RIT voor de eerste keer wordt geregistreerd. De I staat voor Insert.

4. d.

   annuleren van de laatste handmatig ingevoerde ‘Aanvang rit’ is mogelijk. Het te annuleren record bevat alleen gegevens van het begin van de rit (‘Rit volgnummer’, ‘Mutatiecode’, ‘Datumtijd registratie’, ‘Type rit’, ‘Coordinaat beginpunt rit’ , ‘Datumtijd begin rit’ en ‘Km stand begin rit’). Annuleren moet op de volgende manier worden aangegeven:

   1. d1.

      de gegevens van het te annuleren record worden ongewijzigd ondertekend met de elektronische handtekening van de boordcomputer.

   2. d2.

      een nieuwe record wordt geregistreerd met de volgende gegevens: het volgnummer is gelijk aan het volgnummer van het te annuleren record uit d1, mutatiecode is ‘D’, ‘Datumtijd registratie’ is het tijdstip van registreren van dit nieuwe record, en de waarden van de overige attributen zijn gelijk aan de waarden van de overeenkomstige attributen van het te annuleren record. Ook dit record moet ondertekend worden met de elektronische handtekening van de boordcomputer.

5. e.

   annuleren van de laatste handmatig ingevoerde ‘Einde rit’ is mogelijk. Het te annuleren record bevat zowel gegevens van het begin van de rit (‘Volgnummer’, ‘Mutatiecode’, ‘Datumtijd registratie’, ‘Type rit’, ‘Coordinaat beginpunt rit’, ‘Datumtijd begin rit’ en ‘Km stand begin rit’) als einde van de rit (‘Coordinaat einde rit’, ‘Datumtijd einde rit’, ‘Km stand einde rit’, ‘Ritprijs’). Annuleren moet op de volgende manier worden aangegeven:

   1. e1.

      de gegevens van het te annuleren record worden ongewijzigd ondertekend met de elektronische handtekening van de boordcomputer als dit nog niet is gebeurd.

   2. e2.

      een nieuwe record wordt geregistreerd met de volgende gegevens: het volgnummer is gelijk aan het volgnummer van het te annuleren record uit e1, mutatiecode is ‘D’, ‘Datumtijd registratie’ is het tijdstip van registreren van dit nieuwe record, en de waarden van de overige attributen zijn gelijk aan de waarden van de overeenkomstige attributen van het te annuleren record. Ook dit record moet ondertekend worden met de elektronische handtekening van de boordcomputer.

   3. e3.

      een volgend nieuw record wordt geregistreerd met de volgende gegevens: het volgnummer is gelijk aan het volgnummer van het te annuleren record uit e1, mutatiecode is ‘M’, ‘Datumtijd registratie’ is het tijdstip van registreren van dit nieuwe record, de waarden van de attributen ‘Type rit’, ‘Coordinaat begin rit’ , ‘Datumtijd begin rit’ en ‘Km stand begin rit’ zijn gelijk aan de waarden van de overeenkomstige attributen van het te annuleren record, en de attributen ‘Coordinaat einde rit’ , ‘Datumtijd einde rit’, ‘Km stand einde rit’ en ‘Ritprijs’ zijn initieel leeg om gevuld te worden bij het opnieuw uitvoeren van de handmatige actie ‘Einde rit’.

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

De onderstaande ritadministratie.xsd wordt gebruikt.

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

Alle ritten worden ondertekend worden met een elektronische handtekening op basis van de private sleutel van de systeemkaart.

De ritadministratie bevat een element <Rit> en <Rit> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende ritgegevens:

1. ○

   RtVgNr

2. ○

   MtCd

3. ○

   DatTdReg

4. ○

   Type

5. ○

   LocBeg.Lat en LocBeg.Lon

6. ○

   DatTdBeg

7. ○

   KmStdBeg

8. ○

   LocEnd.Lat en LocEnd.Lon

9. ○

   DatTdEnd

10. ○

    KmStdEnd

11. ○

    Prijs

12. ○

    Bestuurder.BSN

13. ○

    Bestuurder.CkVgNr

Het <Integriteit> element bevat de elektronische handtekening van het bijbehorende Data element.

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

De naamgeving van de gegevenslevering ‘ritadministratie’ is als volgt:

Ritadministratie_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

Bij 100 ritten is het bericht ‘ritadministratie’ maximaal 100 Kbyte groot.

Voor het bericht ‘Arbeids-, rij- en rusttijden’ worden de volgende gegevens onderkend:

Toelichting:

1. a.

   de PERIODE is het tijdvak waarover de gebruiker de arbeidstijden heeft opgevraagd

2. b.

   ARBEIDSTIJD wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

3. c.

   RIJTIJD wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

4. d.

   PAUZE wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

5. e.

   ANDERE WERKZAAMHEDEN wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

6. f.

   ARBEIDSTIJD, inclusief bijbehorende voorkomens van RIJTIJD, PAUZE en ANDERE WERKZAAMHEDEN, moet ondertekend worden met een elektronische handtekening om de integriteit van de gegevens achteraf te kunnen bepalen. Indien de chauffeurskaart aanwezig is wordt getekend met de elektronische handtekening van de chauffeur, indien de chauffeurskaart niet aanwezig is wordt getekend met de elektronische handtekening van de boordcomputer.

Opmerkingen

1. a.

   de mutatiecode van een PAUZE of ANDERE WERKZAAMHEDEN is ‘I’ als het volgnummer van de PAUZE of ANDERE WERKZAAMHEDEN voor de eerste keer wordt geregistreerd. De I staat voor Insert.

2. b.

   annuleren van de laatste handmatige actie is mogelijk. Voor PAUZE en ANDERE WERKZAAMHEDEN moet dit op volgende manier worden aangegeven:

   1. b1.

      de bestaande PAUZE of ANDERE WERKZAAMHEDEN wordt niet gewijzigd.

   2. b2.

      een nieuwe PAUZE of ANDERE WERKZAAMHEDEN wordt geregistreerd met het volgnummer van de PAUZE of ANDERE WERKZAAMHEDEN die geannuleerd moet worden.

   3. b3.

      Datumtijd registratie van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN is het tijdstip van registratie van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN.

   4. b4.

      Mutatiecode van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN is ‘D’ om aan te geven dat de PAUZE of ANDERE WERKZAAMHEDEN met dit specifieke volgnummer geannuleerd moet worden.

3. c.

   voor de structuur van het bericht ‘Arbeids-, rij- en rusttijden’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

4. d.

   voor datatypen zie artikel over ‘Technische berichtstructuur’

De functionele bericht structuur ziet er als volgt uit:

Toelichting:

1. a.

   de linkerkolom beschrijft de hiërarchische structuur van het bericht.

2. b.

   de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel). De rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

3. c.

   ook in de taxivervoermodus zonder chauffeurskaart moeten ARBEIDSTIJD, RIJTIJD, PAUZE en ANDERE WERKZAAMHEDEN worden vastgelegd. Alle voorkomens van ARBEIDSTIJD, RIJTIJD, PAUZE en ANDERE WERKZAAMHEDEN die zijn vastgelegd zonder chauffeurskaart worden per VERVOERDER uitgeleverd voor een BESTUURDER met het handmatig ingegeven BSN en het Chauffeurskaart volgnummer gevuld met nullen.

4. d.

   een bericht bevat per BESTUURDER de optionele attributen ‘Publieke sleutel chauffeur’ en ‘Publieke sleutel boordcomputer’ waarvan precies 1 attribuut verplicht gevuld moet worden. Als de BESTUURDER bekend is moet het attribuut ‘Publieke sleutel chauffeur’ gevuld worden, als de bestuurder onbekend is moet het attribuut ‘Publieke sleutel boordcomputer’ gevuld worden.

5. e.

   een bericht bevat per ARBEIDSTIJD de optionele attributen ‘Elektronische handtekening chauffeur’ en ‘Elektronische handtekening boordcomputer’ waarvan precies 1 attribuut verplicht gevuld moet worden. Als de bijbehorende BESTUURDER bekend is moet het attribuut ‘Elektronische handtekening chauffeur’ gevuld worden, als de bestuurder onbekend is moet het attribuut ‘Elektronische handtekening boordcomputer’ gevuld worden.

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur

Het onderstaande Arbeidstijden.xsd wordt gebruikt.

De geselecteerde arbeidstijden moeten gegroepeerd per vervoerder, en daarbinnen per ondernemerskaart, en daarbinnen per bestuurder in oplopende volgorde van volgnummer worden opgenomen. Binnen een arbeidstijd moeten de rijtijd, pauze en andere werkzaamheden in oplopende volgorde van volgnummer worden opgenomen

Alle arbeidstijden worden ondertekend met een elektronische handtekening. Voor het plaatsen van de elektronische handtekening wordt gebruik gemaakt van de private sleutel van de chauffeurskaart indien deze aanwezig is, en van de private sleutel van de systeemkaart indien de chauffeurskaart niet aanwezig is.

De ‘Arbeids-, rij- en rusttijden’ bevat een element <Arbeidstijd> en <Arbeidstijd> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende arbeidstijd gegevens:

1. ○

   ArVgNr

2. ○

   DatTdReg

3. ○

   DatTdBeg

4. ○

   DatTdEnd

5. ○

   Rijtijd

6. ○

   RtVgNr

7. ○

   DatTdReg

8. ○

   DatTdBeg

9. ○

   DatTdEnd

10. ○

    Pauze

11. ○

    PzVgNr

12. ○

    MtCd

13. ○

    DatTdReg

14. ○

    DatTdBeg

15. ○

    DatTdEnd

16. ○

    AndrWrkzmhdn

17. ○

    AwVgNr

18. ○

    MtCd

19. ○

    DatTdReg

20. ○

    DatTdBeg

21. ○

    DatTdEnd

Het <Integriteit> element bevat de elektronische handtekening chauffeur of elektronische handtekening boordcomputer van het bijbehorende <Data> element.

Bij het samenstellen van bericht ‘Arbeids-, rij- en rusttijden’ moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de boordcomputer. Het berekenen van de ‘Elektronische handtekening chauffeur’ of ‘Elektronische handtekening boordcomputer’ van het <Data> element moet gebeuren bij het beëindigen van een arbeidstijd. De vastgelegde ‘Elektronische handtekening chauffeur’ of ‘Elektronische handtekening boordcomputer’ moeten per arbeidstijd onveranderd worden overgenomen in het onderliggende <Integriteit> element.

De naamgeving van de gegevenslevering ‘arbeidstijd’ is als volgt:

Arbeidstijd_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

Bij 100 arbeidstijden is het bericht ‘arbeidstijd’ maximaal 120 Kbyte groot.

Voor het bericht ‘Coördinaten’ worden de volgende gegevens onderkend:

Toelichting:

1. a.

   de PERIODE is het tijdvak waarover de gebruiker de coördinaten heeft opgevraagd

2. b.

   COORDINAAT wordt per VERVOERDER uniek geïdentificeerd door een volgnummer.

Opmerkingen:

1. a.

   voor de structuur van het bericht ‘Coördinaten’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

2. b.

   voor datatypen zie artikel over ‘Technische berichtstructuur’

De functionele bericht structuur ziet er als volgt uit:

Toelichting:

1. a.

   de linkerkolom beschrijft de hiërarchische structuur van het bericht.

2. b.

   de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel).

3. c.

   de rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

4. d.

   in werkingsmodus ‘Operationele modus’ is het attribuut ‘Werkingsniveau’ verplicht.

Opmerkingen:

1. a.

   alle coördinaten met een datumtijd registratie die ligt voor het tijdstip van de laatste activering van de boordcomputer worden gegroepeerd bij dezelfde AUTO - VERVOERDER - ONDERNEMERSKAART combinatie. Het kenteken, KvK-nummer, P-nummer en het volgnummer van de ondernemerskaart worden in deze groepering uitgevuld met nullen.

2. b.

   alle coördinaten die zijn geregistreerd na het tijdstip van de laatste activering worden geleverd met het kenteken van de auto, het KvK-nummer en P-nummer van de vervoerder en het volgnummer van de ondernemerskaart waarvoor de coördinaten zijn geregistreerd.

3. c.

   alleen de werkingsmodus ‘Operationele Modus’ kent meerder werkingsniveaus. Bij de overige modi wordt werkingsniveau ‘Basis’ aangehouden.

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

Het onderstaande Coordinaten.xsd wordt gebruikt.

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

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

De naamgeving van de gegevenslevering ‘coordinaten’ is als volgt:

Coordinaten_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

Kenteken is het kenteken van de auto waarin de boordcomputer als laatste is geactiveerd.

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

Voor het bericht ‘Gebeurtenis’ worden de volgende gegevens onderkend:

Toelichting:

1. a.

   de PERIODE is het tijdvak waarover de gebruiker de gebeurtenissen heeft opgevraagd

2. b.

   GEBEURTENIS wordt per VERVOERDER uniek geïdentificeerd door een volgnummer.

3. c.

   BESTUURDER is verplicht als tijdens het optreden van de gebeurtenis de werkingsmodus ‘Operationele Modus’ actief is in het werkingsniveau ‘Arbeidstijd’ of ‘Taxivervoer’,.

4. d.

   alleen de werkingsmodus ‘Operationele Modus’ kent meerder werkingsniveaus. Bij de overige modi wordt werkingsniveau ‘Basis’ aangehouden.

5. e.

   een GEBEURTENIS moet ondertekend worden met de elektronische handtekening van de boordcomputer om de integriteit van de gegevens achteraf te kunnen bepalen. Daartoe bevat INTEGRITEIT het attribuut ‘Elektronische handtekening boordcomputer’.

6. f.

   het attribuut ‘Status rijden auto’ wordt ingevuld op basis van gegevens van de verplaatsingsopnemer.

Opmerkingen:

1. a.

   voor de structuur van het bericht ‘Gebeurtenis’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

2. b.

   voor datatypen zie het artikel over ‘Technische berichtstructuur’

De functionele bericht structuur ziet er als volgt uit:

Toelichting:

1. a.

   de linkerkolom beschrijft de hiërarchische structuur van het bericht.

2. b.

   de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel).De rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

3. c.

   door het vullen van het attribuut ‘Aanvullende relevante informatie’ kan waar relevant aanvullende informatie worden toegevoegd voor een bepaalde code.

Opmerkingen:

1. a.

   alleen als de chauffeurskaart niet beschikbaar is tijdens registratie van een GEBEURTENIS moet Chauffeurskaart volgnummer van de BESTUURDER gevuld worden met nullen.

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

Het onderstaande Gebeurtenis.xsd wordt gebruikt.

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

Alle gebeurtenissen worden ondertekend op basis van de private sleutel van de boordcomputer.

Het bericht Gebeurtenis bevat een element <Gebeurtenis> en het element <Gebeurtenis> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende gegevens:

1. ○

   GbVgNr

2. ○

   Code

3. ○

   DatTdReg

4. ○

   KmStd

5. ○

   StRdnAt

6. ○

   WrkngsMds

7. ○

   WrkngsNv

8. ○

   AanvInfo

9. ○

   Bestuurder.BSN

10. ○

    Bestuurder.CkVgNr

Het <Integriteit> element bevat de elektronische handtekening boordcomputer van het bijbehorende <Data> element.

Bij het samenstellen van de het bericht ‘gebeurtenis’ moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de administratie op de boordcomputer. Het berekenen van de ‘Elektronische handtekening boordcomputer’ van het Data element van een Rit moet gebeuren bij het optreden van de gebeurtenis. De vastgelegde ‘Elektronische handtekening boordcomputer’ moet per gebeurtenis onveranderd worden overgenomen in het onderliggende <Integriteit> element.

In de onderstaande tabel staat de in het bericht op te nemen code per gebeurtenis vermeld.

De naamgeving van de gegevenslevering ‘gebeurtenis’ is als volgt:

Gebeurtenis_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

Bij 100 gebeurtenissen is het bericht ‘gebeurtenis’ maximaal 100 Kbyte groot.

Voor het bericht ‘Onderzoek’ worden de volgende gegevens onderkend:

Toelichting:

1. a.

   de PERIODE is het tijdvak waarover de gebruiker de onderzoeken heeft opgevraagd

2. b.

   ACTIVERINGSONDERZOEK wordt uniek geïdentificeerd door een volgnummer

3. c.

   PERIODIEK ONDERZOEK wordt uniek geïdentificeerd door een volgnummer

4. d.

   Constante boordcomputer is in impulsen per kilometer

5. e.

   Effectieve omtrek wielband is in millimeters

6. f.

   Bandenmaat is in inches

Opmerkingen:

1. a.

   voor de structuur van het bericht ‘Onderzoek’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

2. b.

   voor datatypen zie artikel over ‘Technische berichtstructuur’

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur: