Hochschule Wismar

Hochschule Wismar

Fakultät für Wirtschaftswissenschaften

Master-Thesis

Kryptografie und Verbindungsmanagement von Smart Meter Gateways

Thesis zur Erlangung des Grades eines

Master of Science (M. Sc.)

eingereicht von: Ingo Krützen

geboren am 17. November 1988 in Aachen Studiengang Wirtschaftsinformatik,

Betreuer: Prof. Dr. Jan Helmke weitere Gutachter: Prof. Dr. Jürgen Cleve

Aachen, den 25. September 2013

I. I

I. INHALTSVERZEICHNIS ... I II. ABBILDUNGSVERZEICHNIS ... III III. TABELLENVERZEICHNIS ... IV IV. ABKÜRZUNGSVERZEICHNIS ... V

1 EINLEITUNG ... 1

1.1. MOTIVATION ... 1

1.2. ZIEL ... 3

1.3. LÖSUNGSANSATZ ... 5

1.4. WISSENSCHAFTLICHE EINORDNUNG ... 7

1.5. ABGRENZUNG ... 8

2 GRUNDLAGEN ... 9

2.1. GRUNDBEGRIFFE ... 9

2.1.1 Smart Meter ... 9

2.1.2 Smart Meter Gateway ... 11

2.1.3 Gateway Administrator ... 11

2.1.4 Hardware Security Module (HSM) ... 12

2.2. KRYPTOGRAFIE ... 13

2.2.1 Symmetrische Verschlüsselung ... 13

2.2.2 Asymmetrische Verschlüsselung ... 14

2.2.3 Hybride Verschlüsselung ... 16

2.2.4 Digitale Signaturen ... 17

2.2.5 Diffie Hellman ... 20

2.2.6 Elgamal ... 22

2.3. TECHNOLOGIEN ... 25

2.3.1 Webservice ... 25

2.3.2 Transport Layer Security (TLS) ... 30

2.3.3 Message Protection ... 34

2.3.4 Sharding ... 35

2.4. SOFTWARE ... 36

2.4.1 Apache Zookeeper ... 36

2.4.2 Pacemaker ... 36

2.4.3 Apache Cassandra ... 36

3 ANFORDERUNGSANALYSE ... 38

3.1. NICHTFUNKTIONALE ANFORDERUNGEN ... 39

3.1.1 CryptoProxy ... 39

3.1.2 SigningAPI ... 44

3.1.3 PKI-Manager ... 47

3.2. FUNKTIONALE ANFORDERUNGEN... 49

3.2.1 CryptoProxy ... 49

3.2.2 SigningAPI ... 53

3.2.3 PKI-Manager ... 55

4 KONZEPT ... 60

4.1. G^ROBDESIGN ... 60

4.2. FEINDESIGN ... 66

4.2.1 CryptoProxy ... 66

4.2.2 PKI-Manager ... 79

5 SCHLUSSBETRACHTUNG ... 91

5.1. K^RITISCHE W^ÜRDIGUNG ... 91

5.2. FAZIT UND AUSBLICK ... 93 V. LITERATURVERZEICHNIS ... VI VI. EIDESSTATTLICHE ERKLÄRUNG ... XX VII. ANHANG ... VIII VI.I. BSI-SPEZIFIKATION: ... VIII VI.II. SEQUENZDIAGRAMME: ... IX

II. A

Abbildung 1-1 Ziel ... 3

Abbildung 1-2 Lösungsansatz ... 6

Abbildung 2-1 Smart Meter ... 9

Abbildung 2-2 Smart METER Web-Interface ... 10

Abbildung 2-3 Smart-Meter-APP ... 10

Abbildung 2-4 Atos security module ... 12

Abbildung 2-5 Symmetrische Verschlüsselung... 13

Abbildung 2-6 Asymmetrische Verschlüsselung I ... 14

Abbildung 2-7 Asymmetrische Verschlüsselung II ... 15

Abbildung 2-8 Hybride Verschlüsselung ... 16

Abbildung 2-9 Signaturerzeugung ... 18

Abbildung 2-10 Signaturerzeugung ... 19

Abbildung 2-11 TLS-Verbindung ... 33

Abbildung 2-12 Message Protection ... 34

Abbildung 2-13 Database-Sharding ... 35

Abbildung 4-1 Grobdesign ... 60

Abbildung 4-2 Sharding I ... 62

Abbildung 4-3 Sharding II ... 63

Abbildung 4-4 Sharding III ... 64

Abbildung 4-5 CryptoProxy-Klasse ... 66

Abbildung 4-6 CertificateToChannelMap-Klasse ... 66

Abbildung 4-7 CryptoProxyChannelHandler-Klasse ... 67

Abbildung 4-8 CertificateStorage-Klasse ... 67

Abbildung 4-9 PKI-Manager-Klasse ... 80

Abbildung 4-10 CertificateStorage-Klasse ... 81

Abbildung 4-11 CrlManager-Klasse ... 82 Abbildung VI-1 ASM gesicherte TLS-Zugänge (connect) ... IX Abbildung VI-2 ASM gesicherte TLS-Zugänge (disconnect)... X Abbildung VI-3 GWA/EMT-Kanal (ADMIN und INFO-Report) ... XI Abbildung VI-4 GW-Kanal (Management) ... XII Abbildung VI-5 Management Request (von GWA nach GW) ... XIII Abbildung VI-6 Zertifikatsanfrage ... XIV Abbildung VI-7 Zertifikate für EMT oder GWA erzeugen (CSR, asynchron) ... XV Abbildung VI-8 Zertifikate für EMT oder GWA erzeugen (CSR, synchron) ... XVI Abbildung VI-9 Zu überwachendes Zertifikat hinzufügen ... XVII Abbildung VI-10 CRL abfragen und prüfen ... XVIII Abbildung VI-11 Ablaufende Zertifikate identifizieren ... XIX

III. T

Tabelle 3-1 Verfügbarkeitsklassen ... 40

Tabelle 3-2 Availability Environment Classification ... 41

Tabelle 4-1 IP-Adressen-Aufteilung ... 61

Tabelle 4-2 Verbindungsaufbau SMGW, Eingabeparameter ... 68

Tabelle 4-3 Verbindungsabbau SMGW, Eingabeparameter ... 69

Tabelle 4-4 Admin-Anfrage verarbeiten, Eingabeparameter ... 70

Tabelle 4-5 Admin-Anfrage verarbeiten, Ausgabeparameter ... 70

Tabelle 4-6 Info-Report verarbeiten, Eingabeparameter ... 71

Tabelle 4-7 Info-Report verarbeiten, Ausgabeparameter ... 71

Tabelle 4-8 Logging-Event, Eingabeparameter ... 72

Tabelle 4-9 Management-Anfragen verarbeiten, Eingabeparameter ... 73

Tabelle 4-10 Management-Anfragen verarbeiten, Ausgabeparameter ... 73

Tabelle 4-11 Daten signieren, Eingabeparameter ... 74

Tabelle 4-12 Daten signieren, Ausgabeparameter ... 74

Tabelle 4-13 Signieren WakeUp Call, Eingabeparameter ... 75

Tabelle 4-14 Signieren WakeUp Call, Ausgabeparameter ... 75

Tabelle 4-15 Wiederherstellen von Daten, Eingabeparameter ... 76

Tabelle 4-16 Wiederherstellen von Daten, Ausgabeparameter ... 76

Tabelle 4-17 Signaturprüfung, Eingabeparameter ... 77

Tabelle 4-18 Signaturprüfung, Ausgabeparameter ... 77

Tabelle 4-19 Zertifikate erzeugen, Eingabeparameter ... 78

Tabelle 4-20 Zertifikate erzeugen, Ausgabeparameter ... 78

Tabelle 4-21 Event für ablaufende Zertifikate, Eingabeparameter ... 83

Tabelle 4-22 Event für gesperrte Zertifikate, Eingabeparameter ... 84

Tabelle 4-23 Zertifikat erhalten, Eingabeparameter ... 85

Tabelle 4-24 Zertifikat erhalten, Ausgabeparameter ... 85

Tabelle 4-25 Zertifikate hinzufügen, Eingabeparameter ... 86

Tabelle 4-26 Zertifikate hinzufügen, Ausgabeparameter ... 86

Tabelle 4-27 Zertifikate entfernen, Eingabeparameter ... 87

Tabelle 4-28 Zertifikatsanfrage verarbeiten, Eingabeparameter ... 88

Tabelle 4-29 Zertifikatsanfrage verarbeiten, Ausgabeparameter ... 88

Tabelle 4-30 Prüfung des Ablaufdatums, Eingabeparameter ... 89

Tabelle 4-31 Prüfung der Sperrungen, Eingabeparameter ... 90

IV. A

ASM Atos Security Module

AWL CP Atos Worldline Crypto Proxy AWL PKIM Atos Worldline PKI-Manager AWL SIGN Atos Worldline Signing-API

API Application programming interface CA Certificate Authority

CRL Certificate Revocation List CSR Certificate Signing Request DN Distinguished Name

DP Distribution Point

ENC Encryption

EMT Externer Marktteilnehmer

EMT-Kern Kernsystem eines externen Marktteilnehmers GWA Smart Meter Gateway Administrator

GWA-Kern Kernsystem eines Smart Meter Gateway Administrators HSM Hardware Security Module

HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure JSON JavaScript Object Notation

LAN Local Area Network MSB Messstellenbetreiber NTP Network Time Protocol PKI Public Key Infrastructure RA Registration Authority

RSA Rivest, Shamir und Adleman SAN Storage Area Network

SIG Signature

SNTP Simple Network Time Protocol

SM Smart Meter

SMGW Smart Meter Gateway

SM-PKI Smart Meter Public Key Infrastructure TLS Transport Layer Security

TP Network Time Protocol URI Uniform Resource Identifier URL Uniform Resource Locator WAN Wide Area Network

XHTML Extensible Hypertext Markup Language XML Extensible Markup Language

Motivation

1 E

1.1.

Atos Worldline ist ein Anbieter von IT-Dienstleistungen. Die Kompetenzbereiche umfassen Beratung, Systemintegration, Outsourcing sowie Hi-Tech Transactional Services. Ein umfangreicher Arbeitsbereich besteht auch in der Ausarbeitung von verschiedenen Sicherheitslösungen und –konzepten. Das derzeit auszuarbeitende Konzept behandelt die Problemstellung der sicheren Verbindung von intelligenten Strom-, Wasser- oder Gaszählern zu ihren Netzbetreibern oder Messstellenbetreibern. Ein Netzbetreiber kann entweder selber Messstellenbetreiber sein und so die Messdaten empfangen und verarbeiten oder einen Dienstleister hierzu beauftragen. Die intelligenten Zähler sollen in der Lage sein, die Verbrauchsinformationen der Haushalte in Deutschland an den Messstellenbetreiber zu übermitteln.

Zusätzlich ermöglichen die neuartigen Zähler das tägliche Ablesen der Verbrauchs- informationen sowie eine grafische Darstellung des gesamten Verbrauches.

Diese intelligenten Zähler werden auch Smart Meter (SM) genannt. Um die Anbindung der Smart Meter an einen Anbieter zu verwirklichen, wird eine Sicherheitslösung benötigt, die eine sichere Verbindung gewährleistet. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat hierzu eine Spezifikation erstelt, die in Deutschland eingehalten werden muss.

In jedem Haus in Deutschland wird es mindestens einen Zähler geben, in jedem Mehrfamilienhaus einen für jede Wohneinheit. Zusätzlich muss auch für jede Solaranlage ein Zähler angebracht werden. Alle Zähler in einer Straße werden an einen sogenannten Smart Meter Gateway (SMGW) angeschlossen. Dieser übernimmt den Aufbau der Transport-Layer-Security(TLS)-Verbindung sowie die Übermittlung der Daten.

Motivation Jeder Zähler versendet je nach Konfiguration (in einem Abstand von mindestens 15 Minuten) die Verbrauchsdaten an den Messstellenbetreiber (MSB), den Netzbetreiber. Aufgrund des großen Aufwands und der hohen Investitionen durch Rechenzentren und Zertifizierungen wird die Anzahl der Netzbetreiber, die dieses System hosten, sehr gering bleiben; kleinere Netzbetreiber werden sich diesen Aufwand nicht leisten können. Die Anzahl der angeschlossenen SMGW wird jedoch sehr groß sein. Dadurch wird auch die Anzahl der Verbindungen zu jedem Netzbetreiber eine nicht zu unterschätzende Größe annehmen. Zusätzlich wird vom Bundesamt für Sicherheit in der Informationstechnik neben der Hybrid- Verschlüsselung und der TLS-Verbindung eine weitere Verschlüsselung vorgeschrieben. Alle symmetrisch verschlüsselten Daten müssen zusätzlich noch einmal asymmetrisch verschlüsselt werden. Die erneute Verschlüsselung macht die Verbindung zwar noch sicherer, ist jedoch auch dafür verantwortlich, dass das Abarbeiten einer Anfrage wesentlich länger dauert, da eine asymmetrische Verschlüsselung sehr viel Zeit in Anspruch nimmt. Der asymmetrische Verschlüsselungsalgorithmus benötigt wesentlich mehr Zeit als ein symmetrischer.

Wenn in jeder Straße in Deutschland ein SMGW installiert ist, ist die Anzahl der Verbindungen statisch und wird nur noch gering variieren, sobald in ganz Deutschland alle SMGW ausgerollt wurden. In der gesamten Bundesrepublik werden daher und aufgrund der wenigen Netzbetreiber eine sehr große Anzahl von Verbindungen zu verwalten sein, die die Verbrauchsdaten an den Messstellenbetreiber senden. Hier muss dafür gesorgt werden, dass das Senden der Daten jeder Verbindung bis zum nächsten Senden abgeschlossen ist, da sonst ein Stau und Timeouts entstehen.

Ziel

ZIEL

1.2.

Das Ziel dieser Arbeit ist es, eine Sicherheitslösung zu entwickeln, welche die tatsächliche Einführung der SM und SMGW in Deutschland möglich und sicher macht. Das hauptsächliche Ziel liegt in der sicheren Verbindung zwischen dem SMGW und dem Netzbetreiber.

Die zu entwickelnde Sicherheitslösung besteht aus der Verwaltung der TLS- Verbindung; hierzu gehören der Aufbau, die Speicherung und der Abbau der Verbindung. Außerdem ist die Kryptografie, d. h. das Verschlüsseln der Informationen, ein Bestandteil der Sicherheitslösung. Diese wird für die Verbindung, aber auch für die zusätzliche asymmetrische Verschlüsselung benötigt.

Im Smart-Meter-Umfeld gibt es fünf verschiedene Teilnehmer, die für die Verbindung untersucht werden müssen. Hierzu gehören

- die Smart Meter (SM),

- die dazugehörigen Smart Meter Gateways (SMGW), - die Gateway-Administratoren (GWA),

- die Messstellenbetreiber (MSB) oder auch externe Marktteilnehmer (EMT) - sowie das zu konzeptionierende System für die Verbindung und Kryptografie

sowohl zwischen EMT und SMGW als auch zwischen GWA und SMGW.

Dieses System wird in der Abbildung 1-1 als „?“ dargestellt, da dieses System zu entwerfen ist.

Diese Teilnehmer stehen in folgender Beziehung (s. Abbildung 1-1):

Abbildung 1-1 Ziel Quelle: Eigene Darstellung

Ziel Ziel der Masterarbeit ist es, für die Verbindung zwischen GWA und Gateways sowie zwischen EMT und Gateways ein System zu konzeptionieren, welches das Verbindungsmanagement sowie die gesamte Kryptografie für EMT und GWA übernimmt.

Technische sowie fachliche Anforderungen an dieses System müssen definiert und analysiert werden.

Zusätzlich soll eine Cluster-Lösung entwickelt werden, die die Hochverfügbarkeit gewährleistet.

Ein Design der verschiedenen benötigten Systeme muss geplant und ausgearbeitet werden. Hierzu werden Sequenzdiagramme sowie Klassendiagramme erstellt.

Es muss zusätzlich getestet werden, wie viele Anfragen mit wie vielen Maschinen abgearbeitet werden können. Hierzu sollen entsprechende Benchmarks erstellt werden. Das größte Augenmerk wird hierbei auf die Hardware-Security-Module gelegt, da die Verschlüsselung der Daten der größte Erfolgsfaktor ist und den meisten Zeitaufwand beansprucht.

Da das Erreichen der Benchmarks von unterschiedlichen Faktoren abhängt, die nicht beeinflussbar sind, sondern vielmehr von der Verfügbarkeit und Qualität benötigter Informationen abhängen, ist dieses Ziel optional zu sehen.

Die Spezifikation, die vom Bundesamt für Sicherheit in der Informationstechnik zur Verfügung gestellt wurde, ist noch nicht endgültig fertiggestellt. Hier kann es noch Abweichungen geben. Zusätzlich werden andere Faktoren wie die Hardwarebeschaffung sowie die Planung der Workshops mit mehreren Kunden eine Rolle spielen.

Lösungsansatz

LÖSUNGSANSATZ

1.3.

Das zu konzeptionierende System muss unterschiedliche Funktionen behandeln können. Daher sind die unterschiedlichen Funktionen in verschiedene Komponenten auszugliedern. Als Überbegriff für das entstehende Produkt hat sich CryptoProxy herauskristallisiert. Der Name ergibt sich aus der Kryptografie und der Eigenschaft, dass das System zwischen zwei Teilnehmern als Proxy fungiert.

Als Komponenten sind hier folgende Funktionen auszugliedern:

- Verschlüsseln, Entschlüsseln und Signieren von Daten,

- Generierung und Speicherung der Schlüssel, der Berechnung der Signatur usw.,

- das Herunterladen von Zertifikaten und die Verwaltung der verschiedenen Zertifikate,

- die BSI-spezifische Nachrichtenverschlüsselung, Signierung und Entschlüsselung sowie

- das eigentliche Verwalten der TLS-Verbindungen

Zusätzlich sollen die Funktionen zum Verschlüsseln, Signieren und Entschlüsseln von Daten in eine eigenständige Anwendung ausgelagert werden. Das Gleiche gilt für das Herunterladen von „Issuer“- und „Intermediate“-Zertifikaten sowie für deren Verwaltung. „Issuer“-Zertifikate sind Zertifikate des Zertifikatsherausgebers. Mit diesem Zertifikat, welches auch Root-Zertifikat genannt wird, werden die unterschiedlichen „Intermediate“-Zertifikate signiert. Diese „Intermediate“-Zertifikate sind Zwischenzertifikate und werden wiederum genutzt, um das Zertifikat des elektronischen Marktteilnehmers zu signieren.

Ein Zwischenzertifikat kann zum Beispiel einem Sub-Unternehmen gehören, das das Signieren der Zertifikate an Dritte vertreibt.

Aus den Funktionen ergeben sich die Namen der Komponenten:

- CryptoProxy

o TLS-Channelmanagement (Verwaltung der TLS-Verbindungen)

o Message Protection (übernimmt die BSI-spezifische Nachrichten- verschlüsselung)

o ASM (Atos Security Module, ein Hardware-Security-Modul der Firma Atos Worldline GmbH)

- PKI-Manager (Public key Infrastructure, Verwaltung der Zertifikate)

- Signing API (API zur Berechnung von Verschlüsselungen und Signaturen, kommuniziert als Einzige mit ASM)

Lösungsansatz Hieraus ergibt sich bereits ein grober Überblick, der als Lösungsansatz genutzt werden kann (s. Abbildung 1-2).

Abbildung 1-2 Lösungsansatz Quelle: Eigene Darstellung

Wissenschaftliche Einordnung

WISSENSCHAFTLICHE EINORDNUNG

1.4.

Die IT-Sicherheit ist ein großer und wichtiger Bereich der Wirtschaftsinformatik.

Aufgabe der IT-Sicherheit ist es, Schäden in Informationssystemen zu vermeiden.

Ein solches Informationssystem soll in dieser Arbeit konzeptioniert werden. Als Teil des Gesamten muss auch das gesamte System gesichert sein. Die Kryptografie sowie der Aufbau von sicheren Verbindungen ist einer der wichtigsten Faktoren in der IT-Sicherheit.

Als sichere Verbindung wird eine TLS-Verbindung genutzt. Auch hier ist die Kryptografie ein wichtiger Bestandteil der Verbindung. TLS-Verbindungen nutzen nicht nur eine symmetrische oder eine asymmetrische Verschlüsselung, sondern eine hybride Verschlüsselung.

Das Verbindungsmanagement sowie die TLS-Verbindungen sind zusätzlich noch von betriebswirtschaftlicher Bedeutung. Jeder Online-Shop benötigt eine sichere Verbindung, damit Kunden im Shop bezahlen können. Das Verbindungsmanagement ist wichtig, um garantieren zu können, dass mehrere Kunden gleichzeitig bezahlen können.

Zahlungsdaten oder Messdaten sind vertrauliche Informationen und müssen daher besonders sensibel behandelt werden. Sie dürfen nicht von Dritten gelesen werden oder gar verfälscht werden können. Eine sichere TLS-Verbindung macht auch dies möglich.

Außerdem zählt die Schlüsselaufbewahrung und Handhabung zu einer der kritischsten Aufgaben in der IT-Sicherheit. Hierzu werden Hardware-Security-Module genutzt, welche diese Aufgabe übernehmen.

Die unterschiedlichsten Unternehmungen müssen im Bereich der Wirtschaftsinformatik herausfinden, welche Sicherheit sie benötigen und welche Sicherheit für sie am wirtschaftlichsten ist. In der Wirtschaftsinformatik wird die IT- Sicherheit nicht nur als ein großer Kostenfaktor gesehen, die abgewehrten Schäden werden den Kosten entgegengesetzt. Hierdurch können Maßnahmen begründet werden, die die Sicherheit der Informationssysteme oder andere Bereiche der IT- Sicherheit gewährleisten.

Verursacht zum Beispiel der Diebstahl von Daten nur einen geringen Schaden, so ist es wirtschaftlicher, seine Daten nur auf einem kostengünstigen Niveau zu sichern.

Werden jedoch Verbraucherdaten verarbeitet und verschickt, so trägt in Deutschland das Bundesamt für Sicherheit in der Informationstechnik die Verantwortung dafür, dass die Lösungen der Unternehmen die Daten schützen und die Datenschutzrichtlinien einhalten.

Aus Datenschutzgründen müssen die Daten so gesichert werden, dass unter keinen Umständen ein Unbefugter die Daten lesen oder auswerten kann.

Auch wenn der CryptoProxy diese Daten annimmt und weiterleitet, darf dieser die Messdaten nicht auslesen können.

Abgrenzung

ABGRENZUNG

1.5.

Das Clusterkonzept beinhaltet mehrere CryptoProxys. Die einzelnen Elemente des CryptoProxys müssen definiert werden. Hierzu dient ein Teil der Arbeit dem Definieren und Analysieren von fachlichen und technischen Anforderungen der einzelnen Elemente. Der CryptoProxy setzt sich aus folgenden Elementen zusammen:

- HSM (Hardware Security Module) - Signing API

- PKI-Manager

- TLS-Channel-Management

Der CryptoProxy ist ein Teil vom gesamten System, welches das Smart Metering zur Verfügung stellt. Smart Meter und Smart Meter Gateway sind zwar Teile des Systems, jedoch nicht Teil der Thesis. Diese befasst sich ausschließlich mit der Kryptografie und dem Verbindungsmanagement von Smart Meter Gateways. Die gesamte Implementierung ist ebenfalls nicht Bestandteil der Arbeit. Diese wird voraussichtlich erst in ein paar Jahren abgeschlossen sein. Auch die Spezifikationen des Smart Meter Gateway, des Gateway Admins sowie der Messstellenbetreiber sind noch nicht endgültig fertiggestellt. Hier werden noch Änderungen vom Bundesamt für Sicherheit in der Informationstechnik erwartet.

Grundbegriffe

2 G

2.1.

2.1.1 S^MART M^ETER

Smart Meter (SM) sind intelligente Zähler (s. Abbildung 2-1), die genutzt werden, um den Verbrauch von Strom, Wasser und Gas zu messen. Die Verbrauchsmessungen werden heute bereits von Strom-, Wasser- und Gaszählern übernommen. Diese Zähler können den Verbrauch jedoch nur anzeigen. Ein Techniker des Netzbetreibers muss regelmäßig den Verbrauch ablesen und an den Netzbetreiber melden. Zusätzlich sind diese Zähler nicht in der Lage, zu erkennen, wann der Verbrauch erzielt wurde. Der Strompreis zum Beispiel kann zu unterschiedlichen Zeiten variieren, daher wird sich in Zukunft ein neues Geschäftsmodell etablieren, denn intelligente Zähler speichern, wann welcher Verbrauch zustande gekommen ist.

Abbildung 2-1 Smart Meter

Quelle: http://www.heise.de/newsticker/meldung/Energie-sparen-mit-dem-Stromzaehler- 202105.html

Außerdem können SM anzeigen, wie viel der Strom zu welcher Zeit gekostet hat.

Hierfür beinhalten sie Tariflisten, die regelmäßig aktualisiert werden. Ein Verbraucher kann außerdem seine Verbrauchsdaten analysieren und seinen Stromverbrauch minimieren. SM sind daher in ein Kommunikationsnetzwerk eingebunden, um dem Netzbetreiber die aktuellen Verbräuche melden zu können. Zusätzlich bieten sie die Möglichkeit, über ein Web-Interface verschiedene Konfigurationen vorzunehmen und aktuelle Daten anzuzeigen.

Grundbegriffe

Abbildung 2-2 Smart METER Web-Interface Quelle: https://www.enbw.com/demo-kundenzentrum/#

Stromanbieter bieten hierzu einen umfangreichen Kundenbereich auf ihrer Internetpräsenz (siehe Abbildung 2-2).

Von den Netzbetreibern wird ebenfalls die Möglichkeit angeboten, den Verbrauch auf Smartphones oder Tablet PCs anzeigen zu lassen(s. Abbildung 2-3). Hierzu werden von den Betreibern Applikationen für mobile Systeme (Anwendungen für Android, iOS, Windows Phone oder ähnliche Smartphone-Betriebssysteme) entwickelt.

Abbildung 2-3 Smart-Meter-APP

Quelle: https://www.enbw.com/demo-kundenzentrum/#

So kann der Verbraucher zu jeder Zeit sehen, wie viel er verbraucht hat.

Andere SM können den Verbrauch von Gas intelligent steuern. Hier werden ebenfalls neue Möglichkeiten geschaffen. Der SM im Haus kann zum Beispiel so eingerichtet werden, dass die Heizung tagsüber ausgeschaltet ist und erst gegen 16 Uhr eingeschaltet wird. So wird Gas gespart und die Umwelt geschont; durch die

Grundbegriffe Einbindung in das Kommunikationsnetzwerk eröffnen sich hierfür neue Wege, um Energie zu sparen und die Umwelt zu schonen. Es werden zum Beispiel Applikationen für Smartphones entwickelt, welche den genauen Standort des Verbrauchers ermitteln und mit dem SM kommunizieren. Hierdurch ist es möglich, die Heizung einzuschalten, sobald man sich in der Nähe des Hauses befindet.

2.1.2 SMART METER GATEWAY

„In einem intelligenten Messsystem bildet das Smart Meter Gateway (SMGW) die zentrale Kommunikationseinheit, die Messdaten von Zählern empfängt, speichert und diese für autorisierte Marktteilnehmer aufbereitet.“¹ Das heißt, mehrere SM werden an einen SMGW angeschlossen. Dieser nimmt die Verbraucherdaten der SM entgegen und sendet sie zum Netzbetreiber (autorisierte Marktteilnehmer). Das SMGW verschlüsselt die Daten, baut eine TLS-Verbindung auf und sendet die Daten an den CryptoProxy. Dieser leitet die Daten anschließend weiter.

Für die Verschlüsselung, Signaturerstellung und -prüfung, Schlüsselgenerierung, Schlüsselaushandlung sowie die Aufbewahrung der Schlüssel beinhaltet das SMGW ein Sicherheitsmodul, das diese Aufgaben übernimmt.²

In jedem Haus soll es in Zukunft mindestens einen SM geben, bei Mehrfamilienhäusern soll für jede Wohneinheit ein SM existieren. Zusätzlich werden für verschiedene Solaranlagen SM benötigt. Nach der derzeitigen Planung wird ein SMGW für eine Straße eingerichtet. Alle SM in dieser Straße werden dann über diesen SMGW verwaltet.

2.1.3 GATEWAY ADMINISTRATOR

Der Smart Meter Gateway Administrator (GWA) hat eine zentrale Rolle beim Betrieb des Smart Meter Gateways. Er muss dafür sorgen, dass der Betrieb des SMGW stets reibungslos gewährleistet ist.

Bei der Installation des SMGW gibt der GWA ein neues Zertifikat für diesen Gateway in Auftrag, der für den Aufbau der sicheren Verbindung zwischen GWA und SMGW benötigt wird. Dieses Zertifikat wird dann über einen Service-Techniker im Smart Meter Gateway installiert. Der Service-Techniker braucht sonst im SMGW keine Konfigurationen vorzunehmen.

Alle nötigen Konfigurationen des SMWG übernimmt der GWA. Die gesamte Kommunikation läuft hierbei über eine gesicherte TLS-Verbindung. Über die gleiche Verbindung überwacht und kontrolliert der GWA seine Smart Meter Gateways.

1 BSI, letzter Zugriff 04.06.2013, http://www.bsi.bund.de.

2 Vgl. BSI, letzter Zugriff 04.06.2013, https://www.bsi.bund.de.

Grundbegriffe

2.1.4 HARDWARE SECURITY MODULE (HSM)

Hardware-Sicherheitsmodule werden eingesetzt, um auf der einen Seite private Schlüssel (siehe 2.2 Kryptografie) sicher aufzubewahren und auf der anderen Seite, um kryptografische Algorithmen effizient auszuführen. Es sind Peripheriegeräte, welche besonders abgesichert sind.³ In einem HSM können folgende Algorithmen für die Kryptografie implementiert sein:

- Asymmetrisch

o Verschlüsseln und Entschlüsseln von Daten o Signieren von Daten oder Zertifikaten

o Schlüsselaustauschverfahren (z. B. Diffie-Hellman) - Symmetrisch

o Symmetrisches Verschlüsseln und Entschlüsseln von Daten - Erzeugen von Hash-Werten, zum Beispiel:

o SHA-1 o SHA-256 o SHA-MD5

Zusätzlich bieten unterschiedliche HSM die Möglichkeit, Zufallszahlen, PINs oder Schlüsselpaare zu generieren.

HSMs werden nach Sicherheitsstandards, wie z. B. FIPS 140-1 und 140-2, DK (Deutsche Kreditwirtschaft) oder Common Criteria (CC) zertifiziert. Speziell für HSMs, die von Zertifizierungsdienstanbietern für die Erzeugung von digitalen Signaturen verwendet werden, wurde das CC-Schutzprofil CWA 14167-2 entwickelt.

2.1.4.1 ATOS SECURITY MODULE (ASM)

Ein Atos-Sicherheitsmodul (s. Abbildung 2-4) ist in der Lage, das Schlüsselpaar, das für die symmetrische bzw. auch für die asymmetrische Verschlüsselung oder Signierung benötigt wird, selbstständig zu generieren. Der öffentliche Schlüssel kann danach exportiert werden. Der private Schlüssel dagegen kann auf keinen Fall aus dem HSM gelesen werden. Selbst wenn man die Festplatte auszubauen versucht, ist der Schlüssel gesichert. Bei diesem Vorgehen zerstört sich die HSM selbst.

Abbildung 2-4 Atos security module Quelle: Eigene Darstellung

3 Vgl. Schmeh, K., 2013, S. 445.

Kryptografie

KRYPTOGRAFIE

2.2.

2.2.1 SYMMETRISCHE VERSCHLÜSSELUNG

Bei der symmetrischen Verschlüsselung existiert nur ein Schlüssel (s. Abbildung 2- 5). Es gibt kein Schlüsselpaar. Der Schlüssel muss über ein sicheres Medium ausgetauscht werden, damit beide Teilnehmer den Schlüssel kennen. Hierbei muss darauf geachtet werden, dass kein Dritter den Schlüssel abfangen kann.⁴

Abbildung 2-5 Symmetrische Verschlüsselung

Quelle: http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/

Wurde der Schlüssel ausgetauscht, können die verschlüsselten Nachrichten sicher über das Internet versendet werden. Um die Nachricht zu verschlüsseln, nutzt Teilnehmer A den geheimen Schlüssel. Die verschlüsselte Nachricht kann nun nicht mehr gelesen werden. Auch bei einer „Man-in-the-middle“-Attacke, bei der ein Dritter die Kommunikation mithört, kann die Nachricht von niemandem gelesen werden.

Teilnehmer B jedoch kann die Nachricht mit dem gleichen geheimen Schlüssel entschlüsseln und lesen.⁵

4 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 22 ff.

5 Vgl. Schmeh, K., 2013, S. 391 f.

Kryptografie

2.2.2 ASYMMETRISCHE VERSCHLÜSSELUNG

Bei der asymmetrischen Verschlüsselung werden zwei unterschiedliche Schlüssel, jeweils zum Entschlüsseln und zum Verschlüsseln, genutzt. Bei der Schlüsselgenerierung wird immer ein Schlüsselpaar gebildet. Dieses Paar gehört zusammen und besteht aus einem öffentlichen und einem privaten Schlüssel.

Der private Schlüssel darf unter keinen Umständen an Dritte herausgegeben werden oder verlorengehen. Der öffentliche Schlüssel hingegen kann in öffentlichen Medien zur Verfügung gestellt werden, da mit der Nutzung des öffentlichen Schlüssels kein Schaden oder Identitätsdiebstahl getätigt werden kann.⁶

Abbildung 2-6 Asymmetrische Verschlüsselung I

Quelle: http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/

Jemand, der den öffentlichen Schlüssel besitzt, kann nun eine Nachricht seiner Wahl verschlüsseln und an den Besitzer des privaten Schlüssels senden (s. Abbildung 2- 6). Mit dem öffentlichen Schlüssel kann jedoch niemand eine Nachricht entschlüsseln, und auch aus der verschlüsselten Nachricht kann niemand Informationen entnehmen.

6 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 26 f.

Kryptografie

Abbildung 2-7 Asymmetrische Verschlüsselung II

Quelle: http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/

Bekommt der Besitzer des privaten Schlüssels nun die Nachricht, kann dieser seinen geheimen privaten Schlüssel nutzen, um die Nachricht zu entschlüsseln und zu lesen (s. Abbildung 2-7).⁷

Die asymmetrische Verschlüsselung ist im Gegensatz zur symmetrischen zwar sicherer, da der private Schlüssel nicht übermittelt werden muss, dauert aber wesentlich länger. Aus diesem Grund wird oft eine hybride Verschlüsselung eingesetzt, welche beide Vorteile nutzt.⁸

7 Vgl. Küsters, R.; Wilke, T., 2011, S. 137 ff.

8 Vgl. Küsters, R.; Wilke, T., 2011, S. 175.

Kryptografie

2.2.3 HYBRIDE VERSCHLÜSSELUNG

Bei der hybriden Verschlüsselung wird sowohl die asymmetrische als auch die symmetrische Verschlüsselung genutzt. Beim Aufbau der Verbindung wird mittels asymmetrischer Verschlüsselung der geheime Schlüssel (privater symmetrischer Schlüssel) versendet. Hierzu wird der geheime Schlüssel selbst mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und anschließend gesendet. Da der Schlüssel in einer Nachricht verschlüsselt wurde, kann niemand den Schlüssel dekodieren.⁹

Der Empfänger kann nun mit seinem privaten Schlüssel die Nachricht mit dem geheimen Schlüssel entschlüsseln. Der Schlüsselaustausch des symmetrischen Schlüssels wurde auf Basis einer sicheren Kommunikation durchgeführt. Hierdurch entfällt der Nachteil der symmetrischen Verschlüsselung, der unsichere Schlüsselaustausch (s. Abbildung 2-8).

Abbildung 2-8 Hybride Verschlüsselung

Quelle: http://edoc.hu-berlin.de/master/ohst-daniel-2004-04-20/HTML/chapter3.html

Alle folgenden Nachrichten werden nun symmetrisch mit dem geheimen Schlüssel verschlüsselt und versendet. Der Nachteil der asymmetrischen Verschlüsselung – die Dauer der Verschlüsselung – hat nur beim Schlüsselaustausch eine Verzögerung bewirkt.

9 Vgl. Schneier, B., 1996, S. 32 ff.

Kryptografie

2.2.4 DIGITALE SIGNATUREN

Digitale Signaturen werden verwendet, um einen Sender einer Nachricht oder bspw.

den Betreiber einer Webseite eindeutig zu identifizieren. Wenn eine Nachricht signiert wurde, heißt dies nichts anderes, als das zusätzlich zur Nachricht auch eine Signatur versendet wird. Wenn diese Signatur nun vom Empfänger geprüft wird, weiß dieser, dass die Nachricht vom Sender stammt und nicht manipuliert wurde.

Um Signaturen zu erzeugen, benötigt man auf der einen Seite ein asymmetrisches Schlüsselpaar und auf der anderen Seite eine Hashfunktion sowie eine Signier- und Verifikationsfunktion. Die Signierfunktion ist die Verschlüsselung mithilfe des privaten Schlüssels. Das Entschlüsseln wird oft auch Verifikationsfunktion genannt.

„Einwegfunktionen sind Funktionen f, die sich leicht berechnen lassen, deren Umkehrung f−1 jedoch nicht oder nur sehr schwer (d. h. mit nicht vertretbarem Aufwand) zu berechnen ist, insbesondere, wenn die Funktion f öffentlich bekannt ist.“¹⁰ Die Abbildung der Zeichenkette oder Nachricht wird Fingerabdruck genannt.¹¹ Aus einer Nachricht wird mit der gleichen Hashfunktion immer der gleiche Fingerabdruck erzeugt.¹²

Es gibt zwei Möglichkeiten eine Signatur zu erzeugen. Mit dem privaten Schlüssel kann die Nachricht direkt signiert werde. Hierzu wird nur die verschlüsselte Nachricht als Signatur geschickt. Der Empfänger kann dann mit dem öffentlichen Schlüssel die Signatur prüfen. Bei dieser Variante wird die komplette Nachricht entschlüsselt. Man kann diese daher nur für die Verifikation des Senders nutzen. In der Vorgehensweise, die öfter in der Praxis genutzt wird, wird erst ein Hash-Wert über die Nachricht gebildet. Dieser wird anschließend signiert (s. Abbildung 2-9).¹³

Im Folgenden wird auf diese Vorgehensweise detaillierter eingegangen.

10 Ertel, W., 2012, S. 98.

11 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 28.

12Vgl. Darmstadt, TU, letzter Zugriff 15.07.2013 http://www.informatik.tu-darmstadt.de .

13 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 27 f.

Kryptografie Erzeugung einer digitalen Signatur für eine Nachricht:

1. Der Fingerabdruck wird erzeugt (Hash-Wert über Nachricht).

2. Die Signatur ist der verschlüsselte Fingerabdruck (mit dem privaten Schlüssel).

3. Die Signatur wird an die Nachricht angehängt und versendet.¹⁴

Abbildung 2-9 Signaturerzeugung

In Anlehnung an: http://www.cryptas.com/cryptas/wissen-unterstuetzung/digitale- signatur/typen-digitaler-signaturen.html

Wenn die Nachricht nun versendet wurde und der Empfänger die vollständige Nachricht sowie die Signatur erhalten hat, muss er diese prüfen. Hierzu benötigt er den öffentlichen Schlüssel des Senders.

Es gibt für den Empfänger zwei Möglichkeiten, diesen Schlüssel zu erhalten.

Entweder hat der Sender ihm den Schlüssel zur Verfügung gestellt oder der Empfänger lädt sich den Schlüssel beim zentralen Verzeichnisdienst, auch Trustcenter genannt, herunter¹⁵.

Dieser zentrale Dienst speichert Zertifikate, in denen sich der öffentliche Schlüssel befindet. Oft wird ein Zertifikat auch als öffentlicher Schlüssel bezeichnet. Diese Bezeichnung ist jedoch nicht korrekt. Der Verzeichnisdienst ist die Verifizierungsstelle der Zertifikate. Das heißt, diese Stelle signiert die Zertifikate der Benutzer und vertraut diesen somit. Eine weitere Aufgabe des Verzeichnisdienstes ist es, Sperrlisten (CRL) zur Verfügung zu stellen. Auf diesen Sperrlisten werden Zertifikate vermerkt, welche gesperrt wurden. Zertifikate werden dann gesperrt, wenn zum Beispiel der private Schlüssel von einem Fremden entwendet wurde oder nur eine Sicherheitslücke besteht, sodass die Möglichkeit besteht, dass der private Schlüssel gelesen werden könnte.

14 Vgl. Schneier, B., 1996, S. 38.

15 Vgl. Ertel, W., 2012 , S. 117.

Kryptografie Wenn der Empfänger der Nachricht den öffentlichen Schlüssel aus dem Zertifikat extrahiert oder von dem Sender empfangen hat, kann er die Signatur prüfen (s.

Abbildung 2-10). Hierzu geht er wie folgt vor:

1. Er benutzt die gleiche Hashfunktion und erzeugt aus der Nachricht den Fingerabdruck, der identisch sein muss (es sei denn, die Nachricht wurde manipuliert).

2. Zusätzlich wird die Signatur entschlüsselt. Diese Funktion ist das Gegenstück zur Signierfunktion.

3. Anschließend wird der erzeugte Hash-Wert mit der entschlüsselten Signatur verglichen. Sind die beiden Werte nicht identisch, so wurde die Nachricht manipuliert oder von einem anderen Sender abgeschickt.¹⁶

Abbildung 2-10 Signaturerzeugung

In Anlehnung an: Quelle: http://www.cryptas.com/cryptas/wissen-unterstuetzung/digitale- signatur/typen-digitaler-signaturen.html

16 Vgl. Schneier, B., 1996, S. 38.

Kryptografie

2.2.5 DIFFIE HELLMAN

Whitfield Diffie und Martin Hellman erfanden 1976 das Diffie-Hellman-Schlüssel- austauschverfahren. Es war das erste Verfahren, mit dem es möglich war, einen gemeinsamen Schlüssel unter zwei Teilnehmern zu berechnen und auszutauschen.

Durch den Schlüsselaustausch ist es möglich, geheime Daten zu verschlüsseln und über die Leitung zu versenden.¹⁷

Bei dem Verfahren wird zuerst eine Primzahl (p) und eine ganze Zahl (g), die kleiner ist als die Primzahl, in Abstimmung beider Teilnehmer vereinbart. Je größer die Primzahl ist, desto sicherer wird der Schlüssel.

Teilnehmer A und Teilnehmer B müssen sich nun beide eine geheime Zahl (a und b) ausdenken, welche nicht übermittelt werden und auch nicht weitergegeben werden dürfen. Diese Zahlen dürfen jedoch nicht kleiner sein als die Primzahl (p).

Aus diesen Zahlen wird nun jeweils eine Zahl berechnet, welche dann an den anderen Teilnehmer übertragen wird.

So berechnet Teilnehmer A:¹⁸

A = g^a (mod p)

A übermittelt die errechnete Zahl an Teilnehmer B. Dieser berechnet ebenso eine Zahl, die dann an Teilnehmer A übermittelt werden kann:

B = g^b (mod p)

Nachdem beide Zahlen übermittelt wurden, können beide Teilnehmer den gemeinsamen Schlüssel berechnen. Teilnehmer A berechnet diesen mit der von Teilnehmer B erhaltenen Zahl (B), sowie mit der Primzahl (p) und der eigenen, ausgedachten Zahl (a):

K = B^a (mod p)

17 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 192 – 130

18 Vgl. Schneier, B, 1996, S. 513.

Kryptografie Die gleiche Zahl kann Teilnehmer B analog berechnen:

K = A^b (mod p) ¹⁹

Mit der errechneten Zahl (K) hat man nun den geheimen Schlüssel. Mit diesem Schlüssel können die Daten symmetrisch verschlüsselt und dann an den anderen Teilnehmer geschickt werden. Dieser kann die Daten entschlüsseln und lesen.²⁰ Bei diesem Verfahren ist der Aufwand für den Angreifer, den Schlüssel zu berechnen, sehr groß, da er nur die Zahlen A und B sowie die vereinbarten Zahlen p und q mithören kann. Die von Teilnehmer A und B ausgedachten Zahlen (a und b) kann niemand mithören. Und auch wenn der Angreifer den Schlüssel berechnet hat, sind die Daten bis dahin meist unbrauchbar geworden, denn die Berechnung des Schlüssels würde zu lange dauern.

Mit folgender Berechnung kann ein Angreifer den Schlüssel berechnen:

a = logg(A) (mod p), denn A = ga (mod p)

Diese Berechnung dauert, je nachdem wie groß die Zahlen p und q sind, mit der heutigen Prozessorleistung mehrere Jahrhunderte.

19 Vgl. Schneier, B., 1996, S. 513.

20 Vgl. Diffie, W.; Hellman, M. E.,1976, S. 648 ff.

Kryptografie

2.2.6 ELGAMAL

Das Verschlüsselungs- und Signaturverfahren nach Elgamal beschreibt die Bestimmung eines gemeinsamen Schlüssels zwischen zwei Teilnehmern sowie das Verschlüsseln oder Signieren einer Nachricht mit diesem Schlüssel. Elgamal ist ein asymmetrisches Schlüsselverfahren, bei dem es einen privaten und einen öffentlichen Schlüssel gibt.

Um ein gemeinsames Schlüsselpaar zwischen zwei Teilnehmern zu finden, agiert Elgamal ähnlich wie das Diffie-Hellman-Verfahren (siehe 2.2.5 Diffie Hellman).

Die Schlüsselerzeugung unterscheidet sich nur in einigen Vorgaben. Die ganze Zahl (g), die zwischen beiden Teilnehmern vereinbart wird, muss bei Elgamal kleiner sein als die Primzahl (p). Diese wiederum muss ebenfalls eine Primzahl sein, wenn man eins subtrahiert und die Zahl durch zwei teilt.

Bis auf diese Unterschiede wird die Schlüsselerzeugung äquivalent zum Diffie- Hellman-Verfahren durchgeführt (siehe 2.2.5 Diffie Hellman ).

Dieses Schlüsselpaar kann nun genutzt werden:

Signieren einer Nachricht²¹

Nachrichten, die über das Internet verschickt werden, werden meist signiert, um den Sender der Nachricht eindeutig zu identifizieren. Hierdurch kann sichergestellt werden, dass kein „man in the middle“, also jemand, der die Nachricht abfängt, die Daten verfälscht, denn die Signatur wird über die Daten gebildet. Die Validierung der Signatur würde bei verfälschten Daten fehlschlagen. ²²

Zur Erstellung der Signatur wird neben dem privaten Schlüssel (a, nicht der gemeinsame private Schlüssel, sondern die zufällige Zahl von Teilnehmer 1, aus der dann A berechnet wurde) und den beiden Zahlen p und q, die bereits vereinbart wurden, eine weitere Zufallszahl (z) benötigt; diese muss teilerfremd zu der Primzahl (p) sein. Zusätzlich muss aus der Nachricht (x) der Hash gebildet werden (H(x)).

Welcher Hash-Algorithmus hierfür verwendet wird, spielt dabei keine Rolle. Die Signatur (s1, s2) wird nun wie folgt berechnet:

S1 = g^z*mod(p)

S2 = z^-1 (H(x) – a*S1) mod(p-1)

(Mit hoch -1 das multiplikative Inverse gemeint ist)

21 Vgl. Schneier, B., 1996, S. 476.

22 Vgl. HS-Mannheim, letzter Zugriff 27.06.2013, http://www.am.hs-mannheim.de.

Kryptografie Verifizieren der Signatur:²³

Um die Signatur nun auf Richtigkeit zu prüfen, werden zwei Bedingungen überprüft:

Die erste Bedingung besagt, dass s1 größer als 1sein muss, aber kleiner als die Primzahl (p). Also

1<s1<p

Bei der zweiten Bedingung wird nun auch die Nachricht einbezogen. Hierdurch kann die Nachricht nicht verfälscht werden:

A^S1 * S1^S2 mod p = g^h(x) mod p

Wenn die linke Seite einen anderen Wert als die rechte Seite ergibt, dann ist die Signatur nicht korrekt.

23Vgl. HS-Mannheim, letzter Zugriff 27.06.2013, http://www.am.hs-mannheim.de.

Kryptografie Verschlüsseln einer Nachricht²⁴

Bei der Verschlüsselung einer Nachricht kommt im Gegensatz zur Signierung einer Nachricht der private Schlüssel zum Einsatz, welcher zwischen Teilnehmer 1 und Teilnehmer 2 im Diffie-Hellman-Verfahren ausgetauscht und berechnet wurde (siehe 2.2.5 Diffie Hellman ).

Die Nachricht (x), welche verschlüsselt werden soll, muss kleiner sein als p-1. Ist dies nicht der Fall, muss die Nachricht aufgeteilt werden. Zum Beispiel wird die Nachricht

„05070810“ zerlegt in: „05“, „07“, „08“ und „10“. Diese vier Blöcke werden einzeln verschlüsselt und anschließend aneinander gehängt.²⁵

c1 = B

c2 = k*m mod p

Hierbei ist m die Klartext-Nachricht und c1, c2 die verschlüsselte Nachricht. c2 besteht aus allen vier verschlüsselten Blöcken. Nach dem vorliegenden Beispiel sieht c2 so aus: „06040301“.

Entschlüsseln einer Nachricht

Der Sender der Nachricht übermittelt c1 und c2, wobei c1 dem B im Diffie-Hellman- Verfahren entspricht. Diese Zahl ist wichtig für die Entschlüsselung der Nachricht.

Auch hier wird c2 wieder in vier Blöcke aufgeteilt und nacheinander entschlüsselt. Im Klartext werden alle Stücke hintereinander gehängt.

m = (B^(p-1-a) * c2) mod p²⁶

24 Vgl. Universität Tübingen, letzter Zugriff 27.06.2013, http://www-ti.informatik.uni-tuebingen.de.

25 Vgl. Regenechsen, letzter Zugriff 27.06.2013, http://www.regenechsen.de.

26 Vgl. Buchmann, J., 2008, S. 157.

Technologien

TECHNOLOGIEN

2.3.

2.3.1 W^EBSERVICE

Ein Webservice oder Webdienst ist ein Dienst im Internet, der über eine eigene Adresse verfügbar ist. Es gibt verschiedene Webservices, die unterschiedliche Kommunikationsprotokolle nutzen. Jeder Webservice muss daher eine eigene Schnittstellenbeschreibung zur Verfügung stellen. Clients können über verschiedene Übertragungsprotokolle eine Anfrage an einen Webservice senden. Hierbei wird meist jedoch HTTP genutzt. ²⁷

Die Nutzung von Webservices steigt stetig an, da die meisten Webservices plattform- und programmiersprachenunabhängig sind.

Ein großer Nachteil ist die fehlende Sicherheit bei Webservices. Beim Aufsetzen eines Web Services wird daher ein sicheres Konzept benötigt.

Außerdem ist bei vielen Webservices die Performance nicht optimal, da sie auf Extensible Markup Language (XML) basieren.

„XML ist ein Datenformat für Fachleute verschiedener Branchen, das die hochautomatisierte Verarbeitung von Text und Daten ermöglicht, weil XML eine strenge Strukturierung erlaubt, so dass in geeigneten Anwendungsfällen große Rationalisierungsgewinne zu realisieren sind.“²⁸

27 Vgl. Tidwell, D.; Snell, J.; Kulchenko, P., 2001, S. 6.

28 Vgl. Mintert, letzter Zugriff 07.08.2013, http://www.mintert.com/xml/.

Technologien

2.3.1.1 REST-WEBSERVICE

REST steht für Representational State Transfer und ist ein Architektur-Modell für Webanwendungen. REST dient als Anleitung für Webservices und stellt weder ein Produkt noch einen Standard dar. Bei REST-Webservices sendet der Client eine Anfrage an den Server. Hierbei kann er Ressourcen anfordern oder andere Aktivitäten im Server anstoßen.²⁹

Der Server speichert hierbei keine Session für einen Client. Daher müssen in einer Anfrage alle nötigen Informationen vorhanden sein.

Es wird keine explizite Norm definiert, jedoch empfiehlt REST, Standards einzusetzen. Hierzu gehören:

- URI: zur Adressierung der Services

- HTTP-Methoden (z. B. GET, POST): um auf die Services zuzugreifen - XML, XHTML, HTML, PNG: um Ressourcen zu versenden³⁰

- JavaScript Object Notation (JSON): wird genutzt, um verschiedene Daten als einen Datensatz erkennbar zu machen

- MIME-Type: zur Deklarierung der gesendeten Daten

Bei einem REST-Service-Aufruf kann entweder z. B. ein GET genutzt werden, um eine Ressource zu bekommen oder zum Beispiel ein PUT, um Daten an den Server zu senden. Hier werden die Daten meist als JSON-Objekt gesendet.

Ein JSON-Objekt stellt einen Datensatz von mehreren Daten dar. Die verschiedenen Daten werden in Textform dargestellt.³¹

Beispiel JSON-Objekt:

{

"Name" : "JSON-Object",

"ID" : "12345678", }

Als Inhaltstyp wird dann application/json anstelle von text/html mit gesendet.

29 Vgl. Richardson, L.; Ruby, S., 2007, S. 13.

30 Vgl. Orientation in Objects, letzter Zugriff 03.06.2013, http://www.oio.de/public/xml/rest- webservices.htm.

31 Vgl. Richardson, L.; Ruby, S., 2007, S. 325 f.

Technologien Die wichtigsten HTTP-Methoden im Überblick:³²

- GET: Ressourcen anfordern

- POST: einer Ressource etwas hinzufügen - PUT: Ressourcen auf dem Server anlegen - DELETE: Ressourcen löschen

Ein Aufruf eines REST-Webservices sieht wie folgt aus:

GET https://testservice.eu/restservices/configurationservice/17

Hier kann zum Beispiel eine Konfiguration mit der ID 17 angefordert werden.

Die Antwort des Servers enthält immer den HTTP-Antwort-Code. ³³ Einige der häufigsten HTTP-Antwort-Codes:³⁴

- 200 (OK) – der repräsentative HTML-Code wird in der Antwort gesendet - 201 (Created) – neue Ressource wurde erstellt

- 202 (Accepted) – erlaubt, aber noch nicht fertiggestellt; die Verarbeitung erfolgt asynchron

- 204 (No content) – die angeforderte Ressource hat keinen Inhalt

- 301 (Moved permanently) – die URL der angeforderten Ressource wurde geändert

- 303 (See Other) – Fehler

- 304 (Not modified) – die Ressource wurde nicht verändert und daher aus dem Cache gesendet

- 305 (See Other) – die Ressource ist nicht erreichbar (z. B. wegen des Proxys) - 400 (Bad request) – die Anfrage war nicht korrekt

- 401 (Unauthorized) – die Anfrage war nicht autorisiert - 402 (Payment required) – reserviert

- 403 (Forbidden) – diese Anfrage ist nicht erlaubt

- 404 (Not found) – die angeforderte Ressource existiert nicht

- 406 (Not acceptable) – die angeforderte Ressource darf nicht dargestellt werden

- 409 (Conflict) – es existiert ein Konflikt

- 412 (Precondition failed) –Vorbedingung wurde nicht erfüllt

- 415 (Unsupported media type) – die angeforderte Repräsentation wird nicht unterstützt

- 500 (Internal server error) – Internetfehler - 501 (Not implemented) – nicht implementiert

- 503 (Service unavailable) – Service ist zur Zeit nicht erreichbar

Diese HTTP-Antwort-Codes beschreiben den Zustand der Anfrage. Die Antwortcodes von 100-199 beschreiben eine Information, von 200-299 eine erfolgreiche Anfrage, von 300-399 eine Weiterleitung, von 400-499 einen Clientfehler und von 500-599 einen Serverfehler.

32 Vgl. Richardson, L.; Ruby, S., 2007, S. 29 f.

33 Vgl. InfoQ, letzter Zugriff 03.06.2013, http://www.infoq.com/articles/designing-restful-http-apps-roth .

34 Vgl. Richardson, L.; Ruby, S., 2007, S. 371–388.

Technologien

2.3.1.2 SOAP-WEBSERVICE

Simple Object Access Protocol oder auch SOAP-Webservice ist ein auf XML basierendes Kommunikationsprotokoll. Das Protokoll ist programmiersprachen- sowie plattformunabhängig.³⁵

Es dient dem Versenden von Nachrichten. Ein SOAP-Webservice bietet eine WSDL- Datei an, die den Webservice und die Schnittstellen beschreibt.³⁶

Jede Nachricht, die über SOAP versendet wird, muss eine gültige XML-Nachricht sein.

Ein Client sendet eine Anfrage und erhält eine Antwort vom Webservice (Server). Bei der Verwendung von HTTP wird vor der SOAP-Nachricht, also Anfrage oder Antwort, zusätzlich der HTTP Header sowie die XML-Definition mit angegeben.³⁷

HTTP Header einer Anfrage:

POST /perl/soaplite.cgi HTTP/1.0 Host: services.xmethods.net:80

Content-Type: text/xml; charset=utf-8 Content-Länge: 556

SOAPAction: ""

HTTP Header einer Antwort:

HTTP/1.1 200 OK

Date: Thu, 05 Sep 2002 08:01:13 GMT

Server: Apache/1.3.22 (Unix) Enhydra-Director SOAPServer: SOAP::Lite/Perl/0.52

Content-Länge: 545 Connection: close

Content-Type: text/xml; charset=utf-8

In dem HTTP Header der Antwort wird zusätzlich der Status angegeben. Die Status- Codes sind die gleichen, die auch bei REST Services verwendet werden (siehe 2.3.1.1 REST-Webservice). Bei einer SOAP-Antwort geben diese Codes jedoch nur an, ob die Anfrage erfolgreich angenommen und verarbeitet werden konnte. Bei einem logischen Fehler wird in der Antwort ein „SOAP:Fault“ mitgeschickt.

35 Vgl. BitWorld, letzter Zugriff 03.06.2013, http://www.bitworld.de/index.php/grundlagen/soap .

36 Vgl. Tidwell, D.; Snell, J.; Kulchenko, P., 2001, S. 15 f.

37 Vgl. Tidwell, D.; Snell, J.; Kulchenko, P., 2001, S. 17.

Technologien Eine Beispiel-SOAP-Anfrage sieht wie folgt aus: ³⁸

<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope xmlns:SOAP-

ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<ns1:Master xmlns:ns1="urn:xmethodsMaster"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<translationmode xsi:type="xsd:string">de_en</translationmode>

<sourcedata xsi:type="xsd:string">Guten Tag</sourcedata>

</ns1:Master>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Der Webservice könnte mit folgender Antwort reagieren: ³⁹

<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-

ENC="http://schemas.xmlsoap.org/soap/encoding/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<namesp1:MasterResponse xmlns:namesp1="urn:xmethodsMaster">

<return xsi:type="xsd:string">hello world </return>

</namesp1:MasterResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

38 Vgl. Tidwell, D.; Snell, J.; Kulchenko, P., 2001, S. 19.

39 Vgl. Tidwell Tidwell, D.; Snell, J.; Kulchenko, P., 2001, S. 19 f.

Technologien

2.3.2 TRANSPORT LAYER SECURITY (TLS)

Transport Layer Security ist eine Weiterentwicklung des Secure-Socket-Layer- Protokolls. Es wurde entwickelt, um eine Internetverbindung abzusichern. Hierbei wird die Verbindung authentifiziert und verschlüsselt. Das SSL-Protokoll wird in Verbindung mit unterschiedlichen Übertragungsprotokollen verwendet.⁴⁰ Verbindungen wie zum Beispiel FTP, SMTP, E-MAIL, TELNET und HTTP werden durch das SSL-Protokoll vor MTM („man in the middle“) oder anderen Angriffen gesichert.⁴¹

Die TLS-Verbindung nutzt für die sichere Übertragung der Daten eine Hybridverschlüsselung. Die Daten, die über die Leitung geschickt werden, werden symmetrisch verschlüsselt. Der symmetrische Schlüssel wird mittels Diffie-Hellman (siehe 2.2.5 Diffie Hellman) asymmetrisch verschlüsselt und übertragen.

Eine TLS-Verbindung kann entweder eine nur serverseitige Authentifizierung beinhalten oder eine Client-Server-Authentifizierung. Das heißt, entweder wird die Identität des Servers sichergestellt oder beide Teilnehmer müssen sich durch ein Zertifikat eindeutig identifizieren. Bei einer Client-Server-Authentifizierung muss der Client ebenfalls ein vertrauenswürdiges Zertifikat sowie das dazugehörige Schlüsselpaar besitzen. Bei einer serverseitigen Authentifizierung dagegen braucht der Client kein eigenes Zertifikat. In diesem Fall wird nur die Identität des Servers sichergestellt.

Der Aufbau einer TLS/SSL-Verbindung erfolgt auf zwei Ebenen. Auf der einen Ebene findet die symmetrische Verschlüsselung der Daten statt. Die Echtheit der Daten wird durch einen Prüfsummencheck, wie zum Beispiel den Secure Hash Algorithm (SHA), oder den Message Digest No. 5 (MD5) geprüft. Auf der zweiten Ebene findet der Schlüsselaustausch statt. Dieser erfolgt über den TLS/SSL-Handshake. Hierbei wird zwischen dem Client und dem Server festgelegt, welche SSL/TLS-Versionen von beiden unterstützt werden und welche schließlich genutzt wird. Zusätzlich findet beim Handshake auch die Übermittlung der Zertifikate statt, die nötig ist, um die andere Seite auch als vertrauenswürdig einzustufen. In jedem Zertifikat ist ebenfalls der öffentliche Schlüssel des jeweiligen Schlüsselpaares enthalten.

40 Vgl. IT-Wissen, letzter Zugriff 10.06.2013, http://www.itwissen.info .

41 Vgl. Schmeh, K., 2013, S. 656.

Technologien Sind die Zertifikate ausgetauscht, wird entweder mit RSA (Rivest, Shamir und Adleman) ein zufälliger, vorläufiger Schlüssel gewürfelt oder das Diffie-Hellman- Verfahren angewandt, um den Schlüsselaustausch zu vollziehen. RSA ist ein asymmetrisches kryptographisches Verfahren, um Daten zu ver- bzw. entschlüsseln oder auch Signaturen zu erzeugen.⁴²

Der sogenannte vorläufige Schlüssel, auch „pre master secret“ genannt, wird mit dem öffentlichen Schlüssel des Servers verschlüsselt und an diesen gesendet. Der Server kann den pre master secret nun mit seinem privaten Schlüssel entschlüsseln.

Er generiert mithilfe der ausgedachten Zahl des Clients und der ausgedachten Zahl des Servers den Master key (siehe hierzu TLS-Handshake Seite 31). Mit beiden Verfahren findet ein geheimer Schlüsselaustausch statt. Dieser Schlüssel wird nun genutzt, um die Daten, die zwischen Server und Client geschickt werden, symmetrisch zu verschlüsseln. Die SSL/TLS-Verbindung nutzt hierdurch die Vorteile der asymmetrischen sowie der symmetrischen Verschlüsselung. Die asymmetrische Verschlüsselung ist sehr sicher, aber auch sehr rechenintensiv. Bei der SSL/TLS- Verbindung wird nur für den Schlüsselaustausch die asymmetrische Verschlüsselung genutzt. Die symmetrische Verschlüsselung erfordert nicht viel Rechenleistung und wird daher für die Verschlüsselung aller Daten genutzt. Der Nachteil der symmetrischen Verschlüsselung – der unsichere Schlüsselaustausch – wurde durch das Diffie-Hellman- bzw. RSA-Verfahren eliminiert.⁴³

42 Vgl. Schneier, B., 1996, S. 466.

43 Vgl. SSL.de, letzter Zugriff 10.06.2013, https://www.ssl.de/ssl.html .

Technologien Der TLS Handshake im Überblick (s. Abbildung 2-11):⁴⁴⁴⁵

1. Der Client sendet eine „Client hello“-Nachricht an den Server; zusätzlich teilt er eine von ihm generierte Zufallszahl sowie die unterstützten TLS-Versionen mit.

2. Der Server antwortet mit einem „Server hello“. Auch er generiert eine Zufallszahl und sendet diese mit.

3. Der Server sendet außerdem sein Zertifikat zum Client. Sollte eine Client- Authentifizierung nötig sein, fordert er auch das Client-Zertifikat an. Schließlich sendet der Server eine „Server hello done“-Nachricht.

4. Wenn der Server ein Client-Zertifikat angefordert hat, muss der Client dieses zunächst senden.

5. Der Schlüsselaustausch zwischen Server und Client wird durchgeführt. Hierzu wird entweder das RSA- oder Diffie-Hellman-Verfahren verwendet:

a. RSA:

i. Der Client generiert einen zusätzlichen Pre-Master Secret und verschlüsselt diesen mit dem öffentlichen Schlüssel des Serverzertifikats. Anschließend sendet er den verschlüsselten Pre-Master Secret zum Server.

ii. Der Server erhält den Pre-Master Secret und kann hieraus den Master Secret mithilfe von beiden Zufallszahlen berechnen.

Auch der Client kann nun den gleichen Master Secret berechnen. Der Master Secret ist nun der Schlüssel, der verwendet wird, um die Daten zu verschlüsseln.

b. Diffie-Hellman (siehe 2.2.5 Diffie Hellman)

6. Der Client sendet eine „Change cipher spec“-Benachrichtigung zum Server, um ihm mitzuteilen, dass er mit dem gemeinsamen, geheimen Schlüssel nun anfangen möchte, Daten bzw. Nachrichten zu verschlüsseln. Zusätzlich sendet der Client eine „Client finished“-Nachricht, um dem Server mitzuteilen, dass der Schlüsselaustausch und die Schlüsselberechnung fertig ist.

7. Der Server erhält die „Change cipher spec“-Benachrichtigung und ändert seine Verschlüsselungsart auf symmetrische Verschlüsselung. Er nutzt hierfür nun den Master Secret oder auch Session Key. Schließlich sendet auch der Server eine Nachricht, dass er fertig ist: „Server finished“.

8. Die TLS-Verbindung ist nun aufgebaut. Server sowie Client können jetzt Daten mit dem Session Key verschlüsseln und diese gesichert über die Verbindung schicken.

44 Vgl. Schmeh, K., 2013, S. 658 f.

45 Vgl. Microsoft Security, letzter Zugriff 10.06.2013, http://msdn.microsoft.com .

Technologien

Abbildung 2-11 TLS-Verbindung Quelle: Eigene Darstellung