VDV-Kernapplikation - Verkehrsunternehmen

Transcription

LuKA
LuKA / OTA-Provisioning
VDV-Kernapplikation
VDV-Kernapplikation
Spezifikation von Luftschnittstellen in einem VDV-Kernapplikationskonformen interoperablen Mobile Ticketing in Verbindung mit einer
passiven Near Field Communication (NFC) Verkaufs- und
Erfassungsstruktur
Erstellung der notwendigen Spezifikationen für die Umsetzung der VDVKA 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
Seite 1 von 98
März 2011
LuKA
VDV-Kernapplikation
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
17.11.2010
Einarbeitung von Anmerkungen nach
Internal Review
0.7
ATOS/
CUBIC/
ESOL
23.11.2010
Version für externes Review
ATOS/
ATOS/
CUBIC
CUBIC
02.02.2011
02.02.2011 Einarbeitung
Einarbeitungvon
vonAnmerkungen
Anmerkungendes
nach
External
ExternalReviews
Review
VDV KA
KG
18.03.2011
Datum
Prüfung
0.8
1.0
Kap. 7.2 eingefügt, Finalisieren des Dokumentes
Prüfung
Version
Freigabe
Bemerkung
Seite 2 von 98
März 2011
LuKA
VDV-Kernapplikation
Inhaltsverzeichnis
Kurztitel: SPEC_LuKA_OTAPROV
1. Projektinformation
1.1.
Ziel und Umfang
2. Systemkontext
2.1.
Einleitung
2.2.
Systemkontext
3. Akteure (Rollen)
3.1.
Übersicht
3.2.
Externe Rollen
3.2.1.
SE_Owner
3.2.2.
SE_Security_Manager
3.2.3.
Secure Element (SE)_Retailer
3.3.
KA-Rollen
3.3.1.
Applikationsherausgeber (AH)
3.3.2.
KA_Registrar
3.3.3.
KA-Sicherheitsmanager
3.3.4.
KA-Trustcenter
3.3.5.
Applikationsausgeber (KVP_NMApp)
3.3.6.
Applikationsausgeber (KVP_HandsetApp)
3.4.
KA-OTA-Provisioning Rollen
3.4.1.
KA-OTA_Provisioning Manager
3.4.2.
Secure Element Trusted Service Manager (SE_TSM)
3.4.3.
SE_Controlling_Authority
3.4.4.
KA-NMApp_Konfigurator
3.4.5.
KA-NMApp_Personalisierer
3.4.6.
KVP_HandsetApp_Loader
3.5.
Sonstige Rollen
3.5.1.
Mobilfunkanbieter
3.5.2.
Technologielieferanten
3.6.
Hinweise zur Allokation von Rollen
4. Funktionale Systembeschreibung
4.1.
Hauptprozess
4.2.
Unterprozesse und beteiligte Systeme
4.3.
Fachliche Komponenten der KA-NM-Handsetservices
4.4.
Weitere Aspekte
5. Funktionale Architektur
5.1.
KA-OTA-Supplymanagement
5.2.
TSM-Funktionalität
5.3.
KA-Nm-Konfiguration (NM-Config)
5.4.
Software und Konfigurationsmanagement
6. Anwendungsfälle und Fachklassen
6.1.
Fachklassenmodell
6.2.
Anwendungsfälle
6.2.1.
Prüfen der Voraussetzung
6.2.2.
Übergabe von Software
6.2.3.
Übergabe von SD-Positivliste
6.2.4.
Laden des KA Handsetservices
6.2.5.
Löschen der KA-NM-Handsetservices
6.2.6.
Sperren/Entsperren des KANM
Seite 3 von 98
1
10
10
10
10
10
14
14
16
16
16
16
17
17
17
17
18
18
18
18
18
19
19
20
20
20
20
20
21
21
23
23
25
26
28
29
30
30
33
34
35
35
36
38
41
44
46
49
51
März 2011
LuKA
7.
VDV-Kernapplikation
6.2.7.
Update des KA-NM-Handsetservices
53
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 HandsetServices (Cardlet)“
70
7.2.2.4.
NM“
Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA
71
7.2.3.
Bedrohungsanalyse
7.2.3.1.
Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“
7.2.3.2.
Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“
7.2.3.3.
Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM HandsetServices (Cardlet)“
7.2.3.4.
74
75
Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
77
7.2.4.
Maßnahmen
7.2.4.1.
Betrachtung von Maßnahmen im Anwendungsfall „Prüfen der
Voraussetzungen“
7.2.4.2.
72
73
78
78
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
Seite 4 von 98
März 2011
LuKA
VDV-Kernapplikation
dedizierten TSM-Connectors
9.4.
Konfigurationsmanagement für KA-NM-Handsetservices
9.5.
Literaturverzeichnis
Seite 5 von 98
93
96
98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 6 von 98
März 2011
LuKA
VDV-Kernapplikation
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 KASicherheitsmanagements
Seite 7 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 8 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 9 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
Seite 10 von 98
März 2011
LuKA
VDV-Kernapplikation
composite structure Systemkontext OTA Prov isioning System
schließt Vertrag über Nutzung
KA Handsetservices mit
KA Handsetserv ice
Hersteller
(from Rollen)
Kunde
(from Rollen)
erhält KA Handsetservices
(insbes. KA NmApp) von
besitzt
Kundenv ertragspartnersystem
KVPS
erhält Arbeitsaufträge zur Ausführung
OTA Provisioning Services
erhält Positivliste für SEs
Applikationsherausgebersystem
AHS
OTA Prov isioning
System
(from KA OTA Provisioning System)
erhält KA NM
Handsetservices
NFC-Handset
mit SE
beauftragt
erhält Cert-PUK-NM von
erhält KA NmApp von
AH Trustcenter
Chipkarte
Abbildung 1: Systemkontext
1
Seite 11 von 98
März 2011
LuKA
VDV-Kernapplikation
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 KANM-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-NMHandsetservices aufgebracht werden sollen. Bei dem Medium kann es sich um ein NFCfä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-NMHandsetservice abfragt.
Trustcenter
Das Trustcenter ist zuständig für das Sicherheitsmanagement. Es stellt das Zertifikate CertPUK-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.
Seite 12 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
Seite 13 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
Seite 14 von 98
März 2011
LuKA
VDV-Kernapplikation
uc Rollenmodell KA OTA Prov isioning System
KA-OTA_Prov isioning
Manager
KA Handsetservice
ausliefern
KVP Berechtigung
KA NmApp
installieren
«invokes»
«invokes»
KA NmApp
konfigurieren
Nutzungsvertrag
KVP
KVP NmApp
autorosiert
von
«invokes»
Zertifikatabruf
«invokes»
SE_Ow ner
SE_TSM
KA Trustcenter
KA-NmApp_Konfigurator
Security
Domain
autorisiert
von
«invokes»
«invokes»
autorisiert
von
Teilnahmevertrag
SE_Controlling
Authority
KA NmApp
personalisieren
autorisiert
von
KA Handsetservice
Bestellung
«invokes»
PKI
Realisierung
KVP HandsetApp
«invokes»
«invokes»
KA-NmApp_Personalisierer
AH
«invokes»
KA
Ausgabetransaktion
«invokes»
loads
besitzt
NFC-Handset
mit SE
Kunde
Mobilfunkanbieter
SE_Retailer
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.
KA-Handsetserv ice
Hersteller
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).
Seite 15 von 98
März 2011
LuKA
3.2.
VDV-Kernapplikation
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 KundenService. 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-OTAProvisioning 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.
Seite 16 von 98
März 2011
LuKA
3.3.
VDV-Kernapplikation
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
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.
Seite 17 von 98
März 2011
LuKA
3.3.4.
VDV-Kernapplikation
KA-Trustcenter
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 NutzermediumApplikation.
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 KANMApps ü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 KVPHandsetApp 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.
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 KAOTA_Provisioning Managers zu delegieren.
Seite 18 von 98
März 2011
LuKA
VDV-Kernapplikation
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-NMHandsetservices 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 KANMApp 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.
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
auszufüllen.
In
anderen
Szenarien
wird
die
SE_Controlling_Authority de facto vom SE_Owner bestimmt.
Seite 19 von 98
März 2011
LuKA
3.4.4.
VDV-Kernapplikation
Der KA-NMApp_Konfigurator konfiguriert im Auftrag des Applikationsausgebers (KVPNMAPP) - 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 KASicherheitssystems, d.h. die Erzeugung des Public/Private Key der KA-NMApplikationsinstanz und dessen Beglaubigung durch ein Zertifikat. Der KANMApp_Konfigurator betreibt dazu eine KA Sub-RA und tauscht Daten mit dem KATrustcenter aus.
Die Prozesse und technischen Einrichtungen des KA-NMApp_Konfigurators werden durch
den KA-Sicherheitsmanager validiert.
3.4.5.
Der KA-NMApp_Personalisierer personalisiert im Auftrag des Applikationsausgebers (KVPNMAPP) 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.
Der KVP_HandsetApp_Loader sorgt im Auftrag der Subrolle KVP_HandsetApp des
Applikationsausgebers für den Download und die Installation der KA-HandsetApp (MenschMaschine-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
Mobilfunkleistungen.
schließt
mit
Nutzern
Verträge
über
die
Nutzung
von
Der Mobilfunkanbieter kann gleichzeitig auch SE_Owner sein (wenn das SE in Form der
(U)SIM-Karte vorliegt), siehe SE_Owner.
Seite 20 von 98
März 2011
LuKA
3.5.2.
VDV-Kernapplikation
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.
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.
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.
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.
Seite 21 von 98
März 2011
LuKA
VDV-Kernapplikation
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 KAHandsetApp_Loader ist stark technisch geprägt, so dass die KVP-übergreifende Nutzung
einer entsprechenden Plattform realistisch erscheint.
Seite 22 von 98
März 2011
LuKA
VDV-Kernapplikation
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 KANM-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 RegistrarSysteme 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-
Seite 23 von 98
März 2011
LuKA

VDV-Kernapplikation
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-ProvisioningSystem 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-ProvisioningSystem. 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-ProvisioningSystem 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 OTAProvisioning-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 KANMApp, die auf Applikationsebene stattfindet.
Seite 24 von 98
März 2011
LuKA
4.2.
VDV-Kernapplikation
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 OTAProvisioning 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 OTAProvisioning-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.
Seite 25 von 98
März 2011
LuKA
4.3.
VDV-Kernapplikation
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.
Seite 26 von 98
März 2011
LuKA
VDV-Kernapplikation
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 OTAProzesse 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 KVPHandsetApp 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 KASchnittstelle 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 KVPHandsetApp 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.
Seite 27 von 98
März 2011
LuKA
TSM-Connector
4.4.
VDV-Kernapplikation
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.
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.
Seite 28 von 98
März 2011
LuKA
VDV-Kernapplikation
5. Funktionale Architektur
Grundlegendes Merkmal der Architektur des OTA-Provisioning-Systems ist die Trennung in
ein zentrales Hintergrundsystem und eine Kommunikationsschicht auf dem NFCMobiltelefon. 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 SecureElements (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-SecurityDomain 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)
Diese Bereiche werden in den folgenden Abschnitten beschrieben.
7
Oder durch eine andere eindeutiges Adressierungsverfahren.
Seite 29 von 98
März 2011
LuKA
5.1.
VDV-Kernapplikation
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
KVP OTA
Auftragsschnittstelle
KVP OTA
Ergebnisschnittstelle
KP, Diskussion: Asynchrone
Bereitstellung von Ergebnissen,
z.B. auf Grunde von
Wiederholungen.
KA Supplymanagement
Process Engine
System AP200::VDV
KA
Supplymanagement::
Session Tracking &
Short Memory
System AP200::VDV KA
Supplymanagement::
Authentication &
Authorisation
TSM Interface
TSM::TSM
TSM Interface
NM Handset
Service Provider
Schnittstelle
NM
Config
NM Handset
Service Delivery
Schnittstelle
Abbildung 5: Komponente KA-OTA-Supplymanagement
5.2.
TSM-Funktionalität
Abbildung 5 zeigt Zusammenhänge von KA-OTA-Supplymanagement sowie der TSMFunktionalitä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.
Seite 30 von 98
März 2011
LuKA
VDV-Kernapplikation
cmp TSM OTA View
KVP System
beauftragt
«flow»
Zentral System AP200
Handset
KA Supplymanagement
TSM::TSM
«flow»
TSM Funktionalität
(optional)
«install»
(from Handset)
fordert Initialisierungssequenz an
«configures»
fordert NM Handset Services an
Secure Element
NmApp Config
CM Repository
Secure Element::
VDV KA NM
(from Handset)
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 NFCHandsets 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 SecureElement 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 KASecurity-Domain.
8
Auf (U)SIM, embedded SE, SD Karte, externes SE
Seite 31 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
Seite 32 von 98
März 2011
LuKA
5.3.
VDV-Kernapplikation
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
NM Config
Schnittstelle
NmApp Config
System AP200::
NmApp Config::
Loader
System AP200::
NmApp Config::
Configurer
Zertifikatsabruf Schnittstelle
Abbildung 7: Komponente NM Konfigurator
Seite 33 von 98
März 2011
LuKA
5.4.
VDV-Kernapplikation
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
Handset Service Delivery Interface
CM Repository
System AP200::
CM Repository::
Version
Resolution
sucht Software in
sucht Software in
System AP200::
CM Repository::
NmApps
NM Handset Service
Provider Interfacer
System AP200::CM
Repository::KVP-Apps
System AP200::CM
Repository::
Discov eryManager
Konfigs
stellt Software ein
Abbildung 8: Komponente CM Repository
Seite 34 von 98
März 2011
LuKA
VDV-Kernapplikation
6. Anwendungsfälle und Fachklassen
6.1.
Fachklassenmodell
class Fachklassen
Secure Element
Ow ner
1
0..*
Positiv liste SE
-
Typ: SE Typ
SE Owner: SE Owner
bestimmt
NFC-Handset::Secure
Verwendbarkeit
Element
-
NFC-Handset::ISD
1
Identifier: String
Typ: SE Typ
NFC-Handset::SD
1
0..*
Positiv liste Handset
-
liefert
Typ: HandsetTyp
NFC-Handset::VDV
KA NM Container
liefert
KVP
liefert
Prioritätenliste
bestimmt
Verwendbarkeit
1
-
Prorität: int
SE Typ: SE Typ
HandsetTyp: HandsetTyp
1
0..1
0..*
NFC-Handset
NFC-Ticketingserv ice-Kunde
besitzt
1
1..*
-
Typ: HandsetTyp
Version: Number
msisdn: MSISDN
1
Version: Number
1..*
1
1
1
«singleton»
KA NmApp
KA NM Handsetserv ice
1
1
1
0..1
TSM Connector
KVP HandsetApp
installiert
0..1
TSM-Connector ist optional
und die Realisierung vom OS
des Handsets abhängig.
0..1
0..1
Discov eryManager
Discov eryManager
Config
1
1
Enthält Startregel für App
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 KANMApp, KA-KVP-HandsetApp sowie der Discoverymanager Konfiguration.
Die KA-NM-Handsetservices sind voneinander unabhängig, allerdings teilen sich alle KANM-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.
Seite 35 von 98
März 2011
LuKA
VDV-Kernapplikation
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 SecureElementen 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 NFCHandset 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-ProvisioningSystem.

KA-NM-Handsetservice laden: Dieser zentrale Anwendungsfall lädt die KA-NMHandsetservices 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 NFCHandset, 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
Seite 36 von 98
März 2011
LuKA
VDV-Kernapplikation
KVP, die Steuerung des übergeordneten Geschäftsprozess und die Überprüfung von
Vorbedingungen dem KVPS.
uc Systemanw endungsfälle
KA-OTA-Provisioning-System
Prüfen der
Voraussetzung
Übergabe v on
Softw are
KA NM
Handsetserv ices
laden
KVPS
AH Trustcenter
Sperren/Entsperren
des KA NM
Update der KA NM
Handset-Serv ices
Löschen der KA NM
Handset-Serv ices
Übergabe v on
SE-Positiv liste
AHS
Abbildung 10: Anwendungsfälle
Seite 37 von 98
März 2011
LuKA
6.2.1.
VDV-Kernapplikation
act Prüfen der Voraussetzung
Prüfen der Voraussetzung TSM-Connector, SE, NM Cardlet(s)
Prüfen der
Voraussetzungen
- Start
[Kunde hat entsprechendes NFC-Device]
«flow»
KVPS
Prüfen ob KVP die
Berechtigung hat das System
zu nutzen
KVP ist berechtigt ?
[nicht berechtigt]
[berechtigt]
Melde KVP:
kein
Berechtigung
Verbindung aufbauen zum
Handset.
[nicht erreichbar]
[erreichbar]
Prüfen ob das Handset
mindestens ein
zugelassenes SE enthält
Handset z Zt.
nicht
erreichbar
Ergebnis der
SE-Prüfung ist
[nicht
zugelassen]
Melde KVP:
Zugriff nicht
zugelassen
[zugelassen]
Melde KVP:
Alles Ok
Fehler
Erfolg
Abbildung 11: Prüfen der Voraussetzung
Seite 38 von 98
März 2011
LuKA
VDV-Kernapplikation
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
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.
Seite 39 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 40 von 98
März 2011
LuKA
6.2.2.
VDV-Kernapplikation
act Activ ity
Übergabe v on Softw are
Software:
1. Cardlet
2. TSM Connector
3. Handy whiteliste
Übergabe
von Software
- start
Prüfen ob KVP
Berechtigung hat über das
System Abfrage zu starten
Prüfe KVP
Übergabeparameter und
Voraussetzungen
Empfang der
Software
Überprüfe empfangene
Softw are
Software OK?
[nein]
[ja]
Neue oder Update Software?
[Update]
[Neu]
«datastore»
Speichere
Softw are
Melde KVP:
Software nicht
gespeichert
«datastore»
Archiv iere alte
v ersion, speichere
neue v ersion
Melde KVP:
Software
gespeichert
Fehler
Melde KVP:
Software wurde
aktualisiert
Erfolg
Abbildung 12: Übergabe von Software
Seite 41 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
Seite 42 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 43 von 98
März 2011
LuKA
6.2.3.
VDV-Kernapplikation
Ü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
Empfang
Positivliste
Überprüfe empfangene
Positiv liste
Positivliste
OK?
[Ja]
[Nein]
«datastore»
Speichere
Positiv liste
Melde AH
Positivliste nicht
gepseichert
Melde AH:
Positivliste
gespeichert
Fehler
Erfolg
Abbildung 13: Übergabe von SE-Positivliste
Seite 44 von 98
März 2011
LuKA
VDV-Kernapplikation
Ü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
Seite 45 von 98
März 2011
LuKA
6.2.4.
VDV-Kernapplikation
act KA NM Handsetserv ice laden
Laden des KA NM Handsetserv ices
Laden KA NM
services- Start
Prüfen ob KVP Berechtigung
hat über das System Abfrage
zu starten
Kunde mit VDV KA NM Service ausstatten
«flow»
KVPS
Prüfe KVP
Voraussetzungen
Daten
ok?
Melde KVP:
Daten nicht OK
:Prüfen ob das Handset
mindestens ein
zugelassenes SE enthält
Melde KVP:
Handy nicht
geeignet
Handy geeignet?
[nein]
Verbindung zum Secure
Element aufbauen
Melde KVP: SE nicht
erreichbar, weitere
Software (wie zB.TSM
Connector) noetig
SE
erreichbar?
[nein]
Prüfen ob KA
(I)SD
v orhanden
ist
Ist SD vorhanden?
[KA SD bereits vorhanden]
[KA SD nicht vorhanden]
NmApp info abfrage v om
SE
KA SD laden
NmApp schon
vorhanden?
SD geladen?
Melde KVP; SD
Laden
gescheitert
[Ja]
[nein]
[ja]
NmApp version OK?
NmApp laden
Melde KVP:
Cardlet Laden
gescheitert
Update NmApp
[Ja]
NmApp geladen?
[nein]
NM Handset App schon
v orhanden?
NM Handset App?
[Vorhanden]
[Nicht vorhanden]
Lade NM Handset App
Melde KVP KA
Handset App
laden
gescheitert
Update KA Handset App
KA Handset
App
geladen?
Update Discov ery
Manager
Melde KVP:
Update Discovery
Manager
gescheitert
Zertifikat
anfragen
Update Discovery Manager OK?
KA NM Konfiguration
Zertifikat
empfangen
KA NM
Handsetservice
geladen?
Melde KVP:
Übertragung
des Secrets
gescheitert
Melde KVP: KA
NM Services
geladen
Fehler
Erfolg
Abbildung 14: Laden des KA Handsetservices
Seite 46 von 98
März 2011
LuKA
VDV-Kernapplikation
Zweck
Laden des KA Handsetservices auf eine Karte oder Over-The-Air in ein NFC-Handset.
Erweitert
Update VDV-KA NM Service
Akteure
KVPS
Kanäle
KVPS-System Verbindung
Mobiles Internet System – NFC Handset
Vorbedingung
Software ist im Repository
Positivliste mit unterstutzten SE liegt vor
Standardablauf
1.
2.
3.
4.
Prüfen ob KVPS berechtigt ist, das Laden zu beauftragen
Prüfung der Voraussetzungen
KA NM Service wird geladen
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 KANMApp 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.
Seite 47 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 48 von 98
März 2011
LuKA
6.2.5.
VDV-Kernapplikation
act Löschen der VDV KA NM Handset-Serv ices
Löschen der VDV KA NM Handset-Serv ices
Löschen der VDV KA NM
Handset-Services - Start
Prüfen ob KVP
Prüfe KVP
Voraussetzungen
:Prüfen der
Voraussetzung
TSM-Connector,
SE, NM Cardlet(s)
Voraussetzungen erfüllt?
[Nicht erfüllt]
[Ja]
Lösche KA NM Cardlet(s)
[fehlgeschlagen]
Löschen erfolgreich?
Melde KVP: Die
Voraussetzungen
sind nicht erfüllt
Melde KVP:
Cardlet(s) wurden
nicht gelöscht
Zertifikat des
Nutzermediums
Cert-PuK-NM
"Revoke"
Melde KVP: KA
NM Services sind
gelöscht
Zertifikat
zurücknehmen
und sperren
Erfolg
Fehler
Abbildung 15: Löschen der KA-NM-Handsetservices
Seite 49 von 98
März 2011
LuKA
VDV-Kernapplikation
Zweck
Das vollständige Löschen eines KA-NM-Handsetservices, inklusive SD, vom SE eines NFC
Handset
Erweitert
Prüfen der Voraussetzung.
Akteure
KVPS
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
Seite 50 von 98
März 2011
LuKA
6.2.6.
VDV-Kernapplikation
Sperren/Entsperren des KANM
act Sperren/Entsperren des VDV KA NM
Sperren/Entsperren der des VDV KA NM
Sperren/Entsperren des VDV KA
NM - Start
Sperren/Entsperren ensprechend der
Mechanismen der GP.
Sperrung des Zugangs zur SD
Prüfen ob KVP
Prüfe KVP
Voraussetzungen
:Prüfen der
Voraussetzung
TSM-Connector,
SE, NM Cardlet(s)
Voraussetzungen
erfüllt?
[Ja]
[Nein]
Sperren oder Entsperren?
Sperren KA NM
Entsperren KA NM
Ausgang Entsperren erfolgreich?
Ausgang Sperren erfolgreich?
[Nein]
[Nein]
[Ja]
[Ja]
Melde KVP:
Voraussetzungen
nicht erfüllt
Melde KVP:
Sperren
gescheitert
Melde KVP: KA
NM gesperrt
Melde KVP:
Entperren
gescheitert
Fehler
Melde KVP: KA
NM ist entsperrt
Erfolg
Abbildung 16: Sperren/Entsperren des KA NM
Seite 51 von 98
März 2011
LuKA
VDV-Kernapplikation
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
KVPS
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.
Seite 52 von 98
März 2011
LuKA
6.2.7.
VDV-Kernapplikation
act Update der VDV KA NM Handset-Serv ices
Update der VDV KA NM Handset-Serv ices
Update der
VDV KA NM
Handset
services start
Prüfen ob KVP
Prüfe KVP
Voraussetzungen
:Prüfen der
Voraussetzung
TSM-Connector,
SE, NM Cardlet(s)
Vorausetzungen
erfüllt?
[nein]
[ja]
Löschen KA NM Serv ices
Gelöscht?
[nein]
[ja]
Melde KVP:
Voraussetzungen
nicht OK
Laden KA NM Serv ices
Melde KVP: KA NM
Cardlet nicht
gelöscht
[nein]
Geladen?
[ja]
Melde KVP: KA NM
cardlet nicht
geladen
Melde KVP: KA NM
Cardlet geladen
Fehler
Ende
Abbildung 17: Update des KA-NM-Handsetservices
Seite 53 von 98
März 2011
LuKA
VDV-Kernapplikation
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
KA NM Service löschen
KA NM Service Laden
Akteure
KVPS
Kanäle
Vorbedingung
Standardablauf
1.
2.
3.
4.
5.
Prüfen ob KVPS berechtigt ist, den Update des KA NM Service zu beauftragen
Prüfen der Vorrausetzungen
VDV-KA NM Service wird gelöscht
VDV-KA NM Service wird geladen
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
Seite 54 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
Seite 55 von 98
März 2011
LuKA
VDV-Kernapplikation
AP210 nr
Beschreibung
Zusammenhang mit
„Prufen der
Vorraussetzung“
Zusammenhang mit
„Übergabe von
Software“
Zusammenhang mit
„Übergabe von SEPositivliste“
Zusammenhang mit
„Laden der
Applikation (auch auf
eine Chipkarte)“
Zusammenhang mit
„Löschen des KA-NMHandsetservices“
Zusammenhang mit
„Sperren/Entsperren
KA-NMHandsetservices“
Zusammenhang mit
„Update des KA-NMHandsetservices“
ANF01
Das Secure Element (SE)
muss die
Sicherheitsanforderunge
n 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 SEPositivliste
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
direkt.-
Wenn die
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 HandsetServices 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
Seite 56 von 98
März 2011
LuKA
VDV-Kernapplikation
ANF04
Es darf keine
Hardwareausprägung
eines SE (SIM-Karte, SDKarte, Bluetooth-Sticker,
embedded Chip, in
Leseweite des NFCHandset 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.
beschrieben können
mehrere Typen und
Umgebungen von TSM
eingebunden werden
TSM aber auch externe,
dies schließt damit keine
HW Ausprägungen aus
aber macht die
komplementär.
beschrieben können
mehrere Typen und
Umgebungen von TSM
eingebunden werden
TSM aber auch
externe, dies schließt
damit keine HW
Ausprägungen aus
aber macht die
komplementär.
beschrieben können
mehrere Typen und
Umgebungen von TSM
eingebunden werden
TSM aber auch
damit keine HW
Ausprägungen aus
aber macht die
komplementär.
beschrieben können
mehrere Typen und
Umgebungen von TSM
eingebunden werden
TSM aber auch
damit keine HW
Ausprägungen aus
aber macht die
komplementär.
beschrieben können
mehrere Typen und
Umgebungen von TSM
eingebunden werden
TSM aber auch
damit keine HW
Ausprägungen aus
aber macht die
komplementär.
beschrieben können
mehrere Typen und
Umgebungen von TSM
eingebunden werden
TSM aber auch
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 VDVKA NM Service und
Initialisierung davon,
danach muss sie noch
Konfiguriert werden.
-
-
Den „Update der
Applikation“
anwendungsfall macht
den ersten Schritt des
aufbringen der VDVKA NM Service,
danach muss sie noch
Konfiguriert werden.
Siehe 6.2.2
Weitere schritt welche
auch ausgeführt wird
ist die sogenannte
Konfiguration des
Discovery Managers.
Siehe 6.2.2
Seite 57 von 98
März 2011
LuKA
ANF08
Sollte für die OTAFunktionalität ein Agent
(MIDlet oder andere
Technologie) benötigt
werden, soll dieser auf
allen NFC-fähigen
Handsets lauffähig sein.
Typ des Handsets sollte
überprüft werden und
demensprechend ein
TSM-Connector
aufgebracht werden.
VDV-Kernapplikation
Generelle und/oder
Handset Spezifische
Software muss im
System geladen und
ausgeliefert werden
können.
Generelle und/oder
Handset Spezifische
Software muss im
System geladen und
ausgeliefert werden
können.
Wen so ein Agent
benötigt wird wird
diese, bevor der VDVKA NM Service
aufgebracht werden
kann, geladen
Siehe 6.2.1
Siehe 6.2.1
Siehe 6.2.1
Siehe 6.2.1
Unterschiede in
Performance und
Funktionsumfang soll es
dabei nicht geben.
Bevor die VDV-KA NM
Service geloescht
werden kann muss die
sogenannte TSMConnector vorhanden
sein oder aufgebracht
werden.
Bevor die VDV-KA NM
Service
gesperrt/entsperrt
werden.
Siehe 6.2.1
Bevor die VDV-KA NM
Service aufgebracht
werden.
Siehe 6.2.1
Siehe 6.2.1
Sind dem Anwender
Inhalte anzuzeigen, so
soll die Anzeige
vollständig und korrekt
sein.
ANF09
ANF14
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.
soll gewährleisten das
verschiedenste Handset
Services geladen werden
können.
Siehe 6.2.1
Siehe 6.2.1
OTA darf nicht
verhindern, dass mit der
Applikation sowohl der
Card-Emulation-Mode
als auch Card-ReaderMode möglich ist.
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
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
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
Den Update des VDVKA NM Service sollte
dies nicht ändern.
Siehe 6.2.1
Siehe 6.2.1
Seite 58 von 98
März 2011
LuKA
VDV-Kernapplikation
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 CardEmulation-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 CardEmulation-Mode im
Battery-Off-Mode und
Battery-On-Mode
bezüglich der
Anwenderinteraktion
gleich verhält.
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
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)
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)
Das Laden der Service
ändert dies nicht.
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
Siehe 6.2.1
Siehe 6.2.1
Siehe 6.2.1
Seite 59 von 98
März 2011
LuKA
VDV-Kernapplikation
ANF25
Die Zeit zum Löschen
sollte maximal der Zeit
zum Aufbringen der
Applikation
entsprechen.
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
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.
Dies wird erreicht durch
Verwendung einer KA
KG zugelassene SD.
Dies wird erreicht
durch Verwendung
einer KA KG
zugelassene SD.
Dies wird erreicht
durch Verwendung
einer KA KG
zugelassene SD.
Dies wird erreicht
durch Verwendung
einer KA KG
zugelassene SD.
Dies wird erreicht
durch Verwendung
einer KA KG
zugelassene SD.
Dies wird erreicht
durch Verwendung
einer KA KG
zugelassene SD.
ANF31
Die Schnittstelle
zwischen KVP und NFCHandset 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 ÖVMIDlet (eines KVP) auf
dem Handy haben.
Siehe 3.3.5
Siehe 3.3.5
Siehe 3.3.5
Siehe 3.3.5
Siehe 3.3.5
Siehe 3.3.5
Siehe 3.3.5
Seite 60 von 98
März 2011
LuKA
ANF39
VDV-Kernapplikation
Die Prozesse, wie sie
zwischen KA
Nutzermediumsherstelle
r und KA vereinbart sind
(siehe
[NUTZERMEDHERERKL]),
müssen in das System
integriert werden.
KVPS stellt zertifikate zur
Verfügung.
KVPS stellt zertifikate zur
Verfügung.
KVPS stellt zertifikate
zur Verfügung.
zur Verfügung.
zur Verfügung.
zur Verfügung.
zur Verfügung.
Alternativ; Service des
Systems, welches dies
direkt anfragt..
direkt anfragt..
direkt anfragt..
direkt anfragt..
direkt anfragt..
direkt anfragt..
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)
Dies ist durch GP
gesichert. (Siehe [Ref.1]
GP 2.2 Cardspec Kapitel
3.1)
Dies ist durch GP
gesichert. (Siehe
[Ref.1] GP 2.2
Cardspec Kapitel 3.1)
Dies ist durch GP
gesichert. (Siehe
[Ref.1] GP 2.2
Dies ist durch GP
gesichert. (Siehe
[Ref.1] GP 2.2
Dies ist durch GP
gesichert. (Siehe
[Ref.1] GP 2.2
Dies ist durch GP
gesichert. (Siehe
[Ref.1] GP 2.2
ANF41
Dem System kann mit
der Administrierung
einzelner oder eine Liste
von bestimmten
Trägermedien
beauftragt werden.
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Seite 61 von 98
März 2011
LuKA
ANF42
Das KVPS übernimmt die
Versionsverwaltung für
die KA NM HandsetServices. 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.
Siehe 6.2.2
VDV-Kernapplikation
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Das System muss vom
KVPS die Komponenten
der KA NM HandsetServices, 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.
Seite 62 von 98
März 2011
LuKA
ANF43
Es sind bei einem Laden
bzw. bei einem Update
nur die Komponenten
des KA NM HandsetServices zu
administrieren, die in
der gewünschten
Version nicht auf der
Zielplattform vorliegen.
Siehe 6.2.2
VDV-Kernapplikation
Siehe 6.2.2
Siehe 6.2.2
Seite 63 von 98
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
Siehe 6.2.2
März 2011
LuKA
7.2.
VDV-Kernapplikation
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.
Seite 64 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Seite 65 von 98
März 2011
LuKA
Sicherheitsziel
Definition
erbracht bzw. eine
durchgeführt wurde)
Anonymität
VDV-Kernapplikation
bestimmte
Funktion
erfolgreich
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 ITSystems, 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ängigkeit 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.
Seite 66 von 98
März 2011
LuKA
7.2.2.1.
VDV-Kernapplikation
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
wesentlich
Der vertrauliche Umgang mit den Handy-Nummern der Nutzer durch KVP
und KA OTA Provisioning-System.
Anonymität
wesentlich
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.
Identifizierung
wesentlich
Aus Sicht des KA OTA Provisioning-Systems muss die Identität eines
anfragenden KVP bestätigt werden können.
Eindeutigkeit
vernachlässigbar
Seite 67 von 98
März 2011
LuKA
VDV-Kernapplikation
Teilprozess: Prüfen der Voraussetzungen
Lückenlosigkeit
Vernachlässigbar
Integrität
Wesentlich
Die Integrität der Informationen aus dem Handset hin zum KA OTA
Provisioning-System bzw. hin zum KVPS.
Authentizität
wesentlich
Die Authentizität der Informationen aus dem Handset hin zum KA OTA
Provisioning-System bzw. hin zum KVPS.
Vernachlässigbar
Autorisierung
wesentlich
Es dürfen nur autorisierte KVPs eine Prüfung der Voraussetzungen für ein
Handset veranlassen.
Zertifizierung
vernachlässigbar
--Bezeugung / Zeitstempel
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.
Sicherheitsziele
Bewertung
Vertraulichkeit
wesentlich
Seite 68 von 98
März 2011
LuKA
VDV-Kernapplikation
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
wesentlich
Sowohl der Lieferant von Software-Komponenten als auch die spezifischen
Komponenten müssen identifizierbar sein.
Eindeutigkeit
Vernachlässigbar
Lückenlosigkeit
Vernachlässigbar
Integrität
Wesentlich
Die Integrität der Informationen während der Übertragung vom Lieferant ins
System.
Authentizität
wesentlich
Die Authentizität der Informationen während der Übertragung vom Lieferant
ins System.
Vernachlässigbar
Autorisierung
wesentlich
Es dürfen nur autorisierte Lieferanten Software-Komponenten ins System
einbringen.
Zertifizierung
vernachlässigbar
--Bezeugung / Zeitstempel
vernachlässigbar
--Verfügbarkeit
vernachlässigbar
--Tabelle 3: Schutzbedarfsanalyse im Anwendungsfall „Übergabe von Software“
Seite 69 von 98
März 2011
LuKA
7.2.2.3.
VDV-Kernapplikation
Schutzbedarfsanalyse im Anwendungsfall „Laden, des VDV KA NM
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.
Sicherheitsziele
Bewertung
Vertraulichkeit
wesentlich
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.
Anonymität
vernachlässigbar
Identifizierung
wesentlich
des KVP sowie des Cardlets.
Eindeutigkeit
Vernachlässigbar
Lückenlosigkeit
Vernachlässigbar
Integrität
Wesentlich
des Cardlets sowie dessen Daten (insbesondere Schlüssel) bei der
Seite 70 von 98
März 2011
LuKA
VDV-Kernapplikation
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
wesentlich
der Datenübertragung zwischen dem System (TSM und Konfigurator) und
dem SE.
vernachlässigbar
Autorisierung
wesentlich
des KVP zum Laden des Cardlets.
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.
Sicherheitsziele
Bewertung
Vertraulichkeit
Vernachlässigbar
Anonymität
vernachlässigbar
Identifizierung
wesentlich
des anfragenden KVP sowie des Cardlets, dessen Verfügbarkeit gesteuert
werden soll.
Eindeutigkeit
Vernachlässigbar
Lückenlosigkeit
Vernachlässigbar
Seite 71 von 98
März 2011
LuKA
VDV-Kernapplikation
Teilprozess: Sperren/Entsperren des VDV KA NM
Integrität
wesentlich
Die Bestätigung der SD, dass sie die angeordnete Zustandsänderung auch
übernommen hat
Authentizität
wesentlich
Die Authentizität der Bestätigung durch die SD, über das Handset, das
OTA-Provisioning-System bis hin zum KVP
Vernachlässigbar
Autorisierung
wesentlich
des KVP zum Sperren/Entsperren des Cardlets bzw. des zu
sperrenden/entsperrenden Cardlets
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.
Seite 72 von 98
März 2011
LuKA
7.2.3.1.
Nr.
VDV-Kernapplikation
Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“
Schutzziel
Bedrohung
Kritikalität bzgl. Risiko
Prüfen der Voraussetzungen
1
Vertraulic
hkeit
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 Einnahmeverlusten führen können. Das
Bekanntwerden von HandyNummern 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 Einnahmeverlusten 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
Identifizier
ung
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.
im Betriebsablauf sowie
schädlichen oder nicht
funktionsfähigen Installationen
kommen.
5
Authentizi
tä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
im Betriebsablauf sowie
Installieren von Applikationen auf
nicht identifizierten Handsets
kommen, was auch zu
Seite 73 von 98
März 2011
LuKA
Nr.
6
Schutzziel
Autorisier
ung
VDV-Kernapplikation
Bedrohung
anderes Handset.
finanziellen Verlusten führen
kann, sofern die betroffenen
Applikationen nicht kostenfrei
sind.
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.
im Betriebsablauf kommen.
Tabelle 6: Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“
7.2.3.2.
Nr.
Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“
Schutzziel
Bedrohung
1
Vertraulic
hkeit
Durch das Ausspähen von SoftwareKomponenten 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 eTicketSystem und der Lieferanten sind
möglich. Daher werden diese
Bedrohungen generell als kritisch
angesehen.
2
Identifizier
ung
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 SoftwareKomponenten.
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
angesehen.
4
Authentizi
tä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
Seite 74 von 98
März 2011
LuKA
Nr.
5
Schutzziel
Autorisier
ung
VDV-Kernapplikation
Bedrohung
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.
Kann ein nicht autorisierter Lieferant am
System normal teilnehmen, so kann er auf
normalem Weg manipulierte SoftwareKomponenten (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.
Nr.
Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM HandsetServices (Cardlet)“
Schutzziel
Bedrohung
„Laden des VDV KA NM Handset-Services (Cardlet)“
1
Vertraulic
hkeit
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
kritisch angesehen.
2
Identifizier
ung
Sind die Software-Komponenten oder die
anfragenden KVPs nicht eindeutig
gezielte Täuschung zur Übergabe und
Installierung der falschen SoftwareKomponenten aus dem Repository des
Systems kommen.
im Betriebsablauf, Image.Schäden sowie finanziellen
Schäden für Lieferanten kommen.
Daher werden diese
angesehen.
Ist das Cardlet nicht eindeutig identifizierbar,
entstehen ähnliche Bedrohungen wie in
§7.2.3.2, Nr.2.
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
Seite 75 von 98
Hohe Schäden sind möglich, da
große Teile des Systems
kompromittiert werden können.
Daher werden diese
angesehen.
März 2011
LuKA
Nr.
Schutzziel
Bedrohung
VDV-Kernapplikation
gemacht. Auch können hierdurch
verschiedene „Fault Injection“ Angriffe
ermöglicht werden, die die Sicherheit des VDV
KA NM stark beinträchtigen.
4
Authentizi
tä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.
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
kritisch angesehen.
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. Berechtigungsschlü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.
5
Autorisier
ung
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.
im Betriebsablauf, ImageSchäden sowie finanziellen
Schäden für Lieferanten kommen.
Daher werden diese
angesehen.
Tabelle 8: Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM HandsetServices (Cardlet)“
Seite 76 von 98
März 2011
LuKA
7.2.3.4.
Nr.
VDV-Kernapplikation
Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA
NM“
Schutzziel
Bedrohung
„Sperren/Entsperren des VDV KA NM “
1
Identifizier
ung
Ist der anfragende KVP nicht eindeutig
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.
Schäden. Daher werden diese
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.
angesehen.
3
Authentizi
tä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.
angesehen.
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
Autorisier
ung
Ohne eine Autorisierungsprüfung könnte ein
KVP die Sperrung/Entsperrung beliebiger
Applikationen verlassen, für das er
normalerweise die Erlaubnis nicht hätte.
angesehen.
Tabelle 9: Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
Seite 77 von 98
März 2011
LuKA
7.2.4.
VDV-Kernapplikation
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.
Nr.
Betrachtung von
Voraussetzungen“
Maßnahmen
im
Anwendungsfall
„Prüfen
Maßnahmen
der
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
Seite 78 von 98
März 2011
LuKA
Nr.
VDV-Kernapplikation
Maßnahmen
Verweis
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
[11]
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.
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
Seite 79 von 98
März 2011
LuKA
Nr.
VDV-Kernapplikation
Maßnahmen
Verweis
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 ProvisioningSystem 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.
Nr.
Betrachtung von Maßnahmen im Anwendungsfall „Übergabe von Software“
Maßnahmen
Verweis
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
KA
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
KA
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
KA
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
KA
Hardware-Kennung des Herstellers sowie den dafür geeigneten Cardlets
enthalten.
Die Identifizierung eines Handsets muss Angaben zur Hardware-Kennung des
Seite 80 von 98
KA
März 2011
LuKA
Nr.
VDV-Kernapplikation
Maßnahmen
Verweis
Herstellers sowie zu geeigneten Software-Komponenten und SE enthalten.
Whitelists müssen mit Angaben

KA
zum Listen-Typ (Listen der Lieferanten, eTicket-Teilnehmer, SoftwareKomponenten, Hardware-Komponenten),

zum Erstellungsdatum der Liste mit ggf. laufender Nummer, um die
Eindeutigkeit zu sichern, sowie

zur Gültigkeit der Liste
ausgestattet werden.
3,
4
Die Integrität und Authentizität der Daten (Software und Whitelists) wird durch
5
Bevor eine Software-Komponente in das Repository aufgenommen wird, prüft das
[11]
eine digitale Signatur geschützt, die vom Absender generiert wird.
-
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.
Nr.
Betrachtung von Maßnahmen im Anwendungsfall „Laden des VDV KA NM
Maßnahmen
Verweis
Laden des VDV KA NM Handset-Services (Cardlet)
1
Die Kommunikation zwischen dem System (TSM) und dem SE verwendet
[10]
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
[10]
erzeugt und ausschließlich im SE gespeichert (nicht auslesbar).
Die im Rahmen der Zertifizierung gestellten Anforderungen an der
KA Zertifizierung
Beschaffenheit des SE gewährleisten die Vertraulichkeit des Cardlet-Code
sowie der geheimen Schlüssel im SE während der Nutzung.
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
[10]
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-
Seite 81 von 98
März 2011
LuKA
Nr.
VDV-Kernapplikation
Maßnahmen
Verweis
Schlüssel der VDV-PKI und dem privaten Konfigurator-Schlüssel
abgedeckt.
Mit Hilfe des mit dem GP Secure Messaging aufgebrachten KonfiguratorSchlü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.
[10]
Die im Rahmen der Zertifizierung gestellten Anforderungen an der
während der Nutzung.
KA
Zertifizierung
In den Whitelisten für eTicket-Teilnehmer müssen zusätzlich zu Org.-ID,
§7.2.4.2, Nr.2
Beschaffenheit des SE gewährleisten die Integrität sämtlicher Daten im SE
5
Organisationsnamen und Organisationsrolle (z.B. KVP), auch die
Identifikationen aller Software-Komponenten angegeben werden, die der
Teilnehmer über das System anfordern darf.
Tabelle 12: Maßnahmen im Anwendungsfall „Laden des VDV KA NM Handset-Services
(Cardlet)“
7.2.4.4.
Nr.
Betrachtung von Maßnahmen im Anwendungsfall „Sperren/Entsperren des
VDV KA NM“
Maßnahmen
Verweis
Sperren/Entsperren des VDV KA NM
1
§7.2.4.2,
Nr.2
2,
3
Abgedeckt durch die Maßnahmen in §7.2.4.3, Nr.3/4.
4
§7.2.4.3,
Nr.3/4.
§7.2.4.2,
Nr.2
Tabelle 13: Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“
Seite 82 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Softwareuploadschnittstelle
KVP System
Auftragsresultatschnittstelle
OTA Provisioning Gesamtsystem
Auftragsresultatschnittstelle
KA Supplymanagement
Software Uploadschnittstelle
Handset
Positivlisten SE
fordert Kommandos an
NmApp Config
TSM
Zertifikatsschnittstelle
Positivlisten SE
AH System
Zertifikatsschnittstelle
AH Trustcenter
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),

die
und
Zertifikatsschnittstelle,
mit
deren
Hilfe
Seite 83 von 98
vom
Trustcenter
des
März 2011
LuKA
VDV-Kernapplikation
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 NFCHandset 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 KANMApp_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
Handset
zwischen
OTA-Provisioning-System
und
NFC-
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.
Seite 84 von 98
März 2011
LuKA
VDV-Kernapplikation
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 OTAProzessen dargestellt. Hierbei ist es unerheblich, ob die Prozesse als Operationen der
Schnittstelle oder als Auftragstypen eines generischen Auftrags modelliert werden.
Seite 85 von 98
März 2011
Update der KA.NMHandsetservices (6.2.7)
X
X
X
X
X
Sperren/Entsperren (6.2.6)
der KA-NMHadsetservices
X
X
X
Löschen der KA.NMHandsetservices
(6.2.5)
X
X
X
X
X
X
Gültigkeit Ende NM
Software ID
X
X
Gültigkeit Start NM
X
appInstanz_ID
X
X
X
MSISDN
X
Organisation_ID
VDV-Kernapplikation
Übergabe KA-NMHandsetservices und der
Positivliste HS (6.2.2 und
0)
Laden der KA.NMHandsetservices
(6.2.4)
Prüfen der
Voraussetzungen (6.2.1)
LuKA
Art der Software/Artefakt
X
Spez. Flags
X
X
X
TXAAUFBER
X
Auszuführende Schritte
X
Sperren oder Entsperren
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.
Seite 86 von 98
März 2011
LuKA
VDV-Kernapplikation
Parameter
Bedeutung
Datent
yp
Definition / Quelle
appInstanz_ID
Instanz ID der auszugebenen, zu
löschenden oder zu
sperrenden
Applikation
INT4
Basis Objekt Modell
VDV KA
CHAR1
‘1‘ Ausführbare Datei der
KA-NMApp (Cardlet)
Art der Software Art der Einlieferung,
/ des Artefakt
dieser bestimmt den
Speicherort und die
weitere Verwendung
im System.
‘2‘ Discoverymanager
Konfiguration
‘3‘ KVP-HandsetApp
‘4‘ Positivliste für NFCHandset-Modelle
‘5‘ Secure Element
Prioritätenliste.
Auszuführende
Schritte
TXAAUFBER
Schalter der den
Ablauf des
Geschäftsprozesses
steuert, dass heißt bis
zu welchem
Teilprozess das OTA
Provisioning
durchgeführt werden
soll.
CHAR1
Datensatz vom Typ
TXAAUFBER, der die
Daten eines initial
auszugebenden EFS
beinhaltet, der in die
KA-NMApp
geschrieben werden
soll.
TXAAU
FBER
‘L‘ Nur Laden der
Applikation
‘C‘ Laden der Applikation
und Konfiguration der
Applikation
‘P‘ Laden der Applikation,
Konfiguration und KAPersonalisierung der
Applikation (ggf. mit
Ausgabe eines Initialen
EFS)
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 KANMApp berücksichtigt.
Gültigkeit Start
NM
Gewünschtes
Startdatum der KANMApp
Datum
Format MMJJJJ, falls leer
heute
Seite 87 von 98
März 2011
LuKA
Gültigkeit Ende
NM
VDV-Kernapplikation
Gewünschtes
Enddatum der KANMApp
Datum
Format MMJJJJ, falls leer
wird das Endedatum aus
dem Standardablaufdatum
des Zertifikates Cert-PuKNM abgeleitet (siehe [7])
Mobilfunknummer des
Handsets
CHAR1
5
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.
CHAR2
0
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,
MSISDN
‘1‘=Embedded SE,
‘2‘=SD Karte,
‘3‘=Anderes externes SE
Software ID
Eindeutige ID die den
Typ und die Version
der Software
identifiziert.
CHAR2
0
frei vergebbar
Sperren oder
Entsperren
Flag das den Ablauf
des
Geschäftsprozesses
steuert.
CHAR1
‘S‘ Sperren oder ‘E‘
Entsperren
Seite 88 von 98
März 2011
LuKA
VDV-Kernapplikation
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
Datentyp
Definition / Quelle
Struktur der Positivliste Secure Element
Anzahl
Inhalt
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.
Seite 89 von 98
März 2011
LuKA
Prüfen der
Voraussetzungen
(6.2.1)
VDV-Kernapplikation
Erfolgsfall
Fehlerfall
OK
Handset nicht erreichbar
Handset nicht auf Positiv-Liste
SE nicht auf Positiv-Liste
Sonstiger Fehler
Übergabe
Software (6.2.2
und 0)
OK
Laden (6.2.4)
OK,
Cert-PuK-NM der
geladenen Applikation,
falls diese in dieser
Operation konfiguriert
wurde
Ungültiges Format/Daten
Schon im System vorhanden
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-ProvisioningSystem im Fall einer erfolgreichen Initialisierung des KA-Mediums das Zertifikat des CertPuK-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
Seite 90 von 98
März 2011
LuKA
VDV-Kernapplikation
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.
8.4.

Gültigkeitsende der KA-NMApp

Gültigkeitsende der KA-NMApp

appInstanz_ID (zur Prüfung gegenüber dem beauftragten Wert)
Schnittstellen zum Sicherheitsmanagement-Dienstleister der VDVKA KG
Das OTA-Provisioning-System besitzt eine Online-Schnittstelle zum Sicherheitsmanagement-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 NMConfig Prozesses ein bereits beantragtes Zertifikat zurückgenommen. An den Lifecycle der
Zertifikate sind die Applikations-Lizenzgebühren des AH gekoppelt.
Seite 91 von 98
März 2011
LuKA
VDV-Kernapplikation
9. Anhang
9.1.
Ergänzungen der vorhanden KA-Spezifikationen Einleitung
(Siehe [10])
9.2.
Übersicht über die TSM-Deploymentmodelle
Sicherheits- und Vertragsanforderungen
und
deren
In dem Whitepaper der GlobalPlatform [GP_NFC] werden die der Deploymentmodelle
Simple, Delegated und Dual beschrieben sowie deren Auswirkung auf das ApplikationManagement 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
Delegated Mode
durchführung
SE Owner
SE Owner
anfrage
fertig
SETSM
SETSM
SE
Owner
Erlaubt?
fertig
Dual Mode
ja
SETSM
Durchführung
Durchführung
durchführung
Simple Mode: Hier führt die Rolle SE_Owner das SD-Management sowie das ApplikationsManagement12 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 SDManagement 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.
Seite 92 von 98
März 2011
LuKA
VDV-Kernapplikation
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 ApplikationsManagement 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
Simple
Höchste
Sicherheitsund
Vertragsanforderungen,
weil der SE_Owner das
komplette ApplikationsManagement
durchführt.
Höchste
Sicherheitsund
weil der SE_Owner das
komplette ApplikationsManagement macht.
Delegated
Normale
Sicherheitsund
weil der SE_Owner die
Autorisierung
macht
und das SE_TSMSystem
die
Durchführung
übernimmt.
Höchste
Sicherheitsund
weil eine SD benutzt
wird, die durch den
SE_Owner
angelegt
und gelöscht werden
kann.
Normale
Sicherheitsund
weil der SE_Owner die
Autorisierung
macht
und das SE_TSMSystem
die
Durchführung
übernimmt.
Höchste
Sicherheits- und
weil eine SD genutzt
wird, die durch den
SE_Owner
angelegt
und gelöscht werden
kann.
Dual
9.3.
External SE (sticker,
SD card)15
Normale Sicherheitsund
weil der SE_Owner
(=VDV-KA)
die
Autorisierung
macht
und der SE_TSM die
Durchführung.
-
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
Seite 93 von 98
März 2011
LuKA
VDV-Kernapplikation
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
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()
(from Akteure)
Abbildung 19: Laden des TSM-Connector MIDlets
Seite 94 von 98
März 2011
LuKA
VDV-Kernapplikation
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 NFCHandsets 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
ist das SE und noch
nicht der VDV KA
Handsetservice
KA OTA Provisioning
System
Secure Element
TSM Connector
Kunde
Starte Kommunikation vom
midlet()
Starte midlet ok?()
Midlet starten()
OK()
Authentizierung()
authentizierung()
Authentisierung und
Erzeugung eines
sicheren Kanals
Abfrage SE management
commandset()
TSM-Agent kann auch
mit einmaliger
Einwilligung des
Kunden von selbst
ohne Bestätigung des
Kunden gestartet
werden (ist allerdings
Handsetabhängig)
Cardlet lade kommandos()
meldungen lade vorgang()
Kommunikations ende()
Bereitschaft mitteilen
(from Rollen)
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
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 SecureElement 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 SecureElement 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.
Seite 95 von 98
März 2011
LuKA
9.4.
VDV-Kernapplikation
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 KANMApp_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
0..*
{maxversion <=,
minversion >=}
optional
{maxversion <=,
minversion >=}
required
0..*
1
BundleGroup:
KA-NM-Handsetservices
NmApp
KV-HandsetApp
Discoverymanager Config
Positvliste zugelassene Handsets
...
Versionsformat:
Major/Minor/Patch
1
Selector:
attrib1=ModelABC and attrib2=UICC
(Bsp.)
content
Content
1
1
mimetype
«enumeration»
Mimetype
text/plain
text/xml
application/zip
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
Seite 96 von 98
März 2011
LuKA
VDV-Kernapplikation
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 BundleSelector 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.
Seite 97 von 98
März 2011
LuKA
9.5.
VDV-Kernapplikation
Literaturverzeichnis
Standard/Spezifikation
Beschreibung
Referenz
Card Specification Version GlobalPlatform Card Specification 2.2
2.2 March 2006
Java
Card™
Bytecode Verifier
1
Off-Card Java Card™ Off-Card Verifier, White Paper, Sun 2
Microsystems, v1.0, June 2002
091125 - AFSCM TECH - INTERFACE SPECIFICATION Between Telecom 3
LIVBL
Interface Operators and NFC Service Providers
Specification - V1.2.doc
Doc: EPC 220-08, Version EPC – GSMA Mobile Contactless Payments 4
2.0 October 2010
Service Management Roles Requirements and
Specifications
Vereinbarung VDV KA KG
NM Hersteller
5
SPEC_PE
Beschreibung der Schnittstellen zwischen der 6
Vertriebseinheit
(KVP-VE)
und
der
Personalisierungseinheit (KVP-PE) eines KVPTerminals
VDV-PKI
Schnittstellenbeschreibung
für
die 7
Zertifikatsbeantragung, Version 1.3 vom 06.08.08
SPEC_AktM
GP_NFC
Aktionsmanagement - Spezifikation für die
Berechtigungsart EFS, Version 1.107
8
GlobalPlatform’s Proposition for NFC Mobile:
9
Secure Element Management and Messaging.,
White Paper April 2009
SPEC_LUKA_ERW-NM
VDV-Kernapplikation
Ergänzung zur NM Spezifikation
SPEC_ION
VDV-Kernapplikation
Spezifikation
des 11
Datenaustausches im interoperablen Netzwerk, V
1.107-1.0.4
SPEC_LUKA_NFC
VDV-KernapplikationNutzung
von
NFC- 12
Handsets zum Erwerb von elektronischen
Fahrscheinen und zur Teilnahme an CICOSystemen unter Nutzung von passiver NFCVerkaufs und –Erfassungsinfrastruktur, V1.0
Seite 98 von 98
10
März 2011

VDV-Kernapplikation - Verkehrsunternehmen

Transcription

Similar documents

Markterkundung In-Out-Vertriebssysteme weltweit

Reinhard Schulte - ÖPNV Innovationskongress

Script zum Video "Jugendschutz" auf

Anhang

TruTops Produkte - TRUMPF Werkzeugmaschinen

Softwarearchitektur verteilter Systeme

TruTops Produkte - TRUMPF Werkzeugmaschinen

White Paper - eTicket Deutschland

Installation des FilterSurf-Redirectors ab v2.14

ticos.master/slave

erfahren - comlineag.de