WEBVTT 00:00.000 --> 00:11.820 All right. Good morning, confidential computing. I'm going to talk about memory isolation and 00:11.820 --> 00:17.100 Texas instruments, microcontrollers. And I imagine that at this point the audience is kind 00:17.100 --> 00:22.100 of divided and half, where half of you are thinking, wait, there's confidential computing 00:22.100 --> 00:27.300 and Texas instruments. And the other half is thinking, why would you need confidential computing 00:27.300 --> 00:34.300 for a calculator? But as it turns out, Texas instruments is more than just a calculator 00:34.300 --> 00:40.260 company. They actually have a very rich history as kind of a computing company. So they 00:40.260 --> 00:45.660 were the first ones, the first company, to manufacture a silicon transistor. And four 00:45.660 --> 00:51.500 years later, they were also the inventors of the integrated circuit. And so they not only 00:51.500 --> 00:56.460 produce calculators, but also other systems, where sometimes I think maybe having some kind 00:56.460 --> 01:02.260 of security for this type of stuff is not the worst idea in the world. So I don't know if 01:02.260 --> 01:07.020 you see it from the back, but they also develop laser guidance systems for precision guided 01:07.020 --> 01:16.860 munitions. So ballistic missiles. So let's talk about what type of security they have. I'm not 01:16.860 --> 01:23.220 going to go too deep into the details, but it's kind of different than this kind of confidential 01:23.220 --> 01:29.180 VM infrastructure that we've seen in the previous stocks as well. So I will explain it a little 01:29.180 --> 01:35.140 bit. This is what we saw in the previous stocks. So this is kind of the traditional high 01:35.140 --> 01:41.620 ends desktop or server environment, where you have actually many different ways of isolating 01:41.620 --> 01:47.260 code and data. You can have processes that are running in parallel. You can have in-process 01:47.340 --> 01:54.140 enclaves. You can have confidential VMs. And all of these rely on the hardware to provide 01:54.140 --> 02:00.980 some kind of isolation between these different entities within the computer. And this 02:00.980 --> 02:08.740 is implemented through things like virtual memory, virtualization, privilege, and so on. 02:08.740 --> 02:13.980 But in this case, the device that I'm going to talk about is this MSP430 macro controller. 02:13.980 --> 02:19.900 And this has none of this. This is, it's actually a long line of macro controllers, 02:19.900 --> 02:24.900 but the specific device that I'm going to talk about was released in 2014. At the time when 02:24.900 --> 02:29.300 it was released, I think it was actually the lowest power, lowest power macro controller 02:29.300 --> 02:35.660 in the entire world. But it still has some security features. As an example, it has AX 02:35.660 --> 02:40.500 acceleration. It has a memory protection unit. And it also has this intellectual property 02:40.580 --> 02:47.220 encapsulation feature that I'm going to focus on in this talk. IP for short. And so the 02:47.220 --> 02:53.460 way this works is that you don't have virtual memory. You don't have virtualization any of 02:53.460 --> 02:59.140 these things on this device. It's a flat unified address space. All the code and data on the 02:59.140 --> 03:06.980 device shares this one physical address range. And what IP allows you to do is you can write 03:07.060 --> 03:13.300 two addresses, the two registers. And this will mark one area of memory that is going to be 03:13.300 --> 03:19.540 the protected area. And you can put code and data in here. It's a font normal architecture. So 03:19.540 --> 03:27.380 it's mixed code and data. So here you can put your intellectual properties such as proprietary 03:27.380 --> 03:33.620 code or secret data such as encryption keys or nuclear launch codes, whatever you use this 03:33.700 --> 03:41.860 device for. And then what IP actually enforces is that if you run code from inside this 03:41.860 --> 03:47.460 enclave, you can access and manipulate the data. That's also inside. But if you have code running 03:47.460 --> 03:53.060 anywhere outside this address range, then it basically cannot access anything inside the enclave. 03:54.260 --> 04:00.340 And this is not only enforced for code, but also for JTAG the buggers and direct memory access. 04:01.060 --> 04:06.020 So it's kind of a program counter based access control. So in certain ways it's a bit similar 04:06.020 --> 04:16.020 to intellectual GX or other similar DEs. But how secure is it? So now I kind of explained how 04:16.020 --> 04:25.140 it's supposed to work. But we performed an MDAP security analysis into this device. And we found 04:25.140 --> 04:30.260 that unfortunately it doesn't work that well. Again I'm not going to go into the details. 04:31.140 --> 04:38.500 Basically what we did is we looked at a lot of prior literature in trying to attack 04:38.500 --> 04:43.780 confidential computing architectures. And we tried to recreate some of these attacks, see which 04:43.780 --> 04:48.740 ones apply, see which ones are successful on this device. And all the ones that are highlighted. 04:48.740 --> 04:54.980 So almost all of the rows in the table, we could recreate on this device. So we could 04:55.700 --> 05:01.860 both architectural and micro architectural side channel attacks successfully executed on this device. 05:02.580 --> 05:06.900 And the security guarantees are basically completely broken as a result. 05:07.620 --> 05:13.860 And important to note that these are all software based attacks. So even if you don't necessarily 05:13.860 --> 05:19.780 have physical access to the device, it might still be possible to take over if you have some 05:19.780 --> 05:25.860 way of injecting code into the device. And actually so I said that we tried to recreate 05:25.860 --> 05:31.700 existing attacks. But that's not the entirety of what we did because this very first line in the 05:31.700 --> 05:37.140 row, the very first row in the table controlled call corruption. It's a completely novel attack 05:37.140 --> 05:41.700 that we discovered on this device. And again I will not go into the details. You can talk 05:41.700 --> 05:48.180 to me later if you're interested in how this actually works. But very shortly it allows you to 05:49.140 --> 05:54.740 corrupt memory anywhere inside this IP region and you can kind of force it to leak its full 05:54.740 --> 06:02.740 contents. And this is something that's TI also released an advisory about. They gave it a CVS 06:02.740 --> 06:10.260 score of high. So they also seem to agree that it's pretty important. And then probably the 06:10.260 --> 06:15.620 natural question that you're asking is, can we mitigate against these attacks? Can we do anything 06:15.620 --> 06:22.500 to kind of restore the security on these devices? And while it turns out if you give researchers 06:22.500 --> 06:30.900 enough coffee anything is possible, it's not very nice but it works. So here again the details are 06:30.900 --> 06:37.220 not important. But we manage to repurpose one of these other security features, the memory protection 06:37.220 --> 06:43.220 unit, to kind of provide some of the security guarantees that IP is supposed to provide but fails. 06:43.700 --> 06:53.540 And yeah with the edit complexity of more software having to trust more software and also 06:53.540 --> 06:58.660 reducing the applicable attacker model a little bit because we cannot defend against attackers 06:58.660 --> 07:04.740 that have control over the debugger. In this case we can still protect the code and the data in the 07:04.740 --> 07:14.420 IP region in most scenarios. So everything that I talked about so far, the attacks, this mitigation 07:14.420 --> 07:19.860 framework and the academic paper that we wrote about this with all the details, you can find 07:20.420 --> 07:26.340 a death QR code. But I have to disappoint you, this is not the end of the target. 07:27.460 --> 07:34.260 Because after we were done with this research we were wondering what could we do if we could 07:34.260 --> 07:39.620 actually change the hardware because most of these bugs, well most of these vulnerabilities 07:39.620 --> 07:46.180 stem from bugs that could be fixed in hardware. But yeah how would we do that? 07:48.340 --> 07:55.220 This MSP430 is used a bit in research but because the hardware is obviously close source, 07:55.220 --> 08:01.540 there is no design files or anything available for these devices. It's kind of hard to prototype 08:01.540 --> 08:06.820 any kind of changes to it. There's no simulator that you can run so even to just run the 08:06.820 --> 08:16.420 exploits you need to have the physical device. But already in 2009 a new software was released called 08:16.420 --> 08:23.460 Open MSP430 which is a simple very low design that implements the same MSP430 architecture 08:24.100 --> 08:30.980 and it's relatively easy to work with and you can see that there's a lot of research publications 08:31.060 --> 08:37.940 that also extended this Open MSP430 core and actually all of these added some kind of memory 08:37.940 --> 08:43.940 isolation feature to it. So clearly there's a need for this and there's some interest in this topic 08:45.380 --> 08:53.220 but it's still very scattered and all of them are kind of random independent implementations 08:53.220 --> 09:00.100 of this memory isolation. So then what we came up with is we took the base Open MSP430 core 09:00.660 --> 09:07.220 and we implemented the IP specification on it. We tried to make it as binary compatible as 09:07.220 --> 09:13.700 possible so that you can run existing programs that were meant to run on the TI market controller 09:13.700 --> 09:22.740 on this framework and we also added one interesting new feature which is this firmware here. 09:22.740 --> 09:28.740 So already on the TI devices there's some small protected boot code that runs that actually 09:28.820 --> 09:34.180 sets up the protection whenever you boot up the device but this is not visible it's not 09:34.180 --> 09:40.820 modifiable on the TI devices but on our implementation we wanted to make this open so that researchers 09:40.820 --> 09:47.220 can actually change this and maybe extend it to implement additional security features mostly by 09:47.220 --> 09:53.300 just changing this small layer of trusted code instead of having to make changes to the core itself 09:53.940 --> 09:58.980 but we also implemented all the hardware fixes that we thought would be relevant for mitigating 09:58.980 --> 10:06.980 the vulnerabilities that we found in the original design. At this point I should ask the 10:06.980 --> 10:13.780 Devroom organizers for the scheduling that they make because now I can talk about Open IP which 10:13.780 --> 10:21.300 is an open and extensible framework for a security research on Texas Instruments IP and this makes 10:21.380 --> 10:28.660 a sound like a very original idea that no one else could possibly have so stick around for the next 10:28.660 --> 10:35.620 stock if you're interested in something very similar but on CCA so a much broader and much bigger 10:35.620 --> 10:44.020 project but okay so about Open IP to test out how this firmware actually works and how it can be 10:44.020 --> 10:53.060 extended for additional security features we also perform the small case study where we again without 10:53.060 --> 11:00.660 going into the details we mitigated some of the architectural and side channel attacks that we discovered 11:00.660 --> 11:12.180 in the original TI boards so there is a tag that can extract secrets from enclaves by measuring 11:12.260 --> 11:16.900 how long inter up stake and this is something that we can mitigate by changing how interrupts 11:16.900 --> 11:21.700 our handled and how the software actually does the context switching between trusted and untrusted code. 11:23.940 --> 11:28.740 Another important aspect if you implement something is to write tests and make sure that 11:28.740 --> 11:35.620 everything works correctly and securely so we did two things regarding this. First of all we wrote 11:35.700 --> 11:42.820 a lot of small unit tests that check whether the functionality works correctly so whether the 11:42.820 --> 11:48.500 IP specification is implemented correctly and also whether the security is better than on the original 11:48.500 --> 11:54.020 board so we wrote a lot of scenarios that's tried to replicate attacks from the original device 11:54.020 --> 12:01.060 and see that it doesn't work anymore on our implementation and then we also care about the security 12:01.060 --> 12:08.100 of the software these tests are more about the hardware working properly but there's also been 12:08.100 --> 12:13.700 quite some research on how you can ensure that software that is running inside an enclave is 12:13.700 --> 12:20.820 properly secured and what we use here is symbolic execution which uses mathematics to 12:21.780 --> 12:27.780 check all the possible paths that your program can take and simulate those executions and see whether 12:27.860 --> 12:34.500 anything potentially dangerous is happening and one of the tools for symbolic execution is anger 12:34.500 --> 12:40.340 and we actually use a framework that's built on top of anger it's called Pandora it was made by 12:40.340 --> 12:47.140 one of the previous organizers of this bedroom and it was originally made for intellectual GX where 12:47.140 --> 12:56.020 it can detect vulnerabilities that are specific to enclaves or to GX in particular and we adapted this to 12:56.020 --> 13:04.340 be so that it can consume these IP binaries or even our firmware code that we can potentially 13:04.340 --> 13:11.140 extend for security features and then check whether everything is protected correctly and this 13:11.140 --> 13:17.380 tool if it detects any kind of potential violations it gives these nice visual reports where you can 13:17.380 --> 13:22.180 look at there's a suspicious instruction there that can potentially leak your entire memory so 13:22.180 --> 13:29.140 maybe you should make sure that this is working as intended all right so what are our goals with 13:29.140 --> 13:35.300 open IP well obviously I already showed before that this seems to be an area of research that 13:35.300 --> 13:41.220 is still active and there is some interest in this kind of memory isolation and in small embedded 13:41.220 --> 13:48.100 microbandrollers so we hope that our platform can be used as a basis for that type of research and 13:48.100 --> 13:53.860 maybe you kind of unify these efforts a little bit and also contribute with things like 13:53.860 --> 13:58.260 thorough testing because we saw that some of the research prototypes in the past were maybe not 13:58.260 --> 14:04.980 that well tested but it's actually also a great tool for teaching because the implementation 14:04.980 --> 14:12.340 is relatively simple it's around the thousand lines of very low code but it can already introduce 14:12.340 --> 14:16.900 students to a lot of different concepts so already during the presentation I talked about 14:17.060 --> 14:22.980 memory isolation hardware vulnerabilities architectural micro architecture attacks symbolic 14:22.980 --> 14:29.860 execution there's a lot of areas that you can kind of easily or excessively discover using this framework 14:29.860 --> 14:34.980 so we are already using this in multiple thesis projects and we're hoping to to keep using this 14:34.980 --> 14:42.580 in the future and this is actually my last slide here you can find the code for so this is for all the 14:42.580 --> 14:48.980 Texas Instruments related codes the attacks and the mitigation framework and this is the open IP 14:48.980 --> 14:55.060 implementation and tests and you can also find the links there at the bottom and I would encourage you 14:55.060 --> 15:01.620 that if you're doing research in this area or if you have any students or interns or whoever could 15:02.260 --> 15:09.860 possibly make use of a nice little onboarding project into enclaves I think it's a good starting point 15:09.940 --> 15:14.420 and you can also find my website at the bottom so feel free to reach out if you have any questions or 15:14.420 --> 15:27.380 or want to ask for help about any of this thanks any questions yeah 15:28.420 --> 15:33.540 so one of the core features of confidential computing is the extension part so you can see that 15:33.540 --> 15:37.300 if there's an empty-time mission to look for why we've got permission to do it by itself 15:38.340 --> 15:44.740 yeah what would be the worst-time mission part in it so the question was whether there's any 15:44.740 --> 15:50.260 attestation support because it's an important part of confidential computing so indeed the 15:51.140 --> 15:58.260 initial the original TIP does not have anything to do with attestation they I think don't even 15:58.260 --> 16:04.500 talk about it in the documentation but it doesn't make sense because they're not leaving 16:04.500 --> 16:09.140 it to be confidential so you are leaving it to the confidential so that's my question to your 16:09.140 --> 16:14.100 part rather than to text us assuming well they claim that it's a feature that can be used for 16:14.100 --> 16:21.140 protecting code and data so that covers the confidentiality part I would say but I agree with you 16:21.140 --> 16:29.780 that attestation is also important and we haven't really looked into it yet but we hope that by 16:29.780 --> 16:36.020 using this extensible firmware layer that we added we could add some software based attestation 16:36.820 --> 16:43.700 that can be triggered and then used as a similar primitive as attestation on higher and 16:44.500 --> 16:46.020 confidential computing architectures 16:51.140 --> 16:56.740 from looking for safe you're doing it x software rather than at the hardware layer so how does it match 16:56.740 --> 17:02.580 with the x-ray this is the definition that was presented hardware based attestation or hardware based 17:03.140 --> 17:10.180 confidentiality and it's a good guarantee I guess it depends on how you define hardware based 17:10.180 --> 17:15.060 so it still relies on some of the guarantees of the hardware that makes it such that you cannot 17:15.140 --> 17:21.540 temper with the attestation so that's provided by the confidentiality of the and the integrity of 17:21.540 --> 17:28.180 the firmware code for example and then relying on that you can add attestation that is computed 17:28.180 --> 17:35.380 in software but I think that still would function the same way but maybe we can discuss it further 17:36.340 --> 17:58.500 yeah so the question is which boards are affected basically so we there's one specific family of 17:58.500 --> 18:05.060 these MSP430 markment rollers that have a specific type of memory this f-ram and these are the devices 18:05.140 --> 18:11.300 that support this IP technology so I don't have complete numbers for how many devices this is specifically 18:12.100 --> 18:18.100 we tested three different CPUs that are in this family and they were all affected so I 18:18.100 --> 18:22.340 imagine that all of them are probably very similar to each other and maybe most of the 18:22.340 --> 18:27.860 different terms of peripherals or something and I would guess that they are all affected actually 18:27.860 --> 18:34.820 I can go back maybe it's a good indication if we check what TI said so in their security bulletin 18:35.220 --> 18:39.620 they also say the bottom I don't know if you can see it from there the affected products 18:39.620 --> 18:45.620 and they list all yeah the whole family of these devices so they probably also think that 18:45.620 --> 19:01.780 all of them are affected so we there are most of yeah whether open IP is starting a 19:01.780 --> 19:09.060 specific board or a specific type of hardware so most of it I think is very generic in the sense 19:09.060 --> 19:15.860 that the specification of IP is is pretty device independent but there are some device specific 19:16.820 --> 19:21.700 specifications so for example where exactly the registers are in memory that you have to 19:21.700 --> 19:27.780 write to so in this case we took one specific board and just use those but it's something that could 19:27.780 --> 19:29.780 be easily changed as well