DE102015103251B4

DE102015103251B4 - Verfahren und System zum Verwalten von Nutzerdaten eines Nutzerendgeräts

Info

Publication number: DE102015103251B4
Application number: DE102015103251.1A
Authority: DE
Inventors: Patentinhaber gleich
Original assignee: Individual
Current assignee: Sabri Aly Dr De
Priority date: 2015-03-05
Filing date: 2015-03-05
Publication date: 2017-03-09
Anticipated expiration: 2035-03-06
Also published as: DE102015103251A1; WO2016139371A1

Abstract

Verfahren zum Verwalten von Nutzerdaten eines Nutzerendgeräts, wobei das Verfahren folgende Schritte aufweist: – Erzeugen eines Schlüsselpaars aus privaten Schlüssel prK und öffentlichen Schlüssel puK, – Aufteilen des privaten Schlüssels prK in mindestens zwei Teildatensätze, wobei die mindestens zwei Teildatensätze mittels einer bijektiven Operation rekombinierbar erzeugt werden und die Transinformation I jedes der mindestens zwei Teildatensätze 0 ≤ I ≤ 2–|prK| erfüllt, wobei |prK| die Zahl der Bits des privaten Schlüssels prK bezeichnet, – Verschlüsseln von Nutzerdaten D und Speichern der verschlüsselten Nutzerdaten D* in einer über ein Netzwerk zugänglichen externen Speichervorrichtung, und – Wiederabrufen und Entschlüsseln der verschlüsselt gespeicherten Nutzerdaten D* aus der externen Speichervorrichtung, wobei das Wiederabrufen und Entschlüsseln ein Wiederherstellen des privaten Schlüssels prK durch Rekombinieren der beiden Teildatensätze mittels der zum Aufteilen inversen bijektiven Operation aufweist.

Description

Stand der Technik
Die digitale Datenverarbeitung, Datenspeicherung und Vernetzung ist nahezu vollständig in das Leben eines jeden Bürgers eingedrungen. In der modernen Zivilisation gibt es heute kaum noch Menschen, die nicht Computer, mobile Smart Devices und das Internet benutzen. Insbesondere durch die Nutzung von mobilen Smart Devices (z. B. Smartphones, Phablets, Tablets, Smart-Watches, Smart-Bands, Smart Keychains, Smart Cards, etc.) fallen kontinuierlich riesige Datenmengen an. Diese Daten werden entweder vom Nutzer selbst erstellt, wie etwa Bilder, Videos und Dokumente, oder werden von den mobilen Smart Devices automatisch erzeugt, wie zum Beispiel Nutzungs- und Bewegungsdaten.
Die Speicherung von digitalen Daten erfolgt zunehmend mit Cloud-Computing auf externen Speichern, sogenannten Cloud-Speichern. Unter Cloud-Computing versteht man allgemein die Nutzung von verteilten Rechner- bzw. Speicherressourcen eines Cloud-Anbieters. Auf diese verteilten Speicherressourcen kann ein elektronisches Nutzer-Endgerät (z. B. mobile Smart Devices, Notebooks, PCs, etc.) über ein meist öffentliches Netzwerk (z. B. das Internet) wie auf einen lokalen Speicher zugreifen. Anbieter von solchen Cloud-Speichern versprechen bei der Speicherung von Nutzerdaten Bequemlichkeit, Verfügbarkeit und Datensicherheit.
Dabei ergeben sich insbesondere beim Speichern und Wiederabrufen der Daten der jeweiligen Nutzer-Endgeräte in den Cloud-Speichern zunehmend Probleme in Bezug auf Datensicherheit und Datenkontrolle, sowie dem Abwägen zwischen Nutzbarkeit versus Sicherheit. Diese drei Problemfelder sollen im Folgenden mit jeweils einem Beispiel veranschaulicht werden:
Datensicherheit:
Die Datenspeicherung in Cloud-Speichern ist bis heute mit erheblichen Sicherheitsrisiken behaftet. Der Zugriff auf die Daten wird in der Regel durch ein Zugangspasswort geschützt, ggf. zusätzlich durch eine Rückruffunktion (bspw. ein dynamisches Codewort, das per SMS versendet wird). Auf den speichernden Systemen liegen die Daten jedoch in der Regel unverschlüsselt vor, so dass bei einem Angriff auf den speichernden Server, oder durch Knacken des Passwortes (z. B. über Phishing-Attacken) diese Daten für Dritte zugänglich werden können.
Um dieses Risiko zu umgehen, kann der Nutzer prinzipiell versuchen, seine Daten bereits verschlüsselt in der Cloud abzulegen. Er muss sich dann jedoch auch um die Verwaltung der verwendeten Schlüssel selber kümmern; verwendet er nur wenige oder nur einen Schlüssel, so sind die Daten nicht wesentlich sicherer abgelegt als zuvor. Verwendet er für jede Datei einen eigenen Schlüssel, ist die Verwaltung manuell mithin nicht mehr handhabbar.
Außerdem gehen durch dieses Vorgehen weitere Cloud-spezifische Features verloren. So ist es dem Nutzer nicht mehr ohne weiteres möglich, unter Beibehaltung der gewünschten Sicherheit Daten mit anderen zu teilen, da er dann auch jeweils die verwendeten Schlüssel teilen muss. Gelten diese für mehr als nur die geteilten Daten, werden unter Umständen auch andere Daten prinzipiell für den Empfänger nutzbar. Gleichzeitig geht der Nutzer das Risiko ein, dass der Dritte, mit dem geteilt werden sollte, die notwendigen Schlüssel nicht sicher genug verwahrt.
Nutzerfreundlichkeit versus Sicherheit
Cloud-Anbieter, die eine als sicher geltende asymmetrische Verschlüsselung mit einem Schlüsselpaar aus privatem und öffentlichem Schlüssel verwenden, die zumindest das Problem der Schlüsselverwaltung einigermaßen reduziert (da die Verschlüsselung über den öffentlichen Schlüssel erfolgt, der gemeinhin bekannt ist, während die Entschlüsselung mit dem geheimen privaten Schlüssel durchgeführt wird) sind derzeit nicht auf dem Markt bekannt. Gleichzeitig bietet diese Art der Verschlüsselung den Nachteil, dass Daten nicht mehr über die Cloud-Infrastruktur geteilt werden können, sondern nur, indem der Nutzer sie auf seinem Endgerät entschlüsselt und dann an den Dritten weitergibt.
Des Weiteren setzen diese asymmetrischen Methoden voraus, dass der identitätsgebende private Schlüssel absolut geheim bleibt. Dieser Schlüssel liegt dabei in der Regel als Datei auf einem Rechner vor, die wiederum über ein Passwort gesichert ist. Bei einem Verlust dieses Passwortes oder einem Verlust der Datei (z. B. durch den Verlust aller sie speichernder Endgeräte) ist die weitere Nutzung des Schlüssels ausgeschlossen; alle Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, sind dann unwiederbringlich verloren. Sollte dagegen die Datei mit dem privaten Schlüssel in falsche Hände geraten und das Passwort gefunden werden (weil es entweder nicht sicher genug war, oder der Nutzer es durch eine Fehlbedienung oder eine Phishing-Attacke preisgegeben hat), sind Daten als auch die Identität des Nutzers, falls der Schlüssel für Signaturen zum Einsatz kommt, kompromittiert. Aufgrund der komplexen Handhabung und der beschriebenen Nachteile werden diese Verfahren daher nur von einem Bruchteil von Nutzern eingesetzt.
Ein weiterer Nachteil, der bei einer Verschlüsselung entsteht, ist der, dass die Verwaltung der Daten durch das Fehlen entsprechender Metadaten erschwert wird. Die einzigen zur Verfügung stehenden Metadaten sind in der Regel noch die Dateinamen. Eine Vorschau z. B. von Bildern oder anderen Inhalten, wie sie den Nutzern heute in Diensten wie iCloud zur Verfügung steht, ist damit mithin ausgeschlossen.
Datenkontrolle:
Mit der Verbreitung von Smart Devices und Online-Diensten werden von Nutzern in zunehmendem Maße Nutzungs- und Bewegungsdaten aufgezeichnet und gespeichert.
Diese sind zum Beispiel Surfdaten (z. B. Browserverlaufsdaten, Cookies, etc.) im Internet, GPS- und Bewegungsprofile, Zahlungsvorgänge, oder weitere Datensätze, die von aktuellen Sensoren erzeugt werden (GPS-Sensoren im Smartphone, Fitness- und Gesundheitsdaten aus aktuellen Smart Wearables, die u. a. Puls, Transpiration und Körpertemperatur messen, Daten von Google Glass, wie z. B. Bewegungsprofile und Blickprofile [in welche Richtung und auf welche Objekte der Nutzer seinen Blick wendet], der Apple Watch, z. B. Fitness-Armbändern, die ebenfalls mit dem Internet verbunden sind, ...), etc. Diese Nutzungs- und Bewegungsdaten sind im Vergleich zu Texten, Bildern oder Videos in der Regel eher mit geringen Datensatzgrößen assoziiert und seien im Folgenden generell als „telematische Daten” bezeichnet.
Zunehmend werden Fragen laut, wem diese Daten gehören bzw. wem die Nutzung und Verwertung zusteht. Im Moment hat der Nutzer nur die Möglichkeit den Nutzungsbedingungen des Anbieters zuzustimmen oder den Dienst oder Service gar nicht erst zu verwenden. Dies schränkt das Recht auf informationelle Selbstbestimmung erheblich ein.
Zum Problemfeld Datenkontrolle kann daher wie folgt zusammengefasst werden: Die Datenkontrolle der vom Nutzer generierten Daten liegt komplett in der Hand eines Service-Anbieters und nicht bei dem, der die Daten erzeugt hat, dem Nutzer. Dies gilt auch für kommerzielle Erträge aus diesen Daten, die dem Nutzer derzeit nicht zugutekommen.
Herkömmliche Verfahren werden beispielsweise in der US 6 072 876 A , in Boyd, C., ”Some Applications of Multiple Key Ciphers”, Advances in Cryptology – EUROCRYPT '88, LNCS 330, Seiten 455–467, Springer-Verlag Berlin Heidelberg 1988 und in Wang, E. K., et al., ”A Key-Recovery System for Long-Term Encrypted Documents”, 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW'06), IEEE 2006, Seiten 1–4, beschrieben.
Überblick über die Erfindung
In Anbetracht der oben beschriebenen Probleme ist es daher Aufgabe der Erfindung ein Verfahren und System zum Verwalten von Nutzerdaten von zumindest einem Nutzerendgerät zu schaffen, dass hinsichtlich der gespeicherten Nutzerdaten eine verbesserte Datensicherheit und -kontrolle sowie akzeptable Benutzerfreundlichkeit aufweist.
Diese Aufgabe wird jeweils durch die Merkmalskombinationen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausführungsformen und Weiterentwicklungen sind Gegenstand der sich daran anschließenden Unteransprüche.
Unter Nutzerdaten werden im Rahmen dieser Erfindung digitale Daten bzw. Datensätze verstanden, die von einem oder mehreren Nutzerendgerät zur Speicherung an einen über ein Netzwerk zugänglichen externen Speicher, beispielsweise einem Cloud-Speicher, gesendet werden, wie dies beim Cloud-Computing geschieht.
Das erfindungsgemäße Verfahren und System bietet folgende Vorteile:

– Vollständige Datensicherheit vor dem Zugriff Dritter, inklusive des jeweiligen Cloud-Anbieters, durch die ausschließliche Handhabung informationsloser oder verschlüsselter Daten auf Systemen außerhalb des Endgerätes des Nutzers.
– Keine Abhängigkeit von einem Dienst-Anbieter im Sinne eines Trustcenters für die Verwaltung der Daten und/oder der Schlüssel
– Die Datenfreigabe (= Teilen von Daten) kann in Bezug auf beliebige Eigenschaften gesteuert werden. Z. B. Format der Datei, Erstellungsdatum, für einen Zeitraum, etc.
– Daten und Schlüssel können auf beliebigen – auch unsicheren – Speichern abgelegt werden, da sie jeweils informationslos bzw. verschlüsselt vorliegen
– Bewegungsdaten lassen sich zur eigenen Verwendung und ggf. zur Freigabe an Dritte sicher speichern, ohne dass sich die Daten selber durch den Nutzer modifizieren lassen
– Sicheres Speichern eines privaten Schlüssels durch Trennen in unterschiedliche Bestandteile zur einfachen Rekonstruktion bei Verlust, und zur sicheren Weiterverbreitung auf mehreren Endgeräten
– Nutzung eines einzelnen Schlüsselpaares für eine ganze Gruppe von Nutzern, die jeweils unterschiedliche Bestandteile des Schlüssels kennen, und die auch einzeln wieder aus der Gruppe ausgeschlossen werden können, zur Vereinfachung der Handhabung der zahlreichen notwendigen Schlüssel.

Unter Nutzerdaten werden im Rahmen dieser Erfindung digitale Daten bzw. Datensätze verstanden, die von einem oder mehreren Nutzerendgerät zur Speicherung an einen über ein Netzwerk zugänglichen externen Speicher gesendet werden, wie dies beispielsweise beim Cloud-Computing geschieht.
Die Erfindung verwendet sogenannte Module, die auf unterschiedlichen im Netz befindlichen Rechner verbunden sind. Die Module können als Funktionseinheiten aufgefasst werden, die als Hardware oder Software implementiert sind. Im Folgenden werden zunächst die für die Erfindung bedeutsamen Module eingeführt. Anschließend folgt eine Übersicht über einige der im Netz verteilten Rechner und ihrer im Rahmen der Erfindung üblichen Rollen. Zuletzt folgen Ausführungsbeispiele, in denen jeweils konkrete Zusammenschaltungen der Module zur Erreichung der oben erwähnten Vorteile vorgestellt werden.
Modulstruktur
Das erfindungsgemäße Verfahren basiert auf den folgenden Modulen, die zu kommunizierenden Funktionseinheiten verbunden werden können:

a. Schlüsselpaar-Generator
b. Dekombinierer
c. Rekombinierer
d. Metadaten-Generator
e. (Symmetrischer) Schlüsselgenerator
f. Enkryptor
g. Dekryptor
h. Distributor
i. Retriever
j. Verzeichnisspeicher
k. Schlüsselspeicher

Die Module können alle oder nur in Teilen zum Einsatz kommen, um problemspezifische Anwendungen zu erhalten. Die rechnerübergreifende Kommunikation zwischen zusammengeschalteten Modulen hat dabei immer mittels einer sicheren (= verschlüsselten) Kommunikation (bspw. HTTPS/TLS/SSL) zu erfolgen.
Im Folgenden werden die Funktionen der Module beschrieben:
Schlisselpaar-Generator
Ein wichtiger Aspekt des erfindungsgemäßen Verfahrens ist es, dass der Nutzer über ein asymmetrisches Schlüsselpaar für eine asymmetrische Verschlüsselung verfügt. Dazu kann ein Schlüsselpaar-Generator verwendet werden, der ein asymmetrisches Schlüsselpaar aus einem privaten Schlüssel (private Key) prK und einem öffentlichen Schlüssel (public key) puK erzeugt.
Dekombinierer/Rekombinierer
Der Dekombinierer teilt den Ursprungsdatensatz D in zwei oder mehr rekombinierbare Teildatensätze D₁, D₂, ..., D_n die der Rekombinierer dann wieder zum Ursprungsdatensatz zusammenfügen kann. Die einzelnen Teildatensätze dürfen dabei für sich genommen keine Information im informationstheoretischen Sinn enthalten. Dies bedeutet, dass bei einem gegebenen Ursprungsdatensatz jede beliebige Menge von Teildatensätzen entstehen kann, dass also die Verteilung von Einsen und Nullen in den Binärdaten hinterher rein zufällig ist, und es unmöglich ist, aus der Kenntnis eines Teildatensatzes auf den Inhalt oder einen Teil des Inhaltes des Ursprungsdatensatzes zu schließen. Genauso sollte bei bekanntem Ursprungsdatensatz nicht auf Eigenschaften der Teildatensätze (wie die Verteilung von Einsen und Nullen) geschlossen werden können. Vorzugsweise sind die Teildatensätzen gleich groß.
Die in D enthaltene Information, sowie die in den Teildatensätzen D_i enthaltene Information wird in der Informationtheorie beschrieben durch das Maß der Entropie, sowie der Transinformation (mutual information). Eine übliche Einheit für die Entropie ist Bit, und für beliebige Datensätze D entspricht sie üblicherweise der Zahl von Einsen und Nullen (also Bits), aus denen D besteht. Diese Entropie kann im informationstheoretischen Sinn gleichgesetzt werden mit der in der Botschaft D enthaltenen Information, jedenfalls dann wenn jede denkbare Bitfolge ein mögliches D darstellt, und jedes mögliche D gleich wahrscheinlich ist. Definiert ist sie als H(D) = –Σ_dp(x)logp(x), wobei jedes x für ein Symbol (ein Bit) in D steht, und p(x) für die Wahrscheinlichkeit, dass dieses Bit genau den Wert annimmt, den es in D hat. Für gleichverteilte Bitfolgen ist p(x) genau ½, und die Entropie entspricht genau der Zahl der Bits in D.
Die Transinformation ist ein Maß für die Wahrscheinlichkeit, mit der unter Verwendung eines der Teildatensätze D_i auf D geschlossen werden kann. Idealerweise ist die Transinformation nahezu Null. Mathematisch definiert ist diese Größe als

wobei die Schreibweise p(D|D_i) die bedingte Wahrscheinlichkeit bedeutet, D zu erraten, wenn D_i bekannt ist. Null ist diese Wahrscheinlichkeit genau dann, wenn der Bruch
den Wert 1 annimmt, da log(1) = 0. Dies ist genau dann der Fall, wenn D und D_i stochastisch unabhängig voneinander sind, oder in einfachen Worten: wenn eine beliebige gewählte Bitfolge immer einen Teildatensatz D_i darstellen könnte, unabhängig von D; dies müsste gleichzeitig für alle Teildatensätze gelten, wobei aus den Teildatensätzen wiederum D rekonstruierbar sein müsste. Daraus ist bereits ersichtlich, dass dies nie vollständig der Fall sein wird, da beispielsweise die Länge der Teildatensätze von der Länge von D abhängig sein muss: besteht D aus n Bits, müssen alle Teildatensätze zusammen wieder mindestens n Bits enthalten, sonst wäre eine Rekonstruktion unmöglich; auf der anderen Seite können die Teildatensätze zusammen nicht beliebig lang sein, da dies unter praktischen Gesichtspunkten die Speicherung limitieren würde. Ziel der Implementierung des Dekombinierers muss es daher sein, die Transinformation zu minimieren; ein guter Zielwert für die Zerlegung in zwei Teildatensätze wäre I = 2^–|D|, wobei |D| die Zahl der Bits von D bezeichnet. Dieser Zielwert wird genau dann erreicht, wenn die Teildatensätze vollständig zufällig, jedoch genauso lang wie D selber sind.
Allgemein gesprochen führt der Dekombinierer auf dem Datensatz selbst, sowie mindestens einer zufällig erzeugten Bitfolge bzw. einer Menge interner Parameter eine algebraische Operation aus, die eine Menge von Bitfolgen als Ergebnis hat. Diese Ergebnis-Bitfolgen können im Rekombinierer durch Anwenden der inversen Operation des Dekombinierers wieder in den ursprünglichen Datensatz verwandelt werden, vorzugsweise so, dass die anderen für die Operation verwendeten Bitfolgen und internen Parameter des Dekombinierers verborgen bleiben.
Mathematisch gesehen führt der Dekombinierer eine bijektive (also invertierbare) Operation f_R(D) aus und liefert R und D zurück, R entspricht hier dem oben genannten internen Parameter. Der Rekombinierer berechnet f^–1 _R(f_R(D)) = D. Für mehr als einen Datensatz kann der Dekombinierer die Ergebnisse f_R1(D), f_R2(R1), ..., f_Rn(R_n-1) liefern. Der Rekombinierer berechnet dann entsprechend R_n-1 = f^–1 _Rn(f_Rn(R_n-1)), R_n-2 = f^–1R_n-1(f_Rn-1(R_n-2)), ..., R₁ = f^–1 _R2(f_R2(R₁)) und daraus schlußendlich f^–1 _R1(f_R1(D)) = D. Die Menge der R_n ist die Menge der internen Parameter des Dekombinierers.
Eine mögliche Realisierung wäre es, als f_R(D) ein symmetrisches Verschlüsselungsverfahren mit dem zufällig gewählten Schlüssel R zu verwenden. Bei Verwendung eines Verschlüsselungsverfahrens besitzt R jedoch in der Regel eine feste Länge, mithin eine geringere Länge als der ursprüngliche Datensatz D, insbesondere bei langen Datensätzen, wie zum Beispiel Bilddaten. Damit ist der Inhalt von f_R(D) automatisch nicht mehr informationslos im obigen Sinne, außerdem lassen sich bei der Übertragung D und f_R(D) anhand der Länge leicht unterscheiden.
Eine bevorzugte Realisierung ist daher die Verwendung einer Operation f_R(D) = D + R, wobei D und R in der Regel gleich lang, oder R mindestens so lang wie D, und diese Operation + auf der Menge der verwendeten Bitfolgen eine algebraische Gruppe bildet, d. h.

– die Operation ist geschlossen, d. h. das Ergebnis der Operation ist wieder eine Bitfolge
– die Operation ist assoziativ, (A + B + C) = (A + B) + C = A + (B + C)
– es gibt ein neutrales Element 0, A + 0 = A (dies ist in der Regel eine Folge aus lauter Nullen)
– zu jedem A gibt es genau ein inverses Element –A, mit A+(–A) = 0

Eine mögliche Realisierung für den Dekombinierer ist daher die Erzeugung zweier Datensätze D1/D2 mit D1 = D xor R, D2 = R aus dem ursprünglichen Datensatz D und einer vollständig zufälligen Zufallsfolge R gleicher Länge unter Verwendung der bitweisen xor-Funktion. D1 und D2 sind dann ebenfalls vollständige Zufallsfolgen, der Ursprungsdatensatz lässt sich allerdings aus Kenntnis von D1 und D2 wieder zusammenfügen als D = D1 xor D2. Die Zufallsfolge R kann dabei mittels eines physikalischen Zufallszahlengenerators, oder eines kryptographisch sicheren Pseudozufallszahlengenerators erzeugt werden.
Statt der xor-Operation kann auch eine normale Addition, oder eine blockweise Addition mit blockweisem Modulo, sowie andere Operationen mit den oben beschriebenen Eigenschaften verwendet werden.
Der Rekombinierer rekombiniert die Teildatensätze zum Ursprungsdatensatz. Der Ursprungsdatensatz kann ein privater Schlüssel und/oder kleinteilige Nutzerdaten sein. Der Rekombinierer führt beispielsweise in der obigen XOR-Realisierung die Operation D1 xor D2 = D aus, um D zu rekonstruieren. Allgemein gesprochen führt der Rekombinierer zum Wiederherstellen des privaten Schlüssels prK eine Rekombination durch Anwenden der zum Dekombinierer inversen Operation auf die Teildatensätze aus.
Metadaten-Generator:
Als Metadaten werden beschreibende Daten der betreffenden Datei definiert. Dies können sein: Datum, Auflösung, Dateityp, Dateiname, Thumbnails, etc. Die Metadaten dienen der einfachen Indizierung auf einem Verzeichnisserver, der ein Modul Verzeichnisspeicher (siehe Punkt e) implementiert, und werden nicht verschlüsselt. Der Grad an gewünschter Sicherheit ist damit auch abhängig von der Zahl an Metadaten, die zur Verfügung gestellt werden. Zu diesem Zweck existiert das Modul Metadaten-Generator, welches in vom Nutzer konfigurierbarer Weise aus Dateien bzw. Datensätzen die gewünschten Metadaten extrahiert.
(Symmetrischer) Schlüsselgenerator
Der Schlüsselgenerator erzeugt in frei konfigurierbaren Intervallen oder nach frei bestimmbaren Regeln einen kryptographisch sicheren, zufälligen Schlüssel K für ein symmetrisches Verschlüsselungsverfahren. Dieser Schlüssel K wird nur an Module auf dem gleichen physikalischen Rechner weitergegeben, und nur an einen Enkryptor oder Distributor. Bei jeder Neuerzeugung eines Schlüssels wird dieser über den öffentlichen Schlüssel puK des Nutzers als K* verschlüsselt und weitergereicht, z. B. an einen Schlüsselspeicher bzw. Schlüsselserver.
Eine wichtige Eigenschaft des Schlüsselgenerators ist, dass nicht zwangsläufig mit jedem Verschlüsselungsvorgang ein neuer Schlüssel erzeugt wird; dies kann auch nach zeitlichen Abständen erfolgen. K kann also jederzeit durch ein anderes Modul angefordert werden, K* verlässt den Schlüsselgenerator nur bei einer Neuerzeugung des Schlüssels.
Enkryptor/Dekryptor:
Der Enkryptor verschlüsselt die eingehenden Daten symmetrisch mit einem Schlüssel K, der von einem Modul Schlüsselgenerator (s. o.) erzeugt wurde. Der Dekryptor entschlüsselt die mit dem entsprechenden Enkryptor verschlüsselten Daten unter Verwendung von K.
Distributor/Retriever:
Der Distributor verteilt empfangene Datenpakete auf eine Menge externer unabhängiger Server mit Speichern, die eine Cloud-Speichervorrichtung bilden können, indem diese Pakete zunächst in kleinere, vorzugsweise exakt gleich große Pakete aufgeteilt und dann in beliebiger Reihenfolge an eine Untermenge zur Verfügung stehender Server zur verteilten Speicherung weitergeleitet werden. Der Distributor wird vor allem dann nötig, wenn die sichere Kommunikation zwischen einem Speicher und der speichernden Anwendung unter Umständen kompromittiert wurde, und verhindert werden soll, dass allein aus der Größe und Zahl gespeicherter Dateien Rückschlüsse auf den Nutzer gezogen werden können.
Um derart verteilte Datenpakete wieder rekonstruieren zu können, wird die Information benötigt, welcher Teil der ursprünglichen Daten wo gespeichert wurde. Dieses Tupel aus Speicherorten wird als Zugriffskode AC bezeichnet. Mit der Speicherung der Daten verschlüsselt der Distributor den Zugriffskode AC mit dem privaten Schlüssel des Nutzers prK als verschlüsselten Zugriffskode AC* und sendet ihn zur Speicherung an ein anderes Modul, beispielsweise einen Verzeichnisspeicher. Die Verschlüsselung des Zugriffskodes AC kann auch separat mit einem Modul Enkryptor erfolgen. Der Retriever ruft die verteilt gespeicherten Datenpakete aus der Cloud-Speichervorrichtung wieder ab und gibt sie als einen Datensatz an das nachfolgende Modul aus. Dieses Modul kann beispielsweise ein Dekryptor sein.
Optional können in Ausführungsformen der Erfindung der Enkryptor und der Dekryptor zum Ver- bzw. Entschlüsseln des Zugriffskodes AC im Distributor bzw. Retriever jeweils integriert oder separat ausgebildet sein.
Verzeichnisspeicher:
Das Modul „Verzeichnisspeicher” verknüpft zusammengehörige Metadaten, Zugriffskodes (aus dem Distributor) und Datensatz-IDs in einer Datenstruktur, die im Verzeichnisspeicher abgelegt wird. So erlaubt der Verzeichnisspeicher eine gezielte Suche nach bestimmten Attributen/Metadaten und das Wiederfinden der zugehörigen Zugriffskodes und Datensatz-IDs. Die Gesamtheit aller dieser Datenstrukturen, die auch untereinander wiederum verknüpft sein können repräsentiert damit die Dateistruktur aller Daten des Nutzers. Bei einem gezielten Hackerangriff kann an dieser Stelle nicht vermieden werden, dass ggf. zumindest Teile der Metadaten einem Angreifer sichtbar werden (die Zugriffskodes sind so verschlüsselt, dass nur der Nutzer selbst sie entschlüsseln kann). Dies ist bei der Auswahl der zu speichernden Metadaten, und dem Ort, an dem der Verzeichnisspeicher betrieben wird (Intanet, Internet, auf dem Endgerät des Nutzers...) zu berücksichtigen. Alternativ können die Metadaten auch verschlüsselt werden.
Um Dateien zwischen Nutzern zu teilen, ist eine Entschlüsselung des Zugriffskodes durch den Nutzer (als Eigentümer der Daten) und die nachfolgende Neuverschlüsselung über den öffentlichen Schlüssel des empfangenden Nutzers (= Nutzer der Daten) notwendig. Der Verzeichnisspeicher kann bei Bedarf verschiedentlich verschlüsselte Zugriffskodes (für jeden zugriffsberechtigten Nutzer) ablegen, um diesen Zugriff zu vereinfachen.
Gleichzeitig kann der Verzeichnisspeicher die gespeicherten Daten zueinander in Relation setzen; so können Versionsbeziehungen von Dateien (Vorgänger- vs. Nachfolgerversion), als auch hierarchische Strukturierung (ähnlich einem Dateisystem) abgebildet werden.
Schlüsselspeicher:
Das Modul „Schlüsselspeicher” speichert die verwendeten Schlüssel K* des Enkryptors, zusammen mit einer Information, für welche Dateien dieser Schlüssel Gültigkeit besitzt. Für die Abfrage des jeweils gültigen Schlüssels sind daher gezielte Informationen an den Schlüsselspeicher zu übergeben (Teile der Metadaten, Datum der Speicherung, ggf. eine eindeutige Datensatz-ID). Die abgelegten Schlüssel selber sind durch den Schlüsselserver nicht entschlüsselbar, da sie mittels des öffentlichen Schlüssels des Eigentümers verschlüsselt wurden (siehe Enkryptor).
Beteiligte Recheneinheiten im Netzwerk
Vorzugsweise werden die oben beschriebenen Module auf unterschiedlichen Rechnern oder Rechnersystemen zur Ausführung kommen. Während im Einzelfall verschiedene Ebenen hinzukommen können, sind in der Regel die folgenden Rechner beteiligt:
Nutzer-Endgerät
Dies ist ein Gerät, das vollständig vom Nutzer kontrolliert wird, bspw. ein privater Rechner, ein Smartphone, ein Tablet, oder dergleichen. Endgeräte stellen in der Regel genau die Orte dar, an denen diejenige Information entsteht bzw. unverschlüsselt vorliegt, die im Rahmen der Erfindung sicher auf einem externen Speicher, beispielsweise einem Cloud-Speicher, gespeichert werden soll.
Aus dieser Definition ergeben sich automatisch zwei Konsequenzen:

• Daten dürfen auf dem Nutzer-Endgerät auch im Rahmen jeglicher Ausführungsform der Erfindung in unverschlüsselter Form bearbeitet werden.
• Außer auf dem Nutzer-Endgerät dürfen Daten jedoch nie so verarbeitet werden, dass sie in Gänze oder zum Teil unverschlüsselt vorliegen, da nicht sichergestellt werden kann, dass andere Geräte (die nicht unter Kontrolle des Nutzers stehen) vollständig sicher sind.

Das Nutzer-Endgerät ist auch diejenige Instanz, die den zu speichernden Daten eine zufällige, möglichst global gültige ID vergibt (sog. UUID), welche in der Regel an den Schlüsselspeicher und den Verzeichnisspeicher weitergereicht werden. Siehe hierzu die spätere Beschreibung der Ausführungsformen.
Sensor, telematisches Gerät
Dies ist eine Sonderform eines Nutzer-Endgerätes, wie die eingangs erwähnten Smart Devices. Auf einem telematischen Gerät im Sinne dieser Erfindung werden kleinteilige Daten über den Nutzer erhoben, zum Teil ohne dessen aktive Mitwirkung. Ein telematischer Sensor kann außerdem die Eigenschaft besitzen, nicht vollständig durch den Nutzer konfigurierbar zu sein (ein Smartphone bspw. ist nicht unter allen Umständen vollständig frei konfigurierbar, wohingegen auf einem privaten Laptop die üblicherweise verwendeten Betriebssysteme deutlich mehr Freiheiten einräumen; eine Sensorbox, die in einem Kraftfahrzeug montiert Daten über das Fahrverhalten des Nutzers liefert, befindet sich zwar in dessen Zugriffsbereich, ist für ihn aber ansonsten nicht in seiner Funktion zu beeinflussen).
Autorisierungsserver:
Der Autorisierungsserver, der sich beispielsweise im Intranet des Nutzers befinden kann, ist hier als eine Instanz definiert, die öffentliche Schlüssel der Nutzer speichert und eindeutig den Nutzern zuordnet (ähnlich einer Zertifizierungsstelle). Zu jedem Nutzer wird dort ein Account verwaltet, der neben dem öffentlichen Schlüssel und generellen Informationen über den Nutzer (wie z. B. eine Nutzerkennung) zusätzlich Teile des privaten Schlüssels speichert. Dies kann beispielsweise ein Teildatensatz von einem privaten Schlüssel prK sein, der vom Dekombinierer erzeugt worden ist. Der Nutzer kann durch eine Authentifizierung beispielsweise mittels Passwort oder Passphrase diesen Teildatensatz abrufen und mit Hilfe eines weiteren Teildatensatz, den er besitzt, zu dem Ursprungsdatensatz, beispielsweise den privaten Schlüssel, rekombinieren.
Neben dem privaten‚ und öffentlichen Schlüssel eines Nutzers verwaltet der Autorisierungsserver auch die Gruppenzugehörigkeit der Nutzer. Jede Gruppe besitzt dabei wieder einen öffentlichen Schlüssel, sowie einen privaten Schlüssel, dessen Bestandteile sich jedoch in den Accounts der Gruppenmitglieder befinden, und sich für jedes Gruppenmitglied unterscheiden (siehe auch weiter unten, Weitergabe von Gruppenschlüsseln).
Schlüssel- und Verzeichnisserver
Die oben beschriebenen Module Schlüssel- und Verzeichnisspeicher werden in den Ausführungsformen in der Regel auf eigenständigen Rechnern abgelegt, die dann als Schlüssel- bzw. Verzeichnisserver bezeichnet werden.
Dabei ist es nicht unbedingt notwendig, dass der Schlüsselspeicher auf einem eigenen Schlüsselserver läuft. Wird vom Enkryptor beispielsweise für jeden Datensatz ein eigener Schlüssel verwendet, ist die Gültigkeit des Schlüssels K auf diesen einen Datensatz beschränkt. In diesem Fall kann der Schlüssel zusammen mit dem Zugriffskode abgelegt werden. Schlüssel- und Verzeichnisspeicher laufen dann auf dem gleichen physikalischen Rechner, der zur Vereinfachung nur noch Verzeichnisserver genannt wird. Wählt der Enkryptor jedoch datumsabhängig neue Schlüssel, ist der Gültigkeitsbereich durch ein Datumsintervall gekennzeichnet.
Speicherserver
Die aus dem Modul „Distributor” gesendeten Teildatensätze werden in einem externen Speicher gespeichert, der als einer oder mehrere Speicherserver implementiert sind. An diese Server wird im Sinne der Erfindung nur die Anforderung gestellt, dass sie Datenpakete unter einer Adresse (URL) ablegen und über die gleiche Adresse auch den Abruf ermöglichen. Um sicherzustellen, dass Nutzer für den von ihnen ausgelösten Speicherverbrauch auch berechtigt sind, geschieht das Ablegen und Abrufen in der Regel über eine Nutzerkennung, die auch das abgelegte Datenpaket wieder dem Nutzer zuordenbar werden lässt. Vorzugsweise sind deshalb auf verschiedenen Speicherservern verschiedene Accounts (Nutzerkennungen) zu verwenden, die nicht der Nutzerkennung des Autorisierungsservers gleichen. Die Nutzerkennungen und verfügbaren Speicherserver sind Bestandteile der Konfiguration des jeweiligen Distributor-Moduls.
Ausführungsformen
Die vorliegende Erfindung wird im Folgenden unter Bezugnahme auf die begleitende Zeichnung weiter erläutert. Es zeigt
1 ein Diagramm, das die Modulstruktur zur Erzeugung eines Schlüsselpaares und die sichere Speicherung des privaten Schlüssels gemäß dem erfindungsgemäßen Verfahren darstellt,
2 ein Diagramm, das die Weitergabe eines privaten Schlüssels einer Gruppe an ein neues Gruppenmitglied gemäß dem erfindungsgemäßen Verfahren darstellt,
3 ein Diagramm, das die Modulstruktur zur Verschlüsselung und Speicherung von Nutzerdaten eines Nutzerendgeräts gemäß dem erfindungsgemäßen Verfahren darstellt,
4 ein Diagramm, das die Modulstruktur zur Entschlüsselung und das Wiederabrufen der gespeicherten, verschlüsselten Nutzerdaten gemäß dem erfindungsgemäßen Verfahren darstellt, und
5 ein Diagramm, das die Modulstruktur zur Behandlung von telematischen (= kleinteiligen) Nutzerdaten gemäß dem erfindungsgemäßen Verfahren darstellt.
Bei einer bevorzugten Ausführungsform wird das erfindungsgemäße Verfahren als ein modulares Computerprogramm in einer Cloud-Umgebung implementiert. Ferner kann der Autorisierungsserver, der Verzeichnisserver und der Schlüsselserver auf einem oder mehreren Rechnern in einem vorzugsweise nicht-öffentlichen Rechnernetz implementiert sind.
Die Cloud-Umgebung weist unter anderem einen externen Speicher auf, beispielsweise eine Cloud-Speichervorrichtung, auf den durch eine oder mehrere Nutzerendgeräte über ein Netzwerk, beispielsweise das Internet, zugegriffen werden kann, um darauf Nutzerdaten zu speichern und wieder abzurufen, sowie ein nicht öffentliches Rechnernetz des Nutzers, auf dem der Nutzer Daten eines Nutzerendgeräts nicht öffentlich und separat zu der Cloud-Speichervorrichtung speichern kann. Die Cloud-Speichervorrichtung kann beispielsweise ein Rechenzentrum mit vielen tausend Servern sein oder auch aus mehreren Rechenzentren bestehen, die untereinander kommunikativ verbunden sind. Das nicht öffentliche Rechnernetz kann beispielsweise ein Intranet des Nutzers oder einer Nutzergruppe sein und kann unter anderem einen Autorisierungsserver, Verzeichnisserver und einen Schlüsselserver enthalten.
Die Speicherung der Daten auf öffentlichen Servern, während die strukturelle Verzeichnisinformation auf einem nicht-öffentlichen Server (Verzeichnisserver) abgelegt wird, birgt die folgenden Vorteile:

– Die im öffentlichen Bereich gespeicherten Datenpakete D_n sind deutlich umfangreicher als die Verzeichnisinformation im nicht-öffentlichen Bereich, ohne diese völlig nutzlos, da ohne Zugang zu den Zugriffscodes praktisch unentschlüsselbar, da sowohl die Inhalte verschlüsselt sind, als auch die Zugehörigkeit von Teildatensätzen zu einer Datei nicht mehr bekannt ist.
– Damit kann eine Speicherung auf öffentlichen, redundanten Servern, wie sie von verschiedenen Anbietern auf dem Markt gemietet werden können, erfolgen, ohne Abstriche bei der Sicherheit der Speicherung zu machen.

Ist diese Stufe der Sicherheit nicht notwendig oder nicht gewünscht, kann der oben als nicht-öffentlich beschriebene Teil ebenfalls im öffentlichen Bereich (Internet statt Intranet) liegen.
Im Folgenden wird die bevorzugte Ausführungsform anhand der 1 bis 4 beschrieben, und im Anschluss anhand 5 eine weitere bevorzugte Ausführungsform für telematische (kleinteilige) Datensätze.
Authentifizierung (Fig. 1)
Zunächst wird anhand von 1 die Schlüsselverwaltung asymmetrischer Schlüsselpaare und damit die Authentifizierung beschrieben, die wie bereits oben erwähnt, häufig einen Schwachpunkt darstellt. Zum einen ist die Verwaltung – insbesondere bei mehreren Schlüsseln – mit einem hohen Aufwand verbunden. Zum anderen besteht immer die Gefahr des Schlüsselverlustes und damit des Verlustes aller damit verschlüsselten Daten. In der vorliegenden Erfindung wird der Schlüssel mit Hilfe des Dekombinierers geteilt und verschlüsselt. Jeder dieser Teile erhält nun für sich keine Information mehr.
Einer der Teile wird auf einem Server abgelegt und mit einem Passwort gesichert, ähnlich wie es heute bei Cloud-Diensten der Fall ist. Da dieses Passwort nur der Zugangskontrolle dient und keine Auswirkung auf die Verschlüsselung der Daten (in diesem Fall: des Teilschlüssels) hat, lässt sich bei entsprechender Authentifizierung über z. B. Empfang einer SMS oder einen per Mail empfangenen Recovery-Link das Passwort bei Verlust auch neu setzen, wobei die Daten des Teilschlüssels erhalten bleiben. Der zweite Teil des Schlüssels verbleibt beim Nutzer und kann auf jedem Endgerät abgelegt werden. Zur Laufzeit des Systems kann die jeweils aktive Version der Software den privaten Schlüssel über einen passwortgesicherten Abruf vom Server wiederherstellen. Dieser Schlüssel darf dann allerdings auf dem Endgerät nicht persistieren, muss also entweder beim Ausschalten des Systems oder nach einiger Zeit der Inaktivität des Nutzers vernichtet werden.
Die Aufsicht über den Teil des Schlüssels, der beim Nutzer verbleibt, liegt beim Nutzer selber. Er kann allerdings beispielsweise an einen Treuhänder weitergegeben werden, der diesen zweiten Teil auf einem nicht an das Internet angebundenen Rechner verwahrt, für den Fall, dass tatsächlich sämtliche Versionen des zweiten Schlüsselteils verloren gegangen sind. Wichtig bei der Speicherung ist nur, dass die beiden Teilschlüssel niemals auf einem einzigen System unter Verlinkung über den Nutzeraccount gespeichert werden (da ansonsten der private Schlüssel auch durch Dritte wieder hergestellt werden könnte).
Wie in 1 gezeigt, kann ein Nutzerendgerät die Module Schlüsselpaar-Generator und Dekombinierer enthalten. Das Modul Schlüsselpaar-Generator erzeugt einen privaten Schlüssel prK und einen öffentlichen Schlüssel puK. Der öffentliche Schlüssel puK wird dann extern auf dem vorstehend beschriebenen Autorisierungsserver gespeichert. Dieser Autorisierungsserver kann beispielsweise auf einen Rechner eines Intranets des Nutzers implementiert sein.
Das Modul Dekombinierer erzeugt aus dem Datensatz des privaten Schlüssels prK zusammen mit einer Zufallsfolge ΔA wie oben beschrieben zwei rekombinierbare Teildatensätze prK + ΔA und –ΔA. Vorzugsweise verbleibt der Teildatensatz prK + ΔA auf dem Nutzerendgerät, während der Teildatensatz –ΔA extern gespeichert wird, vorzugsweise auf dem Autorisierungsserver. Der im Schlüsselpaar-Generator ursprünglich erzeugte private Schlüssel wird danach vorzugsweise vernichtet.
Gruppenverwaltung von Schlüsseln (Fig. 2)
Sollen sicher gespeicherte Daten an eine oder mehrere Gruppen freigegeben werden ist dies mit herkömmlichen Methoden aufwändig und umständlich, da für jeden einzelnen zu berechtigenden Nutzer ein Zugriffsschlüssel (K*) erzeugt werden müsste, bzw. birgt als Risiko die Kompromittierung der Sicherheit von nicht freigegebenen Daten, wenn auf die Verschlüsselung verzichtet, oder nicht für jeden Datensatz ein eigener Schlüssel gewählt wird.
In der vorliegenden Erfindung können Gruppenfreigaben über ein gemeinsames Schlüsselpaar erfolgen. Alle zu verschlüsselnden Daten werden wie gehabt mittels des öffentlichen Schlüssels puK der Gruppe verschlüsselt.
Alle Gruppenmitglieder besitzen nur einen Teil des privaten Gruppenschlüssels (wie oben beschrieben), der zweite Teil ist jeweils auf dem Autorisierungsserver gespeichert. Bei der Weitergabe des privaten Schlüssels eines Nutzers A an ein neues Mitglied B modifiziert der weitergebende Nutzer A seinen Schlüsselteil mittels einer Zufallsfolge (ähnlich wie im Dekombinierer). Diesen modifizierten Teil sendet er direkt an das neue Gruppenmitglied B. Gleichzeitig sendet A die Zufallsfolge selber an den Autorisierungsserver. Dieser prüft, ob das aktuelle Mitglied A zur Weitergabe des Schlüssels berechtigt ist, und fügt das neue Mitglied B der Gruppe hinzu. Hierzu wird auf dem Autorisierungsserver auch der zweite Teil des privaten Schlüssels von A durch die Zufallsfolge modifiziert, und dem Account von B hinzugefügt. Da kein Nutzer die privaten Schlüssel selber persistent auf einem Gerät besitzt, kann einem Nutzer auch nachträglich die Gruppenmitgliedschaft wieder entzogen werden, durch Löschen des zweiten Schlüsselteils auf dem Autorisierungsserver, so dass der Nutzer mit seinem Schlüsselteil nichts mehr anfangen kann.
Wie in 2 gezeigt, kann ein Nutzerendgerät von Nutzer A das Modul Dekombinierer enthalten. Das Modul erhält als Eingangsgröße den Teil des privaten Gruppenschlüssels prK + ΔA, den Nutzer A bei sich verwaltet. Als Ergebnis erzeugt der Dekombinierer aus dem privaten Schlüsselteil zusammen mit einer Zufallsfolge ΔB wie oben beschrieben zwei rekombinierbare Teildatensätze prK + ΔA + ΔB und –ΔB.
Vorzugsweise wird der eine Teil prK + ΔA + ΔB direkt an das Endgerät von Nutzer B verschickt. Der zweite Teil –ΔB wird vorzugsweise an den Autorisierungsserver verschickt zusammen mit der Anforderung, Nutzer B in die Gruppe hinzuzufügen. Der Autorisierungsserver kann das Modul Rekombinierer enthalten. Der Teil –ΔB wird über den Rekombinierer zusammen mit dem Teil –ΔA zu –ΔA – ΔB und vorzugsweise den Nutzerdaten von Nutzer B hinzugefügt. Damit erhält Nutzer B nun ebenfalls Zugriff auf die für die Gruppe abgelegten Daten in der Cloud-Umgebung, da die beiden Teile prK + ΔA + ΔB und –ΔA – ΔB sich zueinander genauso verhalten wie die ursprünglichen Anteile prK + ΔA und –ΔA des Nutzers A.
Cloud-Speicherung (Fig. 3)
3 zeigt die erfindungsgemäße Verschlüsselung und die Speicherung der Nutzerdaten D gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung.
Wie in 3 gezeigt, kann das Nutzerendgerät weiter die Module Schlüsselgenerator, Metadaten-Generator, Enkryptor und Distributor enthalten. Zunächst durchlauft das Datenpaket D den Metadaten-Generator, um eine Reihe von Merkmalen M aus dem Datensatz zu extrahieren, die später im Verzeichnisspeicher suchbar und sichtbar sein sollen. Zu diesen Daten können gehören Dateiname, -typ, -größe der Daten D; das Speicherdatum; eine hierarchische Beziehung des Datensatzes D zu anderen gespeicherten Daten; eine Referenz auf eine Vorgängerversion des Datensatzes; verschiedentliche in den Daten abgelegte Zusatzinformationen (z. B. Tags eines JPEG-Grafikdatei, die u. a. GPSKoordinaten und Belichtungszeit enthalten können).
Das Modul Schlüsselgenerator liefert einen symmetrischen Schlüssel K, mit dem im Modul Enkryptor die Nutzerdaten D zu D* verschlüsselt werden. Der symmetrische Schlüssel K wird nach konfigurierbaren Regeln im Schlüsselgenerator erzeugt und kann dann abgefragt werden. In einer bevorzugten Ausführungsform wird K mit jedem Datensatz D neu erzeugt. In einer alternativen Ausführungsform geschieht dies in zeitlichen Intervallen, wie beispielsweise. alle vier Wochen.
Der Schlüssel K wird bei Neuerzeugung durch das Modul Schlüsselgenerator vorzugsweise mit dem öffentlichen Schlüssel puK als K* verschlüsselt und an einen Schlüsselspeicher weitergereicht, der beispielsweise auf einem Rechner (Schlüsselserver) im Intranet des Nutzers implementiert sein kann, und dort gespeichert, zusammen mit der Information, für welche Daten (d. h. für welches Datum oder für welchen Datensatz) er Gültigkeit besitzt. Diese Information kann in Teilen aus einer eindeutigen Datensatz-ID (UUID) bestehen, die mit Eingang der Daten D in das System erzeugt wurde, und aus Metadaten wie z. B. dem Speicherdatum, falls der Schlüssel zeitabhängig, nicht dateiabhängig, neu generiert wird.
Das Modul Distributor zerlegt die verschlüsselten Nutzerdaten D* in die Datenpakete D1*, D2*, ..., Dn*, verteilt sie auf beliebige Speicherserver und erstellt einen Zugriffskode AC. Das Modul Distributor verschlüsselt vorzugsweise den Zugriffskode AC ebenfalls mit internen Schlüssel K und der verschlüsselte Zugriffskode AC* wird vorzugsweise an einen Verzeichnisspeicher geschickt, der beispielsweise auf einem Rechner (Verzeichnisserver) im Intranet des Nutzers implementiert sein kann, und dort zusammen mit den Metadaten M gespeichert. In alternativen Ausführungsformen kann AC auch unverschlüsselt weitergegeben oder mit dem öffentlichen Schlüssel puK des Nutzers verschlüsselt werden. Wie zuvor besprochen, ist der Ort, an dem Verzeichnisspeicher und Schlüsselspeicher betrieben werden, unter Umständen ebenfalls wichtig für die Sicherheit, falls durch die Kompromittierung der Metadaten M bereits Schaden entstehen kann. Für ein Unternehmen lägen daher beide Module auf einem jeweils eigenständigen Verzeichnisserver und Schlüsselserver zweckmäßigerweise in einem nicht öffentlichen Rechnernetz, d. h. einem Intranet. Die im Intranet gespeicherten Datenmengen sind auch deutlich kleiner als die in der Cloud gespeicherten Datenvolumina, so dass keine besondere Anforderungen an die Speicherkapazität des Intranetzes besteht. Die Daten aus dem Distributor, welche das Volumen ausmachen, können auf beliebigen (auch unsicheren) öffentlichen Servern einer Cloud gespeichert werden. Eine alternative Ausführungsform würde Verzeichnisspeicher oder Schlüsselspeicher auf einem Nutzer-Endgerät halten, um die Zugriffsmöglichkeiten von außen noch weiter einzuschränken. Eine weitere alternative Ausführungsform verzichtet auf den Metadaten-Generator und legt lediglich die eindeutige ID des Datensatzes auf dem Verzeichnisspeicher ab. In dieser Ausführungsform enthält M dann nur noch die ID.
Abruf von Daten aus der Cloud (Fig. 4)
4 zeigt das erfindungsgemäße Wiederabrufen der in der Cloud-Speichervorrichtung gespeicherten Nutzerdaten D* gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung.
Wie in 4 gezeigt, kann das Nutzerendgerät weiter die Module Rekombinierer, Dekryptor und Retriever enthalten. Das Modul Rekombinierer bezieht die beiden rekombinierbaren Teildatensätze prK + ΔA und –ΔA vom Nutzerendgerät und vom Autorisierungsserver und rekombiniert sie zu dem Datensatz des privaten Schlüssels prK. Zum Abrufen des Teildatensatzes –ΔA kann optional zuvor eine Authentifizierung des Nutzers an dem Autorisierungsserver erfolgt sein. Der private Schlüssel wird nun im Modul Dekryptor zum Entschlüsseln des im Schlüsselserver gespeicherten, verschlüsselten symmetrischen Schlüssel K* benutzt. Der dann vorliegende symmetrische Schüssel K kann zum Entschlüsseln des im Verzeichnisserver gespeicherten, verschlüsselten Zugriffskode AC* verwendet werden. Der entschlüsselte Zugriffskode AC wird dann an das Modul Retriever geschickt, welches damit die gespeicherten Nutzerdatenpakete D1*, D2*, ..., Dn* aus der Cloud-Speichervorrichtung abrufen, dann zu den verschlüsselten Nutzerdaten D* zusammensetzen und im Anschluss an das nachfolgende Modul Dekryptor zum Entschlüsseln schicken kann. Im nachfolgenden Modul Dekryptor werden die verschlüsselten Nutzerdaten D* dann mit Hilfe des symmetrischen Schlüssels K entschlüsselt und stehen zur weiteren Verwendung durch das Nutzerendgerät bereit.
Die Schritte des Wiederabrufens und Zusammensetzen der verteilt gespeicherten Nutzerdatenpakete D1*, D2*, ..., Dn* durch das Modul Retriever und des Rekombinierens der rekombinierbaren Teildatensätze prK + ΔA und –ΔA vom Nutzerendgerät und vom Autorisierungsserver durch das Modul Rekombinierer können dabei in beliebiger zeitlicher Abfolge ausgeführt werden, insbesondere gleichzeitig.
Speicherung kleinteiliger (telematischer) Datensätze (Fig. 5)
Im Bereich telematischer Daten sind die einzelnen erhobenen Datensätze deutlich kleiner als die für eine Cloud-Speicherung üblicherweise vorgesehenen Daten (wie Bilder, Musik, Videos). Bei einer Speicherung solcher kleinteiliger Datensätze, die wie oben beschrieben, beispielsweise von einem telematischen Gerät oder einem Sensor eines Smart Device erzeugt werden, würde eine Reihe von Nachteilen entstehen, da die zur Verwaltung auf Verzeichnis- und Schlüsselserver notwendige Datenmenge die eigentlichen Nutzdaten mengenmäßig deutlich übersteigen würde. Hierfür ist es vorzuziehen, dass der Enkryptor bzw. der Schlüsselgenerator, wie oben erwähnt, nicht pro Datensatz sondern abhängig vom Datum einen neuen Schlüssel verwenden bzw. erzeugen sollte, da in diesem Fall nur ein Schlüssel pro Zeitraum für andere berechtigte Nutzer freigegeben werden muss. Üblicherweise sind telematische Daten auch nur aufgrund ihrer Menge ein Sicherheitsproblem; der einzelne Datensatz ist in der Regel wenig aufschlussreich.
Nimmt man jedoch an, dass die telematischen Daten von einer Vielzahl an Sensoren erzeugt werden, und diese Sensoren auf unterschiedlichsten Endgeräten lokalisiert sind, so müsste jeder einzelne Sensor einen eigenen Enkryptor, und damit einen eigenen Schlüsselkreis besitzen. Dies wäre eine mögliche Realisierung. Für die Kombinierung der unterschiedlichsten Sensordaten über einen gemeinsamen zeitbezogenen Schlüssel ist es jedoch notwendig, dass der Enkryptor nicht mehr auf dem Gerät lokalisiert ist, das die Daten erhebt (also dem Sensor), sondern über ein Netzwerk zugreifbar ist; ansonsten müsste eine Vielzahl von Enkryptoren auf verschiedenen Endgeräten den gleichen internen Schlüssel K verwenden, was dessen Sicherheit wiederum kompromittieren würde. Ein Versenden unverschlüsselter telematischer Daten an einen Rechner im Internet, auf dem ein Enkryptor läuft, ist jedoch aus sicherheitstechnischen Aspekten abzulehnen, da diese Daten auf dem empfangenden Rechner zunächst unverschlüsselt vorlägen; durch eine Manipulation dieses Rechners (der außerhalb des direkten Zugriffsbereichs des Nutzers läge, womit eine Manipulation schwer nachzuweisen wäre) könnten diese Daten dauerhaft mitgelesen werden.
5 zeigt eine Ausführungsform der Cloud-Umgebung, die die sichere Speicherung von telematischen Daten eines Nutzers ermöglicht. Diese telematischen Daten werden beispielsweise von einem in dem Nutzerendgerät integrierten oder damit koppelbaren Smart Device mit Sensor erzeugt, wie zuvor beschrieben.
Wie in 5 gezeigt, ist in dem telematischen Endgerät mindestens eine Kombination der Module Dekombinierer und Metadatengenerator implementiert. Der Metadatengenerator erzeugt eine minimale Zahl von Metadaten aus dem Datenpaket (wie z. B. um welche Art von Datum es sich handelt; bspw. ein Bezahlvorgang, ein GPS-Bewegungsprofil, o. ä.), sowie eine eindeutige ID (in Art einer UUID) der Daten. Die Daten selber werden im Dekombinierer in zwei Pakete tD + ΔD und –ΔD zerlegt. Dies geschieht, um die telematischen Daten tD so zu verändern, dass sie auf weiteren externen Servern nicht unverschlüsselt vorliegen. Diese zwei Pakete tD + ΔD und –ΔD werden jeweils über eine Modulstruktur der Cloud-Speicher Lösung und über sichere Kanäle (bspw. TLS) an zwei unabhängige externe Systeme zur Speicherung weitergegeben. Die Schlüssel der Enkryptoren werden vorzugsweise in einem zeitlichen Abstand neu generiert (und nicht mit jedem Datensatz), und zwar vorzugsweise z. B. alle vier Wochen, wobei der Generierungszeitpunkt von einem Enkryptor des einen Servers zu dem des anderen Servers um zwei Wochen versetzt ist. Da sich die originalen Daten nur dann wieder herstellen lassen, wenn beide gespeicherten Teilpakete entschlüsselt werden können, lassen sich Daten genau über zweiwöchige Intervalle freigeben (d. h. ein späterer Verwender kann mit einem freigegeben Schlüsselpaar genau nur Daten in einem zweiwöchigen Zeitraum entschlüsseln).
Die Distributoren der beiden unabhängigen Systeme in 5 kennen sich dabei gegenseitig nicht, liefern den erzeugten Zugriffskode jedoch an ein- und denselben Verzeichnisserver, der auch vom Smart Device bzw. vom Nutzerendgerät sowohl die Metadaten als auch die ID der Daten erhält. Über die ID im Zugriffskode können diese drei Pakete zu einem Verzeichniseintrag zusammengefügt werden. Die jeweils neu erzeugten Schlüssel K aus den Cloud-Speicher Modulstrukturen werden jeweils mit dem öffentlichen Schlüssel puK des Nutzers verschlüsselt und anschließend im Schlüsselserver gespeichert.
Weitere Anwendungsbeispiele
Die vorliegende Erfindung ermöglicht eine sichere Verwaltung des privaten Schlüssels, ohne dass ein Dritter Zugriff auf den Schlüssel erhält, die Regenerierung des Schlüssels im Falle eines Verlustes, sowie die Verteilung des privaten Schlüssel so über mehrere Endgeräte, dass die Sicherheit des privaten Schlüssels selbst beim Verlust eines Endgerätes nicht kompromittiert wird, siehe den Abschnitt über Authentifizierung weiter oben.
Die vorliegende Erfindung ermöglicht weiters die Erstellung und den Betrieb eines sicheren sozialen Netzwerkes (sicheres FaceBook); hier ist die Besonderheit, dass Daten (eingestellte Dokumente, Kurzkommentare oder Bilder) einer ganzen Gruppe von Mitgliedern gleichzeitig zugänglich gemacht werden soll. Dies ist über die Gruppenschlüssel-Funktionalität (s. oben) auf einfache Art sichergestellt. Die Inhalte sind dann auch nur den Gruppenmitgliedern sichtbar, nicht dem Dienstanbieter, wie es beim heutigen Facebook der Fall ist. Gegenüber einer Lösung wie SnapChat, bei der die „Sicherheit” einfach durch ein schnelles Löschen garantiert werden soll (d. h. Beiträge besitzen eine sehr limitierte Lebensdauer) können hier Inhalte beliebig lange sicher aufbewahrt und gezielt geteilt werden.
Aufgrund des inhärenten Sicherheitsniveaus der Anwendung lassen sich mittels Cloud-Ansatz auch hochsensible Daten, wie sie beispielsweise im Gesundheitswesen entstehen, auf unsicheren/öffentlichen Servern ablegen. Hiermit ließen sich Anwendungsfelder wie beispielsweise das Gesundheitswesen erschließen. In Deutschland scheiterte bislang die Einführung einer Gesundheitskarte, die weitergehende gesundheitliche Details des Patienten speichern könnte, an Sicherheitsbedenken der Politik bzw. der Bevölkerung. In dem vorgestellten Cloud-System mit individueller Verschlüsselung einzelner Datensätze könnten diese Bedenken ausgeräumt werden:

– Gesundheitsdaten würden nicht auf der Karte des Patienten, sondern vom Arzt jeweils über einen Enkryptor/Distributor im Netz abgelegt.
– Daten könnten z. B. auch direkt in der behandelnden Einrichtung (z. B. Krankenhaus) auf eigenen Servern abgelegt werden, die Lesezugriff aus dem Internet erlauben.
– Der private Schlüssel könnte vorzugsweise auf der Gesundheitskarte des Patienten abgelegt werden. In diesem Fall können Daten nur genau dann gelesen und entschlüsselt werden, wenn die Karte dem Lesenden physikalisch vorliegt.

Das vorgestellte System erlaubt eine vollständige Trennung der Speichersicherheit von Daten und des Inhaltes von Daten. Zur Speichersicherheit werden üblicherweise hochredundante Systeme eingesetzt, damit Daten auch bei Ausfall eines Teilsystems noch gelesen werden können. Um den Inhalt der Daten geheim zu halten, müssen die speichernden Systeme üblicherweise mit weiteren Sicherheitsmerkmalen ausgerüstet werden. Insbesondere die redundante Speicherung, also die Vervielfachung der Daten, ist in der Regel konträr zur Geheimhaltung der Daten. So kann auch in einem hochsicheren Datencenter bei Tausch einer defekten Festplatte prinzipiell ein Teil des Platteninhaltes öffentlich werden, wenn diese nicht vorher speziell gelöscht wurde.
In dem vorgestellten System jedoch hat ein speicherndes System niemals Kenntnis vom Inhalt der gespeicherten Daten. Der Inhalt erschließt sich nur genau dem Eigentümer des verwendeten privaten Schlüssels. Der Vorteil liegt darin, dass selbst bei fehlerhafter Software auf den Servern (Sicherheitslücken wie z. B. Heartbleed) niemals Zugangsdaten oder Inhalte öffentlich werden können.
Gemäß der vorliegenden Erfindung kann das System streng zwischen dem Dateninhalt und Metadaten trennen, wobei selbst Dateiname, Dateityp, sowie Dateigröße zu den Metadaten gezählt werden. Inhalte werden verschlüsselt ohne Bezug auf den Dateinamen/-typ, und ggf. sogar zerlegt in unabhängige Teilpakete auf einem System mehrerer Server gespeichert. Eine Rekonstruktion der ursprünglichen Dateien, oder auch nur der Metadaten ist selbst mittels Zugriff auf die speichernden Server nicht möglich. Ein Vorteil gegenüber bestehenden Systemen besteht also darin, dass selbst bei einer vollständigen Kenntnis des Kommunikationsflusses zwischen Nutzer und Server durch einen Dritten Daten weder Inhalt noch beschreibende Daten jemals entschlüsselt werden können.
Das System erlaubt im Gegensatz zu bestehenden Systemen – ohne zusätzlichen Administrationsaufwand des Nutzers – die

– Speicherg von Daten als per se unlesbare bzw. inhaltslose Datenpakete un
– Verteilung der Datenpakete auf eine Vielzahl primär unbekannter Datenspeicher
– Beibehaltung der absoluten Datenhoheit bei optionaler gleichzeitiger Änderungsresistenz der Daten
– Möglichkeit der Datenpaket spezifischen (nicht an Rechte innerhalb eines Dateisystems gebundenen) Freigabe ohne die Sicherheit anderer Datenpakete durch die Weitergabe des Schlüssels zu gefährden
– Erhaltung der Datensicherheit selbst bei Kompromittierung eines oder mehrerer Datenspeicher
– Möglichkeit die volumenträchtigen Datenanteile auf unsicherem (kostengünstigem) Speicherplatz zu speichern.

Die Erfindung bietet hinsichtlich der Nutzerdatenverwaltung innerhalb einer Cloud-Umgebung die

– Unabhängigkeit von der Vertrauenswürdigkeit des Dienst-Anbieters
– Möglichkeit den privaten Schlüssel zur Verschlüsselung der Daten zu verwenden, ohne sich selbst um die Verschlüsselung bzw. Entschlüsselung und die Aufbewahrung und Zuordnung der Schlüssel kümmern zu müssen,
– gezielte Freigabe einzelner Datenpakete ohne die Sicherheit weiterer Datenpakete zu gefährden
– Aufbewahrung des privaten Schlüssels ohne Dritten einen potentiellen Zugriff auf diesem zu geben
– Möglichkeit den privaten Schlüssel sicher auf mehrere Endgeräte zu verteilen
– Rekonstruktionsmöglichkeit im Verlustfall ohne Dritten den potentiellen Zugriff auf den privaten Schlüssel gegeben zu haben

Die Erfindung bietet hinsichtlich der Verwaltung von telematischen Nutzerdaten die Vorteile einer

– Verschlüsselung der entstandenen Daten ohne der Verschlüsselungssicherheit (insbesondere der Sicherheit des implementierten Zufallszahlengenerators) im Daten erzeugenden Gerät vertrauen zu müssen, da die eigentliche Verschlüsselung auf einem weiteren Rechner erfolgt
– sicheren Speicherung der entstehenden Daten mit ggf. Freigabemöglichkeit an Dritte über die Freigabe der Schlüssel eines bestimmten Zeitraums, und
– Garantie, dass die Daten nicht durch den Nutzer (Eigentümer der Daten) verändert worden sind

Die Erfindung ist jedoch nicht auf die konkret beschriebene Ausführungsform beschränkt. Vielmehr sind Abwandlungen hinsichtlich der Reihenfolge von Verfahrensschritten und Modul- und/oder Rechnerstruktur denkbar, ohne den Schutzbereich der beigefügten Ansprüche zu verlassen. Beispielsweise können manche Module auch in einem anderen integriert implementiert sein. Die Rechnereinheiten Autorisierungsserver, Verzeichnisserver und Schlüsselserver wurden als auf eigenständigen Rechnersystemen in einem Intranet oder im Internet implementiert beschrieben. Grundsätzlich können diese Einheiten sich aber auf jeder Art von Rechengerät befinden, das im Zugriff und unter der Kontrolle des Nutzers steht, unter anderem auch auf Endgeräten des Nutzers.

Claims

Verfahren zum Verwalten von Nutzerdaten eines Nutzerendgeräts, wobei das Verfahren folgende Schritte aufweist: – Erzeugen eines Schlüsselpaars aus privaten Schlüssel prK und öffentlichen Schlüssel puK, – Aufteilen des privaten Schlüssels prK in mindestens zwei Teildatensätze, wobei die mindestens zwei Teildatensätze mittels einer bijektiven Operation rekombinierbar erzeugt werden und die Transinformation I jedes der mindestens zwei Teildatensätze 0 ≤ I ≤ 2^–|prK| erfüllt, wobei |prK| die Zahl der Bits des privaten Schlüssels prK bezeichnet, – Verschlüsseln von Nutzerdaten D und Speichern der verschlüsselten Nutzerdaten D* in einer über ein Netzwerk zugänglichen externen Speichervorrichtung, und – Wiederabrufen und Entschlüsseln der verschlüsselt gespeicherten Nutzerdaten D* aus der externen Speichervorrichtung, wobei das Wiederabrufen und Entschlüsseln ein Wiederherstellen des privaten Schlüssels prK durch Rekombinieren der beiden Teildatensätze mittels der zum Aufteilen inversen bijektiven Operation aufweist.
Verfahren nach Anspruch 1, wobei das Verschlüsseln von Nutzerdaten D ferner folgende Schritte aufweist: – Erzeugen eines symmetrischen Schlüssels K, und – Verschlüsseln der Nutzerdaten D mit dem symmetrischen Schlüssel K.
Verfahren nach Anspruch 1 oder 2, wobei das Speichern von Nutzerdaten D ferner aufweist: – Zerlegen und verteiltes Speichern der verschlüsselten Nutzerdaten D* in der externen Speichervorrichtung und – Erzeugen eines Zugriffskodes AC.
Verfahren nach Anspruch 3, wobei das Wiederabrufen und Entschlüsseln der verteilt gespeicherten, verschlüsselten Nutzerdaten D* ferner aufweist: – Abrufen des gespeicherten Zugriffskode AC, – Abrufen der verteilt gespeicherten verschlüsselten Nutzerdaten D* mit Hilfe des Zugriffskode AC, und – Wiederherstellen der Nutzerdaten D durch Entschlüsseln der verschlüsselten Nutzerdaten D* mit dem symmetrischen Schlüssel K.
Verfahren nach Anspruch 4, das ferner ein Verschlüsseln des Zugriffskodes AC mit dem symmetrischen Schlüssel K, ein Speichern des verschlüsselten Zugriffskode AC* und ein Entschlüsseln des Zugriffskodes AC mit dem symmetrischen Schlüssel K aufweist
Verfahren nach einem der Ansprüche 1 bis 5, wobei die Nutzerdaten D kleinteilige Datensätze tD eines telematischen Geräts sind, die mittels einer bijektiven Operation in mindestens zwei Teildatensätze derart aufgeteilt werden, dass die mindestens zwei Teildatensätze miteinander rekombinierbar verknüpft sind.
Verfahren nach einem der Ansprüche 1 bis 6, das ferner vor dem Speichern der Nutzerdaten D ein Extrahieren von Metadaten aus den Nutzerdaten aufweist.
Verfahren nach einem der Ansprüche 1 bis 7, das vor dem Wiederherstellen des privaten Schlüssels prK ferner ein Authentifizieren des Nutzers vorsieht.
Verfahren nach einem der Ansprüche 2 bis 8, wobei der symmetrische Schlüssel K erst nach Ablauf einer vorbestimmten Zeitdauer neu erzeugt wird.
Verfahren nach einem der Ansprüche 2 bis 9, das ferner ein Verschlüsseln des symmetrischen Schlüssels K mit dem öffentlichen Schlüssel puK und ein Entschlüsseln des verschlüsselten symmetrischen Schlüssel K* mit dem privaten Schlüssels prK aufweist.
Verfahren nach einem der Ansprüche 1 bis 10, das ferner zur Verwaltung von Nutzergruppen zumindest eine weitere Aufteilung des privaten Schlüssels prK mittels einer weiteren bijektiven Operation vorsieht.
System zum Verwalten von Nutzerdaten eines Nutzerendgeräts, wobei das System aufweist: • mindestens ein Nutzerendgerät • mindestens eine externe Speichervorrichtung, auf die das mindestens eine Nutzerendgerät über ein vorzugsweise öffentliches Netzwerk zugreifen kann, um darauf Nutzerdaten, die von dem mindestens einem Nutzerendgerät erzeugt werden, zu speichern und wieder abzurufen, und • eine Mehrzahl an mit einander kommunizierenden Modulen, wobei die Mehrzahl an Modulen zum Ausführen eines Verfahrens nach Anspruch 1 zumindest aufweist: – einen Schlüsselpaar-Generator, der konfiguriert ist, ein Schlüsselpaar aus privaten Schlüssel prK und öffentlichen Schlüssel puK zu erzeugen; – einen Dekombinierer, der konfiguriert ist, den privaten Schlüssel prK in mindestens zwei Teildatensätze aufzuteilen, wobei die mindestens zwei Teildatensätze mittels einer bijektiven Operation rekombinierbar erzeugt werden und die Transinformation 1 jedes der mindestens zwei Teildatensätze 0 ≤ I ≤ 2^–|prK| erfüllt, wobei |prK| die Zahl der Bits des privaten Schlüssels prK bezeichnet, – einen Enkryptor und einen Distributor, die konfiguriert sind, die Nutzerdaten zu verschlüsseln und die verschlüsselten Nutzerdaten D* in der externen Speichervorrichtung zu speichern, – einen Rekombinierer, einen Retriever und einen Dekryptor, die konfiguriert sind, die verschlüsselt gespeicherten Nutzerdaten D* aus der externen Speichervorrichtung wiederabzurufen und zu entschlüsseln, wobei das Wiederabrufen und Entschlüsseln ein Wiederherstellen des privaten Schlüssels prK durch Rekombinieren der beiden Teildatensätze mittels der zum Aufteilen inversen bijektiven Operation aufweist.
System nach Anspruch 12, das zum Ausführen eines Verfahrens nach den Ansprüchen 2 bis 11 ferner ein Modul Schlüsselgenerator und einen Schlüsselserver aufweist.
System nach Anspruch 12 oder 13, das ferner einen Autorisierungsserver aufweist.
System nach einem der Ansprüche 12 bis 14, das ferner einen Verzeichnisserver aufweist.
System nach Anspruch 15, wobei der Autorisierungsserver, Schlüsselserver und der Verzeichnisserver auf einem oder mehreren Rechnern implementiert sind, der/die sich in einem vorzugsweise nicht öffentlichen Rechnernetz des Nutzers befindet/befinden.
System nach einem der vorhergehenden Ansprüchen 12 bis 16, das ferner ein Modul Metadatengenerator zum Extrahieren von Metadaten aus den Nutzerdaten aufweist.
System nach einem der vorhergehenden Ansprüchen 12 bis 17, wobei das mindestens eine Nutzerendgerät ein telematisches Gerät ist, das kleinteilige Datensätze erzeugt, und ferner zum Ausführen eines Verfahrens nach Anspruch 7 zwei unabhängige externe Server aufweist.