Transcription
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Document TitleRequirements on Crypto StackDocument OwnerDocument ResponsibilityDocument Identification NoAUTOSARAUTOSAR426Document StatusPart of AUTOSAR StandardPart of Standard ReleaseFinalClassic Platform4.3.1Document Change HistoryDateRelease Changed istrationAUTOSARAdministrationChange Description Default error detection renamed todevelopment error detection Editorial changes Added requirements for the wholeCrypto Stack and renamed thedocument Introduced crypto job concept Introduced key managementconcept Editorial changes Editorial changes TPS STDT 0078 formatting Traceability ofBSWAndRTE Features Initial release1 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1DisclaimerThis work (specification and/or software implementation) and the material containedin it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR andthe companies that have contributed to it shall not be liable for any use of the work.The material contained in this work is protected by copyright and other types ofintellectual property rights. The commercial exploitation of the material contained inthis work requires a license to such intellectual property rights.This work may be utilized or reproduced without any modification, in any form or byany means, for informational purposes only. For any other purpose, no part of thework may be utilized or reproduced, in any form or by any means, without permissionin writing from the publisher.The work has been developed for automotive applications only. It has neither beendeveloped, nor tested for non-automotive applications.The word AUTOSAR and the AUTOSAR logo are registered trademarks.2 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Table of Contents1Scope of Document . 42Conventions to be used . 53Acronyms and abbreviations . 63.14Glossary of Terms . 7Functional Overview . 84.15Supported Algorithms . 8Requirements Specification. 105.1Functional Requirements . 105.1.1 Crypto Stack . 105.1.2 Crypto Service Manager . 195.1.3 Crypto Interface . 225.1.4 Crypto Driver . 245.2Non-Functional Requirements (Qualities) . 265.2.1 General . 265.2.2 Crypto Service Manager . 265.2.3 Crypto Interface . 275.2.4 Crypto Driver . 286Requirements Tracing . 297References . 317.17.2Deliverables of AUTOSAR . 31Related standards and norms . 313 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.11 Scope of DocumentThis document specifies the requirements of the crypto stack: Crypto Service Manager (Csm), Crypto Interface (CryIf) and Crypto Driver (Crypto).4 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.12 Conventions to be used The representation of requirements in AUTOSAR documents follows the tablespecified in [TPS STDT 00078]. In requirements, the following specific semantics shall be used (based on theInternet Engineering Task Force IETF).The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this document are to be interpreted as: SHALL: This word means that the definition is an absolute requirementof the specification.SHALL NOT: This phrase means that the definition is an absoluteprohibition of the specification.MUST: This word means that the definition is an absolute requirementof the specification due to legal issues.MUST NOT: This phrase means that the definition is an absoluteprohibition of the specification due to legal constraints.SHOULD: This word, or the adjective "RECOMMENDED", mean thatthere may exist valid reasons in particular circumstances to ignore aparticular item, but the full implications must be understood andcarefully weighed before choosing a different course.SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED"mean that there may exist valid reasons in particular circumstanceswhen the particular behavior is acceptable or even useful, but the fullimplications should be understood and the case carefully weighedbefore implementing any behavior described with this label.MAY: This word, or the adjective „OPTIONAL“, means that an item istruly optional. One vendor may choose to include the item because aparticular marketplace requires it or because the vendor feels that itenhances the product while another vendor may omit the same item.An implementation, which does not include a particular option, MUSTbe prepared to interoperate with another implementation, which doesinclude the option, though perhaps with reduced functionality. In thesame vein an implementation, which does include a particular option,MUST be prepared to interoperate with another implementation, whichdoes not include the option (except, of course, for the feature the optionprovides.)5 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.13 Acronyms and abbreviationsAbbreviation /Acronym:µCAESCBCCDDCFBCMACCPUCRYPTO /CryptoCRYIF / CryIfCSM / CsmCTRDEM / DemDET / DetECBECCECDHECDSAECIESECUGCMGMACHMACHSM / SECOC ed Encryption StandardCipher Block ChainingComplex Device DriverCipher FeedbackCipher-based Message Authentication CodeCentral Processing UnitCrypto DriverCrypto InterfaceCrypto Service ManagerCounterDiagnostic Event ManagerDefault Error TracerElectronic Code BookElliptic Curve CryptographyElliptic Curve Diffie–HellmanElliptic Curve Digital Signature AlgorithmElliptic Curve Integrated Encryption SchemeElectronic Control UnitGalois Counter ModeGalois-based Message Authentication CodeHash-based Message Authentication CodeHardware Security ModuleHardWareKey Encapsulation MechanismMessage Authentication CodeMicro Controller Abstraction LayerOriginal Equipment ManufacturerOutput FeedbackPublic Key InfrastructurePseudo-Random Number GeneratorRapid Automatic Cryptographic EquipmentRandom Access MemoryRACE Integrity Primitives Evaluation Message DigestRivest-Shamir-Adleman CryptosystemRun Time EnvironmentSecure Hash AlgorithmSecure Onboard CommunicationSoftWareSoftWare ComponentSoftWare SpecificationTrue Random Number Generator6 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1ViXEXXTS3.1VendorIdXor-Encrypt-XorXEX-based tweaked-codebook mode with ciphertext stealingGlossary of TermsTerms:Description:Crypto DriverObjectA Crypto Driver Object is an instance of a crypto module (hardwareor software), which is able to perform one or more different cryptooperations.UserA user is a configured object with an ID and configured jobs.ChannelA channel is the path from a Crypto Service Manager queue via theCrypto Interface to a specific Crypto Driver Object.JobA job is an instance of a user’s configured cryptographic primitive.Crypto Primitive A crypto primitive is an instance of a configured cryptographicalgorithm.OperationAn operation of a crypto primitive declares what part of the cryptoprimitive shall be performed. There are three different operations:STARTOperation indicates a new request of a crypto primitive,and it shall cancel all previous requests.UPDATE Operation indicates, that the crypto primitive expectinput data.FINISHOperation indicates, that after this part all data are fedcompletely and the crypto primitive can finalize thecalculations.It is also possible to perform more than one operation at once byconcatenating the corresponding bits of the operation modeargument.PriorityThe priority of a user defines the importance of it. The higher thepriority (as well in value), the more immediate the user's job will beexecuted. The priority of a cryptographic job is part of the user’sconfiguration.Secure Counter “Secure” in the context of Secure Counter means, that the countershall be secured against direct access of the user. Thus, for ameaningful implementation, the Secure Counter should be residentin a special secured nonvolatile ROM (e.g. in an HSM)7 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.14 Functional OverviewThe Crypto Stack offers a standardized access to cryptographic services for applicationsand system functions.The cryptographic services are, e.g., the computation of hashes, the verification ofasymmetrical signatures, or the symmetrical encryption of data. These services dependon underlying cryptographic primitives and cryptographic schemes. The CSM shall makeit possible for different applications to use the same service but using different underlyingprimitives and/or schemes. E.g., one application might need to use the hash service tocompute an SHA2 digest and another might need to compute an SHA1 digest. Or oneapplication might need to verify a signature which has been computed with the RSASSAPKCS1-V1 5 signature scheme and using SHA1 as an underlying hash primitive, whileanother application might need to verify a signature computed with a different schemewhich uses SHA2 as an underlying hash primitive. The Crypto Stack shall make itpossible to configure which services are needed and to create several configurations foreach service where schemes and primitives can be chosen.Furthermore, since the computation of many of the cryptographic services is verycomputation intensive, provisions have to be made for scheduling these longcomputations. The jobs shall be configurable to be executed synchronously orasynchronously.The Crypto Stack provides services with cryptography functionality, based on softwarelibrariesor on hardware modules. Also, mixed setups are possible, for example if a hardwaremodule cannot supply the necessary functionality on its own. In the following, we refer toall instantiations of underlying functionality, be it hardware or software, as "crypto library".4.1Supported AlgorithmsThe following cryptographic algorithms or primitives should be supported by the CryptoStack: Random Number Generationo Deterministic Random Number Generator (DRNG)o True Random Number Generator (TRNG)Symmetric Encryptiono AES Key Length: 128 and 256 bits Modes: ECB, CBC, CTR, GCM, OFB, CFB, XTSo PRESENT Key Length: 128 bits Modes: ECB, CBC, CTR, GCM, OFB, CFB, XTSo ChaCha12/ChaCha20 Key Length: 256 bitsAsymmetric Encryption/Decryption and Signature Handlingo RSA Key Length: 1024, 2048, 3072, 4096 Padding: PKCS#1 v2.2o Curve25519/Ed25519Hasho SHA-2 Length: 224, 256, 384, 5128 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1 o SHA-3 Length: 224, 256, 384, 512o BLAKE Length: 224, 256, 384, 512o RIPEMD-160MACo CMACo GMACo HMAC9 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.15 Requirements Specification5.1Functional Requirements5.1.1 Crypto Stack5.1.1.1 General5.1.1.1.1 [SRS CryptoStack 00100] Synchronous Job Processing⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Material:ValidSome crypto services shall allow synchronous job processing.There are some crypto services which can be calculated very fast and arerequired very fast. Then, the overhead of the asynchronous job processingincluding main function calls and call back functions, is too big.MAC generation for the SecOC module---⌋(RS BRF 01456)5.1.1.1.2 [SRS CryptoStack 00101] Asynchronous Job Processing⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Material:ValidSome crypto services shall allow asynchronous job processing.There are some crypto services which require a lot of time or are executedin an HSM. Then, synchronous job processing would require too much time.Signature verification---⌋(RS BRF 01456)5.1.1.1.3 [SRS CryptoStack 00003] The crypto stack shall be able to incorporatemodules of the crypto library⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Material:ValidThe crypto stack shall be able to incorporate modules of a crypto library.The crypto library itself has to be available in the AUTOSAR stack.SW implementation of cryptographic primitives.---⌋(RS BRF 02032)5.1.1.2 Configuration5.1.1.2.1 [SRS CryptoStack 00007] The Crypto Stack shall provide scalability for thecryptographic features⌈Type:Valid10 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Description:The Crypto Stack shall guarantee that the unused cryptographic features are notcompiled into the binary.Rationale:Different security features require different encryption solutions (example:symmetric/asymmetric encryption, hashing) with or without hardware support. Thehardware profiles available offer different features (example: internal NVM, counters,random number generator, secure CPU core ). Scalability of cryptographic featuresallow different strategies for implementation if some features are not required and thusminimize SW or HW resource utilization.Use Case:The mapping between crypto stack and the functionalities of microcontroller hardwareallows hardware vendors to develop generic drivers for their HSMs.Dependencies:--SupportingMaterial:--⌋(RS BRF 01456, RS BRF 02031 )5.1.1.2.2 [SRS CryptoStack 00008] The Crypto Stack shall allow static configurationof keys used for cryptographic jobs⌈Type:ValidDescription:The Crypto Stack shall allow static configuration of symmetric and asymmetric keypairs used for crypto services.Rationale:It shall be possible to use keys individually.Use Case:Data encryption with a protected key in the HSM.Dependencies:--SupportingMaterial:--⌋(RS BRF 02031, RS BRF 01946 )5.1.1.2.3 [SRS CryptoStack 00105] The Crypto Stack shall only allow unique keyidentifiers⌈Type:ValidDescription:There is one keyId configured for each cryptographic key.Rationale:It shall be possible to treat keys individually.Use Case:Usage of cryptographic keys.Dependencies:--SupportingMaterial:--⌋(RS BRF 02031, RS BRF 01946 )11 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.15.1.1.2.4 [SRS CryptoStack 00013] The modules of the crypto stack shall supportonly pre-compile time configuration⌈Type:ValidDescription:The modules of the crypto stack shall support only pre-compile time configuration.Rationale:No applicable post-build or link-time parametersUse Case:All the configurable parameter values must be decided before compile or build time.Dependencies:--SupportingMaterial:--⌋(RS BRF 01136)5.1.1.2.5 [SRS CryptoStack 00094] The configuration files of the crypto stackmodules shall be readable for human beings⌈Type:Description:ValidThe configuration files of the crypto stack modules shall be readable forhuman beings:e.g. by integration of comments or by tool – support.Rationale:Human being have to read and understand the configuration. So theconfiguration shall be readable and understandable for human being.Debugging---Use Case:Dependencies:Supporting Material:⌋( RS BRF 01456)5.1.1.3 InitializationNone5.1.1.4 Normal Operation5.1.1.4.1 [SRS CryptoStack 00009] The Crypto Stack shall support reentrancy for allcrypto services⌈Type:ValidDescription:The Crypto Stack shall support reentrancy of crypto related interfaces to enableparallel operations of the same or different type when requested by multiple users.This requirement also covers scenarios where applications are residing on differentcores.Rationale:Crypto jobs shall be processable simultaneously12 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Use Case:Different applications may use cryptographic services in parallel. Handling of differenttasks at the same time is RS BRF 02033 )5.1.1.4.2 [SRS CryptoStack 00010] The Crypto Stack shall conceal symmetric keysfrom the users of crypto services⌈Type:ValidDescription:There shall be no interface to extract symmetric key values directly to the user. Keysshall be addressed via identifiers by the users.Rationale:Such keys shall only be exported in an encrypted format.If keys are stored in the application, this increases the chances of invalidation of keysor keys being compromised.Use Case:Keys residing in the HSMDependencies:--SupportingMaterial:--⌋(RS BRF 02031, RS BRF 01946 )5.1.1.4.3 [SRS CryptoStack 00011] The Crypto Stack shall conceal asymmetricprivate keys from the users of Crypto services⌈Type:ValidDescription:There shall be no interface to extract asymmetric private key values directly to theuser. Keys shall be addressed via identifiers by the Users.Such keys shall only be exported in an encrypted format.Rationale:If keys are stored in the application, this increases the chances of invalidation of keysor keys being compromised.Use Case:Keys residing in the HSMDependencies:--SupportingMaterial:--⌋(RS BRF 02031, RS BRF 01946 )5.1.1.4.4 [SRS CryptoStack 00019] The Crypto Stack shall identify random numbergeneration as a cryptographic primitive which can be requested to a driver⌈Type:Valid13 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Description:Rationale:The Crypto Stack shall identify random number generation as a cryptographicprimitive which can be requested to a driver.Random number Generators residing on different crypto drivers should be accessedusing a homogenous interface.Use Case:Generate random numberDependencies:--SupportingMaterial:--⌋(RS BRF 02031 )5.1.1.4.5 [SRS CryptoStack 00020] The Crypto Stack shall identify symmetricencryption/decryption as a cryptographic primitive which can be requestedto a driver⌈Type:ValidDescription:The Crypto Stack shall identify symmetric encryption/decryption as a cryptographicprimitive which can be requested to a driver.Symmetric algorithms residing on different crypto drivers should be accessed using ahomogenous interface.Rationale:Use Case:Encrypted ��(RS BRF 02031 )5.1.1.4.6 [SRS CryptoStack 00021] The Crypto Stack shall identify asymmetricencryption/decryption as a cryptographic primitive which can be requestedto a driver⌈Type:ValidDescription:The Crypto Stack shall identify asymmetric encryption/decryption as a cryptographicprimitive which can be requested to a driver.Rationale:Asymmetric algorithms residing on different crypto drivers should be accessed using ahomogenous interface.Use Case:Unique Interface for success of heterogeneous hardware- and l:--⌋(RS BRF 02031 )14 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.15.1.1.4.7 [SRS CryptoStack 00022] The Crypto Stack shall identify MACgeneration/verification as a cryptographic primitive which can be requestedto a driver⌈Type:ValidDescription:The Crypto Stack shall identify MAC generation/verification as a cryptographicprimitive which can be requested to a driver.Rationale:MAC algorithms residing on different crypto drivers should be accessed using ahomogenous interface.Use Case:SecOC using MACs to verify messagesDependencies:--SupportingMaterial:--⌋(RS BRF 02031 )5.1.1.4.8 [SRS CryptoStack 00023] The Crypto Stack shall identify asymmetricsignature generation/verification as a cryptographic primitive which can berequested to a driver⌈Type:Description:ValidThe Crypto Stack shall identify asymmetric signature generation/verification as acryptographic primitive which can be requested to a driver.Rationale:Asymmetric signature algorithms residing on different crypto drivers should beaccessed using a homogenous interface.Use Case:Signature rial:--⌋(RS BRF 02031 )5.1.1.4.9 [SRS CryptoStack 00024] The Crypto Stack shall identify hash calculationas a cryptographic primitive which can be requested to a driver⌈Type:ValidDescription:The Crypto Stack shall identify hash calculation as a cryptographic primitive which canbe requested to a driver.Rationale:Hash algorithms residing on different crypto drivers should be accessed using ahomogenous interface.15 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Use Case:Signature �(RS BRF 02031 )5.1.1.4.10 [SRS CryptoStack 00026] The Crypto Stack shall provide an interface forthe generation of asymmetric keys⌈Type:ValidDescription:The Crypto Stack shall provide an abstracted interface for the generation ofasymmetric key pair service.Rationale:Key generation services residing on different Crypto drivers should be accessed usinga homogenous interface.Use Case:Dependencies:SupportingMaterial:Generation of an asymmetric key pair inside the ECU. Then, the private key never hasto be available outside the ECU.---⌋(RS BRF 02031 )5.1.1.4.11 [SRS CryptoStack 00027] The Crypto Stack shall provide an interface forthe generation of symmetric keys⌈Type:ValidDescription:The Crypto Stack shall abstract the user from multiple symmetric keys stored byvarious Crypto Drivers through a standardized interface. Also, it shall provide aninterface to the driver for generation of such keys.Rationale:Key generation services residing on different Crypto drivers should be accessed usinga homogenous interface.Use Case:Password-based key inputDependencies:--SupportingMaterial:--⌋(RS BRF 02031 )5.1.1.4.12 [SRS CryptoStack 00103] The Crypto Stack shall provide an interface forthe derivation of symmetric keys⌈Type:ValidDescription:The Crypto Stack shall abstract the user from multiple symmetric keys stored byvarious Crypto Drivers through a standardized interface. Also, it shall provide aninterface to the driver for derivation of such keys.16 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Rationale:Key derivation services residing on different Crypto drivers should be accessed usinga homogenous interface.Use Case:Password-based key inputDependencies:--SupportingMaterial:--⌋(RS BRF 02031 )5.1.1.4.13 [SRS CryptoStack 00028] The Crypto Stack shall provide an interface forkey exchange mechanisms⌈Type:ValidDescription:The Crypto Stack shall support key exchange mechanism as a key managementinterfaceKey exchange algorithms residing on different crypto drivers should be accessedusing a homogenous interfaceRationale:Use Case:Session handlingDependencies:--SupportingMaterial:--⌋(RS BRF 02031 )5.1.1.4.14 [SRS CryptoStack 00029] The Crypto Stack shall provide an interface forkey wrapping/extraction mechanisms⌈Type:ValidDescription:The Crypto Stack shall support key wrapping (encapsulation) and extractionmechanism forward such requests from CSM to the respective driver. It shall supportwrapping using a symmetric key as well as asymmetric key.Rationale:Key wrapping and encapsulation algorithms implemented in the driver shall not beaccessed directly by the users and need to be abstracted.Use Case:Session handlingDependencies:--SupportingMaterial:--⌋(RS BRF 02031 )5.1.1.4.15 [SRS CryptoStack 00030] The Crypto Stack shall identify a secure counteras cryptographic primitive with various operations⌈17 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Type:ValidDescription:The Crypto Stack shall provide interface to the Crypto Driver for secure counter.The following operations shall be possible on a counter:1. read counter2. increment counterRationale:Note: “Secure” in the context of Secure Counter means, that the counter shall besecured against direct access of the user. Thus, for a meaningful implementation, theSecure Counter should be resident in a special secured nonvolatile ROM (e.g. in anHSM)Counters maintained by the driver shall not be accessed directly by the users andneed to be abstracted.Use Case:Keep a counter in secured areas of an HSMDependencies:--SupportingMaterial:--⌋(RS BRF 01946 )5.1.1.4.16 [SRS CryptoStack 00031] The Crypto Stack shall provide an interface forparsing certificates⌈Type:ValidDescription:The Crypto Stack shall support parsing certificates and extracting the contained keysRationale:The crypto driver shall parse incoming certificates and store the key information in thecorresponding keyUse Case:For PKI it is necessary to obtain public keys out of �(RS BRF 01946 )5.1.1.4.17 [SRS CryptoStack 00061] The Crypto Stack shall support detection ofinvalid keys⌈Type:ValidDescription:The implementation of a cryptographic primitive shall detect and reject invalid keys.Rationale:Use Case:Algorithms like RSA or several ECC flavors know keys which can be used to performthe mathematical foundation of the algorithm without an error but address specialcorner cases and are not secure to handle. Keys like that have to be identified andrejected. There is no generic approach hence the implementation has to be in thecryptographic primitive itself or, in case hardware is used, in its driver.RSA and several Elliptic Curve CryptosystemsDependencies:--18 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1SupportingMaterial:--⌋(RS BRF 02031, RS BRF 01946 )5.1.1.5 Shutdown OperationNone5.1.1.6 Fault OperationNone5.1.2 Crypto Service Manager5.1.2.1 General5.1.2.1.1 [SRS CryptoStack 00006] Each primitive of the CRYIF shall belong toexactly one service of the CSM⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Material:ValidEach primitive of the CRYIF shall belong to exactly one service of the CSM.There are channels which map a user specific crypto primitive via the CRYIFto the underlying Crypto Driver module.The CRYIF is responsible for each service to map to the correspondingCrypto Driver module---⌋(RS BRF 02032)5.1.2.2 Configuration5.1.2.2.1 [SRS CryptoStack 00079] The job processing mode (synchronous orasynchronous) of a CSM service shall be defined by static configuration⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Material:ValidThe mode of cryptographic jobs provided by the CSM shall be defined bystatic configuration.It shall not be possible to change the behavior of a specific CSM serviceduring runtime.Synchronous hash calculation---⌋( RS BRF 01456, RS BRF 01136)5.1.2.2.2 [SRS CryptoStack 00102] The priority of a user and its crypto jobs shall bedefined by static configuration⌈Type:Description:ValidThe user’s priority shall be defined by static configuration. All jobs of thatuser inherit that priority.19 of 31Document ID 426: AUTOSAR SRS CryptoStack- AUTOSAR confidential -
Requirements on Crypto StackAUTOSAR CP Release 4.3.1Rationale:Use Case:Dependencies:Supporting Material:There are crypto jobs which have to processed very fast (e.g. MACgeneration for the SecOC). Other crypto jobs (e.g. hashing over the wholeROM) take very long but are not time critical.Prioritized job processing---⌋()5.1.2.2.3 [SRS CryptoStack 00080] The set of cryptographic services provided by theCSM shall be defined by static configuration⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Material:ValidThe set of cryptographic services provided by the CSM shall be defined bystatic configuration.It is not possible during runtime to add new CSM services.If symmetrical encryption is supported by the driver, it has to be configuredwhich user with which is key is using it.---⌋( RS BRF 01456, RS BRF 01136)5.1.2.2.4 [SRS CryptoStack 00081] The CSM module specification shall specifywhich other modules are required⌈Type:Description:Rationale:Use Case:Dependencies:Supporting Mat
Requirements on Crypto Stack AUTOSAR CP Release 4.3.1 8 of 31 Document ID 426: AUTOSAR_SRS_CryptoStack - AUTOSAR confidential - 4 Functional Overview The Crypto Stack offers a standardized access to cryptographic services for applications and system functions. The cryptographic services
