Crypto Driver (Crypto)

Modul	Crypto (Crypto Driver)
BSW-Modul-ID	`114`
Standard-Header	`#include "Crypto.h"`
SWS-Spezifikation	AUTOSAR_SWS_CryptoDriver.pdf
Cluster	Crypto Services

Module guideAI-GENERATED

Provides cryptographic primitives and key management for the hardware-oriented AUTOSAR Classic crypto stack.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 79b1b64c6bf7 Provenance Open questions (2)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Provides cryptographic primitives and key management for the hardware-oriented AUTOSAR Classic crypto stack.

As an MCAL module, the Crypto Driver provides hardware-oriented cryptographic computations as well as key management for the AUTOSAR Classic crypto stack (EXP_UtilizationOfCryptoServices p. 8). It encapsulates hardware security modules (HSM) or software libraries in Driver Objects and processes synchronous as well as asynchronous jobs via the central interface Crypto_ProcessJob ([SWS_Crypto_91003]). Key accesses are subject to configurable rights, and persistent storage in the NVM is triggered only upon successful key validation (SWS_CryptoDriver p. 37).

As an MCAL driver, the Crypto Driver (module Crypto) forms the lowest foundation of the AUTOSAR Classic crypto stack and interfaces hardware security modules (HSM), crypto accelerators, and software routines directly to the crypto interface (CryIf) (EXP_UtilizationOfCryptoServices p. 8, SWS_CryptoDriver p. 15). In multi-implementations, instances are named vendor-specifically according to the schema Crypto_<vi>_<ai> ([SWS_Crypto_00012]). Initialization is performed synchronously via [SWS_Crypto_91000] with a mandatory null pointer for [SWS_Crypto_91016] ([SWS_Crypto_00215]). Internally, the module encapsulates independent computing units in Crypto Driver Objects, each of which can execute exactly one job at a time ([SWS_Crypto_00014]), while n objects enable parallel computations ([SWS_Crypto_00117]). Driver Object 0 acts as the central random number generator for internal demands of all other driver objects of the same instance ([SWS_Crypto_00224], [SWS_Crypto_00225]).

Context diagram: Embedding of the Crypto Driver into the AUTOSAR crypto stack with Driver Objects and interfaces to NvM and DET. Sources: SWS_CryptoDriver p. 15, SWS_Crypto_00012, SWS_Crypto_91017

Cryptographic jobs are processed via [SWS_Crypto_91003] (Crypto_ProcessJob), where a mode bitfield (START, UPDATE, FINISH) unifies streaming and overall calls (SWS_CryptoDriver p. 25, [SWS_Crypto_00017]). Asynchronous jobs are calculated via the cyclic function [SWS_Crypto_91012] (Crypto_MainFunction) and reported to CryIf via CRYIF_CallbackNotification upon completion ([SWS_Crypto_00027], [SWS_Crypto_00028]). Running jobs can be canceled synchronously using [SWS_Crypto_00122] ([SWS_Crypto_00183], [SWS_Crypto_00214]), while direct buffer redirections to key elements reduce copy operations ([SWS_Crypto_00203], [SWS_Crypto_00221]).

Sequence diagram: Asynchronous processing sequence via Crypto_ProcessJob, cycle in Crypto_MainFunction, and feedback via CRYIF_CallbackNotification. Sources: SWS_Crypto_91003, SWS_Crypto_00027, SWS_Crypto_00028, SWS_Crypto_91012

Key management encompasses setting ([SWS_Crypto_91004]), reading ([SWS_Crypto_91006]), copying ([SWS_Crypto_00155], [SWS_Crypto_91015]), generating ([SWS_Crypto_91007]), and deriving ([SWS_Crypto_91008]) key elements under strict access rights control ([SWS_Crypto_00219], [SWS_Crypto_00220]). For consistency reasons, persistence in the Non-Volatile RAM Manager (NvM) is never triggered during single writes, but exclusively during key validation via [SWS_Crypto_91014] (Crypto_KeySetValid) (SWS_CryptoDriver p. 37, [SWS_Crypto_91025]). In multi-core environments, the module operates in isolation in each partition ([SWS_Crypto_CONSTR_00001]), whereby HSM objects may be assigned to at most one partition ([SWS_Crypto_CONSTR_00003]).

Role and System Boundaries of the Crypto Driver in the Classic Crypto Stack

The Crypto Driver (module abbreviation Crypto) is located at the lowest layer of the AUTOSAR Classic basic software in the Microcontroller Abstraction Layer (MCAL) (EXP_UtilizationOfCryptoServices p. 8). It is located directly below the crypto interface (Crypto Interface, CryIf) and serves the Crypto Service Manager (CSM) via this interface (SWS_CryptoDriver p. 15). Its main task consists in encapsulating the concrete cryptographic processing units—be they hardware security modules (Hardware Security Modules, HSM), dedicated crypto accelerators such as AES engines, or pure software libraries (SWS_CryptoDriver p. 15). In addition to the actual computation of cryptographic primitives, the scope of functions includes the storage, configuration, and management of cryptographic keys (SWS_CryptoDriver p. 24).

Multiple driver instances from different vendors can coexist in an ECU; in this case, file, API, and configuration identifiers are uniquely differentiated by a vendor-specific infix according to the schema Crypto_<vi>_<ai> ([SWS_Crypto_00012]). Initialization of the module is performed via the function [SWS_Crypto_91000] (Crypto_Init). As a special rule for the configuration pointer of type [SWS_Crypto_91016] (Crypto_ConfigType), it must always be passed as a null pointer ([SWS_Crypto_00215]). Version information can be queried synchronously via [SWS_Crypto_91001] (Crypto_GetVersionInfo), where passing a null pointer with active development detection is reported to DET with the error CRYPTO_E_PARAM_POINTER (SWS_CryptoDriver p. 56).

Context diagram: Embedding of the Crypto Driver into the AUTOSAR crypto stack with Driver Objects and interfaces to NvM and DET. Sources: SWS_CryptoDriver p. 15, SWS_Crypto_00012, SWS_Crypto_91017

Management of Crypto Driver Objects and Hardware Abstraction

Each instance of the Crypto Driver is divided internally into one or more logical driver objects (Crypto Driver Objects) (SWS_CryptoDriver p. 15). A Crypto Driver Object forms the functional endpoint of a crypto channel and represents an independent hardware processing unit or a software implementation (SWS_CryptoDriver p. 15). Inherently, a single Driver Object can actively execute only exactly one job at any given time ([SWS_Crypto_00014]). Consequently, a Crypto Driver with n Driver Objects has the capacity to compute n crypto jobs in parallel ([SWS_Crypto_00117]). Which mathematical and security-relevant primitives are supported is determined by the capabilities of the assigned object ([SWS_Crypto_00013]).

If a driver object requires internal random numbers (for instance, to calculate public values in the context of key exchange via [SWS_Crypto_91009]) and does not have its own random number generator, it mandatorily relies on Crypto Driver Object 0 of the same driver ([SWS_Crypto_00224], [SWS_Crypto_00225]). Under no circumstances may driver objects address random number generators of external crypto driver instances ([SWS_Crypto_00226]). Interpretation: Driver Object 0 thus acts as a central internal reference random number generator for all further driver objects of the same partition. Question Q-4e8e30714cbc9c80 (open)

Job Processing Between Synchronous Direct Call and Asynchronous Streaming

Cryptographic processing is passed to the module as job structures of type Crypto_JobType via the central interface [SWS_Crypto_91003] (Crypto_ProcessJob) ([SWS_Crypto_00042], AUTOSAR_CP_SWS_CryptoServiceManager p. 21). The interface combines block-based overall calls and continuous data streaming via a mode-specific bitfield: the operations START, UPDATE, and FINISH can be passed individually or combined (SWS_CryptoDriver p. 25). Setting the START flag marks a new job and cancels all previous instances of the same job ([SWS_Crypto_00017]). When passed in combination, the steps are always executed in the fixed order START, UPDATE, and finally FINISH (SWS_CryptoDriver p. 25).

Whether a job is processed synchronously or asynchronously is part of the metadata configuration in Crypto_JobType (SWS_CryptoDriver p. 26). In asynchronous mode, [SWS_Crypto_91003] only accepts the job data; the actual execution is triggered or processed by the cyclic main function [SWS_Crypto_91012] (Crypto_MainFunction) ([SWS_Crypto_00027], [SWS_Crypto_91012]). After completion of the asynchronous calculation, the Crypto Driver mandatorily notifies the upper layer CryIf by calling the callback function CRYIF_CallbackNotification, returning the status and result pointers ([SWS_Crypto_00028]). Interpretation: Synchronous calls, on the other hand, execute the crypto operation blockingly in the context of the caller without being decoupled via the main function. Question Q-0447ed9db11aa30b (open)

Running or pending crypto jobs can be canceled via the function [SWS_Crypto_00122] (Crypto_CancelJob). If the requested job is not in active processing by the driver object, it is removed immediately and the call returns E_OK ([SWS_Crypto_00214]). However, if the hardware cannot interrupt the active computation process immediately, the API acknowledges the attempt with CRYPTO_E_JOB_CANCELED, and the cancellation is completed at the next reachable step ([SWS_Crypto_00183]).

Sequence diagram: Synchronous cancellation of cryptographic jobs via Crypto_CancelJob with case distinction during active hardware execution. Sources: SWS_Crypto_00122, SWS_Crypto_00183, SWS_Crypto_00214

To avoid unnecessary copy operations between application and hardware memories, the Crypto Driver supports direct buffer redirection (Job Redirection): input and output data can be referenced directly to internal key elements via jobRedirectionInfoRef ([SWS_Crypto_00203], [SWS_Crypto_00204]). To prevent data leaks, strict rights checks apply: for input redirections for encryption and decryption services, the key element must have at least the right CRYPTO_RA_ENCRYPTED; for pure read redirections, at least CRYPTO_RA_INTERNAL_COPY is required ([SWS_Crypto_00221]).

Key Management, Access Rights, and Cryptographic Key Operations

In the Crypto Driver, a logical key (Key) consists of one or more key elements (Key Elements) that hold the actual key material, initialization vectors (IV), random seeds, or SHE proofs (Proof) (SWS_CryptoDriver p. 28). Access to each individual element is strictly regulated: read and write accesses are monitored based on configured rights hierarchies (e.g., CRYPTO_RA_ALLOWED, CRYPTO_RA_ENCRYPTED, CRYPTO_RA_INTERNAL_COPY), where a smaller enumeration value represents a higher-level access right (SWS_CryptoDriver p. 28, [SWS_Crypto_00219]). Direct read operations are only permitted for CRYPTO_RA_ALLOWED or CRYPTO_RA_ENCRYPTED ([SWS_Crypto_00222]); write accesses require at least CRYPTO_WA_ALLOWED or CRYPTO_WA_ENCRYPTED ([SWS_Crypto_00223]). When copying, the source element must have at least CRYPTO_RA_INTERNAL_COPY and must not have lower rights than the target element ([SWS_Crypto_00220]).

For direct manipulation of keys and their elements, the Crypto Driver provides a series of synchronous APIs: setting and reading data is performed via [SWS_Crypto_91004] (Crypto_KeyElementSet) and [SWS_Crypto_91006] (Crypto_KeyElementGet), respectively. Existing element identifiers of a key can be determined via [SWS_Crypto_00160] (Crypto_KeyElementIdsGet). Complete keys or individual elements are duplicated using [SWS_Crypto_00155] (Crypto_KeyCopy) or [SWS_Crypto_00148] (Crypto_KeyElementCopy). For partial copies, [SWS_Crypto_91015] (Crypto_KeyElementCopyPartial) exists, which enforces precise length and offset checks on source and target buffers ([SWS_Crypto_00207], [SWS_Crypto_00208], [SWS_Crypto_00209]) and dynamically adapts the target length ([SWS_Crypto_00210], [SWS_Crypto_00211]).

In addition, the module supports complex key operations: key generation is performed via [SWS_Crypto_91007] (Crypto_KeyGenerate) based on entropy data previously initialized using [SWS_Crypto_91013] (Crypto_RandomSeed). Derivation of new key materials is handled by [SWS_Crypto_91008] (Crypto_KeyDerive). For Diffie-Hellman key exchange protocols, the functions [SWS_Crypto_91009] (Crypto_KeyExchangeCalcPubVal) for generating the public value and [SWS_Crypto_91010] (Crypto_KeyExchangeCalcSecret) for determining the shared secret are available (SWS_CryptoServiceManager p. 70).

Each logical key maintains a status that can be queried via [SWS_Crypto_91019] (Crypto_KeyGetStatus). Newly written keys are initially in the state invalid and are released as valid only after successful validation using [SWS_Crypto_91014] (Crypto_KeySetValid), whereas [SWS_Crypto_91020] (Crypto_KeySetInvalid) explicitly locks the key. Regarding data formats, the driver processes asymmetric keys according to RFC 5958 in ASN.1-PKCS#8 encoding ([SWS_Crypto_00184]), RSA key structures according to RFC 8017 with fixed algorithm OID 1.2.840.113549.1.1.1 ([SWS_Crypto_00185], [SWS_Crypto_00186], [SWS_Crypto_00187], [SWS_Crypto_00188]), as well as ECC curve data (NIST, Brainpool, ED25519) in little-endian point coordinates ([SWS_Crypto_00189], [SWS_Crypto_00190], [SWS_Crypto_00191], [SWS_Crypto_00192], [SWS_Crypto_00193]). Hardware-oriented SHE keys are passed in the format M1M2M3; their verification proof M4M5 can be read temporarily in key element 2 immediately after validation ([SWS_Crypto_00255]).

State diagram: State transitions of a key from filling to validation up to persistence and error handling. Sources: SWS_Crypto_00198, SWS_Crypto_00242, SWS_Crypto_91014, SWS_Crypto_91019, SWS_Crypto_91020

Persistence of Key Elements via the Non-Volatile RAM Manager

If keys are to be retained non-volatilely across power cycles, the Crypto Driver is connected to the Non-Volatile RAM Manager (NvM) (SWS_CryptoDriver p. 35, AUTOSAR_CP_SWS_CryptoDriver p. 37). A central architectural principle states that write operations to the NvM are never initiated directly when filling an individual element via Crypto_KeyElementSet (SWS_CryptoDriver p. 37). Instead, persistence is initiated exclusively by the status validation KEYSETVALID via [SWS_Crypto_91014] (Crypto_KeySetValid) or an equivalent crypto job (SWS_CryptoDriver p. 37). This guarantees that mutually dependent key elements are checked consistently and stored in a single NvM write access, which saves flash cycles (SWS_CryptoDriver p. 37).

Interaction with the NvM takes place via dedicated callback interfaces: during ECU startup, the NvM provides the initialization block via [SWS_Crypto_91023] (Crypto_<vi>_<ai>_NvBlock_Init_<NvBlock>). Loading persisted data from the RAM mirror of the NvM is performed via [SWS_Crypto_91024] (Crypto_<vi>_<ai>_NvBlock_ReadFrom_<NvBlock>). Prior to writing, the NvM calls [SWS_Crypto_91025] (Crypto_<vi>_<ai>_NvBlock_WriteTo_<NvBlock>) so that the crypto driver copies its internal key data into the NvM buffer; completion of the asynchronous block transfer is reported via [SWS_Crypto_91026] (Crypto_<vi>_<ai>_NvBlock_Callback_<NvBlock>). For control purposes, the driver uses the NvM services NvM_SetRamBlockStatus and NvM_WriteBlock ([SWS_Crypto_91017]). If loading a persistent key fails during startup, the driver mandatorily marks this key as invalid ([SWS_Crypto_00198]).

Sequence diagram: Persistence of key elements into NVM upon validation via NvM_WriteBlock and driver-specific callbacks. Sources: SWS_Crypto_00242, SWS_Crypto_91017, SWS_Crypto_91025, SWS_Crypto_91026

Partitioning and Multi-Core Operating Rules

To efficiently distribute crypto operations across multi-core systems, the crypto stack can be distributed over multiple software partitions (BSWDistributionGuide p. 59). The Crypto module operates in each partition as a completely independent instance: each API call processes data exclusively within the partition in which it was issued ([SWS_Crypto_CONSTR_00001]). Partitioning of the driver objects is subject to strict configuration rules: the partitions referenced by CryptoDriverObjectEcucPartitionRef must mandatorily form a proper subset of the partitions assigned to the module (CryptoEcucPartitionRef) ([SWS_Crypto_CONSTR_00002]). If a Crypto Driver Object is coupled to a hardware security module (HSM), it may be assigned to exactly 0 or 1 partition for reasons of hardware isolation ([SWS_Crypto_CONSTR_00003]).

Behavior in the event of an error

The Crypto Driver implements a two-stage error monitoring consisting of development detection (Development Errors) and runtime errors (Runtime Errors). With development error detection (DET) enabled, formal interface violations are transmitted to Det_ReportError ([SWS_Crypto_91017]). These include calls prior to driver initialization (CRYPTO_E_UNINIT, 0x00) ([SWS_Crypto_00040], [SWS_Crypto_00196], [SWS_Crypto_00205]), invalid initialization data (CRYPTO_E_INIT_FAILED, 0x01), and inadmissible null pointers (CRYPTO_E_PARAM_POINTER, 0x02) ([SWS_Crypto_00040]). If key identifiers or target key handles are outside the permissible value range, the driver aborts the call with E_NOT_OK and reports CRYPTO_E_PARAM_HANDLE (0x04) ([SWS_Crypto_00040], [SWS_Crypto_00180], [SWS_Crypto_00197], [SWS_Crypto_00202], [SWS_Crypto_00217]).

If the passed input or output buffers are insufficient for an operation, execution is refused and, with DET active, the error CRYPTO_E_SMALL_BUFFER is reported ([SWS_Crypto_00195], SWS_CryptoDriver p. 49). A normative exception applies to the services CRYPTO_HASH and CRYPTO_MACGENERATE: If the output buffer is smaller than the native hash or MAC length here, the result is not discarded, but written to the buffer truncated in the form of the most significant bits (MSB) ([SWS_Crypto_00065]). In operational mode, the driver reports specific runtime errors via the return value: Depletion of random entropy is acknowledged by [SWS_Crypto_91003] with the return code CRYPTO_E_ENTROPY_EXHAUSTED and reports the runtime error CRYPTO_E_RE_ENTROPY_EXHAUSTED (0x03) ([SWS_Crypto_00141], [SWS_Crypto_00194], [SWS_Crypto_91018]). If read or write accesses to the NVM fail, CRYPTO_E_RE_NVM_ACCESS_FAILED (0x04) is signaled ([SWS_Crypto_00194]). Further standardized API return values are CRYPTO_E_BUSY, CRYPTO_E_KEY_READ_FAIL, CRYPTO_E_KEY_WRITE_FAIL, CRYPTO_E_KEY_NOT_AVAILABLE, CRYPTO_E_KEY_NOT_VALID, CRYPTO_E_KEY_SIZE_MISMATCH, and CRYPTO_E_KEY_EMPTY ([SWS_Crypto_00155], [SWS_Crypto_00207], [SWS_Crypto_91018]).

Further detailed evidence

The essential properties of the Crypto Driver are based on the following functional specification requirements and architectural points:

Subject Area	Essential Specification Elements	Document Reference
Module Framework & Instantiation	[SWS_Crypto_00012], [SWS_Crypto_91000], [SWS_Crypto_91016], [SWS_Crypto_00215]	SWS_CryptoDriver S. 15
Job Processing & Cancellation	[SWS_Crypto_91003], [SWS_Crypto_00017], [SWS_Crypto_00027], [SWS_Crypto_00122], [SWS_Crypto_00183]	SWS_CryptoDriver S. 25
Key & Rights Management	[SWS_Crypto_91004], [SWS_Crypto_91006], [SWS_Crypto_00219], [SWS_Crypto_00220], [SWS_Crypto_91014]	SWS_CryptoDriver S. 28
Crypto Operations & Exchange	[SWS_Crypto_91007], [SWS_Crypto_91008], [SWS_Crypto_91009], [SWS_Crypto_91010]	SWS_CryptoServiceManager S. 70
NvM Persistence & Callbacks	[SWS_Crypto_91023], [SWS_Crypto_91024], [SWS_Crypto_91025], [SWS_Crypto_91026]	SWS_CryptoDriver S. 37
Multi-Core & Partitioning	[SWS_Crypto_CONSTR_00001], [SWS_Crypto_CONSTR_00002], [SWS_Crypto_CONSTR_00003]	BSWDistributionGuide S. 59

This guide is based exclusively on the normative provisions of the AUTOSAR Classic R20-11 specification.

Crypto Driver (Crypto)

Low-level driver executing cryptographic primitives on hardware security modules (HSM) or software libraries.

Funktionen — Übersicht

void Crypto_Init (const Crypto_ConfigType* configPtr); Initializes the Crypto Driver.
void Crypto_GetVersionInfo (Std_VersionInfoType* versioninfo); Returns the version information of this module.
Std_ReturnType Crypto_ProcessJob (uint32 objectId, Crypto_JobType* job); Service Crypto_ProcessJob.
Std_ReturnType Crypto_CancelJob (uint32 objectId, Crypto_JobType* job); This interface removes the provided job from the queue and cancels the processing of the job if possible.
Std_ReturnType Crypto_KeyElementSet (uint32 cryptoKeyId, uint32 keyElementId, const uint8* keyPtr, uint32 keyLength); Sets the given key element bytes to the key identified by crypto Key Id.
Std_ReturnType Crypto_KeySetValid (uint32 cryptoKeyId); Sets the key state of the key identified by crypto Key Id to valid.
Std_ReturnType Crypto_KeySetInvalid (uint32 cryptoKeyId); Sets invalid for the status of the key identifi ed by crypto Key Id.
Std_ReturnType Crypto_KeyElementGet (uint32 cryptoKeyId, uint32 keyElementId, uint8* resultPtr, uint32* resultLengthPtr); This interface shall be used to get a key element of the key identified by the crypto
Std_ReturnType Crypto_KeyGetStatus (uint32 cryptoKeyId, Crypto_KeyStatusType* keyStatusPtr); Returns the key state of the key identified by crypto Key Id.
Std_ReturnType Crypto_KeyElementCopy (uint32 cryptoKeyId, uint32 keyElementId, uint32 targetCryptoKeyId, uint32 targetKeyElementId); Service Crypto_KeyElementCopy.
Std_ReturnType Crypto_KeyElementCopyPartial (uint32 cryptoKeyId, uint32 keyElementId, uint32 keyElementSourceOffset, uint32 keyElementTargetOffset, uint32 keyElementCopyLength, uint32 targetCryptoKeyId, uint32 targetKeyElementId); Service Crypto_KeyElementCopyPartial.
Std_ReturnType Crypto_KeyCopy (uint32 cryptoKeyId, uint32 targetCryptoKeyId); Copies a key with all its elements to another key in the same crypto driver.
Std_ReturnType Crypto_KeyElementIdsGet (uint32 cryptoKeyId, uint32* keyElementIdsPtr, uint32* keyElementIdsLengthPtr); Used to retrieve information which key elements are available in a given key.
Std_ReturnType Crypto_RandomSeed (uint32 cryptoKeyId, const uint8* seedPtr, uint32 seedLength); This function generates the internal seed state using the pro vided entropy source.
Std_ReturnType Crypto_KeyGenerate (uint32 cryptoKeyId); Generates new key material store it in the key identified by crypto Key Id.
Std_ReturnType Crypto_KeyDerive (uint32 cryptoKeyId, uint32 targetCryptoKeyId); Derives a new key by using the key elements in the given key identified by the crypto Key Id.
Std_ReturnType Crypto_KeyExchangeCalcPubVal (uint32 cryptoKeyId, uint8* publicValuePtr, uint32* publicValueLengthPtr); Calculates the public value for the key exchange a nd stores the public key in the memory location pointed by the public value...
Std_ReturnType Crypto_KeyExchangeCalcSecret (uint32 cryptoKeyId, const uint8* partnerPublicValuePtr, uint32 partnerPublicValueLength); Calculates the shared secret key for the key exchange with the key material of the key identified by the crypto Key Id and the...
void Crypto_MainFunction (void); If asynchronous job processing is configured and there are job queues, the function is called cyclically to process queued jobs.

Typen — Übersicht

struct Crypto_ConfigType Configuration data structure of Cry If module

Funktionen & Typen — Detailansicht

function Crypto_Init [SWS_Crypto_91000] 📄 PDF

void Crypto_Init (const Crypto_ConfigType* configPtr);

Initializes the Crypto Driver.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 4040b6dde00b Provenance Open questions (2)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function Crypto_Init serves to initialize the Crypto Driver according to [SWS_Crypto_91000]. The interface is declared in the header Crypto.h and has the service ID 0x00 [SWS_Crypto_91000].

The following properties are specified for the call and interface parameters:

Configuration pointer: A pointer to the selected configuration structure is passed via the input parameter configPtr of type const Crypto_ConfigType* [SWS_Crypto_91000].
Return value: The function has no return value (void); neither input/output parameters nor separate output parameters exist [SWS_Crypto_91000].
Execution behavior: The initialization routine is executed synchronously (Synchronous) [SWS_Crypto_91000].
Reentrancy: The function is defined as non-reentrant (Non Reentrant) [SWS_Crypto_91000]. Parallel or overlapping calls are not permissible.

Due to the classification as non-reentrant and because the specification does not return any specific error codes, the call is likely to occur centrally during the startup phase of the ECU before any other driver accesses (interpretation). Question Q-008bb5a45b823891 (open) The caller is likely also responsible for ensuring that the referenced configuration structure remains permanently valid in memory (interpretation). Question Q-6271a86fad440121 (open)

This usage note was generated by an AI based on the specification AUTOSAR CP R20-11.

Implementer's Guide to follow (complexity I1)

function Crypto_GetVersionInfo [SWS_Crypto_91001] 📄 PDF

void Crypto_GetVersionInfo (Std_VersionInfoType* versioninfo);

Returns the version information of this module.

function Crypto_ProcessJob [SWS_Crypto_91003] 📄 PDF

Std_ReturnType Crypto_ProcessJob (uint32 objectId, Crypto_JobType* job);

Service Crypto_ProcessJob.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 58fc9052e1fa Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function Crypto_ProcessJob executes the cryptographic primitive configured in parameter job on the Crypto Driver Object referenced by objectId [SWS_Crypto_91003]. The call is reentrant and operates synchronously or asynchronously depending on the job configuration [SWS_Crypto_91003]. Via the pointer to Crypto_JobType, both configuration data for the primitive and buffers for the result data are passed [SWS_Crypto_91003].

Before the actual execution of a job, the driver checks the key identifiers for validity: If job->cryptoKeyId or optionally job->targetCryptoKeyId lie outside the permissible range, the function reports the error CRYPTO_E_PARAM_HANDLE to the DET and returns E_NOT_OK [SWS_Crypto_00217]. This also applies to the service CRYPTO_KEYDERIVE (job->jobPrimitiveInfo->primitiveInfo->service), provided job->targetCryptoKeyId is invalid [SWS_Crypto_00202].

In addition to E_OK and E_NOT_OK, specific error codes signal the failure of the request [SWS_Crypto_91003]:

CRYPTO_E_BUSY, if the driver object is busy or its queue is full [SWS_Crypto_91003],
key-related errors such as CRYPTO_E_KEY_NOT_VALID, CRYPTO_E_KEY_SIZE_MISMATCH, CRYPTO_E_KEY_READ_FAIL, CRYPTO_E_KEY_WRITE_FAIL, CRYPTO_E_KEY_NOT_AVAILABLE, or CRYPTO_E_KEY_EMPTY [SWS_Crypto_91003],
CRYPTO_E_JOB_CANCELED upon cancellation of a synchronous job [SWS_Crypto_91003], and
CRYPTO_E_ENTROPY_EXHAUSTED in case of insufficient entropy of a random number generator; in this case, the function additionally reports the runtime error CRYPTO_E_RE_ENTROPY_EXHAUSTED [SWS_Crypto_00141], [SWS_Crypto_91003].

This text was created by an AI based on AUTOSAR R20-11 specification data.

Implementer's Guide to follow (complexity I1)

function Crypto_CancelJob [SWS_Crypto_00122] 📄 PDF

Std_ReturnType Crypto_CancelJob (uint32 objectId, Crypto_JobType* job);

This interface removes the provided job from the queue and cancels the processing of the job if possible.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 53c6dc327c97 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The synchronous function Crypto_CancelJob removes a passed job from the queue and cancels its processing if possible [SWS_Crypto_00122]. Upon the call, the identifier of the Crypto Driver Object (objectId) and a pointer to the job configuration (job) are passed [SWS_Crypto_00122].

The return values signal the result of the cancellation attempt:

E_OK: The request was successful and the job was removed [SWS_Crypto_00122]. If there is no error in the driver and the job is currently not being processed, the service also returns E_OK without further actions [SWS_Crypto_00214].
E_NOT_OK: The request failed because the job could not be removed [SWS_Crypto_00122].
CRYPTO_E_JOB_CANCELED: The job was canceled, but continues to be executed; no results are reported back to the application [SWS_Crypto_00122]. This applies if the driver operates error-free, but cannot cancel the job (for example due to hardware limitations) [SWS_Crypto_00183].

Concurrency and Limitations

The interface is reentrant for different instances, but must not be called simultaneously for the same Crypto Driver Object [SWS_Crypto_00122].

This usage note was created automatically and is based exclusively on the specification data of AUTOSAR R20-11.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyElementSet [SWS_Crypto_91004] 📄 PDF

Std_ReturnType Crypto_KeyElementSet (uint32 cryptoKeyId, uint32 keyElementId, const uint8* keyPtr, uint32 keyLength);

Sets the given key element bytes to the key identified by crypto Key Id.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: c644721999af Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyElementSet serves to set the raw data of a specific key element for a key identified via cryptoKeyId in the crypto driver [SWS_Crypto_91004].

Parameters and Return Values

The destination key element is addressed via keyElementId, while keyPtr points to the data buffer and keyLength to its byte size [SWS_Crypto_91004]. Upon successful assignment, the interface returns E_OK [SWS_Crypto_91004].

Error handling

If an error occurs during processing, the function provides specific return values [SWS_Crypto_91004]:

CRYPTO_E_BUSY: The associated Crypto Driver Object is busy.
CRYPTO_E_KEY_WRITE_FAIL: Write access to the key element was denied.
CRYPTO_E_KEY_NOT_AVAILABLE: The requested key element or the key is not available.
CRYPTO_E_KEY_SIZE_MISMATCH: The passed data length does not match the size of the key element.
E_NOT_OK: The request failed for other reasons.

Concurrency

The function is specified as non-reentrant (Non Reentrant) [SWS_Crypto_91004]. Interpretation: Callers are likely responsible for synchronizing parallel calls against each other in order to prevent data inconsistencies in the driver. Question Q-d7ef7a774052a212 (open)

This usage note was created automatically based on the specification SWS_Crypto_91004 (R20-11).

Implementer's Guide to follow (complexity I1)

function Crypto_KeySetValid [SWS_Crypto_91014] 📄 PDF

Std_ReturnType Crypto_KeySetValid (uint32 cryptoKeyId);

Sets the key state of the key identified by crypto Key Id to valid.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 234814436706 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeySetValid serves to set the state of a key specified via the identifier cryptoKeyId to valid ([SWS_Crypto_91014]). The interface is available via the header file Crypto.h and has the service ID 0x05 ([SWS_Crypto_91014]).

The following parameters and return values are defined during usage ([SWS_Crypto_91014]):

Input parameters: Via cryptoKeyId (type uint32), the identifier of the key whose state is to be set to valid is passed ([SWS_Crypto_91014]). Additional input or output parameters do not exist ([SWS_Crypto_91014]).
Return value: A status code of type Std_ReturnType informs about the result of the request ([SWS_Crypto_91014]):
- E_OK: The request was successful ([SWS_Crypto_91014]).
- E_NOT_OK: The request failed ([SWS_Crypto_91014]).
- CRYPTO_E_BUSY: Execution failed because the responsible Crypto Driver Object is busy ([SWS_Crypto_91014]).

Regarding concurrency, the function is specified as non-reentrant (\"Non Reentrant\") ([SWS_Crypto_91014]). Interpretation: Callers are likely to have to coordinate parallel calls across tasks externally in order to avoid conflicts, and should plan to retry the call at a later time upon receiving CRYPTO_E_BUSY. Question Q-32d775a9e61e5731 (open)

This text was created by an AI and is based on the AUTOSAR R20-11 specification status.

Implementer's Guide to follow (complexity I1)

function Crypto_KeySetInvalid [SWS_Crypto_91020] 📄 PDF

Std_ReturnType Crypto_KeySetInvalid (uint32 cryptoKeyId);

Sets invalid for the status of the key identifi ed by crypto Key Id.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: f9c09a4552e9 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Semantics

The synchronous function Crypto_KeySetInvalid sets the status of a key identified by cryptoKeyId to invalid [SWS_Crypto_91020]. The function is defined in the header file Crypto.h and is addressed via the service ID 0x15 [SWS_Crypto_91020]. The input value cryptoKeyId (type uint32), which contains the unique identifier of the target key, serves as the only passed parameter; input/output and output parameters do not exist [SWS_Crypto_91020].

Error Handling and Return Values

The result of the function execution is signaled via the return value of type Std_ReturnType [SWS_Crypto_91020]:

E_OK: The request was successful and the key status was set to invalid [SWS_Crypto_91020].
E_NOT_OK: Execution of the request failed [SWS_Crypto_91020].
CRYPTO_E_BUSY: The request failed because the responsible crypto driver object (Crypto Driver Object) is currently busy [SWS_Crypto_91020].

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) [SWS_Crypto_91020]. A concurrent or interrupting call is therefore not permitted. Because the function is executed synchronously, it returns to the caller only after completion of the status change or after determination of the error [SWS_Crypto_91020].

This usage note was generated automatically based on the specification.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyElementGet [SWS_Crypto_91006] 📄 PDF

Std_ReturnType Crypto_KeyElementGet (uint32 cryptoKeyId, uint32 keyElementId, uint8* resultPtr, uint32* resultLengthPtr);

This interface shall be used to get a key element of the key identified by the crypto

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: c68d666a4fd9 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous and reentrant function Crypto_KeyElementGet serves to read a key element identified by keyElementId from the key cryptoKeyId and store it in the memory area resultPtr [SWS_Crypto_91006]. The interface is provided via the header Crypto.h and has the service ID 0x06 [SWS_Crypto_91006]. Upon the call, the caller passes the buffer size or, in the case of configured partial access, the desired read size via the in-out parameter resultLengthPtr; after completion of execution, the driver stores the actually copied amount of data there [SWS_Crypto_91006].

In case of success, the function returns E_OK [SWS_Crypto_91006]. If the operation fails, it signals this via specific error codes: CRYPTO_E_BUSY if the crypto driver object is busy, CRYPTO_E_KEY_NOT_AVAILABLE if the key element is not available, CRYPTO_E_KEY_READ_FAIL if read access is denied, CRYPTO_E_KEY_EMPTY for an uninitialized source element, as well as generically E_NOT_OK [SWS_Crypto_91006].

Although the interface is specified as reentrant, the specification points out that noticeable latencies can occur during synchronous execution if the key element is directly mapped into the flash memory [SWS_Crypto_91006]. Interpretation: Due to these potential delays, calling primarily in the task context and not within time-critical interrupt service routines is likely to be appropriate. Question Q-ff4e2843b9aad46d (open)

This usage note was generated automatically and is based on the specification status of AUTOSAR Classic R20-11.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyGetStatus [SWS_Crypto_91019] 📄 PDF

Std_ReturnType Crypto_KeyGetStatus (uint32 cryptoKeyId, Crypto_KeyStatusType* keyStatusPtr);

Returns the key state of the key identified by crypto Key Id.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 4f6e929a170d Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyGetStatus serves to query the current state of a specific key within the crypto driver [SWS_Crypto_91019]. It is provided via the header Crypto.h and carries the service ID 0x14 [SWS_Crypto_91019].

Usage and Parameters

The call is synchronous and expects two parameters [SWS_Crypto_91019]:

cryptoKeyId: The identifier of the key whose status is to be determined.
keyStatusPtr: Pointer to the memory area of type Crypto_KeyStatusType to which the state is returned.

The interface returns Std_ReturnType as the return value. Upon successful execution, E_OK is reported, whereas in case of error, E_NOT_OK is returned [SWS_Crypto_91019].

Concurrency and Limitations

The function is declared as non-reentrant (Non Reentrant) [SWS_Crypto_91019]. Callers must therefore ensure that concurrent calls are avoided by higher-level synchronization mechanisms. Specific DET error messages are not listed; presumably, an erroneous call such as an invalid pointer or an invalid ID directly leads to the return of E_NOT_OK [SWS_Crypto_91019]. Question Q-5703fab02905e91a (open)

This text was created by an AI and is based on the specification of AUTOSAR R20-11.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyElementCopy [SWS_Crypto_00148] 📄 PDF

Std_ReturnType Crypto_KeyElementCopy (uint32 cryptoKeyId, uint32 keyElementId, uint32 targetCryptoKeyId, uint32 targetKeyElementId);

Service Crypto_KeyElementCopy.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 0bf976054e55 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyElementCopy serves to copy a key element to another key element within the same crypto driver [SWS_Crypto_00148]. The identifiers of the source key (cryptoKeyId) and the source key element (keyElementId) as well as the destination key (targetCryptoKeyId) and the destination key element (targetKeyElementId) are passed [SWS_Crypto_00148].

Regarding timing behavior, it should be noted that for key elements mapped directly in flash memory, greater delays may occur during the function call due to synchronous execution [SWS_Crypto_00148]. The runtime behavior must therefore be taken into account, especially in time-critical contexts.

The function is designed to be reentrant, but explicitly not for the same cryptoKeyId [SWS_Crypto_00148]. Simultaneous calls with an identical source key must consequently be synchronized or precluded by the caller.

In case of success, the function returns E_OK [SWS_Crypto_00148]. In case of errors, the return value signals the specific cause [SWS_Crypto_00148]:

CRYPTO_E_BUSY: The crypto driver object is busy [SWS_Crypto_00148].
CRYPTO_E_KEY_NOT_AVAILABLE: The requested key element of at least one key is not available [SWS_Crypto_00148].
CRYPTO_E_KEY_READ_FAIL or CRYPTO_E_KEY_WRITE_FAIL: Reading the source element or writing the destination element is not permitted [SWS_Crypto_00148].
CRYPTO_E_KEY_SIZE_MISMATCH: The sizes of the key elements are not compatible with each other [SWS_Crypto_00148].
CRYPTO_E_KEY_EMPTY: The source key element is not initialized [SWS_Crypto_00148].
E_NOT_OK: The request failed generally [SWS_Crypto_00148].

This usage note was generated automatically based on the specification of AUTOSAR Classic R20-11.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyElementCopyPartial [SWS_Crypto_91015] 📄 PDF

Std_ReturnType Crypto_KeyElementCopyPartial (uint32 cryptoKeyId, uint32 keyElementId, uint32 keyElementSourceOffset, uint32 keyElementTargetOffset, uint32 keyElementCopyLength, uint32 targetCryptoKeyId, uint32 targetKeyElementId);

Service Crypto_KeyElementCopyPartial.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: a5ad7cce8b26 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyElementCopyPartial serves for the partial copying of data from a source key element to a target key element within the same crypto driver [SWS_Crypto_91015]. The parameters keyElementSourceOffset and keyElementCopyLength define the segment of the source element to be copied (cryptoKeyId, keyElementId), while keyElementTargetOffset determines the starting position in the target element (targetCryptoKeyId, targetKeyElementId). If checks are error-free, the driver performs the copying synchronously and returns E_OK [SWS_Crypto_00209].

Prior to execution, the driver validates the buffer and driver states:

If the crypto driver is not initialized and development error detection is enabled, the function reports CRYPTO_E_UNINIT to the DET and returns E_NOT_OK [SWS_Crypto_00205].
If the total length of the source key element is less than keyElementSourceOffset + keyElementCopyLength, the call fails with CRYPTO_E_KEY_SIZE_MISMATCH [SWS_Crypto_00207].
If the maximum buffer of the target key element provides less space than keyElementTargetOffset + keyElementCopyLength, CRYPTO_E_KEY_SIZE_MISMATCH is likewise reported [SWS_Crypto_00208].
Other specified error values include CRYPTO_E_BUSY (driver object busy), CRYPTO_E_KEY_EMPTY (uninitialized source element), CRYPTO_E_KEY_NOT_AVAILABLE, and read or write access errors (CRYPTO_E_KEY_READ_FAIL, CRYPTO_E_KEY_WRITE_FAIL) [SWS_Crypto_91015].

The function is reentrant, but must not be called simultaneously for the same key ID cryptoKeyId [SWS_Crypto_91015]. If a key element is stored directly in flash memory, the synchronous execution can lead to noticeable time delays [SWS_Crypto_91015].

This usage note was generated automatically based on the AUTOSAR specification R20-11.

Implementer's Guide to follow (complexity I2)

function Crypto_KeyCopy [SWS_Crypto_00155] 📄 PDF

Std_ReturnType Crypto_KeyCopy (uint32 cryptoKeyId, uint32 targetCryptoKeyId);

Copies a key with all its elements to another key in the same crypto driver. Note: If the actual key element is directly mapped to flash memory, there could be a bigger delay when calling this function (synchronous operation)

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 4fed74be6625 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The synchronous function Crypto_KeyCopy copies a key together with all its key elements to a target key within the same crypto driver [SWS_Crypto_00155]. The assignment takes place via the input parameters cryptoKeyId for the source key and targetCryptoKeyId for the target key [SWS_Crypto_00155]. A successful copy operation is confirmed with E_OK [SWS_Crypto_00155].

Concurrency and Runtime Behavior

The interface is designed to be reentrant, but must not be executed at the same time for the same cryptoKeyId [SWS_Crypto_00155]. Since execution is synchronous, noticeable time delays can occur during the call for key elements stored directly in flash memory [SWS_Crypto_00155].

Error handling

In case of an error, the function returns specific return values of type Std_ReturnType [SWS_Crypto_00155]:

CRYPTO_E_BUSY: The associated Crypto Driver Object is busy [SWS_Crypto_00155].
CRYPTO_E_KEY_NOT_AVAILABLE: At least one of the requested keys is not available [SWS_Crypto_00155].
CRYPTO_E_KEY_READ_FAIL: Reading the source key element is not permitted [SWS_Crypto_00155].
CRYPTO_E_KEY_WRITE_FAIL: Writing to the target key element is not permitted [SWS_Crypto_00155].
CRYPTO_E_KEY_SIZE_MISMATCH: The sizes of the key elements are not compatible with each other [SWS_Crypto_00155].
CRYPTO_E_KEY_EMPTY: The key element of the source key is not initialized [SWS_Crypto_00155].
E_NOT_OK: Execution of the request failed [SWS_Crypto_00155].

This usage note was generated by an AI based on the AUTOSAR CP R20-11 specification.

function Crypto_KeyElementIdsGet [SWS_Crypto_00160] 📄 PDF

Std_ReturnType Crypto_KeyElementIdsGet (uint32 cryptoKeyId, uint32* keyElementIdsPtr, uint32* keyElementIdsLengthPtr);

Used to retrieve information which key elements are available in a given key.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 73fbfa8804b7 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyElementIdsGet serves to query information about which key elements are available in a given key [SWS_Crypto_00160]. The identifier of the key whose available element IDs are to be exported is passed via the input parameter cryptoKeyId [SWS_Crypto_00160]. The determined identifiers are stored in the array referenced by the pointer keyElementIdsPtr [SWS_Crypto_00160].

The buffer size is managed via the input and output parameter keyElementIdsLengthPtr: Upon the call, this parameter must contain the provided size of the buffer keyElementIdsPtr [SWS_Crypto_00160]. After completion of the operation, the actual number of available key elements is stored there [SWS_Crypto_00160].

As a return value, the service provides E_OK upon a successful query, or E_NOT_OK if the request failed [SWS_Crypto_00160]. If the responsible crypto driver object is busy at the time of the call, the error code CRYPTO_E_BUSY is returned [SWS_Crypto_00160].

Regarding concurrency, the function is reentrant, but must not be called simultaneously for the same cryptoKeyId [SWS_Crypto_00160]. The declaration is available via the header Crypto.h [SWS_Crypto_00160].

This text was generated by an AI based on the AUTOSAR specification.

Implementer's Guide to follow (complexity I1)

function Crypto_RandomSeed [SWS_Crypto_91013] 📄 PDF

Std_ReturnType Crypto_RandomSeed (uint32 cryptoKeyId, const uint8* seedPtr, uint32 seedLength);

This function generates the internal seed state using the pro vided entropy source. Furthermore, this function can be used to update the seed state with new entropy

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 7ee33749b38a Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_RandomSeed (service ID 0x0d) serves according to [SWS_Crypto_91013] for the generation and update of the internal seed state of a key using a provided entropy source. The function declaration is contained in the header file Crypto.h.

Usage and Call Parameters

In addition to the initial generation, according to [SWS_Crypto_91013] the function can also be used to update the seed state with new entropy. The synchronous call requires three input parameters:

cryptoKeyId: Passes the identifier of the key for which a new seed is to be generated.
seedPtr: Holds a pointer to the memory area containing the data for feeding the seed.
seedLength: Defines the length of the passed seed data in bytes.

Return Values and Error Handling

As a return value, Crypto_RandomSeed reports a status of type Std_ReturnType according to [SWS_Crypto_91013]:

E_OK: The request was executed successfully.
E_NOT_OK: The request has failed.
CRYPTO_E_KEY_NOT_VALID: Execution fails because the key state of the key identified by cryptoKeyId is in the status "invalid".

Concurrency and Limitations

According to [SWS_Crypto_91013], the function is specified as reentrant, but explicitly not for the same cryptoKeyId. Parallel calls for the same key must therefore be prevented on the caller side.

This text was generated by an AI and is based exclusively on the specification data from the payload.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyGenerate [SWS_Crypto_91007] 📄 PDF

Std_ReturnType Crypto_KeyGenerate (uint32 cryptoKeyId);

Generates new key material store it in the key identified by crypto Key Id.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 9465afa4791c Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The function Crypto_KeyGenerate provided via the header file Crypto.h generates new key material and updates the key addressed via the identifier cryptoKeyId [SWS_Crypto_91007]. The function operates completely synchronously and is defined under the service ID 0x07 [SWS_Crypto_91007]. Other parameters besides the key identifier do not exist [SWS_Crypto_91007].

Concurrency and Limitations

With regard to concurrency, Crypto_KeyGenerate is specified as reentrant, but expressly with the restriction that this does not apply to the same cryptoKeyId [SWS_Crypto_91007]. If multiple requests are made for the same key, these must be synchronized on the caller side to avoid driver conflicts.

Return Values and Error Handling

Via the return value of base type Std_ReturnType, the caller receives detailed feedback on success or specific error causes of the operation [SWS_Crypto_91007]:

E_OK: Key generation was executed successfully [SWS_Crypto_91007].
CRYPTO_E_BUSY: The request failed because the responsible Crypto Driver Object is currently busy [SWS_Crypto_91007].
CRYPTO_E_KEY_EMPTY: Generation failed because a required source key element is uninitialized [SWS_Crypto_91007].
CRYPTO_E_KEY_NOT_VALID: The operation failed because the key state of the key referenced by cryptoKeyId is marked as invalid [SWS_Crypto_91007].
E_NOT_OK: The request for key generation failed for other reasons [SWS_Crypto_91007].

This usage note was generated automatically based on the specification of AUTOSAR Classic R20-11.

function Crypto_KeyDerive [SWS_Crypto_91008] 📄 PDF

Std_ReturnType Crypto_KeyDerive (uint32 cryptoKeyId, uint32 targetCryptoKeyId);

Derives a new key by using the key elements in the given key identified by the crypto Key Id. The given key contains the key elements for the password, salt. The derived key is stored in the key element with the id 1 of the key identified by target Crypto Key Id. The number of iterations is given in the key element CRYPTO_ KE_ KEYDERIVATION_ ITERATIONS.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 5847568b736a Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyDerive derives a new cryptographic key from the key elements of a source key (cryptoKeyId) and stores it in the key element with ID 1 of the destination key (targetCryptoKeyId) [SWS_Crypto_91008]. The source key must contain the required key elements for password and salt; the number of iterations is specified via the key element CRYPTO_KE_KEYDERIVATION_ITERATIONS [SWS_Crypto_91008].

Invocation and Concurrency

The interface is reentrant, but must not be called simultaneously for the same cryptoKeyId [SWS_Crypto_91008]. Callers must therefore ensure that parallel derivation processes operate on different source keys.

Return Values and Error Handling

The function signals the result via defined return values of type Std_ReturnType [SWS_Crypto_91008]:

E_OK: Key derivation successfully performed.
E_NOT_OK: Derivation failed. If the parameter targetCryptoKeyId is outside the valid range, the function also reports CRYPTO_E_PARAM_HANDLE to the DET when development error detection is activated [SWS_Crypto_00180].
CRYPTO_E_BUSY: The responsible crypto driver object is busy [SWS_Crypto_91008].
CRYPTO_E_KEY_EMPTY: A required source key element is not initialized [SWS_Crypto_91008].
CRYPTO_E_KEY_NOT_VALID: The state of the key referenced by cryptoKeyId is invalid [SWS_Crypto_91008].

This usage note was generated automatically based on the specification.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyExchangeCalcPubVal [SWS_Crypto_91009] 📄 PDF

Std_ReturnType Crypto_KeyExchangeCalcPubVal (uint32 cryptoKeyId, uint8* publicValuePtr, uint32* publicValueLengthPtr);

Calculates the public value for the key exchange a nd stores the public key in the memory location pointed by the public value pointer.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: c27ddd0a9e75 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The synchronous function Crypto_KeyExchangeCalcPubVal calculates the public value for a key exchange protocol and stores it at the memory location of publicValuePtr ([SWS_Crypto_91009]). The caller passes the identifier of the key to be used for the protocol via cryptoKeyId. The buffer size of the provided memory must be passed upon the call via the input and output parameter publicValueLengthPtr; after completion of execution, the actual length of the calculated public value is stored there ([SWS_Crypto_91009]).

Error Handling and Return Values

The function returns E_OK upon successful execution. If an error occurs, E_NOT_OK or a specific error code is returned ([SWS_Crypto_91009]):

CRYPTO_E_BUSY: The request fails because the Crypto Driver Object is busy.
CRYPTO_E_KEY_EMPTY: The request fails because the source key element is not initialized.
CRYPTO_E_KEY_NOT_VALID: The request fails because the status of the key referenced via cryptoKeyId is invalid.

Concurrency and system integration

According to [SWS_Crypto_91009], the function is reentrant, but not for the same cryptoKeyId. If the crypto driver requires services of a random number generator (RNG) for internal purposes such as Crypto_KeyExchangeCalcPubVal, the first Crypto Driver Object (object number 0) must be configured for this purpose ([SWS_Crypto_00224]).

This text was generated by an AI. All information is based on the specification AUTOSAR Classic R20-11.

Implementer's Guide to follow (complexity I1)

function Crypto_KeyExchangeCalcSecret [SWS_Crypto_91010] 📄 PDF

Std_ReturnType Crypto_KeyExchangeCalcSecret (uint32 cryptoKeyId, const uint8* partnerPublicValuePtr, uint32 partnerPublicValueLength);

Calculates the shared secret key for the key exchange with the key material of the key identified by the crypto Key Id and the partner public key. The shared secret key is stored as a key element in the same key.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: c3912e0f8927 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function Crypto_KeyExchangeCalcSecret serves to calculate a shared secret (shared secret key) for a key exchange protocol [SWS_Crypto_91010]. It processes the key material of the key specified via cryptoKeyId together with the partner's public value passed via partnerPublicValuePtr, whose byte count is specified via partnerPublicValueLength [SWS_Crypto_91010]. The calculated shared secret is stored directly as a key element within the same key [SWS_Crypto_91010].

As a return value, the function provides the status via Std_ReturnType [SWS_Crypto_91010]:

E_OK: The calculation and storage of the secret were completed successfully [SWS_Crypto_91010].
E_NOT_OK: The request has failed [SWS_Crypto_91010].
CRYPTO_E_BUSY: Execution failed because the responsible Crypto Driver Object is busy [SWS_Crypto_91010].
CRYPTO_E_KEY_EMPTY: The source key element is uninitialized [SWS_Crypto_91010].
CRYPTO_E_KEY_NOT_VALID: The state of the key referenced by cryptoKeyId is invalid [SWS_Crypto_91010].

The interface is implemented as reentrant, but must not be called concurrently for the same cryptoKeyId [SWS_Crypto_91010]. Callers must therefore ensure that concurrent calls with an identical key ID are avoided and that the referenced key material is initialized beforehand and in a valid state to prevent error states [SWS_Crypto_91010].

This usage note was generated automatically based on the specification of SWS_Crypto_91010.

function Crypto_MainFunction [SWS_Crypto_91012] 📄 PDF

void Crypto_MainFunction (void);

If asynchronous job processing is configured and there are job queues, the function is called cyclically to process queued jobs. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_CryptoDriver

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 0801a980dea9 Provenance Open questions (3)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function Crypto_MainFunction serves for the cyclic processing of queued cryptographic jobs in the job queues of the crypto driver [SWS_Crypto_91012]. A prerequisite for its use is that asynchronous job processing has been configured in the module and corresponding job queues are present [SWS_Crypto_91012].

Call and Semantics

The function has the signature void Crypto_MainFunction(void) and is specified with the service ID 0x0c [SWS_Crypto_91012]. It takes no input parameters and returns no return value. The interface is provided via the header SchM_Crypto.h [SWS_Crypto_91012]. This allows the interpretation that the cyclic call is triggered as scheduled by the BSW Scheduler (Schedule Manager) in the context of a periodic task of the operating system.

Concurrency and Limitations

The call is strictly bound to the configuration of asynchronous job queues [SWS_Crypto_91012]. Since the specification does not indicate reentrancy for Crypto_MainFunction, the function is likely to be treated as non-reentrant; parallel calls from multiple threads or tasks should therefore be avoided. Question Q-038d384305c8c5c3 (open)

Error handling

No specific error codes or DET entries are recorded in the specification for this function [SWS_Crypto_91012]. Since the function provides no return values, any errors during asynchronous processing are presumably passed to higher layers via status queries or via the feedback channels of the respective jobs. Question (open)

This usage note was generated by an AI based on the specification AUTOSAR CP R20-11.

type Crypto_ConfigType [SWS_Crypto_91016] 📄 PDF

Configuration data structure of Cry If module

Request a governed re-review of this record. The record is not changed immediately.

Record: AUTOSAR/AP/record/CP_MOD_Crypto
Status: unspecified
Version: AUTOSAR/AP/record/CP_MOD_Crypto@rel:R20-11#d5886321
Content hash: d5886321
Source: https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_CryptoDriver.pdf#nameddest=SWS_Crypto_91000

Topic map

Detail view

Select an entry in the outline.

No element data available for this release

Initialization and status

Crypto_GetVersionInfo function

Returns the version information of this module.

void Crypto_GetVersionInfo (Std_VersionInfoType* versioninfo);

Crypto_Init function

Initializes the Crypto Driver.

void Crypto_Init (const Crypto_ConfigType* configPtr);

Services · `KeyElement…`

Crypto_KeyElementCopy function

Service Crypto_KeyElementCopy.

Std_ReturnType Crypto_KeyElementCopy (uint32 cryptoKeyId, uint32 keyElementId, uint32 targetCryptoKeyId, uint32 targetKeyElementId);

Crypto_KeyElementCopyPartial function

Service Crypto_KeyElementCopyPartial.

Std_ReturnType Crypto_KeyElementCopyPartial (uint32 cryptoKeyId, uint32 keyElementId, uint32 keyElementSourceOffset, uint32 keyElementTargetOffset, uint32 keyElementCopyLength, uint32 targetCryptoKeyId, uint32 targetKeyElementId);

Crypto_KeyElementGet function

This interface shall be used to get a key element of the key identified by the crypto

Std_ReturnType Crypto_KeyElementGet (uint32 cryptoKeyId, uint32 keyElementId, uint8* resultPtr, uint32* resultLengthPtr);

Crypto_KeyElementIdsGet function

Used to retrieve information which key elements are available in a given key.

Std_ReturnType Crypto_KeyElementIdsGet (uint32 cryptoKeyId, uint32* keyElementIdsPtr, uint32* keyElementIdsLengthPtr);

Crypto_KeyElementSet function

Sets the given key element bytes to the key identified by crypto Key Id.

Std_ReturnType Crypto_KeyElementSet (uint32 cryptoKeyId, uint32 keyElementId, const uint8* keyPtr, uint32 keyLength);

Services · `Key…`

Crypto_KeyCopy function

Std_ReturnType Crypto_KeyCopy (uint32 cryptoKeyId, uint32 targetCryptoKeyId);

Crypto_KeyDerive function

Std_ReturnType Crypto_KeyDerive (uint32 cryptoKeyId, uint32 targetCryptoKeyId);

Crypto_KeyExchangeCalcPubVal function

Calculates the public value for the key exchange a nd stores the public key in the memory location pointed by the public value pointer.

Std_ReturnType Crypto_KeyExchangeCalcPubVal (uint32 cryptoKeyId, uint8* publicValuePtr, uint32* publicValueLengthPtr);

Crypto_KeyExchangeCalcSecret function

Std_ReturnType Crypto_KeyExchangeCalcSecret (uint32 cryptoKeyId, const uint8* partnerPublicValuePtr, uint32 partnerPublicValueLength);

Crypto_KeyGenerate function

Generates new key material store it in the key identified by crypto Key Id.

Std_ReturnType Crypto_KeyGenerate (uint32 cryptoKeyId);

Crypto_KeyGetStatus function

Returns the key state of the key identified by crypto Key Id.

Std_ReturnType Crypto_KeyGetStatus (uint32 cryptoKeyId, Crypto_KeyStatusType* keyStatusPtr);

Crypto_KeySetInvalid function

Sets invalid for the status of the key identifi ed by crypto Key Id.

Std_ReturnType Crypto_KeySetInvalid (uint32 cryptoKeyId);

Crypto_KeySetValid function

Sets the key state of the key identified by crypto Key Id to valid.

Std_ReturnType Crypto_KeySetValid (uint32 cryptoKeyId);

Services · More

Crypto_CancelJob function

This interface removes the provided job from the queue and cancels the processing of the job if possible.

Std_ReturnType Crypto_CancelJob (uint32 objectId, Crypto_JobType* job);

Crypto_ProcessJob function

Service Crypto_ProcessJob.

Std_ReturnType Crypto_ProcessJob (uint32 objectId, Crypto_JobType* job);

Crypto_RandomSeed function

This function generates the internal seed state using the pro vided entropy source. Furthermore, this function can be used to update the seed state with new entropy

Std_ReturnType Crypto_RandomSeed (uint32 cryptoKeyId, const uint8* seedPtr, uint32 seedLength);

Cyclic

Crypto_MainFunction function

If asynchronous job processing is configured and there are job queues, the function is called cyclically to process queued jobs. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_CryptoDriver

void Crypto_MainFunction (void);

Types

Crypto_ConfigType type

Configuration data structure of Cry If module

Click an entry to see its relations.

Crypto Driver (Crypto)

Module guideAI-GENERATED

Role and System Boundaries of the Crypto Driver in the Classic Crypto Stack

Management of Crypto Driver Objects and Hardware Abstraction

Job Processing Between Synchronous Direct Call and Asynchronous Streaming

Key Management, Access Rights, and Cryptographic Key Operations

Persistence of Key Elements via the Non-Volatile RAM Manager

Partitioning and Multi-Core Operating Rules

Behavior in the event of an error

Further detailed evidence

Crypto Driver (Crypto)

Funktionen — Übersicht

Typen — Übersicht

Funktionen & Typen — Detailansicht

function Crypto_Init [SWS_Crypto_91000] 📄 PDF

function Crypto_GetVersionInfo [SWS_Crypto_91001] 📄 PDF

function Crypto_ProcessJob [SWS_Crypto_91003] 📄 PDF

function Crypto_CancelJob [SWS_Crypto_00122] 📄 PDF

use

Concurrency and Limitations

function Crypto_KeyElementSet [SWS_Crypto_91004] 📄 PDF

Parameters and Return Values

Error handling

Concurrency

function Crypto_KeySetValid [SWS_Crypto_91014] 📄 PDF

function Crypto_KeySetInvalid [SWS_Crypto_91020] 📄 PDF

Usage and Semantics

Error Handling and Return Values

Concurrency and Limitations

function Crypto_KeyElementGet [SWS_Crypto_91006] 📄 PDF

function Crypto_KeyGetStatus [SWS_Crypto_91019] 📄 PDF

Usage and Parameters

Concurrency and Limitations

function Crypto_KeyElementCopy [SWS_Crypto_00148] 📄 PDF

function Crypto_KeyElementCopyPartial [SWS_Crypto_91015] 📄 PDF

function Crypto_KeyCopy [SWS_Crypto_00155] 📄 PDF

use

Concurrency and Runtime Behavior

Error handling

function Crypto_KeyElementIdsGet [SWS_Crypto_00160] 📄 PDF

function Crypto_RandomSeed [SWS_Crypto_91013] 📄 PDF

Usage and Call Parameters

Return Values and Error Handling

Concurrency and Limitations

function Crypto_KeyGenerate [SWS_Crypto_91007] 📄 PDF

use

Concurrency and Limitations

Return Values and Error Handling

function Crypto_KeyDerive [SWS_Crypto_91008] 📄 PDF

Invocation and Concurrency

Return Values and Error Handling

function Crypto_KeyExchangeCalcPubVal [SWS_Crypto_91009] 📄 PDF

use

Error Handling and Return Values

Concurrency and system integration

function Crypto_KeyExchangeCalcSecret [SWS_Crypto_91010] 📄 PDF

function Crypto_MainFunction [SWS_Crypto_91012] 📄 PDF

Call and Semantics

Concurrency and Limitations

Error handling

type Crypto_ConfigType [SWS_Crypto_91016] 📄 PDF

Topic map

Initialization and status

Services · KeyElement…

Services · Key…

Services · More

Cyclic

Types

Detail view

Initialization and status

Services · KeyElement…

Services · Key…

Services · More

Cyclic

Types

Services · `KeyElement…`

Services · `Key…`

Services · `KeyElement…`

Services · `Key…`