it-swarm.com.de

Wo soll der private Schlüssel gespeichert 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, unbefugten Zugriff zu erhalten.

Wenn ich jedoch Klartext verschlüssele, wo speichere ich dann den Schlüssel? Auf alles, worauf Software Zugriff hat, hätte ein entschlossener Angreifer Zugriff, unabhängig von der Verschleierung:

  • Angenommen, der Schlüssel ist durch das Sicherheitsmodell des Dateisystems geschützt. Aber was ist mit (böswilligen) Superusern oder Plattformen, die keine solche Wiedergabetreue bieten?
  • Oder der Schlüssel ist fest in Software-Binärdateien codiert, kann aber immer 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 das gleiche Problem für den Startwert.
  • usw.

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


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

Für mich scheint das jedoch immer noch unzureichend: Ich möchte nicht, dass jemand dort herumstochert, wo er nicht sein sollte!

23
Xophmeister

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

Jemand, der damals mit mir zusammenarbeitete, beschrieb das Entwerfen eines sicheren Systems in Bezug auf die Messlatte höher legen für Eindringlinge. Jede Sicherungsebene verringert also die Möglichkeit eines Angriffs.

Selbst wenn Sie beispielsweise den privaten Schlüssel perfekt sichern könnten, ist das System nicht vollständig sicher. Die korrekte Verwendung der Sicherheitsalgorithmen und die Aktualisierung der Patches legen jedoch die Messlatte höher. Aber ja, ein Supercomputer, der leistungsfähig genug ist und genügend Zeit hat, kann die Verschlüsselung unterbrechen. Ich bin sicher, dass all dies verstanden wird, also werde ich die Frage zurückbekommen.

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) Superusern oder Plattformen, die keine solche Wiedergabetreue bieten?

Ja, wenn Sie etwas wie Windows Key Store 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 mir zustimmen, dass dies die Messlatte höher legt. Die Dateisystem-ACLs bieten (wenn sie ordnungsgemäß implementiert sind) ein ziemlich gutes Schutzniveau. 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 aber immer 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 Java ist), muss verstehen, dass Java erzeugt Bytecode (usw.) und versteht, wie man es dekompiliert, liest es. Wenn Sie eine Sprache verwenden, die direkt schreibt Beim Maschinencode können Sie sehen, dass dies die Messlatte etwas höher legt. Dies ist keine ideale Sicherheitslösung, könnte aber ein gewisses Maß an Schutz bieten.

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

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

Ich denke, Sie haben bei jeder Sicherheitsrichtlinie ein Kernproblem festgestellt: Schlüsselverwaltung . Die Einrichtung einer Schlüsselverwaltungsrichtlinie ist für die Bereitstellung eines sicheren Systems von zentraler Bedeutung. Und es ist ein ziemlich breites 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 höher gelegt werden?

Wenn Sie bereit sind zu zahlen, gibt es einige Leute, die Lösungen dafür finden. Am Ende haben wir ein HSM (Hardware Security Module) verwendet. Es handelt sich im Grunde genommen um einen manipulationssicheren Server, der einen Schlüssel in der Hardware enthält. Dieser Schlüssel kann dann verwendet werden, um andere Schlüssel zu erstellen, die für die Verschlüsselung verwendet werden. Die Idee hier ist, dass (wenn richtig konfiguriert) der Schlüssel nie verlässt das HSM. HSMs kosten viel. In einigen Unternehmen (z. B. beim Schutz von Kreditkartendaten) sind die Kosten eines Verstoßes jedoch viel höher. Es gibt 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) muss physisch in den Server eingelegt werden, um einen Schlüssel zu ändern. Dies legt die Messlatte also ziemlich hoch, indem nur dann ein Verstoß zugelassen wird, wenn ein Quorum von Superusern zusammenarbeitet.

Es gibt möglicherweise Softwarelösungen, die ähnliche Funktionen wie ein HSM bieten, aber ich weiß nicht, um welche es sich handelt.

Ich weiß, dass dies nur einen Weg zur Beantwortung der Frage darstellt, aber ich hoffe, dass dies hilft.

26
Davin Tryon

Was Sie wollen, kann nicht getan werden.

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

Sie möchten grundsätzlich 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, wie Sie angeben, 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 braucht jemand Zugriff auf die Daten und jemand kann bösartig sein.

2
Pieter B

Dies ist eines dieser Probleme, die auf der Ebene, auf der sie erstellt wurden, nicht wirklich gelöst werden können. 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 die von Ihnen erwähnten Datenbankanmeldeinformationen. Natürlich möchten Sie, dass Ihr Client Zugriff darauf hat, aber keinen zufälligen Internet-Fremden. Daher benötigen Sie eine Art Identitäts-/Verifizierungs-/Anmeldesystem. Die Grundvoraussetzung, dies zu verbergen, ist jedoch ein Problem: Wenn der Benutzer selbst ein Geheimnis besitzen muss, Sie aber nicht möchten, dass er weiß, was dieses Geheimnis ist, können Sie es nur verstecken oder es ihnen 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 Zugriff auf die Datenbank für die Software auf Client-Ebene zu ermöglichen. Wenn der Client böswillig wird, sollte das Worst-Case-Szenario darin bestehen, 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, ausschließlich für diesen Client, ohne dass jemand anderes (einschließlich Sie) unter dem Chaos leidet.

Es gibt bestimmte Anwendungsfälle, in denen Sie nur möchten, dass bereitgestellte Software etwas tut, aber nicht jeder auf der Welt in der Lage ist, eine Verbindung herzustellen und dasselbe zu tun. Dafür verstecken Sie jedoch nur Geheimnisse, und der einzige gute Grund dafür ist nur, dies zu tun Kopfschmerzen oder Systemaktivität reduzieren. Wenn Ihre versteckten Informationen allgemein bekannt werden, sollten Sie sie nicht brechen, sondern im schlimmsten Fall 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 wie Code Golf - außer dass Sie derjenige sind, der das Puzzle erstellt. Das ist alles, was es wirklich ist - ein Rätsel. Und die Leute lösen gerne Rätsel, also ist es besser, wenn jemand es herausfindet.

Für die meisten Dinge auf der Welt ist es jedoch am besten, zu arbeiten, ohne sich Sorgen machen zu müssen, dass der Benutzer ein Geheimnis vor hat. Stattdessen empfiehlt es sich, den Benutzer nur in das Geheimnis einzulassen, es zu seiner Verantwortung zu machen, es zu schützen (z. B. seinen Benutzernamen und sein Passwort) und das Abwärtsrisiko zu begrenzen, was passiert, wenn das Geheimnis herauskommt oder missbraucht wird.

In echten "Schlüsselverwaltungs" -Kryptografie-/Sicherheitskontexten lautet die Antwort "Wo soll der private Schlüssel gespeichert werden?" "Woanders!" Die Verschlüsselung ist ein Punkt-zu-Punkt-Schutz, und die Verschlüsselung mit öffentlich-privaten Schlüsseln dient zum Schutz von Informationen auf dem Weg durch Zeit und Raum. Der private Schlüssel ist von Natur aus anfällig, und beim Schutz geht es nicht wirklich um überlappende Verschlüsselung, sondern darum, ihn vollständig vor dem Zugriff zu schützen. Und wenn das System darauf zugreifen muss, muss das System selbst gesichert sein - und das können Sie auf dem Computer eines Clients nicht tun. Sie können jederzeit eine VM ausführen, den Arbeitsspeicher entleeren, den Netzwerkverkehr abhören, einen Proxy oder eine virtuelle Netzwerkkarte installieren, die ausführbaren Dateien dekompilieren ... sich nicht freiwillig auf diesen verlorenen Kampf einlassen.

Wenn Sie nun etwas wie DRM tun müssen, bei dem Ihre Notwendigkeit, ein Geheimnis zu speichern, tatsächlich auf der Kontrolle der Verwendung der Software selbst basiert, das ist eine ganz andere Situation .


TLDR: Halten Sie keine Geheimnisse vor dem Benutzer, sondern Geheimnisse mit dem Benutzer.

2
BrianH

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

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

Natürlich läuft der geschützte Dienst irgendwo 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 ungültig, wenn Sie einen böswilligen Superuser haben. Und Sie sollten die Anwesenheit eines böswilligen Superusers in Ihrem Bedrohungsmodell annehmen.

Daher müssen Sie Ihren geschützten Dienst vom Client-Computer isolieren. 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, die verhindern, dass sie den Rest der physischen Maschine erreichen, auf der Ihr geschützter Dienst ausgeführt wird.

Wenn Ihr geschützter Dienst nicht so wertvoll ist, dass er solche Maßnahmen befehlen 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.

1
9000