Master- Arbeit - Lehrstuhl für Technische Informatik - Universität ...

Masterarbeit Informatik 

Benutzung von cloud-basierten sicheren Elementen 

für NFC-Smartphone im Fahrzeug-Kontext 

Qinyuan Li 

30.Juni.2013 

Betreuer 

Dr. Bernd Borchert 

Prof. Dr. Klaus Reinhardt 

Hervé Seudié, Robert Bosch GmbH

Qinyuan Li: 

Benutzung von cloud-basierten sicheren Elementen für NFC-Smartphone im Fahrzeug-Kontext 

Masterarbeit Informatik 

Eberhard-Karls-Universität Tübingen 

Bearbeitungszeitraum: Dezember 2012 – Juni 2013 

I

Selbstständigkeitserklärung 

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und nur mit erlaubten 

Hilfsmitteln angefertigt und nicht für weitere Prüfungszwecke verwendet habe. 

Tübingen, den 30. Juni 2013 

Qinyuan Li 

II

III

Sperrvermerk 

Sperrvermerk 

Diese Masterarbeit enthält unternehmensinterne und vertrauliche Informationen der 

Firma Robert Bosch GmbH. Veröffentlichung, Duplizierung und Weitergabe der 

Arbeit, auch in Auszügen, ist grundsätzlich nicht gestattet. Ausnahmen bedürfen der 

schriftlichen Genehmigung der Robert Bosch GmbH. 

Ort, den 30. Juni 2013 

_______________________ 

Unterschrift 

IV

Danksagung 

Danksagung 

An dieser Stelle möchte ich mich zunächst bei all denjenigen bedanken, die mich 

während der Anfertigung dieser Masterarbeit unterstützt und motiviert haben. 

Dieser Dank gilt ganz besonders Herrn Prof. Dr. Reinhardt, Herrn Dr. Borchert und 

Herrn Hervé Seudié, die meine Arbeit und somit auch mich betreut haben. Durch 

stetig kritisches Hinterfragen und konstruktive Kritik gaben sie mir immer wieder 

wertvolle Hinweise. Vielen herzlichen Dank für die Geduld, Zeit und Mühen, die Sie, 

Herr Reinhardt, Herr Borchert und Herr Seudié, in meine Arbeit investiert haben. 

Auch gilt dieser Dank meiner Frau, meinen netten Kolleginnen und Kollegen, die 

mich vor allem die ganze Zeit auch seelisch unterstützt haben. Meinen Eltern möchte 

ich dafür danken, dass sie mich nach wie vor so herzlich unterstützen. 

V

Abstrakt 

Abstrakt 

Mit der heutigen rasanten Entwicklung der IT-Technologie werden NFC-Technologie 

und Cloud Computing zunehmend bekannt. Statt dem Heim-Computer sind 

Smartphones die häufigsten verwendeten Werkzeuge geworden, um Webseiten zu 

besuchen. 

Seit das erste NFC-Handy Nokia 6131 im Jahr 2007 auf Markt gekommen ist, wird 

die NFC-Technologie immer mehr in Smartphones verschiedener Modelle integriert. 

Mit der immer reifer werdenden NFC-Technologie werden auch NFC-Smartphones 

immer beliebter. 

Die zurzeit am meisten diskutierten Anwendungen für NFC-Smartphones sind: NFC 

Payment, E-Ticketing und Zutrittskontrolle. Für all diese Applikationen ist eine 

sogenannte Trusted Execution Environment (TrEE) in Smartphones erforderlich, um 

geheime Daten abzulegen und zu bearbeiten. Die bisherige Lösung einer TrEE ist 

meistens in Form eines Hardware Secure Element realisiert, welche jedoch im 

Hinblick auf Ausführungseffizienz, Speicherkapazität [Kapitel 4.4] und Nutzbarkeit 

eingeschränkt [Kapitel 3.3] ist. 

Das in den letzten Jahren mehr und mehr heiß diskutierte Cloud Computing bietet IT- 

Ressourcen mit einer Flexibilität ohnegleichen. Um die Beschränkungen des 

traditionellen physikalischen Secure Elements aufzulösen, ist man zu der Überlegung 

gekommen das Secure Element in die Cloud zu legen, man spricht hierbei von einem 

cloud-basiertem Secure Element. Ein NFC-Smartphone kombiniert mit einem cloudbasiertem 

Secure Element, bietet ein sicheres Systemmodell beispielsweise für die 

Zutrittskontrolle. 

Das Thema meiner Masterarbeit umfasst die Benutzung von cloud-basierten 

sicheren Elementen für NFC-Smartphones im Fahrzeug-Kontext. 

Die Arbeit besteht aus 7 Kapiteln. Nach dem ersten Kapitel “Einleitung” werden 

zuerst die Grundlagen der jeweiligen Technologien, NFC, das Secure Element im 

Smartphone und Cloud Computing, vorgestellt. Zum Schluss des vierten Kapitels 

VI

Abstrakt 

wird noch über mögliche Vorteile bei der Benutzung von cloud-basierten sicheren 

Elementen gegenüber Hardware-basierten sicheren Elementen für Smartphones 

diskutiert. Im Kapitel 5 wird der Einsatz von NFC-fähigen Smartphone mit cloudbasiertem 

sicherem Element für flexible Zugriffskontrolle vorgestellt und analysiert. 

Anschließend werden, im Kapitel 6, verschiedene Protokolle zur Initialisierung, 

Anmeldung, Token-Vergabe, Authentifizierung, Token-Delegierung und zur 

Deaktivierung vorgestellt. Zum Schluss, im Kapitel 7 wird ein Resümee der Arbeit 

gezogen sowie ein Ausblick auf die weitere Entwicklung gegeben. 

Schlagwörter: NFC, Secure Element / Sichere Element, mobile Sicherheit, Cloud 

Computing, Zugriffskontrolle, Fahrzeugwegfahrsperre. 

VII

Abkürzungsverzeichnis 

Abkürzungsverzeichnis 

NFC Near Field Communication 

SE S Secure Element / Sicheres Element 

RFID 

S D Radio-Frequency Identification 

UI User Interface 

TrEE Trusted Execution Environment 

CS Cloud-basiertes sicheres Element 

SIM Subscriber Identity Module 

IC Integrated circuit/ Integrierte Schaltkreis 

TSM Trusted Service Manager 

ISO International Organisation for Standardization 

IEC International Electrotechnical Commission 

NIST NIST National Institute of Standards and Technology 

IaaS Infrastructure as a Service 

IN 

PaaS Platform as a Service 

I 

SaaS Software as Service 

EaaS 

L 

Everything as a Service 

3G 3. Generation 

LTE Long Term Evolution (vermarktet als 4G) 

OTA Over-The-Air 

OS Operating System 

EMV Europy MasterCard VISA 

ANSI American National Standards Institute 

MULTOS Multi-application smart card operating system 

VIII

Inhaltsverzeichnis 


Sperrvermerk ............................................................................................................... IV 

Danksagung .................................................................................................................. V 

Abstrakt ........................................................................................................................ VI 

Abkürzungsverzeichnis .............................................................................................. VIII 

Inhaltsverzeichnis ........................................................................................................ IX 

1 Einleitung .................................................................................................................. 1 

1.1 Motivation ........................................................................................................... 1 

1.2 Ziele der Arbeit ................................................................................................... 2 

1.3 Verwandte Arbeiten ........................................................................................... 2 

2 NFC in Smartphones ................................................................................................ 4 

2.1 NFC-Technologie ............................................................................................... 4 

2.1.1 RFID-Technologie ...................................................................................... 4 

2.1.2 Smartcard-Technologie .............................................................................. 5 

2.2 Besonderheiten von NFC und Ihre Anwendungen ............................................ 8 

2.2.1 Drei Kommunikations-Modi ........................................................................ 9 

2.2.2 Eigenschaften der NFC Technik .............................................................. 10 

2.2.3 Anwendungen und Vorteile des NFC-fähigen Smartphone ..................... 11 

3 Sichere Elemente (SE) des Smartphones ............................................................. 13 

3.1 Definition und zu erfüllende Funktionen .......................................................... 13 

3.2 SE im Smartphone ........................................................................................... 14 

3.3 Vergleichen der Verschiedenen SE ................................................................. 16 

3.4 Rund um das Secure Element ......................................................................... 17 

4 Cloud Computing .................................................................................................... 20 

4.1 Überblick auf Cloud Computing ....................................................................... 20 

4.1.1 Fünf Eigenschaften ................................................................................... 21 

4.1.2 Cloud-Geschäftsmodelle (Everything as a Service)................................. 21 

IX


4.1.3 Vier Cloud Typen ...................................................................................... 23 

4.2 Sicherheitsanforderungen in Cloud Computing ............................................... 24 

4.3 Cloud Computing – Trend und Entwicklung .................................................... 25 

4.4 Cloud Computing und NFC-Smartphones ....................................................... 26 

4.4.1 Cloud-basiertes SE für Smartphone ......................................................... 27 

4.4.2 Vorteile und Nachteile des cloud-basierten SEs für Smartphones .......... 27 

5 Delegierbares Zutrittskontroll-System für NFC-fähige Smartphones .................... 29 

5.1 Einleitung ......................................................................................................... 29 

5.2 Sicherheitsanalyse ........................................................................................... 31 

5.2.1 Systemmodell mit den cloud-basierten SE .............................................. 31 

5.2.1.1 Erste Überlegung an den Systemanforderungen ............................... 31 

5.2.1.2 Sicherheits- und Gefährdungs-Annahme ........................................... 32 

5.2.1.3 Sicherheitsanforderung und Challenge .............................................. 32 

5.2.2 Authentifizierung mit dem NFC-Smartphone und cloud-basiertem SE .... 32 

5.2.3 Die Sicherheitsanforderungen .................................................................. 35 

5.3 Sicherheitsarchitektur ...................................................................................... 35 

5.4 Smart Token System mit cloud-basierten sicheren Elementen ...................... 37 

5.4.1 Akteure in dem System ............................................................................ 37 

5.4.2 Ökosystem für cloud-basierte SE ............................................................. 38 

6 NFC-Smartphone im Fahrzeug-Kontext ................................................................ 42 

6.1 Smart Keys mit cloud-basierter SE .................................................................. 43 

6.2 Zielsetzungen ................................................................................................... 44 

6.3 Sicherheitsannahmen in dem System ............................................................. 45 

6.4 Gefährdungsmodelle ....................................................................................... 45 

6.5 Komponenten und ihre Funktionen in der Sicherheitsarchitektur ................... 46 

6.6 Protokolle des Systems ................................................................................... 47 

6.6.1 System Initialisierung ................................................................................ 48 

X


6.6.2 Benutzer Registrierung ............................................................................. 48 

6.6.3 Token Erteilung......................................................................................... 50 

6.6.4 Benutzer Authentifizierung ....................................................................... 51 

6.6.5 Token Delegation ..................................................................................... 52 

6.6.6 Authentifizierung von delegiertem Benutzer ............................................ 53 

6.6.7 Widerruf von Benutzer oder Token .......................................................... 53 

7 Zusammenfassung und Ausblick ........................................................................... 54 

Abbildungsverzeichnis ................................................................................................. VI 

Tabelleverzeichnis ...................................................................................................... VII 

Literaturverzeichnis.................................................................................................... VIII 

Anhang ...................................................................................................................... XIII 

Anhang A: Benutzer Registrierung Protokoll ..................................................... XIII 

Anhang B: Token Erteilung Protokoll ................................................................. XIII 

Anhang C: Benutzer Authentifizierung Protokoll ................................................ XIII 

Anhang D: Token Delegation Protokoll .............................................................. XIII 

Erklärung .................................................................................................................. XIV 

XI

1 Einleitung 

1 Einleitung 

1.1 Motivation 

Near Field Communication (NFC) ist eine neue Technologie, ein neues Ökosystem, 

das in den letzten zehn Jahren entstanden ist. Die NFC-Technologie ist eine 

drahtlose Kommunikationstechnik zwischen zwei NFC-Geräten. Die 

Kommunikationsfrequenz liegt bei 13.56 MHz und hat eine kurze Reichweite und 

eine niedrige Bandbreite 1 . Derzeit wird die Integration der NFC-Technologie in 

Smartphone als praktische Lösung betrachtet, da inzwischen nahezu jeder ein 

Smartphone besitzt. Die Kommunikationsmöglichkeiten mit einem NFC-fähigen 

Smartphone sind vielseitig, beispielsweise kann die Kommunikation zwischen zwei 

NFC-Smartphones stattfinden, zwischen einem NFC-Smartphone und einem NFC- 

Reader oder zwischen einem NFC-Smartphone und einem NFC-Tag. Auf Basis der 

vielfältigen Kommunikationsmöglichkeiten lassen sich diversen NFC-Anwendungen 

und Dienstleistungen implementieren, die sind praktisch und erleichtern unser Leben, 

z.B. Mobile Bezahlen, E-Ticketing, Zugangskontrolle, Content-Distribution, smart 

Werbung usw. 

Smartphone-Hersteller wie Samsung, HTC und Sony haben bereits ihre NFC-fähigen 

Smartphones auf den Markt gebracht und auch einige Anwendungen und 

Dienstleistungen auf der Basis von NFC befinden sich bereits im Einsatz. Haben sich 

erst die NFC-fähigen Smartphones verbreitet und werden entsprechende 

kommerzielle Dienste bereitgestellt, werden die Benutzer auch in der Lage sein die 

neue Technologie anzunehmen. 

Eine große Sorge in Bezug auf Anwendungen und Dienstleistungen unter 

Verwendung von NFC-fähigen Smartphones ist die Sicherheit, da, unter gewissen 

Umständen, das Betriebssystem des Smartphones angreifbar ist. Um die 

Sicherheitsprobleme in den Griff zu bekommen werden sogenannte sichere 

Elemente in Smartphones eingesetzt, mit deren Hilfe sicherheitskritische Daten und 

Code getrennt von nicht vertraulichen Host (OS des Smartphones) gespeichert 

werden. 

Die heutzutage am häufigsten eingesetzten sicheren Elemente in NFC-fähigen 

Smartphones sind Hardware-Komponenten, die den typischen Aufbau und 

Funktionsumfang einer Smartcard aufweisen, wie beispielsweise SIM-Karten, 

Integrierte Schaltkreise (IC) oder SD-Karten. 

Für die mögliche Kontrolle über diese sicheren Elemente kommen dabei 

Mobilfunkanbieter, Hardware-Hersteller und Service Provider sowie der Trusted 

Service Manager in Frage.[1] [2] Wenn der Service Provider nicht gleichzeitig dem 

jeweiligen Mobilfunkanbieter oder Hardwarehersteller entspricht so ist ein Abkommen 

zwischen dem Herausgeber der sicheren Elemente und dem Service Provider 

immer notwendig, damit die angebotene Anwendung auf dem SE installiert werden 

1 Derzeitige Datenübertragungsgeschwindigkeiten liegen bei 106, 212 und 424 kbps 

1

1 Einleitung 

kann. Anwendungen, die sich im gleichen SE befinden, sollten sich nicht gegenseitig 

gefährden was den Einsatz des Trusted Service Manager erfordert. 

Ein Nachteil von sicheren Elementen als Hardware-Komponente kommt für den 

Benutzer zum Tragen, wenn dieser seinen Mobilfunkanbieter oder sein Smartphone 

wechselt, da man Anwendungen und Daten aus dem SE nur schwer übertragen 

kann. Von daher fehlt den Hardware-basierten sicheren Elementen eine gewisse 

Verfügbarkeit, Probabilität und Flexibilität. 

Mit der Entwicklung von Cloud Computing [Sehe Kapitel 4], wird über eine neue 

Richtung – Clouds als virtuelle Sichere Elemente zu benutzen gesprochen. Mit Hilfe 

von cloud-basierten Diensten als sicheres Element wird versucht die Probleme von 

Hardware-basierten SE zu beseitigen. 

1.2 Ziele der Arbeit 

In dieser Arbeit geht es darum den Ansatz – cloud-basierter sicherer Elemente für 

NFC-Smartphones im Fahrzeug-Kontext, insbesondere für ein Zutrittskontroll-System 

zu analysieren und evaluieren sowie ein System für diesen Ansatz zu konzipieren 

und Protokolle zu entwerfen. 

1.3 Verwandte Arbeiten 

NFC-fähige Smartphones als Autoschlüssel, proprietäre Lösungen wie [4] [5] 50] 

wurden schon vor langer Zeit angekündigt und die genannten Funktionen klingen 

auch sehr spannend, sind aber bisher auf dem Markt nicht verfügbar. Auch wurden 

bezüglich der Sicherheit bisher keine Details veröffentlicht, so dass man den 

Sicherheitsaspekt dementsprechend nicht nachvollziehen kann. 

Die von [6] [7] vorgestellten Lösungen stellen die Architekturen und Protokolle offen 

dar, jeder kann sich die Details anschauen und seine Sicherheit evaluieren. Die 

Lösung von [6] basiert auf eine Custom Firmware mit Sicherheits-Plugin für NFCfähige 

Android-Smartphones, um somit eine Software-isolierte Trusted Execution 

Environment (TrEE) zu erhalten. Credentials sind in TrEE gespeichert, die ganze 

Lösung ermöglicht eine delegierbare Zutrittskontrolle mit NFC-fähigen Smartphones. 

Die Lösung von [7] ist speziell für eine NFC-fähige Fahrzeug-Wegfahrsperre 

konzipiert, Architektur und Protokolle basieren dabei auf [6] die Credentials sind 

aber auf einem Hardware-isolierten TrEE 2 gespeichert. 

Die Arbeit "Secure Elements für Smartphones" [3] von Markus Lorenz gibt einen 

qualitativen Überblick über die am Markt befindlichen Secure Elements in 

Smartphones dabei werden die verschiedenen Secure Elements verglichen sowie 

2 Realisiert durch sicher SD-Karte von der Firma Giesecke & Devrient 

2

1 Einleitung 

ein Konzept vorgestellt, welches Sicherheit durch die Verwendung von SE und 

sicheren UI auf Smartphones gewährleistet. 

Mit der Entwicklung von Cloud Computing wurde in vielen Studien vorgeschlagen, 

Sicherheits-Services in der Cloud durchzuführen. Auf der einen Seite können 

Aktualisierungen und Verwaltungen der Sicherheitsdienste vereinfacht sowie die 

Rechenleistung erhöht werden, auf der anderen Seite können die rechnerischen 

Kosten für den Service Provider und Kunden verringert werden. Der Service Provider 

kann außerdem flexibel auf den Markt reagieren. Das neue Sicherheits-Produkt wird 

als "Security as a Service" (Sicherheit als Dienst) bezeichnet. Aktuelle Studien 

konzentrieren sich auf das Smartphone als Client, da seine Rechenleistung und 

Speicherkapazität sehr begrenzt ist. Sie beschäftigen sich unter anderem mit Anti- 

Virus Diensten [8] [9] Authentifizierung [10] [44]sowie Sicherheits-Tests. [11] [12] 

Ein weiterer Punkt ist, dass es bei Cloud Computing bzw. Cloud Services 

sicherheitsrelevante Aspekte zu berücksichtigen gilt und Lösungen gefunden werden 

müssen um diese Technologie sicher verwenden zu können. Derzeit arbeiten viele 

Institute und Organisationen engagiert daran. Ein Beispiel dafür ist TClouds. [13] 

3

2 NFC in Smartphones 


Ziel dieses Kapitels ist es ein Überblick von NFC-Technogie zu geben und die 

darunterliegenden Technologien (RFID & Smartcards) kurz zu beschreiben [K. 2.1], 

grundlegende Merkmale und Vorteile von NFC vorzustellen sowie verschiedene 

Anwendungsfälle von NFC-Smartphones zu präsentieren. [K. 2.2] 

2.1 NFC-Technologie 

Near Field Communication (NFC) oder auch Nahfeld-Kommunikation ist eine 

drahtlose Kommunikationstechnologie für kurze Distanzen, welche auf bestehende 

Standards und Technologien wie Radio Frequency Identification (RFID) und 

Smartcards basiert. Sie vereinfacht und sichert die Interaktion zwischen Menschen 

und ubiquitären Systemen. 

2.1.1 RFID-Technologie 

RFID-Technologie (Identifizierung mit Hilfe elektromagnetischer Wellen) 

automatisiert die Identifizierung und Lokalisierung von Gegenständen und 

Lebewesen. Die Entwicklungsgeschichte beginnt bereits in den 1940er Jahren. So 

erfolgte beispielsweise der erste Einsatz von RFID am Ende des zweiten Weltkrieges 

in Form eines Radarsystems zur Freund-Feind-Erkennung. Mittlerweile sind die 

Anwendungen von RFID sehr vielfältig geworden. Die populärsten Anwendungen 

befinden sich zum Beispiel in Systemen zur Lagerverwaltung, Waren- und 

Bestandsmanagement, Diebstahlsicherung sowie in der Zutrittskontrolle. 

Ein typisches RFID-System besteht aus Transponder, Lesegerät und 

Hintergrundsystem. Der Transponder (auch RFID-Tag genannt) ist die Komponente, 

die sich auf einem Produkt oder einem zu identifizierendem Objekt befindet. Er 

besteht in der Regel aus einem integrierten Schaltkreis 3 (IC- integrated circuit) und 

einer Antenne (einer großflächigen Spule). Der IC übernimmt dabei Aufgaben wie 

Datenspeicherung und -verarbeitung, dass Modulieren und Demodulieren eines 

Hochfrequenz-Signals und weitere Funktionen. Die Antenne empfängt und überträgt 

die Signale. Bei Transpondern mit eigener Energiequelle spricht man von aktiven 

Transpondern, anderenfalls spricht man von passiven Transpondern. 

3 Eine einziger Siliziumchip mit Speicher und Mikroprozessor, manchmal auch als "IC-Karte" oder Chipkarte genannt 

4


Abb. 1 Ein typische RFID-System 

Die Basisstation (oft Reader oder Lesegräte genannt) ist die Komponente, welche 

die Daten aus dem Transponder liest und schreibt. Sie besteht aus einem 

Hochfrequenzmodul (Sender und Empfänger), einem Koppelelement (Antenne) zum 

Transponder sowie aus einer Kontrolleinheit (eventuell mit Schnittstelle für 

Hintergrundsystem). 

Wenn sich der Transponder in Reichweite eines RFID-Lesegerätes befindet, wird 

eine Spannung induziert und der IC des Transponders wird aktiviert und im 

Anschluss überprüft der Mikrochip die Berechtigung des Lesegerätes. Hat das RFID- 

Lesegerät die entsprechende Zugriffsberechtigung werden die Daten an das RFID- 

Lesegerät übertragen. Das RFID-Lesegerät gibt dann diese Daten an ein 

übergeordnetes Hintergrundsystem weiter, welches dann die Möglichkeit hat die 

Daten auszuwerten, zu bearbeiten und zu speichern. 

2.1.2 Smartcard-Technologie 

Der Smartcard-Technologie begegnet man in vielen Bereichen der Wirtschaft und 

des öffentlichen Lebens. Sie ist die Basis für viele Anwendungen mit hoher 

Sicherheitsanforderung. Besitzer von Smartcards können ihre sensiblen Daten und 

Anwendungen mit sich führen und auf diese bei Bedarf zugreifen. 

Smartcards werden in Bezug auf den Kommunikations-Mechanismus mit äußeren 

Geräten in zwei Kategorien unterschieden: kontaktbehaftete Smartcards und 

kontaktlose Smartcards. 

Bei kontaktbehafteten Smartcards gibt es keine Möglichkeit diese auszulesen, 

solange sie sich nicht in einem Terminal (Smartcardsleser) befinden. Im Gegensatz 

dazu benötigt die kontaktlose Karte bei der Datenübertragung keinen Einschub im 

Terminal. Sollte eine Karte über beide der obengenannten Schnittstellen verfügen, 

spricht man von einer Hybrid-Karte. 

5


Abb. 2 Smartcards mit und ohne Kontakte [14] 

Im Hinblick auf ihre Fähigkeiten, können Smartcards wiederum in zwei großen 

Gruppen unterteilt werden: Speicher-basierte Smartcards und Mikroprozessorbasierte 

Smartcards. 

Speicher-basierte Smartcards haben nur nicht-programmierbaren Speicher, was sie 

in ihren Fähigkeiten erheblich einschränkt. Smartcards mit eingebettetem 

Mikrocontroller hingegen können Daten mittels On-Card-Funktionen verarbeiten und 

sicherheitsrelevante Vorgänge, wie z.B. gegenseitige Authentifizierung, durchführen. 

Diese Smartcards können intelligent mit einem Lesegerät interagieren und haben ein 

eigenes Betriebssystem 4 . 

Abbildung 3 zeigt die Kategorien der Smartcards. 

Abb. 3 Unterteilung der Smartcards [15] 

4 Bekante Bsp. sind JavaCard OS und MULTOS-Multi-application Operating System 

6


Smartcards sollen den Kriterien des internationalen Standards entsprechen daher 

gibt es eine Reihe von Normen und Spezifikationen 5 , die relevant für die Smartcard- 

Implementierungen sind, darunter befinden sich einige die für die Industriespezifischen 

Anwendungen von Bedeutung sind. 

Der ISO-Norm 7816 ist ein mehrteiliger internationaler Standard für Smartcards, 

welcher die wesentlichen Merkmale von Smartcards vereinheitlicht. Einen Überblick 

der Normen erhält man in Tabelle 1. 

Norme 

ISO 7816 Part 1 














Beschreibung 

Physical Characteristics 

Cards with contacts — Dimensions and location of the contacts 

Cards with contacts — Electrical interface and transmission protocols 

Organization, security and commands for interchange 

Registration of application providers 

Interindustry data elements for interchange 

Interindustry commands for Structured Card Query Language (SCQL) 

Commands for security operations 

Commands for card management 

Electronic signals and answer to reset for synchronous cards 

Personal verification through biometric methods 

Cards with contacts — USB electrical interface and operating procedures 

Commands for application management in multi-application environment 

Cryptographic information application 

Tabelle 1 ISO-Norm 7816 

Eine weitere wichtige internationale Normenreihe speziell für kontaktlose Smartcards 

ist die ISO/IEC‐Norm 14443, in der die physikalischen und datentechnischen 

Eigenschaften der Übertragungsstrecke zwischen kontaktloser Smartcard und einer 

Lesegerät spezifiziert werden. Die ISO‐Norm 14443 für kontaktlose 

Datenübertragung ist kompatibel mit den entsprechenden Teilen der ISO‐Norm 7816, 

damit die Unabhängigkeit oberer Stufen der Norm vom konkreten 

Übertragungsmechanismus geschaffen wird. 

5 Von ISO/IEC Standards, EMV 2000 Specification, American National Standards Institute(ANSI), GlobalPlatform Specifications etc. 

7


ISO Layer 

ISO/IEC 14443-4 

(Übertragungsprotokoll) 

ISO/IEC 14443-3 

(Initialisierung und Antikollision) 

ISO/IEC 14443-2 

(Modulation und Kodierung) 

ISO/IEC 14443-1 

(Physikalische Eigenschaften) 

Tabelle 2 ISO-Norm 14443 

2.2 Besonderheiten von NFC und Ihre Anwendungen 

Near Field Communication (NFC) wurde im Jahr 2002 von NXP Semiconductors 

6 und Sony entwickelt. Im Jahr 2004 wurde das NFC Forum [16] von Unternehmen 

NXP Semiconductors, Sony und Nokia gegründet und hat mittlerweile mehr als 150 

Mitglieder aus unterschiedlichsten Branchen, wie Chiphersteller, SIM-Karten- 

Hersteller, Mobiltelefonhersteller, Banken, Forschungsinstitute, Systemintegratoren, 

usw. Das Forum fokussiert sich darauf, standardbasierte NFC-Spezifikationen zu 

entwickeln, um die NFC-Technologie besser verbreiten zu können. 

Die aus dem NFC-Forum spezifizierte NFC-Technologie basiert auf den Standards 

von RFID und Smartcard und unterscheidet sich nur in geringem Maße auf 

elektromagnetischer Ebene. In den höheren Protokollebenen gibt es allerdings 

deutliche Unterschiede. Trotz dieser Unterschiede ist NFC jedoch abwärtskompatibel 

zu vielen bereits existierenden Systemen. Dies ist besonders vorteilhaft, da sie auf 

eine bereits bestehende Infrastruktur aufgesetzt werden kann. Die Kompatibilität wird 

beim Konzeptdesign berücksichtigt. Im Hinblick auf die Sicherheit und den 

Anwendungsfall (z.B. Bezahlen, den Willen des Benutzers durch aktives Berühren 

(touch) auszudrücken) ist NFC im Vergleich zur RFID aber nur für Übertragungen bis 

zu maximal zehn Zentimeter konzipiert. Die Übertragungshochfrequenz liegt bei 

13,56 MHz, die spezifizierten Übertragungsraten liegen bei 106 Kb/s, 212 Kb/s oder 

424 Kb/s. 

Das NFC-Forum hat eine vollständige NFC-Architektur (siehe Abbildung) durch 

weiterführende Spezifikationen aufgebaut. Der Überblick über diese Architektur ist in 

Abb. 4 dargestellt. 

6 Ehemals Philips Semiconductors 

8


Abb. 4 Überblick über die NFC Forum Architektur [3] 

Das Revolutionäre an NFC gegenüber RFID ist, dass die klare Trennung in 

Lesegerät und Transponder aufgehoben wird. Wie in Kapitel 2.1.1 beschrieben, ist 

bei klassischen RFID-Systemen die Rolle von Lesegerät und Transpondern fest und 

kann nicht geändert werden. Die Daten werden nach einem Frage-Antwort-Prinzip 

zwischen Lesegerät und Transponder ausgetauscht. Die NFC-Einheiten integrieren 

hingegen beide Funktionalitäten – Lesergerät und Transponder (Smartcard) in 

Einem, das heißt, es kann abwechselnd sowohl die Rolle der steuernden 

Komponente als auch die Rolle der gesteuerten Komponente angenommen werden. 

Der Nachrichtenaustausch basiert auf bereits bestehende Standards, wie Norm 

ISO/IEC 14443, welche die Protokolle für Lesegerät und Smartcard festlegen. 

2.2.1 Drei Kommunikations-Modi 

Bei der NFC-Architektur werden drei Kommunikations-Modi unterschieden: NFC- 

Geräte können auf drei verschiedene Arten mit ihrer Gegenstelle kommunizieren. 

-- Reader/Writer Modus (auch Aktiv / Passiv Mode genannt) 

-- Peer-to-Peer Modus 

-- Card Emulation Modus 

9


Abb. 5 Drei Kommunikations-Modi (Graphik adaptiert von [17] ) 

Der Reader/ Writer-Modus erlaubt einem NFC-Gerät mit passiven Transpondern 7 , 

z.B. NFC Forum-Tags (incl. RFID-Transponder) zu kommunizieren. Das NFC-Gerät 

ist in diesem Modus stets aktiv und liefert die Energie für die Interaktion. 

Im Peer-to-Peer-Modus können zwei NFC-Geräte miteinander kommunizieren, d.h. 

beide Geräte sind aktiv und können beliebige Daten, wie Kontaktdaten oder Fotos 

hin- und herschicken. 

Der Card-Emulation-Modus ermöglicht die Kommunikation zwischen einem NFC- 

Gerät und RFID-Lesegeräten. Das NFC-Gerät dient dabei als kontaktlose Smartcard, 

mit welcher man, unter Verwendung einer entsprechend installierten Applikation, die 

Rolle von Bankkarten oder Zugangsausweisen emulieren kann. 

2.2.2 Eigenschaften der NFC Technik 

• Einfachheit: einfache Nutzbarkeit durch installierbare NFC-Anwendung, welche 

dann meist intuitiv bedient werden können – NFC-Gerät an NFC-Gerät und schon 

können Daten ausgetauscht werden 

• Vielseitigkeit: Momentan gibt es nur begrenzte Einsatzmöglichkeiten für NFC, 

jedoch ist der NFC-Standard weltweit genormt und offen und lässt sich in vielen 

Alltags- und Industriesektoren nutzen. 

• Sicherheit: Aufgrund der eingeschränkten Kommunikationsdistanz von nur bis zu 

10 Zentimetern zwischen zwei NFC-Geräten, ist die Datenübertragung weitaus 

sicherer als vergleichsweise via WLAN oder Bluetooth. 

• Energieverbrauch: NFC-Chips verbrauchen wenig Energie und schonen Akku – im 

Card-Emulation-Modus ist sogar keine eigene Energie nötig. 

7 Keine eigene Stromversorgung verfügt 

10


2.2.3 Anwendungen und Vorteile des NFC-fähigen Smartphone 

Die NFC-Technologie ermöglicht den schnellen Austausch von Daten und 

Bedienkommandos zwischen zwei Geräten. Besonders die Integration von heutigen 

Smartphones erleichtert die Echtzeit-Kommunikationen zwischen Menschen und 

ihrer Umgebung und wird mit der Zeit immer populärer und beliebter. Die 

Kombination aus Smartphones und anderen mobilen Geräten gewinnt eine immer 

bedeutendere Rolle, da sie verschiedene Aufgaben in diversen Bereichen 

vereinfacht übernimmt. 

NFC-Smartphones ermöglichen viele intuitive Anwendungsszenarien für kontaktlose 

Transaktionen. 

Beispiele für einige interessante NFC-Smartphone-Anwendungen: 

Bezahlen/Einkaufen ist mit einem NFC-Smartphone in Deutschland derzeit nur 

selten möglich und befindet sich eher in einer Testphase. In naher Zukunft sollte sich 

das jedoch ändern, da sich immer mehr Geschäfte vorsorglich mit NFC-Lesegeräten 

ausstatten. Zum Beispiel rüsten derzeit die Parfümeriekette Douglas sowie die 

Tankstellenkette Aral bundesweit ihre Kassen um. "Kassenterminals, die jetzt 

gefertigt werden, haben mehrheitlich NFC-Technik eingebaut", sagt Ulrich 

Binnebößel, Fachmann für Zahlungssysteme beim Handelsverband HDE. [18] 

Fahrkarten: Ein Touchpoint bietet NFC-Tickets für die Nutzer des Deutsche Bahn 

Touch & Travel Services an. Die Zeit, in der man bei der Deutschen Bahn am 

Schalter oder am Automaten einen Ticket in Papierform erwirbt, könnte bald vorbei 

sein. Ein einfaches Vorhalten eines NFC-Smartphones an einen Touchpoint beim 

jeweiligen Ein- und Aussteigen kann den Bezahlvorgang durch automatisches 

Abbuchen vom Konto in der Zukunft komfortabel und schnell abwickeln [4]. 

Abb. 6 Touchpoint in Berliner S-Bahn Station „Zoologischer Garten.“ [4] 

11


Fitness Trainer: Mit Produkten aus dem Hause A&D kann ein Benutzer bequem 

mittels NFC-fähigem Smartphone, für beispielsweise Trainingszwecke, seinen Puls, 

Blutdruck oder Gewichtsverlauf dokumentieren. Produkte wie z.B. die Waage UC- 

324NFC haben einen integrierten NFC Chip, welcher dann nach der Messung das 

Gewicht sofort an das Smartphone überträgt, sobald der Benutzer dieses an die 

Waage hält. [19] 

NFC Task Launcher: Der NFC Task Launcher erlaubt es mit Hilfe sogenannter 

NFC-Tags (meist in Form von kleinen Aufklebern oder Anhängern) die Einstellungen 

(z.B. Profileinstellungen) eines Smartphones automatisch zu ändern oder Apps zu 

starten, sobald man mit dem Smartphone in die Nähe eines solchen Tags kommt. 

[20] 

Freisprechen: Aufwendige Gerätekopplung oder Code-Abfragen gehören bald der 

Vergangenheit an, wenn mittels NFC-Profiling die Verbindung zwischen einem 

Smartphone und der Freisprecheinrichtung eines Autos per Bluetooth aufgebaut 

werden kann. Einfach ins Auto setzen das NFC-Smartphone an den definierten 

Punkt ("Tag") halten, fertig. [21] 

12

3 Sichere Elemente (SE) des Smartphones 


Wie im letzten Kapitel beschrieben, sind die Anwendungsmöglichkeiten von NFC- 

Smartphones vielfältig. Aber das System von Smartphones und die Kommunikation 

über NFC sind potentiell unsicher [45] [46] [47], daher brauchen sicherheitskritische 

Daten und Anwendungen einen speziellen Schutz – ein sicheres Element. 

Auch wie am Angang schon erwähnt, ist das Ziel der Aufgabe den Ansatz – cloudbasierter 

sicherer Elemente für NFC-Smartphones im Fahrzeug-Kontext zu 

analysieren und zu evaluieren, sowie ein System zu konzipieren. Von daher es ist 

sehr wichtig den Sinn und Zweck von sicheren Elementen zu verstehen und sich mit 

den bestehenden Technologien sicherer Elemente für NFC-Smartphones 

auseinanderzusetzen. 

3.1 Definition und zu erfüllende Funktionen 

Eine einheitliche Definition von sicheren Elementen ist nicht zu finden, denn je nach 

Kontext oder Ansicht können sichere Elemente in verschiedenster Weise verstanden 

werden. 

In der Studie "Secure Elements am Beispiel Google Wallet" [22] heißt es 

beispielsweise: 

"Sicheres Element ist ein vertrauenswürdiges und sicheres Modul, das sicherheitskritische 

Daten speichern und verschiedene Operation sicher durchführen kann." 

Mit dieser Definition kann man Secure Element mit vielen Anwendungsmöglichkeiten 

in Verbindung bringen. In Form von Hardware oder Software, innerhalb oder 

außerhalb der zu schützenden Plattform. Laut einer Idee von Google, möchte man 

einen Ring als Secure Element [23] in Form eines Hardwareschlüssels einsetzen, um 

z.B. das Benutzerpassword eines Google-Online-Accounts zu schützen. In 

Verbindung mit der technischen Weiterentwicklung und Miniaturisierung von 

Hardware, kann man sich vorstellen, ein Secure Element in einem beliebigen Objekt, 

das mit einer Person verbunden ist, zu integrieren und per sicherer kontaktlose 

Schnittstelle mit der zu schützende Plattform zu verbinden. Als weiteren Gedanke 

kann man sich auch vorstellen, dass das Objekt können auch entfernt und virtuelle 

für die Benutzer ist 8 . 

Im Buch "Anwendungen und Technik von NFC (Near Field Communication)" [1] ist 

der Begriff des Secure Elements im Smartphone-Kontext wie folgt beschrieben: 

„Ein Secure Element ist ein Mikrochip, der typischerweise denselben Aufbau und 

Funktionsumfang wie eine Smartcard hat und über eine kontaktbehaftete Schnittstelle mit dem 

NFC‐Steuerbaustein verbunden ist. Das Secure Element wird zum Speichern und Abarbeiten 

8 z.B.Cloud-basiert sichere Elemente 

13


von sicherheitskritischen Daten und Anwendungen eingesetzt und umfasst üblicherweise 

zumindest eine JavaCard.“ 

Diese Definition hat das Secure Element für Smartphones sehr auf eine Hardware 

Komponente eingeschränkt, welche in ein Smartphone verbaut werden kann. 

Abgesehen von der Form und den Funktionen die SEs anbieten, müssen folgende 

Anforderungen gleichermaßen gelten: 

a. Sicherer Speicher für sicherheitskritische Daten 

b. Kryptographische Operationen (Oft mit Hardware-basierter Unterstützung) 

c. Sichere Umgebung zur Ausführung von Programmcode 

3.2 SE im Smartphone 

Nach dem Buch „Anwendungen und Technik von Near Field Communication (NFC)“ 

von Josef Langer und Michael Roland [1] unterscheiden sich aktuelle Sichere 

Elemente für Smartphones in drei Formen: 

 

 

 

Software ohne spezielle Hardware 

fest im Mobiltelefon integrierte Hardware 

austauschbare Hardware 

Software Module (Secure Element) allein im Smartphone, werden meistens als nicht 

ausreichend betrachtet, da die Umgebungen von Smartphones (Host Controller) 

angreifbar sind. Malware könnte unbewusst auf Smartphones installiert werden und 

somit alle Eingabedaten vom Benutzer und lokal gespeicherte Daten ausspäht 

werden, dass bedeutet, dass alle oben genannten Anforderungen [a, b, c] nicht in 

vollem Maße erfüllt werden können. 

Für einen hohen Sicherheitsanspruch, wird üblicherweise ein „isoliertes“ SE 

eingesetzt. Alle sensitiven Daten werden ausschließlich im SE gespeichert und 

darüber hinaus werden ausgehende Daten zunächst, mit Hilfe von kryptographischen 

Maßnahme, im SE verschlüsselt und anschließend weitergeschickt. Damit ist 

gewährleistet, dass nur die gewünschte Gegenseite die verschlüsselten Daten 

empfangen bzw. entschlüsseln und verstehen kann. 

Im Folgenden werden Hardware-basierte SEs innerhalb von Smartphones 

betrachtet. 

Hardware-SEs in Smartphones können in zwei Gruppen unterschieden 

werden: integrierte Hardware und austauschbare Hardware. Die folgende Abbildung 

soll die Beziehungen der Komponenten im Smartphone untereinander verdeutlichen: 

14


Abb. 7 Daten-Path zwischen verschiedene Komponente im Smartphone [24] 

Wie der Autor M. Rolande von [1] in Paper [24] zeigt, gibt es mehrere 

Kommunikationswege zwischen den wichtigen Komponenten im Smartphone. Der 

Application Processor (Host / Basisband Controller) erledigt die meisten Aufgaben 

eines Smartphones. Das SE ist ein Mikrochip, der Sicherheitsfunktionen anbietet und 

eine Smartcard emulieren kann. Der NFC-Controller vermittelt zwischen der HF- 

Schnittstelle (Antenne) und dem Secure Element 

(1) Routen von Befehlen und Daten zwischen dem Anwendungsprozessor und der 

NFC- Schnittstelle. Dieser Pfad wird für Peer-to-Peer-Modus, Lese- / Schreib-Modus 

und als Software- Emulation-Karte verwendet. 

(2) Routen von Befehlen und Daten zwischen dem sicheren Element und dem NFC- 

Controller sowie HF-Schnittstelle (Antenne), sodass ein externes Lesegerät direkt mit 

dem Secure Element kommunizieren kann. Dieser Pfad wird für die sichere Karten- 

Emulation verwendet. 

(3) Es wird eine indirekte und direkte Verbindung zwischen Anwendungsprozessor 

und Secure (4) Element aufgebaut. Diese Verbindung ist für die Kontrolle und die 

Verwaltung des SE wichtig. Verwaltungsdaten und Informationen können über das 

Mobilfunknetz empfangenen und dann auf dem SE abgelegt werden. 

Typischerweise schließen sich (2) und (3) gegenseitig aus. 

15


3.3 Vergleichen der Verschiedenen SE 

Einen detaillierten Vergleich zu den verschiedenen SE erhält man in der Diplomarbeit 

[3] . Die folgende Tabelle aus dieser Arbeit gibt einen entsprechenden Überblick. 

Abb. 8 Vergleich der Secure Elements [3] 

Das Embedded SE hat den großen Vorteil, dass es platzsparend ist, aber es ist fest 

verbaut, was somit bedeutet, dass wenn ein Benutzer sein Smartphone wechselt, er 

nicht einfach die Daten in seinem neuen Smartphone übernehmen kann. Die 

Benutzer müssen dann über entsprechende Ansprechpartner alle Anwendungen und 

Daten des alten SE löschen und im neuen SE seines Smartphones installieren und 

konfigurieren lassen. 

Das SE integriert in einer SIM Karte verwendet den, bei allen Smartphones 

vorhandenen Steckplatz, jedoch unterliegt die SIM-Karte immer der Kontrolle des 

jeweiligen Netzwerkbetreibers. Wechselt der Benutzer den Netzbetreiber, so muss er 

alle seine NFC-Anwendungen von der bisherigen SIM-Karte deaktivieren und 

löschen und anschließend auf die neue SIM-Karte installieren lassen. 

Das SE integriert in einer SD-Karte benötigt einen SD-Kartenslot, welcher aber nicht 

in jedem Smartphone vorhanden ist. Die Secure SD-Karte hat aber den Vorteil, dass 

sie nicht mehr an ein bestimmtes Smartphone oder einen bestimmten 

Netzwerkbetreiber gebunden ist, und im Falle eines Wechsels, ob Smartphone oder 

Netzbetreiber, die Daten konsistent gehalten werden können. 

Der NFC-Sticker [25] , der in der Studien aufgetaut ist, funktioniert wie eine 

eigenständige Bankkarte mit kontaktloser NFC-Schnittstelle und kommuniziert direkt 

16


mit einem POS-Terminal, welches PayPass fähig sind, mit Smartphone arbeitet sie 

aber nicht. 

3.4 Rund um das Secure Element 

NFC-Ökosystem 

Rund um das Secure Element gibt es viele Faktoren bzw. Komponenten, wie z.B. die 

darauf installierte Anwendung, der Benutzer und der Provider des Secure Elementes 

die zusammenspielen und zusammengenommen ein komplexes Ökosystem bilden. 

Um das Ganze zu vereinfachen soll das folgende Model zur Veranschaulichung 

dienen [17] : 

Abb. 9 NFC-Ökosystem 

Der Plattform Provider (Herausgeber des Secure Element) stellt die sicheren 

Elemente her, führt die Initialisierung durch und besitzt einen Master Key zur 

Verwaltung des Secure Elements. Er kann gegeben falls auch eine eigene 

Anwendung auf dem sicheren Element unterbringen und ist dann auch gleichzeitig 

Service Provider. Falls das sichere Element in einer SIM-Karte eingebaut ist, ist der 

Mobilfunkanbieter der Plattform Provider. Ist das sichere Element in einer SD-Karte 

integriert, dann ist der entsprechende SD-Karten-Hersteller der Plattform Provider. Ist 

das sichere Element in das Smartphone fix eingebaut ist der Smartphonehersteller 

der Plattform Provider. Das Smartphone könnte aber auch ein Branding 

(providerspezifische Änderungen) eines bestimmten Mobilfunkanbieters aufweisen, 

in dem Fall ist der Mobilfunkanbieter der Plattform Provider. 

17


Service Provider sind die Firmen, die Anwendungen für das Secure Element 

bereitstellten. Sie müssen mit dem Plattform Provider zusammenarbeiten um die 

Berechtigungen für den Zugriff auf das Secure Element zu bekommen 9 . Jede 

Anwendung hat in einem sicheren Element einen festen zugewiesenen Bereich, in 

welchem nur sie sich befinden darf. Für die Verwaltung von sicheren Elementen und 

dessen Anwendungen ist der sogenannte Trusted Service Manager (TSM) 

zuständig. Die Plattform Provider können ihren eigenen Trusted Service Manager 

haben, oder sie wählen ein Trusted Service Manager aus, Service Provider mit 

eigenem Trusted Service Manager sind in der Praxis aber eher selten. Den Trusted 

Service Manager müssen sich die Sicherheitsprofis zertifizieren lassen. Das hängt 

ganz davon ab, wie das Geschäftsmodell und Fähigkeit der beteiligten Service 

Provider und Plattform Provider ist. 

Der Trusted Service Manager ist das Bindeglied zwischen Plattform Provider, 

Service Provider und dem Benutzer. Der Benutzer besitzt das Smartphone mit 

Secure Element, auf welchem verschiedene Anwendungen installiert werden 

können. Der Trusted Service Manager verwaltet das sichere Element und die darauf 

installierten Anwendungen von Plattform Provider bzw. Service Provider. Darüber 

hinaus könnten Trusted Service Manager auch die Aufgabe der Bereitstellung einer 

Key-Management-Infrastruktur für Plattform und Service Provider übernehmen. 

Als Beispiel-Unternehmen, die einen solchen Trusted Service Manager anbieten sind 

Firmen wie Giesecke & Devrient [26] , Gemalto [27] , Corfire [28] und Bell ID [29] zu 

nennen. 

Over-The-Air Management (OTA) 

Das Sichere Element im Smartphone hat, im Vergleich zur traditionellen Smartcard, 

mehrere Bedienmöglichkeiten und kann sowohl Eingabe als auch Ausgabe des 

Smartphone benutzen. Dadurch ist es möglich, Änderungen von den Anwendungen 

und Daten nachträglich über eine Netzwerkanbindung durchzuführen. Der Benutzer 

muss das Smartphone nicht erst irgendwo hinbringen, alles geht Over-the-Air. 

Das Smartphone verfügt üblicherweise über keine feste IP-Adresse, über welche 

sich ein Backend auf das Smartphone verbinden kann. Deswegen es ist notwendig, 

dass der Verbindungsaufbau vom Smartphone zum Backend erfolgt. Dazu gibt es 

drei verschiedene Mechanismen: 

1. Der Benutzer verwendet das Smartphone um eine Verbindung aufzubauen und 

einen bestimmten Vorgang durchzuführen, beispielsweise ein Update der 

Anwendung auf dem sicheren Element oder die Installation einer Anwendung. 

2. Das Smartphone verbindet sich in regelmäßigen Abständen mit dem Backend, um 

für den Benutzer nach verfügbare Aktualisierungen bzw. Anwendungen zu suchen. 

3. Das Smartphone wird über eine SMS benachrichtigt, dass Änderungen bzw. 

Aktualisierungen auf dem Backend verfügbar sind. Der Benutzer kann dann bei 

9 Es gibt auch sogenannt freie sichere Element, womit man beliebig Anwendung darauf programmieren kann 

18


Bedarf mit dem Smartphone eine Verbindung zum Backend aufbauen und sich die 

gewünschten Daten holen. 

19

4 Cloud Computing 


4.1 Überblick auf Cloud Computing 

Cloud Computing, auf Deutsch: Rechnen in der Wolke. Was ist eigentlich Cloud 

Computing? 

Für Cloud Computing gibt es unterschiedliche Definitionen von verschiedenen 

Instituten: 

„A standardized IT capability (services, software or infrastructure) delivered via internet 

technologies in a pay-per-use, self-service way“, so wird Cloud Computing bezeichnet 

von Forrester Research [30] . 

Die maßgebliche Begriffsbestimmung für Cloud Computing ist von National Institute 

of Standards and Technology (NIST): Cloud computing is a model for enabling 

convenient, on-demand network access to a shared pool of configurable computing resources 

(e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned 

and released with minimal management effort or service provider interaction [31]. 

Die Grundvoraussetzung für Cloud Computing ist ein Netzwerk (z.B. Internet, 

Intranet), welches den Zugriff auf Clouds ermöglicht. Cloud Computing nutzt viele 

Technologien, ermöglichen diverse Geschäftsmodelle, stellt IT-Ressourcen 

dynamisch zur Verfügung und ihre Nutzung nach flexiblen Bezahlmodellen 

abzurechnen. 

Abb. 10 zeigt die Beziehungen zwischen Cloud Nutzer und Cloud Anbieter. 

Abb. 10 Cloud Nutzer und Cloud Anbieter [32] 

20


Gemäß „The NIST Definition of Cloud Computing“ [31], gibt es von Cloud Computing 

„5 Eigenschaften“, „3 Service-Ebenen“ und „4 Cloud-Typen“. 

4.1.1 Fünf Eigenschaften 

1. On-Demand-Selbstbedienung: IT-Ressourcen können von Kunden 

dynamisch und flexibel nach eigenem Bedarf reserviert und freigegeben 

werden. Durch Prozessautomatisierung, kann der Benutzer viele Dinge selbst 

bedienen, ohne den Provider zu kontaktieren. 

2. Broad Netzzugang: Cloud-Services sind generell mit Standard-Mechanismen 

(wie ein Browser, einheitlich API, etc.) über ein Netzwerk (z.B. 

das Internet oder ein Intranet) zu erhalten. Dabei ist eine hohe 

Verbindungsgeschwindigkeit sehr wichtig. Die Clients, der auf den Service 

zugreifen können, sind sehr vielfältig. Beispiele sind Smartphone und Laptops. 

3. Gemeinsame/Schonende Ressourcennutzung: IT-Ressourcen können in 

einem dynamischen „Ressourcen-Pool“ gezogen und geteilt genutzt werden. 

Verschiedene physische und virtuelle Ressourcen können nach 

Kundenwunsch zugeordnet werden. In der Regel haben die Kunden weder 

Kontrolle noch Wissen vom genauen Standort der Ressourcen, aber bei 

Bedarf können sie die Ressource auf abstrakter Ebene (z.B. Land, Region 

oder Rechenzentrum) anfordern. Die Virtualisierung von geteilter Hardware ist 

die zugrundeliegende Technologie. 

4. Elastizität: Die Kunden, haben den Eindruck, dass die Ressourcen in der 

Cloud grenzenlos sind, jederzeit können die angebotenen Dienste schnell und 

flexibel reserviert und wieder freigeben werden, in manchen Fällen, laufen die 

Prozesse automatisch. 

5. Bedarfsorientierte Abrechnung: Nutzer der Clouds müssen nur für die 

tatsächlich verwendete Anzahl von IT-Ressourcen bezahlen. Transparenz für 

Nutzer und Anbieter kann durch Technologien zur Überwachung von 

reservierten IT-Ressourcen und Zugriffen auf diese IT-Ressourcen geschafft 

werden. 

4.1.2 Cloud-Geschäftsmodelle (Everything as a Service) 

„Everything as a Service (XaaS, auch EaaS)“ bedeutet, in der Cloud bereitgestellte 

IT Ressourcen unterschiedlicher Art flexibel und dienstbasiert genutzt werden. Das 

ist ein Ansatz, „alles“ als Service zur Verfügung zu stellen und zu konsumieren. 

Hierbei lassen sich verschiedene Cloud-Geschäftsmodelle gliedern, die nach der Art 

der IT-Ressource benannt sind. 

21


Abb. 11 Cloud-Geschäftsmodellen, IT-Ressourcen und Cloud Stack 

Infrastruktur (Infrastructure as a Service: IaaS) ist die Bereitstellung einer 

skalierbaren IT-Infrastruktur auf IT-Ressourcen (wie z. B. Rechenleistung, 

Datenspeicher, Netze und andere grundlegende Ressourcen) über Netzwerk. Die 

Infrastruktur ist virtualisiert und hochstandardisiert. Aufgrund der Standardisierung 

und Virtualisierung, kann verschiedene Software auf IaaS installiert und konfiguriert 

werden, unabhängig von der zugrundlegenden Hardware. Im Gegensatz zum 

klassischen Kaufen einer Rechnerinfrastruktur, müssen Kunden nicht darum 

kümmern, sie wird lediglich bei Bedarf angemietet. 

Plattform (Platform as a Service: PaaS) PaaS stellt eine dynamische 

Laufzeitumgebung (typischerweise für Webanwendungen) oder 

Entwicklungsumgebung über ein Netzwerk für den Benutzer oder Entwickler bereit. 

Paas stellt für den Benutzer einen geringer administrativen Aufwand dar, d.h. 

Benutzer können ohne Anschaffung der darunterliegenden Hardware und Software 

die gewünscht Laufzeitumgebung oder Entwicklungsumgebung benutzen. PaaS 

bauen auf IaaS auf und können somit ebenfalls skalieren. Aufbauend auf einer PaaS 

können Software as a Service (SaaS) Angebote entstehen. 

Anwendung (Software as a Service: SaaS) beinhaltet sämtliche cloud-basierten 

Software-Anwendungen. Diese Anwendungen sind von verschiedenen Client- 

Geräten zugreifbar. Der Zugriff erfolgt meist über ein Netzwerk per standardisierte 

Schnittstelle und Protokolle. Der Nutzer nutzt nur die Anwendungen, um die 

zugrundliegende Cloud-Infrastruktur kümmert sich der Dienstanbieter. 

22


4.1.3 Vier Cloud Typen 

Nach der physikalischen Betriebsumgebung, der Nutzergruppe der Cloud und dem 

Zugriff auf die Cloud, unterscheidet man folgende vier Cloud-Typen: Public Cloud, 

Private Cloud, Hybrid Cloud und Community Cloud. Davon sind Public Cloud und 

Private Cloud die zwei Urformen. Die anderen Cloud-Typen sind entweder Derivate, 

Kombinationen oder Speziallösungen dieser Grundformen. 

Abb. 12 Arten des Cloud Computing / Deployment Modelle 

Public Cloud: Wie schon der Name sagt, ist eine Public Cloud allgemein 

zugängliche. Die Nutzergruppe ist nicht begrenzt und organisatorisch nicht 

verbunden, sie teilen sich die zugrundeliegende Infrastruktur. Firmen oder 

Privatnutzer können (virtualisierte) IT-Ressourcen in der Public Cloud reservieren 

und nutzen. Sie zahlen dafür auf der Basis von Bedarf und Nutzung. Aber es besteht 

Gefahr, dass die Daten außerhalb ihrer unmittelbaren Kontrolle liegen. 

Private Cloud: Im Gegensatz zur Public Cloud ist die Private Cloud fest für 

bestimmte Firma oder Organisation zugeordnet. Nur von der Firma oder 

Organisation autorisierte Personen haben Zugang zur Private Cloud. Der Zugang zur 

Private Cloud erfolgt in der Regel über ein Virtual Private Network (VPN). Im 

Vergleich zu Public Cloud, haben die Firmen oder Organisationen haben mehr 

Kontrolle auf eigene Daten. Der Nachteil einer Private Cloud ist der, dass die 

zugrundliegende Infrastruktur von der jeweiligen Firma oder Organisation selber 

bereitgestellt werden muss, die meistens eingeschränkte Ressourcen haben. 

Community Cloud: Eine Community Cloud ist die gemeinschaftliche IT-Ressource 

wie bei der "Public Cloud" – jedoch für einen kleineren Nutzerkreis, der sich, meist 

örtlich verteilt, aber ein gemeinsames Anliegen haben. 

Hybrid Cloud: Wie oben beschrieben, Private Cloud und Public Cloud bieten jeweils 

ihre Vor- und Nachteile. Es ist meistens notwendig, Kopplung zwischen internen 

Privaten Clouds und mehreren bzw. verschiedenen Public Clouds sowie traditioneller 

23


IT, um unterschiedliche Anwendungsanforderungen abzudecken. Die Hybrid Cloud 

ist dafür vorhanden, sie wird als eine künftig führende Cloud Computing Form 

gesehen. 

4.2 Sicherheitsanforderungen in Cloud Computing 

Die Gewährleistung der Informationssicherheit nimmt im Rahmen von Cloud 

Computing eine zentrale Rolle ein. Bei Cloud Computing verlieren Nutzer die 

Kontrolle auf Daten und Computing in den Cloud-Servern. Von daher sind 

maßgebliche Sicherheitsmaßnahmen erforderlich, um z.B. die Vertraulichkeit, 

Integrität, Verfügbarkeit der Daten von Nutzern sicherzustellen. 

Bei Sicherheitsbedürfnissen in Cloud Computing sind folgende Punkte zu 

beachten[33] : 

1. Vertraulichkeit: sprich, dass die Daten in Clouds verschlüsselt gespeichert 

oder übertragen werden sollen. Das ist aber mit zusätzlichem Overhead 

verbunden. 

2. Datenintegrität: Die Cloud-basierten Speicherservices, müssen die Integrität 

der gespeicherten Daten gewährleisten. 

3. Zugriffskontrolle: Es muss in Cloud-Computing verhindert werden, dass 

unberechtigte Nutzer auf Ressourcen und Daten zugreifen. Um die 

Berechtigungen der legitimen Nutzer zu kontrollieren, ist eine effektive 

Überprüfung der Zugriffberechtigung des Benutzers erforderlich. 

4. Authentifizierung: Die bestehenden Authentifizierungstechnologien gliedern 

sich in drei Arten: (1) Authentifizierung des Benutzergeheimnisses; (2) 

Authentifizierung der Hardware des Benutzers; (3) Authentifizierung 

biometrischer Charaktere (z.B. Fingerabdruck). Password und X.509 Zertifikat 

basierte Authentifizierung ist eine Authentifizierungsmethode, die sich aktuelle 

breit durchgesetzt hat. 

5. Glaubwürdigkeit: Es handelt sich hierbei um die Glaubwürdigkeit von Cloud 

Services verschiedener Art (IaaS, PaaS, SaaS). Z.B. durch Aufnahme von 

Betriebsinformation und passender Rechenschaftspflicht kann die 

Glaubwürdigkeit erhöht werden. 

6. Firewallsicherheit: Beim Cloud Computing, stellen virtuellen Maschine oft 

Verbindung mit Anderen her. Diese Kommunikationen unterscheiden sich von 

der Verbindung zwischen virtuellen Maschinen untereinander und der 

Verbindung zwischen virtuellen Maschinen und Außen. Die 

Sicherheitskontrolle hierzu kann durch Firewalls realisiert werden, passende 

Konfiguration der Firewalls ist deshalb sehr wichtig. 

24


7. Sicherheit der virtuellen Maschine: Virtualisierung von Rechnen- 

Ressourcen ist die Basis für Cloud Computing. Die virtuelle Maschine nimmt 

herbei eine zentrale Rolle ein, dabei sind zwei Sicherheitsaspekte für 

virtuellen Maschine zu beachten: Zu einem ist es die Sicherheit des 

Aufsichtsverfahrens von virtuellen Maschinen; zum anderen ist es die Image- 

Sicherheit der virtuellen Maschinen. 

Zusätzlich zu den oben gennannten Punkten, sind Gesetzliche Regelungen für 

spezifische Daten ein wichtiger Punkt zur Cloud-Sicherheit. 

4.3 Cloud Computing – Trend und Entwicklung 

Der Hightech-Verband BITKOM in der ITK-Branche hat folgende Umfrage über das 

am häufigste genannte IT-Trendthema des Jahres 2012 gemacht:[34] 

Abb. 13 Die wichtigsten Technologie- und Markttrends aus Sicht der ITK-Unternehmen 2012 

Das Ergebnis zeigt: die wichtigsten Hightech-Themen des Jahres 2012 sind Cloud 

Computing gefolgt von Mobile Applikationen und IT-Sicherheit. Die neue Umfrage im 

Januar 2013 [35] zeigte wieder, dass die drei Themen sehr wichtig sind. 

25


Abb. 14 Die wichtigsten Technologie- und Markttrends aus Sicht der ITK-Unternehmen 2013 

Die obige Umfrageergebnisse sind kein Zufall, sondern spiegeln die wirklichen 

Entwicklungstrends des IT-Bereichs wider. Wenn wir uns mit den Ergebnissen genau 

auseinandersetzen, werden wir feststellen: Es gibt eine enge Beziehung zwischen 

Cloud Computing, Mobile Applikationen und IT-Sicherheit. 

Viele Experten meinen, dass Clouds in der Zukunft die traditionellen IT-Umgebungen 

immer mehr ersetzen werden. Das Smartphone ist mittlerweile das am häufigsten 

genutzte Mittel für den Internetzugang geworden. Freilich sind Smartphones 

leistungsmäßig nicht mit regulären PCs vergleichbar. Wie kann es sich weiter 

entwickeln? – Cloud Computing und mobile Anwendungen zusammenzuführen und 

sich gegenseitig zu ergänzen lassen, während die IT-Sicherheit berücksichtigt wird. 

Allen dies deutet sich an, dass kombinierte Anwendungen von Clouds und 

Smartphones und damit verbundene Sicherheitsprobleme ein wichtiges Thema in der 

Zukunft sind. 

4.4 Cloud Computing und NFC-Smartphones 

In dem Kapitel 3 wurden Secure Element des Smartphones vorgestellt und jeweilige 

Vor- und Nachteile beschrieben. Kurzum, bei allen Varianten der sicheren Elemente 

des Smartphones fehlt die Flexibilität für die sensiblen Daten im SE. Im Gegensatz 

zu dem Flexibilitätsmangel des SE für Smartphones bietet Cloud Computing große 

Elastizität und Flexibilität. 

26


4.4.1 Cloud-basiertes SE für Smartphone 

Eine aktuelle Studienrichtung ist die Cloud als virtuelle sichere Elemente zu 

benutzen. Einige Firmen hat darüber angekündigt: “Inside Secure“[36] „EtherTrust“ 

[37] „SimplyTapp“[38] „Bell ID“[39] . 

Inside Secure’s Chief Innovation Officer Bruno Charrat sagt: “Nothing will be local 

except the user authentication“. 

Der Grundidee dabei ist, dass das physische eingeschränkte Secure-Element des 

Smartphones in die elastischen und flexibel Clouds zu verlagern, somit werden das 

Smartphone und Cloud Computing kombiniert, die platzraubende Daten und rechnen 

aufwendiger Code können in der Cloud gespeichert und ausgeführt werden. Das 

Smartphone soll die Rolle einer „sicheren Antenne“ übernehmen, es zieht die Daten 

sicher nach unten und präsentiert sie auf einem Terminal oder einem kontaktlosen 

Türschloss. 

4.4.2 Vorteile und Nachteile des cloud-basierten SEs für Smartphones 

Die obengenannten Firmen [36-39] haben viele verschiedene Vorteile genannt. Aus 

meiner Sicht die bedeutenden Vorteile des cloud-basierten Secure Elements lassen 

sich mit zwei Wörter zusammenzufassen: Flexibilität und Sicherheit. 

Flexibilität 

 

Speicherplatz-Flexibilität: Traditionelles physikalisches Hardware SE hat nur 

bestimmte vorgegebene Speicherkapazität. Im Lauf der Zeit wird der Benutzer 

immer mehr Applikationen auf dem SE zu speichern haben, bis der Speicher 

voll belegt ist. Dann muss der Benutzer ein neues Hardware SE mit größerer 

Speicherkapazität anschaffen. Mit der cloud-basierten SE Lösung wird das 

Speicherlimit komplett aufgehoben. Das virtuelle cloud-basierte SE ist so 

flexibel, dass der Benutzer jeder Zeit die Speicherkapazität nach Bedarf 

vergrößern und verkleinern kann [36]. 

 

Kosten-Flexibilität: Die Kosten-Flexibilität resultiert aus Speicherplatz- 

Flexibilität. Benutzer zahlt nur für das, was er gebraucht hat. 

Ein anderer Kostenvorteil ist, dass: anstatt komplizierter und teurer 

physikalischer SE zur Datenspeicherung und Benutzer- und Geräte- 

Authentifizierung wird bei dieser Lösung nur ein viel kleineres und billigeres 

physisches SE zur Behandlung der Authentifizierung gebraucht wird; oder es 

wird durch eine vertrauenswürdigen Zone 10 innerhalb des Smartphone- 

Hauptprozessors ein SE komplett vermieden [36] . 

10 Beispielweise: M-Shield [40], ARM TrustZone[41] 

27


 

Integrations-Flexibilität: Für Service Providers von sicheren Anwendungen 

werden die Integration mit beliebigen Drittanbietern und jedes 

Geschäftsmodell viel einfacher. Dazu gehören Mobilfunkbetreiber, NFC- 

Chiphersteller, Gerätehersteller und Trusted Service Managers (TSM). 

 

Kontroll/Zugriffs-Flexibilität: Bei der Lösung ist die Beziehung zwischen 

Service Provider und Benutzer viel enger. Um auf SE zuzugreifen, sind hierfür 

keine Vermittler mehr notwendig [39]. 

Der Benutzer kann auf alle seine Anwendungen mit beliebigen NFC-Geräten 

zugreifen; ein NFC Smartphone kann sich auch mit mehreren cloud-basierten 

SE verbinden, da SE an einem Ort auf der Cloud gespeichert wird. 

Sicherheit 

 

 

Datenspeicherungs-Sicherheit: Da die sensitiven geheimen Daten nicht 

mehr lokal auf einem Smartphone gespeichert sind, werden sie beim Verlust 

des Smartphones, bei der Reparatur oder bei der Übergabe an neuen 

Benutzer deshalb nicht von einem Dritten durch das Handy zugreifbar sein 

[36]. 

Risikomanagement-Sicherheit: Permanente Netzverbindung des Systems 

ermöglicht die sofortige Entdeckung beim Betrug und sofortige Blockierung 

der Anwendung. 

Darüber hinaus ist die Rechenkapazität eines cloud-basierten SE erheblich 

höher als auf einem mobilen Gerät. Dies ermöglicht fortgeschrittenes On- 

Device Risikomanagement [36] [39]. 

Nachteile und Einschränkung von dem cloud-basierten SE sollte auch 

Aufmerksamkeit genommen werden: 

Eine permanente Internetverbindung und schnelle 

Datenübertragungsgeschwindigkeit sind erforderlich. 

Die hohe Anforderung an der Internetverbindung. Durch zunehmende UMTS- und 

LTE-Verbreitung wird dieser Engpass in naher Zukunft beseitigt sein. 

 

 

Obwohl die Cloud viele stärkere Rechenkapazität als physikalische SE hat, 

müssen wegen der Verbindungsverzögerung und langer Transportwege durch 

das Internet, die zu transportierenden Daten so gering wie möglich gehalten 

werden. 

Der wichtigste Punkt ist die „sichere Antenne“ -- das Smartphone. Man muss 

einen sicheren und effizienten Weg finden, mit Hilfe von kryptographische 

Methoden die Daten durch das Smartphone gegenüber anderen Geräten zu 

präsentieren. 

28

5 Delegierbares Zutrittskontroll-System für NFC-fähige Smartphones 


5.1 Einleitung 

Einfache Ein- und Ausgabemöglichkeiten durch Tastatur und Bildschirm, 

verschiedene Schnittstellen (WiFi, Bluetooth, 3G/4G, NFC...) zu anderen Systemen 

und die stetig zunehmende Rechenkapazität machen das Smartphone zu einem 

universellen Werkzeug. 

Abb. 15 Verschiedene Schnittstellen von Smartphone [2] 

Seit das erste NFC-Handy Nokia 6131 im Jahr 2007 auf den Markt gekommen ist, 

wird die NFC-Technologie immer mehr in Smartphones verschiedener Modelle 

integriert. Mit der immer reifer werdenden NFC-Technologie werden auch NFC- 

Smartphones immer beliebter. 

Die zurzeit am meisten diskutierten Anwendungen für NFC-Smartphones sind: E- 

Payment, E-Ticketing und Zutrittskontrolle. Für all diese Applikationen ist eine 

sogenannte Trusted Execution Environment (TrEE) in Smartphones erforderlich, um 

geheime Daten abzulegen und zu bearbeiten. Die bisherige Lösung einer TrEE ist 

meistens in Form eines Hardware Secure Element realisiert, welche jedoch im 

Hinblick auf Ausführungseffizienz, Speicherkapazität und Nutzbarkeit eingeschränkt 

ist, da das Hardware-SE nicht skalierbar wie Cloud ist. 

Diese Arbeit beschäftigt sich mit einem elektronischen Zutrittskontroll-System für 

Smartphones. Elektronische Zutrittskontroll-Tokens für Smartphones können eine 

Vielzahl von attraktiven Merkmalen anbieten: sie können aus der Ferne erteilt und 

29


widerrufen werden; von Benutzern delegiert werden [6] [7] und kontextabhängige und 

zeitbegrenzte Zutrittskontrolle unterstützen [7]. 

Auf dem Markt gibt es vor [6] [7] bereits einige kommerzielle Systeme: elektronische 

Schlüssel für Hotelzimmer [42] [43], die dem Kunden per SMS oder Email geschickt 

werden, sowie elektronische Autoschlüssel [4] [5]. Allerdings sind die 

Sicherheitseigenschaften der genannten Lösungen unklar, insbesondere werden die 

Systemarchitekturen sowie die zugrunde liegende Hardware usw. der Öffentlichkeit 

vorenthalten. Hinzu kommt, dass die meisten Smartphone-Betriebssysteme anfällig 

auf Malware sind. 

Das erste öffentliche System für NFC-Smartphone-basierte Zutrittskontrolle 

"SmartToken“ [6] wurde 2012 von dem Frauenhofer SIT, der TU Darmstadt und Aalto 

University School of Science Finnland gemeinsam entwickelt und präsentiert. 

Gegenüber früheren Lösungen liegen die bemerkenswerten Vorteile dieses 

SmartToken-Systems darin, dass Benutzer die Zutrittsberechtigungen zu anderen 

Benutzern delegieren können, ohne die zentrale Token-Ausgabestelle zu 

kontaktieren. Zudem wird die Unterstützung der Policy-basierten 

Zugangsberechtigung 11 durch Kontextinformationen wie Zeit und Ort vorgeschlagen. 

Dadurch können die delegierten Berechtigungen eingeschränkt werden. Die 

zugrunde legenden Protokolle haben die Einschränkungen der NFC-Bandbreite 

berücksichtigt. 

Abb. 16 Generelle Multi-Level-Plattform Sicherheitsarchitektur [6] 

Diese SmartToken Anwendung läuft auf einer Sicherheitsarchitektur, die die 

zugrunde liegenden Geheimnisse für Authentifizierungen schützt. Die Architektur 

[Abb.16] kombiniert eine Hardware unterstützte Trusted Execution Enviroment 

(TrEE) mit Software-basierter Isolation. Die Hardware unterstützte Trusted Execution 

Environment (TrEE) ist für die Verarbeitung der sicherheitskritischen Daten 

zuständig, während der Software-basierten Isolation für die Kontrolle des Zugriffs von 

Host OS zu TrEE zuständig ist. Die Architektur bietet eine zwei-Fach- 

Verteidigung 12 gegen Software Angriffe und es wird zwischen Sicherheit und 

Ressourcenknappheit des sicheren Elements abgewogen. 

11 Diese Funktionen setzt ein sichere UI voraus, wurd in „SmartToken“ noch nicht umgesetzt 

12 Hardware basierte TrEE und Betriebssystemebene Software Isolation 

30


Trotz der bemerkenswerten Verbesserungen gegenüber den früheren Lösungen 

bestehen allerdings die Beschränkungen des Systems darin, dass erstens 1. die 

Software-basierte Isolierung die Modifizierung des Handybetriebssystems erfordert, 

was die Lösung schwierig zu verbreiten macht. Und zweitens, dass wie bereits 

erwähnt, es Einschränkungen gibt bzgl. Recheneffizienz, Speicherkapazität und 

Nutzbarkeit des Hardware-SEs. 

Da Cloud Computing IT-Ressourcen mit einer Flexibilität ohnegleichen bietet, stellte 

sich während dieser Arbeit die Frage, ob es möglich sei, die Beschränkungen 

aufzuheben durch den Einsatz Cloud-basierter SE. 

5.2 Sicherheitsanalyse 

Um ein SmartToken-System auf der Grundlage eines cloud-basierten SE mit NFCfähigem 

Smartphone als Schlüssel zu konzipieren, werden die Anforderungen genau 

analysiert und die am jeweiligen Systemmodell beteiligten Einheiten/Akteure sowie 

deren Interaktionen unter die Lupe genommen. 

Im Laufe der Analyse sind zwei Überlegungen zu Sicherheitsarchitekturen für das 

SmartToken System entstanden. Die erste Überlegung ist ein System mit NFCfähigem 

Smartphone als Schlüssel ohne Hardware-SE, was die meiste Flexibilität für 

Service Provider und Nutzer bieten soll. Nach eingehender Analyse wurde jedoch 

festgestellt, dass ein solches System aus Sicherheitsgründen nicht ohne weiteres 

einsetzbar ist. In einem späteren Teil des Kapitels werden die Gründe genau 

beschrieben, warum ein solches Modell unsicher ist. 

Danach wurde das Systemmodell neu ausgerichtet. Anstatt kompliziertes und teures 

physikalisches SE zur Datenspeicherung und Benutzer- und Geräte-Authentifizierung 

wird hierbei ein viel kleineres und billigeres physisches SE nur zur Behandlung der 

Authentifizierung eingesetzt, dadurch eine sichere Verbindung zwischen Smartphone 

und dem sicheren Element in der Cloud gewährleistet wird. Der große Teil des 

Authentifizierungsprozesses und Datenspeicherung sowie Software werden jedoch in 

der Cloud ausgelagert. 

5.2.1 Systemmodell mit den cloud-basierten SE 

Wie bereits erwähnt, stellen Smartphone Plattformen, mit dem mobilen 

Betriebssystem einen unsicheren Host dar, welcher potenziell durch Malware 

beeinträchtigt werden kann und alle, auf der Plattform gespeicherten, Geheimnisse 

preisgegeben werden können. 

5.2.1.1 Erste Überlegung an den Systemanforderungen 

A1: Keine Geheimnisse auf den Smartphone zu speichern. 

31


A2: Keine sicherheitskritische Ausführung im Smartphone durchzuführen. 

A3: Alle sicherheitskritische Daten und Ausführung in der Cloud auszulagern. 

5.2.1.2 Sicherheits- und Gefährdungs-Annahme 

Sichere Umgebung der Ressource und Cloud-basierte SE: Die Umgebungen von 

Cloud-basierten sicheren Elementen und Ressourcen (Fahrzeugsperre und Türen) 

werden als sicher betrachtet. 

Datenspeicherung und Ausführungen von Authentifizierungsprozess in der Cloud 13 

und in den Ressourcen werden als sicher angesehen. 

Angreifer können Softwareangriffe gegen den Host H durchführen, Malware 

installieren, Applikation verändern, Eingabe vom Benutzer abhören, alle lokal 

gespeicherten Daten auf Smartphones beeinträchtigen. 

Darüber hinaus sind alle Kommunikationskanäle zwischen Smartphone, Cloudbasierten 

sicheren Element und Ressourcen unsicher. Der Angreifer kann alle 

Nachrichten über die Kanäle abhören, aufnehmen, bearbeiten, injizieren und 

umleiten. 

5.2.1.3 Sicherheitsanforderung und Challenge 

Dann stellt sich die Frage, wie man eine sichere Verbindung zwischen einem 

Smartphone und einem cloud-basierten sicheren Element aufbauen kann. Wie stellt 

die Cloud sicher, dass die Person, die auf ein System zuzugreifen versucht, auch die 

Person ist, die sie vorgibt zu sein? Welche Möglichkeiten gibt es für die 

Authentifizierung? 

5.2.2 Authentifizierung mit dem NFC-Smartphone und cloud-basiertem SE 

In der unteren Tabelle 3 wird die Analyse des Authentifizierungsvorgangs 

vorgenommen bzw. Möglichkeiten der Abwicklung aufgezeigt. Zum veranschaulichen 

wird hier Beispiel mit Benutzer, Smartphone (ohne lokale TrEE) und Fahrzeug- 

Wegfahrsperre genommen. 

Um einen Benutzer zu authentisieren, gibt es allgemein folgenden Möglichkeiten: 

 

 

 

Beweis durch Wissen, was nur der Benutzer weiß. 

Beweis durch Besitz, was nur der Benutzer besitzt. 

Beweis durch biometrischen Eigenschaften, die kein Anderer hat. 

13 Obwohl einige Sicherheitsrisiko in der Cloudsumgebung noch geklärt werden muss 

32


Durch geeignete Kombinationen der Methoden entsteht sogenannt Stark- 

Authentifizierung, jedoch das ist oft mit höheren Kosten und/oder höherem Aufwand 

verbunden. 

 

 

 

Überlegungen 

PIN Eingabe OK, an dieser Stelle wäre die eine 

optimale Lösung 

PIN Eingabe OK? Nur möglich, wenn zusätzliche 

Hardware für PIN Eingabe beim Fahrzeug vorhanden ist. 

Smartphone als Mittel, Benutzer Smartphone(OK), 

Smartphone Wegfahrsperre siehe d. 

c. Benutzer SE in der Cloud 

Keine direkte VerbindungSmartphone als Mittel, 

BenutzerSmartphone(OK) 

d. Smartphone 

Authentifizierung 

a. Benutzer Smartphone 

b. Benutzer Fahrzeug- 

Wegfahrsperre 

Fahrzeug- 

Wegfahrsperre 

SmartphoneCloud-SE siehe e. 

BenutzerSmartphone(OK), SmartphoneFahrzeug 

? siehe Diskussion da unten 

e. Smartphone SE in der Cloud Diskussion siehe unten 

Tabelle 3 Authentifizierungsvorgang 

a. Benutzer Authentifizierung gegenüber dem Smartphone: Das kann man als 

erledigt betrachten, das ist „State of the Art“, wenn ein Benutzer ein Smartphone in 

der Hand hat, und die richtig PIN eingeben kann, er ist authentifiziert. 

b. Benutzer authentisiert sich gengenüber Fahrzeug(Ressource): darunter gibt es 

mehrere Möglichkeiten. 

b.1) Direkte Interaktion zwischen Benutzer und Fahrzeug. (Authentifizierung 

durch Wissen/IST/Besitz des Benutzers) Das kann mit zusätzlich Hardware 

Installation verbunden, um Wissen oder IST direkte vorzuweisen, hier wird 

solcher Fall nicht weiter betrachtet. 

Durch Besitz des Benutzers kann Benutzer sich am Fahrzeug authentisieren, 

dass entspricht die nächste Überlegung – Smartphone als Besitz 

b.2) Benutzer Authentifizierung bei der Benutzung von dem Smartphone ohne 

Cloud-SE: Benutzer kann sich mit Hilfe vom Smartphone am Fahrzeug 

authentisieren. Das Probleme ist schon im „Smart Keys“ [7] gelöst, daher wird 

diesen Fall nicht weiter betrachtet. Einbeziehen der Cloud wird in nächste 

Punkt diskutiert. 

b.3) Benutzer Authentifizierung bei der Benutzung von Smartphone und 

Cloud-SE: Smartphone ist physischer Besitz von dem Benutzer, Cloud SE ist 

entfernt, von daher ist eine sichere Verbindung zwischen Smartphone und 

Cloud-SE erforderlich. Das impliziert eine gegenseitige Authentifizierung 

33


zwischen dem Smartphone und der Cloud (sehe e.). Sichere Authentifizierung 

muss zwischen den drei Stellen (Smartphone, Cloud-SE, Ressource) 

durchgeführt werden. Fahrzeug erhält das Ergebnis am Ende dieses 

Prozesses. Um ein optimale Effizienz und Sicherheit zu erreichen, werden die 

meisten Vorgänge der Authentifizierung in der Cloud durchgeführt. Für das 

Ergebnis Zuteilung gibt es wiederum zwei Möglichkeiten 14 : 

b.3.1) Ohne direkte Kommunikation zwischen Fahrzeug und Cloud: das 

Ergebnis muss über das Smartphone an das Fahrzeug geschickt 

werden. 

b.3.2) Mit direkter Kommunikation zwischen Fahrzeug und Cloud: das 

Ergebnis kann auch direkt vom Cloud-SE an das Fahrzeug übermittelt 

werden. 

c. Benutzer Authentifizierung gegenüber dem Cloud-SE: Benutzer kann sich 

selber nicht direkt am Cloud authentisieren, Verbindung zwischen Benutzer und 

Cloud ist das Smartphone des Benutzers. Wie kann sich das Smartphone gegenüber 

der Cloud authentisieren? e.) 

d. Smartphone Authentifizierung gegenüber dem Fahrzeug: Direkte Authentifizierung 

ohne SE in der Cloud ist der gleiche Fall wie bei „Smart Keys“. 

Sollten die Cloud-SE und Benutzer einbezogen werden, kann dieser Fall gleich als 

der Fall b.3) betrachtet werden. 

e. Smartphone Authentifizierung gegenüber dem Cloud-SE: Smartphone ist ein 

Besitz eines bestimmten Benutzers, nach Authentifizierungsvorgang wie a.) der 

offene Punkt ist nur noch gegenseitige Authentifizierung zwischen dem Smartphone 

und dem Cloud-SE, sowie die Kommunikationssicherheit zwischen den zwei Stellen! 

Fazit: 

Nach obigen Überlegungen, der offene Punkt ist ersichtlich: Authentifizierung des 

Smartphone gegenüber dem Cloud-SE. 

Mit Bezug auf die Gefährdungsannahme [K. 5.2.1.2], weiß man, dass die Eingaben 

des Benutzers sowie die lokal gespeicherten Geheimnisse unsicher sind. Um die 

Gefahr der Preisgabe sicherheitsrelevanter Informationen auszuschließen, werden 

im praktischen Verfahren wie Challenge-Response-Authentifizierung auf Basis von 

digitalen Zertifikaten verwendet. Bei der Authentifizierung soll die zu authentisierende 

Partei nur einen Beweis übermitteln, dass sie gültige Identifizierungsdaten besitzt. Im 

Allgemeinen erfolgt bei einer solchen Authentifizierung eine Abfrage, welche nur von 

einem entsprechenden Gegenüber beantwortet werden kann, welches ein 

bestimmtes Wissen bzw. einen bestimmten Besitz hat. Somit kann ein Gegenüber 

authentifiziert werden, ohne dass dieses sein Wissen bzw. seinen Besitz preisgeben 

musste. 

14 Diese können die Systemdesign und Protokolldesign beeinflussen 

34


In angenommenen System [K. 5.2.1.1] funktioniert es aber nicht so einfach, da die 

Gefahr besteht, dass das Wissen in unserem System über einen Trojaner 

aufgenommen werden und zu einem späteren Zeitpunkt wiederverwendet werden 

kann. Als Besitz des Benutzers ist außer dem Smartphone nichts anderes 

vorgesehen, das Smartphone selber ist wegen A1 und A2 nicht identifizierbar, alle 

Kommunikationskanäle über Smartphones sind nicht vertrauenswürdig. 

Die Sicherheitsanforderungen an das zugrundliegende System müssen neu 

definiert werden. 

5.2.3 Die Sicherheitsanforderungen 

SA1: Sichere Speicherung. Die auf der Smartphone Plattform gespeicherten 

sicherheitsrelevanten Daten sollten nicht zugänglich für nicht vertrauenswürdige 

Software sein. 

SA2: Isolation. Die sicherheitsrelevanten Daten und der Programmcode welcher die 

Daten ausführen, muss von nicht vertrauenswürdigen Komponenten isoliert werden. 

Zugriff auf die Daten und den Programmcode muss geprüft werden. 

SA3: Sichere Smartphone und cloud-basierte Elemente Zuordnung. Zwischen 

Smartphone und cloud-basiertem sicheren Element muss eine eindeutige 

Verbindung aufgebaut werden. Datentransport zwischen Smartphone und cloudbasiertem 

SE muss kryptographisch geschützt werden, also authentisch und 

verschlüsselt sein. 

SA4: Sicheres UI (deutsch, Benutzeroberfläche). Der Benutzer sollte sicher mit der 

vertrauenswürdigen Komponente kommunizieren können, was aber auf 

kommerziellen Smartphones sehr eingeschränkt verfügbar [6] ist. 

5.3 Sicherheitsarchitektur 

Das Sicherheitsproblem bei der Authentifizierung zwischen Benutzer und 

Ressourcen liegt daran, dass die Sicherheitsgewährleistung des Smartphones nicht 

vorhanden ist. Im Folgenden wird ein anderes Systemmodell vorgestellt. Anstatt 

kompliziertes und teures physikalisches SE zur Datenspeicherung und Benutzer- und 

Geräte-Authentifizierung wird hierbei viel kleineres und billigeres physisches SE nur 

zur Behandlung der Authentifizierung eingesetzt. Dadurch wird eine sichere 

Verbindung zwischen Smartphone und dem sicheren Element in der Cloud 

gewährleistet. Der große Teil des Authentifizierungsprozesses und der 

Datenspeicherung sowie Software sind in der Cloud. Dieses Modell soll 

entsprechende Abhilfe für die Einschränkungen bzgl. Recheneffizienz, 

Speicherkapazität, Flexibilität und Nutzbarkeit des Hardware-SEs entsprechende 

Abhilfe anbieten [mehr Vorteile sehe Kapitel 4.4]. 

35


Abb. 17 Sicherheitsarchitektur mit cloud-basierten SE 

Dadurch, dass ein Hardware-SE im Smartphone vorausgesetzt ist, entsteht die 

Möglichkeit die Kommunikationskanäle über Smartphone zu sichern. 

Sicherheitsrelevante Daten kann man jetzt in dem sicheren Element S auf dem 

Smartphone sicher abgelegt werden. Die CS in der Cloud und S in dem Smartphone 

ermöglichen auch die zuverlässige Isolationen von nicht vertrauenswürdigen Daten 

und Code Speicherung. 

Nochmal zurück zu der Sicherheitsanforderungen: 

Nach der Untersuchung von Sicherheitsprobleme und 

Authentifizierungsmöglichketen ist letztendlich dieses Systemmodell zustande 

gekommen. 

SA1: Sicherer Speicherplatz in Smartphones. Mit dem Einsatz der S in 

Smartphones ermöglicht sicheren Speicherplatz im Smartphone. 

Diese Anforderung kann erfüllt werden! 

36


SA2: Isolation. Sowohl die Isolation der sicherheitsrelevanten Daten von nicht 

vertrauenswürdigen Komponenten in der cloud-basierte SE, als auch die Isolation bei 

handelsüblichen Smartphone können erreicht werden 

Diese Anforderung kann nur bedingt erfüllt werden (Modifizierung des OS)! 

SA3: Sichere Zuordnung von Smartphone zu cloud-basiertem SE. Zwischen 

Smartphone und cloud-basiertem sicheren Element muss eine eindeutige 

Verbindung aufgebaut werden. Datentransport zwischen Smartphone und cloudbasiertem 

SE muss kryptographisch geschützt werden, spricht authentisch und 

verschlüsselt sein. 

Solange die unterlegende Protokolle und TSL/ SSL richtig entworfen und 

implementiert werden, kann diese Anforderung erfüllt werden. 

SA4: Sichere Benutzeroberfläche. Handelsübliche Smartphones bieten selten 

sichere Benutzeroberflächen. 

Diese Anforderung kann nur bedingt erfüllt werden! Aber es ist möglich mit Hilfe des 

UI von einem anderen System (Onboard System von Fahrzeug oder PIN-Pad auf 

einer Tür) die Einschränkung zu beseitigen und fortgeschrittene Funktionen zu 

realisieren. 

5.4 Smart Token System mit cloud-basierten sicheren Elementen 

Auf der Basis, der in den Kapitel 5.3 vorgestellten Sicherheitsarchitektur wird das 

„SmartToken“ System neu analysiert und konzipiert. 

5.4.1 Akteure in dem System 

Im Systemmodell enthalten sind Token-Ausgabestelle (Token Issuer) I, eine Reihe 

von Ressourcen R (wie z.B. elektronische Dokumente, Türen von Gebäuden oder 

Fahrzeugen…) und eine Gruppe von Benutzern (User) U. Jeder Benutzer besitzt 

mindestens ein mobiles NFC-fähiges Gerät P (kann ein Smartphone oder Tablet 

sein). 

Der Benutzer bekommt nach erfolgreicher Registrierung und Token-Vergabe das 

Token Tu von der Token-Ausgabestelle I. Der berechtige Benutzer U kann seine 

Berechtigung Td an andere Benutzer delegieren. Delegierte Benutzer D können ihre 

Tokens Td nicht weiter delegieren. 

Zur Speicherung und Ausführung von Benutzer Credentials, die für die 

Authentifizierung notwendig sind, kommt das cloud-basierte sichere Element CS zum 

Einsatz. Cloud-basierte sichere Elemente CS sind virtuelle Sicherheitsmodule in der 

Cloud, die beispielsweise von Automobilherstellern (Service Provider) angeboten 

werden (mehr sehe Typ B in 5.4.2). Es könnte auch sein das der Benutzer hat das 

CS als eigenen Besitz (Typ A in 5.4.2). 

37


5.4.2 Ökosystem für cloud-basierte SE 

Vor der Festlegung der Beziehungen der Akteure in dem Systemmodell wird 

zunächst das Ökosystem für cloud-basierte SE analysiert, da es die Beziehungen 

der Akteure im Systemmodell durchaus beeinflussen kann. 

Wie in Kapitel 3.4 beschrieben, gibt es folgende wichtige Rollen in dem Ökosystem 

der sicheren Elemente: Plattform Provider, Service Provider, Plattform Manager und 

Benutzer. 

Hierfür bietet der Plattform Provider (Herausgeber des Secure Elements) PP ein 

cloud-basiertes sicheres Element als Plattform. Der Service Provider SP bietet 

Services, die dem NFC-Smartphone und dem cloud-basierten sicheren Element 

zugrundeliegen. Der Trust Service Manager TSM ist für die Verwaltung des cloudbasierten 

sicheren Elementes und dem darauf untergebrachten Service 

verantwortlich. Benutzer können verschiedene Services von verschiedenen Service 

Providern benutzen. 

Aus der Sicht eines Service Providers, ist die Frage wer die Rolle des Plattform 

Providers und des Plattform Managers spielen kann. Folgende Tabelle zeigt die 

Möglichkeiten des Ökosystems für cloud-basierte SE. 

Rolle des Ökosystems Variante 1 Variante 2 Variante 3 Variante 4 

Service Provider SP SP SP SP 

Plattform Provider SP SP PP PP 

Trust Service Manager SP TSM TSM PP 

Tabelle 4 Ökosystem von cloud-basierte SE 

Bei Variante 1 und 2, Service Provider (könnte ein Token-Ausgabestelle sein) spielen 

gleich auch die Rolle Plattform Provider. In diesen Fällen hat er volle Kontrolle auf 

cloud-basierte sichere Elemente CS (er besitzt den Master Key für Zugriff auf CS, CS 

könnten aber auch von PP erworben werden). Die Verwaltung von Anwendungen auf 

CS könnte durch ihn selbst erfolgen (Variante 1), oder durch einen neutralen Dritten - 

den TSM (Variante 2). 

Bei Variante 3 und 4, hat der Service Provider nicht direkt Kontrolle auf die cloudbasierten 

sicheren Elemente. Die Master Keys sind unter Kontrolle des Plattform 

Providers, der Benutzer erwirbt das CS von dem PP. In diesen Fällen installiert der 

Benutzer selbst die Services auf seine Plattform. Der Trust Service Manager wird in 

diesen Fällen meistens vom Plattform Provider ausgesucht (Variante 3), oder der 

Plattform Provider verwaltet selbst die cloud-basierten sicheren Elemente und die 

darauf installierten Anwendungen (Variante 4). 

Die obige Tabelle 4 stellt hauptsächlich die möglichen Beziehungen zwischen 

Service Provider, Plattform Provider und Trusted Service Manager dar. Im Folgenden 

zeigen zwei Diagramme die Beziehungen zwischen den Beteiligten, insbesondere 

aus der Benutzersicht. 

38


Typ A: Der Benutzer hat das cloud-basierte SE sozusagen als eigenen Besitz, er 

kann beliebige Anwendungen von verschiedenen Service Providern auf das cloudbasierte 

SE installieren. 

Abb. 18 Cloud-basiertes SE als Plattform für mehre Anwendungen 

In der Cloud bekommt jede Anwendung ihren eigenen sicheren Bereich, in dem sie 

sich befinden dürfen. Durch die Trennung, können die Anwendungen unabhängig 

voneinander verwaltet werden und nicht gegenseitig beeinflusst werden. Der 

Benutzer kann mit einem beliebigen Smartphone oder Tablet eine Verbindung zum 

Service Provider und dem Cloud-basierten SE herstellen, um den Service aus der 

Ferne zu nutzen. 

Typ B: In diesem Modell [Abb.19] ist der Benutzer über sein Smartphone oder Tablet 

nur mit den jeweiligen Service Providern in Kontakt zu treten. 

39


Abb. 19 Cloud-basiertes SE für einzelne Anwendung 

Die Service Provider bieten ihre Dienste an und stellen dabei gleichzeitig das Cloudbasierte 

SE für den Benutzer zur Verfügung. Die Auswahl des Plattform Providers 

sowie die Initialisierung der Anwendung ist die Aufgabe des Service Providers, der 

Benutzer muss sich also nicht um das sichere Element kümmern. Dieses cloudbasierte 

SE wird dem Benutzer auf Basis einer Serviceeinheit erteilt. Das Cloudbasierte 

SE kann von verschiedenen Plattform-Anbietern kommen, was aber für den 

Benutzer verborgen bleibt. Der Benutzer kann mit beliebigen NFC-fähigen 

Smartphones oder Tablets beim Service Anbieter registrieren, und auf von ihm 

gekaufte Services zugreifen. 

Vergleich von Typ A und Typ B 

Typ A 

Benutzer hat bessere Kontrolle auf seine Anwendungen und Cloud-SE. 

Benutzer muss sich nicht um Cloud-SE kümmern. 

Typ B 

Service Provider hat bessere Kontrolle über angebotene Anwendung. 

40


Nach dem Vergleich kommt die folgende Aussage: 

Typ A ist besser für fortgeschrittene Benutzer, welche mehr technisches Verständnis 

haben, und Kontrolle auf eigene Daten und Anwendungen geeignet. 

Das cloud-basierte sichere Element ist eine Art von „Plattform as a Service“ (PaaS). 

Die Zielgruppe sind eher Firmen. Entsprechend ist der Vergleich für Webplattform 

und sein Benutzer. 

Typ B ist eine Arte von sichere „Software as a Service“ (SaaS) für den Benutzer, und 

ein PaaS für die Service Provider. SaaS ist geeignet für den Benutzer, der wenig 

technisches Verständnis besitzt. 

41

6 NFC-Smartphone im Fahrzeug-Kontext 


Smartphone wird zu einem universellen Werkzeug. In Automotiven Systemen und 

Anwendungen findet es natürlich auch seinen Einsatz. Navigieren, Schnelle 

Konfiguration und benutzerdefinierte Einstellungen wie Sitz- und Spiegel-Position 

etc. sind sehr angenehme Funktionalitäten. Besonders zum Entriegeln der 

Zutrittskontrolle von Fahrzeugen (Türen und Wegfahrsperre) ist die Integration von 

Smartphones sehr spannend. Im Vergleich zu herkömmlichen dedizierten 

Token/Transpondern können Smartphone-basierte Wegfahrsperren alle 

bestehenden Funktionen des traditionellen Autoschlüssels beibehalten und darüber 

hinaus die Benutzerfreundlichkeit und Sicherheit durch eine Vielzahl von attraktiven 

Funktionen erhöhen. 

Bereits 2010 wurde ein NFC-basiertes Konzept für Car-Sharing entwickelt und 

vorgestellt [5]. Mittlerweile erwägen immer mehr Firmen NFC-Smartphones als 

Schlüssel für Privat- und Firmen-Nutzung einzusetzen [48][49]. Allerdings handelte 

es sich dabei um proprietäre Lösungen. Die Systemarchitekturen sowie die zugrunde 

liegende Hardware usw. wurden der Öffentlichkeit vorenthalten. 

Das erste offene Sicherheits-Framework für die sichere Smartphone-basierte 

Wegfahrsperre wurde Anfang 2013 von der TU Darmstadt und dem Frauenhofer SIT 

gemeinsam entwickelt und präsentiert [7] Die Sicherheitsarchitektur und Protokolle 

basieren auf dem in Kapitel5 vorgestellten SmartToken System. Sie implementieren 

ihr Wegfahrsperren-System auf dem damals aktuellsten Androide-basierten 

Smartphone (Samsung Galaxy S3) und einer sicheren microSD Smartcard (der 

Firma Giesecke & Devrient). Das offene Smartphone-basierte Wegfahrsperren- 

System erlaubt eine große Dynamik in Bezug auf die Erteilung und Widerruf des 

Zugriffsrechts, gewährleistet hohe Sicherheitsanforderung und bietet mehr 

Funktionen. Diese Eigenschaften machen es für Automotive Anwendungen mit hoher 

Dynamik bzw. große Benutzergruppen wie etwa Car-Sharing und 

Flottenmanagement besonders interessant. 

Die Beschränkung des Systems liegt allerdings darin, dass es nur auf Smartphones 

mit microSD-Kartenslot einsetzbar ist und die Verwendung der sicheren microSD- 

Karte nur in Absprache mit dem Hersteller möglich ist. 

Im Folgenden wird der Einsatz mit cloud-basierten sicheren Elementen und in 

[Kapitel 5.3] vorgestellte Sicherheitsarchitektur in diesem Fahrzeug-Kontext 

diskutiert. 

42


6.1 Smart Keys mit cloud-basierter SE 

Durch den Einsatz von cloud-basierter SE, kann das System wie folgende aussehen. 

Abb. 20 zeigt einen Überblick auf das System: 

1. Der Automobilhersteller I 15 produziert Autos, welche mit Fahrzeug- 

Wegfahrsperre R ausgestattet sind. I initialisiert das Fahrzeug-Wegfahrsperre 

R. 

2. Fahrzeugbesitzer U registriert sich bei I beim Kauf des Fahrzeugs. 

3. Hersteller I stellt den elektronischen Schlüssel Tu für das NFC-fähige 

Smartphone des Fahrzeugbesitzers bereit. 

4. Fahrzeugbesitzer U authentisiert sich am Fahrzeug mit dem registrierten NFC- 

Smartphone. 

5. Fahrzeugbesitzer U delegiert die Zugangsberechtigung Td an Benutzer D. 

6. Benutzer D mit delegiertem Zugangsrecht Td authentisiert sich mit 

berechtigtem Smartphone P am Fahrzeuge R und entriegelt das Fahrzeug. 

Abb. 20 Systemmodell – Smart Keys mit Cloud-basierte SE 

15 I können auch, die vom Automobilhersteller autorisierten, Servicepunkte oder Fahrzeughändler repräsentieren 

43


6.2 Zielsetzungen 

Hauptziel des Systems ist, den unberechtigten Zugriff an einem Fahrzeug zu 

verhindern und, darüber hinaus, die Benutzerfreundlichkeit, Kompatibilität und 

Sicherheit zu bestehenden Smartphones durch den Einsatz Cloud-basierter SEs zu 

erhöhen. 

Funktionale Ziele: 

Z1: Zutrittskontrolle. Nur autorisierte Personen, nämlich, durch I autorisierte U und 

durch U autorisierte D, können das Fahrzeug entriegeln und starten. 

Z2: Remote-Issuing. Der Automobilhersteller I sollte aus der Ferne (z.B. über das 

Internet) dem Autobesitzer U die Zugangsberechtigung bereitstellen und erteilen 

können. 

Z3: Remote-Widerruf. I sollte aus der Ferne die Zugangsberechtigung widerrufen 

oder blockieren können, die Wirkung von Widerruf oder Blockierung muss gleich 

wirksame werden. Außerdem muss beim Widerrufen der Zugangsberechtigung von 

U sichergestellt werden, dass die Zugangsberechtigung, die von U an D delegiert 

wurde, auch automatisch widerrufen wird. 

Die Cloud nehmen hier eine zentrale Rolle für den Authentifizierungsprozess, und 

immer online ist, so ein instant Widerruf von I leicht umgesetzt werden können. 

Z4: Delegation. Ein Autobesitzer U sollte seine Zugangsberechtigung zu einem 

Dritten D sicher delegieren können. 

Z5: Policy-basierte Zugangsberechtigung. Autobesitzer U sollte in der Lage sein, 

mit Hilfe von Kontextinformationen wie Zeit und Ort, die delegierte Berechtigung an D 

einzuschränken. 

Ein sicheres UI ist hierzu für die Funktionen (Z4 und Z5) Voraussetzung, jedoch ist 

dies, bei den derzeit auf dem Markt erhältlichen Smartphones, nicht weit verbreitet. 

Nichtfunktionale Ziele: 

Z6: Performance. Authentifizierung von U oder D sollte in einem unmerklichen 

Zeitintervall durchgeführt werden. Eine niedrige Bandbreite der NFC-Kommunikation 

und die Latenz der Internetverbindung zwischen Smartphones und den Clouds 

müssen berücksichtigt werden. 

Z7: Kompatibilität. Eine wichtige Anforderung ist die Kompatibilität zu den 

handelsüblichen mobilen Plattformen. Aber wegen der Sicherheitsprobleme, ist die 

Modifizierung des Hosts immer erforderlich. 

44


6.3 Sicherheitsannahmen in dem System 

Die nachfolgenden Komponenten, Wegfahrsperre, cloud-basiertes SE und Sicheres 

Element S sowie der Vorgang der Initialisierung, werden in diesem System als 

sicher vorausgesetzt. 

Sichere Wegfahrsperre: Es wurde davon ausgegangen, dass die Wegfahrsperre R, 

wie bei herkömmlichen (nicht-NFC-basierten, nicht cloud-basierten) Wegfahrsperren, 

vertrauenswürdig ist. Beeinträchtigungen der Speicherung oder 

Softwarekomponenten im R sind ausgeschlossen. 

Cloud-basierten sicheren Elemente: Abgesehen von der Risiken der Cloud 

Computing, die Daten und Programcode in cloud-basierten sicheren Elemente CS 

werden eben als sicher betrachtet. 

Sicheres Element im Smartphone: Mobile Plattform P, neben ein nicht 

vertrauenswürdigen Host H ist noch ein vertrauenswürdiges sicheres Element S 

vorhanden. Die Daten und Programcode in dem sicheren Element S werden als 

resistent gegen Angreifer betrachtet. 

Sichere Initialisierungen: Die Initialisierungen des Credentials im Wegfahrsperre R 

und im cloud-basiertem SE werden ebenfalls als sicher angenommen. 

6.4 Gefährdungsmodelle 

Unsichere Kommunikationskanäle: Bis auf die Kanäle für die Initialisierung 

zwischen Hersteller I und Fahrzeug R sowie Hersteller I und dem cloud-basierten 

sicheren Element CS hat der Angreifer die volle Kontrolle auf alle anderen 

Kommunikationskanäle. Der Angreifer kann alle Nachrichten über die Kanäle 

abhören, aufnehmen, bearbeiten, injizieren und umleiten. 

Smartphone Plattform: Die Mobile Plattform P enthält einen nicht 

vertrauenswürdigen Host H. Angreifer können Softwareangriffe gegen den Host H 

durchführen, Malware installieren, Applikation verändern, Eingaben vom Benutzer 

abhören und alle lokal gespeicherten Daten auf Smartphones beeinträchtigen. 

45


6.5 Komponenten und ihre Funktionen in der Sicherheitsarchitektur 

Abb. 21 Funktionen in der Sicherheitsarchitektur 

Wie schon beschrieben hat das Smartphone zwei getrennte Bereiche: einen nicht 

vertrauenswürdigen Host H und eine vertrauenswürdige Umgebung S. Mit Hilfe des 

sicheren Cloud-SE CS, ist für die Hardware-basierte S nur wenige Speicher und 

Rechenleistung erforderlich. Je nach Typ könnte die entsprechende TrEE-Umgebung 

auch direkten sicheren Zugriff auf den NFC-Chip haben. Ansonsten muss der Zugriff 

auf den NFC Chip über den Host des Smartphone erfolgen. 

Programmecode der CloudToken App kann verteilt in H, S und CS abgelegt werden. 

Im H wird Hauptsächlich nicht kritischer Programmcode abgelegt und ausgeführt. In 

S wird Code für die Benutzerauthentifizierung und gegenseitige Authentifizierung 

zwischen S und CS abgelegt. In CS werden rechenaufwendige und platzraubende 

Daten bzw. Code abgelegt. 

Ein Funktions-Aufruf von H auf S muss über den TrEE Service und TrEE Mgr laufen 

und geprüft werden, das stellt sicher, dass nur authentische und berechtigte 

Programme von H Dienste in S aufrufen dürfen. 

Sichere UIs sind nicht weit verbreitet auf dem Markt bisher erhältlicher 

Smartphones. Für fortgeschrittene Funktionen wie Z4 und Z5 muss entweder die 

46


Fähigkeit der Angreifer ausgehebelt, oder die Hilfe vom externen sicheren System 

hinzugezogen werden. 

Authentifizierungsvorgang von Benutzer 

Abb. 22 Authentifizierungsvorgang von Benutzer 

1. Der Benutzer gibt seine PIN ein, um die Applikation zu öffnen. 

2. Mit aktivierter Applikation wird das Smartphone an das Fahrzeug gehalten. 

3. Das Fahrzeug schickt eine Challenge an das Smartphone. 

4. Das Smartphone verbindet sich mit dem Cloud-SE CS und übermittelt Token 

Tu und Challenge vom Fahrzeug R an das Cloud-SE. 

5. Im Cloud-SE werden Tu und Challenge von R geprüft, wenn alles korrekt ist, 

wird eine Response zurück an das Smartphone geschickt. 

6. Das Smartphone übermittelt die Response an das Fahrzeug R. Das Fahrzeug 

R prüft die Response, wenn alles korrekt ist, wird Zutritt gewährt. 

6.6 Protokolle des Systems 

Wie in 5.4.2 diskutiert, könnten cloud-basierte sichere Elemente in zwei Formen 

eingesetzt werden: Typ-A als eine Plattform (PaaS) oder Typ-B mit der 

Sicherheitsanwendung zusammen als ein Service (SaaS). Wie gesagt, beim Typ A 

hat der Service Provider am Anfang keinen direkten Zugriff (kein Plattform-Key) auf 

die cloud-basierten sicheren Elemente. Beim Typ B hat der Service Provider am 

Anfang schon den Zugriff (Plattform-Key) auf die cloud-basierten sicheren Elemente. 

Beide Fälle haben bestimmte Vorteile und Nachteile für den Service Provider oder 

für den Benutzer. Akzeptanz und Durchsetzungsmöglichkeit ist momentan noch 

unbekannt. 

47


Zur Vereinfachung der Integration wird als erstes angenommen, dass der 

Fahrzeughersteller I bereits am Anfang die Kontrolle auf die cloud-basierten 

sicheren Elemente hate. Er bietet die Anwendung mit cloud-basiertem SE zusammen 

als einen Service für den Benutzer an. 

Für das cloud-basierte Zutrittskontroll-System können die bestehenden und 

bewiesenen Protokolle von [6] mit wenigen Anpassungen eingesetzt werden. 

6.6.1 System Initialisierung 

Hersteller I initialisiert ein Liste RevoList 16


(4) Im Hardware-SE werden c reg geprüft. 

Abb. 23 Benutzer Registrierung Protokoll 

Nach erfolgreicher Prüfung speichert TrEE Su am Ende die Authentizität-Schlüssel 

K Auth U,I und ein Ver-/Ent-schlüsselungsschlüssel K Enc U . Die beiden Schlüssel werden 

auch bei I gespeichert. 

Hersteller I kennt in diesen Zeitpunkt folgende Schlüssel: K Auth 

R 

und K Enc 

R 

von R; 

K Auth CS und K Enc CS von CS; K Auth U,I und K Enc 

U 

für weitere Kommunikation mit Benutzer 

Smartphone. 

49


6.6.3 Token Erteilung 

Der Benutzer initiiert das Protokoll mit seinem Smartphone Pu. In Su des 

Smartphones wird dann ein zufälliges Nonce generiert. Das Nonce und sein 

Benutzer IDu werden über Host Hu an Hersteller I gesendet. 

Hersteller I überprüft IDu, wenn es nicht in Revlist steht, wird eine Seriennummer(sn) 

für Token generiert, dann erzeugt I Authentizität-Schlüssel (K U,CS Auth ) für die 

Kommunikation zwischen Benutzer U und Cloud-SE CS, bzw. (K U,R Auth ) zwischen 

Benutzer U und Fahrzeug R; Der Delegation-Schlüssel K U 

Del und Token Tu für 

registrierte Fahrzeugbesitzer U werden auch erstellt. 

Der Token Tu ist so generiert, dass die Authentifizierung im großen Teil in dem 

cloud-SE CS durchgeführt werden muss. σ I ist mit Authentizität-Schlüssel (K CS Auth ) 

vom Cloud-SE signiert. Tu ist mit dem symmetrische Schlüssel (K CS Enc ) von CS 

U,I 

verschlüsselt. Alle diese Geheimnisse werden signiert(σ iss ) mit K Auth und 

verschlüsselt (c iss ) mit K U Enc . 

Abb. 24 Token Erteilung Protokoll 

In Su des Benutzer-Smartphones wird c iss entschlüsselt und die Authentizität geprüft. 

Wenn kein Problem, bekommt Su am Ende K Auth U,R , K Auth U,CS und K Del U zu speichern. 

Tu ist im Host Hu gespeichert. 

50


6.6.4 Benutzer Authentifizierung 

(1) Der Benutzer initiiert Authentifizierung mit dem Smartphone am Fahrzeug. 

Fahrzeug schickt ein Request mit Nonce und ID R an dem Smartphone zurück. 

(2) In Su des Smartphone wird ein Nonce Nu erzeugt, das Nonce und Benutzer 

IDu, und Zugriffsziel ID R werden als Nachrichten (m U ) gepackt, eine Signatur 

(σ U ) wird für die Nachrichten (m U ) generiert, Nachrichten und Signatur werden 

an den Host Hu geschickt. Der Host fügt noch das Zertifikat (cert P U ) und 

Token Tu zu, und schickt das Ganze an die Cloud. 

Abb. 25 Benutzer Authentifizierung Protokoll 

(3) Im Cloud-SE wird die Gültigkeit des Zertifikates, die Authentizität der 

Nachricht (m U ) geprüft. Dann entschlüsselt das Cloud-SE das Token Tu mit 

K Enc CS , prüft Authentizität (σ I .) von der in Tu enthaltene m I . Bei der letzten 

Prüfung ist zu schauen, ob Tu tatsächlich für Benutzer U erstellt ist (IDu 

Konsistent?). Wenn alles korrekt ist, wird ein Session-Key für den Benutzer U 

und Fahrzeug R generiert, dann werden vom Cloud-SE CS zwei 

51


verschlüsselte Nachrichten (c U , c R ) generieren, und an das Benutzer- 

Smartphone geschickt. 

(4) In Su wird c U entschlüsselt und der Session-Key extrahiert. Mit dem 

Session_Key wird die Nonce N R von R verschlüsselt (Response). Dann wird 

eine Response mit c R zusammen zu R geschickt. 

(5) R prüft die Nachrichten vom Smartphone, Wenn alles korrekt ist, wird Zutritt 

gewährt. 

6.6.5 Token Delegation 

(1) Reg. Besitzer U und Del. Benutzer D haben vorab über einen sicheren Weg 

ein einmaliges Password (pwd D ) vereinbart. Der Del. Benutzer D initiiert mit 

seiner ID D und pwd D Delegation-Prozess. In seinem S D werden ein Nonce 

(N D ) generiert und an seinen Host H D übermittelt, N D und seine ID D , sowie 

Zertifikat (cert P D ) werden von seinem Smartphone Host H D an den Host H U 

geschickt. 

(2) In Su wird die Gültigkeit des Zertifikats (cert P D ) vom Benutzer-Smartphone P D 

geprüft, und die Seriennummer (sn) der T D und Authentizität-Schlüssel (K Auth D ) 

generiert. sn, ID D und K Auth D werden als Nachricht (m U ) gepackt, ein σ U für m U 

wird berechnet. m U und σ U werden mit K Del U verschlüsselt, so entsteht T D . Ein 

Nonce(N del U ) wird generiert und σ del für die Authentizität der Nachrichten 

werden aus (pwd D , T D , T U , K Auth D , N del U , N del D ) berechnet. Verschlüsselt 

Nachrichten c del werden schließlich an der S D geschickt. 

Abb. 26 Token Delegation Protokoll 

52


(3) c del werden in S D entschlüsselt und ihre Authentizität geprüft. Wenn alles 

korrekt ist wird der Authentizität-Schlüssel K Auth D in S D gespeichert. T D und T U 

werden in H D gespeichert. 

6.6.6 Authentifizierung von delegiertem Benutzer 

Authentifizierung von delegiertem Benutzer D ist ähnlich wie bei der normalen 

Benutzer-Authentifizierung. Aber sowohl T D als auch T U muss an die Cloud 

übermittelt werden. Die Cloud-SE werden zuerst Tu prüfen und entschlüsseln, K Del 

U 

in Tu wird benutzt um T D zu entschlüsseln und K Auth D aus T D werden. Die andere 

schritte ist gleich wie in 6.6.4. 

6.6.7 Widerruf von Benutzer oder Token 

Widerruf von Benutzer und Token werden durch Eintragen der Benutzer ID und 

Seriennummer von Token im RevList realisiert. 

53

7 Zusammenfassung und Ausblick 


NFC-Smartphones mit sicherheitskritischen Anwendungen erfordern ein sicheres 

Element für Benutzer-Credentials. Die aktuellen Hardware-basierten Lösungen sind 

jedoch nicht wirklich flexibel und offen. In der Arbeit wurde der Einsatz des cloudbasierten 

sicheren Elements behandelt, mit dem Ziel, flexiblere, sicherere und 

rechenleistungsstärkere sichere Elemente für den Benutzer und die stetig 

zunehmenden mobilen Anwendungen zu bieten. Insbesondere für das in [6] [7] 

vorgestellte Zutrittskontroll-System. 

Aber die Nutzung eines Cloud-SEs über ein Smartphone ist nicht unkritisch. 

Abgesehen von den in Kapitel 4.2 erwähnten kritischen Punkten von Cloud 

Computing, ist das handelsübliche Smartphone selbst nicht sicher identifizierbar. Ein 

Angreifer kann sich als der jeweilige Benutzer ausgeben und versuchen über das 

Smartphone auf das Cloud-SE zuzugreifen. 

Um die Identität des Smartphones und die Kommunikation zwischen Smartphone 

und Cloud-SE zu sichern, wird in dieser Arbeit ein allgemein verfügbares Hardwarebasiertes 

SE angenommen, was nur für die Benutzer-Authentifizierung und die 

gegenseitige Authentifizierung des Smartphones und des entfernten Cloud-SE 

zuständig ist. 

Für ein Zutrittskontroll-System mit Hardware-SE und Cloud-SE wurde in der Arbeit 

eine Sicherheitsarchitektur auf der Basis von [6] [7] herausgearbeitet sowie eine 

Reihe von Protokollen entworfen. Die Protokolle sind für „Software as a Service“ [K. 

5.4.2 Typ B] konzipiert, mit der Annahme, dass der Service Provider sämtliche 

Cloud-SE und Anwendungen den Benutzern bereitstellt. In Bezug auf das Cloud-SE 

als eine Plattform [K. 5.4.2 Typ A] für verschiedene sichere Anwendungen müssen 

die Protokolle für die Kooperation und Integration zwischen den verschiedenen 

Service Providern, Cloud-SE Providern und Benutzer noch untersucht werden. 

Zur Benutzerauthentifizierung ohne Hardware-SE im Smartphone sind ebenso 

weitere Untersuchungen notwendig. Eine Richtung könnte „Implicit Authentication“ 

sein. Wegen der großen Speicher- und Rechen-Kapazität der Cloud, könnten in der 

Cloud viele Informationen vom Benutzer und dessen Smartphone gesammelt 

werden. Durch geeignete Algorithmen könnten diese Informationen ausgewertet und 

zur Authentifizierung genutzt werden. 

Zum Verbessern der Sicherheit des Smartphones ist externe Hardware für den 

Einsatz auch möglich. In Verbindung mit der technischen Weiterentwicklung und 

Miniaturisierung von Hardware kann eine dedizierte Sicherheits-Hardware dazu 

beitragen die Sicherheit von Smartphones zu verbessern. Z. B. hat Sony erst kürzlich 

eine Armbanduhr [51] angekündigt, welche mit NFC und Hardware-SE ausgestattet 

ist. 

Die in dieser Arbeit erwähnten Technologien, insbesondere Cloud Computing, sind 

zu einem Großteil noch in der Entwicklungsphase. Viele Dinge sind noch unklar und 

54


nicht standardisiert. Wenn all diese Technologien sich in naher Zukunft entsprechend 

weiterentwickeln, ist das Cloud-SE Thema sicherlich viel attraktiver als heute. 

Es besteht kein Zweifel, dass Cloud Computing, mobile Anwendungen und 

diesbezügliche Sicherheitsprobleme nun die häufigsten Gesprächsthemen des IT- 

Bereichs und künftige IT-Entwicklungstrends sind. Was hier besonders zu betonen 

gilt, ist die Sicherheit. Sicherheit ist eigentlich die grundlegendste technische Frage 

von Cloud Computing und mobilen Anwendungen. Die Bedeutung der Sicherheit 

kann man mit einem Satz zusammenfassen: Eine Entwicklung ohne Sicherheit ist die 

Entwicklung ohne Grundlage; nicht entwickelnde Sicherheit ist trügerische Sicherheit. 

Das heißt, Sicherheit ist der Grundstein für die nachhaltige Entwicklung des Cloud 

Computing und den mobilen Anwendungen. Mit den rasanten Entwicklungen und 

Aktualisierungen des Cloud Computing- und den mobilen Anwendungen bzw. 

Technologien muss sich die Sicherheitstechnologie auch dementsprechend ständig 

weiterentwickeln. 

55

Abbildungsverzeichnis 

Abbildungsverzeichnis 

Abb. 1 Ein typische RFID-System ................................................................................ 5 

Abb. 2 Smartcards mit und ohne Kontakte [14] ........................................................... 6 

Abb. 3 Unterteilung der Smartcards [15]...................................................................... 6 

Abb. 4 Überblick über die NFC Forum Architektur [3].................................................. 9 

Abb. 5 Drei Kommunikations-Modi (Graphik adaptiert von [17] )............................... 10 

Abb. 6 Touchpoint in Berliner S-Bahn Station „Zoologischer Garten.“ [4] ................. 11 

Abb. 7 Daten-Path zwischen verschiedene Komponente im Smartphone [24] ......... 15 

Abb. 8 Vergleich der Secure Elements [3] ................................................................. 16 

Abb. 9 NFC-Ökosystem .............................................................................................. 17 

Abb. 10 Cloud Nutzer und Cloud Anbieter [32] ......................................................... 20 

Abb. 11 Cloud-Geschäftsmodellen, IT-Ressourcen und Cloud Stack ....................... 22 

Abb. 12 Arten des Cloud Computing / Deployment Modelle ...................................... 23 

Abb. 13 Die wichtigsten Technologie- und Markttrends aus Sicht der ITK- 

Unternehmen 2012 ..................................................................................................... 25 

Abb. 14 Die wichtigsten Technologie- und Markttrends aus Sicht der ITK- 

Unternehmen 2013 ..................................................................................................... 26 

Abb. 15 Verschiedene Schnittstellen von Smartphone [2]........................................ 29 

Abb. 16 Generelle Multi-Level-Plattform Sicherheitsarchitektur [6] ........................... 30 

Abb. 17 Sicherheitsarchitektur mit cloud-basierten SE .............................................. 36 

Abb. 18 Cloud-basiertes SE als Plattform für mehre Anwendungen ......................... 39 

Abb. 19 Cloud-basiertes SE für einzelne Anwendung ............................................... 40 

Abb. 20 Systemmodell – Smart Keys mit Cloud-basierte SE .................................... 43 

Abb. 21 Funktionen in der Sicherheitsarchitektur ...................................................... 46 

Abb. 22 Authentifizierungsvorgang von Benutzer ...................................................... 47 

Abb. 23 Benutzer Registrierung Protokoll .................................................................. 49 

Abb. 25 Benutzer Authentifizierung Protokoll ............................................................. 51 

Abb. 26 Token Delegation Protokoll ........................................................................... 52 

VI

Tabelleverzeichnis 

Tabelleverzeichnis 

Tabelle 1 ISO-Norm 7816 ............................................................................................. 7 

Tabelle 2 ISO-Norm 14443 ........................................................................................... 8 

Tabelle 3 Authentifizierungsvorgang .......................................................................... 33 

Tabelle 4 Ökosystem von cloud-basierte SE ............................................................. 38 

VII

Literaturverzeichnis 


[1] Langer, Josef, und Michael Roland. Anwendungen und Technik von Near Field 

Communication. 2010. Aufl. Springer, 2010. 

[2] Coskun, Vedat, Kerem Ok, und Busra Ozdenizci. Near Field Communication 

(NFC): From Theory to Practice. 1. Auflage. John Wiley & Sons, 2012. 

[3] Markus Lorenz. "Secure Elements fur Smartphones". Diplomarbeit, 30. Mai 2013 

[4] „Deutsche Telekom: Intelligent car key in a cell phone“. Zugegriffen 25. Mai 2013. 

http://www.telekom.com/innovation/connectedcar/81840. 

[5] „Orange and Valeo demonstrate NFC car key concept • NFC World“. Zugegriffen 

25. Mai 2013. http://www.nfcworld.com/2010/10/07/34592/orange-and-valeodemonstrate-nfc-car-key-concept/. 

[6] A. Dmitrienko, A.-R. Sadeghi, S. Tamrakar, and C. Wachsmann. SmartTokens: 

Delegable access control with NFC-enabled smartphones. In 5th International 

Conference on Trust & Trustworthy Computing (TRUST’12), 2012. 

[7] Christoph Busold and Alexandra Dmitrienko and Hervé Seudié and Ahmed Taha 

and Majid Sobhani and Christian Wachsmann and Ahmad-Reza Sadeghi. Smart 

Keys for Cyber-Cars: Secure Smartphone-based NFC-enabled Car Immobilizer. 

ACM Conference on Data and Application Security and Privacy (ACM CODASPY). 

Feb, 2013 

[8] Martignoni, Lorenzo, Roberto Paleari, und Danilo Bruschi. „A Framework for 

Behavior-Based Malware Analysis in the Cloud“. In Information Systems Security, 

herausgegeben von Atul Prakash und Indranil Sen Gupta, 5905:178–192. Berlin, 

Heidelberg: Springer Berlin Heidelberg, 2009. http://air.unimi.it/handle/2434/139582. 

[9] Oberheide, Jon, Kaushik Veeraraghavan, Evan Cooke, Jason Flinn, und Farnam 

Jahanian. „Virtualized in-cloud security services for mobile devices“. In Proceedings 

of the First Workshop on Virtualization in Mobile Computing, 31–35. MobiVirt ’08. 

New York, NY, USA: ACM, 2008. doi:10.1145/1622103.1629656. 

[10] Chow, Richard, Markus Jakobsson, Ryusuke Masuoka, Jesus Molina, Yuan Niu, 

Elaine Shi, und Zhexuan Song. „Authentication in the clouds: a framework and its 

application to mobile users“. In Proceedings of the 2010 ACM workshop on Cloud 

computing security workshop, 1–6. CCSW ’10. New York, NY, USA: ACM, 2010. 

oi:10.1145/1866835.1866837. 

VIII


[11] „An Architecture To Provide Cloud Based Security Services For Smartphones.“ 

Cloud Computing Competence Center for Security. Zugegriffen 18. Juni 2013. 

http://www.cloud-competence-center.com/publications/an-architecture-to-providecloud-based-security-services-for-smartphones/. 

[12] Portokalidis, Georgios, Philip Homburg, Kostas Anagnostakis, und Herbert Bos. 

„Paranoid Android: versatile protection for smartphones“. In Proceedings of the 26th 

Annual Computer Security Applications Conference, 347–356. ACSAC ’10. New 

York, NY, USA: ACM, 2010. doi:10.1145/1920261.1920313. 

[13] „Welcome to TClouds“. Zugegriffen 2. Juni 2013. http://www.tclouds-project.eu/. 

[14] „Image28.jpg (JPEG-Grafik, 472 × 275 Pixel)“. Zugegriffen 25. Mai 2013. 

http://w3- 

o.cs.hm.edu/~chipcard/FWP_Chipkarten/SS99/marktforschung/Image28.jpg. 

[15] „Image27.jpg (JPEG-Grafik, 486 × 363 Pixel)“. Zugegriffen 25. Mai 2013. 

http://w3- 

o.cs.hm.edu/~chipcard/FWP_Chipkarten/SS99/marktforschung/Image27.jpg. 

[16] „NFC Forum: home“. Zugegriffen 18. Juni 2013. http://www.nfc-forum.org/home/. 

[17] Madlmayr, G., Ch Kantner, J. Scharinger, und I. Schaumüller-Bichl. „Eine mobile 

Service-Architektur für ein sicheres NFC-Ökosystem“. e & i Elektrotechnik und 

Informationstechnik 127, Nr. 5 (1. Mai 2010): 127–134. doi:10.1007/s00502-010- 

0732-3. 

[18] „NFC-Bezahltechnik: Handy und Smartphone als Geldbörse - Geld - 

Süddeutsche.de“. Zugegriffen 18. Juni 2013. http://www.sueddeutsche.de/geld/nfctelefon-als-geldboerse-mal-eben-schnell-mit-dem-handy-zahlen-1.1580720. 

[19] „[NFC] Das Smartphone als Fitness Trainer | mobile zeitgeist“. Zugegriffen 18. 

[20] „NFC Task Launcher: Smartphone automatisieren mit NFC-Tags“. Zugegriffen 

18. Juni 2013. http://www.androidnext.de/apps/nfc-task-launcher/. 

[21] „Bezahl-Sender: NFC-Technik macht das Smartphone zur Geldbörse - 

Nachrichten Wirtschaft - Webwelt & Technik - DIE WELT“. Zugegriffen 18. Juni 2013. 

Juni 2013. http://www.mobile-zeitgeist.com/2013/04/24/nfc-das-smartphone-alsfitness-trainer/. 

http://www.welt.de/wirtschaft/webwelt/article106338436/NFC-Technik-macht-das- 

Smartphone-zur-Geldboerse.html. 

IX


[22] „A-SIT - Secure Elements am Beispiel Google Wallet“. Zugegriffen 18. Juni 

[23] „Google-Forschung: Ein Ring als Passwortersatz - Golem.de“. Zugegriffen 18. 

Juni 

2013. http://www.a-sit.at/de/technologiebeobachtung/secure_elements_gwallet/index.php. 

2013.http://www.golem.de/news/google-forschung-ein-ring-als-passwortersatz- 

1301-97025.html. 

[24] M. Roland - Software Card Emulation in NFC-enabled Mobile Phones: Great 

Advantage or Security Nightmare? - 4th International Workshop on Security and 

Privacy in Spontaneous Interaction and Mobile Phone Use (IWSSI/SPMU 2012), 

Newcastle, Vereinigtes Königreich von Großbritannien und Nordirland, 2012, pp. 6 

[25] „Jetzt Startguthaben sichern | mpass o2 | Das einfache und schnelle 

Bezahlverfahren beim Online Shopping“. Zugegriffen 18. Juni 2013. 

http://www.mpass.de/o2/angebote. 

[26] „G&D | Trusted Service Manager: Der vertrauenswürdige Vermittler“. Zugegriffen 

18. Juni 2013. http://www.gide.com/de/trends_and_insights/tsm_for_nfc/trusted_service_manager/tsm_1.jsp. 

[27] „Mobile Financial Services | Mobile NFC and TSM Services“. Zugegriffen 18. 

Juni 2013. http://www.gemalto.com/telecom/linqus/mfs/mobile_nfc/. 

[28] „Trusted Service Manager | CorFire“. Zugegriffen 18. Juni 2013. 

http://www.corfire.com/products-services/tsm.php. 

[29] „TSM Software Solutions - Bell ID“. Zugegriffen 18. Juni 2013. 

http://www.bellid.com/solutions/ota-lifecycle-management. 

[30] „Forrester Research: TechRadarTM For Infrastructure & Operations 

Professionals: Cloud Computing, Q4 2011“. Zugegriffen 18. Juni 2013. 

http://www.forrester.com/TechRadar+For+Infrastructure+Operations+Professionals+ 

Cloud+Computing+Q4+2011/fulltext/-/E-RES60916?docid=60916. 

US [31] Peter Mell, Timothy Grance, “The NIST Definition of Cloud Computing”, NIST 

National Institute of Standards and Technology U.S. Department of Commerce, 

Speicial Publication 800-145, September 2011] 

[32] „cloud_computing.jpg (JPEG-Grafik, 606 × 311 Pixel)“. Zugegriffen 25. Mai 2013. 

http://www.wifinotes.com/img/cloud_computing.jpg. 

X


[33] Neng-hai Yu, Zhou Hao, Jia-jia Xu, Wei-ming Zhang, Chi Zhang “Review of 

Cloud Computing Security”, ACTA ELECTRONICA SINICA, 0372-2112 (2013)02- 

0371-011, Feb. 2013 

[34] „Umfrage: Cloud-Computing bleibt auch 2012 Top-Trend der ITK-Branche“. 

Zugegriffen 22. Juni 2013. http://www.zdnet.de/41559461/umfrage-cloud-computingbleibt-auch-2012-top-trend-der-itk-branche/. 

[35] „Die wichtigsten Hightech-Themen 2013 (BITKOM-Grafik) - BITKOM“. 

Zugegriffen 23. Juni 2013. http://www.bitkom.org/de/presse/30739_74757.aspx. 

[36] „Inside Secure to offer cloud-based NFC secure element solution • NFC World“. 

Zugegriffen 23. Juni 2013. http://www.nfcworld.com/2012/09/25/318059/insidesecure-to-offer-cloud-based-nfc-secure-element-solution/. 

[37] „Ethertrust | EtherTrust market software for smart cards and design innovative 

solutions that strengthen the security of WEB applications whilst, dramatically 

simplifying their use.“ Zugegriffen 23. Juni 2013. 

http://www.ethertrust.com/resources/web/Cloud_Secure_elements.pdf. 

[38] „SimplyTapp proposes secure elements in the cloud • NFC World“. Zugegriffen 

23. Juni 2013. http://www.nfcworld.com/2012/09/19/317966/simplytapp-proposessecure-elements-in-the-cloud/. 

[39] „Bell ID launches NFC secure element in the cloud platform • NFC World“. 

Zugegriffen 23. Juni 2013. http://www.nfcworld.com/2013/06/05/324381/bell-idlaunches-nfc-secure-element-in-the-cloud-platform/. 

[40] „OMAPTM Mobile Processors - Security“. Zugegriffen 24. Juni 2013. 

http://www.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigatio 

nId=12316&contentId=4629&DCMP=WTBU&HQS=Other+EM+m-shield. 

[41] „TrustZone - ARM“. Zugegriffen 24. Juni 2013. 

http://www.arm.com/products/processors/technologies/trustzone.php. 

[42] „NFC phones replace room keys and eliminate check-in at Swedish hotel • NFC 

World“. Zugegriffen 24. Juni 2013. http://www.nfcworld.com/2010/11/03/34886/nfckeys-hotel-sweden/. 

[43] „VingCard Elsafe’s NFC Locking Solution Wins Prestigious Gaming Industry 

Technology Award; Next-Generation Hospitality Access System Honored By Casino 

Enterprise Management’s HOT Awards. / August 2011“. Zugegriffen 24. Juni 2013. 

http://www.hotel-online.com/News/PR2011_3rd/Aug11_VingCardHOT.html. 

[44] Kiraz, Mehmet Sabır, Muhammed Ali Bingöl, Süleyman Kardaş, und Fatih 

Birinci. „Anonymous RFID Authentication for Cloud Services“. International Journal of 

Information Security Science 1, Nr. 2 (2. Juli 2012): 32–42. 

[45] McAfee Labs: McAfee threats report: Third quarter 2011. 

XI


http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q3-2011.pdf 

[46] Labs: McAfee threats report: First quarter 2011. 

http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q1-2013.pdf 

[47] „Analysis of NFC Attack Surface — Jathan’s Event Notes 1.1 documentation“. 

Zugegriffen 28. Juni 2013. https://jathanism-eventnotes.readthedocs.org/en/latest/blackhat_2012/talks/nfc_attack_surface.html#nfcbasics. 

[48] „Hyundai shows off NFC car key concept • NFC World“. Zugegriffen 28. Juni 

2013. http://www.nfcworld.com/2013/01/08/321777/hyundai-shows-off-nfc-car-keyconcept/. 

[49] „Continental tests NFC car keys • NFC World“. Zugegriffen 28. Juni 2013. 

http://www.nfcworld.com/2013/04/10/323407/continental-tests-nfc-car-keys-inbordeaux/. 

[50] „NXP launches NFC car key • NFC World“. Zugegriffen 28. Juni 2013. 

http://www.nfcworld.com/2011/06/22/38196/nxp-launches-nfc-car-key/. 

[51] „Sony launches smart watch with NFC • NFC World“. Zugegriffen 1. Juli 2013. 

http://www.nfcworld.com/2013/06/25/324766/sony-launches-smart-watch-with-nfc/. 

XII

Anhang 

Anhang 

Anhang A: Benutzer Registrierung Protokoll 

Anhang B: Token Erteilung Protokoll 

Anhang C: Benutzer Authentifizierung Protokoll 

Anhang D: Token Delegation Protokoll 

XIII

Reg. Besitzer U TrEE S U 

Host H U Hersteller I 

pwd U sk U P cert U P pwd U 

ID U , pwd U 

(1) 

N U reg ∈ R {0, 1} µ 

ID U , N U reg 

ID U , N U reg, cert U P 

(2) 

ID U 

? 

/∈ RevList 

cert U P valid? 

cert U ? 

P /∈ RevList 

Abort if any of the above checks fails 

K U,I 

Auth 

∈R {0, 1}α 

(3) 

K U Enc ← Genkey(1 δ ) 

N I reg ∈ R {0, 1} µ 

K ← RO(N I reg, N U reg, pwd U ) 

σ I reg ← RO(K, ID I, ID U , K U,I 

Auth , KU Enc) 

c reg 

c reg 

Extract pk U P 

from cert U P 

c reg ← Enc(pk U P ; K U,I 

Auth , KU Enc, N I reg, σ I reg) 

(K U,I 

Auth , KU Enc, N I reg, σ I reg) ← Dec(sk U P ; c reg) 

K ← RO(N I reg, N U reg, pwd U ) 

σreg 

I ? 

= RO(K, ID I, ID U , K U,I 


(4) 

Abort if the above check fails 

Store (K U,I 


σ U reg ← RO(N I reg, ID U , ID I) 

σ U reg 

σ U reg 

σ U reg 

? 

= RO(N I reg, ID U , ID I) 


Store (K U,I 

, K U Enc)

Reg. Besitzer U TrEE S U 

Host H U Hersteller I 

pwd U 

K U,I 

Auth , KU Enc 

K R Auth , KR Enc ; KU,I Auth , KU Enc ; KCS Auth , KCS Enc ; RevList, pwd U 

ID U 

N iss ∈ R {0, 1} µ 

ID U , N iss 

ID U , N iss 

ID U 

ciss 

(T U , K U,R 

Auth , KU,CS Auth , KU Del , σ iss) ← Dec(KEnc U ; C iss) 

? 

σ iss = RO(K 

U,I 

Auth , T U , K U,R 

Auth , KU,CS Auth , KU Del , N iss) 


else: Store (K U,R 

Auth , KU,CS Auth , KU Del ) T U 

Store T 

c iss 

? 

/∈ RevList 

Abort if above checks fails 

sn ∈ R {0, 1} β 

K U,CS 

Auth ∈ R {0, 1} γ 

K U,R 

Auth ∈ R {0, 1} α 

K U Del ← Genkey(1δ ) 

m I := (sn, ID U , K U,R 

Auth , KU,CS Auth , KU Del ) 

σ I := RO(KAuth CS , m I) 

T U := Enc(KEnc CS ; m I, σ I ) 

σ iss ← RO(K U,I 

Auth , T U , K U,R 

Auth , KU,CS Auth , KU Del , N iss) 

c iss ← Enc(K U Enc ; T U , K U,R 

Auth , KU,CS Auth , KU Del , σ iss)

Reg. Besitzer U 

Start auth 

(2) 

(4) 

TrEE S U 

Host H U 

Fahrzeug R 

K U,R 

Auth , KU,CS Auth 

cert U P , T U KEnc 

R 

(K U,R 

Session , ID U , ID R , N U , N R ) ← Dec(skP U ; c U ) 

Response ← Enc(K U,R 

Session ; N R) 

Cloud-SE CS 

KEnc U , KR Enc , KCS Auth , KCS Enc 

Start auth 

N R ∈ R {0, 1} β (1) 

NR , ID 

N R , ID R 

R 

N U ∈ R {0, 1} µ 

m U = (ID U , ID R , N U ) 

σ U ← RO(K U,CS 

Auth , m U ) 

m U , σ U 

m U , σ U , cert U P , T U 

cert U ? 


? 

σ U = RO(K 

CS 

Auth , m U ) 

(m I , σ I ) ← Dec(KEnc CS ; T U ) 

? 

σ I = RO(K 

CS 

Auth , m I) 

? 

(3) sn ⊆ m I /∈ RevList 

? 

(ID U ⊆ m U = IDU ⊆ m I )& /∈ ? RevList 


Extract pkP 

U form certU P 

K U,R 

Session ∈ R {0, 1} δ 

c U ← Enc(pkP U ; K U,R 

Session 

, IDU , IDR, NU , NR) 

c R ← Enc(KEnc R 

c 

c U , c ; KU,R Session , ID U ) 

R 

U 

Response 

Response, c R 

(K U,R 

Session , ID U ) ← Dec(KEnc R ; c R) 

? 

ID U /∈ RevList 

N R ← Dec(K U,R 

Session ; Response) 

(5) 

? 

N R = NR ⊆ c R 

Reject if the above check fails, else Open

else: Store K D Auth T D , T U 

Store (T D , T U ) 

Del. Benutzer D TrEE S D 

Host H D Host H U 

pwd D skP D cert D P T U 

TrEE S U 

K U,CS 

Auth , KU Del, RevList 

Reg. Besitzer U 

pwd D 

ID D , pwd D 

Ndel D ∈ R {0, 1} µ 

(1) 

ID D , N D del 

ID D , N D del , certD P 

ID D , N D del , certD P , T U 

(2) 

ID D , pwd D 

cert D P valid? 

cert D ? 


Abort if any of the above checks fails 

sn ∈ R {0, 1} β 

KAuth D ∈ R {0, 1} α 

m U := (sn, ID D , K D Auth ) 

σ U := RO(K U,CS 

Auth , m U ) 

T D := Enc(K U Del ; m U , σ U ) 

N U del ∈ R {0, 1} µ 

σ del ← RO(pwd D , T D , T U K D Auth , N U del , N D del ) 

c del 

c del 

c del 

Extract pkP 

D from certD P 

c del ← Enc(pkP D; T D, T U , KAuth D , N del U , σ del) 

(T D , T U , K D Auth , NU del , σ del ) ← Dec(skD P ; σ del ) 

(3) 

σ del 

? = RO(pwdD , T D , T U , K D Auth , NO del , NU del ) 

Abort if the above check fails

Erklärung 

Erklärung 

Hiermit erkläre ich gemäß § 31 Abs. 7 der Rahmenprüfungsordnung, dass ich die 

vorliegende Arbeit mit dem Titel “Benutzung von cloud-basierten sicheren Elementen 

für NFC-Smartphone im Fahrzeug-Kontext” selbständig verfasst, noch nicht 

anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen 

Quellen oder Hilfsmittel benützt sowie wörtliche und sinngemäße Zitate als solche 

gekennzeichnet habe. 

Stuttgart, den 30. Juni 2013 

_______________________ 

Unterschrift 

XIV

Master- Arbeit - Lehrstuhl für Technische Informatik - Universität ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?