WI – AUFSATZ
Sicheres und nachhaltiges Benchmarking
in der Cloud
Eine Mehrparteien-Cloud-Anwendung
ohne vertrauenswürdigen Dienstanbieter
Durch Cloud-Computing entsteht eine neue Sicherheitsbedrohung: Dem Cloud-
Dienstanbieter werden die Daten aller seiner Kunden anvertraut. Verschlüsselung kann
diesen Konflikt lösen. Am Beispiel gemeinschaftlichen Benchmarkings werden die
Gestaltung und die Implementierung einer Cloud-Anwendung, die nur mit verschlüsselten
Daten arbeitet, beschrieben und evaluiert.
DOI 10.1007/s11576-011-0267-1
Der Autor
Dr. Florian Kerschbaum ()
SAP AG
SAP Research
Vincenz-Prießnitz-Str. 1
76131 Karlsruhe
Deutschland
florian.kerschbaum@sap.com
Eingegangen: 2010-06-14
Angenommen: 2011-02-04
Angenommen nach drei Überarbei-
tungen durch Prof. Dr. Müller.
Online publiziert: 2011-04-15
This article is also available in Eng-
lish via http://www.springerlink.com
and http://www.bise-journal.org:
Kerschbaum F (2011) Secure and Su-
stainable Benchmarking in Clouds.
A Multi-Party Cloud Application with
an Untrusted Service Provider. Bus Inf
Syst Eng. doi: 10.1007/s12599-011-
0153-9.
© Gabler Verlag 2011
1 Einleitung
Durch Cloud-Computing entsteht eine
neue Sicherheitsbedrohung: Dem Cloud-
Dienstanbieter werden die Daten aller
seiner Kunden anvertraut und er kann
diese – unbeabsichtigt oder vorsätzlich-
lich – Dritten zugänglich machen. Ob-
wohl der Dienstanbieter die notwen-
digen Sicherungsmaßnahmen ergreifen
WIRTSCHAFTSINFORMATIK 3|2011
kann, um die Vertraulichkeit der Da-
ten gegenüber Dritten, einschließlich an-
derer Kunden, zu gewährleisten, so er-
fährt er jedoch beiläufig diese Daten
selbst, und diese neue Vertrauensbezie-
hung zwischen Kunde und Dienstanbie-
ter kennzeichnet das Cloud-Computing.
Für einige Anwendungen ist die Nach-
haltigkeit dieses Vertrauens nicht aus-
reichend, zum Beispiel streng vertrauli-
che Daten über den Firmenbetrieb. Um
Kunden für das Cloud-Computing sol-
cher Daten zu gewinnen und zu behalten,
muss die Vertraulichkeit selbst gegenüber
dem Dienstanbieter gewährleistet sein.
Eine langfristige und nachhaltige Bezie-
hung zwischen Dienstanbieter und Kun-
de sollte auf minimalen Vertrauensan-
nahmen beruhen, einschließlich des Ver-
trauens des Kunden in den Dienstanbie-
ter. Deshalb ist es für die Nachhaltigkeit
der Cloud-Anwendung vorteilhaft, wenn
der Dienstanbieter dem Kunden die Ver-
traulichkeit seiner Daten technisch zusi-
chern kann.
Verlässlichkeit und präventive Sicher-
heitsmaßnahmen sind für die Vertrau-
lichkeit von entscheidender Bedeutung.
Verträge und Strafen oder andere feststel-
lende Sicherheitsmaßnahmen erfordern
den Beweis eines Vertraulichkeitsbruchs,
der schwierig zu erbringen sein kann.
Technisch wird die Zusicherung von
Vertraulichkeit – in Ermangelung von
Verweisüberwachung und Zugriffskon-
trolldurchsetzung – mittels Verschlüsse-
lung realisiert. Standardisierte Verfah-
ren mit öffentlichen oder symmetri-
schen Schlüsseln, die regelmäßig zur Si-
cherung der Datenkommunikation ein-
gesetzt werden, erfüllen die Anforde-
rung für nachhaltiges Cloud-Computing
nicht, weil so verschlüsselte Daten nicht
mehr verarbeitet werden können. Die ho-
momorphe Verschlüsselung (Damgard
und Jurik 2001; Gentry 2009; Paillier
1999) erlaubt die Verarbeitung verschlüs-
selter Daten, ist aber für anspruchsvol-
le Cloud-Anwendungen zu ineffizient.
Die sicheren Mehrparteienberechnungen
(Ben-Or et al. 1988; Cramer et al. 2001;
Goldreich et al. 1987) – eine alternati-
ve kryptographische Methode – sind be-
rechnungseffizienter, haben aber erhöhte
Kommunikationsanforderungen.
Die Forschungsfrage dieser Arbeit sind
die Designmöglichkeiten für nachhaltiges
Cloud-Computing mittels dieser Metho-
den. Dem Entwickler bieten sich meh-
rere Möglichkeiten in der Wahl der Ver-
schlüsselungsmethode, der Schlüsselver-
teilung und des Sicherheitsmodells sowie
der nicht sicherheitsrelevanten Funktio-
nen der Anwendung. Er muss sorgfältig
die Zielkonflikte zwischen Funktionali-
tät, Sicherheit und Effizienz abwägen.
Wir betrachten diese Designmöglich-
keiten anhand einer Fallstudie einer von
uns entwickelten vertraulichkeitserhal-
tenden Cloud-Anwendung. Wir haben
eine gemeinschaftliche Geschäftsanwen-
dung zum Benchmarking entwickelt.
Benchmarking ist der Vergleich von
Kennzahlen (KPI) mit den Statistiken ei-
ner Gruppe. Unsere Cloud-Anwendung
berechnet diese Statistiken ohne die
Kennzahlen eines Unternehmens offen-
zulegen.
Benchmarking ist wichtig für Unter-
nehmen, um die Wettbewerbsfähigkeit in
den heutigen Märkten zu erhalten. So
können sie ihre Leistung mit Statistiken
129
WI – AUFSATZ
über die Konkurrenz vergleichen und ge-
gebenenfalls gezielte Verbesserungsmaß-
nahmen einleiten. Benchmarkingdiens-
te wurden bereits vorgeschlagen und
auch schon implementiert (Bogetoft und
Nielsen 2005; Crotts et al. 2006), aber
ohne nachhaltige Sicherheit gegenüber
dem Dienstanbieter. Der positive Einfluss
von Vertraulichkeitsschutz auf die Bereit-
schaft von Firmen, Daten auszutauschen,
wurde bereits in verwandten Studien be-
legt (Eurich et al. 2010).
Wir haben einen Prototypen zum ge-
meinschaftlichen Benchmarking auf ver-
schlüsselten Daten in der Cloud ent-
wickelt, implementiert und evaluiert.
Dies ist die erste uns bekannte Cloud-
Anwendung, die verschlüsselte Daten
verarbeitet. Wir verwenden eine Kom-
bination aus homomorpher Verschlüsse-
lung und sicheren Mehrparteienberech-
nungen, um die notwendige Effizienz
und Funktionalität zu erreichen. Folgen-
de Designmöglichkeiten erörtern wir im
Detail:
 Sicherheit vs. Funktionalität (Abschn. 3
und 4): Zunächst belegen wir, dass
es nicht möglich ist, alle möglichen
Benchmarkingfunktionen sicher zu
implementieren (Abschn. 3). Obwohl
es immer möglich ist, zu verschlüsseln
und die verschlüsselten Daten zu ver-
arbeiten, kann das Ergebnis der Verar-
beitung die zu schützenden Eingaben
verraten. Wir zeigen die notwendigen
Bedingungen zum vertraulichkeits-
erhaltenden Benchmarking auf. Da-
nach zeigen wir die Auswirkungen von
verschlüsseltem Cloud-Computing
auf rationales Verhalten und die ent-
sprechende Auswahl der statistischen
Funktionen (Abschn. 4). Weiterhin
zeigen wir, wie man effizient einen
neuartigen Angriff auf verschlüsseltes
Cloud-Computing verhindert.
 Sicherheit vs. Effizienz (Abschn. 5
und 6): Zunächst beschreiben wir die
Designmöglichkeiten zur Schlüsselver-
waltung und -handhabung und be-
gründen unsere Entscheidung (Ab-
schn. 5). Danach beschreiben wir ei-
ne neuartige Methode zum Vergleich
mittels teil-homomorpher Verschlüs-
selung (Abschn. 6). Diese neue Metho-
de ist zwar weniger sicher als vergleich-
bare kryptographische Methoden, aber
wesentlich effizienter. Zudem verein-
facht sie das Design der gesamten An-
wendungen, weil dann ein homomor-
phes Verschlüsselungsverfahren aus-
reicht.
130
 Funktionalität vs. Effizienz (Abschn. 7):
Wir beschreiben die Softwarearchi-
tektur und Komponentenstruktur, die
vertraulichkeitserhaltendes Benchmar-
king trotz der Effizienzanforderungen
ermöglicht.
Der Beitrag ist wie folgt strukturiert:
In Abschn. 2 beschreiben wir die Pro-
blemstellung vertraulichkeitserhaltenden
Cloud-Computings sowie unsere Schutz-
ziele und vergleichen die Ansätze von
homomorpher Verschlüsselung und si-
cherer Mehrparteienberechnungen. Wir
beschreiben auch gemeinschaftliches
Benchmarking im Detail. In Abschn. 8
beschreiben wir unsere Implementierung
und Effizienzmessungen. In Abschn. 9
geben wir einen Überblick über verwand-
te Arbeiten. Unsere Schlussfolgerungen
fassen wir in Abschn. 10 zusammen.
2 Problemstellung und Ansatz
Mit vertraulichkeitserhaltendem Cloud-
Computing versucht man die Vertrau-
ensvoraussetzungen in den Dienstanbie-
ter zu reduzieren, indem der Kunde die
Daten verschlüsselt, bevor er sie an die
Cloud sendet. Es gibt zwei kryptogra-
phische Methoden, um dies zu errei-
chen: homomorphe Verschlüsselung und
sichere Mehrparteienberechnungen.
2.1 Homomorphe Verschlüsselung
Homomorphe Verschlüsselung ist eine
moderne Verschlüsselungsmethode, bei
der eine Manipulation der Chiffrate eine
Verschlüsselung des Ergebnisses einer ho-
momorphen Operation der Klartexte er-
gibt. Sie kann direkt für vertraulichkeits-
erhaltendes Cloud-Computing eingesetzt
werden. Der Kunde verschlüsselt die Da-
ten, behält den Schlüssel für sich und sen-
det die Chiffrate an den Dienstanbieter.
Der Dienstanbieter führt die Operatio-
nen der Chiffrate durch, die die homo-
morphen Operationen der Klartexte rea-
lisieren.
Kürzlich wurde eine voll-homomorphe
Verschlüsselungsmethode entwickelt, die
als homomorphe Operation „logisches
nicht-und“ (NAND) realisiert (Gen-
try 2009). Sie kann verwendet werden,
um beliebige Funktionen der Klartexte
durchzuführen, aber dieses Verfahren ist
noch zu ineffizient, um sichere Funktio-
nen zu realisieren. Stattdessen verwenden
wir effizientere Verschlüsselungsmetho-
den, bei denen die homomorphe Ope-
ration auf Ganzzahlenaddition (modu-
lo einer schlüsselabhängigen Konstante)
beschränkt ist. Wir belegen später noch
die weiterhin entscheidende Bedeutung
der Effizienz. Wir verwenden Paillier’s
Verschlüsselungsmethode (Paillier 1999)
und seine Schwellwertvariante von Dam-
gard und Jurik (2001). EX (x) bezeichnet
die Verschlüsselung von x mit dem öf-
fentlichen Schlüssel von X und DX () be-
zeichnet die entsprechende Entschlüsse-
lung mit dem geheimen Schlüssel von X.
Es gilt die folgende Eigenschaft:
DX (EX (x) · EX (y)) = x + y.
Durch einfache Arithmetik kann die fol-
gende Eigenschaft abgeleitet werden
DX (EX (x)y ) = x · y.
2.2 Sichere Mehrparteienberechnungen
Homomorphe Verschlüsselung trennt
klar zwischen Berechnung und Einga-
be, ist aber aus Effizienzgründen auf
bestimmte Operationen begrenzt. Eine
Alternative bieten sichere Mehrparteien-
berechnungen. In sicheren Mehrpartei-
enberechnungen wird die Funktion nicht
von nur einer Partei mittels der Chiffra-
te berechnet, sondern als gemeinsames
Protokoll aller Parteien. Nach Abschluss
des Protokolls kann eine definierbare
Untermenge der Parteien das Ergebnis
rekonstruieren, aber alle Parteien – un-
abhängig davon, ob sie das Ergebnis ken-
nen oder nicht – lernen, wie die Funktion
berechnet wird.
Protokolle, die beliebige Funktionen
realisieren können, wurden mittels Ge-
heimnisteilung (Ben-Or et al. 1988),
Oblivious Transfer (Goldreich et al.
1987) und homomorpher Verschlüsse-
lung (Cramer et al. 2001) entwickelt. Im
Allgemeinen gilt, dass man zusätzliche
Operationen zu der homomorphen Ope-
ration mittels interaktiver Protokolle rea-
lisieren kann.
Die Anwendung im vertraulichkeits-
erhaltenden Cloud-Computing ist weni-
ger offensichtlich. Die Kunden und der
Dienstanbieter führen eine sichere Mehr-
parteienberechnung aus. Der Dienstan-
bieter wird wie eine weitere Partei be-
handelt. Die Kunden liefern die Einga-
ben, und keine Partei – einschließlich des
Dienstanbieters – erfahren mehr, als sie
aus ihrer Eingabe und Ausgabe ableiten
können. Es gilt, die Effizienzanforderun-
gen zum Vorteil der Kunden zu verteilen
(Kerschbaum 2009).
Goldreich (2002) definiert ein forma-
les Sicherheitsmodell für sichere Mehr-
parteienberechnungen. Wie bereits be-
WIRTSCHAFTSINFORMATIK 3|2011

Abb. 1 Überblick über
vertraulichkeitserhaltendes
Cloud-Computing
schrieben darf keine Partei mehr erfah-
ren als das, was aus ihren Ein- und Aus-
gaben ableitbar ist. Ein Sicherheitsbe-
weis kann einen Simulator beschreiben,
dessen statistischer Unterschied zu ei-
nem realen Protokolldurchlauf – nur Ein-
und Ausgabe gegeben – vernachlässig-
bar im Sicherheitsparameter ist. Die zwei
von Goldreich (2002) definierten Model-
le sind halbehrlich und böswillig. Im hal-
behrlichen Modell hält der Angreifer das
Protokoll ein, aber versucht aus den auf-
gezeichneten Nachrichten zusätzliche In-
formationen abzuleiten. Im böswilligen
Modell darf sich der Angreifer beliebig
verhalten.
Es gibt einen Kompilierer für Proto-
kolle, die sicher im halbehrlichen Modell
sind, in Protokolle, die sicher im böswil-
ligen Modell sind (Goldreich 2002), aber
die erzeugten Protokolle sind sehr inef-
fizient. Desweiteren wird im böswilligen
Modell nicht verhindert, dass eine Partei
falsche Eingaben liefert, sodass man an-
nehmen muss, dass die Parteien korrekte
Eingaben liefern, um das korrekte Ergeb-
nis zu erhalten. Wir erörtern dieses Pro-
blem weiter in Abschn. 4.
WIRTSCHAFTSINFORMATIK 3|2011
2.3 Gemeinschaftliches Benchmarking
in der Cloud
Benchmarking hilft Unternehmen, ih-
re Konkurrenzfähigkeit zu erhalten. Ein
KPI ist eine statistische Größe, die die
Leistung eines Geschäftsprozesses misst.
Beispiele aus verschiedenen Unterneh-
mensbereichen sind Maschinenlaufzeit
(Produktion), Cashflow (Finanzen) und
Fluktuation (Personal). Eine Vergleichs-
gruppe ist eine Gruppe (meist konkur-
rierender) Unternehmen, die ein Interes-
se am Vergleich ihrer KPIs haben. Bei-
spiele mit verschiedenen Charakteristika
sind Automobilhersteller (Industriesek-
tor), Fortune-500-Unternehmen in den
USA (Umsatz und Herkunftsland), oder
Fluglinien, Eisenbahn- und Transportun-
ternehmen (Absatzmarkt).
Es gibt n Kunden Xi und einen Cloud-
Dienstanbieter SP. Jeder Kunde Xi hat
einen KPI Wert xi – wir betrachten je-
den KPI einzeln. Sie wollen verschiedene
Statistiken über x1 , . . . , xn berechnen –
wir betrachten auch jede Vergleichsgrup-
pe einzeln. Die folgenden Funktionen
werden häufig beim individuellen Bench-
marking verwendet: Arithmetisches Mit-
tel, Varianz, Maximum, Median und bes-
ter Viertelwert.
WI – AUFSATZ
Das Cloud-Computing-Paradigma
schreibt vor, dass jeder Kunde Xi nur mit
dem Dienstanbieter SP kommuniziert,
d. h. wir unterbinden direkte Kommuni-
kation zwischen den Kunden. In diesem
zentralen Kommunikationsmodell ent-
spricht ein böswilliger Dienstanbieter
einem Angreifer, der das Netzwerk kon-
trolliert, und die entsprechenden Sicher-
heitsherausforderungen, wie z. B. kein
Schlüsselaustausch ohne vertrauenswür-
dige dritte Partei, bleiben bestehen.
Unser Schutzziel ist die Vertraulichkeit
des KPI Wertes xi des Kunden Xi , d. h.
weder einem anderen Kunden Xj (j = i)
noch dem Dienstanbieter SP soll xi be-
kannt werden.
2.4 Lösungsüberblick
In den nächsten Abschnitten betrachten
wir mehrere Designmöglichkeiten. Der
Bezug zum gesamten Design vertrau-
lichkeitserhaltenden Cloud-Computings
wird in Abb. 1 dargestellt. In die-
sem Lebenszyklus der Berechnung erfolgt
zunächst die Schlüsselverteilung (Ab-
schn. 5). Dann liefern die Parteien ihre
verschlüsselten Eingaben (Abschn. 6) zur
sicheren Berechnung, deren Funktionen
131
WI – AUFSATZ
wir detailliert beschreiben (Abschn. 3).
Danach wird das (verschlüsselte) Ergeb-
nis zurückgegeben, wobei spezielle Siche-
rungsmaßnahmen ergriffen werden (Ab-
schn. 4).
3 Vertraulichkeit
Sichere Mehrparteienberechnungen ga-
rantieren die Vertraulichkeit eines KPIs
innerhalb einer Vergleichsgruppe, aber
unsere Cloud-Anwendung soll mehre-
re Vergleichsgruppen und mehrere KPIs
handhaben. Die Berechnungen mehrerer
KPIs überschneiden sich nicht, denn sie
sind unabhängig voneinander. Hingegen
können sich mehrere Vergleichsgruppen
überschneiden, da sie gemeinsame Teil-
nehmer enthalten können.
Es sei λi,j = 1, falls Xi in der j-ten
Vergleichsgruppe teilnimmt, und λi,j = 0
andernfalls. Da die Anzahl Kunden in ei-
ner Vergleichsgruppe bekannt ist, kann
man die Berechnung der arithmetischen
Mittel s1 , . . . , sj wie folgt schreiben
s = Λx.
Falls Λ invertierbar oder pseudo-
invertierbar ist, kann jeder Teilnehmer
die Eingaben aus den Ausgaben aus-
rechnen. In diesem Fall ist jegliche si-
chere Berechnung (oder homomorphe
Verschlüsselung) überflüssig. Ein Sicher-
heitsbeweis für das Klartext-Protokoll
wäre möglich, aber irrelevant. Es gibt
keinen Sicherheitsmechanismus, der in
diesem Fall verhindert, die Eingaben
aus den Ausgaben zu erschließen, und
deshalb kann diese Funktionalität nicht
als vertraulichkeitserhaltende Cloud-
Anwendung realisiert werden. Dieses
Problem entsteht, falls eine Untermen-
ge aus linear abhängigen Vektoren und
dem Element der Partei, dessen KPI Wert
offengelegt wird, besteht.
Es gibt zwei mögliche Gegenmaßnah-
men. Erstens, der Cloud-Dienstanbieter
kann nur solche Vergleichsgruppen zu-
lassen, die keinen solchen Fall enthal-
ten. Zweitens, der Kunde nimmt nur
an sicheren Vergleichsgruppenzuweisun-
gen teil. Die zweite Maßnahme hat
den Vorteil, dass der Kunde überprü-
fen kann, dass die Vertraulichkeit sei-
nes KPI-Werts gewährleistet bleibt. Zu-
dem muss eine gegebenenfalls abgelehnte
Vergleichsgruppenteilnahme nicht vom
Cloud-Dienstanbieter erklärt werden. Er-
schwerend kommt hinzu, dass die Teil-
nahmeentscheidung einer Partei die Ver-
gleichsgruppenzuweisung für eine andere
132
Partei unsicher machen kann. Die einzi-
ge Zuweisungsregel, die all diese Proble-
me verhindert, ist, den KPI einer Partei
höchstens einer Vergleichsgruppe zuzu-
weisen, da bereits bei einer Zuweisung zu
zwei Vergleichsgruppen linear abhängige
Vektoren entstehen können.
4 Nutzenkompatibler
Mechanismus
Jede gemeinschaftliche Anwendung im-
plementiert einen Mechanismus aus der
Spieltheorie. Bei gegebener Nutzenfunk-
tion verhalten sich rationale Spieler so,
dass ein Gleichgewicht entsteht. Wir
betrachten in diesem Abschnitt eini-
ge herausragende Ergebnisse für unsere
Benchmarking-Anwendung.
Ein grundlegendes Problem vertrau-
lichkeitserhaltender Berechnung ist, dass
Eingaben nicht mehr extern auditier-
bar sind. Der Cloud-Dienstanbieter so-
wie andere Kunden können sich nicht
auf die Korrektheit der Eingaben einer
anderen Partei verlassen. Selbst im bös-
willigen Sicherheitsmodell gibt es kei-
ne Sicherungsmaßnahme, die wahrheits-
gemäße Eingaben erzwingen kann. Eine
problemgebundene Lösung ist, die An-
reize der Spieler zu untersuchen, ob es ih-
rer Nutzenmaximierung entspricht, kor-
rekte Eingaben zu liefern. Eine spieltheo-
retische Analyse hilft unter der Annahme
rationaler Teilnehmer.
Zunächst müssen wir annehmen, dass
alle Spieler ein Interesse am Erhalt rich-
tiger Ergebnisse aus der Berechnung ha-
ben. Wären nur einige Spieler nicht dar-
an interessiert, das richtige Ergebnis zu
erhalten, so würden sie falsche Eingaben
liefern. Das führt wiederum zu einem
Gleichgewicht, bei dem kein Spieler rich-
tige Eingaben liefert.
Probleme entstehen bei der Annahme,
dass Spieler auch daran interessiert sind,
Informationen über die Eingaben ande-
rer Spieler zu erhalten oder diesen das Er-
gebnis vorzuenthalten, d. h. bei einer ge-
mischten Nutzenfunktion.
Das erste Hauptergebnis ist die Spe-
zifikation nichtkooperativ berechenbarer
Funktionen (Shoham und Tennenholtz
2005). Vereinfacht ausgedrückt ist eine
nichtkooperativ berechenbare Funktion
eine, die weder von einer Eingabe domi-
niert wird (d. h. von einer Eingabe bere-
chenbar ist) noch invertierbar ist. Im Fall
invertierbarer Funktionen wären Spieler
geneigt, falsche Eingaben zu liefern und
dann die Funktion zu invertieren und so
das richtige Ergebnis zu errechnen. Die
Schlussfolgerung von Shoham und Ten-
nenholtz (2005) ist, dass Summe, arith-
metisches Mittel und Maximum nicht
nichtkooperativ berechenbar sind, hin-
gegen Median und höchster Viertelwert
schon.
Das zweite Hauptergebnis ist, dass das
Gleichgewicht sicherer Mehrparteienbe-
rechnungen ist, diese nicht durchzufüh-
ren. Die Spieler haben nämlich kein In-
teresse daran, ihre Lösungsanteile aus-
zutauschen (Halpern und Teague 2004;
Abraham et al. 2006). Jede Partei, die
ihre Lösungsanteile an andere Parteien
schickt, nutzt nur diesen, d. h. sie han-
delt nicht im besten Eigeninteresse, da sie
nur die Anteile der anderen Parteien für
die Gesamtlösung benötigt. Halpern und
Teague (2004) beschreiben das erste Pro-
tokoll, das dieses Problem umgeht. Dieses
wurde später von Abraham et al. (2006)
verbessert.
Erfreulicherweise gibt es das zweitge-
nannte Problem beim Cloud-Computing
nicht. Dabei kann man von einem
Dienstanbieter ausgehen, der daran in-
teressiert ist, seinen Kunden das richtige
Ergebnis zu liefern und so ein nachhal-
tiges Geschäft aufzubauen (Kerschbaum
2009). Der Dienstanbieter agiert dann als
Intermediär, der die Ergebnisse an al-
le Parteien weiterleitet, da er von dieser
Weiterleitung und nicht nur vom Ergeb-
nis an sich profitiert.
Beim vertraulichkeitserhaltenden
Cloud-Computing mit verschlüsselten
Daten gibt es ein weiteres Problem. Ange-
nommen der Dienstanbieter hat das Er-
gebnis berechnet, aber es ist immer noch
homomorph mit dem kundeneigenen
Schlüssel verschlüsselt. In gemeinschaftli-
chen Anwendungen gibt es meist nur ein
Ergebnis, das aber zugleich von mehreren
Kunden begehrt wird. Zudem ist die Ent-
schlüsselung in der Verarbeitungsphase
meist von der Ergebnisübermittlung ge-
trennt. Der folgende einfache Angriff
ist für den Dienstanbieter rational: Er
gibt allen Parteien ihre verschlüsselten
Eingaben zurück, erhält deren Klartex-
te und berechnet das Ergebnis aus den
Klartexten, welches er wiederum zur Er-
gebnisverwendung zur Verfügung stellt.
So hat er das richtige Ergebnis geliefert
(und seine Nutzenfunktion maximiert)
und alle Eingaben erfahren.
Es gibt zwei Möglichkeiten, diesen
Angriff zu unterbinden. Erstens, der
Dienstanbieter darf nur einen Kunden
bitten, das Ergebnis zu entschlüsseln. Da
aber die Kunden nicht untereinander
WIRTSCHAFTSINFORMATIK 3|2011

kommunizieren sollen, kann der ausge-
wählte nicht feststellen, ob er der einzi-
ge ist. Zweitens, der Dienstanbieter sen-
det das gleiche Chiffrat an alle Kunden.
Dies kann durch elektronische Signatu-
ren des Kunden überprüft werden. Dies
verhindert jeden Angriff auf die Vertrau-
lichkeit, falls das richtige Ergebnis gelie-
fert wird (Kerschbaum 2008).
5 Schlüsselverteilung
und -management
Die homomorphe Verschlüsselung ver-
wendet einen Schlüssel, um die Informa-
tionen zu schützen. Um Chiffrate verar-
beiten zu können, müssen sie alle mit
dem gleichen Schlüssel verschlüsselt sein.
Dieser Schlüssel muss geheim gehalten
werden, da andernfalls die Vertraulich-
keit der Daten gefährdet ist.
Der Designer hat die folgenden Alter-
nativen
 einfacher oder Schwellwert-Schlüssel,
 statischer oder dynamischer Schlüssel,
 Schlüsselaustausch, der gegenüber pas-
siven oder aktiven Angreifern abgesi-
chert ist.
Der Schlüsselaustausch sollte sicher in
Bezug auf den gleichen Angreifertyp wie
die sichere Verarbeitung sein, da die Ge-
samtkonstruktion nur so sicher wie das
schwächste Glied sein wird. In Abschn. 4
haben wir unser Protokoll gegen einen
rationellen aktiven Angreifer gesichert
und deshalb muss der Schlüsselaustausch
sicher gegen einen (stärkeren) aktiven
Angreifer sein.
Schlüsselaustauschprotokolle, die si-
cher gegenüber einem aktiven Angrei-
fer sind, brauchen eine vertrauenswürdi-
ge dritte Partei, z. B. die Zertifikatsstel-
le in Public Key Infrastructures (PKI).
Auch unser Schlüsselaustauschprotokoll
braucht eine solche und diese kann nicht
der Dienstanbieter selbst sein, weil dies
das Niveau auf eine Sicherheit gegenüber
passiven Angreifern reduzieren würde (d.
h. man erwartet, dass die vertrauenswür-
dige dritte Partei sich erwartungsgemäß
verhält).
Falls eine dritte Partei am Schlüsselaus-
tausch teilnimmt, wären zwei Dienstan-
bieter notwendig. Es kann daher vor-
teilhaft sein, statische Schlüssel zu wäh-
len und die dritte Partei auf eine einma-
lige Interaktion zu beschränken. Dyna-
mische Schlüssel bedingen einen Schlüs-
selaustausch für jeden Verarbeitungsvor-
gang und sollten nur verwendet werden,
WIRTSCHAFTSINFORMATIK 3|2011
wenn der Schlüsselaustausch ohne Inter-
aktion mit der vertrauenswürdigen drit-
ten Partei erfolgen kann, z. B. mittels
PKI. Man beachte, dass die öffentlichen
Schlüssel in der PKI, wie jeder statische
Identifier, die Anonymität der Teilneh-
mer verletzen, da sie als statisches Pseud-
onym verwendet werden können.
Die Auswirkungen der Entscheidung
zwischen einfachen oder Schwellwert-
schlüsseln sind nicht immer klar. Auf der
einen Seite kann ein einfacher Schlüs-
sel die Sicherheit des gesamten Sys-
tems gefährden, wenn er kompromit-
tiert wird. Diese Gefahr besteht aber be-
sonders für statische Schlüssel, die auf
permanenten Medien gespeichert wer-
den. Allerdings kann jede Absprache zwi-
schen einem Dienstanbieter und einem
Kunden die Sicherheit des Systems ver-
letzen, selbst bei dynamischen Schlüs-
seln. Auf der anderen Seite bedeutet
ein Schwellwertschlüssel nicht automa-
tisch Sicherheit gegen betrügerische Ab-
sprachen zwischen Dienstanbieter und
Kunde, da oft Zwischenergebnisse ausge-
tauscht werden müssen, um die Funk-
tionalität teilhomomorpher Verschlüsse-
lung zu erweitern. Im Fall von Benchmar-
king ist die Sicherung gegen Absprachen
zwischen Dienstanbieter und Kunde zu
ineffizient, selbst bei Verwendung eines
Schwellwertschlüssels.
Im Ergebnis wählen wir einen ein-
fachen, dynamischen Schlüssel für die
homomorphe Verschlüsselung, der mit-
tels eines Schlüsselaustauschs sicher ge-
gen aktive Angreifer ohne die aktive Teil-
nahme der Zertifikatsstelle als vertrau-
enswürdige dritte Partei etabliert wird.
6 „Homomorpher“ Vergleich
Bei der Erstellung von Statistiken ist der
Vergleich – neben der Addition – ein
Kernproblem. Vergleichen ist notwendig
für statistische Größen wie den Median.
Im Fall der Benchmarking-Anwendung
kommt erschwerend hinzu, dass die Ein-
gaben verschlüsselt sind.
Es sei E(x) die Verschlüsselung von
x ∈ Zn mit der homomorphen Ver-
schlüsselungsmethode. Das Problem be-
steht darin, einen Algorithmus oder ein
Protokoll zu konstruieren, mit dem der
Dienstanbieter – bei bekanntem E(x) und
E(y) − E(c) berechnen kann, so dass
c = x < y (dargestellt durch Elemente
in Zn ). Voll-homomorphe Verschlüsse-
lung kann dies selbstverständlich errei-
chen, aber Fischlin (2001) beschreibt eine
WI – AUFSATZ
Methode, mit der dies unter Verwendung
der teil-homomorphen Verschlüsselung
von Sander et al. (1999) erreicht werden
kann. Bei dieser Verschlüsselungsmetho-
de wird jedes Bit einzeln verschlüsselt,
sodass keine Additionen mehr möglich
sind. Wir schlagen daher eine Methode
mittels additiv-homomorpher Verschlüs-
selung vor.
Unsere Methode basiert auf Blendung
mittels Multiplikation. Wir bilden die
Ganzzahlen von [−n/2, n/2] auf die
Ganzzahlen von [0, n − 1] vergleichbar
mit der Zweierkomplementnotation ab,
d. h. 0 → 0, n/2 → n/2, −n/2 → n/2 +
1 und −1 → n − 1. Wir können so
die Ganzzahlen [−n/2, n/2] mittels ho-
momorpher Verschlüsselung (modulo n)
verschlüsseln.
Bei gegebenem E(x) und E(y) wählt der
Dienstanbieter zwei Zufallszahlen 0 < r
und 0 ≤ r < r und berechnet
E(c) = (E(x)E(y) − 1)r E(r )
= E(rx − ry + r ).
Es gilt
x < y ⇔ c < 0.
6.1 Informationstheoretische
Vertraulichkeit
Die Korrektheit des homomorphen Ver-
gleichs kann leicht überprüft werden;
hingegen ist die Sicherheit schwierig. Wir
verblenden die Differenz a = x − y der
Klartexte durch Multiplikation mit einer
Zufallszahl r.
b = ra + r
Unser Sicherheitsmodell ist informa-
tionstheoretisch und nicht kryptogra-
phisch. Wir können deshalb die Frage
stellen, was b über a verrät. Man beach-
te zunächst, dass, falls die Bitlänge von r
möglicherweise bekannt ist, dann von der
Bitlänge von b auf die von a geschlossen
werden kann, weil
lgr + lga − 1 ≤ lgb
≤ lgr + lga .
Wir wählen deshalb zunächst die Bitlänge
von r zufällig und dann die übrigen Bits
gleichverteilt.
Wir können nun die Sicherheit des
homomorphen Vergleichs gegenüber ei-
ner Reihe von Angriffen messen. Im ein-
fachsten Fall wird ein Nur-Chiffrat An-
griff auf a mittels b durchgeführt. Das
133
WI – AUFSATZ
informationstheoretische Maß für Infor-
mationsverlust von a durch b ist die be-
dingte Entropie
H(A|B) = −Σp(B = b)Σp(A = a|B = b)
× log p(A = a|B = b).
Leider können wir sie nicht analytisch
lösen, aber wir können sie erproben.
Kerschbaum (2010) hat einen großange-
legten Versuch durchgeführt und einen
Informationsverlust von 0,11 bit für eine
Stichprobe mit 16 bit a und 512 bit r mit
normalverteilter Bitlänge festgestellt.
7 Systemarchitektur
7.1 Komponenten
und Anwendungsfälle
Bisher haben wir nur die kryptogra-
phischen Aspekte des Benchmarking-
Protokolls betrachtet, aber das Gesamt-
system besteht aus mehreren Komponen-
ten und Anwendungsfällen (Kerschbaum
2007). Wir beschreiben kurz die An-
wendungsfälle der Benchmarking-
Anwendung.
 Registrierung: Ein Kunde meldet dem
Dienstanbieter, dass er am Benchmar-
king teilnehmen möchte. Dies bein-
haltet die Erzeugung eines Benut-
zerkontos, Bezahlung, im Falle stati-
scher Schlüssel dessen Verteilung und
löst die Vergleichsgruppenbildung aus.
Die Teilnehmer der Registrierung sind
der Kunde, der Dienstanbieter und
die Zertifikatsstelle. Die einzige Vor-
aussetzung für die Registrierung ist
die Systemkonfiguration zwischen ver-
trauenswürdiger dritter Partei (Zer-
tifikatsstelle) zum Schlüsselaustausch
und dem Dienstanbieter. Falls PKI ver-
wendet wird, ist das die Installation
des Wurzelzertifikats beim Dienstan-
bieter. Die Registrierung ist Vorausset-
zung, damit die Vergleichsgruppenbil-
dung durchgeführt werden kann.
 Vergleichsgruppenbildung: Die Re-
gistrierung löst die Vergleichsgruppen-
bildung aus, bei der dem Kunden ei-
ne Vergleichsgruppe zum Benchmar-
king zugewiesen wird. Wir betrachten
dies als eigenen Anwendungsfall auf-
grund seiner Komplexität und den ver-
schiedenen Designmöglichkeiten mit-
tels verschiedener Teilnehmer. Wir be-
schreiben einen Algorithmus, um je-
den Kunden einer Vergleichsgruppe
zuzuweisen. Wie bereits erwähnt, darf
134
jeder Kunden höchstens in einer Ver-
gleichsgruppe sein, um Vertraulichkeit
zu gewährleisten. Die Vergleichsgrup-
penbildung kann die Zuweisung von
Kunden zu Vergleichsgruppen ändern
für andere Kunden als den, der sich
gerade registriert hat. Wir führen die
Vergleichsgruppenbildung aber auto-
matisch durch, sodass der einzige An-
wendungsfallteilnehmer der Dienstan-
bieter ist. Die Voraussetzung ist, dass
sich ausreichend Kunden registriert
haben. Die Vergleichsgruppenbildung
ist Voraussetzung für die verbleiben-
den zwei Anwendungsfälle: Statistika-
bruf und Statistikberechnung.
 Statistikabruf: Nachdem sich ein Kun-
de registriert hat und ihm eine Ver-
gleichsgruppe zugewiesen wurde, kann
er mit dem Benchmarking anfangen.
Beim Benchmarking wird eine Ana-
lyse der eigenen KPIs im Vergleich
zur Gruppe durchgeführt und dazu
müssen die Statistiken vom Dienstan-
bieter abgerufen werden. Man beach-
te, dass ein Kunde mit dem Bench-
marking beginnen kann, sobald er ei-
ner Vergleichsgruppe zugewiesen wur-
de. Er muss nicht die Statistikberech-
nung abwarten, d. h. er kann die Sta-
tistiken selbst dann abrufen, wenn sei-
ne KPIs nicht bei deren Berechnung
berücksichtigt wurden. Dies erhöht
den Kundennutzen, indem es Warte-
zeiten verringert. Der Dienstanbieter
hält eine Datenbank mit den Statisti-
ken zum Zugriff bereit. Die Vorausset-
zung ist, dass die Vergleichsgruppen-
bildung durchgeführt wurde. Es gibt
keine Nachfolgebedingungen.
 Statistikberechnung: Der Dienstan-
bieter löst das Benchmarking-
Protokoll aus, um die Statistiken zu be-
rechnen. Die Herausforderung besteht
natürlich darin, diese Berechnung mit
verschlüsselten Daten durchzuführen.
Die Berechnung ist vom Abruf ge-
trennt, d. h. benutzerunabhängig. Die
Teilnehmer des Anwendungsfalles sind
alle Kunden in einer Vergleichsgruppe
und der Dienstanbieter. Die Voraus-
setzung ist, dass die Vergleichsgrup-
penbildung durchgeführt wurde, und
es gibt keine Nachfolgebedingungen.
Das Prinzip, die Benutzerinteraktion
(Benchmarking) von der sicheren Be-
rechnung zu entkoppeln ist entscheidend
für den Umgang mit den Effizienzbe-
schränkungen durch die Berechnung mit
verschlüsselten Daten. Dies ist zwar im
Cloud-Computing unüblich, wird aber
auch in anderen real eingesetzten siche-
ren Berechnungen aufgegriffen (Bogetoft
et al. 2009).
7.2 Vergleichsgruppenbildung
Die Vergleichsgruppenbildung wird
durch die Registrierung eines neuen
Kunden ausgelöst, wird aber selbsttä-
tig vom Dienstanbieter durchgeführt.
Das Ziel der Vergleichsgruppenbildung
ist es, so Gruppen zu bilden, dass die
Teilnehmer am besten vom gegenseitigen
Benchmarking profitieren. Die zugrun-
deliegende Annahme ist, dass je ähnlicher
die Teilnehmer sind, umso effektiver das
Benchmarking ist.
Wir behandeln die Vergleichsgruppen-
bildung als Datenklassifikationsproblem.
Wir wollen jedem Kunden eine Klasse
zu weisen, seine Vergleichsgruppe. Wäh-
rend der Registrierung sendet der Kunde
zunächst unsensible Charakteristika sei-
ner selbst an den Dienstanbieter. Diese
Charakteristika sollten relativ stabil für
das eigene Unternehmen sein, aber zwi-
schen Unternehmen variieren. Sie sollten
zudem für das Geschäftsmodell des Un-
ternehmens relevant sein und ihre Kom-
bination sollte weitestgehend eindeutig
sein.
Diese Charakteristika bilden einen m-
dimensionalen Raum, in dem jedes Un-
ternehmen einen Punkt repräsentiert.
Das Datenklassifikationsproblem ist nun,
den Raum so einzuteilen, dass die Punkte
in den so entstehenden Teilräumen mög-
lichst geringe räumliche Ausdehnung ha-
ben. Dies wird als Datenclustering be-
zeichnet.
Der schnellste aufteilende Daten-
clustering-Algorithmus ist k-Durch-
schnittclustering. Gegeben einen Para-
meter k bildet er k Cluster durch Mini-
mierung des Abstands zum Clustermit-
telpunkt. K-Durchschnittclustering ist
randomisiert, d. h. er findet nicht immer
das Optimum, sondern sein Ergebnis ist
ein Zufallselement einer Menge nahezu
optimaler Lösungen.
K-Durchschnittclustering, wie auch je-
der andere unveränderte Clusteringal-
gorithmus, ist nicht direkt auf Ver-
gleichsgruppenbildung anwendbar. Um
die Vertraulichkeit der KPIs zu gewähr-
leisten, muss jede Vergleichsgruppe eine
minimale Größe besitzen. Diese Rand-
bedingung muss vom Datenclustering-
Algorithmus eingehalten werden. Ben-
nett et al. (2000) verwenden Lineare Pro-
grammierung, um die Distanz zum Clus-
termittelpunkt zu minimieren bei gleich-
WIRTSCHAFTSINFORMATIK 3|2011

zeitiger Einhaltung der Randbedingun-
gen. Leider skaliert dieser Ansatz nicht zu
den Problemgrößen, die bei Vergleichs-
gruppenbildung auftreten können, und
wir brauchen einen Ansatz, der die Effizi-
enz des k-Durchschnittclusterings erhält.
Kerschbaum (2007) beschreibt k, l-
Durchschnittclustering, das eine gieri-
ge Variante von k-Durchschnittclustering
ist, bei der die Cluster mindestens die
Größe l haben. The Idee dahinter ist
wie folgt: In jeder Runde des Algorith-
mus wird über die Cluster iteriert, bis
alle Cluster mindestens Größe l haben.
Falls ein Cluster weniger als l Elemen-
te enthält, „holt“ er sich die nächstgele-
genen Elemente dazu, bis er l Elemen-
te hat. Man muss Buch führen, ob ein
Element den Cluster gewechselt hat und
jedes Element darf pro Runde maximal
einmal den Cluster wechseln, um Endlos-
schleifen zu verhindern. Zum Abschluss
der Iteration hat jeder Cluster mindestens
l Elemente.
Wir haben die Qualität der Vergleichs-
gruppenbildung evaluiert. In Zusam-
menarbeit mit Industrieexperten wur-
de ein Qualitätsmaß für Vergleichs-
gruppen definiert. Der maximale Ab-
stand einer Charakteristik wird dazu
verwendet: je geringer dieser Abstand
ist, um so besser. Wir haben k, l-
Durchschnittclustering mit verschiede-
nen Abstandsmetriken und verschiede-
nen Clustergrößen evaluiert. Überra-
schenderweise hat die Abstandsmetrik
kaum Einfluss. Wir haben den Euklidi-
schen Abstand gewählt, aber das Clus-
tering wurde mit größerer Minimalgrö-
ße l besser, falls künstlich Cluster in die
Eingabe eingefügt wurden. Das bedeu-
tet, dass k, l-Durchschnittclustering bes-
ser als k−Durchschnittclustering funk-
tionert, falls die Clustergröße l bekannt
ist.
Wie in Abschn. 7.1 beschrieben, wird
die Vergleichsgruppenbildung durch die
Registrierung eines neuen Kunden aus-
gelöst. Es reicht daher aus, diesen neu-
en Kunden einem bestehenden Cluster
zuzuweisen anstatt ein vollständig neues
Datenclustering durchzuführen. Dies re-
duziert auch die Anzahl der Vergleichs-
gruppen, für die neue Statistiken be-
rechnet werden müssen. Daher wählen
wir einfach die nächste Vergleichsgruppe
für den neuen Kunden und teilen diese
Gruppe in zwei, falls eine Größenschwel-
le überschritten wird. Um die Gruppe
aufzuteilen, können wir wiederum k, l-
Durchschnittclustering verwenden. Der
WIRTSCHAFTSINFORMATIK 3|2011
Abb. 2 Effizienz von Benchmarking auf Basis von verschlüsselten Daten
Qualitätsnachteil durch diese inkremen-
telle Vergleichsgruppenbildung im Ver-
gleich zur vollen Vergleichsgruppenbil-
dung ist vernachlässigbar.
8 Effizienz
Die Effizienz von Berechnungen ver-
schlüsselter Daten bleibt entscheidend
und es gibt nur wenige experimentelle
Evaluierungen. Unser Benchmarking-
Protokoll hat quadratische O(n2 )
Berechnungs- und Kommunikations-
komplexität. Wir haben unser Protokoll
zur Statistikberechnung implementiert.
Gemäß der gegenwärtigen Praxis in der
Industrie haben wir die Protokolle mit
Webdiensten als Kommunikationsme-
thode implementiert (Kerschbaum et
al. 2009). Jeder Client und Server führt
einen eigenen Webapplikationsserver mit
einer Protokollimplementierung als We-
banwendung aus. Die Implementierung
ist vollständig in Java geschrieben, wo-
bei die Kryptographiemodule auf die
Java-BigInteger-Arithmetik in der Stan-
dardbibliothek zugreifen.
Wir haben die Implementierung
im folgenden Aufbau evaluiert. Als
Dienstanbieter wird ein Pentium 4
3,2 GHz Rechner mit 1,5 GB Speicher
verwendet. Für alle Kunden wird ein Xe-
on Dual 3.6 GHz Rechner mit 8 GB Spei-
cher eingesetzt. Zwischen den Client-
und Server-Rechner haben wir einen
WAN-Emulator als Router geschaltet.
Die WAN-Emulationssoftware war die
dummynet Software für FreeBSD (Rizzo
1997). Alle Rechner waren über einen
nicht dedizierten Gigabit-Ethernet-
Switch verbunden.
WI – AUFSATZ
Im ersten Experiment haben wir die
Anzahl Clients von 5 bis 45 in Schritten
von 5 und die Netzwerklatenz für die Ver-
bindung von 0 bis 100 Millisekunden in
Schritten von 25 erhöht. Die Latenz wird
verwendet, um WAN-Bedingungen über
das Internet zu simulieren. Eine Verzöge-
rung von 100 ms ergibt eine Rundreise-
zeit (RTT) von 200 ms, die ungefähr der
RTT über das Internet zwischen Deutsch-
land und Japan entspricht.
Das Experiment hat aufgezeigt, dass
die Netzwerkeffizienz von entscheiden-
der Bedeutung ist. Bei 45 Clients und ei-
ner Verzögerung von 100 ms nimmt die
Zeit zur Netzwerkkommunikation fast
die Hälfte der gesamten Laufzeit ein.
Im nächsten Experiment haben wir die
Server-Implementierung verändert. An-
statt jeden Client der Reihe nach aufzu-
rufen, haben wir einen Thread für je-
den Client erzeugt, der asynchron kom-
muniziert. Dies wird im Benchmarking-
Protokoll dadurch ermöglicht, dass jede
Runde für jeden Client nur die Eingaben
der vorherigen Runde benötigt und alle
Clients parallel ausgeführt werden kön-
nen. Die Reihenfolge der Clients spielt
im Protokollablauf keine Rolle. Die Syn-
chronisation zwischen den Runden er-
folgt mittels einer Barriere.
Wir haben die gleichen Experimen-
te für die nebenläufige Implementierung
durchgeführt. Wir haben die Anzahl der
Clients und unabhängig davon die Netz-
werklatenz erhöht. Die Ergebnisse sind
in Abb. 2 dargestellt. Der Einfluss der
Netzwerkeffizienz ist deutlich zurückge-
gangen und ist fast vernachlässigbar im
Vergleich zum Berechnungsaufwand. Bei
45 Clients und einer Verzögerung von
100 ms nimmt die Zeit zur Netzwerk-
135
WI – AUFSATZ
kommunikation nur 6 % der gesamten
Laufzeit ein.
Wir schließen daraus, dass Berechnun-
gen auf verschlüsselten Daten in der
Cloud so implementiert werden können,
dass die Effizienz nahezu unabhängig von
der Netzwerkeffizienz ist, d. h. für die Ge-
samtlaufzeit ist es fast irrelevant, ob die
Clients an demselben lokalen Netzwerk
oder am anderen Ende der Welt am In-
ternet angeschlossen sind.
9 Verwandte Arbeiten
Gemeinschaftliche Benchmarking-An-
wendungen wurde bereits von Boge-
toft und Nielsen (2005) beschrieben
und implementiert. Zusätzlich zum pa-
rametrischen (statistischen) haben sie
das nicht parametrische Benchmarking
mittels Data Envelope Analysis (DEA)
implementiert. DEA verwendet Linea-
re Programmierung, die momentan in
der Praxis noch nicht sicher berech-
net werden kann, obwohl es theoreti-
sche Protokolle (Li und Atallah 2006;
Toft 2009) gibt.
Sichere Berechnungen wurden für
Benchmarking erstmals von Atallah et
al. (2004) vorgeschlagen. Sie haben ei-
ne Reihe von sicheren Divisionsproto-
kollen beschrieben, um Zeitreihen zu
realisieren. In unserem Fall statistischen
Benchmarkings können Zeitreihen der
eigenen Daten und der Statistiken lokal
mittels der Klartexte berechnet werden.
Verschlüsselung ist nicht notwendig, weil
der Schutz der KPIs in der Aggregation
zu Statistiken besteht.
Es gibt auch eine Reihe sicherer Be-
rechnungsarten für Statistiken. Beson-
ders Aggarwal et al. (2004) beschreiben
ein effizientes Protokoll zur Medianbe-
rechnung. Wie andere sichere Berech-
nungsarten geht es von verteilten, sich
gegenseitig misstrauenden Parteien aus,
und die Anwendung auf Dienstanbie-
ter in der Cloud ist nicht offensichtlich.
Wenn man es unverändert anwendet, ist
es nicht effizienter als unser Protokoll.
Es gibt auch einige Protokolle zur si-
cheren Berechnung von Statistiken mit
einem zentralen Dienstanbieter. Di Cre-
scenzo (2000) beschreibt ein Protokoll
zur Summenbildung und Di Crescenzo
(2001) beschreibt ein Protokoll für das
Maximum. Beide verwenden einen halb-
ehrlichen Dienstanbieter und vermeiden
so das Problem des Schlüsselaustauschs,
aber das einfache Hinzufügen einer Zerti-
fikatsstelle macht die Protokolle in einem
136
stärkeren Sicherheitsmodell auch nicht
sicherer.
Eine weitere Herausforderung liegt
darin, die Protokolle für verschiedene
Statistiken zu verbinden und trotzdem
effizient zu bleiben. Unser homomorpher
Vergleich ist die einzige uns bekannte
und effizienteste Methode zum Vergleich
additiv-homomorph verschlüsselter Da-
ten (Kerschbaum und Terzidis 2006). Ein
ähnlicher Ansatz wurde später von Saku-
ma und Kobayashi (2007) verfolgt. Ihr Si-
cherheitsbeweis ist insofern fragwürdig,
da sie nicht die Wahrscheinlichkeiten der
verschiedenen Fälle betrachten, sondern
nur zeigen, dass es für jeden eine Bele-
gung gibt. Von daher liefert der Informa-
tionsverlust, wie von uns vorgeschlagen,
eine deutlich klarere Aussage.
Unser homomorpher Vergleich kon-
kurriert mit einer großen Anzahl siche-
rer Vergleichsberechnungen; um nur ei-
nige zu nennen (Damgard et al. 2008;
Fischlin 2001; Yao 1986). Diese Proto-
kolle realisieren einen sicheren „Größer-
als“-Vergleich zweier geheimer Eingaben,
der auch als Yao’s Millionärsproblem be-
kannt ist, das nach dem ersten Protokoll
von Yao (1986) benannt wurde. Das mo-
mentan schnellste Protokoll von Dam-
gard et al. (2008) verwendet eine bekann-
te Eingabe und wir haben nachgewie-
sen, dass das schnellste Protokoll mit zwei
geheimen Eingaben von Fischlin (2001)
deutlich langsamer als unser homomor-
pher Vergleich ist (Kerschbaum und Ter-
zidis 2006).
Die einzige andere praktisch eingesetz-
te sichere Berechnung wird von Bogetoft
et al. (2006; verbessert in 2009) beschrie-
ben. Sie realisiert eine sichere Auktion.
Die Autoren implementierten die gleiche
Trennung von Benutzerinteraktion und
Berechnung wie wir und beschränken die
Berechnungen auf eine konstante Anzahl
Server, d. h. sie verwenden mehrere, aber
sich gegenseitig misstrauende Dienstan-
bieter. Obwohl dieses Modell nicht direkt
auf Cloud-Computing angewendet wer-
den kann, so könnte es doch einen neu-
en Dienstanbieter hervorbringen, der er-
kennbar an sicheren Berechnungen betei-
ligt ist. Es wird über ähnliche Laufzeiten
wie bei uns berichtet.
Es gibt eine Reihe weiterer Rahmen-
werke zur Implementierung sicherer Be-
rechnungen mittels generischer Proto-
kolle. Das erste für sichere Zweiparteien-
berechnungen war FairPlay (Malkhi et al.
2004). Später kamen VIFF (2010), Sha-
reMind (2010) und FairPlayMP (Ben-
David et al. 2008) für sichere Mehr-
parteienberechnungen hinzu. Alle bauen
auf generischen Protokollen für sichere
Berechnungen auf, die jegliche Funkti-
on realisieren können. Da sie aber nicht
für diese Funktionen optimiert sind,
wird man sehen, ob sie angesichts ihrer
hohen Rechenleistungsanforderungen je-
mals praktisch eingesetzt werden.
Wir kennen keine andere in der Lite-
ratur beschriebene Berechnung auf Ba-
sis verschlüsselter Daten in der Cloud
mittels homomorpher Verschlüsselung
(Gentry 2009). Unsere Erfahrungen im
Design der Benchmarking-Anwendung
sind von daher die ersten und wir hoffen
ausreichend Erkenntnisse für die weitere
Forschung geschaffen zu haben.
10 Zusammenfassung
und Ausblick
In diesem Beitrag haben wir vertraulich-
keitserhaltendes Cloud-Computing un-
tersucht, d. h. die Verarbeitung in der
Cloud auf Basis verschlüsselter Daten.
Wir haben die verschiedenen Gestal-
tungsmöglichkeiten am Beispiel einer
Cloud-Anwendung zum gemeinschaft-
lichen Benchmarking untersucht. Die-
se überwindet die Bedrohung der Ver-
traulichkeit seitens des Dienstanbieters
durch Verarbeitung auf Basis verschlüs-
selter Daten und verringert dadurch die
notwendigen Vertrauensannahmen. Wir
vergleichen die Modelle homomorpher
Verschlüsselung und sicherer Mehrpar-
teienberechnungen und realisieren ein
hybrides Modell zur Effizienzsteigerung.
Unsere Erfahrungen im Aufbau dieser
Cloud-Anwendung haben eine Reihe von
Erkenntnissen hervorgebracht, die weit-
läufigen Annahmen widersprechen.
Erstens, Datenverschlüsselung reicht
nicht aus. Die Information, die aus
dem Ergebnis abgeleitet werden kann,
kann die Rekonstruktion der Eingaben
beinhalten. Es ist daher notwendig, die
auf verschlüsselte Daten angewendeten
Funktionen sorgfältig zu planen und zu
evaluieren. In unserem Fall war es not-
wendig, alle Kunden auf die Teilnahme
an einer Vergleichsgruppe pro KPI zu be-
schränken. Wir können nachweisen, dass
bei ausreichender Größe der Vergleichs-
gruppe der KPI-Wert geheim bleibt.
Man beachte, dass es bisher keine for-
malen Werkzeuge oder Methoden gibt,
die diese Analyse unterstützen, und des-
halb muss sie von qualifizierten For-
schern und Ingenieuren manuell durch-
geführt werden. Dies bietet eine gute
Möglichkeit für die weitere Erforschung
WIRTSCHAFTSINFORMATIK 3|2011
 WI – AUFSATZ

von formalen Methoden und Werkzeu-

gen, um die Sicherheit von Anwendun- Zusammenfassung / Abstract
gen zu verifizieren.
Florian Kerschbaum
Zweitens, Sicherheit und Geschäftszie-
le müssen aufeinander abgestimmt wer-
den. Es ist schwierig, vielleicht so- Sicheres und nachhaltiges Benchmarking in der Cloud
gar unmöglich, alle Angriffe eines bös- Eine Mehrparteien-Cloud-Anwendung ohne vertrauenswürdigen Dienstanbieter
willigen Angreifers auf verschlüsseltes
Cloud-Computing zu unterbinden, weil Durch Cloud-Computing entsteht eine neue Sicherheitsbedrohung: Dem Cloud-
die Eingaben verschlüsselt sind und so Dienstanbieter werden die Daten aller seiner Kunden anvertraut. Dies kann die Nach-
Denial-of-Service-Angriffe ermöglichen. haltigkeit bei streng vertraulichen Daten verhindern. Verschlüsselung, oder allgemei-
Deshalb müssen die Ziele der Cloud- ner Kryptographie, kann diesen Konflikt durch kundenseitige Verschlüsselung der zu
Anwendung den wirtschaftlichen Zielen verarbeitenden Daten lösen. Obwohl diese Lösung theoretisch überzeugend ist, er-
der Teilnehmer entsprechen. gibt sich eine Reihe neuer Forschungsfragestellungen bei der Gestaltung betriebli-
In unserer Benchmarking-Anwendung cher Informationssysteme.
verwenden wir nutzenkompatible Statis- Am Beispiel gemeinschaftlichen Benchmarkings werden das Design und die Im-
tiken und verbessern die Sicherheit in plementierung einer Cloud-Anwendung beschrieben und evaluiert, die nur mit ver-
Bezug auf ökonomisch motivierte An- schlüsselten Daten arbeitet und dadurch die Vertraulichkeit der Kundendaten gegen-
greifer. Dies bedeutet, dass manche ein- über dem Dienstanbieter gewährleistet. Die Cloud-Anwendung berechnet unterneh-
fachen Protokolle, die nur gegen passi- mensübergreifende Statistiken im Rahmen des Benchmarkings, ohne dabei die ein-
ve Angreifer sicher sind, nicht mehr ver- zelnen Kennzahlen offenzulegen.
wendet werden können, wie z. B. der Benchmarking ist wichtig für Unternehmen, um die Wettbewerbsfähigkeit zu er-
Schlüsselaustausch mittels des Dienstan- halten. So können sie anhand von Statistiken ihre Leistung mit der Konkurrenz ver-
bieters, und dass wir eine vertrauenswür-
gleichen und gegebenenfalls gezielte Verbesserungsmaßnahmen einleiten.
dige, dritte Partei (Zertifikatsstelle) zum
Schlüsselaustausch benötigen. Allerdings Schlüsselwörter: Cloud-computing, Verschlüsselung, Kryptographie, Homomor-
ist unser Protokoll das erste uns bekann- phe Verschlüsselung, Sichere Mehrparteienberechnungen, Benchmarking, Gemein-
te Protokoll, das effizienter gegen einen schaftliche Geschäftsanwendungen
rationalen Angreifer als gegen einen bös-
willigen ist. Wir nehmen an, dass es vie- Secure and Sustainable Benchmarking in Clouds
le solcher Fälle gibt und erwarten weitere A Multi-Party Cloud Application with an Untrusted Service Provider
Forschungen und Entwicklungen.
Drittens, der Vergleich homomorph ver- Cloud computing entails a novel security threat: The cloud service provider is en-
schlüsselter Ganzzahlen ist möglich. Un- trusted with the data of all its customers. This may not be sustainable for highly con-
ser Ergebnis entstand vor der Entwick-
fidential data. Encryption, or more generally cryptography, may provide a solution by
lung voll-homomorpher Verschlüsselung
computing on data encrypted by the customers. While this solution is theoretically
und hat weitere Anwendungen außer
appealing, it raises a number of research questions in information system design.
dem Vergleich. Unsere Vergleichsmetho-
Using the example of collaborative benchmarking the author presents and evalu-
de passt nicht zu bestehenden, formalen
ates an exemplary design and implementation of a cloud application that operates
Sicherheitsmodellen, aber wir haben ein
only on encrypted data, thus protecting the confidentiality of the customer’s data
weiteres entwickelt und erwarten weite-
against the cloud service provider. The cloud application computes common statis-
re wissenschaftliche Ergebnisse in diesem
tics for benchmarking without disclosing the individual key performance indicators.
Bereich. Eine Herausforderung scheint es
zu sein, diese Methode auf weitere Be- Benchmarking is an important process for companies to stay competitive in today’s
rechnungen außer dem Vergleich auszu- markets. It allows them to evaluate their performance against the statistics of their
dehnen und wir suchen nach generellen peers and implement targeted improvement measures.
Erkenntnissen. Keywords: Cloud computing, Encryption, Cryptography, Homomorphic encryption,
Viertens, der Berechnungsaufwand Secure multi-party computation, Benchmarking, Collaborative business applications
bleibt entscheidend. Obwohl wir nach-
weisen konnten, dass der Berechnungs-
aufwand für Benchmarking akzeptabel
ist, gilt dies nicht notwendigerweise für
aufwendigere Berechnungen. Die Bench-
markingfunktionen können lokal in
15 ms berechnet werden. Im Vergleich
zum Benchmarkingprotokoll ist dies ein
Faktor von ca. 60.000. Der Vergleich
ist nicht ganz gerecht, da eine sichere
Cloud-Anwendung immer zusätzlichen
Aufwand zur sicheren Übertragung und
Speicherung erbringen muss, aber wir
konnten nachweisen, dass die Netzwer-
keffizienz bei Parallelisierung unwichtig

WIRTSCHAFTSINFORMATIK 3|2011 137

WI – AUFSATZ
ist. Das größte Hindernis ist daher der
Berechnungsaufwand.
In diesem Punkt übertrifft unser ho-
momorpher Vergleich auch deutlich an-
dere homomorphe Verschlüsselungen,
wie Gentry’s voll-homomorpher (Gentry
2009) oder Fischlin’s Bitvergleich (Fisch-
lin 2001), weil wir die Effizienz additiver,
teil-homomorpher Verschlüsselung aus-
nutzen.
Wir nehmen an, dass die Effizienz-
steigerung die größte Forschungsaufga-
be des Rechnens mit verschlüsselten Da-
ten bleibt. Es ist eine wirtschaftliche Fra-
ge, ob die Anwendung die zusätzlichen
Ausgaben für Rechenkapazität und Ant-
wortwartezeit rechtfertigt. Falls die Kryp-
tographie nicht schnell effiziente Lösun-
gen bietet, wird sich die Industrie wahr-
scheinlich nach Alternativen umsehen.
In der momentanen, schnellen Entwick-
lung des Cloud-Computings kann so ei-
ne Chance verpasst werden, da es an-
scheinend keine technischen Alternativen
zum präventiven Schutz gegen Vertrau-
lichkeitsbrüche durch den Dienstanbieter
gibt.
Fünftens, die Trennung von Benut-
zerinteraktion und Berechnung kann neue
Möglichkeiten eröffnen. In Anwendun-
gen, die diese Trennung unterstützen,
wie unser gemeinschaftliches Benchmar-
king, kann sie eine alternative Gestaltung
ermöglichen, die beim Benutzer höhe-
re Akzeptanz findet. Außerdem kann der
Dienstanbieter die Berechnungen besser
planen und so die Rechenkapazität bes-
ser ausnutzen. Dies wurde bereits von der
ersten Anwendung aufgegriffen (Bogetoft
et al. 2009) und wir erwarten, dass Weite-
re diesem Modell folgen werden.
Literatur
Abraham I, Dolev D, Gonen R, Halpern JY
(2006) Distributed computing meets game
theory: robust mechanisms for rational se-
cret sharing and multiparty computation.
In: Proc 25th ACM symposium on principles
of distributed computing, S 53–62
Aggarwal G, Mishra N, Pinkas B (2004) Secure
computation of the kth-ranked element. In:
Proc Eurocrypt, S 40–55
Atallah M, Bykova M, Li J, Frikken K, Topkara M
(2004) Private collaborative forecasting and
benchmarking. In: Proc ACM workshop on
privacy in an electronic society, S 103–114
Ben-David A, Nisan N, Pinkas B (2008) Fair-
PlayMP: a system for secure multi-party
138
computation. In: Proc 15th ACM confer-
ence on computer and communications
security, S 257–266
Bennett K, Bradley P, Demiriz A (2000)
Constrained K-means clustering. Microsoft
technical report
Ben-Or M, Goldwasser S, Wigderson A
(1988) Completeness theorems for non-
cryptographic fault-tolerant distributed
computation. In: Proc 20th ACM sympo-
sium on theory of computing, S 1–10
Bogetoft P, Christensen D, Damgard I,
Geisler M, Jakobsen T, Kroigaard M,
Nielsen J, Nielsen J, Nielsen K, Pagter J,
Schwartzbach M, Toft T (2009) Secure
multiparty computation goes live. In: Proc
13th international conference on financial
cryptography and data security, S 325–343
Bogetoft P, Damgard I, Jakobsen T, Nielsen K,
Pagter J, Toft T (2006) A practical imple-
mentation of secure auctions based on
multiparty integer computation. In: Proc
10th international conference on financial
cryptography and data security, S 142–147
Bogetoft P, Nielsen K (2005) Internet based
benchmarking. Group Decision and Nego-
tiation 14(3):195–215
Cramer R, Damgard I, Nielsen J (2001) Mul-
tiparty computation from threshold ho-
momorphic encryption. In: Proc Eurocrypt,
S 280–299
Crotts J, Pan B, Dimitry C (2006) Hospitality
performance index: a case study of devel-
oping an internet-based competitive anal-
ysis and benchmarking tool for hospitality
industry. In: Proc conference of travel and
tourism research association
Damgard I, Geisler M, Kroigard M (2008) Ho-
momorphic encryption and secure com-
parison. International Journal of Applied
Cryptography 1(1):22–31
Damgard I, Jurik M (2001) A generalisation,
a simplification and some applications of
pailliers probabilistic public-key system. In:
Proc international conference on theory
and practice of public-key cryptography,
S 119–136
Di Crescenzo G (2000) Private selective pay-
ment protocols. In: Proc 4th international
conference on financial cryptography and
data security, S 72–89
Di Crescenzo G (2001) Privacy for the stock
market. In: Proc 5th international confer-
ence on financial cryptography and data
security, S 269–288
Eurich M, Oertel N, Boutellier R (2010) The im-
pact of perceived privacy risks on organiza-
tions’ willingness to share item-level event
data across the supply chain. Electronic
Commerce Research 10(3–4):423–440
Fischlin M (2001) A cost-effective pay-per-
multiplication comparison method for mil-
lionaires. In: Proc RSA security cryptogra-
pher’s track, S 457–471
Gentry C (2009) Fully homomorphic en-
cryption using ideal lattices. In: Proc 41st
ACM symposium on theory of computing,
S 169–178
Goldreich O (2002) Secure multi-party com-
putation. http://www.wisdom.weizmann.
ac.il/~oded/pp.html. Abruf am 2011-02-07
Goldreich O, Micali S, Wigderson A (1987)
How to play any mental game. In: Proc 19th
ACM symposium on theory of computing,
S 218–229
Halpern J, Teague V (2004) Rational secret
sharing and multiparty computation: ex-
tended abstract. In: Proc 36th ACM sympo-
sium on theory of computing, S 623–632
Kerschbaum F (2007) Building a privacy-
preserving benchmarking enterprise sys-
tem. In: Proc 11th IEEE international EDOC
conference, S 87–96
Kerschbaum F (2008) Practical privacy-
preserving benchmarking. In: Proc 23rd
IFIP international information security
conference, S 17–31
Kerschbaum F (2009) Adapting privacy-
preserving computation to the service
provider model. In: Proc 1st IEEE interna-
tional conference on privacy, security, risk
and trust, S 34–41
Kerschbaum F (2010) A privacy-preserving
benchmarking platform. Dissertation.
Karlsruhe Institute of Technology
Kerschbaum F, Dahlmeier D, Schröpfer A,
Biswas D (2009) On the practical impor-
tance of communication complexity for
secure multi-party computation protocols.
In: Proc 24th ACM symposium on applied
computing, S 2008–2015
Kerschbaum F, Terzidis O (2006) Filtering
for private collaborative benchmarking. In:
Proc international conference on emerging
trends in information and communication
security, S 409–422
Li J, Atallah M (2006) secure and private col-
laborative linear programming. In: Proc 2nd
international conference on collaborative
computing, S 1–8
Malkhi D, Nisan N, Pinkas B, Sella Y (2004)
Fairplay—a secure two-party computation
system. In: Proc USENIX security sympo-
sium, S 287–302
Paillier P (1999) Public-key cryptosystems
based on composite degree residuosity
classes. In: Proc Eurocrypt, S 223–238
Rizzo L (1997) Dummynet: a simple approach
to the evaluation of network protocols.
ACM Computer Communication Review
27(1):31–41
Sakuma J, Kobayashi S (2007) A genetic
algorithm for privacy preserving combi-
natorial optimization. In: Proc conference
on genetic and evolutionary computation,
S 1372–1379
Sander T, Young A, Yung M (1999) Non-
interactive crypto-computing for NC1. In:
Proc 40th IEEE symposium on foundations
of computer science, S 554–567
ShareMind (2010) http://research.cyber.ee/
sharemind/. Abruf am 2011-02-07
Shoham Y, Tennenholtz M (2005) Non-
cooperative computation: boolean
functions with correctness and exclu-
sivity. Theoretical Computer Science
343(1–2):97–113
Toft T (2009) Solving linear programs using
multiparty computation. In: Proc 13th in-
ternational conference on financial cryp-
tography and data security, S 90–107
VIFF (2010) http://www.viff.dk/. Abruf am
2011-02-07
Yao A (1986) How to generate and exchange
secrets. In: Proc 27th IEEE symposium on
foundations of computer science, S 162–
167
WIRTSCHAFTSINFORMATIK 3|2011