WEBVTT 00:00.000 --> 00:10.160 Okay, well, hello, I'm here, and I'm on the other side of the campus, and I've developed 00:10.160 --> 00:14.680 spoke as part of my own program at the CaliLover, and it's a provision of a professor from 00:14.680 --> 00:18.000 Duke, and a professor of business. 00:18.000 --> 00:23.000 So spoke is a risk-related, and it's so full-base in the sense that it's only a 00:23.000 --> 00:30.000 device on a very basic risk-wise, so it just uses PMP to ensure confidentiality, but 00:30.000 --> 00:34.600 it only uses PMP and machine mode and user modes. 00:34.600 --> 00:39.600 And this is important because spoke is really directed at super low-end of all risk-ship, 00:39.600 --> 00:46.080 so it's really directed at embedded devices side-of-things, so it's a little different 00:46.080 --> 00:47.080 from a keystone. 00:47.080 --> 00:52.520 You might know Keystone, Keystone is another risk-5, so full-base, so multi-so-for-base, 00:52.520 --> 00:59.680 T.E., spoke is a like keystone, but Keystone is not that suited for embedded devices. 00:59.680 --> 01:04.240 spoke is heavily based on Sankers, Sankers is a mobility that has to take a closer, but 01:04.240 --> 01:10.640 Sankers is more hardware-based, and at the beginning, as spoke was a like Sankers, but 01:10.640 --> 01:17.000 in the end it ended up a little different, which means a so-share system or terminology, and 01:17.000 --> 01:20.200 API is quite similar. 01:20.200 --> 01:24.400 So first for the problem statement today, I will discuss the Q and Execution, I will 01:24.400 --> 01:29.480 then spoke at the station, of course, and I'm just going to introduce the terminal situation 01:29.480 --> 01:36.680 on some terminology, so the IP on the infrastructure provided is entity that controls all 01:36.680 --> 01:43.080 the different nodes, so the nodes are marked not until node N here, and the nodes are 01:43.080 --> 01:48.800 just some risk-free embedded devices that could be almost anything, and the software 01:48.800 --> 01:54.800 provided is well-authent to deploy several modules called N-claves on to each of these nodes. 01:54.800 --> 01:59.600 We call these N-claves and let's say several modules, because we all would use them as M-for-securety 01:59.600 --> 02:05.280 management, we'd get a bit confusing, so the software provided has two N-claves on the first 02:05.280 --> 02:10.680 node, N-clave 1 and N-clave 2, and the second software provided has one N-clave on the first 02:10.680 --> 02:15.160 node N-clave 3, and on the last node, it has got N-clave J. 02:15.160 --> 02:21.800 Okay, aside from these N-claves, N-claves also got its own interested operating system, and 02:21.800 --> 02:26.600 we call this the interested operating system, because we work on the assumption that operating 02:26.600 --> 02:29.480 system also in the full control of the attacker. 02:29.480 --> 02:34.960 So our spoke works with the dial of your attacker model, so we assume that the attacker can 02:34.960 --> 02:40.360 do any kind of software basic, so an attacker can also be deploying an N-clave, so an attacker 02:40.360 --> 02:46.160 could potentially try to deploy an N-clave to one of the nodes, and then you have the security 02:46.160 --> 02:50.200 manager, and that's actually the task of spoke, so spoke is the security manager, and it 02:50.200 --> 02:55.080 oversees the execution of the N-claves and other interested operating system. 02:55.080 --> 03:01.880 Now, I'm going to make a bit of an other oversimplified analogy, so in an owner operating system 03:01.880 --> 03:07.080 you have got a program, so you got an operating system, and if I were in the techie, I wanted 03:07.080 --> 03:12.120 to temper with, for example, the blue program, there are two weights to go about, is I could 03:12.120 --> 03:17.560 take control of the operating system, and then interfere with the blue program, or I could 03:17.560 --> 03:25.160 try to attack the blue program directly from some other program, basically, okay. 03:25.160 --> 03:29.960 In spoke, we partition the memory into three parts, it doesn't need to be this partition 03:29.960 --> 03:34.040 this is just an example partition, you can actually configure this, the first partition 03:34.040 --> 03:38.680 is for the security manager, it's for spoke, and the second part is called the blue prison, 03:38.680 --> 03:42.200 or I'll get into the second part called the blue prison, and the last partition is for the 03:42.200 --> 03:48.520 resource operating system, and in the blue prison we will store the N-claves, and as you can see, 03:48.520 --> 03:54.440 N-claves don't need to be contingent, so one N-clave is the gainingclave has two different parts, 03:55.480 --> 04:00.680 and this is because N-claves exist out of a small entity called the blue-frame, and the blue 04:00.680 --> 04:04.920 free is basically the atomic units in which spoke appropriates, and this is just a piece of 04:04.920 --> 04:09.480 memory, with some permissions for the given N-clave, and also experimental version of spoke, 04:09.480 --> 04:14.440 there aren't in line yet that can share, this was not a small instance now, and each N-clave 04:14.440 --> 04:20.360 can basically have a text section to put an executable code and a section to add data to the data 04:20.360 --> 04:27.000 section, and you can initialize and give N-claves both widths or without data section, okay. 04:27.960 --> 04:34.280 Now, the interested opening system cannot access the security manager, and it can also not access 04:34.280 --> 04:42.120 buffers, so when a software provider wants to actually initialize a new N-clave, it first makes 04:42.120 --> 04:47.480 the secure connection to the infrastructure provider, then to a specific note, and it can then 04:47.480 --> 04:54.120 send to the opening system, the N-clave, it wants to deploy. The interest opening system cannot 04:54.120 --> 05:00.760 access access the buffers and directly, but it can use a sort of system calls to interact with 05:00.760 --> 05:04.920 the security manager in order to actually deploy an N-clave in the buffers zone, basically. 05:06.120 --> 05:11.400 Optionally, you can also place an N-claves instead, and in that case, you can actually deploy 05:11.400 --> 05:15.960 an N-clave to the N-clave, so the interest of the existing system even doesn't get access to the 05:15.960 --> 05:21.880 concrete code of the N-clave, but this is just optional. When our software provider wants to win, 05:21.880 --> 05:26.040 an N-clave, it can just send a signal to the untrusted operating system, and an untrusted 05:26.040 --> 05:31.480 operating system can then pass through the arguments, also can be optionally encrypted to the 05:31.480 --> 05:35.160 concrete N-clave that needs to run it, and the security manager will basically run it, 05:35.160 --> 05:40.280 and it can fully forward the same goes for input-ecting the N-clave, the sold-on by the security 05:40.280 --> 05:46.760 manager. It's kind of an old-looking OS, and of course, the situation is also to the security manager. 05:47.720 --> 05:55.640 Now, N-claves cannot access the code, but they can access their own buffers, okay. 05:58.200 --> 06:07.000 And this is basically accomplished using PMP entries, so when the security manager is running, 06:07.000 --> 06:10.360 it's really a machine mode. It's not only requires machine use modes, 06:10.360 --> 06:15.880 contrary to Keystone, who also requires super-surprise mode, but only uses a machine 06:15.880 --> 06:21.080 use mode. An machine mode is the security manager that oversees the execution of the 06:21.080 --> 06:26.200 buffers or of the N-claves, and all of the untrusted operating system. And basically, when you 06:26.200 --> 06:31.480 make a system call, we will switch back to machine mode, and the security manager will run, 06:31.480 --> 06:36.440 and after it's done, it will switch back to user mode to either an N-clave or the untrusted operating 06:36.440 --> 06:43.560 system, and in user mode, well, you cannot access a password memory, protected by PMP entries, 06:43.560 --> 06:50.600 obviously, so that's how our spoke operates. Okay, then a neat little feature of spoke, 06:50.600 --> 06:57.720 that's not that standard, is that spoke both allows to use relocatable enclaves and fixed enclaves. 06:58.520 --> 07:05.240 So a fixed enclave is basically just an enclave, that is loaded into a fixed part of the memory, 07:05.320 --> 07:09.960 and this is very useful because of a loaf and that is the vices use memory-maps IO. 07:09.960 --> 07:15.400 And for memory-maps IO, you need to be able to load an enclave in a certain part of the memory. 07:15.400 --> 07:21.640 For example, if you have some kind of cooling system and a first enclave control with cooling system, 07:21.640 --> 07:26.920 it needs to be able to write to the memory-maps IO. And to search that, you can basically just 07:26.920 --> 07:32.680 give the evidence with the memory-maps IO, and you can load in the double section of specific 07:32.680 --> 07:37.640 address. And when you test the enclave, it will also attest that the enclave is loaded in a 07:37.640 --> 07:45.400 correct place in memory. Now, sometimes it's more convenient to also allow for enclaves to be relocatable, 07:45.400 --> 07:52.840 and that's why spoke allows both in combination. So you can use first a fixed enclave to 07:52.840 --> 07:57.560 give the enclave access to the memory-maps IO, and also that you can use a second enclave 07:57.560 --> 08:02.760 that uses realocatable codes. And this is shown here. So the first enclave is fixed, 08:02.760 --> 08:07.400 and the second enclave is a realocatable enclave. And there is a little problem with realocatable 08:07.400 --> 08:11.480 enclaves because they do not know where the data section and text section is exactly. 08:12.040 --> 08:15.960 It spoke basically, says that by using a little buffer within the enclaves to pass 08:15.960 --> 08:22.200 across the address of the text and the data section to the enclave. This makes attestation a little 08:22.200 --> 08:28.440 difficult, but they basically treated the same after initialization and there are a few tricks 08:28.440 --> 08:34.440 to get this working without having to keep any extra data about the enclaves. 08:35.320 --> 08:40.200 Now, the last thing I want to mention about secure execution in spoke is that 08:41.480 --> 08:46.440 so how spoke basically works is not yet a enclave always there. They're not 08:46.760 --> 08:54.520 persistent in a sense that they always complete enclave a concrete pmp entry, and enclaves only 08:54.520 --> 08:59.160 exist when they're running. So when spoke switches to the intrusive opening system or to an 08:59.160 --> 09:04.120 over enclave, the enclave really doesn't exist, and it's just only present in the SM state. 09:04.120 --> 09:10.120 And spoke basically, swap out the pmp entries. And this allows for many more enclaves than would 09:10.120 --> 09:14.920 be normally possible with a limited amount of pmp entries. As I said, allows for enclaves to use 09:15.000 --> 09:19.400 different buffers at different times. So it's possible to have an enclave, give it access to 09:19.400 --> 09:24.520 a certain buffer, then introtect the buffer and give the enclave another buffer, it's also possible. 09:26.280 --> 09:32.680 So it can be quite convenient in a lot of situations. Okay. Now, at a station, only one slot 09:32.680 --> 09:37.800 or attestation, I'm just going to give a high level overview of how attestation focuses in spoke. 09:37.800 --> 09:44.120 So spoke works with a key hierarchy that's very similar to the Sanker's key hierarchy, 09:44.200 --> 09:48.200 as the top of the hierarchy you have a note key, that's a key specific to each note and it's just 09:48.200 --> 09:54.840 randomly generated. And we then use a key derivation function, the Kdf over there. To basically 09:54.840 --> 10:00.680 derive a key specific for each software provided when it makes a secure connection through that note. 10:00.680 --> 10:05.960 And after we have a key for the software provided, we can basically make a key for each 10:05.960 --> 10:11.880 enclaves specifically using that enclaves hash. And this key contains all the information we need to 10:11.960 --> 10:18.680 attest the enclaves. In practice, we also give a mince word to prevent ripple attacks with 10:18.680 --> 10:25.240 that's the basic ID of the key hierarchy. Okay. And spoke uses Hacker Star, Hacker Star is a 10:25.240 --> 10:31.000 firmly verified cryptography library, I highly recommend reading the book, it's a really nice 10:31.000 --> 10:40.280 paper. We don't need a lot of Hacker Star, I think spoke only uses some basic hash functions from Hacker 10:41.160 --> 10:46.600 Star. It would also be possible to add additional encryption in spoke. Okay. So, 10:46.600 --> 10:51.640 in practice, this is quite challenging because well, you have to divide the memory between the 10:51.640 --> 10:56.680 code. So, our spoke keeps some internal data structures, I haven't shown here, you need to keep 10:56.680 --> 11:02.680 something called the security manager states in check to make this work. And also, 11:03.880 --> 11:09.240 enabling the different enclaves to communicate back to software provided is quite challenging. 11:09.800 --> 11:13.640 We use a system with defects, with response defects. So, the enclaves can actually write to 11:13.640 --> 11:18.600 parts of the internal operating system. So, it can dispense to the software provided. And again, 11:18.600 --> 11:24.840 this also can be encrypted. And memory management, I've already discussed and there are also some 11:24.840 --> 11:30.200 cryptographic changes with data enabling fixed and relocate more enclaves. Okay. So, 11:30.200 --> 11:35.960 I've also done an evaluation of spoke, I don't think it's put online yet. And today, I'm only going 11:35.960 --> 11:42.040 to discuss the just computing base of spoke. Performance of spoke hasn't been tested, 11:42.040 --> 11:47.960 probably yet because spoke has really ran cameo and testing performance in cameo is a little sketchy 11:47.960 --> 11:55.960 to say the least. So, in memory, you have basically five main parts of spoke here for Hacker Star. 11:55.960 --> 12:01.320 That's basically just a hashing function function utility. You have the security 12:01.320 --> 12:07.160 as some state manager has basically the internal, well, we call it data base of all the enclaves. 12:07.160 --> 12:13.320 And the code surrounding that data base, then I have about 60 kilobytes for PMP dimensions, 12:13.320 --> 12:18.040 which is basically shopping out to PMP entries. And then you have the security measure, 12:18.040 --> 12:22.680 which is just the main part of spoke. And then something called intrusive library. 12:22.680 --> 12:27.640 The intrusive library is not part of the DCB. It's just some utility, I provide to make it 12:27.640 --> 12:32.680 easier to communicate with spoke because this is called to the SM can be quite challenging. 12:33.720 --> 12:39.800 Okay, so this is the future works on spoke. First of all, here's silicon iteration would be 12:39.800 --> 12:47.640 very nice. We've already found a candidate, the SP death kit, C02, spoke only bit us from 12:47.640 --> 12:52.600 in the next year. Some of the verification spoke with us, so we really nice option. 12:52.920 --> 12:57.320 Though it would be challenging because spoke is both written partially in assembly and C. 12:59.160 --> 13:03.480 The nice thing about spoke is that it only relies on PMP. And it has already been updated by 13:03.480 --> 13:08.760 the autos of Keystone, but I found it very fast, risk failed PMP. And Hacker Star is also, of course, 13:08.760 --> 13:13.400 fully firmly verified, but it still will be quite challenging. And availability, 13:13.400 --> 13:18.680 assuring availability is also quite important for spoke because it will, if it's several years 13:18.680 --> 13:25.800 to probably run system that have real time constraints. And this could be fixed by adding a simple 13:25.800 --> 13:32.120 schedule or something more advanced, like the time code system or all keystone. Okay, so in conclusion, 13:32.120 --> 13:40.360 spoke is a mostly software based DE that provides acute execution and adaptation. And it's very 13:40.360 --> 13:47.800 compact, so it can actually run on embedded systems. Okay, that was my presentation, any questions? 13:48.760 --> 14:00.760 Yes, the gentleman in the back. 14:00.760 --> 14:04.680 Okay, speak a bit up. I'm saying that that was very nice work. 14:04.680 --> 14:11.880 Public vacation is a key point because we are talking about systems. So one of the questions that I have 14:11.880 --> 14:17.000 to mention for my presentation is for the works that we need to explain to you, or do you 14:17.000 --> 14:23.960 are interested in it? So is there some code code part that you are trying to find? So you 14:23.960 --> 14:29.000 have to add a station code code, and a station code code? And a station code, oh yes, sorry. 14:29.000 --> 14:35.000 So is there any part of a station code code that you have already been found or are you 14:35.000 --> 14:43.240 planning to be found? Well, also, I have to be the question of course. So the question was, 14:43.240 --> 14:48.520 if I have already verified a part of the attestation protocol, no I have not. So the attestation 14:48.520 --> 14:55.320 protocol is verified in a sense that a heck of stock is basically attestation. All of the 14:55.320 --> 15:01.160 attestation is then using a heck of a stock, and a stock has been formally verified, but 15:01.240 --> 15:05.880 well, there are some steps between a heck of a stock and actually getting the attestation, 15:05.880 --> 15:13.000 and those haven't been formally verified. I'm not quite sure how 15:13.000 --> 15:19.320 form of verification will be done, it's possible, it's a subtle part. It hasn't been formally verified yet, 15:19.320 --> 15:31.000 no. So are you using a MP or a MP MP? No, I'm using a reasonable, some of MP I think. 15:31.000 --> 15:34.000 There is five, I hope, we have data that we have 15:34.000 --> 15:37.000 educational response, and we've added, and you know, 15:37.000 --> 15:39.000 started moving a special approach. 15:39.000 --> 15:41.000 We've got a new service and extension to be in these 15:41.000 --> 15:44.000 calls, TPMP, and we can use it to better isolate 15:44.000 --> 15:46.000 and mode from, you know, because now, 15:46.000 --> 15:49.000 every kind of other route to the NP towards the 15:49.000 --> 15:52.000 access framework, in which case we have, you don't have 15:52.000 --> 15:54.000 access, and it's a key recognition from 15:54.000 --> 15:56.000 member of the system, probably very, very, 15:56.000 --> 15:57.000 it's a problem. 15:57.000 --> 15:59.000 So, however, then you provide access to the 15:59.000 --> 16:01.000 community, and you also provide 16:01.000 --> 16:03.000 access to the NP from that region. 16:03.000 --> 16:05.000 There is isolation to the NP. 16:05.000 --> 16:07.000 At least, I don't have a link. 16:07.000 --> 16:09.000 Yeah, in the package. 16:09.000 --> 16:11.000 Oh, sorry. 16:11.000 --> 16:15.000 The question was, if I use EPMP or PMP, 16:15.000 --> 16:19.000 so to be very close, focus only on KMU right now. 16:19.000 --> 16:23.000 So, it's on Spike, and I think it's actually just 16:23.000 --> 16:27.000 PMP, but it's something to consider for sure, 16:27.000 --> 16:29.000 when I actually implementing this order, 16:29.000 --> 16:31.000 you still can chip to use EPMP instead. 16:31.000 --> 16:35.000 Is KMU got a EPMP? 16:35.000 --> 16:36.000 Yeah. Okay. 16:36.000 --> 16:39.000 Well, something to consider then. 16:39.000 --> 16:43.000 How is this difference from the HX5, 16:43.000 --> 16:47.000 might this own sort of security difference? 16:47.000 --> 16:49.000 Do you happen to know? 16:49.000 --> 16:51.000 Yeah, I do happen to know. 16:51.000 --> 16:53.000 So, how is this difference from the, 16:53.000 --> 16:55.000 I keep forgetting. 16:55.000 --> 16:57.000 I was a different from HX5. 16:57.000 --> 17:00.000 Could you quickly interpret HX5? 17:00.000 --> 17:03.000 Because it's been a while since I've heard the pilot's paper. 17:03.000 --> 17:05.000 The company, but they have a developer approach, 17:05.000 --> 17:09.000 where they also try to have an N-clave-based 17:09.000 --> 17:13.000 solution using sort of purely the machine use 17:13.000 --> 17:15.000 a mode separation as far as I remember. 17:15.000 --> 17:17.000 In their mighty zone approach, 17:17.000 --> 17:21.000 to basically compartmentalize on claims 17:21.000 --> 17:23.000 are the different code regions. 17:23.000 --> 17:25.000 I haven't followed up the work, 17:25.000 --> 17:27.000 so I don't know what happened to it. 17:27.000 --> 17:29.000 Probably it's not as popular as one my team, 17:29.000 --> 17:31.000 but maybe there are some shortcomings, 17:31.000 --> 17:33.000 but that's why it was possible. 17:33.000 --> 17:35.000 I actually think, well, 17:35.000 --> 17:37.000 I think I took some inspiration from some of that, 17:37.000 --> 17:40.000 so the similarity you've seen won't be coincidental. 17:40.000 --> 17:42.000 I've fully got HX5. 17:42.000 --> 17:44.000 If I remember correctly, 17:44.000 --> 17:45.000 as another AEMS, 17:45.000 --> 17:47.000 this is not aimed at embedded devices, 17:47.000 --> 17:49.000 HX5. 17:49.000 --> 17:52.000 So, Spook is really also aimed at embedded devices, 17:52.000 --> 17:56.000 and HX5 has a much larger to suit computing-based, 17:56.000 --> 17:59.000 and I don't think it's suitable for most risk-free 17:59.000 --> 18:00.000 the device. 18:00.000 --> 18:01.000 I might be wrong. 18:01.000 --> 18:04.000 But this is also not a microcontroller type of thing. 18:04.000 --> 18:05.000 It's not low end, 18:05.000 --> 18:08.000 this is also like the embedded line of space, right? 18:08.000 --> 18:10.000 It's a handy low end. 18:10.000 --> 18:13.000 There's no virtual memory, so you won't be able to implement it. 18:13.000 --> 18:14.000 No. 18:14.000 --> 18:15.000 Okay. 18:15.000 --> 18:17.000 Non-batch memory, but memory protection unit. 18:18.000 --> 18:19.000 PMP. 18:19.000 --> 18:20.000 All right. 18:20.000 --> 18:22.000 So, you took it out in memory map. 18:22.000 --> 18:23.000 I know, 18:23.000 --> 18:26.000 and you're over there lying on a plane. 18:26.000 --> 18:29.000 It's not essentially restricted. 18:29.000 --> 18:32.000 And it device to any being in one plane. 18:32.000 --> 18:34.000 Okay. 18:34.000 --> 18:38.000 So, he asked if I'm using the memory map title, 18:38.000 --> 18:40.000 and your question was, 18:40.000 --> 18:43.000 if it only sticks to the memory map title, 18:43.000 --> 18:45.000 or being in one end-clave, 18:46.000 --> 18:47.000 and it is not. 18:47.000 --> 18:52.000 Because you can still have multiple data sections over the end-mile. 18:52.000 --> 18:56.000 Every part of the end-mile specifically is for one end-clave. 18:56.000 --> 18:59.000 And this can be a bit challenging, 18:59.000 --> 19:02.000 because in some cases you do not multiple end-claves 19:02.000 --> 19:04.000 to have control over the same part of the end-mile. 19:04.000 --> 19:08.000 But this also can be said that you're spitting parts of the end-tracing system over the end-mile. 19:08.000 --> 19:10.000 And I'm living in an end-clave, 19:10.000 --> 19:12.000 and I'm going to respond to the end-tracing system, 19:13.000 --> 19:17.000 and then the drift drift operating system actually do the end-mile for the end-clave. 19:17.000 --> 19:18.000 Now, as I've said, 19:18.000 --> 19:20.000 there is already an experimental range of spook, 19:20.000 --> 19:22.000 who plays around with this idea of having shared spooks, 19:22.000 --> 19:24.000 for exactly that purpose. 19:24.000 --> 19:26.000 So it's a very good question. 19:26.000 --> 19:28.000 But right now, 19:28.000 --> 19:31.000 it's possible that moving the sense that you can have two end-claves 19:31.000 --> 19:34.000 with the same data section that's also protected 19:34.000 --> 19:37.000 over the same part of the memory map title. 19:37.000 --> 19:38.000 Thank you. 19:38.000 --> 19:40.000 Last question. 19:41.000 --> 19:42.000 Thank you. 19:42.000 --> 19:45.000 Did you already have done an disintegration with any real operating system? 19:45.000 --> 19:48.000 With any real operating system, 19:48.000 --> 19:52.000 I have, I've remembered only one time. 19:52.000 --> 19:53.000 Okay. 19:53.000 --> 19:57.000 So no, spook hasn't been integrated properly with any real operating systems, 19:57.000 --> 19:59.000 because in practice this won't also, 19:59.000 --> 20:01.000 this won't be Linux or any operating system, 20:01.000 --> 20:04.000 it will be probably a very tasty specific operating system 20:04.000 --> 20:05.000 for that chip, 20:05.000 --> 20:08.000 because these are embedded systems. 20:08.000 --> 20:09.000 So the operating system, 20:09.000 --> 20:11.000 we don't really look at it, 20:11.000 --> 20:12.000 because it's also, 20:12.000 --> 20:14.000 well, it's, it's the F-X-S-E, 20:14.000 --> 20:16.000 in all of my research. 20:16.000 --> 20:17.000 So we don't rely on it, 20:17.000 --> 20:18.000 but it would be interesting, 20:18.000 --> 20:21.000 because you could compare the performance, 20:21.000 --> 20:22.000 give an, 20:22.000 --> 20:23.000 a certain operating system, 20:23.000 --> 20:24.000 give a certain task, 20:24.000 --> 20:26.000 and compare it to all the operating systems, 20:26.000 --> 20:27.000 and compare them. 20:27.000 --> 20:29.000 So I think that would be a very interesting. 20:29.000 --> 20:30.000 All right. 20:30.000 --> 20:31.000 Let's say this speaker. 20:38.000 --> 20:40.000 Thank you.