Wie Speicher ich den Schlüssel für verschlüsselte Datenbanken oder Dateien

[QuickAndDirty]

Hallo , das ist keine ausschließliche Firebird-Frage, sondern ehere eine Datenbank und Dateien Frage.

Wenn mein Dienst auf verschlüsselte Daten/Dateien CRUD-operationen ausübt, muss er die ja auch Entschlüsseln/Verschlüsseln können.
Also muss der Dienst den Schlüssel kennen.
Ein Passswort verschlüsselter Key mit Passwortabfrage bei Dienststart geht leider nicht, weil der Dienst nach einem Rechner Neustart laufen muss ohne Menschliches zutun.

Also muss der Symetrische schlüssel Irgendwo gespeichert werden oder?
Aber wo?
Am besten als verteilter schlüssel, falls der Rechner/die VM mal wegkommt?
Wer hat sowas schonmal gemacht? Gibts fertige Lösungen dafür in Delphi?

[Klaus01]

.. den symetrischen Schlüssel asymetrisch verschlüsseln.

Den sym. Schlüssel mit dem priv. Key verschlüsseln.
Der Dienst kann diesen Schlüssel dann mit dem public Key lesen.

Grüße
Klaus

[QuickAndDirty]

Zitat:

Zitat von Klaus01 (Beitrag 1526253)

.. den symetrischen Schlüssel asymetrisch verschlüsseln.

Den sym. Schlüssel mit dem priv. Key verschlüsseln.
Der Dienst kann diesen Schlüssel dann mit dem public Key lesen.

Grüße
Klaus

Und der Public key ist dann wo gespeichert?
Dann kann doch jeder den symetrischen Schlüssel mit dem public Key lesen oder?
Oder ist das einfach nur als zusätzliche Maßnahme gedacht?

Beispielsweise:
\\Rechner1\unverdächtigesverzeichnis1\K1.txt
XOR
\\Rechner2\unverdächtigesverzeichnis2\K2.txt
XOR
\\Rechner3\unverdächtigesverzeichnis3\K3.txt
DECRYPT VIA
c:\unverdächtigesverzeichnis\PUBLIC_KEY.PEM
= Symetrischer Schlüssel für Datenbank

????

[Klaus01]

vielleicht wird es hier deutlicher.

Grüße
Klaus

[jaenicke]

Da keine zusätzliche Information eingegeben werden kann, muss zum Lesen des Schlüssels logischerweise alles direkt zur Verfügung stehen. Daraus folgt auch, dass jemand mit dem entsprechenden Aufwand auch immer an diese Informationen herankommen kann. Man kann den Zugang lediglich erschweren. An der Stelle ist security by obscurity einmal tatsächlich sinnvoll, aber wie immer kein Schutz, sondern nur eine Verzögerung.

Für wirklich sensible Daten ist dies allerdings nicht geeignet. Da braucht man immer eine zusätzliche Informationsquelle, sei es z.B. eine Passworteingabe oder ein Hardwaredongle (der natürlich nicht einfach stecken bleiben darf), oder einen Zugangsschutz zum System, z.B. ein gesichertes Rechenzentrum.

[QuickAndDirty]

Zitat:

Zitat von Klaus01 (Beitrag 1526257)

vielleicht wird es hier deutlicher.

Grüße
Klaus

Ich weiß wie PKI und Verschlüsselung funktioniert.

Ich habe ein anderes Problem. Es geht darum Daten auf einem kompromitierten system zu schützen.
Wenn du den Rechner oder die VM mit nimmst sollst du nicht die Datenbank auslesen können.
Wenn du ein unglücklicher MA bist mit Zugang zum Server, sollst du die Daten nicht (einfach) veröffentlichen können.

Oder übersehe ich da etwas? Misverstehe ich dich?

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1526258)

Da keine zusätzliche Information eingegeben werden kann, muss zum Lesen des Schlüssels logischerweise alles direkt zur Verfügung stehen. Daraus folgt auch, dass jemand mit dem entsprechenden Aufwand auch immer an diese Informationen herankommen kann. Man kann den Zugang lediglich erschweren. An der Stelle ist security by obscurity einmal tatsächlich sinnvoll, aber wie immer kein Schutz, sondern nur eine Verzögerung.

Für wirklich sensible Daten ist dies allerdings nicht geeignet. Da braucht man immer eine zusätzliche Informationsquelle, sei es z.B. eine Passworteingabe oder ein Hardwaredongle (der natürlich nicht einfach stecken bleiben darf), oder einen Zugangsschutz zum System, z.B. ein gesichertes Rechenzentrum.

Das habe ich befürchtet. Keine Hoffnung auf magische Sicherheit...

Ich habe über folgendes nachgedacht:
1.Wenn der Vertrauenswürdige da ist , dann ist eine Eingabe eines Geheimnisses notwendig, beim Start des Dienstes.
2.Wenn der Vertrauenswürdige im Urlaub ist, fragt der Dienst einen microservice der bei dem Vertrauenswürdigen gehostet, ist nach dem Geheimnis.
So hätte man eine art Urlaubsmodus mit herabgesetzter Sicherheit....aber was soll man machen?

[johndoe049]

Zitat:

Zitat von QuickAndDirty (Beitrag 1526261)

Zitat:

Zitat von jaenicke (Beitrag 1526258)

Da keine zusätzliche Information eingegeben werden kann, muss zum Lesen des Schlüssels logischerweise alles direkt zur Verfügung stehen. Daraus folgt auch, dass jemand mit dem entsprechenden Aufwand auch immer an diese Informationen herankommen kann. Man kann den Zugang lediglich erschweren. An der Stelle ist security by obscurity einmal tatsächlich sinnvoll, aber wie immer kein Schutz, sondern nur eine Verzögerung.

Für wirklich sensible Daten ist dies allerdings nicht geeignet. Da braucht man immer eine zusätzliche Informationsquelle, sei es z.B. eine Passworteingabe oder ein Hardwaredongle (der natürlich nicht einfach stecken bleiben darf), oder einen Zugangsschutz zum System, z.B. ein gesichertes Rechenzentrum.

Das habe ich befürchtet. Keine Hoffnung auf magische Sicherheit...

Ich habe über folgendes nachgedacht:
1.Wenn der Vertrauenswürdige da ist , dann ist eine Eingabe eines Geheimnisses notwendig, beim Start des Dienstes.
2.Wenn der Vertrauenswürdige im Urlaub ist, fragt der Dienst einen microservice der bei dem Vertrauenswürdigen gehostet, ist nach dem Geheimnis.
So hätte man eine art Urlaubsmodus mit fast gleicher Sicherheit.

Evtl. kann man den Urlaubsmodus zum standard zu erheben?

Zitat:

Ich habe ein anderes Problem. Es geht darum Daten auf einem kompromitierten system zu schützen.
Wenn du den Rechner oder die VM mit nimmst sollst du nicht die Datenbank auslesen können.
Wenn du ein unglücklicher MA bist mit Zugang zum Server, sollst du die Daten nicht (einfach) veröffentlichen können.

Wenn man mit solchem Umfeld zu arbeiten hat, gilt eine einfache Regelung: Niemand ist vertrauenswürdig. Auch nicht der Programmierer, der das zu programmieren hat und die Möglichkeit hat, eine entsprechende Hintertür zu programmieren. In dem Fall sollten das mindestens 2 Programmierer erstellen, die sich gegenseitig überwachen.


Mögliche Lösung:
USB Stick mit dem Passwort an einem USB to Ethernet Router irgendwo in einem Schrank einschließen. Firewall so einstellen, dass die IP nur hausintern geroutet wird. Ist der Server/die VM im Büro ist der Kontakt möglich, ansonsten nicht.


Ansonsten gilt das von jaenicke. Immer da, wo der menschliche Faktor ausgeschaltet/umgangen wird, muss man Sicherheitseinschränkungen akzeptieren. Alles automatisch und absolut sicher geht in der Werbung oder im Film, aber nicht in der Realität. Auch nicht mit KI.

[jaenicke]

Nichtsdestotrotz hat man bei einem Dienst natürlich zumindest die Möglichkeit, dass man zum Zugriff hohe Rechte benötigt. Dann kommt zumindest kein einfacher Benutzer einfach so an die Daten heran.

[QuickAndDirty]

Wenn es wenigstens keine VM wäre dann hätte man bei einem geteilten Schlüssel einen Teil aus dem Hardwareprofil nehmen können. Das wäre nicht gleich ein offensichtlicher Speicherort...leider ist es ne VM...
und da bekommt man höchstens unterschiedliche prozessornamen....
Andererseits habe ich diese Lösung(https://theroadtodelphi.com/2010/12/...i-and-the-wmi/) noch nie ausprobiert.

Der Vertrauenswürdige könnte sich im Urlaub auch von nem Rubber-Ducky vertreten lassen...
Gut aber dann kann man auch gleich auf eine richtige Dongel Lösung setzen.

[Sinspin]

Was aber auch bei einer VM geht sind andere Geräte im Netzwerk, deren Namen oder Freigaben. Das setzt natürlich weiterhin voraus das Geheim gehalten wird was es nun genau ist.
Besser wäre es wenn der berechtigte eine Nachricht bekommt, SMS oder sowas, und antworten muss.

[Uwe Raabe]

Vielleicht kann man ja das TPM-Modul nutzen. Problematisch ist aber in jedem Fall ein unbefugter physischer Zugriff auf das System.

[jaenicke]

Zitat:

Zitat von Sinspin (Beitrag 1526268)

Besser wäre es wenn der berechtigte eine Nachricht bekommt, SMS oder sowas, und antworten muss.

Dafür kann man ja einen Authenticator nutzen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1526269)

Problematisch ist aber in jedem Fall ein unbefugter physischer Zugriff auf das System.

Wenn das Laufwerk verschlüsselt ist, nutzt es einem Dieb nichts, wenn es jemand schlicht klaut.

[QuickAndDirty]

Zitat:

Zitat von Uwe Raabe (Beitrag 1526269)

Vielleicht kann man ja das TPM-Modul nutzen. Problematisch ist aber in jedem Fall ein unbefugter physischer Zugriff auf das System.

Auf den Rechner kommen vermutlich nur Vertrauenswürdige und Hacker aber auf die betroffene VM schon einige Mitarbeiter. Der Zugriff auf das system ist auch dokumentiert, weil es eben wichtig ist das es läuft.
Kann ein TPM modul letzten endes nicht auch ein Dongel sein?

Zitat:

Zitat von Sinspin (Beitrag 1526268)

Was aber auch bei einer VM geht sind andere Geräte im Netzwerk, deren Namen oder Freigaben. Das setzt natürlich weiterhin voraus das Geheim gehalten wird was es nun genau ist.
Besser wäre es wenn der berechtigte eine Nachricht bekommt, SMS oder sowas, und antworten muss.

Ja, so könnte man auch das Geheimnis selbst recht gemütlich über eine Webservice oder eine App eingeben.

Zitat:

Zitat von jaenicke (Beitrag 1526270)

Zitat:

Zitat von Sinspin (Beitrag 1526268)

Besser wäre es wenn der berechtigte eine Nachricht bekommt, SMS oder sowas, und antworten muss.

Dafür kann man ja einen Authenticator nutzen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1526269)

Problematisch ist aber in jedem Fall ein unbefugter physischer Zugriff auf das System.

Wenn das Laufwerk verschlüsselt ist, nutzt es einem Dieb nichts, wenn es jemand schlicht klaut.

Wenn das Laufwerk verschlüsselt ist, muss man ein Passwort beim Start des Computers eingeben oder?
Ein Authenticator ließe sich zumindest auch im Urlaub aber nicht so toll im Krankenhaus benutzen.
Aber so eine App ist sicher der komfortabelste Weg das Geheimnis einzugeben, wenn man sich nicht Remote auf die VM wo der Dienst läuft einlogen will.

[joachimd]

[irony on]
in den alten nntp newsgroups hatte MM damals angemerkt, man könnte die Zugangsdaten im Klartext in die readme packen, da die eh niemand liest
[irony off]
Wenn der Schlüssel auf dem System gespeichert ist, gilt er als bekannt. Da gibt es keine Ausnahme, auch kein Verschleiern. Die einzige Möglichkeit: pack den Schlüssel in eine Hardware und nur mit dieser Hardware ist der Dienst lauffähig. Die Kollegen von https://www.wibu.com/de/produkte/wibukey.html waren früher immer auf der EKON und haben ihre Lösung vorgestellt.

[QuickAndDirty]

Zitat:

Zitat von joachimd (Beitrag 1526292)

Wenn der Schlüssel auf dem System gespeichert ist, gilt er als bekannt. Da gibt es keine Ausnahme, auch kein Verschleiern. Die einzige Möglichkeit: pack den Schlüssel in eine Hardware und nur mit dieser Hardware ist der Dienst lauffähig. Die Kollegen von https://www.wibu.com/de/produkte/wibukey.html waren früher immer auf der EKON und haben ihre Lösung vorgestellt.

Irgend einen Dongel wird es brauchen. bzw. einen Dongel und eine Verteiltenschlüssel.
Halt mindestens als Urlaubs/Krankenhaus Modus.

Zitat:

Zitat von joachimd (Beitrag 1526292)

[irony on]
in den alten nntp newsgroups hatte MM damals angemerkt, man könnte die Zugangsdaten im Klartext in die readme packen, da die eh niemand liest
[irony off]

Das ist Brilliant! So läuft das bei uns auch. am besten mit README.MD , dann weiß man schon, wenn man drauf klickt findet Windows nicht die Anwendung mit der man die Datei öffnen kann und muss selber aus der Liste eins auswählen, was natürlich viel zu viel Aufwand ist...

[Andreas13]

Zitat:

Zitat von QuickAndDirty (Beitrag 1526295)

Zitat:

Zitat von joachimd (Beitrag 1526292)

Wenn der Schlüssel auf dem System gespeichert ist, gilt er als bekannt. Da gibt es keine Ausnahme, auch kein Verschleiern. Die einzige Möglichkeit: pack den Schlüssel in eine Hardware und nur mit dieser Hardware ist der Dienst lauffähig. Die Kollegen von https://www.wibu.com/de/produkte/wibukey.html waren früher immer auf der EKON und haben ihre Lösung vorgestellt.

Irgend einen Dongel wird es brauchen. bzw. einen Dongel und eine Verteiltenschlüssel.
Halt mindestens als Urlaubs/Krankenhaus Modus.

Hallo,
ich habe mit dem Hardware-Schutz (Dongle) von MatrixLock http://www.matrixlock.de/modelle.htm in der Vergangenheit gute Erfahrungen gemacht. Einen oder mehrere Teile des Schlüssels kann man in den Registern des Dongles speichern und den USB-Dongle nicht nur an den lokalen PC’s, sondern auch direkt an den Server anschließen. Ohne diesen Hardware-Schutz läuft dann eben kein Programm.

[harfes]

Ich mache das in einer Anwendung mit einem USB-Zu-Ethernet-Gerät (wie auch schon von johndoe049 vorgeschlagen). Bei meinem Kunden gab es die Möglichkeit, das Gerät (und somit den USB-Stick) im nicht frei zugänglichen Keller aufzustellen. Der Server steht dann anderswo im Gebäude und die Firewall erlaubt nur von der Server-IP Zugriff auf den USB-Netzwerkadapter. Die Überlegung dabei: wenn der Server geklaut wird, dann muss der Dieb nochmal kommen, um den Stick zu klauen. Das verhindert aber natürlich nicht den Angriff auf das System über's Internet, aber das sollte ja eigentlich die Firewall verhindern...

Fazit: absolute Sicherheit gibt es nicht, aber es kann einem Angreifer so schwer wie möglich gemacht werden.

Hartmut

[QuickAndDirty]

Zitat:

Zitat von harfes (Beitrag 1526315)

Fazit: absolute Sicherheit gibt es nicht, aber es kann einem Angreifer so schwer wie möglich gemacht werden.

Es ist auch zu einem erheblichen Teil eine CYA-Maßnahme.... Mit zunehmender Menge an Kundendaten, wird mir zunehmend unwohler.
Ich hatte schon mal nen Alptraum das die weggekommen sind und ich bin der Entwickler und Admin usw. für das Ding.

[himitsu]

Für den Zugriff auf eine API/Cloud müsste ich im Programm die Zugangsdaten hinterlegen.

Da hab ich demnächst vor, dass im KeyStore des Windows zu hinterlegen (wo auch RDP und Co. ihre Passwörter hinterlegen).
Aktuell ist das auch noch hässlich pseudoverschlüsselt im Programm (Datenbank) hinterlegt.

Windows (Win32) bietet auch "einfache" Verschlüsselungsfunktionen an,
* mit dem aktuellen Programm als Schlüssel (so lange es aktiv ist, kann es Daten der selben Instanz entschlüsseln)
* mit dem UserLogin ... so lange der Nutzer eingeloggt ist, können Daten innerhalb der Session ver-/entschlüsselt werden
* oder mit einem SystemKey (der WindowsInstallation), können innerhalb dieser Installation Daten ver-/entschlüsselt werden
CryptProtectData

Im WinRT soll es besseres Zeugs geben, aber von Win32 muß man sich erst dahin durchkämpfen (wie bei der API für die Notifications im Windows).

[Kas Ob.]

Hi,

CryptProtectData and its companion API, are good as they encrypt and store the encrypted data on a local machine, but it comes with few cons, the ability to decrypt from within the system, by either an application running with same user, or any an application running on any user, all you need is to extract the entropy from the application.
USB and TPM also not that viable for portability.
Better the above is using the LDAP, but again this has its own cons.

I solved this in two ways over the years and hope you finds them useful:

1) My data bank server will load (grab) the key from another different location over the wire (internet or local network), the connection is secure, also that server is a windows service, that detect any login for Windows user and delete the key from the memory, meaning stop the server operation until no more user are logged on the system, then grab the key again, in fact i use it a little differently, the server on detecting a connection it does encrypt all the high value and critical data in memory to make sure, then proceed to march them to the controller, if failed to march them then it will dump them encrypted on the disk with a already supplied key from the controller and will not be able to decrypt them without an admin interaction on the controller side.

2) For easier deploy also when many instances will be used, I use WinLicense https://www.oreans.com/WinLicense.php https://www.oreans.com/help/wl/
It has its own highly protected storage that support custom data in the licensing key https://www.oreans.com/help/wl/hm_cu...-in-licens.htm
It also can lock the license key to a hardware and this will make things way easier by deploying and then apply licenses that have hidden encryption keys.

[Kas Ob.]

Sorry for the screenshot, but for now this what i can post and hope you find it useful


Hi,

CryptProtectData and its companion API, are good as they encrypt and store the encrypted data on a local machine, but it comes with few cons, the ability to decrypt from within the system, by either an application running with same user, or any an application running on any user, all you need is to extract the entropy from the application.
USB and TPM also not that viable for portability.
Better the above is using the LDAP, but again this has its own cons.

I solved this in two ways over the years and hope you finds them useful:

1) My data bank server will load (grab) the key from another different location over the wire (internet or local network), the connection is secure, also that server is a windows service, that detect any login for Windows user and delete the key from the memory, meaning stop the server operation until no more user are logged on the system, then grab the key again, in fact i use it a little differently, the server on detecting a connection it does encrypt all the high value and critical data in memory to make sure, then proceed to march them to the controller, if failed to march them then it will dump them encrypted on the disk with a already supplied key from the controller and will not be able to decrypt them without an admin interaction on the controller side.

2) For easier deploy also when many instances will be used, I use WinLicense from "oreans.com"
( i posted this yesterday few times and there was some redirection of the page notifying that my post should be approved by administrator, so i re-posting without links in case it is the problem)
It has its own highly protected storage that support custom data in the licensing key , custom data in this case can be you encryption key
oreans com -> support -> online help WinLicense -> Licensing with WinLicense -> Customizing features in licenses

Zitat:

WinLicense offers a more flexible approach and allows you to insert a buffer (ASCII or UNICODE) of up to 6400 bytes when generating the license (in the Custom Data field). You can put any information that you want and you can check it in runtime by calling the function WLRegGetLicenseInfo. There are not restrictions about the format of the Custom Data information that you insert. The information that you set in the Custom Data when creating the license, it's the one that it's returned by the WLRegGetLicenseInfo function.

It also can lock the license key to a hardware and this will make things easier by deploying and then apply licenses that have hidden encryption keys to specific station that can't be used on other devices.

[Kas Ob.]

It did went through !!, may be the "Hi" thingy.

[himitsu]

Zitat:

cons

I want to move access to the foreign cloud from the client applications to our server application.
This service is currently still running as a system user for too many customers, but in the future it will be a separate user account.

Either way, from the client computers, as well as as a "simple user" on the server, you wouldn't normally have access to the user account used by the service.


Currently, the client mostly still uses a database connection with SuperUser authorization, so that it would theoretically be easy to get the password that is stored in the database.
And the password has to be decryptable in order to use it for login, I can't hash it.
Unfortunately, the API does not offer the possibility of a restricted API key for the connection.

In addition, the RESTful service runs into a timeout every 30 minutes, so that so far after at least 30 minutes the user + password, almost unencrypted, goes from the client to the Internet, which in future will only happen from the more protected server, which normal users will access less have access.

[QuickAndDirty]

Zitat:

Zitat von Kas Ob. (Beitrag 1526500)

It did went through !!, may be the "Hi" thingy.

HI
Thanks for your suggestion. This sounds like very sophisticated system you have.
Also double thanks for taking the effort to read/translate all those German posts, just to provide me with help.

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1526529)

Zitat:

Zitat von Kas Ob. (Beitrag 1526500)

It did went through !!, may be the "Hi" thingy.

HI
Thanks for your suggestion. This sounds like very sophisticated system you have.
Also double thanks for taking the effort to read/translate all those German posts, just to provide me with help.

You are welcome !, though the thanks for translations goes for glo-glo ;)