Hallo zusammen, eine Frage zum STM32. Welche Möglichkeiten habe ich, um meinen Programmcode gegen unerlaubtes Kopieren zu schützen. Ich möchte verhindern, dass 1:1 Kopien meiner Leiterplatten entstehen. Als Basiskopierschutz ist im Moment ein Freischaltcode in einem Bereich des Flash vorgesehen, der einmalig im Rahmen der Produktion geschrieben wird. Updates uns ausgelieferte Hex-Files schreiben diesen Bereich nicht erneut, überprüfen aber die Gültigkeit der dort vorliegenden Daten. Kann ich verhindern, dass mein Flashbereich mit den Freischaltcode ausgelesen wird? Welche anderen Methoden gibt es den Code zu schützen? vielen Dank für eure Hilfe, Jedi
Ja das geht, das Flash lässt sich gegen Auslesen schützen. Guck in das Manual vom STM32. Jeder STM32 hat auch einen einmalige Identifikationsnummer die das Programm Auslesen könnte und deine Stelle im Flash müsste dann während der Produktion passend daszu geschrieben werden. Wäre ein anderer Ansatz.
Mit dem Unique device ID register: - Man nehme das Unique device ID register - verknuddele die 96 Bits ein wenig - brenne die in das Flash, ab besten reserviert man sich dazu ein paar Bytes nach der Vector Tabelle, die mit 0xFFFFFFFF initialisiert wird. Nun startet Dein Programm und deknuddelt die Bits und vergleicht die mit dem Unique device ID register. Dann kann man zwar wunderschön das Flash 1:1 kopieren, das Programm wird dennoch nicht tun. Der STM32 hat auch ein paar OTP Programmierbare Bytes, dann könnte man die Freischaltung dauerhaft in den Chip brennen, das auch bei SW-Update erhalten bleiben würde.
Vielen Dank zunächst, für die zahlreichen Tips. Die read protection scheint als Basisschutz ganz sinnvoll. Weiterhin könnte ich mir ebenso vorstellen, die Device ID über AES zu verschlüsseln, und auf dem Core wieder zu entschlüsseln, um in Abhängigkeit davon bestimmte Bits zu setzen. Jetzt kommt die große Frage zum SW-Update. Ich nutze derzeit den Onboard-DFU-Bootloader um das Device über die USB-Schnittstelle zu updaten. Dabei liefere ich natürlich ein fast vollständiges HEX-File aus. Wenn bekannt ist, dass der Code in dem Hex-File in einem Flashbereich nach einem Freischaltbit sucht, wie hoch ist denn dann der Aufwand um das HEX-File um entsprechenden Code zu erweitern, der dann die entsprechenden Bits im Flash enthält? Oder die Adresse umbiegt auf eine bekannte Speicherstelle. Oder oder oder...? Gibt es noch anderen Methoden um den Betrieb meines Code auf anderen MCU zu verhindern? Gruß, Jedi
Hallo Markus, bzgl. Verschlüsselung über die UID - keine Fragen. Nur wird am Ende zwangsläufig eine Abfrage stattfinden, ob das Device gesperrt, oder entsperrt ist. Und jetzt geht es darum, diese Abfrage möglichst geschützt stattfinden zu lassen. Wie ich gerade gelernt habe, kann ich trotz Read-out-protection weiterhin lesend und schreibend im RAM unterwegs sein via JTAG. Das macht es natürlich nicht besonders schwer das entscheidende Bit zu setzen, oder?
Jedi82 schrieb: > Wie ich gerade gelernt habe, kann ich trotz Read-out-protection > > weiterhin lesend und schreibend im RAM unterwegs sein via JTAG. Das > > macht es natürlich nicht besonders schwer das entscheidende Bit zu > > setzen, oder? soweit ich weiß wird JTAG/SWD deaktiviert sobald ROP aktiv ist. Wenn man nun z.B. aus dem SRAM ROP deaktiviert um z.B. über JTAG auf den Flash zuzugreifen wird ein mass erase durchgeführt, welcher dein Programm komplett löscht.. ROP sollte also meiner Meinung nach einen guten Basisschutz liefern.. Aber wenn man will kann man sicher durch Hardware hacking o.ä. den Flash auslesen, nur kostet das viel Geld und Zeit..
Wenn man sich eine Routine bastelt, die da Unique Device ID Register mit dem Code verknuddelt/vergleicht was im OTP-ROM drin steht, dann wird das Programm auch nur dann funktionieren. Wenn man natürlich das HEX-File hackt, und diese Routine überspringt, dann bringt dies auch nichts, da hilft nur die ROP. Wenn man sicher sein will, dass die HEX-Datei nur auf dem einen Prozessor läuft, dann am besten beides machen. Man könnte in den OTP-ROM auch eine kleine Funktion einprogrammieren, die wiederum den AD-Wandler aus liest, dann würde das auch wieder ein Schutz mehr sein.
Ich finde leider keinen Hinweis auf OTP-Register beim STM32F107VC... na toll!
Ach so, ein 107er. Im Eingangspost steht davon nichts. Im 2xxer oder 4xxer gibt es so etwas. Im 10xer muss man sich mit dem FLASH_OBR Register begnügen und hat 16Bit die man frei programmieren (codieren) kann. Ich bin mir jetzt aber nicht sicher ob die bei einem Full Chiperase auch mit gelöscht werden. Musst Du lesen im Flash Programming Manual.
das bringt alles nicht viel, unsere Steuerungen wurden in Asien 1:1 kopiert, einer unserer Kunden hat sich (als wir mal nicht liefern konnten) über einen Händler was dazubestellt und hat uns freundlicherweise ein paar dieser kopierten Geräte zur Verfügung gestellt. Die Hacker waren sogar so dreist, dass selbst unser PC Tool welches wir zum Konfigurieren usw. zur Verfügung stellen geknackt haben und z.b. unser Logo durch ein anderes ersetzt haben (das Bitmap in einem Visual Studio Programm ist wohl einfach zu ersetzen). Das Gerät trug allerdings nicht unser Logo, sondern war Baugleich mit einem anderen Logo versehen. Wir haben viele "Tricks" angewendet um unseren Code zu schützen, u.a. die bereits erwähnten, dann viele Abfragen, CRC's, Kompressionen und Verschlüsselung von Konfigurationsdaten mit AES - Das hilft alles nix, selbst mit der höchsten Compiler-Stufe ist es denen wohl leicht gelungen die FW zu reverse-engineeren. Die Verschlüsselung liess sich einfach knacken, da der verwendete Key im Flash gespeichert war, und dieser musste offengelegt sein. Wir haben inzwischen zwei Lösungsansätze: - Zum einen verwenden wir eine CryptoMemory von Atmel, ein 3-Pin Bauteil mit ca. 4K EEPROM welches unauslesbar ist. Dort sind die AES-Keys gespeichert. Einen Hash generieren wir aus einem bestimmten AES Key und der CHIP ID des Micro (Xmega). Teile des Flashs sind damit verschlüsselt, aber nicht mit dem AES Key sondern mit dem zur Laufzeit generierten Hash. Der Hash wird mit einer Liste aus vordefinierten Hash's im Speicher vergliechen, wenn sie korrekt sind macht das Programm was, ansonsten läuft es mit nicht optimalen Parametern. Bisher läuft dieses Prinzip schon über ein Jahr und von diesen Geräten ist noch keine Kopie aufgetaucht. So ein kleiner Chip kostet nur ca. 25Cent extra und hilft gegen einer 1:1 Kopie (derjenige der das Gerät kopieren möchte, müsste einen erheblicheren Aufwand betreiben als es zuvor möglich war, zusätzlich hilft die Unique ID im ATSHA204 da es nicht möglich ist einen zweiten Chip mit derselben ID zu bekommen). Dieses Prinzip verwenden wir für die "günstigere" Variante unserer Geräte. - Die teureren Geräte sind gleich mit einem SecureMicro (ähnlich derer man auch in Smartcards finden kann), auch von Atmel, ausgestattet (wobei diese nicht in Einzelmengen verfügbar sind). Das sind vollwertige ARM7 Controller mit Peripherien wie USARTs usw., und auch vor physikalischen Attacken wie overclocking, overvoltage/undervoltage, microprobing usw. geschützt. Wir haben Atmel ausgewählt, weil sie auch normale MIttelstands-Produktionsmengen (ca. 20-50k) beliefern, ST und die anderen wollten von uns mindestens eine halbe Million(!) Stück pro Jahr Abnahmemenge und waren nichtmal günstiger. Bisher sind weder von der günstigeren Lösung noch von der teureren Lösung Kopien aufgetaucht, wobei bei der ersteren nur eine Frage der Zeit ist.
@Stefan: sehr interessanter Bericht! Bitte mehr :-) Ihr habt also nur mit verschlüsseltem Boot-Loader gearbeitet? Ich überlege gerade, ob man die Software nicht wirklich fest an den Controller binden kann, indem man über das gesamte Programm verstreut Berechnungen mit eben dieser UID durchführt. Damit müsste das Programm doch unkopierbar sein, oder? Aber es muss natürlich an unzähligen Stellen auf die UID zugegriffen werden. Chris D.
Wenn ich das so höre macht es fast keinen Sinn sich über Schutz Gedanken zu machen. Da muss man eher Fallen im Code einbauen... Ausfälle nach wenigen Stunden Betriebszeit generieren usw... Schlechte Parameter sind natürlich auch eine nette Variante. Ein sehr interessanter Einblick! Vielen Dank!
Hi Chris,
in der 2. Variante gibt es einen SecureBootloader. Atmel liefert einen
Standardbootloader aus, dieser kann dann während der Produktion einmalig
durch einen eigenen ersetzt werden. In diesem Bootloader findet dann die
Abfrage des ATSHA204 statt.
in der 1. Variante kann man das eigentlich keinen Bootloader nennen.
- Jedes Gerät hat im Micro die UID + einen ATSHA204 mit einem eigenen
unique AES key.
- Während der Programmierung führen wir folgende Schritte durch:
- Auslesen der Xmega Chip UID
- Programmierung von zufällig ausgewähltem Key in den ATSHA204
- Die Xmega Chip UID wird als Challenge an den ATSHA204 geschickt
und mit dem ausgewählten Key zusammen (also UID + Key + UID SHA204)
ein Hash gebildet
- Mit diesem Hash verschlüsseln wir unsere Tabelle und legen die
Firmware
incl. der verschlüsselten Tabelle in den Flash des Xmega
Damit ist das Gerät "personalisiert", den richtigen Hash zum
Entschlüsseln der Tabelle kann man nur dann bekommen, wenn die richtige
Chip UID und der entsprechende ATSHA204 vorliegt. Jedes Gerät ist
zusätzlich mit einem anderen Hash verschlüsselt. Wir haben im Gerät eine
weitere Abfrage ob die dann entschlüsselte Tabelle einen Sinn ergibt
(sprich der Speicherbereich welcher von der Tabelle belegt wird, wird
mit einem vorher berechneten CRC vergliechen. Wenn dieser übereinstimmt,
dann hat die Entschlüsselung geklappt. Wenn nicht, legen wir den Pointer
auf eine Backup-Tabelle hin. Diese Backup-Tabelle enthält
Konfigurationseinstellung, die zwar das Gerät nicht beschädigen, aber es
läuft sub-optimal. Kauft ein Kunde solche Kopie, wird er damit nicht
glücklich und wir können es Dank der Chip ID identifizieren ob es sich
um eine Eigenproduktion handelt oder Kopie.
Wir führen (so wie es mit der UID möglich wäre) einige hundert Abfragen
des ATSHA204 geschickt verstreut im Code durch (da wo es nicht
Echtzeit-Relevant ist).
Natürlich ist es so dass wenn derjenige der das Gerät kopieren möchte,
nur einen guten Entwickler anheuern muß der die Stellen entsprechend
findet und den Code "re-engineert" - aber es scheint so dass alles was
nicht einfach 1:1 kopiert werden kann für die Asiaten zuviel Aufwand
sei.
Na da braucht man doch "einfach nur" Deine Backup-Tabelle mit den Werten der verschlüsselten zu überschreiben und schon hat man alles was man will...
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.