Verschlüsselungsschlüssel speichern - Best Practices?

Question

Ich habe eine Webanwendung, die einen symmetrischen Verschlüsselungsalgorithmus verwendet.

Wie würden Sie den geheimen Schlüssel und den Initialisierungsvektor speichern? Das Speichern als Literal im Code scheint eine schlechte Idee zu sein. Wie wäre es mit App-Einstellungen? Was ist die beste Vorgehensweise hier?

Answer 1

Ein Standardansatz in der Webapp-Welt ist es, den Schlüssel aufzuteilen und an verschiedenen Stellen zu platzieren. Z. B. könnten Sie den Schlüssel teilen und einen Teil davon in das Dateisystem (außerhalb des "webapps" -Verzeichnisses), einen Teil davon in die JNDI-Konfiguration (oder eine .net-Entsprechung) und einen Teil davon in die Datenbank einfügen. Es ist nicht besonders schwierig, ein einzelnes Teil zu erhalten, wenn Sie kompromittiert sind, z. B. das Durchsuchen von Backup-Medien oder SQL-Injection, aber das Abrufen aller Teile erfordert viel mehr Arbeit.

Sie können einen Schlüssel teilen, indem Sie ihn mit Zufallszahlen der gleichen Größe XOR-ing. (Verwenden Sie einen kryptografisch starken Zufallszahlengenerator!) Sie können diesen Vorgang mehrmals wiederholen, wenn Sie den Schlüssel in mehrere Teile aufteilen möchten. Am Ende des Prozesses möchten Sie z.B. drei partielle Schlüssel, so daß p1^p2^p3 = Schlüssel ist. Möglicherweise müssen Sie einige der Teilschlüssel mit base64 codieren, damit sie ordnungsgemäß gespeichert werden können, z. B. in einer JNDI-Eigenschaft.

(Es gibt ausgefeiltere Möglichkeiten, einen Schlüssel aufzuteilen, z. B. einen n-von-m-Algorithmus, bei dem nicht alle Teile erforderlich sind, um den Schlüssel neu zu erstellen, aber weit darüber hinaus.)

Wenn Sie verlangen können, dass der Benutzer das Passwort aktiv eingibt, gibt es PBE (Passwort-basierte Verschlüsselung) Algorithmen, die ein Passwort in einen guten symmetrischen Schlüssel konvertieren. Sie möchten einen finden, der auch eine externe Datei benötigt. Wiederum ist es ein Fall, dass die Band-Backups oder das Passwort selbst nicht ausreichen, Sie brauchen beides. Sie können dies auch verwenden, um das Passwort in zwei Teile mit JNDI aufzuteilen - Sie können eine Klartext-Passphrase in JNDI und eine Initialisierungsdatei irgendwo im Dateisystem verwenden.

Schließlich, was auch immer Sie tun, stellen Sie sicher, dass Sie Ihre Anwendung relativ einfach "rekey" können. Ein Ansatz besteht darin, das oben erhaltene Passwort zu verwenden, um eine andere Datei zu entschlüsseln, die den eigentlichen Verschlüsselungsschlüssel enthält. Dies macht es einfach, das Passwort zu ändern, wenn Sie der Meinung sind, dass es kompromittiert wurde, ohne dass eine massive Wiederverschlüsselung aller Daten erforderlich wäre - einfach den tatsächlichen Schlüssel erneut verschlüsseln.

Answer 2

-Stick in der web.config und encrypt that section

This SO question Gespräche mehr über web.config Verschlüsselung

Answer 3

Ist es möglich, dass Sie ein Passwort interaktiv einzugeben, wenn die Anwendung startet? Auf diese Weise müssen Sie den Schlüssel nicht speichern, oder zumindest Schlüssel (ob symmetrische oder private Schlüssel) können mit diesem "Bootstrap" -Passwort verschlüsselt werden.

Wenn nicht, speichern Sie Ihren geheimen Schlüssel in einer Datei und ändern Sie seine Berechtigungen so, dass sie nur dem Benutzer zugänglich sind, der die Webanwendung ausführt.

Diese Ansätze sind plattformunabhängig. Für konkretere Vorschläge wären Informationen zu Ihrer Plattform hilfreich.

Übrigens sollte ein Initialisierungsvektor nur für eine Nachricht verwendet werden. Und IVs müssen nicht geheim gehalten werden, so dass Sie es überall speichern können, aber es ist üblich, es mit der einen Nachricht zu speichern, die es verwendet.

Answer 4

Dies sollte helfen ...

http://msdn.microsoft.com/en-us/library/ms998280.aspx

Aber sollten Sie wirklich in Betracht ziehen werde PKI, wenn Sie Ihre Daten zu schützen ernst meinen.

Answer 5

Ich habe einen Ansatz verwendet, bei dem meine Anwendung beim Start einen symmetrischen Schlüssel benötigt und in einer bestimmten Datei danach sucht. Sobald die Anwendung gestartet ist, entferne ich die Datei. Eine Kopie der Datei wird remote für alle erforderlichen Neustarts aufbewahrt. Offensichtlich ist dieser Ansatz nicht praktikabel, wenn Ihre Anwendung häufig neu gestartet wird.

Eine andere Alternative wäre ein Zertifikatsmanager wie der Windows Certificate Store. Es kann Zertifikate und deren Schlüssel sicher speichern, und es ist auch möglich, private Schlüssel als nicht exportierbar zu markieren, so dass es einige ernsthafte Hacking erfordern würde, um den Schlüssel herauszubekommen. Ihre Anwendung könnte ihr Zertifikat aus dem Zertifikatsspeicher laden und Vorgänge zum Signieren von Anforderungen oder zum Generieren neuer symmetrischer Schlüssel aufrufen können. Außerdem können Sie verschiedenen Zertifikatsspeichern Berechtigungen zuweisen, sodass nur bestimmte berechtigte Benutzer auf das Zertifikat zugreifen können.