Hallo,
befasse mich gerade mit "Kopierschutzmassnahmen" bei meinem STM32
Projekt. Die Sache mit der Read Out Protection (ROP) für das Flash
funktioniert auch schon ganz gut, auch wenn ich es komisch finde, dass
sich die Write-Protection der ersten beiden Pages nicht abstellen lässt
und damit ein Bootloader-Update kompliziert wird.
Mit Entsetzen habe ich nun aber festgestellt, dass die ROP nur für das
Flash gültig ist, das RAM aber weiterhin per JTAG lesend/schreibend
angesprochen werden kann.
Ich weiss nicht ob das eine STM32 spezifische Eigenheit ist oder bei
allen ARMs so üblich, aber vom Sicherheitsgedanken ist das nicht
besonders toll.
Wisst Ihr wie man dieses Loch stopfen kann? Bin bisher leider nicht
fündig geworden.
Eine Idee hatte ich, nämlich die JTAG Pins als Alternate Function zu
betreiben, d.h. während der Initialisierung die Pins als Standard IO zu
konfigurieren. Aber gewonnen hab ich dadurch ja leider doch nichts, denn
ein Angreifer kann die Reset Leitung betätigen und das RAM auslesen,
bevor ich die Pins umkonfiguriere. Bei einem Warm-Reset stehen dort ja
noch alle Daten vom letzten Programmlauf.
Jemand eine Idee? Danke!
Sven
Du kannst das JTAG nicht als Alternate-Function schalten um es als JTAG
abzuschalten. Denn das JTAG wird durch eine Reset-Sequenz aktiviert. Zu
diesem Zeitpunkt hat Deine Software noch keine Kontrolle über die Pins.
Erst beim STM32F4 gibt es eine Fuse, die das JTAG abschalten. Soweit ich
weiss, ist das beim STM32F1/2 bislang nicht möglich.
Gruß, Ulrich
Uff, na das wäre ja bescheiden...
Da geb ich mir Mühe mit einer Verschlüsselten Ethernet-Übertragung,
Kryptographie-Schlüssel etc. und am Ende stehen die Daten und Schlüssel
eh für jedermann lesbar im RAM.
Der Controller bietet ja Möglichkeiten, zumindest das Flash zu schützen.
Der Hersteller hat sich also durchaus Gedanken gemacht. Aber wie kann
man so ein Scheunentor offen stehen lassen? Ich staune...
Sven schrieb:> Da geb ich mir Mühe mit einer Verschlüsselten Ethernet-Übertragung,> Kryptographie-Schlüssel etc. und am Ende stehen die Daten und Schlüssel> eh für jedermann lesbar im RAM.
Ist das nicht ein bischen sehr paranoid?
Wer nicht weiß, wo die Variablen stehen und was sie bedeuten, für den
ist das nur ein Gewusel von Nullen und Einsen. Lesbar ist da nichts.
Nimm einen BGA-Typ und lege die JTAG-Anschlüsse fest an VCC.
Peter
Peter Dannegger schrieb:> Wer nicht weiß, wo die Variablen stehen und was sie bedeuten, für den> ist das nur ein Gewusel von Nullen und Einsen. Lesbar ist da nichts.
Kommt ganz drauf an, für was. Soll der Chip irgendwelche
Sicherheitsfunktionen übernehmen, z.B. Tür öffnen durch Code auf
Chipkarte, Passwöter durch Bedienfeld annehmen, ... ist das eine recht
gute Angriffsstelle.
Wir haben in der Ausbildung ein 8051er Board in die Hand bekommen, auf
dem ein kleiner CPLD saß, der die Daten-/Adressbusdekodierung total
durcheinandergewürfelt hat und aus /RD, /WR und /OE rund 20 Signale
durch unbekannte logische Verknüpfungen erstellt hat.
RAM und ROM hatten dann noch ein CPLD dran, das das wieder aufgedröselt
hat.
Unsere Aufgabe war, zwischen den CPLDs mitzuschneiden und das Programm
aus dem ROM dumpen und eine Eingabe einer PS/2 Tastatur im RAM zu
finden.
War kein Hexenwerk, aber recht sinnlos, da man das so wohl in echt nicht
finden wird, aber ging ja nur um das Verständis wie man sowas machen
kann.
Nils S. schrieb:> der die Daten-/Adressbusdekodierung total> durcheinandergewürfelt hat
Na sonderlich kompliziert wirds ja nicht gewesen sein.
Von Maxim gibt es einen MC mit Verschlüsselung, da kannst Du den RAM
ruhig auslesen und kommst trotzdem nicht an Code und Daten ran:
http://www.maxim-ic.com/datasheet/index.mvp/id/2949
Der wurde auch in Geldautomaten eingesetzt.
Peter
Peter Dannegger schrieb:> Na sonderlich kompliziert wirds ja nicht gewesen sein.
Das schwierigste war, stundenlang Zustände von ca. 35 Signalen anzusehen
und dabei konzentriert bleiben ;)
Letzendlich rausgefunden, welche zum RD, WR und OE gehören, diese
Oder-Verknüpfen und alles war getan.
Das war eben nur ein Beispiel, das wir bekamen um zu verstehen, was
möglich ist.
Hat man jetzt einen Controller, dessen RAM sich per JTAG auslesen lässt,
ist das ja noch einfacher.
Aber in diesen Fällen braucht man eben einen anderen Controller.
Nils S. schrieb:> Hat man jetzt einen Controller, dessen RAM sich per JTAG auslesen lässt,> ist das ja noch einfacher.
Nö, da fehlt ja noch der Code dazu.
Peter
Peter Dannegger schrieb:> Nö, da fehlt ja noch der Code dazu.
Achso, jeder Verschlüsselungs-Algorhytmus, der geknackt wurde, wurde
geknackt, weil man die Rohdaten, die verschlüsselten Daten und auch den
Code dazu hatte.
Wenn man weiss, nach was man sucht, findet man das auch. Beispiel
Eingabe von Tastatur mitlesen.
Nils S. schrieb:> Achso, jeder Verschlüsselungs-Algorhytmus, der geknackt wurde, wurde> geknackt, weil man die Rohdaten, die verschlüsselten Daten und auch den> Code dazu hatte.
Es ist ein großer Unterschied, ob Du nur ein zufälliges RAM-Abbild hast,
wo zufällig genau ein Datenbyte drin ist neben vielem anderen unnützen
Zeugs.
Oder ob Du den kompletten dekodierten Datenstrom mitlesen kannst.
Um den Datenstrom zu erhalten, müßtest Du wissen, wo das interessierende
Byte steht und dann Haufenweise RAM-Abbilder einlesen, um kein Byte zu
verpassen.
Wenn Du in das JTAG aber nur über ein Reset reinkommst, kannst Du
garkeine aufeinanderfolgenden RAM-Bilder ziehen.
Peter
Hi!
Ich finde auch, dass das deaktivieren des JTAG per Kommando /
Steuerregister für die meisten Applikationen ausreicht. Und wenn man
Daten hat, die empfindlich sind, muss man sie ja nicht zum Klartext
entschlüsseln und sequenziell im RAM ablegen. Man kann die Daten
beispielweise nur soweit entschlüsseln, wie man sie gerade benötigt oder
man legt sie nach einem Muster im RAM verteilt ab.
Bei Crypto Varianten mit mehrfachen Durchläufen, kann ich ja den letzten
erst machen, wenn ich die Daten brauche, oder ich lege eine zufällige
Maske drüber, die ich aus dem FLASH lade, deren Init-Wert ich mir aus
der CPU internen Temperaturdiode ableite. Damit steht dann im RAM nur
Müll, der Klartext steht nur in einem CPU-Register wenn er gerade
gebraucht wird und das ist bei Reset 0x00.
Selbst wenn der Wert drin stünde, müsste ein Angreifer den exakten
Zeitpunkt bestimmen, wann er dort steht, und dies für alle anderen Werte
wiederholen. Und das nützt ihm eigentlich garnix, denn er weill ja den
Schlüssel und der ist zu diesem Zeitpunkt ja schon weg.
Gruß, Ulrich
