Figure 9.42: Common Interfaces of Cryptography

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Struktur- und Realisierungsansicht der AUTOSAR Adaptive Platform).
• Architektonische Einordnung: Spezifiziert die grundlegenden C++-Schnittstellen (ara::crypto) zwischen einer Anwendung (Adaptive Application) und dem Funktionscluster Cryptography («aapFunctionalCluster») gemäß AUTOSAR_EXP_SWArchitecture (Release R21-11).
• Technischer Zweck: Entkopplung der Anwendungslogik von der konkreten kryptografischen Ausführungseinheit. Die Implementierung ist als Daemon-basierte Architektur (daemon-based) ausgelegt, bei der kryptografische Operationen, Schlüsselhaltung und Hardware-Sicherheitsmodule (HSM/SHE) in einem isolierten Plattformprozess gekapselt sind.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application: Konsumierende Entität (SW-C bzw. POSIX-Prozess im User-Space).
• Cryptography («aapFunctionalCluster», Tag daemon-based): Plattform-Dienstleister, der die kryptografischen Primitiven, Zertifikate und Key-Storage-Dienste über Interprozesskommunikation (IPC) bereitstellt.

Schnittstellen («aapAPI, aapNativeInterface»)

• Globale Utility- & Provider-Fabrikschnittstelle (statischer Einstiegspunkt):
  • + GenerateRandomData(): Generierung kryptografisch starker Zufallszahlen (TRNG/PRNG).
  • + GetSecureCounter(): Zugriff auf manipulationssichere, monotone Hardware-Zähler.
  • + LoadCryptoProvider(): Instanziierung/Laden des Providers für symmetrische/asymmetrische Krypto-Primitiven.
  • + LoadKeyStorageProvider(): Laden des Providers für persistente Schlüsselverwaltung und Keystores.
  • + LoadX509Provider(): Laden der X.509-Engine für Zertifikatskettenprüfung und PKI-Handling. (Hinweis: Alle Methoden sind unterstrichen, d. h. als statische Memberfunktionen im Namespace ara::crypto deklariert).
• IOInterface: Einheitliche Basis-Schnittstelle zur Introspektion und Zustandskontrolle kryptografischer Objekte und Container:
  • Metadaten/Limits: GetAllowedUsage(), GetCapacity(), GetCryptoObjectType(), GetObjectId(), GetPayloadSize(), GetPrimitiveId(), GetTypeRestriction().
  • Zustands- und Schutzattribute: IsObjectExportable(), IsObjectSession(), IsValid(), IsVolatile(), IsWritable().
• Serializable: Schnittstelle für exportfähige Krypto-Artefakte:
  • + ExportPublicly(): Serialisierter Export nicht-geheimer Objektdaten (z. B. Public Keys, CSRs, Zertifikate).
• VolatileTrustedContainer: Kapselung flüchtiger, geschützter Speicherbereiche (RAM) für temporäre Schlüssel oder Sitzungsdaten:
  • + GetIOInterface(): Liefert die Referenz auf das zugehörige IOInterface zur Metadaten- und Zugriffsprüfung.

Beziehungen

• Adaptive Application $\xrightarrow{«\text{use}»}$ Schnittstellen: Unidirektionale Nutzungsabhängigkeit (Client-Rolle).
• Cryptography ⇢ Schnittstellen: Realisierungsbeziehung (Interface Realization / geschlossene, nicht ausgefüllte Dreiecksspitze); der Daemon implementiert die Verträge dieser nativen Interfaces.

3. Dynamisches Verhalten & Sequenzablauf

1. Bootstrapping & Provider-Akquise:
   • Die Adaptive Application ruft statische Factory-Methoden auf (LoadCryptoProvider(), LoadKeyStorageProvider(), LoadX509Provider()), um providerspezifische Kontext-Instanzen zu erhalten.
2. Container-Erzeugung & Objektreferenzierung:
   • Allokation oder Empfang eines VolatileTrustedContainer für flüchtige Schlüsselmaterialien oder Session-Keys.
   • Auflösen des I/O-Handles über GetIOInterface().
3. Validierungs- & Berechtigungsprüfung:
   • Vor Ausführung kryptografischer Operationen prüft der Stack via IOInterface die Attribute: Gültigkeit (IsValid()), Nutzungsbeschränkung (GetAllowedUsage()), Typkonformität (GetCryptoObjectType()) und Schreibberechtigung (IsWritable()).
4. Export / Persistierung:
   • Bei gesetztem Export-Flag (IsObjectExportable() == true) kann über Serializable::ExportPublicly() der öffentliche Anteil eines Schlüsselpaars oder ein Zertifikat extrahiert werden. Rohe private Schlüssel verbleiben im gesicherten Daemon-Kontext.
5. IPC-Pfad (Daemon-Interaktion):
   • Lokale C++-Methodenaufrufe in der Applikation agieren als Thin-Client/Proxy; die Ausführung und Validierung der Privilegien erfolgt synchron oder asynchron via IPC im isolierten Cryptography-Daemon.

4. Normative Relevanz & Entwickler-Hinweise

• Kapselung von Schlüsselmaterial (Zero-Trust-Prinzip): Applikationen erhalten niemals direkten Zugriff auf rohe Schlüsselbytes im User-Space-Speicher. Zugriffe erfolgen ausschließlich über opake Identifier (GetObjectId()) und abstrakte Container (VolatileTrustedContainer).
• IPC-Latenzen beachten: Da der Cluster als daemon-based spezifiziert ist, erzeugt jeder Methodenaufruf Kontextwechsel- und IPC-Overhead. Hochfrequente Operationen (z. B. Stream-Ciphers, CAN-FD SecOC-Prüfungen) müssen gepuffert oder über dedizierte Shared-Memory- bzw. Fast-IPC-Kanäle des Providers abgewickelt werden.
• Typ- und Usage-Restriktionen: Vor der Weiterverwendung kryptografischer Objekte muss GetAllowedUsage() evaluiert werden. Ein Schlüssel, der ausschließlich für kAllowSignature deklariert ist, wird durch den Provider-Treiber hart abgewiesen, wenn er zur Verschlüsselung verwendet werden soll (ara::core::ErrorCode).
• Session vs. Persistent: Entwickler müssen über IsObjectSession() und IsVolatile() differenzieren, ob das Objekt nach Prozessende verloren geht oder im persistenten Keystore via KeyStorageProvider gesichert werden muss.
• Fehlerbehandlung: Alle Methodenaufrufe der C++-Schnittstelle folgen dem fehlertoleranten Entwurfsmuster der Adaptive Platform (ara::core::Result<T>) anstelle von C++-Exceptions.