Rolf B: verschlüsselte Daten mit mehreren Personen teilen

Beitrag lesen

Hallo Klaus1,

Beim Wechsel einer Verantwortlichkeit (Vorgesetzte wechselt), müsste der neue auch auf die bisherigen Daten zugreifen können.

Verschlüsselung für mehrere Personen bedeutet normalerweise, dass das Dokument mit einem symmetrischen Hauptschlüssel gesichert wird und dieser Hauptschlüssel dann einzeln mit den öffentlichen Schlüsseln der beabsichtigten Empfänger verschlüsselt wird. Bei 100 Empfängern habe ich dann also ein verschlüsseltes Dokument und 100 kleine Schlüsselpäckchen, die daran hängen. Der Hauptschlüssel ist pro Dokument einmalig, man bestimmt ihn mit einem kryptographisch sicheren Zufallszahlengenerator.

Wenn ein neuer Mitarbeiter Zugriff auf bestimmte Dokumente bekommen soll, muss jemand, der eins von diesen Päckchen öffnen kann, all diese Dokumente durchgehen und ein neues Schlüsselpäckchen für den neuen Mitarbeiter anhängen. Bei der Gelegenheit sollte er dann auch das Schlüsselpäckchen des alten Chefs eliminieren.

Vermutlich gibt es diverse Tools, die sowas auf Dateiebene lösen. Ich muss zugeben: das war bisher keine Aufgabe, die ich lösen musste, und ich bin darin nicht erfahren. Mir sagt gnuPG was, aber da ist ein Schwerpunkt auch das Web of Trust - ein Problem, dass man in einem Unternehmen nicht hat. Vielleicht habt ihr ja schon eine eigene PKI im Haus. Bei größeren Dokumentenmengen kann das Hantieren auf Dateiebene lästig werden, ich würde es dann mit einer Datenbank organisieren. Welche Tools Du konkret für AES und RSA nimmst, hängt dann von der Programmierumgebung ab, in der Du hantierst.

Tabelle 1: Dokument-ID, ein paar Metadaten und eine image-Column mit dem verschlüsselten Dokument. Zu den Metadaten sollte auch die Organisationsheit gehören, der dieses Dokument "gehört".

Tabelle 2: Dokument-ID, User-ID, Schlüsselpaket

Tabelle 3: User-ID, öffentlicher Schlüssel dieses Users

Wenn nun User U001 ein Dokument hochlädt, wird es mit einem Zufallskey symmetrisch verschlüsselt. Dieser Zufallskey wird mit den öffentlichen Schlüsseln (aus Tabelle 3) für jeden einzelnen, der Zugang haben soll, in ein Schlüsselpaket gelegt und in Tabelle 2 unter der User-ID des berechtigten Lesers gespeichert. Das kann zum Beispiel der User U005 sein, Chef von U001.

Herr U005 kann nun beim Abruf des Dokuments seinen privaten Schlüssel nutzen, damit den Zufallsschlüssel für das Dokument ermitteln und es so entschlüsseln. Diesen privaten Schlüssel hat er im Kopf, auf einem USB-Stick, auf einer Keycard oder sonst irgendwo, wo er sicher ist. Dieser Aspekt der ganzen Kette birgt die größten Gefahren, weil Schlendrian hier gang und gäbe ist, gerade bei höheren Dienstgraden, und Löcher ins System reißt.

Nun kommt der Tag X und Herr U005 wird durch Frau U006 ersetzt. Nun muss jemand, der ein Schlüsselpaket für die Dokumente von Herrn U005 hat (das kann jeder aus seiner Abteilung sein), die Schlüsselpakete dieser Dokumente öffnen, den Dokumentenschlüssel entnehmen und ein neuen Schlüsselpaket für Frau U006 schnüren. Das sollte vorzugsweise Herr U005 selbst sein, als letzte Amtshandlung, aber rein technisch kann das jeder tun, der auf alle Dokumente von Herrn U005 Zugriff hat. Nachdem nun Herr U005 nicht mehr Chef ist, kann man von den betreffenden Dokumenten sein Schlüsselpaket entfernen.

Kleiner Nachteil der Sache ist noch, dass ein so verpackter Schlüssel voraussetzt, dass die Schlüsselpaare der Anwender sich nicht ändern. Falls nun User U099 meint, sein Schlüssel wäre kompromittiert, dann muss er alle Schlüsselpakete, die ihm gehören, neu schnüren. Wenn das System 10000 Dokumente für ihn enthält, kann das eine Weile dauern.

Ob das sicher ist? Keine Ahnung. Aber wenn ich diesen Auftrag bekäme, wäre das mein Ansatz, mit dem ich zu unserer Security-Abteilung ginge und um Beurteilung bäte (bittete? bitten würde? Konjunktive sind was für Fortgeschrittene...).

Die Alternative ist, dass man seinen Admins vertraut (was man nie tun sollte) und den Dokumentenzugang über ein "vertrauenswürdiges System" regelt. Dokumente sind dann an Hand der Berechtigungen zugänglich, die ein angemeldeter User hat. In der DB können sie verschlüsselt sein, damit nicht jeder DB-Admin das Archiv plündern kann, aber das DBMS muss den Key haben. Wenn man das so macht, ist die Spielerei mit den Schlüsselpaketen nicht nötig, die Sicherheit wird über die Rolle der jeweiligen Person hergestellt. Aber es gibt dann die ständige Backdoor, dass ein Admin den Dokumentenschlüssel ausliest. Hinzu kommt, dass dieser Schlüssel übergreifend und nicht zufällig ist, d.h. wer ihn hat, kommt sofort an alle Dokumente.

Rolf

--
sumpsi - posui - obstruxi