Let's talk attestation and boxes and what that means for generating keys on an iOS device.

For a while folks, myself included, have been really interested in getting Apple to provide attestation statements about a key being in the Secure Enclave.

1/15

And while I think that's still a good thing, it doesn't solve all of the problems.

For example, if I have an API that takes a certificate signing request, and an OAuth token, and then returns a signed certificate. I can be pretty sure the right user is using that API.

2/15

But I can't really be sure that the right app is sending the request. As someone could have reversed the API, not overly hard with proxying tools, or maybe just made some educated guesses about what the API is doing.

3/15

To combat this you'd normally embed some sort of API key into your app.

However, that's not real secure as .ipa files can be torn apart, or proxies can be set up, or a few other reasons why putting a static secret into your app is just security theater.

4/15

Alternatively, you could push something via MDM, or some out of band method to get a secret into your app, that then proves it's actually your app to your API.

But all of these methods are also complicated and prone to leakage in their own way.

5/15

With iOS 14 Apple has a "Device Check" service which seems to mostly answer what I'm looking for.

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

This allows a developer to easily generate an attestation statement via Apple's servers that proves the call is coming from inside the house.

6/15

The API seems really geared towards allowing app developers to track devices without getting their hands on any sort of actual PII about the device, which is great.

I don't need that, although you do get two bits per device to flip that Apple stores.

7/15

However, what I like is that Apple is swearing that my app is my app and it's running on a real device that's probably not jailbroken based on querying the actual hardware in ways that only Apple can do.

8/15

So while at first I really just wanted to be able to prove that a key I was using was coming from the Secure Enclave, now I have a way to prove that the CSR is coming from my actual app without having to embed secrets in the app.

9/15

Which brings me back to boxes and where you draw them.

When going through security validation of code, you need to define the actual "thing" you want to validate, as this gets really important to how you do the validation, and the why as well.

10/15

And while I can't prove that my app is using keys from the enclave, I can now draw a bigger box than something that would just cover the individual key.

With Apple providing the assist with the attestation, I can draw a box around my app and everything it does.

11/15

Plus I get jailbreak and actual hardware detection for free in the process.

What a deal!

12/15

Yes, this isn't 100% foolproof.

You have to trust Apple in this equation to properly do the attestation.

However, if you don't trust Apple to be generally competent in this area, I'd suggest you shouldn't be using an Apple device at all.

13/15

The API seems very geared towards App Store apps, but nothing jumps out at me as preventing Enterprise apps from using this service, either.

14/15

There's some extra lifting to be done than just a simple attestation statement about a key, I'm intrigued by the additional validation that your app can get from it and plan to use it a lot more.

Too bad it's not on the Mac, although maybe with Apple Silicon...

15/15