SNIP_ADAPTIVE_CRYPTO_FIGURE_Figure_7_7

Figure 7.7: Key deployment [SWS_CRYPT_10005]{DRAFT} ⌈The interface ara::crypto::keys::KeyStorageProvider::LoadKeySlot shall return the KeySlot instance that represents the key slot resource identified by the provided ara::core::InstanceSpecifier, or return kAccessViolation, if SWS_CRYPT_10000 is not fulfilled. ⌋(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 responsible for access control to internally stored cryptographic objects. All back-end KSP are hidden from the consumers (under public CryptoAPI). [SWS_CRYPT_10004]{DRAFT}⌈The FC Crypto shall ensure confidentiality and authenticity 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.⌋(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 represent 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.