Specification of Cryptography

AUTOSAR AP R22-11

[SWS_CRYPT_00609]{DRAFT} dThe interface ara::crypto::cryp::Key-

DerivationFunctionCtx::AddSecretSalt shall add a secret Salt value stored
in the provided ara::crypto::cryp::SecretSeed for subsequent key derivation
• ara::crypto::cryp::KeyDerivationFunctionCtx::AddSecretSalt
shall return a kInvalidInputSize error, if the size of the provided secret Salt
is not supported by the ara::crypto::CryptoAlgId used to instantiate this
context.
c(RS_CRYPTO_02101)
[SWS_CRYPT_00610]{DRAFT} dThe interface ara::crypto::cryp::Key-
DerivationFunctionCtx::ConfigIterations shall configure the number of
iterations for subsequent key derivation. If the provided number of iterations is smaller
or larger than the implementation of this interface supports, the interface shall return
the actual number of iterations applied otherwise the interface shall return the provided
number of iterations.c(RS_CRYPTO_02101)
The stack vendor may restrict the maximum number of iterations to avoid overloading
the system. The stack vendor may enforce a minimum number of itertions needed to
derive a secure key.
[SWS_CRYPT_00611]{DRAFT} dThe interfaces ara::crypto::cryp::Key-
DerivationFunctionCtx::DeriveKey and ara::crypto::cryp::Key-
DerivationFunctionCtx::DeriveSeed shall apply the configured key derivation
algorithm for the provided context configuration. The interface shall return the derived
Key Material as a ara::crypto::cryp::SymmetricKey or ara::crypto::-
cryp::SecretSeed respectively. The returned objects shall be configured according
to the provided flags isSession or isExportable and isSession or isEx-
portable. If the flags are not provided the object instance shall be session and
not exportable. The interface shall return kUninitializedContext, if the con-
figured key derivation algorithm requires more context configuration than provided.c
(RS_CRYPTO_02101)
[SWS_CRYPT_00622]{DRAFT} Signalization of error dBy conventions, if any algo-
rithm fails the FC Crypto shall provide a distinct error. The context will fail:
• If the input or output lengths exceed some (very large) implementation defined
bound.
c(RS_CRYPTO_02101)
[SWS_CRYPT_40944]{DRAFT} dThe interfaces ara::crypto::cryp::Key-
DerivationFunctionCtx::SetSourceKeyMaterial and ara::crypto::-
cryp::KeyDerivationFunctionCtx::SetSourceKeyMaterial shall deploy
the provided data (ara::crypto::cryp::RestrictedUseObject or ara::-
crypto::cryp::ReadOnlyMemRegion) as source input for key derivation. The
interface shall return
• kUsageViolation error, if the allowed usage flagkAllowKdfMaterial of the
provided ara::crypto::cryp::RestrictedUseObject is not set.

61 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kIncompatibleObject error, if the provided ara::crypto::cryp::Re-

strictedUseObject belongs to a different ara::crypto::cryp::Crypto-
Provider instance.
• kBruteForceRisk error, if the provided source material is below a implemen-
tation defined size
c(RS_CRYPTO_02101)
[SWS_CRYPT_40945]{DRAFT} dThe interface ara::crypto::cryp::Key-
DerivationFunctionCtx::Init shall configure the key derivation by setting the
provided targetKeyId, the optionally provided ara::crypto::CryptoAlgId,
usage flags and context label of the derived key. The interface shall return:
• kUsageViolation error, if a ara::crypto::cryp::RestrictedUseOb-
ject has been provided as source Key Material and its allowed usage flags
are more restrictive than the allowed usage flags provided by this interface.
• kIncompatibleArguments error, if the provided targetAlgId is incompati-
ble with the size of the Key Material derived by the configured key derivation
algorithm.
c(RS_CRYPTO_02101)
[SWS_CRYPT_40946]{DRAFT} dThe interface ara::crypto::cryp::Key-
DerivationFunctionCtx::GetTargetAllowedUsage shall return the allowed
usage flags of the derived key.
• If the context has not yet been configured by a call to ara::crypto::cryp:-
:KeyDerivationFunctionCtx::Init and a ara::crypto::cryp::Re-
strictedUseObject has been provided as source Key Material, the al-
lowed usage flags of the source key-material shall be returned.
• If the context has not yet been configured by a call to ara::crypto::cryp:-
:KeyDerivationFunctionCtx::Init and no ara::crypto::cryp::Re-
strictedUseObject has been provided as source Key Material, kAl-
lowKdfMaterialAnyUsage shall be returned.
• If the context has been configured by a call to ara::crypto::cryp::Key-
DerivationFunctionCtx::Init, the provided ara::crypto::Allowe-
dUsageFlags shall be returned or kAllowKdfMaterialAnyUsage in case
ara::crypto::AllowedUsageFlags have not been provided.
c(RS_CRYPTO_02101)

7.4.1.3 Hashing

A hash-function is a one-way function and maps an arbitrary string of bits to a fixed-

length string of bits. Due to its nature the bit string result is practical infeasible to
invert. Hash-functions are basic elements of cryptography functions. Therefore, the

62 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

FC Crypto allows application and Functional Clusters to use common hash-

functions and expose access via the CryptoAPI to the user. The FC Crypto ensures
that the typical properties of modern hash-functions are met and not altered by third
parties. The typical properties of modern hash-functions are:
• Determinism: the same input to the hash-function generates always the same
result.
• Speed: results are quick to compute.
• No revert: the result is infeasible to revert to the input.
• Collision freedom: two different inputs generate different output.
• Correlation freedom: a small change to the input changes the output significant
without providing a correlation of all parts.
[SWS_CRYPT_00902]{DRAFT} dThe ara::crypto::cryp::HashFunctionCtx
shall implement hashing.
c(RS_CRYPTO_02204)
[SWS_CRYPT_00903]{DRAFT} dThe ara::crypto::cryp::HashFunctionCtx
shall store the calculated hash value until this ara::crypto::cryp::HashFunc-
tionCtx object is destroyed or the function ara::crypto::cryp::HashFunc-
tionCtx::Start is called again.c(RS_CRYPTO_02205)
[SWS_CRYPT_00908]{DRAFT} Start dThe functions ara::crypto::cryp::Hash-
FunctionCtx::Start, ara::crypto::cryp::HashFunctionCtx::Start,
ara::crypto::cryp::HashFunctionCtx::Start shall clear the current hash
value and initialize the context with the provided IV.
• ara::crypto::cryp::HashFunctionCtx::Start, ara::crypto::-
cryp::HashFunctionCtx::Start shall return a
• kInvalidInputSize error, if the size of the provided IV is not supported by
the configured context ara::crypto::CryptoAlgId.
• ara::crypto::cryp::HashFunctionCtx::Start, ara::crypto::-
cryp::HashFunctionCtx::Start shall return a kUnsupported error, if the
configured context ara::crypto::CryptoAlgId does not support an IV.
• ara::crypto::cryp::HashFunctionCtx::Start shall return a
kMissingArgument error, if the configured context ara::crypto::-
CryptoAlgId expected an IV but none was provided.
c(RS_CRYPTO_02205)
Note, Start method can be called after Update method. In this case the ara::-
crypto::cryp::HashFunctionCtx will not return an error, instead Start method
will start a new hash value calculation.

63 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

Some Cryptographic primitives require an Initialization Vector to guarantee

randomness or freshness during the data processing. When an application or Func-
tional Cluster specifies a cryptographic primitive, which requires an IV, the caller
must provide the IV.
Hash-function calculation can be resource intensive when the input data has an ar-
bitrary length, which may exceed some (very large) implementation defined bound.
A solution is to generate hashes incrementally by presenting parts of the input data,
which is hashed. This elementary characteristic is based on two reasons:
• Commonly in practice the entire hash object is not in one contiguous segment
available. Instead, often parts are used independently as given by the HMAC
function for example. Here, the inner hash is some preprocessed keying material,
followed by the message being MAC’ed. Therefore, a temporary buffer consisting
of the HMAC inner key (”ipad”) and the message can be created. However, this is
an overhead.
• The incrementally creation allows to run the hash implementation in memory
complexity O(1). The needed memory space for calculation is independent of
input size. This is very easy to do with current hash function, such as SHA-2 and
SHA-3, where, with a small amount of side memory, the hashing processes the
message in pieces.
When an application or Functional Cluster uses the hash-function of FC
Crypto, it expects that the Crypto Provider supports this elementary characteris-
tic and the CryptoAPI exposes the corresponding interface.
[SWS_CRYPT_00905]{DRAFT} Update dThe functions ara::crypto::cryp::-
HashFunctionCtx::Update, ara::crypto::cryp::HashFunctionCtx::Up-
date, ara::crypto::cryp::HashFunctionCtx::Update shall implement the
configured hash algorithm calculation.c(RS_CRYPTO_02205)
[SWS_CRYPT_00909]{DRAFT} Update dThe user application shall be able to call Up-
date multiple times, each time providing a new chunk of data. Update shall update the
hash value calculation with each new chunk. Update shall return a CryptoError-
Domain::kProcessingNotStarted error, if Start has not been called before.c
(RS_CRYPTO_02205)
With the support of the incrementally creation characteristics the FC Crypto lost the
possibility to know when the input data ends. Therefore, the application or Func-
tional Cluster needs the possibility to inform the Crypto Provider that all parts
of the input was provided and no further input must be processed. The CryptoAPI
supports this signaling with a corresponding interface.
[SWS_CRYPT_00906]{DRAFT} Finish dThe function ara::crypto::cryp::-
HashFunctionCtx::Finish shall finalize the hash value calculation and return the
hash value, i.e. no more data may be provided by Update.

64 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• ara::crypto::cryp::HashFunctionCtx::Finish shall return a Cryp-

toErrorDomain::kProcessingNotStarted error, if Start has not been
successfully called before.
• ara::crypto::cryp::HashFunctionCtx::Finish shall return a Cryp-
toErrorDomain::kInvalidUsageOrder error, if Update has not been
called successfully after the last call to Start.
c(RS_CRYPTO_02205)
[SWS_CRYPT_00910]{DRAFT} dIf Finish is called multiple times for the same hash
value calculation, then only the first call shall apply the finalizations step; i.e. all other
subsequent calls shall only return the hash value.c(RS_CRYPTO_02205)
If the signature object is produced by a plain hash-function, then the dependent COUID
of the signature should be set to COUID of context. However, the hash algorithm ID
field of the signature shall be set according to the used algorithm ID. If the signature
object is produced by a keyed MAC/HMAC/AE/AEAD algorithm, then the dependence
COUID of the signature should be set to COUID of used Symmetric Key. Instead, the
hash algorithm ID field of the signature shall be set to an unknown algorithm ID.
[SWS_CRYPT_00907]{DRAFT} Retrieving the hash value dThe functions ara:-
:crypto::cryp::HashFunctionCtx::GetDigest, ara::crypto::cryp::-
HashFunctionCtx::GetDigest shall return the finalized hash value or part of the
hash value, if the application requested an offset. The offset specifies the first byte that
shall be included in the returned buffer.c(RS_CRYPTO_02205)
[SWS_CRYPT_00919]{DRAFT} Signalization of missing finalization error
dThe functions ara::crypto::cryp::HashFunctionCtx::GetDigest, ara::-
crypto::cryp::HashFunctionCtx::GetDigest shall return a kProcessing-
NotFinished error, if ara::crypto::cryp::HashFunctionCtx::Finish has
not been called for the current hash value calculation.c(RS_CRYPTO_02205)

7.4.1.4 Message Authentication Code (MAC)

According to the ISO-9797 [13] Message Authentication Code (MAC) algorithms

are data integrity mechanisms that compute a short string (the Message Authentication
Code or MAC) as a complex function of every bit of the data and of a secret key. Their
main security property is unforgeability: someone who does not know the secret key
should not be able to predict the MAC on any new data string.
MAC algorithms can be used to provide data integrity, as defined in defined in [14] and
in [15]. Their purpose is the detection of any unauthorized modification of the data
such as deletion, insertion, or transportation of items within data. This includes both
malicious and accidental modifications. MAC algorithms can also provide data origin
authentication. This means that they can provide assurance that a message has been
originated by an entity in possession of a specific secret key.

65 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

In order to support these mechanism, the FC Crypto must provide three basic build-
ing blocks:
• A key generation algorithm
• An signing algorithm
• A verifying algorithm
The FC Crypto shall support Message Authentication Code generation as de-
scribed in [14] and in [15].
This identifier is encoded with the common name as defined in chapter 7.5. MAC al-
gorithms can be constructed from other Cryptographic primitives, like crypto-
graphic hash functions (as in the case of HMAC), which are specified in chapter 7.4.1.3,
or from Block Cipher algorithms, as defined in chapter 7.4.1.5.1. Both variants are
supported by the FC Crypto. However, the Crypto Provider can either directly
access the cryptographic algorithm or use the exposed interfaces provided by the
CryptoAPI.
The context handles two different use cases, when an application or Functional
Cluster start processing or generation of the hash-value:
• The context was fresh initialized. No former data was stored in the context, so the
Crypto Provider can start the calculation on the new data stream (depending
from the primitive).
• The context was used previously. Thus, previous stored content will be deleted,
the context is rest to a fresh initialization state, and the calculation is started on
the new given data stream.
Some Cryptographic primitives require an Initialization Vector to guarantee
randomness or freshness during the data processing. When an application or Func-
tional Cluster specifies a cryptographic primitive, which requires an IV, as MAC al-
gorithms, the caller must provide the IV. Otherwise the Crypto Provider will throw
an error.
[SWS_CRYPT_01202]{DRAFT} dAt initialization phase the context allows to specify an
optional Initialization Vector (IV) or Nonce value. If IV size is greater than maximally
by the algorithm supported length, then an FC Crypto uses the leading bytes only.c
(RS_CRYPTO_02203)
[SWS_CRYPT_01201]{DRAFT} dThe function ara::crypto::cryp::MessageAu-
thnCodeCtx::Start shall initialize the context for a new data stream processing or
generation (depending on the the primitive). The function shall return:
• kUninitializedContext error, if the context was not initialized by deploying
a key.
• kInvalidInputSize error, if the size of provided IV is not supported (i.e. if it is
not enough for the initialization).

66 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kUnsupported error, if if the base algorithm (or its current implementation) prin-
cipally does not support the IV variation, but provided IV value is not empty.
c(RS_CRYPTO_02203)
[SWS_CRYPT_01203]{DRAFT} Start dThe function ara::crypto::cryp::Mes-
sageAuthnCodeCtx::Start shall initialize the context for a new data stream pro-
cessing or generation (depending on the primitive) with a secret seed. If the size of
the secret seed size is greater than maximum supported by the algorithm then an im-
plementation may use the leading bytes only from the sequence. The function shall
return:
• kUninitializedContext error, if the context was not initialized by deploying
a key.
• kInvalidInputSize error, if the size of provided secret seed is not supported
(i.e. if it is not enough for the initialization).
• kUnsupported if the base algorithm (or its current implementation) principally
does not support the secret seed variation.
• kUsageViolation error, if this transformation type is prohibited by the "allowed
usage" restrictions of the provided Secret Seed object.
c(RS_CRYPTO_02203)
[SWS_CRYPT_01204]{DRAFT} Update dThe functions ara::crypto::cryp:-
:MessageAuthnCodeCtx::Update, ara::crypto::cryp::MessageAuthn-
CodeCtx::Update, ara::crypto::cryp::MessageAuthnCodeCtx::Update
shall update the digest calculation context by a new part of the message. The functions
shall return:
• kProcessingNotStarted error, if the digest calculation was not initiated by a
call of the ara::crypto::cryp::MessageAuthnCodeCtx::Start method.
c(RS_CRYPTO_02203)
[SWS_CRYPT_01207]{DRAFT} Finish dThe function ara::crypto::cryp::Mes-
sageAuthnCodeCtx::Finish shall finalize the hash value calculation, return the
hash value and optionally produce the "signature" object. After the call of this function
no more data can be provided by callingara::crypto::cryp::MessageAuthn-
CodeCtx::Update. The function shall return:
• kProcessingNotStarted error, if ara::crypto::cryp::MessageAuthn-
CodeCtx::Start has not been successfully called before.
• kUsageViolation error, if ara::crypto::cryp::MessageAuthn-
CodeCtx::Update, ara::crypto::cryp::MessageAuthnCodeCtx:-
:Update, ara::crypto::cryp::MessageAuthnCodeCtx::Update has
not been called successfully after the last call to ara::crypto::cryp::Mes-
sageAuthnCodeCtx::Start.

67 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

c(RS_CRYPTO_02203)
[SWS_CRYPT_01208]{DRAFT} dIf the signature object is produced by a plain hash-
function then the dependence COUID of the ”signature” should be set to COUID of the
used context. But the hash algorithm ID field of the signature should be set according
to the used algorithm ID.c(RS_CRYPTO_02203)
[SWS_CRYPT_01209]{DRAFT} dIf the signature object is produced by a keyed MAC/
HMAC/AE/AEAD algorithm, then the dependent COUID of the signature should be set
to COUID of the used Symmetric Key. However, the hash algorithm ID field of the
signature should be set to unknown.c(RS_CRYPTO_02203)
[SWS_CRYPT_01210]{DRAFT} GetDigest dThe functions ara::crypto::cryp:-
:MessageAuthnCodeCtx::GetDigest, ara::crypto::cryp::MessageAuth-
nCodeCtx::GetDigest shall provide the hashed output. The CryptoAPI allows
also to specific an offset. This offset informs the Crypto Provider where the posi-
tion of first byte of digest is that should be placed to the output buffer. The functions
shall return:
• kProcessingNotFinished error, if the digest calculation was not finished by
a call of the Finish() method.
• kUsageViolation error, if the buffered digest belongs to a MAC/H-
MAC/AE/AEAD context initialized by a key without kAllowSignature permis-
sion.
c(RS_CRYPTO_02203)
The Key Storage Provider generates and manages the key as described in chap-
ter 7.4.2.2. The key can either be generated or configured in the context of the appli-
cation or Functional Cluster. When the FC Crypto provides the context no key
is given. The application or Functional Cluster will provide the key. The key itself
contains also the encoding as an attribute and will not provided by the application or
Functional Cluster in the call of the CryptoAPI method.
[SWS_CRYPT_01211]{DRAFT} SetKey dThe function ara::crypto::cryp::Mes-
sageAuthnCodeCtx::SetKey shall set (deploy) a key to ara::crypto::cryp:-
:MessageAuthnCodeCtx. The function shall return:
• kIncompatibleObject error, if the provided key object is incompatible with
this Symmetric Key context.
• kUsageViolation error, if the transformation type associated with this context
(taking into account the direction specified by transform) is prohibited by the "al-
lowed usage"restrictions of provided key object.
c(RS_CRYPTO_02203)
[SWS_CRYPT_01213]{DRAFT} Verify dThe CryptoAPI shall ara::crypto::-
cryp::MessageAuthnCodeCtx::Check if previous calculated and internally stored
MAC is valid to an expected ”signature” object. Validation is successful, if value and

68 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

meta-information of the provided ”signature” object is identical to calculated digest and

current configuration of the context.c(RS_CRYPTO_02203)

7.4.1.5 Symmetric encryption

Symmetric encryption uses a shared secret (e.g., share key) to encrypt and / or decrypt
an information. Without knowing the key, the information cannot be understood by
anyone. Symmetric cryptography can be categorized by two algorithm classes:
1. Block Cipher: Data with a fixed length is transformed (en/decrypted). The
system can only process complete blocks of data held in its internal memory.
2. Stream Cipher: Information is encrypted as it streams instead of being re-
tained in the system’s memory.

7.4.1.5.1 Block cipher

The encryption method, Block Cipher, applies an algorithm with a Symmetric Key
to encrypt an input data. Block Ciphers are commonly used to protect data at rest,
such as on file systems.
[SWS_CRYPT_01502]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricBlockCipherCtx::SetKey shall configure this context for encryption or decryp-
tion according to the provided ara::crypto::CryptoTransform and ensure that
the provided ara::crypto::cryp::SymmetricKey is used for the following en/de-
cryption.
• SetKey shall return a CryptoErrorDomain::kIncompatibleObject error,
if the provided Symmetric Key belongs to a different ara::crypto::cryp:-
:CryptoProvider instance.
• SetKey shall return a CryptoErrorDomain::kUsageViolation error, if the
provided transformation direction (CryptoTransform::kEncrypt or Cryp-
toTransform::kDecrypt) does not match the ara::crypto::Allowe-
dUsageFlags (kAllowDataEncryption or kAllowDataDecryption, re-
spectively) of the provided Symmetric Key.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01501]{DRAFT} dOnly the key and transformation direction specified
by the last valid call of ara::crypto::cryp::SymmetricBlockCipherCtx::-
SetKey shall be used for the subsequent encryption or decryption operation.c(RS_-
CRYPTO_02107, RS_CRYPTO_02201)

69 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_01508]{DRAFT} dThe interface ara::crypto::cryp::Symmet-

ricBlockCipherCtx::GetTransformation shall return the ara::crypto::-
CryptoTransform that was provided in the last valid call to ara::crypto::cryp:-
:SymmetricBlockCipherCtx::SetKey.
• GetTransformation shall return a CryptoErrorDomain::kUnini-
tializedContext error, if ara::crypto::cryp::SymmetricBlockCi-
pherCtx::SetKey was never called.
c(RS_CRYPTO_02107, RS_CRYPTO_02201)
[SWS_CRYPT_01506]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricBlockCipherCtx::GetCryptoService shall return a unique pointer to
the ara::crypto::cryp::CryptoService associated with this context.c(RS_-
CRYPTO_02107, RS_CRYPTO_02201)
[SWS_CRYPT_01503]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricBlockCipherCtx::ProcessBlock shall apply the configured transformation
(encryption or decryption) to the provided ara::crypto::ReadOnlyMemRegion
and return the result. Note: ProcessBlock shall not apply padding, but instead the
size of the input buffer must be equal to the block-size.
• ProcessBlock shall return a CryptoErrorDomain::kUninitialized-
Context error, if ara::crypto::cryp::SymmetricBlockCipherCtx::-
SetKey was never called.
• ProcessBlock shall return a CryptoErrorDomain::kInvalidInputSize
error, if the size of the input buffer is not equal to the block-size.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01504]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricBlockCipherCtx::ProcessBlocks shall apply the configured transformation
(encryption or decryption) to the provided ara::crypto::ReadOnlyMemRegion
and return the result. Note: ProcessBlocks shall not apply padding, but instead
the size of the input buffer must be a multiple of the block-size.
• ProcessBlock shall return a CryptoErrorDomain::kUninitialized-
Context error, if ara::crypto::cryp::SymmetricBlockCipherCtx::-
SetKey was never called.
• ProcessBlock shall return a CryptoErrorDomain::kInvalidInputSize
error, if the size of the input buffer is not a multiple of the block-size.
c(RS_CRYPTO_02201)

70 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

7.4.1.5.2 Stream Cipher

A Stream Cipher is used for Symmetric Key cryptography, or when the same key
is used to encrypt and decrypt data. Stream Ciphers encrypt pseudo-random se-
quences with bits of plain-text in order to generate cipher-text, usually with XOR.
Stream Ciphers are good for fast implementations with low resource consumption.
These two features help the defender implement resistance strategies in devices that
may not have the resources for a Block Cipher implementation. Stream Ciphers
can be broadly classified into those that work better in hardware and those that work
better in software. Stream Ciphers are commonly used to protect data in motion,
such as encrypting data on the network.
[SWS_CRYPT_01651]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::GetBlockService shall return a unique pointer to the ara::crypto:-
:cryp::BlockService associated with this context.c(RS_CRYPTO_02107, RS_-
CRYPTO_02201)
[SWS_CRYPT_01658]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::CountBytesInCache shall return the number of input data bytes cur-
rently held in the context cache.c(RS_CRYPTO_02201)
Note, that the above requirement applies only to block-wise modes when the user
supplied input data that is not a multiple of the block-size. In this case the last data
chunk, which cannot be processed because it is less than the block-size, must be
cached until the next data processing call adds sufficient data to complete the block-
size (and continue processing).
[SWS_CRYPT_01659]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::SetKey shall configure this context for encryption or decryption according
to the provided ara::crypto::CryptoTransform and ensure that the provided
ara::crypto::cryp::SymmetricKey is used for the following en/decryption.
• SetKey shall return a CryptoErrorDomain::kIncompatibleObject error,
if the provided Symmetric Key belongs to a different ara::crypto::cryp:-
:CryptoProvider instance.
• SetKey shall return a CryptoErrorDomain::kUsageViolation error, if the
provided transformation direction (CryptoTransform::kEncrypt or Cryp-
toTransform::kDecrypt) does not match the ara::crypto::Allowe-
dUsageFlags (kAllowDataEncryption or kAllowDataDecryption) of the
provided Symmetric Key.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01660]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::GetTransformation shall return the ara::crypto::CryptoTrans-
form that was provided in the last valid call to ara::crypto::cryp::StreamCi-
pherCtx::SetKey.

71 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• GetTransformation shall return a CryptoErrorDomain::kUninitial-

izedContext error, if ara::crypto::cryp::StreamCipherCtx::SetKey
was never called.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01661]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::IsBytewiseMode shall return TRUE, if the algorithm specified during
context creation supports updating data byte-wise. It shall return FALSE, if the al-
gorithm can process only data in multiples of the block-size.c(RS_CRYPTO_02201)
Some operation modes of specific Stream Ciphers are seekable, e.g., [16, CTR],
[17, Salsa20], or [18, Trivium], and others are not. Seekable means that the user
can efficiently seek to any position in the data stream in constant time. If the user
needs such functionality and it is unclear if the chosen algorithm provides this kind of
functionality, the support of such a mode can be queried.
[SWS_CRYPT_01662]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::IsSeekableMode shall return TRUE, if the algorithm specified during
context creation supports seek operations.c(RS_CRYPTO_02201)
[SWS_CRYPT_01653]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::Seek shall increment/decrement the position of the next byte to process
according to the provided offset. If the second and optional boolean parameter
equals TRUE, offset shall be counted from the start of the stream.
• Seek shall return a CryptoErrorDomain::kUnsupported error, if this con-
text does not support seeking.
• Seek shall return a CryptoErrorDomain::kProcessingNotStarted error,
if processing was not started by successfully calling Start or has already been
terminated by successfully calling FinishBytes.
• Seek shall return a CryptoErrorDomain::kBelowBoundary error, if the ab-
solute seek position is negative.
• Seek shall return a CryptoErrorDomain::kInvalidArgument error, if the
interface ara::crypto::cryp::StreamCipherCtx::IsBytewiseMode re-
turns FALSE and the offset is not aligned on the block boundary.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01654]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::Start shall initialize the context either with an optional ara::crypto::-
ReadOnlyMemRegion or a mandatory ara::crypto::cryp::SecretSeed. If the
size of initialization data is larger than required by the context, only the leading bytes
shall be used.
• Start shall return a CryptoErrorDomain::kUninitializedContext er-
ror, if SetKey was never called on this context.

72 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• Start shall return a CryptoErrorDomain::kInvalidInputSize error, if

not enough initialization data has been provided.
• Start shall return a CryptoErrorDomain::kUnsupported error, if the algo-
rithm selected during context creation does not support initialization but initializa-
tion data has been provided nonetheless.
• Start shall return a CryptoErrorDomain::kUsageViolation error, if the
transformation direction provided by a call to ara::crypto::cryp::Stream-
CipherCtx::SetKey (CryptoTransform::kEncrypt or CryptoTrans-
form::kDecrypt) does not match the ara::crypto::AllowedUsageFlags
(kAllowDataEncryption or kAllowDataDecryption) of the provided
ara::crypto::cryp::SecretSeed.
c(RS_CRYPTO_02201)
Start can be called even if processing has already been started by calling for exam-
ple ProcessBlocks. In this case Start will cancel the previous transformation and
discard the intermediate result, and re-initialize the context for the new transformation.
Note: ara::crypto::cryp::StreamCipherCtx::Start must be called even if
the selected algorithm does not support initialization. In this case an empty ara::-
crypto::ReadOnlyMemRegion must be provided.
[SWS_CRYPT_01655]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::ProcessBlocks shall apply the configured transformation (encryption or
decryption) to the provided data. If the data has been provided as a ara::crypto:-
:ReadOnlyMemRegion, ProcessBlock shall return the processed data. If the data
was provided as a ara::crypto::ReadWriteMemRegion, the input data shall be
overwritten with the processed data. Note: the size of the input or input and output
buffer must be a multiple of the block-size.
• ProcessBlock shall return a CryptoErrorDomain::kIn-
validUsageOrder error, if this interface is called after ara::crypto::-
cryp::StreamCipherCtx::ProcessBytes has been called.
• ProcessBlock shall return a CryptoErrorDomain::kInvalidInputSize
error, if the size of the input buffer is not a multiple of the block-size.
• ProcessBlock shall return a CryptoErrorDomain::kProcessingNot-
Started error, if processing was not started by successfully calling Start or
has already been terminated by successfully calling FinishBytes.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01656]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::ProcessBytes shall apply the configured transformation (encryption or
decryption) to the provided data and return the result. Note: the size of the input
buffer does not need to be a multiple of the block-size. Therefore, if IsBytewiseMode
equals FALSE, ProcessBytes shall keep an internal buffer equal in size to the block-
size and only process full blocks of data. If a call to this interface left unprocessed data

73 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

in the buffer, the subsequent call’s input data shall continue filling the buffer until it can
be processed.
• ProcessBlock shall return a CryptoErrorDomain::kProcessingNot-
Started error, if processing was not started by successfully calling Start or
has already been terminated by successfully calling FinishBytes.
c(RS_CRYPTO_02201)
[SWS_CRYPT_01657]{DRAFT} dThe interface ara::crypto::cryp::StreamCi-
pherCtx::FinishBytes shall apply the configured transformation (encryption or
decryption) to the provided data for the last and final time, and return the result. If
IsBytewiseMode equals FALSE and the provided data is insufficient to end process-
ing with a completely filled internal block-size buffer (cache), then padding shall be
applied according to the algorithm selected when creating this context. For decryption
the padding shall be removed before returning the processed data.
• FinishBytes shall return a CryptoErrorDomain::kProcessingNot-
Started error, if processing was not started by successfully calling Start or
has already been terminated by successfully calling FinishBytes.
c(RS_CRYPTO_02201)
Some Stream Cipher need an exact multiple of the block length in byte. If the length
of the data to be encrypted is not an exact multiple, it must be padded to make it so.
Available padding schemes are for example, [19, PKCS5], [20, PKCS5], [21, PKCS7],
or [22, ANSI X9.23].

7.4.1.6 Authenticated Encryption

Authenticated Encryption (AE) or Authenticated Encryption with Associated Data (

AEAD) provide confidentiality and data authenticity simultaneously. AEAD adds the abil-
ity to check the integrity and authenticity of some Associated Data (AD), also called ”ad-
ditional authenticated data”. Additionally, this mechanism adds an Message Authen-
tication Code (MAC), as described in chapter 7.4.1.4, to conform that encrypted
data is authentic.
Note: the class ara::crypto::cryp::AuthCipherCtx provides authenticity and
confidentiality only for well known algorithm-protocols that derive both their proper-
ties from a single Symmetric Key (e.g. ChaCha20-Poly1305, aead/gimli24v1 or
AES-GCM). To implement a custom authenticated-encryption protocol (following a pat-
tern of Encrypt-then-Mac, Mac-then-encrypt or Encrypt-and-Mac) the classes ara:-
:crypto::cryp::StreamCipherCtx and ara::crypto::cryp::MessageAu-
thnCodeCtx can be used.

74 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_01800]{DRAFT} dThe functions ara::crypto::cryp::Au-

thCipherCtx::UpdateAssociatedData, ara::crypto::cryp::Auth-
CipherCtx::UpdateAssociatedData, ara::crypto::cryp::AuthCi-
pherCtx::UpdateAssociatedData shall return a CryptoErrorDomain::kIn-
validUsageOrder error, if ProcessConfidentialData has already been called.c
(RS_CRYPTO_02207)
[SWS_CRYPT_01801]{DRAFT} dIf associated data is provided by calling ara::-
crypto::cryp::AuthCipherCtx::UpdateAssociatedData, ara::crypto:-
:cryp::AuthCipherCtx::UpdateAssociatedData, ara::crypto::cryp::-
AuthCipherCtx::UpdateAssociatedData, the MAC calculation must be updated
with the associated data.c(RS_CRYPTO_02207)
[SWS_CRYPT_01802]{DRAFT} dCalling UpdateAssociatedData is optional for the
user. In this case the MAC shall be calculated over the confidential data only.c(RS_-
CRYPTO_02207)
[SWS_CRYPT_01803]{DRAFT} dThe function ara::crypto::cryp::AuthCi-
pherCtx::ProcessConfidentialData shall update the calculation of the MAC with
the confidential data.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01804]{DRAFT} dIf the transformation direction (ara::crypto::-
cryp::AuthCipherCtx::GetTransformation)is kEncrypt, ara::crypto::-
cryp::AuthCipherCtx::ProcessConfidentialData shall also encrypt the pro-
vided Plaintext data and return the Ciphertext.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01805]{DRAFT} dIf the transformation direction is kDecrypt, ara:-
:crypto::cryp::AuthCipherCtx::ProcessConfidentialData shall also de-
crypt the provided Plaintext data and return the Plaintext, only if the calculated
MAC matches the provided expectedTag. If the calculated MAC does not match the
provided expectedTag, CryptoErrorDomain::kAuthTagNotValid error shall
be returned instead.c(RS_CRYPTO_02207)
[SWS_CRYPT_01807]{DRAFT} dThe ara::crypto::cryp::AuthCipherCtx::-
SetKey interface of the AuthCipherCtx shall check the allowed-usage flags of the
key parameter provided.The function shall return
• a kUsageViolation error, if kAllowDataEncryption is not set and the
transformation direction is CryptoTransform::kEncrypt.
• a kUsageViolation error, if kAllowDataEncryption is not set and the
transformation direction is CryptoTransform::kDecrypt.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01808]{DRAFT} dThe function ara::crypto::cryp::AuthCi-
pherCtx::Start shall initialize the transformation using the provided IV or Nonce.
The function shall return:

75 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• a kUninitializedContext error, if ara::crypto::cryp::AuthCi-

pherCtx::SetKey has not been called before.
• a kInvalidInputSize error, if the provided data is insufficient.
• a kUnsupported error, if the ara::crypto::CryptoAlgId specified does
not support an IV or a Nonce.
• a kUsageViolation error, if a ara::crypto::cryp::SecretSeed instance
has been provided as the IV or Nonce and its allowed usage flags (kAllow-
DataEncryption or kAllowDataDecryption) do not match the transforma-
tion direction set by the ara::crypto::cryp::AuthCipherCtx::SetKey
function kEncrypt or kDecrypt.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01811]{DRAFT} dThe ara::crypto::cryp::AuthCipherCtx::-
GetDigest function shall return the calculated MAC as raw data only after the Pro-
cessConfidentialData has been successfully executed.c(RS_CRYPTO_02207)

7.4.1.7 Key Wrapping

Key Wrapping (as defined in [23] and [24]) encapsulates Key Material, which is
used for example to store a key in an unsecure environment or transport a key by an
unsecure channel. Wrapping a key is a kind of encryption of the key and contributes to
confidentiality.
Wrapping a key requires a KEK. With the call of the CryptoAPI interface the KEK is set
(deployed) to the key wrapper algorithm context. Additionally, a ”direction” indicator is
used to define the transformation direction, such as wrapping, unwrapping, signature
calculation, or signature verification.
[SWS_CRYPT_02121]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricKeyWrapperCtx::CalculateWrappedKeySize shall calculate the size of the
wrapped key based on the provided keyLength of the key to wrap and return the
result.c(RS_CRYPTO_02208)
[SWS_CRYPT_02122]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricKeyWrapperCtx::SetKey shall configure this context for encryption or decryp-
tion according to the provided ara::crypto::CryptoTransform and ensure the
provided ara::crypto::cryp::SymmetricKey is used as the key-encryption-key
(KEK) for subsequent processing in this context.
• SetKey shall return a CryptoErrorDomain::kIncompatibleObject error,
if the provided Symmetric Key belongs to a different ara::crypto::cryp:-
:CryptoProvider instance.

76 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• SetKey shall return a CryptoErrorDomain::kUsageViolation error, if the

provided transformation direction (CryptoTransform::kEncrypt or Cryp-
toTransform::kDecrypt) does not match the ara::crypto::Allowe-
dUsageFlags (kAllowKeyExporting or kAllowKeyImporting) of the pro-
vided SymmetricKey.
c(RS_CRYPTO_02208)
[SWS_CRYPT_02123]{DRAFT} dOnly the key and transformation direction specified
by the last valid call of ara::crypto::cryp::SymmetricKeyWrapperCtx::-
SetKey shall be used for the subsequent encryption or decryption operation.c(RS_-
CRYPTO_02107, RS_CRYPTO_02201)
[SWS_CRYPT_02104]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricKeyWrapperCtx::GetMaxTargetKeyLength shall return the maximum bit-
length of the payload (key-material) that can be protected by the algorithm specified
during context creation.c(RS_CRYPTO_02208)
[SWS_CRYPT_02106]{DRAFT} dThe interface ara::crypto::cryp::Symmet-
ricKeyWrapperCtx::GetTargetKeyGranularity shall return the granularity in
Bytes of the payload (key-material) that can be protected by the algorithm specified
during context creation.c(RS_CRYPTO_02208)
The granularity of key-material refers to the minimum key-size that can be protected
and implies that the actual key-size has to be a multiple of this value.
[SWS_CRYPT_02105]{DRAFT} wrap dThe interface ara::crypto::cryp::Sym-
metricKeyWrapperCtx::WrapKeyMaterial shall execute the key-wrap operation
on the key-material of the provided ara::crypto::RestrictedUseObject and re-
turn the result.
• WrapKeyMaterial shall return a CryptoErrorDomain::kInvalidInput-
Size error, if the length of the provided ara::crypto::RestrictedUseOb-
ject is unsupported by the algorithm specified during context creation.
• WrapKeyMaterial shall return a CryptoErrorDomain::kUninitial-
izedContext error, if ara::crypto::cryp::SymmetricKeyWrap-
perCtx::SetKey was never called.
• WrapKeyMaterial shall return a CryptoErrorDomain::kUsageViola-
tion error, if the kAllowExport flag is not set in the ara::crypto::Allowe-
dUsageFlags of the provided ara::crypto::RestrictedUseObject, or if
the kAllowKeyExporting flag of the ara::crypto::AllowedUsageFlags
is not set for the SymmetricKey specified in the SetKey call.
c(RS_CRYPTO_02208)
The flags ara::crypto::AllowedUsageFlags (kAllowKeyExporting or kAl-
lowKeyImporting) are set for the provided Symmetric Key.
Note: this interface was designed to support for example RFC3394 or RFC5649.

77 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_02107]{DRAFT} unwrap dThe interface ara::crypto::cryp::-

SymmetricKeyWrapperCtx::UnwrapKey shall execute the key-unwrap operation
on the provided ara::crypto::ReadOnlyMemRegion and return a unique smart
pointer to the instantiated ara::crypto::RestrictedUseObject. UnwrapKey
shall also apply the provided ara::crypto::AllowedUsageFlags and ara::-
crypto::CryptoAlgId to the created RestrictedUseObject.c(RS_CRYPTO_-
02208)
[SWS_CRYPT_02108]{DRAFT} unwrap dThe interface ara::crypto::cryp::-
SymmetricKeyWrapperCtx::UnwrapSeed shall execute the key-unwrap opera-
tion on the provided ara::crypto::ReadOnlyMemRegion and return a unique
smart pointer to the instantiated ara::crypto::SecretSeed. UnwrapSeed
shall also apply the provided ara::crypto::AllowedUsageFlags and ara:-
:crypto::CryptoAlgId to the created ara::crypto::cryp::SecretSeed.c
(RS_CRYPTO_02208)
[SWS_CRYPT_02109]{DRAFT} error handling during unwrap dThe interfaces
ara::crypto::cryp::SymmetricKeyWrapperCtx::UnwrapSeed and ara::-
crypto::cryp::SymmetricKeyWrapperCtx::UnwrapKey shall
• return a CryptoErrorDomain::kInvalidInputSize error, if the length of
the provided ara::crypto::ReadOnlyMemRegion is unsupported by the al-
gorithm specified during context creation.
• return a CryptoErrorDomain::kUninitializedContext error, if ara::-
crypto::cryp::SymmetricKeyWrapperCtx::SetKey was never called.
• return a CryptoErrorDomain::kUsageViolation error, if the kAllowKey-
Importing flag of the ara::crypto::AllowedUsageFlags is not set for the
Symmetric Key specified in the SetKey call.
c(RS_CRYPTO_02208)

7.4.1.8 Digital signatures

Digital signature contributes to goal authenticity when information is transferred. Guar-

anteeing the authenticity of the information asymmetric cryptography is used, where
the information is signed by a private key and verified later by using the matching pub-
lic key. When the verification is successful, the receiver of the information can be sure
that the owner of the private key is the sender of the information.
[SWS_CRYPT_02411]{DRAFT} dThe ara::crypto::cryp::MsgRecoveryPub-
licCtx shall implement digital signature verification with message recovery according
to [25].c(RS_CRYPTO_02204)
[SWS_CRYPT_02412]{DRAFT} dThe ara::crypto::cryp::SigEncodePriva-
teCtx shall implement digital signature generation with message encoding according
to [25].c(RS_CRYPTO_02204)

78 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_02413]{DRAFT} dThe ara::crypto::cryp::SignerPrivateCtx

shall implement digital signature generation.c(RS_CRYPTO_02204)
[SWS_CRYPT_02414]{DRAFT} dThe ara::crypto::cryp::VerifierPublic-
Ctx shall implement digital signature verification.c(RS_CRYPTO_02204)
[SWS_CRYPT_01820]{DRAFT} dThe interface ara::crypto::cryp::Signer-
PrivateCtx::SetKey shall ensure the provided ara::crypto::cryp::Pri-
vateKey is used in the following signature generation. The interface shall return
• kUsageViolation error, if the allowed usage flag kAllowSignature of the
provided ara::crypto::cryp::PrivateKey is not set.
• kIncompatibleObject error, if the provided ara::crypto::cryp::Pri-
vateKey belongs to a different ara::crypto::cryp::CryptoProvider in-
stance.
• kIncompatibleObject error, if the ara::crypto::CryptoAlgId of the
provided ara::crypto::cryp::PrivateKey is not compatible with the
ara::crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01821]{DRAFT} dThe interface ara::crypto::cryp::Verifier-
PublicCtx::SetKey shall ensure the provided ara::crypto::cryp::Pub-
licKey is used in the following signature verification. The interface shall return
• kUsageViolation error, if the allowed usage flag kAllowVerification of
the provided ara::crypto::cryp::PublicKey is not set.
• kIncompatibleObject error, if the provided ara::crypto::cryp::Pub-
licKey belongs to a different ara::crypto::cryp::CryptoProvider in-
stance.
• kIncompatibleObject error, if the ara::crypto::CryptoAlgId of the
provided ara::crypto::cryp::PublicKey is not compatible with the ara:-
:crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01822]{DRAFT} dThe interface ara::crypto::cryp::SigEn-
codePrivateCtx::SetKey shall ensure the provided ara::crypto::cryp::-
PrivateKey is used in the following signature generation with message encoding.
The interface shall return
• kUsageViolation error, if the allowed usage flag kAllowSignature of the
provided ara::crypto::cryp::PrivateKey is not set.
• kIncompatibleObject error, if the provided ara::crypto::cryp::Pri-
vateKey belongs to a different ara::crypto::cryp::CryptoProvider in-
stance.

79 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kIncompatibleObject error, if the ara::crypto::CryptoAlgId of the

provided ara::crypto::cryp::PrivateKey is not compatible with the
ara::crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02207)
[SWS_CRYPT_01823]{DRAFT} dThe interface ara::crypto::cryp::MsgRecov-
eryPublicCtx::SetKey shall ensure the provided ara::crypto::cryp::Pub-
licKey is used in the following signature verification with message decoding. The
interface shall return
• kUsageViolation error, if the allowed usage flag kAllowVerification of
the provided ara::crypto::cryp::PublicKey is not set.
• kIncompatibleObjecterror, if the provided ara::crypto::cryp::Pub-
licKey belongs to a different ara::crypto::cryp::CryptoProvider in-
stance.
• kIncompatibleObject error, if the ara::crypto::CryptoAlgId of the
provided ara::crypto::cryp::PublicKey is not compatible with the ara:-
:crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02207)
[SWS_CRYPT_02415]{DRAFT} Pre-hashed signing dThe interfaces ara::-
crypto::cryp::SignerPrivateCtx::SignPreHashed and ara::crypto::-
cryp::SignerPrivateCtx::SignPreHashed shall implement the signing algo-
rithm configured for this context without hashing. Note: hashing has already been
applied by the user. Both interfaces shall return
• kProcessingNotFinished , if a ara::crypto::cryp::HashFunc-
tionCtx has been supplied and the hash value computation has not been fin-
ished.
• kUninitializedContext , if ara::crypto::cryp::SignerPrivate-
Ctx::SetKey was not called before.
• kInvalidInputSize , if the supplied ara::crypto::ReadOnlyMemRegion
parameter, hashValue or context is incompatible with the configured signature
algorithm.
• kInvalidArgument , if the ara::crypto::CryptoAlgId of the provided
ara::crypto::cryp::HashFunctionCtx or the directly provided ara::-
crypto::CryptoAlgId is incompatible with the configured signature algo-
rithm.
c(RS_CRYPTO_02204)
[SWS_CRYPT_02416]{DRAFT} Signing dThe interface ara::crypto::cryp::-
SignerPrivateCtx::Sign shall implement the signing algorithm configured for this
context. The interface shall return

80 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kUninitializedContext, if ara::crypto::cryp::SignerPrivate-
Ctx::SetKey was not called before.
• kInvalidInputSize, if a supplied ara::crypto::ReadOnlyMemRegion
parameter’s size is incompatible with the configured signature algorithm.
c(RS_CRYPTO_02204)
[SWS_CRYPT_02417]{DRAFT} Pre-hashed verification dThe functions ara::-
crypto::cryp::VerifierPublicCtx::VerifyPrehashed, ara::crypto::-
cryp::VerifierPublicCtx::VerifyPrehashed and ara::crypto::cryp:-
:VerifierPublicCtx::VerifyPrehashed shall implement the verification algo-
rithm configured for this context without hashing. Note: hashing has already been
applied by the user. All interfaces shall return
• kProcessingNotFinished, if a ara::crypto::cryp::HashFunc-
tionCtx has been supplied and the hash value computation has not been
finished.
• kUninitializedContext, if ara::crypto::cryp::VerifierPublic-
Ctx::SetKey was not called before.
• kInvalidInputSize, if the supplied ara::crypto::ReadOnlyMemRegion
parameter hashValue or context or signature is incompatible with the con-
figured signature algorithm.
• kInvalidArgument, if the ara::crypto::CryptoAlgId of the provided
ara::crypto::cryp::HashFunctionCtx or the directly provided ara::-
crypto::CryptoAlgId is incompatible with the configured signature algo-
rithm.
• kIncompatibleObject, if the ara::crypto::CryptoAlgId of this context
does not match the ara::crypto::CryptoAlgId of signature; or the required
ara::crypto::CryptoAlgId of the hash is not kAlgIdDefault and the
required hash ara::crypto::CryptoAlgId of this context does not match
hashAlgId or the hash ara::crypto::CryptoAlgId of signature.
• kIncompatibleArguments, if the provided hash ara::crypto::Cryp-
toAlgId is not kAlgIdDefault and the ara::crypto::CryptoAlgId of
the provided signature object does not match the provided hash ara::-
crypto::CryptoAlgId.
• kBadObjectReference, if the provided signature object does not reference the
public key loaded to the context, i.e. if the COUID of the public key in the context
is not equal to the COUID referenced from the signature object.
c(RS_CRYPTO_02204)
[SWS_CRYPT_02418]{DRAFT} Truncation of hash value dThe functions
ara::crypto::cryp::VerifierPublicCtx::VerifyPrehashed and ara::-
crypto::cryp::SignerPrivateCtx::SignPreHashed shall truncate the pro-
vided hash value, if the bitlength of the provided hash value is larger than the bitlength

81 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

used for signing/verification or if the configured algorithm ara::crypto::Cryp-

toAlgId used to instantiate this context) allows the use of a hash-value with the
provided bitlength and specifies a truncation.c(RS_CRYPTO_02204)
[SWS_CRYPT_02419]{DRAFT} Signing dThe interface ara::crypto::cryp::-
VerifierPublicCtx::Verify shall implement the verification algorithm configured
for this context. The interface shall return
• kUninitializedContext, if ara::crypto::cryp::VerifierPublic-
Ctx::SetKey was not called before.
• kInvalidInputSize, if a supplied ara::crypto::ReadOnlyMemRegion
parameter’s size is incompatible with the configured signature algorithm.
c(RS_CRYPTO_02204)
[SWS_CRYPT_02421]{DRAFT} dThe interface ara::crypto::cryp::MsgRecov-
eryPublicCtx::DecodeAndVerify shall decode the message from the provided
signature and return the message after successful verification according to the config-
ured context ara::crypto::CryptoAlgId.c(RS_CRYPTO_02204)
Note: algorithms that compute a signature over a short message allow to embedd
the message inside of the signature. Similarly, the reverse algorithms first decode the
message and return it only after successful verification.
[SWS_CRYPT_02420]{DRAFT} dThe interface ara::crypto::cryp::SigEn-
codePrivateCtx::SignAndEncode shall sign the provided input buffer (message)
and encode the message into the generated signature according to the algorithm con-
figured for this context. The interface shall return this signature with encoded message
as a vector of bytes or
• kInvalidInputSize, if the provided message data is larger than allowed by
the configured context ara::crypto::CryptoAlgId.
• kUninitializedContext, if ara::crypto::cryp::SigEncodePrivate-
Ctx::SetKey has not been called before.
c(RS_CRYPTO_02204)
[SWS_CRYPT_40984]{DRAFT} dThe interface ara::crypto::cryp::SigEn-
codePrivateCtx::GetMaxInputSize shall return the maximum byte-length of the
message that can be signed while also encoding it into the generated signature. If
the provided parameter suppressPadding equals TRUE, only the number of Bytes
available for the message shall be returned. If suppressPadding equals FALSE, the
returned number shall equal the supported block size.c(RS_CRYPTO_02309)
[SWS_CRYPT_02422]{DRAFT} dThe interface ara::crypto::cryp::MsgRecov-
eryPublicCtx::DecodeAndVerify shall decode the message from the provided
signature and return the message only after successful verification according to the
algorithm configured for this context. The interface shall return

82 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kInvalidInputSize, if the provided signature data is incomplete. Note: the

configured context ara::crypto::CryptoAlgId expects more data than pro-
vided.
• kUninitializedContext, if ara::crypto::cryp::MsgRecoveryPub-
licCtx::SetKey has not been called before.
• kAuthTagNotValid, if decoded message could not be verified.
c(RS_CRYPTO_02204)
The context is generated with an algorithm identifier as specified in chapter 7.5.

7.4.1.9 Asymmetric encryption

Asymmetric encryption, asymmetric cryptography, or public key cryptography is a sys-

tem, which is based on a pair of keys, public key and private key. As the name suggest,
a public key can be distributed public to everyone without losing secrecy. Instead, a
private key must be kept secret. Compared to symmetric cryptography, every user, who
possesses the public key, can encrypt information, but only the user with the private
key can decrypt the information.
[SWS_CRYPT_02700]{DRAFT} Separation of asymmetric transformation direc-
tions dThe ara::crypto::cryp::EncryptorPublicCtx shall implement the
asymmetric encryption operation of a Plaintext to a Ciphertext. The ara::-
crypto::cryp::DecryptorPrivateCtx shall implement the asymmetric decryp-
tion operation of a Ciphertext to a Plaintext. It shall be possible to use both
contexts independently.c(RS_CRYPTO_02202)
The separation of the encryption and decryption context allows an application or Func-
tional Cluster to encrypt or decrypt independently based on their needs. When
an application or Functional Cluster need both, encryption and decryption, it has
to setup both contexts.
[SWS_CRYPT_02701]{DRAFT} Creation of DecryptorPrivateCtx and Encryptor-
PublicCtx dThe interface ara::crypto::cryp::CryptoProvider::CreateDe-
cryptorPrivateCtx shall return an instance of ara::crypto::cryp::Decryp-
torPrivateCtx implementing the algorithm specified by the provided parameter
ara::crypto::CryptoAlgId. The interface shall return
• kUnknownIdentifier, if the provided ara::crypto::CryptoAlgId is not
supported.
• kInvalidArgument, if the provided ara::crypto::CryptoAlgId is sup-
ported but does not refer assymetric decryption hashing.
c(RS_CRYPTO_02202)
The ara::crypto::CryptoAlgId is the implementation specific identifier that rep-
resents the algorithm name, as described in chapter 7.5. With this identifier the context

83 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

is setup matching the asymmetric algorithm. Here, the setup can influence the orga-
nization of the cryptographic material, the provided internal buffers for keys, input, or
output data and the buffers length. Some asymmetric cryptographic algorithms need
specific initialization parameters. All the specific needs of an asymmetric algorithm, the
corresponding standards gives detailed insights how to setup internally the Crypto
Provider and its supported Cryptographic primitives.
The Key Storage Provider generates and manages the key as described in chap-
ter 7.4.2.2. The key can either be generated or configured in the context of the appli-
cation or Functional Cluster. When the FC Crypto provides the context no key
is given. The application or Functional Cluster will provide the key. The key itself
contains also the encoding as an attribute and will not provided by the application or
Functional Cluster in the call of the CryptoAPI method.
[SWS_CRYPT_02702]{DRAFT} dThe ara::crypto::cryp::EncryptorPublic-
Ctx::SetKey shall check the allowed-usage flags of the key parameter provided. If
kAllowDataEncryption is not set, a kUsageViolation error shall be returned.
c(RS_CRYPTO_02202)
[SWS_CRYPT_02703]{DRAFT} dThe ara::crypto::cryp::DecryptorPriva-
teCtx::SetKey shall check the allowed-usage flags of the key parameter provided.
If kAllowDataDecryption is not set, a kUsageViolation error shall be returned.c
(RS_CRYPTO_02202)
[SWS_CRYPT_02704]{DRAFT} Encrypting dThe interfaces ara::crypto:-
:cryp::EncryptorPublicCtx::ProcessBlock, ara::crypto::cryp::En-
cryptorPublicCtx::ProcessBlock shall execute the encryption operation using
the deployed public key.c(RS_CRYPTO_02202)
[SWS_CRYPT_02705]{DRAFT} Decrypting dThe interface ara::crypto:-
:cryp::DecryptorPrivateCtx::ProcessBlock, ara::crypto::cryp::De-
cryptorPrivateCtx::ProcessBlock shall execute the decryption operation us-
ing the deployed public key.c(RS_CRYPTO_02202)
[SWS_CRYPT_02706]{DRAFT} dIf the parameter suppressPadding is set to
FALSE, the interface ara::crypto::cryp::EncryptorPublicCtx::Process-
Block shall add padding as specified by the ara::crypto::CryptoAlgId. If
the parameter suppressPadding is set to TRUE, the interface ara::crypto::-
cryp::EncryptorPublicCtx::ProcessBlock shall not add any padding.c(RS_-
CRYPTO_02202)
If a padding shall be applied or how the padding layout looks like, this is encoded in the
common name, as described in chapter 7.5.
[SWS_CRYPT_02726]{DRAFT} Errors of ProcessBlock dThe functions ara:-
:crypto::cryp::DecryptorPrivateCtx::ProcessBlock, ara::crypto::-
cryp::DecryptorPrivateCtx::ProcessBlock shall return
• kUninitializedContext error, if ara::crypto::cryp::EncryptorPub-
licCtx::SetKey was not called before.

84 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kInvalidInputSize error, if suppressPadding is set to TRUE and the user

provided insufficient data.
c(RS_CRYPTO_02202)

7.4.1.10 Key Encapsulation Mechanism (KEM)

Briefly, a key encapsulation mechanism (KEM) works just like a public-key encryption
scheme, except that the encryption algorithm takes no input other than another key.
Therefore, the KEM uses randomly generated Key Material, the key encryption key
(KEK), to encapsulate an input, in this situation a key. The input is encapsulated with
an encryption with a target public key, as given in [26], [27], and [28]. The KEK can be
derived from the encapsulated Key Material or from randomly generated data by
application of a KDF.
[SWS_CRYPT_03000]{DRAFT} Keying-Data dThe interface ara::crypto::-
cryp::KeyEncapsulatorPublicCtx::AddKeyingData shall set the provided
ara::crypto::cryp::RestrictedUseObject as payload to be encapsulated
(keying-data). The interface shall return
• kUsageViolation, if the allowed usage flag kAllowExport of the provided
ara::crypto::cryp::RestrictedUseObject is not set.
• kIncompatibleObject, if the provided ara::crypto::cryp::Restrict-
edUseObject belongs to a different ara::crypto::cryp::Crypto-
Provider instance.
• kInvalidInputSize, if the size of the provided ara::crypto::cryp::-
RestrictedUseObject is not supported by the configured ara::crypto:-
:CryptoAlgId of this context.
c(RS_CRYPTO_02209)
[SWS_CRYPT_03002]{DRAFT} Encapsulation dThe interface ara::crypto:-
:cryp::KeyEncapsulatorPublicCtx::Encapsulate shall execute key-
encapsulation according to the configured ara::crypto::CryptoAlgId of this
context. If the context allows specifying the used key-derivation function and/or
the key-encapsulation-key (KEK) primitive, the interface shall override the initial
context configuration with the provided ara::crypto::cryp::KeyDerivation-
FunctionCtx and ara::crypto::CryptoAlgId. The interface shall return a
byte-vector containing the encapsulated keying-data or
• kUninitializedContext, if ara::crypto::cryp::KeyEncapsulator-
PublicCtx::SetKey and ara::crypto::cryp::KeyEncapsulatorPub-
licCtx::AddKeyingData have not been called successfully before.
• kInvalidArgument, if the provided ara::crypto::cryp::KeyDeriva-
tionFunctionCtx or ara::crypto::CryptoAlgId are incompatible with
the configured ara::crypto::CryptoAlgId of this context.

85 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

c(RS_CRYPTO_02209)
[SWS_CRYPT_03003]{DRAFT} Key Decapsulation dThe interface ara::crypto:-
:cryp::KeyDecapsulatorPrivateCtx::DecapsulateKey shall execute key-
decapsulation on the provided ara::crypto::ReadOnlyMemRegion according to
the configured ara::crypto::CryptoAlgId of this context. If the context al-
lows specifying the used key-derivation function and/or the key-encapsulation-key
(KEK) primitive, the interface shall override the initial context configuration with
the provided ara::crypto::cryp::KeyDerivationFunctionCtx and ara::-
crypto::CryptoAlgId (kekAlgId). The interface shall return a non-exportable, non-
storable instance of ara::crypto::cryp::SymmetricKey representing the de-
capsulated keying-data with usage restrictions set according to the provided ara:-
:crypto::AllowedUsageFlags or kAllowKdfMaterialAnyUsage, if ara::-
crypto::AllowedUsageFlags are not provided. The returned object’s ara::-
crypto::CryptoAlgId shall be set to the provided ara::crypto::CryptoAlgId
(keyingDataAlgId). The interface shall return
• kUninitializedContext, if ara::crypto::cryp::KeyEncapsulator-
PublicCtx::SetKey has not been called successfully before.
• kInvalidArgument, if the provided ara::crypto::cryp::KeyDeriva-
tionFunctionCtx or ara::crypto::CryptoAlgId are incompatible with
the configured ara::crypto::CryptoAlgId of this context.
• kInvalidInputSize, if the size of the provided ara::crypto::ReadOnly-
MemRegion is not supported by the configured ara::crypto::CryptoAlgId
of this context.
c(RS_CRYPTO_02209)
[SWS_CRYPT_03004]{DRAFT} Seed Decapsulation dThe interface ara::-
crypto::cryp::KeyDecapsulatorPrivateCtx::DecapsulateSeed shall ex-
ecute key-decapsulation on the provided ara::crypto::ReadOnlyMemRegion ac-
cording to the configured ara::crypto::CryptoAlgId of this context. The inter-
face shall return a non-exportable, non-storable instance of ara::crypto::cryp:-
:SecretSeed representing the decapsulated keying-data with usage restrictions set
according to the provided ara::crypto::AllowedUsageFlags or kAllowKdfMa-
terialAnyUsage, if ara::crypto::AllowedUsageFlags are not provided. The
returned object’s ara::crypto::CryptoAlgId shall be set to the ara::crypto:-
:CryptoAlgId of this context. The interface shall return
• kUninitializedContext, if ara::crypto::cryp::KeyEncapsulator-
PublicCtx::SetKey has not been called successfully before.
• kInvalidInputSize, if the size of the provided ara::crypto::ReadOnly-
MemRegion is not supported by the configured ara::crypto::CryptoAlgId
of this context.
c(RS_CRYPTO_02209)

86 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_03005]{DRAFT} dThe interface ara::crypto::cryp::KeyDecap-

sulatorPrivateCtx::SetKey shall ensure the provided ara::crypto::cryp:-
:PrivateKey is used in the following key decapsulation. The interface shall return
• kUsageViolation, if the allowed usage flag kAllowKeyImporting of the
provided ara::crypto::cryp::PrivateKey is not set.
• kIncompatibleObject, if the provided ara::crypto::cryp::Pri-
vateKey belongs to a different ara::crypto::cryp::CryptoProvider
instance.
• kIncompatibleObject, if the ara::crypto::CryptoAlgId of the pro-
vided ara::crypto::cryp::PrivateKey is not compatible with the ara:-
:crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02209)
[SWS_CRYPT_03006]{DRAFT} dThe interface ara::crypto::cryp::KeyEncap-
sulatorPublicCtx::SetKey shall ensure the provided ara::crypto::cryp:-
:PublicKey is used in the following key encapsulation. The interface shall return
• kUsageViolation, if the allowed usage flag kAllowKeyExporting of the
provided ara::crypto::cryp::PublicKey is not set.
• kIncompatibleObject, if the provided ara::crypto::cryp::PublicKey
belongs to a different ara::crypto::cryp::CryptoProvider instance.
• kIncompatibleObject, if the ara::crypto::CryptoAlgId of the pro-
vided ara::crypto::cryp::PublicKey is not compatible with the ara::-
crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02209)
[SWS_CRYPT_03007]{DRAFT} dThe interfaces ara::crypto::cryp::KeyEn-
capsulatorPublicCtx::GetKekEntropy and ara::crypto::cryp::KeyDe-
capsulatorPrivateCtx::GetKekEntropy shall return the entropy of the key en-
capsulation key (KEK) in bits, if a KEK is available or the expected entropy can be com-
puted before KEK generation. The interfaces shall return 0 otherwise.c(RS_CRYPTO_-
02209)
[SWS_CRYPT_03008]{DRAFT} dThe interfaces ara::crypto::cryp::KeyEn-
capsulatorPublicCtx::GetEncapsulatedSize and ara::crypto::cryp:-
:KeyDecapsulatorPrivateCtx::GetEncapsulatedSize shall return the size
of the encapsulated keying-data in Bytes. The interfaces shall return 0, if the size
is unknown at this time, because
• the configured KEM algorithm does not specify a fixed size.
• the keying-data has not been set yet (encapsulation).
• the encapsulated data has not been provided yet (decapsulation).
c(RS_CRYPTO_02209)

87 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_03009]{DRAFT} dThe interfaces ara::crypto::cryp::KeyEn-

capsulatorPublicCtx::GetExtensionService and ara::crypto::cryp:-
:KeyDecapsulatorPrivateCtx::GetExtensionService shall return an in-
stance of ara::crypto::cryp::ExtensionService that provides information on
the configuration of this context at the time the interface was called.c(RS_CRYPTO_-
02209)

7.4.1.11 Key Exchange Protocol, Key Exchange Mechanism, and Key Exchange
Scheme

Key Material is an essential element of cryptographic algorithms. Therefore, Key

Material must either be ephemeral (i.e. only temporary) or must be stored persis-
tently in confidential form to ensure it is kept secret. This avoids exposure and mis-
suse. However, there are situations when Key Material must be exchanged without
actually transmitting the secret (key-material) itself. One example for this is secure
communication using symmetric cryptography in the presence of untrusted communi-
cation networks and dynamic connections (i.e. communication partners are not known
in advance). In such situations the Diffie-Hellman key exchange scheme [29] is the
common used key agreement mechanism.
[SWS_CRYPT_03311]{DRAFT} Encryption algorithm dThe FC Crypto shall pro-
vide an encryption algorithm, which matches the chosen public-private key pair and
the key exchange schema.c(RS_CRYPTO_02101)
[SWS_CRYPT_03300]{DRAFT} Ephemeral key usage dThe interface ara:-
:crypto::cryp::CryptoProvider::GeneratePrivateKey shall support the
generation of ara::crypto::cryp::PrivateKey instances of primitive types
matching the ara::crypto::CryptoAlgId provided as part of a successful call
to ara::crypto::cryp::CryptoProvider::CreateKeyAgreementPrivate-
Ctx.c(RS_CRYPTO_02101)
Note: if a specific algorithm for key agreement is supported by the stack, then also the
generation of matching key-material shall be supported to enable ephemeral usage of
this scheme.
The Key Storage Provider generates and manages the key as described in chap-
ter 7.4.2.2.
[SWS_CRYPT_03312]{DRAFT} SetKey dThe interface ara::crypto::cryp::-
KeyAgreementPrivateCtx::SetKey shall ensure the provided ara::crypto:-
:cryp::PrivateKey is used in the following key agreement. The interface shall
return
• kUsageViolation, if the allowed usage flag kAllowKeyAgreement of the
provided ara::crypto::cryp::PrivateKey is not set.

88 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kIncompatibleObject, if the provided ara::crypto::cryp::Pri-

vateKey belongs to a different ara::crypto::cryp::CryptoProvider
instance.
• kIncompatibleObject, if the ara::crypto::CryptoAlgId of the pro-
vided ara::crypto::cryp::PrivateKey is not compatible with the ara:-
:crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02102)
[SWS_CRYPT_03313]{DRAFT} dThe interface ara::crypto::cryp::KeyAgree-
mentPrivateCtx::GetExtensionService shall return an instance of ara::-
crypto::cryp::ExtensionService that provides information on the configuration
of this context at the time the interface was called.c(RS_CRYPTO_02103)
Key agreement requires as input the public key of the communication partner (other
side). To retrieve an instance of ara::crypto::cryp::PublicKey represent-
ing the public key received from the communication partner, the interface ara::-
crypto::cryp::CryptoProvider::ImportPublicObject can be used. Simi-
larly, the communication partner requires the public key of the local application. To
send this public data the interface ara::crypto::Serializable::ExportPub-
licly can be used to retrieve the raw data of the public key. Each ara::crypto::-
cryp::PublicKey instance provides this interface.
While the scheme specified here is termed ”key agreement”, what is actually agreed
(or exchanged) is a common shared secret. How this secret data is obtained and used
is up to the application. Therefore, the ara::crypto::cryp::KeyAgreementPri-
vateCtx provides two dedicated interfaces to generate a shared secret used for secret
seeding or as key-material.
[SWS_CRYPT_03301]{DRAFT} Seed agreement dThe interface ara::crypto::-
cryp::KeyAgreementPrivateCtx::AgreeSeed shall execute the key agreement
scheme specified at the creation of this context using the provided ara::crypto:-
:cryp::PublicKey. The interface shall return a non-exportable, non-storable in-
stance of ara::crypto::cryp::SecretSeed representing the calculated shared
secret and restrict the object allowed usage according to the provided allowed us-
age flags or to kAllowKdfMaterialAnyUsage, in case allowed usage flags are not
provided. The returned object’s ara::crypto::CryptoAlgId shall be set to the
ara::crypto::CryptoAlgId of this context. The interface shall return
• kUninitializedContext, if ara::crypto::cryp::KeyAgreementPri-
vateCtx::SetKey was not successfully called before.
• kIncompatibleObject, if the provided ara::crypto::cryp::PublicKey
belongs to a different ara::crypto::cryp::CryptoProvider instance.
• kIncompatibleObject, if the ara::crypto::CryptoAlgId of the pro-
vided ara::crypto::cryp::PublicKey is not compatible with the ara::-
crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02104)

89 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_03302]{DRAFT} Key agreement dThe interface ara::crypto::-

cryp::KeyAgreementPrivateCtx::AgreeKey shall execute the key agreement
scheme specified at the creation of this context using the provided ara::crypto:-
:cryp::PublicKey and return a non-exportable, non-storable instance of ara::-
crypto::cryp::SymmetricKey. The returned ara::crypto::cryp::Symmet-
ricKey shall be restricted according to the provided allowed usage flags as well as to
the provided ara::crypto::CryptoAlgId. The interface shall return
• kUninitializedContext, if ara::crypto::cryp::KeyAgreementPri-
vateCtx::SetKey was not successfully called before.
• kIncompatibleObject, if the provided ara::crypto::cryp::PublicKey
belongs to a different ara::crypto::cryp::CryptoProvider instance.
• kIncompatibleObject, if the ara::crypto::CryptoAlgId of the pro-
vided ara::crypto::cryp::PublicKey is not compatible with the ara::-
crypto::CryptoAlgId used to instantiate this context.
c(RS_CRYPTO_02105)
[SWS_CRYPT_03303]{DRAFT} Key agreement - no KDF dIf the transformation
specified by the AlgId used to create this context does not include a KDF and
no ara::crypto::cryp::KeyDerivationFunctionCtx is explicitly provided by
calling ara::crypto::cryp::KeyAgreementPrivateCtx::SetKDF, the inter-
face ara::crypto::cryp::KeyAgreementPrivateCtx::AgreeKey and ara:-
:crypto::cryp::KeyAgreementPrivateCtx::AgreeSeed shall return the cal-
culated shared secret. Otherwise the output of key-derivation using the shared secret
as input shall be returned.c(RS_CRYPTO_02105)
[SWS_CRYPT_03304]{DRAFT} Key agreement - optional call parameters dThe
interface ara::crypto::cryp::KeyAgreementPrivateCtx::AgreeKey shall
only process the optionally provided parameters ara::crypto::ReadOnlyMemRe-
gion Salt and ara::crypto::ReadOnlyMemRegion ctxLabel, if required by the
configured ara::crypto::CryptoAlgId of this context. If such parameters are re-
quired, but not provided, an empty value shall be used.c(RS_CRYPTO_02105)
[SWS_CRYPT_03305]{DRAFT} Key agreement - KDF dThe interface ara::-
crypto::cryp::KeyAgreementPrivateCtx::SetKDF shall configure this con-
text to derive the final ara::crypto::cryp::SymmetricKey or ara::crypto::-
cryp::SecretSeed using the provided ara::crypto::cryp::KeyDerivation-
FunctionCtx from the computed shared secret.c(RS_CRYPTO_02115)

7.4.1.12 Identification of cryptographic primitives and using one

Cryptographic primitives are the basic building blocks of cryptographic sys-

tems. These well-established and frequently used elements can be implemented in
hardware or software. Every implementation can be independent from each other
and provided by different vendors. Implementations are represented by Crypto

90 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

Provider. This kind of decoupling provides some negative impacts. Every ven-
dor can choose the Cryptographic primitives and their names independently.
Then, during development phase of application or Functional Cluster, it is not
clear how to access the needed algorithm. Therefore, a common name is specified,
which allows to develop functionality independent from FC Crypto. The common
name of the algorithm is given in chapter 7.5. With this common name, it is possible
to bind the application or function cluster to the FC Crypto during integration phase.
However, this approaches needs both, the interface to translate the common name to
a vendor specific name and the support from the FC Crypto.
[SWS_CRYPT_03904]{DRAFT} dThe ara::crypto::cryp::CryptoContext::-
GetCryptoPrimitiveId shall return a ara::crypto::cryp::CryptoPrimi-
tiveId of the current used cryptographic algorithm.c(RS_CRYPTO_02308)
[SWS_CRYPT_03905]{DRAFT} dThe ara::crypto::cryp::CryptoPrimi-
tiveId::GetPrimitiveName shall return the common name of the current used
cryptographic algorithm.c(RS_CRYPTO_02308)
[SWS_CRYPT_03906]{DRAFT} dThe ara::crypto::cryp::CryptoPrimi-
tiveId::GetPrimitiveId shall return the ara::crypto::cryp::Crypto-
PrimitiveId of the current used cryptographic algorithm.c(RS_CRYPTO_02308)
This allows a decoupling of the vendor specific implementation and the using applica-
tion. With this freedom a late binding during integration phase is realized.
[SWS_CRYPT_40985]{DRAFT} dThe interface ara::crypto::cryp::Cryp-
toService::GetMaxInputSize shall return the maximum byte-length of data that
the cryptographic context associated with this ara::crypto::cryp::CryptoSer-
vice expects as input for applying its cryptographic transformation. If the provided
parameter suppressPadding equals TRUE, only the number of Bytes available for
the payload shall be returned. If suppressPadding equals FALSE, the returned
number shall equal the supported block size.c(RS_CRYPTO_02309)
Note, several encryption algorithms require a certain number of bytes to be added as
padding to improve cryptographic properties (e.g. RSA encryption PKCS1 v1.5)

7.4.1.13 Support on internal elements (Loading, Update, Import, and Export)

[SWS_CRYPT_04200]{DRAFT} Loading cryptographic material dThe load

interfaces ara::crypto::cryp::CryptoProvider::LoadObject, ara::-
crypto::cryp::CryptoProvider::LoadSymmetricKey, ara::crypto::-
cryp::CryptoProvider::LoadPublicKey, ara::crypto::cryp::Crypto-
Provider::LoadPrivateKey, ara::crypto::cryp::CryptoProvider::-
LoadSecretSeed shall load the content from the location pointed to by the provided
IOInterface and return an instance of type CryptoObject, Symmetric Key, PublicKey,
PrivateKey and SecretSeed respectively. The load interface shall return

91 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kEmptyContainer, if the underlying resource this IOInterface points to is empty.

• kResourceFault , if the underlying resource this IOInterface points to is faulty.
• kModifiedResource , if the underlying resource has been modified after the
IOInterface has been opened, i.e., the IOInterface has been invalidated.
• kIncompatibleObject , if the underlying resource belongs to another incom-
patible CryptoProvider or if the type of the crypto object to be returned by the re-
spective interface does not match the type contained in the underlying resource.
c(RS_CRYPTO_02105, RS_CRYPTO_02112, RS_CRYPTO_02113)
[SWS_CRYPT_40947]{DRAFT} dThe interface ara::crypto::IOInterface::-
GetAllowedUsage shall return the allowed usage flags of the underlying CryptoOb-
ject this IOInterface points to. If the content that the IOInterface points to is empty,
kAllowPrototypedOnly shall be returned.c(RS_CRYPTO_02004)
[SWS_CRYPT_40948]{DRAFT} dThe interface ara::crypto::IOInterface::-
GetCapacity shall return capacity of the underlying resource in bytes.c(RS_-
CRYPTO_02004)
Note: IOInterfaces always point to an underlying resource to store CryptoObjects such
as the RAM buffer of a VolatileTrustedContainer or the persistent memory of a KeySlot.
In both cases the underlying resource has a maximum capacity to store a CryptoObject
and the content may be empty.
[SWS_CRYPT_40949]{DRAFT} dThe interface ara::crypto::IOInterface::-
GetCryptoObjectType shall return the CryptoObjectType of the underlying Cryp-
toObject this IOInterface points to. In case the underlying resource this IOInterface
points to is empty, kUndefined shall be returned.c(RS_CRYPTO_02004)
[SWS_CRYPT_40950]{DRAFT} dThe interface ara::crypto::IOInterface::-
GetPayloadSize shall return size of the underlying CryptoObject’s key-material this
IOInterface points to in bytes. The interface shall return 0, if the container is empty.c
(RS_CRYPTO_02004)
[SWS_CRYPT_40951]{DRAFT} dThe interface ara::crypto::IOInterface::-
GetPrimitiveId shall return the vendor specific ara::crypto::CryptoAlgId of
the underlying CryptoObject this IOInterface points to. If the underlying resource this
IOInterface points to is empty, kAlgIdUndefined shall be returned.c(RS_CRYPTO_-
02004)
[SWS_CRYPT_40952]{DRAFT} dThe interface ara::crypto::IOInterface::-
GetTypeRestriction shall return the CryptoObjectType that is allwed to be stored
in the underlying resource this IOInterface points to. The interface shall return kUnde-
fined
• if this IOInterface points to a VolatileTrustedContainer.
• if this IOInterface points to a Key Slot and the KeySlot’s mAllowContent-
TypeChange flag is set to TRUE.

92 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

c(RS_CRYPTO_02004)
[SWS_CRYPT_40953]{DRAFT} dThe interface ara::crypto::IOInterface::-
IsObjectExportable shall only return TRUE, if kAllowExport is set in the al-
lowed usage flags of the CryptoObject stored in the underlying resource this IOInter-
face points to.c(RS_CRYPTO_02004)
[SWS_CRYPT_40954]{DRAFT} dThe interface ara::crypto::IOInterface::-
IsObjectSession shall return TRUE, if the CryptoObject stored in the underlying
resource this IOInterface points to is volatile and cannot be persisted (session flag set).
The interface shall return FALSE, if the underlying resource this IOInterface points to
• is a Key Slot.
• is is empty.
• is volatile but can be persisted.
c(RS_CRYPTO_02004)
[SWS_CRYPT_40955]{DRAFT} dThe interface ara::crypto::IOInterface::-
IsValid shall only return TRUE, if the underlying resource this IOInterface points to
is a VolatileTrustedContainer or a KeySlot that has not been modified since this IOInt-
erface has been obtained by calling ara::crypto::keys::KeySlot::Open on the
loaded KeySlot instance.c(RS_CRYPTO_02004)
[SWS_CRYPT_40956]{DRAFT} dThe interface ara::crypto::IOInterface::-
IsVolatile shall only return TRUE, if this IOInterface points to a VolatileTrusted-
Container.c(RS_CRYPTO_02004)
[SWS_CRYPT_40957]{DRAFT} dThe interface ara::crypto::IOInterface::-
IsWritable shall only return TRUE, if this IOInterface points to a VolatileTrusted-
Container or this IOInterface has been obtained by calling ara::crypto::keys::-
KeySlot::Open with the writable flag set to TRUE.c(RS_CRYPTO_02004)
The serialization format for exporting/importing is not yet standardized in AUTOSAR.
Therefore it is the responsibility of the platform vendor to adequately de-/serialize Cryp-
toObjects including all relevant meta-data such that CryptoObjects can be transferred
between adaptive machines (of the same vendor) without loss of information and func-
tionality.
[SWS_CRYPT_04202]{DRAFT} Exporting secure objects dThe function ara::-
crypto::cryp::CryptoProvider::ExportSecuredObject shall serialize the
provided CryptoObject and apply the transformation specified by the provided Sym-
metricKeyWrapperCtx. The function shall return the serialized data as a vector of bytes
or
• kIncompatibleObject if the object cannot be exported due to ara::-
crypto::cryp::CryptoObject::IsExportable returning FALSE.

93 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• kIncompleteArgState if the provided SymmetricKeyWrapperCtx is not fully

initialized.
• kIncompatibleObject if the flag kAllowKeyExporting of the Symmetric Key
set in the provided SymmetricKeyWrapperCtx is not set to TRUE
c(RS_CRYPTO_02004)
[SWS_CRYPT_04213]{DRAFT} dThe function ara::crypto::cryp::Crypto-
Provider::ExportSecuredObject shall serialize the CryptoObject contained in
the storage location pointed to by the provided IOInterface after applying the transfor-
mation specified by the provided SymmetricKeyWrapperCtx. The function shall return
the serialized data as a vector of bytes or
• kEmptyContainer if the underlying resource this IOInterface points to is empty
• kIncompleteArgState if the provided SymmetricKeyWrapperCtx is not fully
initialized
• kIncompatibleObject if the flag kAllowKeyExporting of the Symmetric Key
set in the provided SymmetricKeyWrapperCtx is not set
• kModifiedResource if this IOInterface points to an instance of a KeySlot that
has been modified after the IOInterface has been opened.
c(RS_CRYPTO_02006)
[SWS_CRYPT_04203]{DRAFT} Exporting public objects dThe function ara:-
:crypto::cryp::CryptoProvider::ExportPublicObject shall serialize the
CryptoObject contained in the storage location pointed to by the provided IOInterface.
The function shall return the serialized data as a vector of bytes or
• kEmptyContainer if the underlying resource this IOInterface points to is empty.
• kUnexpectedValue if the underlying resource this IOInterface points contains
a RestrictedUseObject.
• kModifiedResource if this IOInterface points to an instance of a KeySlot that
has been modified after the IOInterface has been opened.
c(RS_CRYPTO_02004)
Both ExportSecuredObject interfaces can export internal objects in a secure manner.
This allows exchanging cryptographic objects between platforms or different applica-
tions without exposing them to third parties.
[SWS_CRYPT_40958]{DRAFT} dThe function ara::crypto::cryp::CryptoOb-
ject::IsExportable shall only return TRUE, if kAllowExport is set in the allowed
usage flags of this CryptoObject.c(RS_CRYPTO_02006)

94 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_04204]{DRAFT} Importing secure objects dThe function ara:-

:crypto::cryp::CryptoProvider::ImportSecuredObject shall unwrap se-
curely serialized data provided by the application according to the specified Symmet-
ricKeyWrapperCtx. The unwrapped CryptoObject shall be deserialized and saved to
the persistent or volatile storage represented by the provided IOInterface. The function
shall return
• kUnexpectedValue if the payload (serialized CryptoObject) contains invalid
data (errors in the cipher-text or plain-text), or the unwrapping operation failed.
• kBadObjectType if the contained CryptoObject does not match the provided
CryptoObjectType.
• kIncompleteArgState if the provided SymmetricKeyWrapperCtx is not fully
initialized.
• kUsageViolation if the flag kAllowKeyImporting of the Symmetric Key set
in the provided SymmetricKeyWrapperCtx is not set to TRUE.
• kInsufficientCapacity if the capacity of the underlying resource pointed to
by the provided IOInterface is insufficient to hold the deserialized CryptoObject.
• kUnreservedResource if the IOInterface is not opened writable.
c(RS_CRYPTO_02004)
[SWS_CRYPT_04205]{DRAFT} Importing public objects dThe function ara::-
crypto::cryp::CryptoProvider::ImportPublicObject shall deserialize the
provided serialized data and save the contained CryptoObject to the persistent or
volatile storage represented by the provided IOInterface. The function shall return
• kUnexpectedValue if the payload (serialized CryptoObject and associated
meta-data) contains invalid data.
• kBadObjectType if the contained CryptoObject does not match the provided
exptected CryptoObjectType.
• kInsufficientCapacity if the capacity of the underlying resource pointed to
by the provided IOInterface is insufficient to hold the deserialized CryptoObject.
• kUnreservedResource if the IOInterface is not opened writable.
c(RS_CRYPTO_02004)
Vulnerability notice: using the interface ara::crypto::cryp::Crypto-
Provider::ImportPublicObject to import secret key-material without confi-
dentiality protection is strongly discouraged.
This is an obvious attack path and may compromise security of the whole platform. It is
assumed that all parties involved in such a setup are aware of the risk and implement
sufficient countermeasures.

95 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_04207]{DRAFT} dThe function ara::crypto::cryp::Crypto-

Provider::GetPayloadStorageSize shall return the minimum required capacity
of a KeySlot for storing a CryptoObject defined by the provided ara::crypto::-
CryptoAlgId and CryptoObjectType. The function shall return
• kUnknownIdentifier if the provided ara::crypto::CryptoAlgId is un-
supported or the provided ara::crypto::CryptoAlgId equals kUndefined.
• kIncompatibleArguments if the provided pair of ara::crypto::Cryp-
toAlgId and CryptoObjectType represents an unsupported combination.
c(RS_CRYPTO_02004)
[SWS_CRYPT_04208]{DRAFT} dThe function ara::crypto::cryp::Crypto-
Provider::AllocVolatileContainer shall allocate a volatile buffer with suffi-
cient size to hold cryptographic data of the provided capacity and the meta-data as-
sociated with each CryptoObject. The function shall return an instance of VolatileTrust-
edContainer representing the allocated buffer or kInsufficientResource, if not
enough volatile memory is available for allocation.c(RS_CRYPTO_02004)
This type of containers could be used for execution of import operations described
above.
[SWS_CRYPT_40959]{DRAFT} dThe function ara::crypto::cryp::Crypto-
Provider::AllocVolatileContainer shall allocate a volatile buffer with suffi-
cient size to hold cryptographic data and the meta-data associated with each Cryp-
toObject. The necessary size of cryptographic data shall be computed from the pro-
vided pair of ara::crypto::CryptoAlgId and CryptoObjectType. The function
shall return an instance of VolatileTrustedContainer representing the allocated buffer
or
• kInsufficientResource, if not enough volatile memory is available for allo-
cation
• kInvalidArgument if the provided pair of ara::crypto::CryptoAlgId and
CryptoObjectType represents an unsupported combination.
c(RS_CRYPTO_02004)
[SWS_CRYPT_04209]{DRAFT} dThe CryptoAPI shall document all importing or ex-
porting by a logging mechanism. This information can be queried.c(RS_CRYPTO_-
02004)

7.4.2 Key Storage Provider

The Key Storage Provider (KSP, namespace ara::crypto::keys) is responsible for se-
cure (confidential and or authentic) storage of different type Key Material (public,
private, secret keys, or seeds) and other security critical cryptographic objects (digital

96 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

signatures, hash, MAC HMAC tags). These cryptographic objects are represented as
a Key Slots.
Key Slots used by application are defined by the integrator in the manifest via Cryp-
toKeySlot.
CryptoKeySlotInterface and CryptoKeySlotToPortPrototypeMapping
[SWS_CRYPT_10000]{DRAFT} dThe FC Crypto shall provide access to the Cryp-
toKeySlots for every AdaptiveApplicationSwComponentType. Every Cryp-
toKeySlot is represented by RPortPrototype typed by CryptoKeySlotInter-
face in application design.c(RS_CRYPTO_02004, RS_CRYPTO_02305)
Assignment of CryptoKeySlots to a CryptoProvider is described in the manifest.
So with the usage of a RPortPrototype that is typed by a CryptoKeySlotInter-
face the assignment to CryptoProvider is established.
[SWS_CRYPT_10003]{DRAFT} dThe CryptoAPI shall provide a function to obtain
Crypto Provider. With a call of ara::crypto::cryp::CryptoContext::-
MyProvider the FC Crypto provides the correspinding Crypto Provider of a
Key Slot.c(RS_CRYPTO_02009)
The manifest contains separate deployment data for each Process. The class Cryp-
toKeySlotToPortPrototypeMapping defines the mapping between a Process,
a CryptoKeySlot, and an RPortPrototype. Furthermore, the class Crypto-
ProviderToPortPrototypeMapping defines the mapping between a Process, a
CryptoProvider, and an RPortPrototype. Figure 7.7 shows the relevant model
elements. Additional model elements and links are only shown for context.
Application Design

CryptoKeySlotInterface CryptoProviderInterface
CryptoInterface
+ allocateShadowCopy: Boolean [0..1]
+ cryptoAlgId: String [0..1]
+ cryptoObjectType: CryptoObjectTypeEnum [0..1]
+ slotCapacity: PositiveInteger [0..1]
+ slotType: CryptoKeySlotTypeEnum [0..1]

ARElement
+portPrototype AbstractRequiredPortPrototype AtpBlueprint
+requiredInterface
RPortPrototype AtpBlueprintable
0..1 «isOfType» AtpType
+portPrototype 0..1 PortInterface
{redefines atpType}
«instanceRef»
0..1

Deployment

Identifiable
+keySlot CryptoKeySlot Identifiable
UploadablePackageElement +keySlot
+ allocateShadowCopy: Boolean [0..1] CryptoProvider
CryptoKeySlotToPortPrototypeMapping 0..1
+ cryptoAlgId: String [0..1] 0..*
+ cryptoObjectType: CryptoObjectTypeEnum [0..1] «atpSplitable»
+process 0..1 + slotCapacity: PositiveInteger [0..1]
+ slotType: CryptoKeySlotTypeEnum [0..1] 0..1
AbstractExecutionContext
+cryptoProvider
Process
+process UploadablePackageElement
+ functionClusterAffiliation: String [0..1]
0..1 CryptoProviderToPortPrototypeMapping +cryptoProviderDocumentation 0..1
+ numberOfRestartAttempts: PositiveInteger [0..1]
+ preMapping: Boolean [0..1] ARElement
«instanceRef» Documentation

Figure 7.7: Key deployment

97 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_10005]{DRAFT} dThe Key Slot shall be identified during runtime.

The CryptoAPI provides an interface with a call to ara::crypto::keys::-
KeyStorageProvider::LoadKeySlot to support this. The interface needs an
ara::core::InstanceSpecifier as an input parameter. Here, ara::core:-
:InstanceSpecifier represents a path to RPortPrototype mapped to needed
CryptoKeySlot.c(RS_CRYPTO_02405)
CryptoAPI consumers work with logically single KSP that is used for access to all
cryptographic objects independently from their physical hosting on the ECU. However,
from the stack supplier point of view, each HSM may support own back-end KSP re-
sponsible for access control to internally stored cryptographic objects. All back-end
KSP are hidden from the consumers (under public CryptoAPI).
[SWS_CRYPT_10004]{DRAFT} dThe FC Crypto shall ensure confidentiality and au-
thenticity of processed and stored objects with a correct KSP implementation (similar
to Classic Platform). Thus, its implementation shall be isolated from the consumers’
code space.c(RS_CRYPTO_02008, RS_CRYPTO_02009, RS_CRYPTO_02106)
The ”Key Management” functionality is split into four parts:
1. Key Storage Provider API (namespace crypto::keys).
2. Certificate Management Provider API completely (namespace crypto::x509).
3. Key Material Generation, Secured Export, Public/Secured Import and auxiliary
API (via methods of crypto::cryp::CryptoProvider interface). These methods rep-
resent all actions that need implementation of cryptographic transformations of
keys. The usage of HSM is implemented in hardware and thus may not support
all APIs as software solutions would.
4. Generic serialization of public cryptographic objects (via crypto::Serializable in-
terface). Taking into account the deep dependence of 3rd category of the ”Key
Management” sub-API from other cryptographic functionality, possibility to reuse
some functional blocks (including mechanisms of access control to Key Mate-
rial in HSM realms), there is no practical sense to separate this sub-API from
Crypto Provider API.
Key Storage & Certificate Management are realized by separated interfaces, because
they can be implemented completely independent. This allows to combine both pro-
vided by different vendors.

7.4.2.1 Serializable interface

[SWS_CRYPT_10200]{DRAFT} dThe CryptoAPI shall provide an interfaces

ara::crypto::Serializable::ExportPublicly, ara::crypto::Serial-
izable::ExportPublicly for exporting of any public (by nature) objects, where
additional integrity or confidentiality protection are not needed.c(RS_CRYPTO_02112)

98 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

Interfaces of all public (non-confidential) cryptographic objects and certificates that

principally support serialization in plain (non-encrypted and non-authenticated) form
are derived from the ara::crypto::Serializable interface.
Actually, this interface provides only one serialization method formatId.

7.4.2.2 Key Generation

Key Generation is the process of generating cryptographic keys. There are two types
of Key Generation based on the used cryptographic algorithms:
1. Symmetric Algorithms: A symmetric system consists of a key, which is shared
between the different parties.
[SWS_CRYPT_10300]{DRAFT} Symmetric cryptography dThe FC Crypto
shall support symmetric cryptography.c(RS_CRYPTO_02101).
[SWS_CRYPT_10301]{DRAFT} dThe FC Crypto shall allocate a new Sym-
metric Key object by a call of function ara::crypto::cryp::Crypto-
Provider::GenerateSymmetricKey and fill it by a new randomly generated
value. The function shall return
• kUnknownIdentifier error, if the ara::crypto::CryptoAlgId has
an unsupported value.
• kIncompatibleArguments error, if allowedUsage is incompatible with
target algorithm specified by ara::crypto::CryptoAlgId.
c(RS_CRYPTO_02101).
2. Asymmetric Algorithms: Asymmetric systems consist of public and private key,
which are generated. The public key is used for encryption, key encapsulation, or
signature verification. The private key is used for decryption, key encapsulation,
key exchange, or digital signature calculation.
[SWS_CRYPT_10303]{DRAFT} Asymmetric cryptography dThe FC Crypto
shall support asymmetric cryptography.c(RS_CRYPTO_02101).
[SWS_CRYPT_10304]{DRAFT} dThe FC Crypto shall support the Asymmet-
ric Key generation. The CryptoAPI provide such functionality. The private
key is generated by calling ara::crypto::cryp::CryptoProvider::Gen-
eratePrivateKey.c(RS_CRYPTO_02101)
[SWS_CRYPT_10305]{DRAFT} dThe corresponding public key can be obtained
from a private key object by ara::crypto::cryp::PrivateKey::GetPub-
licKey. This function is part of the CryptoAPI.c(RS_CRYPTO_02002)
[SWS_CRYPT_10306]{DRAFT} dAs private and public key are tightly coupled
which each other, they should have the same COUID. A common COUID shall be
shared for both private and public keys.c(RS_CRYPTO_02005)

99 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

7.4.2.3 Exporting and Importing of Key Material

Exporting of Key Material is sometimes necessary. This is useful during the setup
of communication channels, for example. Importing Key Material is also important
for a later use. Export and Import facilities of Crypto Provider are described in
7.4.1.13.
Another use case to export and import Key Material is the confidential delivery of
Symmetric Keys, e.g., transport keys. This technique is called data encapsulation
mechanism and provides a ”crypto envelope” or ”digital envelope” that protects the se-
crecy and integrity of data using symmetric-key cryptographic techniques concept. The
FC Crypto provides two contexts, ara::crypto::cryp::KeyAgreementPriva-
teCtx and ara::crypto::cryp::KeyEncapsulatorPublicCtx, which imple-
ments the data encapsulation mechanism. Additionally, it is possible to assure non-
repudiation by adding a digital signature. This is provided via the ara::crypto::-
cryp::HashFunctionCtx and ara::crypto::cryp::SignerPrivateCtx. All
contexts contains two building blocks:
• The encryption algorithm
• The decryption algorithm
[SWS_CRYPT_10403]{DRAFT} dThe FC Crypto shall provide private key agreement
functionality by a specific context. This context is the ara::crypto::cryp::KeyA-
greementPrivateCtx. The CryptoAPI generates this context via an interface. This
interface needs an identifier of the target key-agreement cryptographic algorithm to
setup the correct context.c(RS_CRYPTO_02105)
[SWS_CRYPT_10401]{DRAFT} dKey agreement private context shall provide function-
ality to produce a common secret seed ara::crypto::cryp::SecretSeed.
c(RS_CRYPTO_02007)
[SWS_CRYPT_10402]{DRAFT} dKey agreement private context shall provide function-
ality to produce a common symmetric key.c(RS_CRYPTO_02103)

7.4.3 Certificate handling (X.509 Provider)

X.509 Certificate Management Provider (X.509 Provider) is responsible for X.-

509 certificates parsing, verification, authentic storage and local searching by different
attributes. In addition, X.509 Provider is responsible for storage, management,
and processing of Certificate Revocation Lists (CRLs) and Delta CRLs. The X.509
Provider supports the preparation of requests, responses, and parsing according to
the Online Certificate Status Protocol (OCSP) as defined in [30] and [31].
[SWS_CRYPT_20000]{DRAFT} dFC Crypto supports only a single instance of the
ara::crypto::x509::X509Provider. As the X.509 Provider is completely

100 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

independent from ara::crypto::cryp::CryptoProvider and ara::crypto:-

:keys::KeyStorageProvider implementation details, it is possible that differ-
ent vendors provide X.509 Provider and Crypto Provider / Key Storage
Provider. Therefore, the standardized CryptoAPI guarantees interoperability be-
tween these independent building blocks. Applications or Functional Clusters
can access certificates by CryptoCertificateInterface, which is provided by
X.509 Provider.c(RS_CRYPTO_02307)
Any FC Crypto implementation shall include a single X.509 Provider. Responsi-
bility of this provider is the support of Public Key Infrastructure (PKI) as defined in [32].
A PKI contains a root certificate and one or many certificates. Main feature are:
1. Storages of certificates, certification signing requests (CSRs), and certificate re-
vocation lists (CRLs).
2. Complete parsing of X.509 certificates and certificate signing requests (CSR).
3. Encoding of all public components of certificate signing requests (e.g. Distin-
guished Names and X.509 Extensions).
4. Verification of certificates and certification chains (according to current set of
trusted certificates).
5. Trust management of the stored certificates.
6. Search of certificates in local storage based on different parameters.
7. Automatic building of the trust chains according to saved certificates, CRLs, and
trust configuration.
[SWS_CRYPT_20001]{DRAFT} dThe CryptoAPI provides a secure local access to
specific information. The minimal information, which shall be accessable, are the
specific system name, the private key, which is associated with the caller, the name
of the CA, which is used as a trust authority, and the ara::crypto::x509::-
X509PublicKeyInfo (or a fingerprint of the public key where a self-certified version
is available elsewhere).c(RS_CRYPTO_02306)
[SWS_CRYPT_20002]{DRAFT} dThe ara::crypto::x509::X509Provider shall
store and provide the root ara::crypto::x509::Certificate and all needed
CAs along the certification path, together with the reference to the correspond-
ing public and private keys, which are handled by the ara::crypto::keys::-
KeyStorageProvider. All elements, which are relevant for the certification
path, shall be stored with local access either hard-coded into the software or in a per-
sistent and tamper-proof manner. The decision how to store the elements is based
on:
• Updatability of certificates: When certificates shall be exchangeable or revocable,
then these are stored in a volatile but persistent storage. Fixed certificates, which
stay forever for example, can be stored hard-coded.

101 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

• Use case specific: An application or Functional Cluster can have pre-

configured certificates, which are stored along side the configuration, e.g. in
ARXML.
• Project specific
c(RS_CRYPTO_02306)
[SWS_CRYPT_20003]{DRAFT} dThe FC Crypto shall provide all cryptographic al-
gorithms to generate, validate, and process certificates, which are used in the sys-
tem. Depending on the certificate the X.509 Provider uses the corresponding
Crypto Provider. However, the X.509 Provider can either directly access the
cryptographic algorithm or use the exposed interfaces provided by the CryptoAPI.c
(RS_CRYPTO_02204, RS_CRYPTO_02306)
[SWS_CRYPT_20004]{DRAFT} dThe X.509 Provider shall support ASN.1 pars-
ing. Thus it provides an ASN.1 parser to read the specific syntax of X.509 certificates.
Typical X.509 certificates must follow the definition given in [32] and [33, RFC 5280]:
1. Certificate
(a) Version Number
(b) ara::crypto::x509::Certificate::SerialNumber
(c) Signature Algorithm ID
(d) ara::crypto::x509::Certificate::IssuerDn
(e) Validity period
i. ara::crypto::x509::Certificate::StartTime
ii. ara::crypto::x509::Certificate::EndTime
(f) ara::crypto::x509::BasicCertInfo::SubjectDn
(g) Subject Public Key Info
i. Public Key Algorithm
ii. Subject Public Key
(h) Issuer Unique Identifier (optional)
(i) Subject Unique Identifier (optional)
(j) Extensions (optional)
2. Certificate Signature Algorithm
3. Certificate Signature
Theses certificates are described by CryptoServiceCertificate with all ele-
ments.c(RS_CRYPTO_02306)

102 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

The X.509 Provider parses certificates when an application or Functional

Cluster uses the CryptoAPI interfaces for importing, storing, or verifying of CSRs
and certificates. This can be problematic when cross-certification or cross-signing is
used. Cross-certification allows to trust one entity in another PKI. Here, one part of
the PKI tree signs a part of another PKI tree and vice verse. The X.509 Provider
shall handle this cross-signing in a correct manner, transparent for the application or
Functional Cluster.
[SWS_CRYPT_20005]{DRAFT} Freedom of interference during update dIt must be
possible to regularly update any key pair of certificates, which are part of a PKI tree,
without affecting any other key pair of related certificates, which can be also part of the
same PKI tree or part of an independent tree.c(RS_CRYPTO_02112, RS_CRYPTO_-
02306)
[SWS_CRYPT_20006]{DRAFT} dThe X.509 Provider shall generate certificates,
so called self-signed certificates, and CSRs based on standardized cryptographic al-
gorithms. A specific algorithm can be chosen by the application or the Functional
Cluster in the generation call. It shall be ensured that the Crypto Provider ex-
poses the needed algorithms. During the CSR generation a key pair, public and private
key, is generated as well. These keys are stored, by the Key Storage Provider.
Therefore, the X.509 Provider shall use either internally or via exposed interfaces
the functionality of the Key Storage Provider to create, store, and manage the
keys.c(RS_CRYPTO_02306)
X.509 Provider supports two variants of long-term storage types:
1. ”Persistent” storage is dedicated for X.509 artifacts that should survive after ECU
restart / shutdown.
2. ”Volatile” (or ”Session”) is dedicated for X.509 artifacts, that are valuable only in
scope of current session of an application or Functional Cluster, importing
these artifacts to the storage.
[SWS_CRYPT_20007]{DRAFT} dThe X.509 Provider shall store issued certifi-
cates in a persistent manner.c(RS_CRYPTO_02306)
[SWS_CRYPT_20009]{DRAFT} dWhen a certificates expires, the X.509 Provider
shall replace the certificate with a new certificate. Additionally, the X.509 Provider
may add the certificate on revocation list. The X.509 Provider shall update the
internal state to reflect this change.c(RS_CRYPTO_02306)
[SWS_CRYPT_20010]{DRAFT} dX.509 Provider implementation shall require es-
pecial capability ”Trust Master” from applications that will set specific certificate as a
root of trust ara::crypto::x509::X509Provider::SetAsRootOfTrust.c(RS_-
CRYPTO_02306)
[SWS_CRYPT_20011]{DRAFT} dX.509 Provider shall support the Proof-Of-
Possession (POP) of the private key.c(RS_CRYPTO_02306)

103 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_40943]{DRAFT} dThe functions ara::crypto::x509::-

X509Provider::ParseCustomCertExtensions, ara::crypto::x509:-
:X509Provider::ParseCustomCertExtensions shall parse the extension
identified by the parameter oid of the provided Certificate and call the functions of
the provided callback class customExtensionsParser in the order of occurence of
the ASN.1 elements in the parsed certificate. If the parameter oid is not given, then
ParseCustomCertExtensions shall parse all extensions of the certificate.
• If the parameter oid is given but the certificate does not contain an extension
with the given oid, then ParseCustomCertExtensions shall return CryptoErrorDo-
main::kUnexpectedValue.
• If a function of the callback class customExtensionsParser returns any error, then
ParseCustomCertExtensions shall stop parsing the certificate and return Crypto-
ErrorDomain::kRuntimeFault.
c(RS_CRYPTO_02306)

7.4.3.1 Certificate Signing Request

[SWS_CRYPT_20301]{DRAFT} dThe X.509 Provider produces the Certificate

Signing Request by ara::crypto::x509::X509Provider::CreateCertSign-
Request. This is done in a specific context, which needs an identifier of the target
asymmetric cryptographic algorithm and the corresponding public-private key pair. The
ara::crypto::x509::CertSignRequest(CSR) is signed by the private key and
contains the public key.c(RS_CRYPTO_02306) The identification of the used algorithm
is done by the common name, as specified in 7.5.
The X.509 Provider delegates the CSR self-signature creation to the corresponding
context, which is also responsible for processing of the correspondent private key.
[SWS_CRYPT_20302]{DRAFT} dX.509 Provider shall encode all meta-
information (Distinguished name and X.509 Extensions). This meta-information
is added during the CSR generation to the CSR before the signature is generated.
The Distinguished name and X.509 Extensions, can be either global or locally
defined. The specific context is given either during the interface call (locally defined)
or specified in the configuration (global). However, the specific local settings shall
overwrite the global ones during the CSR generation. If no meta-information is
provided, the global ones shall be used as default.c(RS_CRYPTO_02306)
[SWS_CRYPT_20303]{DRAFT} dAll meta-information shall be encoded according to
the X.509 specification (as given in [32], [34], [35], [36], [37], [38], and [2]).c(RS_-
CRYPTO_02306)
X.509 Provider distinguishes three states of a CSR:
1. ”New” - the CSR is created, but is not yet sent to the Certification Authority (CA).

104 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

2. ”Pending” - the CSR was already sent to the CA, but the internal was not yet
updated. Either the CSR was not returned or was not processed.
3. ”Retrieved” - the CSR was returned from the CA, and is either processed or the
processing was not started yet.
When a signed CSR is retrieved, the X.509 Provider will import the CSR and starts
the processing.
[SWS_CRYPT_20304]{DRAFT} dEach CSR is an artifact produced by the X.509
Provider and is stored locally. The CryptoAPI provides an interface to allow an
application or Functional Cluster to trigger the storing.c(RS_CRYPTO_02306)

7.4.3.2 Using Certificates

[SWS_CRYPT_20601]{DRAFT} Importing / Installation dThe X.509 Provider pro-

vides a mechanism for applications or Functional Clusters to import ara::-
crypto::x509::X509Provider::Import or install certificates, parts of certi-
fication paths, or full certification paths.c(RS_CRYPTO_02306)
This allows the user to integrate certificates into the system, especially when these
are generated outside the system itself. Therefore, the CryptoAPI provides an in-
terface to import certificates. This interface can be configured during the integration
phase by using the PortInterface, as shown in 7.8, or the specific API call. When
a certificate is imported, the X.509 Provider validates the certificate or the certi-
fication paths with the corresponding PKI. Additionally, the X.509 Provider
checks if all Distinguished names and X.509 Extensions are matching the pre-
configured meta-information (global information) or specified ones (local information).
Specific meta-information is provided by the application or Functional Cluster via
the interface call. If no specific meta-information is provided, the global ones are used
as default. Importing can be done either via a file, which is stored on the system, or
as an ASN.1 encoded information directly. If an internal error occurred or the internal
policy prohibits the importing, the caller will be informed by an error.
[SWS_CRYPT_20602]{DRAFT} Exporting dThe X.509 Provider exports a certifi-
cate, a bundle of certificates, a part of a certification path, or a full certi-
fication path. The private key of the corresponding export is not included in the
export.c(RS_CRYPTO_02306)
The export is done in ASN.1 encoding according to X.509 standard. The application
or Functional Cluster can define the certificate format, such as BER, DER, or
PEM, and specify if the export shall be stored as file or provided directly. The used
meta-information, Distinguished name and X.509 Extension, ca be provided lo-
cally during the export, or provided globally, as configured. However, the local ones will
overwrite the global ones. If no meta-information is given, the global ones are used as
default. Revoked certificated are not exported. In this case or the exporting cannot be
done, either an internal error occurred or the internal policy prohibits it, the caller will
be informed by an error.

105 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_20603]{DRAFT} Getting or Querying dWhen an application or a

Functional Cluster needs a specific certificate, it can either use a configured one
(this is provided via the CryptoCertificateInterface ) or can get a certificate
via the X.509 Provider mechanism. If the user knows, which certificate it wnts to
access, it can do this by providing the direct handle or the COUID. However, it occurs
that the user does not know exactly which certificate is needed. Therefore, the X.509
Provider allows to query the certificate. The application or Functional Cluster
then can provide either certificate information, such as certificate serial num-
ber or issuer, the meta-information, part of the meta-information, the environment the
certificate is used for (e.g., IPsec or TLS), or provide parts of the certification
path. In this case the X.509 Provider provides a list of all matching certificates
ara::crypto::x509::BasicCertInfo or an error, when no matching certificate
was found or the caller has not the corresponding access rights for the found certifi-
cates.c(RS_CRYPTO_02306)
[SWS_CRYPT_40912]{DRAFT} Querying with wildcards dWhen an instance of class
ara::crypto::x509::X509DN is created all attributes of this instance shall be
none-initialized. None-initialized attributes shall serve as wildcards.c(RS_CRYPTO_-
02306)
[SWS_CRYPT_40913]{DRAFT} Sets of certificates dThe function ara::crypto:-
:x509::X509Provider::FindCertByDn shall provide a set of all certificates that
match the attributes of parameter subjectDn. The function findCertByDn shall ignore
none-initialized attributes of parameter subjectDn for the search for certificates.c(RS_-
CRYPTO_02306)
Figure 7.8 shows the model elements that are relevant for the deployment of certifi-
cates.
ApplicationDesign
CryptoCertificateInterface CryptoInterface

+ isPrivate: Boolean [0..1]

+ writeAccess: Boolean [0..1]

ARElement
AbstractRequiredPortPrototype AtpBlueprint
+requiredInterface
+portPrototype RPortPrototype AtpBlueprintable
«isOfType» AtpType
0..1
0..1 PortInterface
{redefines atpType}

Deployment

Identifiable Identifiable
CryptoCertificate CryptoKeySlot Identifiable
+keySlot
«instanceRef» + isPrivate: Boolean [0..1] + allocateShadowCopy: Boolean [0..1] CryptoProvider
+ cryptoAlgId: String [0..1] 0..*
+ cryptoObjectType: CryptoObjectTypeEnum [0..1] «atpSplitable»
+cryptoCertificate

+cryptoCertificate

+cryptoCertificate 0..1 0..1 0..* + slotCapacity: PositiveInteger [0..1]

+ slotType: CryptoKeySlotTypeEnum [0..1] +cryptoProvider 0..*

+cryptoKeySlot 0..2

«atpSplitable»
«atpSplitable»

CryptoCertificateToCryptoKeySlotMapping

UploadablePackageElement +certificateToKeySlotMapping 0..* NonOsModuleInstantiation

CryptoCertificateToPortPrototypeMapping +process AbstractExecutionContext CryptoModuleInstantiation
«atpSplitable»
Process
+ writeAccess: Boolean [0..1] 0..1

Figure 7.8: Certificate deployment

106 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_20611]{DRAFT} Validation of certification path dWhen a cer-

tificate is installed, the whole certificate chain must be validated based on the whole
tree path up to the root certificate (e.g., vehicle root) by ara::crypto::x509::-
X509Provider::CheckCertStatus, ara::crypto::x509::X509Provider:-
:CheckCertStatus, ara::crypto::x509::X509Provider::CountCertsIn-
Chain, ara::crypto::x509::X509Provider::ParseCertChain, ara::-
crypto::x509::X509Provider::ParseCertChain, ara::crypto::x509:-
:X509Provider::VerifyCertChain. Only certificates, which are not root
certificates, are checked.c(RS_CRYPTO_02306)
Root certificates are not checked, because these are the trust anchors of the system.
Because root certificates play this special role, root certificate shall be stored in a
tamper proof manner to avoid malicious manipulation. How this is done is not part of
this standard.
[SWS_CRYPT_20612]{DRAFT} dSupporting a full certificate life-cycle, the FC
Crypto provides functionality to generate certificate signing request, where the
needed encoding (i.e., DER or PEM) can be specified and the correct setting is en-
sured. The CryptoAPI provides this interface for CSR generation. Additionally, the
CryptoAPI offers the specific interfaces to generate certificates and certificate chains,
which can then be used by other protocols, i.e., IKE.c(RS_CRYPTO_02306)
The PKI contains the certificates of the vehicle side, i.e. all certificates or artifacts that
are part of the vehicle. It is structured based on functions on the CA level (level 2) and
on distributed issuers on the Sub-CA level (level 3). The top level is defined by the
vehicle root certificate, which is provided by every OEM and serves as a trust anchor.
Also X.509 Provider may keep root certificates of 3rd party trusted CAs in order to
communicate with external service providers.
[SWS_CRYPT_20613]{DRAFT} dThe FC Crypto allows to encode and decode
ASN.1-based standard formats (like [39, PKCS#8], [40, PKCS#12]), as specified in
[41, X.680], [42, X.682], and [43, X.683]. The CryptoAPI allows an application or
Functional Cluster to select the encoding.c(RS_CRYPTO_02306)
[SWS_CRYPT_20614]{DRAFT} dThe CryptoAPI provide all required X.509 func-
tionality related with access to the certification target private key (used for signature
of own certificate request, via top-level context interface). The target private key can
have a type different from signature (e.g., decryption or key-agreement). This is spec-
ified by the connection between CryptoCertificate and CryptoKeySlot. This
connection is done by a mapping.c(RS_CRYPTO_02306) The mapping is provided by
CryptoCertificateToCryptoKeySlotMapping as shown in 7.8.
[SWS_CRYPT_20615]{DRAFT} dThe X.509 Provider shall verify self-signed cer-
tificates besides PKI based signatures. The CryptoAPI provides methods to specify
the certificate and the used cryptographic algorithm. Based on the algorithm the X.-
509 Provider compares the given signature with the calculated one. If both are
matching, the certificate is valid. Otherwise, the X.509 Provider will return an er-
ror.c(RS_CRYPTO_02306)

107 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_20616]{DRAFT} dThe access to the PKI-client’s private key shall be

used only internally and indirectly via the X.509 Provider interface. The private key
will never leave the boundary of the FC Crypto.c(RS_CRYPTO_02306)
[SWS_CRYPT_20617]{DRAFT} dX.509 Provider is using the base cryptographic
functions provided by the Crypto Provider. CryptoAPI provides related functions
to store, retrieve, enumerate, verify, and use the information stored in the certificates.c
(RS_CRYPTO_02306)
[SWS_CRYPT_20618]{DRAFT} dIn the CryptoAPI context, the certificate store is
protected from unauthorized access and tampering. This can be done by cryptographic
mechanism, such as providing an MAC, or by storing the certificates in a secure storage,
such as a TPM.c(RS_CRYPTO_02306)
[SWS_CRYPT_20619]{DRAFT} dDuring the initialization of the FC Crypto, all
needed steps for service instantiation is done. This includes importing a root CA public
key, setting up the certification path with all public keys along the path, checking
the revocation status of certificates, updating the X.509 Provider internal manage-
ment structure with certificate status, and the certificate ecosystem.c(RS_CRYPTO_-
02306)

7.4.3.3 Revocation of certificates

The X.509 Provider supports the revocation of certificates. This is done by using
standard mechanism, such as certificate revocation lists (CRLs) and certificate trust
lists (CTLs). The X.509 Provider is the organizational part of the FC Crypto,
which handles and stores during run-time these CRLs and CTLs. The CryptoAPI
provides interfaces, which allow application and Functional Clusters to import,
export, and manage these lists.
[SWS_CRYPT_20901]{DRAFT} CRL and CTL usage dThe X.509 Provider shall
support CRL and CTL. The format of CRL and CTL are defined in [33, RFC 5280], [44,
RFC 6518], [45, RFC 8398], and [46, RFC 8399] and is not part of this standard. The
X.509 Provider can store the CRL and the CTL in an own internal used structure.
However, the X.509 Provider can also use the provided information to update the
corresponding elements. The update can be either the deletion of the element or
setting a mark that the element was revoked.c(RS_CRYPTO_02306)
CRL is a list of digital certificates that have been revoked before their expiration date
was reached. This list contains all the serial numbers of the revoked certificates and
the revoked data.
[SWS_CRYPT_20902]{DRAFT} dGiven in [33] the CRL can contain two different states:
1. Revoked: certificates that are irreversibly revoked.
2. Hold: certificates that are marked as temporally invalid.
c(RS_CRYPTO_02306)

108 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

CryptoAPI shall provide two ways to get CRL:

1. Offline: An application or Functional Cluster provides a CRL to the X.509
Provider.
2. Online: X.509 Provider opens a secure channel to a backend system. After
a successful established connection, the X.509 Provider gets the matching
CRL. The location of the specific backend system can either configured or pro-
vided via an application or Functional Cluster.
[SWS_CRYPT_20903]{DRAFT} Import dThe X.509 Provider allows to import
ara::crypto::x509::X509Provider::ImportCrl and update the CRL. These
CRL can be either stored in the X.509 Provider separately or in combination with
the certificate. The application or Functional Cluster can call the interface ara:-
:crypto::x509::X509Provider::ImportCrl, which is provided by the Cryp-
toAPI.c(RS_CRYPTO_02306)
[SWS_CRYPT_20904]{DRAFT} dThe X.509 Provider shall support the online
mode to get and update CRL.c(RS_CRYPTO_02306)
[SWS_CRYPT_20905]{DRAFT} Verify dThe function ara::crypto::x509::-
X509Provider::VerifyCert shall verify if a certificate is valid. Therefore, the
X.509 Provider checks additionally if a certificate was revoked, The revocation of
the certificate is given via the CRL. This check can either be done via a call by an ap-
plication or Functional Cluster (offline mode) or via a connection to a backend
(online mode):
• In offline mode: An application or Functional Cluster provides the CRL to
the X.509 Provider via an interface, which is exposed by the CryptoAPI.
• in online mode: The X.509 Provider uses a provided location to get the CRL.
The location was provided by configuration or given in the interface call.
In both cases, the X.509 Provider uses the CRL to check if one of the internal stored
certificate is listed. Is a certificate listed the X.509 Provider revokes the certificate
internally.c(RS_CRYPTO_02306)
[SWS_CRYPT_20906]{DRAFT} dThe X.509 Provider shall support the standard
protocol, ara::crypto::x509::OcspResponse (as defined in [31, RFC 6960]) and
OCSP Stapling (as defined in [47, RFC 6066], [48, RFC 6961], and [49, RFC 8446]), to
check if a certificate is revoked. OCSP is an alternative to CRLs.
c(RS_CRYPTO_02306)
[SWS_CRYPT_20907]{DRAFT} dThe CryptoAPI provides methods ara::-
crypto::x509::X509Provider::CreateOcspRequest, ara::crypto::-
x509::X509Provider::CreateOcspRequest to generate an ara::crypto::-
x509::OcspRequest request, which is defined in [31, RFC 6960]. The method can
be used by an application or Functional Cluster.c(RS_CRYPTO_02306)
[SWS_CRYPT_20908]{DRAFT} dThe X.509 Provider shall support request gener-
ation for the revocation of certificates.c(RS_CRYPTO_02306)

109 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_20909]{DRAFT} Signalization of revoked certificate by applica-

tion or functional cluster dDedicated applications are allowed to inform the X.509
Provider of a misuse or of the invalidity of certificates. The X.509 Provider stores
this information by revoking internally the specified certificate. This can either be done
in the internal structure where certificates are stored or by updating the stored revoca-
tion list. When the X.509 Provider generates a CRL, it uses its internal information.c
(RS_CRYPTO_02306)
[SWS_CRYPT_20910]{DRAFT} Internal signalization of revoked certificate dThe
X.509 Provider shall mark certificates in its internal structure or update the stored
revocation list as revoked, when the X.509 Provider recognizes that a certificate is
not valid anymore and thus shall be revoked. This can occur during certification
path validation or verification of a certificate.c(RS_CRYPTO_02306)
[SWS_CRYPT_40972]{DRAFT} Configuration Options dThe FC Crypto shall provide
two configuration options. A configuration field contains either the URL or the identifier
to specify either the URL for the backend (local / stack usage) or the required service
interface.c(RS_CRYPTO_02306)
[SWS_CRYPT_40973]{DRAFT} dThe FC Crypto shall report an error by calling the
online functions if the configuration is empty, not performed or the configuration pa-
rameter is not a matching combination. This allows the application to react on the
existing problem.c(RS_CRYPTO_02306)
[SWS_CRYPT_40974]{DRAFT} dThe FC Crypto shall handle the additional behavior to
send or request OCSP tickets via the configured mechanism.c(RS_CRYPTO_02306)
[SWS_CRYPT_40975]{DRAFT} dThe FC Crypto shall inform the application via an
return value that the CRL was updated via configured mechanism.c(RS_CRYPTO_-
02306)
[SWS_CRYPT_40976]{DRAFT} dThe FC Crypto shall inform the application via an
return value, that the online information was sent to the configured mechanism.c(RS_-
CRYPTO_02306)
[SWS_CRYPT_40977]{DRAFT} dThe FC Crypto shall inform the application via an
return value, that the validity of a given certificate was checked online via the configured
mechanism.c(RS_CRYPTO_02306)
[SWS_CRYPT_40978]{DRAFT} dThe FC Crypto shall provide a mechanism, which
is used via the calling user (FC Crypto itself or application), allowing to get the last
received OCSP ticket.c(RS_CRYPTO_02306)
[SWS_CRYPT_40979]{DRAFT} dThe FC Crypto shall update the internal state of a
certificate, if the certificate was invalidated via a given OCSP ticket and if the certificate
is handled via the internal certificates management.c(RS_CRYPTO_02306)
[SWS_CRYPT_40980]{DRAFT} dThe FC Crypto shall point to the successor of an in-
validated certificate, if the OCSP ticket provides a successor.c(RS_CRYPTO_02306)

110 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

7.5 Cryptographic Primitives Naming Convention

Crypto Providers transforms the specific needed algorithm, which was configured
during integration phase, into the by FC Crypto provided vendor specific algorithm.
Supporting this decoupling of configuration from instantiation and enabling the sup-
port of future upcoming cryptographic algorithm, this specification does not provide a
concrete list of cryptographic algorithms’ identifiers and does not suppose usage of nu-
merical identifiers. Instead of this, the vendor shall provide string names of supported
algorithms in accompanying documentation.
The string names are used for the following:
• They are used as parameters by interface functions of a Crypto Provider.
• They serve as identifiers to cryptographic algorithms.
• The Crypto Provider interprets the string names and matches it to the algo-
rithm, which is provided by FC Crypto.
[SWS_CRYPT_03910]{DRAFT} Configuration format for cryptographic algo-
rithms dThe string names to identify cryptographic algorithms shall satisfy the following
rules:
1. The string names contains only Latin alphanumeric characters.
2. The string names contain up to 6 delimiters for cryptographic algorithm definition.
3. The string names is case insensitive. Thus, all comparisons of the identifiers shall
be always case insensitive.
4. The string names to identify cryptographic algorithms shall satisfy the following
structures:
”{TargetTransformation(Mode)} / {SupportingAlgorithms} /
{Encoding&Padding}”
where
• ”{TargetTransformation(Mode)}” – a specifier of target transforma-
tion: for complex transformations it is a mode name, but for fully-defined
algorithms it is just their name.
• ”{SupportingAlgorithms}” – a specifier of basic cryptographic algo-
rithm(s) including key length andor block length.
• ”{Encoding&Padding}” – a specifier of encoding and/or padding
method. It can support following predefined name (equal to empty speci-
fication):
– ”Zero” – a default encoding & padding method: if data are already
aligned to the block boundary then it doesn’t add anything, but if they
are not aligned then applies a padding by ’\0’ bytes up to the block
boundary.

111 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

Allowed delimiters:
• ’/’ – separator between main components of the whole algorithm specification.
• ’_’ – separator instead of general separation characters (e.g.: ’ ’, ’.’,
’:’, ’-’, ’’) in original name of standard. This delimiter can be applied
between two digits or two letters only!
• ’-’ – separator between a base algorithm name and its precise specifiers that
define key-length or block-length in bits.
• ’+’ – separator between a few base algorithms’ specifications for a cascade
transformation definition.
• ’,’ – separator between a few base algorithms’ specifications for a case if the
whole algorithm is based on a few types of basic transformations.
• ’.’ – separator between a common name of a standard and its specific part or
its version that precises a specification of concrete transformation.
c(RS_CRYPTO_02308)
Examples of well-known algorithm names: ”ECDSA-256”, ”ECDH-256”, ”AES-
128”, ”Camellia-256”, ”3DES-168”, ”ChaCha20”, ”GOST28147_89”,
”SHA1”, ”SHA2-256”, ”GOSTR3410.94”, ”GOSTR3410.2001”,
”GOSTR3410.2012-512”.
Examples of well-known modes names: ”ECB”, ”OFB”, ”CFB”, ”CBC”,
”PCBC”, ”CTR”, ”HMAC”, ”CBC_MAC”, ”OMAC1”, ”OMAC2”, ”VMAC”,
”Poly1305”, ”CCM”, ”GCM”, ”OCB”, ”CWC”, ”EAX”, ”KDF1”, ”KDF2”,
”KDF3”, ”MGF1”.
Examples of the encoding and padding names: ”ANSI_X923”, ”ISO10126”,
”PKCS7”, ”ISO_IEC7816_4”, ”PKCS1.v1_5”, ”OAEP”, ”OAEPplus”,
”SAEP”, ”SAEPplus”, ”PSS”, ”EME”, ”EMSA”.
Examples of fully defined transformations:
• ”ECDSA-384” means ECDSA signature algorithm with private key-length 384
bit.
• ”ECDH-512” means ECDH key agreement algorithm with private key-length 512
bit.
• ”CTRAES-256” means a CTR-mode stream cipher based on AES algorithm with
key-length 256 bit.
• ”CBCAES-192+Camellia-192/PKCS7” means CBC-mode cipher based on
cascade application of AES-192 and Camellia-192 with padding of last block ac-
cording to PKCS#7.
• ”HMACSHA-256” means HMAC based on SHA-256.

112 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

If an algorithm support a few variable length parameters then they shall be specified in
following order:
key, IO-block or output digest, IV or input block (e.g.: ”Kalyna-512-256” means
block cipher Kalina with 512-bit key and 256-bit block).
If a transformation is based on a few basic cryptographic algorithms then they shall be
specified in an order corresponding to the level of their application (see example below
for RSA).
Following Mode specifications can be used for RSA-based algorithms:
• ”SIG” – signature primitive (e.g., ”SIGRSA-2048,SHA-
160PKCS1.v1_5,EMSA”)
• ”VER” – verification primitive (e.g., ”VERRSA-2048,SHA-
160PKCS1.v1_5,EMSA”)
• ”ENC” – encryption primitive (e.g., ”ENCRSA-2048,MGF1,SHA-
160PKCS1.v1_5,EME”, ”ENCRSA-4096,MGF1,SHA2-256OAEP,EME”)
• ”DEC” – decryption primitive (e.g., ”DECRSA-2048,MGF1,SHA-
160PKCS1.v1_5,EME”, ”DECRSA-4096,MGF1,SHA2-256OAEP,EME”)
• ”KEM” – Key Encapsulation Mechanism (e.g., ”KEM/RSA-2048,AES-
128,KDF3,SHA-256”)
A supplier should strive to use shortest names of algorithms, sufficient for their unam-
biguous identification.

113 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

8 API specification

8.1 C++ language binding Crypto Provider

[SWS_CRYPT_20100]{DRAFT} d
Kind: class
Symbol: AuthCipherCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::AuthCipherCtx : public CryptoContext {...};
Header file: #include "ara/crypto/cryp/auth_cipher_ctx.h"
Description: Generalized Authenticated Cipher Context interface. Methods of the derived interface Buffered
Digest are used for authentication of associated public data. Methods of the derived interface
StreamCipherCtx are used for encryption/decryption and authentication of confidential part of
message. The data processing must be executed in following order:
Call one of the Start() methods. Process all associated public data via calls of Update()
methods. Process the confidential part of the message via calls of ProcessBlocks(), Process
Bytes() (and optionally FinishBytes()) methods. Call the Finish() method due to finalize the
authentication code calculation (and get it optionally). Copy of the calculated MAC may be
extracted (by GetDigest()) or compared internally (by Compare()). Receiver side should not use
decrypted data before finishing of the whole decryption and authentication process! I.e.
decrypted data can be used only after successful MAC verification!

c(RS_CRYPTO_02207)
[SWS_CRYPT_29030]{DRAFT} d
Kind: class
Symbol: BlockService
Scope: namespace ara::crypto::cryp
Base class: ExtensionService
Syntax: class ara::crypto::cryp::BlockService : public ExtensionService
{...};
Header file: #include "ara/crypto/cryp/block_service.h"
Description: Extension meta-information service for block cipher contexts.

c(RS_CRYPTO_02309)
[SWS_CRYPT_20400]{DRAFT} d
Kind: class
Symbol: CryptoContext
Scope: namespace ara::crypto::cryp
Syntax: class ara::crypto::cryp::CryptoContext {...};
Header file: #include "ara/crypto/cryp/crypto_context.h"
Description: A common interface of a mutable cryptographic context, i.e. that is not binded to a single crypto
object.

c(RS_CRYPTO_02008)

114 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_20500]{DRAFT} d
Kind: class
Symbol: CryptoObject
Scope: namespace ara::crypto::cryp
Syntax: class ara::crypto::cryp::CryptoObject {...};
Header file: #include "ara/crypto/cryp/cryobj/crypto_object.h"
Description: A common interface for all cryptograhic objects recognizable by the Crypto Provider. This
interface (or any its derivative) represents a non-mutable (after completion) object loadable to a
temporary transformation context.

c(RS_CRYPTO_02005)
[SWS_CRYPT_20600]{DRAFT} d
Kind: class
Symbol: CryptoPrimitiveId
Scope: namespace ara::crypto::cryp
Syntax: class ara::crypto::cryp::CryptoPrimitiveId {...};
Header file: #include "ara/crypto/cryp/cryobj/crypto_primitive_id.h"
Description: Common interface for identification of all Crypto Primitives and their keys & parameters.

c(RS_CRYPTO_02005)
[SWS_CRYPT_20700]{DRAFT} d
Kind: class
Symbol: CryptoProvider
Scope: namespace ara::crypto::cryp
Syntax: class ara::crypto::cryp::CryptoProvider {...};
Header file: #include "ara/crypto/cryp/crypto_provider.h"
Description: Crypto Provider is a "factory" interface of all supported Crypto Primitives and a "trusted
environmet" for internal communications between them. All Crypto Primitives should have an
actual reference to their parent Crypto Provider. A Crypto Provider can be destroyed only after
destroying of all its daughterly Crypto Primitives. Each method of this interface that creates a
Crypto Primitive instance is non-constant, because any such creation increases a references
counter of the Crypto Primitive.

c(RS_CRYPTO_02305, RS_CRYPTO_02307, RS_CRYPTO_02401)

[SWS_CRYPT_29020]{DRAFT} d
Kind: class
Symbol: CryptoService
Scope: namespace ara::crypto::cryp
Base class: ExtensionService
Syntax: class ara::crypto::cryp::CryptoService : public ExtensionService
{...};
Header file: #include "ara/crypto/cryp/crypto_service.h"
Description: Extension meta-information service for cryptographic contexts.

c(RS_CRYPTO_02309)

115 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_20800]{DRAFT} d
Kind: class
Symbol: DecryptorPrivateCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::DecryptorPrivateCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/decryptor_private_ctx.h"
Description: Asymmetric Decryption Private key Context interface.

c(RS_CRYPTO_02202)
[SWS_CRYPT_29010]{DRAFT} d
Kind: class
Symbol: DigestService
Scope: namespace ara::crypto::cryp
Base class: BlockService
Syntax: class ara::crypto::cryp::DigestService : public BlockService {...};
Header file: #include "ara/crypto/cryp/digest_service.h"
Description: Extension meta-information service for digest producing contexts.

c(RS_CRYPTO_02309)
[SWS_CRYPT_21000]{DRAFT} d
Kind: class
Symbol: EncryptorPublicCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::EncryptorPublicCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/encryptor_public_ctx.h"
Description: Asymmetric Encryption Public key Context interface.

c(RS_CRYPTO_02202)
[SWS_CRYPT_29040]{DRAFT} d
Kind: class
Symbol: ExtensionService
Scope: namespace ara::crypto::cryp
Syntax: class ara::crypto::cryp::ExtensionService {...};
Header file: #include "ara/crypto/cryp/extension_service.h"
Description: Basic meta-information service for all contexts.

c(RS_CRYPTO_02309)

116 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_21100]{DRAFT} d
Kind: class
Symbol: HashFunctionCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::HashFunctionCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/hash_function_ctx.h"
Description: Hash function interface.

c(RS_CRYPTO_02205)
[SWS_CRYPT_21300]{DRAFT} d
Kind: class
Symbol: KeyAgreementPrivateCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::KeyAgreementPrivateCtx : public Crypto
Context {...};
Header file: #include "ara/crypto/cryp/key_agreement_private_ctx.h"
Description: Key Agreement Private key Context interface (Diffie Hellman or conceptually similar).

c(RS_CRYPTO_02104)
[SWS_CRYPT_21400]{DRAFT} d
Kind: class
Symbol: KeyDecapsulatorPrivateCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::KeyDecapsulatorPrivateCtx : public Crypto
Context {...};
Header file: #include "ara/crypto/cryp/key_decapsulator_private_ctx.h"
Description: Asymmetric Key Encapsulation Mechanism (KEM) Private key Context interface.

c(RS_CRYPTO_02104, RS_CRYPTO_02209)
[SWS_CRYPT_21500]{DRAFT} d
Kind: class
Symbol: KeyDerivationFunctionCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::KeyDerivationFunctionCtx : public Crypto
Context {...};
Header file: #include "ara/crypto/cryp/key_derivation_function_ctx.h"
Description: Key Derivation Function interface.

c(RS_CRYPTO_02103)

117 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

[SWS_CRYPT_21800]{DRAFT} d
Kind: class
Symbol: KeyEncapsulatorPublicCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::KeyEncapsulatorPublicCtx : public Crypto
Context {...};
Header file: #include "ara/crypto/cryp/key_encapsulator_public_ctx.h"
Description: Asymmetric Key Encapsulation Mechanism (KEM) Public key Context interface.

c(RS_CRYPTO_02104, RS_CRYPTO_02209)
[SWS_CRYPT_22100]{DRAFT} d
Kind: class
Symbol: MessageAuthnCodeCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::MessageAuthnCodeCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/message_authn_code_ctx.h"
Description: Keyed Message Authentication Code Context interface definition (MAC/HMAC).

c(RS_CRYPTO_02203)
[SWS_CRYPT_22200]{DRAFT} d
Kind: class
Symbol: MsgRecoveryPublicCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::MsgRecoveryPublicCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/msg_recovery_public_ctx.h"
Description: A public key context for asymmetric recovery of a short message and its signature verification
(RSA-like). Restricted groups of trusted subscribers can use this primitive for simultaneous
provisioning of confidentiality, authenticity and non-repudiation of short messages, if the public
key is generated appropriately and kept in secret. If (0 == BlockCryptor::ProcessBlock(...)) then
the input message-block is violated.

c(RS_CRYPTO_02202, RS_CRYPTO_02204)
[SWS_CRYPT_22500]{DRAFT} d
Kind: class
Symbol: PrivateKey
Scope: namespace ara::crypto::cryp
Base class: RestrictedUseObject
Syntax: class ara::crypto::cryp::PrivateKey : public RestrictedUseObject
{...};
5

118 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

4
Header file: #include "ara/crypto/cryp/cryobj/private_key.h"
Description: Generalized Asymmetric Private Key interface.

c(RS_CRYPTO_02002, RS_CRYPTO_02403)
[SWS_CRYPT_22700]{DRAFT} d
Kind: class
Symbol: PublicKey
Scope: namespace ara::crypto::cryp
Base class: RestrictedUseObject
Syntax: class ara::crypto::cryp::PublicKey : public RestrictedUseObject
{...};
Header file: #include "ara/crypto/cryp/cryobj/public_key.h"
Description: General Asymmetric Public Key interface.

c(RS_CRYPTO_02202)
[SWS_CRYPT_22900]{DRAFT} d
Kind: class
Symbol: RandomGeneratorCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::RandomGeneratorCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/random_generator_ctx.h"
Description: Interface of Random Number Generator Context.

c(RS_CRYPTO_02206)
[SWS_CRYPT_24800]{DRAFT} d
Kind: class
Symbol: RestrictedUseObject
Scope: namespace ara::crypto::cryp
Base class: CryptoObject
Syntax: class ara::crypto::cryp::RestrictedUseObject : public CryptoObject
{...};
Header file: #include "ara/crypto/cryp/cryobj/restricted_use_object.h"
Description: A common interface for all objects supporting the usage restriction.

c(RS_CRYPTO_02008)
[SWS_CRYPT_23000]{DRAFT} d
Kind: class
Symbol: SecretSeed
Scope: namespace ara::crypto::cryp
5

119 of 352 Document ID 883: AUTOSAR_SWS_Cryptography

 Specification of Cryptography
AUTOSAR AP R22-11

4
Base class: RestrictedUseObject
Syntax: class ara::crypto::cryp::SecretSeed : public RestrictedUseObject
{...};
Header file: #include "ara/crypto/cryp/cryobj/secret_seed.h"
Description: Secret Seed object interface. This object contains a raw bit sequence of specific length (without
any filtering of allowed/disallowed values)! The secret seed value can be loaded only to a
non-key input of a cryptographic transformation context (like IV/salt/nonce)! Bit length of the
secret seed is specific to concret crypto algorithm and corresponds to maximum of its input/
output/salt block-length.

c(RS_CRYPTO_02007)
[SWS_CRYPT_23200]{DRAFT} d
Kind: class
Symbol: SigEncodePrivateCtx
Scope: namespace ara::crypto::cryp
Base class: CryptoContext
Syntax: class ara::crypto::cryp::SigEncodePrivateCtx : public CryptoContext
{...};
Header file: #include "ara/crypto/cryp/sig_encode_private_ctx.h"
Description: A private key context for asymmetric signature calculation and short message encoding
(RSA-like). Restricted groups of trusted subscribers can use this primitive for simultaneous
provisioning of confidentiality, authenticity and non-repudiation of short messages, if the public
key is generated appropriately and kept in secret.

c(RS_CRYPTO_02202, RS_CRYPTO_02204)
[SWS_CRYPT_29000]{DRAFT} d
Kind: class
Symbol: SignatureService
Scope: namespace ara::crypto::cryp
Base class: ExtensionService
Syntax: class ara::crypto::cryp::SignatureService : public ExtensionService
{...};
Header file: #include "ara/crypto/cryp/signature_service.h"
Description: Extension meta-information service for signature contexts.

c(RS_CRYPTO_02309)
[SWS_CRYPT_23300]{DRAFT} d
Kind: class
Symbol: Signature
Scope: namespace ara::crypto::cryp
Base class: CryptoObject
Syntax: class ara::crypto::cryp::Signature : public CryptoObject {...};
Header file: #include "ara/crypto/cryp/cryobj/signature.h"
5

120 of 352 Document ID 883: AUTOSAR_SWS_Cryptography