Seminar Heads auf dem NitroPad: Architektur, Vertrauenskette und Boot-Prozess

Heads erweitert die Firmware um eine überprüfbare Startumgebung. Dabei werden Firmwarezustand, Bootdateien, TPM-Messungen und kryptografische Bestätigungen zu einer Vertrauenskette verbunden.

Das Seminar erklärt die Architektur und übersetzt Meldungen des Heads-Menüs in konkrete Prüf- und Betriebsentscheidungen, ohne Warnungen vorschnell zu bestätigen.

Inhaltsübersicht

1. Einordnung und Zielsetzung
2. Zielgruppe und Voraussetzungen
3. Lernziele
4. Seminarinhalte
5. Praxisübungen
6. Methodik

Einordnung und Zielsetzung

Heads erweitert die Firmware um eine überprüfbare Startumgebung. Dabei werden Firmwarezustand, Bootdateien, TPM-Messungen und kryptografische Bestätigungen zu einer Vertrauenskette verbunden. Das Seminar erklärt die Architektur und übersetzt Meldungen des Heads-Menüs in konkrete Prüf- und Betriebsentscheidungen, ohne Warnungen vorschnell zu bestätigen.

Zielgruppe und Voraussetzungen

Zielgruppe: Linux-Administration, IT-Sicherheitsbetrieb, Systemarchitektur, Incident Response und technische Revision.

Voraussetzungen: Linux-Grundkenntnisse, Verständnis von Hashwerten und digitalen Signaturen sowie sicherer Umgang mit einem NitroPad.

Lernziele

• Aufgaben von coreboot und Heads sauber trennen.
• Measured Boot, TPM-PCRs und Bootdatei-Signaturen einordnen.
• Nitrokey und GPG-Karte in der Heads-Vertrauenskette verstehen.
• Normale Änderungen von sicherheitsrelevanten Warnungen unterscheiden.
• Einen kontrollierten Standard-Boot und eine Baseline einrichten.

Seminarinhalte

1. Bedrohungsmodell und Komponenten

Heads wird aus dem Schutz gegen Firmware- und Bootmanipulationen hergeleitet.

1. Schritt 1: Zu schützende Komponenten zwischen Firmware, Bootpartition und Kernel bestimmen.
2. Schritt 2: Angriffe bei unbeaufsichtigtem Gerätezugriff als Szenarien modellieren.
3. Schritt 3: coreboot, Heads, TPM, Nitrokey und Betriebssystem ihren Rollen zuordnen.
4. Schritt 4: Grenzen der Erkennung und verbleibende Vertrauensannahmen dokumentieren.

2. Measured Boot und TPM

Messungen werden von einer Verifikation unterschieden und PCR-Werte werden als Verlauf verstanden.

1. Schritt 1: Messkette vom Firmwarestart bis zu ausgewählten Bootkomponenten nachzeichnen.
2. Schritt 2: PCR-Bindung und Änderungseffekte anhand vorbereiteter Beispiele analysieren.
3. Schritt 3: TPM-Zustand, Eigentümerschaft und Wiederbereitstellung voneinander abgrenzen.
4. Schritt 4: Messwerte in einen dokumentierten Sollzustand überführen.

3. GPG-Signaturen und Nitrokey

Heads nutzt kryptografische Signaturen für autorisierte Änderungen an Bootdateien.

1. Schritt 1: Kompatible Nitrokey-Funktion und benötigte GPG-Anwendung feststellen.
2. Schritt 2: Benutzer- und Administrator-PIN sowie deren Aufgaben trennen.
3. Schritt 3: Bootdateien nach einer legitimen Änderung prüfen und kontrolliert signieren.
4. Schritt 4: Verlust, Sperrung oder Austausch des Nitrokeys in das Notfallmodell aufnehmen.

4. Boot-Menü und Warnungsbewertung

Heads-Meldungen werden in einen festen Entscheidungsprozess eingebettet.

1. Schritt 1: Standard-Boot, alternatives Boot-Menü und Recovery-Konsole unterscheiden.
2. Schritt 2: Hash-Mismatch, geänderten Booteintrag und Firmwarewarnung getrennt bewerten.
3. Schritt 3: Vor Bestätigung Ursache, Zeitpunkt und Änderungsauftrag prüfen.
4. Schritt 4: Nur nachvollziehbare Änderungen signieren und unbekannte Abweichungen eskalieren.

5. Baseline und Routinebetrieb

Ein wiederholbarer Start- und Änderungsprozess reduziert Fehlbestätigungen.

1. Schritt 1: Standard-Boot auf den freigegebenen Kernel setzen.
2. Schritt 2: Ausgangszustand von Firmware, Bootdateien, Nitrokey und TPM dokumentieren.
3. Schritt 3: Regelablauf für Systemupdates und anschließende Signierung festlegen.
4. Schritt 4: Prüfpunkte für Reise, Rückkehr und ungewöhnliche Startmeldungen definieren.

Praxisübungen

• Geführte Analyse eines Heads-Startablaufs.
• Kontrollierter Boot-Hash-Mismatch mit Freigabeentscheidung.
• Aufbau einer Betriebscheckliste für Standard-Boot und Systemupdates.

Methodik

Architekturblöcke werden mit Menüsimulationen und kontrollierten Zustandsänderungen verknüpft. Jede Bestätigung im Heads-Menü wird an eine vorher definierte Prüffrage gebunden.