A MIGA design and example implementation
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 identiﬁer. The reference  provides a
MIGA deﬁnition, an attacker model, four security objectives, and a se-
curity proof for MIGA, provided that the four security objective are sat-
isﬁed. This paper demonstrates how to achieve these security objectives
for the example of a group of HT32F52 MCUs with a common “custom
identiﬁer”. Furthermore, reliability test results are provided.
We provide an example implementation for the MIGA scheme  for the MCU
model HT32F52 . 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 identiﬁer” is well-suited as a group identiﬁer; (3) it has mul-
tiple clock counter modules that can be conﬁgured without a prescaler; (4) the
CRC module and ﬂash conﬁguration options provide nice self-test examples. The
starter-kit  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 . The Arduino Due  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 ﬁx 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 modiﬁ-
cations to be applied to a reference self-test binary. The reference self-test
binary is product speciﬁc but identical for each authentic ECU, and stored in the
ﬂash of its authentic MCU. The modiﬁed binary (code,data) will mainly reside
in RAM. We will ﬁrst describe the construction of the data segment in Section 2.
We will then describe the construction of the code segment in Section 3.
The ﬁnal Section 4 shows (1) that the self-test construction provides an
SBST, (2) that the SBST is a group invariant, and (3) that it satisﬁes the four
MIGA security objectives.
2 The test pattern
The data segment of a self-test binary speciﬁes “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 speciﬁes 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 deﬁned 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 modiﬁed
pseudo-randomly (PrndMask), and a system response mask (ReadMask) in order
to specify which bits at the system response location (ReadAddress) form the
Astimulus-response-test is speciﬁed 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 identiﬁer id(M) in order to distinguish between group elements and
non-group elements in model(M).
It is always possible to ﬁnd 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 diﬀerent 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 diﬀerent
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 diﬀerent CHIP ID or a diﬀerent 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 speciﬁca-
Fig. 1: Test Plan
tion of stimulus-response-tests for the modules NVIC, FMC, GPIO, and CRC
(see ) in the following subsections.
A challenge dependent test pattern is formed by column wise permutations of
this matrix. The ﬁrst 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 ﬂash 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.
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 . 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 reconﬁgurations
of the timers. The following enumeration speciﬁes 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 ﬂash memory.
For testing the ﬂash memory controller FMC of the HT32F52, we apply stimuli
to the FMC module to mess up the timing of ﬂash 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 buﬀer. We will not change the
setting of ﬂash 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 eﬀect 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
Table 2: FMC test example
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
conﬁguration 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 Conﬁguration 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 Conﬁguration 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
The CRC module of the HT32F52 is well suited for testing, since (1) it has a
big variety of conﬁgurations, (2) the CRC engine can be fed by a DMA. DMA
processes cause additional bus traﬃc and amplify characteristic timing eﬀects.
A test example of the CRC in combination with the PDMA module covers the
1. Write a 16-bit random value into the ”CRC Control Register”. Read the ﬁrst
custom ID word.
2. Write a random value into the ”CRC Seed Register”. Read the second custom
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
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 buﬀer. Read the ”PDMA Current
Transfer Size Register”.
8. Write a pseudo-random value to a RAM buﬀer. Read the ”CRC Checksum
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
We presented a language for the speciﬁcation 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 speciﬁes the code segment of a self-test binary. We ﬁrst specify the
ﬁxed reference code. Then we will describe how the SBST prog modiﬁes the
reference code in dependency of a received challenge during the loading of the
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 speciﬁed 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
We divide the code segment into four subsegments identiﬁed 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 buﬀer and the system.
In the feedback loop, the hash buﬀer has two functions: ﬁrst, it’s a source of
pseudo-random stimulus data, and secondly, hashing the system feedback. The
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
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
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 deﬁnition of the computational power of an LCU.
Nevertheless, we have a high trust in achieving the requirement with our hash
construction, since ﬁrst, 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 deﬁnition.
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 deﬁnition 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
M1a ﬁxed identiﬁer block, and M0
1deviates from M1in one or two bits.
For performance reasons, we take four CPU core registers as hash buﬀer, and
implement the hash update solely with ALU instructions without any memory
access. We implement four polynomial functions
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
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
The responder loads the reference test program code from ﬂash to SRAM
while swapping words in the swappable code block according to the ﬁrst 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 ﬂash into
RAM before its execution.
We implement the feedback loop as self-modifying code, again by swapping.
For this self-modiﬁcation, 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 . The SBST prog
conﬁgures 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 buﬀer 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 reconﬁgure 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
diﬃcult to predict on non-authentic hardware. We trim the reconﬁgurations in
such a way that between any two interrupts the feedback loop (main thread)
will sample between 20 and 40 system states.
This section shows ﬁrst, that the self-test construction described in Sections 2
and 3 meets the SBST deﬁnition, and secondly that the provided SBST is re-
liable, i.e. that it is a group invariant of the MCU intrinsic group. It ﬁnally
demonstrates the four MIGA security objectives  for the described implemen-
4.1 SBST mapping
We map the described construction of a challenge dependent self-test binary
(code,data) to the deﬁnition of an SBST in Section 2.4 of  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-
2. The sampled memory and register data sicovers (a) in exec test item
the test items (in a ﬁve 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-
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 ﬂow. (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
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
execute test item Speciﬁed by test item Test item, system re-
sponse, clock counter,
interrupt handler Self reconﬁguration 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 suﬃcient. 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 suﬃcient.
The samples count Ncan be arbitrarily increased in order to obtain the
value required in Theorem 1 of  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  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.
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
Long term test Repeated challenge-response testing with 1 week runtime on
multiple devices did not reveal any mismatch.
Voltage tests We ﬁrst 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
Speciﬁed boundaries are: 2.0-3.6. As long as the chip responed, no mismatch was
Temperature tests Tested MIGA implementation on HT32F52 in a temper-
ature range of 20◦−120◦Celsius without any mismatch.
4.4 Power-on-oﬀ cycles
In repeated power-on-oﬀ cycles no mismatch was observed.
4.5 Hardware coverage
We start the veriﬁcation of the security requirements in Section 4.1 of  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 veriﬁes the charac-
teristic peripherals and the identiﬁer id(M). If sound(m, n, response) is true,
by deﬁnition sync(m, n, response) is true as well, and again by deﬁnition, the
responder MCU has the authentic processor model. Necessarily, an MCU with
authentic processor model, characteristic peripherals and authentic identiﬁer 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-modiﬁcation and code veriﬁcation: 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 eﬀect 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 veriﬁed 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 oﬀset register and the entries in the vector table are sampled via
suitable test items.
We enforce a feedback between system responses and stimuli by using one word
of the hash buﬀer 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)6= (ri, si) is fed as input to the hash function. Due
to the the claimed collision resistance (2), the maximal probability for
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 reconﬁguration by one
of the upcoming four interrupt handlers with probability greater 1 −1/163>
1−pth/4, if pth = 0.001. Since this reconﬁguration uniquely determine the
runtime of the next interrupt, synchrony with an authentic reference MCU will
be lost at least at the ﬁfths 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 Spooﬁng detection
Synchronous spooﬁng requires a malicious Lrunning a synchronous code0with
functions exec test item and/or hash manipulated by some transformation
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) = (ri, si), e.g. if siis a peripheral response, and cases with
i)6= (ri, si). A synchronous spooﬁng 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 spooﬁng
of sampling locations rior sampled data si. Third, by detection mechanisms for
Reducing the degree of freedom Three implementation requirements reduce
the degree of freedom for synchronous code manipulations: First, code eﬃciency,
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 spooﬁng. If code has max-
imal eﬃciently, there is no space for the transformations. If the attacker ﬁnds
a way to implement the authentic functionality a bit more eﬃcient, (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 buﬀer 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
spooﬁng 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 spooﬁng manipulation will also not be able to store data in registers.
Increasing the complexity Some of the described implementation details
already ensure that the spooﬁng 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 veriﬁcation 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 spooﬁng 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 buﬀer is sampled and hashed. Assume that if despite the described
countermeasures spooﬁng transformations exist, then the CPU state of the mod-
iﬁed 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 modiﬁed 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 ﬁxed group identiﬁer (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 identiﬁer.
This section ﬁrst showed that the construction of code and data described in
Sections 2 and 3 is indeed a software based self-test according to the deﬁnition
in . 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 veriﬁed that the construction is an MCU intrinsic
group identiﬁer, assumed that parameters are suitably chosen.
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 identiﬁer in read-only memory, and provided that no third party gets
access to such MCUs.
1. F. Schuhmacher, “Software-based self-testing for the authentication of car
components,” to be published in ESCAR, 2020. https://www.escar.info/
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/