Got HW Crypto? On The (in)security Of A Self .

Table 4: My Passport VSC examplesCommand aliasCDBstatusstatus (OX)handystorec0c0d8c1unlock454500e1Associated data 03000000000200128c1 e2 00 00 00 00 00 00 48setpwc1 e2 00 00 00 00 00 00 48removepwc1 e2 00 00 00 00 00 00 48changepwerasec1 e3 4 * RNG 00 00 2845 00 00 32-byte45 00 0000 * 32 32-byte45 00 00 32-byte00 * 3245 00 00 32-byte 32-byte45 00 00 32-byte00 00 00 00 20KEK 01 00 00 00 20new KEK 10 00 00 00 20current KEK 00 00 00 00 20current KEK new KEK 01 20 00 01 00DEK material 2.3 Authentication and data confidentialityFor those My Passport drives that support HW encryption by the USB bridge (see Table1), the chipuses an AES-128 or AES-256 bit key to encrypt user data before storing it on the HDD. This data-keywill from now on be called the DEK . The models tested in this paper come with a default, factory set,AES-256 DEK. The factory default setting lacks a user provided password for obvious reasons and thusgives everybody access to decrypted data. Transparent to the user, user data is always encrypted usingthis key. Any user can now choose to set a password, which will produce a KEK, used to protect theDEK and some additional data. For this case the device requires a successful password authenticationbefore giving access to the user data (see Figure 3).A factory set DEK is protected with a default, static ”password” or hashvalue as we will see later inSection 2.4. This Key will be called KEKs . Note that KEKs is constant over all tested chips and canbe found hardcoded in the bridge’s firmware. This basically means no protection for the default case, asexpected.Once a MP disk is plugged in a host computer, the respective USB bridge will test if the disk is passwordprotected. This is done by trying to unlock the encrypted DEK, using KEKs from Table 5. If successful,the DEK is fed to the Hardware AES engine and the chip presents the host with a new logical disk unit(LUN5 ). The host only receives decrypted data and will mount the disk as a regular unencrypted HDD.Failing to decrypt the DEK with KEKs means the disk is protected by a user supplied password (usually). In this case the USB bridge presents a different LUN to the host computer containing a VCD tothe host. This contains a GUI-based software to unlock the disk. This unlock software runs on the hostcomputer (currently Windows and Mac supported) and asks the user for a password to unlock the disk.The user supplied password given to the software is used to generate a KEK that is used to decrypt theDEK , as described in Figure 3.5Logical Unit Number6

Figure 3: Standard authentication and encryption setup for My Passport devicesHost computerMy PassportSalt user ser dataDEK256-bitAESECB/CBCencrypteduser dataTo summarize, given the correct password the correct KEK will be generated and the correct DEK willbe decrypted and the LUN with user data is mounted with transparent on-the-fly decryption of data.Note that this might be different for chips which do not support HW AES encryption. Here the AESencryption is moved in the SATA chip. The USB-to-SATA bridge might perform user authentication /KEK verification (INIC-3608) or it will forward the KEK to the SATA chip for verification (JMS569)using standard ATA command SECURITY UNLOCK - F2h [13].2.4 The Key Encryption Key (KEK) derivationThe KEK is a hash, derived from the user password. As discussed in Section 2.3, only the correct KEKunlocks the external MP.This means that an attacker in possession of the KEK, can authenticate successfully to the disk anddecrypt all data. He sends the VSC command unlock from Table 4 and gains access to the mounteddecrypted data. The KEK is generated by software on the host and sent via a VSC to the USB chip, anattacker does not need to know the actual user password which produces this KEK. The default KEKlength is 256 bits (32 bytes).Table 5: My Passport default KEKs (”PI” keys)Algorithm protecting DEKDefault KEK (hex)AES-256-ECB03 14 15 92 65 35 89 79 32 38 46 26 43 38 32 79FC EB EA 6D 9A CA 76 86 CD C7 B9 D9 BC C7 CD 86AES-128-ECB03 14 15 92 65 35 89 79 2B 99 2D DF A2 32 49 D6If the user chooses to set a password, the KEK is generated from mixing a salt and a password to producean AES-256 KEK:7

The Key Derivation Function (KDF): Generation of the KEK is using SHA256 with the saltedpassword as input, iterated x times. The USB bridge firmware supports configuring this iterator,like the salt. So each password set could define it’s own iterator count x.The default iterator count of 1000 is hardcoded in the Western Digital software used to managethe HDDs. The function of the iterator x is to make password guessing infeasible, by beingcomputationally expensive; running x times for one password guess. The salt: The USB bridge firmware supports setting a random salt for each password set. This saltcan, and should, be retrieved from the disk via a VSC before doing authentication. The primaryfunction of a salt is to defend against pre-computed dictionary attack hashes and pre-computedrainbow table attacks. The salt does not need to be kept secret.This salt is default set to ”WDC.” for any MP device. Further, this salt is hardcoded in the WesternDigital software used to manage the disks. The salt never changes, even if the user changes his/herpassword.This means that the current use of the salt does not function as designed. The password: The password is user supplied and is appended to the salt.The static iterator, together with the static salt allows an attacker to pre-generate large sets of possibleKEKs from a password dictionary, and save valuable cracking time. Example of generating a KEK fromuser password ”abc123” is shown in Algorithm 1.Algorithm 1 KEK generation from password ”abc123”Counter 0KEK ”W DC.abc123”while counter 1000 doKEK SHA256(KEK)counter 1end whileThe final KEK (hex) 82 44 bc 08 9c 4a ab 5e 53 aa ec 57 ae 90 19 a7 3f 3ca0 6e de 80 7a 70 5b bb a7 10 cf 7c 3a c8In our opinion, the KEK should never be stored, regardless of the circumstances.2.5 The DEK - Data Encryption KeyThe DEK is the holy grail.The DEK is the AES key used to encrypt all user data. Every user writeable sector on disk is encryptedusing this key. This excludes the unencrypted VCD partition and the HDD Service Area (SA).If an attacker can get hold of the DEK, he/she can decrypt all user data on the disk, regardless of theuser password and KEK.An attacker obtaining the correct DEK can bypass the USB bridge, read the raw disk sectors and decryptuser data manually. Reading the raw encrypted disk sectors can be done for example by connectinga PC-3000 [5] to the serial interface, disabling/removing the bridge firmware chip (EEPROM U14) to8

enable USB-SATA direct bridge (see Section 3.1) or by soldering the SATA interface directly on thePCB [4].The DEK is for some chips stored encrypted in the USB EEPROM, U14, in a hidden sector on the harddrive and in some cases in the SA of the hard drive. Within the SA the encrypted DEK, eDEK, is storedin module 0x25 (ROYL) for JMS538S and INIC-1607E and module 0x38 for SW6316. The encryptedDEK blob is easily identified, starting with the magic ASCII bytes WDv1 for JMS538S, SYMW for theSW6316, SInE for OXUF943SE and WDx01x14 for INIC-1607E models. For any other unknown chipit should be easily identifiable, searching for a small blob with high entropy within the last sectors of theHDD . Even when the location of the DEK is known, dumping it might be slightly different for variousmodels and HDD sizes.See Appendix B for examples of encrypted and decrypted DEK blobs.9

3 Security weaknesses for every analyzed My PassportThis chapter will discuss security weaknesses discovered on every analyzed device, facilitating attacksto recover the eDEK and unauthorized tampering by an attacker with no knowledge of user credentials.The discussion of the weaknesses of the individual devices to recover the DEK is covered in Sections 4,5, 6 and 7.3.1 Dumping the eDEKIf we are able to get our hands on the eDEK, we can create a backup of our own eDEK, to be keptin a safe place. But this obviously also allows effective off-device password brute force attacks, likediscussed in Section 2.4.As already mentioned, the USB bridge has a supporting EEPROM, named U14 (U8 on SYMW6316) onthe PCB. This memory contains crucial info for the USB bridge namely, the firmware, possibly a copyof the eDEK and various configuration blocks. One obvious method of dumping it is to de-solder it andto read out the eDEK directly, as the U14 is a very simple and widely used EEPROM.On some models we were able to read out the eDEK through an undocumented VSC. However this onlyworks if the device is unlocked. Nevertheless this did not work on all models so we looked for otherways. It turns out that reading out the hidden HDD sectors is easier than de-soldering the U14 chip.3.1.1JMS538SNote that if we remove or disable the U14 on the PCB, the USB bridge will fall back to a ”blind” USBto SATA bridge mode, not being able to load the custom firmware. This is similar to soldering the SATAinterface to the PCB [4]. A model with VID:PID 1058:0748 will show up as a device with VID:PID152d:0539 instead, indicating vendor name JMicron Technology Corp. / JMicron USA Technology Corp.(0x152d) and product id 539. With the bridge in ”blind” USB to SATA mode, the hard drive reveals it’strue sector count, which is a few thousand sectors more than is reachable through the Western Digitalfirmware. The reason is that the USB bridge, loaded with Western Digital firmware, keeps some sectorsat the end of the disk hidden and not user reachable. The USB bridge stores another copy of the eDEKin this hidden area of the hard drive.So we can access another copy of the eDEK, if we trigger the blind USB to SATA mode. We needto make the USB bridge think the U14 EEPROM is unreachable during power-up, when the firmwareshould be loaded. This can be accomplished by removing the chip, or by simply making the USB bridgefail to read from it during power-up. Failing to read from the U14 can be accomplished by shortingthe data IN (DI) or data OUT (DO) pins of the EEPROM to ground, and with this enforce blind mode.Although this method is not recommended by responsible hardware technicians, none of the disks testedhad their U14 EEPROM damaged during the numerous tests performed during our research.Reading out the eDEK is now done by reading out the last few thousand hidden sectors from the harddrive, searching for the magic WDv1 ASCII bytes.One big advantage of this approach is that one of the data IN (DI) or data OUT (DO) is reachable on theback of the exposed PCB on the My Passport device, without detaching the PCB from the hard drive. So10

simply removing the hard drive from the enclosure and knowledge of the location of the data IN (DI) ordata OUT (DO) is all that is needed to reach the eDEK.3.1.2INIC-1607EOn the tested model, disabling the U14 EEPROM trick makes the bridge go into ”download mode”,accepting new, and freely patched firmware to the U14 EEPROM.This is of course a weakness in itself, since now any attacker can update the firmware on any locked disk,executing an evil maid attack [1]. However, we used this trick to get hold of the eDEK without havingto use expensive tools like PC-3000. We simply made a 3-byte patch of the firmware (including the 1byte CRC update) which gives us back the eDEK when the handystore VSC is executed. Normally thisVSC reads a hidden sector on the HDD where the non-sensitive user parameters are stored (passwordhint, salt and KDF iterator). One can simply change the disk offset to the location of the eDEK instead.3.1.3OXUF943SEOn the tested OXUF943SE model (PID: 0x071d) no U14 trick is necessary, since the OXUF943SE islocated on a separate PCB from the hard drive. Reading the hidden sectors can be done simply byconnecting to the HDD SATA interface directly, reading out the last few thousand sectors. Additionallyit is possible to calculate the eDEK from an intermediate leaked decrypted DEK (which is not the realDEK). This is can be done an undocumented SCSI VSC that probably was not meant to expose RAM,but can be abused for this purpose. The VSC command to read RAM is not included, to comply withthe responsible disclosure model [11]. The RAM leakage is discussed in more detail in Section 6.1.3.1.4SYMW6316Disabling the U8 EEPROM on this chip makes it go into bridging mode, too. However, we didn’t fullyinvestigate a way to expose the eDEK through this mode, but the code for this mode is contained inthe U8 EEPROM. We couldn’t read data directly from the HDD. For this chip we get the eDEK from alocked disk through the serial interface and the use of HDD recover tools like PC-3000.3.2 Unauthorized modification of firmware and Virtual CDIn addition to the standardized Western Digital set of VSCs, all chip models have their own, nonstandard, set of low level VSCs to support e.g. firmware and Virtual CD (VCD) upgrades.Our research discovered that the firmware and VCD iso that is flashed to the My Passport devices arenot digitally signed and revealed the existence of VSCs that can be used to update both the USB bridgefirmware and VCD. The U14 EEPROM and VCD located on hard drive can also be modified directlyby an unauthorized attacker. In the case of the U14 EEPROM, a 1- or 2-byte CRC-checksum is the onlymeasure to ensure data integrity.This facilitates an evil maid [10] type of attack for stealing user passwords, e.g. by tampering thefirmware to log valid KEKs used on the device, for later collection by the attacker. Another arising11

attack vector is a trojan based attack like in the badUSB [1] project or Stuxnet [12] to attack the wholehost system and spreading of malicious code in the network. This does require modification of the U14EEPROM chip directly, since the VSC to modify firmware will not work on a locked disk.This was tested successfully on a JMS538S device, modifying the firmware to change how the MyPassport identified itself to the host computer, and by modifying the VCD to execute cmd.exe insteadof the Western Digital unlock executable. Note that the unlock executable by default requires adminprivileges on Windows, which makes it a dangerous executable to modify. Modifying this has also beensuccessfully tested and verified to work.One big challenge with infecting the firmware, is that it is very hard to clean. It’s also harder for anyattacker to self-destruct any firmware changes, to cover tracks.A malicious attacker can easily spread to new hosts by infecting the firmware of any connected andunlocked device.The VSC commands to modify the firmware and VCD are not included, to comply with the responsibledisclosure model [11].12

4 JMicron bridgesWD uses two different JMicron bridges in their different hardware models. While the JMS538S, usedin slightly older models, supports the chip hardware AES encryption, the newer JMS569 does not haveany supported hardware co-processors or accelerators.4.1 JMicron JMS538S - Cracking crypto the poor RNG wayThe JMicron JMS538S USB to SATA bridge is used by many MP models. It is in fact one the oldest MPbridge known and has an AES-128 and AES-256 accelerated ASIC to support data en- and decryption.This allows on-the-fly data encryption for USB transfer speeds. The JMicron will be discussed in moredetail in the next few sections, as this MP inherits a rather complex vulnerability compared to the othermodels.4.1.1Authentication phaseThe authentication is done by trying to decrypt the encrypted DEK (WDv1) blob with the given KEK andcheck for a known ASCII string ”DEK1” at the start of the decrypted DEK blob. If the correct string isfound, authentication is considered successful and the DEK contained in the decrypted blob is fed to theHW AES crypto engine. The disk LUN is presented to the host computer, like described in Section 2.3.The authentication scheme can be found in Algorithm 2. An examples of an encrypted and decryptedWDv1 blobs can be found in Appendix B.As we did not find any further information regarding the DEK or KEK, we consider this authenticationscheme safe. To further analyze the security of the JMS538S, we concentrate at the actual DEK generation. Key generation and RNG schemes are a crucial part of any secure cryptographic setup. If keygeneration fails, cryptography fails.Algorithm 2 generic KEK validation for JMS538S, OXUF943SE and INIC-1607Efunction VALIDATE KEK(KEK)DEKE G ET E NCRYPTED DEK()DEKD HW AES DECRYPT (KEK, DEKE )if IS VALID DEK(DEKD ) thenHW AES S ET K EY (DEKD )M OUNT U SER DATA D ISK ()W rongT ryCounter 0return T rueelseW rongT ryCounter if W rongT ryCounter 5 thenL OCK D EVICE ()end ifreturn F alseend ifend function13 AES Key KEK, Data DEK Device needs restart (Power cut)

4.1.2DEK generation and low entropy key materialA common question with all encryption schemes is how they generate the secret key material. Doneproperly, it should be as infeasible to attack as bruteforce of the actual key. The MP devices comeswith pre-installed factory default keys, set in production. In early stages of the research we couldn’tsay anything about the generation of these pre-computed keys, leading to the results in the followingsubsections. However, it later turned out that even the factory set keys are vulnerable. We’ll come tothat in section 4.1.6.In theory, nothing prevents the vendor from storing factory set keys, or creating them in a predictableway to be reproduced by an attacker. This might lead paranoid users to create new key material, a newDEK on their devices. Furthermore, in the case that a user forgets his/her password, there needs to bean option to reset and erase the device. This results in losing all user data stored, but making new use ofthe device.The MP host and virtual CD software supports erasing the drive after typing the wrong password fivetimes. If the user decides to erase, the erase VSC must provide new key material to the device. Thegeneration of key material follows the basic steps outlined in Algorithm 3. Basically the device is fedkey material from two sources: the host computer and the embedded device itself.The VSC used to erase the drive has a flag to signal the My Passport device to use or discard key materialreceived from the My Passport on-device random number generator, RNG, using the host supplied keymaterial as a raw DEK directly. The default setting, not configurable from software, is set to includeboth sources of key material.Algorithm 3 DEK generation on JMicron 538Sfunction G ENERATE DEK(HostSuppliedBLOB)// Key material bytes provided by host computerKeyBytesHost HostSuppliedBLOB[8 : 8 KeyLength]// Host computer decides if on-board RNG generated key material should be mixed inbM ixKeyBytesHost HostSuppliedBLOB[3]if bM ixKeyBytesHost 0x01 thenfor i 0; i KeyLength; i do// Mix key material from host computer with My Passport on-board RNGDEK[i] KeyBytesHost[i] HWRNGB YTE ()end forelsefor i 0; i KeyLength; i do// Use host supplied key material as raw DEK keyDEK[i] KeyBytesHost[i]end forend ifreturn DEKend functionBoth of the key material sources will be analyzed in the following sections.14

4.1.3Key material source 1: Host computerThe MP devices support Windows and Mac as Host-OS. The era

The Western Digital My Passport and My Book devices are external hard drive series connecting to host computers using USB 2.0, USB 3.0, Thunderbolt or Firewire, depending on model. These consumer off-the-shelf hard drives are available world wide. Many of the models advertise the benefit of hardware implemented encryption.