Fragen? Antworten! Siehe auch: Alternativlos
Homomorphe Verschlüsselung ist ein Treppenwitz der Informatik. Ich rege mich da seit Jahren drüber auf. Das ist ein Taschenspielertrick, um den Cloud-Vertrieblern zu ermöglichen, den Leuten ins Gesicht zu lügen, man könne seine Datenbank in die Cloud schieben, ohne dem Cloud-Anbieter vertrauen zu müssen.
Ich will das daher mal kurz erklären.
Die Idee ist, dass man die Daten mit absichtlich kaputtgemachten Verfahren "verschlüsselt".
Wieso sage ich kaputtgemacht? Weil die Daten in "verschlüsselter" Form noch vergleichbar sein sollen. Je nachdem welche Verarbeitung man noch machen können will, desto kaputter wird die Verschlüsselung.
Nehmen wir mal an, ich schicke dir und deinem Nachbarn eine verschlüsselte Mail, und in beiden steht der gleiche Text. Dann ist der Ciphertext (die verschlüsselte Version) selbstverständlich unterschiedlich! Das leuchet hoffentlich direkt intuitiv ein, wieso das so gemacht wird. "Das ist derselbe Text, den er auch dem Nachbarn geschickt hat" ist ja Teil des Inhalts, den wir geheimhalten wollen! Weswegen wir überhaupt Verschlüsselung verwenden!
Bei homomorpher Verschlüsselung in der stärksten Version (bei der man nur Gleichheit testen können will) ist diese Eigenschaft aufgehoben. Wenn zum Beispiel zwei Leute das gleiche Geburtsdatum haben, dann kommt in der Datenbank auch das gleiche "verschlüsselte" Geburtsdatum raus. Das ist keine Schwäche sondern gerade das Ziel und Versprechen von homomorpher Verschlüsselung, dass man damit Datenbankoperationen machen kann. Die schwächste Anforderung, die man an Datenbankoperationen haben kann, ist dass man noch auf Gleichheit testen will.
Weitere Stufen, die die "Verschlüsselung" noch heftiger schwächen, wären Kleiner/Größer-Vergleiche. Das wäre für viele Webseiten die Mindestanforderung, weil die ja anhand des Datums gucken können wollen, ob derjenige über 18 ist.
In der Forschung geht es noch weiter, da gibt es auch Modelle, bei denen noch Addition und Subtraktion gehen soll auf den "verschlüsselten" Daten.
Aber Fefe, fragt ihr jetzt, was ist denn daran so schlimm?
Na stellen wir uns doch mal gemeinsam einen Angreifer vor. Der Angreifer hat die Datenbank erfolgreich angegriffen. Wir haben die Datenbank homomorph verschlüsselt, damit er mit den Daten nichts anfangen kann.
Erstes Problem: Der Angreifer will deinen Datensatz finden. Lösung: Dann loggt er sich bei der Datenbank mit deinem Usernamen ein und guckt, welchen Datensatz in der Datenbank der Webserver haben will. Damit hat er deinen "verschlüsselten" Usernamen und den Datensatz.
Problem 2: Als nächstes will der Angreifer deine Kreditkartennummer entschlüsseln. Wie macht er das? Er macht einen anderen Account auf, und trägt dann da eine Kreditkartennummer ein. Wenn die homomorphe Verschlüsselung noch Gleichheit testen erlauben will, dann kann der Angreifer einfach bei seinem Testaccount Kreditkartennummer durchprobieren. Der Webserver verschlüsselt die Nummer homomorph und trägt die in die Datenbank ein. Dort kann der Angreifer die verschlüsselte Version seiner Test-Nummer sehen. Wenn die verschlüsselte Nummer übereinstimmt, hat der Angreifer deine Kreditkartennummer erfolgreich geraten.
Bei allen diskreten Datensatztypen funktioniert dieser Durchprobieransatz. Ist aber möglicherweise nicht sehr effizient. Wenn die Datenbank Vergleiche auf kleiner und größer erlaubt mit ihrer homomorphen Verschlüsselung, ist das Durchprobieren eine Sache von Sekunden, weil man sich per Binärsuche annähern kann anstatt zufällig herumzustochern.
Ja aber Fefe, dass jemand sowohl die Datenbank kopiert und live beobachten kann, welche Anfragen reinkommen, das ist doch ein total unrealistisches Bedrohungsmodell!1!!
Ist es? Ich dachte homomorphe Verschlüsselung sollte dafür sorgen, dass ich die Datenbank in der Cloud haben kann, und nicht dem Cloudprovider vertrauen muss?
Der Cloudprovider kann die Datenbank abgreifen und die Anfragen sehen. Das ist genau das Bedrohungsszenario, für das dieser Scheiß angeblich gedacht war.
Kurz gesagt: Wenn euch jemand homomorphe Verschlüsselung andrehen will, lacht ihn aus. Am besten ins Gesicht. Öffentlich.
Und ich kann nur sagen: Intel setzt ihre Reihe von Innovationen, die sich als Sicherheitslücken herausstellen, auch unter Pat Gelsinger fort.
Schade.
Genau wie Intel Konkurrenz von AMD brauchte, braucht AMD Konkurrenz von Intel. Nicht dass Intel sich jetzt so ins Abseits schießt, dass AMD am Ende das neue Intel wird.
Oh und eine andere Sache, die an dieser Stelle hoffentlich intuitiv klar ist: Wenn der Webserver vor der Datenbank auch in der Cloud ist, dann bringt homomorphe Verschlüsselung überhaupt nichts.
Update: OK ich muss da vielleicht stärker differenzieren. Was homomorphe Verschlüsselung laut wissenschaftlicher Literatur ist, ist Berechnungen auf verschlüsselten Daten, also Addition und Multiplikation. Was homomorphe Verschlüsselung im Marketing ist, ist was ich oben beschreibe.
Wenn man sich komplett darauf zurückzieht, was die Wissenschaft beschreibt, ist es nicht ganz so kontraproduktiv wie ich oben beschreibe. Allerdings lässt es sich dann auch nicht für "du kannst deine Datenbank verschlüsselt in die Cloud tun" nutzen, denn du kannst ja nur Berechnungen durchführen, nicht einen Index auf das Feld haben, denn um im Index einer Datenbank etwas nachzuschlagen, musst du gleich und/oder kleiner-größer Vergleiche haben. Und, Spoiler: Der Index ist, was die Datenbank zur Datenbank macht. Kurz gesagt: Das ist eine Lösung, die noch nach ihrem Problem sucht.
Die Erkenntnis, dass das Frontend dann nicht in der Cloud sein darf, die gilt ja immer noch. Und findet mal das Frontend, das im Moment nicht in der Cloud läuft. Das ist ja gerade der Teil, den du weltweit verteilen willst, wegen der Skalierbarkeit.
Und die Berechnung muss glaube ich noch erfunden werden, die so teuer ist, dass sie teurer ist als die Daten homomorph zu verschlüsseln.
Und, wenn man genau hinguckt: Wieso würde man denn Berechnungen verschlüsselt in der Cloud durchführen wollen, wenn die Datenbank mit den Daten woanders ist? Was ist hier das Business Model? Dass du deine Datenbank unter Tisch stehen hast, aber die Daten darin einmal verschlüsselt in die Cloud exportierst, damit die eine bestimmte Liste von Operationen darauf durchführen können, dir andere verschlüsselte Daten zurückgeben, und die entschlüsselst du dann und tust sie wieder in die Datenbank?
I call bullshit.
Außer ... ja, außer die Berechnung auf den Daten ist "geheim". Das könnte hier das Endgame sein. Das es nicht darum geht, wo deine Daten lagern, sondern dass dir der Laden, der die Berechnungen macht, nicht verraten will, was sie da eigentlich genau berechnen. Sozusagen Algorithm as a service. Wo es nicht darum geht, ob du dem Anbieter vertraust, sondern dass der Anbieter dir nicht genug vertraut, um dir den Code zu geben, damit du ihn auf deinen Daten ausführen kannst.
Für diese krasse Umkehrung des Computing ist die Welt hoffentlich nicht blöde genug.