Modul ara::crypto — Cryptography

Das funktionale Cluster Cryptography stellt standardisierte Sicherheitsdienste für symmetrische und asymmetrische Verschlüsselung, Signaturprüfung sowie die sichere Schlüssel- und Zertifikatsverwaltung bereit (PlatformDesign S. 71). Der Zugriff auf kryptografische Operationen und persistente Schlüsselplätze erfolgt strikt isoliert über plattformspezifische Provider und deklarativ im Manifest verankerte Instanzspezifizierer (SWS Cryptography S. 39). Die Durchsetzung von Nutzungsbeschränkungen verhindert dabei eine Kompromittierung des sensiblen Schlüsselmaterials ([SWS_CRYPT_50092]).

mehr ›

Das funktionale Cluster Cryptography (ara::crypto) stellt eine umfassende Sicherheitsarchitektur für die AUTOSAR Adaptive Platform bereit (PlatformDesign S. 71). Zur Absicherung gegen kompromittierte Benutzeranwendungen sind Schlüsselhaltung und kryptografische Ausführung typischerweise in einem isolierten Plattform-Daemon oder Hardware-Sicherheitsmodul (HSM) gekapselt (AUTOSAR AP EXP SWArchitecture S. 97, SWS Cryptography S. 87). Die Gesamtfunktionalität gliedert sich in spezialisierte CryptoProvider für Berechnungsprimitiven, den Key-Storage-Bereich für persistente Schlüsselplätze (KeySlots) sowie einen maschinenweiten X509Provider für das PKI-Zertifikatsmanagement (SWS Cryptography S. 39).

Kontextdiagramm: Architektur- und Komponentenbeziehungen des Functional Clusters Cryptography zwischen Applikation, Daemon und Providern. Quellen: SWS Cryptography S. 39, PlatformDesign S. 71, AUTOSAR AP EXP SWArchitecture S. 97.

Anwendungen erzeugen kryptografische Kontexte wie symmetrische Chiffren ([SWS_CRYPT_20742]), authentisierte Chiffren ([SWS_CRYPT_20745]), Hashfunktionen ([SWS_CRYPT_20747]) oder Signer- und Verifier-Instanzen ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) über ihren Provider (AUTOSAR AP EXP SWArchitecture S. 99). Die Verarbeitung folgt einem deterministischen Lebenszyklus: Nach der Schlüsselbindung (SetKey) wird die Transformation über Start() eingeleitet, über Update() gestreamt und mit Finish() abgeschlossen (AUTOSAR AP TR SystemTests S. 206, EXP SWArchitecture S. 104). Unveränderliche AllowedUsageFlags verhindern wirksam eine unautorisierte Schlüsselverwendung ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests S. 177).

Zustandsdiagramm: Lebenszyklus kryptografischer Transformationskontexte von der Allokation bis zum Reset. Quellen: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Zertifikate und CSRs werden über den X509Provider verwaltet ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), während Validierungskontexte Zertifikatsketten unter Berücksichtigung von CRL-Widerrufslisten ([SWS_CRYPT_50183]) und OCSP-Antworten ([SWS_CRYPT_50124]) prüfen (AUTOSAR AP TR SystemTests S. 194). Die Zuweisung von KeySlots und Zertifikaten an Applikationen erfolgt modellbasiert im Manifest über InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification S. 245, AUTOSAR AP TPS ManifestSpecification S. 649). Sämtliche Schnittstellen arbeiten mit ausnahmelosen ara::core::Result-Rückgaben und signalisieren Fehler über die CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography S. 208).

mehr ›

Architektur, Sicherheitsdomänen und Daemon-Isolation

Das funktionale Cluster Cryptography (ara::crypto) bildet die zentrale Sicherheitsbasis der AUTOSAR Adaptive Platform und stellt kryptografische Basismechanismen, Schlüsselverwaltung sowie Zertifikatsdienste bereit (PlatformDesign S. 71). Gemäß dem Vertrauensmodell der Plattform zählen funktionale Plattform-Cluster zum vertrauenswürdigen Fundament, während Adaptive Applications im unprivilegierten Benutzerraum ausgeführt werden (SWS Cryptography S. 37). Um Schlüsselmaterial und kryptografische Operationen auch bei einer potenziellen Kompromittierung einer Anwendung wirksam abzusichern, ist die Architektur typischerweise daemon-basiert ausgelegt; die eigentliche Ausführung und Schlüsselhaltung verbleiben in einem isolierten Plattformprozess oder in einer sicheren Ausführungsumgebung (AUTOSAR AP EXP SWArchitecture S. 97, SWS Cryptography S. 87).

Die Architektur unterteilt die kryptografische Funktionalität in drei primäre Domänen: den CryptoProvider für Berechnungsprimitive und Schlüsseltransformationen, den Key-Storage-Bereich (ara::crypto::keys) für die persistente Objekthaltung sowie den X509Provider (ara::crypto::x509) für das Zertifikatsmanagement (SWS Cryptography S. 39, SWS Cryptography S. 87). Auf einem Steuergerät können mehrere spezialisierte Instanzen von CryptoProvider parallel existieren, beispielsweise zur Anbindung unterschiedlicher Hardware-Sicherheitsmodule (HSM, TPM) oder softwarebasierter Treiber (SWS Cryptography S. 39). Zwischen unterschiedlichen Providern besteht jedoch bewusst keine Interoperabilität: Ein kryptografisches Objekt oder ein Schlüssel gehört exakt zu einem Provider und kann nicht von einem anderen Provider verarbeitet werden (SWS Cryptography S. 39). Diese strikte Kapselung dürfte primär darauf zurückzuführen sein, dass Hardware-Sicherheitsdomänen ihre Schlüsselgrenzen physikalisch erzwingen und Schlüsselgriffe nicht domänenübergreifend gültig sind. Frage Q-63efe107cf111983 (offen)

Kontextdiagramm: Architektur- und Komponentenbeziehungen des Functional Clusters Cryptography zwischen Applikation, Daemon und Providern. Quellen: SWS Cryptography S. 39, PlatformDesign S. 71, AUTOSAR AP EXP SWArchitecture S. 97.

Einstiegspunkte und Initialisierung der kryptografischen Provider

Der Einstieg in das Modul erfolgt über globale Einstiegsfunktionen, die als Fabriken für die zentralen Abstraktionsschnittstellen dienen (SWArchitecture S. 71). Anwendungen erzeugen oder laden eine Instanz eines CryptoProvider über die Funktion [SWS_CRYPT_20099] unter Angabe eines modellierten ara::core::InstanceSpecifier. Für das Zertifikatsmanagement existiert im Gesamtsystem genau ein globaler Zertifikatsprovider, der über [SWS_CRYPT_40099] geladen wird (SWS Cryptography S. 39). Ergänzend stehen globale Hilfsdienste zur Verfügung, darunter die direkte Erzeugung von Zufallsdaten via [SWS_CRYPT_30098] sowie das Abfragen eines hardwaregestützten Sicherheitszählers über [SWS_CRYPT_20098] (SWArchitecture S. 71).

Persistente Schlüsselressourcen werden nicht direkt instanziiert, sondern über logische Schlüsselplätze (KeySlots) geladen. Hierzu stellt die Laufzeitumgebung die Funktionen [SWS_CRYPT_50004] für schreibgeschützte Zugriffe und [SWS_CRYPT_50005] für schreibbare Schlüsselplätze bereit, die den übergebenen Instanzbezeichner gegen die Berechtigungskonfiguration validieren (SWS Cryptography S. 87, AUTOSAR AP TPS ManifestSpecification S. 649). Über eine erhaltene KeySlot-Instanz kann die zugeordnete Provider-Instanz mittels [SWS_CRYPT_30403] abgefragt werden, wodurch die enge Bindung zwischen Speicherort und Ausführungsumgebung sichergestellt bleibt (SWS Cryptography S. 39).

Sobald eine CryptoProvider-Instanz verfügbar ist, fungiert sie als zentrale Fabrik zur Instanziierung spezifischer kryptografischer Arbeitskontexte (AUTOSAR AP EXP SWArchitecture S. 99). Zu den erzeugbaren Kontexten gehören unter anderem Kontexte für Zufallsgeneratoren ([SWS_CRYPT_20741]), symmetrische Block- und Stromchiffren ([SWS_CRYPT_20742]), authentisierte Verschlüsselung ([SWS_CRYPT_20745]), Message Authentication Codes ([SWS_CRYPT_20746]), kryptografische Hashfunktionen ([SWS_CRYPT_20747]), asymmetrische Verschlüsselung bzw. Entschlüsselung ([SWS_CRYPT_20750], [SWS_CRYPT_20751]) sowie Signatur- und Verifikationskontexte ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture S. 99).

Kryptografische Transformationskontexte und Datenverarbeitung

Die Verarbeitung kryptografischer Daten in ara::crypto folgt einem streng zustandsbasierten Lebenszyklus, der die Entkopplung von Algorithmenkonfiguration, Schlüsselbindung und Streaming-Verarbeitung gewährleistet (AUTOSAR AP TR SystemTests S. 211). Nach der Allokation des Kontexts über den Provider befindet sich dieser zunächst im Zustand uninitialisiert. Erst durch die Übergabe eines kompatiblen Schlüssels über die typspezifischen Überladungen von SetKey() – etwa für symmetrische Schlüssel ([SWS_CRYPT_23911]), private Schlüssel ([SWS_CRYPT_23515]) oder direkt aus einem KeySlot ([SWS_CRYPT_50043]) – wechselt der Kontext in den bereiten Zustand (AUTOSAR AP TR SystemTests S. 206).

Für Streaming-Verarbeitungen wird die Transformation durch Start() initiiert, optional unter Übergabe eines Initialisierungsvektors oder Kontexts ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). Anschließend können Datenblöcke schrittweise über Update() eingespeist werden ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). Bei authentisierter Verschlüsselung (AEAD) trennt die Schnittstelle strikt zwischen assoziierten Daten, die über [SWS_CRYPT_20313] verarbeitet werden, und vertraulichen Nutzdaten via [SWS_CRYPT_50074] (EXP SWArchitecture S. 104). Der Abschluss einer Transformation erfolgt über Finish() bzw. FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), woraufhin Authentisierungstags oder Prüfsummen via GetDigest() ausgelesen werden können ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

Neben dem Streaming-Modus unterstützen Kontextklassen wie symmetrische Chiffren und authentisierte Chiffren kompakte Einmalaufrufe über [SWS_CRYPT_50047] oder [SWS_CRYPT_50078], wodurch kurze Payloads effizient ohne mehrstufigen Protokollaufruf ver- oder entschlüsselt werden können (SWS Cryptography S. 58). Soll eine laufende Operation abgebrochen werden, überführt ein Aufruf von Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) oder Reset() ([SWS_CRYPT_50212]) den Kontext deterministisch in den bereinigten Ausgangszustand zurück (EXP SWArchitecture S. 100).

Zustandsdiagramm: Lebenszyklus kryptografischer Transformationskontexte von der Allokation bis zum Reset. Quellen: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Schlüsselverwaltung, Kapselung und Berechtigungsdurchsetzung

Kryptografische Schlüssel werden im Objektmodell als CryptoObject bzw. RestrictedUseObject typisiert (AUTOSAR AP EXP SWArchitecture S. 111, EXP SWArchitecture S. 111). Der Plattformstandard unterscheidet zwischen symmetrischen Schlüsseln (SymmetricKey), privaten asymmetrischen Schlüsseln (PrivateKey) und öffentlichen Schlüsseln (PublicKey) (SWS Cryptography S. 291). Schlüsselmaterial kann direkt über den CryptoProvider erzeugt werden ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) oder aus bestehendem Schlüsselmaterial abgeleitet werden, indem ein KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) mit einem Basisschlüssel parametriert und über [SWS_CRYPT_21515] ausgeführt wird (EXP SWArchitecture S. 108).

Zur Durchsetzung des Prinzips der minimalen Rechte trägt jedes Schlüsselobjekt unveränderliche Verwendungsbeschränkungen (AllowedUsageFlags), die über [SWS_CRYPT_50092] abgefragt werden können (AUTOSAR AP TR SystemTests S. 177). Der Krypto-Stack validiert bei jedem Bindungsversuch (SetKey), ob die Operation des Zielkontexts (z. B. Verschlüsseln, Signieren, Ableiten oder Exportieren) durch die Flags des Schlüssels autorisiert ist, und lehnt unzulässige Verwendungen strikt ab (AUTOSAR AP TR SystemTests S. 177, SWArchitecture S. 95). Die Standardbelegung für einen Algorithmus lässt sich über [SWS_CRYPT_20955] ermitteln.

Für den sicheren Schlüsselaustausch implementiert das Modul mehrere standardisierte Verfahren: Bei der asymmetrischen Schlüsselvereinbarung (Diffie-Hellman / ECDH) wird über [SWS_CRYPT_20758] ein KeyAgreementPrivateCtx erstellt, an den der private Schlüssel gebunden wird ([SWS_CRYPT_21313]); die Methode [SWS_CRYPT_21312] berechnet anschließend unter Einbeziehung des öffentlichen Schlüssels der Gegenstelle den gemeinsamen symmetrischen Zielschlüssel (AUTOSAR AP TR SystemTests S. 179). Beim Key Encapsulation Mechanism (KEM) kapselt ein KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) einen symmetrischen Schlüssel mittels [SWS_CRYPT_21813], während die Gegenstelle die Dekapselung über einen KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) via [SWS_CRYPT_21412] durchführt (AUTOSAR AP TR SystemTests S. 173, AUTOSAR TR AdaptivePlatformSystemTests S. 188). Für den geschützten Schlüsseltransport stehen Key Wrapping ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) und gesicherter Export ([SWS_CRYPT_20728]) bereit (AUTOSAR AP TR SystemTests S. 174, AUTOSAR AP TR SystemTests S. 182).

Sequenzdiagramm: Asymmetrische Schlüsselvereinbarung via Diffie-Hellman und Ableitung symmetrischer Nutzschlüssel. Quellen: [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests S. 179.

Asymmetrische Signaturen werden über getrennte Kontexte abgewickelt: Das Signieren erfolgt über einen SignerPrivateCtx ([SWS_CRYPT_20756]) und die Methode [SWS_CRYPT_23512], während die Verifikation über einen VerifierPublicCtx ([SWS_CRYPT_20757]) und die Methode [SWS_CRYPT_24112] vollzogen wird (AUTOSAR AP TR SystemTests S. 164, SWArchitecture S. 84). Wird ein KeySlot im Hintergrund durch privilegierte Managementdienste (z. B. OTA-Key-Rollover) aktualisiert, können konsumierende Bibliotheken über einen Update-Observer via [SWS_CRYPT_30404] benachrichtigt werden, um ihr Schlüsselmaterial synchron nachzuladen (AUTOSAR AP SWS Cryptography S. 36).

Sequenzdiagramm: Ablauf von Signaturerzeugung und -verifikation unter Nutzung getrennter privater und öffentlicher Kontexte. Quellen: [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests S. 164.

X.509-Zertifikatsmanagement, Validierung und Gruppen

Das Subsystem ara::crypto::x509 stellt standardisierte Funktionen für Public-Key-Infrastrukturen (PKI) bereit (EXP SWArchitecture S. 116). Der zentrale X509Provider ([SWS_CRYPT_40099]) unterstützt sowohl flüchtigen Session-Speicher als auch persistente Ablagen (SWS Cryptography S. 39). Zertifikate und Ketten werden über [SWS_CRYPT_40614] bzw. [SWS_CRYPT_40616] aus Byte-Puffern geparst. Zur Beantragung neuer Identitätszertifikate können Anwendungen über [SWS_CRYPT_40640] kryptografisch signierte Certificate Signing Requests (CSR) generieren, wobei der Signer-Kontext und der Distinguished Name (DN) über [SWS_CRYPT_50186] übergeben werden (AUTOSAR AP TR SystemTests S. 189).

Für die Konformitäts- und Gültigkeitsprüfung instanziiert die Anwendung über [SWS_CRYPT_50125] einen CertificateValidationCtx. Diesem Kontext werden Vertrauensanker (Trust Anchors) über [SWS_CRYPT_50117] hinzugefügt, Validierungsoptionen über [SWS_CRYPT_50120] definiert und Referenzzeitstempel via [SWS_CRYPT_50121] hinterlegt. Die hierarchische Kettenprüfung gegen die Vertrauenskette erfolgt über [SWS_CRYPT_50122] bzw. [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests S. 194). Zur Erfassung von Zertifikatswiderrufen können Certificate Revocation Lists (CRL) importiert ([SWS_CRYPT_50183]) oder Online-Zertifikatsstatusabfragen (OCSP gem. RFC 6960) über [SWS_CRYPT_40626], [SWS_CRYPT_50185] und [SWS_CRYPT_50124] in den Validierungsstatus eingebunden werden (AUTOSAR AP TR SystemTests S. 194).

Um Zertifikatskonsumenten von individuellen Zertifikatsinstanzen bei Schlüsselwechseln zu entkoppeln, unterstützt das Manifest das Konzept der CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification S. 657). Konsumierende Anwendungen laden über [SWS_CRYPT_50126] die gesamte Gruppe logisch verknüpfter Zertifikate, während privilegierte Administrationsdienste Zertifikate über [SWS_CRYPT_50127] und [SWS_CRYPT_50128] dynamisch austauschen oder bereinigen können (AUTOSAR AP TPS ManifestSpecification S. 657).

Sequenzdiagramm: X.509-Zertifikatsvalidierung mit Zertifikatskette, CRL-Import und Online-OCSP-Statusprüfung. Quellen: [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests S. 194.

Manifest-Modellierung, Port-Schnittstellen und Deployment

Die Integration kryptografischer Ressourcen in eine Gesamtfahrzeugarchitektur erfolgt deklarativ über das AUTOSAR-Metamodell im ARXML-Manifest (AUTOSAR AP TPS ManifestSpecification S. 244). Softwarekomponenten modellieren ihre Sicherheitsanforderungen auf Design-Ebene über Ports (RPortPrototype), die durch Spezialisierungen von CryptoInterface typisiert werden: CryptoKeySlotInterface für Schlüsselplätze, CryptoCertificateInterface für Zertifikatsressourcen und CryptoProviderInterface für den Zugriff auf Ausführungs-Provider (TPS ManifestSpecification S. 167, AUTOSAR AP TPS ManifestSpecification S. 245). Die Attribute der Schnittstellen legen unveränderlich fest, ob Lese- oder Schreibrechte gewährt werden (writeAccess) und welche Objekttypen zulässig sind (TPS ManifestSpecification S. 168, TPS ManifestSpecification S. 438).

Im Deployment-Manifest verbindet die Zielkonfiguration (Target Configuration) die abstrakten Port-Prototypen mit konkreten physischen Plattformressourcen (AUTOSAR AP TPS ManifestSpecification S. 649). Das Metamodellelement CryptoKeySlotToPortPrototypeMapping mappt den Port eines Prozesses auf einen im CryptoModuleInstantiation der Maschine deklarierten CryptoKeySlot (TPS ManifestSpecification S. 614, TPS ManifestSpecification S. 646). In analoger Weise ordnet CryptoCertificateToPortPrototypeMapping Zertifikate zu (TPS ManifestSpecification S. 655). Zur Laufzeit repräsentiert der Pfad des Ports im Manifest den ara::core::InstanceSpecifier, den der Anwendungscode an Ladefunktionen wie [SWS_CRYPT_50004] übergibt (ManifestSpecification S. 154).

Für Plattforminteraktionen zwischen funktionalen Clustern – etwa zwischen Communication Management (SecOC, IPsec, TLS) und dem Krypto-Stack – existieren keine klassischen Port-Prototypen (TPS ManifestSpecification S. 861). Hier wird der InstanceSpecifier stattdessen durch Elemente abgeleitet von FunctionalClusterInteractsWithFunctionalClusterMapping gebildet, beispielsweise ComKeyToCryptoKeySlotMapping oder SecOcJobMapping (TPS ManifestSpecification S. 861, TPS ManifestSpecification S. 864, ManifestSpecification S. 411). Auch die Persistenzabsicherung (Persistency Deployment) und Software-Cluster-Prüfsummen binden ihre Schlüssel und Provider über diese standardisierten Manifest-Mappings ein (TPS ManifestSpecification S. 867, TPS ManifestSpecification S. 896).

Verhalten im Fehlerfall

Das Fehlerbehandlungskonzept des Krypto-Moduls folgt den strikten Vorgaben der Adaptive Platform für fehlersicheren und ausnahmelosen Code (noexcept) (SWS Cryptography S. 145). Sämtliche synchronen Operationen geben Fehlersituationen über den generischen Ergebnistyp ara::core::Result<T, ara::core::ErrorCode> zurück (SWS Cryptography S. 208). Die Fehlercodes sind in einer eigenen Fehlerdomäne verankert, die über [SWS_CRYPT_19902] repräsentiert wird; ihr Name lässt sich über [SWS_CRYPT_19950] und die textuelle Fehlerbeschreibung über [SWS_CRYPT_19953] abfragen. Für Applikationen, die Ausnahmebehandlung explizit nutzen, stellt der Stack den Ausnahmetyp CryptoException ([SWS_CRYPT_19906]) und die Hilfsfunktion [SWS_CRYPT_19954] bereit.

Typische funktionale Fehlercodes umfassen Kontextverletzungen wie CryptoErrc::kUninitializedContext, wenn kryptografische Operationen vor dem Aufruf von SetKey() angestoßen werden, oder CryptoErrc::kInvalidInputSize, wenn die übergebenen Eingabedatenpuffer nicht zum geforderten Blockraster passen (SWS Cryptography S. 208). Bei Serialisierungs- und Konvertierungsvorgängen signalisiert CryptoErrc::kUnknownIdentifier nicht unterstützte Argumentwerte und CryptoErrc::kIncompatibleArguments inkompatible Parameterkombinationen (SWS Cryptography S. 145). Beim Zugriff auf Schlüsselressourcen verhindert der Stack unautorisierte Zugriffe durch die Rückgabe von kAccessViolation (SWS Cryptography S. 87). Beim Parsen fehlerhafter benutzerdefinierter X.509-Zertifikatserweiterungen bricht der Parser mit CryptoErrc::kRuntimeFault ab (SWS Cryptography S. 280, SWS Cryptography S. 356).

Um nach einem aufgetretenen Fehler einen definierten Zustand im Kontext wiederherzustellen und Speicherlecks oder hängende Streaming-Puffer im Daemon zu vermeiden, muss der Aufrufer den Kontext bereinigen. Dies geschieht entweder gezielt durch Aufruf von Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), wodurch unvollendete Transformationen verworfen werden, oder durch Reset() ([SWS_CRYPT_50212]), was den Kontext vollständig in den Zustand vor der Schlüsselbindung zurückversetzt (EXP SWArchitecture S. 100).

Weiterführende Detailbelege

Die Spezifikation des Moduls Cryptography stützt sich auf eine Reihe zentraler Anforderungen und Architekturdokumente, die im Folgenden eingeordnet werden:

• Globale Einstiegspunkte und Fabriken: Die Spezifikationen [SWS_CRYPT_20099] (LoadCryptoProvider) und [SWS_CRYPT_40099] (LoadX509Provider) definieren den normativen Zugang zu den beiden primären Provider-Domänen (SWArchitecture S. 71, SWS Cryptography S. 39).
• Schlüsselhaltung und Port-Bindung: Die Funktionen [SWS_CRYPT_50004] (LoadKeySlot) und [SWS_CRYPT_50005] (LoadWriteableKeySlot) setzen das Zusammenspiel zwischen Port-Modellierung im Manifest und isoliertem physischem Speicherzugriff im KSP verbindlich um (SWS Cryptography S. 87, AUTOSAR AP TPS ManifestSpecification S. 649).
• Primitiven- und Kontextfabriken: Die Schnittstellengruppe um [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx) und [SWS_CRYPT_20757] (CreateVerifierPublicCtx) legt die dynamische Erzeugung standardisierter Zustandsmaschinen für Krypto-Jobs fest (AUTOSAR AP EXP SWArchitecture S. 99, AUTOSAR AP TR SystemTests S. 164).
• X.509-Validierung und Widerrufsprüfung: Mit [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl) und [SWS_CRYPT_50124] (AddOcspResponse) wird eine vollständige, automobilgerechte PKI-Prüfkette normiert (AUTOSAR AP TR SystemTests S. 194, EXP SWArchitecture S. 116).