We are trying to integrate "Device Check" and "Device Check - App attest" services to check device integrity and app integrity. We read apple documentation and could not locate the TTL(time-to live) for "Device Token" and "App Attestation Object". Could you let us what TTL for Device Token" and "App Attestation Object"? We can design our architecture based on your answer

We are having trouble with App Attest when built with different processors. We need to build an IPA to send to our testers. When the app is built using Intel processor, everything works. But when we built using a mac with processor M, them the App Attest process fails. The error occurs in our backend while validating the attesation object. We are doing the validation as stated by this documentation: https://developer.apple.com/documentation/devicecheck/attestation-object-validation-guide The process of validating the Attesation Object fails in the step 4, this one: Obtain the value of the credCert extension with OID 1.2.840.113635.100.8.2, which is a DER-encoded ASN.1 sequence. Decode the sequence and extract the single octet string that it contains. Verify that the string equals nonce. The problem is that the validation fails only when the app is built in a M processor machine. In our server we do (using GO Lang) something like this: if !bytes.Equal(nonce[:], unMarshalledCredCert.Bytes) { // error } unMarshalledCredCert is the nonce extracted from the Attesation Object sent by the mobile application and nonce[:] is the nonce stored in our backend side cache. What can this be?

I would need recommendation for App Attest/ DeviceCheck in Apple especially the firebase-appattest/devicecheck. They mentioned there's limits subject to Apple for the quota but no information about exactly number Thanks,

I'm following the attestation object validation guide to check my attestation server validations, but having a different output of that it's expected in the documentation. Everything goes well until the step 2, where it's created the SHA256 hash of the one-time challenge, then this hash it's appended to the end of the authenticator data from the decoded attestation object. Here the generated client data hash is different from the one in the documentation, which also causes a different nonce value. Full implementation at Go Playground: https://go.dev/play/p/DpL_H3L8yWV // generate the SHA256 hash of the one-time challenge challengeHash := sha256.Sum256([]byte(serverChallenge)) // append the one-time challenge hash to the end of the authenticator data clientDataHash := append([]byte(att.AuthData), challengeHash[:]...) // create a SHA256 hash of the composite item to create nonce nonce := sha256.Sum256(clientDataHash) Then I noticed that if the one-time challenge value it's just appended to the end of the authenticator data, the value it's correctly according to the documentation. Full implementation at Go Playground: https://go.dev/play/p/qqN97SevJAB // append the one-time challenge byte array to the end of the authenticator data // this time not generating the SHA256 hash of the one-time challenge clientDataHash := append([]byte(att.AuthData), []byte(serverChallenge)...) // create a SHA256 hash of the composite item to create nonce nonce := sha256.Sum256(clientDataHash) My question is which of the implementations is correct, because if I didn't get it wrong it should be the first one and we would have an error in the documentation.

Hello, Is it correct that right now when any passkey-provider prepares the passkey registration ceremony response with attestation, iOS strips off the attestation before handing over response-assertion to the client. Does this stripping off of attestation have to do anything with the BS and BE flags that are populated by passkey-provider ? Meaning, is it correct statement that iOS removes the attestation blob from the response if the BE and BS flags are set to zero ??

Whenever we call this API enpoint https://api.development.devicecheck.apple.com/v1/validate_device_token we received an 403. The issue started yesterday around 2:00 PM (Brasil - Brasília time).

Dear Experts, I have App Attest deployed in an app that is currently in TestFlight. Its works OK most of the time. For one particular user, however, attestKey fails with DCErrorInvalidKey for a new key that it has just created. I have some insight into what the app is doing because I send diagnostics to the server. It seems that for this user, the sequence of events is: Initially the app has no key ID saved. The user initiates an action that requires App Attest-signed communication with my server. The app calls generateKey which seems to succeed. The app fetches a challenge from the server. The app calls attestKey. attestKey returns DCErrorInvalidKey. The app doesn't save the key ID persistently, so next time the same thing happens. attestKey really shouldn't fail with the invalid key error for a key that it has just created, should it? What could be going on here?

Hello, I'm developing a server that uses the app attestation feature. During the development, I found the behavior that are not written in the document, I would like to inquire this. When Apple server returns 404 for risk metric refresh request? A month after the attestation, receipt is not past expiration time, but 404 is returned from Apple server when I try refresh. And this receipt succeeded in refreshing the risk metric normally if the attestation proceeds again. This behavior is not in the document, but I wonder if it is intended. Is there a case where an attestation has occurred but the risk metric value does not increase? I found a case where attestation occurred twice on one device, but when both receipts were refreshed, the risk metric returned 1. Is this an expected behavior? If it is, I would like to know the detailed conditions under which it occurs. Thank you.

Is there an official way to verify that my app is not running on a rooted device?

In our Enterprise account with Admin access, I can't see the option to create a DeviceCheck key needed for the App Attest functionality. Is there a limitation preventing this key from being generated on Enterprise accounts?

Hello, I am creating this post to ask if there is any plan for bringing the Attestation Service support for macOS or any plans for supporting it in macOS. We implemented it in iOS and it increased the security for our users and partners but we are evaluating deprecated macOS and keeping only Windows and linux because of this restriction on the Attestation Service... if you recommend any other provider to attest the device please bring me some recommendations.

A lot of our customers experienced failed App attest and always return error "DCErrorInvalidKey 3" invalidKey error on these iOS versions: 16.7.2 - iPhone 8 17.1.1, 17.1.2 - iPhone X, iPhone XS, iPhone XR, iPhone SE 2. iPhone 12, iPhone 12 Pro, iPhone 12 Pro Ma

I am seeing DCErrorInvalidInput returned from DCAppAttestService generateAssertion: in production. Can anyone suggest what might cause this, and what I should do in response? The documentation says of this error code: "An error code that indicates when your app provides data that isn’t formatted correctly.: The only input to the method is the key ID and the data hash. I generate the hash with CC_SHA256() and then put the bytes in an NSData. I don't think much can go wrong with that, though I can't see exactly what is being passed in my diagnostics. There is another error response, DCErrorInvalidKey which I handle separately. I am wondering if problems with the key ID are being reported as "invalid input" rather than "invalid key". I can see the key ID in my diagnostics and it looks legitimate, i.e. it's 32 random-looking bytes, base64-encoded. Suggestions anyone?

I'm using App Attest and the endpoint mentioned here to receive receipts with a fraud metric from Apple on my server. However, I've so far been unable to decode the receipts sent by Apple's server. Can anyone point to an implementation in JavaScript/TypeScript? In general, it's been very difficult to implement App Attest on the server due to the lack of reference implementations provided by Apple.

Hi, App Attestation API "attestKey(:clientDataHash:completionHandler" returns "DCErrorInvalidKey 3" for some of the users. We have checked for first reason regarding if generated key is already been attested, we are generating new key and challenge every time. Could you please provide more details regarding more details for second reason "The App Attest service rejects the key." https://developer.apple.com/documentation/devicecheck/dcerror/3585177-invalidkey

I'm trying to verify attestations from Apple devices on my server, and I'm finding it difficult to implement some of the steps outlined here. This is the current state of my implementation. I'm stuck on the step where the credCert extension is decoded and compared with the nonce. I'd be grateful for any help anyone can provide.

Hi, We have a multi-platform application that requires integrity attestation before the backend will enable supporting services (fairly common scenario). I've read the documentation for DeviceCheck and AppAttest, as well as SafetyNet on the Android side. The Android documentation includes lots of examples of use, including server-side (though oddly in C# and Javascript... which I don't see as being server-side languages, but... oh, well). Anyway, maybe there's a server-side example of using an application attestation on the server when validating a client, as well as validating individual requests with assertions, but I've not been able to find it. It seems like a relatively important bit of functionality to ensure that apps aren't being compromised, while at the same time requiring a correct implementation... Why not give a reference implementation as a starting point to make sure developers are on the right path? Can anyone point me at an example as a Gist, etc? Thanks.

Hello everyone, I am using Apple's DeviceCheck API in my Swift application which will check if the device is registered on Apple's server or not and based on the bits I have set I am updating the values in my own database. These values will help me to differentiate the new devices through which the users are getting logged in to my application and I will give them some digital reward poits to use my application on their new devices. Everything is working fine for me in the development environment as I get the right response when I am using the development API i.e. https://api.development.devicecheck.apple.com but it do not work as intended when I am using the production API i.e. https://api.devicecheck.apple.com/

Hi, App Attestation API "attest key" returns "DCErrorInvalidKey 3" in iOS 17 beta with these parameters keyId: "IAeivHRAmm8gDFuNfRbRGAt4n7AuJ1msWEgdMUGHEV8=" and challenge: "9132b01acd5d416369382950be1f421e" tried on device model: XSMax. Note: I tried same challenge on another phone and it works fine.

I have observed few users if their OS upgrades than the DeviceCheck generateAssertion API fails. Is it expected that we need to attest/register new key id iOS version is updated ?