Figure 9.110: 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 Diagnose- und Security-Funktionen als Service-Consumer nutzt und Handler-Methoden als Callbacks bereitstellt.
• «aapFunctionalCluster» Diagnostic Management (Attribut: daemon-based): Zentraler Plattformdienst (Daemon), der als UDS-Server fungiert und die Port-Schnittstellen implementiert bzw. bereitstellt.

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

1. SecurityAccess (UDS Service 0x27):
   • + Offer() / + StopOffer(): Reguläre Service-Methoden zur Lebenszyklus- und Registrierungssteuerung.
   • «aapCallbackMethod» + CompareKey(): Callback zur Schlüsselverifikation (Key Comparison) durch die Applikation.
   • «aapCallbackMethod» + GetSeed(): Callback zur Anforderung eines kryptografischen Zufallswerts (Seed) von der Applikation.
2. ServiceValidation:
   • + Offer() / + StopOffer(): Reguläre Methoden zur Lebenszyklus-Steuerung der Validierungsinstanz.
   • «aapCallbackMethod» + Confirmation(): Callback zur Bestätigung über Abschluss oder Statusänderung einer Diagnoseanfrage.
   • «aapCallbackMethod» + Validate(): Callback zur Prüfung von System-Vorbedingungen vor der Service-Ausführung.
3. Authentication (UDS Service 0x29):
   • + Offer() / + StopOffer(): Reguläre Methoden zur Lebenszyklus-Steuerung.
   • «aapCallbackMethod» + VerifyCertificateBidirectional(): Callback zur gegenseitigen Zertifikatsauthentifizierung.
   • «aapCallbackMethod» + VerifyCertificateUnidirectional(): Callback zur einseitigen Zertifikatsprüfung (Tester gegen ECU).
   • «aapCallbackMethod» + VerifyOwnership(): Callback zur Verifikation des Besitznachweises (Proof of Ownership).
4. TransmitCertificate (UDS Service 0x29 Subfunktionen):
   • + Offer() / + StopOffer(): Reguläre Methoden zur Lebenszyklus-Steuerung.
   • «aapCallbackMethod» + Process(): Callback zur Verarbeitung und Übertragung von Zertifikatsdaten.

Beziehungen & Ports

• Applikationsseite (Adaptive Application): Greift auf alle vier Schnittstellen (SecurityAccess, ServiceValidation, Authentication, TransmitCertificate) jeweils über einen «aapRequiredPort» mit «use»-Abhängigkeit zu.
• Daemon-Seite (Diagnostic Management): Realisiert alle vier Schnittstellen vollständig (UML-Schnittstellenrealisierung: gestrichelte Linien mit geschlossener, nicht ausgefüllter Pfeilspitze vom Diagnostic Management zur jeweiligen Schnittstelle).

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.