Linux ATA Security Tutorial
Recently I went through the basics of ATA security and thought it might be helpful to share a condensed guide. If you have any questions, feel free to email me.
Foreword / Warning
While ATA security can be extremely effective, the implementation is just as important. Nearly all of the existing research on “breaking” ATA’s security is only exploiting poor configuration.
Change the master password
If you fail to do this, then anyone can unlock your drive using the default OEM password they found on Google. (The “HDD password” setting in your BIOS/UEFI doesn’t change the master password.) I would suggest making this >32 characters as you only need to enter it if you’re changing passwords.
hdparm --user-master m --security-set-pass MASTER-PASSWORD /dev/sdb
Change the user password
This the password that you’ll actually have to enter to read your data. Now, you have two options here: --security-mode m (maximum) or --security-mode h (high). With maximum, the master password is able to reset all the passwords, but cannot read any existing data. With high, the master password is also able to unlock the disk. The advantage with using maximum is that you can safely write down your master password without risking your data (it’s only a theft deterrent; a stolen drive will be useless).
hdparm --user-master u --security-mode m --security-set-pass USER-PASSWORD /dev/sdb
Note: If you’re using your BIOS/UEFI to enable password protection, set the security mode to high. Often vendors will implement non-standard hashing or use scancodes, meaning it may be difficult to unlock the drive on another machine. Should you need to recover the data on your laptop, you can simply use the master password to unlock the drive.
Example
Say your device is briefly stolen and the attacker tries to clone it.
~ > sudo dd if=/dev/sdb of=/tmp/evil.clone.dd.raw.img dd: error reading ‘/dev/sdb’: Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 2.11682 s, 0.0 kB/s
Usage
To actually use the drive yourself, you need to unlock it with the user password when you plug it in.
hdparm --user-master u --security-unlock USER-PASSWORD /dev/sdb
The drive is unlocked, but your system likely hasn't read the partition table yet.
partprobe /dev/sdb
Technically freezing the drive after isn’t needed, but it prevents you (or another piece of software) from accidentally changing your security settings. If you want to change your security settings after freezing, you physically have to power off the drive.
hdparm --security-freeze /dev/sdb
Note: If BIOS/UEFI protection is used, the drive will likely always be frozen after booting. If you need to change the password, boot a LiveCD/USB without unlocking the drive and use hdparm.
Unplugging the drive will immediately lock it. You do not need to safely remove it or shutdown.
Level of Protection
HDD
You will have to swap the locked drive controller out with an identical model (or find a way of resetting the memory, but that’s probably more effort). The data on the platters is not encrypted, so this is only an annoyance to a skilled attacker. For a typical thief, a non-default master password will make it worthless to them.
Still, ATA locking will likely prevent cloning on-site (e.g., traveling through a airport) as the technicians and required parts are probably kept in another facility. If that happens not to be the case, you still may be able to notice if a warranty seal is broken.
SSD
This is where you’ll get the most benefit, as nearly all SSDs are self encrypting (enabled by default with the encryption key’s password set to null). I would highly suggest still using a software based FDE (LUKS for Linux and BitLocker for Windows) since hardware encryption systems are rarely audited. However, even if there is a fatal flaw found in the firmware that leaked out the encryption key, it will be an expensive task. This also removes most of the fear about revealing free space with TRIM.
To check if your SSD has transparent encryption, look at the time it takes to complete a security erase. If it’s less than the time it would take to write over the entire disk, then it’s a self-encrypting drive (a SED only has to erase the encryption keys).
sudo hdparm -I /dev/sdb | grep ERASE
Disclaimer
If you’re asked to provide your password and decline, the drive may be seized for an extended period of time (or forever).