VDV-Kernapplikation€¦ · - TSM-Connector (falls die Funktionalität zur Kommunikation mit einem...

LuKA LuKA / OTA-Provisioning VDV-Kernapplikation

SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 1 von 98 März 2011

VDV-Kernapplikation

Spezifikation von Luftschnittstellen in einem VDV-Kernapplikations-konformen interoperablen Mobile Ticketing in Verbindung mit einer passiven Near Field Communication (NFC) Verkaufs- und Erfassungsstruktur

Erstellung der notwendigen Spezifikationen für die Umsetzung der VDV-KA auf NFC-fähigen Mobiltelefonen mit Nutzung des Applikationsdownloads über das GSM-/UMTS-Netzwerk der Mobilfunkbetreiber.

Kurztitel: SPEC_LuKA_OTAPROV

Thema: Spezifikationen für die Umsetzung der VDV-KA auf NFC-fähigen Mobiltelefonen mit Nutzung des Applikationsdownloads über das GSM-/UMTS-Netzwerk der Mobilfunkbetreiber.

Dateiname: SPEC_LUKA_OTAPROVSYS_1.0.doc

Erstellt am: 22.03.2010

Zuletzt geändert am: 19.04.2011 09:03:00

Version: 1.0

Ersteller: ATOS ORIGIN/CUBIC/ESOL

Abnahme am: 24.03.11



Versionsverwaltung

Version Bearbeiter Datum Bemerkung

0.1

0.2/0.3

ATOS

ATOS/

CUBIC/

ESOL/

DB

22.03.2010

Erstellung Dokumentgliederung

Erstellung UML Modelle

0.4 ATOS/

CUBIC/

ESOL

24.09.2010 Internal Review Version

0.5 ATOS/

CUBIC/

ESOL

05.11.2010 Einarbeitung von Anmerkungen nach

Internal Review

0.6 ATOS/ CUBIC/ ESOL


Internal Review

0.7 ATOS/ CUBIC/ ESOL

23.11.2010 Version für externes Review

0.8 ATOS/

CUBIC


External Review

ATOS/

CUBIC

02.02.2011 Einarbeitung von Anmerkungen des

External Reviews

1.0 VDV KA KG

18.03.2011 Kap. 7.2 eingefügt, Finalisieren des Dokumentes

Prüfung

Version Datum Prüfung Freigabe Bemerkung



Inhaltsverzeichnis

Kurztitel: SPEC_LuKA_OTAPROV 1 1. Projektinformation 10

1.1. Ziel und Umfang 10 2. Systemkontext 10

2.1. Einleitung 10 2.2. Systemkontext 10

3. Akteure (Rollen) 14 3.1. Übersicht 14 3.2. Externe Rollen 16

3.2.1. SE_Owner 16 3.2.2. SE_Security_Manager 16 3.2.3. Secure Element (SE)_Retailer 16

3.3. KA-Rollen 17 3.3.1. Applikationsherausgeber (AH) 17 3.3.2. KA_Registrar 17 3.3.3. KA-Sicherheitsmanager 17 3.3.4. KA-Trustcenter 18 3.3.5. Applikationsausgeber (KVP_NMApp) 18 3.3.6. Applikationsausgeber (KVP_HandsetApp) 18

3.4. KA-OTA-Provisioning Rollen 18 3.4.1. KA-OTA_Provisioning Manager 18 3.4.2. Secure Element Trusted Service Manager (SE_TSM) 19 3.4.3. SE_Controlling_Authority 19 3.4.4. KA-NMApp_Konfigurator 20 3.4.5. KA-NMApp_Personalisierer 20 3.4.6. KVP_HandsetApp_Loader 20

3.5. Sonstige Rollen 20 3.5.1. Mobilfunkanbieter 20 3.5.2. Technologielieferanten 21

3.6. Hinweise zur Allokation von Rollen 21 4. Funktionale Systembeschreibung 23

4.1. Hauptprozess 23 4.2. Unterprozesse und beteiligte Systeme 25 4.3. Fachliche Komponenten der KA-NM-Handsetservices 26 4.4. Weitere Aspekte 28

5. Funktionale Architektur 29 5.1. KA-OTA-Supplymanagement 30 5.2. TSM-Funktionalität 30 5.3. KA-Nm-Konfiguration (NM-Config) 33 5.4. Software und Konfigurationsmanagement 34

6. Anwendungsfälle und Fachklassen 35 6.1. Fachklassenmodell 35 6.2. Anwendungsfälle 36

6.2.1. Prüfen der Voraussetzung 38 6.2.2. Übergabe von Software 41 6.2.3. Übergabe von SD-Positivliste 44 6.2.4. Laden des KA Handsetservices 46 6.2.5. Löschen der KA-NM-Handsetservices 49 6.2.6. Sperren/Entsperren des KANM 51



6.2.7. Update des KA-NM-Handsetservices 53 7. Umsetzung der nicht funktionalen Anforderungen 55

7.1. Zusammenhang von Anwendungsfällen zu nicht funktionalen Anforderungen 55 7.2. Sicherheitsbetrachtung 64

7.2.1. Bestandsaufnahme 64 7.2.2. Schutzbedarfsanalyse 64

7.2.2.1. Schutzbedarfsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“ 67

7.2.2.2. Schutzbedarfsanalyse im Anwendungsfall „Übergabe von Software“ 68

7.2.2.3. Schutzbedarfsanalyse im Anwendungsfall „Laden, des VDV KA NM Handset-

Services (Cardlet)“ 70

7.2.2.4. Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA

NM“ 71

7.2.3. Bedrohungsanalyse 72 7.2.3.1. Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“ 73

7.2.3.2. Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“ 74

7.2.3.3. Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-

Services (Cardlet)“ 75

7.2.3.4. Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“

77

7.2.4. Maßnahmen 78 7.2.4.1. Betrachtung von Maßnahmen im Anwendungsfall „Prüfen der

Voraussetzungen“ 78

7.2.4.2. Betrachtung von Maßnahmen im Anwendungsfall „Übergabe von Software“ 80

7.2.4.3. Betrachtung von Maßnahmen im Anwendungsfall „Laden des VDV KA NM

Handset-Services (Cardlet)“ 81

Mit Hilfe des mit dem GP Secure Messaging aufgebrachten Konfigurator-Schlüssel wird sich

das Cardlet authentisiert und ein Sessionkey vereinbart, auf dessen Basis dann die Integrität

und Authentizität der Nachrichten zur Erzeugung des Schlüsselpaares im SE sowie zur

Ausstellung und Einbringung des Zertifikats gesichert werden. 82

7.2.4.4. Betrachtung von Maßnahmen im Anwendungsfall „Sperren/Entsperren des

VDV KA NM“ 82

8. Schnittstellen 83 8.1. Schnittstellen zwischen Mobiltelefon-Komponenten 84 8.2. Schnittstelle zwischen OTA-Provisioning-System und NFC-Handset 84 8.3. Schnittstelle zwischen KVPS und OTA-Provisioning-System 84 8.4. Schnittstellen zum Sicherheitsmanagement-Dienstleister der VDV-KA KG 91

9. Anhang 92 9.1. Ergänzungen der vorhanden KA-Spezifikationen Einleitung 92 9.2. Übersicht über die TSM-Deploymentmodelle und deren Sicherheits- und Vertragsanforderungen 92 9.3. Exemplarische Realisierung des KA Handset Services Ladens mit Hilfe eines



dedizierten TSM-Connectors 93 9.4. Konfigurationsmanagement für KA-NM-Handsetservices 96 9.5. Literaturverzeichnis 98



Abbildungsverzeichnis:

Abbildung 1: Systemkontext .................................................................................................11

Abbildung 2: Rollenmodell KA-OTA-Provisioning .................................................................15

Abbildung 3 Übersicht des Hauptprozesses ........................................................................24

Abbildung 4: Komponente der KA-NM-Handsetservices .......................................................26

Abbildung 5: Komponente KA-OTA-Supplymanagement ......................................................30

Abbildung 6: TSM OTA Interaktion .......................................................................................31

Abbildung 7: Komponente NM Konfigurator ..........................................................................33

Abbildung 8: Komponente CM Repository ............................................................................34

Abbildung 9: Fachklassen ....................................................................................................35

Abbildung 10: Anwendungsfälle ...........................................................................................37

Abbildung 11: Prüfen der Voraussetzung .............................................................................38

Abbildung 12: Übergabe von Software .................................................................................41

Abbildung 13: Übergabe von SE-Positivliste .........................................................................44

Abbildung 14: Laden des KA Handsetservices .....................................................................46

Abbildung 15: Löschen der KA-NM-Handsetservices ...........................................................49

Abbildung 16: Sperren/Entsperren des KA NM .....................................................................51

Abbildung 17: Update des KA-NM-Handsetservices .............................................................53

Abbildung 18: Schnittstellen zu beteiligten Systemen ...........................................................83

Abbildung 19: Laden des TSM-Connector MIDlets ...............................................................94

Abbildung 20: Cardlet Laden Sequenzdiagramm..................................................................95

Abbildung 21 ........................................................................................................................96



Abkürzungsverzeichnis

AFB automatisierte Fahrberechtigung

AH Applikationsherausgeber

AHS Applikationsherausgebersystem

APP Applikation

APP_ID Applikations-Identifikation

BIP Bearer Independent Protocol

(Sub) CA Certificate Authority

CI Check-in

CICO Check-in/Check-out

CO Check-out

DL Dienstleister

DLT Dienstleisterterminal

DLS Dienstleistersystem

EFM Elektronisches Fahrgeldmanagement

EFS Elektronischer Fahrschein

EP Elementarprozess

ggf. Gegebenenfalls

GP GlobalPlatform

GPRS General Packet Radio Service

GPS Global Positioning Service

GSM Global System for Mobile Communications

HGS Hintergrundsystem

HTTP(S) HyperText Transfer Protocol (Secure)

ID Identifikation

ISD Issuer Security-Domain

i. d. R. in der Regel

i. a. Im Allgemeinen

ION Interoperabilitätsnetzwerk

IP Internet-Protocol

J2ME Java Platform 2, Micro Edition

KA Kernapplikation

KA-NMApp KA-Nutzermediumapplikation der VDV-KA-KG

KOSE Kontrollservice (Sperrlistenservice) als Bestandteil des KA-Sicherheitsmanagements



KOSES Kontrollservicesystem

KVP Kundenvertragspartner

KVP-APP Applikationsausgeber

KVP-HandsetApp KVP Handset Applikation

KVPT Kundenvertragspartnerterminal

KVPS Kundenvertragspartnersystem

ms Millisekunde

MSISDN Mobile Subscriber ISDN Number

NDEF NFC-Data-Exchange-Format

NFC Near Field Communication

NM Nutzermedium

ÖPV Öffentlicher Personenverkehr

ORG Organisation

ORG_ID Organisations-Identifikation

PEB Pre-paid-Berechtigung

PKI Public Key Infrastructure

POP Post-paid Berechtigung

PROD_ID Produkt-Identifikation

OTA Over The Air

PUK Public Key/Personal Unblocking Key

PV Produktverantwortlicher

PVS Produktverantwortlichensystem

RF Radio Frequency

RT ReferenzTerminal

SD Security-Domain

SE Secure Element

(S)FTP (Secure) File Transfer Protocol

SIM Subscriber Identity Module

SOAP Simple Object Access Protocol

SMS Short Message Service

SSH Secure SHell

SST Schnittstelle

SWP SingleWireProtocol

TAC Type Allocation Code

TSM Trusted Service Manager

http://en.wikipedia.org/wiki/ISDN



TX(*) Transaktionsdatensatz

UHF Ultra-High-Frequency

UMTS Universal Mobile Telecommunications System

VDV Verband Deutscher Verkehrsunternehmen

VDV-KA KG VDV Kernapplikations GmbH&Co.KG

UML Unified Modeling Language

UMTS Universal Mobile Telecommunications System

USIM Universal Subscriber Identity Module

WEB Werteinheitenberechtigung

WiFi Firmenkonsortium, das Geräte mit Funkschnittstellen zertifiziert



1. Projektinformation

1.1. Ziel und Umfang Ziel ist des vorliegenden Dokumentes ist die notwendige Spezifikationen für die Umsetzung der VDV-KA auf NFC-fähigen Mobiltelefonen mit Nutzung des Applikationsdownloads über das GSM-/UMTS-Netzwerk der Mobilfunkbetreiber. Dabei sollen erste parallele Pilotanwendungen im Feld zur Verifizierung der Spezifikationen genutzt werden. Diese Arbeiten erfolgen außerhalb des Projektes unter Mitwirkung der im Reviewboard vertretenen Unternehmen.

Grundsätzlich sind die beschriebenen Prozesse für das Laden der KA-NMApp und der anschließenden Konfiguration auch für Chipkarten im „nicht OTA“ Fall anwendbar. Hierzu ist insbesondere die Ergänzung zur Nutzermediums Spezifikation [10] hilfreich und im Bezug auf Abläufen, Rollen und Sicherheitsmechanismen vollständig anwendbar.

2. Systemkontext

2.1. Einleitung Der Systemkontext Abbildung 1 schafft ein Verständnis über das Umfeld des zu spezifizierenden Systems. Hiermit wird durch externe Systeme und Akteure das Umfeld beschrieben, die mit dem System interagieren. Der Systemkontext definiert also den Rahmen innerhalb dessen Anforderungen an das System gestellt werden.

Eine Abgrenzung ist hierbei zu den ggf. noch zu definierenden Rollen zu ziehen. Rollen, die in diesem Zusammenhang zu spezifizierende fachliche Funktionen subsumieren und hierarchisieren, sind fachliche Funktionen bzw. Komponenten, die innerhalb des Systems wirken. Diese sind in [12] spezifiziert.

2.2. Systemkontext Das folgende Diagramm (Abbildung 1) stellt den Systemkontext dar und zeigt somit den Gültigkeitsbereich für die aufgestellten Anforderungen.



composite structure Systemkontext OTA Prov isioning System

OTA Prov isioning

System

(from KA OTA Provisioning System)

AH Trustcenter

NFC-Handset

mit SE

Kundenv ertragspartnersystem

KVPS

Chipkarte

Kunde

(from Rollen)

KA Handsetserv ice

Hersteller(from Rollen)

Applikationsherausgebersystem

AHS

beauftragt

erhält Positivliste für SEs

erhält KA Handsetservices

(insbes. KA NmApp) von

schließt Vertrag über Nutzung

KA Handsetservices mit

besitzt

erhält KA NmApp von

erhält Arbeitsaufträge zur Ausführung

OTA Provisioning Services

erhält KA NM

Handsetservices

erhält Cert-PUK-NM von

Abbildung 1: Systemkontext1



Im Folgenden werden die Rollen und externen Systeme sowie deren Interaktion erläutert.

KA-NM-Handsetservice Lieferant

Der KA-NM-Handsetservice Lieferant ist zuständig für die Entwicklung und Lieferung der KA-NM-Handsetservices2 und ggf. zusätzlicher benötigter Komponenten:

- KA-NMApp (Nutzermediums Chipkartenanwendungen; ist erforderlich) - KVP-HandsetApp (Mensch Maschine Interface; ist optional) - Discoverymanager Konfiguration (Metadaten; ist optional)

Gegebenenfalls werden zusätzlich Komponenten geliefert

- TSM-Connector (falls die Funktionalität zur Kommunikation mit einem TSM nicht über die Firmware des Mobilgerätes erbracht wird, siehe Abschnitt 9.3)

- Weitere in die KA-Security-Domain einzubringende Chipkartenanwendungen

Kunde mit Trägermedium

Dies ist der Kunde des KVP. Er ist im Besitz eines Mediums, auf das die KA-NM-Handsetservices aufgebracht werden sollen. Bei dem Medium kann es sich um ein NFC-fähiges Mobiltelefon (allg. Handset) handeln oder eine andere Form von Trägermedium, wie beispielsweise eine Chipkarte.

KVPS

System eines Kundenvertragspartners, das abhängig vom Anwendungsfall

- benötigte Software zur Verfügung stellt oder aktualisiert. - das System beauftragt das OTA-Provisioning-System KA-NM-Handsetservices

aufzubringen, zu aktualisieren oder zu löschen (siehe auch Kapitel 0). - den Status des aufgebrachten oder den Fortgang des aufzubringenden KA-NM-

Handsetservice abfragt.

Trustcenter

Das Trustcenter ist zuständig für das Sicherheitsmanagement. Es stellt das Zertifikate Cert-PUK-NM für die KA-NMApp bereit.

NFC-Handset mit Secure Element als Trägermedium der KA-NMApp

Das NFC-Handset stellt ein nicht zu veränderndes externes System mit vorgegebenen Schnittstellen dar. In das NFC-Handset bzw. in das hierüber administrierte Secure Element (SE) werden KA-NM-Handsetservices eingebracht, insbesondere die KA-NMApp.

2 Die KA-NM-Handsetservices werden ausführlich in Abschnitt 0 geschrieben.



Die Schnittstellen, die das NFC-Handset hierzu anbietet, sind:

Mobiler Datenkanal: Wide Area Network, z.B. IP Protokoll über GPRS/UMTS

Bearer Independend Protocol (BIP) zum Zugriff auf das Secure Element unabhängig vom Kommunikationskanal

ISO 18092, ISO 14443

Display

Tastatur bzw. Touchscreen (i.a. Möglichkeit zur alphanumerischen Eingabe)

Sofern eine Java Microedition -Umgebung3 vorhanden ist: JSR 177, JSR 257

Das NFC-Handset enthält eine sichere Plattform, das sog. Secure Element (SE). Das SE muss den Sicherheitsanforderungen der VDV KA KG genügen (vgl. KA_NM_SYSLH). Ein SE enthält einen zugriffsbeschränkten Bereich, der in einer unsicheren Umgebung sicher administriert werden kann. Eine Ausprägung der sicheren Plattform kann eine (U)SIM-Karte sein.

Die Gestaltung des Secure Elements wird durch den SE_Owner definiert (dieser wird detailliert im Rollenmodell Kapitel 3 beschrieben), so dass die Anforderungen des geforderten Sicherheitsstandards erfüllt sind. Der SE_Owner ist Eigentümer des zugriffsbeschränkten Bereiches des Secure Elements.

Chipkarte als Trägermedium

Über die Teilfunktionalität NM-Config des OTA-Provisioning-Systems kann auf eine geeignete Chipkarte eine KA-NMApp geladen und konfiguriert werden. Dies entspricht dem in [7] beschriebenen Vorgang.

3 J2ME wird im Rahmen von LuKA als Referenzplattform betrachtet.



3. Akteure (Rollen)

Die UML verfügt über kein Artefakt „Rollen“, so dass die „Rollen“ im UML-Modell auf „Akteure“ abgebildet sind. Die Rollen bilden die oberste Ebene des Akteur-Modells, das durch Bildung von Spezialisierungen für eine Realisierung verfeinert werden kann, z.B. zur Abbildung der internen Organisation eines Rolleninhabers.

3.1. Übersicht Die nachfolgende Abbildung zeigt die in Bezug auf das OTA-Provisioning-System relevanten Rollen und deren wesentliche Beziehungen.

Die Darstellung ist keine vollständige Modellierung aller Beziehungen zwischen den Rollen. Sie zeigt vielmehr die wesentlichen Beziehungen anhand des Hauptanwendungsfalls der Auslieferung von KA-Nm-Handservices auf ein NFC-Handset mit Secure-Element.

"Invoke"-Beziehungen zeigen die Beziehungen für die operative Durchführung der Auslieferung. Diese "Invoke"-Beziehungen sind noch keine Modellierung der Schnittstellen der technischen Systeme.

"Dependency"-Beziehungen zeigen die Beziehungen zur Schaffung des organisatorischen Rahmens und der Etablierung einer vertrauenswürdigen Umgebung.



uc Rollenmodell KA OTA Prov isioning System

Kunde

KA-Handsetserv ice

Hersteller

KA TrustcenterKVP NmApp

KA-OTA_Prov isioning

Manager

SE_TSM KA-NmApp_Konfigurator

KA-NmApp_Personalisierer

AH

SE_Owner

SE_Controlling

Authority

NFC-Handset

mit SE

SE_RetailerMobilfunkanbieter

Rollenmodell OTA Provisioning

LuKA AP230

Die Darstellung ist keine vollständige Modellierung aller Beziehungen

zwischen den Rollen. Sie zeigt vielmehr die wesentlichen Beziehungen

anhand des Hauptanwendungsfalls der Auslieferung eines KA Handservices

(enthält inbes. die KA NmApplikation) auf ein NFC-Handset mit SE.

"Invoke"-Beziehungen zeigen die Beziehungen für die operative Durchführung

der Auslieferung. Diese "Invoke"-Beziehungen sind noch keine Modellierung

der Schnittstellen der technischen Systeme.

"Dependency"-Beziehungen zeigen die Beziehungen zur Schaffung des

organisatorischen Rahmens und der Etablierung der einer vertrauenswürdigen

Umgebung.

KVP HandsetApp

KVP

KVP Berechtigung

KVP_HandsetApp_Loader

autorisiert

von

KA

Ausgabetransaktion

«invokes»

«invokes»

Zertifikatabruf

«invokes»

Security

Domain

«invokes»

autorisiert

von

autorosiert

von

«invokes»

autorisiert

von

KA NmApp

konfigurieren

«invokes»

KA NmApp

personalisieren

«invokes»

Nutzungsvertrag

TeilnahmevertragPKI

Realisierung

KA Handsetservice

Bestellung

«invokes»

besitzt

KA Handsetservice

ausliefern

«invokes»

KA NmApp

install ieren

«invokes»

«invokes»

loads

Abbildung 2: Rollenmodell KA-OTA-Provisioning

In den nachfolgenden Abschnitten werden die Rollen beschrieben, wobei sich die Beschreibung gliedert in

Rollen, die die Welt außerhalb des Gestaltungsbereichs der KA abbilden (externe Rollen);

existierende KA-Rollen, die für das OTA-Provisioning erweitert werden;

Rollen innerhalb des OTA-Provisioning-Systems;

sonstige Rollen (erweiterter Kontext).



3.2. Externe Rollen

3.2.1. SE_Owner Der SE_Owner spezifiziert die Gestaltung des Secure Elements (SE), sodass insbesondere das von der VDV KA KG definierte Sicherheitsniveau sichergestellt ist. Der SE_Owner definiert wirtschaftliche und rechtliche (Rahmen-) Bedingungen für die Nutzung des SE durch Applikationen.

Der SE_Owner autorisiert Applikationsausgeber (KVP_NMAPP), um Applikationen auf dem SE zu laden (initialisieren) und zu löschen.

Der SE_Owner stellt sicher, dass die Plattform-Umgebung als eine vertrauenswürdige und isolierte Umgebung für die Ausführung der KA-NMApp eingesetzt werden kann und dass die Unbedenklichkeit der Applikation gegenüber der SE-Umwelt und gegenüber anderen Applikationen auf dem SE geprüft ist.

Die Bezeichnung „SE_Owner“ bezieht sich auf die im Kontext von NFC Mobiltelefonen eingeführte Bezeichnung „Secure Element“ als Sammelbegriff für verschiedene Bauformen, z.B. (U)SIM, Secure Digital-Karten, Bluetooth-Sticker, Embedded Chipkarten.

Im Kontext von Multiapplikationskarten werden die allgemeineren Begriffe User-Medium (anstelle von SE-Element) und User-Medium-Owner (anstelle SE_Owner) genutzt.

3.2.2. SE_Security_Manager Subrolle des SE_Owners

Der SE_Security_Manager überwacht im Auftrag des SE_Owners die Einhaltung der Sicherheitsanforderungen für die Secure Elements sowohl in Bezug auf die Herstellung als auch die Nutzung.

Der SE_Security_Manager definiert den Validierungsprozess für die Secure Elements (Rolle „Validation Authority“ in der GlobalPlatform).

Der SE_Security_Manager ist Ansprechpartner des KA-Sicherheitsmanagement bzgl. der Sicherstellung der von der KA geforderten Sicherheitsstandards von KA Nutzermedien.

3.2.3. Secure Element (SE)_Retailer Der SE_Retailer gibt Secure Elements (SE) an Kunden aus und realisiert dafür den Kunden-Service. Der SE_Retailer ist als Vertragspartner gegenüber dem Kunden für die Einhaltung der zugesicherten Sicherheitsstandards und die Funktionsfähigkeit des SE verantwortlich.

Der SE_Retailer hat keine direkten Beziehungen zu den KA-Rollen oder den KA-OTA-Provisioning Rollen. Ein KVP wird jedoch ggf. einen Kunden an den SE_Retailer verweisen, sofern ein Kundenserviceanliegen die Funktionsfähigkeit bzw. Funktionsweise des Secure Elements betrifft. Es ist dem KVP freigestellt, im Rahmen seines Kundenservices auch Beziehungen zu relevanten SE_Retailern zu unterhalten.



3.3. KA-Rollen

3.3.1. Applikationsherausgeber (AH) KA-Rolle

Erweiterung der bislang in der KA definierten Funktionen:

Der AH gewährleistet, dass ausschließlich den Anforderungen der KA genügende SE zum Einsatz kommen. Umgekehrt stellt der AH dem SE_Owner die erforderlichen Informationen bereit, die der SE_Owner benötigt, um die KA als Applikation auf seinem Secure-Element zuzulassen.

Der AH stellt in den Teilnahmeverträgen sicher, dass nur registrierte Secure-Elements für seine Applikationen zur Anwendung kommen.

Der AH genehmigt den applikationsausgebenden Kundenvertragspartnern (KVP-NMAPP) mittels der Teilnahmeverträge die Ausgabe von Applikationen über registrierte SE_TSM und KA_NMApp_Konfiguratoren.

In Analogie zu dem für Secure Elements (in Mobiltelefonen) festgelegten Modell gewährleistet der AH, dass dies auch für alle in der KA zum Einsatz kommenden Nutzermedien Dritter (z.B. Multiapplikationschipkarten) gilt. In diesem Fall stellt der AH dem User-Medium Owner (in Analogie zum SE_Owner) die erforderlichen Informationen bereit, die der User-Medium Owner benötigt, um die KA als Applikation auf seinem User-Medium (in Analogie zum Secure Element) zuzulassen.

3.3.2. KA_Registrar KA-Rolle, Subrolle des AH


Der KA_Registrar registriert die zugelassenen User-Medium-Owner, die zugelassenen SE_Owner, die zugelassenen User-Medium bzw. SE_TSM und KA-NMApp_Konfiguratoren sowie die zugelassenen und zertifizierten User Media und Secure Elements für den Applikatonsdownload.

3.3.3. KA-Sicherheitsmanager KA-Rolle, Subrolle des AH


Der KA_Sicherheitsmanager gewährleistet die sichere Bereitstellung der Sicherheitskomponenten für die Applikation, abgestimmt mit dem SE_Security_Manager, der die Sicherheitsstandards für die SE definiert.

Der KA-Sicherheitsmanager spezifiziert die Sicherheitsanforderungen der Applikation für die SE_TSM und KA_NMApp_Konfiguratoren und gibt die relevanten Schnittstellen zur Übergabe der Zertifikate und SE-Positiv-Listen der Applikation vor.



3.3.4. KA-Trustcenter KA-Rolle, Subrolle des AH

Kurzzusammenfassung der wesentlichen Eigenschaften in Bezug auf das OTA Provisioning.

Das KA-Trustcenter bildet die Wurzel der PKI innerhalb der KA. Es stattet die Beteiligten mit vertrauenswürdigen digitalen Identitäten aus. Dazu zählt insbesondere auch die Erstellung von Zertifikaten über die öffentlichen Schlüssel einer Instanz der KA Nutzermedium-Applikation.

3.3.5. Applikationsausgeber (KVP_NMApp) KA-Rolle, Subrolle eines Kundenvertragspartners (KVP)

Der KVP_NMApp schließt Verträge mit SE_Ownern zur Nutzung von deren Secure Elements. Dies kann in Form direkter Verträge erfolgen oder auch indirekt, wenn ein SE_TSM diese zur Verfügung stellt.

Der KVP_NMApp lässt die Einbringung der KA-NMApp auf das SE des SE_Owners von dem AH autorisieren.

Der KVP_NMApp initialisiert über SE_TSM und KA-NMApp_Konfigurator die betriebsbereite KA-NMApp auf Secure Elements geeigneter NFC Mobiltelefone und personalisiert diese KA-NMApps über den KA_NMApp_Personalisierer.

3.3.6. Applikationsausgeber (KVP_HandsetApp) KA-Rolle, Subrolle eines Kundenvertragspartners (KVP)

Der KVP_HandsetApp stellt dem Kunden auf dessen NFC-Handset die optionale KVP-HandsetApp zur Verfügung.

Die KVP-HandsetApp muss nicht zwangsläufig als eigenständiges Programm der mobilen Plattform (z.B. als MIDlet, siehe Referenzplattform) realisiert werden, sondern kann auch als Webapplikation auf der UICC implementiert werden (Smart Card Web Server). In diesem Fall werden beide KVP_* Rollen durch dieselbe Organisation ausgefüllt.

3.4. KA-OTA-Provisioning Rollen

3.4.1. KA-OTA_Provisioning Manager Der KA-OTA_Provisioning Manager steuert im Auftrag eines oder mehrerer KVPs den Gesamtablauf zur Bereitstellung eines betriebsbereiten KA-NM-Handsetservice auf dem NFC Handset des Kunden. Der Gesamtablauf umfasst: Laden der KA-NMApp ( SE_TSM), Konfiguration der geladenen KA-NMApp ( KA-NMApp_Konfigurator) sowie Installation der KA Handset Applikationen und Konfiguration des NFC-Discoverymanagers.

Die KA Ausgabetransaktion ( KA-NMApp_Personalisierer) wird nicht vom Provisioning Manager gesteuert. Die Ausgabetransaktion wird als erste „Nutzungstransaktion“ gesehen, die mit dem KVP-System ausgeführt wird. Es ist dem KVP jedoch freigestellt, die Ansteuerung des KA-NMApp_Personalisierer an das technische System des KA-OTA_Provisioning Managers zu delegieren.



Der KA-OTA_Provisioning Manager kümmert sich um alle Dienste rund um die technischen Kernfunktionen SE_TSM und KA_NMApp_Konfigurator. Dies umfasst insbesondere auch Ermittlung der vom SE_TSM benötigten Informationen über das NFC Handset des Kunden.

Der KVP benennt dem KA-OTA_Provisioning Manager die auszubringenden KA-NM-Handsetservices Konfigurationen (NMApp + KVP-HandsetApp + ggf. weitere Konfigurationsvorgaben) und stellt den ausführenden Rollen die entsprechenden Objekte zur Verfügung (z.B. dem SE_TSM die KA-NMApp).

3.4.2. Secure Element Trusted Service Manager (SE_TSM) Der SE_TSM führt im Auftrag des Applikationsausgebers (KVP_APP) - autorisiert durch den SE_Owner und den Applikationsherausgeber (AH) – das Laden (Initialisieren), Löschen, Aktualisieren, Sperren von KA-NMApp auf dem SE im Kontext der durch das SE bereitgestellten Managementumgebung (GlobalPlatform oder gleichwertige Systeme) durch.

Der SE_TSM setzt autorisiert durch SE_Owner und Applikationsherausgeber (AH) das Supportmanagement um, wenn Konflikte beim Laden oder bei der Aktualisierung der Applikation auftreten (z.B. Überlauf der Kapazität des SE, Unverträglichkeit von Applikationen, ...).

Der SE_TSM arbeitet beim Aufbau des für das Laden der Applikation erforderlichen Sicherheitskontextes und der sicheren Durchführung des Ladens der Applikation mit der SE_Controlling_Authority zusammen.

Der SE_TSM führt ausschließlich Operationen im Kontext der durch das SE bereitgestellten Managementumgebung (GlobalPlatform oder gleichwertige Systeme) durch, d.h. er behandelt die KA-NMApp als „Black Box“. In Bezug auf den Vorgang des Ladens der KA-NMApp bedeutet dies, dass die KA-spezifische Initialisierung des KA-Sicherheitssystems innerhalb der KA-NMApp von einer weiteren Rolle, dem KA-NMApp_Konfigurator, übernommen wird.

Der Zuschnitt der Rolle SE_TSM ist kompatibel zur Definition des Trusted Service Managers (TSM) in den GlobalPlatform Spezifikationen.

3.4.3. SE_Controlling_Authority Die SE_Controlling_Authority ist eine vertrauenswürdige dritte Partei sowohl für den SE_Owner als auch den applikationsausgebenden KVP (KVP-NMApp), vgl. GlobalPlatform Spezifikationen zur Rolle Controlling Authority.

Die SE_Controlling_Authority ermöglicht die sichere und vertrauliche Initialisierung der Applikation während des Downloadprozesses. Hierzu sind unterschiedliche organisatorische und technische Modelle möglich, vgl. GlobalPlatform Spezifikationen. Die für ein SE anwendbaren Modelle werden vom SE_Owner (gestützt auf den SE_Security_Manager) und dem Applikationsherausgeber (gestützt auf den KA-Sicherheitsmanager) autorisiert. Der von dem KVP-NMAPP beauftragte SE Application Lifecycle Manager (entspricht dem TSM in der GlobalPlatform Spezifikation) und die SE_Controlling_Authority sind verantwortlich für die Implementierung der entsprechenden Prozesse und technischen Schnittstellen.

In einem Modell, in dem der SE_Owner der KA eine eigene GlobalPlatform Security-Domain zuweist, wäre der Applikationsherausgeber (AH) geeignet, die Rolle SE_Controlling_Authority auszufüllen. In anderen Szenarien wird die SE_Controlling_Authority de facto vom SE_Owner bestimmt.



3.4.4. KA-NMApp_Konfigurator Der KA-NMApp_Konfigurator konfiguriert im Auftrag des Applikationsausgebers (KVP-NMAPP) - autorisiert durch den Applikationsherausgeber (AH) – eine in das SE (bzw. allgemein in ein Nutzermedium) geladene KA Applikation, so dass diese anschließend betriebsbereit ist, d.h. durch die KA Applikationsausgabetransaktion in Umlauf gebracht werden kann.

Wichtigstes Element des Konfigurationsvorgangs ist die Initialisierung des KA-Sicherheitssystems, d.h. die Erzeugung des Public/Private Key der KA-NM-Applikationsinstanz und dessen Beglaubigung durch ein Zertifikat. Der KA-NMApp_Konfigurator betreibt dazu eine KA Sub-RA und tauscht Daten mit dem KA-Trustcenter aus.

Die Prozesse und technischen Einrichtungen des KA-NMApp_Konfigurators werden durch den KA-Sicherheitsmanager validiert.

3.4.5. KA-NMApp_Personalisierer Der KA-NMApp_Personalisierer personalisiert im Auftrag des Applikationsausgebers (KVP-NMAPP) eine betriebsbereite KA-NMApp. Dies umfasst die Ausführung der KA Applikationsausgabetransaktion sowie (optional) die Initialisierung des Kundenprofils (Teil der KA-NM-Applikation) mit den Daten des künftigen Karteninhabers.

Der KVP stellt dem KA-NMApp_Personalisierer die dazu benötigten KVP-Schlüssel zur Verfügung.

3.4.6. KVP_HandsetApp_Loader Der KVP_HandsetApp_Loader sorgt im Auftrag der Subrolle KVP_HandsetApp des Applikationsausgebers für den Download und die Installation der KA-HandsetApp (Mensch-Maschine-Interface für den Fahrgast zum Tätigen von Einstellungen, ggf. Kaufen von EFS, ggf. CICO-Service).

Ein KVP_HandsetApp_Loader kann auch im Auftrag eines KVP tätig werden, wenn auf einem NFC-Handset (mit bereits vorhandener KA-NMApp und KVP-HandsetApp) eine weitere KVP-HandsetApp geladen werden soll.

3.5. Sonstige Rollen

3.5.1. Mobilfunkanbieter Der Mobilfunkanbieter schließt mit Nutzern Verträge über die Nutzung von Mobilfunkleistungen.

Der Mobilfunkanbieter kann gleichzeitig auch SE_Owner sein (wenn das SE in Form der (U)SIM-Karte vorliegt), siehe SE_Owner.



3.5.2. Technologielieferanten Die Lieferantenrollen KA-NMApp-Hersteller, KA-HandsetApp-Hersteller, Handset-Hersteller etc. sind nicht spezifikationsbedürftig. Soweit diese Lieferanten spezielle technische Parameter oder organisatorische Prozesse einzuhalten haben, so werden diese von den Auftraggebern (KVP_NMApp, SE_Owner, …) den Lieferanten vorgegeben. Die Komponenten und/oder Hersteller müssen teilweise von dem AH und/oder dem SE_Owner zertifiziert werden.

3.6. Hinweise zur Allokation von Rollen Die in den vorherigen Abschnitten beschriebenen Rollen stellen funktional abgegrenzte Bereiche dar. Nachfolgend sollen Hinweise gegeben werden, wie sich insbesondere die Rollen des Abschnitts 3.4 auf reale Organisationen (Unternehmen) abbilden lassen.

KA-OTA_Provisioning Manager

Der KA-OTA_Provisioning Manager handelt im Auftrag des KVP. Er kann also auch durch den KVP in einem eigenen technischen System realisiert werden.

Alternativ bietet es sich an, einen technischen Dienstleister mit der Durchführung zu beauftragen. Die Funktion des KA-OTA_Provisioning Manager ist stark technisch geprägt, so dass die KVP-übergreifende Nutzung einer entsprechenden Plattform realistisch erscheint.

SE_TSM

Der SE_TSM handelt im Auftrag des KVP. Er kann also prinzipiell auch durch den KVP in einem eigenen technischen System realisiert werden. Die technologischen und organisatorischen Anforderungen sind jedoch so speziell, dass dies kein realistisches Szenario ist. Der SE_TSM wird in aller Regel durch entsprechend spezialisierte technische Dienstleister implementiert werden.

KA-NMApp_Konfigurator

Analog dem SE_TSM ist auch hier davon auszugehen, dass der KA-NMApp_Konfigurator in aller Regel durch entsprechend spezialisierte technische Dienstleister implementiert werden wird.

KA-NMApp_Personalisierer

Der KA-NMApp_Personalisierer handelt im Auftrag des KVP. Er kann also auch durch den KVP in einem eigenen technischen System realisiert werden.

In Bezug auf KA-NMApp in NFC Mobiltelefonen ist das benötigte technische System eng verwandt mit dem technischen System für die Ausgabe von Berechtigungen. Insofern erscheint die Realisierung in einem eigenen technischen System des KVP (ggf. auch einem von mehreren KVP gemeinsam beschafften und betriebenen System) durchaus realistisch.



Alternativ kann auch ein technischer Dienstleister eingesetzt werden, der eine geeignete Serviceplattform betreibt.

KA-HandsetApp_Loader

Der KA-HandsetApp_Loader handelt im Auftrag des KVP. Er kann also auch durch den KVP in einem eigenen technischen System realisiert werden.

Analog dem KA-OTA_Provisioning Manager bietet es sich jedoch an, einen technischen Dienstleister mit der Durchführung zu beauftragen. Die Funktion des KA-HandsetApp_Loader ist stark technisch geprägt, so dass die KVP-übergreifende Nutzung einer entsprechenden Plattform realistisch erscheint.



4. Funktionale Systembeschreibung

Das in der vorliegenden Spezifikation beschriebene OTA Provisioning System stellt die grundlegenden Prozesse des Installierens, Konfigurierens und des Verwaltens von sogenannten KA-NM-Handsetservices im NFC-Handset zur Verfügung.

Dabei werden als KA-NM-Handsetservices alle fachlichen Komponenten verstanden, die zur Nutzung der KA auf NFC-Handsets entweder erforderlich oder optional wünschenswert sind (siehe auch Abschnitt 0).

Für die Durchführung der Aufgaben erhält das System die zur Verteilung an die Handsets erforderliche Software vom KVPS (der KA-Handsetservice Lieferant liefert die entsprechende Software zuvor an den KVP), speichert diese in einem internen Repository ab, beziehungsweise aktualisiert die dort bereits vorhandenen Software Versionen, und stellt die Komponenten dann seinerseits zur Verteilung an die Mobiltelefone bereit.

Dabei werden grundsätzlich alle direkt mit Installation, Konfiguration und Verwalten der KA-NM-Handsetservices auf dem Handset in Verbindung stehender OTA Prozesse vom KVPS des zum Mobiltelefonbesitzer gehörenden KVP in Auftrag gegeben. Die Aktivität fließt vom KVPS über das OTA Provisioning System zum NFC-Handset.

Für die Adressierung des NFC-Handsets wird im Standardfall die MSISDN angenommen. Die Verwendung anderer Adressierungsarten unter Einbeziehung alternativer Registrar-Systeme ist dennoch denkbar.

4.1. Hauptprozess Der wichtigste Prozess des OTA Provisioning ist die Installation oder die Wiederherstellung einer nutzbaren Gesamtkonfiguration der KA-NM-Handsetservices. Die Wiederherstellung einer nutzbaren Konfiguration kann zum Beispiel durch den Tausch des Telefons, den Tausch der SIM Karte oder den Wechsel eines externen Secure Elements erforderlich werden.

Der Hauptprozess führt also zur Verwendbarkeit des NFC-Mobiltelefons als KA-Medium und umfasst die Schritte:

Prüfung, ob das Handset die Voraussetzungen erfüllt.

Identifikation der erforderlichen Version(en) der KA-NM-Handsetservices, insbesondere auch Prüfung der Kompatibilitäten mit bereits vorhandenen Komponenten der KA-NM-Handsetservices.

Einbringen der KA-NM-Handsetservices (bzw. der fehlenden Komponenten) in den entsprechenden kompatiblen Versionen.

Falls erforderlich: Anstoßen des Lifecycle der KA-NMApp bis hin zum Status Operational. Hierzu ist insbesondere das Generieren des NM Schlüsselpaares innerhalb der KA-NMApp, das Auslesen des Schlüssels sowie die anschließende Einbringung des Zertifikates der VDV Sub-CA der VDV-PKI über den öffentlichen Schlüssel erforderlich.

Optional

Die oben beschriebenen Schritte führen zur Erstellung eines KA-Mediums im Secure-



Element. Der KVP Personalisierer kann (muss aber nicht) die anschließend stattfindende KA Personalisierung an das OTA-Provisioning-System delegieren. Dies ist im Hinblick auf Nutzerfreundlichkeit sinnvoll, weil erst nach der KA Applikationsausgabe das KA-Medium für den Mobiltelefonbesitzer sinnvoll verwendbar ist.

Nicht nur die Personalisierung kann das KVP System an das OTA-Provisioning-System delegieren, sondern weitergehend auch die Ausgabe der initialen Automatischen Fahrberechtigung auf das neue KA-Medium. Zu diesem Zweck nutzt das KVPS das OTA-System wie ein KVP-Terminal im Aktionslistenverfahren und übergibt den in [11] definierten Datensatz TXAAUFBER an das OTA-Provisioning-System. Im Gegensatz zu der Definition in [11] muss für diesen Fall die Einschränkung entfallen, dass im TXAAUFBER keine Fahrberechtigungen vom Typ AFB (POP, PEB, WEB und WES-AFB) enthalten sein dürfen.

Insgesamt ergibt sich der in Abbildung 3 gezeigten Gesamtablauf.

sd Hauptprozess - Übersicht

KVPT nahe Funktion - optional

Einrichtung KA

Security-Domain

Laden der NmApp

und Konfiguration

der Applikation

KA-Personalisierung Ausgabe des

initialen EFS

Abbildung 3 Übersicht des Hauptprozesses

Für die in Abbildung 3 als optional gekennzeichnete Schritte muss das OTA-Provisioning-System Teile der KVPT Funktionalität integrieren. Dies führt notwendigerweise dazu, dass das OTA-Provisioning-System über eine Verwaltung der KVP- und PV-Schlüssel verfügen muss. Diese Erhöhung der technischen Anforderungen ist der Grund warum die Funktionalität in realisierten Systemen auch vom KVPS (bzw. KVPT) durchgeleitet werden kann. In diesem Fall ist es die Aufgabe des OTA-Systems, dem KVPS (bzw. KVPT) ein „Over-The-Air“-Stream zur Verfügung zu stellen, mit dessen Hilfe es direkt Chipkartenkommandos mit der KA-NMApp austauschen kann.

Neben dem Hauptprozess existieren weitere Prozesse, die für die Sperrung des Nutzermediums4 (Sperrung/Entsperrung 6.2.6) oder für die Übertragung von Softwarekomponenten sowie der anderen zu verteilenden Artefakte an das OTA-Provisioning-System verantwortlich sind.

4 Hier wird unter der Sperrung/Entsperrung die Änderung der Sichtbarkeit/Selektierbarkeit der

gesamten Applikation verstanden, nicht die in der KA vorgesehene Sperrung/Entsperrung der KA-NMApp, die auf Applikationsebene stattfindet.



4.2. Unterprozesse und beteiligte Systeme Das OTA-Provisioning-System bedient sich zweier Unterprozesse. Der eine ist verantwortlich für die Kommunikation und Vorbereitung des Secure Elements und wird im weiteren TSM Prozess genannt. Der andere Prozess dient der Einbringung des KA Mediums. Beide Teilprozesse werden von eigenständigen Komponenten bereitgestellt, die bezüglich der technischen Realisierung extern sein können. Im Systemkontext werden sie als zum OTA-Provisioning System-gehörend angenommen.

TSM-Funktionalität

Die Einrichten einer KA-Security-Domain und das Laden der Applikationsdaten werden durch den mit dem Secure Element konjugierten TSM durchgeführt. Hierzu delegiert das OTA- Provisioning-System die entsprechenden Teilprozesse an die TSM-Funktionalität. In einem realisierten System ist die TSM-Funktionalität sowohl gesamthaft intern, extern oder verteilt vorstellbar. Um den konjugierten TSM festzustellen, muss das System zunächst Daten zur Identifikation des Secure Elements ermitteln. Mit diesen Daten kann zunächst auf den SE_Owner geschlossen und damit wiederum auf den zuständigen, weil durch den SE_Owner autorisierten, TSM. Die Daten des Secure Elements werden vom System gegenüber einer Positivliste unterstützter Secure Elements geprüft und mit Hilfe der oben erläuterten Routing-Datenbank wird dann der zugeordnete TSM ermittelt.

NM-Config

Mit Hilfe der gesicherten Kommunikation des TSMs werden die KA-Security-Domain5, die NM Applikationsdaten sowie die root-Daten PuK.Root eingebracht. Die NM-Config Komponente des OTA-Provisioning-Systems nimmt zunächst die Rolle AppLoader ein (siehe [10]), lädt die Applikation und bringt den Datensatz PrK.Config, der der Authentifizierung im nächsten Prozessschritt dient, ein. Der anschließende Prozess der Konfiguration generiert das zum Medium gehörende Schlüsselpaar und bringt abschließend das vom Trustcenter des Applikationsherausgebers erhaltend Zertifikat Cert-PuK-NM sowie die appInstanz_ID ein.

5 Ggf. wird direkt die Issuer-Secure-Domain (ISD) genutzt und keine dedizierte KA-SD eingebracht.



4.3. Fachliche Komponenten der KA-NM-Handsetservices

Abbildung 4: Komponente der KA-NM-Handsetservices

Die Abbildung zeigt die fachlichen Komponenten der KA-NM-Handsetservices im Kontext des NFC Mobiltelefons. Der Zugriff des OTA-Provisioning-Systems auf das Mobiltelefon erfolgt grundsätzlich über das Mobilfunknetzwerk. Das zwischen OTA-Provisioning-System und Handset verwandte Protokoll wird vom Betreiber des Systems festgelegt, eine Festlegung dieses systeminternen Protokolls ist nicht sinnvoll. Die im Verlauf des Ladens der KA-Handset-Services einzubringenden Komponenten sind das KA Medium, optional die KVP-HandsetApp und ebenfalls optional die Discoverymanager-Konfiguration. Die nachfolgende Tabelle führt die Verantwortlichkeiten dieser Komponenten auf.



KA Medium (muss) Secure Element mit eingebrachter KA-Security-Domain / Schlüsseln sowie einer KA-NMApp. Die Applikation kann im Status CONFIGURATION oder OPERATIONAL sein. Im letzten Fall ist sie über die kontaktlose KA-Schnittstelle selektierbar.

KVP-HandsetApp (optional)

Applikation die den über das Mobilfunknetz verlaufenden Nachrichtenfluss zwischen KA-NMApp und KVPS kontrolliert (siehe [12]). Sie kann, muss aber nicht. im Verlaufe der OTA-Prozesse eingebracht werden, da sie nicht zwingend notwendig für die Nutzung des Mediums ist. Die Installation im Verlaufe der KA-NM-Handsetservices hat jedoch aus Sicht des Handset Nutzers einen klaren Bedienvorteil6. Die KVP- HandsetApp kann als Java MIDlet implementiert werden; in diesem Fall stehen die in JSR 177 und JSE 257 definierten APIs für den Zugriff auf das Secure Element, NFC Controller und Discoverymanager zur Verfügung.

Discoverymanager Konfiguration (optional)

Die Selektierbarkeit der KA-NMApp über die kontaktlose KA-Schnittstelle wird durch die Konfiguration des NFC – Discoverymanagers gewährleistet, dieser ist Bestandteil der NFC-Infrastruktur des NFC-Handsets. Abhängig von der Mobilplattform kann darüber hinaus der Start der KVP-HandsetApp durch die passive NFC Verkaufsinfrastuktur ausgelöst werden. Dies fällt ebenfalls in den Verantwortungsbereich des Discoverymanagers.

Es kann nicht davon ausgegangen werden, dass alle Mobilplattformen eine Konfigurierbarkeit dieser Funktionalitäten anbieten. Die Referenzplattform J2ME tut dies, dort wird der Discoverymanager Pushregistry genannt.

Je nach Realisierung kann noch eine weitere Komponente hinzukommen, die zum System des TSM gehört und TSM-Connector benannt wurde. Der TSM-Connector muss nicht als eigenständige Softwarekomponente realisiert sein, vielmehr kann auch bereits existierende Protokolle wie das Bearer Independent Protokoll (BIP) zur Kommunikation mit der (U)SIM bzw. auf andere vorhandene Firmware Funktionen zugegriffen werden.

6 Da keine gesonderte Installation erforderlich ist.



TSM-Connector Komponente die auf der Seite des NFC-Handsets das OTA System in die Lage versetzt, mit dem Secure Element zu kommunizieren und mit Hilfe von Mechanismen und Kommandos der GlobalPlatform die KA-Security-Domain zu erstellen, die konkreten Programmdateien der KA-NMApp einzubringen und abschließend diese zu konfigurieren.

4.4. Weitere Aspekte

Authentifizierung & Autorisierung

Bevor das OTA-Provisioning-System eine Operation im Namen eines KVP durchführt, wird die Berechtigung des KVPs überprüft.

Die ORG_ID des KVP muss auf der Liste der vom System akzeptierten KVPs enthalten sein.

Das KVPS muss die Anfrage mit einem korrekten Zertifikat gestellt haben.

Die OTA Operation muss für diesen KVP erlaubt sein.

Wiederholversuche

In Mobilfunknetzen muss grundsätzlich mit Unterbrechungen bei der Erreichbarkeit von Teilnehmern ausgegangen werden. Je nach Situation gibt es unterschiedliche Strategien, Wiederholungen bei Fehlversuchen zu initiieren.

Nutzerinitiierte Wiederholversuche werden regulär über das KVPS veranlasst.

Zeitgesteuerte Wiederholversuche können über das KVPS oder eine dem KVPS nachgelagerte Komponente gesteuert werden, dies kann das OTA Provisioning System sein.

Wiederholversuche, die durch Ereignisse des Mobilfunknetzes ausgelöst werden, müssen von dem den KVPS nachgelagerten Komponenten gesteuert werden, also dem OTA-Provisioning-System oder dem TSM-System. Hierzu gehören auch Wiederholversuche, die automatisch oder manuell durch das Mobiltelefon initiiert werden.

Ziel dieser Festlegung ist es, das KVPS frei von technisch induzierten Wiederholversuchen zu halten und gleichzeitig das KVPS als zentrale Schnittstelle für die Kundeninteraktion beizubehalten.



5. Funktionale Architektur

Grundlegendes Merkmal der Architektur des OTA-Provisioning-Systems ist die Trennung in ein zentrales Hintergrundsystem und eine Kommunikationsschicht auf dem NFC-Mobiltelefon. Zwischen diesen beiden physikalisch getrennten Teilen werden die Daten „Over The Air“ über das mobile Datennetz übertragen.

Die Kommunikationsschicht auf den NFC-Handsets besitzt eine hohe Abhängigkeit von den technischen Bedingungen der unterschiedlichen Mobilfunkplattformen. Aufgrund der Vielzahl der im Rahmen dieses Dokuments berücksichtigten Integrationsformen des Secure-Elements (eingebettetes SE, (U)SIM, Secure Digital oder Bluetooth Modul) erscheint es sinnvoll, die genaue Ausgestaltung der Realisation den Anbietern der TSM-Funktionalität zu überlassen. An die TSM Komponente werden daher lediglich drei grobgranulare funktionale Anforderungen gestellt.

1. Die TSM Komponente kann die zur Identifikation des Secure-Elements notwendigen Daten ermitteln. Hierbei sollen alle geeigneten Secure-Elements des durch seine MSISDN7 adressierten NFC-Handset, berücksichtigt werden.

2. Die TSM Komponente kann in ein adressiertes Secure-Element eine KA-Security-Domain einbringen und dort ein KA-NMApp laden.

3. Die TSM Komponente kann an die KA-NMApp, die von einem externen System erhaltenden Chipkartenkommandos, senden.

Optional (Falls KVP die entsprechenden Artefakte über OTA Provisioning zur Verfügung stellen möchte)

4. Die TSM Komponente installiert die KVP-HandsetApp auf dem Zielsystem und nimmt Konfigurationen des Discoverymanagers vor.

Die Anforderung 3. bezieht sich dabei auf die Durchleitung der für die KA-NMApp Konfiguration erforderlichen Chipkarten-Kommandos, deren Erzeugung nicht in der Verantwortlichkeit des TSM liegt. Dies gilt analog für die optional vom OTA Provisioning System durchzuführende KA Personalisierung und deren Kommandos.

Das OTA System gliedert sich entsprechend seiner Aufgaben in folgende vier Bereiche.

KA OTA Supplymanagement (Ablaufsteuerung)

TSM-Funktionalität

KA-NMApp Konfiguration (Prozess NM-Config)

Software und Konfigurationsmanagement Diese Bereiche werden in den folgenden Abschnitten beschrieben.

7 Oder durch eine andere eindeutiges Adressierungsverfahren.



5.1. KA-OTA-Supplymanagement Das KA-OTA-Supplymanagement steuert die in Kapitel 6 beschriebenen Prozesse und orchestriert hierzu die Komponenten des OTA Systems. Es verfügt über eine Schnittstelle zum KVPS mit der die Operationen des OTA-Provisioning initiiert werden.

Es ist verantwortlich für die Wiederaufnahme unterbrochener OTA-Prozesse. Hierzu werden die Ereignisschritte zwischengespeichert. Die Zwischenspeicherung dient ausschließlich der Durchführung und Optimierung der technischen Prozesse und erfolgt nur über kurze Zeit. Die längerfristige Speicherung der (Transaktions-)Daten findet beim KVP statt.

composite structure KA Supplymanagement

NM Handset

Service Provider

Schnittstelle

KA Supplymanagement

NM Handset

Service Provider

Schnittstelle

System AP200::VDV KA

Supplymanagement::

Authentication &

Authorisation

Process Engine

System AP200::VDV

KA

Supplymanagement::

Session Tracking &

Short Memory

TSM::TSM

TSM Interface

KP, Diskussion: Asynchrone

Bereitstellung von Ergebnissen,

z.B. auf Grunde von

Wiederholungen.

KVP OTA

Auftragsschnittstelle

NM

Config

KVP OTA

Ergebnisschnittstelle

NM Handset

Service Delivery

Schnittstelle

TSM Interface

Abbildung 5: Komponente KA-OTA-Supplymanagement

5.2. TSM-Funktionalität Abbildung 5 zeigt Zusammenhänge von KA-OTA-Supplymanagement sowie der TSM-Funktionalität beim Installieren, Konfigurieren sowie den weiteren Lifecycle-Operationen auf dem KA-NMApp. Der blaue Kasten umfasst das TSM System sowie die TSM Funktionalität auf dem Handset. An der Schnittstelle zu diesem Verantwortungsblock müssen die folgenden Operationen zur Verfügung stehen.



cmp TSM OTA View

HandsetZentral System AP200

TSM Funktionalität

(from Handset)

NmApp Config

KA Supplymanagement

Secure Element

(from Handset)

KVP System

CM Repository

Secure Element::

VDV KA NM

TSM::TSM

«configures»

(optional)

«install»

beauftragt

«flow»

«flow»

fordert NM Handset Services an

fordert Initialisierungssequenz an

Abbildung 6: TSM OTA Interaktion

1. Die TSM-Funktional-Komponente kann die zur Identifikation notwendigen Daten aller Secure-Elements ermitteln, die in einem durch seine MSISDN adressierten NFC-Handsets gefunden wurden.

Anfrage des OTA-Supplymanagement Antwort der TSM-Funktional-Komponente

(MSISDN , Liste mit SE-Typen8) (Liste mit (SE Kennung, SE Typ))

2. Die TSM-Funktional-Komponente kann in ein vollständig adressiertes Secure-Element eine KA-Security-Domain einbringen und dort eine KA-NMApp laden.


(MSISDN, SE Kennung, Binärdaten KA-NMApp, ** ) (Verbindungsparameter für Kommunikation mit KA-NMApp)

** Optionale Parameter können z.B. weitere in die Security-Domain einzubringende Applikationen sein, Angabe ob ISD genutzt werden soll oder allgemein Daten zur KA-Security-Domain.

8 Auf (U)SIM, embedded SE, SD Karte, externes SE



3. Die TSM-Funktional-Komponente kann an die KA-NMApp die von einem externen

System erhaltenden Chipkartenkommandos senden.


(Verbindungsparameter für Kommunikation, Kommando) (Antwort der KA-NMApp)

Kommando ist beispielsweise SELECT FILE oder ein anderes definiertes CONFIGURE Kommando (siehe [10]).

Optional

4. Die TSM-Funktional-Komponente installiert KVP-HandsetApp auf dem Zielsystem und nimmt die Konfigurationen des Discoverymanagers vor.


(MSISDN, KVP-HandsetApp, Discoverymanager Konfiguration) (Ok)

Es wird davon ausgegangen, dass Informationen, die die KVP-HandsetApp benötigt um auf die KA-NMApp zuzugreifen, bereits in der KVP-HandsetApp enthalten sind.

Da die TSM-Funktionalität integraler Bestandteil des OTA-Provisioning-Systems ist, wird keine Schnittstelle zum TSM definiert, sondern der TSM als Systembestandteil angenommen.



5.3. KA-Nm-Konfiguration (NM-Config) Diese Komponente überwacht den Lade und Konfigurationsprozess der Nutzermediums Applikation KA-NMApp (siehe [7]), insbesondere verfügt sie über die Möglichkeit mit Hilfe des Trustcenters des AH eine Signatur über den Public Key der KA-NMApp zu erstellen und in diese einzubringen. Da der Abruf des Zertifikats Grundlage der zugrundeliegenden Berechnung der Abnahmemenge zwischen AH und KVP sein kann, muss er protokolliert werden. Für den Fall eines Prozessfehlers muss die Zurückname des Zertifikats beim Trustcenter beantragt werden (REVOKE) und in der Protokollierung vermerkt werden.

composite structure KA NM Config

Zertifikatsabruf Schnittstelle

NmApp Config

Zertifikatsabruf Schnittstelle

System AP200::

NmApp Config::

Configurer

System AP200::

NmApp Config::

Loader

NM Config

Schnittstelle

Abbildung 7: Komponente NM Konfigurator



5.4. Software und Konfigurationsmanagement Die auf den NFC-Handsets zu installierende Software wird vom OTA-Provisioning-System zentral in einem Repository gespeichert. Es ist davon auszugehen, dass die Software für unterschiedliche NFC-Handsets und Secure-Element differenziert werden muss. Somit ist es erforderlich, zusätzlich zu den Nutz- auch Metadaten abzuspeichern, die die eindeutige Auswahl von Softwareversionen anhand der zuvor ermittelten Gerätemerkmale und Versionsständen der bereits installierten Komponenten gewährleistet.

Im Anhang befindet sich eine Beschreibung des hierfür anzuwendenden Verfahrens.

composite structure CM Repository

CM Repository

Handset Service Delivery Interface

System AP200::CM

Repository::

Discov eryManager

Konfigs

System AP200::CM

Repository::KVP-Apps

System AP200::

CM Repository::

Version

Resolution

System AP200::

CM Repository::

NmApps

NM Handset Service

Provider Interfacer

sucht Software in

sucht Software in

stellt Software ein

Abbildung 8: Komponente CM Repository



6. Anwendungsfälle und Fachklassen

6.1. Fachklassenmodell class Fachklassen

NFC-Ticketingserv ice-Kunde NFC-Handset

- Typ: HandsetTyp

- Version: Number

- msisdn: MSISDN

NFC-Handset::Secure

Element

- Identifier: String

- Typ: SE Typ

«singleton»

KA NmApp

NFC-Handset::VDV

KA NM Container

KA NM Handsetserv ice

- Version: Number

NFC-Handset::ISD NFC-Handset::SD

TSM Connector

Secure Element

Owner

Discov eryManager Discov eryManager

Config

KVP

KVP HandsetApp

Prioritätenliste

- Prorität: int

- SE Typ: SE Typ

- HandsetTyp: HandsetTyp

Positiv liste SE

- Typ: SE Typ

- SE Owner: SE Owner

Positiv liste Handset

- Typ: HandsetTyp

TSM-Connector ist optional

und die Realisierung vom OS

des Handsets abhängig.0..1

1

1..*

besitzt

1

0..1

1

1..*1

1

0..*

1 1 0..*

11

1 1

bestimmt

Verwendbarkeit1

0..*

0..1

1

Enthält Startregel für App

0..1

1

liefert

l iefert

install iert

l iefert

bestimmt

Verwendbarkeit

0..1

1

Abbildung 9: Fachklassen

Der NFC-Ticketingservice-Kunde steht in vertraglicher Beziehung zu einem Kundenvertragspartner KVP und besitzt ein oder auch mehrere NFC-Handsets. Auf jedem seiner NFC-Handsets können im Rahmen des zentralen OTA-Prozesses ein oder mehrere KA-NM-Handsetservices installiert werden. Die KA-NM-Handsetservices bestehen aus KA-NMApp, KA-KVP-HandsetApp sowie der Discoverymanager Konfiguration.

Die KA-NM-Handsetservices sind voneinander unabhängig, allerdings teilen sich alle KA-NM-Handsetservices eines NFC-Handsets eine gemeinsame Instanz der KA-NMApp unabhängig davon, wie viele Secure-Elements bzw. darauf befindliche SD/ISD, die eine solche KA-NMApp aufnehmen könnten, auf dem NFC-Handset vorhanden sind.



Hieraus ergibt sich unmittelbar, dass beim Installieren eines KA-NM-Handsetservices eine vorhandene KA-NMApp weder ausgetauscht noch eine weitere installiert werden darf. Stattdessen darf eine KA-NMApp von mehreren KA-NM-Handsetservices (insbesondere also mehreren KVP-HandsetApps) angesteuert werden.

Die KA-NMApp wird in einem KA-NM-Container eingespielt, dieser Container wird durch eine Issuer Security-Domain (ISD) oder eine dedizierte Security-Domain geliefert. Physikalisch ist das Ganze in ein Secure-Element eingebettet, zu dem ein SE_Owner die Berechtigungen vergibt. In den meisten Fällen delegiert der SE_Owner alle mit dem Berechtigungssystem des Secure-Elements in Verbindung stehenden Prozessen an einen TSM, für das Modell ist er an dieser Stelle unwichtig, da er funktional, jedoch nicht strukturell auftritt.

Die beiden Positiv-Listen, die bestimmen auf welchen Handsets und auf welchen Secure-Elementen die Software installiert werden darf, sowie die Prioritätenliste, mit deren Hilfe bestimmt wird in welcher Reihenfolge das Ziel Secure Element gesucht wird, werden vom KVP geliefert und definieren dessen Präferenzen. Zwecks Übersichtlichkeit wurden weitere Lieferbeziehungen, die zu den Komponenten des KA-NM-Handsetservices existieren, nicht eingezeichnet, auch diese werden durch den KVP bereitgestellt.

6.2. Anwendungsfälle Abbildung 10 zeigt eine Übersicht der Anwendungsfälle. Diese werden in den nachfolgenden Abschnitten genauer erläutert.

Prüfen der Voraussetzung: In diesem Anwendungsfall wird überprüft, ob ein NFC-Handset den für die Nutzung als KA-Medium existierende Anforderungen des KVPs entspricht.

Übergabe von Software: In diesem Anwendungsfall übergibt das KVP System die Softwarekomponenten der KA-NM-Handsetservices an das OTA-Provisioning-System.

KA-NM-Handsetservice laden: Dieser zentrale Anwendungsfall lädt die KA-NM-Handsetservices auf ein NFC fähiges Gerät.

KA-NMApp sperren: In diesem Anwendungsfall wird der Zugriff (Selektierbarkeit der Applikation entsprechend GlobalPlatform) auf die KA-NMApp gesperrt oder erlaubt.

KA-NM-Handsetservice aktualisieren: Wiederherstellen, Ergänzen oder Ersetzen der KA-NM-Handsetservices bzw. von Komponenten der KA-NM-Handsetservice.

KA-NM-Handsetservice löschen: Entfernen aller auf dem NFC-Handset installierten Komponenten/Artefakte der KA-NM-Handsetservice.

Mit Hilfe dieser Anwendungsfälle können die Geschäftsvorfälle Kunde tauscht sein NFC-Handset, Kunde ändert seine Secure-Element Konfiguration (durch Tausch (U)SIM, Handset oder Tausch/Verlust des externen Secure-Element, Kunde wechselt seine MSISDN) sowie Kunde verliert sein NFC-Handset abgebildet werden. Die konkrete Gestaltung obliegt dem



KVP, die Steuerung des übergeordneten Geschäftsprozess und die Überprüfung von Vorbedingungen dem KVPS.

uc Systemanwendungsfälle

KA-OTA-Provisioning-System

Prüfen der

Voraussetzung

Übergabe v on

Software

KA NM

Handsetserv ices

laden

Sperren/Entsperren

des KA NM

Update der KA NM

Handset-Serv ices

Löschen der KA NM

Handset-Serv ices

KVPS

AHS

Übergabe v on

SE-Positiv liste

AH Trustcenter

Abbildung 10: Anwendungsfälle



6.2.1. Prüfen der Voraussetzung

act Prüfen der Voraussetzung

Prüfen der Voraussetzung TSM-Connector, SE, NM Cardlet(s)

Prüfen ob KVP die

Berechtigung hat das System

zu nutzen

Erfolg

Prüfen ob das Handset

mindestens ein

zugelassenes SE enthält

KVP ist berechtigt ?

Fehler

Ergebnis der

SE-Prüfung ist

KVPS

Prüfen der

Voraussetzungen

- Start

Melde KVP:

kein

Berechtigung

Melde KVP:

Zugriff nicht

zugelassen

Melde KVP:

Alles Ok

Verbindung aufbauen zum

Handset.

Handset z Zt.

nicht

erreichbar

[nicht

zugelassen]

[zugelassen]

[Kunde hat entsprechendes NFC-Device]

«flow»

[berechtigt]

[nicht berechtigt]

[erreichbar]

[nicht erreichbar]

Abbildung 11: Prüfen der Voraussetzung



Prüfen der Voraussetzung9

Zweck Die Prüfung der Voraussetzungen gibt dem KVP die Möglichkeit, zu prüfen ob ein NFC Handset den Voraussetzungen zum Aufnehmen eines KVP-Handsetservices und insbesondere einer KA-NMApp entspricht. Wie abgebildet werden bestimmte Fehler an den KVPS zurück gemeldet.

Erweitert -

Wird erweitert durch -

Akteure

KVPS Kunde mit Trägermedium

Kanäle

KVPS-System Verbindung Mobiles Internet System – NFC Handset

Vorbedingung

System besitzt benötigte Software für evt. Laden des TSM Connectors. System enthält Liste von zugelassenen Handsets und Secure Elements.

Standardablauf

1. Prüfen ob KVPS berechtigt ist, über das System die Anfrage zu starten 2. KVPS beauftragt das KA-OTA-Provisioning System, die Voraussetzungen eines

bestimmten NFC Handset zu prüfen. Input ist die Handy Nummer des NFC Ticketingservice Kunde Handsets

3. System überprüft ob Handset erreichbar ist 4. System überprüft Voraussetzung, d.h.;

a. Ob es ein geeignetes Handset ist, d.h. ob die Handset-Services für das spezifische Modell verfügbar sind.

b. Ob das SE zugelassen ist, d.h. ob das SE auf der Liste von KA KG zertifizierten SE vorhanden ist.

5. System überprüft, welche Software und zugehörige Versionen des KA Handsetservices und dessen Artefakte auf dem Handset ggf. bereits vorhanden sind.

Alternativ ablaufe

Wenn das Handset den Voraussetzungen nicht entspricht, muss der KVP über weitere Schritte entscheiden, ob ein alternatives VDV-KA NM an zu bieten ist

Nachbedingung

Handset und Secure Element wurden als zugelassen erkannt und Meldungen dazu wurden an den KVPS zurückgegeben. Dabei werden auch Details wie Handy, SE Type und OS

9 Im rahmen des GP wird dieser Prozess auch Eligiblity Check genannt wo der Issuer die

Zulassungsbeschraenkungen für das Handset definiert und die notwendige Maßnahmen nimmt.



Version übermittelt. Weitere Ergebnisse: Das Handy braucht zusätzliche Software (z.B. TSM-Connector) um die Voraussetzungen (weiter) überprüfen zu können.

Parameter

- Bevorzugter SE Typ (nicht verpflichtend, wenn nicht mitgegeben wird die SE Prioritätenliste beibehalten)

- Kunde Endgerät Identifikation ZB. MSISDN



6.2.2. Übergabe von Software act Activ ity

Übergabe v on Software

Empfang der

Software

Überprüfe empfangene

Software

Software OK?

«datastore»

Speichere

Software

Neue oder Update Software?

«datastore»

Archiv iere alte

v ersion, speichere

neue v ersion

Erfolg

Übergabe

von Software

- start

Fehler

Melde KVP:

Software

gespeichert

Melde KVP:

Software wurde

aktualisiert

Melde KVP:

Software nicht

gespeichert

Software:

1. Cardlet

2. TSM Connector

3. Handy whiteliste

Prüfen ob KVP

Berechtigung hat über das

System Abfrage zu starten

Prüfe KVP

Übergabeparameter und

Voraussetzungen

[nein]

[ja]

[Update][Neu]

Abbildung 12: Übergabe von Software



Übergabe von Software

Zweck Vor dem Laden der KA NM -Service muss die benötigte Software (Midlets, KA-NMApps, Discovery-Manager Konfiguration) an das System übergeben werden. Bei der Übergabe von Software wird diese vom System ins Repository geladen und überprüft. Dies verbessert die Performance, weil die Software nicht bei jedem Ladeauftrag neu übertragen werden muss. Initiale Befüllung von Software, Update und Löschen

Erweitert -


Akteure

KVPS

Kanäle

Verbindung KVPS - System

Vorbedingung

Das Versionsmanagement der Software macht der KVP.

Standardablauf

1. Prüfen ob KVPS/KA Handset Service Lieferant berechtigt ist, Software zu laden. 2. KA Handset Service Lieferant sendet die Software (via KVPS) zum System 3. System überprüft die empfangene Software, d.h. prüft;

a. Ob die Software eindeutig erkennbar und adressierbar ist. b. Ob die Software bestimmten Voraussetzungen* entspricht. c. Ob die Version eines Bundles nicht schon im System vorhanden ist d. Ob die Software einem bestimmten Handset-Typ oder SE entspricht. e. Größe Software zum prüfen des Speicherbedarfs bei Installation.

4. Software wird ins Repository übernommen *Voraussetzungen Software:

- KA-NMApps; müssen off-card wie in „Java Card™ Off-Card Verifier, White Paper, Sun Microsystems, v1.0, June 2002“ beschrieben verifiziert werden

Midlets müssen signiert sein.

Alternativ ablaufe

Wenn es ein Update von Software gibt, wird die altere Version archiviert und ist damit nicht mehr direkt verfügbar im System. Im Fall der Erhalt eines Midlets wird geprüft, ob das Midlet signiert ist. Der KVP kann auch das Löschen von bestimmter Software beauftragen, damit wird dann die bestimmte Software oder Bundle von Software gelöscht.



Nachbedingung

Die Software wurde im System gespeichert und ist damit verfügbar für Ladeaufträge. Dem KVPS wird gemeldet, dass die Software für Ladeaufträge verfügbar ist.

Parameter

- Software ID - Software Typ (KA-NMApps, Whiteliste Handys, Whiteliste SE und TSM Connector) - Software Version - Eingekapselte Software (Zip Datei mit spezifische Software Files) - Spezifisch per Software Typ:

o Handy Hersteller und Typ (Für Midlet) o SE Typ (Für KA-NMApp) o Gültigkeit Periode ab/bis



6.2.3. Übergabe von SD-Positivliste act Activ ity

Übergabe v on SE-Positiv liste

Übergabe von

SE-Positivliste

- start

Prüfen ob AH



Prüfe KVP


Voraussetzungen

Überprüfe empfangene

Positiv liste

Positivliste

OK?

«datastore»

Speichere

Positiv liste

Melde AH

Positivliste nicht

gepseichert

Melde AH:

Positivliste

gespeichert

Empfang

Positivliste

ErfolgFehler

[Nein]

[Ja]

Abbildung 13: Übergabe von SE-Positivliste



Übergabe von SE-Positivliste

Zweck Vor dem Laden der KA NM -Service muss die benötigte Positivliste (Whiteliste Secure Elements) an das System übergeben werden. Bei der Übergabe der Positivliste wird diese vom System ins Repository geladen und überprüft. Initiale Befüllung von Positivliste, Update und Löschen

Erweitert -


Akteure

AH

Kanäle

Verbindung AH - System

Vorbedingung

Das Versionsmanagement der SE Positivliste macht der AH.

Standardablauf

1. Prüfen ob AH berechtigt ist, Positivliste zu Laden. 2. AH sendet die Positivliste zum System 3. System überprüft die empfangene Positivliste, d.h. prüft, ob ;

a. Die Positivliste eindeutig erkennbar und adressierbar ist. b. Die Version der Positivliste nicht schon im System vorhanden ist

4. Positivliste wird ins Repository übernommen

Alternativ ablaufe

Wenn es ein Update der Positivliste gibt, wird die altere Version archiviert.

Nachbedingung

Die Positivliste wurde im System gespeichert und ist damit verfügbar. Dem AH wird gemeldet, dass die Positivliste verfügbar ist.

Parameter

- Positivliste ID - Positivliste Version - Positivliste



6.2.4. Laden des KA Handsetservices act KA NM Handsetserv ice laden

Laden des KA NM Handsetserv ices

Verbindung zum Secure

Element aufbauen

NmApp laden

Erfolg

Handy geeignet?

Daten

ok?

SE

erreichbar?

NmApp geladen?

KA NM Konfiguration

KA NM

Handsetservice

geladen?

Fehler

Laden KA NM

services- Start

Prüfe KVP


Voraussetzungen

Prüfen ob KVP Berechtigung

hat über das System Abfrage

zu starten

:Prüfen ob das Handset

mindestens ein

zugelassenes SE enthält

Melde KVP: KA

NM Services

geladen

Melde KVP:

Übertragung

des Secrets

gescheitert

Melde KVP:

Cardlet Laden

gescheitert

Melde KVP:

Daten nicht OK

Melde KVP:

Handy nicht

geeignet

Melde KVP: SE nicht

erreichbar, weitere

Software (wie zB.TSM

Connector) noetig

Zertifikat

anfragen

Zertifikat

empfangen

NM Handset App schon

v orhanden?

Prüfen ob KA

(I)SD

v orhanden

ist

Ist SD vorhanden?

KA SD laden

SD geladen?

NmApp schon

vorhanden?

NmApp info abfrage v om

SE

NmApp version OK?

Update NmApp

KA Handset

App

geladen?

Update Discov ery

Manager

Melde KVP KA

Handset App

laden

gescheitert

Melde KVP; SD

Laden

gescheitert

KVPS

NM Handset App?

Lade NM Handset App Update KA Handset App

Update Discovery Manager OK?Melde KVP:

Update Discovery

Manager

gescheitert

[nein]

[ja]

[KA SD bereits vorhanden][KA SD nicht vorhanden]

[Ja]

[nein]

[nein]

[nein]

[Ja]

[Vorhanden][Nicht vorhanden]

Kunde mit VDV KA NM Service ausstatten

«flow»

Abbildung 14: Laden des KA Handsetservices



Laden des KA Handsetservices

Zweck Laden des KA Handsetservices auf eine Karte oder Over-The-Air in ein NFC-Handset.

Erweitert -

Wird erweitert durch Prüfen der Voraussetzung Update VDV-KA NM Service

Akteure


Kanäle

KVPS-System Verbindung Mobiles Internet System – NFC Handset

Vorbedingung

Software ist im Repository Positivliste mit unterstutzten SE liegt vor

Standardablauf

1. Prüfen ob KVPS berechtigt ist, das Laden zu beauftragen 2. Prüfung der Voraussetzungen 3. KA NM Service wird geladen 4. KA NM Service wird personalisiert (im Sinne von GP, siehe auch Anhang

„Ergänzungen Spezifikation KA NM“) dabei werden die notwendigen Root keys für weitere Konfiguration des NMs geladen

5. KVPS wird über den Lade- und Personalisierungsvorgang benachrichtigt.

Alternativ ablaufe

Wenn keine geeignete Security Domain vorhanden ist, wird diese installiert, damit die KA NM Service geladen werden kann. Folgendes wird geprüft bzgl. einer geeigneten SD:

- KA SD ist vorhanden und kann adressiert werden. (D.h. die Keys für Eröffnung der SD sind vorhanden, damit KA NM LifeCycle Management gemacht werden kann)

- KA SD ist die richtige Version - KVP ist berechtigt, diese KA SD zu benutzen.

Wenn das Security Domain schon vorhanden ist, wird geprüft ob auch die richtige KA-NMApp Version anwesend ist und entsprechend ein Update vorgenommen. Wenn mehrere unterstützte Secure Elements im Handy vorhanden sind, wird folgende Priorität eingehalten:

- Vorher durch der Kunde gewählte SE - SE auf der SIM Karte - Embedded SE - SD Karte - Sticker

Das durch den Kunden vorher gewählte SE wird bei der Anfrage des Ladens der Applikation als Parameter übertragen. Der KVPS kann über Parameter steuern, dass der für das Laden etablierte Kanal offen bleibt, so dass ohne weitere Kundenaktivität die KA-Prozesse „Ausgabe der Applikation“ und/oder „Ausgabe einer Berechtigung“ folgen können.



Nachbedingung

VDV-KA NM Service ist geladen und personalisiert (im Sinne von GP) und ist initialisiert (im Sinne von VDV-KA) Hier ist es empfehlenswert, dass der offene Kanal, worüber die Initialisierung stattgefunden hat, weiter gegeben werden kann zur KA Personalisierung. Damit kann Zeit gespart werden indem der Kanal nicht erneut eröffnet werden muss. Als Rückgabe wird referenziert durch die Auftragsnummer das Zertifikat geliefert10.

Ausnahme

Ist im Sinne von [5] die Erstellung eines NMs fehlerhaft verlaufen, so sind die Zertifikate zu sperren.

Parameter

- Auftragsnummer - Kunden Endgerät Identifikation z.B. MSISDN des Handsets - Software Typ - Software ID - Bevorzugte SE - Aus zu führende Lade schritte (Nur laden oder Laden und Personalisieren) - Steuerung zum anschließenden Ausgeben von Applikation und/oder Berechtigung

gemäß [6]

10 Die Zuordnung von MSISDN zum Zertifikat für einen Einzelauftrag (keine MSIDN-Listen) wird durch

den KVP bei Response durch das OTA-Provisioning-System selbst durchgeführt, d.h. es sind keine Lieferlisten notwendig



6.2.5. Löschen der KA-NM-Handsetservices act Löschen der VDV KA NM Handset-Serv ices

Löschen der VDV KA NM Handset-Serv ices

Voraussetzungen erfüllt?

Lösche KA NM Cardlet(s)

Löschen erfolgreich?

Fehler

Melde KVP:

Cardlet(s) wurden

nicht gelöscht

Melde KVP: Die

Voraussetzungen

sind nicht erfüllt

Melde KVP: KA

NM Services sind

gelöscht

Löschen der VDV KA NM

Handset-Services - Start

Erfolg

:Prüfen der

Voraussetzung

TSM-Connector,

SE, NM Cardlet(s)

Prüfen ob KVP



Prüfe KVP


Voraussetzungen

Zertifikat des

Nutzermediums

Cert-PuK-NM

"Revoke"

Zertifikat

zurücknehmen

und sperren

[Ja]

[Nicht erfüllt]

[fehlgeschlagen]

Abbildung 15: Löschen der KA-NM-Handsetservices



Löschen der KA-NM-Handsetservices

Zweck Das vollständige Löschen eines KA-NM-Handsetservices, inklusive SD, vom SE eines NFC Handset

Erweitert -

Wird erweitert durch Prüfen der Voraussetzung.

Akteure


Kanäle

KVPS- KA-OTA-Provisioning System Verbindung Mobiles Internet KA-OTA-Provisioning System – NFC Handset

Vorbedingung

Standardablauf

1. Prüfen ob KVPS berechtigt ist, das Löschen zu beauftragen 2. Prüfen der Vorrausetzungen 3. KA-NMApp(s) werden gelöscht 4. Zertifikat zur endgültigen Sperrung an TC melden 5. VDV-KA NM Security Domain wird gelöscht 6. KVPS wird benachrichtigt über den Löschungsvorgang

Alternativ ablaufe

Wenn eine oder mehrere KA-NMApps oder die Security Domain nicht gelöscht werden können, wird das KVPS darüber informiert.

Nachbedingung

Cardlet(s) und Security Domain sind komplett vom Secure Element gelöscht worden.

Parameter

- Kunde Endgerät Identifikation (z.B. MSISDN) - Software Typ - Software ID - Bevorzugte SE



6.2.6. Sperren/Entsperren des KANM act Sperren/Entsperren des VDV KA NM

Sperren/Entsperren der des VDV KA NM

Fehler

Voraussetzungen

erfüllt?

Sperren KA NM Entsperren KA NM

Sperren oder Entsperren?

Ausgang Sperren erfolgreich? Ausgang Entsperren erfolgreich?

Erfolg

Sperren/Entsperren des VDV KA

NM - Start

:Prüfen der

Voraussetzung

TSM-Connector,

SE, NM Cardlet(s)

Melde KVP:

Voraussetzungen

nicht erfüllt

Melde KVP:

Sperren

gescheitert

Melde KVP: KA

NM gesperrt

Melde KVP:

Entperren

gescheitert

Melde KVP: KA

NM ist entsperrt

Sperren/Entsperren ensprechend der

Mechanismen der GP.

Sperrung des Zugangs zur SD

Prüfen ob KVP



Prüfe KVP


Voraussetzungen

[Ja][Ja]

[Nein] [Ja]

[Nein] [Nein]

Abbildung 16: Sperren/Entsperren des KA NM



Sperren/Entsperren des KA NM

Zweck Sperren des KA NM insofern das Cardlet von außen nicht weiter benutzt werden soll. Entsperrung sorgt dafür, dass das NM wieder benutzt werden kann.

Erweitert -


Akteure


Kanäle


Vorbedingung

Standardablauf

1. Prüfen ob KVPS berechtigt ist, das Sperren/Entsperren zu beauftragen 2. Prüfen der Vorrausetzungen 3. VDV-KA NM Security Domain wird gesperrt/entsperrt bzw. in GlobalPlatform

Lifecycle LOCKED-State versetzt oder zurück gesetzt im SELECTABLE-State 4. KVPS wird benachrichtigt über den Sperrungs-/Entsperrungsvorgang

Alternativ ablaufe

Wenn die KA NM Service im ISD installiert wurde, werden die betreffenden KA-NMApps in GP lifecycle state LOCKED gesetzt

Nachbedingung

VDV-KA NM Service ist gesperrt/entsperrt.

Parameter

- Kunde Endgerät Identifikation Zb. MSISDN - Software Typ - Software ID - Bevorzugte SE - Sperren bzw. Entsperren

Bemerkung: Hier wird keine Beschränkung des Sperrens oder Entsperrens auferlegt; der KVP(S) soll entscheiden, ob die Sperrung oder Entsperrung zulässig ist, das System übernimmt die eigentliche Sperrung laut GP Spezifikationen und sperrt die Security Domain, in der das KA-NMApp des KA NM Service abgelegt ist.



6.2.7. Update des KA-NM-Handsetservices act Update der VDV KA NM Handset-Serv ices

Update der VDV KA NM Handset-Serv ices

Vorausetzungen

erfüllt?

Löschen KA NM Serv ices

Gelöscht?

Laden KA NM Serv ices

Geladen?

Fehler

Update der

VDV KA NM

Handset

services -

start

:Prüfen der

Voraussetzung

TSM-Connector,

SE, NM Cardlet(s)

Ende

Melde KVP:

Voraussetzungen

nicht OK

Melde KVP: KA NM

Cardlet nicht

gelöscht

Melde KVP: KA NM

cardlet nicht

geladen

Melde KVP: KA NM

Cardlet geladen

Prüfen ob KVP



Prüfe KVP


Voraussetzungen

[ja]

[ja]

[nein]

[nein]

[nein]

[ja]

Abbildung 17: Update des KA-NM-Handsetservices



Update des KA-NM-Handsetservices

Zweck Neue Software ist im System anwesend und muss dem entsprechend durch einen Update der KA NM Handset Service im SE des Trägermediums neu geladen werden. Des Weiteren kann auch der Tausch eines Handsets, der Wechsel des SE oder der MSISDN ein Grund für die Update-Funktion sein.

Erweitert -

Wird erweitert durch KA NM Service löschen KA NM Service Laden

Akteure


Kanäle


Vorbedingung

Standardablauf

1. Prüfen ob KVPS berechtigt ist, den Update des KA NM Service zu beauftragen 2. Prüfen der Vorrausetzungen 3. VDV-KA NM Service wird gelöscht 4. VDV-KA NM Service wird geladen 5. KVPS wird benachrichtigt über das mittels update neu laden des VDV-KA NM

Service.

Alternativ ablaufe

Alternativ muss ein Update der einzelnen Komponenten möglich sein. Wie Update des KA HandsetApp und KA-NMApps.

Nachbedingung

KA NM Service würde durch Update neu geladen und an KVPS gemeldet

Parameter

- Kunde Endgerät Identifikation z.B. MSISDN - Software Typ - Software ID - Bevorzugte SE - Personalisierung Daten



7. Umsetzung der nicht funktionalen Anforderungen

7.1. Zusammenhang von Anwendungsfällen zu nicht funktionalen Anforderungen In diesem Kapitel werden die nicht funktionalen Anforderungen aus AP210 per Anwendungsfall weiter erläutert und der Zusammenhang erklärt.



AP210 nr Beschreibung Zusammenhang mit „Prufen der Vorraussetzung“

Zusammenhang mit „Übergabe von Software“

Zusammenhang mit „Übergabe von SE-Positivliste“

Zusammenhang mit „Laden der Applikation (auch auf eine Chipkarte)“

Zusammenhang mit „Löschen des KA-NM-Handsetservices“

Zusammenhang mit „Sperren/Entsperren KA-NM-Handsetservices“

Zusammenhang mit „Update des KA-NM-Handsetservices“

ANF01 Das Secure Element (SE) muss die Sicherheitsanforderungen der KA an ein NM erfüllen. Es dürfen durch das System keine KA NMs auf Chiptypen administriert werden, welche diese Sicherheitsanforderung nicht erfüllen.

Eine Whiteliste von KA KG zugelassene SE wird im System geladen und damit kann überprüft werden ob eine SE die Sicherheitsanforderung von KA erfüllt. (Siehe 4 in 6.2.1 und 0)

Die Liste der zertifizierte SE muss in die Übergabe von SE-Positivliste anwendungsfall übertragen und im System gepflegt werden. (Siehe 0)

Die Liste der zertifizierte SE muss in die Übergabe von SE-Positivliste anwendungsfall übertragen und im System gepflegt werden. (Siehe 0)

Die VDV-KA NM Service wird nicht aufgebracht wenn diese Anforderung nicht erfüllt ist.(siehe 6.2.4 Vorbedingung)

Wenn die Voraussetzungen nicht erfüllt werden in 6.2.5 scheitert das löschen direkt.

Wenn die Voraussetzungen nicht erfüllt werden in 6.2.5 scheitert das löschen direkt.-

Wenn die Voraussetzungen nicht erfüllt werden in 6.2.5 scheitert das löschen direkt.-

ANF02 Das SE muss den Global Platform-Standard (Card Specification v2.2) erfüllen.

Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Sieh ANF01 Siehe ANF01

ANF03 Das SE muss die Cardletausprägungen der KA NM Handset-Services aufnehmen können. Die Funktionalität der KA NM Handset-Services muss verfügbar und darf durch die Administration nicht eingeschränkt sein.

Das System bekommt beim laden der Handset Services die benötigte Parameter wie zB. Größe des KA-NMApps. Wenn die technische Ausprägung das erlaubt werden diese Parameter dann benutzt um vor laden der Services dies zu überprüfen. Siehe auch ANF01

Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01



ANF04 Es darf keine Hardwareausprägung eines SE (SIM-Karte, SD-Karte, Bluetooth-Sticker, embedded Chip, in Leseweite des NFC-Handset befindliche Chipkarte etc.) diskriminiert werden.

Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01

ANF05 Die Spezifikation darf keine Lösung ausschließen, die nur eine Teilmenge von Hardwareausprägungen unterstützt.

Wie in 4.2 und 3.4.2 beschrieben können mehrere Typen und Umgebungen von TSM eingebunden werden sowohl System interne TSM aber auch externe, dies schließt damit keine HW Ausprägungen aus aber macht die komplementär.







ANF06 Eine aufzubringende Applikation soll nach dem Download, unabhängig von dem Vorhandensein weiterer Applikationen, lauffähig sein und ohne weitere Konfiguration durch den Handsetbesitzer angewendet werden können. Dies soll OTA unterstützen. Die Applikationen dürfen sich nach dem Aufbringen nicht ungewollt beeinflussen.

Dies sollte vorher überprüft werden, bzw. die freie Speicher Platz sollte die voraus gesetzte Speicher des VDV –KA NM Service entsprechen. Siehe 6.2.2

Siehe 6.2.2 Siehe 6.2.2 Den „laden der Applikation“ anwendungsfall macht den ersten Schritt des aufbringen der VDV-KA NM Service und Initialisierung davon, danach muss sie noch Konfiguriert werden.

Weitere schritt welche auch ausgeführt wird ist die sogenannte Konfiguration des Discovery Managers. Siehe 6.2.2

- - Den „Update der Applikation“ anwendungsfall macht den ersten Schritt des aufbringen der VDV-KA NM Service, danach muss sie noch Konfiguriert werden.

Siehe 6.2.2



ANF08 Sollte für die OTA-Funktionalität ein Agent (MIDlet oder andere Technologie) benötigt werden, soll dieser auf allen NFC-fähigen Handsets lauffähig sein.

Unterschiede in Performance und Funktionsumfang soll es dabei nicht geben.

Sind dem Anwender Inhalte anzuzeigen, so soll die Anzeige vollständig und korrekt sein.

Typ des Handsets sollte überprüft werden und demensprechend ein TSM-Connector aufgebracht werden.

Siehe 6.2.1

Generelle und/oder Handset Spezifische Software muss im System geladen und ausgeliefert werden können.

Siehe 6.2.1

Generelle und/oder Handset Spezifische Software muss im System geladen und ausgeliefert werden können.

Siehe 6.2.1

Wen so ein Agent benötigt wird wird diese, bevor der VDV-KA NM Service aufgebracht werden kann, geladen

Siehe 6.2.1

Bevor die VDV-KA NM Service geloescht werden kann muss die sogenannte TSM-Connector vorhanden sein oder aufgebracht werden.

Siehe 6.2.1

Bevor die VDV-KA NM Service gesperrt/entsperrt werden kann muss die sogenannte TSM-Connector vorhanden sein oder aufgebracht werden.

Siehe 6.2.1

Bevor die VDV-KA NM Service aufgebracht werden kann muss die sogenannte TSM-Connector vorhanden sein oder aufgebracht werden.

Siehe 6.2.1

ANF09 Es ist nicht zu gewährleisten, dass es nur eine technische Variante eines KA NM Handset-Services mit gleicher Funktionalität gibt, so muss das System selbständig erkennen, welche Zielplattform vorliegt und welche technische Variante dieses benötigt.

Als Resultat einer Überprüfung ist bekannt welche technische Variante der KA NM Service benötigt wird.

Siehe 6.2.1

Übergabe von Software soll gewährleisten das verschiedenste Handset Services geladen werden können.

Siehe 6.2.1

Übergabe von Software soll gewährleisten das verschiedenste Handset Services geladen werden können.

Siehe 6.2.1

Siehe 6.2.1 Siehe 6.2.1 - Siehe 6.2.1 Bevor eine KA NM Service geladen wird muss erkannt werden welche Technische Variante die Zielplattform ist.

Siehe 6.2.1

ANF14 OTA darf nicht verhindern, dass mit der Applikation sowohl der Card-Emulation-Mode als auch Card-Reader-Mode möglich ist.

Siehe 6.2.1 Siehe 6.2.1 Siehe 6.2.1 Bevor eine KA NM Service geladen wird muss erkannt werden welche Technische Variante die Zielplattform ist.

Siehe 6.2.1

Siehe 6.2.1 Siehe 6.2.1 Den Update des VDV-KA NM Service sollte dies nicht ändern.

Siehe 6.2.1



ANF15 Die Verwendung des SE auf einem Handset muss ermöglichen, dass bei Vorhandensein der KA NM Applikation im KA NM Handset-Service das Handset im Card-Emulation-Mode die Transaktionszeit eines KA NMs entsprechend der [VDVKA_NM_SPEC] ist.

Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1

ANF16 OTA darf nicht verhindern, dass sich das Handset im Card-Emulation-Mode im Battery-Off-Mode und Battery-On-Mode bezüglich der Anwenderinteraktion gleich verhält.


ANF19 Wenn die Zielplattform die einwandfreie und benutzerfreundliche Funktionsfähigkeit nur zulässt, wenn Komponenten des KA NM Handset-Services von den Herstellern bzw. Betreibern der Zielplattform zertifiziert sind, so darf das System auch nur solche Komponenten aufspielen.

Wird um Anwendungsfall „prüfen der Voraussetzungen“ gemacht. Siehe 6.2.1

Diese spezifische Software muss im System geladen werden können und dementsprechend adressiert mit Hilfe eines unique ID und Versions nummer. (von KVPS und/oder zielplatform)

Siehe 6.2.1

Diese spezifische Software muss im System geladen werden können und dementsprechend adressiert mit Hilfe eines unique ID und Versions nummer. (von KVPS und/oder zielplatform)

Siehe 6.2.1

Das Laden der Service ändert dies nicht.

Siehe 6.2.1

Siehe 6.2.1 Siehe 6.2.1 Diese spezifische Software muss im System geladen werden sein und dementsprechend adressiert. (von KVPS und/oder zielplatform)

Siehe 6.2.1



ANF25 Die Zeit zum Löschen sollte maximal der Zeit zum Aufbringen der Applikation entsprechen.


ANF30 Es soll möglich sein, die KA-NM Applikation authentisch und vertraulich auf eine Chipkarte (insbesondere auf ein SE) zu laden, welche sich außerhalb einer gesicherten Produktionsumgebung befindet.

Dies wird erreicht durch Verwendung einer KA KG zugelassene SD.







ANF31 Die Schnittstelle zwischen KVP und NFC-Handset mit SE darf keine Organisation (z.B. MNOs, MVNOs, Provider und TSM-Anbieter) diskriminieren. Die Schnittstelle muss unabhängig von den TSM-Varianten (single, authorized, delegated) funktionieren.

Siehe 0 Siehe 0 Siehe 0 Siehe 0 Siehe 0 Siehe 0 Siehe 0

ANF32 Gewährleistung von Interoperabilität: Beim Ticketing sollen die Kunden nur ein ÖV-MIDlet (eines KVP) auf dem Handy haben.




ANF39 Die Prozesse, wie sie zwischen KA Nutzermediumshersteller und KA vereinbart sind (siehe [NUTZERMEDHERERKL]), müssen in das System integriert werden.

KVPS stellt zertifikate zur Verfügung.

Alternativ; Service des Systems, welches dies direkt anfragt..

Zeihe 8.4



Zeihe 8.4



Zeihe 8.4



Zeihe 8.4



Zeihe 8.4



Zeihe 8.4



Zeihe 8.4

ANF40 Der SE Owner darf nach der Personalisierung zu keiner Zeit den Inhalt des zugriffsbeschränkten Bereiches kennen.

Dies ist durch GP gesichert. (Siehe [Ref.1] GP 2.2 Cardspec Kapitel 3.1)







ANF41 Dem System kann mit der Administrierung einzelner oder eine Liste von bestimmten Trägermedien beauftragt werden.




ANF42 Das KVPS übernimmt die Versionsverwaltung für die KA NM Handset-Services. Der KVP ist dafür verantwortlich, dass die einzelnen Komponenten der KA NM Handset-Services zueinander fachlich und technisch kompatibel sind (Bundle). Durch die unterschiedlichen Handsetausprägungen ist es denkbar, dass insbesondere für MIDlets mehrere Ausprägungen existieren, die fachlich die gleiche Funktion haben.

Das System muss vom KVPS die Komponenten der KA NM Handset-Services, deren Versionen und die Zusammengehörigkeit entgegennehmen können. Das System speichert die Komponenten, so dass diese nur einmalig vom KVPS an das System übertragen werden müssen.

Der KVPS kann das Löschen von Bundles im System durchführen.




ANF43 Es sind bei einem Laden bzw. bei einem Update nur die Komponenten des KA NM Handset-Services zu administrieren, die in der gewünschten Version nicht auf der Zielplattform vorliegen.




7.2. Sicherheitsbetrachtung

Die Zielsetzung der vorliegenden Sicherheitsbetrachtung ist die Durchleuchtung möglicher Bedrohungen und Risiken sowie die Ermittlung entsprechender Maßnahmen zur Erreichung eines den Erfordernissen angepassten Sicherheitsniveaus bei der OTA-Provisioning der VDV-Kernapplikation auf NFC-Medien.

Die primären Schutzziele sind

Der Schutz der Vertraulichkeit von persönlichen Kundendaten sowie

die Verhinderung der nichtautorisierten Inanspruchnahme von

Beförderungsleistungen sowie nichtautorisierte Verrechnung solcher Leistungen

zwischen Teilnehmern.

Die Vorgehensweise zur Erstellung der Sicherheitsbetrachtung geschieht im Rahmen dieser Spezifikation in vier Stufen: in der Bestandsaufnahme werden zuerst die zu berücksichtigenden Anwendungsfälle erfasst. Im nächsten Schritt, die Schutzbedarfsanalyse, erfolgt eine Beurteilung der Schutzbedürftigkeit, d.h. der Wichtigkeit, der erfassten Prozesse bzw. Anwendungsfälle in Bezug auf die erklärten primären Schutzziele. Hier werden die sicherheitskritischen Geschäftsprozesse bzw. Anwendungsfälle identifiziert, die in den nachfolgenden Schritten näher untersucht werden müssen. In einer anschließenden Bedrohungsanalyse werden die Gefahren für die sicherheitskritischen Geschäftsprozesse bzw. Anwendungsfälle ermittelt. Im letzten Schritt, werden entsprechenden Sicherheitsmaßnahmen entwickelt und den Bedrohungen gegenübergestellt.

Spezifikationsrelevant sind die im Kap. 7.2.4 definierten Maßnahmen. Alle vorangestellten Betrachtungen in diesem Kapitel dienen lediglich der Nachvollziehbarkeit der entwickelten Maßnahmen.

7.2.1. Bestandsaufnahme Die relevanten Geschäftsprozesse bei der OTA-Provisioning der VDV-Kernapplikation Verwendung auf mobilen Handsets sind:

Prüfen der Voraussetzungen (§6.2.1),

Übergabe von Software (§6.2.2),

Laden des VDV KA NM Handset-Services insbesondere des Cardlet (§6.2.4),

Sperren und Entsperren des VDV KA NM(§6.2.6).

7.2.2. Schutzbedarfsanalyse Zuerst werden hier die Bedeutungen der bereits in der Einleitung zu diesem Kapitel formulierten primären Schutzziele für die einzelnen Teilprozesse erläutert und die Schutzbedürftigkeit hinsichtlich der verschiedenen Sicherheitsziele dargestellt. Zu diesem Zweck wird die in der folgenden Tabelle definierte und im Bereich der Informationssicherheit übliche Kategorisierung von allgemeinen Sicherheitszielen herangezogen.



Sicherheitsziel Definition

Vertraulichkeit Ein Objekt, Prozess oder System gewährleistet Vertraulichkeit, wenn die in ihm enthaltenen Informationen ausschließlich berechtigten Personen oder Systemen zugänglich sind.

Als Schutzziel formuliert bedeutet dies: gespeicherte bzw. zu kommunizierende Informationen sind vor dem Zugriff von Unbefugten zu schützen.

Integrität Integrität bezeichnet die Sicherstellung der Unversehrtheit von Daten und der korrekten Funktionsweise von Systemen.

Als Schutzziel formuliert bedeutet dies: gespeicherte bzw. zu kommunizierende Informationen sind vor unberechtigter Veränderung zu schützen.

Identifizierung Bestätigung der Identität einer Entität (z.B. einer Person, eines Terminals, einer Karte etc.).

Authentizität Authentizität einer Information ist die sichere Zuordnung zum Sender und der Nachweis, dass die Informationen nach dem Versand nicht mehr verändert worden sind. Diese Eigenschaft bedeutet zugleich, dass die Daten integer übertragen wurden.

Autorisierung / Zugriffskontrolle

Autorisierung ist die Übertragung einer offiziellen Genehmigung an eine Entität, eine bestimmte Rolle einnehmen bzw. eine bestimmte Aktion durchführen zu dürfen. Bei einer damit einhergehenden Zugriffskontrolle handelt es sich um die Einschränkung des Zugriffs auf bestimmte Ressourcen zu entsprechend autorisierten Entitäten.

Eine Autorisierung kann für ungültig erklärt werden (Widerruf).

Zertifizierung Bestätigung von Informationen durch eine vertrauenswürdige Instanz.

Eine Zertifizierung kann für ungültig erklärt werden (Widerrufung).

Bezeugung / Zeitstempel

Bestätigung der Erzeugung oder Existenz einer bestimmten Information durch eine nicht an deren Erzeugung beteiligte Entität.

Aufzeichnung des Zeitpunktes der Erzeugung oder Existenz einer bestimmten Information.

Nichtabstreitbarkeit Unter Nichtabstreitbarkeit wird die Gewährleistung verstanden, dass die Erzeugung bestimmter Daten oder Auslösung bestimmter Ereignisse durch eine spezifizierte Entität nicht in Abrede gestellt werden kann. Spezielle Formen sind:

Urheberschaftsbestätigung (Bestätigung, dass eine

bestimmte Information durch eine spezifizierte Entität

erzeugt wurde)

Empfangsbestätigung (Bestätigung, dass eine bestimmte

Information erfolgreich von einer spezifizierten Entität

empfangen wurde)

Auftragsbestätigung (Bestätigung, dass durch eine

spezifizierte Entität eine bestimmte Leistung erfolgreich



Sicherheitsziel Definition

erbracht bzw. eine bestimmte Funktion erfolgreich

durchgeführt wurde)

Anonymität Anonymität ist die Unverknüpfbarkeit zwischen der Identität einer Entität und der von dieser Entität ausgelösten Ereignisse.

Somit gibt es z.B. Sender-Anonymität als Unverknüpfbarkeit zwischen Sender und Nachricht und Empfänger-Anonymität als Unverknüpfbarkeit zwischen Nachricht und Empfänger.

Verfügbarkeit Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen oder IT-Netzen oder auch von Informationen ist vorhanden, wenn diese den Benutzern stets wie gewünscht (z.B. in zugesicherter Form und Qualität in einem zugesicherten Zeitraum) zur Verfügung stehen.

Als Schutzziel formuliert bedeutet dies: Informationen und Betriebsmittel sind vor unbefugter Vorenthaltung zu schützen.

Eindeutigkeit Innerhalb einer definierten Gruppe von Ereignissen bedeutet die Eindeutigkeit von bestimmten, mit diesen Ereignissen assoziierten Informationen, dass aus der Gleichheit zweier dieser Informationen deren Assoziierung mit dem selben Ereignis folgt.

Zusammenhängig-keit oder Lückenlosigkeit

Es wird von der Zusammenhängigkeit oder Lückenlosigkeit einer

Menge von Informationselementen , die bestimmten Ereignissen

zugeordnet sind, gesprochen, wenn eine Parametrisierung (t), t = 1, 2, 3, ... dieser Elemente existiert, so dass aus dem Vorliegen

bestimmter Elemente (n) und (m) mit n<m geschlossen werden

kann, dass alle Elemente (t) mit n<t<m auch bereits erzeugt wurden, und folglich dass assoziierte Ereignisse stattgefunden haben.

Tabelle 1: Kategorisierung von allgemeinen Sicherheitszielen

Hinsichtlich der Schutzbedürftigkeit werden zum betrachteten Anwendungsfall die verschiedenen allgemeinen Sicherheitszielen jeweils bewertet, um diese als wesentlich oder vernachlässigbar für die weitere Betrachtung einzustufen. Eine weiter abgestufte Bewertung ist erst im Rahmen einer spezifischen Umsetzung eines dann vorliegenden Umsetzungskonzepts sinnvoll.



7.2.2.1. Schutzbedarfsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“

Teilprozess: Prüfen der Voraussetzungen

Allgemeine Erläuterung der primären Schutzziele

Der Anwendungsfall beinhaltet die Prüfung der Eignung eines bestimmten Handsets sowie der Zulassung des damit assoziierten SE im Rahmen der Provisioning eines bestimmten Service. Der Ablauf der Prüfung ist wie folgt:

1. Prüfung, ob das KVPS berechtigt ist, über das KA OTA Provisioning-System eine Anfrage zu starten;

2. Beauftragung des KA OTA Provisioning-Systems durch das KVPS die Voraussetzungen von einem bestimmten NFC Handset zu prüfen (Input ist die Handy-Nummer des Nutzer-Handsets);

3. Das KA OTA Provisioning-System überprüft, ob das Handset erreichbar ist;

4. KA OTA Provisioning-System überprüft die Voraussetzung, d.h.

5. ob es sich um ein geeignetes Handset handelt, d.h. ob die Handset-Services für das spezifische Modell verfügbar sind, und

6. ob das SE zugelassen ist, d.h. ob das SE auf der Liste von KA KG zertifizierten SE vorhanden ist.

7. Meldung an das KVPS (mit Details wie Handy-Type, SE Type und OS Version).

Aus Sicht des Nutzers darf seine Handy-Nummer nicht zweckentfremdet werden oder an Organisationen gelangen, die nicht an der Erbringung der Leistung direkt beteiligt sind.

Aus Sicht des KA OTA Provisioning-Systems dürfen nur Anfragen von autorisierten KVPs bearbeitet werden und nur auf eine entsprechend spezifizierte Art und Weise. Ferner sollte gewährleistet werden, dass die vom Handset erhaltenen Informationen tatsächlich dem Zustand im Handset mit der angegebenen Handy-Nummer entsprechen.

Aus Sicht des KVP müssen die vom KA OTA Provisioning-System erhaltenen Informationen tatsächlich dem Zustand im Handset mit der angegebenen Handy-Nummer entsprechen.

Sicherheitsziele Bewertung

Vertraulichkeit

Der vertrauliche Umgang mit den Handy-Nummern der Nutzer durch KVP und KA OTA Provisioning-System.

wesentlich

Anonymität

Die Unverknüpfbarkeit für das KA OTA Provisioning-System zwischen der übermittelten Handy-Nummer und der Identität des Nutzers sowie weiterer nutzerspezifischen Daten wie Berechtigungen, Fahrten etc.

wesentlich

Identifizierung

Aus Sicht des KA OTA Provisioning-Systems muss die Identität eines anfragenden KVP bestätigt werden können.

wesentlich

Eindeutigkeit vernachlässigbar



Teilprozess: Prüfen der Voraussetzungen

Lückenlosigkeit Vernachlässigbar

Integrität

Die Integrität der Informationen aus dem Handset hin zum KA OTA Provisioning-System bzw. hin zum KVPS.

Wesentlich

Authentizität

Die Authentizität der Informationen aus dem Handset hin zum KA OTA Provisioning-System bzw. hin zum KVPS.

wesentlich

Nichtabstreitbarkeit Vernachlässigbar

Autorisierung

Es dürfen nur autorisierte KVPs eine Prüfung der Voraussetzungen für ein Handset veranlassen.

wesentlich

Zertifizierung

---

vernachlässigbar


---

vernachlässigbar

Verfügbarkeit

---

vernachlässigbar

Tabelle 2: Schutzbedarfsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“

7.2.2.2. Schutzbedarfsanalyse im Anwendungsfall „Übergabe von Software“

Teilprozess: Übergabe von Software


Der Anwendungsfall beinhaltet die Übergabe der Whitelists der erlaubten Handsets und SE sowie der für einen VDV-KA NM-Service benötigten Software-Komponenten (Midlets, Cardlets und ggf. TSM Connector) an das System, wo diese nach einer Überprüfung ins Repository geladen werden. Die Software wird vom Lieferant über den KVP an das System übergeben. Aus Sicht des KVP und des System-Verantwortlichen muss erkennbar sein,

um welche Softwarekomponenten es sich handelt,

von welchem Lieferant die Software bereitgestellt wird und

dass der Lieferant berechtigt ist, die Softwarekomponenten im System entsprechend einzusetzen.

Ferner muss aus Sicht des KVP und des System-Verantwortlichen verhindert werden, dass Schaden durch Änderungen an den Softwarekomponenten bzw. durch Bekanntwerden der Funktionsweise der Softwarekomponenten entstehen.

Aus Sicht des Lieferanten müssen auch seine geistigen Eigentumsrechte an Software-Produkten geschützt werden.


Vertraulichkeit wesentlich



Teilprozess: Übergabe von Software

Der vertrauliche Umgang mit dem Code der Software-Komponenten bei der Übertragung vom Lieferanten in das System sowie bei der Speicherung im System.

Anonymität vernachlässigbar

Identifizierung

Sowohl der Lieferant von Software-Komponenten als auch die spezifischen Komponenten müssen identifizierbar sein.

wesentlich

Eindeutigkeit Vernachlässigbar


Integrität

Die Integrität der Informationen während der Übertragung vom Lieferant ins System.

Wesentlich

Authentizität

Die Authentizität der Informationen während der Übertragung vom Lieferant ins System.

wesentlich


Autorisierung

Es dürfen nur autorisierte Lieferanten Software-Komponenten ins System einbringen.

wesentlich

Zertifizierung

---

vernachlässigbar


---

vernachlässigbar

Verfügbarkeit

---

vernachlässigbar

Tabelle 3: Schutzbedarfsanalyse im Anwendungsfall „Übergabe von Software“



7.2.2.3. Schutzbedarfsanalyse im Anwendungsfall „Laden, des VDV KA NM Handset-Services (Cardlet)“

Teilprozess: Laden des VDV KA NM Handset-Services (Cardlet)


Der Anwendungsfall beinhaltet folgende Schritte:

1. Vorab wird eine Prüfung der Voraussetzungen durchgeführt, insbesondere ob

ein geeignetes Handy,

ein geeigneter TSM-Connector, sofern notwendig, sowie

ein geeignetes SE

vorhanden sind.

Insbesondere muss das SE für das spezifische Cardlet zertifiziert sein und über eine Security Domain (SD) verfügen, in die das Cardlet geladen werden darf.

Darüber hinaus muss das System auf die SD zugreifen können.

2. Es wird geprüft, ob der KVP berechtigt ist, das spezifische Cardlet in die vorliegende SD zu laden.

3. Die GlobalPlatform-Prozesse Install und Personalize (mittels Store Data) werden durchgeführt. Dabei werden das Cardlet in das SE und der Root-CA-Schlüssel der VDV PKI sowie der entsprechende Konfigurator-Schlüssel in das Cardlet eingebracht.

4. Die KA Initialisierung des Cardlets wird durchgeführt. Dabei werden das Schlüsselpaar des Cardlets erzeugt und das Zertifikat beantragt und eingebracht.

5. Der KVP wird über den Vorgang benachrichtigt.

Aus Sicht des KVP muss das Cardlet unversehrt und nachvollziehbar in das SE geladen werden und es dürfen keine Informationen preisgegeben werden, die die Sicherheit oder Funktionsfähigkeit des Cardlets beeinträchtigen könnten, insbesondere muss das gesamte Schlüsselmaterial des Cardlets geheim gehalten werden.

Darüber hinaus darf aus Sicht des System-Verantwortlichen nur ein berechtigter KVP den Prozess veranlassen.

Aus Sicht des Cardlet-Lieferanten muss sein Produkt vor unbefugtem Kopieren oder Ändern geschützt werden.


Vertraulichkeit

des Cardlets sowie dessen geheimen Schlüssel bei der Übertragung vom System (TSM und Konfigurator) zum SE hin sowie während des Betriebs im SE.

wesentlich


Identifizierung

des KVP sowie des Cardlets.

wesentlich



Integrität

des Cardlets sowie dessen Daten (insbesondere Schlüssel) bei der

Wesentlich



Teilprozess: Laden des VDV KA NM Handset-Services (Cardlet)

Übertragung vom System (TSM und Konfigurator) zum SE hin sowie während des Betriebs im SE.

Authentizität

der Datenübertragung zwischen dem System (TSM und Konfigurator) und dem SE.

wesentlich

Nichtabstreitbarkeit vernachlässigbar

Autorisierung

des KVP zum Laden des Cardlets.

wesentlich

Zertifizierung vernachlässigbar

Bezeugung / Zeitstempel vernachlässigbar

Verfügbarkeit vernachlässigbar

Tabelle 4: Schutzbedarfsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“

7.2.2.4. Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“

Teilprozess: Sperren/Entsperren des VDV KA NM


Der Anwendungsfall beinhaltet folgende Schritte:

1. Es wird geprüft, ob der KVP berechtigt ist, das spezifische Cardlet in die vorliegende SD zu laden.

2. Der GlobalPlatform-Prozesse Lock Privileges werden durchgeführt, um die Applikation generell selektierbar oder um sie zu nicht mehr selektierbar und damit von außen nicht mehr als vorhanden erkennbar zu machen.

3. Der KVP wird über den Vorgang benachrichtigt.

Aus Sicht des KVP muss die Funktion, die das Cardlet bietet, über das vom SE zur Verfügung gestellte Interface verfügbar gemacht werden bzw. ist die Funktionalität in der Art und Weise zu sperren, dass das Cardlet von außerhalb der SD als nicht vorhanden erkannt werden kann und somit auch keine Funktionalität zur Verfügung stellt.

Darüber hinaus darf aus Sicht des System-Verantwortlichen nur ein berechtigter KVP den Prozess veranlassen.


Vertraulichkeit Vernachlässigbar


Identifizierung

des anfragenden KVP sowie des Cardlets, dessen Verfügbarkeit gesteuert werden soll.

wesentlich





Teilprozess: Sperren/Entsperren des VDV KA NM

Integrität

Die Bestätigung der SD, dass sie die angeordnete Zustandsänderung auch übernommen hat

wesentlich

Authentizität

Die Authentizität der Bestätigung durch die SD, über das Handset, das OTA-Provisioning-System bis hin zum KVP

wesentlich


Autorisierung

des KVP zum Sperren/Entsperren des Cardlets bzw. des zu sperrenden/entsperrenden Cardlets

wesentlich

Zertifizierung vernachlässigbar

Bezeugung / Zeitstempel vernachlässigbar

Verfügbarkeit vernachlässigbar

Tabelle 5: Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“

7.2.3. Bedrohungsanalyse In der Bedrohungsanalyse sind Bedrohungen zu erfassen, die eine Gefährdung der Schutzziele zur Folge haben könnten. Jedes Objekt wird hinsichtlich verschiedener Bedrohungen, z.B.

vorsätzliche Manipulation,

höhere Gewalt,

technisches Versagen,

menschliches Versagen,

allgemeine und politisch motivierte Kriminalität sowie

Missbrauch (bei unberechtigtem Zugriff oder Weitergabe an Dritte)

daraufhin untersucht, ob sich hieraus ein konkretes Risiko ergibt.

Aus der Bedrohung eines Schutzzieles leitet sich ein resultierendes Risiko ab. Damit Sicherheitsmaßnahmen zum Erfolg führen, muss eine sorgfältige Risikoanalyse erfolgen. Im Falle einer konkreten Umsetzung des vorliegenden Systemkonzepts mit bekannten Größen (Umsatzzahlen, Nutzer, etc.) kann eine Quantifizierung des Risikos (jeweils als Produkt aus geschätzter Schadenshöhe und Eintrittswahrscheinlichkeit) auf Basis der vorliegenden allgemeinen Sicherheitsbetrachtung aufgebaut werden.

Im Folgenden werden die Zusammenhänge zwischen Bedrohungen und Risiken auf einem dem Konzept entsprechenden allgemeinen Niveau erläutert, so dass die Kritikalität der Bedrohungen qualitativ erfasst und eine Grundlage für weitergehende, quantitative Betrachtungen spezifischer Umsetzungen geschaffen wird.



7.2.3.1. Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“

Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko

Prüfen der Voraussetzungen

1 Vertraulichkeit

Ausspähen von Handy-Nummern während der Übertragung zwischen KVPS und KA OTA Provisioning-System bzw. nichtautorisierter Zugriff auf diese Daten im KVPS oder KA OTA Provisioning-System.

Es sind hohe, schwer abschätzbare Image-Schäden in der Öffentlichkeit möglich, die indirekt auch zu Einnahme-verlusten führen können. Das Bekanntwerden von Handy-Nummern auch ohne weitere Verknüpfung zu Personen ist kritisch zu sehen. Daher wird diese Bedrohung als allgemein kritisch angesehen.

Eine eventuelle Aggregation dieser Daten im KVPS oder KA OTA Provisioning-System stellt ein erhöhtes Schadenpotential dar.

2 Anonymität

Nichtautorisierter Zugriff auf Datenbestände im KVPS bzw. KA OTA Provisioning-System, um eine direkte Verknüpfung der Identitäten von Einzelpersonen mit deren Handy-Nummern zu ermöglichen.

Es sind hohe, schwer abschätzbare Image-Schäden in der Öffentlichkeit möglich, die indirekt auch zu Einnahme-verlusten führen können. Durch das mögliche Bekanntwerden von persönlichen Daten in Verbindung mit den Handy-Nummern, und da es sich ggf. um aggregierte Datenmengen handelt, ist das Schadenspotential in diesem Fall noch höher als in Nr.1. Daher wird diese Bedrohung als allgemein sehr kritisch angesehen.

3 Identifizierung

Kann das KA OTA Provisioning-System den anfragenden KVP nicht identifizieren, so kann das System „Denial-of-Service“-Angiffe ausgesetzt werden bzw. können Anfragen von nicht autorisierten Organisationen nicht erkannt werden.

Hierdurch kann es zu Störungen im Betriebsablauf kommen.

4 Integrität Durch Manipulation oder Korrumpierung der Daten an der Schnittstelle zum KA OTA Provisioning-System bzw. zum KVPS kann es zur Installierung von Services auf ein Handset kommen, für die das Handset die Voraussetzungen bzw. die Autorisierung nicht hat.

Hierdurch kann es zu Störungen im Betriebsablauf sowie schädlichen oder nicht funktionsfähigen Installationen kommen.

5 Authentizität

Wenn die Verbindung der Informationen mit einem bestimmten Handset für das KA OTA Provisioning-System nicht feststellbar ist, kann es mittels eines „man-in-the-middle“ Angriffs zum Laden von Handset-Applikationen auf ein

Hierdurch kann es zu Störungen im Betriebsablauf sowie Installieren von Applikationen auf nicht identifizierten Handsets kommen, was auch zu




anderes Handset. finanziellen Verlusten führen kann, sofern die betroffenen Applikationen nicht kostenfrei sind.

6 Autorisierung

Können nicht autorisierte Entitäten Anfragen an das KA OTA Provisioning-System stellen, so können „Denial-of-Service“-Angriffe auf das System gefahren werden.

Hierdurch kann es zu Störungen im Betriebsablauf kommen.

Tabelle 6: Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“

7.2.3.2. Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“



1 Vertraulichkeit

Durch das Ausspähen von Software-Komponenten durch Unberechtigte bei der Übertragung zwischen Lieferant (über KVP) und System bzw. aus dem Repository des Systems können verschiedene Bedrohungen entstehen.

Die Analyse der so erhaltenen Software kann z.B. Anhaltspunkte für Angriffe auf das eTicket-System liefern oder es kann zu Produktpiraterie kommen.

Signifikante Systemstörungen, Verluste finanzieller Art seitens der Teilnehmer im eTicket-System und der Lieferanten sind möglich. Daher werden diese Bedrohungen generell als kritisch angesehen.

2 Identifizierung

Sind die Software-Komponenten oder die Software-Lieferanten selbst nicht eindeutig identifizierbar, kann es durch Irrtum oder gezielte Täuschung zur Übergabe und Installierung inkorrekter Software-Komponenten.

Hierdurch kann es zu signifikanten Störungen im Betriebsablauf mit einhergehenden finanziellen Verlusten und Image-Schäden kommen.

3 Integrität Ist die Integrität der an das System übertragenen Daten (Software, Whitelists) nicht gesichert, so können unbeabsichtigte Korrumpierungen oder auch gezielte Änderungen der Daten durch Angreifer nicht zuverlässig erkannt werden. Somit kann es zum Einsatz solcher korrumpierten Software bzw. zur Nutzung einer inkorrekten Whitelist kommen.

Hohe Schäden sind möglich, da große Teile des Systems kompromittiert werden können. Daher werden diese Bedrohungen generell als kritisch angesehen.

4 Authentizität

Ist die Quelle der Daten (Software, Whitelists) bei der Übertragung an das System nicht mit Sicherheit feststellbar, dann kann es ebenfalls durch Irrtum oder gezielte Täuschung zur Übergabe und Installierung inkorrekter Software-Komponenten kommen. Solche Software kann auch Funktionen anbieten die

Da auf dieser Weise u.a. sehr kritische Daten wie geheime Schlüssel aus dem Echt-System heraus gezogen werden können, sind die potentiellen Schäden sehr hoch. Daher werden diese Bedrohungen generell als extrem




nicht erlaubt sind und die die Ausgabe kritischer Daten, z.B. Schlüssel, im Klartext ermöglichen. Siehe auch §7.2.3.3, Nr. 4.

kritisch angesehen.

5 Autorisierung

Kann ein nicht autorisierter Lieferant am System normal teilnehmen, so kann er auf normalem Weg manipulierte Software-Komponenten (mit eingebauten Sicherheitslücken, nicht erlaubten Funktionen oder Fehlfunktionen) einbringen. Die möglichen Auswirkungen sind ähnlich zu Nr.4.

Tabelle 7: Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“

7.2.3.3. Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“


„Laden des VDV KA NM Handset-Services (Cardlet)“

1 Vertraulichkeit

Durch das Ausspähen der Cardlet-Software durch Unberechtigte bei der Übertragung bzw. aus dem SE selbst entstehen ähnliche Bedrohungen wie in §7.2.3.2, Nr.1. Ist es aber möglich geheime Schlüssel bei der Übertragung oder aus dem Cardlet auf dem SE auszuspähen, so können „unechte“ Cardlets ins Feld gebracht, die nicht von echten zu unterscheiden sind und mit deren Hilfe beispielsweise Berechtigungsschlüssel kompromittiert werden könnten, so dass man in der Lage wäre, unberechtigterweise auch Berechtigungen auszugeben.

Sehr hohe Schäden sind möglich, da große Teile des Systems wesentlich kompromittiert werden können. Daher werden diese Bedrohungen generell als extrem kritisch angesehen.

2 Identifizierung

Sind die Software-Komponenten oder die anfragenden KVPs nicht eindeutig identifizierbar, kann es durch Irrtum oder gezielte Täuschung zur Übergabe und Installierung der falschen Software-Komponenten aus dem Repository des Systems kommen.

Ist das Cardlet nicht eindeutig identifizierbar, entstehen ähnliche Bedrohungen wie in §7.2.3.2, Nr.2.

Hierdurch kann es zu Störungen im Betriebsablauf, Image.-Schäden sowie finanziellen Schäden für Lieferanten kommen. Daher werden diese Bedrohungen generell als kritisch angesehen.

3 Integrität Ist die Integrität nicht gesichert, so können unbeabsichtigte oder auch gezielte Korrumpierungen des Cardlets oder des Schlüsselmaterials während der Übertragung zum SE bzw. während des Betriebs im SE nicht zuverlässig erkannt werden. Auf dieser Weise können Komponenten funktionsunfähig

Hohe Schäden sind möglich, da große Teile des Systems kompromittiert werden können. Daher werden diese Bedrohungen generell als kritisch angesehen.




gemacht. Auch können hierdurch verschiedene „Fault Injection“ Angriffe ermöglicht werden, die die Sicherheit des VDV KA NM stark beinträchtigen.

4 Authentizität

Authentisiert sich das SE (bzw. die SD auf dem SE) beim Laden des Cardlets nicht, so könnte ein Angreifer ein echtes Cardlet und dessen Schlüssel in ein „Rogue SE“ laden lassen. Ein solches Rogue SE könnte mit zusätzlichen, in einem echten SE nicht erlaubten Funktionen ausgestattet werden, so dass z.B. alle von den Echtsystemen an das Cardlet gesendeten Daten inkl. Schlüssel in Klartext ausgegeben werden könnten.

Authentisiert sich das Cardlet beim Laden des Zertifikats nicht, so könnte ein Angreifer das Zertifikat für ein „Rogue Cardlet“ ausstellen lassen, das wiederum die Ausgabe aller empfangenen Daten inkl. Berechtigungs-schlüssel in Klartext ermöglichen würde.

Authentisiert sich das System nicht, so könnten andererseits durch ein „Rogue System“ auch manipulierte Cardlets auf SEs installiert werden, die dann ebenfalls durch zusätzlichen, in einem „echten“ Cardlet nicht erlaubten Funktionen alle durch die Cardlets empfangenen Daten in Klartext ausgeben.

Authentisiert sich der Kunde nicht als Besitzer des angegebenen Handsets, so können sich Angreifer unauthorisiert in den Besitz von Software auf ihrem Handset bringen oder veranlassen, dass Software ungewollt von den Besitzern auf deren Handsets geladen wird.

Da auf dieser Weise u.a. sehr kritische Daten wie geheime Schlüssel aus dem Echt-System heraus gezogen werden können, sind die potentiellen Schäden sehr hoch. Daher werden diese Bedrohungen generell als extrem kritisch angesehen.

5 Autorisierung

Ohne eine Autorisierungsprüfung könnte ein KVP Software aus dem Repository des Systems in Handsets installieren lassen, für die er normalerweise die Erlaubnis nicht hätte.

Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden für Lieferanten kommen. Daher werden diese Bedrohungen generell als kritisch angesehen.

Tabelle 8: Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“



7.2.3.4. Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“


„Sperren/Entsperren des VDV KA NM “

1 Identifizierung

Ist der anfragende KVP nicht eindeutig identifizierbar, kann es durch Irrtum oder gezielte Täuschung zur unberechtigten Sperrung bzw. zur Freigabe von gesperrten Applikationen kommen.

Ist das Cardlet nicht eindeutig identifizierbar, so kann sich ein Kunde die Freigabe eines gesperrten Cardlets erschleichen.

Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden. Daher werden diese Bedrohungen generell als kritisch angesehen.

2 Integrität Ist nicht gesichert, dass die SD die angeordnete Zustandsänderung übernommen hat, so kann nicht sichergestellt werden, dass schadhaftes Verhalten durch die Sperrung auch eingeschränkt werden kann.


3 Authentizität

Authentisiert sich das SE (bzw. die SD auf dem SE) beim Sperren/Entsperren des Cardlets nicht, so könnte ein Angreifer ein bereits gesperrtes, anderes Cardlet entsperren lassen und es anschließend unberechtigt benutzen.

Authentisiert sich der KVP nicht, so kann ein Angreifer die Sperrung/Entsperrung beliebiger Applikationen veranlassen.

Authentisiert sich das System nicht gegenüber dem KVP, so ist es möglich, dass ein Angreifer-System die vom KVP veranlasste Applikationssperrung nicht umsetzt und damit der vermeidlich gesperrte Kunde weiterhin Schaden erzeugen kann.


4 Autorisierung

Ohne eine Autorisierungsprüfung könnte ein KVP die Sperrung/Entsperrung beliebiger Applikationen verlassen, für das er normalerweise die Erlaubnis nicht hätte.


Tabelle 9: Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“



7.2.4. Maßnahmen In einem Maßnahmenplan werden Maßnahmen gegen die bereits erkannten Bedrohungen behandelt.

Ziel der im Maßnahmenplan aufgeführten Maßnahmenauswahl ist es, das zu schützende Objekt/Teilobjekt durch geeignete und angemessene Maßnahmen präventiv so zu gestalten, dass eine Reduzierung des bekannten Risikos erreicht wird. Dabei soll das Risiko möglichst gegen „Null / kein Risiko“ reduziert werden. Maßnahmen können die Schadenshöhe oder Schadenshäufigkeit verringern.

Die Maßnahmenauswahl wird in zwei Kategorien aufgeteilt:

I. Maßnahmen, die im Rahmen dieser Betrachtung zur Erfüllung der Interoperabilität mindestens erfüllt sein müssen. Diese Maßnahmen der Kategorie I sind dadurch gekennzeichnet, dass sie einen Verweis auf ein entsprechendes Kapitel tragen, in denen die Komponenten und die Schnittstellen beschrieben sind bzw. auf die bisher in der Kernapplikation spezifizierten Maßnahmen tragen.

II. Maßnahmen, die als Ausgangspunkt für eine quantitative Betrachtung in einer speziellen (Umsetzungs-)Situation dienen und entsprechend ausgearbeitet werden sollen. Maßnahmen der Kategorie II sind dadurch gekennzeichnet, dass sie keinen Verweis auf eine konkrete Maßnahme haben und deshalb mit „-“ gekennzeichnet sind.

Das Ziel der spezifizierten Maßnahmen in der Kategorie I ist es, Festlegungen im Rahmen der allgemeinen Betrachtung zu machen, die bei der Ausarbeitung eines detaillierten Maßnahmenplans für eine spezielle Umsetzungssituation nicht mehr modifiziert werden müssen, um Restrisiken auf ein akzeptables Niveau reduzieren zu können.

Die allgemeinen Maßnahmen in der Kategorie II dienen als Ausgangspunkt für die Festlegungen weiterer spezifischer Maßnahmen für spezielle Umsetzungssituationen. Für diese Maßnahmen soll dann eine entsprechende Gegenüberstellung des Restrisikos und der (quantifizierbaren) Gesamtkosten erfolgen.

7.2.4.1. Betrachtung von Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“

Nr. Maßnahmen Verweis

Prüfen der Voraussetzungen

1 a. Verschlüsselung der Datenübertragung zwischen KVPS und KA OTA

Provisioning-System . Eine konkrete Lösung könnte z.B. die Erweiterung

der Transaktionsdatenstrukturen im Interoperabilitätsnetzwerk der KA, um

diesen Datenaustausch zu unterstützen und somit auch die dort greifende

Verschlüsselung anzuwenden.

b. Sichere Speicherung der Daten im KVPS und KA OTA Provisioning-

System sowie Beschränkung des internen Zugriffs.

c. Die Verwendung der Daten muss in einer verbindlichen Erklärung mit

dem Kunden vereinbart werden. Daten dürfen ohne Einwilligung des

Kunden weder weiter bekannt gegeben noch für andere Zwecke

-

-

-




verwendet werden.

d. Die Daten dürfen im KVPS und KA OTA Provisioning-System nur so

lange gehalten werden wie für den Zweck notwendig sind (Fristen in

Erklärung festzulegen).

-

2 a. Im KA OTA Provisioning-System dürfen persönliche Daten über Nutzer

nur mit Zustimmung des Nutzers gehalten werden.

b. Die in diesem Anwendungsfall verwendeten Daten müssen im KVPS

„alias“ gespeichert werden. Der Schutz vor unberechtigtem

Zusammenführen kann z.B. durch physische Trennung der

Datenbestände in separaten Systemen oder durch logische

Zugriffsberechtigungen erfolgen.

-

-

3 Das anfragende KVPS soll zu Beginn der Kommunikation mit dem KA OTA

Provisioning-System im Rahmen einer Authentisierung identifiziert werden. Dafür

muss der Zuordnung des bei der Authentisierung verwendeten Schlüssels zur

Identität des KVP im KA OTA Provisioning-System bekannt sein.

Das kann beispielsweise durch eine zertifikatsbasierte TLS-Zertifizierung, wie im

ION der KA [11], realisiert werden, wobei der KVP im Zertifikat genannt wird und

das KA OTA Provisioning-System die Zertifikate prüfen kann.

-

-

4 Der Datenaustausch zwischen KVPS und KA OTA Provisioning-System bzw. KA

OTA Provisioning-System und Handset muss mit MACs (Message Authentication

Codes) oder digitalen Signaturen versehen werden.

Unter Nutzung des ION der KA an der Schnittstelle KVPS und KA OTA

Provisioning-System werden diese Anforderungen sowohl durch die Anwendung

von „WS Signature“ als auch MACs mit Sessionkeys im Rahmen einer TLS

Authentisierung erfüllt.

An der Schnittstelle zwischen KA OTA Provisioning-System und Handset kann

beispielsweise hier ebenfalls eine TLS Authentisierung oder die

Sicherheitsmechanismen des GSM Standards zur Bildung einer sicheren Session

verwendet werden.

-

[11]

-

5 Bei der Übertragung werden die Daten mit einer Signatur oder einem MAC

gesichert, wobei der MAC auf Basis eines Sessionkeys berechnet wird, der

zwischen dem KA OTA Provisioning-System und dem Handset im Rahmen einer

Authentisierung vereinbart wird. Es muss dabei zugesichert werden, dass das

anschließende Laden einer Applikation auf dasselbe Hansdset geschieht, das auf

die Prüfung der Voraussetzung geantwortet hat.

Diese Anforderung kann mit den Sessionmechanismen des GSM Standards

realisiert werden, wobei das anschließende Laden der Applikation im Rahmen

derselben Authentisierung durchgeführt wird, wie die Prüfung der

-

-




Voraussetzungen.

6 Nach der Authentisierung eines KVPs gegenüber dem KA OTA Provisioning-

System, prüft das KA OTA Provisioning-System das Authentisierungsmerkmal auf

die entsprechende Autorisierung des KVP. Dazu erhält das KA OTA Provisioning-

System eine Whiteliste, in der die autorisierten Organisationen aufgeführt sind

(siehe auch Anwendungsfall „Übergabe von Software“ bzgl. der Übergabe von

Whitelists.

Im Falle der Nutzung eines Zertifikats für die Authentisierung (z.B. im ION der KA)

prüft das KA OTA Provisioning-System die Org.-ID aus dem Zertifikat gegen die

Liste.

-

-

Tabelle 10: Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“

7.2.4.2. Betrachtung von Maßnahmen im Anwendungsfall „Übergabe von Software“



1 Die Übertragung von Software-Komponenten bzw. Whitelists vom Absender an

das System muss verschlüsselt sein.

Darüber hinaus muss im System ein wirksamer Schutz vor unberechtigten

Zugriffen auf das Repository implementiert sein. Hierzu gehört die Abschottung

durch Firewalls sowie die Umsetzungen eines Berechtigungskonzepts für

Administratoren.

-

-

2 Lieferanten bzw. Hersteller müssen durch die VDV KA KG mit Firmennamen und

Adresse registriert werden und eine eindeutige Org.-ID zugeordnet bekommen,

die in einer entsprechenden Whitelist eingetragen und verteilt werden.

Zertifizierte bzw. zugelassene Software-Komponenten, zertifizierte SE und

zugelassene Handsets müssen ebenfalls durch die VDV KA KG registriert werden

und eine eindeutige Identifizierung zugeordnet bekommen, die in entsprechenden

Whitelists eingetragen und verteilt werden.

Die Identifizierung einer Software-Komponente muss Angaben zum Typ der

Software (Midlets, Cardlets, und ggf. TSM Connector), zur Org.-ID des

Lieferanten bzw. Herstellers, zur Spezifikationsversion, zur Release und ggf. zur

Gültigkeit enthalten.

Die Identifizierung eines SE muss Angaben zum SE Owner (Org.-ID), zur

Hardware-Kennung des Herstellers sowie den dafür geeigneten Cardlets

enthalten.

Die Identifizierung eines Handsets muss Angaben zur Hardware-Kennung des

KA

KA

KA

KA

KA




Herstellers sowie zu geeigneten Software-Komponenten und SE enthalten.

Whitelists müssen mit Angaben

zum Listen-Typ (Listen der Lieferanten, eTicket-Teilnehmer, Software-

Komponenten, Hardware-Komponenten),

zum Erstellungsdatum der Liste mit ggf. laufender Nummer, um die

Eindeutigkeit zu sichern, sowie

zur Gültigkeit der Liste

ausgestattet werden.

KA

3, 4

Die Integrität und Authentizität der Daten (Software und Whitelists) wird durch

eine digitale Signatur geschützt, die vom Absender generiert wird.

[11]

5 Bevor eine Software-Komponente in das Repository aufgenommen wird, prüft das

System, ob diese in der aktuellen Whitelist der Software-Komponenten vorhanden

ist.

-

Tabelle 11: Maßnahmen im Anwendungsfall „Übergabe von Software“

7.2.4.3. Betrachtung von Maßnahmen im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“


Laden des VDV KA NM Handset-Services (Cardlet)

1 Die Kommunikation zwischen dem System (TSM) und dem SE verwendet

das im Rahmen von GlobalPlatform definierte Secure Messaging. Damit

werden alle Nachrichten mit einem dafür vereinbarten Sessionkey

verschlüsselt. Der Sessionkey wird in einer gegenseitigen Authentisierung

vereinbart. Die Basis dafür sind die Schlüssel des AH in der SD.

Darüber hinaus wird das Schlüsselpaar für das VDV KA NM wird im SE

erzeugt und ausschließlich im SE gespeichert (nicht auslesbar).

Die im Rahmen der Zertifizierung gestellten Anforderungen an der

Beschaffenheit des SE gewährleisten die Vertraulichkeit des Cardlet-Code

sowie der geheimen Schlüssel im SE während der Nutzung.

[10]

[10]

KA Zertifizierung

2 Abgedeckt durch die Maßnahmen in §7.2.4.2, Nr.2. §7.2.4.2, Nr.2

3, 4

Durch die Verwendung der GlobalPlatform Session in Nr.1 werden beide

Seiten in der Kommunikation authentisiert und die Integrität des gesamten

Datenaustauschs wird mit Hilfe eines zweiten, dafür zusätzlich vereinbarten

Sessionkey. Dadurch wird die Integrität und Authentizität beim Laden und

bei der Personalisierung des Cardlets mit dem öffentlichen Root-CA-

[10]




Schlüssel der VDV-PKI und dem privaten Konfigurator-Schlüssel

abgedeckt.

Mit Hilfe des mit dem GP Secure Messaging aufgebrachten Konfigurator-Schlüssel wird sich das Cardlet authentisiert und ein Sessionkey vereinbart, auf dessen Basis dann die Integrität und Authentizität der Nachrichten zur Erzeugung des Schlüsselpaares im SE sowie zur

Ausstellung und Einbringung des Zertifikats gesichert werden.

Die im Rahmen der Zertifizierung gestellten Anforderungen an der

Beschaffenheit des SE gewährleisten die Integrität sämtlicher Daten im SE

während der Nutzung.

[10]

KA

Zertifizierung

5 In den Whitelisten für eTicket-Teilnehmer müssen zusätzlich zu Org.-ID,

Organisationsnamen und Organisationsrolle (z.B. KVP), auch die

Identifikationen aller Software-Komponenten angegeben werden, die der

Teilnehmer über das System anfordern darf.

§7.2.4.2, Nr.2

Tabelle 12: Maßnahmen im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“

7.2.4.4. Betrachtung von Maßnahmen im Anwendungsfall „Sperren/Entsperren des VDV KA NM“


Sperren/Entsperren des VDV KA NM

1 Abgedeckt durch die Maßnahmen in §7.2.4.2, Nr.2. §7.2.4.2,

Nr.2

2, 3

Abgedeckt durch die Maßnahmen in §7.2.4.3, Nr.3/4. §7.2.4.3,

Nr.3/4.

4 Abgedeckt durch die Maßnahmen in §7.2.4.2, Nr.2. §7.2.4.2,

Nr.2

Tabelle 13: Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“



8. Schnittstellen

Dieses Kapitel behandelt die Schnittstellen zwischen den beteiligten Systemen. Es werden die Schnittstellen zwischen KVPS, dem OTA-Provisioning-Hintergrundsystem sowie der Sicherheitsinfrastruktur des Applikationsherausgebers betrachtet.

cmp Schnittstellen des OTA Prov isioning Systems

OTA Provisioning Gesamtsystem

Zertifikatsschnittstelle

NmApp Config


AH Trustcenter


Auftragsschnittstelle

Softwareuploadschnittstelle

KVP System

AuftragsschnittstelleAuftragsresultatschnittstelle

Softwareuploadschnittstelle

TSM

Handset

Positivl isten SE

AH System

Positivl isten SE

Auftragsresultatschnittstelle

KA Supplymanagement

Auftragsschnittstelle Auftragsresultatschnittstelle

Software Uploadschnittstelle

Positivl isten SE

fordert Kommandos an

Abbildung 18: Schnittstellen zu beteiligten Systemen

Der Vollständigkeit halber werden in der Abbildung auch interne Schnittstellen gezeigt, ausgeprägt und erläutert werden jedoch nur

die Auftragsschnittstelle vom KVPS zum OTA-Provisioning-System über die die in Abschnitt 6 beschriebenen OTA-Prozesse initiiert werden (erläutert in Abschnitt 8.3).

die Software Upload Schnittstelle, über die Software und Handset Positivlisten an das OTA-Provisioning-System übergeben werden (ebenfalls erläutert in Abschnitt 8.3),

und

die Zertifikatsschnittstelle, mit deren Hilfe vom Trustcenter des



Applikationsherausgebers (AH-Trustcenter) Zertifikate Cert-PuK-NM für die öffentlichen Schlüssel der zu konfigurierenden Medien abgefragt werden.

Neben diesen Schnittstellen gibt es noch eine Schnittstelle zum AH-System, über die der AH dem System Positivlisten mit unterstützen Secure-Elements zur Verfügung stellt. Die Schnittstelle kann als einfacher File Upload (z.B. realisiert als (S)FTP) angesehen werden und wird nicht weiter erläutert.

Zu der internen Schnittstelle zwischen dem OTA-Provisioning-System und dem NFC-Handset sowie den Schnittstellen zwischen den Mobiltelefonkomponenten enthält dieses Kapitel lediglich allgemeine Anmerkungen.

8.1. Schnittstellen zwischen Mobiltelefon-Komponenten Die Schnittstellen zwischen Mobiltelefon-Komponenten werden im Rahmen der vorliegenden Spezifikation nicht weiter detailliert. Es obliegt vielmehr den Secure-Element-TSM, geeignete vorhandene Standards für die Kommunikation mit den entfernten NFC-Handsets und den dort enthaltenen (bzw. verbundenen) Secure-Element zu nutzen.

Darüber hinaus gilt für die in diesem Dokument im Hinblick auf das Secure Element beschriebene Funktionalität und Kommunikationsstrukturen, dass diese im Rahmen der GlobalPlatform v2.2 beschrieben und dort ausreichend spezifiziert sind. Für den Fall einer Applikationskarte auf Basis des JavaCard Standards existiert zusätzlich die ergänzende Java Card API v2.2 der GlobalPlatform.

Im Rahmen der Konfiguration des KA Mediums existiert die Notwendigkeit, durch den KA-NMApp_Konfigurator ISO 7816 basierte Chipkartekommandos an das Medium zu senden. Hierzu können Mechanismen der GlobalPlatform genutzt werden, wobei auch hier der Einsatz anderer Schnittstellen und Verfahren möglich ist. Beispielsweise bietet sich bei der Realisierung der Kommunikationsschicht in Java das im JSR 177 beschriebene SATSA Paket als abstraktere Alternative an.

Die zuletzt genannte Notwendigkeit existiert analog für den Schritt der KA Personalisierung, der vom KA Personalisierer an das OTA-Provisioning-System delegiert werden kann.

8.2. Schnittstelle zwischen OTA-Provisioning-System und NFC-Handset

Sowohl GlobalPlatform als auch VDV KA sehen eine Sicherung der Kommunikation auf Applikationsebene vor, so dass die Integrität der Nachrichten in jedem Fall gewährleistet ist. Da der Datenfluss über die OTA Schnittstelle grundsätzlich mitgehört werden kann, wird dennoch empfohlen die Kommunikation auch auf Protokollebene abzusichern und einen gesicherten Kanal zu verwenden, wie dies beispielsweise durch HTTPS oder SSH gewährleistet wird.

8.3. Schnittstelle zwischen KVPS und OTA-Provisioning-System Über die Auftragsschnittstelle zwischen KVPS und OTA-Provisioning-System werden die in Kapitel 6. beschriebenen Prozesse aktiviert. „Best Practice“ für derartige Schnittstellen stellen SOAP Webservices via http(s) dar, es wird in diesem Dokument jedoch keine konkrete Realisierungsvariante der Schnittstelle gefordert. Vielmehr wird Herstellern hier die Wahlfreiheit gelassen.



Die Kommunikation erfolgt grundsätzlich asynchron nach dem Muster:

Auftragsschnittstelle KVPS OTA-Provisioning-System : Auftrag

… zeitlicher Verzug aufgrund von Prozesszeit oder Wiederholversuchen

OTA- Provisioning –System Auftragsresultatschnittstelle KVPS: Auftragsresultat

Über die maximale Zeitdauer die zwischen Beauftragung und Resultat liegen kann, sowie der Anzahl der ggf. innerhalb dieser Zeitspanne vorzunehmenden Wiederholversuche verständigen sich KVP und OTA-Provisioning-Manager im Vorfeld.

In der folgenden Tabelle sind die zwingend erforderlichen Operationen und Parameter mit ihren Bezeichnungen, ihrer Semantik und ihren Wertebereichen festgehalten. Diese Parameter sind verbindlich und bilden eine Basis für die grundsätzliche Austauschbarkeit der Systeme.

In der Tabelle werden die Parameter differenziert nach den in Kapitel 6 beschriebenen OTA-Prozessen dargestellt. Hierbei ist es unerheblich, ob die Prozesse als Operationen der Schnittstelle oder als Auftragstypen eines generischen Auftrags modelliert werden.



Prü

fen

de

r

Vo

rau

ss

etz

un

ge

n (

6.2

.1)

Üb

erg

ab

e

KA

-NM

-

Ha

nd

se

tse

rvic

es

un

d d

er

Po

sit

ivlis

te H

S (

6.2

.2 u

nd

0)

La

de

n d

er

KA

.NM

-

Ha

nd

se

tse

rvic

es

(6.2

.4)

Lö

sc

hen

de

r K

A.N

M-

Ha

nd

se

tse

rvic

es

(6.2

.5)

Sp

err

en

/En

tsp

err

en

(6

.2.6

) d

er

KA

-NM

-

Ha

ds

ets

erv

ices

Up

da

te d

er

KA

.NM

-

Ha

nd

se

tse

rvic

es

(6

.2.7

)

Organisation_ID X

X

X

X

X

X

MSISDN X X

X

X

X

appInstanz_ID X X

X

X

X

Gültigkeit Start NM X X

Gültigkeit Ende NM X X

Software ID X

Spez. Flags

Art der Software/Artefakt X

Sperren oder Entsperren X

Auszuführende Schritte X X

TXAAUFBER X X

Die Operation Übergabe der KA-NM-Handsetservices / Handset Positivliste ist an der Schnittstelle zur Übergabe der Software vorgesehen, alle anderen Operationen an der Schnittstelle Auftragsschnittstelle.

Die Bedeutung der Felder und deren Definition zeigt die folgende Tabelle.



Parameter Bedeutung Datentyp

Definition / Quelle

appInstanz_ID Instanz ID der auszu-gebenen, zu löschenden oder zu sperrenden Applikation

INT4 Basis Objekt Modell VDV KA

Art der Software / des Artefakt

Art der Einlieferung, dieser bestimmt den Speicherort und die weitere Verwendung im System.

CHAR1 ‘1‘ Ausführbare Datei der KA-NMApp (Cardlet)

‘2‘ Discoverymanager Konfiguration

‘3‘ KVP-HandsetApp

‘4‘ Positivliste für NFC- Handset-Modelle

‘5‘ Secure Element Prioritätenliste.

Auszuführende Schritte

Schalter der den Ablauf des Geschäftsprozesses steuert, dass heißt bis zu welchem Teilprozess das OTA Provisioning durchgeführt werden soll.

CHAR1 ‘L‘ Nur Laden der Applikation

‘C‘ Laden der Applikation und Konfiguration der Applikation

‘P‘ Laden der Applikation, Konfiguration und KA- Personalisierung der Applikation (ggf. mit Ausgabe eines Initialen EFS)

TXAAUFBER

Datensatz vom Typ TXAAUFBER, der die Daten eines initial auszugebenden EFS beinhaltet, der in die KA-NMApp geschrieben werden soll.

TXAAUFBER

Wenn kein EFS geschrieben werden soll, entfällt des Feld oder ist leer.

Das Transaktionsergebnis wird als Nachweis im Typ TXABER rückübergeben.

Im Falle eines Updates wird der Datensatz nur bei der Neuausgabe der KA-NMApp berücksichtigt.

Gültigkeit Start NM

Gewünschtes Startdatum der KA-NMApp

Datum Format MMJJJJ, falls leer heute



Gültigkeit Ende NM

Gewünschtes Enddatum der KA-NMApp

Datum Format MMJJJJ, falls leer wird das Endedatum aus dem Standardablaufdatum des Zertifikates Cert-PuK-NM abgeleitet (siehe [7])

MSISDN Mobilfunknummer des Handsets

CHAR15

ITU-T Recommend E.164

Organisation_ID Eindeutige Organisations ID des KVP

INT2 Basis Objekt Modell der VDV-Kernapplikation

Secure Element Prioritäten Liste

Reihenfolge in der nach SE in/am Handset gesucht wird.

CHAR20

Komma separierte Liste mit Secure Element Typen, z.B. ‘1,2,3‘

Secure Element Typ

Typ des Secure Elements

CHAR1 ‘0‘ = SE auf (U)SIM,

‘1‘=Embedded SE,

‘2‘=SD Karte,

‘3‘=Anderes externes SE

Software ID Eindeutige ID die den Typ und die Version der Software identifiziert.

CHAR20

frei vergebbar

Sperren oder Entsperren

Flag das den Ablauf des Geschäftsprozesses steuert.

CHAR1 ‘S‘ Sperren oder ‘E‘ Entsperren



Hierbei sind die Positiv-Listen einfache CSV Textdatei mit den folgenden Inhalten.

Struktur der Positivliste Handset

Anzahl Inhalt Datentyp Definition / Quelle

Beliebig viele

TAC Code (Type Allocation Type)

CHAR8 3GPP TS 23.003 V9.4.0

Struktur der Positivliste Secure Element

Anzahl Inhalt Datentyp Definition / Quelle

Beliebig viele

SE Identifier Siehe 7.4.1 von GP

cardspec 2.2 [ref.1} oder

card recognition data

Das OTA Provisioning System gibt abhängig vom OTA Prozess die in der folgenden Tabelle aufgeführten Rückgaben zurück.



Erfolgsfall Fehlerfall

Prüfen der Voraussetzungen (6.2.1)

OK Handset nicht erreichbar

Handset nicht auf Positiv-Liste

SE nicht auf Positiv-Liste

Sonstiger Fehler

Übergabe Software (6.2.2 und 0)

OK Ungültiges Format/Daten

Schon im System vorhanden

Laden (6.2.4) OK, Cert-PuK-NM der geladenen Applikation, falls diese in dieser Operation konfiguriert wurde

KA-NMApp Laden nicht möglich

appInstanz_ID bereits vergeben

Konfiguration gescheitert

KA Personalisierung gescheitert

Sonstiger Fehler

Löschen (6.2.5) OK, erfolgreich Kein KA-Medium gefunden

appInstanz_ID stimmt nicht überein.

Löschen gescheitert, weil weitere Cardlets existieren.

Löschen gescheitert, sonstiger Fehler

Sperren (6.2.6) OK, erfolgreich Kein KA-Medium gefunden

appInstanz_ID stimmt nicht überein.

Sperrung/Entsperrung gescheitert, sonstiger Fehler

Update der KA Handset Services (6.2.7)

OK, erfolgreich Cert-PuK-NM der geladenen Applikation, falls diese in dieser Operation konfiguriert wurde,

KA-NMApp Laden gescheitert

appInstanz_ID bereits vergeben

Konfiguration gescheitert

KA Personalisierung gescheitert

Sonstiger Fehler

In Analogie zur Lieferlisten Festlegung für Chipkartenhersteller muss das OTA-Provisioning-System im Fall einer erfolgreichen Initialisierung des KA-Mediums das Zertifikat des Cert-PuK-NM an das KVPS zurück liefern. Obwohl die Kommunikation des Auftragsresultat asynchron erfolgt, sollte dies zeitnah passieren (< 19 Minuten), da es möglicherweise bereits



nach der Medienauslieferung zu einer KA-Personalisierung durch das KVPS kommen soll (oder zu einer anderen OTA KA-Transaktion, z.B. einer EFS-Verkauf). Hierfür muss das Medium bereits im KVPS inventarisiert sein. Aus dem Zertifikat entnimmt das KVP System.

Gültigkeitsende der KA-NMApp

Gültigkeitsende der KA-NMApp

appInstanz_ID (zur Prüfung gegenüber dem beauftragten Wert)

8.4. Schnittstellen zum Sicherheitsmanagement-Dienstleister der VDV-KA KG

Das OTA-Provisioning-System besitzt eine Online-Schnittstelle zum Sicherheits-management-Dienstleister der VDV-KA KG (siehe Abbildung 18, Zertifikatsabruf Schnittstelle). Über die Schnittstelle werden die Nutzermediums-Zertifikate Cert-PuK-NM der VDV-PKI vom Trustcenter des Applikationsherausgeber abgefragt. Die Schnittstelle ist im Dokument Schnittstellenbeschreibung für die Zertifikatsbeantragung [7] ausführlich beschrieben und verfügt über die Operationen.

requestCertificate

revokeCertificate

Mit requestCertificate wird für eine bekannte appInstanz_id bei gekanntem

Gültigkeitszeitraum das Zertifikat für den öffentlichen Schlüssel der KA-NMApp abgefragt. Dies erfolgt im Ablauf des NM-Config Teilprozesses.

Mit revokeCertificate wird beim Löschen der KA-NMApp oder im Fehlerfall des NM-

Config Prozesses ein bereits beantragtes Zertifikat zurückgenommen. An den Lifecycle der Zertifikate sind die Applikations-Lizenzgebühren des AH gekoppelt.



9. Anhang

9.1. Ergänzungen der vorhanden KA-Spezifikationen Einleitung (Siehe [10])

9.2. Übersicht über die TSM-Deploymentmodelle und deren Sicherheits- und Vertragsanforderungen

In dem Whitepaper der GlobalPlatform [GP_NFC] werden die der Deploymentmodelle Simple, Delegated und Dual beschrieben sowie deren Auswirkung auf das Applikation-Management unter Berücksichtigung der SE-Ausprägungen.

Unabhängig vom den unten erläuterten Deploymentmodell kann der SE_Owner immer Secure Domain Bereiche im Secure-Element anlegen und löschen. Dies ist eine Teilmenge des SD-Managements11. Kann der SE_Owner zusätzlich Zugriffe innerhalb der Secure Domain ändern, dann hat er Vollzugriff auf die Secure Domain.

Simple Mode

SE Owner

SE-

TSM

durchführung

anfrage fertig

Delegated Mode

SE Owner

SE-

TSM

fertigErlaubt?

Dual Mode

SE

Owner

SE-

TSM

Durchführung

ja

durchführung

Durchführung

Simple Mode: Hier führt die Rolle SE_Owner das SD-Management sowie das Applikations-Management12 durch. Ein SE_TSM-System beauftragt in diesem Deploymentmodell also den SE_Owner mit dem Applikations-Management. Auch das SD-Management ist in der Hoheit des SE_Owner. Resultate werden an das SE_TSM-System zurückgegeben.

Delegated Mode: Das SE_TSM-System wird mit einer Pre-Authorisierung durch den SE_Owner authorisiert um das Applikations-Management durchzuführen. Das SD-Management kann entweder durch SE_Owner und/oder SE_TSM durchgeführt werden. Damit wird das Applikations-Management an das SE_TSM-System delegiert. Jede

11 SD-Management: Anlegen und Löschen einer SD, Zugriffsberechtigungen auf SD ändern.

12 Applikationsmanagement: Applikationen in SD einbringen oder entfernen.



Durchführung von Applikations-Management muss durch den SE_Owner autorisiert werden. Resultate werden an SE_TSM-System zurück gegeben.

Dual Mode: Der SE_Owner aber auch der SE_TSM sind autorisiert, das Applikations-Management durchzuführen. Das Applikations-Management für den als Secure Domain benannten Teilbereich des Secure Elements ist völlig im SE_TSM-System integriert.

SE auf UICC13 Embedded SE14 External SE (sticker, SD card)15

Simple Höchste Sicherheits- und Vertragsanforderungen, weil der SE_Owner das komplette Applikations-Management durchführt.

Höchste Sicherheits- und Vertragsanforderungen, weil der SE_Owner das komplette Applikations-Management macht.

Normale Sicherheits- und Vertragsanforderungen, weil der SE_Owner (=VDV-KA) die Autorisierung macht und der SE_TSM die Durchführung.

Delegated Normale Sicherheits- und Vertragsanforderungen, weil der SE_Owner die Autorisierung macht und das SE_TSM-System die Durchführung übernimmt.

Normale Sicherheits- und Vertragsanforderungen, weil der SE_Owner die Autorisierung macht und das SE_TSM-System die Durchführung übernimmt.

-

Dual Höchste Sicherheits- und Vertragsanforderungen, weil eine SD benutzt wird, die durch den SE_Owner angelegt und gelöscht werden kann.

Höchste Sicherheits- und Vertragsanforderungen, weil eine SD genutzt wird, die durch den SE_Owner angelegt und gelöscht werden kann.

-

9.3. Exemplarische Realisierung des KA Handset Services Ladens mit Hilfe eines dedizierten TSM-Connectors

In diesem Dokument wird davon ausgegangen, dass der TSM über geeignete Verfahren zur Installation und Initialisierung der KA-NMApp verfügt. Ob die konkrete Realisierung dieser Funktionalität durch Teile der Handset-Firmware oder durch zu installierende Software Komponenten erbracht wird, ist offen gelassen worden.

Dieser Anhang zeigt beispielhaft die Realisierung der TS_Funktionalität durch eine

13 MNO ist SE-Owner

14 Handy Hersteller ist SE-Owner

15 VDV ist SE-Owner



eigenständige Software Komponente, genannt TSM-Connector. Der TSM-Connector hat die Aufgabe, Befehle des TSM-Zentralsystems zu empfangen und auf dem NFC-Handset zur Ausführung zu bringen, der TSM-Connector kann beispielsweise als MIDlet mit Hilfe der Java Microedition Plattform implementiert wird. Installiert wird das TSM-Connector MIDlet via SMS sowie Mechanismen des mobilen Internets, die den Eingriff des Nutzers in den Prozess erforderlich machen. Ein weiteres Merkmal der TSM-Connector Lösung ist die Authentifizierung des Kunden durch eine in einer SMS enthaltenden PassCode, dadurch ist die Verwendung einer nicht beglaubigten Verbindung zum Laden des TSM-Connectors möglich.

sd TSM-Connector laden

TSM-Connector

Delivery System

Kunde mit Trägermedium

(from Akteure)

Handset

SMS mit passcode und erklarung fuer Kunde()

Zugang zu Midlet-Download (URL)

übermitteln

Akzeptiere midlet

installation?()

Akzeptieren()

Midlet installation

akzeptiert()

midlet request()

midlet

download()

midlet herunter geladen, starten?()

Ok()

Starte

midlet()Passcode

abfragen()

Passcode

eingabe()

Passcode()

Passcode()

Pruefe

passcode()

Kunde authoriziert()

Midlet

aktiviert()Midlet

bereitgestellt()

Abbildung 19: Laden des TSM-Connector MIDlets



In dem in Abbildung 19: Laden des TSM-Connector MIDlets gezeigten Sequenzdiagram ist das Laden eines TSM-Connector MIDlets abgebildet. Damit das TSM-Zentralsystem prüfen kann, ob die Download-Anfrage des MIDlets wirklich vom Kunden stammt, der das KVPS beauftragt hat, wird zunächst eine SMS mit einem PassCode an die MSISDN des NFC-Handsets geschickt.

Dieser PassCode muss dann vom Kunden nach dem Herunterladen und vor der Installation und dem Starten des MIDlets eingegeben werden. Damit wird der Kreis, System, Kunde und Handset geschlossen und der TSM-Connector kann frei geschaltet werden.

sd Cardlet laden

KA OTA Provisioning

System

Kunde

(from Rollen)

TSM ConnectorSecure Element

Voraussetzung: Midlet zum Laden eines

Cardlets (TSM-Connector) muss auf dem

Handset vorhanden sein.

Funktion kann Bestandteil eines KA

Handsetservices sein oder ein unabhängiges

Wallet

Midlet nur notwendig, wenn keine andere

Variante wie z.B. BIP möglich

TSM-Agent kann auch

mit einmaliger

Einwill igung des

Kunden von selbst

ohne Bestätigung des

Kunden gestartet

werden (ist allerdings

Handsetabhängig)

Authentisierung und

Erzeugung eines

sicheren Kanals

ist das SE und noch

nicht der VDV KA

Handsetservice

Bereitschaft mitteilen

Starte Kommunikation vom

midlet()

Starte midlet ok?()

Midlet starten()

OK()

Authentizierung()

authentizierung()

Abfrage SE management

commandset()

Cardlet lade kommandos()

meldungen lade vorgang()

Kommunikations ende()

Abbildung 20: Cardlet Laden Sequenzdiagramm

In dem oben abgebildeten Sequenzdiagramm wird das Laden des KA-NmApp Cardlets erläutert. Bevor die Verbindung zwischen KA-OTA-Provisioning-System und dem Secure-Element im Trägermedium aufgebaut werden kann, muss der TSM-Connector vorhanden sein, oder geladen werden (siehe Abbildung 10: TSM-Connector Laden). Dieser ermöglicht dann die Verbindung zwischen TSM-Funktionalität des Zentralsystems und dem Secure-Element im NFC-Handset. Über die authentisierte Verbindung des TSM-Connectors werden dann die Kommandos zur Einrichtung der KA-SD und zum Laden des Cardlets geschickt.



9.4. Konfigurationsmanagement für KA-NM-Handsetservices Das hier beschriebene Verfahren behandelt die Auflösung von Abhängigkeiten zwischen den verschiedenen Komponenten der KA-NM-Handsetservices und ist somit in der Komponente CM Repository (beschrieben in 5.2) angesiedelt. Es dient der Feststellung von installierbaren Gesamtkonfigurationen und der Bestimmung von verfügbaren Versionen für den Fall der Wiederherstellung fehlender Teilkomponenten.

In der Abbildung 21 ist das Objektmodell des Verfahrens dargestellt. Die zu verteilenden Artefakte des KA-NM-Handsetservices werden als Bundles eingeliefert. Bundles können wieder Bundles enthalten (Komposition), deren Zuordnung geschieht über BundleGroups.

BundleGroups können z.B. KA-NM-Handsetservice, KA-KVP-HandsetApp, KA-NMApp sein. Diese fassen gleichartige Artefakte zusammen, aber auch weitere Unterteilungen wie KA-NMApp_JCOP sowie KA-NMApp_SECCOS sind denkbar. In diesem Fall müsste es dann auch zwei inkludierende KA-NM-Handsetservices geben (Erläuterung weiter unten).

class Bundle Struktur

Bundle

bundleId: int

bundleGroup: int

version: int

selector: int

«enumeration»

Mimetype

text/plain

text/xml

application/zip

Content

BundleGroup:

KA-NM-Handsetservices

NmApp

KV-HandsetApp

Discoverymanager Config

Positvliste zugelassene Handsets

...

Versionsformat:

Major/Minor/Patch

Selector:

attrib1=ModelABC and attrib2=UICC

(Bsp.)

1

content 1

1

mimetype1

0..*

{maxversion <=,

minversion >=}

required

0..*

{maxversion <=,

minversion >=}

optional

Abbildung 21

.

Jedes Bundle besteht aus einem ZIP-Archiv, das ZIP Archiv enthält die Datei MANIFEST.MF, sowie (optional) Nutzdaten eines Artefakts. Die Datei MANIFEST.MF ist eine einfache Textdatei, transportiert die im Modell dargestellten Metainformationen und hat beispielsweise die folgende Struktur:

Bundle-Id: de.otasystem.handsetservices.j2me



Bundle-Group: de.otasystem.handsetservices

Bundle-Description: KVP-Handsetservices für J2ME Handsets mit JSR 177

Bundle-Version: 1.0.0

Bundle-Selector: OS=javame,

Import-Required-Group-1: de.otasystem.handsetservices.nmapp;minversion="1.2.0"

Import-Required-Group-2: de.kvp.handsetservices.kvpapp;minversion="1.0.0"

Import-Group-3: de.otasystem.handsetservices.tsrconnector.j2me;minversion="1.0.0"

Der Bundle-Selector ist eine einfache Zuweisung von Werten zu Attributnamen, die in einer logischen Bedingung auf Übereinstimmung abgefragt werden können. In obigem Beispiel würde eine Auswertung für J2ME-Handsets zu einem Resultat führen, während bei Handsets ohne J2ME das Bundle keine Anwendung finden würde.

Der Algorithmus zur Auflösung funktioniert folgendermaßen:

Erstinstallation (Laden)

Das OTA-System fragt die aktuelle Gruppe der KA-NM-Handsetservices

de.otasystem.handsetservices an. Zunächst wird das Bundle der entsprechenden

Gruppe mit der höchsten Versionsnummer, auf den der Bundle-Selector passt, bestimmt. Im oben skizzierten Fall handelt es sich um ein zusammengesetztes Bundle ohne eigene Nutzdaten.

Da es sich um ein zusammengesetztes Bundle mit aufzulösenden Referenzen handelt, werden die refernzierten Importe im Repository gesucht. Dabei wird wieder die Vorgabe gemacht, dass die Bundles zur gesuchten Gruppe gehören, die höchsten Versionsnummer des zulässigen Bereichs (>= minversion und <= maxversion) besitzen und den Bundle-Selector erfüllen. Import-Groups ohne das Schlüsselwort Required müssen dabei nicht zwingend auflösbar sein.

Wenn alle erforderlichen Referenzen aufgelöst sind, ist der Prozess beendet und die gefundenen Artefakte werden an den übergeordneten Prozess zur weiteren Verarbeitung gemeldet.

Wiederherstellung (Update)

Im Fall einer Wiederherstellung der KA-NM-Handsetservices gehen bereits installierte (und daher beizubehaltende) Artefakte als zusätzliche Filterbedingung in den oben beschriebenen Auflauf ein. Für den Fall, dass beispielsweise eine KA-NmApp in Version 1.0.0 vorliegt, werden nur Bundles berücksichtigt, die diese Version importieren können.



9.5. Literaturverzeichnis

Standard/Spezifikation Beschreibung Referenz

Card Specification Version 2.2 March 2006

GlobalPlatform Card Specification 2.2 1

Java Card™ Off-Card Bytecode Verifier

Java Card™ Off-Card Verifier, White Paper, Sun Microsystems, v1.0, June 2002

2

091125 - AFSCM TECH - LIVBL - Interface Specification - V1.2.doc

INTERFACE SPECIFICATION Between Telecom Operators and NFC Service Providers

3

Doc: EPC 220-08, Version 2.0 October 2010

EPC – GSMA Mobile Contactless Payments Service Management Roles Requirements and Specifications

4

Vereinbarung VDV KA KG NM Hersteller

5

SPEC_PE Beschreibung der Schnittstellen zwischen der Vertriebseinheit (KVP-VE) und der Personalisierungseinheit (KVP-PE) eines KVP-Terminals

6

VDV-PKI Schnittstellenbeschreibung für die Zertifikatsbeantragung, Version 1.3 vom 06.08.08

7

SPEC_AktM Aktionsmanagement - Spezifikation für die Berechtigungsart EFS, Version 1.107

8

GP_NFC GlobalPlatform’s Proposition for NFC Mobile:

Secure Element Management and Messaging., White Paper April 2009

9

SPEC_LUKA_ERW-NM VDV-Kernapplikation

Ergänzung zur NM Spezifikation

10

SPEC_ION VDV-Kernapplikation - Spezifikation des Datenaustausches im interoperablen Netzwerk, V 1.107-1.0.4

11

SPEC_LUKA_NFC VDV-Kernapplikation- Nutzung von NFC-Handsets zum Erwerb von elektronischen Fahrscheinen und zur Teilnahme an CICO-Systemen unter Nutzung von passiver NFC-Verkaufs und –Erfassungsinfrastruktur, V1.0

12

VDV-Kernapplikation€¦ · - TSM-Connector (falls die Funktionalität zur Kommunikation mit einem...

Documents

Transcript of VDV-Kernapplikation€¦ · - TSM-Connector (falls die Funktionalität zur Kommunikation mit einem...