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...
Wofür ist denn die verschlüsselte Übertragung? Betreibst Du das mit Linux oder geht so etwas auch ohne Linux?
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
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.