This subtitle is not finished yet. If you are able to, please support us and watch the talk in amara for the last changes: https://c3subtitles.de/talk/1583 Thanks!
*rc3 preroll music*
Herald: So for the next talk, I have Jo Van Bulck, and Fritz Alder from the
University of Leuven in Belgium, and David Oswald professor for cyber security in
Birmingham. They are here to talk about the trusted execution environment. You
probably know from Intel and so on, and you should probably not trust it all the
way because it's software and it has its flaws. And so they're talking about
ramming enclave gates, which is always good, a systematic vulnerability
assessment of TEE shielding runtimes. Please go on with your talk.
Jo van Bulck: Hi, everyone. Welcome to our talk. So I'm Jo, former imec-DistriNet
research group at KU Leuven. And today joining me are Fritz, also from
Leuven and David from the University of Birmingham. And we have this very exciting
topic to talk about, ramming enclave gates. But before we dive into that, I
think most of you will not know what are enclave's, let alone what are these TEEs.
So let me first start with some analogy. So enclave's are essentially a sort of a
secure fortress in the processor, in the CPU. And so it's an encrypted memory
region that is exclusively accessible from the inside. And what we know from the last
history of fortress attacks and defenses, of course, is that when you cannot take a
fortress because the walls are high and strong, you typically aim for the gates,
right? That's the weakest point in any in any fortress defense. And that's exactly
the idea of this research. So it turns out to apply to enclave's as well. And we have
been ramming the enclave gates. We have been attacking the input/output interface
of the enclave. So a very simple idea, but very drastic consequences I dare to say.
So this is sort of the summary of our research. With over 40 interface
sanitization vulnerabilities that we found in over 8 widely used open source enclave
projects. So we will go a bit into detail over that in the rest of the slides. Also,
a nice thing to say here is that this resulted in two academic papers to date,
over 7 CVEs and altogether quite some responsible disclosure, lengthy embargo
periods. David Oswald: OK, so, uh, I guess we
should talk about why we need such enclave fortresses anyway. So if you look at a
traditional kind of like operating system or computer architecture, you have a very
large trusted computing base. So you, for instance, on the laptop that you most
likely use to watch this talk, you trust the kernel, you trust maybe a
hypervisor if you have and the whole hardware under the systems: a CPU,
memory, maybe hard drive, a trusted platform module and the like. So actually
the problem is here with such a large TCB, trusted computing base, you can also have
vulnerabilities basically everywhere. And also malware hiding in all these parts. So
the idea of this enclaved execution is as we find, for instance, in Intel SGX, which
is built into most recent Intel processors, is that you take most of the
software stack between an actual application, here the enclave app and the
actual CPU out of the TCB. So now you only trust really the CPU and of course, you
trust your own code, but you don't have to trust the OS anymore. And SGX, for
instance, promises to protect against an attacker who has achieved root in the
operating system. And even depending on who you ask against, for instance, a
malicious cloud provider. So imagine you run your application on the cloud and then
you can still run your code in a trusted way with hardware level isolation. And you
have attestation and so on. And you don't no longer really have to trust even the
administrator. So the problem is, of course, that attack surface remains, so
previous attacks and some of them, I think will also be presented at this remote
Congress this year, have targeted vulnerabilities in the microarchitecture
of the CPU. So you are hacking basically the hardware level. So you had foreshadow,
you had microarchitectural data sampling, spectre and LVI and the like. But what
less attention has been paid to and what we'll talk about more in this presentation
is the software level inside the enclave, which I hinted at, that there is some
software that you trust. But now we'll look in more detail into what actually is
in such an enclave. Now from the software side. So can an attacker exploit
any classical software vulnerabilities in the enclave?
Jo: Yes David, that's quite an interesting approach, right? Let's aim for the
software. So we have to understand what is the software landscape out there for these
SGX enclaves and TEEs in general. So that's what we did. We started with an
analysis and you see some screenshots here. This is actually a growing open
source ecosystem. Many, many of these runtimes, library operating systems, SDKs.
And before we dive into the details, I want to stand still with what is the
common factor that all of them share, right? What is kind of the idea of these
enclave development environments? So here, what any TEE, trusted execution
environment gives you is this notion of a secure enclave oasis in a hostile
environment. And you can do secure computations in the green box while the
outside world is burning. As with any defense mechanism, as I said earlier, the
devil is in the details and typically at the gate, right? So how do you mediate
between that untrusted world where the desert is on fire, and the secure oasis in
the enclave? And the intuition here is that you need some sort of intermediary
software layer, what we call a shielding runtime. So it kind of makes a secure
bridge to go from the untrusted world to the enclave and back. And that's what we
are interested in. To see, what kind of security checks you need to do there. So
it's quite a beautiful picture you have on the right, the fertile enclave and on the
left the hostile desert. And we make this secure bridge in between. And what we are
interested in is what if it goes wrong? What if your bridge itself is flawed? So
to answer that question, we look at that yellow box and we ask what kind of
sanitization, what kind of security checks do you need to apply when you go from the
outside to the inside and back from the inside to the outside. And one of the key
contributions that we have built up in the past two years of this research, I think,
is that that yellow box can be subdivided into 2 smaller subsequent layers. And the
first one is this ABI, application binary interface, very low level CPU state. And
the second one is what we call API, application programing interface. So
that's the kind of state that is already visible at the programing language. In the
remainder of the presentation, we will kind of guide you through some relevant
vulnerabilities on both these layers to give you an understanding of what this
means. So first, Fritz will guide you to the exciting low level landscape of the
ABI. Fritz: Yeah, exactly. And Jo, you just
said it's the CPU state and it's the application binary interface. But let's
take a look at what this means, actually. So it means basically that the attacker
controls the CPU register contents and that... On every enclave entry and every
enclave exit, we need to perform some tasks. So that's the enclave and the
trusted runtime have some like, well initialized CPU state and the compiler can
work with the calling conventions that it expects. So these are basically the key
part. We need to initialize the CPU registers when entering the enclave and
scrubbing them when we exiting the enclave. So we can't just assume anything
that the attacker gives us as a given. We have to initialize it to something proper.
And we looked at multiple TEE runtimes and multiple TEEs and we found a lot of
vulnerabilities in this ABI layer. And one key insight of this analysis is basically
that a lot of these vulnerabilities happen on complex instruction set processors, so
on CISC processors and basically on the Intel SGX TEE. We also looked at some RISC
processors and of course, it's not representative, but it's like immediately
visible that the complex x86 ABI seems to be... have a way higher, larger attack
surface than the simpler RISC designs. So let's take a look at one example of this
more complex design. So, for example, there's the x86 string instructions that
are controlled by the direction flag. So there's a special x86 rep instruction that
basically allows you to perform streamed memory operations. So if you do a memset
on a buffer, this will be compiled to the rep string operation instruction. And the
idea here is basically that the buffer is read from left to right and written over
it by memset. But this direction flag also allows you to go through it from right to
left. So backwards. Let's not think about why this was a good idea or why this is
needed. But definitely it is possible to just set the direction flag to one and run
this buffer backwards. And what we found out is that the System-V ABI actually says
that this must be clear or set to forward on function entry and return.
And that compilers expect this to happen. So let's take a look at this when we do
this in our enclave. So in our enclave, when we, in our trusted application,
perform this memset on our buffer, on normal entry with the normal direction
flag this just means that we walk this buffer from front to back. So you can see
here it just runs correctly from front to back. But now, if the attacker enters the
enclave with the direction flag set to 1 so set to run backwards, this now means
that from the start of our buffer. So from where the pointer points right now, you
can now see it actually runs backwards. So that's a problem. And that's definitely
something that we don't want in our trusted applications because, well, as you
can think, it allows you to overwrite keys that are in the memory location that you
can go backwards. It allows you to read out things, that's definitely not
something that is useful. And when we reported this, this actually got a nice
CVE assigned with the base score High, as you can see here on the next slide. And
while you may say, OK, well, that's one instance. And you just have to think of
all the flags to sanitize and all the flags to check. But wait, of course,
there's always more, right? So as we found out, there's actually the floating point
unit, which comes with a like, whole lot of other registers and a whole lot of
other things to exploit. And I will spare you all the details. But just for this
presentation, just know that there is an older x87 FPU and a new SSE that does
vector floating point operations. So there's the FPU control word and the MXCSR
register for these newer instructions. And this x87 FPU is older, but it's still used
for example, for extended precision, like long double variables. So old and new
doesn't really apply here because both are still relevant. And that's kind of the
thing with x86 and x87 here. That old archaic things that you could say are
outdated, are still relevant or are still used nowadays. And again, if you look at
the System-V ABI now, we saw that these control bits are callee-saved. So they are
preserved across function calls. And the idea here is which to some degree holds
merit, is that these are some global states that you can set and they are all
transferred within one application. So one application can set some global state and
keep the state across all its usage. But the problem here as you can see here is
our application or enclave is basically one application, and we don't want our
attacker to have control over the global state within our trusted application,
right? So what happens if FPU settings are preserved across calls? Well, on a normal,
for a normal user, let's say we just do some calculation inside the enclave. Like
2.1 times 3.4, which just nicely calculates to a 7.14, a long double.
That's nice, right? But what happens if the attacker now enters the enclave with
some corrupt precision and rounding modes for the FPU? Well, then we actually get
another result. So we get distorted results with a lower precision and a
different rounding mode. So actually it's rounding down here, whenever it exceeds
the precision. And this is something we don't want, right? So this is something
where the developer expects a certain precision or long double precision, but
the attacker could actually just reduce it to a very short position. And we reported
this and we actually found this issue also in Microsoft OpenEnclave. That's why it's
marked as not exploitable here. But what we found interesting is that the Intel SGX
SDK, which was vulnerable, patched this with some xrstore instruction, which
completely restores the extended state to a known value, while OpenEnclave only
restored the specific register that was affected, the ldmxcsr instruction. And
so let's just skip over the next few slides here, because I just want to give
you the idea that this was not enough. So we found out that even if you restored
this specific register, there's still another data register that you can just
mark as in use before entering the enclave and with which the attacker can make that
any floating point calculation results in a not a number. And this is silent, so
this is not programing language specific, this is not developer specific. This is a
silent ABI issue that the calculations are just not a number. So we also reported
this. And now, thankfully, all enclave runtimes use this full xrstor instruction
to fully restore this extended state. So it took two CVEs, but now luckily, they
all perform this nice full restore. So I don't want to go to the full details of
our use cases now or of our case studies that we did now. So let me just give you
the ideas of these case studies. So we looked at these issues and wanted to look
into whether they just feel difficult or whether they are bad. And we found that we
can use overflows as a side channel to deduce secrets. So, for example, the
attacker could use this register to unmask exceptions, that inside the
enclave are then triggered by some input dependent multiplication. And we found out
that these side channels if you have some input dependent multiplication can
actually be used in the enclave to perform a binary search on this input space. And
we can actually retrieve this multiplication secret with a deterministic
number of steps. So even though we just have a single mask we flip, we can
actually retrieve a secret with deterministic steps. And just for the, just
so that you know, there's more you can do. We can also do machine learning in the
enclave. So Jo said it nicely, you can run it inside the TEE, inside the cloud. And
that's great for machine learning, right? So let's do a handwritten digit
recognition. And if you look at just the model that we look at, we just have two
users where one user pushes some machine learning model and the other user
pushes some input and everything is protected with enclaves, right?
Everything is secure. But we actually found out that we can poison these FPU
registers and degrade the performance of this machine learning down from all digits
were predicted correctly to just eight percent of digits were correctly. And
actually all digits were just predicting the same number. And this basically made
this machine learning model useless, right? There's more we did so we can also
attack blender with image differences, slight image differences between blender
images. But this is just for you to see that it's small, but it's a tricky thing
and indicate that that can go wrong very fast on the ABI level once you play around
with it. So this is about the CPU state. And now we will talk more about the
application programing interface that I think more of you will be comfortable
with. David: Yeah, we take, uh, thank you,
Fritz. We take a quite simple example. So let's assume that we actually load a
standard Unix binary into such an enclave, and there are frameworks that can do that,
such as graphene or so. And what I want to illustrate with that example is that it's
actually very important to check where pointers come from. Because the enclave
kind of partitions memory into untrusted memory and enclave memory and they live in
a shared address space. So the problem here is as follows. Let's assume we have
an echo binary that just prints an input. And we give it as an argument a string and
that normally, when everything is fine, points to some string, let's say hello
world, which is located in the untrusted memory. So if everything runs as it
should, this enclave will run, will get the pointer to untrusted memory and will
just print that string. But the problem is now actually the enclave has access also
to its own trusted memory. So if you don't check this pointer and the attacker passes
a pointed to the secret that might live in enclave memory, what will happen? Well the
enclave will fetch it from there and will just print it. So suddenly you have turned
this kind of like into a like a memory disclosure vulnerability. And we can see
that in action here for the framework named graphene that I mentioned. So we
have a very simple hello world binary and we run it with a couple of command line
arguments. And now on the untrusted side, we actually change a memory address to
point into enclave memory. And as you can see, normally, it should print here test,
but actually it prints a super secret enclave string that lived inside
the memory space of the enclave. So these kind of vulnerabilities are quite
well known from user to kernel research and from other instances. And they're
called confused deputy. So the deputy kind of like has a gun now can read and if
memory and suddenly then does something which is not not supposed to do because he
didn't really didn't really check where the memory should belong or not. So I
think this vulnerability, uh, seems seems to be quite trivial to solve. You simply
check all the time where, uh, where pointers come from. But as you will tell,
you know, it's often not quite quite that easy. Yes. David, that's quite insightful
that we should check all of the pointers. So that's what we did. We checked all of
the pointer checks and we noticed that Endo has a very interesting kind of all
the way to check these things. Of course, the code is high quality. They checked all
of the pointers, but you have to do something special for things. We're
talking here, the C programing language. So things are no terminated, terminated.
They end with a new byte and you can use a function as they are struggling to compute
the length of this thing. And let's see how they check whether thing that's
completely outside of memory. So the first step is you compute the length of the
interest, it's ten, and then you check whether the string from start to end lives
completely outside of the anchor. That sounds so legitimate. Then you eject the
steam. So so this works beautifully. Let's see, however, how it behaves when we when
we partnered. And so we are not going to parse this thing has a world outside of
the enclave that we pass on string secret, one that lies within the. So the first
step will be that the conclave starts computing the length of that string that
lies within the anklet. That sounds already fishy, but then luckily everything
comes OK because then it will detect that this actually should never have been done
and that this thing lies inside the enclave. So it will reject the call so
that the call into the anklet. So that's fine. But but some of you who know such
channels know that this is exciting because the English did some competition
it was never supposed to do. And the length of that competition depends on the
amount of of non-zero bites within the anklet. So what we have here is a side
channel where the English will always return false. But the time it takes to
return false depends on the amount of of zero bytes inside that secret Arncliffe
memory block. So that's what we found. We are excited and we said, OK, it's simple
timing channel. Let's go with that. So we did that and you can see a graph here and
it turns out it's not as easy as it seems. So I can tell you that the blue one is for
a string of length one, and that one is for a string of like two. But there is no
way you can see that from that graph because it said six processors are
lightning fast so that one single incrementing section is completely
dissolves into the pipeline. You will not see that by by measuring execution time.
So we need something different. And what we have smart papers and in literature,
one of the very common attacks in ASICs is also something that Intel describes here.
You can see which memory pages for memory blocks are being accessed while the
English executes because you control the operating system and the paging machinery.
So that's what we tried to do. We thought this is a nice channel and we were there
scratching our heads, looking at that code of very simple for loop that fits entirely
within one page and a very short string that fits entirely within one page. So
just having access to for a memory, it's not going to help us here because because
votes the code and the data fit on a single page. So this is essentially what
we call the temporal resolution of the sideshow. This is not accurate enough. So
we need a lot of take. And well, here we have been working on quite an exciting
framework. It uses indirects and it's called as a big step. So it's a completely
open source framework on Hadoop. And what it allows you to do essentially is to
execute an enclave one step at a time, hence the name. So it allows you to
interleave the execution of the enclave with attacker code after every single
instruction. And the way we pull it off is highly technical. We have this Linux
kernel drive around a little library operating system in userspace, but that's
a bit out of scope. The matter is that we can interrupt an enclave after every
single restriction and then let's see what we can do with that. So. What we
essentially can do here is to execute and follow up with all this extra increment
instructions one of the time, and after every interrupt, we can simply check
whether the enclave accessed the string residing of our target. That's another way
to think about it, is that we have that execution of the enclave and we can break
that up into individual steps and then just count the steps and hands and hands.
A deterministic timing. So in other words, we have an oracle that tells you where all
zero bytes are in the anklet. I don't know if that's useful, actually do so. It turns
out that this I mean, some people who might be born into exploitation already
know that it's good to know whether zero is somewhere in memory or not. And we do
now do one example where we break A-S and Iowa, which is the hardware acceleration
of enterprises process for AI. So finally, that actually operates only on registers.
And you just said you can kind of like do that on onepoint us on memory, but says
another trick that comes into play here. So whenever the enclave is interrupted, it
will store its current registers, date somewhere to memory Quazi as a frame so we
can actually interrupt it and clarify make it right. It's memory to to it's it's
register sorry to to say memory. And then we can run the zero byte oracle on this
SSA a memory. And what we figure out is where zero is or if there's any zero in
the state. So I don't want to go into the gory details of a yes. But what we
basically do is we find whenever there's a zero in the last in the state before the
last round of ads and then that zero will go down to the box will be X or to a key
byte, and then that will give us a cipher text. But we actually know the ciphertext
byte so we can go backwards. So we can kind of compute, uh, we can compute from
zero up to here and from here to this X1. And that way we can compute directly one
key byte. So we repeat that whole thing 16 times until we have found a zero in every
bite of this state before the last round. And that way we get the whole final round
key. And for those that know as if you have one round key, you have the whole key
in it. So you get like the original key, you can go backwards. So sounds
complicated, but it's actually a very fast attack when you see it running. So here is
a except doing this attack and as you can see, was in a couple of seconds and maybe
five hundred twenty invocations of of Asir, we get the full KeIso. That's
actually quite impressive, especially because the whole uh. Yeah, one of the
points in essence is that you don't put anything in memory, but this is
interaction with SGX, which is kind of like allows you to put stuff into into
memory. So I want to wrap up here. Um, we have found various other attacks. Yeah.
So, um, both in research code and in production code, such as the Intel SDK and
the Microsoft SDK. And they basically go across the whole range of foreign
abilities that we have often seen already from use it to kind of research. But there
are also some, uh, some interesting new new kind of like vulnerabilities due to
some of the aspects we explained. There was also a problem with all call centers
when the enclave calls into untrust, the codes that is used when you want to, for
instance, emulate system calls and so on. And if you return some kind of like a
wrong result here, you could again go out of out of bounds. And they were actually
quite, quite widespread. And then finally, we also found some issues with padding,
with leakage in the padding. I don't want to go into details. I think we have, uh,
learned a lesson here that that we also know from from the real world. And that is
it's important to wash your hands. So it's also important to sanitize and state to
check pointers and so on. No. So that is kind of one one of the take away message
is really that to build and connect securely, yes, you need to fix all the
hardware issues, but you also need to write safe code. And for enclave's, that
means you have to do a proper API and APIs sanitization. And that's quite a difficult
task actually, as as we've seen, I think in that presentation, there's quite a
large attack surface due to the attack model, especially of intellectual X, where
you can interrupt after every instruction and so on. And I think for from a research
perspective, there's really a need for a more. Approach, then just continue if you
want, maybe we can learn something from from the user to analogy which which I
invoked, I think a couple of times so we can learn kind of like how what an enclave
should do, uh, from from what we know about what a colonel should do. But they
are quite important differences also that need to be taken account. So I think, as
you said, all all our code is is open source. So you can find that on the below
GitHub links and you can, of course, ask also questions after you have watched this
talk. So thank you very much. Hello, so back again. Here are the questions. Hello
to see your life. Um, we have no questions yet, so you can put up questions in the
see below if you have questions. And on the other hand. Oh, let me make close this
up so I'll ask you some questions. How did you come about this topic and how did you
meet? Uh, well, that's actually interesting. I think this such as has been
building up over the years. Um, and it's so, so, so I think some some of the
vulnerabilities from our initial paper, I actually started in my master's thesis to
sort of see and collect and we didn't really see the big picture until I think I
met David and his colleagues from Birmingham at an event in London, the nice
conference. And then we we started to collaborate on this and we went to look at
this a bit more systematic. So I started with this whole list of vulnerabilities
and then with with David, we kind of made it into a more systematic analysis. And
and that was sort of a Pandora's box. I dare to say from the moment on this, this
kind of same errors being repeated. And then also Fitzhugh, who recently joined
our team in London, started working together with us on one or more of these
low level Sebu estate. And that's the Pandora's box in itself. I would say,
especially one of the lessons, as we said, that particular six is extremely complex.
And it turns out that almost all of that complexity, I would say, can be abused,
potentially biodiversity. So it's more like a fractal in a fraction of a fractal
where you're opening a box and you're getting more and more of questions out of
that. In a way, I think. Yes, I think it's fair to say this this research is not the
final answer to to this, but it's an attempt to to give a systematic way of
looking at probably never ending up actually funding is. So there is a
question from the Internet. So are there any other circumstances where he has
Mianus and he is writing its registers into memory, or is this executed exclusive
to SGX? So I repeat, I do not understand the question either, so, so well, I think
the question is that this is a tactical defeat. Prison depends on, of course,
having a memory disclosure about the content and people that are accusing us
except to kind of forcibly right the memory content of the content into memory.
So that is definitely a specific um. However, I would say one of the the
lessons from the past five years of research is that often these things
generalize beyond the six and at least the general concept of, let's say, the
insights that sebu, that justice end up in memory one way or another sooner or later.
I think that also applies to creating systems that if you somehow can force an
operating system to complex, which pertain to applications, that you also have to
register temporarily in memory. So if you would have something similar like what we
have in an operating system, Colonel, you would potentially mount a similar attack.
But maybe David wants to say something about operating systems there as well. No,
no, not really. I think, like one one thing that helps with SGX is that you have
very precise control, as you explained, which was the interrupts and stuff because
you were your route outside the outside the enclave. So you can signal step
essentially the whole enclave where it's like, um, interrupting the operating
system. Exactly repeatedly at exactly the point you want or some other process also
tends to be probably probably harder just by design. But of course, on a context
which keep us to save somewhere, it's register set and then then it will end up
in memoria in some situations probably not not as controlled as it is for for as
Asgeirsson. So there is the question, what about other CPU architectures other than
Intel, did you test those? So maybe I can I can go into this so. Well, interesting.
See, that's the largest one with the largest software base and the most runtime
that is also that we could look at. Right. But there, of course, some other stuff we
have or as this eternity that we developed some years ago, it's called Sancho's. And
of course, for this, there are similar issues. Right. So you always need the
software layer to interact, to enter the enclave into the enclave. And I think you
had David in the earlier work, also found issues in our TI. So it's not just Intel
and really related product projects that mess up there, of course. But what we
definitely found is it's easier to to think of all cases for simpler designs
like risk five or simpler risk designs then for this complex actually six
architecture. Right. So right now there are not that many sites into less Jicks.
So so they have the advantage and disadvantage of being the first widely
deployed, let's say. And um, but I think as soon as others start to, to grow out
and simpler designs start to be more common, I think we will see this, that
it's easier to fix alleged cases for simpler designs. OK, so what is a
reasonable alternative to tea, or is there any way you want to take that or think,
should I say what? Uh, well, we can probably both give our perspectives. So I
think. Well, the question to start statute, of course, is do we need an
alternative or do we need to find more systematic ways to to to sanitize
Australians? That's, I think, one part of the answer here, that we don't have to
necessarily throw away these because we have problems with them. We can also look
at how to solve those problems. But apart from that, there is some exciting
research. OK, maybe David also wants to say a bit more about, for instance, on
capabilities, but that's not in a way not so different than these necessarily. But
but when you have high tech support for capabilities like like the Cherry
Borjesson computer, which essentially associates metadata to a point of
metadata, like commission checks, then you could at least for some cause of the
issues we talked about point to point of poisoning attacks, you could natively
catch those without support. But but it's a very high level idea. Maybe David wants
to say something. Yeah. So so I think, like alternative to tea is whenever you
want to partition your system into into parts, which is, I think, a good idea. And
everybody is now doing that also in there, how we build online services and stuff so
that these are one systems that we have become quite used to from from mobile
phones or from maybe even even from something like a banking card or so out,
which is sort of like a protected environment for a very simple job. But the
problem then starts when you throw a lot of functionality into the tea. As we saw,
the trusted code base becomes more and more complex and you get traditional box.
So I'm saying like, yeah, it's really a question if you need an alternative or a
better way of approaching it. How are you partition software? And as you mentioned,
there are some other things you can do architecturally so you can change the way
we or extends the way we build build architectures for with capabilities and
then start to isolate components. For instance, in one software project, say it,
say in your Web server, you isolate the stack or something like this. And also,
thanks for the people noticing the secret password here. You so obviously only for
decoration purposes to give the people something to watch. So but it's not
fundamentally broken, isn't? Yeah, not 60. I mean, these are so many of them, I
think, like you cannot say, fundamentally broken for but for a question I had was
specifically for SGX at that point, because signal uses its mobile coin,
cryptocurrency uses it and so on and so forth. Is that fundamentally broken or
would you rather say so? So I guess it depends what you call fundamentally right.
So there has been in the past, we have worked also on what I would say for
breaches of attitudes, but they have been fixed and it's actually quite a beautiful
instance of a well researched and have short term industry impact. So you find a
vulnerability, then the vendor has to devise a fix that they are often not
available and there are often workarounds to the problem. And then the later,
because you're are talking, of course, about how to talk to. So then you need new
processes to really get a fundamental fix for the problem and then you have
temporary workarounds. So I would say, for instance, a company like Signeul using it,
if they so it does not give you security by default. But you need to think about
the software. That's what you focused on in this stock. We also need to think about
all of the hardware, micro patches and on the processors to take care of all the
known vulnerabilities. And then, of course, the question always remains, are
the abilities that we don't know of yet with any secure system? I guess. But but
maybe also David wants to say something about some of his latest work there.
That's a bit interesting. Yeah. So I think what what your source or my answer to this
question would be, it depends on your threat model, really. So some some people
use SGX as a way to kind of like remove the trust in the cloud provider. So you
say like RSS and Signaler. So I move all this functionality that that is hosted
maybe on some cloud provider into an enclave and then then I don't have to
trust the cloud provider anymore because there's also some form of protection
against physical access. But recently we actually we published another attack,
which shows that if you have hardware access to an SGX processor, you can inject
false into into the processor by playing with the on the voting interface with was
hardware. And so you really saw that to the main board to to a couple of a couple
of wires on the bus to the voltage regulator. And then you can do voltage
glitching, as some people might know, from from other embedded contexts. And that way
then you can flip bits essentially in the enclave and of course, do all kinds of,
um, it kind of like inject all kinds of evil effects that then can be used further
to get keys out or maybe hijack control flow or something. So it depends on your
threat model. I wouldn't say so. That ASX is completely pointless. It's, I think,
better than not having it at all. But it definitely cannot you cannot have, like,
complete protection against somebody who has physical access to your server. So I
have to close this talk. It's a bummer. And I would ask all the questions that I
flew in. But one very, very fast answer, please. What is that with a password in
your background? I explained it. It's it's, of course, like just a joke. So I'll
say it again, because some people seem to have taken it seriously. So it was such an
empty whiteboard. So I put a password there. Unfortunately, it's not fully
visible in the in the screen. OK, so I think you should open book out of David
Oswald. Thank you for having that nice talk. And now we make the transition to
the new show.
Subtitles created by c3subtitles.de in the year 2021. Join, and help us!