Hallo zusammen,
wie funktionieren eigentlich verschlüsselte FW-Updates?
Wenn ich ein verfahren wie AES verwende, muss ja der Schlüssel in der FW
des Gerätes bekannt sein, was ja potentiell als unsicher gilt.
Wenn ich ein Verfahren wie RSA verwende, benötige ich den öffentlichen
Schlüssel des Gerätes, der natürlich individuell sein soll und ebenfalls
sicher abgelegt sein muss.
Das sichere Ablegen von irgendwelchen Schlüsseln bekommt man ja über
irgendeinen speziellen Security Baustein hin ... Aber die bei einem
"sicheren" FW-Update zu Grunde liegenden Mechanismen sind mir momentan
noch geläufig...
Wenn man googelt findet man nur Firmen bzw. Produkte zu diesem Thema,
aber keine Beschreibung der Verfahren.
Könnt ihr hier bitte weiter helfen? - Danke!
Viele Grüße
Sven
Symmetrisch verschlüsselt, Key im Bootloader/Updater.
Ist sicher, solange der nicht ausgelesen werden kann (also die Lock-Bits
halten).
Und wenn die Lock-Bits übergangen werden können, dann kann man die
Firmware auch direkt & unverschlüsselt aus dem Flash auslesen.
http://www.atmel.com/images/doc2589.pdfhttp://www.atmel.com/images/doc2541.pdf
Sven K. schrieb:> wie funktionieren eigentlich verschlüsselte FW-Updates?
Unterschiedlich.
Es gibt welche, bei denen dieselbe Datei bei allen Geräten funktioniert,
die ist logischerweise immer gleich verschlüsselt und alle Geräte
enthalten dieselbe Entschlüsselungsroutine. Das dient eher der
obfurscation des Inhalts, oder der signierung.
Dann gibt es welche, bei denen die Datei nur bei einem Endgerät passt,
jedes also einen eigenen Entschlüsselungsschlüssel hst.
Und dann gibt es die, wo selbst beim gleichen update erst das Endgerät
einen Schlüssel sendet, mit dem dann die Datei verschlüsselt wird, bei
jedem attempt also ein anderer.
Und es gäbe die Methode, bei der ein Endgerät die Daten annimmt, aber
erst entschlüsseln kann wenn ein Schlüssel (bezahlt?) eingegeben oder
sonstwie nachträglich übermittelt wird.
Bis auf den letzten Fall ist das Endgerät in der Lage, die Daten zu
entschlüsseln, enthält also im bootloader den Entschlüsselungsschlüssel.
Ja ist am einfachsten und wird von vielen Controllern in Hardware
unterstützt.
Wenn du noch eine Datei nur für einen Controller brauchst kannst du in
dem verschlüsselten file die Seriennummer vom Controller eintragen und
nur dann flashen wenn die aus dem file und Controller übereinstimmt.
Jens
Sven K. schrieb:> Also doch AES Verschlüsselung mit einem festen Schlüssel
Kommt darauf an. Wenn du so generell fragst: Es geht auch mit
Quantenkryptographie. Sobald die Hardware dazu auf dem Markt ist.
Hier im Forum geht's viel um die Atmel/Microchip AVR µC's. für diese
gibt es (oben verlinkt) eine Application Note, die AES vorschlägt.
Es gibt aber auch eine Application Note, die 3DES vorschlägt.
und wenn du außerhalb der Application-Notes vom Hersteller suchst,
findest du vermutlich auch noch zig andere, auch asymmetrische,
Verschlüsselungsverfahren.
Wenn du dich dann nicht nur auf den AVR beschränkst, sondern auf µC
(oder embedded) allgemein, gibt's nochmal Größenordnungen mehr an
Optionen.
Also: Bezieht sich deine Frage auf eine Hardware im speziellen, oder war
sie nur so allgemein?
Εrnst B. schrieb:> Kommt darauf an. Wenn du so generell fragst: Es geht auch mit> Quantenkryptographie. Sobald die Hardware dazu auf dem Markt ist.
Ja, Quantenkryptographie! - das wäre doch mal was. Und am besten noch
das FW-Update per verschränkte Photonen laden ...
Εrnst B. schrieb:> Also: Bezieht sich deine Frage auf eine Hardware im speziellen, oder war> sie nur so allgemein?
Also sowohl, als auch.
Habe ihr einen STM32. Der hat AES und (3)DES als HW-Engine.
Aber nur, weil der Controller AES in HW kann heißt es ja nicht, dass es
die bevorzugte und/oder beste Methode ist.
Ja, einfach paar Photonen verschränken...
Eins davon mit dem Gerät ausliefern...
Und eins davon selbst behalten... aber gut beschriften, damit diese dann
nicht verwechselt werden.
Dann stehet ein Update mit fast Lichtgeschwindigkeit nichts mehr im Weg.
Und belastet außerdem keine Datennetze...
Gute neue Welt!
Sowas kommt bestimmt in einer der nächsten Folgen der neuen
MacGyver-Serie. - Dann wissen wir, wie man sowas selbst mit einer
Taschenlampe einem Spiegel und natürlich einem Schweizer Taschenmesser
selber bauen kann. :-P
So ... Scherz beiseite und zurück zum Thema: Erstmal danke für eure
Antworten.
Werde mir mal die Artikel durchlesen, die ihr gepostet habt.
Falls noch Fragen sind, werde ich mich sicherlich melden.
Oder falls ich Fortschritte in der Quantenkryptographie geschafft habe.
Aber dann lest ihr es eher in der Nature oder seht mich bei der
kommenden Nobelpreisverleihung.
höhenflugbeendet
Moin
3DES ist glaube ich überholt, da es als unsicher gilt.
Bei Asymetrischer verschlüsselung wird eigentlich immer nur der
Transportschlüssel damit verschlüsselt, da Asymetrisch immer
rechenintensiver ist als symetrisch.
Das ganze (Transportkey + FW) noch durch eine Signatur sichern. Sollte
der Transoportkey doch rauskommen, ist es extrem schwer bis unmöglich
nur durch modifikation der FW die signatur gleich zu lassen.
Weiter hält das gerät bei RSA nur den öffentlichen schlüssel bzw seinen
öffentlichen. Den Privaten schön geheim halten. denn mitells des
privaten schlüssel lässt sich der öffentliche wieder berechnen.
Verschlüsseln/Entschlüsseln mit dem privaten schlüssel ist
rechenintensiver als mit dem öffentlichen. Hat was damit zu tun wie bei
RSA rechenzeit optimiert wird (factor 3 beim Privaten und beim
öffentlichen noch mehr, ist halt nicht zu verachten)
ggf kann man sich auch anhand von signaturen/verschlüsselung auch
überlegen, ob man den Transportkey für das device separat überträgt und
das device nur verifiziert ob dieser aus einer vertrauenswürdigen quelle
stammt.
Ganz einfach: Du schickst verschlüsselte Daten an das Gerät, das Gerät
entschlüsselt diese und aktualisiert sich.
Dazu muss das Endgerät die Firmware entschlüsseln können, also muss es
entweder einen passenden Schlüssel beinhalten oder vom Benutzer
einfordern können. Es muss auch nicht der gleiche Schlüssel sein, weder
pro Gerät, noch pro Update.
Du kannst auch zweimal verschlüsseln, einmal symmetrisch das
Gesamtpaket, und dessen Schlüssel dann asymmetrisch. Damit kannst du den
Schlüssel auch nachträglich ändern (bzw. vom Updater generieren lassen),
ohne das Gesamtpaket neu verschlüsseln zu müssen.
Allgemein:
Kryptographie löst keine Probleme.
Kryptographie wandelt Probleme in Schlüsselaustauschprobleme um.
AES-decrypt auf nem Stm32 in Software haben wir schon erfolgreich in
Assembler implementiert.
Natürlich mit Cbc.
Xor und decrypt-roundkeys liegen im Flash und wie Jens schon schrieb ist
Jtag deaktiviert im Bootloader.
Kostet mit Can rund 4 - 8 kByte.
So ein Block von 1024 Bytes sind in unter 2 ms entschlüsselt.
Die Aes-Hardware im Stm32 sind nämlich nur in den größeren Typen.
Der Cortex-M3 hat dafür aber n paar interessante Bitmanipulationsbefehle
von Haus aus.
