*rc3 preroll music*
Herald: In the world of bad puns, everyone knows and loves the famous line from the
cinematic masterpiece, where the IT security specialists ask the CPU architect
"Warum leakt hier Strom?" or in English, "why is power leaking here?". In this talk
our four speakers demonstrate how they can attack modern processors purely in
software, relying on technical, techniques from classical power side channel attacks.
They'll explain how to use these unprivileged access to energy monitoring
features and modern Intel and AMD CPU's. Please welcome with a round of digital
applause. Moritz Lipp, Michael Schwarz, Daniel Gruss and Andreas Kogler.
Moritz: Warum leaked hier Strom? *laugh track*
Andreas: Und warum wendest du kein Masking an?
*laugh track*
Daniel: But to understand how we got here, we have to go back to San Diego in May
2017. A: This is a great, Moritz, this is
a great talk title. We have to use this. *laugh track*
M: Yeah, but actually, before we can do a talk, we should do some interesting
research that we can present, right? *laugh track*
A: Of course. Of course. But we have to remember this talk title, it's great.
*laugh track* M: Yes.
*music*
Michael: Hey Moritz. Today I have found something really cool.
Moritz: OK, what is it? Michael: Our computers, they give
us the current energy consumption in microjoule and you can access that
from userspace. *laugh track*
Moritz: What? Are you for real? Michael: That, that basically means we
could mount something like software based power side channels.
Moritz: Nice. We should try that out. Michael: Yes, I already did, because I
thought you might not believe me. Moritz: OK.
Michael: So this is one of the experiments I did. Here you can already see that. I
measured the power consumption using that interface.
Moritz: yeah Michael: First while doing nothing, idling
around sleeping Moritz: like always
Michael: and then I increased the CPU load, I just did an endless loop which
accessed a bit of memory. It's nothing interesting but you can already see the
difference for that. So you can see that there's a difference in doing nothing and
doing a lot. That's pretty nice. Moritz: We should look take a closer look
at that, I think. Michael: Definitely.
*music*
Moritz: *sings* You can create my power trace
Andreas: Oh, this is great. We already
have a song for this paper now. Okay. Well, this is a great song that we can use
for the paper...
*music*
Michael: Powertrace, like power analysis attacks?
Moritz: Yeah, but that would be an attack with physical access.
Daniel: Software-only would be great
Michael: Yes, I told you already, I found one can measure energy
consumption in micro joules
Moritz: Like attacking all server, desktop and laptop CPUs
Daniel: Ideally with unprivileged access
Michael: Imagine if you could distinguish different instructions
or even observe the Hamming weights of operands and memory loads
Daniel: Control flow monitoring
Moritz: In physical attacks they often go for cryptographic keys.
That would be great. Attacking AES-NI and RSA
Daniel: There's just one problem: there is no such channel
Michael: As I said, don't you listen, Daniel?
It's like always, there is this RAPL register. This interface is already there
and you can measure power consumption
Daniel: Yes, but only on a very coarse granularity
Moritz: But first, we need to get a bit
more understanding of the CPU power management. The thermal design power, the
TDP, is the power consumption under the maximum theoretical load of the processor.
And you probably know that number from the CPU specification. And this gives
integrators a target to find the proper thermal solution when you integrate CPU in
a computer so that it doesn't run too hot. But for short periods of time, the CPU can
consume more power than that. And this we can see in this graphic. So here for this
Tau moment, the power consumption is much higher than for the rest of the CPU.
Because usually a CPU is not instantly hot and thermal properties propagate over a
bit of time. So on the other hand, you should also be able to save power. And you
can do this in different ways. For instance, you could just shut down
resources completely that you do not need at the moment, or you can reduce the
voltage of the processor or those components and then it also consumes less
power. And on top of that, you could also reduce the frequency of the processor and
then it also consumes less power. And you need this for different scenarios. For
instance, with your laptop, you need to budget the power consumption because you
want to have a long run time. And you also know these options that you can change,
like the performance level if it should run on high performance or to save
battery. And you need this in different scenarios.
Michael: Yes, Moritz, that's exactly what I showed you before. Do you remember? I
showed you this intel running average power limit, short RAPL, that provides
exactly that functionality. So with this Intel RAPL, you have the power limiting
features so you can do exactly what you just described, reduce the power usage for
your system or for parts of your system. And additionally, you also have the energy
readings. So you know exactly how much power is currently used on a system which
helps you do exactly the things you just mentioned before, like getting a better
power performance balance. So this is already there.
Moritz: Because the CPU needs to know in a way how much power it consumes, right?
Michael: Exactly and the scheduler also uses that feature to ensure that you get a
better battery runtime on your laptop, for example. And because this is an important
feature you can directly get that from the operating system as well. On Linux, you
can even get that as an unprivileged application. There's the powercap
framework that you can directly access in this pseudo file system where you get the
current power readings, you can directly see how much power your CPU currently
consumes. Moritz: How convenient!
Michael: On MacOS and on Windows you have a similar thing, but for that you first
need to install a driver because usually you don't need that as a userspace
application. But some drivers might want to have that and some drivers even expose
that to you and you can use that. So there are some drivers that are even
preinstalled on some of the motherboards that expose that information to
applications as well on Windows. Moritz: Interesting, but what can we do
with this? So I ran some experiments because I wanted to know how good this
energy consumption monitoring works. And in a first run we tried to distinguish
instructions from each other. So we implemented a small program just running
the same instructions all the time, and we measured its power consumption. And as we
can see easily in this plot, different instructions need a different amount of
power. So we can distinguish instructions from each other. In addition, what I
tried, I changed the operands that different instructions used. For instance,
for a multiplication, you can multiply different numbers with each other. And
also here we see, depending on the bits that are set in the operand a different
power consumption of the same instruction, but just depending on the operand so we
can also distinguish them from each other. This could also come in handy later on.
But I also tried to load data with an instruction and I wanted to know if I
could see differences in the power consumption, depending on the data that
has been loaded by the processor. And as you can see in this plot, the more bits
that are set in the data that is loaded, the more power the CPU consumes. But let's
be honest here, to record these measurements, it took more than 23 days,
so it took quite some time to get to this granularity to see those differences, but
in other cases, if you just... Michael: still a fascinating result.
Moritz: Yes, it's a very interesting result. And in other cases, Michael, you
only want to know if one operand or one value is a zero or if it's not a zero. And
to come to this result, you don't need that many measurements. And the last
experiments that we did was we wanted to know if we would see a difference in the
energy consumption, depending where data has been loaded from. For instance, as
we've seen also at CCC in many different talks over the past years, they are like
cache attacks. And here in this experiment, we also were able to see a
difference in the power consumption if your value has been loadad from the cache
or if it has to be loaded from the main memory, because, of course, then DRAM is
activated and it consumes more power. But these results are very nice.
Michael: Yes, these are really fascinating results. So we should actually exploit
them and build attacks from that. I mean, it's fascinating to see that all these
measurements are possible, but we also want to do something security related.
Moritz: Do you have any idea what we could do?
Michael: Yes, I have that idea I already showed you something from before. If you
remember from the office, this one measurement. And I extended that
measurement. Moritz: Yes.
Michael: Into a covert channel. So a covert channel is a communication channel
between two parties that are usually not allowed to communicate with each other. So
there might be different reasons for that. Maybe ther's no interface, maybe there's a
policy or a firewall or something that prevents them from communicating. And
still, in this scenario, I want to communicate. So for that, I'm using
exactly these power side channels and all this analysis you have done to actually
communicate. And that's is very simple to do, actually. I have two processes, a
sender and a receiver, and the sender tries to send single bits, zeros and ones.
And to send a one bit. I do something that uses a lot of energy, like accessing main
memory. And if I want to send a zero bit, then I don't do anything. And now as a
receiver, I just have to measure the power consumption and I see if the power
consumption has a spike. Then I know the sender is sending a one. If there's
nothing the sender is apparently sending a zero and from that I can get this
information a Sender wants to send me. Moritz: But did you try that out?
*laugh track* Michael: Yes, I also tried that and we can
see that here in this graph. So this is the energy measurement.
Moritz: That's a very clean signal. Michael: Yes, it's the energy measurement
on the receiver side. And we see exactly what I told you before. If there are one
bits, then the energy consumption is higher. If there are zero bits, it's
lower. And from that we can deduce the information that I wanted to send on the
sender side. Pretty neat, huh? Moritz: Yeah, but this is just from one
process to another process. Actually, I took your idea and used this in a
hypervisor scenario where we attack the Xen hypervisor. So it's not limited to two
processes. I installed the Xen hypervisor with two virtual machines. And what Xen
does is it also exposes those RAPL registers to the virtual machine. So now
as a virtual machine, I can have direct access to that and then I can establish a
covert channel between two virtual machines in the cloud.
Michael: That's even better. Moritz: And this is really working, as you
can see here. I mean, here I'm just sending ones and zeros, but the signal is
pretty clear. Michael: That's nice.
Moritz: But it's the more that we can do? Michael: Yes. I mean, covert channels are
great to demonstrate something, that it actually works, across VM, really great. I
like that. That gives you a different threat model here, but still they are a
bit boring. So I decided to have something more interesting as another example of
what we can do. I always like to break kernel address space layout randomization,
KASLR. With this kernel address space layout randomization, the kernel is mapped
to different virtual locations every time I boot my computer to make it difficult to
actually exploit something in the kernel because it's not predictable where the
kernel is located. And I again use the energy consumption to figure out where
this kernel is located. So how does that work? In this address space I have the
kernel which is actually mapped using physical pages and I have a lot of nothing
where no physical page is mapped. And if I try to access these addresses, I can't, of
course, because I don't have the privileges for that. But I will still see
differences when doing that because the CPU has to do different things depending
on whether there's actually a page or not, whether this page can be cached, this
translation, or whether this translation is always invalid because there's nothing
there and it can't be cached. We can see that here in an illustration, if you're
wondering how that really works. So it turns out the kernel can only be mapped to
a limited number of places because it has to be aligned by two megabytes, so I only
need to check the spots there where the kernel could be located. And for all these
places in the address space, I just try to access it and measure how much energy that
consumes. And if there's nothing mapped, it consumes quite a lot of energy because
the CPU has to figure out that there's nothing mapped. It goes through the page
tables, the page table walk, and at the end figures out, oh, there's nothing here,
so I can't do anything, and aborts that. And that uses quite some energy. But if
there's actually the kernel here, then this translation is valid. It works. There
is something there. It will likely be already in the translation caches in the
TLB, so the CPU has less work. It just needs to check the cache, sees: "Oh it's
there. I know that. But wait a moment, you can't access it" and can immediately abort
and that uses less energy. So just from the energy consumption, I can see if
there's something mapped and with that see where the kernel is actually mapped.
Moritz: And this is really working? Did you try it out or is this just some
theoretical thing? Michael: You're always so skeptical. Of
course I tried that and I brought the demo with me. So here you can see the demo
running. This is on a real system. And you see it's super fast measuring the energy
consumption going over the address space and finding the kernel.
*applause* Moritz: But these attacks are boring,
Michael. We want to attack something real, we want to be like real attackers, we want
to attack crypto, we want to get keys. Michael: Crypto is complicated. That's …
*laugh track* Moritz: No, no, no, just listen. So, for
instance, with RSA, this is a widely used public-key cryptosystem. This is really
easy because to encrypt some data, you have a public key. To decrypt the data you
have a private key. And if we get the private key: profit, easy as that. What do
you say? Michael: Yeah, I know how that works. So
the theory is easy, that I have the two keys and I have a private key. But then
the complicated part starts where you really have to understand the crypto to
actually attack it. And that's really complicated. And I don't really want to do
that. Maybe we can a student who tries that but I'm out of here. *laughter*
Andreas: Hi guys, I'm a student and I want a master thesis.
Moritz: This is perfect. Your name is Andreas, right?
Andreas: Yeah, sure, I'm Andreas. *laughter*
M: OK, I don't know if you have heard the last bits, but we want to attack some
crypto with power side channel attacks. A: OK
Moritz: And for instance, with RSA, we have the private key and the public key.
Here we have M the message and C the ciphertext and d the private exponent. And
of course, it's a computer. It consists of ones and zeros. And depending on the key
bit if it's a one, for the computation of the algorithm, we do a square and the
multiply operation. And if it's zero, we just do the square operation and we do
this for the entire private key. A: Now OK, sounds easy enough.
M: Yes. And if we can observe that we can extract the key. Sounds good. But I
did some experiments and it didn't work out as well as I've expected it to be. So
we need to get a bit more control and maybe a better threat model how to do
that. And there comes Intel SGX into play. And this is an instruction set extension
and it provides you with integrity and confidentiality of code and data even in
untrusted environments. So with Intel SGX, you can run programs using protected areas
of memory. And even in the case where the operating system is compromised and cannot
be trusted at all. A: So basically we have the full
access of all operating system features to attack, the enclave.
M: Yes, exactly A: OK, that sounds quite powerful
M: But there's still one issue. It's still just executing a program. So we have
more power, but we need to make use of that. And there is this paper called
SGX-Step, which gives you more control of enclaves and Jo Van Bulck the author maybe
has time to explain this a bit to us so maybe we can give him a call.
A: Sounds great. *ringing sound*
M: Hi Jo, this is Moritz. I've seen the paper of yours, this SGX-Step paper.
It might be the thing that we need, but can you explain a bit what it is about?
Jo: Yes, surely Moritz, so SGX-Step I think in one sentence it's an enclave
execution control framework. What I mean with that is that it allows you to
precisely control the execution of the enclave so that you can interleave it with
attacker code, as the name implies, you would do one step of the enclave, one step
of the attacker again one step of the enclave, one step of the attacker, etc.
M: That's perfect. J: That's the high level.
Moritz: Can you expand it a bit on the technical point of view? How do you do
that? J: Yes, I'm very excited about the
technical details, Moritz. So let me walk you through. The first thing you should
know about SGX-Step: it's completely open source and we build it on top of stock
Linux environments. M: Nice
J: So what you should start with always is to load a malicious kernel driver. And
this is called the /dev/sgx-step driver. And from that moment on we kind of export
all of the powers of the Linux kernel into the userspace. And the second component of
SGX-step that's important is this small library operating system that we wrote.
It's called libsgxstep and it sits just alongside of the library alongside in the
userspace application. And libsgxstep allows you to do a number of cool things.
I think the most important thing being that you have direct access to the APIC
x86 high resolution timing device. So that sounds interesting for you, right Moriz?.
M: Yeah, but what do you do with the timer?
J: Well, what you can do with the timer is essentially you can arm it just before
you enter the enclave. And what would happen then is, let's have a look. You arm
the timer, you start executing the enclave, then after a while and interrupt
fires and you exit the enclave again. M: Hmm, so it's like a debugger like
GDB, but for enclaves? J: Yes, it's a... it's exactly that
Moritz. It's like an attacker controlled debugger without using any of the debug
features, just using the raw x86 primitives and operating system files. And
just as in a debugger, it allows you to do single stepping. So every instruction will
be executed one at a time. At most one at a time I should say.
M: But what happens if I, like, configure the timer a bit lower? Does it
then like start executing an instruction? J: That's a very good question. And
configuring the timer is the tricky thing about SGX-step. So it will indeed happen
sometimes what we call a zero step event. So you will fire the timer before the
enclave even had time to execute an instruction. And those are a kind of event
that you can also detect with SGX-step. There is a trick to detect whether you had
a single step or a zero step. M: Jo, this is perfect. This is
exactly what we are looking for. Thank you so much for explaining that.
J: I'm very happy to hear that. M: I'm looking forward to try it out
now. J: Go.
M: See you hopefully soon. J: Bye bye.
M: Bye!
M: So SGX-step to sum it up, it's an open source Linux kernel
framework, and it allows us to configure the APIC timer interrupts so that we can
interrupt the enclave execution to single and zero step it. And this is perfect
because now we can combine it with the power measurements of Intel RAPL, and this
gives us the possibility to measure the energy consumption of single instructions.
Can you try it out Andi? A: OK, let me dig deeper into that.
We have this really slow RAPL interface here and if you want to visualize it, we
could imagine that it's like we have slots where we can fill the slots with
instructions and the RAPL interface gives us the average power consumption over the
slots. So in the default case, when we execute our target instruction, we have
basically one slot filled with the target instruction and the remaining slots filled
with other instructions we don't know. So basically noise. The best case for us
would be if we repeat the target instruction indefinitely and fill every
slot with the target instruction. M: This is exactly what I did
in the experiments in the beginning. A: Yeah, exactly. That's the reason
why we got so good measurements there. Another trick would be if we only used the
target instruction in one slot and fill the remaining slots with instructions
where we know the energy consumption of or we know the instruction of. Then it could
do tricks to calculate the energy consumption of the target instruction.
With SGX-step now we can use a hybrid solution here, where we use SGX-step the
zero stepping mechanism to reissue this instruction and we can fill multiple slots
with the same target instruction. Only drawback here is that we have a noise
overhead of SGX-step itself, but this is probably the best solution we can go with.
M: This sounds pretty good, so we should actually try that out. So we
implement a toy cipher, which imitates square and multiply basically. So we can
leave out all the rest, the overhead of a library that would be used otherwise. And
we then just single step every instruction and measure its energy consumption and
then we could plot this. Can you do that? A: I got already some results here
for us. Basically here we use, as you explained, a toy example for square and
multiply. And in both cases the square and the multiply, they execute exactly six
instructions. And so basically we have a period of six here. And if you look at the
results of the measurement here, we can see that we have patterns that repeat with
a period of six and we can see that these different patterns correspond to either a
square or a multiply instruction here. M: Nice, perfect, but this is just a
toy cipher, right? *laughter* A: Yeah.
M: Can we do like real crypto? *laughter*
A: We can try. So the plan now is that we want to attack a real RSA
implementation and the real implementation is not like a toy square and multiply
algorithm. The real implementation needs to handle these huge numbers. So basically
there's much more code involved and it's not feasible to single step every
instruction there. So we must do a more clever approach here. If we observe the
square multiply part here, we see that the square and the multiply function uses the
AVX optimized memset function. So the energy consumption should also be more if
we execute an AVX instruction because AVX instructions use much larger registers. So
basically we should be able to observe that.
M: Interesting. A: The only drawback here is that we
cannot use the same approach as with the toy cipher because the square has a
different number of instructions as the square and multiply function. So we need
to do a trick here. So to understand what we did here, our target is that we
reconstruct a key bit. And if the key bit is one we execute a square and multiply.
If the key bit is zero, we execute a square. So to visualize how we execute
zero and single stepping, we have to dig into the assembler a bit. So to test for
the key bit, we execute like a test instruction and then we execute a
conditional jump. And if we execute the square and multiply we have for instance,
K instructions. And if we execute the square we have for instance L
instructions. So we can see that these two numbers do not add up. They are different.
So we cannot simply measure each Kth instruction and get the key out. So we
need to do something different here. We can number the instructions after the jump
instruction and then using single stepping to single step to the Nth instruction
after the jump instruction. And on the left side, if you observe one, we hit then
exactly the AVX instruction there, used in the AVX memset. And if you then use our
measurement framework to measure exactly the nth instruction after the jump, we
observe on the one hand a high energy consumption and on the other hand, we
observe low energy consumption if the branch was not taken or a zero.
M: It's very clever. A: So if you measured both
instructions here, we can then combine this energy measurements and then use a
simple threshold to reconstruct the key bit in the beginning. And then we do this
iteratively for each key bit. M: This sounds pretty promising, but
did you try it out? *laughter*
A: Sure. Here, the results of that. And we can clearly see that we have
different energy consumption or in this case voltage
*applause* based on if the
AVX instruction is executed or if the instruction at the same offset in the
other branch is executed. M: How fast does this work, does this
take like 5 days? A: Not quite that long. We have one
problem here that the time per key bit increases the further or later the key bit
is in the key. So basically the first key bit we can reconstruct very fast, but for
the last key bit, we need a single step much further in the code to actually reach
it. And this adds up. So basically the time increases linearly between the key
bits. But for our key here, our test key with 512 bits that takes us about 3.5
hours to reconstruct a complete key. Note here that we spent like 52 minutes
only to find the target instruction. So basically, if we could optimize that, the
attack would be much faster. In addition, we had to record like 3 samples per key
bit. But with the implementation, it should be possible to actually do that
with 1 sample. And since we then only need one sample per key bit, we actually can do
it with a single trace attack. But we did not try that out, unfortunately.
Moritz: quite fast. Michael: So while all this sounded quite
easy and straightforward in hindsight, this was actually a really long process.
Starting at the beginning of 2017 when we discovered this interface, the RAPL
interface. Then we had to come up with a title for this talk, of course, *laughter*
and some lyrics for a song. We had the first toy attack on RSA at the end of
2017. It took us until 2018 to finally get a KASLR break that was working and only in
2019, by the end of 2019. After Andreas did his master's thesis on that, we were
able to produce a full attack on RSA. And this is also the time when we submitted
that as a paper to a conference and disclosed that to the CPU vendors so that
they can fix that. And this is also the start of the embargo. This embargo for
this vulnerability lasted almost one year. So from November 2019 to November 2020. It
was just a few weeks ago that this embargo ended here.
Moritz: But there's one thing missing. We really wanted to do crypto attacks, but
not only with SGX-step as a compromised operating system, but also from userspace.
But as we've seen, it's so difficult to measure parts of the code without having
SGX-step. But what we can do is we can measure the power consumption of the
overall execution of an algorithm and there correlation power analysis comes in
handy. And there what we do is we build a power consumption model of our device. As
we've heard earlier, the Hamming Weight is the number of bits that is set in an
operand or in the data. And we assume that if a bit is set, the computer takes more
power to process it. In addition, what you can use as a different model is the
Hamming distance. So from one operation to the other, how many bits change? And then
we assume the more bits change, the more power is consumed. And we really want to
try that out. So what we are targeting now is AES-NI, a side channel resistant
instruction set of Intel. And we target it in a scenario where we can trigger the
encryption and decryption of many, many blocks over long time so that the
execution time is longer than the RAPL update rate, so that we can really see the
power consumption in our measurement. And this is used, for instance, in disk
encryption or decryption or if you seal or unseal the SGX enclave state. And we can
now do that and record power measurements in different scenarios, right?
Andreas: Sure, we can try that. So in our experiment, we recorded two million traces
over 26 hours for SGX environment. But we also tried to reconstruct it without SGX
where we used the encryption inside a kernel module. And there we recorded
4 million traces in 50 hours. And to understand the attack here, we have to
look at this animation. So basically we have our computer where secret key is
stored somewhere intern. Then we have this key to encrypt some messages and we also
have the power consumption here. And what we now did is we recorded the encrypted
message and the power consumption it took to encrypt this message for many messages.
And then we use a model of the CPU here to predict the energy consumption, to
reconstruct the key. The key is usually split up into parts, where each of the
parts can have a value between 0 and 255. So to reconstruct the key here, we simply
use our measurements in the model and we try out one of the key parts and estimate
the energy consumption for the key part. And then we store the correlation between
the recorded messages and the prediction. And we do this for every of the possible
key values. And once we found the key value of the highest correlation, we know
that this key value corresponds to the key part of the key. And we then simply repeat
the process for each of the parts of the key until we get the final key.
M: And we actually tried that out. So here in our demo video, you see on the
left where we test all the combinations and see what is the most likely key
candidate at the moment, while for a single key byte on the right, you see
every possible value and the correlation. So in the beginning, with not that many
traces processed, it's not very clear which key candidate is the right one,
because there's so much measurement noise introduced by measuring over the overall
execution time. But over time, this signal gets more stable and we see on the right
with the peak getting more and more distance from the other candidates that
this is our correct key byte. And we do this, as Andreas said, for every possible
key byte with every possible value. So in the end, we end up with the correct key.
*applause* A: OK, but this seems like it's only
Intel CPUs. Does this also affect others? M: Yes. So actually, we also tried
out how to CPU vendors if they have similar interfaces. And for instance, AMD
is affected as well. But we never really heard back from them after our disclosure.
And the patch how to try to solve the problem with the driver is similar to the
one that Intel has. A: Your right Moritz, it actually
works. So I tried the same code on AMD. The one you showed before was
distinguishing operands, at that also works on AMD. That's pretty nice. It's not
an Intel only issue. It also affects at least AMD as well.
M: Yes, but actually there are many other vendors as well that provide
interfaces, even some of them unprivileged to user space where you could probably
mount similar attacks. For instance, Nvidia, IBM, or Marvell and Ampere.
A: So this is really an industry wide problem here. And we've also seen
that from the media coverage. So not only German news brought about that like Heise
or Golem, but it also went more international with ZDNET, Ars Technica,
CSO, Tech Radar, Computer Weekly and many, many others that wrote about this new type
of vulnerability that affects many computers out there. And I guess if it
affects many computers, we should do something against that.
M: Yes, you're right. We cannot only have an attack and no mitigation against
it. This would not be right. And indeed, it's quite easy to fix that because we
said in the beginning, you have unprivileged access to those registers. So
we just restrict the access. And we are done, and this is exactly a one line patch
for the Linux kernel. But as we've seen with the threat model of Intel SGX, which
allows a compromised operating system. So this one line patch does not help there
because I'm the operating system, I can do whatever I want to. We need more and more
complex mitigations. And in this case, microcode updates are necessary. And what
Intel does is to fall back to the model of the energy consumption. So they have an
internal model. How much energy is consumed by an executed instruction and
use that instead of the real measurement. And this does not allow to distinguish
data and operands from each other again. So if your implementation is implemented
correctly, if you use constant time, then you are mitigated and protected against
these attacks. And as we see here in the plot, we tried to mitigation out. So on
the left, we were able to see differences depending on the Hamming weight of the
operands. And on the right with the mitigation in place, it just does not work
anymore and you cannot see any differences. *applause*
Andreas: Nice. So you really can't read her power trace any more.
*Music: Pokerface by Lady Gaga*
*sings* I wonna probe 'em like in 1943
touch 'em, measure wattage correlate and get the key
I probe it
Oscilloscopes are not the same without a probe
And babe, if it's remote if it's not code, it cannot run
I'll let him plot, let's see what he's got
Can't read my, can't read my
No he can't read my power trace
She's got the countermeasure
Can't read my, can't read my
No he can't read my power trace
She's got the countermeasure
P-p-p-power trace, p-p-power trace
*applause*
Moritz: With all those nasty songs, we
wrote them down in a scientific paper and the PLATYPUS paper has been accepted
recently at a conference. And we also want to thank you, all the other coauthors who
are not in this talk, like David Oswald, Catherine Easton and Claudio Canela. To
sum it up, what we have seen is that with power sidechannel attacks, you can even
exploit them from software. So there is no need to attach an oscilloscope on modern
Intel CPUs.
Michael: And what we've also seen is that since the SGX threat model allows for
much more capable attackers, mitigating power sidechannel attacks on the SGX
enclaves is much more work than simple software patches.
Andreas: Yes, and that concludes
our talk on PLATYPUS. Thank you all for listening.
*Applause and Music*
Herald: Thank you very much for your excuse me, nerdy talk and thank Moritz,
Michael, Daniel and Andreas. We head over to our Q&A session and the first question
would be, how does it come that you have so, let's say through the back door
against CPU attack against the CPU idea, you mentioned you attack the through a
power driver RSA. Could you tell me a little bit more about that?
Moritz: Yes. So the basic idea of attacking cryptographic algorithms with
power side channel attacks is not very new This was like one of the first things
researchers have shown, but most of the time for like smaller devices, like smart
cards, like your bank card, for instance. And for those attacks, you usually had
like an oscilloscope that you needed to attach to the device to do the attack. But
with modern processors, they have basically an oscilloscope built into the
processor, which you can read out as the operating system. And in our case, there
are like drivers that expose this interface, also to userspace. So from
there as an unprivileged attacker, you can then try to exploit that. And yeah
basically the best thing that we wanted to achieve with those attacks is to attack
cryptographic algorithms and not to transmit some data between two processes.
Herald: Cool, thank you. Our next question, you mentioned a little bit about
ARM sorry, AMD, how about ARM? So not x86 architecture?
Moritz: So there are many other vendors that have similar interfaces, some of them
also provide drivers that expose them directly to userspace, but we hardly had
any access to those devices, so we could not really fully evaluate if these attacks
are also possible on them. But in the paper, we have an appendix where we
describe them in a bit more detail so you can try it out on your own and let us know
if it works. Herald: Cool. Thank you. So please, fellow
hackers, try it out at your system, at home. Now, our next question is related to
that. Is there a survey which hardware has the RAPL or similar weaknesses? Intel,
AMD, ARM even. Moritz: I don't know if anyone else wants
to answer that, I can also take the question. So the RAPL interface itself
comes from Intel, but a similar interface is also implemented for AMD, and they also
use basically the same name. They have a... For now, it's implemented in two ways
for the Linux kernel, also in the RAPL driver, but also in a separate called AMD
Energy Driver, which is included since a few months in the Linux kernel, in the
upstream Kernel. And for other vendors it works a bit differently. So some of them
just give you similar measurements, but not in a tightly related way to the RAPL
Interface with a measure over a period of time and give you the average.
Herald: OK, and.. Michael: Maybe to add one point here: On
Intel, basically the high resolution sensors are included since the Skylake
micro architecture. So something around 2015.
Herald: I see. We have another related question to AMD. So did AMD issue any
Microcode update for the secure encrypted virtual machines case apart from
restricting access to MSR? Moritz: Not as far as we know. But from
our knowledge to attack AMD CPU's, we need to wait for a new generation so that we
can do similar attacks from a similar threat model than we can do on an Intel.
Herald: Cool, thank you. So another I think this is also related to it, you
mentioned your Xen example where you attack through a hypervisor. Does it work
on other hypervisors like KVM or hyperV as well?
Moritz: So for KVM, I don't think so. For Windows I also don't know I don't think
they exposed those MSR directly to the virtual machines. So the issue is really
here that we can have access to those MSRs at the virtual machine where we should not
have access to. Herald: OK, we have another question from,
I think, the hardware section of our remote Congress. Someone wonders if the
same could be achieved with external power measurement.
Moritz: You mean if you could attach actually an oscilloscope or a different
probe to the CPU? Yes, you can do that. And it has already been demonstrated in
the past. Michael: But it turned out with external
tools, it takes even longer than with software. You have more issues finding the
right spot in measuring. And there is one paper, it took 14 days of collecting
traces which are harder to probe, which is much longer than in software. But it can
be done. Herald: And there's another follow up
question, how external is external? Where do you measure power consumptions of an
x86 server? Moritz: OK, you would need to get physical
access to the data center, I guess. And if this is in your threat model, you probably
have different things to worry about. Michael: Yeah, you still need to find the
right spot on your mainboard. Herald: OK, so are there, let's say
documentation's where to get that right spot.
Moritz: I think one can take a look at other research papers where they attached
a probe, I think there are experts out there, but I don't know.
Herald: OK, thank you. The next question, why is the power information exported in
such detail to the kernel or userspace software? Why isn't it only available to
the firmware or filtered to return an average, for example, one second power
trace? Moritz: Good question. We did not
implement that. I think the reason is... Andi?
Andreas: The once second power trace would make the attack only slower because you
can still do exactly what we did with single stepping here, because RAPL is
already very slow and we need a mechanism to replay instructions to get a good
reading of the energy consumption of the instructions. So if you only increase the
update rate there, the attacks would still be possible, but only take longer to
record the traces there. So you have to... Yeah. So you have to find a tradeoff
between your countermeasures there. Herald: Okay, so let's say with an
average, your resolution is lower, but still it just takes more time to record
it. And still it does work, right? Moritz: Yes. And the other thing is that
one needs to keep in mind those drivers are not written for security in mind, but
for performance so that this can be used by other tools that like give you the best
performance of your CPU. And in that case, it just has not been masked and you get
the value directly at the operating system sees.
Herald: Crazy. Our second to last question, how long is the update interval
for this measurement? I heard something about...
Andreas: For the fastest register we observed, it's like 10 microseconds, for
the slowest one... So there are different domains where you measure only parts of
the CPU and for the whole package, this includes all the cores and the memory
controller, it takes around one millisecond there. So this is already very
slow, if you compare it to the frequency where CPUs are currently running at.
Herald: Crazy. In this case, are there any other questions from the interwebs, from
Twitter, from our IRC channel? Because otherwise we would head over to more,
let's say, personal interview. Let's give them a try.
In this case, no more
questions, so in this. So, again, thank you. Moritz, Michael, Daniel and Andreas,
for these for this really interesting talk for this Q&A session, the Internet tells
me no questions. We head over to our personal interview. I asked you earlier
before our talk. So with all these, let's say, research things going on in the
Corona time. So what's your personal experience? What changed in your work life
balance in the last one year? Moritz: I think the biggest change is that
most of the coffee breaks you do alone instead of with the colleagues.
Herald: So how do you meet in your in your, let's say, lunch break? Do you have
as well a lunch break break out session in Jitsi? Yeah, we started with Jitsi, but
used different systems on the long way. And now it's like a fixed coffee meeting
at 2:00 p.m. every day and try to meet everyone or have individual meetings, of
course. Herald: And does this work? But so is
everyone on time. So sharp 12? Moritz: No, but I think no one really
cares. Herald: So it's just for socializing?
Moritz: Yes. But we also discuss work related issues also in separate meetings.
And yeah, I think time is different, but you get used to it. But let's hope it's
over soon. Herald: What about the others, Michael?
Michael: Yes, I'm in the same coffee breaks as Moritz. Sometimes every day,
depends on the workload, so I feel quite lucky that we can still work full time and
get our work done. And I don't have to fear that we lose our jobs in the in the
short term. So I think that takes a lot of pressure off. But, yeah, I mean, it's
different. I'm also missing the conferences, so I used to travel around a
lot before Corona times and this year is basically nothing. So you really miss the
social interactions and conferences, meeting other researchers, exchanging
ideas, having that online is different and just not the same, but still it works. So
I can still do a lot of research. The positive thing, you have less
interruptions than when you're in the office. So that's a positive thing. But
yeah, I also hope that it's over soon. Daniel: But then again, on the other side,
you have way more conference calls because instead of writing emails, people ask for
conference calls all the time. Michael: Yes, you are in meetings all the
time. Herald: Yeah, Daniel you mentioned earlier
you're, let's say, flightplan the last year. And as far as I understood it, you
like to be in personal contact with your colleagues, also from others or from
foreign countries. How does this work? So let's say topic exchange between different
organizations, between different countries?
Daniel: Yeah, it's more difficult. So in 2018, I had these 54 talks outside of Graz
in 52 weeks and this year I had a single talk outside of, outside of Graz where I
was in person of course. Of course more Online. Um yeah. So it's, it's difficult
to engage with people from other places, but it works of course in teams that you,
that you already have established in the past, for instance. So you can continue in
teams that you've already built there. But also in some cases it works to start new
collaborations. But it's of course more difficult than if you can just meet people
in person like we did for this paper actually, David Osvald, one of the
coauthors, we met with him in person and talked with him about the paper in person.
Herald: Andreas, what's your, let's say, Corona year?
Andreas: Yeah, since I'm one of the persons who was interrupting Michael all
the time I am missing the office because it looks like the unscheduled flow,
because it's sitting in an office and suddenly you have like a question or idea,
you can not or you don't have to write it. You can just ask it on the fly. So I'm a
bit missing that side. On the other side, I gained a lot of time since I don't have
to travel to work there. And often I got a bit better in writing stuff I want to
know, asking questions more, much more faster, like losing the clover and that
stuff. And so I think it's both positive and negative. And I only joined since I
think August, when I finished my master's thesis and in the first half of the year,
I worked at a software company where the first lockdown was also handled very well.
So we had like a smooth transition. So I'm kind of used to home office, but I miss
interacting with people. Herald: I think that's the main thing 2020
brings us: more remote work. Which is basically a good thing to work more from
home, but we have some minutes left. And please excuse me myself. Did your mate
consumption increase or decrease? Moritz: I think it's hard to say for
coffee because I used to drink more coffee in the office than at home. Yeah, but but
now I see it when we go grocery shopping. *laughs* It's hard to say.
Michael: I think it decreased for me because now if I'm tired, I can simply
take a nap, thats easier. Herald: And just turn your instant
messaging off. Michael: Yeah.
Herald: So our time is over. Thank you again for the brilliant for the amazing
work, for these attack against CPU, for the great puns you brought, for the nice
interview and have a nice remote Congress 3.
*postrol music*
Subtitles created by c3subtitles.de in the year 2021. Join, and help us!