Layered Security Offers Best Embedded Hardware Security

The importance of building a secure and rigid foundation in SoC and system designs has never been so true as it is now, given not only the garden variety of software vulnerabilities existing today, but also micro-architectural attacks on CPUs like Meltdown, Spectre, and Foreshadow.

Design engineers should embrace two security-related tenets when selecting a security processor: one is depth of defense; the other, principle of least privilege. The former says you have many layers of defense against certain attacks. Due to that layered security, an attacker has to access each layer to get an asset, but which they shouldn’t have access to in the first place.

Principle of least privilege refers to access controls at each of those layers. Fig. 1 shows an example of layered security. For instance, the user application layer has access to only its assets and nothing more. The user application layer is only allowed to make requests of other layers.

Fig. 1: Layered security

Let’s now look at the bootloader layer. The bootloader is specified to securely boot the system into a state that is ready to accept user applications. You have to ask such questions as: What is the flow of that behavior? What are the error conditions? How do I manage these error conditions? Is there a way for a malformed image to cause the bootloader to behave in such a way that secure assets could be exposed?

Enforcing a rigid foundation
This pair of security tenets enforce the rigid foundation on which a security processor should operate. Each layer performs the functions it’s permitted. Anything out of that realm goes to another layer as a request, and this is true for all the layers.

When a user application is loaded into an exemplary secure processor, the application’s image should have its requested permissions attached. If the user application is trusted, its permissions can be written directly to hardware registers, where available. These hardware registers can be applied to access to cryptographic keys, non-volatile memory address ranges, general purpose I/O, etc.

If a vulnerability is found in the user application layer, there is still safety from the user application getting outside its own boundary. An attacker cannot take advantage of security flaws to gain access to assets. That’s because the user application’s permissions were set in hardware when loaded and the permissions persist until the application is unloaded.

Based on defense in depth and principle of least privilege, there can be multiple distrusting parties securely executing code inside the bounds of the security processor without risking leakage of their secure assets between or among one another.

In summary, the goal is to ensure each layer is limited to the tasks it is assigned to perform and no more. If a mistake were made in a particular layer and it was handed access to an asset it wasn’t supposed to have, an attacker could exploit that behavior.