Spezifikation statischer Berechtigungen für 2D Barcode-Tickets

VDV-Kernapplikation Spezifikation statischer Berechtigungen für 2D Barcode-Tickets Kurztitel: KA STB-Spec Stand: 10. Mai 2016 Thema: Dateiname: Erstellt am: 11.01.2010 Verwendung von Statischen Berechtigungen auf der Grundlage des KA-Referenz_EFS/KA-TLV-Referenz- EFS für 2D Barcode (KA STB-SPEC) Spec_Stat Ber_V150.docx Zuletzt geändert am: 17.08.2016 14:51:00 Version: 1.5.0 Autor: Dr. J. Lutgen / VDV-ETS (vormals VDV KA-KG)

Releaseverzeichnis Release Bearbeiter Datum Bemerkung 1.0 Dr. J. Lutgen 28.09.2009 Berücksichtigung der Ergebnisse der Sitzung der AG Barcode am 24.08.09 1.106 Dr. J. Lutgen 30.09.2009 Formale Angleichung der Versionsnummer an die Nummerierung des aktuellen Spezifikationspakets zur Einheitlichkeit. 1.106 Dr. J. Lutgen 25.10.2009 Redaktionelle Änderungen. Keine spezifische Transaktionen für statische Berechtigungen notwendig. Überarbeitung der Erläuterung zur Datenstruktur, Wegfall der Fahrgastzahl. Einarbeitung der Kommentare von Herrn Lorenz. Erläuterungen zu Signaturen und Kopierschutz. Detaillierte Angaben über Druckerauflösung. Streichung der Sub-CA-Zertifikate gemäß PKCS#1 1.106 E. Fischer 01.11.2009 Ergänzungen für die vorhandenen KA- Spezifikationen eingefügt (Kap. 6) 1.106 Dr. J. Lutgen 01.11.2009 Einfügung des SAM-Transaktionszählers in die Datenstruktur der statischen Berechtigung mit Anpassung aller Längenangabe im Text. Text redaktionell überarbeitet. 1.106 E. Fischer 13.11.2009 Überarbeitung von Kap. 6, Einarbeitung der Kommentare von Herrn Lorenz zu Kap. 6. 1.106 Dr. J. Lutgen 16.11.2009 Überarbeitung Abschnitt 6.1 und ; Einfügung Abschnitte in 6.1 Redaktionelle Überarbeitung 1.106 H. Lorenz 19.11.2009 Überarbeitung Abschn. 6.1.1, 6.1.2, 6.2.1, Einfügung Abschn. 6.1.1.16, 6.1.2.2.8, 6.2.1.3 1.106 E. Fischer 07.12.2009 Ergänzung der Anwendungsfälle 1.106 Dr. J. Lutgen 11.01.2010 Überarbeitung der Abschnitte 6.1 und 6.2 Redaktionelle Überarbeitung 13.01.2010 Ergänzung in KVPT STB anzeigen 08.04.2010 Anmerkungen H. Lorenz bearbeitet 1.107 Elke Fischer 17.08.2010 Version angepasst Anwendungsfallbezeichnungen an SysLH V1.107 Spec_Stat Ber_V150.docx Seite ii 10. Mai 2016

Release Bearbeiter Datum Bemerkung angepasst TXUESTBER und TXSIGSTBER eingefügt TXASTBER korrigiert Hinweis KVPS: Zertifikat verteilen eingefügt Anwendungsfall PVS: Statische Berechtigung signieren eingefügt 1.107 Dr. J. Lutgen 18.08.2010 efsfahrgastnamevorname durch stbidentifikationsmediumnummer ersetzt. 1.107 Elke Fischer 17.09.2010 Ergänzung für die KA KUSCH-Spezifikation eingefügt 1.1.08 Dr. J. Lutgen Elke Fischer 19.04.2011 27.04.2011 Ergänzungen zur Signatur eingefügt, Anmerkungen Lorenz eingearbeitet TXZERTL ergänzt Anwendungsfälle zur unvollständigen Ausgabe ergänzt (CR_125) Dr. J. Lutgen 27.09.2011 Anforderung Lorenz/Systemtechnik zur Ergänzung der Beschreibung im Anhangs zur kryptographischen Prüfung von CA Zertifikaten umgesetzt (CR_125) Elke Fischer 06.10.2011 Hinweis zur Nutzung von ebezahlberechtigungen eingefügt (CR_125) Elke Fischer/ Helge Lorenz AG-S/ Elke Fischer 29.11.2011/ 30.11.2011 Ergänzung Anwendungsfälle: - KVPS: Statische Berechtigung Signatur anfordern, - KVPS: Statische Berechtigung Signatur weiterleiten Präzisierung Anwendungsfälle: - KVPT: Statische Berechtigung ausgeben, - PVS: Statische Berechtigung ausgeben - EP_Ausgabe_Statische Berechtigung (CR_125) 21.02.2012 Ergänzungen von Beschreibungen zur Bildung der Transaktionsdaten und zu den TXASTBER, TXESTBER und TXRSTBER (CR_125) Elke Fischer 13.03.2012 Korrektur Schreibfehler Singn Entitlement, Kap.4.4 (CR_125) J. Lutgen 13.03.2012 Anpassung der Signaturverfahren, um eine variable Datenmenge im statischen produktspezifischen Teil zu ermöglichen. Entsprechende redaktionelle Überarbeitung (CR_131) Spec_Stat Ber_V150.docx Seite iii 10. Mai 2016

Release Bearbeiter Datum Bemerkung J. Lutgen, E. Fischer 17.07.2012 Korrekturen der Nutzung variabler Datenlängen 1.1.09 E. Fischer 07.09.2012 Kap. 3; Hinweis zur einzutragenden Versionsnummer ergänzt. 01.10.2012 Fehlerkorrektur in TX_ZERT: berchr: CHRDaten J. Lutgen 18.10.2012 Korrekturen zu Ungleichungen in Kap. 7 E. Fischer/ H. Loerch 17.04.2013 Datentypen in Kap. 6.2.2 und 6.3.1 an XSD angeglichen E.Fischer 23.04.2013 Glossar gelöscht, in KA Hauptglossar integriert 1.3.0 J. Lutgen 13.11.2012 Umsetzung CR133: Korrektur der Anzahlen der Layer und Module in Kap. 2, Umsetzung gemäß ISO/IEC 24778:2008(E). J. Lutgen E. Fischer ergänzende Hinweise zur Beschreibung in der KA STB-Spec gemäß CR_133 eingearbeitet 21.11.2012 Präzisierung der Byteangabe in der Struktur STB Hinweis zur Datenübernahme aus dem SAM ergänzt Anlage 1 Transaktionsstrukturen in den TXASTBER, TXESTBER und TXRSTBER eingefügt 12.12.2012 Hinweis zur Ausgabe und Kontrolle bei gesperrtem PV-Schlüssel eingefügt (Kap. 6.1.1.5, 6.1.1.2, 6.1.1.1) E. Fischer 17.04.2013 Datenbezeichnung Kap. 6.3.1 korrigiert J. Lutgen E. Fischer E. Fischer H. Loerch Tabelle Validation_CODE in KA BOM-SPEC überführt 30.09.2013 Tabelle 2-1, Fußnoten 6 und 7 Mindestlängenangaben nach Überprüfung CR_141 korrigiert 10.01.2014 Hinweis zur Ermittlung der KV des PV-Schlüssels für TXASTBER eingefügt (Kap. 6.2.2.1) (CR_159) 09.07.2014 In Tabelle 4-1 und Tabelle 4-3 Angaben Pos. 5 bzw. 6 präzisiert. 01.08.2014 Beschreibung in Kap. 4.5.1 und 4.5.2 angepasst 01.09.2014 Kap. 4.3 Optionales STB-Format für die Abbildung mehrerer Berechtigungen in einem Barcode eingefügt (CR_141) 1.4.0 keine Änderungen gegenüber dem vorherigen Spec_Stat Ber_V150.docx Seite iv 10. Mai 2016

Release Bearbeiter Datum Bemerkung 1.5.0 E. Fischer H. Loerch E. Fischer H. Loerch Release 28.06.2016 Zur Rücknahme von Berechtigungen Hinweis Produktmodul eingefügt (CR_206); Kap. 6.1.1.6 Anwendungsfälle zu PKM an Anlage 2 zum (((eticket-teilnahmevertrag KA-Migrationsszenarien (TlnV-Beschluss 10.05.2016) angepasst (CR_206) 29.06.2016 Beschreibung der Anwendungsfälle, die analog zu KVPS und PVS für EFS ausgeführt werden gestrichen (CR_206), Kap. 6.1.2.2; 6.1.2.3 13.07.2016 Entfall reduziertes Format für 2D Barcode- Symbole (CR_195), Kap. 2, 4.3, 4.5, 6 E. Fischer 02.08.2016 TXZERTL und Verteilung von Zertifikaten für kleinen Barcode entfernt (CR_195); in Kap. 6.2.1, 6.2.2 Spec_Stat Ber_V150.docx Seite v 10. Mai 2016

Inhalt Releaseverzeichnis ii Inhalt vi Abbildungsverzeichnis viii Tabellenverzeichnis viii 1 Einleitung 1 2 Unterstützte Formate für 2D Barcode-Symbole 3 3 Standarddatenstruktur Statischer Berechtigungen 6 4 Sicherheitsmerkmale und Gesamtdatenstrukturen der Statischen Berechtigung 14 4.1 Struktur der signierten statischen Berechtigung... 14 4.2 Verwendete Zertifikate über Signaturschlüssel... 15 4.3 Gesamtdatenstrukturen der Statischen Berechtigung mit Sicherheitsmerkmalen... 16 4.4 Ausstellungsprozess... 21 4.5 Kontrollprozess... 21 4.5.1 Laden des Root-Schlüssels der VDV-KA-PKI... 22 4.5.2 Laden der benötigten Sub-CA-Zertifikate der VDV-KA-PKI... 22 4.5.3 Einlesen statischer Berechtigung... 22 4.5.4 Signaturzertifikat holen und prüfen... 23 4.5.5 Signatur prüfen... 24 4.5.6 Gültigkeit der Berechtigung prüfen... 24 4.5.7 Kontrollnachweis schreiben... 24 5 Spezifikation der Applikationsschnittstellen 26 5.1 Basisdatensätze... 26 5.2 Applikationsdatensätze... 26 6 Ergänzung der KA-Spezifikationen 28 6.1 Anwendungsfälle im Systemlastenheft für KA-Referenzsystemkomponenten... 28 6.1.1 Anwendungsfälle für KA-Referenzterminals... 28 6.1.1.1 DLT: Statische Berechtigung kontrollieren (durch Kontrollpersonal).. 29 6.1.1.2 DLT: Statische Berechtigung kontrollieren (Einstiegskontrolle)... 32 6.1.1.3 DLT: Gesperrte oder ungültige Statische Berechtigung erfassen... 34 6.1.1.4 DLT: Root- und CA-Zertifikate entgegennehmen... 35 6.1.1.5 KVPT: Statische Berechtigung ausgeben... 36 6.1.1.6 KVPT: Statische Berechtigung zurücknehmen... 39 6.1.1.7 KVPT: Statische Berechtigung erstatten... 41 6.1.1.8 KVPT: Statische Berechtigung ändern... 42 6.1.1.9 KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen... 42 6.1.1.10 KVPT: Statische Berechtigung anzeigen... 43 6.1.1.11 KVPT: Statische Berechtigung Beleg_drucken... 44 Spec_Stat Ber_V150.docx Seite vi 10. Mai 2016

6.1.1.12 KVPT: ZSAM-Zertifikat entgegennehmen... 45 6.1.1.13 KVPT: Root- und CA-Zertifikate entgegennehmen... 46 6.1.1.14 KVPT: Unvollständig ausgeführte Ausgabe von Statischen Berechtigungen im Terminal registrieren... 47 6.1.2 Anwendungsfälle für KA-Referenzhintergrundsysteme... 48 6.1.2.1 Anwendungsfälle im DLS... 48 6.1.2.1.1 DLS: Statische Berechtigung_Kontrolldaten verarbeiten 49 6.1.2.1.2 DLS: Root- und CA-Zertifikate herunterladen 49 6.1.2.1.3 DLS: Root- und CA-Zertifikate verteilen 51 6.1.2.2 Anwendungsfälle im KVPS... 52 6.1.2.2.1 KVPS: Statische Berechtigung ausgeben 54 6.1.2.2.2 KVPS: Statische Berechtigung zurücknehmen 55 6.1.2.2.3 KVPS: Statische Berechtigung Kontrollnachweis bearbeiten 55 6.1.2.2.4 KVPS: ZSAM-Zertifikat beantragen 56 6.1.2.2.5 KVPS: ZSAM-Zertifikat verteilen 56 6.1.2.2.6 KVPS: Root- und CA-Zertifikate herunterladen 57 6.1.2.2.7 KVPS: Root- und CA-Zertifikate verteilen 59 6.1.2.3 Anwendungsfälle im PVS... 60 6.1.2.3.1 PVS: Statische Berechtigung ausgeben 61 6.1.2.3.2 PVS: Statische Berechtigung zurücknehmen 62 6.1.2.3.3 PVS: Statische Berechtigung_Kontrolldaten verarbeiten 63 6.1.2.3.4 PVS: Unvollständig ausgeführte Ausgabe entgegennehmen und verarbeiten 64 6.2 Ergänzung in der KA SST-Spezifikation... 64 6.2.1 Elementarprozesse... 64 6.2.1.1 EP_Ausgabe_Statische Berechtigung... 66 6.2.1.2 EP_Rücknahme_Statische Berechtigung... 67 6.2.1.3 EP_Änderung_Statische Berechtigung... 68 6.2.1.4 EP_Kontrolle_Statische Berechtigung... 68 6.2.1.5 EP_Erfassung_gesperrte / ungültige Statische Berechtigung... 69 6.2.1.6 EP_Anzeige_Statische Berechtigung... 70 6.2.1.7 EP_Belegdruck_Statische Berechtigung... 70 6.2.2 Applikationsdatensätze... 71 6.2.2.1 TXASTBER... 71 6.2.2.2 TXESTBER... 72 6.2.2.3 TXRSTBER... 73 6.2.2.4 TXKNAWB... 74 6.2.3 Basisdatensätze... 75 6.2.3.1 Signatur-Sicherung... 75 6.2.3.2 Zertifikatsdaten... 76 6.3 Ergänzung in der KA BOM-Spezifikation... 76 6.3.1 Konstruierte Datentypen... 76 6.3.2 Aufzählungstypen (Codes)... 77 6.4 Ergänzung in der KA KUSCH-Spezifikation... 79 Spec_Stat Ber_V150.docx Seite vii 10. Mai 2016

7 Anhang: Signaturen mit Message Recovery gemäß ISO/IEC 9796-2 Schema 1 81 8 Glossar 85 9 Referenzen 86 Anlage 1 1 Transaktionsstrukturen in den TXASTBER, TXESTBER und TXRSTBER 1 Ausgabetransaktion Berechtigung 1 Rücknahmetransaktion Berechtigung 2 Kontrolltransaktion Berechtigung 3 Abbildungsverzeichnis Abbildung 3: Ausgabe Statische Berechtigung TXASTBER... 72 Abbildung 4: Kontrolle Statische Berechtigung TXESTBER... 73 Abbildung 5: Rücknahme Statische Berechtigung TXRSTBER... 74 Abbildung 6: Kontrollnachweis gesperrte/ungültige Berechtigung TXKNAWB... 75 Abbildung 8: Basisdatensatz zur Signatur-Sicherung einer statischen Berechtigung... 75 Abbildung 9: Basisdatensatz zur Beschreibung eines Zertifikats... 76 Abbildung 10: Logo für die Barcodeanwendung... 79 Abbildung 11: Logo Barcodekontrolle horizontale Scanfläche... 79 Abbildung 12: Logo Barcodekontrolle vertikale Scanfläche... 80 Tabellenverzeichnis Tabelle 2-1: Unterstützte Formate für 2D Barcode-Symbole... 3 Tabelle 2-2: Formatbezogene Vertriebskanäle... 4 Tabelle 3-1 : Standarddatenstruktur statischer Berechtigungen in der VDV- Kernapplikation- am Beispiel des Referenz-EFS gemäß KA NM Spezifikation... 11 Tabelle 4-1 : Struktur der signierten statischen Berechtigung... 15 Tabelle 4-2 : Speicherformat eines nichtselbstbeschreibenden CV-Zertifikats für den Signaturschlüssel (Signatur mit Message Recovery)... 16 Tabelle 4-3 : Gesamtdatenstruktur der statischen Berechtigung mit Sicherheitsmerkmalen... 17 Tabelle 4-5: Optionales STB-Format für die Abbildung mehrerer Berechtigungen in einem Barcode... 19 Tabelle 4-6 : Erlaubte Kombinationen der Gesamtdatenstrukturen und 2D Barcode Formate... 20 Spec_Stat Ber_V150.docx Seite viii 10. Mai 2016

Tabelle 6-1: Elementare Datentypen SIGNATUR... 76 Tabelle 6-2: Elementare Datentypen Restdaten... 76 Tabelle 6-3: Elementare Datentypen Zertifikatsdaten... 77 Tabelle 6-4: Elementare Datentypen CHRDaten... 77 Tabelle 6-5: Elementare Datentypen CARDaten... 77 Tabelle 6-6: Aufzählungstypen (Codes) SignaturTyp_CODE (Ergänzung Tabelle 6-64 KA BOM-Spezifikation)... 78 Spec_Stat Ber_V150.docx Seite ix 10. Mai 2016

1 Einleitung Ziel des vorliegenden Dokuments ist die Beschreibung von Datenstrukturen (inkl. Sicherheitsmerkmale) und Prozessen (Ausgabe und Kontrolle) für eine interoperable, standardisierte Nutzung von statischen Berechtigungen. Der Begriff statische Berechtigung bezieht sich hier auf einen mit einer digitalen Signatur ausgestatteten elektronischen Fahrschein, der als nicht veränderbarer Datensatz auf verschiedene, auch einfache Medien, ausgegeben werden kann. Es kann sich hierbei beispielsweise um ein auf Papier gedrucktes bzw. auf einem mobilen Endgerät gespeichertes 2D Barcode-Symbol oder einen auf einem kostengünstigen Speicherchip oder NFC-Handy gespeicherten und über eine ISO 14443-Schnittstelle lesbaren Datensatz handeln. In beiden Fällen sind die grundlegenden Strukturen und Prozesse identisch. Besonders die Nutzung eines 2D Barcode-Symbols für die Darstellung der Daten einer solchen statischen Berechtigung wird in Kap. 2 spezifiziert. Die statische Berechtigung wurde so spezifiziert, dass die wesentlichen Anwendungsfälle, Elementarprozesse und Schnittstellendatensätze der VDV-KA zur Anwendung kommen können und damit identische Verarbeitungsprozesse in den Terminals sowie in und zwischen den Hintergrundsystemen der Rollen gewährleistet sind. Durch die digitale Signatur über den Daten der Berechtigung wird ein sehr starker Schutz gegen Fälschung und Änderung von Berechtigungen realisiert. Da es sich aber dennoch um einen statischen Datensatz handelt, wird durch die Signatur allein kein Schutz gegen Kopieren der gesamten Berechtigung 1 erreicht. Es müssen also weitere begleitende Maßnahmen ergriffen werden, um zu sichern, dass eine solche Berechtigung höchsten einmal im System verwendet wird. Dieses Ziel wird durch die Bindung der Berechtigungsdaten an ein einmaliges, nicht kopierbares Medium erreicht. Diese Bindung wird entweder durch eine Referenz (siehe das Datenelement stbidentifikationsmediumnummer in Tabelle 3-1 sowie Anmerkung 6 zur Tabelle) auf ein solches Medium (im weiteren Kontrollmedium genannt) in den Berechtigungsdaten oder durch direkte physikalische Verbindung der Berechtigungsdaten mit einem nichtkopierbaren Trägermedium realisiert 2. Der Kopierschutz der Berechtigung ist dabei nur so hoch wie der Kopierschutz des gewählten Kontroll- 1 Mit dem Ziel beispielsweise weiteren Personen mit Kopien der Berechtigung zu versorgen, damit diese unberechtigt die entsprechende Leistung ebenfalls in Anspruch nehmen könnten. 2 Z.B. durch Druck einer als 2D Barcode kodierten Berechtigung auf Sicherheitspapier. Spec_Stat Ber_V150.docx Seite 1 10. Mai 2016

mediums bzw. Trägermediums, der im Verhältnis zum Wert des Tickets zu stellen ist. Der gewählte Kopierschutz sollte einerseits sein. effektiv, d.h. der Aufwand um den Kopierschutz zu kompromittieren und Kopien von Berechtigungen zu erstellen und verteilen ist hoch im Vergleich zu dem verursachten Schaden 3, und andererseits effizient, d.h. die Kosten für die Implementierung des Kopierschutzes sind gering im Verhältnis zum potentiellen Schaden, 3 Einnahmeverluste, Image-Schaden etc. Spec_Stat Ber_V150.docx Seite 2 10. Mai 2016

2 Unterstützte Formate für 2D Barcode-Symbole In diesem Kapitel werden die in diesem Standard unterstützten 2D Barcode-Symbole beschrieben, die verwendet werden können, um die in Kap. 3 definierten statischen Berechtigungsdaten zu transportieren, und die im Weiteren als KA-Formate bezeichnet werden. Alle KA-Formate werden grundsätzlich auf Basis des Aztec-Verfahrens (siehe ISO/IEC 24778:2008) mit einer Fehlerkorrektur von 23% erzeugt. Ferner müssen die einzelnen Module der 2D Barcode-Symbole in allen Fällen eine Kantenlänge von mindestens 0,378 mm (oder 14,9 mil) haben. Die in Anwendungen des Standards eingesetzte Barcodeleser- Technologie (z. B. Laser-Scanner, Imager etc.) muss eine hinreichende Auflösung besitzen, um alle KA-Formate (siehe folgende Tabelle) gut lesen zu können. Die Begriffe gut lesen bzw. gut lesbar bedeuten im Folgenden, dass die Daten bei jedem von mehreren wiederholten Versuchen (mindestens 10 hintereinander) erfolgreich und schnell (unter 2 Sek.) gelesen werden können. Es werden zwei spezifische KA-Formate mit den Bezeichnungen Regelformat und Erweitertes Format festgelegt. Die folgende Tabelle zeigt die entsprechend zusätzlich festgelegten Parameter dieser KA-Formate an 4. KA-Format Datenkapazität (binär in Byte) Erlaubte Darstellungsgrößen (Seitenlänge des gesamten 2D Barcode- Symbols) Layer Module Regelformat 394 5 26,8 mm 50,0 mm 13 71x71 Erweitertes Format Tabelle 2-1: 347-621 6 26,8 mm 50,0 mm 13 bis 17 71x71 bis 87x87 7 Unterstützte Formate für 2D Barcode-Symbole Um die Interoperabilität zu gewährleisten muss die eingesetzte Barcodeleser-Technologie in den Kontrollgeräten alle KA-Formate über den kompletten, jeweils angegebenen Bereich der 4 Angaben zu Anzahlen von Layer und Modulen sowie Datenkapazität sind gemäß ISO/IEC 24778:2008(E). 5 Beim Regelformat enthält der VDV Barcode auch mindestens 352 Byte Daten (siehe Kap. 4.3) und beim Referenz-EFS (siehe Kap. 3) genau 362 Byte Daten. 6 Beim erweiterten Format enthält der VDV Barcode auch mindestens 352 Byte Daten (siehe Kap. 4.3) und beim Referenz-EFS (siehe Kap. 3) mindestens 362 Byte Daten. 7 Die Anzahl der Module ist nicht ganz unabhängig von der Gesamtgröße des 2D Barcode-Symbols, denn es gilt weiterhin, dass (Seitenlänge des Symbols) / (Anzahl der Module entlang einer Seite) 0,378 mm Spec_Stat Ber_V150.docx Seite 3 10. Mai 2016

Darstellungsgröße gut lesen können. Für die Ausgabe von statischen Berechtigungen als 2D Barcodes werden bereits folgende Hauptvertriebskanäle vorgesehen: - Handy-Ticket mit Anzeige eines 2D Barcode-Symbols auf dem Handy-Display (kurz Handy-Ticket) - Papierfahrschein mit Aufdruck eines 2D Barcode-Symbols durch einen Fahrscheindrucker eines Kundenvertragspartners (kurz Papierfahrschein) auf Fahrscheinpapier - Online-Ticket mit Aufdruck eines 2D Barcode-Symbols auf Normalpapier (kurz Online- Ticket) Bei der Umsetzung des vorliegenden Standards dürfen nicht alle KA-Formate bei allen Vertriebskanälen zum Einsatz kommen. Die folgende Tabelle zeigt, welche KA-Formate in welchen Vertriebskanälen grundsätzlich verwendet werden dürfen. Vertriebskanäle KA-Format Handy-Ticket Papierfahrschein Online-Ticket Regelformat Verwendung erlaubt Verwendung erlaubt Verwendung erlaubt Erweitertes Format Verwendung erlaubt Verwendung erlaubt Verwendung erlaubt Tabelle 2-2: Formatbezogene Vertriebskanäle Für die Ausgabe muss der Ausgeber eine spezifische Größe definieren, die im erlaubten Bereich liegt. In einer spezifischen Anwendung des vorliegenden Standards muss bzgl. der Erstellung und Darstellung der 2D Barcode-Tickets festgelegt werden, - welche KA-Formate zur Anwendung kommen sollen, - welche der entsprechend erlaubten Symbolgrößen (Seitenlänge des gesamten 2D Barcode-Symbols) dabei zu benutzen sind und - im Falle des erweiterten Formats, auch welche Datenkapazität (und entsprechend daraus folgend die Zahl der Layer und Module) realisiert werden soll. Im Falle der Verwendung des Vertriebskanals Handy-Ticket bzw. Online-Ticket müssen diese Festlegungen so gewählt werden, dass die vorhandene Auflösung der Handy-Displays bzw. der Drucker hinreichend ist, um eine gut lesbare Darstellung des 2D Barcode wiederzugeben. Dabei sind insbesondere die Drucker der zu erreichenden Kunden zu beachten. Diese sind ggf. in geeigneter Weise auf eine Mindestauflösung hinzuweisen. Spec_Stat Ber_V150.docx Seite 4 10. Mai 2016

Im Falle der Verwendung des Vertriebskanals Papierfahrschein muss vom Lieferant des Fahrscheindruckers gefordert werden, dass der Fahrscheindrucker über eine hinreichend hohe Auflösung verfügt, um eine gut lesbare Darstellung des 2D Barcode wiederzugeben. Spec_Stat Ber_V150.docx Seite 5 10. Mai 2016

3 Standarddatenstruktur Statischer Berechtigungen Auf Basis des in der VDV-Kernapplikation standardisierten Referenz-EFS (siehe Spezifikation des Nutzermediums der VDV-Kernapplikation) wird in der folgenden Tabelle der Standard für die Datenstruktur sogenannter statischer Berechtigungen im Rahmen der VDV- Kernapplikation beschrieben. Anstelle der für den KA-Referenz-EFS definierten Datenelemente in den produktspezifischen Teilen der Berechtigung können hier natürlich auch für den TLV-EFS definierte TAGs verwendet werden. Die Beschreibung beschränkt sich auf die Inhalte einer statischen Berechtigung ohne Sicherheitsmerkmale. Die Sicherheitsmerkmale sowie die durch ihre Berücksichtigung resultierenden Gesamtstrukturen werden in Kap. 4 beschrieben. Die linke Spalte in der Tabelle listet die in der auf dem Medium gespeicherten statischen Berechtigung enthaltenen Datenelementen auf. Dabei erscheinen die entsprechenden Standardlängen dieser Elemente in der mittleren Spalte. Bis auf die Ergänzungen am Ende der Tabelle entstehen diese Datenelemente durch Entfernung aller für eine statische Berechtigung nicht sinnvollen bzw. nicht benötigten Datenelemente (inkl. Tag- und Längenangaben) aus dem Referenz-EFS der VDV-Kernapplikation (siehe (1) KA NM-Spec). Die rechte Spalte zeigt die im KVP- und PV-System zusätzlich zu haltenden, relevanten Datenelemente - berstatus, - bersynchronnummer, - logtransaktionstyp.code sowie die Tags und Längen, die einzufügen sind, um wieder eine selbstbeschreibende Struktur Berechtigung - Referenz EFS zu erhalten. Die Längen dieser Elemente werden ebenfalls in der mittleren Spalte in den entsprechenden Zeilen angegeben. Bis auf die Ergänzungen am Ende der Tabelle sind Kodierung und Werte aller Datenelemente gemäß der Spezifikation des Referenz-EFS (siehe (1) KA NM-Spec). Eine gemäß diesem Standard konstruierte, als Barcode gespeicherte statische Berechtigung muss immer mindestens eine Länge von 111 Byte haben. Diese ist erforderlich, um zu gewährleisten, dass die Informationen zu - Kennung (ASCII) 3 Byte =VDV - Version (BitString(16)) 2 Byte im Format: 0x0000 frei lesbar und nicht im verschlüsselten Datenbereich enthalten sind. Wird mit der in der Tabelle vorgegebenen Struktur mit den benutzten Datenelementen eine Länge von mindestens 111 Bytes nicht erreicht, so muss die entsprechende Anzahl an Füllbytes eingefügt werden. Spec_Stat Ber_V150.docx Seite 6 10. Mai 2016

Die Datenelemente Kennung und Version müssen immer am Ende der statischen Berechtigungsdaten vorhanden sein, damit die restliche Struktur identifiziert und letztendlich interpretiert werden kann. Diese Datenelemente können außerdem in Hintergrundsystemen verwendet werden, um zu erkennen, dass es sich bei dem Datensatz um eine statische Berechtigung handelt. Datenelemente der statischen Berechtigung 121 Byte in diesem Beispiel Länge in Byte Struktur Berechtigung EFS TLV-Struktur des EFS 145 Byte in diesem Beispiel 1 Tag Berechtigung 2-3 Länge Berechtigung EFS = 142 in diesem Beispiel Struktur Verzeichniseintrag Berechtigung 1 Tag Verzeichniseintrag Berechtigung 1 Länge Verzeichniseintrag Berechtigung = 26 Struktur Systemspezifischer Verzeichnisteil 1 Tag Systemspezifischer Verzeichnisteil 1 Länge Systemspezifischer Verzeichnisteil =0 Struktur Verzeichniseintrag Berechtigung Statischer Teil 1 1 Tag Verzeichniseintrag Berechtigung Statischer Teil Länge Verzeichniseintrag Berechtigung Statischer Teil = 18 berberechtigung_id (Struktur Berechtigung_ID ) prodprodukt_id (Struktur ( EFMProdukt_ID ) 6 4 Hinweis: Die prodkeyorganisation_id muss nicht rekonstruiert werden, da sie in den Transaktionsdaten, die über das ION gehen, nicht vorhanden ist. bergueltigkeitsbeginn 4 Spec_Stat Ber_V150.docx Seite 7 10. Mai 2016

Datenelemente der statischen Berechtigung 121 Byte in diesem Beispiel bergueltigkeitsende 4 Länge in Byte TLV-Struktur des EFS 145 Byte in diesem Beispiel Struktur Verzeichniseintrag Berechtigung Dynamischer Teil 1 1 Tag Verzeichniseintrag Berechtigung Dynamischer Teil Länge Verzeichniseintrag Berechtigung Dynamischer Teil = 2 1 berstatus = 7 1 bersynchronnummer = 1 Struktur Separate Daten Berechtigung EFS 1 Tag Separate Daten Berechtigung 2 Länge Separate Daten Berechtigung EFS Länge EFS = 111 in diesem Beispiel Bei Verwendung des TLV-EFS kann diese Länge abweichend sein! Struktur Separate Daten Berechtigung EFS Statischer Produktspezifischer Teil Tag Separate Daten Berechtigung Statischer produktspezifischer Teil Länge Separate Daten Berechtigung EFS Statischer produktspezifischer Teil 1 1 Länge für EFS = 64 in diesem Beispiel Bei Verwendung des TLV-EFS kann diese Länge abweichend sein! 8 berbezahlart.code 1 efsfahrgasttyp.code 1 stbidentifikationsmediumnummer 17 efsfahrgastgeschlecht 1 efsfahrgastgeburtsdatum 4 efsmitnahme1 (Struktur Mitnahme ) 2 efsmitnahme2 (Struktur Mitnahme ) 2 efsverkehrsmittelkategorie.code 1 8 Die Verwendung des TLV-EFS für die Statischen Berechtigungen empfiehlt sich insbesondere bei einer parallelen Verwendung von TLV-EFS in (((eticket-systemen. Für den EFS ist dort gefordert, dass für die produktspezifischen Anteile der Berechtigungen (Tag 0x85 und 0x8A) insgesamt nicht mehr als 96 Byte (ohne die Tag und Längenangabe für die produktspezifischen Teile) verbraucht werden. Spec_Stat Ber_V150.docx Seite 8 10. Mai 2016

Datenelemente der statischen Berechtigung 121 Byte in diesem Beispiel efsserviceklasse.code 1 Länge in Byte TLV-Struktur des EFS 145 Byte in diesem Beispiel efsstartort_id (Struktur Ort_ID ) 6 efszielort_id (Struktur Ort_ID ) 6 efsviaorte_id1 (Struktur Ort_ID ) 6 efsviaorte_id2 (Struktur Ort_ID ) 6 efsviaorte_id3 (Struktur Ort_ID ) 6 efspreis 2 EfsMehrwertsteuer 2 Letzte Transaktion (EFS) 1 Tag Ausgabetransaktion Berechtigung 1 Länge Ausgabetransaktion Berechtigung Länge für EFS = 31 in diesem Beispiel Bei Verwendung des TLV-EFS = 30 9 Struktur Allgemeine Transaktionsdaten 1 Tag Allgemeine Transaktionsdaten 1 Länge Allgemeine Transaktionsdaten = 18 logtransaktionsoperator_id 2 logterminal_id (Struktur Terminal_ ID ) 5 logtransaktionszeitpunkt 4 logtransaktionsortid (Struktur Ort_ID ) 6 1 logtransaktionstyp.code =1 Struktur Transaktion Produktspezifischer Teil Tag Transaktion Produktspezifischer Teil 1 Länge Transaktion Produktspezifischer Teil Referenz EFS 1 efsverkehrsmittelkategorie.code 1 Struktur Ausgabe Berechtigung Daten 9 Bei TLV-EFS entfällt der Inhalt von Transaktion Produktspezifischer Teil : efsverkehrsmittelkategorie.code Spec_Stat Ber_V150.docx Seite 9 10. Mai 2016

Datenelemente der statischen Berechtigung 121 Byte in diesem Beispiel Länge in Byte TLV-Struktur des EFS 145 Byte in diesem Beispiel 1 Tag Ausgabe Berechtigung Daten 1 Länge Ausgabe Berechtigung Daten = 4 berprodlogsamseqnummer: Es handelt sich hierbei um den Wert des Nutzungs-Sequenz-Zählers zu dem unten referenzierten Masterkey MKPV-NM-MAC des SAM, der sich in den letzten 4 Byte des entsprechenden Rekords des EF_Schlüssel-Info befindet, siehe (2) KA SAM-Spec. Da das SAM die Quelle dieser Daten ist, muss diese nach der Signatur aus dem SAM ausgelesen werden oder durch Entschlüsselung der Signatur ermittelt werden. 4 Struktur Statusaenderung Berechtigung 1 Tag Statusaenderung Berechtigung 1 Länge Statusaenderung Berechtigung = 0 Struktur Schluesselversionen Berechtigung 1 Tag Schluesselversionen 1 Länge Schluesselversionen = 1 Version MKPV Da das SAM die Quelle dieser Daten ist, muss diese nach der Signatur aus dem SAM ausgelesen werden oder durch Entschlüsselung der Signatur ermittelt werden. 1 Struktur Ausgabetransaktionskennung 1 Tag Ausgabetransaktionskennung 1 Länge Ausgabetransaktionskennung = 7 Struktur NM_Transaktion_ID Spec_Stat Ber_V150.docx Seite 10 10. Mai 2016

Datenelemente der statischen Berechtigung 121 Byte in diesem Beispiel samsequenznummer: Es handelt sich hierbei um den Wert im EF_Transaktionszähler des ausgebenden SAM, der vom SAM bei der Ausgabe eingetragen wird, siehe (2) KA SAM-Spec. Da das SAM die Quelle dieser Daten ist, muss diese nach der Signatur aus dem SAM ausgelesen werden oder durch Entschlüsselung der Signatur ermittelt werden. SAM_ID.samNummer: Es handelt sich hierbei um die letzten 3 Byte im EF_SAM-ID des ausgebenden SAM, die bei der Ausgabe vom SAM eingetragen werden, siehe (2) KA SAM-Spec. Da das SAM die Quelle dieser Daten ist, muss diese nach der Signatur aus dem SAM ausgelesen werden oder durch Entschlüsselung der Signatur ermittelt werden. Länge in Byte 4 3 TLV-Struktur des EFS 145 Byte in diesem Beispiel Ergänzungen Hier ggf. Füllbytes 0x00 einfügen, so dass eine Gesamtlänge von mindestens 111 Bytes 10 erreicht wird. (OctetString) Var. Diese Werte werden nicht in die TLV-Struktur übernommen und damit nicht in den TX(x) übertragen. Kennung (ASCII) = VDV 3 Version (VersionNumberExtended) 11 2 Tabelle 3-1 : Standarddatenstruktur statischer Berechtigungen in der VDV-Kernapplikationam Beispiel des Referenz-EFS gemäß KA NM Spezifikation 10 Eine Länge von mindestens 111 Byte ist erforderlich, damit die letzten 5 Byte (Kennung und Version) immer im Klartext lesbar sind. 11 Hier ist die jeweils zugrunde liegende KA-Spezifikationsversion einzutragen, z.b. 1.3.0! Spec_Stat Ber_V150.docx Seite 11 10. Mai 2016

Anmerkungen: 1. Die Datenelemente berstatus=7 und bersynchronnummer=1 des EFS können bei statischen Berechtigungen nach der Ausgabe nicht verändert werden. Deshalb werden diese in der Datenstruktur nicht geführt. Die Werte sollen im System (KVPS/PVS) vorgehalten und nachträglich eingetragen werden. Sie sind in den Daten des TXASTBER enthalten. 2. Da bei statischen Berechtigungen immer nur eine Ausgabetransaktion vorhanden ist, hat das Element logtransaktionstyp.code=1 des EFS einen festen Wert. Deshalb wird dieser in der Datenstruktur nicht geführt. Der Wert wird nachträglich in die Gesamt-TLV-Struktur ergänzt, er ist in den Daten des TXASTBER enthalten. 3. Der Infotext des EFS wird bei der statischen Berechtigung nicht benötigt, da es ergänzend zur statischen Berechtigung eine kundenorientierte Darstellung des Tickettextes für das jeweilige Medium geben muss. Diese ist nicht Bestandteil der Spezifikation der statischen Berechtigung und deren Abbildung im Barcode. 4. Die Tags und Längen für die Strukturen Separate Daten Berechtigung Statischer produktspezifischer Teil und Transaktion Produktspezifischer Teil bleiben in der Struktur der statischen Berechtigung erhalten, um die grundsätzliche Eigenschaft der KA, jeden (hier EFS-)Tarif abbilden zu können, beizubehalten. Wenn der vorstehend spezifizierte Referenz-EFS der statischen Berechtigung für ein Tarifprodukt nicht ausreicht, kann alternativ ein eigener produktspezifischer statischer Teil der Statischen Berechtigung spezifiziert werden. 5. Bei Bedarf können wie in der VDV-KA definiert abweichend vom Referenz-EFS der TLV-EFS verwendet oder für einzelne Produkte durch den betreffenden PV spezifische EFS unter Nutzung der produktspezifischen Datenelemente in der Berechtigung definiert werden. 6. Name und Vorname können aufgrund der Länge von 40 Byte nicht im verfügbaren Platz der statischen Berechtigung abgebildet werden. Die Information kann aber durch folgende Regelung mit dem Ticket verknüpft werden: Personenbezogene Tickets dürfen nur gegen personenbezogene Kontrollmedien ausgegeben werden. Deshalb steht in diesem Fall im Datenelement stbidentifikationsmediumnummer statt Name und Vorname des Kunden der Kontrollmedientyp und die Kontrollmediennummer. Die Länge des Datenelements kann somit gegenüber dem Referenz-EFS verkürzt werden. Es bleibt bei der ASCII-Codierung. Alternativ kann statt des Refe- Spec_Stat Ber_V150.docx Seite 12 10. Mai 2016

renz EFS ein spezifischer EFS definiert werden, in dem Name und Vorname als Datenelemente aufgenommen werden (unter Verzicht auf andere nicht benötigte Daten). Bei Verwendung des TLV-EFS ist dafür jeweils ein gesondertes TAG definiert. 7. Das Datenelement efsverkehrsmittelkategorie.code wird aus Kompatibilitätsgründen zum Referenz-EFS beibehalten, es entfällt beim TLV-EFS und es kann bei Definition eines eigenen EFS entfallen oder durch andere Datenelemente ersetzt werden. 8. Um die Vollständigkeit und Lückenlosigkeit von Ausgabetransaktionen prüfen zu können, ist es sinnvoll, einen separaten Zähler einzuführen (siehe berprodlogsam- SeqNummer, der vom ausgebenden SAM in die Daten der statischen Berechtigung eingetragen wird). Dieser Zähler wird in Zusammenhang mit einem im SAM gespeicherten PV-Masterkey geführt, der dem in der prodprodukt_id festgehaltenen PV gehört. Die Version des so referenzierten Schlüssels muss in der Struktur Schluesselversionen Berechtigung ebenfalls angegeben werden. 9. Ein beispielsweise beim HandyTicket zur Sichtkontrolle verwendetes Codewort muss nicht in der statischen Berechtigung abgebildet werden, da diese durch eine digitale Signatur gesichert wird (siehe Kap. 4) und eine darüber hinaus gehende Prüfung eines Codewortes nicht notwendig ist. 10. Kennung und Versionsangabe werden fest am Ende der Datenstruktur positioniert, damit sie immer an dieser Position gefunden werden können unabhängig von dynamischer Länge der vorherigen Datenelemente. Spec_Stat Ber_V150.docx Seite 13 10. Mai 2016

4 Sicherheitsmerkmale und Gesamtdatenstrukturen der Statischen Berechtigung Bei der Ausgabe werden statische Berechtigungen mit einer Signatur ausgestattet, die mit Hilfe eines privaten Signaturschlüssels erzeugt wird. Die Prüfung dieser Signatur erfolgt dann mit dem entsprechenden öffentlichen Teil des Signaturschlüssels. Um sich über die Authentizität dieses Schlüssels sicher zu sein, muss die prüfende Instanz ein Zertifikat über den öffentlichen Schlüssel erhalten und prüfen. Ein solches Zertifikat muss also entweder direkt mit den Berechtigungsdaten mitgeliefert o- der zumindest darin eindeutig referenziert werden. Im zweiten Fall muss die prüfende Instanz entweder das benötigte Zertifikat bereits vorhalten oder dieses im Verlauf der Kontrolle von einem Verzeichnisdienst der PKI bei Bedarf besorgen können. 4.1 Struktur der signierten statischen Berechtigung Über die in Kap. 3 definierten statischen Berechtigungsdaten, die eine Mindestlänge von 111 Byte haben müssen, wird eine Signatur gemäß dem im Standard ISO/IEC 9796-2 Schema 1 beschriebenen Verfahren (Signatur mit Message Recovery) unter Verwendung des Hashalgorithmus SHA-1 und des RSA-Verfahrens mit 1024 Bit Modulus und 4 Byte öffentlichem Exponent berechnet (siehe auch Kap. 7). Bei der Umkehrung der Berechnung zur Prüfung der Signatur werden dann die ersten 106 Byte der Berechtigungsdaten aus dem Signaturwert zurückerhalten, der in einem Datenobjekt mit Tag 9E geliefert wird. Die restlichen Bytes der Berechtigungsdaten werden in einem separaten Datenobjekt mit dem Tag 9A angegeben. Die signierten statischen Berechtigungsdaten haben also die folgende Struktur: Position Länge Inhalt Beschreibung 1 1 9E Tag für Signatur 2 2 81 80 Länge 3 128 XX...XX Signatur (128 Byte) Die ersten 106 Byte der signierten Daten werden in der Signatur kodiert. Spec_Stat Ber_V150.docx Seite 14 10. Mai 2016

Position Länge Inhalt Beschreibung 4 1 9A Tag für Restdaten 5 1 XX Länge der Restdaten (variabel, aber minimal 5 Byte bzw. >/= 5Byte) 6 variabel XX XX Restdaten der statischen Berechtigung Im Falle der Datenstruktur für das Beispiel in der Tabelle 3-1 bestehend aus 12 : letzte 2 Byte von berprodlogsamseqnummer Version MPV (1 Byte) SamSequenznummer (4 Byte) SAM_ID.samNummer (3 Byte) Kennung VDV (3 Byte) Version (2 Byte) Tabelle 4-1 : Struktur der signierten statischen Berechtigung 4.2 Verwendete Zertifikate über Signaturschlüssel Im Zusammenhang mit der hier standardisierten statischen Berechtigung kommen grundsätzlich nur Zertifikate der KA-Sicherheitsinfrastruktur gemäß ISO/IEC 9796-2 Schema 1 über den Signaturschlüsseln mit folgender Struktur zur Anwendung: Tag Länge Wert 7F 21 81 C8 CV Zertifikat (200 Byte) für einen Signaturschlüssel mit 1024 Bit Modulus, 4 Byte öffentlichem Exponent und CA-Schlüssel mit 1536 Bit Modulus Tag Länge Wert 5F 37 81 C0 Signatur des Zertifikatsherausgebers (Sub-CA) mit Message Recovery 192 Byte Digitale Signatur über die nachfolgenden Daten ( 6A BC ) gemäß ISO 9796-2 Schema 1 6A = Padding gemäß ISO 9796-2 04 = CPI XX... XX = CAR (8 Byte) XX... XX = CHR (12 Byte) 56 44 56 5F 4B 41 22 = CHA (7 Byte). 12 Hier werden keine Füllbytes verwendet, da die Länge der Daten im Beispiel bereits größer als 111 Byte ist. Spec_Stat Ber_V150.docx Seite 15 10. Mai 2016

Tag Länge Wert JJ JJ MM TT = EOV 2B 24 03 04 02 02 01 = OID XX XX = erster Teil (131 Byte) des Modulus bzw. des öffentlichen Exponents des öffentlichen Schlüssels XX XX = SHA-1 Hashwert (20 Byte) über die Dateninhalte CPI bis Modulus und öffentlichen Exponent. BC = Trailer-Byte 5F 38 01 XX XX = PK Remainder, d.h. der Rest öffentlichen Exponenten, also insgesamt 1 Byte Tabelle 4-2 : Speicherformat eines nichtselbstbeschreibenden CV-Zertifikats für den Signaturschlüssel (Signatur mit Message Recovery) Die Root- und Sub-CA-Struktur der KA-Sicherheitsinfrastruktur zur Ausgabe dieser Zertifikate ist in (2) KA SAM-Spec, Abschnitt 4.1 und Abschnitt 4.4 beschrieben. 4.3 Gesamtdatenstrukturen der Statischen Berechtigung mit Sicherheitsmerkmalen In diesem Abschnitt werden die Varianten zur Zusammensetzungen der statischen Berechtigungsdaten mit Signatur aus Abschnitt 4.1 und den Zertifikatsdaten aus Abschnitt 4.2 zu einer Gesamtstruktur erläutert. Den signierten statischen Berechtigungsdaten aus Tabelle 4-1 wird ein Zertifikat wie in Abschnitt 4.2 über den verwendeten Signaturschlüssel beigestellt. Da die Certificate Authority Reference (CAR) (siehe (2) KA SAM-Spec, Abschnitt 4.3.1.2) eines Zertifikats dieses Typs nicht transparent ist (d.h. erst nach der Umkehroperation ersichtlich) und die CAR den Prüfschlüssel identifiziert, wird das Datenobjekt mit der CAR noch einmal am Ende zusätzlich angehängt. Position Länge Inhalt Beschreibung 1 1 9E Tag für Signatur gemäß Abschnitt 4.1. 2 2 81 80 Länge der Signatur 3 128 XX...XX Signatur über statischen Berechtigungsdaten (128 Byte) Spec_Stat Ber_V150.docx Seite 16 10. Mai 2016

Position Länge Inhalt Beschreibung 4 1 9A Tag für Restdaten 5 1 XX Länge der Restdaten 6 variabel. XX XX Restdaten (minimal 5 Byte bzw. >/= 5Byte) der statischen Berechtigung 7 2 7F 21 Tag für CV Zertifikat gemäß Tabelle 4-2 8 2 81 C8 Länge CV Zertifikatsdaten 9 200 XX... XX CV Zertifikatsdaten 10 1 42 Tag für die CAR 11 1 08 Länge der CAR 12 8 XX... XX CAR, siehe (2) KA SAM-Spec, Abschnitt 4.3.1.2 ab 352 Summe (362 Bytes im Falle des Referenz-EFS) Tabelle 4-3 : Gesamtdatenstruktur der statischen Berechtigung mit Sicherheitsmerkmalen Spec_Stat Ber_V150.docx Seite 17 10. Mai 2016

Variante optionales STB-Format für die Abbildung mehrerer Berechtigungen in einem Barcode Für diese STB-Struktur gelten folgende Randbedingungen: - Alle Berechtigungen in einem VDV-Barcode müssen mit einem SAM signiert werden. Dieser muss alle erforderlichen PV-Schlüssel enthalten. - Jede im Barcode abgebildete Berechtigung muss einzeln durch das SAM mit Hilfe des Kommandos Sign Entitlement signiert werden. Damit ist sichergestellt, dass die Nutzungszähler der jeweiligen PV-Schlüssel auch korrekt hochgezählt werden. - Für jede Berechtigung ist eine Ausgabenachweis TXASTBER an den jeweiligen PV der Berechtigung zu schicken. Beispiel 1: 1 Barcode mit 2 Tickets des PV A Zählerstand PV-Schlüssel von PV A = vorheriger Zählerstand+2 2 getrennte Ausgabenachweise an PV A Beispiel 2: 1 Barcode mit einem Ticket des PV A und einem Ticket des PV B : Zählerstand PV-Schlüssel von PV A = vorheriger Zählerstand+1 Zählerstand PV-Schlüssel von PV B = vorheriger Zählerstand+1 1 Ausgabenachweis an PV A 1 Ausgabenachweis an PV B Spec_Stat Ber_V150.docx Seite 18 10. Mai 2016

Kapselndes Tag 1 EF Struktur "Mehrere Berechtigungen" 3 82 XX XX mindestens 355 Bytes, maximal 617 Bytes Tag für Anzahl Berechtigungen 1 90 Struktur "Anzahl Berechtigungen" 1 01 Länge 1 XX Anzahl Berechtigungen mindestens 1, maximal 2 Tag für Signatur 1. Berechtigung 1 9E Struktur "Signierte Berechtigung" 2 81 80 Länge 128 XX...XX Signatur (128 Byte) Die ersten 106 Byte der signierten Daten werden in der Signatur kodiert. Tag für Restdaten 1. Berechtigung 1 9A Struktur "Restdaten" 1 XX Länge 67 XX...XX mindesten 5 Byte (mit VDV und Versionsnummer), Restdaten der statischen Berechtigung wenn diese maximal 67 Byte (bei 96 Byte maximaler Länge der länger ist als 106 Byte Produktspezifischen Teile und bei TLV EFS mit maximaler Länge vom zusätzlichen Tag 0xD7 Tag für Signatur 2. Berechtigung 1 9E Struktur "Signierte Berechtigung" 2 81 80 Länge 128 XX...XX Signatur (128 Byte) Die ersten 106 Byte der signierten Daten werden in der Signatur kodiert. Tag für Restdaten 2. Berechtigung 1 9A Struktur "Restdaten" 1 XX Länge 67 XX...XX Restdaten der statischen Berechtigung wenn diese länger ist als 106 Byte Tag für Zertifikat 2 7F 21 Tag für CV Zertifikat (200 Byte) für einen Signaturschlüssel mit 1024 Bit Modulus, 4 Byte öffentlichem Exponent und CA- Schlüssel mit 1536 Bit Modulus 2 81 C8 Länge CV Zertifikat 2 5F 37 Tag für Signatur des Zertifikatsherausgebers (Sub-CA) mit Message Recovery 192 Byte Digitale Signatur über die nachfolgenden Daten ( 6A BC ) gemäß ISO 9796-2 Schema 1 2 81 C0 Länge 192 XX XX' Signatur 2 5F 38 Tag PK-Remainder 1 01' Länge PK-Remainder 1 XX Inhalt PK-Remainder 1 Byte Tag für CAR 1 42 Tag für CAR 1 08 Länge der CAR 8 XX XX' CAR, siehe KA SAM-Spec, Abschnitt 4.3.1.2 mindesten 5 Byte (mit VDV und Versionsnummer), maximal 67 Byte (bei 96 Byte maximaler Länge der Produktspezifischen Teile und bei TLV EFS mit maximaler Länge vom zusätzlichen Tag 0xD7 Summe: 621 Bei 2 Berechtigungen mit 96 Byte maximaler Länge der Produktspezifischen Teile und bei TLV EFS mit maximaler Länge vom zusätzlichen Tag 0xD7 "Identifikationsmedium" von 19 Byte Tabelle 4-4: Optionales STB-Format für die Abbildung mehrerer Berechtigungen in einem Barcode Spec_Stat Ber_V150.docx Seite 19 10. Mai 2016

Die markierten Zellen in der folgenden Tabelle zeigen die im vorliegenden Standard unterstützten Kombinationen aus Varianten der Gesamtdatenstruktur und KA-Formaten der 2D Barcode-Symbole. KA-Formate der 2D Barcode-Symbole gemäß Kap. 2 Variante gemäß Abschnitt 4.3 1 2 Normal datenerweitert Tabelle 4-5 : Erlaubte Kombinationen der Gesamtdatenstrukturen und 2D Barcode Formate Spec_Stat Ber_V150.docx Seite 20 10. Mai 2016

4.4 Ausstellungsprozess Die Ausstellung der Signatur einer statischen Berechtigung erfolgt in der VDV- Kernapplikation durch ein SAM, das die benötigte Schnittstelle bereitstellt. Für diesen Prozess muss das SAM sowohl durch das Security Management als auch den SAM-Betreiber aktiviert sein (siehe (2) KA SAM-Spec, Abschnitt 6.1). Ferner muss die Certificate Holder Authorisation (CHA) des entsprechenden SAM-Zertifikats die Autorisierung zur Ausgabe von solchen statischen Berechtigungen enthalten, da diese im Kontrollprozess geprüft wird. Die statischen Berechtigungsdaten werden gemäß Kap. 3 zusammengestellt und an das SAM zum Signieren übergeben. Hierzu soll das SAM-Kommando SIGN ENTITLEMENT dienen, dessen Antwort die signierten Berechtigungsdaten gemäß Tabelle 4-1 enthält. Gemäß einer der in Abschnitt 4.3 erläuterten Varianten wird das Zertifikat des Signaturschlüssels bzw. eine CHR als Referenz zum Signierschlüssel den signierten statischen Berechtigungsdaten beigestellt und die so erhaltene Gesamtdatenstruktur vom Terminal an den Nutzer ausgegeben. Die technische Darstellungsform dieser Daten auf dem Medium des Nutzers kann unterschiedlich sein. Falls aber ein 2D Barcode-Symbol hierfür zur Verwendung kommen soll, so sind die im Rahmen dieses Standards erlaubten Formate in Kap. 2 und Abschnitt 4.3 beschrieben und die entsprechenden Festlegungen sind zu beachten. 4.5 Kontrollprozess Im Folgenden wird der Prozess zur Verifikation der Authentizität und Gültigkeit der in dieser Spezifikation definierten statischen Berechtigungen durch ein DL-Terminal beschrieben. Dieser Prozess besteht aus folgenden Teilprozessen: Vorkonfiguration des Systems 1. Laden des Root-Schlüssels der VDV-KA-PKI 2. Laden der benötigten Sub-CA-Zertifikate der VDV-KA-PKI 3. Ggf. Laden bekannter Signaturzertifikate Prüfung einer statischen Berechtigung 1. Einlesen einer statischen Berechtigung 2. Signaturzertifikat holen und ggf. prüfen Spec_Stat Ber_V150.docx Seite 21 10. Mai 2016

3. Signatur prüfen 4. Gültigkeit der Berechtigung prüfen 5. Kontrollnachweis schreiben Die folgenden Abschnitte beschreiben diese Teilprozesse in Detail. 4.5.1 Laden des Root-Schlüssels der VDV-KA-PKI Als Teil der Vorkonfiguration des DL-Terminals muss der öffentliche Root-Schlüssel der VDV-KA-PKI authentisch vom Sicherheitsdienstleister bezogen (über PKI-Web-Service) oder über VDV-ETS angefragt werden und in das Terminal geladen werden. Der Schlüssel kann z.b. Bestandteil der Terminal-Software sein, so dass dieser nach dem Laden der Software bereits vorhanden ist. 4.5.2 Laden der benötigten Sub-CA-Zertifikate der VDV-KA-PKI Als Teil der Vorkonfiguration des DL-Terminals müssen die benötigten Sub-CA-Zertifikate der VDV-KA-PKI authentisch vom Sicherheitsdienstleister bezogen (über PKI-Web-Service) oder über VDV-ETS angefragt werden und in das Terminal geladen werden. Eine Übersicht über die vorhandenen Sub-CAs ist in (2) KA SAM-Spec, Abschnitt 4.4 zu finden. Das Terminal muss in der Lage sein, alle Sub-CA-Zertifikate zu speichern und zu verwalten. Die authentischen Sub-CA-Zertifikate können ein integraler Bestandteil der Kontroll-Software sein oder sie müssen mit Hilfe des Root-Schlüssels authentisch nachgeladen werden können. Beim Nachladen muss die Authentizität der Sub-CA-Zertifikate im Format ISO/IEC 9796-2 Schema 1 (siehe Kap. 7 bzw. (2) KA SAM-Spec, Abschnitt 4.3.3.2.2) mit dem bereits geladenen (öffentlichen) Root-Schlüssel verifiziert werden. 4.5.3 Einlesen statischer Berechtigung Das DL-Terminal muss statische Berechtigungen mit Gesamtdatenstrukturen gemäß der in Abschnitt 4.3 beschriebenen Varianten über spezifizierte technische Schnittstellen einlesen und für die weitere Verarbeitung speichern können. Die hierbei verwendeten technischen Schnittstellen sowie Darstellungsformen dieser Daten können unterschiedlich sein. Falls aber ein 2D Barcode-Symbol hierfür zur Verwendung kommen soll, so sind die im Rahmen dieses Standards erlaubten KA-Formate in Kap. 2 und Abschnitt 4.3 beschrieben. Spec_Stat Ber_V150.docx Seite 22 10. Mai 2016

4.5.4 Signaturzertifikat holen und prüfen Gemäß Abschnitt 4.3 enthält die Gesamtdatenstruktur der eingelesenen statischen Berechtigung entweder 1. ein Signaturzertifikat gemäß der Beschreibung in Abschnitt 4.2 oder 2. die CHR eines solchen Signaturzertifikats als Referenz. Im ersten Fall muss die Authentizität des eingelesenen Signaturzertifikats mit dem entsprechenden, bereits geladenen (öffentlichen) Sub-CA-Schlüssel verifiziert werden. Der dabei zu verwendende Sub-CA-Schlüssel wird in der CAR des Signaturzertifikats referenziert. Für die Verifikation muss das Verfahren ISO/IEC 9796-2 Schema 1 (siehe Kap. 7) vom Terminal unterstützt werden. Im zweiten Fall muss das referenzierte Signaturzertifikat gemäß Abschnitt 4.5.3 entweder bereits vorab im Terminal geladen sein oder von einem entsprechenden Verzeichnis (z.b. der VDV-KA-PKI) bei Bedarf eingelesen werden können. Soll das Laden von Zertifikaten bei Bedarf während des Kontrollprozesses von der Terminal-Applikation unterstützt werden, so darf dadurch keine wesentliche Verlängerung der vom Anwender (Verkehrsunternehmen) geforderten Gesamtzeit für den Kontrollprozess entstehen. Kann dies nicht gewährleistet werden, so muss dafür gesorgt werden, dass die benötigten Zertifikate durch rechtzeitige Updates immer vorab geladen sind. Wurde das Signaturzertifikat erfolgreich verifiziert bzw. bereits gemäß Abschnitt 4.5.3 geladen, so wird lediglich geprüft, ob es noch gültig ist (d.h. das End-of-Validity (EOV) noch nicht erreicht ist, siehe (2) KA SAM-Spec, Abschnitt 4.3.1.5), und ob die Nutzung des Schlüssels für die Ausgabe von Berechtigungen autorisiert ist (Prüfung, ob die CHA ein VDV-KA-SAM für Verkauf anzeigt, siehe (2) KA SAM-Spec, Abschnitt 4.3.1.4). Anschließend wird der Schlüssel aus dem Zertifikat für den nächsten Teilprozess im Terminal gespeichert. Schlägt die Verifikation oder eine der Prüfungen fehl, so wird der Kontrollprozess abgebrochen. Spec_Stat Ber_V150.docx Seite 23 10. Mai 2016

4.5.5 Signatur prüfen Die Struktur der signierten Berechtigung gemäß Abschnitt 4.1, Tabelle 4-1 wird der eingelesenen Gesamtdatenstruktur gemäß Abschnitt 4.3 entnommen und mit dem bereits gespeicherten (öffentlichen) Signaturschlüssel (Abschnitt 4.5.5) gemäß dem Verfahren ISO/IEC 9796-2 Schema 1 geprüft (siehe auch Kap. 7). Die insgesamt erhaltenen Klartextdaten der statischen Berechtigung gemäß Kap. 3, Tabelle 3-1 werden für den nächsten Teilprozess gespeichert. Schlägt die Verifikation der Signatur fehl, so wird der Kontrollprozess abgebrochen. 4.5.6 Gültigkeit der Berechtigung prüfen Die statischen Berechtigungsdaten gemäß Kap. 3, Tabelle 3-1 werden darauf hin geprüft, ob ein Sperreintrag für die Berechtigung in der Sperrliste vorhanden ist (gemäß VDV-KA bzw. Kap. 5), die Berechtigung räumlich und zeitlich gültig ist 13, der Berechtigungshalter das ggf. in der Berechtigung referenzierte Kontrollmedium vorzeigt und der Berechtigungshalter im Falle einer personenbezogenen Berechtigung auch der Inhaber des in der Berechtigung referenzierten personenbezogenen Kontrollmediums ist. Schlägt eine der Prüfungen fehl, so wird der Kontrollprozess abgebrochen. Sind alle Prüfungen erfolgreich, so ist der gesamte Kontrollprozess erfolgreich und die Berechtigung gültig. 4.5.7 Kontrollnachweis schreiben Im Rahmen des Kontrollprozesses werden entsprechende Transaktionsdatensätze geschrieben. Siehe dazu die Beschreibungen in den Abschnitten: - 6.1.1.1: DLT: Statische Berechtigung kontrollieren (durch Kontrollpersonal) - 6.1.1.2: DLT: Statische Berechtigung kontrollieren (Einstiegskontrolle) 13 Der Umfang der räumlichen und zeitlichen Gültigkeitsprüfungen ist produktspezifisch durch den PV zu regeln. Die entsprechenden Informationen dazu sind in einem Kontrollmodul gemäß VDV-KA an das DL-Terminal zu übergeben. Spec_Stat Ber_V150.docx Seite 24 10. Mai 2016

- 6.1.1.3: DLT: Gesperrte oder ungültige Statische Berechtigung erfassen Spec_Stat Ber_V150.docx Seite 25 10. Mai 2016

5 Spezifikation der Applikationsschnittstellen In diesem Kapitel sollen Hinweise zur Verwendung der in der Schnittstellenspezifikation der VDV-Kernapplikation (siehe (3) KA SST-SPEC) definierten Datensätze in Zusammenhang mit den hier spezifizierten statischen Berechtigungen gegeben werden. 5.1 Basisdatensätze Für Transaktionen zwischen den Referenzsystemen Kundenvertragspartner (KVP), Dienstleister (DL), Produktverantwortlicher (PV), Applikationsherausgeber (AH) und Kontrollservice (KOSE) sind folgende Basisdatensätze der Schnittstellenspezifikation der VDV-Kernapplikation (siehe (3) KA SST-SPEC) für die hier standardisierte statische Berechtigung relevant: 1. TX_BASE 2. TX_BER 3. TX_SANF 4. TX_SAUF Da hier kein Änderungsbedarf besteht, werden diese Basisdatensätze genauso verwendet wie in der Schnittstellenspezifikation beschrieben. 5.2 Applikationsdatensätze Für Transaktionen zwischen den Referenzsystemen sind folgende Applikationsdatensätze der Schnittstellenspezifikation der VDV-Kernapplikation (siehe (3) KA SST-SPEC) für die hier standardisierte statische Berechtigung relevant: 1. TXASTBER (Ausgabe statischer Berechtigung; siehe Kap. 6.2.2.1) 2. TXESTBER (Kontrolle statischer Berechtigung; siehe Kap.6.2.2.2) 3. TXRSTBER (Rücknahme statischer Berechtigung; siehe Kap.6.2.2.3) 4. TXSAUFB (Sperrauftrag an KOSE) 5. TXSFREIB (Sperrfreigabe an KOSE) 6. TXSANFB (Sperranforderung der sperranfordernden Instanz an KVP) 7. TXSAANFB (Sperraufhebungsanforderung) 8. TXSMITB (Sperrmitteilung des KVP an sperranfordernde Instanz) 9. TXSFREIMITB (Sperrfreigabemitteilung des KVP an sperrfreigabeanfordernde Instanz) 10. TXKNAWB (Kontrollnachweis Berechtigung, siehe Kap. 6.2.2.4) Spec_Stat Ber_V150.docx Seite 26 10. Mai 2016

Für TXASTBER, TXESTBER und TXRSTBER gibt es Änderungen gegenüber TXABER, TXEBER und TXRBER. Die in der statischen Berechtigung gemäß Kap. 3, Tabelle 3-1eliminierten Tag- und Längenangaben sind in den Datensätzen durch das Terminal wieder einzufügen. Sofern es keine Inhalte dazu gibt, ist die Länge mit 0 anzugeben. In den Ausgabetransaktionen, Erfassungstransaktionen und Rückgabetransaktionen zu der Statischen Berechtigung werden alle nicht vorhandenen Felder durch das Terminal mit Initialwerten aufgefüllt, um die Kompatibilität zu den vorhandenen TX-Transaktionen zu wahren. Damit werden für STB und BER identische Transaktionsdaten erzeugt und in die Hintergrundsysteme übertragen. Die TX unterscheiden sich nur durch die übertragene Signatur (STB) bzw. die übertragenen MAC (BER). Beim TXRSTBER sind die entsprechenden Daten aus der Ausgabetransaktion von TXASTBER zu entnehmen, da es bei statischen Berechtigungen keine Rücknahmetransaktion mit einem Nutzermedium im eigentlichen Sinne gibt. Im Falle einer Rücknahme von statischen Berechtigungen sind generell sowohl eine Rücknahme als auch eine Sperrung auszuführen. Die folgenden Datensätze werden für statische Berechtigungen im Sperrmanagement der KA benutzt. 1. TXSAUFB Sperrauftrag für Berechtigung an KOSE (zusätzlich ist das Gültigkeitsende gemäß dem in Arbeit befindlichen CR umzusetzen) 2. TXSFREIB Freigabeauftrag für Berechtigung an KOSE 3. TXSANFB Sperranforderung für Berechtigung an KVP 4. TXSAANFB Sperraufhebungsanforderung für Berechtigung an KVP 5. TXSMITB Sperrmitteilung des KVP für Berechtigung an sperranfordernde Instanz 6. TXSFREIMITB Sperrfreigabemitteilung des KVP für Berechtigung an sperrfreigabeanfordernde Instanz Spec_Stat Ber_V150.docx Seite 27 10. Mai 2016

6 Ergänzung der KA-Spezifikationen 6.1 Anwendungsfälle im Systemlastenheft für KA-Referenzsystemkomponenten 6.1.1 Anwendungsfälle für KA-Referenzterminals Es kommen folgende Anwendungsfälle für die statischen Berechtigungen für das DLT und KVPT zum Einsatz: DLT: Statische Berechtigung kontrollieren (durch Kontrollpersonal) DLT: Statische Berechtigung kontrollieren (kundenselbstbedient; Einstiegskontrolle) DLT: Gesperrte oder ungültige Statische Berechtigung erfassen DLT: Sperrliste(n) aktualisieren DLT: EFS-DL-Kontrollmodul entgegennehmen DLT: Root- und CA-Zertifikate entgegennehmen KVPT: Statische Berechtigung ausgeben KVPT: EFS mit geszahl bezahlen KVPT: Statische Berechtigung zurücknehmen KVPT: Statische Berechtigung erstatten KVPT: EFS gegen gesetzliches Zahlungsmittel zurückzahlen KVPT: Statische Berechtigung ändern KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen KVPT: Statische Berechtigung anzeigen KVPT: Statische Berechtigung Beleg_drucken KVPT: ZSAM-Zertifikat entgegennehmen KVPT: Root- und CA-Zertifikate entgegennehmen KVPT: SAM-Konfiguration prüfen KVPT: Sperrlisten aktualisieren KVPT: EFS_KVP-Produktmodul entgegennehmen KVPT: EFS_KVP-Produktmodul aktivieren KVPT: BER_Kontingente aktualisieren Spec_Stat Ber_V150.docx Seite 28 10. Mai 2016

KVPT: Key laden/ Key löschen KVPT: Notfall_Key aktivieren KVPT: Unvollständig ausgeführte Ausgabe im Terminal registrieren Anwendungsfälle zum EFS oder zur Systemorganisation, die identisch zum Elektronischen Fahrgeldmanagement der KA nutzbar sind, werden nicht gesondert für die statische Berechtigung beschrieben. Die Anwendungsfälle werden identisch gemäß (7) Systemlastenheft Teil: Personalbediente KVP-ReferenzTerminals, (8) Systemlastenheft Teil: Selbstbediente KVP- ReferenzTerminals und (9) Systemlastenheft Teil: DL-ReferenzTerminals benutzt. Es ist auch möglich, Barcode-Tickets auf Grundlage der Statischen Berechtigung an Terminals bargeldlos gegen Akzeptanz einer ebezahlberechtigung (POB/PEB-autoload oder WEB) auszugeben. In diesem Falle sind die zum Bezahlen eines EFS relevanten Anwendungsfälle aus dem Systemlastenheft Teil: Personalbediente KVP-ReferenzTerminals, bzw. Systemlastenheft Teil: Selbstbediente KVP-ReferenzTerminals in den Terminals umzusetzen. 6.1.1.1 DLT: Statische Berechtigung kontrollieren (durch Kontrollpersonal) DLT: Statische Berechtigung kontrollieren Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Eine statische Berechtigung wird zur Kontrolle mittels personalbedienter Kontrollterminals erfasst und auf Gültigkeit geprüft. DLT Kontrolleur Berechtigungsdaten durch Leser erfasst EFS_DL-Kontrollmodul ist aktiviert Sperrlisten SLNM und SLOS sind aktualisiert Spec_Stat Ber_V150.docx Seite 29 10. Mai 2016

DLT: Statische Berechtigung kontrollieren Root-Schlüssel der VDV-KA-PKI ist vorhanden 14 Benötigte Sub-CA-Zertifikate der VDV-KA-PKI sind geladen 14 Ergebnis Statische Berechtigung ist zur Kontrolle erfasst. Es wird eine Kontroll-Transaktion durchgeführt und der Transaktionsdatensatz für TXESTBER ist erzeugt. Nachbedingung Ablauf Daten für TXESTBER werden zur Übergabe an DLS bereitgestellt - Berechtigungsdaten lesen - Falls keine statische Berechtigung oder keine statische Berechtigung gemäß dieser Spezifikation mit Kennung VDV (in den letzten 5 Byte des Bytestrings 15 ) erkannt wird, EBE-Fall einleiten; - Berechtigungsdaten werden ausgewertet; - Signaturprüfung wird durchgeführt; - Falls negativ, so wird die statische Berechtigung abgewiesen mit Anzeige und ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; EBE- Fall einleiten; - Prüfung der Berechtigung_ID gegen Sperrliste SLNM wird durchgeführt; - Im Falle eines Treffers wird die statische Berechtigung abgewiesen mit Anzeige und ggf. Erfassung (s. DLT: gesperrte oder ungültige STB 14 Die Root-Zertifikate werden vom DLS an die Terminals verteilt (siehe AW: DLS: Root- und CA-Zertifikate verteilen). Sie sind auf den VDV-PKI-Webseiten abrufbar: https://vdv-web.telesec.de/cara-vdv (Level 3) bzw. http://vdv-test-pki.test.telesec.de/cara-vdv (Level 2). Sie können auch bei ETS direkt abgefragt werden. 15 Die Datenelemente Kennung und Version müssen immer am Ende der statischen Berechtigungsdaten vorhanden sein! Spec_Stat Ber_V150.docx Seite 30 10. Mai 2016

DLT: Statische Berechtigung kontrollieren Hinweis: erfassen) zur späteren Auswertung vorgenommen; EBE-Fall einleiten; - Zeitliche Gültigkeit der Berechtigung prüfen; wenn ungültig ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; EBE-Fall einleiten; - Prüfung o der enthaltenen ORG-IDs gegen Sperrliste Organisation; o der SAM-ID der Ausgabetransaktionskennung gegen Sperrliste SAM o des verwendeten SAM-Signaturschlüssels gegen Sperrliste asymmetrische Schlüssel o des benutzten MKPV gegen Sperrliste symmetrische Schlüssel - Im Falle eines Treffers wird die statische Berechtigung abgewiesen mit Anzeige und ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; EBE-Fall einleiten; - Unter Nutzung des EFS_DL-Kontrollmoduls kontrollrelevante Tarifparameter prüfen, ggf. anzeigen; - Unter Nutzung des EFS_DL-Kontrollmoduls räumliche Gültigkeit der STB prüfen, falls nicht gültig ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; EBE- Fall einleiten; - Erfassungstransaktionsdaten für TXESTBER werden zur Übergabe an DL-System gespeichert; - Beenden der Kontrolle mit Anzeige. Spec_Stat Ber_V150.docx Seite 31 10. Mai 2016

Sperrlisteneinträge für PV-Schlüssel haben keinerlei Auswirkung auf die Kontrolle der Statischen Berechtigungen (VDV-Barcode). 6.1.1.2 DLT: Statische Berechtigung kontrollieren (Einstiegskontrolle) DLT Statische Berechtigung kontrollieren (Einstiegskontrolle) Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Eine statische Berechtigung wird zur Kontrolle mittels selbstbedienter Kontrollterminals erfasst und auf Gültigkeit geprüft. DLT Kunde Berechtigungsdaten durch Leser erfasst EFS_DL-Kontrollmodul ist aktiviert Sperrlisten SLNM und SLOS sind aktualisiert Root-Schlüssels der VDV-KA-PKI ist vorhanden 14 Benötigte Sub-CA-Zertifikate der VDV-KA-PKI sind geladen 14 Statische Berechtigung ist zur Kontrolle erfasst. Es wird eine Kontroll-Transaktion durchgeführt, und der Transaktionsdatensatz für TXESTBER ist erzeugt. Daten für TXESTBER werden zur Übergabe an DLS bereitgestellt - Berechtigungsdaten lesen - Falls keine statische Berechtigung oder keine statische Berechtigung gemäß dieser Spezifikation mit Kennung VDV (in den letzten 5 Byte des Bytestrings 15 ) erkannt wird, erfolgt eine Abweisung mit Anzeige ; - Berechtigungsdaten werden ausgewertet; - Signaturprüfung wird durchgeführt; - Falls negativ, wird die statische Berechtigung Spec_Stat Ber_V150.docx Seite 32 10. Mai 2016

DLT Statische Berechtigung kontrollieren (Einstiegskontrolle) abgewiesen mit Anzeige und ggf. Erfassung (s. DLT: Gesperrte oder ungültige Statische Berechtigung erfassen) zur späteren Auswertung vorgenommen; - Prüfung der Berechtigung_ID gegen Sperrliste SLNM wird durchgeführt; - Im Falle eines Treffers wird die statische Berechtigung mit Anzeige abgewiesen und ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; - Zeitliche Gültigkeit der akzeptierten Berechtigung prüfen; wenn ungültig, wird die statische Berechtigung mit Anzeige abgewiesen; ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; - Prüfung o der enthaltenen ORG-IDs gegen Sperrliste Organisation; o der SAM-ID der Ausgabetransaktionskennung gegen Sperrliste SAM o des verwendeten SAM-Signaturschlüssels gegen Sperrliste asymmetrische Schlüssel o des benutzten MKPV gegen Sperrliste symmetrische Schlüssel - Im Falle eines Treffers wird die statische Berechtigung mit Anzeige abgewiesen und ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; - Unter Nutzung des EFS_DL-Kontrollmoduls kontrollrelevante Tarifparameter prüfen, ggf. anzeigen; - Unter Nutzung des EFS_DL-Kontrollmoduls räumliche Gültigkeit Spec_Stat Ber_V150.docx Seite 33 10. Mai 2016

DLT Statische Berechtigung kontrollieren (Einstiegskontrolle) der STB prüfen, falls nicht gültig, wird die statische Berechtigung mit Anzeige abgewiesen; ggf. Erfassung (s. DLT: gesperrte oder ungültige STB erfassen) zur späteren Auswertung vorgenommen; - Erfassungstransaktionsdaten für TXESTBER werden zur Übergabe an DL-System gespeichert; - Beenden der Kontrolle mit Anzeige. Hinweis: Sperrlisteneinträge für PV-Schlüssel haben keinerlei Auswirkung auf die Kontrolle der Statischen Berechtigungen (VDV-Barcode). 6.1.1.3 DLT: Gesperrte oder ungültige Statische Berechtigung erfassen Um systematische Angriffe und Betrugsfälle frühzeitig erkennen zu können, wird empfohlen, vereinfachte Kontrollnachweise (Rumpfkontrollnachweise) bei der Kontrolle ungültiger oder auf der Sperrliste SLNM erfasster statischer Berechtigungen oder von statischen Berechtigungen, zu denen in der SLOS ein Sperrauftrag vorliegt, im Terminal zu erzeugen. Sie sind außerdem sinnvoll und notwendig für statistische Auswertungen. Dieser Anwendungsfall wird immer dann abgearbeitet, wenn eine gesperrte bzw. zeitlich o- der räumlich ungültige Berechtigung erkannt wird oder die Signaturprüfung fehlgeschlagen ist. DLT: Gesperrte oder ungültige Statische Berechtigung erfassen Kurzbeschreibung Akteure Auslöser Es wird eine statische Berechtigung an einem DL- Terminal erfasst, die auf der Sperrliste SLNM steht, zu der auf der SLOS ein Sperrauftrag vorliegt bzw. die zeitlich oder räumlich ungültig ist. Es wird ein Datensatz erzeugt, der ins DLS zur internen Auswertung weitergeleitet wird. DLT gesperrte oder ungültige statische Berechtigung Spec_Stat Ber_V150.docx Seite 34 10. Mai 2016

DLT: Gesperrte oder ungültige Statische Berechtigung erfassen Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Berechtigung_ID Kontrolle wird ausgeführt Datensatz für TXKNAWB ist erzeugt. Daten für TXKNAWB werden zur Übergabe an DLS bereitgestellt - Daten für TXKNAWB werden zur Übergabe an DL- System gespeichert - Beenden der Aktion mit Anzeige 6.1.1.4 DLT: Root- und CA-Zertifikate entgegennehmen DLT: Root- und CA-Zertifikate entgegennehmen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Das DLT benötigt neben dem im Barcode gelieferte ZSAM- Zertifikat gültige Root- und Sub-CA-Zertifikate der KA-PKI zur Prüfung der Statischen Berechtigung. Die Root- und CA-Zertifikate werden durch das DLS von der VDV-KA-PKI heruntergeladen und an das DLT übergeben. DLT, DLS Meldung der Root- und/oder Sub-CA-Zertifikate durch das DLS. Zertifikatsdaten Die benötigten Zertifikate liegen im DLS vor. Zertifikat(e) sind im DLT verfügbar und werden bis zum Verfallszeitpunkt gespeichert Keine - Zertifikat(e) wird (werden) im DLT zur weiteren Nutzung abgelegt Spec_Stat Ber_V150.docx Seite 35 10. Mai 2016

DLT: Root- und CA-Zertifikate entgegennehmen - Empfang wird gegenüber DLS quittiert 6.1.1.5 KVPT: Statische Berechtigung ausgeben KVPT: Statische Berechtigung ausgeben Kurzbeschreibung Akteure Auslöser Eine statische Berechtigung wird ggf. mit einem im Klartext lesbaren Berechtigungstext auf ein mobiles Endgerät, Speicherchip oder Papier ausgegeben. Die tarifrelevanten Daten werden im KA-Datenformat aufbereitet, durch ein KA-SAM im KVPT signiert und auf dem Träger entsprechend kodiert (beispielsweise als 2D Barcode für Displays mobiler Endgeräte oder Online-Ticket). KVP-Terminal mit KA-SAM im KVPT Kunde Eingehende Info Vorauswahl der Berechtigung durch den Kunden; Anzeige einer bereits erworbenen statischen Berechtigung als Option für die nächste Auswahl einer statischen Berechtigung Vorbedingung EFS_KVP-Produktmodul ist aktiviert Kontingent für das Produkt 0 CHA des entsprechenden SAM-Zertifikats muss die Autorisierung zur Ausgabe von statischen Berechtigungen enthalten, d.h. es handelt sich um ein Verkaufs-SAM. keine PV-Notfallschlüsselaktivierung vorhanden 16, d.h. die Regulär-Version des PV-Masterkey ist nicht gesperrt. Ergebnis Statische Berechtigung wird zur Ausgabe auf ein Medium bereitgestellt bzw. Ausgabe wird durchgeführt; 16 Eine Ausgabe mit PV-Notfallschlüssel findet nicht statt. Die Regelversion des PV-Schlüssels wird hier analog zum eticket nur verwendet, um den Stand des Nutzungszählers der Regelversion in die Berechtigung einzutragen. Im Falle einer Schlüsselkompromittierung sind unverzüglich neue Schlüsselversionen zu verwenden. Spec_Stat Ber_V150.docx Seite 36 10. Mai 2016

KVPT: Statische Berechtigung ausgeben Datensatz für TXASTBER mit Signatur ist erzeugt Nachbedingung Ablauf Daten für TXASTBER werden zur Übergabe an KVPS bereitgestellt - Auswahl der anzulegenden statischen Berechtigung, Anlegen der Berechtigung mit Eintragen der Berechtigung_ID 17 ; - Zeitliche Gültigkeit der anzulegenden Berechtigung wird auf Plausibilität geprüft; - Zeitliche Gültigkeit der Berechtigung wird ggf. angepasst; - Falls erforderlich werden vertragsrelevante Kundendaten/Kundenvertragsdaten für KVP-System erfasst und zur Weiterleitung ins KVP-System aufbereitet; - Alle nicht für einen Eintrag erfassten Daten werden mit dem Wert= 00 gefüllt; - Ausgabetransaktionsdaten mit allen terminal- und ortsspezifischen Angaben aufbereiten (nach Vorgabe des Auftraggebers); Die Datenelemente berstatus und bersynchronnummer werden in der Datenstruktur nicht geführt. Das Element logtransaktionstyp.code hat einen festen Wert und wird in der Datenstruktur nicht geführt. Der Infotext wird durch eine kundenorientierte Darstellung des Tickettextes für das jeweilige Medium ersetzt. 17 Achtung: Es muss sichergestellt werden, dass die bei einem KVP ausgegebenen Berechtigungen eine eineindeutige laufende Nummer erhalten! Spec_Stat Ber_V150.docx Seite 37 10. Mai 2016

KVPT: Statische Berechtigung ausgeben Die Tags und Längen für die Strukturen Separate Daten Berechtigung Statischer produktspezifischer Teil und Transaktion Produktspezifischer Teil bleiben in der Struktur der statischen Berechtigung erhalten, um die grundsätzliche Eigenschaft der KA, jeden (hier EFS-)Tarif abbilden zu können, beizubehalten. Wenn der Referenz-EFS oder der Referenz-TLV_EFS für ein Tarifprodukt nicht anwendbar ist, muss ein eigener EFS spezifiziert werden. Das Datenelement efsverkehrsmittelkategorie.code (Wert = 00 ) wird aus Kompatibilitätsgründen bei Nutzung des Referenz-EFS beibehalten, es entfällt bei Verwendung des TLV-EFS und kann bei Definition eines eigenen EFS entfallen. - Um die Vollständigkeit und Lückenlosigkeit von Ausgabetransaktionen prüfen zu können, wird ein Zähler vom SAM übergeben, der die Ausgaben zählt (siehe ber- ProdLogSAMSeqNummer, der vom ausgebenden SAM in die Daten der statischen Berechtigung eingetragen wird). - Version des referenzierten Schlüssels MKPV-NM-MAC in der Struktur Schluesselversionen Berechtigung eintragen - Signatur erzeugen 18 ; - Gesamtberechtigungsdaten erzeugen; - Daten zur Ausgabe bereitstellen; - Ggf. Daten ausgeben oder Ausgabeprozess über Remote Procedure Call ausführen; - Ausgabetransaktionsdaten für TXASTBER sind zur Übergabe an KVP-System gespeichert; - Beenden der Ausgabe mit Anzeige. 18 Erzeugung von berprodlogsamseqnummer mit PV-Schlüssel im SAM dann Signaturbildung mit SAM und ZSAM-Zertifikat im KVPT. Spec_Stat Ber_V150.docx Seite 38 10. Mai 2016

6.1.1.6 KVPT: Statische Berechtigung zurücknehmen Die Rücknahme einer Berechtigung mit Transaktionsnachweis ist immer dann erforderlich, wenn zeitlich noch gültige Berechtigungen zurückgenommen werden und insbesondere, wenn eine Erstattung damit verbunden ist. Da nicht sichergestellt ist, dass noch Kopien im Umlauf sind, muss diese Berechtigung zur Sperrung beauftragt werden. Wenn eine Erstattung in den Tarifbestimmungen vorgesehen ist, ist dieser Anwendungsfall in Verbindung mit einer Erstattung nur bei dem KVP zulässig, der die Berechtigung ausgegeben hat (Primär-KVP). Dabei sind die innerhalb von Produktmodulen für ein Produkt definierten Rücknahmebedingungen auszuwerten. KVPT: Rücknahme der Statischen Berechtigung Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Die Rücknahme wird ausgeführt, die Berechtigung_ID muss während ihrer zeitlichen Gültigkeit auf die Sperrliste gesetzt werden KVP-Terminal Kunde Rücknahmewunsch des Kunden für eine statische Berechtigung Berechtigungsdaten durch Leser erfasst Root-Schlüssel der VDV-KA-PKI ist vorhanden Benötigte Sub-CA-Zertifikate der VDV-KA-PKI sind geladen Bekannte SAM-Signaturzertifikate sind ggf. geladen Sperrlisten SLNM und SLOS sind aktualisiert Statische Berechtigung ist zur Sperrung beauftragt, Datensatz für TXRSTBER und Datensatz für TXSAUFB ist erzeugt; Daten bleiben im KVP-System ab Löschzeitpunkt noch x Tage gespeichert (Nachweis/Service). ggf. Erstattung statische Berechtigung Daten für TXRSTBER werden zur Übergabe an KVPS Spec_Stat Ber_V150.docx Seite 39 10. Mai 2016

KVPT: Rücknahme der Statischen Berechtigung bereitgestellt Ablauf - Berechtigungsdaten lesen - Wird keine statische Berechtigung oder keine statische Berechtigung gemäß dieser Spec mit Kennung VDV (in den letzten 5 Byte des Bytestrings in Kap. 3 15 ) erkannt, so wird die Berechtigung mit Anzeige abgewiesen; - Berechtigungsdaten werden ausgewertet; - Signaturprüfung wird durchgeführt; - Falls negativ, wird die statische Berechtigung mit Anzeige abgewiesen und ggf. Erfassung (s. KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen) zur späteren Auswertung vorgenommen; - Prüfung der Berechtigung_ID gegen Sperrliste SLNM wird durchgeführt; - Im Falle eines Treffers wird die statische Berechtigung mit Anzeige abgewiesen und ggf. Erfassung (s. KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen) zur späteren Auswertung vorgenommen; - Zeitliche Gültigkeit der akzeptierten Berechtigung prüfen; Falls Gültigkeit abgelaufen, wird die statische Berechtigung mit Anzeige abgewiesen; - Prüfung o der enthaltenen ORG-IDs gegen Sperrliste Organisation; o der SAM-ID der Ausgabetransaktionskennung gegen Sperrliste SAM o der benutzten Signatur gegen Sperrliste asymmetrische Schlüssel o des benutzten MKPV-NM-MAC gegen Sperrliste symmetrische Schlüssel - Im Falle eines Treffers wird die statische Berechtigung mit Anzeige abgewiesen und ggf. Erfassung (s. KVPT: Gesperrte oder ungültige Statische Berechtigung erfas- Spec_Stat Ber_V150.docx Seite 40 10. Mai 2016

KVPT: Rücknahme der Statischen Berechtigung sen) zur späteren Auswertung vorgenommen; - Falls erforderlich Erstattung anstoßen, Preis, Zahlungsmittel, PROD_ID und BER_ID für Anwendungsfall Erstattung bereitstellen; - Rücknahmetransaktionsdaten für TXRSTBER werden zur Übergabe an KVP-System gespeichert; - Beenden der Rücknahme mit Anzeige. 6.1.1.7 KVPT: Statische Berechtigung erstatten KVPT: Statische Berechtigung erstatten Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Bei der Rücknahme einer statischen Berechtigung wird i. d. Regel eine Erstattung fällig. Diese findet gegen das Zahlungsmittel statt, das zum Erwerb der Statischen Berechtigung gedient hat. Dieses ist in einem Datenelement der statischen Berechtigung vermerkt. Bei Rücknahme im Prozess einer Änderung der statischen Berechtigung kann auch nur ein Teilbetrag oder kein Betrag erstattet werden. Dafür wird zusätzlich der Anwendungsfall.KVPT: Statische Berechtigung ausgeben ausgeführt. KVP-Terminal Rücknahme einer statischen Berechtigung Preis und Zahlungsmittel, PROD_ID und BER_ID der zurückzunehmenden statischen Berechtigung Rücknahme ist angestoßen Erstattung ist erfasst Ggf. Auslösung des Anwendungsfalles: KVPT: EFS gegen gesetzliches Zahlungsmittel zurückzahlen Ablauf - Speichern des Erstattungsvorganges mit PROD_ID / BER_ID zur Speicherung im KVP-System; Spec_Stat Ber_V150.docx Seite 41 10. Mai 2016

KVPT: Statische Berechtigung erstatten - Zahlungsprozess/Gutschrift anstoßen 6.1.1.8 KVPT: Statische Berechtigung ändern Wird mit den Anwendungsfällen KVPT: Statische Berechtigung zurücknehmen, ggf. KVPT: Statische Berechtigung erstatten+ KVPT: Statische Berechtigung ausgeben realisiert. 6.1.1.9 KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen Um systematische Angriffe und Betrugsfälle frühzeitig erkennen zu können, wird empfohlen, vereinfachte Kontrollnachweise (Rumpfkontrollnachweise) bei der Erfassung ungültiger oder auf der Sperrliste erfasster statischer Berechtigungen im Terminal zu erzeugen. Sie sind außerdem sinnvoll und notwendig für statistische Auswertungen. Dieser Anwendungsfall wird immer dann abgearbeitet, wenn eine gesperrte bzw. zeitlich o- der räumlich ungültige Berechtigung erkannt wird oder die Signaturprüfung fehlgeschlagen ist. KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Es wird eine statische Berechtigung an einem KVP- Terminal erfasst, die auf der Sperrliste SLNM steht, zu der auf der SLOS ein Sperrauftrag vorliegt bzw. die zeitlich oder räumlich ungültig ist. Es wird ein Datensatz erzeugt, der ins KVPS zur internen Auswertung weitergeleitet wird. KVP-Terminal. gesperrte oder ungültige statische Berechtigung. Berechtigung_ID. Berechtigungsdaten wurden erfasst. Datensatz für TXKNAWB ist erzeugt. Daten für TXKNAWB werden zur Übergabe an KVPS bereitgestellt Spec_Stat Ber_V150.docx Seite 42 10. Mai 2016

KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen Ablauf - Daten für TXKNAWB werden zur Übergabe an KVP- System gespeichert - Beenden der Aktion mit Anzeige 6.1.1.10 KVPT: Statische Berechtigung anzeigen KVPT: Kundenservice Statische Berechtigung anzeigen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Anzeige der Statische Berechtigung KVP-Terminal Kunde Anwahl des Anwendungsfalles Statische Berechtigung anzeigen Ausgabe einer Statische Berechtigung ist erfolgt Root-Schlüssels der VDV-KA-PKI ist vorhanden Benötigte Sub-CA-Zertifikate der VDV-KA-PKI sind geladen Bekannte Signaturzertifikate sind ggf. geladen bzw. Berechtigung_ID ist anderweitig im Terminal erfasst Sperrlisten SLNM und SLOS sind aktualisiert Anzeige der auf dem Medium gespeicherten Statischen Berechtigung Keine - Berechtigungsdaten lesen - Wird keine statische Berechtigung gemäß dieser Spec mit Kennung VDV (in den letzten 5 Byte des Bytestrings in Kap. 3 15 ) erkannt, wird der Prozess mit Anzeige abgebrochen - Berechtigungsdaten werden ausgewertet; - Signaturprüfung wird durchgeführt; Spec_Stat Ber_V150.docx Seite 43 10. Mai 2016

KVPT: Kundenservice Statische Berechtigung anzeigen - Falls negativ, wird die statische Berechtigung abgewiesen mit Anzeige und ggf. Erfassung (s. KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen) zur späteren Auswertung vorgenommen; - Prüfung der Berechtigung_ID gegen Sperrliste SLNM wird durchgeführt; - Im Falle eines Treffers wird die statische Berechtigung mit Anzeige abgewiesen und ggf. Erfassung (s. KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen) zur späteren Auswertung vorgenommen; - Prüfung o der enthaltenen ORG-IDs gegen Sperrliste Organisation; o der SAM-ID der Ausgabetransaktionskennung gegen Sperrliste SAM o der benutzten Signatur gegen Sperrliste asymmetrische Schlüssel o des benutzten MKPV-NM-MAC gegen Sperrliste symmetrische Schlüssel - Im Falle eines Treffers wird die statische Berechtigung abgewiesen mit Anzeige und ggf. Erfassung (s. KVPT: Gesperrte oder ungültige Statische Berechtigung erfassen) zur späteren Auswertung vorgenommen - Aufbereitung der Daten zur Anzeige auf dem Terminal- Display - Prozess beenden oder Übergang zum Anwendungsfall KVPT: Statische Berechtigung Beleg_drucken 6.1.1.11 KVPT: Statische Berechtigung Beleg_drucken KVPT: Kundenservice zum Ausdruck von Belegen Kurzbeschreibung Ausdruck eines Beleges für eine zuvor ausgegebene Statische Berechtigung Spec_Stat Ber_V150.docx Seite 44 10. Mai 2016

KVPT: Kundenservice zum Ausdruck von Belegen Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf KVP-Terminal/KVPS Kunde Anwahl des Belegdruckes Statische Berechtigung Ausgabe der Statischen Berechtigung ist erfolgt oder Anzeige der Statischen Berechtigung ist erfolgt Ausgabe eines Beleges (z. B. als Quittung) Keine - nach Ausgabe oder Anzeige für die Statische Berechtigung erfolgt die Abfrage, ob ein Belegdruck erfolgen soll - Aufbereitung Daten zur Ausgabe des Beleges (für die Ausgabe als Quittung ist die MwSt. auszuweisen) - Druck des Beleges und Ausgabe 6.1.1.12 KVPT: ZSAM-Zertifikat entgegennehmen KVPT: ZSAM-Zertifikat entgegennehmen Kurzbeschreibung Akteure Auslöser Eingehende Info Das KVPT benötigt ein ZSAM-Zertifikat zur Signatur bei der Ausgabe der statischen Berechtigung. Es wird im Barcode-Symbol mit ausgeliefert, um die signierte Berechtigung lesen zu können. Das ZSAM-Zertifikat für das im KVPT eingesetzte SAM wird durch das KVPS von der VDV-KA-PKI abgerufen und an das KVPT übergeben. KVPT, KVPS Meldung eines neuen ZSAM-Zertifikats durch das KVPS. Zertifikatsdaten Spec_Stat Ber_V150.docx Seite 45 10. Mai 2016

KVPT: ZSAM-Zertifikat entgegennehmen Vorbedingung Ergebnis Nachbedingung Ablauf Das benötigte Zertifikat liegt im KVPS vor (siehe AW: KVPS: ZSAM-Zertifikat verteilen). Zertifikat ist im KVPT verfügbar Keine - Zertifikat wird im KVPT zur weiteren Nutzung abgelegt - Empfang wird gegenüber KVPS quittiert 6.1.1.13 KVPT: Root- und CA-Zertifikate entgegennehmen KVPT: Root- und CA-Zertifikate entgegennehmen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Das KVPT benötigt neben dem im Barcode gelieferten ZSAM-Zertifikat gültige Root- und Sub-CA-Zertifikate der KA-PKI zur Anzeige der Statischen Berechtigung. Die Root- und CA-Zertifikate werden durch das KVPS von der VDV-KA-PKI heruntergeladen und an das KVPT übergeben. KVPT, KVPS Meldung der Root- und/oder Sub-CA-Zertifikate durch das KVPS. Zertifikatsdaten Die benötigten Zertifikate liegen im KVPS vor. Zertifikat(e) sind im KVPT verfügbar und werden bis zum Verfallszeitpunkt gespeichert Keine - Zertifikat(e) wird (werden) im KVPT zur weiteren Nutzung abgelegt - Empfang wird gegenüber KVPS quittiert Spec_Stat Ber_V150.docx Seite 46 10. Mai 2016

6.1.1.14 KVPT: Unvollständig ausgeführte Ausgabe von Statischen Berechtigungen im Terminal registrieren KVPT: Unvollständig ausgeführte Ausgabe von Statischen Berechtigungen im Terminal registrieren Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Werden Ausgaben statischer Berechtigungen nach dem Kommando Sign Entitlement unterbrochen/abgebrochen oder ist durch das Terminal auf Grund einer Fehlermeldung ein Ausgabefehler zu identifizieren (z.b. Druck/Auswurf des Barcodetickets nicht möglich), sind diese im Terminal zu registrieren und je SAM an den KVPS weiterzumelden. KVP-Terminal Abbruch der Ausgabe identifiziert keine keine Daten für TXTRANSABBRUCH sind erzeugt Daten für TXTRANSABBRUCH werden ins KVPS übergeben - Feststellen des Abbruches im Terminal - Erfassen der Allgemeinen Transaktionsdaten (siehe Tabelle 3-1 : Standarddatenstruktur statischer Berechtigungen in der VDV-Kernapplikation- am Beispiel des Referenz-EFS gemäß KA NM Spezifikation des MK PV-NM-MAC_ID und der Nutzungszähler dieses Schlüssels, der der berprodlogsamseqnummer entspricht - Bereitstellen der Daten für TXTRANSABBRUCH zur Übertragung in den KVPS - Übertragung der Daten für TXTRANSABBRUCH an das KVPS Spec_Stat Ber_V150.docx Seite 47 10. Mai 2016

6.1.2 Anwendungsfälle für KA-Referenzhintergrundsysteme 6.1.2.1 Anwendungsfälle im DLS Es kommen folgende Anwendungsfälle für das DLS zum Einsatz: DLS: Statische Berechtigung_Kontrolldaten verarbeiten DLS: EFS_Sperranforderung erzeugen DLS: EFS_Sperrmitteilung entgegennehmen DLS: EFS_Sperraufhebungsanforderung erzeugen DLS: EFS_Sperrfreigabemitteilung entgegennehmen DLS: Gesperrten oder ungültigen EFS erfassen DLS: EFS_PV-Kontrollmodul entgegennehmen DLS: EFS_DL-Kontrollmodul definieren DLS: EFS_DL-_Kontrollmodul verteilen DLS: ORG_Sperranforderung erzeugen DLS: Key_asym_Sperranforderung erzeugen DLS: Organisation_Sperrmitteilung entgegennehmen DLS: Key_asym_Sperrmitteilung entgegennehmen DLS: Sperrliste_NMkomplett anfordern DLS: Sperrliste_NMdifferenz anfordern DLS: Sperrliste_ORG anfordern DLS: Sperrliste_SAM anfordern DLS: Sperrliste_Key_asym anfordern DLS: Sperrlisten empfangen und aktivieren DLS: ORG_Sperraufhebungsanforderung erzeugen DLS: Key_asym_Sperraufhebungsanforderung erzeugen DLS: Organisation_Sperrfreigabemitteilung entgegennehmen DLS_ Key_asym_Sperrfreigabemitteilung entgegennehmen DLS: Root- und CA-Zertifikate herunterladen DLS: Root- und CA-Zertifikate verteilen Spec_Stat Ber_V150.docx Seite 48 10. Mai 2016

Anwendungsfälle zum EFS oder zur Systemorganisation, die identisch nutzbar sind, werden nicht gesondert für die statische Berechtigung beschrieben. Die Anwendungsfälle werden identisch gemäß (4) Systemlastenheft Teil: Dienstleister-System (DLS) benutzt. 6.1.2.1.1 DLS: Statische Berechtigung_Kontrolldaten verarbeiten DLS: Statische Berechtigung_Kontrolldaten verarbeiten Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Verarbeitung des Kontrollnachweises mit Signatur- Sicherung vom DLT und Weiterleitung an das PVS DLT, DLS, PVS DLT Daten für TXESTBER keine TXESTBER verarbeitet und weitergeleitet TXB/TXA von PVS empfangen - Daten für TXESTBER von DLT empfangen - TXESTBER prüfen und registrieren - TXESTBER an PVS weiterleiten 6.1.2.1.2 DLS: Root- und CA-Zertifikate herunterladen DLS: Root- und CA-Zertifikate herunterladen Kurzbeschreibung Akteure Auslöser Eingehende Info Von der VDV-KA-PKI werden gültige Root- und CA- Zertifikate abgerufen. DLS, VDV-KA-PKI Der Zeitpunkt für eine Prüfung auf neue Root- und/oder CA-Zertifikate ist erreicht. Root- und Sub-CA-Zertifikatsdaten Spec_Stat Ber_V150.docx Seite 49 10. Mai 2016

DLS: Root- und CA-Zertifikate herunterladen Vorbedingung Ergebnis Nachbedingung Ablauf In der VDV-KA-PKI sind neue Root- und/oder CA- Zertifikate vorhanden. Root- und/oder CA-Zertifikate sind im DLS verfügbar. keine - Prüfung auf Vorliegen neuer Root- und/oder CA- Zertifikate im LDAP-Verzeichnis der KA-PKI 19 19 Test-LDAP (Level 2): ldap://vdv.test.telesec.de:389 oder im LDAP-Browser eintragen: Wirk-LDAP (Level 3): ldap://ldap-vdv.telesec.de:389 oder ldap://ldap-vdv-ion.telesec.de:389 oder im LDAP-Browser eintragen: Spec_Stat Ber_V150.docx Seite 50 10. Mai 2016

DLS: Root- und CA-Zertifikate herunterladen - neue Zertifikatsdaten werden heruntergeladen 6.1.2.1.3 DLS: Root- und CA-Zertifikate verteilen DLS: Root- und CA-Zertifikate verteilen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Die von der VDV-KA-PKI heruntergeladenen gültigen Rootund CA-Zertifikate werden an die DLT verteilt, um sie für die Prüfung der Statischen Berechtigung zu verwenden. DLS, DLT Vorliegen neuer Root- und/oder CA-Zertifikate Root- und Sub-CA-Zertifikatsdaten Zertifikate wurden vom Trustcenter ins DLS heruntergeladen Spec_Stat Ber_V150.docx Seite 51 10. Mai 2016

DLS: Root- und CA-Zertifikate verteilen Ergebnis Nachbedingung Ablauf Zertifikatsdaten sind im DLT verfügbar Quittierung durch DLT liegt vor - Zertifikatsdaten werden an das DLT versendet - Empfangsquittung vom DLT erhalten und geprüft 6.1.2.2 Anwendungsfälle im KVPS Es kommen folgende Anwendungsfälle für das KVPS zum Einsatz: KVPS: Statische Berechtigung ausgeben KVPS: Statische Berechtigung zurücknehmen KVPS: Statische Berechtigung Kontrollnachweis bearbeiten KVPS: EFS_Sperranforderung erzeugen KVPS: EFS_Sperranforderung bearbeiten KVPS: EFS_Sperrauftrag und Sperrmitteilung erzeugen KVPS: EFS_Sperrmitteilung entgegennehmen KVPS: EFS_Sperraufhebungsanforderung erzeugen KVPS: EFS_Sperraufhebungsanforderung bearbeiten KVPS: EFS_Sperrfreigabeauftrag und Sperrfreigabemitteilung erzeugen KVPS: EFS_Sperrfreigabemitteilung entgegennehmen KVPS: Gesperrten oder ungültigen EFS erfassen KVPS: EFS_PV-Produktmodul entgegennehmen KVPS: EFS_KVP-Produktmodul definieren KVPS: EFS_KVP-Produktmodul verteilen KVPS: BER_Kontingent anfordern KVPS: BER_Kontingent Bestätigung entgegennehmen KVPS: SAM_Sperranforderung erzeugen KVPS: ORG_Sperranforderung erzeugen Spec_Stat Ber_V150.docx Seite 52 10. Mai 2016

KVPS: Key_sym_Sperranforderung erzeugen KVPS: Key_asym_Sperranforderung erzeugen KVPS: SAM_Sperrmitteilung entgegennehmen KVPS: Organisation_Sperrmitteilung entgegennehmen KVPS: Key_sym_Sperrmitteilung entgegennehmen KVPS: Key_asym_Sperrmitteilung entgegennehmen KVPS: Sperrliste_NMkomplett anfordern KVPS: Sperrliste_NMdifferenz anfordern KVPS: Sperrliste_ORG anfordern KVPS: Sperrliste_SAM anfordern KVPS: Sperrliste_Key_sym anfordern KVPS: Sperrliste_Key_asym anfordern KVPS: Sperrlisten empfangen und aktivieren KVPS: SAM_Sperraufhebungsanforderung erzeugen KVPS: ORG_Sperraufhebungsanforderung erzeugen KVPS: Key_sym_Sperraufhebungsanforderung erzeugen KVPS: Key_asym_Sperraufhebungsanforderung erzeugen KVPS: SAM_Sperrfreigabemitteilung entgegennehmen KVPS: Organisation_Sperrfreigabemitteilung entgegennehmen KVPS: Key_sym_Sperrfreigabemitteilung entgegennehmen KVPS: Key_asym_Sperrfreigabemitteilung entgegennehmen KVPS: SAM_Key laden/key löschen KVPS: SAM_Ausgabe registrieren KVPS: SAM verteilen KVPS: Unvollständig ausgeführte Ausgabe entgegennehmen und verarbeiten KVPS: Unvollständig ausgeführte Ausgabe an PVS melden KVPS: Statische Berechtigung_Transaktionsvollständigkeit prüfen KVPS: ZSAM-Zertifikat beantragen KVPS: ZSAM-Zertifikat verteilen KVPS: Root- und CA-Zertifikate herunterladen Spec_Stat Ber_V150.docx Seite 53 10. Mai 2016

Anwendungsfälle zum EFS oder zur Systemorganisation, die identisch nutzbar sind, werden nicht gesondert für die Statische Berechtigung beschrieben. Die Anwendungsfälle werden identisch gemäß (5) Systemlastenheft Teil: Kundenvertragspartner-System (KVPS) benutzt. Wenn Barcode-Tickets auf Grundlage der Statischen Berechtigung an Terminals bargeldlos gegen Akzeptanz einer ebezahlberechtigung (POB/PEB-autoload oder WEB) ausgegeben werden, sind die für die Bezahlung eines EFS mit einer ebezahlberechtigung relevanten Anwendungsfälle aus dem Systemlastenheft Teil: Kundenvertragspartner-System (KVPS) umzusetzen. 6.1.2.2.1 KVPS: Statische Berechtigung ausgeben KVPS: Statische Berechtigung ausgeben Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Verarbeitung des vom KVPT kommenden Berechtigungs- Ausgabenachweises zum TXASTBER und Weiterleitung an das PVS KVPT, KVPS, PVS KVPT Daten für TXASTBER Keine Daten zum TXASTBER verarbeitet und TXASTBER an PVS weitergeleitet Keine Daten für TXASTBER von KVPT empfangen TXASTBER prüfen und registrieren Berechtigungs-Verkauf im Verkaufsregister buchen Die Werte: berstatus = 7 und bersynchronnummer =1 sowie logtransaktionstyp.code = 1 werden zur Ausgabetransaktion im KVP-System nachträglich eingetragen und vorgehalten. TXASTBER an PVS senden Spec_Stat Ber_V150.docx Seite 54 10. Mai 2016

6.1.2.2.2 KVPS: Statische Berechtigung zurücknehmen KVPS: Statische Berechtigung zurücknehmen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Verarbeitung des vom KVPT kommenden Berechtigungs- Rücknahmenachweises zum TXRSTBER und Weiterleitung an das PVS KVPT, KVPS, PVS KVPT Daten zum TXRSTBER Berechtigung wird nur vom Primär-KVP zurückgenommen Daten zum TXRSTBER verarbeitet und an TXRSTBER PVS weitergeleitet Keine Daten zum TXRSTBER von KVPT empfangen TXRSTBER prüfen und registrieren Rücknahme im Verkaufsregister buchen TXRSTBER an PVS senden Anmerkung: Der Erstattungsprozess im KVPT generiert keine gesonderten Informationen für das HGS. Eine Teilerstattung ist durch Kombination von Rücknahme und Ausgabe einer neuen STB zu realisieren. 6.1.2.2.3 KVPS: Statische Berechtigung Kontrollnachweis bearbeiten KVPS: Statische Berechtigung Kontrollnachweis bearbeiten Kurzbeschreibung Akteure Verarbeitung des vom DLT über DLS und PVS kommenden Kontrollnachweises PVS, KVPS Spec_Stat Ber_V150.docx Seite 55 10. Mai 2016

KVPS: Statische Berechtigung Kontrollnachweis bearbeiten Auslöser PVS Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf TXESTBER Keine Kontrollnachweis statische Berechtigung verarbeitet Keine TXESTBER von PVS empfangen TXESTBER prüfen und registrieren 6.1.2.2.4 KVPS: ZSAM-Zertifikat beantragen Die VDV-PKI-Webseiten für die Beantragung von ZSAM-Zertifikaten sind zu erreichen über: https://vdv-web.telesec.de/cara-vdv (Level 3) http://vdv-test-pki.test.telesec.de/cara-vdv (Level 2). Dazu ist der Menüpunkt ZSAM-Zertifikat beantragen anzuwählen. Das SAM, zu dem das Zertifikat erstellt werden soll, ist auszuwählen. Das Zertifikat ist ins KVPS herunterzuladen und an die KVPT mit dem zugehörigen SAM zu verteilen. 6.1.2.2.5 KVPS: ZSAM-Zertifikat verteilen KVPS: ZSAM-Zertifikat verteilen Kurzbeschreibung Akteure Auslöser Bei den Service-Anwendungsfällen für eine statische Berechtigung wird der öffentliche Teil des bei der Ausgabe der statischen Berechtigung verwendeten Signaturschlüssels benötigt, um die Signatur über die Berechtigungsdaten zu prüfen. Dieser Schlüssel wird mit einem ZSAM-Zertifikat vom KVPS an das KVPT geliefert. KVPS Vorliegen eines ZSAM-Zertifikats, das zur Ausgabe der Spec_Stat Ber_V150.docx Seite 56 10. Mai 2016

KVPS: ZSAM-Zertifikat verteilen statischen Berechtigungen benötigt wird. Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Zertifikatsdaten des SAM-Signaturschlüssels. Zertifikat für Signaturschlüssel vom Trustcenter erstellt und ins KVPS heruntergeladen Zertifikatsdaten sind im KVPT verfügbar Quittierung durch KVPT liegt vor - Zertifikatsdaten werden an das KVPT versendet - Empfangsquittung vom KVPT erhalten und geprüft 6.1.2.2.6 KVPS: Root- und CA-Zertifikate herunterladen KVPS: Root- und CA-Zertifikate herunterladen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Von der VDV-KA-PKI werden gültige Root- und CA- Zertifikate abgerufen. KVPS, VDV-KA-PKI Der Zeitpunkt für eine Prüfung auf neue Root- und/oder CA-Zertifikate ist erreicht. Root- und Sub-CA-Zertifikatsdaten In der VDV-KA-PKI sind neue Root- und/oder CA- Zertifikate vorhanden. Root- und/oder CA-Zertifikate sind im KVPS verfügbar. keine - Prüfung auf Vorliegen neuer Root- und/oder CA- Zertifikate im LDAP-Verzeichnis der KA-PKI 20 20 Test-LDAP (Level 2): ldap://vdv.test.telesec.de:389 oder im LDAP-Browser eintragen: Spec_Stat Ber_V150.docx Seite 57 10. Mai 2016

Wirk-LDAP (Level 3): ldap://ldap-vdv.telesec.de:389 oder ldap://ldap-vdv-ion.telesec.de:389 oder im LDAP-Browser eintragen: Spec_Stat Ber_V150.docx Seite 58 10. Mai 2016

KVPS: Root- und CA-Zertifikate herunterladen - neue Zertifikatsdaten werden heruntergeladen 6.1.2.2.7 KVPS: Root- und CA-Zertifikate verteilen KVPS: Root- und CA-Zertifikate verteilen Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Die von der VDV-KA-PKI heruntergeladenen gültigen Rootund CA-Zertifikate werden an die KVPT verteilt, um sie für die Anzeige der Statischen Berechtigung zu verwenden. KVPS, KVPT Vorliegen neuer Root- und/oder CA-Zertifikate Root- und Sub-CA-Zertifikatsdaten Zertifikate wurden vom Trustcenter ins KVPS heruntergeladen Zertifikatsdaten sind im KVPT verfügbar Quittierung durch KVPT liegt vor - Zertifikatsdaten werden an das KVPT versendet - Empfangsquittung vom KVPT erhalten und geprüft Spec_Stat Ber_V150.docx Seite 59 10. Mai 2016

6.1.2.3 Anwendungsfälle im PVS Es kommen folgende Anwendungsfälle für das PVS zum Einsatz: PVS: Statische Berechtigung ausgeben PVS: Statische Berechtigung zurücknehmen PVS: Statische Berechtigung_Kontrolldaten verarbeiten PVS: EFS_Sperranforderung erzeugen PVS: EFS_Sperrmitteilung entgegennehmen PVS: EFS_Sperraufhebungsanforderung erzeugen PVS: EFS_Sperrfreigabemitteilung entgegennehmen PVS: EFS_PV-Produktmodul definieren PVS: EFS_PV-Produktmodul verteilen PVS: EFS_Produkt deaktivieren PVS: BER_Kontingent bearbeiten PVS: EFS_PV-Kontrollmodul definieren PVS: EFS_PV-Kontrollmodul verteilen PVS: Konfiguration_KOSE bearbeiten PVS: Organisation_Sperranforderung erzeugen PVS: Organisation_Sperrmitteilung entgegennehmen PVS: Organisation_Sperraufhebungsanforderung erzeugen PVS: Organisation_Sperrfreigabemitteilung entgegennehmen PVS: Key_asym_Sperranforderung erzeugen PVS: Key_asym_Sperrmitteilung entgegennehmen PVS: Key_sym_Sperranforderung bearbeiten PVS: Key_asym_Sperranforderung bearbeiten PVS: Key_sym_Sperrauftrag und Sperrmitteilung erzeugen PVS: Key_asym_Sperrauftrag und Sperrmitteilung erzeugen PVS: Key_asym_Sperraufhebungsanforderung erzeugen PVS: Key_asym_Sperrfreigabemitteilung entgegennehmen Spec_Stat Ber_V150.docx Seite 60 10. Mai 2016

PVS: Key_sym_Sperraufhebungsanforderung bearbeiten PVS: Key_asym_Sperraufhebungsanforderung bearbeiten PVS: Key_sym_Sperrfreigabeauftrag und Sperrfreigabemitteilung erzeugen PVS: Key_asym_Sperrfreigabeauftrag und Sperrfreigabemitteilung erzeugen PVS: Sperrliste_NMkomplett anfordern PVS: Sperrliste_NMdifferenz anfordern PVS: Sperrliste_ORG anfordern PVS: Sperrliste_SAM anfordern PVS: Sperrliste_Key_sym anfordern PVS: Sperrliste_Key_asym anfordern PVS: Sperrliste empfangen und aktivieren PVS: Sperrinformation anfordern und verarbeiten PVS: Unvollständig ausgeführte Ausgabe entgegennehmen und verarbeiten PVS: Statische Berechtigung_Transaktionsvollständigkeit prüfen PVS: Zertifikat melden PVS: SAM_Key freigeben PVS: Key laden/key löschen Anwendungsfälle zum EFS oder zur Systemorganisation, die identisch nutzbar sind, werden nicht gesondert für die Statische Berechtigung beschrieben. Die Anwendungsfälle werden gemäß (6) Systemlastenheft Teil: Produktverantwortlicher-System (PVS) identisch benutzt. Wenn Barcode-Tickets auf Grundlage der Statischen Berechtigung an Terminals bargeldlos gegen Akzeptanz einer ebezahlberechtigung (POB/PEB-autoload oder WEB) ausgegeben werden, sind die für die Bezahlung eines EFS mit einer ebezahlberechtigung relevanten Anwendungsfälle aus dem Systemlastenheft Teil: Produktiverantwortlichen-System (PVS) umzusetzen. 6.1.2.3.1 PVS: Statische Berechtigung ausgeben PVS: Statische Berechtigung ausgeben Spec_Stat Ber_V150.docx Seite 61 10. Mai 2016

PVS: Statische Berechtigung ausgeben Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Verarbeitung der Ausgabetransaktion_Statische Berechtigung KVPS, PVS KVPS TXASTBER keine TXASTBER verarbeitet Berechtigung registriert Berechtigungsstatus gesetzt keine - TXASTBER von KVPS empfangen Berechtigung registrieren Die Werte: berstatus = 7 und bersynchronnummer =1 sowie logtransaktionstyp.code = 1 werden zur Ausgabetransaktion im PV-System nachträglich eingetragen und vorgehalten. - Kontingent prüfen - Verkauf als Forderung gegen KVP buchen - berstatus speichern = ausgegeben 6.1.2.3.2 PVS: Statische Berechtigung zurücknehmen PVS: Statische Berechtigung zurücknehmen Kurzbeschreibung Akteure Auslöser Eingehende Info Verarbeitung des Rücknahmenachweis_Berechtigung KVPS, PVS KVPS TXRSTBER Spec_Stat Ber_V150.docx Seite 62 10. Mai 2016

PVS: Statische Berechtigung zurücknehmen Vorbedingung Ergebnis Nachbedingung Ablauf keine TXRSTBER verarbeitet Berechtigungsstatus aktualisiert keine - TXRSTBER von KVPS empfangen - TXRSTBER registrieren - ggf. Erstattung als Gutschrift für KVP buchen - berstatus speichern = zurückgenommen 6.1.2.3.3 PVS: Statische Berechtigung_Kontrolldaten verarbeiten PVS: Statische Berechtigung_Kontrolldaten verarbeiten Kurzbeschreibung Akteure Auslöser Eingehende Info Vorbedingung Ergebnis Nachbedingung Ablauf Das PVS erhält vom DLS die Kontrolldaten zur Auswertung und Archivierung. Er leitet sie an das KVPS weiter. DLS, PVS DLS TXESTBER keine Kontrolldaten verarbeitet und archiviert TXB, TXA senden TXB/TXA vom KVPS erwarten - TXESTBER von DLS empfangen - TXESTBER registrieren - TXESTBER an das KVPS weiterleiten Spec_Stat Ber_V150.docx Seite 63 10. Mai 2016

6.1.2.3.4 PVS: Unvollständig ausgeführte Ausgabe entgegennehmen und verarbeiten Im PVS sind Daten vom KVPS über abgebrochene Ausgaben (sofern dies am KVPT identifiziert werden konnten) zur Prüfung der Vollständigkeit der eingereichten mit dem in jedem SAM vorhandenen PV-Schlüssel erzeugten Ausgabetransaktionen für statische Berechtigungen entgegenzunehmen. 6.2 Ergänzung in der KA SST-Spezifikation 6.2.1 Elementarprozesse Es kommen folgende Elementarprozesse gemäß (3) KA SST-SPEC zum Einsatz: EP_Ausgabe_Statische Berechtigung EP_Bezahlung_gesZahl EP_Rücknahme_Statische Berechtigung EP_Rückzahlung_gesZahl EP_Änderung_Statische Berechtigung EP_Kontrolle_Statische Berechtigung EP_Erfassung_gesperrte / ungültige Statische Berechtigung EP_Anzeige_Statische Berechtigung EP_Belegdruck_Statische Berechtigung EP_Sperranforderung_Berechtigung EP_Sperranforderung_SAM EP_Sperranforderung_Organisation EP_Sperrauftrag_SAM EP_Sperrauftrag_Organisation EP_Sperranforderung_Key EP_Sperrauftrag_Berechtigung EP_Sperrauftrag_Key EP_Sperrlistenanforderung EP_Sperrlistenversand Spec_Stat Ber_V150.docx Seite 64 10. Mai 2016

EP_Sperraufhebungsanforderung_Berechtigung EP_Sperraufhebungsanforderung_SAM EP_Sperraufhebungsanforderung_Organisation EP_Sperraufhebungsanforderung_Key EP_Sperrfreigabeauftrag_SAM EP_Sperrfreigabeauftrag_Organisation EP_Sperrfreigabeauftrag_Berechtigung EP_Sperrfreigabeauftrag_Key EP_Konfiguration_Produktakzeptanten EP_Verteilung_PV-Produktmodul EP_Verteilung_KVP-Produktmodul EP_Verteilung_PV-Kontrollmodul EP_Verteilung_DL-Kontrollmodul EP_Deaktivieren_EFMProd EP_Konfiguration_KOSE EP_Verteilung_SAM EP_Verteilung_Zertifikate EP_Anforderung_Kryptogramm EP_Verteilung_Kryptogramm_Key EP_Sperrinfoanforderung und - versand Elementarprozesse, die identisch zum EFS nutzbar sind, werden nicht gesondert für die Statische Berechtigung beschrieben. Die Elementarprozesse werden identisch gemäß (3) KA SST-SPEC benutzt. Wenn Barcode-Tickets auf Grundlage der Statischen Berechtigung an Terminals bargeldlos gegen Akzeptanz einer ebezahlberechtigung (POB/PEB-autoload oder WEB) ausgegeben werden, sind die für die Bezahlung eines EFS mit einer ebezahlberechtigung relevanten Elementarprozesse aus der (3) KA SST-SPEC umzusetzen. Spec_Stat Ber_V150.docx Seite 65 10. Mai 2016

6.2.1.1 EP_Ausgabe_Statische Berechtigung Beschreibung: Der Elementarprozess EP_Ausgabe_Statische Berechtigung realisiert die Ausgabe einer statischen Berechtigung vom ReferenzTerminal_KVP auf einen Träger, die Generierung eines Ausgabe-Nachweises und die Weiterleitung des Ausgabe-Nachweises vom Referenz- Terminal_KVP über das ReferenzSystem_KVP zum ReferenzSystem_PV. Der ausgebende KVP wird dadurch bei allen der Berechtigung betreffenden Transaktionen als Primär-KVP auftreten. Teil-Prozesse, die durch das ReferenzTerminal_KVP mit dem Träger realisiert werden: - die Signatur-Sicherung der statischen Berechtigung Ausstellungsprozess., - die Ausgabe der Berechtigungstextdaten und der Berechtigung auf einen Träger oder Übertragung der Berechtigungstextdaten und der Berechtigung zur Ausgabe Teil-Prozesse, die durch das ReferenzSystem_KVP mit dem ReferenzSystem_PV realisiert werden: - die Übergabe des Ausgabe-Nachweises mit Signatur vom KVP an den PV. Beschreibung der Transaktionsdaten TXASTBER, ggf. TXUESTBER, ggf. TXSIGSTBER Relevante Schnittstelle(n): SST_NM=RT-KVP ( ) in der Spezialisierung SST_NM=RT-KVP_Statische Berechtigung_Ausgabe SST_PV=KVP ( ) in der Spezialisierung SST_PV=KVP_Statische Berechtigung_Ausgabe ggf. SST_PV=KVP_Statische Berechtigung_ Signatur anfordern SST_PV=KVP_Statische Berechtigung_ Signatur weiterleiten Wird ausgelöst durch: keine Spec_Stat Ber_V150.docx Seite 66 10. Mai 2016

Löst aus: Ist eine Bezahlung erforderlich, wird ein Elementarprozess zum Bezahlen ausgelöst. EP_Bezahlung_gesZahl ( Kap. 3.1.26, KA SST-Spezifikation) 6.2.1.2 EP_Rücknahme_Statische Berechtigung Beschreibung: Der Elementarprozess EP_Rücknahme_Berechtigung realisiert die Rücknahme einer statischen Berechtigung durch das ReferenzTerminal_KVP. Der Rücknahmenachweis der Berechtigung wird über das Referenzsystem_KVP an das Referenzsystem_PV gesendet. Bevor dieser EP durchgeführt wird, d.h. die Berechtigung zurückgenommen werden kann, wird die der Berechtigung entsprechende Erstattung ausgeführt. Teil-Prozesse, die durch das ReferenzTerminal_KVP mit dem Träger realisiert werden: - Signaturprüfung des Barcodes. Teil-Prozesse, die durch das ReferenzSystem_KVP mit dem ReferenzSystem_PV realisiert werden: - die Übergabe der Berechtigung vom KVP an den PV. Beschreibung der Transaktionsdaten TXRSTBER Relevante Schnittstelle(n): SST_NM=RT-KVP ( ) in der Spezialisierung SST_NM=RT-KVP_Statische Berechtigung_Rücknahme SST_PV=KVP ( ) in der Spezialisierung SST_PV=KVP_Statische Berechtigung_Rücknahme Wird ausgelöst durch: keine Löst aus: Einen Elementarprozess zur Rückzahlung ( 3.1.5 KA SST-Spezifikation) Bei Feststellung eines entsprechenden Sperrlisteneintrages optional: EP_Erfassung_gesperrte / ungültige Statische Berechtigung ( ) 6.2.1.5) Spec_Stat Ber_V150.docx Seite 67 10. Mai 2016

6.2.1.3 EP_Änderung_Statische Berechtigung Eine direkte Änderung der Statischen Berechtigung ist nicht möglich. Gewünschte Änderungen an einer Statischen Berechtigung werden durch eine Rücknahme einer Statischen Berechtigung und einen Neuverkauf einer Statischen Berechtigung realisiert. Dieses wird durch die Elementarprozesse EP_Rücknahme_Statische Berechtigung ( 6.2.1.2) und EP_Ausgabe_Statische Berechtigung ( 6.2.1.1) realisiert. 6.2.1.4 EP_Kontrolle_Statische Berechtigung Beschreibung: Der Elementarprozess EP_Kontrolle realisiert die Überprüfung des Vorliegens und der Gültigkeit einer statischen Berechtigung. Die Kontrolle erfolgt mit Erzeugung eines Kontrollnachweises. Teil-Prozesse, die durch das ReferenzTerminal_DL realisiert werden: - Erzeugung des KontrollNachweis_Statische Berechtigung durch das ReferenzTerminal_DL Teil-Prozesse, die durch das ReferenzSystem_DL mit dem ReferenzSystem_PV realisiert werden: - Einreichung des KontrollNachweis_Statische Berechtigung vom ReferenzTerminal_DL über des ReferenzSystem_DL an das für das in Anspruch genommene Produkt zuständige ReferenzSystem_PV Beschreibung der Transaktionsdaten TXESTBER Teil-Prozesse, die durch das ReferenzSystem_PV mit dem ReferenzSystem_KVP realisiert werden: - Weiterleitung des KontrollNachweis_Statische Berechtigung vom ReferenzTerminal_PV an das zuständige ReferenzSystem_KVP Beschreibung der Transaktionsdaten TXESTBER Relevante Schnittstelle(n): SST_NM=RT-DL ( ) in der Spezialisierung SST_NM=RT-DL_Statische_Berechtigung_Kontrolle Spec_Stat Ber_V150.docx Seite 68 10. Mai 2016

SST_PV=DL ( ) in der Spezialisierung SST_PV=DL_Statische_Berechtigung_Kontrolle SST_PV=KVP ( ) in der Spezialisierung SST_PV=KVP_Statische_Berechtigung_Kontrolle Wird ausgelöst durch: keine Löst aus: Bei Feststellung eines entsprechenden Sperrlisteneintrages optional: EP_Erfassung_gesperrte / ungültige Statische Berechtigung ( ) 6.2.1.5 EP_Erfassung_gesperrte / ungültige Statische Berechtigung Beschreibung: Der Elementarprozess EP_Erfassung_gesperrte/ungültige statische Berechtigung realisiert die Erfassung einer gesperrten oder ungültigen statischen Berechtigung. Der Elementarprozess wird ausgeführt, wenn die Prüfung ergeben hat, dass die gemäß Produkt_ID Referenz- Terminal_DL akzeptierte Berechtigung auf der SLNM steht, gemäß Sperreintrag auf der SLOS gesperrt ist, die zeitliche Gültigkeit abgelaufen oder keine räumliche Gültigkeit gegeben ist oder die Signaturprüfung negativ verlaufen ist. Die Prüfung selbst ist ein interner Prozess des ReferenzTerminal_DL oder des Referenz- Terminal_KVP. Der Empfänger der erfassten Daten wird entsprechend den Vorgaben zu den Kontrollprozessen beim DL von den daran eventuell Beteiligten festgelegt (vgl. auch KA Medien-ANW). Beschreibung der Transaktionsdaten, TXKNAWB Relevante Schnittstelle(n): nicht vorgeschrieben Wird ausgelöst durch: EP_Kontrolle_Statische Berechtigung oder EP_Rücknahme_Statische_Berechtigung Löst aus: Keine Spec_Stat Ber_V150.docx Seite 69 10. Mai 2016

6.2.1.6 EP_Anzeige_Statische Berechtigung Beschreibung: Die im 2D Barcode gespeicherten Berechtigungsdaten werden durch ein KVP- ReferenzTerminal angezeigt. s. Kap. 3 Standarddatenstruktur Statischer Berechti- Beschreibung der Transaktionsdaten gungen. Es findet kein Datenaustausch an den für KA SST-SPEC relevanten Schnittstellen statt. Relevante Schnittstelle(n): SST_NM=RT-KVP ( ) in der Spezialisierung SST_NM=RT-KVP_Statische Berechtigung_Anzeige Wird ausgelöst durch: keine Löst aus: Bei Feststellung eines entsprechenden Sperrlisteneintrages optional: EP_Erfassung_gesperrte / ungültige Statische Berechtigung ( ) 6.2.1.7 EP_Belegdruck_Statische Berechtigung Beschreibung: Der Ausdruck eines Beleges zu einer als 2D Barcode gespeicherten Statischen Berechtigung erfolgt an einem KVP-Referenz-Terminal. Im Falle des Belegdrucks sind mehrwertsteuerliche Belange zu beachten. Relevante Schnittstelle(n): SST_NM=RT-KVP ( ) in der Spezialisierung SST_NM=RT-KVP_Statische Berechtigung_Belegdruck Wird ausgelöst durch: EP_Ausgabe_Statische Berechtigung ( ) EP_Anzeige_Statische Berechtigung ( ) Löst aus: keine Spec_Stat Ber_V150.docx Seite 70 10. Mai 2016

6.2.2 Applikationsdatensätze 6.2.2.1 TXASTBER Transaktionsdatensatzbeschreibung zur Übertragung einer Ausgabemeldung einer statischen Berechtigung (STB). Die Berechtigung wird mit ihrer Identifikation, einschließlich der für sie eingerichteten Kundenvertragsdaten und Tarifparameter, gemeldet. Für statistische Auswertungen können in der Struktur BerechtigungTarifbereichZusatz optional auch zusätzliche Daten (zu den im statischen produktspezifischen Teil enthaltenen Daten) an die Hintergrundsysteme übertragen werden. Werden keine ergänzenden Daten übertragen, entfällt dieser Block. Die Daten mit den zulässigen Datenelementen sind aus dem Wertevorrat Baukasten_Berechtigung Tarifbereich zu entnehmen. Die Transaktion STB enthält in Transaktionsdatensatz die identische Struktur der NM- Ausgabetransaktionen gemäß KA-NM-Spec (s. Anlage 1). Die Version des verwendeten PV-Schlüssels, die für die Transaktionsprüfung (Vollständigkeit der je KVPT eingereichten TXASTBER) im PVS benötigt wird, befindet sich in den Daten der Berechtigung und somit auch in der Signatur (berstb Signatur), und zwar in diesem Fall in den kodierten Daten der Signatur. Durch Dekodierung erhält der PV die Versionsinformation. Spec_Stat Ber_V150.docx Seite 71 10. Mai 2016

Abbildung 1: Ausgabe Statische Berechtigung TXASTBER 6.2.2.2 TXESTBER Dieser Datensatz ist für alle Kontrollprozesse, die mit einer statischen Berechtigung stattfinden, relevant. Die Transaktion STB enthält in Transaktionsdatensatz die identische Struktur der NM- Fahrttransaktionen gemäß KA-NM-Spec (s. Anlage 1). Spec_Stat Ber_V150.docx Seite 72 10. Mai 2016

Abbildung 2: Kontrolle Statische Berechtigung TXESTBER 6.2.2.3 TXRSTBER Transaktionsdatensatz für die Rückgabe einer Statischen Berechtigung. Die Transaktion STB enthält in Transaktionsdatensatz die identische Struktur der NM- Rücknahmetrantsaktionen gemäß KA-NM-Spec (s. Anlage 1). Spec_Stat Ber_V150.docx Seite 73 10. Mai 2016

Abbildung 3: Rücknahme Statische Berechtigung TXRSTBER 6.2.2.4 TXKNAWB TKNAWB wird um das Datenelement logvalidation_code erweitert. Mit diesem Datenelement kann zusätzlich der Grund der Erfassung angegeben werden. Spec_Stat Ber_V150.docx Seite 74 10. Mai 2016

Abbildung 4: Kontrollnachweis gesperrte/ungültige Berechtigung TXKNAWB 6.2.3 Basisdatensätze 6.2.3.1 Signatur-Sicherung Daten zur Signatur-Sicherung einer statischen Berechtigung: Abbildung 5: Basisdatensatz zur Signatur-Sicherung einer statischen Berechtigung Spec_Stat Ber_V150.docx Seite 75 10. Mai 2016

6.2.3.2 Zertifikatsdaten Daten eines Zertifikats Abbildung 6: Basisdatensatz zur Beschreibung eines Zertifikats 6.3 Ergänzung in der KA BOM-Spezifikation 6.3.1 Konstruierte Datentypen SIGNATUR OctetString-Darstellung einer Signatur für Statische Berechtigungen Attribute Attributname Beschreibung Kard. Wertebereich Format wert Signatur einer Statischen Berechtigung mit 128 Byte, einschließlich 1..n OctetString(128) 106 Byte Nutzdaten Tabelle 6-1: Elementare Datentypen SIGNATUR Restdaten OctetString-Darstellung von Fülldaten in einer Signatur für Statische Berechtigungen Attribute Attributname Beschreibung Kard. Wertebereich Format wert Restdaten der Nutzdaten einer Statischen Berechtigung ab Byte 107 1..n OctetString(x) Tabelle 6-2: Elementare Datentypen Restdaten Spec_Stat Ber_V150.docx Seite 76 10. Mai 2016

Zertifikatsdaten OctetString-Darstellung eines Zertifikates für Barcodes der Variante 2 Attribute Attributname Beschreibung Kard. Wertebereich Format wert Inhaltsdaten eines Zertifikats 1..n OctetString(200) Tabelle 6-3: Elementare Datentypen Zertifikatsdaten CHRDaten OctetString-Darstellung der CHR-Daten eines Zertifikates für Barcodes der Variante 1 Attribute Attributname Beschreibung Kard. Wertebereich Format wert Inhaltsdaten eines Zertifikats 1..n OctetString(12) Tabelle 6-4: Elementare Datentypen CHRDaten CARDaten OctetString-Darstellung der CAR-Daten eines Zertifikates für Barcodes der Variante 2 Attribute Attributname Beschreibung Kard. Wertebereich Format wert Inhaltsdaten eines Zertifikats 1..n OctetString(8) Tabelle 6-5: Elementare Datentypen CARDaten 6.3.2 Aufzählungstypen (Codes) Aufzählungstypen (Codes) Validation_CODE siehe KA BOM-SPEC SignaturTyp_CODE Es wird der Typ einer Signatur (z.b. MAC, digitale Signatur) codiert. Mögliches Äquivalent in ENV1545 Security Services Attribute Attributname Beschreibung Kard. Wertebereich Format Spec_Stat Ber_V150.docx Seite 77 10. Mai 2016

SignaturTyp_CODE Code 1..1 ENUMERATED { 2 Key Triple-DES MAC gemäß der SAM-Spezifikation 1 INT1 Signatur der XML-Transaktion, Länge 128 Byte, Verfahren RSASSA-PSS gemäß PKCS#1 2 Signatur der Statischen Berechtigung, Länge 128 Byte Zertifikat gemäß ISO/IEC 9796-2 Schema 1 3 Signatur der Statischen Berechtigung, Länge 128 Byte PKCS#1_v1.5 (Signatur im Anhang) 4 RFU für weitere Signatur- bzw. MAC-Verfahren und Schlüssellängen } Tabelle 6-6: Aufzählungstypen (Codes) SignaturTyp_CODE (Ergänzung Tabelle 6-64 KA BOM-Spezifikation) Spec_Stat Ber_V150.docx Seite 78 10. Mai 2016

6.4 Ergänzung in der KA KUSCH-Spezifikation Für die Anwendung der Statischen Berechtigung als 2D Barcode, stehen folgende Logos zur Verfügung, die am Terminal die Ausgabe kennzeichnen bzw. an Kontrollterminals anzeigen, wo der Kunde sein Barcode-Ticket anhalten muss. Abbildung 7: Logo für die Barcodeanwendung Abbildung 8: Logo Barcodekontrolle horizontale Scanfläche Spec_Stat Ber_V150.docx Seite 79 10. Mai 2016

Abbildung 9: Logo Barcodekontrolle vertikale Scanfläche Die Pfeilspitzen können jeweils in die benötigte Richtung der am Terminal integrierten Scanfläche gedreht werden. Die Rechte für die Verwendung der Logos liegen bei der VDV eticket Service GmbH & Co. KG. Spec_Stat Ber_V150.docx Seite 80 10. Mai 2016