Figure 7.1: AUTOSAR layered view with KEYM.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR-Schichtenmodell (Layered Architectural View) mit Detail-Explosion (Detail Callout) des AUTOSAR Crypto-Stacks.
• Technischer Zweck: Verortung des BSW-Moduls Key Manager (KeyM) innerhalb der Services-Schicht sowie Darstellung der vertikalen und horizontalen Interaktionspfade innerhalb des AUTOSAR-Kryptografie-Stacks von der Applikation bis zur Hardware.
• Funktionale Einordnung:
  • Linker Bereich: Standard-AUTOSAR-Schichtenarchitektur (Microcontroller, MCAL / Drivers, ECU Abstraction, Services, RTE, Application Layer inkl. Complex Drivers).
  • Rechter Bereich: Detaillierte Dekomposition des Crypto-Stacks über alle relevanten BSW-Ebenen hinweg zur Entkopplung von Krypto-Diensten, Key-/Zertifikatsmanagement, Hardwareabstraktion und Hardwarediensten (HSM, SHE, Secure Element via SPI, SW-Fallback).

2. Komponenten, Entitäten & Schnittstellen

• Services Layer (Crypto Services):
  • Key Manager (KeyM): Zentrale BSW-Komponente für Schlüssel- und Zertifikatslebenszyklus-Management. Unterteilt in:
    • Crypto Keys: Bereitstellung, Erneuerung, Ableitung und Import/Export von kryptografischen Schlüsseln (gemäß SWS_KeyM_00001, SWS_KeyM_00002).
    • Certificates: Parsing, Validierung von Zertifikatsketten (X.509 v3), CRL-Verwaltung und Zertifikatsstatusverwaltung.
  • Crypto Service Manager (CSM): Abstraktion standardisierter Krypto-Primitiven (Hashing, Signaturprüfung, Verschlüsselung) für BSW und Applikation; Zielkomponente für Krypto-Operationen des KeyM.
• ECU Abstraction Layer (Crypto Hardware Abstraction):
  • Crypto Interface (CryIf): Zentraler Dispatcher/Router zwischen CSM/KeyM und den zugrunde liegenden Krypto-Treibern (Uniform API).
  • External Crypto Driver: Treiber für externe Hardware-Sicherheitsbausteine (z. B. HSM/TPM/Secure Element via SPI).
  • Crypto Driver (SW-based): Reiner Software-Kryptotreiber für Host-CPU-Ausführung (keine dedizierte HW-Krypto-Engine erforderlich).
• Microcontroller Abstraction Layer (MCAL / Drivers):
  • Crypto Drivers (Crypto): On-Chip-Hardware-Treiber (z. B. MCAL-Crypto-Treiber für integrierte HSM/SHE-Cores).
  • Communication Drivers (SPIHandlerDriver / Spi): Bus-Treiber zur physischen Anbindung externer Krypto-Controller/Peripheriebausteine.
• Hardware Layer (Microcontroller):
  • SHE (Secure Hardware Extension), HSM (Hardware Security Module) als integrierte On-Chip-Sicherheitsmodule.
  • µC (Host-Core) zur Ausführung von Software-Krypto-Algorithmen.
  • SPI-Schnittstelle zur Anbindung externer Krypto-Hardware.
• Beziehungen & Schnittstellen:
  • Vertikaler Dienstfluss: Application Layer / BSW (z. B. SecOC, Dcm) → RTE → KeyM / CSM.
  • Service-zu-Abstraktion: CSM / KeyM nutzen CryIf-Schnittstellen.
  • Hardware-Abstraktionsfluss: CryIf routet Aufrufe entweder direkt an native Crypto Driver (MCAL) oder an den External Crypto Driver (dieser greift über SpiHandlerDriver auf den SPI-Bus zu) oder den SW-based Crypto Driver.

3. Dynamisches Verhalten & Sequenzablauf

• Key- & Zertifikats-Bereitstellung / Update:
  1. Trigger: Diagnoseanforderung (z. B. via Dcm / UDS RoutineControl), BSW-Aufruf (SecOC, TLS) oder Applikation über RTE.
  2. Zertifikatsprüfung / Schlüsselimport: KeyM parst und verifiziert Zertifikate/Schlüsselblöcke unter Nutzung der kryptografischen Primitiven des CSM (z. B. Signaturprüfung gegen hinterlegte Root-Zertifikate).
  3. Routing über CryIf: KeyM delegiert das Schreiben/Provisionieren der Schlüssel über den CSM an das CryIf.
  4. Treiber-Dispatch: CryIf leitet den Request synchron oder asynchron an den konfigurierten Treiberkanal weiter:
     • On-Chip-HSM: Direktaufruf des On-Chip-Crypto Driver.
     • Externes Secure Element: External Crypto Driver transformiert den Aufruf in SPI-Jobs und delegiert an SpiHandlerDriver.
• Asynchrone vs. Synchrone Pfade:
  • Zeitkritische Krypto- und Speicheroperationen (z. B. Flash-/NVM-Schreibvorgänge von Schlüsseln in SHE/HSM) werden in der Regel asynchron initiiert (KeyM_<JobName>Start(), KeyM_MainFunction()).
  • Benachrichtigung über Status und Beendigung erfolgt über standardisierte Callback-Routinen (KeyM_CertificateStatusChangedNotification, KeyM_KeyStatusChangedNotification).
• Fehlerbehandlung:
  • Entwicklungsfehler (z. B. uninitialisierter KeyM, ungültige Key-IDs, Null-Pointer) werden via Det_ReportError (DET) abgefangen.
  • Hardware-/Kryptofehler (z. B. abgelaufene Zertifikate, Prüffehler, HSM-Kommunikationsabbruch) werden über Dem_SetEventStatus (DEM) oder spezifische Rückgabewerte (KEYM_E_VERIFICATION_FAILED, CRYPTO_E_BUSY) signalisiert.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsaspekte (KeyM, CryIf, Crypto):
  • KeyM muss statisch konfigurierte Container für Zertifikate (KeyMCertificate) und Schlüssel (KeyMKey) enthalten, die logischen Kanälen im CryIf und CSM zugeordnet sind.
  • Das Routing von CryIf muss strikt auf die physikalische Ziel-Hardware abgestimmt werden (Channel-to-Driver-Mapping: Zuordnung von CryIfChannelId zu CryptoDriverObject).
• Treiber- und Integrator-Vorgaben:
  • External Crypto Driver: Erfordert zwingend eine kompatible SPI-Konfiguration (SpiChannel, SpiSequence, asynchron/DMA) ohne Blockade anderer sicherheitskritischer BSW-Busse.
  • Crypto Driver (MCAL): Treibermodule müssen die normierten APIs nach SWS Crypto Driver (z. B. Crypto_KeyElementSet, Crypto_KeyValidSet) unterstützen.
• Einschränkungen & API-Vertrag:
  • Schlüsselmaterial verlässt die sichere Domäne nicht im Klartext: Ein Schlüssel-Update in Hardwarespeichern (SHE/HSM) muss direkt über den gesicherten Kanal des Treibers provisioniert werden.
  • KeyM stellt selbst keine kryptografischen Rechenoperationen bereit, sondern nutzt hierfür den CSM (Trennung von Lifecycle-/Zertifikatslogik und Krypto-Execution gemäß SRS_CryptoStack_00007, SRS_CryptoStack_00013).