AV-Portal 3.23.3 (4dfb8a34932102951b25870966c61d06d6b97156)

Self-encrypting deception

Video in TIB AV-Portal: Self-encrypting deception

Formal Metadata

Title
Self-encrypting deception
Subtitle
weaknesses in the encryption of solid state drives (SSDs)
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
We have analyzed the hardware full-disk encryption implementation of several Self-Encrypting Drives (SEDs) from Samsung and Crucial (Micron) by reverse engineering their firmwares. The vendors combined cover a majority of the market share of SEDs sold today. In theory, the security guarantees offered by hardware encryption are similar to those of software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the drive advertises supported for it. Thus, for these drives, data protected by BitLocker is also compromised. This challenges the view that full-disk encryption implemented in hardware is preferable over software. We conclude that one should not rely solely on hardware encryption offered by SEDs.
Keywords Security

Related Material

The following resource is accompanying material for the video
Video is cited by the following resource
Loading...
Software Instance (computer science) Musical ensemble Cryptography Information security Operating system Usability
Classical physics Focus (optics) Numerical digit Password Solid geometry Student's t-test Mathematical analysis Digital signal Student's t-test Information technology consulting Independence (probability theory) Cryptography Password System programming Motion blur Encryption Information security Router (computing) Electric generator Wireless LAN Router (computing)
Algorithm Key (cryptography) Numerical digit Computer-generated imagery Moment (mathematics) Data storage device Digital signal Password Software Computer hardware Encryption Motion blur Encryption Information security Reverse engineering Reverse engineering
Personal identification number Arm Observational study Numerical digit Digital signal Arm Inclusion map Duality (mathematics) Event horizon Software Befehlsprozessor Computer hardware Software Core dump Computer hardware Encryption Encryption Information Information security
Random number Context awareness State of matter Authentication Virtual machine Password Theory Data management Software Encryption Motion blur Factory (trading post) Information security Booting Vulnerability (computing) Default (computer science) Default (computer science) Focus (optics) Key (cryptography) Data recovery Point (geometry) Model theory Digital signal Virtual machine Sign (mathematics) Event horizon Software Computer hardware Password Endliche Modelltheorie Encryption Game theory Information security Physical system Booting
Laptop Axiom of choice Slide rule Game controller Functional (mathematics) Implementation Installation art Open source Multiplication sign Virtual machine Black box 2 (number) Mathematics Peripheral Software Computer hardware Encryption Implementation Information security Booting Key (cryptography) Interface (computing) Model theory Open source Data storage device Expert system Digital signal Virtual machine Message passing Computer configuration Software Computer hardware Function (mathematics) Password Order (biology) Encryption Game theory Information security Software protection dongle Asynchronous Transfer Mode Booting
Standard deviation Execution unit Standard deviation Game controller Key (cryptography) Electronic program guide Set (mathematics) Digital signal Zugriffskontrolle Hash function Password Information security Information security Resultant
Standard deviation Password Maxima and minima Zugriffskontrolle Type theory Term (mathematics) Hash function Encryption Motion blur Factory (trading post) Data structure Pairwise comparison Information security Scalable Coherent Interface Key (cryptography) Content (media) Maxima and minima Bit Digital signal Line (geometry) Greatest element Type theory Arithmetic mean Process (computing) Hash function Password Encryption Information security Resultant
Standard deviation Standard deviation Multiplication Range (statistics) Password Independence (probability theory) Range (statistics) Database Digital signal Partition (number theory) Single-precision floating-point format Term (mathematics) Computer hardware Password Encryption Information security MiniDisc Partition (number theory)
Random number Implementation Randomization Link (knot theory) Flash memory Tape drive Range (statistics) Password Numbering scheme Black box Entire function Number Cryptography Finite set Single-precision floating-point format Logic Energy level Firmware Partition (number theory) Key (cryptography) Block (periodic table) Flash memory Range (statistics) Digital signal Single-precision floating-point format Partition (number theory) Software Logic Personal digital assistant Entropie <Informationstheorie> Password Order (biology) Statement (computer science) Encryption Cycle (graph theory) Information security Table (information)
Standard deviation Asynchronous Transfer Mode Game controller Implementation Service (economics) State of matter Multiplication sign Password Number Power (physics) Non-volatile memory Derivation (linguistics) Cryptography Operator (mathematics) Software Computer hardware Logic Encryption Motion blur Implementation Algorithm Key (cryptography) Data storage device Physicalism Digital signal Entire function Inclusion map Software Personal digital assistant Logic Factory (trading post) Password Order (biology) Video game Encryption Information security Spacetime Asynchronous Transfer Mode
Computer program Game controller Implementation Computer-generated imagery Execution unit Code Medical imaging Spacetime Endliche Modelltheorie Reverse engineering Firmware Address space Personal identification number Execution unit Standard deviation Key (cryptography) Model theory Digital signal Motion capture Control flow Cryptography Befehlsprozessor Personal digital assistant Encryption Information security Firmware Address space
Email Injektivität Structural load Sheaf (mathematics) Medical imaging Cryptography Semiconductor memory Oval Information Personal identification number Injektivität Email Mass Bit Digital signal Control flow Opcode Electronic signature Endliche Modelltheorie Whiteboard Information security Reverse engineering Firmware Web page Game controller Implementation Functional (mathematics) Proxy server Computer-generated imagery Tape drive Maxima and minima Code Latent heat Read-only memory Motion blur Spacetime Data structure Atomic nucleus Firmware Proxy server Address space Disassembler Vulnerability (computing) Standard deviation Assembly language Information Forcing (mathematics) Cryptography Code Pointer (computer programming) Sheaf (mathematics) Table (information) Address space
Web page Reading (process) Game controller Observational study Computer-generated imagery Flash memory Range (statistics) Password Coprocessor Code Arm Number Writing Medical imaging Malware Cryptography Personal digital assistant Computer hardware Pairwise comparison Information security Firmware Booting Game controller Observational study Arm Web page Debugger Digital signal Opcode Cryptography Electronic signature Band matrix Preprocessor Hash function Personal digital assistant Computer hardware Password Order (biology) Interface (computing) Right angle Information security Block (periodic table) Multi-core processor RSA (algorithm) Reverse engineering Firmware Booting Address space
Reading (process) Game controller Flash memory Password Code Software bug Writing Read-only memory Different (Kate Ryan album) Semiconductor memory Hash function Motion blur Process (computing) Pairwise comparison Booting Firmware Information security Vulnerability (computing) Buffer overflow Personal identification number Game controller Key (cryptography) Structural load Web page Digital signal Electronic signature Code Order (biology) Whiteboard Game theory Information security Block (periodic table) Buffer overflow Address space Data buffer Booting Firmware
Patch (Unix) Computer-generated imagery Flash memory Password Electronic signature Code Subset Information retrieval Motion blur Backup Firmware Booting Email Key (cryptography) Mass Digital signal Control flow Numbering scheme Electronic signature Code Derivation (linguistics) Backup Information security Writing Reading (process) Firmware
Range (statistics) Numbering scheme Function (mathematics) Parameter (computer programming) Electronic signature Medical imaging Derivation (linguistics) Strategy game Single-precision floating-point format Formal verification Encryption Flag Backup Exception handling Source code Flash memory Data storage device Range (statistics) Mass Digital signal Numbering scheme Derivation (linguistics) Hash function Buffer solution Order (biology) Quicksort Information security Programmschleife Firmware Data buffer Booting Functional (mathematics) Game controller Computer file Computer-generated imagery Flash memory MIDI Password Code Number Software Motion blur Spacetime Firmware Operations research Execution unit Multiplication Key (cryptography) Image resolution Code Function (mathematics) Password Strategy game Revision control Backup Table (information) Address space
Default (computer science) Bellman equation Multiplication sign Password Phase transition Computer hardware Encryption Volume (thermodynamics) Table (information) Partition (number theory)
Source code Email Execution unit User interface Image resolution Flash memory Flash memory Range (statistics) Content (media) Software Programmschleife Online chat Booting
Laptop Crash (computing) Software Computer hardware Musical ensemble Shareware God
State observer Proxy server Flash memory Computer-generated imagery Password Electronic signature Code Medical imaging Read-only memory Compiler Revision control Spacetime Backup Encryption Volume Firmware Address space Firmware Booting
Computer font Key (cryptography) Patch (Unix) Computer-generated imagery Open source Password Drop (liquid) Code Code Error message Linker (computing) Read-only memory Compiler Order (biology) Data Encryption Standard Right angle Encryption Musical ensemble Volume Address space Hydraulic jump Surjective function Firmware
Computer font Computer file Patch (Unix) Computer-generated imagery Open source Password Drop (liquid) Data storage device Code Root Error message Linker (computing) Read-only memory Compiler Password Encryption Musical ensemble Volume Surjective function Firmware
Texture mapping Multiplication sign Range (statistics) Coroutine Numbering scheme Mereology Storage area network Medical imaging Cryptography Different (Kate Ryan album) Semiconductor memory Hash function Encryption Pairwise comparison Information security Exception handling Electronic mailing list Sound effect Range (statistics) Bit Maxima and minima Digital signal Port scanner Portable communications device Category of being Hash function Order (biology) Different (Kate Ryan album) MiniDisc Encryption Information security Advanced Encryption Standard Data structure Asynchronous Transfer Mode Firmware Booting Asynchronous Transfer Mode Implementation Game controller Computer-generated imagery Password Maxima and minima Data storage device Power (physics) String (computer science) Computer hardware Factory (trading post) Analog-to-digital converter Data structure Implementation Firmware Booting Game controller Default (computer science) Vulnerability (computing) Standard deviation Key (cryptography) Debugger Cryptography Mathematics Password Key (cryptography) Table (information)
Android (robot) Implementation Android (robot) Password Maxima and minima Core dump Digital signal Portable communications device Shareware Latent heat Multi-agent system Password Configuration space Encryption Configuration space Musical ensemble Information security Implementation Gamma function Information security Firmware
Patch (Unix) Debugger Programmable read-only memory State of matter Password Menu (computing) Online help Dynamic random-access memory Open set Local Group Escape character Befehlsprozessor Password Core dump Telnet Maize Information Musical ensemble Information security Information security Address space Data type
Intel Digital signal Portable communications device Advanced Encryption Standard Process (computing) Computer hardware Computer hardware Encryption Motion blur Encryption Data conversion Gamma function Information security
Implementation Digital signal Mereology Equivalence relation Flow separation Mathematics Software Personal digital assistant Software Software testing Software testing Data structure Information security Implementation Information security Vulnerability (computing)
Internetworking Musical ensemble
Revision control Game controller Group action Arm Software Computer file Computer hardware Encryption Cryptography Operating system Physical system
Point (geometry) Optics Sampling (statistics) Device driver Right angle Bit Information security
Implementation Software Open source Encryption Information security Firmware
Dependent and independent variables Telecommunication Lattice (order) Number
Implementation Distribution (mathematics) Interface (computing) Similarity (geometry) Measurement Number Medical imaging Uniform resource locator Centralizer and normalizer Core dump Traffic reporting Firmware Window Computing platform Social class
Implementation Functional (mathematics) Mapping Key (cryptography) Multiplication sign Information privacy Code Field (computer science) Number Radical (chemistry) Exterior algebra Software Logic Internetworking Computer hardware Statement (computer science) Encryption Musical ensemble Table (information) Window
[Music] 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 the detects you're using such a device BitLocker for instance will automatically use that device instead possibly stronger software crypto here to tell us more about that is Carlos Meyer
all right thanks so who is this guy well
I'm a PhD student at Radford University in MA my focus is on like cryptographic
stuff in the wild so basically breaking stuff that's blackbox you might know me for cryptographic attacks on my fret classic like the patched one and some algorithms in 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 like I can't thank Phillip Goering 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 it's awesome it's amazing so yeah cliche
what's the self encrypting drive so
traditional Christian is like you have a
plaintext you have an algorithm and a key and combined you get some ciphertext at you that that means nothing to you and 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 equip ssin and you should you just basically give to drive the data and the key and it will do everything for you now that sounds convenient but there's there are caveats that's 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 use that password to encrypt the key so the encryption is then instant so you don't have to be 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 it's basically software if you if you dive deep enough
there's if you look at a PCB then you might wonder what these 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 these
self encrypting drives haven't been like theoretically proven but they've been democratically proven in a sense that yeah there's there's is all this marketing fluff around it and well basically the the takeaway note is software encryption is way inferior to hardware encryption there's even studies released about it it's all it's great so even BitLocker trust these things by
default if your drive actually advertises support for this so I kind of
wonder what like 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 are three tackle 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 powered on machine this is very bad when you're using software encryption either the machine is off and there is no awareness of the the victim that the attacker has actually physically physical access to the machine and or the victim is actually aware that there is that there has been physical access to the machine so then you should that 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 from the physical encounter onward there is no 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's needed 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 previous state or you
could do DMA attack for example through thunder to turn or firewire and that kind of stuff and so hardware encryption is supposedly immune but so actually the key is kept in RAM and that is in order to support standby mode so if you if you put your PC in standby mode it turns it 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 kept in 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 in on many of them as we saw in a previous slide there's debugging interfaces on them so you can just use that and take the key out and given that the adversary is physical access you can basically just hop 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 machines off and the and the the the victim hasn't noticed that there has been a physical encounter then that's what we call the ego made attack so basically you're in your out and your laptop is in a hotel room and the and evil mate comes there and install some backdoor functionality so basically installed a backdoor functionality you wait for the victim to end your secret key and then you excavate the data or the key or whatever you want and so this can be Hardware key logger and there's not really meaningful defense this can be back door in the bootloader well you can actually defend against this with TPMS or 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 monitor when the thing is powered off or when you lose it or when your device gets stolen then and the attacker has physical access to it then software encryption actually provides proper security given that implementation is sound and if you use open source software which is audited by independent experts you have you have a pretty safe bet that your data is secure or if you use a proprietary software with some implementation details that are public and independently audited then you probably fine 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 just you only have that choice so and it's moreover it's extremely hard to audit and there's even additional pitfalls in the implementation that apply only to hardware encryption and not of software so basically to take away message 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 88 security feature set and dcgo pal it's a security feature set is actually something it'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 it for use the incoming password as a key for encrypting the stuff and TCO pal is actually designed for for use for usage in self encrypting drives so let's take
a look at the first well before we do that suppose that you have to implement it yourself like it'll 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 a 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 this this is how I would probably implement this so so far this is easy and so now if we go back to
88 standard as I said is it's predated
the sed era and 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 set in 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 drives contents and max means only the user can unlock to 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 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 keyed incoming user password and you you put that through keyed hash with a salt and then you get a hash result and you check whether the hash will whether the incoming password was valid and if so then you use another salt to generate a key which then decrypt an entry in this data structure which then decrypt another entry in this data structure and the reason for it is that if you want to erase the drive that you don't need both passwords so dcgo pal it's a it's like
more modern they say and so it's
actually a de facto standard for these kind of things there so there's a notion of multiple partitions which we call 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 like 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 uses this so well there's a couple of
typical pitfalls in this in the implementation of these things so
pitfall number one in yeah this is like the stupidest so you have an incoming password coming from the host PC and everything that ends up in the inner drives flash chips gets encrypted with some key so and in the middle there's a black box that basically 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 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 it pitfall number two is supposed you naively implement this scheme then you probably take a single key in order to access all two 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 it's it's you can you can 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 in this case even BitLocker leaves a single range on 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 be to become decrypted so in this case yeah everything's compromised so obviously there's 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 a we're 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 to make sure that that the flash tape doesn't wear down too stupid too quickly so you have a finite number of writing erase a 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 to make the service life as long as possible so therefore there is algorithm
in between that Maps logical sectors to physical sectors and if you write to successive times to the same physical sectors chances are that they end up at the to the same logical sector chances are that that they end up in a different physical sector so the old data are 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'd enter the password and then you overwrite the original key with an encrypted variant it's oversimplification but this space it's a basic idea but if you if there's we're leveling then the original data may still be there and therefore all you need and to in order to encrypt all the data is also still there so yeah that's basically what I just said pitfall number five in fact this is the final one there's this deftly mode and this basically means going to some power saving state so host PC sends a definite signal to the Stowers controller and the storage controller basically there's so there's there's no specified way in order how it is that defines how this power saving is to be achieved so it can be it can be achieved any way 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 or not being used it may 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 a general implementation issues that also apply to software that still apply in Hardware so stuff like mode of operations this probably rings a bell sorry annals key derivation etc that's all still there so what's our methodology
so a general approach it's it's actually
it's pretty ad-hoc the stuff that we did and there's that I mean you can't really fit it into a single model but we tried to make it as generic as possible so like there's this three-step program obtaining a firmware image gaining low-level control over the device or actually that means debugging it or getting code execution or and then analyze the firmware and see if you can find some some crypto implementation false yeah so obtain the firmware image and that like that that seems easy download it but that can be harder than seams because there's usually obfuscation applied so you need some vendor to from a from the manufacturer that uses SSL so you need to strip that and then then probably there's another layer of crypto applied just for obfuscation just to piss you off and so this is example of the Samsung magician which uses some some AES key that's hard coded and but it's not in the body of the filter of the executables you need to reverse that and it's annoying and any image itself may also be encrypted and if the decryption is performed on the unit itself then there's that's a dead end because you don't have the keys if it's not on the host PC and obviously you can perform the decryption yourself and so in that case you have to pull the firmware from ram to JTAG for example but that's not it's not a given that that's available so yeah let's let's let's take a deeper look into that so JTAG allows you to control the device like completely so 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 the plaintiff in plain sight so for example this one it's a 14 standardized pin layout others need some figuring out we
use this board called the jtagulator for it just basically brute force just a pin layout and if it's not there it can be turned off in many for many of these controllers then you need some code execution to be achieved so how do you do that well some vendors have undock commands that allow this some have phoner abilities in their firmware but like 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 tape that you may modify with external equipment and/or like 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 but I'll give you a couple of a couple of hints that that you probably want to 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 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 and then load the image into this assembler we use either Pro for this and then figure out the firmware does now it seems it's it's easier said than done so like one of the things that you probably want to look at is finding the ATA dispatch table so basically it's a table of structures that has at least an opcode and a function pointer that can that contains the implementation of that command and so basically that I haven't seen any a manufacturer that doesn't do it this way so if you find that table then you can actually look up any ath standard what every of one of these function implements and that's really convenient so if you want to go target it and you want to see what I what kind what kind of implementation is used for certain commands then go hunt for that table and yeah you'll probably find it in a couple of days so yeah look through function with interesting op codes like this can be vendor specific though it's those tend to be really interesting so without
further ado I will I will go into the case studies so the first one is the
crucial MX 100 it has some Marvell controller there's no documentation whatsoever so we used reverse engineering for all of it and it has a dual core yeah basically arm controller it's some proprietary design I believe and of course it has a hardware crypto processor in order to cope with the bandwidth of a TA because this thing obviously isn't powerful enough although it's quite powerful it's like in the range of a Raspberry Pi so further images they come as bootable ISO images so you can just yeah you can just take the firmware image out and it's plaintext everything's there there cryptographically signed oh 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 but by breaking the signature checks so the findings on these drives is well the incoming ATA password if you're using ATA 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 that's sufficient in order to break the encryption if you're using ATA security on this drive now with TCO pal you probably expect better but now then again so same story everything is the same and there's some interesting vendor commands but you need to unlock them first so you need just like this this this quirky command set some LBA to some magic value and use this feature code and this ATA opcode and then all of a sudden the big unlock the 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 like the serial number or 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 the arbitrary right so so summarizing the above it's great
you'll see so the the MX 200 is basically the
successor to this thing the JTAG pins have moved so it's kind of annoying to solder on them now so yeah that that 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 create the MX 300 though they really upped their game so they move to to a different kind of memory which is not really relevant in security but I thought I tell you anyway new controller and they turned off the JTAG 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 so bad and there's some buffer overflows and none of the numerix 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 you want code execution order to exploit some creative 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 is like if you want to 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 in the outside and it's located there on the board so
that's what we did you connected a reader to this thing so some wire is going on and convenient header and 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 that's some 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 drive will accept arbitrary firmware with invalid 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 through 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 your 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 RTS 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 cryptographic reinforced but you still need a single password in order to access all the ranges and all the keys for the all the all the unprotected ranges are actually stored in plain text so they don't then you don't get the RTS key from them so this could work at least like you need a single password which like in it let's be honest like that's the only reasonable scenario that you're going to use this in you're not going to 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 you already ascii 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 on some on some within some functions and we changed the behavior such that it just does the original behavior and also just puts it 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 in 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 RTS key from slot 1 basically decrypting it with the zero buffer execute that code on the device and then you have the RTS key but you're still up the air yet because there's still some 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 going to demo this let's pray
to the Democrats so yeah sorry so let me see I had this one this is flash one yeah so it detected my flash so it's actually it's actually on the desk here could someone please the team set camera maybe yeah so this is my USB SPI reader device and this is the crucial MX 300 and it's actually connected and there's this board in between and it's a it's a fancy jtagulator but it's just there to supply voltage sorry so 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 by make file that tells everything and it patches the firmware and now basically the firmware sort of SPI flash image is patched now so I have this 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 Wow and amou I'll show you video if 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 HD f HD f as you can see there's no dialogue asking you to - would you like hardware encryption whatsoever it's just 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 that I actually modified so it's okay it's just some some glitch so now I will remove this and remove the reader and plug this in
okay so oh wow like we're not panicked so while the laptops rebooting our beady
metaphorical chicken to be butchered to appraise the gods who here had a demo crash on stage hands up [Applause] [Music] of those was it hardware yeah was it software oh well alright how's it going back right yes [Applause] [Music]
can I get a picture maybe ah there we are great great so okay now that the the SPR
is flashed it should I accept our observed firmware images so I'm going to make an arbitrary favor image and it's over there and now I'm going to flash that so this is the command for flashing it HD parm yes I know what I'm doing please destroy my drive how great
doesn't work SDC yeah okay [Applause] okay so now okay so now I'm going to compile some code recover our DES key oh it's already there and then I'm going to use my tool tinker in order to to write that into Ram of the drive so by the way let's read out the RDS key oh oh wait uh-huh yes do you see this thing is zero so it's not loaded and so then you stinker to write this code into the address space then SDC yeah all right
successful okay now run it in folk jump successful and now redraw it again oh I can use this the RDS keys there okay so [Applause] [Music] cryptographically we won now though we have to unlock the drive so I'm going to use this just make a four byte 0 0 byte
file and then upload that to the drive do you see okay and now I should be able
to unlock this thing with any password oh you're right there we go
[Applause] [Music] [Applause] [Music] okay
that one's sort of okay 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 there's also they've also obviously implement the 80 a security feature set and they it by default it has an empty master password so you need to change that or set the master password capability set to max as I as you know so for Amex 300 its insufficient because if you have this custom firmware you you can basically set that variable in RAM to 0 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 840 Evo it's actually the first samsung drive that supports the teach gol standard it's a tweak or cortex all three for Omega L it's pretty powerful firmware updates are pushed through magician or a bootable ISO image and it's cryptographically signed and it has a JW 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 crunching table so there's in total there's 14 credentials you can define 14 credentials and it takes a password takes the first salt and then puts that through keyed hash and then you get a hash you know and you verify that hash and if it's 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 tables 14 times 9 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 entry and with that you get another key which is then used to decrypt these lists did an entry in this encrypted disk encryption key tables so this is how you probably implement Oh pal so they actually use a 64 K blob in order to store all of this data and then you get all of the the proper cryptographically enforced properties so congrats to Samsung they did it on the 88 security feature set though the dek only depends on the password in max mode so if you use high mode there's no cryptographic binding they're not there the password and the key is not related at all so you can just remove the password check and and do whatever you want so this 64k bit blob is stored somewhere and it's actually stored in where left of memory so you can just scan through the NAND and find an earlier copy of it if you're lucky there's a plaintext key in there and you can use that to unlock the drive and we actually did the same practice although it's pretty unlikely that you're gonna find this but if you find it then you're there and it effects obviously both both opal and TCL and 80's security because it's in the same data structure so on with the 850 it's a success to be a 40 of course and it uses a new go controller and different firmware obfuscation routines but that's sophistication it's all done it's all undone on the host PC but this one supports deaf sleep and that the me that made it interesting because we wanna take a look at their sleep as well and 8:40 didn't have that everything is pretty different and they did why 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 wear leveling issue they they fix that so now the t3 portable it's it's a portable drive based on the 850 it's actually the exact same thing it's just with a USB SATA convertor in front of it we're the t3 specific firmware that you can download but you can pull it from JTAG so it has a proprietary security command set so no ETA and no Opel proprietary stuff and aes-256 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 if you properly secured your your data this thing is actually the implementation of this D secure these proprietary commands are actually based on the ATA security implementation with the the master password capability sets a high so no cryptographic binding whatsoever you just can't you can just remove the password check so yeah hopefully going
to them with this as well so VirtualBox
[Music]
okay so access security enabled so yeah if I go into here there as far as I know this yeah this thing's connected yeah
it's not there so if I took 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 wait of course I have a cheat sheet there we go so this address wait no CT okay Gitex connected so now should be able to do this hang on okay so these are the course can now help CPU dump registers all of that it's amazing okay so let's put a breakpoint at this address so two Hardware resume okay so now if I enter an arbitrary password it will stumble upon that breakpoint and oh wait so I will now remove that drape that check now so you remove the breakpoint and then resume and there we go security disabled [Applause] [Music] [Applause] [Music]
so yeah that works
okay so apparently this thing is tough
to crack so some some very impressive shock resistant exterior this thing has and of course hardware is 256 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 gen2 on it supports Gen 2 but actually the hard way behind it it's pretty similar so it's equally vulnerable they just switched off the JTAG so it's just harder to exploit so the same thing in conclusion so most of
these self encrypting drives have some severe weaknesses best-case scenario it's going to be it's going to be equivalent to software not better and worst case it's it's all down the drain so on a further note teach the old pals terrible so so it's act is really over-engineered and they they had all of these kinds of features that nobody uses security goals are not clear like what 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's structural changes needed so
with that if you have any questions I'm happy to take them [Applause]
[Music]
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 there thank you very much for the sexy talk we'll start with our signal angel referring questions from the internet so do I are familiar issues and it's 508 is crucial tries one can try today the MX 500 in particular I didn't take a look at it because actually the MX 100
200 and 300 they they use some Marvel controller and the AMEX 500 it's 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 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 encryption so with BitLocker so the question was can I disable the the the BitLocker encryption dedicating 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 and with other operating systems they basically don't do this so so if you use like Linux or Mac OS X file vault it doesn't matter so particularly with BitLocker yeah they basically BitLocker is the only thing that does is except if you use it to all that advertisers like hey we're using the hardware crypto what
about the newest 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 Oh pal they screwed up 80 a security and with the 950 that the 950 is an nvme drive right so but they still support 80 a 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 it's a 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 driver that we can add to our collection we want to make it a bit more more broad so we want to make the sample that we have as accurate as possible
microphone optics 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 I mean there are efforts for open source firmware on these drives but they didn't get far as of yet so yet I mean you probably want that and 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 it's negligible so you can you can do this properly Samsung did this with opal as far as I know
because like if I am 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 gather together with Samsung and so we set up a meeting and we actually demonstrated all this stuff and then so they they were really kind to us so and also we contacted crucial for this it's just that yeah basically they responded they obviously they weren't happy with what we found but we they were very happy the way we reported it so yeah I mean I don't know what what can I say it's a responsible disclosure Thanks
number four please I thanks for a great
talk my question would be did you happen to take a look at mdme 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 we didn't added nvme sauce so the core of the implementation of everything is the same just the interface has changed so
but we did it included in our final research report because that's that's basically we're not trying to cherry-pick drives that are likely for honorable whatsoever so number one is how common are firmer updates for this class of devices are they distributed by Windows updates or similar measures or
are they only available if you install them manually so for for Samsung you have this tool called magician that checks for firmware updates definitely not through Windows Update though so yeah I think I think like it depends on your manufacturer but all of them do offer some 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 almost as these there is a function to calmly 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 not deeply enough I'd say well of course we did look at at some of these implementations like is the key actually written with random data and where does that data come from so yeah yeah we did that but like like for example if there's we're leveling you can probably still get the key out but then again all the tables like probably the the dfdl so the the the the physical to logical mapping tables probably destroyed and you get all that that kind of stuff so it will be really hard to recover data from this thing even if you had the key again microphone to please yeah thanks for your clear yet a kind of radical statement about self encrypting drives I'm wondering working in an Research Institute were I find more and more people going to use or demand these self encrypting drives for as they say practical reasons of data protection while working in the field and now I have learned just now that it software encryption is superior what do you recommend in a practical usage scenario for the three ecosystems Linux Windows as a software and a solution that is definitely superior to surfing cryptic drives I'd say veracrypt ok thank you are there any more questions [Applause] no more questions from the internet oh we have one question for at microphone number two yeah thanks for your research you said you actually disclose 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 open instrumentation is solid for crucial they basically told everybody yeah we released firmware updates I haven't looked into the MX 300 firmware update but for the MX 100 and 200 they basically just switch off the JTAG and remove some vendor commands that allow for the arbitrary write and 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 on in the same boat I think we're all out of time thank you very much Oscar Mayer [Applause] [Music] [Music]
Loading...
Feedback
hidden