Partially Solved: SSD security password - stuck with an I/O Error

Question

Model in question is a Kingston SV300S37A120G.

I read here that when trying to unlock a security password, I should put “quotes” around it if it contains special characters. Does that apply for caps?

I set my password by issuing a sudo hdparm --user-master u --security-set-pass XXXXXX /dev/sda command in UbuntuStudio running from a live USB. I could then confirm that security had switched from not enabled to enabled.

Update

Reason I ask is because I've been trying to issue
sudo hdparm --user-master u --security-unlock XXXXXX /dev/sda
(XXXXXX being my chosen password, then "", then "NULL",
then "my chosen password wrapped in quotes").

Whichever variant I try, I keep getting

security_password: "XXXXXX"

/dev/sda:
 Issuing SECURITY_UNLOCK command, password="XXXXXX", user=user
SECURITY_UNLOCK: Input/output error

Same happened when I initially tried to proceed to
sudo hdparm --user-master u --security-erase XXXXXX /dev/sda.

What's more, this morning I rebooted my system and noticed that
sudo hdparm -I /dev/sda
is now returning not only enabled but also locked, under Security, whereas before the reboot it was enabled but not locked.

Update II

--user-master u --security-erase "XXXXXX " /dev/sda
(that's my chosen password + 26 spaces = 32 characters)

or

--user-master m --security-erase NULL /dev/sda

or

--user-master m --security-erase " " /dev/sda
(that's 32 spaces)

all return

security_password: "password_as_typed"

/dev/sda:
 Issuing SECURITY_UNLOCK command, password="password_as_typed", user=user (in 1st case) OR master (in 2nd and 3rd case)
SECURITY_UNLOCK: Input/output error

Any kind of help would be greatly appreciated.

Solution 1

Input/output error means the password is rejected by the drive (because it's wrong; or the per-power-cycle five trials has been used up, i.e. expired: security count in hdparm -I), at least it's the case with my Intel SSDs (X25-M G1 / 530).

I am not sure what's the cause of the hiccup in your drive/case though. Could be you've been using an old/bugged version of hdparm; could be the firmware of your drive is bugged.

In any case, you can try to:

• use the latest version (currently 9.48) of hdparm if you haven't been doing so
• quote and pad your password with spaces until it reach the maximum possible length (i.e. 32 characters; e.g. "XXXXXX ")
• use --user-master m instead of --user-master u, with password like NULL or " " (i.e. 32 spaces)

As I mentioned before, make sure you do NOT try more than five times in each power cycle (in some case a "reboot" is not enough; confirm with hdparm -I before spending your effort).

Even in version 9.48 there's a bug with --security-unlock for the special password NULL, so you probably want to stick with --security-disable until you figure out what's wrong (apparently "" is equivalent to NULL and hence can be used to workaround the bug as well).

---

...is now returning not only enabled but also locked...

That's normal. When the password is just set, the drive remains unlocked until the next power cycle.

Solution 2

Okay. Here's my word to whomever may be interested in doing a security-erase on a Kingston SSD from an Ubuntu environment.

Issuing sudo hdparm --user-master u --security-set-pass <password> /dev/sda
as is advised here, among other places (<password> being your chosen password )
will indeed set a user password on your drive.

Note that you must NOT wrap up your password in so-called chevrons (< and >).
If you do that, Terminal will return bash: password: No such file or directory
(password being your chosen password ).

You can confirm that your password has been set by issuing sudo hdparm -I /dev/sda
Security will now have switched from not enabled to enabled,
which according to the aforementioned links would mean it's time to proceed to
sudo hdparm --user-master u --security-erase <password> /dev/sda.

Here is where the trouble began.

security_password: "<password>"

/dev/sda:
Issuing SECURITY_ERASE command, password="<password>", user=user
SECURITY_ERASE: Input/output error

...Terminal replied.

I kept trying, typing my password with or without quotation marks, replacing it with other suggestions such as "", "NULL", or NULL, but Terminal kept giving me the same answer, bottom line being Input/output error

Two days passed and I thought it wise to reboot. Next time I issued sudo hdparm -I /dev/sda
I could see Security had switched not only from not enabled to enabled, but also from not locked to locked.

That's normal. When the password is just set, the drive remains unlocked until the next power cycle.

Normal as it may be, I got a bit worried, so I decided to try to unlock my drive before doing anything else with it.

From my experience that's impossible.

sudo hdparm --user-master u --security-unlock <password> /dev/sda

returns

security_password: "<password>"

/dev/sda:
 Issuing SECURITY_UNLOCK command, password="<password>", user=user
SECURITY_UNLOCK: Input/output error

Wrapping up the password in quotation marks makes no difference.

sudo hdparm --user-master m --security-unlock "" /dev/sda
sudo hdparm --user-master m --security-unlock "NULL" /dev/sda
sudo hdparm --user-master m --security-unlock NULL /dev/sda

or even

sudo hdparm --user-master m --security-unlock "                                " /dev/sda

(that's 32 spaces)

all return

security_password: "whatever_pw_I_provide"

/dev/sda:
 Issuing SECURITY_UNLOCK command, password="whatever_pw_I_provide", user=master
SECURITY_UNLOCK: Input/output error

NOTE that in this case I tried m instead of u, as in master instead of user, having read somewhere (can't find the link at the moment) that setting a user password would set the master password back to NULL; although in Kingston's case it's NULL by default, they say, unless altered by the dealer.

(reference: https://www.kingston.com/datasheets/SVP100ES2_us.pdf)

Anyway, I did try these variants with both m and u, making ZERO progress.

To my surprise came a moment when I said to myself to hell with it and typed
sudo hdparm --user-master m --security-erase "" /dev/sda

Terminal contemplated what I had just said for a while... and BEHOLD, wiped was my drive.

The very same master password ("") that returned the Input/output error for the security-unlock command, worked just fine with the security-erase command.

As mentioned by Tom Yan, there is a bug in hdparm.

Similar issues are reported here:

When I entered NULL as the security it showed up as " " but entering NULL in the unlock command shows up as "NULL"

Bottom line: Don't lock your ssd unless you really intend to erase it.

PS: Too bad my reputation won't allow me to post more than 2 links.

Comments

[Tom Yan]

I don't think quotes would be your concern anyway. They are for the shell but not hdparm. If you set the password without quotes, then you don't need quotes when you unlock.

[Tom Yan]

Btw, is the drive connected to a SATA port on your motherboard directly? or is it connected to some SATA/USB adapter?

[m.a.a.]

@Tom Yup. SATA port directly on my motherboard it is.

[m.a.a.]

Well, thanks for your time. I tried with quotes, but I keep getting some "Input/Output Error". Anyway, I've asked elsewhere about that... shouldn't be violating the forum's code of conduct.

[Michael Frank]

@m.a.a. Update your question with the I/O error, as it's an appropriate question for SuperUser.

[m.a.a.]

Well, at least security count appears as not expired, but I'm not so sure I can see any information regarding remaining trials. As for the version of hdparm, I downloaded Ubuntu Studio 16.04 and set it up on a live USB about two weeks ago or so. Would that mean I'm using the latest version? How can I check this and update if needed? Also: bugged firmware, you say - how can I check that? Last: does anybody have any idea about Kingston master passwords? No luck here...

[Tom Yan]

As I've said, five times per power cycle (it's documented in ATA standards); and no hdparm will not show you the remaining trials, just count it yourself (by "make sure" I mean check whether the not shows up again after you "reboot", if not you'll need to "power off" and "power on"; I do NOT mean to "cut" the power while the computer is running though :P)

[Tom Yan]

Well apparently the "Xenial" Ubuntus has 9.48 in their repo. You can always run hdparm and it should show the version on top.

[Tom Yan]

How do you think you can check whether a firmware is bugged? Try to capture it somehow and do some RE? Anyway, that's why I suggested you to try pad your password with spaces.

[Tom Yan]

The only thing I could find about the master password is the datasheet of another Kingston SSD series. Apparently for those drives it's NULL. And as I mentioned, another "general" possibility (that one could think) of is naturally 32 spaces.

[m.a.a.]

Security count still appears as not expired... nonetheless I'm making zero progress. As for the workaround patch you linked to (now, pardon my novicehood) is that something I can just try to copy-paste into the Terminal?

[Tom Yan]

It sounds more of a bug in your drive's firmware to me. NULL become "NULL" instead of "" with --security-unlock, that's a known bug correct; however, in my experiments, apart from using my patch, this bug can also be worked around by entering "" instead of NULL. And according to your "answer", you tried sudo hdparm --user-master m --security-unlock "" /dev/sda, so...

[Tom Yan]

Also, this bug does not affect --security-disable; Unfortunately you didn't seem to have try it or stick with it as I advised...

[Tom Yan]

Oops, never mind. I think I know what happened. IIRC, one can only use master password to unlock/disable the user password if the the user password is set with "high" security mode/level instead of "maximum"; where hdparm defaults to "maximum" when it's not specified by user. However, security erase with master password is not limited by that.

[Tom Yan]

See 4.18.4 Master password capability in ACS-3

[Tom Yan]

Still, neither of what I post or what you post explains why you cannot unlock/disable your user password, or erase your drive, with your user password...

[m.a.a.]

@Tom True. None of this explains my inability to proceed to secure erase by use of the user password I had just set. Still, I thought it would be sound to update my story in as much detail as possible, describing how I eventually achieved what I initially intended to - that is, to secure erase my drive. Your posts have been really helpful along the way, as have other people's - most notably in terms of understanding what it is I'm doing. I'm by no means an expert on pc:s; rather a newbie when it comes to Linux - and as such I've attempted no more than what my gut told me I could handle...