←back to thread

Reverse Engineering iOS 18 Inactivity Reboot

(naehrdine.blogspot.com)
511 points moonsword | 2 comments | 17 Nov 24 21:50 UTC | HN request time: 0.423s | 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. myflash13 ◴[18 Nov 24 12:37 UTC] No.42171836[source]▶
> The class key is protected with a key derived from the user passcode or password and the device UID. Shortly after the user locks a device (10 seconds, if the Require Password setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks (logs in to) the device using Face ID or Touch ID.
replies(1): >>42172604 #
2. happytoexplain ◴[18 Nov 24 14:35 UTC] No.42172604[source]▶
This means it can't be read from storage, but AFAIK anything you've read into your app's memory sandbox is still sitting there decrypted until your app releases it or is closed or has its memory wiped by system housekeeping.