TrustZone, MultiZone, Security Check and Code Signing

Make it to the Right and Larger Audience

Blog

TrustZone, MultiZone, Security Check and Code Signing

MultiZone security proposed by Hex Five for RISC-V is compared with ARM’s trustZone in my other post, Hex Five’s MultiZone Security for RISC-V.  Both MultiZone and TrustZone employ the following architecture. BM stands for bus master and BS stands for bus slave. Only Bus master can initiate a transaction on InterConnect Matrix and to a bus slave. SSAC stands for Slave Security Access Check.

 

 

When a bus master initiates a transaction, it also sends security metadata of the transaction on security bus. Security metadata carries security level information. Each transaction has a corresponding security metadata. InterConnect Matrix not only needs to route normal transaction on data bus to bus slave but also needs to route security metadata on security bus to bus slave.

On bus slave side, SSAC checks security metadata. If it passes security check, SSAC passes through the transaction to bus slave. If security check fails, SSAC blocks this transaction and may further log security violation and sends interrupt to firmware.

The difference of MultiZone and TrustZone is TrustZone’s security metadata is just one single bit to indicate whether the transaction is trusted or untrusted. Security metadata needs to be multi-bits to indicate multiple security levels (>=2). A bus slave’s SSAC only passes through a transaction whose security level is higher than a pre-programmed security threshold.

It is important to note that although transactions coming out of some bus master are of the same security level, it is not always true. One example is an ARM processor which supports TrustZone. ARM processor inside is split into trusted zone and untrusted zone so processor initiated transactions can be either secure or nonsecure.

 

In addition, careful considerations need to be taken for

  1. how SSAC is programmed. Which bus master(s) has the privilege to program SSAC? Obviously you don’t want to allow a malicious user to program SSAC otherwise it breaks security.
  2. SSAC hw reset setting. Is there a security due to hw reset?

The answer to other questions can vary and depends on the particular system.

 

Architecture wise, place security check on bus slave side is not the only solution. Security check can be put on bus master side too. MSAC stands for Master Security Access Check. Similar to SSAC, MSAC needs to block transaction which does not pass security check. Unlike SSAC, MSAC implementation is normally address based. For example, each MSAC may define up to 16 security zones. Each security specifies starting address, zone length or ending address, security level, block write or read or both, etc.

MSAC architecture can be of particular interest to an IP core. The IP core itself is considered safe initially. It can stay in safe condition as long as the external access, either from other cores on the same chip or from external chip, is safe. We can’t guarantee this external access is always safe but we can put MSAC on that access port to block unsafe access. Below diagram uses BM2 as an example.

 

One way to implement external access MSAC is to restrict external access to only touch certain “scratch” area and IP core checks security of that access first before acting on it. Let’s use code signing as an example.

Let’s say BM0 of this IP core is a ARM processor. BS0 is instruction memory and BS1 is data/scratch memory. At bootup, ARM processor fetches instruction from a small ROM and needs the external chip to download main code to instruction memory. But we can’t allow external chip to download code to instruction memory directly. Otherwise a user may download a malicious code to instruction memory. ARM processor executing the malicious code can make the whole IP core unsafe.

Instead,

  1. external chip first downloads code to data memory. BM2 MSAC is programmed to allow this access but blocks access to other address spaces such as instruction mem and BS9.
  2. BM0/processor reads downloaded code from data memory and checks its security. For example, calculate sha number or authentication code and compares it to the downloaded authentication in data memory. If matches, we say downloaded code passes security check. If does not match, security check fails.
  3. If security check passes in step #2, BM0 copies downloaded code from data memory to instruction memory.
  4. BM0 then executes code from instruction memory which is now populated with the downloaded code.

 

 

 
Author brief is empty
Groups:

0 Comments

Contact Us

Thanks for helping us better serve the community. You can make a suggestion, report a bug, a misconduct, or any other issue. We'll get back to you using your private message ASAP.

Sending

©2020  ValPont.com

Forgot your details?