mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 Leseschutz gecracked (readout protection)


Autor: H. R. (hacker_r)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: H. R. (hacker_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Markus M. (adrock)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Franz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist ein RDP Level? Und wieso hat ein STM32 einen?

Autor: Kuno (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Franz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Alex W. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lo,

der Firmware-Extraktor basiert auf dem selben Boardtyp :-D

Autor: A.. P. (arnonym)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes O. (jojo_2)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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...

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Youtube-Video "35C3 -  wallet.fail"

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
Autor: mIstA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :/

Autor: Gerd E. (robberknight)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.