Hacker News Reader

Comment by wepple | Hacker News Reader

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?

View on HN

There's a decent amount of data protected by Class A keys (which are only available when a device is 'actively unlocked') and some amount of data protected by Class B keys (which are asymmetric keys to allow data to be encrypted while the device is locked but only decrypted when the device is unlocked by way of a private key encrypted with a Class A key). The security guide[0] isn't super obvious about what data is protected with what keys:

> The Mail app database (including attachments), managed books, Safari bookmarks, app launch images, and location data are also stored through encryption, with keys protected by the user’s passcode on their device.

> Calendar (excluding attachments), Contacts, Reminders, Notes, Messages, and Photos implement the Data Protection entitlement Protected Until First User Authentication.

I can confirm that when they say "keys protected by the user's passcode" they mean "protected with class A or B". The most shameful omissions there in my opinion are Messages and Photos, but location data is (from a law enforcement perspective) obviously a big one.

0: https://help.apple.com/pdf/security/en_US/apple-platform-sec...

Edit: Additionally, as to your API question, the system provides notifications for when content is about to become unavailable allowing for an app developer to flush data to disk:

https://developer.apple.com/documentation/uikit/uiapplicatio...

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

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.

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.

Reply on news.ycombinator.com