Securing the SoCs
In the era of Internet-of-Things (IoT), security has become one of the most crucial parts of a System-on-Chip (SoC). Secured SoCs are used to provide authentication, confidentiality, integrity, non-reproduction, and access control to the system (hardware and software). Here are some of the architectural techniques to develop a secure system.
Typically in a secured SoC, three key functionalities are desired: secure booting, secured memory, run time data integrity check.
- Secure Booting
- Secured Memory
- Run time Data Integrity Check
Secure Booting
Boot is an important part of an SoC from a security point of view. If a hacker is able to control the booting process of the SoC, then all other security implementations can be avoided to gain unauthorized access. SoC architects develop multiple techniques to provide security during the boot process of SoC.
The linkage that transfers the control from hardware to software is one of the favorite target points for hackers. Secure booting is one of the best technique to safe-guard this linkage. Chain-of-Trust is the classic technique used for implementing secure booting.
Chain-of-Trust is envisioned as a security implementation where trusted/authenticated hardware and software is used in multiple phases of the chain. If SoC chooses to deploy secure boot, then at each boot phase it authenticates the next phase to be executed.
Secure boot starts from a trusted entity (anchor point). Chip hardware booting sequence and BootROM are the trusted entities which are fabricated in silicon. BootROM is the first code or booting code that executes when SoC is powered on. BootROM is stored in ROM or write-protected flash embedded inside the processor chip. Hence this code contains instructions to configure the system-on-chip (SoC) to allow the SoC to execute applications.
The process of authenticating each successive stage is performed to create a chain-of-trust as shown in the following figure.
Phase 1 represents the execution of a hardware reset sequence which facilitates SoC power-up. Additionally the sequence transfers the control to BootROM, which is a trusted entity.
Phase 2 represents the BootROM execution as well as authentication of the user application software. Authentication is the process to generate a unique signature of an application image and matching the same, with a golden signature, stored at secured region in SoC.
Phase 3 represents the execution of the user application software.
The completion of Phase 2 ensures that the user application software can be trusted. Had the user application been illegally modified, its authentication would have failed in Phase 2, and therefore Phase 3 would not be executed.
Secured Memory
The Memory in SoC can be secured to preserve sensitive data such as cryptographic keys, unique IDs, passwords, and the like.
The memory can be divided into multiple partitions, each with a different set of access controls. On the basis of the nature of data stored in a partition, the partition can be designated as a security sensitive or a non-sensitive partition. The memory that contains sensitive data is referred to as secure memory. In case of a security breach (such as tamper detect, ecc manipulation, etc.), the contents of a security sensitive partition can be erased by the controller itself while that of the non-sensitive partitions can remain unchanged. Such memory controllers are called secure memory controllers.
Run-Time Data Integrity Check
A run-time data integrity check is used to ensure the integrity of the peripheral memory contents during run time execution. The secure booting sequence generates a reference file that contains the hash value of the contents of individual memory blocks stored in a secured memory. In the run-time mode, the integrity checker reads the contents of a memory block, waits for a specified period of time, and then reads the contents of another memory block. In the process, the checker also computes the hash values of the memory blocks and compares them with the contents of the reference file generated during boot time.
In case of a mismatch between two hash-values, the checker reports a security intrusion to a central unit that decides the action to be taken based on the security policy. In case the value matches, the Integrity checker starts over and validates the contents of subsequent memory blocks. This process is continued till the SoC is running. The scan rate of the integrity checker should be configurable so that the user can have a tradeoff between the memory block validation rate and the memory bandwidth utilization.
So, these are the three techniques which can be used for securing the SoCs. SoC Security is paramount for the safe and reliable operation of IoT connected devices. The same capability that enables the SoC to perform their tasks must also enable them to recognize and handle threats. Fortunately, this does not require a revolutionary approach, but rather an evolution of the existing architecture.
Stay Tuned, Stay safe and Stay Updated!!!
