Hi, Ich habe eine Platine mit uC erstellt, bei welcher die Firmware geschützt werden muss. Nun kann man das bei ein paar hundert Stück gut von Hand mit dem STLink Utility flashen und so die Read-Out protection aktivieren. Wenn ich aber einen Dritten für das flashen anstelle, wie kann ich da meine Firmware schützen? Das .hex darf der Flasher ja nicht unverschlüsselt bekommen und das Flashen muss mit dem jeweiligen Schlüssel passieren. Gibt es da eine Möglichkeit?
Was soll das denn schon wieder für Militärtechnik werden, dass man dem Mitarbeiter nicht das Binary Image von der Firmware in die Hand geben kann? Das verlinkte Produkt hilft auch nur, wenn die Plattform verschlüsseltes Booten (mit Key und Krypto-Modul auf der CPU) unterstützt. Dann könnte man sich vermutlich was basteln, was den genannten Anforderungen genügt.
Bert S. schrieb: > Wenn ich aber einen Dritten für das flashen anstelle, wie > kann ich da meine Firmware schützen? Per NDA mit angemessener Vertragsstrafe, 4-Augen-Prinzip,... Wenn es sooo super geheim ist daß das nicht ausreichen sollte, ist ein normaler Mikrocontroller eh die falsche Wahl. Siehe z.B. Beitrag "STM32 Leseschutz gecracked (readout protection)"
Wenn du nicht selbst flashst musst du irgendjemanden vertrauen. Theoretisch kannst du auch alle Controller mit einem Testsockel flashen und dem Bestücker geben. Dafür eignen sich JEDEC Trays sehr gut. Ansonsten gibt es Dienstleister die sich auf das offline flashen spezialisiert haben.
Bert S. schrieb: > Ich habe eine Platine mit uC erstellt, bei welcher die Firmware > geschützt werden muss. Nun kann man das bei ein paar hundert Stück gut > von Hand mit dem STLink Utility flashen und so die Read-Out protection > aktivieren. Wenn ich aber einen Dritten für das flashen anstelle, wie > kann ich da meine Firmware schützen? Das .hex darf der Flasher ja nicht > unverschlüsselt bekommen und das Flashen muss mit dem jeweiligen > Schlüssel passieren. Gibt es da eine Möglichkeit? Der Flasher muss ja das hex entschlüsseln und im Klartext übers jtag schicken, damit der Prozessor es ausführen kann. An den JTAG-Pins kann ich den Datenstrom mit Leichtigkeit abgreifen. Im Klartext: Nein. Du kannst genauso gut dem Dienstleister das Hex so mitgeben. fchk
Das ist ja einfach: Wenn Firmware soooo furchtbar geheim ist, hat man meistens eh einen eigenen Bootloader gebaut. Den lässt man beim Fertiger flashen. Die eigentliche Firmware wird dann im eigenen Haus nachgeliefert.
Frank K. schrieb: > Der Flasher muss ja das hex entschlüsseln und im Klartext übers jtag > schicken, damit der Prozessor es ausführen kann. An den JTAG-Pins kann > ich den Datenstrom mit Leichtigkeit abgreifen. > > Im Klartext: Nein. Du kannst genauso gut dem Dienstleister das Hex so > mitgeben. Nja nicht notwendigerweise. Große Plattformen wie z.B. der imx7 haben "Encrypted Boot"-Features, mit denen man das (mit hinreichendem Entwicklungsaufwand) vermeiden könnte, wenn man wirklich wollte.
Gerd E. schrieb: > Wenn es sooo super geheim ist daß das nicht ausreichen sollte, ist ein > normaler Mikrocontroller eh die falsche Wahl. Siehe z.B. > Beitrag "STM32 Leseschutz gecracked (readout protection)" Betrifft nur F0 und read out protection level 1 (nicht 2) soweit ich mich erinnere. Ich frag mich grad was für ein Threat Model vor liegt, das wär hier mal die wichtigere Sache, anstatt mit der Implementierung an zu fangen. Hersteller produziert mehr und verkauft den rest selber? Irgendwer will das ding reverse engineeren? Irgendwer flasht eigene firmware (in dem gegebenen szenario nicht inkludiert), das ding verletzt alle safety Bedenken und der Hersteller kann es nicht nachweisen?
Base64 U. schrieb: > Betrifft nur F0 und read out protection level 1 (nicht 2) soweit ich > mich erinnere. Nein, bisher alle STM32.
Dr. Sommer schrieb: > https://www.segger.com/products/production/flasher/models/flasher-secure/ Noch ein Grund nichts von Segger zu verwenden.
Uwe B. schrieb: > Nein, bisher alle STM32. Hast du es mal selber ausprobiert? Bisher habe ich es nur am F0 getestet....mit Erfolg.
James schrieb: > Dr. Sommer schrieb: >> https://www.segger.com/products/production/flasher/models/flasher-secure/ > > Noch ein Grund nichts von Segger zu verwenden. ? John P. schrieb: > Uwe B. schrieb: >> Nein, bisher alle STM32. > > Hast du es mal selber ausprobiert? > > Bisher habe ich es nur am F0 getestet....mit Erfolg. Aus dem Paper vom Fraunhofer: (https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17-paper-obermaier.pdf) > To prevent the attack, the developer has to set the device into the fully-locked > RDP Level 2. This disables the debug interface completely. Without access to the > debug interface and SRAM, the attack becomes infeasible. RDP Level 2 is > supported by most STM32 microcontrollers, except the STM32F1 series. Seh damit also kein Problem, solang man nicht schon Produkte mit dem am Markt hat. Wenn man Updatefähigkeit will kann man sich immer noch einen Bootloader dafür seleber bauen der dann über irgendein Interface das Image entgegen nimmt, in den Flash schreibt, signatur checkt und dann frei gibt.
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.