In the Vault

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).

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.

The Master Password: Caution!

So far, I have not talked about the master password. In the previous scenario, the master password can be used as a fallback if the user password is not known. The idea behind this design again originates in a corporate laptop scenario: The company's own IT department must at all times have access to the data, even if the users are no longer around.

Every hard disk is initially supplied with an undocumented master password. In the hdparm output, you can see this from the details of the master password revision code, which refers to the currently valid master password as an identifier. The default value 65534 (hex $ FFFE) references the manufacturer-defined password. In other words, the HDD or SSD manufacturer has a way of resetting the security settings right from the outset. The initial master password is unknown to the user but can be overwritten by the first call of the SECURITY_SET_PASSWORD command, this time using the --user-master m switch:

# hdparm --user-master m --security-set-pass "UltraSecret" /dev/sdb
security_password="UltraSecret"
/dev/sdb:
Issuing SECURITY_SET_PASS command, password="UltraSecret", user=master, mode=high

The Master Password Revision Code is then set to 1. If only a master password, but no user password, is set, no security features are active. The master password does not enter the game until these settings are enabled. All security settings can then be disabled either with the user or with master password using the SECURITY_DISABLE_PASSWORD ATA command:

# hdparm --user-master [m|u] --security-disable "UltraSecret" /dev/sdb

In terms of ATA states, a transition from SEC5 to SEC1 occurs. Now you can assign a new user password.

The ATA standard specifies two different security levels that are defined when setting the user password. These levels also define the scope and capabilities of the master password: HIGH and MAXIMUM. HIGH is the default (LOW would mean no security features are enabled). All explanations so far have related to the HIGH level. Set the MAXIMUM security level as follows:

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

The hdparm output reflects the new status (Listing 5). In this state, you can no longer unlock the device with the master password or directly disable the security features. If you do not know your user password, a transition from SEC5 to SEC1 requires a SECURITY_ERASE_UNIT, which will restore the device to a usable, pristine state.

# 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 maximum
        4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

The idea is that admins should not be able to gain access to user data, which is fine if you want to configure your disk that way. Keep in mind that when the security level is set to MAXIMUM, you'll lose all user data if you forget the user password.

Summary

The security features of modern ATA drives offer useful protection against unauthorized data access, provided they are applied correctly. The concept behind ATA security come from the world of corporate notebooks, but these techniques are also applicable to desktop systems – although you might need to use scripts to automate steps that the notebook BIOS completes automatically.

It is important to remember, especially in a private or simple business environment, that the HIGH security level is usually sufficient, and that devices should definitely be frozen to give malware no chance of changing the security settings – whether security is enabled or not.

If you set the security level to MAXIMUM, loss of the user password is equivalent to loss of data, unless you are prepared to pay a data recovery specialist a large amount money to open the disk under cleanroom conditions and retrieve the data or read the memory cells of the SSD directly.

Secure deletion of USB hard disks or SSDs with hdparm will generate error messages in many cases. It seems that many SATA-USB adapters block the use of the some ATA Security Commands or at least do not implement them cleanly.