Multi-Master RAM Content Protection
Automotive designs cater to wide range of applications like infotainment, engine and braking controls, driver-assistance as well as autonomous driving; containing vendor as well as customer secret keys in the memories. With growing security incidents and attack surfaces within these applications, it’s critical that assets stored within on-chip or off-chip memories are well-protected.
In many scenarios, we come across a situation where the core may need access to certain keys/security assets for various house-keeping activities. However, the core may not be the consumer for the data but only transfer/install it to be used by some security module. Allowing core to assess plaintext data can create vulnerabilities, if the software running on the core gets tampered or compromised.
We recommend that sensitive data should be available to core as ‘black’ data –
- Core can only interpret instructions but not sensitive data/keys, even though accessible to core (for copy etc)
- Removes vulnerabilities introduced due to SW
- Memory will contain encrypted content, to prevent secrets from any attack using debug or test mechanisms, that can enable complete physical reading of RAM
As shown in Fig-1, we assign different functional privileges to different masters, while the content is physically accessible to all masters.
During debug or test, the descrambler can be permanently disabled –
- No master can access plaintext data
- Avoids ram zero-ising FSM
Data travel across the RAM controller and memory are secure, avoids side-channel based attacks.
Example:
Consider a 64kB RAM with 64-bits data, thus a depth of 8K addresses
If we implement 1-bit for each word to indicate whether the data is encrypted or not -> 8K bits will be needed.
We can also create blocks/page/group of larger words to reduce config bits.
Thus, in a best Case: 1–bit is needed, if entire RAM is marked as secure.
When reading the data, the controller will return additional flag (as sideband AHB/AXI) to indicate if the data is plaintext or not. A scrambled data will be saved as-is at destination, and will not be re-scrambled, based on the flag, as shown in Fig4.
Configuration bits can be further made as non-readable (write-only), to avoid leaking knowledge of sensitive regions.
When reading the data, the controller will return additional flag (as sideband AHB/AXI) to indicate if the data is plaintext or not, as shown in Fig 5.
A scrambled data will be available as plaintext to the secure master. The data will be saved encrypted at destination (re-scrambled), based on the flag.
Note that gaining knowledge of the function, through test/debug paths, should not be an issue as the RNG source forces a different behavior for each session.
The obfuscation function can be a simple scrambler or a cryptographic function (eg AES), based on the area and performance overheads acceptable in the system
Summary: There are multiple access-restriction solutions in the industry, catering to master based access controls. The solutions either provide complete access or complete denial of content (in any form). In this article, we discussed a solution that creates another layer with interpretable access vs black-box access.
About the authors:
Sandeep Jain (sandeep.j@nxp.com) is Security designer at NXP
Kirk Taylor (kirk.taylor@nxp.com) is Security architect at NXP
Pradip Singh (pradip.singh@nxp.com) is Security FW designer at NXP
References:
- US 8560863 B2 – Systems and techniques for datapath security in a system-on-a-chp device
- NXP Extended Resource Domain Controller xRDC
- US9400890 – Method and devices for selective RAM scrambling
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
