Abstract

Embedded systems are ubiquitous. However, physical access of users and likewise attackers makes them often threatened by fault attacks: a single fault during the computation of a cryptographic primitive can lead to a total loss of system security. This can have serious consequences, e.g., in safety-critical systems, including bodily harm and catastrophic technical failures. However, countermeasures often focus on isolated fault models and high layers of abstraction. This leads to a dangerous sense of security, because exploitable faults that are only visible at machine code level might not be covered by countermeasures. In this work we present ARMORY, a fully automated open source framework for exhaustive fault simulation on binaries of the ubiquitous ARM-M class. It allows engineers and analysts to efficiently scan a binary for potential weaknesses against arbitrary combinations of multi-variate fault injections under a large variety of fault models. Using ARMORY, we demonstrate the power of fully automated fault analysis and the dangerous implications of applying countermeasures without knowledge of physical addresses and offsets. We exemplarily analyze two case studies, which are highly relevant for practice: a DFA on AES (cryptographic) and a secure bootloader (non-cryptographic). Our results show that indeed numerous exploitable faults found by ARMORY which occur in the actual implementations are easily missed in manual inspection. Crucially, most faults are only visible when taking machine code information, i.e., addresses and offsets, into account. Surprisingly, we show that a countermeasure that protects against one type of fault can actually largely increase the vulnerability to other fault models. Our work demonstrates the need for countermeasures that, at least in their evaluation, are not restricted to isolated fault models and consider low-level information during the design process.

Highlights

  • A ROUND 1970, it was discovered that cosmic radiation can induce charge in microelectronics, resulting in potentially faulty behavior of unprotected microcontrollers in avionics

  • We demonstrated that ARMORY is capable of uncovering higher-order fault combinations which are highly unlikely to be found by manual inspection, cf. the discussed example

  • We presented ARMORY as a powerful and accessible tool for automated exhaustive fault simulation

Read more

Summary

INTRODUCTION

A ROUND 1970, it was discovered that cosmic radiation can induce charge in microelectronics, resulting in potentially faulty behavior of unprotected microcontrollers in avionics. As well as logical parameters (e.g., location, clock cycle) are correct, a useful fault might appear This led to different approaches of assessing fault attacks on various levels of abstraction. Even more crucial, applying and evaluating countermeasures at high-level code or even at Assembly code with labels can lead to many faults that are missed in actual physical implementations and a false sense of security. Working directly on machine code, it supports all processors of the ARMv6-M and ARMv7-M families, since emulation is based only on public architecture information. It supports all processors of these families out-of-the-box and further can be extended with profiled hardware properties of specific chips. HOFFMANN et al.: ARMORY: FULLY AUTOMATED AND EXHAUSTIVE FAULT SIMULATION ON ARM-M BINARIES uncover numerous faults that are missed in manual inspection

Contributions
BACKGROUND
Fault Simulation and Assessment
MOTIVATION
M-ULATOR
ARMORY
Terminology
Inputs
Outputs
Fault Models
Optimized Fault Simulation Strategy
Further Optimizations
Applying ARMORY in Real-World Scenarios
CASE STUDIES
Case Study
OVERVIEW ON PERFORMED ANALYSES
Analysis I – Influence of Compiler Optimization
Analysis II – Influence of Code Positioning
Analysis III – Influence of Countermeasures
Analysis IV – Injecting Higher-Order Faults
Analysis V – Profiling Undefined Behavior
Results of Analysis I – Influence of Compiler Optimization
RESULTS
Results of Analysis II – Influence of Code Positioning
Results of Analysis III – Influence of Countermeasures
Results of Analysis IV – Injecting Higher-Order Faults
Results of Analysis V – Profiling Undefined Behavior
Discussion
CONCLUSION
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call