Content uploaded by Frank Schuhmacher
Author content
All content in this area was uploaded by Frank Schuhmacher on Jan 27, 2021
Content may be subject to copyright.
A MIGA design and example implementation
Frank.Schuhmacher@segrids.com
Segrids GmbH
Abstract. MCU intrinsic group authentication (MIGA) is a secrecy
free, time bounded authentication method for low ressource ECUs based
on characteristic hardware features of a group of MCUs of the same
model with a common group identifier. The reference [1] provides a
MIGA definition, an attacker model, four security objectives, and a se-
curity proof for MIGA, provided that the four security objective are sat-
isfied. This paper demonstrates how to achieve these security objectives
for the example of a group of HT32F52 MCUs with a common “custom
identifier”. Furthermore, reliability test results are provided.
1 Introduction
We provide an example implementation for the MIGA scheme [1] for the MCU
model HT32F52 [2]. We have chosen this model due the following properties:
(1) its 32-bit Cortex-M0+ processor is simple and widely distributed; (2) its
four word “custom identifier” is well-suited as a group identifier; (3) it has mul-
tiple clock counter modules that can be configured without a prescaler; (4) the
CRC module and flash configuration options provide nice self-test examples. The
starter-kit [3] serves as an example of a to-be-authenticated ECU with HT32F52
MCU. Furthermore, we provides some test observations on a MIGA implemen-
tation for the SAX3x8e [4]. The Arduino Due [5] serves as an example of a
to-be-authenticated ECU with SAM3x3e MCU.
A MIGA requires an SBST invariant of an MCU intrinsic group. An SBST
requires the derivation of a self-test binary from a received challenge. We fix a
challenge length of 128 bit, and realize the derivation of the self-test binary in
such a way that the SBST interprets any 128 bit challenge as a set of modifi-
cations to be applied to a reference self-test binary. The reference self-test
binary is product specific but identical for each authentic ECU, and stored in the
flash of its authentic MCU. The modified binary (code,data) will mainly reside
in RAM. We will first describe the construction of the data segment in Section 2.
We will then describe the construction of the code segment in Section 3.
The final Section 4 shows (1) that the self-test construction provides an
SBST, (2) that the SBST is a group invariant, and (3) that it satisfies the four
MIGA security objectives.
2 The test pattern
The data segment of a self-test binary specifies “stimulus-response-tests” of
MCU modules (memories, system control, peripheral modules), where the CPU
acts as a tester. We call it the test pattern.
2.1 Test items
The test pattern contains test items. A test item specifies a test with a single
stimulus (i.e. write to the memory/register space) followed by a single system
response (i.e. read from the memory/register space). It is defined by a word
address was stimulus location, a word address (WriteAddress) as system
response location, and stimulus masks in order to specify stimulus bits to
be set (SetMask), cleared (ClearMask), left unchanged (KeepMask), or modified
pseudo-randomly (PrndMask), and a system response mask (ReadMask) in order
to specify which bits at the system response location (ReadAddress) form the
system response.
2.2 Stimulus-response-tests
Astimulus-response-test is specified by a sequences of a few test-items, and
suitable for testing a property of a peripheral module, or a dependency between
system and/or peripheral modules. Examples of stimulus-response-tests will be
provided in Sections 2.5-2.8.
We collect a set of stimulus-response-test (of 1-8 test items each) in such a
way that their combination is suitable for functionally testing a set of peripheral
modules that characterizes the MCU model among all MCU models on the
market, or at least among those MCU models with the same processor model.
Some of the system response locations in these self-test threads will point to
the group identifier id(M) in order to distinguish between group elements and
non-group elements in model(M).
It is always possible to find a suitable set of stimulus-response-tests for a
dedicated MCU model, provided that no MCU clones show up on the market:
Manufacturers have their typical addressing schemes for peripheral module reg-
isters. There will be no second MCU model with the same peripheral modules
addressing by chance. A different MCU model might have the same peripheral
modules addressing if it is either (a) a model of the original MCU manufacturer,
or a model licensed by the original MCU manufacturer, (b) a model of a different
manufacturer claiming “capability” with the original model (or vice versa), or
(c) an MCU clone. In cases (a) and (b) the two MCU models will have at least
a different CHIP ID or a different ROM content at some memory location.
2.3 Choosing modules for tests
We will divide the set of stimulus-response-tests into 4 groups, each group cov-
ering an equal number of test items. The four groups are considered as test
threads of equal length. The reference test pattern is the matrix with the
test items of the four groups as rows.
Focusing on the HT32F52 example, we need to collect a set of stimulus-
response-tests suitable for functionally characterizing the HT32F52 at least among
all MCU products with a Cortex-M0+ processor. We choose the set of peripherals
depicted in Figure 1 for the implementation of tests. We illustrate the specifica-
Fig. 1: Test Plan
tion of stimulus-response-tests for the modules NVIC, FMC, GPIO, and CRC
(see [2]) in the following subsections.
2.4 Braiding
A challenge dependent test pattern is formed by column wise permutations of
this matrix. The first 125 bits of the challenge are mapped by the SBST prog
to 25 permutations to be applied to the columns of the reference test pattern
while loading the test pattern from flash to RAM. This shall be referred to
as braiding. Braiding will change the “execution order” of the test items, see
Fig. 2: Test Pattern
Section 3. In some sense it randomizes the multi-threading of test threads.
2.5 NVIC
Testing the nested vectored interrupt controller (NVIC) requires the implementa-
tion of interrupt service routines. We have interrupt service routines for the timer
modules BFTM0 and BFTM1, see [2]. Their implementation will be discussed
in Section 3.4. The interrupt numbers are 17 and 18. The interrupts will happen
often and at pseudo-random runtimes, due to pseudo-random reconfigurations
of the timers. The following enumeration specifies a stimulus-response-test with
six test items:
1. Write to the ”Interrupt 16-19 Priority Register” to set the priority of inter-
rupt 17 to one. Read a code word.
2. Write a random bit to the ”Interrupt Clear Enable Register” to disable
interrupt 17 maybe. Read next code word.
3. Write a random bit to the ”Interrupt Set Enable Register” to enable inter-
rupt 17 maybe. Read next code word.
4. Write a bit to the ”Interrupt Set Pending Register” to set interrupt 17 pend-
ing. Read next code word.
5. Write to the ”Interrupt Set Enable Register” to enable interrupt 17 for sure.
Read the ”Interrupt Control and State Register”.
6. Write to the ”Interrupt 16-19 Priority Register” to set the priority of inter-
rupt 17 to zero. Read next code word.
The corresponding sequence of test items is depicted in Table 1. All numbers
in the table are hexadecimal. The read addresses 0x1220-0x1230 point to the
Test Item 0 1 2
WriteAddress e000e410 e000e180 e000e100
SetMask 100 0 0
ClearMask 0 0 0
KeepMask fffffeff fffffdff fffffdff
PrndMask 0 200 200
ReadAddress 1220 1224 1228
ReadMask ffffffff ffffffff ffffffff
Test Item 3 4 5
WriteAddress e000e200 e000e100 e000e410
SetMask 200 200 0
ClearMask 0 0 100
KeepMask fffffdff fffffdff fffffeff
PrndMask 0 0 0
ReadAddress 122C e000ed04 1230
ReadMask ffffffff ffffffff ffffffff
Table 1: NVIC test example
interrupt handlers that remain in flash memory.
2.6 FMC
For testing the flash memory controller FMC of the HT32F52, we apply stimuli
to the FMC module to mess up the timing of flash memory accesses. Two bits
of the ”Flash Cache and Pre-fetch Control Register” are suitable: bit 12 enables
the branch cache, and bit 4 enables the pre-fetch buffer. We will not change the
setting of flash wait states (bits 2:0), since this caused non-deterministic timings
in our tests.
An example for a stimulus-response-test consisting of a single test item is
shown in Table 2. The effect of the stimulus is not measured by the system
response in the test itself (the system response address points to a custom ID
register) but in other stimulus-response-tests where timer values are sampled.
We instantiate this test multiple times within the test pattern variating only the
read address and read mask.
Test Item 0
WriteAddress 40080200
SetMask 0
ClearMask 0
KeepMask ffffffed
PrndMask 00000012
ReadAddress 40080310
ReadMask ffffffff
Table 2: FMC test example
2.7 GPIO
For testing the general purpose IO module (GPIO), we focus on port C and
assume that the pins C11 and C12 are connected via a 50 Ohm resistor as
loop-back. The initialization routine of the SBST prog shall cover the clocking
the alternative function IO module (AFIO), and the GPIO port C, and the
configuration of pin C11 as output and pin C12 as input. A stimulus-response-
test example covers the following steps:
1. Write bit 11 of the ”Port C Output Set and Reset Control Register” pseudo-
randomly to set pin C11. Read the pin C12 status.
2. Write bit 12 of the ”GPIO Port C AFIO Configuration Register 1” pseudo-
randomly to select an alternative function for pin C11 between 0 and 1. Read
the pin C12 status.
3. Clear bit 12 of the ”GPIO Port C AFIO Configuration Register 1” to select
alternative function 0 for pin C11. Read the pin C12 status.
4. Write bit 12 of the ”Port C Pull-Down Selection Register” pseudo-randomly.
Read the pin C12 status.
5. Write bit 11 of the ”Port C Open Drain Selection Register” pseudo-randomly.
Read the pin C12 status.
6. Write bit 12 of the ”Port C Pull-Up Selection Register” pseudo-randomly.
Read the pin C12 status.
Its sequence of test items is displayed in Table 3.
Test Item 0 1 2
WriteAddress 400b4024 40022034 40022034
SetMask 0 0 0
ClearMask 0 0 1000
KeepMask fffffbff ffffefff ffffefff
PrndMask 400 1000 0
ReadAddress 400b401c 400b401c 400b401c
ReadMask 1000 1000 1000
Test Item 3 4 5
WriteAddress 400b400c 400b4010 400b4008
SetMask 0 0 0
ClearMask 0 0 0
KeepMask ffffefff fffffbff ffffefff
PrndMask 1000 400 1000
ReadAddress 400b401c 400b401c 400b401c
ReadMask 1000 1000 1000
Table 3: GPIO test example
2.8 CRC
The CRC module of the HT32F52 is well suited for testing, since (1) it has a
big variety of configurations, (2) the CRC engine can be fed by a DMA. DMA
processes cause additional bus traffic and amplify characteristic timing effects.
A test example of the CRC in combination with the PDMA module covers the
following steps:
1. Write a 16-bit random value into the ”CRC Control Register”. Read the first
custom ID word.
2. Write a random value into the ”CRC Seed Register”. Read the second custom
ID word.
3. Write a RAM address of the test program code to the ”PDMA channel 3
Source Address Register”. Read the third custom ID word.
4. Write the address of the ”CRC Data Register” into the ”PDMA channel 3
Destination Address Register”. Read a code word.
5. Set the PDMA transfer size to 4 blocks `a 250 bytes. Read the next code
word.
6. Write the ”PDMA Control Register” in order to assign random priority to
PDMA channel 3, use circular dest address mode, and start transfer. Read
the PDMA interrupt status.
7. Write a pseudo-random value to a RAM buffer. Read the ”PDMA Current
Transfer Size Register”.
8. Write a pseudo-random value to a RAM buffer. Read the ”CRC Checksum
Register”.
An implementation of this test as sequence of test items is depicted in Table 4.
Test Item 0 1 2 3
WriteAddress 4008a000 4008a004 4009004c 40090050
SetMask 0 0 20001000 4008a00c
ClearMask 0 0 dfffefff bff75ff3
KeepMask ffffff00 0 0 0
PrndMask ff ffffffff 0 0
ReadAddress 40080310 40080314 40080318 123C
ReadMask ffffffff ffffffff ffffffff ffffffff
Test Item 4 5 6 7
WriteAddress 40090058 40090048 20002000 20002000
SetMask 400fa 021 0 0
ClearMask fffbff05 cde 0 0
KeepMask 0 fffff000 0 0
PrndMask 0 300 ffffffff ffffffff
ReadAddress 1240 4009005c 40090120 4008a008
ReadMask ffffffff ffff0000 7fffffff ffffffff
Table 4: CRC test example
2.9 Summary
We presented a language for the specification of stimulus-response-tests to be
applied by the CPU to the ambient MCU modules. The set of stimulus-response-
tests forms a 4 row matrix called the test pattern. We indicated how to modify
the test pattern in dependency of a received challenge.
3 The self-test code
This section specifies the code segment of a self-test binary. We first specify the
fixed reference code. Then we will describe how the SBST prog modifies the
reference code in dependency of a received challenge during the loading of the
self-test binary.
On one hand-side, the self-test code is an interpreter for the test pattern, i.e.
it has to apply the stimuli, sample the responses as specified by the test pattern
data, and compute a hash sum over the sampled data and addresses. We call this
the execution of a test item. On the other hand-side, it implements multiple
emulation countermeasures.
We divide the code segment into four subsegments identified by the symbols
swap and hash,exec test item,hash, and interrupt handler.
3.1 The Feedback Loop
Figure 3 depicts the feedback loop between the hash buffer and the system.
In the feedback loop, the hash buffer has two functions: first, it’s a source of
pseudo-random stimulus data, and secondly, hashing the system feedback. The
System
Hash
feedback
stimulus
Fig. 3: Feedback Loop
code loops in the feedback loop over the test items of the test pattern data.
In each round it executes the test item below the symbol exec test item. For
hashing a data word, it jumps to a function in the hash segment. The function
exec test item samples and hashes 10 system states: (1) the test item encoded
in 5 words, (2) the system response. (3) the sysTick clock counter value, and (4)
three CPU registers.
3.2 The Hash functions
Our hash functions has a four word block size. In our SBST construction, the
exec test item and hash code segments are both challenge dependent. There-
fore, we obtain in fact a family of hash functions
(hash[challenge])challenge.
Furthermore, the hash code changes dynamically within this family once per
round of the feedback loop.
Before going into implementation details, specify what we want to achieve
by the hashing.
Requirement 1 (Pre-image resistance). The probability for an LCU to
compute for a fresh challenge and input blocks M0, M1, M 0
06=M0an input
block M0
1such that
hash[challenge](M0
0, M 0
1) = hash[challenge](M0, M1)
within the response time limit tlim is below pth.
Even if this requirement is relatively weak, it is not provable, or at least not
provable without a precise definition of the computational power of an LCU.
Nevertheless, we have a high trust in achieving the requirement with our hash
construction, since first, the pre-image problem is a problem of solving a system
of polynomial equations, and the equations are randomized by the challenge;
secondly, solving a system of polynomial equations is an NP-hard problem, and
resources of an LCU and computation time are limited, by definition.
The sequence of hash states S0, ...., SMafter hashing blocks of input data
serves as a pseudo-random sequence seeded by the challenge, and provides a
sequence of pseudo-random system stimuli. The lower 8 bits of the hash state
will be of special importance for stimuli in timing randomization. We require a
collision resistance of the hash function focusing on these lower bits. We impose
a requirement similar to requiring that each of the eight lower bits contributes
1/2 to the hash entropy.
Requirement 2 (Collision Resistance). The probability of
hash[challenge](M0, M1)[0 : 8] = hash[challenge](M0
0, M 0
1)[0 : 8]
for (M0, M1)6= (M0
0, M 0
1) is lower than 1/16.
This is again much weaker than the collision resistance requirement on a crypto-
graphic hash function, where the probability would need to be close to 1/256. A
rigorous definition requires a probability distribution on the space of random 5-
tuples (challenge,M0, M1, M 0
0, M 0
1). We assume a uniform distribution on the
challenge space (this is a requirement on the challenger), but the distribution
on the Mand M0spaces will not be uniform. (M0, M1) will be in a space of
sampled data and hash states of an authentic MCU, and (M0
0, M 0
1) will be in a
space of sampled data and hash states of a non authentic MCU. We impose the
requirement in the form that is has to be true for any malicious LCU. Again,
a prove of the requirement is not possible. Nevertheless one can gain trust by
testing special cases that might appear in an attack. One such case is M0
0=M0,
M1a fixed identifier block, and M0
1deviates from M1in one or two bits.
For performance reasons, we take four CPU core registers as hash buffer, and
implement the hash update solely with ALU instructions without any memory
access. We implement four polynomial functions
Fi:GF(2)96 →GF(2)32
of degree ≥3 using the 16-bit ARM-v6 CPU instructions MUL, ORR, ADD,
EOR, REV, REV16, REVSH, ROR, MVN. For a hash update with input block
M0, .., M3, we apply a code similar to the pseudo-code in Figure 4. In this way,
H 0 = ROT(H 0 + F 0 ( H 1 ,H2 , H3 ) ˆM 0 )
H 1 = ROT( H 1 + F 1 (H 0 , H2 , H3 ) ˆM 1 )
H 2 = ROT( H 2 + F 2 (H 0 , H1 , H3 ) ˆM 2 )
H 3 = ROT( H 3 + F 3 (H 0 , H1 , H2 ) ˆM 3 )
H 0 = ROT( H 0 + F 0 (H 1 , H2 , H3 ) ˆM 2 )
H 1 = ROT( H 1 + F 1 (H 0 , H2 , H3 ) ˆM 3 )
H 2 = ROT( H 2 + F 2 (H 0 , H1 , H3 ) ˆM 0 )
H 3 = ROT( H 3 + F 3 (H 0 , H1 , H2 ) ˆM 1 )
Fig. 4: Hash update
we can achieve the hashing of a four word block in less than 100 CPU clocks.
Challenge dependency of the hash function is obtained by swapping of two 16-
bit instructions (see the next subsection) within a code word. This will not only
change the execution order but also the polynomials (keeping the polynomial
degree).
3.3 Swap and hash
An SBST requires challenge dependent code. For this purpose, we implement
exec test item and the hash function as swappable code, i.e. we only use
16-bit CPU instructions, and implement the code in such a way that each swap,
i.e. the exchange of the two instructions in word aligned code word, provides a
new code still suitable for test item execution and hashing. Note that for most
code words in the two functions, a swap changes either the code timing, or the
hash function itself.
Aswap is the exchange of two 16-bit instructions in a 32-bit code word. The
reference test program is implemented in such a way that a 256-byte block of its
code segment consists of 64 pairs of 16 bit instructions, and each test program
obtained by the application of swaps to these pairs again complies with the test
program specification.
The responder loads the reference test program code from flash to SRAM
while swapping words in the swappable code block according to the first 64 bits
of the challenge. The initial code swapping is encoded in the challenge. The
CRT program prog has to load the code in a swapped form from flash into
RAM before its execution.
We implement the feedback loop as self-modifying code, again by swapping.
For this self-modification, the feedback loop calls at least once per round the ad-
ditional function swap and hash for reading two code words of exec test item
or hash, swapping the code words, hashing the swapped code words and writing
the swapped code words back to memory.
3.4 The Interrupt Handlers
In addition to the feedback loop as main thread, we implement clock counter
interrupt handlers for the modules BFTM0 and BFTM1 [2]. The SBST prog
configures these modules in such a way that their interrupts are triggered if
the clock counter value reaches the “Compare Value Register”. Within the in-
terrupt handlers 12 words of the CPU state of the interrupted thread will be
sampled and hashed. Hashing uses the same hash function and hash buffer as
exec test item and swap and hash. Parts of the CPU states will be sampled
from the stack, where stored by the interrupt entry process implemented in hard-
ware. We consider the return address sampled as a CPU state as timing data
since it depends uniquely on the runtime when the interrupt was triggered. After
sampling and hashing the CPU state, each interrupt handler will reconfigure its
own “Compare Value Register” pseudo-randomly. The source of pseudo-random
data are the lower 8 bits of the hash state. This “timing feedback” makes timing
difficult to predict on non-authentic hardware. We trim the reconfigurations in
such a way that between any two interrupts the feedback loop (main thread)
will sample between 20 and 40 system states.
4 Rationale
This section shows first, that the self-test construction described in Sections 2
and 3 meets the SBST definition, and secondly that the provided SBST is re-
liable, i.e. that it is a group invariant of the MCU intrinsic group. It finally
demonstrates the four MIGA security objectives [1] for the described implemen-
tation.
4.1 SBST mapping
We map the described construction of a challenge dependent self-test binary
(code,data) to the definition of an SBST in Section 2.4 of [1] and check that
the requirements A-D are met:
1. The system stimulation by data words wiis achieved (a) in exec test item
by writing one stimulus per test item of the test pattern data to the stim-
ulus location; (b) in swap and hash by writing swapped code back to code
memory; (c) in the interrupt handler by the pseudo-random timer recon-
figuration.
2. The sampled memory and register data sicovers (a) in exec test item
the test items (in a five word encoding), (b) the system responses, (c)
timer values; (d) in swap and hash the sampled code words; (e) in the
interrupt handler the stacked CPU states. During the loop over the 80
test items, 1248-1536 system states will be sampled and hashed, the exact
number depends on the interrupts.
3. The hash sum hash(s1, ..., sN) is computed by hash updates triggered by
exec test item,swap and hash, and the interrupt handler in a pseudo-
random order.
Table 5 displays the applied stimuli and sampled system responses per func-
tion. Check the requirements A-D on a SBST: (A) The code depends on the
challenge due to the initial swapping, but not uniquely. However, the pseudo-
random stimulus sequence will uniquely depend on the challenge, which leads to
a unique interrupt timing, and hence to a unique instruction flow. (B) Due to
the braiding, data will depend on 125 bits of the challenge. (C) The stimuli lo-
cations obviously depend on data. (D) The response locations obviously depend
on data.
4.2 MIGA parameters
As probability threshold, set pth := 0.001, and assume a worst case attack
potential of (px,py) = (0.9,0.1).
Function Stimulus Sampled data Sample count
swap and hash Swapped code words Code of functions
exec test item and
hash
2
execute test item Specified by test item Test item, system re-
sponse, clock counter,
program counter
10
interrupt handler Self reconfiguration Stacked CPU state 12
Table 5: Data sampled by code functions.
We claim test coverage, after a loop over 80 test items. If the loop is repeated
multiple times, i.e. a multiple of 80 test items are executed, then test coverage
of characteristic group features is obtained by an arbitrary runtime interval
covering a sequence of at least 80 test items. By construction, if a sequence
sm, ..., snis sampled, and m−n≥1536, then the sequence covers 80 consecutive
test items and the corresponding response data. In consequence, c= 1536 would
be sufficient. Nevertheless, set c:= 1548 in order to achieve d|(c+o).
At least one out of 17 consecutive samples will be a timing state. Nevertheless,
we only append bits of some timing samples to the timing signature. In this way
we can achieve a mesh width d= 52.
We will show that it follows by the assumed pre-image resistance of the hash
function that a feedback parameter o= 220 is sufficient.
The samples count Ncan be arbitrarily increased in order to obtain the
value required in Theorem 1 of [1] by repeating the loop. With the assumption
of py = 0.1, we need a minimal re-synchronization count 3. In consequence,
if the requirements of Section 4.1 of [1] hold, we get an MCU intrinsic group
authenticator for N= (c+d+o)·(Y+ 1) = 7280. This requires hashing of 1820
input blocks during the self-test execution.
4.3 Reliability
The most important thing is the reliability of the SBST, i.e. that the challenge-
response function is deterministic on a single MCU, and invariant of the group
element of an MCU intrinsic group. For testing the reliability we used two dif-
ferent MCU models: HT32F52 by Holtek, and SAM3x8e by STMicroelectronics.
We used six boards for each of the MCU examples for testing. Figue 5 shows the
test setup.
Long term test Repeated challenge-response testing with 1 week runtime on
multiple devices did not reveal any mismatch.
Voltage tests We first choose minimal and maximal voltage keeping the de-
vice and I/O alive. For HT32F52 the minimum was 2.2V, the maximum 5.2V.
Fig. 5: Test Pattern
Specified boundaries are: 2.0-3.6. As long as the chip responed, no mismatch was
observed.
Temperature tests Tested MIGA implementation on HT32F52 in a temper-
ature range of 20◦−120◦Celsius without any mismatch.
4.4 Power-on-off cycles
In repeated power-on-off cycles no mismatch was observed.
4.5 Hardware coverage
We start the verification of the security requirements in Section 4.1 of [1] with
the Hardware coverage:
The ECU is authentic if its MCU is in group(M, model,id). The MCU
model is characterized by the processor model and characteristic peripherals.
If m−n>c= 1536, an MCU executing the authentic self-test binary runs the
feedback loop over the complete test pattern and therefore verifies the charac-
teristic peripherals and the identifier id(M). If sound(m, n, response) is true,
by definition sync(m, n, response) is true as well, and again by definition, the
responder MCU has the authentic processor model. Necessarily, an MCU with
authentic processor model, characteristic peripherals and authentic identifier is
authentic. This proves the hardware coverage requirement.
4.6 Code coverage
We achieve the code coverage objective for the functions exec test item and
hash by a combination of code self-modification and code verification: In each
round of the feedback loop, the function swap and hash is called at least once.
Each code word of exec test item and hash will be swapped twice within the
loop over 80 test items. Due to the timing effect of the swapping, this ensures
that the hashed and executed code are identical. The remaining functions, in
particular swap and hash and the interrupt handlers will be verified via test
items with system response locations pointing to their code regions. In order
to verify that executed and sampled code of the interrupt handlers agree, the
vector table offset register and the entries in the vector table are sampled via
suitable test items.
4.7 Feedback
We enforce a feedback between system responses and stimuli by using one word
of the hash buffer as source of pseudo-random stimulus data.
If ¬sound(m, n, response) and ¬spoof(m, n, response), there is an i∈
[m, n] such that (r0
i, s0
i)6= (ri, si) is fed as input to the hash function. Due
to the the claimed collision resistance (2), the maximal probability for
hash0
j[0 : 8] = hashj[0 : 8]
is 1/16. The interrupt handler uses the 8 lower bits of the hash state as timing
stimulus. There will thus be a non-authentic clock counter reconfiguration by one
of the upcoming four interrupt handlers with probability greater 1 −1/163>
1−pth/4, if pth = 0.001. Since this reconfiguration uniquely determine the
runtime of the next interrupt, synchrony with an authentic reference MCU will
be lost at least at the fifths interrupt. We sample a maximum of 40 samples
in between two interrupts and 12 by the interrupt handler, we thus achieve the
feedback objective for the feedback parameter o= 4 ∗(40 + 12) + 12 = 220.
4.8 Spoofing detection
Synchronous spoofing requires a malicious Lrunning a synchronous code0with
functions exec test item and/or hash manipulated by some transformation
τ(r0
i, s0
i)7→ (ri, si). The attacker has to implement this transformation in such
a way that it doesn’t change timing between sample times tnand tm−1. On
the other hand-side, it’s a non-trivial transformation, since it has to distinguish
cases with (r0
i, s0
i) = (ri, si), e.g. if siis a peripheral response, and cases with
(r0
i, s0
i)6= (ri, si). A synchronous spoofing can be prevented by a combination of
three types of countermeasures: First, by reducing the degree of freedom for syn-
chronous code manipulations. Secondly, by increasing the complexity for spoofing
of sampling locations rior sampled data si. Third, by detection mechanisms for
code manipulations.
Reducing the degree of freedom Three implementation requirements reduce
the degree of freedom for synchronous code manipulations: First, code efficiency,
secondly, a minimal number of memory reads and writes, third, the exhaustive
use of CPU registers.
The manipulated code has to implement the functionality of the authentic
code plus additional functionality for data or address spoofing. If code has max-
imal efficiently, there is no space for the transformations. If the attacker finds
a way to implement the authentic functionality a bit more efficient, (s)he can
insert some extra instructions.
We can minimize the number of memory accesses by implementing the hash
function completely without memory accesses. The hash buffer uses four CPU
registers and only ALU instructions are required for the hashing. In this way we
get that each read data word is a sample, which will be hashed. Since synchronous
code will have the same sequence of memory accesses, there is no way for the
spoofing transformation to use a lookup table in memory.
If the authentic code makes use of all CPU working registers, and if the
authentic functionality cannot be implemented as fast with less CPU registers,
then a spoofing manipulation will also not be able to store data in registers.
Increasing the complexity Some of the described implementation details
already ensure that the spoofing is complex: The indirect addressing via the
test items, the challenge dependent test pattern and code, the code dynamiza-
tion by the function swap and hash, and the mutual code verification between
swap and hash and exec test item.
Additionally, let system response addresses of test items point to half word-
aligned code addresses of exec test item and hash. Then, the spoofing trans-
formation needs to distinguish for each of these code words four cases depending
on the swap history of the two overlapping word aligned code words.
Detect code manipulations The clock counter will interrupt the the feedback
loop at pseudo-random runtimes. At each interruption, each CPU register not
used as hash buffer is sampled and hashed. Assume that if despite the described
countermeasures spoofing transformations exist, then the CPU state of the mod-
ified main thread deviates at least in 1/4 of its runtime from the authentic CPU
state. Sampling a number of c= 1548 system states covers at least 25 inter-
rupts. The probability to detect a modified CPU state within the 25 interrupts
is greater 1 −pth/4 if pth = 0.001.
4.9 Application note
Note that for the use of MIGA in practice, the MCU manufacturer (this is Holtek
in the example) must reserve a fixed group identifier (the “custom ID”) for the
MCUs to be used in the original ECUs. The original ECU manufacturer and
the MCU manufacturer need to ensure by contracts and suitable organizational
means that no third party will ever have access to (HT32F52) MCUs with the
reserved group identifier.
4.10 Summary
This section first showed that the construction of code and data described in
Sections 2 and 3 is indeed a software based self-test according to the definition
in [1]. It then provided evidence that the SBST construction provides a deter-
ministic challenge-response function, independent of the group element in the
MCU intrinsic group. Then it verified that the construction is an MCU intrinsic
group identifier, assumed that parameters are suitably chosen.
5 Conclusion
We demonstrated that it is feasible to authenticate ECUs without using secret
keys, provided that all ECUs have an MCU of a dedicated MCU model with
a group identifier in read-only memory, and provided that no third party gets
access to such MCUs.
References
1. F. Schuhmacher, “Software-based self-testing for the authentication of car
components,” to be published in ESCAR, 2020. https://www.escar.info/
download-area.html.
2. Holtek, “HT32F52342/HT32F52352 user manual, Holtek 32-bit microcontroller
with ARM Cortex-M0+ core.” Revision: V1.30, September 28, 2018.
3. Holtek, “HT32 MCU, starter kit user manual.” Revision: V1.00, March 19, 2018.
4. Atmel, “SAM3X/SAM3A series datasheet.”
5. Arduino, “Arduino due schematic.” https://www.arduino.cc/en/uploads/Main/
arduino-Due-schematic.pdf.