SPEZIFIKATION DER FAHRTENSCHREIBERKARTEN

INHALTSVERZEICHNIS

1. EINLEITUNG 1.1. Abkürzungen 1.2. Referenzdokumente 2. ELEKTRISCHE UND PHYSIKALISCHE EIGENSCHAFTEN 2.1. Versorgungsspannung und Stromverbrauch 2.2. Programmierspannung V_pp 2.3. Taktversorgung und -frequenz 2.4. E/A-Kontakt 2.5. Kartenzustände 3. HARDWARE UND DATENAUSTAUSCH 3.1. Einleitung 3.2. Übertragungsprotokoll 3.2.1 Protokolle 3.2.2 ATR 3.2.3 PTS 3.3. Zugriffsregeln 3.4. Befehle und Fehlercodes — Übersicht 3.5. Beschreibung der Befehle 3.5.1 SELECT 3.5.2 READ BINARY 3.5.3 UPDATE BINARY 3.5.4 GET CHALLENGE 3.5.5 VERIFY 3.5.6 GET RESPONSE 3.5.7 PSO: VERIFY CERTIFICATE 3.5.8 INTERNAL AUTHENTICATE 3.5.9 EXTERNAL AUTHENTICATE 3.5.10 GENERAL AUTHENTICATE 3.5.11 MANAGE SECURITY ENVIRONMENT 3.5.12 PSO: HASH 3.5.13 PERFORM HASH of FILE 3.5.14 PSO: COMPUTE DIGITAL SIGNATURE 3.5.15 PSO: VERIFY DIGITAL SIGNATURE 3.5.16 PROCESS DSRC MESSAGE 4. STRUKTUR DER FAHRTENSCHREIBERKARTEN 4.1. Wurzelverzeichnis (MF) 4.2. Fahrerkartenanwendungen 4.2.1 Fahrerkartenanwendung der 1. Generation 4.2.2 Fahrerkartenanwendung der 2. Generation 4.3. Werkstattkartenanwendungen 4.3.1 Werkstattkartenanwendung der 1. Generation 4.3.2 Werkstattkartenanwendung der 2. Generation 4.4. Kontrollkartenanwendungen 4.4.1 Kontrollkartenanwendung der 1. Generation 4.4.2 Kontrollkartenanwendung der 2. Generation 4.5. Unternehmenskartenanwendungen 4.5.1 Unternehmenskartenanwendung der 1. Generation 4.5.2 Unternehmenskartenanwendung der 2. Generation

1.

EINLEITUNG

1.1.

Abkürzungen

Im Sinne dieser Anlage gelten folgende Abkürzungen.

AC

Access conditions (Zugriffsbedingungen)

AES

Advanced Encryption Standard

AID

Application Identifier (Anwendungskennung)

ALW

Always (immer)

APDU

Application Protocol Data Unit (Befehlsstruktur)

ATR

Aswer To Reset (Antwort auf Zurücksetzen)

AUT

Authenticated (authentisiert)

C6, C7

Kontakte Nr. 6 und 7 der Karte laut Beschreibung in ISO/IEC 7816-2

cc

Taktgeberzyklen

CHA

Certificate Holder Authorisation (Autorisierung des Zertifikatsinhabers)

CHV

Card holder Verification Information (Information zur Überprüfung des Karteninhabers)

CLA

Klassenbyte eines APDU-Befehls

DO

Datenobjekt

DSRC

Dedicated Short Range Communication (Dedizierte Nahbereichskommunikation)

DF

Dedicated File (Verzeichnis). Ein DF kann andere Dateien enthalten (EF oder DF)

ECC

Elliptic Curve Cryptography (Elliptische-Kurven-Kryptografie)

EF

Elementary File (Elementardatei)

etu

elementary time unit (Elementarzeiteinheit)

G1

1. Generation

G2

2. Generation

IC

Integrated Circuit (Integrierter Schaltkreis)

ICC

Integrated Circuit Card (Chipkarte)

ID

Identifier (Bezeichner, Kennung)

IFD

Interface Device (Schnittstellengerät, Kartenterminal)

IFS

Information Field Size (Informationsfeldgröße)

IFSC

Informationsfeldgröße der Karte

IFSD

Informationsfeldgröße des Schnittstellengeräts, Terminals

INS

Befehlsbyte eines APDU-Befehls

Lc

Länge der Eingabedaten für einen APDU-Befehl

Le

Länge der erwarteten Daten (Ausgabedaten für einen Befehl)

MF

Master File (Wurzel-DF)

NAD

Knotenadresse, verwendet im Protokoll T=1

NEV

Never (nie)

P1-P2

Parameterbytes

PIN

Persönliche Geheimzahl (Personal Identification Number)

PRO SM

Mit Secure Messaging geschützt

PTS

Protocol Transmission Selection (Auswahl der Protokollübertragung)

RFU

Reserved for Future Use (für künftige Anwendungen reserviert)

RST

Zurücksetzen (der Karte)

SFID

Kurz-Elementardateikennung

SM

Secure Messaging

SW1-SW2

Statusbytes

TS

ATR-Anfangszeichen

VPP

Programmierspannung

VU

Fahrzeugeinheit

XXh

Wert XX in Hexadezimalnotation

„XXh”

Wert XX in Hexadezimalnotation

||

Verkettungssymbol 03||04=0304

1.2.

Referenzdokumente

In dieser Anlage werden folgende Referenzdokumente herangezogen:

ISO/IEC 7816-2

Identification cards — Integrated circuit cards — Part 2: Dimensions and location of the contacts. ISO/IEC 7816-2:2007.

ISO/IEC 7816-3

Identification cards — Integrated circuit cards — Part 3: Electrical interface and transmission protocols. ISO/IEC 7816-3:2006.

ISO/IEC 7816-4

Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange. ISO/IEC 7816-4:2013 + Berichtigung 1: 2014.

ISO/IEC 7816-6

Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for interchange. ISO/IEC 7816-6:2004 + Cor 1: 2006.

ISO/IEC 7816-8

Identification cards — Integrated circuit cards — Part 8: Commands for security operations. ISO/IEC 7816-8:2004.

ISO/IEC 9797-2

Information technology — Security techniques — Message Authentication Codes (MACs) — Part 2: Mechanisms using a dedicated hash-function. ISO/IEC 9797-2:2011

2.

ELEKTRISCHE UND PHYSIKALISCHE EIGENSCHAFTEN

TCS_01

Sofern nicht anderweitig spezifiziert, erfüllen alle elektronischen Signale die Norm ISO/IEC 7816-3.

TCS_02

Maße und Anordnung der Kartenkontakte erfüllen die Norm ISO/IEC 7816-2.

2.1.

Versorgungsspannung und Stromverbrauch

TCS_03

Die Karte arbeitet gemäß Spezifikation innerhalb der Grenzen für die Leistungsaufnahme nach ISO/IEC 7816-3.

TCS_04

Die Karte arbeitet mit Vcc = 3 V (± 0,3 V) oder mit Vcc = 5 V (± 0,5 V).

Die Spannungswahl erfolgt gemäß ISO/IEC 7816-3.

2.2.

Programmierspannung V_pp

TCS_05

Die Karte benötigt am Kontakt C6 keine Programmierspannung. Es wird davon ausgegangen, dass Kontakt C6 in einem Schnittstellengerät nicht angeschlossen ist. Der Kontakt C6 kann an V_cc auf der Karte angeschlossen sein, aber nicht an Masse. Auf jeden Fall ist diese Spannung nicht zu interpretieren.

2.3.

Taktversorgung und -frequenz

TCS_06

Die Karte arbeitet im Frequenzbereich von 1 bis 5 MHz und kann unter Umständen höhere Frequenzen unterstützen. Innerhalb eines Kartenvorgangs darf die Taktfrequenz um ± 2 % schwanken. Die Taktfrequenz wird von der Fahrzeugeinheit und nicht von der Karte selbst erzeugt. Für den Arbeitszyklus ist eine Schwankung zwischen 40 und 60 % zulässig.

TCS_07

Unter den in der Kartendatei EF ICC enthaltenen Bedingungen kann der externe Taktgeber angehalten werden. Das erste Byte des Hauptteils der EF ICC-Datei kodiert die Bedingungen für den Clockstop-Modus:

L-Pegel	H-Pegel
Bit 3	Bit 2	Bit 1
0	0	1	Clockstop zulässig, kein Vorzugspegel
0	1	1	Clockstop zulässig, Vorzugspegel: H
1	0	1	Clockstop zulässig, Vorzugspegel: L
0	0	0	Clockstop nicht zulässig
0	1	0	Clockstop nur bei H-Pegel zulässig
1	0	0	Clockstop nur bei L-Pegel zulässig

Bits 4 bis 8 werden nicht genutzt.

2.4.

E/A-Kontakt

TCS_08

Der E/A-Kontakt C7 wird für den Empfang von Daten vom Schnittstellengerät und das Senden von Daten zum Schnittstellengerät verwendet. Während des Betriebs befindet sich entweder die Karte oder das Schnittstellengerät im Sendemodus. Sollten sich beide Einheiten im Sendemodus befinden, darf die Karte dadurch nicht beschädigt werden. Sofern die Karte nicht sendet, tritt sie in den Empfangsmodus.

2.5.

Kartenzustände

TCS_09

Bei angelegter Versorgungsspannung arbeitet die Karte in zwei Zuständen:

im Betriebszustand während der Ausführung von Befehlen oder während der Verbindung zur Fahrzeugeinheit,

im Ruhezustand zu allen anderen Zeiten; in diesem Zustand bleiben alle Daten auf der Karte erhalten.

3.

HARDWARE UND DATENAUSTAUSCH

3.1.

Einleitung

Dieser Abschnitt beschreibt die für die Fahrtenschreiberkarten und Fahrzeugeinheit (VU) erforderliche Mindestfunktionalität, mit der ein korrekter Betrieb und Interoperabilität gewährleistet werden. Fahrtenschreiberkarten erfüllen so weit wie möglich die geltenden ISO/IEC-Normen (insbesondere ISO/IEC 7816). Befehle und Protokolle werden jedoch vollständig beschrieben, um gegebenenfalls bestimmte eingeschränkte Verwendungen oder Unterschiede herauszustellen. Die spezifizierten Befehle entsprechen, sofern nicht anders angegeben, in vollem Umfang den angeführten Normen.

3.2.

Übertragungsprotokoll

TCS_10

Das Übertragungsprotokoll entspricht den Festlegungen von ISO/IEC 7816-3 für T = 0 und T = 1. Insbesondere erkennt die VU von der Karte gesendete Wartezeitverlängerungen.

3.2.1

Protokolle

TCS_11

Die Karte unterstützt sowohl Protokoll T=0 als auch Protokoll T=1. Darüber hinaus kann die Karte weitere kontaktorientierte Protokolle unterstützen.

TCS_12

T=0 ist das Standardprotokoll; zum Wechsel auf das Protokoll T=1 ist daher ein PTS-Befehl erforderlich.

TCS_13

Die Geräte unterstützen in beiden Protokollen die direct convention, die somit für die Karte obligatorisch ist.

TCS_14

Das Byte für die Informationsfeldgröße der Karte wird im ATR im Zeichen TA3 dargestellt. Dieser Wert beträgt mindestens „F0h” (= 240 Bytes).

Für die Protokolle gelten die folgenden Einschränkungen:

TCS_15

T=0

—

Das Schnittstellengerät unterstützt eine Antwort bei E/A nach der ansteigenden Flanke des Signals bei RST von 400 cc.

—

Das Schnittstellengerät muss Zeichen im Abstand von 12 etu lesen können.

—

Das Schnittstellengerät liest ein fehlerhaftes Zeichen und dessen Wiederholung, wenn der Abstand 13 etu beträgt. Wird ein fehlerhaftes Zeichen festgestellt, kann das Fehlersignal bei E/A zwischen 1 etu und 2 etu auftreten. Das Gerät unterstützt eine Verzögerung von 1 etu.

—

Das Schnittstellengerät akzeptiert ein ATR von 33 Bytes (TS+32).

—

Befindet sich TC1 im ATR, ist für vom Schnittstellengerät gesendete Zeichen die Extra Guard Time vorhanden, obwohl von der Karte gesendete Zeichen weiterhin mit 12 etu getrennt werden können. Dies gilt auch für das von der Karte gesendete ACK-Zeichen nach Aussendung eines P3-Zeichens vom Schnittstellengerät.

—

Das Schnittstellengerät berücksichtigt ein von der Karte ausgesendetes NUL-Zeichen.

—

Das Schnittstellengerät akzeptiert den Ergänzungsmodus für ACK.

—

Der Befehl GET RESPONSE kann im Verkettungsmodus nicht zum Einholen von Daten verwendet werden, deren Länge 255 Bytes übersteigen könnte.

TCS_16

T=1

—

NAD-Byte: nicht verwendet (NAD ist auf „00” gesetzt).

—

S-Block ABORT: nicht verwendet.

—

S-Block VPP-Zustandsfehler: nicht verwendet.

—

Die Gesamtverkettungslänge für ein Datenfeld darf 255 Bytes (vom Schnittstellengerät abzusichern) nicht übersteigen.

—

Die Information Field Size Device (IFSD) wird vom Schnittstellengerät unmittelbar nach dem ATR angezeigt: Das Schnittstellengerät überträgt die S-Block IFS-Anforderung nach dem ATR, und die Karte sendet S-Block IFS zurück. Der empfohlene Wert für IFSD ist 254 Bytes.

—

Die Karte fordert keine IFS-Nachkorrektur an.

3.2.2

ATR

TCS_17

Das Gerät überprüft ATR-Bytes gemäß ISO/IEC 7816-3. Es erfolgt keine Überprüfung von historischen ATR-Zeichen.

Beispiel für ein Zweiprotokoll-Basis-ATR gemäß ISO/IEC 7816-3

Zeichen	Wert	Bemerkungen
TS	„3Bh”	Anzeiger für „direct convention” .
T0	„85h”	TD1 vorhanden; 5 historische Bytes vorhanden
TD1	„80h”	TD2 vorhanden; T=0 verwenden
TD2	„11h”	TA3 vorhanden; T=1 verwenden
TA3	„XXh” (mind. „F0h” )	Informationsfeldgröße der Karte (IFSC)
TH1 bis TH5	„XXh”	Historische Zeichen
TCK	„XXh”	Prüfzeichen (ohne OR)

TCS_18

Nach der Antwort auf das Zurücksetzen (ATR) wird das Wurzelverzeichnis (MF) implizit ausgewählt und zum aktuellen Verzeichnis.

3.2.3

PTS

TCS_19

Das Standardprotokoll ist T=0. Zur Einstellung des Protokolls T=1 muss ein PTS (auch PPS genannt) vom Gerät gesendet werden.

TCS_20

Da für die Karte beide Protokolle, T=0 und T=1, obligatorisch sind, ist das Basis-PTS für die Protokollumschaltung ebenfalls obligatorisch.

Wie in ISO/IEC 7816-3 angegeben, kann das PTS zur Umschaltung auf höhere Übertragungsraten als die von der Karte im ATR vorgeschlagene Geschwindigkeit verwendet werden (TA(1) Byte).

Höhere Übertragungsraten sind für die Karte fakultativ.

TCS_21

Wird keine andere Übertragungsrate als die Standardgeschwindigkeit unterstützt (oder wird die ausgewählte Übertragungsrate nicht unterstützt), antwortet die Karte auf das PTS korrekt gemäß ISO/IEC 7816-3 durch Weglassen des PPS1-Byte.

Beispiele für ein Basis-PTS zur Protokollwahl:

Zeichen	Wert	Bemerkungen
PPSS	„FFh”	Startzeichen
PPS0	„00h” oder „01h”	PPS1 bis PPS3 nicht vorhanden; „00h” zur Auswahl von T0, „01h” zur Auswahl von T1.
PK	„XXh”	Prüfzeichen: „XXh” = „FFh” wenn PPS0 = „00h” , „XXh” = „FEh” wenn PPS0 = „01h” ,

3.3.

Zugriffsregeln

TCS_22

Eine Zugriffsregel legt für einen Zugriffsmodus, d. h. Befehl, die zugehörigen Sicherheitsbedingungen fest. Sind diese Sicherheitsbedingungen erfüllt, wird der entsprechende Befehl verarbeitet.

TCS_23

Für die Fahrtenschreiberkarte werden folgende Sicherheitsbedingungen genutzt:

Abkürzung	Bedeutung
ALW	Die Aktion ist immer möglich und kann ohne Einschränkung ausgeführt werden. Befehls- und Antwort-APDU werden als Klartext übermittelt, d. h. ohne Secure Messaging.
NEV	Die Aktion ist nie möglich.
PLAIN-C	Die Befehls-APDU werden als Klartext übermittelt, d. h. ohne Secure Messaging.
PWD	Die Aktion wird nur ausgeführt, wenn die PIN der Werkstattkarte erfolgreich verifiziert wurde, d. h. der interne Sicherheitsstatus der Karte auf „PIN_Verified” gesetzt ist. Der Befehl muss ohne Secure Messaging übertragen werden.
EXT-AUT-G1	Die Aktion kann nur ausgeführt werden, wenn der Befehl External Authenticate für die Authentisierung der 1. Generation (siehe auch Anlage 11 Teil A) erfolgreich ausgeführt wurde.
SM-MAC-G1	Die (Befehls- und Antwort-) APDU muss mit Secure Messaging der 1. Generation im reinen Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil A).
SM-C-MAC-G1	Die (Befehls-)APDU muss mit Secure Messaging der 1. Generation im reinen Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil A).
SM-R-ENC-G1	Die Antwort-APDU muss mit Secure Messaging der 1. Generation im Verschlüsselungsmodus angewandt werden (siehe Anlage 11 Teil A), d. h. so, dass kein Code für die Nachrichtenauthentisierung zurückgesendet wird.
SM-R-ENC-MAC-G1	Die (Antwort-) APDU muss mit Secure Messaging der 1. Generation im Verschlüsselungs-dann-Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil A).
SM-MAC-G2	Die (Befehls- und Antwort-) APDU muss mit Secure Messaging der 2. Generation im reinen Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil B).
SM-C-MAC-G2	Die (Befehls-) APDU muss mit Secure Messaging der 2. Generation im reinen Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil B).
SM-R-ENC-MAC-G2	Die (Antwort-) APDU muss mit Secure Messaging der 2. Generation im Verschlüsselungs-dann-Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil B).

TCS_24

Diese Sicherheitsbedingungen können folgendermaßen verknüpft werden:

AND:

Alle Sicherheitsbedingungen müssen erfüllt sein.

OR:

Mindestens eine Sicherheitsbedingung muss erfüllt sein.

Die Zugriffsregeln für das Dateisystem, d. h., die Befehle SELECT, READ BINARY und UPDATE BINARY sind in Kapitel 4 spezifiziert. Die Zugriffsregeln für die verbleibenden Befehle sind in den folgenden Tabellen beschrieben. Der Ausdruck „Nicht zutreffend” wird verwendet, wenn der Befehl von keiner Randnummer unterstützt wird. Der Befehl kann dann gegebenenfalls unterstützt werden, aber die Zugriffsbedingung ist nicht anwendbar.

TCS_25

In der Anwendung DF Tachograph der 1. Generation kommen folgende Zugriffsregeln zum Einsatz:

Befehl	Fahrerkarte	Werkstattkarte	Kontrollkarte	Unternehmenskarte
External Authenticate
— Zur Authentisierung für die 1. Generation	ALW	ALW	ALW	ALW
— Zur Authentisierung für die 2. Generation	ALW	PWD	ALW	ALW
Internal Authenticate	ALW	PWD	ALW	ALW
General Authenticate	ALW	ALW	ALW	ALW
Get Challenge	ALW	ALW	ALW	ALW
MSE:SET AT	ALW	ALW	ALW	ALW
MSE:SET DST	ALW	ALW	ALW	ALW
Process DSRC Message	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
PSO: Compute Digital Signature	ALW OR SM-MAC-G2	ALW OR SM-MAC-G2	Nicht zutreffend	Nicht zutreffend
PSO: Hash	Nicht zutreffend	Nicht zutreffend	ALW	Nicht zutreffend
PERFORM HASH OF FILE	ALW OR SM-MAC-G2	ALW OR SM-MAC-G2	Nicht zutreffend	Nicht zutreffend
PSO: Verify Certificate	ALW	ALW	ALW	ALW
PSO: Verify Digital Signature	Nicht zutreffend	Nicht zutreffend	ALW	Nicht zutreffend
Verify	Nicht zutreffend	ALW	Nicht zutreffend	Nicht zutreffend

TCS_26

In der Anwendung DF Tachograph der 2. Generation kommen folgende Zugriffsregeln zum Einsatz:

Befehl	Fahrerkarte	Werkstattkarte	Kontrollkarte	Unternehmenskarte
External Authenticate
— Zur Authentisierung für die 1. Generation	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
— Zur Authentisierung für die 2. Generation	ALW	PWD	ALW	ALW
Internal Authenticate	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
General Authenticate	ALW	ALW	ALW	ALW
Get Challenge	ALW	ALW	ALW	ALW
MSE:SET AT	ALW	ALW	ALW	ALW
MSE:SET DST	ALW	ALW	ALW	ALW
Process DSRC Message	Nicht zutreffend	ALW	ALW	Nicht zutreffend
PSO: Compute Digital Signature	ALW OR SM-MAC-G2	ALW OR SM-MAC-G2	Nicht zutreffend	Nicht zutreffend
PSO: Hash	Nicht zutreffend	Nicht zutreffend	ALW	Nicht zutreffend
PERFORM HASH OF FILE	ALW OR SM-MAC-G2	ALW OR SM-MAC-G2	Nicht zutreffend	Nicht zutreffend
PSO: Verify Certificate	ALW	ALW	ALW	ALW
PSO: Verify Digital Signature	Nicht zutreffend	Nicht zutreffend	ALW	Nicht zutreffend
Verify	Nicht zutreffend	ALW	Nicht zutreffend	Nicht zutreffend

TCS_27

In MF kommen folgende Zugriffsregeln zum Einsatz:

Befehl	Fahrerkarte	Werkstattkarte	Kontrollkarte	Unternehmenskarte
External Authenticate
— Zur Authentisierung für die 1. Generation	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
— Zur Authentisierung für die 2. Generation	ALW	PWD	ALW	ALW
Internal Authenticate	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
General Authenticate	ALW	ALW	ALW	ALW
Get Challenge	ALW	ALW	ALW	ALW
MSE:SET AT	ALW	ALW	ALW	ALW
MSE:SET DST	ALW	ALW	ALW	ALW
Process DSRC Message	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
PSO: Compute Digital Signature	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
PSO: Hash	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
PERFORM HASH OF FILE	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
PSO: Verify Certificate	ALW	ALW	ALW	ALW
PSO: Verify Digital Signature	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
Verify	Nicht zutreffend	ALW	Nicht zutreffend	Nicht zutreffend

TCS_28

Eine Fahrtenschreiberkarte kann unter Umständen Befehle eines Sicherheitsniveaus akzeptieren, das über dem in den Sicherheitsbedingungen festgelegten Niveau liegt, d. h. bei den Sicherheitsbedingungen ALW (oder PLAIN-C) kann die Karte Befehle mit Secure Messaging (Verschlüsselungs- und/oder Authentisierungsmodus) akzeptieren. Falls die Sicherheitsbedingungen Secure Messaging mit Authentisierungsmodus voraussetzen, kann die Fahrtenschreiberkarte Befehle mit Secure Messaging der gleichen Generation im Authentisierungs- und Verschlüsselungsmodus akzeptieren.

Hinweis: Die Beschreibung der Befehle liefert weitere Informationen zur Unterstützung der Befehle für die verschiedenen Fahrtenschreiberkartentypen und DF.

3.4.

Befehle und Fehlercodes — Übersicht

Befehle und Dateiorganisation sind von der ISO/IEC 7816-4 abgeleitet und erfüllen diese Norm. Dieser Abschnitt beschreibt die folgenden APDU-Befehl-Antwort-Paare. Die durch die Anwendungen der 1. und 2. Generation unterstützten Befehlsvarianten sind in der zugehörigen Befehlsbeschreibung angegeben.

Befehl	INS
SELECT	„A4h”
READ BINARY	„B0h” , „B1h”
UPDATE BINARY	„D6h” , „D7h”
GET CHALLENGE	„84h”
VERIFY	„20h”
GET RESPONSE	„C0h”
PERFORM SECURITY OPERATION	„2Ah”
— VERIFY CERTIFICATE
— COMPUTE DIGITAL SIGNATURE
— VERIFY DIGITAL SIGNATURE
— HASH
— PERFORM HASH OF FILE
— PROCESS DSRC MESSAGE
INTERNAL AUTHENTICATE	„88h”
EXTERNAL AUTHENTICATE	„82h”
MANAGE SECURITY ENVIRONMENT	„22h”
— SET DIGITAL SIGNATURE TEMPLATE
— SET AUTHENTICATION TEMPLATE
GENERAL AUTHENTICATE	„86h”

TCS_29

In jeder Antwortnachricht werden die Statusbytes SW1 SW2 zurückgesendet, die den Verarbeitungszustand des Befehls bezeichnen.

SW1	SW2	Bedeutung
90	00	Normale Verarbeitung
61	XX	Normale Verarbeitung XX = Zahl der verfügbaren Antwortbytes
62	81	Verarbeitungswarnung. Ein Teil der zurückgesendeten Daten kann beschädigt sein.
63	00	Authentisierung fehlgeschlagen (Warnung)
63	CX	Falsche CHV (PIN). Zähler für verbleibende Versuche „X” .
64	00	Ausführungsfehler — Zustand des nichtflüchtigen Speichers unverändert. Integritätsfehler.
65	00	Ausführungsfehler — Zustand des nichtflüchtigen Speichers verändert.
65	81	Ausführungsfehler — Zustand des nichtflüchtigen Speichers verändert – Speicherfehler.
66	88	Sicherheitsfehler: falsche kryptografische Prüfsumme (bei Secure Messaging) oder falsches Zertifikat (bei Zertifikatsverifizierung) oder falsches Kryptogramm (bei externer Authentisierung) oder falsche Signatur (bei Signaturverifizierung)
67	00	Falsche Länge (falsche Lc oder Le)
68	83	Letzter Befehl der Kette erwartet
69	00	Verbotener Befehl (keine Antwort verfügbar in T=0)
69	82	Sicherheitsstatus nicht erfüllt
69	83	Authentisierungsverfahren blockiert
69	85	Nutzungsbedingungen nicht erfüllt
69	86	Befehl nicht zulässig (keine aktuelle EF)
69	87	Erwartete Secure-Messaging-Datenobjekte fehlen
69	88	Inkorrekte Secure-Messaging-Datenobjekte
6A	80	Falsche Parameter im Datenfeld
6A	82	Datei nicht gefunden
6A	86	Falsche Parameter P1-P2
6A	88	Bezugsdaten nicht gefunden
6B	00	Falsche Parameter (Offset außerhalb der EF)
6C	XX	Falsche Länge, SW2 gibt die genaue Länge an. Kein Datenfeld wird zurückgesendet
6D	00	Befehlscode nicht unterstützt oder ungültig
6E	00	Klasse nicht unterstützt
6F	00	— Sonstige Prüffehler

Weitere in ISO/IEC 7816-4 definierte Statusbytes können zurückgesendet werden, wenn ihr Verhalten in dieser Anlage nicht ausdrücklich erwähnt wird.

Zum Beispiel können die folgenden Statusbytes optional zurückgesendet werden:

6881: Logischer Kanal nicht unterstützt

6882: Secure Messaging nicht unterstützt

TCS_30

Erfüllt ein einzelner APDU-Befehl mehr als eine Fehlerbedingung, kann die Karte beliebige der zugehörigen Statusbytes zurücksenden.

3.5.

Beschreibung der Befehle

In diesem Kapitel werden die obligatorischen Befehle für die Fahrtenschreiberkarten beschrieben. Weitere sachdienliche Einzelheiten zu kryptografischen Operationen sind in Anlage 11, Gemeinsame Sicherheitsmechanismen für Fahrtenschreiber der 1. und 2. Generation, aufgeführt. Alle Befehle werden unabhängig vom verwendeten Protokoll (T=0 oder T=1) beschrieben. Die APDU-Bytes CLA, INS, P1, P2, Lc und Le werden immer angegeben. Wird Lc oder Le für den beschriebenen Befehl nicht benötigt, bleiben die entsprechende Länge, der Wert und die Beschreibung leer.

TCS_31

Werden beide Längenbytes (Lc und Le) angefordert, ist der Befehl in zwei Teile aufzuspalten, wenn das IFD das Protokoll T=0 verwendet: Das IFD sendet den Befehl wie beschrieben mit P3=Lc + Daten und sendet dann einen GET RESPONSE-Befehl (siehe Abschnitt 3.5.6) bei P3=Le.

TCS_32

Wenn beide Längenbytes angefordert werden und wenn Le=0 (Secure Messaging) gilt Folgendes:

—

Bei Verwendung von Protokoll T=1 antwortet die Karte auf Le=0 mit dem Senden aller verfügbaren Ausgabedaten.

—

Bei Verwendung von Protokoll T=0 sendet das IFD den ersten Befehl mit P3=Lc + Daten und die Karte antwortet auf dieses implizierte Le=0 mit den Statusbytes 61La, wobei La die Anzahl der verfügbaren Antwortbytes ist. Daraufhin generiert das IFD einen GET RESPONSE-Befehl mit P3=La zum Lesen der Daten.

TCS_33

Optional kann eine Fahrtenschreiberkarte erweiterte Längenfelder gemäß ISO/IEC 7816-4 unterstützen. Eine Fahrtenschreiberkarte, die erweiterte Längenfelder unterstützt,

—

gibt die Unterstützung erweiterter Längenfelder in der ATR an

—

gibt die unterstützten Puffergrößen durch erweiterte Längenangabe in der EF ATR/INFO an, siehe TCS_146

—

gibt die Unterstützung erweiterter Längenfelder für T = 1 und/oder T = 0 in der EF Extended Length an, siehe TCS_147

—

unterstützt erweiterte Längenfelder für die Fahrtenschreiberanwendung der 1. und 2. Generation.

Hinweise:

Sämtliche Befehle sind für kurze Längenfelder spezifiziert. Die Verwendung von APDU erweiterter Länge ergibt sich aus ISO/IEC 7816-4.

Generell sind die Befehle für den Klarmodus spezifiziert, d. h. ohne Secure Messaging, da die Secure-Messaging-Schicht in Anlage 11 beschrieben wird. Aus den Zugriffsregeln für einen Befehl ergibt sich, ob der Befehl Secure Messaging unterstützt und ob sich die Unterstützung auf Secure Messaging der 1. und/oder 2. Generation bezieht. Einige Befehlsvarianten werden mit Secure Messaging beschrieben, um die Verwendung dieser Funktion zu veranschaulichen.

TCS_34

Die VU führt für eine Sitzung das gesamte Protokoll zur gegenseitigen Authentisierung von VU der 2. Generation und Karte aus, einschließlich (erforderlichenfalls) der Zertifikatsverifizierung entweder im DF Tachograph, dem DF Tachograph_G2 oder in MF.

3.5.1

SELECT

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt. Der Befehl SELECT wird verwendet:

—

zur Auswahl eines Applikations-DF (Auswahl nach Namen obligatorisch)

—

zur Auswahl einer Elementardatei, die der vorgelegten Datei-ID entspricht.

3.5.1.1

Auswahl nach Namen (AID)

Dieser Befehl ermöglicht die Auswahl eines Applikations-DF auf der Karte.

TCS_35

Dieser Befehl kann von jeder beliebigen Stelle in der Dateistruktur aus ausgeführt werden (nach dem ATR oder jederzeit).

TCS_36

Bei Auswahl einer Anwendung wird die derzeitige Sicherheitsumgebung zurückgesetzt. Nach Auswahl der Anwendung wird kein aktueller öffentlicher Schlüssel mehr ausgewählt. Die Zugriffsbedingung EXT-AUT-G1 geht ebenfalls verloren. Wurde der Befehl ohne Secure Messaging ausgeführt, stehen die früheren Sitzungsschlüssel nicht mehr für das Secure Messaging zur Verfügung.

TCS_37

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„A4h”
P1	1	„04h”	Auswahl nach Namen (AID)
P2	1	„0Ch”	Keine Antwort erwartet
Lc	1	„NNh”	Anzahl der an die Karte gesendeten Bytes (Länge der AID): „06h” für die Fahrtenschreiberanwendung
#6-#(5+NN)	NN	„XX..XXh”	AID: „FF 54 41 43 48 4F” für die Fahrtenschreiberanwendung der 1. Generation AID: „FF 53 4D 52 44 54” für die Fahrtenschreiberanwendung der 2. Generation

Es wird keine Antwort auf den Befehl SELECT benötigt (Le fehlt in T=1 oder keine Antwort angefordert in T=0).

TCS_38

Antwortnachricht (keine Antwort angefordert)

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wird die der AID entsprechende Anwendung nicht gefunden, lautet der zurückgesendete Verarbeitungsstatus 6A82.

—

Bei Vorhandensein des Byte Le lautet in T=1 der zurückgesendete Status 6700.

—

Wenn nach dem Befehl SELECT eine Antwort angefordert wird, lautet in T=0 der zurückgesendete Status 6900.

—

Wird die ausgewählte Anwendung als verfälscht betrachtet (weil in den Dateiattributen ein Integritätsfehler festgestellt wurde), lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6500.

3.5.1.2

Auswahl einer Elementardatei anhand ihrer Dateikennung

TCS_39

Befehlsnachricht

TCS_40

Die Fahrtenschreiberkarte muss Secure Messaging der 2. Generation gemäß Anlage 11 Teil B für diese Befehlsvarianten unterstützen.

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„A4h”
P1	1	„02h”	Auswahl einer EF unter dem aktuellen DF
P2	1	„0Ch”	Keine Antwort erwartet
Lc	1	„02h”	Anzahl der an die Karte gesendeten Bytes
#6-#7	2	„XXXXh”	Dateikennung

Es wird keine Antwort auf den Befehl SELECT benötigt (Le fehlt in T=1 oder keine Antwort angefordert in T=0).

TCS_41

Antwortnachricht (keine Antwort angefordert)

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wird die der Dateikennung entsprechende Datei nicht gefunden, lautet der zurückgesendete Verarbeitungsstatus 6A82.

—

Bei Vorhandensein des Byte Le lautet in T=1 der zurückgesendete Status 6700.

—

Wenn nach dem Befehl SELECT eine Antwort angefordert wird, lautet in T=0 der zurückgesendete Status 6900.

—

Wird die ausgewählte Datei als verfälscht betrachtet (weil in den Dateiattributen ein Integritätsfehler festgestellt wurde), lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6500.

3.5.2

READ BINARY

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt. Der Befehl READ BINARY wird zum Auslesen von Daten aus einer transparenten Datei verwendet. Die Antwort der Karte besteht im Zurücksenden der gelesenen Daten, die optional in einer Secure-Messaging-Struktur eingekapselt werden können.

3.5.2.1

Befehl mit Offset in P1-P2

Dieser Befehl ermöglicht dem IFD das Lesen von Daten aus der zu dem entsprechenden Zeitpunkt ausgewählten EF ohne Secure Messaging.

Hinweis: Dieser Befehl ohne Secure Messaging kann nur genutzt werden, um eine Datei auszulesen, die die ALW-Sicherheitsbedingung für den Lese-Zugriffsmodus unterstützt.

TCS_42

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„B0h”	Read Binary
P1	1	„XXh”	Offset in Bytes vom Dateianfang: höchstwertiges Byte
P2	1	„XXh”	Offset in Bytes vom Dateianfang: niedrigstwertiges Byte
Le	1	„XXh”	Erwartete Datenlänge. Anzahl der zu lesenden Bytes.

Hinweis: Bit 8 von P1 muss auf 0 gesetzt sein.

TCS_43

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#X	X	„XX..XXh”	Gelesene Daten
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist keine EF ausgewählt, lautet der zurückgesendete Verarbeitungsstatus 6986.

—

Sind die Sicherheitsbedingungen der ausgewählten Datei nicht erfüllt, wird der Befehl mit 6982 abgebrochen.

—

Ist das Offset nicht mit der Größe der EF kompatibel (Offset > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6B00.

—

Ist die Größe der auszulesenden Daten nicht mit der Größe der EF kompatibel (Offset + Le > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6700 oder 6Cxx, wobei „xx” die genaue Länge angibt.

—

Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet 6400 oder 6500.

—

Wird in den gespeicherten Daten ein Integritätsfehler festgestellt, so gibt die Karte die angeforderten Daten aus und der zurückgesendete Verarbeitungsstatus lautet 6281.

Dieser Befehl ermöglicht dem IFD das Lesen von Daten aus der zu dem entsprechenden Zeitpunkt ausgewählten EF mit Secure Messaging, um die Integrität der empfangenen Daten zu überprüfen und die Vertraulichkeit der Daten bei als verschlüsselt gekennzeichneter SM-R-ENC-MAC-G1 (1. Generation) oder SM-R-ENC-MAC-G2 (2. Generation) zu schützen.

TCS_44

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„0Ch”	Secure Messaging angefordert
INS	1	„B0h”	Read Binary
P1	1	„XXh”	P1 (Offset in Bytes vom Dateianfang): höchstwertiges Byte
P2	1	„XXh”	P2 (Offset in Bytes vom Dateianfang): niedrigstwertiges Byte
Lc	1	„XXh”	Länge der Eingabedaten für Secure Messaging
#6	1	„97h”	TLE: Tag zur Spezifikation der erwarteten Länge
#7	1	„01h”	LLE: Erwartete Länge
#8	1	„NNh”	Spezifikation der erwarteten Länge (Original Le): Anzahl der zu lesenden Bytes
#9	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#10	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „04h” für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A) „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#11-#(10+L)	L	„XX..XXh”	Kryptografische Prüfsumme
Le	1	„00h”	Gemäß ISO/IEC 7816-4

TCS_45

Antwortnachricht, wenn SM-R-ENC-MAC-G1 (1. Generation)/SM-R-ENC-MAC-G2 (2. Generation) nicht erforderlich und Secure-Messaging-Eingabeformat korrekt:

Byte	Länge	Wert	Beschreibung
#1	1	„81h”	TPV: Tag für Klarwertdaten
#2	L	„NNh” oder ‚81 NNh‘	LPV: Länge der zurückgesendeten Daten (= Original Le). L gleich 2 Bytes, wenn LPV > 127 Bytes
#(2+L) - #(1+L+NN)	NN	„XX..XXh”	Klardatenwert
#(2+L+NN)	1	„99h”	Tag für Verarbeitungsstatus (SW1-SW2) — optional für Secure Messaging der 1. Generation
#(3+L+NN)	1	„02h”	Länge des Verarbeitungsstatus — optional für Secure Messaging der 1. Generation
#(4+L+NN) - #(5+L+NN)	2	„XX XXh”	Verarbeitungsstatus der ungeschützten APDU-Antwort — optional für Secure Messaging der 1. Generation
#(6+L+NN)	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#(7+L+NN)	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „04h” für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A) „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#(8+L+NN) - #(7+M+L+NN)	M	„XX..XXh”	Kryptografische Prüfsumme
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

TCS_46

Antwortnachricht, wenn SM-R-ENC-MAC-G1 (1. Generation)/SM-R-ENC-MAC-G2 (2. Generation) erforderlich und Secure-Messaging-Eingabeformat korrekt:

Byte	Länge	Wert	Beschreibung
#1	1	„87h”	TPI CG: Tag für verschlüsselte Daten (Kryptogramm)
#2	L	„MMh” oder ‚81 MMh‘	LPI CG: Länge der zurückgesendeten verschlüsselten Daten (wegen Auffüllung anders als Original-Le des Befehls). L gleich 2 Bytes, wenn LPI CG > 127 Bytes.
#(2+L)-#(1+L+MM)	MM	„01XX..XXh”	Verschlüsselte Daten: Auffüllindikator und Kryptogramm
#(2+L+MM)	1	„99h”	Tag für Verarbeitungsstatus (SW1-SW2) — optional für Secure Messaging der 1. Generation
#(3+L+MM)	1	„02h”	Länge des Verarbeitungsstatus — optional für Secure Messaging der 1. Generation
#(4+L+MM) - #(5+L+MM)	2	„XX XXh”	Verarbeitungsstatus der ungeschützten APDU-Antwort – optional für Secure Messaging der 1. Generation
#(6+L+MM)	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#(7+L+MM)	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „04h” für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A) „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#(8+L+MM) - #(7+N+L+MM)	N	„XX..XXh”	Kryptografische Prüfsumme
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

Der Befehl READ BINARY kann die regulären Verarbeitungszustände, die in TCS_43 unter Tag „99h” aufgelistet und in TCS_59 beschrieben sind, mittels Secure-Messaging-Antwortstruktur zurücksenden.

Darüber hinaus können einige Fehler speziell im Zusammenhang mit Secure Messaging auftreten. In diesem Fall wird der Verarbeitungsstatus einfach ohne Secure-Messaging-Struktur zurückgesendet:

TCS_47

Antwortnachricht bei inkorrektem Secure-Messaging-Eingabeformat

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist kein aktueller Sitzungsschlüssel vorhanden, wird der Verarbeitungsstatus 6A88 zurückgesendet. Dies geschieht entweder, wenn der Sitzungsschlüssel noch nicht erzeugt wurde oder wenn seine Gültigkeit abgelaufen ist (in diesem Fall muss das IFD erneut eine gegenseitige Authentisierung durchführen, um einen neuen Sitzungsschlüssel zu setzen).

—

Wenn im Secure-Messaging-Format einige erwartete Datenobjekte (siehe oben) fehlen, wird der Verarbeitungsstatus 6987 zurückgesendet. Dieser Fehler tritt auf, wenn ein erwartetes Tag fehlt oder wenn der Befehlskörper nicht den Anforderungen entsprechend aufgebaut ist.

—

Sind Datenobjekte nicht korrekt, lautet der zurückgesendete Verarbeitungsstatus 6988. Dieser Fehler tritt auf, wenn zwar alle benötigten Tags vorhanden sind, einige Längen sich jedoch von den erwarteten unterscheiden.

—

Schlägt die Überprüfung der kryptografischen Prüfsumme fehl, lautet der zurückgesendete Verarbeitungsstatus 6688.

3.5.2.2

Befehl mit Kurz-Elementardateikennung

Mit dieser Befehlsvariante kann das IFD eine EF mithilfe einer Kurz-Elementardateikennung auswählen und Daten aus dieser EF lesen.

TCS_48

Eine Fahrtenschreiberkarte unterstützt diese Befehlsvariante für alle Elementardateien mit angegebener Kurz-Elementardateikennung. Diese Kurz-Elementardateikennungen sind in Kapitel 4 angegeben.

TCS_49

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„B0h”	Read Binary
P1	1	„XXh”	Bit 8 auf 1 gesetzt Bit 7 und 6 auf 00 gesetzt Bit 5 — 1 kodieren die Kurz-Elementardateikennung der entsprechenden EF
P2	1	„XXh”	Kodiert ein Offset von 0 bis 255 Bytes in der durch P1 angegebenen EF
Le	1	„XXh”	Erwartete Datenlänge. Anzahl der zu lesenden Bytes.

Hinweis: Die für die Fahrtenschreiberanwendung der 2. Generation verwendeten Kurz-Elementardateikennungen sind in Kapitel 4 angegeben.

Wenn P1 eine Kurz-Elementardateikennung kodiert und der Befehl erfolgreich ist, wird die angegebene EF zur derzeit ausgewählten EF (aktuelle EF).

TCS_50

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#L	L	„XX..XXh”	Gelesene Daten
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wird die der Kurz-Elementardateikennung entsprechende Datei nicht gefunden, lautet der zurückgesendete Verarbeitungsstatus 6A82.

—

Sind die Sicherheitsbedingungen der ausgewählten Dateien nicht erfüllt, wird der Befehl mit 6982 abgebrochen.

—

Ist das Offset nicht mit der Größe der EF kompatibel (Offset > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6B00.

—

Ist die Größe der auszulesenden Daten nicht mit der Größe der EF kompatibel (Offset + Le > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6700 oder 6Cxx, wobei „xx” die genaue Länge angibt.

—

Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet 6400 oder 6500.

—

Wird in den gespeicherten Daten ein Integritätsfehler festgestellt, so gibt die Karte die angeforderten Daten aus und der zurückgesendete Verarbeitungsstatus lautet 6281.

3.5.2.3

Befehl mit ungeradem Befehlsbyte

Mit dieser Befehlsvariante kann das IFD Daten aus einer EF mit 32768 Bytes oder mehr lesen.

TCS_51

Eine Fahrtenschreiberkarte, die EF mit 32768 Bytes oder mehr unterstützt, unterstützt diese Befehlsvariante für diese EF. Eine Fahrtenschreiberkarte kann diese Befehlsvariante ggf. für andere EF unterstützen, ausgenommen die EF Sensor_Installation_Data (siehe TCS_156 und TCS_160).

TCS_52

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„B1h”	Read Binary
P1	1	„00h”	Aktuelle EF
P2	1	„00h”
Lc	1	„NNh”	Lc = Länge des Datenobjekts „offset” .
#6-#(5+NN)	NN	„XX..XXh”	Datenobjekt „offset” : Tag „54h” Länge „01h” oder „02h” Wert offset
Le	1	‚XXh‘	Gemäß ISO/IEC 7816-4

Das IFD kodiert die Länge des Datenobjekts „offset” mit einer minimal möglichen Anzahl an Oktetten, d. h. bei der Verwendung des Längenbytes „01h” kodiert das IFD ein Offset zwischen 0 und 255 und bei der Verwendung des Längenbytes „02h” ein Offset zwischen 256 und 65535 Bytes.

Ist T=0, geht die Karte vom Wert Le = ‚00h‘ aus, sofern kein Secure Messaging angewandt wird.

Bei T=1 lautet der zurückgesendete Verarbeitungsstatus ‚6700‘, falls Le= ‚01h‘.

TCS_53

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#L	L	„XX..XXh”	Lesen von Daten, die in einem beliebigen Datenobjekt mit Tag „53h” eingekapselt sind.
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist keine EF ausgewählt, lautet der zurückgesendete Verarbeitungsstatus 6986.

—

Sind die Sicherheitsbedingungen der ausgewählten Dateien nicht erfüllt, wird der Befehl mit 6982 abgebrochen.

—

Ist das Offset nicht mit der Größe der EF kompatibel (Offset > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6B00.

—

Ist die Größe der auszulesenden Daten nicht mit der Größe der EF kompatibel (Offset + Le > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6700 oder 6Cxx, wobei „xx” die genaue Länge angibt.

—

Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.

—

Wird in den gespeicherten Daten ein Integritätsfehler festgestellt, so gibt die Karte die angeforderten Daten aus und der zurückgesendete Verarbeitungsstatus lautet 6281.

Im folgenden Beispiel wird die Verwendung von Secure Messaging dargestellt, wenn die Sicherheitsbedingung SM-MAC-G2 gilt.

TCS_54

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„0Ch”	Secure Messaging angefordert
INS	1	„B1h”	Read Binary
P1	1	„00h”	Aktuelle EF
P2	1	„00h”
Lc	1	„XXh”	Länge des gesicherten Datenfelds
#6	1	„B3h”	Tag für in BER-TLV kodierte Klarwertdaten
#7	1	„NNh”	LPV: Länge der übermittelten Daten
#(8)-#(7+NN)	NN	„XX..XXh”	In BER-TLV kodierte Klardaten, d. h. das Datenobjekt „offset” mit Tag „54”
#(8+NN)	1	„97h”	TLE: Tag zur Spezifikation der erwarteten Länge
#(9+NN)	1	„01h”	LLE: Erwartete Länge
#(10+NN)	1	„XXh”	Spezifikation der erwarteten Länge (Original Le): Anzahl der zu lesenden Bytes
#(11+NN)	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#(12+NN)	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#(13+NN)-#(12+M+NN)	M	„XX..XXh”	Kryptografische Prüfsumme
Le	1	„00h”	Gemäß ISO/IEC 7816-4

TCS_55

Antwortnachricht bei erfolgreichem Befehl

Byte	Länge	Wert	Beschreibung
#1	1	„B3h”	In BER-TLV kodierte Klarwertdaten
#2	L	„NNh” oder „81 NNh”	LPV: Länge der zurückgesendeten Daten (= Original Le). L gleich 2 Bytes, wenn LPV > 127 Bytes
#(2+L)-#(1+L+NN)	NN	„XX..XXh”	In BER-TLV kodierter Klarwertdaten, d. h. Lesen von Daten, die in einem beliebigen Datenobjekt mit Tag „53h” eingekapselt sind.
#(2+L+NN)	1	„99h”	Verarbeitungsstatus der ungeschützten APDU-Antwort
#(3+L+NN)	1	„02h”	Länge des Verarbeitungsstatus
#(4+L+NN) — #(5+L+NN)	2	„XX XXh”	Verarbeitungsstatus der ungeschützten APDU-Antwort
#(6+L+NN)	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#(7+L+NN)	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#(8+L+NN)-#(7+M+L+NN)	M	„XX..XXh”	Kryptografische Prüfsumme
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

3.5.3

UPDATE BINARY

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt. Die Befehlsnachricht UPDATE BINARY initiiert die Aktualisierung (erase + write) der bereits in einer EF-Binärzahl vorhandenen Bits mit den im APDU-Befehl gegebenen Bits.

3.5.3.1

Befehl mit Offset in P1-P2

Dieser Befehl ermöglicht dem IFD das Schreiben von Daten in die zu dem entsprechenden Zeitpunkt ausgewählte EF, ohne dass die Karte die Integrität der empfangenen Daten überprüft.

Hinweis: Dieser Befehl ohne Secure Messaging kann nur genutzt werden, um eine Datei zu aktualisieren, die die ALW-Sicherheitsbedingung für den Aktualisierungs-Zugriffsmodus unterstützt.

TCS_56

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„D6h”	Update Binary
P1	1	„XXh”	Offset in Bytes vom Dateianfang: höchstwertiges Byte
P2	1	„XXh”	Offset in Bytes vom Dateianfang: niedrigstwertiges Byte
Lc	1	„NNh”	Lc = Länge des zu aktualisierenden Datenobjekts. Anzahl der zu schreibenden Bytes
#6-#(5+NN)	NN	„XX..XXh”	Zu schreibende Daten

Hinweis: Bit 8 von P1 muss auf 0 gesetzt sein.

TCS_57

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist keine EF ausgewählt, lautet der zurückgesendete Verarbeitungsstatus 6986.

—

Sind die Sicherheitsbedingungen der ausgewählten Dateien nicht erfüllt, wird der Befehl mit 6982 abgebrochen.

—

Ist das Offset nicht mit der Größe der EF kompatibel (Offset > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6B00.

—

Ist die Größe der zu schreibenden Daten nicht mit der Größe der EF kompatibel (Offset + Le > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6700.

—

Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wiederherstellbar und der zurückgesendete Verarbeitungsstatus lautet 6400 oder 6500.

—

Schlägt der Schreibvorgang fehl, so lautet der zurückgesendete Verarbeitungsstatus 6581.

Dieser Befehl ermöglicht dem IFD das Schreiben von Daten in die zu dem entsprechenden Zeitpunkt ausgewählte EF, wobei die Karte die Integrität der empfangenen Daten überprüft. Da keine Vertraulichkeit erforderlich ist, werden die Daten nicht verschlüsselt.

TCS_58

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„0Ch”	Secure Messaging angefordert
INS	1	„D6h”	Update Binary
P1	1	„XXh”	Offset in Bytes vom Dateianfang: höchstwertiges Byte
P2	1	„XXh”	Offset in Bytes vom Dateianfang: niedrigstwertiges Byte
Lc	1	„XXh”	Länge des gesicherten Datenfelds
#6	1	„81h”	TPV: Tag für Klarwertdaten
#7	L	„NNh” oder „81 NNh”	LPV: Länge der übermittelten Daten. L gleich 2 Bytes, wenn LPV > 127 Bytes
#(7+L)-#(6+L+NN)	NN	„XX..XXh”	Klardatenwert (zu schreibende Daten)
#(7+L+NN)	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#(8+L+NN)	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „04h” für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A) „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#(9+L+NN)-#(8+M+L+NN)	M	„XX..XXh”	Kryptografische Prüfsumme
Le	1	„00h”	Gemäß ISO/IEC 7816-4

TCS_59

Antwortnachricht bei korrektem Secure-Messaging-Eingabeformat

Byte	Länge	Wert	Beschreibung
#1	1	„99h”	TSW: Tag für Statusbytes (durch CC zu schützen)
#2	1	„02h”	LSW: Länge der zurückgesendeten Statusbytes
#3-#4	2	„XXXXh”	Verarbeitungsstatus der ungeschützten APDU-Antwort
#5	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#6	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „04h” für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A) „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#7-#(6+L)	L	„XX..XXh”	Kryptografische Prüfsumme
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

Die für den Befehl UPDATE BINARY ohne Secure Messaging beschriebenen „regulären” Verarbeitungszustände (siehe Abschnitt 3.5.3.1) können unter Verwendung der oben aufgeführten Antwortnachrichtstrukturen zurückgesendet werden.

Darüber hinaus können einige Fehler speziell im Zusammenhang mit Secure Messaging auftreten. In diesem Fall wird der Verarbeitungsstatus einfach ohne Secure-Messaging-Struktur zurückgesendet:

TCS_60

Antwortnachricht bei Fehler im Secure Messaging

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist kein aktueller Sitzungsschlüssel vorhanden, wird der Verarbeitungsstatus 6A88 zurückgesendet.

—

Wenn im Secure-Messaging-Format einige erwartete Datenobjekte (siehe oben) fehlen, wird der Verarbeitungsstatus 6987 zurückgesendet. Dieser Fehler tritt auf, wenn ein erwartetes Tag fehlt oder wenn der Befehlskörper nicht den Anforderungen entsprechend aufgebaut ist.

—

Sind Datenobjekte nicht korrekt, lautet der zurückgesendete Verarbeitungsstatus 6988. Dieser Fehler tritt auf, wenn zwar alle benötigten Tags vorhanden sind, einige Längen sich jedoch von den erwarteten unterscheiden.

—

Schlägt die Überprüfung der kryptografischen Prüfsumme fehl, lautet der zurückgesendete Verarbeitungsstatus 6688.

3.5.3.2

Befehl mit Kurz-Elementardateikennung

Mit dieser Befehlsvariante kann das IFD eine EF mithilfe einer Kurz-Elementardateikennung auswählen und Daten aus dieser EF schreiben.

TCS_61

Eine Fahrtenschreiberkarte sollte die Befehlsvariante für alle Elementardateien mit angegebener Kurz-Elementardateikennung unterstützen. Diese Kurz-Elementardateikennungen sind in Kapitel 4 angegeben.

TCS_62

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„D6h”	Update Binary
P1	1	„XXh”	Bit 8 auf 1 gesetzt Bit 7 und 6 auf 00 gesetzt Bit 5 — 1 kodieren die Kurz-Elementardateikennung der entsprechenden EF
P2	1	„XXh”	Kodiert ein Offset von 0 bis 255 Bytes in der durch P1 angegebenen EF
Lc	1	„NNh”	Lc = Länge der zu aktualisierenden Daten. Anzahl der zu schreibenden Bytes
#6-#(5+NN)	NN	„XX..XXh”	Zu schreibende Daten

TCS_63

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

Hinweis: Die für die Fahrtenschreiberanwendung der 2. Generation verwendeten Kurz-Elementardateikennungen sind in Kapitel 4 angegeben.

Wenn P1 eine Kurz-Elementardateikennung kodiert und der Befehl erfolgreich ist, wird die angegebene EF zur derzeit ausgewählten EF (aktuelle EF).

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wird die der Kurz-Elementardateikennung entsprechende Datei nicht gefunden, lautet der zurückgesendete Verarbeitungsstatus 6A82.

—

Sind die Sicherheitsbedingungen der ausgewählten Dateien nicht erfüllt, wird der Befehl mit 6982 abgebrochen.

—

Ist das Offset nicht mit der Größe der EF kompatibel (Offset > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6B00.

—

Ist die Größe der zu schreibenden Daten nicht mit der Größe der EF kompatibel (Offset + Le > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6700.

—

Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.

—

Schlägt der Schreibvorgang fehl, so lautet der zurückgesendete Verarbeitungsstatus 6581.

3.5.3.3

Befehl mit ungeradem Befehlsbyte

Mit dieser Befehlsvariante kann das IFD Daten in eine EF mit 32768 Bytes oder mehr schreiben.

TCS_64

Eine Fahrtenschreiberkarte, die EF mit 32768 Bytes oder mehr unterstützt, unterstützt diese Befehlsvariante für diese EF. Eine Fahrtenschreiberkarte kann diese Befehlsvariante für andere EF ggf. unterstützen.

TCS_65

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„D7h”	Update Binary
P1	1	„00h”	Aktuelle EF
P2	1	„00h”
Lc	1	„NNh”	Lc Länge der Daten im Befehlsdatenfeld
#6-#(5+NN)	NN	„XX..XXh”	Datenobjekt „offset” mit Tag „54h” || Beliebiges Datenobjekt mit Tag „53h” , das die zu schreibenden Daten einkapselt

Das IFD kodiert die Länge des Datenobjekts „offset” und des beliebigen Datenobjekts mit einer minimal möglichen Anzahl an Oktetten, d. h. bei der Verwendung des Längenbytes „01h” kodiert das IFD ein Offset/eine Länge zwischen 0 und 255 und bei der Verwendung des Längenbytes „02h” ein Offset/eine Länge zwischen 256 und 65535 Bytes.

TCS_66

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist keine EF ausgewählt, lautet der zurückgesendete Verarbeitungsstatus 6986.

—

Sind die Sicherheitsbedingungen der ausgewählten Dateien nicht erfüllt, wird der Befehl mit 6982 abgebrochen.

—

Ist das Offset nicht mit der Größe der EF kompatibel (Offset > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6B00.

—

Ist die Größe der zu schreibenden Daten nicht mit der Größe der EF kompatibel (Offset + Le > EF-Größe), lautet der zurückgesendete Verarbeitungsstatus 6700.

—

Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wiederherstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.

—

Schlägt der Schreibvorgang fehl, so lautet der zurückgesendete Verarbeitungsstatus ‚6581‘.

Im folgenden Beispiel wird die Verwendung von Secure Messaging dargestellt, wenn die Sicherheitsbedingung SM-MAC-G2 gilt.

TCS_67

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„0Ch”	Secure Messaging angefordert
INS	1	„D7h”	Update Binary
P1	1	„00h”	Aktuelle EF
P2	1	„00h”
Lc	1	„XXh”	Länge des gesicherten Datenfelds
#6	1	„B3h”	Tag für in BER-TLV kodierte Klarwertdaten
#7	L	„NNh” oder „81 NNh”	LPV: Länge der übermittelten Daten. L gleich 2 Bytes, wenn LPV > 127 Bytes
#(7+L)-#(6+L+NN)	NN	„XX..XXh”	In BER-TLV kodierte Klardaten, d. h. Datenobjekt „offset” mit Tag „54h” || Beliebiges Datenobjekt mit Tag „53h” , das die zu schreibenden Daten einkapselt
#(7+L+NN)	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#(8+L+NN)	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#(9+L+NN)-#(8+M+L+NN)	M	„XX..XXh”	Kryptografische Prüfsumme
Le	1	„00h”	Gemäß ISO/IEC 7816-4

TCS_68

Antwortnachricht bei erfolgreichem Befehl

Byte	Länge	Wert	Beschreibung
#1	1	„99h”	TSW: Tag für Statusbytes (durch CC zu schützen)
#2	1	„02h”	LSW: Länge der zurückgesendeten Statusbytes
#3-#4	2	„XXXXh”	Verarbeitungsstatus der ungeschützten APDU-Antwort
#5	1	„8Eh”	TCC: Tag für kryptografische Prüfsumme
#6	1	„XXh”	LCC: Länge der folgenden kryptografischen Prüfsumme „08h” , „0Ch” oder „10h” in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)
#7-#(6+L)	L	„XX..XXh”	Kryptografische Prüfsumme
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

3.5.4

GET CHALLENGE

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt. Der Befehl GET CHALLENGE fordert die Karte zur Ausgabe einer Zufallszahl aus, damit diese in einem sicherheitsbezogenen Verfahren verwendet werden kann, bei dem ein Kryptogramm oder chiffrierte Daten an die Karte gesendet werden.

TCS_69

Die von der Karte ausgegebene Zufallszahl ist nur für den nächsten Befehl gültig, der eine an die Karte gesendete Zufallszahl verwendet.

TCS_70

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„84h”	INS
P1	1	„00h”	P1
P2	1	„00h”	P2
Le	1	„08h”	Le (Länge der erwarteten Zufallszahl).

TCS_71

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#8	8	„XX..XXh”	Zufallszahl
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Unterscheidet sich Le von „08h” , ist der Verarbeitungsstatus 6700.

—

Sind die Parameter P1-P2 inkorrekt, ist der Verarbeitungsstatus 6A86.

3.5.5

VERIFY

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt. Nur die Werkstattkarte muss diesen Befehl unterstützen. Andere Arten von Fahrtenschreiberkarten können diesen Befehl ggf. unterstützen; für diese Karten wird allerdings keine Bezugs-CHV personalisiert. Aus diesem Grund können diese Karten diesen Befehl nicht erfolgreich ausführen. Für andere Arten von Fahrtenschreiberkarten als Werkstattkarten ist dieses Verhalten, d. h. der zurückgesendete Fehlercode, beim Senden dieses Befehls nicht erforderlich. Der Befehl Verify leitet auf der Karte den Vergleich der vom Befehl gesendeten CHV (PIN)-Daten mit der auf der Karte gespeicherten Bezugs-CHV ein.

TCS_72

Die vom Benutzer eingegebene PIN muss ASCII-kodiert und durch das IFD bis zu einer Länge von 8 Byte nach rechts mit ‚FFh‘-Bytes aufgefüllt sein (siehe auch Datentyp WorkshopCardPIN in Anlage 1).

TCS_73

Die Fahrtenschreiberanwendungen der 1. und 2. Generation verwenden die gleiche Bezugs-CHV.

TCS_74

Die Fahrtenschreiberkarte überprüft, ob der Befehl richtig kodiert ist. Wenn der Befehl nicht richtig kodiert ist, darf die Karte die CHV-Werte nicht vergleichen, den Zähler für die verbleibenden CHV-Versuche nicht herabsetzen und den Sicherheitsstatus „PIN_Verified” nicht zurücksetzen, sondern muss den Befehl abbrechen. Ein Befehl ist richtig kodiert, wenn die Bytes CLA, INS, P1, P2, Lc die angegebenen Werte aufweisen, Le nicht vorhanden ist und das Befehlsdatenfeld die richtige Länge aufweist.

TCS_75

Ist der Befehl erfolgreich, wird der Zähler für die verbleibenden CHV-Versuche reinitialisiert. Der Anfangswert des Zählers für die verbleibenden CHV-Versuche ist 5. Ist der Befehl erfolgreich, setzt die Karte den internen Sicherheitsstatus auf „PIN_Verified” . Die Karte diesen Sicherheitsstatus zurücksetzen, wenn die Karte zurückgesetzt ist oder der im Befehl übertragene CHV-Code nicht mit dem gespeicherten Bezugs-CHV übereinstimmt.

Hinweis: Durch die Verwendung des gleichen Bezugs-CHV und eines globalen Sicherheitsstatus wird verhindert, dass ein Mitarbeiter der Werkstatt nach Auswahl eines anderen Fahrtenschreiberanwendung-DF die PIN neu eingeben muss.

TCS_76

Ein fehlgeschlagener Vergleich wird auf der Karte gespeichert, d. h., dass der Zähler für die verbleibenden CHV-Versuche um eins herabgesetzt wird, um die Anzahl weiterer Versuche, die Bezugs-CHV zu verwenden, zu begrenzen.

TCS_77

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„20h”	INS
P1	1	„00h”	P1
P2	1	„00h”	P2 (die verifizierte CHV ist implizit bekannt)
Lc	1	„08h”	Länge des übermittelten CHV-Codes
#6-#13	8	„XX..XXh”	CHV

TCS_78

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wird die Bezugs-CHV nicht gefunden, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Ist die CHV blockiert (der Zähler für verbleibende Versuche steht auf null), lautet der zurückgesendete Verarbeitungsstatus 6983. Wenn dieser Zustand erreicht ist, kann die CHV nie wieder erfolgreich präsentiert werden.

—

Ist der Vergleich erfolglos, wird der Zähler für die verbleibenden Versuche herabgesetzt und der Status 63CX zurückgesendet (X > 0, und X ist gleich dem Zähler für verbleibende CHV-Versuche.

—

Wird die Bezugs-CHV als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

—

Unterscheidet sich Lc von „08h” , ist der Verarbeitungsstatus 6700.

3.5.6

GET RESPONSE

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4. Dieser (nur für das Protokoll T=0 notwendige und verfügbare) Befehl wird zur Übertragung vorbereiteter Daten von der Karte zum Schnittstellengerät verwendet (wenn ein Befehl sowohl Lc als auch Le enthalten hat). Der Befehl GET RESPONSE muss sofort nach dem Befehl zur Vorbereitung der Daten ausgegeben werden, sonst gehen die Daten verloren. Nach der Ausführung des Befehls GET RESPONSE (außer bei Auftreten der Fehler 61xx oder 6Cxx, siehe unten) stehen die zuvor vorbereiteten Daten nicht mehr zur Verfügung.

TCS_79

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„C0h”
P1	1	„00h”
P2	1	„00h”
Le	1	„XXh”	Anzahl der erwarteten Bytes

TCS_80

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#X	X	„XX..XXh”	Daten
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wurden von der Karte keine Daten vorbereitet, lautet der zurückgesendete Verarbeitungsstatus 6900 oder 6F00.

—

Übersteigt Le die Anzahl der verfügbaren Bytes oder ist Le gleich null, lautet der zurückgesendete Verarbeitungsstatus 6Cxx, wobei „xx” die genaue Anzahl der verfügbaren Bytes bezeichnet. In diesem Fall stehen die vorbereiteten Daten für einen weiteren Befehl GET RESPONSE zur Verfügung.

—

Ist Le nicht null und kleiner als die Anzahl der verfügbaren Bytes, werden die angeforderten Daten normal von der Karte gesendet. Der zurückgesendete Verarbeitungsstatus lautet 61xx, wobei „xx” die Anzahl der zusätzlichen Bytes angibt, die noch für einen nachfolgenden Befehl GET RESPONSE zur Verfügung stehen.

—

Wird der Befehl nicht unterstützt (Protokoll T=1), sendet die Karte 6D00 zurück.

3.5.7

PSO: VERIFY CERTIFICATE

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt. Der Befehl VERIFY CERTIFICATE wird von der Karte zur Einholung eines öffentlichen Schlüssels von außen und zur Prüfung seiner Gültigkeit verwendet.

3.5.7.1

Befehl-Antwort-Paar der 1. Generation

TCS_81

Diese Befehlsvariante wird lediglich durch eine Fahrtenschreiberanwendung der 1. Generation unterstützt.

TCS_82

Ist der Befehl VERIFY CERTIFICATE erfolgreich, wird der öffentliche Schlüssel zur künftigen Verwendung in der Sicherheitsumgebung gespeichert. Dieser Schlüssel wird explizit zur Verwendung in sicherheitsbezogenen Befehlen (INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE oder VERIFY CERTIFICATE) durch den Befehl MSE (siehe Abschnitt 3.5.11) unter Verwendung seines Schlüsselbezeichners gesetzt.

TCS_83

Auf jeden Fall verwendet der Befehl VERIFY CERTIFICATE den zuvor vom Befehl MSE zur Eröffnung des Zertifikats ausgewählten öffentlichen Schlüssel. Dabei muss es sich um den öffentlichen Schlüssel eines Mitgliedstaates oder Europas handeln.

TCS_84

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„2Ah”	Perform Security Operation
P1	1	„00h”	P1
P2	1	„AEh”	P2: nicht BER-TLV kodierte Daten (Verkettung von Datenelementen)
Lc	1	„C2h”	Lc: Länge des Zertifikats, 194 Bytes
#6-#199	194	„XX..XXh”	Zertifikat: Verkettung von Datenelementen (gemäß Beschreibung in Anlage 11)

TCS_85

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Schlägt die Zertifikatsverifizierung fehl, lautet der zurückgesendete Verarbeitungsstatus 6688. Das Prüfungs- und Entpackungsverfahren für das Zertifikat wird für G1 und G2 in Anlage 11 beschrieben.

—

Ist kein öffentlicher Schlüssel in der Sicherheitsumgebung vorhanden, wird 6A88 zurückgesendet.

—

Wird der (zum Entpacken des Zertifikats verwendete) ausgewählte öffentliche Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

—

Nur 1. Generation: Weist der (zum Entpacken des Zertifikats verwendete) öffentliche Schlüssel ein CHA.LSB () mit einem anderen Wert als „00” auf (d. h., es ist der Schlüssel eines Mitgliedstaates oder Europas), so lautet der zurückgesendete Verarbeitungsstatus 6985.

3.5.7.2

Befehl-Antwort-Paar der 2. Generation

Je nach Kurvengröße können ECC-Zertifikate so lang sein, dass sie sich nicht in einem einzigen APDU übermitteln lassen. In einem solchen Fall muss eine Befehlsverkettung gemäß ISO/IEC 7816-4 erfolgen und das Zertifikat in zwei aufeinander folgenden PSO: Verify Certificate APDU-Befehlen übermittelt werden. Zertifikatstruktur und Domänenparameter werden in Anlage 11 definiert.

TCS_86

Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_87

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„X0h”	CLA-Byte zur Angabe einer Befehlsverkettung: „00h” als einziger oder letzter Befehl der Kette „10h” nicht als letzter Befehl einer Kette
INS	1	„2Ah”	Perform Security Operation
P1	1	„00h”
P2	1	„BEh”	Selbstbeschreibendes Zertifikat verifizieren
Lc	1	„XXh”	Länge des Befehlsdatenfelds, siehe TCS_88 und TCS_89.
#6-#5+L	L	„XX..XXh”	DER-TLV-kodierte Daten: Datenobjekt „ECC Certificate Body” als erstes Datenobjekt, verkettet mit dem Datenobjekt „ECC Certificate Signature” als zweites Datenobjekt oder als Teil dieser Verkettung. Der Tag „7F21” und die damit einhergehende Länge sind nicht zu übermitteln. Die Reihenfolge dieser Datenobjekte ist fest.

TCS_88

Für APDU mit kurzen Längenfeldern gilt Folgendes: Das IFD verwendet die Mindestanzahl an APDU, die erforderlich sind, um die Befehlsdaten zu übermitteln und die Höchstzahl an Bytes im ersten APDU-Befehl zu übermitteln. Es muss jedoch jeder Wert „Lc” bis zu 255 Bytes von der Karte unterstützt werden.

TCS_89

Für APDU mit erweiterten Längenfeldern gilt Folgendes: Passt das Zertifikat nicht in eine einzige APDU, so unterstützt die Karte die Befehlsverkettung. Das IFD verwendet die Mindestanzahl an APDU, die erforderlich sind, um die Befehlsdaten zu übermitteln und die Höchstzahl an Bytes im ersten APDU-Befehl zu übermitteln. Ist eine Verkettung erforderlich, so muss der Wert „Lc” bis zur angegebenen maximalen erweiterten Länge von der Karte unterstützt werden.

Hinweis: Gemäß Anlage 11 speichert die Karte das Zertifikat oder die relevanten Inhalte des Zertifikats und aktualisiert ihren Wert currentAuthenticatedTime.

Struktur und Statusbytes der Antwortnachricht entsprechen der Definition in TCS_85.

TCS_90

Zusätzlich zu den in TCS_85 aufgeführten Fehlercodes kann die Karte die folgenden Fehlercodes zurücksenden:

—

Weist der (zum Entpacken des Zertifikats verwendete) ausgewählte öffentliche Schlüssel einen CHA.LSB (CertificateHolderAuthorisation.equipmentType) auf, der nicht für die Verifizierung des Zertifikats gemäß Anlage 11 geeignet ist, lautet der zurückgesendete Verarbeitungsstatus 6985.

—

Weist der Wert currentAuthenticatedTime der Karte einen späteren Zeitpunkt als das Ablaufdatum des Zertifikats auf, lautet der zurückgesendete Verarbeitungsstatus 6985.

—

Wird der letzte Befehl der Kette erwartet, sendet die Karte 6883 zurück.

—

Werden im Befehlsdatenfeld falsche Parameter gesendet, sendet die Karte 6A80 zurück (wird auch verwendet, wenn die Datenobjekte nicht in der festgelegten Reihenfolge gesendet werden).

3.5.8

INTERNAL AUTHENTICATE

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4.

TCS_91

Alle Fahrtenschreiberkarten müssen diesen Befehl in DF Tachograph der 1. Generation verwenden. Der Befehl kann in MF und/oder DF Tachograph_G2 gegebenenfalls zur Verfügung stehen. In einem solchen Fall muss der Befehl mit einem geeigneten Fehlercode enden, da der private Schlüssel der Karte (Card.SK) für das Authentisierungsprotokoll der 1. Generation nur in DF_Tachograph der 1. Generation zugreifbar ist.

Mit Hilfe des Befehls INTERNAL AUTHENTICATE kann das IFD die Karte authentisieren. Der Authentisierungsvorgang wird in Anlage 11 beschrieben. Er beinhaltet folgende Aussagen:

TCS_92

Der Befehl INTERNAL AUTHENTICATE verwendet den (implizit ausgewählten) privaten Kartenschlüssel zum Signieren von Authentisierungsdaten einschließlich K1 (erstes Element für die Sitzungsschlüsselvereinbarung) und RND1 und verwendet den aktuell (durch den letzten MSE-Befehl) ausgewählten öffentlichen Schlüssel zur Verschlüsselung der Signatur und zur Bildung des Authentisierungstokens (nähere Angaben in Anlage 11).

TCS_93

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”	CLA
INS	1	„88h”	INS
P1	1	„00h”	P1
P2	1	„00h”	P2
Lc	1	„10h”	Länge der an die Karte gesendeten Daten
#6 — #13	8	„XX..XXh”	Zur Authentisierung der Karte verwendete Zufallszahl
#14 -#21	8	„XX..XXh”	VU.CHR (siehe Anlage 11)
Le	1	„80h”	Länge der von der Karte erwarteten Daten

TCS_94

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#128	128	„XX..XXh”	Token zur Authentisierung der Karte (siehe Anlage 11)
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist in der Sicherheitsumgebung kein öffentlicher Schlüssel vorhanden, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Ist in der Sicherheitsumgebung kein privater Schlüssel vorhanden, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Stimmt VU.CHR nicht mit dem aktuellen Bezeichner des öffentlichen Schlüssels überein, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Wird der ausgewählte private Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

TCS_95

Ist der Befehl INTERNAL AUTHENTICATE erfolgreich, wird der aktuelle Sitzungsschlüssel der 1. Generation, sofern vorhanden, gelöscht und ist nicht mehr verfügbar. Um einen neuen Sitzungsschlüssel der 1. Generation zur Verfügung zu haben, muss der Befehl EXTERNAL AUTHENTICATE für den Authentisierungsmechanismus der 1. Generation erfolgreich ausgeführt werden.

Hinweis:

Für Sitzungsschlüssel der 2. Generation siehe Anlage 11 CSM_193 und CSM_195. Werden Sitzungsschlüssel der 2. Generation erstellt und erhält die Fahrtenschreiberkarte den APDU-Klartextbefehl INTERNAL AUTHENTICATE, bricht sie die Secure-Messaging-Sitzung der 2. Generation ab und vernichtet die Sitzungsschlüssel der 2. Generation.

3.5.9

EXTERNAL AUTHENTICATE

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4. Mit Hilfe des Befehls EXTERNAL AUTHENTICATE kann die Karte das IFD authentisieren. Das Authentisierungsverfahren wird in Anlage 11 für die Fahrtenschreiber der 1. und 2. Generation beschrieben (VU-Authentisierung).

TCS_96

Die Befehlsvariante für den Mechanismus zur gegenseitigen Authentisierung der 1. Generation wird nur von einer Fahrtenschreiberanwendung der 1. Generation unterstützt.

TCS_97

Die Befehlsvariante für die gegenseitige VU-Karten-Authentisierung der 2. Generation kann in MF, DF Tachograph und DF Tachograph_G2 erfolgen (siehe auch TCS_34). Ist der Befehl EXTERNAL AUTHENTICATE der 2. Generation erfolgreich, wird der aktuelle Sitzungsschlüssel der 1. Generation, sofern vorhanden, gelöscht und ist nicht mehr verfügbar.

Hinweis:

Für Sitzungsschlüssel der 2. Generation siehe Anlage 11 CSM_193 und CSM_195. Werden Sitzungsschlüssel der 2. Generation erstellt und erhält die Fahrtenschreiberkarte den APDU-Klartextbefehl EXTERNAL AUTHENTICATE, bricht sie die Secure-Messaging-Sitzung der 2. Generation ab und vernichtet die Sitzungsschlüssel der 2. Generation.

TCS_98

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”	CLA
INS	1	„82h”	INS
P1	1	„00h”	Schlüssel und Algorithmen implizit bekannt
P2	1	„00h”
Lc	1	„XXh”	Lc (Länge der an die Karte gesendeten Daten)
#6-#(5+L)	L	„XX..XXh”	Authentisierung der 1. Generation: Kryptogramm (siehe Anlage 11 Teil A) Authentisierung der 2 Generation: Vom IFD erstellte Signatur (siehe Anlage 11 Teil B)

TCS_99

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist die CHA des derzeit gesetzten Schlüssels nicht die Verkettung der AID der Fahrtenschreiberanwendung und eines VU-Gerätetyps, lautet der zurückgesendete Verarbeitungsstatus 6F00.

—

Geht dem Befehl nicht unmittelbar ein GET CHALLENGE-Befehl voraus, lautet der zurückgesendete Verarbeitungsstatus 6985.

Die Fahrtenschreiberanwendung der 1. Generation kann gegebenenfalls die folgenden Fehlercodes zurücksenden:

—

Ist kein öffentlicher Schlüssel in der Sicherheitsumgebung vorhanden, wird 6A88 zurückgesendet.

—

Ist in der Sicherheitsumgebung kein privater Schlüssel vorhanden, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Schlägt die Prüfung des Kryptogramms fehl, lautet der zurückgesendete Verarbeitungsstatus 6688.

—

Wird der ausgewählte private Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

Die Befehlsvariante für die Authentisierung der 2. Generation kann gegebenenfalls die folgenden Fehlercodes zurücksenden:

—

Schlägt die Verifizierung der Signatur fehl, sendet die Karte 6300 zurück.

3.5.10

GENERAL AUTHENTICATE

Dieser Befehl wird für das Chip-Authentisierungsprotokoll der 2. Generation gemäß Anlage 11 Teil B verwendet und entspricht den Festlegungen von ISO/IEC 7816-4.

TCS_100

Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_101

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„86h”
P1	1	„00h”	Schlüssel und Protokoll implizit bekannt
P2	1	„00h”
Lc	1	„NNh”	Lc: Länge des folgenden Datenfelds
#6-#(5+L)	L	„7Ch” + L7C + „80h” + L80 + „XX..XXh”	DER-TLV-kodierter Wert des flüchtigen öffentlichen Schlüssels (siehe Anlage 11) Die VU sendet die Datenobjekte in dieser Reihenfolge.
Le	1	„00h”	Gemäß ISO/IEC 7816-4

TCS_102

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#L	L	„7Ch” + L7C + „81h” + „08h” + „XX..XXh” + „82h” + L82 + „XX..XXh”	DER-TLV-kodierte Dynamic Authentication Data: Nonce und Authentisierungstoken (siehe Anlage 11)
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Bei falschen Parametern im Datenfeld sendet die Karte 6A80 zurück.

—

Wurde der Befehl External Authenticate nicht erfolgreich ausgeführt, sendet die Karte 6982 zurück.

Das Datenobjekt Dynamic Authentication — 7Chv

—

muss bei erfolgreicher Ausführung vorhanden sein, d. h. die Statusbytes lauten 9000,

—

muss bei einem Ausführungs- oder Prüffehler fehlen, d. h. wenn die Statusbytes im Bereich 6400 — 6FFF liegen, und

—

muss bei einer Warnung fehlen, d. h. wenn die Statusbytes im Bereich 6200 — 63FF liegen.

3.5.11

MANAGE SECURITY ENVIRONMENT

Dieser Befehl wird zum Setzen eines öffentlichen Schlüssels zu Authentisierungszwecken verwendet.

3.5.11.1

Befehl-Antwort-Paar der 1. Generation

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.

TCS_103

Dieser Befehl wird lediglich durch eine Fahrtenschreiberanwendung der 1. Generation unterstützt.

TCS_104

Der Schlüssel, auf den im MSE-Datenfeld verwiesen wird, bleibt der aktuelle öffentliche Schlüssel, bis der nächste korrekte MSE-Befehl eingeht, ein DF ausgewählt wird oder die Karte zurückgesetzt wird.

TCS_105

Ist der Schlüssel, auf den verwiesen wird, (noch) nicht in der Karte vorhanden, bleibt die Sicherheitsumgebung unverändert.

TCS_106

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”	CLA
INS	1	„22h”	INS
P1	1	„C1h”	P1: Schlüssel, auf den verwiesen wird, gültig für alle kryptografischen Operationen
P2	1	„B6h”	P2 (mit Verweis versehene Daten zur digitalen Signatur)
Lc	1	„0Ah”	Lc: Länge des folgenden Datenfelds
#6	1	„83h”	Tag zum Verweis auf einen öffentlichen Schlüssel in asymmetrischen Fällen
#7	1	„08h”	Länge des Schlüsselverweises (Schlüsselbezeichner)
#8-#15	8	„XX..XXh”	Schlüsselbezeichner laut Anlage 11

TCS_107

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Ist der Schlüssel, auf den verwiesen wird, auf der Karte nicht vorhanden, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Fehlen einige erwartete Datenobjekte im Secure-Messaging-Format, wird 6987 zurückgesendet. Dies kann der Fall sein, wenn der Tag „83h” fehlt.

—

Sind einige Datenobjekte inkorrekt, lautet der zurückgesendete Verarbeitungsstatus 6988. Dies kann der Fall sein, wenn der Schlüsselbezeichner nicht „08h” ist.

—

Wird der ausgewählte Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

3.5.11.2

Befehl-Antwort-Paare der 2. Generation

Für die Authentisierung der 2. Generation unterstützt die Fahrtenschreiberkarte folgenden MSE: Befehlsvarianten zum Setzen, die den Festlegungen von ISO/IEC 7816-4 entsprechen. Diese Befehlsvarianten werden bei der Authentisierung der 1. Generation nicht unterstützt. Mit Hilfe des folgenden Befehls MSE:SET AT werden die Parameter für die Chip-Authentisierung ausgewählt, die durch einen nachfolgenden Befehl General Authenticate durchgeführt wird.

TCS_108

Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_109

MSE:SET AT Befehlsnachricht für die Chip-Authentisierung

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„22h”
P1	1	„41h”	Zur internen Authentisierung gesetzt
P2	1	„A4h”	Authentisierung
Lc	1	„NNh”	Lc: Länge des folgenden Datenfelds
#6-#(5+L)	L	„80h” + 0Ah + „XX..XXh”	DER-TLV-kodierter Verweis zu kryptografischen Mechanismen: Objektkennung der Chip-Authentisierung (nur Wert, Tag „06h” wird weggelassen). Für die Werte der Objektkennungen siehe Anlage 1; es wird die Byte-Notation verwendet. Anleitungen zur Auswahl einer dieser Objektkennungen befinden sich in Anlage 11.

Mit Hilfe des folgenden Befehls MSE:SET AT werden die Parameter und Schlüssel für die VU-Authentisierung ausgewählt, die durch einen nachfolgenden Befehl External Authenticate durchgeführt wird.

TCS_110

Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_111

MSE:SET AT Befehlsnachricht für die VU-Authentisierung

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„22h”
P1	1	„81h”	Zur externen Authentisierung gesetzt
P2	1	„A4h”	Authentisierung
Lc	1	„NNh”	Lc: Länge des folgenden Datenfelds
#6-#(5+L)	L	„80h” + 0Ah + „XX..XXh”	DER-TLV-kodierter Verweis zu kryptografischen Mechanismen: Objektkennung der VU-Authentisierung (nur Wert, Tag „06h” wird weggelassen). Für die Werte der Objektkennungen siehe Anlage 1; es wird die Byte-Notation verwendet. Anleitungen zur Auswahl einer dieser Objektkennungen befinden sich in Anlage 11.
		„83h” + 08h + „XX..XXh”	DER-TLV-kodierter Verweis auf den öffentlichen Schlüssel der FE durch die im Zertifikat erwähnte Referenz des Zertifikatinhabers.
		„91h” + L91 + „XX..XXh”	DER-TLV-kodierte komprimierte Darstellung des flüchtigen öffentlichen Schlüssels der VU, die während der Chip-Authentisierung verwendet wird (siehe Anlage 11)

Der folgende Befehls MSE:SET AT wird verwendet, um einen öffentlichen Schlüssel entweder

—

zur Verifizierung einer Signatur, die in einem nachfolgenden Befehl PSO: Verify Digital Signature bereitgestellt wird, oder

—

zur Verifizierung der Signatur eines Zertifikats, das in einem nachfolgenden Befehl PSO: Verify Certificate bereitgestellt wird, zu setzen.

TCS_112

Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_33.

TCS_113

MSE:SET DST Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”
INS	1	„22h”
P1	1	„81h”	Zur Verifizierung gesetzt
P2	1	„B6h”	Digitale Signatur
Lc	1	„NNh”	Lc: Länge des folgenden Datenfelds
#6-#(5+L)	L	„83h” + „08h” + „XX...XXh”	DER-TLV-kodierter Verweis auf einen öffentlichen Schlüssel, d. h. die Referenz des Zertifikatinhabers im Zertifikat eines öffentlichen Schlüssels (siehe Anlage 11)

Für sämtliche Befehlsversionen werden Struktur und Statusbytes der Antwortnachricht bereitgestellt durch:

TCS_114

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück. Das Protokoll wurde ausgewählt und initialisiert.

—

6A80 kennzeichnet fehlerhafte Parameter im Befehlsdatenfeld.

—

6A88 gibt an, dass Daten, auf die verwiesen wird (d. h. ein Schlüssel, auf den verwiesen wird), nicht verfügbar sind.

—

Weist der Wert currentAuthenticatedTime der Karte einen späteren Zeitpunkt als das Ablaufdatum des ausgewählten öffentlichen Schlüssels auf, lautet der zurückgesendete Verarbeitungsstatus ‚6A88‘.

Hinweis:

Im Fall eines Befehls MSE:SET AT für die VU-Authentisierung ist der Schlüssel, auf den verwiesen wird, ein öffentlicher VU_MA-Schlüssel. Die Karte legt, falls in ihrem Speicher vorhanden, den öffentlichen VU_MA-Schlüssel für die Nutzung fest, der der im Befehlsdatenfeld angegebenen Referenz des Zertifikatinhabers (Certificate Holder Reference, CHR) entspricht (die Karte kann öffentliche VU_MA-Schlüssel anhand des CHA-Felds des Zertifikats identifizieren). Die Karte sendet ‚6A 88‘ auf diesen Befehl zurück, falls nur der öffentliche Schlüssel VU_Sign oder kein öffentlicher Schlüssel der Fahrzeugeinheit verfügbar ist. Siehe die Definition des CHA-Felds in Anlage 11 sowie des Datentyps EquipmentType in Anlage 1.

Ebenso ist der Schlüssel, auf den verwiesen wird, immer ein EQT_Sign-Schlüssel, der für die Verifizierung einer digitalen Signatur zu verwenden ist, wenn ein Befehl MSE: SET DST, der auf ein Gerät (EQT) (d. h. auf eine Fahrzeugeinheit oder Karte) verweist, an eine Kontrollkarte gesendet wird. Nach Anlage 11 Abbildung 13 hat die Kontrollkarte den relevanten öffentlichen Schlüssel EQT_Sign immer gespeichert. In manchen Fällen kann die Kontrollkarte auch den entsprechenden öffentlichen Schlüssel EQT_MA gespeichert haben. Die Kontrollkarte muss den zu verwendenden öffentlichen Schlüssel EQT_Sign immer festlegen, wenn sie einen Befehl MSE: SET DST erhält.

3.5.12

PSO: HASH

Dieser Befehl dient dazu, Ergebnisse der Hashwertberechnung für bestimmte Daten an die Karte zu übertragen. Dieser Befehl wird zur Verifizierung digitaler Signaturen verwendet. Der Hashwert wird temporär gespeichert für den folgenden Befehl PSO: Verify Digital Signature Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt. Nur die Kontrollkarte wird benötigt, um diesen Befehl in DF Tachograph und DF Tachograph_G2 zu unterstützen. Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Der Befehl kann in MF gegebenenfalls zur Verfügung stehen. Die Kontrollkartenanwendung der 1. Generation unterstützt nur SHA-1.

TCS_115

Der vorübergehend gespeicherte Hashwert ist zu löschen, wenn mithilfe des Befehls PSO: HASH ein neuer Hashwert berechnet wird, wenn ein DF ausgewählt wird und wenn die Fahrtenschreiberkarte zurückgesetzt wird.

TCS_116

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”	CLA
INS	1	„2Ah”	Perform Security Operation
P1	1	„90h”	Hashcode zurücksenden
P2	1	„A0h”	Tag: Datenfeld enthält für Hashing relevante DO
Lc	1	„XXh”	Länge Lc des nachfolgenden Datenfelds
#6	1	„90h”	Tag für den Hashcode
#7	1	„XXh”	Länge L des Hashcodes: „14h” in Anwendung der 1. Generation (siehe Anlage 11 Teil A) „20h” , „30h” oder „40h” in Anwendung der 2. Generation (siehe Anlage 11 Teil B)
#8-#(7+L)	L	„XX..XXh”	Hashcode

TCS_117

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Fehlen einige der erwarteten Datenobjekte (siehe oben), wird der Verarbeitungsstatus 6987 zurückgesendet. Dies kann der Fall sein, wenn der Tag „90h” fehlt.

—

Sind einige Datenobjekte inkorrekt, lautet der zurückgesendete Verarbeitungsstatus 6988. Dieser Fehler tritt auf, wenn der erforderliche Tag zwar vorhanden ist, aber eine andere Länge als „14h” für SHA-1, „20h” für SHA-256, „30h” für SHA-384, „40h” für SHA-512 (Anwendung der 2. Generation) aufweist.

3.5.13

PERFORM HASH of FILE

Dieser Befehl entspricht nicht den Festlegungen von ISO/IEC 7816-8. Das CLA-Byte dieses Befehls gibt daher an, dass eine proprietäre Verwendung von PERFORM SECURITY OPERATION/HASH erfolgt. Nur die Fahrer- und die Werkstattkarte müssen diesen Befehl in DF Tachograph und DF Tachograph_G2 unterstützen. Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Wenn eine Unternehmens- oder Kontrollkarte diesen Befehl implementiert, muss dies gemäß den Angaben dieses Kapitels erfolgen. Der Befehl kann in der MF gegebenenfalls zur Verfügung stehen. Wenn ja, muss er gemäß den Angaben dieses Kapitels implementiert werden, d. h. der Befehl darf nicht die Berechnung eines Hashwerts zulassen, sondern muss mit einem geeigneten Fehlercode abschließen.

TCS_118

Der Befehl PERFORM HASH of FILE wird zur Hashwertberechnung des Datenbereichs der zu dem entsprechenden Zeitpunkt ausgewählten transparenten EF verwendet.

TCS_119

Eine Fahrtenschreiberkarte darf diesen Befehl nur für die im Kapitel 4 aufgeführten EF im Rahmen von DF_Tachograph und DF_Tachograph_G2 unterstützen, mit folgender Ausnahme. Eine Fahrtenschreiberkarte darf den Befehl nicht für den EF Sensor_Installation_Data von DF Tachograph_G2 unterstützen.

TCS_120

Das Ergebnis der Hash-Operation wird auf der Karte temporär gespeichert. Es kann dann zur Einholung einer digitalen Signatur der Datei mit Hilfe des Befehls PSO: COMPUTE DIGITAL SIGNATURE verwendet werden.

TCS_121

Der temporär gespeicherte ‚hash of file‘-Wert ist zu löschen, wenn mithilfe des Befehls PERFORM HASH of FILE ein neuer Hashwert berechnet wird, wenn ein DF ausgewählt wird und wenn die Fahrtenschreiberkarte zurückgesetzt wird.

TCS_122

Die Fahrtenschreiberanwendung der 1. Generation muss SHA-1 unterstützen.

TCS_123

Die Fahrtenschreiberanwendung der 2. Generation muss den Algorithmus SHA-2, SHA-256, SHA-384 oder SHA-512 unterstützen, der durch die Cipher Suite in Anlage 11 Teil B für den Kartensignaturschlüssel Card_Sign spezifiziert wird.

TCS_124

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	‚80h‘	CLA
INS	1	‚2Ah‘	Perform Security Operation
P1	1	‚90h‘	Tag: Hash
P2	1	‚00h‘	Algorithmus implizit bekannt Für die Fahrtenschreiberanwendung der 1. Generation: SHA-1 Für die Fahrtenschreiberanwendung der 2. Generation: SHA-2-Algorithmus (SHA-256, SHA-384 oder SHA-512) entsprechend der Cipher Suite in Anlage 11 Teil B für den Kartensignaturschlüssel Card_Sign

TCS_125

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Lässt die aktuelle EF diesen Befehl (EF Sensor_Installation_Data in DF Tachograph_G2) nicht zu, wird der Verarbeitungsstatus 6985 zurückgesendet.

—

Wird die ausgewählte EF als verfälscht betrachtet (wegen Integritätsfehlern in den Dateiattributen oder den gespeicherten Daten), lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

—

Ist die ausgewählte Datei keine transparente Datei oder gibt es keine aktuelle EF, wird der Verarbeitungsstatus 6986 zurückgesendet.

3.5.14

PSO: COMPUTE DIGITAL SIGNATURE

Dieser Befehl wird zur Berechnung der digitalen Signatur des zuvor berechneten Hashcodes (siehe PERFORM HASH of FILE, Abschnitt 3.5.13) verwendet. Nur die Fahrer- und die Werkstattkarte müssen diesen Befehl in DF Tachograph und DF Tachograph_G2 unterstützen. Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Im Falle einer Fahrtenschreiberanwendung der 2. Generation haben nur die Fahrerkarte und die Werkstattkarte einen Signaturschlüssel der 2. Generation, während andere Karten den Befehl nicht erfolgreich ausführen können und mit einem geeigneten Fehlercode abschließen. Der Befehl kann in MF gegebenenfalls zur Verfügung stehen. Steht der Befehl in MF nicht zur Verfügung, schließt er mit einem geeigneten Fehlercode ab. Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.

TCS_126

Dieser Befehl darf keine digitale Signatur eines zuvor mit dem Befehl PSO: HASH berechneten Hashcodes verarbeiten.

TCS_127

Zur Berechnung der digitalen Signatur wird der private Schlüssel der Karte, der der Karte implizit bekannt ist, herangezogen.

TCS_128

Die Fahrtenschreiberanwendung der 1. Generation führt eine digitale Signatur mit Hilfe einer Auffüllmethode gemäß PKCS1 aus (Einzelheiten siehe Anlage 11).

TCS_129

Die Fahrtenschreiberanwendung der 2. Generation berechnet eine auf elliptischen Kurven basierende digitale Signatur (Einzelheiten siehe Anlage 11).

TCS_130

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„00h”	CLA
INS	1	„2Ah”	Perform Security Operation
P1	1	„9Eh”	Zurückzusendende digitale Signatur
P2	1	„9Ah”	Tag: Datenfeld enthält zu signierende Daten. Da kein Datenfeld vorhanden ist, wird davon ausgegangen, dass die Daten bereits in der Karte vorhanden sind (Hash of File).
Le	1	„NNh”	Länge der erwarteten Signatur

TCS_131

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#L	L	„XX..XXh”	Signatur des zuvor berechneten Hash
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Wird der implizit ausgewählte private Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

—

Ist der in einem vorherigen „Perform Hash of File” -Befehl berechnete Hash nicht verfügbar, wird der Verarbeitungsstatus „6985” zurückgesendet.

3.5.15

PSO: VERIFY DIGITAL SIGNATURE

Dieser Befehl wird zur Verifizierung der als Eingabe bereitgestellten digitalen Signatur verwendet, deren Hash der Karte bekannt ist. Der Signaturalgorithmus ist der Karte implizit bekannt. Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt. Nur die Kontrollkarte wird benötigt, um diesen Befehl in DF Tachograph und DF Tachograph_G2 zu unterstützen. Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Der Befehl kann in MF gegebenenfalls zur Verfügung stehen.

TCS_132

Der Befehl VERIFY DIGITAL SIGNATURE verwendet stets den vom vorhergehenden Befehl Manage Security Environment MSE: Set DST ausgewählten öffentlichen Schlüssel sowie den von einem PSO: HASH- Befehl eingegebenen Hashcode.

TCS_133

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	‚00h‘	CLA
INS	1	‚2Ah‘	Perform Security Operation
P1	1	‚00h‘
P2	1	‚A8h‘	Tag: Datenfeld enthält für die Verifizierung relevante DO
Lc	1	‚XXh‘	Länge Lc des nachfolgenden Datenfelds
#6	1	‚9Eh‘	Tag für digitale Signatur
#7 oder #7 – #8	L	‚NNh‘ oder ‚81 NNh‘	Länge der digitalen Signatur (L gleich 2 Bytes, wenn die Länge der digitalen Signatur mehr als 127 Bytes beträgt): 128 Bytes, kodiert gemäß Anlage 11 Teil A für Fahrtenschreiberanwendung der 1. Generation. Je nach der für die Fahrtenschreiberanwendung der 2. Generation ausgewählten Kurve (siehe Anlage 11 Teil B).
#(7+L) – #(6+L+NN)	NN	‚XX..XXh‘	Inhalt der digitalen Signatur

TCS_134

Antwortnachricht

Byte	Länge	Wert	Beschreibung
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

Schlägt die Verifizierung der Signatur fehl, lautet der zurückgesendete Verarbeitungsstatus 6688. Der Verifizierungsvorgang wird in Anlage 11 beschrieben.

—

Ist kein öffentlicher Schlüssel ausgewählt, lautet der zurückgesendete Verarbeitungsstatus 6A88.

—

Fehlen einige der erwarteten Datenobjekte (siehe oben), wird der Verarbeitungsstatus 6987 zurückgesendet. Das kann der Fall sein, wenn der erforderliche Tag fehlt.

—

Ist kein Hash-Code zur Verarbeitung des Befehls verfügbar (im Ergebnis eines PSO: Hash-Befehls), lautet der zurückgesendete Verarbeitungsstatus 6985.

—

Sind einige Datenobjekte inkorrekt, lautet der zurückgesendete Verarbeitungsstatus 6988. Dies kann der Fall sein, wenn eine Länge der erforderlichen Datenobjekte inkorrekt ist.

—

Wird der ausgewählte öffentliche Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus 6400 oder 6581.

—

Weist der (zur Verifizierung der digitalen Signatur verwendete) ausgewählte öffentliche Schlüssel einen CHA.LSB (CertificateHolderAuthorisation.equipmentType) auf, der nicht für die Verifizierung der digitalen Signatur gemäß Anlage 11 geeignet ist, lautet der zurückgesendete Verarbeitungsstatus ‚6985‘.

3.5.16

PROCESS DSRC MESSAGE

Dieser Befehl wird verwendet, um die Integrität und Authentizität der DSRC-Nachricht zu verifizieren und um die von einer VU per DSRC-Link an eine Kontrollbehörde oder eine Werkstatt gesendeten Daten zu entschlüsseln. Die Karte leitet den zur Sicherung der DSRC-Nachricht gemäß Anlage 11 Teil B Kapitel 13 verwendeten Kodierungsschlüssel samt MAC-Schlüssel ab. Nur die Kontroll- und die Werkstattkarte müssen diesen Befehl in DF Tachograph_G2 unterstützen. Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren, dürfen aber nicht über einen DSRC-Hauptschlüssel verfügen. Aus diesem Grund können diese Karten den Befehl nicht erfolgreich ausführen, sondern schließen mit einem geeigneten Fehlercode ab. Der Befehl kann in MF und/oder DF Tachograph gegebenenfalls zur Verfügung stehen. Wenn ja, muss der Befehl mit einem geeigneten Fehlercode abschließen.

TCS_135

Der DSRC-Hauptschlüssel ist nur in DF Tachograph_G2 zugreifbar, d. h. Kontroll- und Werkstattkarte unterstützen die erfolgreiche Ausführung des Befehls lediglich in DF Tachograph_G2.

TCS_136

Der Befehl darf lediglich die DSRC-Daten entschlüsseln und die kryptografische Prüfsumme verifizieren, nicht aber die Eingabedaten interpretieren.

TCS_137

Die Reihenfolge der Datenobjekte im Befehlsdatenfeld ist durch diese Spezifikation festgelegt.

TCS_138

Befehlsnachricht

Byte	Länge	Wert	Beschreibung
CLA	1	„80h”	Proprietäres CLA
INS	1	„2Ah”	Perform Security Operation
P1	1	„80h”	Antwortdaten: Klarwert
P2	1	„B0h”	Befehlsdaten: in BER-TLV kodierter Klarwert mit SM DO
Lc	1	„NNh”	Länge Lc des nachfolgenden Datenfelds
#6-#(5+L)	L	„87h” + L87 + „XX..XXh”	DER-TLV-kodiertes Padding-Content Indicator-Byte, gefolgt von den verschlüsselten Fahrtenschreiberdaten. Für das Padding-Content Indicator-Byte ist der Wert „00h” ( „keine weitere Angabe” gemäß ISO/IEC 7816-4:2013 Tabelle 52) zu verwenden. Zur Verschlüsselung siehe Anlage 11 Teil B Kapitel 13. Zulässige Werte für die Länge L87 sind Vielfache der AES-Blocklänge zuzüglich 1 für das Padding-Content Indicator-Byte, d. h. von 17 Bytes bis einschließlich 193 Bytes. Hinweis: Siehe ISO/IEC 7816-4:2013 Tabelle 49 für das SM-Datenobjekt mit Tag „87h” .
		„81h” + „10h”	DER-TLV-kodiertes Control Reference Template for Confidentiality, das die Verkettung der folgenden Datenelemente gewährleistet (siehe Anlage 1 DSRCSecurityData und Anlage 11 Teil B Kapitel 13): — 4-Byte-Zeitstempel — 3-Byte-Zähler — 8-Byte-VU-Seriennummer — 1-Byte-DSRC-Hauptschlüsselversion Hinweis: Siehe ISO/IEC 7816-4:2013 Tabelle 49 für das SM-Datenobjekt mit Tag „81h” .
		„8Eh” + L8E + „XX..XXh”	DER-TLV-kodiertes MAC über der DSRC-Nachricht. Zu MAC-Algorithmus und Berechnung siehe Anlage 11 Teil B Kapitel 13. Hinweis: Siehe ISO/IEC 7816-4:2013 Tabelle 49 für das SM-Datenobjekt mit Tag „8Eh” .
Le	1	„00h”	Gemäß ISO/IEC 7816-4

TCS_139

Antwortnachricht

Byte	Länge	Wert	Beschreibung
#1-#L	L	„XX..XXh”	Fehlende (im Falle eines Fehlers) oder entschlüsselte Daten (Auffüllung entfernt)
SW	2	„XXXXh”	Statusbytes (SW1, SW2)

—

Ist der Befehl erfolgreich, sendet die Karte 9000 zurück.

—

6A80 gibt fehlerhafte Parameter im Befehlsdatenfeld an (auch verwendet, wenn die Datenobjekte nicht in der angegebenen Reihenfolge gesendet werden).

—

6A88 gibt an, dass Daten, auf die verwiesen wird, nicht verfügbar sind (d. h. der DSRC-Hauptschlüssel, auf den verwiesen wird, ist nicht verfügbar).

—

6900 gibt an, dass die Verifizierung der kryptografischen Prüfsumme oder die Entschlüsselung der Daten fehlgeschlagen ist.

—

6985 gibt an, dass der 4-Byte-Zeitstempel im Befehlsdatenfeld vor dem Zeitpunkt cardValidityBegin oder nach dem cardExpiryDate liegt.

4.

STRUKTUR DER FAHRTENSCHREIBERKARTEN

In diesem Abschnitt werden die Dateistrukturen, die auf den Fahrtenschreiberkarten der Speicherung zugänglicher Daten dienen, spezifiziert. Nicht spezifiziert werden vom Kartenhersteller abhängige interne Strukturen, wie z. B. Dateianfangskennsätze oder die Speicherung und Verarbeitung von Datenelementen, die nur für den internen Gebrauch benötigt werden, z. B. , , oder .

TCS_140

Eine Fahrtenschreiberkarte der 2. Generation muss das Wurzelverzeichnis (MF) und eine Fahrtenschreiberanwendung gleichen Typs der 1. und 2. Generation aufnehmen (z. B. Fahrerkartenanwendungen).

TCS_141

Eine Fahrtenschreiberkarte muss zumindest die Mindestzahl der für die entsprechenden Anwendungen angegebenen Datensätze unterstützen und darf nicht mehr als die Höchstzahl der für die entsprechenden Anwendungen angegebenen Datensätze unterstützen.

Die Höchst- und die Mindestzahl an Datensätzen sind in diesem Kapitel für die unterschiedlichen Anwendungen angegeben. In Version 2 von Fahrer- und Werkstattkarten der 2. Generation muss die Anwendung der 1. Generation die Höchstzahl der Datensätze gemäß TCS_150 und TCS_158 unterstützen.

Zu den Sicherheitsbedingungen, die in den in diesem Kapitel verwendeten Zugriffsregeln verwendet werden, siehe Kapitel 3.3. Generell bezeichnet der Zugriffsmodus „Lesen” den Befehl READ BINARY mit geradem und bei entsprechender Unterstützung mit ungeradem INS-Byte, ausgenommen die EF Sensor_Installation_Data auf der Werkstattkarte, siehe TCS_156 und TCS_160. Der Zugriffsmodus „Aktualisieren” bezeichnet den Befehl Update Binary mit geraden und bei entsprechender Unterstützung mit ungeradem INS-Byte und der Zugriffsmodus „Auswählen” den Befehl SELECT.

4.1.

Wurzelverzeichnis (MF)

TCS_142

Nach der Personalisierung weist das Wurzelverzeichnis (MF) folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweis: Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.

In dieser Tabelle wird die folgende Abkürzung für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

TCS_143

Die Strukturen aller EF sind transparent.

TCS_144

Das Wurzelverzeichnis (MF) hat folgende Datenstruktur:

TCS_145

Die Elementardatei EF DIR muss die folgenden anwendungsbezogenen Datenobjekte enthalten: „61 08 4F 06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54”

TCS_146

Die Elementardatei EF ATR/INFO muss vorhanden sein, wenn die Fahrtenschreiberkarte in ihrer ATR angibt, dass sie erweiterte Längenfelder unterstützt. In diesem Fall muss EF ATR/INFO das Datenobjekt mit der erweiterten Längenangabe (DO „7F66” ) gemäß ISO/IEC 7816-4:2013 Punkt 12.7.1 enthalten.

TCS_147

Die Elementardatei EF Extended_Length muss vorhanden sein, wenn die Fahrtenschreiberkarte in ihrer ATR angibt, dass sie erweiterte Längenfelder unterstützt. In diesem Fall muss die Elementardatei das folgende Datenobjekt enthalten: „02 01 xx” , wobei der Wert „xx” angibt, ob erweiterte Längenfelder für das Protokoll T = 1 und/oder T = 0 unterstützt werden.

Der Wert „01” zeigt die Unterstützung erweiterter Längenfelder für das Protokoll T = 1 an.

Der Wert „10” zeigt die Unterstützung erweiterter Längenfelder für das Protokoll T = 0 an.

Der Wert „11” zeigt die Unterstützung erweiterter Längenfelder für das Protokoll T = 1 und T = 0 an.

4.2.

Fahrerkartenanwendungen

4.2.1

Fahrerkartenanwendung der 1. Generation

TCS_148

Nach der Personalisierung weist die Fahrerkartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC2

ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3

SM-MAC-G1 ODER SM-MAC-G2

TCS_149

Die Strukturen aller EF sind transparent.

TCS_150

Die Fahrerkartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_151

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Fahrerkarte für eine Anwendung der 1. Generation verwenden muss:

4.2.2

Fahrerkartenanwendung der 2. Generation

TCS_152

Nach der Personalisierung weist die Fahrerkartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweise:

—

Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.

—

EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration und EF Load_Type_Entries sind nur in Version 2 der Fahrerkarte der 2. Generation vorhanden.

—

cardStructureVersion in EF Application_Identification ist für Version 2 der Fahrerkarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Fahrerkarte der 2. Generation gleich {01 00} war.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC5

Für den Befehl Read Binary mit geradem INS-Byte: SM-C-MAC-G2 UND SM-R-ENC-MAC-G2

Für den Befehl Read Binary mit ungeradem INS-Byte (falls unterstützt): NEV

TCS_153

Die Strukturen aller EF sind transparent.

TCS_154

Die Fahrerkartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_155

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Fahrerkarte für eine Anwendung der 2. Generation verwenden muss:

		Min.	Max.
n1	NoOfEventsPerType	12	12
n2	NoOfFaultsPerType	24	24
n3	NoOfCardVehicleRecords	200	200
n4	NoOfCardPlaceRecords	112	112
n6	CardActivityLengthRange	13776 Bytes (56 Tage * 117 Tätigkeitsveränderungen)	13776 Bytes (56 Tage * 117 Tätigkeitsveränderungen)
n7	NoOfCardVehicleUnitRecords	200	200
n8	NoOfGNSSADRecords	336	336
n9	NoOfSpecificConditionRecords	112	112
n10	NoOfBorderCrossingRecords	1120	1120
n11	NoOfLoadUnloadRecords	1624	1624
n12	NoOfLoadTypeEntryRecords	336	336
n13	VuConfigurationLengthRange	3072 Bytes	3072 Bytes

4.3.

Werkstattkartenanwendungen

4.3.1

Werkstattkartenanwendung der 1. Generation

TCS_156

Nach der Personalisierung weist die Werkstattkartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC2

ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3

SM-MAC-G1 ODER SM-MAC-G2

SC4

Für den Befehl READ BINARY mit geradem INS-Byte:

(SM-C-MAC-G1 UND SM-R-ENC-MAC-G1) ODER

(SM-C-MAC-G2 UND SM-R-ENC-MAC-G2)

Für den Befehl READ BINARY mit ungeradem INS-Byte (falls unterstützt): NEV

TCS_157

Die Strukturen aller EF sind transparent.

TCS_158

Die Werkstattkartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_159

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Werkstattkarte für eine Anwendung der 1. Generation verwenden muss:

4.3.2

Werkstattkartenanwendung der 2. Generation

TCS_160

Nach der Personalisierung weist die Werkstattkartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweise:

—

Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.

—

EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration und EF Calibration_Add_Data sind nur in Version 2 der Werkstattkarte der 2. Generation vorhanden.

—

cardStructureVersion in EF Application_Identification ist für Version 2 der Werkstattkarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Werkstattkarte der 2. Generation gleich {01 00} ist.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC5

Für den Befehl Read Binary mit geradem INS-Byte: SM-C-MAC-G2 UND SM-R-ENC-MAC-G2

Für den Befehl Read Binary mit ungeradem INS-Byte (falls unterstützt): NEV

TCS_161

Die Strukturen aller EF sind transparent.

TCS_162

Die Werkstattkartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_163

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Werkstattkarte für eine Anwendung der 2. Generation verwenden muss:

		Min.	Max.
n1	NoOfEventsPerType	3	3
n2	NoOfFaultsPerType	6	6
n3	NoOfCardVehicleRecords	8	8
n4	NoOfCardPlaceRecords	8	8
n5	NoOfCalibrationRecords	255	255
n6	CardActivityLengthRange	492 Bytes (1 Tag * 240 Tätigkeitsveränderungen)	492 Bytes (1 Tag * 240 Tätigkeitsveränderungen)
n7	NoOfCardVehicleUnitRecords	8	8
n8	NoOfGNSSADRecords	24	24
n9	NoOfSpecificConditionRecords	4	4
n10	NoOfBorderCrossingRecords	4	4
n11	NoOfLoadUnloadRecords	8	8
n12	NoOfLoadTypeEntryRecords	4	4
n13	VuConfigurationLengthRange	3072 Bytes	3072 Bytes

4.4.

Kontrollkartenanwendungen

4.4.1

Kontrollkartenanwendung der 1. Generation

TCS_164

Nach der Personalisierung weist die Kontrollkartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC2

ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3

SM-MAC-G1 ODER SM-MAC-G2

SC6

EXT-AUT-G1 ODER SM-MAC-G1 ODER SM-MAC-G2

TCS_165

Die Strukturen aller EF sind transparent.

TCS_166

Die Kontrollkartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_167

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Kontrollkarte für eine Anwendung der 1. Generation verwenden muss:

4.4.2

Kontrollkartenanwendung der 2. Generation

TCS_168

Nach der Personalisierung weist die Kontrollkartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf.

Hinweise:

—

Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.

—

EF Application_Identification_V2 und EF VU_Configuration sind nur in Version 2 der Kontrollkarte der 2. Generation vorhanden.

—

cardStructureVersion in EF Application_Identification ist für Version 2 der Kontrollkarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Kontrollkarte der 2. Generation gleich {01 00} war.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC5

Für den Befehl Read Binary mit geradem INS-Byte: SM-C-MAC-G2 UND SM-R-ENC-MAC-G2

Für den Befehl Read Binary mit ungeradem INS-Byte (falls unterstützt): NEV

TCS_169

Die Strukturen aller EF sind transparent.

TCS_170

Die Kontrollkartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_171

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Kontrollkarte für eine Anwendung der 2. Generation verwenden muss:

		Min.	Max.
n7	NoOfControlActivityRecords	230	520
n13	VuConfigurationLengthRange	3072 Bytes	3072 Bytes

4.5.

Unternehmenskartenanwendungen

4.5.1

Unternehmenskartenanwendung der 1. Generation

TCS_172

Nach der Personalisierung weist die Unternehmenskartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC2

ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3

SM-MAC-G1 ODER SM-MAC-G2

SC6

EXT-AUT-G1 ODER SM-MAC-G1 ODER SM-MAC-G2

TCS_173

Die Strukturen aller EF sind transparent.

TCS_174

Die Unternehmenskartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_175

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Unternehmenskarte für eine Anwendung der 1. Generation verwenden muss:

4.5.2

Unternehmenskartenanwendung der 2. Generation

TCS_176

Nach der Personalisierung weist die Unternehmenskartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweise:

—

Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.

—

EF Application_Identification_V2 und EF VU_Configuration sind nur in Version 2 der Unternehmenskarte der 2. Generation vorhanden.

—

cardStructureVersion in EF Application_Identification ist für Version 2 der Unternehmenskarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Unternehmenskarte der 2. Generation gleich {01 00} war.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1

ALW ODER SM-MAC-G2

SC5

Für den Befehl Read Binary mit geradem INS-Byte: SM-C-MAC-G2 UND SM-R-ENC-MAC-G2

Für den Befehl Read Binary mit ungeradem INS-Byte (falls unterstützt): NEV

TCS_177

Die Strukturen aller EF sind transparent.

TCS_178

Die Unternehmenskartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_179

Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Unternehmenskarte für eine Anwendung der 2. Generation verwenden muss:

		Min.	Max.
n8	NoOfCompanyActivityRecords	230	520
n13	VuConfigurationLengthRange	3072 Bytes	3072 Bytes