-
Notifications
You must be signed in to change notification settings - Fork 62
ATA Security Feature
ATA Security is a feature that has been part of the T13 standards since ATA-3 was published in 1997. This feature has stayed mostly the same since then with only a few changes here and there.
ATA/ATAPI-4 added the Enhanced Security Erase mode to the feature, so to support enhanced security erase, a device must at least support this standard.
In ACS-4 (2017), the restricted Sanitize Overrides Security feature was added.
Since ATA Security was added to the standards, the feature has been marked "optional", however it is available on most ATA devices.
The way this feature is most often used is by setting a password in a computer's BIOS or UEFI configuration settings. Sometimes this is also related to a "boot password" required to allow the computer to boot up.
The use of this feature does NOT imply that data is protected by encryption at rest. A device may or may not support encrypting data at rest with or without this feature.
ATA security defines two passwords:
- User Password
- Master Password (Or Administrator Password)
Both passwords are restricted to 32 bytes in length. There are no requirements on byte ordering, encoding, ASCII, UTF-8, hashing or anything like that by the standards. The standards only provide 32 bytes to set the password to.
Up to 5 attempts to unlock the drive are allowed before the device must be power cycled to try again.
Seagate has had support calls in the past with users attempting to move a drive protected by ATA security from one system to another only to find the password they type in fails to unlock the drive. What Seagate has been able to determine is that in some cases a manufacturer of a BIOS/Motherboard has encoded the password in one way that is not compatible with another system that may encode it some other way. Since this encoding is not described in any known standard or motherboard document, if you encounter this same case you may need to remove the password from the original motherboard, then set the password again on your other system.
It is strongly recommended that software is NOT used to manage ATA security and let the BIOS/UEFI of the system manage this feature as you may become locked out if the BIOS/UEFI, HBA, Driver, or OS do not support the ability to make the device visible to unlock the drive upon reboot.
From the factory, a drive vendor will set a master password on the device, and the master password identifier will be set to FFFEh or 65534.
This master password may be used to erase the drive, and depending on the user password configuration, even unlock the drive. This is controlled by the master password capability bit being set to high or maximum security.
openSeaChest_Security provides the option --ataSecurityInfo to display what mode the device is in as well as the current security state the drive is in.
Seagate does not share the value of the default master password and since Seagate began implementing the SD&D (Secure Downloads and Diagnostics) feature on all HDDs the default master password is uniquely set for each device. Attempting to use past default passwords for old devices will fail to unlock or erase the device.
When the user password is set there is an option to specify the security mode as high or maximum.
In high security mode, the drive can be unlocked to read the data by the administrator or erased by the administrator.
In maximum security mode, the drive can only be erased by the administrator.
ATA Security has two methods of erase and they have some differing requirements:
| Erase Mode | Pattern | Sanitize Method | Sanitized Areas |
|---|---|---|---|
| Normal | All bits 0 or all bits 1 | Overwrite | LBA 0 through current MaxLBA |
| Enhanced | Vendor Defined | Vendor Defined | LBA 0 through Native MaxLBA + bad blocks + unused blocks + spare blocks + overprovisioning areas |
Now that we know what these differences are, what exactly does Vendor Defined mean? This means that the manufacturer of the device decides what is the most effective method to securely remove data from all the sanitized areas.
On devices that support cryptographic erasure, a vendor will likely choose a cryptographic erase to perform the enhanced secure erase since changing the cryptographic key changes what the device is able to read and report back to the host instantly. For Seagate drives that support this, the enhanced erase time estimate is set to 2 minutes; the lowest value allowed in the spec.
For SSDs, the vendor is likely to implement a block erase where each NAND cell is sent the "erase" command to remove all of the data. This is generally pretty fast as well on the order of minutes.
For HDDs without encryption support, this will be a full pass overwrite, similar to normal erase but writing to all the other areas of the device.
Prior to issuing a normal mode ATA security erase, it is strongly recommended to restore the Max LBA back to the native max address so that there is no user data left on the device. The HPA, DCO, and AMAC features can be used to restrict the max LBA to a lower value (short-stroke an HDD or overprovision an SSD) which means that any data left above this value may be left untouched in a normal erase.
To ensure all data is completely removed, this step must be done first.
For ZBDs, there is an additional option bit called ZNR or Zone No Reset. This instructs the device to leave all the zones "full" to allow reading to verify that that all data has been securely erased.
In order to start an ATA Security Erase, a password must be set. If anything interrupts the erase it is left in a locked state with the set password. This has the potential to lock you out of the device in case of a failure.
Some systems will interrupt the erase while it is in progress with a bus-reset/com-reset. When this happens, ATA security erase stops and does not start again until the erase command is sent again. There is no guarantee that restarting the erase will pick up where it left off.
When ATA security erase is issued to the device, it holds the bus in a busy state until it has completed. There is no ability to check the progress of the erase and some controllers will only allow erasing one drive at a time due to this busy state.
Some BIOS's are known to issue the freeze-lock command as soon as they boot up, making it impossible to start an ATA-security erase on that system.
Until Windows 8, all prior versions of Windows will issue the Freeze-lock command if the device is not already in the frozen state. Starting in Windows 8, Windows PE versions will not issue this command and will allow ATA security erase to be performed, however the password must be exactly "AutoATAWindowsString12345678901". MSDN Security Group Commands
Some SAS/SATA HBAs have limited support for detecting ATA security. If the drive has been locked either due to reset during erasure or due to setting a password and rebooting, these HBAs may stop showing the drive as available to the Operating System. When this happens, you must move the drive to another controller that can handle this mode or the motherboard.
This new feature allows using a restricted mode Sanitize command to erase the drive without needing the master or user passwords. This can be helpful in the case that a user password is set to maximum security but has been forgotten and the default master password is still set, but now known to the user.
This will completely erase the entire device using sanitize to restore it back to not having security enabled.
Not all devices support this capability. See the --ataSecurityInfo output to determine if this is supported on your device or not.
See the Sanitize documentation for more information about the sanitize command set.
OpenSeaChest has support for ATA security in both the Erase tool and the Security tool. openSeaChest_Erase only supports erasure options, whereas openSeaChest_Security has a few other options.
Since running ATA security erase requires a password to be set, this is a risk that the device may be locked upon error. Seagate has studied lots of systems and interruptions of erase to automatically recover and disable the password that is used when it was a password set by openSeaChest.
By default, openSeaChest sets the user password to SeaChest without any additional spaces or padding and without byteswapping to try and be as compatible with other software and BIOS's as possible in case it does get left in a locked state.
To run a secure erase, you can do the following:
openSeaChest_Erase -d <handle> --ataSecureErase normal --confirm this-will...
or
openSeaChest_Erase -d <handle> --ataSecureErase enhanced --confirm this-will...
There are additional options to control whether to use the master password or user password as well as whether to byteswap it, pad it with spaces, and more.
openSeaChest_Security contains a few other options related to ATA security and some that are disabled in default builds.
First, the --ataSecurityInfo option to see information about what is supported for ATA security and the current state the device is in.
This option will tell you the security state from the standards as well as whether it is locked, frozen, enabled, the erase time estimates, whether the drive encrypts the data, and if the restricted sanitize overrides security is supported or not.
The other options available in openSeaChest_Security are the ability to unlock (--unlockATASec) and/or disable (--disableATASecPW) the ATA security password on the drive. As noted earlier, this may depend on how the BIOS encoded the password in the first place. Since this is not documented, there are some options in the --ataSecPWMod to attempt other ways of encoding it that may help, but it is not known what, if any, of these options are supported by a given system's BIOS.
If you want to provide some extra protection to prevent modifications to the ATA security feature once the system is booted and running, you can use --ataSecFreeze to freezelock the feature and prevent it from being enabled, unlocked, disabled, and erasing the drive.
It is recommended that this is done on startup if you are not using the ATA security feature in your system.
One other option is the ability to force all ATA security commands through the SAT security protocol. The SAT specification (SCSI to ATA Translation) defines a security protocol to interact with ATA security. Some SAS/SATA HBAs support this and sometimes an NVMe or USB device may support this as well. You can use the option --ataSATsecurityProtocol to attempt using this protocol to interact with ATA security instead, which may "play nicer" with your hardware. By default, all SATA devices will use passthrough commands for ATA security in openSeaChest, but there may be times where forcing this protocol will work better.
By default, the build flag atasecsetpass is set to false.
By enabling this option, it adds the ability to set the ATA security password for both the user and master passwords.
This is disabled by default since it is very easy to get yourself locked out of a drive by configuring the password from software.
What does it look like being locked out?
This depends on the operating system, system hardware, and how the drive is attached to the system.
Sometimes the system will boot and ask you for the password, but no matter how many times you try, it will not accept it. This means the BIOS is encoding the password differently than the software that was used to set the password.
Sometimes the HBA will try to identify the attached devices, but during this process it does not find or entirely skips the drive with a password that is set. This is likely a compatibility issue with the HBA firmware.
Sometimes you can get through all of the hardware initialization and booted into the OS, only to find your locked drive does not show up at all. Some OS's will only show drives which they can read the partition table from and that is not possible while the drive is in a locked state, so the system simply does not show it as attached and available.
Why does this feature even exist if it shouldn't be configured by software?
When this feature was developed, it was the job of the BIOS to provide interaction with ATA security. Even a modern UEFI system still provides ATA security support through the security options available. While you can compile openSeaChest with the ability to set a password, it is not recommended due to the numerous issues observed trying to manage ATA security with software.