Self-encrypting deception
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 165 | |
| 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 | 10.5446/39237 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
35C3 Refreshing Memories124 / 165
2
5
6
7
8
9
10
11
12
13
15
16
17
22
26
29
30
31
33
37
38
39
40
44
45
48
49
53
54
55
57
59
60
62
65
66
69
70
72
73
74
77
80
82
83
84
85
86
87
89
92
94
100
104
105
106
107
108
111
113
114
115
116
117
119
121
122
123
124
127
132
133
136
139
141
143
144
145
146
148
149
150
154
155
156
157
158
159
160
161
162
163
164
165
00:00
Operating systemCryptographyUsabilityInformation securitySoftwareMusical ensembleInstance (computer science)Lecture/Conference
00:57
Solid geometryEncryptionMotion blurNumerical digitStudent's t-testSystem programmingCryptographyMathematical analysisIndependence (probability theory)Information securityRouter (computing)Wireless LANPasswordElectric generatorDigital signalStudent's t-testFocus (optics)Universe (mathematics)Information technology consultingPasswordRouter (computing)Classical physicsBlack boxAlgorithmLecture/ConferenceUMLComputer animation
01:43
Digital signalMotion blurInformation securityReverse engineeringNumerical digitSoftwareEncryptionComputer-generated imageryReverse engineeringEncryptionData storage deviceKey (cryptography)Computer hardwarePasswordAlgorithmMoment (mathematics)Computer animationXML
03:00
ArmDigital signalInformation securityBefehlsprozessorDuality (mathematics)Numerical digitSoftwareEncryptionInclusion mapComputer hardwareEvent horizonInformationArmCore dumpSoftwarePersonal identification numberEncryptionComputer hardwareObservational studyXMLProgram flowchartComputer animation
03:57
Sign (mathematics)Motion blurInformation securityDigital signalSoftwareDefault (computer science)EncryptionComputer hardwarePhysical systemPoint (geometry)Random numberFactory (trading post)AuthenticationPasswordData recoveryData managementBootingEvent horizonEndliche ModelltheorieVirtual machineDefault (computer science)MultilaterationInformation securityTheoryVirtual machineSoftwareEncryptionModel theoryKey (cryptography)State of matterBootingGame theoryPasswordFocus (optics)Vulnerability (computing)Context awarenessPhysicalismXMLJSONComputer animation
05:25
Information securityDigital signalBootingComputer hardwareEncryptionImplementationFunction (mathematics)Installation artVirtual machineData storage deviceComputer hardwareMultiplication signEncryptionAsynchronous Transfer ModeLaptopBootingPasswordInterface (computing)SoftwareMinimal surfaceKey (cryptography)Game controllerFunctional (mathematics)RootkitOrder (biology)Virtual machineBackdoor (computing)State of matterModel theoryInformation securitySlide rulePeripheral2 (number)Software protection dongle
07:15
Information securityVirtual machineDigital signalEncryptionSoftwareComputer configurationOpen sourceImplementationComputer hardwareComputer hardwareEncryptionSoftwareInformation securityMessage passingBlack boxAxiom of choiceImplementationGame theoryExpert systemOpen sourceMathematicsElectronic program guideComputer animation
08:31
Standard deviationInformation securityDigital signalZugriffskontrolleExecution unitElectronic program guideStandard deviationInformation securityGame controllerPasswordSet (mathematics)Key (cryptography)ResultantHash functionFunction (mathematics)JSONComputer animation
09:37
Digital signalInformation securityStandard deviationZugriffskontrolleType theoryPasswordEncryptionMotion blurFactory (trading post)Maxima and minimaGreatest elementScalable Coherent InterfaceHash functionPairwise comparisonStandard deviationEncryptionInformation securityData structurePasswordType theoryKey (cryptography)ResultantLine (geometry)Process (computing)BitContent (media)Arithmetic meanHash functionTerm (mathematics)Maxima and minimaXMLComputer animation
11:08
Information securityDigital signalStandard deviationEncryptionMiniDiscComputer hardwarePartition (number theory)PasswordSingle-precision floating-point formatRange (statistics)Range (statistics)Standard deviationMultiplicationPartition (number theory)Independence (probability theory)PasswordTerm (mathematics)DatabaseXMLComputer animation
12:11
Flash memoryPasswordInformation securityDigital signalEncryptionSingle-precision floating-point formatEntire functionCryptographyPartition (number theory)Range (statistics)Random numberEntropie <Informationstheorie>LogicImplementationFirmwareCASE <Informatik>Partition (number theory)Numbering schemeRandomizationSingle-precision floating-point formatLink (knot theory)PasswordOrder (biology)SoftwareBlack boxLevel (video gaming)Finite setTape driveRange (statistics)Key (cryptography)Cycle (graph theory)NumberLogicFlash memoryBlock (periodic table)Table (information)Statement (computer science)WritingComputer animation
14:28
LogicPasswordMotion blurDigital signalInformation securityAsynchronous Transfer ModeCryptographyInclusion mapStandard deviationEncryptionSoftwareImplementationEntire functionAlgorithmOrder (biology)Video gameService (economics)Data storage deviceAsynchronous Transfer ModeGame controllerKey (cryptography)LogicPhysicalismRing (mathematics)NumberNon-volatile memorySoftwareMultiplication signImplementationPower (physics)MappingState of matterCASE <Informatik>Operator (mathematics)Derivation (linguistics)Computer hardwareFactory (trading post)PasswordEncryptionSpacetimeLecture/ConferenceComputer animation
16:35
Information securityDigital signalControl flowComputer-generated imageryFirmwareReverse engineeringMotion captureExecution unitEncryptionAddress spaceSpacetimeExecution unitCryptographyKey (cryptography)Reverse engineeringAddress spaceMedical imagingGame controllerStandard deviationPersonal identification numberSet (mathematics)Computer fileEndliche ModelltheorieCodeFirmwareImplementationModel theoryCASE <Informatik>Computer programBefehlsprozessorJSONXML
18:34
Digital signalInformation securityCodeControl flowSpacetimeAddress spaceEndliche ModelltheorieVulnerability (computing)Read-only memoryInjektivitätProxy serverCryptographyFirmwareMotion blurInformationSheaf (mathematics)Atomic nucleusMaxima and minimaEmailComputer-generated imageryMassDisassemblerStructural loadCodeElectronic signatureSemiconductor memoryProxy serverCryptographyWhiteboardVulnerability (computing)Personal identification numberOvalFirmwareMedical imagingForcing (mathematics)Tape driveInjektivitätGame controllerSheaf (mathematics)Functional (mathematics)Data structureImplementationBitOpcodeStandard deviationTable (information)Web pageAddress spaceReverse engineeringLatent heatInformationPointer (computer programming)EmailAssembly languageComputer animation
20:49
Observational studyCASE <Informatik>Game controllerDigital signalInformation securityCryptographyPreprocessorComputer hardwareArmComputer-generated imageryFirmwareRSA (algorithm)BootingInterface (computing)PasswordPairwise comparisonBlock (periodic table)Web pageReading (process)WritingAddress spaceCASE <Informatik>Observational studyRange (statistics)CodeWeb pageOrder (biology)Computer hardwareCryptographyMedical imagingElectronic signatureBand matrixBootingFlash memoryInformation securityArmFirmwareWritingDebuggerMalwareGame controllerPasswordRight angleHash functionOpcodeCoprocessorReverse engineeringMulti-core processorNumberComputer animation
23:15
Digital signalInformation securityMotion blurReading (process)Web pageWritingAddress spacePasswordPairwise comparisonBlock (periodic table)Read-only memoryGame controllerCodeBuffer overflowData bufferBootingHash functionProcess (computing)FirmwareBootingPersonal identification numberSoftware bugCodeKey (cryptography)Structural loadInformation securityBuffer solutionFirmwareWhiteboardDifferent (Kate Ryan album)Order (biology)Game controllerBuffer overflowFlash memoryVulnerability (computing)Semiconductor memoryGame theoryElectronic signatureComputer animationLecture/Conference
25:08
Digital signalMotion blurInformation securityCodeBackupElectronic signatureFirmwareInformation retrievalLevel (video gaming)Control flowComputer-generated imageryCodeFlash memoryFirmwareElectronic signatureBackupPatch (Unix)BootingLevel (video gaming)EmailSubsetReading (process)WritingComputer animation
26:02
MassPasswordNumbering schemeDerivation (linguistics)Digital signalInformation securityCodeInformation retrievalComputer-generated imageryFirmwareBackupLevel (video gaming)Electronic signatureControl flowRange (statistics)Function (mathematics)Motion blurExecution unitMIDIStrategy gameData bufferKey (cryptography)MultilaterationFlagEncryptionPasswordOrder (biology)Buffer solutionRange (statistics)NumberSingle-precision floating-point formatFirmwareCodeHash functionData storage deviceGame controllerFormal verificationFunctional (mathematics)MultiplicationFunction (mathematics)Parameter (computer programming)Derivation (linguistics)Table (information)Exception handlingMedical imagingNumbering schemeStrategy gameComputer fileComputer animationXML
29:00
Image resolutionProgrammschleifeOperations researchSource codeSoftwareRevision controlFirmwareSpacetimeAddress spaceElectronic signatureBackupFlash memoryComputer-generated imageryBootingFirmwareBackupFlash memoryVideoconferencingMedical imagingPlastikkarteQuicksortComputer fileComputer animationEngineering drawing
30:44
Bellman equationPhase transitionTable (information)Volume (thermodynamics)Multiplication signPartition (number theory)Default (computer science)EncryptionPasswordComputer hardwareComputer animation
31:54
Execution unitUser interfaceBootingImage resolutionContent (media)Flash memorySource codeSoftwareProgrammschleifeEmailOnline chatFlash memoryRange (statistics)Computer animation
33:21
LaptopKernel (computing)Lecture/Conference
34:18
Crash (computing)SharewareGodLevel (video gaming)Computer hardwareSoftwareMusical ensembleLecture/Conference
35:40
Address spaceSpacetimeRevision controlFirmwareElectronic signatureProxy serverBackupFlash memoryBootingComputer-generated imageryPasswordVolumeEncryptionCompilerCodeRead-only memoryError messageComputer fontSurjective functionLinker (computing)Open sourcePatch (Unix)Drop (liquid)Medical imagingFirmwareState observerOrder (biology)Address spaceData recoveryCodeRight angleKey (cryptography)Data Encryption StandardSource codeComputer animation
37:17
PasswordVolumeComputer-generated imageryFirmwareEncryptionError messageCodeCompilerSurjective functionRead-only memoryOpen sourceDrop (liquid)Key (cryptography)Raw image formatWritingHydraulic jumpMusical ensembleComputer animation
38:02
PasswordVolumeFirmwareComputer-generated imageryError messageEncryptionCodeCompilerRead-only memorySurjective functionLinker (computing)Open sourceDrop (liquid)Computer fontPatch (Unix)RootData storage deviceComputer filePasswordQuicksortMusical ensembleComputer animationSource code
38:54
PasswordFactory (trading post)Information securityDigital signalMaxima and minimaMathematicsComputer-generated imageryFirmwareBootingEncryptionRange (statistics)Data storage deviceTexture mappingHash functionStorage area networkImplementationAsynchronous Transfer ModePairwise comparisonData structureCryptographyKey (cryptography)Port scannerGame controllerDifferent (Kate Ryan album)Vulnerability (computing)Portable communications deviceEncryptionKey (cryptography)Information securityFirmwarePasswordBootingImplementationDefault (computer science)Multiplication signNumbering schemeData conversionData structureDebuggerRange (statistics)Maxima and minimaCryptographyCore dumpString (computer science)Different (Kate Ryan album)Social classStandard deviationBitComputer hardwareConfiguration spaceTable (information)Semiconductor memoryGame controllerOrder (biology)Advanced Encryption StandardMiniDiscCategory of beingAsynchronous Transfer ModeMereologyHash functionMedical imagingAnalog-to-digital converterPower (physics)CoroutineSound effectException handlingElectronic mailing listLecture/ConferenceComputer animation
43:24
Information securityDigital signalEncryptionPortable communications deviceFirmwareLatent heatAndroid (robot)Configuration spaceMulti-agent systemPasswordImplementationGamma functionSharewareCore dumpMaxima and minimaPasswordAndroid (robot)ImplementationInformation securityConfiguration spaceMusical ensembleComputer animation
44:12
MaizeProgrammable read-only memoryMenu (computing)Information securityInformationPasswordPatch (Unix)DebuggerOpen setEscape characterTelnetData typeState of matterDynamic random-access memoryLocal GroupInformation securityConnected spaceCore dumpPasswordOnline helpAddress spaceMusical ensembleBefehlsprozessorComputer animation
46:57
Gamma functionIntelInformation securityDigital signalPortable communications deviceEncryptionAdvanced Encryption StandardComputer hardwareMotion blurComputer hardwareEncryptionProcess (computing)Data conversionComputer animation
47:48
Digital signalInformation securityEquivalence relationSoftwareSoftware testingImplementationCASE <Informatik>Vulnerability (computing)Data structureSoftware testingInformation securityImplementationMathematicsMereologySoftwareFlow separationComputer animationJSONXML
48:37
Musical ensembleInternetworkingLecture/Conference
49:28
Computer hardwareArmGame controllerNumberEncryptionSoftwareCryptographyGroup actionPhysical systemComputer fileOperating systemLecture/Conference
50:52
NumberRevision controlBitSampling (statistics)Point (geometry)Right angleInformation securityDevice driverLecture/Conference
51:54
OpticsNumberSoftware developerInformation securitySoftwareImplementationFirmwareOpen sourceProper mapEncryptionLecture/Conference
52:45
Lattice (order)Dependent and independent variablesNumberTelecommunicationJSONXMLLecture/Conference
53:43
NumberCore dumpImplementationInterface (computing)Open sourceSocial classSimilarity (geometry)WindowMeasurementTraffic reportingLecture/Conference
54:29
Centralizer and normalizerWindowComputing platformDistribution (mathematics)FirmwareUniform resource locatorMedical imagingNumberWebsiteMusical ensembleFunctional (mathematics)Radical (chemistry)ImplementationField (computer science)MappingCodeTable (information)Statement (computer science)LogicKey (cryptography)SoftwareExterior algebraInformation privacyEncryptionMultiplication signInternetworkingComputer hardwareWritingSolid geometryLecture/Conference
Transcript: English(auto-generated)
00:05
One of the major pitfalls in any security solution is usability and one
00:23
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 a operating
00:42
system like Microsoft Windows and it 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.
01:06
Alright, thanks. So who is this guy? Well, I'm a PhD student at Radboud University in Nijmegen. My focus is on like cryptographic stuff in the wild, so basically breaking stuff that's black box. You might know me for cryptographic
01:23
attacks on my fair 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
01:46
with a few acknowledgments, like I can't thank Philip 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 awesome, it's amazing. So, yeah, cliche, what's the self-encrypting
02:05
drive? So traditional encryption is like you have a plaintext, you have an ciphertext 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
02:24
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 it sounds convenient, but there are caveats, that's probably why you
02:41
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 re-encrypt everything. So
03:02
basically, if you look up the spec sheets of these things, these aren't like there's firmware, it's basically software, if you if you dived even off, and if you look at a PCB, then you might wonder what these pins
03:22
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 like theoretically proven, but they've been democratically proven, in a sense that, yeah, there's all
03:41
this marketing fluff around it, and well 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
04:06
of wonder, like what are the actual security guarantees of these things? Well, just taking a 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 the machine is on, and the attacker has physical access to a
04:25
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 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
04:44
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, 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. So software encryption
05:05
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 a cold boot attack, for example. I won't go into this in too much detail, but basically you load
05:20
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 actually the key is kept in RAM, and that is in order
05:43
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 need to be unlocked again, and you don't have to enter a password. So it's actually kept in RAM all the time. And also a key is kept in storage
06:05
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
06:21
given that the adversary has physical access, you can basically just hot-block 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
06:43
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 backdoor functionality. So basically, you install the backdoor functionality, you wait for the victim to enter a secret key, and then you exfiltrate the
07:01
data or the key or whatever you want. And so this can be a hardware keylogger. There's not really meaningful defense. This can be a backdoor in the bootloader. Well, you can actually defend against this with TPMs or a secure boot. But when a hardware encryption enters the game, it doesn't change anything. So it's still
07:21
equivalent. It's not superior. And then we end up at our last scenario. 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
07:43
open-source software, which is audited by independent experts, 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're probably fine as well. Or you can just live on the edge and use a black box
08:04
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
08:21
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
08:42
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 it for use the incoming password as a key for encrypting the stuff. And TCG-OPAL is actually designed for usage in
09:05
self-encrypting drives. So let's take a look at the first. Well, before we do that, suppose that you had 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
09:20
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 SED era. So
09:45
encryption is not mentioned anywhere at all. And there's two types of password, user and master. And both are user-setable, actually. But the master password is set during the manufacturing process. So there's some setting. It's called the master password capability bit.
10:03
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,
10:23
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
10:41
have an incoming keyed, incoming user password. And you put that through keyed hash with assault. And then you get a hash result and you check whether the hash, whether the incoming password is valid. And if so, then you use another assault to generate a key, which then decrypts an entry in this data structure, which then decrypts another entry in this data
11:01
structure. And the reason for it is that if you want to erase the drive, then you don't need both passwords. So GCD-OPAL, it's like more modern, they say. And so it's actually a de facto standard for these kind of things. So there's a notion of
11:20
multiple partitions, which they 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
11:41
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
12:03
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.
12:24
So you have an incoming password coming from the host PC, and everything that ends up in the drive's flash chips gets encrypted with some key. And in the middle there's a black box that basically links one to
12:41
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
13:01
this scheme, 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,
13:22
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
13:41
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.
14:01
And so, yeah, these things in embedded devices tend to be badly implemented. And there's a wear leveling issue, which is kind of interesting. So multiple writes to the same logical sector trigger writes to different physical sectors. That's basically in order to make sure that the
14:20
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
14:42
to physical sectors. And if you write two successive times to the same physical sector, chances are that they end up to the same logical sector, chances are that they end up in different physical sectors. 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
15:02
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 wear 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.
15:22
So, yeah, that's basically what I just said. Pitfall number five, and this is the final one, there's this dev sleep mode, and this basically means going to some power saving state. So host PC sends a dev sleep signal to the storage controller, and the storage controller, basically there's no
15:43
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.
16:02
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 stored in non-volatile storage at all. So, yeah, there's a couple of scenarios where we looked at this.
16:21
And finally, there's general implementation issues that also apply to software that still apply in hardware, so stuff like mode of 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,
16:41
it's pretty ad hoc, the stuff that we did, and there's, 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
17:02
analyze the firmware and see if you can find some crypto implementation files. So obtaining a firmware image, that seems easy. Download it, but that can be harder than it seems, because there's usually obfuscation applied,
17:20
so you need some vendor tool from the manufacturer that uses SSL, so 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 executable,
17:42
so 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 not on the host PC, then obviously you can perform the decryption yourself. So in that case, you have to pull the firmware from RAM
18:03
through 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,
18:23
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, just basically brute forces the pin layout,
18:41
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 a firmware image, then you can't find these, obviously.
19:02
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, or 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,
19:22
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 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
19:42
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 IDA Pro 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
20:03
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 contains the implementation of that command, and so basically, I haven't seen any manufacturer that doesn't do it this way,
20:21
so if you find that table, then you can actually look up in the ATA 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.
20:42
So yeah, look through a function with interesting opcodes, like these can be vendor specific, 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,
21:01
so we use reverse engineering for all of it. It has a dual core, basically ARM controller, it's on proprietary design, I believe, and of course, it has a hardware crypto code processor, in order to cope with the bandwidth of ATA, because this thing obviously isn't powerful enough, although it's quite powerful, it's like in the range of a Raspberry Pi.
21:22
So firmware images, they come as bootable ISO images, so you can just take the firmware image out, and 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 if you want, you can still flash it
21:40
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.
22:00
Remove the check, and then access the data. That's enough. That's sufficient in order to break the encryption if you're using ATA security on this drive. Now with TCG-OPAL, you probably expect better, but nah, then again. So same story, everything's the same. There's some interesting vendor commands,
22:21
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 ATA 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,
22:41
or erase, or write it to it, and the SPI flash actually contains like 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,
23:02
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.
23:25
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,
23:43
so they moved to a different kind of memory, which is not really relevant in security, but I thought I'd tell you anyway. A new controller, and they turned off the JDAC, and they also completely rewritten the security code. So, oh yeah, by the way,
24:03
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.
24:21
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,
24:42
and basically that loads the firmware from NAND. So yeah, if you want to take off the NAND and modify the firmware in NAND, that's really annoying, like it's a BGA chip, like over a hundred pins, so how about we look at the SPI flash,
25:01
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,
25:20
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 but 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,
25:44
and then the drive will accept arbitrary firmwares 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.
26:03
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,
26:21
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,
26:41
everything else is just if statements. So yeah, this is prevented by the firmware, but it's not actually cryptographically 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.
27:01
So this could work, at least you need a single password, which let's be honest, that's the only reasonable scenario that you're going to use this in, you're not going to use multiple passwords, multiple ranges, but we still found a way around it. So consider the password protection function,
27:21
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, the output actually contains the RDS key encrypted with your password, so you shouldn't really be throwing around the output of this thing.
27:40
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.
28:01
So what you get from that is this fancy log file, and 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
28:21
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,
28:41
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.
29:00
So now I'm going to demo this. Let's pray to the demo cards. So yeah, I'm sorry. So let me see. Oh yeah, this one.
29:21
Let's see. Yes, flash one. Yeah, so it detected my flash, so it's actually on the desk here. Could someone please change the camera maybe? Yeah, so this is my USB SPI reader device, and this is the Crucial MX300,
29:44
and it's actually connected, and there's this port in between, and it's a fancy JTAG later, but it's just there to supply voltage. Sorry. So yeah, I created a cheat sheet though.
30:04
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 going to... Okay, so yeah, this is my makefile that does everything, and it patches the firmware,
30:20
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.
30:42
So that will take a while. In the meanwhile, 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 detects it, and let's create an empty partition table.
31:06
New volume, NTFS, everything default,
31:25
and then we enable BitLocker. So spoiler alert, the password is hdfhdf. As you can see, there's no dialogue asking you to...
31:41
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.
32:59
Yeah, okay, so that's probably...
33:01
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.
33:29
Okay, so... Oh wow, my kernel panicked.
34:18
So while the laptop's rebooting, I'll be the metaphorical chicken
34:22
to be butchered to praise the gods. Who here had a demo crash on stage? Hands up.
34:42
Of those, was it hardware? Yeah, was it software? Well, how's it going? Ready?
35:05
Can I get a picture maybe?
35:36
Ah, there we are. Great, great.
35:44
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, and it's over there, and now I'm going to flash that. So this is the command for flashing it.
36:01
HD parm, yes, I know what I'm doing. Please destroy my drive. Oh great, it doesn't work. SDC, oh, okay.
36:28
Okay, so now I'm going to compile some code,
36:42
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.
37:00
Oh, wow, what's, 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, raw write successful.
37:24
Okay, now run it, invoke jump successful, and now read it out again. Oh, I can use this.
37:40
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,
38:04
and then upload that to the drive. Okay, and now I should be able to unlock this thing with any password.
38:25
Oh, you're right. There we go.
38:52
Okay, that went sort of okay-ish.
39:07
So they claim this is the best in class hardware encryption. Yeah, I'll leave that up to you whether that's true. So they also obviously implement the ATA security feature set,
39:21
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.
39:44
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 THGOPL standard. It's a three core Cortex R3, 400 megahertz, pretty powerful.
40:00
Firmware updates are pushed through Magician or a bootable ISO image, and it's cryptographically signed. And it has a JTAG 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.
40:22
So 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 a keyed 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.
40:43
That table's 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 an entry
41:02
in this encrypted disk encryption key table. So this is how you properly implement Opal. 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.
41:24
So congrats to Samsung, they did it. On the ATA 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, the password and the key is not related at all, so you can just remove the password check
41:43
and do whatever you want. So this 64K bit blob is stored somewhere, and that's actually stored in wear-level 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,
42:02
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 TCL and ATA security because it's in the same data structure. So on with the 850, it's a success to the 840, of course.
42:23
It uses a newer controller and different firmware obfuscation routines, but that's obfuscation, it's all undone on the host PC. But this one supports DevSleep, and that made it interesting because we wanted to take a look at DevSleep as well, and 840 didn't have that.
42:41
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 wear-leveling issue, they fixed that. So now the T3 portable, it's a portable drive based on the 850.
43:02
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 Opal proprietary stuff. And AES-256 is a big part of its marketing.
43:23
And so there's this configuration tool that they ship. It actually supports Android. I think it's kind of cool if it properly secured your data. This thing is actually, the implementation of these proprietary commands are actually based on the ATA security implementation
43:41
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.
44:24
Okay, so it says security enabled. So yeah, if I go into here, as far as I know, yeah, this thing's connected. Yeah, it's not there. So if I do this, yes.
44:44
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.
45:02
Oh wait, of course I have a cheat sheet. There we go. So this address,
45:21
OpenOCD. Okay, JTAG's connected. So now I should be able to do this.
45:42
Hang on. Okay, so these are the cores. Can now help CPU, dump registers, all of that.
46:00
It's amazing. Okay, so let's put a breakpoint at this address. So to 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
46:33
and obviously remove the breakpoint and then resume. And there we go. Security disabled.
46:59
So yeah, that worked.
47:05
Okay, so apparently this thing is tough to crack. So some very impressive shock-resistant exterior this thing has and of course hardware ES256 encryption.
47:20
So yeah, I hope the exterior does a better job. So on with the T5, it's basically a T3 actually with a different converter. So rather than USB 3.1 Gen 1, it supports Gen 2. But actually the hardware behind it is pretty similar.
47:41
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.
48:04
So on a further note, TCG-OPAL 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.
48:23
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.
48:51
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 this excellent talk.
49:04
And we'll start with our signal angel referring questions from the internet. Thanks for your talk. I hope you're going to see me smiling. So do I. Are there similar issues on MX500 and latest crucial drives one can buy today?
49:25
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.
49:40
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?
50:02
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.
50:22
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, Falvop, it doesn't matter. So particularly with BitLocker,
50:43
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.
51:00
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, the 950 is an NVMe drive, right? So, but they still support ATA security. And nobody in their right mind would use that,
51:21
but they support it, and you can actually use it. But I don't think it's actually really interesting to look at all of these Samsung drives. 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,
51:41
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?
52:04
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.
52:20
So yeah, I mean, you probably want that. But then if I made, like, why would you want self-encrypting drives? They're not in any way better. Just use software encryption. It's fine. And even for performance, you have these AES instructions that everyone has now. So for performance, it's negligible.
52:41
So you can do this properly. Samsung did this with Opel, as far as I know, because 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.
53:04
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.
53:20
And so they were really kind to us. 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?
53:41
It's a responsible disclosure. 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.
54:01
And it's basically the same thing, just with an added NVMe source. 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 basically, we're not trying to cherry pick drives that are likely vulnerable whatsoever. So number one, please.
54:23
How common are 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.
54:42
Definitely not through Windows update, though. So yeah, I think 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.
55:01
Number two, please. On most STs, 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.
55:23
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 for example, if there's wear leveling, you can probably still get the key out. But then again, all the tables, like probably the FTL,
55:45
so the physical to logical mapping tables probably destroyed, and you get all that kind of stuff. So it'll be really hard to recover data from this thing, even if you had the key. Again, microphone two, please.
56:00
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
56:25
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,
56:41
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?
57:04
No more questions from the internet? Oh, we have one question for 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 released a statement, basically saying,
57:24
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.
57:45
I haven't looked into the MX300 firmware update, but for the MX100 and MX200, 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,
58:03
you're back in the same boat. I think we're all out of time. Thank you very much, Oscar Mayer.