Hello and welcome to my presentation of
"The Anatomy of Hardware Reverse Engineering - An
Exploration of Human Factors During Problem Solving",
which was recently published in the ACM
Transactions on Computer Human Interaction. My name
is Steffen Becker and this is joint
work with Carina Wiesen, René Walendy,
Christof Paar, and Nikol Rummel.
Embedded microelectronics in the form of microchips
provide the foundation of trust for numerous
modern day applications. For example, for autonomous
driving, in our energy grids or in everyday
appliances such as robot vacuums or smartwatches.
Subverting the security of such devices at
the hardware level is a dangerous and
stealthy threat and is most likely already
being pursued by a number of nation
state threat actors.
This is evidenced by the billions of
dollars the European Union and the
United States are currently investing to
restore control over the microchip supply chain
via their respective chips acts. In this context
one specific yet powerful attack vector to
undermine the security of microchips is the
process of hardware reverse
engineering, or short HRE,
which we investigate in our paper.
HRE can be the starting point
for a number of illegal purposes
such as introducing hardware Trojans or infringing
intellectual property.
While the technical aspects of hardware
reverse engineering have been researched for nearly
three decades, we are specifically interested in
the human factors that enable successful reverse
engineering. We pursue this approach with a
similar intent to that evident in the
field of human-centered security as discussed
in Eva Wolfangel's opening keynote.
To impede reverse-engineering-based attacks
and therefore develop effective defenses, we must
first understand the attackers' mindset, their
motivation and strategies, in detail. So let's
first take a closer look at what
hardware reverse engineering actually is. HRE
usually starts with a microchip – a piece of silicon –
that implements one or several functions,
for example, cryptographic algorithms, general purpose
processors, or communication interfaces. The goal of
the attacker is to understand the circuit,
at least partially. To this end they
extract a circuit diagram – the so called netlist
– from the chip. A digital netlist
consists of a high number – often
millions – of components – the gates – and their
interconnections. Here we can see a snippet
from a larger netlist. The goal of
the reverse engineer is now to make
sense of this unstructured "sea-of-gates".
To investigate this HRE
sensemaking process, we have established a model
for HRE. On the one side
is the technical part, where the reverse
engineer runs a combination of manual and
semi-automated analyses. On the other side
are the cognitive processes of the
reverse engineer which steer the analysis.
However, there has been little research on
the latter. As such, reverse engineers' strategies
and crucial cognitive factors remain poorly understood.
Thus, our overarching research goal with this
work is to achieve an initial understanding
of the human factors influencing the success
of HRE.
To give you an idea of how
HRE works in practice, I'm going
to show you a time lapse of
a reverse engineer investigating a small netlist.
The reverse engineer's goal in the case
at hand was to recover a mathematical
formula describing the function that a netlist
performs. To achieve this, the analyst utilized
the state-of-the-art HRE
software HAL, which is available under open
source license on Github. Most importantly,
HAL comprises a viewer – as you can
see on the left – showing the circuit
and a Python editor on the right.
And both of these tools can be
used to interact with the netlist.
As this example is just intended to
give you an intuition of the process
please don't pay too much attention to
the code that will be shown on
the screen.
In the beginning, the reverse engineer loads
the netlist into HAL. Next, they start
exploring individual gates and their connectivity in
search for a suitable attack target – first
manually then by developing a small Python
script which helps them highlight some interesting
parts of the netlist.
Now, the reverse engineer has found an
interesting set of target gates and wants
to validate their target selection. In this
step, the reverse engineer needs to infer
what function each part of the netlist
performs. A common technique which we can
also see here is the recovery of
higher-level structures of the netlist
by finding and grouping related gates. Again,
the reverse engineer makes use of both
visual inspection and small automations that they
script in Python. Together, these approaches help
them to reduce the unordered sea-of-gates
to just three central functional blocks.
After detecting and verifying these blocks of
interest, they can now realize the actual
attack. In this case, this means designing
an algorithm that generates a formula describing
the Boolean function performed by one of
the three modules. The final output is
shown at the bottom right.
For our study, we now recruited participants
to solve a realistic HRE study
task with the HAL reverse engineering framework
I just introduced. Since HRE experts
are scarce and usually not available for
such studies, we recruited eight intermediate-level
participants who had successfully completed a fourteen-week
course on HRE. In addition, we
were able to recruit one expert through
our professional network.
While the participants solved the task in
HAL, we recorded detailed behavioral logfiles,
including all their manual and script-based
interactions with the netlist. We then went
on and conducted a qualitative continent analysis
of the logfiles via an
iterative open coding where three researchers first
described each observed action, compared it to the
previous step, and then explained the observed
behavior.
From the codes which emerged during our
qualitative content analysis, we derived a detailed
hierarchical taxonomy of HRE
processes, which is divided into two main
categories. The first category, "Reversing Actions", includes
the steps taken and strategies chosen during
reverse engineering. One important
observation here are the various types of
reversing problems that our participants encountered. As
previously stated, developing automations is a central
supporting activity during HRE. Hence, our
second category comprises various
facets of "Code Development".
Finally, we observed a few external factors
that influenced our participants such as software
bugs or external interruptions.
As our taxonomy is only derived from
a single realistic task, it could likely
be extended through the observation of other
HRE tasks. However, it equips
us with the means to analyze strategies
of reverse engineers in detail and includes
valuable information on obstacles and roadblocks encountered
by them.
With this in mind let's take a
deeper look into the reversing problems we
observed. In our taxonomy, the groups of
codes is further split into the clusters "Confusion",
"Failed Attempts" and "Lack of Understanding". In
this figure you can see the relative
frequency of each cluster in each participant's
data. It is noticeable
that not a single participant – including
the expert – completed the study task without
encountering one or multiple roadblocks along the
way. As such, confusion, lack of understanding
and the choice of inappropriate strategies seem
to be common factors that slow down
HRE. However, some participants could still
cope better with those problems
than others. Our findings support that
both expertise and cognitive abilities play a
role for HRE success. As shown
in this figure, we observed a slight
negative correlation between the total solution time
of the task and participants' working memory
scores – an IQ subscore which
helps them to temporarily keep chunks of
information in mind. These findings open an
avenue for a new research direction which we
coin "cognitive obfuscation"; a new set of
methods developed to prevent illegitimate reverse
engineering by impeding the human sense-making processes.
So let me conclude with a brief
overview of our research contributions
and an outlook on some potential
future work. Hardware reverse engineering is an
attack vector threatening the security of microchips.
In our work, we shed first light
on the human factors influencing HRE
success by establishing a hierarchical problem-solving
taxonomy for HRE which we then
use to classify the individual strategies of
reverse engineers – more on this in the paper!
Based on our results, we defined
HRE as a type of problem
solving that builds on both expertise and
cognitive abilities – the latter being the foundation
for a first sketch of cognitively demanding challenges
which ultimately aim to impede attacks based
on hardware reverse engineering.
As our results to date are based
on qualitative analyses, further quantification of cognitive
factors and problems of reverse engineers would
be worthwhile. Lastly, first prototypes of cognitive
obfuscation could be built and tested in
practical and realistic settings.
With this, I would like to thank
you very much for your attention. Please
take a look into our paper and
if you have any thoughts or questions
don't hesitate to reach out to us
via email or talk to us in
person in Hamburg.