Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)

No	Test	Description	Description	Related requirements
1.	Administrative examination	Administrative examination	Administrative examination	Administrative examination
1.1	Documentation	Correctness of documentation	Correctness of documentation
2.	Visual inspection for external GNSS facility	Visual inspection for external GNSS facility	Visual inspection for external GNSS facility	Visual inspection for external GNSS facility
2.1.	Compliance with documentation	Compliance with documentation	Compliance with documentation
2.2.	Identification/markings	Identification/markings	Identification/markings	224 to 226
2.3	Materials	Materials	Materials	219 to 223
3.	Functional tests	Functional tests	Functional tests	Functional tests
3.1	Sensor identification data	Sensor identification data	Sensor identification data	98,99
3.2	External GNSS module — vehicle unit coupling	External GNSS module — vehicle unit coupling	External GNSS module — vehicle unit coupling	123, 205
3.3	GNSS position	GNSS position	GNSS position	36, 37
3.4	Vehicle unit interface when the GNSS receiver is external to the Vehicle Unit	Vehicle unit interface when the GNSS receiver is external to the Vehicle Unit	Vehicle unit interface when the GNSS receiver is external to the Vehicle Unit	03
3.5	Cypher suite and standardized domain parameters	Cypher suite and standardized domain parameters	Cypher suite and standardized domain parameters	CSM_48, CSM_50
4.	Environmental tests	Environmental tests	Environmental tests	Environmental tests
4.1	Temperature	Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h @ 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 1 h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles	Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h @ 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 1 h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles	213
4.2	Humidity	Verify that the vehicle unit can withstand a cyclic damp (heat test) through IEC 60068-2-30, test Db, six 24 hours cycles, each temperature varying from + 25 °C to + 55 °C and a relative humidity of 97 % at + 25 °C and equal to 93 % at + 55 °C	Verify that the vehicle unit can withstand a cyclic damp (heat test) through IEC 60068-2-30, test Db, six 24 hours cycles, each temperature varying from + 25 °C to + 55 °C and a relative humidity of 97 % at + 25 °C and equal to 93 % at + 55 °C	214
4.3	Mechanical	1. Sinusoidal vibrations. verify that the vehicle unit can withstand sinusoidal vibrations with the following characteristics: constant displacement between 5 and 11 Hz: 10 mm peak constant acceleration between 11 and 300 Hz: 5g This requirement is verified through IEC 60068-2-6, test Fc, with a minimum test duration of 3 × 12 hours (12 hours per axis) ISO 16750-3 does not require a sinusoidal vibration test for devices located in the decoupled vehicle cab. 2. Random vibrations: Test according to ISO 16750-3: Chapter 4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle cab Random vibration test, 10…2 000  Hz, RMS vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS lateral 13,1 m/s2, 3 axes, 32 h per axis, including temperature cycle – 20…70°C. This test refers to IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh: Vibration, broadband random and guidance 3. Shocks: mechanical shock with 3g half sinus according ISO 16750. The tests described above are performed on different samples of the equipment type being tested.	1. Sinusoidal vibrations. verify that the vehicle unit can withstand sinusoidal vibrations with the following characteristics: constant displacement between 5 and 11 Hz: 10 mm peak constant acceleration between 11 and 300 Hz: 5g This requirement is verified through IEC 60068-2-6, test Fc, with a minimum test duration of 3 × 12 hours (12 hours per axis) ISO 16750-3 does not require a sinusoidal vibration test for devices located in the decoupled vehicle cab. 2. Random vibrations: Test according to ISO 16750-3: Chapter 4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle cab Random vibration test, 10…2 000  Hz, RMS vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS lateral 13,1 m/s2, 3 axes, 32 h per axis, including temperature cycle – 20…70°C. This test refers to IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh: Vibration, broadband random and guidance 3. Shocks: mechanical shock with 3g half sinus according ISO 16750. The tests described above are performed on different samples of the equipment type being tested.	219
4.4	Protection against water and foreign bodies	Test according to ISO 20653: Road vehicles — Degree of protection (IP code) — Protection of electrical equipment against foreign objects, water and access (No change in parameters)	Test according to ISO 20653: Road vehicles — Degree of protection (IP code) — Protection of electrical equipment against foreign objects, water and access (No change in parameters)	220, 221
4.5	Over-voltage protection	Verify that the vehicle unit can withstand a power supply of:	Verify that the vehicle unit can withstand a power supply of:	216
4.5	Over-voltage protection	24 V versions:	34 V at + 40 °C 1 hour	216
4.5	Over-voltage protection	12V versions:	17 V at + 40 °C 1 hour	216
4.5	Over-voltage protection	( ISO 16750-2, chapter 4.3)	( ISO 16750-2, chapter 4.3)	216
4.6	Reverse polarity protection	Verify that the vehicle unit can withstand an inversion of its power supply (ISO 16750-2, chapter 4.7)	Verify that the vehicle unit can withstand an inversion of its power supply (ISO 16750-2, chapter 4.7)	216
4.7	Short-circuit protection	Verify that input output signals are protected against short circuits to power supply and ground (ISO 16750-2, chapter 4.10])	Verify that input output signals are protected against short circuits to power supply and ground (ISO 16750-2, chapter 4.10])	216
5	EMC tests	EMC tests	EMC tests	EMC tests
5.1	Radiated emissions and susceptibility	Compliance with Regulation ECE R10	Compliance with Regulation ECE R10	218
5.2	Electrostatic discharge	Compliance with ISO 10605:2008 + Technical Corrigendum: 2010 + AMD1:2014: +/– 4kV for contact and +/– 8kV for air discharge	Compliance with ISO 10605:2008 + Technical Corrigendum: 2010 + AMD1:2014: +/– 4kV for contact and +/– 8kV for air discharge	218
5.3	Conducted transient susceptibility on power supply	For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs = – 450V Ri = 50 ohms pulse 2a: Vs= + 37V Ri = 2 ohms pulse 2b: Vs= + 20V Ri = 0,05 ohms pulse 3a: Vs= – 150V Ri = 50 ohms pulse 3b: Vs=+ 150V Ri = 50 ohms pulse 4: Vs = – 16 V Va = – 12V t6 = 100 ms pulse 5: Vs= + 120 V Ri = 2,2 ohms td = 250 ms For 12V versions: compliance with ISO 7637-1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs= – 75V Ri=10 ohms pulse 2a: Vs= + 37V Ri=2 ohms pulse 2b: Vs= + 10V Ri=0,05 ohms pulse 3a: Vs= – 112V Ri=50 ohms pulse 3b: Vs= + 75V Ri=50 ohms pulse 4: Vs= – 6V Va=-5V t6=15ms pulse 5: Vs= + 65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4.	For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs = – 450V Ri = 50 ohms pulse 2a: Vs= + 37V Ri = 2 ohms pulse 2b: Vs= + 20V Ri = 0,05 ohms pulse 3a: Vs= – 150V Ri = 50 ohms pulse 3b: Vs=+ 150V Ri = 50 ohms pulse 4: Vs = – 16 V Va = – 12V t6 = 100 ms pulse 5: Vs= + 120 V Ri = 2,2 ohms td = 250 ms For 12V versions: compliance with ISO 7637-1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs= – 75V Ri=10 ohms pulse 2a: Vs= + 37V Ri=2 ohms pulse 2b: Vs= + 10V Ri=0,05 ohms pulse 3a: Vs= – 112V Ri=50 ohms pulse 3b: Vs= + 75V Ri=50 ohms pulse 4: Vs= – 6V Va=-5V t6=15ms pulse 5: Vs= + 65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4.	218

No	Test	Test	Description	Related requirements
1.	Administrative examination	Administrative examination	Administrative examination	Administrative examination
1.1	Documentation	Documentation	Correctness of documentation
2.	Visual inspection	Visual inspection	Visual inspection	Visual inspection
2.1.	Compliance with documentation	Compliance with documentation	Compliance with documentation
2.2.	Identification / markings	Identification / markings	Identification / markings	225, 226
2.3	Materials	Materials	Materials	219 to 223
3.	Functional tests	Functional tests	Functional tests	Functional tests
3.1	Remote communication for targeted roadside checks	Remote communication for targeted roadside checks	Remote communication for targeted roadside checks	4, 197 to 199
3.2	Recording and storing in data memory	Recording and storing in data memory	Recording and storing in data memory	91
3.3	Communication with Vehicle Unit	Communication with Vehicle Unit	Communication with Vehicle Unit	Appendix 14 DSC_66 to DSC_70, DSC_71 to DSC_76
4.	Environmental tests	Environmental tests	Environmental tests	Environmental tests
4.1	Temperature	Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing - Part 2-1: Tests - Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h @ 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 1 h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles	Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing - Part 2-1: Tests - Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h @ 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 1 h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles	213
4.2	Protection against water and foreign bodies	Test according to ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (targeted value IP40)	Test according to ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (targeted value IP40)	220, 221
5	EMC tests	EMC tests	EMC tests	EMC tests
5.1	Radiated emissions and susceptibility	Compliance with Regulation ECE R10	Compliance with Regulation ECE R10	218
5.2	Electrostatic discharge	Compliance with ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014: +/– 4 kV for contact and +/– 8 kV for air discharge	Compliance with ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014: +/– 4 kV for contact and +/– 8 kV for air discharge	218
5.3	Conducted transient susceptibility on power supply	For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs=– 450V Ri=50 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+20V Ri=0,05 ohms pulse 3a: Vs=– 150V Ri=50 ohms pulse 3b: Vs=+150V Ri=50 ohms pulse 4: Vs=– 16V Va=-12V t6=100ms pulse 5: Vs=+120V Ri=2,2 ohms td=250ms For 12V versions: compliance with ISO 7637-1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs=-75V Ri=10 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+10V Ri=0,05 ohms pulse 3a: Vs=– 112V Ri=50 ohms pulse 3b: Vs=+75V Ri=50 ohms pulse 4: Vs=– 6V Va=– 5V t6=15ms pulse 5: Vs=+65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4.	For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs=– 450V Ri=50 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+20V Ri=0,05 ohms pulse 3a: Vs=– 150V Ri=50 ohms pulse 3b: Vs=+150V Ri=50 ohms pulse 4: Vs=– 16V Va=-12V t6=100ms pulse 5: Vs=+120V Ri=2,2 ohms td=250ms For 12V versions: compliance with ISO 7637-1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs=-75V Ri=10 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+10V Ri=0,05 ohms pulse 3a: Vs=– 112V Ri=50 ohms pulse 3b: Vs=+75V Ri=50 ohms pulse 4: Vs=– 6V Va=– 5V t6=15ms pulse 5: Vs=+65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4.	218

No	Test	Description	Related requirements
1.	Administrative examination	Administrative examination	Administrative examination
1.1	Documentation	Correctness of documentation
2	General Tests	General Tests	General Tests
2.1	Number of characters per line	Visual inspection of printouts.	172
2.2	Minimum character size	Visual inspection of printout and character inspection.	173
2.3	Supported character sets	The printer shall support characters specified in Appendix 1 Chapter 4 ‘Character sets’.	174
2.4	Printouts definition	Check of tachograph type approval and visual inspection of printouts	174
2.5	Legibility and identification of printouts	Inspection of printouts Demonstrated by test reports and test protocols by manufacturer. All homologation number(s) of tachographs with which the printer paper may be used are imprinted on the paper.	175, 177, 178
2.6	Addition of handwritten notes	Visual inspection: Field for signature of the driver is available. Fields for additional other handwritten entries are available.	180
2.7	Additional details on paper faces.	Paper's face and reverse side may feature additional details and information. These additional details and information may not interfere with the legibility of the printouts. Visual inspection.	177, 178
3	Storage Tests	Storage Tests	Storage Tests
3.1	Dry Heat	Preconditioning: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity Test environment: 72 hours at + 70 °C ± 2 °C Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178 IEC 60068-2-2-Bb
2.2	Damp Heat	Preconditioning: 16 hours at + 23 °C ± 2 °C/55 % ±3 % relative humidity Test environment: 144 hours at + 55 °C ± 2 °C and 93 % ± 3 % r.h. Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178 IEC 60068-2-78-Cab
4	Paper In-Service Tests	Paper In-Service Tests	Paper In-Service Tests
4.1	Humidity resistance background (unprinted paper)	Preconditioning: 16 hours at + 23 °C ± 2 °C/55 % ±3 % relative humidity Test environment: 144 hours at + 55 °C ± 2 °C and 93 % ± 3 % r.h. Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178 IEC 60068-2-78-Cab
4.2	Printability	Preconditioning: 24 hours at + 40 °C ± 2 °C/93 % ± 3 % relative humidity Test environment: printout produced at + 23 °C ± 2 °C Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178
4.3	Heat resistance	Preconditioning: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity Test environment: 2 hours at + 70 °C ± 2 °C, dry heat Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178 IEC 60068-2-2-Bb
4.4	Low temperature resistance	Preconditioning: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity Test environment: 24 hours – 20 °C ± 3 °C, dry cold Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178 ISO 60068-2-1-Ab
4.5	Light resistance	Preconditioning: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity Test environment: 100 hours under 5 000 Lux illumination at + 23 °C ± 2 °C/55 % ± 3 % relative humidity Recovery: 16 hours at + 23 °C ± 2 °C/55 % ± 3 % relative humidity	176, 178

Legibility criteria for tests 3.x and 4.x:

Printout legibility is assured if optical densities comply with the following limits:

Printed characters: min. 1,0

Background (unprinted paper): max. 0,2

Optical densities of the resulting printouts shall be measured according to DIN EN ISO 534.

Printouts shall show no dimensional changes and remain clearly legible.

No	Test	Description
8.1  Interoperability tests between vehicle units and tachograph cards	8.1  Interoperability tests between vehicle units and tachograph cards	8.1  Interoperability tests between vehicle units and tachograph cards
1	Mutual authentication	Check that the mutual authentication between the vehicle unit and the tachograph card runs normally
2	Write/read tests	Execute a typical activity scenario on the vehicle unit. The scenario shall be adapted to the type of card being tested and involve writings in as many EFs as possible in the card Verify through a vehicle unit downloading that all corresponding recordings have been properly made Verify through a card downloading that all corresponding recordings have been properly made Verify through daily printouts that all corresponding recordings can be properly read
8.2  Interoperability tests between vehicle units and motion sensors	8.2  Interoperability tests between vehicle units and motion sensors	8.2  Interoperability tests between vehicle units and motion sensors
1	Pairing	Check that the pairing between the vehicle units and the motion sensors runs normally
2	Activity tests	Execute a typical activity scenario on the motion sensor. The scenario shall involve a normal activity and creating as many events or faults as possible. Verify through a vehicle unit downloading that all corresponding recordings have been properly made Verify through a card downloading that all corresponding recordings have been properly made Verify through a daily printout that all corresponding recordings can be properly read
8.3  Interoperability tests between vehicle units and external GNSS facilities (when applicable)	8.3  Interoperability tests between vehicle units and external GNSS facilities (when applicable)	8.3  Interoperability tests between vehicle units and external GNSS facilities (when applicable)
1	Mutual authentication	Check that the mutual authentication (coupling) between the vehicle unit and the external GNSS module runs normally.
2	Activity tests	Execute a typical activity scenario on the external GNSS facility. The scenario shall involve a normal activity and creating as many events or faults as possible. Verify through a vehicle unit downloading that all corresponding recordings have been properly made Verify through a card downloading that all corresponding recordings have been properly made Verify through a daily printout that all corresponding recordings can be properly read

• 9.1. Introduction This chapter describes the tests to prove the correct implementation of OSNMA in the GNSS receiver. Since satellite signal authentication is carried out solely by the GNSS receiver with independence of any other component of the tachograph, the tests set out in this chapter may be performed on the GNSS receiver as a stand-alone element. In this case, the tachograph manufacturer shall present a report to the type-approval authorities providing details about the development and results of the tests that are performed under the responsibility of the GNSS receiver manufacturer.

• 9.2 Applicable conditions
• — The pass/fail criteria defined in the OSNMA tests shall be considered valid only for the identified testing conditions.
• — The criteria might be revised at the moment of the Galileo OSNMA service declaration and considering the associated service performance commitments.

• 9.3. Definitions and acronyms
• 9.3.1 Definitions GNSS cold/warm/hot start : refers to the start condition of a GNSS receiver based on the availability of time (T), current almanac (A) and ephemeris (E), position (P): — GNSS Cold Start: none — GNSS Warm Start: T, A, P — GNSS Hot Start: T, A, E, P OSNMA cold/warm/hot start : refers to the start condition of the OSNMA function based on the availability of the Public Key (P) and DSM-KROOT (K) information (as defined in the OSNMA Receiver Guidelines referred to in Appendix 12): — OSNMA Cold Start: none — OSNMA Warm Start: P — OSNMA Hot Start: P, K
• 9.3.2 Acronyms ADKD Authentication Data & Key Delay DSM-KROOT Digital Signature Message KROOT GNSS Global Navigation Satellite System KROOT Root Key of the TESLA key chain MAC Message Authentication Code NMACK Number of MAC & key blocks (per 30 seconds) OSNMA Galileo Open Service Navigation Message Authentication SLMAC Slow MAC TESLA Timed Efficient Stream Loss-tolerant Authentication (Protocol used in OSNMA)

- 9.4. Equipment for the generation of the GNSS signals

The generation of the GNSS signals can be carried out using a multi-constellation GNSS simulator supporting OSNMA message transmission. Alternatively, a radiofrequency signal re-player capable of playing back GNSS signal samples from files can be used. Typical bit depth and sampling rate are respectively 4 bits I/Q and 10MHz. It is assumed that the GNSS receiver has interfaces to command the clearing of the receiver memory (to independently erase the public key, KROOT, clock information, position information, ephemeris and almanac), to set the receiver local time realisation for the OSNMA timing verification requirement, and to load the cryptographic information. These commands may be limited to test purposes and therefore may not be available for the receiver nominal operation.

- 9.5 Test conditions

• 9.5.1 GNSS conditions The simulated or replayed GNSS signals will have the following features:
• — Static user receiver scenario;
• — At least GPS and Galileo constellations;
• — E1/L1 frequency;
• — At least 4 Galileo satellites with elevation angle greater than 5°;
• — Duration as required for each test;
• — Constant navigation ephemerides from the satellites during the test.
• 9.5.2 OSNMA conditions The OSNMA message transmitted in the RF signal will have the following features:
• — An HKROOT message with OSNMA Status set to Operational or Test and a fixed DSM-KROOT of 8 blocks for the chain in force;
• — At least 4 Galileo satellites transmitting OSNMA;
• — A MACK message with one MACK block (i.e. NMACK=1), and at least one ADKD=0 and one ADKD=12 per satellite and MACK block;
• — A tag size of 40 bits;
• — The minimum equivalent tag length as required in the OSNMA Receiver Guidelines (currently 80 bits). Except when noted, the internal receiver time realisation shall be known with sufficient accuracy and properly aligned with the simulated time. This guarantees that the OSNMA initial time synchronisation requirement is fulfilled for each test condition, i.e., nominal synchronization for all but the SLMAC test. See the OSNMA Receiver Guidelines for more details on the time initialization. Note that the identified pass/fail criteria are conservative and do not represent the expected Galileo OSNMA performance.

- 9.6. Tests specification

No Test Description Related requirements

1.1 Documentation Correctness of documentation 2 General Tests 2.1 OSNMA hot start Objective: verify that the GNSS receiver computes a position with OSNMA after a hot start. Procedure: The GNSS receiver starts in GNSS and OSNMA hot start conditions and acquires the signals of visible Galileo satellites. The receiver authenticates the Galileo navigation data with OSNMA (ADKD = 0) and provides a position with authenticated data. Pass/fail criteria: the receiver computes an authenticated position fix within 160 seconds. Appendix 12, GNS_3b 2.2 OSNMA warm start Objective: verify that the GNSS receiver computes a position with OSNMA after a warm start. Procedure: Before starting the test, the ephemeris and KROOT information shall be erased from the GNSS receiver memory in order to force a warm GNSS and OSNMA start. The GNSS receiver starts and acquires the signals of the visible Galileo satellites. The DSM-KROOT is received and verified. The receiver authenticates the Galileo navigation data with OSNMA (ADKD=0) and provides a position with authenticated data. Pass/fail criteria: the receiver computes an authenticated valid position fix within 430 seconds. Appendix 12, GNS_3b 2.3 OSNMA warm start with SLMAC Objective: verify that the GNSS receiver computes a position with OSNMA after a warm start with a time initialisation requiring SLMAC mode, as defined in the OSNMA Receiver Guidelines. Procedure: The internal receiver time realisation shall be configured in order to have an initial time uncertainty of a value between 2 and 2.5 minutes so that, according to OSNMA Receiver Guidelines, the Slow MAC mode is activated. Before starting the tests, the ephemeris and KROOT information shall be erased from the GNSS receiver memory in order to force a warm GNSS and OSNMA start. The GNSS receiver starts and acquires the signals of the visible Galileo satellites. The DSM-KROOT is received and verified. The receiver authenticates the Galileo navigation data with only OSNMA Slow MAC (ADKD=12) and provides a position with authenticated data. Pass/fail criteria: the receiver computes an authenticated valid position fix within 730 seconds. Appendix 12, GNS_3b 2.4 OSNMA hot start with replayed signal Objective: verify that the GNSS receiver detects a replayed signal. Procedure: The GNSS receiver starts in GNSS and OSNMA hot start conditions and acquires the signals of visible Galileo satellites. The receiver authenticates the Galileo navigation data with OSNMA (ADKD=0) and provides a position with authenticated data. Once the receiver provides PVT solution with authenticated data, it is switched off. A replayed signal with a delay of 40 seconds with respect to the previous one is simulated, and the receiver is switched on. The receiver detects that the Galileo System Time from the signal-in-space time and the local timing realisation do not meet the synchronisation requirement and it stops processing OSNMA data as defined in OSNMA Receiver Guidelines. Pass/fail criteria: the receiver detects the replay and does not compute an authenticated valid position since the start of the replay until the end of the test. Appendix 12, GNS_3b 2.5 OSNMA hot start with false data Objective: Verify that OSNMA detects false data. Procedure: The GNSS receiver starts in GNSS and OSNMA hot start conditions. The GNSS receiver shall be able to acquire the signal of all the visible Galileo satellites and verify the authenticity of their navigation messages by means of OSNMA. At least one bit of the ephemeris data provided by each Galileo satellite does not correspond with the original and authenticated data, but the Galileo I/NAV message must be coherent, including CRC. Pass/fail criteria: the receiver detects the false data within 160 seconds and does not compute an authenticated valid position until the end of the test. Appendix 12, GNS_3b

Appendix 10

SECURITY REQUIREMENTS

This appendix specifies the IT security requirements for the smart tachograph system components (second-generation tachograph).

• SEC_001The following components of the smart tachograph system shall be security certified according to the Common Criteria scheme:

• — vehicle unit

• — tachograph card,

• — motion sensor,

• — external GNSS facility.

• SEC_002The minimum IT security requirements to be met by each component needing to be security certified shall be defined in a component Protection Profile, according to the Common Criteria scheme.

• SEC_003The European Commission shall make sure that four Protection Profiles compliant with this Annex are sponsored, developed, approved by the governmental IT security certification bodies organised within the Joint Interpretation Working Group (JIWG) which is supporting the mutual recognition of certificates under the umbrella of the European SOGIS-MRA (Agreement on Mutual Recognition of Information Technology Security Evaluation Certificates) and registered:

• — Protection Profile for vehicle unit,

• — Protection Profile for tachograph card,

- — Protection Profile for motion sensor,

• — Protection Profile for external GNSS facility.

The Protection Profile for vehicle unit shall address the cases when the VU is designed to be used or not with an external GNSS facility. In the former case, the security requirements of the external GNSS facility are provided in the dedicated Protection Profile.

• SEC_004Component manufacturers shall refine and complete the appropriate component Protection Profile as necessary, without amending or deleting existing threats, objectives, procedural means and security enforcing functions specifications, in order to build a Security Target against which they shall seek the security certification of the component.

• SEC_005Strict conformance of such specific Security Target with the corresponding Protection Profile must be stated during the evaluation process.

• SEC_006The assurance level for each Protection Profile shall be EAL4 augmented by the assurance components ATE_DPT.2 and AVA_VAN.5.

Appendix 11

COMMON SECURITY MECHANISMS

TABLE OF CONTENTS	TABLE OF CONTENTS
	PREAMBLE
PART A	FIRST-GENERATION TACHOGRAPH SYSTEM
1.	INTRODUCTION
1.1.	References
1.2.	Notations and abbreviated terms
2.	CRYPTOGRAPHIC SYSTEMS AND ALGORITHMS
2.1.	Cryptographic systems
2.2.	Cryptographic algorithms
2.2.1	RSA algorithm
2.2.2	Hash algorithm
2.2.3	Data Encryption Algorithm
3.	KEYS AND CERTIFICATES
3.1.	Keys generation and distribution
3.1.1	RSA Keys generation and distribution
3.1.2	RSA Test keys
3.1.3	Motion sensor keys
3.1.4	T-DES session keys generation and distribution
3.2.	Keys
3.3.	Certificates
3.3.1	Certificates content
3.3.2	Certificates issued
3.3.3	Certificate verification and unwrapping
4.	MUTUAL AUTHENTICATION MECHANISM
5.	VU-CARDS DATA TRANSFER CONFIDENTIALITY, INTEGRITY AND AUTHENTICATION MECHANISMS
5.1.	Secure Messaging
5.2.	Treatment of Secure Messaging errors
5.3.	Algorithm to compute Cryptographic Checksums
5.4.	Algorithm to compute cryptograms for confidentiality DOs
6.	DATA DOWNLOAD DIGITAL SIGNATURE MECHANISMS
6.1.	Signature generation
6.2.	Signature verification
PART B	SECOND-GENERATION TACHOGRAPH SYSTEM
7.	INTRODUCTION
7.1.	References
7.2.	Notations and Abbreviations
7.3.	Definitions
8.	CRYPTOGRAPHIC SYSTEMS AND ALGORITHMS
8.1.	Cryptographic Systems
8.2.	Cryptographic Algorithms
8.2.1	Symmetric Algorithms
8.2.2	Asymmetric Algorithms and Standardized Domain Parameters
8.2.3	Hashing algorithms
8.2.4	Cipher Suites
9.	KEYS AND CERTIFICATES
9.1.	Asymmetric Key Pairs and Public Key Certificates
9.1.1	General
9.1.2	European Level
9.1.3	Member State Level
9.1.4	Equipment Level: Vehicle Units
9.1.5	Equipment Level: Tachograph Cards
9.1.6	Equipment Level: External GNSS Facilities
9.1.7	Overview: Certificate Replacement
9.2.	Symmetric Keys
9.2.1	Keys for Securing VU — Motion Sensor Communication
9.2.2	Keys for Securing DSRC Communication
9.3.	Certificates
9.3.1	General
9.3.2	Certificate Content
9.3.3	Requesting Certificates
10.	VU- CARD MUTUAL AUTHENTICATION AND SECURE MESSAGING
10.1.	General
10.2.	Mutual Certificate Chain Verification
10.2.1	Card Certificate Chain Verification by VU
10.2.2	VU Certificate Chain Verification by Card
10.3.	VU Authentication
10.4.	Chip Authentication and Session Key Agreement
10.5.	Secure Messaging
10.5.1	General
10.5.2	Secure Message Structure
10.5.3	Secure Messaging Session Abortion
11.	VU — EXTERNAL GNSS FACILITY COUPLING, MUTUAL AUTHENTICATION AND SECURE MESSAGING
11.1.	General
11.2.	VU and External GNSS Facility Coupling
11.3.	Mutual Certificate Chain Verification
11.3.1	General
11.3.2	During VU — EGF Coupling
11.3.3	During Normal Operation
11.4.	VU Authentication, Chip Authentication and Session Key Agreement
11.5.	Secure Messaging
12.	VU — MOTION SENSOR PAIRING AND COMMUNICATION
12.1.	General
12.2.	VU — Motion Sensor Pairing Using Different Key Generations
12.3.	VU — Motion Sensor Pairing and Communication using AES
12.4.	VU — Motion Sensor Pairing For Different Equipment Generations
13.	SECURITY FOR REMOTE COMMUNICATION OVER DSRC
13.1.	General
13.2.	Tachograph Payload Encryption and MAC Generation
13.3.	Verification and Decryption of Tachograph Payload
14.	SIGNING DATA DOWNLOADS AND VERIFYING SIGNATURES
14.1.	General
14.2.	Signature generation
14.3.	Signature verification

PREAMBLE

This Appendix specifies the security mechanisms ensuring

• — mutual authentication between different components of the tachograph system.

• — confidentiality, integrity, authenticity and/or non-repudiation of data transferred between different components of the tachograph system or downloaded to external storage media.

This Appendix consists of two parts. Part A defines the security mechanisms for the first-generation tachograph system (digital tachograph). Part B defines the security mechanisms for the second-generation tachograph system (smart tachograph).

The mechanisms specified in Part A of this Appendix shall apply if at least one of the components of the tachograph system involved in a mutual authentication and/or data transfer process is of the first generation.

The mechanisms specified in Part B of this Appendix shall apply if both components of the tachograph system involved in the mutual authentication and/or data transfer process are of the second generation.

Appendix 15 provides more information regarding the use of first generation components in combination with second-generation components.

PART A

FIRST-GENERATION TACHOGRAPH SYSTEM

1.1.   References

The following references are used in this Appendix:

• SHA-1 National Institute of Standards and Technology (NIST). FIPS Publication 180-1: Secure Hash Standard. April 1995.

• PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Standard. Version 2.0. October 1998.

• TDES National Institute of Standards and Technology (NIST). FIPS Publication 46-3: Data Encryption Standard. Draft 1999.

• TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation. 1998.

• ISO/IEC 7816-4 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 4: Interindustry commands for interexchange. First edition: 1995 + Amendment 1: 1997.

• ISO/IEC 7816-6 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements. First edition: 1996 + Cor 1: 1998.

• ISO/IEC 7816-8 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands. First edition 1999.

• ISO/IEC 9796-2 Information Technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Mechanisms using a hash function. First edition: 1997.

• ISO/IEC 9798-3 Information Technology — Security techniques — Entity authentication mechanisms — Part 3: Entity authentication using a public key algorithm. Second edition 1998.

• ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Motion sensor interface.

1.2.   Notations and abbreviated terms

The following notations and abbreviated terms are used in this Appendix:

• (Ka, Kb, Kc) a key bundle for use by the Triple Data Encryption Algorithm,

• CA Certification Authority,

• CAR Certification Authority Reference,

• CC Cryptographic Checksum,

• CG Cryptogram,

• CH Command Header,

• CHA Certificate Holder Authorisation,

• CHR Certificate Holder Reference,

• D() Decryption with DES,

• DE Data Element,

- DO Data Object,

- d RSA private key, private exponent,

• e RSA public key, public exponent,

• E() Encryption with DES,

• EQT Equipment,

• Hash() hash value, an output of Hash,

• Hash hash function,

- KID Key Identifier,

• Km TDES key. Master Key defined in ISO 16844-3.

• KmVU TDES key inserted in vehicle units.

• KmWC TDES key inserted in workshop cards.

• m message representative, an integer between 0 and n-1,

• n RSA keys, modulus,

• PB Padding Bytes,

• PI Padding Indicator byte (for use in Cryptogram for confidentiality DO),

• PV Plain Value,

• s signature representative, an integer between 0 and n-1,

- SSC Send Sequence Counter,

- SM Secure Messaging,

• TCBC TDEA Cipher Block Chaining Mode of Operation

• TDEA Triple Data Encryption Algorithm,

• TLV Tag Length Value,

• VU Vehicle Unit,

• X.C the certificate of user X issued by a certification authority,

• X.CA a certification authority of user X,

• X.CA.PK o X.C the operation of unwrapping a certificate to extract a public key. It is an infix operator, whose left operand is the public key of a certification authority, and whose right operand is the certificate issued by that certification authority. The outcome is the public key of the user X whose certificate is the right operand,

• X.PK RSA public key of a user X,

• X.PK[I] RSA encipherment of some information I, using the public key of user X,

• X.SK RSA private key of a user X,

• X.SK[I] RSA encipherment of some information I, using the private key of user X,

• ‘xx’ an Hexadecimal value,

|| concatenation operator.

2.1.   Cryptographic systems

• CSM_001Vehicle units and tachograph cards shall use a classical RSA public-key cryptographic system to provide the following security mechanisms:

• — authentication between vehicle units and cards,

• — transport of Triple-DES session keys between vehicle units and tachograph cards,

• — digital signature of data downloaded from vehicle units or tachograph cards to external media.

• CSM_002Vehicle units and tachograph cards shall use a Triple DES symmetric cryptographic system to provide a mechanism for data integrity during user data exchange between vehicle units and tachograph cards, and to provide, where applicable, confidentiality of data exchange between vehicle units and tachograph cards.

2.2.   Cryptographic algorithms

2.2.1   RSA algorithm

• CSM_003The RSA algorithm is fully defined by the following relations:

X.SK[m] = s = m^d mod n

X.PK[s] = m = s^e mod n

• A more comprehensive description of the RSA function can be found in reference [PKCS1]. Public exponent, e, for RSA calculations is an integer between 3 and n-1 satisfying gcd(e, lcm(p-1, q-1))=1.

2.2.2   Hash algorithm

- CSM_004The digital signature mechanisms shall use the SHA-1 hash algorithm as defined in reference [SHA-1].

2.2.3   Data Encryption Algorithm

• CSM_005DES based algorithms shall be used in Cipher Block Chaining mode of operation.

3.1.   Keys generation and distribution

3.1.1   RSA Keys generation and distribution

• CSM_006RSA keys shall be generated through three functional hierarchical levels:

• — European level,

• — Member State level,

• — Equipment level.

• CSM_007At European level, a single European key pair (EUR.SK and EUR.PK) shall be generated. The European private key shall be used to certify the Member States public keys. Records of all certified keys shall be kept. These tasks shall be handled by a European Certification Authority, under the authority and responsibility of the European Commission.

• CSM_008At Member State level, a Member State key pair (MS.SK and MS.PK) shall be generated. Member States public keys shall be certified by the European Certification Authority. The Member State private key shall be used to certify public keys to be inserted in equipment (vehicle unit or tachograph card). Records of all certified public keys shall be kept with the identification of the equipment to which it is intended. These tasks shall be handled by a Member State Certification Authority. A Member State may regularly change its key pair.

• CSM_009At equipment level, one single key pair (EQT.SK and EQT.PK) shall be generated and inserted in each equipment. Equipment public keys shall be certified by a Member State Certification Authority. These tasks may be handled by equipment manufacturers, equipment personalisers or Member State authorities. This key pair is used for authentication, digital signature and encipherement services

• CSM_010Private keys confidentiality shall be maintained during generation, transport (if any) and storage.

• The following picture summarises the data flow of this process:

• Image omitted; see official source

3.1.2   RSA Test keys

• CSM_011For the purpose of equipment testing (including interoperability tests) the European Certification Authority shall generate a different single European test key pair and at least two Member State test key pairs, the public keys of which shall be certified with the European private test key. Manufacturers shall insert, in equipment undergoing type approval tests, test keys certified by one of these Member State test keys.

3.1.3   Motion sensor keys

The confidentiality of the three Triple DES keys described below shall be appropriately maintained during generation, transport (if any) and storage.

In order to support tachograph components compliant with ISO 16844, the European Certification Authority and the Member State Certification Authorities shall, in addition, ensure the following:

• CSM_036

The European Certification authority shall generate KmVU and KmWC, two independent and unique Triple DES keys, and generate Km as: Km = KmVU XOR KmWC . The European Certification Authority shall forward these keys, under appropriately secured procedures, to Member States Certification Authorities at their request.

• CSM_037Member States Certification Authorities shall:

• — use Km to encrypt motion sensor data requested by motion sensor manufacturers (data to be encrypted with Km is defined in ISO 16844-3),

• — forward KmVU to vehicle unit manufacturers, under appropriately secured procedures, for insertion in vehicle units,

• — ensure that KmWC will be inserted in all workshop cards (Image omitted; see official source in Image omitted; see official source elementary file) during card personalisation.

3.1.4   T-DES session keys generation and distribution

• CSM_012Vehicle units and tachograph cards shall, as a part of the mutual authentication process, generate and exchange necessary data to elaborate a common Triple DES session key. This exchange of data shall be protected for confidentiality through an RSA crypt-mechanism.

• CSM_013This key shall be used for all subsequent cryptographic operations using secure messaging. Its validity shall expire at the end of the session (withdrawal of the card or reset of the card) and/or after 240 use (one use of the key = one command using secure messaging sent to the card and associated response).

3.2.   Keys

• CSM_014RSA keys shall have (whatever the level) the following lengths: modulus n1 024 bits, public exponent e 64 bits maximum, private exponent d1 024 bits.

• CSM_015Triple DES keys shall have the form (Ka, Kb, Ka) where Ka and Kb are independent 64 bits long keys. No parity error detecting bits shall be set.

3.3.   Certificates

• CSM_016RSA Public key certificates shall be ‘non self-descriptive’‘Card Verifiable’ certificates (Ref.: ISO/IEC 7816-8)

3.3.1   Certificates content

• CSM_017RSA Public key certificates are built with the following data in the following order:

Data	Format	Bytes	Obs
CPI	INTEGER	1	Certificate Profile Identifier (‘01’ for this version)
CAR	OCTET STRING	8	Certification Authority Reference
CHA	OCTET STRING	7	Certificate Holder Authorisation
EOV	TimeReal	4	Certificate end of validity. Optional, ‘FF’ padded if not used.
CHR	OCTET STRING	8	Certificate Holder Reference
n	OCTET STRING	128	Public key (modulus)
e	OCTET STRING	8	Public Key (public exponent)
		164

Notes:

• 1.The ‘Certificate Profile Identifier’ (CPI) delineates the exact structure of an authentication certificate. It can be used as an equipment internal identifier of a relevant headerlist which describes the concatenation of Data Elements within the certificate.

• The headerlist associated with this certificate content is as follows:

‘4D’	‘16’	‘5F 29’	‘01’	‘42’	‘08’	‘5F 4B’	‘07’	‘5F 24’	‘04’	‘5F 20’	‘08’	‘7F 49’	‘05’	‘81’	‘81 80’	‘82’	‘08’
Extended Headerlist Tag	Length of header list	CPI Tag	CPI Length	CAR Tag	CAR Length	CHA Tag	CHA Length	EOV Tag	EOV Length	CHR Tag	CHR Length	Public Key Tag (Constructed)	Length of subsequent DOs	modulus Tag	modulus length	public exponent Tag	public exponent length
Extended Headerlist Tag	Length of header list	CPI Tag	CPI Length	CAR Tag	CAR Length	CHA Tag	CHA Length	EOV Tag	EOV Length	CHR Tag	CHR Length	Public Key Tag (Constructed)	Length of subsequent DOs
Extended Headerlist Tag	Length of header list

• 2.The ‘Certification Authority Reference’ (CAR) has the purpose of identifying the certificate issuing CA, in such a way that the Data Element can be used at the same time as an Authority Key Identifier to reference the Public Key of the Certification Authority (for coding, see Key Identifier below).

• 3.The ‘Certificate Holder Authorisation’ (CHA) is used to identify the rights of the certificate holder. It consists of the Tachograph Application ID and of the type of equipment to which the certificate is intended (according to Image omitted; see official source data element, ‘00’ for a Member State).

• 4.The ‘Certificate Holder Reference’ (CHR) has the purpose of identifying uniquely the certificate holder, in such a way that the Data Element can be used at the same time as a Subject Key Identifier to reference the Public Key of the certificate holder.

• 5.Key Identifiers uniquely identify certificate holder or certification authorities. They are coded as follows:

- 5.1 Equipment (VU or Card):

Data Equipment serial number Date Type Manufacturer Length 4 Bytes 2 Bytes 1 Byte 1 Byte Value Integer mm yy BCD coding Manufacturer specific Manufacturer code In the case of a VU, the manufacturer, when requesting certificates, may or may not know the identification of the equipment in which the keys will be inserted. In the first case, the manufacturer will send the equipment identification with the public key to its Member State authority for certification. The certificate will then contain the equipment identification, and the manufacturer must ensure that keys and certificate are inserted in the intended equipment. The Key identifier has the form shown above. In the later case, the manufacturer must uniquely identify each certificate request and send this identification with the public key to its Member State authority for certification. The certificate will contain the request identification. The manufacturer must feed back its Member State authority with the assignment of key to equipment (i.e. certificate request identification, equipment identification) after key installation in the equipment. The key identifier has the following form: Data Certificate request serial number Date Type Manufacturer Length 4 Bytes 2 Bytes 1 Byte 1 Byte Value Integer mm yy BCD coding ‘FF’ Manufacturer code

• 5.2 Certification Authority: Data Authority Identification Key serial number Additional info Identifier Length 4 Bytes 1 Byte 2 Bytes 1 Byte Value 1 Byte nation numerical code 3 Bytes nation alphanumerical code Integer additional coding (CA specific) ‘FF FF’ if not used ‘01’ The key serial number is used to distinguish the different keys of a Member State, in the case the key is changed.

• 6.Certificate verifiers shall implicitly know that the public key certified is an RSA key relevant to authentication, digital signature verification and encipherement for confidentiality services (the certificate contains no Object Identifier to specify it).

3.3.2   Certificates issued

• CSM_018The certificate issued is a digital signature with partial recovery of the certificate content in accordance with ISO/IEC 9796-2 (except for its annex A4), with the ‘Certification Authority Reference’ appended.

X.C = X.CA.SK[‘6A’ || Cr || Hash(Cc) || ‘BC’] || Cn || X.CAR

With certificate content = Cc =	Cr	||	Cn
	106 bytes		58 bytes

Notes:

- 1.This certificate is 194 bytes long.

- 2.CAR, being hidden by the signature, is also appended to the signature, such that the Public Key of the Certification Authority may be selected for the verification of the certificate.

• 3.The certificate verifier shall implicitly know the algorithm used by the Certification Authority to sign the certificate.

• 4.The headerlist associated with this issued certificate is as follows:

‘7F 21’	‘09’	‘5F 37’	‘81 80’	‘5F 38’	‘3A’	‘42’	‘08’
CV Certificate Tag (Constructed)	Length of subsequent DOs	Signature Tag	Signature Length	Remainder Tag	Remainder Length	CAR Tag	CAR Length
CV Certificate Tag (Constructed)	Length of subsequent DOs

3.3.3   Certificate verification and unwrapping

Certificate verification and unwrapping consists in verifying the signature in accordance with ISO/IEC 9796-2, retrieving the certificate content and the public key contained: X.PK = X.CA.PK o X.C, and verifying the validity of the certificate.

• CSM_019It involves the following steps:

Verify signature and retrieve content:

—  from X.C retrieve Sign, Cn' and CAR':	X.C =	Sign	||	Cn'	||	CAR'
		128 Bytes		58 Bytes		8 Bytes

• — from CAR' select appropriate Certification Authority Public Key (if not done before through other means)

• — open Sign with CA Public Key: Sr'= X.CA.PK [Sign],

• — check Sr' starts with ‘6A’ and ends with ‘BC’

—  compute Cr' and H' from: Sr' =	‘6A’	||	Cr'	||	H'	||	‘BC’
			106 Bytes		20 Bytes

• — Recover certificate content C' = Cr' || Cn',

• — check Hash(C') = H'

If the checks are OK the certificate is a genuine one, its content is C'.

Verify validity. From C':

• — if applicable, check End of validity date,

Retrieve and store public key, Key Identifier, Certificate Holder Authorisation and Certificate End of Validity from C':

• — X.PK = n || e

• — X.KID = CHR

• — X.CHA = CHA

- — X.EOV = EOV

Mutual authentication between cards and VUs is based on the following principle:

Each party shall demonstrate to the other that it owns a valid key pair, the public key of which has been certified by a Member State certification authority, itself being certified by the European certification authority.

Demonstration is made by signing with the private key a random number sent by the other party, who must recover the random number sent when verifying this signature.

The mechanism is triggered at card insertion by the VU. It starts with the exchange of certificates and unwrapping of public keys, and ends with the setting of a session key.

- CSM_020The following protocol shall be used (arrows indicate commands and data exchanged (see Appendix 2)):

• Image omitted; see official source

• Image omitted; see official source

5.1.   Secure Messaging

• CSM_021VU-Cards data transfers integrity shall be protected through Secure Messaging in accordance with references [ISO/IEC 7816-4] and [ISO/IEC 7816-8].

• CSM_022When data need to be protected during transfer, a Cryptographic Checksum Data Object shall be appended to the Data Objects sent within the command or the response. The Cryptographic Checksum shall be verified by the receiver.

• CSM_023The cryptographic checksum of data sent within a command shall integrate the command header, and all data objects sent (=>CLA = ‘0C’, and all data objects shall be encapsulated with tags in which b1=1).

• CSM_024The response status-information bytes shall be protected by a cryptographic checksum when the response contains no data field.

• CSM_025Cryptographic checksums shall be 4 Bytes long.

• The structure of commands and responses when using secure messaging is therefore the following:

The DOs used are a partial set of the Secure Messaging DOs described in ISO/IEC 7816-4:

| Tag | Mnemonic | Meaning |

| --- | --- | --- | | ‘81’ | TPV | Plain Value not BER-TLV coded data (to be protected by CC) | | ‘97’ | TLE | Value of Le in the unsecured command (to be protected by CC) | | ‘99’ | TSW | Status-Info (to be protected by CC) | | ‘8E’ | TCC | Cryptographic Checksum | | ‘87’ | TPI CG | Padding Indicator Byte || Cryptogram (Plain Value not coded in BER-TLV) |

Given an unsecured command response pair:

Command header	Command header	Command header	Command header	Command body	Command body	Command body
CLA	INS	P1	P2	[Lc field]	[Data field]	[Le field]
four bytes	four bytes	four bytes	four bytes	L bytes, denoted as B1 to BL	L bytes, denoted as B1 to BL	L bytes, denoted as B1 to BL
Response body	Response trailer	Response trailer
---	---	---
[Data field]	SW1	SW2
Lr data bytes	two bytes	two bytes

The corresponding secured command response pair is:

Secured command:

Command header (CH)	Command header (CH)	Command header (CH)	Command header (CH)	Command body	Command body	Command body	Command body	Command body	Command body	Command body	Command body	Command body	Command body	Command body
CLA	INS	P1	P2	[New Lc field]	[New Data field]	[New Data field]	[New Data field]	[New Data field]	[New Data field]	[New Data field]	[New Data field]	[New Data field]	[New Data field]	[New Le field]
‘OC’	‘OC’	‘OC’	‘OC’	Length of New Data field	TPV	LPV	PV	TLE	LLE	Le	TCC	LCC	CC	‘00’
‘OC’	‘OC’	‘OC’	‘OC’	Length of New Data field	‘81’	Lc	Data field	‘97’	‘01’	Le	‘8E’	‘04’	CC	‘00’

Data to be integrated in checksum = CH || PB || TPV || LPV || PV || TLE || LLE || Le || PB

PB = Padding Bytes (80 .. 00) in accordance with ISO-IEC 7816-4 and ISO 9797 method 2.

DOs PV and LE are present only when there is some corresponding data in the unsecured command.

Secured response:

• 1. Case where response data field is not empty and needs not to be protected for confidentiality: Response body Response trailer [New Data field] new SW1 SW2 TPV LPV PV TCC LCC CC ‘81’ Lr Data field ‘8E’ ‘04’ CC Data to be integrated in checksum = TPV || LPV || PV || PB

• 1. Case where response data field is not empty and needs to be protected for confidentiality: Response body Response trailer [New Data field] new SW1 SW2 TPI CG LPI CG PI CG TCC LCC CC ‘87’

PI || CG

‘8E’ ‘04’ CC Data to be carried by CG: non BER-TLV coded data and padding bytes. Data to be integrated in checksum = TPI CG || LPI CG || PI CG || PB

• 1. Case where response data field is empty: Response body Response trailer [New Data field] new SW1 SW2 TSW LSW SW TCC LCC CC ‘99’ ‘02’ New SW1 SW2 ‘8E’ ‘04’ CC Data to be integrated in checksum = TSW || LSW || SW || PB

5.2.   Treatment of Secure Messaging errors

• CSM_026When the tachograph card recognises an SM error while interpreting a command, then the status bytes must be returned without SM. In accordance with ISO/IEC 7816-4, the following status bytes are defined to indicate SM errors:

‘66 88’	:	Verification of Cryptographic Checksum failed,
---	---	---
‘69 87’	:	Expected SM Data Objects missing,

| | | |

| --- | --- | --- | | ‘69 88’ | : | SM Data Objects incorrect. |

- CSM_027When the tachograph card returns status bytes without SM DOs or with an erroneous SM DO, the session must be aborted by the VU.

5.3.   Algorithm to compute Cryptographic Checksums

- CSM_028Cryptographic checksums are built using a retail MACs in accordance with ANSI X9.19 with DES:

• — Initial stage: The initial check block y0 is E(Ka, SSC).

• — Sequential stage: The check blocks y1, .., yn are calculated using Ka.

• — Final stage: The cryptographic checksum is calculated from the last check block yn as follows: E(Ka, D(Kb, yn)).

• where E() means encryption with DES, and D() means decryption with DES.

• The four most significant bytes of the cryptographic checksum are transferred

• CSM_029The Send Sequence Counter (SSC) shall be initiated during key agreement procedure to:

• Initial SSC: Rnd3 (4 least significant bytes) || Rnd1 (4 least significant bytes).

• CSM_030The Send Sequence Counter shall be increased by 1 each time before a MAC is calculated (i.e. the SSC for the first command is Initial SSC + 1, the SSC for the first response is Initial SSC + 2).

• The following figure shows the calculation of the retail MAC:

• Image omitted; see official source

5.4.   Algorithm to compute cryptograms for confidentiality DOs

• CSM_031Cryptograms are computed using TDEA in TCBC mode of operation in accordance with references [TDES] and [TDES-OP] and with the Null vector as Initial Value block.

• The following figure shows the application of keys in TDES:

• Image omitted; see official source

- CSM_032The Intelligent Dedicated Equipment (IDE) stores data received from an equipment (VU or card) during one download session within one physical data file. This file must contain the certificates MSi.C and EQT.C. The file contains digital signatures of data blocks as specified in Appendix 7 Data Downloading Protocols.

• CSM_033Digital signatures of downloaded data shall use a digital signature scheme with appendix such, that downloaded data may be read without any decipherment if desired.

6.1.   Signature generation

• CSM_034Data signature generation by the equipment shall follow the signature scheme with appendix defined in reference [PKCS1] with the SHA-1 hash function:

Signature = EQT.SK[‘00’ || ‘01’ || PS || ‘00’ || DER(SHA-1(Data))]

PS = Padding string of octets with value ‘FF’ such that length is 128.

DER(SHA-1(M)) is the encoding of the algorithm ID for the hash function and the hash value into an ASN.1 value of type DigestInfo (distinguished encoding rules):

‘30’||‘21’||‘30’||‘09’||‘06’||‘05’||‘2B’||‘0E’||‘03’||‘02’||‘1A’||‘05’||‘00’||‘04’||‘14’||Hash Value.

6.2.   Signature verification

• CSM_035Data signature verification on downloaded data shall follow the signature scheme with appendix defined in reference [PKCS1] with the SHA-1 hash function.

• The European public key EUR.PK needs to be known independently (and trusted) by the verifier.

• The following table illustrates the protocol an IDE carrying a Control card can follow to verify the integrity of data downloaded and stored on the ESM (External Storage media). The control card is used to perform the decipherement of digital signatures. This function may in this case not be implemented in the IDE.

• The equipment that has downloaded and signed the data to be analysed is denoted EQT.

• Image omitted; see official source

PART B

SECOND-GENERATION TACHOGRAPH SYSTEM

7.1.   References

The following references are used in this part of this Appendix.

• AES National Institute of Standards and Technology (NIST), FIPS PUB 197: Advanced Encryption Standard (AES), November 26, 2001

• DSS National Institute of Standards and Technology (NIST), FIPS PUB 186-4: Digital Signature Standard (DSS), July 2013

• ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange. Third edition 2013-04-15

• ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security operations. Second edition 2004-06-01

• ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Fourth edition, 2008-12-15

• ISO 9797-1 ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher. Second edition, 2011-03-01

• ISO 10116 ISO/IEC 10116, Information technology — Security techniques — Modes of operation of an n-bit block cipher. Third edition, 2006-02-01

• ISO 16844-3 ISO/IEC 16844-3, Road vehicles — Tachograph systems — Part 3: Motion sensor interface. First edition 2004, including Technical Corrigendum 1 2006

• RFC 5480 Elliptic Curve Cryptography Subject Public Key Information, March 2009

• RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool Standard Curves and Curve Generation, 2010

• RFC 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010

• SHS National Institute of Standards and Technology (NIST), FIPS PUB 180-4: Secure Hash Standard, March 2012

• SP 800-38B National Institute of Standards and Technology (NIST), Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, 2005

• TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryptography, version 2.00, 2012-06-28

7.2.   Notations and Abbreviations

The following notations and abbreviated terms are used in this Appendix:

• AES Advanced Encryption Standard

• CA Certificate Authority

• CAR Certificate Authority Reference

• CBC Cipher Block Chaining (mode of operation)

• CH Command Header

• CHA Certificate Holder Authorisation

• CHR Certificate Holder Reference

- CV Constant Vector

• DER Distinguished Encoding Rules

- DO Data Object

- DSRC Dedicated Short Range Communication

• ECC Elliptic Curve Cryptography

• ECDSA Elliptic Curve Digital Signature Algorithm

• ECDH Elliptic Curve Diffie-Hellman (key agreement algorithm)

• EGF External GNSS Facility

• EQT Equipment

• IDE Intelligent Dedicated Equipment

• KM Motion Sensor Master Key, allowing the pairing of a Vehicle Unit to a Motion Sensor

• KM-VU Key inserted in vehicle units, allowing a VU to derive the Motion Sensor Master Key if a workshop card is inserted into the VU

• KM-WC Key inserted in workshop cards, allowing a VU to derive the Motion Sensor Master Key if a workshop card is inserted into the VU

• MAC Message Authentication Code

• MoS Motion Sensor

• MSB Most Significant Bit

• PKI Public Key Infrastructure

• RCF Remote Communication Facility

• SSC Send Sequence Counter

• SM Secure Messaging

• TDES Triple Data Encryption Standard

• TLV Tag Length Value

• VU Vehicle Unit

- X.C the public key certificate of user X

• X.CA the certificate authority that issued the certificate of user X

• X.CAR the certificate authority reference mentioned in the certificate of user X

- X.CHR the certificate holder reference mentioned in the certificate of user X

• X.PK public key of user X

• X.SK private key of user X

• X.PKeph ephemeral public key of user X

• X.SKeph ephemeral private key of user X

• ‘xx’ a hexadecimal value

|| concatenation operator

7.3.   Definitions

The definitions of terms used in this Appendix are included in section I of Annex 1C.

8. CRYPTOGRAPHIC SYSTEMS AND ALGORITHMS

8.1.   Cryptographic Systems

• CSM_38Vehicle units and tachograph cards shall use an elliptic curve-based public-key cryptographic system to provide the following security services:

• — mutual authentication between a vehicle unit and a card,

• — agreement of AES session keys between a vehicle unit and a card,

• — ensuring the authenticity, integrity and non-repudiation of data downloaded from vehicle units or tachograph cards to external media.

• CSM_39Vehicle units and external GNSS facilities shall use an elliptic curve-based public-key cryptographic system to provide the following security services:

• — coupling of a vehicle unit and an external GNSS facility,

- — mutual authentication between a vehicle unit and an external GNSS facility,

- — agreement of an AES session key between a vehicle unit and an external GNSS facility.

• CSM_40Vehicle units and tachograph cards shall use an AES-based symmetric cryptographic system to provide the following security services:

• — ensuring authenticity and integrity of data exchanged between a vehicle unit and a tachograph card,

- — where applicable, ensuring confidentiality of data exchanged between a vehicle unit and a tachograph card.

- CSM_41Vehicle units and external GNSS facilities shall use an AES-based symmetric cryptographic system to provide the following security services:

• — ensuring authenticity and integrity of data exchanged between a vehicle unit and an external GNSS facility.

• CSM_42Vehicle units and motion sensors shall use an AES-based symmetric cryptographic system to provide the following security services:

• — pairing of a vehicle unit and a motion sensor,

• — mutual authentication between a vehicle unit and a motion sensor,