Enabling ATA Security on a Self-Encrypting SSD

Recently I purchased a Samsung 840 Pro SSD for my frayed old notebook (a Thinkpad X200s). It’s a self-encrypting drive where data is always stored with AES-256 encryption. But first, to benefit from the encryption, I needed to encrypt the underlying encryption keys. One way of doing that is to set an ATA user password for the drive, which is supported by the BIOS of most notebooks.

But there is a problem.

ATA Password and Bios Incompatibilites

Using the BIOS is like using a blackbox, where you have no idea what the underlying code does to the password that you enter before it’s sent to the drive. For instance, (older) Thinkpads have an option to allow for long password paraphrases (with up to 64 characters). That sounds good, doesn’t it? Well, what it doesn’t tell you is that the paraphrase is converted using some unknown hashing algorithm and reduced to a pathetic 7 bytes before it’s sent as the password to the device. And what’s just as bad, because the hash routine is unknown, you won’t be able to gather the actual password used to encrypt the drive’s encryption keys – in other words, you won’t be able to use the drive with another computer or tool that doesn’t rely on the same hashing method.

In short: If your notebook dies, you may not be able to use your user and master passwords anymore, which means your SSD will remain locked without access to read, write or erase any data within the device. In this case, your SSD is toast.

Use hdparm instead

What I recommend instead is to use a third party tool like hdparm to activate the ATA security and set both user and master passwords for the drive. There are some caveats to be aware of, such as the limited character set allowed by the BIOS, the limited length, and the use of scan codes.

Below are my notes that I scribbled down while testing ATA security on a unused spare drive (the last thing I wanted is to ruin a shiny new Samsung SSD because of some silly mistake). They may contain some information useful for your needs. Just make sure you don’t accidently send the commands to the wrong drive!

PS: Most of the information I gathered from the ATA Command Set 2013 draft.

Notes on Harddisk ATA Security Feature Set

Lenovo “legacy” bios password limitations

  • accepted characters: a-z (case insensitive), 0-9, ‘ ‘, ‘;’
  • transmitted to hdd as scan codes
  • maximum length: 12 bytes (12 characters), or 7 bytes (hash) if paraphrase-enabled
  • stored in SMRAM? security issue?
  • internal Lenovo document with some really useful information 🙂

General info good to know

  • ATA password is 32 bytes long (padded with trailing zeros)
  • stored in the hidden system area on the drive
  • encoded in ASCII if generated from application software; often encoded as keyboard scan codes if generated via BIOS
  • without a user password, the security feature set is disabled
  • security level high: master password can unlock the device and reset the user password, data remains
  • security level maximum: master password can reset the user password, but only if data is erased

Get Drive Info

hdparm -I /dev/sdb

Result:

/dev/sdb:

ATA device, with non-removable media
        Model Number:       SAMSUNG HD321KJ                         
        Serial Number:      S0ZEJ1NP601353
        Firmware Revision:  CP100-11
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
.
.
.
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        112min for SECURITY ERASE UNIT. 112min for ENHANCED SECURITY ERASE UNIT. 

Notes:

  • a disk always has two passwords
  • the master password identifier = 65534 = 0xFFFE implies master password is still factory default (it’s set to something else when master password is changed; this Samsung HDD for instance uses it as a password set counter)

Get Raw Identify Device Information

hdparm --Istdout /dev/sdb  

Result:

/dev/sdb:
0040 3fff c837 0010 8856 022a 003f 0000
0000 0000 2020 2020 2020 5330 5a45 4a31
4e50 3630 3133 3533 0003 8000 0004 4350
3130 302d 3131 5341 4d53 554e 4720 4844
3332 314b 4a20 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0000 2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0000 ffff 0fff 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 001f 0706 0000 004c 0040
01f8 0052 746b 7f01 4123 7469 be01 4123
40ff 0038 0038 0000 fffe 0000 fefe 0000
0000 0000 0000 0000 eab0 2542 0000 0000
0000 0000 0000 0000 5000 0f00 0b0e 0100
0000 0000 0000 0000 0000 0000 0000 4014
4014 0000 0000 0000 0000 0000 0000 0000
0021 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 ffff 0400 0e00 0003
0000 9a00 0300 2400 6a20 3431 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 003f 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 100f 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0001 0400 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 9ea5

Notes:

  • word 89 (0038): time to perform secure erase (*2 if 1…254)
  • word 92 (fffe): master password identifier
  • word 128 (0021): security status (bit 8: MASTER PASSWORD CAPABILITY ~ 0 = high, 1 = max; bit 4: SECURITY COUNT ~ 1 = EXPIRED; bit 3: SECURITY FROZEN; bit 2: SECURITY LOCKED; bit 1: SECURITY ENABLED)
  • word 255 (9ea5): checksum

Set Master Password (SECURITY SET PASSWORD)

hdparm --user-master m --security-set-pass masterpass /dev/sdb

Notes:

  • device must not be locked or frozen, or command is aborted
  • will overwrite factory default master password
  • does not enable security (i.e. it doesn’t lock the device after next power-on reset)
  • use of the master password is indicated by the MASTER PASSWORD CAPABILITY bit (word 128, bit 8: 0 = high, 1 = max)
  • MASTER PASSWORD CAPABILITY bit = 0 (high): user password and master password can be used interchangeably
  • MASTER PASSWORD CAPABILITY bit = 1 (maximum): master password cannot be used with the SECURITY DISABLE PASSWORD and SECURITY UNLOCK commands. SECURITY ERASE UNIT will still accept either user password or master password

Set User Password (SECURITY SET PASSWORD) with MASTER PASSWORD CAPABILITY bit set to maximum

hdparm --user-master u --security-mode m --security-set-pass userpass /dev/sdb

Notes:

  • a user password automatically enables security (i.e. device will require SECURITY UNLOCK upon next power-on resets)
  • SECURITY ENABLED bit is set to 1
  • the MASTER PASSWORD CAPABILITY bit is modified during the processing of a SECURITY SET PASSWORD command that specifies a user password

Unlock a Drive (SECURITY UNLOCK)

hdparm --user-master u --security-unlock userpass /dev/sdb

Notes:

  • an unlocked device (SECURITY LOCKED bit set to zero) allows read and write access
  • if SECURITY UNLOCK fails and password attempt counter (usually 5 attempts?) reaches zero, SECURITY COUNT EXPIRED bit is set to one
  • abort if passwords don’t match, SECURITY COUNT EXPIRED bit is set to one, or SECURITY FROZEN bit is set to one
  • a power-on reset or hardware reset clears SECURITY COUNT EXPIRED bit to zero
  • master password can only unlock a device if MASTER PASSWORD CAPABILITY bit = 0 (high)

Disable Security (SECURITY DISABLE PASSWORD)

hdparm --user-master u --security-disable userpass /dev/sdb

Notes:

  • disables security by disabling the user password and returns device to security disabled, not locked, not frozen state
  • does not change master password
  • master password can only disable security if MASTER PASSWORD CAPABILITY bit = 0 (high)

Erase a drive (SECURITY ERASE PREPARE & SECURITY ERASE UNIT)

hdparm --user-master u --security-erase userpass /dev/sdb

or

hdparm --user-master u --security-erase-enhanced userpass /dev/sdb

Notes:

  • ignores the MASTER PASSWORD CAPABILITY bit when comparing passwords, always accepts either a valid master password or user password
  • two erase modes: normal (overwrite data with binary zeros and/or ones), enhanced (overwrite data with vendor specific data pattern, also includes sectors no longer in use due to reallocation)
  • for self-encrypting drives (SED), the SECURITY ERASE enhanced command causes the SED encryption key to change, which immediately renders existing (encrypted) data useless
  • disables security on completion (existing user password is invalidated, device is returned to security disabled, not locked, not frozen state)
  • does not change or erase master password

Thinkpad-compatible Passwords with hdparm

hdparm --user-master u --security-mode m --security-set-pass $(printf 'userpassword' | tr '1234567890qwertyuiopasdfghjkl;zxcvbnm ' '\2-\13\20-\31\36-\47\54-\62\71') /dev/sdb

Notes:

  • older thinkpads (and many other notebooks) use character scancodes to make up the password
  • above command replaces userpassword with the scancodes of characters accepted by the BIOS (a-z , 0-9, ‘ ‘, ‘;’)
  • remember to limit the password length to 12 characters

13 thoughts on “Enabling ATA Security on a Self-Encrypting SSD

  1. The scan code method didn’t work on a Lenovo X220 so they must be doing something different as of a few years ago anyway. This is quite unfortunate as it would be useful to at least know what was being set in the drive in case the Lenovo failed and the data needed to be recovered on another machine.

    • Shane, I agree, that’s very unfortunate. It seems (from the internal Lenovo document I linked to in the article) that on newer devices, the passphrase mode is always activated (meaning your password is salted with the hashed model and serial number of your notebook).

      One workaround (albeit one with limitations) is to use a dedicated boot device, like a USB stick with a minimal Linux install to unlock your ATA password; upon reboot your boot device would still be unlocked (if BIOS password at reboot is disabled) and allow you to continue to boot. Drawback: Wake up from hibernate would again require a boot from the USB stick to unlock the disk before hibernation could work.

      Another possible workaround: If the internal document is still up-to-date, it appears (see bit flags on page 12) that newer BIOSes are backward compatible. They use the Master Password Revision Code (word 92h) to identify whether a disk was locked using the passphrase or the password method. What I don’t know is what tool allows you to manually modify the Master Password Revision Code.

      • The way I read that internal document, the password is hashed with the hard drive’s model and serial numbers rather than the notebook’s but I could be wrong here. Otherwise inserting a drive into another Lenovo would not work and other Lenovo documents suggest that works. So I tried:
        p=sha256(password)
        Where password is my password, converted to scancodes and padded by \x00 to 64 bytes
        m=drive model (0 padded to 40 bytes)
        s=drive serial (0 padded to 20 bytes)
        p=trunk(p,12) take first 12 bytes of password hash
        hd=sha256(m+s+p)
        Should give a 32 byte hd password. Alas, fail.
        Also tried sha256 of the password not converted to scancodes, and with and without padding. But in entering the password in bios, it is not case sensitive implying scancodes are used rather than the actual password characters.

        Hashing the password with the laptop model and serial would be a major oversight as replacing the motherboard changes the serial number. Those do get replaced regularly as part of the warranty process.

        • You are probably right; the document doesn’t exactly say what serial number is used with the hash, but it’d make a lot more sense to use the hard drive’s serial.

          The steps you outlined seem to closely match the password generation flow as shown on page 11. Did you try it with hd=sha256(p+m+s) or hd=sha256(p+s+m) as well?

  2. Hi, thank you for these details. Could you specify the commands, if I only want to set “security level high” to “max”?

    My “word 128” reads “0029”, if I not miscounted (it is 36 after “word 92” which is “fffe”). This means converted to binary “0000 0000 0010 1001”.

    This means, my “bit 8” of “word 128” is 0 and thus “MASTER PASSWORD CAPABILITY ~ 0 = high”.

    Now even with applying a user password, the manufacturer could apply this as a backdoor to enter my data, right?

    Then I need to set “bit 8” of “word 128” to 1 – then even if the master password were applied, it could not enter my data on the drive, but just securely delete the drive.

    Actually, this is fine with me. I do not need to change the master password, just push it to level “max”.

    Any idea for the command on hdparm to do so?

    • Hi Joachim,

      did you try setting your own master password? If you do, it would overwrite the potentially existing master password. Also, in the how to, the user password is defined with the “maximum security” setting. This is done via the “–security-mode m” setting.

      Check your drive with “hdparm -I /dev/sda” (or whatever your drive is), and look further down in the output where it says “Security level”.

  3. Hi Alex, thank you for this great information. I too have a Thinkpad X200s with the 1440×900 screen and love it. I updated the BIOS for the Full Disk Encryption extensions from https://support.lenovo.com/us/en/documents/migr-69621

    I would like to use the BIOS power-on disk password, but still be able to unlock the drive on another machine with hdparm. Is this what your section on Thinkpad Compatible Passwords with HDPARM is supposed to do? Can you walk us through the steps to do this? Thanks for your good work!

  4. I’m doing a project where I’m hoping to use the hdparm tools with a SED. Your write-up is the best I’ve come across so I’m looking for some insight.

    So far it appears to me that one must use the “–user-master u –security-set-pass {pwd} /dev/sdx” to Lock the drive, HOWEVER the locking does not happen instantly, but instead only is in effect AFTER a power cycle to the drive (Similar to how a frozen drive -“–security-freeze /dev/sdx” only gets thawed by a power cycle to the drive). Does this observation make sense? Is there a means to tickle the drive to immediately LOCK the drive WITHOUT a physical power cycle to the drive? is there a different command or sequence to effect an immediate locking?

    Further, from what I can tell so far I can actually unlock my particular drive without the power cycle so long as its not under a freeze (with “–user-master u –security-unlock {pwd} /dev/sdx”), contrary to things I’ve read elsewhere from other users.

    Also I can do an immediate freeze of the drive, but once done power cycle is necessary to get thawed.

    — Still looking for proper insights… Thanks in advance.

  5. Hi. Jethro Beekman’s blog post suggests — if I understand correctly — that 96 bits of entropy can be generated by entering an 18 character password in Lenovo bios.

    How much entropy will a 12 character password generate using this hdparm method?

    Thanks for the informative post.

Leave a Reply

Your email address will not be published.