Ich arbeite an einem eingebetteten Gerät, das Daten sendet / empfängt und im Chiffretextmodus (verschlüsselter Modus) speichert. Was ist nun der beste Ansatz zum Speichern von Schlüsseln (ich habe eine MCU der ARM CORTEX M-Serie verwendet)?
1-Schlüssel im SRAM-Speicher speichern und bei jeder Startsequenz Schlüssel in die eingebettete MCU einspeisen und im SRAM-Speicher speichern. Ich denke, es ist der beste Weg, wenn die MCU das Eindringen erkennt (mit Manipulationssensor oder ...), kann sie SRAM schnell löschen und sich selbst zurücksetzen. Nachteil: Wenn es dem Angreifer gelingt, Manipulationen und Zugriff auf das Gerät zu passieren, wie sicher ist der SRAM-Speicher (gegen Code-Mining). Ich kann keine Sicherheitsfunktion für diesen Speicher in MCUs finden.
2-Generieren Sie Schlüssel und speichern Sie sie im Flash-Speicher bei der Programmierung der MCU. Der MCU-Flash-Speicher unterstützt CRP (Code-Leseschutz), das Code-Mining verhindert, und mit Hilfe der internen AES-Engine und der RNG-Engine (Random Number Generation) können wir einen zufälligen Schlüssel erstellen und den Flash-Speicher verschlüsseln und diesen zufälligen Schlüssel im OTP speichern ( einmal programmierbarer Speicher - ein 128-Bit-verschlüsselter Speicher), dann dekodieren wir bei der Codeausführung den Flash-Speicher mit RNG-Schlüssel und Zugriff auf den ursprünglichen Schlüssel und die Codes. Nachteil: Schlüssel werden in einem nichtflüchtigen Speicher gespeichert, Sabotageversuche sind nutzlos und Angreifer haben viel Zeit, um Schlüssel zu schürfen.
3-Gespeicherter Schlüssel im EEPROM-Speicher, Kombination aus 2 obigen Ansätzen, Schlüssel im nicht flüchtigen Speicher gespeichert, aber wenn Manipulationen das Eindringen erkennen, ist das EEPROM löschbar.
Ich betrachte LPC18S57FBD208 (Cortex m3 mit 1 MB Flash-Speicher, 180 MHz, 136 KB SRAM, 16 KB EEPROM und einem TFT-LCD-Controller, den ich zum Ansteuern eines 7-Zoll-TFT-LCD und einer AES-128-Bit-Krypto-Engine benötige). Gibt es dafür einen anderen besseren Vorschlag?
Keine dieser Optionen ist besonders besser oder schlechter als die anderen, weil sie alle sehr unsicher sind. Ich gehe von Möglichkeit 4 aus.
SRAM ist der sicherste Ort zum Speichern von Schlüsseln, aber Sie dürfen sie niemals von außen injizieren. Sie müssen IMMER während des Bootens im Prozessor generiert werden. Alles andere macht den Rest sofort ungültig – es ist automatisch unsicher.
Speichern Sie keine Schlüssel im nichtflüchtigen Speicher, da haben Sie Recht. Es spielt keine Rolle, ob Sie das EEPROM oder den Flash-Speicher vor dem Auslesen schützen. Diese Code-Leseschutzsicherung lässt sich leicht umkehren. Ein Angreifer muss nur die Kappe entfernen (die schwarze Epoxidverpackung entfernen oder chemisch wegätzen, um den Siliziumchip im Inneren freizulegen). An diesem Punkt können sie den Teil des Chips verdecken, der aus nichtflüchtigen Speicherzellen besteht (diese Abschnitte sind sehr regelmäßig und während einzelne Speicherzellen viel zu klein sind, um gesehen zu werden, kann die größere Struktur sein) und ein kleines Stück von etwas UV-undurchlässig wird über diesem Abschnitt maskiert. Dann kann der Angreifer einfach 5-10 Minuten lang ein UV-Licht auf den Chip strahlen und alle Sicherungen zurücksetzen, einschließlich der CRP-Sicherung. Der OTP-Speicher kann jetzt von jedem Standard-Programmierer gelesen werden.
Oder, wenn sie gut finanziert sind (sagen wir, jemandem sind diese Schlüssel mehr als 1000 Dollar wert), können sie die Speicherzellen einfach direkt mit verschiedenen Arten von Elektronenmikroskopen lesen.
Um sicher zu sein, müssen Schlüssel gelöscht und nicht versteckt werden.
Nun zu Variante 4:
Es gibt jedoch ein Problem, nämlich dass nichts außer der CPU eine Ahnung hat, was der geheime Schlüssel ist. Kein Problem: Verwenden Sie Public-Key-Kryptographie. Was Sie im OTP-Speicher gespeichert haben, ist Ihr öffentlicher Schlüssel. Dieser Schlüssel kann von jedem gelesen werden, Sie können ihn auf einem Stapel austauschen, Sie können ihn in 5 Fuß hohen Buchstaben an die Seite eines Öltankers malen, es spielt keine Rolle. Das Wunderbare an der Kryptografie mit öffentlichen Schlüsseln ist, dass sie asymmetrisch ist. Der Schlüssel, um etwas zu verschlüsseln, kann es nicht entschlüsseln, das erfordert den privaten Schlüssel. Und umgekehrt kann der Schlüssel zum Entschlüsseln von etwas, das durch den öffentlichen Schlüssel verschlüsselt wurde, nicht zum Verschlüsseln von etwas verwendet werden. Die CPU generiert also die geheimen Schlüssel, verwendet Ihren gespeicherten öffentlichen Schlüssel, um die geheimen Schlüssel zu VERSCHLÜSSELN, und sendet sie einfach über USB oder RS232 oder was auch immer Sie wollen. Das Lesen des geheimen Schlüssels erfordert Ihren privaten Schlüssel, die nicht gespeichert, gesendet oder überhaupt mit dem Chip in Verbindung gebracht werden müssen. Sobald Sie den geheimen Schlüssel mit Ihrem privaten Schlüssel entschlüsselt haben (anderswo, außerhalb des Chips), sind Sie fertig. Sie haben einen sicher übertragenen geheimen Schlüssel, der vollständig innerhalb des Chips ERZEUGT wurde, ohne etwas außer einem öffentlichen Schlüssel speichern zu müssen - der, wie bereits erwähnt, überhaupt nicht vor dem Lesen geschützt werden muss.
Dieser Prozess wird formal als Schlüsselaushandlung bezeichnet, und jedes Ding verwendet ihn. Sie haben es heute mehrmals benutzt. Es gibt viele Ressourcen und Bibliotheken, um damit umzugehen. Bitte 'injizieren' Sie niemals Schlüssel in irgendetwas.
Eine letzte zu erwähnende Sache: All dies ist strittig, da der AES-Schlüssel leicht mithilfe von Seitenkanalangriffen wiederhergestellt werden kann, die auf der Stromversorgung sitzen und winzige Änderungen der Stromaufnahme und das Timing zwischen diesen Änderungen messen, die durch das Umdrehen von Bits in der CPU verursacht werden als Register. Dies, kombiniert mit dem Wissen darüber, wie AES (oder was auch immer aus der sehr kleinen Menge möglicher Verschlüsselungsalgorithmen verwendet werden könnte) funktioniert, macht es relativ einfach und kostengünstig, den Schlüssel wiederherzustellen. Es erlaubt nicht, den Schlüssel zu lesen, aber es kann den Schlüsselraum auf etwas lächerlich Kleines wie 255 mögliche Schlüssel einschränken. Der Chip kann es auch nicht erkennen, da es stromaufwärts liegt.
Dies hat AES-256-verschlüsselte Bootloader auf "sicheren" Kryptoprozessoren besiegt, und es ist nicht einmal so schwer. Soweit ich weiß, gibt es keine echten Hardware-Gegenmaßnahmen für diesen Angriff. Es sind jedoch die Verschlüsselungsalgorithmen selbst und wie sie eine CPU zum Umdrehen von Bits benötigen, die diese Sicherheitsanfälligkeit verursacht. Ich vermute, dass seitenkanalresistente oder seitenkanalsichere Algorithmen entwickelt werden müssen (und hoffentlich werden).
So wie es derzeit aussieht, lautet die wirkliche Antwort darauf, wie man einen Schlüssel sicher auf einem eingebetteten Gerät speichert (oder auch nur einen temporären Schlüssel verwendet): Das geht nicht.
Aber zumindest wenn Sie jedes Mal einen neuen Schlüssel generieren, indem Sie die Schlüsselaushandlung in Option 4 verwenden, kann ein Seitenkanalangriff nur den Schlüssel eines verwendeten Kanals kompromittieren, und nur, wenn sie eine Weile Zeit haben, die Stromversorgung zu überwachen, während Daten verschlüsselt werden . Wenn Sie häufig neue intern generierte Schlüssel aushandeln, kann dies nützliche Sicherheitsmaßnahmen bieten.
Generieren Sie Schlüssel und speichern Sie diese so kurz wie möglich.
Mahmud Hosseinipour
bakcsa83
Lundin
Bogenmaß
The wonderful thing about private key cryptography is that it is asymmetric.
Auch wenn aus Ihrem Beitrag klar hervorgeht, dass Sie dies wissen, werde ich es für andere Leser erwähnen ... s/private/public im obigen Zitat.Greg