Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 1 von 98 März 2011
VDV-Kernapplikation
Spezifikation von Luftschnittstellen in einem VDV-Kernapplikations-konformen interoperablen Mobile Ticketing in Verbindung mit einer passiven Near Field Communication (NFC) Verkaufs- und Erfassungsstruktur
Erstellung der notwendigen Spezifikationen für die Umsetzung der VDV-KA auf NFC-fähigen Mobiltelefonen mit Nutzung des Applikationsdownloads über das GSM-/UMTS-Netzwerk der Mobilfunkbetreiber.
Kurztitel: SPEC_LuKA_OTAPROV
Thema: Spezifikationen für die Umsetzung der VDV-KA auf NFC-fähigen Mobiltelefonen mit Nutzung des Applikationsdownloads über das GSM-/UMTS-Netzwerk der Mobilfunkbetreiber.
Dateiname: SPEC_LUKA_OTAPROVSYS_1.0.doc
Erstellt am: 22.03.2010
Zuletzt geändert am: 19.04.2011 09:03:00
Version: 1.0
Ersteller: ATOS ORIGIN/CUBIC/ESOL
Abnahme am: 24.03.11
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 2 von 98 März 2011
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
0.8 ATOS/
CUBIC
02.02.2011 Einarbeitung von Anmerkungen nach
External Review
ATOS/
CUBIC
02.02.2011 Einarbeitung von Anmerkungen des
External Reviews
1.0 VDV KA KG
18.03.2011 Kap. 7.2 eingefügt, Finalisieren des Dokumentes
Prüfung
Version Datum Prüfung Freigabe Bemerkung
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 3 von 98 März 2011
Inhaltsverzeichnis
Kurztitel: SPEC_LuKA_OTAPROV 1 1. Projektinformation 10
1.1. Ziel und Umfang 10 2. Systemkontext 10
2.1. Einleitung 10 2.2. Systemkontext 10
3. Akteure (Rollen) 14 3.1. Übersicht 14 3.2. Externe Rollen 16
3.2.1. SE_Owner 16 3.2.2. SE_Security_Manager 16 3.2.3. Secure Element (SE)_Retailer 16
3.3. KA-Rollen 17 3.3.1. Applikationsherausgeber (AH) 17 3.3.2. KA_Registrar 17 3.3.3. KA-Sicherheitsmanager 17 3.3.4. KA-Trustcenter 18 3.3.5. Applikationsausgeber (KVP_NMApp) 18 3.3.6. Applikationsausgeber (KVP_HandsetApp) 18
3.4. KA-OTA-Provisioning Rollen 18 3.4.1. KA-OTA_Provisioning Manager 18 3.4.2. Secure Element Trusted Service Manager (SE_TSM) 19 3.4.3. SE_Controlling_Authority 19 3.4.4. KA-NMApp_Konfigurator 20 3.4.5. KA-NMApp_Personalisierer 20 3.4.6. KVP_HandsetApp_Loader 20
3.5. Sonstige Rollen 20 3.5.1. Mobilfunkanbieter 20 3.5.2. Technologielieferanten 21
3.6. Hinweise zur Allokation von Rollen 21 4. Funktionale Systembeschreibung 23
4.1. Hauptprozess 23 4.2. Unterprozesse und beteiligte Systeme 25 4.3. Fachliche Komponenten der KA-NM-Handsetservices 26 4.4. Weitere Aspekte 28
5. Funktionale Architektur 29 5.1. KA-OTA-Supplymanagement 30 5.2. TSM-Funktionalität 30 5.3. KA-Nm-Konfiguration (NM-Config) 33 5.4. Software und Konfigurationsmanagement 34
6. Anwendungsfälle und Fachklassen 35 6.1. Fachklassenmodell 35 6.2. Anwendungsfälle 36
6.2.1. Prüfen der Voraussetzung 38 6.2.2. Übergabe von Software 41 6.2.3. Übergabe von SD-Positivliste 44 6.2.4. Laden des KA Handsetservices 46 6.2.5. Löschen der KA-NM-Handsetservices 49 6.2.6. Sperren/Entsperren des KANM 51
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 4 von 98 März 2011
6.2.7. Update des KA-NM-Handsetservices 53 7. Umsetzung der nicht funktionalen Anforderungen 55
7.1. Zusammenhang von Anwendungsfällen zu nicht funktionalen Anforderungen 55 7.2. Sicherheitsbetrachtung 64
7.2.1. Bestandsaufnahme 64 7.2.2. Schutzbedarfsanalyse 64
7.2.2.1. Schutzbedarfsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“ 67
7.2.2.2. Schutzbedarfsanalyse im Anwendungsfall „Übergabe von Software“ 68
7.2.2.3. Schutzbedarfsanalyse im Anwendungsfall „Laden, des VDV KA NM Handset-
Services (Cardlet)“ 70
7.2.2.4. Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA
NM“ 71
7.2.3. Bedrohungsanalyse 72 7.2.3.1. Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“ 73
7.2.3.2. Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“ 74
7.2.3.3. Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-
Services (Cardlet)“ 75
7.2.3.4. Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
77
7.2.4. Maßnahmen 78 7.2.4.1. Betrachtung von Maßnahmen im Anwendungsfall „Prüfen der
Voraussetzungen“ 78
7.2.4.2. Betrachtung von Maßnahmen im Anwendungsfall „Übergabe von Software“ 80
7.2.4.3. Betrachtung von Maßnahmen im Anwendungsfall „Laden des VDV KA NM
Handset-Services (Cardlet)“ 81
Mit Hilfe des mit dem GP Secure Messaging aufgebrachten Konfigurator-Schlüssel wird sich
das Cardlet authentisiert und ein Sessionkey vereinbart, auf dessen Basis dann die Integrität
und Authentizität der Nachrichten zur Erzeugung des Schlüsselpaares im SE sowie zur
Ausstellung und Einbringung des Zertifikats gesichert werden. 82
7.2.4.4. Betrachtung von Maßnahmen im Anwendungsfall „Sperren/Entsperren des
VDV KA NM“ 82
8. Schnittstellen 83 8.1. Schnittstellen zwischen Mobiltelefon-Komponenten 84 8.2. Schnittstelle zwischen OTA-Provisioning-System und NFC-Handset 84 8.3. Schnittstelle zwischen KVPS und OTA-Provisioning-System 84 8.4. Schnittstellen zum Sicherheitsmanagement-Dienstleister der VDV-KA KG 91
9. Anhang 92 9.1. Ergänzungen der vorhanden KA-Spezifikationen Einleitung 92 9.2. Übersicht über die TSM-Deploymentmodelle und deren Sicherheits- und Vertragsanforderungen 92 9.3. Exemplarische Realisierung des KA Handset Services Ladens mit Hilfe eines
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 5 von 98 März 2011
dedizierten TSM-Connectors 93 9.4. Konfigurationsmanagement für KA-NM-Handsetservices 96 9.5. Literaturverzeichnis 98
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 6 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 7 von 98 März 2011
Abkürzungsverzeichnis
AFB automatisierte Fahrberechtigung
AH Applikationsherausgeber
AHS Applikationsherausgebersystem
APP Applikation
APP_ID Applikations-Identifikation
BIP Bearer Independent Protocol
(Sub) CA Certificate Authority
CI Check-in
CICO Check-in/Check-out
CO Check-out
DL Dienstleister
DLT Dienstleisterterminal
DLS Dienstleistersystem
EFM Elektronisches Fahrgeldmanagement
EFS Elektronischer Fahrschein
EP Elementarprozess
ggf. Gegebenenfalls
GP GlobalPlatform
GPRS General Packet Radio Service
GPS Global Positioning Service
GSM Global System for Mobile Communications
HGS Hintergrundsystem
HTTP(S) HyperText Transfer Protocol (Secure)
ID Identifikation
ISD Issuer Security-Domain
i. d. R. in der Regel
i. a. Im Allgemeinen
ION Interoperabilitätsnetzwerk
IP Internet-Protocol
J2ME Java Platform 2, Micro Edition
KA Kernapplikation
KA-NMApp KA-Nutzermediumapplikation der VDV-KA-KG
KOSE Kontrollservice (Sperrlistenservice) als Bestandteil des KA-Sicherheitsmanagements
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 8 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 9 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 10 von 98 März 2011
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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 11 von 98 März 2011
composite structure Systemkontext OTA Prov isioning System
OTA Prov isioning
System
(from KA OTA Provisioning System)
AH Trustcenter
NFC-Handset
mit SE
Kundenv ertragspartnersystem
KVPS
Chipkarte
Kunde
(from Rollen)
KA Handsetserv ice
Hersteller(from Rollen)
Applikationsherausgebersystem
AHS
beauftragt
erhält Positivliste für SEs
erhält KA Handsetservices
(insbes. KA NmApp) von
schließt Vertrag über Nutzung
KA Handsetservices mit
besitzt
erhält KA NmApp von
erhält Arbeitsaufträge zur Ausführung
OTA Provisioning Services
erhält KA NM
Handsetservices
erhält Cert-PUK-NM von
Abbildung 1: Systemkontext1
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 12 von 98 März 2011
Im Folgenden werden die Rollen und externen Systeme sowie deren Interaktion erläutert.
KA-NM-Handsetservice Lieferant
Der KA-NM-Handsetservice Lieferant ist zuständig für die Entwicklung und Lieferung der KA-NM-Handsetservices2 und ggf. zusätzlicher benötigter Komponenten:
- KA-NMApp (Nutzermediums Chipkartenanwendungen; ist erforderlich) - KVP-HandsetApp (Mensch Maschine Interface; ist optional) - Discoverymanager Konfiguration (Metadaten; ist optional)
Gegebenenfalls werden zusätzlich Komponenten geliefert
- TSM-Connector (falls die Funktionalität zur Kommunikation mit einem TSM nicht über die Firmware des Mobilgerätes erbracht wird, siehe Abschnitt 9.3)
- Weitere in die KA-Security-Domain einzubringende Chipkartenanwendungen
Kunde mit Trägermedium
Dies ist der Kunde des KVP. Er ist im Besitz eines Mediums, auf das die KA-NM-Handsetservices aufgebracht werden sollen. Bei dem Medium kann es sich um ein NFC-fähiges Mobiltelefon (allg. Handset) handeln oder eine andere Form von Trägermedium, wie beispielsweise eine Chipkarte.
KVPS
System eines Kundenvertragspartners, das abhängig vom Anwendungsfall
- benötigte Software zur Verfügung stellt oder aktualisiert. - das System beauftragt das OTA-Provisioning-System KA-NM-Handsetservices
aufzubringen, zu aktualisieren oder zu löschen (siehe auch Kapitel 0). - den Status des aufgebrachten oder den Fortgang des aufzubringenden KA-NM-
Handsetservice abfragt.
Trustcenter
Das Trustcenter ist zuständig für das Sicherheitsmanagement. Es stellt das Zertifikate Cert-PUK-NM für die KA-NMApp bereit.
NFC-Handset mit Secure Element als Trägermedium der KA-NMApp
Das NFC-Handset stellt ein nicht zu veränderndes externes System mit vorgegebenen Schnittstellen dar. In das NFC-Handset bzw. in das hierüber administrierte Secure Element (SE) werden KA-NM-Handsetservices eingebracht, insbesondere die KA-NMApp.
2 Die KA-NM-Handsetservices werden ausführlich in Abschnitt 0 geschrieben.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 13 von 98 März 2011
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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 14 von 98 März 2011
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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 15 von 98 März 2011
uc Rollenmodell KA OTA Prov isioning System
Kunde
KA-Handsetserv ice
Hersteller
KA TrustcenterKVP NmApp
KA-OTA_Prov isioning
Manager
SE_TSM KA-NmApp_Konfigurator
KA-NmApp_Personalisierer
AH
SE_Owner
SE_Controlling
Authority
NFC-Handset
mit SE
SE_RetailerMobilfunkanbieter
Rollenmodell OTA Provisioning
LuKA AP230
Die Darstellung ist keine vollständige Modellierung aller Beziehungen
zwischen den Rollen. Sie zeigt vielmehr die wesentlichen Beziehungen
anhand des Hauptanwendungsfalls der Auslieferung eines KA Handservices
(enthält inbes. die KA NmApplikation) auf ein NFC-Handset mit SE.
"Invoke"-Beziehungen zeigen die Beziehungen für die operative Durchführung
der Auslieferung. Diese "Invoke"-Beziehungen sind noch keine Modellierung
der Schnittstellen der technischen Systeme.
"Dependency"-Beziehungen zeigen die Beziehungen zur Schaffung des
organisatorischen Rahmens und der Etablierung der einer vertrauenswürdigen
Umgebung.
KVP HandsetApp
KVP
KVP Berechtigung
KVP_HandsetApp_Loader
autorisiert
von
KA
Ausgabetransaktion
«invokes»
«invokes»
Zertifikatabruf
«invokes»
Security
Domain
«invokes»
autorisiert
von
autorosiert
von
«invokes»
autorisiert
von
KA NmApp
konfigurieren
«invokes»
KA NmApp
personalisieren
«invokes»
Nutzungsvertrag
TeilnahmevertragPKI
Realisierung
KA Handsetservice
Bestellung
«invokes»
besitzt
KA Handsetservice
ausliefern
«invokes»
KA NmApp
install ieren
«invokes»
«invokes»
loads
Abbildung 2: Rollenmodell KA-OTA-Provisioning
In den nachfolgenden Abschnitten werden die Rollen beschrieben, wobei sich die Beschreibung gliedert in
Rollen, die die Welt außerhalb des Gestaltungsbereichs der KA abbilden (externe Rollen);
existierende KA-Rollen, die für das OTA-Provisioning erweitert werden;
Rollen innerhalb des OTA-Provisioning-Systems;
sonstige Rollen (erweiterter Kontext).
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 16 von 98 März 2011
3.2. Externe Rollen
3.2.1. SE_Owner Der SE_Owner spezifiziert die Gestaltung des Secure Elements (SE), sodass insbesondere das von der VDV KA KG definierte Sicherheitsniveau sichergestellt ist. Der SE_Owner definiert wirtschaftliche und rechtliche (Rahmen-) Bedingungen für die Nutzung des SE durch Applikationen.
Der SE_Owner autorisiert Applikationsausgeber (KVP_NMAPP), um Applikationen auf dem SE zu laden (initialisieren) und zu löschen.
Der SE_Owner stellt sicher, dass die Plattform-Umgebung als eine vertrauenswürdige und isolierte Umgebung für die Ausführung der KA-NMApp eingesetzt werden kann und dass die Unbedenklichkeit der Applikation gegenüber der SE-Umwelt und gegenüber anderen Applikationen auf dem SE geprüft ist.
Die Bezeichnung „SE_Owner“ bezieht sich auf die im Kontext von NFC Mobiltelefonen eingeführte Bezeichnung „Secure Element“ als Sammelbegriff für verschiedene Bauformen, z.B. (U)SIM, Secure Digital-Karten, Bluetooth-Sticker, Embedded Chipkarten.
Im Kontext von Multiapplikationskarten werden die allgemeineren Begriffe User-Medium (anstelle von SE-Element) und User-Medium-Owner (anstelle SE_Owner) genutzt.
3.2.2. SE_Security_Manager Subrolle des SE_Owners
Der SE_Security_Manager überwacht im Auftrag des SE_Owners die Einhaltung der Sicherheitsanforderungen für die Secure Elements sowohl in Bezug auf die Herstellung als auch die Nutzung.
Der SE_Security_Manager definiert den Validierungsprozess für die Secure Elements (Rolle „Validation Authority“ in der GlobalPlatform).
Der SE_Security_Manager ist Ansprechpartner des KA-Sicherheitsmanagement bzgl. der Sicherstellung der von der KA geforderten Sicherheitsstandards von KA Nutzermedien.
3.2.3. Secure Element (SE)_Retailer Der SE_Retailer gibt Secure Elements (SE) an Kunden aus und realisiert dafür den Kunden-Service. Der SE_Retailer ist als Vertragspartner gegenüber dem Kunden für die Einhaltung der zugesicherten Sicherheitsstandards und die Funktionsfähigkeit des SE verantwortlich.
Der SE_Retailer hat keine direkten Beziehungen zu den KA-Rollen oder den KA-OTA-Provisioning Rollen. Ein KVP wird jedoch ggf. einen Kunden an den SE_Retailer verweisen, sofern ein Kundenserviceanliegen die Funktionsfähigkeit bzw. Funktionsweise des Secure Elements betrifft. Es ist dem KVP freigestellt, im Rahmen seines Kundenservices auch Beziehungen zu relevanten SE_Retailern zu unterhalten.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 17 von 98 März 2011
3.3. KA-Rollen
3.3.1. Applikationsherausgeber (AH) KA-Rolle
Erweiterung der bislang in der KA definierten Funktionen:
Der AH gewährleistet, dass ausschließlich den Anforderungen der KA genügende SE zum Einsatz kommen. Umgekehrt stellt der AH dem SE_Owner die erforderlichen Informationen bereit, die der SE_Owner benötigt, um die KA als Applikation auf seinem Secure-Element zuzulassen.
Der AH stellt in den Teilnahmeverträgen sicher, dass nur registrierte Secure-Elements für seine Applikationen zur Anwendung kommen.
Der AH genehmigt den applikationsausgebenden Kundenvertragspartnern (KVP-NMAPP) mittels der Teilnahmeverträge die Ausgabe von Applikationen über registrierte SE_TSM und KA_NMApp_Konfiguratoren.
In Analogie zu dem für Secure Elements (in Mobiltelefonen) festgelegten Modell gewährleistet der AH, dass dies auch für alle in der KA zum Einsatz kommenden Nutzermedien Dritter (z.B. Multiapplikationschipkarten) gilt. In diesem Fall stellt der AH dem User-Medium Owner (in Analogie zum SE_Owner) die erforderlichen Informationen bereit, die der User-Medium Owner benötigt, um die KA als Applikation auf seinem User-Medium (in Analogie zum Secure Element) zuzulassen.
3.3.2. KA_Registrar KA-Rolle, Subrolle des AH
Erweiterung der bislang in der KA definierten Funktionen:
Der KA_Registrar registriert die zugelassenen User-Medium-Owner, die zugelassenen SE_Owner, die zugelassenen User-Medium bzw. SE_TSM und KA-NMApp_Konfiguratoren sowie die zugelassenen und zertifizierten User Media und Secure Elements für den Applikatonsdownload.
3.3.3. KA-Sicherheitsmanager KA-Rolle, Subrolle des AH
Erweiterung der bislang in der KA definierten Funktionen:
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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 18 von 98 März 2011
3.3.4. KA-Trustcenter KA-Rolle, Subrolle des AH
Kurzzusammenfassung der wesentlichen Eigenschaften in Bezug auf das OTA Provisioning.
Das KA-Trustcenter bildet die Wurzel der PKI innerhalb der KA. Es stattet die Beteiligten mit vertrauenswürdigen digitalen Identitäten aus. Dazu zählt insbesondere auch die Erstellung von Zertifikaten über die öffentlichen Schlüssel einer Instanz der KA Nutzermedium-Applikation.
3.3.5. Applikationsausgeber (KVP_NMApp) KA-Rolle, Subrolle eines Kundenvertragspartners (KVP)
Der KVP_NMApp schließt Verträge mit SE_Ownern zur Nutzung von deren Secure Elements. Dies kann in Form direkter Verträge erfolgen oder auch indirekt, wenn ein SE_TSM diese zur Verfügung stellt.
Der KVP_NMApp lässt die Einbringung der KA-NMApp auf das SE des SE_Owners von dem AH autorisieren.
Der KVP_NMApp initialisiert über SE_TSM und KA-NMApp_Konfigurator die betriebsbereite KA-NMApp auf Secure Elements geeigneter NFC Mobiltelefone und personalisiert diese KA-NMApps über den KA_NMApp_Personalisierer.
3.3.6. Applikationsausgeber (KVP_HandsetApp) KA-Rolle, Subrolle eines Kundenvertragspartners (KVP)
Der KVP_HandsetApp stellt dem Kunden auf dessen NFC-Handset die optionale KVP-HandsetApp zur Verfügung.
Die KVP-HandsetApp muss nicht zwangsläufig als eigenständiges Programm der mobilen Plattform (z.B. als MIDlet, siehe Referenzplattform) realisiert werden, sondern kann auch als Webapplikation auf der UICC implementiert werden (Smart Card Web Server). In diesem Fall werden beide KVP_* Rollen durch dieselbe Organisation ausgefüllt.
3.4. KA-OTA-Provisioning Rollen
3.4.1. KA-OTA_Provisioning Manager Der KA-OTA_Provisioning Manager steuert im Auftrag eines oder mehrerer KVPs den Gesamtablauf zur Bereitstellung eines betriebsbereiten KA-NM-Handsetservice auf dem NFC Handset des Kunden. Der Gesamtablauf umfasst: Laden der KA-NMApp ( SE_TSM), Konfiguration der geladenen KA-NMApp ( KA-NMApp_Konfigurator) sowie Installation der KA Handset Applikationen und Konfiguration des NFC-Discoverymanagers.
Die KA Ausgabetransaktion ( KA-NMApp_Personalisierer) wird nicht vom Provisioning Manager gesteuert. Die Ausgabetransaktion wird als erste „Nutzungstransaktion“ gesehen, die mit dem KVP-System ausgeführt wird. Es ist dem KVP jedoch freigestellt, die Ansteuerung des KA-NMApp_Personalisierer an das technische System des KA-OTA_Provisioning Managers zu delegieren.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 19 von 98 März 2011
Der KA-OTA_Provisioning Manager kümmert sich um alle Dienste rund um die technischen Kernfunktionen SE_TSM und KA_NMApp_Konfigurator. Dies umfasst insbesondere auch Ermittlung der vom SE_TSM benötigten Informationen über das NFC Handset des Kunden.
Der KVP benennt dem KA-OTA_Provisioning Manager die auszubringenden KA-NM-Handsetservices Konfigurationen (NMApp + KVP-HandsetApp + ggf. weitere Konfigurationsvorgaben) und stellt den ausführenden Rollen die entsprechenden Objekte zur Verfügung (z.B. dem SE_TSM die KA-NMApp).
3.4.2. Secure Element Trusted Service Manager (SE_TSM) Der SE_TSM führt im Auftrag des Applikationsausgebers (KVP_APP) - autorisiert durch den SE_Owner und den Applikationsherausgeber (AH) – das Laden (Initialisieren), Löschen, Aktualisieren, Sperren von KA-NMApp auf dem SE im Kontext der durch das SE bereitgestellten Managementumgebung (GlobalPlatform oder gleichwertige Systeme) durch.
Der SE_TSM setzt autorisiert durch SE_Owner und Applikationsherausgeber (AH) das Supportmanagement um, wenn Konflikte beim Laden oder bei der Aktualisierung der Applikation auftreten (z.B. Überlauf der Kapazität des SE, Unverträglichkeit von Applikationen, ...).
Der SE_TSM arbeitet beim Aufbau des für das Laden der Applikation erforderlichen Sicherheitskontextes und der sicheren Durchführung des Ladens der Applikation mit der SE_Controlling_Authority zusammen.
Der SE_TSM führt ausschließlich Operationen im Kontext der durch das SE bereitgestellten Managementumgebung (GlobalPlatform oder gleichwertige Systeme) durch, d.h. er behandelt die KA-NMApp als „Black Box“. In Bezug auf den Vorgang des Ladens der KA-NMApp bedeutet dies, dass die KA-spezifische Initialisierung des KA-Sicherheitssystems innerhalb der KA-NMApp von einer weiteren Rolle, dem KA-NMApp_Konfigurator, übernommen wird.
Der Zuschnitt der Rolle SE_TSM ist kompatibel zur Definition des Trusted Service Managers (TSM) in den GlobalPlatform Spezifikationen.
3.4.3. SE_Controlling_Authority Die SE_Controlling_Authority ist eine vertrauenswürdige dritte Partei sowohl für den SE_Owner als auch den applikationsausgebenden KVP (KVP-NMApp), vgl. GlobalPlatform Spezifikationen zur Rolle Controlling Authority.
Die SE_Controlling_Authority ermöglicht die sichere und vertrauliche Initialisierung der Applikation während des Downloadprozesses. Hierzu sind unterschiedliche organisatorische und technische Modelle möglich, vgl. GlobalPlatform Spezifikationen. Die für ein SE anwendbaren Modelle werden vom SE_Owner (gestützt auf den SE_Security_Manager) und dem Applikationsherausgeber (gestützt auf den KA-Sicherheitsmanager) autorisiert. Der von dem KVP-NMAPP beauftragte SE Application Lifecycle Manager (entspricht dem TSM in der GlobalPlatform Spezifikation) und die SE_Controlling_Authority sind verantwortlich für die Implementierung der entsprechenden Prozesse und technischen Schnittstellen.
In einem Modell, in dem der SE_Owner der KA eine eigene GlobalPlatform Security-Domain zuweist, wäre der Applikationsherausgeber (AH) geeignet, die Rolle SE_Controlling_Authority auszufüllen. In anderen Szenarien wird die SE_Controlling_Authority de facto vom SE_Owner bestimmt.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 20 von 98 März 2011
3.4.4. KA-NMApp_Konfigurator Der KA-NMApp_Konfigurator konfiguriert im Auftrag des Applikationsausgebers (KVP-NMAPP) - autorisiert durch den Applikationsherausgeber (AH) – eine in das SE (bzw. allgemein in ein Nutzermedium) geladene KA Applikation, so dass diese anschließend betriebsbereit ist, d.h. durch die KA Applikationsausgabetransaktion in Umlauf gebracht werden kann.
Wichtigstes Element des Konfigurationsvorgangs ist die Initialisierung des KA-Sicherheitssystems, d.h. die Erzeugung des Public/Private Key der KA-NM-Applikationsinstanz und dessen Beglaubigung durch ein Zertifikat. Der KA-NMApp_Konfigurator betreibt dazu eine KA Sub-RA und tauscht Daten mit dem KA-Trustcenter aus.
Die Prozesse und technischen Einrichtungen des KA-NMApp_Konfigurators werden durch den KA-Sicherheitsmanager validiert.
3.4.5. KA-NMApp_Personalisierer Der KA-NMApp_Personalisierer personalisiert im Auftrag des Applikationsausgebers (KVP-NMAPP) eine betriebsbereite KA-NMApp. Dies umfasst die Ausführung der KA Applikationsausgabetransaktion sowie (optional) die Initialisierung des Kundenprofils (Teil der KA-NM-Applikation) mit den Daten des künftigen Karteninhabers.
Der KVP stellt dem KA-NMApp_Personalisierer die dazu benötigten KVP-Schlüssel zur Verfügung.
3.4.6. KVP_HandsetApp_Loader Der KVP_HandsetApp_Loader sorgt im Auftrag der Subrolle KVP_HandsetApp des Applikationsausgebers für den Download und die Installation der KA-HandsetApp (Mensch-Maschine-Interface für den Fahrgast zum Tätigen von Einstellungen, ggf. Kaufen von EFS, ggf. CICO-Service).
Ein KVP_HandsetApp_Loader kann auch im Auftrag eines KVP tätig werden, wenn auf einem NFC-Handset (mit bereits vorhandener KA-NMApp und KVP-HandsetApp) eine weitere KVP-HandsetApp geladen werden soll.
3.5. Sonstige Rollen
3.5.1. Mobilfunkanbieter Der Mobilfunkanbieter schließt mit Nutzern Verträge über die Nutzung von Mobilfunkleistungen.
Der Mobilfunkanbieter kann gleichzeitig auch SE_Owner sein (wenn das SE in Form der (U)SIM-Karte vorliegt), siehe SE_Owner.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 21 von 98 März 2011
3.5.2. Technologielieferanten Die Lieferantenrollen KA-NMApp-Hersteller, KA-HandsetApp-Hersteller, Handset-Hersteller etc. sind nicht spezifikationsbedürftig. Soweit diese Lieferanten spezielle technische Parameter oder organisatorische Prozesse einzuhalten haben, so werden diese von den Auftraggebern (KVP_NMApp, SE_Owner, …) den Lieferanten vorgegeben. Die Komponenten und/oder Hersteller müssen teilweise von dem AH und/oder dem SE_Owner zertifiziert werden.
3.6. Hinweise zur Allokation von Rollen Die in den vorherigen Abschnitten beschriebenen Rollen stellen funktional abgegrenzte Bereiche dar. Nachfolgend sollen Hinweise gegeben werden, wie sich insbesondere die Rollen des Abschnitts 3.4 auf reale Organisationen (Unternehmen) abbilden lassen.
KA-OTA_Provisioning Manager
Der KA-OTA_Provisioning Manager handelt im Auftrag des KVP. Er kann also auch durch den KVP in einem eigenen technischen System realisiert werden.
Alternativ bietet es sich an, einen technischen Dienstleister mit der Durchführung zu beauftragen. Die Funktion des KA-OTA_Provisioning Manager ist stark technisch geprägt, so dass die KVP-übergreifende Nutzung einer entsprechenden Plattform realistisch erscheint.
SE_TSM
Der SE_TSM handelt im Auftrag des KVP. Er kann also prinzipiell auch durch den KVP in einem eigenen technischen System realisiert werden. Die technologischen und organisatorischen Anforderungen sind jedoch so speziell, dass dies kein realistisches Szenario ist. Der SE_TSM wird in aller Regel durch entsprechend spezialisierte technische Dienstleister implementiert werden.
KA-NMApp_Konfigurator
Analog dem SE_TSM ist auch hier davon auszugehen, dass der KA-NMApp_Konfigurator in aller Regel durch entsprechend spezialisierte technische Dienstleister implementiert werden wird.
KA-NMApp_Personalisierer
Der KA-NMApp_Personalisierer handelt im Auftrag des KVP. Er kann also auch durch den KVP in einem eigenen technischen System realisiert werden.
In Bezug auf KA-NMApp in NFC Mobiltelefonen ist das benötigte technische System eng verwandt mit dem technischen System für die Ausgabe von Berechtigungen. Insofern erscheint die Realisierung in einem eigenen technischen System des KVP (ggf. auch einem von mehreren KVP gemeinsam beschafften und betriebenen System) durchaus realistisch.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 22 von 98 März 2011
Alternativ kann auch ein technischer Dienstleister eingesetzt werden, der eine geeignete Serviceplattform betreibt.
KA-HandsetApp_Loader
Der KA-HandsetApp_Loader handelt im Auftrag des KVP. Er kann also auch durch den KVP in einem eigenen technischen System realisiert werden.
Analog dem KA-OTA_Provisioning Manager bietet es sich jedoch an, einen technischen Dienstleister mit der Durchführung zu beauftragen. Die Funktion des KA-HandsetApp_Loader ist stark technisch geprägt, so dass die KVP-übergreifende Nutzung einer entsprechenden Plattform realistisch erscheint.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 23 von 98 März 2011
4. Funktionale Systembeschreibung
Das in der vorliegenden Spezifikation beschriebene OTA Provisioning System stellt die grundlegenden Prozesse des Installierens, Konfigurierens und des Verwaltens von sogenannten KA-NM-Handsetservices im NFC-Handset zur Verfügung.
Dabei werden als KA-NM-Handsetservices alle fachlichen Komponenten verstanden, die zur Nutzung der KA auf NFC-Handsets entweder erforderlich oder optional wünschenswert sind (siehe auch Abschnitt 0).
Für die Durchführung der Aufgaben erhält das System die zur Verteilung an die Handsets erforderliche Software vom KVPS (der KA-Handsetservice Lieferant liefert die entsprechende Software zuvor an den KVP), speichert diese in einem internen Repository ab, beziehungsweise aktualisiert die dort bereits vorhandenen Software Versionen, und stellt die Komponenten dann seinerseits zur Verteilung an die Mobiltelefone bereit.
Dabei werden grundsätzlich alle direkt mit Installation, Konfiguration und Verwalten der KA-NM-Handsetservices auf dem Handset in Verbindung stehender OTA Prozesse vom KVPS des zum Mobiltelefonbesitzer gehörenden KVP in Auftrag gegeben. Die Aktivität fließt vom KVPS über das OTA Provisioning System zum NFC-Handset.
Für die Adressierung des NFC-Handsets wird im Standardfall die MSISDN angenommen. Die Verwendung anderer Adressierungsarten unter Einbeziehung alternativer Registrar-Systeme ist dennoch denkbar.
4.1. Hauptprozess Der wichtigste Prozess des OTA Provisioning ist die Installation oder die Wiederherstellung einer nutzbaren Gesamtkonfiguration der KA-NM-Handsetservices. Die Wiederherstellung einer nutzbaren Konfiguration kann zum Beispiel durch den Tausch des Telefons, den Tausch der SIM Karte oder den Wechsel eines externen Secure Elements erforderlich werden.
Der Hauptprozess führt also zur Verwendbarkeit des NFC-Mobiltelefons als KA-Medium und umfasst die Schritte:
Prüfung, ob das Handset die Voraussetzungen erfüllt.
Identifikation der erforderlichen Version(en) der KA-NM-Handsetservices, insbesondere auch Prüfung der Kompatibilitäten mit bereits vorhandenen Komponenten der KA-NM-Handsetservices.
Einbringen der KA-NM-Handsetservices (bzw. der fehlenden Komponenten) in den entsprechenden kompatiblen Versionen.
Falls erforderlich: Anstoßen des Lifecycle der KA-NMApp bis hin zum Status Operational. Hierzu ist insbesondere das Generieren des NM Schlüsselpaares innerhalb der KA-NMApp, das Auslesen des Schlüssels sowie die anschließende Einbringung des Zertifikates der VDV Sub-CA der VDV-PKI über den öffentlichen Schlüssel erforderlich.
Optional
Die oben beschriebenen Schritte führen zur Erstellung eines KA-Mediums im Secure-
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 24 von 98 März 2011
Element. Der KVP Personalisierer kann (muss aber nicht) die anschließend stattfindende KA Personalisierung an das OTA-Provisioning-System delegieren. Dies ist im Hinblick auf Nutzerfreundlichkeit sinnvoll, weil erst nach der KA Applikationsausgabe das KA-Medium für den Mobiltelefonbesitzer sinnvoll verwendbar ist.
Nicht nur die Personalisierung kann das KVP System an das OTA-Provisioning-System delegieren, sondern weitergehend auch die Ausgabe der initialen Automatischen Fahrberechtigung auf das neue KA-Medium. Zu diesem Zweck nutzt das KVPS das OTA-System wie ein KVP-Terminal im Aktionslistenverfahren und übergibt den in [11] definierten Datensatz TXAAUFBER an das OTA-Provisioning-System. Im Gegensatz zu der Definition in [11] muss für diesen Fall die Einschränkung entfallen, dass im TXAAUFBER keine Fahrberechtigungen vom Typ AFB (POP, PEB, WEB und WES-AFB) enthalten sein dürfen.
Insgesamt ergibt sich der in Abbildung 3 gezeigten Gesamtablauf.
sd Hauptprozess - Übersicht
KVPT nahe Funktion - optional
Einrichtung KA
Security-Domain
Laden der NmApp
und Konfiguration
der Applikation
KA-Personalisierung Ausgabe des
initialen EFS
Abbildung 3 Übersicht des Hauptprozesses
Für die in Abbildung 3 als optional gekennzeichnete Schritte muss das OTA-Provisioning-System Teile der KVPT Funktionalität integrieren. Dies führt notwendigerweise dazu, dass das OTA-Provisioning-System über eine Verwaltung der KVP- und PV-Schlüssel verfügen muss. Diese Erhöhung der technischen Anforderungen ist der Grund warum die Funktionalität in realisierten Systemen auch vom KVPS (bzw. KVPT) durchgeleitet werden kann. In diesem Fall ist es die Aufgabe des OTA-Systems, dem KVPS (bzw. KVPT) ein „Over-The-Air“-Stream zur Verfügung zu stellen, mit dessen Hilfe es direkt Chipkartenkommandos mit der KA-NMApp austauschen kann.
Neben dem Hauptprozess existieren weitere Prozesse, die für die Sperrung des Nutzermediums4 (Sperrung/Entsperrung 6.2.6) oder für die Übertragung von Softwarekomponenten sowie der anderen zu verteilenden Artefakte an das OTA-Provisioning-System verantwortlich sind.
4 Hier wird unter der Sperrung/Entsperrung die Änderung der Sichtbarkeit/Selektierbarkeit der
gesamten Applikation verstanden, nicht die in der KA vorgesehene Sperrung/Entsperrung der KA-NMApp, die auf Applikationsebene stattfindet.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 25 von 98 März 2011
4.2. Unterprozesse und beteiligte Systeme Das OTA-Provisioning-System bedient sich zweier Unterprozesse. Der eine ist verantwortlich für die Kommunikation und Vorbereitung des Secure Elements und wird im weiteren TSM Prozess genannt. Der andere Prozess dient der Einbringung des KA Mediums. Beide Teilprozesse werden von eigenständigen Komponenten bereitgestellt, die bezüglich der technischen Realisierung extern sein können. Im Systemkontext werden sie als zum OTA-Provisioning System-gehörend angenommen.
TSM-Funktionalität
Die Einrichten einer KA-Security-Domain und das Laden der Applikationsdaten werden durch den mit dem Secure Element konjugierten TSM durchgeführt. Hierzu delegiert das OTA- Provisioning-System die entsprechenden Teilprozesse an die TSM-Funktionalität. In einem realisierten System ist die TSM-Funktionalität sowohl gesamthaft intern, extern oder verteilt vorstellbar. Um den konjugierten TSM festzustellen, muss das System zunächst Daten zur Identifikation des Secure Elements ermitteln. Mit diesen Daten kann zunächst auf den SE_Owner geschlossen und damit wiederum auf den zuständigen, weil durch den SE_Owner autorisierten, TSM. Die Daten des Secure Elements werden vom System gegenüber einer Positivliste unterstützter Secure Elements geprüft und mit Hilfe der oben erläuterten Routing-Datenbank wird dann der zugeordnete TSM ermittelt.
NM-Config
Mit Hilfe der gesicherten Kommunikation des TSMs werden die KA-Security-Domain5, die NM Applikationsdaten sowie die root-Daten PuK.Root eingebracht. Die NM-Config Komponente des OTA-Provisioning-Systems nimmt zunächst die Rolle AppLoader ein (siehe [10]), lädt die Applikation und bringt den Datensatz PrK.Config, der der Authentifizierung im nächsten Prozessschritt dient, ein. Der anschließende Prozess der Konfiguration generiert das zum Medium gehörende Schlüsselpaar und bringt abschließend das vom Trustcenter des Applikationsherausgebers erhaltend Zertifikat Cert-PuK-NM sowie die appInstanz_ID ein.
5 Ggf. wird direkt die Issuer-Secure-Domain (ISD) genutzt und keine dedizierte KA-SD eingebracht.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 26 von 98 März 2011
4.3. Fachliche Komponenten der KA-NM-Handsetservices
Abbildung 4: Komponente der KA-NM-Handsetservices
Die Abbildung zeigt die fachlichen Komponenten der KA-NM-Handsetservices im Kontext des NFC Mobiltelefons. Der Zugriff des OTA-Provisioning-Systems auf das Mobiltelefon erfolgt grundsätzlich über das Mobilfunknetzwerk. Das zwischen OTA-Provisioning-System und Handset verwandte Protokoll wird vom Betreiber des Systems festgelegt, eine Festlegung dieses systeminternen Protokolls ist nicht sinnvoll. Die im Verlauf des Ladens der KA-Handset-Services einzubringenden Komponenten sind das KA Medium, optional die KVP-HandsetApp und ebenfalls optional die Discoverymanager-Konfiguration. Die nachfolgende Tabelle führt die Verantwortlichkeiten dieser Komponenten auf.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 27 von 98 März 2011
KA Medium (muss) Secure Element mit eingebrachter KA-Security-Domain / Schlüsseln sowie einer KA-NMApp. Die Applikation kann im Status CONFIGURATION oder OPERATIONAL sein. Im letzten Fall ist sie über die kontaktlose KA-Schnittstelle selektierbar.
KVP-HandsetApp (optional)
Applikation die den über das Mobilfunknetz verlaufenden Nachrichtenfluss zwischen KA-NMApp und KVPS kontrolliert (siehe [12]). Sie kann, muss aber nicht. im Verlaufe der OTA-Prozesse eingebracht werden, da sie nicht zwingend notwendig für die Nutzung des Mediums ist. Die Installation im Verlaufe der KA-NM-Handsetservices hat jedoch aus Sicht des Handset Nutzers einen klaren Bedienvorteil6. Die KVP- HandsetApp kann als Java MIDlet implementiert werden; in diesem Fall stehen die in JSR 177 und JSE 257 definierten APIs für den Zugriff auf das Secure Element, NFC Controller und Discoverymanager zur Verfügung.
Discoverymanager Konfiguration (optional)
Die Selektierbarkeit der KA-NMApp über die kontaktlose KA-Schnittstelle wird durch die Konfiguration des NFC – Discoverymanagers gewährleistet, dieser ist Bestandteil der NFC-Infrastruktur des NFC-Handsets. Abhängig von der Mobilplattform kann darüber hinaus der Start der KVP-HandsetApp durch die passive NFC Verkaufsinfrastuktur ausgelöst werden. Dies fällt ebenfalls in den Verantwortungsbereich des Discoverymanagers.
Es kann nicht davon ausgegangen werden, dass alle Mobilplattformen eine Konfigurierbarkeit dieser Funktionalitäten anbieten. Die Referenzplattform J2ME tut dies, dort wird der Discoverymanager Pushregistry genannt.
Je nach Realisierung kann noch eine weitere Komponente hinzukommen, die zum System des TSM gehört und TSM-Connector benannt wurde. Der TSM-Connector muss nicht als eigenständige Softwarekomponente realisiert sein, vielmehr kann auch bereits existierende Protokolle wie das Bearer Independent Protokoll (BIP) zur Kommunikation mit der (U)SIM bzw. auf andere vorhandene Firmware Funktionen zugegriffen werden.
6 Da keine gesonderte Installation erforderlich ist.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 28 von 98 März 2011
TSM-Connector Komponente die auf der Seite des NFC-Handsets das OTA System in die Lage versetzt, mit dem Secure Element zu kommunizieren und mit Hilfe von Mechanismen und Kommandos der GlobalPlatform die KA-Security-Domain zu erstellen, die konkreten Programmdateien der KA-NMApp einzubringen und abschließend diese zu konfigurieren.
4.4. Weitere Aspekte
Authentifizierung & Autorisierung
Bevor das OTA-Provisioning-System eine Operation im Namen eines KVP durchführt, wird die Berechtigung des KVPs überprüft.
Die ORG_ID des KVP muss auf der Liste der vom System akzeptierten KVPs enthalten sein.
Das KVPS muss die Anfrage mit einem korrekten Zertifikat gestellt haben.
Die OTA Operation muss für diesen KVP erlaubt sein.
Wiederholversuche
In Mobilfunknetzen muss grundsätzlich mit Unterbrechungen bei der Erreichbarkeit von Teilnehmern ausgegangen werden. Je nach Situation gibt es unterschiedliche Strategien, Wiederholungen bei Fehlversuchen zu initiieren.
Nutzerinitiierte Wiederholversuche werden regulär über das KVPS veranlasst.
Zeitgesteuerte Wiederholversuche können über das KVPS oder eine dem KVPS nachgelagerte Komponente gesteuert werden, dies kann das OTA Provisioning System sein.
Wiederholversuche, die durch Ereignisse des Mobilfunknetzes ausgelöst werden, müssen von dem den KVPS nachgelagerten Komponenten gesteuert werden, also dem OTA-Provisioning-System oder dem TSM-System. Hierzu gehören auch Wiederholversuche, die automatisch oder manuell durch das Mobiltelefon initiiert werden.
Ziel dieser Festlegung ist es, das KVPS frei von technisch induzierten Wiederholversuchen zu halten und gleichzeitig das KVPS als zentrale Schnittstelle für die Kundeninteraktion beizubehalten.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 29 von 98 März 2011
5. Funktionale Architektur
Grundlegendes Merkmal der Architektur des OTA-Provisioning-Systems ist die Trennung in ein zentrales Hintergrundsystem und eine Kommunikationsschicht auf dem NFC-Mobiltelefon. Zwischen diesen beiden physikalisch getrennten Teilen werden die Daten „Over The Air“ über das mobile Datennetz übertragen.
Die Kommunikationsschicht auf den NFC-Handsets besitzt eine hohe Abhängigkeit von den technischen Bedingungen der unterschiedlichen Mobilfunkplattformen. Aufgrund der Vielzahl der im Rahmen dieses Dokuments berücksichtigten Integrationsformen des Secure-Elements (eingebettetes SE, (U)SIM, Secure Digital oder Bluetooth Modul) erscheint es sinnvoll, die genaue Ausgestaltung der Realisation den Anbietern der TSM-Funktionalität zu überlassen. An die TSM Komponente werden daher lediglich drei grobgranulare funktionale Anforderungen gestellt.
1. Die TSM Komponente kann die zur Identifikation des Secure-Elements notwendigen Daten ermitteln. Hierbei sollen alle geeigneten Secure-Elements des durch seine MSISDN7 adressierten NFC-Handset, berücksichtigt werden.
2. Die TSM Komponente kann in ein adressiertes Secure-Element eine KA-Security-Domain einbringen und dort ein KA-NMApp laden.
3. Die TSM Komponente kann an die KA-NMApp, die von einem externen System erhaltenden Chipkartenkommandos, senden.
Optional (Falls KVP die entsprechenden Artefakte über OTA Provisioning zur Verfügung stellen möchte)
4. Die TSM Komponente installiert die KVP-HandsetApp auf dem Zielsystem und nimmt Konfigurationen des Discoverymanagers vor.
Die Anforderung 3. bezieht sich dabei auf die Durchleitung der für die KA-NMApp Konfiguration erforderlichen Chipkarten-Kommandos, deren Erzeugung nicht in der Verantwortlichkeit des TSM liegt. Dies gilt analog für die optional vom OTA Provisioning System durchzuführende KA Personalisierung und deren Kommandos.
Das OTA System gliedert sich entsprechend seiner Aufgaben in folgende vier Bereiche.
KA OTA Supplymanagement (Ablaufsteuerung)
TSM-Funktionalität
KA-NMApp Konfiguration (Prozess NM-Config)
Software und Konfigurationsmanagement Diese Bereiche werden in den folgenden Abschnitten beschrieben.
7 Oder durch eine andere eindeutiges Adressierungsverfahren.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 30 von 98 März 2011
5.1. KA-OTA-Supplymanagement Das KA-OTA-Supplymanagement steuert die in Kapitel 6 beschriebenen Prozesse und orchestriert hierzu die Komponenten des OTA Systems. Es verfügt über eine Schnittstelle zum KVPS mit der die Operationen des OTA-Provisioning initiiert werden.
Es ist verantwortlich für die Wiederaufnahme unterbrochener OTA-Prozesse. Hierzu werden die Ereignisschritte zwischengespeichert. Die Zwischenspeicherung dient ausschließlich der Durchführung und Optimierung der technischen Prozesse und erfolgt nur über kurze Zeit. Die längerfristige Speicherung der (Transaktions-)Daten findet beim KVP statt.
composite structure KA Supplymanagement
NM Handset
Service Provider
Schnittstelle
KA Supplymanagement
NM Handset
Service Provider
Schnittstelle
System AP200::VDV KA
Supplymanagement::
Authentication &
Authorisation
Process Engine
System AP200::VDV
KA
Supplymanagement::
Session Tracking &
Short Memory
TSM::TSM
TSM Interface
KP, Diskussion: Asynchrone
Bereitstellung von Ergebnissen,
z.B. auf Grunde von
Wiederholungen.
KVP OTA
Auftragsschnittstelle
NM
Config
KVP OTA
Ergebnisschnittstelle
NM Handset
Service Delivery
Schnittstelle
TSM Interface
Abbildung 5: Komponente KA-OTA-Supplymanagement
5.2. TSM-Funktionalität Abbildung 5 zeigt Zusammenhänge von KA-OTA-Supplymanagement sowie der TSM-Funktionalität beim Installieren, Konfigurieren sowie den weiteren Lifecycle-Operationen auf dem KA-NMApp. Der blaue Kasten umfasst das TSM System sowie die TSM Funktionalität auf dem Handset. An der Schnittstelle zu diesem Verantwortungsblock müssen die folgenden Operationen zur Verfügung stehen.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 31 von 98 März 2011
cmp TSM OTA View
HandsetZentral System AP200
TSM Funktionalität
(from Handset)
NmApp Config
KA Supplymanagement
Secure Element
(from Handset)
KVP System
CM Repository
Secure Element::
VDV KA NM
TSM::TSM
«configures»
(optional)
«install»
beauftragt
«flow»
«flow»
fordert NM Handset Services an
fordert Initialisierungssequenz an
Abbildung 6: TSM OTA Interaktion
1. Die TSM-Funktional-Komponente kann die zur Identifikation notwendigen Daten aller Secure-Elements ermitteln, die in einem durch seine MSISDN adressierten NFC-Handsets gefunden wurden.
Anfrage des OTA-Supplymanagement Antwort der TSM-Funktional-Komponente
(MSISDN , Liste mit SE-Typen8) (Liste mit (SE Kennung, SE Typ))
2. Die TSM-Funktional-Komponente kann in ein vollständig adressiertes Secure-Element eine KA-Security-Domain einbringen und dort eine KA-NMApp laden.
Anfrage des OTA-Supplymanagement Antwort der TSM-Funktional-Komponente
(MSISDN, SE Kennung, Binärdaten KA-NMApp, ** ) (Verbindungsparameter für Kommunikation mit KA-NMApp)
** Optionale Parameter können z.B. weitere in die Security-Domain einzubringende Applikationen sein, Angabe ob ISD genutzt werden soll oder allgemein Daten zur KA-Security-Domain.
8 Auf (U)SIM, embedded SE, SD Karte, externes SE
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 32 von 98 März 2011
3. Die TSM-Funktional-Komponente kann an die KA-NMApp die von einem externen
System erhaltenden Chipkartenkommandos senden.
Anfrage des OTA-Supplymanagement Antwort der TSM-Funktional-Komponente
(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.
Anfrage des OTA-Supplymanagement Antwort der TSM-Funktional-Komponente
(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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 33 von 98 März 2011
5.3. KA-Nm-Konfiguration (NM-Config) Diese Komponente überwacht den Lade und Konfigurationsprozess der Nutzermediums Applikation KA-NMApp (siehe [7]), insbesondere verfügt sie über die Möglichkeit mit Hilfe des Trustcenters des AH eine Signatur über den Public Key der KA-NMApp zu erstellen und in diese einzubringen. Da der Abruf des Zertifikats Grundlage der zugrundeliegenden Berechnung der Abnahmemenge zwischen AH und KVP sein kann, muss er protokolliert werden. Für den Fall eines Prozessfehlers muss die Zurückname des Zertifikats beim Trustcenter beantragt werden (REVOKE) und in der Protokollierung vermerkt werden.
composite structure KA NM Config
Zertifikatsabruf Schnittstelle
NmApp Config
Zertifikatsabruf Schnittstelle
System AP200::
NmApp Config::
Configurer
System AP200::
NmApp Config::
Loader
NM Config
Schnittstelle
Abbildung 7: Komponente NM Konfigurator
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 34 von 98 März 2011
5.4. Software und Konfigurationsmanagement Die auf den NFC-Handsets zu installierende Software wird vom OTA-Provisioning-System zentral in einem Repository gespeichert. Es ist davon auszugehen, dass die Software für unterschiedliche NFC-Handsets und Secure-Element differenziert werden muss. Somit ist es erforderlich, zusätzlich zu den Nutz- auch Metadaten abzuspeichern, die die eindeutige Auswahl von Softwareversionen anhand der zuvor ermittelten Gerätemerkmale und Versionsständen der bereits installierten Komponenten gewährleistet.
Im Anhang befindet sich eine Beschreibung des hierfür anzuwendenden Verfahrens.
composite structure CM Repository
CM Repository
Handset Service Delivery Interface
System AP200::CM
Repository::
Discov eryManager
Konfigs
System AP200::CM
Repository::KVP-Apps
System AP200::
CM Repository::
Version
Resolution
System AP200::
CM Repository::
NmApps
NM Handset Service
Provider Interfacer
sucht Software in
sucht Software in
stellt Software ein
Abbildung 8: Komponente CM Repository
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 35 von 98 März 2011
6. Anwendungsfälle und Fachklassen
6.1. Fachklassenmodell class Fachklassen
NFC-Ticketingserv ice-Kunde NFC-Handset
- Typ: HandsetTyp
- Version: Number
- msisdn: MSISDN
NFC-Handset::Secure
Element
- Identifier: String
- Typ: SE Typ
«singleton»
KA NmApp
NFC-Handset::VDV
KA NM Container
KA NM Handsetserv ice
- Version: Number
NFC-Handset::ISD NFC-Handset::SD
TSM Connector
Secure Element
Owner
Discov eryManager Discov eryManager
Config
KVP
KVP HandsetApp
Prioritätenliste
- Prorität: int
- SE Typ: SE Typ
- HandsetTyp: HandsetTyp
Positiv liste SE
- Typ: SE Typ
- SE Owner: SE Owner
Positiv liste Handset
- Typ: HandsetTyp
TSM-Connector ist optional
und die Realisierung vom OS
des Handsets abhängig.0..1
1
1..*
besitzt
1
0..1
1
1..*1
1
0..*
1 1 0..*
11
1 1
bestimmt
Verwendbarkeit1
0..*
0..1
1
Enthält Startregel für App
0..1
1
liefert
l iefert
install iert
l iefert
bestimmt
Verwendbarkeit
0..1
1
Abbildung 9: Fachklassen
Der NFC-Ticketingservice-Kunde steht in vertraglicher Beziehung zu einem Kundenvertragspartner KVP und besitzt ein oder auch mehrere NFC-Handsets. Auf jedem seiner NFC-Handsets können im Rahmen des zentralen OTA-Prozesses ein oder mehrere KA-NM-Handsetservices installiert werden. Die KA-NM-Handsetservices bestehen aus KA-NMApp, KA-KVP-HandsetApp sowie der Discoverymanager Konfiguration.
Die KA-NM-Handsetservices sind voneinander unabhängig, allerdings teilen sich alle KA-NM-Handsetservices eines NFC-Handsets eine gemeinsame Instanz der KA-NMApp unabhängig davon, wie viele Secure-Elements bzw. darauf befindliche SD/ISD, die eine solche KA-NMApp aufnehmen könnten, auf dem NFC-Handset vorhanden sind.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 36 von 98 März 2011
Hieraus ergibt sich unmittelbar, dass beim Installieren eines KA-NM-Handsetservices eine vorhandene KA-NMApp weder ausgetauscht noch eine weitere installiert werden darf. Stattdessen darf eine KA-NMApp von mehreren KA-NM-Handsetservices (insbesondere also mehreren KVP-HandsetApps) angesteuert werden.
Die KA-NMApp wird in einem KA-NM-Container eingespielt, dieser Container wird durch eine Issuer Security-Domain (ISD) oder eine dedizierte Security-Domain geliefert. Physikalisch ist das Ganze in ein Secure-Element eingebettet, zu dem ein SE_Owner die Berechtigungen vergibt. In den meisten Fällen delegiert der SE_Owner alle mit dem Berechtigungssystem des Secure-Elements in Verbindung stehenden Prozessen an einen TSM, für das Modell ist er an dieser Stelle unwichtig, da er funktional, jedoch nicht strukturell auftritt.
Die beiden Positiv-Listen, die bestimmen auf welchen Handsets und auf welchen Secure-Elementen die Software installiert werden darf, sowie die Prioritätenliste, mit deren Hilfe bestimmt wird in welcher Reihenfolge das Ziel Secure Element gesucht wird, werden vom KVP geliefert und definieren dessen Präferenzen. Zwecks Übersichtlichkeit wurden weitere Lieferbeziehungen, die zu den Komponenten des KA-NM-Handsetservices existieren, nicht eingezeichnet, auch diese werden durch den KVP bereitgestellt.
6.2. Anwendungsfälle Abbildung 10 zeigt eine Übersicht der Anwendungsfälle. Diese werden in den nachfolgenden Abschnitten genauer erläutert.
Prüfen der Voraussetzung: In diesem Anwendungsfall wird überprüft, ob ein NFC-Handset den für die Nutzung als KA-Medium existierende Anforderungen des KVPs entspricht.
Übergabe von Software: In diesem Anwendungsfall übergibt das KVP System die Softwarekomponenten der KA-NM-Handsetservices an das OTA-Provisioning-System.
KA-NM-Handsetservice laden: Dieser zentrale Anwendungsfall lädt die KA-NM-Handsetservices auf ein NFC fähiges Gerät.
KA-NMApp sperren: In diesem Anwendungsfall wird der Zugriff (Selektierbarkeit der Applikation entsprechend GlobalPlatform) auf die KA-NMApp gesperrt oder erlaubt.
KA-NM-Handsetservice aktualisieren: Wiederherstellen, Ergänzen oder Ersetzen der KA-NM-Handsetservices bzw. von Komponenten der KA-NM-Handsetservice.
KA-NM-Handsetservice löschen: Entfernen aller auf dem NFC-Handset installierten Komponenten/Artefakte der KA-NM-Handsetservice.
Mit Hilfe dieser Anwendungsfälle können die Geschäftsvorfälle Kunde tauscht sein NFC-Handset, Kunde ändert seine Secure-Element Konfiguration (durch Tausch (U)SIM, Handset oder Tausch/Verlust des externen Secure-Element, Kunde wechselt seine MSISDN) sowie Kunde verliert sein NFC-Handset abgebildet werden. Die konkrete Gestaltung obliegt dem
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 37 von 98 März 2011
KVP, die Steuerung des übergeordneten Geschäftsprozess und die Überprüfung von Vorbedingungen dem KVPS.
uc Systemanwendungsfälle
KA-OTA-Provisioning-System
Prüfen der
Voraussetzung
Übergabe v on
Software
KA NM
Handsetserv ices
laden
Sperren/Entsperren
des KA NM
Update der KA NM
Handset-Serv ices
Löschen der KA NM
Handset-Serv ices
KVPS
AHS
Übergabe v on
SE-Positiv liste
AH Trustcenter
Abbildung 10: Anwendungsfälle
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 38 von 98 März 2011
6.2.1. Prüfen der Voraussetzung
act Prüfen der Voraussetzung
Prüfen der Voraussetzung TSM-Connector, SE, NM Cardlet(s)
Prüfen ob KVP die
Berechtigung hat das System
zu nutzen
Erfolg
Prüfen ob das Handset
mindestens ein
zugelassenes SE enthält
KVP ist berechtigt ?
Fehler
Ergebnis der
SE-Prüfung ist
KVPS
Prüfen der
Voraussetzungen
- Start
Melde KVP:
kein
Berechtigung
Melde KVP:
Zugriff nicht
zugelassen
Melde KVP:
Alles Ok
Verbindung aufbauen zum
Handset.
Handset z Zt.
nicht
erreichbar
[nicht
zugelassen]
[zugelassen]
[Kunde hat entsprechendes NFC-Device]
«flow»
[berechtigt]
[nicht berechtigt]
[erreichbar]
[nicht erreichbar]
Abbildung 11: Prüfen der Voraussetzung
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 39 von 98 März 2011
Prüfen der Voraussetzung9
Zweck Die Prüfung der Voraussetzungen gibt dem KVP die Möglichkeit, zu prüfen ob ein NFC Handset den Voraussetzungen zum Aufnehmen eines KVP-Handsetservices und insbesondere einer KA-NMApp entspricht. Wie abgebildet werden bestimmte Fehler an den KVPS zurück gemeldet.
Erweitert -
Wird erweitert durch -
Akteure
KVPS Kunde mit Trägermedium
Kanäle
KVPS-System Verbindung Mobiles Internet System – NFC Handset
Vorbedingung
System besitzt benötigte Software für evt. Laden des TSM Connectors. System enthält Liste von zugelassenen Handsets und Secure Elements.
Standardablauf
1. Prüfen ob KVPS berechtigt ist, über das System die Anfrage zu starten 2. KVPS beauftragt das KA-OTA-Provisioning System, die Voraussetzungen eines
bestimmten NFC Handset zu prüfen. Input ist die Handy Nummer des NFC Ticketingservice Kunde Handsets
3. System überprüft ob Handset erreichbar ist 4. System überprüft Voraussetzung, d.h.;
a. Ob es ein geeignetes Handset ist, d.h. ob die Handset-Services für das spezifische Modell verfügbar sind.
b. Ob das SE zugelassen ist, d.h. ob das SE auf der Liste von KA KG zertifizierten SE vorhanden ist.
5. System überprüft, welche Software und zugehörige Versionen des KA Handsetservices und dessen Artefakte auf dem Handset ggf. bereits vorhanden sind.
Alternativ ablaufe
Wenn das Handset den Voraussetzungen nicht entspricht, muss der KVP über weitere Schritte entscheiden, ob ein alternatives VDV-KA NM an zu bieten ist
Nachbedingung
Handset und Secure Element wurden als zugelassen erkannt und Meldungen dazu wurden an den KVPS zurückgegeben. Dabei werden auch Details wie Handy, SE Type und OS
9 Im rahmen des GP wird dieser Prozess auch Eligiblity Check genannt wo der Issuer die
Zulassungsbeschraenkungen für das Handset definiert und die notwendige Maßnahmen nimmt.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 40 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 41 von 98 März 2011
6.2.2. Übergabe von Software act Activ ity
Übergabe v on Software
Empfang der
Software
Überprüfe empfangene
Software
Software OK?
«datastore»
Speichere
Software
Neue oder Update Software?
«datastore»
Archiv iere alte
v ersion, speichere
neue v ersion
Erfolg
Übergabe
von Software
- start
Fehler
Melde KVP:
Software
gespeichert
Melde KVP:
Software wurde
aktualisiert
Melde KVP:
Software nicht
gespeichert
Software:
1. Cardlet
2. TSM Connector
3. Handy whiteliste
Prüfen ob KVP
Berechtigung hat über das
System Abfrage zu starten
Prüfe KVP
Übergabeparameter und
Voraussetzungen
[nein]
[ja]
[Update][Neu]
Abbildung 12: Übergabe von Software
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 42 von 98 März 2011
Übergabe von Software
Zweck Vor dem Laden der KA NM -Service muss die benötigte Software (Midlets, KA-NMApps, Discovery-Manager Konfiguration) an das System übergeben werden. Bei der Übergabe von Software wird diese vom System ins Repository geladen und überprüft. Dies verbessert die Performance, weil die Software nicht bei jedem Ladeauftrag neu übertragen werden muss. Initiale Befüllung von Software, Update und Löschen
Erweitert -
Wird erweitert durch -
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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 43 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 44 von 98 März 2011
6.2.3. Übergabe von SD-Positivliste act Activ ity
Übergabe v on SE-Positiv liste
Übergabe von
SE-Positivliste
- start
Prüfen ob AH
Berechtigung hat über das
System Abfrage zu starten
Prüfe KVP
Übergabeparameter und
Voraussetzungen
Überprüfe empfangene
Positiv liste
Positivliste
OK?
«datastore»
Speichere
Positiv liste
Melde AH
Positivliste nicht
gepseichert
Melde AH:
Positivliste
gespeichert
Empfang
Positivliste
ErfolgFehler
[Nein]
[Ja]
Abbildung 13: Übergabe von SE-Positivliste
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 45 von 98 März 2011
Ü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 -
Wird erweitert durch -
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 46 von 98 März 2011
6.2.4. Laden des KA Handsetservices act KA NM Handsetserv ice laden
Laden des KA NM Handsetserv ices
Verbindung zum Secure
Element aufbauen
NmApp laden
Erfolg
Handy geeignet?
Daten
ok?
SE
erreichbar?
NmApp geladen?
KA NM Konfiguration
KA NM
Handsetservice
geladen?
Fehler
Laden KA NM
services- Start
Prüfe KVP
Übergabeparameter und
Voraussetzungen
Prüfen ob KVP Berechtigung
hat über das System Abfrage
zu starten
:Prüfen ob das Handset
mindestens ein
zugelassenes SE enthält
Melde KVP: KA
NM Services
geladen
Melde KVP:
Übertragung
des Secrets
gescheitert
Melde KVP:
Cardlet Laden
gescheitert
Melde KVP:
Daten nicht OK
Melde KVP:
Handy nicht
geeignet
Melde KVP: SE nicht
erreichbar, weitere
Software (wie zB.TSM
Connector) noetig
Zertifikat
anfragen
Zertifikat
empfangen
NM Handset App schon
v orhanden?
Prüfen ob KA
(I)SD
v orhanden
ist
Ist SD vorhanden?
KA SD laden
SD geladen?
NmApp schon
vorhanden?
NmApp info abfrage v om
SE
NmApp version OK?
Update NmApp
KA Handset
App
geladen?
Update Discov ery
Manager
Melde KVP KA
Handset App
laden
gescheitert
Melde KVP; SD
Laden
gescheitert
KVPS
NM Handset App?
Lade NM Handset App Update KA Handset App
Update Discovery Manager OK?Melde KVP:
Update Discovery
Manager
gescheitert
[nein]
[ja]
[KA SD bereits vorhanden][KA SD nicht vorhanden]
[Ja]
[nein]
[nein]
[nein]
[Ja]
[Vorhanden][Nicht vorhanden]
Kunde mit VDV KA NM Service ausstatten
«flow»
Abbildung 14: Laden des KA Handsetservices
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 47 von 98 März 2011
Laden des KA Handsetservices
Zweck Laden des KA Handsetservices auf eine Karte oder Over-The-Air in ein NFC-Handset.
Erweitert -
Wird erweitert durch Prüfen der Voraussetzung Update VDV-KA NM Service
Akteure
KVPS Kunde mit Trägermedium
Kanäle
KVPS-System Verbindung Mobiles Internet System – NFC Handset
Vorbedingung
Software ist im Repository Positivliste mit unterstutzten SE liegt vor
Standardablauf
1. Prüfen ob KVPS berechtigt ist, das Laden zu beauftragen 2. Prüfung der Voraussetzungen 3. KA NM Service wird geladen 4. KA NM Service wird personalisiert (im Sinne von GP, siehe auch Anhang
„Ergänzungen Spezifikation KA NM“) dabei werden die notwendigen Root keys für weitere Konfiguration des NMs geladen
5. KVPS wird über den Lade- und Personalisierungsvorgang benachrichtigt.
Alternativ ablaufe
Wenn keine geeignete Security Domain vorhanden ist, wird diese installiert, damit die KA NM Service geladen werden kann. Folgendes wird geprüft bzgl. einer geeigneten SD:
- KA SD ist vorhanden und kann adressiert werden. (D.h. die Keys für Eröffnung der SD sind vorhanden, damit KA NM LifeCycle Management gemacht werden kann)
- KA SD ist die richtige Version - KVP ist berechtigt, diese KA SD zu benutzen.
Wenn das Security Domain schon vorhanden ist, wird geprüft ob auch die richtige KA-NMApp Version anwesend ist und entsprechend ein Update vorgenommen. Wenn mehrere unterstützte Secure Elements im Handy vorhanden sind, wird folgende Priorität eingehalten:
- Vorher durch der Kunde gewählte SE - SE auf der SIM Karte - Embedded SE - SD Karte - Sticker
Das durch den Kunden vorher gewählte SE wird bei der Anfrage des Ladens der Applikation als Parameter übertragen. Der KVPS kann über Parameter steuern, dass der für das Laden etablierte Kanal offen bleibt, so dass ohne weitere Kundenaktivität die KA-Prozesse „Ausgabe der Applikation“ und/oder „Ausgabe einer Berechtigung“ folgen können.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 48 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 49 von 98 März 2011
6.2.5. Löschen der KA-NM-Handsetservices act Löschen der VDV KA NM Handset-Serv ices
Löschen der VDV KA NM Handset-Serv ices
Voraussetzungen erfüllt?
Lösche KA NM Cardlet(s)
Löschen erfolgreich?
Fehler
Melde KVP:
Cardlet(s) wurden
nicht gelöscht
Melde KVP: Die
Voraussetzungen
sind nicht erfüllt
Melde KVP: KA
NM Services sind
gelöscht
Löschen der VDV KA NM
Handset-Services - Start
Erfolg
:Prüfen der
Voraussetzung
TSM-Connector,
SE, NM Cardlet(s)
Prüfen ob KVP
Berechtigung hat über das
System Abfrage zu starten
Prüfe KVP
Übergabeparameter und
Voraussetzungen
Zertifikat des
Nutzermediums
Cert-PuK-NM
"Revoke"
Zertifikat
zurücknehmen
und sperren
[Ja]
[Nicht erfüllt]
[fehlgeschlagen]
Abbildung 15: Löschen der KA-NM-Handsetservices
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 50 von 98 März 2011
Löschen der KA-NM-Handsetservices
Zweck Das vollständige Löschen eines KA-NM-Handsetservices, inklusive SD, vom SE eines NFC Handset
Erweitert -
Wird erweitert durch Prüfen der Voraussetzung.
Akteure
KVPS Kunde mit Trägermedium
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 51 von 98 März 2011
6.2.6. Sperren/Entsperren des KANM act Sperren/Entsperren des VDV KA NM
Sperren/Entsperren der des VDV KA NM
Fehler
Voraussetzungen
erfüllt?
Sperren KA NM Entsperren KA NM
Sperren oder Entsperren?
Ausgang Sperren erfolgreich? Ausgang Entsperren erfolgreich?
Erfolg
Sperren/Entsperren des VDV KA
NM - Start
:Prüfen der
Voraussetzung
TSM-Connector,
SE, NM Cardlet(s)
Melde KVP:
Voraussetzungen
nicht erfüllt
Melde KVP:
Sperren
gescheitert
Melde KVP: KA
NM gesperrt
Melde KVP:
Entperren
gescheitert
Melde KVP: KA
NM ist entsperrt
Sperren/Entsperren ensprechend der
Mechanismen der GP.
Sperrung des Zugangs zur SD
Prüfen ob KVP
Berechtigung hat über das
System Abfrage zu starten
Prüfe KVP
Übergabeparameter und
Voraussetzungen
[Ja][Ja]
[Nein] [Ja]
[Nein] [Nein]
Abbildung 16: Sperren/Entsperren des KA NM
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 52 von 98 März 2011
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 -
Wird erweitert durch -
Akteure
KVPS Kunde mit Trägermedium
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 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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 53 von 98 März 2011
6.2.7. Update des KA-NM-Handsetservices act Update der VDV KA NM Handset-Serv ices
Update der VDV KA NM Handset-Serv ices
Vorausetzungen
erfüllt?
Löschen KA NM Serv ices
Gelöscht?
Laden KA NM Serv ices
Geladen?
Fehler
Update der
VDV KA NM
Handset
services -
start
:Prüfen der
Voraussetzung
TSM-Connector,
SE, NM Cardlet(s)
Ende
Melde KVP:
Voraussetzungen
nicht OK
Melde KVP: KA NM
Cardlet nicht
gelöscht
Melde KVP: KA NM
cardlet nicht
geladen
Melde KVP: KA NM
Cardlet geladen
Prüfen ob KVP
Berechtigung hat über das
System Abfrage zu starten
Prüfe KVP
Übergabeparameter und
Voraussetzungen
[ja]
[ja]
[nein]
[nein]
[nein]
[ja]
Abbildung 17: Update des KA-NM-Handsetservices
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 54 von 98 März 2011
Update des KA-NM-Handsetservices
Zweck Neue Software ist im System anwesend und muss dem entsprechend durch einen Update der KA NM Handset Service im SE des Trägermediums neu geladen werden. Des Weiteren kann auch der Tausch eines Handsets, der Wechsel des SE oder der MSISDN ein Grund für die Update-Funktion sein.
Erweitert -
Wird erweitert durch KA NM Service löschen KA NM Service Laden
Akteure
KVPS Kunde mit Trägermedium
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, den Update des KA NM Service zu beauftragen 2. Prüfen der Vorrausetzungen 3. VDV-KA NM Service wird gelöscht 4. VDV-KA NM Service wird geladen 5. KVPS wird benachrichtigt über das mittels update neu laden des VDV-KA NM
Service.
Alternativ ablaufe
Alternativ muss ein Update der einzelnen Komponenten möglich sein. Wie Update des KA HandsetApp und KA-NMApps.
Nachbedingung
KA NM Service würde durch Update neu geladen und an KVPS gemeldet
Parameter
- Kunde Endgerät Identifikation z.B. MSISDN - Software Typ - Software ID - Bevorzugte SE - Personalisierung Daten
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 55 von 98 März 2011
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.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 56 von 98 März 2011
AP210 nr Beschreibung Zusammenhang mit „Prufen der Vorraussetzung“
Zusammenhang mit „Übergabe von Software“
Zusammenhang mit „Übergabe von SE-Positivliste“
Zusammenhang mit „Laden der Applikation (auch auf eine Chipkarte)“
Zusammenhang mit „Löschen des KA-NM-Handsetservices“
Zusammenhang mit „Sperren/Entsperren KA-NM-Handsetservices“
Zusammenhang mit „Update des KA-NM-Handsetservices“
ANF01 Das Secure Element (SE) muss die Sicherheitsanforderungen der KA an ein NM erfüllen. Es dürfen durch das System keine KA NMs auf Chiptypen administriert werden, welche diese Sicherheitsanforderung nicht erfüllen.
Eine Whiteliste von KA KG zugelassene SE wird im System geladen und damit kann überprüft werden ob eine SE die Sicherheitsanforderung von KA erfüllt. (Siehe 4 in 6.2.1 und 0)
Die Liste der zertifizierte SE muss in die Übergabe von SE-Positivliste anwendungsfall übertragen und im System gepflegt werden. (Siehe 0)
Die Liste der zertifizierte SE muss in die Übergabe von SE-Positivliste anwendungsfall übertragen und im System gepflegt werden. (Siehe 0)
Die VDV-KA NM Service wird nicht aufgebracht wenn diese Anforderung nicht erfüllt ist.(siehe 6.2.4 Vorbedingung)
Wenn die Voraussetzungen nicht erfüllt werden in 6.2.5 scheitert das löschen direkt.
Wenn die Voraussetzungen nicht erfüllt werden in 6.2.5 scheitert das löschen direkt.-
Wenn die Voraussetzungen nicht erfüllt werden in 6.2.5 scheitert das löschen direkt.-
ANF02 Das SE muss den Global Platform-Standard (Card Specification v2.2) erfüllen.
Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Sieh ANF01 Siehe ANF01
ANF03 Das SE muss die Cardletausprägungen der KA NM Handset-Services aufnehmen können. Die Funktionalität der KA NM Handset-Services muss verfügbar und darf durch die Administration nicht eingeschränkt sein.
Das System bekommt beim laden der Handset Services die benötigte Parameter wie zB. Größe des KA-NMApps. Wenn die technische Ausprägung das erlaubt werden diese Parameter dann benutzt um vor laden der Services dies zu überprüfen. Siehe auch ANF01
Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 57 von 98 März 2011
ANF04 Es darf keine Hardwareausprägung eines SE (SIM-Karte, SD-Karte, Bluetooth-Sticker, embedded Chip, in Leseweite des NFC-Handset befindliche Chipkarte etc.) diskriminiert werden.
Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01 Siehe ANF01
ANF05 Die Spezifikation darf keine Lösung ausschließen, die nur eine Teilmenge von Hardwareausprägungen unterstützt.
Wie in 4.2 und 3.4.2 beschrieben können mehrere Typen und Umgebungen von TSM eingebunden werden sowohl System interne TSM aber auch externe, dies schließt damit keine HW Ausprägungen aus aber macht die komplementär.
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.
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.
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.
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.
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.
Wie in 4.2 und 3.4.2 beschrieben können mehrere Typen und Umgebungen von TSM eingebunden werden sowohl System interne TSM aber auch externe, dies schließt damit keine HW Ausprägungen aus aber macht die komplementär.
ANF06 Eine aufzubringende Applikation soll nach dem Download, unabhängig von dem Vorhandensein weiterer Applikationen, lauffähig sein und ohne weitere Konfiguration durch den Handsetbesitzer angewendet werden können. Dies soll OTA unterstützen. Die Applikationen dürfen sich nach dem Aufbringen nicht ungewollt beeinflussen.
Dies sollte vorher überprüft werden, bzw. die freie Speicher Platz sollte die voraus gesetzte Speicher des VDV –KA NM Service entsprechen. Siehe 6.2.2
Siehe 6.2.2 Siehe 6.2.2 Den „laden der Applikation“ anwendungsfall macht den ersten Schritt des aufbringen der VDV-KA NM Service und Initialisierung davon, danach muss sie noch Konfiguriert werden.
Weitere schritt welche auch ausgeführt wird ist die sogenannte Konfiguration des Discovery Managers. Siehe 6.2.2
- - Den „Update der Applikation“ anwendungsfall macht den ersten Schritt des aufbringen der VDV-KA NM Service, danach muss sie noch Konfiguriert werden.
Siehe 6.2.2
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 58 von 98 März 2011
ANF08 Sollte für die OTA-Funktionalität ein Agent (MIDlet oder andere Technologie) benötigt werden, soll dieser auf allen NFC-fähigen Handsets lauffähig sein.
Unterschiede in Performance und Funktionsumfang soll es dabei nicht geben.
Sind dem Anwender Inhalte anzuzeigen, so soll die Anzeige vollständig und korrekt sein.
Typ des Handsets sollte überprüft werden und demensprechend ein TSM-Connector aufgebracht werden.
Siehe 6.2.1
Generelle und/oder Handset Spezifische Software muss im System geladen und ausgeliefert werden können.
Siehe 6.2.1
Generelle und/oder Handset Spezifische Software muss im System geladen und ausgeliefert werden können.
Siehe 6.2.1
Wen so ein Agent benötigt wird wird diese, bevor der VDV-KA NM Service aufgebracht werden kann, geladen
Siehe 6.2.1
Bevor die VDV-KA NM Service geloescht werden kann muss die sogenannte TSM-Connector vorhanden sein oder aufgebracht werden.
Siehe 6.2.1
Bevor die VDV-KA NM Service gesperrt/entsperrt werden kann muss die sogenannte TSM-Connector vorhanden sein oder aufgebracht werden.
Siehe 6.2.1
Bevor die VDV-KA NM Service aufgebracht werden kann muss die sogenannte TSM-Connector vorhanden sein oder aufgebracht werden.
Siehe 6.2.1
ANF09 Es ist nicht zu gewährleisten, dass es nur eine technische Variante eines KA NM Handset-Services mit gleicher Funktionalität gibt, so muss das System selbständig erkennen, welche Zielplattform vorliegt und welche technische Variante dieses benötigt.
Als Resultat einer Überprüfung ist bekannt welche technische Variante der KA NM Service benötigt wird.
Siehe 6.2.1
Übergabe von Software soll gewährleisten das verschiedenste Handset Services geladen werden können.
Siehe 6.2.1
Übergabe von Software soll gewährleisten das verschiedenste Handset Services geladen werden können.
Siehe 6.2.1
Siehe 6.2.1 Siehe 6.2.1 - Siehe 6.2.1 Bevor eine KA NM Service geladen wird muss erkannt werden welche Technische Variante die Zielplattform ist.
Siehe 6.2.1
ANF14 OTA darf nicht verhindern, dass mit der Applikation sowohl der Card-Emulation-Mode als auch Card-Reader-Mode möglich ist.
Siehe 6.2.1 Siehe 6.2.1 Siehe 6.2.1 Bevor eine KA NM Service geladen wird muss erkannt werden welche Technische Variante die Zielplattform ist.
Siehe 6.2.1
Siehe 6.2.1 Siehe 6.2.1 Den Update des VDV-KA NM Service sollte dies nicht ändern.
Siehe 6.2.1
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 59 von 98 März 2011
ANF15 Die Verwendung des SE auf einem Handset muss ermöglichen, dass bei Vorhandensein der KA NM Applikation im KA NM Handset-Service das Handset im Card-Emulation-Mode die Transaktionszeit eines KA NMs entsprechend der [VDVKA_NM_SPEC] ist.
Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1 Siehe 3.3.1
ANF16 OTA darf nicht verhindern, dass sich das Handset im Card-Emulation-Mode im Battery-Off-Mode und Battery-On-Mode bezüglich der Anwenderinteraktion gleich verhält.
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)
Siehe 6.2.1
Diese spezifische Software muss im System geladen werden können und dementsprechend adressiert mit Hilfe eines unique ID und Versions nummer. (von KVPS und/oder zielplatform)
Siehe 6.2.1
Das Laden der Service ändert dies nicht.
Siehe 6.2.1
Siehe 6.2.1 Siehe 6.2.1 Diese spezifische Software muss im System geladen werden sein und dementsprechend adressiert. (von KVPS und/oder zielplatform)
Siehe 6.2.1
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 60 von 98 März 2011
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 NFC-Handset mit SE darf keine Organisation (z.B. MNOs, MVNOs, Provider und TSM-Anbieter) diskriminieren. Die Schnittstelle muss unabhängig von den TSM-Varianten (single, authorized, delegated) funktionieren.
Siehe 0 Siehe 0 Siehe 0 Siehe 0 Siehe 0 Siehe 0 Siehe 0
ANF32 Gewährleistung von Interoperabilität: Beim Ticketing sollen die Kunden nur ein ÖV-MIDlet (eines KVP) auf dem Handy haben.
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 61 von 98 März 2011
ANF39 Die Prozesse, wie sie zwischen KA Nutzermediumshersteller und KA vereinbart sind (siehe [NUTZERMEDHERERKL]), müssen in das System integriert werden.
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
Zeihe 8.4
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
Zeihe 8.4
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
Zeihe 8.4
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
Zeihe 8.4
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
Zeihe 8.4
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
Zeihe 8.4
KVPS stellt zertifikate zur Verfügung.
Alternativ; Service des Systems, welches dies direkt anfragt..
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 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 Cardspec Kapitel 3.1)
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 62 von 98 März 2011
ANF42 Das KVPS übernimmt die Versionsverwaltung für die KA NM Handset-Services. Der KVP ist dafür verantwortlich, dass die einzelnen Komponenten der KA NM Handset-Services zueinander fachlich und technisch kompatibel sind (Bundle). Durch die unterschiedlichen Handsetausprägungen ist es denkbar, dass insbesondere für MIDlets mehrere Ausprägungen existieren, die fachlich die gleiche Funktion haben.
Das System muss vom KVPS die Komponenten der KA NM Handset-Services, deren Versionen und die Zusammengehörigkeit entgegennehmen können. Das System speichert die Komponenten, so dass diese nur einmalig vom KVPS an das System übertragen werden müssen.
Der KVPS kann das Löschen von Bundles im System durchführen.
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 63 von 98 März 2011
ANF43 Es sind bei einem Laden bzw. bei einem Update nur die Komponenten des KA NM Handset-Services zu administrieren, die in der gewünschten Version nicht auf der Zielplattform vorliegen.
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 64 von 98 März 2011
7.2. Sicherheitsbetrachtung
Die Zielsetzung der vorliegenden Sicherheitsbetrachtung ist die Durchleuchtung möglicher Bedrohungen und Risiken sowie die Ermittlung entsprechender Maßnahmen zur Erreichung eines den Erfordernissen angepassten Sicherheitsniveaus bei der OTA-Provisioning der VDV-Kernapplikation auf NFC-Medien.
Die primären Schutzziele sind
Der Schutz der Vertraulichkeit von persönlichen Kundendaten sowie
die Verhinderung der nichtautorisierten Inanspruchnahme von
Beförderungsleistungen sowie nichtautorisierte Verrechnung solcher Leistungen
zwischen Teilnehmern.
Die Vorgehensweise zur Erstellung der Sicherheitsbetrachtung geschieht im Rahmen dieser Spezifikation in vier Stufen: in der Bestandsaufnahme werden zuerst die zu berücksichtigenden Anwendungsfälle erfasst. Im nächsten Schritt, die Schutzbedarfsanalyse, erfolgt eine Beurteilung der Schutzbedürftigkeit, d.h. der Wichtigkeit, der erfassten Prozesse bzw. Anwendungsfälle in Bezug auf die erklärten primären Schutzziele. Hier werden die sicherheitskritischen Geschäftsprozesse bzw. Anwendungsfälle identifiziert, die in den nachfolgenden Schritten näher untersucht werden müssen. In einer anschließenden Bedrohungsanalyse werden die Gefahren für die sicherheitskritischen Geschäftsprozesse bzw. Anwendungsfälle ermittelt. Im letzten Schritt, werden entsprechenden Sicherheitsmaßnahmen entwickelt und den Bedrohungen gegenübergestellt.
Spezifikationsrelevant sind die im Kap. 7.2.4 definierten Maßnahmen. Alle vorangestellten Betrachtungen in diesem Kapitel dienen lediglich der Nachvollziehbarkeit der entwickelten Maßnahmen.
7.2.1. Bestandsaufnahme Die relevanten Geschäftsprozesse bei der OTA-Provisioning der VDV-Kernapplikation Verwendung auf mobilen Handsets sind:
Prüfen der Voraussetzungen (§6.2.1),
Übergabe von Software (§6.2.2),
Laden des VDV KA NM Handset-Services insbesondere des Cardlet (§6.2.4),
Sperren und Entsperren des VDV KA NM(§6.2.6).
7.2.2. Schutzbedarfsanalyse Zuerst werden hier die Bedeutungen der bereits in der Einleitung zu diesem Kapitel formulierten primären Schutzziele für die einzelnen Teilprozesse erläutert und die Schutzbedürftigkeit hinsichtlich der verschiedenen Sicherheitsziele dargestellt. Zu diesem Zweck wird die in der folgenden Tabelle definierte und im Bereich der Informationssicherheit übliche Kategorisierung von allgemeinen Sicherheitszielen herangezogen.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 65 von 98 März 2011
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 66 von 98 März 2011
Sicherheitsziel Definition
erbracht bzw. eine bestimmte Funktion erfolgreich
durchgeführt wurde)
Anonymität Anonymität ist die Unverknüpfbarkeit zwischen der Identität einer Entität und der von dieser Entität ausgelösten Ereignisse.
Somit gibt es z.B. Sender-Anonymität als Unverknüpfbarkeit zwischen Sender und Nachricht und Empfänger-Anonymität als Unverknüpfbarkeit zwischen Nachricht und Empfänger.
Verfügbarkeit Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen oder IT-Netzen oder auch von Informationen ist vorhanden, wenn diese den Benutzern stets wie gewünscht (z.B. in zugesicherter Form und Qualität in einem zugesicherten Zeitraum) zur Verfügung stehen.
Als Schutzziel formuliert bedeutet dies: Informationen und Betriebsmittel sind vor unbefugter Vorenthaltung zu schützen.
Eindeutigkeit Innerhalb einer definierten Gruppe von Ereignissen bedeutet die Eindeutigkeit von bestimmten, mit diesen Ereignissen assoziierten Informationen, dass aus der Gleichheit zweier dieser Informationen deren Assoziierung mit dem selben Ereignis folgt.
Zusammenhängig-keit oder Lückenlosigkeit
Es wird von der Zusammenhängigkeit oder Lückenlosigkeit einer
Menge von Informationselementen , die bestimmten Ereignissen
zugeordnet sind, gesprochen, wenn eine Parametrisierung (t), t = 1, 2, 3, ... dieser Elemente existiert, so dass aus dem Vorliegen
bestimmter Elemente (n) und (m) mit n<m geschlossen werden
kann, dass alle Elemente (t) mit n<t<m auch bereits erzeugt wurden, und folglich dass assoziierte Ereignisse stattgefunden haben.
Tabelle 1: Kategorisierung von allgemeinen Sicherheitszielen
Hinsichtlich der Schutzbedürftigkeit werden zum betrachteten Anwendungsfall die verschiedenen allgemeinen Sicherheitszielen jeweils bewertet, um diese als wesentlich oder vernachlässigbar für die weitere Betrachtung einzustufen. Eine weiter abgestufte Bewertung ist erst im Rahmen einer spezifischen Umsetzung eines dann vorliegenden Umsetzungskonzepts sinnvoll.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 67 von 98 März 2011
7.2.2.1. Schutzbedarfsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“
Teilprozess: Prüfen der Voraussetzungen
Allgemeine Erläuterung der primären Schutzziele
Der Anwendungsfall beinhaltet die Prüfung der Eignung eines bestimmten Handsets sowie der Zulassung des damit assoziierten SE im Rahmen der Provisioning eines bestimmten Service. Der Ablauf der Prüfung ist wie folgt:
1. Prüfung, ob das KVPS berechtigt ist, über das KA OTA Provisioning-System eine Anfrage zu starten;
2. Beauftragung des KA OTA Provisioning-Systems durch das KVPS die Voraussetzungen von einem bestimmten NFC Handset zu prüfen (Input ist die Handy-Nummer des Nutzer-Handsets);
3. Das KA OTA Provisioning-System überprüft, ob das Handset erreichbar ist;
4. KA OTA Provisioning-System überprüft die Voraussetzung, d.h.
5. ob es sich um ein geeignetes Handset handelt, d.h. ob die Handset-Services für das spezifische Modell verfügbar sind, und
6. ob das SE zugelassen ist, d.h. ob das SE auf der Liste von KA KG zertifizierten SE vorhanden ist.
7. Meldung an das KVPS (mit Details wie Handy-Type, SE Type und OS Version).
Aus Sicht des Nutzers darf seine Handy-Nummer nicht zweckentfremdet werden oder an Organisationen gelangen, die nicht an der Erbringung der Leistung direkt beteiligt sind.
Aus Sicht des KA OTA Provisioning-Systems dürfen nur Anfragen von autorisierten KVPs bearbeitet werden und nur auf eine entsprechend spezifizierte Art und Weise. Ferner sollte gewährleistet werden, dass die vom Handset erhaltenen Informationen tatsächlich dem Zustand im Handset mit der angegebenen Handy-Nummer entsprechen.
Aus Sicht des KVP müssen die vom KA OTA Provisioning-System erhaltenen Informationen tatsächlich dem Zustand im Handset mit der angegebenen Handy-Nummer entsprechen.
Sicherheitsziele Bewertung
Vertraulichkeit
Der vertrauliche Umgang mit den Handy-Nummern der Nutzer durch KVP und KA OTA Provisioning-System.
wesentlich
Anonymität
Die Unverknüpfbarkeit für das KA OTA Provisioning-System zwischen der übermittelten Handy-Nummer und der Identität des Nutzers sowie weiterer nutzerspezifischen Daten wie Berechtigungen, Fahrten etc.
wesentlich
Identifizierung
Aus Sicht des KA OTA Provisioning-Systems muss die Identität eines anfragenden KVP bestätigt werden können.
wesentlich
Eindeutigkeit vernachlässigbar
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 68 von 98 März 2011
Teilprozess: Prüfen der Voraussetzungen
Lückenlosigkeit Vernachlässigbar
Integrität
Die Integrität der Informationen aus dem Handset hin zum KA OTA Provisioning-System bzw. hin zum KVPS.
Wesentlich
Authentizität
Die Authentizität der Informationen aus dem Handset hin zum KA OTA Provisioning-System bzw. hin zum KVPS.
wesentlich
Nichtabstreitbarkeit Vernachlässigbar
Autorisierung
Es dürfen nur autorisierte KVPs eine Prüfung der Voraussetzungen für ein Handset veranlassen.
wesentlich
Zertifizierung
---
vernachlässigbar
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
Allgemeine Erläuterung der primären Schutzziele
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
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 69 von 98 März 2011
Teilprozess: Übergabe von Software
Der vertrauliche Umgang mit dem Code der Software-Komponenten bei der Übertragung vom Lieferanten in das System sowie bei der Speicherung im System.
Anonymität vernachlässigbar
Identifizierung
Sowohl der Lieferant von Software-Komponenten als auch die spezifischen Komponenten müssen identifizierbar sein.
wesentlich
Eindeutigkeit Vernachlässigbar
Lückenlosigkeit Vernachlässigbar
Integrität
Die Integrität der Informationen während der Übertragung vom Lieferant ins System.
Wesentlich
Authentizität
Die Authentizität der Informationen während der Übertragung vom Lieferant ins System.
wesentlich
Nichtabstreitbarkeit Vernachlässigbar
Autorisierung
Es dürfen nur autorisierte Lieferanten Software-Komponenten ins System einbringen.
wesentlich
Zertifizierung
---
vernachlässigbar
Bezeugung / Zeitstempel
---
vernachlässigbar
Verfügbarkeit
---
vernachlässigbar
Tabelle 3: Schutzbedarfsanalyse im Anwendungsfall „Übergabe von Software“
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 70 von 98 März 2011
7.2.2.3. Schutzbedarfsanalyse im Anwendungsfall „Laden, des VDV KA NM Handset-Services (Cardlet)“
Teilprozess: Laden des VDV KA NM Handset-Services (Cardlet)
Allgemeine Erläuterung der primären Schutzziele
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
des Cardlets sowie dessen geheimen Schlüssel bei der Übertragung vom System (TSM und Konfigurator) zum SE hin sowie während des Betriebs im SE.
wesentlich
Anonymität vernachlässigbar
Identifizierung
des KVP sowie des Cardlets.
wesentlich
Eindeutigkeit Vernachlässigbar
Lückenlosigkeit Vernachlässigbar
Integrität
des Cardlets sowie dessen Daten (insbesondere Schlüssel) bei der
Wesentlich
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 71 von 98 März 2011
Teilprozess: Laden des VDV KA NM Handset-Services (Cardlet)
Übertragung vom System (TSM und Konfigurator) zum SE hin sowie während des Betriebs im SE.
Authentizität
der Datenübertragung zwischen dem System (TSM und Konfigurator) und dem SE.
wesentlich
Nichtabstreitbarkeit vernachlässigbar
Autorisierung
des KVP zum Laden des Cardlets.
wesentlich
Zertifizierung vernachlässigbar
Bezeugung / Zeitstempel vernachlässigbar
Verfügbarkeit vernachlässigbar
Tabelle 4: Schutzbedarfsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“
7.2.2.4. Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
Teilprozess: Sperren/Entsperren des VDV KA NM
Allgemeine Erläuterung der primären Schutzziele
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
des anfragenden KVP sowie des Cardlets, dessen Verfügbarkeit gesteuert werden soll.
wesentlich
Eindeutigkeit Vernachlässigbar
Lückenlosigkeit Vernachlässigbar
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 72 von 98 März 2011
Teilprozess: Sperren/Entsperren des VDV KA NM
Integrität
Die Bestätigung der SD, dass sie die angeordnete Zustandsänderung auch übernommen hat
wesentlich
Authentizität
Die Authentizität der Bestätigung durch die SD, über das Handset, das OTA-Provisioning-System bis hin zum KVP
wesentlich
Nichtabstreitbarkeit Vernachlässigbar
Autorisierung
des KVP zum Sperren/Entsperren des Cardlets bzw. des zu sperrenden/entsperrenden Cardlets
wesentlich
Zertifizierung vernachlässigbar
Bezeugung / Zeitstempel vernachlässigbar
Verfügbarkeit vernachlässigbar
Tabelle 5: Schutzbedarfsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
7.2.3. Bedrohungsanalyse In der Bedrohungsanalyse sind Bedrohungen zu erfassen, die eine Gefährdung der Schutzziele zur Folge haben könnten. Jedes Objekt wird hinsichtlich verschiedener Bedrohungen, z.B.
vorsätzliche Manipulation,
höhere Gewalt,
technisches Versagen,
menschliches Versagen,
allgemeine und politisch motivierte Kriminalität sowie
Missbrauch (bei unberechtigtem Zugriff oder Weitergabe an Dritte)
daraufhin untersucht, ob sich hieraus ein konkretes Risiko ergibt.
Aus der Bedrohung eines Schutzzieles leitet sich ein resultierendes Risiko ab. Damit Sicherheitsmaßnahmen zum Erfolg führen, muss eine sorgfältige Risikoanalyse erfolgen. Im Falle einer konkreten Umsetzung des vorliegenden Systemkonzepts mit bekannten Größen (Umsatzzahlen, Nutzer, etc.) kann eine Quantifizierung des Risikos (jeweils als Produkt aus geschätzter Schadenshöhe und Eintrittswahrscheinlichkeit) auf Basis der vorliegenden allgemeinen Sicherheitsbetrachtung aufgebaut werden.
Im Folgenden werden die Zusammenhänge zwischen Bedrohungen und Risiken auf einem dem Konzept entsprechenden allgemeinen Niveau erläutert, so dass die Kritikalität der Bedrohungen qualitativ erfasst und eine Grundlage für weitergehende, quantitative Betrachtungen spezifischer Umsetzungen geschaffen wird.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 73 von 98 März 2011
7.2.3.1. Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
Prüfen der Voraussetzungen
1 Vertraulichkeit
Ausspähen von Handy-Nummern während der Übertragung zwischen KVPS und KA OTA Provisioning-System bzw. nichtautorisierter Zugriff auf diese Daten im KVPS oder KA OTA Provisioning-System.
Es sind hohe, schwer abschätzbare Image-Schäden in der Öffentlichkeit möglich, die indirekt auch zu Einnahme-verlusten führen können. Das Bekanntwerden von Handy-Nummern auch ohne weitere Verknüpfung zu Personen ist kritisch zu sehen. Daher wird diese Bedrohung als allgemein kritisch angesehen.
Eine eventuelle Aggregation dieser Daten im KVPS oder KA OTA Provisioning-System stellt ein erhöhtes Schadenpotential dar.
2 Anonymität
Nichtautorisierter Zugriff auf Datenbestände im KVPS bzw. KA OTA Provisioning-System, um eine direkte Verknüpfung der Identitäten von Einzelpersonen mit deren Handy-Nummern zu ermöglichen.
Es sind hohe, schwer abschätzbare Image-Schäden in der Öffentlichkeit möglich, die indirekt auch zu Einnahme-verlusten führen können. Durch das mögliche Bekanntwerden von persönlichen Daten in Verbindung mit den Handy-Nummern, und da es sich ggf. um aggregierte Datenmengen handelt, ist das Schadenspotential in diesem Fall noch höher als in Nr.1. Daher wird diese Bedrohung als allgemein sehr kritisch angesehen.
3 Identifizierung
Kann das KA OTA Provisioning-System den anfragenden KVP nicht identifizieren, so kann das System „Denial-of-Service“-Angiffe ausgesetzt werden bzw. können Anfragen von nicht autorisierten Organisationen nicht erkannt werden.
Hierdurch kann es zu Störungen im Betriebsablauf kommen.
4 Integrität Durch Manipulation oder Korrumpierung der Daten an der Schnittstelle zum KA OTA Provisioning-System bzw. zum KVPS kann es zur Installierung von Services auf ein Handset kommen, für die das Handset die Voraussetzungen bzw. die Autorisierung nicht hat.
Hierdurch kann es zu Störungen im Betriebsablauf sowie schädlichen oder nicht funktionsfähigen Installationen kommen.
5 Authentizität
Wenn die Verbindung der Informationen mit einem bestimmten Handset für das KA OTA Provisioning-System nicht feststellbar ist, kann es mittels eines „man-in-the-middle“ Angriffs zum Laden von Handset-Applikationen auf ein
Hierdurch kann es zu Störungen im Betriebsablauf sowie Installieren von Applikationen auf nicht identifizierten Handsets kommen, was auch zu
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 74 von 98 März 2011
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
anderes Handset. finanziellen Verlusten führen kann, sofern die betroffenen Applikationen nicht kostenfrei sind.
6 Autorisierung
Können nicht autorisierte Entitäten Anfragen an das KA OTA Provisioning-System stellen, so können „Denial-of-Service“-Angriffe auf das System gefahren werden.
Hierdurch kann es zu Störungen im Betriebsablauf kommen.
Tabelle 6: Bedrohungsanalyse im Anwendungsfall „Prüfen der Voraussetzungen“
7.2.3.2. Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
Übergabe von Software
1 Vertraulichkeit
Durch das Ausspähen von Software-Komponenten durch Unberechtigte bei der Übertragung zwischen Lieferant (über KVP) und System bzw. aus dem Repository des Systems können verschiedene Bedrohungen entstehen.
Die Analyse der so erhaltenen Software kann z.B. Anhaltspunkte für Angriffe auf das eTicket-System liefern oder es kann zu Produktpiraterie kommen.
Signifikante Systemstörungen, Verluste finanzieller Art seitens der Teilnehmer im eTicket-System und der Lieferanten sind möglich. Daher werden diese Bedrohungen generell als kritisch angesehen.
2 Identifizierung
Sind die Software-Komponenten oder die Software-Lieferanten selbst nicht eindeutig identifizierbar, kann es durch Irrtum oder gezielte Täuschung zur Übergabe und Installierung inkorrekter Software-Komponenten.
Hierdurch kann es zu signifikanten Störungen im Betriebsablauf mit einhergehenden finanziellen Verlusten und Image-Schäden kommen.
3 Integrität Ist die Integrität der an das System übertragenen Daten (Software, Whitelists) nicht gesichert, so können unbeabsichtigte Korrumpierungen oder auch gezielte Änderungen der Daten durch Angreifer nicht zuverlässig erkannt werden. Somit kann es zum Einsatz solcher korrumpierten Software bzw. zur Nutzung einer inkorrekten Whitelist kommen.
Hohe Schäden sind möglich, da große Teile des Systems kompromittiert werden können. Daher werden diese Bedrohungen generell als kritisch angesehen.
4 Authentizität
Ist die Quelle der Daten (Software, Whitelists) bei der Übertragung an das System nicht mit Sicherheit feststellbar, dann kann es ebenfalls durch Irrtum oder gezielte Täuschung zur Übergabe und Installierung inkorrekter Software-Komponenten kommen. Solche Software kann auch Funktionen anbieten die
Da auf dieser Weise u.a. sehr kritische Daten wie geheime Schlüssel aus dem Echt-System heraus gezogen werden können, sind die potentiellen Schäden sehr hoch. Daher werden diese Bedrohungen generell als extrem
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 75 von 98 März 2011
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
nicht erlaubt sind und die die Ausgabe kritischer Daten, z.B. Schlüssel, im Klartext ermöglichen. Siehe auch §7.2.3.3, Nr. 4.
kritisch angesehen.
5 Autorisierung
Kann ein nicht autorisierter Lieferant am System normal teilnehmen, so kann er auf normalem Weg manipulierte Software-Komponenten (mit eingebauten Sicherheitslücken, nicht erlaubten Funktionen oder Fehlfunktionen) einbringen. Die möglichen Auswirkungen sind ähnlich zu Nr.4.
Tabelle 7: Bedrohungsanalyse im Anwendungsfall „Übergabe von Software“
7.2.3.3. Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
„Laden des VDV KA NM Handset-Services (Cardlet)“
1 Vertraulichkeit
Durch das Ausspähen der Cardlet-Software durch Unberechtigte bei der Übertragung bzw. aus dem SE selbst entstehen ähnliche Bedrohungen wie in §7.2.3.2, Nr.1. Ist es aber möglich geheime Schlüssel bei der Übertragung oder aus dem Cardlet auf dem SE auszuspähen, so können „unechte“ Cardlets ins Feld gebracht, die nicht von echten zu unterscheiden sind und mit deren Hilfe beispielsweise Berechtigungsschlüssel kompromittiert werden könnten, so dass man in der Lage wäre, unberechtigterweise auch Berechtigungen auszugeben.
Sehr hohe Schäden sind möglich, da große Teile des Systems wesentlich kompromittiert werden können. Daher werden diese Bedrohungen generell als extrem kritisch angesehen.
2 Identifizierung
Sind die Software-Komponenten oder die anfragenden KVPs nicht eindeutig identifizierbar, kann es durch Irrtum oder gezielte Täuschung zur Übergabe und Installierung der falschen Software-Komponenten aus dem Repository des Systems kommen.
Ist das Cardlet nicht eindeutig identifizierbar, entstehen ähnliche Bedrohungen wie in §7.2.3.2, Nr.2.
Hierdurch kann es zu Störungen im Betriebsablauf, Image.-Schäden sowie finanziellen Schäden für Lieferanten kommen. Daher werden diese Bedrohungen generell als kritisch angesehen.
3 Integrität Ist die Integrität nicht gesichert, so können unbeabsichtigte oder auch gezielte Korrumpierungen des Cardlets oder des Schlüsselmaterials während der Übertragung zum SE bzw. während des Betriebs im SE nicht zuverlässig erkannt werden. Auf dieser Weise können Komponenten funktionsunfähig
Hohe Schäden sind möglich, da große Teile des Systems kompromittiert werden können. Daher werden diese Bedrohungen generell als kritisch angesehen.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 76 von 98 März 2011
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
gemacht. Auch können hierdurch verschiedene „Fault Injection“ Angriffe ermöglicht werden, die die Sicherheit des VDV KA NM stark beinträchtigen.
4 Authentizität
Authentisiert sich das SE (bzw. die SD auf dem SE) beim Laden des Cardlets nicht, so könnte ein Angreifer ein echtes Cardlet und dessen Schlüssel in ein „Rogue SE“ laden lassen. Ein solches Rogue SE könnte mit zusätzlichen, in einem echten SE nicht erlaubten Funktionen ausgestattet werden, so dass z.B. alle von den Echtsystemen an das Cardlet gesendeten Daten inkl. Schlüssel in Klartext ausgegeben werden könnten.
Authentisiert sich das Cardlet beim Laden des Zertifikats nicht, so könnte ein Angreifer das Zertifikat für ein „Rogue Cardlet“ ausstellen lassen, das wiederum die Ausgabe aller empfangenen Daten inkl. Berechtigungs-schlüssel in Klartext ermöglichen würde.
Authentisiert sich das System nicht, so könnten andererseits durch ein „Rogue System“ auch manipulierte Cardlets auf SEs installiert werden, die dann ebenfalls durch zusätzlichen, in einem „echten“ Cardlet nicht erlaubten Funktionen alle durch die Cardlets empfangenen Daten in Klartext ausgeben.
Authentisiert sich der Kunde nicht als Besitzer des angegebenen Handsets, so können sich Angreifer unauthorisiert in den Besitz von Software auf ihrem Handset bringen oder veranlassen, dass Software ungewollt von den Besitzern auf deren Handsets geladen wird.
Da auf dieser Weise u.a. sehr kritische Daten wie geheime Schlüssel aus dem Echt-System heraus gezogen werden können, sind die potentiellen Schäden sehr hoch. Daher werden diese Bedrohungen generell als extrem kritisch angesehen.
5 Autorisierung
Ohne eine Autorisierungsprüfung könnte ein KVP Software aus dem Repository des Systems in Handsets installieren lassen, für die er normalerweise die Erlaubnis nicht hätte.
Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden für Lieferanten kommen. Daher werden diese Bedrohungen generell als kritisch angesehen.
Tabelle 8: Bedrohungsanalyse im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 77 von 98 März 2011
7.2.3.4. Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
Nr. Schutzziel Bedrohung Kritikalität bzgl. Risiko
„Sperren/Entsperren des VDV KA NM “
1 Identifizierung
Ist der anfragende KVP nicht eindeutig identifizierbar, kann es durch Irrtum oder gezielte Täuschung zur unberechtigten Sperrung bzw. zur Freigabe von gesperrten Applikationen kommen.
Ist das Cardlet nicht eindeutig identifizierbar, so kann sich ein Kunde die Freigabe eines gesperrten Cardlets erschleichen.
Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden. Daher werden diese Bedrohungen generell als kritisch angesehen.
2 Integrität Ist nicht gesichert, dass die SD die angeordnete Zustandsänderung übernommen hat, so kann nicht sichergestellt werden, dass schadhaftes Verhalten durch die Sperrung auch eingeschränkt werden kann.
Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden. Daher werden diese Bedrohungen generell als kritisch angesehen.
3 Authentizität
Authentisiert sich das SE (bzw. die SD auf dem SE) beim Sperren/Entsperren des Cardlets nicht, so könnte ein Angreifer ein bereits gesperrtes, anderes Cardlet entsperren lassen und es anschließend unberechtigt benutzen.
Authentisiert sich der KVP nicht, so kann ein Angreifer die Sperrung/Entsperrung beliebiger Applikationen veranlassen.
Authentisiert sich das System nicht gegenüber dem KVP, so ist es möglich, dass ein Angreifer-System die vom KVP veranlasste Applikationssperrung nicht umsetzt und damit der vermeidlich gesperrte Kunde weiterhin Schaden erzeugen kann.
Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden. Daher werden diese Bedrohungen generell als kritisch angesehen.
4 Autorisierung
Ohne eine Autorisierungsprüfung könnte ein KVP die Sperrung/Entsperrung beliebiger Applikationen verlassen, für das er normalerweise die Erlaubnis nicht hätte.
Hierdurch kann es zu Störungen im Betriebsablauf, Image-Schäden sowie finanziellen Schäden. Daher werden diese Bedrohungen generell als kritisch angesehen.
Tabelle 9: Bedrohungsanalyse im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 78 von 98 März 2011
7.2.4. Maßnahmen In einem Maßnahmenplan werden Maßnahmen gegen die bereits erkannten Bedrohungen behandelt.
Ziel der im Maßnahmenplan aufgeführten Maßnahmenauswahl ist es, das zu schützende Objekt/Teilobjekt durch geeignete und angemessene Maßnahmen präventiv so zu gestalten, dass eine Reduzierung des bekannten Risikos erreicht wird. Dabei soll das Risiko möglichst gegen „Null / kein Risiko“ reduziert werden. Maßnahmen können die Schadenshöhe oder Schadenshäufigkeit verringern.
Die Maßnahmenauswahl wird in zwei Kategorien aufgeteilt:
I. Maßnahmen, die im Rahmen dieser Betrachtung zur Erfüllung der Interoperabilität mindestens erfüllt sein müssen. Diese Maßnahmen der Kategorie I sind dadurch gekennzeichnet, dass sie einen Verweis auf ein entsprechendes Kapitel tragen, in denen die Komponenten und die Schnittstellen beschrieben sind bzw. auf die bisher in der Kernapplikation spezifizierten Maßnahmen tragen.
II. Maßnahmen, die als Ausgangspunkt für eine quantitative Betrachtung in einer speziellen (Umsetzungs-)Situation dienen und entsprechend ausgearbeitet werden sollen. Maßnahmen der Kategorie II sind dadurch gekennzeichnet, dass sie keinen Verweis auf eine konkrete Maßnahme haben und deshalb mit „-“ gekennzeichnet sind.
Das Ziel der spezifizierten Maßnahmen in der Kategorie I ist es, Festlegungen im Rahmen der allgemeinen Betrachtung zu machen, die bei der Ausarbeitung eines detaillierten Maßnahmenplans für eine spezielle Umsetzungssituation nicht mehr modifiziert werden müssen, um Restrisiken auf ein akzeptables Niveau reduzieren zu können.
Die allgemeinen Maßnahmen in der Kategorie II dienen als Ausgangspunkt für die Festlegungen weiterer spezifischer Maßnahmen für spezielle Umsetzungssituationen. Für diese Maßnahmen soll dann eine entsprechende Gegenüberstellung des Restrisikos und der (quantifizierbaren) Gesamtkosten erfolgen.
7.2.4.1. Betrachtung von Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“
Nr. Maßnahmen Verweis
Prüfen der Voraussetzungen
1 a. Verschlüsselung der Datenübertragung zwischen KVPS und KA OTA
Provisioning-System . Eine konkrete Lösung könnte z.B. die Erweiterung
der Transaktionsdatenstrukturen im Interoperabilitätsnetzwerk der KA, um
diesen Datenaustausch zu unterstützen und somit auch die dort greifende
Verschlüsselung anzuwenden.
b. Sichere Speicherung der Daten im KVPS und KA OTA Provisioning-
System sowie Beschränkung des internen Zugriffs.
c. Die Verwendung der Daten muss in einer verbindlichen Erklärung mit
dem Kunden vereinbart werden. Daten dürfen ohne Einwilligung des
Kunden weder weiter bekannt gegeben noch für andere Zwecke
-
-
-
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 79 von 98 März 2011
Nr. 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
Provisioning-System werden diese Anforderungen sowohl durch die Anwendung
von „WS Signature“ als auch MACs mit Sessionkeys im Rahmen einer TLS
Authentisierung erfüllt.
An der Schnittstelle zwischen KA OTA Provisioning-System und Handset kann
beispielsweise hier ebenfalls eine TLS Authentisierung oder die
Sicherheitsmechanismen des GSM Standards zur Bildung einer sicheren Session
verwendet werden.
-
[11]
-
5 Bei der Übertragung werden die Daten mit einer Signatur oder einem MAC
gesichert, wobei der MAC auf Basis eines Sessionkeys berechnet wird, der
zwischen dem KA OTA Provisioning-System und dem Handset im Rahmen einer
Authentisierung vereinbart wird. Es muss dabei zugesichert werden, dass das
anschließende Laden einer Applikation auf dasselbe Hansdset geschieht, das auf
die Prüfung der Voraussetzung geantwortet hat.
Diese Anforderung kann mit den Sessionmechanismen des GSM Standards
realisiert werden, wobei das anschließende Laden der Applikation im Rahmen
derselben Authentisierung durchgeführt wird, wie die Prüfung der
-
-
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 80 von 98 März 2011
Nr. 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 Provisioning-
System eine Whiteliste, in der die autorisierten Organisationen aufgeführt sind
(siehe auch Anwendungsfall „Übergabe von Software“ bzgl. der Übergabe von
Whitelists.
Im Falle der Nutzung eines Zertifikats für die Authentisierung (z.B. im ION der KA)
prüft das KA OTA Provisioning-System die Org.-ID aus dem Zertifikat gegen die
Liste.
-
-
Tabelle 10: Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“
7.2.4.2. Betrachtung von Maßnahmen im Anwendungsfall „Übergabe von Software“
Nr. Maßnahmen Verweis
Übergabe von Software
1 Die Übertragung von Software-Komponenten bzw. Whitelists vom Absender an
das System muss verschlüsselt sein.
Darüber hinaus muss im System ein wirksamer Schutz vor unberechtigten
Zugriffen auf das Repository implementiert sein. Hierzu gehört die Abschottung
durch Firewalls sowie die Umsetzungen eines Berechtigungskonzepts für
Administratoren.
-
-
2 Lieferanten bzw. Hersteller müssen durch die VDV KA KG mit Firmennamen und
Adresse registriert werden und eine eindeutige Org.-ID zugeordnet bekommen,
die in einer entsprechenden Whitelist eingetragen und verteilt werden.
Zertifizierte bzw. zugelassene Software-Komponenten, zertifizierte SE und
zugelassene Handsets müssen ebenfalls durch die VDV KA KG registriert werden
und eine eindeutige Identifizierung zugeordnet bekommen, die in entsprechenden
Whitelists eingetragen und verteilt werden.
Die Identifizierung einer Software-Komponente muss Angaben zum Typ der
Software (Midlets, Cardlets, und ggf. TSM Connector), zur Org.-ID des
Lieferanten bzw. Herstellers, zur Spezifikationsversion, zur Release und ggf. zur
Gültigkeit enthalten.
Die Identifizierung eines SE muss Angaben zum SE Owner (Org.-ID), zur
Hardware-Kennung des Herstellers sowie den dafür geeigneten Cardlets
enthalten.
Die Identifizierung eines Handsets muss Angaben zur Hardware-Kennung des
KA
KA
KA
KA
KA
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 81 von 98 März 2011
Nr. Maßnahmen Verweis
Herstellers sowie zu geeigneten Software-Komponenten und SE enthalten.
Whitelists müssen mit Angaben
zum Listen-Typ (Listen der Lieferanten, eTicket-Teilnehmer, Software-
Komponenten, Hardware-Komponenten),
zum Erstellungsdatum der Liste mit ggf. laufender Nummer, um die
Eindeutigkeit zu sichern, sowie
zur Gültigkeit der Liste
ausgestattet werden.
KA
3, 4
Die Integrität und Authentizität der Daten (Software und Whitelists) wird durch
eine digitale Signatur geschützt, die vom Absender generiert wird.
[11]
5 Bevor eine Software-Komponente in das Repository aufgenommen wird, prüft das
System, ob diese in der aktuellen Whitelist der Software-Komponenten vorhanden
ist.
-
Tabelle 11: Maßnahmen im Anwendungsfall „Übergabe von Software“
7.2.4.3. Betrachtung von Maßnahmen im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“
Nr. Maßnahmen Verweis
Laden des VDV KA NM Handset-Services (Cardlet)
1 Die Kommunikation zwischen dem System (TSM) und dem SE verwendet
das im Rahmen von GlobalPlatform definierte Secure Messaging. Damit
werden alle Nachrichten mit einem dafür vereinbarten Sessionkey
verschlüsselt. Der Sessionkey wird in einer gegenseitigen Authentisierung
vereinbart. Die Basis dafür sind die Schlüssel des AH in der SD.
Darüber hinaus wird das Schlüsselpaar für das VDV KA NM wird im SE
erzeugt und ausschließlich im SE gespeichert (nicht auslesbar).
Die im Rahmen der Zertifizierung gestellten Anforderungen an der
Beschaffenheit des SE gewährleisten die Vertraulichkeit des Cardlet-Code
sowie der geheimen Schlüssel im SE während der Nutzung.
[10]
[10]
KA Zertifizierung
2 Abgedeckt durch die Maßnahmen in §7.2.4.2, Nr.2. §7.2.4.2, Nr.2
3, 4
Durch die Verwendung der GlobalPlatform Session in Nr.1 werden beide
Seiten in der Kommunikation authentisiert und die Integrität des gesamten
Datenaustauschs wird mit Hilfe eines zweiten, dafür zusätzlich vereinbarten
Sessionkey. Dadurch wird die Integrität und Authentizität beim Laden und
bei der Personalisierung des Cardlets mit dem öffentlichen Root-CA-
[10]
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 82 von 98 März 2011
Nr. Maßnahmen Verweis
Schlüssel der VDV-PKI und dem privaten Konfigurator-Schlüssel
abgedeckt.
Mit Hilfe des mit dem GP Secure Messaging aufgebrachten Konfigurator-Schlüssel wird sich das Cardlet authentisiert und ein Sessionkey vereinbart, auf dessen Basis dann die Integrität und Authentizität der Nachrichten zur Erzeugung des Schlüsselpaares im SE sowie zur
Ausstellung und Einbringung des Zertifikats gesichert werden.
Die im Rahmen der Zertifizierung gestellten Anforderungen an der
Beschaffenheit des SE gewährleisten die Integrität sämtlicher Daten im SE
während der Nutzung.
[10]
KA
Zertifizierung
5 In den Whitelisten für eTicket-Teilnehmer müssen zusätzlich zu Org.-ID,
Organisationsnamen und Organisationsrolle (z.B. KVP), auch die
Identifikationen aller Software-Komponenten angegeben werden, die der
Teilnehmer über das System anfordern darf.
§7.2.4.2, Nr.2
Tabelle 12: Maßnahmen im Anwendungsfall „Laden des VDV KA NM Handset-Services (Cardlet)“
7.2.4.4. Betrachtung von Maßnahmen im Anwendungsfall „Sperren/Entsperren des VDV KA NM“
Nr. Maßnahmen Verweis
Sperren/Entsperren des VDV KA NM
1 Abgedeckt durch die Maßnahmen in §7.2.4.2, Nr.2. §7.2.4.2,
Nr.2
2, 3
Abgedeckt durch die Maßnahmen in §7.2.4.3, Nr.3/4. §7.2.4.3,
Nr.3/4.
4 Abgedeckt durch die Maßnahmen in §7.2.4.2, Nr.2. §7.2.4.2,
Nr.2
Tabelle 13: Maßnahmen im Anwendungsfall „Prüfen der Voraussetzungen“
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 83 von 98 März 2011
8. Schnittstellen
Dieses Kapitel behandelt die Schnittstellen zwischen den beteiligten Systemen. Es werden die Schnittstellen zwischen KVPS, dem OTA-Provisioning-Hintergrundsystem sowie der Sicherheitsinfrastruktur des Applikationsherausgebers betrachtet.
cmp Schnittstellen des OTA Prov isioning Systems
OTA Provisioning Gesamtsystem
Zertifikatsschnittstelle
NmApp Config
Zertifikatsschnittstelle
AH Trustcenter
Zertifikatsschnittstelle
Auftragsschnittstelle
Softwareuploadschnittstelle
KVP System
AuftragsschnittstelleAuftragsresultatschnittstelle
Softwareuploadschnittstelle
TSM
Handset
Positivl isten SE
AH System
Positivl isten SE
Auftragsresultatschnittstelle
KA Supplymanagement
Auftragsschnittstelle Auftragsresultatschnittstelle
Software Uploadschnittstelle
Positivl isten SE
fordert Kommandos an
Abbildung 18: Schnittstellen zu beteiligten Systemen
Der Vollständigkeit halber werden in der Abbildung auch interne Schnittstellen gezeigt, ausgeprägt und erläutert werden jedoch nur
die Auftragsschnittstelle vom KVPS zum OTA-Provisioning-System über die die in Abschnitt 6 beschriebenen OTA-Prozesse initiiert werden (erläutert in Abschnitt 8.3).
die Software Upload Schnittstelle, über die Software und Handset Positivlisten an das OTA-Provisioning-System übergeben werden (ebenfalls erläutert in Abschnitt 8.3),
und
die Zertifikatsschnittstelle, mit deren Hilfe vom Trustcenter des
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 84 von 98 März 2011
Applikationsherausgebers (AH-Trustcenter) Zertifikate Cert-PuK-NM für die öffentlichen Schlüssel der zu konfigurierenden Medien abgefragt werden.
Neben diesen Schnittstellen gibt es noch eine Schnittstelle zum AH-System, über die der AH dem System Positivlisten mit unterstützen Secure-Elements zur Verfügung stellt. Die Schnittstelle kann als einfacher File Upload (z.B. realisiert als (S)FTP) angesehen werden und wird nicht weiter erläutert.
Zu der internen Schnittstelle zwischen dem OTA-Provisioning-System und dem NFC-Handset sowie den Schnittstellen zwischen den Mobiltelefonkomponenten enthält dieses Kapitel lediglich allgemeine Anmerkungen.
8.1. Schnittstellen zwischen Mobiltelefon-Komponenten Die Schnittstellen zwischen Mobiltelefon-Komponenten werden im Rahmen der vorliegenden Spezifikation nicht weiter detailliert. Es obliegt vielmehr den Secure-Element-TSM, geeignete vorhandene Standards für die Kommunikation mit den entfernten NFC-Handsets und den dort enthaltenen (bzw. verbundenen) Secure-Element zu nutzen.
Darüber hinaus gilt für die in diesem Dokument im Hinblick auf das Secure Element beschriebene Funktionalität und Kommunikationsstrukturen, dass diese im Rahmen der GlobalPlatform v2.2 beschrieben und dort ausreichend spezifiziert sind. Für den Fall einer Applikationskarte auf Basis des JavaCard Standards existiert zusätzlich die ergänzende Java Card API v2.2 der GlobalPlatform.
Im Rahmen der Konfiguration des KA Mediums existiert die Notwendigkeit, durch den KA-NMApp_Konfigurator ISO 7816 basierte Chipkartekommandos an das Medium zu senden. Hierzu können Mechanismen der GlobalPlatform genutzt werden, wobei auch hier der Einsatz anderer Schnittstellen und Verfahren möglich ist. Beispielsweise bietet sich bei der Realisierung der Kommunikationsschicht in Java das im JSR 177 beschriebene SATSA Paket als abstraktere Alternative an.
Die zuletzt genannte Notwendigkeit existiert analog für den Schritt der KA Personalisierung, der vom KA Personalisierer an das OTA-Provisioning-System delegiert werden kann.
8.2. Schnittstelle zwischen OTA-Provisioning-System und NFC-Handset
Sowohl GlobalPlatform als auch VDV KA sehen eine Sicherung der Kommunikation auf Applikationsebene vor, so dass die Integrität der Nachrichten in jedem Fall gewährleistet ist. Da der Datenfluss über die OTA Schnittstelle grundsätzlich mitgehört werden kann, wird dennoch empfohlen die Kommunikation auch auf Protokollebene abzusichern und einen gesicherten Kanal zu verwenden, wie dies beispielsweise durch HTTPS oder SSH gewährleistet wird.
8.3. Schnittstelle zwischen KVPS und OTA-Provisioning-System Über die Auftragsschnittstelle zwischen KVPS und OTA-Provisioning-System werden die in Kapitel 6. beschriebenen Prozesse aktiviert. „Best Practice“ für derartige Schnittstellen stellen SOAP Webservices via http(s) dar, es wird in diesem Dokument jedoch keine konkrete Realisierungsvariante der Schnittstelle gefordert. Vielmehr wird Herstellern hier die Wahlfreiheit gelassen.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 85 von 98 März 2011
Die Kommunikation erfolgt grundsätzlich asynchron nach dem Muster:
Auftragsschnittstelle KVPS OTA-Provisioning-System : Auftrag
… zeitlicher Verzug aufgrund von Prozesszeit oder Wiederholversuchen
OTA- Provisioning –System Auftragsresultatschnittstelle KVPS: Auftragsresultat
Über die maximale Zeitdauer die zwischen Beauftragung und Resultat liegen kann, sowie der Anzahl der ggf. innerhalb dieser Zeitspanne vorzunehmenden Wiederholversuche verständigen sich KVP und OTA-Provisioning-Manager im Vorfeld.
In der folgenden Tabelle sind die zwingend erforderlichen Operationen und Parameter mit ihren Bezeichnungen, ihrer Semantik und ihren Wertebereichen festgehalten. Diese Parameter sind verbindlich und bilden eine Basis für die grundsätzliche Austauschbarkeit der Systeme.
In der Tabelle werden die Parameter differenziert nach den in Kapitel 6 beschriebenen OTA-Prozessen dargestellt. Hierbei ist es unerheblich, ob die Prozesse als Operationen der Schnittstelle oder als Auftragstypen eines generischen Auftrags modelliert werden.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 86 von 98 März 2011
Prü
fen
de
r
Vo
rau
ss
etz
un
ge
n (
6.2
.1)
Üb
erg
ab
e
KA
-NM
-
Ha
nd
se
tse
rvic
es
un
d d
er
Po
sit
ivlis
te H
S (
6.2
.2 u
nd
0)
La
de
n d
er
KA
.NM
-
Ha
nd
se
tse
rvic
es
(6.2
.4)
Lö
sc
hen
de
r K
A.N
M-
Ha
nd
se
tse
rvic
es
(6.2
.5)
Sp
err
en
/En
tsp
err
en
(6
.2.6
) d
er
KA
-NM
-
Ha
ds
ets
erv
ices
Up
da
te d
er
KA
.NM
-
Ha
nd
se
tse
rvic
es
(6
.2.7
)
Organisation_ID X
X
X
X
X
X
MSISDN X X
X
X
X
appInstanz_ID X X
X
X
X
Gültigkeit Start NM X X
Gültigkeit Ende NM X X
Software ID X
Spez. Flags
Art der Software/Artefakt X
Sperren oder Entsperren X
Auszuführende Schritte X X
TXAAUFBER X X
Die Operation Übergabe der KA-NM-Handsetservices / Handset Positivliste ist an der Schnittstelle zur Übergabe der Software vorgesehen, alle anderen Operationen an der Schnittstelle Auftragsschnittstelle.
Die Bedeutung der Felder und deren Definition zeigt die folgende Tabelle.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 87 von 98 März 2011
Parameter Bedeutung Datentyp
Definition / Quelle
appInstanz_ID Instanz ID der auszu-gebenen, zu löschenden oder zu sperrenden Applikation
INT4 Basis Objekt Modell VDV KA
Art der Software / des Artefakt
Art der Einlieferung, dieser bestimmt den Speicherort und die weitere Verwendung im System.
CHAR1 ‘1‘ Ausführbare Datei der KA-NMApp (Cardlet)
‘2‘ Discoverymanager Konfiguration
‘3‘ KVP-HandsetApp
‘4‘ Positivliste für NFC- Handset-Modelle
‘5‘ Secure Element Prioritätenliste.
Auszuführende Schritte
Schalter der den Ablauf des Geschäftsprozesses steuert, dass heißt bis zu welchem Teilprozess das OTA Provisioning durchgeführt werden soll.
CHAR1 ‘L‘ Nur Laden der Applikation
‘C‘ Laden der Applikation und Konfiguration der Applikation
‘P‘ Laden der Applikation, Konfiguration und KA- Personalisierung der Applikation (ggf. mit Ausgabe eines Initialen EFS)
TXAAUFBER
Datensatz vom Typ TXAAUFBER, der die Daten eines initial auszugebenden EFS beinhaltet, der in die KA-NMApp geschrieben werden soll.
TXAAUFBER
Wenn kein EFS geschrieben werden soll, entfällt des Feld oder ist leer.
Das Transaktionsergebnis wird als Nachweis im Typ TXABER rückübergeben.
Im Falle eines Updates wird der Datensatz nur bei der Neuausgabe der KA-NMApp berücksichtigt.
Gültigkeit Start NM
Gewünschtes Startdatum der KA-NMApp
Datum Format MMJJJJ, falls leer heute
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 88 von 98 März 2011
Gültigkeit Ende NM
Gewünschtes Enddatum der KA-NMApp
Datum Format MMJJJJ, falls leer wird das Endedatum aus dem Standardablaufdatum des Zertifikates Cert-PuK-NM abgeleitet (siehe [7])
MSISDN Mobilfunknummer des Handsets
CHAR15
ITU-T Recommend E.164
Organisation_ID Eindeutige Organisations ID des KVP
INT2 Basis Objekt Modell der VDV-Kernapplikation
Secure Element Prioritäten Liste
Reihenfolge in der nach SE in/am Handset gesucht wird.
CHAR20
Komma separierte Liste mit Secure Element Typen, z.B. ‘1,2,3‘
Secure Element Typ
Typ des Secure Elements
CHAR1 ‘0‘ = SE auf (U)SIM,
‘1‘=Embedded SE,
‘2‘=SD Karte,
‘3‘=Anderes externes SE
Software ID Eindeutige ID die den Typ und die Version der Software identifiziert.
CHAR20
frei vergebbar
Sperren oder Entsperren
Flag das den Ablauf des Geschäftsprozesses steuert.
CHAR1 ‘S‘ Sperren oder ‘E‘ Entsperren
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 89 von 98 März 2011
Hierbei sind die Positiv-Listen einfache CSV Textdatei mit den folgenden Inhalten.
Struktur der Positivliste Handset
Anzahl Inhalt Datentyp Definition / Quelle
Beliebig viele
TAC Code (Type Allocation Type)
CHAR8 3GPP TS 23.003 V9.4.0
Struktur der Positivliste Secure Element
Anzahl Inhalt Datentyp Definition / Quelle
Beliebig viele
SE Identifier Siehe 7.4.1 von GP
cardspec 2.2 [ref.1} oder
card recognition data
Das OTA Provisioning System gibt abhängig vom OTA Prozess die in der folgenden Tabelle aufgeführten Rückgaben zurück.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 90 von 98 März 2011
Erfolgsfall Fehlerfall
Prüfen der Voraussetzungen (6.2.1)
OK Handset nicht erreichbar
Handset nicht auf Positiv-Liste
SE nicht auf Positiv-Liste
Sonstiger Fehler
Übergabe Software (6.2.2 und 0)
OK Ungültiges Format/Daten
Schon im System vorhanden
Laden (6.2.4) OK, Cert-PuK-NM der geladenen Applikation, falls diese in dieser Operation konfiguriert wurde
KA-NMApp Laden nicht möglich
appInstanz_ID bereits vergeben
Konfiguration gescheitert
KA Personalisierung gescheitert
Sonstiger Fehler
Löschen (6.2.5) OK, erfolgreich Kein KA-Medium gefunden
appInstanz_ID stimmt nicht überein.
Löschen gescheitert, weil weitere Cardlets existieren.
Löschen gescheitert, sonstiger Fehler
Sperren (6.2.6) OK, erfolgreich Kein KA-Medium gefunden
appInstanz_ID stimmt nicht überein.
Sperrung/Entsperrung gescheitert, sonstiger Fehler
Update der KA Handset Services (6.2.7)
OK, erfolgreich Cert-PuK-NM der geladenen Applikation, falls diese in dieser Operation konfiguriert wurde,
KA-NMApp Laden gescheitert
appInstanz_ID bereits vergeben
Konfiguration gescheitert
KA Personalisierung gescheitert
Sonstiger Fehler
In Analogie zur Lieferlisten Festlegung für Chipkartenhersteller muss das OTA-Provisioning-System im Fall einer erfolgreichen Initialisierung des KA-Mediums das Zertifikat des Cert-PuK-NM an das KVPS zurück liefern. Obwohl die Kommunikation des Auftragsresultat asynchron erfolgt, sollte dies zeitnah passieren (< 19 Minuten), da es möglicherweise bereits
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 91 von 98 März 2011
nach der Medienauslieferung zu einer KA-Personalisierung durch das KVPS kommen soll (oder zu einer anderen OTA KA-Transaktion, z.B. einer EFS-Verkauf). Hierfür muss das Medium bereits im KVPS inventarisiert sein. Aus dem Zertifikat entnimmt das KVP System.
Gültigkeitsende der KA-NMApp
Gültigkeitsende der KA-NMApp
appInstanz_ID (zur Prüfung gegenüber dem beauftragten Wert)
8.4. Schnittstellen zum Sicherheitsmanagement-Dienstleister der VDV-KA KG
Das OTA-Provisioning-System besitzt eine Online-Schnittstelle zum Sicherheits-management-Dienstleister der VDV-KA KG (siehe Abbildung 18, Zertifikatsabruf Schnittstelle). Über die Schnittstelle werden die Nutzermediums-Zertifikate Cert-PuK-NM der VDV-PKI vom Trustcenter des Applikationsherausgeber abgefragt. Die Schnittstelle ist im Dokument Schnittstellenbeschreibung für die Zertifikatsbeantragung [7] ausführlich beschrieben und verfügt über die Operationen.
requestCertificate
revokeCertificate
Mit requestCertificate wird für eine bekannte appInstanz_id bei gekanntem
Gültigkeitszeitraum das Zertifikat für den öffentlichen Schlüssel der KA-NMApp abgefragt. Dies erfolgt im Ablauf des NM-Config Teilprozesses.
Mit revokeCertificate wird beim Löschen der KA-NMApp oder im Fehlerfall des NM-
Config Prozesses ein bereits beantragtes Zertifikat zurückgenommen. An den Lifecycle der Zertifikate sind die Applikations-Lizenzgebühren des AH gekoppelt.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 92 von 98 März 2011
9. Anhang
9.1. Ergänzungen der vorhanden KA-Spezifikationen Einleitung (Siehe [10])
9.2. Übersicht über die TSM-Deploymentmodelle und deren Sicherheits- und Vertragsanforderungen
In dem Whitepaper der GlobalPlatform [GP_NFC] werden die der Deploymentmodelle Simple, Delegated und Dual beschrieben sowie deren Auswirkung auf das Applikation-Management unter Berücksichtigung der SE-Ausprägungen.
Unabhängig vom den unten erläuterten Deploymentmodell kann der SE_Owner immer Secure Domain Bereiche im Secure-Element anlegen und löschen. Dies ist eine Teilmenge des SD-Managements11. Kann der SE_Owner zusätzlich Zugriffe innerhalb der Secure Domain ändern, dann hat er Vollzugriff auf die Secure Domain.
Simple Mode
SE Owner
SE-
TSM
durchführung
anfrage fertig
Delegated Mode
SE Owner
SE-
TSM
fertigErlaubt?
Dual Mode
SE
Owner
SE-
TSM
Durchführung
ja
durchführung
Durchführung
Simple Mode: Hier führt die Rolle SE_Owner das SD-Management sowie das Applikations-Management12 durch. Ein SE_TSM-System beauftragt in diesem Deploymentmodell also den SE_Owner mit dem Applikations-Management. Auch das SD-Management ist in der Hoheit des SE_Owner. Resultate werden an das SE_TSM-System zurückgegeben.
Delegated Mode: Das SE_TSM-System wird mit einer Pre-Authorisierung durch den SE_Owner authorisiert um das Applikations-Management durchzuführen. Das SD-Management kann entweder durch SE_Owner und/oder SE_TSM durchgeführt werden. Damit wird das Applikations-Management an das SE_TSM-System delegiert. Jede
11 SD-Management: Anlegen und Löschen einer SD, Zugriffsberechtigungen auf SD ändern.
12 Applikationsmanagement: Applikationen in SD einbringen oder entfernen.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 93 von 98 März 2011
Durchführung von Applikations-Management muss durch den SE_Owner autorisiert werden. Resultate werden an SE_TSM-System zurück gegeben.
Dual Mode: Der SE_Owner aber auch der SE_TSM sind autorisiert, das Applikations-Management durchzuführen. Das Applikations-Management für den als Secure Domain benannten Teilbereich des Secure Elements ist völlig im SE_TSM-System integriert.
SE auf UICC13 Embedded SE14 External SE (sticker, SD card)15
Simple Höchste Sicherheits- und Vertragsanforderungen, weil der SE_Owner das komplette Applikations-Management durchführt.
Höchste Sicherheits- und Vertragsanforderungen, weil der SE_Owner das komplette Applikations-Management macht.
Normale Sicherheits- und Vertragsanforderungen, weil der SE_Owner (=VDV-KA) die Autorisierung macht und der SE_TSM die Durchführung.
Delegated Normale Sicherheits- und Vertragsanforderungen, weil der SE_Owner die Autorisierung macht und das SE_TSM-System die Durchführung übernimmt.
Normale Sicherheits- und Vertragsanforderungen, weil der SE_Owner die Autorisierung macht und das SE_TSM-System die Durchführung übernimmt.
-
Dual Höchste Sicherheits- und Vertragsanforderungen, weil eine SD benutzt wird, die durch den SE_Owner angelegt und gelöscht werden kann.
Höchste Sicherheits- und Vertragsanforderungen, weil eine SD genutzt wird, die durch den SE_Owner angelegt und gelöscht werden kann.
-
9.3. Exemplarische Realisierung des KA Handset Services Ladens mit Hilfe eines dedizierten TSM-Connectors
In diesem Dokument wird davon ausgegangen, dass der TSM über geeignete Verfahren zur Installation und Initialisierung der KA-NMApp verfügt. Ob die konkrete Realisierung dieser Funktionalität durch Teile der Handset-Firmware oder durch zu installierende Software Komponenten erbracht wird, ist offen gelassen worden.
Dieser Anhang zeigt beispielhaft die Realisierung der TS_Funktionalität durch eine
13 MNO ist SE-Owner
14 Handy Hersteller ist SE-Owner
15 VDV ist SE-Owner
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 94 von 98 März 2011
eigenständige Software Komponente, genannt TSM-Connector. Der TSM-Connector hat die Aufgabe, Befehle des TSM-Zentralsystems zu empfangen und auf dem NFC-Handset zur Ausführung zu bringen, der TSM-Connector kann beispielsweise als MIDlet mit Hilfe der Java Microedition Plattform implementiert wird. Installiert wird das TSM-Connector MIDlet via SMS sowie Mechanismen des mobilen Internets, die den Eingriff des Nutzers in den Prozess erforderlich machen. Ein weiteres Merkmal der TSM-Connector Lösung ist die Authentifizierung des Kunden durch eine in einer SMS enthaltenden PassCode, dadurch ist die Verwendung einer nicht beglaubigten Verbindung zum Laden des TSM-Connectors möglich.
sd TSM-Connector laden
TSM-Connector
Delivery System
Kunde mit Trägermedium
(from Akteure)
Handset
SMS mit passcode und erklarung fuer Kunde()
Zugang zu Midlet-Download (URL)
übermitteln
Akzeptiere midlet
installation?()
Akzeptieren()
Midlet installation
akzeptiert()
midlet request()
midlet
download()
midlet herunter geladen, starten?()
Ok()
Starte
midlet()Passcode
abfragen()
Passcode
eingabe()
Passcode()
Passcode()
Pruefe
passcode()
Kunde authoriziert()
Midlet
aktiviert()Midlet
bereitgestellt()
Abbildung 19: Laden des TSM-Connector MIDlets
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 95 von 98 März 2011
In dem in Abbildung 19: Laden des TSM-Connector MIDlets gezeigten Sequenzdiagram ist das Laden eines TSM-Connector MIDlets abgebildet. Damit das TSM-Zentralsystem prüfen kann, ob die Download-Anfrage des MIDlets wirklich vom Kunden stammt, der das KVPS beauftragt hat, wird zunächst eine SMS mit einem PassCode an die MSISDN des NFC-Handsets geschickt.
Dieser PassCode muss dann vom Kunden nach dem Herunterladen und vor der Installation und dem Starten des MIDlets eingegeben werden. Damit wird der Kreis, System, Kunde und Handset geschlossen und der TSM-Connector kann frei geschaltet werden.
sd Cardlet laden
KA OTA Provisioning
System
Kunde
(from Rollen)
TSM ConnectorSecure Element
Voraussetzung: Midlet zum Laden eines
Cardlets (TSM-Connector) muss auf dem
Handset vorhanden sein.
Funktion kann Bestandteil eines KA
Handsetservices sein oder ein unabhängiges
Wallet
Midlet nur notwendig, wenn keine andere
Variante wie z.B. BIP möglich
TSM-Agent kann auch
mit einmaliger
Einwill igung des
Kunden von selbst
ohne Bestätigung des
Kunden gestartet
werden (ist allerdings
Handsetabhängig)
Authentisierung und
Erzeugung eines
sicheren Kanals
ist das SE und noch
nicht der VDV KA
Handsetservice
Bereitschaft mitteilen
Starte Kommunikation vom
midlet()
Starte midlet ok?()
Midlet starten()
OK()
Authentizierung()
authentizierung()
Abfrage SE management
commandset()
Cardlet lade kommandos()
meldungen lade vorgang()
Kommunikations ende()
Abbildung 20: Cardlet Laden Sequenzdiagramm
In dem oben abgebildeten Sequenzdiagramm wird das Laden des KA-NmApp Cardlets erläutert. Bevor die Verbindung zwischen KA-OTA-Provisioning-System und dem Secure-Element im Trägermedium aufgebaut werden kann, muss der TSM-Connector vorhanden sein, oder geladen werden (siehe Abbildung 10: TSM-Connector Laden). Dieser ermöglicht dann die Verbindung zwischen TSM-Funktionalität des Zentralsystems und dem Secure-Element im NFC-Handset. Über die authentisierte Verbindung des TSM-Connectors werden dann die Kommandos zur Einrichtung der KA-SD und zum Laden des Cardlets geschickt.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 96 von 98 März 2011
9.4. Konfigurationsmanagement für KA-NM-Handsetservices Das hier beschriebene Verfahren behandelt die Auflösung von Abhängigkeiten zwischen den verschiedenen Komponenten der KA-NM-Handsetservices und ist somit in der Komponente CM Repository (beschrieben in 5.2) angesiedelt. Es dient der Feststellung von installierbaren Gesamtkonfigurationen und der Bestimmung von verfügbaren Versionen für den Fall der Wiederherstellung fehlender Teilkomponenten.
In der Abbildung 21 ist das Objektmodell des Verfahrens dargestellt. Die zu verteilenden Artefakte des KA-NM-Handsetservices werden als Bundles eingeliefert. Bundles können wieder Bundles enthalten (Komposition), deren Zuordnung geschieht über BundleGroups.
BundleGroups können z.B. KA-NM-Handsetservice, KA-KVP-HandsetApp, KA-NMApp sein. Diese fassen gleichartige Artefakte zusammen, aber auch weitere Unterteilungen wie KA-NMApp_JCOP sowie KA-NMApp_SECCOS sind denkbar. In diesem Fall müsste es dann auch zwei inkludierende KA-NM-Handsetservices geben (Erläuterung weiter unten).
class Bundle Struktur
Bundle
bundleId: int
bundleGroup: int
version: int
selector: int
«enumeration»
Mimetype
text/plain
text/xml
application/zip
Content
BundleGroup:
KA-NM-Handsetservices
NmApp
KV-HandsetApp
Discoverymanager Config
Positvliste zugelassene Handsets
...
Versionsformat:
Major/Minor/Patch
Selector:
attrib1=ModelABC and attrib2=UICC
(Bsp.)
1
content 1
1
mimetype1
0..*
{maxversion <=,
minversion >=}
required
0..*
{maxversion <=,
minversion >=}
optional
Abbildung 21
.
Jedes Bundle besteht aus einem ZIP-Archiv, das ZIP Archiv enthält die Datei MANIFEST.MF, sowie (optional) Nutzdaten eines Artefakts. Die Datei MANIFEST.MF ist eine einfache Textdatei, transportiert die im Modell dargestellten Metainformationen und hat beispielsweise die folgende Struktur:
Bundle-Id: de.otasystem.handsetservices.j2me
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 97 von 98 März 2011
Bundle-Group: de.otasystem.handsetservices
Bundle-Description: KVP-Handsetservices für J2ME Handsets mit JSR 177
Bundle-Version: 1.0.0
Bundle-Selector: OS=javame,
Import-Required-Group-1: de.otasystem.handsetservices.nmapp;minversion="1.2.0"
Import-Required-Group-2: de.kvp.handsetservices.kvpapp;minversion="1.0.0"
Import-Group-3: de.otasystem.handsetservices.tsrconnector.j2me;minversion="1.0.0"
Der Bundle-Selector ist eine einfache Zuweisung von Werten zu Attributnamen, die in einer logischen Bedingung auf Übereinstimmung abgefragt werden können. In obigem Beispiel würde eine Auswertung für J2ME-Handsets zu einem Resultat führen, während bei Handsets ohne J2ME das Bundle keine Anwendung finden würde.
Der Algorithmus zur Auflösung funktioniert folgendermaßen:
Erstinstallation (Laden)
Das OTA-System fragt die aktuelle Gruppe der KA-NM-Handsetservices
de.otasystem.handsetservices an. Zunächst wird das Bundle der entsprechenden
Gruppe mit der höchsten Versionsnummer, auf den der Bundle-Selector passt, bestimmt. Im oben skizzierten Fall handelt es sich um ein zusammengesetztes Bundle ohne eigene Nutzdaten.
Da es sich um ein zusammengesetztes Bundle mit aufzulösenden Referenzen handelt, werden die refernzierten Importe im Repository gesucht. Dabei wird wieder die Vorgabe gemacht, dass die Bundles zur gesuchten Gruppe gehören, die höchsten Versionsnummer des zulässigen Bereichs (>= minversion und <= maxversion) besitzen und den Bundle-Selector erfüllen. Import-Groups ohne das Schlüsselwort Required müssen dabei nicht zwingend auflösbar sein.
Wenn alle erforderlichen Referenzen aufgelöst sind, ist der Prozess beendet und die gefundenen Artefakte werden an den übergeordneten Prozess zur weiteren Verarbeitung gemeldet.
Wiederherstellung (Update)
Im Fall einer Wiederherstellung der KA-NM-Handsetservices gehen bereits installierte (und daher beizubehaltende) Artefakte als zusätzliche Filterbedingung in den oben beschriebenen Auflauf ein. Für den Fall, dass beispielsweise eine KA-NmApp in Version 1.0.0 vorliegt, werden nur Bundles berücksichtigt, die diese Version importieren können.
LuKA LuKA / OTA-Provisioning VDV-Kernapplikation
SPEC_LUKA_OTAPROVSYS_1.0.doc Seite 98 von 98 März 2011
9.5. Literaturverzeichnis
Standard/Spezifikation Beschreibung Referenz
Card Specification Version 2.2 March 2006
GlobalPlatform Card Specification 2.2 1
Java Card™ Off-Card Bytecode Verifier
Java Card™ Off-Card Verifier, White Paper, Sun Microsystems, v1.0, June 2002
2
091125 - AFSCM TECH - LIVBL - Interface Specification - V1.2.doc
INTERFACE SPECIFICATION Between Telecom Operators and NFC Service Providers
3
Doc: EPC 220-08, Version 2.0 October 2010
EPC – GSMA Mobile Contactless Payments Service Management Roles Requirements and Specifications
4
Vereinbarung VDV KA KG NM Hersteller
5
SPEC_PE Beschreibung der Schnittstellen zwischen der Vertriebseinheit (KVP-VE) und der Personalisierungseinheit (KVP-PE) eines KVP-Terminals
6
VDV-PKI Schnittstellenbeschreibung für die Zertifikatsbeantragung, Version 1.3 vom 06.08.08
7
SPEC_AktM Aktionsmanagement - Spezifikation für die Berechtigungsart EFS, Version 1.107
8
GP_NFC GlobalPlatform’s Proposition for NFC Mobile:
Secure Element Management and Messaging., White Paper April 2009
9
SPEC_LUKA_ERW-NM VDV-Kernapplikation
Ergänzung zur NM Spezifikation
10
SPEC_ION VDV-Kernapplikation - Spezifikation des Datenaustausches im interoperablen Netzwerk, V 1.107-1.0.4
11
SPEC_LUKA_NFC VDV-Kernapplikation- Nutzung von NFC-Handsets zum Erwerb von elektronischen Fahrscheinen und zur Teilnahme an CICO-Systemen unter Nutzung von passiver NFC-Verkaufs und –Erfassungsinfrastruktur, V1.0
12