Kernkomponenten in der Cloud

Transkript

1 Dokumentation E-Government Kernkomponenten in der Cloud Version 1.0, Bernd Zwattendorfer Zusammenfassung: Cloud Computing ist seit Jahren eines der dominanten Themen im IT-Sektor, da sich viele Organisation eine hohe Kosteneinsparung erwarten. Aus diesem Grund ist Cloud Computing auch für die öffentliche Verwaltung interessant. Das größte Kosteneinsparungspotential haben Public Clouds. Private Clouds hingegen erlauben dafür eine größere Kontrolle über die in der Cloud gespeicherten bzw. verarbeiteten Daten. Im Rahmen dieses Projekts wurde untersucht, wie E-Government Kernkomponenten (MOA-ID und Online Vollmachten-Service) in eine Public Cloud migriert werden könnten, um die vollen Kostenvorteile abzuschöpfen, aber dass dabei die gespeicherten bzw. verarbeiteten Daten trotzdem so geschützt wie in einer Private Cloud sind. Für die entsprechende Realisierung wurden unterschiedliche kryptographische Technologien eingesetzt. Im Rahmen dieses Dokuments werden unterschiedliche Ansätze und Möglichkeiten auf Basis dieser Technologien skizziert. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung Verwendete Technologien Digitale Signaturen (DS) Redigierbare Signaturen (RS) Asymmetrische Verschlüsselung (AE) Proxy Re-Encryption (PRE) Fully Homomorphic Encryption (FHE) MOA-ID in der Public Cloud Allgemeine Architektur Ansatz 1: Verwendung von PRE und RS Vorbedingung Bürgerinnen- bzw. Bürgerregistrierung Service Provider Registrierung Identifizierungs- und Authentifizierungsprozess Ansatz 2: Verwendung von FHE Vorbedingung Bürgerinnen- bzw. Bürgerregistrierung Service Provider Registrierung Identifizierungs- und Authentifizierungsprozess Evaluierung Wiederverwendung existierenden Infrastruktur Konformität mit dem bestehen Prozessablauf Skalierbarkeit Praktikabilität Erweiterbarkeit Änderungen in der BKU Vertrauen in MOA-ID Online Vollmachten-Service in der Public Cloud Allgemeine Architektur Einleitung 2

3 4.2 Verwendung von DS und AE Vorbedingung Vollmachtregistrierung Vollmachtverwendung Audit einer Vollmachtverwendung Evaluierung Wiederverwendung existierender Infrastruktur Konformität zum aktuellen Prozessfluss Skalierbarkeit Praktikabilität Erweiterbarkeit Änderungen in der BKU Vertrauen in das MIS Zusammenfassung und Fazit Abbildungsverzeichnis Abbildung 1 - MOA-ID in der Public Cloud... 7 Abbildung 2 - Sequenzdiagramm des Identifizierungs- und Authentifizierungsprozesses unter Verwendung von PRE und RS... 9 Abbildung 3 - Sequenzdiagramm des Identifizierungs- und Authentifizierungsprozesses unter Verwendung von FHE Abbildung 4 - Online Vollmachten-Service in der Public Cloud Abbildung 5 - Sequenzdiagramm des Identifizierungs- und Authentifizierungsprozesses in Vertretung unter Verwendung von DS und AE Einleitung 3

4 1 Einleitung Cloud Computing ist seit Jahren eine der aufstrebenden Technologien, die ein hohes Markt- und Wachstumspotential versprechen. Die Gründe dieses Potential sind vielfältig. Vorteile sind vor allem die hohe Skalierbarkeit, dynamische Anpassung an Lastspitzen (Elastizität), hohe Verfügbarkeit, aber vor allem das dynamische Preismodell. Im Endeffekt werden nur jene IT Ressourcen (CPU-Zeit, Arbeitsspeicher, etc.) verrechnet, die auch wirklich verbraucht wurden. Diese Gründe machen Cloud Computing auch für die österreichische Verwaltung interessant, da dadurch eine enorme Kosteneinsparung möglich ist. Ein zentraler Betrieb von E-Government-Komponenten in der Cloud hätte somit neben zahlreichen technischen Vorteilen auch Vorteile in ökonomischer Hinsicht. Das größte Kosteneinsparungspotential ergibt sich bei der Verwendung von Public Clouds Clouds, die nicht für ein bestimmtes Unternehmen oder eine Organisation betrieben werden, sondern deren Ressourcen quasi der Allgemeinheit zur Verfügung stehen. Im Gegensatz dazu können bei Private Clouds oder Community Clouds IT Ressourcen nur von beteiligten Unternehmen oder Organisationen abgegriffen werden. Private Clouds bzw. Community Clouds erlauben daher mehr Kontrolle über die Daten, die in der Cloud gespeichert oder verarbeitet werden, als Public Clouds. Das Kosteneinsparungspotential von Private Clouds ist jedoch geringer als jenes von Public Clouds, wie z.b. in [HaYa10] beschrieben. Um das volle Kosteneinsparungspotential abschöpfen zu können, sollte man also E- Government Kernkomponenten nicht in eine Private Cloud sondern in eine Public Cloud migrieren. Hierbei können sich jedoch Probleme hinsichtlich Sicherheit und Datenschutz ergeben [ZiLe12]. Um diesen Problemen entgegenzuwirken, existieren bereits einige technologische Möglichkeiten (manche bis jetzt nur theoretischer Natur), um ein notwendiges Maß an Sicherheit und Datenschutz auch in Public Clouds gewährleisten zu können. Im Rahmen dieses Dokuments werden deshalb Möglichkeiten beschrieben, wie zwei E-Government-Kernkomponenten (MOA-ID und das Online Vollmachten-Service) in eine Public Cloud migriert werden könnten, ohne dass der Cloud Provider Zugriff auf den Inhalt der verarbeiteten Daten hat. Abschnitt 2 gibt dabei einen Überblick über die verwendeten Technologien. Wie MOA-ID und dessen Prozessfluss verändert werden müsste, wird in Abschnitt 3 beschrieben. Eine mögliche Migration des Online-Vollmachten-Services (MIS) in die Public Cloud wird in Abschnitt 4 erläutert. Das Projekt wird in Abschnitt 5 zusammengefasst. Einleitung 4

5 2 Verwendete Technologien 2.1 Digitale Signaturen (DS) Digitale Signaturen [RiShAd78] erlauben das Signieren von beliebigen Daten, sodass diese die folgenden Eigenschaften der Informationssicherheit aufweisen: Integrität, Authentizität, und Nicht-Absstreitbarkeit. Integrität bedeutet, dass die Nachricht beim Transfer z.b. zwischen Sender und Empfänger nicht verändert wurde. Authentizität gibt einem Empfänger die Information, dass die Nachricht von einem bestimmten Sender verschickt wurde und dass dieser den Versand nicht abstreiten kann (Nicht- Abstreitbarkeit). Digitale Signaturen basieren auf asymmetrischen Kryptografieverfahren, und somit auf der Verwendung von einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel wird dabei zum Signieren der Daten 1 verwendet, während der öffentliche Schlüssel zum Verifizieren der Signatur dient. Der öffentliche Schlüssel ist meist in ein Zertifikat eingebettet, welches den öffentlichen Schlüssel zu einer digitalen Identität bindet. Dieses Zertifkat ist meist von einer vertrauenswürdigen Stelle beglaubigt, die Teil einer Public-Key Infrastruktur (PKI) ist. 2.2 Redigierbare Signaturen (RS) Digitale Signaturen erlauben üblicherweise keine Veränderung der signierten Daten. In manchen Fällen kann es jedoch wünschenswert sein, dass Teile von signierten Daten entfernt oder verändert werden können, sodass die Original-Signatur trotzdem ihre Gültigkeit behält. Redigierbare Signaturen [JMS+02] ermöglichen diese Funktionalität, ohne dass der Original-Signator dazu nochmals eingreifen muss. Signaturverfahren, die das Entfernen von Teilen einer Signatur von beliebigen Personen bei Beibehaltung der Gültigkeit erlauben, werden als redigierbare Signaturen bezeichnet. Signaturverfahren, die das Austauschen von bestimmten Teilen von ausgewählten Personen bei Beibehaltung der Gültigkeit erlauben, werden als sanitizeable Signaturen [ACM+05] bezeichnet. 2.3 Asymmetrische Verschlüsselung (AE) Die asymmetrische Verschlüsselung [Simm79] dient dazu, die Vertraulichtkeit von Daten zu wahren und Daten entsprechend vor unbefugten Dritten geheim zu halten. Die Verschlüsselung erlaubt es, Daten von einem Sender zu einem Empfänger in unleserlicher Form zu übermitteln, sodass nur der Empfänger die Möglichkeit besitzt, den passenden Klartext wieder herzustellen. 1 Üblicherweise wird nur der Hash-Wert der Daten und nicht die Daten selbst signiert. Verwendete Technologien 5

6 Asymmetrische Verschlüsselungs-Verfahren verwenden ebenfalls ein Schlüsselpaar, wobei der öffentliche Schlüssel zum Verschlüsseln und der private Schlüssel zum Entschlüsseln der Nachricht dienen. 2.4 Proxy Re-Encryption (PRE) Bei Proxy Re-Encryption [GrAt07] handelt es sich ebenfalls um ein asymmetrisches Kryptographieverfahren, bei dem ein halbvertrauenswürdiger Proxy für Person A verschlüsselte Daten für eine andere Person B so umschlüsseln kann, dass Person B mit ihrem privaten Schlüssel die Daten wiederum entschlüsseln kann. Obwohl der Proxy die Daten umschlüsseln kann, erhält der Proxy weder Zugriff auf den Klartext noch auf die privaten Schlüssel zum Entschlüsseln von Person A oder B. Es gibt unterschiedliche Proxy Re-Encryption-Verfahren. Bei unidirektionalen Verfahren können Daten nur in eine Richtung umgeschlüsselt werden (z.b. von A nach B), während bei bidirektionalen Verfahren eine Umschlüsselung in beide Richtungen möglich ist (von A nach B und von B nach A). Außerdem kann zwischen Verfahren unterschieden werden, die entweder nur eine einmalige (z.b. von A nach B) oder eine mehrfache Umschlüsselung (z.b. von A nach B nach C) erlauben. 2.5 Fully Homomorphic Encryption (FHE) Fully Homomorphic Encryption (homomorphe Verschlüsselung) [Gent09] bezeichnet ein Verschlüsselungsverfahren, bei dem mathematische Operationen direkt auf verschlüsselten Daten ausgeführt werden können, ohne diese zuvor entschlüsseln zu müssen. Es kommt also beispielsweise das gleiche Ergebnis raus, wenn zwei Daten zuerst verschlüsselt und dann die verschlüsselten Daten addiert werden, oder ob zuerst die Daten addiert und anschließend das Ergebnis verschlüsselt wird. Die folgenden Gleichungen illustrieren dieses Verfahren, wobei m1 und m2 zwei verschiedene Datenblöcke sind und Enc die homomorphe Verschlüsselungsfunktion bezeichent. Enc(m1) + Enc(m2) = Enc(m1 + m2) Enc(m1) * Enc(m2) = Enc(m1 * m2) Verwendete Technologien 6

7 3 MOA-ID in der Public Cloud Dieser Abschnitt beschreibt unterschiedliche Lösungsmöglichkeiten unter Anwendung unterschiedlicher Technologien, wie MOA-ID in einer Public Cloud deployed werden könnte. Es wird dabei nur eine reine Bürgerkarten-Authentifizierung ohne eine mögliche Anmeldung in Vertretung betrachtet. 3.1 Allgemeine Architektur Abbildung 1 zeigt die allgemeine Idee und Architektur von MOA-ID in einer Public Cloud. MOA-ID wird also in einer Public Cloud betrieben, eine Migration der Online Applikation ist nicht notwendig. Durch den zentralen Betrieb von MOA-ID in der Public Cloud können alle wesentlichen Vorteile einer Public Cloud (z.b. Skalierbarkeit, geringerer Wartungsaufwand, Verringerung der Kosten) abgeschöpft werden. Abbildung 1 - MOA-ID in der Public Cloud Eine direkte Migration der aktuellen MOA-ID-Umsetzung in eine Public Cloud wäre theoretisch zwar möglich, jedoch würde bei gleichbleibender Implementierung und gleichbleibenden Anmeldeprozess der Public Cloud Provider Zugriff auf persönliche Daten (z.b. Stammzahl) von Bürgerinnen bzw. Bürgern erhalten. Um diesen Umstand zu verhindern und persönliche Daten vor dem Cloud Provider geheim zu halten, wurden im Rahmen dieses Projekts zwei Lösungsmöglichkeiten unter Verwendung unterschiedlicher Technologien erarbeitet, wie ein Anmeldeprozess unter Verwendung von MOA-ID in der Public Cloud vonstattengehen könnte. Im Folgenden werden die zwei unterschiedlichen Lösungsmöglichkeiten bzw. Ansätze vorgestellt. MOA-ID in der Public Cloud 7

8 3.2 Ansatz 1: Verwendung von PRE und RS In dieser Lösungsmöglichkeit wird die Personenbindung so modifiziert, dass sie nicht die Stammzahl der Bürgerin bzw. des Bürgers enthält, sondern bereits alle bereichsspezifischen Personenkennzeichen (bpks) aller staatlichen Tätigkeitsbereiche. Die bpks werden dabei jedoch mit einem PRE-Verfahren verschlüsselt gespeichert, und zwar unter dem öffentlichen Schlüssel von MOA-ID. Der private Schlüssel dazu ist jedoch nicht im Besitz von MOA-ID, sondern von der Stammzahlenregisterbehörde (SRB). Name und Geburtsdatum der Bürgerin bzw. des Bürgers werden ebenso in der Personenbindung verschlüsselt gespeichert. Die Personenbindung mit den verschlüsselten Daten wird wiederum signiert, jedoch mit einer redigierbaren Signatur, sodass bestimmte Daten (z.b. nicht benötigte bpks) bei Bedarf ausgeschwärzt werden können. Der öffentliche Schlüssel zur Signatur-Verifikation ist MOA-ID verfügbar. Zusätzlich muss sich jeder Service Provider (Online Applikation) bei der SRB registrieren, um ein AE-Schlüsselpaar zu erhalten. Dieses dient dann dem Service Provider zum Entschlüsseln der Daten. Zusätzlich erstellt die SRB für MOA-ID ein PRE-Schlüsselpaar, welches es MOA-ID erlaubt, Daten für den jeweiligen Service Provider umzuschlüsseln. Der öffentliche Schlüssel wird MOA-ID zur Verfügung gestellt, jedoch der private bei der SRB geheim gehalten. Der genaue Workflow wird nun beschrieben Vorbedingung Die SRB erstellt für sich ein RS-Schlüsselpaar zum Signieren der jeweiligen modifizierten Personenbindungen. Zusätzlich erstellt sie ein PRE-Schlüsselpaar für MOA-ID, wobei nur der öffentliche Schlüssel an MOA-ID ausgehändigt wird und der private Schlüssel im Besitz der SRB bleibt Bürgerinnen- bzw. Bürgerregistrierung Der Prozess der Registrierung von Bürgerinnen bzw. Bürgern oder die Aktivierung deren Bürgerkarten muss nicht umgestellt werden und kann wie bisher durchgeführt erfolgen. Es wird lediglich eine neue Personenbindung ausgestellt, die neben Name und Geburtsdatum und anstelle der Stammzahl bereits alle bpks für MOA-ID verschlüsselt enthält. Im Vergleich zur aktuellen Situation wird die Personenbindung auch mit einem redigierbaren Signaturverfahren signiert und auf der Bürgerkarte der Bürgerin bzw. des Bürgers gespeichert. Zusätzlich wird ein Schlüsselpaar zum Erstellen von qualifizierten Signaturen auf der Karte gespeichert Service Provider Registrierung Alle Service Provider (SP), die MOA-ID verwenden wollen, müssen sich bei der SRB registrieren. Die SRB erstellt dabei für jeden Service Provider ein AE-Schlüsselpaar und zusätzlich einen PRE-Re-Encryption-Schlüssel von MOA-ID auf den jeweiligen Service MOA-ID in der Public Cloud 8

9 Provider, sodass MOA-ID für sich verschlüsselte Daten auf den Service Provider bei Bedarf umschlüsseln kann. Das AE-Schlüsselpaar wird dabei dem Service Provider und der PRE-Re-Encryption-SchlüsselMOA-ID SP MOA-ID ausgehändigt Identifizierungs- und Authentifizierungsprozess Im Folgenden werden die einzelnen Schritte des Identifizierungs- und Authentifizierungsprozesses gemäß dem Sequenzdiagramm in Abbildung 2 beschrieben. Bürgerin bzw. Bürger BKU MOA-ID Service Provider 1. Zugriff auf Online Applikation 2. Authentifizierungs-Request 2. Authentifizierungs-Request 3. Lese Personenbindung 4. Redigiere bpks 5. Antwort mit redigierter Personenbindung 6. Verifiziere Personenbindung 7. Umschlüsseln des bpk für den Service Provider 8. Erstelle Signatur 9. PIN für Signatur 10. Antwort mit Signatur 11. Verifiziere Signatur 13. Authentifizierungs-Response mit SAML-Assertion 13. Authentifizierungs-Response mit SAML-Assertion 12. Erstelle und signiere SAML-Assertion 15. Erlaube Zugriff auf Online Applikation 14. Verifiziere SAML-Assertion und entschlüssle Attribute Abbildung 2 - Sequenzdiagramm des Identifizierungs- und Authentifizierungsprozesses unter Verwendung von PRE und RS 1. Eine Bürgerin bzw. ein Bürger möchte auf eine Online Applikation eines Service Providers zugreifen. 2. Der Service Provider schickt einen Authentifizierungs-Request an MOA-ID. 3. MOA-ID startet den Identifizierungsprozess, indem es die neue, modifizierte Personenbindung über die Bürgerkartenumgebung auslesen möchte. MOA-ID in der Public Cloud 9

10 4. In der Bürgerkartenumgebung hat die Bürgerin bzw. der Bürger die Möglichkeit, all jene verschlüsselten bpks auszuschwärzen, die nicht für den Identifizierungsprozess beim Service Provider benötigt werden. 5. Diese redigierte Personenbindung wird anschließend an MOA-ID übermittelt. 6. MOA-ID überprüft wie gewohnt die Signatur der Personenbindung. Aufgrund der Verwendung einer redigierbaren Signatur bleibt die Signatur trotz des Ausschwärzens gültig. 7. Üblicherweise wird in diesem Schritt die bpk aus der Stammzahl der Person berechnet. In diesem Ansatz wird jedoch einfach die verschlüsselte bpk aus der Personenbindung für den Service Provider umgeschlüsselt. 8. Die Authentifizierung erfolgt wie gewohnt anhand einer DS-Signatur 2. MOA-ID stellt den entsprechenden Request an die BKU. 9. Die Bürgerin bzw. der Bürger startet durch Eingabe der PIN den Signaturerstellungsprozess. 10. Die erstellte Signatur wird an MOA-ID übermittelt. 11. MOA-ID überprüft die Signatur der Bürgerin bzw. des Bürgers. 12. Sind die Signatur sowohl der Personenbindung als auch der Bürgerin bzw. des Bürgers gültig, erstellt MOA-ID eine SAML 3 -Assertion, die alle notwendigen Attribute der Bürgerin bzw. des Bürgers (von MOA-ID umgeschlüsselt) für den Service Provider enthält. Um die Integrität und Authentizität der SAML-Assertion zu wahren, wird diese von MOA-ID signiert. 13. Die SAML-Assertion wird anschließend in der Authentifizierungs-Antwort an den Service Provider übermittelt. 14. Der Service Provider verifiziert die Signatur der SAML-Assertion und entschlüsselt die Attribute. 15. Basierend auf den Attributen kann der Service Provider der Bürgerin bzw. dem Bürger Zugriff auf die Online Applikation gewähren. 3.3 Ansatz 2: Verwendung von FHE Bei diesem Ansatz enthält die Personenbindung alle Attribute wie bisher (auch die Stammzahl), jedoch ebenfalls nur in für MOA-ID verschlüsselter Form. Dabei ist wiederum nur der öffentliche Schlüssel MOA-ID bekannt und nicht der private Schlüssel, den nur die SRB kennt. Die Personenbindung ist wie bisher mit einem einfachen DS- Verfahren von der SRB signiert. Zur Authentifizierung wird wie gewohnt die Personenbindung an MOA-ID übertragen. Aufgrund der Eigenschaften von FHE ist es möglich, dass quasi aus der verschlüsselten Stammzahl das entsprechende bpk 2 Um hier eine Wiedererkennung der Bürgerin bzw. des Bürgers beim Cloud Provider zu vermeiden, könnte man statt der DS-Signatur auch anonyme Signaturen verwenden. 3 Security Assertion Markup Language, MOA-ID in der Public Cloud 10

11 berechnet werden kann, ohne dass MOA-ID die eigentliche Stammzahl oder das bpk kennenlernt. Dieser Wert wird anschließend wiederum von MOA-ID für den Service Provider umgeschlüsselt Vorbedingung Die SRB erstellt für sich ein RS-Schlüsselpaar zum Signieren der jeweiligen modifizierten Personenbindungen. Zusätzlich erstellt sie ein FHE-Schlüsselpaar für MOA-ID, wobei nur der öffentliche Schlüssel an MOA-ID ausgehändigt wird und der private Schlüssel im Besitz der SRB bleibt Bürgerinnen- bzw. Bürgerregistrierung Der Prozess der Registrierung von Bürgerinnen bzw. Bürgern oder die Aktivierung deren Bürgerkarten muss nicht umgestellt werden. Es wird lediglich eine neue Personenbindung ausgestellt, die neben Name und Geburtsdatum auch die Stammzahl für MOA-ID FHE-verschlüsselt enthält. Wie in der derzeitigen Situation wird die Personenbindung mit einem klassischen DS-Signaturverfahren signiert und auf der Bürgerkarte der Bürgerin bzw. des Bürgers gespeichert. Zusätzlich wird ein Schlüsselpaar zum Erstellen von qualifizierten Signaturen auf der Karte gespeichert Service Provider Registrierung Alle Service Provider (SP), die MOA-ID verwenden wollen, müssen sich bei der SRB registrieren. Die SRB erstellt dabei für jeden Service Provider ein FHE-Schlüsselpaar aus Identifizierungs- und Authentifizierungsprozess Im Folgenden werden die einzelnen Schritte des Identifizierungs- und Authentifizierungsprozesses gemäß dem Sequenzdiagramm in Abbildung 3 beschrieben. 4 Dieser Ansatz setzt ein paar theoretische Annahmen voraus und ist vorerst nicht praktikabel. MOA-ID in der Public Cloud 11

12 Bürgerin bzw. Bürger BKU MOA-ID Service Provider 1. Zugriff auf Online Applikation 2. Authentifizierungs-Request 2. Authentifizierungs-Request 3. Lese Personenbindung 4. Antwort mit Personenbindung 5. Verifiziere Personenbindung 6. Berechnung bpk 7. Erstelle Signatur 8. PIN für Signatur 9. Antwort mit Signatur 10. Verifiziere Signatur 11. Umschlüsseln der Attribute 13. Authentifizierungs-Response mit SAML-Assertion 13. Authentifizierungs-Response mit SAML-Assertion 12. Erstelle und signiere SAML-Assertion 15. Erlaube Zugriff auf Online Applikation 14. Verifiziere SAML-Assertion und entschlüssle Attribute Abbildung 3 - Sequenzdiagramm des Identifizierungs- und Authentifizierungsprozesses unter Verwendung von FHE 1. Eine Bürgerin bzw. ein Bürger möchte auf eine Online Applikation eines Service Providers zugreifen. 2. Der Service Provider schickt einen Authentifizierungs-Request an MOA-ID. 3. MOA-ID startet den Identifizierungsprozess, indem es die neue, modifizierte Personenbindung über die Bürgerkartenumgebung auslesen möchte. 4. Die Personenbindung wird anschließend an MOA-ID übermittelt. 5. MOA-ID überprüft wie gewohnt die Signatur der Personenbindung. 6. MOA-ID berechnet in diesem Schritt das bpk auf Basis der verschlüsselten Stammzahl aus der Personenbindung. 7. Die Authentifizierung erfolgt wie gewohnt anhand einer DS-Signatur 5. MOA-ID stellt den entsprechenden Request an die BKU. 5 Um hier eine Wiedererkennung der Bürgerin bzw. des Bürgers beim Cloud Provider zu vermeiden, könnte man statt der DS-Signatur auch anonyme Signaturen verwenden. MOA-ID in der Public Cloud 12

13 8. Die Bürgerin bzw. der Bürger startet durch Eingabe der PIN den Signaturerstellungsprozess. 9. Die erstellte Signatur wird an MOA-ID übermittelt. 10. MOA-ID überprüft die Signatur der Bürgerin bzw. des Bürgers. 11. MOA-ID schlüsselt alle notwendigen Attribute (inkl. berechnetem bpk) für den Service Provider um. 12. Sind die Signatur sowohl der Personenbindung als auch der Bürgerin bzw. des Bürgers gültig, erstellt MOA-ID eine SAML-Assertion, die alle notwendigen Attribute der Bürgerin bzw. des Bürgers (von MOA-ID umgeschlüsselt) für den Service Provider enthält. Um die Integrität und Authentizität der SAML-Assertion zu wahren, wird diese von MOA-ID signiert. 13. Die SAML-Assertion wird anschließend in der Authentifizierungs-Antwort an den Service Provider übermittelt. 14. Der Service Provider verifiziert die Signatur der SAML-Assertion und entschlüsselt die Attribute. 15. Basierend auf den Attributen kann der Service Provider der Bürgerin bzw. dem Bürger Zugriff auf die Online Applikation gewähren. 3.4 Evaluierung In diesem Abschnitt werden die beiden unterschiedlichen Ansätze für ein Deployment von MOA-ID in einer Public Cloud anhand unterschiedlicher Kriterien evaluiert Wiederverwendung existierenden Infrastruktur Sowohl Ansatz 1 als auch Ansatz 2 benötigt Änderungen in der bestehenden Identitätsmanagement-Infrastruktur. Die SRB erhält zusätzliche Verantwortung, da sich alle Service Provider bei ihr registrieren und entsprechende Schlüsselpaare zum Verund Entschlüsseln generiert werden müssen. In beiden Fällen muss auch die Personenbindung modifiziert werden, indem die Attribute der Bürgerin bzw. des Bürgers durch für MOA-ID verschlüsselte Attribute ausgetauscht werden. Auch das SAML- Protokoll für den Austausch von Daten zwischen MOA-ID und dem Service Provider muss adaptiert werden, die Änderungen sind hier jedoch minimal Konformität mit dem bestehen Prozessablauf Beide Ansätze sind im Wesentlichen vollkommen konform mit dem derzeitigen Identifizierungs- und Authentifizierungsablauf von MOA-ID. D.h. in beiden Fällen erfolgt die Identifizierung über die Personenbindung und ein bpk, und die Authentifizierung über die Erstellung einer qualifizierten Signatur durch die Bürgerin bzw. den Bürger. MOA-ID in der Public Cloud 13

14 3.4.3 Skalierbarkeit Die Skalierbarkeit ist in beiden Fällen gegeben, da MOA-ID in beiden Ansätzen in einer Public Cloud betrieben wird, welche von Haus aus hohe Skalierbarkeit aufweist Praktikabilität Ansatz 1 ist sehr praktikabel ausgelegt, da sowohl PRE und RS bereits effizient implementiert werden können. Ansatz 2 ist hingegen eher von theoretischer Natur, da FHE im Moment noch sehr ineffizient ist und somit noch weitere Forschungsarbeit notwendig ist Erweiterbarkeit Ansatz 1 ist für Erweiterungen nur bedingt geeignet, da bei Hinzufügen eines neuen staatlichen Tätigkeitsbereichs bzw. eines bpks die komplette Personenbindung ausgetauscht werden müsste. Bei Ansatz 2 wären hingegen solche Änderungen nicht notwendig, da ein bpk direkt aus der verschlüsselten Stammzahl berechnet werden kann Änderungen in der BKU Nur in Ansatz 1 muss die Funktionalität der BKU erweitert werden. Alle nicht benötigten bpks müssen hier redigiert werden. Für Ansatz 2 sind keine Änderungen in der BKU notwendig Vertrauen in MOA-ID MOA-ID muss zumindest insofern vertraut werden, dass seine Funktionen korrekt durchgeführt werden. Aus der Sicht des Datenschutzes sieht MOA-ID in beiden Fällen nur verschlüsselte Daten aus der Personenbindung, somit ist dieser in beiden Fällen gewahrt. Wie viele Informationen einer Bürgerin bzw. eines Bürgers MOA-ID mitbekommt, hängt auch von den Informationen ab, die im Zertifikat stehen, welches für die Signaturerstellung zur Authentifizierung verwendet wird. MOA-ID in der Public Cloud 14

15 4 Online Vollmachten-Service in der Public Cloud Dieser Abschnitt beschreibt eine Lösungsmöglichkeit unter Verwendung von DS und AE, wie das Online Vollmachten-Service (MIS) in einer Public Cloud deployed werden könnte. 4.1 Allgemeine Architektur Abbildung 4 zeigt die allgemeine Idee des Deployments des Online Vollmachten- Services in einer Public Cloud. Wie beim Deployment von MOA-ID in einer Public Cloud könnten auch hier alle wesentlichen Vorteile einer Public Cloud ausgenutzt werden. Abbildung 4 - Online Vollmachten-Service in der Public Cloud Auch in diesem Fall wäre ein simples Deployment des aktuellen MIS-Services in der Public Cloud ohne Probleme möglich, jedoch würde der Public Cloud Provider dadurch zu Informationen und Daten kommen, die rechtlich unter besonderem Schutz stehen. Aus diesem Grund wurde im Rahmen dieses Projekts eine Lösungsmöglichkeit entwickelt, wie ein Deployment des MIS in der Public Cloud möglich wäre, ohne dem Public Cloud Provider sensible Daten zu verraten. Im Folgenden wird diese Möglichkeit unter Verwendung von DS und AE vorgestellt. Online Vollmachten-Service in der Public Cloud 15

16 4.2 Verwendung von DS und AE In diesem Ansatz werden die einzelnen Entitäten (MOA-ID, MIS, Register) von der SRB mit entsprechenden DS- und AE-Schlüsselpaaren ausgestattet. Es wird nur das MIS in der Public Cloud betrieben, alle anderen Entitäten (MOA-ID, die einzelnen Register, Online Applikation) müssen nicht in einer Public Cloud betrieben werden. Bei der Beschreibung dieses Ansatzes wird beispielhaft auf den Fall einer bilateralen Vollmacht zurückgegriffen. Für die Verwendung von Vollmachten für juristische Personen sind die Prozesse entsprechend anzupassen Vorbedingung Die SRB erhält wiederum mehr Verantwortung und ist für die Schlüsselpaar-Generierung zuständig. Sie generiert für sich jeweils ein DS- und AE-Schlüsselpaar und jeweils ein Paar für MOA-ID und das bilaterale Vollmachtenregister (BI-VR) Vollmachtregistrierung Die einfachste Möglichkeit, die Registrierung sicher zu gestalten, ist die Verlagerung des Registrierungsprozesses vom MIS in der Cloud zu einer vertrauenswürdigen Entität wie dem bilateralen Vollmachtenregister. Dieser Schritt wird auch in diesem Ansatz vollzogen, somit kann der Registrierungsprozess komplett ident zur bestehenden Lösung gehalten werden Vollmachtverwendung Im Folgenden werden die einzelnen und adaptierten Schritte bei Vollmachtverwendung eines MIS in der Cloud gemäß dem Sequenzdiagramm in Abbildung 5 beschrieben. Online Vollmachten-Service in der Public Cloud 16

17 Vertreterin bzw. Vertreter Online Applikation MOA-ID MIS BI-VR SRB 1. Anmeldung in Vertretung 2. Authentifizierung mittels Bürgerkarte 3. Welche Art von Person soll vertreten werden? 3. Natürliche Person 4. Berechnung bpk 5. Signiere bpk + Attribute 6. Signiere und verschlüssle Daten 7. Signierte + verschlüsselte Daten 8. Suche von Vollmachtsinformationen 9. Suche von Vollmachtsinformationen 10. Retourniere registrierte Vollmachten 11. Verfügbare Vollmachten 12. Auswahl der Vollmacht 13. Hole Information des Vertrenen 14. Retourniere Information des Vertretenen 15. Hole Stammzahl des Vertretenen 16. Retourniere Stammzahl des Vertretenen 17. Erstelle Vollmacht 18. Retourniere Vollmacht 19. Retourniere Vollmacht 20. Retourniere Vollmacht 21. Erlaube Zugriff auf Online Applikation Abbildung 5 - Sequenzdiagramm des Identifizierungs- und Authentifizierungsprozesses in Vertretung unter Verwendung von DS und AE 1. Eine Bürgerin bzw. ein Bürger möchte sich in Vertretung bei einer Online Applikation anmelden. 2. Die Bürgerin bzw. der Bürger meldet sich wie bisher bei MOA-ID mit ihrer bzw. seiner Bürgerkarte an. 3. MOA-ID fragt bereits jetzt die Bürgerin bzw. den Bürger, ob sie bzw. er eine natürliche oder juristische Person vertreten möchte. Diese Abfrage dient zur Berechnung des entsprechenden bpks für das jeweilige Register. In diesem Fall wird davon ausgegangen, dass die Bürgerin bzw. der Bürger eine natürliche Person vertreten möchte. Online Vollmachten-Service in der Public Cloud 17

18 4. MOA-ID berechnet deshalb aus der Stammzahl das bpk für das BI-VR, die Stammzahl muss deshalb nicht an das MIS in der Cloud übertragen werden. 5. MOA-ID schickt das berechnete bpk, die persönlichen Attribute, sowie einen Identifikator von MOA-ID zur Bürgerin bzw. zum Bürger zum Signieren und Verschlüsseln. 6. Die Bürgerin bzw. der Bürger signiert die Daten mit ihrem bzw. seinem privaten Schlüssel und verschlüsselt diese anschließend mit dem öffentlichen Schlüssel des BI-VR Die Bürgerin bzw. der Bürger retourniert die signierten und verschlüsselten Daten zu MOA-ID. 8. MOA-ID übermittelt diese Daten dem MIS zur Suche von Vollmachtsinformationen. 9. Das MIS transferiert die Daten weiter an das BI-VR. Das BI-VR entschlüsselt die für sich verschlüsselten Daten und überprüft die Signatur der Bürgerin bzw. des Bürgers. Bei Gültigkeit wird anhand der entschlüsselten bpk nach Vollmachtinformationen zur Bürgerin bzw. zum Bürger gesucht. 10. Das BI-VR signiert und verschlüsselt alle zur Bürgerin bzw. zum Bürger verfügbaren Vollmachten aus dem Register. Die Verschlüsselung erfolgt dabei für die Bürgerin bzw. den Bürger. Die signierten und verschlüsselten Vollmachten werden zum MIS übertragen. 11. Das MIS leitet die signierten und verschlüsselten Vollmachten zur Bürgerin bzw. zum Bürger weiter. Die Bürgerin bzw. der Bürger überprüft die Signatur und entschlüsselt die Daten. 12. Die Bürgerin bzw. der Bürger wählt die gewünschte Vollmacht aus. Sie bzw. er extrahiert dabei Name und Geburtsdatum des Vertretenen. Danach werden von ihr bzw. ihm zwei Signaturen erstellt. Einerseits die ID zur ausgewählten Vollmacht und andererseits Name und Geburtsdatum des Vertretenen. Diese beiden signierten Daten werden anschließend für das BI-VR verschlüsselt und an das MIS übertragen. 13. Die zuvor verschlüsselten Daten werden von MIS an das BI-VR weitergeleitet. 14. Das BI-VR entschlüsselt die Daten und verifiziert deren Signatur. Das BI-VR weiß nun anhand der gewählten Vollmacht-ID, welche Vollmacht die Bürgerin bzw. der Bürger ausgewählt hat. Das BI-VR verschlüsselt anschließend den signierten Namen und Geburtsdatum des Vertretenen und dessen bpk für die Stammzahlenregisterbehörde (SRB). Diese Daten werden anschließend an das MIS übermittelt. 15. Das MIS leitet diese Daten an die SRB weiter. 6 Es wird davon ausgegangen, dass der öffentliche Schlüssel des BI-VR der Bürgerin bzw. dem Bürger zur Verfügung steht. Online Vollmachten-Service in der Public Cloud 18

19 16. Die SRB entschlüsselt die Daten, verifiziert deren Signatur und erstellt auf Basis der Daten des Vertretenen (Name, Geburtsdatum, bpk) dessen Stammzahl. 17. Die Stammzahl des Vertretenen wird signiert, für das BI-VR verschlüsselt, und an das MIS übermittelt. 18. Das MIS übermittelt die signierte und verschlüsselte Stammzahl an das BI-VR. Das BI-VR entschlüsselt diese und überprüft deren Signatur. Das BI-VR hat nun alle Daten um eine elektronische Vollmacht zu erstellen. Das BI-VR signiert diese Daten und verschlüsselt die vollständige Vollmacht für MOA-ID (auf Basis des in Schritt 5 übermittelten Identifikators von MOA-ID). Diese Daten werden wiederum an das MIS übermittelt. 19. Das MIS übermittelt die erhaltenen Daten weiter an MOA-ID. MOA-ID entschlüsselt die Vollmachtsdaten und überprüft deren Signatur. Die überprüften Daten werden in eine SAML-Assertion verpackt und an die Online Applikation übermittelt. 20. Basierend auf diesen Daten kann dem Vertreter im Namen des Vertretenen Zugriff auf die Online Applikation gewährt werden Audit einer Vollmachtverwendung Nachdem das MIS ausschließlich verschlüsselte Daten zu Gesicht bekommt, muss der Audit-Prozess, so wie der Vollmachten-Registrierungsprozess, zu einer vertrauenswürdigen Entität ausgelagert werden. In diesem Fall wird das Logging für Audit-Zwecke vom BI-VR übernommen. 4.3 Evaluierung In diesem Abschnitt wird der dargestellte Ansatz für ein Deployment des MIS in der Public Cloud anhand unterschiedlicher Kriterien evaluiert Wiederverwendung existierender Infrastruktur Bei Verwendung dieses Ansatzes können wesentliche Teile der österreichischen Infrastruktur wiederverwendet werden. So kann das sektor-spezifische Modell mit den bpks beibehalten werden. Es ist auch nicht notwendig, neue Bürgerkarten auszurollen, da die derzeitigen Implementierungen bereits über eine Signatur- und Verschlüsselungsfunktion verfügen 7. Um dieses vorgestellte Protokoll jedoch vollständig zu unterstützen, müssen natürlich Änderungen zur Unterstützung der kryptographischen Technologien bei den involvierten Komponenten (MOA-ID, BI-VR, etc.) durchgeführt werden. 7 Die derzeitige Implementierung der Handy-Signatur müsste jedoch noch um eine Verschlüsselungsfunktion erweitert werden Online Vollmachten-Service in der Public Cloud 19

20 4.3.2 Konformität zum aktuellen Prozessfluss Beim Prozessfluss wurden nur minimale Änderungen vorgenommen. So wurden für das Abholen der Vollmacht (siehe Schritte 13 und 17) zwei zusätzliche Prozessschritte eingeführt. Diese zusätzlichen Prozessschritte können bei Bedarf jedoch eingespart werden, und der Prozessfluss wieder an die ursprüngliche und derzeitige Schrittfolge angepasst werden. In diesem Fall kann die elektronische Vollmacht jedoch nicht als ein ganzes signiertes Datenpaket an MOA-ID übertragen werden, sondern müsste aus mehreren getrennten signierten Paketen bestehen Skalierbarkeit Die Skalierbarkeit ist im Wesentlichen durch die Migration des MIS in die Public Cloud gegeben. Nachdem jedoch trotzdem Komponenten angesprochen werden, die nicht in die Cloud migriert werden, kann es bei diesen Komponenten eventuell zu Lastengpässen kommen. Eine Migration dieser Komponenten in eine Private Cloud könnte jedoch diese Problematik etwas abschwächen Praktikabilität Der vorgestellte Ansatz ist praktikabel, da sowohl DS und AE effizient implementiert werden können. Diese beiden kryptographischen Methoden werden auch bereits von der Bürgerkarte unterstützt Erweiterbarkeit Das vorgestellte System ist im Wesentlichen einfach erweiterbar, da bei den meisten Komponenten nur einfache kryptographische Methoden (Signatur und Verschlüsselung) implementiert werden müssten. So ist es auch einfach möglich, zusätzliche Register, die ebenfalls Vollmachtsdaten abbilden, in das System zu integrieren Änderungen in der BKU Von der Basis-Funktionalität her sind in der BKU keine großen Änderungen notwendig, da Signatur- und Verschlüsselungsfunktionen (zumindest bei der Bürgerkarten- Implementierung als Chipkarte) bereits standardmäßig vorhanden sind. Es muss jedoch über eine Möglichkeit zur Anzeige von Vollmachtsdaten und zur Auswahl der Vollmacht nachgedacht werden Vertrauen in das MIS Dem MIS in der Public Cloud muss nur insofern vertraut werden, dass die Prozessschritte korrekt abgearbeitet werden. Da dem MIS immer nur verschlüsselte Daten zur Verarbeitung übergeben werden, besteht auch keine Gefahr, dass der notwendige Datenschutz für Bürgerinnen oder Bürger in irgendeiner Weise verletzt werden könnte. Online Vollmachten-Service in der Public Cloud 20

21 5 Zusammenfassung und Fazit Cloud Computing hat sehr viele Vorteile wie hohe Skalierbarkeit, geringerer Wartungsaufwand, oder Kostenvorteile. Besonders das von Cloud Providern verwendete Pay as you go -Abrechnungsmodell ermöglicht enormes Kosteneinsparungspotential, wodurch es auch für die öffentliche Verwaltung von Interesse ist. Eine Public Cloud hat hier im Vergleich zu einer Private Cloud einen noch größeren Kosteneinsparungsfaktor, man hat jedoch geringen Einfluss über den Verbleib bzw. die Verarbeitung von Daten. Im Rahmen dieses Projekts wurde untersucht, inwiefern E-Government Kernkomponenten in eine Public Cloud migriert werden können, um einerseits das volle Kosteneinsparungspotential einer Public Cloud ausschöpfen, und andererseits trotzdem ein sicheres Speichern bzw. Verarbeiten der Daten gewährleisten zu können. Konkret wurden Vorschläge skizziert, wie MOA-ID bzw. das Online Vollmachte-Service in eine Public Cloud migriert werden können. Dabei wurden unterschiedliche kryptographische Technologien eingesetzt (z.b. Redigierbare Signaturen, Proxy Re- Encryption, etc.). Das Projekt hat gezeigt, das prinzipiell eine Migration dieser Komponenten in eine Public Cloud möglich ist, ohne dass sensible Daten von Bürgerinnen bzw. Bürgern dem Cloud Provider offengelegt gegeben werden müssen. Um diese Möglichkeiten zu realisieren, müssten jedoch einige Änderungen in der bestehenden Infrastruktur vorgenommen werden (z.b. Änderung der Struktur der Personenbindung), was für einen zukünftigen praktikablen Einsatz vermutlich noch einer genaueren Analyse und strategischen Abstimmung bedarf. Zusammenfassung und Fazit 21

22 Dokumentenhistorie Version Datum Autor(en) Anmerkung Bernd Zwattendorfer Bernd Zwattendorfer Bernd Zwattendorfer Bernd Zwattendorfer Bernd Zwattendorfer Dokumenterstellung Kapitel 2 Kapitel 3 Kapitel 4 Finaler Draft Arne Tauber Kommentare Bernd Zwattendorfer Finale Version Zusammenfassung und Fazit 22

23 Referenzen [ACM+05] G. Ateniese, D.H. Chou, B. de Medeiros, G. Tsudik: Sanitizable Signatures, ESORICS 2005, 2005, vol. 3679, pp [Gent09] C. Gentry: Fully Homomorphic Encryption using Ideal Lattices, 2009, ACM STOC 2009, pp [GrAt07] M. Green, G Ateniese: Identity-Based Proxy Re-encryption, 2007, ACNS 2007, vol. 4521, pp [HaYa10] Rolf Harms und Michael Yamartino: The Economics of the Cloud for the EU Public Sector, 2010, onomics_a4.pdf [JMS+02] R. Johnson, D. Molnar, D.X. Song, D. Wagner: Homomorphic Signature Schemes. CT-RSA '02, 2002, vol. 2271, pp [RiShAd78] R. L. Rivest, A. Shamir, und L. Adleman: A method for obtaining digital signatures and public-key cryptosystems, 1978, Commun. ACM 21, 2, [Simm79] Gustavus J. Simmons: Symmetric and Asymmetric Encryption, 1979, ACM Comput. Surv. 11, 4 [ZiLe12] Dimitrios Zissis und Dimitrios Lekkas: Addressing cloud computing security issues, 2012, Future Generation Computer Systems, 28(3), Zusammenfassung und Fazit 23