it-swarm.com.de

Welche Strategie zum Verschlüsseln von Daten, auf die mehrere Benutzer zugreifen?

Ich benötige Vorschläge, um meine Datenbankarchitektur (im Kontext einer Webanwendung) unter dem bestimmten Punkt ihrer Verschlüsselung zu entwerfen. zu wissen, dass die folgenden Elemente beachtet werden müssen:

1 - Daten müssen in der Datenbank sicher verschlüsselt sein

Dies dient dazu, sich vor Angreifern zu schützen, und vor allem, damit die Benutzer wissen, dass selbst die Mitarbeiter nicht auf ihre Daten zugreifen können. Daher darf das Tech-Team nicht auf die Schlüssel zugreifen können.

2 - Daten werden auf Benutzerkonten übertragen

(was bedeutet: Jeder Benutzer hat seinen eigenen Datensatz, der mit seiner Benutzer-ID verknüpft ist)

Daher dachte ich, das Kennwort des Benutzers als Verschlüsselungsschlüssel zu verwenden, aber dies verursacht ein Problem: Wenn der Eigentümer der Daten beschließt, das Kennwort zu ändern, müssen die Daten neu verschlüsselt werden, und dies würde die Serverleistung zu stark beanspruchen.

- Der Eigentümer der verschlüsselten Daten muss anderen Benutzern Zugriff auf seine Daten gewähren können

(bedeutet: Es gibt ein Einladungssystem, auf das andere eingeladene Benutzer ganz oder teilweise zugreifen können.)

Dies macht es unmöglich, das Passwort des Benutzers zum Verschlüsseln der Daten zu verwenden, da wir unser Passwort nicht teilen möchten.

Also habe ich über eine Verschlüsselung mit privatem/öffentlichem Schlüssel nachgedacht, aber der private Schlüssel muss irgendwo gespeichert werden. Durch das Speichern in der Datenbank wird lediglich die gesamte Verschlüsselung unbrauchbar. Das Speichern auf der Clientseite ist ebenfalls nicht möglich, da dadurch der Zugriff auf die Anwendung von den einzigen Computern eingeschränkt wird, auf denen der private Schlüssel installiert ist.

4 - Andere Benutzer können von diesem Zugriff ausgeschlossen werden

Das heißt, wenn wir die Lösung für den privaten/öffentlichen Schlüssel in Betracht ziehen, müssen wir in der Lage sein, den privaten Schlüssel zu löschen, der dem widerrufenen Benutzer übergeben wurde.

Jeder Vorschlag zur Architektur eines solchen Systems oder jede Idee, die ich inspirieren könnte, ist sehr willkommen. Vielen Dank


pdate

Bisher scheint der beste Ansatz darin zu bestehen, die Daten mit einem asymmetrischen Schlüssel zu verschlüsseln (ich nenne ihn den Datenschlüssel ) und dann den zu verschlüsseln privater Teil des Datenschlüssels mit einem symmetrischen Schlüssel (der das Passwort des Benutzers ist).

Es scheint eine gute Lösung zu sein; Es gibt jedoch einige Probleme, an die ich denken kann:

  • Wenn sich ein Benutzer anmeldet, muss sein eindeutiges Kennwort auf der Serverseite gespeichert werden, während die Sitzung geöffnet ist, da für jede Anforderung Daten entschlüsselt werden müssen. Dies ist eine Sicherheitslücke, da ein Hacker auf alle offenen Sitzungen zugreifen und das Kennwort seines Benutzers in clear speichern kann.

  • Wenn die Daten gemeinsam genutzt werden (d. H. Ein Eigentümer gewährt einem eingeladenen Benutzer Zugriff), wird der Datenschlüssel mit dem eindeutigen Kennwort des Eigentümers entschlüsselt und anschließend mit dem eindeutigen Kennwort des eingeladenen Benutzers verschlüsselt. Das Problem ist, dass Eigentümer und eingeladener Teilnehmer nicht gleichzeitig angemeldet sein müssen. Daher kennt der Server das eindeutige Kennwort des eingeladenen Benutzers zum Zeitpunkt der Einladung nicht und kann die Daten nicht verschlüsseln. Schlüssel.

  • Wenn ein Benutzer sein Passwort verliert und eine neue Passwortgenerierung anfordert, verliert er alle seine Daten, die nicht mehr entschlüsselt werden können

18
Benj

TL; DR: Generieren Sie ein Datenschlüsselpaar, verschlüsseln Sie den privaten Teil mit dem öffentlichen Schlüssel aller Benutzer mit Schreibzugriff und verschlüsseln Sie den öffentlichen Teil mit dem öffentlichen Schlüssel aller Benutzer mit Lesezugriff.


Lassen Sie uns dies einzeln angehen:

  1. Daten müssen in der Datenbank sicher verschlüsselt sein

Dies dient dazu, sich vor Angreifern zu schützen, und vor allem, damit die Benutzer wissen, dass selbst die Mitarbeiter nicht auf ihre Daten zugreifen können. Daher darf das Tech-Team nicht auf die Schlüssel zugreifen können.

Angesichts dieser Anforderung ist die wichtigste Eigenschaft, die Sie berücksichtigen müssen, dass der Server unter keinen Umständen die Informationen erhalten kann, die zum Ver- oder Entschlüsseln der Daten erforderlich sind. Dies impliziert, dass die gesamte Verschlüsselung/Entschlüsselung auf der Clientseite erfolgen muss . Da das webbasierte System von Natur aus unsicher ist, wenn Sie eine End-to-End-Verschlüsselung durchführen müssen, kann der Server JavaScript-Code bei Bedarf einfügen. Je sicherheitsbewusster Benutzer die Client-Software steuern möchten, die für den Zugriff auf den Dienst verwendet wird, desto mehr möchten sie diese als Desktop-Anwendung implementieren.

  1. Daten werden auf Benutzerkonten übertragen
  2. Der Eigentümer der verschlüsselten Daten muss anderen Benutzern Zugriff auf seine Daten gewähren können

Diese beiden Einschränkungen bedeuten, dass mehrere Benutzer die Daten entschlüsseln müssen. Dies bedeutet, dass das Geheimnis zum Entschlüsseln der Daten für die anderen Benutzer freigegeben werden muss.

  1. Andere Benutzer können von diesem Zugriff ausgeschlossen werden

Das heißt, wenn wir die Lösung für den privaten/öffentlichen Schlüssel in Betracht ziehen, müssen wir in der Lage sein, den privaten Schlüssel zu löschen, der dem widerrufenen Benutzer übergeben wurde.

Um den Zugriff zu widerrufen, müssen Sie die Daten mit einem neuen Schlüssel neu verschlüsseln. Als andere Antworten haben diskutiert können Sie keine Vergesslichkeit erzwingen.

Der beste Weg, dies zu beschreiben, ist vielleicht ein Beispiel.


Notationen:

  • P(x) ist der private Schlüssel mit dem Namen x.
  • Q(x) ist der passende öffentliche Schlüssel für x.
  • e = E(d, Q(x)) bedeutet, dass e das Ergebnis der Verschlüsselung von Klartext d mit dem öffentlichen Schlüssel x ist.
  • d = D(e, P(x)) bedeutet, dass d das Ergebnis der Entschlüsselung des Chiffretextes e mit dem privaten Schlüssel x ist.

Angenommen, Alice möchte Daten an Bob, Charlie und Dave weitergeben. Alice möchte Bob erlauben, die Daten lesen und schreiben zu können, Charlie kann die Daten lesen, aber keine gültigen Daten erzeugen, und Dave kann nur schreiben, aber nicht entschlüsseln, was andere geschrieben haben (im Wesentlichen ist es ein Ablageordner für Dave).

Alle Benutzer haben Benutzer-Schlüssel-Paare. P(Alice), Q(Alice) ist Alices Benutzerschlüsselpaar; P(Bob), Q(Bob) ist Bobs Benutzerschlüsselpaar; P(Charlie), Q(Charlie) ist Charlies Benutzerschlüssel; und P(Dave), Q(Dave) ist Daves Benutzer-Schlüssel-Paar.

Das System verfügt über eine Benutzerschlüsselregistrierung, in der Benutzer den öffentlichen Teil ihres Benutzerschlüssels freigeben können. Wie ein Benutzer den Benutzerschlüssel eines anderen Benutzers sicher abrufen und authentifizieren kann, geht über den Rahmen dieser Antwort hinaus und wird dem Leser als Übung überlassen. Die meisten Benutzer vertrauen möglicherweise einfach auf die Zugriffsbeschränkungen, die Sie auf Ihrem Server festgelegt haben, aber die sicherheitsbewussteren Benutzer müssten etwas Ähnliches tun wie eine GPG-Schlüsselsignaturpartei.

Von allen Benutzern wird erwartet, dass sie den privaten Teil ihres Benutzerschlüssels für sich geheim halten. Die Vorgehensweise im Detail würde den Rahmen dieser Antwort sprengen, aber Sie möchten den privaten Benutzerschlüssel definitiv nicht unverschlüsselt auf dem Server speichern. Stattdessen kann das, was ich vorschlage, den Benutzerschlüssel mit einem symmetrischen Schlüssel verschlüsseln, der aus dem Benutzerkennwort und einem Salt abgeleitet ist, und dann den verschlüsselten Benutzerschlüssel und das Salt auf dem Server speichern.

Um die Daten "Hello World" sicher zu speichern, generiert Alice zunächst ein Datenschlüsselpaar : P(data), Q(data). Alice verschlüsselt dann die Daten mit dem öffentlichen Schlüssel data-key :

plaintext = "Hello World"
ciphertext = E(plaintext, Q(data))

Aufgrund der Eigenschaften der Kryptographie mit öffentlichen Schlüsseln wissen wir, dass ciphertext nur von jemandem entschlüsselt werden kann, der P(data) kennt. (Beachten Sie, dass der Begriff "privat" und "öffentlich" für einen Datenschlüssel nur eine Frage der Konvention ist. Sowohl P(data) als auch Q(data) müssen vor allen Personen geheim gehalten werden, die sie nicht benötigen. wie der Server)

Alice möchte, dass Bob und Charlie diese Daten lesen können, also ruft Alice den öffentlichen Schlüssel Q(Bob) und Q(Charlie) von Bob und Charlie ab und verschlüsselt P(data) mit ihnen. Damit Alice die Datei in Zukunft möglicherweise von einem anderen Computer aus entschlüsseln kann, führt Alice denselben Vorgang mit ihrem eigenen öffentlichen Schlüssel aus:

alice_read_key = E(P(data), Q(Alice))
bob_read_key = E(P(data), Q(Bob))
charlie_read_key = E(P(data), Q(Charlie))

Alice möchte, dass Bob und Dave Daten schreiben können, die von Alice, Bob und Charlie gelesen werden können. Alice möchte auch in Zukunft die Daten aktualisieren können. Um dies zu tun, verschlüsselt Alice den öffentlichen Datenschlüssel Q(data) mit Q(Alice), Q(Bob) und Q(Dave):

alice_write_key = E(Q(data), Q(Alice))
bob_write_key = E(Q(data), Q(Bob))
charlie_write_key = E(Q(data), Q(Charlie))

Alice sendet dann alle encrypted_key, alice_read_key, bob_read_key, charlie_read_key, alice_write_key, bob_write_key Und charlie_write_key Zum Server.

Da der Server/Angreifer niemals im Besitz von P(data) oder Q(data) ist und der Server auch nicht über den privaten Schlüssel verfügt, um einen der read_keys, Den Server, zu entschlüsseln wäre nicht in der Lage, ciphertext zu entschlüsseln.

Wenn Charlie die Daten abrufen möchte, muss er sowohl ciphertext als auch charlie_read_key Herunterladen und charlie_read_key Mit seinem privaten Benutzerschlüssel entschlüsseln, um P(data) und dann mit P(data)ciphertext entschlüsseln:

P(data) = D(charlie_read_key, P(Charlie))
plaintext = D(ciphertext, P(data))

Jetzt ist Charlie im Besitz von plaintext. Da Charlie jedoch keinen Schreibschlüssel hat, verfügt er nicht über eine Q(data), sodass er die Daten im System nicht so aktualisieren kann, dass andere sie erfolgreich entschlüsseln können.

Als nächstes muss Dave in der Lage sein, die Daten zu ergänzen. Er kann das ciphertext nicht lesen, aber er kann es anhängen, indem er seinen Schreibschlüssel entschlüsselt, um das Q (Daten) zu erhalten:

new_plaintext = "New Data"
Q(data) = D(dave_write_key, P(Dave))
new_ciphertext = E(new_plaintext, Q(data))
updated_ciphertext = ciphertext + new_ciphertext

Jetzt kann Dave den aktualisierten Chiffretext an den Server senden.

(Beachten Sie, dass Sie in den meisten asymmetrischen Verschlüsselungsalgorithmen nicht einfach zwei Chiffretexte verketten können und erwarten können, dass sie entschlüsselt werden können. Daher müssen Sie möglicherweise einige Metadaten speichern, die die Chiffretextblöcke getrennt halten und sie separat entschlüsseln.)

Dies lässt uns nur Widerruf. Um den Zugriff zu widerrufen, müssen Sie mindestens P(data) haben, um ciphertext zurück zu plaintext zu entschlüsseln und ein neues Datenschlüsselpaar zu generieren: P'(data) , Q'(data) und verschlüsseln Sie den Klartext mit dem neuen Datenschlüsselpaar neu:

plaintext = D(ciphertext, P(data))
new_ciphertext = E(plaintext, Q'(data))

und dann müssen Sie alle Schreib- und Leseschlüssel aktualisieren.

Um einer vorhandenen Datei einen neuen Benutzer hinzuzufügen, müssen Sie lediglich den Schreib- und den Leseschlüssel erstellen. Nur Personen, die selbst ihren Leseschlüssel entschlüsseln können, können einen Leseschlüssel auf einen neuen Benutzer erweitern, und nur Personen, die ihren Schreibschlüssel selbst entschlüsseln können, können einen Schreibschlüssel auf einen neuen Benutzer erweitern.


Wenn Sie nicht benötigen, benötigen Sie die fein abgestimmte Berechtigung in diesem System (IOW, wenn alle Benutzer, die die Daten lesen können, sie auch aktualisieren können); oder wenn Sie andere Methoden verwenden, um fein abgestimmte Berechtigungen zu erzwingen, können Sie den asymmetrischen Datenschlüssel durch einen symmetrischen Datenschlüssel ersetzen ( Trivia : the Ein System mit symmetrischem Datenschlüssel ähnelt der Funktionsweise von PGP-verschlüsselten E-Mails mit mehreren Empfängern. Vielleicht möchten Sie dies untersuchen.

14
Lie Ryan

Die generische Methodik für diese Art von Problem ist die Argumentation in Bezug auf Wissen und Indirektion.

Sie möchten, dass jeder Benutzer einige Dinge tun kann, die andere Benutzer oder die "Techniker" nicht können. Daher muss jeder Benutzer wissen einen geheimen Wert haben, den andere Leute nicht haben. Das Passwort des Benutzers kann ein solches Geheimnis sein. Andernfalls müssten Sie etwas auf der Client-Seite speichern.

Der Zugriff auf jedes Datenelement darf zu jedem Zeitpunkt nur für eine ausgewählte Gruppe von Personen zugänglich sein. Daher müssen die Daten verschlüsselt und der Verschlüsselungsschlüssel genau diesen Personen bekannt sein. Darüber hinaus möchten Sie Elemente für jedes Element gemeinsam nutzen können, sodass jedes Element (jede Datei) über einen eigenen Verschlüsselungsschlüssel verfügen muss.

Sie können Vergesslichkeit nicht erzwingen; Wenn jemand irgendwann den Inhalt einer Datei kannte, können Sie ihn nicht so gestalten, dass er ihn vergisst. In der Praxis haben sie möglicherweise ein Backup auf ihrem eigenen Computer erstellt. Daher können Sie den Zugriff auf ein Datenelement nicht widerrufen. Bestenfalls können Sie pro Datei auswählen, wer sie lesen kann, und so einigen Personen die neue Version einer bestimmten Datei nicht zur Verfügung stellen.

Da Benutzer sich gegenseitig Zugriff auf einige Dateien gewähren sollen, benötigen Sie eine Art Rendezvous, das mit asymmetrischer Kryptografie am einfachsten zu erreichen ist.


Dies führt zu folgendem Design:

  • Jeder Benutzer [~ # ~] u [~ # ~] besitzt ein öffentliches/privates Schlüsselpaar [~ # ~] p [~ # ~]U. / [~ # ~] s [~ # ~] [~ # ~] u [~ # ~] von einem Typ, der für asymmetrische Verschlüsselung geeignet ist (z. B. RSA).

  • Der private Schlüssel wird "irgendwo" gespeichert, so dass nur der rechtmäßige Eigentümer jemals darauf zugreifen kann. Eine Methode wäre die Verschlüsselung des privaten Schlüssels mit dem Kennwort des Benutzers (vorausgesetzt, der Benutzer sendet sein Kennwort niemals an Ihren Server, andernfalls könnten die "Techniker" es abrufen). Alternativ wird der private Schlüssel des Benutzers in einer Datei auf seinem Desktop-/Laptop-System gespeichert.

  • Jedes Datenelement (oder jede Datei) wird mit einem eigenen, zufällig generierten Schlüssel verschlüsselt [~ # ~] k [~ # ~] (symmetrische Verschlüsselung).

  • Zusammen mit jeder Datei werden verschlüsselte Versionen von [~ # ~] k [~ # ~] mit den öffentlichen Schlüsseln der Benutzer gespeichert, die die Datei lesen können sollen. Wenn Benutzer [~ # ~] u [~ # ~] Teil dieses Satzes ist, verwendet dieser Benutzer seinen privaten Schlüssel [~ # ~] s [~ # ~] [~ # ~] u [~ # ~] um [~ # ~] k [~ # ~] wiederherzustellen und die Datei zu entschlüsseln.

  • Das Teilen einer Datei mit einem anderen Benutzer [~ # ~] v [~ # ~] erfolgt durch Wiederherstellen von [~ # ~] k [~ # ~] , dann verschlüsseln [~ # ~] k [~ # ~] mit [~ # ~] p [~ # ~] [~ # ~] v [~ # ~] (der öffentliche Schlüssel von Benutzer [~ # ~] v [~ # ~]) und Speichern des Ergebnisses entlang der Datei (oder Bereitstellung für Benutzer [~ # ~] v [~ # ~] durch einen anderen Mechanismus).

  • Wenn ein Benutzer sein Passwort ändert, wirkt sich dies höchstens auf die Speicherung seines privaten Schlüssels aus. Nichts zu tun mit den Dateien. Während sich das Passwort des Benutzers ändern kann, ist sein öffentliches/privates Schlüsselpaar permanent.

  • Wenn eine Datei geändert wird, können Sie die neue Version entweder als neue, unabhängige Datei mit einem eigenen neuen Schlüssel [~ # ~] k [~ # ~] und einem eigenen Satz von behandeln Empfänger. Wenn die neue Gruppe von Empfängern mit der alten Gruppe (oder einer Obermenge davon) identisch ist, können Sie einfach denselben Schlüssel [~ # ~] k [~ # ~] wiederverwenden einfacher für die Implementierung sein. Das Ändern des Schlüssels [~ # ~] k [~ # ~] Ist dem "Zugriff widerrufen" am ähnlichsten (vorbehaltlich der Einschränkung nicht durchsetzbarer Vergesslichkeit).


Natürlich kontrollieren die "Techniker" immer noch, welche Software zur Ausführung dieser Vorgänge ausgeführt wird (insbesondere in einem Webkontext, wobei das Javascript vom Server selbst gesendet wird oder wenn die Verschlüsselungs-/Entschlüsselungsvorgänge serverseitig ausgeführt werden). Wenn sie also wirklich Benutzer betrügen wollen, muss man davon ausgehen, dass sie es können.

3
Tom Leek

Dies ist ein interessantes Problem, das jedoch zu diesem Zeitpunkt in verschiedenen Open-Source-Anwendungen tatsächlich gelöst wurde. Ich würde für Ihren Anwendungsfall empfehlen, sich das Verschlüsselungsmodell von ownCloud zu leihen (das den Vorteil hat, Open Source zu sein).

Die allgemeine Anwendung dieses Modells auf Ihre Software würde folgendermaßen aussehen:

1) Dies kann natürlich auf viele Arten geschehen, aber ich empfehle, dass der Anwendungsserver diese Daten selbst mit asymmetrischer Verschlüsselung (öffentlich-privater Schlüssel) und anschließend mit symmetrischer Verschlüsselung verschlüsselt. Mit symmetrischer Verschlüsselung können Sie viel tun - beispielsweise, dass die Hälfte des Schlüssels auf dem Server liegt und der Benutzer die andere Hälfte usw. bereitstellen muss, um dieses Problem zu beheben.

2) Wie o11c hervorhebt, wird dieses Problem definitiv gelöst, wenn der asymmetrische private Schlüssel mit einer symmetrischen Verschlüsselungsmethode (Passwort) verschlüsselt wird.

3) Wenn andere Benutzer eine Kopie der Daten benötigen, muss der Anwendungsserver die Daten für diesen Benutzer entschlüsseln und anschließend erneut verschlüsseln. Auf diese Weise erhalten Sie Duplikate der Daten für jeden Benutzer, der sie benötigt. Die ownCloud-Methode ist interessant - sie verwendet einen asymmetrischen "Freigabeschlüssel", um von einem Benutzer freigegebene Dateien zu verschlüsseln. Dieser Freigabeschlüssel wird für jede Datei und jeden Benutzer generiert, für die die Datei freigegeben wird. Sie können dann den Anwendungsserver veranlassen, die Daten zu entschlüsseln, sie mit dem öffentlichen Schlüssel dieses Benutzers zu verschlüsseln, und dann würde nur das Kennwort dieses Benutzers den privaten Schlüssel entsperren, der zum Entschlüsseln der Datei erforderlich ist.

4) Wenn Sie auf 3 zurückgreifen, müssen Sie lediglich den neu generierten Freigabeschlüssel löschen und den Zugriff sicher widerrufen (vorausgesetzt, sie haben ihn nicht heruntergeladen oder einen Screenshot erstellt usw.).

1
Herringbone Cat

Apple verwendet einen solchen Mechanismus in iCloud. Ich glaube, so funktioniert es (wenn das Gedächtnis mir recht tut) und etwas anders als von anderen vorgeschlagen. Soweit ich es verstehe, handelt es sich nur um asymmetrische Verschlüsselung.

1) Das Gerät (iPhone, iPad usw.) generiert ein Schlüsselpaar (Geräteschlüssel).

2) Für ein neues iCloud-Konto generiert das Gerät ein zweites Schlüsselpaar (den Verschlüsselungsschlüssel).

3) Das Gerät verschlüsselt den privaten Teil des Verschlüsselungsschlüssels mit dem öffentlichen Geräteschlüssel. Sowohl der (Klartext-) öffentliche Verschlüsselungsschlüssel als auch der (verschlüsselte) private Verschlüsselungsschlüssel werden auf dem Server gespeichert.

4) Das Gerät verwendet den öffentlichen Verschlüsselungsschlüssel, um an den Server gesendete Daten zu verschlüsseln.

So teilen Sie Daten:

1) Sie benötigen ein Gerät, das bereits mit der Cloud verbunden ist. Nennen wir das Gerät 1. Das neue Gerät ist Gerät 2. 2) Gerät 2 generiert ein eigenes Geräteschlüsselpaar. 3) Gerät 2 sendet seinen öffentlichen Schlüssel an Gerät 1 (entweder direkt oder über die Cloud. Direkt ist sicherer). 4) Gerät 1 entschlüsselt den privaten Verschlüsselungsschlüssel mit seinem eigenen privaten Schlüssel und verschlüsselt ihn dann mit dem öffentlichen Schlüssel von Gerät 2.

In Schritt 3 besteht möglicherweise die Möglichkeit einer Sicherheitsanfälligkeit. Wenn ein Angreifer Gerät 1 dazu bringen kann, seinen öffentlichen Schlüssel zu akzeptieren, erhält er möglicherweise Zugriff auf freigegebene Daten. Ich weiß nicht, wie dies gelöst wird, aber wahrscheinlich handelt es sich dabei um Geräteidentifikation und wichtige Fingerabdrücke.

Zur Verdeutlichung bearbeiten: Das Verschlüsselungsschlüsselpaar in meiner Beschreibung ist pro Benutzer, aber Sie können denselben Mechanismus in einem anderen Bereich verwenden. Der Bereich bestimmt die "Freigabeeinheit". Wenn Sie entscheiden möchten, ob Sie einzelne Dateien freigeben oder nicht freigeben möchten, muss jede Datei über ein eigenes Schlüsselpaar verfügen. Für die Freigabe wird nur das Schlüsselpaar und nicht die zugrunde liegenden Daten dupliziert.

1
Kevin Keane