How does Apple certify the keys and queries of an application using App Attest?

Once you file a bug using Feedback Assistant, it shows you a page giving some basic status info about that bug. On that page you’ll see a number like FB1234567. I’d like you to post that number.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi there. I have exactly the same question as Sheezen. I submitted the fedback myself: FB11984676

Let me speculate in the meantime :) Two possible methods come to my mind:

1. Apple just checks the device serial number against their database. If there is a match, the attestation object is granted.
2. There is some built-in device certificate inside the Secure Enclave, created at manufacture time and signed by some Apple CA. This built-in certificate is used to provide a fresh signature tag to the "remote Apple server", to show that the hardware is genuine.

If only METHOD 1 is used, an attacker who has a list of serial numbers could generate attestation objects (even without having to modify the OS, which would contradict "A compromised version of your app running on a genuine, unmodified Apple device can’t create valid assertions"). And as long as the metric is kept low, every same serial number could be used to generate a few attestation objects.

Apple already uses certificates to validate if an external accessory is approved, so it's natural to think that it does something similar with its own devices (METHOD 2).

I reviewed the App Attest and the Apple Platform Security documentation and have not found the answer. It would be really nice that Apple gives some (high-level) explanation about that. Otherwise, the "security through obscurity" undermines a little the trust to this security feature, and makes developers wonder if it is worth the effort using it.

In any case, thank you very much

My assumption is that this works using a "chain of trust" of some sort, i.e. the (immutable) bootloader computes a signature for the kernel before it loads it, and the kernel computes a signature for the app before it runs it, and when App Attest runs it sends these signatures to Apple. You can avoid replay attacks with nonces and timestamps and so on. There is plenty of public material available describing how to do "trusted computing" on, for example, UEFI bootloaders loading Linux; I speculate that what Apple is doing for App Attest is similar in most respects.

Edited to add: the term to search for is "Remote Attestation". This will find a variety of e.g. academic papers, stack exchange answers, etc.

There is a catch in:

"when App Attest runs [on the device] it sends these signatures to Apple [servers]".

In principle, those signatures are meaningful to the device hardware but meaningless to Apple servers.

There are two completely different remote attestation scenarios, depending on the threat model:

1. Apple wants to ensure that a genuine Apple device will only run approved software. For that, the TPM only needs to have some public keys to bootstrap the process. We can assume that these keys are the same for all devices. They are used to verify the signature of the software to be loaded. Software that has already been verified can do the exact same process to run other software. This is documented in great detail in the Apple Platform Security document.

2. Apple wants to ensure that a request to their cloud servers comes from a genuine Apple device. This is needed for the App Attest feature to really make sense. One way to do it, is to have the Apple servers send a nonce/timestamp to the device, then the TPM signs it, and sends back the signature. But to do that, the TPM needs to have a public+private key pair, signed by some Apple CA. Another way to do it is to have Apple servers trust any self-signed certificate the first time a device registers in iCloud, and use it as a "root of trust" from then on, binding that certificate to the serial number. Maybe Apple uses a combination of both. Who knows!!! My point is: this is just a supposition, because this is not documented. I am afraid that Apple will not release this information, as it could be used to copy or attack the security of their engineering techniques and/or supply chain.