GEMEINSAME SICHERHEITSMECHANISMEN

INHALTSVERZEICHNIS

VORWORT TEIL A FAHRTENSCHREIBERSYSTEM DER 1. GENERATION 1. EINLEITUNG 1.1. Referenzdokumente 1.2. Notationen und Abkürzungen 2. KRYPTOGRAFISCHE SYSTEME UND ALGORITHMEN 2.1. Kryptografische Systeme 2.2. Kryptografische Algorithmen 2.2.1 RSA-Algorithmus 2.2.2 Hash-Algorithmus 2.2.3 Datenverschlüsselungsalgorithmus 3. SCHLÜSSEL UND ZERTIFIKATE 3.1. Erzeugung und Verteilung der Schlüssel 3.1.1 Erzeugung und Verteilung der RSA-Schlüssel 3.1.2 RSA-Prüfschlüssel 3.1.3 Bewegungssensorschlüssel 3.1.4 Erzeugung und Verteilung von T-DES-Sitzungsschlüsseln 3.2. Schlüssel 3.3. Zertifikate 3.3.1 Inhalt der Zertifikate 3.3.2 Ausgestellte Zertifikate 3.3.3 Verifizieren und Entpacken der Zertifikate 4. GEGENSEITIGE AUTHENTISIERUNG 5. VERTRAULICHKEITS-, INTEGRITÄTS- UND AUTHENTISIERUNGSMECHANISMEN FÜR DIE DATENÜBERTRAGUNG VU-KARTE 5.1. Secure Messaging 5.2. Behandlung von Secure-Messaging-Fehlern 5.3. Algorithmus zur Berechnung der kryptografischen Prüfsummen 5.4. Algorithmus zur Berechnung von Kryptogrammen für Vertraulichkeits-DOs 6. DIGITALE SIGNATURMECHANISMEN BEIM HERUNTERLADEN VON DATEN 6.1. Erzeugung der Signatur 6.2. Verifizierung der Signatur TEIL B FAHRTENSCHREIBERSYSTEM DER 2. GENERATION 7. EINLEITUNG 7.1. Referenzdokumente 7.2. Notationen und Abkürzungen 7.3. Begriffsbestimmungen 8. KRYPTOGRAFISCHE SYSTEME UND ALGORITHMEN 8.1. Kryptografische Systeme 8.2. Kryptografische Algorithmen 8.2.1 Symmetrische Algorithmen 8.2.2 Asymmetrische Algorithmen und standardisierte Domänenparameter 8.2.3 Hash-Algorithmen 8.2.4 Cipher Suites 9. SCHLÜSSEL UND ZERTIFIKATE 9.1. Asymmetrische Schlüsselpaare und Public-Key-Zertifikate 9.1.1 Allgemein 9.1.2 Europäische Ebene 9.1.3 Mitgliedstaatebene 9.1.4 Geräteebene: Fahrzeugeinheiten 9.1.5 Geräteebene: Fahrtenschreiberkarten 9.1.6 Geräteebene: Externe GNSS-Ausrüstung 9.1.7 Überblick Ersatz von Zertifikaten 9.2. Symmetrische Schlüssel 9.2.1 Schlüssel für die Sicherung der Kommunikation VU-Bewegungssensor 9.2.2 Schlüssel zur Sicherung der DSRC-Kommunikation 9.3. Zertifikate 9.3.1 Allgemein 9.3.2 Zertifikatsinhalt 9.3.3 Beantragen von Zertifikaten 10. GEGENSEITIGE AUTHENTISIERUNG VU-KARTE UND SECURE MESSAGING 10.1. Allgemein 10.2. Gegenseitige Verifizierung der Zertifikatkette 10.2.1 Verifizierung der Kartenzertifikatkette durch die VU 10.2.2 Verifizierung der VU-Zertifikatkette durch die Karte 10.3. VU-Authentisierung 10.4. Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels 10.5. Secure Messaging 10.5.1 Allgemein 10.5.2 Secure-Message-Struktur 10.5.3 Abbruch einer Secure-Messaging-Sitzung 11. VU UND EXTERNE GNSS-AUSRÜSTUNG: KOPPELUNG, GEGENSEITIGE AUTHENTISIERUNG UND SECURE MESSAGING 11.1. Allgemein 11.2. Koppelung von VU und externer GNSS-Ausrüstung 11.3. Gegenseitige Verifizierung der Zertifikatkette 11.3.1 Allgemein 11.3.2 Während der Koppelung VU-EGF 11.3.3 Im Normalbetrieb 11.4. VU-Authentisierung, Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels 11.5. Secure Messaging 12. KOPPELUNG UND KOMMUNIKATION VU-BEWEGUNGSSENSOR 12.1. Allgemein 12.2. Koppelung VU-Bewegungssensor unter Verwendung verschiedener Schlüsselgenerationen 12.3. Koppelung und Kommunikation VU-Bewegungssensor mit AES 12.4. Koppelung VU-Bewegungssensor bei verschiedenen Gerätegenerationen 13. SICHERHEIT FÜR FERNKOMMUNIKATION PER DSRC 13.1. Allgemein 13.2. Verschlüsselung der Fahrtenschreibernutzdaten und MAC-Generierung 13.3. Verifizierung und Entschlüsselung der Fahrtenschreibernutzdaten 14. SIGNIEREN VON DATENDOWNLOADS UND VERIFIZIEREN DER SIGNATUREN 14.1. Allgemein 14.2. Erzeugung der Signatur 14.3. Verifizierung der Signatur

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

1.

EINLEITUNG

1.1.

Referenzdokumente

In dieser Anlage werden folgende Referenzdokumente herangezogen:

SHA-1

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

PKCS1

RSA Laboratories. PKCS # 1: RSA Encryption Standard. Version 2.0. Oktober 1998.

TDES

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

TDES-OP

ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation. 1998.

ISO/IEC 7816-4

Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 4: Interindustry commands for interexchange (Informationstechnik — Identifikationskarten, mit integrierten Schaltkreisen und Kontakten — Teil 4: Interindustrielle Kommandos). Erste Ausgabe: 1995 + Änderung 1: 1997.

ISO/IEC 7816-6

Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements (Identifikationskarten — Chipkarten — Teil 6: Datenelemente für den interindustriellen Informationsaustausch.) Erste Ausgabe: 1996 + Berichtigung 1: 1998.

ISO/IEC 7816-8

Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands (Informationstechnik — Identifikationskarten, mit integrierten Schaltkreisen und Kontakten — Teil 8: Interindustrielle sicherheitsbezogene Kommandos). Erste Ausgabe 1999.

ISO/IEC 9796-2

Information Technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Mechanisms using a hash function (Informationstechnik — IT-Sicherheitsverfahren — Digitale Signaturschemata welche die Nachricht wieder herstellen — Teil 2: Mechanismen die eine dedizierte Hash Funktion verwenden). Erste Ausgabe: 1997.

ISO/IEC 9798-3

Information Technology — Security techniques — Entity authentication mechanisms — Part 3: Entity authentication using a public key algorithm (Informationstechnik — Sicherheitsverfahren — Mechanismen zur Authentifikation von Instanzen — Teil 3: Authentifikation von Instanzen unter Nutzung eines Algorithmus mit öffentlichem Schlüssel). Zweite Ausgabe 1998.

ISO 16844-3

Road vehicles — Tachograph systems — Part 3: Motion sensor interface (Straßenfahrzeuge — Fahrtenschreibersysteme — Teil 3: Bewegungssensor-Schnittstelle).

1.2.

Notationen und Abkürzungen

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

(K_a, K_b, K_c)

ein Schlüsselbund zur Verwendung durch den Triple Data Encryption Algorithm

CA

Certification Authority (Zertifizierungsstelle)

CAR

Certification Authority Reference (Referenz der Zertifizierungsstelle)

CC

Cryptographic Checksum (kryptografische Prüfsumme)

CG

Cryptogram (Kryptogramm)

CH

Command Header (Befehlskopf)

CHA

Certificate Holder Authorisation (Autorisierung des Zertifikatsinhabers)

CHR

Certificate Holder Reference (Referenz des Zertifikatsinhabers)

D()

Entschlüsselung mit DES

DE

Datenelement

DO

Datenobjekt

d

privater RSA-Schlüssel, privater Exponent

e

öffentlicher RSA-Schlüssel, öffentlicher Exponent

E()

Verschlüsselung mit DES

EQT

Equipment (Gerät)

Hash()

Hash-Wert, ein Ergebnis von Hash

Hash

Hash-Funktion

KID

Key Identifier (Schlüsselbezeichner)

Km

T-DES-Schlüssel Hauptschlüssel gemäß ISO 16844-3

Km_VU

in Fahrzeugeinheiten integrierter T-DES-Schlüssel

Km_WC

in Werkstattkarten integrierter T-DES-Schlüssel

m

Nachrichtenrepräsentant, eine ganze Zahl zwischen 0 und n-1

n

RSA-Schlüssel, Modulus

PB

Padding Bytes (Füllbytes)

PI

Padding Indicator-Byte (Verwendung im Kryptogramm für Vertraulichkeits-DO)

PV

Plain Value (Klarwert)

s

Signaturrepräsentant, eine ganze Zahl zwischen 0 und n-1

SSC

Send Sequence Counter (Sendesequenzzähler)

SM

Secure Messaging

TCBC

TDEA-Modus Cipher Block Chaining

TDEA

Triple Data Encryption Algorithm (Triple-Datenverschlüsselungsalgorithmus)

TLV

Tag Length Value (Taglängenwert)

VU

Fahrzeugeinheit (Vehicle Unit)

X.C

Zertifikat von Benutzer X, ausgestellt durch eine Zertifizierungsstelle

X.CA

Zertifizierungsstelle von Benutzer X

X.CA.PK _o X.C

Vorgang des Entpackens eines Zertifikats zur Herauslösung eines öffentlichen Schlüssels; es handelt sich um einen Infix-Operator, dessen linker Operand der öffentliche Schlüssel einer Zertifizierungsstelle und dessen rechter Operand das von der Zertifizierungsstelle ausgestellte Zertifikat ist; das Ergebnis ist der öffentliche Schlüssel von Benutzer X, dessen Zertifikat der rechte Operand ist

X.PK

öffentlicher RSA-Schlüssel eines Benutzers X

X.PK[I]

RSA-Chiffrierung einer Information I unter Verwendung des öffentlichen Schlüssels von Benutzer X

X.SK

privater RSA-Schlüssel eines Benutzers X

X.SK[I]

RSA-Chiffrierung einer Information I unter Verwendung des privaten Schlüssels von Benutzer X

„xx”

ein Hexadezimalwert

||

Verkettungsoperator

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:

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

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: Km = Km_VU XOR Km_WC. 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 Km_VU zum Einbau in die Fahrzeugeinheiten unter geeigneten Sicherheitsvorkehrungen an deren Hersteller,

—

stellen sicher, dass Km_WC bei der Personalisierung der Karten in alle Werkstattkarten eingefügt wird ( in 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 1024 Bit, öffentlicher Exponent e max. 64 Bit, privater Exponent d 1024 Bit.

CSM_015

Triple-DES-Schlüssel haben die Form (K_a, K_b, K_a), wobei K_a und K_b 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:

Daten	Format	Bytes	Bemerkung
CPI	INTEGER	1	Certificate Profile Identifier (Zertifikatsprofil „01” in dieser Version)
CAR	OCTET STRING	8	Certification Authority Reference (Referenz der Zertifizierungsstelle)
CHA	OCTET STRING	7	Certificate Holder Authorisation (Autorisierung des Zertifikatsinhabers)
EOV	TimeReal	4	Ablauf der Gültigkeit des Zertifikats, bei Nichtverwendung mit „FF” gefüllt
CHR	OCTET STRING	8	Certificate Holder Reference (Referenz des Zertifikatsinhabers)
n	OCTET STRING	128	Öffentlicher Schlüssel (Modulus)
e	OCTET STRING	8	Öffentlicher Schlüssel (öffentlicher Exponent)
		164

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:

„4D”

„16”

„5F 29”

„01”

„42”

„08”

„5F 4B”

„07”

„5F 24”

„04”

„5F 20”

„08”

„7F 49”

„05”

„81”

„81 80”

„82”

„08”

Tag für erweiterte Kopfliste

Länge der Kopfliste

CPI-Tag

CPI-Länge

CAR-Tag

CAR-Länge

CHA-Tag

CHA-Länge

EOV-Tag

EOV-Länge

CHR-Tag

CHR-Länge

Tag für öffentlichen Schlüssel (konstruiert)

Länge der folgenden DO

Modulus-Tag

Modulus-Länge

Tag für öffentlichen Exponenten

Länge des öffentlichen Exponenten

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 , „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):

Daten	Seriennummer Gerät	Datum	Art	Hersteller
Länge	4 Bytes	2 Bytes	1 Byte	1 Byte
Wert	Ganze Zahl	MM JJ BCD-Kod.	Herstellerspezifisch	Herstellercode

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:

Daten	Seriennummer Zertifikatsantrag	Datum	Art	Hersteller
Länge	4 Bytes	2 Bytes	1 Byte	1 Byte
Wert	Ganze Zahl	MM JJ BCD-Kod.	„FF”	Herstellercode

5.2

Zertifizierungsstelle:

Daten	Kennung	Seriennr. Schlüssel	Zusatzinfo	Kennung
Länge	4 Bytes	1 Byte	2 Bytes	1 Byte
Wert	1 Byte numerischer Landescode 3 Bytes alphanumerischer Landescode	Ganze Zahl	Zusatzkodierung (CA-spezifisch) „FF FF” bei Nichtverwendung	„01”

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” .

X.C = X.CA.SK[ „6A” || C_r || Hash(Cc) || „BC” ] || C_n || X.CAR

wobei Zertifikatsinhalt = Cc =	Cr	||	Cn
	106 Bytes		58 Bytes

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:

„7F 21”	„09”	„5F 37”	„81 80”	„5F 38”	„3A”	„42”	„08”
Tag für CV-Zertifikat (konstruiert)	Länge der folgenden DO	Signatur-Tag	Signatur-Länge	Rest-Tag	Restlänge	CAR-Tag	CAR-Länge

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':	X.C =	Sign	||	Cn'	||	CAR'
		128 Bytes		58 Bytes		8 Bytes

—

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' =	„6A”	||	Cr'	||	H'	||	„BC”
			106 Bytes		20 Bytes

—

Wiederherstellung des Zertifikatsinhalts C' = C_r' || C_n',

—

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:

Tag	Symbolform	Bedeutung
„81”	TPV	Klarwert, nicht in BER-TLV kodiert (durch CC zu schützen)
„97”	TLE	Wert von Le im ungesicherten Befehl (durch CC zu schützen)
„99”	TSW	Status-Info (durch CC zu schützen)
„8E”	TCC	Kryptografische Prüfsumme (CC)
„87”	TPI CG	Padding Indicator Byte || Cryptogram (Klarwert, nicht in BER-TLV kodiert)

Ausgehend von einem ungesicherten Befehl-Antwort-Paar:

Befehlskopf				Befehlskörper
CLA	INS	P1	P2	[Lc-Feld]	[Datenfeld]	[Le-Feld]
vier Bytes				L Bytes, bezeichnet als B1 bis BL

Antwortkörper	Antwortendmarke
[Datenfeld]	SW1	SW2
Lr Datenbytes	zwei Bytes

lautet das entsprechende gesicherte Befehl-Antwort-Paar:

Gesicherter Befehl:

Befehlskopf (CH)				Befehlskörper
CLA	INS	P1	P2	[Neues Lc-Feld]	[Neues Datenfeld]									[Neues Le-Feld]
„OC”				Länge des neuen Datenfelds	TPV	LPV	PV	TLE	LLE	Le	TCC	LCC	CC	„00”
					„81”	Lc	Datenfeld	„97”	„01”	Le	„8E”	„04”	CC

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:

Antwortkörper						Antwortendmarke
[Neues Datenfeld]						SW1 SW2 neu
TPV	LPV	PV	TCC	LCC	CC
„81”	Lr	Datenfeld	„8E”	„04”	CC

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:

Antwortkörper						Antwortendmarke
[Neues Datenfeld]						SW1 SW2 neu
TPI CG	LPI CG	PI CG	TCC	LCC	CC
„87”		PI || CG	„8E”	„04”	CC

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:

Antwortkörper						Antwortendmarke
[Neues Datenfeld]						SW1 SW2 neu
TSW	LSW	SW	TCC	LCC	CC
„99”	„02”	SW1 SW2 neu	„8E”	„04”	CC

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 MS_i.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 DigestInfo (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

7.

EINLEITUNG

7.1.

Referenzdokumente

Referenzdokumente zu dieser Anlage:

AES

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

DSS

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

ISO 7816-4

ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange (Identifikationskarten — Chipkarten — Teil 4 — Regeln, Sicherheitsfunktionen und Befehle für den Datenaustausch). Dritte Ausgabe 2013-04-15

ISO 7816-8

ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security operations (Identifikationskarten — Chipkarten — Teil 8 — Kommandos für Sicherheitsoperationen). Zweite Ausgabe, 2004-06-01.

ISO 8825-1

ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) (Informationstechnik — Codierungsregeln für ASN.1: Spezifikation der Basis-Codierungsregeln (BER), der Kanonischen Codierungsregeln (CER) und der Besonderen Codierungsregeln (DER)). Vierte Ausgabe, 2008-12-15.

ISO 9797-1

ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanismen using a block cipher (Informationstechnik — Sicherheitsverfahren — Message Authentication Codes (MACs) — Teil 1 — Mechanismen, die eine Blockchiffre verwenden). Zweite Ausgabe, 2011-03-01.

ISO 10116

ISO/IEC 10116, Information technology — Security techniques — Modes of operation of an n-bit block cipher (Informationstechnik — Sicherheitsverfahren — Betriebsarten für n-bit Blockchiffre). Dritte Ausgabe, 2006-02-01.

ISO 16844-3

ISO/IEC 16844-3, Road vehicles — Tachograph systems — Part 3: Motion sensor interface (Straßenfahrzeuge — Fahrtenschreibersysteme — Teil 3: Bewegungssensor-Schnittstelle). Erste Ausgabe 2004, einschließlich Technical Corrigendum 1 2006.

RFC 5480

Elliptic Curve Cryptography Subject Public Key Information, März 2009

RFC 5639

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

RFC 5869

HMAC-based Extract-and-Expand Key Derivation Function (HKDF), Mai 2010

SHS

National Institute of Standards and Technology (NIST), FIPS PUB 180-4: Secure Hash Standard, März 2012

SP 800-38B

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

TR-03111

BSI Technical Guideline TR-03111, Elliptic Curve Cryptography, Version 2.00, 28.6.2012

7.2.

Notationen und Abkürzungen

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

AES

Advanced Encryption Standard

CA

Certification Authority (Zertifizierungsstelle)

CAR

Certification Authority Reference (Referenz der Zertifizierungsstelle)

CBC

Cipher Block Chaining (Betriebsmodus)

CH

Command Header (Befehlskopf)

CHA

Certificate Holder Authorisation (Autorisierung des Zertifikatsinhabers)

CHR

Certificate Holder Reference (Referenz des Zertifikatsinhabers)

CV

Constant Vector (Konstanter Vektor)

DER

Distinguished Encoding Rules (Besondere Codierungsregeln)

DO

Datenobjekt

DSRC

Dedicated Short Range Communication (Dedizierte Nahbereichskommunikation)

ECC

Elliptic Curve Cryptography (Elliptische-Kurven-Kryptografie)

ECDSA

Elliptic Curve Digital Signature Algorithm (auf elliptischen Kurven basierender Algorithmus für digitale Signaturen)

ECDH

Elliptic Curve Diffie-Hellman (Diffie-Hellman-Schlüsselaustausch)

EGF

External GNSS Facility (Externe GNSS-Ausrüstung)

EQT

Equipment (Gerät)

IDE

Intelligent Dedicated Equipment

K_M

Bewegungssensor-Hauptschlüssel, ermöglicht die Koppelung einer Fahrzeugeinheit mit einem Bewegungssensor

K_M-VU

In Fahrzeugeinheiten eingesetzter Schlüssel, der es einer VU gestattet, den Bewegungssensor-Hauptschlüssel abzuleiten, wenn eine Werkstattkarte in die VU eingesetzt ist

K_M-VC

In Werkstattkarten eingesetzter Schlüssel, der es einer VU gestattet, den Bewegungssensor-Hauptschlüssel abzuleiten, wenn eine Werkstattkarte in die VU eingesetzt ist

MAC

Message Authentication Code

MoS

Bewegungssensor

MSB

Most Significant Bit (höchstwertige Bitposition)

PKI

Public Key Infrastructure (Public-Key-Infrastruktur)

RCF

Remote Communication Facility (Ausrüstung zur Fernkommunikation)

SSC

Send Sequence Counter (Sendesequenzzähler)

SM

Secure Messaging

TDES

Triple Data Encryption Standard (Triple-Datenverschlüsselungsstandard)

TLV

Tag Length Value (Taglängenwert)

VU

Fahrzeugeinheit (Vehicle Unit, VU)

X.C

Zertifikat des öffentlichen Schlüssels von Benutzer X

X.CA

Zertifizierungsstelle, die das Zertifikat von Benutzer X ausgestellt hat

X.CA

die im Zertifikat von Benutzer X erwähnte Referenz der Zertifizierungsstelle

X.CA

die im Zertifikat von Benutzer X erwähnte Referenz des Zertifikatsinhabers

X.PK

öffentlicher Schlüssel von Benutzer X

X.SK

privater Schlüssel von Benutzer X

X.PK_eph

flüchtiger öffentlicher Schlüssel von Benutzer X

X.SK_eph

flüchtiger privater Schlüssel von Benutzer X

„xx”

ein Hexadezimalwert

||

Verkettungsoperator

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

Name	Größe (Bits)	Referenzdokument	Objektkennung
NIST P-256	256	[DSS], [RFC 5480]
BrainpoolP256r1	256	[RFC 5639]
NIST P-384	384	[DSS], [RFC 5480]
BrainpoolP384r1	384	[RFC 5639]
BrainpoolP512r1	512	[RFC 5639]
NIST P-521	521	[DSS], [RFC 5480]

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

Kennung der Cipher Suite	ECC-Schlüsselgröße (Bits)	AES-Schlüssellänge (Bits)	Hash-Algorithmus	MAC-Länge (Bytes)
CS#1	256	128	SHA-256	8
CS#2	384	192	SHA-384	12
CS#3	512/521	256	SHA-512	16

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:

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

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

Schlüssel	Symbol	Generiert durch	Generierungsmethode	Gespeichert durch
Bewegungssensor-Hauptschlüssel — VU-Teil	KM-VU	ERCA	Zufall	ERCA, an der Ausgabe von VU-Zertifikaten beteiligte MSCA, VU-Hersteller, Fahrzeugeinheiten
Bewegungssensor-Hauptschlüssel — Werkstattteil	KM-WC	ERCA	Zufall	ERCA, MSCA, Kartenhersteller, Werkstattkarten
Bewegungssensor-Hauptschlüssel	KM	Nicht unabhängig generiert	Berechnet als KM = KM-VU XOR KM-WC	ERCA, an der Ausgabe von Bewegungssensor-Schlüsseln beteiligte MSCA (fakultativ)(*)
Identifikationsschlüssel	KID	Nicht unabhängig generiert	Berechnet als KID = KM XOR CV (CV angegeben in CSM_106)	ERCA, an der Ausgabe von Bewegungssensor-Schlüsseln beteiligte MSCA (fakultativ)(*)
Koppelungsschlüssel	KP	Hersteller von Bewegungssensoren	Zufall	Ein Bewegungssensor
Sitzungsschlüssel	KS	VU (während der Koppelung von VU und Bewegungssensor)	Zufall	Eine VU und ein 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 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 6A 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).

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.

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

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 .

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 KM_DSRC 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 KM_DSRC 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.

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.

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 KM_DSRC-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 65535 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.

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.

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.

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).

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.

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 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 aufweisen. Wenn sie ihm nicht bekannt ist, muss Certificate Holder Reference den in Anlage 1 angegebenen Datentyp 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 aufweisen.

CSM_148

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

CSM_149

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

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 )

—

den alphanumerischen Landescode der Zertifizierungsstelle (der in Anlage 1 definierte Datentyp )

—

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 () 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.

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).

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.PK_eph) 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

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

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 N_PICC und leitet mit dieser zwei AES-Sitzungsschlüssel K_MAC und K_ENC von K ab. Siehe CSM_179.

6.

Mithilfe von K_MAC 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.PKeph) 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 N_PICC 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 K_ENC 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

Datenobjektname	Tag	Vorgeschrieben (V), an Bedingungen geknüpft (B) oder untersagt (U) in
		Befehlen	Antworten
Klarwert, nicht in BER-TLV kodiert	„81”	B	B
Klarwert, in BER-TLV kodiert, jedoch ohne SM DO	„B3”	B	B
Padding Indicator, gefolgt von Kryptogramm, Klarwert nicht in BER-TLV kodiert	„87”	B	B
Geschütztes Le	„97”	B	U
Verarbeitungsstatus	„99”	U	V
Kryptografische Prüfsumme (CC)	„8E”	V	V

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 32768 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 65535 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.

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.

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 liest die VU die 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.

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 K_S 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 Datenbytes pro Befehl gemäß ISO 16844-3

Anweisung	Anforderung/Antwort	Beschreibung der Daten	Anz. der Klartext-Datenbytes gemäß ISO 16844-3	Anz. der Klartext-Datenbytes bei Verwendung von AES-Schlüsseln	Anz. der verschlüsselten Datenbytes bei Verwendung von AES-Schlüsseln mit Bitlänge
					128	192	256
10	Anforderung	Authentisierungsdaten + Nummer der Datei	8	8	16	16	16
11	Antwort	Authentisierungsdaten + Inhalte der Datei	16 oder 32, je nach Datei	16 oder 32, je nach Datei	32/48	32/48	32/48
41	Anforderung	Seriennummer des Sensors	8	8	16	16	16
41	Antwort	Koppelungsschlüssel	16	16/24/32	16	32	32
42	Anforderung	Sitzungsschlüssel	16	16/24/32	16	32	32
43	Anforderung	Koppelungsinformation	24	24	32	32	32
50	Antwort	Koppelungsinformation	24	24	32	32	32
70	Anforderung	Authentisierungsdaten	8	8	16	16	16
80	Antwort	Zählerwert Bewegungssensor + Authentisierungsdaten	8	8	16	16	16

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 -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:

Current date time

aktuelles Datum und aktuelle Uhrzeit der Fahrzeugeinheit (Datentyp )

Counter

ein 3-Byte-Zähler, siehe CSM_225

VU serial number

die Seriennummer der VU oder die Kennung für den Zertifikatsantrag (Datentyp VuSerialNumber oder CertificateRequestID) — siehe CSM_123

DSRC master key version number

die 1-Byte-Versionsnummer des DSRC-Hauptschlüssels, von dem die VU-spezifischen DSRC-Schlüssel abgeleitet wurden, siehe Abschnitt 9.2.2.

MAC

der mithilfe aller vorausgehenden Bytes in den RTM-Daten berechnete MAC

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 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

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_VU_DSRC_ENC und K_VU_DSRC_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