Transparently encrypting SD card adapter

An SD card that transparently encrypts data with a public key. Reading the data written requires the private key after a power cycle.

Public Chat
Similar projects worth following
Most of the professional cameras can not encrypt the pictures they take.
So others can take your camera away and see all the pictures in the
card. Thus I am making this SD card adapter. It plugs in to a camera
like a regular SD card.

Here's how I intend the adapter to work. An RSA key pair is created on
a computer. The public key is written to a micro SD card which is then
put into the adapter. The adapter presents itself to a camera as a
regular SD card. When the camera is powered on, the adapter will add a
new image encrypted with AES XTS with a random key. The image key is
stored in the micro SD card encrypted with the public key provided. The
adapter will redirect writes and reads to the image. The image key
stored in registers is lost when power goes off. On the next power up,
the adapter will start a new image. Finally, the micro SD card is taken
out and read by a computer, which decrypts what has been written with
the secret key.

I have basic functionality.  I can connect my development board to a normal card adapter and access it as a normal SD card.  Next I should be making the PCB and case.

I don't have a prototype yet.  My plan is to use a Xilinx Artix FPGA and a DRAM.  Why not a cheaper FPGA?  Because I want it to eventually support SD Express (PCIe 3 with 1GB/s of throughput) without consuming too much power.  The maximum power of a removable SD card is 1.80W (data from SD simplified spec v6.00, might change in v7.0).  This adapter should take a fraction of that.

A DRAM stores the grain mapping.  Encryption and decryption of the disk image is done in hardware.  A soft CPU is also used for things like initialization and updating image metadata.  I'm currently using the Microblaze, but I don't mind switching.

Since I don't have a PCB yet, I am testing my code on a Digilent Arty S7-50.  The connection is straightforward.  My connection is configured in the file adapter/adapter.srcs/constrs_1/new/sd_host_if.xdc.  You'll probably want to change it.  sd_host_if_dat, sd_host_if_cmd, and sd_host_if_clk connect to the corresponding pins of an USB SD card reader.  sd_host_if_dat3_pullup is connected to CD/DAT3 through a 47KOhm resistor.

Some of the challenges to me:

I need a name for this project.

I don't have the latest SD full specification.  But the simplified specification is badly written besides having some parts omitted.  This problem is partly mitigated with the MMC specification.

I have to figure out how to fit everything in 2.1mm by 32mm by 24mm.  It includes an FPGA, a DRAM, the voltage regulator, and a micro SD card socket.

The adapter should present to the host a formatted disk.  We should also allow it to present to the host a disk of size as big as the space left on the micro SD card.  This means the initial image contents would be different depending on how much space is left.  We plan to solve this by saving templates at different locations when initializing the storage.

I need a way to generate random keys.  The ADC seems to be a good random source.  It provides 16 bit results, but only 12 bits of accuracy is guaranteed.  I tried reading the internal temperature sensor at about 1 MSPS for about 6M samples.  I then tested randomness of each of the 16 bits by extracting that bit from each sample and feeding them to rngtest.  Bit 2 to 5 (corresponding to 0.031℃ up to 0.25℃) passed the FIPS test.  I will also use an EEPROM that's updated every power cycle just to be safe.

Parts I have:

The storage format.  Some parts are still to be figured out.  And my writing may be bad.

A mostly working AXI lite bus SD device interface.  It supports generating responses in hardware.  But it only supports the SD bus.  We also need SPI and UHS-II interfaces and possibly NVMe in the future.

XTS-AES hardware implementation.  It supports configuring how many hardware AES stages are used in order to balance real estate and speed.  It can process 16 bytes per clock cycle in the fastest configuration.

The storage format:

The code:

  • We have some basic functionality

    eywdck2l06/17/2020 at 08:16 0 comments

    Now we have the basic hdl code.  We added software to create images.  We can now connect the development board to a card reader and access it like a real SD card.  We haven't added software to do RSA encryption and key generation yet.  Maybe the key can be generated with the FPGA's 16-bit ADC.

  • Got some HDL code

    eywdck2l01/23/2020 at 01:40 0 comments

    We now have the SD card interface, SD host interface, and XTS-AES IP cores. Hopefully that means only a little more HDL coding is needed for the first prototype.

    The XTS-AES IP core saves keys in SRAM instead of flip-flops to save resources. We need to find out whether it comes with security implications.

  • SD device interface

    eywdck2l06/26/2019 at 22:25 0 comments

    We have a mostly working SD device interface connected to an AXI4 LITE

    bus.  It generates responses on its own.  There will be about 100ms at
    least for the CPU to react to commands that involve the CPU.

View all 3 project logs

Enjoy this project?



nooitaf wrote 07/07/2020 at 01:38 point

Just saw a video about the New Parrot ANAFI USA Drone and they are using AES-XTS on their sd-cards natively. So i thought, wouldn't it be nice to have an adapter so it would work for anything micro-sd card related and legacy stuff. Just something in between faking a card...  did a google search and here i am :D .. Good thinking with the public key on the card. I'm a noob at FPGA's so can't help, but i hope you get this finished in time for the price or some day later :) Good luck!

  Are you sure? yes | no

Kosma wrote 06/24/2020 at 11:57 point

Many devices do not have encryption programs, routers, tablets or old computers or with a system that does not have compatible encryption (solaris)

  Are you sure? yes | no

eywdck2l wrote 06/26/2020 at 00:34 point

I see.  Sadly I am not even done with this project, and I want to continue working on it.  You may have to do it yourself if you want a thumb drive version.

  Are you sure? yes | no

Kosma wrote 06/21/2020 at 15:58 point

I prefer encrypt normal usbA

and encrypt similar veracrypt. Hidden partition on free space

  Are you sure? yes | no

eywdck2l wrote 06/22/2020 at 06:35 point

Thanks for taking interest in my project.  I would appreciate it even more if you could write grammatical sentences.  If you are saying that I should make an encrypted USB thumb drive, the thing is you would probably use thumb drives on computers, where you can use any software you want.  Thus there's less need for encryption in the hardware.  I am making an SD card adapter because devices like cameras usually don't allow you to install your own software to do the encryption.  As for hidden partitions, the first sector of the underlying storage is currently used for metadata and an MBR partition table is not possible.  Could you elaborate what you mean and explain why it's preferable?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates