There was a time that encryption was almost a dirty word; a concept that really only applied to people with something to hide. If you said you wanted to encrypt your hard drive, it may as well have been an admission to a crime. But now more than ever it’s clear that encryption, whether it’s on our personal devices or on the web, is a basic necessity in a digital society. The age of Big Data is upon us, and unless you’re particularly fond of being a row in a database, you need to do everything you can to limit the amount of plaintext data you have.
Of course, it’s sometimes easier said than done. Not everyone has the time or desire to learn how the different cryptographic packages work, others may be working on systems that simply don’t have the capability. What do you do when you want to encrypt some files, but the traditional methods are out of reach?
Enter the latest project from [Dimitris Platis]: Cryptopuck. By combining the ever-versatile Raspberry Pi Zero, some clever Python programs, and a few odds and ends in a 3D printed case, he has created a completely self-contained encryption device that anyone can use. Stick a USB flash drive in, wait for the LED to stop blinking, and all your files are now securely encrypted and only accessible by those who have the private key. [Dimitris] envisions a device like this could be invaluable for reporters and photographers on the front lines, protesters, or really anyone who needs a discreet way of quickly securing data but may not have access to a computer.
The hardware side is really just the Pi, a switch, a single LED for notifications, and a battery. The real magic comes from the software, where [Dimitris] has leveraged PyCrypto to perform the AES-256 encryption, and a combination of pyinotify and udiskie to detect new mounted volumes and act on them. The various Python scripts that make up the Cryptopuck suite are all available on the project’s GitHub page, but [Dimitris] makes it very clear the software is to be considered a proof of concept, and has not undergone any sort of security audit.
For some background information on how the software used by the Cryptopuck works you may want to check out this excellent primer from a few years back; though if you’d like to read up on why encryption is so important, you don’t need to go nearly as far back in time.
Imagine non tech savy people using this to organize protests. Now imagine this device was modified by an enemy of the protesters to weaken security and add some kind of watermarking like implemented in NK’s red star os. I’m not saying this is a bad thing, but whenever somthing security related is simplified and trusted by people who don’t understand it…
It still is insanely cool!
as has been said at defcon- rule one of civil disobedience is: Don’t f*ck it up!
Nope.
About the case: another ugly 3D printed cuboid for instead of using a nice standard prototyping boxes with a dremel.
Beauty is not objective. Personally, I am much more likely to have a 3d printer and filament on hand than an appropriately sized prototyping box. I typically find that there is not enough gained, aesthetically, by using a standard box to justify the increased time/labor/cost for someone who already owns a 3d printer. Doubly so for a project like this, where aesthetics serve no function other than to increase perceived value.
Why bother with a file structure storage file etc?
I would understand if the aim was to allow for incremental addition of unencrypted files,, but this looks like a one shot protect, unprotect implementation. Just store the file structure by compress the entire drive, then encrypt the compressed file. There are compression formats that store the file permission, owners, dates etc.
Thanks for the write-up Hackaday! :) A discussion on the project is taking place on reddit: https://www.reddit.com/r/raspberry_pi/comments/75o3s1/cryptopuck_pocketsized_encryption_for_your/
“There was a time that encryption was almost a dirty word; a concept that really only applied to people with something to hide.”
Like being a G-man.
…I’m sorry, folks, but I’m all out of tin foil…
https://imgs.xkcd.com/comics/security.png
Just a thought, If files can be stored using one the security keys in the pair and the other isn’t needed, one could simply not include the other key along with the device. That way the file could only be accessed by those back at “headquarters” where the sibling key resides. No amount of $5 wrench bludgeoning could lead to accessing that key. I wonder if the setup could be made functional with just one of the two keys as a kind of file drop box, sort of like a high security cash box at convenience stores.
Entropy?
True RNGs are not cheap and with little to no moving parts in or attached to the Pi I imagine there is little to nothing even close to random to provide entropy…
What about grabbing a selection of stock prices, run it through some hash algorithm. Theres a lot of data there and it varies all the time. Alternately a $5 usb camera in a dark box the a radio active source should make for some wildly random data.
True RNG’s are as simple as a diode or radio tuned to white noise static.
http://iank.org/trng.html
As for a Pi they do have HRNG’s available
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=19334&p=273944&hilit=hwrng#p273944
and
https://www.raspberrypi.org/forums/viewtopic.php?f=33&t=127706
“Just replace “/dev/random” with “/dev/hwrng”
That’s from 2013 & 2015 so and it’s built into the Pi’s SOC.
I don’t have a Pi to check the RNG function but I am reasonably sure most hardware providers have such things I know AMD and Intel both do. Today it’s more common to have a true HRNG system available.
The Pi actually has a hardware RNG onboard that uses reverse bias transistor noise. All the benchmarks I’ve seen for the Pi RNG say it does a very respectable job, and at the very least is certainly an improvement over the standard PRNG setup most machines are using.
Good to know! I will have to check that out; maybe more hardware manufacturers can take note
Unfortunately, I can see a few problems: USB flash drives typically don’t erase cells until absolutely necessary (i.e. immediately before a write). So erasing the unencrypted files is likely leaving them around in plain view. Even if you fill all the empty space with random junk, there’s usually an extra 20% capacity that is used for wear levelling.
USB flash drive manufacturers often provide tools to securely wipe their drives, but then you’re not going to have a generic solution that can accept all drives.
I’m not sure why symmetric encryption is done with a randomly generated key, followed by asymmetric encryption of the generated key? Why not just do all the encryption with the public key? Then if the process aborts half way though, you can at least decrypt some of the files?
For preserving the file structure, why not just zip the contents first? zip can output to stdout so you don’t need to save an intermediate file to disk.
Asymmetric encryption is much more computationally expensive than symmetric. By combining approaches, they get near equivalent privacy without the computational overhead.
…except that they don’t, because this is already how PGP works behind the scenes: it generates a one-time symmetric key which is used to encrypt the data and is then encrypted with the asymmetric key. He’s basically just re-implemented PGP, but without any consideration for all the side-channel attacks.
Besides, even if the more computationally complex asymmetric encryption was used for all the data, the bottleneck is _definitely_ going to be the USB2.0 comms, not the CPU.
Read that as ‘cryptofuck’ at first