Security has become a crucial requirement for automotive SoCs and there are different ways to test how secure security.
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.
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:
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.
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.
Clocking plays an important role in security. Multiple scenarios can be checked:
New products & solutions, whitepaper downloads, reference designs, videos
Register, join the conference, and visit the booths for a chance to win great prizes.