 So, my name is Marcin Biz and you can call me Martin and I would like to tell you about a secured embedded product I did for one of my customers. It actually works, it's a story. Okay, I'm... I wrote a book about Linux, it's quite popular in Poland. I'm also related in some... doing some engineering and also some business related tasks with embedded Linux, real-time Linux, and I'm especially interested in industrial and home automation control devices. So as soon as I did working real-time prototype for my customer, they asked me, okay, now let's make it secure. So it will be about that. Okay, so there will be some trivial things. We'll get through this very quickly and what I would like to show you today is a practical example of a device secured. So no abuse user or anything else can steal or see the added value of the product. Of course, it's built on Linux, on open source, on some popular microprocessors, SOCs. Okay, I will not be talking about Android, web applications and so on. It will be somewhat about infrastructure. Okay, so first trivial thing. There's something like attack of the surface of attack. Here's the sum of the inputs that user or abuser can use to attack the system to get access to the system or just to influence the normal standard user to do something bad. So in case of embedded devices, we have some of the attack surfaces, which are different than the ones in the standard systems. The typical example, this is the quite old iConnect, the remote storage, it's got a USB, it's got flash device serial, network, actually wireless and also internet. Some of them are like normal things we can think about when trying to attack a device, like just try to see what's on the network, just try to look what's in the USB. Some things are not so straightforward, like some things here, probably JTAC or maybe something else. So we have one or more attack vectors on such a device. So the idea is to exploit a surface in an abusive way, the common ones, network, CPIP, Wi-Fi, Ethernet, all levels of the software stack from low-level Ethernet to high-level IPsec and so on. There's an application in the industrial control devices or home automation control devices. There's usually one application that user interacts with. It can be of course the network and the touch screen, but the application is working on the touch screen. So application must be do well. Okay, there are some less obvious, oh, the serial part is also quite obvious, less obvious vectors of attack, USB, it's quite easy to analyze what's going on the USB. You can just have access to system and run some kind of wire shark TCP dump that can just use the USB devices to look at it. iScore C, this is the quite common bus, this device somewhere there has a temperature sensor for iScore C. The idea is that iScore C is usually used for some trusted models, so trusted chips or some external chips or as a inter microcontroller connection device to just send data to some external microcontroller that is, for example, doing the real-time stack. Okay, solid state memory flash here it's QFP, so the pins are easy to connect to and analyze what's on this. Bluetooth, GPS, that's more for phones. Well, the less obvious the attack vector, the more dangerous it is for us. This is the more he takes. Okay, some differences embedded versus standard like server-like or desktop-like devices. Well, some attack vectors are unique. Usually they do not have iScore C on a laptop. The software update is problematic. Okay, we have Yocto, we have Android when the software updates usually work, but on the very, very embedded devices that has to be working in some factory facility and working well for 10 to 15 years. There's usually a root file system by build-root and there's no option to update it. Sometimes it's done, but in a way, so if the not well-behaving version of Apache, for example, Apache was used, it's a quite a problem. It's quite software monoculture. The system is done and nobody will update it. People will usually not treat embedded devices as computers, like we do with our phones. Phone is for calling and for texting and it's got a quite big CPU in it. Some people do not know, see this. Okay, on the other hand, we have the same problems, the same programs, the same software demons services as on the server, like Apache, OpenSSH, Perl, Awahi, DNS, OpenSSL, etc. Maybe not in the factory floor, but for example in home automation, automatic configuration, automatic network discovery, it's a quite nice thing to have, to have your iPhone detect your device in it. Okay, there are some infamous examples of misuse of security in embedded devices. Stuxnet, it's not actually a Linux related. Idea was to it was a virus running on some Windows software that was updating the unsecured logic controllers, spoiling the devices. In my work, I usually see some devices that are just have downloadables, locks, your FTP, and usually that's poorly secured. Admin default, it's actually my neighbor's network and it's router. There are more examples, quite old on this ELC page, and this is from yesterday actually. It's hot update. It's iZone, the camera you get in App Store, and it has the hard-coded root password. So this is a root password. I didn't show this. So it's a huge problem. They sell a few million of the devices. You put it in your home and you get to get a string from it. So this is a hot story. Misuse of credentials. Okay, so common methods are easy to fight with. Just use the strong passwords. Restrict the shell access. The idea with this iZone camera was that it was having a web page on which you get the access to the actual camera stream without any credentials, just security by obscurity too. So avoid other methods to access system shell. Web shells, SSH, Talonet, don't use it or use it with secure passwords. So strong passwords once again. In build-routed environment, I used to usually run everything from a root account. It was easy to develop. It was easy to run, easy to debug. But on the production side, it's nice to have separated credentials. Even standard Unix credentials. Might be SL Linux and so on, but it takes time to implement it. So we need to use bug-fixed component. This is usually not a problem at beginning of development where we have the quite nice version, but then there's a quality assurance, the test and so on, and there's no possibility to update it. Even if it's bug fixes. So this is a problem. Components should be up-to-date. And there's an ultimate question. Do it yourself or use the open source software. We can quite easily write a web server for web services in Python, in Java and other scripting languages or use Apache. So if you are using something, writing something in home is a defensive programming. It's like it's a nice buzzword, but the idea is to think about the other parts of the systems as are possibly already failed. So if I'm writing a program that is connecting the socket, I cannot assume the socket is okay. It's working. I assume it doesn't. If I get the temperature from temperature sensor, I do not assume that the temperature sensor is working. It's giving me the right temperature. It's a bit of paranoia. It will be well developing programming. Okay, so this was a trivial part and what I actually want to do today is to tell about passive security. This is all active security, like fighting the abusive users. And in passive security, we are defending our software and hardware from being still being analyzed by a maybe competition. So how the customer, how my customers actually see what I'm doing is the product. I'm doing all this part. The free software, the Linux, BSP, SDKs and so on, all this that support the foundation of the development. And what the customer really wants to sell is the added value. It's his fancy algorithm of doing some component extraction for some biochemistry process, for synthesizing the DNA, for example. This is the added value for the system. So the next thing is that hardware becomes cheaper and cheaper. I mean hardware that is capable of running Linux. You can have quite nice, but quite old, SOC for one and a half dollar in a bunch, for example. Just add a DRAM, just add a non-storage and you have a quite nice system on chip, a system on board. So expectations increased. Like let's put a 10 inches display for our device, because our customer will buy by seeing the device and the competition have a 7 inch display. So it's not possible to do in microcontroller in a nice way. So Linux and Open Source is a default system for Embedded. It's going to be, or it actually is, so people are trying to build the software products on the Embedded Linux basis. So just add value. Okay, Open Source gives us freedom so everybody can do it. It's like a company that are free engineers working on a product can have the same starting point. As a huge mega-corp. That's starting with the same basis, which is what Open Source and Free Software gives us. Okay, so customer will want to make money on update value. We have to integrate the added value to the system and secure it. Of course, we have to do it according to licenses. GPL or GPLBSD, you know the differences. So how to do it? It's just an idea. There are many ways to do it. Actually, you can just run a program application that is proprietary on the base of Open Source system. Other things like executing GPL applications or doing the kernel models are more or less fragile. You have to have a low advice on this account. Or just do an Open Source GPL code. So how to secure out that value? If you go too much to too far, we'll do something like Tivo. Tivoization was a quite nice set-up box in the US. It's running Linux and of course you get the source code, but there's no possibility to run the compiled source codes on the device. It's sealed. So actually we can do Tivoization right now with Linux and this presentation will do it. But there's a slight moral question about how to do it and how to do it. So it's right to the acceptable for the customer and for the community. Actually, only GPL version 3 license denies the Tivoization. You can do it in Linux and other parts. Linux kernel is GPL version 2 right now. Okay, so let's see how to do it. At first nothing will stop user. Abuser for analyzing the product. You can buy a product. If it's a mass product, it's easier. If it is small volume like very specialized industrial automation, it's harder. So you can just desolder the CPU and analyze the logic states, in theory of course, because the paths should have a proper capacity. If the sock is running on one gigahertz, it's harder and so on. So it only depends how determined abuser is and how determined we are for secure device. So the main idea is that security is not a product, actually. It's a process. You are just chasing or you are running away from abusers who are chasing us. So we can use different security methods in devices that we produce in 1000 pieces a year and quite different should be used in the devices that are produced in 10 millions per year, for example. Okay, so there are hardware methods. I don't do hardware usually. I just write a specification to outsource it, but there are some tricks that the company that is doing hardware can do. First of all, example is BGP. Both are on the bottom of the CPU and other components. It's harder to analyze the actually tracks and signals for it. Next thing is the multi-layer PCB. Eight layers are quite common. Four layers are quite cheap. So usually the signal paths are in the inner layers of PCB. It's harder to analyze the logic states and it gives us the better emission of the electronic noise to the air if there are huge surfaces on the external parts of the PCB. So if using the multi-CPU design it's quite common in some industrial automation devices to do user application CPU to display the state of process on like 10-inch LCD and then use the small microcontroller to do the hard drill time path. So if there are two chips they can check each other. It's like watchdog. Microcontroller sends signals, timed signals to application CPU and vice versa and if there's no response everything shuts down or resets. So it's avoiding connecting a JTAG and just stopping the CPU. It stopped, it will get down. Okay, there are some nice TPM chips. You can easily find some presentations about adding TPM chips to your design in LC even. Just quick examples. This is a BGA CPU. As you can see the balls are on the bottom. It's very hard to analyze what's here, what's the voltage on this. This is a multi-layer PCB. So you can see so we can use something like hidden vias between the layers. Images are quite simple from Wikipedia. As you can see this is also quite nice thing to have. It's called a sandwich. It's Texas Instruments CPU, the DM, on top of which there is a chip with RAM and NAND memory. So it's here. There's no problem just for paths on PCB. All is done in CPU. Quite nice. Hard to analyze. This was the IG board actually. The problem with securing or obscuring the hardware is that the hardware actually is quite hard to debug if something goes wrong. We spent about a month debugging this and it appears the solution was quite easy. They misaligned the D plus and D minus on USB port. Well, it hurts. Okay, let's secure data actually. I'm a software guy. I'm not doing the hardware. Okay, the first idea is to sign it. Use TPM chip to provide a secure way of storing the keys or high assurance butte. It's vendor specific for free scale. The idea is that software is signed. User cannot change the software abusing the usage of the device but still can analyze our algorithm. It's not a way I want it to go. My idea is to encrypt everything. Well, the encryption should be fast because it's a real-time industrial control device. So performance penalty must be very, very low. Especially real-time and deterministic performance shouldn't be touched. Okay, well, the algorithms are there. The tools are there. The main problem is where to store the key. So we can have the root file system encrypted, Linux root file system, the busybox plus application gives us 4 to 8 megs, depending on how much resources the application have. Of course, application is then decrypted and copied to RAM. But RAM is BGP. So it's hard to analyze. Okay, I don't know. Probably there are some encrypted RAM chips right now. So the idea is to boot a kernel with device strip, probably, new kernel. Maybe RAM disk, maybe not, we'll see. And then have a script in RAM disk that will decrypt the root file system. And the problem is where to store the key for this. Okay, so let's see what's what the possibilities are. If you are using the block device, SD card is actually not a good idea because SD card has a this mechanic part so so it can loosen it can if there are some tremors in especially in factory. So EMMC is the solution used in phones and and other wearable devices right now. And EMMC is just a block device. So we can easily use DM crypt on it. No problem. One crypt setup has a tutorial and so on. There's a Linux Unify key setup standard of writing the data so it can be easily discovered by crypt setup and other tools. So if you try to connect this to the PC it will show that it's a Linux partition and try to decrypt it. Okay, but this works for block file system. Another solution which is which work on top of the standard Linux file system is a crypt fs. Just mount a crypt fs one directory to the second directory. It is working on top of file system. So in one directory we have encrypted files and another shows us the the real files. There's a problem using a crypt fs as a root file system. So there's a problem if initram disk starts and then tries to switch root or pivot root to the the crypt root file system. It doesn't work. Still it can be used for encrypting a part of file system just. Okay, but in my case in industrial automation customer wants to use NAND the RoNAND device to have a wear leveling to have a bad block control because it's producing a device that will be standing here for 10 to 15 years and must work or must signal us if it's going to fail. So no use of black box like AMMC. NAND is nice here. Okay, how does it how does a NAND work? If somebody do not know yet. NAND has a IO blocks which you can just read or write but the only possible right operation is switching 1 to 0. So to switch 0 to 1 state you have to erase the block and you are doing it on the erase blocks which are quite quite big like 2 kilobytes IO block 128 kilobytes erase block. Well, next thing is that you can have bad blocks on the NAND. It's normal and the bad blocks appears as the erasing is done. It's like the modern NAND chip will fail about 10,000 erases. Some of the blocks will fail. So EMMC is just throwing a flash transaction layer that is doing a block device. Standard block device you can do input output. So just read the block write a block flash transaction layer will do the the rest of thing. So that's the main problem. We do not know how the flash transaction layer on EMMC work. We do not know how it is tuned how it is optimized. So it will be a problem. The solution is to use some kind of flash aware NAND aware file systems. JFFS2 was a standard. It's still used for quite small NAND chips. So it is doing the log based storage with ware leveling. It is aware of bad blocks and it will just store the data in a nice way. Okay and next standard for doing it for a big NAND devices is UBI. UBI is more complicated. It's actually the idea was not to do everything in one driver in flash file system but to just cut it in half. This is only doing the file system and this is doing the ware leveling and bad blocks handling. So UBI is nice for big NANDs. Actually benchmarks are quite for 2.3.2 kernel are here. But there is a problem how to add encryption to UBI FS. So it can emulate a block device. It will look like just upping another layer on top of this schematics. I don't like it. Use encrypted FS. There is a problem with switching root file system to a encrypted FS. A encrypted FS tools are quite big too. So it's a problem. Or to use the source code. So let's look at the source code, what's possible. The nice thing about flash file system is that UBI FS and JFFS2 also compresses data while writing it and decompresses it while reading. So you can actually store more data on flash device than you have. Quite easy algorithm like LZO or GZ. So maybe in this function that do the compression it can be also be encrypted. So just search. There's a crypto API in Linux that can do encryption of course. And patches are already there. They are floating somewhere. It's from 2012 actually. Joel updates some functions for UBI FS to make the encryption next to compression. And the other tricky thing was that UBI FS not always compresses data. If it compresses a block and sees that the compressed block is actually bigger than uncompressed it will store uncompressed block. But encryption should be mandatory. So the encryption is done. The patches are not in the mainline. Probably won't be. They look like abandoned. So the idea is to just grab it and apply it. It doesn't yet do the encryption. You have to provide a key. There is something like I don't want to go through the code. But there's a variable. A variable is set. It will be used as a key. If not, just pass. It will work as normal. So the code actually works. Okay. On the other side of the crypto API we have encryption is using crypto API. You can read here. This is counter mode. The other side of the crypto API is that the crypto API can use some actually hardware to speed up the encryption. So this is for DCP which is found on free scale. Sorry, it's not a free scale advertising. I'm just using chips in some of the designs. So it's forward ported from the vendor tree. It's not in the mainline. I put it in stagging. So it is. It just integrates with crypto API and then IPsec uses it just like that. And also we will be using it if it provides, of course, the proper eyes. Okay. Watch out. You have to use the proper block cipher to encrypt your data. This is important. Well, the first two images can be found on Wikipedia, I think. But the idea is to get the PPM image, which is just a text data, and then just encrypt it. Open SSL can do it. So let's use the ECB. This is the first. This is a block cipher. The data is cut into the blocks. Block is 128 bytes. And then each block is encrypted separately. So actually, you can see encrypted data here and how they look. Well, if you are storing some tables of data, like in an injection engine, for example, there are huge tables of parameters, this can be easily worked out how it works. So we have to use some mixing in block cipher. There's a CBC. Each block is just sort with the previous block. And the idea of the patch is to use the counter mode. Counter mode is nice for encrypting stream of data as used in IPsec. DCP accelerates this. And in counter mode, the result looks better. The last one is counter mode. Just CTR here, I think, to do it. Okay. So we can actually produce a secure device based on the FreeScape chip, for example, IMX28. Well, the key is stored somewhere there, still. In its RAM disk, it's not needed here because UBIFS can be compiled in. The key can be stored as a variable, for example, put in device tree as a parameter. Then you can encrypt the root file system and just mount it. One notice here, in case of a cryptFS and dmCrypt for block devices, all data are encrypted, like the file names and the headers of the file system, too, because it's on the block layer. And then we are doing encryption of the file data. So only the file content is encrypted. So file names are still there. If you will be able to connect to this flash device and just get the data from it, you can see the UBIFS structures. Okay, you can see that there are files. Just name the application up one and data one, data two, data three, security by obscurity, in some way. Okay. But the problem of storing key still exists here. So how to do it? We have to use, unfortunately, some vendor-specific stuff here. So I put a key in the device tree attribute just to have the same kernel for all the devices, and the DTB is the one thing that changes. For all root file system I built, I have the same kernel, because DTB is the part that changes. It can be easily put somewhere in the attribute. The driver can use it. It's got just the functions to call the device tree and get the attribute and use data. There's it. It's like 128 bytes for ASK. Then encrypt kernel plus any tram disk plus DTB using the chip-specific features. So for this device, actually, I have to switch to reference manual, and I can see it has the, sorry, the data processor here, and as for boot modes, okay, the previous chapter, it's got the disk configuration, the assurance boot, and secure boot also somewhere. Okay, encrypted boot feature. It's here, like secure boot. So it's from a vendor. So idea is to store a secret key in some registers of the chip, then to blow some fuse, one-time programmable fuses, to make the key storage sealed. Then the key is copied to the DCP engine, and then the DCP engine unencrypts something called BootStream. This is a bootloader image for the CPU. The idea is you cannot read the secure key from CPU. You cannot change it. You cannot turn the encryption off. Well, it's a vendor promise. Well, so, yes, I don't know if I will use it for iPhone, for example. Okay, it works. Well, another, the last words, oops, sorry, mistranslated, written in Polish. Okay, security is not a product, it's a process. So, you know, this is secured, but it's not really a product. It's just a process to running away from abusers. For example, I do not know if, in a 10 years lifespan, the IS will be, the AS algorithm will be still secured, like the RC4 used to be, right, 10 years ago secured. So it's a process. It's just abding another IS. Okay, don't use security by obscurity. It do not work, the camera example, use the proper algorithm. We have to, you know, depend on something. So in this design, I'm depending on the vendor promise. I think it should work for now. Okay, and the next problem, less from engineering part of the problem, but more business part of the problem is the source of the attack. The many attacks for the software are from inside. There's a WikiLeaks and so on. So people working in the company can just publish the code. So this is the huge problem for business. So in case of security, I even do not trust myself in this topics. The idea is that this process, which works for booting the secured product, and the product is secure, is to be put in some kind of, you know, build infrastructure and business infrastructure to decide who has the access to the keys, who will program the CPUs with the internal keys, and how the keys are stored, how the keys are used in a build system, and some trivial questions. How do we just build a root file system for every device, or just use the same root file system for quite a few bunch of devices, if we have produced million devices, for example. Okay, so the next problem is to just make it built in a secure way. Probably the build root installation with all the scripts done from beginning to end is not quite a good idea here. Okay, so it's not a product, it's a process, and beware of internal attacks. Don't even trust yourselves and encrypt your devices, for example. Okay, that's all. Thank you. Any questions? So, I don't see the mic. I can just repeat the question. So the idea is, is it possible to remove that? Going back to what you're saying about your root of trust, yes. And necessarily, you know, today, that being whatever the vendor offers for the hardware that you're using, and taking the approach of encrypting the image, the kernel image that you're loading in, I mean, great stuff. How does, you know, what effect does that then have on our ability to do a remote update of the system in the field? You can still do the remote update. You have to just think about the secure channel of putting update, via some network. The idea is that if you are building an image for update, you have to encrypt it with the key for a single processor. So every device is encrypted with different keys. So you cannot just do the mass update. Specifically with FreeScale. Yes. A signed kernel for the particular device with its particular key. And I did a partial update and that failed. Have I got an ability to fall back to the previous signed image? You do not have. Yes. You have to think about some, maybe, I was thinking about it like that. I can have an image that is encrypted with multiple keys. It's for FreeScale specific if you are down. So I just create an image that will run on 100 CPUs, and this image will do all the checks, the defensive programming. If all the checks are okay, it will update. And the quality assurance assures me that it will work. Of course, there is a problem that if update fails, the device is bricked. So the CPU still have some recovery possibility. Like for a FreeScale specific, you can just turn the boot, you can just change the resistance, press a button for a device and it will boot in the recovery mode, waiting for a USB for data download. So it's probably not, user cannot do it probably on site, but the technician could. Yes. You can always use a dual-boots kind of concept. There usually is a first-stage boot that takes over the chain of trust that you can keep static in there and then you would be able to switch between two kernels and router faces that would always allow you a fallback if the firmware update is encrypted. Yes, that's a good idea. You can use a secondary image or bootloader or even kernel that will be the fallback image. Some CPUs have the ability to just try to boot something. If it fails, go to another image or another offset in NAND. It can be isometric and then there's some logic in it. Store the isometric key and then store the symmetric key somewhere in the script, which is just encrypted by the private key of the symmetric one, but the idea was to boot it quite fast. So storing the symmetric key and using this key in DCP accelerator was the fastest way. You can always add some other features of the chip. This chip has the high assurance boot that the whole image can be sign additional to be encrypted, but it's not giving us anything new in this case. Chris Peele has support for this hardware acceleration of the encryption, the DCP. What about the microcontrollers or chipsets which doesn't have the acceleration and we would like to have them in software. Do you know any benchmarks which show how long does it take? No, I do not know any benchmarks I do. I did myself on the DCP versus software and DCP was faster. How much does it take? Do you see any difference between unencrypted and encrypted? Yes, I can see about 10 to 20 percent slower read access for an ant. It's just a figure. I do not have a test here. The idea is that the application is built to be a real-time process running on the preemptor t-cernel. So all of the application data or resources are preloaded to random access memory before going into the real-time state. So it doesn't affect the working performance, it affects only a boot time and start time of the application. You mean taking it from the flash to RAM? Yes, if it has to be the real-time application, it has to put all the data in RAM, do the memory locking, set a scheduler priority and then it can go into look for example to do some real-time stuff. If it would read the data during the real-time, the reading is not real-time, not deterministic in Linux. Yes, it's the feature of the CPU that it's very easy to encrypt everything, the whole boot stream. Yes, it's not trying to obscure. The idea is this is actually a devolization case. The user cannot change a kernel here, it's a problem, will be a problem at some point. The idea is that the same thing can be used just to encrypt a part of the file system, user application data. But at first stage we do everything, encrypt everything to show it. The idea is to encrypt only the parts that are needed, the encryption. The first idea is to just put the variable equals key in the kernel code. Just a quick hug. Just to show the customer. The device tree was the nice solution. It's just developed later on. Yes, for reading data from NAND, hardware encryption. I do not have it here, I can show you. Yes, I do not check the software encryption actually doing reads. I just run a row benchmark on the crypto API, which was faster, and the faster was DCP, so I then use... Yes, of course. So I used DCP and it's like 10 to 20% dependent application actually. It's not a setup. Yes, using hardware acceleration. Yes, it could be. So the idea is that if you know this and know this and encrypt the data and encrypt the data, you can work out what the key was here and it's not possible with AS currently. Probably would be in 10 years. So that's a good point. So just encrypt the unknown parts. So if you are encrypting everything, the kernel and the known data, you are giving the attacker a standard kernel that can build itself and the encrypted version of it. Yes. Awesome. And also the tricks that you can do with the linker to adding noise into your kernel, it slightly increases your kernel image, but it has a lot of random data to each of the releases. It might be really difficult for somebody to figure out what the... Yes, that's security by obscurity. It's difficult, so it will cost another 100 dollars to work out for an attacker, right? $100,000. It's not really a security, but it just means that the node is no longer in nodes. It makes it a lot less difficult to crack the keys. Yes. How did you manage that? Is it allowing again security? I mean the overhead of having everything encrypted, you will do the break, you will be back. Yes. So there is an overhead in development. You do not trust the developers in the first place, so developers do not like it. Well, the idea is to just develop the Linux application that is running on a known basis. So to the point, the application can be developed on the standard desktop systems, secured with some hard drive encryption, and then put to the real device, which is the main difficulty. The multi-thread application, the multi-thread debugging is quite the same on the PC and on the ARM. Talking to hardware is a bit different, because of specific interfaces. So I don't know. I'm not an application developer, but they are not quitting. Okay. So in this design, I actually have two keys. One key is for, next slide, one key is for to the CPU. No. This key is the different key for each single device. Yes. I have to store it on my own in some secure way. Yes. I have to get a key. Yes. Yes. That's true. The idea is that you can just write scripts on everything and put it on the server and store it in the secure place. And the idea is to have one or a few just management stuff who can just press the button to encrypt it. Yes. I've got to... Yes. Yes. That's true. It's like the devices are produced in a bunch. Like I've got a bunch of 100 devices and I've got a labeling process that gives me the labeled CPUs. Each CPU has a unique serial number and then I've got the data, the serial number encrypted key. This data is encrypted using the asymmetry cryptography and then the public key is on the pendrive in the safe place and only management has access to it. It's a case of physical security actually. Correct. Yes. Ten of these machines on the same place you have to give. But it's just but just some part of the application because maybe the added value is just a single program that gives you the specific algorithm and the data of the algorithm. It is... Yes. You have right. It is possible. Yes. It is possible to access this specific free-scale DCP from user space. The idea is that it's got a CPU key copied and then you can just ask encrypted using the key. So you do not get the key from the DCP in this case. But it's not universal. We have to stop. Okay. So thank you very much. We can continue during the break.