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.
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).
Listing 1: hdparm Info
# 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.
Listing 2: In SEC2 State
# 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.
Listing 3: With User Password
# 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.
Listing 4: Disk Locked
# 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. [...]
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
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
# 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 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
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.
Listing 5: MAXIMUM Level
# 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.
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.