Add initial version of Feature Request for Crypto & Security in docs. #1490
Conversation
Change-Id: Ie816f6354dba2e35b1dc5994001af4e3f51b1fb0
|
The created documentation from the pull request is available at: docu-html |
| * The cryptographic subsystem should be aware that certain attacks will try to observe the overall | ||
| system to analyze its inner workings to guess secrets (side channel/timing attacks) or to influence | ||
| it to limit its availability for system critical tasks. | ||
|
|
There was a problem hiding this comment.
HW separation to specify what is done in S-CORE and what in a TEE/HSW/Hardware and many supported by the OS as well. To be detailed.
Think if combination of key mangmt and cert mngmt possible.
Potentially del line 72
|
|
||
| * The cryptographic subsystem typically needs to 'rely on hardware acceleration' to execute operations | ||
| efficiently or to access a TRNG (True random number generator) for entropy. Additionally, it MAY be a | ||
| good idea to as well have a software-only solution. |
There was a problem hiding this comment.
Considering PQC and using SW for that if the HW may not support it.
| to ensure it is protected (memory, CPU) from applications and the normal operating system while still offering its functionality to | ||
| applications and middleware services. | ||
| * 'Time' in the sense of real world wall clock is crucial for the cryptographic subsystem to ensure | ||
| that for example a certificate or token is only used within its validity period. |
There was a problem hiding this comment.
Integrity of time should be an additional requirement (e.g. signed by a backend and verified on S-CORE).
| * The cryptographic subsystem typically needs to 'rely on hardware acceleration' to execute operations | ||
| efficiently or to access a TRNG (True random number generator) for entropy. Additionally, it MAY be a | ||
| good idea to as well have a software-only solution. | ||
| * Will use system level means (co-processor, hardware security module, Trusted Execution Environment, ...) |
There was a problem hiding this comment.
Add that we want to rely on HW as primary computational resource and add as well a SW algorithm if the HW does not support specific cases)
| | | ||
| | | ||
| |------------------| | ||
| | KeyStore | |
There was a problem hiding this comment.
Local in-device key generation and derivate strategies is still missing and should be considered.
| | --> Signature (create / verify) | ||
| | --> Symmmetic crypto (encrypt, decrypt) | ||
| | --> KeyMngmt (generate, import, update, delete, check) | ||
| | --> CertificateManagement (add, update, verify) |
There was a problem hiding this comment.
Certificates could be protected by means of filesystem OS protection means and ACLs.
| * Key exchange (ECDH) | ||
| * Hashing (SHA-2, SHA-3, BLAKE3) | ||
| * Random number generation (ChaCha20Rng) | ||
|
|
There was a problem hiding this comment.
Potentially missing here are RSA for a-sym, EDDSA, MLDSA, SLDSA.
There was a problem hiding this comment.
Need maybe a stakeholder requirement for other markets, e.g. China.
|
|
||
| Finally the security subsystem needs to consider the production scenario where potentially several | ||
| 'initial production keys' are brought into the system. | ||
|
|
There was a problem hiding this comment.
ACL for the APIs - add this as well. (manifest, whitelist/blacklist)
| Following the white house cybersecurity plan and other industry voices to improve robustness of | ||
| critical systems by using memory safe languages S-CORE decided to have Rust as a 1st class | ||
| citizen. The security subsystem SHALL be developed entirely in Rust. | ||
|
|
There was a problem hiding this comment.
Compatibility with existing and already hardened libraries in C++.
In general I admit the feature request is not the place to take a design decision right here.
| * Trusted computing environmeent / HSM | ||
| * Roles and capability rights management | ||
| * Connection to IDS / anomaly detection | ||
| * Zero trust - BS or where to use ? |
There was a problem hiding this comment.
- Defense in depth, least right privilege;
- Assumptions of use of the overall system not being directly exposed to the internet but behind further security controls.
| * OS security mechanisms | ||
| * Trusted computing environmeent / HSM | ||
| * Roles and capability rights management | ||
| * Connection to IDS / anomaly detection |
There was a problem hiding this comment.
Potentially add that a tamper proof-able or tamper-detetable log/journal is in used.
There was a problem hiding this comment.
- Time budget, observation and process observation.
|
|
||
| Post quantum readiness | ||
| ---------------------- | ||
|
|
There was a problem hiding this comment.
Latest version of WolfSSL, latest version and OpenSSL,v 3.5 already have support here.
| Due to the nature of our overall system to be deployed for 10+ years in an embedded systems | ||
| such a security plan needs to as well cover 'software-update strategy', 'field observation', 'crypto | ||
| algorithm updates', 'repairability', and 'whitstand reverse engineering of secrets'. | ||
|
|
There was a problem hiding this comment.
Use "best practices" and follow industry standards like ISO21434.
originates from CR #132926