Figure 9.23: Interfaces for SecOC

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Service-Schnittstellen-Architekturdiagramm der AUTOSAR Adaptive Platform (Modellierung von Service-Interfaces via ara::com).
• Architektur-Kontext: Spezifikation von SecOC (Secure Onboard Communication) innerhalb des Functional Clusters Communication Management (ara::com).
• Funktionaler Zweck: Standardisierte Dienstschnittstellen zur Überwachung und Beeinflussung der kryptografischen Verifikation gesicherter PDUs/Nachrichten. Ermöglicht privilegierten Adaptive Applications (z. B. Diagnose, Intrusion Detection System / IDS, Test-Frameworks), Verifikationsstatus-Ereignisse asynchron zu empfangen und den Verifikationsstatus gezielt (pro Data-ID oder Freshness-ID) zu übersteuern (Override).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Adaptive Application (UML-Komponente):
  • Konsument (Client/Subscriber) der SecOC-Dienste.
  • Hält drei «aapRequiredPort»-Instanzen mit «use»-Abhängigkeiten auf die Service-Interfaces.
• Communication Management («aapFunctionalCluster», daemon-based):
  • Provider (Server/Publisher) der SecOC-Dienste auf Plattformebene in daemon-basierter Ausprägung (daemon-based).
  • Realisiert die kryptografische Authentifizierung (MAC-Prüfung, Freshness-Validierung) und exponiert drei «aapProvidedPort»-Instanzen.

Schnittstellen (Service Interfaces)

1. VerificationStatusConfigurationByDataId («aapAraComServiceInterface, aapAPI»):
   • Methode: + VerifyStatusOverride()
   • Stereotypen: «aapAccessControlled, aapServiceMethod»
   • Funktion: Ermöglicht das temporäre Übersteuern der Verifikationsergebnisse bezogen auf eine spezifische Nachricht bzw. PDU (DataID).
2. VerificationStatusConfigurationByFreshnessId («aapAraComServiceInterface, aapAPI»):
   • Methode: + VerifyStatusOverride()
   • Stereotypen: «aapAccessControlled, aapServiceMethod»
   • Funktion: Ermöglicht das Übersteuern der Verifikationslogik gebunden an eine spezifische Frischewert-Quelle (FreshnessID / Counter / Trip-Reset-Synchronisation).
3. VerificationStatus («aapAraComServiceInterface, aapAPI»):
   • Event: + VerificationStatus
   • Stereotypen: «aapAccessControlled, aapServiceEvent»
   • Funktion: Asynchrones Publish/Subscribe-Event. Kommuniziert das Ergebnis der PDU-Verifikation (z. B. SEC_OK, SEC_ERROR_AUTHENTICATION, SEC_ERROR_FRESHNESS) an abonnierende Applikationen.

Beziehungen & Absicherung

• Port-Bindung: Client-Server-Beziehung (PPort an Communication Management ↔ RPort an Adaptive Application).
• Sicherheits-Stereotyp «aapAccessControlled»: Alle Methoden und Events unterliegen zwingend der Zugriffskontrolle durch IAM (Identity and Access Management / ara::iam). Nur Applikationen mit explizit konfiguriertem Grant dürfen die Schnittstellen nutzen.

3. Dynamisches Verhalten & Sequenzablauf

• Event-Pfad (Monitoring / Reporting):
  1. Eintreffen einer SecOC-gesicherten PDU am Kommunikationsstack.
  2. Prüfung von MAC und Frischewert im Communication Management (unter Nutzung von ara::crypto).
  3. Bei Statusänderung oder fehlgeschlagener Verifikation: Feuern des Events VerificationStatus via ara::com.
  4. Abonnierte Adaptive Application verarbeitet das Event (z. B. Setzen von DTCs, Security Event Reporting via IdsM).
• Methoden-Pfad (Status Override / Diagnose & Test):
  1. Synchroner oder asynchroner Methodenaufruf VerifyStatusOverride(...) durch die Applikation.
  2. IAM-Pre-Check prüft Prozessberechtigung (ProcessExecutionManifest / Grants).
  3. Stack schaltet in den Override-Modus (z. B. Forcieren von SUCCESS zur Restbus-Simulation oder FAILURE für Negativtests).
  4. Geltungsbereich wird granular gesteuert: wahlweise über die logische Datenkennung (DataId) oder über die Entität des Frischewertes (FreshnessId).

4. Normative Relevanz & Entwickler-Hinweise

• IAM-Manifest-Konfiguration (Kritischer Pfad): Da VerifyStatusOverride ein potenzielles Sicherheitsrisiko darstellt (Deaktivierung/Täuschung von Sicherheitsprüfungen), müssen die entsprechenden ServiceMethodDeployment- und ServiceEventDeployment-Ressourcen im Execution/Access-Manifest restriktiv gekapselt werden. Im Produktivbetrieb ist dieser Zugriff in der Regel für Standard-Anwendungen zu sperren.
• ARXML-Modellierung: Entwickler müssen ProvidedServiceInstance im Cluster-Manifest von ara::com sowie entsprechende RequiredServiceInstance in den Software-Komponenten-Manifesten anlegen; die Port-Modellierung verlangt exakte Übereinstimmung der Service-IDs (InterfaceId, InstanceId).
• Keine Classic-Platform-API: Entgegen Classic SecOC (welches über C-APIs wie SecOC_VerifyStatusOverride / Callouts im SecOC.c gesteuert wird) erfolgt die Interaktion in der Adaptive Platform rein Service-orientiert über generierte C++-Proxies und Skeletons (ara::com-API-Header).
• Deterministic Behavior: Event-Subscriptions auf VerificationStatus müssen in zeitkritischen Systemen entkoppelt werden, um Rückstau im Event-Queue-Handling bei hoher PDU-Rate / Flooding-Angriffen zu verhindern.