Figure 7.17: Authenticated start-up sequence

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Ablauf- und Schichtenübergangsdiagramm (High-Level Start-up Flowchart) zur Spezifikation der Chain of Trust (Secure / Authenticated Boot Pipeline) gemäß AUTOSAR Adaptive Platform (AP).
• Technischer Zweck & funktionale Einordnung: Modellierung des lückenlosen, kryptografisch verifizierten Hochlaufsystems vom Hardware-Reset bis zur Ausführung von User-Space-Prozessen. Das Diagramm visualisiert die Realisierung von RS_EM_00014 (Authenticity and Integrity of Executables/Manifests) und RS_EM_00015 (Secure Startup) innerhalb des Execution Management (EM) Clusters.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten der Vertrauenskette:
  • Trust Anchor: Hardware-basierte Root of Trust (RoT; z. B. Hardware Security Module / HSM, Secure Boot ROM mit eFuse-verankerten öffentlichen Schlüsseln).
  • Bootloader: Primärer/Sekundärer Bootloader (FSBL/SSBL, U-Boot, Bootmanager) zur Hardware-Initialisierung.
  • OS: POSIX-konformes Betriebssystem (Kernel-Space und Initial-Userspace, z. B. QNX Neutrino, Linux, Integrity).
  • Execution Management: Zentraler Core-Cluster der AUTOSAR AP Foundation; fungiert als Prozess-Manager und Security Enforcement Point für den Anwendungs-Userspace.
  • Processed Manifests / Execution Manifest: Serialisierte, vorverarbeitete Konfigurationsartefakte («AR:ExecutionManifest»), welche Prozesskonfigurationen, Ressourcengrenzen, Function Groups sowie StartupConfig und StartupDependency definieren.
  • Adaptive Platform Foundation Modules: Basisdienste der AP (z. B. State Management, Communication Management, Crypto, Diagnostic Management), die architektonisch als reguläre Applikationen modelliert sind.
  • Application Executables / processes: Kompilierte ELF-Binärdateien und deren zur Laufzeit erzeugte OS-Prozessinstanzen («AR:Process»).
• Beziehungen & Modellierung:
  • Gerichtete 1:1-Übergaben: Jede Schicht authentifiziert und startet deterministisch die nachfolgende Entität.
  • 1:n-Beziehung zwischen Application Executable und Process: Ein Executable kann über mehrere Manifest-Einträge in mehreren Prozessen instanziiert werden.
  • Foundation-Module unterliegen identischen Manifest- und Verifikationsmechanismen wie kundenspezifische Applikationen.

3. Dynamisches Verhalten & Sequenzablauf

Die Authenticated-Start-up-Sequenz erfolgt in fünf sequenziellen Stufen ohne asynchrone Verzweigungen:

1. Stufe 1 (Trust Anchor → Bootloader):
   • Der Trust Anchor prüft Signatur/Hash des Bootloaders gegen fest verdrahtete/gebrannte Schlüssel (OTP).
   • Bei Erfolg: Sprung zur Bootloader-Ausführung.
2. Stufe 2 (Bootloader → OS):
   • Der Bootloader validiert OS-Kernel, Device Tree und ggf. Root-FS (z. B. FIT-Image-Signatur, dm-verity).
   • Übergabe der Kontrolle an den OS-Kernel.
3. Stufe 3 (OS → Execution Management):
   • Das OS authentifiziert das EM-Binary (z. B. via IMA – Integrity Measurement Architecture oder OS-eigene Signature-Checks) und startet EM als prioritären Initialprozess.
4. Stufe 4 (Manifest-Verifikation & Dependency Resolution):
   • EM verifiziert Integrität und Authentizität der Processed Manifests.
   • EM parst Abhängigkeitsstrukturen (StartupDependency) und ermittelt die topologische Startreihenfolge für Foundation- und User-Applikationen unter Berücksichtigung des aktiven MachineState bzw. der FunctionGroupStates.
5. Stufe 5 (Executable-Verifikation & Prozess-Instanziierung, SWS_EM_02305):
   • Vor jedem Prozessstart (fork/posix_spawn) authentifiziert EM das zugehörige Application Executable (Signatur/Prüfsumme).
   • Nach erfolgreicher Validierung erfolgt die Instanziierung der Prozesse entlang der berechneten Startreihenfolge.

• Abbruchbedingungen & Fehlerbehandlung:
  • Jede fehlschlagende Authentifizierung bricht die Chain of Trust hart ab.
  • Gemäß SWS_EM_02305: Schlägt die Prüfung von Manifest oder Binary fehl, darf EM den betroffenen Prozess nicht starten; es erfolgt eine Fehlermeldung an das Logging/Tracing-Subsystem bzw. ein Security-Event an das State Management.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsanforderungen (Toolchain & Manifest-Deployment):
  • Für alle Binaries (Foundation und User-Apps) sowie Execution Manifests müssen im Build- und Packaging-Prozess kryptografische Signaturen generiert und in den jeweiligen Deployable-Containern bereitgestellt werden.
  • Abhängigkeiten zwischen Modulen müssen im Execution Manifest zyklenfrei (StartupDependency) definiert sein, um Deadlocks beim sequenziellen Hochlauf zu verhindern.
• Laufzeit- und Echtzeiteinfluss (Boot-Time Budgeting):
  • Die kryptografische Verifikation aller Executables und Manifeste vor der Ausführung verlängert die Time-to-Operation signifikant.
  • Entwickler müssen hardwarebeschleunigte Kryptografie (Crypto Stack / ara::crypto bzw. OS-Crypto-Treiber) einbinden oder Authentifizierungsmechanismen wie Page-Hash-Verifikation (z. B. dm-verity) auf OS-Ebene nutzen.
• Architektureinschränkung:
  • Dynamisches Nachladen unzertifizierter/unsignierter Binaries oder Skripte zur Laufzeit ist normativ ausgeschlossen. Foundation-Module genießen keine Sonderrechte und müssen vollständig über Manifeste deklariert sein.