AoU Component Requirements#
Crypto Component AoU
|
status: draft
security: YES
safety: ASIL_B
|
||||
Hash Assumptions of Use#
Use canonical hash identifiers
|
status: valid
security: YES
safety: QM
|
||||
The component user shall select SHA-256, SHA-384, and SHA-512 with the
canonical identifiers |
|||||
Allocate hash output from the reported digest size
|
status: valid
security: YES
safety: QM
|
||||
The component user shall provide a writable output buffer whose size is at
least the value returned by |
|||||
Verify provider and mechanism availability
|
status: valid
security: YES
safety: QM
|
||||
The integrator shall ensure that the selected provider is configured and available. For a PKCS#11 provider, the selected token shall advertise the required SHA mechanism. Applications shall handle an unsupported-algorithm or provider-unavailable result without assuming a silent provider fallback. |
|||||
Keep caller-owned buffers valid for each hash call
|
status: valid
security: YES
safety: QM
|
||||
The component user shall keep input and output buffers valid and unmodified
for the duration of the corresponding synchronous |
|||||
Handle daemon and operation failures
|
status: valid
security: YES
safety: QM
|
||||
The component user shall check every returned |
|||||
Do not claim safety qualification for the current hash path
|
status: valid
security: YES
safety: ASIL_B
|
||||
The integrator shall not use the current client, IPC and shared-memory, daemon, and OpenSSL or PKCS#11 hash path as an ISO 26262-qualified safety mechanism unless the complete deployed path has been independently qualified and the resulting safety case explicitly permits that use. |
|||||
Restrict new migrations to approved hash algorithms
|
status: valid
security: YES
safety: QM
|
||||
New Baselibs migrations shall use |
|||||