[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:15.03,Default,,0000,0000,0000,,{\i1}34C3 preroll music{\i0}
Dialogue: 0,0:00:15.03,0:00:22.57,Default,,0000,0000,0000,,Herald: Hello fellow creatures.\NWelcome and
Dialogue: 0,0:00:22.57,0:00:30.14,Default,,0000,0000,0000,,I wanna start with a question. \NAnother one: Who do we trust?
Dialogue: 0,0:00:30.14,0:00:36.50,Default,,0000,0000,0000,,Do we trust the TrustZones \Non our smartphones?
Dialogue: 0,0:00:36.50,0:00:41.71,Default,,0000,0000,0000,,Well Keegan Ryan, he's really \Nfortunate to be here and
Dialogue: 0,0:00:41.71,0:00:51.71,Default,,0000,0000,0000,,he was inspired by another talk from the\NCCC before - I think it was 29C3 and his
Dialogue: 0,0:00:51.71,0:00:57.55,Default,,0000,0000,0000,,research on smartphones and systems on a\Nchip used in smart phones will answer
Dialogue: 0,0:00:57.55,0:01:02.52,Default,,0000,0000,0000,,these questions if you can trust those\Ntrusted execution environments. Please
Dialogue: 0,0:01:02.52,0:01:06.33,Default,,0000,0000,0000,,give a warm round of applause\Nto Keegan and enjoy!
Dialogue: 0,0:01:06.33,0:01:10.63,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:01:10.63,0:01:14.22,Default,,0000,0000,0000,,Kegan Ryan: All right, thank you! So I'm\NKeegan Ryan, I'm a consultant with NCC
Dialogue: 0,0:01:14.22,0:01:19.74,Default,,0000,0000,0000,,group and this is micro architectural\Nattacks on Trusted Execution Environments.
Dialogue: 0,0:01:19.74,0:01:23.25,Default,,0000,0000,0000,,So, in order to understand what a Trusted\NExecution Environment is we need to go
Dialogue: 0,0:01:23.25,0:01:29.73,Default,,0000,0000,0000,,back into processor security, specifically\Non x86. So as many of you are probably
Dialogue: 0,0:01:29.73,0:01:33.73,Default,,0000,0000,0000,,aware there are a couple different modes\Nwhich we can execute code under in x86
Dialogue: 0,0:01:33.73,0:01:39.29,Default,,0000,0000,0000,,processors and that includes ring 3, which\Nis the user code and the applications, and
Dialogue: 0,0:01:39.29,0:01:45.57,Default,,0000,0000,0000,,also ring 0 which is the kernel code. Now\Nthere's also a ring 1 and ring 2 that are
Dialogue: 0,0:01:45.57,0:01:50.23,Default,,0000,0000,0000,,supposedly used for drivers or guest\Noperating systems but really it just boils
Dialogue: 0,0:01:50.23,0:01:56.16,Default,,0000,0000,0000,,down to ring 0 and ring 3. And in this\Ndiagram we have here we see that privilege
Dialogue: 0,0:01:56.16,0:02:02.15,Default,,0000,0000,0000,,increases as we go up the diagram, so ring\N0 is the most privileged ring and ring 3
Dialogue: 0,0:02:02.15,0:02:05.47,Default,,0000,0000,0000,,is the least privileged ring. So all of\Nour secrets, all of our sensitive
Dialogue: 0,0:02:05.47,0:02:10.03,Default,,0000,0000,0000,,information, all of the attackers goals\Nare in ring 0 and the attacker is trying
Dialogue: 0,0:02:10.03,0:02:15.89,Default,,0000,0000,0000,,to access those from the unprivileged\Nworld of ring 3. Now you may have a
Dialogue: 0,0:02:15.89,0:02:20.15,Default,,0000,0000,0000,,question what if I want to add a processor\Nfeature that I don't want ring 0 to be
Dialogue: 0,0:02:20.15,0:02:26.24,Default,,0000,0000,0000,,able to access? Well then you add ring -1\Nwhich is often used for a hypervisor. Now
Dialogue: 0,0:02:26.24,0:02:30.61,Default,,0000,0000,0000,,the hypervisor has all the secrets and the\Nhypervisor can manage different guest
Dialogue: 0,0:02:30.61,0:02:35.68,Default,,0000,0000,0000,,operating systems and each of these guest\Noperating systems can execute in ring 0
Dialogue: 0,0:02:35.68,0:02:41.30,Default,,0000,0000,0000,,without having any idea of the other\Noperating systems. So this way now the
Dialogue: 0,0:02:41.30,0:02:45.23,Default,,0000,0000,0000,,secrets are all in ring -1 so now the\Nattackers goals have shifted from ring 0
Dialogue: 0,0:02:45.23,0:02:50.76,Default,,0000,0000,0000,,to ring -1. The attacker has to attack\Nring -1 from a less privileged ring and
Dialogue: 0,0:02:50.76,0:02:55.43,Default,,0000,0000,0000,,tries to access those secrets. But what if\Nyou want to add a processor feature that
Dialogue: 0,0:02:55.43,0:03:00.56,Default,,0000,0000,0000,,you don't want ring -1 to be able to\Naccess? So you add ring -2 which is System
Dialogue: 0,0:03:00.56,0:03:05.23,Default,,0000,0000,0000,,Management Mode and that's capable of\Nmonitoring power, directly interfacing
Dialogue: 0,0:03:05.23,0:03:10.35,Default,,0000,0000,0000,,with firmware and other chips on a\Nmotherboard and it's able to access and do
Dialogue: 0,0:03:10.35,0:03:13.82,Default,,0000,0000,0000,,a lot of things that the hypervisor is not\Nable to and now all of your secrets and
Dialogue: 0,0:03:13.82,0:03:17.88,Default,,0000,0000,0000,,all of your attacker goals are in ring -2\Nand the attacker has to attack those from
Dialogue: 0,0:03:17.88,0:03:22.40,Default,,0000,0000,0000,,a less privileged ring. Now maybe you want\Nto add something to your processor that
Dialogue: 0,0:03:22.40,0:03:26.90,Default,,0000,0000,0000,,you don't want ring -2 to be able access,\Nso you add ring -3 and I think you get the
Dialogue: 0,0:03:26.90,0:03:31.45,Default,,0000,0000,0000,,picture now. And we just keep on adding\Nmore and more privilege rings and keep
Dialogue: 0,0:03:31.45,0:03:35.26,Default,,0000,0000,0000,,putting our secrets and our attackers\Ngoals in these higher and higher
Dialogue: 0,0:03:35.26,0:03:41.26,Default,,0000,0000,0000,,privileged rings but what if we're\Nthinking about it wrong? What if instead
Dialogue: 0,0:03:41.26,0:03:46.71,Default,,0000,0000,0000,,we want to put all the secrets in the\Nleast privileged ring? So this is sort of
Dialogue: 0,0:03:46.71,0:03:51.49,Default,,0000,0000,0000,,the idea behind SGX and it's useful for\Nthings like DRM where you want that to run
Dialogue: 0,0:03:51.49,0:03:56.98,Default,,0000,0000,0000,,ring 3 code but have sensitive secrets or\Nother assigning capabilities running in
Dialogue: 0,0:03:56.98,0:04:02.05,Default,,0000,0000,0000,,ring 3. But this picture is getting a\Nlittle bit complicated, this diagram is a
Dialogue: 0,0:04:02.05,0:04:06.25,Default,,0000,0000,0000,,little bit complex so let's simplify it a\Nlittle bit. We'll only be looking at ring
Dialogue: 0,0:04:06.25,0:04:12.10,Default,,0000,0000,0000,,0 through ring 3 which is the kernel, the\Nuserland and the SGX enclave which also
Dialogue: 0,0:04:12.10,0:04:16.91,Default,,0000,0000,0000,,executes in ring 3. Now when you're\Nexecuting code in the SGX enclave you
Dialogue: 0,0:04:16.91,0:04:22.17,Default,,0000,0000,0000,,first load the code into the enclave and\Nthen from that point on you trust the
Dialogue: 0,0:04:22.17,0:04:26.98,Default,,0000,0000,0000,,execution of whatever's going on in that\Nenclave. You trust that the other elements
Dialogue: 0,0:04:26.98,0:04:31.64,Default,,0000,0000,0000,,the kernel, the userland, the other rings\Nare not going to be able to access what's
Dialogue: 0,0:04:31.64,0:04:38.02,Default,,0000,0000,0000,,in that enclave so you've made your\NTrusted Execution Environment. This is a
Dialogue: 0,0:04:38.02,0:04:44.75,Default,,0000,0000,0000,,bit of a weird model because now your\Nattacker is in the ring 0 kernel and your
Dialogue: 0,0:04:44.75,0:04:48.84,Default,,0000,0000,0000,,target victim here is in ring 3. So\Ninstead of the attacker trying to move up
Dialogue: 0,0:04:48.84,0:04:54.07,Default,,0000,0000,0000,,the privilege chain, the attacker is\Ntrying to move down. Which is pretty
Dialogue: 0,0:04:54.07,0:04:57.82,Default,,0000,0000,0000,,strange and you might have some questions\Nlike "under this model who handles memory
Dialogue: 0,0:04:57.82,0:05:01.47,Default,,0000,0000,0000,,management?" because traditionally that's\Nsomething that ring 0 would manage and
Dialogue: 0,0:05:01.47,0:05:05.29,Default,,0000,0000,0000,,ring 0 would be responsible for paging\Nmemory in and out for different processes
Dialogue: 0,0:05:05.29,0:05:10.46,Default,,0000,0000,0000,,in different code that's executing it in\Nring 3. But on the other hand you don't
Dialogue: 0,0:05:10.46,0:05:16.03,Default,,0000,0000,0000,,want that to happen with the SGX enclave\Nbecause what if the malicious ring 0 adds
Dialogue: 0,0:05:16.03,0:05:22.41,Default,,0000,0000,0000,,a page to the enclave that the enclave\Ndoesn't expect? So in order to solve this
Dialogue: 0,0:05:22.41,0:05:28.95,Default,,0000,0000,0000,,problem, SGX does allow ring 0 to handle\Npage faults. But simultaneously and in
Dialogue: 0,0:05:28.95,0:05:35.38,Default,,0000,0000,0000,,parallel it verifies every memory load to\Nmake sure that no access violations are
Dialogue: 0,0:05:35.38,0:05:40.14,Default,,0000,0000,0000,,made so that all the SGX memory is safe.\NSo it allows ring 0 to do its job but it
Dialogue: 0,0:05:40.14,0:05:45.01,Default,,0000,0000,0000,,sort of watches over at the same time to\Nmake sure that nothing is messed up. So
Dialogue: 0,0:05:45.01,0:05:51.12,Default,,0000,0000,0000,,it's a bit of a weird convoluted solution\Nto a strange inverted problem but it works
Dialogue: 0,0:05:51.12,0:05:57.58,Default,,0000,0000,0000,,and that's essentially how SGX works and\Nthe idea behind SGX. Now we can look at
Dialogue: 0,0:05:57.58,0:06:02.53,Default,,0000,0000,0000,,x86 and we can see that ARMv8 is\Nconstructed in a similar way but it
Dialogue: 0,0:06:02.53,0:06:08.45,Default,,0000,0000,0000,,improves on x86 in a couple key ways. So\Nfirst of all ARMv8 gets rid of ring 1 and
Dialogue: 0,0:06:08.45,0:06:12.17,Default,,0000,0000,0000,,ring 2 so you don't have to worry about\Nthose and it just has different privilege
Dialogue: 0,0:06:12.17,0:06:17.37,Default,,0000,0000,0000,,levels for userland and the kernel. And\Nthese different privilege levels are
Dialogue: 0,0:06:17.37,0:06:21.52,Default,,0000,0000,0000,,called exception levels in the ARM\Nterminology. And the second thing that ARM
Dialogue: 0,0:06:21.52,0:06:25.93,Default,,0000,0000,0000,,gets right compared to x86 is that instead\Nof starting at 3 and counting down as
Dialogue: 0,0:06:25.93,0:06:30.73,Default,,0000,0000,0000,,privilege goes up, ARM starts at 0 and\Ncounts up so we don't have to worry about
Dialogue: 0,0:06:30.73,0:06:35.94,Default,,0000,0000,0000,,negative numbers anymore. Now when we add\Nthe next privilege level the hypervisor we
Dialogue: 0,0:06:35.94,0:06:40.86,Default,,0000,0000,0000,,call it exception level 2 and the next one\Nafter that is the monitor in exception
Dialogue: 0,0:06:40.86,0:06:47.21,Default,,0000,0000,0000,,level 3. So at this point we still want to\Nhave the ability to run trusted code in
Dialogue: 0,0:06:47.21,0:06:52.65,Default,,0000,0000,0000,,exception level 0 the least privileged\Nlevel of the ARMv8 processor. So in order
Dialogue: 0,0:06:52.65,0:06:59.06,Default,,0000,0000,0000,,to support this we need to separate this\Ndiagram into two different sections. In
Dialogue: 0,0:06:59.06,0:07:03.51,Default,,0000,0000,0000,,ARMv8 these are called the secure world\Nand the non-secure world. So we have the
Dialogue: 0,0:07:03.51,0:07:07.74,Default,,0000,0000,0000,,non-secure world on the left in blue that\Nconsists of the userland, the kernel and
Dialogue: 0,0:07:07.74,0:07:11.90,Default,,0000,0000,0000,,the hypervisor and we have the secure\Nworld on the right which consists of the
Dialogue: 0,0:07:11.90,0:07:17.36,Default,,0000,0000,0000,,monitor in exception level 3, a trusted\Noperating system in exception level 1 and
Dialogue: 0,0:07:17.36,0:07:23.03,Default,,0000,0000,0000,,trusted applications in exception level 0.\NSo the idea is that if you run anything in
Dialogue: 0,0:07:23.03,0:07:27.36,Default,,0000,0000,0000,,the secure world, it should not be\Naccessible or modifiable by anything in
Dialogue: 0,0:07:27.36,0:07:32.32,Default,,0000,0000,0000,,the non secure world. So that's how our\Nattacker is trying to access it. The
Dialogue: 0,0:07:32.32,0:07:36.37,Default,,0000,0000,0000,,attacker has access to the non secure\Nkernel, which is often Linux, and they're
Dialogue: 0,0:07:36.37,0:07:40.12,Default,,0000,0000,0000,,trying to go after the trusted apps. So\Nonce again we have this weird inversion
Dialogue: 0,0:07:40.12,0:07:43.33,Default,,0000,0000,0000,,where we're trying to go from a more\Nprivileged level to a less privileged
Dialogue: 0,0:07:43.33,0:07:48.26,Default,,0000,0000,0000,,level and trying to extract secrets in\Nthat way. So the question that arises when
Dialogue: 0,0:07:48.26,0:07:53.07,Default,,0000,0000,0000,,using these Trusted Execution Environments\Nthat are implemented in SGX and TrustZone
Dialogue: 0,0:07:53.07,0:07:58.33,Default,,0000,0000,0000,,in ARM is "can we use these privilege\Nmodes in our privilege access in order to
Dialogue: 0,0:07:58.33,0:08:03.33,Default,,0000,0000,0000,,attack these Trusted Execution\NEnvironments?". Now transfer that question
Dialogue: 0,0:08:03.33,0:08:06.26,Default,,0000,0000,0000,,and we can start looking at a few\Ndifferent research papers. The first one
Dialogue: 0,0:08:06.26,0:08:11.36,Default,,0000,0000,0000,,that I want to go into is one called\NCLKSCREW and it's an attack on TrustZone.
Dialogue: 0,0:08:11.36,0:08:14.36,Default,,0000,0000,0000,,So throughout this presentation I'm going\Nto go through a few different papers and
Dialogue: 0,0:08:14.36,0:08:18.05,Default,,0000,0000,0000,,just to make it clear which papers have\Nalready been published and which ones are
Dialogue: 0,0:08:18.05,0:08:21.40,Default,,0000,0000,0000,,old I'll include the citations in the\Nupper right hand corner so that way you
Dialogue: 0,0:08:21.40,0:08:26.58,Default,,0000,0000,0000,,can tell what's old and what's new. And as\Nfar as papers go this CLKSCREW paper is
Dialogue: 0,0:08:26.58,0:08:31.43,Default,,0000,0000,0000,,relatively new. It was released in 2017.\NAnd the way CLKSCREW works is it takes
Dialogue: 0,0:08:31.43,0:08:38.01,Default,,0000,0000,0000,,advantage of the energy management\Nfeatures of a processor. So a non-secure
Dialogue: 0,0:08:38.01,0:08:41.68,Default,,0000,0000,0000,,operating system has the ability to manage\Nthe energy consumption of the different
Dialogue: 0,0:08:41.68,0:08:47.97,Default,,0000,0000,0000,,cores. So if a certain target core doesn't\Nhave much scheduled to do then the
Dialogue: 0,0:08:47.97,0:08:52.35,Default,,0000,0000,0000,,operating system is able to scale back\Nthat voltage or dial down the frequency on
Dialogue: 0,0:08:52.35,0:08:56.45,Default,,0000,0000,0000,,that core so that core uses less energy\Nwhich is a great thing for performance: it
Dialogue: 0,0:08:56.45,0:09:00.97,Default,,0000,0000,0000,,really extends battery life, it makes the\Nthe cores last longer and it gives better
Dialogue: 0,0:09:00.97,0:09:07.01,Default,,0000,0000,0000,,performance overall. But the problem here\Nis what if you have two separate cores and
Dialogue: 0,0:09:07.01,0:09:11.74,Default,,0000,0000,0000,,one of your cores is running this non-\Ntrusted operating system and the other
Dialogue: 0,0:09:11.74,0:09:15.58,Default,,0000,0000,0000,,core is running code in the secure world?\NIt's running that trusted code those
Dialogue: 0,0:09:15.58,0:09:21.24,Default,,0000,0000,0000,,trusted applications so that non secure\Noperating system can still dial down that
Dialogue: 0,0:09:21.24,0:09:25.63,Default,,0000,0000,0000,,voltage and it can still change that\Nfrequency and those changes will affect
Dialogue: 0,0:09:25.63,0:09:30.74,Default,,0000,0000,0000,,the secure world code. So what the\NCLKSCREW attack does is the non secure
Dialogue: 0,0:09:30.74,0:09:36.47,Default,,0000,0000,0000,,operating system core will dial down the\Nvoltage, it will overclock the frequency
Dialogue: 0,0:09:36.47,0:09:40.75,Default,,0000,0000,0000,,on the target secure world core in order\Nto induce faults to make sure to make the
Dialogue: 0,0:09:40.75,0:09:45.91,Default,,0000,0000,0000,,computation on that core fail in some way\Nand when that computation fails you get
Dialogue: 0,0:09:45.91,0:09:50.44,Default,,0000,0000,0000,,certain cryptographic errors that the\Nattack can use to infer things like secret
Dialogue: 0,0:09:50.44,0:09:56.04,Default,,0000,0000,0000,,keys, secret AES keys and to bypass code\Nsigning implemented in the secure world.
Dialogue: 0,0:09:56.04,0:09:59.68,Default,,0000,0000,0000,,So it's a very powerful attack that's made\Npossible because the non-secure operating
Dialogue: 0,0:09:59.68,0:10:06.10,Default,,0000,0000,0000,,system is privileged enough in order to\Nuse these energy management features. Now
Dialogue: 0,0:10:06.10,0:10:10.19,Default,,0000,0000,0000,,CLKSCREW is an example of an active attack\Nwhere the attacker is actively changing
Dialogue: 0,0:10:10.19,0:10:15.47,Default,,0000,0000,0000,,the outcome of the victim code of that\Ncode in the secure world. But what about
Dialogue: 0,0:10:15.47,0:10:20.54,Default,,0000,0000,0000,,passive attacks? So in a passive attack,\Nthe attacker does not modify the actual
Dialogue: 0,0:10:20.54,0:10:25.22,Default,,0000,0000,0000,,outcome of the process. The attacker just\Ntries to monitor that process infer what's
Dialogue: 0,0:10:25.22,0:10:29.20,Default,,0000,0000,0000,,going on and that is the sort of attack\Nthat we'll be considering for the rest of
Dialogue: 0,0:10:29.20,0:10:35.77,Default,,0000,0000,0000,,the presentation. So in a lot of SGX and\NTrustZone implementations, the trusted and
Dialogue: 0,0:10:35.77,0:10:39.76,Default,,0000,0000,0000,,the non-trusted code both share the same\Nhardware and this shared hardware could be
Dialogue: 0,0:10:39.76,0:10:45.80,Default,,0000,0000,0000,,a shared cache, it could be a branch\Npredictor, it could be a TLB. The point is
Dialogue: 0,0:10:45.80,0:10:53.23,Default,,0000,0000,0000,,that they share the same hardware so that\Nthe changes made by the secure code may be
Dialogue: 0,0:10:53.23,0:10:57.21,Default,,0000,0000,0000,,reflected in the behavior of the non-\Nsecure code. So the trusted code might
Dialogue: 0,0:10:57.21,0:11:02.26,Default,,0000,0000,0000,,execute, change the state of that shared\Ncache for example and then the untrusted
Dialogue: 0,0:11:02.26,0:11:07.18,Default,,0000,0000,0000,,code may be able to go in, see the changes\Nin that cache and infer information about
Dialogue: 0,0:11:07.18,0:11:11.72,Default,,0000,0000,0000,,the behavior of the secure code. So that's\Nessentially how our side channel attacks
Dialogue: 0,0:11:11.72,0:11:16.16,Default,,0000,0000,0000,,are going to work. If the non-secure code\Nis going to monitor these shared hardware
Dialogue: 0,0:11:16.16,0:11:23.05,Default,,0000,0000,0000,,resources for state changes that reflect\Nthe behavior of the secure code. Now we've
Dialogue: 0,0:11:23.05,0:11:27.90,Default,,0000,0000,0000,,all talked about how Intel and SGX address\Nthe problem of memory management and who's
Dialogue: 0,0:11:27.90,0:11:33.40,Default,,0000,0000,0000,,responsible for making sure that those\Nattacks don't work on SGX. So what do they
Dialogue: 0,0:11:33.40,0:11:37.05,Default,,0000,0000,0000,,have to say on how they protect against\Nthese side channel attacks and attacks on
Dialogue: 0,0:11:37.05,0:11:45.49,Default,,0000,0000,0000,,this shared cache hardware? They don't..\Nat all. They essentially say "we do not
Dialogue: 0,0:11:45.49,0:11:48.93,Default,,0000,0000,0000,,consider this part of our threat model. It\Nis up to the developer to implement the
Dialogue: 0,0:11:48.93,0:11:53.53,Default,,0000,0000,0000,,protections needed to protect against\Nthese side-channel attacks". Which is
Dialogue: 0,0:11:53.53,0:11:56.77,Default,,0000,0000,0000,,great news for us because these side\Nchannel attacks can be very powerful and
Dialogue: 0,0:11:56.77,0:12:00.35,Default,,0000,0000,0000,,if there aren't any hardware features that\Nare necessarily stopping us from being
Dialogue: 0,0:12:00.35,0:12:06.91,Default,,0000,0000,0000,,able to accomplish our goal it makes us\Nthat more likely to succeed. So with that
Dialogue: 0,0:12:06.91,0:12:11.43,Default,,0000,0000,0000,,we can sort of take a step back from trust\Nzone industry acts and just take a look at
Dialogue: 0,0:12:11.43,0:12:14.96,Default,,0000,0000,0000,,cache attacks to make sure that we all\Nhave the same understanding of how the
Dialogue: 0,0:12:14.96,0:12:19.55,Default,,0000,0000,0000,,cache attacks will be applied to these\NTrusted Execution Environments. To start
Dialogue: 0,0:12:19.55,0:12:25.62,Default,,0000,0000,0000,,that let's go over a brief recap of how a\Ncache works. So caches are necessary in
Dialogue: 0,0:12:25.62,0:12:29.95,Default,,0000,0000,0000,,processors because accessing the main\Nmemory is slow. When you try to access
Dialogue: 0,0:12:29.95,0:12:34.08,Default,,0000,0000,0000,,something from the main memory it takes a\Nwhile to be read into the process. So the
Dialogue: 0,0:12:34.08,0:12:40.39,Default,,0000,0000,0000,,cache exists as sort of a layer to\Nremember what that information is so if
Dialogue: 0,0:12:40.39,0:12:45.04,Default,,0000,0000,0000,,the process ever needs information from\Nthat same address it just reloads it from
Dialogue: 0,0:12:45.04,0:12:49.70,Default,,0000,0000,0000,,the cache and that access is going to be\Nfast. So it really speeds up the memory
Dialogue: 0,0:12:49.70,0:12:55.81,Default,,0000,0000,0000,,access for repeated accesses to the same\Naddress. And then if we try to access a
Dialogue: 0,0:12:55.81,0:13:00.07,Default,,0000,0000,0000,,different address then that will also be\Nread into the cache, slowly at first but
Dialogue: 0,0:13:00.07,0:13:06.72,Default,,0000,0000,0000,,then quickly for repeated accesses and so\Non and so forth. Now as you can probably
Dialogue: 0,0:13:06.72,0:13:10.97,Default,,0000,0000,0000,,tell from all of these examples the memory\Nblocks have been moving horizontally
Dialogue: 0,0:13:10.97,0:13:15.65,Default,,0000,0000,0000,,they've always been staying in the same\Nrow. And that is reflective of the idea of
Dialogue: 0,0:13:15.65,0:13:20.36,Default,,0000,0000,0000,,sets in a cache. So there are a number of\Ndifferent set IDs and that corresponds to
Dialogue: 0,0:13:20.36,0:13:24.19,Default,,0000,0000,0000,,the different rows in this diagram. So for\Nour example there are four different set
Dialogue: 0,0:13:24.19,0:13:30.89,Default,,0000,0000,0000,,IDs and each address in the main memory\Nmaps to a different set ID. So that
Dialogue: 0,0:13:30.89,0:13:35.10,Default,,0000,0000,0000,,address in main memory will only go into\Nthat location in the cache with the same
Dialogue: 0,0:13:35.10,0:13:39.73,Default,,0000,0000,0000,,set ID so it will only travel along those\Nrows. So that means if you have two
Dialogue: 0,0:13:39.73,0:13:43.41,Default,,0000,0000,0000,,different blocks of memory that mapped to\Ndifferent set IDs they're not going to
Dialogue: 0,0:13:43.41,0:13:48.90,Default,,0000,0000,0000,,interfere with each other in the cache.\NBut that raises the question "what about
Dialogue: 0,0:13:48.90,0:13:53.31,Default,,0000,0000,0000,,two memory blocks that do map to the same\Nset ID?". Well if there's room in the
Dialogue: 0,0:13:53.31,0:13:58.76,Default,,0000,0000,0000,,cache then the same thing will happen as\Nbefore: those memory contents will be
Dialogue: 0,0:13:58.76,0:14:03.77,Default,,0000,0000,0000,,loaded into the cache and then retrieved\Nfrom the cache for future accesses. And
Dialogue: 0,0:14:03.77,0:14:08.11,Default,,0000,0000,0000,,the number of possible entries for a\Nparticular set ID within a cache is called
Dialogue: 0,0:14:08.11,0:14:11.80,Default,,0000,0000,0000,,the associativity. And on this diagram\Nthat's represented by the number of
Dialogue: 0,0:14:11.80,0:14:16.82,Default,,0000,0000,0000,,columns in the cache. So we will call our\Ncache in this example a 2-way set-
Dialogue: 0,0:14:16.82,0:14:22.35,Default,,0000,0000,0000,,associative cache. Now the next question\Nis "what happens if you try to read a
Dialogue: 0,0:14:22.35,0:14:27.05,Default,,0000,0000,0000,,memory address that maps the same set ID\Nbut all of those entries within that said ID
Dialogue: 0,0:14:27.05,0:14:32.53,Default,,0000,0000,0000,,within the cache are full?". Well one of\Nthose entries is chosen, it's evicted from
Dialogue: 0,0:14:32.53,0:14:38.73,Default,,0000,0000,0000,,the cache, the new memory is read in and\Nthen that's fed to the process. So it
Dialogue: 0,0:14:38.73,0:14:43.78,Default,,0000,0000,0000,,doesn't really matter how the cache entry\Nis chosen that you're evicting for the
Dialogue: 0,0:14:43.78,0:14:47.96,Default,,0000,0000,0000,,purpose of the presentation you can just\Nassume that it's random. But the important
Dialogue: 0,0:14:47.96,0:14:51.90,Default,,0000,0000,0000,,thing is that if you try to access that\Nsame memory that was evicted before you're
Dialogue: 0,0:14:51.90,0:14:55.69,Default,,0000,0000,0000,,not going to have to wait for that time\Npenalty for that to be reloaded into the
Dialogue: 0,0:14:55.69,0:15:01.33,Default,,0000,0000,0000,,cache and read into the process. So those\Nare caches in a nutshell in particularly
Dialogue: 0,0:15:01.33,0:15:05.75,Default,,0000,0000,0000,,set associative caches, we can begin\Nlooking at the different types of cache
Dialogue: 0,0:15:05.75,0:15:09.32,Default,,0000,0000,0000,,attacks. So for a cache attack we have two\Ndifferent processes we have an attacker
Dialogue: 0,0:15:09.32,0:15:13.78,Default,,0000,0000,0000,,process and a victim process. For this\Ntype of attack that we're considering both
Dialogue: 0,0:15:13.78,0:15:17.29,Default,,0000,0000,0000,,of them share the same underlying code so\Nthey're trying to access the same
Dialogue: 0,0:15:17.29,0:15:21.83,Default,,0000,0000,0000,,resources which could be the case if you\Nhave page deduplication in virtual
Dialogue: 0,0:15:21.83,0:15:26.01,Default,,0000,0000,0000,,machines or if you have copy-on-write\Nmechanisms for shared code and shared
Dialogue: 0,0:15:26.01,0:15:31.65,Default,,0000,0000,0000,,libraries. But the point is that they\Nshare the same underlying memory. Now the
Dialogue: 0,0:15:31.65,0:15:35.66,Default,,0000,0000,0000,,Flush and Reload Attack works in two\Nstages for the attacker. The attacker
Dialogue: 0,0:15:35.66,0:15:39.42,Default,,0000,0000,0000,,first starts by flushing out the cache.\NThey flush each and every addresses in the
Dialogue: 0,0:15:39.42,0:15:44.31,Default,,0000,0000,0000,,cache so the cache is just empty. Then the\Nattacker let's the victim executes for a
Dialogue: 0,0:15:44.31,0:15:48.77,Default,,0000,0000,0000,,small amount of time so the victim might\Nread on an address from main memory
Dialogue: 0,0:15:48.77,0:15:53.49,Default,,0000,0000,0000,,loading that into the cache and then the\Nsecond stage of the attack is the reload
Dialogue: 0,0:15:53.49,0:15:58.10,Default,,0000,0000,0000,,phase. In the reload phase the attacker\Ntries to load different memory addresses
Dialogue: 0,0:15:58.10,0:16:04.17,Default,,0000,0000,0000,,from main memory and see if those entries\Nare in the cache or not. Here the attacker
Dialogue: 0,0:16:04.17,0:16:09.38,Default,,0000,0000,0000,,will first try to load address 0 and see\Nthat because it takes a long time to read
Dialogue: 0,0:16:09.38,0:16:14.43,Default,,0000,0000,0000,,the contents of address 0 the attacker can\Ninfer that address 0 was not part of the
Dialogue: 0,0:16:14.43,0:16:17.50,Default,,0000,0000,0000,,cache which makes sense because the\Nattacker flushed it from the cache in the
Dialogue: 0,0:16:17.50,0:16:23.33,Default,,0000,0000,0000,,first stage. The attacker then tries to\Nread the memory at address 1 and sees that
Dialogue: 0,0:16:23.33,0:16:29.09,Default,,0000,0000,0000,,this operation is fast so the attacker\Ninfers that the contents of address 1 are
Dialogue: 0,0:16:29.09,0:16:32.86,Default,,0000,0000,0000,,in the cache and because the attacker\Nflushed everything from the cache before
Dialogue: 0,0:16:32.86,0:16:37.12,Default,,0000,0000,0000,,the victim executed, the attacker then\Nconcludes that the victim is responsible
Dialogue: 0,0:16:37.12,0:16:42.54,Default,,0000,0000,0000,,for bringing address 1 into the cache.\NThis Flush+Reload attack reveals which
Dialogue: 0,0:16:42.54,0:16:47.37,Default,,0000,0000,0000,,memory addresses the victim accesses\Nduring that small slice of time. Then
Dialogue: 0,0:16:47.37,0:16:50.97,Default,,0000,0000,0000,,after that reload phase, the attack\Nrepeats so the attacker flushes again
Dialogue: 0,0:16:50.97,0:16:57.74,Default,,0000,0000,0000,,let's the victim execute, reloads again\Nand so on. There's also a variant on the
Dialogue: 0,0:16:57.74,0:17:01.05,Default,,0000,0000,0000,,Flush+Reload attack that's called the\NFlush+Flush attack which I'm not going to
Dialogue: 0,0:17:01.05,0:17:05.57,Default,,0000,0000,0000,,go into the details of, but essentially\Nit's the same idea. But instead of using
Dialogue: 0,0:17:05.57,0:17:08.98,Default,,0000,0000,0000,,load instructions to determine whether or\Nnot a piece of memory is in the cache or
Dialogue: 0,0:17:08.98,0:17:13.72,Default,,0000,0000,0000,,not, it uses flush instructions because\Nflush instructions will take longer if
Dialogue: 0,0:17:13.72,0:17:19.14,Default,,0000,0000,0000,,something is in the cache already. The\Nimportant thing is that both the
Dialogue: 0,0:17:19.14,0:17:22.82,Default,,0000,0000,0000,,Flush+Reload attack and the Flush+Flush\Nattack rely on the attacker and the victim
Dialogue: 0,0:17:22.82,0:17:27.03,Default,,0000,0000,0000,,sharing the same memory. But this isn't\Nalways the case so we need to consider
Dialogue: 0,0:17:27.03,0:17:30.81,Default,,0000,0000,0000,,what happens when the attacker and the\Nvictim do not share memory. For this we
Dialogue: 0,0:17:30.81,0:17:35.67,Default,,0000,0000,0000,,have the Prime+Probe attack. The\NPrime+Probe attack once again works in two
Dialogue: 0,0:17:35.67,0:17:40.38,Default,,0000,0000,0000,,separate stages. In the first stage the\Nattacker prime's the cache by reading all
Dialogue: 0,0:17:40.38,0:17:44.40,Default,,0000,0000,0000,,the attacker memory into the cache and\Nthen the attacker lets the victim execute
Dialogue: 0,0:17:44.40,0:17:49.75,Default,,0000,0000,0000,,for a small amount of time. So no matter\Nwhat the victim accesses from main memory
Dialogue: 0,0:17:49.75,0:17:54.46,Default,,0000,0000,0000,,since the cache is full of the attacker\Ndata, one of those attacker entries will
Dialogue: 0,0:17:54.46,0:17:59.19,Default,,0000,0000,0000,,be replaced by a victim entry. Then in the\Nsecond phase of the attack, during the
Dialogue: 0,0:17:59.19,0:18:03.53,Default,,0000,0000,0000,,probe phase, the attacker checks the\Ndifferent cache entries for particular set
Dialogue: 0,0:18:03.53,0:18:08.96,Default,,0000,0000,0000,,IDs and sees if all of the attacker\Nentries are still in the cache. So maybe
Dialogue: 0,0:18:08.96,0:18:13.44,Default,,0000,0000,0000,,our attacker is curious about the last set\NID, the bottom row, so the attacker first
Dialogue: 0,0:18:13.44,0:18:18.09,Default,,0000,0000,0000,,tries to load the memory at address 3 and\Nbecause this operation is fast the
Dialogue: 0,0:18:18.09,0:18:23.00,Default,,0000,0000,0000,,attacker knows that address 3 is in the\Ncache. The attacker tries the same thing
Dialogue: 0,0:18:23.00,0:18:28.16,Default,,0000,0000,0000,,with address 7, sees that this operation\Nis slow and infers that at some point
Dialogue: 0,0:18:28.16,0:18:33.28,Default,,0000,0000,0000,,address 7 was evicted from the cache so\Nthe attacker knows that something had to
Dialogue: 0,0:18:33.28,0:18:37.49,Default,,0000,0000,0000,,evicted from the cache and it had to be\Nfrom the victim so the attacker concludes
Dialogue: 0,0:18:37.49,0:18:42.84,Default,,0000,0000,0000,,that the victim accessed something in that\Nlast set ID and that bottom row. The
Dialogue: 0,0:18:42.84,0:18:47.23,Default,,0000,0000,0000,,attacker doesn't know if it was the\Ncontents of address 11 or the contents of
Dialogue: 0,0:18:47.23,0:18:51.26,Default,,0000,0000,0000,,address 15 or even what those contents\Nare, but the attacker has a good idea of
Dialogue: 0,0:18:51.26,0:18:57.09,Default,,0000,0000,0000,,which set ID it was. So, the good things,\Nthe important things to remember about
Dialogue: 0,0:18:57.09,0:19:01.18,Default,,0000,0000,0000,,cache attacks is that caches are very\Nimportant, they're crucial for performance
Dialogue: 0,0:19:01.18,0:19:06.06,Default,,0000,0000,0000,,on processors, they give a huge speed\Nboost and there's a huge time difference
Dialogue: 0,0:19:06.06,0:19:11.57,Default,,0000,0000,0000,,between having a cache and not having a\Ncache for your executables. But the
Dialogue: 0,0:19:11.57,0:19:16.08,Default,,0000,0000,0000,,downside to this is that big time\Ndifference also allows the attacker to
Dialogue: 0,0:19:16.08,0:19:21.62,Default,,0000,0000,0000,,infer information about how the victim is\Nusing the cache. We're able to use these
Dialogue: 0,0:19:21.62,0:19:24.43,Default,,0000,0000,0000,,cache attacks in the two different\Nscenarios of, where memory is shared, in
Dialogue: 0,0:19:24.43,0:19:28.23,Default,,0000,0000,0000,,the case of the Flush+Reload and\NFlush+Flush attacks and in the case where
Dialogue: 0,0:19:28.23,0:19:31.74,Default,,0000,0000,0000,,memory is not shared, in the case of the\NPrime+Probe attack. And finally the
Dialogue: 0,0:19:31.74,0:19:36.66,Default,,0000,0000,0000,,important thing to keep in mind is that,\Nfor these cache attacks, we know where the
Dialogue: 0,0:19:36.66,0:19:40.48,Default,,0000,0000,0000,,victim is looking, but we don't know what\Nthey see. So we don't know the contents of
Dialogue: 0,0:19:40.48,0:19:44.36,Default,,0000,0000,0000,,the memory that the victim is actually\Nseeing, we just know the location and the
Dialogue: 0,0:19:44.36,0:19:51.55,Default,,0000,0000,0000,,addresses. So, what does an example trace\Nof these attacks look like? Well, there's
Dialogue: 0,0:19:51.55,0:19:56.45,Default,,0000,0000,0000,,an easy way to represent these as two-\Ndimensional images. So in this image, we
Dialogue: 0,0:19:56.45,0:20:01.76,Default,,0000,0000,0000,,have our horizontal axis as time, so each\Ncolumn in this image represents a
Dialogue: 0,0:20:01.76,0:20:07.16,Default,,0000,0000,0000,,different time slice, a different\Niteration of the Prime measure and Probe.
Dialogue: 0,0:20:07.16,0:20:11.44,Default,,0000,0000,0000,,So, then we also have the vertical access\Nwhich is the different set IDs, which is
Dialogue: 0,0:20:11.44,0:20:18.36,Default,,0000,0000,0000,,the location that's accessed by the victim\Nprocess, and then here a pixel is white if
Dialogue: 0,0:20:18.36,0:20:24.16,Default,,0000,0000,0000,,the victim accessed that set ID during\Nthat time slice. So, as you look from left
Dialogue: 0,0:20:24.16,0:20:28.14,Default,,0000,0000,0000,,to right as time moves forward, you can\Nsort of see the changes in the patterns of
Dialogue: 0,0:20:28.14,0:20:34.07,Default,,0000,0000,0000,,the memory accesses made by the victim\Nprocess. Now, for this particular example
Dialogue: 0,0:20:34.07,0:20:39.86,Default,,0000,0000,0000,,the trace is captured on an execution of\NAES repeated several times, an AES
Dialogue: 0,0:20:39.86,0:20:44.52,Default,,0000,0000,0000,,encryption repeated about 20 times. And\Nyou can tell that this is a repeated
Dialogue: 0,0:20:44.52,0:20:49.07,Default,,0000,0000,0000,,action because you see the same repeated\Nmemory access patterns in the data, you
Dialogue: 0,0:20:49.07,0:20:55.32,Default,,0000,0000,0000,,see the same structures repeated over and\Nover. So, you know that this is reflecting
Dialogue: 0,0:20:55.32,0:21:00.75,Default,,0000,0000,0000,,at what's going on throughout time, but\Nwhat does it have to do with AES itself?
Dialogue: 0,0:21:00.75,0:21:05.95,Default,,0000,0000,0000,,Well, if we take the same trace with the\Nsame settings, but a different key, we see
Dialogue: 0,0:21:05.95,0:21:11.59,Default,,0000,0000,0000,,that there is a different memory access\Npattern with different repetition within
Dialogue: 0,0:21:11.59,0:21:18.20,Default,,0000,0000,0000,,the trace. So, only the key changed, the\Ncode didn't change. So, even though we're
Dialogue: 0,0:21:18.20,0:21:22.13,Default,,0000,0000,0000,,not able to read the contents of the key\Ndirectly using this cache attack, we know
Dialogue: 0,0:21:22.13,0:21:25.61,Default,,0000,0000,0000,,that the key is changing these memory\Naccess patterns, and if we can see these
Dialogue: 0,0:21:25.61,0:21:30.85,Default,,0000,0000,0000,,memory access patterns, then we can infer\Nthe key. So, that's the essential idea: we
Dialogue: 0,0:21:30.85,0:21:35.38,Default,,0000,0000,0000,,want to make these images as clear as\Npossible and as descriptive as possible so
Dialogue: 0,0:21:35.38,0:21:42.28,Default,,0000,0000,0000,,we have the best chance of learning what\Nthose secrets are. And we can define the
Dialogue: 0,0:21:42.28,0:21:47.39,Default,,0000,0000,0000,,metrics for what makes these cache attacks\Npowerful in a few different ways. So, the
Dialogue: 0,0:21:47.39,0:21:51.76,Default,,0000,0000,0000,,three ways we'll be looking at are spatial\Nresolution, temporal resolution and noise.
Dialogue: 0,0:21:51.76,0:21:56.30,Default,,0000,0000,0000,,So, spatial resolution refers to how\Naccurately we can determine the where. If
Dialogue: 0,0:21:56.30,0:22:00.51,Default,,0000,0000,0000,,we know that the victim access to memory\Naddress within 1,000 bytes, that's
Dialogue: 0,0:22:00.51,0:22:06.82,Default,,0000,0000,0000,,obviously not as powerful as knowing where\Nthey accessed within 512 bytes. Temporal
Dialogue: 0,0:22:06.82,0:22:12.05,Default,,0000,0000,0000,,resolution is similar, where we want to\Nknow the order of what accesses the victim
Dialogue: 0,0:22:12.05,0:22:17.77,Default,,0000,0000,0000,,made. So if that time slice during our\Nattack is 1 millisecond, we're going to
Dialogue: 0,0:22:17.77,0:22:22.14,Default,,0000,0000,0000,,get much better ordering information on\Nthose memory access than we would get if
Dialogue: 0,0:22:22.14,0:22:27.35,Default,,0000,0000,0000,,we only saw all the memory accesses over\Nthe course of one second. So the shorter
Dialogue: 0,0:22:27.35,0:22:32.16,Default,,0000,0000,0000,,that time slice, the better the temporal\Nresolution, the longer our picture will be
Dialogue: 0,0:22:32.16,0:22:37.79,Default,,0000,0000,0000,,on the horizontal access, and the clearer\Nof an image of the cache that we'll see.
Dialogue: 0,0:22:37.79,0:22:41.42,Default,,0000,0000,0000,,And the last metric to evaluate our\Nattacks on is noise and that reflects how
Dialogue: 0,0:22:41.42,0:22:46.07,Default,,0000,0000,0000,,accurately our measurements reflect the\Ntrue state of the cache. So, right now
Dialogue: 0,0:22:46.07,0:22:49.95,Default,,0000,0000,0000,,we've been using time and data to infer\Nwhether or not an item was in the cache or
Dialogue: 0,0:22:49.95,0:22:54.34,Default,,0000,0000,0000,,not, but this is a little bit noisy. It's\Npossible that we'll have false positives
Dialogue: 0,0:22:54.34,0:22:57.37,Default,,0000,0000,0000,,or false negatives, so we want to keep\Nthat in mind as we look at the different
Dialogue: 0,0:22:57.37,0:23:03.08,Default,,0000,0000,0000,,attacks. So, that's essentially cache\Nattacks, and then, in a nutshell and
Dialogue: 0,0:23:03.08,0:23:06.52,Default,,0000,0000,0000,,that's all you really need to understand\Nin order to understand these attacks as
Dialogue: 0,0:23:06.52,0:23:11.39,Default,,0000,0000,0000,,they've been implemented on Trusted\NExecution Environments. And the first
Dialogue: 0,0:23:11.39,0:23:14.51,Default,,0000,0000,0000,,particular attack that we're going to be\Nlooking at is called a Controlled-Channel
Dialogue: 0,0:23:14.51,0:23:19.89,Default,,0000,0000,0000,,Attack on SGX, and this attack isn't\Nnecessarily a cache attack, but we can
Dialogue: 0,0:23:19.89,0:23:23.77,Default,,0000,0000,0000,,analyze it in the same way that we analyze\Nthe cache attacks. So, it's still useful
Dialogue: 0,0:23:23.77,0:23:30.94,Default,,0000,0000,0000,,to look at. Now, if you remember how\Nmemory management occurs with SGX, we know
Dialogue: 0,0:23:30.94,0:23:36.21,Default,,0000,0000,0000,,that if a page fault occurs during SGX\NEnclave code execution, that page fault is
Dialogue: 0,0:23:36.21,0:23:43.02,Default,,0000,0000,0000,,handled by the kernel. So, the kernel has\Nto know which page the Enclave needs to be
Dialogue: 0,0:23:43.02,0:23:48.05,Default,,0000,0000,0000,,paged in. The kernel already gets some\Ninformation about what the Enclave is
Dialogue: 0,0:23:48.05,0:23:54.79,Default,,0000,0000,0000,,looking at. Now, in the Controlled-Channel\Nattack, there's a, what the attacker does
Dialogue: 0,0:23:54.79,0:23:59.84,Default,,0000,0000,0000,,from the non-trusted OS is the attacker\Npages almost every other page from the
Dialogue: 0,0:23:59.84,0:24:05.26,Default,,0000,0000,0000,,Enclave out of memory. So no matter\Nwhatever page that Enclave tries to
Dialogue: 0,0:24:05.26,0:24:09.77,Default,,0000,0000,0000,,access, it's very likely to cause a page\Nfault, which will be redirected to the
Dialogue: 0,0:24:09.77,0:24:14.15,Default,,0000,0000,0000,,non-trusted OS, where the non-trusted OS\Ncan record it, page out any other pages
Dialogue: 0,0:24:14.15,0:24:20.43,Default,,0000,0000,0000,,and continue execution. So, the OS\Nessentially gets a list of sequential page
Dialogue: 0,0:24:20.43,0:24:26.26,Default,,0000,0000,0000,,accesses made by the SGX Enclaves, all by\Ncapturing the page fault handler. This is
Dialogue: 0,0:24:26.26,0:24:29.67,Default,,0000,0000,0000,,a very general attack, you don't need to\Nknow what's going on in the Enclave in
Dialogue: 0,0:24:29.67,0:24:33.46,Default,,0000,0000,0000,,order to pull this off. You just load up\Nan arbitrary Enclave and you're able to
Dialogue: 0,0:24:33.46,0:24:40.72,Default,,0000,0000,0000,,see which pages that Enclave is trying to\Naccess. So, how does it do on our metrics?
Dialogue: 0,0:24:40.72,0:24:44.27,Default,,0000,0000,0000,,First of all, this spatial resolution is\Nnot great. We can only see where the
Dialogue: 0,0:24:44.27,0:24:50.47,Default,,0000,0000,0000,,victim is accessing within 4096 bytes or\Nthe size of a full page because SGX
Dialogue: 0,0:24:50.47,0:24:55.52,Default,,0000,0000,0000,,obscures the offset into the page where\Nthe page fault occurs. The temporal
Dialogue: 0,0:24:55.52,0:24:58.76,Default,,0000,0000,0000,,resolution is good but not great, because\Neven though we're able to see any
Dialogue: 0,0:24:58.76,0:25:04.45,Default,,0000,0000,0000,,sequential accesses to different pages\Nwe're not able to see sequential accesses
Dialogue: 0,0:25:04.45,0:25:09.97,Default,,0000,0000,0000,,to the same page because we need to keep\Nthat same page paged-in while we let our
Dialogue: 0,0:25:09.97,0:25:15.49,Default,,0000,0000,0000,,SGX Enclave run for that small time slice.\NSo temporal resolution is good but not
Dialogue: 0,0:25:15.49,0:25:22.44,Default,,0000,0000,0000,,perfect. But the noise is, there is no\Nnoise in this attack because no matter
Dialogue: 0,0:25:22.44,0:25:26.15,Default,,0000,0000,0000,,where the page fault occurs, the untrusted\Noperating system is going to capture that
Dialogue: 0,0:25:26.15,0:25:30.18,Default,,0000,0000,0000,,page fault and is going to handle it. So,\Nit's very low noise, not great spatial
Dialogue: 0,0:25:30.18,0:25:37.49,Default,,0000,0000,0000,,resolution but overall still a powerful\Nattack. But we still want to improve on
Dialogue: 0,0:25:37.49,0:25:40.70,Default,,0000,0000,0000,,that spatial resolution, we want to be\Nable to see what the Enclave is doing that
Dialogue: 0,0:25:40.70,0:25:45.97,Default,,0000,0000,0000,,greater than a resolution of a one page of\Nfour kilobytes. So that's exactly what the
Dialogue: 0,0:25:45.97,0:25:50.18,Default,,0000,0000,0000,,CacheZoom paper does, and instead of\Ninterrupting the SGX Enclave execution
Dialogue: 0,0:25:50.18,0:25:55.37,Default,,0000,0000,0000,,with page faults, it uses timer\Ninterrupts. Because the untrusted
Dialogue: 0,0:25:55.37,0:25:59.28,Default,,0000,0000,0000,,operating system is able to schedule when\Ntimer interrupts occur, so it's able to
Dialogue: 0,0:25:59.28,0:26:03.32,Default,,0000,0000,0000,,schedule them at very tight intervals, so\Nit's able to get that small and tight
Dialogue: 0,0:26:03.32,0:26:08.55,Default,,0000,0000,0000,,temporal resolution. And essentially what\Nhappens in between is this timer
Dialogue: 0,0:26:08.55,0:26:13.41,Default,,0000,0000,0000,,interrupts fires, the untrusted operating\Nsystem runs the Prime+Probe attack code in
Dialogue: 0,0:26:13.41,0:26:18.24,Default,,0000,0000,0000,,this case, and resumes execution of the\Nonclick process, and this repeats. So this
Dialogue: 0,0:26:18.24,0:26:24.55,Default,,0000,0000,0000,,is a Prime+Probe attack on the L1 data\Ncache. So, this attack let's you see what
Dialogue: 0,0:26:24.55,0:26:30.53,Default,,0000,0000,0000,,data The Enclave is looking at. Now, this\Nattack could be easily modified to use the
Dialogue: 0,0:26:30.53,0:26:36.00,Default,,0000,0000,0000,,L1 instruction cache, so in that case you\Nlearn which instructions The Enclave is
Dialogue: 0,0:26:36.00,0:26:41.42,Default,,0000,0000,0000,,executing. And overall this is an even\Nmore powerful attack than the Control-
Dialogue: 0,0:26:41.42,0:26:46.43,Default,,0000,0000,0000,,Channel attack. If we look at the metrics,\Nwe can see that the spatial resolution is
Dialogue: 0,0:26:46.43,0:26:50.36,Default,,0000,0000,0000,,a lot better, now we're looking at spatial\Nresolution of 64 bytes or the size of an
Dialogue: 0,0:26:50.36,0:26:55.37,Default,,0000,0000,0000,,individual line. The temporal resolution\Nis very good, it's "almost unlimited", to
Dialogue: 0,0:26:55.37,0:27:00.25,Default,,0000,0000,0000,,quote the paper, because the untrusted\Noperating system has the privilege to keep
Dialogue: 0,0:27:00.25,0:27:05.18,Default,,0000,0000,0000,,scheduling those time interrupts closer\Nand closer together until it's able to
Dialogue: 0,0:27:05.18,0:27:10.26,Default,,0000,0000,0000,,capture very small time slices of the\Nvictim process .And the noise itself is
Dialogue: 0,0:27:10.26,0:27:14.56,Default,,0000,0000,0000,,low, we're still using a cycle counter to\Nmeasure the time it takes to load memory
Dialogue: 0,0:27:14.56,0:27:20.63,Default,,0000,0000,0000,,in and out of the cache, but it's, it's\Nuseful, the chances of having a false
Dialogue: 0,0:27:20.63,0:27:26.81,Default,,0000,0000,0000,,positive or false negative are low, so the\Nnoise is low as well. Now, we can also
Dialogue: 0,0:27:26.81,0:27:31.13,Default,,0000,0000,0000,,look at Trust Zone attacks, because so far\Nthe attacks that we've looked at, the
Dialogue: 0,0:27:31.13,0:27:35.13,Default,,0000,0000,0000,,passive attacks, have been against SGX and\Nthose attacks on SGX have been pretty
Dialogue: 0,0:27:35.13,0:27:40.67,Default,,0000,0000,0000,,powerful. So, what are the published\Nattacks on Trust Zone? Well, there's one
Dialogue: 0,0:27:40.67,0:27:44.99,Default,,0000,0000,0000,,called TruSpy, which is kind of similar in\Nconcept to the CacheZoom attack that we
Dialogue: 0,0:27:44.99,0:27:51.63,Default,,0000,0000,0000,,just looked at on SGX. It's once again a\NPrime+probe attack on the L1 data cache,
Dialogue: 0,0:27:51.63,0:27:57.13,Default,,0000,0000,0000,,and the difference here is that instead of\Ninterrupting the victim code execution
Dialogue: 0,0:27:57.13,0:28:04.46,Default,,0000,0000,0000,,multiple times, the TruSpy attack does the\Nprime step, does the full AES encryption,
Dialogue: 0,0:28:04.46,0:28:08.54,Default,,0000,0000,0000,,and then does the probe step. And the\Nreason they do this, is because as they
Dialogue: 0,0:28:08.54,0:28:13.33,Default,,0000,0000,0000,,say, the secure world is protected, and is\Nnot interruptible in the same way that SGX
Dialogue: 0,0:28:13.33,0:28:20.69,Default,,0000,0000,0000,,is interruptable. But even despite this,\Njust having one measurement per execution,
Dialogue: 0,0:28:20.69,0:28:24.94,Default,,0000,0000,0000,,the TruSpy authors were able to use some\Nstatistics to still recover the AES key
Dialogue: 0,0:28:24.94,0:28:30.46,Default,,0000,0000,0000,,from that noise. And their methods were so\Npowerful, they are able to do this from an
Dialogue: 0,0:28:30.46,0:28:34.54,Default,,0000,0000,0000,,unapproved application in user land, so\Nthey don't even need to be running within
Dialogue: 0,0:28:34.54,0:28:39.82,Default,,0000,0000,0000,,the kernel in order to be able to pull off\Nthis attack. So, how does this attack
Dialogue: 0,0:28:39.82,0:28:43.36,Default,,0000,0000,0000,,measure up? The spatial resolution is once\Nagain 64 bytes because that's the size of
Dialogue: 0,0:28:43.36,0:28:48.56,Default,,0000,0000,0000,,a cache line on this processor, and the\Ntemporal resolution is, is pretty poor
Dialogue: 0,0:28:48.56,0:28:54.19,Default,,0000,0000,0000,,here, because we only get one measurement\Nper execution of the AES encryption. This
Dialogue: 0,0:28:54.19,0:28:58.70,Default,,0000,0000,0000,,is also a particularly noisy attack\Nbecause we're making the measurements from
Dialogue: 0,0:28:58.70,0:29:02.66,Default,,0000,0000,0000,,the user land, but even if we make the\Nmeasurements from the kernel, we're still
Dialogue: 0,0:29:02.66,0:29:05.79,Default,,0000,0000,0000,,going to have the same issues of false\Npositives and false negatives associated
Dialogue: 0,0:29:05.79,0:29:12.47,Default,,0000,0000,0000,,with using a cycle counter to measure\Nmembership in a cache. So, we'd like to
Dialogue: 0,0:29:12.47,0:29:16.39,Default,,0000,0000,0000,,improve this a little bit. We'd like to\Nimprove the temporal resolution, so we
Dialogue: 0,0:29:16.39,0:29:20.75,Default,,0000,0000,0000,,have the power of the cache attack to be a\Nlittle bit closer on TrustZone, as it is
Dialogue: 0,0:29:20.75,0:29:27.15,Default,,0000,0000,0000,,on SGX. So, we want to improve that\Ntemporal resolution. Let's dig into that
Dialogue: 0,0:29:27.15,0:29:30.55,Default,,0000,0000,0000,,statement a little bit, that the secure\Nworld is protected and not interruptable.
Dialogue: 0,0:29:30.55,0:29:36.50,Default,,0000,0000,0000,,And to do, this we go back to this diagram\Nof ARMv8 and how that TrustZone is set up.
Dialogue: 0,0:29:36.50,0:29:41.49,Default,,0000,0000,0000,,So, it is true that when an interrupt\Noccurs, it is directed to the monitor and,
Dialogue: 0,0:29:41.49,0:29:45.53,Default,,0000,0000,0000,,because the monitor operates in the secure\Nworld, if we interrupt secure code that's
Dialogue: 0,0:29:45.53,0:29:49.08,Default,,0000,0000,0000,,running an exception level 0, we're just\Ngoing to end up running secure code an
Dialogue: 0,0:29:49.08,0:29:54.24,Default,,0000,0000,0000,,exception level 3. So, this doesn't\Nnecessarily get us anything. I think,
Dialogue: 0,0:29:54.24,0:29:57.88,Default,,0000,0000,0000,,that's what the author's mean by saying\Nthat it's protected against this. Just by
Dialogue: 0,0:29:57.88,0:30:02.78,Default,,0000,0000,0000,,setting an interrupt, we don't have a\Nway to redirect our flow to the non-
Dialogue: 0,0:30:02.78,0:30:08.19,Default,,0000,0000,0000,,trusted code. At least that's how it works\Nin theory. In practice, the Linux
Dialogue: 0,0:30:08.19,0:30:11.84,Default,,0000,0000,0000,,operating system, running in exception\Nlevel 1 in the non-secure world, kind of
Dialogue: 0,0:30:11.84,0:30:15.30,Default,,0000,0000,0000,,needs interrupts in order to be able to\Nwork, so if an interrupt occurs and it's
Dialogue: 0,0:30:15.30,0:30:18.12,Default,,0000,0000,0000,,being sent to the monitor, the monitor\Nwill just forward it right to the non-
Dialogue: 0,0:30:18.12,0:30:22.50,Default,,0000,0000,0000,,secure operating system. So, we have\Ninterrupts just the same way as we did in
Dialogue: 0,0:30:22.50,0:30:28.93,Default,,0000,0000,0000,,CacheZoom. And we can improve the\NTrustZone attacks by using this idea: We
Dialogue: 0,0:30:28.93,0:30:33.55,Default,,0000,0000,0000,,have 2 cores, where one core is running\Nthe secure code, the other core is running
Dialogue: 0,0:30:33.55,0:30:38.10,Default,,0000,0000,0000,,the non-secure code, and the non-secure\Ncode is sending interrupts to the secure-
Dialogue: 0,0:30:38.10,0:30:42.81,Default,,0000,0000,0000,,world core and that will give us that\Ninterleaving of attacker process and
Dialogue: 0,0:30:42.81,0:30:47.41,Default,,0000,0000,0000,,victim process that allow us to have a\Npowerful prime-and-probe attack. So, what
Dialogue: 0,0:30:47.41,0:30:51.14,Default,,0000,0000,0000,,does this look like? We have the attack\Ncore and the victim core. The attack core
Dialogue: 0,0:30:51.14,0:30:54.91,Default,,0000,0000,0000,,sends an interrupt to the victim core.\NThis interrupt is captured by the monitor,
Dialogue: 0,0:30:54.91,0:30:58.77,Default,,0000,0000,0000,,which passes it to the non-secure\Noperating system. The not-secure operating
Dialogue: 0,0:30:58.77,0:31:02.98,Default,,0000,0000,0000,,system transfers this to our attack code,\Nwhich runs the prime-and-probe attack.
Dialogue: 0,0:31:02.98,0:31:06.53,Default,,0000,0000,0000,,Then, we leave the interrupt, the\Nexecution within the victim code in the
Dialogue: 0,0:31:06.53,0:31:10.91,Default,,0000,0000,0000,,secure world resumes and we just repeat\Nthis over and over. So, now we have that
Dialogue: 0,0:31:10.91,0:31:16.69,Default,,0000,0000,0000,,interleaving of data... of the processes\Nof the attacker and the victim. So, now,
Dialogue: 0,0:31:16.69,0:31:22.69,Default,,0000,0000,0000,,instead of having a temporal resolution of\None measurement per execution, we once
Dialogue: 0,0:31:22.69,0:31:26.32,Default,,0000,0000,0000,,again have almost unlimited temporal\Nresolution, because we can just schedule
Dialogue: 0,0:31:26.32,0:31:32.23,Default,,0000,0000,0000,,when we send those interrupts from the\Nattacker core. Now, we'd also like to
Dialogue: 0,0:31:32.23,0:31:37.59,Default,,0000,0000,0000,,improve the noise measurements. The...\Nbecause if we can improve the noise, we'll
Dialogue: 0,0:31:37.59,0:31:42.16,Default,,0000,0000,0000,,get clearer pictures and we'll be able to\Ninfer those secrets more clearly. So, we
Dialogue: 0,0:31:42.16,0:31:45.72,Default,,0000,0000,0000,,can get some improvement by switching the\Nmeasurements from userland and starting to
Dialogue: 0,0:31:45.72,0:31:50.83,Default,,0000,0000,0000,,do those in the kernel, but again we have\Nthe cycle counters. So, what if, instead
Dialogue: 0,0:31:50.83,0:31:54.33,Default,,0000,0000,0000,,of using the cycle counter to measure\Nwhether or not something is in the cache,
Dialogue: 0,0:31:54.33,0:32:00.07,Default,,0000,0000,0000,,we use the other performance counters?\NBecause on ARMv8 platforms, there is a way
Dialogue: 0,0:32:00.07,0:32:03.77,Default,,0000,0000,0000,,to use performance counters to measure\Ndifferent events, such as cache hits and
Dialogue: 0,0:32:03.77,0:32:09.81,Default,,0000,0000,0000,,cache misses. So, these events and these\Nperformance monitors require privileged
Dialogue: 0,0:32:09.81,0:32:15.33,Default,,0000,0000,0000,,access in order to use, which, for this\Nattack, we do have. Now, in a typical
Dialogue: 0,0:32:15.33,0:32:18.78,Default,,0000,0000,0000,,cache text scenario we wouldn't have\Naccess to these performance monitors,
Dialogue: 0,0:32:18.78,0:32:22.26,Default,,0000,0000,0000,,which is why they haven't really been\Nexplored before, but in this weird
Dialogue: 0,0:32:22.26,0:32:25.25,Default,,0000,0000,0000,,scenario where we're attacking the less\Nprivileged code from the more privileged
Dialogue: 0,0:32:25.25,0:32:29.34,Default,,0000,0000,0000,,code, we do have access to these\Nperformance monitors and we can use these
Dialogue: 0,0:32:29.34,0:32:33.64,Default,,0000,0000,0000,,monitors during the probe step to get a\Nvery accurate count of whether or not a
Dialogue: 0,0:32:33.64,0:32:39.52,Default,,0000,0000,0000,,certain memory load caused a cache miss or\Na cache hit. So, we're able to essentially
Dialogue: 0,0:32:39.52,0:32:45.72,Default,,0000,0000,0000,,get rid of the different levels of noise.\NNow, one thing to point out is that maybe
Dialogue: 0,0:32:45.72,0:32:49.23,Default,,0000,0000,0000,,we'd like to use these ARMv8 performance\Ncounters in order to count the different
Dialogue: 0,0:32:49.23,0:32:53.73,Default,,0000,0000,0000,,events that are occurring in the secure\Nworld code. So, maybe we start the
Dialogue: 0,0:32:53.73,0:32:57.91,Default,,0000,0000,0000,,performance counters from the non-secure\Nworld, let the secure world run and then,
Dialogue: 0,0:32:57.91,0:33:01.67,Default,,0000,0000,0000,,when they secure world exits, we use the\Nnon-secure world to read these performance
Dialogue: 0,0:33:01.67,0:33:05.44,Default,,0000,0000,0000,,counters and maybe we'd like to see how\Nmany instructions the secure world
Dialogue: 0,0:33:05.44,0:33:09.02,Default,,0000,0000,0000,,executed or how many branch instructions\Nor how many arithmetic instructions or how
Dialogue: 0,0:33:09.02,0:33:13.18,Default,,0000,0000,0000,,many cache misses there were. But\Nunfortunately, ARMv8 took this into
Dialogue: 0,0:33:13.18,0:33:17.35,Default,,0000,0000,0000,,account and by default, performance\Ncounters that are started in the non-
Dialogue: 0,0:33:17.35,0:33:20.77,Default,,0000,0000,0000,,secure world will not measure events that\Nhappen in the secure world, which is
Dialogue: 0,0:33:20.77,0:33:24.57,Default,,0000,0000,0000,,smart; which is how it should be. And the\Nonly reason I bring this up is because
Dialogue: 0,0:33:24.57,0:33:29.32,Default,,0000,0000,0000,,that's not how it is an ARMv7. So, we go\Ninto a whole different talk with that,
Dialogue: 0,0:33:29.32,0:33:33.91,Default,,0000,0000,0000,,just exploring the different implications\Nof what that means, but I want to focus on
Dialogue: 0,0:33:33.91,0:33:39.23,Default,,0000,0000,0000,,ARMv8, because that's that's the newest of\Nthe new. So, we'll keep looking at that.
Dialogue: 0,0:33:39.23,0:33:42.54,Default,,0000,0000,0000,,So, we instrument the primary probe attack\Nto use these performance counters, so we
Dialogue: 0,0:33:42.54,0:33:46.51,Default,,0000,0000,0000,,can get a clear picture of what is and\Nwhat is not in the cache. And instead of
Dialogue: 0,0:33:46.51,0:33:52.40,Default,,0000,0000,0000,,having noisy measurements based on time,\Nwe have virtually no noise at all, because
Dialogue: 0,0:33:52.40,0:33:55.92,Default,,0000,0000,0000,,we get the truth straight from the\Nprocessor itself, whether or not we
Dialogue: 0,0:33:55.92,0:34:01.66,Default,,0000,0000,0000,,experience a cache miss. So, how do we\Nimplement these attacks, where do we go
Dialogue: 0,0:34:01.66,0:34:05.55,Default,,0000,0000,0000,,from here? We have all these ideas; we\Nhave ways to make these TrustZone attacks
Dialogue: 0,0:34:05.55,0:34:11.84,Default,,0000,0000,0000,,more powerful, but that's not worthwhile,\Nunless we actually implement them. So, the
Dialogue: 0,0:34:11.84,0:34:16.51,Default,,0000,0000,0000,,goal here is to implement these attacks on\NTrustZone and since typically the non-
Dialogue: 0,0:34:16.51,0:34:20.96,Default,,0000,0000,0000,,secure world operating system is based on\NLinux, we'll take that into account when
Dialogue: 0,0:34:20.96,0:34:25.36,Default,,0000,0000,0000,,making our implementation. So, we'll write\Na kernel module that uses these
Dialogue: 0,0:34:25.36,0:34:29.34,Default,,0000,0000,0000,,performance counters and these inner\Nprocessor interrupts, in order to actually
Dialogue: 0,0:34:29.34,0:34:33.18,Default,,0000,0000,0000,,accomplish these attacks; and we'll write\Nit in such a way that it's very
Dialogue: 0,0:34:33.18,0:34:37.30,Default,,0000,0000,0000,,generalizable. So you can take this kernel\Nmodule that's was written for one device
Dialogue: 0,0:34:37.30,0:34:41.65,Default,,0000,0000,0000,,-- in my case I did most of my attention\Non the Nexus 5x -- and it's very easy to
Dialogue: 0,0:34:41.65,0:34:46.74,Default,,0000,0000,0000,,transfer this module to any other Linux-\Nbased device that has a trust zone that has
Dialogue: 0,0:34:46.74,0:34:52.14,Default,,0000,0000,0000,,these shared caches, so it should be very\Neasy to port this over and to perform
Dialogue: 0,0:34:52.14,0:34:57.81,Default,,0000,0000,0000,,these same powerful cache attacks on\Ndifferent platforms. We can also do clever
Dialogue: 0,0:34:57.81,0:35:01.50,Default,,0000,0000,0000,,things based on the Linux operating\Nsystem, so that we limit that collection
Dialogue: 0,0:35:01.50,0:35:05.50,Default,,0000,0000,0000,,window to just when we're executing within\Nthe secure world, so we can align our
Dialogue: 0,0:35:05.50,0:35:10.58,Default,,0000,0000,0000,,traces a lot more easily that way. And the\Nend result is having a synchronized trace
Dialogue: 0,0:35:10.58,0:35:14.93,Default,,0000,0000,0000,,for each different attacks, because, since\Nwe've written in a modular way, we're able
Dialogue: 0,0:35:14.93,0:35:19.44,Default,,0000,0000,0000,,to run different attacks simultaneously.\NSo, maybe we're running one prime-and-
Dialogue: 0,0:35:19.44,0:35:23.05,Default,,0000,0000,0000,,probe attack on the L1 data cache, to\Nlearn where the victim is accessing
Dialogue: 0,0:35:23.05,0:35:27.05,Default,,0000,0000,0000,,memory, and we're simultaneously running\Nan attack on the L1 instruction cache, so
Dialogue: 0,0:35:27.05,0:35:33.91,Default,,0000,0000,0000,,we can see what instructions the victim is\Nexecuting. And these can be aligned. So,
Dialogue: 0,0:35:33.91,0:35:37.08,Default,,0000,0000,0000,,the tool that I've written is a\Ncombination of a kernel module which
Dialogue: 0,0:35:37.08,0:35:41.58,Default,,0000,0000,0000,,actually performs this attack, a userland\Nbinary which schedules these processes to
Dialogue: 0,0:35:41.58,0:35:45.86,Default,,0000,0000,0000,,different cores, and a GUI that will allow\Nyou to interact with this kernel module
Dialogue: 0,0:35:45.86,0:35:49.71,Default,,0000,0000,0000,,and rapidly start doing these cache\Nattacks for yourself and perform them
Dialogue: 0,0:35:49.71,0:35:56.86,Default,,0000,0000,0000,,against different processes and secure\Ncode and secure world code. So, the
Dialogue: 0,0:35:56.86,0:36:02.82,Default,,0000,0000,0000,,intention behind this tool is to be very\Ngeneralizable to make it very easy to use
Dialogue: 0,0:36:02.82,0:36:08.43,Default,,0000,0000,0000,,this platform for different devices and to\Nallow people way to, once again, quickly
Dialogue: 0,0:36:08.43,0:36:12.36,Default,,0000,0000,0000,,develop these attacks; and also to see if\Ntheir own code is vulnerable to these
Dialogue: 0,0:36:12.36,0:36:18.49,Default,,0000,0000,0000,,cache attacks, to see if their code has\Nthese secret dependent memory accesses.
Dialogue: 0,0:36:18.49,0:36:25.35,Default,,0000,0000,0000,,So, can we get even better... spatial\Nresolution? Right now, we're down to 64
Dialogue: 0,0:36:25.35,0:36:30.32,Default,,0000,0000,0000,,bytes and that's the size of a cache line,\Nwhich is the size of our shared hardware.
Dialogue: 0,0:36:30.32,0:36:35.51,Default,,0000,0000,0000,,And on SGX, we actually can get better\Nthan 64 bytes, based on something called a
Dialogue: 0,0:36:35.51,0:36:39.16,Default,,0000,0000,0000,,branch-shadowing attack. So, a branch-\Nshadowing attack takes advantage of
Dialogue: 0,0:36:39.16,0:36:42.73,Default,,0000,0000,0000,,something called the branch target buffer.\NAnd the branch target buffer is a
Dialogue: 0,0:36:42.73,0:36:48.49,Default,,0000,0000,0000,,structure that's used for branch\Nprediction. It's similar to a cache, but
Dialogue: 0,0:36:48.49,0:36:51.74,Default,,0000,0000,0000,,there's a key difference where the branch\Ntarget buffer doesn't compare the full
Dialogue: 0,0:36:51.74,0:36:54.77,Default,,0000,0000,0000,,address, when seeing if something is\Nalready in the cache or not: It doesn't
Dialogue: 0,0:36:54.77,0:36:59.70,Default,,0000,0000,0000,,compare all of the upper level bits. So,\Nthat means that it's possible that two
Dialogue: 0,0:36:59.70,0:37:04.14,Default,,0000,0000,0000,,different addresses will experience a\Ncollision, and the same entry from that
Dialogue: 0,0:37:04.14,0:37:08.87,Default,,0000,0000,0000,,BTB cache will be read out for an improper\Naddress. Now, since this is just for
Dialogue: 0,0:37:08.87,0:37:12.09,Default,,0000,0000,0000,,branch prediction, the worst that can\Nhappen is, you'll get a misprediction and
Dialogue: 0,0:37:12.09,0:37:18.07,Default,,0000,0000,0000,,a small time penalty, but that's about it.\NThe idea of behind the branch-shadowing
Dialogue: 0,0:37:18.07,0:37:22.44,Default,,0000,0000,0000,,attack is leveraging the small difference\Nin this overlapping and this collision of
Dialogue: 0,0:37:22.44,0:37:28.54,Default,,0000,0000,0000,,addresses in order to sort of execute a\Nshared code cell flush-and-reload attack
Dialogue: 0,0:37:28.54,0:37:35.33,Default,,0000,0000,0000,,on the branch target buffer. So, here what\Ngoes on is, during the attack the attacker
Dialogue: 0,0:37:35.33,0:37:39.65,Default,,0000,0000,0000,,modifies the SGX Enclave to make sure that\Nthe branches that are within the Enclave
Dialogue: 0,0:37:39.65,0:37:44.34,Default,,0000,0000,0000,,will collide with branches that are not in\Nthe Enclave. The attacker executes the
Dialogue: 0,0:37:44.34,0:37:50.44,Default,,0000,0000,0000,,Enclave code and then the attacker\Nexecutes their own code and based on the
Dialogue: 0,0:37:50.44,0:37:55.46,Default,,0000,0000,0000,,outcome of the the victim code in that\Ncache, the attacker code may or may not
Dialogue: 0,0:37:55.46,0:37:59.21,Default,,0000,0000,0000,,experience a branch prediction. So, the\Nattacker is able to tell the outcome of a
Dialogue: 0,0:37:59.21,0:38:03.31,Default,,0000,0000,0000,,branch, because of this overlap in this\Ncollision, like would be in a flush-and-
Dialogue: 0,0:38:03.31,0:38:06.57,Default,,0000,0000,0000,,reload attack, where those memories\Noverlap between the attacker and the
Dialogue: 0,0:38:06.57,0:38:14.02,Default,,0000,0000,0000,,victim. So here, our spatial resolution is\Nfantastic: We can tell down to individual
Dialogue: 0,0:38:14.02,0:38:19.44,Default,,0000,0000,0000,,branch instructions in SGX; we can tell\Nexactly, which branches were executed and
Dialogue: 0,0:38:19.44,0:38:25.01,Default,,0000,0000,0000,,which directions they were taken, in the\Ncase of conditional branches. The temporal
Dialogue: 0,0:38:25.01,0:38:29.72,Default,,0000,0000,0000,,resolution is also, once again, almost\Nunlimited, because we can use the same
Dialogue: 0,0:38:29.72,0:38:33.88,Default,,0000,0000,0000,,timer interrupts in order to schedule our\Nprocess, our attacker process. And the
Dialogue: 0,0:38:33.88,0:38:39.12,Default,,0000,0000,0000,,noise is, once again, very low, because we\Ncan, once again, use the same sort of
Dialogue: 0,0:38:39.12,0:38:43.98,Default,,0000,0000,0000,,branch misprediction counters, that exist\Nin the Intel world, in order to measure
Dialogue: 0,0:38:43.98,0:38:51.51,Default,,0000,0000,0000,,this noise. So, does anything of that\Napply to the TrustZone attacks? Well, in
Dialogue: 0,0:38:51.51,0:38:55.04,Default,,0000,0000,0000,,this case the victim and attacker don't\Nshare entries in the branch target buffer,
Dialogue: 0,0:38:55.04,0:39:01.61,Default,,0000,0000,0000,,because the attacker is not able to map\Nthe virtual address of the victim process.
Dialogue: 0,0:39:01.61,0:39:05.34,Default,,0000,0000,0000,,But this is kind of reminiscent of our\Nearlier cache attacks, so our flush-and-
Dialogue: 0,0:39:05.34,0:39:10.10,Default,,0000,0000,0000,,reload attack only worked when the attack\Non the victim shared that memory, but we
Dialogue: 0,0:39:10.10,0:39:13.93,Default,,0000,0000,0000,,still have the prime-and-probe attack for\Nwhen they don't. So, what if we use a
Dialogue: 0,0:39:13.93,0:39:21.38,Default,,0000,0000,0000,,prime-and-probe-style attack on the branch\Ntarget buffer cache in ARM processors? So,
Dialogue: 0,0:39:21.38,0:39:25.32,Default,,0000,0000,0000,,essentially what we do here is, we prime\Nthe branch target buffer by executing mini
Dialogue: 0,0:39:25.32,0:39:29.53,Default,,0000,0000,0000,,attacker branches to sort of fill up this\NBTB cache with the attacker branch
Dialogue: 0,0:39:29.53,0:39:34.77,Default,,0000,0000,0000,,prediction data; we let the victim execute\Na branch which will evict an attacker BTB
Dialogue: 0,0:39:34.77,0:39:39.12,Default,,0000,0000,0000,,entry; and then we have the attacker re-\Nexecute those branches and see if there
Dialogue: 0,0:39:39.12,0:39:45.12,Default,,0000,0000,0000,,have been any mispredictions. So now, the\Ncool thing about this attack is, the
Dialogue: 0,0:39:45.12,0:39:50.32,Default,,0000,0000,0000,,structure of the BTB cache is different\Nfrom that of the L1 caches. So, instead of
Dialogue: 0,0:39:50.32,0:39:59.75,Default,,0000,0000,0000,,having 256 different sets in the L1 cache,\Nthe BTB cache has 2048 different sets, so
Dialogue: 0,0:39:59.75,0:40:06.38,Default,,0000,0000,0000,,we can tell which branch it attacks, based\Non which one of 2048 different set IDs
Dialogue: 0,0:40:06.38,0:40:11.23,Default,,0000,0000,0000,,that it could fall into. And even more\Nthan that, on the ARM platform, at least
Dialogue: 0,0:40:11.23,0:40:15.73,Default,,0000,0000,0000,,on the Nexus 5x that I was working with,\Nthe granularity is no longer 64 bytes,
Dialogue: 0,0:40:15.73,0:40:21.83,Default,,0000,0000,0000,,which is the size of the line, it's now 16\Nbytes. So, we can see which branches the
Dialogue: 0,0:40:21.83,0:40:27.62,Default,,0000,0000,0000,,the trusted code within TrustZone is\Nexecuting within 16 bytes. So, what does
Dialogue: 0,0:40:27.62,0:40:31.82,Default,,0000,0000,0000,,this look like? So, previously with the\Ntrue-spy attack, this is sort of the
Dialogue: 0,0:40:31.82,0:40:37.41,Default,,0000,0000,0000,,outcome of our prime-and-probe attack: We\Nget 1 measurement for those 256 different
Dialogue: 0,0:40:37.41,0:40:43.42,Default,,0000,0000,0000,,set IDs. When we added those interrupts,\Nwe're able to get that time resolution,
Dialogue: 0,0:40:43.42,0:40:48.09,Default,,0000,0000,0000,,and it looks something like this. Now,\Nmaybe you can see a little bit at the top
Dialogue: 0,0:40:48.09,0:40:52.66,Default,,0000,0000,0000,,of the screen, how there's these repeated\Nsections of little white blocks, and you
Dialogue: 0,0:40:52.66,0:40:56.72,Default,,0000,0000,0000,,can sort of use that to infer, maybe\Nthere's the same cache line and cache
Dialogue: 0,0:40:56.72,0:41:00.87,Default,,0000,0000,0000,,instructions that are called over and\Nover. So, just looking at this L1-I cache
Dialogue: 0,0:41:00.87,0:41:06.92,Default,,0000,0000,0000,,attack, you can tell some information\Nabout how the process went. Now, let's
Dialogue: 0,0:41:06.92,0:41:11.87,Default,,0000,0000,0000,,compare that to the BTB attack. And I\Ndon't know if you can see too clearly --
Dialogue: 0,0:41:11.87,0:41:17.19,Default,,0000,0000,0000,,it's a it's a bit too high of resolution\Nright now -- so let's just focus in on one
Dialogue: 0,0:41:17.19,0:41:22.58,Default,,0000,0000,0000,,small part of this overall trace. And this\Nis what it looks like. So, each of those
Dialogue: 0,0:41:22.58,0:41:27.72,Default,,0000,0000,0000,,white pixels represents a branch that was\Ntaken by that secure-world code and we can
Dialogue: 0,0:41:27.72,0:41:31.07,Default,,0000,0000,0000,,see repeated patterns, we can see maybe\Ndifferent functions that were called, we
Dialogue: 0,0:41:31.07,0:41:35.31,Default,,0000,0000,0000,,can see different loops. And just by\Nlooking at this 1 trace, we can infer a
Dialogue: 0,0:41:35.31,0:41:40.11,Default,,0000,0000,0000,,lot of information on how that secure\Nworld executed. So, it's incredibly
Dialogue: 0,0:41:40.11,0:41:44.23,Default,,0000,0000,0000,,powerful and all of those secrets are just\Nwaiting to be uncovered using these new
Dialogue: 0,0:41:44.23,0:41:52.89,Default,,0000,0000,0000,,tools. So, where do we go from here? What\Nsort of countermeasures do we have? Well,
Dialogue: 0,0:41:52.89,0:41:56.69,Default,,0000,0000,0000,,first of all I think, the long term\Nsolution is going to be moving to no more
Dialogue: 0,0:41:56.69,0:42:00.20,Default,,0000,0000,0000,,shared hardware. We need to have separate\Nhardware and no more shared caches in
Dialogue: 0,0:42:00.20,0:42:05.75,Default,,0000,0000,0000,,order to fully get rid of these different\Ncache attacks. And we've already seen this
Dialogue: 0,0:42:05.75,0:42:11.42,Default,,0000,0000,0000,,trend in different cell phones. So, for\Nexample, in Apple SSEs for a long time now
Dialogue: 0,0:42:11.42,0:42:15.52,Default,,0000,0000,0000,,-- I think since the Apple A7 -- the\Nsecure Enclave, which runs the secure
Dialogue: 0,0:42:15.52,0:42:21.00,Default,,0000,0000,0000,,code, has its own cache. So, these cache\Nattacks can't be accomplished from code
Dialogue: 0,0:42:21.00,0:42:27.40,Default,,0000,0000,0000,,outside of that secure Enclave. So, just\Nby using that separate hardware, it knocks
Dialogue: 0,0:42:27.40,0:42:30.97,Default,,0000,0000,0000,,out a whole class of different potential\Nside-channel and microarchitecture
Dialogue: 0,0:42:30.97,0:42:35.61,Default,,0000,0000,0000,,attacks. And just recently, the Pixel 2 is\Nmoving in the same direction. The Pixel 2
Dialogue: 0,0:42:35.61,0:42:40.54,Default,,0000,0000,0000,,now includes a hardware security module\Nthat includes cryptographic operations;
Dialogue: 0,0:42:40.54,0:42:45.89,Default,,0000,0000,0000,,and that chip also has its own memory and\Nits own caches, so now we can no longer
Dialogue: 0,0:42:45.89,0:42:51.27,Default,,0000,0000,0000,,use this attack to extract information\Nabout what's going on in this external
Dialogue: 0,0:42:51.27,0:42:56.53,Default,,0000,0000,0000,,hardware security module. But even then,\Nusing this separate hardware, that doesn't
Dialogue: 0,0:42:56.53,0:43:00.80,Default,,0000,0000,0000,,solve all of our problems. Because we\Nstill have the question of "What do we
Dialogue: 0,0:43:00.80,0:43:05.90,Default,,0000,0000,0000,,include in this separate hardware?" On the\None hand, we want to include more code in
Dialogue: 0,0:43:05.90,0:43:11.37,Default,,0000,0000,0000,,that a separate hardware, so we're less\Nvulnerable to these side-channel attacks,
Dialogue: 0,0:43:11.37,0:43:16.49,Default,,0000,0000,0000,,but on the other hand, we don't want to\Nexpand the attack surface anymore. Because
Dialogue: 0,0:43:16.49,0:43:19.06,Default,,0000,0000,0000,,the more code we include in these secure\Nenvironments, the more like that a
Dialogue: 0,0:43:19.06,0:43:22.60,Default,,0000,0000,0000,,vulnerabiliyy will be found and the\Nattacker will be able to get a foothold
Dialogue: 0,0:43:22.60,0:43:26.47,Default,,0000,0000,0000,,within the secure, trusted environment.\NSo, there's going to be a balance between
Dialogue: 0,0:43:26.47,0:43:30.27,Default,,0000,0000,0000,,what do you choose to include in the\Nseparate hardware and what you don't. So,
Dialogue: 0,0:43:30.27,0:43:35.22,Default,,0000,0000,0000,,do you include DRM code? Do you include\Ncryptographic code? It's still an open
Dialogue: 0,0:43:35.22,0:43:41.80,Default,,0000,0000,0000,,question. And that's sort of the long-term\Napproach. In the short term, you just kind
Dialogue: 0,0:43:41.80,0:43:46.37,Default,,0000,0000,0000,,of have to write side-channel-free\Nsoftware: Just be very careful about what
Dialogue: 0,0:43:46.37,0:43:50.81,Default,,0000,0000,0000,,your process does, if there are any\Nsecret, dependent memory accesses or a
Dialogue: 0,0:43:50.81,0:43:55.31,Default,,0000,0000,0000,,secret, dependent branching or secret,\Ndependent function calls, because any of
Dialogue: 0,0:43:55.31,0:44:00.01,Default,,0000,0000,0000,,those can leak the secrets out of your\Ntrusted execution environment. So, here
Dialogue: 0,0:44:00.01,0:44:03.46,Default,,0000,0000,0000,,are the things that, if you are a\Ndeveloper of trusted execution environment
Dialogue: 0,0:44:03.46,0:44:08.15,Default,,0000,0000,0000,,code, that I want you to keep in mind:\NFirst of all, performance is very often at
Dialogue: 0,0:44:08.15,0:44:13.13,Default,,0000,0000,0000,,odds with security. We've seen over and\Nover that the performance enhancements to
Dialogue: 0,0:44:13.13,0:44:18.88,Default,,0000,0000,0000,,these processors open up the ability for\Nthese microarchitectural attacks to be
Dialogue: 0,0:44:18.88,0:44:23.75,Default,,0000,0000,0000,,more efficient. Additionally, these\Ntrusted execution environments don't
Dialogue: 0,0:44:23.75,0:44:27.16,Default,,0000,0000,0000,,protect against everything; there are\Nstill these side-channel attacks and these
Dialogue: 0,0:44:27.16,0:44:32.31,Default,,0000,0000,0000,,microarchitectural attacks that these\Nsystems are vulnerable to. These attacks
Dialogue: 0,0:44:32.31,0:44:37.65,Default,,0000,0000,0000,,are very powerful; they can be\Naccomplished simply; and with the
Dialogue: 0,0:44:37.65,0:44:41.77,Default,,0000,0000,0000,,publication of the code that I've written,\Nit should be very simple to get set up and
Dialogue: 0,0:44:41.77,0:44:46.07,Default,,0000,0000,0000,,to analyze your own code to see "Am I\Nvulnerable, do I expose information in the
Dialogue: 0,0:44:46.07,0:44:52.76,Default,,0000,0000,0000,,same way?" And lastly, it only takes 1\Nsmall error, 1 tiny leak from your trusted
Dialogue: 0,0:44:52.76,0:44:56.67,Default,,0000,0000,0000,,and secure code, in order to extract the\Nentire secret, in order to bring the whole
Dialogue: 0,0:44:56.67,0:45:03.92,Default,,0000,0000,0000,,thing down. So, what I want to leave you\Nwith is: I want you to remember that you
Dialogue: 0,0:45:03.92,0:45:08.52,Default,,0000,0000,0000,,are responsible for making sure that your\Nprogram is not vulnerable to these
Dialogue: 0,0:45:08.52,0:45:13.11,Default,,0000,0000,0000,,microarchitectural attacks, because if you\Ndo not take responsibility for this, who
Dialogue: 0,0:45:13.11,0:45:16.64,Default,,0000,0000,0000,,will? Thank you!
Dialogue: 0,0:45:16.64,0:45:25.04,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:45:25.04,0:45:29.82,Default,,0000,0000,0000,,Herald: Thank you very much. Please, if\Nyou want to leave the hall, please do it
Dialogue: 0,0:45:29.82,0:45:35.00,Default,,0000,0000,0000,,quiet and take all your belongings with\Nyou and respect the speaker. We have
Dialogue: 0,0:45:35.00,0:45:43.23,Default,,0000,0000,0000,,plenty of time, 16, 17 minutes for Q&A, so\Nplease line up on the microphones. No
Dialogue: 0,0:45:43.23,0:45:50.65,Default,,0000,0000,0000,,questions from the signal angel, all\Nright. So, we can start with microphone 6,
Dialogue: 0,0:45:50.65,0:45:54.77,Default,,0000,0000,0000,,please.\NMic 6: Okay. There was a symbol of secure
Dialogue: 0,0:45:54.77,0:46:01.16,Default,,0000,0000,0000,,OSes at the ARM TrustZone. Which a idea of\Nthem if the non-secure OS gets all the
Dialogue: 0,0:46:01.16,0:46:04.21,Default,,0000,0000,0000,,interrupts? What does is\Nthe secure OS for?
Dialogue: 0,0:46:04.21,0:46:08.88,Default,,0000,0000,0000,,Keegan: Yeah so, in the ARMv8 there are a\Ncouple different kinds of interrupts. So,
Dialogue: 0,0:46:08.88,0:46:11.76,Default,,0000,0000,0000,,I think -- if I'm remembering the\Nterminology correctly -- there is an IRQ
Dialogue: 0,0:46:11.76,0:46:16.80,Default,,0000,0000,0000,,and an FIQ interrupt. So, the non-secure\Nmode handles the IRQ interrupts and the
Dialogue: 0,0:46:16.80,0:46:20.44,Default,,0000,0000,0000,,secure mode handles the FIQ interrupts.\NSo, depending on which one you send, it
Dialogue: 0,0:46:20.44,0:46:24.84,Default,,0000,0000,0000,,will depend on which direction that\Nmonitor will direct that interrupt.
Dialogue: 0,0:46:29.64,0:46:32.01,Default,,0000,0000,0000,,Mic 6: Thank you.\NHerald: Okay, thank you. Microphone number
Dialogue: 0,0:46:32.01,0:46:37.93,Default,,0000,0000,0000,,7, please.\NMic 7: Does any of your present attacks on
Dialogue: 0,0:46:37.93,0:46:45.29,Default,,0000,0000,0000,,TrustZone also apply to the AMD\Nimplementation of TrustZone or are you
Dialogue: 0,0:46:45.29,0:46:48.38,Default,,0000,0000,0000,,looking into it?\NKeegan: I haven't looked into AMD too
Dialogue: 0,0:46:48.38,0:46:54.01,Default,,0000,0000,0000,,much, because, as far as I can tell,\Nthat's not used as commonly, but there are
Dialogue: 0,0:46:54.01,0:46:57.49,Default,,0000,0000,0000,,many different types of trusted execution\Nenvironments. The 2 that I focus on were
Dialogue: 0,0:46:57.49,0:47:04.76,Default,,0000,0000,0000,,SGX and TrustZone, because those are the\Nmost common examples that I've seen.
Dialogue: 0,0:47:04.76,0:47:09.25,Default,,0000,0000,0000,,Herald: Thank you. Microphone\Nnumber 8, please.
Dialogue: 0,0:47:09.25,0:47:20.37,Default,,0000,0000,0000,,Mic 8: When TrustZone is moved to\Ndedicated hardware, dedicated memory,
Dialogue: 0,0:47:20.37,0:47:27.78,Default,,0000,0000,0000,,couldn't you replicate the userspace\Nattacks by loading your own trusted
Dialogue: 0,0:47:27.78,0:47:32.21,Default,,0000,0000,0000,,userspace app and use it as an\Noracle of some sorts?
Dialogue: 0,0:47:32.21,0:47:35.76,Default,,0000,0000,0000,,Keegan: If you can load your own trust\Ncode, then yes, you could do that. But in
Dialogue: 0,0:47:35.76,0:47:39.65,Default,,0000,0000,0000,,many of the models I've seen today, that's\Nnot possible. So, that's why you have
Dialogue: 0,0:47:39.65,0:47:44.25,Default,,0000,0000,0000,,things like code signing, which prevent\Nthe arbitrary user from running their own
Dialogue: 0,0:47:44.25,0:47:50.31,Default,,0000,0000,0000,,code in the trusted OS... or in the the\Ntrusted environment.
Dialogue: 0,0:47:50.31,0:47:55.01,Default,,0000,0000,0000,,Herald: All right. Microphone number 1.\NMic 1: So, these attacks are more powerful
Dialogue: 0,0:47:55.01,0:48:00.72,Default,,0000,0000,0000,,against code that's running in... just the\Nexecution environments than similar
Dialogue: 0,0:48:00.72,0:48:07.10,Default,,0000,0000,0000,,attacks would be against ring-3 code, or,\Nin general, trusted code. Does that mean
Dialogue: 0,0:48:07.10,0:48:10.91,Default,,0000,0000,0000,,that trusting execution environments are\Nbasically an attractive nuisance that we
Dialogue: 0,0:48:10.91,0:48:15.08,Default,,0000,0000,0000,,shouldn't use?\NKeegan: There's still a large benefit to
Dialogue: 0,0:48:15.08,0:48:17.60,Default,,0000,0000,0000,,using these trusted execution\Nenvironments. The point I want to get
Dialogue: 0,0:48:17.60,0:48:21.39,Default,,0000,0000,0000,,across is that, although they add a lot of\Nfeatures, they don't protect against
Dialogue: 0,0:48:21.39,0:48:25.45,Default,,0000,0000,0000,,everything, so you should keep in mind\Nthat these side-channel attacks do still
Dialogue: 0,0:48:25.45,0:48:28.82,Default,,0000,0000,0000,,exist and you still need to protect\Nagainst them. But overall, these are
Dialogue: 0,0:48:28.82,0:48:35.93,Default,,0000,0000,0000,,better things and worthwhile in including.\NHerald: Thank you. Microphone number 1
Dialogue: 0,0:48:35.93,0:48:41.58,Default,,0000,0000,0000,,again, please\NMic 1: So, AMD is doing something with
Dialogue: 0,0:48:41.58,0:48:47.78,Default,,0000,0000,0000,,encrypting memory and I'm not sure if they\Nencrypt addresses, too, and but would that
Dialogue: 0,0:48:47.78,0:48:53.09,Default,,0000,0000,0000,,be a defense against such attacks?\NKeegan: So, I'm not too familiar with AMD,
Dialogue: 0,0:48:53.09,0:48:57.69,Default,,0000,0000,0000,,but SGX also encrypts memory. It encrypts\Nit in between the lowest-level cache and
Dialogue: 0,0:48:57.69,0:49:02.17,Default,,0000,0000,0000,,the main memory. But that doesn't really\Nhave an impact on the actual operation,
Dialogue: 0,0:49:02.17,0:49:06.22,Default,,0000,0000,0000,,because the memories encrypt at the cache\Nline level and as the attacker, we don't
Dialogue: 0,0:49:06.22,0:49:10.38,Default,,0000,0000,0000,,care what that data is within that cache\Nline, we only care which cache line is
Dialogue: 0,0:49:10.38,0:49:16.15,Default,,0000,0000,0000,,being accessed.\NMic 1: If you encrypt addresses, wouldn't
Dialogue: 0,0:49:16.15,0:49:20.55,Default,,0000,0000,0000,,that help against that?\NKeegan: I'm not sure, how you would
Dialogue: 0,0:49:20.55,0:49:25.07,Default,,0000,0000,0000,,encrypt the addresses yourself. As long as\Nthose adresses map into the same set IDs
Dialogue: 0,0:49:25.07,0:49:30.20,Default,,0000,0000,0000,,that the victim can map into, then the\Nvictim could still pull off the same style
Dialogue: 0,0:49:30.20,0:49:35.03,Default,,0000,0000,0000,,of attacks.\NHerald: Great. We have a question from the
Dialogue: 0,0:49:35.03,0:49:38.20,Default,,0000,0000,0000,,internet, please.\NSignal Angel: The question is "Does the
Dialogue: 0,0:49:38.20,0:49:42.41,Default,,0000,0000,0000,,secure enclave on the Samsung Exynos\Ndistinguish the receiver of the messag, so
Dialogue: 0,0:49:42.41,0:49:46.83,Default,,0000,0000,0000,,that if the user application asked to\Ndecode an AES message, can one sniff on
Dialogue: 0,0:49:46.83,0:49:52.22,Default,,0000,0000,0000,,the value that the secure\Nenclave returns?"
Dialogue: 0,0:49:52.22,0:49:56.68,Default,,0000,0000,0000,,Keegan: So, that sounds like it's asking\Nabout the true-spy style attack, where
Dialogue: 0,0:49:56.68,0:50:01.27,Default,,0000,0000,0000,,it's calling to the secure world to\Nencrypt something with AES. I think, that
Dialogue: 0,0:50:01.27,0:50:04.83,Default,,0000,0000,0000,,would all depend on the different\Nimplementation: As long as it's encrypting
Dialogue: 0,0:50:04.83,0:50:09.79,Default,,0000,0000,0000,,for a certain key and it's able to do that\Nrepeatably, then the attack would,
Dialogue: 0,0:50:09.79,0:50:16.29,Default,,0000,0000,0000,,assuming a vulnerable AES implementation,\Nwould be able to extract that key out.
Dialogue: 0,0:50:16.29,0:50:20.75,Default,,0000,0000,0000,,Herald: Cool. Microphone number 2, please.\NMic 2: Do you recommend a reference to
Dialogue: 0,0:50:20.75,0:50:25.35,Default,,0000,0000,0000,,understand how these cache line attacks\Nand branch oracles actually lead to key
Dialogue: 0,0:50:25.35,0:50:29.54,Default,,0000,0000,0000,,recovery?\NKeegan: Yeah. So, I will flip through
Dialogue: 0,0:50:29.54,0:50:33.62,Default,,0000,0000,0000,,these pages which include a lot of the\Nreferences for the attacks that I've
Dialogue: 0,0:50:33.62,0:50:38.03,Default,,0000,0000,0000,,mentioned, so if you're watching the\Nvideo, you can see these right away or
Dialogue: 0,0:50:38.03,0:50:43.20,Default,,0000,0000,0000,,just access the slides. And a lot of these\Ncontain good starting points. So, I didn't
Dialogue: 0,0:50:43.20,0:50:46.34,Default,,0000,0000,0000,,go into a lot of the details on how, for\Nexample, the true-spy attack recovered
Dialogue: 0,0:50:46.34,0:50:53.09,Default,,0000,0000,0000,,that AES key., but that paper does have a\Nlot of good links, how those areas can
Dialogue: 0,0:50:53.09,0:50:56.35,Default,,0000,0000,0000,,lead to key recovery. Same thing with the\NCLKSCREW attack, how the different fault
Dialogue: 0,0:50:56.35,0:51:03.07,Default,,0000,0000,0000,,injection can lead to key recovery.\NHerald: Microphone number 6, please.
Dialogue: 0,0:51:03.07,0:51:07.90,Default,,0000,0000,0000,,Mic 6: I think my question might have been\Nvery, almost the same thing: How hard is
Dialogue: 0,0:51:07.90,0:51:11.92,Default,,0000,0000,0000,,it actually to recover the keys? Is this\Nlike a massive machine learning problem or
Dialogue: 0,0:51:11.92,0:51:18.50,Default,,0000,0000,0000,,is this something that you can do\Npractically on a single machine?
Dialogue: 0,0:51:18.50,0:51:21.64,Default,,0000,0000,0000,,Keegan: It varies entirely by the end\Nimplementation. So, for all these attacks
Dialogue: 0,0:51:21.64,0:51:25.75,Default,,0000,0000,0000,,work, you need to have some sort of\Nvulnerable implementation and some
Dialogue: 0,0:51:25.75,0:51:29.01,Default,,0000,0000,0000,,implementations leak more data than\Nothers. In the case of a lot of the AES
Dialogue: 0,0:51:29.01,0:51:33.88,Default,,0000,0000,0000,,attacks, where you're doing the passive\Nattacks, those are very easy to do on just
Dialogue: 0,0:51:33.88,0:51:37.63,Default,,0000,0000,0000,,your own computer. For the AES fault\Ninjection attack, I think that one
Dialogue: 0,0:51:37.63,0:51:42.34,Default,,0000,0000,0000,,required more brute force, in the CLKSCREW\Npaper, so that one required more computing
Dialogue: 0,0:51:42.34,0:51:49.78,Default,,0000,0000,0000,,resources, but still, it was entirely\Npractical to do in a realistic setting.
Dialogue: 0,0:51:49.78,0:51:53.77,Default,,0000,0000,0000,,Herald: Cool, thank you. So, we have one\Nmore: Microphone number 1, please.
Dialogue: 0,0:51:53.77,0:51:59.08,Default,,0000,0000,0000,,Mic 1: So, I hope it's not a too naive\Nquestion, but I was wondering, since all
Dialogue: 0,0:51:59.08,0:52:04.73,Default,,0000,0000,0000,,these attacks are based on cache hit and\Nmisses, isn't it possible to forcibly
Dialogue: 0,0:52:04.73,0:52:11.28,Default,,0000,0000,0000,,flush or invalidate or insert noise in\Ncache after each operation in this trust
Dialogue: 0,0:52:11.28,0:52:23.52,Default,,0000,0000,0000,,environment, in order to mess up the\Nguesswork of the attacker? So, discarding
Dialogue: 0,0:52:23.52,0:52:29.18,Default,,0000,0000,0000,,optimization and performance for\Nadditional security benefits.
Dialogue: 0,0:52:29.18,0:52:32.42,Default,,0000,0000,0000,,Keegan: Yeah, and that is absolutely\Npossible and you are absolutely right: It
Dialogue: 0,0:52:32.42,0:52:36.30,Default,,0000,0000,0000,,does lead to a performance degradation,\Nbecause if you always flush the entire
Dialogue: 0,0:52:36.30,0:52:41.19,Default,,0000,0000,0000,,cache every time you do a context switch,\Nthat will be a huge performance hit. So
Dialogue: 0,0:52:41.19,0:52:45.19,Default,,0000,0000,0000,,again, that comes down to the question of\Nthe performance and security trade-off:
Dialogue: 0,0:52:45.19,0:52:49.54,Default,,0000,0000,0000,,Which one do you end up going with? And it\Nseems historically the choice has been
Dialogue: 0,0:52:49.54,0:52:54.00,Default,,0000,0000,0000,,more in the direction of performance.\NMic 1: Thank you.
Dialogue: 0,0:52:54.00,0:52:56.92,Default,,0000,0000,0000,,Herald: But we have one more: Microphone\Nnumber 1, please.
Dialogue: 0,0:52:56.92,0:53:01.50,Default,,0000,0000,0000,,Mic 1: So, I have more of a moral\Nquestion: So, how well should we really
Dialogue: 0,0:53:01.50,0:53:07.72,Default,,0000,0000,0000,,protect from attacks which need some\Nring-0 cooperation? Because, basically,
Dialogue: 0,0:53:07.72,0:53:14.35,Default,,0000,0000,0000,,when we use TrustZone for purpose... we\Nwould see clear, like protecting the
Dialogue: 0,0:53:14.35,0:53:20.25,Default,,0000,0000,0000,,browser from interacting from outside\Nworld, then we are basically using the
Dialogue: 0,0:53:20.25,0:53:27.28,Default,,0000,0000,0000,,safe execution environment for sandboxing\Nthe process. But once we need some
Dialogue: 0,0:53:27.28,0:53:32.28,Default,,0000,0000,0000,,cooperation from the kernel, some of that\Nattacks, is in fact, empower the user
Dialogue: 0,0:53:32.28,0:53:36.32,Default,,0000,0000,0000,,instead of the hardware producer.\NKeegan: Yeah, and you're right. It
Dialogue: 0,0:53:36.32,0:53:39.21,Default,,0000,0000,0000,,depends entirely on what your application\Nis and what your threat model is that
Dialogue: 0,0:53:39.21,0:53:43.02,Default,,0000,0000,0000,,you're looking at. So, if you're using\Nthese trusted execution environments to do
Dialogue: 0,0:53:43.02,0:53:48.43,Default,,0000,0000,0000,,DRM, for example, then maybe you wouldn't\Nbe worried about that ring-0 attack or
Dialogue: 0,0:53:48.43,0:53:51.62,Default,,0000,0000,0000,,that privileged attacker who has their\Nphone rooted and is trying to recover
Dialogue: 0,0:53:51.62,0:53:56.74,Default,,0000,0000,0000,,these media encryption keys from this\Nexecution environment. But maybe there are
Dialogue: 0,0:53:56.74,0:54:01.23,Default,,0000,0000,0000,,other scenarios where you're not as\Nworried about having an attack with a
Dialogue: 0,0:54:01.23,0:54:05.58,Default,,0000,0000,0000,,compromised ring 0. So, it entirely\Ndepends on context.
Dialogue: 0,0:54:05.58,0:54:09.00,Default,,0000,0000,0000,,Herald: Alright, thank you. So, we have\None more: Microphone number 1, again.
Dialogue: 0,0:54:09.00,0:54:10.99,Default,,0000,0000,0000,,Mic 1: Hey there. Great talk, thank you\Nvery much.
Dialogue: 0,0:54:10.99,0:54:13.04,Default,,0000,0000,0000,,Keegan: Thank you.\NMic 1: Just a short question: Do you have
Dialogue: 0,0:54:13.04,0:54:16.98,Default,,0000,0000,0000,,any success stories about attacking the\NTrustZone and the different
Dialogue: 0,0:54:16.98,0:54:24.01,Default,,0000,0000,0000,,implementations of TE with some vendors\Nlike some OEMs creating phones and stuff?
Dialogue: 0,0:54:24.01,0:54:29.75,Default,,0000,0000,0000,,Keegan: Not that I'm announcing\Nat this time.
Dialogue: 0,0:54:29.75,0:54:35.58,Default,,0000,0000,0000,,Herald: So, thank you very much. Please,\Nagain a warm round of applause for Keegan!
Dialogue: 0,0:54:35.58,0:54:39.100,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:54:39.100,0:54:45.49,Default,,0000,0000,0000,,{\i1}34c3 postroll music{\i0}
Dialogue: 0,0:54:45.49,0:55:02.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2018. Join, and help us!