All SD/SDHC cards that adhere to the SD Group's standards support password protection at the card level.  This means that you can assign a password (up to 16 bytes long) to any given SD card.  If the password is set, the card is locked against read/write access to the card's data.  If you later want to access that data, you must first write the password to the card and request access.

The password is maintained by the card, not by the computer that the card is plugged into.  This password access is only granted for so long as the card receives power; if the card loses power with the password still set, the password lock willl be restored when the card powers up later.

This page describes the SD Locker 2, a standalone, battery-powered device that can set and clear password protection on SD and SDHC cards.  This is a proof-of-concept project, intended to show how you can use a microcontroller to manipulate the card's password.  I hope others will take this project and expand on it, bringing the security of password-protected data to others.




Here is the SD locker 2 device, mounted in an Altoids can, complete with a set of AA batteries for power.  The small green PCB stuck to the SD card socket is a 3.3 VDC boost regulator, to provide a stable voltage source for the ATmega328P microcontroller and for the SD card.

On the right side of the board (top) are a red LED and pushbutton for locking the card.  Below these are a green LED and a pushbutton for unlocking the card.

On the left side of the board is a single pushbutton for selecting access either to the TMP_WRITE_PROTECT bit (switch not pressed) or the card's password (switch pressed).




Here's a closer view, showing the password switch on the left and the LOCK and UNLOCK switches on the right.  This is the same electronics used in the SD locker project (see below), except for the addition of the password switch.


The concepts
This project builds on an earlier device, called SD Locker, that provides access to an SD card's TMP_WRITE_PROTECT bit.  Using this bit, you can write-lock data on an SD card, allowing you to make the card read-only.  However, the card's data can still be accessed, so the contents are not hidden.  SD Locker 2 (SDL2) lets you set a password so the card's data cannot be read or written.

An SD card's password is accessed using CMD42, as outlined in the SD Group's SD Specifications Part 1, Physical Layer
mplified Specification, available on various websites, such as this one.  The use of this register is fairly complex and takes several pages in the spec to describe.  I'll hit the high points here, but expect to go through the spec for all the details.

A password can contain up to 16 bytes (not necessarily characters) of data.  The password is defined by the contents of the card's 16-byte PWD register and the 1-byte PWD_LEN register.  By default, PWD_LEN is 0, indicating that the password is not set.

To set a password on a card, you send a CMD42 command to the card with the following payload:

Byte	Function	Notes
0	Flags	Describes operation to perform with following password
1	Length	Contains the number of bytes in the following password data
N	Data	Contains the password data

The Flags byte uses the low four bits to define the password operation to perform.

If bit 0 is set, the password data is written to the card to create a new password.

If bit 1 is set and the following password data matches the card's current password, the card's password is cleared.  This means the card internally sets PWD_LEN to zero, erasing the password.

If bit 2 is set and the following password data matches the card's current password, the card's password is activated and the data is locked against read/write access.  If instead bit 2 is cleared, the card's password is temporarily deactivated and the data is available for read/write access.

If bit 3 is set, the card is password-locked, and the following password data matches the card's current password, the card's entire contents, including the PWD and PWD_LEN registers, will be erased.  This allows you to remove a password lock, but it also destroys all of the card's data.

The Length field contains the number of bytes in the following password data block.  If you are setting a password on a card that does not yet have a password, this field will be the length of the password you are writing.  However, if the card already has a password and you wish to change that password, this field must be the sum of the old password length and the new password length.  Refer to the spec for more details.

The Data field contains all of the password data for the current command.  If you are setting a password on a card that does not yet have a password, this field contains the bytes of the password.  However, if the card already has a password and you wish to change that password, this field must contain the bytes of the original password, followed by the bytes of the new password.

Note that a CMD42 must be sent by your device as if it were a sector write operation.  This means you must provide all of the bytes the card would normally expect in a sector write command, even though the password can be as short as one byte.  You can simply send a block of 0xff bytes to fill in the gap, as the card only uses the number of bytes defined in the Length field.

There are a few details to note.  Passwords can be binary.  We are used to using ASCII characters as passwords because we have to type in the data from a keyboard prompt, but you are free to set your password with non-printable bytes if you choose.

Setting a password does not itself lock the card's data.  Until power is cycled or a subsequent CMD42 is sent to lock the card explicitly, the card's data can still be accessed.  In real life, this probably won't be an issue, since you will set the password, then remove the card from the SDL2 device, which immediatly enables the lock.  A subtle point, perhaps, but worth noting.

The spec implies that you can combine some password operations into a single CMD42 command.  Particularly, the spec implies that you can set bit 0 to set the password and also set bit 2 to lock the password, combining the set and lock operations into a single command.  In practice, however, I've found this sometimes doesn't work; it varies based on the card's brand.  I've resorted to separate CMD42 operations, first to set and then to lock, for reliable operation.

At any time, you can determine the state of the card's password lock by sending a CMD13 (SEND_STATUS) and examining the two-byte response, which is the card status.  I found the spec to be very confusing regarding this register and the response to a CMD13.  The goal is to read the LOCK/UNLOCK bit, which is bit 8 of the 16 bits returned by CMD13.  Bit 8 is set to show the card is locked and cleared to show it is unlocked.  If you have questions, consult the source code below.


Using the SDL2
The SDL2 has three pushbutton switches.  Pressing the LOCK switch sets the TMP_WRITE_PROTECT bit and write-locks the card's data.  Pressing the UNLOCK switch clears the TMP_WRITE_PROTECT bit and write-enables the card's data.

If you press and hold the PWD switch, then press the LOCK switch, the device sets a fixed password and locks the card.  If you press and hold the PWD switch, then press the UNLOCK switch, the device erases that fixed password, unlocking the card. Following an UNLOCK operation, there is no password in the card (PWD_LEN has been set to 0).

The SDL2 has an UNLOCK LED and a LOCK LED.  These LEDs show the results of the most recent operation.  For example, if you press the LOCK switch and the SDL2 successfully set the TMP_WRITE_PROTECT bit, then the LOCK LED will light and the UNLOCK LED will be dark.

If you press the PWD switch, the UNLOCK LED and LOCK LED will show the state of the card's password lock.  For example, if you have password-locked the card, then press the PWD switch, the LOCK LED will light and the UNLOCK LED will be dark.  When you release the PWD switch, the UNLOCK LED and LOCK LED will revert to showing the state of the TMP_WRITE_PROTECT bit.

The SDL2 device includes a four-pin header for attaching a serial connection.  The signals on this header are CMOS-level, NOT RS-232 level!  To attach a serial connection to your PC, you will need to provide some type of RS-232 level-shifting circuitry.  Note that you do not need to attach a serial port to use the SDL2.  The serial port can be used to control the SDL2, and it provides a lot of additional data and features, but it is not required to use the device.


What's it like?
I've played with password-locking on about a dozen SD cards of various sizes and brands.  I've plugged these cards into several different computers, from laptops to an old Mac Mini and a fairly new gaming PC.  I've used these cards directly (in the SD card slot of laptops) and with USB to SD card adapters of various brands.  I've tested these cards with variuos OSes, including old versions of Mac OS X, Win XP, and Win7.

In all cases, the computer simply doesn't see the card.  It's not like Windows pops up a card icon but you cannot open the card.  The computer is not even aware that the card is installed.  If I install a password-protected SD card into a laptop set to boot from an SD card via USB adapter, the laptop simply hangs, waiting for a bootable device to appear magically.


What's it for?
This project gives you access to a security feature built into SD cards pretty much from the beginning.  It's odd that this security feature isn't more commonly used.  I did find a reference to Microsoft's use of password-locking on the Nokia Focus phone; see this report from Endgadget.  But aside from some vendors using password-locked SD cards as a kind of built-in storage for their device, there doesn't seem to be a lot of info about this concept.

But the security possibilities are huge.  With an SDL2 device, you can lock access to financial data, business plans, personal information, historical details, private data, software under development, proof-of-concept ideas or designs; nearly anything you can store on a computer can be password-locked.on an SD card.

Once locked, the card can be transferred physically to a receipent for use, and the password prevents unauthorized access.  Given the small size of microSDHC cards and their large capacity, you can move a lot of data around securely using an SDL2.

Password-locking also works as a secure archival tool.  Just unlock the card, update the contents, relock, and store the card away.  It cannot be read without unlocking it, so even if the card is stolen, the info is still secure.

As with anything security related, there is a risk that backdoor access to the card's data or password might exist.  I have not seen any news articles that address SD security in the Snowden papers, but that doesn't mean the password security has not been compromised.  That said, an SD card is drastically different from the Internet.  A backdoor into the SD card does not help you if you don't have physical access to the card.


Mods and ideas
The SDL2 shown here is only a proof-of-concept.  It shows a simple use case but it's really a starting point.  My hope is that others will take this design and build on it.

The most obvious mod would be porting this design to the Arduino, which opens up secure data to an army of users.  I have already been asked about porting the original SD locker project to Arduino, but I don't use Arduino so I'm not a good resource.  However, the code is straightforward and I'm pretty sure there are already Arduino shields and libraries that could be used.

The SDL2 design does not use the card-detect switch built into most SD card connectors.  It would be simple to add a connection to this switch, so the MCU could tell when a card is plugged in and update the LEDs immediately.  My code just waits for the user to press a button before trying to access the SD card; simple, and it works well.

Another option would be to build a USB adapter with the necessary buttons and LEDs to use it as an SDL2 device.  This would give you a single device that allows password control with a push of a button.  This in turn lets you create a password-protected stealth PC, further hardening your PC boot device.

Along those lines, a USB adapter and suitable code would let you modify the password.  The SDL2 design uses a single, fixed password, but an improved design could read the card's CID register, which is unique to each card, then hash that into a password (perhaps including info about you, your group, or your PC), then use that password to lock the card.

I would like to think there would be enough interest in this device to warrant a product of some kind.  Feel free to use this design as a starting point.  I am releasing this code and the associated electronics design to the public for use however you see fit.  As I've said repeatedly, this is not a product, it is a proof-of-concept.  It has not been rigorously tested!  If you want to use this as the start of a product design, you accept this design as-is and are responsible for all testing and qualification of your product.


Final thoughts
Here is a link to the schematic as a PDF.  I used a green LED for the UNLOCK LED and a red LED for the LOCK LED; suit yourself.

I've put together a ZIP file containing the source code and a HEX image that you can burn into an ATmega328P.  The source file is standalone except for its use of my custom UART library.  You don't need any of the UART code to use the SDL2; you can do everything with the pushbuttons and LEDs.  If you want to rebuild from the source file, you need either to strip out my UART code or replace it with your own code that performs the same functions.  I've thought about releasing my UART libraries, but it's simply too much work to repackage all of it so someone else can use it.

As usual, a tip of the hat to ChaN, of FatFS fame, for his SD card code that I used as a starting point.  I referred back to his site all through this project, and encourage others to ues this valuable resource.

Like the SD locker project, this code uses a CRC7 generator that I pulled from the Pololu website.  It's a neat piece of code and works well.  Thanks to Pololu for making this code available.  And I really like some of the Pololu products, such as their tiny boost regulator and the tiny pushbuttons I used here.


Home