The range of ATA security features are well defined, however, you will be hard pressed to find an operating system with a tightly-integrated tool chain that consistently leverages the benefits of ATA.

The hdparm tool, which is included with almost all Linux distributions, at least lets you control the ATA security features by scripting or manual commands. On many laptops, ATA security is integrated into the BIOS. This article describes how you can control access to your disk data through ATA security.

A Little Theory

When you buy an HDD or SSD today, all the security features are initially disabled. A query with hdparm as the root user provides ATA security information (Listing 1).

# hdparm -I /dev/sdb
/dev/sda:
ATA device, with non-removable media
        Model Number:       INTEL SSDSC2CW240A3
        Serial Number:      XXXXXXXXXXXXXXXXXX
        Firmware Revision:  400i
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II
[...]
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
                Look-ahead
           *    Host Protected Area feature set
[...]
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

Listing 1 shows that the SSD supports the ATA security command set; although all the security features show up as not enabled, the SSD does allow changes to the security state (not frozen). In ATA jargon, this state is known as SEC1; that is, the as-delivered state (the powered-down state would be SEC0). To prevent security-related manipulation of the SSD, such as disabling all I/O, either accidentally or by malware with root privileges, you can freeze the security state of the device:

# hdparm --security-freeze /dev/sdb

The device is now in SEC2 state. The associated hdparm -I output is shown in Listing 2.

# hdparm -I /dev/sdb
/dev/sda:
[...]
Security:
   Master password revision code = 65534
   supported
   not  enabled
   not  locked
   frozen
[...]

The counterpart to freezing (thawing, so to speak) does not exist. It takes a hardware reset or power cycle to revert to the SEC1 state (Figure 1).

Figure 1: The possible security state transitions in the ATA Security concept.

I do need to point out a possible pitfall: the BIOSes of many notebooks run the SECURITY_FREEZE_LOCK ATA command when booting to provide protection against manipulation. In this case, it would be impossible to carry out any further changes to the security state on the current system. In fact, I already had to cheat a little at this point. My laptop freezes the built-in SSD via the BIOS at boot time. Your only option is to install the disk to a PC with a BIOS that does not automatically freeze the drive or SSD; otherwise, the tutorial would come to an end at this point.

Locking Up Your Data

The ATA security concept has two different passwords: the user password and the master password, each with a length of 32 bytes. The factory default user password is NULL (i.e., 32 null bytes); the master password is manufacturer specific and undocumented, but you will find all kinds of information about factory presets on the web. The whole parade begins with setting the user password:

# hdparm --user-master u --security-set-passwd "Secret" /dev/sdb
security_password="Secret"
/dev/sdb:
Issuing SECURITY_SET_PASS command, password="Secret", user=user, mode=high

--user-master u specifies that the user password is referenced in the following. Because this option is the default, you can omit it at this point. You will then see the output in Listing 3.

# hdparm -I /dev/sdb
/dev/sdb:
[...]
Security:
        Master password revision code = 65534
                supported
                enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
                Security level high
        4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

The disk or SSD is now in the SEC5 security state (if it were turned off, this would be SEC3). In this state, you can do two things with the device: block it for all I/O or erase it completely. The lock is automatically applied after a reboot. The SSD does not allow any data I/O (state: SEC4) until a SECURITY_UNLOCK command is issued stating the password, either directly at the BIOS prompt (if the drive is required for booting) or with hdparm, which of course, requires an operating system and is thus only suitable for additional data disks:

# hdparm --user-master u --security-unlock "Secret" /dev/sdb

Because malware with root privileges could change the password again in this state (SEC5), an immediate freeze of the HDD/SSD makes sense, and this is what most laptop BIOSes actually do. After that, the SSD is secured against other security-relevant manipulation (state: SEC6).

By the way, a counter in the hard disk electronics allows only five attempts to enter the user password. Otherwise, the device remains locked in SEC4 state. Any further attempt at unlocking is only possible after a power cycle or hardware reset. hdparm then returns the output in Listing 4.

# hdparm -I /dev/sdb
/dev/sdb:
[...]
Security:
        Master password revision code = 65534
                supported
                enabled
                locked
        not     frozen
                expired: security count
                supported: enhanced erase
                Security level high
        4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

Secure Erase

The myth stubbornly persists that secure overwriting of hard disk sectors is only possible by overwriting at least 137 times with random bytes. What was true in the past no longer applies – this approach is no longer appropriate given high-density modern disks. Moreover, overwriting all the cells multiple times on SSDs is not only pointless, but it also massively shortens the service life. For reasonably modern disks and SSDs, a single overwrite with null bytes is sufficient.

To do this, the ATA standard supports the SECURITY_ERASE_UNIT command. This command tells the hard disk controller to irretrievably delete all the data on the device. The command has a normal mode and an enhanced mode. Normal mode does the same thing that dd does, but it takes the load off the CPU and PCIe bus by overwriting all addressable LBA sectors, mostly with null bytes. If DCO (Device Configuration Overlay) is running, that is, if the disk shows fewer sectors and therefore a smaller capacity than the maximum possible, and if it spoofs a different geometry to the operating system and the BIOS (a relic from the hard disk and BIOS Stone Age), then only this small area is cleared, because only this area is LBA addressable.

Enhanced Mode ignores DCO (but does not reset it) and overwrites all sectors, including all deallocated areas from the G-list with manufacturer-specific data. The G-list is a list of all sectors marked as defective and deallocated in the past whose LBA addresses have been reallocated to reserved areas. The operating system cannot directly access these areas. Only the disk controller itself has access to them; it does not reveal their contents, but it does delete them reliably. To run the SECURITY_ERASE_UNIT successfully, the device status must be SEC5; the security line in the hdparm output must read enabled and the device must be not frozen.

As Listing 4 shows, a complete delete run in normal mode takes four minutes for this device and two minutes in enhanced mode. For large devices that are not SSDs, you will find times measured in hours. You can initiate a delete with hdparm as follows:

# hdparm --user-master u --security-erase "Secret" /dev/sdb
security_password = "Secret"
/dev/sdd:
Issuing SECURITY_ERASE command, password = "Secret", user = user
0.000u 0.000s 0:39.71 0.0% 0+0k 0+0io 0pf+0w

or

# hdparm --user-master u --security-erase-enhanced "Secret" /dev/sdb

In both cases, not only is the delete process described above carried out, the user password is also cleared (reset to NULL) and Security mode is disabled. The device is then in the unprotected SEC1 state. Thus, the SECURITY_ERASE_UNIT ATA command is used to restore a hard drive to a pristine state.