Innerhalb einer Anwendung wird Secret Keys verwendet, um einen Hash für einen API-Aufruf zu berechnen. In einer .NET-Anwendung ist es ziemlich einfach, ein Programm wie Reflector zu verwenden, um Informationen aus der Assembly zu holen, um diese Schlüssel aufzunehmen.Schützen von geheimen API-Schlüsseln in einer Thick-Client-Anwendung
Verschleiert die Baugruppe eine gute Möglichkeit, diese Schlüssel zu sichern?
Wahrscheinlich nicht.
Sehen Sie sich die Kryptografie und die Windows-Mechanismen zum Verbergen von Informationen an (DPAPI und Speichern der Schlüssel in einem ACL-beschränkten Registrierungsschlüssel zum Beispiel). Das ist so gut, wie Sie für die Sicherheit benötigen, Sie müssen auf dem gleichen System wie Ihre Anwendung bleiben.
Wenn Sie nach einer Möglichkeit suchen, jemanden, der an der Maschine sitzt, daran zu hindern, Ihre Informationen zu erhalten, vergessen Sie es. Wenn jemand bestimmt ist und uneingeschränkten Zugriff auf einen Computer hat, der nicht unter Ihrer Kontrolle steht, gibt es keine Möglichkeit, zu 100% sicher zu sein, dass die Daten unter allen Umständen geschützt sind. Jemand, der entschlossen ist, wird darauf kommen, wenn sie es wollen.
Ich würde nicht so denken, wie Verschleierung (wie ich es zumindest verstehe) wird einfach mit den Namen der Methoden rumspielen, um es schwer zu machen (aber nicht unmöglich), den Code zu verstehen. Dies ändert nicht die Daten des tatsächlichen Schlüssels (den ich vermute, dass Sie irgendwo in einer Konstante gespeichert haben).
Wenn Sie es nur etwas schwieriger zu sehen machen möchten, könnten Sie eine einfache Chiffre auf dem Klartext (wie ROT-13 oder etwas) ausführen, so dass es zumindest nicht im Code im Code selbst gespeichert ist. Aber das wird bestimmt keinen entschlossenen Hacker davon abhalten, auf Ihren Schlüssel zuzugreifen. Eine stärkere Verschlüsselungsmethode wird nicht helfen, da Sie den Schlüssel für THAT immer noch im Code speichern müssen. Nichts schützt das.
Die einzige wirklich sichere Sache, die ich denken kann, ist, den Schlüssel außerhalb der Anwendung irgendwie zu halten, und dann den Zugriff auf den Schlüssel zu beschränken. Beispielsweise könnten Sie den Schlüssel in einer separaten Datei behalten und dann die Datei mit einer benutzerbasierten Benutzereinschränkung auf Betriebssystemebene schützen. das würde wahrscheinlich funktionieren. Sie könnten dasselbe mit einer Datenbankverbindung tun (wiederum unter Berufung auf die benutzerbasierte Zugriffsbeschränkung, um nicht autorisierte Benutzer aus der Datenbank herauszuhalten).
Ich habe mit der Idee gespielt, dies für meine Apps zu tun, aber ich habe es nie implementiert.
DannySmurf ist richtig, dass Sie nicht Schlüssel von der Person verstecken können, die eine Anwendung ausführt; Wenn die Anwendung zu den Schlüsseln kommen kann, so kann die Person.
Was möchten Sie jedoch genau erreichen?
Je nach dem, was es ist, gibt es oft Möglichkeiten, um Ihr Ziel zu erreichen, die nicht einfach auf ein geheimes "Geheimnis" auf dem Computer Ihres Benutzers verlassen.
spät, um das Spiel hier ...
Der Ansatz, die Schlüssel in der Montage/Montage Config-Speicherung ist grundsätzlich unsicher. Es gibt keine Möglichkeit, sie zu speichern, da ein bestimmter Benutzer Zugriff hat. Es ist mir egal, ob Sie das beste/teuerste Verschleierungsprodukt auf dem Planeten verwenden. Es ist mir egal, wenn Sie PDAPI verwenden, um die Daten zu sichern (obwohl das besser ist). Es ist mir egal, wenn Sie einen lokalen OS-geschützten Schlüsselspeicher verwenden (das ist noch besser). Keine sind ideal, da alle unter dem gleichen Kernproblem leiden: Der Benutzer hat Zugang zu den Schlüsseln, und sie sind dort, unveränderlich für Tage, Wochen, möglicherweise sogar Monate und Jahre.
Ein weitaus sicherer Ansatz wäre es, Ihre API-Aufrufe mit bewährten PKI zu sichern. Dies hat jedoch einen offensichtlichen Leistungsaufwand, wenn Ihre API-Aufrufe gesprächig sind, aber für die große Mehrheit der Anwendungen ist dies kein Problem.
Wenn die Leistung ein Problem darstellt, können Sie Diffie-Hellman über asymmetrische PKI verwenden, um einen gemeinsamen geheimen symmetrischen Schlüssel für die Verwendung mit einer Chiffre wie AES zu erstellen. "shared" bedeutet in diesem Fall "shared" zwischen Client und Server, nicht alle Clients/Benutzer. Es gibt keinen fest codierten/gebackenen Schlüssel. Irgendwo.
Die Schlüssel sind flüchtig, werden jedes Mal neu generiert, wenn der Benutzer das Programm ausführt, oder wenn Sie wirklich paranoid sind, könnten sie eine Auszeit nehmen und Erholung benötigen.
Die berechneten gemeinsamen geheimen symmetrischen Schlüssel selbst werden nur im Speicher in SecureString gespeichert. Sie sind schwer zu extrahieren, und selbst wenn Sie es tun, sind sie nur für eine sehr kurze Zeit und nur für die Kommunikation zwischen diesem bestimmten Client (dh dieser Sitzung) gut. Mit anderen Worten, selbst wenn jemand seine lokalen Schlüssel hackt, sind sie nur dazu geeignet, die lokale Kommunikation zu stören. Sie können dieses Wissen nicht nutzen, um andere Benutzer zu beeinflussen, im Gegensatz zu einem eingebackenen Schlüssel, den alle Benutzer über code/config teilen.
Darüber hinaus werden nie die gesamten Schlüssel selbst jemals über das Netzwerk übergeben. Der Client Alice und der Server Bob berechnen diese unabhängig voneinander. Die Informationen, die sie zu diesem Zweck weitergeben, könnten theoretisch von Charlie von Dritten abgefangen werden, was ihm erlaubt, den gemeinsamen geheimen Schlüssel unabhängig zu berechnen. Aus diesem Grund verwenden Sie diese (wesentlich kostengünstigere) asymmetrische PKI, um die Schlüsselgenerierung zwischen Alice und Bob zu schützen.
In diesen Systemen ist die Schlüsselgenerierung häufig mit der Authentifizierung und somit der Sitzungsgenerierung gekoppelt. Sie "loggen" sich ein und erstellen Ihre "Sitzung" über PKI, und danach haben sowohl der Client als auch der Server unabhängig einen symmetrischen Schlüssel, der für eine schnellere Verschlüsselung für alle nachfolgenden Kommunikation in dieser Sitzung verwendet werden kann. Für Server mit hohem Serveraufwand ist dies wichtig, um Rechenzyklen bei der Entschlüsselung zu sparen, indem TLS für alles verwendet wird.
Aber warte: wir sind noch nicht sicher. Wir haben nur das Lesen der Nachrichten verhindert.
Beachten Sie, dass ein Message Digest-Mechanismus weiterhin erforderlich ist, um Man-in-the-Middle-Manipulationen zu verhindern. Während niemand die übertragenen Daten lesen kann, gibt es nichts, was sie daran hindert, sie zu ändern. Sie Hash also die Nachricht vor der Verschlüsselung, dann senden Sie den Hash zusammen mit der Nachricht. Der Server hasht die Nutzlast bei der Entschlüsselung erneut und überprüft, ob sie mit dem Hash übereinstimmt, der Teil der Nachricht war. Wenn die Nachricht während der Übertragung geändert wurde, wird dies nicht der Fall sein, und die gesamte Nachricht wird verworfen/ignoriert.
Der letzte Mechanismus, gegen den man sich schützen muss, sind Replay-Angriffe. An diesem Punkt haben Sie verhindert, dass Personen Ihre Daten lesen und Ihre Daten ändern, aber Sie haben sie nicht daran gehindert, sie einfach erneut zu senden. Wenn dies ein Problem für Ihre Anwendung ist, muss das Protokoll Daten bereitstellen, und sowohl der Client als auch der Server müssen über genügend Statusinformationen verfügen, um eine Wiederholung zu erkennen. Dies könnte so einfach sein wie ein Zähler, der Teil der verschlüsselten Nutzlast ist. Beachten Sie, dass Sie, wenn Sie einen Transport wie UDP verwenden, wahrscheinlich bereits über einen Mechanismus verfügen, mit duplizierten Paketen umzugehen, und daher bereits mit Replay-Angriffen umgehen können.
Was offensichtlich sein sollte, ist es nicht einfach, dieses Recht zu bekommen. Verwenden Sie daher PKI, es sei denn, Sie können es nicht.
Beachten Sie, dass dieser Ansatz stark in der Spieleindustrie verwendet wird, wo es äußerst wünschenswert ist, so wenig Rechenleistung wie möglich auf jeden Spieler auszugeben, um eine höhere Skalierbarkeit zu erreichen und gleichzeitig Sicherheit vor Hackerangriffen zu bieten.
Also abschließend, wenn das wirklich etwas ist, das ein Anliegen ist, anstatt zu versuchen, eine sichere Speicherung der API-Schlüssel zu finden, nicht. Ändern Sie stattdessen, wie Ihre App diese API verwendet (vorausgesetzt, Sie haben natürlich die Kontrolle über beide Seiten). Verwenden Sie eine PKI oder verwenden Sie eine PKI-Shared Symmetric Hybrid, wenn PKI zu langsam ist (was derzeit ein Problem ist). Dann haben Sie nichts gespeichert, das ein Sicherheitsrisiko darstellt.
Es ist beängstigend, dass es keinen Weg gibt, aber ich muss zustimmen, weil es Tatsache ist. – Shimmy