Hi Weiss jemand ob ST Stellung genommen hat zu diesem Problem? Das ist ja eigentlich schon Tödlich, weil jeder die Firmware auslesen kann Es ist noch nicht mal klar ob nur STMF1 oder alle STM32 betroffen sind! https://www.aisec.fraunhofer.de/en/FirmwareProtection.html
H. R. schrieb: > Es ist noch nicht mal klar ob nur STMF1 Wo findest Du den? In den Papers ist nur vom F0, speziell STM32F051R8T6, die Rede.
> Wo findest Du den? > In den Papers ist nur vom F0, speziell STM32F051R8T6, die Rede. Schreibfehler, meinte F0. Interessant, dieser Artikel über den Hack ist vor 7 Monaten veröffentlicht worden, und es gibt immer noch kein Statement von ST!
Der erste Angriff lässt sich mit RDP Level 2 wohl vermeiden. Der zweite Angriff ist mit dem Offenlegen des DIEs verbunden, auch schon etwas aufwändiger (aber natürlich mit entsprechender Energie machbar). Der dritte (noninvasive) Angriff dürfte wohl der interessanteste sein, und betrifft nach meinem Verständnis auch RDP level 2? Das ist schon krass...
Sehr interessantes Paper. RDP level 1 kann man sich ja beim F0 schon fast schenken. Würde mich mal interessieren, ob von der dritten Attacke auch Cortex-M0 von anderen Herstellern betroffen sind und wenn ja, welche Revisionen. SWD ist ja schließlich ein Teil des Kerns und die Frage wäre ob die Race-Condition nur von STs Flashanbindung ausgeht oder ob das von ARM quasi per IP an alle geliefert wurde. Markus M. schrieb: > Der dritte (noninvasive) Angriff dürfte wohl der interessanteste sein, > und betrifft nach meinem Verständnis auch RDP level 2? Das ist schon > krass... Ne, man braucht für den dritten Angriff SWD-Zugriff, funktioniert also nur mit RDP level 1. Gegen RDP level 2 hilft laut Paper nur der invasive Eingriff.
Die Option-Bytes für den RDP level werden ja ziemlich am Anfang nach dem release des Low Power-Resets ausgelesen. Was man da jetzt mal probieren könnte, wäre einen Powerglitching zu machen, also dem µC erst genug Spannung geben so daß er startet und dann mit genau kontrolliertem Timing kurz die Spannung reduzieren. Wenn man das richtige Timing raus hat, kann es sein daß er wegen der zu niedrigen Spannung das Bit falsch ausliest, aber noch nicht wieder in den Low-Power-Reset geht. Die STM32...8-er ICs dürften dafür am empfänglichsten sein, denn dort kommt man direkt an die 1,8V-Versorgung des Cores ran. Bei den anderen ist ja intern zwischen Vcc und dem Core immer noch ein LDO-Regler vorgeschaltet.
Franz schrieb: > Was ist ein RDP Level? www.st.com/resource/en/application_note/dm00075930.pdf Hier ist unter Punkt 1.1 eine Tabelle, welche die RDP-Level erläutert. > Und wieso hat ein STM32 einen? Gegenfrage: Wieso sollte er keinen Schutz gegen auslesen haben?
>www.st.com/resource/en/application_note/dm00075930.pdf Ah, jetzt wird's klarer In der Wikipedia firmiert RDP unter Remote DeskTop https://en.wikipedia.org/wiki/Network_Level_Authentication Bei ST unter Global Read Out Protection (RDP). Jeder nutzt die Abkürzung, wie's ihm passt.
Lo, der Firmware-Extraktor basiert auf dem selben Boardtyp :-D
Franz schrieb: > Was ist ein RDP Level? Und wieso hat ein STM32 einen? Wieso fragst du, warum etwas existiert, wenn du nicht weißt, was es ist?
Gerd E. schrieb: > Was man da jetzt mal probieren könnte, wäre einen Powerglitching zu > machen, also dem µC erst genug Spannung geben so daß er startet und dann > mit genau kontrolliertem Timing kurz die Spannung reduzieren. Ich denke gegen Powerglitching sollte die Brownout-Protection helfen, schließlich ist die genau dafür da und Spannung lässt sich eben auch relativ gut durch externe Komponenten (außerhalb des Cores) kontrollieren. Grundsätzlich finde ich die Idee aber gar nicht schlecht. Clock Glitching fällt leider (oder zum Glück ;)) auch heraus, weil die Cortex-M grundsätzlich mit internem Takt starten.
Christopher J. schrieb: > Ich denke gegen Powerglitching sollte die Brownout-Protection helfen, soweit die Theorie aus dem Datenblatt. Aber wie man an dem verlinkten Paper sieht, hat die zumindest an anderen Stellen auch ihre Grenzen... > schließlich ist die genau dafür da und Spannung lässt sich eben auch > relativ gut durch externe Komponenten (außerhalb des Cores) > kontrollieren. Komparatoren etc. haben aber auch eine Reaktionszeit. Und dicke Kondensatoren zum Stützen für längere Zeit sind auf Silizium nicht realistisch. > Clock Glitching fällt leider (oder zum Glück ;)) auch heraus, weil die > Cortex-M grundsätzlich mit internem Takt starten. klar.
Hallo zusammen, ich bin einer der Autoren des obigen Papers. Ich kann gerne ein paar Fragen zum Thema beantworten! H. R. schrieb: > Weiss jemand ob ST Stellung genommen hat zu diesem Problem? In den öffentlich verfügbaren Erratas habe ich bisher nichts dergleichen gesehen. Auch ansonsten ist mir persönlich dazu nichts bekannt. Horst schrieb: > H. R. schrieb: >> Es ist noch nicht mal klar ob nur STMF1 > > Wo findest Du den? > In den Papers ist nur vom F0, speziell STM32F051R8T6, die Rede. Ja, es handelt sich nur um den STM32F0, wir haben ein paar Controller dieser Serie getestet und diese waren anfällig dafür. Auf den STM32F1 kann der Angriff nicht angewendet werden. Markus M. schrieb: > Der erste Angriff lässt sich mit RDP Level 2 wohl vermeiden. Ja! > Der zweite Angriff ist mit dem Offenlegen des DIEs verbunden, auch schon > etwas aufwändiger (aber natürlich mit entsprechender Energie machbar). Chips lassen sich im technischen Umfeld relativ einfach öffnen, wenn die entsprechenden Chemikalien vorhanden sind. Ansonsten gibt es für so etwas auch Dienstleister. > Der dritte (noninvasive) Angriff dürfte wohl der interessanteste sein, > und betrifft nach meinem Verständnis auch RDP level 2? Das ist schon > krass... Die Schwachstelle lässt sich erst mal nur im RDP Level 1 ausnutzen, in RDP Level 2 ist die SWD-Schnittstelle deaktiviert. Da man aber nur ein einziges Bit der RDP-Bytes im Flash kippen muss, erreicht man durchaus einen Fallback von Level 2 auf Level 1. (=Kombination des zweiten und dritten Angriffs). Gerd E. schrieb: > Was man da jetzt mal probieren könnte, wäre einen Powerglitching zu > machen [...] Nur zu! Mir hat dazu leider bisher die Zeit gefehlt, mich genauer damit zu beschäftigen. Würde mich aber nicht wundern, wenn sie beispielsweise die Settings mehrmals auslesen und vergleichen. Dann könnte es mit einem einzelnen Glitch schwierig sein. Ich hatte mir mal überlegt, während des Hochstartens des Chips die Stromaufnahme zu beobachten (Oszi + kleiner Shunt + ggf. Verstärker). Damit könnte man abschätzen ob der Glitch intern einen Effekt ausgelöst hat. Es ist leider sehr schwierig Feedback aus dem Chip zu bekommen...
Johannes O. schrieb: >> Was man da jetzt mal probieren könnte, wäre einen Powerglitching zu >> machen [...] > Nur zu! Mir hat dazu leider bisher die Zeit gefehlt, mich genauer damit > zu beschäftigen. Würde mich aber nicht wundern, wenn sie beispielsweise > die Settings mehrmals auslesen und vergleichen. Dann könnte es mit einem > einzelnen Glitch schwierig sein. Das würde aber voraussetzen, daß die sich dieser Gefahr bewusst sind und sie versuchen, kostenneutrale Gegenmaßnahmen umzusetzen. Da bin ich mir nicht sicher ob dieses Bewusstsein tatsächlich da ist. Denn dann hätten sie es vermutlich mit der Redundanz der Option-Flags auch anders gelöst so daß man den RDP 2 nicht nur mit einem einzelnen gekippten Bit wieder loswird. Gibt es eigentlich in RDP 1 einen Weg die CPU-Register zu verändern ohne daß das Flash gelockt wird? Dann könnte man vielleicht in den integrierten Bootloader springen an eine Stelle nach dessen Prüfung des RDP levels...
H. R. schrieb: > Interessant, dieser Artikel über den Hack ist vor 7 Monaten > veröffentlicht worden, und es gibt immer noch kein Statement von ST! Laut Post vom 9. Januar https://community.st.com/thread/46432-hacking-readout-protection-on-stm32 Arbeitet ST an einem Statement. Philipp
Gerd E. schrieb: > Was man da jetzt mal probieren könnte, wäre einen Powerglitching zu > machen, also dem µC erst genug Spannung geben so daß er startet und dann > mit genau kontrolliertem Timing kurz die Spannung reduzieren. Wenn man > das richtige Timing raus hat, kann es sein daß er wegen der zu niedrigen > Spannung das Bit falsch ausliest, aber noch nicht wieder in den > Low-Power-Reset geht. Der Thread ist zwar schon älter, aber genau das haben die wallet.fail-Leute zum Hacken der Hardware-Wallet Trezor ausgenutzt. Sie haben RDP2 auf RDP1 gedowngradet und konnten so im Update-Prozess der Wallet den privaten Schlüssel auslesen, weil der im RAM gebackupt wurde. https://youtu.be/Y1OBIGslgGM?t=2397 Die haben dann auch hübsche Platinen für ihren PoC gebaut, damit man nur noch den STM32 in einen Test-Sockel einlegen muss und der private Schlüssel wird vollautomatisch extrahiert.
:
Bearbeitet durch User
Philipp Klaus K. schrieb: > Laut Post vom 9. Januar > > Arbeitet ST an einem Statement. Weiß vielleicht einer der anwesenden Forumskollegen, ob diese Arbeit - nach mittlerweile beinahe einem Jahr - erfolgreich beendet wurde?
@Mampf F: Am Ende haben die Jungs doch aber "nur"* den RAM auslesen können wenn ich das richtig gesehen habe? An den Key kamen die dann ran, weil er während eines FW Updates in den RAM geschrieben wurde <insert facepalm here>. Hätten vom Trezor die letzte Flashpage für statische Daten genutzt so wärs doch immernoch sicher gewesen? *auch das ist eine großartige Leistung
Mw E. schrieb: > @Mampf F: > Am Ende haben die Jungs doch aber "nur"* den RAM auslesen können wenn > ich das richtig gesehen habe? Ja genau - immerhin konnten sie den Debugger nutzen, der mit RDP2 vollständig deaktiviert ist. > An den Key kamen die dann ran, weil er während eines FW Updates in den > RAM geschrieben wurde <insert facepalm here>. > Hätten vom Trezor die letzte Flashpage für statische Daten genutzt so > wärs doch immernoch sicher gewesen? Stimmt, den Flash konnten sie ja immer noch nicht auslesen. Vlt ändern sie das ja mal. > *auch das ist eine großartige Leistung Absolut! Letztens hatte ich mich noch mit jemandem über die RDP-Level unterhalten und wäre der Meinung gewesen, dass das sicher genug ist. So kann man sich täuschen. Seltsam, dass man da so wenig Informationen findet - das Geschrei hätte eigentlich groß sein müssen.
Der Glitchangriff funzt ja nur wenn man sich auf die Configbytes verlässt und dann gabs auch "nur" ein Downgrade auf RDP1, der Debugger durfte daher ja in den RAM gucken. Aber es lässt sich der RDP Level nochmal in Software setzen bevor diese was wichtiges tut. Sollte man vllt unbedingt tun wenn man ein Trezor baut ;) Das Problem ist die Codierung der Optionbytes: 0xAA: Level 0, no protection 0xCC: Level 2, chip protection (debug and boot from RAM features disabled) Others: Level 1, read protection of memories (debug features limited) Wenn "Others" -> Level 2 wäre, dann wär alles gut. Sobald auch nur ein Bit flippt ist RDP L1 aktiv. Also STM32 immer so proggen als wär man nur im RDP L1 :/
Mampf F. schrieb: > Seltsam, dass man da so wenig Informationen findet - das Geschrei hätte > eigentlich groß sein müssen. Ich denke jeder, der sich ein bischen tiefer mit dem Thema beschäftigt, weiß, daß man reguläre µCs mit überschaubarem Aufwand auslesen kann. Was ich so gehört hab, gibt es in China einige Hinterhof-Adressen, die sowas regelmäßig als Dienstleistung anbieten. Vermutlich tüfteln die für die gängigen Controllertypen eine Weile, und finden dann Glitching- oder ähnliche Angriffe. Die andere Variante ist mit Elektronenmikroskop und Ionenstrahl anzugreifen, so ähnlich wie z.B. hier beschrieben: http://siliconexposed.blogspot.com/2014/03/getting-my-feet-wet-with-invasive_31.html Spezielle Security-Mikrocontroller sollen Schutzmaßnahmen gegen diese Angriffe haben. Die konkret verwendeten Schutzmaßnahmen werden allerdings eigentlich so gut wie immer geheim gehalten. Viele von diesen Security-Mikrocontrollern sind auch nicht frei erhältlich oder öffentlich dokumentiert. Das erschwert natürlich auch die Security-Forschung an ihnen.
mIstA schrieb: > Philipp Klaus K. schrieb: >> Laut Post vom 9. Januar >> >> Arbeitet ST an einem Statement. > > Weiß vielleicht einer der anwesenden Forumskollegen, ob diese Arbeit > - nach mittlerweile beinahe einem Jahr - erfolgreich beendet wurde? Es gab Forumsposts von einem ST-Mitarbeiter (MANI Christophe_O) im damaligen ST-Forum. Seither wurde die Forumssoftware gewechselt,der Thread wurde ins neue Forum portiert, aber dass MANI Christophe_O für ST arbeitet(e) ist nun nicht mehr ohne weiteres erkennbar (in der neuen Software steht nur "(Community Member)" wie bei den gewöhnlichen Postern hinter dem Namen, wo in der alten Software das blaue ST-Symbol war (auch wenn manche andere ST-Mitarbeiter nun ein "(ST Employee)" haben): https://community.st.com/s/question/0D50X00009Xke7aSAB/readout-protection-cracked-on-stm32 Philipp
Offenbar hat der STM32F1 auch eine Lücke, siehe Beitrag "STM32F1: Sicherheit der Firmware Protection" ThoLausen
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.