Sicheres Speichern und Verwenden von Schlüsseln in einem eingebetteten System

Ich verwende einen Mikroprozessor - PIC32MZ2048efm144 MCU, der mit einem bestimmten Schlüssel verschlüsselte Befehle empfängt , entschlüsselt und den Befehl ausführt. Die verschlüsselten Befehle werden offline gespeichert , sodass ich den Schlüssel nicht jederzeit ändern kann. Der Schlüssel ist FIXED . Die Befehle werden von einem Server verschlüsselt und von einem Telefon heruntergeladen . Das Telefon sendet die verschlüsselten Befehle zu einem späteren Zeitpunkt an die MCU, wenn es nicht online ist . Die Befehle werden verschlüsselt, bevor das Telefon sie an die MCU übermittelt, sodass ein Sitzungsschlüssel nicht möglich ist.

Ich darf ein externes Verschlüsselungs-/Entschlüsselungsmodul an den PIC anschließen, aber dann werden die Daten in mindestens einer Richtung entschlüsselt passieren.

Die hier vorgestellte Lösung: Speichern eines sicheren Schlüssels im Speicher eines eingebetteten Geräts

verwendet Einmalschlüssel zum Verschlüsseln, aber ich muss einen einzigen supergeheimen Schlüssel speichern

Was mein Arbeitgeber verlangt, ist, dass die Schlüssel nicht zugänglich sind, sodass physischer Schutz außer dem, der durch sichere Speichermodule und die MCU geboten wird, nicht berücksichtigt wird.

Unter der Annahme, dass keine militärische Ausrüstung verwendet wird, gibt es irgendwelche bekannten Lösungen, die Sie kennen und empfehlen können?

Danke im Voraus!

Können Sie näher erläutern, was Sie zu verhindern versuchen? Was macht der Mikroprozessor? Glauben Sie, dass die Verwendung eines öffentlichen/privaten Schlüssels funktionieren könnte? Haben Sie den privaten Schlüssel auf dem Mikroprozessor gespeichert? Dann würden die Geräte, die Befehle senden, einen Sitzungsschlüssel erstellen, ihn mit dem öffentlichen Schlüssel verschlüsseln und an Sie senden. Danach verwenden beide Seiten den Sitzungsschlüssel. Was würde passieren, wenn ein Angreifer den öffentlichen Schlüssel hätte (der, obwohl er "öffentlich" heißt, nicht wirklich öffentlich sein muss)?
@mkeith Ich habe die Frage aktualisiert, hoffe es hilft :)
Da Sie sich für diesen PIC entschieden haben, warum nicht den von ihm bereitgestellten "programmatisch sicheren Schlüsselspeicher" verwenden? Es hat ein eigenes eingebautes Kryptomodul!
Ich glaube nicht, dass Sie den Wert Ihres Geheimnisses klar beziffert haben. Es scheint, als wollten Sie eine billige und zuverlässige Methode (die meiner Meinung nach unbekannt ist). Bitten Sie um Klärung, was möglich sein muss, nachdem eine Schwachstelle in dieser ersten Lösung gefunden wurde. Signierte Over-the-Air-Firmware-Updates wären meine erste nicht verhandelbare Funktion ... Es ist immer ein Systemproblem.
Nun, wenn der Speicher des PIC geschützt ist (und er sogar ein Schlüsselspeichermodul hat), warum nicht eine einfache AES-Verschlüsselung verwenden? Ich weiß, es ist symmetrisch, aber wenn der Server sicher ist (was wir irgendwie annehmen müssen), dann besteht hier kein Risiko - oder doch?
@pjc50 Dieses Bild unterstützt "Programmatically Secure Key Storage" nicht :( nur der PIC24 tut das..
Wenn Sie eine endliche Anzahl von Befehlen haben, die mit einem statischen Schlüssel verschlüsselt sind, gibt es einen Angriffstyp namens Replay-Angriff, über den Sie sich möglicherweise Sorgen machen müssen. Die Idee ist, dass der Angreifer den verschlüsselten Befehl sieht, das Ergebnis beobachtet, dann weiß, was dieser verschlüsselte Befehl tut, und ihn wiedergeben kann. Der Angreifer kann es möglicherweise nicht entschlüsseln und hat möglicherweise nicht den Schlüssel, aber er/sie kann den verschlüsselten Befehl jederzeit senden, wenn er oder sie will. Wenn der Angreifer den verschlüsselten Befehl nicht beobachten kann, ist eine Verschlüsselung gar nicht nötig.

Antworten (3)

Es tut mir leid, dass diese Antwort Ihr Problem nicht wirklich lösen wird. Aber es ist zu lang, um einen Kommentar einzufügen, und es wird Ihnen ermöglichen, Ihr Problem auf die richtige Weise zu überdenken (denn so wie es ist, halte ich es für fehlerhaft).

Diese Art von Problemen muss gelöst werden, indem alle Komponenten des Systems berücksichtigt werden und vernünftige Annahmen darüber getroffen werden, was ein potenzieller Hacker tun kann oder nicht tun kann.

Zum Beispiel:

Sie sagen: "Der PIC32MZ2048efm144 (MCU) empfängt mit einem bestimmten Schlüssel verschlüsselte Befehle, entschlüsselt sie und führt den Befehl aus". Ich nehme an, das Ergebnis der Ausführung des Befehls ist das Umschalten einiger GPIOs, um Dinge zu aktivieren.

Warum befürchten Sie dann, dass möglicherweise einige Daten entschlüsselt zwischen der MCU und einem Verschlüsselungs-/Entschlüsselungsmodul übertragen werden? Ein Hacker, der Zugriff auf die Hardware hat, um die entschlüsselten Befehle zu sehen, könnte ohnehin direkt auf die GPIOs der MCU einwirken und genauso einfach "das Zeug betätigen".

Zweites Beispiel:

Die Verwendung von pünktlichen Schlüsseln ist eine Idee. Aber wie Sie sagen, wo speichern Sie den Haupthauptschlüssel, der zum Generieren der Einmalschlüssel verwendet wird? Sie werden mit genau denselben Fragen konfrontiert wie bei Ihrem ursprünglichen Problem.

Eigentlich gibt es keine Möglichkeit, Ihr System sicher zu machen, wenn Sie annehmen, dass sich ein Hacker möglicherweise an jeder Stelle Ihres Systems einschleichen kann (was Sie meiner Meinung nach derzeit annehmen).

Was macht denn ein System sicher?

Eine Smartcard wird sicher gemacht, weil es unvernünftig ist anzunehmen, dass ein Hacker die internen Routen innerhalb des IC zwischen dem Speicher und dem CPU-Block untersuchen kann.

Ein elektrisches Türschloss wird sicher gemacht, weil es unvernünftig ist anzunehmen, dass ein Hacker die Drähte erreichen kann, die das Schloss betätigen.

Etc ... Im Grunde müssen Sie damit beginnen, Dinge zu identifizieren, die ein Hacker nicht tun kann, und von dort aus Ihre gesamte Lösung erarbeiten. Ist es beispielsweise möglich, Ihr gesamtes System in einer sicheren, physisch manipulationssicheren Box unterzubringen? In diesem Fall können Sie entschlüsselte Befehle frei durch einen internen Bus leiten lassen.

Sie können kein sicheres System aufbauen, ohne zu wissen, was der Hacker vernünftigerweise nicht tun kann. Das hast du uns nicht gesagt. Wir können daher keine Komplettlösung vorschlagen.

erstmal danke für die ausführliche antwort! Ich habe die Frage so aktualisiert, dass ich glaube, dass sie dir antworten wird :)
Was ich aus der Bearbeitung Ihres Beitrags verstehe, ist, dass nur die Schlüssel gesichert werden müssen. Die tatsächlichen Ergebnisse der Befehle müssen nicht gesichert werden. Legen Sie in diesem Fall die Schlüssel wie von Ihnen vorgeschlagen in ein externes sicheres Modul und akzeptieren Sie, dass die entschlüsselten Befehle deutlich sichtbar sind. Wenn mein Vorschlag aus irgendeinem Grund ungültig ist, nehmen Sie sich die Zeit, ausführlich zu erklären, was akzeptabel ist und was nicht . Es ist nicht nur ein weiterer Satz in Ihrem Beitrag, den wir brauchen. Wir brauchen das Gesamtbild der Sache. Wirklich.
Außerdem habe ich das Gefühl, dass die Verschlüsselung der Befehle nicht wirklich das ist, was Sie tun möchten. Normalerweise müssen wir Daten verschlüsseln (einige Informationen über etwas oder ein Dokument ...). Aber wir müssen selten Befehle verschlüsseln, die an ein Gerät gesendet werden. Befehle müssen normalerweise signiert werden , um sicherzustellen, dass sie von der autorisierten Partei stammen. Aber ihr Inhalt ist eigentlich selten sensibel. Sie sollten dies also auch bestätigen.

Dies sieht nach einem klassischen Fall aus, in dem eine asymmetrische Schlüsselverschlüsselung nützlich wäre. Bei der Verschlüsselung mit asymmetrischen Schlüsseln haben Sie zwei Schlüssel, einen privaten und einen öffentlichen. Sie möchten den privaten Schlüssel vollständig schützen, aber der öffentliche Schlüssel kann öffentlich gemacht werden und benötigt keinen Schutz. Möglicherweise können Sie den privaten Schlüssel auf dem sicheren System und den öffentlichen Schlüssel auf dem eingebetteten Gerät aufbewahren.

Die Entschlüsselung der Daten erfolgt mit dem privaten Schlüssel (und die Verschlüsselung mit dem öffentlichen Schlüssel). Andernfalls bedeutet dies, dass jeder entschlüsseln kann (da jeder Zugriff auf den öffentlichen Schlüssel hat), was ein Problem wäre. Daher muss sich der private Schlüssel im Gerät befinden. Also, wie legt man nun den privaten Schlüssel in das Gerät? Naja, zurück zum Anfangsproblem...
In der Lage zu sein, Befehle zu entschlüsseln, erlaubt es nicht, neue von Grund auf neu zu erstellen, daher ist es kein so großes Problem, dass der öffentliche Schlüssel irgendwie zugänglich ist
Dies ist im Allgemeinen dasselbe wie das kryptografische Signieren; was den Nachteil hat, dass jemand, der den öffentlichen Schlüssel hat (muss eigentlich nicht öffentlich sein, könnte so sicher gespeichert werden wie der symmetrische Schlüssel), alles entschlüsseln kann; aber wie masterX244 sagt, können Sie im Allgemeinen keine neuen Befehle erstellen/signieren. Ich denke, das ist eine gute Lösung.

Sie erklären nicht, warum Sie die Befehle verschlüsselt haben möchten (mit anderen Worten, was Ihr Bedrohungsmodell ist). Wollen Sie verhindern, dass ein Angreifer im Besitz des PIC-basierten Geräts ermittelt, welche Befehle an es gesendet werden? Oder versuchen Sie zu verhindern, dass das PIC-basierte Gerät eine Reihe von Befehlen ausführt, die von einem Gegner ersetzt werden, und ihm nur erlauben, Befehle auszuführen, die von Ihrem Server stammen?

Im ersten Fall stehen Sie vor einer fast unmöglichen Aufgabe: Ihr Gerät muss die Befehle entschlüsseln, um sie auszuführen – der Besitz des PIC-Geräts bedeutet den Besitz des Entschlüsselungsschlüssels. Ein Angreifer kann entweder den Schlüssel extrahieren (der auf dem PIC-Gerät gespeichert ist, das er besitzt) oder einfach warten, bis Ihre Firmware die Befehle entschlüsselt, und sie dann aus dem Speicher erfassen.

Wenn Sie andererseits nur versuchen sicherzustellen, dass Ihr Gerät nur Befehle ausführt, die von Ihrem Server stammen, haben Sie Glück. In diesem Fall können Sie eine Verschlüsselung mit öffentlichem Schlüssel (z. B. RSA) oder ein digitales Signaturschema mit öffentlichem Schlüssel (z. B. DSS) verwenden. In diesen speichert Ihr Gerät nur den öffentlichen Schlüssel: Dieser reicht aus, um die Befehle zu entschlüsseln (oder die digitale Signatur zu überprüfen), kann aber nicht verwendet werden, um Befehle zu verschlüsseln (oder eine digitale Signatur zu erzeugen), die das Gerät akzeptiert. Dazu ist der private Schlüssel erforderlich, mit dem Sie die Befehle vor dem Senden verschlüsseln (oder signieren). Der private Schlüssel muss Ihren Server nie verlassen. Noch besser, verschlüsseln oder signieren Sie die Befehle auf einem Computer, der nicht extern kommuniziert, und kopieren Sie diese nur auf den Server, damit der private Schlüssel niemals auf einem extern zugänglichen Server gefunden wird.

Sicheres Speichern und Verwenden von Schlüsseln in einem eingebetteten System
AntwortenHierDatenschutz-Bestimmungen1y, 0v