Transparently encrypting SD card adapter

Description

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.

Details

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: https://github.com/eywdck2l/cvtm-format

The code: https://github.com/eywdck2l/adapter-parts

Project Logs

Collapse

We have some basic functionality

eywdck2l • 06/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

eywdck2l • 01/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

eywdck2l • 06/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.

Discussions

Frix wrote 10/11/2021 at 21:09

Good day,

It seems that Swissbit has commercialised a custom SD card with an embedded 'secure element' which manages encrypted access to the storage space on the card. The price for an 8GB SD card is $46 at https://www.sparkfun.com/products/16899

The product has some limitations, since its assumed that the owner has full access to all the security keys. This will give the owner access to the partition with the OS and applications.

I would like to sell a product where the key management is split. The factory lock the partition of the main OS&app and the user manages the user data partition with the key that they configure. A new user key can be programmed, which will result in the user partition being encrypted by the new key, leaving the main OS & application partition unaltered. The user will be able to interact with the application via a UART but not have access to the OS or application binary (executable) itself.

Can you please provide me with an approx. hardware price when using a FPGA + regular SD card, as used in your project?

Are you sure? yes | no

albertodonda wrote 04/23/2021 at 21:22

Hello,

I'm very interested in this project.

Any progress?

Are you sure? yes | no

nooitaf wrote 07/07/2020 at 01:38

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

[deleted]

[this comment has been deleted]

eywdck2l wrote 06/26/2020 at 00:34

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

[deleted]

[this comment has been deleted]

eywdck2l wrote 06/22/2020 at 06:35

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

Transparently encrypting SD card adapter

Description

Details