Seminar SEGGER emSecure-Boot – ROM-Integration und Root of Trust

Das Seminar richtet sich an Plattform- und Siliziumteams, die emSecure-Boot als unveränderlichen Vertrauensanker in Boot-ROM oder vergleichbar geschützten Speicher integrieren. Die Dauer von drei Tagen ist erforderlich, weil ROM-Design, OTP-Provisionierung, Bootprüfung, exponierte API und Hardwarevalidierung gemeinsam entworfen und getestet werden müssen.

Inhaltsübersicht

• Lernziele und fachliche Einordnung
• Schrittweise Seminarinhalte
• Praxisübungen und Laborszenarien
• Zielgruppe und Voraussetzungen
• Didaktik und Arbeitsweise

Lernziele

• Boot-ROM, OTP, RAM und optionale UID als Root-of-Trust-Ressourcen planen.
• Kunden-, Firmware- und Hardwareauthentisierung in eine Bootarchitektur integrieren.
• Eine sichere, minimale API für Firmwarefunktionen definieren.
• Unveränderliche ROM-Anteile und aktualisierbare Software sauber abgrenzen.
• Pre-Silicon- und Post-Silicon-Validierung mit Manipulationsfällen aufbauen.

Schrittweise Seminarinhalte

1. Silicon- und Plattform-Zielbild

Schwerpunkt: MCU oder SoC, Bootquellen, ROM, OTP, UID, Debug, Lifecycle-States, Kundenmodell, Fertigung und Feldbetrieb.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Silicon- und Plattform-Zielbild“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von MCU oder SoC, Bootquellen, ROM, OTP, UID, Debug, Lifecycle-States, Kundenmodell, Fertigung und Feldbetrieb modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis ein vollständiges Root-of-Trust-Zielbild dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

2. ROM-, RAM- und OTP-Ressourcen

Schwerpunkt: minimaler Codeumfang, Arbeits-RAM, Schlüsselmaterial, OTP-Bits, UID, Startlatenz, Wiederverwendung des RAM und Hardwaregrenzen.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „ROM-, RAM- und OTP-Ressourcen“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von minimaler Codeumfang, Arbeits-RAM, Schlüsselmaterial, OTP-Bits, UID, Startlatenz, Wiederverwendung des RAM und Hardwaregrenzen modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis ein freigegebenes Ressourcen- und Speicherbudget dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

3. Boot-ROM-Kontrollfluss

Schwerpunkt: Reset, Bootmodus, Kundenidentität, Firmwarequelle, Signaturprüfung, API-Bereitstellung, Fehlerzustand und Übergabe.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Boot-ROM-Kontrollfluss“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von Reset, Bootmodus, Kundenidentität, Firmwarequelle, Signaturprüfung, API-Bereitstellung, Fehlerzustand und Übergabe modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis eine deterministische ROM-Startzustandsmaschine dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

4. Kundenauthentisierung und Provisionierung

Schwerpunkt: Chipkunde, Kundenschlüssel, OTP-Programmierung, Lifecycle-Zustand, Erstinbetriebnahme, Sperren, Mehrkundenfähigkeit und Fehlprovisionierung.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Kundenauthentisierung und Provisionierung“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von Chipkunde, Kundenschlüssel, OTP-Programmierung, Lifecycle-Zustand, Erstinbetriebnahme, Sperren, Mehrkundenfähigkeit und Fehlprovisionierung modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis einen sicheren Customer-Onboarding- und Provisionierungsprozess dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

5. Firmwareauthentisierung im ROM

Schwerpunkt: öffentlicher Schlüssel, Firmwarebereich, Signaturformat, Hash, Startadresse, Manipulation, Timing und sichere Ablehnung.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Firmwareauthentisierung im ROM“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von öffentlicher Schlüssel, Firmwarebereich, Signaturformat, Hash, Startadresse, Manipulation, Timing und sichere Ablehnung modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis einen vollständigen ROM-basierten Verified-Boot-Pfad dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

6. Exponierte Sicherheits-API

Schwerpunkt: Verifikationsfunktionen, Hardwareauthentisierung, Parameterprüfung, Zugriffsmodell, Reentranz, Fehlercodes, Seiteneffekte und Missbrauchsschutz.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Exponierte Sicherheits-API“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von Verifikationsfunktionen, Hardwareauthentisierung, Parameterprüfung, Zugriffsmodell, Reentranz, Fehlercodes, Seiteneffekte und Missbrauchsschutz modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis eine minimale und belastbare ROM-API-Spezifikation dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

7. Hardwareauthentisierung und Anti-Cloning

Schwerpunkt: UID, Gerätedaten, Signatur, OTP, Firmwareprüfung, Produktionsintegration, Bauteilwechsel und Fehlerreaktion.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Hardwareauthentisierung und Anti-Cloning“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von UID, Gerätedaten, Signatur, OTP, Firmwareprüfung, Produktionsintegration, Bauteilwechsel und Fehlerreaktion modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis einen ROM-gestützten Anti-Cloning-Referenzablauf dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

8. Unveränderbarkeit, Updates und Schlüsselwechsel

Schwerpunkt: ROM-Fixierung, Patches, nachgelagerter Bootloader, öffentliche Schlüssel, Übergangsschlüssel, Widerruf und Produktlebensdauer.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Unveränderbarkeit, Updates und Schlüsselwechsel“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von ROM-Fixierung, Patches, nachgelagerter Bootloader, öffentliche Schlüssel, Übergangsschlüssel, Widerruf und Produktlebensdauer modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis eine langfristige Wartungs- und Schlüsselstrategie dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

9. Pre-Silicon- und Post-Silicon-Validierung

Schwerpunkt: Simulation, FPGA-Prototyp, Test-ROM, OTP-Emulation, Manipulation, Glitch- und Resetfälle, Debug-Sperren und Serienfreigabe.

1. Ausgangslage, Schutzbedarf und Zielkriterien für den Themenblock „Pre-Silicon- und Post-Silicon-Validierung“ erfassen.
2. Relevante Komponenten, Daten, Rollen und Abhängigkeiten anhand von Simulation, FPGA-Prototyp, Test-ROM, OTP-Emulation, Manipulation, Glitch- und Resetfälle, Debug-Sperren und Serienfreigabe modellieren.
3. Die erforderliche Konfiguration, Implementierung oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Sicherheitsgrenzen, Fehlerverhalten und Nachvollziehbarkeit mit definierten Positiv-, Negativ- und Manipulationsfällen prüfen.
5. Als Arbeitsergebnis einen vollständigen Silicon-Security-Validierungsplan dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

Praxisübungen und Laborszenarien

• Entwurf eines Boot-ROM- und OTP-Layouts für eine Beispiel-SoC-Architektur.
• Modellierung der Kundenprovisionierung und der ROM-Startzustandsmaschine.
• Spezifikation einer minimalen Sicherheits-API mit Negativfällen.
• Aufbau eines Pre-Silicon-Testplans für Firmware- und Hardwareauthentisierung.
• Durchspielen einer Fehlprovisionierung und eines Schlüsselwechsel-Szenarios.

Zielgruppe und Voraussetzungen

Zielgruppe: Silicon-Vendoren, MCU- und SoC-Architektur, Boot-ROM-Entwicklung, Hardware-Security, Embedded-Platform-Teams und Pre-Silicon-Validierung.

Voraussetzungen: Sehr gute Kenntnisse in MCU- oder SoC-Architekturen, Boot-ROM, OTP, Embedded C, Hardware-Lifecycle und digitaler Signaturprüfung.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Architekturarbeit, Demonstrationen, strukturierte Implementierungsschritte, praktische Übungen und kontrollierte Fehlerfälle vertieft. Jede Übung verwendet definierte Ausgangswerte, Prüfpunkte, Negativfälle und Dokumentationsanforderungen, damit die erarbeiteten Abläufe als Entwicklungs-, Produktions- oder Betriebsstandard wiederholbar bleiben.