Wo soll der private Schlüssel aufbewahrt werden?

Angenommen, ich möchte, dass einige Teile meiner Software verschlüsselt werden. Zum Beispiel die Anmeldeinformationen für eine Datenbank usw. Ich muss diese Werte irgendwo speichern, aber dies im Klartext zu tun, würde es einem Angreifer leicht machen, nicht autorisierten Zugriff zu erhalten.

Wenn ich jedoch Klartext verschlüssele, wo speichere ich dann den Schlüssel? Auf alles, auf das die Software Zugriff hat, kann ein entschlossener Angreifer zugreifen, unabhängig vom Grad der Verschleierung:

• Angenommen, der Schlüssel ist durch das Sicherheitsmodell des Dateisystems geschützt. Aber was ist mit (böswilligen) Super-Usern oder Plattformen, die keine solche Wiedergabetreue bieten?
• Oder der Schlüssel ist fest in Software-Binärdateien codiert, kann jedoch jederzeit dekompiliert werden, und was ist mit Open Source-Software oder interpretiertem Code?
• Wenn der Schlüssel generiert wird, müsste ein solcher Algorithmus (vermutlich) deterministisch sein, und dann gilt dasselbe Problem für den Startwert.
• etc.

Kryptographie ist nur so stark wie das schwächste Glied in seiner Kette und das scheint ziemlich locker zu sein! Angenommen, es ist das richtige Werkzeug für den Job (humor me), wie kann man dann solche Informationen zuverlässig sichern?

In Bezug auf das richtige Tool für den Job: Wahrscheinlich würden Sie beispielsweise im Fall des Servicezugriffs (DBs, Authentifizierungsserver usw.) den Zugriff auf diese Ebene mit einem Servicekonto einschränken, möglicherweise mit einem bestimmten Service-Level Auditing usw. und damit die Berechtigungsnachweise im Klartext zu haben, ist keine solche Sorge.

Das scheint mir jedoch immer noch unzureichend: Ich möchte nicht, dass jemand herumstochert, wo er nicht sein sollte!

Zunächst einmal würde ich mich nicht als Sicherheitsexperten bezeichnen, aber ich war in der Lage, diese Frage beantworten zu müssen. Was ich herausgefunden habe, hat mich ein wenig überrascht: Es gibt kein absolut sicheres System . Nun, ich denke, ein absolut sicheres System wäre eines, bei dem alle Server ausgeschaltet sind :)

Jemand, der damals mit mir zusammenarbeitete, beschrieb die Entwicklung eines sicheren Systems , um die Messlatte für Eindringlinge höher zu legen. Daher verringert jede Sicherungsebene die Möglichkeit eines Angriffs.

Selbst wenn Sie beispielsweise den privaten Schlüssel perfekt sichern könnten, ist das System nicht vollständig sicher. Wenn Sie jedoch die Sicherheitsalgorithmen richtig anwenden und mit Patches auf dem neuesten Stand sind, werden Sie die Messlatte höher legen. Aber ja, ein Supercomputer, der stark genug ist und genügend Zeit hat, kann die Verschlüsselung aufheben. Ich bin mir sicher, dass all dies verstanden wird, also werde ich die Frage zurückerhalten.

Die Frage ist klar, also werde ich zuerst versuchen, jeden Ihrer Punkte anzusprechen:

Angenommen, der Schlüssel ist durch das Sicherheitsmodell des Dateisystems geschützt. Aber was ist mit (böswilligen) Super-Usern oder Plattformen, die keine solche Genauigkeit bieten?

Ja, wenn Sie einen Windows-Schlüsselspeicher oder einen kennwortverschlüsselten privaten TLS-Schlüssel verwenden, sind Sie den Benutzern ausgesetzt, die über das Kennwort (oder den Zugriff) auf die privaten Schlüssel verfügen. Aber ich denke, Sie werden zustimmen, dass dies die Messlatte höher legt. Die Dateisystem-ACLs (sofern sie ordnungsgemäß implementiert sind) bieten einen recht guten Schutz. Und Sie sind in der Lage, Ihre Superuser persönlich zu überprüfen und zu kennen.

Oder der Schlüssel ist fest in Software-Binärdateien codiert, kann jedoch jederzeit dekompiliert werden, und was ist mit Open Source-Software oder interpretiertem Code?

Ja, ich habe fest codierte Schlüssel in Binärdateien gesehen. Auch dies legt die Messlatte ein wenig höher. Jemand, der dieses System angreift (wenn es sich um Java handelt), muss verstehen, dass Java Byte-Code (usw.) erzeugt, und muss verstehen, wie es dekompiliert wird, und es muss gelesen werden. Wenn Sie eine Sprache verwenden, die direkt in Maschinencode schreibt, können Sie sehen, dass dies die Messlatte ein bisschen höher legt. Es ist keine ideale Sicherheitslösung, kann jedoch ein gewisses Maß an Schutz bieten.

Wenn der Schlüssel generiert wird, müsste ein solcher Algorithmus (vermutlich) deterministisch sein, und dann gilt dasselbe Problem für den Startwert.

Ja, im Wesentlichen wird der Algorithmus dann zur Information über den privaten Schlüssel zum Erstellen des privaten Schlüssels. Es müsste also jetzt geschützt werden.

Ich denke, Sie haben ein Kernproblem mit einer Sicherheitsrichtlinie, der Schlüsselverwaltung, identifiziert . Die Einrichtung einer Schlüsselverwaltungsrichtlinie ist für die Bereitstellung eines sicheren Systems von zentraler Bedeutung. Und es ist ein ziemlich weites Thema .

Die Frage ist also, wie sicher Ihr System (und damit der private Schlüssel) sein muss. Wie hoch muss in Ihrem System die Messlatte angehoben werden?

Nun, wenn Sie bereit sind zu zahlen, gibt es einige Leute, die Lösungen für dieses Problem entwickeln. Am Ende haben wir ein HSM (Hardware Security Module) verwendet . Grundsätzlich handelt es sich um einen manipulationssicheren Server, der einen Hardwareschlüssel enthält. Mit diesem Schlüssel können dann andere Schlüssel für die Verschlüsselung erstellt werden. Die Idee dabei ist, dass (bei korrekter Konfiguration) der Schlüssel das HSM niemals verlässt . HSM kosten viel . In einigen Unternehmen (zum Beispiel beim Schutz von Kreditkartendaten) sind die Kosten für einen Verstoß jedoch viel höher. Es besteht also ein Gleichgewicht.

Viele HSMs verwenden Schlüsselkarten aus der Wartung und Verwaltung der Funktionen. Ein Quorum von Schlüsselkarten (5 von 9 sagen wir mal) muss physisch in den Server gesteckt werden, um einen Schlüssel zu ändern. Dies legt also die Messlatte ziemlich hoch, indem nur dann ein Verstoß zugelassen wird, wenn ein Quorum von Super-Usern zusammentrifft.

Möglicherweise gibt es Softwarelösungen, die ähnliche Funktionen wie ein HSM bieten, aber ich weiß nicht, was sie sind.

Ich weiß, dass dies nur dazu beiträgt, die Frage zu beantworten, aber ich hoffe, dass dies hilft.

Was du willst, kann nicht getan werden.

Angenommen, der Schlüssel ist durch das Sicherheitsmodell des Dateisystems geschützt. Aber was ist mit (böswilligen) Super-Usern oder Plattformen, die keine solche Genauigkeit bieten?

Sie möchten im Grunde genommen Schutz vor böswilligen Personen. In Ihrem Modell hat irgendwann jemand Zugriff auf den Schlüssel. Was ist, wenn diese Person bösartig ist? Was ist, wenn Sie bösartig sind? Sehen Sie, das Problem ist unlösbar, es sei denn, Sie haben überhaupt keinen Schlüssel.

Arbeiten Sie also nicht mit Datenbankanmeldeinformationen, sondern mit anderen Authentifizierungsmechanismen. Aber egal was passiert, irgendwann muss jemand Zugriff auf die Daten haben und kann böswillig sein.

Dies ist eines der Probleme, die nicht auf der gleichen Ebene gelöst werden können, auf der sie entstanden sind. Wir müssen einen Schritt zurück zu einigen grundlegenden Philosophien machen und der Kaskade in der Hoffnung auf eine Lösung folgen.

Die erste Philosophie lautet: "Vertraue niemals dem Kunden", und die eng verwandte: "Wenn du wirklich ein Geheimnis bewahren willst, sag es niemandem!"

Ein einfaches Beispiel sind Datenbankanmeldeinformationen, wie Sie bereits erwähnt haben. Natürlich möchten Sie, dass Ihr Kunde Zugriff darauf hat, aber keinen zufälligen Internet-Fremden. Daher benötigen Sie eine Art Identitäts- / Verifizierungs- / Anmeldesystem. Aber die Grundvoraussetzung, dies zu verbergen, ist ein Problem: Wenn der Benutzer selbst ein Geheimnis haben muss, aber nicht möchte, dass er weiß, was dieses Geheimnis ist, kann er es nur verbergen oder es ihm schwer machen, es zu öffnen. " das geheime Paket ". Aber sie können es immer noch herausfinden, also sollten Sie einen Backup-Plan haben!

Die einfachste Lösung ist: "Tu das nicht." Verwenden Sie die Anmeldeinformationen des Benutzers, um den Client-Zugriff auf die Datenbank für die Software zuzulassen. Wenn der Client böswillig wird, sollte das schlimmste Szenario sein, dass der Client seine eigenen Daten vermasseln kann. Das ist es. Ihre Datenbank und Ihr System sollten jetzt höchstens Junk-Einträge von diesem Client enthalten, und zwar nur für diesen Client, und niemand anderes (einschließlich Sie) sollte unter dem Chaos leiden.

Es gibt bestimmte Anwendungsfälle, in denen Sie nur möchten, dass bereitgestellte Software etwas tut, aber nicht, dass jeder auf der Welt in der Lage ist, sich zu verbinden und dasselbe zu tun, aber dafür verstecken Sie nur Geheimnisse und der einzige gute Grund dafür ist, dies einfach zu tun Reduzieren Sie Kopfschmerzen oder Systemaktivität. Wenn Ihre verborgenen Informationen allgemein bekannt werden, ist es besser, nicht das Spiel zu brechen, sondern im schlimmsten Fall zu nerven.

Wenn Sie sich in einem dieser engen Anwendungsfälle befinden, geht es nur um Verschleierung, bei der es darum geht, kreativ zu werden. Es ist wirklich sehr ähnlich zu Code Golf - außer dass Sie derjenige sind, der das Puzzle erstellt. Das ist alles, was es wirklich ist - ein Puzzle. Und die Leute mögen es, Rätsel zu lösen, also ist es besser, wenn jemand es herausfindet.

Für die meisten Dinge auf der Welt ist es jedoch am besten, wenn Sie nicht befürchten, ein Geheimnis vor dem Benutzer zu haben. Stattdessen besteht die beste Vorgehensweise darin, den Benutzer auf das Geheimnis aufmerksam zu machen, es zu schützen (z. B. seinen Benutzernamen und sein Passwort) und das Risiko zu begrenzen, dass das Geheimnis herauskommt oder missbraucht wird.

In echten "Schlüsselmanagement" -Kryptografie- / Sicherheitskontexten lautet die Antwort von "wo der private Schlüssel gespeichert werden soll" "woanders!" Die Verschlüsselung ist ein Punkt-zu-Punkt-Schutz, und die Verschlüsselung mit öffentlichen und privaten Schlüsseln dient zum Schutz von Informationen während der Übertragung durch Zeit und Raum. Der private Schlüssel ist von Natur aus anfällig, und sein Schutz ist nicht wirklich eine Frage überlappender Verschlüsselung - er sichert ihn vollständig gegen Zugriff. Und wenn das System darauf zugreifen muss, muss das System selbst gesichert sein - und das können Sie auf einem Client-Computer nicht. Sie können jederzeit eine VM ausführen, den RAM sichern, den Netzwerkverkehr überwachen, einen Proxy oder eine virtuelle Netzwerkkarte installieren, die ausführbaren Dateien dekompilieren.

Wenn Sie jetzt etwas wie DRM ausführen müssen, bei dem die Speicherung eines Geheimnisses auf der Kontrolle der Nutzung der Software selbst beruht , ist dies eine völlig andere Situation .

TLDR: Bewahren Sie keine Geheimnisse vor dem Benutzer auf, bewahren Sie Geheimnisse vor dem Benutzer auf.

Eines der Systeme, die ich derzeit verwende, funktioniert auf diese Weise.

• Ich beginne mit einem Anmeldeformular des Authentifizierungsdienstes. Es verwendet eine Zwei-Faktor-Authentifizierung, um sicherzustellen, dass ich der bin, für den ich mich ausspreche.
• Ich erhalte ein temporäres SSL-Zertifikat, mit dem ich auf den geschützten Dienst zugreifen kann. Der Dienst verfolgt die Zertifikate, die er akzeptiert.
• Mein Austausch wird durch dieses Zertifikat vor dem Abhören verschlüsselt. Der Versuch, es zu knacken, ist nicht sehr nützlich, da es verfällt.
• Das Zertifikat läuft schnell ab (in einigen Stunden), jedoch nicht zu schnell, sodass ich nicht für jede Interaktion ein Kennwort angeben muss.
• Das Zertifikat kann auf der anderen Seite sofort widerrufen werden.

Natürlich läuft der geschützte Dienst außerhalb meiner Reichweite. Es könnte auf meinem Computer unter einem anderen Konto (und möglicherweise in einem Container) ausgeführt werden, aber ich habe Superuser-Berechtigungen und könnte dann versuchen, die Einschränkungen zu umgehen.

Grundsätzlich sind alle Wetten deaktiviert, wenn Sie einen böswilligen Superuser haben. Außerdem sollten Sie in Ihrem Bedrohungsmodell das Vorhandensein eines böswilligen Super-Users voraussetzen.

Daher müssen Sie Ihren geschützten Dienst von dem Client-Computer trennen, auf den Sie zugreifen können. Verschieben Sie den geschützten Dienst auf einen Computer, auf den nur über das Netzwerk zugegriffen werden kann. Stellen Sie Ihre Clients auf virtuelle Maschinen, damit sie nicht auf den Rest der physischen Maschine zugreifen können, auf der Ihr geschützter Dienst ausgeführt wird.

Wenn Ihr geschützter Dienst nicht so wertvoll ist, dass er solche Maßnahmen ausführen kann, wählen Sie den verschlüsselten Schlüsselspeicher, den das Betriebssystem Ihnen bietet: Sowohl Windows als auch Linux und OSX verfügen über Schlüsselringimplementierungen.

Meiner Meinung nach besteht die einzige Möglichkeit, dies vollständig sicher zu machen, darin, den Schlüssel / das Kennwort mit einer Passphrase zum Entsperren verschlüsseln zu lassen. Auf diese Weise muss die Passphrase bei jedem Start oder jeder Verwendung des Geheimnisses angegeben werden. Nicht allzu nützlich.

Eine andere Möglichkeit besteht darin, das Sicherheitssystem als eigenes Datenbankkonto zu konfigurieren. Nicht sehr skalierbar ...

Wenn jeder Benutzer auf einem System über ein eigenes DB-Konto verfügt und diese Konten vorab erstellt wurden, sodass die Anwendung keine Rechte zum Erstellen von Konten in DB für einen Benutzer hat, können Sie dem jedoch ziemlich nahe kommen. Auch dies ist keine gute Lösung, daher müssen Sie den Lesezugriff auf die Konfigurationsdateien stark einschränken und Ihren Super-Usern vertrauen.