WEBVTT 00:00.000 --> 00:17.360 Hi, I am Alice. I worked at Capfruit actually in Switzerland, a company from Switzerland. 00:17.360 --> 00:22.200 And today I'm going to talk about Trusted Boot with the GenotOS framework, aka using TPM with 00:22.200 --> 00:29.960 Genot. A word about Capfruit. So once upon a time, some team of engineers that work 00:29.960 --> 00:34.960 in R&D could create a real product based on microcan and inkable-b-based security. 00:34.960 --> 00:41.040 In 2018, this five-engine year for the Capfruit I-D. One of the most important milestones 00:41.040 --> 00:46.320 in 2020, Capfruit released its first NDP, a Trusted Execution Environment for the banking 00:46.320 --> 00:52.240 industry and I-John Capfruit. Since then, Capfruit has committed with different partners and 00:52.240 --> 00:57.280 created network to work on product for the IoT sectors, most of using under the device 00:57.280 --> 01:04.840 based on ARM or X86. These devices are mostly used to interconnect other devices to the 01:04.840 --> 01:10.680 internet or even with the ambition to quickly replace different set of machines to be on 01:10.680 --> 01:15.200 a one-board on the needs of your machine that does the machine control and also connect 01:15.200 --> 01:22.880 to the internet. This set, this set, this is a set of requirements 01:23.120 --> 01:26.760 that we have for our product key infrastructure. We want other devices to be shipped from 01:26.760 --> 01:31.760 the factory with their touch provisioning. What we are meaning here is that we don't want 01:31.760 --> 01:36.000 a new man or an specific intervention to open on the device. It's provisioning in the factory 01:36.000 --> 01:40.080 and it's protocol, customer and it should connect to the cloud and fetch its configuration 01:40.080 --> 01:45.960 for there. For this, we need to provide access to the cloud. Another thing that we want 01:45.960 --> 01:50.960 to do for that is to use the Trusted Cognitive-based to record the bootchain environment 01:50.960 --> 01:57.840 in PCRs. And for that, we're going to use a router straff. It's going to be a TPM, a Trusted 01:57.840 --> 02:04.000 Platform module. We're also going to use the TPM to sign shortly certificate so that 02:04.000 --> 02:08.960 this legacy up can easily access the cloud. And all of this is running on a macro-canon-based 02:08.960 --> 02:16.720 operating system. So the design goal we are for the TPM stack is compatibility and separation 02:16.720 --> 02:20.760 of concerns between a huge monotip block. We have different components and some of the 02:20.760 --> 02:27.080 components are part of the TCB. We need them to be able to easily trust them, such minimal 02:27.080 --> 02:33.160 Trusted Confidence. We also want for application to benefit from existing libraries. Also, 02:33.160 --> 02:42.200 we want integration with a measured boot and non-retail PCRs. We don't this because we 02:42.200 --> 02:47.560 want to be able to take the system and we want to be sure which system is actually running 02:47.560 --> 02:51.880 so shorter than secure boot. We want to be sure this is this image that is running and 02:51.880 --> 02:59.960 eventually we also want updating to do rollback prevention. Finally, we will see PIM to authenticate 02:59.960 --> 03:05.160 and integrate our OPKI and we also want compatibility with the legacy up application. 03:08.600 --> 03:13.480 So the foundation of all of this is measured boot and platform configuration registers a 03:13.480 --> 03:24.520 amount of existing image that is extended in TCI and 9. So let's look at a practical example. 03:25.560 --> 03:30.600 The FH Trésor Trusted Anchor. What is Trésor? Trésor is the consist of block 03:30.600 --> 03:36.040 uncryptor created by Gnode. It's actually an ecosystem and most notably we have its Trusted Anchor. 03:36.840 --> 03:42.280 So in Gnode, VF is not like any operating system. We have a global FH system. We have a 03:42.280 --> 03:48.600 FH system server and provide the session interface in all the micro-danners stuff and the actual 03:48.600 --> 03:56.200 implementation of the FH system they usually come as plug-ings. Trude object. For example, if you have 03:56.200 --> 04:00.600 an actual FH, you can have the implementation of an actual FH system from a block device. 04:00.600 --> 04:06.200 When it's then fashion that Linux likes to do character device, we can also create a FH system 04:06.200 --> 04:10.840 a plug-ing that will be the driver for the TPM and expose it as a file. That's the architecture 04:10.840 --> 04:15.960 we decide to take. So everything that we are seeing here from the TPM up to the Trésor Trusted 04:15.960 --> 04:21.960 Anchor is actually 5 system plug-ings at the exception of two other devices. So how does that look like? 04:21.960 --> 04:26.200 We have the hardware on there. We have what we call the TPMOS. It's going to be a subsistender 04:26.200 --> 04:31.400 content to drive for the hardware. In the middle, we have the TPM max. It's going to multiplex 04:32.360 --> 04:38.440 the TPM and some resources, more detail about this coming and finally we have the Trésor Trusted Anchor. 04:38.440 --> 04:42.840 The Trésor Trusted Anchor is basically abstracting for the rest of the subsistender, 04:42.840 --> 04:48.280 the secret key that is used by the CBE. The three, so it has different set of file that abstract 04:48.280 --> 04:53.000 low operation you can do. But the three main operation we are interested in from the TPM is creating the 04:53.000 --> 04:59.240 secret key, still in it, and unsealing it. And what we are going to do is perhaps this plug-ing 04:59.480 --> 05:04.680 using a TPM. We can also have at the same time also component. We have the TPM to run them here. 05:04.680 --> 05:10.440 It's basically just the lip C-base example from the lip TSS. We can have a TPM to it. TPCR 05:10.440 --> 05:16.040 reports that basically report the state of the PCR in the NXML blob. And report the specific 05:16.040 --> 05:19.720 session in the genome operating system framework. It's more to use for debugging. 05:22.040 --> 05:27.880 So the support hardware, let's have a look at the TPM observed system. TPM comes in different 05:27.880 --> 05:33.160 versions. We may have this great TPM, we have femo TPMs, and we also have TPMs on USB-T because 05:33.160 --> 05:41.000 why not. On this great TPM usually they are connected to the main slot using a spi-bus or an 05:41.000 --> 05:46.120 isqueci-bus. So the first plug-ing is going to abstract the platform and a pin control session 05:46.120 --> 05:52.280 into a file system session. So it hands just a fine. That's going to be dev-spi. But it does 05:52.840 --> 05:57.400 the red-white interface is just an extra abstraction to the bus. If we want to use it for the 05:57.400 --> 06:02.840 TPM, we will need the TPM-T. This is going to be to translate the ability to write a full 06:02.840 --> 06:11.480 command and under all the bus operation. For X86, we have the TPM CRB, so TPM can be accessible from the 06:11.480 --> 06:16.520 command response buffer interface. In that case, we can directly write the all command to the bus. 06:16.520 --> 06:23.560 So in that case, we all directly have the TPM row file. And finally, for USB-C, we are taking 06:23.560 --> 06:29.000 advantage of a cool feature of the genome that is actually too. So on a higher level, we bought 06:29.000 --> 06:35.000 the TPM 2TSS library, so client application can use the TPM. This library comes from the Linux 06:35.000 --> 06:42.120 world and expects a dev TPM zero device. The TPM max provides this device. It multiplixes the command 06:42.120 --> 06:48.760 if different components wants to access the TPM. But most importantly, it loads an unload 06:48.760 --> 06:56.280 object-manage method resources. As I said, the TPM is a discrete device. It has a hue, a persistent 06:56.280 --> 07:01.480 object, but most of the time, when you want to do an operation, you will need to load in advance 07:01.480 --> 07:06.520 first, so that you need, and then you can buffer an operation. And then you need to unload 07:06.520 --> 07:14.440 this resource. Otherwise, you are not going to be able to perform many operations. This component 07:14.440 --> 07:18.840 does that for you. So the application that has 200 at this level, this resource management. 07:18.840 --> 07:23.880 On Linux, we have the TPM 2, AB, Air and D, which comes also for the Linux world, but it's way 07:23.880 --> 07:29.160 to complex for a use case. And also, we want to keep the TPM as much as possible. So step 07:29.160 --> 07:36.840 120 road, the TPM max, a simple AirFest plugin keeping the TCC small. 07:40.440 --> 07:45.720 Now, the Troso Trost Anker. So it's a file plugin. What must it do is generate the CBE 07:45.720 --> 07:51.000 secret key. And it's in the CBE key on a persistent file system. What the system is brought 07:51.000 --> 07:56.040 down, and later on it turns it on, and you want to unlock your CPE again. For that, we use the 07:56.040 --> 08:03.800 TPM 2, TSS library that reads the TPM 0 file from the TPM max. It uses a policy session for PCR 08:03.800 --> 08:09.080 and password authorization. This is where whole the magic happened. Remember, at the beginning, 08:09.960 --> 08:14.920 you were using visual boots, and at that thing, our boot chain, we have measured all the boot 08:14.920 --> 08:20.440 components of the operating system. So when we reach the state of the full of the running operating 08:20.440 --> 08:26.120 system, all the PCR has be extended, we think that matters to us to be measured. We will use 08:26.120 --> 08:39.960 those value to authorize certain operation on the TPM on top. Let's have a look at which function 08:39.960 --> 08:45.720 actually the Trost Anker will use from the TPM 2, TSS library. Here, there is actually an important 08:45.720 --> 08:51.880 detail. When the Trost Anker is constructed for the first time and access the TPM, we will need to 08:51.880 --> 08:58.120 provision it. In this specific case, for the sake of simplicity, if it's not provision, what we're 08:58.120 --> 09:04.040 going to do is create a policy PCR, and for that we're going to select a set of PCR and a value 09:04.040 --> 09:09.880 and they're going to result in a digest in the policy. Then we are going to ask the TPM to create 09:09.960 --> 09:17.240 an empty space, and this space is one of this persistent object in the TPM. And we are going to write 09:17.240 --> 09:23.080 this policy digest that we just created in there. And we select the policy, the PCR we want, 09:23.080 --> 09:28.440 using this policy PCR. And this time, we result with a digest, we're going to do policy 09:28.440 --> 09:33.640 authorized, and what happened in the TPM is that the digest that is in the policy is compared 09:33.640 --> 09:39.080 again to one in the end of the run. Those two methods match. In the result operation, whether 09:39.080 --> 09:46.120 the policy is authorized, it's not. Then we will extend this policy with the password. This is 09:46.120 --> 09:52.200 basically the password, the user provide. The result digest is basically wrapped into the private 09:52.200 --> 10:02.200 part of the key we are using to seal the secret key. On the TPM, when you generate a key, the 10:02.200 --> 10:05.960 private part that you get and store on your system is always encrypted, so you can't access 10:05.960 --> 10:12.200 the actual private key, only the TPM can. And then we are basically done, we have our RAP secret 10:12.200 --> 10:18.040 key. Later on we want to unseal, so we load our secret key, we will recreate our policy again, 10:18.040 --> 10:22.760 we autorize it and again at the end of the run, we set the policy password, and if everything 10:22.760 --> 10:26.760 is authorized, then we can actually unseal from the private key and get the secret key. 10:32.200 --> 10:42.200 First of all, I haven't talked about the different key, but there exists a different 10:42.200 --> 10:47.880 key on which you can create different keys and a primary key that you have derived 10:47.880 --> 10:53.160 all the keys. And those different key are different property. We have been using the owner 10:53.160 --> 10:58.680 year, and the owner used the TPM owner, we want to set the owner password. In that case, we 10:58.680 --> 11:03.640 don't have any input GUI to provide it, so we assume it's not set, which on a positive 11:03.640 --> 11:08.920 environment we shouldn't do that. Later on, we also don't have input GUI to set to provide 11:09.640 --> 11:15.160 the password, the old value for the end space. So it means that when we provision the TPM in 11:15.160 --> 11:20.760 the first place, we have created the random, and we set this is the password to access the end space. 11:20.760 --> 11:26.120 We wrote it, and as soon as we are done, we get rid of the password. This is a problem, 11:26.120 --> 11:31.320 because this means that now we have brittle PCRs. We are protected from an attacker, it's very 11:31.320 --> 11:36.200 good. No one can change the LVRM, and no one can pretend, putting another system. Now, 11:37.240 --> 11:41.720 we rest in a trusted state. You can't do that. The problem is, if you're using an operating 11:41.720 --> 11:46.760 system such as code, and you're updating to the next version, you pull the C for PCR, 11:46.760 --> 11:52.280 are not matching again. So you can't unlock the CB anymore. So for that, we need a mechanism 11:52.280 --> 11:59.000 to update the PCR values to actually update the policy digest into NVR, and when the PCR 11:59.000 --> 12:03.800 values change, because of the system update. Finally, and most importantly, the biggest problem 12:03.800 --> 12:10.040 we have is the TPM. Two TSS depends in the ellipse C. So a problem that might not be obvious 12:10.040 --> 12:15.160 in the first place is that everything is running in file systems. Those are file system plugings. 12:15.160 --> 12:20.760 Displayable, you may need such things as an allocator. There is to it to proceed. As I provide 12:20.840 --> 12:26.760 a minimal ellipse, that is not filling on the VFS, only to perform operational such as 12:26.760 --> 12:33.320 allocation, or eventually just armor, damage with patches on top of the libraries. 12:37.240 --> 12:45.320 The lesson's run. TPM are hard. Most notably, we had a case where we sealed a key, and then we 12:45.320 --> 12:50.280 unsealed it, and the unsealed value is not matching the value we sealed, because something I haven't 12:50.280 --> 12:55.320 mentioned earlier, but we were using a parameter encryption. This means any sensitive data 12:55.320 --> 13:02.120 provided to the TPM is not visible to a potential observer on the bus. And if it's not done properly, 13:02.120 --> 13:07.160 eventually you might take a quick garbage and just get garbage in the return. But there is a good 13:07.160 --> 13:15.160 advantage is providing vitamins instead of bank healers when using the TPM. Finally, again, using TPM 13:15.160 --> 13:19.640 to TSS, and then getting open as a challenge when using the VFS when they depend on the 13:19.640 --> 13:26.760 ellipse. And also, what's really neat with the file system plugging architecture is that it's a very 13:26.760 --> 13:32.280 good way for my perspective to organize the complexity of all these things together and to expose 13:32.280 --> 13:36.280 them to third party application or subsystem without having a huge monolid block. 13:39.480 --> 13:40.440 Thank you for your attention. 13:46.120 --> 13:51.560 Thank you Alice for this great talk on a very important subject, and we have lots of time for 13:51.560 --> 14:00.200 questions, because this is the last last one. So, good question. I have a question. What you've 14:00.200 --> 14:05.640 described so far seems to be mostly focused on aesthetic wood of trust. Have you also looked 14:05.640 --> 14:10.040 at the dynamic wood of trust, who did NPCOS 17 and 18? 14:11.000 --> 14:15.400 Now, I think I've got answer this question because my knowledge are limited to this. 14:15.960 --> 14:20.760 However, what we are planning to fix this to have non-britled BCR is to use sign policy and to 14:20.760 --> 14:25.640 rather provide the policy about the wood image and to let the TPM recognize this policy saying 14:25.640 --> 14:30.280 all this was decided by trusted authorities, such as example our company or any provider of the 14:30.280 --> 14:35.080 wood image, and then said, okay, now we can load this policy that contains the RPCR value. 14:35.080 --> 14:37.400 But there is certainly also mechanism that I'm not aware of. 14:40.040 --> 14:46.360 It's just that recent versions of Novok provide this TXT image of launch, where you don't have 14:46.360 --> 14:51.560 to rely on a wood loader and is long chain of trust anymore, and that Alexander at some point 14:51.560 --> 14:56.600 gets to the point where this becomes generally usable for G-node, I think you'll benefit from 14:56.600 --> 14:57.960 the TPM. 14:57.960 --> 15:00.200 Any other questions? 15:00.360 --> 15:12.360 So when you have mentioned the USB here, I did not apply to G-node this question. 15:12.360 --> 15:16.120 I'm here, but it's SPI, but it's certainly just a bug interface as well. 15:16.120 --> 15:20.120 The motivation I think that it was on in the first place, so Stefan Tony, when they came to me 15:20.120 --> 15:22.280 and said, oh, look, I have done that and we finally can use. 15:22.280 --> 15:28.520 He said, must this reason right now, unfortunately, doesn't have to use this on a Linux platform, 15:29.400 --> 15:34.840 this TPM to go, you need a version of TPM 2TSA that is recent enough that it contains the proper 15:34.840 --> 15:38.920 TCTI that's not willing from TPM 0, but using your USB. 15:38.920 --> 15:44.520 So, unfortunately, it's very difficult to rebuild yourself to TPM 2TSA, it's not difficult to 15:44.520 --> 15:47.640 but update it on your system because you break a lot of dependencies. 15:47.640 --> 15:53.720 So, where we say is, oh, maybe it's actually just easier to create this for G-node and using it 15:53.720 --> 15:56.360 from G-node because what we want to do is G-node development. 15:57.320 --> 16:02.680 So, that was the first motivation, but I think we will certainly come with support on top of 16:02.680 --> 16:03.640 base-ish typically.