So, the next talk will be about embedded system security and Pascal, the speaker, will explain

how you can hijack debug components for embedded security in ARM processors. Pascal is not only an abandoned software security engineer, but also a researcher in his spare time, so please give a very, very warm, welcoming good morning applause

to Pascal. Okay, thanks for the introduction. So, as it was said, I'm an engineer by day in a French company, so I work as an embedded system security engineer, but this talk is mainly about

mass Python activity, which is a researcher, whatever you call it. This is because this talk I worked with a PhD student called Muhammad Adulgharab, and he was a third-year PhD student in the French lab, so this talk will be mainly a representation on this work about the embedded system security,

and especially the debug components available in ARM processor. Don't worry about the link, at the end there will be also the link with all the slides, the documentations, and everything. Before the Congress, I didn't know about what kind of background did you need for my talk,

so I put there some links, I mean some references of some talks, where you will have all the vocabulary needed to understand at least some parts of my talk. So yeah, about the computer architecture and the embedded system security, I hope you had attended the talk

by Alistair about the formal verification of software, and also the talk by Keegan about trusted execution environments, so VTE, search, and in this talk I will also talk about FPGA stuff, and about FPGAs, so there was a talk on day two about FPGA reverse engineering, and if you don't

know about FPGAs, I hope that you have some time to go to the FPGA assembly, because these guys are doing a great job about FPGA open source tools. So yeah, when you see this slide,

I mean the first question is that why I put Trozone is not enough. Just a quick reminder about what is Trozone. Trozone is about separating a system between a non-secure world in red, and the secure world in green, so when we want to use the Trozone framework,

we have lots of hardware components, lots of software components, allowing us to let's say to run separately a secure OS and a non-secure OS. In our case, what we wanted to do is to use

the debug components, you can see it on the left side of the picture, to see if we can make some security with it. Furthermore, we wanted to use something else than Trozone, because if you

attended the talk about the security in the Nintendo Switch, you can see that the Trozone framework can be let's say bypassed under specific cases. Furthermore, this talk is something quite complementary, because we will do something at a low level, I mean at a low level,

at the processor architecture level, so I will talk in a later part of my talk about what we can do between Trozone and the approach developed in this work. So basically the presentation will be a quick introduction. I will talk about some works aiming to use debug components to make

some security. Then I will talk about Armex, which is the name of the system we developed to use the debug components in Harper Store, and finally some results and the conclusion. So yeah, in the

context of our project, we were working with system-on-ships. So system-on-ships are this kind of device where we have in the green part a processor, so it can be a single core, a dual core, or even a quad-core processor. And another interesting part which is in yellow in the image

here is the programmable logic, which is also called an FPGA in this case, and in this kind of system-on-ship, you have the output processor, the FPGA, and some links between those two units.

And so you can see here in the little red rectangle, one of the two processors. So yeah, this picture is an image of a system-on-ship called ZYNC, provided by Xyninx, which is also an FPGA provider. And this kind of ship, we usually have two Cortex-9 processors and some FPGA logic to work with.

So yeah, so what we want to do with the debug components is to work about dynamic information flow tracking. So basically, what is information flow? Information flow is the transfer of information

from an information container C1 to C2 in the given process P. So in other words, if we take this simple code over there, if you have four variables, for instance A, B, W, and X, the idea is

that okay, if you have some metadata in A, the metadata will be transmitted to W. In other words, what kind of information will we transmit into the code? Well, basically, the information I'm

talking in the first block is okay, this data is private, this data is public, and we should not mix data which are public and private together. So basically, we can say that the information can be a binary information which is public or private, but of course, we will be able to have

several levels of information. In the following parts, this information will be called taint or even tags, and to be, let's say, to be a bit more simple, we will use some colors to say okay, my tag is red or green, just to say if it's private or public data. So yeah,

so as I said, if the tag contained in A is red, the data contained in W will be red as well, and the same thing for B and X. If we take a quick example over there, so if we look

at a buffer overflow, so in the upper side of the slide, you have the assembly code, and on the lower part, the green column will be the color of the tags, and on the right side of these

columns, you have the status of the different registers. So this code is basically okay when my input is red at the beginning, so basically we just use the taint input into the index variable, so basically the register 2 which contains the IDX variable will be red as well, and then

when we want to access a buffer IDX, which is the second line in the C code at the beginning, basically the information there will be red as well, and of course the result of the

operation which is X will be red as well. So basically that means that if there is a tainted input at the beginning, we must be able to transmit this information until the return address of this code, just to say okay if this tainted input is private, the return address at the end of

of the code should be should be private as well. What can we do with that? There is a simple code over there, so this is a simple code saying okay if you are a normal user in your code, you would just have to open

the welcome file, otherwise if you're a root user you must open the password file, so this is basically to say okay if we want to open the welcome file, this is a public information you can do whatever you want with it,

otherwise if it's a root user maybe the password will contain for instance a cryptographic key, and we should not go to the printf function at the end of this code, so basically the idea behind that is to check that the fs variable containing the data of the

file is private or public, so there are mainly three steps for that. First of all the compilation will give us the assembly code, then we should modify, well we must modify the system calls to send the tags, so the tags will be as I said before the

private or public information about my fs variable, and I will talk a bit about that later but maybe in future works the idea is to make or at least compile an operating system

integrated with integrated support service for the IFT, so there were already some works about dynamic information flow tracking, so basically we should do this kind of information flow tracking in two manners, so the first one at the application level, so basically working

at the java on android level, some works also propose some solutions at the os level, for instance kblair, but what we wanted to do here is to work at a lower level,

so this is not at the application of the os level but just at the hardware level or at least at the processor architecture level, so if you want to have some information about the os level implementation of information flow tracking you can go to blair-ideas.ro

where you have some implementations of an android port and the java port of intrusion detection systems, so yeah in the rest of my talk I will just go through the existing works and just see what we can do about that.

When we talk about dynamic information flow tracking at the low level there are mainly few approaches, the first one is the one in the left side of the slide, so basically

the idea is to say okay in the upper side of this figure we have the normal processor pipeline, so basically decode stage and register file and arith 20 and logic unit and the basic idea is to say okay when we want to process with tags or taints we just

duplicate the processor pipeline, so basically with the gray pipeline under the normal one just to process data and it implies two things, first of all we must have the source code of the processor itself just to duplicate the processor pipeline and to make the let's say the DFT

pipeline, so this is quite convenient because we must have the source code of the processor which is not really easy sometimes

and otherwise let's say the main advantage of this approach is that okay we can do nearly anything we want because we have access to all codes so we can pull all wires we need from the processor just to get the information we need. On the second approach so this is the right

side of the picture there is something a bit more different so instead of having a single processor aiming to do the normal application flow plus the information flow tracking we should separate the normal execution and the information flow tracking so this is the second approach

and this approach is not satisfying as well because you will have one core running the normal application that's okay but the sub-core number two in the figure over there will be just able to make DFT controls so basically it's a bit of shame just to use

the processor just to make some DFT controls so let's say the best compromise we can do is to make a dedicated coprocessor just to make the information flow tracking processing so basically the most interesting part of this topic is to have a main core processor aiming to

just to make the normal application and the dedicated coprocessor just to make the IFT controls and you will have some communications between those two cores. So yeah basically if we want to make a quick comparison between different works so if you want to run the dynamic

information for control in pure software I will talk about that just in the in the slide after but this is really really I mean really painful in terms of time already because you will see that the time to do information for tracking in pure software is

really unacceptable and regarding the hardware assisted approach the best advantage in all cases is that we have a lower overhead in terms of silicon era that means that on this slide the the overhead between the main core and the main core plus the coprocessor is not

is not so important and we will see that in the case of my talk we will see that the dedicated the IFT coprocessor is also is also let's say is also easier to to to get some

different security policies so yeah as I said in in the pure software solution so the first line of this table the the basic idea is that is to use instrumentation so if you're there on day two instrumentation is basically the transformation of a program into its own measurement tool so

basically that means that we will put some sensors in all parts of my code just to just to monitor this activity and gather for some information from it so basically if we want to measure the impact of instrumentation on the execution time of an application you can see in

diagram over there the normal application level which is normalized to one and when we want to use instrumentation with it the minimal overhead we will have is about 75 percent so basically it will let's say the time with instrumentation will be most of the time it

will be twice higher than the normal execution time so this is completely unacceptable because it will just run slower your your application so basically yeah as I said the main uh the main

concern about my talk is about reducing the overhead of suffering termination I will talk also a bit about the security of the DFT coprocessor because we can't we can't include a DFT coprocessor without taking care of its security and this is uh accounting to my to my

knowledge this is the first work about DFT in a harm-based system and chips on the on the talk about the security of the nintendo switch the speaker said that black bus texting is that except that it isn't in our case we have we have only a black box because we can't modify the structure of the processor we must

make our job without let's say decapping the person and so on so basically this is another schematic of our architecture so on the left side we've in light green you have

the arm processor so basically in this case this is a simplified version with only one core and on the right side you have the structure of the of the coprocessor we implemented in the fpga so basically you can notice for instance uh for for the moment sorry two things the first

is that you have some links between the fpga and the cpu these links are already pre already existing uh in in the system and chip and you can see another thing is that uh regarding the memory you have separate memory for the uh for the processor and for the fpga

and we will see later that we can use trust zone in vehicle set just to add the layer of security just to be sure that we want we want let's say mix the memory between the cpu and and the fpga so basically we want to work with um uh we have armpus so we must use uh arm data sheets

we must read arm data sheets and first of all don't be afraid by the length of arm data sheets because in my case i used to work with the arm v7 technical manual which is already 2 000 pages the arm v8 manual is about 6 000 pages anyway um and of all of course

what is also difficult is that the information is split between different documents anyway when we want to use the debug components in the case of harm we just have this register over there which

is called dbg blah blah blah so we can see that in this register we can say that okay writing the key value uh 0 c5 a blah blah to this will lock the debug register and if you write any other value it will just unlock those debug registers so that was basically the first step

to um to uh to enable the debug components was just to uh to write a random value to this register to this register just to unlock my my debug components so uh here is again the let's say a schematic of the overall system at ship

so as you can see you you have let's say the trooper and on the top part you have what are called the cross-site components so these are the famous uh debug components i will talk about in the second part of my talk so here is a simplified view of the debug components we have

in uh in zinc socs so basically uh on the left on the left side we have the two processors so the cpu 0 and cpu 1 and all the cross-site components are ptm so the one which is the in the red rectangle and also the ect which is the embedded cross trigger and the

itm which is the instrumentation trace microcell and basically when we want to let's say extract some data from this cross-site components the basic the basic path will be okay we will use the ptm and we will follow the red line go through the funnel and at this

step we'll have two choices to store the information taken from from debug components the first one is the embedded trace buffer which is a small memory embedded in the processor unfortunately this memory is really low because it's really small sorry because it's only about

four kilobytes as far as i remember but the other possibility is just to export some data to trace packet output and this is what we will use just to export some data to the uh to the processor to the corpuscle sorry implementing in the nvfpga so basically what ptm is able to do

the first thing that ptm can do is to trace uh whatever you can whatever you want in your memory for instance you can trace all your code so basically all the blue all the blue sections but you can also um you you can also let's say trace a specific region of the code so basically

that means that you can say okay i just want to trace the code in my section one on say or section two or section n then the ptm is also able to make some branch broadcasting that is something that was not presented during the scanner so we already submitted a patch

that was accepted to uh to uh to manage a branch broadcasting uh into the ptm and we can do some time style time stamping and other things just to be able to to store the information in the traces so basically what the traces what the trace

looks like so here is the most simple code we could had is just a for loop doing nothing so basically the assembly code over there and the trace will look like this so uh in the in the first let's say in the first uh five bytes we'll have uh some some kind of start packets

which is called the async packet just to say okay this is the beginning of the trace uh in the green part we will have uh the address which correspond to the to the beginning of the loop and in the orange part we will have the branch address packet so you can see that you have

10 iterations of this branch address packet because we have 10 iterations of the for loop so this is just to show what is the general structure of of a trace yeah so in other words this is just a control forgot just to say what we could have about

this so of course if we have another loop at the end of this control forgot it will just make the trace a bit longer just to add the information about the about the second loop and so on once we have all these traces the next step is to say okay i have my tags but now

how do i uh let's say define the rules between uh between an institution in nova just to transmit my tags and this is where we will use static analysis for this so basically in this example if we have the instruction okay just do uh help register one plus register two

and put the result in register zero so for this we will use uh static analysis which allows us to say okay the tag uh the tag associated with register zero will be the tag of register one or the tag of uh or register two and a static analysis will be done before running my code just

to say okay i have all the rules needed for all the lines of my code so now that you have the traces we know how to transmit uh the tags all over my code the final step will be just to make the static analysis in via in vlvm back end and the final step will be about instrumentation

so as i said before we can uh we can recover all the memory addresses we need through instrumentation otherwise we can also uh in the in the second possibility we can also only uh let's say get the register relative memory addresses for instrumentation

in the first case on this simple code we we can basically just just say okay we instrument all the code but the main uh the main drawback of this solution is that okay we it will completely uh it will completely access the the time of the exception otherwise what we can do

is that okay uh we've uh with the restore section over there we can get uh data from the trace so basically we will use the program counter address from the trace and then for the stack pointer we will use the static analysis to get information from the stack pointer and finally we can use only one instrumented instruction at the end

so if i go back to this uh to this system yeah the communication overhead will be uh the main uh let's say the main drawback uh as i said before because okay uh if we have over there the processor and the fpga are running

in in uh in different parts the main let's say problem will be how we can transmit data in real time or at most at least in uh in in the isp we can between the processor and the fpga

so yeah uh the ptm uh so this is the let's say the time of red when we enable across our components or not so basically in blue we have uh the the time of red let's say the basic time of red when the traces are disabled and we can see that when when we enable traces uh the time of red is nearly uh is nearly negligible

yeah regarding time instrumentation we can see that regarding the strategy two which is uh you are using the cosine components using the static analysis and the instrumentation we can lower the instrumentation overhead from 53 percent up down to five percent so this is basically

okay we still have some uh overhead due to instrumentation but it's really low compared to the related rocks where all the code was uh instrumented and this is an overview that

show us that in the graylands you have some uh some overheads of related rocks with full instrumentation and we can see that in our approach with the green uh the green lines over there that the overhead the time already with with our code is much much smaller sorry

so yeah so basically uh how we can use uh how chosen is this so this is just an overview of our system and we can say okay we can use frozen just to separate the cpu from the from the fpga capacitor so if we make a comparison between with related rocks

we can see that compared to the first works we are able to make some information for control with a hard compressor which is which was not the case with uh with the two first trucks uh in this table so it means that okay you can use a basic compass just to make the information

for tracking instead of having a specific processor and of course uh yet the area of it which is another important topic is much much slower compared to the extending worse so it's time for the conclusion so yeah as i presented in this talk we are able to use the

component just to obtain runtime information about my application this is a non-intrusive tracing because we still have a negligible performance of red and we also improve the software security just because we were able to make some security on the corpus so the future perspective about

that is to mainly to work with a multi-core processor and to see if we can use the same approach for intel and maybe st micro controls to see if we can also do information flow tracking in this case so that was basically for my toast thanks for listening thank you very much for this

talk unfortunately we don't have time for q and a so um please if you leave the room

take your trash with you and make the angels happy i was a bit long yeah huh i was a bit long my dog and another round of applause for pascal