module ara::crypto — Cryptography

The functional cluster Cryptography provides standardized security services for symmetric and asymmetric encryption, signature verification, and secure key and certificate management (PlatformDesign p. 71). Access to cryptographic operations and persistent key slots is strictly isolated via platform-specific providers and instance specifiers defined declaratively in the manifest (SWS Cryptography p. 39). In doing so, enforcing usage restrictions prevents compromise of the sensitive key material ([SWS_CRYPT_50092]).

more ›

The functional cluster Cryptography (ara::crypto) provides a comprehensive security architecture for the AUTOSAR Adaptive Platform (PlatformDesign p. 71). To safeguard against compromised user applications, key storage and cryptographic execution are typically encapsulated in an isolated platform daemon or Hardware Security Module (HSM) (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87). The overall functionality is divided into specialized CryptoProvider for computation primitives, the key storage area for persistent key slots (KeySlots), and a machine-wide X509Provider for PKI certificate management (SWS Cryptography p. 39).

Context diagram: Architecture and component relationships of the functional cluster Cryptography between application, daemon, and providers. Sources: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Applications create cryptographic contexts such as symmetric ciphers ([SWS_CRYPT_20742]), authenticated ciphers ([SWS_CRYPT_20745]), hash functions ([SWS_CRYPT_20747]), or signer and verifier instances ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) via their provider (AUTOSAR AP EXP SWArchitecture p. 99). Processing follows a deterministic lifecycle: following key binding (SetKey), the transformation is initiated via Start(), streamed via Update(), and completed with Finish() (AUTOSAR AP TR SystemTests p. 206, EXP SWArchitecture p. 104). Immutable AllowedUsageFlags effectively prevent unauthorized key usage ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests p. 177).

State diagram: Lifecycle of cryptographic transformation contexts from allocation to reset. Sources: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Certificates and CSRs are managed via the X509Provider ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), while validation contexts verify certificate chains taking into account CRL revocation lists ([SWS_CRYPT_50183]) and OCSP responses ([SWS_CRYPT_50124]) (AUTOSAR AP TR SystemTests p. 194). The assignment of KeySlots and certificates to applications is performed model-based in the manifest via InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification p. 245, AUTOSAR AP TPS ManifestSpecification p. 649). All interfaces operate with exceptionless ara::core::Result returns and signal errors via the CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography p. 208).

more ›

Architecture, Security Domains, and Daemon Isolation

The functional cluster Cryptography (ara::crypto) forms the central security foundation of the AUTOSAR Adaptive Platform and provides cryptographic base mechanisms, key management, and certificate services (PlatformDesign p. 71). According to the trust model of the platform, functional platform clusters belong to the trusted foundation, whereas Adaptive Applications are executed in unprivileged user space (SWS Cryptography p. 37). In order to effectively protect key material and cryptographic operations even in the event of a potential compromise of an application, the architecture is typically daemon-based; the actual execution and key storage remain in an isolated platform process or in a secure execution environment (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87).

The architecture divides the cryptographic functionality into three primary domains: the CryptoProvider for computation primitives and key transformations, the key storage area (ara::crypto::keys) for persistent object storage, and the X509Provider (ara::crypto::x509) for certificate management (SWS Cryptography p. 39, SWS Cryptography p. 87). On an ECU, multiple specialized instances of CryptoProvider can exist concurrently, for example to connect different Hardware Security Modules (HSM, TPM) or software-based drivers (SWS Cryptography p. 39). However, there is deliberately no interoperability between different providers: a cryptographic object or key belongs strictly to one provider and cannot be processed by another provider (SWS Cryptography p. 39). This strict encapsulation is likely primarily attributable to hardware security domains physically enforcing their key boundaries and key handles not being valid across domains. Question Q-63efe107cf111983 (open)

Context diagram: Architecture and component relationships of the functional cluster Cryptography between application, daemon, and providers. Sources: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Entry Points and Initialization of Cryptographic Providers

Entry into the module occurs via global entry-point functions that serve as factories for the central abstraction interfaces (SWArchitecture p. 71). Applications create or load an instance of a CryptoProvider via the function [SWS_CRYPT_20099], specifying a modeled ara::core::InstanceSpecifier. For certificate management, exactly one global certificate provider exists in the overall system, which is loaded via [SWS_CRYPT_40099] (SWS Cryptography p. 39). In addition, global helper services are available, including direct generation of random data via [SWS_CRYPT_30098] and querying a hardware-backed security counter via [SWS_CRYPT_20098] (SWArchitecture p. 71).

Persistent key resources are not instantiated directly, but are loaded via logical key slots (KeySlots). For this purpose, the runtime environment provides the functions [SWS_CRYPT_50004] for read-only access and [SWS_CRYPT_50005] for writable key slots, which validate the passed instance identifier against the permission configuration (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649). Via an obtained KeySlot instance, the assigned provider instance can be queried using [SWS_CRYPT_30403], thereby ensuring the tight binding between storage location and execution environment is maintained (SWS Cryptography p. 39).

As soon as a CryptoProvider instance is available, it functions as a central factory for instantiating specific cryptographic working contexts (AUTOSAR AP EXP SWArchitecture p. 99). The contexts that can be created include, among others, contexts for random number generators ([SWS_CRYPT_20741]), symmetric block and stream ciphers ([SWS_CRYPT_20742]), authenticated encryption ([SWS_CRYPT_20745]), message authentication codes ([SWS_CRYPT_20746]), cryptographic hash functions ([SWS_CRYPT_20747]), asymmetric encryption and decryption ([SWS_CRYPT_20750], [SWS_CRYPT_20751]), as well as signature and verification contexts ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture p. 99).

Cryptographic Transformation Contexts and Data Processing

The processing of cryptographic data in ara::crypto follows a strictly state-based lifecycle that ensures the decoupling of algorithm configuration, key binding, and streaming processing (AUTOSAR AP TR SystemTests p. 211). After allocation of the context via the provider, it is initially in the uninitialized state. Only by passing a compatible key via the type-specific overloads of SetKey()—such as for symmetric keys ([SWS_CRYPT_23911]), private keys ([SWS_CRYPT_23515]), or directly from a KeySlot ([SWS_CRYPT_50043])—does the context transition into the ready state (AUTOSAR AP TR SystemTests p. 206).

For streaming operations, the transformation is initiated by Start(), optionally passing an initialization vector or context ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). Subsequently, data blocks can be fed in incrementally via Update() ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). For authenticated encryption (AEAD), the interface strictly separates associated data, which is processed via [SWS_CRYPT_20313], from confidential payload data via [SWS_CRYPT_50074] (EXP SWArchitecture p. 104). A transformation is concluded via Finish() or FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), whereupon authentication tags or checksums can be retrieved via GetDigest() ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

In addition to the streaming mode, context classes such as symmetric ciphers and authenticated ciphers support compact one-shot invocations via [SWS_CRYPT_50047] or [SWS_CRYPT_50078], allowing short payloads to be efficiently encrypted or decrypted without a multi-stage protocol call (SWS Cryptography p. 58). If an ongoing operation is to be aborted, a call to Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) or Reset() ([SWS_CRYPT_50212]) deterministically transitions the context back into the cleared initial state (EXP SWArchitecture p. 100).

State diagram: Lifecycle of cryptographic transformation contexts from allocation to reset. Sources: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Key Management, Encapsulation, and Permission Enforcement

Cryptographic keys are typed in the object model as CryptoObject or RestrictedUseObject (AUTOSAR AP EXP SWArchitecture p. 111, EXP SWArchitecture p. 111). The platform standard distinguishes between symmetric keys (SymmetricKey), private asymmetric keys (PrivateKey), and public keys (PublicKey) (SWS Cryptography p. 291). Key material can be generated directly via the CryptoProvider ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) or derived from existing key material by parameterizing a KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) with a base key and executing it via [SWS_CRYPT_21515] (EXP SWArchitecture p. 108).

To enforce the principle of least privilege, each key object carries immutable usage restrictions (AllowedUsageFlags) that can be queried via [SWS_CRYPT_50092] (AUTOSAR AP TR SystemTests p. 177). On every binding attempt (SetKey), the crypto stack validates whether the operation of the target context (e.g., encrypting, signing, deriving, or exporting) is authorized by the flags of the key, and strictly rejects unauthorized uses (AUTOSAR AP TR SystemTests p. 177, SWArchitecture p. 95). The default setting for an algorithm can be determined via [SWS_CRYPT_20955].

For secure key exchange, the module implements several standardized methods: In asymmetric key agreement (Diffie-Hellman / ECDH), a KeyAgreementPrivateCtx is created via [SWS_CRYPT_20758], to which the private key is bound ([SWS_CRYPT_21313]); the method [SWS_CRYPT_21312] then computes the shared symmetric target key, incorporating the public key of the counterparty (AUTOSAR AP TR SystemTests p. 179). In the Key Encapsulation Mechanism (KEM), an KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) encapsulates a symmetric key using [SWS_CRYPT_21813], while the counterparty performs the decapsulation via an KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) via [SWS_CRYPT_21412] (AUTOSAR AP TR SystemTests p. 173, AUTOSAR TR AdaptivePlatformSystemTests p. 188). For protected key transport, key wrapping ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) and secured export ([SWS_CRYPT_20728]) are available (AUTOSAR AP TR SystemTests p. 174, AUTOSAR AP TR SystemTests p. 182).

Sequence diagram: Asymmetric key agreement via Diffie-Hellman and derivation of symmetric payload keys. Sources: [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests p. 179.

Asymmetric signatures are handled via separate contexts: Signing is performed via a SignerPrivateCtx ([SWS_CRYPT_20756]) and the [SWS_CRYPT_23512] method, while verification is carried out via a VerifierPublicCtx ([SWS_CRYPT_20757]) and the [SWS_CRYPT_24112] method (AUTOSAR AP TR SystemTests p. 164, SWArchitecture p. 84). If a KeySlot is updated in the background by privileged management services (e.g., OTA key rollover), consuming libraries can be notified via an update observer using [SWS_CRYPT_30404] in order to reload their key material synchronously (AUTOSAR AP SWS Cryptography p. 36).

Sequence diagram: Sequence of signature generation and verification utilizing separate private and public contexts. Sources: [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests p. 164.

X.509 Certificate Management, Validation, and Groups

The subsystem ara::crypto::x509 provides standardized functions for Public Key Infrastructures (PKI) (EXP SWArchitecture p. 116). The central X509Provider ([SWS_CRYPT_40099]) supports both volatile session storage and persistent repositories (SWS Cryptography p. 39). Certificates and chains are parsed from byte buffers via [SWS_CRYPT_40614] and [SWS_CRYPT_40616], respectively. To request new identity certificates, applications can generate cryptographically signed Certificate Signing Requests (CSR) via [SWS_CRYPT_40640], where the signer context and the Distinguished Name (DN) are passed via [SWS_CRYPT_50186] (AUTOSAR AP TR SystemTests p. 189).

For conformance and validity verification, the application instantiates a CertificateValidationCtx via [SWS_CRYPT_50125]. Trust anchors are added to this context via [SWS_CRYPT_50117], validation options are defined via [SWS_CRYPT_50120], and reference timestamps are deposited via [SWS_CRYPT_50121]. Hierarchical chain validation against the trust chain is performed via [SWS_CRYPT_50122] or [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests p. 194). To capture certificate revocations, Certificate Revocation Lists (CRL) can be imported ([SWS_CRYPT_50183]) or online certificate status queries (OCSP according to RFC 6960) can be incorporated into the validation status via [SWS_CRYPT_40626], [SWS_CRYPT_50185], and [SWS_CRYPT_50124] (AUTOSAR AP TR SystemTests p. 194).

To decouple certificate consumers from individual certificate instances during key rollovers, the manifest supports the concept of CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification p. 657). Consuming applications load the entire group of logically linked certificates via [SWS_CRYPT_50126], while privileged administration services can dynamically replace or clean up certificates via [SWS_CRYPT_50127] and [SWS_CRYPT_50128] (AUTOSAR AP TPS ManifestSpecification p. 657).

Sequence diagram: X.509 certificate validation with certificate chain, CRL import, and online OCSP status verification. Sources: [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests p. 194.

Manifest Modeling, Port Interfaces, and Deployment

The integration of cryptographic resources into an overall vehicle architecture takes place declaratively via the AUTOSAR metamodel in the ARXML manifest (AUTOSAR AP TPS ManifestSpecification p. 244). Software components model their security requirements at the design level via ports (RPortPrototype) that are typed by specializations of CryptoInterface: CryptoKeySlotInterface for key slots, CryptoCertificateInterface for certificate resources, and CryptoProviderInterface for access to execution providers (TPS ManifestSpecification p. 167, AUTOSAR AP TPS ManifestSpecification p. 245). The attributes of the interfaces immutably specify whether read or write permissions are granted (writeAccess) and which object types are permitted (TPS ManifestSpecification p. 168, TPS ManifestSpecification p. 438).

In the deployment manifest, the target configuration connects the abstract port prototypes with concrete physical platform resources (AUTOSAR AP TPS ManifestSpecification p. 649). The metamodel element CryptoKeySlotToPortPrototypeMapping maps the port of a process to a CryptoKeySlot declared in the CryptoModuleInstantiation of the machine (TPS ManifestSpecification p. 614, TPS ManifestSpecification p. 646). In an analogous manner, CryptoCertificateToPortPrototypeMapping assigns certificates (TPS ManifestSpecification p. 655). At runtime, the path of the port in the manifest represents the ara::core::InstanceSpecifier that the application code passes to loader functions such as [SWS_CRYPT_50004] (ManifestSpecification p. 154).

For platform interactions between functional clusters—such as between Communication Management (SecOC, IPsec, TLS) and the crypto stack—no classical port prototypes exist (TPS ManifestSpecification p. 861). Here, the InstanceSpecifier is instead formed by elements derived from FunctionalClusterInteractsWithFunctionalClusterMapping, for example ComKeyToCryptoKeySlotMapping or SecOcJobMapping (TPS ManifestSpecification p. 861, TPS ManifestSpecification p. 864, ManifestSpecification p. 411). Persistency protection (Persistency Deployment) and software cluster checksums also bind their keys and providers via these standardized manifest mappings (TPS ManifestSpecification p. 867, TPS ManifestSpecification p. 896).

Behavior in the event of an error

The error handling concept of the crypto module follows the strict requirements of the Adaptive Platform for fail-safe and exception-free code (noexcept) (SWS Cryptography p. 145). All synchronous operations return error situations via the generic result type ara::core::Result<T, ara::core::ErrorCode> (SWS Cryptography p. 208). The error codes are rooted in a dedicated error domain represented by [SWS_CRYPT_19902]; its name can be queried via [SWS_CRYPT_19950] and the textual error description via [SWS_CRYPT_19953]. For applications that explicitly use exception handling, the stack provides the exception type CryptoException ([SWS_CRYPT_19906]) and the helper function [SWS_CRYPT_19954].

Typical functional error codes include context violations such as CryptoErrc::kUninitializedContext if cryptographic operations are triggered before calling SetKey(), or CryptoErrc::kInvalidInputSize if the passed input data buffers do not match the required block raster (SWS Cryptography p. 208). During serialization and conversion operations, CryptoErrc::kUnknownIdentifier signals unsupported argument values and CryptoErrc::kIncompatibleArguments incompatible parameter combinations (SWS Cryptography p. 145). When accessing key resources, the stack prevents unauthorized access by returning kAccessViolation (SWS Cryptography p. 87). When parsing malformed custom X.509 certificate extensions, the parser aborts with CryptoErrc::kRuntimeFault (SWS Cryptography p. 280, SWS Cryptography p. 356).

To restore a defined state in the context after an error occurs and to avoid memory leaks or hanging streaming buffers in the daemon, the caller must clean up the context. This is done either specifically by calling Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), which discards unfinished transformations, or by Reset() ([SWS_CRYPT_50212]), which completely resets the context to the state prior to key binding (EXP SWArchitecture p. 100).

Further detailed evidence

The specification of the Cryptography module relies on a series of central requirements and architectural documents, which are categorized below:

• Global entry points and factories: The specifications [SWS_CRYPT_20099] (LoadCryptoProvider) and [SWS_CRYPT_40099] (LoadX509Provider) define normative access to the two primary provider domains (SWArchitecture p. 71, SWS Cryptography p. 39).
• Key storage and port binding: The functions [SWS_CRYPT_50004] (LoadKeySlot) and [SWS_CRYPT_50005] (LoadWriteableKeySlot) normatively implement the interaction between port modeling in the manifest and isolated physical memory access in the KSP (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649).
• Primitive and context factories: The interface group around [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx), and [SWS_CRYPT_20757] (CreateVerifierPublicCtx) specifies the dynamic creation of standardized state machines for crypto jobs (AUTOSAR AP EXP SWArchitecture p. 99, AUTOSAR AP TR SystemTests p. 164).
• X.509 validation and revocation check: With [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl), and [SWS_CRYPT_50124] (AddOcspResponse), a complete, automotive-grade PKI verification chain is standardized (AUTOSAR AP TR SystemTests p. 194, EXP SWArchitecture p. 116).