Hochschule Wismar

Fakultt fr Wirtschaftswissenschaften

Master-Thesis

Kryptografie und Verbindungsmanagement

von Smart Meter Gateways

Thesis zur Erlangung des Grades eines

Master of Science (M. Sc.)

eingereicht von: Ingo Krtzen

geboren am 17. November 1988 in Aachen Studiengang Wirtschaftsinformatik,

Betreuer: Prof. Dr. Jan Helmke

weitere Gutachter: Prof. Dr. Jrgen Cleve

Aachen, den 25. September 2013

- I -

I. INHALTSVERZEICHNIS

I. INHALTSVERZEICHNIS ........................................................................................... I

II. ABBILDUNGSVERZEICHNIS ................................................................................ III

III. TABELLENVERZEICHNIS ................................................................................. IV

IV. ABKRZUNGSVERZEICHNIS ........................................................................... V

1 EINLEITUNG ............................................................................................................ 1

1.1. MOTIVATION ........................................................................................................ 1 1.2. ZIEL .................................................................................................................... 3 1.3. LSUNGSANSATZ ................................................................................................. 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 Verschlsselung ............................................................................ 13 2.2.2 Asymmetrische Verschlsselung ........................................................................... 14 2.2.3 Hybride Verschlsselung ....................................................................................... 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

- II -

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. GROBDESIGN .................................................................................................... 60 4.2. FEINDESIGN ...................................................................................................... 66

4.2.1 CryptoProxy .......................................................................................................... 66 4.2.2 PKI-Manager ......................................................................................................... 79

5 SCHLUSSBETRACHTUNG ................................................................................... 91

5.1. KRITISCHE WRDIGUNG ..................................................................................... 91 5.2. FAZIT UND AUSBLICK .......................................................................................... 93

V. LITERATURVERZEICHNIS ................................................................................... VI

VI. EIDESSTATTLICHE ERKLRUNG .................................................................. XX

VII. ANHANG .......................................................................................................... VIII

VI.I. BSI-SPEZIFIKATION: ........................................................................................ VIII VI.II. SEQUENZDIAGRAMME: ....................................................................................... IX

- III -

II. ABBILDUNGSVERZEICHNIS Abbildung 1-1 Ziel ............................................................................................................ 3 Abbildung 1-2 Lsungsansatz ......................................................................................... 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 Verschlsselung.............................................................. 13 Abbildung 2-6 Asymmetrische Verschlsselung I .......................................................... 14 Abbildung 2-7 Asymmetrische Verschlsselung II ......................................................... 15 Abbildung 2-8 Hybride Verschlsselung ........................................................................ 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-Zugnge (connect) .............................................. IX Abbildung VI-2 ASM gesicherte TLS-Zugnge (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 fr EMT oder GWA erzeugen (CSR, asynchron) ................. XV Abbildung VI-8 Zertifikate fr EMT oder GWA erzeugen (CSR, synchron) .................. XVI Abbildung VI-9 Zu berwachendes Zertifikat hinzufgen ........................................... XVII Abbildung VI-10 CRL abfragen und prfen ................................................................ XVIII Abbildung VI-11 Ablaufende Zertifikate identifizieren .................................................. XIX

- IV -

III. TABELLENVERZEICHNIS Tabelle 3-1 Verfgbarkeitsklassen ................................................................................ 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 Signaturprfung, Eingabeparameter ......................................................... 77 Tabelle 4-18 Signaturprfung, Ausgabeparameter ........................................................ 77 Tabelle 4-19 Zertifikate erzeugen, Eingabeparameter ................................................... 78 Tabelle 4-20 Zertifikate erzeugen, Ausgabeparameter .................................................. 78 Tabelle 4-21 Event fr ablaufende Zertifikate, Eingabeparameter ................................. 83 Tabelle 4-22 Event fr gesperrte Zertifikate, Eingabeparameter ................................... 84 Tabelle 4-23 Zertifikat erhalten, Eingabeparameter ....................................................... 85 Tabelle 4-24 Zertifikat erhalten, Ausgabeparameter ...................................................... 85 Tabelle 4-25 Zertifikate hinzufgen, Eingabeparameter ................................................ 86 Tabelle 4-26 Zertifikate hinzufgen, 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 Prfung des Ablaufdatums, Eingabeparameter ........................................ 89 Tabelle 4-31 Prfung der Sperrungen, Eingabeparameter ............................................ 90

- V -

IV. ABKRZUNGSVERZEICHNIS Abkrzung Bedeutung 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 -

1 E INLEITUNG

MOTIVATION 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 Sicherheitslsungen und konzepten. Das derzeit auszuarbeitende Konzept behandelt die Problemstellung der sicheren Verbindung von intelligenten Strom-, Wasser- oder Gaszhlern 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 Zhler sollen in der Lage sein, die Verbrauchsinformationen der Haushalte in Deutschland an den Messstellenbetreiber zu bermitteln. Zustzlich ermglichen die neuartigen Zhler das tgliche Ablesen der Verbrauchs-informationen sowie eine grafische Darstellung des gesamten Verbrauches. Diese intelligenten Zhler werden auch Smart Meter (SM) genannt. Um die Anbindung der Smart Meter an einen Anbieter zu verwirklichen, wird eine Sicherheitslsung bentigt, die eine sichere Verbindung gewhrleistet. Das Bundesamt fr 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 Zhler geben, in jedem Mehrfamilienhaus einen fr jede Wohneinheit. Zustzlich muss auch fr jede Solaranlage ein Zhler angebracht werden. Alle Zhler in einer Strae 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

- 2 -

Jeder Zhler versendet je nach Konfiguration (in einem Abstand von mindestens 15 Minuten) die Verbrauchsdaten an den Messstellenbetreiber (MSB), den Netzbetreiber. Aufgrund des groen 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 knnen. Die Anzahl der angeschlossenen SMGW wird jedoch sehr gro sein. Dadurch wird auch die Anzahl der Verbindungen zu jedem Netzbetreiber eine nicht zu unterschtzende Gre annehmen. Zustzlich wird vom Bundesamt fr Sicherheit in der Informationstechnik neben der Hybrid-Verschlsselung und der TLS-Verbindung eine weitere Verschlsselung vorgeschrieben. Alle symmetrisch verschlsselten Daten mssen zustzlich noch einmal asymmetrisch verschlsselt werden. Die erneute Verschlsselung macht die Verbindung zwar noch sicherer, ist jedoch auch dafr verantwortlich, dass das Abarbeiten einer Anfrage wesentlich lnger dauert, da eine asymmetrische Verschlsselung sehr viel Zeit in Anspruch nimmt. Der asymmetrische Verschlsselungsalgorithmus bentigt wesentlich mehr Zeit als ein symmetrischer. Wenn in jeder Strae 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 groe Anzahl von Verbindungen zu verwalten sein, die die Verbrauchsdaten an den Messstellenbetreiber senden. Hier muss dafr gesorgt werden, dass das Senden der Daten jeder Verbindung bis zum nchsten Senden abgeschlossen ist, da sonst ein Stau und Timeouts entstehen.

Ziel

- 3 -

ZIEL 1.2.

Das Ziel dieser Arbeit ist es, eine Sicherheitslsung zu entwickeln, welche die tatschliche Einfhrung der SM und SMGW in Deutschland mglich und sicher macht. Das hauptschliche Ziel liegt in der sicheren Verbindung zwischen dem SMGW und dem Netzbetreiber. Die zu entwickelnde Sicherheitslsung besteht aus der Verwaltung der TLS-Verbindung; hierzu gehren der Aufbau, die Speicherung und der Abbau der Verbindung. Auerdem ist die Kryptografie, d. h. das Verschlsseln der Informationen, ein Bestandteil der Sicherheitslsung. Diese wird fr die Verbindung, aber auch fr die zustzliche asymmetrische Verschlsselung bentigt. Im Smart-Meter-Umfeld gibt es fnf verschiedene Teilnehmer, die fr die Verbindung untersucht werden mssen. Hierzu gehren

- die Smart Meter (SM), - die dazugehrigen Smart Meter Gateways (SMGW), - die Gateway-Administratoren (GWA), - die Messstellenbetreiber (MSB) oder auch externe Marktteilnehmer (EMT) - sowie das zu konzeptionierende System fr 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

- 4 -

Ziel der Masterarbeit ist es, fr die Verbindung zwischen GWA und Gateways sowie zwischen EMT und Gateways ein System zu konzeptionieren, welches das Verbindungsmanagement sowie die gesamte Kryptografie fr EMT und GWA bernimmt. Technische sowie fachliche Anforderungen an dieses System mssen definiert und analysiert werden. Zustzlich soll eine Cluster-Lsung entwickelt werden, die die Hochverfgbarkeit gewhrleistet. Ein Design der verschiedenen bentigten Systeme muss geplant und ausgearbeitet werden. Hierzu werden Sequenzdiagramme sowie Klassendiagramme erstellt. Es muss zustzlich getestet werden, wie viele Anfragen mit wie vielen Maschinen abgearbeitet werden knnen. Hierzu sollen entsprechende Benchmarks erstellt werden. Das grte Augenmerk wird hierbei auf die Hardware-Security-Module gelegt, da die Verschlsselung der Daten der grte Erfolgsfaktor ist und den meisten Zeitaufwand beansprucht. Da das Erreichen der Benchmarks von unterschiedlichen Faktoren abhngt, die nicht beeinflussbar sind, sondern vielmehr von der Verfgbarkeit und Qualitt bentigter Informationen abhngen, ist dieses Ziel optional zu sehen. Die Spezifikation, die vom Bundesamt fr Sicherheit in der Informationstechnik zur Verfgung gestellt wurde, ist noch nicht endgltig fertiggestellt. Hier kann es noch Abweichungen geben. Zustzlich werden andere Faktoren wie die Hardwarebeschaffung sowie die Planung der Workshops mit mehreren Kunden eine Rolle spielen.

Lsungsansatz

- 5 -

LSUNGSANSATZ 1.3.

Das zu konzeptionierende System muss unterschiedliche Funktionen behandeln knnen. Daher sind die unterschiedlichen Funktionen in verschiedene Komponenten auszugliedern. Als berbegriff fr 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:

- Verschlsseln, Entschlsseln und Signieren von Daten, - Generierung und Speicherung der Schlssel, der Berechnung der Signatur

usw., - das Herunterladen von Zertifikaten und die Verwaltung der verschiedenen

Zertifikate, - die BSI-spezifische Nachrichtenverschlsselung, Signierung und

Entschlsselung sowie - das eigentliche Verwalten der TLS-Verbindungen

Zustzlich sollen die Funktionen zum Verschlsseln, Signieren und Entschlsseln von Daten in eine eigenstndige Anwendung ausgelagert werden. Das Gleiche gilt fr das Herunterladen von Issuer- und Intermediate-Zertifikaten sowie fr 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 gehren, 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-

verschlsselung) 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 Verschlsselungen und Signaturen,

kommuniziert als Einzige mit ASM)

Lsungsansatz

- 6 -

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

Abbildung 1-2 Lsungsansatz

Quelle: Eigene Darstellung

Wissenschaftliche Einordnung

- 7 -

WISSENSCHAFTLICHE EINORDNUNG 1.4.

Die IT-Sicherheit ist ein groer und wichtiger Bereich der Wirtschaftsinformatik. Aufgabe der IT-Sicherheit ist es, Schden 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 Verschlsselung, sondern eine hybride Verschlsselung. Das Verbindungsmanagement sowie die TLS-Verbindungen sind zustzlich noch von betriebswirtschaftlicher Bedeutung. Jeder Online-Shop bentigt eine sichere Verbindung, damit Kunden im Shop bezahlen knnen. Das Verbindungsmanagement ist wichtig, um garantieren zu knnen, dass mehrere Kunden gleichzeitig bezahlen knnen. Zahlungsdaten oder Messdaten sind vertrauliche Informationen und mssen daher besonders sensibel behandelt werden. Sie drfen nicht von Dritten gelesen werden oder gar verflscht werden knnen. Eine sichere TLS-Verbindung macht auch dies mglich. Auerdem zhlt die Schlsselaufbewahrung und Handhabung zu einer der kritischsten Aufgaben in der IT-Sicherheit. Hierzu werden Hardware-Security-Module genutzt, welche diese Aufgabe bernehmen. Die unterschiedlichsten Unternehmungen mssen im Bereich der Wirtschaftsinformatik herausfinden, welche Sicherheit sie bentigen und welche Sicherheit fr sie am wirtschaftlichsten ist. In der Wirtschaftsinformatik wird die IT-Sicherheit nicht nur als ein groer Kostenfaktor gesehen, die abgewehrten Schden werden den Kosten entgegengesetzt. Hierdurch knnen Manahmen begrndet werden, die die Sicherheit der Informationssysteme oder andere Bereiche der IT-Sicherheit gewhrleisten. Verursacht zum Beispiel der Diebstahl von Daten nur einen geringen Schaden, so ist es wirtschaftlicher, seine Daten nur auf einem kostengnstigen Niveau zu sichern. Werden jedoch Verbraucherdaten verarbeitet und verschickt, so trgt in Deutschland das Bundesamt fr Sicherheit in der Informationstechnik die Verantwortung dafr, dass die Lsungen der Unternehmen die Daten schtzen und die Datenschutzrichtlinien einhalten. Aus Datenschutzgrnden mssen die Daten so gesichert werden, dass unter keinen Umstnden ein Unbefugter die Daten lesen oder auswerten kann. Auch wenn der CryptoProxy diese Daten annimmt und weiterleitet, darf dieser die Messdaten nicht auslesen knnen.

Abgrenzung

- 8 -

ABGRENZUNG 1.5.

Das Clusterkonzept beinhaltet mehrere CryptoProxys. Die einzelnen Elemente des CryptoProxys mssen 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 Verfgung stellt. Smart Meter und Smart Meter Gateway sind zwar Teile des Systems, jedoch nicht Teil der Thesis. Diese befasst sich ausschlielich 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 endgltig fertiggestellt. Hier werden noch nderungen vom Bundesamt fr Sicherheit in der Informationstechnik erwartet.

Grundbegriffe

- 9 -

2 GRUNDLAGEN

GRUNDBEGRIFFE 2.1.

2.1.1 SMART METER

Smart Meter (SM) sind intelligente Zhler (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 Gaszhlern bernommen. Diese Zhler knnen den Verbrauch jedoch nur anzeigen. Ein Techniker des Netzbetreibers muss regelmig den Verbrauch ablesen und an den Netzbetreiber melden. Zustzlich sind diese Zhler 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 Geschftsmodell etablieren, denn intelligente Zhler 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

Auerdem knnen SM anzeigen, wie viel der Strom zu welcher Zeit gekostet hat. Hierfr beinhalten sie Tariflisten, die regelmig aktualisiert werden. Ein Verbraucher kann auerdem seine Verbrauchsdaten analysieren und seinen Stromverbrauch minimieren. SM sind daher in ein Kommunikationsnetzwerk eingebunden, um dem Netzbetreiber die aktuellen Verbruche melden zu knnen. Zustzlich bieten sie die Mglichkeit, ber ein Web-Interface verschiedene Konfigurationen vorzunehmen und aktuelle Daten anzuzeigen.

Grundbegriffe

- 10 -

Abbildung 2-2 Smart METER Web-Interface

Quelle: https://www.enbw.com/demo-kundenzentrum/# Stromanbieter bieten hierzu einen umfangreichen Kundenbereich auf ihrer Internetprsenz (siehe Abbildung 2-2). Von den Netzbetreibern wird ebenfalls die Mglichkeit angeboten, den Verbrauch auf Smartphones oder Tablet PCs anzeigen zu lassen(s. Abbildung 2-3). Hierzu werden von den Betreibern Applikationen fr mobile Systeme (Anwendungen fr 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 knnen den Verbrauch von Gas intelligent steuern. Hier werden ebenfalls neue Mglichkeiten geschaffen. Der SM im Haus kann zum Beispiel so eingerichtet werden, dass die Heizung tagsber ausgeschaltet ist und erst gegen 16 Uhr eingeschaltet wird. So wird Gas gespart und die Umwelt geschont; durch die

Grundbegriffe

- 11 -

Einbindung in das Kommunikationsnetzwerk erffnen sich hierfr neue Wege, um Energie zu sparen und die Umwelt zu schonen. Es werden zum Beispiel Applikationen fr Smartphones entwickelt, welche den genauen Standort des Verbrauchers ermitteln und mit dem SM kommunizieren. Hierdurch ist es mglich, die Heizung einzuschalten, sobald man sich in der Nhe 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 Zhlern empfngt, speichert und diese fr autorisierte Marktteilnehmer aufbereitet.1 Das heit, mehrere SM werden an einen SMGW angeschlossen. Dieser nimmt die Verbraucherdaten der SM entgegen und sendet sie zum Netzbetreiber (autorisierte Marktteilnehmer). Das SMGW verschlsselt die Daten, baut eine TLS-Verbindung auf und sendet die Daten an den CryptoProxy. Dieser leitet die Daten anschlieend weiter. Fr die Verschlsselung, Signaturerstellung und -prfung, Schlsselgenerierung, Schlsselaushandlung sowie die Aufbewahrung der Schlssel beinhaltet das SMGW ein Sicherheitsmodul, das diese Aufgaben bernimmt.2 In jedem Haus soll es in Zukunft mindestens einen SM geben, bei Mehrfamilienhusern soll fr jede Wohneinheit ein SM existieren. Zustzlich werden fr verschiedene Solaranlagen SM bentigt. Nach der derzeitigen Planung wird ein SMGW fr eine Strae eingerichtet. Alle SM in dieser Strae 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 dafr sorgen, dass der Betrieb des SMGW stets reibungslos gewhrleistet ist. Bei der Installation des SMGW gibt der GWA ein neues Zertifikat fr diesen Gateway in Auftrag, der fr den Aufbau der sicheren Verbindung zwischen GWA und SMGW bentigt 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 ntigen Konfigurationen des SMWG bernimmt der GWA. Die gesamte Kommunikation luft 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

- 12 -

2.1.4 HARDWARE SECURITY MODULE (HSM)

Hardware-Sicherheitsmodule werden eingesetzt, um auf der einen Seite private Schlssel (siehe 2.2 Kryptografie) sicher aufzubewahren und auf der anderen Seite, um kryptografische Algorithmen effizient auszufhren. Es sind Peripheriegerte, welche besonders abgesichert sind.3 In einem HSM knnen folgende Algorithmen fr die Kryptografie implementiert sein:

- Asymmetrisch o Verschlsseln und Entschlsseln von Daten o Signieren von Daten oder Zertifikaten o Schlsselaustauschverfahren (z. B. Diffie-Hellman)

- Symmetrisch o Symmetrisches Verschlsseln und Entschlsseln von Daten

- Erzeugen von Hash-Werten, zum Beispiel: o SHA-1 o SHA-256 o SHA-MD5

Zustzlich bieten unterschiedliche HSM die Mglichkeit, Zufallszahlen, PINs oder Schlsselpaare zu generieren. HSMs werden nach Sicherheitsstandards, wie z. B. FIPS 140-1 und 140-2, DK (Deutsche Kreditwirtschaft) oder Common Criteria (CC) zertifiziert. Speziell fr HSMs, die von Zertifizierungsdienstanbietern fr 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 Schlsselpaar, das fr die symmetrische bzw. auch fr die asymmetrische Verschlsselung oder Signierung bentigt wird, selbststndig zu generieren. Der ffentliche Schlssel kann danach exportiert werden. Der private Schlssel dagegen kann auf keinen Fall aus dem HSM gelesen werden. Selbst wenn man die Festplatte auszubauen versucht, ist der Schlssel gesichert. Bei diesem Vorgehen zerstrt sich die HSM selbst.

Abbildung 2-4 Atos security module

Quelle: Eigene Darstellung

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

Kryptografie

- 13 -

KRYPTOGRAFIE 2.2.

2.2.1 SYMMETRISCHE VERSCHLSSELUNG

Bei der symmetrischen Verschlsselung existiert nur ein Schlssel (s. Abbildung 2-5). Es gibt kein Schlsselpaar. Der Schlssel muss ber ein sicheres Medium ausgetauscht werden, damit beide Teilnehmer den Schlssel kennen. Hierbei muss darauf geachtet werden, dass kein Dritter den Schlssel abfangen kann.4

Abbildung 2-5 Symmetrische Verschlsselung

Quelle: http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/ Wurde der Schlssel ausgetauscht, knnen die verschlsselten Nachrichten sicher ber das Internet versendet werden. Um die Nachricht zu verschlsseln, nutzt Teilnehmer A den geheimen Schlssel. Die verschlsselte Nachricht kann nun nicht mehr gelesen werden. Auch bei einer Man-in-the-middle-Attacke, bei der ein Dritter die Kommunikation mithrt, kann die Nachricht von niemandem gelesen werden. Teilnehmer B jedoch kann die Nachricht mit dem gleichen geheimen Schlssel entschlsseln und lesen.5

4 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 22 ff. 5 Vgl. Schmeh, K., 2013, S. 391 f.

Kryptografie

- 14 -

2.2.2 ASYMMETRISCHE VERSCHLSSELUNG

Bei der asymmetrischen Verschlsselung werden zwei unterschiedliche Schlssel, jeweils zum Entschlsseln und zum Verschlsseln, genutzt. Bei der Schlsselgenerierung wird immer ein Schlsselpaar gebildet. Dieses Paar gehrt zusammen und besteht aus einem ffentlichen und einem privaten Schlssel. Der private Schlssel darf unter keinen Umstnden an Dritte herausgegeben werden oder verlorengehen. Der ffentliche Schlssel hingegen kann in ffentlichen Medien zur Verfgung gestellt werden, da mit der Nutzung des ffentlichen Schlssels kein Schaden oder Identittsdiebstahl gettigt werden kann.6

Abbildung 2-6 Asymmetrische Verschlsselung I

Quelle: http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/ Jemand, der den ffentlichen Schlssel besitzt, kann nun eine Nachricht seiner Wahl verschlsseln und an den Besitzer des privaten Schlssels senden (s. Abbildung 2-6). Mit dem ffentlichen Schlssel kann jedoch niemand eine Nachricht entschlsseln, und auch aus der verschlsselten Nachricht kann niemand Informationen entnehmen.

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

Kryptografie

- 15 -

Abbildung 2-7 Asymmetrische Verschlsselung II

Quelle: http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/ Bekommt der Besitzer des privaten Schlssels nun die Nachricht, kann dieser seinen geheimen privaten Schlssel nutzen, um die Nachricht zu entschlsseln und zu lesen (s. Abbildung 2-7).7 Die asymmetrische Verschlsselung ist im Gegensatz zur symmetrischen zwar sicherer, da der private Schlssel nicht bermittelt werden muss, dauert aber wesentlich lnger. Aus diesem Grund wird oft eine hybride Verschlsselung eingesetzt, welche beide Vorteile nutzt.8

7 Vgl. Ksters, R.; Wilke, T., 2011, S. 137 ff. 8 Vgl. Ksters, R.; Wilke, T., 2011, S. 175.

Kryptografie

- 16 -

2.2.3 HYBRIDE VERSCHLSSELUNG

Bei der hybriden Verschlsselung wird sowohl die asymmetrische als auch die symmetrische Verschlsselung genutzt. Beim Aufbau der Verbindung wird mittels asymmetrischer Verschlsselung der geheime Schlssel (privater symmetrischer Schlssel) versendet. Hierzu wird der geheime Schlssel selbst mit dem ffentlichen Schlssel des Empfngers verschlsselt und anschlieend gesendet. Da der Schlssel in einer Nachricht verschlsselt wurde, kann niemand den Schlssel dekodieren.9 Der Empfnger kann nun mit seinem privaten Schlssel die Nachricht mit dem geheimen Schlssel entschlsseln. Der Schlsselaustausch des symmetrischen Schlssels wurde auf Basis einer sicheren Kommunikation durchgefhrt. Hierdurch entfllt der Nachteil der symmetrischen Verschlsselung, der unsichere Schlsselaustausch (s. Abbildung 2-8).

Abbildung 2-8 Hybride Verschlsselung

Quelle: http://edoc.hu-berlin.de/master/ohst-daniel-2004-04-20/HTML/chapter3.html Alle folgenden Nachrichten werden nun symmetrisch mit dem geheimen Schlssel verschlsselt und versendet. Der Nachteil der asymmetrischen Verschlsselung die Dauer der Verschlsselung hat nur beim Schlsselaustausch eine Verzgerung bewirkt.

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

Kryptografie

- 17 -

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, heit dies nichts anderes, als das zustzlich zur Nachricht auch eine Signatur versendet wird. Wenn diese Signatur nun vom Empfnger geprft wird, wei dieser, dass die Nachricht vom Sender stammt und nicht manipuliert wurde. Um Signaturen zu erzeugen, bentigt man auf der einen Seite ein asymmetrisches Schlsselpaar und auf der anderen Seite eine Hashfunktion sowie eine Signier- und Verifikationsfunktion. Die Signierfunktion ist die Verschlsselung mithilfe des privaten Schlssels. Das Entschlsseln wird oft auch Verifikationsfunktion genannt. Einwegfunktionen sind Funktionen f, die sich leicht berechnen lassen, deren Umkehrung f1 jedoch nicht oder nur sehr schwer (d. h. mit nicht vertretbarem Aufwand) zu berechnen ist, insbesondere, wenn die Funktion f ffentlich bekannt ist.10 Die Abbildung der Zeichenkette oder Nachricht wird Fingerabdruck genannt.11 Aus einer Nachricht wird mit der gleichen Hashfunktion immer der gleiche Fingerabdruck erzeugt.12 Es gibt zwei Mglichkeiten eine Signatur zu erzeugen. Mit dem privaten Schlssel kann die Nachricht direkt signiert werde. Hierzu wird nur die verschlsselte Nachricht als Signatur geschickt. Der Empfnger kann dann mit dem ffentlichen Schlssel die Signatur prfen. Bei dieser Variante wird die komplette Nachricht entschlsselt. Man kann diese daher nur fr 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 anschlieend signiert (s. Abbildung 2-9).13 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. 12 Vgl. 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.

http://www.informatik.tu-darmstadt.de/

Kryptografie

- 18 -

Erzeugung einer digitalen Signatur fr eine Nachricht: 1. Der Fingerabdruck wird erzeugt (Hash-Wert ber Nachricht). 2. Die Signatur ist der verschlsselte Fingerabdruck (mit dem privaten

Schlssel). 3. Die Signatur wird an die Nachricht angehngt und versendet.14

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 Empfnger die vollstndige Nachricht sowie die Signatur erhalten hat, muss er diese prfen. Hierzu bentigt er den ffentlichen Schlssel des Senders. Es gibt fr den Empfnger zwei Mglichkeiten, diesen Schlssel zu erhalten. Entweder hat der Sender ihm den Schlssel zur Verfgung gestellt oder der Empfnger ldt sich den Schlssel beim zentralen Verzeichnisdienst, auch Trustcenter genannt, herunter15. Dieser zentrale Dienst speichert Zertifikate, in denen sich der ffentliche Schlssel befindet. Oft wird ein Zertifikat auch als ffentlicher Schlssel bezeichnet. Diese Bezeichnung ist jedoch nicht korrekt. Der Verzeichnisdienst ist die Verifizierungsstelle der Zertifikate. Das heit, diese Stelle signiert die Zertifikate der Benutzer und vertraut diesen somit. Eine weitere Aufgabe des Verzeichnisdienstes ist es, Sperrlisten (CRL) zur Verfgung zu stellen. Auf diesen Sperrlisten werden Zertifikate vermerkt, welche gesperrt wurden. Zertifikate werden dann gesperrt, wenn zum Beispiel der private Schlssel von einem Fremden entwendet wurde oder nur eine Sicherheitslcke besteht, sodass die Mglichkeit besteht, dass der private Schlssel gelesen werden knnte.

14 Vgl. Schneier, B., 1996, S. 38. 15 Vgl. Ertel, W., 2012 , S. 117.

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

Kryptografie

- 19 -

Wenn der Empfnger der Nachricht den ffentlichen Schlssel aus dem Zertifikat extrahiert oder von dem Sender empfangen hat, kann er die Signatur prfen (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. Zustzlich wird die Signatur entschlsselt. Diese Funktion ist das Gegenstck zur Signierfunktion.

3. Anschlieend wird der erzeugte Hash-Wert mit der entschlsselten Signatur verglichen. Sind die beiden Werte nicht identisch, so wurde die Nachricht manipuliert oder von einem anderen Sender abgeschickt.16

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.

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

Kryptografie

- 20 -

2.2.5 DIFFIE HELLMAN

Whitfield Diffie und Martin Hellman erfanden 1976 das Diffie-Hellman-Schlssel-austauschverfahren. Es war das erste Verfahren, mit dem es mglich war, einen gemeinsamen Schlssel unter zwei Teilnehmern zu berechnen und auszutauschen. Durch den Schlsselaustausch ist es mglich, geheime Daten zu verschlsseln und ber die Leitung zu versenden.17 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 grer die Primzahl ist, desto sicherer wird der Schlssel. Teilnehmer A und Teilnehmer B mssen sich nun beide eine geheime Zahl (a und b) ausdenken, welche nicht bermittelt werden und auch nicht weitergegeben werden drfen. Diese Zahlen drfen 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:18 A = ga (mod p) A bermittelt die errechnete Zahl an Teilnehmer B. Dieser berechnet ebenso eine Zahl, die dann an Teilnehmer A bermittelt werden kann: B = gb (mod p) Nachdem beide Zahlen bermittelt wurden, knnen beide Teilnehmer den gemeinsamen Schlssel 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 = Ba (mod p)

17 Vgl. Spitz, St.; Pramateftakis, M.; Swoboda, J., 2011, S. 192 130 18 Vgl. Schneier, B, 1996, S. 513.

Kryptografie

- 21 -

Die gleiche Zahl kann Teilnehmer B analog berechnen: K = Ab (mod p) 19 Mit der errechneten Zahl (K) hat man nun den geheimen Schlssel. Mit diesem Schlssel knnen die Daten symmetrisch verschlsselt und dann an den anderen Teilnehmer geschickt werden. Dieser kann die Daten entschlsseln und lesen.20 Bei diesem Verfahren ist der Aufwand fr den Angreifer, den Schlssel zu berechnen, sehr gro, da er nur die Zahlen A und B sowie die vereinbarten Zahlen p und q mithren kann. Die von Teilnehmer A und B ausgedachten Zahlen (a und b) kann niemand mithren. Und auch wenn der Angreifer den Schlssel berechnet hat, sind die Daten bis dahin meist unbrauchbar geworden, denn die Berechnung des Schlssels wrde zu lange dauern. Mit folgender Berechnung kann ein Angreifer den Schlssel 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

- 22 -

2.2.6 ELGAMAL

Das Verschlsselungs- und Signaturverfahren nach Elgamal beschreibt die Bestimmung eines gemeinsamen Schlssels zwischen zwei Teilnehmern sowie das Verschlsseln oder Signieren einer Nachricht mit diesem Schlssel. Elgamal ist ein asymmetrisches Schlsselverfahren, bei dem es einen privaten und einen ffentlichen Schlssel gibt. Um ein gemeinsames Schlsselpaar zwischen zwei Teilnehmern zu finden, agiert Elgamal hnlich wie das Diffie-Hellman-Verfahren (siehe 2.2.5 Diffie Hellman). Die Schlsselerzeugung 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 Schlsselerzeugung quivalent zum Diffie-Hellman-Verfahren durchgefhrt (siehe 2.2.5 Diffie Hellman ). Dieses Schlsselpaar kann nun genutzt werden: Signieren einer Nachricht21 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 abfngt, die Daten verflscht, denn die Signatur wird ber die Daten gebildet. Die Validierung der Signatur wrde bei verflschten Daten fehlschlagen. 22 Zur Erstellung der Signatur wird neben dem privaten Schlssel (a, nicht der gemeinsame private Schlssel, sondern die zufllige 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) bentigt; diese muss teilerfremd zu der Primzahl (p) sein. Zustzlich muss aus der Nachricht (x) der Hash gebildet werden (H(x)). Welcher Hash-Algorithmus hierfr verwendet wird, spielt dabei keine Rolle. Die Signatur (s1, s2) wird nun wie folgt berechnet: S1 = gz*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

- 23 -

Verifizieren der Signatur:23 Um die Signatur nun auf Richtigkeit zu prfen, werden zwei Bedingungen berprft: Die erste Bedingung besagt, dass s1 grer als 1sein muss, aber kleiner als die Primzahl (p). Also 1

Kryptografie

- 24 -

Verschlsseln einer Nachricht24 Bei der Verschlsselung einer Nachricht kommt im Gegensatz zur Signierung einer Nachricht der private Schlssel 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 verschlsselt 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 Blcke werden einzeln verschlsselt und anschlieend aneinander gehngt.25 c1 = B c2 = k*m mod p Hierbei ist m die Klartext-Nachricht und c1, c2 die verschlsselte Nachricht. c2 besteht aus allen vier verschlsselten Blcken. Nach dem vorliegenden Beispiel sieht c2 so aus: 06040301. Entschlsseln einer Nachricht Der Sender der Nachricht bermittelt c1 und c2, wobei c1 dem B im Diffie-Hellman-Verfahren entspricht. Diese Zahl ist wichtig fr die Entschlsselung der Nachricht. Auch hier wird c2 wieder in vier Blcke aufgeteilt und nacheinander entschlsselt. Im Klartext werden alle Stcke hintereinander gehngt. m = (B(p-1-a) * c2) mod p26

24 Vgl. Universitt Tbingen, 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

- 25 -

TECHNOLOGIEN 2.3.

2.3.1 WEBSERVICE

Ein Webservice oder Webdienst ist ein Dienst im Internet, der ber eine eigene Adresse verfgbar ist. Es gibt verschiedene Webservices, die unterschiedliche Kommunikationsprotokolle nutzen. Jeder Webservice muss daher eine eigene Schnittstellenbeschreibung zur Verfgung stellen. Clients knnen ber verschiedene bertragungsprotokolle eine Anfrage an einen Webservice senden. Hierbei wird meist jedoch HTTP genutzt. 27 Die Nutzung von Webservices steigt stetig an, da die meisten Webservices plattform- und programmiersprachenunabhngig sind. Ein groer Nachteil ist die fehlende Sicherheit bei Webservices. Beim Aufsetzen eines Web Services wird daher ein sicheres Konzept bentigt. Auerdem ist bei vielen Webservices die Performance nicht optimal, da sie auf Extensible Markup Language (XML) basieren. XML ist ein Datenformat fr Fachleute verschiedener Branchen, das die hochautomatisierte Verarbeitung von Text und Daten ermglicht, weil XML eine strenge Strukturierung erlaubt, so dass in geeigneten Anwendungsfllen groe Rationalisierungsgewinne zu realisieren sind.28

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

- 26 -

2.3.1.1 REST-WEBSERVICE

REST steht fr Representational State Transfer und ist ein Architektur-Modell fr Webanwendungen. REST dient als Anleitung fr 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 Aktivitten im Server anstoen.29 Der Server speichert hierbei keine Session fr einen Client. Daher mssen in einer Anfrage alle ntigen Informationen vorhanden sein. Es wird keine explizite Norm definiert, jedoch empfiehlt REST, Standards einzusetzen. Hierzu gehren:

- URI: zur Adressierung der Services - HTTP-Methoden (z. B. GET, POST): um auf die Services zuzugreifen - XML, XHTML, HTML, PNG: um Ressourcen zu versenden30 - 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.31 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.

http://www.oio.de/public/xml/rest-webservices.htmhttp://www.oio.de/public/xml/rest-webservices.htmhttp://www.oio.de/public/xml/rest-webservices.htm

Technologien

- 27 -

Die wichtigsten HTTP-Methoden im berblick:32 - GET: Ressourcen anfordern - POST: einer Ressource etwas hinzufgen - PUT: Ressourcen auf dem Server anlegen - DELETE: Ressourcen lschen

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 enthlt immer den HTTP-Antwort-Code. 33 Einige der hufigsten HTTP-Antwort-Codes:34

- 200 (OK) der reprsentative 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

gendert - 303 (See Other) Fehler - 304 (Not modified) die Ressource wurde nicht verndert 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 erfllt - 415 (Unsupported media type) die angeforderte Reprsentation wird nicht

untersttzt - 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. 371388.

http://www.infoq.com/articles/designing-restful-http-apps-rothhttps://testservice.eu/restservices/configurationservice/17

Technologien

- 28 -

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 plattformunabhngig.35 Es dient dem Versenden von Nachrichten. Ein SOAP-Webservice bietet eine WSDL-Datei an, die den Webservice und die Schnittstellen beschreibt.36 Jede Nachricht, die ber SOAP versendet wird, muss eine gltige XML-Nachricht sein. Ein Client sendet eine Anfrage und erhlt eine Antwort vom Webservice (Server). Bei der Verwendung von HTTP wird vor der SOAP-Nachricht, also Anfrage oder Antwort, zustzlich der HTTP Header sowie die XML-Definition mit angegeben.37 HTTP Header einer Anfrage: POST /perl/soaplite.cgi HTTP/1.0 Host: services.xmethods.net:80 Content-Type: text/xml; charset=utf-8 Content-Lnge: 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-Lnge: 545 Connection: close Content-Type: text/xml; charset=utf-8

In dem HTTP Header der Antwort wird zustzlich 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.

http://www.bitworld.de/index.php/grundlagen/soap

Technologien

- 29 -

Eine Beispiel-SOAP-Anfrage sieht wie folgt aus: 38 de_en Guten Tag

Der Webservice knnte mit folgender Antwort reagieren: 39 hello world

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

- 30 -

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 verschlsselt. Das SSL-Protokoll wird in Verbindung mit unterschiedlichen bertragungsprotokollen verwendet.40 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.41 Die TLS-Verbindung nutzt fr die sichere bertragung der Daten eine Hybridverschlsselung. Die Daten, die ber die Leitung geschickt werden, werden symmetrisch verschlsselt. Der symmetrische Schlssel wird mittels Diffie-Hellman (siehe 2.2.5 Diffie Hellman) asymmetrisch verschlsselt und bertragen. Eine TLS-Verbindung kann entweder eine nur serverseitige Authentifizierung beinhalten oder eine Client-Server-Authentifizierung. Das heit, entweder wird die Identitt des Servers sichergestellt oder beide Teilnehmer mssen sich durch ein Zertifikat eindeutig identifizieren. Bei einer Client-Server-Authentifizierung muss der Client ebenfalls ein vertrauenswrdiges Zertifikat sowie das dazugehrige Schlsselpaar besitzen. Bei einer serverseitigen Authentifizierung dagegen braucht der Client kein eigenes Zertifikat. In diesem Fall wird nur die Identitt des Servers sichergestellt. Der Aufbau einer TLS/SSL-Verbindung erfolgt auf zwei Ebenen. Auf der einen Ebene findet die symmetrische Verschlsselung der Daten statt. Die Echtheit der Daten wird durch einen Prfsummencheck, wie zum Beispiel den Secure Hash Algorithm (SHA), oder den Message Digest No. 5 (MD5) geprft. Auf der zweiten Ebene findet der Schlsselaustausch statt. Dieser erfolgt ber den TLS/SSL-Handshake. Hierbei wird zwischen dem Client und dem Server festgelegt, welche SSL/TLS-Versionen von beiden untersttzt werden und welche schlielich genutzt wird. Zustzlich findet beim Handshake auch die bermittlung der Zertifikate statt, die ntig ist, um die andere Seite auch als vertrauenswrdig einzustufen. In jedem Zertifikat ist ebenfalls der ffentliche Schlssel des jeweiligen Schlsselpaares enthalten.

40 Vgl. IT-Wissen, letzter Zugriff 10.06.2013, http://www.itwissen.info . 41 Vgl. Schmeh, K., 2013, S. 656.

http://www.itwissen.info/

Technologien

- 31 -

Sind die Zertifikate ausgetauscht, wird entweder mit RSA (Rivest, Shamir und Adleman) ein zuflliger, vorlufiger Schlssel gewrfelt oder das Diffie-Hellman-Verfahren angewandt, um den Schlsselaustausch zu vollziehen. RSA ist ein asymmetrisches kryptographisches Verfahren, um Daten zu ver- bzw. entschlsseln oder auch Signaturen zu erzeugen.42 Der sogenannte vorlufige Schlssel, auch pre master secret genannt, wird mit dem ffentlichen Schlssel des Servers verschlsselt und an diesen gesendet. Der Server kann den pre master secret nun mit seinem privaten Schlssel entschlsseln. 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 Schlsselaustausch statt. Dieser Schlssel wird nun genutzt, um die Daten, die zwischen Server und Client geschickt werden, symmetrisch zu verschlsseln. Die SSL/TLS-Verbindung nutzt hierdurch die Vorteile der asymmetrischen sowie der symmetrischen Verschlsselung. Die asymmetrische Verschlsselung ist sehr sicher, aber auch sehr rechenintensiv. Bei der SSL/TLS-Verbindung wird nur fr den Schlsselaustausch die asymmetrische Verschlsselung genutzt. Die symmetrische Verschlsselung erfordert nicht viel Rechenleistung und wird daher fr die Verschlsselung aller Daten genutzt. Der Nachteil der symmetrischen Verschlsselung der unsichere Schlsselaustausch wurde durch das Diffie-Hellman- bzw. RSA-Verfahren eliminiert.43

42 Vgl. Schneier, B., 1996, S. 466. 43 Vgl. SSL.de, letzter Zugriff 10.06.2013, https://www.ssl.de/ssl.html .

https://www.ssl.de/ssl.html

Technologien

- 32 -

Der TLS Handshake im berblick (s. Abbildung 2-11):4445

1. Der Client sendet eine Client hello-Nachricht an den Server; zustzlich teilt er eine von ihm generierte Zufallszahl sowie die untersttzten TLS-Versionen mit.

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

3. Der Server sendet auerdem sein Zertifikat zum Client. Sollte eine Client-Authentifizierung ntig sein, fordert er auch das Client-Zertifikat an. Schlielich sendet der Server eine Server hello done-Nachricht.

4. Wenn der Server ein Client-Zertifikat angefordert hat, muss der Client dieses zunchst senden.

5. Der Schlsselaustausch zwischen Server und Client wird durchgefhrt. Hierzu wird entweder das RSA- oder Diffie-Hellman-Verfahren verwendet:

a. RSA: i. Der Client generiert einen zustzlichen Pre-Master Secret und

verschlsselt diesen mit dem ffentlichen Schlssel des Serverzertifikats. Anschlieend sendet er den verschlsselten Pre-Master Secret zum Server.

ii. Der Server erhlt 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 Schlssel, der verwendet wird, um die Daten zu verschlsseln.

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 Schlssel nun anfangen mchte, Daten bzw. Nachrichten zu verschlsseln. Zustzlich sendet der Client eine Client finished-Nachricht, um dem Server mitzuteilen, dass der Schlsselaustausch und die Schlsselberechnung fertig ist.

7. Der Server erhlt die Change cipher spec-Benachrichtigung und ndert seine Verschlsselungsart auf symmetrische Verschlsselung. Er nutzt hierfr nun den Master Secret oder auch Session Key. Schlielich sendet auch der Server eine Nachricht, dass er fertig ist: Server finished.

8. Die TLS-Verbindung ist nun aufgebaut. Server sowie Client knnen jetzt Daten mit dem Session Key verschlsseln 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 .

http://msdn.microsoft.com/

Technologien

- 33 -

Abbildung 2-11 TLS-Verbindung

Quelle: Eigene Darstellung

Technologien

- 34 -

2.3.3 MESSAGE PROTECTION

Zustzlich zur TLS-Verbindung schreibt das Bundesamt fr Sicherheit in der Informationstechnik vor, die bereits symmetrisch verschlsselten Daten noch einmal asymmetrisch zu verschlsseln. Hierdurch kann zwar ein hoher Grad an Sicherheit geboten werden, die Dauer der Nachrichtenbertragung nimmt jedoch enorm zu. Fr jeden Teilnehmer gibt es fr die Message Protection ein eigenes Schlsselpaar, das aus einem ffentlichen und einem privaten Schlssel besteht. Zustzlich bentigt jeder Teilnehmer ein vertrauenswrdiges Zertifikat. Dieses beinhaltet den ffentlichen Schlssel. Ein Teilnehmer A, der einem Teilnehmer B eine Nachricht schicken mchte, muss das Zertifikat des Empfngers besitzen. Wenn nun die TLS-Verbindung von einem Teilnehmer zum anderen aufgebaut wurde, werden die symmetrisch verschlsselten Daten, die bertragen werden sollen, mit dem ffentlichen Schlssel des Empfngers verschlsselt (siehe 2.3.2 Transport Layer Security (TLS)) (s. Abbildung 2-12). Zustzlich wird eine Signatur gebildet, die dem anderen Teilnehmer die Identitt sichert. Theoretisch sind fr TLS-Verbindungen die asymmetrische Verschlsselung, die Signierung, ein Schlsselpaar und ein vertrauenswrdiges Zertifikat pro Teilnehmer ausreichend. Die BSI-Spezifikation schreibt jedoch ein Zertifikatstriple vor. Das heit, es gibt sowohl fr die TLS-Verbindung als auch fr die asymmetrische Verschlsselung und ebenfalls fr die Signierung ein eigenes Schlsselpaar. Auerdem wird fr jeden Schritt zu dem jeweiligen Schlsselpaar ein vertrauenswrdiges Zertifikat bentigt.

(Client)

(Server)

TLS-

Technologien

- 35 -

2.3.4 SHARDING

Sharding ist eine Art der Datenbankpartitionierung. Der Datenbestand wird auf mehrere Server aufgeteilt, wodurch die Datenmenge pro Server verringert wird und sich auf mehrere Server verteilt. Dies erzielt eine Performancesteigerung im Umgang mit groen Datenmengen. Da nun die Daten verteilt sind, muss sichergestellt sein, dass sie trotzdem abgerufen werden knnen und bekannt, wo diese zu finden sind. Hierfr werden Datenstze, deren Inhalt zum Beispiel aus personenbezogenen Daten besteht, so aufgeteilt, dass die Anfangsbuchstaben der Personennamen von A bis E auf dem ersten Server liegen (s. Abbildung 2-13). Auf den zweiten werden dann alle Datenstze von F bis J gelegt, bis schlielich alle Daten gleichmig auf den Servern verteilt wurden. Wenn ein Datensatz nun neu erzeugt wird, ist anhand des Anfangsbuchstabens der Person zu erkennen, welchem Server der Datensatz zugeordnet werden muss. Das Gleiche gilt, wenn ein Datensatz eingelesen werden soll.46 47

Abbildung 2-13 Database-Sharding

Quelle: http://www.cubrid.org/manual/91/en/shard.html

46 Vgl. Datenbank-Engines, letzter Zugriff 19.06.2013, http://db-engines.com/de/article/Sharding . 47 Vgl. CUBRID, letzter Zugriff 20.06.2013, http://www.cubrid.org/manual/91/en/shard.html .

http://db-engines.com/de/article/Shardinghttp://www.cubrid.org/manual/91/en/shard.html

Software

- 36 -

SOFTWARE 2.4.

2.4.1 APACHE ZOOKEEPER

Apache Zookeeper ist ein Dienst, der helfen soll, Cluster-Umgebungen aufzusetzen und diese zu verwalten.48 Das heit, Zookeeper bietet die Mglichkeit, eine dateisystemhnliche Schnittstelle zwischen den verschiedenen Servern bereitzustellen. Diese ist zentral verfgbar und wird repliziert. Um alle Server oder auch Knoten synchron zu halten und auf den Ausfall eines Servers reagieren zu knnen, wird der Ansatz der State Machines verwendet. Dieser wurde 1990 von Schneider beschrieben. Er sagt, dass ein Dienst einen Zustand hat, der bei allen Replikaten gleich zu halten ist, indem alle zustandsverndernden Operationen auf allen Replikaten gleich angewendet werden. Auerdem wird dafr gesorgt, dass auch bei einem totalen Systemausfall der alte Systemstand wiederhergestellt werden kann. Dies wird ber eine Log-Datei umgesetzt. In diese Log-Datei wird jede zustandsverndernde Operation geschrieben, bevor sie ausgefhrt wird.

2.4.2 PACEMAKER

Fr jeden Cluster wird eine Cluster-Software bentigt, welche die verschiedenen Instanzen verwaltet. Hierzu zhlt auch das Failover bei Hochverfgbarkeitslsungen. Das heit, die Cluster-Software, auch Cluster-Manager genannt, muss bei Ausfall einer Serverinstanz auf eine andere umschalten, damit die Applikationen weiterhin verfgbar sind.49 Auch bei anderen Problemen muss eine Cluster-Software entsprechend reagieren, um die Verfgbarkeit der Anwendungen zu gewhrleisten. Wenn ein Cluster-Manager auf eine zweite Instanz umschaltet, kann es passieren, dass das Dateisystem von der ersten Instanz noch nicht freigegeben wurde und noch blockiert ist. Das hat zur Folge, dass die neue Instanz nicht auf das Dateisystem zugreifen kann, auch wenn die erste Instanz bereits heruntergefahren wurde. Hierzu gibt es die Mglichkeit, den Manager so zu konfigurieren, dass dieser beim Umschalten auf eine andere Instanz die gesamte Stromverbindung zur ersten Instanz kappt. Dies stellt sicher, dass das Dateisystem freigegeben ist, wenn die neue Instanz darauf zugreifen mchte. Pacemaker ist der erste brauchbare Cluster-Manager, der auf Basis einer Open-Source-Software fr Linux entwickelt wurde.50 Pacemaker bietet eine zustzliche grafische Oberflche an, um die verschiedenen Instanzen manuell zu berwachen.

2.4.3 APACHE CASSANDRA

48 Vgl. Zookeper Apache, letzter Zugriff 02.06.2013, http://zookeeper.apache.org/ . 49 Vgl. Admin-Magazin, letzter Zugriff 01.07.2013, http://www.admin-magazin.de . 50 Vgl. Pacemaker, letzter Zugriff 05.07.2013, http://clusterlabs.org/ .

http://zookeeper.apache.org/http://www.admin-magazin.de/http://clusterlabs.org/

Software

- 37 -

Cassandra ist ein Projekt von Apache und steht daher unter der Apache-Lizenz. Es wird offen dokumentiert und ist als freie Software verfgbar.51 Fr die Bearbeitung von groen Daten braucht man eine Datenbank, die diese Aufgabe bernimmt. Doch nicht jede Datenbank kann eine groe Menge an Daten auch verarbeiten und/oder speichern. Die meisten Datenbanken, die zum Beispiel auf SQL aufbauen, knnen Daten zwar systematisch verarbeiten und speichern, sind jedoch auf Grund ihrer schlechten Speicher- sowie Verarbeitungsverfahren fr groe Datenmengen nicht zu gebrauchen. Verschiedene NoSQL-Datenbanken bieten zwar keine komfortable Sprache zur Speicherung und Verwaltung der Daten, knnen dafr aber sehr groe Datenmengen speichern und verwalten. Zustzlich sind diese NoSQL-Datenbanken auf die Optimierung der Zugriffszeiten ausgelegt. Sie bieten sich also optimal fr den Umgang mit groen Datenmengen an. Apache Cassandra ist ein solches verteiltes NoSQL-Datenbankverwaltungssystem. Es bietet neben der hohen Skalierbarkeit ein sehr gutes Konzept fr die Ausfallsicherung. Diese besonderen Merkmale machen Cassandra zu einem wichtigen Datenverwaltungssystem.52

51 Vgl. Cassandra Apache, letzter Zugriff 02.07.2013, http://cassandra.apache.org/ 52 Vgl. Curtalo, letzter Zugriff 02.07.2013, http://www.curtalo.de/workshop/von-wie-apache-bis-wie-zookeeper/ .

http://cassandra.apache.org/http://www.curtalo.de/workshop/von-wie-apache-bis-wie-zookeeper/http://www.curtalo.de/workshop/von-wie-apache-bis-wie-zookeeper/http://www.curtalo.de/workshop/von-wie-apache-bis-wie-zookeeper/

Software

- 38 -

3 ANFORDERUNGSANALYSE Das SMGW bernimmt den Aufbau der TLS-Verbindung sowie die bermittlung der Daten an den CryptoProxy. Der CryptoProxy soll von Atos Worldline entwickelt werden. Zustzlich werden nach einer ersten Analyse folgende Elemente bentigt:

- HSM (Hardware Security Module): Zum Verwalten von privaten Schlsseln sowie zum Verschlsseln und Signieren von Daten.

- Signing API/JSS: Um Daten, die verschlsselt oder signiert werden sollen, an die HSM zu schicken. Hier wird die gesamte Kommunikation mit der HSM abgebildet.

- PKI-Manager: Im PKI-Manager werden die Zertifikate verwaltet und die Gltigkeit geprft. Ebenfalls werden Sperrlisten von den Zertifikatsherausgebern geholt und berprft.

Das TLS-Channel-Management, in dem die TLS-Verbindungen aufgebaut und verwaltet werden, wird ebenfalls vom CryptoProxy bernommen.

Nichtfunktionale Anforderungen

- 39 -

NICHTFUNKTIONALE ANFORDERUNGEN 3.1.

3.1.1 CRYPTOPROXY

Der CryptoProxy kann an zwei Stellen im System eingesetzt werden:

- vor einem GWA oder - vor einem EMT.

Fr die nichtfunktionalen Anforderungen stellt es keinen Unterschied dar, ob der CryptoProxy und der PKI-Manager vor einem EMT oder einem GWA stehen.

3.1.1.1 TRANSPARENZ

Fr den Benutzer des CryptoProxy sind Klassendiagramme und auch Vorgehensweisen des CryptoProxys irrelevant. Der Benutzer, der entweder ein Gateway Admin oder ein Messstellenbetreiber ist, mchte seine Daten an den CryptoProxy schicken und sicher sein, dass die Daten gem den Sicherheitsvorschriften des Bundesamtes fr Sicherheit in der Informationstechnik verschickt werden. Der CryptoProxy bernimmt die komplette Kryptografie sowie die Verwaltung von TLS-Verbindungen, sodass der Benutzer diese Problematik nicht beachten muss. Vom CryptoProxy zum Benutzer besteht eine sichere Verbindung. Das bedeutet, dass die Verbindung von auen nicht zu erreichen ist. Der CryptoProxy bietet dem Benutzer unterschiedliche Schnittstellen, die es ermglichen sollen, die zu verschickenden Daten unkompliziert an den CryptoProxy zu versenden. Zustzlich nimmt der CryptoProxy empfangene Daten fr den Benutzer an. Er bereitet die Daten so auf, dass sie im Klartext vorliegen und vom Benutzer ohne groen Aufwand transparent gelesen werden knnen. Der CryptoProxy verschickt die Daten ber die gemeinsame Schnittstelle zum Benutzer.

Nichtfunktionale Anforderungen

- 40 -

3.1.1.2 VERFGBARKEIT

Der CryptoProxy muss hochverfgbar sein. Das heit, er darf zu keiner Zeit ausfallen. Wenn eine Instanz des Clusters ausfllt, muss die Cluster-Software dafr sorgen, dass eine andere Instanz die Aufgaben bernimmt. Hierbei knnen mehrere Schwierigkeiten auftreten. Zum Beispiel, wenn das Problem von einem noch nicht freigegebenen Dateisystem behandelt werden muss. Hier muss die Cluster-Software sicherstellen, dass die neue Instanz auf das Dateisystem zugreifen kann und das Dateisystem von keinem anderen Knoten annektiert ist. Diese Aufgabe kann mit Apache Zookeeper umgesetzt werden. Man unterscheidet bei der Verfgbarkeit zwischen folgenden Verfgbarkeitsklassen, die in der Tabelle 3-1 aufgelistet sind. Tabelle 3 1 Verfgbarkeitsklassen Verfgbarkeitsklasse Verfgbarkeit Max. Ausfall pro Jahr 2 99 % 87,66 Stunden 3 99,9 % 8,76 Stunden 4 99,99 % 52,6 Minuten 5 99,999 % 5,26 Minuten

Tabelle 3-1 Verfgbarkeitsklassen Quelle: Eigene Darstellung

Nichtfunktionale Anforderungen

- 41 -

Alternativ gibt es die Availability-Environment-Classification-Kennzahlen (s. Tabelle 3-2)53. Tabelle 3 2 Availability Environment Classification Availability Environment Classification

Beschreibung

AEC-0 (Conventional) Funktion kann unterbrochen werden, Datenintegritt ist nicht essentiell

AEC-1 (Highly Reliable) Funktion kann unterbrochen werden, Datenintegritt muss jedoch gewhrleistet sein

AEC-2 (High Availability) Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit minimal unterbrochen werden

AEC-3 (Fault Resilient) Funktion muss innerhalb festgelegter Zeiten oder whrend der Hauptbetriebszeit ununterbrochen aufrechterhalten werden

AEC-4 (Fault Tolerant) Funktion muss ununterbrochen aufrechterhalten werden, 24/7-Betrieb muss gewhrleistet sein

AEC-5 (Disaster Tolerant) Funktion muss unter allen Umstnden verfgbar sein

Tabelle 3-2 Availability Environment Classification Quelle:

In Anlehnung an : Quelle: http://www.it-administrator.de/themen/server_client/grundlagen/98988.html

Diese Verfgbarkeitsklassen und auch Kennzahlen ordnen die Verfgbarkeit eines Systems ein. Der CryptoProxy sollte eine Verfgbarkeit von 99,99 % erreichen.

53 Vgl. IT-Administrator, letzter Zugriff 24.07.2013, http://www.it-administrator.de .

http://www.it-administrator.de/http://www.it-administrator.de/themen/server_client/grundlagen/98988.htmlhttp://www.it-administrator.de/themen/server_client/grundlagen/98988.html

Nichtfunktionale Anforderungen

- 42 -

3.1.1.3 LASTVERTEILUNG

Die Anfragen an den CrpytoProxy werden eine nicht zu unterschtzende Gre einnehmen. Daher muss die Lastverteilung so gewhlt werden, dass auf jeden Knoten im Cluster die Anfragen gleichmig verteilt werden (siehe 4.1.1 Cluster). Sollten zu viele Anfragen auf eine Serverinstanz geraten, kann es passieren, dass dieser Server nicht mehr reagiert, da er zu viele Anfragen in seinem Speicher hat. In diesem Fall werden die Anfragen, die noch im Speicher sind, verworfen und von keiner anderen Instanz abgearbeitet. Der Cluster erkennt zwar, dass ein Knoten ausgefallen ist und verteilt die IP-Adressen auf die anderen Instanzen, die Anfragen aus dem Speicher jedoch sind nicht wiederherzustellen. Lastverteilung wurde frher mit einem Load Balancer geregelt. Dessen Schwachstelle ist jedoch, dass er einen Flaschenhals bildet (ein Load Balancer ist nicht redundant; wenn er ausfllt, knnen Anfragen nicht an die Cluster-Knoten weitergeleitet werden) und bei Ausfall somit das gesamte System nicht mehr erreichbar ist. Daher distanziert sich die moderne Systemarchitektur mittlerweile von dieser Anordnung. Fr dieses Problem gibt es heute andere Methoden, um die Last auf die Cluster-Knoten zu verteilen. Beim CryptoProxy erfolgt die Lastverteilung durch ein Sharding-Konzept (siehe 3.3.1 Cluster).

3.1.1.4 ZUGRIFFSBESCHRNKUNG

Fr die Sicherheit des Systems ist es notwendig, dass die Zugriffe auf den CryptoProxy beschrnkt sind. Von auen drfen nur TLS-Verbindungen mit Client/Server-Authentifizierung zugelassen werden. Hierdurch wird sichergestellt, dass sich nicht nur der Server identifiziert, sondern auch der Client, das SMGW. Zustzlich muss darauf geachtet werden, dass die Schnittstellen fr EMT und GWA abgesichert sind. Diese Schnittstellen drfen nur aus dem sicheren Netzwerk zwischen EMT (bzw. GWA) und CryptoProxy aufgerufen werden. Neben der Netzwerk- und Softwareebene muss auch auf die Hardware-Zugriffs-beschrnkung geachtet werden. Hierzu wurden Sicherheits-Policies ausgearbeitet, die eingehalten werden mssen. Kein Unbefugter darf von seiner Workstation auf die Maschinen gelangen. Die Administratoren, die fr die Wartung des Clusters sowie der Server verantwortlich sind, mssen per SSH-Zugriff auf die Maschinen gelangen knnen. Dieser SSH-Zugriff darf jedoch nur vom eigenen Rechner aus freigegeben sein und muss mit einem Schlsselpaar und einem dazugehrigen Zertifikat abgesichert sein. Ein SSH-Zugriff nur mit Passwortauthentifizierung darf nicht genehmigt werden.

Nichtfunktionale Anforderungen

- 43 -

3.1.1.5 FLEXIBILITT

Der CryptoProxy soll sich in Zukunft als Produkt auf dem Energiemarkt etablieren. Hierzu ist es notwendig, dass er in Bezug auf Programmiersprachenunabhngigkeit und andere Standards flexibel ist. Da es Kunden geben kann, die den CryptoProxy selbst hosten wollen, muss dieser ebenfalls vom Betriebssystem unabhngig geschrieben sein. Um diese Flexibilitt zu gewhrleisten, wird die Programmiersprache Java genutzt. Zustzlich werden die Schnittstellen mit der RESTFULL-API, die zur Erstellung der REST-Webservices genutzt wird, erstellt. Diese sind programmiersprachenunabhngig, da nur HTTP-Methoden (z. B. GET, POST, PUT) verwendet werden. Neben diesen REST-Webservices werden zustzlich fr die Schnittstellen SOAP-Webservices entwickelt. Diese sind ebenfalls programmiersprachenunabhngig und werden mit Hilfe der XML-Datenstruktur angesprochen. Welche Schnittstelle der Kunde nutzt, ist ihm berlassen.

Nichtfunktionale Anforderungen

- 44 -

3.1.2 SIGNINGAPI

Fr die SigningAPI sowie fr die ASM sind einige nichtfunktionale Anforderungen zu beachten, die im Folgenden beschrieben werden. Da jedoch die SigningAPI und die ASM bereits als Produkt der Atos Worldline GmbH gefhrt werden, sind diese Anforderungen bereits erfllt.

3.1.2.1 TRANSPARENZ

Fr die Benutzung der SigningAPI ist es erforderlich, dass die Anfragen transparent weitergereicht werden. Der Benutzer darf nicht sehen, was im Hintergrund geschieht. Die Anfrage soll ber die SigningAPI eingereicht, ber das ASM bearbeitet und schlielich von der SigningAPI wieder zum Drittsystem zurckgeleitet werden. Der Benutzer der SigningAPI fhrt einen einzelnen einfachen Befehl aus, indem er angibt, welcher Schlssel in der ASM benutzt werden soll und welcher Verschlsselungs- oder Signieralgorithmus ausgefhrt werden soll. Anschlieend erhlt er von der SigningAPI die gewnschten Informationen. Die Existenz der ASM ist fr den Benutzer nicht von Interesse.

3.1.2.2 VERFGBARKEIT DER ASM

Da die Atos-Security-Module zur Ver- und Entschlsselung sowie zur Signaturerzeugung bentigt werden, darf es nicht vorkommen, dass ber einen lngeren Zeitraum kein ASM erreichbar ist. Die ASM mssen redundant aufgebaut werden. Sollte ein ASM ausfallen, mssen die anderen ASM die Aufgaben des ausgefallenen ASM bernehmen.

3.1.2.3 VERFGBARKEIT DER SIGNINGAPI

Wie das ASM darf auch die SigningAPI nicht ber einen lngeren Zeitraum ausfallen. Das heit, die Schnittstelle selber muss gegen jeden Angriff gesichert sein und die Anfragen weiterleiten oder verwerfen. Die SigningAPI sollte im Internet nicht erreichbar sein, GWA, EMT sowie CryptoProxy sollten ber ein gesichertes Netzwerk agieren.

Nichtfunktionale Anforderungen

- 45 -

3.1.2.4 LASTVERTEILUNG DER ASM

Bei redundanten Systemen tritt stets das Problem der Lastverteilung auf. Auch wenn mehrere ASM zur Ausfallsicherheit zur Verfgung stehen, heit dies nicht, dass die Last auch automatisch verteilt wird. Je mehr Anfragen auf einem ASM gettigt werden und je grer die Last wird, desto langsamer werden die Anfragen bearbeitet, da sie erst in einer Liste abgearbeitet werden mssen. Irgendwann ist die Last so gro, dass das ASM ausfllt. Daher ist es erforderlich, eine Architektur zu entwerfen, die die Lastverteilung fr die ASM regelt. Bei einem sogenannten Load Balancer wird die Last gleichmig verteilt (siehe 3.1.1.3 Lastverteilung). Eine andere Mglichkeit besteht darin, die Last nur dann zu verteilen, wenn die erste ASM die Anfragen nicht mehr kontinuierlich abarbeiten kann. Hierzu werden von dem Server die Anfragen an die verschiedenen ASM weitergeleitet. Ein ASM hat seine Kapazitt dann erreicht, wenn auf der Liste der abzuarbeitenden Befehle bereits ein Befehl wartet. Ist dies der Fall, so wird der Befehl auf die Liste eines zweiten Moduls geschrieben. Dieses bernimmt dann den Befehl. Die Lastverteilung der ASM nutzt seit einigen Jahren keine Load Balancer mehr. Die entwickelte Lastverteilung, eine Aufgabe nur dann abzugeben, wenn die erste ASM eine Warteschleife bilden wrde, hat sich in den letzten Jahren im Einsatz bewhrt.

3.1.2.5 ZUGRIFFSBESCHRNKUNG

Die SigningAPI sollte fr die Benutzung von den unterschiedlichen Systemen aus erreichbar sein. Sie sollte jedoch sicherheitshalber nicht aus dem Internet verfgbar sein, da die Angriffe trotz enormer Sicherheitsmanahmen nicht abzuschtzen sind. Die SigningAPI und der Benutzer, der diese aufruft, knnen niemals ber die API auf die ASM zugreifen. Es ist auch nicht mglich, ein Schlsselpaar aus der ASM zu lesen. Die SigningAPI ist lediglich dazu da, die Funktionen der ASM aufzurufen und die Antwort weiterzuleiten. Hierbei wird auf die Schlssel im ASM referenziert. Die Zugriffe auf Netzwerkebene mssen bei den ASM zustzlich abgesichert werden. Die Module drfen von auen nicht erreichbar sein. Ausschlielich die SigningAPI darf eine Verbindung zu den ASM haben. Auch das Rechenzentrum muss vor unbefugtem Eindringen gesichert werden. Ausschlielich ausgewhlte Mitarbeiter drfen Zugang zu den ASM haben. Ein ASM ist zwar ein kostspieliges Modul, bei Diebstahl wiegt jedoch das Risiko, dass der Schlssel doch irgendwie aus der ASM extrahiert werden kann, schwerer als der Verlust des Geldes.

Nichtfunktionale Anforderungen

- 46 -

3.1.2.6 SICHERHEIT DER SCHLSSEL IM ASM

Die Sicherheit der Schlssel ist die wichtigste Aufgabe der ASM. Die in dem Modul generierten Schlssel drfen unter keinen Umstnden aus dem Modul extrahiert werden, weder per Zugriff auf die Hardware, noch per Netzwerkzugriff. Wenn ein privater Schlssel aus dem Modul extrahiert werden knnte, so kann man nicht mehr sicherstellen, dass nur der Berechtigte eine Signatur erzeugt hat und Nachrichten entschlsseln kann. Die gesamte Sicherheit wre somit gefhrdet. Die Atos Security-Module sind daher so abgesichert, dass niemand an den privaten oder auch ffentlichen Schlssel im Modul gelangt. Versucht man, die Festplatte aus dem Modul zu bauen, so zerstrt sich diese mit einer Farbe, hnlich wie in Geldkoffern, von selbst. Dies passiert schon bei grerer Erschtterung, daher ist es ebenfalls nur schwer mglich, ein ASM zu stehlen. Von auen ist ein ASM nie erreichbar. Nur die SigningAPI kann auf die ASM zugreifen. Hier ist es besonders wichtig, dass der Zugriff der SigningAPI begrenzt ist und gleichermaen gesichert wird. Die SigningAPI selbst darf auch keine Schlssel extrahieren. Sie kann diese Schlssel zum Beispiel nur in einem Verschlsselungsalgorithmus verwenden.

Nichtfunktionale Anforderungen

- 47 -

3.1.3 PKI-MANAGER

Der PKI-Manager wird als zustzliche Komponente zum CryptoProxy ausgeliefert. Im vollstndigen SES (Smart Energy Security) -System wird der PKI-Manager im gleichen Netz wie der CryptoProxy aufgebaut. Der PKI-Manager kann jedoch auch als einzelne Komponente verkauft und ausgeliefert werden. Dieser muss einzeln wie im gesamten System den gleichen Anforderungen entsprechen.

3.1.3.1 TRANSPARENZ

Analog zum CryptoProxy muss der PKI-Manager die Anfragen, die an ihn gestellt werden, transparent bearbeiten. Er bernimmt die komplette Verwaltung der Zertifikate sowie das Herunterladen der Zertifikate vom Zertifikatsherausgeber und das Verwalten des Zertifikats-Cache. Fr den Benutzer des PKI-Managers ist dies nicht sichtbar. ber die ihm zur Verfgung gestellten Schnittstellen sendet er sein