Update: SD Card Locker Now Supports Password Protect


[Karl Lunt] has updated his Secure Digital Card locker to support password based locking. [Karl’s] original design only supported write locking via the TMP_WRITE_PROTECT  bit. The new design gives the user an option: TMP_WRITE_PROTECT, or password protection. [Karl] goes into further detail this time around about the bit fields used with CMD42, and how they are set. The passwords in this case are up to 16 bytes. The bytes don’t necessarily have to be printable characters – any binary value can be used. Unfortunately, [Karl’s] locker doesn’t utilize a user interface beyond the buttons, so any password must be “baked in” to the SD Card locker firmware. We would love to see the option of even a basic serial interface for entering a password (most likely in hex).

[Karl] tried his device out with several different cards, and several computers. While not an exhaustive test, he did find that the computers always behaved the same: A locked SD card would not show up. In the case of windows, no beep, no drive, nothing. He goes into the security possibilities of using password locking: Financial data could be stored and physically transferred via SD or microSD, with the password sent separately (say in an email or SMS). Any unenlightened data thief attempting to use the card would think they have a broken device on their hands.

We don’t know how secure the password lock feature is – brute forcing a variable length 16 byte binary password would take some time. It all comes down to how quickly each password attempt takes. Some cursory web searching didn’t bring up any information about successful SD card password cracking. Sounds like a challenge for our readers!

19 thoughts on “Update: SD Card Locker Now Supports Password Protect

  1. “Unfortunately, [Karl’s] locker doesn’t utilize a user interface beyond the buttons, so any password must be “baked in” to the SD Card locker firmware”

    if there is enough room in the can you may be able to do like 1 older scanner did where you had to program it with 2 buttons marked 1 and 0 and you entered a 16 or 32 digit string of 1 and 0.

    so in the same way you could do the same for the password.

    1. Thinking a little ahead, could interface it with phone through headphone jack, bluetooth or plain USB serial, or if one’s going for style, with a rotary dial like big safes.

      On a security note, I wouldn’t really trust my data with this kind of password. I haven’t read the SD specs so correct me if I’m wrong but I doubt the data is actually encrypted with the given password.

      1. Yup. There is no encryption for this. It is just like the similar flimsy password protection offered as an extra feature for some USB HDs. If you can bypass the password then everything is accessible to you.

    1. There is nothing standard but generally most of the USB flash drive controller chips will have a readonly bit and “secure” password option. Your problem is that because it isn’t standard, there isn’t any way of accessing these extra features without documentation or reverse engineering the supplied utility.

  2. No no no no!!!

    I think this is false security! You should encrypt the files (or filesystem) on the SD card with TrueCrypt or other encryption software with a good password and AES128 or better.

    Even the author writes: “there is a risk that backdoor access to the card’s data or password might exist”, which is also true.

  3. Great device!

    “It all comes down to how quickly each password attempt takes. ”
    At 16 bytes the password 128 bits long. Brute forcing this would be for all intents and purposes impossible, even if you could try a billion billion combinations per second without penalty. Other methods (firmware exploits, hardware exploits, chip demasking/hacking…) would have to be employed to get to the data without the password (or to get to the password).

          1. None are sufficient if you don’t have a person who knows the password in captivity. The cartoon implies law enforcement given the DA on the briefcase. Here this is about the average law abiding joe or jane hoping to secure personal data.

  4. Why Hex?
    You have 16 bytes for the password? You could use “Orange1KupCake? or some other password. 16 bytes is a little short but it would work.
    BTW before you tell me that the password is not secure because I use common subs and words yes I know and I use a password manager and random strings for everything that is really important.

  5. Would it be possible to implement the same idea using an Aruino and a SD shield? I have looked at the Arduino SPI library and cant make heads or tales of it, I suck at anything MCU related.

  6. I’d like to know more about the permanent write protect bit, especially how permanent it actually is. Popping a fusible link, that’s permanent. Setting a bit in flash or EEPROM, perhaps not so permanent.

  7. I have reason to believe that genuine-but-faulty cards sold second hand (Yes, people really do this!) have this bit set.
    Is there a way to force the card to do a full erase at a firmware level, because I have a use for this “feature” ie making >32GB microSD’s useful again.
    It would be a bit like the ATA command equivalent on some HDDs, so once the lock is set only ATA_FULL_ERASE fixes it by wiping everything then 30 or so minutes later the operation finishes.

    1. Check the SD Group spec on CMD42. There is a bit you can set in the CMD42 packet that will do a full erase of the card’s data. You lose the data and the password; the card is essentially cleaned. See section, Forcing Erase.

      Note also the PERM_WRITE_PROTECT bit in the CSD (section 5.3.2) is described by the spec as “Permanently protects the entire card content against overwriting or erasing (all write and erase commands for this card are permanently disabled).” But this conflicts with CMD42, which claims to allow full erase. I haven’t tested to see what actually happens if you try to erase a perm-locked card.

      One of my SanDisk cards might have been one of the genuine-but-faulty cards you describe. Checking the CSD shows the Copy bit was set, meaning that someone (other than the original vendor) had manipulated the CSD. Of course, it might have been me in an earlier fit of firmware flailing…


  8. can you please add a force erase button i have a card that has the PERM_WRITE_PROTECT set i want to erase it.
    a button with a led saying it has permanent write bit set would be nice then you have to just press button and hope it erases the card.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.