High Availability and Standard Availability Storage
Our understanding is that there are at least the following grades of data storage medium for automotive electronics systems.
- ROM stores code for use by ECUs and is written only once
- EEPROM stores code for use by ECUs and may be overwritten a limited number of times
- Flash stores code and persistent data for use by ECUs and may be overwritten a (relatively) large number of times. It is more expensive than ROM or EEPROM
- There may also be other grades of storage. Our understanding is that there is a spectrum of storage media from highly reliable and highly expensive (which are referred to as “automotive grade”) to less reliable but cheaper storage (which are referred to as “standard grade”). For example, infotainment systems may use less-reliable, cheaper storage to allow more storage to be provided.
The following are assumptions:
- Automotive-grade storage is so expensive that less than 1 MB will be available
- Standard-grade storage will also be available and that it will be sufficiently cheap to be provided in larger volumes, 100 MB or more
- Executable security and security management codes can be provided in a form that does not use the automotive-grade flash
Secure Storage
- The OBE needs to store the following in the highly available memory (encrypted):
- Local private keys for signing
- Local CSR signing key
- Any symmetric keys used for certificate management, i.e. for expanding the butterfly keys
- Seed butterfly key
- If the OBE does not encrypt its certificates, there may be an attack that allows them to be read from storage, which in turn allows the OBE to be tracked. However, an attacker with this level of access to the OBE can probably carry out other attacks. There is no requirement for certificates to be encrypted in place as long as they are integrity-checked.
- The OBE needs to provide integrity checks on the encrypted stored values noted above and also on the following:
- Root certificates
- Its own local certificates (if not encrypted)
- Any certificates used for validating software updates
- It is assumed that an arbitrary amount of automotive-grade storage can be converted to secure storage by using a hardware security module that stores a content encryption and authentication key.
- Integrity checks can be provided on a block wise basis rather than per data element. This reduces the storage overhead for integrity checks but increases the cost to check an integrity check (the entire block must be checked) and requires that the integrity check for the entire block is recalculated if any single element is changed.
- The content encryption key should be protected by TPM-like mechanisms so it can only be accessed if the software platform is in a known good state