Figure 9.50: SignatureService and CryptoContext Interfaces

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellen-Realisierungsdiagramm der AUTOSAR Adaptive Platform (AAP).
• Technischer Zweck: Spezifikation der objektorientierten C++-Programmierschnittstellen (ara::crypto::cryp) für asymmetrische digitale Signaturen (Signaturerzeugung und -verifikation) sowie deren Metadaten-Abfrage über den SignatureService.
• Funktionale Einordnung: Verortung im Functional Cluster Cryptography (ara::crypto) unter einer daemon-basierten Deployment-Architektur (Prozess- und Rechtemodell mit ausgelagerter Krypto-Ausführung/Schlüsselverwaltung via IPC/HSM-Anbindung).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application («component»): Applikativer Konsument im User Space, der kryptografische Operationen anfordert.
• Cryptography («aapFunctionalCluster», daemon-based): Bereitstellender Plattform-Daemon, der die kryptografischen Primitiven kapselt, Schlüssel schützt und die Schnittstellen implementiert.

Schnittstellen & Klassenhierarchie

• SignerPrivateCtx («aapAPI, aapNativeInterface», Subtyp von CryptoContext):
  • Zuständiger Kontext für die Erzeugung digitaler Signaturen mittels privatem Schlüssel.
  • Operationen:
    • + GetSignatureService(): Liefert die assoziierte SignatureService-Instanz für Algorithmenparameter.
    • + SetKey(): Bindet einen privaten Schlüssel (PrivateKey) an den Kontext.
    • + Reset(): Setzt den internen Zustand des Kontexts zurück (erlaubt Wiederverwendung mit gleichem Schlüssel).
    • + Sign(): Berechnet Hash und Signatur über die übergebenen Rohdaten.
    • + SignPreHashed(): Signiert einen bereits vorberechneten Hashwert (Digest).
• VerifierPublicCtx («aapAPI, aapNativeInterface», Subtyp von CryptoContext):
  • Zuständiger Kontext für die Verifikation digitaler Signaturen mittels öffentlichem Schlüssel (PublicKey).
  • Operationen:
    • + GetSignatureService(): Liefert die assoziierte SignatureService-Instanz.
    • + Verify(): Verifiziert die Signatur direkt über den Rohdaten.
    • + VerifyPrehashed(): Verifiziert die Signatur gegen einen vorberechneten Hashwert.
• SignatureService («aapAPI, aapNativeInterface», Subtyp von ExtensionService):
  • Hilfsschnittstelle zur Abfrage von Algorithmen- und Puffer-Spezifika.
  • Operationen:
    • + GetRequiredHashAlgId(): Liefert die Crypto-Algorithmus-ID des korrespondierenden Hash-Verfahrens.
    • + GetRequiredHashSize(): Liefert die erwartete Digest-Größe in Bytes.
    • + GetSignatureSize(): Liefert die exakte Ausgabegröße der Signatur in Bytes (für statische Pufferallokation).

Beziehungen

• Realisierung (<|..): Der Functional Cluster Cryptography implementiert die nativen Schnittstellen SignerPrivateCtx, VerifierPublicCtx und SignatureService.
• Nutzungsbeziehung («use»): Die Adaptive Application interagiert direkt über native C++-Proxy-Interfaces mit den drei Kontext-/Service-Schnittstellen.
• Assoziation / Delegation: SignerPrivateCtx und VerifierPublicCtx navigieren über GetSignatureService() auf die jeweilige SignatureService-Instanz.

3. Dynamisches Verhalten & Sequenzablauf

1. Kontext-Allokation: Die Applikation erzeugt via ara::crypto::cryp::CryptoProvider eine Kontext-Instanz (CreateSignerPrivateCtx bzw. CreateVerifierPublicCtx).
2. Schlüsselbindung: Aufruf von SetKey() bindet ein zuvor geladenes Schlüssel-Handle (PrivateKey bzw. PublicKey). Ohne gültigen Schlüssel schlagen Folgeoperationen fehl (kUninitializedContext).
3. Puffer-Dimensionierung (optional / vorbereitend): Aufruf von GetSignatureService() ermöglicht via GetSignatureSize() die statische Allokation eines ara::crypto::WritableMemRegion-Puffers für die Signatur bzw. via GetRequiredHashSize() für den Hashwert.
4. Ausführung (Synchroner Pfad via IPC):
   • Pfad A (Direkt): Sign() / Verify() übernimmt Rohdaten, führt Hashing und Signatur-Primitiv gekapselt aus.
   • Pfad B (Pre-Hashed): Die Applikation hasht Daten lokal und ruft SignPreHashed() / VerifyPrehashed() auf (minimiert IPC-Payload zum Krypto-Daemon).
5. Abschluss & Reset: Reset() löscht transiente Zustandsdaten (z. B. Zwischenergebnisse), behält jedoch die Schlüsselzuordnung für wiederholte Signaturen bei.

4. Normative Relevanz & Entwickler-Hinweise

• Speicher- und Pufferverwaltung: GetSignatureSize() ist zwingend vor dem Aufruf von Sign() zu konsultieren, um Deadlocks oder ara::core::ErrorCode-Fehlschläge (kInsufficientCapacity) bei fest allokierten Memory-Regions zu verhindern.
• IPC-Bandbreite & Latenz: Im daemon-basierten Deployment erzeugen große Payloads bei Sign() hohen IPC-Overhead. Embedded-Entwickler sollten für große Datenmengen (z. B. Firmware-Images, Diagnosedaten) stets lokales Hashing via HashFunctionCtx und anschließend SignPreHashed() bzw. VerifyPrehashed() verwenden.
• Privilegientrennung (Zero-Trust/HSM): Der private Schlüssel verbleibt als opakes Handle im Daemon bzw. Hardware Security Module (HSM). Die Applikation hält zu keinem Zeitpunkt Schlüsselmaterial im eigenen Prozess-Adressraum.
• Fehlerbehandlung: Alle Methoden operieren nach dem AUTOSAR Adaptive Fehlermodell und geben ara::core::Result<T> zurück (keine C++-Exceptions; Auswertung über .HasValue() bzw. .Error()).