AUTOSAR Crypto Stack Interview Notes (Concept-wise)

1. Purpose of the Crypto Stack

• Provides standardized cryptographic services in AUTOSAR ECUs.

• Ensures data integrity, authenticity, confidentiality, and non-repudiation.

• Used in:

o Secure Diagnostics (UDS 0x27, 0x29)

o Secure Communication (SecOC)

o Secure Boot & FOTA

o Random number generation

o Key management

2. Crypto Stack Architecture

Main Layers:

css

CopyEdit

[ Upper Layer Modules ]

[ Crypto Interface (CryIf) ]

[ Crypto Service Manager (CSM) ]

[ Crypto Drivers (CryHw / CrySw) ]

[ Hardware (HSM / SE) or Software Libraries ]

3. CryIf (Crypto Interface)

• Provides API to upper layers like DCM, SecOC.

• Abstracts whether the backend is hardware (CryHw) or software (CrySw).

• Manages job queueing and callback routing.

4. Crypto Service Manager (CSM)

• Core routing and service handling component.

• Exposes APIs:

o Csm_SymmetricEncryption, Csm_Signature, Csm_Hash, etc.

• Handles job state, scheduling, and asynchronous callbacks.

• Routes to proper driver based on configuration.

5. Crypto Drivers

• CrySw: Software-based crypto (e.g., mbedTLS, wolfSSL).

• CryHw: Uses HSM or hardware crypto accelerators.

• Performs actual crypto operations: AES, SHA, RSA, ECDSA, etc.

• Must conform to AUTOSAR API interface.

6. Key Management (KeyM)

• Secure storage, handling, and provisioning of keys.

• Supports:

o Key generation

o Import/export

o Wrapping/unwrapping

o Session keys, static keys

• Keys are referenced by Key ID – not exposed to upper layers.

• Supports symmetric and asymmetric key pairs.

7. Supported Cryptographic Services

Category Algorithms

Symmetric AES (CBC, ECB, GCM), HMAC

Asymmetric RSA, ECC (ECDSA, ECDH)

Hash SHA-1, SHA-2 family

RNG TRNG (True RNG), DRBG (Deterministic RNG)

Signature Sign / Verify using private/public key

8. Integration with Other Modules

a) SecOC (Secure Onboard Communication):

• Uses HMAC or MAC to ensure authenticity of CAN messages.

• Uses CryIf → CSM to generate/verify MACs.

• Sequence counters protect against replay attacks.

b) DCM (Diagnostics Communication Manager):

• Used in UDS 0x27/0x29 security access.

• ECU verifies signature or HMAC of challenge responses.

• Uses CryIf to trigger signature verification or MAC check.

c) Secure Bootloader:

• Uses digital signature verification before starting application.

• Uses CSM via CryIf to verify signature of firmware.

• Uses KeyM to retrieve public key.

d) FOTA:

• Verifies downloaded software integrity via digital signature.

• Crypto operations may be chunked to save memory.

9. Asynchronous Job Handling

• Crypto operations can be non-blocking.

• Jobs assigned via JobID and callbacks used for completion.

 • Essential for hardware-based operations (HSM interrupts).

• JobResultType: PENDING, OK, FAILED.

10. Key Concepts for Configuration

• Key Properties:

o Algorithm, usage (sign, encrypt), scope (session/local/global).

• Job Routing:

o Maps each crypto service to a driver (software or hardware).

• Security Levels:

o Defined per use-case (e.g., diagnostics vs boot).

• Key IDs:

o Used by applications to reference keys abstractly.

11. Security Best Practices

• Use hardware crypto where possible.

• Store keys in HSM, not RAM.

• Apply role-based access control on key usage.

• Always validate return/error codes.

• Use strong cryptographic algorithms (e.g., SHA-256, AES-256).

• Never expose key material to application layers.

12. Typical Crypto Use Cases in OEMs

Use Case Crypto Operation

Secure Diagnostics MAC or Signature Verification

SecOC MAC Generation/Verification

Secure Boot Signature Verification

FOTA Hash + Signature Validation

Use Case Crypto Operation

Key Exchange ECC (ECDH)

Authentication RSA or ECDSA Challenge Signing

13. Testing & Debugging Tips

• Use test vectors for verifying AES/HMAC/SHA/RSA outputs.

• Use CANoe or CAPL scripts to simulate secure requests.

• Validate key loading in KeyM using diagnostic tools.

• Enable tracing in CSM to track job failures.

14. Standards & Compliance

• ISO 21434 – Cybersecurity lifecycle.

• ISO 26262 – Functional safety compliance.

• NIST SP 800 series – Cryptographic algorithm compliance.

• OEM-specific security frameworks (e.g., VW's SHE, BMW Crypto Layer).

AUTOSAR Crypto Stack – Interview Questions and Answers

Q1. What is the AUTOSAR Crypto Stack, and why is it used in automotive ECUs?
Answer:
The AUTOSAR Crypto Stack provides standardized cryptographic services to ensure security
in automotive ECUs. It is used for secure communication, secure diagnostics, secure boot,
and OTA updates. It helps protect against cyberattacks by offering encryption, decryption,
MAC generation, digital signatures, and key management services.
Q2. What are the main components of the AUTOSAR Crypto Stack?
Answer:
The key components are:
• CryIf (Crypto Interface): Interface for upper layers to request crypto services.
• Csm (Crypto Service Manager): Routes service requests to appropriate crypto
drivers.
• Crypto Drivers (CryHw / CrySw): Actual implementation using hardware or software.
• KeyM (Key Manager): Handles secure key storage and life cycle management.

Q3. How does the CryIf module work in the Crypto Stack?
Answer:
CryIf acts as a unified interface between upper-layer modules (like SecOC or Diagnostic
Security) and the Crypto Service Manager. It abstracts away the complexity of underlying
crypto implementations and provides consistent APIs for services like MAC generation,
encryption, and signature verification.

Q4. What is the role of the CSM (Crypto Service Manager)?

Answer:
CSM handles the orchestration of crypto service requests. It receives requests from CryIf and
decides which crypto driver (hardware or software) to use based on availability and
configuration. It also provides APIs for various crypto operations like encryption, hashing,
signing, etc.

Q5. What types of cryptographic services are supported in the AUTOSAR Crypto Stack?
Answer:
• Symmetric Crypto: AES encryption/decryption, HMAC
• Asymmetric Crypto: RSA, ECC (including ECDSA)
• Hashing: SHA1, SHA256
• Random Number Generation: TRNG, PRNG
• Key Management: Key import/export, derivation, generation, deletion

Q6. What is the difference between CryHw and CrySw?

Answer:
• CryHw: Crypto driver that uses dedicated hardware accelerators (e.g., HSM).
• CrySw: Software-based crypto implementation, often using libraries like wolfSSL or
OpenSSL.
Choice depends on performance, security requirements, and hardware support.

Q7. Explain a real-world use case of AUTOSAR Crypto Stack in vehicles.

Answer:
In Secure Onboard Communication (SecOC), the Crypto Stack is used to generate and verify
MACs to ensure message authenticity. The SecOC module uses CryIf to request a MAC for
each message. The request goes through CSM and is processed by a crypto driver using a
secret key stored in KeyM.

Q8. How does key management work in AUTOSAR Crypto Stack?

Answer:
KeyM (Key Manager) manages the storage and lifecycle of cryptographic keys. It provides
services for key generation, loading, storing (in secure storage), wrapping/unwrapping, and
deleting keys. It ensures that keys are protected from unauthorized access.

Q9. How is the AUTOSAR Crypto Stack involved in Secure Boot?

Answer:
During Secure Boot, the crypto stack verifies the digital signature of the bootloader or
application software. Using a public key stored securely, the CryIf requests a signature
verification through CSM. The result confirms software authenticity before execution.

Q10. What AUTOSAR module typically uses Crypto Stack services for diagnostic security?
Answer:
The DCM (Diagnostic Communication Manager) uses the Crypto Stack for authenticated
diagnostic sessions (e.g., service 0x27 - Security Access). It sends a challenge and verifies the
key or response using crypto services like MAC or digital signatures.

AUTOSAR Crypto Stack – Advanced Interview Q&A

1. What is the AUTOSAR Crypto Stack, and what problem does it solve in automotive
ECUs?
Answer:
The AUTOSAR Crypto Stack standardizes cryptographic functionality across ECUs. It provides
services like encryption, decryption, MAC generation/verification, digital signatures, hashing,
and secure key management. Its main role is to support security-critical operations such as
secure communication (SecOC), secure diagnostics (service 0x27), secure boot, and secure
firmware updates. This ensures authenticity, integrity, and confidentiality of messages and
software.

2. Describe the layered architecture of the AUTOSAR Crypto Stack.

Answer:
The architecture is divided into layers:
• Upper Layers: Modules like SecOC, PduR, DCM, Secure Boot, and application
software.
• CryIf (Crypto Interface): The standard interface exposing cryptographic operations to
upper layers.
• CSM (Crypto Service Manager): Abstracts and routes the requested cryptographic
services to drivers.
• Crypto Drivers:
o CryHw: Uses Hardware Security Modules (HSM).
o CrySw: Uses software crypto libraries (e.g., wolfSSL, mbedTLS).
• Key Management (KeyM): Handles secure key lifecycle and storage.
This architecture ensures modularity and hardware abstraction.

3. What are the types of cryptographic operations supported in AUTOSAR?

Answer:

Category Supported Services

Symmetric Crypto AES (ECB, CBC, GCM), HMAC

Asymmetric Crypto RSA, ECC (e.g., ECDSA, ECDH), signature verification

Hashing SHA-1, SHA-256

Random Generation True Random (TRNG), Deterministic (DRBG)

Key Management Key import, export, wrap, unwrap, generation, deletion

4. What is the purpose of the CryIf module?
Answer:
CryIf acts as a unified interface between upper-layer modules and the Crypto Service
Manager. It abstracts cryptographic functionality and hides underlying implementation
details (HW or SW). It enables the same upper-layer code to work with either hardware-
backed or software crypto drivers.

5. Explain the role and responsibilities of the Crypto Service Manager (CSM).
Answer:
CSM coordinates and manages crypto service requests from CryIf:
• Routes service requests (like encryption, hashing) to the appropriate driver.
• Maintains asynchronous job handling and state tracking (via JobIDs).
• Provides APIs grouped by service categories, e.g., Csm_SymmetricEncryption,
Csm_Hash, Csm_Signature.

6. How are cryptographic keys managed in AUTOSAR?

Answer:
The KeyM (Key Manager) is responsible for:
• Key storage in secure memory (e.g., HSM, EEPROM).
• Key generation (e.g., symmetric or asymmetric).
• Key wrapping/unwrapping for secure exchange.
• Key derivation and deletion.
• Key indexing and referencing for CSM operations.
The actual key material is abstracted via key handles or key IDs.

7. How does AUTOSAR support both hardware and software cryptographic operations?
Answer:
AUTOSAR supports both through Crypto Drivers:
• CryHw: Accesses hardware crypto engines, usually via HSM.
• CrySw: Implements crypto algorithms in software using libraries.
• The choice depends on security needs and hardware capabilities. CSM handles
switching based on configuration.
8. How is the Crypto Stack used in Secure Onboard Communication (SecOC)?
Answer:
• MAC Generation: For outgoing messages, SecOC calls CryIf to generate a MAC using
a shared secret.
• MAC Verification: For incoming messages, CryIf verifies the MAC.
• Keys used for MACs are managed by KeyM.
• Helps ensure message authenticity and freshness.

9. Describe the flow of a MAC generation request using the Crypto Stack.
Answer:
1. SecOC → CryIf: Requests MAC generation with data and key ID.
2. CryIf → CSM: Forwards the request.
3. CSM → Crypto Driver (CrySw or CryHw): Executes the algorithm.
4. Driver → CSM → CryIf → SecOC: MAC is returned.

10. How is the Crypto Stack used in Diagnostic Security (UDS service 0x27)?
Answer:
• The ECU issues a challenge to the tester.
• Tester calculates a key or signature using a shared secret/private key.
• ECU uses the Crypto Stack (via DCM → CryIf → CSM) to verify the tester's response.
• Often involves symmetric MAC or asymmetric signature verification.

11. What are the common error scenarios in Crypto Stack operations and how are they
handled?
Answer:
Some common errors:
• Invalid Key Reference
• Unsupported Algorithm
• Crypto Driver Failure (e.g., HSM not responding)
 • Insufficient Entropy for RNG
Error handling involves:
• Error codes returned via callback mechanisms.
• Diagnostic Event Reporting via DEM (if integrated).
• Recovery strategies like retry, fallback to software crypto, or ECU reset (in secure
boot).

12. How is the Crypto Stack configured in AUTOSAR?

Answer:
Configuration is done via:
• ECU Configuration Description: XML or ARXML files define keys, algorithms, driver
mapping, etc.
• Crypto Job Mapping: Which services are handled by which drivers.
• Key References: Defined using Key IDs and scopes.
• Config tools (like Vector DaVinci Configurator) are used for setup and code
generation.

14. What security standards influence AUTOSAR Crypto Stack design?

Answer:
• ISO 21434 (Cybersecurity)
• ISO 26262 (Functional Safety) – For secure boot and memory integrity.
• NIST SP 800 series – Algorithm compliance.
• OEM-specific security guidelines – Often impose stricter constraints.

15. How does the Crypto Stack support Secure Boot?

Answer:
• Bootloader uses CryIf to verify the digital signature of application firmware.
• Signature is validated using a stored public key (via KeyM).
• If verification fails, the ECU may enter a recovery or fallback mode.
 AUTOSAR Crypto Stack – Advanced & In-Depth Interview Q&A (Part 2)

16. What is the purpose of asynchronous job handling in the Crypto Stack, and how is it
managed?
Answer:
Asynchronous job handling is critical because many cryptographic operations, especially
hardware-based ones, are time-consuming or interrupt-driven. To avoid blocking the main
flow:
• CSM assigns a JobID and returns immediately.
• The job result is reported later via callback notification.
• CryIf manages job status (PENDING, SUCCESS, FAILED).
• Upper layers (e.g., SecOC) must register callbacks to receive job completion.
This improves responsiveness in real-time systems.

17. How is memory handled in the Crypto Stack, especially for key storage?
Answer:
Memory in the Crypto Stack is managed with security and safety in mind:
• KeyM uses secure memory regions like:
o Internal Flash/EEPROM
o HSM NVRAM
o External Secure Elements (SE)
• Key handles or IDs are stored; key material itself is not exposed.
• Memory partitioning ensures isolation of secure vs. non-secure zones.
• Cryptographic buffers are protected (e.g., stack wiping after usage).
• Static configuration is preferred; dynamic allocation is minimal or avoided due to ISO
26262 constraints.

18. How does the AUTOSAR Crypto Stack support firmware-over-the-air (FOTA) updates?
Answer:
During FOTA:
• Software integrity is validated via digital signature verification.
 • The update agent uses CryIf to verify the signature of the downloaded binary.
• The public key is pre-stored securely via KeyM.
• Hashing and signature verification are often performed in chunks to reduce memory
usage.

19. How does the Crypto Stack ensure that keys are not exposed during operation?
Answer:
• Key handles are used instead of actual key material.
• Hardware support (HSM, SE) ensures keys never leave secure memory.
• Software implementations must erase intermediate buffers after usage.
• Key wrapping/unwrapping ensures encrypted key transport between components.

20. What is the role of "Key Properties" in the configuration of the Crypto Stack?
Answer:
Key Properties define:
• Algorithm compatibility (e.g., can the key be used for AES or RSA?)
• Usage type (encryption, MAC, signature, verification)
• Key scope (local, session-based, global)
• Access control (which module can access/use it)
They ensure correct and secure usage of keys per their intended purpose.

21. What are some best practices when configuring the AUTOSAR Crypto Stack?
Answer:
• Use hardware-based crypto wherever possible for performance and tamper
resistance.
• Limit key access only to necessary modules.
• Avoid key reuse across different operations.
• Use strong algorithms with long key lengths (e.g., SHA256, AES-256).
• Always verify return values and handle errors securely.
22. What is the difference between encryption, MAC, and digital signature in AUTOSAR
Crypto usage?
Answer:

Operation Purpose Key Type Example Use

Symmetric or OTA Software

Encryption Confidentiality
Asymmetric Download

Symmetric (shared SecOC, UDS Service

MAC Integrity + Authenticity
secret) 0x27

Digital Integrity + Authenticity + Non- Asymmetric Secure Boot, FOTA

Signature repudiation (private/public) Verification

23. How does the Crypto Stack handle Random Number Generation (RNG)?
Answer:
• CryIf requests RNG services from CSM.
• RNG is typically implemented via:
o TRNG (True Random) from hardware (preferred for security).
o DRBG (Deterministic RNG) seeded with entropy.
• Used for challenge generation, session key creation, or cryptographic nonce.
• KeyM ensures that the entropy pool is regularly reseeded.

24. How can performance be optimized in the AUTOSAR Crypto Stack?

Answer:
• Use hardware-accelerated crypto drivers.
• Offload tasks like MAC or signature generation to HSM.
• Avoid unnecessary copying of data buffers.
• Use job queuing in CSM to batch similar crypto tasks.
• Limit key length and algorithm complexity only to what's needed (e.g., ECC over RSA
for performance).

25. What are the limitations or challenges in deploying the AUTOSAR Crypto Stack?
Answer:
• Requires secure key provisioning at manufacturing time.
• Hardware dependency: not all platforms have HSM.
• Performance overhead if crypto is done in software.
• Complexity in managing key life cycles and synchronization across ECUs.
• Certification of crypto libraries for ISO 26262 compliance.

26. How does the Crypto Stack integrate with Secure Diagnostics (Authentication
methods)?
Answer:
• ECU uses service 0x27 (Security Access) or 0x29 (Authentication).
• Tester receives a challenge, signs or encrypts it.
• ECU uses CryIf to verify the response using a shared key (HMAC) or public key
(signature).
• The key or certificate is managed by KeyM.

27. How are crypto operations tested or verified during development?

Answer:
• Use of test vectors for known algorithms (NIST standards).
• Tools like DaVinci Developer/Configurator, Vector CANoe, and cryptographic test
benches.
• ECU Test or CAPL scripts to simulate authentication or secure message exchanges.
• Mock KeyM for unit testing when HSM isn’t available.

28. What is a Secure Element (SE), and how is it used in the Crypto Stack?
Answer:
A Secure Element is a tamper-resistant hardware component (e.g., TPM, SAM chip) used to:
• Store keys securely.
• Perform crypto operations in isolation.
• Communicate with the Crypto Stack via a driver or external API.
• Often used in high-security OEM requirements.
29. How is certificate-based authentication supported in the AUTOSAR Crypto Stack?
Answer:
• Certificates are stored securely (or fetched externally).
• During communication or bootup, digital signatures are verified using public keys
from the certificate.
• The Crypto Stack (CryIf/CSM) can verify certificate chains and signatures.
• May integrate with X.509 parsing libraries outside AUTOSAR if needed.

30. In what cases would you choose a software crypto driver over a hardware one?
Answer:
• During early development or simulation, when hardware is unavailable.
• When performance and attack resistance are less critical.
• On low-cost ECUs that lack an HSM or secure crypto engine.
• For fallback or debug modes when HSM fails.