DeviceCheck - iOS App Attestation

A new Apple iOS feature to "attest" an app is healthy.

https://developer.apple.com/documentation/devicecheck

DeviceCheck launched in the summer of 2020 as part of the iOS 14 release.

On paper, the Public Interface to the DCAppAttestService Class is tiny:

var shared: DCAppAttestService
var isSupported: Bool
func generateKey(completionHandler: (String?, Error?) -> Void)
func attestKey(String, clientDataHash: Data, completionHandler: (Data?, Error?) -> Void)
func generateAssertion(String, clientDataHash: Data, completionHandler: (Data?, Error?) -> Void)

But then it becomes apparent there is a sister class: dcdevice:

class var current: DCDevice
var isSupported: Bool
func generateToken(completionHandler: (Data?, Error?) -> Void)

To use the DCDevice class, the app ID must with this Capability on developer.apple.com.

Design notes

• Key generated by App Attest are generated and persisted inside the device’s Security Enclave.

• Like other Secure Enclave work, the app is never given the Private Key.

• The app is responsible for persisting a key Identifier so you can always point the Secure Enclave to the correct Private Key.

• The app can get a serialized version of the Public Key. But, before that happens, you call service.attestKey. This makes a call to Apple's attestation service. Apple servers generate an attestation object and return it to the app. That object can then be passed to your server.

• This attestation step is purely an enrolment step to ensure the app's App Attest Public Key resists tampering.

• Other parts of the attestation object additional your server to detect replay attacks.

Tradeoffs

• The request to Apple's servers can fail. Or forced to fail.

• if service.isSupported references a Yes/No Objective-C property that could be swizzled at run-time.