Figure 9.43: General Cryptography Interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Komponenten-Schnittstellen-Diagramm (AUTOSAR Adaptive Platform Schnittstellenspezifikation).
• Technischer Zweck: Definition der primären Abstraktions- und Fabrikschnittstellen (CryptoProvider, CryptoContext) des funktionalen Clusters Cryptography (ara::crypto) innerhalb der AUTOSAR Adaptive Platform (Release R21-11).
• Funktionale Einordnung: Dient der Entkopplung der Adaptive Application von spezifischen kryptografischen Hardware-Sicherheitsmodulen (HSM, SHE, TPM) oder Software-Krypto-Bibliotheken über ein standardisiertes, plattformnatives C++ API. Die Implementierung ist als Daemon-basierter Service (daemon-based) ausgelegt, der Schlüsselmaterial isoliert und Operationen über IPC bzw. direkte Treiberzugriffe kapselt.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Adaptive Application (Komponente): Konsument der kryptografischen Dienste im User Space.
• «aapAPI, aapNativeInterface» CryptoProvider (Interface):
  • Zentraler Fabrikdienst (Factory Pattern) und Schlüsselverwalter für kryptografische Primitive.
  • Operationen:
    • Speicher- & Pufferverwaltung: AllocVolatileContainer(), GetPayloadStorageSize(), GetSerializedSize().
    • Identifikation / Mapping: ConvertToAlgId(), ConvertToAlgName().
    • Kontext-Fabriken (Erzeugung spezifischer Krypto-Kontexte): CreateAuthCipherCtx(), CreateDecryptorPrivateCtx(), CreateEncryptorPublicCtx(), CreateHashDigest(), CreateHashFunctionCtx(), CreateKeyAgreementPrivateCtx(), CreateKeyDecapsulatorPrivateCtx(), CreateKeyDerivationFunctionCtx(), CreateKeyEncapsulatorPublicCtx(), CreateMessageAuthCodeCtx(), CreateMsgRecoveryPublicCtx(), CreateRandomGeneratorCtx(), CreateSigEncodePrivateCtx(), CreateSignature(), CreateSignerPrivateCtx(), CreateStreamCipherCtx(), CreateSymmetricBlockCipherCtx(), CreateSymmetricKeyWrapperCtx(), CreateVerifierPublicCtx().
    • Schlüssel- und Objekt-Lebenszyklus: GeneratePrivateKey(), GenerateSeed(), GenerateSymmetricKey(), ExportPublicObject(), ExportSecuredObject(), ImportPublicObject(), ImportSecuredObject(), LoadObject(), LoadPrivateKey(), LoadPublicKey(), LoadSecretSeed(), LoadSymmetricKey().
• «aapAPI, aapNativeInterface» CryptoContext (Interface):
  • Basis-Schnittstelle aller spezialisierten Ausführungskontexte (z. B. Hashing, Signaturen, Verschlüsselung).
  • Operationen: GetCryptoPrimitiveId() (Rückgabe des Algorithmus- und Primitiv-Typs), IsInitialized() (Zustandsprüfung der Parametrisierung), MyProvider() (Referenz/Rückverweis auf den erzeugenden CryptoProvider).
• «aapFunctionalCluster» Cryptography (Komponente, daemon-based):
  • Konkreter Plattform-Cluster der Adaptive Platform, der die kryptografischen Dienste und Schnittstellen systemweit zur Verfügung stellt.

Beziehungen & Kardinalitäten

• Adaptive Application $\xrightarrow{«\text{use}»}$ CryptoProvider: Abhängigkeitsbeziehung (Verwendungsabhängigkeit). Die Applikation initialisiert und steuert die Erzeugung von Objekten über den Provider.
• Adaptive Application $\xrightarrow{«\text{use}»}$ CryptoContext: Direkte Interaktion mit dem erzeugten Kontext zur Durchführung eigentlicher kryptografischer Berechnungen (z. B. Update/Finish-Operationen in den abgeleiteten Kontexten).
• Cryptography ⇢ CryptoProvider / CryptoContext: Interface-Realisierung (UML Realization, gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze). Der Daemon-basierte Cluster implementiert die nativen Schnittstellenverträge.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl statisch dargestellt, erzwingt die Struktur folgendes typisches Interaktionsmuster zur Laufzeit:

1. Provider-Lookup: Die Applikation fordert eine Instanz des CryptoProvider über die Laufzeitumgebung an (ara::crypto::LoadCryptoProvider()).
2. Schlüssel-Initialisierung: Laden oder Generieren kryptografischer Schlüssel (LoadPublicKey(), GenerateSymmetricKey(), etc.) oder Allokieren volatiler Container (AllocVolatileContainer()).
3. Kontexterzeugung: Aufruf der zuständigen Factory-Methode (z. B. CreateMessageAuthCodeCtx(), CreateEncryptorPublicCtx()). Der Provider instantiiert und konfiguriert den Kontext unter Zuordnung zum Daemon/Treiber.
4. Zustandsprüfung & Ausführung:
   • Abfrage über CryptoContext::IsInitialized() stellt sicher, dass alle Parameter (IV/Nonce, Key) gesetzt sind.
   • Rückführbarkeit auf den Provider über CryptoContext::MyProvider().
   • Synchrone oder asynchrone Krypto-Operationen laufen kontextbezogen ab. Bei Daemon-basierter Implementierung erfolgt dies über IPC zum Krypto-Serverprozess bzw. HSM-Treiber.
5. Serialisierung / Persistenz: Export oder Import geschützter Objekte über ExportSecuredObject() / ImportSecuredObject().

4. Normative Relevanz & Entwickler-Hinweise

• Architekturprinzip (Factory & Capability Isolation): Direkte Instantiierung von Krypto-Algorithmen per new ist strikt untersagt. Die Erzeugung läuft zwingend über den CryptoProvider.
• Daemon-based vs. Library-based: Der Vermerk daemon-based kennzeichnet ein Prozess-Isolationsmodell. Schlüsselmaterial verbleibt im Adressraum des Daemons bzw. der HSM; die Applikation hält im Normalfall nur opake Handles (CryptoObject, KeySlot).
• Zero-Allocation im Arbeitsbetrieb: Um Echtzeitanforderungen zu genügen, müssen flüchtige Container (AllocVolatileContainer()) und Kontexte vor Beginn zeitkritischer Phasen (Transitionsphase Execution Management) allokiert und initialisiert werden.
• Memory & Thread Safety: Kontexte (CryptoContext) sind standardmäßig nicht threadsicher und dürfen ohne externe Synchronisation nicht von parallelen Threads geteilt werden. Der CryptoProvider selbst ist zustandslos bezüglich einzelner Krypto-Operationen, verwaltet jedoch gemeinsame Ressourcen und Slots.
• C++ API-Bindung (ara::core::Result): Sämtliche Methodenaufrufe (insbesondere Context-Fabriken und Key-Loads) liefern typischerweise ara::core::Result<T>, wodurch Fehler (z. B. nicht unterstützte Algorithmus-IDs, fehlende Berechtigungen, fehlerhafte Signaturen) explizit ohne C++-Exceptions behandelt werden müssen.