Andy - chapter 2
Closed this issue · 1 comments
Chapter2 review
2.2.1 -Known (documented) attacks except Spectre v1 are specific to particular micro- architectures, and RISC-V systems are not expected to be vulnerable to those. This
is an evolving area of research.
This needs to state it is essential that the microarchitecture does not introduce speculation-based vulnerabilities, and is implementation dependent
2.2.2
Analysis of physical leakage - the recommendation ‘Implement robust power management and radiation control’ seems a little vague. Id prefer to state ‘Implement robust leakage protections such as masking, and constant time coding’ or similar
Boot attacks - recommend to add code hardening as a bullet, (maybe mention double checks on critical decision points, avoid infinite loops on fail but this is probably too detailed)
2.3.2
Top of page 14 of the PDF – ‘there are use case’ should be ‘these are use case’
‘Secured - the system is fully locked down and has all its hardware provisioned assets’ – maybe ‘Secured - the system is in an operational usage state and has all its hardware provisioned assets’
2.3.4 Page 16 –
Talks about ‘trusted signers’. Would ‘signed by a trusted authority’ be better
‘Direct verification requires a signed image autorization from a trusted signer
For example, a signed image header, or a separately signed authorization message’
Shouldn’t this say
Direct verification requires a signed image authorization from a trusted authority
For example, a signed image, or a separately signed authorization message’
2.2.1 -Known (documented) attacks except Spectre v1 are specific to particular micro- architectures, and RISC-V systems are not expected to be vulnerable to those. This is an evolving area of research.
This needs to state it is essential that the microarchitecture does not introduce speculation-based vulnerabilities, and is implementation dependent
Rephrased to "Known (documented) attacks except Spectre v1 are specific to particular
micro-architectures. Micro-architecture for RISC-V systems is implementation specific, but must not introduce such vulnerabilities."
2.2.2 - Analysis of physical leakage - the recommendation ‘Implement robust power management and radiation control’ seems a little vague. Id prefer to state ‘Implement robust leakage protections such as masking, and constant time coding’ or similar
This section is about physical leakage - voltage or actual radiation, for example.
Data independent latency is already listed in mitigations.
2.2.2 - Boot attacks - recommend to add code hardening as a bullet, (maybe mention double checks on critical decision points, avoid infinite loops on fail but this is probably too detailed)
Added: "Code hardening (for example, see https://www.riscure.com/publication/practical-steps-evaluate-protect-secure-boot-implementations-embedded-devices/[Riscure white paper])"
2.3.2 Top of page 14 of the PDF – ‘there are use case’ should be ‘these are use case’
Done.
2.3.2 ‘Secured - the system is fully locked down and has all its hardware provisioned assets’ – maybe ‘Secured - the system is in an operational usage state and has all its hardware provisioned assets’
Changed to: "hardware provisioned assets are locked (immutable), only authorized software can be used, and revealing debug is not enabled"
Also added a formal definition of "revealing debug" - see latest draft.
2.3.4 - Talks about ‘trusted signers’. Would ‘signed by a trusted authority’ be better
Changed "signer" to "authority".
Changed to:
- Direct verification requires a signed image authorization from a trusted authority for loading an image +
For example, a signed image, or a separately signed authorization
message. - Indirect verification requires a signed authorization from a trusted authority for migrating assets bound to a measured state +
For example, a signed provisioning message.