Crypto Service Manager (CSM)

The synchronous function Csm_Init serves to initialize the Crypto Service Manager (CSM) module according to [SWS_Csm_00646]. The interface is declared via header Csm.h [SWS_Csm_00646].

With regard to parameters and call behavior, [SWS_Csm_00646] defines the following properties:

• Parameters: configPtr is passed as an input parameter. This is a pointer to a selected configuration structure of type const Csm_ConfigType* [SWS_Csm_00646]. In/out parameters or output parameters are not present [SWS_Csm_00646].
• Return value: The function has no return value (void) [SWS_Csm_00646].
• Synchronicity and identification: Execution is synchronous; the service ID is 0x00 [SWS_Csm_00646].

According to [SWS_Csm_00646], specific requirements apply to concurrency and multi-partition operation:

• Reentrancy: The function is non-reentrant (Non Reentrant) and may therefore not be called concurrently [SWS_Csm_00646].
• Partitioning: If the CSM module is assigned to more than one partition (that is, if main functions such as Csm_MainFunction are distributed across partitions), the CSM may provide a dedicated initialization function per partition [SWS_Csm_00646].

Interpretation: Since the specification defines Csm_Init as an initialization function, the call is likely typically made during the system startup phase before regular cryptographic jobs are executed. Question Q-f462c3f9f4ed24fc (open)

use

Function Csm_Hash calculates a cryptographic hash value over the passed input data and saves the result in the destination memory [SWS_Csm_00980]. The interface is declared via header Csm.h and has service ID 0x5d [SWS_Csm_00980]. The execution behavior is either synchronous or asynchronous, depending on the respective configuration of the job specified via jobId [SWS_Csm_00980].

The parameters are structured as follows [SWS_Csm_00980]:

• jobId: Unique identifier of the CSM job utilizing the cryptographic service.
• mode: Indicates which operation mode or operation modes are to be executed.
• dataPtr and dataLength: Pointer to the input data to be hashed and the number of bytes to be processed.
• resultPtr: Pointer to the buffer in which the calculated hash value is stored.
• resultLengthPtr: Prior to the call, this pointer must contain the provided capacity of buffer resultPtr in bytes. After processing is completed, this value is overwritten with the actual byte length of the generated hash value. If the provided buffer is smaller than the total length of the result, the hash value is stored truncated.

Error Handling and Concurrency

The return value of type Std_ReturnType signals a successful request with E_OK and an error during job processing with E_NOT_OK [SWS_Csm_00980]. With regard to concurrency, Csm_Hash is specified as reentrant [SWS_Csm_00980].

The reentrant function Csm_MacGenerate (service ID 0x60, header Csm.h) calculates a Message Authentication Code (MAC) over the passed input data and stores the result at the specified destination address [SWS_Csm_00982]. Whether processing is synchronous or asynchronous depends on the configuration of the job referenced via jobId [SWS_Csm_00982].

Parameter mode specifies the operation modes to be executed. Input data is passed via dataPtr and its number of bytes via dataLength [SWS_Csm_00982]. Buffer macPtr receives the result. Via the in/out parameter macLengthPtr, the size of the provided buffer must be passed upon the call; after completion of the request, the actual length of the calculated MAC is stored therein. If the buffer is smaller than the total result, the MAC is stored truncated [SWS_Csm_00982].

Possible return values of type Std_ReturnType are [SWS_Csm_00982]:

• E_OK: Request executed successfully.
• E_NOT_OK: Request failed.
• CRYPTO_E_BUSY: Service is still busy.
• CRYPTO_E_KEY_NOT_VALID: Key state is invalid.
• CRYPTO_E_KEY_SIZE_MISMATCH: A key element has an incorrect size.
• CRYPTO_E_KEY_EMPTY: The source key element is not initialized.

According to [SWS_Csm_01050], the function Csm_MacVerify is used to verify a Message Authentication Code (MAC) by checking whether the passed MAC matches the provided data. The result of the verification is stored at the memory location pointed to by verifyPtr. The service is available via the header file Csm.h and is specified as reentrant.

When calling, the following parameters and semantics must be observed [SWS_Csm_01050]:

• Synchronous or asynchronous behavior: Execution is synchronous or asynchronous depending on the configuration of the job referenced via jobId.
• Operation mode: The operation modes to be executed are specified via mode (Crypto_OperationModeType).
• Length indications: While dataLength specifies the number of data bytes for dataPtr, macLength strictly requires the length of the MAC to be verified in bits.

As a return value, the function returns the status of the request as Std_ReturnType [SWS_Csm_01050]:

• E_OK: The request was successful.
• E_NOT_OK: The request has failed.
• CRYPTO_E_BUSY: The service is still busy.
• CRYPTO_E_KEY_NOT_VALID: The state of the key is invalid.
• CRYPTO_E_KEY_SIZE_MISMATCH: A key element has an incorrect size.
• CRYPTO_E_KEY_EMPTY: The source key element is uninitialized.

Function Csm_Encrypt (service ID 0x5e, provided via Csm.h) encrypts the passed input data and stores the ciphertext in the specified result buffer [SWS_Csm_00984].

Usage and Semantics

To perform the operation, the following parameters are passed [SWS_Csm_00984]:

• jobId: Identifier of the CSM job using the service.
• mode: Designates the operation mode or modes to be executed (of type Crypto_OperationModeType).
• dataPtr and dataLength: Pointer to the input data to be encrypted and the number of bytes to be processed.
• resultPtr: Pointer to the memory area where the encrypted data is stored.
• resultLengthPtr: Pointer to the length information in bytes. Prior to the call, this parameter must contain the provided buffer capacity of resultPtr; after completion of the request, the actual output length is stored there [SWS_Csm_00984].

Execution semantics are not statically defined: they are synchronous or asynchronous depending on the configuration of the assigned job [SWS_Csm_00984].

Concurrency and Limitations

The function is specified as reentrant [SWS_Csm_00984]. Callers must ensure that buffer resultPtr remains valid throughout the entire processing until completion of the operation and has at least the size initially specified via resultLengthPtr.

Error Handling and Return Values

The return value of type Std_ReturnType provides information about the request status [SWS_Csm_00984]:

• E_OK: Request successful.
• E_NOT_OK: Request failed.
• CRYPTO_E_BUSY: Request rejected because the service is currently still busy.
• CRYPTO_E_KEY_NOT_VALID: The specified key is in the "invalid" state.
• CRYPTO_E_KEY_SIZE_MISMATCH: A key element has an invalid size.
• CRYPTO_E_KEY_EMPTY: An uninitialized source key element was passed.

The function Csm_Decrypt ([SWS_Csm_00989]) decrypts passed ciphertext data and stores the resulting plaintext in the destination memory area. It is provided via header Csm.h and executes cryptographic operations based on the configuration of the passed job.

Usage and Parameters

Via parameter jobId, the CSM job to be used is addressed, while mode (type Crypto_OperationModeType) specifies the operation phase(s) to be executed ([SWS_Csm_00989]). The data to be decrypted is passed as pointer dataPtr with the byte count dataLength. The plaintext is written into the buffer referenced by resultPtr.

The in-out parameter resultLengthPtr controls buffer management: on call, it must contain the provided buffer size of resultPtr in bytes; after completion of the operation, the actually written output length is stored there ([SWS_Csm_00989]).

Execution and Return Values

The execution behavior (synchronous or asynchronous) depends directly on the underlying job configuration ([SWS_Csm_00989]). The function is designed to be reentrant and returns specific return values of type Std_ReturnType:

• E_OK: The request was successful ([SWS_Csm_00989]).
• E_NOT_OK: The request failed ([SWS_Csm_00989]).
• CRYPTO_E_BUSY: The requested service is currently still busy ([SWS_Csm_00989]).
• CRYPTO_E_KEY_NOT_VALID: The status of the key used is invalid ([SWS_Csm_00989]).
• CRYPTO_E_KEY_SIZE_MISMATCH: A key element has an unsuitable size ([SWS_Csm_00989]).
• CRYPTO_E_KEY_EMPTY: The source key element is uninitialized ([SWS_Csm_00989]).

use

The function Csm_AEADEncrypt performs authenticated encryption with associated data (AEAD) and is available via header Csm.h [SWS_Csm_01023]. Via plaintextPtr and plaintextLength, it processes the plaintext to be encrypted, and via associatedDataPtr and associatedDataLength, it processes additional associated data [SWS_Csm_01023]. The output data is written to buffers ciphertextPtr (ciphertext) and tagPtr (authentication tag or MAC) [SWS_Csm_01023]. Upon invocation, ciphertextLengthPtr and tagLengthPtr must contain the provided buffer capacity in bytes; after completion, they contain the actual length of the output values [SWS_Csm_01023] (Interpretation: The parameter resultPtr mentioned in the specification presumably refers to ciphertextPtr or tagPtr due to an editorial issue). Question Q-ea7e69875375c501 (open) The operation mode to be performed is selected via mode [SWS_Csm_01023]. Execution takes place synchronously or asynchronously depending on the job configuration of the passed jobId [SWS_Csm_01023].

Error Handling and Return Values

The service provides the following status values via the return type Std_ReturnType [SWS_Csm_01023]:

• E_OK: The request was successful [SWS_Csm_01023].
• E_NOT_OK: The request has failed [SWS_Csm_01023].
• CRYPTO_E_BUSY: The request failed because the service is busy [SWS_Csm_01023].
• CRYPTO_E_KEY_NOT_VALID: The request failed because the status of the key is invalid [SWS_Csm_01023].
• CRYPTO_E_KEY_SIZE_MISMATCH: The request failed because a key element has an incorrect size [SWS_Csm_01023].
• CRYPTO_E_KEY_EMPTY: The request failed due to an uninitialized source key element [SWS_Csm_01023].

Concurrency

The interface is specified as reentrant [SWS_Csm_01023].

The service Csm_AEADDecrypt (service ID 0x63, provided via Csm.h) performs an AEAD decryption (Authenticated Encryption with Associated Data) according to [SWS_Csm_01026]. Interpretation: Although the description in the specification text speaks of encryption, the function serves to decrypt ciphertext and verify the passed authentication tag based on the defined input and output parameters. Question Q-00e8fca03eb3b44d (open)

Execution is synchronous or asynchronous depending on the configuration of the job identified via jobId ([SWS_Csm_01026]). Regarding concurrency, the function is reentrant ([SWS_Csm_01026]). The parameter mode specifies which operation modes are to be processed.

The following parameter relationships apply to the call ([SWS_Csm_01026]):

• Input data: pointers and length indications for ciphertext (ciphertextPtr, ciphertextLength), associated data (associatedDataPtr, associatedDataLength), and the tag to be verified (tagPtr, tagLength).
• Output data: the buffer plaintextPtr receives the decrypted plaintext. The pointer plaintextLengthPtr must contain the buffer capacity on call; after completion, the actual output length is stored there.
• Verification result: the result of the tag verification is reported back via verifyPtr.

According to [SWS_Csm_01026], the following are specified as return values of type Std_ReturnType:

• E_OK: Request was successful.
• E_NOT_OK: Request has failed.
• CRYPTO_E_BUSY: Service is busy.
• CRYPTO_E_KEY_NOT_VALID: Key status is invalid.
• CRYPTO_E_KEY_SIZE_MISMATCH: Key element has the wrong size.
• CRYPTO_E_KEY_EMPTY: Source key element is uninitialized.

The function Csm_SignatureGenerate serves to compute the cryptographic signature over passed payload data according to [SWS_Csm_00992]. Whether the call is processed synchronously or asynchronously depends on the respective configuration of the passed job (jobId) [SWS_Csm_00992]. The function is specified as reentrant [SWS_Csm_00992].

When called, the parameter mode of type Crypto_OperationModeType controls the operation modes to be executed [SWS_Csm_00992]. The data to be signed is passed via dataPtr together with its byte length dataLength [SWS_Csm_00992]. The calculated signature is written to the memory area referenced by signaturePtr [SWS_Csm_00992]. The input/output parameter signatureLengthPtr must contain the provided buffer size in bytes before the call; after completion of the request, it contains the actual byte length of the generated signature [SWS_Csm_00992].

The return value signals the status of the function request [SWS_Csm_00992]:

• E_OK: Request executed or started successfully [SWS_Csm_00992].
• E_NOT_OK: General errors during the request [SWS_Csm_00992].
• CRYPTO_E_BUSY: The requested service is currently busy [SWS_Csm_00992].
• CRYPTO_E_KEY_NOT_VALID: The state of the key used is invalid [SWS_Csm_00992].
• CRYPTO_E_KEY_SIZE_MISMATCH: A key element has an unsuitable size [SWS_Csm_00992].
• CRYPTO_E_KEY_EMPTY: The source key element is not initialized [SWS_Csm_00992].

The service Csm_SignatureVerify (service ID 0x64, declared in Csm.h) serves to verify a cryptographic signature based on passed data [SWS_Csm_00996]. The specification describes the functionality comparatively as checking whether the signature (also referred to as MAC in the description) was generated with the passed data [SWS_Csm_00996].

Usage and parameters: Upon call, jobId identifies the configured CSM job, while mode (type Crypto_OperationModeType) specifies the operation modes to be executed [SWS_Csm_00996]. The payload data to be verified are passed via pointer dataPtr with the byte count dataLength [SWS_Csm_00996]. The signature to be validated is provided via signaturePtr along with its byte length signatureLength [SWS_Csm_00996]. The function stores the verification result at the memory location referenced by output parameter verifyPtr (type Crypto_VerifyResultType*) [SWS_Csm_00996]. The execution behavior is synchronous or asynchronous, depending on the respective job configuration [SWS_Csm_00996].

Error handling and return values: The function returns a status of type Std_ReturnType that signals the success or specific error states of the request [SWS_Csm_00996]:

• E_OK: The service request was successful [SWS_Csm_00996].
• E_NOT_OK: The service request has failed [SWS_Csm_00996].
• CRYPTO_E_BUSY: The request failed because the underlying service is still busy [SWS_Csm_00996].
• CRYPTO_E_KEY_NOT_VALID: The request failed because the state of the key is invalid [SWS_Csm_00996].
• CRYPTO_E_KEY_SIZE_MISMATCH: The request failed because a key element has the wrong size [SWS_Csm_00996].
• CRYPTO_E_KEY_EMPTY: The request failed due to an uninitialized source key element [SWS_Csm_00996].

Concurrency: According to the specification, the function is implemented as reentrant [SWS_Csm_00996].

The function Csm_RandomGenerate serves to generate random numbers and stores the result in the memory area to which resultPtr points [SWS_Csm_01543].

Usage and Parameters

The identifier of the configured CSM job that uses the service is passed via the parameter jobId [SWS_Csm_01543]. The caller controls the desired amount of data via the input and output parameter resultLengthPtr: Upon the call, this pointer must point to the number of random bytes to be generated, which are to be stored in the buffer resultPtr [SWS_Csm_01543]. After completion of the request, resultLengthPtr contains the actual byte length of the generated value [SWS_Csm_01543]. Processing takes place synchronously or asynchronously, depending on the configuration of the respective job [SWS_Csm_01543].

Return Values and Error Handling

The function returns a status of type Std_ReturnType [SWS_Csm_01543]:

• E_OK: The request was successful [SWS_Csm_01543].
• E_NOT_OK: The request failed [SWS_Csm_01543].
• CRYPTO_E_BUSY: The request failed because the service is still busy [SWS_Csm_01543].
• CRYPTO_E_ENTROPY_EXHAUSTED: The request failed because the entropy of the random number generator is exhausted [SWS_Csm_01543].

Concurrency

The function is designed to be reentrant and is available via the header Csm.h with the service ID 0x72 [SWS_Csm_01543].

Usage and Semantics

The synchronous function Csm_KeyElementSet sets the bytes of a specified key element for a key identified via keyId [SWS_Csm_00957]. The function has service ID 0x78 and is available via header Csm.h [SWS_Csm_00957]. For the call, the following input parameters are passed [SWS_Csm_00957]:

• keyId: Identifier of the key for which new key material is to be set [SWS_Csm_00957].
• keyElementId: Identifier of the key element to be written [SWS_Csm_00957].
• keyElementPtr: Pointer to the bytes of the key element to be processed [SWS_Csm_00957].
• keyElementLength: Number of bytes of the key element to be set [SWS_Csm_00957].

Return Values and Error Handling

Execution returns a status of type Std_ReturnType indicating success or specific root causes of errors [SWS_Csm_00957]:

• E_OK: The request was successful [SWS_Csm_00957].
• E_NOT_OK: The request failed [SWS_Csm_00957].
• CRYPTO_E_BUSY: The responsible crypto driver object is busy [SWS_Csm_00957].
• CRYPTO_E_KEY_WRITE_FAIL: Write access to the key element was denied [SWS_Csm_00957].
• CRYPTO_E_KEY_NOT_AVAILABLE: The addressed key is not available [SWS_Csm_00957].
• CRYPTO_E_KEY_SIZE_MISMATCH: The size of the key element does not match the size of the provided data [SWS_Csm_00957].

Concurrency and Limitations

Function Csm_KeyElementSet is specified as synchronous and non-reentrant (Non Reentrant) [SWS_Csm_00957]. It has no in/out (inout) or output parameters (out) [SWS_Csm_00957].

The synchronous function Csm_KeySetValid serves to set the key state of a key addressed via identifier keyId to valid after new key material has been provided [SWS_Csm_00958]. The service is provided via header Csm.h and has service ID 0x67 [SWS_Csm_00958].

The following specifications apply to usage and return values according to [SWS_Csm_00958]:

• Input parameter: Via keyId, the identifier of the key for which the new material is to be validated is passed.
• Return value E_OK: The request to validate the key state was successful.
• Return value E_NOT_OK: The request has failed.
• Return value CRYPTO_E_BUSY: The request failed because the underlying Crypto Driver Object is busy.

Regarding concurrency, Csm_KeySetValid is specified as non-reentrant [SWS_Csm_00958]. Callers might therefore need to ensure suitable synchronization if calls potentially occur from concurrent contexts. Question Q-1762a3bca77ab74e (open)

The synchronous function Csm_KeySetInvalid sets the status of a key to invalid [SWS_Csm_91075]. A key set to invalid can no longer be used for cryptographic operations until it has been transitioned to a valid state again [SWS_Csm_91075].

Usage and Parameters

The call is available via the header Csm.h and is executed synchronously [SWS_Csm_91075]. Via the input parameter keyId (type uint32), the identifier of the key to be invalidated is passed [SWS_Csm_91075].

Return Values and Error Handling

The function returns a status value of type Std_ReturnType [SWS_Csm_91075]:

• E_OK: The invalidation request was successful [SWS_Csm_91075].
• E_NOT_OK: The request failed [SWS_Csm_91075].
• CRYPTO_E_BUSY: The request failed because the crypto driver object is busy [SWS_Csm_91075].

Concurrency and Limitations

The function is specified as non-reentrant (Non Reentrant) [SWS_Csm_91075]. Callers must therefore ensure that calls do not occur interruptingly or uncoordinated in parallel. If the responsible crypto driver object is busy at the time of the call, the operation is rejected with CRYPTO_E_BUSY [SWS_Csm_91075].

use

The synchronous function Csm_KeyGetStatus is used to query the current status of a key specified via its identifier [SWS_Csm_91047]. The declaration is available via header Csm.h [SWS_Csm_91047].

Upon invocation, the following parameters are passed [SWS_Csm_91047]:

• keyId (IN): Identifier of the key whose status is to be determined.
• keyStatusPtr (OUT): Pointer to a memory location of type Crypto_KeyStatusType where the CSM stores the determined key status.

As a return value, the function provides Std_ReturnType [SWS_Csm_91047]:

• E_OK: The status query was successful and the result is available via the output pointer.
• E_NOT_OK: The request has failed.

Concurrency and behavior

The service function has the service ID 0x83 and is specified as reentrant [SWS_Csm_91047]. Since execution is synchronous, the call blocks the caller until status determination is complete [SWS_Csm_91047]. A valid memory area for keyStatusPtr must be provided by the caller, as invalid pointers presumably lead to the return value E_NOT_OK. Question Q-a920a9a12b1374aa (open)

The synchronous and reentrant function Csm_KeyElementGet reads the data of a specific key element from the key identified via keyId and copies it into the passed memory area [SWS_Csm_00959]. The service is declared via header file Csm.h and has service ID 0x68 [SWS_Csm_00959].

Parameters and Buffer Handling

To identify the element, the parameters keyId (identifier of the key) and keyElementId (identifier of the desired key element) are passed [SWS_Csm_00959]. Reading out requires the provision of an output buffer as well as its length management:

• keyElementPtr: Pointer to the memory location to which the extracted bytes of the key element are copied [SWS_Csm_00959].
• keyElementLengthPtr: An input/output parameter (inout) that must contain the maximum available buffer size of keyElementPtr in bytes upon function call. After processing is complete, the function stores the actually written byte length here [SWS_Csm_00959].

Return Values and Error Analysis

The function returns specific status codes as Std_ReturnType to indicate the outcome of the operation [SWS_Csm_00959]:

• E_OK: The copying process of the key element was successful [SWS_Csm_00959].
• E_NOT_OK: The request failed generally [SWS_Csm_00959].
• CRYPTO_E_BUSY: The request failed because the affected Crypto Driver Object is currently busy [SWS_Csm_00959].
• CRYPTO_E_KEY_NOT_AVAILABLE: The key element requested via keyElementId is not available [SWS_Csm_00959].
• CRYPTO_E_KEY_READ_FAIL: Read access to the key element was denied [SWS_Csm_00959].
• CRYPTO_E_KEY_EMPTY: The requested source key element is not initialized [SWS_Csm_00959].

The synchronous function Csm_KeyElementCopyManager serves to copy a single key element from a source key into a target element of a target key [SWS_Csm_00969]. The call is provided via the header file Csm.h with the service ID 0x71 and requires four input parameters: keyId and keyElementId to identify the source key element, as well as targetKeyId and targetKeyElementId for the target [SWS_Csm_00969].

Regarding concurrency, the service is designed to be reentrant, but explicitly not for the same keyId [SWS_Csm_00969]. Parallel accesses to the same source key must therefore be avoided or synchronized by the caller.

The function returns a status of type Std_ReturnType. Upon successful execution, it returns E_OK [SWS_Csm_00969]. In case of an error, specific return values are available for root cause analysis [SWS_Csm_00969]:

• CRYPTO_E_BUSY: The underlying crypto driver object is busy [SWS_Csm_00969].
• CRYPTO_E_KEY_NOT_AVAILABLE: The requested key element is not available [SWS_Csm_00969].
• CRYPTO_E_KEY_READ_FAIL: Reading the source element is not permitted [SWS_Csm_00969].
• CRYPTO_E_KEY_WRITE_FAIL: Writing to the target element is not permitted [SWS_Csm_00969].
• CRYPTO_E_KEY_SIZE_MISMATCH: The sizes of the two key elements are incompatible with each other [SWS_Csm_00969].
• CRYPTO_E_KEY_EMPTY: The source key element is not yet initialized [SWS_Csm_00969].
• E_NOT_OK: General errors during request execution [SWS_Csm_00969].

use

The synchronous service function Csm_KeyCopy with service ID 0x73 serves to completely copy all key elements from a source key to a target key [SWS_Csm_01034]. The declaration is made available via header file Csm.h [SWS_Csm_01034]. As immutable input parameters, keyId is passed for the identifier of the source key and targetKeyId for the identifier of the target key [SWS_Csm_01034]. Additional input/output or output parameters are not defined in the signature [SWS_Csm_01034].

Error Handling and Return Values

The return value of type Std_ReturnType informs the caller about the result of the execution [SWS_Csm_01034]. While E_OK signals successful execution, E_NOT_OK indicates a general failure of the request [SWS_Csm_01034]. Specific error causes are indicated by separate crypto return values [SWS_Csm_01034]:

• CRYPTO_E_BUSY: The operation failed because the crypto driver object is busy.
• CRYPTO_E_KEY_NOT_AVAILABLE: The requested key element is not available.
• CRYPTO_E_KEY_READ_FAIL: Reading of the key element from the source is not permitted.
• CRYPTO_E_KEY_WRITE_FAIL: Writing of the key element to the target is not permitted.
• CRYPTO_E_KEY_SIZE_MISMATCH: The sizes of the involved key elements are not compatible with each other.
• CRYPTO_E_KEY_EMPTY: The key element of the source key is not initialized.

Concurrency and Limitations

Regarding call behavior, Csm_KeyCopy is designed to be reentrant, however with the binding restriction that this does not apply to the same keyId [SWS_Csm_01034].

The synchronous function Csm_KeyElementCopyPartial copies a defined subrange of a key element into another key element within the same crypto driver [SWS_Csm_91025]. Parameters keyElementSourceOffset and keyElementCopyLength determine the byte offset and length with which the source element (identified by keyId and keyElementId) is copied. The start position in the target element (targetKeyId, targetKeyElementId) is specified via keyElementTargetOffset [SWS_Csm_91025].

The return value provides the execution status as well as specific error causes [SWS_Csm_91025]:

• E_OK: The copy operation was executed successfully.
• CRYPTO_E_BUSY: The crypto driver object is busy.
• CRYPTO_E_KEY_NOT_AVAILABLE: The requested key element is not available.
• CRYPTO_E_KEY_READ_FAIL: Reading of the source key element is not permitted.
• CRYPTO_E_KEY_WRITE_FAIL: Writing to the target key element is not permitted.
• CRYPTO_E_KEY_SIZE_MISMATCH: The sizes of the involved key elements are incompatible.
• CRYPTO_E_KEY_EMPTY: The source key element is uninitialized.
• E_NOT_OK: The request failed due to general reasons.

The function is implemented as reentrant, but must not be called concurrently for the same keyId [SWS_Csm_91025]. In addition, the interface requires that source and target are managed in the same crypto driver [SWS_Csm_91025]. The declaration is available via header Csm.h [SWS_Csm_91025].

Usage and Call Context

The synchronous function Csm_RandomSeed is used to fill the key element CRYPTO_KE_RANDOM_SEED of a key with a passed random value (seed) [SWS_Csm_01051]. When called, the identifier of the destination key is passed via keyId, the pointer to the memory location with the seed data via seedPtr, and the length of the seed in bytes via seedLength [SWS_Csm_01051].

Interaction

If the CSM detects no errors during execution, the function Csm_RandomSeed forwards the service call directly to CryIf_RandomSeed of the Crypto Interface [SWS_Csm_01052].

Error Handling and Return Values

The function returns a status value of type Std_ReturnType [SWS_Csm_01051]:

• E_OK: The request was successful [SWS_Csm_01051].
• E_NOT_OK: The request failed [SWS_Csm_01051].
• CRYPTO_E_BUSY: Execution failed because the corresponding Crypto Driver Object is currently busy [SWS_Csm_01051].
• CRYPTO_E_KEY_NOT_VALID: The request was rejected because the state of the key is invalid [SWS_Csm_01051].

Concurrency and Limitations

Regarding concurrency behavior, Csm_RandomSeed is implemented reentrantly, but must not be called concurrently for the same keyId [SWS_Csm_01051].

The synchronous function Csm_KeyGenerate serves to generate new cryptographic key material and stores it directly in the key specified via the parameter keyId [SWS_Csm_00955]. The interface is provided via the header file Csm.h and has the service ID 0x6a [SWS_Csm_00955].

Upon the call, the application passes the identifier keyId (type uint32) of the key for which the material is to be generated; input/output or pure output parameters do not exist [SWS_Csm_00955]. The status of the operation is reported synchronously via the return value of type Std_ReturnType [SWS_Csm_00955]:

• E_OK: The generation and storage of the key material was successful [SWS_Csm_00955].
• E_NOT_OK: The request failed [SWS_Csm_00955].
• CRYPTO_E_BUSY: Execution failed because the responsible Crypto Driver Object is currently busy [SWS_Csm_00955].
• CRYPTO_E_KEY_NOT_VALID: The request was rejected because the destination key is in the status "invalid" [SWS_Csm_00955].
• CRYPTO_E_KEY_EMPTY: Generation failed due to an uninitialized source key element [SWS_Csm_00955].

With regard to concurrency, Csm_KeyGenerate is designed to be reentrant, but must not be called concurrently for the same keyId [SWS_Csm_00955].

The synchronous function Csm_KeyDerive serves to derive a new cryptographic key from a specified source key [SWS_Csm_00956]. The function is declared in header file Csm.h and has service ID 0x6b [SWS_Csm_00956].

Usage and Parameters

The synchronous call processes two input parameters [SWS_Csm_00956]:

• keyId: Identifier of the source key that contains the key elements for password and salt [SWS_Csm_00956].
• targetKeyId: Identifier of the target key; the derived key material is stored in the key element with ID 1 [SWS_Csm_00956].

Return Values and Error Handling

As return value, the function provides status Std_ReturnType [SWS_Csm_00956]. In addition to E_OK upon successful execution and E_NOT_OK upon general errors, specific crypto errors are defined [SWS_Csm_00956]:

• CRYPTO_E_BUSY: The crypto driver object is busy [SWS_Csm_00956].
• CRYPTO_E_KEY_READ_FAIL: Reading of the key element is not allowed [SWS_Csm_00956].
• CRYPTO_E_KEY_WRITE_FAIL: Writing to the target key element is not allowed [SWS_Csm_00956].
• CRYPTO_E_KEY_NOT_VALID: The state of the key is invalid [SWS_Csm_00956].
• CRYPTO_E_KEY_SIZE_MISMATCH: Sizes of the key elements are incompatible [SWS_Csm_00956].
• CRYPTO_E_KEY_EMPTY: The source key element is uninitialized [SWS_Csm_00956].

Concurrency and Interaction

The function is reentrant, but expressly not for the same keyId [SWS_Csm_00956]. If no errors are detected in the CSM, the service forwards execution directly to CryIf_KeyDerive [SWS_Csm_01018].

The synchronous interface Csm_KeyExchangeCalcPubVal (service ID 0x6c, available via Csm.h) calculates the public value of the current user for the key exchange protocol and stores the public key at the memory address referenced by pointer publicValuePtr [SWS_Csm_00966].

Parameters and Buffer Management

The function processes three input parameters [SWS_Csm_00966]:

• keyId (in): Contains the identifier of the key to be used for the key exchange protocol [SWS_Csm_00966].
• publicValuePtr (out): Pointer to the memory area in which the resulting public key value is stored [SWS_Csm_00966].
• publicValueLengthPtr (inout): Pointer to the length information. Upon invocation, this parameter must contain the provided size of buffer publicValuePtr; after completion of execution, the actual length of the calculated value is stored there [SWS_Csm_00966].

Error Handling and Return Values

The execution status is returned via Std_ReturnType [SWS_Csm_00966]:

• E_OK: The request was successful [SWS_Csm_00966].
• E_NOT_OK: The request has failed [SWS_Csm_00966].
• CRYPTO_E_BUSY: The request failed because the crypto driver object is busy [SWS_Csm_00966].
• CRYPTO_E_KEY_NOT_VALID: The request fails because the status of the key is invalid [SWS_Csm_00966].
• CRYPTO_E_KEY_EMPTY: The request fails due to an uninitialized source key element [SWS_Csm_00966].

Concurrency

The function is designed to be reentrant, but must not be called concurrently for the same keyId [SWS_Csm_00966].

The synchronous function Csm_KeyExchangeCalcSecret serves in the Crypto Service Manager to calculate a shared secret (Shared Secret Key) within the scope of a key exchange protocol [SWS_Csm_00967]. In this process, the key material of the key referenced via keyId is combined with the public value of the communication partner. The calculated secret key is then stored directly as a key element within the same key [SWS_Csm_00967].

The interface is provided via header Csm.h and expects three input parameters [SWS_Csm_00967]:

• keyId: Identifier of the key whose key material is used for the protocol.
• partnerPublicValuePtr: Pointer to the memory area containing the public value of the partner.
• partnerPublicValueLength: Length of the passed partner value in bytes.

As return value of type Std_ReturnType, the call provides either E_OK upon successful execution or E_NOT_OK upon a general error [SWS_Csm_00967]. Specific error cases signal detailed status codes: CRYPTO_E_BUSY indicates that the underlying crypto driver object is busy. If the state of the key is invalid, CRYPTO_E_KEY_NOT_VALID is returned, while CRYPTO_E_KEY_EMPTY indicates an uninitialized source key element [SWS_Csm_00967].

With regard to concurrency, the function is designed to be reentrant, but must not be called concurrently for the same keyId [SWS_Csm_00967].

use

The function Csm_JobKeySetValid stores the key if needed and sets the key state of the key identified via keyId to valid [SWS_Csm_91027]. The interface is declared via the header file Csm.h and has the service ID 0x7a with signature Std_ReturnType Csm_JobKeySetValid (uint32 jobId, uint32 keyId) [SWS_Csm_91027].

Upon invocation, two input parameters of type uint32 are passed [SWS_Csm_91027]:

• jobId: Holds the identifier of the job that uses the CSM service [SWS_Csm_91027].
• keyId: Holds the identifier of the key for which new key material is to be validated [SWS_Csm_91027].

Additional input/output parameters or pure output parameters are not defined for this function [SWS_Csm_91027].

Synchronous and Asynchronous Behavior as Well as Concurrency

The execution semantics depend on the respective job configuration: The call occurs either synchronously or asynchronously [SWS_Csm_91027]. The function is specified as reentrant [SWS_Csm_91027].

Return Values and Error Handling

The return value of type Std_ReturnType reflects the result of the function request [SWS_Csm_91027]:

• E_OK: The request was successful [SWS_Csm_91027].
• E_NOT_OK: The request has failed [SWS_Csm_91027].
• CRYPTO_E_BUSY: The request failed because the responsible Crypto Driver Object is busy [SWS_Csm_91027].

use

The function Csm_JobKeySetInvalid sets the status of a cryptographic key to invalid [SWS_Csm_91002]. After calling this interface, the key concerned can no longer be used for cryptographic operations until it has been returned to a valid state again [SWS_Csm_91002]. The service has service ID 0x84, is available via header file Csm.h, and operates either synchronously or asynchronously depending on the job configuration [SWS_Csm_91002].

The following parameters are passed for the call [SWS_Csm_91002]:

• jobId: Identifier of the CSM job that uses this service [SWS_Csm_91002].
• keyId: Identifier of the key to be invalidated [SWS_Csm_91002].

Error Handling and Return Values

The return value of type Std_ReturnType reports the result of the request [SWS_Csm_91002]:

• E_OK: The request was successful [SWS_Csm_91002].
• E_NOT_OK: The request failed [SWS_Csm_91002].
• CRYPTO_E_BUSY: The request failed because the responsible Crypto Driver Object is busy [SWS_Csm_91002].

Concurrency

The interface is specified as reentrant [SWS_Csm_91002]. Additional input or output parameters do not exist [SWS_Csm_91002].

Usage and Call Context

The function Csm_JobRandomSeed serves to provide a new seed for a specified key that is used for an associated random number generator [SWS_Csm_91028]. The declaration is available in the header Csm.h [SWS_Csm_91028]. The function has the service ID 0x7b and processes four input parameters: jobId identifies the consuming CSM job, while keyId determines the target key for which the seed is to be generated [SWS_Csm_91028]. The initialization data is passed via the pointer seedPtr, and its length in bytes is specified with seedLength [SWS_Csm_91028]. The execution behavior depends on the configuration of the respective job and is performed either synchronously or asynchronously [SWS_Csm_91028].

Error Handling and Return Values

The function returns a status of type Std_ReturnType that indicates the result of the request [SWS_Csm_91028]:

• E_OK: The request was successful [SWS_Csm_91028].
• E_NOT_OK: The request has failed generally [SWS_Csm_91028].
• CRYPTO_E_BUSY: The request failed because the service is currently still busy [SWS_Csm_91028].
• CRYPTO_E_KEY_NOT_VALID: The request was rejected because the specified key is in the invalid state [SWS_Csm_91028].

Concurrency and Limitations

The interface is specified as reentrant [SWS_Csm_91028]. If an application calls the service while another operation is still active, the return value CRYPTO_E_BUSY signals this state [SWS_Csm_91028]. In addition, it must be ensured before execution that the key addressed via keyId is valid in order to avoid the error CRYPTO_E_KEY_NOT_VALID [SWS_Csm_91028].

use

The function Csm_JobKeyGenerate generates new key material and stores it in the key identified via keyId [SWS_Csm_91029]. Via parameter jobId, the identifier of the job using the CSM service is passed [SWS_Csm_91029]. Execution takes place synchronously or asynchronously depending on the configuration of the respective job [SWS_Csm_91029]. The service is declared via header file Csm.h with service ID 0x7c [SWS_Csm_91029].

Return Values and Error Handling

The return value of type Std_ReturnType provides information about the result of the request [SWS_Csm_91029]:

• E_OK: The request was successful [SWS_Csm_91029].
• E_NOT_OK: The request failed [SWS_Csm_91029].
• CRYPTO_E_BUSY: The service is currently still busy [SWS_Csm_91029].
• CRYPTO_E_KEY_NOT_VALID: The state of the key is invalid [SWS_Csm_91029].
• CRYPTO_E_KEY_EMPTY: The request failed due to an uninitialized source key element [SWS_Csm_91029].

Concurrency and Limitations

The function is specified as reentrant [SWS_Csm_91029]. Interpretation: Since the specification does not prescribe a specific execution context, the call is likely to occur typically in task context. Question Q-236d699ed655e285 (open)

Usage and Semantics

The function Csm_JobKeyDerive derives a new cryptographic key by using the key elements for password and salt from the key identified by keyId [SWS_Csm_91030]. The result is stored in the key element with ID 1 of the target key specified by targetKeyId [SWS_Csm_91030]. The call is made via header file Csm.h with service ID 0x7d, passing the respective job via jobId [SWS_Csm_91030].

Processing takes place either synchronously or asynchronously depending on the configuration of the passed job [SWS_Csm_91030]. The function is specified as reentrant [SWS_Csm_91030].

Error Handling and Return Values

As return value, the function provides type Std_ReturnType. A successful execution of the request is confirmed by E_OK [SWS_Csm_91030]. In case of an error or unsuitable preconditions, specific return values are reported [SWS_Csm_91030]:

• E_NOT_OK: The request has failed [SWS_Csm_91030].
• CRYPTO_E_BUSY: The request fails because the service is currently still busy [SWS_Csm_91030].
• CRYPTO_E_KEY_READ_FAIL: Reading of the key element is not permitted [SWS_Csm_91030].
• CRYPTO_E_KEY_WRITE_FAIL: Writing to the target key element is not permitted [SWS_Csm_91030].
• CRYPTO_E_KEY_NOT_VALID: The state of the key is invalid [SWS_Csm_91030].
• CRYPTO_E_KEY_SIZE_MISMATCH: The involved key element sizes are not compatible with each other [SWS_Csm_91030].
• CRYPTO_E_KEY_EMPTY: The source key element is uninitialized [SWS_Csm_91030].

use

The function Csm_JobKeyExchangeCalcPubVal calculates the public value of the current participant for the key exchange protocol and stores it in the specified target memory [SWS_Csm_91031]. Depending on the configuration of the associated job, processing is performed either synchronously or asynchronously [SWS_Csm_91031].

The parameters are passed via the following interface data [SWS_Csm_91031]:

• jobId: Identifier of the CSM job using the cryptographic service.
• keyId: Identifier of the key used for the key exchange protocol.
• publicValuePtr: Pointer to the buffer area in which the calculated public key is stored.
• publicValueLengthPtr: Pointer to the length specification. When the function is called, this parameter must contain the capacity of the buffer publicValuePtr; after completion of the execution, the actual length of the calculated value is entered.

Error handling

The return value of type Std_ReturnType provides information about the execution status of the request [SWS_Csm_91031]:

• E_OK: Request was executed successfully.
• E_NOT_OK: Request has failed.
• CRYPTO_E_BUSY: The requested service is currently still busy.
• CRYPTO_E_KEY_NOT_VALID: The key state is invalid.
• CRYPTO_E_KEY_EMPTY: The source key element is not initialized.

Concurrency and Integration

The interface is declared as reentrant, has the service ID 0x7e, and is provided via the header file Csm.h [SWS_Csm_91031].

Usage and Semantics

The function Csm_JobKeyExchangeCalcSecret calculates the shared secret key for a key exchange using the key material from the key identified via keyId and the public key of the communication partner [SWS_Csm_91032]. The memory address of the partner key is passed via partnerPublicValuePtr, and its length in bytes is defined via partnerPublicValueLength [SWS_Csm_91032]. The calculated shared secret is stored directly as a key element within the same key [SWS_Csm_91032].

The consuming CSM job is identified via the input parameter jobId. The execution behavior is synchronous or asynchronous, depending on the respective job configuration [SWS_Csm_91032].

Error Handling and Return Values

The return value of type Std_ReturnType reports the status of the service request [SWS_Csm_91032]:

• E_OK: The service request was successful [SWS_Csm_91032].
• E_NOT_OK: The service request has failed [SWS_Csm_91032].
• CRYPTO_E_BUSY: The request fails because the underlying service is still busy [SWS_Csm_91032].
• CRYPTO_E_KEY_NOT_VALID: The request fails because the referenced key is in the "invalid" state [SWS_Csm_91032].
• CRYPTO_E_KEY_EMPTY: The calculation fails because a required source key element is not initialized [SWS_Csm_91032].

Concurrency and Integration

The function is designed to be reentrant, has the service ID 0x7f, and is declared via the header file Csm.h [SWS_Csm_91032].

The function Csm_SaveContextJob causes the Crypto Driver to save the internal context of the respective crypto operation into an application-side buffer [SWS_Csm_91063]. The service is declared in the header file Csm.h and has the service ID 0x86 [SWS_Csm_91063].

The interface expects the following parameters [SWS_Csm_91063]:

• jobId (input): Designates the unique identifier of the job that uses the CSM service.
• contextBufferLengthPtr (input/output): Pointer to the length value. Upon the call, it specifies the maximum capacity available in the target buffer; after execution, it contains the data length actually written or, in case of an error, the value 0.
• contextBufferPtr (output): Pointer to the memory area of the application into which the context data is to be written.

Execution takes place either synchronously or asynchronously depending on the job configuration [SWS_Csm_91063]. In addition, the function is specified as reentrant [SWS_Csm_91063].

The following return values are defined for reporting the operation status [SWS_Csm_91063]:

• E_OK: The context data was successfully stored in the buffer and the length specification was updated.
• E_NOT_OK: The context data could not be provided because the values are invalid; the returned length is set to 0.
• CRYPTO_E_BUSY: The request failed because the underlying crypto service is still busy.

Usage and Semantics

The function Csm_RestoreContextJob serves to restore the internal state of a cryptographic job from an external buffer so that subsequent operations are resumed at the exact point of the previous save [SWS_Csm_91064]. The target job is addressed via the parameter jobId, while contextBufferPtr refers to the payload data and contextBufferLength to its byte size [SWS_Csm_91064]. Execution takes place synchronously or asynchronously depending on the configuration of the respective job [SWS_Csm_91064].

Return Values and Error Handling

The function reports the result of the operation via its return value of type Std_ReturnType [SWS_Csm_91064]:

• E_OK: The context data was read successfully and the internal driver state was restored [SWS_Csm_91064].
• E_NOT_OK: Restoration of the context failed [SWS_Csm_91064].
• CRYPTO_E_BUSY: The underlying crypto service is currently busy, which is why the request was rejected [SWS_Csm_91064].

Concurrency and Limitations

The interface is specified as reentrant and available via Csm.h (Service ID 0x87) [SWS_Csm_91064]. Interpretation: In the case of an asynchronous configuration of the job, the caller likely has to ensure that the buffer under contextBufferPtr remains unchanged and valid until the restoration is actually completed. Question Q-8ab0cb179f807bd4 (open)

Usage and Call Context

Function Csm_CancelJob (service ID 0x6f) serves to synchronously abort the processing of asynchronous or streaming jobs within module Csm [SWS_Csm_00968]. The interface is provided via header Csm.h [SWS_Csm_00968]. As parameters, the function takes the identifier of the job to be aborted via job (of type uint32) as well as parameter mode (of type Crypto_OperationModeType), which is unused and serves exclusively for interface compatibility [SWS_Csm_00968].

Return Values and Cancellation Behavior

The result of the abort call is signaled synchronously via the return value of type Std_ReturnType [SWS_Csm_00968]:

• E_OK: The abort was immediately successful; the job was removed from all queues and potentially directly from the crypto driver hardware [SWS_Csm_00968].
• E_NOT_OK: The abort request failed [SWS_Csm_00968].
• CRYPTO_E_JOB_CANCELED: Immediate cancellation was not possible; the abort will be completed in the next suitable processing step and subsequently communicated via the job's negative completion callback [SWS_Csm_00968].

Concurrency and Limitations

The specification defines Csm_CancelJob as synchronous and non-reentrant (Non Reentrant) [SWS_Csm_00968]. Calling components must therefore ensure that no concurrent calls to the function occur.

The synchronous interface Csm_CallbackNotification is declared via the header file Csm.h and serves the underlying layer (CRYIF) as a callback function to notify the Crypto Service Manager (CSM) about the completion of a cryptographic job [SWS_Csm_00970]. The function has no return value and accepts two input parameters: the pointer job to the finished job of type Crypto_JobType*, and result of type Crypto_ResultType, which transmits the execution result of the underlying cryptographic operation [SWS_Csm_00970].

Regarding concurrency, the execution of Csm_CallbackNotification is specified as reentrant [SWS_Csm_00970]. Specific return codes or separate DET or DEM error messages are not defined in the element; error states and execution results of the cryptographic processing are instead provided directly via the passed argument result [SWS_Csm_00970].

As part of the interaction, the function checks the processing mode of the job: If bit CRYPTO_OPERATIONMODE_FINISH is set in the job->jobPrimitiveInputOutput.mode field, specification Csm_CallbackNotification obligates calling the configured callback function [SWS_Csm_01044]. Interpretation: This call is likely the notification of the higher-level application layer, since the FINISH flag signals the final completion of a cryptographic operation sequence. Question Q-32da2433b15ba3a9 (open)

use

The function Csm_MainFunction is called cyclically to process requested cryptographic jobs [SWS_Csm_00479]. It has no parameters (void) and returns no return value [SWS_Csm_00479]. The declaration is available via the header SchM_Csm.h [SWS_Csm_00479].

Responsibilities and Interaction

As part of its periodic execution, the function checks the internal queues for pending jobs and passes them to the underlying CRYIF layer [SWS_Csm_00479].

Instantiation and Call Context

For each configured instance, a dedicated function of the form Csm_MainFunction_<shortName> is implemented, where <shortName> corresponds to the short name of the configuration container in the ECU configuration [SWS_Csm_00479]. As scheduled, the cyclic call is likely performed by the BSW Scheduler (SchM) in a periodic task, as the interface is provided via SchM_Csm.h. Question Q-ffb62942b1f517b3 (open)

Error Handling and Boundary Conditions

Specific error codes, DET or DEM messages, and explicit reentrancy requirements are not described in the present specification excerpt [SWS_Csm_00479].

The configurable callback function <Csm_ Application Callback Notification> serves to inform an application synchronously via the Crypto Service Manager (CSM) about the end of a processing job [SWS_Csm_00971]. The identifier of the function is not fixed, but is specified project-specifically via configuration parameter {Csm Job/ Csm Job Primitive Callback Ref}/Csm Callback Func [SWS_Csm_00971]. The interface has service ID 0x82 and is provided via header file Csm.h [SWS_Csm_00971].

The signature has no return value (void) and passes two input parameters to the application for evaluation [SWS_Csm_00971]:

• jobId (uint32): Designates the unique ID of the cryptographic job whose completion triggered the callback [SWS_Csm_00971].
• result (Crypto_ResultType): Conveys the result or status of the executed cryptographic operation [SWS_Csm_00971].

Regarding concurrency, the notification function is specified as reentrant [SWS_Csm_00971]. Specific DET or DEM error codes are not defined for the callback itself; errors that occurred during the preceding operation must be evaluated directly via result [SWS_Csm_00971]. Since the interface is declared as reentrant, the application-side implementation might have to be designed to process concurrent notifications for different jobs in a thread-safe manner. Question Q-79504ea3461f8d61 (open)

According to [SWS_Csm_01048], the enumeration type Crypto_AlgorithmModeType specifies the operation mode of a cryptographic algorithm. It is available via the header file Crypto_GeneralTypes.h and is used for standardized configuration and runtime selection of cryptographic schemes in the Crypto Service Manager.

Usage and value range:

• Classic block cipher modes: among others, CRYPTO_ALGOMODE_ECB, CRYPTO_ALGOMODE_CBC, CRYPTO_ALGOMODE_CFB, CRYPTO_ALGOMODE_OFB, CRYPTO_ALGOMODE_CTR, CRYPTO_ALGOMODE_GCM, and CRYPTO_ALGOMODE_XTS are supported [SWS_Csm_01048].
• Asymmetric schemes and padding: modes for encryption and signatures such as CRYPTO_ALGOMODE_RSAES_OAEP, CRYPTO_ALGOMODE_RSAES_PKCS1_v1_5, CRYPTO_ALGOMODE_RSASSA_PSS, and CRYPTO_ALGOMODE_RSASSA_PKCS1_v1_5 are included [SWS_Csm_01048].
• Further operation modes: the value range includes round counts (CRYPTO_ALGOMODE_8ROUNDS, CRYPTO_ALGOMODE_12ROUNDS, CRYPTO_ALGOMODE_20ROUNDS), MAC schemes (CRYPTO_ALGOMODE_HMAC, CRYPTO_ALGOMODE_CMAC, CRYPTO_ALGOMODE_GMAC), random bit generators (CRYPTO_ALGOMODE_CTRDRBG), SipHash variants, and curve definitions such as CRYPTO_ALGOMODE_PXXXR1 [SWS_Csm_01048].
• Special states: CRYPTO_ALGOMODE_NOT_SET (0x00) signals an unset algorithm key, while CRYPTO_ALGOMODE_CUSTOM (0xff) allows vendor-specific operation modes [SWS_Csm_01048].

Interpretation: Since Crypto_AlgorithmModeType is a pure enumeration, the type has no error handling of its own via DET or DEM and is not subject to any reentrancy requirements. Question Q-3d2e905dda6531ac (open) Error checks and restrictions regarding the call context only arise from the CSM functions to which values of this type are passed as parameters.

Usage and Structure of Crypto_JobType

The structure Crypto_JobType bundles all relevant control, state, and buffer data for executing a cryptographic job in the Crypto Service Manager and is available via Crypto_GeneralTypes.h [SWS_Csm_01013].

The central elements of the structure include [SWS_Csm_01013]:

• jobId: Unique identifier of the job.
• jobState: Represents the current execution state of the job.
• jobPrimitiveInputOutput: Points to the specific input and output data of the primitive.
• jobPrimitiveInfo: Pointer to constant additional information on the selected crypto primitive.
• jobPriority: Determines the execution priority, where a higher value indicates a higher urgency.
• jobRedirectionInfoRef: Pointer to optional information for redirecting keys as input and output values.

Interaction and Interface Relationships

The structure fields cryptoKeyId and targetCryptoKeyId reference the keys to be used in the crypto driver; according to the specification, these identifiers are described by the Crypto Interface [SWS_Csm_01013]. Interpretation: jobPriority is likely used to govern the order of scheduling and processing concurrent jobs in queues. Question Q-439432c5631948fb (open)

The enumeration type Crypto_JobStateType defines the current processing status of a cryptographic job in the CSM [SWS_Csm_01028]. It is provided via header file Crypto_GeneralTypes.h and distinguishes between two main states of the job lifecycle [SWS_Csm_01028]:

• CRYPTO_JOBSTATE_IDLE (0x00): Designates the idle state of the job. This state is entered initially after calling Csm_Init() or as soon as a finish operation (state "Finish") has been completed [SWS_Csm_01028].
• CRYPTO_JOBSTATE_ACTIVE (0x01): Indicates that the job is being actively processed and input data have already been processed or intermediate results are available. This state is reached as soon as a start or update operation has been successfully completed [SWS_Csm_01028].

In terms of usage and interaction, the type reflects the progress of streaming or multi-stage crypto operations [SWS_Csm_01028]. A transition to CRYPTO_JOBSTATE_ACTIVE signals that the cryptographic context is initialized or continuously holds intermediate results, while the transition to CRYPTO_JOBSTATE_IDLE marks termination and indicates that the job is available for new workflows [SWS_Csm_01028].

The data structure Crypto_JobPrimitiveInfoType bundles additional information on a crypto job and its underlying primitives [SWS_Csm_01012]. It is available in the Classic AUTOSAR stack via the header file Crypto_GeneralTypes.h [SWS_Csm_01012].

Components and Usage

According to specification [SWS_Csm_01012], the structure is composed of the following fields:

• callbackId (uint32): Internal identifier of the callback function that is called by the CSM module as soon as execution of the configured service has finished [SWS_Csm_01012].
• primitiveInfo (const Crypto_PrimitiveInfoType*): Pointer to a data structure with the further configuration of the crypto primitive [SWS_Csm_01012].
• cryIfKeyId (uint32): Identifier of the key for the crypto interface (CryIf) [SWS_Csm_01012].
• processingType (Crypto_ProcessingType): Defines the execution behavior and determines whether the job is processed synchronously or asynchronously [SWS_Csm_01012].

Execution Context and Semantics

The field processingType controls the synchronous or asynchronous semantics of the job processing [SWS_Csm_01012]. The callback function registered via callbackId is likely relevant primarily in asynchronous mode to inform the caller about the end of the service, whereas the pointer primitiveInfo must point to a valid primitive configuration [SWS_Csm_01012]. Question Q-791dae4fb6a83f99 (open)

use

The data structure Crypto_AlgorithmInfoType determines the exact configuration of a cryptographic algorithm and is provided via header file Crypto_GeneralTypes.h [SWS_Csm_01008]. It is composed of the following elements:

• family (Crypto_AlgorithmFamilyType): The primary family of the algorithm.
• secondaryFamily (Crypto_AlgorithmFamilyType): The secondary family of the algorithm.
• keyLength (uint32): The key length to be used in bits.
• mode (Crypto_AlgorithmModeType): The intended operation mode of the algorithm.

Not every algorithm requires all structure elements to be populated [SWS_Csm_01008]. Depending on the type of cryptographic operation, individual fields such as the operation mode or a secondary family may remain unused.

Restrictions and Error Handling

According to [SWS_Csm_01008], only valid combinations of the structure elements may occur in AUTOSAR. Invalid combinations—for example, mismatched operation modes or invalid key lengths for a specific algorithm family—are not permitted. Checking the validity of the parameter combination would presumably be performed by configuration tools or upon service calls by the CSM. Question Q-da4984170bba173c (open)

The structure Crypto_PrimitiveInfoType serves in the Crypto Service Manager (CSM) to provide basic metadata for a cryptographic primitive ([SWS_Csm_01011]). It is declared via header file Crypto_GeneralTypes.h and bundles the static characteristics of the respective operation ([SWS_Csm_01011]).

The structure is composed of two elements ([SWS_Csm_01011]):

• service (type: const Crypto_ServiceInfoType): Determines the cryptographic service used via an enumeration, for example encryption (Encrypt) ([SWS_Csm_01011]).
• algorithm (type: const Crypto_AlgorithmInfoType): Contains detailed information on the algorithm used ([SWS_Csm_01011]).

Since both elements are typed as const, these are likely read-only configuration or metadata that are defined at configuration time and evaluated purely read-only at runtime by drivers or the CSM ([SWS_Csm_01011]). Question Q-6d53291f7fb8cfe6 (open) Specific error codes, error handling routines, or concurrency restrictions are not defined for this data structure type.

The enumeration type Crypto_OperationModeType defines, according to [SWS_Csm_01029], the processing phase to be executed for cryptographic operations. The type is structured as a bitmask whose first three bits represent the core steps Start (bit 1 / 0x01), Update (bit 2 / 0x02), and Finish (bit 3 / 0x04).

The different execution and lifecycle phases of a crypto job are controlled via the enumeration values [SWS_Csm_01029]:

• CRYPTO_OPERATIONMODE_START (0x01): Initializes the job; the state is reset, whereby previous input data and intermediate results are cleared.
• CRYPTO_OPERATIONMODE_UPDATE (0x02): Processes input data to compute intermediate results.
• CRYPTO_OPERATIONMODE_FINISH (0x04): Finally completes the computations of the cryptographic operation.
• CRYPTO_OPERATIONMODE_STREAMSTART (0x03): Combines start and update for streaming scenarios.
• CRYPTO_OPERATIONMODE_SINGLECALL (0x07): Unites start, update, and finish for complete processing in a single call.

In addition, the type supports workspace management for interruptible sequences: With CRYPTO_OPERATIONMODE_SAVE_CONTEXT (0x08), the crypto driver provides the current workspace context to the application, whereas CRYPTO_OPERATIONMODE_RESTORE_CONTEXT (0x10) restores a previously saved state in the driver's internal workspace [SWS_Csm_01029]. The type is provided via the header Rte_Csm_Type.h.

The enumeration type Crypto_VerifyResultType defines the functional result of verification operations in module CSM [SWS_Csm_01024]. It is provided via header file Rte_Csm_Type.h and serves to determine whether a cryptographic comparison was successfully completed [SWS_Csm_01024].

Value Range and Semantics

According to [SWS_Csm_01024], the enumeration comprises two discrete values to represent the comparison status:

• CRYPTO_E_VER_OK (value 0x00 or 0): The result of the verification is "true"; the two compared elements are therefore identical [SWS_Csm_01024].
• CRYPTO_E_VER_NOT_OK (value 0x01 or 1): The result of the verification is "false"; the compared elements are not identical [SWS_Csm_01024].

The type separates the functional statement about data matching from the general execution status of an operation. By interpretation, this means that even an error-free executed check routine can return CRYPTO_E_VER_NOT_OK if data deviate from each other [SWS_Csm_01024].

Usage and restrictions

Since the data type is declared via Rte_Csm_Type.h, it is likely used primarily as an output parameter for verification services of the CSM [SWS_Csm_01024]. Question Q-067a1d2b36ffe56b (open) Specific error handlings such as DET or DEM notifications as well as requirements for reentrancy or concurrency are not specified for the type itself [SWS_Csm_01024].

The enumeration type Crypto_ResultType serves as a specific return type for functions of the AUTOSAR crypto stack and is available via header Rte_Csm_Type.h [SWS_Csm_91044]. It extends the classic return scheme by differentiated error and status notifications for cryptographic operations [SWS_Csm_91044].

In addition to the regular success status E_OK (0x00) and the general error E_NOT_OK (0x01), the type defines the following specific error states [SWS_Csm_91044]:

• Execution and resource states: CRYPTO_E_BUSY (0x02) designates a service that is still busy, CRYPTO_E_JOB_CANCELED (0x0C) the cancellation of a job, and CRYPTO_E_ENTROPY_EXHAUSTED (0x04) an exhausted entropy source of the random number generator [SWS_Csm_91044].
• Key and access issues: Specified are access denials when reading (CRYPTO_E_KEY_READ_FAIL, 0x06) or writing (CRYPTO_E_KEY_WRITE_FAIL, 0x07), missing keys (CRYPTO_E_KEY_NOT_AVAILABLE, 0x08), invalid keys (CRYPTO_E_KEY_NOT_VALID, 0x09), incorrect key sizes (CRYPTO_E_KEY_SIZE_MISMATCH, 0x0A), as well as uninitialized source key elements (CRYPTO_E_KEY_EMPTY, 0x0D) [SWS_Csm_91044].

Interpretation: Calling components are likely to evaluate these return codes in order to distinguish, depending on the situation, between temporary wait states and permanent configuration errors. Question Q-68cfedad7880908c (open)

Usage and Structure of Csm_HashDataType

According to [SWS_Csm_01920], the data type Csm_HashDataType is defined as an array with elements of the base type uint8. It serves as a data buffer for storing the input data to be subjected to a hash value calculation in the Crypto Service Manager. The length of the array is designed so that it is sufficient to hold all of the data to be hashed [SWS_Csm_01920].

Configuration and Variation

The actual dimensioning of the array is controlled via the configuration parameter CsmHashDataMaxLength, which is defined under the path Csm/CsmPrimitives/CsmHash/CsmHashConfig [SWS_Csm_01920]. This ensures that the memory area is dimensioned appropriately for the maximum expected amount of data of the respective hash configuration.

In addition, cryptographic variant formation exists according to the pattern Csm_HashDataType_{Crypto}, where the placeholder {Crypto} is resolved via the SHORT-NAME of the respective primitive configuration under Csm/CsmPrimitives [SWS_Csm_01920]. This enables primitive-specific buffer structures in the system.

Integration and Boundary Conditions

The type is provided via the header Rte_Csm_Type.h [SWS_Csm_01920]. This is likely to mean that the type is intended for standardized data transfer via RTE interfaces between software components and the CSM. Question Q-4240a8394cdd746d (open) When populating the buffer, users must ensure that data does not exceed the configured upper limit CsmHashDataMaxLength in order to avoid overflows during the hash calculation.

Usage and structure of Csm_HashResultType

The data type Csm_HashResultType represents an array of uint8 elements and serves as a sufficiently dimensioned memory area for storing the data of a hash result [SWS_Csm_00912].

The concrete buffer length of the array is configurable and is defined via the configuration parameter CsmHashResultLength under Csm/CsmPrimitives/CsmHash/CsmHashConfig/CsmHashResultLength [SWS_Csm_00912]. Thus, the size of the data type directly depends on the output length of the respective cryptographic hash algorithm.

The type definition is subject to name variation according to the pattern Csm_HashResultType_{Crypto}, where the identifier {Crypto} is substituted by the short name of the configured primitive (ecuc/Csm/CsmPrimitives.SHORT-NAME) [SWS_Csm_00912].

The data type is made available via the header Rte_Csm_Type.h [SWS_Csm_00912]. Interpretation: Due to the provision via Rte_Csm_Type.h, the type is likely primarily intended to be used in software components or at RTE interfaces as a typed result buffer for hash return values. Question Q-4ff10e08b6a5c8c0 (open)

The data type Csm_MacGenerateDataType serves as a byte array for storing the input data from which a Message Authentication Code (MAC) is to be calculated [SWS_Csm_00935].

Usage and Type Structure

According to [SWS_Csm_00935], the element is specified as an array with elements of base type uint8. The type name is subject to cryptographic name variation according to the scheme Csm_MacGenerateDataType_{Crypto}, where the suffix corresponds to the configured short name of the respective primitive [SWS_Csm_00935]. The dimensioning of the array is determined statically via the configuration parameter CsmMacGenerateDataMaxLength, ensuring that the array provides sufficient storage space for the data to be processed [SWS_Csm_00935].

Integration and Interfaces

The type is provided via the header file Rte_Csm_Type.h and links the data structures to the AUTOSAR RTE [SWS_Csm_00935]. Calling software components (SWCs) or basic software modules can use this type to declare typed data buffers for MAC generation services of the CSM.

restrictions

Since the array size is configured firmly via the maximum length, it is likely that it must be ensured at application level that the payload data does not exceed this limit, as the static type does not provide for dynamic length adjustment [SWS_Csm_00935]. Question Q-2010ffc7191f874a (open)

According to [SWS_Csm_00927], the data type Csm_MacGenerateResultType represents a byte array (element type uint8) that serves to hold the result data of a generated Message Authentication Code (MAC).

Usage and dimensioning

The specification defines the array as sufficiently long to store the data of the MAC ([SWS_Csm_00927]). The actual buffer size is defined via the configuration parameter CsmMacGenerateResultLength, which is configured under the path Csm/CsmPrimitives/CsmMacGenerate/CsmMacGenerateConfig ([SWS_Csm_00927]). In addition, the type is subject to cryptographic variation via the short name of the primitives ({Crypto} or ecuc/Csm/CsmPrimitives.SHORT-NAME) according to [SWS_Csm_00927].

Availability and Interface

The type is provided via the header Rte_Csm_Type.h ([SWS_Csm_00927]). This indicates that it is primarily designed for typed data transfer via the RTE interface to provide the calculated MAC value.

restrictions

Since this is a static type definition, the specific instantiation depends on the pre-configuration of the MAC length; further parameters, error codes, or concurrency requirements are not specified for this data type itself ([SWS_Csm_00927]).

The data type Csm_MacVerifyDataType is specified as an array of uint8 elements and serves as a buffer for storing the data for which a Message Authentication Code (MAC) is to be verified [SWS_Csm_00802].

The following provisions apply to the use and configuration of this type:

• Buffer size: The array size is determined by the configuration parameter CsmMacVerifyDataMaxLength in container Csm/CsmPrimitives/CsmMacVerify/CsmMacVerifyConfig. This ensures that the array is sufficiently dimensioned to completely accommodate the input data to be verified [SWS_Csm_00802].
• Variance and naming: The definition contains the variance criterion Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, whereby the concrete C type identifier is generated module-specifically in the form Csm_MacVerifyDataType_{Crypto} [SWS_Csm_00802].
• Interface integration: The type is exported via the header file Rte_Csm_Type.h [SWS_Csm_00802]. Interpretation: The provision in this header indicates that the type is likely primarily intended for RTE-based interface communication between software components and the CSM. Question Q-c49670b3de0ba19c (open)

Application developers must note that the maximum length of the verifiable payload data is limited by the static configuration of the primitives, and input data must not exceed this buffer capacity [SWS_Csm_00802].

Usage and structure

According to [SWS_Csm_00803], the type Csm_MacVerifyCompareType is defined as an array of uint8 elements. It serves to hold the Message Authentication Code (MAC) to be verified, which is to be compared with the MAC calculated as part of a cryptographic operation.

The type is provided via the header Rte_Csm_Type.h for the RTE interface [SWS_Csm_00803]. The concrete type name is subject to name variation via the primitive name according to the pattern Csm_MacVerifyCompareType_{Crypto}, where {Crypto} is replaced by the short name of the primitive (ecuc/Csm/CsmPrimitives.SHORT-NAME).

Configuration and sizing

According to [SWS_Csm_00803], the size of the array is dimensioned according to the expression CsmMacVerifyCompareLength/8 from the configuration (ecuc(Csm/CsmPrimitives/CsmMacVerify/CsmMacVerifyConfig/CsmMacVerifyCompareLength)). This reflects the length of the MAC comparison value in bytes.

Error Handling and Boundary Conditions

As a pure type definition for a data array, Csm_MacVerifyCompareType has no return values of its own and generates no direct error codes or DET/DEM events. However, the following application-related boundary conditions apply:

• Buffer provision: Callers are likely responsible for completely initializing the array with the received reference MAC before passing it to a verification function. Question Q-94b98958fd778057 (open)
• Concurrency: Since this is a data structure, the type itself is reentrant. However, concurrent read and write access to the same array instance by multiple tasks is likely to lead to corruption without synchronization. Question Q-148c0a523da7b402 (open)

The type Csm_EncryptDataType defines a byte array of uint8 elements that serves to hold the data to be encrypted [SWS_Csm_01921]. It is provided via the header file Rte_Csm_Type.h and enables software components to transfer typed data to the module's cryptographic services [SWS_Csm_01921].

Structure and Configuration

• Array elements: The elements are of the base type uint8 [SWS_Csm_01921].
• Size: The array length is based on the configuration parameter CsmEncryptDataMaxLength below the respective primitive configuration CsmEncryptConfig [SWS_Csm_01921].
• Naming variation: The type name varies depending on the primitive according to the scheme Csm_EncryptDataType_{Crypto}, where {Crypto} corresponds to the short name (SHORT-NAME) of the configured CSM primitive [SWS_Csm_01921].

Usage and restrictions

As a pure type definition, the element has no reentrancy or error handling of its own. Since the array size is fixedly coupled to the maximum buffer size of the configuration, as an interpretation, the caller is likely to have to ensure during population that the provided data does not exceed the buffer limit CsmEncryptDataMaxLength [SWS_Csm_01921]. Question Q-4bf70d603b5679d3 (open)

Usage and purpose

The data type Csm_EncryptResultType is specified as a byte array with element type uint8 and serves to hold the cipher data (cipher result) of an encryption operation ([SWS_Csm_01922]). According to the specification, the array must be dimensioned such that it is long enough to hold all data of the cipher ([SWS_Csm_01922]).

Configuration and variants

The definition of the data type is subject to variant formation based on the configured crypto primitives. For each primitive, a type-specific identifier is formed according to the scheme Csm_EncryptResultType_{Crypto}, where {Crypto} corresponds to the short name of the respective primitive ([SWS_Csm_01922]). The static array size of the array is determined via the configuration parameter CsmEncryptResultMaxLength under Csm/CsmPrimitives/CsmEncrypt/CsmEncryptConfig/ ([SWS_Csm_01922]).

Integration and Boundary Conditions

The data type is exported via the header file Rte_Csm_Type.h ([SWS_Csm_01922]). Interpretation: Due to its provision via Rte_Csm_Type.h, the type is likely designed for standardized data transfer between application software components and the Crypto Service Manager via RTE ports. Question Q-6dc06520e3fd9dc6 (open) When providing buffers, users must ensure that the cipher results do not exceed the configured maximum length CsmEncryptResultMaxLength ([SWS_Csm_01922]).

Usage and Data Structure

The type Csm_DecryptDataType is defined in the Crypto Service Manager specification as an array with elements of the base type uint8 [SWS_Csm_01923]. It serves as a dedicated memory buffer for the input data to be decrypted [SWS_Csm_01923]. The dimensioning of the array is mandatory specified such that its capacity must always be long enough to hold the respective data completely [SWS_Csm_01923].

Configuration and Variation

The dimensioning of the array is performed statically via the configuration parameter ecuc(Csm/CsmPrimitives/CsmDecrypt/CsmDecryptConfig/CsmDecryptDataMaxLength) [SWS_Csm_01923]. In addition, the data type is subject to cryptographic variance according to Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME} [SWS_Csm_01923]. As a result, the type identifier for the concrete primitive configuration is instantiated with the corresponding short name as Csm_DecryptDataType_{Crypto} [SWS_Csm_01923].

Integration and Boundary Conditions

The definition is provided for the overall system via the header file Rte_Csm_Type.h [SWS_Csm_01923]. Interpretation: Its inclusion in Rte_Csm_Type.h suggests that the type is primarily intended for typed ports and data exchange between software components and the CSM module via the RTE. Question Q-6dcc31d5d7258088 (open) Because it is a data structure and not a function, neither synchronous or asynchronous call semantics nor reentrancy requirements or specific DET error messages are defined within the scope of the specification [SWS_Csm_01923].

According to [SWS_Csm_01924], the data type Csm_DecryptResultType is defined in the module Csm as an array with elements of type uint8. It serves as a data buffer for storing the result data of a decrypted plaintext and must be sufficiently dimensioned to hold the complete plaintext.

According to [SWS_Csm_01924], the following specifications apply to the configuration, provision, and structuring of the type:

• Header availability: The definition of the data type is provided via the header file Rte_Csm_Type.h.
• Dimensioning of the buffer: The size of the array is specified via the configuration parameter CsmDecryptResultMaxLength (path Csm/CsmPrimitives/CsmDecrypt/CsmDecryptConfig/CsmDecryptResultMaxLength), statically defining the maximum memory space for the decryption result.
• Cryptographic variant formation: The type name is subject to primitive variant formation according to the scheme Csm_DecryptResultType_{Crypto}, with the form being controlled via the configuration element Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}.

With regard to call context, concurrency, and error handling, [SWS_Csm_01924] contains exclusively the type definition without any functional logic of its own. Interpretation: The type is likely to serve primarily in consuming software components as a storage structure to hold output data from cryptographic decryption operations of the CSM. Question Q-54c836ed946ee1f2 (open) Specific DET or DEM error codes are not defined for this data type; however, configuration engineers must ensure that the configured maximum length is sufficient for all plaintexts to be processed.

Usage and Type Definition

According to [SWS_Csm_01925], the data type Csm_AEADEncryptPlaintextType serves as a data buffer for the plaintext to be processed as part of an AEAD (Authenticated Encryption with Associated Data) encryption operation. The type is defined as a byte array with element type uint8 and provides sufficient memory space to completely hold the plaintext to be encrypted.

Dimensioning and Variant Formation

The concrete buffer size is not rigid, but depends on the configuration parameter CsmAEADEncryptPlaintextMaxLength from the configuration of the respective primitive ([SWS_Csm_01925]). In addition, the type is subject to a naming and structural variation: depending on the configured crypto primitive, the identifier is extended by the short name of the primitive (Csm_AEADEncryptPlaintextType_{Crypto}).

Integration and Interface

According to [SWS_Csm_01925], the type is provided via the header Rte_Csm_Type.h. This supports the interpretation that the type is made available for application software components primarily in the context of the AUTOSAR RTE in order to pass typed plaintext data to cryptographic services of the CSM. Since it is a pure type declaration, the specification defines no error codes or reentrancy requirements of its own at the data type level.

The data type Csm_AEADEncryptAssociatedDataType defines a byte array of elements of the base type uint8 that serves as a buffer to hold the header or associated additional data during AEAD encryption operations [SWS_Csm_01928]. The type is provided via the header file Rte_Csm_Type.h and enables typed data exchange via the AUTOSAR RTE interface of the Crypto Service Manager [SWS_Csm_01928].

The dimensioning and manifestation of the type depend on the configuration of the cryptographic primitive [SWS_Csm_01928]:

• Array size: The buffer size is dimensioned according to the configuration parameter CsmAEADEncryptAssociatedDataMaxLength within the configuration Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig, which ensures that the array is sufficiently long for the header data [SWS_Csm_01928].
• Naming variation: The element is subject to a cryptography-specific naming variation Csm_AEADEncryptAssociatedDataType_{Crypto}, where the placeholder {Crypto} corresponds to the short name of the respective primitive from CsmPrimitives.SHORT-NAME [SWS_Csm_01928].

When populating the array, callers must ensure that the actual length of the header data to be transferred does not exceed the configured maximum size [SWS_Csm_01928]. Interpretation: Since associated data remains unencrypted in AEAD schemes but is authenticated, the data type is likely intended primarily to transfer protocol-specific metadata consistently between the application and the CSM. Question Q-26b724044c51253f (open)

According to [SWS_Csm_01927], the data type Csm_AEADEncryptCiphertextType serves as a byte array for storing the cipher data during cryptographic AEAD encryption operations in the Classic AUTOSAR module Csm.

The specification defines the data element as an array of elements of the base type uint8 [SWS_Csm_01927]. The fixed buffer size is determined via the configuration parameter CsmAEADEncryptCiphertextMaxLength within the configuration path Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig [SWS_Csm_01927]. According to the requirement, the array must be dimensioned long enough to hold the complete data of the cipher [SWS_Csm_01927].

The type identifier exhibits a primitive-dependent naming variation: via the configuration attribute Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, the concrete type name is expanded to Csm_AEADEncryptCiphertextType_{Crypto} [SWS_Csm_01927]. This definition is provided for application software components and the CSM via the header file Rte_Csm_Type.h [SWS_Csm_01927].

In practical use, calling components are likely to declare corresponding buffers to receive the cipher results of an AEAD operation. Question Q-af095525ea319451 (open) Specific call contexts, error handlings (such as DET or DEM), return values, or reentrancy requirements are not defined for this data structure in the sources.

According to [SWS_Csm_01926], the data type Csm_AEADEncryptTagType defines a byte array (element type uint8) that serves as a buffer for the authentication tag data during AEAD encryption operations. As specified, the array is designed to be long enough to completely hold the tag data [SWS_Csm_01926].

Regarding structure and configuration, the following specifications from [SWS_Csm_01926] apply:

• Buffer size: The dimensioning of the array is specified via the configuration parameter CsmAEADEncryptTagLength under Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig [SWS_Csm_01926].
• Naming variant: The type name possesses cryptographic variance and is formed according to the scheme Csm_AEADEncryptTagType_{Crypto}, where {Crypto} corresponds to the short name of the respective primitive (SHORT-NAME) [SWS_Csm_01926].
• Header inclusion: The type is provided via the header Rte_Csm_Type.h [SWS_Csm_01926].

Due to its availability in Rte_Csm_Type.h, the data type is likely intended for standardized software interfaces (interpretation: use for buffer passing in software component ports) [SWS_Csm_01926]. Question Q-3cd2f6ae1229483e (open)

Usage and structure

According to [SWS_Csm_00922], the data type Csm_AEADDecryptCiphertextType defines a byte array based on the element type uint8. It serves as a sufficiently dimensioned buffer for holding the ciphertext that is to be decrypted within an AEAD (Authenticated Encryption with Associated Data) operation [SWS_Csm_00922]. The type definition is provided via the header file Rte_Csm_Type.h [SWS_Csm_00922].

Dimensioning and Variance

The dimensioning of the array is performed statically using the configuration parameter CsmAEADDecryptCiphertextMaxLength within the configuration branch Csm/CsmAEADDecrypt/CsmAEADDecryptConfig [SWS_Csm_00922]. The array is designed to hold the entire ciphertext to be processed. Furthermore, the type name is subject to cryptographic variance according to the pattern Csm_AEADDecryptCiphertextType_{Crypto}, where the identifier part {Crypto} is formed by the short name of the respective primitive (CsmPrimitives.SHORT-NAME) [SWS_Csm_00922].

Interaction and Boundary Conditions

Due to the definition in Rte_Csm_Type.h, the type is likely intended primarily for the typed connection of software components (SW-Cs) via RTE ports to the Crypto Service Gateway or CSM [SWS_Csm_00922]. Question Q-35738ff5fc96c699 (open) Since the array size is fixed at configuration time, callers must ensure that the ciphertext data does not exceed the maximum length in order to rule out buffer overflows at runtime.

The data type Csm_AEADDecryptAssociatedDataType is defined as an array of elements of type uint8 and carries the formation-dependent name pattern Csm_AEADDecryptAssociatedDataType_{Crypto} [SWS_Csm_00923]. The purpose of this data type is to provide a memory area that is sufficiently dimensioned to hold the header data or associated data of an authenticated decryption (AEAD Decrypt) [SWS_Csm_00923].

The size of the array depends on the configuration parameter CsmAEADDecryptAssociatedDataMaxLength in the configuration path Csm/CsmAEADDecrypt/CsmAEADDecryptConfig [SWS_Csm_00923]. Via the variance Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, the type identifier is specialized for the respective primitive configured in the Crypto Service Manager using its short name [SWS_Csm_00923]. This allows a specific buffer with a suitable maximum length to be declared for each cryptographic primitive.

The data type is exported via the header file Rte_Csm_Type.h [SWS_Csm_00923]. Since this is a pure type definition, the entry specifies no error codes, DET messages, or reentrancy conditions. As an interpretation, the array is likely to serve as a typed data buffer for passing unencrypted accompanying data, which is to be cryptographically verified, between software components and the CSM via the RTE. Question Q-2f32bbe9a4489b27 (open)

Usage and purpose

The data type Csm_AEADDecryptTagType is defined as a byte array with element type uint8 and serves as a dedicated memory area for holding tag data in AEAD decryption operations [SWS_Csm_01074]. It is provided via the header file Rte_Csm_Type.h [SWS_Csm_01074].

Dimensioning and Configuration Dependency

The dimensioning of the array is configurable and depends on the configured tag length CsmAEADDecryptTagLength [SWS_Csm_01074]. The number of elements is determined via the expression (({ecuc(Csm/CsmPrimitives/CsmAEADDecrypt/CsmAEADDecryptConfig/CsmAEADDecryptTagLength)}+7)/8) [SWS_Csm_01074]. Through this calculation, the tag length specified in bits is converted into complete bytes, rounding up bit lengths not divisible by eight to the next byte boundary.

The type is subject to a name variation according to the scheme Csm_AEADDecryptTagType_{Crypto}, where {Crypto} is replaced by the short name (SHORT-NAME) of the respective primitive configuration [SWS_Csm_01074]. As a result, a suitably typed structure exists for each configured AEAD decryption primitive instance.

Integration and Boundary Conditions

The provision via Rte_Csm_Type.h is likely to mean that this type is intended primarily for software components at ports of the AUTOSAR RTE in order to pass the authentication tag to the Crypto Service Manager [SWS_Csm_01074]. Question Q-2a0bebbb8e1d6b76 (open) Since the type does not bring its own control flows or synchronization mechanisms, the consistency of the data in the buffer is presumably ensured entirely by the calling context during the decryption cycle.

Usage and structure

The data type Csm_AEADDecryptPlaintextType or its primitive-specific variant Csm_AEADDecryptPlaintextType_{Crypto} is defined as a byte array with elements of type uint8 [SWS_Csm_01075]. It serves to provide a sufficiently dimensioned buffer for storing plaintext data during an AEAD (Authenticated Encryption with Associated Data) decryption [SWS_Csm_01075]. The fixed array size is determined via the configuration parameter CsmAEADDecryptPlaintextMaxLength within the configuration of the respective AEAD decryption primitive [SWS_Csm_01075]. The data type is provided for software components via the header Rte_Csm_Type.h, with the type name being linked to the short name of the configured CSM primitives via the variation Crypto [SWS_Csm_01075].

Error Handling and Concurrency

Since it is a pure type definition, the element defines no return values, error codes, or DET messages of its own [SWS_Csm_01075]. The essential functional constraint lies in the statically specified maximum length: plaintext data that exceeds the configured limit cannot be accommodated in this buffer [SWS_Csm_01075]. Interpretation: The type is likely intended primarily for typed data transfer via RTE ports when SWCs receive results from decryption services asynchronously or synchronously. Question Q-2de04243d7f996c8 (open) Callers presumably need to independently ensure that buffer boundaries are respected and that concurrent read or write accesses across multiple tasks are synchronized in a thread-safe manner.

According to [SWS_Csm_01083], the type Csm_SignatureGenerateDataType defines an array of uint8 elements that serves as a buffer to hold the data from which a cryptographic signature is to be generated. The concrete naming in the source code is primitive-specific and follows the pattern Csm_SignatureGenerateDataType_{Crypto}, with the identifier varied via the short name of the configured crypto primitive [SWS_Csm_01083].

The static dimensioning of the data array is determined via the configuration parameter CsmSignatureGenerateDataMaxLength [SWS_Csm_01083]. The data type is provided via the header file Rte_Csm_Type.h [SWS_Csm_01083]. Interpretation: Due to its provision via Rte_Csm_Type.h, the array type is likely intended primarily for typed data transfer at RTE ports between software components and the CSM module. Question Q-dcc731a5b8961aef (open)

During configuration and use, it must be noted that CsmSignatureGenerateDataMaxLength defines the fixed upper limit of the array [SWS_Csm_01083]. Users must ensure through configuration that the buffer size is sufficient for all input data for signature generation occurring during operation, since the array is statically allocated.

According to [SWS_Csm_01077], the data type Csm_SignatureGenerateResultType defines a byte array based on uint8 that serves to hold a generated cryptographic signature and its length specification. The type is declared via the header Rte_Csm_Type.h and provides the standardized output buffer for signature operations in the Crypto Service Manager.

The structure and dimensioning of the type are configurable:

• Buffer size: The number of uint8 elements is specified via the configuration parameter CsmSignatureGenerateResultLength of the respective signature generation configuration ([SWS_Csm_01077]).
• Naming variant: The identifier contains the suffix _{Crypto}, which corresponds to the short name of the configured primitive ([SWS_Csm_01077]).

Since it is a pure type definition, [SWS_Csm_01077] contains no specification of error codes, DET messages, or reentrancy properties. Runtime semantics and buffer passing are likely to follow the synchronous or asynchronous calling conventions of the CSM service interfaces. Question Q-3304c06a29f069a2 (open) Callers must ensure that the configured array size is always sufficient for the signature to be held, including the length value.

According to [SWS_Csm_01078], the data type Csm_SignatureVerifyDataType is defined as a byte array with element type uint8 and serves to buffer data whose signature is to be verified.

According to [SWS_Csm_01078], the following specifications apply to the configuration and use of the type:

• Array dimensioning: The size of the array corresponds to the configuration value CsmSignatureVerifyDataMaxLength from the configuration path Csm/CsmPrimitives/CsmSignatureVerify/CsmSignatureVerifyConfig, so that the array is sufficiently dimensioned to hold all of the data to be verified.
• Naming variation: The type name varies depending on the respective crypto primitive according to the scheme Csm_SignatureVerifyDataType_{Crypto}, where {Crypto} corresponds to the short name CsmPrimitives.SHORT-NAME.
• Header provision: The type definition is available via the header file Rte_Csm_Type.h.

Interpretation: By being provided in Rte_Csm_Type.h, the type is likely intended primarily for software components at the RTE interface to pass payload data up to the configured maximum length to the Crypto Service Manager for signature verification [SWS_Csm_01078]. Question Q-c1541703c2bcd199 (open)

The type Csm_SignatureVerifyCompareType defines a byte array based on uint8 that provides sufficient memory space for a cryptographic signature to be verified ([SWS_Csm_01079]). It is provided via the header Rte_Csm_Type.h and enables software components to access signature comparison data in a typed manner ([SWS_Csm_01079]).

Configuration and Variance

The concrete size of the array is not fixed, but is determined by the configuration value CsmSignatureVerifyCompareLength from the signature verification configuration of the respective primitive ([SWS_Csm_01079]). In addition, the type is subject to a naming variation via the short name of the cryptographic primitive (Crypto = {ecuc/Csm/CsmPrimitives.SHORT-NAME}), so that the typed identifier is formed as Csm_SignatureVerifyCompareType_{Crypto} ([SWS_Csm_01079]).

Usage Aspects and Constraints

• Call context and semantics: As a pure data structure, the element has no independent synchronous or asynchronous semantics. Instantiation is typically performed by the caller of the module's verification services ([SWS_Csm_01079]).
• Error handling: The type definition does not define any error codes or DET/DEM messages of its own ([SWS_Csm_01079]). Interpretation: Validation of buffer length or pointer integrity is likely to take place in the consuming CSM functions. Question Q-60454c8a7d8035cf (open)
• Concurrency: For pure type definitions, there are no restrictions regarding reentrancy; concurrent access to buffer instances must be coordinated by the consuming modules ([SWS_Csm_01079]).

Usage and purpose

The data type Csm_RandomGenerateResultType is defined as an array and serves as a structured memory area for storing the result data of a generated random number [SWS_Csm_00930]. The individual elements of the array have the base type uint8, mapping the resulting random number as a contiguous byte sequence [SWS_Csm_00930].

Configuration and Variation

The buffer size is not passed dynamically, but is determined statically via the module configuration: the number of array elements depends on the configuration parameter CsmRandomGenerateResultLength below the path Csm/CsmPrimitives/CsmRandomGenerate/CsmRandomGenerateConfig [SWS_Csm_00930]. In addition, the identifier is subject to cryptography-specific name variation according to the scheme Csm_RandomGenerateResultType_{Crypto}, where the suffix corresponds to the short name of the respective primitive [SWS_Csm_00930]. In this way, each configured instance of random number generation receives a type-conformant buffer of suitable length.

Integration and Boundary Conditions

The declaration of the type is provided via the header file Rte_Csm_Type.h [SWS_Csm_00930]. Interpretation: Since it is provided via the RTE header, this data type is likely intended primarily for Application Software Components to receive random values via ports in a type-safe manner. Question Q-ea993612037bec12 (open) Concrete API call contexts, error codes, or concurrency aspects are not anchored in the type itself, but in the associated CSM services, while this type secures the static memory requirement [SWS_Csm_00930].

Usage and Semantics

The type Csm_VerifyResultPtr is an AUTOSAR Implementation Data Type of category DATA_REFERENCE whose pointer target is Csm_VerifyResultType (formally Csm_VerifyResultType*) [SWS_Csm_91046]. The type definition is provided via the header Rte_Csm_Type.h and is thus available for application components via the RTE as well as for basic software modules [SWS_Csm_91046].

The functional purpose of Csm_VerifyResultPtr is to return the verification result for asynchronous cryptographic operations [SWS_Csm_91046]. In the case of asynchronous execution, the pointer refers to a buffer reserved by the caller, into which the Csm module writes the result after completion of the check [SWS_Csm_91046].

Concurrency and Limitations

Since Csm_VerifyResultPtr is explicitly intended for asynchronous feedback [SWS_Csm_91046], users must ensure that the validity of the referenced target object is preserved throughout the entire duration of the operation. The following aspects must be taken into account:

• The referenced memory area of type Csm_VerifyResultType likely has to remain valid and protected during the entire asynchronous execution time until the feedback arrives (Interpretation: avoidance of write accesses to invalid memory addresses). Question (open)
• Callers should presumably not point the pointer to volatile stack variables if the calling function can already be exited before the asynchronous job is completed. Question (open)

The enumeration type Crypto_KeyStatusType defines the validity status of cryptographic keys and is provided via the header file Rte_Csm_Type.h [SWS_Csm_91102].

Value Range and Semantics

The type comprises two values [SWS_Csm_91102]:

• CRYPTO_KEYSTATUS_INVALID (0x00): The status of the key is invalid. This occurs, for example, if after setting a key element using Csm_KeyElementSet, the function Csm_KeySetValid has not yet been executed.
• CRYPTO_KEYSTATUS_VALID (0x01): The key is valid after the status has been set, for example, by the successful call of Csm_KeySetValid.

Order Requirements and Interaction

The state logic couples validity directly to the update processes of key management: Every modification of key elements transitions the key into an invalid intermediate state, which is only terminated by explicit validation via Csm_KeySetValid [SWS_Csm_91102]. Interpretation: Callers and cryptographic services are therefore likely to require the status CRYPTO_KEYSTATUS_VALID before executing cryptographic operations in order to rule out malfunctions due to incomplete key data. Question Q-7ad50e0568814efa (open)