As more security related capabilities are added in hardware it is changing the effort required to ensure that SoCs are not prone to attack. Hardware has the initial appeal of creating physical barriers to attack, yet it presents its own difficulties. For one thing, a flaw in a hardware security feature is much harder to fix in the field, which makes it an appealing target for bad actors. Hardware related attack surfaces offer a larger ROI and hackers know that because they are hard to fix, they can exploit them for a longer period of time.
A webinar titled “Detecting Security Vulnerabilities in a RISC-V Based System-on-Chip” by Dr. Nicole Fern of Tortuga Logic covers the issues of SoC security by offering several examples of vulnerabilities that have been discovered, the various ways that SoCs can be compromised and approaches that can be used to improve the process of development and testing SoCs so that security issues can be significantly reduced.
Nicole goes over the ‘Nail Gun’ attack that allows code running on an insecure core to accomplish privilege escalation on another core by activating a debug mode strictly through software. No physical access to the system is required. Another of her examples is a boot tampering attack on Cisco routers where the bit-stream for an FPGA was stored in unprotected memory and could be modified by attackers. She cited a documented BLE software stack issue with TI chips that allows unsecure code to process Bluetooth packets.
To prevent hardware related attacks Nicole discusses three system level security goals. Each block or IP must not contain vulnerabilities of its own. Next, the process of SoC integration must not introduce vulnerabilities. Examples of this are improper management of debug and test interfaces and accidentally grounding a privilege bit in a peripheral interface. Lastly, software configuration and usage of hardware features must be correct. For instance, assets can be mismanaged during secure boot, MPUs can be misconfigured, or on-chip bus interfaces can be improperly programmed.
Nicole advocates a Secure Development Lifecycle (SDL) for hardware to help avoid security related problems in finished designs. At each stage of SoC and system development there are corresponding steps that should be taken. At the root of any security plan is threat modeling and creating a security specification. Naturally this is followed by security verification.
These steps often rely on in-house or consultant security expertise. There are several repositories of known vulnerabilities such as Mitre CVE and CWE that provide essential information for securing SoCs. At each step there needs to be design and architecture review. Formal verification methods can be applied. Simulation based and directed negative testing approaches can be used. Lastly, post silicon penetration testing is necessary. These approaches have some shortcomings which Nicole discusses in the webinar. She concludes that there need to be ways for guided security requirement creation from weakness databases, such as CWE, that are approachable for non-experts.
At the end of the webinar Nicole details how the Tortuga Logic Radix technologies offer a method that can be used by existing design teams to efficiently and effectively execute an SDL for hardware. Radix offers both simulation and emulation to detect potential risks in design. She makes the important point that, unlike functional verification that cares about data values, security simulation cares about data flow, transmission and access.
The webinar is an eye-opening look at how SoC security can be compromised even if the best hardware logic design methods are used. Security design is in many ways orthogonal to functional design. At the very least it represents another perspective of what must be considered during the design process. Anyone who cares about SoC based system security should view the webinar which will be on Tuesday April 14th at 10AM PDT.
