Secure SD card- 2 -SD card copier
Next logical sequel in our secure crypto-device series, necessary to securely copy and manage sensitive files, before and after encryption/decryption.
So, Alice has just prepared a few gigabytes of good random number OTP sequences using our RNG:
https://www.elektormagazine.com/labs/random-number-generator-150116
They are now stored on the SD. She can give a copy to Bob hand-to-hand, or she can also use the tamper-evident paper-mail box to send it to Bob using any snail-mail service:
https://www.elektormagazine.com/labs/tamper-evident-paper-mail-box-for-secure-distribution-of-one-time-pads
But wait, how is she actually going to make that copy? Using a PC or any general-purpose computer for copying SD cards with security-crytical info is a "crypto-suicide" by itself. So, this copier device comes in to fill in this security gap! Besides for copying one-time pads, this device will be a complete secure FAT32 file-handling system with the following features:
1.) Direct secure copying from SD1 to SD2. Reaches a speed up to 20Mbit/sec, tested at 32MHz DMA transfer. Entire SD card cloning is also possible.
2.) Comparison and verification of the copied data.
3.) A simple text editor, to securely type simple text messages and store them to SD card before offline encryption with our OTP crypto device:
https://www.elektormagazine.com/labs/one-time-pad-otp-crypto-system
4.) Other basic FAT32 file functions, like delete, rename, format etc.
This can also be used as a secure link between one "dirty" and one "clean" SD card - will copy only the selected data, sector-wise, and keep any infections out of the "clean" part of the system, so a "dirty" card, with encrypted data only copied, can then be securely put to a "dirty" PC or smartphone to e-mail the encrypted files.
Hardware is tested in "spaghetti-breadboard" version, software needs to be completed.
Discussie (2 opmerking(en))
Teun Kloosterman 4 jaar geleden
https://media.ccc.de/v/30C3_-_5294_-_en_-_saal_1_-_201312291400_-_the_exploration_and_exploitation_of_an_sd_memory_card_-_bunnie_-_xobs
lux36 4 jaar geleden
SD cards have many inherent shortcomings (speaking about their use for secure systems), they can be used, but only with certain limitations.
This is why I decided to make a cassette tape interface as well, since tapes beat them all in any security aspect:
https://www.elektormagazine.com/labs/secure-sd-card-2-cassette-tape-copier
Since all the modern day MCUs and FPGAs are also black boxes, I started this project as well:
https://www.elektormagazine.com/labs/crypto-dev-shield-for-zmc-zilog-z80-system-1
It is very difficult to plant a hardware Trojan inside a Z80 system, especially with UV EPROM.
My tamper-evident box was published in the last issue of Elektor. Read the article, in the end I also announced to make (I have actually already completed and tested the prototype) an additional protection against hardware Trojans as an add-on (can't use a Z80 system here, it is too big).
If you are interested in this stuff, maybe you can propose another solution...
lux36 5 jaar geleden
-ATmega328P MCU x1 pc
-SD card and holder x2 pcs
-74HC125 buffer x2 pcs
-74HC86 XOR gate x1 pc
-74HC393 latch x1 pc
-32MHz XTAL x1 pc
The basic idea is to make a direct DMA transfer of data between SD1 and SD2, by clocking them at 32MHz, through IC5C gate ("/f" gate signal). 74HC393 (double 4-bit counter) divides the 32MHz to 8MHz for the MCU clock. MCU gives SPI commands to both SD cards and then reroutes the data chunks through 74HC125 gates directly from SD1 to SD2, at 32 MHz SPI clock. The hardware part is tested completely, the DMA at 32MHz works well. For fast DMA copying (err... "fast" meaning faster than USB 1.1 :) the SCK is passed through IC7B and IC7A - the R25-R3-R2-C8-C6 network is adjusted to create a 30ns delay between SCK and SCK2 - an SCK pulse first needs to pass through IC5D, for a data bit to appear on pin 7 of SD1, then it needs to pass through IC5C and arrive to pin2 of SD2, so SCK2 needs to be properly delayed for this to work.
For DMA verification/comparison between SD1 and SD2, the SCK is passed through IC7C, so SCK1 and SCK2 are equally delayed related to SCK - the data bits on pin 7 of SD1 and SD2 will appear almost simultaneously and arrive to XOR gate IC3A. If the two bits are different, the output of IC3A will go high and QA output of IC6A will latch. It will be kept high long enough for the slow MCU to read it (through PC0 input ) at the end of the data "chunk" - both IC3A inputs will stay locked high through D5 and D6, so no more triggering pulses can be passed to IC6A, until the MCU reads its PC0 input and gives a command on PD4 to clear the IC6A latch.
Working version of the MCU software is also attached, FAT32 functions are still under development.
20 Mbit/sec is rather slow by today's standards, but this project is primarily about security, not speed - cheap, standard and ubiquitous components, all open-source and easily obtainable - our usual design philosophy. Alice can surely wait 20 minutes to copy several gigabytes - after mailing the OTP copy to Bob, they will be able to securely communicate for many years...
Working version of the MCU software, raw sector functions implemented and tested (238kb)