←back to thread

Reverse Engineering iOS 18 Inactivity Reboot

(naehrdine.blogspot.com)
511 points moonsword | 1 comments | 17 Nov 24 21:50 UTC | HN request time: 0s | source
Show context
happytoexplain ◴[18 Nov 24 03:37 UTC] No.42169525[source]▶
>In the After First Unlock (AFU) state, user data is decrypted

Note that this is a slight simplification because, I assume, the reality is irrelevant to understanding the topic:

There are a few different keys [0] that can be chosen at this level of the encryption pipeline. The default one makes data available after first unlock, as described. But, as the developer, you can choose a key that, for example, makes your app's data unavailable any time the device is locked. Apple uses that one for the user's health data, and maybe other extra-sensitive stuff.

[0]: https://support.apple.com/guide/security/data-protection-cla...

replies(1): >>42171426 #
wepple ◴[18 Nov 24 11:15 UTC] No.42171426[source]▶
How useful do you think this is in practice? Wouldn’t it rely on app-level memory scrubbing and page clearing and such as well, if you wanted to truly make sure it’s unavailable? Do Apple offer APIs to assist there?
replies(3): >>42171836 #>>42172065 #>>42174424 #
1. happytoexplain ◴[18 Nov 24 13:18 UTC] No.42172065[source]▶
It's a good point - I am not an expert, but I think this feature just doesn't protect memory (tying one of the keys to rebooting helps, but the Data Protection feature itself doesn't seem to protect memory). However, that doesn't moot in-storage protection. There are other features protecting memory (and other features protecting data in storage - there are tons of security features).

I am not aware of APIs for securely clearing your app's memory (aside from lower level, more manual APIs). This may be one of those cases that relies mostly on sandboxing for protection. I also imagine it's hard to circumvent sandboxing without rebooting. But I'm making a lot of guesses here.