Private Keys in Datenbank abspeichern

[paedubucher]

Ich arbeite im Moment an einem Projekt, wo es u.a. darum geht Dokumente verschlüsselt abzuspeichern. Der einfachste Ansatz wäre es, mit einem globalen, symmetrischen Schlüssel alle Dokumente zu ver- und entschlüsseln. Wenn dann aber mal jemand das Volume und den Schlüssel rausträgt, hat er doch sämtliche Daten. Darum verfolge ich einen anderen Ansatz, nämlich für jeden Benutzer ein RSA-Schlüssselpaar zu erzeugen, womit dessen Dokumente dann ver- und entschlüsselt werden. Die Schlüssel sollen in der Datenbank abgelegt werden, wozu ich eine Base64-Kodierung verwende und sie als Zeichenkette abspeichere. Derzeit ist es nicht vorgesehen, dass der Benutzer seine Schlüssel je zu sehen bekommt, höchstens vielleicht einmal den öffentlichen Schlüssel, den er dann weitergibt (aber dafür habe ich im Moment noch keinen Use-Case), und der ist ja per Definition nicht sensitiv. (Die Datenbank ist nur für Leute zugänglich, die auch Zugriff aufs Backend-System haben und von dort aus ein Port-Forwarding einrichten können, sprich für die Admins.)

Bei privaten Schlüssel überlege ich mir aber schon, ob ich den einfach im Klartext ablegen soll. Denn wenn einer die Datenbank und das Dokument-Volume rausträgt, hat er wiederum Vollzugriff. Darum habe ich mir überlegt, die privaten Schlüssel wiederum zu verschlüsseln, was ich dann symmetrisch, etwa mit einem 256-Bit AES-Schlüssel bewerkstelligen würde. Dieser Schlüssel stünde dann als Umgebungsvariable im Backend-System zur Verfügung. Und die Konfiguration der Umgebungsvariablen ist wiederum in einem verschlüsselten Vault abgelegt, sodass ein Angreifer wirklich Zugriff auf die laufende Umgebung bräuchte.

Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.
Spezielle Hardware-Module für die Schlüsselablage sind keine Option, zumal in diesem Projekt ein "Platform as Code"-Ansatz verwendet wird (Ansible Playbooks, OpenShift, Kubernetes, Docker... praktisch die volle Bullshit-Bingo-Karte ohne Blockchain und IoT ) Ein weiterer Store neben relationaler Datenbank und Dokumentablage wäre zwar möglich, aber mit massivem Zusatzaufwand (und wohl einer Release-Verspätung) verbunden, allem "Platform as Code"-Ansatz zum Trotz

[Meillo]

Die Schlüssel sollen in der Datenbank abgelegt werden

Meinst du hier sowohl den oeffentlichen als auch den privaten Schluessel? Das wird nicht ganz klar

wozu ich eine Base64-Kodierung verwende und sie als Zeichenkette abspeichere.

Base64 nur damit es kein binaerer Blob ist? Die `--armor' Option von Gnupg scheint auch Base64 zu verwenden. Du solltest darauf achten, damit kompatibel zu sein, oder eben Gnupg die Textrepraesentation erstellen lassen.

Bei privaten Schlüssel überlege ich mir aber schon, ob ich den einfach im Klartext ablegen soll.

Du meinst also ebenfalls Base64-kodiert (s.o.) aber nicht verschluesselt?

Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.

Wie waere es stattdessen mit einer Passphrase fuer den Seckey statt ihn zu verschluesseln? Damit solltest du wohl das gleiche hinbekommen, ohne die Komplexitaet des Systems zu erhoehen.

(Ich bin kein Securityexperte.)

[paedubucher]

Erstmals danke für die Antwort! Entschuldige auch meine etwas verspätete Antwort, ich war unterwegs und hatte keinen Zugriff auf meinen privaten Passwort-Store (ebenfalls RSA-verschlüsselt).

Die Schlüssel sollen in der Datenbank abgelegt werden

Meinst du hier sowohl den oeffentlichen als auch den privaten Schluessel? Das wird nicht ganz klar

Ja, beide Schlüssel.

wozu ich eine Base64-Kodierung verwende und sie als Zeichenkette abspeichere.

Base64 nur damit es kein binaerer Blob ist? Die `--armor' Option von Gnupg scheint auch Base64 zu verwenden. Du solltest darauf achten, damit kompatibel zu sein, oder eben Gnupg die Textrepraesentation erstellen lassen.

Ja, d.h. am Freitag habe ich das noch richtig mit PKCS8 gebaut. GnuPG macht das, soviel ich weiss, auch, und dann noch base64, damit es ein String ist.

Bei privaten Schlüssel überlege ich mir aber schon, ob ich den einfach im Klartext ablegen soll.

Du meinst also ebenfalls Base64-kodiert (s.o.) aber nicht verschluesselt?

Doch, AES-verschlüsselt. Damit man eben diesen zusätzlichen Schlüssel noch braucht, um etwas mit dem privaten Schlüssel jedes Accounts anfangen zu können.

Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.

Wie waere es stattdessen mit einer Passphrase fuer den Seckey statt ihn zu verschluesseln? Damit solltest du wohl das gleiche hinbekommen, ohne die Komplexitaet des Systems zu erhoehen.

(Ich bin kein Securityexperte.)

Vom Prinzip her dürfte das mehr oder weniger das gleiche machen, aber das System mit der Passphrase klingt schon interessant. Java, das im Projekt verwendet wird, unterstützt sowas sogar (PBEKeySpec). Es würde aber dann bei einer Passphrase für alle Private Keys bleiben. Zeit zum Umbau von AES-Verschlüsselung auf Passphrase habe ich noch genug.
So hätte ich die Verschlüsselung nachgebaut, die ich privat auch für meine Passwörter verwende. Quasi ein Koch, der sein eigenes Essen isst.

[Meillo]

Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.

Wie waere es stattdessen mit einer Passphrase fuer den Seckey statt ihn zu verschluesseln? Damit solltest du wohl das gleiche hinbekommen, ohne die Komplexitaet des Systems zu erhoehen.

Vom Prinzip her dürfte das mehr oder weniger das gleiche machen, aber das System mit der Passphrase klingt schon interessant. Java, das im Projekt verwendet wird, unterstützt sowas sogar (PBEKeySpec). Es würde aber dann bei einer Passphrase für alle Private Keys bleiben. Zeit zum Umbau von AES-Verschlüsselung auf Passphrase habe ich noch genug.

Ich denke halt, dass es sich anbieten wuerde, das von den GnuPG-Experten bereits vorgesehene (und auf seine Tauglichkeit gepruefte) Verfahren, also eine Passphrase fuer den Seckey, zu verwenden anstatt sich (als Security-Laie) etwas eigenes auszudenken.

Und wenn es dir nur um den paedagogischen Lernerfolg geht, dann hast du den auch dadurch (und zwar auf einem hoeheren Level, weil Effektivitaet wichtiger ist als Effizienz -- schneller als der schnellste Codeschreiber ist derjenige, der den Code gar nicht erst schreiben muss --), dass du diesen Denkprozess durchlaufen hast.

[paedubucher]

Ich denke halt, dass es sich anbieten wuerde, das von den GnuPG-Experten bereits vorgesehene (und auf seine Tauglichkeit gepruefte) Verfahren, also eine Passphrase fuer den Seckey, zu verwenden anstatt sich (als Security-Laie) etwas eigenes auszudenken.

Ja, das ist sicherlich der richtige Weg.

Und wenn es dir nur um den paedagogischen Lernerfolg geht, dann hast du den auch dadurch (und zwar auf einem hoeheren Level, weil Effektivitaet wichtiger ist als Effizienz -- schneller als der schnellste Codeschreiber ist derjenige, der den Code gar nicht erst schreiben muss --), dass du diesen Denkprozess durchlaufen hast.

Den pädagogischen Lernerfolg hatte ich heute. Ich hatte nämlich ganz vergessen, wie PGP/GPG eigentlich arbeitet. Der RSA-Schlüssel wird gebraucht, um einen symmetrischen Schlüssel zu verschlüsseln, der dann der Nachricht mitgegeben wird. Mit dem RSA-Schlüssel selber kann man nur kleine Datenmengen auf einmal verschlüsseln. Zwar könnte man eine grössere Datenmenge aufteilen und alle Teile gesondert verschlüsseln. Davon wird einem aber abgeraten, ausserdem erzeugt das Probleme beim Entschlüsseln mit dem Padding. Und zu langsam für grosse Datenmengen wäre es eh. Zudem müsste ich für jedes Dokument einen Schlüssel generieren und ablegen, was die Komplexität des Systems bloss weiter erhöhen würde.
So bin ich vom Ansatz mit Public/Private Key abgerückt und verwende nun einen symmetrischen Schlüssel (AES). Dieser ist wiederum mit dem systemweiten symmetrischen AES-Schlüssel verschlüsselt. Dieser Mechanismus ist jedoch (im Gegensatz zu meiner angedachten Verschlüsselung des privaten Schlüssels) erprobt: Er wird in unserer Infrastruktur bereits so eingesetzt (Ansible Vault), und zwar zum Verschlüsseln der sicherheitssensitiven Umgebungsvariablen in den Skripts (Playbooks).
So wurde heute ein Teil meiner bisher geleisteten Arbeit obsolet. Immerhin habe ich aber jetzt eine einfache, erprobte, schnelle und dennoch sichere Lösung, die seit heute Abend auch funktioniert
Der pädagogische Lerneffekt war heute wirklich gewaltig, diese Lektion werde ich so schnell nicht vergessen!

[Meillo]

Cool!