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.pdf http://www.atmel.com/images/doc2541.pdf
:
Bearbeitet durch User
Dazu muss wenn vorhanden auch jtag aus sein um den RAM nicht auslesen zu können und gleiche Blöcke sollten verändert werden siehe. https://en.m.wikipedia.org/wiki/Block_cipher_mode_of_operation https://de.m.wikipedia.org/wiki/Electronic_Code_Book_Mode?wprov=sfla1
:
Bearbeitet durch User
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.
Also doch AES Verschlüsselung mit einem festen Schlüssel ... !? :-O
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
Schau mal hier: https://www.segger.com/products/security-iot/emsecure/ Das ist genau das was du suchst.
Tom schrieb: > Schau mal hier: > https://www.segger.com/products/security-iot/emsecure/ > > Das ist genau das was du suchst. Das war das was ich damit gemeint habe: Sven K. schrieb: > Wenn man googelt findet man nur Firmen bzw. Produkte zu diesem Thema, > aber keine Beschreibung der Verfahren. Wibu (http://www.wibu.com) ist auch so was ... Kostet alles aber ein bisschen: https://www.segger.com/purchase/pricing/security-products/ So viel habe ich gerade nicht in der Sparbüchse... Kommt dann, wenn ich die Quantenkryptographie revolutioniert habe. :-D
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.