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.
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.
