Negative tests for SoC security validation – Part 2
Article By : Singh Amrit & Atulesh Kansal
Since equipment for security testing is usually expensive negative checks can be done to validate and ensure SoC security.
« Previously: Negative tests for SoC security validation – Part 1
Checking by voltage tampering
Supply voltages can be tweaked to perturb the device and security modules. There should not be any effect on the operation of device if we tamper with the voltage. These scenarios can be tried:
- Run the secure operation when the device is running at minimum voltage or maximum voltage defined by specification.
- Run the secure operation when device is running at voltage lower or higher than defined by specification.
- Suddenly change the voltage to a value that is out of spec while secure operation is ongoing.
- Suddenly change the voltage while secure operations are ongoing.
- Change the voltage in steps while secure operations are ongoing.
Testing by asynchronous event generation
The SoC supports different types of asynchronous events such as non-maskable interrupts, change in power mode, etc. Testing these asynchronous events is critical for validation of security engines. For example, trigger a low power mode request while some of the secure operation is ongoing, then return to normal. There should be no leakage of secure data.
Testing by asynchronous event sweeping
The next step is to apply async events at different intervals of secure operation. This will help us to identify that there is no leakage of secure data or secure keys due to events at random intervals or random power loss. This sweeping can be tried during secure booting, encryption/decryption, signature generation/verification, etc.
Figure 2: Asynchronous event generation at varying intervals during secure operation.
Asynchronous events can be generated at different time intervals in different power cycles or in the same power cycle, and the time window for generation of these events can be increased or decreased.
Testing through miscellaneous attacks
- Try to expose secure information by exercising the debug port in various ways.
- Software attacks: Try to execute malicious code (any non-application code).
- Try to corrupt random locations or the non-secure area and verify no secure information has leaked.
Conclusion
Security validation can never be considered 100 per cent complete. There will always be some other way to perturb the device, possibly leaking secure information. Always try to do the opposite of what the security spec says. While validating security, the purpose shouldn’t be to check if the device is working properly, but how to break it.
