WEBVTT 00:00.000 --> 00:12.520 Hello everybody, and welcome to my talk about single-image secure boots with Bevels. 00:12.520 --> 00:21.000 My name is Ahmed Fortun, I work for Pingotronics, we do embedded Linux developments and consulting. 00:21.000 --> 00:27.280 I think a lot of people here in the room might guess, a lot of our new projects, or most 00:27.280 --> 00:31.960 of them actually are employing some scheme of secure boots. 00:31.960 --> 00:38.800 This is mostly, I think, motivated by upcoming EU regulations, which should make it more difficult 00:38.800 --> 00:43.560 for digital products to be compromised. 00:43.560 --> 00:52.440 And in the embedded space that we are working in, this usually is, this is a, it's much 00:52.440 --> 00:56.400 of a call, a single-image interpreter. 00:56.400 --> 01:02.720 Yeah, and in the embedded space we are in, this usually takes the form of a verified boot chain. 01:02.720 --> 01:05.000 So I have two short slides about that. 01:05.000 --> 01:10.320 So usually you have some hardware root of trust in the form of if you use this for example. 01:10.320 --> 01:15.320 In these if you use this, which you can only burn once, so you only can change a 0 to a 1, 01:15.320 --> 01:17.040 but never a 1 to a 0. 01:17.040 --> 01:20.320 You can encode the hash of a public key. 01:20.320 --> 01:24.280 And using that hash of a public key, you can verify the boot loader. 01:24.280 --> 01:31.480 The boot loader itself will have, in its verified contents, a public key, which is 01:31.480 --> 01:33.640 used to verify the kernel image. 01:33.640 --> 01:39.280 If you don't want to use the same key, that you are also using to verify the boot loader itself. 01:39.280 --> 01:46.760 Then the OS image will contain, for example, the hash of a D&V root file system, and 01:46.760 --> 01:52.680 that will be used to verify all blocks within it, and now you have a chain of trust stretching 01:52.680 --> 01:59.440 from applications running in user space to the hardware with the keys that was burned in the 01:59.440 --> 02:01.720 factory. 02:01.720 --> 02:07.080 Of course, if you can mount and attack on the boot loader, all this securing is for 02:07.080 --> 02:11.720 not because you can compromise everything from the boot loader onwards. 02:11.720 --> 02:16.360 And because of that, you need to invest time to secure the boot loader if you are going to 02:16.360 --> 02:19.880 do a secure boot chain. 02:19.880 --> 02:24.360 And securing the boot loader is mostly about restricting stuff. 02:24.360 --> 02:30.080 So you restrict what can be done, what it can do, and you restrict what can be done with 02:30.080 --> 02:31.080 it. 02:31.080 --> 02:33.720 And this has far-reaching consequences. 02:33.720 --> 02:38.800 So development is certainly more awkward because you need to sign your images, always 02:38.800 --> 02:44.240 testing is more complex, because you wouldn't give access to a boot loader shelf, for example. 02:44.240 --> 02:50.480 And the kind of stuff we test, for example, if you have a watchdog, you want to decrease 02:50.480 --> 02:54.760 an attempt, and if you get the watchdog after an update, you want to roll back to another 02:54.760 --> 02:57.360 update to the old system, for example. 02:57.360 --> 03:01.680 This is very complicated to test when you don't have a boot loader shelf, because you can 03:01.680 --> 03:06.400 directly ask the boot loader and inspect the boot state, and because the development and 03:06.400 --> 03:12.360 testing is more complex, also maintenance will be more work, and overall complexity of 03:12.360 --> 03:18.720 the system is higher, the risk that you don't finish it on time, or that it costs too 03:18.720 --> 03:24.680 much as high as well, and of course the manufacturing, the factory setup, and the infield service 03:24.680 --> 03:28.960 when a technician goes to repair something, they will also need to be authenticated and 03:28.960 --> 03:31.640 authorized, so that's also more effort. 03:31.640 --> 03:39.720 So if you are going to secure a boot product, you will have to take this issue somehow. 03:39.720 --> 03:47.040 The thing is developer solve issues, so if the problem is, it is very awkward to develop 03:47.040 --> 03:52.360 for the hardware, they will find a way around this awkwardness, and for example, disable 03:52.360 --> 03:59.000 secure boot for the development, or use a different build, or okay, I had the build this 03:59.000 --> 04:03.960 boot loader that's unlocked, and I share it with all my colleagues for example, and of course 04:03.960 --> 04:08.640 that's not a workable solution, because in the end it means the state in the field is not 04:08.640 --> 04:16.520 adequately tested, and you don't want to debug two weeks before you're doing a null series, 04:16.520 --> 04:22.320 if you want to debug all my the integrities setup is taking so long, and now that I have 04:22.320 --> 04:26.440 a read only with FS, something's doing or to work, because we usually have an overlay 04:26.440 --> 04:33.320 FS for the development, so project risk is greatly increased if you do not account for 04:33.320 --> 04:41.280 how people are going developers or testers are going to use the product. 04:41.280 --> 04:48.280 And I found a nice way to visualize this when we think about device lifecycle, so the 04:48.280 --> 04:54.320 same hardware will have different states that it will be in, it will be a convenient development 04:54.320 --> 04:59.880 state, it can be in the factory for provisioning, it can be deployed in the field, it 04:59.880 --> 05:06.440 can be returned, and each one of them has a different profile or different threat modeling, 05:06.440 --> 05:11.360 what needs to be able to be done, so if you get a field return, of course you want to 05:11.360 --> 05:16.200 interact with the hardware, but maybe you should wipe the keys first, so you can access 05:16.200 --> 05:22.120 patient information for example, and you need to look at all of this, and the way I see 05:22.120 --> 05:28.720 it done in many projects is that you encode the lifecycle state into an image, so you have 05:28.800 --> 05:34.720 this image is used for the factory, this image is used in production, this image is used 05:34.720 --> 05:38.600 when we have a field return, it might be the same image for factory and field return for 05:38.600 --> 05:45.760 example, but this is a disaster waiting to happen if that image leaks, here is an example, 05:45.760 --> 05:52.800 so Nintendo for the Wii and the Wii U setup, they had special SD cards with a special factory 05:52.880 --> 05:59.440 bootloader, and then after they were done with them, they gave them to their contractor, 05:59.440 --> 06:07.120 they were crushed, broken, thrown away, resourceful people were able to get a hold of them, 06:07.120 --> 06:13.600 with some, I like the way they phrased it, with a little straightening and convincing I was able 06:13.600 --> 06:18.960 to recover the data, of course that's not the bootloader, that's actually deployed everywhere, 06:19.040 --> 06:25.520 and it had much less eyes on it, much less usage, and they found exploits in it that allowed 06:25.520 --> 06:35.520 them to roots the devices, so just using the image to handle a lifecycle state is not adequate, 06:35.520 --> 06:42.960 because any leak would be disastrous, and thus the image should verify that the status correct, 06:43.840 --> 06:49.760 so for example you have an e-fuse, and you burn that e-fuse in the factory, and after that the 06:49.760 --> 06:55.520 image will check the e-fuse, oh it's burnt, I will not do anything anymore, so the factory 06:56.320 --> 07:01.280 image is only valid as long as this e-fuse is not burnt, or devices that are returning from 07:01.280 --> 07:05.920 the fields, they have field return e-fuse, and when that field return e-fuse is burnt, 07:06.800 --> 07:11.760 wipe all data, unlock the device, but you can't go back to the normal, so you have 07:12.080 --> 07:20.880 fuses that mark how you transition through states, and once you have that you can go the extra step 07:20.880 --> 07:26.880 and have the same boot image handle multiple of these lifecycle states, because it's already 07:26.880 --> 07:32.560 has to verify that a fuses burnt, then you just need to implement fallback behavior basically, 07:33.600 --> 07:38.960 and one can argue that this increases complexity, but I would rather argue that it just shifts 07:39.040 --> 07:46.080 complexity around, if you have a lot of multiple images, the complexity is in the way you do testing 07:46.080 --> 07:53.280 and the way you maintain the complexity is like in the whole workflow and infrastructure around 07:53.280 --> 08:00.080 it's that you need to juggle these images around, but if you put this complexity in runtime by having 08:00.720 --> 08:09.680 by knowing I am in this lifecycle state, I will do that, you make it, you move it to a place where 08:09.680 --> 08:14.400 it's more easily auditable and you can run tests against it and so on, and yeah that's enough for 08:14.400 --> 08:20.640 the theory, and I have some more practical example, but yeah in summary what I want to say is 08:20.640 --> 08:26.240 if you are the image is the better I think, and a single image is achievable, and I think it brings 08:26.320 --> 08:36.320 real benefits, so an example for a few space state transitions and opti, so opti, which is 08:36.320 --> 08:44.160 a trusted execution environment maintained by Leonardo, it's like what you would normally use 08:44.160 --> 08:50.080 on many embedded systems, and often it's provisions with device specific certificates in the factory, 08:50.080 --> 08:56.320 so you want the device to call back into the mother cloud, and then it has a device specific 08:56.320 --> 09:04.480 certificates, and these certificates are stored into replay protected the memory, and you can only 09:04.480 --> 09:13.040 do the storage, after you have written a key into the EMMC, which the EMMC will save in some 09:13.120 --> 09:22.320 secrets place, and then sock can, I think, authenticate as a correct word, authenticate, 09:22.320 --> 09:31.120 so what the EMMC was an HMAX that stuff is authorized to be stored there, so yeah, and the thing 09:31.120 --> 09:37.200 is because you can only, because you need this sock specific key, it can only happen after 09:37.200 --> 09:42.560 secure boot is enabled, so in your factory step, you must, after having enabled secure boot, 09:43.360 --> 09:50.080 verified boot, write this RPMV key, and now if you had an image that writes this RPMV key, 09:50.080 --> 09:59.520 and it leaks, then people could modify the RPMV contents, if they reuse that image, opti has an option 09:59.600 --> 10:06.000 config RPMV writes key, yeah, and if you enable it, it will ask the EMMC, do you have a key, 10:07.840 --> 10:14.400 built in our key program, if it's not programmed, it will transfer a new key, and you can't have 10:14.400 --> 10:20.960 opti every time asking the EMMC, are you programmed, because on attacker, could just disolder the EMMC, 10:20.960 --> 10:26.880 add a fresh EMMC, the fresh EMMC will answer, yeah, of course, I am not programmed, and then you can just 10:26.880 --> 10:37.040 snoop the clear text sending off the key on the bus, and yeah, and to cartelset, my colleague Marko 10:37.040 --> 10:44.480 Phelch made some cool requests for opti, and the idea is that instead of having one image where we 10:44.480 --> 10:50.400 always enable RPMV write key, and one image where we always disable it, we always enable RPMV 10:50.400 --> 10:57.360 key, but before the key writes, we always check is a specific if you've burned or not, and after 10:57.360 --> 11:06.160 the key writes, we blow the if use, and this way we have in our lifecycle graph a link that only 11:06.160 --> 11:11.840 goes into one direction, so it was in unprovisioned EMMC state, now it's in provisioned EMMC state, 11:11.840 --> 11:18.960 and you can just do a replay and get the keys this way, for that he added for one opti, one time 11:18.960 --> 11:25.040 had support for I am exprocessed as to opti, there is an open request for that, and there was a 11:25.040 --> 11:33.200 second pull request to do this fuse, checking, and writing an opti, there was a very fruitful 11:33.200 --> 11:41.520 upstream discussion about, yeah, about how to do this better, so there will be a second pull request 11:41.520 --> 11:48.160 coming, and some form of replay protection in addition, but it would still be gated behind 11:48.720 --> 11:55.680 an if use, and I think we can use this model of gating stuff behind the if use at many more places, 11:56.880 --> 12:02.080 and with that we eliminate the image, the different image that we usually would have. 12:04.160 --> 12:09.520 Another thing I wanted to show is access control, and access control in the bootloader, 12:09.600 --> 12:17.680 so that's not something that's usual it's on, and the status quo is that one time access control 12:17.680 --> 12:22.640 in the bootloader is a mess, because everyone using the bootloader in a different way, and everyone 12:22.640 --> 12:28.000 defines the old threat model, and what might be secure for one is not secure for someone else, 12:28.000 --> 12:33.200 and if you are writing your own bot code, whether it be in u boot or a barbox, it will be 12:33.200 --> 12:39.440 very complicated stuff where you push into the guts of the bootloader to selectively enable 12:39.440 --> 12:45.280 or disable features, and that's the way you would handle different security states. 12:45.280 --> 12:49.520 So for example, here's an example from bearbox, it doesn't look very nice, so it checks 12:49.520 --> 12:54.960 a locked-in variables that you for example got from the one time pad, and if it's set, 12:54.960 --> 13:01.040 you can call boot and force signed images, this is a function that in forces, that fit image 13:01.040 --> 13:07.760 is must be signed, and you can't get back from that, and alternatively if that's not the case, 13:07.760 --> 13:16.000 it will get the console, and enable it and switch it to the open pin-mook state, and yeah, 13:16.000 --> 13:20.880 this is a lot of specialized code, no one can keep all of that off mind, and it's easy to get 13:20.880 --> 13:28.560 something wrong with that, and no one is upstreaming this code, so this is why this is more 13:28.560 --> 13:33.760 infrastructure, it's both specific and no one bothers to upstream it, which makes every project 13:33.760 --> 13:39.760 reinvents the wheel. For bearbox, I introduced last year, bearbox security policies, 13:39.760 --> 13:47.280 and the idea is that you have these allowed markers that can check specific security decisions, 13:47.280 --> 13:52.880 and at the privileged operation itself, so insights that get sharp function, which you would use 13:52.880 --> 13:58.000 to get a character, there is a check, is allowed console input, and if it's not allowed, it will return 13:58.080 --> 14:09.600 an error, and this way, you can have very future proof access control, because you are disabling 14:09.600 --> 14:15.120 the feature directly where it is, for example, another example is the environment, you don't want 14:15.120 --> 14:22.640 to load a mutable environment, arbitrary mutable environment in your infield case, and instead 14:22.640 --> 14:27.920 of, but you need, but you want to have the environment for the development case, so instead of 14:27.920 --> 14:33.680 trying to disable all ways, you might load the environment, you go directly into the environment code, 14:33.680 --> 14:40.720 and you add an is allowed, that prevents loading the environment, and then you know, for sure, 14:40.720 --> 14:45.920 if there is some new way to load the environment added, it will be still covered, because you 14:45.920 --> 14:51.360 are directly at the privileged operation where you do this check, I have some slides, 14:52.320 --> 14:57.840 how this security policies look like, so these are key config files, in the end, but they are not 14:57.840 --> 15:03.280 used for compiler, but for runtime decisions, if you do security old config, you are asked 15:04.160 --> 15:09.120 interactically, if you do security manual config, you've got a manual config, and there it asks 15:09.120 --> 15:17.440 your question, should console input be opened, should share script be executed, should fast put 15:17.520 --> 15:22.880 your m commands, be supported, and so on, and you can have multiple of these security policies, 15:22.880 --> 15:28.240 so you can have one for lockdown, one for development, one for factory, one for field return, 15:28.240 --> 15:33.520 as you want, you just define these are the security policies I have, you call these function, 15:33.520 --> 15:40.000 and it will ask you one for by one, this security relevant options, and it's only the security 15:40.000 --> 15:45.840 relevant ones, so it's not like K config, where you must really have the insight into the bootloader 15:45.840 --> 15:50.880 to decide, okay, is something I want to enable disabled, so if you read for example fast boot, 15:50.880 --> 15:55.520 we m commands, you might not know that this allows you to run arbitrarily commands, 15:55.520 --> 16:02.240 so this is usually something you don't want, but in this security config view, it only asks you 16:02.240 --> 16:09.760 actually actionable questions, then in the end you get a number of K config style files, 16:09.760 --> 16:16.400 with this S config for security config in front, and these are normalized by K config, 16:17.600 --> 16:26.480 and these are all compiled into the bootloader, and then you can have in the your bit time K config, 16:26.480 --> 16:31.440 you can set a default policy, for example lockdown, so the device as soon as it starts, it will be 16:31.440 --> 16:38.480 in the lockdown policy, which is what will be active, and then board code can decide to move 16:38.480 --> 16:44.560 into a different state, depending on a fuse, for example, yeah, here it can choose an active 16:44.560 --> 16:49.840 policy, and then the bootloader can do stuff with that, and the nice thing is you can have this 16:49.840 --> 16:56.640 clean separation, so you have the policy sides that you are defining on a per board basis, 16:56.640 --> 17:03.520 with this K config, like mechanism, and then you have the mechanism side, which actually applies 17:03.520 --> 17:10.320 the security policy, and that's in common code that different projects can collaborate on that, 17:10.320 --> 17:15.200 and not everyone needs to figure out how do I reliably disable the environment, or how do I 17:15.200 --> 17:21.600 reliably ensure that only white listed variables are passed through, for example, and yeah, 17:21.600 --> 17:31.920 then you can, yeah, and these decisions are enforced, so here is an example for this policy selection, 17:31.920 --> 17:41.200 so chooses the NVM API to read fuse, this factory NVM cell, and if it fails to read that fuse, 17:41.200 --> 17:48.080 it does security policy select lockdown, I only added this for, yeah, for descriptive purposes, 17:48.080 --> 17:53.680 it should be already in lockdown mode, and if for example, a factory done fuse is not burnt, 17:53.680 --> 17:58.480 it would select the devil mode, and then in the devil mode, you could say I have console input 17:58.480 --> 18:06.240 enabled, I have USB, I have fast-boot, I have enabled, and so on, and in the factory you would 18:06.240 --> 18:12.320 always burn this factory done fuse at the end, and then developers would get the device without 18:12.320 --> 18:20.720 that factory done fuse burnt, yeah, last thing I wanted to talk about is runtime unlocking, 18:22.240 --> 18:27.040 so going back to what I said at first, you want to give developers an easy escape hatch, 18:27.120 --> 18:31.440 but you don't want to make it too easy, otherwise they do not test normal boot flow, 18:32.320 --> 18:37.680 and this is something we had used for in a few projects now, and I like it pretty much, 18:37.680 --> 18:48.320 which is we have two fuses, one fuse is the factory done fuse, and one is okay, we haven't decided 18:48.320 --> 18:56.080 on a good name yet, one is partially done, one is very very done, and you would burn both fuses 18:56.160 --> 19:01.120 for all devices that go into the field, but for developers you would only burn one fuses, 19:01.120 --> 19:07.520 one fuse of them, and when you have only this one fuse burnt, it would say factory fuse intact, 19:07.520 --> 19:13.040 and then it will just pull for five seconds, that you press the key D, it will tell you, 19:13.040 --> 19:18.640 press D to enter devil mode, and then when you press D, it will enter devil mode, and then you have 19:18.640 --> 19:23.920 a bootloader shell, and the testing system can interact with the bootloader, and do stuff, 19:24.400 --> 19:30.080 and if you don't press it, it will just continue a normal secure boot with no console, for example, 19:30.080 --> 19:34.960 or only read only console, and it will only check EMMC, it will not allow not work boot, 19:34.960 --> 19:41.840 and so on and so on, and the nice thing is about that is if you just let the device start up, 19:41.840 --> 19:47.920 the default behavior is that it will start up like it doesn't feel just with any layer of five seconds, 19:48.480 --> 19:54.400 instead of having devices that are permanently open, and permanently locked, and not testing 19:54.400 --> 20:01.040 the permanently locked state as often. Yeah, for unlocking, that's for development device, 20:01.040 --> 20:07.760 if you have production device that are fully, fully fused, you can have also unlock tokens, 20:07.760 --> 20:13.600 so I have seen this implemented in board calls, in your boot and in verbox before, 20:13.600 --> 20:20.320 but there is no generic way to do it. For the box a few years ago, I added JSON work token support, 20:20.320 --> 20:27.360 you can pass JSON in the bootloader now, but it's a verified first, and then it's passed, 20:28.240 --> 20:34.560 and the total possible was RSA signatures, my colleague Jonas will, in an hour or so, 20:34.560 --> 20:39.200 talk about the TLV format, which is another way to store the tokens also on the device, 20:39.200 --> 20:46.400 and ECDSA signatures are also now supported, and an important point about this unlock tokens 20:46.400 --> 20:52.000 is that they must be bounded to a device. In verbox there is now an API for that, that gives you a 20:52.000 --> 20:57.120 unique ID, that's implemented for multiple socks, and this is very important because you don't want 20:57.120 --> 21:03.120 an unlock token leaking or reproduced to unlock other devices. So the way it works is you have 21:03.120 --> 21:09.840 a public key, for example, you see there is a public key, in the bootloader, statically compiled in, 21:09.840 --> 21:16.480 and then it's used to verify the token, and the token has a claim that says, I am only valid on 21:16.480 --> 21:21.920 this one device, and if it's not then it's not unlocked, and this is another way that you can 21:21.920 --> 21:29.280 allow developers to unlock hardware, why the system is computer computing, but once they remove 21:29.360 --> 21:35.760 a USB stick or once they wipes the data, it's revert to the original state. The same data 21:35.760 --> 21:42.800 can also be in an Android verified boot tier, for example. Yeah, and that brings me to my last 21:42.800 --> 21:51.200 slides, so for the future, there is work on generic system data TA, so if you don't have a full 21:51.280 --> 21:56.960 blow in TPM, but you have opti, there are still some things that would be really nice to have, 21:56.960 --> 22:03.840 just with an opti TA for exactly this purpose, which is having a key value store and having 22:03.840 --> 22:11.040 world-back protection and what right one is variables, and you could store signed blocks here, 22:11.040 --> 22:16.880 and then you can verify, for example, that this device is allowed to be in the developer mode, 22:16.960 --> 22:24.480 and then you can send, again, it should be in a normal, infield mode, and because it starts in 22:24.480 --> 22:31.120 the replay protected memory area, you can revert to the whole state. So this work is underway for that, 22:31.120 --> 22:40.160 and yeah, we are looking forward to publish this at Pingotronics. I'm not sure if we will try 22:40.160 --> 22:48.080 to get this into opti upstream, but yeah, it's, we'll publish that and provide user space tools, 22:48.080 --> 22:53.120 and also bootloader integration, and I hope it would be a useful building blocks for this kind of 22:53.120 --> 22:59.280 things. Yeah, I had a talk in August, which went more into detail about 22:59.280 --> 23:05.280 barbox for secure booting system. We have fixed a number of memory leaks now, especially the 23:05.280 --> 23:12.000 hash shell was very difficult not to crack, but it doesn't leak anymore, so I hopefully we can 23:12.000 --> 23:16.800 actually run the fast test in CI with OS, as fast in the future. I'm looking forward to that, 23:17.520 --> 23:22.560 and the big problems that we have in the computer tackle that is, we want to pass along the 23:22.560 --> 23:29.280 security policy we have to Linux, for example, in the kernel command line. So if you select the 23:29.280 --> 23:34.960 devil or the lockdown security policy in the bootloader, that should also affect the way you 23:34.960 --> 23:41.760 start, for example, an SSH team in the user space, and we would need some way to communicate 23:41.760 --> 23:46.560 this information. In a secure manner, for example, the kernel command line, we are not sure yet 23:46.560 --> 23:53.040 about how to do that, but set on the agenda. Yeah, and that's it. So it's a call for the 23:53.040 --> 23:57.760 bubble of security documentation, if you want to read more, this is a few links, and yeah, I'm 23:57.760 --> 24:04.560 ready for questions. Thank you. 24:07.840 --> 24:19.840 We have done for one question. Hi, thanks for the talk. I just want one question. The thing is, 24:19.920 --> 24:25.360 you seem to look really completely the device, once it's in production. The problem is, most 24:25.920 --> 24:33.360 really corner cases will happen at customer, and you will have to probably debug that. In this 24:33.360 --> 24:38.640 case, is there a way, did you find a way to address this issue, to be able to take a device that's 24:39.040 --> 24:44.800 in production, and you need to somehow find a way to authenticate with the device, to be able to 24:44.880 --> 24:51.520 to debug it. Yeah, so that's what I meant here with runtime unlock, it's this one, but this one, 24:51.520 --> 24:57.520 you can have signed tokens per device, and yeah, you would keep the private key somewhere safe, 24:57.520 --> 25:03.440 and when you have a field return, you would get it out, sign a token with it, and then you can 25:03.440 --> 25:09.760 use it to unlock the device, but you need to have beforehand included the key to do it for doing that. 25:09.760 --> 25:15.040 Because I remember you said that you would use two bits to be able to say, now it's in production, 25:15.040 --> 25:19.360 but it would be worth to have a bit that says, now this device was in production, 25:19.360 --> 25:25.360 now we put it back in testing, so we lock some pretty cool stuff. Yeah, yeah, yeah. So the 25:25.360 --> 25:30.240 thing is, what code has complete control about, about when to select the different policies, 25:30.240 --> 25:35.600 that just a function call away, so you can check a fuse, but you can also check a token, 25:35.680 --> 25:41.360 so you can mix both, and that's what you would do. Some processors also have built in field 25:41.360 --> 25:47.440 return capability, like I'm X processors, so you can generate a special case, field return 25:47.440 --> 25:52.800 bookloader, only valid for a single talk, use that to unlock the system, it will wipe 25:52.800 --> 25:56.960 the hardware unique here or make it inaccessible, so it wipes all data that's the right 25:56.960 --> 26:02.000 all data that's encrypted with it, and then you can do that debugging. All right, so if you have 26:02.000 --> 26:06.160 hardware specific measures, you said, if you don't, you can re-implement it with Jason 26:06.160 --> 26:11.760 WebTalk, and for example, in their box. All right, thank you. Thank you. Thank you really much.