it-swarm.com.de

Wie sicher ist die Ciphersweet-Bibliothek für durchsuchbare Verschlüsselung und warum ist ein doppeltes Eintragsleck kein Problem?

Ich verwalte derzeit eine Codebasis, in der wir eine MySQL-Datenbank haben, in der alle Datensätze mit PHP-Verschlüsselungsbibliothek verschlüsselt sind. Dies funktioniert gut für unser aktuelles Setup. Wir haben jetzt eine neue Geschäftsanforderung, die es ermöglichen sollte, ein SELECT basierend auf einem der verschlüsselten Felder auszuführen.

Da es unmöglich ist, basierend auf den verschlüsselten Werten auszuwählen, habe ich mich umgesehen und ciphersweet gefunden. Es ist ein neues (6 Monate altes) Repo mit derzeit nur 136 Github-Sternen. Ich habe ein Blogpost darüber gelesen, das von der Firma hinter der Bibliothek geschrieben wurde.

Die Idee basiert auf einer blinden Indizierung, bei der die allgemeine Idee darin besteht, einen verschlüsselten Hash (z. B. HMAC) des Klartextes in einer separaten Spalte zu speichern. Der blinde Indexschlüssel sollte sich vom Verschlüsselungsschlüssel unterscheiden und dem Datenbankserver unbekannt sein.

Soweit ich weiß (aber ich könnte mich hier irren), wird der Wert, nach dem ich suchen muss, mit dem Indexschlüssel gehasht, der pro Spalte statisch ist. Der resultierende Wert wird in der Spalte HMAC gesucht. Wenn ein Datensatz gefunden wird, wird der verschlüsselte Wert entschlüsselt.

Sie beschreiben, dass es ein doppeltes Eintragsleck gibt, was bedeutet, dass, wenn alle Datensätze erhalten werden, bekannt sein kann, welche Datensätze den gleichen Wert haben, aber nicht was dieser Wert ist.

Ich verstehe die Konzepte und es klingt in Ordnung, aber da ich kein Kryptographie-Experte bin, kann ich die Sicherheit nicht wirklich beurteilen. Ist es nicht irgendwie möglich, dieses doppelte Eintragsleck für einen anderen Angriff zu verwenden? Ich habe immer gelernt (= im Internet gelesen), dass die Verschlüsselung immer eine IV/Nonce/Salt enthalten sollte, um Rainbow-Tabellen unmöglich zu machen. Ich denke, die Verwendung des statischen Indexschlüssels pro Spalte verhindert diese Rainbow-Tabellen.

Grundsätzlich habe ich das Gefühl, hier etwas zu vermissen. Warum ist das doppelte Eintrittsleck nicht plötzlich ein Problem? Gibt es noch jemanden, der diese Bibliothek/Technologie kommentieren kann?

13
kramer65

Wichtiger Haftungsausschluss: Ich habe CipherSweet für meinen Arbeitgeber geschrieben. Alles, was folgt, sollte mit einem Körnchen Salz eingenommen werden, sofern von Sicherheitsexperten Dritter nichts anderes überprüft wurde. Selbst wenn diese Antwort viele Stimmen erhält, darf sie niemals akzeptiert werden. Ich versuche lediglich, einige der grundlegenden Fragen zum Design von CipherSweet zu beantworten und nicht zu beantworten, ob es sicher ist oder nicht. Vertraue stattdessen anderen.

Das Sicherheitsmodell von CipherSweet ist im Wesentlichen ein Zeit-Speicher-Kompromiss, der das Risiko von Angriffen mit sich bringt, die einem Kreuzworträtsel ähnlicher sind als herkömmliche Kryptoanalyse-Techniken (daher werden sie einfach als "Kreuzworträtsel-Angriffe" bezeichnet, obwohl dies umso mehr der Fall ist Der formale Begriff "teilweise bekannte Klartextangriffe" findet eher relevante Treffer in der akademischen Literatur.

In dieser Hinsicht ist das Gesamtdesign von CipherSweet can sicher, jedoch nur, wenn beim Entwerfen der Blindindizes in Ihrer Anwendung sorgfältig vorgegangen wird. Es gibt einige Überlegungen:

  1. Wie viele Bits jedes Blindindex werden Sie speichern?
    • Weniger Bits erhöhen die Wahrscheinlichkeit von Kollisionen bei einer bestimmten SELECT-Abfrage, was bedeutet, dass nach der Entschlüsselung mehr Fehlalarme herausgefiltert werden müssen.
    • Weniger Bits verringern jedoch auch die Nützlichkeit eines Blindindex.
  2. Wie viele Blindindizes erstellen Sie für eine bestimmte verschlüsselte Spalte?
    • Je mehr Indizes Sie erstellen, desto mehr Metadaten können an Angreifer weitergegeben werden.

Natürlich lohnt es sich nur, über die Sicherheit dieses Entwurfs zu sprechen, wenn einige andere Annahmen zutreffen:

  1. Jeder Blindindex hat einen eigenen Schlüssel.
  2. Die Hash-Funktion (oder KDF), die verwendet wird, um den Klartext in einen blinden Index umzuwandeln, ist ausreichend sicher (z. B. im zufälligen Oracle-Modell).
  3. Die Verschlüsselung selbst ist sicher (z. B. AEAD mit einer Sicherheitsstufe von mehr als 127 Bit gegen alle bekannten praktischen Angriffe).

Um zu verstehen, wie diese Annahmen beantwortet werden, lesen Sie die interne Dokumentation zu CipherSweet . Kurz gesagt, die Antworten sind:

  1. CipherSweet verwendet unterschiedliche Schlüssel pro Feld und pro Index, abgeleitet von einem Hauptschlüssel .
  2. Ab November 2018 bleiben HMAC-SHA384 und BLAKE2b ungebrochen.
  3. Ab November 2018 bleiben AES-CTR + HMAC-SHA2 und XChaCha20-Poly1305 ungebrochen.

Nachdem dies gesagt wurde, lautet die unbeantwortete Frage: Wie bestimmen wir einen unsicheren Grad an Informationsleckage?

  • Erstellen eines eindeutigen Blindindex $plaintext[0], $plaintext[1], ... würde ganze Klartexte aus den Indizes verlieren.
    • In diesem Fall müssten Sie die Verschlüsselung nicht aufheben. Studieren Sie einfach Muster und schreiben Sie Dummy-Einträge fest und behandeln Sie sie als eine sehr ineffiziente Substitutions-Chiffre.
  • Umgekehrt würde ein einzelner Literal Blindindex des gesamten Klartextes, abgeschnitten auf 16 Bit, mit ziemlicher Sicherheit nichts Nützliches für Angreifer verlieren.
    • Bei einem ausreichend großen Datensatz sind Kollisionen sehr häufig.
    • Dies macht natürlich fast den Zweck zunichte, sogar einen Blindindex zu erstellen.

Darüber hinaus können Sie mit CipherSweet zusammengesetzte blinde Indizes erstellen. Zum Beispiel könnten Sie zusammen hashen:

  1. Die erste Initiale des Vornamens der Person (falls zutreffend)
  2. Die erste Initiale des Nachnamens der Person (falls zutreffend)
  3. Die letzten 4 Ziffern der Sozialversicherungsnummer der Person
  4. Ein einzelner Buchstabe, in dem das Geschlecht angegeben ist (falls zutreffend)

Dies erhöht den Schlüsselraum möglicher Klartexte für einen bestimmten Blindindex erheblich, selbst wenn der Schlüsselraum jeder einzelnen Eingabe begrenzt ist. Dies ist besonders nützlich für Verschlüsseln/Suchen mit booleschen Feldern .


Angesichts all der oben genannten Punkte weiß ich nicht, ob Sie eine ausreichende Antwort darauf erhalten, ob Sie CipherSweet auf dieser Website vertrauen sollen oder nicht. Die unbeantworteten Fragen sind nicht gerade einfach zu beantworten und erfordern eine eingehende Analyse.

Davon abgesehen: Es ist sicherlich möglich, Missbrauch CipherSweet auf eine Weise zu verwenden, die seine Sicherheitsziele untergräbt. Es ist ein Werkzeug.

Ich glaube, dass es möglich sein sollte, CipherSweet sicher zu verwenden, es sei denn, es wurde ein tiefer Fehler im Protokolldesign entdeckt. SOLLTE sein. Und selbst wenn es sicher ist, möchten Sie mit ziemlicher Sicherheit, dass ein Sicherheitsexperte überprüft, wie Sie es verwenden.

12

Haftungsausschluss : Während ich mich mit dem Design und der Implementierung von ciphersweet befasste, als es veröffentlicht wurde (oder zumindest als ich davon erfuhr), führte ich keine vollständige Prüfung und keinen vollständigen Sicherheitsnachweis durch des Designs, und ich habe mich nicht eingehend mit der PHP Implementierung) befasst (in großen Teilen, weil ich nicht viel mache PHP Arbeit). Nicht Verwechseln Sie dies mit einem Prüfungsbericht (ich mache diese nur, wenn ich dafür bezahlt werde: P)

Ciphersweet verwendet ein hübsches, langweiliges Design. Scott erklärt es zusammen mit den Sicherheitsansprüchen von Cyphersweet in seiner Antwort, damit ich nicht noch einmal darauf eingehen werde. Der Hauptpunkt von Ciphersweet, IMO, ist, dass es sicherer und schwieriger ist, Fehler zu machen als die Alternativen.

Das von Ihnen erwähnte „Duplicate Entry Leak“ gilt nicht für vollständige Datensätze (diese werden mit standardmäßiger, nicht deterministischer Verschlüsselung verschlüsselt), sondern für die Blindindizes: Wenn Sie beispielsweise den HIV-Status indizieren, hat jemand Lesezugriff auf die Datenbank kann herausfinden, welche Datensätze denselben HIV-Status haben, und von dort wahrscheinlich den HIV-Status für alle Datensätze wiederherstellen.

Dies ist ein Informationsleck, das für blinde Indizes grundlegend ist: Wenn Sie über genügend Informationen verfügen, um SELECT alle Zeilen mit einer bestimmten (Funktion von Wenn Sie den HIV-Status haben, verfügen Sie über genügend Informationen, um zu überprüfen, ob zwei Zeilen denselben HIV-Status haben. Daher hilft eine ausgefallenere Kryptografie dort nicht (einschließlich deterministischer Verschlüsselung, auftragserhaltender/aufschlussreicher Verschlüsselung, ...).

Die gute Nachricht ist, dass verschlüsselte Hashes (unter einem unbekannten Schlüssel) im Gegensatz zu anderen Designs (wie der Verschlüsselung, die die Reihenfolge offenbaren) nicht mehr Informationen enthalten, als ob die Werte gleich sind.

Offensichtlich ist dies nicht ausreichend (wie im Beispiel für den HIV-Status gezeigt), daher können Sie drei Hauptminderungen anwenden (und Ciphersweet unterstützt sie alle):

  1. am naheliegendsten ist es, keine blinden Indizes für sehr sensible Daten hinzuzufügen: Wenn Sie keine HIV-Statusdaten offenlegen möchten, warum erstellen Sie einen Index, um diese effizient abzufragen?

  2. Verwenden Sie zusammengesetzte Indizes: Wenn die Daten, auf die Sie indizieren müssen, zu entropiearm sind, um sicher in einen Blindindex (z. B. HIV-Status) aufgenommen zu werden, können Sie sie zusammen mit einigen anderen Daten hashen (in der Dokumentation wird die SSN verwendet) Beispiel) und unterstützen SELECT Datensätze mit einem bestimmten HIV-Status nd einer bestimmten SSN.

    Dies ist, IMO, die weniger nützliche Option, da Sie direkt SELECT per SSN (vorausgesetzt, Sie haben einen Blindindex über SSNs) und dann den HIV-Status im entschlüsselten Datensatz überprüfen können. Reservieren Sie es für Fälle, in denen Sie entweder keinen Index für eines der Felder haben können (weil sie alle zu niedrig entropisch und/oder zu empfindlich sind).

  3. schneiden Sie den HMAC-Wert ab, um das Informationsleck zu verringern: Nehmen wir an, Sie haben Patientenakten, alle mit einem eindeutigen Namen, und unterstützen die Auswahl durch diese [0]. Ich könnte überprüfen, ob ein bestimmter Patient existiert, indem ich einen Datensatz (über die Anwendung) mit diesem Namen hinzufüge und dann in der Datenbank nach einem zweiten Datensatz mit demselben Namens-Hash suche, selbst wenn die Anwendung selbst mir nicht die Berechtigung zum Suchen erteilen würde Patienten mit Namen.

    Mit einem abgeschnittenen Hash können Sie festlegen, dass bei jeder Suche im Blindindex (im Durchschnitt) eine kleine Anzahl von Datensätzen zurückgegeben wird. sagen Sie, wenn Sie durchschn. 3 Datensätze pro Abfrage, von 1 000 000 Datensätzen möchten Sie einen Hash mit der Größe log2 (10⁶/3) ~ 18 Bit. Dies macht das von mir beschriebene Szenario unmöglich.

    Ich denke nicht, dass Ciphersweet eine besondere Unterstützung für die Weiterentwicklung der Größe der Blindindizes bietet, wenn die Größe Ihrer Datenbank zunimmt, obwohl dies machbar sein sollte. Glücklicherweise ist das einzige Problem, bei dem die Größe eines Blindindex nicht geändert wird, wenn die Datenbank wächst, ein geringfügiger Leistungsaufwand: Wenn Ihre Datenbank 10-mal größer wird und jetzt 10 000 000 Datensätze enthält, führt die Beibehaltung des gleichen 18-Bit-Blindindex zu einem Durchschnitt. Es werden 30 Datensätze ausgewählt, die die Anwendung dann entschlüsselt und filtert. Das Entschlüsseln von 30 Datensätzen, um den zu finden, an dem Sie interessiert sind, sollte immer noch recht schnell gehen.

[0] In einem realen Anwendungsfall würden Sie wahrscheinlich die Auswahl des Namens durch eine normalisierte (in Kleinbuchstaben, ohne Interpunktion) Version unterstützen. Ciphersweet unterstützt Funktionsindizes.

TL; DR: Ciphersweet ist sicher, wahrscheinlich viel mehr als die meisten Alternativen; Es gibt einige Einschränkungen, die Sie beachten müssen, die in allen verschlüsselten Datenbanken vorhanden sind, und einige betriebliche Probleme, die jedoch alle sehr überschaubar sind.