29 comments

[ 2.9 ms ] story [ 47.9 ms ] thread
Good stuff! If I remember correctly there was company at Defcon selling memory cards that had this feature built into them a couple years ago?
If you're using off-the-shelf "hidden" encrypted volume schemes, you're not going to be evading state-level adversaries; if you can find these projects and conveniently use them, state vendors can and will write scanners that find them. They're paid to do it; new detections are how they get to charge for maintenance and new versions.

Then you're down to two issues:

(1) Concealing an encrypted volume jacks suspicion way up; whatever pickle you were going to be in if you just kept an encrypted DMG on your desktop, you're trebly in now.

(2) Your actual security comes down to the strength of the encrypted volume, and this is 20-year-old encryption. He can't use a memory-hard KDF because of his BOM, which, like, fair enough, but that doesn't change the fact that this KDF is probably ~50x faster than standard bcrypt hardness and on realistic human passwords is probably crackable in minutes-to-hours on a dedicated rig.

I winced particularly at the observation that the hardness was set where it is because of how long it takes to open the encrypted volume on this hardware, because whatever scheme is being used to run the KDF now, an attacker won't bother; they'll just copy the bits and attack them on serious hardware.

Point (1) isn't meaningful if your adversaries aren't states. It might make sense to have a hidden encrypted volume for the same reason you'd want an encrypted safe. But point (2) applies to everybody.

At the risk of being dumb, wouldn't an easier solution be physical? ie have a usb stick with two actual "disks" and a an appropriately obscured physical switch to define what plugging it in actually does?

Again, this isn't going to beat someone who knows you've got something to hide, they can physically deconstruct/analyse the drive, but at least it's not going to be found by automatic scanning/software etc?

Plausible deniability requires people to believe that you don't know about any so called "hidden" volumes. That goes out the window once you buy Hidden Drive from Hidden Drive Company.
Rule no. 1: you don't announce your security by obscurity methods :)
A very interesting solution!

If you can do without Windows, I would say formatting a USB with a first partition as an 8 gig DOS partition and a 2nd partition as Linux LUKS may work just a good.

But a few people may know about Linux. So if on OpenBSD, you can create a second OpenBSD encrypted partition. I think that will probably look like garbage to 99.999% of the people you may be hiding from.

Be aware, if dealing with a sophisticated Gov agency, all bets are off.

Might as well be rot13.

If you rented 8 MI300X's or the nvidia equivalent, I don't even think an unreasonably long password would matter.

It should finish quickly enough that you would be upset with all of the money you have now wasted by having to commit to a month of utilization

>Let’s now assume our attacker has a really powerful machine, has gotten your salt and now will compute their own “table”.

You should be using a TPM so such an attack is impossible. The TPM should be what is rate limiting the guesses. You don't need a KDF here.

There are other issues with AES-CTR - an attacker can flip bits at chosen offsets in the plaintext without knowing the key. For example, if they know (or can guess/infer) what offset the relevant portion of the `sudo` binary is at, they could flip the branch instruction responsible for password checking. This can be done in one step, as opposed to the multi-step plaintext recovery attack described in the article.

With XTS, the attacker is forced to completely garble a whole block at a time.

>Many places don’t respect privacy laws, in certain situations you may be forced to unencrypt your media, or worse, assumed to be guilty. A Veracrypt hidden volume is useful in the former situation, but not the latter.

> ...

>Due to AI demand the cost of eMMC memory is unusually high, so I chose to go with an SD card for memory. Someone will find your SD card if they tear it apart, but of course everything is encrypted.

So which one is it? It sounds like this is trading off between "having veracrypt installed on your computer" vs "having a custom usb drive". In other words, hiding something in software vs hardware. I'm not really convinced hardware is better. The hardware device is going to get discovered if the x-ray it, not least because of the super suspicious embedded sd card reader. Even if we concede that hiding in hardware is better, surely you can just use whatever trick to hide the software (eg. putting in a secret password mounts a second drive with veracrypt)? That way you don't run into the crypto issues that the parent poster mentioned.

Dude. Veracrypt. Hidden volumes. This is an old and well-solved problem set.
Just a heads-up, your blog post has a broken link for

> As for the security of the device, I’ve verified things with functional tests like this

Otherwise great project!

Encrypted USB drives, there are definite legal uses, but like others have said, it raises suspicion.
Could use an Opal or Pyrite drive connected to a USB caddy and sedutil-cli to manage it.
I want something like this in a keyboard: a completely hidden drive that the OS cannot see until I type in a certain string of characters (password) to activate it with a separate string of characters to deactivate it.
That is actually what my company built. The primary purpose was for encrypted messaging, but it also acted as secrets store and password manager. The great thing about it being built into the keyboard is there is no chance for a rooted host to intercept passwords/messages etc.

https://www.anomie.tech/

(comment deleted)
Can this be done on boards with the same layouts as known commercial USB keys i.e will imaging just show this to be what it is?
You would need to re-engineer this to not have an SD card. And you'd also need the MCU where you can't just read off the firmware and decompile it to see the encryption routing.
It might make more sense to embed the encrypted volume in some generic USB device. Require some condition to be true before the volume appears to the host, otherwise it's doing power or camera stuff.

A drive would draw more scrutiny than a camera or powerbank or even a cable. https://shop.hak5.org/products/omg-cable

Reading this made me think that a good solution would be to write your own filesystem as a mod if an existing system. It just needs to differ enough from existing recognised systems. Then nobody would be able to read except you and the encrypted data effectively doesn't exist. It just would show up as an unreadible partition.
This only makes sense if the underlying thing that gets exposed after you put in the password is a block device... I'd want to then be able to have that encrypted with LUKS myself, I don't want to rely on this homebrew stuff.
Just chiming in that there are lots of threats that aren't state level attackers. In fact for most people the threat is never gonna be the border guard. It's your parents, an abusive partner, a sibling, a school admin or an employer.

Just because something does work vs the NSA or the FBI, that doesn't make it useless

Why not decouple the special card reader from SD card instead then? I mean it's unsuspecting already, but it probably even less sus since readers are cheap and never a target.
Another day, another one of these projects.

>With Phantomdrive, hopefully you’ll slip past authoritarian government representatives, corrupt police, and anyone else that doesn’t respect basic encryption rights.

Apart from the SD card on the board making it obvious something is going on, and the iron bar comes out

We know that crooks are selling fake drives where the size is over-reported. Shouldn't something that tries to be sneaky under-report the size instead? Not just in the partition.
> "Many places don’t respect privacy laws, in certain situations you may be forced to unencrypt your media, or worse, assumed to be guilty. A Veracrypt hidden volume is useful in the former situation, but not the latter. This is why I made Phantomdrive."

Can someone explain to me how this project is different than a Veracrypt hidden volume and also what he means that Veracrypt wouldn't help if you are assumed to be guilty? I thought Veracrypt hidden volumes aren't visible.