14.3.4. Ein Hinweis zum Schutz vor dem Auslesen des Flash¶

Im Auslieferungszustand ist die Firmware einer ausgelieferten OpenMV Cam für jeden mit physischem Zugriff auf das Gerät lesbar. Ein Angreifer mit der Kamera in der Hand kann eine SWD-Sonde an den Debug-Header anschließen, mit der Debug-Schnittstelle des MCU kommunizieren und den Flash auslesen – was jedes eingefrorene Python-Modul und den Inhalt der ROMFS-Partition umfasst. Die ab Werk gelieferte OpenMV-Firmware aktiviert den Schutz vor dem Auslesen des Flash standardmäßig nicht.

Diese Seite dokumentiert das ausdrücklich, damit ein Team, das ein Produkt ausliefert, weiß, wo die Verantwortung liegt.

14.3.4.1. Was die Kamera standardmäßig tut¶

Der Bootloader und die Laufzeitumgebung der Kamera aktivieren keinerlei Auslesschutzfunktion des zugrunde liegenden MCU. Die Debug-Schnittstelle bleibt offen, der Flash bleibt lesbar, und der Build läuft so, wie er auf dem Entwicklungsrechner eines Entwicklers läuft. Das ist die richtige Voreinstellung für die Zielgruppe des Tutorials – eine Kamera, die mit aktiviertem Auslesschutz ausgeliefert wird, ist eine Kamera, die nicht über die IDE neu geflasht werden kann, die nach einem misslungenen Deployment nicht neu bespielt werden kann und die von niemandem außer dem Build-Team gerettet werden kann.

Der Kompromiss ändert sich, wenn die Kamera vom „Entwicklergerät“ zum „Produkt“ wird. Ein Produkt, dessen Wert davon abhängt, dass der Anwendungscode privat bleibt, muss den Schutz selbst aktivieren; die OpenMV-Firmware tut das nicht.

14.3.4.2. Was das Produktteam tut¶

Jeder MCU-Hersteller bietet einen Mechanismus zum Schutz vor dem Auslesen. Die Details unterscheiden sich – Fuses auf Bit-Ebene, einmalige Lebenszyklus-Übergänge, signierte Flash-Images – aber die gemeinsame Form ist:

Ein herstellerspezifisches Bit (oder eine Reihe von Bits) wird in das Silizium festgeschrieben, üblicherweise über ein Hersteller-Tool, das ein letztes Mal mit dem Debug-Port des MCU kommuniziert.
Nach dem Festschreiben verweigert der Debug-Port das Lesen des Flash. Die Kamera bootet und führt die Anwendung weiterhin aus; sie legt ihre Inhalte lediglich nicht mehr gegenüber einer Sonde offen.
Das Festschreiben ist unumkehrbar. Es gibt keine Möglichkeit, die Kamera in einen debugfähigen Zustand zurückzuversetzen, ohne sie zu zerstören.

Die Einrichtung ist MCU-spezifisch, und die Schritte hängen von dem zu schützenden Bauteil auf der Kamera ab. Das Referenzhandbuch des Herstellers ist die maßgebliche Quelle; der Herstellersupport ist der Kanal, um es auf einer Fertigungslinie richtig zu machen.

Das ist der einfache Teil.

Der schwierige Teil besteht darin, jeden anderen Weg zu schließen, auf dem ein Angreifer Code auf der Kamera ausführen oder lesen kann, was die Anwendung tut. Der Auslesschutz verhindert nur, dass eine Debug-Sonde den Flash auslesen kann. Die Kamera muss außerdem schließen:

Die MicroPython-REPL. Eine über USB angeschlossene REPL nimmt beliebiges Python an. Der Auslesschutz ändert daran nichts. Eine REPL-Sitzung kann RAM lesen, Funktionen aufrufen und alles exfiltrieren, was die laufende Anwendung sehen kann – de facto umgeht eine erreichbare REPL alles, was der Auslesschutz einbringt. Das Deaktivieren des REPL-Zugriffs ist eine Änderung am Firmware-Build, die in der Verantwortung des Produktteams liegt.
Das Hochladen von Skripten über die IDE. Der „Dieses Skript auf der Kamera ausführen“-Pfad der IDE nutzt dieselbe USB-Protokolloberfläche wie die REPL. Das Schließen der REPL schließt dies mit; lässt man eines von beiden offen, bleibt ein Kanal zur Ausführung beliebigen Codes in die Kamera hinein offen.
Übernahme des Einstiegspunkts aus dem Dateisystem. Bereits geschlossen, wenn die Anwendung über Skripte in die Firmware einfrieren ausgeliefert wird – die Laufzeitumgebung löst eingefrorene boot.py und main.py vor jeder Dateisystemkopie auf, sodass nichts, was auf den Flash oder die SD-Karte gelegt wird, sie überschreiben kann. Dieser Schutz ist kostenlos, sobald die Anwendung im Build enthalten ist.
Externer Flash auf neueren Kameras. Kameras, die das Anwendungs-Image in externem Flash speichern, legen dieses Image auf einem Chip ab, der gut sichtbar auf der Platine sitzt; der Chip kann ausgelötet und direkt mit handelsüblichen Werkzeugen ausgelesen werden, oder durch Abgreifen des Busses an Ort und Stelle ausgelesen werden. Um ihn zu schützen, muss die On-Chip-Hardware aktiviert werden, die den Flash-Inhalt beim Lesen entschlüsselt, der Verschlüsselungsschlüssel muss erzeugt, dieser Schlüssel auf der Kamera bereitgestellt und unumkehrbar in den einmalig programmierbaren Speicher des MCU eingebrannt werden. Jeder dieser Schritte ist eine eigene einmalige Operation, und jeder einzelne davon, falsch an einer Produktionseinheit ausgeführt, macht diese Einheit unbrauchbar.

Jeder Punkt auf dieser Liste ist ein eigener Stapel aus Firmware-Build-Arbeit, Fertigungslinien-Schritten und unumkehrbaren Festschreibungen. Ein wirklich abgeschottetes Produkt ist ein angepasster Firmware-Build, ein angepasster Bootloader, ein Fertigungsablauf, der pro Einheit Schlüssel bereitstellt, und ein Satz von Tests, die belegen, dass die Sperre tatsächlich geschlossen ist, bevor die Einheit die Linie verlässt. Das ist eine Arbeit von Monaten, nicht von Tagen, und die Unumkehrbarkeit bedeutet, dass Fehler Einheiten kosten.

Warum die Voreinstellung offen ist

Diese Liste ist auch der Grund, warum die ab Werk gelieferte OpenMV-Firmware ohne aktivierten Auslesschutz ausgeliefert wird. Eine Kamera mit geschlossener REPL, deaktiviertem IDE-Skript-Upload und gesperrter Firmware ist eine Kamera, auf der überhaupt nicht entwickelt werden kann – der Arbeitsablauf, der OpenMV-Kameras überhaupt erst nutzbar macht, wäre dann einfach weg. Die Voreinstellung lässt alles offen; das Produktteam entscheidet, welche Teile es auf dem Weg zu einer ausgelieferten Einheit schließt.

14.3.4.3. Was physischer Zugriff trotzdem einbringt¶

Selbst bei aktiviertem Auslesschutz kann ein Angreifer, der die Kamera in Händen hält, einiges tun:

Den Netzwerkverkehr der Kamera durch Mitschneiden ihrer Ausgaben wiedergeben.
Ihr sichtbares Verhalten beobachten und daraus ableiten, wie sie auf Eingaben reagiert.
In manchen Fällen Geheimnisse durch Fehlerinjektions- oder Seitenkanalangriffe wiederherstellen, die speziell gegen den geschützten MCU gerichtet sind.

Der Auslesschutz erhöht die Kosten, um an den Quellcode der Anwendung zu gelangen. Er beseitigt die Kosten nicht. „Physischer Zugriff = Kompromittierung“ ist die Arbeitsannahme, von der eine Sicherheitsüberprüfung ausgehen sollte; der Schutzmechanismus entscheidet lediglich, wie viel diese Kompromittierung an Zeit und Ausrüstung kostet.

14.3.4.4. Womit die OpenMV-Firmware ausgeliefert wird¶

Eine Zusammenfassung, damit das konkret wird:

Standardmäßig kein Auslesschutz aktiviert.
Kein Build-Flag in der ab Werk gelieferten Firmware, das ihn aktiviert.
Keine API auf Anwendungsebene, die aus MicroPython aufgerufen werden kann.

Ein Produkt, das den Schutz benötigt, liefert angepasste Firmware aus. Diese Anpassung lebt im Bootloader der Platine und im Fertigungsablauf und liegt außerhalb der OpenMV-Codebasis. Teams, die das zum ersten Mal tun, sollten es als eigenständiges Arbeitspaket in den Entwicklungszeitplan einplanen und nicht als etwas, das am Ende hinzugefügt wird – die Unumkehrbarkeit macht „später hinzufügen“ teuer.