All right. Good morning, confidential computing. I'm going to talk about memory isolation and
Texas instruments, microcontrollers. And I imagine that at this point the audience is kind
of divided and half, where half of you are thinking, wait, there's confidential computing
and Texas instruments. And the other half is thinking, why would you need confidential computing
for a calculator? But as it turns out, Texas instruments is more than just a calculator
company. They actually have a very rich history as kind of a computing company. So they
were the first ones, the first company, to manufacture a silicon transistor. And four
years later, they were also the inventors of the integrated circuit. And so they not only
produce calculators, but also other systems, where sometimes I think maybe having some kind
of security for this type of stuff is not the worst idea in the world. So I don't know if
you see it from the back, but they also develop laser guidance systems for precision guided
munitions. So ballistic missiles. So let's talk about what type of security they have. I'm not
going to go too deep into the details, but it's kind of different than this kind of confidential
VM infrastructure that we've seen in the previous stocks as well. So I will explain it a little
bit. This is what we saw in the previous stocks. So this is kind of the traditional high
ends desktop or server environment, where you have actually many different ways of isolating
code and data. You can have processes that are running in parallel. You can have in-process
enclaves. You can have confidential VMs. And all of these rely on the hardware to provide
some kind of isolation between these different entities within the computer. And this
is implemented through things like virtual memory, virtualization, privilege, and so on.
But in this case, the device that I'm going to talk about is this MSP430 macro controller.
And this has none of this. This is, it's actually a long line of macro controllers,
but the specific device that I'm going to talk about was released in 2014. At the time when
it was released, I think it was actually the lowest power, lowest power macro controller
in the entire world. But it still has some security features. As an example, it has AX
acceleration. It has a memory protection unit. And it also has this intellectual property
encapsulation feature that I'm going to focus on in this talk. IP for short. And so the
way this works is that you don't have virtual memory. You don't have virtualization any of
these things on this device. It's a flat unified address space. All the code and data on the
device shares this one physical address range. And what IP allows you to do is you can write
two addresses, the two registers. And this will mark one area of memory that is going to be
the protected area. And you can put code and data in here. It's a font normal architecture. So
it's mixed code and data. So here you can put your intellectual properties such as proprietary
code or secret data such as encryption keys or nuclear launch codes, whatever you use this
device for. And then what IP actually enforces is that if you run code from inside this
enclave, you can access and manipulate the data. That's also inside. But if you have code running
anywhere outside this address range, then it basically cannot access anything inside the enclave.
And this is not only enforced for code, but also for JTAG the buggers and direct memory access.
So it's kind of a program counter based access control. So in certain ways it's a bit similar
to intellectual GX or other similar DEs. But how secure is it? So now I kind of explained how
it's supposed to work. But we performed an MDAP security analysis into this device. And we found
that unfortunately it doesn't work that well. Again I'm not going to go into the details.
Basically what we did is we looked at a lot of prior literature in trying to attack
confidential computing architectures. And we tried to recreate some of these attacks, see which
ones apply, see which ones are successful on this device. And all the ones that are highlighted.
So almost all of the rows in the table, we could recreate on this device. So we could
both architectural and micro architectural side channel attacks successfully executed on this device.
And the security guarantees are basically completely broken as a result.
And important to note that these are all software based attacks. So even if you don't necessarily
have physical access to the device, it might still be possible to take over if you have some
way of injecting code into the device. And actually so I said that we tried to recreate
existing attacks. But that's not the entirety of what we did because this very first line in the
row, the very first row in the table controlled call corruption. It's a completely novel attack
that we discovered on this device. And again I will not go into the details. You can talk
to me later if you're interested in how this actually works. But very shortly it allows you to
corrupt memory anywhere inside this IP region and you can kind of force it to leak its full
contents. And this is something that's TI also released an advisory about. They gave it a CVS
score of high. So they also seem to agree that it's pretty important. And then probably the
natural question that you're asking is, can we mitigate against these attacks? Can we do anything
to kind of restore the security on these devices? And while it turns out if you give researchers
enough coffee anything is possible, it's not very nice but it works. So here again the details are
not important. But we manage to repurpose one of these other security features, the memory protection
unit, to kind of provide some of the security guarantees that IP is supposed to provide but fails.
And yeah with the edit complexity of more software having to trust more software and also
reducing the applicable attacker model a little bit because we cannot defend against attackers
that have control over the debugger. In this case we can still protect the code and the data in the
IP region in most scenarios. So everything that I talked about so far, the attacks, this mitigation
framework and the academic paper that we wrote about this with all the details, you can find
a death QR code. But I have to disappoint you, this is not the end of the target.
Because after we were done with this research we were wondering what could we do if we could
actually change the hardware because most of these bugs, well most of these vulnerabilities
stem from bugs that could be fixed in hardware. But yeah how would we do that?
This MSP430 is used a bit in research but because the hardware is obviously close source,
there is no design files or anything available for these devices. It's kind of hard to prototype
any kind of changes to it. There's no simulator that you can run so even to just run the
exploits you need to have the physical device. But already in 2009 a new software was released called
Open MSP430 which is a simple very low design that implements the same MSP430 architecture
and it's relatively easy to work with and you can see that there's a lot of research publications
that also extended this Open MSP430 core and actually all of these added some kind of memory
isolation feature to it. So clearly there's a need for this and there's some interest in this topic
but it's still very scattered and all of them are kind of random independent implementations
of this memory isolation. So then what we came up with is we took the base Open MSP430 core
and we implemented the IP specification on it. We tried to make it as binary compatible as
possible so that you can run existing programs that were meant to run on the TI market controller
on this framework and we also added one interesting new feature which is this firmware here.
So already on the TI devices there's some small protected boot code that runs that actually
sets up the protection whenever you boot up the device but this is not visible it's not
modifiable on the TI devices but on our implementation we wanted to make this open so that researchers
can actually change this and maybe extend it to implement additional security features mostly by
just changing this small layer of trusted code instead of having to make changes to the core itself
but we also implemented all the hardware fixes that we thought would be relevant for mitigating
the vulnerabilities that we found in the original design. At this point I should ask the
Devroom organizers for the scheduling that they make because now I can talk about Open IP which
is an open and extensible framework for a security research on Texas Instruments IP and this makes
a sound like a very original idea that no one else could possibly have so stick around for the next
stock if you're interested in something very similar but on CCA so a much broader and much bigger
project but okay so about Open IP to test out how this firmware actually works and how it can be
extended for additional security features we also perform the small case study where we again without
going into the details we mitigated some of the architectural and side channel attacks that we discovered
in the original TI boards so there is a tag that can extract secrets from enclaves by measuring
how long inter up stake and this is something that we can mitigate by changing how interrupts
our handled and how the software actually does the context switching between trusted and untrusted code.
Another important aspect if you implement something is to write tests and make sure that
everything works correctly and securely so we did two things regarding this. First of all we wrote
a lot of small unit tests that check whether the functionality works correctly so whether the
IP specification is implemented correctly and also whether the security is better than on the original
board so we wrote a lot of scenarios that's tried to replicate attacks from the original device
and see that it doesn't work anymore on our implementation and then we also care about the security
of the software these tests are more about the hardware working properly but there's also been
quite some research on how you can ensure that software that is running inside an enclave is
properly secured and what we use here is symbolic execution which uses mathematics to
check all the possible paths that your program can take and simulate those executions and see whether
anything potentially dangerous is happening and one of the tools for symbolic execution is anger
and we actually use a framework that's built on top of anger it's called Pandora it was made by
one of the previous organizers of this bedroom and it was originally made for intellectual GX where
it can detect vulnerabilities that are specific to enclaves or to GX in particular and we adapted this to
be so that it can consume these IP binaries or even our firmware code that we can potentially
extend for security features and then check whether everything is protected correctly and this
tool if it detects any kind of potential violations it gives these nice visual reports where you can
look at there's a suspicious instruction there that can potentially leak your entire memory so
maybe you should make sure that this is working as intended all right so what are our goals with
open IP well obviously I already showed before that this seems to be an area of research that
is still active and there is some interest in this kind of memory isolation and in small embedded
microbandrollers so we hope that our platform can be used as a basis for that type of research and
maybe you kind of unify these efforts a little bit and also contribute with things like
thorough testing because we saw that some of the research prototypes in the past were maybe not
that well tested but it's actually also a great tool for teaching because the implementation
is relatively simple it's around the thousand lines of very low code but it can already introduce
students to a lot of different concepts so already during the presentation I talked about
memory isolation hardware vulnerabilities architectural micro architecture attacks symbolic
execution there's a lot of areas that you can kind of easily or excessively discover using this framework
so we are already using this in multiple thesis projects and we're hoping to to keep using this
in the future and this is actually my last slide here you can find the code for so this is for all the
Texas Instruments related codes the attacks and the mitigation framework and this is the open IP
implementation and tests and you can also find the links there at the bottom and I would encourage you
that if you're doing research in this area or if you have any students or interns or whoever could
possibly make use of a nice little onboarding project into enclaves I think it's a good starting point
and you can also find my website at the bottom so feel free to reach out if you have any questions or
or want to ask for help about any of this thanks any questions yeah
so one of the core features of confidential computing is the extension part so you can see that
if there's an empty-time mission to look for why we've got permission to do it by itself
yeah what would be the worst-time mission part in it so the question was whether there's any
attestation support because it's an important part of confidential computing so indeed the
initial the original TIP does not have anything to do with attestation they I think don't even
talk about it in the documentation but it doesn't make sense because they're not leaving
it to be confidential so you are leaving it to the confidential so that's my question to your
part rather than to text us assuming well they claim that it's a feature that can be used for
protecting code and data so that covers the confidentiality part I would say but I agree with you
that attestation is also important and we haven't really looked into it yet but we hope that by
using this extensible firmware layer that we added we could add some software based attestation
that can be triggered and then used as a similar primitive as attestation on higher and
confidential computing architectures
from looking for safe you're doing it x software rather than at the hardware layer so how does it match
with the x-ray this is the definition that was presented hardware based attestation or hardware based
confidentiality and it's a good guarantee I guess it depends on how you define hardware based
so it still relies on some of the guarantees of the hardware that makes it such that you cannot
temper with the attestation so that's provided by the confidentiality of the and the integrity of
the firmware code for example and then relying on that you can add attestation that is computed
in software but I think that still would function the same way but maybe we can discuss it further
yeah so the question is which boards are affected basically so we there's one specific family of
these MSP430 markment rollers that have a specific type of memory this f-ram and these are the devices
that support this IP technology so I don't have complete numbers for how many devices this is specifically
we tested three different CPUs that are in this family and they were all affected so I
imagine that all of them are probably very similar to each other and maybe most of the
different terms of peripherals or something and I would guess that they are all affected actually
I can go back maybe it's a good indication if we check what TI said so in their security bulletin
they also say the bottom I don't know if you can see it from there the affected products
and they list all yeah the whole family of these devices so they probably also think that
all of them are affected so we there are most of yeah whether open IP is starting a
specific board or a specific type of hardware so most of it I think is very generic in the sense
that the specification of IP is is pretty device independent but there are some device specific
specifications so for example where exactly the registers are in memory that you have to
write to so in this case we took one specific board and just use those but it's something that could
be easily changed as well