 Our next talk is the title, architecture of security devices, security by design. Our speaker will talk about the different steps, technologies and methods that you shall apply and that will help you to build a secure by design device or system. Our next talk is a freelancing software developer with quite a bit of experience in the field of security. Please welcome the eutron of applause. Hello. Okay. Welcome to everybody to the presentation, architecture of secure IoT devices. So I've been introduced already, so I skip this. The intended audience is our current users of Raspberry Pi and who might be interested in or thinking about how could I achieve to get a secure IoT system. So what's necessary to get to the next level? And I've got, I'm sorry to tell you that the first step you've got to do is to, you have got to switch the hardware because the Raspberry Pi will not be sufficient or the right hardware to implement this functionality and this architecture I'm presenting here. So what you need is an NXP, IMX6 or a newer version of the NXP processor family, ARM Cortex A7 and it has usual features. So this board is a bit older, it's 10 or 100 megabits per second, Ethernet, USB 2, serial devices, I2C, CANG, GPIOs and the important fact is secure JTEC, EFUSES and CAN. So these are the aspects that allow us to implement a secure IoT device. We will talk later about what is the secure IoT device, we will have a look at a small example and discuss, so what are our requirements, what are our, what do we want to achieve. We will talk a little bit about the risk and threats, how do we achieve a secure boot on our IMX6, encrypted partitions and additional isolation techniques to separate applications from each other. We will talk about a little bit about organization, so if you are in a company and you start to set up a secure IoT system, first you will start to implement your PKI as a development team and so on and then later you ask yourself, okay, who is responsible now for the PKI infrastructure, so who will manage it, it's not a developer, so it should be IT service in your company and this, so having this thought, there are some organizational aspects we have got to talk about. So we will have a short, very simple example, we will have, our example is a charging station and here, that's the charging station and it's used to charge a car, it can interact with an RFID card and it's connected to the operator, to the data center of the operator, it receives system updates, it sends, it receives control messages, it's sending up data, so the data could be the amount that has been charged by a car and so on, so important for billing, so quite important data. We can split this apart into four stages, the sensor actuators, the internet gateways, oops, internet gateways, we have got HIT, in our case we don't have any HIT and the data center cloud. This one here is our device, which is connected to the car using sensors and so encrypting the data and sending it over to the data center. We also have some technician working on the spot and configuring the system locally, so we need some kind of secure connection to our device. We need a secure system update, transport, let's assume we use HTTPS. We need a remote control connection that could be HTTPS or it could be SSH and we've got a data upload using HTTP but it could be also kind of VPN network. We've got a local database here storing all local data and for visualization and being uploaded to the data center on this side. On the data center side we've got an update service, some facility receiving the data uploads, PQA infrastructure, some kind of DNS. When we analyze the risk now there are some methodologies that should be used and so there is the BSI 100 standard or the ISO 2707000 and so important fact is also they define a process how you analyze certain risks and threats and it's also important so the BSI standard defines the important protection, confidentiality, integrity and availability. So these three aspects will be our targets we want to achieve here. So there is one mantra, so security cannot be introduced in the afterthought. So we have got to think about security from the beginning. We cannot develop a system and attach security later. So we have got, it must be in our system from the first startup. Influences device boot times, file system performance, firmware upgrade processes. So if we go back to our example, so we have got this system update being transferred from our data center or from portal to our device. So here we would need some mutual authentication. So we need a client certificate, we need a server certificate. Talking about remote control, again, so we need a client certificate connecting to the target to the device and we need a server certificate on the device. For data uploads might be VPN so we need, we need, we need a mutual authentication, we need client certificates, server certificates. We have got a database, so database should be encrypted and as you see here so it's full of security and requirements for cryptographic items, credentials, you name it. We will talk about fuse bits also, we will talk about secure boot and code signing and maybe some words about DNSSEC, trust anchor. So having a look at the organization of your company, so you might have, so it's a bit, I did it with another tool so it's not as fine as it looked before I used, copied it. So we have got the development department here, developing or implementing some code and to execute or to realize some kind of secure boot, this code must be signed. So we need some mechanism to sign the code, could be used, could be done within the development center or development team but if we do so the development team is responsible to keep these data secret and it's the most important data of the company. So if this data gets lost anybody could compile code and sign it with those credentials and deploy it on the hardware. So this is the most important aspect of a secure system that these credentials are kept very secret. So we should establish some kind of code signing service within the company, so sending, so authentic, so developers are authenticating against the service, maybe with a username password or maybe with some kind of cryptographic credentials to get access to the code signing service. So we need, we also need credentials, credentials, keys that are stored on the target during production when we commission the device and send it out for delivery. The operation support and incidence response team needs keys to access the devices. So again, so it's all around in your company suddenly the requirement for security security items pop up and you need within your company some kind of understanding and support to get these services delivered by the IT service department. So important steps also to choose the right hardware. So in this case, so I've experienced with this NXP IMX6 ultralight, it's an ARM Cortex, it has 250 megabyte, it's 4 gig flash memory, it has an industrial grade, it's operating a wide range of temperature and so it's offered by the company Caru and this company also offers more performant devices but this device is sufficient for our need. As I said, it has usual features, internet, USB, serial device, can, GPIO and the important aspects are the secure JTEC, eFuse and this can cryptographic accelerator assurance module. So let's have a look how these functionalities work together. We want to establish a secure boot, why? So we want to make sure that nobody else will be able to start code on our device except our code. So to enforce this, we can set or code some fuse bits in our processor, these are called one-time programming, so once they are set, you can't modify them anymore. They are burned into your processor. What is burned into your processor is the hash value of your public key. Of a public key, we will see later how it is used but these hash values are just the trust anchor of your public key and the public key will be used to verify signature attached to your code. This is the signature, this is the boot loader and interesting aspect is the public key is also attached to your code. It will be the whole image will be loaded by the initial boot loader, it will extract the public key, it will hash the public key, it will verify that the hash of the public key matches the hash values burned into the CPU and if this is fine, the public key will be used to decrypt the signature and the decrypted signature will be compared to a newly computed signature of the boot loader image, of boot loader execution code, executable code. So, if public key or signature do not match, the CPU will not start up this code and it will do, so it will just freeze, nothing will happen. So the process to create this signed boot loader is you start with your boot loader, you compute the hash, you take a private key and the private key will sign the hash and the hash and when you ship your software, the signature is attached to the boot loader. So this is how a secure boot or as it's called in this environment, high assurance boot is working. So this is an example how we can make use of this mechanism to establish a chain of trust during the boot phase, so we've got the wrong, secondary or second program loader, there are multiple names for this, and the second program loader is performing exactly the step we analyzed before, we had a look at before. So it's reading, reading the boot image, the boot loader and verifying the signature. If the signature is fine, the boot loader will be started and the boot loader itself now will read the kernel image, it will verify the kernel image, signature of the kernel image and it's using the same mechanism, the CAM mechanism we used before to verify the boot. This step, the keys are locked, so it's not possible to use any other key now. And also, once the kernel has been verified, we can also verify the root file system. The root file system, if you compile it with Yoctur, so it's maybe 10 or 10 megabytes, so minimum size is 10 megabyte. If you use a minimum or a small Debian setup, so you can reach 120 megabyte. But still, so it's a very fast process. One good note here is that Uboot supports some kind of external elements or items. Uboot has something called environment, the environment is stored on the disk as a text file. It can be read, it can be written. So we must make sure that nobody is able to write something into this environment text file. And we make sure by integrating or embedding this environment file into the Uboot image, also the device tree of Linux, so usually it's externally stored on the image. So we want to make sure that nobody is able to modify this device tree. So again, we have got to integrate it into Uboot. The device tree later will be handed over to the kernel. So the kernel will read a verified device tree. Nobody was able to modify. So this way we get a very, we get a trust of chain starting up our system. And nobody will be, as long as nobody gets access to the code signing keys, nobody will be able or anybody will be able to start any code on our device, on our hardware. This is important because the next step, we will have a look at how we establish some kind of encrypted file system on this target. So once we started our system. So we have got to remember the root file system has been signed. So we will not be able or we should never ever modify our root file system because this would modify the hash value of this root file system. So we are not able to store anything in our root file system. We have got to establish some kind of other mechanism to store data that should survive a reboot. But on the other side, some applications expect that they are able to write into the slash ETC directory. So for this case, we established some kind of overlay for our read only file systems. So having these overlays, the applications will be able to store volatile data in the ETC directory. On reboot, those data will be lost. Now we need to establish some kind of encrypted storage or secure storage. We are able to modify and to store certain configuration data into. So here, we use another feature of the IMX6 CPU. It's called the master key, C-A-M master key. So here the kernel itself has an adapter to interact with the C-A-M master key and encryption functionality around this master key. So we are able to encrypt and decrypt a key blob. And the key blob could be a key storage. And this key storage is used by the device mapper demon to initialize the device mapper for an encrypted file system. So as you see, there are two important aspects to establish secure IET system. It's first of all the trust of chain of the boot loader and the encrypted storage and also the overlay file systems. So everything starts with the fuse bits we set in our CPU. These fuse bits are set in very early production process. So when we order some boards at Kauru, these boards are delivered with those fuse bits already set. In fuse bits we also deactivate JTEC, we deactivate other devices, we deactivate booting from external devices. So a lot of fuses has been set in terms of security and also these hashes and fuses to set the hashes. So that means over the complete production cycle we are not able to start any other non-signed boot loaders or kernels. So in every phase we have got to think about providing the right boot loader for this production phase with a correct or with a required functionality in kernel, the required functionality in root FS. So it's not only that we add security before we ship our product, we have got to deal with security issues during the complete production cycle. So from starting from manufacturing the module, assembly, putting together all the parts, attaching the battery, attaching sensors, commission phase, so setting the serial number and then delivering and setting up on the spot and during operations. It's also important to talk about the software updates. So it's not possible to use any functionality like APT, Debian package updates or whatever. So we have got to update our images completely. I talked about the requirement for PKI credentials that will cover the code signing, or the remote control, update services, signing update packages. So for all these features and tasks we need some kind of credentials, PKI credentials. So there are multiple choices you could do to establish a CA or PKI infrastructure in your company. You could use Let's Encrypt for example. But Let's Encrypt does not cover code signing certificates and those code signing is... If you look into the scripts, so those code signing tools, they generate keys. Using OpenSSL but afterwards they are modified and they are bundled together and so they require certain structure. So Let's Encrypt will not cover this functionality. Also Let's Encrypt will not be the right choice if you have got IoT devices located in some kind of home area networks. Let's Encrypt will never issue a certificate to you for a device located in a home area network. Assuming there are some Fritzbox or whatever, some DSL router badly managed. So Let's Encrypt would not be able to verify if this domain belongs to this user. So it's only of limited use Let's Encrypt. So you could use Self-host Encrypt PKI. With a few, OpenSSL is able to generate and to generate certificates, keys and create certificates. So it could be used to realize a complete CA being hosted in your company. So but it requires some kind of understanding what the process is doing, what it's good for and it requires a lot of knowledge most companies might not have internally. So you could use a Self-host PKI being managed by some professional service provider like MS server, a Microsoft server but this is a very costly solution. So in this case every Microsoft server can deal only with a single CA. And so if you need a number of CA's you end up with a lot of Microsoft servers you've got to manage and host. So it's then you've got to deal with online certificate, status, protocol, services and so on. So it's quite complex. So what's interesting is so what I came across recently is some kind of service PKI service offered by Nexus Group. I'm not sure they offered already publicly but this is I think it's a good, it's in between so you outsource the management of the PKI but still you've got full control of your PKI and can do whatever you want and issue certificates forever for any region you want. Talking about PKI service you need OCSP, online certificate status protocol that's used by or will be used by your IoT device to verify if any certificate is still valid or has been revoked. You might have need for certificate verification lists, important and important certificate enrollment protocol. So there is EST enrollment protocol and there is a modification of this EST based on constrained application protocols and a more ancient simple certificate enrollment protocol formerly known as Cisco enrollment protocol. So beside all these PKI services we've got also to talk about the update service. I think that's one of the most important services on our device. So whenever we want to change anything we might want to update the system and update or changing the code is always a risk that attacker might interfere. So we've got the update service and we've got to move or ship our update package to our target. So what I see sometimes is that people are doing it the wrong way. So they create some kind of tar fire containing the images containing some kind of signature and then they start to untar this package and afterwards they verify the signature. So that's the wrong way. You should first steps always if you receive any data verify the signature of this data. Otherwise if you start to untar this package it might be a tar or sip bomb or whatever so it might be a denial of service attack to kick your system out. So first step always dealing with update packages is verify the signature. Once you received an update package you want to replace an existing system with new images and going back a few slides I was talking about confidentiality, integrity and availability. So we must make sure that any kind of update mechanism even if it fails or if someone pulls a plug or if it's the update process interrupted it should never be any system or the system should not be pricked. It should always be possible a fail safe mode possible so the system will realize that the active image is not working and should fall back and should fall back to the recovery system or the previous image that ran before properly. So I had a look at U-Boat and I think even with so I didn't so I analyzed it a little bit and I think it would be possible even with U-Boat to create such mechanism. So I know it works with Grubb but Grubb is not in our focus right now so but I think it would be possible to implement U-Boat to configure U-Boat away that we've got some kind of fail safe boot process. Of course you see here a variable active so active is the zero system shall be the active one. Of course this would be necessary to sign this data as well. So we would juggle with kind of scripting in U-Boat and those scripts being signed itself and just replacing one script by another script. So maybe if you've got experience with those scripting you can tell me later if it's working as I think but so additional features. So I've got to speed up now. You should remove any interpreter from your device. There's no batch, no Python, no JS. So focus onto a single D-Bus or single IPC mechanism. Think about isolating access to GPIOs or other hardware devices. Define what is the well, what is the allowed message flow between devices? Who's allowed to write files? Who's allowed to read files? So the simple tasks. Do we need firewall? Do we need isolation, sandboxing of the baseband for the cell phone? USB 3 nowadays is using DMA. So USB 2 in the past did not use direct memory access. So USB 3 is using direct memory access. Once you attach a USB 3 device it might happen that it directly transfers data from one physical region to another region reading your data. Firewise the same problem. So anything with DMA is evil. So avoid any device using DMA underneath. So there are multiple mechanisms. You could partition or isolate your systems. You could use the UNIX groups. You could use some C groups as a Linux established name spaces. You could use a kernel virtual machine, Docker virtual box. You could use a trust zone feature called OPTI or L4 micro kernel. So usually UNIX groups, so this is a UNIX system. So we'll skip this. The next step would be using C groups name spaces. So a good way to establish or manage C groups is using system D on your system. So system D makes it very easy to define C groups, to define access to certain network devices, to restrict memory usage and so on. So it's very handy. KVM or Docker, somehow they make use of C groups and other name spaces and other functionality. This would be the next level to isolate certain tasks. But it's not sufficient to isolate DMA access. So it's still running on top of your operating system. Linux has 60 million lines of code. So it's quite a big system and it's not possible to verify the system. OPTI would be the next level regarding complexity and security. So OPTI is something like a micro kernel running a site in a call trust zone. And the rich operating system is triggering a call into this trust zone, executing certain secure and cryptographic operations and you get back the result. So this is a well established mechanism. It's possible to integrate this into the UBOOT process. What would be even better would be if the hardware would be designed for this. So for example, certain devices should only, or GPIOs should only be accessible from within the trust zone, running within the OPTI, the trust execution environment. But most hardware nowadays does not have this wiring on the board. So that would be a nice feature, but in most cases it's not realized. So hardware is not supporting this. So there are just a few ways you could use BOOT into the OPTI, the trust environment. Another very interesting way to isolate tasks and application is using an L4 micro kernel. It's a family of micro kernels. So I work with L4 Reo Fiasco. So it's capability based runtime. And during startup you define who is allowed to send message to which application. So you've got the micro kernel here. So this micro kernel has only 60,000 lines of code, so it's much easier to verify this code. And the capability system allows you to define communication patterns between tasks. And the interesting point is that those capabilities can be handed over from one task to another task. If there are permissions. So in this way it's very easy to establish communication channels between tasks, but also dynamically extend those channels. So if you start dynamically a Linux kernel, this Linux kernel might receive certain capabilities and being able to access memory, to access certain USB devices and so on. So L4 would be the right choice if you want to restrict access to certain devices. The problem is that this kernel is tailored especially for your hardware. So if you change the hardware later, you start again from scratch and bring L4 and your system up on a new hardware. The problem is also if you've got a chip or hardware which has a single interrupt but serving two functionalities, USB and maybe modem. So then it's very hard to separate those two functionalities from each other. What we did in another project was we had the need to do some kind of 3D acceleration. So some guy managed to implement a governor for the 3D accelerator, allowing two tasks or two competitions on our system to make use of this 3D accelerator. That was really cool. So that's almost the end. So we talked about a charging station located on a parking lot having been accessible over a public IP. The fully qualified domain name can be resolved and we can access the device. So what will change if we move our charging station now into our home area network? So suddenly we've got the problem I mentioned with let's encrypt. So we will not be able to get any, no public CA will issue a certificate for our device. And that's a problem if we have some kind of user interface for the user who bought this charging station and he wants to manage this charging station. So this user has the choice between entering a user and password at the web page in plaintext and transferring plaintext or accepting some kind of self-scientificates being deployed on the target. But if you do so, the user will always see a warning. So once he tries to access this device with HTTPS, the browser will always warn him that this is an unsecure connection, a self-signed connection untrusted. He should store or asking if he trusts this server. So it's very annoying this. So if you try to establish some kind of security for IoT device located in the home area network, you've got to struggle with this problem. Another problem is if you move your IoT device into your home area network, some services might not be usable. So you might not be able to use DNSSEC anymore. It might be blocked by the router of the user. You might not be able to use certain kinds of VPN connections. So it's a lot of limitations in your home area network. And regarding this HTTPS problem and self-scientificates, I asked some guys from Chrome and they told me that they don't have any solution for this. So it's a bit annoying because the web page would be a nice access or user interface to manage your IoT device. If there is any solution, I would be happy to get to know about it. So that's the end of my presentation. So we had a look at the architecture of a secure IoT device. We talked about secure boot, how the functionality of the underlying hardware is used to establish a chain of trust during the boot phase. Once we're booted, how we establish encrypted storage, how we deal with the read-only partitions we booted from. Yes, so I thank you. Thank you very much for your talk. If you happen to have any questions, we have about two minutes left. If you would like to ask a question, please find any of the... Yeah, go ahead. Thanks for your talk. First of all, a small remark. Maybe it is useful to pay attention to kernel hardening measures and user space protection measures. How you build your software using your tool chain, which is further used on your device. And a small question. I didn't understand how this encryption container helps in your attack model. Could you describe it, please? Which one do you mean? The last slide. The last L4 kernel? The last slide, if you show it. So... This one? Further. No. It was a recap. Yes. So you have this encrypted storage and how it helps you and what is the purpose of it? So encrypted storage is encrypted file system. As the other file systems are read-only, we have no way to store any data. So if IP address is configured or username or some kind of for our IoT device some functionality configuration. So we have got to store it somewhere. So the encrypted source is intended for this. And why? Might be using DHTPS or no fixed static IP address, what is the DNS server and so on. And why encrypted that but not storing it? Unencrypted. So what do you protect if the device's attacker has access to it? It's not only the IP address. You're right. So it's also... We talked about a lot of HTTPS credentials. So a client key, VPN keys maybe to open a VPN session and so on. These should not be... So they should be configurable. They should not be... The file systems are read-only but readable. They are just signed. So this is Extender 3. The encrypted storage is to protect also those credentials that should not be readable, accessible by anybody else. Getting access to the flash memory. Yeah, sorry. So I didn't put it into the slides. Thank you for your answer and I'm afraid we're out of time. Please, some applause for Freback for giving this talk.