Figure 9.52: Taxonomy of Cryptographic Object Interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellentaxonomie (statische Vererbungshierarchie von C++-Interfaces).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), funktionaler Cluster ara::crypto (Cryptography Architecture, Dokument AUTOSAR_EXP_SWArchitecture, R21-11, referenzierend AUTOSAR_SWS_Cryptography).
• Funktionaler Zweck: Formale Strukturierung der objektorientierten Schnittstellen zur Kapselung kryptografischer Primitive, Schlüssel und Artefakte. Das Modell trennt bewusst die Verwaltung sicherheitsrelevanter Nutzungsrestriktionen (RestrictedUseObject) von der Serialisierbarkeit (Serializable), um unberechtigten Klartext-Export von sensitivem Schlüsselmaterial auf API-Ebene typsicher zu unterbinden.

2. Komponenten, Entitäten & Schnittstellen

Alle Schnittstellen tragen das Stereotyp «aapAPI, aapNativeInterface» (AUTOSAR Adaptive Platform Native C++ API-Interface).

• CryptoObject (Basis-Schnittstelle):
  • Abstrakter Wurzeltyp für alle kryptografischen Entitäten im Stack.
  • Stellt generische Metadaten bereit (z. B. Crypto Object Unique Identifier [COUID], Objekttyp, Provider-Zuordnung).
• RestrictedUseObject:
  • Spezialisierung von CryptoObject.
  • Ergänzt Restriktions- und Sicherheitsrichtlinien: definiert anwendungsbezogene Nutzungsmasken (Allowed Usage Flags, z. B. kAllowSignature, kAllowDataEncryption), Gültigkeitsdauern und Algorithmen-Einschränkungen.
• Serializable:
  • Orthogonale funktionale Schnittstelle für Objekte, die in Byte-Repräsentationen exportiert bzw. persistiert werden dürfen (Bereitstellung von Serialisierungsmethoden wie ExportPublicly()).
• Spezialisierte Kryptografie-Objekte (Unterklassen):
  • SymmetricKey: Spezialisiert RestrictedUseObject. Repräsentiert symmetrische Schlüssel (z. B. AES). Nicht serialisierbar.
  • SecretSeed: Spezialisiert RestrictedUseObject. Kapselt geheimes Entropie-/Seed-Material (z. B. für KDFs oder RNGs). Nicht serialisierbar.
  • PrivateKey: Spezialisiert RestrictedUseObject. Repräsentiert asymmetrische private Schlüssel. Nicht serialisierbar.
  • PublicKey: Mehrfachvererbung aus RestrictedUseObject und Serializable. Unterliegt Nutzungsrestriktionen, ist jedoch öffentlich exportierbar.
  • Signature: Spezialisiert direkt CryptoObject und Serializable. Kapselt das kryptografische Resultat einer Signaturoperation; benötigt keine RestrictedUseObject-Schlüsselnutzungsregeln, ist aber exportier- und transportfähig.

Vererbungs- und Beziehungstopologie:

• Generalisierung zu CryptoObject:
  • RestrictedUseObject → CryptoObject
  • Signature → CryptoObject (direkte Vererbung unter Umgehung von RestrictedUseObject)
• Generalisierung zu RestrictedUseObject:
  • SymmetricKey, SecretSeed, PrivateKey, PublicKey → RestrictedUseObject
• Mehrfachvererbung zu Serializable:
  • PublicKey → Serializable
  • Signature → Serializable

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Schnittstellendiagramm enthält die Abbildung keine Zeitachsen oder Zustandsübergänge. Das implizierte Laufzeitverhalten innerhalb des ara::crypto-Clusters gestaltet sich wie folgt:

• Erzeugung/Lebenszyklus:
  • Objekte werden nicht direkt instanziiert, sondern über Factory-Methoden des zuständigen CryptoProvider (z. B. GeneratePrivateKey(), LoadObject()) synchron via Unique Pointer (ara::crypto::CryptoObject::Uptr) alloziert.
• Synchroner Kontrollfluss & Validierung:
  • Vor Ausführung einer kryptografischen Operation (z. B. in SignerPrivateCtx oder EncryptorPublicCtx) prüft der Stack synchron die Bitmaske von RestrictedUseObject::GetAllowedUsage().
  • Verletzt die angeforderte Transformation die Restriktion, bricht der Aufruf synchron ab und meldet den Fehler über ara::core::Result (typischer Fehlercode: CryptoErrc::kUsageViolation).
• Fehlerbehandlung:
  • Adaptive-Plattform-spezifisch: Keine DET/DEM-Meldungen, sondern typsichere ara::core::ErrorCode / ara::core::Result<T>-Rückgaben.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- und API-Vertrag:
  • Security by Type Design: Geheimes Schlüsselmaterial (PrivateKey, SymmetricKey, SecretSeed) implementiert Serializable explizit nicht. Entwickler können diese Objekte über die Standard-API nicht versehentlich im Klartext exportieren oder serialisieren.
  • Persistenz & Export: Der Export oder die Persistierung geheimer Schlüssel ist ausschließlich über privilegierte Key-Management-Schnittstellen (ara::crypto::keys::KeySlot) unter Kapselung durch Hardware-Sicherheitsmodule (HSM / Secure Elements) möglich.
• Auswirkungen auf C++-Entwickler:
  • Abstrakte Basisschnittstellen erfordern den Einsatz von Mehrfachvererbung (class PublicKey : public RestrictedUseObject, public Serializable).
  • Signatur- und Verifikationskontexte akzeptieren ausschließlich Instanzen, die den entsprechenden Schnittstellenvertrag erfüllen (z. B. VerifierPublicCtx erwartet PublicKey, während SignerPrivateCtx PrivateKey verlangt).
  • Polymorphe Übergabe erfolgt normativ über Interface-Pointer; Destruktoren der Basisinterfaces sind virtual ausgelegt, um Ressourcenfreigabe im zugrunde liegenden Treiber sicherzustellen.