 Our next speaker works at RIPE on the Atlas project which tests the internet connection worldwide. But in his hobby, he has a hobby OS which is based on Minix, which many of you should know. But for his hobby OS he needed a proper, a better file system. And he wanted to have a secure file system and so this talk is about a secure file system for Minix, but probably also for Linux, but we'll get to know that. He would like to have a discussion and feedback afterwards. So please, if you see anything in his design where you think this sucks, write it down and use the microphones later to discuss it with FICO. Okay, please give a warm welcome to FICO. Hi, I'm FICO and before I start I want to say this presentation is designed also to be accessible for non-crypto experts, so afterwards give me feedback if you think, well, I got something out of it or this was, I completely failed to understand anything, let me know. For the crypto experts, so what I want to know is, well, can you immediately find some holes in it? Also, there's the issue like if you think there should be crypto features here that I missed, also please let me know. And to spice it up a bit for crypto experts, in the last part of the talk, I will give a security analysis that is completely flawed. And then in the last slide, I will tell you what I did wrong, but if you know, well, you can also run to the microphone and say, okay, this is what you did wrong before I get to it. So a bit of background, I wanted to, I have my own hobby OS and not invented here is an explicit goal there. So I want to design software, I want to implement software, I want to learn how stuff works because then later in work or in other situations, you are way more aware of all the design choices, etc. And then if you just install some open source package, compile it and make it run. So at some point, I also got to the point that I wanted to have a secure file system and the obvious way to do it is to have encrypted block device. So I started designing the crypto for such a block device and then it didn't fit. Whatever I tried, I never got the security right. I knew sort of what kind of guarantees I wanted to have and I couldn't make it work. So then in the end, I gave up and I said, well, I have to look at what other systems are doing because obviously they have encrypted block devices in use. I mean, on Windows you have TrueCrypt and Linux have Lux and then previous D has Gaely, etc. And then I found that basically none of them actually met my requirements. So at some point I said, well, I have to take a step back and not try to have it in a separate layer in a block device but maybe it should be an integral part of the file system itself. Then you can do a lot more stuff. And then I started designing what I will now present. There's another thing that I really don't like about file systems, how it's done today. I mean, I work a lot in networks. And what happens there is if you have a Linux host and a Windows host then a Mac, they can all talk to each other because people first set out and try to design some protocols, have standards for that and then everybody tries to implement the same standard. It's not always perfect but by a large it works. Whereas for a file system, everybody sits down and writes a file system for their operating system. So you have a completely unique file system. By a large it doesn't have any specifications. There's just a bit of code and if you're lucky there's a white paper and if anybody from another operating system wants to do it then either they have to run exactly the same code or they have to painfully review engineer that file system. So I want to change how we approach designing file systems by actually first writing a design and making sure that you can have a couple of independent implementations that can interoperate and only then consider it a new file system. But that's sort of... You cannot do that with an existing file system because there's already way too many file systems. So you can't say, okay, you're doing it all wrong. You need to follow my way. But there's almost no file systems that have built-in encryption. So I want to see if I can start a project that actually designs it like that instead of first focusing on a bit of code. And of course also if you want to do crypto then you need to have a good design that everybody can read and not just some code that does stuff. But that's not the topic of this talk. This is just a general thing. So then thinking about what I wanted to achieve then the obvious thing is I wanted to be secure here I define as it needs to provide secrecy. That's the obvious thing that you all want from an encrypted file system. But I also want to have integrity. If you leave a USB stick somewhere and somebody returns it to you then it would be bad if somebody could hack that USB stick some and then still take over your computer even though you thought it had a secure file system on it. Then another principle which is a bit tricky to define so I'll focus on sort of the opposite. So the opposite of robustness is that it's fragile and a good example of that is things like OpenSSL. So there you start with a TLS specification which is completely horrible in its own way and nobody understands how it works and then on top of that they also manage to make it worse to make sure that it's as bad as possible. So I don't want that. I want to have a few simple components and an explicit goal, reduce the number of components make sure that all the interactions are simple and that a component can work or well if you do it really wrong it can fail but there shouldn't be that in-between zone like well if you flip this bit there then it also becomes insecure. And then the first principle is simple and that works in two ways. One is if you look again at something like OpenSSL if that's just released then no security researchers ever going to bother to look at it. I mean the first time you start reading a bit of code of that you give up and discussed. So what you do is you wait until it got insanely popular then you look at it find an interesting bug and then you make headlines but that's not really the way to design secure systems so I want to make sure that it's simple enough that I can explain it to security experts and that they can then say oh this is really stupid you have to fix it and maybe if people don't say that for a while then you can say oh maybe it's sort of secure. Simple has another component and that is most people who are not into crypto tend to treat security software or devices as a black box so you add your magical security source and then it will all be perfectly secure and that almost never works because security devices are designed to work in a context and unless you perfectly understand what that context is you probably deploy it the wrong way and then it's still insecure which means that you have to know a bit like what is this really doing you don't have to know all the details but you have to have some fake awareness of what it does so that's also why I decided to have a simple design because then you have more chance that people are going to use it actually understand a bit what it's really doing and can evaluate whether it makes sense and then sort of to avoid starting out creating the next butter FS or something like that I want to have a really simple file system so it should be modern that you'd have all normal stuff like iNodes and attributes and stuff like that but the student immediately have every different kind of checkpoint in cloning etc thrown in that you can think of so that's why I think of it as a secure fat 32 replacement another thing that a lot of projects are not doing is they say well we do encryption and then they give a general overview of what kind of encryption they do and then they start listing all the different block ciphers and other stuff that you can use but they never explicit on what the attack model is and the problem there is that if you think there's something wrong then you never know whether you got outside the attack model or that it actually booked and also sometimes people report bugs and then people immediately say yeah but that's not part of the attack model that works also the other way around is that if you want to use it then basically you have to study the whole design of that system to sort of reconstruct what the attack model could be to see whether it actually fits your use case and there's only few people that can do it so then stuff get deployed in a context where it probably doesn't work so I want to be explicit about the attack model and I try to come up with these three classes of attack that I want to protect against so the first one, the single first read only is essentially where if you lose a USB stick so the attacker gets to see your entire file system but it's only one instant in time and from a crypto point of view that makes a lot of difference because there's a lot of attacks that you can only do if you see multiple versions so this is basically the easiest thing to do and also most current block encryption systems actually work quite well in this because for example if you only lose your USB stick then integrity doesn't become an issue because there's no way in the attack model that the attacker will try to modify any bit then the next one for a couple of years at my work on my desk there was a backup disk and then when I was at work my work laptop would just make a backup to the backup disk but the disk just stayed there on my disk which means that in theory every night either security or cleanliness or some way could make a copy of the backup disk and then start analyzing all the differences and unless you specifically design for that it's easy to come up with crypto so that is perfectly secure if you see only one version but then if you see the complete evolution of the file system then it leaks way too much and you may even be able to decrypt it so that's a separate step and then of course there's the last one and there you can for example think of online storage suppose that you have an ice-coosy thing or maybe in the future clouds will offer some sort of block storage there an attacker can also try to modify bits so there you have to be really make sure that if an attacker tries to do that that you will attack that and not allow that to happen and there's two things that I'm specifically not doing so if you have a running computer with key material in the computer there's all kinds of ways that that key material can leak so I'm not looking into that I'm only looking at how do what kind of encrypted bits get written out to a disk can you attack only based on looking at those bits and not looking at the stuff inside the computers that does the encryption and there's another part that sometimes comes up and they don't look into is plausible deniability if you're interested in that you can always talk to me afterwards to see whether or not that should be included or not so to give a bit of a crypto background for people who don't know it these are the crypto primitives that I am going to use the first one SHA-256 a hash function you give the arbitrary input it comes out with 256 bits and it has some unique properties that if you have such a sequence of bits you can never find any input that would result in the same bits unless you created that yourself if you know what goes in then of course you can know but otherwise it's not reversible so this is very good for integrity checks then in some cases I need a construct where you do the same kind of hashing but then with a key and that's the HMAC SHA-256 so you can see that as a signature scheme but it's not a traditional public key signature scheme where one party signs and the other one and everybody can verify here basically everybody who wants to sign and verify has to have the same key but anybody who doesn't have the key cannot do anything AES is essentially the standard block cipher there's basically no need to think about other block ciphers and I like block ciphers because of the additional robustness you get from a block cipher and in this case I use CBC because a block cipher can only encrypt the basic block of the block cipher which is 128 bits for AES and of course we need to encrypt an entire disk block which is a lot longer so then you need to have a way to chain those blocks and CBC is one of the methods there and then finally there's a crypto primitive called argon 2 and that's basically that if you give a system a password then all of the crypto that we have is designed to be as fast as possible which means that if somebody wants to do a brute force on your password then you're in a really bad situation because that attacker can buy some dedicated hardware and try a gazillion passwords per second and break your password so what password hashing functions like argon 2 try to do is to be slow they try to guarantee that they're slow you give them some parameters to define how slow they should be and then basically they try to make the life of the attacker that wants to speed it up as hard as possible you shouldn't be able to speed it up unless you spend a lot of money and that way you can prevent people from doing passwords guessing attacks so these are the primitives that I need and then this is sort of the core the really simple construct that I came up with and basically if you look at the file system in a really abstract sense then it's a tree-like data structure so you have stuff that points to other stuff in the typical file system you have inodes and a point to data blocks if you load large files and a point to indirect blocks but you can also have B3s and other stuff it's all stuff pointing to other stuff and typically if you do that then you include a block number and I also have a block number here and basically that says well this points to stuff or this block somewhere on disk then borrowing from ZFS if you want to do integrity checks then together with this block pointer you need to have some information about the contents that way if you try to access it then you know where it is but you also know what to expect ZFS assumed hardware errors so they typically have a CRC but I assume an attacker so I have a full SHA-256 hash value there then moving on there's another thing that you need for encryption and that's a bit of randomness and historically in crypto literature that is called an initialization factor so I just keep calling it an initialization factor though in fact it's just a bunch of random bits there's no magic and then I still have 64 bits left because I want to pad it to a nice power of two and then I use one flag to specify whether it's big onion or lithium in but that's irrelevant for this talk so that's the basic concept then using this I can define how you would no, I have them in the wrong order okay so what you now can do is you can create arbitrary linked data structures but you run into one problem is that if you have a block and you say well this is the root of my tree then you need to have a pointer again that points to the root of your tree so you get sort of an infinite recursion well not turtles all the way down but pointers all the way up that will never stop so you need to do something special to break that recursion so the other thing that you get if you use these kinds of pointers is that if you have a traditional file system then if you overwrite a block then you try to write to the same place that's in normal file systems most efficient operation because then you don't have to change any of the metadata you just write update a block and you're done but if you have those pointers that include information about the contents that means that as you write a block you always also have to update a pointer to the block and that leads to a system that is called copy on write so instead of if you update a block you write it to the original location and you will always write it to an empty space on disk and that has the convenience that if something goes wrong then you can easily roll back because you never damage anything in your file system because you always write to empty space and if you then continue with that then the logical way to deal with that is you have checkpoints so as soon as you think okay I made a bunch of modifications then you write down a new checkpoint block that essentially make those modifications official and then you can make new modifications so the name of checkpoint is coming from this concept but then security wise what a checkpoint block tries to do is it tries to have a pointer and block data in the same location so what you can see here is first part is essentially the same as a block pointer and then it's followed by the data but the way it's written out is different because instead of having just a hash function now it needs to be a signed hash function because it's no longer encrypted and checked at a higher level and then the other thing is there's a split because the other three fields in the station factor and the flags and the block number they are actually encrypted and only the signed hash is not encrypted if you do that then for checkpoints again it makes sense from file system layout point of view to have them somewhere in the middle of the disk but if they're in the middle of the disk you never know how to find them so you need to have something at the start of the disk that will actually tell them where they are so that's traditionally called a super block and the other thing you need to do is you need to do something with the password so that's here I said that argon2 has parameters that you can specify how slow it is we can assume that hardware continues to evolve so you need to be able to specify those parameters in your file system otherwise you would be stuck so that's the first two fields and then the remainder looks very much like the construct I had for the checkpoint you get a block pointer but it's split in that weird way that you have a signed hash and then the rest is encrypted and there's another thing and that is here instead of using the password directly to encrypt the disk I store a disk encryption key explicitly in the super block because that has the advantage that if I want to change my password then I only have to write out new super blocks and I can still keep the same disk encryption key or even another way would be to have multiple passwords, multiple super blocks that would all include the same disk key because then you could access the file system using multiple passwords and basically from a data structure point of view that's it, there's no more that's all the different primitives file system primitives that you need to create a full file system so next thing I'll try to describe for the three types of blocks how encryption and decryption sort of works so this is if you just have an ordinary block you start creating a block pointer where you take here the plain text hash it and you have a hash initialization factor is a random number the flags get filled in and of course you have to know where to write it in disk so that that's the position then I generate a key to encrypt it with using this HMAC construction so this key that's the secret key for the entire disk and then using this block pointer I can create a new encryption key and then I use the AESCBC with that key I need the initialization factor and the plain text to generate ciphertext decrypting is almost the other way around you assume that you have a block pointer that has the block number so you can read the ciphertext using this block pointer we can again compute that encryption key we can do the AES decrypt that gives a plain text then of course we have to hash the plain text such that we verify that the hash of the plain text is indeed the same as the hash that was stored in the block pointer to make sure that the integrity check works out so that's essentially 99% of all the disk IO operations because this is all the normal blocks that they will all go through this process then occasionally you make a checkpoint so there you again have the random data flags you know where to write the checkpoint and you have the checkpoint data so that's together the plain text you hash it but in this case because an attacker might temper with it you need to use an 8th MAC construction to protect it so that's put here then because we don't have on decode decrypt the entire block pointer we have only the sign hash we can only use the sign hash as input for the encryption key so that's here and then we just encrypted with that key we also don't have an association factor so that can be set to be 0 and then encrypted and then the decrypt is again almost up so down you create a decrypt key from the block from the sign hash decrypt it then you have this then you have to again of course compute this 8th MAC SHA2 to compare and make sure that nobody tried to temper with the checkpoint block so I mean this happens essentially every time you do a sync etc to make a new checkpoint and then you have the super block and that gets modified essentially only when you create a file system so that almost never happens so here I have these argon 2 parameters and everything I write to disk is encrypted so it all looks like random data and then to me it felt really wrong to just write a few integers as the parameters just as something that stands out like well this is this type of encrypted file system so I decided to mask it a bit but of course this is not real security so I fear an encryption key and then I crypt the parameters with that key and that basically only scrambles it to make sure that it all completely looks like random data even though if an attacker knows that this is there then the attacker can still immediately decrypt it so then argon 2 takes quite a few parameters like the number of iterations, amount of memory there's something about pluralism how long the key should be an assault and then the actual, the user's password so that is what I call the super key and then basically you encrypt with the super key but that's the same as in the checkpoint block you compute the hash function using HMAC SHA2 using a sign-in key and then you CBC encrypt it and then of course each time you boot the system you first have to decrypt the super block but like all the other constructions that's almost the same thing upside down so you have to extract these parameters by decrypting it with that salt you take the password then you construct the super key and then basically you can create the decryption key and you can create a hash, compare it and you're done so these are essentially just six operations that you would need to implement and that's it then to look a bit on whether this is actually secure I now look at the three different types of blocks and I have three different types of attacks so basically the next will be nine different versions of a block type combined with an attack type so if we start with the data block and you have a single version read only then it's safe if you analyze for an attack it's best to assume that the attacker already knows quite a bit of plain text so that's called a non-plain text attack because usually file systems contain all kinds of stuff that an attacker can just predict if you assume that then you assume that an attacker can try to brute force the AES encryption key though in practice this is obviously not possible but then the attacker could reconstruct the block pointer and then again brute force the HMAC to find the system key and all of that is basically impossible so if we look at the decrypt block procedure then an attacker would have to start here with a known plain text attack try to recover the key and then again do a brute force to recover the disk key but that's if we assume that those underlying cryptoprimitives are secure then that's completely impossible if we now look at the multiple versions then what you may have noticed is that every time you change something to a block you get a different encryption key so you get a different encryption key if the contents of the blocks are different because you have a different hash if the blocks are in different locations but they're in the same contents you get a different key because the location is different and even if it's the same block at the same location because the initialization vectors are random numbers you still get a different encryption key so that means that from an attacker's point of view you cannot tell anything you can only see that there's new random data written but you cannot correlate it in any way but this is after warning that this is only the encryption part so if you have the actual file system layout then from disk write patterns an attacker still might get information about what you're doing from the way blocks are written but the encryption itself doesn't leak anything so you can see that clearly over here the hash function gets its input the random number, the block number so every time it will be different and the attacker will see a completely new set of random bits then that's where the attacker tries to modify it so one attack here is an attacker could try to come up with encrypted plain text data that results in exactly the same hash as is stored in the block pointer and then obviously we wouldn't detect that as long as SHA-256 is considered secure that's of course not possible the other attack possibility is that the attacker can try to change the block pointer itself but that requires modifying another block in an undetected way and if you go up and up and up the tree then essentially that requires changing a checkpoint so if we assume that checkpoints are also secure then from that we can assume that all the data blocks cannot be modified so these are the attacks on a normal data block so that's showing here and basically it's this compare so an attacker has two choices either you make sure that this hash stays the same that is the second pre-image attack or you can try to update the block pointer somewhere moving on to the checkpoint we have said again assume a known plain text attack so there the attacker can try the same as the data block you brute force AS and then you brute force an HMAC which probably not possible and then there's also an option that is you try to brute force the HMAC and the AS at the same time which is again not possible but it's slightly different but you have to here be worried that if the disk key would be weak then you could brute force that key directly whereas even if the disk key is weak then these two separate steps are completely impossible so it's best to sort of concentrate on this attack because that would be the most practical attack for an attacker and that shows here you can either go for brute forcing this and then brute forcing this one in two separate steps or you can just have a guess what could this key be and then do this step and then do a check whether or not that matches your expected known plain text then multiple versions well basically there's no assumption to assume that there will even be the same so then you get a different encryption key every time that would happen and the other thing is that because checkpoints are in known locations for an attacker it's probably very easy to figure out from the disk exos pattern what checkpoint blocks are so the fact that they are written will be known but the contents is not that's not really interesting furthermore then you can try to modify a checkpoint of course that the whole integrity of a file system depends on that there again you can try to do the second pre-image attack and you can attack a sign-tash but for that you again need to brute force you need to brute force this sign-in key but in that case if you would be able to do that you could just brute force the disk key itself so basically it's an attack that would be essentially the same as breaking the encryption so we can assume that that will not happen so that's here so if you want to have the same contents then you would have to come up with new plain text such that this compare would work or otherwise you would want to brute force the disk key to make sure that you can actually generate new sign-tashes and write them to disk then the superblock is of course the most interesting one because that's protected by password and there the thing is that you cannot say anything about the quality of a password from an engineering point of view you can only tell a user should have a good password so it's safe to assume that the best way to attack the system is to just do password guessing because all the other attacks are essentially impossible and that's exactly where we should be the weakest point of an encrypted file system should be the password and not any other component so then basically you would try to brute force here the argon 2 thing and of course argon 2 is specifically designed to prevent that but you have to keep the parameters right and there could be issues that if you have a file system on an extremely slow device then you have to choose relatively weak argon 2 parameters or you have to wait a long time and then an attacker with state-of-the-art equipment has an advantage but that's all stuff that is basically unavoidable and you have to tell our users what generate a good password on a fast enough system and use that then while many versions of a superblock that basically doesn't happen we don't expect a superblock to change maybe change it to change the password or resize a file system but that's something so obvious to an attacker it's not really interesting and if the attacker wants to modify the superblock then that's the same as modifying a checkpoint and again sort of breaking the entire encryption is the best way to attack that so there's no way to just violate integrity without just completely breaking the system so that's the basic secure analysis assuming that everything gets implemented properly but then from experience we know that systems tend to end up with broken random number generators and there's a few famous ones in comics you can choose 9 if you like Dilbert or 4 for XKCD but Debian at some point managed to completely screw up but also if you have an embedded system then even if you try to do the right thing then it's still possible that you may not have enough entropy because those devices sometimes have not a lot of input so where do your random numbers come from not all of them have hardware random number generators etc so I want to do an analysis based on what happens if the random number is broken and so this is the part where if you can spot the design flaw then just go to the microphone and say well what you presented so far is insecure under the assumption that the random number generator is flawed so if we do the analysis then basically if you have a single version then you don't need a randomness so you need the randomness for a data block that if you have multiple versions then you want to make sure that you have a different encryption key every time but if you just have a single version of the file system then all of that doesn't matter so basically you don't need any randomness for that that's because all of the block contents is already input to the key so if the attacker already knows the complete contents of the block well then it doesn't really matter whether the attacker can still know something if you have multiple versions then if the random number generator is broken to the extent that it's predictable and that's one of the common attacks on random number generators then all the blocks will have different encryption keys so the system is still secure so then only if the random number generator is broken to the point that it will always return exactly the same number then you need to have blocks with identical content and they need to be on the same position on disk and then they would actually end up with exactly the same encryption key and then an attacker can see that you are writing an identical block to an identical position so it's some information that gets leaked but it's sort of the most horrible situation when it comes to your random number generator and it's just a small amount of leakage because it's not that often that you write the same contents to exactly the same place in disk that's showing here that if the block number is different then you get a different key if the hash is different so only if that's all the same and the association factor is the same then you would actually reuse a key and then of course if an attacker tries to do an integrity attack that's not affected by randomness if you look at a checkpoint then the single version doesn't matter because it's only one version that key will be unique if you have multiple versions then we expect all checkpoints to be different that's why it's a checkpoint something has changed on the file system and then you write out a checkpoint so it would be really weird if you have an identical checkpoint a theory can happen and then of course if indeed the random number generator would be constant then you would leak the fact that you would have an identical checkpoint but that's an extremely remote situation and of course again if you try to modify it that does not depend on randomness so going for the super block well, you do not need any randomness well it may be make the salt and argon 2 parameters stand out a bit basically you don't write the super block so you only would write a new version if something changed which results in a new key so there again you don't need any randomness and then oops, going too fast of course you only don't modify it so now it's like well this looks like it's secure and now I sort of cleverly well it took me a while to realize what was wrong that I skipped one part and the part that I skipped that basically completely breaks what I said so far is that part of the super block is the actual disk encryption key and I already hinted to that that if you could brute force the disk encryption key because it's somehow predictable then of course it will completely break so if we assume that you have a bad random number generator then basically you have to assume that that disk encryption key that is generated is also bad and when I realize that I realize that if I take the random number that I generate for the disk encryption key and then hash it with the super block key which is derived from the password then if it's a strong random number then it will not change anything because it will just be different bits but the same quality of bits but if the random data is really bad then it will at least be as strong as your disk password and given that already the best way to attack the disk is to attack the password so basically you get the same security so that's the end of my talk I've basically if you have any questions like to comment etc let me know so thank you so thank you Wilco I see a lot of questions lined up we have 10 minutes for Q&A so go ahead I had a simple question because you started off with saying that you wanted to have a nice design document that other people could implement but I only saw just now on the website you only published the slides and I didn't see any links for a design document on the slides so do you plan to publish this as well or where could you find this? so in sort of typical following tradition I started writing code but it's sort of on purpose that I don't have a design document because I want to have feedback on the crypto part I don't want to spend a lot of time writing it down and then people say ok this is really stupid so after Shah people sit down and start working on actually nailing it down I had some questions on the I couldn't really follow all the steps and I saw that you sometimes use an IV with non-random which is basically electronic codebook etc so I had some questions also why you use Argon and not a key derivation function etc but I will then look a bit more in detail in the slides again and I will send you some email with some commands then you can always send me an email then I can try to keep track of your email address that when I have written that down then I can send you a link ok perfect please talk into the microphone I'll lower it a bit just a simple question why are you using straight hashes for the data blocks and no hmax there because then the contents of the hashes will give an indication of the contents so that leaks information so the assumption is that for normal block pointers they will always be stored encrypted so given that there's no way that an attacker can get directly access to them it seems pointless to have extra protection so they will of course be visible inside a file system cache but in that case you probably already have all the necessary key material to load the block and just decrypt it and look at what really the contents is so it's not clear to me what kind of attack you can come up with where having an hmax would actually make a difference I couldn't come up with one so you do carving over the disk and you're looking for a specific file of which you know the hashes already or of which you know the contents and you can recreate the hashes and compare it to what's on disk but how would you so as an attacker how would you get access to those has values because you cannot well you're already you're trying to verify that a certain file is on the disk that's my attack model so if you have a file system that does deduplication then that would work very well which is basically don't have a file system that does deduplication but that's a file system function so if you see this as a simple fat32 file system then the only thing you can do is write a new file to the file system which doesn't tell you about any of the other files that are there or you can try to read the file and if there's protection then you wouldn't be able to read it so it's not for example if I get hold of a device which is encrypted with this file system and I know it's a certain architecture and for that architecture there's a library and I want to know if that version of the library is on the file system yeah but all of those block those has values are also encrypted so you can never directly read a hash value from the disk because that will be in an encrypted block not sure but we can discuss that yeah please do I was wondering with respect to the use of the cipher block chaining in combination with the possibility of hardware errors in file allocation table blocks because if you do the cipher block chaining where you have something probably an 8k block while if you would use some counter mode for those blocks you would maybe have some more recovery possibilities in case of partial failure so yeah you're right nowhere in my design I have included the possibility of recovering from errors so yeah that's not there so I think that for cbc if you have one block wrong then I think you should be able to recover most of it but I'm not sure the problem I have with counter mode is that if you for a reason end up with the same key twice then you completely leak all the data that is encrypted with that key so I try to avoid those kind of stream like cipher as much as possible but yeah for good point that maybe if you want to recover data then it would be more robust especially I think for the file allocation table blocks maybe it would be a good way to say file allocation blocks or have a duplicate or either use only counter mode for those and cbc for the rest things like having storing multiple copies that would be more up to the file system layout part because of course you can store multiple copies of blocks if you think it's really important that would not change the encryption so it's only if you assume you have one block and you assume that you have two blocks and also assume that you don't have proper backups then yes you might be right we have three more speakers so please keep it short three more questions suppose if I would be an attacker and I would have access to the disk several times at first to make a copy of the disk and then the next time I see what's changed and I know where the checkpoint blocks are and I replace the blocks that I know I probably won't like and the matching checkpoint block with the old version how would you think so there's one thing that this completely cannot defend against and that is yes if you roll back the entire contents of the file system then there's no way you can detect that you're dealing with an old version of the file system but you have to roll it back to the entire old version because otherwise at some point you will notice that something is wrong so are there multiple checkpoint blocks but one should be active at any one time but if you save a copy of the file system and then at later time restore that copy on the disk then to the user of the file system it looks like well this is a valid file system because it was a valid file system in the past and in this design there's nothing I can do about it. Please go to the discussion afterwards. Hi could I see the last slide please again the cheating one? So if I change my password now I also change my disk key which is a power digger but you cannot do that so if your first password was weak and the random number was also really weak then you're stuck with that but if you change the password then you would keep the same disk key it only protects essentially when the disk key is generated and then afterwards. Just a small question. You can lower the mic this might be easier. Thanks. A few slides back you were talking about a hash of the plain text. Am I correct? This is the hash of the plain text the SHA256 hash? Yeah, that's normally hash which do you... Was it a checkpoint or a data block? I think it was some kind of your C replacement hash. Well I can go to any data block. So here let's see let's see The block itself said SHA256 hash But there should be that one you may, here on the right. I'm not seeing the hash here either. I think that... Let's use this one. So this one, the SHA256 hash of the plain text is stored exactly in front of the block? No, no, no if it's stored in front of the block then you would be talking about the checkpoint block and in that case what is stored here is a signed hash so that's an HMAC. I'm not talking about that one. That was a hash, I'm pretty sure it was about the hash of the plain text and the thing was that that hash was never sold in any way. We should take this offline I guess. Sorry we have for one minute last. Thank you. Can I have applause again for...