Recovering the master key from RAM to break Android's file-based encryption (2021)
1–10 of 17 posts
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#2> Over-the-air updates do not change the encryption scheme of a device, because it requires a complete re-encryption of the userdata partition.
JFC that one would have been obvious to think ahead of: what to do if the key derivation becomes compromised?
In an ideal system, each file's metadata should not just specify which master key is to be used, but also which version/KDF scheme was used - that way, newly created files could benefit from stronger encryption schemes and existing files be transparently re-encrypted in the background (or in the foreground, which may be easier to implement technically, but people won't want to wait hours for their upgrade to finish).
Passwords have been doing this for decades, every password in /etc/shadow carries a prefix indicating the hash scheme and settings (salt, rounds), and if the system default changes (like Arch did last year [1]), users get their password updated at login. In user space, for example PHP has a function to check if a re-hash is needed [2].
[1] https://archlinux.org/news/changes-to-default-password-hashi...
[2] https://www.php.net/manual/en/function.password-needs-rehash...
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#3[deleted]
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#4[deleted]
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#5Apple solves the problem in hardware by streaming the persistent storage data through dedicated silicon. Not only is this extremely fast, it guards the key. For the Intel versions of Mac, this was done in the T2 coprocessor.
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#6Apple solves the problem in hardware by streaming the persistent storage data through dedicated silicon. Not only is this extremely fast, it guards the key. For the Intel versions of Mac, this was done in the T2 coprocessor.
The flipside of this is availability. Your T2 coprocessor is now permanently tied to your data. This means if the chip dies, there's no recovery unless you have a backup encrypted with a separate key (with its own confidentiality/availability tradeoff).
(And if anything else on your motherboard dies, Apple's official answer is "you're f*cked", since they refuse to do board-level repair.)
For the threat model of most users, where hardware-based targeted attacks aren't a big concern, this is a bad tradeoff.
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#7Apple solves the problem in hardware by streaming the persistent storage data through dedicated silicon. Not only is this extremely fast, it guards the key. For the Intel versions of Mac, this was done in the T2 coprocessor.
Is that how self-encrypting SSDs also work?
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#8Apple solves the problem in hardware by streaming the persistent storage data through dedicated silicon. Not only is this extremely fast, it guards the key. For the Intel versions of Mac, this was done in the T2 coprocessor.
The flipside of this is availability. Your T2 coprocessor is now permanently tied to your data. This means if the chip dies, there's no recovery unless you have a backup encrypted with a separate key (with its own confidentiality/availability tradeoff). (And if anything else on your motherboard dies, Apple's official answer is "you're f*cked", since they refuse to do board-level repair.) For the threat model of most…
> if the chip dies,
I've heard of zero T2s dying. I've hard of android data recovered (TFA)
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#9Since the device has to be powered on, but locked, and they're using a memory dump, they're referring to the AFU state, right?
From my understanding the BFU state is much harder given that the keys are not in memory but in the TEE. Although there has been exploits for that in the past, not sure if they can extract encryption keys.
It's also interesting to consider what's possible with arbitrary code execution vulnerabilities in early boot stages - would they be able to influence the ARM TZ?
Re: Recovering the master key from RAM to break Android's file-based encryption (2021)
#10Apple solves the problem in hardware by streaming the persistent storage data through dedicated silicon. Not only is this extremely fast, it guards the key. For the Intel versions of Mac, this was done in the T2 coprocessor.
The flipside of this is availability. Your T2 coprocessor is now permanently tied to your data. This means if the chip dies, there's no recovery unless you have a backup encrypted with a separate key (with its own confidentiality/availability tradeoff). (And if anything else on your motherboard dies, Apple's official answer is "you're f*cked", since they refuse to do board-level repair.) For the threat model of most…
It's sort of a weird space we're in in the modern world, where you have to assume that anything on a "device" is ephemeral and fragile, and those of us concerned with data persistence on local hardware need to work at having a path to verifiably-restorable backups.
Cloud is a great solution for most people. But not really an option for "where do I put my decades-stale collection of old home directories" or "mbox files from email in the late 90's".