Hacker News Reader

Comment by tptacek | Hacker News Reader

This is self-soothing, not a real security plan. It doesn't matter how competent a security agency is, because there's a whole ecosystem of vendors selling into that space; knowledge of how to attack encrypted disks like this is outsourced, and, importantly, those firms have incentives to mop up even random stuff like this, because vendors will be selected in part based on lists of how many different circumvention and privacy tools they can detect.

View on HN

You are right in a laboratory way of let's-assume-perfect-adversary, and you're not in a how-it-really-works way. I simply have my own RL exp in a bad repressive country on this topic, and my claim that e.g. hidden volume works most of the time. Like any tech it will stop being useful eventually, but it has been saving people for quite some time.

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.

This isn't stand-up-to-state-actors security. This is keep-state-actors-from-noticing security. They know you're guilty, they'll get it. The XKCD version of password cracking works no matter how secure your hardware.

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

> The XKCD version of password cracking works no matter how secure your hardware.

Lavabit would like to enter the conversation.

The xkcd approach worked in that case; the wrench in that case was legal, not physical, but boy would it have hurt nonetheless.

He deleted everything ultimately. He printed it out in ultra tiny font in order to comply, but it was nearly impossible for law enforcement to use it. The FBI never decrypted the files.

What about the other Lavabit users whose data he had handed over previously, before deciding to say no?

It's hard to tell if you're being serious here. At the end of the day, Lavabit's security came down to... the FBI's inability to read an ultra tiny font?

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.

FBI = legal

We're talking about exactly the same threat. What I'm pointing out is that state adversaries won't have to "notice" this; all they'll have to do is plug the device into a standard commercial forensics scanner product --- and we're stipulating that they're plugging the device in already (else what does it matter what bits are on it).

They pay other people to notice this stuff for them!

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

He's saying they just plug your USB stick into some gizmo sold to the state, and it's going to find enough to escalate it.

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.

Try to explain how the hidden content would be found? It effectively doesn’t exist until the password is in place. It isn’t hidden, it isn’t connected at all.

I’m no expert but I can imagine a scenario where an x-ray scan can notice an SD card embedded into the controller and flag that for follow-up

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

Yeah the SD card is going to be glaring for anybody with actual investigation into this device.

But saying that, the sheer amount of fake flash storage out there now, that's just a glorified USB-SD reader in a box.

I mean - if there are multiple sdcards in the device - and they each contain a hidden partition - how is the X-RAY going to determine that the reported 5GB (or whatever) isn't matching the devices actual 7GB (for example)

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.

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

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

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

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.

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.

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.

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.

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.

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.

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

https://usbkill.com/

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.

> But there is a big flaw I see: 8gb. You're carting around an 8gb flash drive these days??

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 found a 8GB USB drive in my pocket after doing the washing the other day (RIP).

I'd been using it to boot the debian installer from.

You should check to see if it still works. My favorite thumb drive went through the washing machine several times and still works.

Most drives are bigger. I have some around that size--but they're old.

It would be less suspicious if the drive advertised 512GB and returned garbage data for any read past 8GB

Reply on news.ycombinator.com