Mitigate fraud with App Attest and DeviceCheck

♪ ♪ Hello, and welcome to "Mitigate fraud with App Attest and DeviceCheck." My name is Xuerui Yan, and I work on the App Store Trust and Safety team. I'm excited to talk about protecting your apps using App Attest and DeviceCheck. At Apple, we're constantly working to ensure that the App Store is a safe and trusted place for customers and developers.

In this video, we will cover the engineering specifics.

For business and conceptual details, see "Safeguard your accounts, promotions, and content" video from WWDC 2021.

In iOS 11, we introduced the DeviceCheck framework. DeviceCheck helps mitigate fraud on promotional offerings. Suppose you are introducing a new feature in your app. To promote the feature, you offer a free, single-use item. Someone might abuse the promotion by reinstalling the app over and over again just to claim the free item. Likely, you'll want to limit promotional items to once per device, instead of allowing the app to be installed repeatedly and having the promotion reused.

Now, DeviceCheck can help you detect whether a device has received a promotion offer, or if a device has participated in fraudulent activity.

It allows you to persistently store two bits of information and a timestamp associated with one device on Apple servers.

It is up to you to decide what these bits mean to your applications.

The state will be maintained by Apple for you to update and query.

The bits are shared by all apps from a developer. Please keep that in mind when assigning meanings to the bits so they are applicable across all your apps.

The state persists across app reinstallation, device transfer between users, and even "Erase all contents and settings." Consider using the timestamp to reset the bits on a period of your choosing, based on your promotional and business strategies.

To find out more about DeviceCheck, see the "Privacy and Your Apps" video from WWDC 2017 and the DeviceCheck Framework documentation.

So that's DeviceCheck. Next, I'm going to talk about App Attest, also available under the DeviceCheck Framework.

When your service receives a request, it can be hard to know whether it really is from your app.

App Attest allows your app to attach a hardware-backed assertion as a part of the request. Your server can use assertion to verify the request came from your genuine app, on a genuine Apple device. Imagine, you designed a beautiful app that encourages travel to discover collectibles, only to find that a modified app allowed collecting everything without ever leaving home.

Or imagine players' frustration seeing others racing up the leaderboards, by using cheats to get unlimited boosts in a competitive multiplayer racing game.

Or imagine waking up on a Saturday and, much to your delight, seeing a very high request volume on your server, but after investigation, you find the calls aren't coming from your app at all.

App Attest can help you identify genuine and modified versions of your app, letting you protect your app experience and your business.

App Attest provides three key properties that you can take advantage of to protect you and your customers.

App Attest lets your service verify a request came from a legitimate instance of your app by satisfying three conditions: the request came from a genuine Apple device, running your genuine application, and that the payload has not been tampered with.

Let's go through how App Attest provides each of these properties. At the heart of App Attest is a secure key pair and an attestation, signed by Apple, certifying that the key pair originates from a genuine Apple device. The private key is stored and accessible only through the Secure Enclave using the App Attest API.

Your app can sign requests to your service with the key, and your service can then check the signature to verify the request was generated on a genuine Apple device.

For an app to execute on an Apple device, it must be signed. A person making unauthorized modifications to your app must re-sign it with an identity they control. This unavoidably modifies the app identity.

We include a hash of the app identity in the attestation.

By comparing your app identity with the one included in the attestation, you can determine whether the caller is using a modified version.

Now that you know the request came from a genuine device and your genuine app, let's talk about the request payload.

Before sending a payload to your server, you can instruct App Attest to sign a digest of the payload using the attested key. This creates an assertion of the payload.

Your app should transmit the payload and the assertion to your service. By verifying the assertion against the payload, you can trust that the payload was not tampered with in transit.

Those are three key properties. Now let's talk a bit about privacy.

Here at Apple, we care deeply about privacy. We believe that privacy is an essential foundation for a healthy app ecosystem. Each element of App Attest has been built with privacy in mind.

The attestations are designed to provide assurance of a genuine device, while protecting against tracking. The attestations are anonymous and include no hardware identifiers.

App Attest keys are unique per installation of your app. This means that an App Attest key will not survive app reinstallation, is not backed up, and is not synced across devices. Keep this in mind when designing your app.

Now that you understand the value App Attest provides, let's dive into the details of incorporating it into your app. There are three basic parts to incorporate App Attest into your app. Creating an App Attest key, attesting and verifying the key, and generating and verifying assertions. Let's start with creating an App Attest Key. All App Attest calls should be guarded by the isSupported property. App Attest is supported on devices that have a Secure Enclave, but there are cases, such as App Extensions, where isSupported will still return false. Your app must handle these cases gracefully.

Instead of immediately blocking access, use failures as a risk signal. First, classify the caller as untrusted. Then, based on your risk assessment logic, evaluate whether to allow the client to use sensitive features.

Another approach is to monitor for a sudden increase in devices claiming they don't support App Attest when calling your service. If the ratio of devices supporting App Attest suddenly decreases, it may be a sign of modified apps trying to bypass your checks.

With an App Attest key successfully generated, let's go ahead and attest the key. To prevent man-in-the-middle and replay attacks, we need a one-time server challenge. Let's have your server issue the challenge to the app.

To link the attestation with a user account ID or other values, hash those values together with the challenge to create the clientDataHash. Using the clientDataHash, along with the keyId from the previous step, we can now call attestKey API.

attestKey will use the private key to create a hardware attestation request for the device, and submit the request to Apple for verification. Once verified, Apple will return an anonymous attestation object to your app. Send the attestation, along with any custom payload, back to your server for verification. OK, now that your app has sent the attestation to your server, let's try to verify it.

The attestation follows the Web Authentication standard and contains three parts: a list of certificates signed by Apple, an Authenticator Data structure, and a risk metric receipt.

Let's look at the important pieces that you need to verify.

The certificate section contains the leaf and intermediate certificates. The App Attest root certificate is available in the Apple Private PKI repository. Validating the full certificate chain tells you the device is a genuine Apple device.

When you called attestKey, a single-use hash, known as a nonce, was created from the clientDataHash and other data. That nonce is included in the leaf certificate.

To prevent tampering, you'll reconstruct the nonce on your server and verify it matches.

The authenticator data block contains multiple properties, including a hash of the app identity, that you can use to verify it is your app calling you.

The key attestation also contains a receipt that you can store and use later to request a risk metric from Apple. I will cover more information about it later in the video.

If everything checks out, the App Attest Key is genuine. Store the key associated with the client data for use to verify subsequent requests.

Not all failures are due to an invalid attestation. Gracefully handle scenarios, such as isSupported returning false, being throttled during ramp up, or general network failures. You can then incorporate failures as signals in your overall risk assessment.

For further details on implementing the verification, please see the documentation. Calling the attest-Key API generates a network call from your app to App Attest service. This only happens once per app instance. However, if you have a large install base, collectively, your app may send many requests to App Attest. In order to manage resources and avoid being rate limited, make sure you gradually enable this feature across your install base. For example, if you have a million daily active users, you can probably ramp up over a day or so. If you have a billion daily active users, nice work! You should ramp up over a month or more.

Now that you have the attested key, you can use the generateAssertion API call to protect sensitive communication between your app and your server.

The assertion flow is simpler than attestation, as the Apple servers are no longer involved.

All assertions using the key are generated on-device and validated on your server.

Start by requesting a unique challenge from the server, then generate a digest of the payload and call generateAssertion. generateAssertion will use the digest to compute a nonce and sign it with the App Attest key.

Your app can then send the payload and the assertion to your server. Finally, your server should verify the payload.

Assertion payloads contains this high-level structure. Signature and Authenticator Data.

To validate the signature, reverse the process to reconstruct the nonce on your server. Then use the public key to verify the signature.

If the signature is valid, you can trust the payload is unmodified.

The authenticator data section contains the app identity hash.

Validate the hash to ensure the assertion is from your genuine app.

The authenticator data also includes an ever-increasing counter. To help protect against replay attacks, store the counter value on your server, and expect it to increase with each subsequent request.

With the key, you can now repeat this process as much as you need. While generating an assertion doesn't call Apple servers, it's a cryptographic operation, which adds some latency. You should factor this into your design when incorporating App Attest into your app.

Assertions are a good fit for important but infrequent calls, and the calls that can deal with the additional latency and the computation required.

For frequent real-time network commands, assertions may not be suitable.

Congratulations! You have now completed the basic implementation of App Attest. With this implementation alone, you can start classifying your incoming server requests as genuine and modified, and incorporate this important fraud signal into your business logic.

But there's more. An attacker may try to work around App Attest by using a single device to create many App Attest keys, and use that device to serve communications between many modified apps and your server. To help detect such behavior, we offer a service called the App Attest Risk Metric Service that provides the approximate number of keys created on a device for your app. Recall that attestKey returns both the attestation and a risk metric receipt. Your server can submit that receipt to the service and redeem it for a new receipt. The new receipt will include the risk metric.

Periodically, you can redeem your latest receipt for updated metrics for that app/device pair.

Here is a high-level view of the receipt structure. It is a PKCS7 container. For full details, see "Assessing Fraud Risk" in the DeviceCheck Framework documentation.

App Clips is an exciting feature in iOS. We've added App Attest support to App Clips in iOS 15. To support a seamless upgrade from App Clip to full app, the App Clip and full app share the same app identity in the App Attest context. Make sure to keep this in mind when you verify the app identity on your server side.

When App Clips are manually removed or expire, their keys will be invalidated, just like when your full app is uninstalled.

OK, that's it for App Clips. Now, remember these key points for success with App Attest. Validate on server, not on-device. The app may be modified to disable your validation code.

Incorporate a one-time server challenge in your flow to prevent network replay attacks.

Handle failure scenarios, such as isSupported returning false, being throttled during ramp up, or general network failures. Incorporate failures as signals in your risk assessment.

App Attest and DeviceCheck provide the information that you can integrate into your overall fraud assessment. Use DeviceCheck to mitigate fraud on promotional offerings.

Take advantage of App Attest to help you detect modified versions of your app, protecting your content and your user experience. Thanks for watching! I'm looking forward to seeing your apps protected by App Attest and DeviceCheck. Peace!