Skip to content
New issue

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

3 security requirements for 'generic ECUs' #2

Open
BenGardiner opened this issue Feb 16, 2022 · 0 comments
Open

3 security requirements for 'generic ECUs' #2

BenGardiner opened this issue Feb 16, 2022 · 0 comments

Comments

@BenGardiner
Copy link
Member

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant