namespace ara::crypto::cryp

Namespace ara::crypto::cryp provides the central interfaces for cryptographic operations, key objects, and key storages in the AUTOSAR Adaptive Platform. Via the central factory CryptoProvider, keys are obtained from instances of KeySlot, and specialized execution contexts derived from CryptoContext are instantiated for encryption, signatures, or hashing. The cryptographic operations are performed after configuring the stateful context with the input data. An essential constraint according to the present interpretation lies in the strict encapsulation of key material via CryptoObject as well as the differentiation of write permissions via WriteableKeySlot.

more ›

Context and Scope

Namespace ara::crypto::cryp forms the functional core of the AUTOSAR Adaptive cryptography module and provides interfaces for cryptographic primitives, object models, and key management structures. At the center of the architecture is interface CryptoProvider, which serves as an implementation instance and factory for cryptographic algorithms as well as for accessing key storage. Fundamental data structures and keys are represented via the common interface CryptoObject, from which concrete key types such as SymmetricKey, PublicKey, and PrivateKey derive. Storage locations for key material are represented by KeySlot and its writable specialization WriteableKeySlot.

Context diagram: Interplay between CryptoProvider, key storage, and cryptographic contexts. Sources: None specified in payload.

For executing cryptographic transformations, the namespace provides a family of specialized interfaces built upon mutable base context CryptoContext. These execution contexts include symmetric ciphers (SymmetricCipherCtx, AuthCipherCtx), asymmetric encryption and decryption (EncryptorPublicCtx, DecryptorPrivateCtx), and mechanisms for signature generation and verification (SignerPrivateCtx, VerifierPublicCtx). This spectrum is supplemented by contexts for hash functions (HashFunctionCtx), message authentication codes (MessageAuthnCodeCtx), key derivation (KeyDerivationFunctionCtx), key agreement (KeyAgreementPrivateCtx), key encapsulation (KeyEncapsulatorPublicCtx, KeyDecapsulatorPrivateCtx), key encapsulation with symmetric wrapping (SymmetricKeyWrapperCtx), random number generation (RandomGeneratorCtx), and secure key import (ProtectedKeyImportCtx).

Lifecycle and State Management

The management and lifetime of cryptographic artifacts are tightly coupled to the interplay between CryptoProvider, key objects, and contexts. According to the present interpretation, the lifecycle of cryptographic contexts and objects is primarily controlled via the factory and management methods of CryptoProvider, which acts as the central entry point for instantiation. Objects derived from CryptoObject represent immutable or managed cryptographic entities, whereas CryptoContext is explicitly defined as a stateful, mutable context. This requires configurations, intermediate states, and algorithmic parameters to be maintained within the respective context instance.

For persistent or temporary storage of key material, the namespace differentiates between KeySlot and WriteableKeySlot. According to a proper interpretation, the separation between KeySlot and WriteableKeySlot is likely to separate read accesses from write key modifications, so that immutable or write-protected key areas can be protected against accidental overwriting. Question Q-e1b708ca976f7e99 (open) State transformations of keys and contexts thus take place under the control of the associated provider, which ensures the validity of key objects across their lifecycle.

Usage Path of Cryptographic Operations

Cryptographic operations typically follow the sequence of provider query, key provisioning via key slots, and initialization of the stateful context. In a first step, an application component accesses the responsible CryptoProvider. Via this provider, the required key material is either loaded from a KeySlot or WriteableKeySlot, respectively, or obtained as a concrete CryptoObject (for example as SymmetricKey, PrivateKey, or PublicKey). In parallel or subsequently, the provider creates the appropriate instance of CryptoContext, such as a SymmetricCipherCtx for encryptions or a SignerPrivateCtx for digital signatures.

Sequence diagram: Typical call order when performing cryptographic operations. Sources: None specified in payload.

In the subsequent execution step, the generated context is configured with the loaded key and supplied with the payload data to be processed. Due to the stateful nature of CryptoContext, streaming operations or multi-stage transformations can be performed incrementally before the final cryptographic result (such as ciphertext, signature, or hash value) is returned to the application. After processing is complete, releasing volatile states is subject to the convention of the executing context and provider.