HackLab 2014 - Hard disk drives? Squishy disk drives!

By on 12 May, 2014

The aim of this project was to investigate the implementation of the ATA disk protection password on hardware encrypted hard drives, by accessing the microcontroller on the disk itself, and see how well it was actually protected…

The aim of this project was to investigate the implementation of the ATA disk protection password on hardware encrypted hard drives.

Historically, the hard disk password was used to lock the drive; the correct password needed to be presented to the drive for the majority of disk commands (such as reading and writing) to work. There has been some previous successful research into circumventing these passwords through implementation bugs and a number of demonstrable side-channel attacks, such as reading the raw platters on the disk and extracting the data; data recovery firms use this technique amongst others to recover data from damaged drives.

Self encrypting drives, sometimes called hardware encrypted drives, encrypt everything on the disk platters (regardless of whether a password has been set) using a key which is stored somewhere on the drive. This key is protected using the ATA drive password, the reason being that without the drive password, the contents of the disk cannot be decrypted even if the drive is directly accessed. A similar approach is taken for SSD drives. Some of these drives have been awarded various security-related accreditations, although most seem to relate to individual components; for example, in one case, the chip performing the AES encryption had been awarded various certifications, but the scope of this award did not include key storage or anything unrelated to the mathematical implementation of AES.

The focus of the day was to find the extent to which the claims above were supported by practical research. There were a number of immediate questions, such as:

  • Is it possible to directly access and interact with the drive firmware, which may provide an attack vector? This could include serial or JTAG interfaces on the firmware board itself, or undocumented ATA instructions that are sent during, for example, a drive firmware upgrade.
  • Is the master decryption key encrypted with the ATA password or simply in an area which is protected by it? A side channel attack which could acquire the master key directly would render the ATA password useless.
  • Are there any protection options available that could serve as an adjunct to the existing security? For example, wiping the drive (for a self encrypting drive, this can be as simple as deleting the stored key and replacing it with a new one).

It was important that the project be conducted against modern hardware, on drives which are trusted to store sensitive information by many organisations, including MWR. For this reason, the drives which were tested included:

  • A Samsung 840 EVO SSD (self encrypting)
  • An Intel 520 SSD (self encrypting)
  • A Seagate Momentus FDE drive (traditional mechanical disk, self encrypting)
  • A Seagate Barracuda drive (not self encrypting)

A number of paths were followed:

Identification of side channel opportunities (serial/JTAG)

The previous research suggested that most drives will have test ports on the board, used for debugging or testing purposes. Although these are usually left on production boards, the manufacturers tend not to disclose their presence and there was very little documentation available providing technical support in this area.

The first stage was to carefully separate the firmware board from the rest of the drive or, in the case of the SSD drives, open the case and gain full 360 degree access to the board. This was easier on some drives than others; the Intel case was unscrewed using a standard security screwdriver but the Samsung case proved to be more resistant. The screws that were used did not appear to be standard and, after nearly an hour, the case was removed with the aid of two pairs of pliers and a pair of cutters. Surprisingly, the Samsung board was very small; about 1/3 of the size of the 2.5" case it was in. Removing the board from the mechanical drives was straightforward as it was exposed in all cases; it was merely a case of unscrewing it and removing the ribbon cable.

The next stage was to identify potential interfaces on the board. This was mainly a process of trial and error and involved soldering pins onto the board to make further connections easier. A combination of a “Jtagulator” (a board which tries to bruteforce the correct pinout for a JTAG interface by trying all possible combinations) and a bus pirate were used with some success; a serial interface was located very quickly on the Intel drive although further work had to be done to decode the protocol that was used.

Software access to drive interfaces

A number of drive firmware update utilities, along with the actual update binary image, were downloaded off the internet and loaded into a disassembler and debugger to try to identify any privileged commands that were being sent to the drive.

Drive manufacturers package their firmware updates in a number of ways, although none appeared to be simply extractable. Some appeared to have been packed in a proprietary way, some were encrypted or at least unreadable in their current form and all needed to be individually dissected in order to recover the firmware image.

As there were a number of people involved and, for most, this was a new area, a lot of time was spent learning about the tools and the new environment. The majority of research available on the internet in this area appeared to rely on very outdated bugs or techniques which have long since been addressed by manufacturers. There is a lot of further work to be done on this project and more concrete findings will undoubtedly emerge as a result.