We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
from @kentindell (thanks Ken!):
7.2 Secure hardware There is an additional set of requirements on the security gateway not met by the Canis Labs gateway: a secure hardware platform (the Canis Labs gateway predates the wide availability of secure MCU hardware). A secure hardware platform should: - Resist physical exfiltration of data (e.g. prevent reading out of configuration data and firmware via a JTAG connector) - Not permit reprogramming by unauthorized firmware (i.e. there should be a secure boot process) - Store encryption keys securely so that if software in the MCU is compromised (by an RCE, for example) then the keys cannot be read out The above requirements can be met with an MCU that includes an SHE+ HSM. Today these are widely available devices. Hardware encryption should anyway be included for performance reasons. 7.3 Rollback resistance The rollback to a previous version of firmware should be prevented: it is a common attack to force the existing firmware to fail on boot and for a system to boot from an older copy kept the system. The reason for keeping an old version of the firmware is normally to prevent a system from being bricked if power is lost during programming (see earlier discussion) but once the system has been securely upgraded then the previous version should be erased. The same operation applies to cryptographic keys: any previous version of a key should be erased once the operation has completed correctly. 7.4 Secure programming language There are well-known programming weaknesses that cause problems, such as buffer overflows. Many of these are due to inherently dangerous languages such as C. The Canis Labs gateway firmware is written in C because of availability of tools at the time. Today the SPARK Ada subset would be more appropriate to a high security application: there are formal verification tools of the type that hardware design has been using for some years, plus the open source tools now can generate code for Arm Cortex M and RISC-V based MCUs. If custom hardware is used for the bulk of security gateway features then the software will be Copyright © 2022 Canis Automotive Labs Ltd. 22 / 25 moderate, confined mostly to management, and it should be amenable to formal verification to prove there are zero RCE vulnerabilities
The text was updated successfully, but these errors were encountered:
No branches or pull requests
from @kentindell (thanks Ken!):
The text was updated successfully, but these errors were encountered: