My USB Drive Has a Hidden Encrypted Vault
rootkitlabs.com
rootkitlabs.com
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.
This would evade 99% of them.
Most "state-level" adversaries are just high school dropouts working border jobs told to "investigate suspicious things".
I once had a police officer literally raid my room for drugs during a massive party we were throwing in university, for example.
They took everything. They found everything. Everything except for the $1,000 piece of drug paraphernalia I had sitting right out in open view in the middle of the apartment... the Volcano vaporizer.
It didn't look like anything they had seen before so they didn't think anything of it.
Same would be true with this USB drive in 99% of border crossing privacy invasions... plug in USB, ask for password, read it/copy it/whatever... they're not taking it apart and performing open heart surgery on a $5 USB drive at the border.
They might throw it out... or keep it or something... sure... but in general... this is a hell of a lot better than a regular USB drive imho.
You will miss your government's incompetence when they start rectifying these failures. I know I do.
They are the tyrants who oppress us with a clean conscience. They never rest and have infinite money. Their occasional episodes of bumbling incompetence is the only respite, but those won't last. Especially now with AI to think for them.
I guess it's human nature to build the Torment Nexus.
But while states realistically can crack most anything it doesn't mean they can crack *every*thing. There are simply too many flash drives crossing the border every day.
But there is a big flaw I see: 8gb. You're carting around an 8gb flash drive these days??
Lavabit would like to enter the conversation.
That's not the actual story (like, that happened, but all it did was provoke the DOJ), but it's remarkable to see someone cite that as a success for Levison.
They pay other people to notice this stuff for them!
Money, even at state level, is not some infinite resource (and neither is time).
States put effort into what they consider worth investigating - no state strip searches every incoming traveller, and goes through every item in their possession - it's possible for them to do, and if they did they'd find a hang of a lot more contraband, but it's costly, time consuming, and politically risky.
If the idea is that there's no point in encrypting anything on a USB stick, and you just hope they don't look at it at all, sure.
But there is no threat model here that includes "check the USB stick" and does not automatically lead to finding and breaking "hidden" content.
SD card the author says was added to offset the cost of eMMC but would presumably stand out as anomalous with whatever AI is classifying the scan
But saying that, the sheer amount of fake flash storage out there now, that's just a glorified USB-SD reader in a box.
1: Reads/Writes are just routed to a COTS SD-card. 2: Unless the (correct?) password is detected in the write-data that starts the disconnect procedure.
The only way to detect it from what I can see is to profile writes then append a "password:" string multiple times to measure the write-delay, only works if the CPU cost is large enough to overtake the SD-card measurably and some constant-time optimizations should make it more or less undetectable.
It's a clever design and I think it should be possible to optimize to become more or less unrecognizable.
1: The drive more or less looks like any boring old usb-stick, it isn't even uncommon for cheap fake Amazon sellers to sell sticks with SD-card's as faked large drives (so even with X-ray inspection it doesn't look too much out of order).
2: To a computer, since the firmware presents a regular UMASS device, there isn't anything telling the computers over-the-wire protocol that anything is amiss (since the real size is hidden by the firmware and regular accessible blocks just behave normally).
So, short of an intrusive teardown of the device to read the true size of the SD-card and even knowing the presence of a hidden volume, the only over the wire that can help discerning this from a regular drive is timing attacks (And as you notice from this thread, people are jumping on to suggest solutions to minimize or even remove that).
- Have the first check be a simple 8bit hash that filters out most passwords in microseconds, or use a customizable prefix instead of “password:”.
- have your password checking thread run in background at idle priority
- when you get an async password match, force usb disconnect and reconnect and the system will rescan the bus and mount your real drive.
Short of adversary dumping drive firmware (or them figuring out your hn account t, having a LLM scan the messages and finding this conversation) it’s not really easily detectable..
So detecting this drive is just a matter of writing "password:anything" to the drive, unmounting, remounting and checking the file you just wrote. If it's not what you wrote, then you have detected the existence of this drive.
The parent comment was correct that if this was mitigated by testing if the key is valid then you can detect it by checking for timing differences between writing a sector that starts "password:" and one that doesn't. Moving the password check async just means that you run the risk of having the real password written to the SD card before it was detected.
If you buffer that sector from being written, then you might be able to detect it because the write was faster than expected, or if you write the modified version and go back and overwrite it with the original if the check fails, then you will slow down a different subsequent access, again which would be detectable. This would also invalidate one of the design goals of never keeping the password in memory, only the derived key.
Having a customizable prefix is possible, as the project is open source. Personally, I'd be tempted to make this possible on the base build by storing the prefix in the hidden area of the SD card.
Fucking up every single import and traveler on the off-chance one in seven billion scans detects one of these devices and, further, carries some data the US cares enough about to chase down to this degree?
No. Nope. Nuh uh. Insanely unreasonable. You will get ONE at a station, which you only bother to use if you can convince your $12/hr employee to even give a shit. Literally an insane proposition.
https://www.alibaba.com/product-detail/MX17-Current-and-Volt...
Ignore the case and connector, on the basis that the circuit will be integrated into a larger scanner, and the cost will be substantially less. Most USB controllers already monitor current, so even the <$1 circuit probably would not be needed. The main cost would be the manufacturer putting together a database of power consumption figures to allow a pass/fail test.
Law enforcement, airports and so on already boxes to scan USB devices. They don't use them for every USB drive, just those that they decide they have cause to scan.
You're not going to get the uA level of detection to be able to decipher between a R/W operation and some sort of crypto in the CPU with these cheap components.
What is the problem? I have promotional flash drives from 1 Gb up to 8 Gb, that I use to store music for my car, or to carry pdfs to print in shared printers. I don't care if they break or get lost. I know people that carry similar promotional items with similar capacities. What is suspicious about 8 Gb drives? Maybe the lack of external branding, like "SanDisk" or "Walmart"?
I'd been using it to boot the debian installer from.
Why is that is a long story. And it includes both general inefficiency of state apparatus, but also the fact that repressive systems aren't optimized for getting evidence (or just correct information) in most cases.
The state-level threat isn't just about the direct employees' competence. They also have the funding to purchase tools made by people who really know what they are doing. Think of things like Pegasus spyware or Darksword iPhone hacking.
I can believe that a keystone cop wouldn't know the difference between a bong and a flower vase, but border crossing guards will know a USB drive when they see one and pass a copy of it to someone who knows what they are doing.
https://prodefence.io/news/pegasus-spyware-operating-costs-c...
Just to say, I know what you mean.
Saying that, any proper investigation would read the firmware from the flash and identify the decryption routing anyway
There is a world of difference if you get searched by your local police and a country level agency.
There are military units dealing with forensic investigations they have 100x or 1000x more budget and much smarter people.
But they don’t care about some drug dealers. They don’t waste time on silly stuff.
The military is stuffed full of grunts who are just there for the pay, and in many cases, conscription.
You can throw all the money you want at something, it doesn't make it work, just look at the US military
If you're intercepted with anything of value what you want is to rapidly destroy it.
This was the big problem I found when I was trying to figure out a secure way use Yubikeys: they're both long term unreliable, and short term impossible to wipe or destroy fast enough.
Literally a printout of 1 time passwords has better security properties in an adversarial situation.
For a storage device what you want isn't a secure store, what you want is a pin pull or switch which wipes it instantly.
Even dumb cops know how to use a Cellebrite machine.
> Most "state-level" adversaries are just high school dropouts working border jobs told to "investigate suspicious things"
Famous last words. Do not underestimate the police, they have been doing this longer than you, they typically have highly sophisticated people working for them, and at the border they have enormous resources behind them.
I kinda assumed this was a solved problem now, up to the information-theoretic limit. Just create a FAT32 fs (for example), put some boring decoy files on it, and then unmount it. Traverse the FAT to map which blocks are in-use vs not-in-use, and use the not-in-use ones to store your encrypted data in some arbitrary header-free indistinguishable-from-random format. The result should look just like someone had set up a FAT filesystem on top of a securely erased drive.
If anyone ever mounts and subsequently writes to the FAT volume they'll clobber your data - oh well.
The remaining issue is that you need some special software on the host to mount the hidden volume, which itself raises suspicions. This could be solved by bundling it with OSes by default.
Apple and Microsoft? I trust apple a bit more and MS none at all.
Linux is a bit different because the kernel is the OS, but only a small part of all its different packages. Also you'll have to watch it like a hawk because nation states will constantly try to compromise it.
I thought of a much simpler approach though. Personally, it's completely normal for my USB drives to contain some OS installer dd'd to the first few GB, and to be wiped with urandom between uses. The installer .iso is typically immutable and will never expand beyond its initial size. Rather than mess around with block mappings, I can just use last n GB as a hidden storage volume. dm-crypt "plain" mode is headerless and can be configured to start from some offset within the underlying block device.
The only giveaway here might be forensic examination of the drive's internal wear-leveling data.
FAT is a filesystem, it isn't hardware. They're talking about the table storing numbers of bad sectors/blocks.
The system you just described is exactly what TrueCrypt did, where if you overwrote the capacity and into the "hidden" data, you'd end up killing the hidden partition.
Does the forensic software read the whole physical flash drive or just the logical one? They might if they want to get deleted files. Can they detect that there are lots of failures?
You can ship my genius award to me at X..x>X..X.
Now you can claim that any encrypted drive (which just looks like pure noise if done correctly) is a drive that was just formatted.
No, there isn't.
https://edri.org/our-work/edri-gramnumber7-16decrypt-data-ca...
Encrypted data should be statistically indistinct from random noise.
It's an information theory thing. Everything in the ciphertext should be sitting at maximum entropy.
There are even statistically measurable differences in the garbage written across versions of a tool or OS, which, unlike the invented scenario above, has been successfully used to place a time window on when exactly someone destroyed evidence.
"Garbage" isn't the same thing as random noise.
I have looked at the entropy graphs of encrypted data commonly. It's one of the first things I look at when looking at a new firmware image I haven't seen before.
Merely that, unlike in the invented scenario above, statistical differences in the random garbage that gets written to a disk across different tool or OS versions has been successfully used to place a time window on when exactly someone destroyed evidence.
A LUKS volume with a detached header is indistinguishable from random data.
Compare the entropy graph of /dev/random against a LUKS volume with a decrypted header, and you will see no difference.
And it actually _does_ make sense for formatting utilities to offer it, as this is a good way to ensure that data is really gone after formatting (writing all 0s or all 1s could leave information at the physical layer; and any intermediate layer could not compress random data much so the data must be overwritten).
No there isn't. even people who have been prosecuted for refusing to decrypt data, it takes a lot of working by the prosecution to PROVE it's encrypted and not just "random data".
I'm from the UK and have been in court with encrypted data myself.....
Sources or names?
How would those scanners work? If the device presents itself as a bog-standard usb drive, with all the same identification strings, etc., and the hidden volume is completely inaccessible until triggered (e.g. like swapping on sd card for another), it seems like such a scanner would have to rely on things like precise timing and performance characteristics vs what the drive presents as, and there are a lot of legitimate USB drives out there to characterize.
Edit: and if that's the case, maybe pick a lower-performance drive to mimic (and use its case). Then have some kind of characterization step to add custom delays to match its timing and performance characteristics.
> (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 agree. What's the point of doing on-device encryption? Seems like this device should only do the volume-swapping bit. Once it "it unmounts [the unhidden section] and remounts the second hidden section, you should have to decrypt that hidden section with soemthing like VeraCrypt.
Time to bust out the old "Can't tell if this MP3 is a steganographically important encrypted file or just a Nurse With Wound EP" trick then.
And my mother would duly sift through these forwarded meme images for the dankest of the dank, and then she would eagerly forward them to her friend from church, who also had a large distribution list, and so that is how I became a conduit for the dankest GenZ Facebook memes to the boomer generations in another state.
And then I became a Cybersecurity educator, and our curriculum contained a module on steganography, and we all had the students do a proof-of-concept where they cryptographically embedded secret messages in innocent-looking photograph files.
And that is where my meme-sharing came to a screeching halt, and I deleted every meme I ever collected, and I unsubbed from every possible source, and I began completely ignoring memes, and my mother's distribution dried up. Good god that was absolutely shocking. I have no idea what sort, if any, secret messages I was responsible for, and I hope that we never ever find out!
The risk, of becoming a mule, an unwitting accessory to some evil cause, was just far outweighing the rewards of sharing dumb crap with my mother, you know?
Normally would not comment just to make fun of someone but this is just a wild take, how could you be sure that HN is not full of coded messages?
If your pastime involved trading envelopes with other collectors of envelopes, and you started passing along a bunch of sealed envelopes with unknown contents, how would you feel? Or if you enjoyed well-constructed cartons, and you found yourself trafficking in sealed cartons with unknown contents? That would basically make you a shipping, receiving, and logistics provider. Anything at all could be in those parcels. Why do it? Why open up to risk?
The main point here is that there was no point to my trading in memes. It was recreation; it was optional; it was totally a lark with my boomer mom and her audience. I had no reason to look at these memes and I had no reason to forward them on. Sure, the risk was very, very low that anyone "evil" was encoding "secret messages" or "targeting" anyone I knew. But since I had no reason to engage in this activity in the first place, why not quit? Why not just distance myself? Thereby removing 100% of the risk.
I don't agree with you at all, nor do I understand how your mind works, but I very much appreciate you taking the time to respond and respect your commitment not to facilitate anything nefarious even though we disagree.
Basically evading a state-level actor is going to be hard. People do get lucky but to evade them in a straight-up contest you need to very clever (if it's possible at all). Given that, I just dunno how useful it is to emblazen warnings on AES-based encryption schemes that it won't fool the NSA. Either the person reading it is not technically equipped to evaluate the claims and may be scared off of a solution that protects against some adversaries while searching for an impossible zero-config state-proof solution. Or the person already knew as soon as they saw 'AES' that this isn't the project they need.
I don't mean to denigrate the inclination to highlight weaknesses like this - good communication around this is genuinely challenging.
I think this post is a fun technical case study on its own. It only takes on urgency because it literally markets itself as a tool to slip past state adversaries. I think it's important that people understand that it isn't the state itself that's going to take the time to detect something like this; it's some commercial forensics vendor they use automatically.
Like if they have good tools for profiling you from your posts they'll totally expect the OP to have some interesting hardware and stories to tell. Contrast that to just being some boring guy who has a cover story that happens to be true or the colorful character who doesn't really have anything to hide but who can keep spooks talking for hours.
50x is not the decider between allowing a good password and allowing a bad password. It's a tiny little nudge.
Edit: To put "little nudge" another way, if you have a 1-10 scale of password quality, most steps in that scale are going to be more than 5.6 bits apart.
Then use the rest of the drive (~1Gb) for a hidden TrueCrypt volume with a secure key.
I'll also note that anyone plugging this into a forensics machine is going to have a bit of a dilemma: Perform write tests, or not? Because if they probe it with password:... attempts to check on timing leakage, that's potentially damaging evidence.
You have to always keep a clean hashed copy, and then work on copies from there.
I use 100k rounds instead of 600k https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
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?
Just because something does work vs the NSA or the FBI, that doesn't make it useless
A drive would draw more scrutiny than a camera or powerbank or even a cable. https://shop.hak5.org/products/omg-cable
With XTS, the attacker is forced to completely garble a whole block at a time.
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.
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.
The OP had a version that is invisible.
But the big question would the guards even know about fdisk type utilities ?
> As for the security of the device, I’ve verified things with functional tests like this
Otherwise great project!
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
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.
>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
> ...
>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.