510 DuD Datenschutz und Datensicherheit 7 | 2012

SCHWERPUNKT

Einleitung

Cloud Computing ist ein aufstrebender Markt und wird als rich-tungsweisende Technologie für die Verwaltung von Daten sowie die Nutzung von Software und Diensten im Internet betrachtet. Jüngste Umfragen des Marktforschungs- und Beratungsunter-nehmens Gartner prognostizieren bis zum Jahr 2014 eine Stei-gerung des Umsatzes durch Cloud-Dienste auf 148,8 Milliarden US-Dollar. Besonders attraktiv ist dieser Ansatz durch die Mög-lichkeit, dynamisch Ressourcen zu allokieren und so eine hohe Skalierbarkeit zu erreichen.

Zudem wird das damit verbundene Bezahlmodell im Allgemei-nen so gestaltet, dass Kunden eines Cloud Providers ausschließlich diejenigen Ressourcen bezahlen, die Sie auch tatsächlich benötigen, z. B. Speicherplatz pro Monat. Somit muss ein Kunde seine IT-In-frastruktur nicht mehr an Spitzenlasten anpassen, sondern kann Ressourcen dynamisch in Form von virtuellen Ressourcen in der Cloud seinem aktuellen Bedarf entsprechend allokieren.

Neben den zuvor erwähnten Vorteilen gibt es jedoch auch schwerwiegende Bedenken hinsichtlich Datensicherheit und Da-tenschutz. Auch der Schutz der Privatsphäre ist ein großes Hin-dernis für eine breite Akzeptanz des Cloud Computing. Beden-

ken beziehen sich einerseits auf die Vertraulichkeit von gespei-cherten Daten sowie Daten, die in der Cloud verarbeitet werden. Andererseits, und das ist im Fokus dieses Beitrags, fehlt derzeit den Kunden eines Cloud Providers die Möglichkeit, zu beliebigen Zeitpunkten die Vollständigkeit und Verfügbarkeit aller Daten, die beim Provider gespeichert wurden, zu überprüfen.

1 Motivation

Dass auch Bedenken hinsichtlich des letztgenannten Problems nicht unbegründet sind, zeigen einige Vorkommnisse in der Ver-gangenheit. Im Juni 2008 wurde bekannt, dass im Simple Storage Service (S3) von Amazon, einem der populärsten Cloud Speicher-dienste, Daten von unterschiedlichen Kunden manipuliert wur-den [1]. Ein weiteres Ereignis im Mai 2011, bei dem es zu einem massiven Serverabsturz im Amazon EC2 kam, zeigt, dass die Sys-teme noch nicht so robust sind, wie die Cloud Provider es teilwei-se suggerieren. Noch verheerender fielen die Konsequenzen für LinkUp (MediaMax), einen weiteren Cloud-Speicherdienst aus, der nach dem Verlust von 45% der Daten seiner Kunden durch administrative Fehler in Konkurs ging.

Gewiss führt die Zentralisierung von Informationen, wie im Fal-le des Cloud Computing dazu, dass Cloud Provider auch lohnens-werte Angriffsziele darstellen, jedoch zeigen die zuvor genannten Beispiele, dass auch Software- oder Hardwarefehler, falsche oder fehlende Konfigurationen oder administrative Fehler Gefahren-potentiale für Kunden darstellen. Auch für den Cloud Provider haben diese dramatischen Zwischenfälle äußert negative und im schlimmsten Falle existenzbedrohende Konsequenzen.

Lösungen für das zuvor genannte Problem sind natürlich so-wohl für Kunden als auch für Cloud Provider von großem Inte-resse. Denn damit kann speziell Cloud Providern ein Werkzeug zur Verfügung gestellt werden, um auch innerhalb ihrer Rechen-zentren die Vollständigkeit der gespeicherten Daten zu überprü-fen. Somit kann ein Cloud Provider die Dienstgüte (QoS) sei-nes Cloud-Speicherdienstes für die Kunden verbessern und den Dienst damit attraktiver gestalten.

2 Problemstellung

Werden Dokumente in die Cloud ausgelagert, so können einzel-ne Datenblöcke modifiziert werden, sowie Teile von Dokumenten

Daniel Slamanig, Christian Stingl

Vollständigkeitsnachweis für Daten im Cloud Computing

Wie bei der Archivierung von Daten wäre auch beim Cloud Computing ein Mechanismus hilfreich, mit dem man effizient testen könnte, ob die „in die Cloud“ übermittelten Daten beim Cloud-Provider noch vollständig und unverändert zur Verfügung stehen. Die Autoren stellen zwei grundlegende Konzepte zur Lösung dieser Aufgabenstellung vor.

Dr. Daniel Slamanig

ist Wissenschaftlicher Mitarbeiter am Institut für Angewandte Informations-verarbeitung und Kommunikations-technologie (IAIK) an der Technischen Universität Graz. Forschungsgebiet: Angewandte Kryptographie, Privacy Enhancing Technologies

E-Mail: daniel.slamanig@iaik.tugraz.at

Dr. Christian Stingl

ist Professor an der Fachhochschule Kärnten. Forschungsgebiete: Privacy Enhancing Technologies, elektronische Gesundheitsakten

E-Mail: c.stingl@fh-kaernten.at

DuD Datenschutz und Datensicherheit 7 | 2012 511

SCHWERPUNKT

oder gar die Gesamtheit aller Dokumente eines Kunden (im Wei-teren Archiv genannt) verloren gehen. Ohne Frage ist ein Kunde jedoch daran interessiert, dass die Integrität ausgelagerter Doku-mente sichergestellt wird und alle Dokumente des Archivs jeder-zeit vollständig zur Verfügung stehen. Im Worst Case könnte je-doch das gesamte Archiv eines Kunden verloren gehen, und dies kann, wenn kein Backup dieser Dokumente vorhanden ist, fata-le Auswirkungen für ein Unternehmen haben.

Deshalb kann man sich die Frage stellen, ob es für einen Kun-den bzw. den Cloud Provider effizient möglich ist, die Vollstän-digkeit der Dokumente zu überprüfen. Vollständig bedeutet in diesem Kontext, dass alle Dokumente vorhanden und konsistent sind. Deswegen sind in diesem Zusammenhang sowohl Fehle-rerkennung als auch Fehlerkorrektur von großem Interesse. Feh-ler können prinzipiell aus unterschiedlichen Gründen auftreten, wie z. B. durch absichtliche bzw. unabsichtliche Manipulation von Dokumenten oder auch aufgrund von Software- oder Hard-warefehlern.

Die beiden Aspekte Fehlererkennung und -korrektur sind klas-sische Themen der Codierungstheorie und essentielle Bausteine jedes Cloud-Systems, lösen jedoch nicht alle Probleme. Gerade wenn man die Vollständigkeit von Archiven nachweisen möch-te, benötigt man alternative Ansätze. Dieser Beitrag beschäftigt sich speziell mit der Fehlererkennung im Großen, d.h. in einem digitalen Archiv. Auch wenn dies im Interesse sowohl des Cloud Providers als auch dessen Kunden liegt, besteht trotzdem ein gra-vierender Unterschied zwischen den Zielen dieser beiden Partei-en: der Cloud Provider hat das Ziel, die Vollständigkeit seines Ar-chivs zu überprüfen; der Kunde hingegen möchte einen Beweis vom Provider erhalten, dass seine Daten vollständig im System erhalten sind.

Dabei werden unterschiedliche Vertrauensmodelle angenom-men, die nachfolgend näher erläutert werden. Trotzdem kann man sich die Frage stellen, ob deswegen unterschiedliche Metho-den für die Kontrolle eingesetzt werden müssen. Bevor man die-se Frage beantworten kann, muss zuerst ein wesentlicher Aspekt diskutiert werden: Wie effizient kann die Vollständigkeit eines Archivs festgestellt werden? Aus der Sicht eines Kunden mag dies lösbar erscheinen, aber aus der Sicht eines Providers ist ein Nach-weis für die Vollständigkeit des gesamten Archivs wahrscheinlich kaum effizient durchführbar.

Diese Aspekte werden nun näher beleuchtet und dienen später zur Evaluierung der vorgestellten Verfahren.

2.1 Modell

Bevor wir die Verfahren zur Überprüfung der Vollständigkeit diskutieren, möchten wir das Szenario „Speichern von Daten in der Cloud“ näher beschreiben. Ein Kunde speichert Dokumente D = (D1,…,Dn), ein so genanntes Archiv, bei einem Cloud Provi-der. Dabei kann jedes Dokument Di = (b1,...,bm) als eine geordne-te Sequenz von Datenblöcken aufgefasst werden.

Zusätzlich existieren Metadaten für das Archiv, die Referen-zen auf alle im Archiv enthaltenen Dokumente beinhalten. Wei-ters existieren Verifikationsdaten für die Überprüfung der Exis-tenz, der Integrität und Vollständigkeit der Dokumente im Ar-chiv. Diese können grundsätzlich beim Kunden, beim Provider oder bei beiden Parteien verwaltet werden.

Die in einem Archiv gespeicherten Daten können entweder statisch oder dynamisch sein. Das bedeutet, dass einmal gespei-

cherte Dokumente entweder nie verändert werden können (sta-tische Daten) oder dass zusätzliche Dokumente im Archiv integ-riert und bestehende Dokumente geändert und gelöscht werden können (dynamische Daten). Die hier behandelten Verfahren be-ziehen sich primär auf Archive, die um Dokumente erweitert wer-den können, aber nicht vollkommen dynamisch sind. Verfahren, die alle Operationen unterstützen, können im Allgemeinen nicht so effizient gestaltet werden, sind aber auch nicht in allen Anwen-dungsszenarien notwendig.

2.2 Vertrauensmodell

Das zugrunde liegende Vertrauensmodell ist davon abhängig, wer die Überprüfung durchführt. Wahrscheinlich wird der Cloud Provider grundsätzlich mehr Vertrauen in sein eigenes System haben als seine Kunden. Ein Kunde vertraut dem Cloud Provi-der nicht vollständig und geht möglicherweise sogar davon aus, dass jener im Falle eines Datenverlustes nicht vollkommen ehr-lich ist und versuchen wird, den Verlust vor dem Kunden zu ver-bergen. Auch wenn die meisten Kunden, wenn Sie ihre Daten ei-nem Provider anvertrauen, diesem großes Vertrauen entgegen-bringen, möchten sie dies von Zeit zu Zeit kontrollieren.

2.3 Ansätze

Die Überprüfung auf Vollständigkeit kann einerseits determinis-tisch und andererseits probabilistisch erfolgen. Beim ersten An-satz wird dabei ein gesamtes Dokument bzw. das gesamte Archiv auf Vollständigkeit überprüft. Offensichtlich ist der Aufwand beim deterministischen Ansatz speziell bei Archiven enorm, da alle Dokumente geladen und überprüft werden müssen. Im Ge-gensatz dazu basieren probabilistische Ansätze auf dem Prinzip des Spot Checkings. Dies bedeutet, dass nicht das gesamte Doku-ment bzw. das gesamte Archiv geprüft wird, sondern nur eine zu-fällig gewählte Anzahl von Blöcken bzw. Dokumenten. Somit er-hält man bei einer erfolgreichen Überprüfung zwar keine Garan-tie, dass alle Dokumente noch vollständig vorhanden sind, jedoch kann über die Anzahl der Spots die Wahrscheinlichkeit für Voll-ständigkeit prinzipiell beliebig groß gemacht werden.

2.4 Parameter

Wichtige Aspekte bei der Überprüfung auf Vollständigkeit sind die folgenden:

Robustheit: Diese Eigenschaft beschreibt, wie gut ein Verfahren Datenblöcke bzw. Dokumente vor Modifikationen schützt. Ei-nerseits interessiert man sich dabei für die Robustheit gegenüber großen Fehlern (ein großer Teil eines Dokuments bzw. Archivs existiert nicht mehr) und andererseits gegenüber kleinen Fehlern (z.B. Fehler, die sich nur auf wenige bits beziehen). Letzteres wird üblicherweise durch die Verwendung von fehlerkorrigierenden Codes, also dem Einbringen von Wiederherstellungsinformati-onen in ein Dokument vor dem Speichern erreicht, da in diesem Fall der probabilistische Ansatz für die Erkennung von Manipu-lationen zu ineffizient wäre.

Effizienz: Diese Eigenschaft umfasst mehrere Bereiche, näm-lich den Kommunikationsaufwand, den Berechnungsaufwand, den Speicheroverhead (Verifikationsdaten) und den I/O Over-head während einer Überprüfung.

512 DuD Datenschutz und Datensicherheit 7 | 2012

SCHWERPUNKT

3 Evidence Record Syntax

Ein interessanter Ansatz zum Überprüfen der Existenz und der Integrität von Dokumenten in einem Archiv wurde in der Evi-dence Record Syntax (ERS) [2, 3] spezifiziert. Die ERS ist Teil der Spezifikation des Long-Term Archiving and Notary Service (LTANS).

Ein wesentliches Ziel der ERS ist, neben Existenz und Integ-rität, die Integration von digitalen Signaturen zur Beweissiche-rung in Gerichtsverfahren für die Dokumente im Archiv. Es ist somit naheliegend, diesen Ansatz auch in der Cloud einzuset-zen. Ein erster naiver Ansatz könnte so aussehen, dass für jedes Dokument eine digitale Signatur von einer Time Stamp Authori-ty (TSA) angefordert wird. Eine vertrauenswürdige externe Stel-le bietet in diesem Zusammenhang den Vorteil, dass die Signa-turen auch von anderen Parteien überprüft werden können und somit Manipulationen durch den Cloud Provider ausgeschlossen werden können. Dieser Ansatz funktioniert auch, wenn im Ori-ginaldokument bereits eine Signatur integriert wurde. Es hat so-gar den großen Vorteil, dass die Originalsignatur unter Zuhilfe-nahme der „neuen“ Signatur verifiziert werden kann.

Aber was macht man, wenn im Laufe der Zeit die Signaturen ihre Beweiskraft verlieren? Dies kann passieren, wenn die ver-wendeten Signaturalgorithmen gebrochen oder zumindest als „schwach“ eingestuft werden oder auch weil die im Signatur-verfahren eingesetzte Hashfunktion als „zu schwach“ bewertet wird. Ein weiteres mögliches Szenario wäre, dass der Zertifizie-rungspfad nicht mehr verifiziert werden kann, da die involvier-ten Zertifikate nicht mehr zur Verfügung stehen oder die Zerti-fikate als nicht mehr gültig eingestuft sind. Um die Beweiskraft wieder herstellen zu können, wäre eine Neusignierung eine the-oretische Lösung, die jedoch in großen Archiven nicht praktika-bel umsetzbar ist.

Deswegen verfolgt man den Ansatz, dass die Signaturen von ei-ner vertrauenswürdigen Stelle nachsigniert werden [4, 5]. Wür-de man jedoch den zuvor erwähnten Ansatz des Nachsignierens für jedes Dokument einzeln anwenden, so wäre dies erstens mit enormem Aufwand verbunden und zweitens wären die Kosten für die Erstellung der TSA-Signaturen zu hoch. Deswegen ver-folgt man das Ziel, eine TSA-Signatur für eine große Anzahl von Dokumenten zu erlangen.

3.1 Hashbäume

Um dieses Problem zu lösen, werden so genannte Hashbäume (Merkle-Trees) eingesetzt. Diese wurden 1980 von R. Merkle ein-geführt und können verwendet werden, um Teile größerer Archi-ve auf Authentizität zu prüfen, ohne dass alle Dokumente vor-liegen müssen [6]. Dazu werden im ersten Schritt Hashwerte der einzelnen Dokumente den Blättern eines binären Baumes zuge-wiesen. Anschließend wird rekursiv für jeden inneren Knoten ein neuer Hashwert auf Basis der konkatenierten Hashwerte der Kindknoten berechnet.

Das resultierende Root-Element kann nun als „Repräsentant“ für alle Dokumente im Hashbaum aufgefasst werden, denn jede Manipulation eines einzigen Dokuments verändert das Root-Ele-ment. Dieses Root-Element wird anschließend von der TSA sig-niert und dient in weiterer Folge zum Überprüfen der Existenz und Integrität derjenigen Dokumente, die in dem Hashbaum in-tegriert wurden. Dazu wird für jedes Dokument ein reduzierter

Hashbaum gebildet. Dieser besteht genau aus denjenigen Knoten des (ursprünglichen) Hashbaumes, die notwendig sind, um das Root-Element zu rekonstruieren. Genauer gesagt, aus allen Hash-werten von Geschwisterknoten entlang des Pfades zum Root-Ele-ment.

Hinterlegt man nun bei jedem Dokument den reduzierten Hashbaum und die TSA-Signatur, so muss zuerst der Hashwert des Dokumentes gebildet werden, dann das Root-Element mit Hilfe des reduzierten Hashbaumes errechnet werden, und zum Schluss kann unter Zuhilfenahme der TSA-Signatur die Integrität des Root-Elements und folglich des Dokuments festgestellt wer-den. Zugleich ist damit auch die Existenz des Dokuments sicher-gestellt, da sonst der Hashwert des Dokuments nicht gebildet und folglich auch das Root-Element nicht rekonstruiert werden könn-te. Man kann hier jedoch nicht von einem Beweis sprechen, da natürlich der Hashwert des Dokuments ebenfalls im Archiv hin-terlegt werden könnte und damit der gespeicherte Hashwert für die Konstruktion des Root-Elements herangezogen werden kann.

Was macht man aber, wenn die Gefahr besteht, dass die TSA-Signatur Ihre Beweiskraft verlieren könnte? Vor dem Eintreten dieses Ereignisses wird wiederum das Prozedere des Nachsignie-rens, nun jedoch für die TSA-Signatur, angewandt. Um diesen Prozess effizient zu gestalten, werden alle TSA-Signaturen, die die Beweiskraft verlieren könnten, gleichzeitig erneuert. Dazu wird der Hashbaum der TSA-Signaturen gebildet und das resultieren-de Root-Element wird wiederum von einer TSA signiert. Für je-des Dokument müssen damit die Verifikationsdaten um den re-duzierten Hashbaum der ersten TSA-Signatur erweitert werden. Dieser einheitliche Prozess der Signaturerneuerung kann im Lau-fe der Zeit mehrfach zur Anwendung kommen.

Wendet ein Cloud Provider dieses Verfahren für sein Archiv an, so muss geklärt werden, welche Dokumente in einem Hash-baum zusammengefasst werden sollen. Dazu könnten beispiels-weise zeitliche (einmal pro Tag), thematische (Dokumente eines Kunden) oder quantitative (je 1000 Dokumente) Einteilungen ge-troffen werden. Problematisch ist beim Einsatz von ERS erstens die Zeitspanne bis zum Bilden des Hashbaumes und zweitens, dass bei einem Verlust von Dokument und zugehörigen Verifika-tionsdaten die Existenz nicht mehr nachgewiesen werden kann. Deswegen ist es notwendig, das Verzeichnis der Dokumente (Me-tadaten) mit den Verifikationsdaten separat von den Dokumen-ten zu speichern. Somit kann zumindest die Wahrscheinlichkeit für den beschriebenen Totalverlust reduziert werden.

3.2 Bewertung

Wie kann der Cloud Provider nun die Vollständigkeit seines Ar-chivs überprüfen? Der deterministische Ansatz ist aus offensicht-lichen Gründen in großen Archiven eher von theoretischer Be-deutung. Weiter ist es damit nur möglich, Dokumente vollständig zu überprüfen und nicht nur bestimmte Datenblöcke des Doku-ments. Letzteres ließe sich jedoch durch die Integration der Da-tenblöcke (statt der gesamten Dokumente) in den Hashbäumen und der Speicherung der Verifikationsdaten pro Datenblock lö-sen. Der Aufwand wäre jedoch beträchtlich.

In ERS-Implementierungen ist im Allgemeinen nicht vorgese-hen, dass der Kunde zusätzliche Informationen bekommt, die er zum Überprüfen der Existenz und Integrität seiner Daten heran-ziehen könnte. Sonst müsste nämlich auch der Kunde die Meta-daten und die Verifikationsdaten (möglicherweise signiert durch

DuD Datenschutz und Datensicherheit 7 | 2012 513

SCHWERPUNKT

den Cloud Provider) separat speichern um Nachweise vom Cloud Provider verlangen zu können. Der Aufwand muss wiederum als beträchtlich eingestuft werden.

4 Remote Data Checking

Ein alternativer Ansatz für den Kunden wäre folgende Strategie: Für jedes auszulagernde Dokument D wird ein Message Authen-tication Code (MAC) bzw. eine digitale Signatur lokal berech-net, gespeichert und D beim Cloud Provider gespeichert. Soll nun überprüft werden, ob ein Dokument D existiert und konsistent ist, so wird D vom Cloud Provider angefordert und der MAC bzw. die Signatur für das erhaltene Dokument überprüft. Wird dieses Verfahren auf das gesamtes Archiv des Kunden D = (D1,…,Dn) angewendet, so wird die Prozedur einfach für jedes Di, 1 ≤ i ≤ n, unabhängig durchgeführt.

Offensichtlich ist dieses Verfahren aufgrund der großen Daten-mengen nicht praktikabel, da das gesamte Archiv bei der Über-prüfung zum Kunden übertragen werden muss. Man könnte je-doch die Kommunikations- und die Berechnungskomplexität dieses Verfahrens reduzieren, indem anstatt der Dokumente nur die Hashwerte zum Kunden übertragen werden. Auch bei einem sehr großen Archiv wäre das Übertragen von n 160 bit Hashwer-ten bei Verwendung von SHA-1 durchaus praktikabel. Verwendet man in diesem Zusammenhang ein Signaturverfahren, das Nach-richtenrückgewinnung unterstützt, z. B. RSA-Signaturen auf Ba-sis des Hashen-dann-Signieren-Paradigmas, so ist auch eine Ve-rifikation der lokal gespeicherten Signaturen problemlos mög-lich. Allerdings könnte bei diesem Ansatz ein Cloud Provider ein-fach nur die Hashwerte der Dokumente speichern, die eigentli-chen Dokumente verwerfen und den Kunden trotzdem davon überzeugen, dass alle Dokumente existieren und konsistent sind.

4.1 Probabilistische Challenge-Response Verfahren

Alle weiteren Verfahren basieren auf einem probabilistischen An-satz in Kombination mit Challenge-Response-Verfahren. Verein-facht gesagt stellt der Kunde dem Cloud Provider eine Challen-ge in Form einer zufällig gewählten Menge von Dokumenten. Der Provider muss anschließend einen „Beweis“ erstellen und diesen dann als Response an den Kunden schicken. Bei erfolg-reicher Verifikation des Beweises ist der Kunde überzeugt, dass die jeweiligen Dokumente (bzw. das gesamte Archiv) mit einer durch die Challenge definierten Wahrscheinlichkeit existieren und integer sind.

Eine Modifikation des oben genannten einfachen Verfahrens in Kombination mit einem probabilistischen Challenge-Respon-se Ansatz wurde in [7] vorgestellt. Dieses Verfahren funktioniert schematisch wie folgt: Will ein Kunde ein Dokument D = (b1,…,bm) bei einem Cloud Provider speichern, so muss er vorab fest-legen, wie oft er überprüfen will, ob D existiert und integer ist. Nehmen wir an, dass dies t-mal möglich sein soll. Nun wählt der Kunde zwei Master-Schlüssel für die Erzeugung von Seeds (Start-werten), um eine Pseudozufallspermutation g und eine Pseudozu-fallsfunktion f (beide können mittels einer Blockchiffre wie AES realisiert werden) zu initialisieren.

Nun wird die Pseudozufallsfunktion f mit dem Input i {1, …, t} und den Master-Schlüsseln verwendet, um einen Seed ki für g und eine zufällige Challenge ci zu erzeugen. Anschließend wird

definiert, wie viele Blöcke in D jeweils zufällig geprüft werden sollen. Wir bezeichnen diese Anzahl mit r. Durch die Wahl die-ses Parameters r wird die Betrugswahrscheinlichkeit des Cloud Providers begrenzt. Nun wird mit g (mit ki parametriert) für jede Runde eine Indexmenge I = {i1,…,ir} berechnet. Diese legt die in der jeweiligen Überprüfung zu verwendenden Blöcke von D fest.

Der Kunde kann nun unter Verwendung einer Hashfunktion H und eines symmetrischen Verschlüsselungsverfahrens (z.B. AES) die t Token berechnen, die dann jeweils für einen Check verwen-det werden können. Jeder Token vi, 1 ≤ i ≤ t, errechnet sich als vi = H(ci,bi1,…,bir). Danach werden die Token v1, …, vt unter Ver-wendung eines symmetrischen Verschlüsselungsverfahrens ein-zeln verschlüsselt und die verschlüsselten Token zusammen mit dem Dokument D beim Cloud Provider abgelegt.

Will ein Kunde nun das i-te mal überprüfen, ob das Dokument D noch existiert und konsistent ist, so geht er wie folgt vor: Er be-rechnet ki und ci für das Token und sendet diese beiden Werte zum Cloud Provider, der f und g kennt. Nun greift der Cloud Pro-vider auf die den Indizes entsprechenden Blöcken von D zu und berechnet vi‘ = H(ci, bi1,…, bir) und sendet vi‘ zusammen mit dem verschlüsselten Token an den Kunden. Der Kunde überprüft nun, ob das erhaltene Token vi‘ und das entschlüsselte Token überein-stimmen.

Der Vorteil bei diesem Verfahren liegt nun darin, dass die für eine Überprüfung vom Cloud Provider zum Kunden zu übertra-gende Menge an Daten konstant ist (ein Hashwert und ein ver-schlüsselter Hashwert) und somit unabhängig von der Größe des Dokuments D. Ein Nachteil ist jedoch, dass die Anzahl t der ge-planten Überprüfungen vorab festgelegt werden muss. Allerdings lässt sich dieser Ansatz relativ einfach auf ein vollkommen dyna-misches Szenario erweitern.

4.2 Provable Data Possession

Nun wollen wir noch weitere, dem gleichen Prinzip folgende An-sätze diskutieren, die am vielversprechendsten für den prakti-schen Einsatz sind. Das Konzept der Proofs of Retrievability (PoRs) wurde in [8] eingeführt. Dieser Ansatz ist auch nur für eine limitierte Anzahl von Challenges ausgelegt. In [9] werden PoRs mit einer unlimitierten Anzahl von Challenges konstru-iert. PoRs legen den Fokus auf integrierte Fehlerkorrektur, setz-ten aber auch auf den Spot-Checking-Ansatz zur Erkennung von größeren Fehlern (siehe [10] für eine umfangreiche Betrachtung).

Eine Alternative und ein unabhängig von PoRs vorgeschlage-ner Ansatz ist die Provable Data Possession (PDP) [11]. Dabei liegt der Fokus auf der Erkennung größerer Fehler und einer unlimi-tierten Anzahl von Challenges. In [12] wurde der PDP-Ansatz um Fehlerkorrektur erweitert. Ein allgemeines Framework für PDPs, die robust gegen beide Arten von Fehlern sind, und das ei-ne Kombination der Resultate von [11] und [12] darstellt, wird in [13] präsentiert.

Im Folgenden wollen wir die prinzipielle Idee von PDPs zur Er-kennung größerer Fehler schematisch beschreiben. Die Erken-nung und Korrektur kleiner Manipulationen und fehlender Do-kumentteile kann durch eine geschickte Codierung eines Doku-ments vor der Speicherung erreicht werden und wird hier nicht behandelt. Will ein Kunde ein Dokument D beim Cloud Provider speichern, so benötigt dieser, wie auch schon zuvor, ein Prepro-cessing am Client. Dieser erzeugt für sich öffentliche und private Informationen, wobei die private Information als Falltüre (Trap-

514 DuD Datenschutz und Datensicherheit 7 | 2012

SCHWERPUNKT

door) dient. In [11] ist dies ein „spezielles“ RSA-Schlüsselpaar. Dieses „Schlüsselpaar“ kann für das gesamte Archiv des Kunden verwendet werden.

Ein Kunde wählt einen geheimen Zufallsstring v für jedes Dokument D und berechnet für jeden Block bi, 1 ≤ i ≤ m, einen Tag Ti. Diese Tags kann man sich jeweils als speziellen Hashwert von v, dem Blockindex i und einer Repräsentation von bi vorstel-len, in dessen Berechnung die private Information einfließt. Somit ist sichergestellt, dass nur der Kunde valide Tags berechnen kann.

Dann werden diese Tags zusammen mit D und der öffentlichen Information zum Cloud Provider übermittelt. Diese Tags besit-zen eine so genannte homomorphe Eigenschaft. Man kann also mehrere Tags zu einem Tag gleicher Größe kombinieren, wobei der Ergebnis-Tag eine (verifizierbare) Repräsentation der Sum-me der zugehörigen Dokumentenblöcke darstellt. Stellt ein Kun-de nun eine Challenge für das Dokument D an den Cloud Provi-der, so definiert diese Challenge (wie im zuvor vorgestellten Ver-fahren) die Indexmenge der zu verwendenden Blöcke. Der Server „kombiniert“ nun erstens die entsprechenden Tags unter Verwen-dung der homomorphen Eigenschaft in einen Tag T*. Zweitens bestimmt er einen Wert p, der einer Funktion der entsprechen-den Blöcke entspricht. Der Cloud Provider sendet darauf (T*, p) an den Kunden, und dieser überprüft, ob eine gewisse Beziehung zwischen T* und p erfüllt ist. Diese Beziehung kann ausschließ-lich dann hergestellt werden, wenn der Cloud Provider alle ent-sprechenden Blöcke besitzt (bzw. er keinen Zugriff auf die priva-te Information des Kunden hat).

Zusammenfassend kann folgendes festgehalten werden: Der Kunde muss für sein gesamtes Archiv ausschließlich die private Information (wenige KB) speichern.

Die gesamten Verifikationsdaten werden beim Provider hin-terlegt.

Jede Manipulation an diesen Daten kann vom Kunden erkannt werden.

Für ein praktikables Setup bringt dies einen Speicher-Overhead von ca. 10% beim Cloud Provider.

4.3 Bewertung

Will ein Kunde die Vollständigkeit seines gesamten Archivs über-prüfen, so kann je eine Challenge für jedes Dokument gestellt werden. Alternativ kann das Archiv auch als „großes“ Doku-ment betrachtet werden und eine einzige Challenge gestellt wer-den. Dies ist bei der Konstruktion in [11] problemlos möglich, da ein „Anhängen“ von Blöcken an ein existierendes Dokument und die Berechnung der zusätzlichen Tags einfach möglich ist.

Die in Abschnitt 4.2 diskutierten Ansätze eignen sich beson-ders, um Kunden die Möglichkeit zu geben, ein Archiv auf Voll-ständigkeit zu überprüfen. Deswegen werden diese Konzepte be-reits im Design von zukünftigen cloud-basierten Speicherdiens-ten berücksichtigt [14, 15].

5 Resümee

In diesem Beitrag wurden zwei unterschiedliche Konzepte zur Überprüfung von Vollständigkeit und Integrität von Dokumen-ten bzw. Archiven betrachtet. Beide haben in diesem Kontext so-wohl Stärken als auch Schwächen.

Beim Ansatz ERS liegt die Stärke klar in der Überprüfung von einzelnen Dokumenten hinsichtlich Vollständigkeit und Integri-tät. Dies erfolgt deterministisch, und die Verifikationsdaten sind im Vergleich zur Dokumentengröße relativ gering, zumindest so-lange die eingesetzten kryptographischen Primitive nicht bald als „schwach“ eingestuft werden bzw. die Algorithmen möglichst vorausschauend gewählt wurden. Weiter ist diese Art der Über-prüfung nur für den Cloud Provider sinnvoll, da beim Kunden die Verifikationsdaten im Allgemeinen nicht zur Verfügung ste-hen bzw. der Aufwand der Datenübermittlung zum Kunden zu groß wäre.

Im Gegensatz dazu sind PDP-Verfahren primär für die Über-prüfung des gesamten Archivs geeignet, da mit dem probabilis-tischen Ansatz die Vollständigkeit des (potentiell großen) Ar-chivs sehr effizient überprüft werden kann. Dies kann sowohl vom Cloud Provider als auch von Kunden eingesetzt werden, da erstens das Datenvolumen, das zum Überprüfen notwendig ist, sehr gering ist, und zweitens dies sehr performant durchge-führt werden kann. Der Overhead hinsichtlich des Speicherplat-zes für Verifikationsdaten sollte jedoch nicht unterschätzt wer-den, da diese sowohl durch den Provider als auch beim Kunden gespeichert werden müssen. Der zweite Ansatz bietet jedoch spe-ziell für den Kunden den großen Vorteil, dass die Überprüfun-gen als verlässlich eingestuft werden kann, da der Cloud Provi-der keine Möglichkeit hat, das Fehlen von Blöcken bzw. Doku-menten zu kaschieren.

Zusammenfassend kann gesagt werden, dass beide Methoden keinesfalls exklusiv eingesetzt werden müssen, sondern sehr wahr-scheinlich in Kombination mit einem Cloud-Speicherdienst eine erhöhte Dienstgüte hinsichtlich Vollständigkeit bringen können.

Literatur

[1] A. Ferdowsi. S3 data corruption? http://developer.amazonwebservices.com/connect/thread.jspa?threadID=22709&start=0&tstart=0, 2008.

[2] Evidence Record Syntax, RFC 4998[3] Extensible Markup Language Evidence Record Syntax, RFC 6283[4] R. Brandner, U. Pordesch, A. Roßnagel, J. Schachermayer: Langzeitsiche-

rung digitaler Signaturen. DuD 2/2002, S. 97-103.[5] S. Fischer-Dieskau, U. Korte, D. Hühnlein: Die Technische Richtlinie zur ver-

trauenswürdigen elektronischen Langzeitspeicherung (TR-VELS). DuD 11/2009, S. 673-677.

[6] R. Merkle: Protocols for Public Key Cryptosystems, IEEE Symposium on Se-curity and Privacy 1980.

[7] G. Ateniese, R.D. Pietro, L.V. Mancini, G. Tsudik: Scalable and Efficient Pro-vable Data Possession. SecureComm 2008.

[8] A. Juels, B. S. Kaliski Jr.: PORs: Proofs of Retrievability for Large Files. ACM CCS 2007, ACM.

[9] H. Shacham, B. Waters: Compact Proofs of Retrievability. ASIACRYPT 2008, Springer.

[10] K. D. Bowers, A. Juels, A. Oprea: Proofs of retrievability: theory and imple-mentation. CCSW 2009, ACM.

[11] G. Ateniese, et al.: Provable data possession at untrusted stores. ACM CCS 2007, ACM.

[12] R. Curtmola, O. Khan, R.C. Burns: Robust remote data checking. StorageSS 2008, ACM.

[13] G. Ateniese, et al.: Remote data checking using provable data possession. ACM Trans. Inf. Syst. Secur. 14(1): 12 (2011).

[14] K.D. Bowers, A. Juels, A. Oprea: HAIL: a high-availability and integrity lay-er for cloud storage. CCS 2009, ACM.

[15] R.A. Popa, J.R. Lorch, D. Molnar, H.J. Wang, L. Zhuang: Enabling security in cloud storage SLAs with CloudProof. USENIXATC’11.