 trusted boot module, a project they developed as an open hardware module, a project that they're doing to create a trusted bootchain. The two speakers are Guido from Nordende and Marie Weier and I will hand it over to them. Thank you very much. I'm going to talk about our trusted boot module, a subtitled trusted boot on the Olimax holdings in a line, but it actually works on more than just this ARM development board. I'll first give you an introduction about works. We'll talk about the features, the limitations. Then I'll give you a brief overview of the design and then we'll go into each of the most part of the design in more detail. We'll give you a status report of where we are and possibly present future work. So I was briefly introduced, I'll take a few minutes to introduce myself a bit more. I'm currently doing a master's of science in computational science at the University of Amsterdam and I did my bachelor's there as well, I'm hoping to finish very soon. I'm more of a software guide and hardware but I'm trying to transition a bit more to hardware as well, just for fun. I really like Hacker Spaces, the one in Sofia and the one in Amsterdam are both brilliant and actually all the ones I've been to are excellent. And that's all in 2013, I started the foundation in the Netherlands called Heart for Internet Firehide and we're trying to run more exit nodes and make Tor more well known to the general public. So if you're Dutch and you're interested, please contact us there. I work at Widebox Systems, which is initiated by Guido and he'll introduce himself a bit more and I sometimes work for the Internet Archive. Okay, so back to the trustee boot module. There's three main goals here, in contrast to what you might know as UEFI or secure boot, we really want it to be under control. The thing is yours to hold, the thing is yours to hack, the thing is yours to do whatever you want with. So it's not designed to lock you out of your system. Our main personal goal was to prevent permanent compromise of our devices in the field and our trustee boot module has one restriction that we'll get to that more a lot later. It's specifically protecting the device going online and it ensures that it's at that point only running trustee code but it can protect your device forever, like most other boot mechanisms. So I'll briefly hand it over to Guido to provide some context on how and why we made the system. Yeah, okay, yes, I'll just do a brief introduction of myself and the context for the work. Madeleine together with Stephen who's also sitting here, the main technical part. So the context of this project is this little wide box and the wide box is something we've been working on for three years and this is an authorization server that sits with general petitioners and allows general petitioners to authorize specific parties to access medical information. So in contrast to many large scale information exchange systems in healthcare, this one is actually controllable by the doctor and possibly the patient if he has an account on it as well. So we're trying to build mechanisms to allow doctors to authorize other doctors to access content but to keep the access servers and the attack servers very small. This little box sits with general petitioners and we pretend that we have a secure solution and that also suggests that people can trust it but what does that mean because this box is now wide but it's essentially a black box. So what we're trying to do is actually make it a really wide box and to have everything that's in there open and controllable. We have software running on it that's public source. We don't give away the copyright but we do open it up so people can access it and inspect it and we have a re-producible build chain that we've been working on that has not been published yet but we've been working on it. Debian has a similar approach and we're applying it to Gen2 where the source code can be built in a re-producible way such that many people can actually build from the source the same binaries and check that that is actually the binary that runs on this box. Still that does not really make it a trustworthy distributed system. There are many things to consider them and one of the things is do we actually know the software that runs on there. So we need the software to be signed and preferably we need a number of people or parties to sign a software that's been re-producibly built and we need a verification system for that. So the system currently runs on the Audimax boards. It's also been running on a QB board and it could conceivably also run on a Raspberry Poly which is just an ARM based development board with Linux running on it in our own application stack that we're going to publish. The trick is how can we verify the software that runs on it and ensure that if there has been a compromise that it can be restored and removed from the thing because it's a distributed system so we cannot actually walk to the GP and say pull the plug and reconfigure the whole thing. So that is the context why we need a trusted boot manager. We need some mechanism where we can have the system fetch updates. We can control them, verify the signatures and control the boot process. Do regular updates of the system so we reboot every day so you know as a general measure and each time that we boot the system verify that we have the latest updates and the latest version and that's actually been signed by us or maybe other parties. But of course the principle of that is general and so Stichting and LNET has provided us with some funding to actually provide this as an open source not published really open source and open hardware project. So we've been designing the hardware and the software that runs on the MCU on the hardware to do this actual image verification and this protocol to ensure that the boot process is trustworthy and well I'm going to give back control to Malayan who is going to talk about the technical details more. Thank you very much. Okay, let's see. Yeah, this is good. All right, okay. So yeah, so a part of this is that the system will reboot every few days or every day so in case there is a compromise it will at least go back to what is trusted code and then from there on hopefully a load code that's not exploitable again. And specifically it should be very infeasible to permanently compromise such a device remotely. It should be clear at this point I think that local attacks are not our aim here because you own the things or if you take it apart and flash it off. Of course you own it. So Hito briefly talked about the device that we're currently using. It's an Olimax Olimax Xenolime 2 and this is our host device. This is not what the trusted boot module runs on. I'll get to that soon. It's a dual core machine. It has one gigabyte of RAM, SATA, Gigabyte Ethernet, USB and a lot more storage options including SPI North Flash. And it's one of the reasons we're also using it is because it's open hardware. So you can download the schematics, you can verify, you can make the piece of it yourself if you want. Of course open hardware here means that the design is open source but there's no CPU on there that's open source. There's a risk five development board that we are able to use. The trusted boot module essentially always ensures that the system boots to a trusted state. So that means that whatever the CPU starts running it should be our code right away. Usually there's just a tiny bit of code that actually starts with the CPU and then loads code from somewhere but it should load our code as soon as possible and whatever code the CPU is running before loads our code it should be read-only and people should be able to change it remotely. So of course we need to be able to upgrade the operating system so we need to upgrade our kernel. So if our kernel is in a read-only segment then how do you ensure that you get a more recent kernel with a dozen of exploits, those kind of things. And we're hoping to make it relatively cheap for people to produce themselves, take the PCB and assemble it. And we're trying also to handle various levels of complexity in the trusted boot module. You can envision different use cases for a trusted boot module and I'll get into those in more detail a bit later. So with terminology I'll explain all these things again but just to repeat them. The trusted boot module is obvious. Something we call the ROTS is the read-only trusted system. This is the code that we load initially and it's just an image stored read-only in some storage. Obviously when I say flash I'm going to be referring to SPI nor flash here so it's not about NAND flash. There's a big difference in reliability how much you can store on there. SPI nor flash is supposed to be very reliable which should last 10 to 20 years even if you're writing quite a bit to it and NAND is. There's a special art for balancing NAND failures and growing the size of the NAND without causing real failures. This is essentially what SSDs are doing there, just putting in more NANDs. We have the trusted stage and the untrusted stage of the boot process which would be fairly evident. When I say U-boot that's referring to the universal boot loader which is a boot loader you find on lots of MIPS and ARM systems so most of the ARM development boards run U-boot. Most of your Android phones run U-boot in one way or the other. Most of the OpenWRT or even most of the home routers run U-boot in one way. The initial RAM file system is something that Linux loads as soon as it starts so you just have something in RAM that looks like a file system and you can put binaries in there so you don't need to be able to load any root file system. KXEG is a method we use that is in the Linux kernel, I think 1, 2, maybe 3 years, that you can use to load a new kernel from Linux without restarting going through your BIOS again and the whole process so you can actually load a new Linux kernel from Linux. A simplified explanation of the LIME 2 is the trusted boot process on the LIME 2 would be that our code always needs to be executed first and in this trusted stage which we are in when we load the code we can communicate with the trusted boot module. This is a separate hardware device that's connected to the LIME and the LIME itself will cryptographically check the validity of the images so this is very different from a TPM where the TPM has a lot of crypto in there and random number generators and the TPM is purposely very simple so any crypto operations will simply be done on your whole system and of course the whole system will boot new kernels and tell the TPM that there's no longer a reason to trust the code that we're running because it might now be code that we fetched online as an update and we no longer want to be able to communicate with... We no longer want to have privileged access to our trusted boot module for storage reasons or such. So the setup is very simple, there's a LIME 2 board I think Kido has it there right now and there's this thing. This is LIME 2, so this is your ARM based and this is a prototype of TPM. So they fit on each other so the PCB was made to fit on the LIME 2. So how it works is the TPM is a very simple ARM microcontroller it has some form of RTC, some form of battery for the RTC and it actually has storage as well, it also has an SPI Nord flash chip so it can store certificates or keys or log files or specific operating system versions to prevent rollbacks. And the TPM and the LIME they communicate using serial so you simply take UART from both sides, connect them and they can talk with each other. And this of course will work for routers as well or router APIs or non-ARM platforms. And the TPM has some other features that I'll get into later but it should work on most architectures out there and we're hopefully going to take maybe a Libreboot machine next time which is I'm not sure if you know Libreboot but it's a fork of Coreboot which is an open source BIOS that runs on certain machines and it should not use any blobs at all on your system and Libreboot is the blob version of Coreboot. So that might make a nice target or maybe an ORT router for people who really don't want their routers to be compromised permanently. Yeah, so our goal is to prevent remote compromise especially permit remote compromise but that's very difficult so we're trying to reasonably prevent permit remote compromise because there are some exploits that could like there could be some bugs in our read-only firmware for example loading a file system, loading an X4 file system if there's a certain corruption in the X4 file system then the read-only code could be exploited and then before it even starts to load other code you can already break in. That's why it says reasonably. A lot of huge feature for the TBM for us of course is that we can put certificates in there or keys in there that are used to verify updates or images that are being downloaded you can have all the usual X5.09 certificates you can use a CA and you can have multiple keys and multiple certificates in there and our goal is to have a threshold system where we would have three or five parties that all sign the code put their signature on there and those certificates of those parties will be in the trusted boot module and then when an upgrade is downloaded it wouldn't be it has to be signed by at least say three out of five parties so even if one or two parties become compromised or they no longer exist at least we can still distribute the software as I said before the TBM is not a TBM so it doesn't do crypto, it doesn't do keygen we were not planning at all to implement our own crypto on a simple microcontroller unit and it doesn't have a proper source of randomness so that was completely out of our scope and specifically the crypto part if we have Linux on a device we can just write code and see or go that already has the crypto libraries and we can just reuse them instead of writing it ourselves so our focus has really been on making the project not too large making it feasible and hopefully easily usable for other platforms as well I think I covered most of this point we'll get some more of this but I've talked about the line the microcontroller we're using is a Cortex M3 I'll talk a bit about how the write protect works in the flash so it's actually read only code, not writeable code I'll go into more detail about the boot process so how do we actually ensure that nothing interferes with the boot process and it actually only loads our code and then there's the image verification and image loading so this is what our first hack looked like I hope you can see it from the distance so this is a zoom-in of a line board it's approximately a zoom-in of this part of the line board so these soldering joints here are actually pretty small and a very friendly hacker from the Amsterdam Hacker space helped me solder these three wires because these three wires were needed to actually get the device to boot from SPI Nord Flash I gave a small version of this talk half a year ago with the people who made these devices and they listened and now we have a very nice device which has an SPI Nord Flash on there so no longer we need to... we don't want to need any hardware modifications at all so that's nice okay, so the line has a lot of serial lines I think it has 6 or 7 as most all-in or 820 devices do UR0 will be for debugging and we are using UR2 to communicate with the CBM one specific thing I haven't mentioned yet or I glance over it is that we can't have any other storage on the line that is MAND's EMMC or microSD cards we can have SATA the reason for this is that there is some small portion of code fused in all the all-in or 820s that decides where to load from so if you plug in an SD card you're hoping it will load from your SD card before it loads something from MAND because you would have to desolder MAND to get it to not boot from MAND so there's an order in here and I think it might be somewhere in the presentation where some are going to mention now but the point is that it's very hard to protect these types of storage from remote parties to prevent remote parties from writing anything they don't have very nice write protection mechanisms you can mount something as read-only in Linux but that's not very strong you can just remount it as read-write or if you break into the kernel on a different level you can just write to it microSD cards specifically are interestingly complex and they have their own operating system and I think Bunny showed several years ago that you can in fact break into those operating systems and do a lot of weird things there's a link to that blog post at the end of the presentation and the same goes for EMMC and MAND so all our data is instead stored either on USB plugs which is not very reliable solution so we use SATA and have a hard disk or an SSD attached and as I said before the LIME 2 now has support for SPI North Flash I will get to how the write protect on SPI North Flash works in a bit so I explain the part of this when I refer to the small code that is on the LIME that loads the next code from either the microSD card or Flash that's called the B-ROM or the BootROM and in our case the BootROM finds an SPI North Flash chip and then from that SPI North Flash chip it loads something called the SPL which is a simple program loader the reason that we have a simple program loader is because the BootROM is very limited in how much how large a program can be that it loads so it loads a program and a program can handle larger pieces of code and then that program loads U-boot from the SPI Flash so it's just another step to actually get the boot loader loaded and then from U-boot which is our boot loader you can compare it I guess to Grubb as well U-boot will then load the Linux kernel from the SPI North Flash this was one of the tricky parts of the project because there was no support for this at all there are some devices that have support in U-boot to load from SPI North Flash but the A20 didn't have it so Stéphane, one of my colleagues he implemented the U-boot SPI driver for A20 devices for A6040 devices, A32 which is a large range of older devices and the patches I think still somewhere stuck in the main list but they worked really well so somewhere next year they'll probably be merged into U-boot okay so U-boot will then load Linux and the Linux kernel will start up and it will load the introduce your RAM file system which again is a small file system containing say a shell and some other basic program so you can run the script and boot to your real operating system so then the Linux kernel plus the UnitromFast will communicate with the TBM it will say hi I'm the host operating system and I would like you to give me tell me what keys I can trust what certificates are part of those keys go along with those keys I would like you to tell me what the software version was that I last loaded because I have no place to save it and then we will load a verified kernel and images using KXA so again there's a lot of things going on here to verify images to figure out what is the latest image of our operating system can we trust it is it signed by enough parties and then it will be loaded combined with a new kernel so this again is why I'm mentioning KXA here we could have opted for not loading a new kernel but then eventually your kernel gets really out of date and if you change devices only every five or six years that becomes a real nuisance because your kernel is connected to a network and you don't want to do that and of course by the way the reason that we from the host-limes side can't save any files on our we can't save any status because the only other place we can write to is our SATA disk and if we get compromised then somebody can just write to that SATA disk and put there whatever it wants so that's another reason we have the TBM so we can have some form of safe storage so I think this is kind of what I told you before just now but in the graph there's the boot run that loads the simple program loader the simple program loader loads Uboot and Uboot loads the kernel and from there on we can load another kernel and then we're all good to go so all of this code is on a read-only flash chip so none of this can be changed unless you have physical access the same goes for the TBM but it's kind of isolated completely so there's no real risk there okay so what are we actually using in the TBM I'm not going to pronounce the full name of this STM chip but it's an STM32F1 it's an ARM Cortex M3 and the features it has are serial you're going to get with the LIME and the SPI it says possibly but it definitely has SPI because we use it to interface with another flash chip that's on the boot manager and we're specifically using something called LIP Open CM3 and we actually picked the STM32 chips because of this reason because this is a very nice project that has a free library for many of these STM32 microcontrollers and it's actually expanding to other ones as well it's LGPL licensed and it was really great with good documentation that made it very easy to just use GCC and whatever normal tools you're used to do and better work at least we liked it and the program is done using JTAG debuggers with OpenOCD which is the open-on-chip debugger so what you can essentially do is you can just connect your STM32 f1 and then you can just hook GDB to that chip and load your code and debug it of course we need the toolchain to build the whole thing we have documentation at the end of the presentation that basically explains our whole process and has links to these toolchains and as I said the TBM also uses SPI in your flash for data storage so there's another small chip on there to store data we did most of our tests with the STM32 f0 discovery board because when you start out with these things you don't want to start out by designing your own PCB and then figuring out how these microcontrollers work so for many months we just use discovery boards and they work great you can get them from STM one of the more challenging things that we have in the TBM I mean some serial communication is relatively trivial one of the more challenging parts was the file system and the flash translation layer so because we want to store parts because we want to store certificates and keys and some log files and versions on the TBM we need a place to store it and these microcontrollers have very little storage on board so instead we simply decided to put another SPI nor flash chip there because they're again very reliable and pretty cheap you can get them in sizes from 1MB to 16MB and 16MB and that's pretty much the max but they're relatively cheap so stay fun again, work on this project you wrote a file system for this for SPI nor flash including a flash translation layer we tried to find file systems that would just run there's some nice flash file systems in the lambscreen as well but those don't run on a microcontroller unit then you can't just port such a huge file system to a microcontroller they're very resource constrained so stay fun started out by writing the file system and it became very complex because he really needed a flash translation layer to make those mappings a lot easier and at this point it's working quite well we're still working on debugging some parts but it's mostly been pretty stable and this is also included in the source relation if you have a need for this you can just take out just a file system and use it somewhere else this is a picture of our first set of PCBs there's five of them and I'm very happy that you probably can't see some of the bad soldering work we did I mentioned before I'm mostly a software person not a hardware person so we failed soldering at least four microcontrollers and at some point we asked for some help and eventually we managed to get it to work properly this is the version one and version two will be smaller and it will also be easier to hook up other boards this is what it looks like in action so to say so you can simply plug this PCB on top of the line and the battery goes right there at the top but it's not there right now the battery is required to keep time because the line again has no concept of time it can't save the time anywhere in case to save the time where it can't be modified by someone else the TBM can keep the time it's not always required to keep the time but if you're dealing with certificates then it's usually useful to know is this difficult expired or not it depends on your use case you can also not care about that but it's an optional feature of the TBM ok so again a linux and intramfs are on this SPI NOR flash chip and they have full access to the TBM in what we call the trusted stage trusted stage and untrusted stage is very simple in the trusted stage it can essentially do whatever it wants there's probably some limitations like you can't wipe logs or something but it can ask for the time it can read files, it can write files and essentially do pretty much everything so then the lime too will get whatever information it needs verify the image and then load it and then just before it does KXAC it loads the possibly untrusted code which is no longer physically on the device so to say it will tell the TBM I am now moving to something to the untrusted stage which is you can no longer trust me for most of these commands because it might be some remote attacker who compromised the system and then wants to mess with the trusted boot module the trusted boot module is always connected so yeah there's always a serial line that works so it's pretty hard to prevent people from talking with it because they can't mess with it and of course in the whole trusted stage our kernel is very minimal it doesn't have any network capability so there's no attack factor there okay so the untrusted stage is as I said it's pretty simple in this stage the device can do whatever it's supposed to be doing but nothing more so at this point we're connected to the network we might be doing a lot of crypto or there's a chance of people raking in and then the line has almost no access to the TBM it can probably still maybe get the time and it can tell the TBM that it managed the boot successfully which is one of the main things that the TBM really needs to know because otherwise it will just reset the line but yeah I can't mess with the aspect last ship and again of course in the untrusted stage the operating system can load other code it can touch new updates it can restart programs it can download zips or whatever it wants but this is not something we can protect against it's not our goal of the TBM to protect against this what we want to protect against is somebody trying to mess with the next reboot when we forcefully reboot the system again so the most essential part here is that the line can simply tell the trusted boot manager that it's been able to successfully boot okay so I haven't talked a lot about this but I mentioned some basic things so there's one of the features of the TBM is trust management and it can store several keys or certificates and in a future version it will also be able to contain revocation statements of keys if the use case or desire so we're hopefully going to make the code relatively simple but if you want more features you can enable them yeah so this is basically the threshold scheme that I talked about before we will require say three or four out of five keys to be four out of five signatures to be there to actually trust if an image is valid we could store more but and again I'm specifically saying keys here because there might be scenarios where I don't want to deal with time and the category of a certificate is kind of sensitive so you can also deal with keys and not deal with certificates at all but you can also use certificates so you can have a CA and deal with this yeah key revocation could be required in our case we are not going to start with that because it's pretty complex and sometimes even human interaction you want a person to go there and actually change the key so it really depends if your company simply wants to secure his Wi-Fi routers and can just walk over there himself to change any keys so then you don't need any dynamic key management you just load them in there with a program for example there's no perfect trust management system and it really depends on your use case and whatever complexity you need so your requirements are essential in the most simple case one or more keys can be stored in the read-only trusted system so then they would not even need to be stored in the TBM but this is a very simple scenario and these keys are used to verify the images and again you can just require a certain amount of keys there but in such a scenario key revocation is impossible and you can't essentially manage any kind of keys so this is more suitable for someone at home who just wants to secure their machine yeah just the first goal and this is working at this point so this can run on other devices it doesn't just have to run on the line it can run on the Raspberry Pi 3 or other or the Pine 64 or an Orange Pi or any of the other cheap Chinese development boards as long as they can boot from SPI nor Flash and they don't actually load the code before that so you need to have a way to ensure that it only boots from SPI nor Flash so if someone plugs in the Z card that's kind of an issue and especially if there's onboard NAND Flash then you usually can't force it to boot to SPI nor Flash the Raspberry Pi is a nice solution to this where you can simply connect certain pins together that will force it to boot from a certain storage device but most of the others don't have that so the current status serial works on the trusted boot module the real-time plot works and the file system is working so using the serial you can communicate with the file system you can say LS or CAT or write and you can interact with the files the protocol implementation is between trusted boot module and the line work so they are able to talk to each other and communicate and KXX seemed to work and we haven't actually run until a lot of issues yet I'm saying this because it's one of the things I was really afraid of is that if I'm having a Linux kernel from say version 3.0 and I want a boot 4.6 then it might be that they initialize devices very differently and if the old Linux shuts down it doesn't actually shut down certain devices and then when the Linux boots it's a big problem but fortunately this hasn't popped up yet what we also try to do is to boot from KXX to Uboot but that didn't work very well, Uboot tried to initialize the memory again and completely failed so we gave up on that the SPI FlashWriteProtect works but it requires a fork of FlashFirm and FlashFirm is a tool to program mostly Flash devices and Google forked it to add WriteProtect support so the way WriteProtect works in these Flash chips is that they have 8 pins or 16 depending on the size of this chip and if you pull the WriteProtect pin down you will lock the WriteProtect down but that actually doesn't mean that you can't write to the Flash chip it just means that you can no longer change what regions are WriteProtected and what ones are not so this is actually something that took me a day or two to find out so what you're supposed to do is set up a region that's supposed to be WriteProtected then you will say this region can no longer be changed and then you enable the WriteProtect so if you just enable the WriteProtect you can still write to the Flash chip as I said we developed an SPI driver for Uboot for the Eleanor boards and those patches are on the mailing list and the LIME 2 hardware changes are finished so within the next few weeks Olimax will release those new boards and hopefully everyone can play with it and there are other A64 boards which is a different system on chip pool so support has been replaced and finally one other feature that I haven't touched on a lot yet but we seem to have some extra time so I'll touch on that to see how the module can reset the LIME so in our case Hilo said it would be very nice if we can reset such a device daily because if it's been running for a month we can't really know if it's been compromised or not so we need to find the balance between how long would that run and how annoying it is to reboot the device so it could be a day, it could be a week something like this so the TBM is connected to the LIME 2 to a specific pin that will cause the LIME to reset so if the TBM pulls it up then the LIME resets so this is what we use for say daily or weekly reboots and we came up with a mechanism to not just reboot daily but also have the LIME tell the TBM I just want to run for a little longer so hold up for a while and we've even been thinking about a network protocol where we can issue do not reboot signals to those devices so they could fetch something from our website and that's a sign statement with a timestamp in there that says you don't need to reboot yet but in the case of a serious problem where a lot of devices are compromised we can simply not issue do not reboot a signal and then when the LIME is unable to send such a thing to the TBM then the TBM will reset the LIME the issue here however is that this will require some crypto on the TBM and that's something we actually didn't want to do so that's not finished but it is able to reset the LIME so there's a lot of testing to be done still I mean everything seems to work but it might not so we're planning on to test this in the next few weeks and there's some work to be done in the read only trusted system implementation still it can verify basic images but because we're also dealing with reproducible builds figure out what extra metadata we want of those reproducible builds and deal with multiple parties signing the software we've actually spent some time writing user guides and tools for this talk and hope that some people will read it and ask questions afterwards but they're not fully finished so there's quite some information there but if something is not clear then please if you're reading it let us know and in the nearby future we will also provide documentation to use the TBM with other devices and complex trust management is still on the table because we haven't needed it yet and it really kind of depends on the read only trusted system there there's some attack vectors here that I haven't touched on yet but they're all kind of subtle for example if the TBM is power cycled at any point it will forget or not know what state it is in so always go to a trusted state so if somehow the attacker can power cycle the TBM then it can essentially just permanently compromise the system because then it can read files, it can write its own keys or certificates so this is the real issue and right now the TBM is connected to the LIM but in a way that if the LIM would try to pull the power the LIM itself would also reset but this is something that's very subtle and if you're just using this on your own device you should be wary of this we should probably mention that more clearly in the documentation and something I mentioned at the start of the talk there's some permanent boot time exploits that you can imagine again if we're using a file system say X4 and that's on the SATA disk and the attacker figures out how to write his own file system there that when Linux reads it actually overflows and then there's another payload there that then executes while trying to mount the file system we have a real problem because then the really trusted system is compromised another thing that we haven't figured out and it's actually kind of funny is you can't reboot as a LIM right now if you reboot then you don't know what to boot and the TBM won't talk to you because you're still in the untrusted state so this is again where the the LIM where the TBM being able to reboot the LIM comes in was in the previous slide here so the fact that the TBM can reset the LIM is something we can use for rebooting so then the LIM can say well can you reboot me and then move back to the trusted state but we haven't done this in part because we need to make sure that it works the way it's supposed to work and of course bugs in our trust management simple things like key verification or image verification against the key shouldn't be such a big deal but you need to be careful there and that's in part why we're trying to keep it very simple at first place and this is I think from the previous presentation because the TBM does have a concept of time now or at least it can have a concept of time so in this case the TBM can give a valid time to the LIM and because the LIM relies on the TBM in the first place it can assume that the time that the TBM is giving it is sensible so there can be some concept of day and time but if you don't need it then you're just using keys not certificates then you might not even need it and there are some obvious issues with the system but those are I think we can't do anything about it if an attacker logs into the system and we store all our updates on the SATA disk then simply removing all the operating system files from the SATA disk will break the device it can still load the real nature of the system but there's nothing else you can start to the system no longer works but I think this is preferable to a system that's permanently compromised and can steal your data whenever it wants yeah so I touched on the reboot part here I'm really hoping to move to some other devices as well with this project so I've mentioned routers and laptops several times one of my personal favorites will be to have a reproducibly built system that runs with people in the homes of people that runs Tor nodes I'm not sure how familiar everyone is with Tor but I'll give you a very brief introduction so Tor is an under routing network so if you're using Tor to connect you can conceivably hide your location identity to people if you're using it in a clever way but it's a decentralized system so it relies on other people running Tor nodes and right now it's there's quite some people doing it but it could be a lot more people running Tor nodes and you need to keep them up to date to make sure that the network can be compromised so this is pretty difficult so I really hope to take some parts of the work that we're doing here and turn that into reproducibly built Tor routers that can securely update themselves and people can just plug in at home and not worry about it ever and share 20% of the network with the Tor network another open question would be right now our boot image format is very simple so it contains the image, a few signatures and some metadata and we will need to expand that for a reproducible build setup so there's a full chain of trust that you can trace all the way back to the first image you've ever booted as for the license it will be something open we haven't quite figured out what's fitting we are using lip open CM3 so some parts will probably need to be at least LGPL some other parts might be licensed there's a few other things I should really mention I've mentioned reproducible builds a couple of times it was initiated by Dabian but open SUSE is now doing it as well and another distribution that I don't remember right now but this is a really cool website if you want to figure out how reproducible builds work and who's working on it and I think Dabian has been able to reproducibly build at least 94% of their packages so it's really impressive so probably everything you're using daily can be reproducibly built and another really cool project is HADS from Dremel and it's essentially it can work with tails so it's kind of like a boot manager but it works with core boot and it does a lot of cool things to prevent physical compromise to your device as well so we are in our project mostly not caring about physical compromise but if you're interested in this kind of stuff and really preventing hopefully government agencies to mess with your device at all and you should really check out and there was a very cool talk about it at SUSE as well we owe some thanks to various organizations and people and now for funding our project and letting us work on this project I personally owe some thanks to people at my local Hacker Space for explaining to me how some hardware parts work helping me soldering things that I really can't solder Olimax has been very kind in talking with us and figuring out how to fit our user request which is an SPI neuroflash that doesn't require hot gluing and nasty soldering under the already very crowded devices OpenFest for allowing me to give a short version of this talk and of course Shaaf for organizing this awesome camp and letting us give this talk here that went pretty fast you can mail me at this address and you can mail white box systems basically our website you can find contact information there and more things go out to the really awesome Linux SunXI community Allwinner themselves are not very well known for basically handing out GPI license code and helping the community develop proper Linux drivers for it but the Linux SunXI community is basically people from all over the world that have picked up Allwinner's lame source jobs and they fixed it and turned most of the code into proper drivers that are now in Linux so without this community we wouldn't have been able to do this at all with those Allwinner devices and as a result of their work in my opinion those devices are one of the best supported ARM devices ARM development devices that you can get for cheap devices finally some extra resources so we've put up a simple page on opensource.whitebox systems that are now that contains links to the technical documentation and user documentation and has links to the Git repose that's already online right now the read-only trusted state will come online in a few more weeks I think that's it thank you very much so we have some time left for questions two microphones in the room so please in any questions go to the microphone oh wait could you wait open up secure boot software thanks for the plug for heads your motivation for not using a TPM one of the key features that the TPM potentially provides is remote attestation that if this server is talking to other servers to be able to prove to some degree that the software running on the machine is what it says it is is that in scope or is that something that is sort of outside your your threat model are you talking about software that's been running at the system for a long time or just during system startup as you point out it's hard to know most of these things really only assess the system at boot time but when the machine goes to say communicate with an outside server is it desirable to be able to get a something like a quote from the TPM or a TPM hardware to say this is the kernel that has been booted this is the software image that it is running so that you don't have to so that you can trust that it is actually running what you think it is well that would essentially be very useful let me answer that in two parts so I think it would be very useful I'm always afraid that there's always some extra exploiter issue there that the system can't figure out and then we're running these devices for years and years because we think the TPM tells us that everything is working and then it's not and specifically in our case but I think also in the tour case to some degree but more in our case we're dealing with essentially we're firewall for medical health care so we well not a firewall but we share medical data on one on one with parties over TLS connections and we have some form of flash access to certain documents that contain medical like privacy sensitive data so it's it's you have to wait your risks I think the other reason that we didn't just take a TPM is because in my experience but maybe you know a lot better you know a lot more about this it's not that trivial to hook up a TPM to a random system the Chromebooks are very nice because they come with a TPM and Google Wrots offer for them but if you just have a Raspberry Pi or a random development board you can't just plug on a TPM so that was the other reason for trying to figure out how we can write something relatively simple that suits at least a part of our use case and in your current build there's no way to have a secret in the TPM is that correct that it's running completely open source code and the user could potentially a local user could potentially dump or reflash the code in the TPM whoever owns the hardware can of course just take our code and flash whatever user wants on the microcontroller is that what you're asking? yes so that the TPM is closed source that is completely un-reprogramable that closes off that particular vector they're complex devices of course it's still an ARM Cortex so you don't know what it's exactly doing but it's likely that hopefully there's not a huge vector in there not saying that the TPMs have huge vectors but it could be part of your threat model thank you for the question any other questions then I would like to thank Malijn and Guido for their thought