Crypto Service Manager (CSM)

Die synchrone Funktion Csm_Init dient der Initialisierung des Moduls Crypto Service Manager (CSM) gemäß [SWS_Csm_00646]. Die Schnittstelle ist über den Header Csm.h deklariert [SWS_Csm_00646].

Hinsichtlich der Parameter und des Aufrufverhaltens legt [SWS_Csm_00646] folgende Eigenschaften fest:

• Parameter: Als Eingabeparameter wird configPtr übergeben. Dieser ist ein Zeiger auf eine ausgewählte Konfigurationsstruktur vom Typ const Csm_ConfigType* [SWS_Csm_00646]. Ein-/Ausgabeparameter oder Ausgabeparameter sind nicht vorhanden [SWS_Csm_00646].
• Rückgabewert: Die Funktion liefert keinen Rückgabewert (void) [SWS_Csm_00646].
• Synchronizität und Identifikation: Die Ausführung erfolgt synchron; die Service-ID lautet 0x00 [SWS_Csm_00646].

Für die Nebenläufigkeit und den Mehrpartitionsbetrieb gelten nach [SWS_Csm_00646] spezifische Vorgaben:

• Reentranz: Die Funktion ist nicht reentrant (Non Reentrant) und darf daher nicht nebenläufig aufgerufen werden [SWS_Csm_00646].
• Partitionierung: Wenn das CSM-Modul mehr als einer Partition zugewiesen ist (das heißt, wenn Hauptfunktionen wie Csm_MainFunction auf Partitionen verteilt sind), darf das CSM pro Partition eine eigene Initialisierungsfunktion bereitstellen [SWS_Csm_00646].

Interpretation: Da die Spezifikation Csm_Init als Initialisierungsfunktion definiert, dürfte der Aufruf typischerweise während der Systemstartphase vor der Ausführung regulärer kryptografischer Aufträge erfolgen. Frage Q-f462c3f9f4ed24fc (offen)

Verwendung

Die Funktion Csm_Hash berechnet einen kryptografischen Hashwert über die übergebenen Eingangsdaten und sichert das Ergebnis im Zielspeicher [SWS_Csm_00980]. Die Schnittstelle wird über den Header Csm.h deklariert und besitzt die Service-ID 0x5d [SWS_Csm_00980]. Das Ausführungsverhalten ist entweder synchron oder asynchron, was von der jeweiligen Konfiguration des über jobId angegebenen Jobs abhängt [SWS_Csm_00980].

Die Parameter gliedern sich wie folgt auf [SWS_Csm_00980]:

• jobId: Eindeutige Kennung des CSM-Jobs, der den kryptografischen Dienst in Anspruch nimmt.
• mode: Gibt an, welcher Operationsmodus bzw. welche Operationsmodi ausgeführt werden sollen.
• dataPtr und dataLength: Zeiger auf die zu hashenden Eingangsdaten sowie die Anzahl der zu verarbeitenden Bytes.
• resultPtr: Zeiger auf den Puffer, in dem der berechnete Hashwert gespeichert wird.
• resultLengthPtr: Vor dem Aufruf muss dieser Zeiger die bereitgestellte Kapazität des Puffers resultPtr in Bytes enthalten. Nach Abschluss der Verarbeitung wird dieser Wert durch die tatsächliche Bytelänge des erzeugten Hashwerts überschrieben. Ist der bereitgestellte Puffer kleiner als die Gesamtlänge des Ergebnisses, wird der Hashwert gekürzt abgelegt.

Fehlerbehandlung und Nebenläufigkeit

Der Rückgabewert vom Typ Std_ReturnType signalisiert mit E_OK eine erfolgreiche Anforderung und mit E_NOT_OK einen Fehler bei der Auftragsabwicklung [SWS_Csm_00980]. Hinsichtlich der Nebenläufigkeit ist Csm_Hash als reentrant spezifiziert [SWS_Csm_00980].

Die reentrante Funktion Csm_MacGenerate (Service-ID 0x60, Header Csm.h) berechnet einen Message Authentication Code (MAC) über die übergebenen Eingabedaten und speichert das Ergebnis an der angegebenen Zieladresse [SWS_Csm_00982]. Ob die Bearbeitung synchron oder asynchron erfolgt, hängt von der Konfiguration des über jobId referenzierten Jobs ab [SWS_Csm_00982].

Der Parameter mode spezifiziert die auszuführenden Operationsmodi. Eingangsdaten werden über dataPtr und deren Bytezahl über dataLength übergeben [SWS_Csm_00982]. Der Puffer macPtr nimmt das Ergebnis auf. Über den Ein- und Ausgangsparameter macLengthPtr muss beim Aufruf die Größe des bereitgestellten Puffers übergeben werden; nach Abschluss der Anfrage wird darin die tatsächliche Länge des berechneten MAC abgelegt. Ist der Puffer kleiner als das Gesamtergebnis, wird der MAC abgeschnitten gespeichert [SWS_Csm_00982].

Mögliche Rückgabewerte vom Typ Std_ReturnType sind [SWS_Csm_00982]:

• E_OK: Anfrage erfolgreich ausgeführt.
• E_NOT_OK: Anfrage fehlgeschlagen.
• CRYPTO_E_BUSY: Dienst ist noch belegt.
• CRYPTO_E_KEY_NOT_VALID: Status des Schlüssels ist ungültig.
• CRYPTO_E_KEY_SIZE_MISMATCH: Ein Schlüsselelement weist eine falsche Größe auf.
• CRYPTO_E_KEY_EMPTY: Das Quell-Schlüsselelement ist nicht initialisiert.

Die Funktion Csm_MacVerify dient gemäß [SWS_Csm_01050] der Verifikation eines Message Authentication Codes (MAC), indem geprüft wird, ob der übergebene MAC zu den bereitgestellten Daten passt. Das Ergebnis der Verifikation wird am Speicherort abgelegt, auf den verifyPtr verweist. Der Dienst ist über die Header-Datei Csm.h verfügbar und als reentrant spezifiziert.

Beim Aufruf sind folgende Parameter und Semantiken zu beachten [SWS_Csm_01050]:

• Synchrones oder asynchrones Verhalten: Die Ausführung erfolgt synchron oder asynchron in Abhängigkeit von der Konfiguration des über jobId referenzierten Jobs.
• Betriebsmodus: Über mode (Crypto_OperationModeType) wird festgelegt, welche Operationsmodi ausgeführt werden sollen.
• Längenangaben: Während dataLength die Anzahl der Datenbytes für dataPtr angibt, erfordert macLength zwingend die Länge des zu prüfenden MACs in Bits.

Als Rückgabewert liefert die Funktion den Status der Anforderung als Std_ReturnType [SWS_Csm_01050]:

• E_OK: Die Anforderung war erfolgreich.
• E_NOT_OK: Die Anforderung ist fehlgeschlagen.
• CRYPTO_E_BUSY: Der Dienst ist noch belegt.
• CRYPTO_E_KEY_NOT_VALID: Der Zustand des Schlüssels ist ungültig.
• CRYPTO_E_KEY_SIZE_MISMATCH: Ein Schlüsselelement weist eine falsche Größe auf.
• CRYPTO_E_KEY_EMPTY: Das Quellschlüsselelement ist uninitialisiert.

Die Funktion Csm_Encrypt (Service-ID 0x5e, bereitgestellt über Csm.h) verschlüsselt die übergebenen Eingangsdaten und legt das Chiffrat im angegebenen Ergebnispuffer ab [SWS_Csm_00984].

Verwendung und Semantik

Für die Durchführung der Operation werden folgende Parameter übergeben [SWS_Csm_00984]:

• jobId: Bezeichner des CSM-Jobs, der den Dienst nutzt.
• mode: Kennzeichnet den oder die auszuführenden Operationsmodi (vom Typ Crypto_OperationModeType).
• dataPtr und dataLength: Zeiger auf die zu verschlüsselnden Ausgangsdaten sowie die Anzahl der zu verarbeitenden Bytes.
• resultPtr: Zeiger auf den Speicherbereich, in dem die verschlüsselten Daten abgelegt werden.
• resultLengthPtr: Zeiger auf die Längeninformation in Bytes. Vor dem Aufruf muss dieser Parameter die bereitgestellte Pufferkapazität von resultPtr enthalten; nach Abschluss der Anfrage wird dort die tatsächliche Ausgabelänge gespeichert [SWS_Csm_00984].

Die Ausführungssemantik ist nicht statisch festgelegt: Sie erfolgt je nach Konfiguration des zugeordneten Jobs synchron oder asynchron [SWS_Csm_00984].

Nebenläufigkeit und Einschränkungen

Die Funktion ist als reentrant spezifiziert [SWS_Csm_00984]. Aufrufer müssen gewährleisten, dass der Puffer resultPtr während der gesamten Bearbeitung bis zur Vollendung der Operation gültig bleibt und mindestens die initial über resultLengthPtr angegebene Größe aufweist.

Fehlerbehandlung und Rückgabewerte

Der Rückgabewert vom Typ Std_ReturnType liefert Aufschluss über den Anforderungsstatus [SWS_Csm_00984]:

• E_OK: Anforderung erfolgreich.
• E_NOT_OK: Anforderung fehlgeschlagen.
• CRYPTO_E_BUSY: Anforderung abgewiesen, da der Dienst derzeit noch belegt ist.
• CRYPTO_E_KEY_NOT_VALID: Der angegebene Schlüssel befindet sich im Zustand „invalid“.
• CRYPTO_E_KEY_SIZE_MISMATCH: Ein Schlüsselelement weist eine ungültige Größe auf.
• CRYPTO_E_KEY_EMPTY: Ein uninitialisiertes Quell-Schlüsselelement wurde übergeben.

Die Funktion Csm_Decrypt ([SWS_Csm_00989]) entschlüsselt übergebene Chiffredaten und speichert den resultierenden Klartext im Zielspeicherbereich ab. Sie wird über den Header Csm.h bereitgestellt und führt kryptografische Operationen basierend auf der Konfiguration des übergebenen Jobs aus.

Verwendung und Parameter

Über den Parameter jobId wird der zu nutzende CSM-Job adressiert, während mode (Typ Crypto_OperationModeType) die auszuführende(n) Operationsphase(n) vorgibt ([SWS_Csm_00989]). Die zu entschlüsselnden Daten werden als Zeiger dataPtr mit der Bytezahl dataLength übergeben. Der Klartext wird in den durch resultPtr referenzierten Puffer geschrieben.

Der In-Out-Parameter resultLengthPtr steuert das Puffermanagement: Beim Aufruf muss er die bereitgestellte Puffergröße von resultPtr in Bytes enthalten; nach Abschluss der Operation wird dort die tatsächlich geschriebene Ausgabelänge hinterlegt ([SWS_Csm_00989]).

Ausführung und Rückgabewerte

Das Ausführungsverhalten (synchron oder asynchron) hängt direkt von der zugrunde liegenden Jobkonfiguration ab ([SWS_Csm_00989]). Die Funktion ist reentrant ausgelegt und liefert spezifische Rückgabewerte vom Typ Std_ReturnType zurück:

• E_OK: Die Anfrage war erfolgreich ([SWS_Csm_00989]).
• E_NOT_OK: Die Anfrage ist fehlgeschlagen ([SWS_Csm_00989]).
• CRYPTO_E_BUSY: Der angeforderte Dienst ist derzeit noch belegt ([SWS_Csm_00989]).
• CRYPTO_E_KEY_NOT_VALID: Der Status des verwendeten Schlüssels ist ungültig ([SWS_Csm_00989]).
• CRYPTO_E_KEY_SIZE_MISMATCH: Ein Schlüsselelement besitzt eine unpassende Größe ([SWS_Csm_00989]).
• CRYPTO_E_KEY_EMPTY: Das Quell-Schlüsselelement ist uninitialisiert ([SWS_Csm_00989]).

Verwendung

Die Funktion Csm_AEADEncrypt führt eine authentifizierte Verschlüsselung mit assoziierten Daten (AEAD) durch und ist über den Header Csm.h verfügbar [SWS_Csm_01023]. Sie verarbeitet über plaintextPtr und plaintextLength den zu verschlüsselnden Klartext sowie über associatedDataPtr und associatedDataLength zusätzliche assoziierte Daten [SWS_Csm_01023]. Die Ausgabedaten werden in die Puffer ciphertextPtr (Chiffretext) und tagPtr (Authentifizierungs-Tag bzw. MAC) geschrieben [SWS_Csm_01023]. Beim Aufruf müssen ciphertextLengthPtr und tagLengthPtr die bereitgestellte Pufferkapazität in Bytes enthalten; nach Abschluss enthalten sie die tatsächliche Länge der Ausgabewerte [SWS_Csm_01023] (Interpretation: Der in der Spezifikation genannte Parameter resultPtr dürfte sich redaktionell bedingt auf ciphertextPtr bzw. tagPtr beziehen). Frage Q-ea7e69875375c501 (offen) Über mode wird der durchzuführende Operationsmodus gewählt [SWS_Csm_01023]. Die Ausführung erfolgt synchron oder asynchron in Abhängigkeit von der Job-Konfiguration der übergebenen jobId [SWS_Csm_01023].

Fehlerbehandlung und Rückgabewerte

Der Dienst liefert über den Rückgabetyp Std_ReturnType folgende Statuswerte [SWS_Csm_01023]:

• E_OK: Die Anfrage war erfolgreich [SWS_Csm_01023].
• E_NOT_OK: Die Anfrage ist fehlgeschlagen [SWS_Csm_01023].
• CRYPTO_E_BUSY: Die Anfrage schlug fehl, da der Dienst belegt ist [SWS_Csm_01023].
• CRYPTO_E_KEY_NOT_VALID: Die Anfrage schlug fehl, da der Status des Schlüssels ungültig ist [SWS_Csm_01023].
• CRYPTO_E_KEY_SIZE_MISMATCH: Die Anfrage schlug fehl, da ein Schlüsselelement eine falsche Größe aufweist [SWS_Csm_01023].
• CRYPTO_E_KEY_EMPTY: Die Anfrage schlug fehl aufgrund eines uninitialisierten Quell-Schlüsselelements [SWS_Csm_01023].

Nebenläufigkeit

Die Schnittstelle ist als reentrant spezifiziert [SWS_Csm_01023].

Der Dienst Csm_AEADDecrypt (Service-ID 0x63, bereitgestellt über Csm.h) führt gemäß [SWS_Csm_01026] eine AEAD-Entschlüsselung (Authenticated Encryption with Associated Data) durch. Interpretation: Obwohl die Beschreibung im Spezifikationstext von einer Verschlüsselung spricht, dient die Funktion anhand der definierten Ein- und Ausgabeparameter der Entschlüsselung von Chiffretext sowie der Verifikation des übergebenen Authentifizierungstags. Frage Q-00e8fca03eb3b44d (offen)

Die Ausführung erfolgt je nach Konfiguration des über jobId identifizierten Jobs synchron oder asynchron ([SWS_Csm_01026]). Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant ([SWS_Csm_01026]). Über den Parameter mode wird vorgegeben, welche Operationsmodi abzuarbeiten sind.

Für den Aufruf gelten folgende Parameterbeziehungen ([SWS_Csm_01026]):

• Eingangsdaten: Zeiger und Längenangaben für Chiffretext (ciphertextPtr, ciphertextLength), assoziierte Daten (associatedDataPtr, associatedDataLength) und das zu prüfende Tag (tagPtr, tagLength).
• Ausgabedaten: Der Puffer plaintextPtr nimmt den entschlüsselten Klartext auf. Der Zeiger plaintextLengthPtr muss beim Aufruf die Pufferkapazität enthalten; nach Abschluss wird dort die tatsächliche Ausgabelänge hinterlegt.
• Verifikationsergebnis: Das Resultat der Tag-Prüfung wird über verifyPtr zurückgemeldet.

Als Rückgabewerte vom Typ Std_ReturnType sind nach [SWS_Csm_01026] spezifiziert:

• E_OK: Anfrage war erfolgreich.
• E_NOT_OK: Anfrage ist fehlgeschlagen.
• CRYPTO_E_BUSY: Dienst ist belegt.
• CRYPTO_E_KEY_NOT_VALID: Schlüsselstatus ist ungültig.
• CRYPTO_E_KEY_SIZE_MISMATCH: Schlüsselelement besitzt die falsche Größe.
• CRYPTO_E_KEY_EMPTY: Quell-Schlüsselelement ist nicht initialisiert.

Die Funktion Csm_SignatureGenerate dient der kryptografischen Signaturberechnung über übergebene Nutzdaten gemäß [SWS_Csm_00992]. Ob der Aufruf synchron oder asynchron verarbeitet wird, hängt von der jeweiligen Konfiguration des übergebenen Jobs (jobId) ab [SWS_Csm_00992]. Die Funktion ist als reentrant spezifiziert [SWS_Csm_00992].

Beim Aufruf steuert der Parameter mode vom Typ Crypto_OperationModeType die auszuführenden Operationsmodi [SWS_Csm_00992]. Die zu signierenden Daten werden über dataPtr zusammen mit ihrer Bytelänge dataLength übergeben [SWS_Csm_00992]. Die berechnete Signatur wird in den durch signaturePtr referenzierten Speicherbereich geschrieben [SWS_Csm_00992]. Der Ein-/Ausgabeparameter signatureLengthPtr muss vor dem Aufruf die bereitgestellte Puffergröße in Bytes enthalten; nach Abschluss der Anfrage enthält er die tatsächliche Bytelänge der erzeugten Signatur [SWS_Csm_00992].

Der Rückgabewert signalisiert den Status der Funktionsanforderung [SWS_Csm_00992]:

• E_OK: Anforderung erfolgreich ausgeführt bzw. gestartet [SWS_Csm_00992].
• E_NOT_OK: Allgemeine Fehler bei der Anfrage [SWS_Csm_00992].
• CRYPTO_E_BUSY: Der angeforderte Dienst ist derzeit belegt [SWS_Csm_00992].
• CRYPTO_E_KEY_NOT_VALID: Der Status des verwendeten Schlüssels ist ungültig [SWS_Csm_00992].
• CRYPTO_E_KEY_SIZE_MISMATCH: Ein Schlüsselelement weist eine unpassende Größe auf [SWS_Csm_00992].
• CRYPTO_E_KEY_EMPTY: Das Quell-Schlüsselelement ist nicht initialisiert [SWS_Csm_00992].

Der Dienst Csm_SignatureVerify (Service-ID 0x64, deklariert in Csm.h) dient der Verifikation einer kryptografischen Signatur anhand übergebener Daten [SWS_Csm_00996]. Die Spezifikation beschreibt die Funktionalität vergleichend als Prüfung, ob die Signatur (in der Beschreibung auch als MAC bezeichnet) mit den übergebenen Daten generiert wurde [SWS_Csm_00996].

Verwendung und Parameter: Beim Aufruf identifiziert jobId den konfigurierte CSM-Job, während mode (Typ Crypto_OperationModeType) die auszuführenden Operationsmodi vorgibt [SWS_Csm_00996]. Die zu prüfenden Nutzdaten werden über den Zeiger dataPtr mit der Byteanzahl dataLength übergeben [SWS_Csm_00996]. Die zu validierende Signatur wird über signaturePtr zusammen mit ihrer Bytelänge signatureLength bereitgestellt [SWS_Csm_00996]. Das Verifikationsergebnis speichert die Funktion an der durch den Ausgabeparameter verifyPtr (Typ Crypto_VerifyResultType*) referenzierten Speicherstelle [SWS_Csm_00996]. Das Ausführungsverhalten ist synchron oder asynchron, abhängig von der jeweiligen Job-Konfiguration [SWS_Csm_00996].

Fehlerbehandlung und Rückgabewerte: Die Funktion gibt einen Status vom Typ Std_ReturnType zurück, der den Erfolg oder spezifische Fehlerzustände der Anfrage signalisiert [SWS_Csm_00996]:

• E_OK: Die Dienstanforderung war erfolgreich [SWS_Csm_00996].
• E_NOT_OK: Die Dienstanforderung ist fehlgeschlagen [SWS_Csm_00996].
• CRYPTO_E_BUSY: Die Anfrage scheiterte, da der zugrundeliegende Dienst noch belegt ist [SWS_Csm_00996].
• CRYPTO_E_KEY_NOT_VALID: Die Anfrage schlug fehl, weil der Zustand des Schlüssels ungültig ist [SWS_Csm_00996].
• CRYPTO_E_KEY_SIZE_MISMATCH: Die Anfrage scheiterte, da ein Schlüsselelement die falsche Größe besitzt [SWS_Csm_00996].
• CRYPTO_E_KEY_EMPTY: Die Anfrage schlug fehl aufgrund eines uninitialisierten Quell-Schlüsselelements [SWS_Csm_00996].

Nebenläufigkeit: Gemäß Spezifikation ist die Funktion reentrant ausgeführt [SWS_Csm_00996].

Die Funktion Csm_RandomGenerate dient der Erzeugung von Zufallszahlen und speichert das Ergebnis in dem Speicherbereich, auf den resultPtr verweist [SWS_Csm_01543].

Verwendung und Parameter

Über den Parameter jobId wird die Kennung des konfigurieren CSM-Jobs übergeben, der den Dienst nutzt [SWS_Csm_01543]. Der Aufrufer steuert die gewünschte Datenmenge über den Ein- und Ausgangsparameter resultLengthPtr: Beim Aufruf muss dieser Zeiger auf die Anzahl der zu generierenden Zufallsbytes verweisen, die im Puffer resultPtr abgelegt werden sollen [SWS_Csm_01543]. Nach Abschluss der Anfrage enthält resultLengthPtr die tatsächliche Bytelänge des erzeugten Wertes [SWS_Csm_01543]. Die Verarbeitung erfolgt synchron oder asynchron, abhängig von der Konfiguration des jeweiligen Jobs [SWS_Csm_01543].

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert einen Status vom Typ Std_ReturnType zurück [SWS_Csm_01543]:

• E_OK: Die Anforderung war erfolgreich [SWS_Csm_01543].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_01543].
• CRYPTO_E_BUSY: Die Anforderung schlug fehl, da der Dienst noch belegt ist [SWS_Csm_01543].
• CRYPTO_E_ENTROPY_EXHAUSTED: Die Anforderung schlug fehl, da die Entropie des Zufallszahlengenerators erschöpft ist [SWS_Csm_01543].

Nebenläufigkeit

Die Funktion ist reentrant ausgelegt und über den Header Csm.h mit der Service-ID 0x72 verfügbar [SWS_Csm_01543].

Verwendung und Semantik

Die synchrone Funktion Csm_KeyElementSet setzt die Bytes eines spezifizierten Schlüsselelements für einen über keyId identifizierten Schlüssel [SWS_Csm_00957]. Die Funktion besitzt die Service-ID 0x78 und ist über den Header Csm.h verfügbar [SWS_Csm_00957]. Für den Aufruf werden folgende Eingangsparameter übergeben [SWS_Csm_00957]:

• keyId: Kennung des Schlüssels, für den neues Schlüsselmaterial gesetzt werden soll [SWS_Csm_00957].
• keyElementId: Kennung des zu beschreibenden Schlüsselelements [SWS_Csm_00957].
• keyElementPtr: Zeiger auf die zu verarbeitenden Bytes des Schlüsselelements [SWS_Csm_00957].
• keyElementLength: Anzahl der zu setzenden Bytes des Schlüsselelements [SWS_Csm_00957].

Rückgabewerte und Fehlerbehandlung

Die Ausführung liefert einen Status vom Typ Std_ReturnType zurück, der den Erfolg oder spezifische Fehlerursachen anzeigt [SWS_Csm_00957]:

• E_OK: Die Anforderung war erfolgreich [SWS_Csm_00957].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_00957].
• CRYPTO_E_BUSY: Das zuständige Crypto Driver Object ist belegt [SWS_Csm_00957].
• CRYPTO_E_KEY_WRITE_FAIL: Der Schreibzugriff auf das Schlüsselelement wurde verweigert [SWS_Csm_00957].
• CRYPTO_E_KEY_NOT_AVAILABLE: Der adressierte Schlüssel ist nicht verfügbar [SWS_Csm_00957].
• CRYPTO_E_KEY_SIZE_MISMATCH: Die Größe des Schlüsselelements stimmt nicht mit der Größe der bereitgestellten Daten überein [SWS_Csm_00957].

Nebenläufigkeit und Einschränkungen

Die Funktion Csm_KeyElementSet ist als synchron und nicht reentrant (Non Reentrant) spezifiziert [SWS_Csm_00957]. Sie besitzt keine Ein-/Ausgabe- (inout) oder Ausgabeparameter (out) [SWS_Csm_00957].

Die synchrone Funktion Csm_KeySetValid dient dazu, den Schlüsselzustand eines über die Kennung keyId adressierten Schlüssels auf gültig („valid“) zu setzen, nachdem neues Schlüsselmaterial bereitgestellt wurde [SWS_Csm_00958]. Der Dienst wird über den Header Csm.h bereitgestellt und besitzt die Service-ID 0x67 [SWS_Csm_00958].

Für die Verwendung und Rückgabewerte gelten folgende Festlegungen gemäß [SWS_Csm_00958]:

• Eingabeparameter: Über keyId wird der Bezeichner des Schlüssels übergeben, für den das neue Material validiert werden soll.
• Rückgabewert E_OK: Die Anforderung zur Validierung des Schlüsselzustands war erfolgreich.
• Rückgabewert E_NOT_OK: Die Anforderung ist fehlgeschlagen.
• Rückgabewert CRYPTO_E_BUSY: Die Anfrage schlug fehl, da das zugrunde liegende Crypto Driver Object belegt ist.

Hinsichtlich der Nebenläufigkeit ist Csm_KeySetValid als nicht reentrant („Non Reentrant“) spezifiziert [SWS_Csm_00958]. Aufrufer dürften daher für eine geeignete Synchronisation sorgen müssen, falls Aufrufe potenziell aus nebenläufigen Kontexten erfolgen. Frage Q-1762a3bca77ab74e (offen)

Die synchrone Funktion Csm_KeySetInvalid setzt den Status eines Schlüssels auf ungültig [SWS_Csm_91075]. Ein ungültig gesetzter Schlüssel kann so lange nicht mehr für kryptografische Operationen verwendet werden, bis er erneut in einen gültigen Zustand überführt wurde [SWS_Csm_91075].

Verwendung und Parameter

Der Aufruf steht über den Header Csm.h zur Verfügung und wird synchron ausgeführt [SWS_Csm_91075]. Über den Eingabeparameter keyId (Typ uint32) wird die Kennung des Schlüssels übergeben, der invalidiert werden soll [SWS_Csm_91075].

Rückgabewerte und Fehlerbehandlung

Die Funktion gibt einen Statuswert vom Typ Std_ReturnType zurück [SWS_Csm_91075]:

• E_OK: Die Anforderung zur Invalidierung war erfolgreich [SWS_Csm_91075].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_91075].
• CRYPTO_E_BUSY: Die Anforderung ist fehlgeschlagen, da das Krypto-Treiber-Objekt belegt ist [SWS_Csm_91075].

Nebenläufigkeit und Einschränkungen

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Csm_91075]. Aufrufer müssen daher sicherstellen, dass Aufrufe nicht unterbrechend oder unkoordiniert parallel erfolgen. Ist das zuständige Krypto-Treiber-Objekt zum Aufrufzeitpunkt beschäftigt, wird die Operation mit CRYPTO_E_BUSY abgewiesen [SWS_Csm_91075].

Verwendung

Die synchrone Funktion Csm_KeyGetStatus dient dazu, den aktuellen Status eines über seinen Bezeichner spezifizierten Schlüssels abzufragen [SWS_Csm_91047]. Die Deklaration ist über den Header Csm.h verfügbar [SWS_Csm_91047].

Beim Aufruf werden folgende Parameter übergeben [SWS_Csm_91047]:

• keyId (Eingang): Identifikator des Schlüssels, dessen Status ermittelt werden soll.
• keyStatusPtr (Ausgang): Zeiger auf eine Speicherstelle vom Typ Crypto_KeyStatusType, an der das CSM den ermittelten Schlüsselstatus ablegt.

Als Rückgabewert liefert die Funktion Std_ReturnType [SWS_Csm_91047]:

• E_OK: Die Statusabfrage war erfolgreich und das Ergebnis steht über den Ausgabepointer bereit.
• E_NOT_OK: Die Anfrage ist fehlgeschlagen.

Nebenläufigkeit und Verhalten

Die Servicefunktion besitzt die Service-ID 0x83 und ist als reentrant spezifiziert [SWS_Csm_91047]. Da der Ablauf synchron erfolgt, blockiert der Aufruf den Aufrufer bis zur Fertigstellung der Statusermittlung [SWS_Csm_91047]. Ein gültiger Speicherbereich für keyStatusPtr muss vom Aufrufer bereitgestellt werden, da ungültige Zeiger vermutlich zum Rückgabewert E_NOT_OK führen. Frage Q-a920a9a12b1374aa (offen)

Die synchrone und reentrante Funktion Csm_KeyElementGet liest die Daten eines spezifischen Schlüsselelements aus dem über keyId identifizierten Schlüssel aus und kopiert diese in den übergebenen Speicherbereich [SWS_Csm_00959]. Der Dienst wird über die Header-Datei Csm.h deklariert und besitzt die Service-ID 0x68 [SWS_Csm_00959].

Parameter und Pufferhandhabung

Zur Identifikation des Elements werden die Parameter keyId (Identifikator des Schlüssels) und keyElementId (Identifikator des gewünschten Schlüsselelements) übergeben [SWS_Csm_00959]. Das Auslesen erfordert die Bereitstellung eines Ausgabepuffers sowie dessen Längenverwaltung:

• keyElementPtr: Zeiger auf den Speicherort, an den die extrahierten Bytes des Schlüsselelements kopiert werden [SWS_Csm_00959].
• keyElementLengthPtr: Ein Ein-/Ausgabeparameter (inout), der beim Funktionsaufruf die maximal verfügbare Puffergröße von keyElementPtr in Bytes enthalten muss. Nach Abschluss der Verarbeitung speichert die Funktion hier die tatsächlich geschriebene Bytelänge ab [SWS_Csm_00959].

Rückgabewerte und Fehleranalyse

Die Funktion liefert als Std_ReturnType spezifische Statuscodes zurück, um den Ausgang der Operation anzuzeigen [SWS_Csm_00959]:

• E_OK: Der Kopiervorgang des Schlüsselelements war erfolgreich [SWS_Csm_00959].
• E_NOT_OK: Die Anfrage ist allgemein fehlgeschlagen [SWS_Csm_00959].
• CRYPTO_E_BUSY: Die Anfrage scheiterte, da das betroffene Crypto Driver Object derzeit belegt ist [SWS_Csm_00959].
• CRYPTO_E_KEY_NOT_AVAILABLE: Das über keyElementId angeforderte Schlüsselelement ist nicht verfügbar [SWS_Csm_00959].
• CRYPTO_E_KEY_READ_FAIL: Der Lesezugriff auf das Schlüsselelement wurde verweigert [SWS_Csm_00959].
• CRYPTO_E_KEY_EMPTY: Das angeforderte Quell-Schlüsselelement ist nicht initialisiert [SWS_Csm_00959].

Die synchrone Funktion Csm_KeyElementCopyManager dient dazu, ein einzelnes Schlüsselelement aus einem Quellschlüssel in ein Zielelement eines Zielschlüssels zu kopieren [SWS_Csm_00969]. Der Aufruf wird über die Header-Datei Csm.h mit der Service-ID 0x71 bereitgestellt und erfordert vier Eingabeparameter: keyId und keyElementId zur Identifikation des Quell-Schlüsselelements sowie targetKeyId und targetKeyElementId für das Ziel [SWS_Csm_00969].

Hinsichtlich der Nebenläufigkeit ist der Dienst reentrant ausgelegt, jedoch explizit nicht für dieselbe keyId [SWS_Csm_00969]. Parallele Zugriffe auf denselben Quellschlüssel müssen daher vom Aufrufer vermieden oder synchronisiert werden.

Die Funktion gibt einen Status vom Typ Std_ReturnType zurück. Bei erfolgreicher Durchführung liefert sie E_OK [SWS_Csm_00969]. Im Fehlerfall stehen spezifische Rückgabewerte zur Ursachenanalyse zur Verfügung [SWS_Csm_00969]:

• CRYPTO_E_BUSY: Das zugrundeliegende Crypto-Treiber-Objekt ist belegt [SWS_Csm_00969].
• CRYPTO_E_KEY_NOT_AVAILABLE: Das angeforderte Schlüsselelement ist nicht verfügbar [SWS_Csm_00969].
• CRYPTO_E_KEY_READ_FAIL: Das Auslesen des Quellelements ist nicht gestattet [SWS_Csm_00969].
• CRYPTO_E_KEY_WRITE_FAIL: Das Schreiben in das Zielelement ist nicht gestattet [SWS_Csm_00969].
• CRYPTO_E_KEY_SIZE_MISMATCH: Die Größen der beiden Schlüsselelemente sind zueinander inkompatibel [SWS_Csm_00969].
• CRYPTO_E_KEY_EMPTY: Das Quellschlüsselelement ist noch uninitialisiert [SWS_Csm_00969].
• E_NOT_OK: Allgemeine Fehler bei der Anfrageausführung [SWS_Csm_00969].

Verwendung

Die synchrone Servicefunktion Csm_KeyCopy mit der Service-ID 0x73 dient dem vollständigen Kopieren aller Schlüsselelemente von einem Quellschlüssel zu einem Zielschlüssel [SWS_Csm_01034]. Die Deklaration wird über die Header-Datei Csm.h zur Verfügung gestellt [SWS_Csm_01034]. Als unveränderliche Eingangsparameter werden keyId für den Bezeichner des Quellschlüssels und targetKeyId für den Bezeichner des Zielschlüssels übergeben [SWS_Csm_01034]. Zusätzliche Ein-/Ausgangs- oder Ausgangsparameter sind in der Signatur nicht definiert [SWS_Csm_01034].

Fehlerbehandlung und Rückgabewerte

Der Rückgabewert vom Typ Std_ReturnType informiert den Aufrufer über das Ergebnis der Ausführung [SWS_Csm_01034]. Während E_OK eine erfolgreiche Durchführung signalisiert, kennzeichnet E_NOT_OK ein allgemeines Fehlschlagen der Anfrage [SWS_Csm_01034]. Spezifische Fehlerursachen werden durch gesonderte Krypto-Rückgabewerte angezeigt [SWS_Csm_01034]:

• CRYPTO_E_BUSY: Die Operation scheiterte, da das Crypto-Driver-Objekt belegt ist.
• CRYPTO_E_KEY_NOT_AVAILABLE: Das angeforderte Schlüsselelement ist nicht verfügbar.
• CRYPTO_E_KEY_READ_FAIL: Das Auslesen des Schlüsselelements aus der Quelle ist nicht gestattet.
• CRYPTO_E_KEY_WRITE_FAIL: Das Schreiben des Schlüsselelements in das Ziel ist nicht gestattet.
• CRYPTO_E_KEY_SIZE_MISMATCH: Die Größen der beteiligten Schlüsselelemente sind nicht miteinander kompatibel.
• CRYPTO_E_KEY_EMPTY: Das Schlüsselelement des Quellschlüssels ist nicht initialisiert.

Nebenläufigkeit und Einschränkungen

Hinsichtlich des Aufrufverhaltens ist Csm_KeyCopy reentrant ausgelegt, allerdings mit der bindenden Einschränkung, dass dies nicht für dieselbe keyId gilt [SWS_Csm_01034].

Die synchrone Funktion Csm_KeyElementCopyPartial kopiert einen definierten Teilbereich eines Schlüsselelements in ein anderes Schlüsselelement innerhalb desselben Crypto-Treibers [SWS_Csm_91025]. Über die Parameter keyElementSourceOffset und keyElementCopyLength wird bestimmt, ab welchem Byte und in welcher Länge das Quell-Element (identifiziert durch keyId und keyElementId) kopiert wird. Die Startposition im Ziel-Element (targetKeyId, targetKeyElementId) wird über keyElementTargetOffset angegeben [SWS_Csm_91025].

Der Rückgabewert liefert den Ausführungsstatus sowie spezifische Fehlerursachen [SWS_Csm_91025]:

• E_OK: Der Kopiervorgang wurde erfolgreich ausgeführt.
• CRYPTO_E_BUSY: Das Crypto-Driver-Objekt ist belegt.
• CRYPTO_E_KEY_NOT_AVAILABLE: Das angeforderte Schlüsselelement ist nicht verfügbar.
• CRYPTO_E_KEY_READ_FAIL: Das Auslesen des Quell-Schlüsselelements ist nicht gestattet.
• CRYPTO_E_KEY_WRITE_FAIL: Das Beschreiben des Ziel-Schlüsselelements ist nicht gestattet.
• CRYPTO_E_KEY_SIZE_MISMATCH: Die Größen der beteiligten Schlüsselelemente sind inkompatibel.
• CRYPTO_E_KEY_EMPTY: Das Quell-Schlüsselelement ist uninitialisiert.
• E_NOT_OK: Die Anfrage ist aus allgemeinen Gründen fehlgeschlagen.

Die Funktion ist reentrant implementiert, darf jedoch nicht zeitgleich für dieselbe keyId aufgerufen werden [SWS_Csm_91025]. Zudem setzt die Schnittstelle voraus, dass Quelle und Ziel im selben Crypto-Treiber verwaltet werden [SWS_Csm_91025]. Die Deklaration ist über den Header Csm.h verfügbar [SWS_Csm_91025].

Verwendung und Aufrufkontext

Die synchrone Funktion Csm_RandomSeed dient dazu, das Schlüsselelement CRYPTO_KE_RANDOM_SEED eines Schlüssels mit einem übergebenen Zufallswert (Seed) zu befüllen [SWS_Csm_01051]. Beim Aufruf werden über keyId der Bezeichner des Zielschlüssels, über seedPtr der Zeiger auf die Speicherstelle mit den Seed-Daten und über seedLength die Länge des Seeds in Bytes übergeben [SWS_Csm_01051].

Zusammenspiel

Erkennt der CSM bei der Ausführung keine Fehler, leitet die Funktion Csm_RandomSeed den Dienstaufruf direkt an CryIf_RandomSeed der Crypto Interface weiter [SWS_Csm_01052].

Fehlerbehandlung und Rückgabewerte

Die Funktion gibt einen Statuswert vom Typ Std_ReturnType zurück [SWS_Csm_01051]:

• E_OK: Die Anforderung war erfolgreich [SWS_Csm_01051].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_01051].
• CRYPTO_E_BUSY: Die Ausführung schlug fehl, da das entsprechende Crypto Driver Object aktuell belegt ist [SWS_Csm_01051].
• CRYPTO_E_KEY_NOT_VALID: Die Anforderung wurde abgewiesen, weil der Zustand des Schlüssels ungültig ist [SWS_Csm_01051].

Nebenläufigkeit und Einschränkungen

Hinsichtlich des Nebenläufigkeitsverhaltens ist Csm_RandomSeed reentrant implementiert, darf allerdings nicht zeitgleich für dieselbe keyId aufgerufen werden [SWS_Csm_01051].

Die synchrone Funktion Csm_KeyGenerate dient der Erzeugung von neuem kryptografischem Schlüsselmaterial und speichert dieses direkt in dem über den Parameter keyId festgelegten Schlüssel [SWS_Csm_00955]. Die Schnittstelle wird über die Header-Datei Csm.h bereitgestellt und besitzt die Service-ID 0x6a [SWS_Csm_00955].

Beim Aufruf übergibt die Anwendung die Kennung keyId (Typ uint32) des Schlüssels, für den das Material generiert werden soll; Ein-/Ausgabe- oder reine Ausgabeparameter existieren nicht [SWS_Csm_00955]. Der Status der Operation wird synchron über den Rückgabewert vom Typ Std_ReturnType gemeldet [SWS_Csm_00955]:

• E_OK: Die Generierung und Speicherung des Schlüsselmaterials war erfolgreich [SWS_Csm_00955].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_00955].
• CRYPTO_E_BUSY: Die Ausführung schlug fehl, da das zuständige Crypto-Treiber-Objekt derzeit belegt ist [SWS_Csm_00955].
• CRYPTO_E_KEY_NOT_VALID: Die Anforderung wurde abgewiesen, da sich der Zielschlüssel im Zustand „invalid“ befindet [SWS_Csm_00955].
• CRYPTO_E_KEY_EMPTY: Die Erzeugung scheiterte aufgrund eines uninitialisierten Quellschlüsselelements [SWS_Csm_00955].

Hinsichtlich der Nebenläufigkeit ist Csm_KeyGenerate reentrant ausgelegt, darf jedoch nicht nebenläufig für dieselbe keyId aufgerufen werden [SWS_Csm_00955].

Die synchrone Funktion Csm_KeyDerive dient der Ableitung eines neuen kryptografischen Schlüssels aus einem vorgegebenen Ausgangsschlüssel [SWS_Csm_00956]. Die Funktion ist in der Header-Datei Csm.h deklariert und besitzt die Service-ID 0x6b [SWS_Csm_00956].

Verwendung und Parameter

Der synchrone Aufruf verarbeitet zwei Eingangsparameter [SWS_Csm_00956]:

• keyId: Kennung des Ausgangsschlüssels, der die Schlüsselelemente für Passwort und Salt enthält [SWS_Csm_00956].
• targetKeyId: Kennung des Zielschlüssels; das abgeleitete Schlüsselmaterial wird im Schlüsselelement mit der ID 1 abgelegt [SWS_Csm_00956].

Rückgabewerte und Fehlerbehandlung

Als Rückgabewert liefert die Funktion den Status Std_ReturnType [SWS_Csm_00956]. Neben E_OK bei erfolgreicher Durchführung und E_NOT_OK bei allgemeinen Fehlern sind spezifische Krypto-Fehler definiert [SWS_Csm_00956]:

• CRYPTO_E_BUSY: Das Crypto-Treiber-Objekt ist ausgelastet [SWS_Csm_00956].
• CRYPTO_E_KEY_READ_FAIL: Auslesen des Schlüsselelements ist nicht erlaubt [SWS_Csm_00956].
• CRYPTO_E_KEY_WRITE_FAIL: Schreiben in das Zielschlüsselelement ist nicht erlaubt [SWS_Csm_00956].
• CRYPTO_E_KEY_NOT_VALID: Der Zustand des Schlüssels ist ungültig [SWS_Csm_00956].
• CRYPTO_E_KEY_SIZE_MISMATCH: Größen der Schlüsselelemente sind inkompatibel [SWS_Csm_00956].
• CRYPTO_E_KEY_EMPTY: Das Schlüsselelement der Quelle ist uninitialisiert [SWS_Csm_00956].

Nebenläufigkeit und Zusammenspiel

Die Funktion ist reentrant, jedoch ausdrücklich nicht für dieselbe keyId [SWS_Csm_00956]. Werden im CSM keine Fehler festgestellt, leitet der Dienst die Ausführung unmittelbar an CryIf_KeyDerive weiter [SWS_Csm_01018].

Die synchrone Schnittstelle Csm_KeyExchangeCalcPubVal (Service-ID 0x6c, verfügbar über Csm.h) berechnet den öffentlichen Wert des aktuellen Benutzers für das Schlüsselaustauschprotokoll und speichert den öffentlichen Schlüssel an der durch den Zeiger publicValuePtr referenzierten Speicheradresse [SWS_Csm_00966].

Parameter und Pufferverwaltung

Die Funktion verarbeitet drei Übergabeparameter [SWS_Csm_00966]:

• keyId (Eingabe): Enthält die Kennung des Schlüssels, der für das Schlüsselaustauschprotokoll verwendet werden soll [SWS_Csm_00966].
• publicValuePtr (Ausgabe): Zeiger auf den Speicherbereich, in dem der resultierende öffentliche Schlüsselwert abgelegt wird [SWS_Csm_00966].
• publicValueLengthPtr (Ein-/Ausgabe): Zeiger auf die Längeninformation. Beim Aufruf muss dieser Parameter die bereitgestellte Größe des Puffers publicValuePtr enthalten; nach Abschluss der Ausführung wird dort die tatsächliche Länge des berechneten Werts gespeichert [SWS_Csm_00966].

Fehlerbehandlung und Rückgabewerte

Der Ausführungsstatus wird über Std_ReturnType zurückgemeldet [SWS_Csm_00966]:

• E_OK: Die Anfrage war erfolgreich [SWS_Csm_00966].
• E_NOT_OK: Die Anfrage ist fehlgeschlagen [SWS_Csm_00966].
• CRYPTO_E_BUSY: Die Anfrage ist fehlgeschlagen, da das Crypto-Treiber-Objekt belegt ist [SWS_Csm_00966].
• CRYPTO_E_KEY_NOT_VALID: Die Anfrage schlägt fehl, da der Status des Schlüssels ungültig ist [SWS_Csm_00966].
• CRYPTO_E_KEY_EMPTY: Die Anfrage schlägt aufgrund eines uninitialisierten Quellschlüsselelements fehl [SWS_Csm_00966].

Nebenläufigkeit

Die Funktion ist reentrant ausgelegt, darf jedoch nicht zeitgleich für dieselbe keyId aufgerufen werden [SWS_Csm_00966].

Die synchrone Funktion Csm_KeyExchangeCalcSecret dient im Crypto Service Manager der Berechnung eines gemeinsamen Geheimnisses (Shared Secret Key) im Rahmen eines Schlüsselaustauschprotokolls [SWS_Csm_00967]. Hierbei wird das Schlüsselmaterial des über keyId referenzierten Schlüssels mit dem öffentlichen Wert des Kommunikationspartners kombiniert. Der berechnete geheime Schlüssel wird anschließend direkt als Schlüsselelement innerhalb desselben Schlüssels hinterlegt [SWS_Csm_00967].

Die Schnittstelle wird über den Header Csm.h bereitgestellt und erwartet drei Eingabeparameter [SWS_Csm_00967]:

• keyId: Kennung des Schlüssels, dessen Schlüsselmaterial für das Protokoll verwendet wird.
• partnerPublicValuePtr: Zeiger auf den Speicherbereich, der den öffentlichen Wert des Partners enthält.
• partnerPublicValueLength: Länge des übergebenen Partnerwerts in Bytes.

Der Aufruf liefert als Rückgabewert vom Typ Std_ReturnType entweder E_OK bei erfolgreicher Ausführung oder E_NOT_OK bei einem allgemeinen Fehler [SWS_Csm_00967]. Spezifische Fehlerfälle signalisieren detaillierte Statuscodes: CRYPTO_E_BUSY zeigt an, dass das zugrunde liegende Crypto-Driver-Objekt belegt ist. Ist der Zustand des Schlüssels ungültig, wird CRYPTO_E_KEY_NOT_VALID zurückgegeben, während CRYPTO_E_KEY_EMPTY auf ein uninitialisiertes Quell-Schlüsselelement hinweist [SWS_Csm_00967].

Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant ausgelegt, darf jedoch nicht zeitgleich für dieselbe keyId aufgerufen werden [SWS_Csm_00967].

Verwendung

Die Funktion Csm_JobKeySetValid speichert den Schlüssel bei Bedarf und setzt den Schlüsselzustand des über keyId identifizierten Schlüssels auf gültig [SWS_Csm_91027]. Die Schnittstelle ist über die Header-Datei Csm.h deklariert und besitzt die Service-ID 0x7a mit der Signatur Std_ReturnType Csm_JobKeySetValid (uint32 jobId, uint32 keyId) [SWS_Csm_91027].

Beim Aufruf werden zwei Eingabeparameter vom Typ uint32 übergeben [SWS_Csm_91027]:

• jobId: Hält den Identifikator des Jobs, der den CSM-Dienst verwendet [SWS_Csm_91027].
• keyId: Hält den Identifikator des Schlüssels, für den neues Schlüsselmaterial validiert werden soll [SWS_Csm_91027].

Zusätzliche Ein-/Ausgabeparameter oder reine Ausgabeparameter sind für diese Funktion nicht definiert [SWS_Csm_91027].

Synchrones und asynchrones Verhalten sowie Nebenläufigkeit

Die Ausführungssemantik ist von der jeweiligen Job-Konfiguration abhängig: Der Aufruf erfolgt entweder synchron oder asynchron [SWS_Csm_91027]. Die Funktion ist als reentrant spezifiziert [SWS_Csm_91027].

Rückgabewerte und Fehlerbehandlung

Der Rückgabewert vom Typ Std_ReturnType spiegelt das Ergebnis der Funktionsanfrage wider [SWS_Csm_91027]:

• E_OK: Die Anfrage war erfolgreich [SWS_Csm_91027].
• E_NOT_OK: Die Anfrage ist fehlgeschlagen [SWS_Csm_91027].
• CRYPTO_E_BUSY: Die Anfrage ist fehlgeschlagen, da das zuständige Crypto Driver Object belegt ist [SWS_Csm_91027].

Verwendung

Die Funktion Csm_JobKeySetInvalid setzt den Status eines kryptografischen Schlüssels auf ungültig [SWS_Csm_91002]. Nach Aufruf dieser Schnittstelle kann der betreffende Schlüssel nicht mehr für kryptografische Operationen genutzt werden, bis er erneut in einen gültigen Zustand versetzt worden ist [SWS_Csm_91002]. Der Dienst besitzt die Service-ID 0x84, ist über die Header-Datei Csm.h verfügbar und arbeitet abhängig von der Job-Konfiguration entweder synchron oder asynchron [SWS_Csm_91002].

Für den Aufruf werden folgende Parameter übergeben [SWS_Csm_91002]:

• jobId: Kennung des CSM-Jobs, welcher diesen Service verwendet [SWS_Csm_91002].
• keyId: Kennung des Schlüssels, der invalidiert werden soll [SWS_Csm_91002].

Fehlerbehandlung und Rückgabewerte

Der Rückgabewert vom Typ Std_ReturnType meldet das Ergebnis der Anforderung [SWS_Csm_91002]:

• E_OK: Die Anforderung war erfolgreich [SWS_Csm_91002].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_91002].
• CRYPTO_E_BUSY: Die Anforderung schlug fehl, da das zuständige Crypto Driver Object belegt ist [SWS_Csm_91002].

Nebenläufigkeit

Die Schnittstelle ist als reentrant spezifiziert [SWS_Csm_91002]. Zusätzliche Ein- oder Ausgabeparameter existieren nicht [SWS_Csm_91002].

Verwendung und Aufrufkontext

Die Funktion Csm_JobRandomSeed dient dazu, einen neuen Seed für einen festgelegten Schlüssel bereitzustellen, welcher für einen zugeordneten Zufallszahlengenerator verwendet wird [SWS_Csm_91028]. Die Deklaration ist im Header Csm.h verfügbar [SWS_Csm_91028]. Die Funktion besitzt die Service-ID 0x7b und verarbeitet vier Eingangsparameter: Über jobId wird der nutzende CSM-Job identifiziert, während keyId den Zielschlüssel bestimmt, für den der Seed generiert werden soll [SWS_Csm_91028]. Über den Zeiger seedPtr werden die Initialisierungsdaten übergeben und mit seedLength deren Länge in Bytes festgelegt [SWS_Csm_91028]. Das Ausführungsverhalten richtet sich nach der Konfiguration des jeweiligen Jobs und erfolgt entweder synchron oder asynchron [SWS_Csm_91028].

Fehlerbehandlung und Rückgabewerte

Die Funktion liefert einen Status vom Typ Std_ReturnType zurück, der das Ergebnis der Anforderung anzeigt [SWS_Csm_91028]:

• E_OK: Die Anforderung war erfolgreich [SWS_Csm_91028].
• E_NOT_OK: Die Anforderung ist allgemein fehlgeschlagen [SWS_Csm_91028].
• CRYPTO_E_BUSY: Die Anforderung schlug fehl, da der Dienst derzeit noch beschäftigt ist [SWS_Csm_91028].
• CRYPTO_E_KEY_NOT_VALID: Die Anforderung wurde abgewiesen, da sich der spezifizierte Schlüssel im Zustand invalid befindet [SWS_Csm_91028].

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als reentrant spezifiziert [SWS_Csm_91028]. Ruft eine Anwendung den Dienst auf, während eine andere Operation noch aktiv ist, signalisiert der Rückgabewert CRYPTO_E_BUSY diesen Zustand [SWS_Csm_91028]. Zudem muss vor der Ausführung sichergestellt sein, dass der über keyId adressierte Schlüssel gültig ist, um den Fehler CRYPTO_E_KEY_NOT_VALID zu vermeiden [SWS_Csm_91028].

Verwendung

Die Funktion Csm_JobKeyGenerate generiert neues Schlüsselmaterial und speichert dieses in dem über keyId identifizierten Schlüssel [SWS_Csm_91029]. Über den Parameter jobId wird die Kennung des Jobs übergeben, welcher den CSM-Dienst nutzt [SWS_Csm_91029]. Die Ausführung erfolgt abhängig von der Konfiguration des jeweiligen Jobs synchron oder asynchron [SWS_Csm_91029]. Deklariert ist der Dienst über die Header-Datei Csm.h mit der Service-ID 0x7c [SWS_Csm_91029].

Rückgabewerte und Fehlerbehandlung

Der Rückgabewert vom Typ Std_ReturnType gibt Auskunft über das Ergebnis der Anforderung [SWS_Csm_91029]:

• E_OK: Die Anforderung war erfolgreich [SWS_Csm_91029].
• E_NOT_OK: Die Anforderung ist fehlgeschlagen [SWS_Csm_91029].
• CRYPTO_E_BUSY: Der Dienst ist gegenwärtig noch belegt [SWS_Csm_91029].
• CRYPTO_E_KEY_NOT_VALID: Der Zustand des Schlüssels ist ungültig (invalid) [SWS_Csm_91029].
• CRYPTO_E_KEY_EMPTY: Die Anforderung schlug wegen eines nicht initialisierten Quellschlüsselelements fehl [SWS_Csm_91029].

Nebenläufigkeit und Einschränkungen

Die Funktion ist als reentrant spezifiziert [SWS_Csm_91029]. Interpretation: Da die Spezifikation keinen spezifischen Ausführungskontext vorgibt, dürfte der Aufruf typischerweise im Task-Kontext erfolgen. Frage Q-236d699ed655e285 (offen)

Verwendung und Semantik

Die Funktion Csm_JobKeyDerive leitet einen neuen kryptografischen Schlüssel ab, indem sie die Schlüsselelemente für Passwort und Salt aus dem durch keyId identifizierten Schlüssel verwendet [SWS_Csm_91030]. Das Ergebnis wird im Schlüsselelement mit der ID 1 des durch targetKeyId festgelegten Zielschlüssels abgelegt [SWS_Csm_91030]. Der Aufruf erfolgt über die Header-Datei Csm.h mit der Service-ID 0x7d unter Übergabe des jeweiligen Jobs via jobId [SWS_Csm_91030].

Die Verarbeitung erfolgt je nach Konfiguration des übergebenen Jobs entweder synchron oder asynchron [SWS_Csm_91030]. Die Funktion ist als reentrant spezifiziert [SWS_Csm_91030].

Fehlerbehandlung und Rückgabewerte

Als Rückgabewert liefert die Funktion den Typ Std_ReturnType. Eine erfolgreiche Ausführung der Anfrage wird durch E_OK bestätigt [SWS_Csm_91030]. Im Fehlerfall oder bei unpassenden Vorbedingungen werden spezifische Rückgabewerte gemeldet [SWS_Csm_91030]:

• E_NOT_OK: Die Anfrage ist fehlgeschlagen [SWS_Csm_91030].
• CRYPTO_E_BUSY: Die Anfrage scheitert, da der Dienst aktuell noch ausgelastet ist [SWS_Csm_91030].
• CRYPTO_E_KEY_READ_FAIL: Das Auslesen des Schlüsselelements ist nicht zulässig [SWS_Csm_91030].
• CRYPTO_E_KEY_WRITE_FAIL: Das Schreiben in das Ziel-Schlüsselelement ist nicht gestattet [SWS_Csm_91030].
• CRYPTO_E_KEY_NOT_VALID: Der Zustand des Schlüssels ist ungültig [SWS_Csm_91030].
• CRYPTO_E_KEY_SIZE_MISMATCH: Die beteiligten Schlüsselelement-Größen sind zueinander nicht kompatibel [SWS_Csm_91030].
• CRYPTO_E_KEY_EMPTY: Das Quell-Schlüsselelement ist uninitialisiert [SWS_Csm_91030].

Verwendung

Die Funktion Csm_JobKeyExchangeCalcPubVal berechnet den öffentlichen Wert des aktuellen Teilnehmers für das Schlüsselaustausch-Protokoll und legt diesen im angegebenen Zielspeicher ab [SWS_Csm_91031]. Abhängig von der Konfiguration des zugeordneten Jobs erfolgt die Verarbeitung entweder synchron oder asynchron [SWS_Csm_91031].

Die Übergabe der Parameter erfolgt über folgende Schnittstellendaten [SWS_Csm_91031]:

• jobId: Bezeichner des CSM-Jobs, der den kryptografischen Dienst in Anspruch nimmt.
• keyId: Bezeichner des Schlüssels, welcher für das Schlüsselaustausch-Protokoll verwendet wird.
• publicValuePtr: Zeiger auf den Pufferbereich, in dem der berechnete öffentliche Schlüssel abgelegt wird.
• publicValueLengthPtr: Zeiger auf die Längenangabe. Beim Funktionsaufruf muss dieser Parameter die Kapazität des Puffers publicValuePtr enthalten; nach Abschluss der Ausführung wird die tatsächliche Länge des berechneten Werts eingetragen.

Fehlerbehandlung

Der Rückgabewert vom Typ Std_ReturnType gibt Auskunft über den Ausführungsstatus der Anforderung [SWS_Csm_91031]:

• E_OK: Anforderung wurde erfolgreich ausgeführt.
• E_NOT_OK: Anforderung ist fehlgeschlagen.
• CRYPTO_E_BUSY: Der angeforderte Dienst ist derzeit noch belegt.
• CRYPTO_E_KEY_NOT_VALID: Der Schlüsselzustand ist ungültig.
• CRYPTO_E_KEY_EMPTY: Das Quell-Schlüsselelement ist nicht initialisiert.

Nebenläufigkeit und Integration

Die Schnittstelle ist als reentrant deklariert, besitzt die Service-ID 0x7e und wird über die Header-Datei Csm.h bereitgestellt [SWS_Csm_91031].

Verwendung und Semantik

Die Funktion Csm_JobKeyExchangeCalcSecret berechnet den gemeinsamen geheimen Schlüssel (Shared Secret Key) für einen Schlüsselaustausch unter Verwendung des Schlüsselmaterials aus dem über keyId identifizierten Schlüssel sowie des öffentlichen Schlüssels des Kommunikationspartners [SWS_Csm_91032]. Die Speicheradresse des Partner-Schlüssels wird über partnerPublicValuePtr übergeben und dessen Länge in Bytes über partnerPublicValueLength definiert [SWS_Csm_91032]. Das berechnete gemeinsame Geheimnis wird direkt als Schlüsselelement innerhalb desselben Schlüssels abgelegt [SWS_Csm_91032].

Über den Eingabeparameter jobId wird der nutzende CSM-Job identifiziert. Das Ausführungsverhalten ist synchron oder asynchron, abhängig von der jeweiligen Job-Konfiguration [SWS_Csm_91032].

Fehlerbehandlung und Rückgabewerte

Der Rückgabewert vom Typ Std_ReturnType meldet den Status der Dienstanforderung [SWS_Csm_91032]:

• E_OK: Die Dienstanforderung war erfolgreich [SWS_Csm_91032].
• E_NOT_OK: Die Dienstanforderung ist fehlgeschlagen [SWS_Csm_91032].
• CRYPTO_E_BUSY: Die Anforderung scheitert, da der zugrundeliegende Dienst noch belegt ist [SWS_Csm_91032].
• CRYPTO_E_KEY_NOT_VALID: Die Anforderung scheitert, weil sich der referenzierte Schlüssel im Zustand „invalid“ befindet [SWS_Csm_91032].
• CRYPTO_E_KEY_EMPTY: Die Berechnung schlägt fehl, da ein erforderliches Quell-Schlüsselelement nicht initialisiert ist [SWS_Csm_91032].

Nebenläufigkeit und Integration

Die Funktion ist reentrant ausgelegt, besitzt die Service-ID 0x7f und wird über die Header-Datei Csm.h deklariert [SWS_Csm_91032].

Die Funktion Csm_SaveContextJob veranlasst den Crypto Driver, den internen Kontext der jeweiligen Krypto-Operation in einen anwendungsseitigen Puffer zu sichern [SWS_Csm_91063]. Der Dienst ist in der Header-Datei Csm.h deklariert und besitzt die Service-ID 0x86 [SWS_Csm_91063].

Die Schnittstelle erwartet folgende Parameter [SWS_Csm_91063]:

• jobId (Eingabe): Bezeichnet die eindeutige Kennung des Jobs, der den CSM-Dienst nutzt.
• contextBufferLengthPtr (Ein-/Ausgabe): Zeiger auf den Längenwert. Beim Aufruf gibt er die maximal im Zielpuffer verfügbare Kapazität an; nach der Ausführung enthält er die tatsächlich geschriebene Datenlänge oder im Fehlerfall den Wert 0.
• contextBufferPtr (Ausgabe): Zeiger auf den Speicherbereich der Anwendung, in den die Kontextdaten geschrieben werden sollen.

Die Ausführung erfolgt in Abhängigkeit von der Job-Konfiguration entweder synchron oder asynchron [SWS_Csm_91063]. Zudem ist die Funktion reentrant spezifiziert [SWS_Csm_91063].

Für die Rückmeldung des Operationsstatus werden folgende Rückgabewerte definiert [SWS_Csm_91063]:

• E_OK: Die Kontextdaten wurden erfolgreich im Puffer abgelegt und die Längenangabe aktualisiert.
• E_NOT_OK: Die Kontextdaten konnten nicht bereitgestellt werden, da die Werte ungültig sind; die zurückgemeldete Länge wird auf 0 gesetzt.
• CRYPTO_E_BUSY: Die Anfrage ist fehlgeschlagen, weil der zugrunde liegende Krypto-Dienst noch beschäftigt ist.

Verwendung und Semantik

Die Funktion Csm_RestoreContextJob dient dazu, den internen Zustand eines kryptografischen Jobs aus einem externen Puffer wiederherzustellen, sodass nachfolgende Operationen an der exakten Stelle der vorherigen Sicherung fortgeführt werden [SWS_Csm_91064]. Über den Parameter jobId wird der Zieljob adressiert, während contextBufferPtr auf die Nutzdaten und contextBufferLength auf deren Bytegröße verweist [SWS_Csm_91064]. Die Ausführung erfolgt abhängig von der Konfiguration des jeweiligen Jobs synchron oder asynchron [SWS_Csm_91064].

Rückgabewerte und Fehlerbehandlung

Die Funktion meldet das Ergebnis der Operation über ihren Rückgabewert vom Typ Std_ReturnType zurück [SWS_Csm_91064]:

• E_OK: Die Kontextdaten wurden erfolgreich eingelesen und der interne Treiberzustand wiederhergestellt [SWS_Csm_91064].
• E_NOT_OK: Die Wiederherstellung des Kontexts schlug fehl [SWS_Csm_91064].
• CRYPTO_E_BUSY: Der zugrundeliegende Krypto-Dienst ist gegenwärtig belegt, weshalb die Anfrage abgewiesen wurde [SWS_Csm_91064].

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als reentrant spezifiziert und über Csm.h verfügbar (Service-ID 0x87) [SWS_Csm_91064]. Interpretation: Bei einer asynchronen Konfiguration des Jobs dürfte der Aufrufer dafür Sorge tragen müssen, dass der Puffer unter contextBufferPtr bis zum tatsächlichen Abschluss der Wiederherstellung unverändert und gültig bleibt. Frage Q-8ab0cb179f807bd4 (offen)

Verwendung und Aufrufkontext

Die Funktion Csm_CancelJob (Service-ID 0x6f) dient dem synchronen Abbruch der Verarbeitung von asynchronen oder Streaming-Jobs innerhalb des Moduls Csm [SWS_Csm_00968]. Die Schnittstelle wird über den Header Csm.h bereitgestellt [SWS_Csm_00968]. Als Parameter übernimmt die Funktion den Bezeichner des abzubrechenden Jobs über job (vom Typ uint32) sowie den Parameter mode (vom Typ Crypto_OperationModeType), welcher nicht verwendet wird und ausschließlich der Schnittstellenkompatibilität dient [SWS_Csm_00968].

Rückgabewerte und Stornierungsverhalten

Das Ergebnis des Abbruchaufrufs wird synchron über den Rückgabewert vom Typ Std_ReturnType signalisiert [SWS_Csm_00968]:

• E_OK: Der Abbruch war unmittelbar erfolgreich; der Job wurde aus sämtlichen Warteschlangen und potenziell direkt aus der Hardware des Krypto-Treibers entfernt [SWS_Csm_00968].
• E_NOT_OK: Die Abbruchanforderung ist fehlgeschlagen [SWS_Csm_00968].
• CRYPTO_E_JOB_CANCELED: Eine sofortige Stornierung war nicht möglich; der Abbruch wird im nächsten geeigneten Verarbeitungsschritt vollzogen und anschließend über den negativen Abschluss-Callback des Jobs mitgeteilt [SWS_Csm_00968].

Nebenläufigkeit und Einschränkungen

Die Spezifikation definiert Csm_CancelJob als synchron und nicht reentrant (Non Reentrant) [SWS_Csm_00968]. Aufrufende Komponenten müssen daher sicherstellen, dass keine konkurrierenden Aufrufe der Funktion erfolgen.

Die synchrone Schnittstelle Csm_CallbackNotification wird über die Header-Datei Csm.h deklariert und dient der unterlagerten Schicht (CRYIF) als Rückmeldefunktion, um den Crypto Service Manager (CSM) über die Fertigstellung eines kryptografischen Auftrags zu benachrichtigen [SWS_Csm_00970]. Die Funktion besitzt keinen Rückgabewert und nimmt zwei Eingangsparameter entgegen: den Zeiger job auf den beendeten Auftrag vom Typ Crypto_JobType* sowie result vom Typ Crypto_ResultType, der das Ausführungsergebnis der zugrundeliegenden kryptografischen Operation übermittelt [SWS_Csm_00970].

In Bezug auf die Nebenläufigkeit ist die Ausführung von Csm_CallbackNotification als reentrant spezifiziert [SWS_Csm_00970]. Spezifische Rückgabecodes oder separate DET- bzw. DEM-Fehlermeldungen sind im Element nicht definiert; Fehlzustände und Ausführungsergebnisse der kryptografischen Verarbeitung werden stattdessen direkt über das übergebene Argument result bereitgestellt [SWS_Csm_00970].

Im Rahmen des Zusammenspiels prüft die Funktion den Verarbeitungsmodus des Auftrags: Ist im Feld job->jobPrimitiveInputOutput.mode das Bit CRYPTO_OPERATIONMODE_FINISH gesetzt, verpflichtet die Spezifikation Csm_CallbackNotification dazu, die konfigurierte Callback-Funktion aufzurufen [SWS_Csm_01044]. Interpretation: Bei diesem Aufruf dürfte es sich um die Benachrichtigung der übergeordneten Applikationsschicht handeln, da das FINISH-Flag den finalen Abschluss einer kryptografischen Operationssequenz signalisiert. Frage Q-32da2433b15ba3a9 (offen)

Verwendung

Die Funktion Csm_MainFunction wird zyklisch aufgerufen, um angeforderte kryptografische Jobs zu verarbeiten [SWS_Csm_00479]. Sie besitzt keine Übergabeparameter (void) und liefert keinen Rückgabewert zurück [SWS_Csm_00479]. Die Deklaration ist über den Header SchM_Csm.h verfügbar [SWS_Csm_00479].

Aufgaben und Zusammenspiel

Im Rahmen ihrer periodischen Ausführung prüft die Funktion die internen Warteschlangen auf anstehende Jobs und übergibt diese an die darunterliegende Schicht CRYIF [SWS_Csm_00479].

Instanziierung und Aufrufkontext

Pro konfigurierter Instanz wird eine dedizierte Funktion der Form Csm_MainFunction_<shortName> implementiert, wobei <shortName> dem Kurznamen des Konfigurationscontainers in der ECU-Konfiguration entspricht [SWS_Csm_00479]. Der zyklische Aufruf dürfte planmäßig durch den BSW-Scheduler (SchM) in einer periodischen Task erfolgen, da die Schnittstelle über SchM_Csm.h bereitgestellt wird. Frage Q-ffb62942b1f517b3 (offen)

Fehlerbehandlung und Randbedingungen

Spezifische Fehlercodes, DET- oder DEM-Meldungen sowie explizite Reentranzvorgaben werden im vorliegenden Spezifikationsauszug nicht beschrieben [SWS_Csm_00479].

Die konfigurierbare Callback-Funktion <Csm_ Application Callback Notification> dient dazu, eine Anwendung durch den Crypto Service Manager (CSM) synchron über das Ende eines Verarbeitungsauftrags zu informieren [SWS_Csm_00971]. Der Bezeichner der Funktion ist nicht fest vorgegeben, sondern wird über den Konfigurationsparameter {Csm Job/ Csm Job Primitive Callback Ref}/Csm Callback Func projektspezifisch festgelegt [SWS_Csm_00971]. Die Schnittstelle besitzt die Service-ID 0x82 und wird über die Header-Datei Csm.h bereitgestellt [SWS_Csm_00971].

Die Signatur besitzt keinen Rückgabewert (void) und übergibt zwei Eingangsparameter zur Auswertung an die Anwendung [SWS_Csm_00971]:

• jobId (uint32): Bezeichnet die eindeutige ID des kryptografischen Auftrags, dessen Abschluss den Callback ausgelöst hat [SWS_Csm_00971].
• result (Crypto_ResultType): Übermittelt das Resultat beziehungsweise den Status der ausgeführten kryptografischen Operation [SWS_Csm_00971].

In Bezug auf die Nebenläufigkeit ist die Benachrichtigungsfunktion als reentrant spezifiziert [SWS_Csm_00971]. Spezifische DET- oder DEM-Fehlercodes werden für den Callback selbst nicht definiert; aufgetretene Fehler der vorangegangenen Operation müssen direkt über result ausgewertet werden [SWS_Csm_00971]. Da die Schnittstelle reentrant deklariert ist, dürfte die anwendungsseitige Implementierung so ausgelegt sein müssen, dass sie gleichzeitige Benachrichtigungen für verschiedene Aufträge thread-sicher verarbeiten kann. Frage Q-79504ea3461f8d61 (offen)

Der Aufzählungstyp Crypto_AlgorithmModeType spezifiziert nach [SWS_Csm_01048] den Betriebsmodus eines kryptografischen Algorithmus. Er ist über die Header-Datei Crypto_GeneralTypes.h verfügbar und dient der standardisierten Konfiguration sowie Laufzeitauswahl kryptografischer Verfahren im Crypto Service Manager.

Verwendung und Wertebereich:

• Klassische Blockchiffren-Modi: Unterstützt werden unter anderem CRYPTO_ALGOMODE_ECB, CRYPTO_ALGOMODE_CBC, CRYPTO_ALGOMODE_CFB, CRYPTO_ALGOMODE_OFB, CRYPTO_ALGOMODE_CTR, CRYPTO_ALGOMODE_GCM sowie CRYPTO_ALGOMODE_XTS [SWS_Csm_01048].
• Asymmetrische Verfahren und Padding: Enthalten sind Modi für Verschlüsselung und Signaturen wie CRYPTO_ALGOMODE_RSAES_OAEP, CRYPTO_ALGOMODE_RSAES_PKCS1_v1_5, CRYPTO_ALGOMODE_RSASSA_PSS und CRYPTO_ALGOMODE_RSASSA_PKCS1_v1_5 [SWS_Csm_01048].
• Weitere Betriebsmodi: Der Wertebereich umfasst Rundenanzahlen (CRYPTO_ALGOMODE_8ROUNDS, CRYPTO_ALGOMODE_12ROUNDS, CRYPTO_ALGOMODE_20ROUNDS), MAC-Verfahren (CRYPTO_ALGOMODE_HMAC, CRYPTO_ALGOMODE_CMAC, CRYPTO_ALGOMODE_GMAC), Zufallsbitgeneratoren (CRYPTO_ALGOMODE_CTRDRBG), SipHash-Varianten sowie Kurvendefinitionen wie CRYPTO_ALGOMODE_PXXXR1 [SWS_Csm_01048].
• Sonderzustände: Mit CRYPTO_ALGOMODE_NOT_SET (0x00) wird ein nicht gesetzter Algorithmus-Schlüssel signalisiert, während CRYPTO_ALGOMODE_CUSTOM (0xff) herstellerspezifische Betriebsmodi gestattet [SWS_Csm_01048].

Interpretation: Da es sich bei Crypto_AlgorithmModeType um eine reine Enumeration handelt, besitzt der Typ keine eigene Fehlerbehandlung über DET oder DEM und unterliegt keinen Reentranz-Vorgaben. Frage Q-3d2e905dda6531ac (offen) Fehlerprüfungen und Einschränkungen hinsichtlich des Aufrufkontexts ergeben sich erst aus den CSM-Funktionen, denen Werte dieses Typs als Parameter übergeben werden.

Verwendung und Aufbau von Crypto_JobType

Die Struktur Crypto_JobType bündelt alle relevanten Steuerungs-, Zustands- und Pufferdaten für die Durchführung eines kryptografischen Auftrags im Crypto Service Manager und steht über Crypto_GeneralTypes.h bereit [SWS_Csm_01013].

Zu den zentralen Elementen der Struktur gehören [SWS_Csm_01013]:

• jobId: Eindeutige Kennung des Jobs.
• jobState: Repräsentiert den aktuellen Ausführungsstatus des Jobs.
• jobPrimitiveInputOutput: Verweist auf die spezifischen Ein- und Ausgabedaten des Primitivs.
• jobPrimitiveInfo: Zeiger auf konstante Zusatzinformationen zum gewählten Krypto-Primitiv.
• jobPriority: Bestimmt die Ausführungspriorität, wobei ein höherer Wert eine höhere Dringlichkeit kennzeichnet.
• jobRedirectionInfoRef: Zeiger auf optionale Angaben zur Umleitung von Schlüsseln als Ein- und Ausgabewerte.

Zusammenspiel und Schnittstellenbeziehungen

Die Strukturfelder cryptoKeyId und targetCryptoKeyId referenzieren die zu verwendenden Schlüssel im Krypto-Treiber; gemäß Spezifikation werden diese Bezeichner durch das Crypto Interface beschrieben [SWS_Csm_01013]. Interpretation: Über jobPriority dürfte die Reihenfolge bei der Einplanung und Abarbeitung nebenläufiger Aufträge in Warteschlangen geregelt werden. Frage Q-439432c5631948fb (offen)

Der Enumerationstyp Crypto_JobStateType definiert den aktuellen Verarbeitungsstatus eines kryptografischen Jobs im CSM [SWS_Csm_01028]. Er wird über die Header-Datei Crypto_GeneralTypes.h bereitgestellt und unterscheidet zwischen zwei Hauptzuständen des Job-Lebenszyklus [SWS_Csm_01028]:

• CRYPTO_JOBSTATE_IDLE (0x00): Kennzeichnet den Ruhezustand des Jobs. Dieser Zustand wird initial nach dem Aufruf von Csm_Init() eingenommen oder sobald eine Finish-Operation (Zustand „Finish“) abgeschlossen wurde [SWS_Csm_01028].
• CRYPTO_JOBSTATE_ACTIVE (0x01): Zeigt an, dass der Job aktiv verarbeitet wird und bereits Eingabedaten verarbeitet wurden oder Zwischenergebnisse vorliegen. Dieser Zustand wird erreicht, sobald eine Start- oder Update-Operation erfolgreich abgeschlossen wurde [SWS_Csm_01028].

In Bezug auf die Verwendung und das Zusammenspiel spiegelt der Typ den Fortschritt von Streaming- oder mehrstufigen Krypto-Operationen wider [SWS_Csm_01028]. Ein Übergang nach CRYPTO_JOBSTATE_ACTIVE signalisiert, dass der kryptografische Kontext initialisiert ist oder fortlaufend Zwischenergebnisse hält, während der Übergang zu CRYPTO_JOBSTATE_IDLE die Beendigung markiert und anzeigt, dass der Job für neue Abläufe bereitsteht [SWS_Csm_01028].

Die Datenstruktur Crypto_JobPrimitiveInfoType bündelt Zusatzinformationen zu einem Krypto-Job und dessen zugrundeliegenden Primitiven [SWS_Csm_01012]. Sie ist im Classic-AUTOSAR-Stack über die Header-Datei Crypto_GeneralTypes.h verfügbar [SWS_Csm_01012].

Bestandteile und Verwendung

Laut Spezifikation [SWS_Csm_01012] setzt sich die Struktur aus folgenden Feldern zusammen:

• callbackId (uint32): Interner Bezeichner der Callback-Funktion, die durch das Modul CSM aufgerufen wird, sobald die Ausführung des konfigurierten Dienstes beendet ist [SWS_Csm_01012].
• primitiveInfo (const Crypto_PrimitiveInfoType*): Zeiger auf eine Datenstruktur mit der weiteren Konfiguration der Krypto-Primitive [SWS_Csm_01012].
• cryIfKeyId (uint32): Kennung des Schlüssels für die Krypto-Schnittstelle (CryIf) [SWS_Csm_01012].
• processingType (Crypto_ProcessingType): Definiert das Ausführungsverhalten und bestimmt, ob der Auftrag synchron oder asynchron verarbeitet wird [SWS_Csm_01012].

Ausführungskontext und Semantik

Das Feld processingType steuert die synchrone oder asynchrone Semantik der Auftragsverarbeitung [SWS_Csm_01012]. Die über callbackId hinterlegte Rückruffunktion dürfte dabei vor allem im asynchronen Modus relevant sein, um den Aufrufer über das Ende des Dienstes zu informieren, während der Zeiger primitiveInfo auf eine gültige Primitiv-Konfiguration verweisen muss [SWS_Csm_01012]. Frage Q-791dae4fb6a83f99 (offen)

Verwendung

Die Datenstruktur Crypto_AlgorithmInfoType bestimmt die exakte Konfiguration eines kryptografischen Algorithmus und wird über die Header-Datei Crypto_GeneralTypes.h bereitgestellt [SWS_Csm_01008]. Sie setzt sich aus folgenden Elementen zusammen:

• family (Crypto_AlgorithmFamilyType): Die primäre Familie des Algorithmus.
• secondaryFamily (Crypto_AlgorithmFamilyType): Die sekundäre Familie des Algorithmus.
• keyLength (uint32): Die zu verwendende Schlüssellänge in Bit.
• mode (Crypto_AlgorithmModeType): Der vorgesehene Betriebsmodus des Algorithmus.

Nicht jeder Algorithmus erfordert die vollständige Belegung aller Strukturelemente [SWS_Csm_01008]. Je nach Art der kryptografischen Operation können einzelne Felder wie der Betriebsmodus oder eine sekundäre Familie ungenutzt bleiben.

Einschränkungen und Fehlerbehandlung

Gemäß [SWS_Csm_01008] dürfen in AUTOSAR ausschließlich gültige Kombinationen der Strukturelemente vorkommen. Unzulässige Kombinationen – beispielsweise nicht zusammenpassende Betriebsmodi oder unzulässige Schlüssellängen für eine spezifische Algorithmenfamilie – sind nicht erlaubt. Die Überprüfung auf Gültigkeit der Parameterkombination dürfte vermutlich durch die Konfigurationswerkzeuge oder bei Dienstaufrufen durch den CSM erfolgen. Frage Q-da4984170bba173c (offen)

Die Struktur Crypto_PrimitiveInfoType dient im Crypto Service Manager (CSM) der Bereitstellung grundlegender Metadaten zu einem kryptografischen Primitiv ([SWS_Csm_01011]). Sie wird über die Header-Datei Crypto_GeneralTypes.h deklariert und bündelt die statischen Charakteristika der jeweiligen Operation ([SWS_Csm_01011]).

Die Struktur setzt sich aus zwei Elementen zusammen ([SWS_Csm_01011]):

• service (Typ: const Crypto_ServiceInfoType): Bestimmt den genutzten kryptografischen Dienst über eine Enumeration, beispielsweise eine Verschlüsselung (Encrypt) ([SWS_Csm_01011]).
• algorithm (Typ: const Crypto_AlgorithmInfoType): Enthält die Detailinformationen zum verwendeten Algorithmus ([SWS_Csm_01011]).

Da beide Elemente als const typisiert sind, dürfte es sich um schreibgeschützte Konfigurations- oder Metadaten handeln, die zur Konfigurationszeit festgelegt und zur Laufzeit durch Treiber oder den CSM rein lesend ausgewertet werden ([SWS_Csm_01011]). Frage Q-6d53291f7fb8cfe6 (offen) Spezifische Fehlercodes, Fehlerbehandlungsroutinen oder Nebenläufigkeitsbeschränkungen sind für diesen Datenstrukturtyp nicht definiert.

Der Aufzählungstyp Crypto_OperationModeType definiert gemäß [SWS_Csm_01029] die auszuführende Verarbeitungsphase bei kryptografischen Operationen. Der Typ ist als Bitmaske aufgebaut, deren erste drei Bits die Kernschritte Start (Bit 1 / 0x01), Update (Bit 2 / 0x02) und Finish (Bit 3 / 0x04) abbilden.

Über die Enumerationswerte werden die unterschiedlichen Ausführungs- und Lebenszyklusphasen eines Krypto-Jobs gesteuert [SWS_Csm_01029]:

• CRYPTO_OPERATIONMODE_START (0x01): Initialisiert den Job; der Zustand wird zurückgesetzt, wodurch vorherige Eingabedaten und Zwischenergebnisse gelöscht werden.
• CRYPTO_OPERATIONMODE_UPDATE (0x02): Verarbeitet Eingabedaten zur Berechnung von Zwischenergebnissen.
• CRYPTO_OPERATIONMODE_FINISH (0x04): Schließt die Berechnungen der kryptografischen Operation final ab.
• CRYPTO_OPERATIONMODE_STREAMSTART (0x03): Kombiniert Start und Update für Streaming-Szenarien.
• CRYPTO_OPERATIONMODE_SINGLECALL (0x07): Vereint Start, Update und Finish für die vollständige Verarbeitung in einem einzelnen Aufruf.

Darüber hinaus unterstützt der Typ das Workspace-Management bei unterbrechbaren Abläufen: Mit CRYPTO_OPERATIONMODE_SAVE_CONTEXT (0x08) stellt der Krypto-Treiber den aktuellen Workspace-Kontext der Anwendung bereit, während CRYPTO_OPERATIONMODE_RESTORE_CONTEXT (0x10) einen zuvor gesicherten Zustand im internen Workspace des Treibers wiederherstellt [SWS_Csm_01029]. Der Typ wird über den Header Rte_Csm_Type.h bereitgestellt.

Der Aufzählungstyp Crypto_VerifyResultType definiert das funktionale Ergebnis von Verifikationsoperationen im Modul CSM [SWS_Csm_01024]. Er wird über die Header-Datei Rte_Csm_Type.h bereitgestellt und dient der Feststellung, ob ein kryptografischer Vergleich erfolgreich abgeschlossen wurde [SWS_Csm_01024].

Wertebereich und Semantik

Die Enumeration umfasst gemäß [SWS_Csm_01024] zwei diskrete Werte zur Abbildung des Vergleichsstatus:

• CRYPTO_E_VER_OK (Wert 0x00 bzw. 0): Das Ergebnis der Verifikation ist „true“, die beiden verglichenen Elemente sind somit identisch [SWS_Csm_01024].
• CRYPTO_E_VER_NOT_OK (Wert 0x01 bzw. 1): Das Ergebnis der Verifikation ist „false“, die verglichenen Elemente sind nicht identisch [SWS_Csm_01024].

Der Typ trennt die funktionale Aussage über die Datenübereinstimmung vom allgemeinen Ausführungsstatus einer Operation. Als Interpretation bedeutet dies, dass auch eine fehlerfrei ausgeführte Prüfroutine den Rückgabewert CRYPTO_E_VER_NOT_OK liefern kann, wenn Daten voneinander abweichen [SWS_Csm_01024].

Verwendung und Einschränkungen

Da der Datentyp über Rte_Csm_Type.h deklariert ist, dürfte er vor allem als Ausgabeparameter für Verifikationsdienste des CSM genutzt werden [SWS_Csm_01024]. Frage Q-067a1d2b36ffe56b (offen) Spezifische Fehlerbehandlungen wie DET- oder DEM-Meldungen sowie Vorgaben zu Reentranz oder Nebenläufigkeit sind am Typ selbst nicht festgelegt [SWS_Csm_01024].

Der Enumerationstyp Crypto_ResultType dient als spezifischer Rückgabetyp für Funktionen des AUTOSAR-Krypto-Stacks und ist über den Header Rte_Csm_Type.h verfügbar [SWS_Csm_91044]. Er erweitert das klassische Rückgabeschema um differenzierte Fehler- und Statusmeldungen für kryptographische Operationen [SWS_Csm_91044].

Neben dem regulären Erfolgsstatus E_OK (0x00) und dem allgemeinen Fehler E_NOT_OK (0x01) definiert der Typ folgende spezifische Fehlerzustände [SWS_Csm_91044]:

• Ablauf- und Ressourcenzustände: CRYPTO_E_BUSY (0x02) kennzeichnet einen noch belegten Dienst, CRYPTO_E_JOB_CANCELED (0x0C) den Abbruch eines Auftrags und CRYPTO_E_ENTROPY_EXHAUSTED (0x04) eine erschöpfte Entropiequelle des Zufallsgenerators [SWS_Csm_91044].
• Schlüssel- und Zugriffsprobleme: Spezifiziert sind Zugriffsverweigerungen beim Lesen (CRYPTO_E_KEY_READ_FAIL, 0x06) oder Schreiben (CRYPTO_E_KEY_WRITE_FAIL, 0x07), fehlende Schlüssel (CRYPTO_E_KEY_NOT_AVAILABLE, 0x08), ungültige Schlüssel (CRYPTO_E_KEY_NOT_VALID, 0x09), inkorrekte Schlüsselgrößen (CRYPTO_E_KEY_SIZE_MISMATCH, 0x0A) sowie nicht initialisierte Quellschlüsselelemente (CRYPTO_E_KEY_EMPTY, 0x0D) [SWS_Csm_91044].

Interpretation: Aufrufende Komponenten dürften diese Rückgabecodes auswerten, um situationsabhängig zwischen temporären Wartezuständen und permanenten Konfigurationsfehlern zu unterscheiden. Frage Q-68cfedad7880908c (offen)

Verwendung und Struktur von Csm_HashDataType

Der Datentyp Csm_HashDataType ist gemäß [SWS_Csm_01920] als Array mit Elementen vom Basistyp uint8 definiert. Er dient als Datenpuffer zur Speicherung der Eingangsdaten, die einer Hashwertberechnung im Crypto Service Manager unterzogen werden sollen. Die Länge des Feldes ist so ausgelegt, dass sie für die vollständige Aufnahme der zu hashenden Daten ausreicht [SWS_Csm_01920].

Konfiguration und Variantenbildung

Die tatsächliche Dimensionierung des Arrays wird über den Konfigurationsparameter CsmHashDataMaxLength gesteuert, der unter dem Pfad Csm/CsmPrimitives/CsmHash/CsmHashConfig definiert ist [SWS_Csm_01920]. Hierdurch wird sichergestellt, dass der Speicherbereich passend zur maximal erwarteten Datenmenge der jeweiligen Hash-Konfiguration ausgelegt ist.

Darüber hinaus existiert eine kryptografische Variantenbildung gemäß dem Muster Csm_HashDataType_{Crypto}, wobei der Platzhalter {Crypto} über den SHORT-NAME der jeweiligen Primitiv-Konfiguration unter Csm/CsmPrimitives aufgelöst wird [SWS_Csm_01920]. Dies ermöglicht primitive-spezifische Pufferstrukturen im System.

Einbindung und Randbedingungen

Der Typ wird über den Header Rte_Csm_Type.h bereitgestellt [SWS_Csm_01920]. Dies dürfte bedeuten, dass der Typ für die standardisierte Datenübergabe über RTE-Schnittstellen zwischen Software-Komponenten und dem CSM vorgesehen ist. Frage Q-4240a8394cdd746d (offen) Anwender müssen bei der Pufferbelegung beachten, dass Daten die konfigurierte Obergrenze CsmHashDataMaxLength nicht überschreiten dürfen, um Überläufe bei der Hash-Berechnung zu vermeiden.

Verwendung und Struktur von Csm_HashResultType

Der Datentyp Csm_HashResultType repräsentiert ein Array von uint8-Elementen und dient als ausreichend dimensionierter Speicherbereich zur Ablage der Daten eines Hash-Ergebnisses [SWS_Csm_00912].

Die konkrete Pufferlänge des Arrays ist konfigurierbar und wird über den Konfigurationsparameter CsmHashResultLength unter Csm/CsmPrimitives/CsmHash/CsmHashConfig/CsmHashResultLength festgelegt [SWS_Csm_00912]. Damit richtet sich die Größe des Datentyps direkt nach der Ausgabelänge des jeweiligen kryptografischen Hash-Algorithmus.

Die Typdefinition unterliegt einer Namensvariation gemäß dem Muster Csm_HashResultType_{Crypto}, wobei der Bezeichner {Crypto} durch den Kurznamen des konfigurierten Primitivs (ecuc/Csm/CsmPrimitives.SHORT-NAME) substituiert wird [SWS_Csm_00912].

Verfügbar gemacht wird der Datentyp über den Header Rte_Csm_Type.h [SWS_Csm_00912]. Interpretation: Aufgrund der Bereitstellung über Rte_Csm_Type.h dürfte der Typ vor allem dafür vorgesehen sein, in Software-Komponenten oder an RTE-Schnittstellen als typisierter Ergebnispuffer für Hash-Rückgabewerte verwendet zu werden. Frage Q-4ff10e08b6a5c8c0 (offen)

Der Datentyp Csm_MacGenerateDataType dient als Byte-Array zur Speicherung der Eingangsdaten, aus denen ein Message Authentication Code (MAC) berechnet werden soll [SWS_Csm_00935].

Verwendung und Typaufbau

Das Element ist gemäß [SWS_Csm_00935] als Array mit Elementen des Basistyps uint8 spezifiziert. Der Typname unterliegt einer kryptografischen Namensvariation nach dem Schema Csm_MacGenerateDataType_{Crypto}, wobei das Suffix dem konfigurierten Kurznamen der jeweiligen Primitive entspricht [SWS_Csm_00935]. Die Dimensionierung des Feldes wird statisch über den Konfigurationsparameter CsmMacGenerateDataMaxLength bestimmt, wodurch sichergestellt wird, dass das Array ausreichend Speicherplatz für die zu verarbeitenden Daten bietet [SWS_Csm_00935].

Einbindung und Schnittstellen

Der Typ wird über die Header-Datei Rte_Csm_Type.h bereitgestellt und bindet die Datenstrukturen an die AUTOSAR-RTE an [SWS_Csm_00935]. Aufrufende Software-Komponenten (SWCs) oder Basissoftware-Module können diesen Typ nutzen, um typisierte Datenpuffer für MAC-Generierungsdienste des CSM zu deklarieren.

Einschränkungen

Da die Feldgröße fest über die Maximallänge konfiguriert ist, dürfte auf Anwenderebene sicherzustellen sein, dass die Nutzdaten diese Grenze nicht überschreiten, da der statische Typ keine dynamische Längenanpassung vorsieht [SWS_Csm_00935]. Frage Q-2010ffc7191f874a (offen)

Der Datentyp Csm_MacGenerateResultType repräsentiert gemäß [SWS_Csm_00927] ein Byte-Array (Elementtyp uint8), das zur Aufnahme der Ergebnisdaten eines generierten Message Authentication Codes (MAC) dient.

Verwendung und Dimensionierung

Die Spezifikation definiert das Array als ausreichend lang, um die Daten des MAC zu speichern ([SWS_Csm_00927]). Die tatsächliche Puffergröße wird über den Konfigurationsparameter CsmMacGenerateResultLength festgelegt, welcher unter dem Pfad Csm/CsmPrimitives/CsmMacGenerate/CsmMacGenerateConfig konfiguriert wird ([SWS_Csm_00927]). Zudem unterliegt der Typ einer kryptografischen Variierung über den Kurznamen der Primitive ({Crypto} bzw. ecuc/Csm/CsmPrimitives.SHORT-NAME) gemäß [SWS_Csm_00927].

Verfügbarkeit und Schnittstelle

Der Typ wird über den Header Rte_Csm_Type.h bereitgestellt ([SWS_Csm_00927]). Dies zeigt, dass er primär für die typisierte Datenübergabe über die RTE-Schnittstelle zur Bereitstellung des berechneten MAC-Werts konzipiert ist.

Einschränkungen

Da es sich um eine statische Typdefinition handelt, hängt die konkrete Instanziierung von der Vorkonfiguration der MAC-Länge ab; weitere Parameter, Fehlercodes oder Nebenläufigkeitsanforderungen sind für diesen Datentyp selbst nicht spezifiziert ([SWS_Csm_00927]).

Der Datentyp Csm_MacVerifyDataType ist als Array von uint8-Elementen spezifiziert und dient als Puffer zur Speicherung der Daten, für welche ein Message Authentication Code (MAC) verifiziert werden soll [SWS_Csm_00802].

Für die Verwendung und Konfiguration dieses Typs gelten die folgenden Festlegungen:

• Puffergröße: Die Array-Größe richtet sich nach dem Konfigurationsparameter CsmMacVerifyDataMaxLength im Container Csm/CsmPrimitives/CsmMacVerify/CsmMacVerifyConfig. Dadurch wird sichergestellt, dass das Array ausreichend dimensioniert ist, um die zu verifizierenden Eingangsdaten vollständig aufzunehmen [SWS_Csm_00802].
• Varianz und Benennung: Die Definition enthält das Varianzkriterium Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, wodurch der konkrete C-Typbezeichner modulspezifisch in der Form Csm_MacVerifyDataType_{Crypto} generiert wird [SWS_Csm_00802].
• Schnittstelleneinbindung: Der Typ wird über die Header-Datei Rte_Csm_Type.h exportiert [SWS_Csm_00802]. Interpretation: Die Bereitstellung in diesem Header lässt darauf schließen, dass der Typ vorrangig für die RTE-gestützte Schnittstellenkommunikation zwischen Software-Komponenten und dem CSM bestimmt sein dürfte. Frage Q-c49670b3de0ba19c (offen)

Anwendungsentwickler müssen beachten, dass die maximale Länge der verifizierbaren Nutzdaten durch die statische Konfiguration der Primitiven begrenzt ist und Eingabedaten diese Pufferkapazität nicht überschreiten dürfen [SWS_Csm_00802].

Verwendung und Struktur

Der Typ Csm_MacVerifyCompareType ist gemäß [SWS_Csm_00803] als Array aus uint8-Elementen definiert. Er dient dazu, den zu verifizierenden Message Authentication Code (MAC) aufzunehmen, welcher mit dem im Rahmen einer kryptografischen Operation berechneten MAC verglichen werden soll.

Die Bereitstellung des Typs erfolgt über den Header Rte_Csm_Type.h für die RTE-Schnittstelle [SWS_Csm_00803]. Die konkrete Typbezeichnung unterliegt einer Namensvariation über den Primitivnamen nach dem Muster Csm_MacVerifyCompareType_{Crypto}, wobei {Crypto} durch den Kurznamen des Primitivs (ecuc/Csm/CsmPrimitives.SHORT-NAME) ersetzt wird.

Konfiguration und Dimensionierung

Die Größe des Arrays bemisst sich gemäß [SWS_Csm_00803] nach dem Ausdruck CsmMacVerifyCompareLength/8 aus der Konfiguration (ecuc(Csm/CsmPrimitives/CsmMacVerify/CsmMacVerifyConfig/CsmMacVerifyCompareLength)). Dies spiegelt die Länge des MAC-Vergleichswerts in Bytes wider.

Fehlerbehandlung und Randbedingungen

Als reine Typdefinition für ein Daten-Array besitzt Csm_MacVerifyCompareType keine eigenen Rückgabewerte und generiert keine direkten Fehlercodes oder DET-/DEM-Ereignisse. Es gelten jedoch folgende anwendungsbezogene Randbedingungen:

• Pufferbereitstellung: Aufrufer dürften dafür verantwortlich sein, das Array vor der Übergabe an eine Verifizierungsfunktion vollständig mit dem empfangenen Referenz-MAC zu initialisieren. Frage Q-94b98958fd778057 (offen)
• Nebenläufigkeit: Da es sich um eine Datenstruktur handelt, ist der Typ selbst reentrant. Ein konkurrierender Lese- und Schreibzugriff mehrerer Tasks auf dieselbe Array-Instanz dürfte jedoch ohne Synchronisation zu Verfälschungen führen. Frage Q-148c0a523da7b402 (offen)

Der Typ Csm_EncryptDataType definiert ein Byte-Array aus uint8-Elementen, das zur Aufnahme der zu verschlüsselnden Daten dient [SWS_Csm_01921]. Er wird über die Header-Datei Rte_Csm_Type.h bereitgestellt und ermöglicht Software-Komponenten die typisierte Datenübergabe an die kryptografischen Dienste des Moduls [SWS_Csm_01921].

Struktur und Konfiguration

• Array-Elemente: Die Elemente sind vom Basistyp uint8 [SWS_Csm_01921].
• Größe: Die Array-Länge richtet sich nach dem Konfigurationsparameter CsmEncryptDataMaxLength unterhalb der jeweiligen Primitiv-Konfiguration CsmEncryptConfig [SWS_Csm_01921].
• Namensvariation: Der Typname variiert je nach Primitiv gemäß dem Schema Csm_EncryptDataType_{Crypto}, wobei {Crypto} dem Kurznamen (SHORT-NAME) des konfigurierten CSM-Primitives entspricht [SWS_Csm_01921].

Verwendung und Einschränkungen

Als reine Typdefinition besitzt das Element keine eigene Reentranz oder Fehlerbehandlung. Da die Array-Größe fest an die maximale Puffergröße der Konfiguration gekoppelt ist, dürfte als Interpretation der Aufrufer bei der Befüllung dafür Sorge tragen müssen, dass die bereitgestellten Daten die Puffergrenze CsmEncryptDataMaxLength nicht überschreiten [SWS_Csm_01921]. Frage Q-4bf70d603b5679d3 (offen)

Verwendung und Zweck

Der Datentyp Csm_EncryptResultType ist als Byte-Array mit dem Elementtyp uint8 spezifiziert und dient der Aufnahme der Chiffrierdaten (Cipher-Ergebnis) eines Verschlüsselungsvorgangs ([SWS_Csm_01922]). Das Array ist laut Spezifikation so auszulegen, dass es lang genug ist, um sämtliche Daten der Chiffre aufzunehmen ([SWS_Csm_01922]).

Konfiguration und Varianten

Die Definition des Datentyps unterliegt einer Variantenbildung anhand der konfigurierten Krypto-Primitive. Für jede Primitive wird ein typspezifischer Bezeichner nach dem Schema Csm_EncryptResultType_{Crypto} gebildet, wobei {Crypto} dem Kurznamen der jeweiligen Primitive entspricht ([SWS_Csm_01922]). Die statische Feldgröße des Arrays wird über den Konfigurationsparameter CsmEncryptResultMaxLength unter Csm/CsmPrimitives/CsmEncrypt/CsmEncryptConfig/ bestimmt ([SWS_Csm_01922]).

Einbindung und Randbedingungen

Der Datentyp wird über die Header-Datei Rte_Csm_Type.h exportiert ([SWS_Csm_01922]). Interpretation: Aufgrund der Bereitstellung über Rte_Csm_Type.h dürfte der Typ für die standardisierte Datenübergabe zwischen Applikations-Softwarekomponenten und dem Crypto Service Manager über RTE-Ports konzipiert sein. Frage Q-6dc06520e3fd9dc6 (offen) Anwender müssen bei der Pufferbeistellung sicherstellen, dass die Chiffrierergebnisse die konfigurierte Maximallänge CsmEncryptResultMaxLength nicht überschreiten ([SWS_Csm_01922]).

Verwendung und Datenstruktur

Der Typ Csm_DecryptDataType ist in der Spezifikation des Crypto Service Managers als Array mit Elementen des Basistyps uint8 definiert [SWS_Csm_01923]. Er dient als dedizierter Speicherpuffer für die zu entschlüsselnden Eingangsdaten [SWS_Csm_01923]. Die Auslegung des Arrays ist verbindlich so vorgegeben, dass seine Kapazität stets lang genug sein muss, um die jeweiligen Daten vollständig aufzunehmen [SWS_Csm_01923].

Konfiguration und Variantenbildung

Die Dimensionierung des Arrays erfolgt statisch über den Konfigurationsparameter ecuc(Csm/CsmPrimitives/CsmDecrypt/CsmDecryptConfig/CsmDecryptDataMaxLength) [SWS_Csm_01923]. Zusätzlich unterliegt der Datentyp einer kryptografischen Varianz gemäß Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME} [SWS_Csm_01923]. Dadurch wird der Typbezeichner für die konkrete Primitive-Konfiguration mit dem entsprechenden Kurznamen zu Csm_DecryptDataType_{Crypto} instanziiert [SWS_Csm_01923].

Einbindung und Randbedingungen

Die Definition wird über die Header-Datei Rte_Csm_Type.h für das Gesamtsystem bereitgestellt [SWS_Csm_01923]. Interpretation: Die Aufnahme in Rte_Csm_Type.h lässt darauf schließen, dass der Typ vor allem für typisierte Ports und den Datenaustausch zwischen Software-Komponenten und dem Modul CSM über die RTE bestimmt ist. Frage Q-6dcc31d5d7258088 (offen) Da es sich um eine Datenstruktur und nicht um eine Funktion handelt, sind im Spezifikationsumfang weder synchrone oder asynchrone Aufrufsemantiken noch Reentranz-Vorgaben oder spezifische DET-Fehlermeldungen definiert [SWS_Csm_01923].

Der Datentyp Csm_DecryptResultType ist gemäß [SWS_Csm_01924] im Modul Csm als Array mit Elementen des Typs uint8 definiert. Er dient als Datenpuffer zur Speicherung der Ergebnisdaten eines entschlüsselten Klartexts und muss ausreichend dimensioniert sein, um den vollständigen Klartext aufzunehmen.

Für die Konfiguration, Bereitstellung und Strukturierung des Typs gelten nach [SWS_Csm_01924] folgende Festlegungen:

• Header-Verfügbarkeit: Die Definition des Datentyps wird über die Header-Datei Rte_Csm_Type.h zur Verfügung gestellt.
• Dimensionierung des Puffers: Die Größe des Arrays wird über den Konfigurationsparameter CsmDecryptResultMaxLength (Pfad Csm/CsmPrimitives/CsmDecrypt/CsmDecryptConfig/CsmDecryptResultMaxLength) vorgegeben, wodurch der maximale Speicherplatz für das Entschlüsselungsergebnis statisch festgelegt wird.
• Kryptografische Variantenbildung: Der Typname unterliegt einer Primitiven-Variantenbildung gemäß dem Schema Csm_DecryptResultType_{Crypto}, wobei die Ausprägung über das Konfigurationselement Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME} gesteuert wird.

Hinsichtlich Aufrufkontext, Nebenläufigkeit und Fehlerbehandlung enthält [SWS_Csm_01924] ausschließlich die Typdefinition ohne eigene Funktionslogik. Interpretation: Der Typ dürfte vor allem in anwendenden Software-Komponenten als Speicherstruktur dienen, um Ausgabedaten von kryptografischen Entschlüsselungsoperationen des CSM aufzunehmen. Frage Q-54c836ed946ee1f2 (offen) Spezifische DET- oder DEM-Fehlercodes sind für diesen Datentyp nicht definiert; Konfigurationsverantwortliche müssen jedoch gewährleisten, dass die konfigurierte Maximallänge für alle zu verarbeitenden Klartexte ausreicht.

Verwendung und Typdefinition

Der Datentyp Csm_AEADEncryptPlaintextType dient gemäß [SWS_Csm_01925] als Datenpuffer für den Klartext, der im Rahmen einer AEAD-Verschlüsselungsoperation (Authenticated Encryption with Associated Data) verarbeitet werden soll. Der Typ ist als Byte-Array mit dem Elementtyp uint8 definiert und bietet ausreichend Speicherplatz, um den zu verschlüsselnden Klartext vollständig aufzunehmen.

Dimensionierung und Variantenbildung

Die konkrete Puffergröße ist nicht starr vorgegeben, sondern richtet sich nach dem Konfigurationsparameter CsmAEADEncryptPlaintextMaxLength aus der Konfiguration der jeweiligen Primitive ([SWS_Csm_01925]). Zudem unterliegt der Typ einer Namens- und Strukturvariation: In Abhängigkeit von der konfigurierten Kryptoprimitive wird der Bezeichner um den Kurznamen der Primitive erweitert (Csm_AEADEncryptPlaintextType_{Crypto}).

Einbindung und Schnittstelle

Gemäß [SWS_Csm_01925] wird der Typ über den Header Rte_Csm_Type.h bereitgestellt. Dies spricht für die Interpretation, dass der Typ vor allem im Kontext der AUTOSAR-RTE für Anwendungs-Softwarekomponenten zur Verfügung gestellt wird, um typisierte Klartextdaten an kryptografische Services des CSM zu übergeben. Da es sich um eine reine Typdeklaration handelt, definiert die Spezifikation keine eigenen Fehlercodes oder Reentranz-Vorgaben auf Datentypebene.

Der Datentyp Csm_AEADEncryptAssociatedDataType definiert ein Byte-Array aus Elementen des Basistyps uint8, das als Puffer zur Aufnahme der Header- bzw. assoziierten Zusatzdaten bei AEAD-Verschlüsselungsoperationen dient [SWS_Csm_01928]. Der Typ wird über die Header-Datei Rte_Csm_Type.h bereitgestellt und ermöglicht den typisierten Datenaustausch über das AUTOSAR-RTE-Interface des Crypto Service Managers [SWS_Csm_01928].

Die Dimensionierung und Ausprägung des Typs hängen von der Konfiguration der kryptografischen Primitive ab [SWS_Csm_01928]:

• Array-Größe: Die Puffergröße bemisst sich nach dem Konfigurationsparameter CsmAEADEncryptAssociatedDataMaxLength innerhalb der Konfiguration Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig, wodurch sichergestellt wird, dass das Array ausreichend lang für die Header-Daten ist [SWS_Csm_01928].
• Namensvariation: Das Element unterliegt einer kryptografiespezifischen Namensvariation Csm_AEADEncryptAssociatedDataType_{Crypto}, wobei der Platzhalter {Crypto} dem Kurznamen der jeweiligen Primitive aus CsmPrimitives.SHORT-NAME entspricht [SWS_Csm_01928].

Aufrufer müssen bei der Belegung des Arrays sicherstellen, dass die tatsächliche Länge der zu übertragenden Header-Daten die konfigurierte Maximalgröße nicht überschreitet [SWS_Csm_01928]. Interpretation: Da assoziierte Daten bei AEAD-Verfahren unverschlüsselt bleiben, aber authentifiziert werden, dürfte der Datentyp vor allem dazu dienen, protokollspezifische Metadaten konsistent zwischen Anwendung und CSM zu übergeben. Frage Q-26b724044c51253f (offen)

Der Datentyp Csm_AEADEncryptCiphertextType dient gemäß [SWS_Csm_01927] als Byte-Array zur Speicherung der Chiffredaten bei kryptografischen AEAD-Verschlüsselungsoperationen im Classic-AUTOSAR-Modul Csm.

Die Spezifikation definiert das Datenelement als ein Array aus Elementen des Basistyps uint8 [SWS_Csm_01927]. Die feste Puffergröße wird über den Konfigurationsparameter CsmAEADEncryptCiphertextMaxLength innerhalb des Konfigurationspfads Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig bestimmt [SWS_Csm_01927]. Gemäß Anforderung muss das Array lang genug bemessen sein, um die vollständigen Daten der Chiffre aufzunehmen [SWS_Csm_01927].

Der Typbezeichner weist eine Primitiven-abhängige Namensvariation auf: Über das Konfigurationsattribut Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME} wird der konkrete Typname zu Csm_AEADEncryptCiphertextType_{Crypto} expandiert [SWS_Csm_01927]. Bereitgestellt wird diese Definition für Anwendungs-Software-Komponenten sowie das CSM über die Header-Datei Rte_Csm_Type.h [SWS_Csm_01927].

In der praktischen Nutzung dürften aufrufende Komponenten entsprechende Puffer deklarieren, um die Chiffrierergebnisse einer AEAD-Operation entgegenzunehmen. Frage Q-af095525ea319451 (offen) Spezifische Aufrufkontexte, Fehlerbehandlungen (wie DET oder DEM), Rückgabewerte oder Reentranz-Vorgaben sind für diese Datenstruktur in den Quellen nicht definiert.

Der Datentyp Csm_AEADEncryptTagType definiert gemäß [SWS_Csm_01926] ein Byte-Array (Elementtyp uint8), das als Puffer für die Daten des Authentifizierungs-Tags bei AEAD-Verschlüsselungsoperationen dient. Das Array ist spezifikationsgemäß lang genug ausgelegt, um die Daten des Tags vollständig aufzunehmen [SWS_Csm_01926].

Hinsichtlich Struktur und Konfiguration gelten die folgenden Festlegungen aus [SWS_Csm_01926]:

• Puffergröße: Die Dimensionierung des Arrays wird über den Konfigurationsparameter CsmAEADEncryptTagLength unter Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig festgelegt [SWS_Csm_01926].
• Namensvariante: Der Typname besitzt eine kryptografische Varianz und wird gemäß dem Schema Csm_AEADEncryptTagType_{Crypto} gebildet, wobei {Crypto} dem Kurznamen der jeweiligen Primitive (SHORT-NAME) entspricht [SWS_Csm_01926].
• Header-Einbindung: Der Typ wird über den Header Rte_Csm_Type.h bereitgestellt [SWS_Csm_01926].

Durch die Verfügbarkeit in Rte_Csm_Type.h dürfte der Datentyp für standardisierte Softwareschnittstellen bestimmt sein (Interpretation: Nutzung zur Pufferübergabe in Software-Komponenten-Ports) [SWS_Csm_01926]. Frage Q-3cd2f6ae1229483e (offen)

Verwendung und Aufbau

Der Datentyp Csm_AEADDecryptCiphertextType definiert gemäß [SWS_Csm_00922] ein Byte-Array auf Basis des Elementtyps uint8. Er dient als ausreichend dimensionierter Puffer zur Aufnahme des Chiffretexts, der im Rahmen einer AEAD-Operation (Authenticated Encryption with Associated Data) entschlüsselt werden soll [SWS_Csm_00922]. Die Bereitstellung der Typdefinition erfolgt über die Header-Datei Rte_Csm_Type.h [SWS_Csm_00922].

Dimensionierung und Varianz

Die Dimensionierung des Feldes erfolgt statisch anhand des Konfigurationsparameters CsmAEADDecryptCiphertextMaxLength innerhalb des Konfigurationszweigs Csm/CsmAEADDecrypt/CsmAEADDecryptConfig [SWS_Csm_00922]. Das Array ist so ausgelegt, dass es den gesamten zu verarbeitenden Chiffretext fassen kann. Zudem unterliegt der Typname einer kryptografischen Varianz gemäß dem Muster Csm_AEADDecryptCiphertextType_{Crypto}, wobei der Bezeichneranteil {Crypto} durch den Kurznamen des jeweiligen Primitivs (CsmPrimitives.SHORT-NAME) gebildet wird [SWS_Csm_00922].

Zusammenspiel und Randbedingungen

Aufgrund der Definition in Rte_Csm_Type.h dürfte der Typ primär für die typisierte Anbindung von Software-Komponenten (SW-Cs) über RTE-Ports an das Crypto Service Gateway bzw. CSM vorgesehen sein [SWS_Csm_00922]. Frage Q-35738ff5fc96c699 (offen) Da die Array-Größe zur Konfigurationszeit fest vorgegeben wird, müssen Aufrufer sicherstellen, dass die Chiffretextdaten die Maximallänge nicht überschreiten, um Pufferüberläufe zur Laufzeit auszuschließen.

Der Datentyp Csm_AEADDecryptAssociatedDataType ist als ein Array aus Elementen des Typs uint8 definiert und trägt das formationsabhängige Namensmuster Csm_AEADDecryptAssociatedDataType_{Crypto} [SWS_Csm_00923]. Zweck dieses Datentyps ist die Bereitstellung eines Speicherbereichs, der ausreichend dimensioniert ist, um die Header-Daten bzw. assoziierten Zusatzdaten (Associated Data) einer authentifizierten Entschlüsselung (AEAD Decrypt) aufzunehmen [SWS_Csm_00923].

Die Größe des Arrays richtet sich nach dem Konfigurationsparameter CsmAEADDecryptAssociatedDataMaxLength im Konfigurationspfad Csm/CsmAEADDecrypt/CsmAEADDecryptConfig [SWS_Csm_00923]. Über die Varianz Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME} wird der Typbezeichner für das jeweilige im Crypto Service Manager konfigurierte Primitiv über dessen Kurznamen spezialisiert [SWS_Csm_00923]. Dadurch kann für jedes kryptografische Primitiv ein spezifischer Puffer mit passender Maximallänge deklariert werden.

Der Datentyp wird über die Header-Datei Rte_Csm_Type.h exportiert [SWS_Csm_00923]. Da es sich um eine reine Typdefinition handelt, spezifiziert der Eintrag keine Fehlercodes, DET-Meldungen oder Wiedereintrittsbedingungen. Als Interpretation dürfte das Array als typisierter Datenpuffer für die Übergabe unverschlüsselter, aber kryptografisch zu verifizierender Begleitdaten zwischen Software-Komponenten und dem CSM über die RTE dienen. Frage Q-2f32bbe9a4489b27 (offen)

Verwendung und Zweck

Der Datentyp Csm_AEADDecryptTagType ist als Byte-Array mit dem Elementtyp uint8 definiert und dient als dedizierter Speicherbereich zur Aufnahme der Tag-Daten bei AEAD-Entschlüsselungsoperationen [SWS_Csm_01074]. Die Bereitstellung erfolgt über die Header-Datei Rte_Csm_Type.h [SWS_Csm_01074].

Dimensionierung und Konfigurationsabhängigkeit

Die Dimensionierung des Arrays ist konfigurierbar und richtet sich nach der konfigurierten Tag-Länge CsmAEADDecryptTagLength [SWS_Csm_01074]. Die Elementanzahl wird über den Ausdruck (({ecuc(Csm/CsmPrimitives/CsmAEADDecrypt/CsmAEADDecryptConfig/CsmAEADDecryptTagLength)}+7)/8) ermittelt [SWS_Csm_01074]. Durch diese Berechnung wird die in Bits angegebene Tag-Länge in vollständige Bytes umgerechnet, wobei nicht durch acht teilbare Bitlängen auf die nächste Bytegrenze aufgerundet werden.

Der Typ unterliegt einer Namensvariation gemäß dem Schema Csm_AEADDecryptTagType_{Crypto}, wobei {Crypto} durch den Kurznamen (SHORT-NAME) der jeweiligen Primitiv-Konfiguration ersetzt wird [SWS_Csm_01074]. Dadurch existiert für jede konfigurierte AEAD-Entschlüsselungs-Primitiv-Instanz eine passend typisierte Struktur.

Integrations- und Randbedingungen

Die Bereitstellung über Rte_Csm_Type.h dürfte bedeuten, dass dieser Typ vor allem für Software-Komponenten an Ports der AUTOSAR-RTE vorgesehen ist, um das Authentifizierungs-Tag an den Crypto Service Manager zu übergeben [SWS_Csm_01074]. Frage Q-2a0bebbb8e1d6b76 (offen) Da der Typ keine eigenen Kontrollflüsse oder Synchronisationsmechanismen mitbringt, wird die Konsistenz der Daten im Puffer vermutlich vollständig durch den aufrufenden Kontext während des Entschlüsselungszyklus gewährleistet.

Verwendung und Struktur

Der Datentyp Csm_AEADDecryptPlaintextType bzw. dessen primitivenspezifische Variante Csm_AEADDecryptPlaintextType_{Crypto} ist als Byte-Array mit Elementen des Typs uint8 definiert [SWS_Csm_01075]. Er dient dazu, einen ausreichend dimensionierten Puffer zur Speicherung der Klartextdaten bei einer AEAD-Entschlüsselung (Authenticated Encryption with Associated Data) bereitzustellen [SWS_Csm_01075]. Die feste Feldgröße wird über den Konfigurationsparameter CsmAEADDecryptPlaintextMaxLength innerhalb der Konfiguration der jeweiligen AEAD-Entschlüsselungs-Primitive bestimmt [SWS_Csm_01075]. Über den Header Rte_Csm_Type.h wird der Datentyp für Software-Komponenten bereitgestellt, wobei der Typname über die Variation Crypto an den Kurznamen der konfigurierten CSM-Primitiven gekoppelt ist [SWS_Csm_01075].

Fehlerbehandlung und Nebenläufigkeit

Da es sich um eine reine Typdefinition handelt, definiert das Element keine eigenen Rückgabewerte, Fehlercodes oder DET-Meldungen [SWS_Csm_01075]. Die wesentliche funktionale Randbedingung liegt in der statisch festgelegten Maximallänge: Klartextdaten, welche die konfigurierte Grenze überschreiten, können in diesem Puffer nicht abgebildet werden [SWS_Csm_01075]. Interpretation: Der Typ dürfte primär zur typisierten Datenübergabe über RTE-Ports dienen, wenn SWCs asynchron oder synchron Ergebnisse von Entschlüsselungsdiensten empfangen. Frage Q-2de04243d7f996c8 (offen) Aufrufer müssen vermutlich eigenständig sicherstellen, dass Puffergrenzen eingehalten werden und gleichzeitige Schreib- oder Lesezugriffe über mehrere Tasks hinweg threadsicher synchronisiert sind.

Der Typ Csm_SignatureGenerateDataType definiert laut [SWS_Csm_01083] ein Array aus uint8-Elementen, das als Puffer zur Aufnahme der Daten dient, aus denen eine kryptografische Signatur erzeugt werden soll. Die konkrete Namensgebung im Quellcode ist primitivespezifisch und folgt dem Muster Csm_SignatureGenerateDataType_{Crypto}, wobei der Bezeichner über den Kurznamen der konfigurierten Kryptoprimitive variiert wird [SWS_Csm_01083].

Die statische Dimensionierung des Datenfelds wird über den Konfigurationsparameter CsmSignatureGenerateDataMaxLength bestimmt [SWS_Csm_01083]. Der Datentyp wird über die Header-Datei Rte_Csm_Type.h bereitgestellt [SWS_Csm_01083]. Interpretation: Wegen der Bereitstellung über Rte_Csm_Type.h dürfte der Array-Typ primär für die typisierte Datenübergabe an RTE-Ports zwischen Software-Komponenten und dem Modul CSM vorgesehen sein. Frage Q-dcc731a5b8961aef (offen)

Bei der Konfiguration und Verwendung ist zu beachten, dass CsmSignatureGenerateDataMaxLength die feste Obergrenze des Arrays festlegt [SWS_Csm_01083]. Anwender müssen konfigurativ sicherstellen, dass die Puffergröße für alle im Betrieb auftretenden Eingabedaten der Signaturerzeugung ausreicht, da das Array statisch alloziert wird.

Der Datentyp Csm_SignatureGenerateResultType definiert gemäß [SWS_Csm_01077] ein Byte-Array auf Basis von uint8, das zur Aufnahme einer erzeugten kryptografischen Signatur sowie deren Längenangabe dient. Der Typ wird über den Header Rte_Csm_Type.h deklariert und stellt den standardisierten Ausgabepuffer für Signaturoperationen im Crypto Service Manager bereit.

Die Struktur und Dimensionierung des Typs sind konfigurierbar:

• Puffergröße: Die Anzahl der uint8-Elemente wird über den Konfigurationsparameter CsmSignatureGenerateResultLength der jeweiligen Signaturerzeugungs-Konfiguration vorgegeben ([SWS_Csm_01077]).
• Namensvariante: Der Bezeichner enthält das Suffix _{Crypto}, welches dem Kurznamen des konfigurierten Primitivs entspricht ([SWS_Csm_01077]).

Da es sich um eine reine Typdefinition handelt, enthält [SWS_Csm_01077] keine Spezifikation von Fehlercodes, DET-Meldungen oder Reentranzeigenschaften. Laufzeitsemantik und Pufferübergabe dürften sich nach den synchronen oder asynchronen Aufrufkonventionen der CSM-Dienstschnittstellen richten. Frage Q-3304c06a29f069a2 (offen) Aufrufer müssen sicherstellen, dass die konfigurierte Array-Größe für die aufzunehmende Signatur inklusive Längenwert stets ausreicht.

Der Datentyp Csm_SignatureVerifyDataType ist gemäß [SWS_Csm_01078] als Byte-Array mit dem Elementtyp uint8 definiert und dient zur Pufferung von Daten, deren Signatur verifiziert werden soll.

Für die Konfiguration und Verwendung des Typs gelten gemäß [SWS_Csm_01078] folgende Festlegungen:

• Array-Dimensionierung: Die Größe des Feldes entspricht dem Konfigurationswert CsmSignatureVerifyDataMaxLength aus dem Konfigurationspfad Csm/CsmPrimitives/CsmSignatureVerify/CsmSignatureVerifyConfig, sodass das Array ausreichend dimensioniert ist, um die gesamten zu prüfenden Daten aufzunehmen.
• Namensvariation: Der Typname variiert abhängig von der jeweiligen Kryptoprimitive nach dem Schema Csm_SignatureVerifyDataType_{Crypto}, wobei {Crypto} dem Kurznamen CsmPrimitives.SHORT-NAME entspricht.
• Header-Bereitstellung: Die Typdefinition ist über die Header-Datei Rte_Csm_Type.h verfügbar.

Interpretation: Durch die Bereitstellung in Rte_Csm_Type.h dürfte der Typ vor allem für Software-Komponenten an der RTE-Schnittstelle bestimmt sein, um Nutzdaten bis zur konfigurierten Maximallänge für die Signaturprüfung an den Crypto Service Manager zu übergeben [SWS_Csm_01078]. Frage Q-c1541703c2bcd199 (offen)

Der Typ Csm_SignatureVerifyCompareType definiert ein Byte-Array auf Basis von uint8, das ausreichend Speicherplatz für eine zu verifizierende kryptografische Signatur bereitstellt ([SWS_Csm_01079]). Er wird über den Header Rte_Csm_Type.h zur Verfügung gestellt und ermöglicht Software-Komponenten den typisierten Zugriff auf Signaturvergleichsdaten ([SWS_Csm_01079]).

Konfiguration und Varianz

Die konkrete Größe des Arrays ist nicht fest vorgegeben, sondern richtet sich nach dem Konfigurationswert CsmSignatureVerifyCompareLength aus der Signatur-Verifikationskonfiguration der jeweiligen Primitiven ([SWS_Csm_01079]). Zudem unterliegt der Typ einer Namensvariation über den Kurznamen der kryptografischen Primitive (Crypto = {ecuc/Csm/CsmPrimitives.SHORT-NAME}), sodass der typisierte Bezeichner als Csm_SignatureVerifyCompareType_{Crypto} gebildet wird ([SWS_Csm_01079]).

Nutzungsaspekte und Randbedingungen

• Aufrufkontext und Semantik: Als reine Datenstruktur besitzt das Element keine eigenständige synchrone oder asynchrone Semantik. Die Instanziierung erfolgt typischerweise durch den Aufrufer von Verifikationsdiensten des Moduls ([SWS_Csm_01079]).
• Fehlerbehandlung: Die Typdefinition definiert keine eigenen Fehlercodes oder DET-/DEM-Meldungen ([SWS_Csm_01079]). Interpretation: Eine Validierung der Pufferlänge oder Zeigerintegrität dürfte in den nutzenden CSM-Funktionen stattfinden. Frage Q-60454c8a7d8035cf (offen)
• Nebenläufigkeit: Für reine Typdefinitionen bestehen keine Einschränkungen zur Reentranz; der nebenläufige Zugriff auf Pufferinstanzen ist durch die nutzenden Module zu koordinieren ([SWS_Csm_01079]).

Verwendung und Zweck

Der Datentyp Csm_RandomGenerateResultType ist als Array definiert und dient als strukturierter Speicherbereich zur Ablage der Ergebnisdaten einer generierten Zufallszahl [SWS_Csm_00930]. Die einzelnen Elemente des Arrays besitzen den Basistyp uint8, wodurch die resultierende Zufallszahl als zusammenhängende Bytefolge abgebildet wird [SWS_Csm_00930].

Konfiguration und Variantenbildung

Die Puffergröße wird nicht dynamisch übergeben, sondern statisch über die Modulkonfiguration festgelegt: Die Anzahl der Array-Elemente richtet sich nach dem Konfigurationsparameter CsmRandomGenerateResultLength unterhalb des Pfads Csm/CsmPrimitives/CsmRandomGenerate/CsmRandomGenerateConfig [SWS_Csm_00930]. Zudem unterliegt der Bezeichner einer kryptografiespezifischen Namensvariation nach dem Schema Csm_RandomGenerateResultType_{Crypto}, wobei der Suffix dem Kurznamen des jeweiligen Primitives entspricht [SWS_Csm_00930]. Auf diese Weise erhält jede konfigurierte Instanz der Zufallsgenerierung einen typkonformen Puffer passender Länge.

Einbindung und Randbedingungen

Die Deklaration des Typs wird über die Header-Datei Rte_Csm_Type.h bereitgestellt [SWS_Csm_00930]. Interpretation: Da die Bereitstellung über den RTE-Header erfolgt, dürfte dieser Datentyp primär für Application Software Components vorgesehen sein, um Zufallswerte über Ports typsicher entgegenzunehmen. Frage Q-ea993612037bec12 (offen) Konkrete API-Aufrufkontexte, Fehlercodes oder Nebenläufigkeitsaspekte sind nicht am Typ selbst, sondern an den zugehörigen CSM-Diensten verankert, während dieser Typ die statische Speicheranforderung absichert [SWS_Csm_00930].

Verwendung und Semantik

Der Typ Csm_VerifyResultPtr ist ein AUTOSAR-Implementation-Data-Type der Kategorie DATA_REFERENCE, dessen Zeigerziel Csm_VerifyResultType ist (formal Csm_VerifyResultType*) [SWS_Csm_91046]. Die Typdefinition wird über den Header Rte_Csm_Type.h bereitgestellt und steht damit für Anwendungskomponenten über die RTE sowie für Basissoftware-Module zur Verfügung [SWS_Csm_91046].

Die funktionale Aufgabe von Csm_VerifyResultPtr besteht darin, das Verifikationsergebnis bei asynchronen kryptografischen Operationen zurückzuliefern [SWS_Csm_91046]. Bei asynchroner Ausführung verweist der Zeiger auf einen vom Aufrufer reservierten Puffer, in den das Modul Csm nach Abschluss der Prüfung das Ergebnis einträgt [SWS_Csm_91046].

Nebenläufigkeit und Einschränkungen

Da Csm_VerifyResultPtr explizit für die asynchrone Rückmeldung vorgesehen ist [SWS_Csm_91046], müssen Anwender sicherstellen, dass die Gültigkeit des referenzierten Zielobjekts über die gesamte Operationsdauer erhalten bleibt. Folgende Aspekte sind dabei zu berücksichtigen:

• Der referenzierte Speicherbereich vom Typ Csm_VerifyResultType dürfte während der gesamten asynchronen Ausführungszeit bis zum Eintreffen der Rückmeldung gültig und geschützt bleiben müssen (Interpretation: Vermeidung von Schreibzugriffen auf ungültige Speicheradressen). Frage (offen)
• Aufrufer sollten den Zeiger vermutlich nicht auf flüchtige Stack-Variablen richten, wenn die aufrufende Funktion bereits vor Abschluss des asynchronen Auftrags verlassen werden kann. Frage (offen)

Der Enumerationstyp Crypto_KeyStatusType definiert den Gültigkeitsstatus kryptografischer Schlüssel und wird über die Header-Datei Rte_Csm_Type.h bereitgestellt [SWS_Csm_91102].

Wertebereich und Semantik

Der Typ umfasst zwei Ausprägungen [SWS_Csm_91102]:

• CRYPTO_KEYSTATUS_INVALID (0x00): Der Status des Schlüssels ist ungültig. Dies tritt beispielsweise auf, wenn nach dem Setzen eines Schlüsselelements mittels Csm_KeyElementSet die Funktion Csm_KeySetValid noch nicht ausgeführt wurde.
• CRYPTO_KEYSTATUS_VALID (0x01): Der Schlüssel ist gültig, nachdem der Status etwa durch den erfolgreichen Aufruf von Csm_KeySetValid gesetzt wurde.

Reihenfolgebedingungen und Zusammenspiel

Die Zustandslogik koppelt die Gültigkeit direkt an die Aktualisierungsabläufe des Schlüsselmanagements: Jede Modifikation von Schlüsselelementen versetzt den Schlüssel in einen ungültigen Zwischenzustand, der erst durch die explizite Validierung über Csm_KeySetValid beendet wird [SWS_Csm_91102]. Interpretation: Aufrufer und kryptografische Dienste dürften daher vor der Ausführung von kryptografischen Operationen den Status CRYPTO_KEYSTATUS_VALID voraussetzen, um Fehlfunktionen durch unvollständige Schlüsseldaten auszuschließen. Frage Q-7ad50e0568814efa (offen)