Validation of security apparatus in SoC

Designing resilience into designs is one aspect of security assurance. The other critical aspect is validating that the security objectives of the product are indeed satisfied. Security validation is different from most other kinds of validation since the requirements are typically less precise. The goal of security validation is to validate conditions related to security and privacy of the system that are not covered by other validation activities. The requirement that security validation focuses on targets not covered by other validation is important given strict time-to-market constraints, which preclude duplication of resources for the same validation tasks however, it puts responsibility on the security validation organization to understand activities performed across the spectrum of the SoC design validation and identify holes that pertain to security.

A. Functional Validation of Security-Sensitive Design Features

Let’s take into consideration the example of the cryptographic engine IP. A critical functional requirement for the cryptographic engine is that it encrypts and decrypts data correctly for all modes. As with any other design block, the cryptographic engine is also a target of functional validation. However, given that it is a critical component of a number of security-critical design features, cryptographic functionality may be crucial enough to justify further validation beyond the coverage provided by vanilla functional validation activities. Consequently, such an IP may undergo more rigorous testing, or even formal analysis. Other such critical IPs may include IPs involved in secure boot, and in-field firmware patching.

B. Validation of Deterministic Security Requirements

Deterministic security requirements are validation objectives that can be directly derived from security policies. They include access control restrictions, address translations, etc. Consider an access control restriction that specifies a certain range of memory to be protected from DMA(Direct memory access) access this may be done to ensure protection against code-injection attacks, or protect a key that is stored in such location. An obvious derived validation objective is to ensure that all DMA calls for access to a memory whose address translates to an address in the protected range must be aborted. Note that validation of such properties may not be included in functional validation, since DMA access requests for DMA-protected addresses are unlikely to arise for normal test cases or usage scenarios.

C. Negative Testing

Negative testing looks beyond the functional specification to identify if security objectives can be subverted or are underspecified. Continuing with the DMA-protection example above, negative testing may extend the deterministic security requirement to identify if there are any other paths to protected memory in addition to address translation activated by a DMA access request, and potential input stimulus to activate such paths.

D. Hackathons

Hackathons, also referred to as white box hacking fall in the “black magic” end of the security validation spectrum. The idea is for expert hackers to perform goal-oriented attempts at breaking security objectives. This activity depends primarily on human creativity, although some guidelines exist on how to approach them . Because of their cost and the need for high human expertise, they are performed for attacking complex security objectives, typically at hardware/ firmware/software interfaces.