I D E E N S K I Z Z E REDS. secure data. Torben Haase & Annika Schulz

Transkript

1 I D E E N S K I Z Z E REDS secure data Torben Haase & Annika Schulz Stand:

2

3 Inhalt 1 Abstract Einführung Problem Anforderungen Lösungsskizze Stand der Technik REDS Grundlagen Terminologie Kommunikation Konzepte Informationsverteilung Anwendungsszenarien Persönlicher Pod Externe Pods Stand der Entwicklung Konzept Referenzimplementierungen REDS Framework Geschäftsmodell Open-Source Dual-Licensing Zielgruppe Personen Torben Haase Annika Schulz Referenzen... 14

4

5 1 Abstract Das in diesem Dokument beschriebene Konzept ermöglicht die Implementierung einer Webapp, bei dem der Dienstbetreiber den Datenzugriff kontrollieren kann ohne selbst Zugriff auf die Daten der Nutzer zu haben. Dies erlaubt die Nutzung einer Webapp ohne ein Vertrauensverhältnis mit den Anbieter eingehen zu müssen und unterbindet effektiv die Datenakkumulation durch einzelne App-Anbieter. Möglich wird dies durch das Speichern der Daten im Kontrollbereich des Nutzers und die Verschlüsselung der Informationen, solange sich diese im Zugriffsbereich des App-Anbieters befinden. Zu diesem Zweck wird das übliche Client-Server Modell in die drei unabhängigen Komponenten Pod (Daten-Server, Speicher), Node (App-Server, Zugriffskontrolle) und Leaf (App-Client, Website) aufgebrochen, von denen zur Laufzeit nur der Node durch den App-Anbieter kontrolliert wird. In diesem Dokument werden die für die Kommunikation zwischen den Komponenten notwendigen Schnittstellen auf Basis von JavaScript/JSON und HTTP/REST definiert und konkrete Anwendungsfälle beschrieben. 2 Einführung 2.1 Problem Als 1962 am MIT mit der Entwicklung des ARPANET, dem Vorläufer des heutigen Internets, begonnen wurde, war eine der zentralen Eigenschaften dieses neuartigen Netzwerkes seine dezentrale Organisationsstruktur. Im Zuge des Web 2.0 hat sich das Internet jedoch immer mehr von einem Präsentations- zu einem Dienstleistungsnetzwerk entwickelt, in dem Informationen nicht nur an die Websitebesucher ausgeliefert, sondern von diesen auch aktiv generiert werden. Generell sammeln alle cloudbasierten Anwendungen (auch Cloud-Apps oder kurz Apps ) Daten ihrer Nutzer an einer zentralen Stelle unter der Kontrolle des App-Anbieters. 1 Diese Akkumulation von Daten ist für die Nutzer einer Clioudanwendung in zweierlei Hinsicht problematisch: 1.) Die dezentrale Struktur des Internets fördert die Unabhängigkeit des Netzes, da keine zentrale Stelle existiert, welche den Zugriff auf Informationen kontrollieren könnte. Da heutzutage jedoch ein Großteil der vorhandenen Informationen unter der Kontrolle einzelner App-Anbieter stehen, können diese die Verbreitung von Informationen steuern und gegebenenfalls sogar unterbinden. Dabei muss die Zensur nicht zwangsläufig aus Eigeninteresse erfolgen, sondern kann auch durch externen Druck erzwungen werden. 2 2.) Die Anbieter einer Cloudanwendung haben vollen Zugriff auf alle Informationen, die in der Anwendung verarbeitet werden. Nutzer müssen also dem Anbieter vertrauen, dass dieser in Ihrem Sinne mit ihren Daten umgeht. Dieses Vertrauen ist jedoch nicht immer angebracht, da nicht nur der Anbieter sondern auch Dritte Nutzerdaten lesen können, sobald diese sich einmal Zugriff auf die Datenspeicher des Anbieters verschafft haben. 3 Für App-Anbieter hat eine zentrale Datenspeicherung hingegen eine Reihe von Vorteilen. In erster Linie ist hier natürlich die vergleichsweise einfache Implementierung zu nennen, aber gerade für kostenpflichtige Dienste ist es außerdem essentiell, dass sie den Zugriff auf die Daten kontrollieren können. Nachteile, wie die zusätzlichen Kosten durch die Bereitstellung der Speicherinfrastruktur und die potentielle Fehleranfälligkeit einer zentralen Organisationsstruktur, werden dabei durch die Notwendigkeit der Zugriffskontrolle aufgewogen. 1

6 Zusammengefasst lässt sich sagen, dass das derzeit vorherrschende Konzept der zentralen Datenspeicherung eine Reihe von Problemen beinhaltet. Insbesondere ist hier der volle Informationszugriff des Anbieters und der damit einhergehende Kontrollverlust des Benutzers zu nennen. Diese Schwächen können durch eine dezentrale Datenspeicherung in Verbindung mit einer entsprechenden Verschlüsselung umgangen werden. 2.2 Anforderungen Aus den oben skizzierten Problemen bei der Verarbeitung von Daten in der Cloud ergeben sich eine Reihe von Anforderungen an mögliche Lösungsansätze. Der Fokus liegt dabei vor Allem auf dem Schutz der Informationen vor fremdem Zugriff. Insbesondere darf der App-Anbieter zu keinem Zeitpunkt Zugriff die Nutzerdaten haben. Dies umfasst neben dem Schutz der Inhalte auch Abwehrmaßnahmen gegen Datenmanipulation. Des weiteren sollte es Nutzern der Anwendung möglich sein, diese anonym zu verwenden. Trotz dieser Sicherheitsanforderungen darf die Handhabung für den Nutzer jedoch nicht komplizierter als die einer herkömmlichen App sein. Vor allem sollte die Verschlüsselung des Datenverkehrs keine Aktionen auf Nutzerseite erfordern, da die Mehrheit der Nutzer mit derartigen Konzepten nicht vertraut ist und den Mehraufwand scheut. 4 Auf der anderen Seite muss der Anbieter einer Anwendung die Möglichkeit besitzen eine Zugriffskontrolle auszuüben, um beispielsweise Dienste auf Basis eines monatlichen Abonnements anbieten zu können. Dazu gehört insbesondere der Schutz vor der unerlaubten Verwendung von Nutzerdaten in anderen Anwendungen. Konkrete Implementationen sollten sich auf offene und anerkannte Standards stützen und Datenstrukturen verwenden, die sowohl von Mensch als auch von Maschine lesbar sind. Des Weiteren sollten sie als Open- Source umgesetzt werden. Dies ist dabei nicht nur ein kosmetischer Aspekt, sondern verbessert essentiell die Sicherheit der Implementierung, da diese so durch unabhängige Dritte überprüft werden kann, wodurch Fehler schneller gefunden werden und das Vertrauen in die Implementierung insgesamt gesteigert wird. Trotzdem sollte es App-Anbietern möglich sein, für die Sicherheit irrelevante Teile des Quellcodes unter Verschluss zu halten, um ihr geistiges Eigentum schützen zu können. Diese Prinzip widerspricht zwar der angestrebten Offenheit der Lösung, ist jedoch essentiell für die breite Akzeptanz über die Open-Source- Community hinaus. 2.3 Lösungsskizze Die derzeit dominierende Ansicht ist, dass sich der Wert eines Dienstes vor allem über die von ihm angesammelten Daten definiert. Der Wert eines Dienstes erschließt sich jedoch in den meisten Fällen nicht aus den Informationen in den Daten, sondern vielmehr aus den Relationen zwischen den einzelnen Datensätzen, der Präsentation der Informationen auf der Website und aus den Verknüpfungen zwischen seinen Benutzern. Herkömmliche Cloudanwendungen verarbeiten viele Informationen auf dem App-Server im Kontrollbereich des Anbieters, wohingegen der App-Client (z.b. die Website im Browser des Nutzers) nur die Visualisierung der Daten übernimmt. Da Informationen jedoch nur auf Clientseite verfügbar sein sollen, ist ein Bruch mit dem Thin-Client/Fat-Server Dogma notwendig, an dessen Stelle eine Fat-Client/Thin-Server Architektur treten muss. Der App-Server stellt hierbei nur die Daten zur Verfügung, welche dann vom App-Client bearbeitet werden. 2

7 Des Weiteren ist es notwendig, dass die Daten zwar verschlüsselt übertragen aber unverschlüsselt gespeichert werden. Denn nur so ist es möglich die angefragten Datensätze nach bestimmten Gesichtspunkten zu filtern (z.b. alle Adressen mit einem bestimmten Nachnamen). Da die unverschlüsselte Speicherung der Daten auf dem App-Server, also unter der Kontrolle des Anbieters, keine Option ist, müssen die Daten auf einem Daten-Server im Zugriffsbereich des Nutzers gespeichert werden. Daraus ergibt sich folgendes Szenario: Auf Seiten des Anbieters werden nur die Relationen zwischen verschiedenen Datensätzen gespeichert, wohingegen die Inhalte der Datensätze auf einem Daten-Server auf Nutzerseite gespeichert werden. Um einen Datensatz zu bearbeiten sendet der App-Client eine verschlüsselte und signierte Anfrage an den App-Server. Dieser überprüft die Zugriffsrechte und leitet die Anfrage an den entsprechenden Daten-Server weiter. Auf dem Daten Server werden erneut die Zugriffsrechte überprüft, die Anfrage ausgeführt und die verschlüsselte und signierte Antwort über den App-Server zurück an den App-Client gesendet. Dort wird die Signatur geprüft sowie der Datensatz entschlüsselt und weiterverarbeitet. Der App-Server ist demnach als zentraler Knotenpunkt unverzichtbar. Der Anbieter behält so die Kontrolle über die Zugriffsrechte und die Relationen, wohingegen der Nutzer die Inhalte auf dem Daten-Server kontrolliert. Da der Datentransfer zwischen App-Client und Daten-Server verschlüsselt geschieht, kann dem Anbieter der Zugriff auf die Informationen völlig verwehrt werden. Der Nutzer muss also nur dem Besitzer des Daten-Servers, der er im Idealfall selbst ist, vertrauen, um die durch den Anbieter bereitgestellte Anwendung nutzen zu können. 2.4 Stand der Technik Derzeit ist den Entwicklern von REDS kein System bekannt, welches die im vorherigen Kapitel beschriebenen Anforderungen erfüllt. Dennoch gibt es auch jetzt schon einige Entwicklungen, welche zumindest einen Teil der Anforderungen umsetzen. Drei dieser Technologien, welche jeweils exemplarisch für eine größere Gruppe ähnlicher Lösungen stehen, sollen hier im Einzelnen kurz erläutert werden Lokaler Cloud-Speicher: owncloud owncloud a ist eine open-source Software, die Dienste zur Datensynchronisation und zum gemeinsamen Verwenden von Daten bereitstellt. owncloud wurde in PHP und JavaScript geschrieben und muss daher auf einem eigenen Webserver installiert werden. Neben den typischen Diensten wie Kalender, Addressbuch und File-Sharing können weitere Funktionen durch Apps von externen Entwicklern ergänzt werden. Lokale Cloud-Lösungen wie owncloud lösen zwar das Datenschutzproblem, da die Kontrolle über die Daten im Bereich des Nutzers liegt, allerdings setzt die Administration einer lokalen Cloud Fachwissen voraus, das bei den meisten Nutzern nicht vorhanden ist. Zudem verliert der App-Anbieter nicht nur die Kontrolle über die Informationen, sondern auch über die Zugriffsrechte. Freemium-Dienste oder monatliche Abos sind bei Apps in der lokalen Cloud also nicht möglich Verteilte soziale Netzwerke: Friendica Red Matrix Friendica b ist ein verteiltes soziales Netzwerk, bei dem sich mehrere unabhängige Knotenpunkte zu einem sozialen Netzwerk verbinden. Grundsätzlich kann dabei jeder einen Knotenpunkt auf seinem eigenen Webserver aufsetzen und so die Kontrolle über seine Daten behalten. Die Red Matrix stellt die nächste a b 3

8 Entwicklungsstufe von Friendica dar. Sie ist jedoch in ihrer grundlegenden Struktur völlig anders als REDS, da Programm und Daten hier nicht getrennt werden. Aufgrund der verteilten Struktur stellen die gleichen Probleme wie bei lokalen Cloud Lösungen: Webapp- Anbieter geben nicht nur die Daten, sondern die gesamte Anwendung in die Kontrolle der Nutzer und die Nutzer müssten die Anwendung wiederum erst auf ihrem eigenen Server installieren Verschlüsselter Cloud-Speicher: SpiderOak Crypton Crypton a ist ein Framework für die Entwicklung von Zero-Knowledge Anwendungen, welches von SpiderOak b, einem der größten Anbieter für verschlüsselten CloudSpeicher, entwickelt wurde. Cypton stellt im Kern eine Objekt-Datenbak dar, deren Daten-Objekte verschlüsselt gespeichert werden c. Mit diesem Prinzip kommt Cypton von allen vorgestellten Ansätzen am nächsten an das REDS-Konzept heran. Allerdings werden die Daten bei Crypton zentral gespeichert, so dass der Anbieter weiterhin die Speicher- Infrastruktur bereitstellen muss und der Nutzer seine Daten im Falle eines permanenten Serverausfalls nicht mehr rekonstruieren kann. Des Weiteren liegen die Daten nur in verschlüsselten Containern vor, welche erst komplett auf den App-Client übertragen werden müssen, bevor mit ihnen gearbeitet werden kann. Außerdem können serverseitig keine Anbindungen an andere Dienste geschaffen werden. 3 REDS Grundlagen REDS ist eine Implementierung der in Abschnitt 2.2 skizzierten Lösung. REDS steht dabei für Remotely Encrypted Distributed Storage und spiegelt so die zentralen Aspekte des vorgestellten Lösungsansatzes wider. Da REDS in erster Linie für die Verwendung mit Webapps entwickelt wurde, wird im Folgenden vor allem dieses Szenario berücksichtigt. Das zugrundeliegende Konzept kann aber ausdrücklich auch auf andere Software-Anwendungen mit einer Client-Server Organisation übertragen werden. a b c

9 3.1 Terminologie Leaf, Node & Pod Webserver Node Programmcode H N Relationen Bereitstellung Datenaustausch Anbieter Nutzer Leaf L Ausführung Visualisierung Informationen P Pod Die obige Abbildung gibt eine Gesamtübersicht über die Struktur von REDS. Der Webserver ist kein direkter Teil von REDS, sondern wird nur bei Webapps für die Bereitstellung des Programmcodes gebraucht. Wie bereits in der Lösungsskizze beschrieben, verteilt sich auch REDS auf drei Komponenten: Leaf: Der Anwendung mit dem der Nutzer aktuell arbeitet. Bei Webapps ist dies in der Regel der Browser, mit dem die URL App geöffnet wurde. Allgemeiner ist der Leaf das Programm, welches auf Nutzerseite ausgeführt wird. Die Ausführung des App-Clients erfolgt im Kontrollbereich des Nutzers. Der Nutzer ist nicht an einen bestimmten Leaf gebunden und kann auch mit mehreren Leafs gleichzeitig angemeldet sein (z.b. Desktop-Browser und Smartphone). Node: Der App-Server, welcher Anfragen des Leafs entgegen nimmt. Zur jeder App gehört immer genau ein Node, der als zentrales Verzeichnis für die Accounts, Domains und Entities dient und die Zugriffskontrolle übernimmt. In der Regel werden die Leaf-Anfragen vom Node an den Pod weitergeleitet., um dort weiterverarbeitet zu werden. Der Node befindet sich komplett in der Kontrolle des App-Anbieters. Pod: Der Daten-Server. Der Pod empfängt über den Node die Anfragen des Leaf und speichert die Inhalte der Datensätze. Ein Nutzer kann mehrere Pods nutzen, um dort verschiedene Datensätze zu speichern. Der Pod befindet sich komplett in der Kontrolle des Nutzers oder eines vertrauenswürdigen Dritten Account, Domain, Entity & Ticket Neben den bereits beschriebenen Komponenten werden bei REDS noch folgende Begriffe verwendet: Account: Zu jedem User gehört genau ein Account. Dieser dient zum Einen zur Zugriffskontrolle durch den Node und zum Anderen zur Speicherung von permanenten Nutzerdaten auf einem Pod. Für die Authentifizierung werden auf dem Node nur die anonyme Account-ID, der Authentifizierungsschlüssel und einige Salt-Werte gespeichert. Alle weiteren Accountdaten werden 5

10 auf einem vom Nutzer gewählten Pod gespeichert. Die Accountdaten auf dem Pod werden im Allgemeinen verschlüsselt gespeichert und sind daher nur für den Nutzer selbst zugänglich. Domain: Datensätze werden in Domains gruppiert, über welche die Zugriffsrechte definiert werden. Eine Domain hat eine nodeweit eindeutige ID und gehört immer zu genau einem Pod. Daher befinden sich alle Datensätze einer Domain auf dem gleichen Pod. Auf dem Node wird in der Regel nur die ID gespeichert, die eigentlichen Informationen befinden sich auf dem Pod. Die Daten auf dem Pod werden in der Standardimplemetierung unverschlüsselt gespeichert. Es ist jedoch auch möglich Daten verschlüsselt auf dem Pod zu speichern. Entity: Ein einzelner Datensatz innerhalb einer Domain wird als Entity bezeichnet. Jede Entity gehört einem bestimmten Typ an und hat eine ID. Die Kombination Typ+ID ist nodeweit eindeutig. Abgesehen von Typ und ID werden alle Entitydaten wird immer auf dem Pod der überordneten Domain gespeichert, also nicht über mehrere Pods verteilt. Es können Eltern-Kind-Relationen zwischen Entities geknüpft werden, um diese so in einer Graphenstruktur zu organisieren. Relationen zwischen Entities werden auf dem Node gespeichert. Ticket: Zugriffsrechte auf eine Domain werden über Tickets definiert. Rechte können nur domainweit und nicht für einzelne Enitites vergeben werden. Einer Domain können mehrere Tickets zugeordnet werden, wobei jeder Nutzer ein eigenes Ticket mit einer domainweit eindeutigen ID besitzt. 3.2 Kommunikation Die folgenden Diagramme stellen eine High-Level-Beschreibung der Kommunikation zwischen den verschiedenen REDS-Komponenten dar. Auf Details der Verschlüsselung und Authentifizierung wird bewusst verzichtet, um den allgemeinen Ablauf besser verdeutlichen zu können. Stellt Programmcode bereit Webserver H Node N HTML, CSS, JS, etc. Leaf L Führt Programmcode aus P Pod Bei Webapps fordert der Browser zunächst den Programmcode für den Leaf beim Webserver des Anbieters an. Bei anderen Anwendungen befindet sich der Leaf-Programmcode in der Regel bereits auf dem Endgerät des Nutzers. Sobald der Code verfügbar ist, kann der Leaf-Programmcode ausgeführt werden und die Kommunikation mit dem Node beginnen. 6

11 Node N Selektiert Datensätze Prüft Zugriffsrechte signiert Request sendet Request Weiterleitung an Pod verschlüsselt Request entschlüsselt Request Leaf L Führt Programmcode aus P Pod Sobald der Leaf Daten auf einer Domain benötigt, wird eine Anfrage formuliert, verschlüsselt, signiert und an den Node gesendet. Signatur und Verschlüsselung erfolgen dabei mit dem entsprechenden Ticketschlüssel für die Domain. Außerdem kann die Anfrage zusätzlich noch mit dem Account- Authentifizierungsschlüssel signiert werden um eine zusätzliche Zugriffskontrolle auf dem Node zu ermöglichen. Der Node prüft gegebenenfalls die Zugriffsrechte und entfernt die Accountsignatur. Anhand der Domain- ID kann der Node dann den Ziel-Pod ermitteln, die Anfrage mit dem entsprechenden Node- Authentifizierungsschlüssel signieren und dann an den Pod der Domain weiterleiten. Node N Sammelt Responses Weiterleitung an Browser sendet Response entschlüsselt Response verschüsselt Response Leaf L Verarbeitet Daten Prüft Signatur Bearbeitet Anfrage P Pod Der Pod prüft zunächst die Nodesignatur, um sicherzustellen, dass eine gültige Anfrage vorliegt, und überprüft dann die Ticketsignatur und -zugriffsrechte. Ist dies erfolgreich wird die Anfrage entschlüsselt und verarbeitet. Nachdem dies abgeschlossen ist, wird die Antwort mit dem Ticketschlüssel verschlüsselt und signiert. Vor dem Versand an den Node wird diese außerdem mit dem Node- Authentifizierungsschlüssel signiert. 7

12 Der Node prüft die Signatur und leitet die Antwort an den Leaf weiter. Nach der erfolgreichen Überprüfung der Ticketsignatur wird die Antwort entschlüsselt und kann dann in der Anwendung weiterverarbeitet werden. Gegebenenfalls können nun weitere Anfragen gesendet werden. 3.3 Konzepte Unverschlüsselter Pod Anders als bei anderen verschlüsselten Cloud-Speichern werden die Informationen bei REDS auf dem Pod unverschlüsselt gespeichert. Nur der Austausch der Informationen zwischen Pod und Leaf erfolgt verschlüsselt. Dies stellt jedoch kein Nachteil dar, da der Pod sowieso im Kontrollbereich des Nutzer liegt, sondern bietet sogar einen entscheidenden Vorteil: Da die Daten auf dem Pod im Klartext vorliegen, können Entities auch nach ihrem Inhalt gefiltert werden. Nehme man zum Beispiel die Anfrage Alle Adressen mit dem Vornamen Torben : Wären die Entities auf dem Pod verschlüsselt, müssten zunächst alle zum Leaf übertragen, dort entschlüsselt und dann die relevanten Adressen herausgefiltert werden. Da die Entities jedoch unverschlüsselt sind, können die relevanten Adressen bereits auf dem Pod selektiert werden, so dass deutlich weniger Daten übertragen werden müssen. Um jedoch auch weniger sichere Speicherplätze, zum Beispiel Webserver von einem Drittanbieter, für REDS nutzen zu können, biete REDs außerdem die Möglichkeit, Daten verschlüsselt auf dem Pod zu Speichern. Die geht jedoch, wie zuvor beschrieben, mit einer Einschränkung des Funktionsumfangs einher Programm & Daten Der Programmcode einer Web-Anwendung, die REDS implementiert, darf keine nutzerspezifischen Informationen enthalten. HTML und CSS definieren also nur die Struktur und Optik der App. Teile des DOM-Tree, welche aus Nutzerdaten aufgebaut werden sollen, werden nur in ihrer logischen Struktur ohne konkrete Inhalte beschrieben. Die fehlenden Inhalte werden später per JavaScript (AJAX) vom Node angefordert und in den DOM-Tree eingefügt. Aus Model-View-Controller Sicht beschreibt der DOM-Tree also die View, wohingegen der JavaScript-Code den Controller darstellt. Das Model wird durch den Node repräsentiert, da dieser aus Sicht des Controllers die Daten bereitstellt. 8

13 3.4 Informationsverteilung Node N Account-Authorization Node-Authorization Anbieter Nutzer Leaf L Account-Authorization Account-Key Account-Secret Ticket-Key Node-Authorization Account-Key Ticket-Key P Pod Die Schlüsselverteilung zeigt, dass dem Node nur die Authentifizierungsschlüssel bekannt sind. Alle Schlüssel, die für die Verschlüsselung von Daten verwendet werden, sind nur dem Pod und dem Leaf bekannt. Darüber hinaus sind die Schlüssel für den Datenaustausch zwischen Leaf und Pod nur bis zum nächsten Datenaustausch gültig ( Kapitel Error: Reference source not found). Die Kommunikation zwischen Leaf und Pod entspricht also dem Prinzip der Perfect-Forward-Secrecy. Node N Ticket - Domain Domain - Entity Entity - Entity Anbieter Nutzer Leaf L Account - Ticket Ticket - Domain Domain - Entity Entity - Entity Ticket - Domain Domain - Entity P Pod Das Diagramm zeigt, an welche Informationen die einzelnen Komponenten anhand von gespeicherten Daten und der Analyse der ausgetauschten Daten gelangen können. Wichtigstes Merkmal ist dabei, dass es dem Node nicht möglich ist, Verbindungen zwischen Tickets und Accounts oder Domains und Accounts abzuleiten. Somit ist es einem Angreifer mit Zugriff auf den Node und eine Domain nicht möglich, Rückschlüsse auf andere Domains oder die Accounts der Domainnutzer zu ziehen. 9

14 4 Anwendungsszenarien 4.1 Persönlicher Pod Im Idealfall hat jeder Anwender seinen eigenen Pod auf dem er seine persönlichen Daten speichert. Im einfachsten Fall ist dieser auf dem eigenen Rechner installiert. Dies ist die einzige Softwareinstallation, die der Anwender tätigen muss. Er kann dann in allen REDS-fähigen Webapps seinen eigenen Rechner als Pod nutzen. Voraussetzung ist allerdings, dass der Rechner über das Internet erreichbar ist. Aus diesem Grund eignet sich der eigene Rechner nur bedingt als Pod. Besser ist es ein NAS oder den eigenen Webserver (bei Firmen) als Pod zu nutzen. Grundsätzlich bleibt es hier aber immer bei dem gleichen Prinzip, dass ein Pod nur einen (oder wenige) Nutzer bedient, die dort die Daten von mehreren REDS Webapps speichern. 4.2 Externe Pods Da die Installation eines Pods zwar vergleichsweise einfach vonstatten geht, ist doch immer ein aus dem Internet erreichbarer Rechner, der als Pod fungiert, von Nöten. Da dieser dem Durchschnittsanwender nicht immer zur Verfügung steht, kann der Pod auch zu einem vertrauenswürdigen Drittanbieter ausgelagert werden. Dessen Geschäftsmodell würde auf der Vermietung von vertrauenswürdigem Speicher basieren, so das dieser aus sich heraus schon ein Interesse an dem Schutz der Daten seiner Nutzer hat. Da auf dem Pod keine Verknüpfungen zwischen User und Entity gespeichert werden, ist es für einen Pod- Anbieter außerdem schwer einzelne Datensätze mit einem bestimmten Nutzer einer App in Verbindung zu bringen. Zusätzlich ist es mit REDS außerdem möglich die Daten verschlüsselt auf dem Pod des Drittanbieters zu speichern. 5 Stand der Entwicklung Das ursprüngliche Konzept basiert auf Bachelor-Thesis von Torben Haase. 5 Im Jahr 2013 wurde REDS durch das Projekt Flowy Tasks an der FH-Flensburg durch Torben Haase und Annika Schulz weiterentwickelt. Dieses wurde durch das EXIST-Gründerstipendium gefördert. In diesem Rahmen wurde nicht nur ein Konzept erarbeitet, sondern auch eine Referenzimplementierung entwickelt. Basierend auf der Arbeit aus dem Projekt Flowy Tasks wurde im ersten Quartal 2014 das Unternehmen Flowy Apps GmbH gegründet. Dieses wird neben den beiden REDS Webapps Flowy Notes a und Flowy Tasks b auch ein JavaScript-Framework zur Entwicklung von REDS Webapps vertreiben. 6 Derzeit wird das REDS-Konzept im Rahmen einer Closed Review durch Experten und erfahrene Programmierer untersucht. Das Release von REDS ist für Anfang September geplant. 5.1 Konzept Das Konzept kann nach über einem Jahr Entwicklungszeit im Wesentlichen als stabil betrachtet werden. Die Kommunikationsschnittstellen zwischen Leaf, Node und Pod werden derzeit nur noch geringfügig angepasst, um Anforderungen der konkreten Implementierung und Feedback aus der Closed Review zu berücksichtigen. a b

15 Ein Verschlüsselungsschema basierend auf Diffie-Hellman, AES128 und SHA256 wird ebenfalls durch das derzeitige Konzept vollständig beschrieben. Die Implemtierung ist bereits in Form einer Rohversion (Alpha) komplett vorhanden und wird derzeit in eine Reinversion umgeschrieben, welche die Grundlage für die öffentliche Betaphase ab September 2014 darstellt. 5.2 Referenzimplementierungen Im Rahmen des Projektes Flowy Tasks wurde die Notizen-Webapp Flowy Notes entwickelt, welche sich derzeit in der öffentlichen Betaphase befindet. Flowy Notes dient in Erster Linie als Proof-of-Concept für REDS. In dieser wird das grundlegende Kommunikationsschema auf seine Alltagstauglichkeit getestet. Hierbei geht in erster Linie um die Effizienz der Kommunikation zwischen Leaf, Node und Pod, sowie um die Tauglichkeit der definierten Schnittstellen für die Entwicklung einer Webapp. Das Ende der Betaphase ist für Oktober 2014 geplant. 5.3 REDS Framework Das REDS-Framework ist sowohl browser- als auch serverseitig komplett in JavaScript geschrieben. Auf Leaf-Seite umfasst ein Node-Client Modul, welches die Kommunikation zwischen der restlichen Webapp und dem Node übernimmt. Darüber hinaus sind ein Node-Server und einen Pod-Server vollständig implementiert. Node- und Pod-Server erweitern den HTTP-Server von Node.js um eine RESTful-API und optimieren diesen für Multi-Core Prozessoren. Out of the Box bekommt der Entwickler so eine sehr einfache, aber bereits funktionierende Webapp, die beispielhaft die Konzepte des REDS-Frameworks zeigt. Diese fungiert so als Boilerplate a und ermöglicht so den schnellen Entwicklungsstart. Der Code des REDS-Frameworks ist im Wesentlichen bereits in der Referenzimplemtierung enthalten. Allerdings muss der Framework-Code vor der Veröffentlichung noch aus dem Gesamtcode von Flowy Notes herausgelöst, aufbereitet und dokumentiert werden. Das Release des REDS-Framworks ist für das erste Quartal 2014 geplant Funktionsumfang Datenzugriff: Das REDS-Konzept wird so weit gekapselt, dass Entities über den einfachen Aufruf von Methoden des Node-Client Moduls erstellt, modifiziert und gelöscht werden können. Die für REDS nötigen Funktionen (z.b. Netzwerkkommunikation, Datenbankzugriff, Verschlüsselung) müssen also nicht neu implementiert werden. Nutzerverwaltung: Das Node-Client Modul stellt außerdem Methoden zum Registrieren, Anmelden und Verwalten von Nutzerkonten bereit. Da Zugriffskontrolle und das Teilen von gespeicherte Entities durch REDS geregelt wird, müssen diese Funktionen ebenfalls nicht erneut implementiert werden. Gute Integration: Auf der Backend-Seite können verschiedene Systeme für die Speicherung der REDS-Daten verwendet werden. Eine Anbindung an PostgreSQL-Datenbanken wird mitgeliefert; Weitere Anbindungen können als Module eingebunden werden. Auf der Frontend-Seite besitzt das Framework keine Abhängigkeiten von anderen Javascript-Libraries und ist dadurch einfach zu integrieren. Klarer Code: Das REDS-Framework trennt auf der Frontend-Seite klar zwischen Design und Code und folgt dem erprobten Model-View-Controller Prinzip. Diese Maßnahmen und der modulare a 11

16 Aufbau des Frameworks führen zu einem sauberen und pflegeleichten Code. 6 Geschäftsmodell 6.1 Open-Source Das REDS-Framework wird als Open-Source unter der GNU General Public License (GPL) veröffentlicht. Dies ist nicht nur Teil der Formenphilosophie von Flowy Apps, sondern ermöglicht vor allem anderen Entwicklern die Einsicht in den Code. Durch die externe Kontrolle werden dabei nicht nur Fehler minimiert, sondern es wird vor allem Vertrauen aufgebaut, da sich die Anwender nur so sicher sein können, dass REDS frei von bewusst eingebauten Sicherheitslücken, sogenannten Backdoors, ist. Die Nutzung des REDS-Frameworks ist kostenlos, allerdings erzwingt die GPL die Veröffentlichung des Quellcodes der auf dem REDS-Framework aufbauenden Webapps. Für die Nutzung in proprietären Webapps wird für REDS außerdem über eine kostenpflichtige Lizenz ähnlich der GNU Lesser General Public License (LGPL) angeboten, bei der de Quellcode geheim bleiben kann. 6.2 Dual-Licensing Diese Art der Lizenzierung wird als Dual-Licensing bezeichnet und wird bereits von anderen Open-Source Produkten erfolgreich verwendet (u.a. ZK a, Wakanda b oder QT c ). Die Preise für die kommerzielle Lizenz variieren bei vergleichbaren Lizenzmodellen zwischen 899$/Entwickler (ZK) und 6.395$/Entwickler (QT) d. Die Preismodelle unterscheiden sich jedoch stark in der Anzahl der angebotenen Features und im Supportumfang. Die Preisfestlegung von REDS orientiert sich an dem Programmieraufwand, der nötig wäre um eine vergleichbare Software wie das REDS-Framework selbst zu entwickeln. Durch die Veröffentlichung von REDS als Open-Source, ist die Entwicklungszeit deutlich kürzer als bei der Erstentwicklung. Ausgehend von circa 480 Arbeitsstunden und einem durchschnittlichen Monatsgehalt von Euro brutto je Programmierer, belaufen sich die Kosten für die Selbstentwicklung auf circa Euro. Die Jahreslizenz soll zu einem Verkaufspreis von brutto angeboten werden. Der Preis wird nur auf Anfrage mitgeteilt, so dass flexibel auf Anfragen von verschiedenen Kunden reagiert werden kann. 6.3 Zielgruppe Die kommerzielle Version des REDS-Frameworks richtet sich vor allem an den B2B-Bereich. Hier werden in erster Linie Web-Startups angeprochen, da diese Innovationen schneller adaptieren als bestehende Unternehmen. In Deutschland werden jährlich etwa Gründungen im IKT-Sektor getätigt e. Ein weiteres Kundensegment sind freiberufliche Webentwickler und bestehende Webapp-Anbieter. Die freie Version des REDS-Frameworks spricht daneben auch private Entwickler und Open-Source Projekte an. Diesen ermöglicht die kostenlose Verfügbarkeit des REDS-Frameworks einen schnellen und a b c d /msg /read/ e Monitoring-Report Digitale Wirtschaft 2012, Seite 9 12

17 unkomplizierten Einstieg. Diese Zielgruppe dient vor allem als Multiplikator und als Pool, aus dem sich zukünftige Professionals rekrutieren. 7 Personen 7.1 Torben Haase Torben Haase brachte sich im Alter von 13 Jahren selbst das Programmieren bei. Nach dem Beginn des Studiums der Biologie und Informatik an der Christian-Albrechts-Universität Kiel, entschied er sich 2005 für einen Wechsel zum Studiengang Medieninformatik an der Fachhochschule Flensburg. Ende 2012 schloss er sein Studium als Bachelor of Science mit einer Thesis über die theoretischen Grundlagen von REDS ab. Er war bereits neben seiner Schulausbildung als Programmierer für die Kieler Webagentur Tech-Know-How tätig und arbeitete ab 2008 neben dem Studium als freiberuflicher Webdesigner. Parallel dazu entwickelte er das iphone-spiel Shapes und betreute als Tutor Studenten in einer eigenen Veranstaltung. Torben Haase kann auf mehr als 15 Jahre Erfahrung als Web-Entwickler zurückblicken. Alle für die Entwicklung bei Flowy Apps notwendigen Basistechnologien beherrscht er auf höchstem Niveau und besitzt daneben ebenso Kompetenzen in den Bereichen Grafik und User-Interface-Design. Er hat mehrere umfangreiche Softwareprojekte (alleine und im Team) erfolgreich zuende geführt und konnte bereits vor Flowy Apps erste Erfahrungen als Selbständiger und Gründer sammeln. Aufgrund seiner Fähigkeiten ist Torben Haase daher vor allem für den technischen Bereich bei Flowy Apps verantwortlich. Dieser umfasst neben der eigentlichen Programmiertätigkeit auch das Design des User- Interfaces. Innerhalb des Flowy Apps Teams ist er der kreative Motor, der die Vision entwickelt hat und voran treibt. 7.2 Annika Schulz Annika Schulz schloss 2006 ihr Abitur an der Käthe-Kollwitz-Schule Kiel ab und begann anschließend ihre Ausbildung zur Veranstaltungskauffrau bei der Stockheim Catering Hamburg GmbH. Nach dem Abschluss ihrer Ausbildung 2010 absolvierte sie ein halbjährliches Praktikum bei der Handelsmarketingagentur Kiendl GmbH in Hamburg. Dabei war sie für die Planung und Betreuung von Sales-Promotions für einen eigenen Kundenstamm, sowie für die Personalorganisation dieser Projekte, verantwortlich. Derzeit studiert Annika Schulz Betriebswirtschaftslehre mit dem Schwerpunkt Marketing an der Fachhochschule Kiel. In diesem Zusammenhang hat sie im Frühjahr 2013 ein Auslandssemester in Almeria/Spanien absolviert und wird ihr Studium voraussichtlich im Sommersemester 2014 als Bachelor of Arts abschließen. Durch ihre vielseitige Aus- und Weiterbildung und das Studium im In- und Ausland konnte sich Annika Schulz bereits ein breites kaufmännisches Wissen aneignen. Zudem kann Sie sich durch Ihr Organisationstalent und ihre sozialen Kompetenzen schnell an neue Situationen und Gegebenheiten anpassen und auftretende Probleme lösen. Bei Flowy Apps übernimmt sie alle Aufgaben, die in den kaufmännischen Bereich fallen. Vom strategischen Management und Marketing bis hin zu den Finanzen. Sie ist der strukturierende Teil des Gründerteams, der die Einhaltung der Zielvorgaben und Meilensteine kontrolliert und so den stabilen Rahmen liefert, in dem die Vision von Flowy Apps gedeihen kann. 13

18 1 Referenzen 1 O'Reilly (2005): Design Patterns and Business Models for the Next Generation of Software 2 Index on Censorship (24. August 2012): Web 2.0: Don t shoot the messenger 3 The Guardian (7. Juni 2013): NSA Prism program taps in to user data of Apple, Google and others 4 Whitten, Tygar (2005): Why Jonny can't encrypt - A Usability Evaluation of PGP 5.0 Designing Secure Systems that People Can Use (Seite 679ff), O'Reilly Media, ISBN: Haase (2012): Implementierung eines Systems zur sicheren Speicherung von Daten in verteilten Systemen Einsicht auf Anfrage (torben@flowyapps.com) 6 Schulz, Haase (2013): Businessplan: Flowy Apps another kind of working Einsicht auf Anfrage (annika@flowyapps.com)