More questions about additional security and privacy controls for OCKStore

[vanvoorden]

#275

Hi! I had a few more questions related to this previous discussion about data store security.

It currently looks like the default FileProtectionType used to create OCKStore is .complete.¹ This seems to imply that our CoreData store is locked when the device is locked and unlocked when the device is unlocked.

My question then goes back to the previous discussion: are there any best practices your team could share for building on top of Core Data for additional privacy and security?

One use case here could be a user that wants to lock access to this CareKit app with Face ID or password. This would be on top of the normal FileProtectionType.complete protection and could function similarly to locking Hidden or Deleted Photos with Face ID or protecting certain Notes with Face ID. If the device was unlocked and the user handed their phone to a family member or friend then access to the CareKit app could then be blocked and encrypted even though the device itself is unlocked.

AFAIK there is currently no public support from Core Data or SwiftData to directly manage persistent stores with this level of additional security. Security is traditionally handled at the FileProtectionType level.

I am not an expert on using SQLite directly… but it does look like extensions like SEE can support an encrypted SQLite database that might give us the extra protection we are looking for.² It is not clear how a SQLite store protected with SEE could then serve as the backing store of Core Data or SwiftData store.

Is there any more advice you would have for product engineers looking to add extra security beyond FileProtectionType.complete? Are there any more Core Data or SwiftData documentation or sample projects you could recommend that might have more clues?

Footnotes

1. https://developer.apple.com/documentation/foundation/fileprotectiontype/complete ↩

2. https://www.sqlite.org/see/doc/trunk/www/readme.wiki ↩