hello and welcome uh to the presentation
of our work coin GNN based control flow
adastation for embedded
devices uh we did this work with our
colleagues from the Technical University
of damad Nvidia and the University of
Southampton but first of all why do we
even need uh control flow
adastation um over the recent years we
saw a steady increase in remote code
execution vulnerabilities but also at
the same time um an increase in iot
devices
worldwide and this um leads to an
increased exposure uh to uh code reuse
attacks um in these uh iot devices with
low
security so some background on control
flow attestation CFA what is control
flow attestation in the most generic and
highlevel way we have U three parties
the verifier the approver and the third
party and the third party uh wants to be
sure of the state of execution of the
Prov so it goes like this that the
verifier uh sends an attestation
challenge to the prover and ask it to uh
provide evidence um of his State the
Prov is Computing or collecting this
evidence and then returning it to the
verifier where the verifier is verifying
this evidence for example against the
database of uh matching evidences or
through other means timing and so on and
then the verify is a disseminating a
report uh which is uh most of the time
signed by the verifier which shows the
third party the state of the Prov for
example if it's benign if the
computations are correct or
not so also some background about code
reuser Texs I stated them earlier but uh
what are code reuser Texs and what
examples are there for code Reus Texs uh
here on the right you see a control flow
graph also called
CFG and this control flow graph has uh
two different benign executions uh for
example the uh green one from V1 to V7
but also the uh Violet one from V1 to V7
um over different nodes
um and a return oriented programming
attack also called Rob attack um adds
extra transitions to this a control flow
graph as you can see here from uh V1 to
V7 um the
execution has basically the same start
and end point but it is jumping from V6
to V uh 3 uh for example to create um
malicious functionality which is not in
the initial benign control flow graph on
the other hand uh a data oriented
programming attack or also called dop
attack uh reuses theb9 transitions but
still Alters the control flow but not
the control flow graph so as you can see
here the execution goes from V1 over V4
to V7 and the first part is reused from
the green uh execution v9 execution and
the second part is reused from The
Violet B9
execution um so we come to the uh
related work in this scenario uh about
control flow attestation schemes um you
can divide them in three topics on
control flow adapation schemes relying
on a complete control flow graph as a
reference um on them relying on the
memory access to the memory content and
uh relying on custom Hardware the
problem is that um having a complete
control flow graph is a very strong
assumption it's uh
sometimes not possible to um calculate
one um access to the memory content can
lead to information leakage for example
between the prover when it's collecting
the evidence and uh to the and sending
it to the verifier so
um either on the way or on the verifier
side this information can be leaked and
custom Hardware is uh expensive in
design and it's not applicable to
off-the-shelf devices
which brings us to our uh question
research question is it possible to
relax the assumptions by leveraging
Machine learning uh to not have to rely
on these uh strong
assumptions so uh we looked into
suitable machine learning techniques uh
and chose uh graph neural network as a
promising solution um and as evidence we
chose to collect basic block addresses
of the execution Trace uh this avoids
information leakage to the verifier
because we only sending the program
counter values uh we then process the
trace to an execution
graph while extracting uh the features
and uh here we don't impose any
assumptions about its completeness
because it it's just uh extracted from
one execution
trace and finally we extract per node
embeddings from the graph using a graph
neural network and this
way uh we maintain a correlation between
elements uh in the different
representation as you can see here in
red from the execution tray uh over the
execution graph and over the execution
embeddings there's a one to one uh
correlation M maintained this is our key
intuition so um this key intuition is
then utilized by our approach called
rage uh which does uh not rely on
complete control flow graphs as I as I
said earlier uh we use unsupervised
graph neural networks to relax this
assumption and this model we we
uh yeah we we we show that this model
learns the execution patterns and
correctly separates benign and malicious
executions um it also does not leak any
uh data to the verifier or on the way on
the way between verifier and prover uh
because we only collect program counter
addresses
uh it is also not platform specific as
we will show later um it can be run on
any platform um which has a
te and uh we don't need any extra
Hardware we also don't need uh data
labeling on our on the machine learning
site uh it is very lightweight the model
counts uh less than 9,000 parameters and
can run even on a rasp P where I will
also show evaluation
later and uh as stated uh for the code
reuse attacks the model can precisely
detect Rob and do attacks including real
world attacks which were uh never seen
before so
um uh uh we use variational graph uh
Auto encoder in our um graph neural
network uh approach and graph variation
graph Auto encoders or also called VGA
are state-of-the-art generative models
uh trained to learn to reconstruct input
graphs to Output graphs and we designed
our custom encoder able to extract the
latent features of the input graph and
the um you can say that the control flow
graph behavior is therefore captured in
the output
embeddings and uh this customized
version of a VJ is used in our approach
um which I will explain in
detail so here on the right you can see
um uh our encoder design uh using
um on the our a custom encoder design uh
which consists of four graph
convolutional uh layers uh which vary in
dimensionality from 15 to 48 uh
connected by Dropout layers for regular
ing the training and we selected the VJ
as a model of choice as it was matching
our requirements specifically through a
phase of model selection we designed our
custom encoder keeping in mind the
trade-off between complexity of the
model and performance uh of of
extracting these embeddings that are
rich enough to capture the control flow
behavior and as I said earlier the en
encoder counts of four layers with
varying Dimensions uh specifically we uh
increase the dimensionality for
expanding the features we extracted
during the feature engineering phase and
consequently we reduce it slightly again
to discard the most noisy
features where which brings us uh to our
system overview uh to train our approach
we trace the executed software as stated
earlier this one Trace is pre-processed
into a graph representation and features
are extracted this graph is then used to
uh train the model uh extract the
embeddings and tune the attestation
threshold on the validation set to
attest an execution the software is
traced again pre-processed and forwarded
to the VJ encoder which then extracts
the embeddings computes the distance
between them and uh the training
embeddings and this distance is then
tested against the threshold and the
system discerns between a benign and
malicious execution
uh we uh did a real world uh evaluation
on code reuser attacks um we extended
the r framework uh with a gadget length
configuration option for testing
different uh Rob chain length and the r
framework is a collection of um uh uh um
code reuser text
robex um uh we extended it also to
include uh benign application logic to
collect traces from additional software
and we chose to use software from MCH
iot data
set and we tested this on uh a beagle
bone black a siling Ultra scale plus and
an Nvidia
Jetson um
device and as you can see here on the
right uh rage correctly separates B9 and
detect traces in every case uh with a
great distance even this is because this
um ripe framework attack is not stealthy
the Rob attack is basically not
returning um the execution flow back to
the benign application but is
um uh basically uh terminating the
program and resulting in a in a
shell to also be able to evaluate stey
uh cras we uh simulated um Rob and dop
attacks on tra on Bine Traces by um
creating an algorithm which adds
malicious traces which uh show Rob and
do attacks in these traces uh to the
traces we uh did it this way that the
control flow is always returned to the
program which uh as I stated earlier
ripe attacks
don't so these are more stealthy uh we
evaluated on 23 software
um collecting around one terabyte of
Trace data on which we evaluated here on
the right you can see that the data sets
we use are um open SSL and thee
mentioned mben iot data set so as you
can see um for Rob and do attacks the F1
score on both sides is in the high 90
range which means that we are able to um
detect even Steepy simulated um Rob and
do attacks which are even more more sty
than in the real world uh however Rob
attack is easier to detect as it creates
new edges in the control flow graph and
dop attacks are harder uh as it reuses
benign edges but and this detection of
the do attack also heavily relies on the
extracted features uh where we have also
evaluation in the paper so uh refer
refer to the paper for uh this
evaluation we also evaluated um
different uh Rob chain length in the
paper um so yeah refer to the
paper here in detail for the op SSL data
set uh you can see that for uh both Rob
and do attack the distance of the benign
ones in uh yellow and the uh malicious
ones in blue uh is rather high and it's
uh and most are easy to
detect uh finally we also evaluated the
performance we uh used um a Raspberry Pi
for B2 gigabyte version to show that uh
the approver and the verifier can both
be an edge device such an such as an
Raspberry Pi and for on the Prova side
you can see that the average Trace step
length is around um 100 to 100,000 to uh
10 million uh the but still
pre-processing time is only around 4
seconds the processed Trace size is um
only um in average around 0.73 kilobyte
which is set sent over the network uh
here you can also do the pre-processing
on the verifier side but then
uh the whole Trace needs to be sent over
so this is a um tradeoff between um
preprocessing on the Prov or sending
over the
network uh on the verifier side the
initial model training time only takes 5
minutes on a Raspberry Pi which is
feasible and the inference runtime uh of
the uh VJ model is only
0.005 seconds uh per execution
Trace thank you very much