I am getting issue on my application that my device is jailbroken security message I updated my device 18.2 what the solution

Hello, I would like to secure the exchanges between my application and my webservices to make sure requests are only made by an authentic application. By searching the internet I discovered that App Attest from Device Check framework exists but it looks like there are some limitation about it : App Attest doesn't work on most App Extensions (like Share extension) We are limited by the requests count made to the App Attest webservice (only when generating the Apple certificate, one time by device / application). The problem is I need this security on my app extension because I have a Share extension sending e-mails. Do you have advice to secure the exchanges between my app and my webservices ?

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).

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?

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

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.

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 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.

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.

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