[HN Gopher] Recovering the master key from RAM to break Android'...
___________________________________________________________________
Recovering the master key from RAM to break Android's file-based
encryption (2021)
Author : thunderbong
Score : 50 points
Date : 2024-05-02 12:07 UTC (2 days ago)
(HTM) web link (www.sciencedirect.com)
(TXT) w3m dump (www.sciencedirect.com)
| mschuster91 wrote:
| > 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...
| AzzyHN wrote:
| I think, if the key derivation becomes compromised, we have
| bigger problems to worry about.
| goalieca wrote:
| Apple 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.
| purkka wrote:
| 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.
| dmitrygr wrote:
| > if the chip dies,
|
| I've heard of zero T2s dying. I've hard of android data
| recovered (TFA)
| ajross wrote:
| 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".
| wesamco wrote:
| > For the threat model of most users, where hardware-based
| targeted attacks aren't a big concern, this is a bad
| tradeoff.
|
| > hardware-based targeted attacks
|
| You mean physical-access attacks, correct? Is it really just
| these kinds of attacks that a T2 chip protects against?
|
| AFAIK if malware has super user privilege, it can access the
| RAM of other processes, and therefore it can access the
| encryption keys stored in RAM by other processes.
|
| If those processes could have used an encryption API that
| does the encryption on the chip, and therefore not need to
| store encryption keys in RAM, they'd be protected against
| this kind of attack, a kind of attack that is not hardware-
| based.
| curt15 wrote:
| Is that how self-encrypting SSDs also work?
| WirelessGigabit wrote:
| No, I found this a good explanation:
| https://www.lullabot.com/articles/adventures-with-edrive-
| acc...
| dangerclose wrote:
| my colleagues' mbp m2 got into recovery mode after sonoma 14.3
| update. it is mdm managed and the recovery key got from the IT
| is not able to decrypt the disk. login accounts tied to the
| drive also not able to unlock the disk. IT reached out to apple
| support and waiting response. because of silicon no other
| methods like in intel, getting into the machine works. does
| that mean no way of getting the data back? is it possible to
| install a fresh mac installation on a external disk and access
| mbp internal disk for decrypting?
| KennyBlanken wrote:
| Why does your IT department MDM devices but not have backups
| and/or why is any substantial amount of data not synced to
| servers, in repos, etc?
|
| Given how fast networks and storage and processors are these
| days - if something takes more than an hour or two of
| diagnostic time and rarely happens, you just nuke the machine
| and re-image.
| tripdout wrote:
| Since 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?
___________________________________________________________________
(page generated 2024-05-04 23:02 UTC)