this will likely fail as block devices aren't dumb anymore, the firmware state will out the hidden volume. counting on the laziness/unsophistication of an adversary isn't a great move.

this problem may be solvable by a purpose-built abstraction where every write no matter what address will look identical to the firmware (naively, a randomized key-value map).

▲

Grimblewald 5 hours ago | parent | next [-]

I largly agree, hence why the prudent move is not visiting shitholes like the (current) USA with anything important on your person.

However, if you must do it, there are better options than duress pins that wipe a device.

▲

OGWhales 12 hours ago | parent | prev | next [-]

Not that shufflecake solves the issue you highlighted, but I found the shufflecake FAQ to be a good intro to the topic for anyone curious. It does a good job explaining the threat vectors and the relevant trade offs, in particular the TRIM and ORAM sections. It’s also just a cool project: https://shufflecake.net/

▲

8 hours ago | parent | prev | next [-]

[deleted]

▲

JSR_FDED 15 hours ago | parent | prev | next [-]

What does “block devices aren’t dumb anymore” mean?

▲

greyface- 15 hours ago | parent | next [-]

Modern SSDs are log-structured under the hood. The presentation to the host system as a random access block device is an abstraction on top of that, emulating the semantics of spinning rust. Inspecting the underlying log will reveal the location of the hidden area, even if it looks random when read linearly.

▲

OsrsNeedsf2P 27 minutes ago | parent | next [-]

If you have access to the SSD, you can just see the partitions anyway. I assume the threat model here is simply safely showing the agents "your phone"

▲

vlovich123 15 hours ago | parent | prev [-]

I’m not so sure that log structure would reveal to you VeraCrypt style hidden volumes. It would only tell you about which blocks are allocated but the whole point is that VeraCrypt would allocate the whole space and within it have hidden space. You wouldn’t be able to infer (at least ethically, but you could lie) whether or not a hidden partition exists because you don’t know if the allocated block is present in the filesystem or was just allocated and never trimmed.

▲

teravor 11 hours ago | parent | next [-]

> allocate the whole space

what do you imagine allocation is in this context? it's just a set of written blocks that mark address ranges and other metadata for the OS filesystem driver (all encrypted).

firmware metadata will leak the fact that there is churn in the address range where a potential hidden volume lies. the churn will be inconsistent with filesystem activity that would be present in its absence.

it's not just SSDs you need to worry about either, HDD firmware also keeps metadata, some of it could be be proxy to churn by region.

	▲	vlovich123 3 hours ago \| parent [-]
		> churn in the address range where a potential hidden volume lies. You’re assuming separation exists. VeraCrypt specifically and intentionally allocates the hidden partition blocks from the unallocated space within the normal partition. You know, the same thing that would happen if you wrote a file. Even if you had access to the “open” partition, you couldn’t conclude that “there’s allocated blocks but no files, thus hidden partition” - that presumes the filesystem would TRIM immediately, which is indistinguishable from “there’s just a lot of deleted files that haven’t yet been GC’ed”. Now to be clear, VeraCrypt specifically is believed to be susceptible to SSD side channel attacks, but even still it’s not definitive conclusions. You’re less likely to be betrayed by the firmware than the OS helpfully remembering you opened a file on a hidden partition and saving that history into the unhidden partition.

▲

greyface- 14 hours ago | parent | prev [-]

It would also give you information about the order in which blocks were written, and the historical state of the disk. Because of wear leveling, block allocation isn't just a one-time initial thing; the mappings between logical and physical address space are changing with each write.

	▲	vlovich123 11 hours ago \| parent [-]
		That still doesn’t tell you anything about the existence of partitions within the filesystem UNLESS you discover a side channel attack.

▲

yencabulator 15 hours ago | parent | prev [-]

SSD/NVMe keep track of what regions are wiped and which contain data that has to be preserved. To hide something in the seemingly-unused space, you have to turn off trim, eat the performance cost, and pretend you had a reason to have turned off trim.

▲

teravor 15 hours ago | parent [-]

I don't believe having trim disabled even helps here. smart firmware sees the same address being written to and may therefore reassign it to a different cell for wear leveling. it's a de facto trim.

trim lets the firmware know which mappings it can discard without the explicit reuse of the same address.

however I don't believe you can observe this effect from trim command results, it will report the usual size trimmed as if the firmware never realized that you reused the same address range multiple times.

	▲	yencabulator 15 hours ago \| parent [-]
		Data recovery providers can probably get access to firmware-internal metadata.

▲

jauntywundrkind 12 hours ago | parent | prev [-]

I agree that trying to outcompete seems really hard, but also:

Given what the experience of using a non-rooted phone is like, how very very tight the sandboxing is and how useless it is a General Purpose Computer that will tell you anything: I find it very hard to believe the unlocked phone is going to let you start probing firmware & snooping on hidden volumes.

This post sent my BS detector on high alert. I'm struggling to take it seriously.

	▲	teravor 12 hours ago \| parent [-]
		you do realize what the threat model behind a hidden volume is right? no one will be accessing the firmware through the OS, they will access it from the PCB/chip/debug port. there is no point to a hidden volume if you cannot credibly deny its existance.