Figure 12.47: Different perspectives on the CryptoCertificateGroup

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Architektur- und Modellierungsdiagramm / UML-Objektdiagramm (Instanzebene M1) zur Veranschaulichung funktionaler Perspektiven auf das Manifest-Metamodell.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_TPS_ManifestSpecification, Kapitel Crypto / Key & Certificate Management (ara::crypto).
• Funktionaler Zweck: Visualisierung des Entwurfsmusters zur Entkopplung von Zertifikatskonsumenten (Consumer Perspective) und Zertifikatsverwaltern (Management/Provisioning Perspective) über das Metamodellelement CryptoCertificateGroup. Das Konzept verhindert harte Compile- bzw. Manifest-Abhängigkeiten zwischen Nutzungsapplikationen und individuellen Zertifikatsinstanzen bei Schlüsselwechseln oder Roll-Overs.

2. Komponenten, Entitäten & Schnittstellen

• CryptoCertificateGroup:
  • Metamodell-Entität (Grouping-Container) im Crypto-Manifest.
  • Dient als logische Abstraktionsschicht (z. B. Repräsentation eines Certificate Stores, einer CA-Vertrauenskette oder einer Menge alternativer Cipher-Zertifikate).
• CryptoCertificate "A" & CryptoCertificate "B":
  • Instanzen von CryptoCertificate, die konkrete X.509-Zertifikate oder Slot-Ressourcen im Zertifikatsspeicher des Crypto-Stacks (ara::crypto::keys) modellieren.
  • Beziehung: Gerichtete Assoziation / Aggregation mit der Rollenbezeichnung includedCertificate (Kardinalität 0..* bzw. 1..*).
• Application "GimmeCerts" (Konsument):
  • Adaptive Application / SWC mit konsumierender Schnittstelle (symbolisiert durch den Socket / Required-Port).
  • Perspektive / Abhängigkeit: Gestrichelte Abhängigkeitskante auf CryptoCertificateGroup. Die Anwendung adressiert ausschließlich den logischen Verbund und kennt die konkreten IDs/Slots der enthaltenen Zertifikate nicht zwingend im Voraus.
• Management Software "UpdateCert" (Verwalter):
  • Privilegierte Management-Applikation (z. B. UCM / Update and Configuration Management, Diagnostics Daemon oder Security Manager).
  • Perspektive / Abhängigkeit: Gestrichelte Abhängigkeitskante direkt auf CryptoCertificate "B". Adressiert granular die konkrete Zertifikatsinstanz zur Pflege des Lebenszyklus.

3. Dynamisches Verhalten & Sequenzablauf

Das statische Strukturmodell impliziert zwei orthogonale Lebenszyklus- und Zugriffspfade:

1. Konsumierender Pfad (Runtime Access):
   • GimmeCerts instanziiert den Zugriff über die Adaptive Crypto-API (ara::crypto::keys::KeyStorageProvider).
   • Über das Mapping der CryptoCertificateGroup im Manifest erhält die Applikation Zugriff auf alle aktuell assoziierten Zertifikate (CryptoCertificate "A" und "B"), z. B. zur Validierung eingehender TLS-Gegenstellen oder zur Signaturprüfung.
2. Administrativer Update-Pfad (Certificate Provisioning / Roll-Over):
   • UpdateCert empfängt ein aktualisiertes Zertifikat (z. B. via OTA-Kampagne oder UDS-Diagnose).
   • Die Management-Software adressiert gezielt CryptoCertificate "B" über administrative Schnittstellen (z. B. Import/Overwrite im Slot des Key-Storage-Treibers).
   • Wirkung: Nach dem Update-Vorgang greift GimmeCerts bei der nächsten Abfrage der CryptoCertificateGroup transparent auf die aktualisierte Instanz "B" zu, ohne dass die Konsumenten-Applikation reassembliert, neu gelinkt oder deren eigenes Manifest modifiziert werden muss.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Design & Berechtigungsmodell (Access Control):
  • Consumer-Trennung: Gewöhnliche Applikationen dürfen im Security-Manifest nur Zugriffsrechte (Read- bzw. Use-Permissions) auf die CryptoCertificateGroup erhalten, nicht auf isolierte Schreiboperationen.
  • Privileged Writes: Nur ausgewählte Management-Executables erhalten Schreib- und Modifikationsrechte (Update/Write) auf die konkreten CryptoCertificate-Slots.
• API-Nutzung (ara::crypto):
  • Applikationsentwickler müssen Schnittstellen so implementieren, dass dynamische Ergänzungen oder Updates von Zertifikaten innerhalb einer Gruppe zur Laufzeit toleriert bzw. neu eingelesen werden (kein unreflektiertes lokales Caching von Zertifikatshandles über Applikationsgrenzen hinweg).
• Lifecycle- und OTA-Robustheit:
  • Das Schema ermöglicht asynchrone Zertifikatserneuerungen (z. B. abgelaufene Sub-CA oder Leaf-Zertifikate) bei laufendem oder ruhendem Gesamtsystem, ohne dass abhängige funktionale Applikationen redeployed werden müssen.