Schützen geheimer API-Schlüssel in einer Thick-Client-Anwendung

Question

Innerhalb einer Anwendung verwende ich Secret Keys, 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 abzurufen, um diese Schlüssel einzuschließen.

Ist die Verschleierung der Baugruppe eine gute Möglichkeit, diese Schlüssel zu sichern?

Answer 1

Wahrscheinlich nicht.

Informieren Sie sich über Kryptografie und die in Windows integrierten Mechanismen zum Verbergen von Informationen (z. B. DPAPI und Speichern der Schlüssel in einem durch ACL eingeschränkten Registrierungsschlüssel).Das ist das Beste, was Sie für die Sicherheit erhalten, die Sie benötigen, um auf demselben System wie Ihre Anwendung zu bleiben.

Wenn Sie nach einer Möglichkeit suchen, zu verhindern, dass jemand, der physisch am Automaten sitzt, an Ihre Informationen gelangt, vergessen Sie es.Wenn jemand ermittelt wird und uneingeschränkten Zugriff auf einen Computer hat, der nicht unter Ihrer Kontrolle steht, gibt es keine 100-prozentige Sicherheit, dass die Daten unter allen Umständen geschützt sind.Wer entschlossen ist, wird es schaffen, wenn er will.

Answer 2

Das würde ich nicht glauben, da die Verschleierung (so wie ich es zumindest verstehe) einfach mit den Methodennamen herumspielen wird, um das Verständnis des Codes zu erschweren (aber nicht unmöglich).Dadurch werden die Daten des eigentlichen Schlüssels nicht geändert (den Sie vermutlich irgendwo in einer Konstante gespeichert haben).

Wenn Sie die Sichtbarkeit etwas erschweren möchten, können Sie den Klartext mit einer einfachen Chiffrierung versehen (wie ROT-13 oder so etwas), sodass er zumindest nicht im Klartext im Code selbst gespeichert wird.Aber das wird sicher keinen entschlossenen Hacker davon abhalten, auf Ihren Schlüssel zuzugreifen.Eine stärkere Verschlüsselungsmethode hilft nicht weiter, da Sie den Schlüssel dafür immer noch im Code speichern müssten und es nichts gibt, was ihn schützt.

Das einzig wirklich Sichere, was mir einfällt, ist, den Schlüssel irgendwie außerhalb der Anwendung zu halten und dann den Zugriff auf den Schlüssel einzuschränken.Beispielsweise könnten Sie den Schlüssel in einer separaten Datei aufbewahren und die Datei dann mit einer benutzerbasierten Einschränkung auf Betriebssystemebene schützen;das würde wahrscheinlich funktionieren.Das Gleiche können Sie auch mit einer Datenbankverbindung tun (wobei Sie sich wiederum auf die benutzerbasierte Zugriffsbeschränkung verlassen, um nicht autorisierte Benutzer vom Zugriff auf die Datenbank fernzuhalten).

Ich habe mit dem Gedanken gespielt, dies für meine Apps zu tun, habe es aber nie umgesetzt.

Answer 3

DannySmurf hat Recht, dass man Schlüssel nicht vor der Person verbergen kann, die eine Anwendung ausführt;Wenn die Anwendung an die Schlüssel gelangen kann, kann dies auch die Person tun.

Was genau wollen Sie jedoch erreichen?

Je nachdem, um was es sich handelt, gibt es oft Möglichkeiten, Ihr Ziel zu erreichen, die nicht einfach darauf beruhen, ein Geheimnis auf dem Computer Ihres Benutzers zu bewahren.

Answer 4

Zu spät zum Spiel hier...

Der Ansatz, die Schlüssel in der Assembly/Assembly-Konfiguration zu speichern, ist grundsätzlich unsicher.Es gibt keine sichere Möglichkeit, es zu speichern, da ein bestimmter Benutzer Zugriff darauf hat.Es ist mir egal, ob Sie das beste/teuerste Verschleierungsprodukt der Welt verwenden.Es ist mir egal, ob Sie PDAPI zum Sichern der Daten verwenden (obwohl dies besser ist).Es ist mir egal, ob Sie einen lokalen, vom Betriebssystem geschützten Schlüsselspeicher verwenden (das ist sogar noch besser).Keiner ist ideal, da alle unter dem gleichen Kernproblem leiden:Der Benutzer hat Zugriff auf die Schlüssel, und sie bleiben unverändert über Tage, Wochen, möglicherweise sogar Monate und Jahre erhalten.

Ein weitaus sichererer Ansatz wäre, Ihre API-Aufrufe mit bewährter PKI zu sichern.Dies führt jedoch zu offensichtlichen Leistungseinbußen, wenn Ihre API-Aufrufe sehr gesprächig sind. Für die überwiegende Mehrheit der Anwendungen stellt dies jedoch kein Problem dar.

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 Verschlüsselung wie AES zu erstellen.„Geteilt“ bedeutet in diesem Fall, dass es zwischen Client und Server geteilt wird, nicht zwischen allen Clients/Benutzern.Es gibt keinen fest codierten/eingebackenen Schlüssel.Überall.

Die Schlüssel sind vorübergehend und werden jedes Mal neu generiert, wenn der Benutzer das Programm ausführt. Wenn Sie wirklich paranoid sind, kann es zu einer Zeitüberschreitung kommen und eine Wiederherstellung erforderlich sein.

Die berechneten gemeinsamen geheimen symmetrischen Schlüssel selbst werden nur im Speicher in SecureString gespeichert.Sie sind schwer zu extrahieren, und selbst wenn Sie das tun, sind sie nur für eine sehr kurze Zeit und nur für die Kommunikation zwischen diesem bestimmten Client (dh dieser Sitzung) nützlich.Mit anderen Worten: Selbst wenn jemand seine lokalen Schlüssel hackt, sind diese 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 eingebauten Schlüssel, der von allen Benutzern über Code/Konfiguration geteilt wird.

Darüber hinaus werden niemals die gesamten Schlüssel selbst über das Netzwerk weitergegeben.Der Client Alice und der Server Bob berechnen sie unabhängig voneinander.Die Informationen, die sie zu diesem Zweck weitergeben, könnten theoretisch von einem Dritten, Charlie, abgefangen werden, sodass dieser den gemeinsamen geheimen Schlüssel unabhängig berechnen kann.Deshalb nutzen Sie diese (deutlich kostenintensivere) 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 damit der Sitzungserstellung gekoppelt.Sie „melden sich an“ und erstellen Ihre „Sitzung“ über PKI. Sobald dies abgeschlossen ist, verfügen sowohl der Client als auch der Server unabhängig voneinander über einen symmetrischen Schlüssel, der für eine um Größenordnungen schnellere Verschlüsselung für die gesamte nachfolgende Kommunikation in dieser Sitzung verwendet werden kann.Bei Hochleistungsservern ist dies wichtig, um Rechenzyklen bei der Entschlüsselung einzusparen, anstatt beispielsweise TLS für alles zu verwenden.

Aber warte:Wir sind noch nicht sicher.Wir haben lediglich das Lesen der Nachrichten verhindert.

Beachten Sie, dass es immer noch notwendig ist, einen Message-Digest-Mechanismus zu verwenden, um Man-in-the-Middle-Manipulationen zu verhindern.Während niemand die übertragenen Daten lesen kann, steht einer Änderung ohne MD nichts im Wege.Sie hashen also die Nachricht vor der Verschlüsselung und senden den Hash dann zusammen mit der Nachricht.Der Server hasht die Nutzlast dann nach 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 Schutzmechanismus sind Wiederholungsangriffe.Zu diesem Zeitpunkt haben Sie Personen daran gehindert, Ihre Daten zu lesen und zu ändern, aber Sie haben sie nicht daran gehindert, sie einfach erneut zu senden.Wenn dies ein Problem für Ihre Anwendung darstellt, muss das Protokoll Daten bereitstellen und sowohl Client als auch Server müssen über genügend Statusinformationen verfügen, um eine Wiedergabe zu erkennen.Dies könnte so etwas Einfaches wie ein Zähler sein, der Teil der verschlüsselten Nutzlast ist.Beachten Sie, dass Sie bei Verwendung eines Transportmittels wie UDP wahrscheinlich bereits über einen Mechanismus zum Umgang mit duplizierten Paketen verfügen und somit bereits mit Replay-Angriffen umgehen können.

Es sollte klar sein, dass es nicht einfach ist, dies richtig zu machen.Verwenden Sie daher PKI, es sei denn, Sie können dies ABSOLUT nicht.

Beachten Sie, dass dieser Ansatz in der Spielebranche häufig verwendet wird, wo es äußerst wünschenswert ist, so wenig Rechenleistung wie möglich für jeden Spieler aufzuwenden, um eine höhere Skalierbarkeit zu erreichen und gleichzeitig Sicherheit vor Hackern und neugierigen Blicken zu bieten.

Zusammenfassend lässt sich sagen: Wenn dies wirklich ein Problem darstellt, sollten Sie es lieber lassen, anstatt zu versuchen, einen sicheren Speicher für die API-Schlüssel zu finden.Ändern Sie stattdessen, wie Ihre App diese API verwendet (natürlich vorausgesetzt, Sie haben die Kontrolle über beide Seiten).Verwenden Sie eine PKI oder einen PKI-gemeinsamen symmetrischen Hybrid, wenn die PKI zu langsam ist (was heutzutage selten ein Problem darstellt).Dann werden keine sicherheitsrelevanten Daten gespeichert.