Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recovering the master key from RAM to break Android's file-based encryption (2021)

sciencedirect.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#11

Post by dangerclose »

goalieca wrote: post #5

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.

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?

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#12

Post by AzzyHN »

mschuster91 wrote: post #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…

I think, if the key derivation becomes compromised, we have bigger problems to worry about.

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#13

Post by KennyBlanken »

dangerclose wrote: post #11
goalieca wrote: post #5

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.

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 pos…

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.

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#14

Post by wesamco »

purkka wrote: post #6
goalieca wrote: post #5

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.

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…

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

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#15

Post by WirelessGigabit »

curt15 wrote: post #7
goalieca wrote: post #5

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.

Is that how self-encrypting SSDs also work?

No, I found this a good explanation: https://www.lullabot.com/articles/adventures-with-edrive-acc...

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#16

Post by moe_sc »

wesamco wrote: post #14
purkka wrote: post #6

Earlier quoted context omitted.

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…

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

Considering those keys are loaded into RAM for/whilst unencripting, i don't see how it matters, cause the malware should have access to the (now) unencripted data regardless.

Re: Recovering the master key from RAM to break Android's file-based encryption (2021)

#17

Post by jmprspret »

mschuster91 wrote: post #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…

This paper is from 2021. I don't know the advanced details, but I do know that Android's security is improving quite fast, so it's very possible (and, likely, I'd say) that many of the issues on this paper have already been fixed
Post reply on HN