High-Quality Test And Embedded Analytics Are Vital For Secure SoCs

Applications such as smart cards and devices used in the defense industry require security features to ensure that sensitive data is inaccessible to outside agents. This used to be a niche requirement met through custom solutions. However, now that automotive and cyber-physical systems are proliferating, the requirements around secure test and monitoring are becoming mainstream. The current best strategy is to add security across different levels of SoC development to provide the best coverage in a defense-in-depth strategy. Figure 1 illustrates a high-level concept of device security across the ecosystem.

Fig. 1: Defense-in-depth solutions.

The implementation of test structures, which falls under System Integrity in figure 1, can significantly compromise any functional security features already part of the design. Let’s look at the security risks of common IC test strategies and how to mitigate them.

Security risks with scan-based test

Scan chains provide full access to the sequential elements of a device under test. Serial access from device pins allows test patterns to provide the stimulus and response needed to detect defects. Historically, scan test achieves the highest achievable test quality with low design and schedule impact.

However, while fully accessible scan chains are great for test, they may compromise security because they allow easy access to any portion of the device. This limitation has led many designers of secure applications to seek alternate approaches that provide the benefits of deterministic scan test while maintaining the required IC security.

Test access mechanism can be vulnerable

In addition to scan chains, most designs now have some form of test access mechanism (TAM). This can be a simple external interface such as IEEE 1149.1 (JTAG), or it can be both an external and internal interface with an in-system test controller used for running test.

The TAM is mostly used for setup, configuration, running and data collection of various complex test structures within the design, including scan chains, memory BIST, logic BIST, custom analog test IP, and parametric sensors. Once enabled, it gives direct access to many critical registers within the design. Access to these registers could be used to collect sensitive data or, in some cases, program the device to operate outside its intended function. Therefore, to keep the TAM from acting as a simple back door to security threats, it is critical that it be as secure as the other functional interfaces within the design. Figure 2 shows how a JTAG TAP based TAM presents several vulnerable points that are open to attack, both externally and internally.

Fig. 2: Typical JTAG TAP-based TAM.

Secure logic built-in self test

Built-in self-test (BIST) is common test technique that reduces security risks because it uses a pseudorandom pattern generator (PRPG) embedded in the circuit to create patterns on chip and apply them through the design’s scan chains. The circuit responses are compressed into a final signature using a multiple-input shift register (MISR), which also resides in the circuit. An on-chip BIST controller controls the number of patterns, shift cycles, and other parameters that allow the test to be fully contained inside the device. Figure 3 illustrates a basic logic BIST architecture.

Fig. 3: Basic logic BIST architecture.

For secure applications, logic BIST provides the highest level of security because no scan data is shifted in or out of the device. The only vulnerability would be in failure diagnosis. Logic BIST only outputs a final signature or a pass/fail flag at the end of test, but diagnosis requires additional patterns to be applied in BIST bypass mode. It can therefore be problematic to simultaneously perform diagnosis and maintain security by limiting access to the device.

Secure embedded test compression

The new fault models used to improve overall test quality have also increased test data volume and test application time. To reduce the costs associated with this, embedded test compression has become standard on many modern designs. Embedded test compression provides the benefits of deterministic scan test while meeting the security requirements of secure applications. Figure 4 illustrates a basic ATPG compression architecture.

Fig. 4: Basic ATPG compression architecture.

Bus-based packetized test data distribution

A new method of distributing scan test data across a bus-based system enables simultaneous testing of any number of cores even with few chip I/Os. It reduces test time by enabling high-speed data distribution, by efficiently handling imbalances between cores, and by supporting testing of any number of identical cores with a constant cost. A basic bus-based scan data delivery architecture is shown in figure 5.

Fig. 5: Basic bus-based packetized scan data architecture.

The bus-based scan data distribution adds a level of security on top of embedded test compression because access to the scan chains has an additional level of abstraction. The scan data is compressed, then bussed around the SoC, removing the direct access from the external pins to the scan channels. The data transferred to and from internal scan chains is both compressed and packetized to be delivered over the test bus.

Bus-based scan data distribution also supports on-chip compare. On-chip compare ensures that no data that has passed through the functional flip-flops can be taken off-chip because the actual checking of the ATPG result is done on chip. This removes the need for any data from the scan flops to ever be taken off chip. This adds another level of security because no data that has touched internal functional logic is ever taken off chip. The pass/fail result from the on-chip compare is stored in a status register, which is not part of the functional logic and is typically read by the IJTAG infrastructure. Figure 6 illustrates on-chip compare circuitry.

Fig. 6: On-chip compare circuit.

Secure TAM

The test access mechanism, typically JTAG, on today’s SoCs does far more than just basic test configuration. It enables functional debug modes within the device and could also be mapped in some places to the functional address map, so it is critical that this interface has a high level of security protection.

In the past, the solution to securing the TAM has been to either not bond the JTAG pins in the production package, or to disconnect the TAP after the device has completed final test using some form of one-time-programmable (OTP) fuse. However, with the increasing need for in-life analytics data collection, and customer return analysis for SoCs in automotive and safety applications, we need access to the internal test network either externally or through an embedded safety island.

There are many ways to secure the external JTAG TAP interface and the internal in-system connection to the TAP, but designers must have the correct infrastructure in place to enable their chosen solution, whether a simple hardware code sequencer or a full embedded root of trust. This would involve on-chip circuitry to act as a security manager. The security manager can vary in complexity, from a simple sequence detector that gives the correct binary signature to unlock the TAP interfaces, to a fully featured root of trust that is not only capable of generating its own inborn identity. This identity can be managed within the appropriate ecosystem to ensure that the TAP interfaces can only be unlocked if the correct authentication is given via a secure authentication service.

Including a security manager socket provides all the controls into the test and analytics architecture so designers can simply plug in their security manager. Figure 7 shows a security manager socket architecture.

Fig. 7: Security manager socket architecture.

It is possible to implement a number of different layers of security, so that different keys can unlock the device to different levels, granting different access rights for various applications or users. This approach is used extensively in the automotive ecosystem, where different access levels are granted at different phases of the device lifecycle. Figure 8 shows scenarios where different levels of access would be appropriate:

• Phase 1, where the maximum access level is granted to enable full debug and diagnostics capability.
• Phase 2, where the device could need some level of manufacturing testing either at package or system level.
• Phase 3, where a minimal access level is granted for any in-field applications that could need to collect some health or reliability data.

Fig. 8: Different levels of access to the chip can be granted at different stages of the chip lifecycle.

Summary

Having explored the risks and looked at ways in which these risks can be mitigated, we return to the concept of defence in depth. Deploying all of the security technologies discussed here and more builds multiple rings of defence. Using existing test technology to introduce many levels of protection can provide a significant defence against malicious attacks. Although some of these concepts are passive—they just providing a lock against access—others are also reactive in that they can take evasive action when a threat is detected.