You didn’t read the article you linked to, did you?
The encryption by default you speak of is before the first unlock, that is, locked with something like a password or PIN. After the first unlock, the decryption key is stored in memory and your filesystem is pretty much vulnerable to anyone that can get access to the memory. That is why you can even unlock your phone with your face or fingers, because all that is a simple boolean value that indicates whether you logged in or not. You can’t “generate” or get a key from your face nor fingers.
In a lot of modern phones, and particularly iPhones, the encryption key is stored in the TPM. The TPM itself handles the encryption and decryption of data. If someone manages to get read access to the system memory, the most they’re getting is whatever cleartext data is stored in memory for cache or process memory.
Citing my Claims:
I’m not going to bore myself or anyone else with whitepapers and PDFs, but Apple themselves summarize how T2 (TPM) works with disk encryption on Mac devices. The iPhone has the same chip and an even stricter threat model. In M-series Apple devices, they rolled its functionality into the SoC.
Correct, though it still is saved somewhere. Just like how TPMs in Computers can be exploited as well, this also can be. What I meant in my original comment was that the emergency mode did not clear that hardware chip’s storage, which others said otherwise.
Ah. Then yeah, emergency mode won’t suffice for protecting the full contents of the disk.
I can’t say Apple actually does this, but it is possible to protect important data by further encrypting user data with a separate encryption key derived from the passcode, and then clearing the key whenever the screen is locked.
That’s not how disk encryption works. Data in storage is always encrypted. That’s the whole point. When an app requests data, it is decrypted on the fly. Decrypted data is never stored outside of RAM.
It’s encrypted by default.
You didn’t read the article you linked to, did you?
The encryption by default you speak of is before the first unlock, that is, locked with something like a password or PIN. After the first unlock, the decryption key is stored in memory and your filesystem is pretty much vulnerable to anyone that can get access to the memory. That is why you can even unlock your phone with your face or fingers, because all that is a simple boolean value that indicates whether you logged in or not. You can’t “generate” or get a key from your face nor fingers.
In a lot of modern phones, and particularly iPhones, the encryption key is stored in the TPM. The TPM itself handles the encryption and decryption of data. If someone manages to get read access to the system memory, the most they’re getting is whatever cleartext data is stored in memory for cache or process memory.
Citing my Claims:
I’m not going to bore myself or anyone else with whitepapers and PDFs, but Apple themselves summarize how T2 (TPM) works with disk encryption on Mac devices. The iPhone has the same chip and an even stricter threat model. In M-series Apple devices, they rolled its functionality into the SoC.
Correct, though it still is saved somewhere. Just like how TPMs in Computers can be exploited as well, this also can be. What I meant in my original comment was that the emergency mode did not clear that hardware chip’s storage, which others said otherwise.
edit: corrected mistake according to ethan
Ah. Then yeah, emergency mode won’t suffice for protecting the full contents of the disk.
I can’t say Apple actually does this, but it is possible to protect important data by further encrypting user data with a separate encryption key derived from the passcode, and then clearing the key whenever the screen is locked.
That’s not how disk encryption works. Data in storage is always encrypted. That’s the whole point. When an app requests data, it is decrypted on the fly. Decrypted data is never stored outside of RAM.
deleted by creator