 One of the major pitfalls in any security solution is usability, and one way to deal with that, the market decided is self-encrypting devices. You might have come across them, it's usually external drives that do all the crypto stuff for you, but what do you do if these devices are broken and have weak crypto? Well, it gets even worse if you have an operating system like Microsoft Windows and it detects you're using such a device. BitLocker, for instance, will automatically use that device instead of possibly stronger software crypto. Here to tell us more about that is Carlos Meijer. Alright, thanks. So who is this guy? Well, I'm a PhD student at Radboud University in Nijmegen. My focus is on cryptographic stuff in the wild, so basically breaking stuff that's black box. You might know me for cryptographic attacks on my third classic, like the patched one, and some algorithms for generating passwords in Wi-Fi routers. And this year, about self-encrypting drives. If my research appeals to you, then you can hire me as a consultant at Midnight Blue Labs if you want to. And first I'll start off with a few acknowledgments. I can't thank Philip Gehring enough for his research on the Samsung 840 EVO, like it really contributed to mine. So thanks. If you want to get involved with his reverse engineering stuff, you should. It's awesome. It's amazing. So yeah, cliche, what's a self-encrypting drive? So traditional encryption is like you have a plain text, you have an algorithm and a key, and combined you get some cybertext that means nothing to you. Everything can only be decrypted if you have the same key. And that ends up in a storage device. Now there's also the hardware style, which basically integrates everything into a single device. So both the encryption and you just basically give the drive, the data, and the key, and it will do everything for you. And that sounds convenient, but there are caveats. That's probably why you think I'm here. So basically these things encrypt everything, and they always encrypt everything. So even if you don't set a password, the moment that you set a password basically uses that password to encrypt the key. So the encryption is then instant, so you don't have to re-encrypt everything. So basically if you look up the spec sheets of these things, these aren't like magical chips, they're just ARM cores, and there's another. So there's firmware. That's basically software if you typed even off. And if you look at a PCB, then you might wonder what these pins are. And they're actually JTAG, so you can actually debug these things. And there's another example of one. So yeah, that's where the fun starts. So well, these self-encrypting drives haven't been theoretically proven, but they've been democratically proven in the sense that there's all this marketing fluff around it. So basically the takeaway note is software encryption is way inferior to hardware encryption. There's even studies released about it. It's great. So even BitLocker trusts these things by default if your drive actually advertises support for this. So I kind of wonder, what are the actual security guarantees of these things? Well, just taking theoretical approach. We're going to dive into the practice later. So there's three attacker models, and we're just going to play the attacker model game. So either machine is on and the attacker has physical access to a power-down machine. This is very bad when you're using software encryption. Either the machine is off and there is no awareness of the victim that the attacker has actually physical access to the machine, or the victim is actually aware that there has been physical access to the machine. So then you should consider the device tainted, and therefore you shouldn't enter a password into it anymore. So you're just going to assume that from the physical encounter onward, you won't get anything from the victim anymore. So no password secrets whatsoever. So let's focus on the first one first. So software encryption keeps a secret key in RAM. It needs that to operate. So that has inherent weaknesses, so you can extract that key from RAM with the cold boot attack, for example. I won't go into this in too much detail, but basically you load a custom OS and then basically you extract it from its previous state. Or you could do a DMA attack, for example, through Thunderbolt or Firewire and that kind of stuff. And so hardware encryption is supposedly immune, but so actually the key is Captain RAM and that is in order to support standby mode. So if you put your PC in standby mode, it turns off all the peripheral devices and therefore when you resume it again, the drives needs to be unlocked again and you don't have to enter a password. So guess where that password came from? So it's actually Captain RAM all the time. And also a key is kept in storage controller because it needs to use it for encryption. And a storage controller is not a secure device by any standard, so there's actually on many of them as we saw in the previous slide, there's debugging interfaces on them. So you can just use that and take the key out. And given that the afterwards area is physical access, you can basically just hot plug the device. So in this scenario, self-encrypting drives are definitely not superior to software encryption. So we take a look at the second attacker model. So the machine's off and the victim hasn't noticed that there has been a physical encounter. Then that's what we call the evil maid attack. So basically you're out and your laptop is in a hotel room and the evil maid comes there and installs some vector functionality. So basically you install the vector functionality, you wait for the victim to enter a secret key and then you exit the data or the key or whatever you want. And so this can be a hardware key logger. There's not really meaningful defense. This can be a backdoor in the boot loader. Well, you can actually defend against this with TPMs or secure boot. But when our hardware encryption enters the game, it doesn't change anything. So it's still equivalent. It's not superior. And then we end up at our last scenario. It's when the thing is powered off or when you lose it or when your device gets stolen and the attacker has physical access to it, then software encryption actually provides proper security given that the implementation is sound. And if you use open source software, which is audited by independent experts, you have a pretty safe bet that your data is secure. Or if you use proprietary software with some implementation details that are public and independently audited, then you probably find as well. Or you can just live on the edge and use a black box implementation and hope for the best. I mean, I wouldn't prefer it, but it's your choice and you have that choice. For hardware encryption, you only have that choice. And moreover, it's extremely hard to audit. And there's even additional pitfalls in the implementation that apply only to hardware encryption and not to software. So basically, the takeaway message is security guarantees are equivalent at best. And probably worse. So with that, I'll guide you through some standards for self-encrypting drives. So there's actually two widely used standards. So it's ATA security feature set and TCG OPAL. ATA security feature set is actually something that's just designed for access control. And so it actually predated the self-encrypting drive era and then manufacturers decided to basically take that and use the incoming password as a key for encrypting the stuff. And TCG OPAL is actually designed for usage in self-encrypting drives. So let's take a look at the first. Well, before we do that, suppose that you had to implement this yourself. Like, it will probably look something like this. So you get an incoming user-supplied password and some keyed hash, which you use combined with the password and the salt. And then you get a hash result and you compare that to some hash output. And if that matches, you take another keyed hash with another salt with the same password and that will be your key. At least this is how I would probably implement this. So so far, this is easy. So now if we go back to ATA standard, as I said, it's predated. The SCD era, so encryption is not mentioned anywhere at all. And there's two types of password, user master. And both are user-settable, actually. But the master password is set during the manufacturing process. So there's some setting. It's called the master password capability bit. And it's either high or maximum. And so high means both user and master password have access to the drive's contents. And max means only the user can unlock the drive, but the master may actually erase the drive. So I didn't come up with these terms, but high doesn't seem that high security to me. So bottom line, you should either always change the master password or set this thing to max or face the consequences. So this is how I would likely implement this. So you have two of these data structures. And basically you have the same thing for checking the password. So you have an incoming user password, and you put that through a key hash with a salt. And then you get a hash result, and you check whether the incoming password is valid. And if so, then you use another salt to generate a key, which then decrypts an entry in this data structure, which then decrypts another entry in this data structure. And the reason for it is that if you want to erase the drive, then you don't need both passwords. So TCG OPAL, it's more modern, they say. And so it's actually a de facto standard for these kind of things. So there's a notion of multiple partitions, which are called locking ranges. And there's a notion of multiple passwords, which they call credentials. And a single credential has the ability to unlock multiple ranges. And a single range can be unlocked by multiple credentials. And so in database terms, this is many to many. So this is something that has to be supported if you implement this. So any password, any range, and many to many. So imagine that you had to implement this. It shouldn't come as a surprise that people make mistakes with this. And oh, by the way, you also need to be able to scramble a single range independent of all the others, and also not knowing all the passwords that unlock it. So this is fully trusted by BitLocker. BitLocker doesn't use the ATA standard, it only uses this. So, well, there's a couple of typical pitfalls in the implementation of these things. So pitfall number one, and yeah, this is like the stupidest. So you have an incoming password coming from the host PC, and everything that ends up in the drives flash chips gets encrypted with some key. And in the middle there's a black box that basically links one to another. But you don't know how that works, and you don't even know whether these things are related at all. So if not, then basically all the secrets that you need in order to access the data are already stored in the drive. So this happens. And so pitfall number two is suppose that you naively implement this scheme, and then you probably take a single key in order to encrypt all the data, and then use different passwords to encrypt that key. So this means the weakest password will allow access to everything. You can lock that down in software, but it's not cryptographically enforced. And so if statements, which you can basically do away with if you modify the firmware. So in this case, even BitLocker leaves a single range unprotected, where the partition table is stored. So if you would use this scheme, then you would basically need no password, because that range has to be able to become decrypted. So in this case, yeah, everything's compromised. So obviously there's this randomness problem, because there's no way to directly influence these keys. You need to somehow make them trigger a regeneration of them. And so you don't know how the randomness is obtained. And so yeah, these things in embedded devices tend to be badly implemented. And there's the ware leveling issue, which is kind of interesting. So multiple writes the same logical sector trigger writes to different physical sectors. That's basically in order to make sure that the flash chip doesn't wear down too quickly. So you have a finite number of write and erase cycles that a single block can actually handle. And in order to, you want to spread that out as much as you can over the entire chip in order to make the service life as long as possible. So therefore there's this algorithm in between that maps logical sectors to physical sectors. And if you write two successive times to the same physical sectors, chances are that they end up to the same logical sector. Chances are that they end up in a different physical sector. So the old data is still there if you overwrite the original. So if you get the drive from the factory, then obviously the key is in there, but it's stored unprotected. And suppose that you then set a password, and then you overwrite the original key with an encrypted variant. It's oversimplification, but it's a basic idea. But if there's ware leveling, then the original data may still be there. And therefore, all you need in order to encrypt all the data is also still there. So yeah, that's basically what I just said. Pitfall number five, and this is the final one. There's this devsleep mode. And this basically means going to some power saving state. So hostPC sends a devsleep signal to the storage controller. And the storage controller, basically there's no specified way in order how it is that defines how this power saving is to be achieved. So it can be achieved anyway. So the storage controller may decide to dump its RAM into non-volatile storage and then turn off its RAM. So it may do that. It's not specified. So in that case, secret keys may also end up in non-volatile storage. And it's crucial that these things are erased on resumption or not being used, not being stored in non-volatile storage at all. So yeah, there's a couple of scenarios where we looked at this. And finally, there's general implementation issues that also apply to software that still apply in hardware. So stuff like motive operations. This probably rings a bell, side channels, key derivation, et cetera. That's all still there. So what's our methodology? So a general approach, it's actually pretty ad hoc, the stuff that we did. And I mean, you can't really fit it into a single model, but we tried to make it as generic as possible. So there's this three-step program. Obtaining a firmware image, gaining low-level control over the device. So actually, that means debugging it or getting code execution. And then analyze the firmware and see if you can find some crypto implementation falls. Yeah. So obtaining a firmware image, that seems easy, download it. But that can be harder than it seems because there's usually obfuscation applied. So you need some vendor tool from the manufacturer that uses SSLs. You need to strip that. And then probably there's another layer of crypto applied just for obfuscation, just to piss you off. And so this is an example of the Samsung Magician, which uses some AES key that's hard-coded, but it's not in the body of the executables. You need to reverse that. And it's annoying. And the image itself may also be encrypted. And if the decryption is performed on the unit itself, then that's a dead end because you don't have the keys. If it's done on the host PC, then obviously you can perform the decryption yourself. So in that case, you'd have to pull the firmware from RAM to JTAG, for example. But it's not a given that that's available. So yeah, let's take a deeper look into that. So JTAG allows you to control the device completely. So you can help the CPU, set registers, read or write to the address space. Basically, you control the whole thing. And some models have it in plain sight. So for example, this one, it's a 14 standardized pin layout. Others need some figuring out. So we use this board called the JTAGulator for it. It just basically brute forces the pin layout. And if it's not there, it can be turned off for many of these controllers. Then you need some code execution to be achieved. So how do you do that? Well, some vendors have undocumented commands that allow this. Some have vulnerabilities in their firmware. But it's kind of a chicken and egg problem because if you don't have the firmware image, then you can find these, obviously. Some have some code stored in memory chips, like the firmware image itself, stored in some memory chip that you may modify with external equipment. And if you want to go really hardcore, you can bypass cryptographic signature checks with fault injection, for example. So now, yeah, this is analyzing the firmware. It's basically looking at how it's implemented. That's more of an art than a science. So I'll give you a couple of hints that you probably want to take away. So first, if you have the image, you want to figure out its section information. So you want to see what pages are mapped where in the actual address space. So you take that from the image header. Sometimes it's obvious. Sometimes you need a little bit of reverse engineering. Then load the image into disassembler. We use IDAPRO for this. And then figure out what the firmware does. Now, it seems it's easier said than done. So one of the things that you probably want to look at is finding the HTA dispatch table. So basically, it's a table of structures that has at least an opcode and a function pointer that contains the implementation of that command. And so basically, I haven't seen any manufacturer that doesn't do it this way. So if you find that table, then you can actually look up in the HTA standard what every one of these functions implements. And that's really convenient. So if you want to go target it and you want to see what kind of implementation is used for a certain command, then go hunt for that table. And yeah, you'll probably find it in a couple of days. So yeah, look through a function with interesting opcodes. Like, these can be vendor-specific, though those tend to be really interesting. So without further ado, I will go into the case studies. So the first one is the crucial MX100. It has some Marvel controller. There's no documentation whatsoever. So we use reverse engineering for all of it. It has a dual core, yeah, basically ARM controller. It's some proprietary design, I believe. And of course, it has a hardware crypto code processor in order to cope with the bandwidth of HTA because this thing obviously isn't powerful enough, although it's quite powerful. It's like in the range of a Raspberry Pi. So firmware images, they come as bootable ISO images. So you can just, yeah, you can just take the firmware image out. It's plain text. Everything's there. They're cryptographically signed though, so you can just modify it and then flash it. But it has a JTAG debugger, so you can, if you want, you can still flash it by breaking the signature checks. So the findings on these drives is, well, the incoming HTA password, if you're using HTA in order to encrypt your data, it's basically hashed compared to some other hash and then not used further on anywhere. So basically, that's it. Remove the check and then access the data. That's enough. That's sufficient in order to break the encryption if you're using HTA security on this drive. Now, with these OPL, you probably expect better, but nah, then again. So same story. Everything's the same. There's some interesting vendor commands, but you need to unlock them first. So you need this quirky command, set some LBA to some magic value and use this feature code and this HTA opcode. And then all of a sudden, the vendor commands are unlocked and you can use different commands. So one of them is to read a page in SPI or erase or write it to it. And the SPI flash actually contains the serial number, some diagnostic stuff, but also the bootloader. So you can actually get code execution with this from the host PC, which is interesting if you're developing malware, for example. But even they thought this was kind of inefficient, so they also included an arbitrary write. So summarizing the above, it's great. You'll see. So the MX200 is basically the successor to this thing. The JDAC pins have moved, so it's kind of annoying to solder on them now. So yeah, that's basically the challenge that you get. But everything else is the same. So same vulnerabilities, same everything, same vendor commands, everything. So yeah, great. The MX300 though, they really upped their game. So they moved to a different kind of memory, which is not really relevant in security, but I thought I'd tell you anyway. New controller, and they turned off the JDAC, and they also completely rewritten the security code. So, oh yeah, by the way, the vendor commands are still in there, but now you don't need this magic. You can't use this magic unlock command anymore. They use cryptographic signatures, and obviously we don't have the key because it's asymmetric, too bad. And there's some buffer overflows, and none of them are exploitable, though at least I couldn't exploit them. So how do we get code execution on this thing? Because we need that in order to, well it makes researching this thing easier, and also you want code execution in order to exploit some crypto bugs. So for that we looked at the boot process. So on the left you see a ROM, which is embedded into the controller, which then loads some code from the SPI flash. And basically that loads the firmware from NAND. So, yeah, this, like if you wanna take off the NAND and modify the firmware in NAND, that's really annoying. Like there's, it's a BGA chip, like over a hundred pins. So how about we look at the SPI flash? Because that's only eight pins, and the pins are exposed on the outside. And it's located there on the board. So that's what we did. We connected a reader to this thing. So some wires going on and a convenient header. So first what you do is connect an SPI reader device and make a backup obviously of this thing. Then craft some code that removes the signature checks from the firmware. So once the firmware is loaded, and but not not yet jumped to, then you patch it. That's some code that you inject into the SPI flash. So yeah, that. And then flash this modified stage two of the boot process. And then the driver will accept arbitrary firmware's within valid signatures. So then you take a firmware image and add some features like arbitrary read, write and execute. And then you flash it as if you would flash a normal firmware update to send it to some ATA command. So I'll do that later. Actually, I'll demonstrate that. So on with the key derivation scheme. So we reverse engineered all of it. Basically, there is now binding between the actual password and the actual key that's being used eventually for encrypting our data. But, and that's a big but, basically this incoming password is used to encrypt one key. And every password basically yields that same key. And that key is then used to decrypt some range key. So basically, if you have that key, which they refer to as the RDS key, then you have actually access to everything. Everything else is just if statements. So yeah, this is prevented by the firmware, but it's not actually encrypt graphically enforced. But you still need a single password in order to access all the ranges. And all the keys for all the unprotected ranges are actually stored in plain text. So you don't get the RDS key from them. So this could work. At least like you need a single password, which like it lets be honest, like that's the only reasonable scenario that you're going to use this in. You're not gonna use multiple passwords, multiple ranges. So, but we still found a way around it. So consider the password protection function. So they call it protect password. And from the name, you probably think this thing just generates a hash, but it does more than that. It actually, the output actually contains the RDS key encrypted with your password. So you shouldn't really be throwing around the output of this thing. So actually we looked at, so we injected some code into the firmware within some functions. And we changed the behavior such that it just does the original behavior and also just puts the fact that it's been called into a log file. So with its parameters. So what you get from that is this fancy log file. And it basically, it says protect password. And the password is a zero buffer. And the flag for storing the RDS key is, yes, please store the RDS key in some slot number, in some table. And then that entry gets copied to a lot of other slots. So eventually this RDS key encrypted with a zero buffer ends up in all of these slots, except for 15, which is overwritten later. And the decryption key is a zero buffer. So as an attack strategy, you would flash this modified firmware image, then craft some code that recovers the RDS key from slot one, basically decrypting it with a zero buffer, execute that code on the device, and then you have the RDS key. But you're still not there yet because there's still some access control in the way, so you need to remove that. So there's a password verification function that basically checks a hash that you have to nullify. And then unlock any desired range with an arbitrary password. So now I'm gonna demo this. Let's pray to the demo gods. So, yeah, sorry. So let me see. Oh yeah, this one, let's see, flash one. Yeah, so it detected my flash. So it's actually on the desk here. Could someone please the camera maybe? Yeah, so this is my USB SPI reader device and this is the crucial MX300 and it's actually connected and there's this board in between and it's a fancy JTagulator, but it's just there to supply voltage. Sorry. So yeah, I created a cheat sheet though. So basically what I'm going to do now is generate this. I already made a backup of this thing, obviously. So I'm just gonna, Okay, so yeah, this is my make file that does everything and it patches the firmware and now basically the firmware. So the SPI flash image is patched now. So I have this thing here and I'm going to flash it. So I'm going to look it up in my cheat sheet. Okay, so now it's flashing. So that will take a while. In a minute, I'll show you a video of the stuff that I did earlier. So this is basically the BitLocker setup phase. So the drive is connected to the PC for the first time and it attacks it and let's create an empty partition table, new volume, NTFS, everything default and then we enable BitLocker. So spoiler alert, the password is HDF HDF. As you can see, there's no dialogue asking you to would you like hardware encryption whatsoever? It just uses it and now drive encryption is enabled. Okay, let's see if the flashing is finished. Verifying flash. Yeah, okay, so that's probably, this is not within the range that I actually modified. So it's okay, it's just some glitch. So now I will remove this and remove the reader and plug this in. Okay, so, oh wow, my kernel panicked. So while the laptop's rebooting, I'll be the metaphorical chicken to be butchered to appraise the gods. Who here had a demo crash on stage? Hands up. Of those, was it hardware? Yeah, was it software? Ooh. Well, how's it going? Ready? Yes. Can I get a picture maybe? Ah, there we are, great, great. So, okay, now that the SPR is flashed, it should now accept arbitrary firmware images. So I'm going to make an arbitrary firmware image. It's over there and now I'm going to flash that. So this is the command for flashing it, HDPARM, yes, I know what I'm doing. Please destroy my drive. Oh, great. Doesn't work. SDC, oh, okay. So now, okay, so now I'm going to compile some code. Recover RDS key, oh, it's already there. And then I'm going to use my tool tinker in order to write that into RAM of the drive. So, oh, by the way, let's read out the RDS key. Oh, wait, SDC. So this thing is zero, so it's not loaded. So then use tinker to write this code into the address space. Then SDC, yeah, roll write successful. Okay, and now run it, invoke jump successful. And now, read it out again. Oh, I can use this. The RDS key is there. Okay, so cryptographically we won. Now though, we have to unlock the drive. So I'm going to use this. Just make a four byte zero byte file and then upload that to the drive. Okay, and now I should be able to unlock this thing with any password. There we go, that one's sort of okayish. So, they claim this is the best in class hardware encryption. Yeah, I'll leave that up to you whether that's true. So there's also, they also obviously implement the ATA security feature set. And by default it has an empty master password. So you need to change that or set the master password capability set to max as you know. So for the MX300 it's insufficient because if you have this custom firmware you can basically set that variable in RAM to zero and then downgrade to high and unlock it with an empty string. So I'm not going to demo that though. So on with the Samsung A40 EVO, it's actually the first Samsung drive that supports the TCGO PAL standard. It's a three core Cortex R3, 400 mega, it's pretty powerful. Firmware updates are pushed through Magician or a bootable ISO image and it's cryptographically signed. And it has a JDAB debugger. So this is their scheme. So, bear with me. So on the left you have a password coming from the user and actually they take some salt in some table which is the credential table. So there's a total, there's 14 credentials. You can define 14 credentials and it takes that password, takes the first salt and then puts that through a key hash and then you get a hash and you verify that hash and if it matches, then you take the second salt with the key and you get a key. And that key is used to decrypt an entry in a table. That table is 14 times nine entries wide. So for every 14 credentials, it has an entry for all the nine ranges that are possible and it takes that one entry and uses it to decrypt that entry. And with that you get another key which is then used to decrypt these lists, an entry in this encrypted disk encryption key tables. So this is how you properly implement Opel. So they actually use a 64K blob in order to store all of this data and then you get all of the proper cryptographically enforced properties. So congrats to Samsung, they did it. On the ATA security feature set though, the DAK only depends on the password in max mode. So if you use high mode, there's no cryptographic binding. The password and the key is not related at all. So you can just remove the password check and do whatever you want. So this 64K bit blob is stored somewhere and that's actually stored in a ware-leveled memory. So you can just scan through the NAND and find an earlier copy of it. If you're lucky, there's a plain text key in there and you can use that to unlock the drive. And we actually did this in practice, although it's pretty unlikely that you're gonna find this. But if you find it, then you're there. And it affects obviously both OPAL and ATA security because it's in the same data structure. So on with the 850, it's a successor to the 840 of course. It uses a newer controller and different firmware obfuscation routines, but that's obfuscation, it's all done, it's all undone on the host PC. But this one supports Dev Sleep and that made it interesting because we're gonna take a look at Dev Sleep as well and 840 didn't have that. Everything is pretty different. They made quite some changes except for the crypto implementation that's built on the same implementation. So it's basically all of the same except for the ware-leveling issue, they fixed that. So now the T3 portable, it's a portable drive based on the 850, it's actually the exact same thing. It's just with a USB SATA converter in front of it. With a T3 specific firmware that you can download but you can pull it from JTAG. So it has a proprietary security command set, so no ATA and no OPL proprietary stuff. And AS256 is a big part of its marketing. And so there's this configuration tool that they ship. It actually sports Android, I think it's kind of cool if it properly secures your data. This thing is actually the implementation of these proprietary commands are actually based on the ATA security implementation with the master password capabilities set to high. So no cryptographic binding whatsoever. You can just remove the password check. So yeah, I'm hopefully going to demo this as well. So virtual box. So access security enabled. So yeah, if I go into here as far as I know this, yeah, this thing's connected. Yeah, it's not there. So if I do this, yes. Then security set to enabled. So if I now want to disable security, I'm just going to go for an arbitrary password and that's incorrect. Okay, so far so good. Let's try something. Oh wait, of course I have a cheat sheet. There we go. So this address, OCD, okay. Data is connected. So I now should be able to do this, hang on. Okay, so these are the cores. Now held CPU, dump registers, all of that. It's amazing. Okay, so let's put a breakpoint at this address. So do hardware, resume. Okay, so now if I enter an arbitrary password, it will stumble upon that breakpoint. And so I will now remove that check and obviously remove the breakpoint and then resume. And there we go, security disabled. So yeah, that worked. Okay, so apparently this thing is tough to crack. So some very impressive shock resistant exterior this thing has and of course hardware AS256 encryption. So yeah, I hope the exterior does a better job. So on with the T5, it's basically a T3 with, yeah actually with a different converter. So rather than USB 3.1 Gen1, it supports Gen2, but actually the hardware behind it is pretty similar, so it's equally vulnerable. They just switched off the JTAG, so it's just harder to exploit. So same thing. Conclusion, so most of these self-encrypting drives have some severe weaknesses. Best case scenario, it's going to be equivalent to software, not better, and worst case, it's all down the drain. So on a further note, TCG Opel is terrible, so it's really over-engineered. They have all of these kinds of features that nobody uses. Security goals are not clear, like what's the benefit, and there's no reference implementation of this thing, and implementation is not even part of its compliance test whatsoever. So yeah, there are structural changes needed. So with that, if you have any questions, I'm happy to take them. Okay, we have microphones in the hall here. Please line up behind the microphones if you have any questions, and keep your question to one sentence and for all of you to spare you that. Thank you very much for this excellent talk. We'll start with our signal angel referring questions from the internet. Thanks for your talk. I hope your SDP is fine. So do I. Are there similar issues? Are there 500 and latest crucial drives one can buy today? The MX500 in particular, I didn't take a look at it because actually the MX100, 200 and 300, they use some Marvel controller and the MX500 is from a different manufacturer and it's not even based on ARM. And so it's really annoying for me to reverse and so therefore I left it at that. Microphone number two, please. Hi, great talk. Can I ask you if that hardware encryption can be disabled for BitLocker and what if I don't use BitLocker use another software or another operating system? Does it use hardware encryption? So with BitLocker, so the question was can I disable the BitLocker encryption delegating it to the drive and how is it this thing, what's happening with other operating systems? So BitLocker can be, you can actually tell BitLocker not to use this. You can change some group policy setting. There's an advisory set up by Microsoft that tells you how to do this. With other operating systems, they basically don't do this. So if you use Linux or Mac OS X, file vault, it doesn't matter. So particularly with BitLocker, yeah, basically BitLocker is the only thing that does this except if you use a tool that advertises like, hey, we're using the hardware crypto. Microphone number four, please. What about the newer Samsung versions like 960 and 860? I haven't taken a look at it. So actually I've taken a look at the 950 and it's pretty similar to the 850. The point is, so they didn't screw up Opel. They screwed up ATA security and with the 950, that the 950 is an NVMe drive, right? So, but they still support ATA security and nobody in their right mind would use that, but they support it and you can actually use it. So, but I don't think it's actually really interesting to look at all of these Samsung drives. Like we're trying to make a scientific approach here. So we're taking a couple of samples. We don't want to take too much of these convenient samples like, okay, this is probably similar to that and therefore it's just another drive that we can add to our collection. We want to make it a bit more broad. So we want to make the sample that we have as accurate as possible. Microphone number one, please. How hard would it be to implement security on self-encrypting drives correctly? And is it reasonable that that could be done in an open source development model? I mean, there are efforts for open source firmware on these drives, but they didn't get far as of yet. So, yeah, I mean, you probably want that, but then if I made like, why would you want self-encrypting drives? Like they're not in any way better. Just use software encryption, it's fine. And like even for performance, you have these AES instructions that everyone has now. So for performance, it's negligible. So, yeah, you can do this properly. Samsung did this with Opel as far as I know, because like, I'm not a wizard, I don't know everything. So, yeah, you probably could implement this correctly, but even if you did, then it doesn't give you any benefit. Microphone number two, please. Thanks for your research. What about your communication with vendors? Did you do responsible disclosure? Yes, in April, we actually gathered together with Samsung. So, we set up a meeting and we actually demonstrated all of this stuff, and then, so they were really kind to us. So, and also, we contacted Crucial for this. It's just that, yeah, basically they responded, obviously they weren't happy with what we found, but they were very happy the way we reported it. So, yeah, I don't know, what can I say? It's a responsible disclosure. Thanks. Number four, please. Hi, thanks for a great talk. My question would be, did you happen to take a look at NVME drives, and if yes, did things improve on that front? So, as I said before, we did take a look at the 950, so that's a Samsung NVME drive, and it's basically the same thing just with an added NVME sauce. So, the core of the implementation of everything is the same, just the interface has changed. So, but we didn't include it in our final research report because that's basically, we're not trying to cherry pick drives that are likely vulnerable whatsoever, so. Number one, please. How come in our firmware updates for these class of devices? Are they distributed by Windows updates or similar measures? Or are they only available if you install them manually? So, for Samsung, you have this tool called Magician that checks for firmware updates. Definitely not through Windows update, though. So, yeah, I think, like, it depends on your manufacturer, but all of them do offer some kind of centralized distribution platform for firmware images. But if you don't run Windows, then you're basically on your own, you have to download them from the website. Number two, please. Hi, I mean, on most SSDs, there is a function to completely wipe the drive by removing the key. Have you looked into this case and have you tried to recover the data after wiping the drive? Well, not deeply enough, I'd say. Well, of course, we did look at some of these implementations, like, is the key actually written with random data and where does that data come from? So, yeah, we did that. But, like, for example, if there's ware leveling, you can probably still get the key out. But then, again, all the tables, like, probably the FTL, so the physical to logical mapping tables probably destroyed, and you get all of that kind of stuff. So, it will be really hard to recover data from this thing, even if you had the key. Again, microphone two, please. Yeah, thanks for your clear yet kind of radical statement about self-encrypting drives. I'm wondering, working in a research institute, where I find more and more people going to use or demand these self-encrypting drives for, as they say, practical reasons of data protection when working in the field. And now, I have learned just now that software encryption is superior. What do you recommend in a practical usage scenario for the three ecosystems, Apple, Linux, Windows, as a software solution that is definitely superior to self-encrypting drives? I'd say veracrypt. Okay, thank you. Are there any more questions? No more questions from the internet? Oh, we have one question at microphone number two. Yeah, thanks for your research. You said you actually disclosed these problems to the vendors. Did they actually fix it? So actually, Samsung really released a statement and basically saying, if you're using an internal drive and you're dependent on the hardware encryption, please switch to software, which is, I think it's kind of radical because I think as far as I have seen, the Opel implementation is solid. For crucial, they basically told everyone, yeah, we released firmware updates. I haven't looked into the MX300 firmware update, but for the MX100 and 200, they basically just switch off the JTAG and remove some vendor commands that allow for the arbitrary write and also obviously not make it able to downgrade. But if you find some alternative means to get code execution on this thing, you're back in the same boat. I think we're all out of time. Thank you very much, Oscar Mayer. Thank you.