Embedded electronic devices for new models of automobiles, as well as in other products, are gradually increasing, which in turn also increases the need for connectivity. This connectivity can be between the devices within an automobile or a device, or between SoCs and the outside world over wired or on-air networks.

Thus, security has become a critical requirement for automotive SoCs and is essential to ensure that information is transferred without tampering. Security may include cryptography, digital signatures, MAC calculation, and authentication.

Validating security is more about targeting negative scenarios or attacks than just feature testing. One should have a hacker mindset while validating security. Much of the equipment available for security testing is very expensive, but in this paper we will discuss some of the negative tests that can be performed in post-silicon validation without using such equipment.

Below are some corner scenarios and negative checks that can be carried out to stress security.

Checking by inserting ECC faults

ECC faults can occur anytime in the non-volatile memory. We should be aware of the device’s behaviour while encountering ECC faults and should check that there is no security breach due to this. For validation purpose, we can intentionally inject multi-bit ECC errors. These errors may be injected in secure non-volatile memory, in secure keys area, in security firmware, secure image, device configuration registers, etc.

Below is an example of ECC inserted in a memory where the output of a secure engine is to be stored. The AES-128 engine will encrypt two 128-bit blocks of data. The image below shows the two ECC scenarios:

20170524_SoC_Security_01 Figure 1: Case 1 shows ECC inserted in the first 128 bits of memory and the rest of the memory is accessible, while Case 2 shows the first 128 bits of memory are accessible and ECC is inserted in the next 128 bits.

Case 1: ECC is inserted in first 128 bits of memory and the rest of the memory is accessible. In this test, we can check whether if there is an error encountered in the first block of data, the security engine halts the encryption of the next block or it ignores the error and stores the output of the second block that is accessible.

Case 2: The first 128 bits of memory are accessible and ECC is inserted in the next 128 bits. In this test, we can check whether the first block of data is stored in the accessible memory and operation is halted when encountering an error during the second block, or the operation is halted for both the blocks.

Checking by command sequencing and cancellation

Check the behaviour of a device by playing with the command sequencing. For example, run a valid encryption/decryption command after an invalid command. In this case, we are making sure that the error occurring after running the invalid command should not remain latched after a valid encryption/decryption command is run.

We can check using cancellation by issuing a cancel/abort during operation. Partial output should not be generated so there is no leakage of secure data. The same can be checked for other secure operations as well.

Check by clock tampering

Clocking plays an important role in security. Multiple scenarios can be checked:

  • Ideally, there should be no provision to gate the clock for security IPs alone.
  • If there is a provision to gate the clocking of security IPs, try to gate the clock while secure operation is ongoing and see that there is no leakage of secure data or keys due to clock gating.
  • If there are multiple security IPs in a microcontroller and there is a provision to gate the clock for individual IPs, make sure all the possible permutation/combinations of clock gating are checked. This will ensure that gating of any security IP will not affect another security IP and there is no leakage of secure data.
  • If there are any clock dividers on secure modules, check all divisors to make sure that secure operations are as expected.
  • Clock tampering may also include changing the frequency of a security module, setting it to values that are out of spec to cause malfunction.

 
Next: Other SoC security validation checks »