 So, next talk is from Milan Broz. Milan is a software engineer at Red Hat and he's also a PhD candidate at the local university here at Pro. He's going to talk us about the story and the encryption and the question of data integrity. Thank you. I hope you hear me. Thank you for coming. Afternoon is quite late, but I will today talk about something that maybe follows the talk from last year about Clux 2. I'm now going to talk about storage data integrity detection, maybe correction in full disk encryption. So, thank you for your introduction. I will just add that this work is partially part of my academic work and part of the software engineering. I'm trying to do something useful. We will see if it really works. So, let's start. What I would like to talk here can be split into two parts. First part is a little bit description of some terminology and maybe description of what is the checksum and what is the authentication pack just to understand what is authenticated encryption because we will play with the data. And the second part is real demonstration what we actually developed and what hopefully will be some day in distribution. Maybe, maybe not. I will mention the problems. So, let's start with that. First, why we should care about data integrity at all. The major problem here is data corruption. Data corruption is something, some change in data. I'm talking about the storage devices, so data at rest devices. Data corruption is something that basically changes the data without intention and the most importantly without detection. So, it lives somewhere and sometimes later it will come and do some damage. What is important? I need to split this into two separate areas. The problem is the same but the solution is different. First is silent data corruption. Usually, if you talk to storage people and there is a lot of such people there, you are talking about silent data corruption. So, something what happens if bit flips in memory happens and it's stored to this. Something if you have flaky cables, data misalignment but something that is random. It's not intentional change. So, if we can detect it or we can fix it, okay, that's correct. The second part usually is not so focused by storage people is some not authorized change of data. It's intentional change of data by usually some attacker trying to play with storage device and later it can do some damage. The solution for two problems are different. We will focus on the second one because I am trying to combine integrity checking with full disk encryption but this split is quite important to understand why some subsystems cannot provide real integrity prevention or integrity protection. So, what is data integrity? As I already said, it's the way how to provide data consistency and it should at least detect that something is wrong during the whole life cycle. Because we are talking about the data at rest, so not in password but in normal speak about the disk or SSDs. It can be even years. It can be a very long period, so you need to store some checksums or something like that. So, the solution for the first problem, random data corruption or silent data corruption is basically just a simple checksum. You probably met it in several programs, several tools. For not authorized change, you need something more. You need a little bit of cryptography there. And then we usually talk about message authentication codes or if I will be talking about authenticative encryption usually about the authentication tech. It is almost the same but it is something that can be calculated only by authorized person. I will talk about it later. So, if we are talking about encryption, we usually want authenticated encryption. I will show why looks in that current version cannot provide any authenticated encryption because we don't have space to store that. So, integrity protection. As I said, you need some additional space. You have the data. You will encrypt that, decrypt that. But if you have link present encryption, you don't have any additional space there. Imagine for example some network protocol. There is no problem with that. You just can encrypt the data and add some additional data. This also packets slightly increase in size, but it's okay. In disk, it's not so easy because the sector is fixed. We need some additional data. Additional data can be used for. Simple checksum, authentication tech, but also it can be used to store some additional data like forward error correction. So, we can detect the corruption and we can basically repair it if it's possible. For the error correction usually there are some algorithms like read salamone codes, something working with Heming codes. But I don't want to explain it more here. Just the problem is the same. You need more additional data for the redundancy. And we can somehow combine it with encryption as well. But that's something I mentioned like a possible extension. I will shortly mention it in the example for DM Verity, what you have probably on your Android devices. So, that's the beginning. And question usually people ask there why I should care about it here because it's already in hardware. Well, maybe it is, maybe it isn't. If you buy some very big proprietary solution, you will probably have something that tells about that integrity there. Some SSDs probably calculate something inside the drive, but you cannot prove that. But there are definitely disk that just don't do any error checking at all if it's retinal data. It's okay. But definitely you cannot prevent that not authorized use of the device. If someone will just temporary the device, you have no way out to detect that. So that's the reason why I would like to look. And just one mention more. It was question if we can implement everything, if we can prevent so-called reply attacks. Reply attacks is something you take the snapshot of the device, order snapshot, and you will place it back. So we will basically revert the, either the whole disk or part of that. If I am talking about just common of the shell of disk, so just normal disk, we cannot solve this situation because for prevention of reply attacks, you always need some external trusted store to store something more. Counter, last date of modification, something like that. So this combination with, for example, a trusted platform module, maybe it can be done. But if I have just only disk that provides me sector space or something like that, nobody will stop me, take the snapshots and return it back. So that's one of the problem I cannot easily solve here. Otherwise, we will see how it works. So I already mentioned there are some algorithms for checks, so you probably know secret currency codes. I just want to mention here, never use that for any cryptography. The problem is that you can very easily find another message or another data that will have the same checksum. There are a lot of examples in cryptography where someone tried to use that and it failed later. One of that example is one of the old through-crypt system and they used CRC32 for initialization vector generator and the problem was exactly that they used something used, should be used just for random data detection, not for intentional data, intentional data corruption. So that's enough. If you are a trust model, just detect the random changes, okay, that's fine. If you need something more, you need to use cryptographic hash. I mentioned here because you can calculate even for the random data corruption, you can calculate checksum using cryptographic hash. Still, attacker can recalculate that, but now you have at least the guarantee that attacker will not find another file with the same checksum. You can later sign off these checksums and you will have something, for example, what is used for ISO images signing or something like that. But this is just if you need checksums. So that's for non-authenticated integrity protection. What I need is authenticated integrity protection. What it means? It means that the checksum, and I intentionally will not use checksum again in this context, it should be authentication tag. You need some key or something that allows you to calculate or verify the checksum. So you can use hash, but you need to use something key. So usually there is HMAC algorithm hash message authentication code. You can, in combination with encryption, you can use authenticated encryption, and usually there is specific modes designed that it does both encryption and integrity protection. So calculate authentication tag, for example, as GCM. I don't like the GCM mode here, but it's implemented everywhere. So I am using it for testing. But what I would like to know, there is ongoing crypto competition named Cesar that is trying to find better algorithms for authenticated encryption. And we will probably in future use something better. But for now, I am trying to use what's its kernel. We will see that the whole solution is basically algorithm agnostic. So what's possible we can use? We are not bound to any explicit algorithm. Another abbreviation I would like to mention here is authenticated encryption with additional data. It's basically the same. Just you are authenticating something more, just only data. It's metadata usually. It can be probably, it can, there are usually public. Imagine some date of creation or in our case sector number. It's something public. But I would like to add it to authentication. So if I'm reading the sector from the wrong place, authentication should fail. So that's the additional data. So you will usually see somewhere A, E, A, D. That's authenticated encryption with additional data. That was the beginning, just interaction of the basic terms. I don't have much time to go into details about the existing solution, but just a few of them from the open source world. I am not talking about proprietary drivers, but from the open source, there is on the block level, there is very interesting DM verity. DM verity does just the integrity protection. It doesn't encrypt the data. And you are probably using it if you have Android phone or Chromebook, because it is the device map or target that provides integrity checking, cryptographical integrity checking for the block device. Basically for the system partition. The problem here is that it works not directly by checking the sectors, but you have hashes of the sectors. In the tree structure, in cryptography, it's called mercury. And the root hash is stored in firmware and side bind firmware key. So we should want to upgrade the whole partition unit, that key, just basically flash the whole device and recalculate what's in firmware. It perfectly works for system partition on Android, but if you have some data that needs to be written there, it's read-only partition. So it's a nice idea. It requires a little bit additional storage space, but it's unusable for read-write partition. For file systems, but there is doing some checksums. It doesn't do authenticated encryption. ZFS uses GSM in some mode, but with ZFS, it's problematic. It's out of the tree. And the only file system I know about that is trying to implement real authenticated encryption is currently B-Cache FS. It's file system based on the B-Cache in kernel, but it's developed outside of the tree. But it really uses the authenticated encryption based on Cha-Cha 20 and Polis 1308 Authenticator, but it's fixed there. If you are interested, just Google it. You will find some discussion about that. I am not talking here about integrity on application level, because the data integrity, for example, in database world means something slightly different. In relation to database, it would be probably meaning consistency of the references and so on. That's not what we are talking here. We are talking about storage. So the second part, I will talk about something that we already implemented. First introduction, then I will show the demo. So we have full disk encryption. We have looks. Basically, it's generic for disk encryption. And the problem there, if we want to provide integrity, is that it's so-called length-presentary encryption. The same size of the input, imagine the sector size, is on the input. So plain text is the same size as the ciphertext. If you want to add integrity, you need to add something to that. I basically cannot just create bigger sector on the device. So that's the problem. I usually, in literature, it's said without extending sector of some data. It's not solvable. So the full disk encryption provides confidentiality only. Confidentiality means that user can access the data only if it's authorized. So it can provide a key. Nobody can decrypt the data if you don't have key. But it absolutely cannot provide integrity. The only way how to detect integrity in current full disk encryption, and this applies for all operating systems like big locker for windows or service encryption if you can modify the sector directly there. Only way you can detect some violation there is that the decryption can produce garbage. Someone is tampering with the ciphertext after decryption you have garbage. How do you know it's garbage? Sometimes you can detect it. It's so-called pullman authentication. I think I mentioned in BitLocker definition by Niels Ferguson. I would say it's no authentication at all. It's just something you can in some context use. So there is no integrity protection. That's Many people just confuse that really if you try to modify something on Look's device, it will quietly decrypt that wrong ciphertext there, result will be garbage, but nobody will detect it until something bad happens on the application layer. If application will have integrity checking, okay, that's fine, but how many applications do that? So, okay, one side step I need to mention is change propagation or error propagation inside for this encryption. If you change one bit on disk, on memory and then save to disk, if you don't have encryption, only this bit changes, so you have some small corruption, but nothing else happens. But if this happened in encrypted disk and you flip one bit in sector, the damage will be at least cipher block size, so 16 bytes usually. In some, it depends on encryption mode, it can be amplified up to the sector size, so one bit can change the full sector is completely garbage. So that's error amplification inside full disk encryption, and that's why if something bad happens on encrypted disk, you are usually detecting it much more earlier than on other disk because the focus of that destruction is much, much bigger. It's the feature, it's not bug, it's intentional design, because if you are looking from the other side, if you change one bit in encrypting data, you would like to split it to whole sector, so attacker cannot detect where the change was. So it's feature, but unfortunately it has that bad problem if you are dealing with data corruption. Okay, that was, that was a slight sidestep, I know this looks. What I am doing here, what I am trying to present. First there was just pure academic idea during some PhD discussions at the faculty. Why we can try to run out the decadent encryption in disk encryption context. Nobody probably expected that I will try to do something more useful with that, so unfortunately I am engineer, I have to do something that is working, not just for some paper. So we implemented the way with MiClash, I hope sitting somewhere here, we implement it so it's usable, if it's usable in reality it depends on testing, but I will show you booting machine with the full disk encryption with authenticated, so it works, it's implemented, but it's the first stage here. So what we did, we split the problem to separate parts. First is non-cryptographic part, we need somehow provided additional space to the sector. This encryption runs with sectors, so we need additional space. So we invented or write new DM integrity module. I will explain how it works later on some high level point of view, but basically DM integrity provides only that additional space, nothing more. Then I added authenticated encryption to DM crypt, so we can now either encrypt in like preserving mode or with authenticated encryption and it needs some more logic there. I will talk about it later, but the whole talk can be about the problems, how to use correctly known or initialization vector, because it's not so easy to do that. So that's the architecture, a little bit more on DM integrity. It's new separate device mapper, by the way all patches I will show are on the kernel or Git tree in my tree in branch, the same for cribset up, it's in development branch. It's not yet in mainline kernel, but everything is public on the website. So DM integrity works that way, that it basically inspires by thrice from SCSI world, SCSI invented something like that 10 years maybe even more ago, providing separate data integrity field. So this can store up to 8 bytes and you will receive the data plus 8 bytes. It's not enough for our use, but the logic is inside kernel already. Kernel can provide kernel EO operation on bio structure can provide data plus the integrity metadata and we are just using that logic. So we are not requiring any changes in kernel, we are just emulating this way. So DM integrity basically emulates the disk with additional metadata and provides the info up to the next layer. It used by using interactive metadata sector, you will see that and what we need, we need to provide atomic updates of data and metadata. So that's what DM integrity does. What I like to mention, it works, it can work in two modes. First is, as I described, I will be showing it provides metadata for someone else, for DM crypt, but it can work also in standalone mode, it can calculate the checksum itself. We don't have yet user space for that, but it can be useful for other ways. I'm just mentioning I will not use the standalone mode here. So how it looks like, I said there are some interleaving sectors. So on the disk you have just normal sector, then you have the metadata sector where all the metadata starts and this repeats. The structure is here this way because it can allow us to resize the device in some steps but the device can be still resized. I put here a table from some paper where I calculated how many space it will take from your block device. Similarly if we are using Shah tool, we need 32 bytes, so for 512 bytes sector it's around 6% of the data needed for checksums. For 4 kilo sector it's quite better, but that's just for information, you will see the real numbers. The second part, DM crypt extension, as I said, it adds a possibility to add authenticated encryption. We are using interface to kernel cryptography API, so we can use whatever provides cryptography API there. As said here, it can provide combined modes and so on. I will better show it live, so that's just slides. Slightly more about cryptography, I will not go into detail, just I want to show that it's not so simple. So instead of encrypting data as previously, so you take data, you encrypt it and store on the disk. I create something like sector request and that sector request contains, these are the additional meta data, so sector in little end end encoding, so we are cross-platform initialization vector. So we will like to fail early on authentication if there is corruption not in the data but in the nonce or initialization vector and the output is encrypted sector and the authentication tag. Decryption is just reversed, you take the data authentication tag and authenticate additional data and it will either put the data or it will fail with authentication failed. The rest is the cryptography problems there. Just to mention, you can forget that, but that's what it's about. Then authenticating encryption some modes are very problematic if you use nonce, nonce is a number, use only one, so you never must use the nonce if you are encrypting the same data. You can do it easily in network communication, but if you are writing to the same sector area, you need to generate something more. So part of that problem we implemented random initialization vector, we can store it in the additional data, but there are more problems with that, but also it helps in other context. I mentioned here probably I will write something more about that, but it's probably not good idea to mention it in detail here. Just the real problem, the security of the whole solution is in that initialization vector here. Okay. So let's do something more interesting demo. I hope it will work. So I have two demonstrations here. First is I will boot just plain installation Fedora. It's not completely recent. I think I prepared it one month ago. But what I did, I took it just to switch the look, standard looks installation to the authenticated one and just replaced kernel with the patches and the Cripset up with the patches. So everything else is standard Fedora. I will just show you that it works and it's usable. A second one, we will play this command line. Just I will show you how to create that. I hope it's quite simple in the Cripset up context. So I will switch here, sorry for using VM there, but it's how I have to configure it for now. So here you can see just normal Fedora installation. I just switched some older kernel with the patches. So it's a basic Fedora just with added VM integrity and with patched VM Cript. So I will try to boot that. There should be some standard looks question and it should boot to some environments. So I need to remember password. And by the way, I'm using for I think six year old laptop with virtual machine. So even if I am running encryption, it takes some time. But you can see here that the speed is at least usable here. And if you don't believe me, I will just show you, okay, let's switch it to the full screen. Is it blocked? Okay, so standard block. So this should be standard block stack in device stack in Fedora. Just you can see that there is one device more here. That's the VM integrity device. And otherwise it's exactly the same like in Fedora. LVM overlux. I need to be a super user to show more. So we will, we can show device mapper table. It's quite unreadable, but if you can find the first lines are LVM, then there is Cript target is Vibe key. And you can see it's using SGCM with random initialization vector. So every right to the device will regenerate that initialization vector and store the metadata. And with new parameter here, integrity, 28 means we are using 28 bytes per sector, additional 28 bytes. Why 28 here? Because GCMOs are using 12 initialization vector, not 16, 16, but 12. And 16 bytes is reserved for the persistent nonce or initialization vector. So 12 plus 16 should be 28. And the second device is that new integrated target. So you can see integrity here, 28, that's the same number. J, it means that we have active journal. So we are providing that atomicity. And basically that's all. I can try to show you how looks device. I hope it was SDA2. So looks version 2. So that's maybe answer for what happened, but if it looks to I talk last year, we are still working on that, but I'm focusing on some other features. So I am still using that. And this is real usage of the encryption implemented there. What I would like to show here is the segment is encrypted as GCM random, integrity IID. So that's how it works. Just small note for the key slot where you have the real key. You cannot use authenticated encryption because the key for authentication is stored there. So it's using normal encryption, but later it's authenticated by key digest. So basically it's already there. So that's just short demo of booting the machine. Maybe I will, I can do something more intelligent, like open library office and open these slides. So you can see that there is no so big delay. The system is usable. I don't want to present the real performance checks because there are some problems on SSD still, but on the rotational drive we are quite good in performance and I think it's usable. Okay. So I will shut down this machine. I will show you. Ignore that. I will switch, I will switch to second demo. I have running some small development system. Actually it's my, it's my small Gen2 system where I am testing that Gen2 because it can be really small and I can avoid all system DMS with automatic activation and so on. So this system is quite recent. If you can, it should have some recent patched kernel and I will show you how to, how I created that encrypted system. So I have patched kernel, I have patched clip setup, rest is the same. So let's format some single, I will show you how the device text looks here. So I have several, several disk. I will use, for example, SDB for the looks to device. So just normal format, but we need to use looks to here and that's just normal format as if you want to format looks device, but now I want to use integrity. So this is new switch and for now we will use HMAC SHA2 to see something different and I will switch it to batch mode and to some, some quicker mode, just not waste time here with iterations in key slot. So enter some passphrase. Now it's doing benchmark for key slot, the standard looks tough and it should, it should be done. So let's try what's there. So I have looks to and we have the standard encryption more because I didn't specify another one. So let's use the default for full list, encryption XTS, but now we have HMAC as integrity. So I will activate it and show you what it's, what it's, it is already doing. So again, and let's name the device test and you can see that I have this DM integrity DM looks. So if I have, if I check the table, we have the integrity stuff, as I explained, we have DM crypt with IS XTS plane and there is the HMAC. In reality, Crypto API constructs the constructs these two together and creates authenticated mode like something like this. So we have authenticated encryption with the authenticator HMAC SHA2 with XTS mode. So internally it's using Crypto API interface. What happened here? I activated new device, but that new device, nobody formatted it, nobody calculates that integrity integrity checksums or integrity authentication tech. So every read on the device should fail because the, it authentication tech doesn't, doesn't match. And exactly that happened. There is a log from that, a log from that kernel. You can see that if you activate new device, Udev will scan it if there is some signature. Because the device is integrity checking and integrity wasn't there, nobody write it there. So integrity must fail. We can see that block ID just failed. I can repeat that very easily. It's turning block ID on that top level device. And it will, I guess that block ID apparently stops after the first error. So it doesn't continue with scanning. But that's the problem, new problem if you add in integrity checking inside block layer. So what I have to do, I should rewrite the whole device just to recalculate the integrity checksum. I should integrate it in a Cripset app, but for now I have some external tools. For now it's on my GitHub. Basically it's just DD, it's duplicate, running some more intelligently. So we will run format and the top level device. All this should be integrated. So for now it's very hacking the tools, but later all this should be in a Cripset app. So I will format it, and if I, for example, some file system, I can do block ID again. I see signature, I can see there is no more any integrity problems. So I think I have some test script that will inject data corruption just to test it works. If we can see what it does, basically it takes only some random data from the DeFiurandom and rewrite some random sectors inside the low level device to prevent reading the data from PageCache. I am just flushing the PageCache. So by running these scripts, I basically corrupt the device, know that this device is empty. There is no data there. They are doing integrity protection even for the unused sectors. Now if I run the check again, basically the check is just, integrity checks just read the device. It doesn't have any magic. There should be some failures. The same, it should be 16 sectors. I just rewrite. Just the offset is different because we are mapping it to be some offset. The kernel should comply in exactly the same. So we detected integrity failure. That's the reason why we are doing something happened with your device. And now it depends what we want to do with that. Currently I can just wipe this area. Later probably we can provide some special tool that can how to read data without checking the integrity and do some recovery. We will see how it should work. For now I have a very simple case here. It will try to read that and if there is error it will be wiped. So it works. It works this way. So that's one thing. Second is that DM integrity, standalone mode, I don't have demonstration for that because we don't have any user space for that yet. But so it will be very hard to play with DM tables. I don't want to show it here. The logic is that you can use DM integrity in standalone mode and you can basically add just some simple checksum with this target and you can use anything up to that layer. So I can imagine that it can be useful if you want to add integrity to something that is like black box. It can be some virtual machine and you can put that target below that. So you will quietly checking for any corruption there. Maybe it will work. So I will return to my slides actually just to the conclusion. So it was quite a heckery here but based on that academic idea I think we went to quite far and we have something working. We proved that authenticated encryption can be used in full disk encryption. With some device mapper help. It's quite easy to start. Once it's in kernel it's quite easy to start in. Basically instead of Anaconda creating the standard looks device it will just add one parameter and the rest is the same. Activation is exactly the same. The stacking of device that's all the handle by grip setup. The problem is of course price for the performance. We will work on that. I will provide some better testing but even now it's quite usable in some situations. If you are not doing any complicated device you will probably not notice it at all. I would like to merge it in upstream kernel but these discussions are just ongoing. We start this week so there are some changes needed yet but the logic there is based on looks too and that's the question looks to is still life and I hope in several weeks we will have some testing development released. There is a lot of other new things so we will need to discuss it but I will release some some bundle of that for testing. So for now if you want to test it you really need to patch everything and place that. The last what I would like to mention my intention was to show that we can do an integrity checking on this level. There are many situations where it's not proper place for data integrity but if you see last year's how many systems really implemented something. There is butterfs doing something but butterfs is not quite usable yet at least not for all these things and on application layer just try to modify randomly some documents if application detects that someone is playing with the data. I think there is not many such code doing integrity. So if we are doing it on the lowest level maybe it can help. Maybe not. I don't know. That depends on users on you actually. So that's all from me. Thank you for listening and we have probably some few minutes for questions. The question was if the same CRC check can be used in DM integrity as in butterfs. Yeah sure that's exactly that standalone mode. You can select whatever Cript API provides Cript API CRC32 so you can just define it that and it will do the same mechanism on allocating the sectors and calculating itself. So no more Cript setup over that DM integrity work this way. You can even use the hash actually you can even use an HMAC but that's more complicated you need to provide key. But CRC32 is exactly the situation I mentioned for standalone target. Sure you are storing more data but that's the question sorry the question was if the performance is in the IO or somewhere else. That's exactly why I don't want to present some performance graph because we surely don't know yet. We have some strange output. We have tools like brain mentions here we will analyze that but really this is the first step so it works quite well but maybe I forgot to say 10 years ago when look started we have the same performance problem in this encryption. It takes several years to stabilize it that it's today. This is completely new system so I think it will take few months at least so yeah. Question if there is some attacks like row hammer on storage. I am not sure exactly what type attacks you mean row hammer is that you are attacking different cells then you are accessing so you are playing with some bits in memory and some other bits change I am not sure how it's mapped to the storage probably inside SSD I don't know maybe maybe discuss it later but I am I don't know about such attacks probably in SSD maybe there are some but I don't know about that yeah that's the good question if it can support this card on SSD script setup or DM script supports SSD you can switch it on for that stuff it's problematic we can very easily switch it to support that but problem is that if you run the discard it will discard that checksum as well or that authentication tech and the problem is that you need to write there using direct to create it again it will work if we enable it problem is that in between application on this layer is page cache and page cache read the page so if you read one sector 512 bytes page cache will read 4 kilobytes and if you don't have calculated calculated checksum for the rest rest of the sectors it will fail the whole aisle so it's problematic currently we have disabled disabled the trim so it will not support him I can imagine if the page page is the of the same size as sector we can probably somehow enable it it's more question for me clash but maybe later sorry which calculates sorry how I created the table that with that numbers or I don't see I'm not sure if I understand the question calculation for for the page or yeah yeah yeah that day I it will fail okay the page on the Intel hit actually is for kill it's eight sectors we are calculating checksum for each sector if we are using that small sector so if you have the device and only first sector is used and have the proper checksum if I using direct you I'm I'm going around the page cache so I'm asking device just to the one sector it will decrypt it will verify authentication it it works if I'm going through page cache I have the just one sector this proper checksum and seven sector without proper authentication so the page cache will issue instead want that small operation it will issue I operation of the whole page for kilos and because there is no DMC it will see that one request it will try to decrypt it will decrypt the first part and under seven sector will fail and it can it cannot proper actually better than fail the whole IO so I cannot write there I need to skip it by direct you that's that's the limitation maybe something will be better but if we are using the page size and the sector size of the same size I think it can be solved but currently we don't support it that's that's going to be complicated and in the security context you are creating some side channel so yeah so sorry I didn't repeat that the question was and if we create some bitmap of something like that that depends yeah I will try it's a lot of local question there but I will try to repeat that the problems with this attacks here is that basically we are trying to fit some usable space so attacker can can replace the sectors and if there is file I create some destruction if not basically it means nothing and you are suggesting that instead of wiping we are replace it with backup or something like that well yes first is we are below the file level abstraction so the block device has no conceptual file it cannot know if the sector is used or not by file or whatever so I cannot play this file but I give you some example it's maybe like James bought example but how this can be used and why I want to integrity checking even for unused sectors imagine you have a laptop with encrypted disk and you are going through some airport checking something someone who can do forensic checking there and someone will replace the unused area with hidden disk the same like true keep to that so someone take the take the image place it there calls the the airport security that you have some confidential data there and say the password for that they will run forensic checking they have password and they will reveal that hidden disk with some confidential whatever imagine whatever that I I don't have any chance to checks myself that this unused area was tampered with I can do snapshot undo some diff but that's complicated but if I have if I have this this integrity checking I can just run that check command and I will fail I will see which sectors fail so there is some tampering if it's intentional or unintentional I don't know but I know this data are no data I've written there so maybe stupid example but that's something I am using to show that and you are of course right that if it's connected with backup it's of course much more simple just to take back up sectors and put it there to recover but that's integration summer okay the last question yeah a question was if for forward error correction we have some algorithms or we don't want in what I don't want to invent any crypto I don't want to invent any forward correction and we have already in kernel it's actually used with DM verity I didn't say that but the mv3 does not only verification but it has a space for forward correction classic rich Solomon codes it's in another DM verity targets I can use it there I just need to do some analysis if it's a cure and maybe if it's usable but definitely if we want to use forward error correction we will use the library or a representing kernel so okay and we are out of time thank you very much for questions and for coming okay thank you and for everybody there will be lightning talks in this room and the rooms downstairs so if you want to see the schedule it's only online app and on the website and we'll have five of them in this room so like a 10 minute short talks you can see them on the website