Ensuring that if an attacker successfully bypasses a mechanism of protection, they’ll face another layer of defense.
As the number and type of cyberattacks, from the “simple and cheap” to the “expensive and sophisticated,” continues to grow at a dramatic pace, protection of chips and devices must employ a defense in depth strategy. In this way, if an attacker successfully bypasses a mechanism of protection, they’ll face another layer of defense, rather than a clear path to the assets they seek to exploit. In this blog, we’ll talk about some of the protections security architects can marshal to build a defense in depth.
One of the easiest logical attack vectors is to replace the genuine device firmware with rogue firmware. The simplest protection is to have all firmware in embedded ROM. For various reasons – including security updates in the field – this is not accepted anymore. Firmware upgrade mechanisms are required to allow in field updating and upgrading of devices including security patches. Typical boot flows start with a small boot loader in ROM that pulls in the subsequent boot stages and application code from external Flash, or through other mechanisms. A robust cryptographic digital signature scheme can validate digitally signed images prior to allowing boot from them. Extended mechanisms also provide firmware confidentiality and anti-roll back mechanisms.
Runtime memory protection is a security service that may be utilized to verify the integrity of application code and data at runtime. Integrity checks of the memories are initiated periodically or triggered through events. The service may be utilized to protect code and data from unauthorized modification not only at boot time as in firmware integrity protection above, but during the entire runtime of the application. Runtime memory protection may be used to verify the integrity of critical application code or data. Generally, runtime memory protection makes sense for memories whose contents remain unchanged for long periods of time. Examples to which this may apply include operating system code, interrupt vector tables, interrupt handlers or monitoring software. An additional layer of memory protection would be to have confidentiality, error detection and anti-roll back protection of application data regions of the memory.
Beyond being vital for system integrity, the firmware is a high-value asset that may require confidentiality protection in addition to integrity and authenticity protection, e.g., to prevent it from being used in clones. In devices that store firmware in an on-chip flash area, the firmware needs to be guarded against many non-invasive attacks through readout protection as well as invasive attacks against on-chip flash. When external flash is used, the security subsystem may need to provide additional protection mechanisms such as on-the-fly encryption/decryption and verification services to protect the integrity of firmware stored in this non-volatile memory (NVM).
Additional protection mechanisms may be needed to maintain a secure state after boot, i.e., during the execution of the application to make sure the code is not only correctly read from memory, as with runtime memory protection, but also executed correctly. Modern security subsystems therefore may feature runtime integrity protection mechanisms such as regular verification of correct flow of code execution to validate platform integrity or – for a base-level security – feature environmental security sensors to monitor the IC.
In order to reduce the attack surface, complex tasks are split into smaller subtasks, and these are then isolated from each other by various means. Also, restricting access rights to IC resources that are not required by the task is a way to reduce the attack surface of said task.
A plethora of countermeasures exists to battle side-channel attacks. These range from special hardware designs that balance the power consumption regardless of what precisely is being computed to a wide range of software countermeasures that often involve sophisticated mathematics. For devices that are built with standard hardware components, the focus for side-channel attack countermeasures relies on software methods. In essence, all these methods try to decorrelate the logical digital information (e.g,. valuable cryptographic key materials) from its physical bit representation. Likewise, the goal is to decorrelate the logical algorithmic steps performed on these keys from the actual physical execution of operations on bits and bytes. One way or another, this often involves adding randomization to the implementation of a cryptographic algorithm. Keywords here are masking, hiding, blinding, etc.
The basic remedy against fault injection attacks is adding redundancy and resilience to the hardware and software at all layers. In some cases, this can be as simple as defining return codes to be values other than all zeros or all ones, but rather two non-trivial bytes. This makes it harder for a glitch attack to create the desired correct return value. It also helps to add measures that monitor whether certain critical blocks of code have been executed – and executed in the correct order. Countermeasures will also vary depending on whether the fault is transient (i.e. present only during a brief moment in time), or quasi permanent.
One of the most striking aspects of running through such a list of protections is that architecting successful security for a chip or device can be a daunting task. Fortunately, there are experts with off-the-shelf solutions that can help you. At Rambus, we have nearly three decades of security expertise and a broad portfolio of security IP solutions. We can help you safeguard your designs whether they target consumer IoT or the most sensitive military applications.
Additional resources:
 |
 |
 |
 |
 |
 |
Leave a Reply