Webinar discusses SoC security, area, and power trade-offs

A webinar from Synopsys discusses the challenges of creating secure SoCs, and then covers the trade-offs necessary to balance the value of whatever it is that the SoC is protecting with the complexity, area and power-budget implications of implementing the appropriate security.

Ruud Derwig, a software and systems architect at Synopsys, opens by discussing the three types of threat that SoCs are likely to face. These include communications-centric attacks such as eavesdropping to sniff data such as passwords, and remote attacks using backdoors. Software-based attacks may include malware that exploits programming errors in the SoC’s own code, or which tampers with privilege levels to gain unauthorised levels of control of the device. The third form of attack is through hardware, for example by manipulating a system through its debug interfaces, or even, in the most extreme (and valuable) hacks, by decapsulating the chip and micro-probing its surface to understand internal signals that don’t make it to a peripheral pin.

These side-channel attacks can gain insights into how a chip works by watching timing signals, measuring power consumption or reading electromagnetic (EM) signals to infer useful information about how the SoC operates. Many of these attacks are relatively simple to implement, needing little more than a digital oscilloscope and/or an EM probe.

The webinar goes on to discuss the utility of implementing trusted execution environments within which you can run software securely, because the environment separates the secure operations from the hardware, software and interfaces of the rest of the SoC. Coming back to the issue of balancing cost of implementation against value protected, Derwig describes three ways to achieve this kind of separation: with a single CPU with hardware separation; with a physically separated secure CPU; and with a secure module that acts as a companion to an applications processor.

The webinar goes on to discuss strategies for implementing onchip security, including various approaches that combine the SecureShield technology developed for use with the ARC processor core IP, and the APEX instruction set extension facility offered by the architecture. This includes strategies such as isolating the network stack in its own sandbox so that if the network connection is exploited by a hack, its impact can be limited.

The webinar discusses techniques for protecting access to chip resources such as memory, processor registers, extension registers, tables in memory, control and status registers, and interrupt handling. It also covers strategies for creating multiple operating modes and privilege levels to constrain the operation of real-time operating systems on your SoC.

There’s also a discussion of the software side of the SecureShield technology, a run-time library that can be used to define trusted regions that Synopsys calls containers. These act as sandboxes for applications to run within and have explicitly managed access rights, a private stack, and the option to have private data and/or context data. Each container also has an associated access control table that lists the access rights it has to the rest of the system and its resources. Containers can also be defined as having a particular privilege level, and as operating is normal or secure mode.

After a detailed description of how containers can be implemented and the security implications of the various options that can be applied to them, Derwig moves on to discuss side-channel attacks and strategies to defeat them. These include techniques such as ensuring that the processing of encryption keys takes roughly the same amount of energy, independent of the value of the key; and ensuring that all the instructions for the ARC processor take similar amounts of time to execute and use similar amounts of energy. Where these strategies are too complex to implement, timing and power randomization can be introduced.

Derwig also talks about options to increase security during physical implementation, such as by placing sources of electrical noise near potential sources of information leakage from computations, and/or ensuring that lots of other parts of an SoC are active at the same time as any cryptography functions are being run.

The webinar concludes with a return to its initial premise, considering how to balance all the various options for implementing security and the costs of doing so, with the value of whatever the security system is protecting. It takes the example of implementing cryptography in three different ways – using software on a standard processor, running software on a processor core that has been enhanced with cryptography-specific instructions; and using a full hardware implementation. The power, area, performance and security implications of each approach are compared.

You can view the webinar here.