Figure 9.100: Interfaces for security

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Modeling).
• Funktionaler Kontext: Das Diagramm spezifiziert die Interaktion zwischen dem zentralen Diagnostic Management (DM) Functional Cluster (ara::diag, daemon-basiert) und einer Adaptive Application (AA) für sicherheitskritische Diagnosefunktionen gemäß ISO 14229-1 (UDS).
• Architektonischer Zweck: Trennung von protokollarischer Diagnoseabwicklung (UDS/DoIP-Terminierung im Daemon) und applikativer Autorisierungs-, Validierungs- sowie Kryptologielogik im Prozesskontext der Adaptive Application.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application: Applikationsprozess im POSIX User Space der Adaptive Platform, der anwendungsspezifische Diagnose- und Security-Funktionen ausführt.
• «aapFunctionalCluster» Diagnostic Management (Attribut: daemon-based): Zentraler Plattformdienst (Daemon), der als UDS-Server fungiert und eingehende Diagnoseanfragen an die zuständigen Applikationen routet.

Port-Schnittstellen («aapPortInterface,aapAPI» bzw. «aapAPI,aapPortInterface»)

1. SecurityAccess (UDS Service 0x27):
   • + GetSeed(): Anforderung eines kryptografischen Zufallswerts (Seed) von der Applikation.
   • + CompareKey(): Übergabe des vom Diagnosetester empfangenen Schlüssels (Key) zur Verifikation.
   • + Offer() / + StopOffer(): Registrierung bzw. Deregistrierung der Service-Instanz am Diagnose-Daemon.
2. ServiceValidation:
   • + Validate(): Zustands- und Vorbedingungsprüfung vor Ausführung eines Diagnose-Services (z. B. Fahrzeugstillstand, Klemme 15).
   • + Confirmation(): Rückmeldung über Abschluss oder Statusänderung einer Diagnoseanfrage.
   • + Offer() / + StopOffer(): Lebenszyklus-Steuerung der Validierungs-Instanz.
3. Authentication (UDS Service 0x29):
   • + VerifyCertificateUnidirectional(): Einseitige Zertifikatsprüfung (Tester gegenüber ECU).
   • + VerifyCertificateBidirectional(): Gegenseitige Authentifizierung zwischen Tester und ECU.
   • + VerifyOwnership(): Überprüfung des Besitznachweises (Proof of Ownership / Challenge-Response via Private Key).
   • + Offer() / + StopOffer(): Lebenszyklus-Steuerung.
4. TransmitCertificate (UDS Service 0x29 Subfunktionen):
   • + Process(): Verarbeitung und Segmentierungs-Handling eingehender/ausgehender Zertifikatsdaten.
   • + Offer() / + StopOffer(): Lebenszyklus-Steuerung.

Beziehungen & Ports

• Applikationsseite: Die Adaptive Application realisiert die Schnittstellen (UML-Schnittstellenrealisierung: gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze zur jeweiligen Schnittstelle).
• Daemon-Seite (Diagnostic Management):
  • Verwendet SecurityAccess und ServiceValidation über «aapRequiredPort» mit «use»-Abhängigkeit (DM agiert als Client/Aufrufer der Applikationslogik).
  • Verwendet Authentication und TransmitCertificate über «aapProvidedPort» mit «use»-Abhängigkeit (Modellierungszuordnung als bereitgestellter Service-Port im Kontext des Daemons).

3. Dynamisches Verhalten & Sequenzablauf

Lifecycle & Registrierung

1. Service Announcement: Die Applikation initialisiert ihre Diagnose-Handler und ruft Offer() auf. Dies publiziert die Instanz per IPC (z. B. UNIX Domain Sockets/Shared Memory) beim DM-Daemon.
2. Shutdown: Bei Prozessbeendigung oder Degradation wird StopOffer() ausgeführt, woraufhin der DM-Daemon UDS-Anfragen für diesen Service mit NRCs abweist (z. B. 0x31 RequestOutOfRange oder 0x22 ConditionsNotCorrect).

UDS 0x27 SecurityAccess-Ablauf

1. Seed-Request: Tester sendet Subfunktion 0x01 (RequestSeed). DM parst die PDU und ruft asynchron GetSeed() an der Applikation auf.
2. Seed-Response: Applikation generiert den Seed (typischerweise via ara::crypto) und gibt ihn an den DM zurück; DM kapselt ihn in die UDS-Antwort.
3. Key-Verifikation: Tester sendet Subfunktion 0x02 (SendKey). DM ruft CompareKey() auf. Bei Übereinstimmung setzt DM die Sicherheitsstufe aktiv; bei Fehlschlag wird der Fehlversuchszähler (Attempt Counter / Penalty Timer) inkrementiert.

Service-Validierung (Pre-Condition Check)

1. Eingehender UDS-Request triggert Validate(). Die Applikation prüft interne Zustände.
2. Gibt Validate() ein negatives Resultat zurück, antwortet DM unmittelbar mit NRC 0x22 (ConditionsNotCorrect) oder herstellerspezifischen NRCs, ohne den Service auszuführen.
3. Nach erfolgreicher Verarbeitung informiert DM die Applikation via Confirmation().

UDS 0x29 Authentication & Zertifikatsaustausch

1. Tester initiiert Zertifikatsübertragung (TransmitCertificate::Process()), um Certificate Chains in den ECU-Puffer zu laden.
2. Validierung erfolgt über VerifyCertificateUnidirectional() bzw. VerifyCertificateBidirectional().
3. Asymmetrischer Besitznachweis wird über VerifyOwnership() verifiziert, bevor erweiterte Diagnoserechte freigeschaltet werden.

4. Normative Relevanz & Entwickler-Hinweise

• Asynchroner API-Vertrag (ara::core::Future / ara::core::Result): Methoden wie GetSeed(), CompareKey() und VerifyCertificate*() sind nicht-blockierend zu implementieren. Da kryptografische Berechnungen Latenzen erzeugen, muss der DM-Daemon bei Überschreitung des UDS-Timers P2_Server automatisch Response Pending (0x78) an den Tester senden, bis das Future aufgelöst ist.
• ARXML-Modellierung (Manifest):
  • DiagnosticSecurityAccessInterface und DiagnosticServiceValidationInterface müssen im Execution- und Service-Instance-Manifest korrekt an die Port-Prototypen der AA gebunden werden.
  • Zuweisung der Security-Levels (SecurityLevel-Referenzen) und Zuordnung der UDS-Service-IDs zur ServiceValidation muss im Diagnose-Extrakt konsistent definiert sein.
• Interaktion mit ara::crypto: Für Authentication (UDS 0x29) und SecurityAccess (UDS 0x27) darf die Applikation Schlüsselmaterial nicht im Klartext halten; private Keys und Root-Zertifikate müssen über die Krypto-APIs (X509Provider, KeyStorageProvider) in Hardware-Vertrauensankern (HSM/Secure Element) abgesichert sein.