Figure 4.4: Security features

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichtenbasiertes Architektur- und Funktionsclustermodell (Blockdiagramm) der AUTOSAR Adaptive Platform (AP, Release R23-11) mit orthogonaler Hervorhebung („Security Features Overlay“).
• Technischer Zweck: Systematische Zuordnung aller funktionalen Security-Mechanismen und Schutzklauseln zu den standardisierten Functional Clusters (FCs) der AUTOSAR Runtime for Adaptive Applications (ARA) sowie Abgrenzung gegenüber User Application und Base Software (POSIX OS).
• Funktionale Einordnung: Definiert die Defense-in-Depth-Architektur der Adaptive Platform: Sichere Ausführungsumgebung, kryptografische Basisservices, sichere Kommunikation (netzwerk- und bordnetzweit), Absicherung des Software-Lebenszyklus (Update/Rollback) sowie Angriffsfrüherkennung (IDS).

2. Komponenten, Entitäten & Schnittstellen

1. Schichten-Hierarchie (Top-Down)

• User Application Layer: Beherbergt adaptive Anwendungen (Application), gekapselt als eigenständige POSIX-Betriebssystemprozesse.
• AUTOSAR Runtime for Adaptive Applications (ARA): Laufzeitumgebung, bestehend aus C++-APIs (ara::*) und plattforminternen Dämonen/Diensten.
  • POSIX PSE51 / C++ STL OS Interface: Schmale, definierte Betriebssystemschnittstelle (beschränkt auf POSIX PSE51 Profile und C++ Standardbibliothek).
• Base Software Layer: Zugrunde liegendes Standard-POSIX-kompatibles Betriebssystem (POSIX OS) inklusive Kernel, Treiber und Hardware-Abstraction.

2. Dekomposition der Functional Clusters (FCs) & Security-Features

Die Cluster unterteilen sich in vier Domänen, wobei die sicherheitsrelevanten Teilfunktionalitäten als blaue Sub-Blöcke ausgewiesen sind:

1. Platform Foundation Functional Clusters (FCs):
   • Communication Management (ara::com): Implementiert Transportsicherheit über fahrzeuginterne und externe Protokolle: SecOC (PDU-Level), TLS (Socket-Level), IPsec (Netzwerk-Level), MACsec (Link-Level).
   • Execution Management (ara::exec): Gewährleistet die Trusted Platform (Authentizitätsprüfung von Binaries/Manifesten, Messung der Boot-Kette, Prozessintegrität).
   • Diagnostic Management (ara::diag): Bietet SecurityAccess (ISO 14229-1 Seed-&-Key) und standardisierte UDS-basierte Authentication (ISO 14229-1 / ISO 13400-2 DoIP).
   • Intrusion Detection System Manager (ara::idsm): Fungiert als lokale Sensor-Schnittstelle und Filterinstanz für Sicherheitsereignisse (IDS / Security Event Reporting gemäß AUTOSAR IdsM).
   • Persistency (ara::per): Stellt Secure Storage bereit (transparente Verschlüsselung, Vertraulichkeit und Manipulationsschutz/Authentizität gespeicherter Key-Value-Daten und Files).
   • Time Synchronization (ara::tsync): Erzwingt Secure Time (authentifizierte Zeitübertragung via IEEE 802.1AS / IEEE 1588 / StbM gegen Replay- und Spoofing-Angriffe).
   • Cryptography (ara::crypto): Schnittstelle zur Krypto-Hardware (HSM/SHE/TPM); übernimmt Zertifikats- und Schlüsselverwaltung (Certificate and key management) sowie Zugriff auf Krypto-Primitive (Signaturen, AEAD, Random Number Generation).
   • Log and Trace (ara::log): Bietet Authenticated Logging (integritätsgeschützte Audit-Logs und Rückverfolgbarkeit von Sicherheitsereignissen).
   • Firewall (ara::fw): Netzwerk- und Paketfilter (Zustands- und Regelfilterung für Ethernet/IP-Traffic).
   • Weitere Foundation FCs ohne dediziertes Security-Overlay: ara::nm (Network Management), ara::rds (Raw Data Stream), ara::phm (Platform Health Management), ara::core (Basistypen/Fehlerbehandlung).
2. Platform Service FCs:
   • Update and Config Management (ara::ucm): Realisiert Secure Update (Validierung der Signatur von Softwarepaketen, Integritäts- und Authentizitätsprüfung, strikter Down-grade Protection über Monotonic Counter).
   • Weitere Platform Services: ara::sm (State Management / Process State Control).
3. Standardized Application / Interface FCs:
   • ara::adi::sensoritf service (Sensor Interfaces) sowie erweiterbare anwendungsspezifische Schnittstellen.
4. Vehicle Service FCs:
   • Vehicle Update and Config Management (VUCM): Fahrzeuggroße Flotten- und ECU-übergreifende Orchestrierung von Secure Update (Authentizität, Vertraulichkeit und Rollback-Schutz auf Gesamtfahrzeugebene).
   • Automotive API Gateway (ara::aag): Standardisierte Schnittstelle zur Fahrzeug- und Cloud-Kommunikation (ohne dediziertes Security-Overlay ausgewiesen).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Schichten- und Bausteindiagramm handelt, manifestiert sich das dynamische Verhalten in den operativen Schnittstellenpfaden zwischen den Clustern:

[Netzwerk / Peripherie]
         │
         ▼
    [Firewall (ara::fw)]  ───(Paketfilter / Drop)
         │ (Valide Pakete)
         ▼
[Communication Management] ◄───(Key / MAC-Verify)───► [ara::crypto]
         │                                                  │
         ├─────────────────────────────────────────┐        │ (Zertifikatsvalidierung)
         ▼                                         ▼        ▼
[Diagnostic Mgmt (Auth/SecAccess)]      [Update Mgmt (ara::ucm)]
         │                                         │
         ▼ (Sicherheitsvorfall / Verletzung)       ▼ (Down-Grade Check & Deploy)
[Intrusion Detection (ara::idsm)]       [Execution Mgmt (ara::exec)]
         │                                         │ (Prozessstart / Verifikation)
         ▼ (QoS-gefilterter Upload)                ▼
   [Onboard / Offboard SIEM]               [Adaptive Application]

1. Bootstrapping & Trust Anchor:
   • Beim Plattformstart verifiziert ara::exec die Signaturen und Prüfsummen der Executables gegen den von ara::crypto bzw. dem POSIX OS/HSM bereitgestellten Hardware-Trust-Anchor, bevor Applikationsprozesse gestartet werden.
2. Ingress Security & Session Establishment:
   • Eintreffende Ethernet-Frames passieren zuerst die Regeln von ara::fw.
   • ara::com delegiert TLS/IPsec/SecOC-Prüfungen asynchron an ara::crypto, um Session Keys abzuleiten und MACs/Signaturen zu verifizieren.
3. Incident Detection & Reporting:
   • Bei sicherheitsrelevanten Anomalien (z. B. fehlgeschlagene SecOC-Prüfung in ara::com, fehlerhafter SecurityAccess in ara::diag, unautorisierter Prozessaufruf) triggern die FCs synchrone Security-Event-Meldungen an ara::idsm.
   • ara::idsm aggregiert, filtert und überträgt diese Events an standardisierte interne Puffer oder fahrzeugweite IDS-Reporter.
4. Update-Transaktion:
   • Pakete erreichen ara::ucm (oder via VUCM). ara::ucm nutzt ara::crypto zur Authentizitätsprüfung der Manifeste, prüft die Versionsnummern gegen Persistenz-Zähler (ara::per), um Downgrades zu sperren, und signalisiert nach erfolgreicher Signaturprüfung den Update-Zustand an ara::sm.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung von Krypto-Material (ara::crypto): Applikationsentwickler dürfen niemals private Schlüssel im Speicher halten. Alle kryptografischen Operationen erfolgen über Handles (CryptoContext, KeySlot, CryptoProvider). Der Zugriff auf Schlüssel ist strikt an Manifest-Rechte (Execution Manifest, Manifest Deployment) gebunden.
• Persistenzabsicherung (ara::per): Vertrauliche Anwendungsdaten müssen in den Deployment-Deskriptoren mit Attributen für Authentizität und Verschlüsselung deklariert werden. ara::per kapselt den Aufruf von ara::crypto transparent für den Anwendungsentwickler; Plaintext-Storage sensibler Parameter ist normativ unzulässig.
• Instrumentierung für Intrusion Detection (ara::idsm): Applikationen mit erhöhtem Sicherheitsrisiko müssen als IDS Security Sensor modelliert werden. Erkannte Protokollbrüche oder ungültige Payloads müssen aktiv per ara::idsm::ReportSecurityEvent() gemeldet werden.
• Manifest-Konfiguration & Packaging: Jede Auslieferung einer Adaptive Application erfordert kryptografisch signierte Softwarepakete für UCM/VUCM. Fehlt die Manifest-Signatur oder verletzt das Deployment das Downgrade-Versionskriterium, lehnt ara::ucm die Installation deterministisch ab.
• Netzwerk-Isolation: Die Koexistenz von ara::fw und ara::com bedeutet, dass Ports und Protokolle nicht nur auf Service-Ebene (ara::com-Deployment), sondern auch in den Plattform-Firewall-Regelsätzen konsistent modelliert werden müssen, um Kommunikations-Timeouts durch Kernel-/Paket-Drops zu verhindern.