zurück

3. Funktionstests am Bewegungssensor

4. Funktionsprüfungen an Fahrtenschreiberkarten

Die Prüfungen gemäß diesem Abschnitt 4,

Abschnitt 5 "Protokollprüfungen",

Abschnitt 6 "Kartenstruktur" und

Abschnitt 7 "Funktionsprüfungen"

können vom prüfenden oder bescheinigenden Unternehmen während der CC-Sicherheitszertifizierung (Common Criteria bzw. Allgemeine Kriterien für die Bewertung der Sicherheit für Informationstechnologie) für das Chipmodul durchgeführt werden.

Die Prüfungen 2.3 und 4.2 sind identisch. Hierbei handelt es sich um mechanische Prüfungen der Kombination Kartenkörper/Chipmodul. Wenn eine dieser Komponenten (Kartenkörper, Chipmodul) geändert wird, sind diese Prüfungen erforderlich.

5. Prüfung externer GNSS-Ausrüstung

6. Prüfungen der externen Ausrüstung zur Fernkommunikation ¹⁸

7. Papierfunktionsprüfungen

Lesbarkeitskriterien für die Prüfungen 3.x und 4.x:

Lesbarkeit des Ausdrucks ist gewährleistet, wenn die optische Dichte die folgenden Grenzwerte einhält:

Gedruckte Zeichen: min. 1,0

Hintergrund (unbedrucktes Papier): max. 0,2

Optische Dichten der Ausdrucke zu messen gemäß DIN EN ISO 534.

Bei den Ausdrucken dürfen keine Änderungen der Maße auftreten; sie müssen perfekt lesbar bleiben.

8. Interoperabilitätsprüfungen ¹⁸

9. Osnma-Prüfungen

9.1. Einleitung

In diesem Kapitel werden die Prüfungen beschrieben, mit denen die korrekte Implementierung von OSNMA im GNSS-Empfänger nachzuweisen ist. Da die Authentisierung der Satellitensignale ausschließlich vom GNSS-Empfänger und unabhängig von anderen Komponenten des Fahrtenschreibers durchgeführt wird, können die in diesem Kapitel beschriebenen Prüfungen am GNSS-Empfänger als eigenständiges Element durchgeführt werden. In diesem Fall legt der Hersteller des Fahrtenschreibers den Typgenehmigungsbehörden einen Bericht mit Einzelheiten zur Entwicklung und zu den Ergebnissen der Prüfungen vor, die unter der Verantwortung des Herstellers des GNSS-Empfängers durchgeführt wurden.

9.2. Anwendbare Bedingungen

• Die in den OSNMA-Prüfungen festgelegten Kriterien für "bestanden"/"nicht bestanden" werden nur für die festgestellten Prüfbedingungen als gültig betrachtet.
• Die Kriterien könnten zum Zeitpunkt der Erklärung des Galileo OSNMA-Dienstes und unter Berücksichtigung der damit verbundenen Leistungsverpflichtungen des Dienstes geändert werden.

9.3. Begriffsbestimmungen und Akronyme

9.3.1 Begriffsbestimmungen

9.3.2 Akronyme

9.4. Ausrüstung für die Erzeugung der GNSS-Signale

Die GNSS-Signale können unter Verwendung eines GNSS-Simulators mit mehreren Konstellationen, der die Übertragung von OSNMA-Nachrichten unterstützt, erzeugt werden. Alternativ kann eine Hochfrequenzsignal-Wiedergabevorrichtung verwendet werden, die in der Lage ist, GNSS-Signalproben aus Dateien wiederzugeben. Die typische Bit-Tiefe und Abtastfrequenz sind 4 Bits I/Q und 10 MHz.

Es wird davon ausgegangen, dass der GNSS-Empfänger über Schnittstellen verfügt, über die Befehle zum Löschen des Empfängerspeichers gegeben werden können (unabhängiges Löschen des öffentlichen Schlüssels, von KROOT, Uhrzeitinformationen, Positionsinformationen, Ephemeriden- und Almanach-Daten), um die Realisierung der lokalen Zeit des Empfängers für die OSNMA-Zeitverifizierungsanforderung festzulegen und die kryptografischen Informationen zu laden. Diese Befehle können auf Prüfzwecke beschränkt sein und daher für den Nennbetrieb des Empfängers möglicherweise nicht verfügbar sein.

9.5. Prüfbedingungen

9.5.1 GNSS-Bedingungen

Die simulierten oder wiedergegebenen GNSS-Signale weisen folgende Merkmale auf:

• Szenario eines statischen Nutzerempfängers
• Mindestens GPS- und Galileo-Konstellationen
• E1/L1-Frequenz
• Mindestens 4 Galileo-Satelliten mit einem Höhenwinkel von mehr als 5°
• Dauer wie für jede Prüfung erforderlich
• Konstante Navigationsephemeriden von den Satelliten während der Prüfung

9.5.2 OSNMA-Bedingungen

Die im HF-Signal übermittelte OSNMA-9.4Merkmale auf:

• Eine HKROOT-Nachricht, deren OSNMA-Status auf Betrieb oder Prüfung eingestellt ist, und eine feste DSM-KROOT von 8 Blöcken für die geltende Kette
• Mindestens 4 Galileo-Satelliten, die OSNMA übertragen
• Eine MACK-Nachricht mit einem MACK-Block (d. h. NMACK = 1) und mindestens einem ADKD = 0 und einem ADKD = 12 pro Satellit und MACK-Block
• Eine Tag-Größe von 40 Bit
• Die Tag-Mindestlänge, wie sie in den Leitlinien für OSNMA-Empfänger vorgeschrieben ist (derzeit 80 Bit).

Sofern nichts anderes angegeben, muss die interne Empfängerzeitrealisierung mit ausreichender Genauigkeit bekannt sein und ordnungsgemäß an die simulierte Zeit angeglichen sein. Dadurch wird gewährleistet, dass die Anforderung der Synchronisierung der OSNMA-Anfangszeit für jede Prüfbedingung erfüllt ist, d. h. eine nominale Synchronisierung für alle Prüfungen außer der SLMAC-Prüfung. Weitere Einzelheiten zur Zeitinitialisierung sind in den Leitlinien für OSNMA-Empfänger zu finden.

Hinweis: Die genannten Kriterien für "bestanden"/"nicht bestanden" sind konservativ und repräsentieren nicht die erwartete Leistung von Galileo OSNMA.

9.6. Prüfspezifikation

.

In dieser Anlage werden die Anforderungen an die IT-Sicherheit für die Komponenten von intelligenten Fahrtenschreibersystemen (Fahrtenschreiber der zweiten Generation) festgelegt.

SEC_001 Für folgende Komponenten des intelligenten Fahrtenschreibersystems erfolgt eine Sicherheitszertifizierung gemäß dem Common-Criteria-Zertifizierungsverfahren:

• Fahrzeugeinheit,
• Fahrtenschreiberkarte,
• Bewegungssensor,
• externe GNSS-Ausrüstung.

SEC_002 Die von jeder Komponente, für die eine Sicherheitszertifizierung zu erfolgen hat, zu erfüllenden Mindestanforderungen an die IT-Sicherheit werden in einem Schutzprofil gemäß dem Common-Criteria-Zertifizierungsverfahren festgelegt.

SEC_003 Die Europäische Kommission stellt sicher, dass vier mit diesem Anhang konforme Schutzprofile gefördert, entwickelt, von den für die IT-Sicherheitszertifizierung zuständigen staatlichen Stellen, die in der Joint Interpretation Working Group zusammenarbeiten (die die gegenseitige Anerkennung von Zertifikaten im Rahmen des europäischen Abkommens zur gegenseitigen Anerkennung von IT-Sicherheitszertifikaten (Agreement on Mutual Recognition of Information Technology Security Evaluation Certificates, SOGIS-MRA) unterstützt), genehmigt und registriert werden:

• Schutzprofil für die Fahrzeugeinheit,
• Schutzprofil für die Fahrtenschreiberkarte,
• Schutzprofil für den Bewegungssensor,
• Schutzprofil für die externe GNSS-Ausrüstung.

Das Schutzprofil für die Fahrzeugeinheit gilt für die Fälle, in denen die VU zur Verwendung mit oder ohne eine externe GNSS-Ausrüstung bestimmt ist. Im ersten Fall sind die Sicherheitsanforderungen der externen GNSS-Ausrüstung im spezifischen Schutzprofil festgelegt.

SEC_004 Zur Formulierung der Sicherheitsanforderungen, die bei Beantragung der Sicherheitszertifizierung für die Komponente erfüllt werden müssen, konkretisieren und vervollständigen die Komponentenhersteller erforderlichenfalls das geeignete Schutzprofil, ohne die bestehenden Sicherheitsgefährdungen, Ziele, Verfahrensmöglichkeiten und SEF-Spezifikationen zu ändern bzw. zu streichen.

SEC_005 Während des Bewertungsverfahrens muss die strikte Konformität dieser spezifischen Sicherheitsanforderungen mit dem entsprechenden Schutzprofil festgestellt werden.

SEC_006 Die für jedes Schutzprofil vorgegebene Vertrauenswürdigkeitsstufe ist EAL4, erweitert um die Vertrauenswürdigkeitskomponenten ATE_DPT.2 und AVA_VAN.5.

.

Vorwort

Diese Anlage enthält die Spezifizierung der Sicherheitsmechanismen zur Gewährleistung

• der gegenseitigen Authentisierung zwischen unterschiedlichen Komponenten im Fahrtenschreibersystem.
• Vertraulichkeit, Integrität, Authentizität und/oder Nichtabstreitbarkeit der zwischen den unterschiedlichen Komponenten des Fahrtenschreibersystems übertragenen oder auf externe Speichermedien heruntergeladenen Daten.

Diese Anlage besteht aus zwei Teilen. In Teil A werden die Sicherheitsmechanismen für das Fahrtenschreibersystem der 1. Generation (digitaler Fahrtenschreiber) definiert. In Teil B werden die Sicherheitsmechanismen für das Fahrtenschreibersystem der 2. Generation (intelligenter Fahrtenschreiber) definiert.

Die in Teil A dieser Anlage angegebenen Mechanismen kommen zur Anwendung, wenn mindestens eine der am Prozess der gegenseitigen Authentisierung und/oder Datenübertragung beteiligten Komponenten des Fahrtenschreibersystems der 1. Generation angehört.

Die in Teil B dieser Anlage angegebenen Mechanismen kommen zur Anwendung, wenn beide am Prozess der gegenseitigen Authentisierung und/oder Datenübertragung beteiligten Komponenten des Fahrtenschreibersystems der 2. Generation angehören.

In Anlage 15 sind weitere Informationen über die Verwendung von Komponenten der 1. Generation zusammen mit Komponenten der 2. Generation aufgeführt.

Teil A
Fahrtenschreibersystem der 1. Generation

1. Einleitung

1.1. Referenzdokumente

In dieser Anlage werden folgende Referenzdokumente herangezogen:

1.2. Notationen und Abkürzungen

In dieser Anlage werden folgende Notationen und Abkürzungen verwendet:

2. Kryptografische Systeme und Algorithmen

2.1. Kryptografische Systeme

CSM_001 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden ein klassisches RSA-Public-Key-Verschlüsselungssystem, sodass folgende Sicherheitsmechanismen vorliegen:

• Authentisierung zwischen Fahrzeugeinheiten und Karten,
• Übertragung von Triple-DES-Sitzungsschlüsseln zwischen Fahrzeugeinheiten und Fahrtenschreiberkarten,
• digitale Signatur von Daten, die von Fahrzeugeinheiten oder Fahrtenschreiberkarten an externe Medien heruntergeladen werden.

CSM_002 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden ein symmetrisches Triple-DES-Verschlüsselungssystem, sodass ein Mechanismus für die Datenintegrität während des Benutzerdatenaustauschs zwischen Fahrzeugeinheiten und Fahrtenschreiberkarten und gegebenenfalls die Vertraulichkeit beim Datenaustausch zwischen Fahrzeugeinheiten und Fahrtenschreiberkarten gewährleistet sind.

2.2. Kryptografische Algorithmen

2.2.1 RSA-Algorithmus

CSM_003 Der RSA-Algorithmus wird durch folgende Beziehungen vollständig definiert:

Eine ausführlichere Beschreibung der RSA-Funktion findet sich im Referenzdokument PKCS1. Der im RSA-Algorithmus verwendete öffentliche Exponent e ist eine Ganzzahl zwischen 3 und n-1, wobei gilt: gcd(e, lcm(p-1, q-1))=1.

2.2.2 Hash-Algorithmus

CSM_004 Die Mechanismen für die digitale Signatur verwenden den Hash-Algorithmus SHA-1 gemäß Definition im Referenzdokument SHA-1.

2.2.3 Datenverschlüsselungsalgorithmus

CSM_005 DES-gestützte Algorithmen werden im Modus Cipher Block Chaining verwendet.

3. Schlüssel und Zertifikate

3.1. Erzeugung und Verteilung der Schlüssel

3.1.1 Erzeugung und Verteilung der RSA-Schlüssel

CSM_006 Die Erzeugung der RSA-Schlüssel erfolgt auf drei hierarchischen Funktionsebenen:

• auf europäischer Ebene,
• auf Mitgliedstaatebene,
• auf Geräteebene.

CSM_007 Auf europäischer Ebene wird ein einziges Schlüsselpaar (EUR.SK und EUR.PK) erzeugt. Der europäische private Schlüssel wird zur Zertifizierung der öffentlichen Schlüssel der Mitgliedstaaten verwendet. Über alle zertifizierten Schlüssel sind Belege aufzubewahren. Diese Aufgaben werden von einer Europäischen Zertifizierungsstelle wahrgenommen, die der Europäischen Kommission untersteht.

CSM_008 Auf Mitgliedstaatebene wird ein Mitgliedstaatschlüsselpaar (MS.SK und MS.PK) erzeugt. Öffentliche Mitgliedstaatschlüssel werden von der Europäischen Zertifizierungsstelle zertifiziert. Der private Mitgliedstaatschlüssel wird für die Zertifizierung von öffentlichen Schlüsseln verwendet, die in Geräten (Fahrzeugeinheit oder Fahrtenschreiberkarte) eingefügt sind. Über alle zertifizierten öffentlichen Schlüssel sind Belege zusammen mit der Kennung des Geräts, für das sie bestimmt sind, aufzubewahren. Diese Aufgaben werden von der Zertifizierungsstelle des jeweiligen Mitgliedstaates wahrgenommen. Ein Mitgliedstaat darf sein Schlüsselpaar in regelmäßigen Abständen ändern.

CSM_009 Auf Geräteebene wird ein einziges Schlüsselpaar (EQT.SK und EQT.PK) erzeugt und in jedes Gerät eingefügt. Die öffentlichen Geräteschlüssel werden von der Zertifizierungsstelle des jeweiligen Mitgliedstaates zertifiziert. Diese Aufgaben können von Geräteherstellern, Geräteintegratoren und Behörden der Mitgliedstaaten wahrgenommen werden. Dieses Schlüsselpaar wird zur Authentisierung, für die digitale Signatur sowie zur Chiffrierung verwendet.

CSM_010 Bei der Erzeugung, ggf. bei der Übertragung sowie bei der Speicherung ist die Vertraulichkeit der privaten Schlüssel zu wahren.

Im folgenden Schaubild ist der Datenfluss dieses Prozesses zusammengefasst:

3.1.2 RSA-Prüfschlüssel

CSM_011 Zum Zwecke der Geräteprüfung (einschließlich Interoperabilitätsprüfungen) erzeugt die Europäische Zertifizierungsstelle ein anderes einziges europäisches Prüfschlüsselpaar und mindestens zwei Mitgliedstaat-Prüfschlüsselpaare, deren öffentliche Schlüssel mit dem europäischen privaten Prüfschlüssel zertifiziert werden. Von den Herstellern werden in Geräte, die der Typgenehmigungsprüfung unterzogen werden, Prüfschlüssel eingefügt, die durch einen dieser Mitgliedstaatprüfschlüssel zertifiziert sind.

3.1.3 Bewegungssensorschlüssel

Die Geheimhaltung der drei genannten T-DES-Schlüssel ist während der Erzeugung, der Übermittlung und ggf. der Aufbewahrung in geeigneter Weise zu gewährleisten.

Um die Unterstützung von Fahrtenschreiberkomponenten, die der ISO 16844 entsprechen, zu gewährleisten, stellen die Europäische Zertifizierungsstelle und die Zertifizierungsstellen der Mitgliedstaaten darüber hinaus Folgendes sicher:

CSM_036 Die Europäische Zertifizierungsstelle erzeugt KmVU und KmWC als zwei voneinander unabhängige und einmalige Triple-DES-Schlüssel sowie Km, wobei gilt:

Die Europäische Zertifizierungsstelle übermittelt diese Schlüssel unter geeigneten Sicherheitsvorkehrungen auf deren Anforderung an die Zertifizierungsstellen der Mitgliedstaaten.

CSM_037 Die Zertifizierungsstellen der Mitgliedstaaten:

• verschlüsseln mit Km die von den Herstellern der Bewegungssensoren angeforderten Bewegungssensordaten (die mit Km zu verschlüsselnden Daten sind in ISO 16844-3 festgelegt),
• übermitteln KmVU zum Einbau in die Fahrzeugeinheiten unter geeigneten Sicherheitsvorkehrungen an deren Hersteller,
• stellen sicher, dass KmWC bei der Personalisierung der Karten in alle Werkstattkarten eingefügt wird (Sensor InstallationSecData in Sensor_Installation_Data der Elementardatei).

3.1.4 Erzeugung und Verteilung von T-DES-Sitzungsschlüsseln

CSM_012 Im Rahmen des Prozesses der gegenseitigen Authentisierung erzeugen Fahrzeugeinheiten und Fahrtenschreiberkarten die erforderlichen Daten zur Erstellung eines gemeinsamen Triple-DES-Sitzungsschlüssels und tauschen diese Daten aus. Die Vertraulichkeit dieses Datenaustauschs wird durch einen RSA-Verschlüsselungsmechanismus geschützt.

CSM_013 Dieser Schlüssel wird für alle nachfolgenden kryptografischen Operationen unter Anwendung des Secure Messaging benutzt. Seine Gültigkeit erlischt am Ende der Sitzung (Entnahme oder Zurücksetzen der Karte) und/oder nach 240 Benutzungen (eine Benutzung des Schlüssels = ein mittels Secure Messaging an die Karte gesandter Befehl und die dazugehörige Antwort).

3.2. Schlüssel

CSM_014 RSA-Schlüssel haben (ungeachtet der Ebene) folgende Länge: Modulus n 1.024 Bit, öffentlicher Exponent e max. 64 Bit, privater Exponent d 1.024 Bit.

CSM_015 Triple-DES-Schlüssel haben die Form (K_a, K_b, K_a), wobei Ka und Kb unabhängige Schlüssel mit einer Länge von 64 Bit sind. Es wird kein Paritätsfehler-Erkennungsbit gesetzt.

3.3. Zertifikate

CSM_016 Bei den RSA-Public-Key-Zertifikaten muss es sich um Zertifikate entsprechend der Definition "non self descriptive" und "card verifiable" des Referenzdokuments ISO/IEC 7816-8 handeln.

3.3.1 Inhalt der Zertifikate

CSM_017 RSA-Public-Key-Zertifikate sind aus den folgenden Daten in folgender Reihenfolge aufgebaut:

Hinweise:

1. Mit dem Certificate Profile Identifier (Zertifikatsprofilbezeichner, CPI) wird die genaue Struktur eines Authentisierungszertifikats abgegrenzt. Er kann als interner Gerätebezeichner einer relevanten Kopfliste verwendet werden, die die Verkettung der Datenelemente innerhalb des Zertifikats beschreibt.

Die Kopfliste für diesen Zertifikatinhalt lautet wie folgt:

2."Certification Authority Reference" (Referenz der Zertifizierungsstelle, CAR) identifiziert die das Zertifikat ausstellende Zertifizierungsstelle, sodass das Datenelement gleichzeitig als Authority Key Identifier (Schlüsselbezeichner der Stelle) zur Angabe des öffentlichen Schlüssels der Zertifizierungsstelle verwendet werden kann (Kodierung siehe "Key Identifier").

3. Mit "Certificate Holder Authorisation" (Autorisierung des Zertifikatsinhabers, CHA) wird die Berechtigung des Zertifikatsinhabers ausgewiesen. Sie besteht aus der Kontrollgerätanwendungs-ID sowie aus der Art des Geräts, für das das Zertifikat bestimmt ist (entsprechend dem Datenelement Equipment Type, '00' für einen Mitgliedstaat).

4. "Certificate Holder Reference" (Referenz des Zertifikatsinhabers, CHR) dient der eindeutigen Identifizierung des Zertifikatsinhabers, sodass das Datenelement gleichzeitig als "Subject Key Identifier" (Schlüsselbezeichner des Subjekts) zur Angabe des öffentlichen Schlüssels des Zertifikatsinhabers verwendet werden kann.

5."KEY IDENTIFIERS" (Schlüsselbezeichner, KID) dienen der eindeutigen Identifizierung des Zertifikatsinhabers oder der Zertifizierungsstellen. Sie sind wie folgt kodiert:

5.1 Gerät (VU oder Karte):

Dem Hersteller einer VU ist die Kennung des Geräts, in das die Schlüssel eingefügt werden, bei der Beantragung von Zertifikaten unter Umständen nicht bekannt.

Ist dem Hersteller die Gerätekennung bekannt, sendet er sie mit dem öffentlichen Schlüssel zwecks Zertifizierung an die Zertifizierungsstelle seines Mitgliedstaats. Das Zertifikat enthält dann die Gerätekennung, und der Hersteller muss sicherstellen, dass Schlüssel und Zertifikat in das vorgesehene Gerät eingefügt werden. Der Key Identifier weist die oben genannte Form auf.

Ist dem Hersteller die Gerätekennung nicht bekannt, muss er jeden Antrag auf ein Zertifikat eindeutig kennzeichnen und diese Kennung zusammen mit dem öffentlichen Schlüssel zwecks Zertifizierung an die Zertifizierungsstelle seines Mitgliedstaates senden. Das Zertifikat enthält dann die Antragskennung. Nach dem Einfügen der Schlüssel in das Gerät muss der Hersteller der Zertifizierungsstelle die Zuordnung des Schlüssels zum Gerät mitteilen (d. h. Kennung des Zertifikatsantrags, Gerätekennung). Der Key Identifier (KID) hat folgende Form:

5.2 Zertifizierungsstelle:

Mit der Seriennummer Schlüssel werden die verschiedenen Schlüssel eines Mitgliedstaates unterschieden, sofern der Schlüssel verändert wird.

6. Den Zertifikatsprüfern ist implizit bekannt, dass es sich bei dem zertifizierten Schlüssel um einen für die Authentisierung, für die Verifizierung der digitalen Signatur und für die vertrauliche Chiffrierung relevanten RSA-Schlüssel handelt (das Zertifikat enthält keine Objektkennung zur entsprechenden Spezifizierung).

3.3.2 Ausgestellte Zertifikate

CSM_018 Das ausgestellte Zertifikat ist eine digitale Signatur mit teilweiser Wiederherstellung des Zertifikatsinhalts gemäß ISO/IEC 9796-2 (ausgenommen Anhang A4) mit angefügter "Certification Authority Reference".

Hinweise:

1. Dieses Zertifikat ist 194 Bytes lang.

2. Die von der Signatur verdeckte CAR wird ebenfalls an die Signatur angefügt, sodass der öffentliche Schlüssel der Zertifizierungsstelle zur Verifizierung des Zertifikats gewählt werden kann.

3. Dem Zertifikatsprüfer ist der von der Zertifizierungsstelle für die Unterzeichnung des Zertifikats verwendete Algorithmus implizit bekannt.

4. Die zu dem ausgestellten Zertifikat gehörende Kopfliste lautet wie folgt:

3.3.3 Verifizieren und Entpacken der Zertifikate

Das Verifizieren und Entpacken der Zertifikate besteht in der Verifizierung der Signatur entsprechend ISO/IEC 9796-2, wodurch der Zertifikatsinhalt und der enthaltene öffentliche Schlüssel aufgerufen werden: X.PK = X.CA.PK o X.C, sowie in der Verifizierung der Gültigkeit des Zertifikats.

CSM_019 Dazu gehören folgende Schritte:

Verifizierung der Signatur und Abrufen des Inhalts:

• von X.C Abruf von Sign, Cn' und CAR':

• von CAR' Auswahl des entsprechenden öffentlichen Schlüssels der Zertifizierungsstelle (wenn nicht bereits zuvor durch andere Mittel erfolgt),
• Öffnen von Sign mit öffentlichem CA-Schlüssel: Sr'= X.CA.PK [Sign],
• Prüfung Sr' startet mit '6A' und endet mit 'BC'
• Berechnung von Cr' und H' aus: Sr' =

• Wiederherstellung des Zertifikatsinhalts C' = Cr' || Cn',
• Prüfung Hash(C') = H'

Sind die Prüfungen positiv, ist das Zertifikat echt und sein Inhalt ist C'.

Verifizierung der Gültigkeit. Von C':

• Prüfung des Ablaufdatums der Gültigkeit, wenn zutreffend,

Abruf und Speicherung des öffentlichen Schlüssels, des Key Identifier, der Certificate Holder Authorisation und des Ablaufs der Gültigkeit des Zertifikats von C':

• X.PK = n || e
• X.KID = CHR
• X.CHA = CHA
• X.EOV = EOV

4. Gegenseitige Authentisierung

Die gegenseitige Authentisierung zwischen Karten und VU beruht auf dem folgenden Prinzip:

Jede Seite weist der Gegenseite nach, dass sie sich im Besitz eines gültigen Schlüsselpaares befindet, dessen öffentlicher Schlüssel von der Zertifizierungsstelle des jeweiligen Mitgliedstaates zertifiziert worden ist, die wiederum von der europäischen Zertifizierungsstelle zertifiziert wurde.

Der Nachweis wird geführt, indem mit dem privaten Schlüssel eine von der Gegenseite gesandte Zufallszahl signiert wird; die Gegenseite muss bei der Verifizierung dieser Signatur die Zufallszahl wiederherstellen können.

Der Mechanismus wird von der VU beim Einstecken der Karte ausgelöst. Er beginnt mit dem Austausch der Zertifikate und dem Entpacken der öffentlichen Schlüssel und endet mit der Erzeugung eines Sitzungsschlüssels.

CSM_020 Folgendes Protokoll findet Verwendung (Pfeile weisen auf Befehle und ausgetauschte Daten hin, siehe Anlage 2):

5. Vertraulichkeits-, Integritäts- und Authentisierungsmechanismen für die Datenübertragung VU-Karte

5.1. Secure Messaging

CSM_021 Die Integrität der Datenübertragung zwischen VU und Karte wird durch Secure Messaging entsprechend den Referenzdokumenten ISO/IEC 7816-4 und ISO/IEC 7816-8 geschützt.

CSM_022 Müssen Daten während der Übertragung geschützt werden, wird den innerhalb des Befehls oder der Antwort gesandten Datenobjekten ein Datenobjekt "Cryptographic Checksum" angefügt. Diese kryptografische Prüfsumme wird vom Empfänger verifiziert.

CSM_023 Die kryptografische Prüfsumme der innerhalb eines Befehls gesandten Daten integriert den Befehlskopf sowie alle gesandten Datenobjekte (=> CLA = '0C', und alle Datenobjekte sind mit Tags zu kapseln, bei denen b1=1).

CSM_024 Die Statusinformationsbytes der Antwort sind durch eine kryptografische Prüfsumme zu schützen, wenn die Antwort kein Datenfeld enthält.

CSM_025 Kryptografische Prüfsummen sind 4 Bytes lang.

Somit weisen Befehle und Antworten bei Anwendung von Secure Messaging folgende Struktur auf:

Die DO werden als Teilmenge der in ISO/IEC 7816-4 beschriebenen Secure-Messaging-DO verwendet:

Ausgehend von einem ungesicherten Befehl-Antwort-Paar:

lautet das entsprechende gesicherte Befehl-Antwort-Paar:

Gesicherter Befehl:

In die Prüfsumme zu integrierende Daten = CH || PB || T_PV || L_PV || PV || T_LE || L_LE || L_e || PB

PB = Padding Bytes (80 .. 00) gemäß ISO-IEC 7816-4 und ISO 9797, Methode 2.

Die PV und LE der DO sind nur vorhanden, wenn entsprechende Daten im ungesicherten Befehl vorliegen.

Gesicherte Antwort:

1. Wenn das Antwortdatenfeld nicht leer ist und nicht vertraulichkeitsgeschützt werden muss:

In die Prüfsumme zu integrierende Daten = T_PV || L_PV || PV || PB

2. Wenn das Antwortdatenfeld nicht leer ist und vertraulichkeitsgeschützt werden muss:

Daten in CG: nicht-BER-TLV-kodierte Daten und Füllbytes.

In die Prüfsumme zu integrierende Daten = T_{PI CG} || L_{PI CG} || PI CG || PB

3. Wenn das Antwortdatenfeld leer ist:

In die Prüfsumme zu integrierende Daten = T_SW || L_SW || SW || PB

5.2. Behandlung von Secure-Messaging-Fehlern

CSM_026 Erkennt die Fahrtenschreiberkarte beim Interpretieren eines Befehls einen SM-Fehler, müssen die Statusbytes ohne SM zurückgesandt werden. Laut ISO/IEC 7816-4 sind folgende Statusbytes zur Anzeige von SM-Fehlern definiert:

'66 88': Verifizierung der kryptografischen Prüfsumme fehlgeschlagen,

'69 87': erwartete SM-Datenobjekte fehlen,

'69 88': SM-Datenobjekte inkorrekt.

CSM_027 Sendet die Fahrtenschreiberkarte Statusbytes ohne SM-DO oder mit einem fehlerhaften SM-DO zurück, muss die VU den Vorgang abbrechen.

5.3. Algorithmus zur Berechnung der kryptografischen Prüfsummen

CSM_028 Kryptografische Prüfsummen werden unter Verwendung eines üblichen MAC gemäß ANSI X9.19 mit DES aufgebaut:

• Ausgangsstufe: Der Ausgangsprüfblock y0 ist E(Ka, SSC).
• Folgestufe: Unter Verwendung von Ka werden die Prüfblöcke y1, ..., yn berechnet.
• Endstufe: Die kryptografische Prüfsumme wird aus dem letzten Prüfblock yn wie folgt berechnet: E(Ka, D(Kb, yn)).

E() bedeutet Verschlüsselung mit DES, und D() bedeutet Entschlüsselung mit DES.

Die vier höchstwertigen Bytes der kryptografischen Prüfsumme werden übertragen.

CSM_029 Während der Schlüsselvereinbarung wird der "Send Sequence Counter" (Sendesequenzzähler, SSC) wie folgt initialisiert:

Anfangs-SSC: Rnd3 (4 niedrigstwertige Bytes) || Rnd1 (4 niedrigstwertige Bytes).

CSM_030 Vor jeder Berechnung eines MAC wird der SSC um 1 erhöht (d. h. der SSC für den ersten Befehl ist Anfangs-SSC + 1, der SSC für die erste Antwort Anfangs-SSC + 2).

Die folgende Abbildung zeigt die Berechnung des MAC:

5.4. Algorithmus zur Berechnung von Kryptogrammen für Vertraulichkeits-DOs

CSM_031 Kryptogramme werden mit TDEA im Modus TCBC entsprechend den Referenzdokumenten TDES und TDES-OP sowie mit dem Nullvektor als Initial Value-Block berechnet.

Die folgende Abbildung zeigt die Anwendung von Schlüsseln in T-DES:

6. Digitale Signaturmechanismen beim Herunterladen von Daten

CSM_032 Das Intelligent Dedicated Equipment (IDE) speichert die von einem Gerät (VU oder Karte) während eines Übertragungsvorgangs empfangenen Daten in einer Datei ab. Diese Datei muss die Zertifikate MSi.C und EQT.C enthalten. Die Datei enthält digitale Signaturen von Datenblöcken gemäß Anlage 7, Protokolle zum Herunterladen der Daten.

CSM_033 Für die digitalen Signaturen heruntergeladener Daten wird ein digitales Signatursystem mit Anhang verwendet, sodass die heruntergeladenen Daten auf Wunsch ohne Dechiffrierung lesbar sind.

6.1. Erzeugung der Signatur

CSM_034 Die Erzeugung der Datensignatur durch das Gerät folgt dem in Referenzdokument PKCS1 definierten digitalen Signatursystem mit Anhang und der Hash-Funktion SHA-1:

Signatur = EQT.SK['00' || '01' || PS || '00' || DER(SHA-1(Data))]

PS = Füllstring von Oktetten mit Wert 'FF', sodass die Länge 128 beträgt.

DER(SHA-1(M)) ist die Kodierung der Algorithmus-ID für die Hash-Funktion und den Hash-Wert in einen ASN.1-Wert des Typs Digest Info (Kodierungsregeln):

'30'||'21'||'30'||'09'||'06'||'05'||'2B'||'0E'||'03'||'02'||'1A'||'05'||'00'||'04'||'14'||Hash-Wert.

6.2. Verifizierung der Signatur

CSM_035 Die Verifizierung der Datensignatur bei heruntergeladenen Daten folgt dem in Referenzdokument PKCS1 definierten digitalen Signatursystem mit Anhang und der Hash-Funktion SHA-1.

Der europäische öffentliche Schlüssel EUR.PK muss dem Prüfer von unabhängiger Seite her (für ihn verlässlich) bekannt sein.

Die folgende Tabelle veranschaulicht das Protokoll, das von einem IDE mit Kontrollkarte zur Verifizierung der Integrität von heruntergeladenen und in ESM (externen Speichermedien) gespeicherten Daten herangezogen werden kann. Die Kontrollkarte wird zur Dechiffrierung digitaler Signaturen verwendet. Diese Funktion kann in diesem Fall nicht im IDE implementiert sein.

Das Gerät, das die zu analysierenden Daten heruntergeladen und signiert hat, ist mit EQT bezeichnet.

Teil B
Fahrtenschreibersystem der 2. Generation

7. Einleitung

7.1. Referenzdokumente

Referenzdokumente zu dieser Anlage:

7.2. Notationen und Abkürzungen

In dieser Anlage werden folgende Notationen und Abkürzungen verwendet:

7.3. Begriffsbestimmungen

Die in dieser Anlage verwendeten Begriffsbestimmungen sind in Anhang 1C Abschnitt I aufgeführt.

8. Kryptografische Systeme und Algorithmen

8.1. Kryptografische Systeme

CSM_38 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden ein auf elliptischen Kurven basierendes Public-Key-Verschlüsselungssystem, sodass folgende Sicherheitsmechanismen vorliegen:

• gegenseitige Authentisierung zwischen Fahrzeugeinheit und Karte,
• Vereinbarung von AES-Sitzungsschlüsseln zwischen Fahrzeugeinheit und Karte,
• Gewährleistung der Authentizität, Integrität und Nichtabstreitbarkeit der von Fahrzeugeinheiten oder Fahrtenschreiberkarten an externe Medien heruntergeladenen Daten.

CSM_39 Fahrzeugeinheiten und externe GNSS-Ausrüstung verwenden ein auf elliptischen Kurven basierendes Public-Key-Verschlüsselungssystem, sodass folgende Sicherheitsmechanismen vorliegen:

• Koppelung von Fahrzeugeinheit und externer GNSS-Ausrüstung,
• gegenseitige Authentisierung zwischen Fahrzeugeinheit und externer GNSS-Ausrüstung,
• Vereinbarung eines AES-Sitzungsschlüssels zwischen Fahrzeugeinheit und externer GNSS-Ausrüstung.

CSM_40 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden ein AES-basiertes symmetrisches Verschlüsselungssystem, sodass folgende Sicherheitsmechanismen vorliegen:

• Gewährleistung von Authentizität und Integrität der zwischen Fahrzeugeinheit und Fahrtenschreiberkarte ausgetauschten Daten,
• gegebenenfalls Gewährleistung der Vertraulichkeit der zwischen Fahrzeugeinheit und Fahrtenschreiberkarte ausgetauschten Daten.

CSM_41 Fahrzeugeinheiten und externe GNSS-Ausrüstung verwenden ein AES-basiertes symmetrisches Verschlüsselungssystem, sodass folgende Sicherheitsmechanismen vorliegen:

• Gewährleistung von Authentizität und Integrität der zwischen Fahrzeugeinheit und externer GNSS-Ausrüstung ausgetauschten Daten,

CSM_42 Fahrzeugeinheiten und Bewegungssensoren verwenden ein AES-basiertes symmetrisches Verschlüsselungssystem, sodass folgende Sicherheitsmechanismen vorliegen:

• Koppelung von Fahrzeugeinheit und Bewegungssensor,
• gegenseitige Authentisierung zwischen Fahrzeugeinheit und Bewegungssensor,
• Gewährleistung der Vertraulichkeit der zwischen Fahrzeugeinheit und Bewegungssensor ausgetauschten Daten.

CSM_43 Fahrzeugeinheiten und Kontrollkarten verwenden ein AES-basiertes symmetrisches Verschlüsselungssystem, sodass an der Schnittstelle für die Fernkommunikation folgende Sicherheitsmechanismen vorliegen:

• Gewährleistung von Vertraulichkeit, Authentizität und Integrität der von der Fahrzeugeinheit an die Kontrollkarte übermittelten Daten.

Hinweise:

• Genau genommen werden die Daten von einer Fahrzeugeinheit unter Aufsicht eines Kontrolleurs mithilfe einer VU-internen oder -externen Ausrüstung zur Fernkommunikation an die Fernabfrageeinrichtung übermittelt (siehe Anlage 14). Allerdings sendet die Fernabfrageeinrichtung die erhaltenen Daten zwecks Entschlüsselung und Validierung der Authentizität an eine Kontrollkarte. Im Hinblick auf die Sicherheit sind die Ausrüstung zur Fernkommunikation und die Fernabfrageeinrichtung vollständig transparent.
• Eine Werkstattkarte bietet die gleichen Sicherheitsmechanismen für die DSRC-Schnittstelle wie eine Kontrollkarte. Dadurch kann eine Werkstatt überprüfen, ob die Schnittstelle für die Fernkommunikation einer VU ordnungsgemäß funktioniert und sicher ist. Weitere Informationen siehe Abschnitt 9.2.2.

8.2. Kryptografische Algorithmen

8.2.1 Symmetrische Algorithmen

CSM_44 Fahrzeugeinheiten, Fahrtenschreiberkarten, Bewegungssensoren und externe GNSS-Ausrüstung unterstützen den in Referenzdokument AES definierten AES-Algorithmus, mit Schlüssellängen von 128, 192 und 256 Bits.

8.2.2 Asymmetrische Algorithmen und standardisierte Domänenparameter

CSM_45 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe GNSS-Ausrüstung unterstützen Elliptische-Kurven-Kryptografie mit einer Schlüsselgröße von 256, 384 und 512/521 Bits.

CSM_46 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe GNSS-Ausrüstung unterstützen den ECDSA Signaturalgorithmus gemäß Referenzdokument DSS.

CSM_47 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe GNSS-Ausrüstung unterstützen den ECKA-EG-Algorithmus zur Schlüsselvereinbarung gemäß Referenzdokument TR 03111.

CSM_48 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe GNSS-Ausrüstung unterstützen sämtliche standardisierte Domänenparameter gemäß Tabelle 1 unten für Elliptische-Kurven-Kryptografie.

Tabelle 1: Standardisierte Domänenparameter

Hinweis: Die in der letzten Spalte von Tabelle 1 genannten Objektkennungen sind in Referenzdokument RFC 5639 für Brainpool-Kurven und in Referenzdokument RFC 5480 für NIST-Kurven angegeben.

8.2.3 Hash-Algorithmen ¹⁸

CSM_49 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe GNSS-Ausrüstung unterstützen die Algorithmen SHA-256, SHA-384 und SHA-512 gemäß Referenzdokument SHS.

8.2.4 Cipher Suites

CSM_50 Wenn ein symmetrischer Algorithmus, ein asymmetrischer Algorithmus und/oder ein Hash-Algorithmus zusammen ein Sicherheitsprotokoll bilden, haben ihre jeweiligen Schlüssellängen und Hashgrößen (grob) die gleiche Stärke aufzuweisen. Tabelle 2 zeigt die zulässigen Cipher Suites:

Tabelle 2: Zulässige Cipher Suites

Hinweis: ECC-Schlüsselgrößen von 512 Bits und 521 Bits gelten im Sinne dieser Anlage als gleich stark.

9. Schlüssel und Zertifikate

9.1. Asymmetrische Schlüsselpaare und Public-Key-Zertifikate

9.1.1 Allgemein

Hinweis: Die in diesem Abschnitt beschriebenen Schlüssel werden zur gegenseitigen Authentisierung und zum Secure Messaging zwischen den Fahrzeugeinheiten und den Fahrtenschreiberkarten sowie zwischen den Fahrzeugeinheiten und externer GNSS-Ausrüstung verwendet. Diese Vorgänge werden detailliert in den Kapiteln 10 und 11 dieser Anlage beschrieben.

CSM_51 Beim europäischen intelligenten Fahrtenschreibersystem werden die ECC-Schlüsselpaare und die entsprechenden Zertifikate auf drei hierarchischen Funktionsebenen erzeugt und verwaltet:

• auf europäischer Ebene,
• auf Mitgliedstaatebene,
• auf Geräteebene.

CSM_52 Im gesamten europäischen intelligenten Fahrtenschreibersystem werden öffentliche und private Schlüssel sowie Zertifikate mithilfe genormter und sicherer Methoden erzeugt, verwaltet und kommuniziert.

9.1.2 Europäische Ebene ¹⁸

CSM_53 Auf europäischer Ebene wird ein einziges ECC-Schlüsselpaar (EUR) erzeugt. Es besteht aus einem privaten (EUR.SK) und einem öffentlichen Schlüssel (EUR.PK). Dieses Schlüsselpaar bildet das Wurzel-Schlüsselpaar der gesamten europäischen intelligenten Fahrtenschreiber-PKI. Diese Aufgabe wird von einer Europäischen Wurzel-Zertifizierungsstelle (ERCA) wahrgenommen, die der Europäischen Kommission untersteht.

CSM_54 Die ERCA verwendet den europäischen privaten Schlüssel, um ein (selbstsigniertes) Wurzelzertifikat des europäischen öffentlichen Schlüssels zu signieren, und übermittelt dieses europäische Wurzelzertifikat an alle Mitgliedstaaten.

CSM_55 Die ERCA verwendet den europäischen privaten Schlüssel, um auf Anfrage die Zertifikate der öffentlichen Schlüssel der Mitgliedstaaten zu signieren. Die ERCA führt ein Verzeichnis aller signierten Public-Key-Zertifikate der Mitgliedstaaten.

CSM_56 Wie in Abbildung 1 (Abschnitt 9.1.7) dargestellt, erzeugt die ERCA alle 17 Jahre ein neues europäisches Wurzel-Schlüsselpaar. Immer, wenn die ERCA ein neues europäisches Wurzel-Schlüsselpaar erzeugt, erstellt es ein neues selbstsigniertes Wurzelzertifikat für den neuen europäischen öffentlichen Schlüssel. Die Gültigkeitsdauer eines europäischen Wurzelzertifikats beträgt 34 Jahre und 3 Monate.

Hinweis: Die Einführung eines neuen Wurzel-Schlüsselpaares bedeutet auch, dass die ERCA einen neuen Bewegungssensor-Hauptschlüssel und einen neuen DSRC-Hauptschlüssel erzeugt, siehe Abschnitte 9.2.1.2 und 9.2.2.2.

CSM_57 Bevor ein neues europäisches Wurzel-Schlüsselpaar erzeugt wird, analysiert die ERCA die für das neue Schlüsselpaar erforderliche kryptografische Stärke, da dieses die kommenden 34 Jahre Sicherheit bieten soll. Wenn nötig, wechselt die ERCA zu einer Cipher Suite, die stärker als die aktuelle ist, wie in CSM_50 festgelegt.

CSM_58 Immer wenn die ERCA ein neues europäisches Wurzel-Schlüsselpaar erzeugt, muss es ein Linkzertifikat für den neuen europäischen öffentlichen Schlüssel erstellen und dieses mit dem ehemaligen privaten Schlüssel signieren. Die Gültigkeitsdauer des Linkzertifikats beträgt 17 Jahre und 3 Monate. Dies wird auch in Abbildung 1 (Abschnitt 9.1.7) gezeigt.

Hinweis: Da ein Linkzertifikat den öffentlichen Schlüssel der Generation X von ERCA enthält und mit dem privaten Schlüssel der Generation X-1 von ERCA signiert ist, bietet ein Linkzertifikat Ausrüstung, die im Laufe der Generation X-1 herausgegeben wurde, eine Möglichkeit, im Laufe der Generation X herausgegebener Ausrüstung zu vertrauen.

CSM_59 Die ERCA darf in keinem Fall den privaten Schlüssel eines Wurzel-Schlüsselpaares verwenden, sobald die neuen Wurzelzertifikate Gültigkeit erlangen.

CSM_60 Die ERCA muss jederzeit über folgende kryptografische Schlüssel und Zertifikate verfügen:

• das aktuelle EUR-Schlüsselpaar samt zugehörigem Zertifikat
• sämtliche vorherigen EUR-Vorgängerzertifikate, die zur Verifizierung noch gültiger MSCA-Zertifikate verwendet werden sollen
• Linkzertifikate aller Generationen von EUR-Linkzertifikaten mit Ausnahme des ersten

9.1.3 Mitgliedstaatebene

CSM_61 Auf Mitgliedstaatebene müssen alle Mitgliedstaaten, die zur Signierung von Fahrtenschreiberkartenzertifikaten verpflichtet sind, eines oder mehrere einzigartige ECC-Schlüsselpaare erzeugen, das mit MSCA_Card bezeichnet wird. Alle Mitgliedstaaten, die zur Signierung von Zertifikaten für Fahrzeugeinheiten oder externe GNSS-Ausrüstung verpflichtet sind, müssen zusätzlich eines oder mehrere einzigartige ECC-Schlüsselpaare erzeugen, das mit MSCA_VU-EGF bezeichnet wird.

CSM_62 Die Aufgabe, Mitgliedstaat-Schlüsselpaare zu erzeugen, wird durch eine Zertifizierungsstelle des jeweiligen Mitgliedstaates (Member State Certificate Authority, MSCA) übernommen. Immer, wenn eine MSCA ein Mitgliedstaat-Schlüsselpaar erzeugt, übermittelt sie den öffentlichen Schlüssel an die ERCA, um ein entsprechendes durch die ERCA signiertes Mitgliedstaatzertifikat zu erhalten.

CSM_63 Die MSCA wählt die Stärke eines Mitgliedstaat-Schlüsselpaars so, dass sie derjenigen des europäischen Wurzel-Schlüsselpaars entspricht, das zur Signierung des zugehörigen Mitgliedstaatzertifikats verwendet wird.

CSM_64 Ein gegebenenfalls vorhandenes MSCA_VU-EGF-Schlüsselpaar besteht aus dem privaten Schlüssel MSCA_VU-EGF.SK und dem öffentlichen Schlüssel MSCA_VU-EGF.PK. Eine MSCA darf den privaten Schlüssel MSCA_VU-EGF.SK ausschließlich dazu nutzen, die Public-Key-Zertifikate von Fahrzeugeinheiten und externer GNSS-Ausrüstung zu signieren.

CSM_65 Ein MSCA_Card-Schlüsselpaar besteht aus einem privaten (MSCA_Card.SK) und einem öffentlichen Schlüssel (MSCA_Card.PK). Eine MSCA darf den privaten Schlüssel MSCA_Card.SK ausschließlich dazu nutzen, die Public-Key-Zertifikate von Fahrtenschreiberkarten zu signieren.

CSM_66 Eine MSCA muss Aufzeichnungen über alle signierten VU-Zertifikate, externen GNSS-Ausrüstungs-Zertifikate und Kartenzertifikate sowie die Kennung der Geräte, für die jedes dieser Zertifikate bestimmt ist, aufbewahren.

CSM_67 Die Gültigkeitsdauer eines MSCA_VU-EGF-Zertifikats beträgt 17 Jahre und 3 Monate. Die Gültigkeitsdauer eines MSCA_Card-Zertifikats beträgt 7 Jahre und 1 Monat.

CSM_68 Wie in Abbildung 1 (Abschnitt 9.1.7) dargestellt, beträgt die Nutzungsdauer eines privaten Schlüssels eines MSCA_VU-EGF-Schlüsselpaares und eines privaten Schlüssels eines MSCA_Card-Schlüsselpaares zwei Jahre.

CSM_69 Das MSCA darf in keinem Fall den privaten Schlüssel eines MSCA_VU-EGF-Schlüsselpaares verwenden, sobald die Nutzungsdauer abgelaufen ist. Ebenso wenig darf das MSCA den privaten Schlüssel eines MSCA_Card-Schlüsselpaares verwenden, sobald die Nutzungsdauer abgelaufen ist.

CSM_70 Das MSCA muss jederzeit über folgende kryptografische Schlüssel und Zertifikate verfügen:

• das aktuelle MSCA_Card-Schlüsselpaar samt zugehörigem Zertifikat
• sämtliche vorherigen MSCA_Card-Vorgängerzertifikate, die zur Verifizierung noch gültiger Zertifikate für Fahrtenschreiberkarten verwendet werden sollen
• das für die Verifizierung des aktuellen MSCA-Zertifikats erforderliche aktuelle EUR-Zertifikat
• sämtliche vorherigen EUR-Vorgängerzertifikate, die zur Verifizierung noch gültiger MSCA-Zertifikate erforderlich sind

CSM_71 Wenn eine MSCA Zertifikate für Fahrzeugeinheiten oder externe GNSS-Ausrüstung signiert, muss sie zusätzlich über folgende Schlüssel und Zertifikate verfügen:

• das aktuelle MSCA_VU-EGF-Schlüsselpaar samt zugehörigem Zertifikat
• sämtliche vorherigen öffentlichen MSCA_VU-EGF-Schlüssel, die zur Verifizierung noch gültiger Zertifikate von VU oder externer GNSS-Ausrüstung verwendet werden sollen

9.1.4 Geräteebene: Fahrzeugeinheiten ¹⁸

CSM_72 Für jede Fahrzeugeinheit müssen zwei eindeutige ECC-Schlüsselpaare erzeugt werden, die als VU_MA und VU_Sign bezeichnet werden. Diese Aufgabe wird von den Herstellern der VU übernommen. Immer wenn ein VU-Schlüsselpaar erzeugt wird, übermittelt die erzeugende Partei den öffentlichen Schlüssel an ihre MSCA, um das entsprechende durch die MSCA signierte VU-Zertifikat zu erhalten. Der private Schlüssel darf nur durch die Fahrzeugeinheit genutzt werden.

CSM_73 Die Zertifikate VU_MA und VU_Sign jeder gegebenen Fahrzeugeinheit müssen das gleiche Certificate Effective Date aufweisen.

CSM_74 Der VU-Hersteller wählt die Stärke eines VU-Schlüsselpaars so, dass sie derjenigen des MSCA-Schlüsselpaars entspricht, das zur Signierung des zugehörigen VU-Zertifikats verwendet wird.

CSM_75 Fahrzeugeinheiten dürfen ihr aus dem privaten Schlüssel VU_MA.SK und dem öffentlichen Schlüssel VU_MA.PK bestehendes VU_MA-Schlüsselpaar ausschließlich dazu verwenden, die VU-Authentisierung gegenüber Fahrtenschreiberkarten und externer GNSS-Ausrüstung durchzuführen, wie in den Abschnitten 10.3 und 11.4 dieser Anlage beschrieben.

CSM_76 Fahrzeugeinheiten müssen in der Lage sein, flüchtige ECC-Schlüsselpaare, zu erzeugen und dürfen ein flüchtiges Schlüsselpaar ausschließlich dazu nutzen, eine Sitzungsschlüsselvereinbarung mit einer Fahrtenschreiberkarte oder externer GNSS-Ausrüstung durchzuführen, wie in den Abschnitten 10.4 und 11.4 dieser Anlage beschrieben.

CSM_77 Fahrzeugeinheiten nutzen den privaten Schlüssel VU_Sign.SK des VU_Sign-Schlüsselpaars ausschließlich dazu, heruntergeladene Datendateien zu signieren, wie in Kapitel 14 dieser Anlage beschrieben. Der zugehörige öffentliche Schlüssel VU_Sign.PK darf nur dazu genutzt werden, Signaturen, die durch die Fahrzeugeinheit erzeugt wurden, zu verifizieren.

CSM_78 Wie in Abbildung 1 (Abschnitt 9.1.7) dargestellt, beträgt die Gültigkeitsdauer eines VU_MA-Zertifikats 15 Jahre und 3 Monate. Die Gültigkeitsdauer eines VU_Sign-Zertifikats beträgt ebenfalls 15 Jahre und 3 Monate.

Hinweise:

• Die erweiterte Gültigkeitsdauer eines VU_Sign-Zertifikats ermöglicht es einer Fahrzeugeinheit, während der ersten drei Monate nach Ablauf gültige Signaturen für heruntergeladene Daten zu erzeugen, wie in der Verordnung (EU) Nr. 581/2010 vorgeschrieben.
• Die erweiterte Gültigkeitsdauer eines VU_MA-Zertifikats ist erforderlich, um der VU die Authentisierung gegenüber einer Kontroll- oder Unternehmenskarte während der ersten drei Monate nach Ablauf zu ermöglichen, sodass es möglich ist, Daten herunterzuladen.

CSM_79 Nach Ablauf der Gültigkeitsdauer des entsprechenden Zertifikats darf die Fahrzeugeinheit den privaten Schlüssel eines VU-Schlüsselpaars keinesfalls verwenden.

CSM_80 Die VU-Schlüsselpaare (mit Ausnahme flüchtiger Schlüsselpaare) und zugehörigen Zertifikate einer gegebenen Fahrzeugeinheit dürfen nicht bei der Praxisanwendung ausgetauscht oder erneuert werden, sobald das Fahrzeug in Betrieb genommen wurde.

Hinweise:

• Flüchtige Schlüsselpaare sind nicht Teil dieser Anforderung, da eine VU jedes Mal, wenn eine Chip-Authentisierung und eine Sitzungsschlüsselvereinbarung durchgeführt werden, ein neues flüchtiges Schlüsselpaar erzeugt (siehe Abschnitt 10.4). Die flüchtigen Schlüsselpaare verfügen nicht über zugehörige Zertifikate.
• Diese Anforderung verbietet nicht die Möglichkeit, im Rahmen einer Modernisierung oder Reparatur in einer sicheren, vom VU-Hersteller kontrollierten Umgebung statische VU-Schlüsselpaare zu ersetzen.

CSM_81 Im Betrieb müssen die Fahrzeugeinheiten die folgenden kryptografischen Schlüssel und Zertifikate enthalten:

• den privaten VU_MA-Schlüssel samt zugehörigem Zertifikat
• den privaten VU_Sign-Schlüssel samt zugehörigem Zertifikat
• das MSCA_VU-EGF-Zertifikat mit dem öffentlichen MSCA_VU-EGF.PK-Schlüssel zur Verifizierung des VU_MA-Zertifikats und des VU_Sign-Zertifikats
• das EUR-Zertifikat mit dem öffentlichen EUR.PK-Schlüssel zur Verifizierung des MSCA_VU-EGF-Zertifikats
• das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der Gültigkeitsdauer des zur Verifizierung des MSCA_VU-EGF-Zertifikats zu verwendenden EUR-Zertifikats vorausgeht, falls vorhanden
• das Linkzertifikat, das diese beiden EUR-Zertifikate verbindet, sofern vorhanden

CSM_82 Über die in CSM_81 aufgeführten kryptografischen Schlüssel und Zertifikate hinaus müssen die Fahrzeugeinheiten zudem die in Teil A dieser Anlage aufgeführten Schlüssel und Zertifikate enthalten, damit eine Fahrzeugeinheit mit Fahrtenschreiberkarten der 1. Generation interagieren kann.

9.1.5 Geräteebene: Fahrtenschreiberkarten ¹⁸

CSM_83 Für jede Fahrtenschreiberkarte wird ein eindeutiges ECC-Schlüsselpaar unter dem Namen Card_MA erzeugt. Zusätzlich wird für jede Fahrerkarte und jede Werkstattkarte ein zweites eindeutiges ECC-Schlüsselpaar unter dem Namen Card_Sign erzeugt. Diese Aufgabe kann von den Kartenherstellern oder -integratoren übernommen werden. Immer wenn ein Kartenschlüsselpaar erzeugt wird, übermittelt die erzeugende Partei den öffentlichen Schlüssel an ihre MSCA, um das entsprechende durch die MSCA signierte Kartenzertifikat zu erhalten. Der private Schlüssel darf nur durch die Fahrtenschreiberkarte genutzt werden.

CSM_84 Die Zertifikate Card_MA und Card_Sign jeder gegebenen Fahrer- oder Werkstattkarte müssen das gleiche Certificate Effective Date aufweisen.

CSM_85 Der Kartenhersteller oder -integrator wählt die Stärke eines Kartenschlüsselpaars so, dass sie derjenigen des MSCA-Schlüsselpaars entspricht, das zur Signierung des zugehörigen Kartenzertifikats verwendet wird.

CSM_86 Fahrtenschreiberkarten dürfen ihr aus dem privaten Schlüssel Card_MA.SK und dem öffentlichen Schlüssel Card_MA.PK bestehendes Card_MA-Schlüsselpaar ausschließlich dazu verwenden, die gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung gegenüber Fahrzeugeinheiten durchzuführen, wie in den Abschnitten 10.3 und 10.4 dieser Anlage beschrieben.

CSM_87 Fahrer- oder Werkstattkarten nutzen den privaten Schlüssel Card_Sign.SK des Card_Sign-Schlüsselpaars ausschließlich dazu, heruntergeladene Datendateien zu signieren, wie in Kapitel 14 dieser Anlage beschrieben. Der zugehörige öffentliche Schlüssel Card_Sign.PK darf nur dazu genutzt werden, Signaturen, die durch die Karte erzeugt wurden, zu verifizieren.

CSM_88 Die Gültigkeitsdauer des Card-MA-Zertifikats beträgt für

• Fahrerkarten: 5 Jahre
• Unternehmenskarten: 5 Jahre
• Kontrollkarten: 2 Jahre
• Werkstattkarten: 1 Jahr

CSM_89 Die Gültigkeitsdauer des Card-Sign-Zertifikats lautet wie folgt:

• Fahrerkarten: 5 Jahre und 1 Monat
• Werkstattkarten: 1 Jahr und 1 Monat

Hinweis: Die erweiterte Gültigkeitsdauer eines Card_Sign-Zertifikats ermöglicht es einer Fahrerkarte, während des ersten Monats nach Ablauf gültige Signaturen für heruntergeladene Daten zu erzeugen. Dies ist aufgrund der Verordnung (EU) Nr. 581/2010 erforderlich, nach der das Herunterladen von Daten einer Fahrerkarte bis 28 Tage nach Aufzeichnung der letzten Tage möglich sein muss.

CSM_90 Die Schlüsselpaare und entsprechenden Zertifikate einer Fahrtenschreiberkarte dürfen nicht mehr ersetzt oder erneuert werden, sobald die Karte ausgegeben ist.

CSM_91 Nach der Ausgabe müssen die Fahrtenschreiberkarten die folgenden kryptografischen Schlüssel und Zertifikate enthalten:

• den privaten Card_MA-Schlüssel samt zugehörigem Zertifikat
• Zusätzlich für Fahrerkarten und Werkstattkarten: der private Card_Sign-Schlüssel und das entsprechende Zertifikat
• das MSCA_Card-Zertifikat mit dem öffentlichen MSCA_Card.PK-Schlüssel zur Verifizierung des Card_MA-Zertifikats und des Card_Sign-Zertifikats
• das EUR-Zertifikat mit dem öffentlichen EUR.PK-Schlüssel zur Verifizierung des MSCA_Card-Zertifikats
• das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der Gültigkeitsdauer des zur Verifizierung des MSCA_Card-Zertifikats zu verwendenden EUR-Zertifikats vorausgeht, falls vorhanden
• das Linkzertifikat, das diese beiden EUR-Zertifikate verbindet, sofern vorhanden.
• Zusätzlich für Kontrollkarten, Unternehmenskarten und Werkstattkarten und nur, wenn solche Karten in den ersten drei Monaten der Gültigkeitsdauer eines neuen EUR-Zertifikats ausgestellt werden: das EUR-Zertifikat, das zwei Generationen älter ist, falls vorhanden.

Hinweis zum letzten Gedankenstrich: Beispielsweise müssen die genannten Karten in den ersten drei Monaten der Gültigkeit des ERCA(3)-Zertifikats (siehe Abbildung 1) das ERCA(1)-Zertifikat enthalten. Dies ist erforderlich, damit diese Karten für den Datendownload von ERCA(1)-Fahrzeugeinheiten verwendet werden können, deren normale Gültigkeitsdauer von 15 Jahren zuzüglich der drei Monate für das Herunterladen von Daten in diesen Monaten abläuft (siehe Anhang IC Randnummer 13 letzter Gedankenstrich).

CSM_92 Über die in CSM_91 aufgeführten kryptografischen Schlüssel und Zertifikate hinaus müssen die Fahrtenschreiberkarten zudem die in Teil A dieser Anlage aufgeführten Schlüssel und Zertifikate enthalten, damit diese Karten mit Fahrzeugeinheiten der 1. Generation interagieren können.

9.1.6 Geräteebene: Externe GNSS-Ausrüstung ¹⁸

CSM_93 Für jede externe GNSS-Ausrüstung wird ein eindeutiges ECC-Schlüsselpaar unter dem Namen EGF_MA erzeugt. Diese Aufgabe wird von den Herstellern der externen GNSS-Ausrüstung übernommen. Immer wenn ein EGF-MA-Schlüsselpaar erzeugt wird, übermittelt die erzeugende Partei den öffentlichen Schlüssel an ihre MSCA, um das entsprechende durch die MSCA signierte EGF-MA-Schlüsselpaar zu erhalten. Der private Schlüssel darf nur durch die externe GNSS-Ausrüstung genutzt werden.

CSM_94 Der EGF-Hersteller wählt die Stärke eines EGF_MA-Schlüsselpaars so, dass sie derjenigen des MSCA-Schlüsselpaars entspricht, das zur Signierung des zugehörigen EGF-MA-Zertifikats verwendet wird.

CSM_95 Externe GNSS-Ausrüstung darf ihr aus dem privaten Schlüssel EGF_MA.SK und dem öffentlichen Schlüssel EGF_MA.PK bestehendes EGF_MA-Schlüsselpaar ausschließlich dazu verwenden, die gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung gegenüber Fahrzeugeinheiten durchzuführen, wie in Abschnitt 11.4 dieser Anlage beschrieben.

CSM_96 Die Gültigkeitsdauer des EGF_MA-Zertifikats beträgt 15 Jahre.

CSM_97 Eine externe GNSS-Ausrüstung darf den privaten Schlüssel ihres EGF_MA Schlüsselpaars nicht zur Koppelung mit einer Fahrzeugeinheit verwenden, wenn das entsprechende Zertifikat abgelaufen ist.

Hinweis: Wie in Abschnitt 11.3.3 erläutert, kann eine externe GNSS-Ausrüstung ihren privaten Schlüssel möglicherweise auch nach Ablauf des entsprechenden Zertifikats gegenüber der VU verwenden, mit der sie bereits gekoppelt ist.

CSM_98 EGF_MA-Schlüsselpaar und zugehöriges Zertifikat einer gegebenen externen GNSS-Ausrüstung dürfen nicht bei der Praxisanwendung ausgetauscht oder erneuert werden, sobald die EGF in Betrieb genommen wurde.

Hinweis: Diese Anforderung verbietet nicht die Möglichkeit, im Rahmen einer Modernisierung oder Reparatur in einer sicheren, vom EGF-Hersteller kontrollierten Umgebung EGF-Schlüsselpaare zu ersetzen.

CSM_99 Im Betrieb muss eine externe GNSS-Ausrüstung die folgenden kryptografischen Schlüssel und Zertifikate enthalten:

• den privaten EGF_MA-Schlüssel samt zugehörigem Zertifikat
• das MSCA_VU-EGF-Zertifikat mit dem öffentlichen MSCA_VU-EGF.PK-Schlüssel zur Verifizierung des EGF_MA-Zertifikats
• das EUR-Zertifikat mit dem öffentlichen EUR.PK-Schlüssel zur Verifizierung des MSCA_VU-EGF-Zertifikats
• das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der Gültigkeitsdauer des zur Verifizierung des MSCA_VU-EGF-Zertifikats zu verwendenden EUR-Zertifikats vorausgeht, falls vorhanden
• das Linkzertifikat, das diese beiden EUR-Zertifikate verbindet, sofern vorhanden

9.1.7 Überblick Ersatz von Zertifikaten ¹⁸

In der untenstehenden Abbildung 1 ist dargestellt, wie die verschiedenen Generationen von ERCA-Wurzelzertifikaten, ERCA-Linkzertifikaten, MSCA-Zertifikaten und Ausrüstungszertifikaten (VU und Karte) im Laufe der Zeit ausgegeben und genutzt werden:

Abbildung 1 Ausgabe und Nutzung der verschiedenen Generationen von ERCA-Wurzelzertifikaten, ERCA-Linkzertifikaten, MSCA-Zertifikaten und Ausrüstungszertifikaten

Hinweise zu Abbildung 1:

1. Unterschiedliche Generationen des Wurzelzertifikats werden durch eine Zahl in Klammern dargestellt. Beispiel: ERCA (1) gibt die erste Generation des ERCA-Wurzelzertifikats an; ERCA (2) die zweite Generation usw.
2. Sonstige Zertifikate sind durch zwei Zahlen in Klammern dargestellt, wobei die erste Zahl die Generation des Wurzelzertifikats angibt, unter dem sie ausgestellt wurden, und die zweite Zahl die Generation des jeweiligen Zertifikats selbst. MSCA_Card (1-1) ist beispielsweise das erste unter ERCA (1) ausgestellte MSCA_Card-Zertifikat; MSCA_Card (2-1) ist das erste unter ERCA ausgestellte MSCA_Card-Zertifikat (2); MSCA_Card (2-last) ist das letzte unter ERCA (2) ausgestellte MSCA_Card-Zertifikat; Card_MA(2-1) ist das erste unter ERCA (2) ausgestellte Kartenzertifikat für die gegenseitige Authentisierung usw.
3. Die Zertifikate MSCA_Card (2-1) und MSCA_Card (1-last) werden fast, aber nicht exakt am selben Tag ausgestellt. MSCA_Card (2-1) ist das erste unter ERCA (2) ausgestellte MSCA_Card-Zertifikat und wird ein wenig später ausgestellt als MSCA_Card (1-last), dem letzten MSCA_Card-Zertifikat unter ERCA (1).
4. Wie in der Abbildung dargestellt, werden die ersten unter ERCA (2) ausgestellten VU- und Kartenzertifikate fast zwei Jahre, bevor die letzten VU- und Kartenzertifikate unter ERCA (1) ausgegeben werden, verfügbar sein. Grund dafür ist, dass VU- und Kartenzertifikate nicht direkt unter dem ERCA-Zertifikat, sondern unter einem MSCA-Zertifikat ausgestellt werden. Das MSCA (2-1) Zertifikat wird direkt nach Gültigkeitsbeginn von ERCA (2) ausgegeben; das Zertifikat MSCA (1-last) wird hingegen unmittelbar davor ausgestellt, im letzten Moment, zu dem das Zertifikat ERCA (1) noch gültig ist. Aus diesem Grund haben diese beiden MSCA-Zertifikate fast die gleiche Gültigkeitsdauer, gehören aber zu verschiedenen Generationen.
5. Die für Karten angegebene Gültigkeitsdauer entspricht derjenigen von Fahrerkarten (5 Jahre).
6. Aus Platzgründen ist die unterschiedliche Gültigkeitsdauer der Zertifikate Card_MA und Card_Sign nur für die 1. Generation angegeben.

9.2. Symmetrische Schlüssel

9.2.1 Schlüssel für die Sicherung der Kommunikation VU-Bewegungssensor

9.2.1.1 Allgemein ¹⁸

Hinweis: In diesem Abschnitt wird die Kenntnis des Inhalts von Referenzdokument ISO 16844-3 vorausgesetzt, in dem die Schnittstelle zwischen Fahrzeugeinheit und Bewegungssensor erläutert wird. Die Koppelung zwischen einer VU und einem Bewegungssensor wird in Kapitel 12 dieser Anlage detailliert beschrieben.

CSM_100 Eine Reihe symmetrischer Schlüssel wird zur Koppelung von Fahrzeugeinheiten und Bewegungssensoren, zur gegenseitigen Authentisierung zwischen Fahrzeugeinheiten und Bewegungssensoren sowie zur Verschlüsselung der Kommunikation zwischen Fahrzeugeinheiten und Bewegungssensoren benötigt (siehe Tabelle 3). Bei diesen Schlüsseln muss es sich stets um AES-Schlüssel handeln, deren Schlüssellänge derjenigen des Bewegungssensor-Hauptschlüssels entspricht, die wiederum an die Länge des (vorgesehenen) europäischen Wurzelschlüsselpaars angepasst ist (siehe CSM_50).

Tabelle 3: Schlüssel für die Sicherung der Kommunikation VU-Bewegungssensor

CSM_101 Die Europäische Wurzel-Zertifizierungsstelle (ERCA) generiert K_M-VU und K_M-WC, zwei zufällig erzeugte und eindeutige AES-Schlüssel, aus denen sich der Bewegungssensor-Hauptschlüssel K_M als K_M-VU XOR K_M-WC berechnen lässt. Die ERCA teilt den Zertifizierungsstellen der Mitgliedstaaten die Schlüssel K_M, K_M-VU und K_M-WC auf Anfrage mit.

CSM_102 Die ERCA weist jedem Bewegungssensor-Hauptschlüssel K_M eine eindeutige Versionsnummer zu, die auch für die zugrunde liegenden Schlüssel K_M-VU und K_M-WC und für den zugehörigen Identifikationsschlüssel K_ID gilt. Wenn die ERCA den MSCA die Schlüssel K_M-VU und K_M-WC übermittelt, informiert sie diese über die Versionsnummer.

Hinweis: Mithilfe der Versionsnummer können die verschiedenen Generationen dieser Schlüssel unterschieden werden; dies ist in Abschnitt 9.2.1.2 detailliert erläutert.

CSM_103 Die Zertifizierungsstelle des jeweiligen Mitgliedstaates leitet den Schlüssel K_M-VU samt Versionsnummer an die VU-Hersteller auf deren Anfrage weiter. Die VU-Hersteller setzen den Schlüssel K_M-VU samt Versionsnummer in allen hergestellten VU ein.

CSM_104 Die Zertifizierungsstelle des Mitgliedstaates stellt sicher, dass der Schlüssel K_M-WC samt Versionsnummer in jede Werkstattkarte eingefügt wird, die unter ihrer Verantwortung ausgegeben wird.

Hinweise:

• Siehe die Beschreibung des Datentyps Sensor InstallationSecData in Anlage 2.
• Wie in Abschnitt 9.2.1.2 erläutert, müssen in eine einzelne Werkstattkarte mehrere Generationen von K_M-WC eingesetzt werden.

CSM_105 Über den in CSM_104 angegebenen AES-Schlüssel hinaus muss die MSCA sicherstellen, dass der unter Randnummer CSM_037 in Teil A dieser Anlage angegebene T-DES-Schlüssel Km_WC in jede Werkstattkarte eingesetzt wird, die unter ihrer Verantwortung ausgegeben wird.

Hinweise:

• Dadurch kann eine Werkstattkarte der 2. Generation zur Koppelung einer VU der 1. Generation verwendet werden.
• Eine Werkstattkarte der 2. Generation umfasst zwei verschiedene Anwendungen: Eine entspricht Teil B dieser Anlage, die andere Teil A. Die Letztgenannte enthält den T-DES-Schlüssel Km_WC.

CSM_106 Eine an der Ausgabe von Bewegungssensoren beteiligte MSCA leitet den Identifikationsschlüssel per XOR-Berechnung mit einem konstanten Vektor CV vom Bewegungssensor-Hauptschlüssel ab. Der Wert von CV lautet wie folgt:

• Für 128-Bit-Bewegungssensor-Hauptschlüssel: CV = 'B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83'
• Für 192-Bit-Bewegungssensor-Hauptschlüssel: CV = '72 AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25'
• Für 256-Bit-Bewegungssensor-Hauptschlüssel: CV = '1D 74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63 AD 60'

Hinweis: Die konstanten Vektoren sind wie folgt zu berechnen:

Pi_10 = die ersten 10 Bytes des Dezimalteils der mathematischen Konstante π = '24 3F 6 A 88 85 A3 08 D3 13 19'

CV_128-bits = erste 16 Bytes von SHA-256(Pi_10)

CV_192-bits = erste 24 Bytes von SHA-384(Pi_10)

CV_256-bits = erste 32 Bytes von SHA-512(Pi_10)

CSM_107 Die Hersteller von Bewegungssensoren generieren für jeden Bewegungssensor einen zufälligen, eindeutigen Koppelungsschlüssel K_P und senden jeden einzelnen Koppelungsschlüssel an die Zertifizierungsstelle des Mitgliedstaates. Die MSCA verschlüsselt jeden Koppelungsschlüssel einzeln mit dem Bewegungssensor-Hauptschlüssel K_M und übermittelt den kodierten Schlüssel zurück an den Hersteller des Bewegungssensors. Für jeden kodierten Schlüssel informiert die MSCA den Hersteller von Bewegungssensoren über die Versionsnummer des zugehörigen K_M.

Hinweis: Wie in Abschnitt 9.2.1.2 erläutert, muss ein Hersteller von Bewegungssensoren für einen einzelnen Bewegungssensor unter Umständen mehrere eindeutige Koppelungsschlüssel generieren.

CSM_108 Die Hersteller von Bewegungssensoren generieren für jeden Bewegungssensor eine eindeutige Seriennummer und senden sämtliche Seriennummern an die Zertifizierungsstelle des Mitgliedstaates. Die MSCA verschlüsselt jede Seriennummer einzeln mit dem Identifikationsschlüssel K_ID und übermittelt die kodierte Seriennummer zurück an den Hersteller des Bewegungssensors. Für jede kodierte Seriennummer informiert die MSCA den Hersteller von Bewegungssensoren über die Versionsnummer des zugehörigen K_ID.

CSM_109 Bezüglich der Randnummern CSM_107 und CSM_108 muss die MSCA den AES-Algorithmus im Modus Cipher Block Chaining gemäß Referenzdokument ISO 10116, mit einem Verschachtelungsparameter m = 1 und einem Initialisierungsvektor SV = '00'{16}, d. h. sechzehn Bytes mit dem Binärwert 0, verwenden. Falls erforderlich, muss die MSCA die Auffüllmethode 2 gemäß Referenzdokument ISO 9797-1 verwenden.

CSM_110 Der Hersteller von Bewegungssensoren speichert den kodierten Koppelungsschlüssel und die kodierte Seriennummer im vorgesehenen Bewegungssensor, zusammen mit den entsprechenden Klartextwerten und der Versionsnummer der zur Verschlüsselung verwendeten K_M und K_ID.

Hinweis: Wie in Abschnitt 9.2.1.2 erläutert, muss ein Hersteller von Bewegungssensoren für einen einzelnen Bewegungssensor unter Umständen mehrere kodierte Koppelungsschlüssel und mehrere kodierte Seriennummern einfügen.

CSM_111 Über die in CSM_110 erläuterten AES-basierten kryptografischen Elemente hinaus kann der Hersteller von Bewegungssensoren in jedem Bewegungssensor auch die in Teil A dieser Anlage, Randnummer CSM_037, genannten T-DES-basierten kryptografischen Elemente speichern.

Hinweis: Dadurch kann ein Bewegungssensor der 2. Generation mit einer VU der 1. Generation gekoppelt werden.

CSM_112 Die Länge des während der Koppelung mit einem Bewegungssensor von einer VU generierten Sitzungsschlüssels K_S muss derjenigen seines K_M-VU entsprechen (siehe CSM_50).

9.2.1.2 Austausch des Bewegungssensor-Hauptschlüssels bei Geräten der zweiten Generation

CSM_113 Sämtliche Bewegungssensor-Hauptschlüssel und alle zugehörigen Schlüssel (siehe Tabelle 3) sind einer bestimmten Generation des ERCA-Wurzelschlüsselpaars zugeordnet. Diese Schlüssel müssen deshalb alle 17 Jahre ersetzt werden. Die Gültigkeitsdauer jeder Generation von Bewegungssensor-Hauptschlüsseln beginnt ein Jahr, bevor das zugehörige ERCA-Wurzel-Schlüsselpaar gültig wird, und endet, wenn das zugehörige ERCA-Wurzel-Schlüsselpaar ausläuft. Dies ist in Abbildung 2 dargestellt.

Abbildung 2 Ausstellung und Verwendung verschiedener Generationen von Bewegungssensor-Hauptschlüsseln in Fahrzeugeinheiten, Bewegungssensoren und Werkstattkarten

CSM_114 Mindestens ein Jahr, bevor ein neues European Wurzel-Schlüsselpaar erstellt wird (siehe CSM_56), erstellt die ERCA K_M durch Generierung neuer K_M-VU und K_M-WC einen neuen Bewegungssensor-Hauptschlüssel. Die Länge des Bewegungssensor-Hauptschlüssels muss der vorgesehenen Stärke des neuen europäischen Wurzel-Schlüsselpaars gemäß CSM_50 entsprechen. Die ERCA teilt den MSCA auf Anfrage die neuen K_M, K_M-VU und K_M-WC samt Versionsnummer mit.

CSM_115 Die MSCA stellt sicher, dass alle gültigen Generationen von K_M-WC in jeder unter ihrer Verantwortung ausgegebenen Werkstattkarte samt ihren Versionsnummern gespeichert werden (siehe Abbildung 2).

Hinweis: Dies hat zur Folge, dass im letzten Jahr der Gültigkeitsdauer eines ERCA-Zertifikats Werkstattkarten mit drei verschiedenen Generationen von K_M-WC ausgegeben werden (siehe Abbildung 2).

CSM_116 Bezüglich des unter CSM_107 und CSM_108 oben genannten Verfahrens: Die MSCA kodiert jeden Koppelungsschlüssel K_P, den sie von einem Hersteller von Bewegungssensoren erhält, separat mit jeder gültigen Generation des Bewegungssensor-Hauptschlüssels K_M. Weiterhin kodiert die MSCA jede Seriennummer, die sie von einem Hersteller von Bewegungssensoren erhält, separat mit jeder gültigen Generation des Identifizierungsschlüssels K_ID. Der Hersteller von Bewegungssensoren speichert sämtliche Kodierungen des Koppelungsschlüssels sowie sämtliche Kodierungen der Seriennummern im vorgesehenen Bewegungssensor, zusammen mit den entsprechenden Klartextwerten und der Versionsnummer der zur Verschlüsselung verwendeten K_M und K_ID.

Hinweis: Dies hat zur Folge, dass im letzten Jahr der Gültigkeitsdauer eines ERCA-Zertifikats Bewegungssensoren mit kodierten Daten ausgegeben werden, die auf drei verschiedenen K_M-Generationen basieren (siehe Abbildung 2).

CSM_117 Bezüglich des unter CSM_107 oben genannten Verfahrens: Da die Länge des Koppelungsschlüssels K_P an der Länge von K_M auszurichten ist (siehe CSM_100), muss ein Hersteller von Bewegungssensoren für einen Bewegungssensor unter Umständen bis zu drei verschiedene Koppelungsschlüssel (unterschiedlicher Länge) für den Fall generieren, dass nachfolgende K_M-Generationen unterschiedliche Längen aufweisen. In einem solchen Fall sendet der Hersteller sämtliche Koppelungsschlüssel an die MSCA. Die MSCA stellt sicher, dass jeder Koppelungsschlüssel mit der richtigen Generation des Bewegungssensor-Hauptschlüssels kodiert ist, also derjenigen gleicher Länge.

Hinweis: Wenn der Hersteller von Bewegungssensoren entscheidet, einen T-DES-basierten Koppelungsschlüssel für einen Bewegungssensor der 2. Generation zu generieren (siehe CSM_111), muss der Hersteller die MSCA darauf hinweisen, dass der T-DES-basierte Bewegungssensor-Hauptschlüssel zur Dekodierung dieses Koppelungsschlüssels verwendet werden muss. Grund dafür ist, dass die Länge eines T-DES-Schlüssels mit derjenigen eines AES-Schlüssels identisch sein kann; die MSCA kann die Unterscheidung deshalb nicht alleine anhand der Schlüssellänge treffen.

CSM_118 Die VU-Hersteller dürfen in jede Fahrzeugeinheit nur eine K_M-VU-Generation samt Versionsnummer einsetzen. Diese K_M-VU-Generation ist an das ERCA-Zertifikat zu binden, auf dem die Zertifikate der VU basieren.

Anmerkungen:

• Eine Fahrzeugeinheit, die auf dem ERCA-Zertifikat der Generation X basiert, darf nur den K_M-VU der Generation X enthalten, selbst wenn dieser erst nach Beginn der Gültigkeitsdauer des ERCA-Zertifikats der Generation X+1 ausgestellt wurde. Dies ist in Abbildung 2 dargestellt.
• Eine VU der Generation X kann nicht mit einem Bewegungssensor der Generation X-1 gekoppelt werden.
• Da Werkstattkarten eine Gültigkeitsdauer von einem Jahr aufweisen, bewirken CSM_113 - CSM_118, dass alle Werkstattkarten dann, wenn der neue K_M-VU ausgegeben werden wird, den neuen K_M-WC enthalten werden. Somit wird eine solche VU immer in der Lage sein, den neuen K_M zu berechnen. Zudem werden dann die meisten neuen Bewegungssensoren ebenfalls kodierte Daten enthalten, die auf dem neuen K_M beruhen.

9.2.2 Schlüssel zur Sicherung der DSRC-Kommunikation

9.2.2.1 Allgemein ¹⁸

CSM_119 Die Authentizität und Vertraulichkeit der von einer Fahrzeugeinheit per DSRC-Fernkommunikationskanal an eine Kontrollbehörde übermittelten Daten kann mithilfe einer Reihe VU-spezifischer AES-Schlüssel sichergestellt werden, die von einem einzigen DSRC-Hauptschlüssel, KM_DSRC, abgeleitet sind.

CSM_120 Beim DSRC-Hauptschlüssel KM_DSRC muss es sich um einen AES-Schlüssel handeln, der von der ERCA sicher generiert, gespeichert und verteilt wird. Die Schlüssellänge kann 128, 192 oder 256 Bits betragen und orientiert sich an der Länge des europäischen Wurzel-Schlüsselpaars (siehe CSM_50).

CSM_121 Die ERCA übermittelt auf Anfrage den Zertifizierungsstellen der Mitgliedstaaten den DSRC-Hauptschlüssel in sicherer Form, damit diese Stellen VU-spezifische DSRC-Schlüssel ableiten und somit sicherstellen können, dass der DSRC-Hauptschlüssel in alle unter ihrer Verantwortung ausgegebenen Kontrollkarten und Werkstattkarten eingesetzt ist.

CSM_122 Die ERCA weist jedem DSRC-Hauptschlüssel eine eindeutige Versionsnummer zu. Wenn die ERCA den MSCA den DSRC-Hauptschlüssel übermittelt, informiert sie diese über die Versionsnummer.

Hinweis: Mithilfe der Versionsnummer können die verschiedenen Generationen des DSRC-Hauptschlüssels unterschieden werden; dies ist in Abschnitt 9.2.2.2 detailliert erläutert.

CSM_123 Für jede Fahrzeugeinheit erstellt der Hersteller der Fahrzeugeinheit eine eindeutige VU-Seriennummer und sendet diese an die Zertifizierungsstelle des Mitgliedstaates, um eine Gruppe von zwei VU-spezifischen DSRC-Schlüsseln zu beantragen. Die VU-Seriennummer verfügt über den Datentyp VuSerialNumber.

Hinweis:

• Die VU-Seriennummer muss mit dem Element 'vuSerialNumber' von VuIdentification (siehe Anlage 1) und mit der Certificate Holder Reference in den Zertifikaten der VU übereinstimmen.
• Die VU-Seriennummer ist zu dem Zeitpunkt, zu dem der Hersteller einer Fahrzeugeinheit die VU-spezifischen DSRC-Schlüssel beantragt, unter Umständen nicht bekannt. In diesem Fall sendet der Hersteller der VU stattdessen die bei der Beantragung der VU-Zertifikate verwendete eindeutige Kennung für den Zertifikatsantrag (siehe CSM_153). Diese Kennung des Zertifikatsantrags muss deshalb mit der Certificate Holder Reference in den Zertifikaten der VU übereinstimmen.

CSM_124 Nach Erhalt des Antrags auf VU-spezifische DSRC-Schlüssel leitet die MSCA für die Fahrzeugeinheit zwei AES-Schlüssel namens K_VU_DSRC_ENC und K_VU_DSRC_MAC ab. Diese VU-spezifischen Schlüssel sind genauso lang wie der DSRC-Hauptschlüssel. Die MSCA verwendet die in Referenzdokument RFC 5869 definierte Schlüsselableitungsfunktion. Die zum Instanzieren der HMAC-Hashfunktion erforderliche Hashfunktion ist an der Länge des DSRC-Hauptschlüssels auszurichten (siehe CSM_50). Die in RFC 5869 dargelegte Schlüsselableitungsfunktion ist wie folgt zu verwenden:

Schritt 1 (Extrahieren):

• PRK = HMAC-Hash (salt, IKM) wobei salt einen leeren String '' darstellt und IKM KMDSRC entspricht

Schritt 2 (Expandieren):

• OKM = T(1), wobei

  T(1) = HMAC-Hash (PRK, T(0) || info || '01') mit

  • T(0) = leerer String ('')
  • info = VU-Seriennummer oder Kennung des Zertifikatsantrags gemäß CSM_123
• K_VU_DSRC_ENC = erste L-Oktette von OKM und

  K_VU_DSRC_MAC = letzte L-Oktette von OKM;

  dabei ist L die erforderliche Länge von K_VU_DSRC_ENC und K_VU_DSRC_MAC in Oktetten.

CSM_125 Die MSCA verteilt K_VU_DSRC_ENC und K_VU_DSRC_MAC in sicherer Form an die VU-Hersteller, damit diese sie in die vorgesehene Fahrzeugeinheit einsetzen.

CSM_126 Bei der Ausgabe müssen im geschützten Speicher einer Fahrzeugeinheit K_VU_DSRC_ENC und K_VU_DSRC_MAC abgelegt sein, um die Integrität, Authentizität und Vertraulichkeit der über den Fernkommunikationskanal gesendeten Daten gewährleisten zu können. Außerdem muss in einer Fahrzeugeinheit die Versionsnummer des zum Ableitung dieser VU-spezifischen Schlüssel verwendeten DSRC-Hauptschlüssels gespeichert sein.

CSM_127 Bei der Ausgabe muss im geschützten Speicher von Kontrollkarten und Werkstattkarten KMDSRC abgelegt sein, um die Integrität und Authentizität der von einer VU über den Fernkommunikationskanal gesendeten Daten zu überprüfen und diese Daten zu entschlüsseln. Auch in den Kontrollkarten und Werkstattkarten muss die Versionsnummer des DSRC-Hauptschlüssels abgelegt sein.

Hinweis: Wie in Abschnitt 9.2.2.2 erläutert, müssen unter Umständen in eine einzelne Werkstatt- oder Kontrollkarte mehrere Generationen von K_MDSRC eingesetzt werden.

CSM_128 Die MSCA muss Aufzeichnungen aller von ihr erzeugten VU-spezifischen DSRC-Schlüssel samt Versionsnummer und der zu ihrer Ableitung verwendeten VU-Seriennummer oder Kennung des Zertifikatsantrags führen.

9.2.2.2 Austausch des DSRC-Hauptschlüssels

CSM_129 Sämtliche DSRC-Hauptschlüssel sind einer bestimmten Generation des ERCA-Wurzelschlüsselpaars zugeordnet. Die ERCA tauscht den DSRC-Hauptschlüssel deshalb alle 17 Jahre aus. Die Gültigkeitsdauer jeder Generation von DSRC-Hauptschlüsseln beginnt zwei Jahre, bevor das zugehörige ERCA-Wurzel-Schlüsselpaar gültig wird, und endet, wenn das zugehörige ERCA-Wurzel-Schlüsselpaar ausläuft. Dies ist in Abbildung 3 dargestellt.

Abbildung 3 Ausstellung und Verwendung verschiedener Generationen von DSRC-Hauptschlüsseln in Fahrzeugeinheiten, Werkstatt- und Kontrollkarten

CSM_130 Spätestens zwei Jahre vor dem Erstellen eines neuen europäischen Wurzel-Schlüsselpaars (siehe CSM_56) erstellt die ERCA einen neuen DSRC-Hauptschlüssel. Die Länge des DSRC-Hauptschlüssels muss der vorgesehenen Stärke des neuen europäischen Wurzel-Schlüsselpaars gemäß CSM_50 entsprechen. Die ERCA teilt den MSCA auf Anfrage den neuen DSRC-Hauptschlüssel samt Versionsnummer mit.

CSM_131 Die MSCA stellt sicher, dass alle gültigen Generationen von K_MDSRC in jeder unter ihrer Verantwortung ausgegebenen Kontrollkarte samt Versionsnummern gespeichert werden (siehe Abbildung 3).

Hinweis: Dies hat zur Folge, dass in den letzten beiden Jahren der Gültigkeitsdauer eines ERCA-Zertifikats Kontrollkarten mit drei verschiedenen Generationen von K_MDSRC ausgegeben werden (siehe Abbildung 3).

CSM_132 Die MSCA stellt sicher, dass alle Generationen von K_MDSRC, die seit mindestens einem Jahr und auch noch weiter gültig sind, in jeder unter ihrer Verantwortung ausgegebenen Werkstattkarte samt ihren Versionsnummern gespeichert werden (siehe Abbildung 3).

Hinweis: Dies hat zur Folge, dass im letzten Jahr der Gültigkeitsdauer eines ERCA-Zertifikats Werkstattkarten mit drei verschiedenen Generationen von K_MDSRC ausgegeben werden (siehe Abbildung 3).

CSM_133 Die VU-Hersteller dürfen in jede Fahrzeugeinheit nur eine Gruppe VU-spezifischer DSRC-Schlüssel samt Versionsnummer einsetzen. Diese Schlüsselgruppe ist von der K_MDSRC-Generation abzuleiten, die an das ERCA-Zertifikat gebunden ist, auf dem die Zertifikate der VU basieren.

Hinweise:

• Dies bedeutet, dass eine Fahrzeugeinheit, die auf dem ERCA-Zertifikat der Generation X basiert, nur die K_VU_ENC und K_VU_DSRC_MAC der Generation enthalten darf, selbst wenn die VU erst nach Beginn der Gültigkeitsdauer des ERCA-Zertifikats der Generation X+1 ausgestellt wurde. Dies ist in Abbildung 3 dargestellt.
• Da Werkstattkarten eine Gültigkeitsdauer von einem Jahr und Kontrollkarten eine Gültigkeitsdauer von zwei Jahren aufweisen, bewirken CSM_131 - CSM_133, dass alle Werkstatt- und Kontrollkarten dann, wenn die erste VU mit VU-spezifischen Schlüsseln auf Grundlage dieses Hauptschlüssels ausgegeben werden wird, den neuen DSRC-Hauptschlüssel enthalten werden.

9.3. Zertifikate

9.3.1 Allgemein ¹⁸

CSM_134 Bei allen Zertifikaten im europäischen intelligenten Fahrtenschreibersystem muss es sich um selbstbeschreibende, kartenverifizierbare (CV) Zertifikate gemäß ISO 7816-4 und ISO 7816-8 handeln.

CSM_135 Zur Kodierung der Datenobjekte innerhalb der Zertifikate sind die Distinguished Encoding Rules (DER) gemäß ISO 8825-1 zu verwenden. Tabelle 4 zeigt die vollständige Kodierung der Zertifikate, einschließlich aller Tags und Längenbytes.

Hinweis: Diese Kodierung bewirkt folgende TLV-Struktur (Tag-Length-Value, Tag-Längen-Wert):

Tag: Der Tag ist in ein oder zwei Oktette verschlüsselt und gibt den Inhalt an.

Länge: Die Länge ist als unsignierte Ganzzahl in ein, zwei oder drei Oktette verschlüsselt, was zu einer Länge von maximal 65.535 Oktetten führt. Es ist die Mindestzahl an Oktetten zu verwenden.

Wert: Der Wert ist in null oder mehr Oktette verschlüsselt.

9.3.2 Zertifikatsinhalt

CSM_136 Alle Zertifikate weisen die Struktur des Zertifikatprofils in Tabelle 4 auf.

Tabelle 4: Zertifikatprofil Version 1

Feld	Feldkennung	Tag	Länge (Bytes)	ASN.1-Datentyp (siehe Anlage 1)
ECC-Zertifikat	C	'7F 21'	var
ECC Certificate Body	B	'7F 4E'	var
Certificate Profile Identifier	CPI	'5F 29'	'01'
Certificate Authority Reference	CAR	'42'	'08'
Certificate Holder Authorisation	CHA	'5F 4C'	'07'
Public Key	PK	'7F 49'	var
Domain Parameters	DP	'06'	var
Public Point	PP	'86'	var
Certificate Holder Reference	CHR	'5F 20'	'08'
Certificate Effective Date	CEfD	'5F 25'	'04'
Certificate Expiration Date	CExD	'5F 24'	'04'
ECC Certificate Signature	S	'5F 37'	var

Hinweis: Mit der Feldkennung werden in späteren Abschnitten dieser Anlage einzelne Felder eines Zertifikats angegeben - X.CAR ist beispielsweise die im Zertifikat von Benutzer X angegebene Certificate Authority Reference.

9.3.2.1 Certificate Profile Identifier

CSM_137 Die Zertifikate müssen mit einem Certificate Profile Identifier das verwendete Zertifikatprofil angeben. Version 1 (siehe Tabelle 4) ist durch einen Wert von '00' anzugeben.

9.3.2.2. Certificate Authority Reference

CSM_138 Mit der Certificate Authority Reference wird der öffentliche Schlüssel angegeben, mit dem die Zertifikatsignatur verifiziert wird. Die Certificate Authority Reference muss deshalb mit der Certificate Holder Reference im Zertifikat der entsprechenden Zertifizierungsstelle übereinstimmen.

CSM_139 Ein ERCA-Wurzelzertifikat muss selbstsigniert sein, d. h. Certificate Authority Reference und Certificate Holder Reference im Zertifikat müssen übereinstimmen.

CSM_140 Bei einem ERCA-Linkzertifikat muss die Certificate Holder Reference der CHR des neuen ERCA-Wurzelzertifikats entsprechen. Die Certificate Holder Reference eines Linkzertifikats muss der CHR des vorherigen ERCA-Wurzelzertifikats entsprechen.

9.3.2.3 Certificate Holder Authorisation ¹⁸

CSM_141 Mit 'Certificate Holder Authorisation' wird die Zertifikatart angegeben. Sie besteht aus den sechs höchstwertigen Bytes der Fahrtenschreiberanwendungs-ID, verkettet mit dem Gerätetyp, der die Art des Geräts angibt, für die das Zertifikat vorgesehen ist. Bei VU-Zertifikaten, Fahrerkarten- oder Werkstattkartenzertifikaten wird der Gerätetyp auch verwendet, um zwischen einem Zertifikat für die gegenseitige Authentisierung und einem Zertifikat für die Erzeugung digitaler Signaturen zu unterscheiden (siehe Abschnitt 9.1 und Anlage 1, Datentyp EquipmentType).

9.3.2.4. Public Key

Public Key verschachtelt zwei Datenelemente: den mit dem öffentlichen Schlüssel im Zertifikat zu verwendenden standardisierten Domänenparameter und den Wert des öffentlichen Punktes.

CSM_142 Das Datenelement Domain Parameters muss eine der in Tabelle 1 angegebenen Objektkennungen enthalten, um auf eine Gruppe standardisierter Domänenparameter zu verweisen.

CSM_143 Das Datenelement Public Point enthält den öffentlichen Punkt. Öffentliche Punkte auf elliptischen Kurven sind gemäß TR-03111 in Oktettstrings umzuwandeln. Dabei ist das unkomprimierte Verschlüsselungsformat zu verwenden. Beim Wiederherstellen eines Punktes auf einer elliptischen Kurve aus seinem verschlüsselten Format sind stets die in TR-03111 genannten Validierungen durchzuführen.

9.3.2.5 Certificate Holder Reference (Referenz des Zertifikatinhabers) ¹⁸

CSM_144 Certificate Holder Reference ist eine Kennung für den im Zertifikat angegebenen öffentlichen Schlüssel. Mit dieser Kennung wird in anderen Zertifikaten auf diesen öffentlichen Schlüssel verwiesen.

CSM_145 Bei Kartenzertifikaten und Zertifikaten externer GNSS-Ausrüstung muss Certificate Holder Reference den in Anlage 1 angegebenen Datentyp ExtendedSerialNumber aufweisen.

CSM_146 Bei Fahrzeugeinheiten ist dem Hersteller bei der Beantragung eines Zertifikats die herstellerspezifische Seriennummer der VU, für die das Zertifikat und der zugehörige private Schlüssel vorgesehen sind, unter Umständen nicht bekannt. Wenn sie ihm bekannt ist, muss Certificate Holder Reference den in Anlage 1 angegebenen Datentyp ExtendedSerialNumber aufweisen. Wenn sie ihm nicht bekannt ist, muss Certificate Holder Reference den in Anlage 1 angegebenen Datentyp CertificateRequestID aufweisen.

Hinweis: Bei Kartenzertifikaten muss der Wert der CHR dem Wert von 'cardExtendedSerialNumber' in EF_ICC entsprechen (siehe Anlage 2). Bei EGF-Zertifikaten muss der Wert der CHR dem Wert von 'sensorGNSSSerialNumber' in EF_ICC entsprechen (siehe Anlage 14). Bei VU-Zertifikaten muss der Wert der CHR dem Element "vuSerialNumber" von 'VuIdentification' entsprechen (siehe Anlage 1), es sei denn, dem Hersteller ist die herstellerspezifische Seriennummer zum Zeitpunkt der Beantragung des Zertifikats nicht bekannt.

CSM_147 Bei ERCA- und MSCA-Zertifikaten muss Certificate Holder Reference den in Anlage 1 angegebenen Datentyp CertificationAuthorityKID Certification AuthorityKID aufweisen.

9.3.2.6 Certificate Effective Date ¹⁸

CSM_148 Certificate Effective Date gibt Anfangsdatum und -uhrzeit der Gültigkeitsdauer des Zertifikats an.

9.3.2.7. Certificate Expiration Date

CSM_149 Certificate Expiration Date gibt Enddatum und -uhrzeit der Gültigkeitsdauer des Zertifikats an.

9.3.2.8 Certificate Signature

CSM_150 Die Signatur des Zertifikats wird anhand des kodierten Zertifikatkörpers erstellt, einschließlich Tag und Länge des Zertifikatkörpers. Als Signaturalgorithmus wird ECDSA gemäß DSS verwendet; dabei ist der an die Schlüsselgröße der signierenden Stelle gebundene Hash-Algorithmus zu verwenden (siehe CSM_50). Das Signaturformat ist Klartext, wie in TR-03111 angegeben.

9.3.3 Beantragen von Zertifikaten ¹⁸

CSM_151 Beim Beantragen eines Zertifikats muss die MSCA der ERCA die folgenden Daten übermitteln:

• den Certificate Profile Identifier des beantragten Zertifikats
• die Certificate Authority Reference, die zum Signieren des Zertifikats voraussichtlich verwendet werden soll
• den zu signierenden Public Key

CSM_152 Über die in CSM_151 genannten Angaben hinaus muss die MSCA der ERCA in einem Zertifikatsantrag die folgenden Daten übermitteln, damit Letztgenannte die Certificate Holder Reference des neuen MSCA-Zertifikats erstellen kann:

• den numerischen Landescode der Zertifizierungsstelle (der in Anlage 1 definierte Datentyp NationNumeric)
• den alphanumerischen Landescode der Zertifizierungsstelle (der in Anlage 1 definierte Datentyp NationAlpha)
• die 1-Byte-Seriennummer zur Unterscheidung der verschiedenen Schlüssel der Zertifizierungsstelle für den Fall des Wechsels von Schlüsseln
• das 2-Byte-Feld mit weiteren Informationen zur Zertifizierungsstelle

CSM_153 Der Gerätehersteller muss der MSCA in einem Zertifikatsantrag die folgenden Daten übermitteln, damit Letztgenannte die Certificate Holder Reference des neuen Gerätezertifikats erstellen kann:

• falls bekannt (siehe CSM_154), die Seriennummer des Geräts zur eindeutigen Identifizierung von Hersteller, Gerätetyp und Herstellungsmonat. Andernfalls eine eindeutige Kennung für den Zertifikatsantrag.
• Monat und Jahr der Geräteherstellung oder des Zertifikatsantrags.

Der Hersteller muss sicherstellen, dass diese Angaben richtig sind und dass das von der MSCA übermittelte Zertifikat in die vorgesehene Ausrüstung eingesetzt wird.

CSM_154 Bei Fahrzeugeinheiten ist dem Hersteller bei der Beantragung eines Zertifikats die herstellerspezifische Seriennummer der VU, für die das Zertifikat und der zugehörige private Schlüssel vorgesehen sind, unter Umständen nicht bekannt. Wenn bekannt, übermittelt der VU-Hersteller die Seriennummer der MSCA. Wenn nicht bekannt, kennzeichnet der Hersteller jeden Zertifikatsantrag eindeutig und übermittelt diese Seriennummer der MSCA. Das ausgestellte Zertifikat enthält dann die Seriennummer des Zertifikatsantrags. Sobald das Zertifikat in eine bestimmte VU eingesetzt ist, übermittelt der Hersteller der MSCA den Zusammenhang zwischen der Seriennummer des Zertifikatsantrags und der VU-Kennung.

10. Gegenseitige Authentisierung VU-Karte und Secure Messaging

10.1. Allgemein

CSM_155 Generell wird die sichere Kommunikation zwischen Fahrzeugeinheit und Fahrtenschreiberkarte durch die folgenden Schritte gewährleistet:

• Im ersten Schritt zeigt jede Partei der jeweils anderen, dass sie über ein gültiges Public-Key-Zertifikat verfügt, signiert durch die Zertifizierungsstelle des Mitgliedstaats. Das Public-Key-Zertifikat der MSCA wiederum muss durch die Europäische Wurzel-Zertifizierungsstelle signiert sein. Dieser Schritt, die Verifizierung der Zertifikatkette, wird in Abschnitt 10.2 detailliert erläutert.
• Im zweiten Schritt weist die Fahrzeugeinheit der Karte nach, dass sie über den privaten Schlüssel verfügt, der dem öffentlichen Schlüssel im vorgelegten Zertifikat entspricht. Dazu signiert sie eine von der Karte übermittelte Zufallszahl. Die Karte verifiziert die Signatur anhand der Zufallszahl. Wenn diese Verifizierung erfolgreich verläuft, ist die VU authentisiert. Dieser Schritt, die VU-Authentisierung, wird in Abschnitt 10.3 detailliert erläutert.
• Im dritten Schritt berechnen beide Parteien unabhängig voneinander mithilfe eines asymmetrischen Algorithmus zur Schlüsselvereinbarung zwei AES-Sitzungsschlüssel. Mit einem dieser Sitzungsschlüssel erstellt die Karte anhand einiger von der Karte gesendeter Daten einen Code für die Nachrichtenauthentisierung (MAC). Die VU verifiziert den MAC. Wenn diese Verifizierung erfolgreich verläuft, ist die Karte authentisiert. Dieser Schritt, die Kartenauthentisierung, wird in Abschnitt 10.4 detailliert erläutert.
• Im vierten Schritt gewährleisten VU und Karte mithilfe der vereinbarten Sitzungsschlüssel die Vertraulichkeit, Integrität und Authentizität aller ausgetauschten Nachrichten. Dieser Schritt namens Secure Messaging wird in Abschnitt 10.5 detailliert erläutert.

CSM_156 Der in CSM_155 beschriebene Mechanismus wird von der Fahrzeugeinheit ausgelöst, sobald in einen ihrer Steckplätze eine Karte eingesetzt wird.

10.2. Gegenseitige Verifizierung der Zertifikatkette

10.2.1 Verifizierung der Kartenzertifikatkette durch die VU ¹⁸

CSM_157 Die Fahrzeugeinheiten verifizieren mithilfe des in Abbildung 4 dargestellten Protokolls die Zertifikatkette einer Fahrtenschreiberkarte. Bei jedem aus der Karte ausgelesenem Zertifikat überprüft die VU die Richtigkeit des Feldes Certificate Holder Authorisation (CHA):

• Im Feld CHA des Kartenzertifikats muss ein Kartenzertifikat für die gegenseitige Authentisierung angegeben sein (siehe Anlage 1, Datentyp EquipmentType).
• In der CHA des Card.CA-Zertifikats muss eine MSCA angegeben sein.
• In der CHA des Card.Link-Zertifikats muss die ERCA angegeben sein.

Hinweise zu Abbildung 4:

• Bei den in der Abbildung erwähnten Kartenzertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur gegenseitigen Authentisierung. In Abschnitt 9.1.5 werden sie als Card_MA bezeichnet.
• Bei den in der Abbildung erwähnten Card.CA-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur Signierung der Kartenzertifikate, die in der CAR des Card-Zertifikats angegeben sind. In Abschnitt 9.1.3 werden sie als MSCA_Card bezeichnet.
• Bei dem in der Abbildung erwähnten Card.CA.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des Card.CA-Zertifikats angegeben ist.
• Das in der Abbildung erwähnte Card.Link-Zertifikat ist das Linkzertifikat der Karte, sofern vorhanden. Wie in Abschnitt 9.1.2 angegeben, handelt es sich hierbei um ein Linkzertifikat für ein neues europäisches Wurzel-Schlüsselpaar, das durch die ERCA erstellt und mithilfe des zuvor erwähnten europäischen privaten Schlüssels signiert wird.
• Bei dem Card.Link.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des Card.Link-Zertifikats angegeben ist.

CSM_158 Wie in Abbildung 4 dargestellt, beginnt beim Einsetzen der Karte die Verifizierung ihrer Zertifikatkette. Die Fahrzeugeinheit liest aus der EF-ECC die Kennung des Karteninhabers (cardExtendedSerialNumber) aus. Die VU muss überprüfen, ob sie die Karte kennt - ob sie also in der Vergangenheit die Zertifikatkette der Karte erfolgreich überprüft und zur späteren Referenz abgelegt hat. Wenn dies der Fall und das Zertifikat der Karte weiterhin gültig ist, wird nun die Zertifikatkette der VU verifiziert. Andernfalls muss die VU das MSCA_Card-Zertifikat zur Verifizierung des Kartenzertifikats, das Card.CA.EUR-Zertifikat zur Verifizierung des MSCA_Card-Zertifikats und eventuell das Linkzertifikat nacheinander aus der Karte auslesen, bis sie auf ein bekanntes Zertifikat stößt. Wenn sie ein solches Zertifikat findet, verifiziert die VU mit diesem die zugrunde liegenden Kartenzertifikate, die sie der Karte entnommen hat. Wenn diese Überprüfung erfolgreich verläuft, wird nun die Zertifikatkette der VU verifiziert. Andernfalls ignoriert die VU die Karte.

Hinweis: Der VU kann das Card.CA.EUR-Zertifikat auf drei Arten bekannt sein:

• es handelt sich um das gleiche Zertifikat wie das EUR-Zertifikat der VU selbst;
• das Card.EUR-Zertifikat ist ein Vorgänger des EUR-Zertifikats der VU und die VU enthielt dieses Zertifikat bereits ab Ausgabe (siehe CSM_81);
• das Card.CA.EUR-Zertifikat ist ein Nachfolger des EUR-Zertifikat der VU und die VU hat in der Vergangenheit von einer anderen Fahrtenschreiberkarte ein Linkzertifikat erhalten, verifiziert und zur zukünftigen Referenz abgespeichert.

CSM_159 Wie in Abbildung 4 angegeben, kann die VU, sobald sie die Authentizität und Gültigkeit eines zuvor unbekannten Zertifikats überprüft hat, dieses Zertifikat zur zukünftigen Referenz abspeichern. Sie braucht dann die Authentizität dieses Zertifikats nicht ein weiteres Mal zu prüfen, wenn es ihr erneut vorgelegt wird. Die VU braucht nicht das gesamte Zertifikat zu speichern, sondern lediglich den Inhalt des Zertifikatkörpers (siehe Abschnitt 9.3.2). Während die Speicherung aller anderen Arten von Zertifikaten optional ist, muss ein von einer Karte vorgelegtes neues Linkzertifikat von der VU gespeichert werden.

CSM_160 Die VU überprüft die temporäre Gültigkeit aller Zertifikate, die sie aus der Karte ausliest oder gespeichert hat, und lehnt abgelaufene Zertifikate ab. Die VU überprüft die temporäre Gültigkeit eines von einer Karte vorgelegten Zertifikats mithilfe ihrer Systemuhr.

Abbildung 4 Protokoll zur Verifizierung der Kartenzertifikatkette durch die VU

10.2.2 Verifizierung der VU-Zertifikatkette durch die Karte ¹⁸

CSM_161 Die Fahrtenschreiberkarten verifizieren mithilfe des in Abbildung 5 dargestellten Protokolls die Zertifikatkette einer VU. Bei jedem von der VU vorgelegtem Zertifikat überprüft die Karte die Richtigkeit des Feldes Certificate Holder Authorisation (CHA):

• In der CHA des VU.Link-Zertifikats muss die ERCA angegeben sein.
• In der CHA des VU.CA-Zertifikats muss eine MSCA angegeben sein.
• Im Feld CHA des VU-Zertifikats muss ein VU-Zertifikat für die gegenseitige Authentisierung angegeben sein (siehe Anlage 1, Datentyp EquipmentType).

Abbildung 5 Protokoll zur Verifizierung der VU-Zertifikatkette durch Card

Hinweise zu Abbildung 5:

• Bei den in der Abbildung erwähnten VU-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur gegenseitigen Authentisierung. In Abschnitt 9.1.4 werden sie als VU_MA bezeichnet.
• Bei den in der Abbildung erwähnten VU.CA-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur Signierung der Zertifikate von VU und externer GNSS-Ausrüstung. In Abschnitt 9.1.3 werden sie als MSCA_VU-EGF bezeichnet.
• Bei dem in der Abbildung erwähnten VU.CA.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des VU.CA-Zertifikats angegeben ist.
• Das in der Abbildung erwähnte VU.Link-Zertifikat ist das Linkzertifikat der VU, sofern vorhanden. Wie in Abschnitt 9.1.2 angegeben, handelt es sich hierbei um ein Linkzertifikat für ein neues europäisches Wurzel-Schlüsselpaar, das durch die ERCA erstellt und mithilfe des zuvor erwähnten europäischen privaten Schlüssels signiert wird.
• Bei dem VU.Link.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des VU.Link-Zertifikats angegeben ist.

CSM_162 Wie in Abbildung 5 dargestellt, versucht die Fahrzeugeinheit bei der Verifizierung der Zertifikatkette der Fahrzeugeinheit zunächst, ihren eigenen öffentlichen Schlüssel zur Verwendung in der Fahrtenschreiberkarte anzugeben. Wenn dies erfolgreich verläuft, bedeutet dies, dass die Karte zu einem früheren Zeitpunkt die Zertifikatkette der VU erfolgreich verifiziert und das VU-Zertifikat zur späteren Referenz abgelegt hat. In einem solchen Fall wird das VU-Zertifikat verwendet, und es schließt sich die VU-Authentisierung an. Wenn der Karte das VU-Zertifikat nicht bekannt ist, präsentiert die VU nacheinander das VU.CA-Zertifikat zur Verifizierung ihres VU-Zertifikats, das VU.CA.EUR-Zertifikat zur Verifizierung ihres VU.CA-Zertifikats und eventuell das Linkzertifikat, um festzustellen, ob die Karte eines dieser Zertifikate kennt oder verifizieren kann. Wenn sie ein solches Zertifikat findet, verifiziert die Karte mit diesem die ihr präsentierten zugrunde liegenden VU-Zertifikate. Im Erfolgsfall legt die VU schließlich ihren öffentlichen Schlüssel zur Verwendung in der Fahrtenschreiberkarte fest. Andernfalls ignoriert die VU die Karte.

Hinweis: Der VU kann das VU.CA.EUR-Zertifikat auf drei Arten bekannt sein:

• es handelt sich um das gleiche Zertifikat wie das EUR-Zertifikat der Karte selbst;
• das VU.CA.EUR-Zertifikat ist ein Vorgänger des EUR-Zertifikats der Karte und die Karte enthielt dieses Zertifikat bereits ab Ausgabe (siehe CSM_91);
• das VU.CA.EUR-Zertifikat ist ein Nachfolger des EUR-Zertifikat der Karte und die Karte hat in der Vergangenheit von einer anderen Fahrzeugeinheit ein Linkzertifikat erhalten, verifiziert und zur zukünftigen Referenz abgespeichert.

CSM_163 Die VU legt mithilfe des Befehls MSE: Set AT ihren öffentlichen Schlüssel zur Verwendung in der Fahrtenschreiberkarte fest. Wie in Anlage 2 erläutert, gibt dieser Befehl das kryptografische Verfahren an, das zusammen mit dem festgelegten Schlüssel verwendet wird. Hierbei handelt es sich um eine VU-Authentisierung unter Verwendung des ECDSA-Algorithmus in Kombination mit dem Hash-Algorithmus, der an die Schlüsselgröße des VU_MA-Schlüsselpaars der VU gebunden ist (siehe CSM_50).

CSM_164 Der Befehl MSE: Set AT beinhaltet zudem die Angabe des flüchtigen Schlüsselpaars, das die VU während der Vereinbarung des Sitzungsschlüssels verwendet (siehe Abschnitt 10.4). Vor dem Senden des Befehls MSE: Set AT generiert die VU deshalb ein flüchtiges ECC-Schlüsselpaar. Zur Generierung des flüchtigen Schlüsselpaars verwendet die VU die im Kartenzertifikat angegebenen standardisierten Domänenparameter. Das flüchtige Schlüsselpaar wird dargestellt als (VU.SK_eph, VU.PK_eph, Card.DP). Die VU wählt die x-Koordinate des flüchtigen öffentlichen Punkts des ECDH-Verfahrens als Schlüsselkennung; dies ist eine komprimierte Darstellung des öffentlichen Schlüssels und wird in der Form Comp(VU.PK_eph) dargestellt.

CSM_165 Wenn der Befehl 'MSE: Set AT' erfolgreich ausgeführt wird, legt die Karte den angegebenen VU.PK zur weiteren Verwendung im Rahmen der VU-Authentisierung fest und speichert Comp(VU.PKeph) temporär. Wenn vor der Vereinbarung des Sitzungsschlüssels zwei oder mehr erfolgreiche Befehle 'MSE: Set AT' gesendet werden, speichert die Karte lediglich den letzten erhaltenen Comp(VU.PKeph). Nach einem erfolgreichen Befehl GENERAL AUTHENTICATE setzt die Karte Comp(VU.PKeph) zurück.

CSM_166 Die Karte überprüft die temporäre Gültigkeit aller von der VU präsentierten oder von der VU als Referenz verwendeten Zertifikate, die im Speicher der Karte abgelegt sind, und lehnt abgelaufene Zertifikate ab.

CSM_167 Um die temporäre Gültigkeit eines von der VU präsentierten Zertifikats zu überprüfen, speichert jede Fahrtenschreiberkarte intern gewisse Daten, die den aktuellen Zeitpunkt darstellen. Diese Daten dürfen von einer VU nicht direkt aktualisiert werden können. Im Moment der Ausgabe wird die aktuelle Uhrzeit einer Karte auf das Effective Date des Card_MA-Zertifikats der Karte gesetzt. Eine Karte darf dann ihre aktuelle Uhrzeit aktualisieren, wenn das Effective Date eines authentischen, von einer VU präsentierten Zertifikats einer "gültigen Zeitquelle" jünger ist als die aktuelle Uhrzeit der Karte. In diesem Fall setzt die Karte ihre aktuelle Uhrzeit auf das Effective Date dieses Zertifikats. Die Karte darf nur die folgenden Zertifikate als gültige Zeitquelle akzeptieren:

• ERCA-Linkzertifikate der 2. Generation
• MSCA-Zertifikate der 2. Generation
• VU-Zertifikate der 2. Generation, die vom selben Land ausgestellt sind wie das bzw. die Kartenzertifikat(e) der Karte selbst.

Hinweis: Die letzte Anforderung impliziert, dass eine Karte die CAR des VU-Zertifikats, d. h. das MSCA_VU-EGF-Zertifikat, erkennen muss. Diese ist mit der CAR ihres eigenen Zertifikats, dem MSCA_Card-Zertifikat, nicht identisch.

CSM_168 Wie in Abbildung 5 angegeben, kann die Karte, sobald sie die Authentizität und Gültigkeit eines zuvor unbekannten Zertifikats überprüft hat, dieses Zertifikat zur zukünftigen Referenz abspeichern. Sie braucht dann die Authentizität dieses Zertifikats nicht ein weiteres Mal zu prüfen, wenn es ihr erneut vorgelegt wird. Die Karte braucht nicht das gesamte Zertifikat zu speichern, sondern lediglich den Inhalt des Zertifikatkörpers (siehe Abschnitt 9.3.2).

10.3. VU-Authentisierung ¹⁸

CSM_169 Fahrzeugeinheiten und Karten verwenden zur Authentisierung der VU gegenüber der Karte das VU-Authentisierungsprotokoll Abbildung 6. Durch die VU-Authentisierung kann die Fahrtenschreiberkarte explizit verifizieren, dass die VU authentisch ist. Dazu verwendet die VU ihren privaten Schlüssel, um eine von der Karte erzeugte Zufallszahl zu signieren.

CSM_170 Neben der Zufallszahl enthält die Signatur der VU die dem Kartenzertifikat entnommene Kennung des Zertifikatinhabers.

Hinweis: Dadurch lässt sich sicherstellen, dass es sich bei der Karte, gegenüber der die VU sich authentisiert, um dieselbe Karte handelt, deren Zertifikatkette die VU zuvor verifiziert hat.

CSM_171 Außerdem nimmt die VU in die Signatur die Kennung des flüchtigen öffentlichen Schlüssels Comp(VU.PKeph) auf, mit dem die VU während der Chip-Authentisierung das Secure Messaging konfiguriert (siehe Abschnitt 10.4).

Hinweis: Dadurch wird sichergestellt, dass es sich bei der VU, mit der die Karte während einer Secure-Messaging-Sitzung kommuniziert, um die von der Karte authentisierte VU handelt.

Abbildung 6 VU-Authentisierungsprotokoll

CSM_172 Wenn die VU während der VU-Authentisierung mehrere Befehle GET CHALLENGE sendet, gibt die Karte jedes Mal einen neue 8-Byte-Zufallszahl zurück, speichert aber nur die letzte Zufallszahl.

CSM_173 Die VU verwendet zur VU-Authentisierung den Signaturalgorithmus ECDSA gemäß DSS; dabei wird der an die Schlüsselgröße des VU_MA-Schlüsselpaars der VU gebundene Hash-Algorithmus verwendet (siehe CSM_50). Das Signaturformat ist Klartext, wie in TR-03111 angegeben. Die VU sendet die resultierende Signatur an die Karte.

CSM_174 Nach Erhalt der VU-Signatur in einem Befehl EXTERNAL AUTHENTICATE führt die Karte Folgendes durch:

• Sie berechnet den Authentisierungstoken, indem sie Card.CHR, den r_card der Kartenzufallszahl und die Kennung des flüchtigen öffentlichen Schlüssels der VU, Comp(VU.PK_eph), miteinander verkettet;
• sie überprüft die Signatur der VU unter Verwendung des ECDSA-Algorithmus und des Hash-Algorithmus, der an die Schlüsselgröße des VU_MA-Schlüsselpaars der VU gebunden ist (siehe CSM_50), in Kombination mit VU.PK und dem berechneten Authentisierungstoken.

10.4. Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels ¹⁸

CSM_175 Fahrzeugeinheiten und Karten verwenden zur Authentisierung der Karte gegenüber der VU das Chip-Authentisierungsprotokoll Abbildung 7. Durch die Chip-Authentisierung kann die Fahrzeugeinheit explizit verifizieren, dass die Karte authentisch ist.

Abbildung 7 Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels

CSM_176 VU und Karte gehen wie folgt vor:

1. Die Fahrzeugeinheit leitet die Chip-Authentisierung durch Senden des Befehls MSE: Set AT ein. Dieser zeigt eine Chip-Authentisierung unter Verwendung des ECDH-Algorithmus an; die Länge des AES-Sitzungsschlüssels ist an die Schlüsselgröße des Card_MA-Schlüsselpaars der Karte gebunden (siehe CSM_50). Die VU ermittelt aus dem Kartenzertifikat die Schlüsselgröße des Schlüsselpaars der Karte.
2. Die VU sendet den öffentlichen Punkt VU.PK_eph ihres flüchtigen Schlüsselpaars an die Karte. Der öffentliche Punkt ist gemäß TR-03111 in einen Oktettstring umzuwandeln. Dabei ist das unkomprimierte Verschlüsselungsformat zu verwenden. Wie in CSM_164 erläutert, hat die VU dieses flüchtige Schlüsselpaar bereits vor der Verifizierung der VU-Zertifikatkette generiert. Dabei sendete die VU die Kennung des flüchtigen öffentlichen Schlüssels Comp(VU.PK_eph) an die Karte, die diese Kennung speicherte.
3. Die Karte berechnet nun Comp(VU.PK_eph) anhand von VU.PK_eph und vergleicht diesen mit dem gespeicherten Wert von Comp(VU.PK_eph).
4. Mithilfe des ECDH-Algorithmus in Kombination mit dem statischen privaten Schlüssel der Karte und dem flüchtigen öffentlichen Schlüssel der VU berechnet die Karte einen geheimen Wert K.
5. Die Karte wählt eine zufällige 8-Byte-Nonce NPICC und leitet mit dieser zwei AES-Sitzungsschlüssel K_MAC und K_ENC von K ab. Siehe CSM_179.
6. Mithilfe von KMAC berechnet die Karte anhand der Kennung des flüchtigen öffentlichen Punkts der VU einen Authentisierungstoken: T_PICC = CMAC(K_MAC, VU.PK_eph). Der öffentliche Punkt muss das von der VU verwendete Format haben (siehe Nummer 2 oben). Die Karte übermittelt N_PICC und T_PICC an die Fahrzeugeinheit.
7. Mithilfe des ECDH-Algorithmus in Kombination mit dem statischen privaten Schlüssel der Karte und dem flüchtigen privaten Schlüssel der VU berechnet die VU den geheimen Wert K auf die gleiche Weise, wie die Karte dies in Schritt 4 durchführte.
8. Die VU leitet die Sitzungsschlüssel K_MAC und K_ENC von K und N_PICC ab, siehe CSM_179.
9. Die VU verifiziert den Authentisierungstoken T_PICC.

CSM_177 In Schritt 3 oben berechnet die Karte Comp(VU.PK_eph) als x-Koordinate des öffentlichen Punkts in VU.PKeph.

CSM_178 In den Schritten 4 und 7 oben verwenden Karte und Fahrzeugeinheit den ECKA-EG Algorithmus gemäß TR-03111.

CSM_179 In den Schritten 5 und 8 oben verwenden Karte und Fahrzeugeinheit die Schlüsselableitungsfunktion für AES-Sitzungsschlüssel gemäß TR-03111, mit den folgenden Präzisierungen und Änderungen:

• Der Zählerwert beträgt '00 00 00 01' für K_ENC und '00 00 00 02' für K_MAC.
• Es wird die optionale Nonce r verwendet, die mit NPICC identisch ist.
• Zum Ableiten von 128-Bits-AES-Schlüsseln ist der Hash-Algorithmus SHA-256 zu verwenden.
• Zum Ableiten von 192-Bits-AES-Schlüsseln ist der Hash-Algorithmus SHA-384 zu verwenden.
• Zum Ableiten von 256-Bits-AES-Schlüsseln ist der Hash-Algorithmus SHA-512 zu verwenden.

Die Länge des Sitzungsschlüssels (d. h. die Länge, nach der der Hash abgeschnitten wird) ist an die Größe des Card_MA-Schlüsselpaars zu binden, siehe CSM_50.

CSM_180 In den Schritten 6 und 9 oben verwenden Karte und Fahrzeugeinheit den AES-Algorithmus im CMAC-Modus, wie in SP 800-38B festgelegt. Die Länge von T_PICC ist an die Länge des AES-Sitzungsschlüssels gemäß CSM_50 zu binden.

10.5. Secure Messaging

10.5.1 Allgemein

CSM_181 Alle zwischen Fahrzeugeinheit und Fahrtenschreiberkarte im Anschluss an eine erfolgreiche Chip-Authentisierung bis zum Sitzungsende ausgetauschten Befehle und Antworten sind durch den Secure-Messaging-Modus zu schützen.

CSM_182 Außer beim Lesen aus einer Datei mit Zugriffsbedingung SM-R-ENC-MAC-G2 (siehe Anlage 2 Abschnitt 4) muss das Secure Messaging im reinen Authentisierungsmodus stattfinden. In diesem Modus werden sämtliche Befehle und Antworten um eine kryptografische Prüfsumme (MAC) ergänzt, um die Authentizität und Integrität der Nachricht zu gewährleisten.

CSM_183 Beim Lesen von Daten aus einer Datei mit Zugriffsbedingung SM-R-ENC-MAC-G2 ist Secure Messaging im Modus Verschlüsseln-dann-Authentisieren zu verwenden. Das bedeutet, dass die Antwort zunächst verschlüsselt wird, um die Vertraulichkeit der Nachricht zu gewährleisten. Anschließend wird anhand der formatierten verschlüsselten Daten ein MAC berechnet, um Authentizität und Integrität sicherzustellen.

CSM_184 Beim Secure Messaging muss AES gemäß Definition im Referenzdokument AES mit den während der Chip-Authentisierung vereinbarten Sitzungsschlüsseln K_MAC und K_ENC verwendet werden.

CSM_185 Als Sendesequenzzähler (Send Sequence Counter, SSC) ist eine unsignierte Ganzzahl zu verwenden, um Replay-Angriffe zu verhindern. Die Größe des SSC muss mit derjenigen des AES-Blocks übereinstimmen, d. h. 128 Bits. Der SSC muss im Format MSB-first vorliegen. Beim Start von Secure Messaging ist der SSC auf null zu setzen (d. h. '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'). Der SSC ist jedes Mal hochzusetzen, bevor eine Befehls- oder Antwort-APDU generiert wird: Da der SSC-Anfangswert in einer SM-Sitzung 0 beträgt, wird er im ersten Befehl auf 1 gesetzt. Der SSC-Wert der ersten Antwort lautet 2.

CSM_186 Zur Nachrichtenverschlüsselung ist KENC mit AES im CBC-Modus (Cipher Block Chaining) gemäß ISO 10116 zu verwenden, mit einem Verschachtelungsparameter m = 1 und einem Initialisierungsvektor SV = E(K_ENC, SSC), d. h. dem aktuellen SSC verschlüsselt mit K_ENC.

CSM_187 Zur Nachrichtenauthentisierung ist K_MAC mit AES in CMAC-Modus gemäß SP 800-38B zu verwenden. Die Länge des MAC ist an die Länge des AES-Sitzungsschlüssels gemäß CSM_50 zu binden. Der SSC ist im MAC vor dem zu authentisierenden Datenpaket einzufügen.

10.5.2 Secure-Message-Struktur ¹⁸

CSM_188 Beim Secure Messaging dürfen nur die in Tabelle 5 aufgeführten Secure-Messaging-Datenobjekte (siehe ISO 7816-4) verwendet werden. In allen Nachrichten sind diese Datenobjekte in der in dieser Tabelle angegebenen Reihenfolge zu verwenden.

Tabelle 5: Secure-Messaging-Datenobjekte

Hinweis: Wie in Anlage 2 angegeben, können Fahrtenschreiberkarten die Befehle READ BINARY und UPDATE BINARY mit ungeradem INS-Byte ('B1' bzw. 'D7') unterstützen. Die Befehlsvarianten sind erforderlich, um Dateien mit 32.768 Bytes oder mehr zu lesen und zu aktualisieren. Falls eine Variante verwendet wird, ist anstelle eines Objekts mit Tag '81' ein Datenobjekt mit Tag 'B3' zu verwenden. Weitere Informationen siehe Anlage 2.

CSM_189 Alle SM-Datenobjekte sind gemäß ISO 8825-1 in DER TLV zu kodieren. Diese Kodierung bewirkt folgende TLV-Struktur (Tag-Length-Value, Tag-Längen-Wert):

Tag: Der Tag ist in ein oder zwei Oktette verschlüsselt und gibt den Inhalt an.

Länge: Die Länge ist als unsignierte Ganzzahl in ein, zwei oder drei Oktette verschlüsselt, was zu einer Länge von maximal 65.535 Oktetten führt. Es ist die Mindestzahl an Oktetten zu verwenden.

Wert: Der Wert ist in null oder mehr Oktette verschlüsselt.

CSM_190 Durch Secure Messaging geschützte APDU sind wie folgt zu erstellen:

• Der Befehlskopf ist in der MAC-Berechnung zu berücksichtigen, deshalb ist für das Klassenbyte CLA der Wert '0C' zu verwenden.
• Wie in Anlage 2 angegeben, müssen sämtliche INS-Bytes gerade sein, mit der möglichen Ausnahme ungerader INS-Bytes für die Befehle READ BINARY und UPDATE BINARY.
• Der tatsächliche Wert von Lc wird nach Anwendung von Secure Messaging in Lc' geändert.
• Das Datenfeld muss aus SM-Datenobjekten bestehen.
• Im geschützten APDU-Befehl ist das neue Le-Byte auf '00' zu setzen. Gegebenenfalls ist ein Datenobjekt '97' in das Datenfeld aufzunehmen, um den Originalwert von Le zu übertragen.

CSM_191 Sämtliche zu verschlüsselnde Datenobjekte sind gemäß ISO 7816-4 mithilfe von Padding Indicator '01' aufzufüllen. Zur Berechnung des MAC müssen Datenobjekte im APDU gemäß ISO 7816-4 aufgefüllt werden.

Hinweis: Bei Secure Messaging erfolgt das Auffüllen immer durch die Secure-Messaging-Schicht, nicht durch die CMAC- oder CBC-Algorithmen.

Zusammenfassung und Beispiele

Ein APDU-Befehl mit angewandtem Secure Messaging besitzt die folgende Struktur, je nach dem jeweiligen ungesicherten Befehl (DO ist Datenobjekt):

Fall 1: CLA INS P1 P2 || Lc' || DO '8E' || Le

Fall 2: CLA INS P1 P2 || Lc' || DO '97' || DO'8E' || Le

Fall 3 (gerades INS-Byte): CLA INS P1 P2 || Lc' || DO '81' || DO'8E' || Le

Fall 3 (ungerades INS-Byte): CLA INS P1 P2 || Lc' || DO 'B3' || DO'8E' || Le

Fall 4 (gerades INS-Byte): CLA INS P1 P2 || Lc' || DO '81' || DO'97' || DO'8E' || Le

Fall 4 (ungerades INS-Byte): CLA INS P1 P2 || Lc' || DO 'B3' || DO'97' || DO'8E' || Le

Dabei ist Le = '00' oder '00 00', je nachdem, ob kurze Längenfelder oder erweiterte Längenfelder verwendet werden; siehe ISO 7816-4.

Eine APDU-Antwort mit angewandtem Secure Messaging besitzt die folgende Struktur, je nach dem jeweiligen ungesicherten Befehl (DO ist Datenobjekt):

Fall 1 oder 3: DO '99' || DO '8E' || SW1SW2

Fall 2 oder 4 (gerades INS-Byte) ohne Verschlüsselung: DO '81' || DO '99' || DO '8E' || SW1SW2

Fall 2 oder 4 (gerades INS-Byte) mit Verschlüsselung: DO '87' || DO '99' || DO '8E' || SW1SW2

Fall 2 oder 4 (ungerades INS-Byte) ohne Verschlüsselung: DO 'B3' || DO '99' || DO '8E' || SW1SW2

Hinweis: Fall 2 oder 4 (ungerades INS-Byte) mit Verschlüsselung kommt in der Kommunikation zwischen VU und Karte nie zum Einsatz.

Im Folgenden sind drei APDU-Transformationen für Befehle mit geradem INS-Code beispielhaft aufgeführt. Abbildung 8 zeigt einen authentisierten APDU-Befehl für Fall 4, Abbildung 9 zeigt eine authentisierte APDU-Antwort für Fall 1/Fall 3, und Abbildung 10 zeigt eine verschlüsselte und authentisierte APDU-Antwort für Fall 2/Fall 4.

Abbildung 8 Transformation eines authentisierten APDU-Befehls für Fall 4

Abbildung 9 Transformation einer authentisierten Antwort-APDU für Fall 1/Fall 3

Abbildung 10 Transformation einer verschlüsselten und authentisierten

10.5.3 Abbruch einer Secure-Messaging-Sitzung ¹⁸

CSM_192 Eine Fahrzeugeinheit muss eine laufende Secure-Messaging-Sitzung abbrechen, wenn (und nur wenn) eine der folgenden Bedingungen eintritt:

• Sie erhält eine APDU-Antwort in Klartext.
• Sie entdeckt in einer APDU-Antwort einen Secure-Messaging-Fehler:
  • Ein erwartetes Secure-Messaging-Datenobjekt fehlt, die Reihenfolge der Datenobjekte ist falsch, oder ein unbekanntes Datenobjekt ist vorhanden.
  • Ein Secure-Messaging-Datenobjekt ist falsch, z.B. der MAC-Wert ist falsch, die TLV-Struktur ist fehlerhaft, oder der Padding Indicator in Tag '87' ist nicht gleich '01'.
• Die Karte sendet ein Statusbyte, laut dem sie einen SM-Fehler entdeckt hat (siehe CSM_194).
• Der Grenzwert für die innerhalb der aktuellen Sitzung zulässige Anzahl an Befehlen und zugehörigen Antworten ist erreicht. Dieser Grenzwert wird für eine VU von ihrem Hersteller festgelegt, der dabei die Sicherheitsanforderungen der verwendeten Hardware berücksichtigt; der Höchstwert beträgt 240 SM-Befehle und zugehörige Antworten pro Sitzung.

CSM_193 Eine Fahrtenschreiberkarte muss eine laufende Secure-Messaging-Sitzung abbrechen, wenn (und nur wenn) eine der folgenden Bedingungen eintritt:

• Sie erhält einen APDU-Befehl in Klartext.
• Sie entdeckt in einem APDU-Befehl einen Secure-Messaging-Fehler:
  • Ein erwartetes Secure-Messaging-Datenobjekt fehlt, die Reihenfolge der Datenobjekte ist falsch, oder ein unbekanntes Datenobjekt ist vorhanden.
  • Ein Secure-Messaging-Datenobjekt ist fehlerhaft, beispielsweise ist der MAC-Wert oder die TLV-Struktur fehlerhaft.
• Sie ist ohne Stromversorgung oder wurde zurückgesetzt.
• Die VU leitet die VU-Authentisierung ein.
• Der Grenzwert für die innerhalb der aktuellen Sitzung zulässige Anzahl an Befehlen und zugehörigen Antworten ist erreicht. Dieser Grenzwert wird für eine Karte von ihrem Hersteller festgelegt, der dabei die Sicherheitsanforderungen der verwendeten Hardware berücksichtigt; der Höchstwert beträgt 240 SM-Befehle und zugehörige Antworten pro Sitzung.

CSM_194 SM-Fehlerbehandlung durch eine Fahrtenschreiberkarte:

• Wenn in einem APDU-Befehl erwartete Secure-Messaging-Datenobjekte fehlen, die Reihenfolge der Datenobjekte falsch ist oder unbekannte Datenobjekte vorhanden sind, antwortet die Fahrtenschreiberkarte mit den Statusbytes '69 87'.
• Wenn ein Secure-Messaging-Datenobjekt in einem APDU-Befehl falsch ist, antwortet die Fahrtenschreiberkarte mit Statusbytes '69 88'.

In einem solchen Fall werden die Statusbytes ohne SM zurückgesendet.

CSM_195 Wenn eine Secure-Messaging-Sitzung zwischen VU und Fahrtenschreiberkarte abgebrochen wird, führen VU und Fahrtenschreiberkarte Folgendes durch:

• Sie zerstören die gespeicherten Sitzungsschlüssel auf sichere Weise.
• Sie leiten sofort eine neue Secure-Messaging-Sitzung ein, wie in den Abschnitten 10.2 - 10.5 beschrieben.

CSM_196 Wenn die VU aus beliebigem Grund entscheidet, die gegenseitige Authentisierung mit einer eingesetzten Karte neu zu starten, beginnt der Prozess mit der Verifizierung der Zertifikatkette der Karte (siehe Abschnitt 10.2) und geht dann gemäß den Abschnitten 10.2 - 10.5 weiter.

11. VU und externe GNSS-Ausrüstung: Koppelung, gegenseitige Authentisierung und Secure Messaging

11.1. Allgemein

CSM_197 Bei der von einer VU zur Ermittlung ihrer Position genutzten GNSS-Ausrüstung kann es sich um ein internes (d. h. in das VU-Gehäuse fest integriertes) oder externes Modul handeln. Im ersten Fall ist es nicht nötig, die interne Kommunikation zwischen GNSS-Ausrüstung und VU zu standardisieren; die Anforderungen dieses Kapitels gelten deshalb nicht. Im zweiten Fall muss die Kommunikation zwischen VU und externer GNSS-Ausrüstung nach den Beschreibungen in diesem Kapitel standardisiert und geschützt werden.

CSM_198 Die sichere Kommunikation zwischen Fahrzeugeinheit und externer GNSS-Ausrüstung erfolgt genauso wie die sichere Kommunikation zwischen Fahrzeugeinheit und Fahrtenschreiberkarte, wobei die externe GNSS-Ausrüstung (EGF) die Rolle der Karte einnimmt. Die externe GNSS-Ausrüstung muss alle in Kapitel 10 für Fahrtenschreiberkarten erwähnten Anforderungen erfüllen, wobei die in diesem Kapitel genannten Abweichungen, Klärungen und Ergänzungen zu berücksichtigen sind. Insbesondere müssen gegenseitige Verifizierung der Zertifikatkette, VU-Authentisierung und Chip-Authentisierung gemäß den Abschnitten 11.3 und 11.4 erfolgen.

CSM_199 Die Kommunikation zwischen Fahrzeugeinheit und EGF unterscheidet sich von der Kommunikation zwischen Fahrzeugeinheit und Karte insofern, als Fahrzeugeinheit und EGF einmal in einer Werkstatt gekoppelt werden müssen, damit VU und EGF im Normalbetrieb GNSS-basierte Daten austauschen können. Die Koppelung wird in Abschnitt 11.2 beschrieben.

CSM_200 Zur Kommunikation zwischen Fahrzeugeinheit und EGF sind APDU-Befehle und -Antworten gemäß ISO 7816-4 und ISO 7816-8 zu verwenden. Die genaue Struktur dieser APDU ist in Anlage 2 dieses Anhangs festgelegt.

11.2. Koppelung von VU und externer GNSS-Ausrüstung

CSM_201 Fahrzeugeinheit und EGF in einem Fahrzeug müssen durch eine Werkstatt gekoppelt werden. Nur gekoppelte Fahrzeugeinheiten und EGF dürfen im Normalbetrieb kommunizieren.

CSM_202 Die Koppelung von Fahrzeugeinheit und EGF darf nur möglich sein, wenn sich die Fahrzeugeinheit im Kalibrierungsmodus befindet. Die Koppelung ist durch die Fahrzeugeinheit einzuleiten.

CSM_203 Eine Werkstatt kann eine Fahrzeugeinheit jederzeit mit einer anderen oder derselben EGF neu koppeln. Während der Neukoppelung muss die VU das in ihrem Speicher vorhandene EGF_MA-Zertifikat auf sichere Weise zerstören und das EGF_MA-Zertifikat der EGF, mit der sie gekoppelt wird, im Speicher ablegen.

CSM_204 Eine Werkstatt kann eine externe GNSS-Ausrüstung jederzeit mit einer anderen oder derselben VU neu koppeln. Während der Neukoppelung muss die EGF das in ihrem Speicher vorhandene VU_MA-Zertifikat auf sichere Weise zerstören und das VU_MA-Zertifikat der VU, mit der sie gekoppelt wird, im Speicher ablegen.

11.3. Gegenseitige Verifizierung der Zertifikatkette

11.3.1 Allgemein

CSM_205 Die gegenseitige Verifizierung der Zertifikatkette zwischen VU und EGF kann nur während der Koppelung von VU und EGF durch eine Werkstatt erfolgen. Im Normalbetrieb gekoppelter VU und EGF werden keine Zertifikate verifiziert. Stattdessen vertrauen VU und EGF den während der Koppelung gespeicherten Zertifikaten, überprüfen allerdings deren temporäre Gültigkeit. Um im Normalbetrieb die Kommunikation zwischen VU und EGF zu schützen, vertrauen VU und EGF lediglich diesen Zertifikaten.

11.3.2 Während der Koppelung VU-EGF ¹⁸

CSM_206 Während der Koppelung an eine EGF verwendet die Fahrzeugeinheit das in Abbildung 4 (Abschnitt 10.2.1) dargestellte Protokoll, um die Zertifikatkette der externen GNSS-Ausrüstung zu verifizieren.

Hinweise zu Abbildung 4 in diesem Kontext:

• Die Kommunikationskontrolle ist nicht Gegenstand dieser Anlage. Allerdings handelt es sich bei einer EGF nicht um eine Chipkarte, weshalb die VU vermutlich kein Reset zum Einleiten der Kommunikation senden und kein ATR erhalten wird.
• Die in der Abbildung genannten Zertifikate und öffentlichen Schlüssel der Karte sind als Zertifikate und öffentlichen Schlüssel der EGF zur gegenseitigen Authentisierung zu verstehen. In Abschnitt 9.1.6 werden sie als EGF_MA bezeichnet.
• Die in der Abbildung genannten Card.CA-Zertifikate und öffentlichen Schlüssel sind als Zertifikate und öffentlichen Schlüssel der MSCA zum Signieren der EGF-Zertifikate zu verstehen. In Abschnitt 9.1.3 werden sie als MSCA_VU-EGF bezeichnet.
• Das in der Abbildung erwähnte Card.CA.EUR-Zertifikat ist als das europäische Wurzelzertifikat zu verstehen, das in der CAR des MSCA-VU-EGF-Zertifikats angegeben ist.
• Das in der Abbildung erwähnte Card.Link-Zertifikat ist als das Linkzertifikat der EGF zu verstehen, sofern vorhanden. Wie in Abschnitt 9.1.2 angegeben, handelt es sich hierbei um ein Linkzertifikat für ein neues europäisches Wurzel-Schlüsselpaar, das durch die ERCA erstellt und mithilfe des zuvor erwähnten europäischen privaten Schlüssels signiert wird.
• Bei dem Card.Link.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des Card.Link-Zertifikats angegeben ist.
• Anstelle der card ExtendedSerialNumber liest die VU die sensorGNSSSerialNumber aus der EF-ICC.
• Die VU wählt nicht die Fahrtenschreiber-AID, sondern die EGF-AID.
• "Karte ignorieren" ist als "EGF ignorieren" zu verstehen.

CSM_207 Wenn die Fahrzeugeinheit das EGF_MA-Zertifikat verifiziert hat, speichert sie es zur Verwendung im Normalbetrieb; siehe Abschnitt 11.3.3.

CSM_208 Während der Koppelung an eine VU verwendet die externe GNSS-Ausrüstung das in Abbildung 5 (Abschnitt 10.2.2) dargestellte Protokoll, um die Zertifikatkette der VU zu verifizieren.

Hinweise zu Abbildung 5 in diesem Kontext:

• Die VU generiert mithilfe der Domänenparameter im EGF-Zertifikat ein neues flüchtiges Schlüsselpaar.
• Bei den in der Abbildung erwähnten VU-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur gegenseitigen Authentisierung. In Abschnitt 9.1.4 werden sie als VU_MA bezeichnet.
• Bei den in der Abbildung erwähnten VU.CA-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur Signierung der Zertifikate von VU und externer GNSS-Ausrüstung. In Abschnitt 9.1.3 werden sie als MSCA_VU-EGF bezeichnet.
• Bei dem in der Abbildung erwähnten VU.CA.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des VU.CA-Zertifikats angegeben ist.
• Das in der Abbildung erwähnte VU.Link-Zertifikat ist das Linkzertifikat der VU, sofern vorhanden. Wie in Abschnitt 9.1.2 angegeben, handelt es sich hierbei um ein Linkzertifikat für ein neues europäisches Wurzel-Schlüsselpaar, das durch die ERCA erstellt und mithilfe des zuvor erwähnten europäischen privaten Schlüssels signiert wird.
• Bei dem VU.Link.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des VU.Link-Zertifikats angegeben ist.

CSM_209 In Abweichung von Anforderung CSM_167 verwendet eine EGF die GNSS-Zeit, um die temporäre Gültigkeit präsentierter Zertifikate zu überprüfen.

CSM_210 Wenn die externe GNSS-Ausrüstung das VU_MA-Zertifikat verifiziert hat, speichert sie es zur Verwendung im Normalbetrieb; siehe Abschnitt 11.3.3.

11.3.3 Im Normalbetrieb ¹⁸

CSM_211 Im Normalbetrieb verwenden Fahrzeugeinheit und EGF das in Abbildung 11 dargestellte Protokoll, um die temporäre Gültigkeit des gespeicherten EGF_MA-Zertifikats zu überprüfen und um den öffentlichen VU_MA-Schlüssel zur anschließenden VU-Authentisierung festzulegen. Im Normalbetrieb findet keine weitere gegenseitige Verifizierung der Zertifikatketten statt.

Hinweis: Abbildung 11 besteht im Wesentlichen aus den ersten in Abbildung 4 und Abbildung 5 dargestellten Schritten. Wie bereits erwähnt, handelt es sich bei einer EGF nicht um eine Chipkarte, weshalb die VU vermutlich kein Reset zum Einleiten der Kommunikation senden und kein ATR erhalten wird. Dies ist nicht Gegenstand dieser Anlage.

Abbildung 11 Gegenseitige Verifizierung der temporären Gültigkeit von Zertifikaten im normalen VU-EGF-Betrieb

CSM_212 Wie in Abbildung 11 dargestellt, meldet die Fahrzeugeinheit einen Fehler, wenn das EGF_MA-Zertifikat nicht mehr gültig ist. Allerdings erfolgen gegenseitige Authentisierung, Schlüsselvereinbarung und anschließende Kommunikation per Secure Messaging normal.

11.4. VU-Authentisierung, Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels

CSM_213 VU-Authentisierung, Chip-Authentisierung und Sitzungsschlüsselvereinbarung zwischen VU und EGF erfolgen im Rahmen der Koppelung und jedes Mal, wenn im Normalbetrieb eine Secure-Messaging-Sitzung wiederhergestellt wird. VU und EGF gehen wie in den Abschnitten 10.3 und 10.4 erläutert vor. Es gelten sämtliche Anforderungen dieser Abschnitte.

11.5. Secure Messaging

CSM_214 Alle zwischen Fahrzeugeinheit und externer GNSS-Ausrüstung im Anschluss an eine erfolgreiche Chip-Authentisierung bis zum Sitzungsende ausgetauschten Befehle und Antworten sind durch Secure Messaging im reinen Authentisierungsmodus zu schützen. Es gelten sämtliche Anforderungen von Abschnitt 10.5.

CSM_215 Wenn eine Secure-Messaging-Sitzung zwischen VU und EGF abgebrochen wird, leitet die VU sofort eine neue Secure-Messaging-Sitzung ein (siehe Abschnitte 11.3.3 und 11.4).

12. Koppelung und Kommunikation VU-Bewegungssensor

12.1. Allgemein

CSM_216 Die Kommunikation zwischen Fahrzeugeinheit und Bewegungssensor während der Koppelung und im Normalbetrieb hat mithilfe des in ISO 16844-3 spezifizierten Schnittstellenprotokolls zu erfolgen, unter Vornahme der in diesem Kapitel und in Abschnitt 9.2.1 beschriebenen Änderungen.

Hinweis: Es wird vorausgesetzt, dass die Leserinnen und Leser dieses Kapitels mit den Inhalten von ISO 16844-3 vertraut sind.

12.2. Koppelung VU-Bewegungssensor unter Verwendung verschiedener Schlüsselgenerationen

Wie in Abschnitt 9.2.1 erläutert, werden der Hauptschüssel des Bewegungssensors und alle damit verbundenen Schlüssel regelmäßig ersetzt. Dies führt dazu, dass in Werkstattkarten bis zu drei AES-Schlüssel K_M-WC (fortlaufender Schlüsselgenerationen) für den Bewegungssensor vorhanden sind. Ebenso können in Bewegungssensoren bis zu drei verschiedene AES-basierte Datenverschlüsselungen (basierend auf fortlaufenden Generationen des K_M-Bewegungssensor-Hauptschlüssels) vorhanden sein. Eine Fahrzeugeinheit enthält nur einen K_M-VU-Schlüssel für den Bewegungssensor.

CSM_217 Eine VU der 2. Generation und ein Bewegungssensor der 2. Generation sind wie folgt zu koppeln (vergleiche Tabelle 6 in ISO 16844-3):

1. Eine Werkstattkarte der zweiten Generation wird in die VU eingesteckt und diese mit dem Bewegungssensor verbunden.
2. Die VU liest alle auf der Werkstattkarte verfügbaren K_M-WC-Schlüssel, geht deren Versionsnummern durch und wählt denjenigen aus, der mit der Versionsnummer des K_M-VU-Schlüssels der VU übereinstimmt. Befindet sich der passende K_M-WC-Schlüssel nicht auf der Werkstattkarte, bricht die VU den Koppelungsprozess ab und zeigt dem Inhaber der Werkstattkarte eine entsprechende Fehlermeldung an.
3. Die VU berechnet den Bewegungssensor-Hauptschlüssel K_M aus dem K_M-VU und dem K_M-WC sowie den Identifikationsschlüssel K_ID aus dem K_M, wie in Abschnitt 9.2.1 spezifiziert.
4. Die VU sendet den Befehl zum Einleiten des Koppelungsprozesses an den Bewegungssensor, wie in ISO 16844-3 beschrieben, und verschlüsselt die Seriennummer, die sie vom Bewegungssensor erhält, mit dem Identifikationsschlüssel K_ID. Die VU sendet die verschlüsselte Seriennummer zurück an den Bewegungssensor.
5. Der Bewegungssensor gleicht die verschlüsselte Seriennummer nacheinander mit jeder intern vorhandenen Verschlüsselung der Seriennummer ab. Wenn er das passende Gegenstück findet, wird die VU authentisiert. Der Bewegungssensor erkennt die von der VU verwendete K_ID-Generation und sendet die kodierte Version des Koppelungsschlüssels, d. h. die Verschlüsselung, die mithilfe derselben K_M-Generation erstellt wurde, zurück.
6. Die VU entschlüsselt den Koppelungsschlüssel mithilfe des K_M, generiert einen Sitzungsschlüssel K_S, verschlüsselt ihn mit dem Koppelungsschlüssel und sendet das Ergebnis an den Bewegungssensor. Der Bewegungssensor entschlüsselt den K_S.
7. Die VU setzt die Koppelungsinformation gemäß ISO 16844-3 zusammen, verschlüsselt die Information mit dem Koppelungsschlüssel und sendet das Ergebnis an den Bewegungssensor. Der Bewegungssensor entschlüsselt die Koppelungsinformation.
8. Der Bewegungssensor verschlüsselt die empfangene Koppelungsinformation mit dem empfangenen K_S und sendet sie an die VU zurück. Die VU prüft, ob die Koppelungsinformation mit derjenigen übereinstimmt, die die VU im vorherigen Schritt an den Bewegungssensor gesendet hat. Falls ja, ist damit belegt, dass der Bewegungssensor denselben KS verwendet hat wie die VU und somit in Schritt 5 seinen mit der korrekten K_M-Generation verschlüsselten Koppelungsschlüssel gesendet hat. Der Bewegungssensor ist somit authentisiert.

Es ist zu beachten, dass die Schritte 2 und 5 vom Standardprozess gemäß ISO 16844-3 abweichen; die übrigen Schritte entsprechen dem Standardprozess.

Beispiel: Angenommen, im ersten Jahr der Gültigkeit des ERCA (3)-Zertifikats findet eine Koppelung statt; siehe Abbildung 2 in Abschnitt 9.2.1.2, und

• angenommen, der Bewegungssensor wurde im letzten Jahr der Gültigkeit des ERCA (1)-Zertifikats ausgestellt. Unter diesen Umständen enthält er die folgenden Schlüssel und Daten:
  • N_s[1]: seine Seriennummer, verschlüsselt mit K_ID-Generation 1
  • N_s[2]: seine Seriennummer, verschlüsselt mit K_ID-Generation 2
  • N_s[3]: seine Seriennummer, verschlüsselt mit K_ID-Generation 3
  • K_P[1]: seinen Koppelungsschlüssel der 1. Generation ¹, verschlüsselt mit K_M-Generation 1
  • K_P[2]: seinen Koppelungsschlüssel der 2. Generation, verschlüsselt mit K_M-Generation 2
  • K_P[3]: seinen Koppelungsschlüssel der 3. Generation, verschlüsselt mit K_M-Generation 3
• Angenommen, die Werkstattkarte wurde im ersten Jahr der Gültigkeit des ERCA (3)-Zertifikats ausgestellt. Unter diesen Umständen enthält sie den Schlüssel K_M-WC der 2. und 3. Generation.
• Angenommen, bei der VU handelt es sich um eine VU der 2. Generation, die die 2. Generation des K_M-VU enthält.

Unter diesen Umständen geschieht in den Schritten 2-5 Folgendes:

• Schritt 2: Die VU liest den K_M-WC der 2. und 3. Generation von der Werkstattkarte und prüft deren Versionsnummern.
• Schritt 3: Die VU kombiniert den K_M-WC der 2. Generation mit K_M-VU, um K_M und K_ID zu berechnen.
• Schritt 4: Die VU verschlüsselt die Seriennummer, die sie vom Bewegungssensor erhält, mit dem K_ID.
• Schritt 5: Der Bewegungssensor vergleicht die empfangenen Daten mit N_s[1] und findet kein Gegenstück. Dann vergleicht er die Daten mit N_s[2] und findet ein Gegenstück. Er folgert, dass es sich bei der VU um eine VU der 2. Generation handelt, und sendet daher K_P[2] zurück.

12.3. Koppelung und Kommunikation VU-Bewegungssensor mit AES

CSM_218 Wie in Tabelle 3 in Abschnitt 9.2.1 spezifiziert, handelt es sich bei allen Schlüsseln, die an der Koppelung einer Fahrzeugeinheit (der 2. Generation) und eines Bewegungssensors sowie an der nachfolgenden Kommunikation beteiligt sind, nicht um T-DES-Schlüssel doppelter Länge, sondern um AES-Schlüssel (siehe ISO 16844-3). Diese AES-Schlüssel können eine Länge von 128, 192 oder 256 Bits aufweisen. Da die AES-Blockgröße bei 16 Bytes liegt, muss die Länge einer verschlüsselten Nachricht ein Mehrfaches von 16 Bytes betragen (T-DES: 8 Bytes). Darüber hinaus werden einige dieser Nachrichten für die Übertragung von AES-Schlüsseln verwendet, deren Länge bei 128, 192 oder 256 Bits liegen kann. Daher ist die Anzahl an Datenbyte pro Anweisung in Tabelle 5 von ISO 16844-3 gemäß folgender Tabelle 6 zu verändern:

Tabelle 6: Anzahl der Klartext- und verschlüsselten Datenbyte pro Befehl gemäß ISO 16844-3 ¹⁸

CSM_219 Die Koppelungsinformation, die in den Anweisungen 43 (VU-Anforderung) und 50 (Antwort des Bewegungssensors) gesendet wird, ist gemäß der Beschreibung in Abschnitt 7.6.10 von ISO 16844-3 zusammenzusetzen, allerdings wird anstelle des T-DES-Algorithmus im Verschlüsselungssystem für die Koppelungsdaten der AES-Algorithmus verwendet, sodass zwei AES-Verschlüsselungen erfolgen und die in CSM_220 beschriebene Auffüllmethode passend zur AES-Blockgröße angewandt wird. Der für diese Verschlüsselung verwendete Schlüssel K'_p wird wie folgt generiert:

• Wenn der Koppelungsschlüssel K_P 16 Bytes lang ist: K'_p = K_P XOR (N_s||N_s)
• Wenn der Koppelungsschlüssel K_P 24 Bytes lang ist: K'_p = K_P XOR (N_s||N_s||N_s)
• Wenn der Koppelungsschlüssel K_P 32 Bytes lang ist: K'_p = K_P XOR (N_s||N_s||N_s||N_s)

wobei N_s die 8-Byte-Seriennummer des Bewegungssensors ist.

CSM_220 Falls die Länge der Klartextdaten (bei Verwendung von AES-Schlüsseln) kein Vielfaches von 16 Bytes ist, hat die in ISO 9797-1 beschriebene Auffüllmethode 2 zur Anwendung zu kommen.

Hinweis: In ISO 16844-3 ist die Anzahl der Klartext-Datenbytes stets ein Vielfaches von 8, sodass bei Verwendung von T-DES kein Auffüllen erforderlich ist. Die Definition der Daten und Nachrichten in ISO 16844-3 wird durch diesen Teil der Anlage nicht verändert, was die Anwendung der Auffüllmethode erforderlich macht.

CSM_221 Für Anweisung 11 und falls mehr als ein Datenblock verschlüsselt werden muss, ist der Betriebsmodus Cipher Block Chaining gemäß ISO 10116 zu verwenden, mit einem Verschachtelungsparameter von m = 1. Der zu verwendende IV ist:

• für Anweisung 11: der in Abschnitt 7.6.3.3 von ISO 16844-3 spezifizierte 8-Byte-Authentisierungsblock, aufgefüllt mithilfe der in ISO 9797-1 beschriebenen Auffüllmethode 2; siehe auch Abschnitte 7.6.5 und 7.6.6 von ISO 16844-3.
• für alle anderen Befehle, in denen mehr als 16 Bytes übertragen werden, wie in Tabelle 6 spezifiziert: '00' {16}, d. h. sechzehn Bytes mit Binärwert 0.

Hinweis: Wie in den Abschnitten 7.6.5 und 7.6.6 von ISO 16844-3 beschrieben, wird - wenn der Bewegungssensor Dateien für die Einbeziehung in Anweisung 11 verschlüsselt - der Authentisierungsblock sowohl

• als Initialisierungsvektor für die Verschlüsselung der Dateien mithilfe des CBC-Modus verwendet als auch
• verschlüsselt und als erster Block in die Daten einbezogen, die an die VU gesendet werden.

12.4. Koppelung VU-Bewegungssensor bei verschiedenen Gerätegenerationen

CSM_222 Wie in Abschnitt 9.2.1 erläutert, kann ein Bewegungssensor der zweiten Generation die T-DES-basierte Verschlüsselung der Koppelungsdaten (wie in Teil A dieser Anlage definiert) enthalten, wodurch sich der Bewegungssensor mit einer VU der 1. Generation koppeln lässt. In diesem Fall sind eine VU der 1. Generation und ein Bewegungssensor der 2. Generation so zu koppeln, wie in Teil A dieser Anlage und in ISO 16844-3 beschrieben. Für den Koppelungsprozess kann eine Werkstattkarte der 1. oder 2. Generation verwendet werden.

Hinweise:

• Eine VU der 2. Generation kann nicht mit einem Bewegungssensor der 1. Generation gekoppelt werden.
• Eine Werkstattkarte der 1. Generation kann nicht zur Koppelung einer VU der 2. Generation an einen Bewegungssensor verwendet werden.

13. Sicherheit für Fernkommunikation per DSRC

13.1. Allgemein ¹⁸

Wie in Anlage 14 spezifiziert, generiert eine VU regelmäßig Daten zur Fernüberwachung des Fahrtenschreibers (Remote Tachograph Monitoring, RTM) und sendet diese an die (interne oder externe) Fernkommunikationsvorrichtung (Remote Communication Facility, RCF). Die RCF sendet diese Daten über die in Anlage 14 beschriebene DSRC-Schnittstelle an die Fernabfrageeinrichtung (Remote Interrogator, RI). Gemäß Anlage 1 sind die RTM-Daten eine Verkettung von:

Fahrtenschreibernutzdaten die Verschlüsselung der Klartextnutzdaten des Fahrtenschreibers

DSRC-Sicherheitsdaten weiter unten beschrieben

Das Format der Klartextnutzdaten des Fahrtenschreibers ist in Anlage 1 spezifiziert und in Anlage 14 genauer erläutert. Dieser Abschnitt beschreibt die Struktur der DSRC-Sicherheitsdaten; die formale Spezifikation findet sich in Anlage 1.

CSM_223 Die tachograph Payload-Klartextdaten, die von einer VU an eine RCF (wenn die RCF sich außerhalb der VU befindet) oder von der VU per DSRC-Schnittstelle an den RI (wenn die RCF sich innerhalb der VU befindet) gesendet werden, sind im Modus Verschlüsseln-dann-Authentisieren zu schützen, d. h., die Fahrtenschreibernutzdaten werden zunächst verschlüsselt, um die Vertraulichkeit der Nachricht sicherzustellen, und anschließend wird ein MAC berechnet, um die Authentizität und Integrität der Daten zu gewährleisten.

CSM_224 Die DSRC-Sicherheitsdaten müssen aus einer Verkettung folgender Datenelemente in folgender Reihenfolge bestehen; siehe auch Abbildung 12:

CSM_225 Der 3-Byte-Zähler in den DSRC-Sicherheitsdaten muss im Format MSB-first vorliegen. Bei der ersten Berechnung eines RTM-Datensatzes nach ihrer Inproduktionsnahme setzt die VU den Wert des Zählers auf 0. Die VU erhöht den Wert der Zählerdaten vor jeder Berechnung eines weiteren RTM-Datensatzes um 1.

13.2. Verschlüsselung der Fahrtenschreibernutzdaten und MAC-Generierung

CSM_226 Bei Vorliegen eines Klartext-Datenelements vom Datentyp TachographPayload im Sinne von Anlage 14 verschlüsselt eine VU diese Daten gemäß Abbildung 12: Der DSRC-Schlüssel der VU für die Verschlüsselung K_VU_DSRC_ENC (siehe Abschnitt 9.2.2) ist mit AES im Betriebsmodus Cipher Block Chaining (CBC) gemäß ISO 10116 zu verwenden, mit einem Verschachtelungsparameter von m = 1. Der Initialisierungsvektor muss IV = current date time ||'00 00 00 00 00 00 00 00 00' || counter entsprechen, wobei current date time und counter in CSM_224 spezifiziert sind. Die zu verschlüsselnden Daten sind mit der in ISO 9797-1 definierten Auffüllmethode 2 aufzufüllen.

CSM_227 Die VU berechnet MAC in den DSRC-Sicherheitsdaten gemäß Abbildung 12: Der MAC ist mithilfe aller vorausgehenden Bytes in den RTM-Daten zu berechnen, bis einschließlich der DSRC-Hauptschlüsselversionsnummer und einschließlich der Tags und Längen der Datenobjekte. Die VU muss ihren DSRC-Schlüssel zur Authentizität K_VU_DSRC_MAC verwenden (siehe Abschnitt 9.2.2), mit dem AES-Algorithmus im CMAC-Modus (siehe SP 800-38B). Die Länge des MAC ist an die Länge des VU-spezifischen DSRC-Schlüssels gebunden (siehe CSM_50).

Abbildung 12 Verschlüsselung der Fahrtenschreibernutzdaten und MAC-Generierung

13.3. Verifizierung und Entschlüsselung der Fahrtenschreibernutzdaten ¹⁸

CSM_228 Wenn ein RI von einer VU RTM-Daten erhält, muss er die gesamten RTM-Daten an eine Kontrollkarte im Datenfeld eines Befehls PROCESS DSRC MESSAGE senden (siehe Anlage 2). Anschließend gilt:

1. Die Kontrollkarte überprüft die DSRC-Hauptschlüsselversionsnummer in den DSRC-Sicherheitsdaten. Wenn die Kontrollkarte den angegebenen DSRC-Hauptschlüssel nicht kennt, muss sie eine Fehlermeldung gemäß Anlage 2 zurücksenden und den Prozess abbrechen.
2. Die Kontrollkarte verwendet den angegebenen DSRC-Hauptschlüssel in Kombination mit der VU-Seriennummer oder der Kennung für den Zertifikatsantrag in den DSRC-Sicherheitsdaten, um daraus die VU-spezifischen DSRC-Schlüssel K_VUDSRC_ENC und K_VUDSRC_MAC abzuleiten (siehe CSM_124).
3. Die Kontrollkarte verwendet K_VU_DSRC_MAC, um den MAC in den DSRC-Sicherheitsdaten zu überprüfen (siehe CSM_227). Wenn der MAC inkorrekt ist, muss die Kontrollkarte eine Fehlermeldung gemäß Anlage 2 zurücksenden und den Prozess abbrechen.
4. Die Kontrollkarte verwendet K_VU_DSRC_ENC, um die verschlüsselten Fahrtenschreibernutzdaten zu entschlüsseln, wie in CSM_226 spezifiziert. Die Kontrollkarte entfernt die Auffüllung und sendet die verschlüsselten Fahrtenschreibernutzdaten an den RI zurück.

CSM_229 Um Replay-Angriffe zu verhindert, muss der RI die Frische der RTM-Daten überprüfen, indem er sicherstellt, dass current date time in den DSRC-Sicherheitsdaten nicht zu sehr von der aktuellen Zeit des RI abweicht.

Hinweise:

• Hierfür muss der RI über eine präzise und verlässliche Zeitquelle verfügen.
• Da eine VU gemäß Anlage 14 alle 60 Sekunden einen neuen RTM-Datensatz berechnen muss und die Uhr der VU 1 Minute von der Echtzeit abweichen darf, beträgt die untere Grenze für die Frische der RTM-Daten 2 Minuten. Die jeweiligen Frischeanforderungen hängen auch von der Genauigkeit der RI-Uhr ab.

CSM_230 Wenn eine Werkstatt das einwandfreie Funktionieren der DSRC-Funktion der VU überprüft, sendet sie alle von der VU erhaltenen RTM-Daten an eine Werkstattkarte im Datenfeld eines Befehls PROCESS DSRC MESSAGE (siehe Anlage 2). Die Werkstattkarte muss alle in CSM_228 angegebenen Prüfungen und Aktionen durchführen.

14. Signieren von Datendownloads und Verifizieren der Signaturen

14.1. Allgemein

CSM_231 Das Intelligent Dedicated Equipment (IDE) speichert die von einer VU oder Karte während eines Übertragungsvorgangs empfangenen Daten in einer Datei ab. Daten können auf einem externen Speichermedium (ESM) gespeichert werden. Die Datei enthält digitale Signaturen von Datenblöcken gemäß Anlage 7. Die betreffende Datei muss außerdem folgende Zertifikate enthalten (siehe Abschnitt 9.1):

• im Falle eines VU-Downloads:
  • das VU_Sign-Zertifikat
  • das MSCA_VU-EGF-Zertifikat mit dem öffentlichen Schlüssel zur Verifizierung des VU_Sign-Zertifikats
• im Falle eines Kartendownloads:
  • das Card_Sign-Zertifikat
  • das MSCA_Card-Zertifikat mit dem öffentlichen Schlüssel zur Verifizierung des Card_Sign-Zertifikats

CSM_232 Das IDE muss außerdem über Folgendes verfügen:

• falls es eine Kontrollkarte zur Verifizierung der Signatur verwendet, wie in Abbildung 13 gezeigt: das Linkzertifikat, das das neueste EUR-Zertifikat gegebenenfalls mit dem direkt davor gültigen EUR-Zertifikat verknüpft.
• falls es die Signatur selbst verifiziert: alle gültigen europäischen Wurzelzertifikate.

Hinweis: Die Methode, mit der das IDE diese Zertifikate abruft, ist in dieser Anlage nicht spezifiziert.

14.2. Erzeugung der Signatur

CSM_233 Als Signaturalgorithmus zur Erzeugung digitaler Signaturen anhand heruntergeladener Daten wird ECDSA gemäß DSS verwendet; dabei ist der an die Schlüsselgröße der VU oder Karte gebundene Hash-Algorithmus zu verwenden (siehe CSM_50). Das Signaturformat ist Klartext, wie in TR-03111 angegeben.

14.3. Verifizierung der Signatur ¹⁸

CSM_234 Ein IDE kann die Verifizierung einer Signatur anhand heruntergeladener Daten selbst durchführen oder zu diesem Zweck eine Kontrollkarte verwenden. Falls es eine Kontrollkarte verwendet, ist die Verifizierung der Signatur gemäß Abbildung 13 durchzuführen. Die Kontrollkarte überprüft die temporäre Gültigkeit eines vom IDE vorgelegten Zertifikats mithilfe ihrer internen aktuellen Uhrzeit (siehe CSM_167). Die Kontrollkarte darf dann ihre aktuelle Uhrzeit aktualisieren, wenn das Effective Date eines authentischen Zertifikats einer 'gültigen Zeitquelle' jünger ist als die aktuelle Uhrzeit der Karte. Die Karte darf nur die folgenden Zertifikate als gültige Zeitquelle akzeptieren:

• ERCA-Linkzertifikate der 2. Generation
• MSCA-Zertifikate der 2. Generation
• VU_Sign- oder Card_Sign-Zertifikate der 2. Generation, die vom selben Land ausgestellt sind wie das bzw. die Kartenzertifikat(e) der Kontrollkarte selbst.

Falls es die Verifizierung der Signatur selbst durchführt, muss das IDE die Authentizität und Gültigkeit aller Zertifikate in der Zertifikatkette der Datei sowie die Signatur anhand der Daten gemäß dem in DSS definierten Signatursystem überprüfen. In beiden Fällen ist es erforderlich, bei jedem aus der Datei ausgelesenem Zertifikat die Richtigkeit des Feldes Certificate Holder Authorisation (CHA) zu überprüfen:

• Im Feld CHA des EQT-Zertifikats muss ein VU-Zertifikat bzw. ein Kartenzertifikat zur Signierung angegeben sein (siehe Anlage 1, Datentyp EquipmentType).
• In der CHA des EQT.CA-Zertifikats muss eine MSCA angegeben sein.
• In der CHA des EQT.Link-Zertifikats muss die ERCA angegeben sein.

Hinweise zu Abbildung 13:

• Das Gerät, das die zu analysierenden Daten signiert hat, ist mit EQT bezeichnet.
• Bei den in der Abbildung erwähnten EQT-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur Signierung von Kartenzertifikaten, d. h. VU_Sign oder Card_Sign.
• Bei den in der Abbildung erwähnten EQT.CA-Zertifikaten und öffentlichen Schlüsseln handelt es sich um diejenigen zur Signierung der Zertifikate von VU bzw. Karte.
• Bei dem in der Abbildung erwähnten EQT.CA.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des EQT.CA-Zertifikats angegeben ist.
• Das in der Abbildung erwähnte EQT.Link-Zertifikat ist das Linkzertifikat des Geräts, sofern vorhanden. Wie in Abschnitt 9.1.2 angegeben, handelt es sich hierbei um ein Linkzertifikat für ein neues europäisches Wurzel-Schlüsselpaar, das durch die ERCA erstellt und mithilfe des zuvor erwähnten europäischen privaten Schlüssels signiert wird.
• Bei dem EQT.Link.EUR-Zertifikat handelt es sich um das europäische Wurzelzertifikat, das in der CAR des EQT.Link-Zertifikats angegeben ist.

CSM_235 Zur Berechnung des Hashwerts M, der im Befehl PSO:Hash an die Kontrollkarte gesendet wird, verwendet das IDE den Hash-Algorithmus, der mit der Schlüsselgröße der VU oder der Karte, von der die Daten heruntergeladen werden, verlinkt ist (siehe CSM_50).

CSM_236 Bei der Verifizierung der Signatur des Geräts folgt die Kontrollkarte dem in DSS definierten Signatursystem.

Das vorliegende Dokument spezifiziert keinerlei Maßnahmen für den Fall, dass die Signatur über eine heruntergeladene Datei nicht verifiziert werden kann oder die Verifizierung erfolglos ist.

Abbildung 13 Protokoll für die Verifizierung der Signatur mithilfe einer heruntergeladenen Datei

______

1) Es ist zu beachten, dass es sich bei den Koppelungsschlüsseln der 1., 2. und 3. Generation um denselben Schlüssel oder aber um drei verschiedene, unterschiedlich lange Schlüssel handeln kann, wie in CSM_117 erläutert.

weiter.