 Hello and welcome to the R3s stage on the RC3 on day 2 of a great online conference and hopefully the last one. So today we are going to hear a talk about military great AS 1024 bit encryption from Sylvain and Boy. But before we go there, I want to share with you some information. First of all, this talk will be in English and it will be translated to German. This talk will be in English, but it will also be translated to German. You can find the corresponding configuration in your web player or in the software of your choice that you use to watch this stream. Then we have again a lightning round tonight. There will be a lightning round of talks five minutes each. And we still are looking for submissions for that. Please refer to the to the blog post to the relevant blog post. And if you submit, please, please, please include your event phone number so that we can reach you and we can get in contact with you. Furthermore, there is the Harold News show where we are looking for submissions to keep people up to date for what's happening. And for that, of course, we need to know what is happening. So if you want to share something with us, please feel free to share it at c3news.show. And of course, there will be a Q&A afterwards on and you can submit questions on various platforms, either being a hack in on in the channel R3S or on the Mastodons and Twitters of this world with the hashtag R3S or RC3R3S and so on and so forth. I'm sure you will find a way to contact us. Last but not least, I have to unlock my phone. Last but not least about the speakers. Sylvain does crypto for a living who wouldn't like to do that. And he also likes to spend his time doing crypto, hardware attacks and security research in general. And also somehow he likes playing CTFs that doesn't fit the profile at all. And then there is Boy who is also a security researcher in his own right and does this also as a job. And of course, he likes cryptography, hacking and salsa dancing, what else? So and with that, give it up for Sylvain and Boy. Hello. Thank you for joining us to our presentation. So I'm Sylvain. I will present you what brings me to Brutforce AES 1024 military grade encryption and what does it mean? And then Boy will explain how he patched some problems that I discovered during my research. So this project started during a forensic project. One of my colleagues received a USB key containing a vault encrypted with SanDisk Secure Access software. He asked me if it's possible to Brutforce the password of the vault. So I started my research with that. Finally, meanwhile, he found the password elsewhere, basically written on a post-it. So it could have been end of the story. But while I was researching about this software, I discovered that it is distributed by default on any SanDisk storage product you buy as a simple binary. So you executed once you configure your vault. And then when you launch the vault, the software, it will ask you your password. You enter it and if it is correct, it lets you access to your file. You can import file, export them, display them. So nothing really new as a vault solution. But I figured out that in the preferences, you can choose the encryption method. So by default, it is set to AS128 bit. But if you buy the premium version, you can go up to AS1024 bit. So I was a bit surprised and it started to interest me because as you may know, AS is not standardized for key larger than 256 bits. So I was interested to know how AS1024 was implemented in this solution. So I dig a bit deeper and I figured out that this solution is developed by a company called ENC Security. And on their website, they have really strong security claims. They say that they use ultimate encryption using 1,024 bit AS keys military grade. So then I was even more interested to dig deeper to see how this solution works. And especially because each time I see military grade, I always think about this tweet by CryptoDictionary. And it always tells me, okay, now you have to look inside the solution to discover how it is implemented. Joke apart, this is an interesting software to analyze. As I said, it's developed by ENC Security and it is a general solution. It seems it is used by Lexar, Sony and Western Digital by default in various storage products. And even though it seems to be widely distributed, it was not yet supported by Ashcat, nor John the Ripper for password brute force. So from a forensic point of view, it was interesting for us to have a solution to brute force this kind of vault if in the future we receive again this vault. And also of course, I wanted to know if I'm able to brute force AS 1,024. So I started my reverse. It turns out that the solution is a P32 bits binary of about 10 megabytes. It is packed with UPEX. So I was able to unpack it with P Explorer. It runs perfectly. There are no further debug protection. So I could debug it, put breakpoint and so on. It is written in C++, compiled with Visual Studio. So it was a bit painful to reverse C++. But I use Ghidra and tools in Ghidra to have it decompiled properly. And I use as well Radar too for some further disassembly. And the solution is QT for graphic user interface and open SSL for the cryptographic implementation. The first difficulty I got was when you execute the binary at another place than the storage. You have an error message saying that this application runs only on the storage of the brand. For example, here it is the Sony solution. So for Sandisk it was okay. I got a USB key. But for Sony, I had no SSD. So I started searching this string in the binary. I figured out that it was just after a branch. So I blindly patched this branch, this instruction, GNE to GE, like cracking in the 90s. And then the binary executed it properly without any further checks. So I was able to debug it from any place I wanted. So it was quite convenient and it remind me good memory about cracking. Then another feature I use massively for this project was Ghidra Function ID. So since I knew that open SSL and QT were used in this solution, I created signature from the compiled version of the library for the same architecture. And then it could detect the signature in my binary. So as soon as it is detected in Ghidra, it add the comment just before the function. And it helps you a lot for reversing. I could avoid function related to the GUI and I could dig a bit deeper in the crypto function. So that was really convenient and it really helped me to be faster for the reverse. Then I started to see how the binary behave. So I run process monitor and I enter a wrong password. And I figure out that only one file in the preference folder is open during the process. It is file system.dat. And then the file is read. And if the password is wrong, it is closed and then a sound is played. So I knew that my password is compared to something in this file. If we step back a bit here and we go to the general problem, we are trying to reverse a password hashing algorithm. So basically we want to derive a key from a user password. And then we will use this key to encrypt data. Usually when we do that, we use a unique and random salt to avoid an attacker to do dictionary or rainbow table attack. We have a parameter which is called the iteration number, which helps us to adapt the work factor. So to slow down as the brute force. And today the recommended algorithm are pbkdf2, which stands for password-based key derivation function 2. We have balloon hashing, which is recommended by NIST password guidelines. We have script and more recently we got argon2, which is the winner of the password hashing competition. So if you are interested by this topic of password hashing, I would strongly suggest you to go and check the literature about password hashing competition. It's really, really interesting. For this project, I was interested by pbkdf2. So the construction is quite simple. We input the salt concatenated with the constant one to a hash mark function. And the user password is used as a key for this function. We iterate c times this hash mark function. So here c is the iteration number. We saw all the intermediate results. And at the end we obtain the key. The first problem here is that, okay, but what if we want a key larger than the hash mark output? For example, what is it possible to have a 1024-bit key if we have only 16 bytes of output from the hash mark? And in fact, this was the first problem of pbkdf1, the first version of this algorithm. And this was solved in pbkdf2 by just considering that the key output here is the first key. And then we run this algorithm a second time with the constant two, which is concatenated with the salt, and we obtain a second key. And we can repeat this process again and again. And at the end, when we have generated any key byte, we concatenate all of them and we obtain the final key. For example, if we want a 1024-bit key and we have only 16 bytes of output, we do 8 iterations of the process and we obtain the final key. So this is fine here. But what is inside the binary? I reversed it. And in fact, I discovered that the number of iterations is hardcoded. And then we have a loop with hash function inside it. So I reversed this main loop and I figured out that the construction for the key derivation function is really close to pbkdf2, except that the hash function, I mean, the function used is not a hash mark, but MD5, a hash function. And the password is hashed a first time and then input it to MD5 again and again, 1,000 times. And the key is outputted the same way. Another difference is that the salt and the constant are hashed a first time by MD5 and sort to the result. So it was close to pbkdf2, but with some differences. The first thing I struggled was, okay, I could figure out the algorithm, but I couldn't find out from where the salt came from. But I found a string which was hardcoded in the code, which looks random, but it is always the same because it is in the code. And it turns out that this string is a salt of my key derivation function. So it was random, but obviously it was not a unique per user. And yeah, it's really not a good practice. I mean, it brings some possible attack because you can have dictionary or rainbow table attack for a user. And in fact, I checked for other version for other vendors, and it turns out that the same value is used for all the vendors. So your dictionary attack can work for a sunny user and a salt user exactly the same way, which was the first vulnerability I discovered here in this solution. Another less important problem is the iteration number. For 1000 iteration was a recommended number of iteration when pbkdf2 was out. But now, for example, OWASP recommend 310,000 iteration or more for pbkdf2 using HMAC 200256. So this number of iteration should be higher or should be updateable for this solution. But there is another bigger problem here, and it's really a construction problem. If you look in the blue part of, I put it here on this algorithm, you can see that it does not depend of the salt and the constant. So we can pre-compute this part, this 1000 times MD5, and then we can reuse this pre-computed value to compute the second key. And the work factor really disappear because we have to compute just one time the iterations and reuse them for all the key we have generated. So it's really a design problem. And here we can see that between 128-bit key compared to 1024-bit key, it's simply a sore operation. And in addition, we can reuse this pre-computation to have a dictionary attack, a pre-computed attack. For even if the salt is randomly generated and unique per user because we can pre-compute our dictionary and just store this value to the hash of the salt and the constant. So we can see here that even if it's close to pbkdf2, it doesn't reach the same level of security and there is a design problem here. So that was the key derivation function. Now, let's see how the key verification works. So to verify that the password of a user is correct, after we have generated keys, we will read the file system.dat, as I explained before, and we will decrypt the value store in this file. And if a word is a clear text, word equals d2c3b4a1, then the software considers the password to be correct. The first thing I needed to know is, okay, but what is the encryption algorithm used to decrypt file system.dat? And this part of the code was not identified by Gidra function ID. And it was using a lot of SSC instruction, which was really hard to reverse. And even the decompilation was not helping much, but I knew that it uses OpenSSL. So I started to search in the source code of OpenSSL, and I found a Perl script which generates SSC instruction to implement AS, exactly in the same order as the instruction I got in my disassembly. So then I could figure out that AS was used for the decryption. And in fact, it turns out it was AS in counter mode. So for AS128, it was AS in counter mode, which was simple. So then I thought, okay, for AS256, it must be AS256 block in CTR mode. But in fact, it was not. It was two iterations of AS128, but the nonce was XOR with the second key generated by the key derivation function. And then the key stream is XOR again with the ciphertext to obtain the plaintext. So then it was not difficult to figure out how AS512 and AS1024 worked. It was simply the same, but with four iterations for AS512 and eight iterations for AS1024 and always with the keys generated by the key derivation function XOR with the nonce. And we can remark here that only the first eight bytes of the key were XOR with the nonce. The counter was left untouched before the encryption. So here the difference between AS128 and AS1024 modes was only the number of AS encryption. And in addition, only half of the generated key bits were used because even though we generated 1024 bits, only half of them were XOR with the nonce. Anyway, at the end, the level of security cannot be higher than the level of security of the user password. If it has a low entropy, then the security cannot be higher than this entropy. Nevertheless, the nonce were randomly generated with open SSL with runbyte function. So it was really fine with those nonce. So at this state of the project, I got everything I needed to implement a brute force in John's Reaper. So I created a Python script to extract the encrypted data, the nonces, and everything I needed to brute force the vault. I figured out that you can have false positives after about two to 32 candidates because you are testing your password against just a 32-bit world. However, for Sandisk and Sony, you have the version right after this magic run. So it helps you to sort the false positives. So my implementation is available on my GitHub and it will be soon integrated in the main John's Reaper repository. So now everybody is able to brute force AS-1024 and I encourage you to test my implementation and tell me what you think. So now let's see how it works in practice. So if you execute John on the hash you obtained with my script, it will brute force the password. Here it found the password because it was in my password list. It found it after two seconds of execution and John's Reaper was able to test about 7,000 passwords per second. If we compare this to PBKDF2 using 310,000 iteration, we can see that John will figure out the password used because I use exactly the same list. But it will find it after two minutes, which is quite longer. And John is able to test only 30 passwords per second, which is really, really slower. And it shows how the algorithm and the number of iteration influenced the result here. So that was it for the key derivation function and password tracking. The only thing missing for the reverse was how the file encryption worked. And in fact, after the password is verified, there is a file containing all the file encryption key, which is decrypted with the generated keys. And then those key are used to encrypt the files individually. So this is a standard solution and quite good because if the user changed his password, you don't have to re-encrypt all the vault, which is really slow. But just this file and the file encryption keys will stay untouched and will stay the same. And one thing missing was, okay, but what is the file encryption algorithm? So at the beginning I thought it is the same as the one used to verify the user password. And for AS128 mode, it is indeed exactly the same. It is AS128 in CTR mode. But then when I executed my script to test for AS256 mode, I was surprised that it was not working properly. So I reversed a bit the file encryption more. And I could find that, in fact, there was a small modification. The second key, the second file encryption key is now fully XORed with the nonce and the counter. The 16 bytes of this key is XORed before the encryption. And then it is used to generate a second key stream and XOR with the first output to obtain the plaintext. So I corrected my script. But then again for AS512, it was not working the same way as for the key verification. So I reversed again. And I figured out that for AS512, only two iterations of AS128 were used. But only with the last file encryption key. So I was a bit surprised because it was really interesting to me. And it was the same for AS1024, except that we used the last eight file encryption key. So now I got everything I needed for the file encryption. I could reverse the five format. So in the encrypted file, we have first the IV in clear, the nonce. Then we have a version number. We have a parameter telling which algorithm we are using. Here four stands for AS1024. And then we have the file name length in clear. Then encrypted with the algorithm I described before, we have the file name. We have zeros. And at offset 0x200, we have the plaintext in clear. The second problem I discovered here was that it is a CTR like design. Even if there is several iteration, it is almost the same as a CTR mode of operation. And you can have file malleability. Meaning that if someone is able to modify your file, then it will be decrypted exactly with the same modification. And it won't be detected by this solution. So that was a problem. If, for example, you store your vault in the cloud or if someone has access to your vault. Again, nonces were randomly generated with open SSL. So there are no problem, not the problem of nonce reuse. It was perfectly fine. But since there is only two iterations of AS, we got only a maximum of 256 bits of security level. And in fact, if we go a bit deeper. So what if we got only the encrypted file, we can, I mean, theoretically brute force 128 bits for the first file encryption key. And then we have to brute force the last file encryption key, which is so with the IV, because we don't know it. So we have indeed a security level up to 256 bits. But if we do a bit of cryptography here, and we assume that we have a two plain text block equal to zero, and we have the corresponding ciphertext C1 and C2. Then we can write the equations for the encryption. And we know that C1 equals AS used with the first file encryption key of the first IV, so with AS of the first IV, so with the last file encryption key. And here the plain text is not in the equation because we have make the hypothesis it is zero. And we can write the same for the second ciphertext. Then if we rearrange the equation and we sort them together, we obtain this last equation, which depends only on the first file encryption key and not on the last encryption key, because it can sell out. And meaning that we can test this left part of the equation with the first for all the possible file encryption key and test if it equals to IV1, so with IV2, which are known because they are unclear in the file. And as soon as this equation is satisfied, we know that we have guessed the correct key. So it gives theoretical reduction of 128 bits of security. This is theoretical. It assumes that we got a zero block in our file encrypted. But in fact, if you remember well, it turns out that we know from where the file name end encrypted. And then we know that we have zero until 0x200 offset. So we can use this information to have zero block. And in fact, we can, I mean this reduction, the security reduction apply for this solution. So as soon as I got my result, I contacted and security in May this year. So they acknowledge of the vulnerabilities, so the key derivation function problem and the file malleability problem. Then the vulnerabilities were disclosed to Sony, Western Digital and Lexar. I got a meeting with ENC security to agree on the deadline and also to handle the disclosure to the vendors. Then I received two CV, one for the key derivation function and one for the file malleability. And then in September, it turned out that this key derivation function is used in other Western Digital applications. So we extended the deadline to the 22nd of December. So that was all the finding I found for this solution. And now I will let Boy present his part. Yes. Thank you. So I'm now going to hold this presentation from the view of ENC security. So I'm going to tell our side of the story. The interesting events that happened, the challenges that we faced, choices that we made. And I guess for this audience always interesting how we actually came to the designs that we made for fixing those issues. A slight bit of background here. So the company actually was founded in 2009. And we have millions of people using the software. And part of that is because we have OEM versions. So what happened is that we managed to sell the product on USB devices, USB storage devices. So for example, that would be some disk, which is still our biggest customer. And they're actually nowadays part of Western Digital. Sony was also a customer of ours. And they sold it with an SSD that they sold. And Lexar also sold USB sticks with our product. And in this whole filmability disclosure process, only Western Digital and Sony actually replied to our contacts, our time set contact. And Lexar never really answered to us. But I have to remind you that both Sony and Lexar are actually not customers of us anymore. So the timeline from our point of view, I'm now going to shift the perspective a bit to my point of view, because I actually got involved with the ENC only in March and April of 2001. And that was because the company wanted to have an internal security assessment. So I did a small security assessment. I did not all the fancy stuff that Silvan did with Gidra and decompiling and debugging, etc. What I did was basically some simple tests that I could do, including looking at files with hex editors and modifying them. And actually I found some similar things. I also asked just questions to the team. So how do you do the key derivation? Well, we use MD5 with a thousand rounds for PBKDF2. Okay, so one of my findings is obviously that's not enough. So I gave them my report in April and then my assignment was done. I'm a private contractor. So, you know, I was just hired for a small assignment. And then Silvan disclosed his findings. ENC did acknowledge the vulnerability, but didn't do much more with it at that time. Not yet. And then Silvan disclosed his vulnerabilities to our business-to-business or OEM customers. So they started asking questions. Yeah, and then ENC started to investigate the issues. We then spent from June to November upscaling our team, doing discussions internally with our customers, doing a new design implementation and testing. And as you can imagine, because I had been involved a few months before on the cryptographic assessment, I was also asked to help the company out with this. So that's what I did. And in the end, we actually managed to publish a new version, which fixes the KDF issue. And what we still have on the roadmap is addressing the cyber-taxability ability and the cyber strength issues. So one of the first things that happened and what I was contacted, you know, then my manager said, okay, so we've got this vulnerability report from a guy who I don't know and is this real? Is this anything at all? And he was afraid it was because, you know, some of the same vulnerabilities were actually confirmed in his report. But yeah, so I just Googled Sylvan. I was like, okay, looks legit. He has done some stuff. The report was actually very well written. And honestly, if this would have been a paid assignment, the report would have been paid for. So that's really good work. Well, maybe even a bit too much for something that's basically for free. The report is also specific to our product. So it's not some random report which says you have vulnerabilities just in hopes to get a CVE mention or to get a bug bounty. We don't have a bug bounty program, but you know, these sort of things happen at times. I also noticed that the terminology and the evidence presented really indicated that the author knows cryptography. So yeah, it was real. Sorry guys, we really have to do something about it, which was already planned, but not at the speed that we now had to do stuff. Yeah, and that sounds easy, right? Because just choosing a new KDF, new key derivation function, it's not rocket science. This problem has been solved before, basically. And also the malleability issue. Oh, you just authenticated encryption and it's fixed. But anything is easy if you don't have to do it yourself, really. So let's take a look at what happened. Well, someone set us up the bomb and it was so fun. So the company at the time was at the product was in maintenance mode, which meant that we didn't have that many resources to work with. So we first had to get more people to upscale our team. We also had to figure out, okay, so what are we going to do? How are we going to fix it? How bad are these issues and can we prioritize stuff? We had to make a design and we also had to work more closely with our OEM customers than we did before. Like I said, Western Digital was still an active customer of ours, but this thing required more attention from them. And certainly they also wanted to look at the proposed resolutions that we wanted to implement. They wanted to make sure that it was actually fixed. So we had to work more closely with them than before and everything had to be done fast. Okay, that's all very nice. But yeah, so upscaling, we need more people. We need more hands. Where are we going to get them from? Because there is so much demand for tech skills and also crypto skills. It's really hard to find. This thing also happened during summer holidays and many people are just not reachable at the time or don't react as quickly. And in fact, myself, I also went on holiday and it was planned, it was booked. We were going on holiday. And we had to do everything in short notice. So we did get some extra people, but most of them were part-time. And that really doesn't help if you want to fix things quickly. The next thing that we did was obviously the triage part. So we looked at the key derivation function and what the actual risk to the users is. And obviously that depends a bit on the use cases, with defining some sort of about the key derivation function. That was pretty clear. It is a big risk for users. So we really wanted to get that fixed first. And we also expected that it's only a limited effort to do so. Then the other issue that was found, the malleability issue that was initially reported. Well, that may not be so easy to actually abuse. There is of course the theoretical approach, which is actually not a malleability issue. But yeah, so you can modify files certainly, but it's hard to do a specific targeted change in the files. I'm going to actually explain a bit more about this in a later slide. So let's keep it at that. And we also expect this to take much more effort. So what we decided on was a staged approach. First we wanted to fix the key derivation function, and then we wanted to fix the rest. So we had to choose a new key derivation function. And there were a few considerations that were important for us. Of course, there was compatibility because we have an existing product and we want users to be able to still open those folds because if they can't open the folds, we have a problem with our help desk. Also, they may never want to buy the product again. Performance is an issue. I mean, sure, people want security, but they also want performance. And many of these users, they are not perhaps the most technically skilled people. So for them, usually performance is more important. Then obviously there's also security because different KDFs have different security properties. And then there was implementation time and effort for us to actually implement that stuff. So those were the main considerations. Now, fireworks. Yeah, so the different options that we considered were argon 2, balloon hashing, script, PBKDF 2, and then there was the question, how many iterations are we going to do? So the first three options here, they have an interesting property in the sense that they are memory hardened. They take a lot of memory to compute and that helps against attacks using GPUs or dedicated cracking devices with A6 or FPGAs. And PBKDF 2, even with HMAC SHA256, that can be parallelized much better than the other three algorithms. However, looking from an implementation point of view, PBKDF 2 was a lot easier for us because we use open as cell. And that's already included. And the other options are not. And you can try to build it from the components that open as cell gives you, but it takes more time. You actually have to verify it because one of the things that we really went wrong in the software is that someone tried to implement PBKDF 2 in its own implementation, but it's actually something that looks like PBKDF 2 but is not. So we wanted to avoid that. And then there was also some discussion internally about the more proven solutions because PBKDF 2 has been around for quite some time, but the others are much newer. And then there is the question, how many iterations? Because our products actually run on older platforms, but also newer platforms, but also mobile platforms. So we were afraid that if we would do too many iterations, then we would actually have people, they would have to wait so long for opening their fold that they would not like it or they would call the help desk and things like that. So yeah, therefore, we actually decided to, in the end, to use PBKDF 2 but only with 100,000 iterations and not a factor 3 more as recommended by OWASP. So then we actually faced some challenges implementing this stuff. We had limited team capacity. And on top of that, we actually, the team was formed pretty quickly, but we still had to get to know each other and some of us had to get to know the environment. And many of us were part-time. So we also had to know, like, okay, so when are people available or when not, we had to get into a common rhythm that actually works. So the ENC team was, like I said, was mostly part-time members, but we also worked closely with the testing team and the testing digital. And those people are actually in India. So we had different time zones. We also had to discuss some of the things with people from the United States. So more time zone stuff. Then we had holidays and festivities. As before, we started out during the summer. So there were summer holidays. And even in COVID times, there were still options to go on holiday even though the options were limited, but they were there. And then there were some more festivities. For example, in India, there is a festival called Diwali, and that's a really important festival there. I guess it's a lot of fun. But people took a whole week off because that's what they do over there. And then a few weeks later, there was Thanksgiving in the U.S., which also meant that people were less available. Then we got people getting sick. Two people from our team got COVID. And actually it was really offline for like two full weeks straight. And then had to recover a bit. The other one had less trouble with it, but still we also needed time to prepare statements for public release, web pages and everything, things that take sometimes more time than you'd expect them to. We had to fight scope creep because there are more bugs in our software. Probably doesn't surprise you, but it's software, so it has bugs. And if you find them, the first thing you want to do is fix it. But if you're on a tight deadline, sometimes you have to enter the discussion like do we really have to fix this now or can we fix this later? Then we also ran into some issues where Apple decided to make some updates to macOS, which actually broke our code. So that's all very nice, that we were going to build a new release, but we also had to fix this because otherwise users would not be able to actually use it. Whereas in digital, users mobile applications and the Play Store came out with new requirements. We had to use SDK 30. That didn't really work nicely on the first try. We also had limited testing capability. I'll show a bit more about that later. But part of the issue was that we couldn't test we as E&C security, could not test the mobile apps because we didn't have the code, we didn't have an environment to test it on because those were actually developed by Western Digital. At the same time, we provided an API which was actually used by them. So if there are issues in the API library, then, you know, we had to use the API library. Then, you know, we have to look at it, but if it's the application, they have to look at it. And also our API works both on Android and on iOS, and the underlying file system access calls, those are slightly different. So our API was sandwiched between an application layer and a file system layer. So that doesn't always make things easier to debug. Yeah, and we had many, many different operating system and product combinations to test. So I'm going to try and show that a bit. So the product is called Datafold, and there is Datafold version 6. There's a new iteration called Datafold version 7. That's a slightly different code based mostly different user interface. But Datafold 6 is also the basis for Datafold light, which is the Sony version, Secure Access, which is the old Western Digital version, and Private Access, which is the new Western Digital version. And it's also the basis for the Vault API. And this Vault API is used for three different mobile applications. So if you look at upgrade paths, and these are only upgrade paths for desktop versions because the software runs on Windows and on Mac, and it has to run on different versions of Windows and different versions of macOS, right? We want the older versions of the software to be upgradeable to newer and intermediate versions, and we also want all products to be able to upgrade to our paid version because that's a source of income. So that's a lot of different upgrade paths to test, and it's not just an upgrade from software to software to software, but also from the file format to a file format that may be different. Then we also had some limitations on actually using the software because we actually have limitations in those free versions on what kind of devices they can run. The full version can run on your hard disk or any USB stick. It doesn't matter. But the old version of your access, the old version from Western Digital or Sandisk only runs on Sandisk USB sticks. Then there's Private Access which runs on Sandisk USB sticks, but also something called the iExpand Charger app. This is a device that can actually wirelessly charge your phone and perform a backup at the same time. There's an app for on your phone to actually do this to do the backup, and it's called the iExpand Charger app. Obviously this thing only works if you got one of those iExpand chargers. Similarly, on the Sony side, Datafold Lite only runs when you connect it to a Sony SSD. That's all very nice. This one I could easily buy. This one, my manager gave me one, and this one I couldn't buy anymore, the Sony device. But I was hacking it like the 20s. I also used to do hacking in the 90s or maybe even in the 80s with old computer games on my MSX. But the thing is that while of course I could patch binaries to run on any device, there's actually the situation that we want to test because for us the limitation is a functional requirement. We also can just make debug builds that run on any device. There's a simple option for that in the build script. So what I did is I bought myself an Oris Pi Zero and I ran Armbion on it and I just installed I made a script that can load the G mouse storage kernel module and presented it with a fake vendor and product ID and that way I can have an I expand drive or an I expand charger or a Sony SSD. It looks like this. All right, so as before we had some challenges to face and while you might think that fixing the key derivation function is easy it turns out it is not always so easy. So we could not meet the deadline and fortunately Silvan was allowing us to extend the deadline because he didn't want to increase the risk for users because what would be the point. So finally the new version went live on 2 December and that's the part of the key derivation function and then we had another thing to fix which is the cyber text reliability. So what we use is AES in counter mode and like Silvan said we actually do if we have more than AES 128 we do multiple rounds of the counter mode but effectively that is basically the same as if you know anything about counter mode you make a key stream which you XOR on top of your plain text which basically means that you make a more complicated key stream which is just two layers but effectively it's the same thing. So what's the issue here with cyber text reliability? So if this is the plain text sorry if this is the plain text this thing above here is the word test all lowercase and then you have a key stream and you XOR that on top of it you get this cyber text. Now what you see is because it's XOR if it's just two zeros it becomes zero if there's one of the two bits is one then it becomes a one and if both bits are one it becomes a zero again. Okay but what if I know something about the data in something about the plain text and I want to change it for example I know this is test if I want to make this lowercase t a capital T I can do that by changing this bit trying to select it but it doesn't work in presentation mode sorry if I change this bit to zero then it becomes a capital T and I can do that by changing this bit to one because I just have to flip the bit in cyber text and it flips the bit in plain text now that's fine for some applications but you can do even worse if you for example have an executable stored in this file and an attacker knows what executable it is so the attacker knows exactly bit by bit what is in the file they can just replace that file by something else of the same size or smaller because you can just chop off the end you can't make it bigger because you don't have the key stream but in that case you could replace an executable by piece of malware so it's not always easy to abuse this but if you can the result is double plus on good let's say so the proven solution to this is just use some sort of a message authentication code and there are several options to do this you can use a cypher mode that is authenticated like a counter mode with gmac or you can use hmac there are other constructs as well but yeah that sounds nice because it solves your problem completely because now it's authenticated if someone screws around with any of the bits in here the mac will not match and you will have detected that someone changed it however there are two ways of using a vault we have copy in copy out mode which is what you saw in some of the screenshots from Solven and that's where you copy a file into the vault or copy a file out of the vault and you can do it with drag or drop where you can use buttons and with that mode you always read or write the entire file and then there is a mounting which makes the vault available as part of your file system either on a drive letter or as a folder in your I think your favorites this feature is only available on the full paid product only but that introduces some interesting side effects in this context because suppose you have a file it contains all of your ciphertext because it's the encrypted file and there is a mac summer storage we would probably store it in the header in this case now suppose you open the file then you first have to do a full verification of that file if that's a long file that's going to take some time if you change something in the file doesn't matter if it's small or large you have to recalculate the mac for the entire file for each write now suppose you would open you would open a bunch of movie files so you have like 256 gigabytes of movies in 4k and in those movie files is usually included an icon so that you can just display the thumbnail which is all well and good but now if you open that fold and your viewer wants to show that icon it will open that file but that file will have to be checked out completely from A to Z that's an expensive operation so opening that fold in your explorer window might take like minutes that will be annoying and if you would have some sort of application that changes only a few bytes in your file you would have to spend a lot of time recalculating that mac every single change so from a performance point of view it's not desirable an obvious solution would be to like turn a file into blocks and then perform a mac on each block and then it's more manageable because if you only need to read the first block then you only need to check this out you also need to check all the other macs to make sure that the entire file is correct because otherwise people might change something around here you don't know that the entire file is being messed with this setup actually gives you lower and much more predictable latency which is good but it will give you additional performance overhead for full reason right because now you need to do this mac calculation for every block and you also need to either maintain a mercury or you need to combine all those macs and check them out it will give you more on this overhead because now you've got more macs stored that's usually in the order of like 12.5% to like a few percent depending on the block size that you choose it gives you a lot more complexity more error cases, more corner cases so it's much more complicated and it doesn't really fit into our current design so it will be a lot of work so yeah what else are there alternatives and yes there are what you could do is use an encryption mode and that could be for example cbc mode or XDS XDS is a good example because it's really hard to mess with things I mean you can certainly break some part of the file that's really easy if you can have write access but then again you can just destroy the entire file if you can write you're doomed cbc mode has more options, more opportunity because you can flip individual bits and then you get a penalty I believe the next block will be completely garbled so it has more limitations than counter mode but there are still some options you can also use large block ciphers or nothing transforms these things actually also help against people detecting where you changed things in the file that's also good those are mitigations they're not a full solution because it's still not authenticated encryption but it's a mitigation it really reduces the risk and we can actually combine this with authenticated encryption of headers because the headers are obviously the most important metadata that you have they're small so this is quite doable to actually perform authenticated encryption on and that's actually the intent to do fix the reliability issue we intend to implement XGS with authentication of headers yeah so one last thing when I started out on my initial assignment for E&C I think I had the same reaction to AES 1024 as Sylvain did what this thing does not exist and I had some discussion with this about this with the people from E&C who have been around for a bit longer and it turns out that the product has been sold to many different countries and some of them are not part of the Wassenaar agreement so there were export restrictions against them and fortunately it's not restricted to 40 or 48 bit export restrictions that's something from the 90s but they can only use AES 128 sure not like people can't just use open source software but whatever I don't consider that highly effective but that was a regulation and if you're a company you can get fine for breaking it so but marketing really wants to offer something stronger because people feel like okay there's 128 yeah but can we make it stronger in military grade and actually people outside the crypto industry I think they have a more positive view on military grade encryption than us so what was decided okay let's do multiple rounds of AES 128 and then call it 256, 512,024 because people understand bigger numbers you can't say yeah we do 8 rounds and then of course what I'm not saying here but this was not on the sheet but apparently we do not do 8 rounds except for only the initial key wrapping of the file encryption key so that's certainly an issue but that's yeah so I wanted to explain why on earth this decision was ever made because anyone who knows their stuff on cryptography they look at AES 1024 and they say okay these people don't know what they're thinking about and it's marketing yeah so I'm giving the floor back to Sylvain yep thank you so as we've seen during the presentation and to sum up yeah the level of security is really difficult to assess for a full solution it depends many things the algorithm used the work factors, number of iteration from your algorithm and at the end of course the size of the keys used so this project was really nice in terms of collaboration with ENC security to me and they handle the problems in a I mean in the way they could and they always I mean I had a lot of meetings with them and we collaborate a lot on this and the findings I got which is not always the case and I'm really happy that Boyd could share the presentation because for our point of view we always have the attacker point of view or often the attacker point of view in our community and it's nice to see all the constraints which happen when in fact behind people have to patch what we have found and it's interesting to understand their problem at the end so this is it for us if you have a further question we'll be happy to answer during the Q&A session or you can contact us on Twitter, GitHub or by email thank you very much I want to add that we also enjoy the cooperation with Sorin it was very pleasant to work with you and we were happy that you spent the time for us to do so because basically you don't have to so thank you very much thank you okay thank you very much it was a really interesting talk although I do have to admit I'm not that deep into cryptography as you two are but thanks a lot and I heard that the interest was very high so congratulations for that reminder for everybody at home if you want to submit questions feel free to do so on Twitter or on Twitter or in the RSC with the hashtag R3S in the FIDIWARS or in the channel R3S in RSC so we have some questions already first and foremost before I forget it because I don't have it down from people here on premise how much of a pain in the in the back was it to discover this and get it and get everything working no it was I mean I'm not used to Windows Reverse so it was interesting to me to get back to that it was not that painful except for the open part where I had to look to open SSL source code to match this part but otherwise it was quite okay there were no debug protection and so on so it was quite and function ID was working quite good okay thank you very much so let's go to the first question from the audience are the signs that this solution for 1024 bits are it widely used or only found here so it is used by many people mostly by people using Sandisk use B sticks but yeah I can't give you actual numbers but it's a fair amount of people so it's the setup is only you've only seen it with with exactly the set of devices you described it's not broadly used in terms of of it's not an industry standard as you would say it's not an industry standard no certainly not what we can see is the update request because the software has a built in updates function and we can see the request to the update server to see if there's a new version available and that also reports the version numbers that are actually used by the software so that there we can see we can make an estimate of how many people are using it thank you very much then furthermore would a tech illiterate end user ever want to use this type of security products as opposed to just using well known software that the built in disk encryption in the operating system it's so it's a bit different than full disk encryption it's file encryption and the solution is quite simple it's by default on the disk and it's quite simple to use so yeah if you don't know a lot I mean if you don't know a lot on this kind of software then you will use it and it's quite simple no I do have to interpret the question but I'm not sure whether that's the intended what they intended to say but how I would see it is would you recommend a end user to use this to protect their assets or would you rather recommend look do software encryption and leave this thing leave this thing aside the examples that that we got in the question are basically all block device encryption and that's not always working for all scenarios so if you need file encryption you will need to use something else and there are actually also other alternatives available even open source ones what I think is really interesting about especially the combination with our software with Sandisk is that you can actually use it on the iPhone as well because using used B sticks on the iPhone is not a given that you have to make something special to actually make it work as a vendor and this software of Sandisk actually includes an encryption option I like that thanks did you have a look at the M Crip with the M integrity for doing file encryption I do see that also as a yeah please take it if you want to answer that so no we did not look at that well not in the sense that we cannot use the M we cannot use the device mapper stuff from Linux because this is software for Windows and for macOS and it's file encryption and not block encryption that's what I thought so then how did the migration of existing vaults work for the end user so it's it's actually relatively simple as soon as you start a new version and you open the vault it will tell you that the vault has been upgraded you have to open it you have to specify the password and then it will upgrade it for you which means that the key encryption key will be re-encrypted and we will now also write the the salt because the previous version had a static salt as so far correctly concluded so we need to write the salt for every fault and that's what we do and obviously then you need to re-encrypt the key encryption key ok thanks and for now the last question what do you think about using ECC in military great cryptography I have never heard about ECC military great encryption but I would be happy to know and to look at it it would be really fun ok thank you very much ok so far I don't see any new questions let me refresh my pad so thank you very much for your talk it was really interesting and as again the interest from the community was there so thanks a lot I just have one remark my contribution to GenZeripper was merged recently to the main repo so now you just need to update your GenZeripper repository you don't need to use mine ok cool so John the Ripper has been updated from the talk we have one last question I do think we have time for that have you considered data format compatibility with existing file based encryption schemes such as NGFS no we haven't ok thanks so and with that I will hand you over to our backstage crew so to say