[whizzter]

I think part of the entire design is that it's quite hard to detect.

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.

[05]

> 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,

- 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..

[ralferoo]

It's even easier to detect from that. From the project writeup Q&As: 'The firmware snoops for the string "password:xyz" and inhibits the write of "xyz". Otherwise, yes this would be very insecure.'

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.

[LorenPechtel]

Simply dismounting it won't prevent the stored write. You would have to dismount and then quickly power down. The safe-to-remove indication on Windows takes at least that long.

[femto]

If I was building a black box to detect hidden data on a USB stick, I'd include a feature whereby it measures power consumption and flags USB drives that don't consume the expected power for that type of drive.

[kulahan]

What an unreasonably complex device to imply you’re going to make 50,000 copies of and ship out to every border agent in the nation after telling them every SINGLE flash drive crossing the border MUST be scanned. That’s so much wasted time, energy, and money. Are you building a similar device for SD cards? HDDs? SSDs? External drives? You’re going to build a database of exact charge draws for every device in existence which happens to have some form of storage on it?

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.

[femto]

A complete USB voltmeter/ammeter costs $1.

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.

[marysol5]

I'm confused here, what are you trying to detect?

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.

[LorenPechtel]

Power use is not deterministic unless it's in a known state. The power hungry circuit is the erase and that's mostly a background thing.

[marysol5]

laughs in that flash drive I have that just gets hot instead of working

[fragmede]

https://usbkill.com/

[tptacek]

Can you flesh that out? If I've missed something and oversimplified the design here, I'd want to clarify that!

[whizzter]

The encryption/hiding is done by the firmware, hence..

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).