Hello, Since the 21st of March 2024 around 6PM UTC I've been observing a very significant an increase (more than quadrupled) in P99 and P95 latency on https://data.appattest.apple.com/v1/attestationData I'm calling other endpoints of the same API, and I'm not observing a similar increase there. I tried submitting a report in Feedback Assistant but it's not working for me at the moment.

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.

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

response body is "service discovery failure" It appeared by chance.. Does anyone know why?

i need to install a ipa file without apple id and in offline mode for my users (and) by using usbmuxd i want command to enable the developer mode by using commands only not manually

As documented in this article (by Apple), it is apparent that calls to the DeviceCheck App Attest API (DCAppAttestService.attestKey(_:clientDataHash:completionHandler:)) might be subject of throttling from Apple's side. Apple servers might throttle attestation traffic from a particular app to avoid becoming overwhelmed if too many instances of your app make this call simultaneously. That could happen if you have a lot of users that simultaneously receive an app update enabling App Attest. Me and my team are planning to launch a new feature in our app that utilise Apple’s DeviceCheck framework to attest cryptographic keys for our users. And as part of our internal development process and risk analysis routine, we would love to get more details about this throttling. Do anyone have any numbers on when Apple might start to throttle our API calls? Is there a limit on requests per hour or something? And is it possible to get an exception from this throttling?

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 we are developing a appattestation devicecheck feature . we would like to is there a limit on creating a DCAppAttestService.generateKey() ? what happens to the cryptographic key in the Secure Enclave that already created when we call the DCAppAttestService.generateKey() again . Does it overrides the old keypair OR does it create a new key always

I have a question regarding the usage of the DeviceCheck API. We have been using https://api.development.devicecheck.apple.com/v1/validate_device_token for checking device tokens. However, we encountered frequent HTTP response status code 403 between 16:50 and 17:15 Japan time on June 29th. According to the official documentation at https://developer.apple.com/documentation/devicecheck/accessing_and_modifying_per-device_data, I understand that a 403 error indicates "The specified action isn't allowed". Yet, I would like to clarify under what specific circumstances this error would be returned. Please note that we do not encounter a 403 error outside the aforementioned timeframe, which leads us to believe there is no issue with our basic implementation.

How to uniquely identify the device to prevent fraudulent activity in any financial Apps? since UUID also gets changed on every installation, is there any option to track the device like how it is done with IMEI number ? Note: Our App is targeted for normal Appstore users.

HI, Since more than a Month i am trying to solve the issue. Issue is as under Developer program end dates on apple developer account / app and in mac book's setting> manage subscription are different. In developer application not showing renew button. When i am trying to renew from mac book manage subscription option (When wrong date is mentioned) Its giving an error that could not purchase subscription. I got 7 days extension from apple and my corrected date (in apple account on website) got properly extended. Please solve this issue on priority. I am attaching screenshots for your reference.

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 ?

There seem to be an issue with the DeviceCheck Framework where in rare cases the public key (ECC P-256) embedded inside the attestation object returned from DCAppAttestService.attestKey(_:clientDataHash:completionHandler:) has X and Y coordinates with mismatching length. Sometimes X or Y has 31 bytes instead of the expected 32 bytes. This can easily be reproduced by generating and attesting multiple keys using DCAppAttestService.generateKey(completionHandler:) and DCAppAttestService.attestKey(_:clientDataHash:completionHandler:). Every now and then the public key embedded inside the attestation object has X and Y coordinates with mismatching length (number of bytes). Added a Swift snippet at the bottom that shows example on how to generate and detect this. I would expect the ECC P-256 public key X and Y coordinates to always be 32 bytes long. As mentioned in the Web Authentication spec for example. I've attached an example attestation object (in base64 encoded CBOR) that has an embedded public key with mismatching X and Y coordinate length (Y is 31 bits, and not the expected 32 bits). The file was generated using the Swift snippet below. The snippet was built using Xcode 14.3 (14E222b) and ran on iPhone XR with iOS 15.7.1 (19H117). A feedback ticket has also been submitted regarding this issue: FB12235865 Swift snippet to generate and check attestation objects: import DeviceCheck import CryptoKit import SwiftCBOR // https://github.com/valpackett/SwiftCBOR ​ func generateAttestationObjects() { for i in 0..<1000 { DispatchQueue.main.asyncAfter(deadline: .now() + TimeInterval(i)) { DCAppAttestService.shared.generateKey { keyId, error in guard let keyId else { print("\(i): Failed to generate key: \(error)") return } ​ print("\(i): Generated keyId: \(keyId)") ​ DCAppAttestService.shared.attestKey( keyId, clientDataHash: Data(hex: "01020304")! ) { attestationObject, error in guard let attestationObject else { print("\(i): Failed to get attestation: \(error)") return } ​ do { let attestationObjectBytes = [UInt8](attestationObject) ​ if case let .map(decodedAttestationObject) = try CBOR.decode(attestationObjectBytes) { print("\(i): Successfully decoded Attestation object (CBOR)") ​ if case let .byteString(authData) = decodedAttestationObject["authData"] { ​ let attestedCredentialData = [UInt8](authData.dropFirst(37)) ​ let credentialIdLengthBuffer = [UInt8](attestedCredentialData[16..<18]) let credentialIdLength = Int(credentialIdLengthBuffer.reversed().withUnsafeBytes { $0.load(as: UInt16.self) }) let credentialId = [UInt8](attestedCredentialData[18..<(18 + credentialIdLength)]) let credentialPublicKeyBuffer = [UInt8](attestedCredentialData.dropFirst(18 + credentialIdLength)) ​ if let decodedCredentialPublicKey = try CBOR.decode(credentialPublicKeyBuffer) { ​ if case let .byteString(xCoordinateBuffer) = decodedCredentialPublicKey[-2], case let .byteString(yCoordinateBuffer) = decodedCredentialPublicKey[-3] { let xCoordinateLength = xCoordinateBuffer.count let yCoordinateLength = yCoordinateBuffer.count ​ if xCoordinateLength != yCoordinateLength { print("\(i): X/Y Coordinate length mismatch! X: \(xCoordinateLength), Y: \(yCoordinateLength)") } else if xCoordinateLength != 32 || yCoordinateLength != 32 { print("\(i): X/Y Coordinate length mismatch! X: \(xCoordinateLength), Y: \(yCoordinateLength)") } else { print("\(i): X/Y Coordinates OK") } } } } } } catch { print("\(i): Error decoding Attestation object (CBOR): \(error)") } } } } } } An attestation object with a embedded public key with mismatching X and Y coordinate length (base64 encoded CBOR): appattest-object-mismatching-x-y-base64.txt

Is it possible to clear out the existing DeviceCheck state on a developer account? (either ourselves or via Apple support) We recently built a feature that leverages DeviceCheck and did a trial run of that feature. Now there's this trial data stored in DeviceCheck that we'd like to clear out so we can start from a clean slate. I wanted to check what our options are to do this. Thanks!

I'm trying to prevent my App from running on jailbroken devices. For React Native apps, there is Firebase App Check, wich integrates with App Attest and DeviceCheck. I wonder, is App Attest with DeviceCheck able to detect that my App is running on a jailbroken device? I see other posts about jailbeaking on this forum, but they are mostly (or perhaps all of them) older than DeviceCheck. Which is why I'm repeating the question but asking specifically about DeviceCheck and App Attest.