 Yeah, so Thanks everyone for coming especially since this is the last slot and there's a closing game after this one I don't think you need to run out after my talk. There's 15 minutes or so to get over there and Yeah, so Yeah, let's get started. I'm young liberal. I'm from pangatronics. I Started there doing kind of development work and now do talking with customers finding finding out what they want to do and Looking at other technologies that are coming up and yeah deciding how they fit into the embedded context So you probably all Basically now that does the Linux storage stack in a very simplified way. So, you know on one hand we have Block devices that is the normal Hard disk drives SSDs SD cards and so on where you have normal fire systems on top and In some cases you can have the device map a layer in between which can Yeah, do interesting things with the data in between the fire system and the book device and on the other hand you have the MTD layer which is used mostly on embedded devices to store data on Yeah storage devices that are not as simple as Here you get the right this block to this address. So where you need to do most of some for example like a net flashes and To make that usable for fire systems for data storage there's the UBI on sort of block images layer in the Linux kernel Which is then used by fire systems like UBI FS So and on top of this stack we can introduce encryption authentication and come both in the at the same time at various levels and We could also do that in our own applications, but for this talk. I'm only looking at Layers or infrastructure which is already in the Linux kernel so that the Authentication and encryption is transparent to the application so that's what I think is most useful for our general embedded devices and interestingly in Any given project only usually one or two of those is actually a good choice and if you choose the other one Yeah, you're choosing a lot of pain Probably not initially, but maybe later When you do things that don't really fit to what that layer is providing you So there was the word crypto three times on the last slide So we need a bit of cryptography knowledge not much. So I'm going to give a quick refresher Most of you probably know at least some of those So we're going to talk about hash functions But this is a method medical algorithm, which takes a chunk of data and produces deterministic fixed-size result independent of how large the input data is and the interesting thing at that level is That you can't go back from the output to the input and That you cannot generate another block easily It is it is not feasible to generate a different block of input which produces the same output But it's what we usually use in the form of the SHA algorithms one or 256 and so on so Building on top of a hash function. You can have the hash-based message authentication codes Which is basically a method of using a hash Together with the secret to authenticate data the way that this works is that you take the hash put the key in first then your data and hash the result so that you Can see if the person that generated this HMAC is also in possession of this secret which is usually yourself at an earlier point in time So the next step relates to public key cryptography There is the concept of a signature which is used for data authentication So you have a private key on one hand, which you use to produce a signature for some data and Someone else can use the corresponding public key to make sure that this data was actually signed by the holder of the private key So that's where we can separate authentication from the Between multiple people or systems coming to encryption there for this talk basically to Relevant differences. There's unauthenticated encryption and authenticated encryption So for the unauthenticated encryption that is what we usually use on on this encryption and so on I Take a block of data. I have a key encrypt this block of data stored on a device but any attacker cannot decrypt this but he can modify it and I can still take this modified Encrypted block decrypted and I will get something out and that May look like random noise. It may look like somewhat like my initial data but there's nothing telling me that this was modified and This is exactly what I get with authenticated encryption. So at the decryption step The algorithm tells me if this was the original data or if it has been modified So I'm not going through the different Implementations I had on the storage stack For authentication encryption and the few cases where we can do both at the same time and I will go through them Beginning from the block device going up through the layers ending on top of the fire systems and afterwards I'm going to Talk a bit about some general considerations which come up when implementing such mechanisms so and if at any point I'm Not explaining something in enough detail. Please wave at me or shout and I try to Explain it in more detail. So beginning We start with the emberity that is Element in the device map a layer which can be used to authenticate data. So I take my file system put it into the emberity container basically and store that on my block device and in addition to the original file system data, I have a tree of Hashes So basically I have my data pages from file system. I take a few of those hash each block individually put all those hazards in a new block Do that for some other nodes and now I have a new layer Which are blocks full of hashes and hash those again? Up the tree until I end up with only one hash so this allows me to Make sure that each individual block that I read from the file system. I can look at the in the hash tree go up the layers and find out if that is actually Intended to be at that location in this file system that works only if I know the original Root hash so this has to be provided out of band In the originally that was spun by the bootloader in the kernel command line Or it was compiled into the corner so the kernel basically knows which root file system it expects and No single block in this image can be changed But I'm sure that the original data is there when I read it and I don't need to go through all the blocks Initially to check them. I can just do that incrementally when I read each block and very recently The mainline kernel has gained support to have a signature in this root block So I can do signature checking of the root file system By just having a public key in my kernel image And I can then easily update the root file system and just check the new signature input that So that's very new The tools to create that and configure it is in verity setup That comes from the Luxe 2 package. So it's probably installed on most of your laptops Together with crypt setup and some other tools So usually you combine it with something like x4 Squash FS or the ERO FS It's in your read-only file system and in that way it has been used in the past and Currently as well for Chrome OS and Android. So they have fixed root partitions that they check at each access so at the same layer in the Device mapper layer. There is the dm integrity dm integrity module so The dm verity only supports read-only file systems. So if I want to have a file system Which authenticates my data, but is also writable. I need to do something more complex. So I have For each block of data, I have some additional smaller space where I can store authentication data and this was not invented by the Linux device mapper people but by the storage industry. They have something called t10 or device integrity format, which is initially was done for SCSI devices and Sus disks where they have for each data sector some additional space to store integrity data and Basically, this API is emulated by the dm integrity module But to do that it needs additional space so after Several blocks we get one block of integrity data because the integrity data is smaller and this single block combines integrity data for the preceding data blocks that Leads to a problem when writing to this What happens if I write data and that one then my system crashes and I haven't updated integrity data So on the next boot It there's a mismatch and I can't read my data. I at least get an authentication error So what the integrity does is it has journaling for the data and for the integrity meta data So each right is all first written into journal and after it's committed into the journal It's written in the normal data area. So that costs some performance because basically every Data element is written twice so, yeah, we lose some performance for that and on its own it can use Simple checksums to detect data corruption, but not intentional attacks And that's configured by a via integrity setup So then there's the encrypt that is probably the best known of the methods. I'm going to talk about it's an Made module to do sector-based encryption So I take a sector of data encrypted and write it into my block device. That's pretty simple at that level It supports many different algorithms can get its encryption keys in several different ways And it's usually configured at least on desktop systems using crypto setup The crypto setup tool has gained recently a new feature for re-encryption So you can change the underlying encryption key on the fly For example, if you remove someone from the access list of your server You can re-encrypt all data. So that person does not have access to any further data that you write and again, it does not authenticate and That is because to authenticate we would need some additional space to store this authentication data. It is an underlying Constant of encryption and authentication The normal length through preserving encryption can only be unauthenticated so Irrelevant which algorithm I use As long as I don't have additional space I can't authenticate. So that's what the encrypt does is a good choice for Laptops if I don't have additional space or if I need the performance at least I have encryption and it's hard for an attacker to Modify something specific, but I'm not really protecting it against that. So and that's something gained in the recent years that I can Combine the integrity and layer the encrypt on top and at that point The encrypt has some space to store this authentication data So when I encrypt in sector, I get additional authentication data and that is stored in this metadata area provided by the integrity so at that point I can If I read back a sector from the storage device run the authenticated encryption and can detect intentional modifications There's one downside to this or limitation is that because it's sector-based. I cannot Detect if this is the correct version of the sector that I'm reading So an attacker could take an old sector from an old copy Put that onto my device and I would not notice that this has been modified But depending on which attackers you are you're expecting that might be accept It's definitely more secure than just using the encrypt without authentication. And so There are again several algorithms supported by The encrypt with authentication called a ad algorithms So it's authenticated encryption with associated data, but we don't have any associated data. It's just authenticated encryption our case so the recommended algorithm is ages 128 random, so it uses a random miscellaneous vector for each sector and that's also Security improvement about what the encrypt can do without authentication. So moving up a layer In file systems We now have since the very last main icon is Something called FS Verity, which is basically the same idea we had with DM Verity, but applied to files So the main use case for that is Authenticating large files on a writeable file system So the main use case where this was invented for is Android packages on mobile phones, so that you download the large APG to your X4 file system or some other writeable file system and The Android runtime wants to make sure that every time it accesses this APK That is still unmodified compared to what it downloaded from the store So You basically have File system call Which you can run on a single file and the file system will generate this hash hash tree for you report the root hash back and then you can check that this root hash is The one you expected and after this point the file system is completely immutable so after the next reboot or Any time you want to Verify this file can ask a file system for the root hash and Compare it to your own database, which is stored somewhere else and Then on each access to this fire the Hash tree is used to authenticate the data that this has been read So you get authenticated read-only files on a writeable file system So yeah, Android is basically the main user for this And there are some ideas to integrate this with IMA, which I am going to talk about later so and basically the same idea with the embarity and FS variety is with the encrypt and FS script. So we have block based on block based Encryption of fires at the file system ever that allows you to have different keys in a single file system Which is again interesting for Android or any other multi-user system So each user can have its own keys on The shared file system. So you can you reuse this free space? random, yeah dynamically between the different users and One additional benefit is that you can mount the file systems without having the key and you can also Remove complete directory trees without having this key. So for example, if you have an Android phone and Added an additional user and Later want to delete this user. You don't need to have the corresponding encryption key yet You can just delete that sub directory completely and the file system doesn't care. So For the security side, it's basically the same SD encrypt But has more complex key management because you need to manage keys for each user So it's only really useful if you have a system where you want to have Uses with their own passwords or their own encryption keys and need to share space between them and Since last year, there's Basically the single case where file system Does authentication of the complete data in the Linux kernel with UBI FS That this works with UBI FS is yeah lucky coincidence maybe because UBI FS is a file system special specifically designed for flash use cases and With this constraint the file system is built in a way that it never overrides data Which is a problem. We've seen with the integrity You cannot simply update things in place and keep the hash trees in sync so by just never overriding data and storing all the File system data and metadata in a tree, which is basically written linearly over the flash and then regularly Goblet-collected you can just add hashes to each of these tree nodes Which then authenticates the parts that are below those tree nodes so With one single Key you can have authentication of the whole file system and make a file system metadata but only for UBI FS so in one case the root hash is authenticated we are H max so it's a Fixed secret or you can have a signature in the root hash in the root node similar to what it has been done for Deamverity for initial flashing in the factory So every system gets its gets the same image signed with a public key and on the first boot the system uses its own key To update that to a HMAC and then the system file system is writable So it's the best choice for NAND and other raw MTD devices Probably because it's the only choice But then at least you get authentication and you can use FS script again to Encrypt specific parts of that file system So or not net flash you can't use device mapper so there's no deam script and so on so There's also eCrypt FS probably longtime Ubuntu users know about that It's a stacked file system So you mount it on top of a different file system and it encrypts all files in this upper file system That has been used for home directory encryption per user by Ubuntu since Over ten years ago But it's now deprecated and they use deam script as well as most other distributions And the Ubuntu employees that have previously maintained that Now do other things So the maintenance is a bit unclear the current part is still maintained, but the user space tools didn't get releases for For some time now and yeah, so it's probably not a good idea to use that for new systems So and it has no authentication There were some patches for authenticated encryption posted Several years ago, but they were never merged and So yeah, it's I considered superseded by FS script then There's IMA EVM Which yeah, it's a bit On on a tangent It's it's layout on top of the file system, but it's not a file system by itself it stores its own metadata in Extended attributes in the file system and it's mainly initially developed for use with TPMs and trusted boot or a verified boot and remote attestation so that a Role mode system can prove that your computer or your laptop or desktop in the company is running the approved software image and It does that by having hashes of each file in extended attributes Sending those to the TPM to So the TPM can basically log which files have been accessed and if only authentic Whitelisted files have been accessed and the system is trusted and secure So that alone cannot be used by the system itself to protect it against any attackers That wants to modify files because only the mode system can then detect that it's not in a secure state anymore so The idea was to introduce this EVM extended validation module on top of that Which basically uses HMAX again to authenticate each individual file, but then you have At least currently because some parts of the initial design have not been implemented There are texts possible like Copying the shell over the init Binary near reboot rebooted the system In my EVM detects, that's an authentic file, but it cannot know that it's in the wrong location So we get a root shell so it's interesting for remote authentication, but more or less useless currently for Protecting the system itself against modification. So there's a talk On Monday by Luke Hins About the key lime project. That's Yeah infrastructure for doing this remote authentication. So if you're interested in that Go to his talk and Watch the recording So we've now gone through several implementations, but there are some things that apply basically to all of them Initially Where do we store the key to? Authenticate or decrypt our file system So we now have a mechanism to encrypt data, but we still need to have some key that is not readable by the attacker so on a desktop or laptop system the way this is usually done is the user has to enter a password the key is derived from that and So an attacker that simply steals the laptop does not have the password. So it does not have the key For embedded systems that is not really useful Because there's usually no user who wants to enter the password to Yeah, talk to his fridge or whatever So many of those embedded socks have some mechanism To store a secret key inside the SOC itself That can be used to encrypt such secrets it's usually called wrapping keys and That can be used together with a Verified boot or secure boot to make sure that only the authentic boot loader or kernel can access this key and decrypt the rest of the data But there are other talks at this conference and previous iterations to Look at how this works and also by You like been yourself here to talk earlier today how that can be done with the mainland kind of today and Other options to source this data are T's or opti which is an open source trusted execution environment on our platforms Which is basically the way that Android does this so they have a tea Running in a separate processor mode to store such secrets or you can use a TPM to store that secrets so When we think about These mechanisms there are some which apply to read-only file systems, which are very low overhead like DM verity But they have the downside of being read-only so I can't just edit my configuration files and root file system But I still have usually some configuration data or application data that needs to be stored somewhere else so I need to decide what how to partition my system in Usually with only root file systems and maybe application file system and writeable data partitions So I can use the high performance and most simple DM verity for the root file system and Do some things like DM integrity with the encrypt for authenticated encryption on the data side so I only have the the overhead of the Combination and the additional logging for the errors where I actually need it So in the case where we have authenticated starch We cannot actually protect against an attacker which gets into our system via some network exploit and then Just uses the system as it is to write to that authenticated partition because he has access to all the keys so if we only had authenticated writeable storage After such an event I would need to destroy my device and get a new one So usually it's useful to have some sort of read-only authenticated recovery partition that can be used to erase all the writeable parts restore the factory state and get back to a working state after after an exploit and for the developers among us it's Also use case that needs to be thought about in advance but only hurts later because We will get devices back from the field which have failed in some way that we don't understand and We have when we have systems which are locked down with verified boot and have only authenticated starch We usually can't do the normal debugging approach we are used to so and Possible way to do that is to have a way in the boot loader or a kernel startup That can erase these encryption keys which are used for our customers data so Which I intended to protect those data partitions Just erase them and disable verified boot and then you can just use your normal Mechanisms to start another kernel and look at how is how does the file system layout look how Does the NAND flash work and so on to at least get some data back out of those return devices so coming to the end some recommendations so for read by block devices Use dm-crypt as you're used to with laptops possibly with a dm-integrity If you can take the performance hits and need the additional authentication Use dm-verity for read or if I systems because it's simple and well tested on NAND flashes you can use uBFS and enable encryption authentication if you need it and Do something like verify boot keep wrapping to store the actual master key Which is yeah the root of the security of the rest of the system and then use yeah, hard acceleration for Doing hashes and encryption on those socks. It's it's usually well supported So in summary avoid the complexity and only select the necessary components depending on what you're actually defending against Yeah, so that concludes the talk Happy to take questions Thank you. Yeah, so I have a microphone here which I'll pass around the room Maybe just come forward Yes, thank you You said something about replay attacks because even though the sector is authenticated when it's encrypted You could take a previous sector and replace it. Is there any way to work around that? Yeah, that's correct so currently What is implemented in the links are there and there's no way around that at least for Dm-verity and dm-crypt so uBFS authentication would detect that because that's a Continuous tree up to the root hash. So we only have the most recent consistent version But as it's sector-based if an attacker has access to the device at two points in time Can make a copy and then return sometime later to restore Maybe an old vulnerable kernel then you can do that if he figures out where your partitions are So you still can't read the data So he needs to have some other way to find out which parts he needs to replace That is definitely hard, but it's it's not prevented by the mechanism itself. So this limitation is known to the people implementing this and they're definitely thinking about ways how to solve that on the sector level, but it's Yeah, you can search for the the authenticate full description problem That's it's it's cryptography research and it's it's not Solved in a general high performance way Yeah, someone else if no other questions come up then thanks a lot