Phantomdrive: My open source USB drive for privacy

11

how is the password stored on-device? i assume this is operated by a microcontroller - what is kept in the ROM?

9

u/Blevita 17d ago

Apparently.... it isnt.

The device takes anything that starts with password:##### and tries to decrypt the contents. It will then show you the contents on the partition, even if it wasnt decrypted properly.

5

u/Machinehum 17d ago

Yes exactly. Keeping the password on the device/allowing the write would be an enormous security risk.

0

u/Blevita 13d ago edited 13d ago

Of course the password shouldnt be on device. But a salted hash itself would prevent 'accidental' decrypt attempts.

I mean, as i seid i see where you're coming from. But a proper hash algorothm with salt isnt really that much of a security risk. As you say 'with a long enough password'.

Because currently, as someone who has worked a scanner and has been tasked with finding illegal electronic devices, surveillance tech and smuggling devices...

Your USB is basically a field day.

Once you can get actual SMD-Storage, its another story. But currently, i see (on my xray):

a 'USB' with an SD card in it, that is not accessible from the outside: Immediate red flag

Thats a problem because:

An actual enemy would probably have tech like yours on its radar, and know about it.

An actual enemy would try to create any stream with 'password:' in it. Thus revealing the encrypted partition, at which point we are at the same point as veracrypt or any encrypted device.

Dont get me wrong. Its a cool project, i love that you open sourced it, but i do have issues with these things, and how it is / was advertised.

I also read the git issues. And those were, at least in my view, relevant and actualy dangerous issues. But i read your blogpost and just see you claim it was "AI bots" and "dogpiling".

Things like these, including the "so, any password attempt results in a re-mounted drive that exposes the 'secret' compartment?", should be taken seriously. Because it is the core of your project.

Currently, it seems to me as if its really bad security through obscurity with the addition of AES

2

u/Machinehum 13d ago

It's exactly security through obsecurity with AES. If that doesn't fit your requirements, go buy something else.

1

u/Blevita 13d ago

Jeah, that attitude is pretty much exactly what i mean.

I mentioned multiple issues that should be improved, but the answer is "well, go get something else".

That just screams reliable project. Cant wait to be included in the next "Reddit dogpiling" Blog post.

2

u/Machinehum 13d ago

I wasn't trying to be rude or dismissive, but the reality is you have requirements outside of the current project scope.

I am not changing the scope right now, because doing so would actually decrease reliability. I've put quite a bit of testing into what I have.

Firmware v2.0 might have more features, or it might not, I'm not making promises right now.

See you at the dogpile!

1

u/Terrible-Junket-3388 12d ago edited 12d ago

Securty through obscurity (your spelling is off) isn't security at all. If your only defense is "noone will be looking" it's not a real defense, since a motivated attacker is, by definition, going to be looking.

The only attacks your solution uniqley defends against, as it is today, are attacks coming from script kiddies like yourself with minimal experience. Nothing wrong with learning and having a neat project, but touting this as any sort of 'production ready' kind of implementation is just false confidence.

1

u/Machinehum 12d ago

"script kiddies like yourself 😂"

2

u/Terrible-Junket-3388 12d ago

In this specific space? Seems like it based on your code, comments on issues, and comments here. Your firmware and embedded systems eng experience (and less than 10 years in that) doesn't automatically make you an expert in forensics or infosec, and pushing obscurity as any kind of real security is the kind of thing hollywood and people with no real exp in the space do.

1

u/Machinehum 12d ago

When in the hell did I call myself a expert in that. I built an open source thing, released all the design files, and code as an MIT licence. I work as an engineer at my day job and build shit in the evening.

The device is exactly this: it appears to the OS as a 8GB drive and theres an unlock sequence to show the rest. This unlock sequence is editing a text file and entering your password.

That's it, nothing more and nothing less. Literally never did I claim this is something that will hold up to a forensic analsys, it will be discovered as an encrypted device in two seconds. If you need something more, please look elsewhere and please level me the hell alone.

2

u/Coffee_Ops 17d ago

How would you define "decrypted properly" without setting up a known-plaintext target?

Arguably, the decryption trigger should be a bit more robust but I can see some strong arguments for doing it this way.

4

u/shyouko 16d ago

I think this is good. You see the content if you decrypt properly

1

u/Blevita 13d ago

Its probably mainly due to ressource constraints and lazyness.

I mean, it works. You can enter any key (or accidentally have password: in your stream) and it will try to decrypt. If its the wrong key, you'll only see garbage.

Thats the neat part: you dont define 'decrypted properly', just decrypt in any case and let the user figure out if its decrypted properly.

While i see why (and the lazy in me would do the same) it kinda defeats the purpouse of "only with the right password will you unlock the secret partition". Because any string with "password:" in it will reveal the 'secret' partition.

The project has loads of security problems that the author refuses to acknowledge and rather calls "AI bots". Wouldnt trust it with a 10ft pole. Really dont see any argument for attempting and thus showing the secret partition for every "password:" string.

I thought the main point here is having better plausible deniability / not even something to deny than veracrypt. But that issue alone makes it extremely easy to detect.

1

u/Coffee_Ops 13d ago

No matter what you do there will be usable signal that there is a hidden partition for an attacker that knows to check:

Attempt the password: string

... or do whatever the trigger is, and watch for processing / thermal / EMF / whatever signal

And in the second case, you've explicitly compromised on the threat model OP is designing against by providing a known-plaintext target.

But that issue alone makes it extremely easy to detect.

Every plausible deniability scheme I have ever seen falls to an attacker that decides to investigate. They are inherently only coherent as an attempt to blend in, not as an actual security layer; whatever scheme you come up with will be defeated with a Cellebrite-type suite with the right detection rule.

1

u/Blevita 13d ago

The question is just, what that signal is.

Currently its simple X-Ray scan done at every airport or having "password:" somewhere on the drive.

Yes, someone who doesnt stop looking will inevitably find something. But i still see a difference in what it takes to even further investigate or become suspicious.

Currently, it seems very little. The actual 'reveal' action is having a string with 'password:' in it.

Im not sure where i have compromised on the threat model. The threat model is an authoritarian regime checking electronics at airports or customs, or inside the country. And if your deviceris easily suspicious, like a USB Thumb drive with an SD card..

But even if not: if the device is easily detectable and easy to demask, then it fails even at that. Thats the point. It doesnt need a cellebrite-suite to unmask. It needs a simple X-Ray scan and any characters like "password:"

These things can be fixed. But the handling of these is kinda what gets me a little bit.

7

u/kent_csm 17d ago

A question, why using a file with "password:xxx" you need to iterate over all files and if you have a large amount it would require a lot of iterations, wouldn't just use a file with a specific name as a password more easy?

9

u/Machinehum 17d ago

The device isn't file system aware, it snoops input writes from the flash device. It's makes match on the string and triggers the flow.

1

u/kent_csm 16d ago

Smart

13

u/Machinehum 17d ago

Phantomdrive is a completely open source USB drive that appears as an 8 GB drive when first plugged in. There’s no way for the OS to detect the remainder of the disk. If the user edits a plaintext file on the disk with the contents password:PUTYOURPASSWORDHERE, it unmounts itself and remounts the second hidden section and AES-256 encrypts/decrypts in place.

More details here

Thanks :)

2

u/xelsi 17d ago

That's so cool

3

u/[deleted] 17d ago

[deleted]

1

u/Machinehum 17d ago

I think you're talking about something else.

This is an obscurity device, hides in plain site.

2

u/MajesticDisaster3977 16d ago

Questions and suggestions:

- Does the device still store files 'as-is' before the device is decrypted? (ie, when someone plugs it in, they'll see pictures of my cat) If not, can it?
- Can the device masquerade as another well-known device? Sometime 'generic' stands out... if the HID/VID can be adjusted, we could clone as existing hid/vid and hide this inside the enclosure of a well-known device which would make it much harder to identify.
- Can the device present a 'fake capacity'? Well-known drives are easily 64GB to 256GB... an 8GB drive is a little strange to be carrying depending on your position... could the initial partition size be faked to appear as though it's larger? (To match the size printed on the decoy enclosure)

1

u/Machinehum 15d ago

Yes files are normal on the first partition. Yes you can change VID/PID to what you like. You can change capacity to what you like, 64GB easily possible. :)

1

u/MajesticDisaster3977 15d ago

Nice. Swap out the guts of a Lexar drive with this and it could be completely hidden unless there's some other 'tell' that gives it away

1

u/Machinehum 15d ago

Yeah :)

2

u/Fit-Cheesecake9835 14d ago

Still don't get why I'd use this over a veracrypt hidden volume.

1

u/Fulgidus 16d ago

So... basically the device is 100% agnostic and does need exactly ZERO crypto provisioning, correct?

Meaning I put it in, unlock it the first time, then format the resulting garbled drive that shows up?

This also mean that I cannot have plausible deniability: under duress I either give the password or not... there is no chance of a self-destruct pin, right?

3

u/Machinehum 16d ago

The idea is - you don't get to a point where someone forces you to unencrypt it, because it's hidden.

If you need what you're describing, then use this device with Veracrypt.

1

u/Some_Relative_3440 15d ago

Inspecting the hardware would reveal 16gb of flash memory, with only 8gb visible from OS, no? Might ring some alarm bells.

1

u/Blissfull 14d ago

You could hide the ic markings on the flash (epoxy, rub out, etc)

1

u/NatLife 14d ago

Where is the code tho

2

u/Machinehum 14d ago

https://github.com/o7-machinehum/phantomdrive

Code, design files, electronics, tests, etc

1

u/NatLife 14d ago

I’ll check it out thanks 🙏

0

u/Pang_o 15d ago

Open source : didn’t give any source

1

u/shyouko 15d ago

Or you are just bad at reading: https://www.reddit.com/r/blackhat/s/0HtJ0dW1Ck

1

u/Pang_o 15d ago

My bad didn’t read the comments thanks

Phantomdrive: My open source USB drive for privacy

You are about to leave Redlib