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
Private Keys in Datenbank abspeichern
- paedubucher
- Beiträge: 856
- Registriert: 22.02.2009 16:19:02
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Schweiz
-
Kontaktdaten:
Private Keys in Datenbank abspeichern
Habe nun, ach! Java
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Re: Private Keys in Datenbank abspeichern
Meinst du hier sowohl den oeffentlichen als auch den privaten Schluessel? Das wird nicht ganz klarpaedubucher hat geschrieben:31.01.2019 19:57:28Die Schlüssel sollen in der Datenbank abgelegt werden
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.wozu ich eine Base64-Kodierung verwende und sie als Zeichenkette abspeichere.
Du meinst also ebenfalls Base64-kodiert (s.o.) aber nicht verschluesselt?Bei privaten Schlüssel überlege ich mir aber schon, ob ich den einfach im Klartext ablegen soll.
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.Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.
(Ich bin kein Securityexperte.)
Use ed once in a while!
- paedubucher
- Beiträge: 856
- Registriert: 22.02.2009 16:19:02
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Schweiz
-
Kontaktdaten:
Re: Private Keys in Datenbank abspeichern
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).
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.
Ja, beide Schlüssel.Meillo hat geschrieben:01.02.2019 08:25:07Meinst du hier sowohl den oeffentlichen als auch den privaten Schluessel? Das wird nicht ganz klarpaedubucher hat geschrieben:31.01.2019 19:57:28Die Schlüssel sollen in der Datenbank abgelegt werden
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.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.wozu ich eine Base64-Kodierung verwende und sie als Zeichenkette abspeichere.
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.Du meinst also ebenfalls Base64-kodiert (s.o.) aber nicht verschluesselt?Bei privaten Schlüssel überlege ich mir aber schon, ob ich den einfach im Klartext ablegen soll.
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.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.Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.
(Ich bin kein Securityexperte.)
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.
Habe nun, ach! Java
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Re: Private Keys in Datenbank abspeichern
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.paedubucher hat geschrieben:03.02.2019 19:06:36Vom 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.Meillo hat geschrieben:01.02.2019 08:25:07Wie 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.paedubucher hat geschrieben:31.01.2019 19:57:28Nun frage ich mich, ob das Verschlüsseln der privaten Schlüssel in dieser Form sinnvoll, unsicher, unnötig oder gar schädlich ist.
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.
Use ed once in a while!
- paedubucher
- Beiträge: 856
- Registriert: 22.02.2009 16:19:02
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Schweiz
-
Kontaktdaten:
Re: Private Keys in Datenbank abspeichern
Ja, das ist sicherlich der richtige Weg.Meillo hat geschrieben:04.02.2019 10:06:21Ich 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.
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.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.
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!
Habe nun, ach! Java
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.