device-integrity
dpearson2699/swift-ios-skills
Verify device legitimacy and app authenticity using Apple's DeviceCheck and App Attest frameworks.
What is device-integrity?
Implements DeviceCheck (per-device bit flags) and App Attest (Secure Enclave-backed cryptographic attestation) to prevent fraud and validate that requests come from genuine Apple devices running legitimate app instances. Use when protecting sensitive API endpoints, detecting compromised devices, or implementing device verification in your backend.
- Generate and manage per-device tokens via DCDevice for simple device identification and fraud flagging
- Create hardware-backed key pairs in the Secure Enclave using DCAppAttestService for cryptographic app authenticity
- Perform one-time attestation flow to prove app legitimacy to Apple's servers
- Sign subsequent requests with assertion flow to maintain ongoing device and app verification
- Store and reuse account/device-scoped key identifiers to minimize key generation overhead
- Handle server-side verification with Apple's DeviceCheck API endpoints for production and development
How to install device-integrity
npx skills add https://github.com/dpearson2699/swift-ios-skills --skill device-integrity- iOS 11+ for DeviceCheck (DCDevice); iOS 14+ for App Attest (DCAppAttestService)
- Apple Developer account with DeviceCheck capability enabled
- Private key from Apple Developer portal for server-side JWT signing to call DeviceCheck API
- Keychain access for storing account/device-scoped key identifiers on the client
How to use device-integrity
- 1.Check device support using DCDevice.current.isSupported or DCAppAttestService.shared.isSupported
- 2.For DeviceCheck: generate a token, send it to your server, and call Apple's DeviceCheck API endpoints to read/update two per-device bits
- 3.For App Attest: generate a key pair once per user account on each device and store the keyId in Keychain
- 4.Perform attestation once per key by sending the attestation object to your server for verification with Apple
- 5.After successful attestation, use the assertion flow to sign sensitive requests with the attested key for ongoing verification
Use cases
- Prevent users from claiming promotional offers multiple times by flagging devices with per-device bits
- Detect and block requests from jailbroken or compromised devices before they reach sensitive endpoints
- Validate that API requests originate from your legitimate app, not a reverse-engineered client
- Protect high-value transactions (payments, account changes) by requiring cryptographic proof of app authenticity
- Implement device-level fraud detection by combining DeviceCheck bits with backend risk assessment
- iOS app developers implementing fraud prevention
- Backend engineers building device verification into API authentication
- Security teams protecting sensitive user operations and transactions
- Developers of apps handling payments, account access, or promotional offers
device-integrity FAQ
DeviceCheck (DCDevice) provides simple per-device bit flags for tracking device state (e.g., promo claimed, flagged for fraud) and requires server communication with Apple for each operation. App Attest (DCAppAttestService) uses Secure Enclave keys to cryptographically prove app authenticity on individual requests without contacting Apple each time after initial attestation.
Generate one key per user account on each device. Reuse the keyId for that account/device pair. Avoid unnecessary key regeneration as it affects App Attest risk metrics. Only treat a keyId as usable after server verification of attestation succeeds.
App Attest requires iOS 14+ and is not available on simulators or all device models. Check isSupported at runtime. For app extensions, it is supported only in Action, extensible SSO, and watchOS extensions.
Discard the keyId and generate a new key before retrying. Do not reuse a keyId that failed server verification.
No. Generate a new token for each server operation. Each token is single-use and ephemeral.
Full instructions (SKILL.md)
Source of truth, from dpearson2699/swift-ios-skills.
name: device-integrity description: "Verify device legitimacy and app integrity using DeviceCheck (DCDevice per-device bits) and App Attest (DCAppAttestService key generation, attestation, and assertion flows). Use when implementing fraud prevention, detecting compromised devices, validating app authenticity with Apple's servers, protecting sensitive API endpoints with attested requests, or adding device verification to a backend architecture."
Device Integrity
Verify that requests to your server come from a genuine Apple device running a legitimate instance of your app. DeviceCheck provides per-device bits for simple flags (e.g., "claimed promo offer"). App Attest uses Secure Enclave keys and Apple attestation to cryptographically prove app legitimacy on sensitive requests.
Contents
- DCDevice (DeviceCheck Tokens)
- DCAppAttestService (App Attest)
- App Attest Key Generation
- App Attest Attestation Flow
- App Attest Assertion Flow
- Server Verification Guidance
- Error Handling
- Common Patterns
- Common Mistakes
- Review Checklist
- References
DCDevice (DeviceCheck Tokens)
DCDevice generates a
unique, ephemeral token that identifies a device. Treat each token as
single-use: generate a new token for each server operation instead of caching or
reusing one. The token is sent to your server, which then communicates with
Apple's servers to read or set two per-device bits. Available on iOS 11+.
Token Generation
import DeviceCheck
func generateDeviceToken() async throws -> Data {
guard DCDevice.current.isSupported else {
throw DeviceIntegrityError.deviceCheckUnsupported
}
return try await DCDevice.current.generateToken()
}
Sending the Token to Your Server
func sendTokenToServer(_ token: Data) async throws {
let tokenString = token.base64EncodedString()
var request = URLRequest(url: serverURL.appending(path: "verify-device"))
request.httpMethod = "POST"
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
request.httpBody = try JSONEncoder().encode(["device_token": tokenString])
let (_, response) = try await URLSession.shared.data(for: request)
guard let httpResponse = response as? HTTPURLResponse,
httpResponse.statusCode == 200 else {
throw DeviceIntegrityError.serverVerificationFailed
}
}
Server-Side Overview
Your server uses the device token to call Apple's DeviceCheck API endpoints:
| Endpoint | Purpose |
|---|---|
https://api.devicecheck.apple.com/v1/query_two_bits | Read the two bits for a device |
https://api.devicecheck.apple.com/v1/update_two_bits | Set the two bits for a device |
https://api.devicecheck.apple.com/v1/validate_device_token | Validate a device token without reading bits |
The server authenticates with a DeviceCheck private key from the Apple Developer portal, creating a signed JWT for each request.
Use https://api.development.devicecheck.apple.com only while testing; use
https://api.devicecheck.apple.com for production.
What the Two Bits Are For
Apple stores two Boolean values per device per developer team. You decide what they mean. Common uses:
- Bit 0: Device has claimed a promotional offer.
- Bit 1: Device has been flagged for fraud.
Bits persist across app reinstall. You control when to reset them via the server API.
DCAppAttestService (App Attest)
DCAppAttestService
validates that a specific instance of your app on a specific device is
legitimate. It uses a hardware-backed key in the Secure Enclave to create
cryptographic attestations and assertions. Available on iOS 14+.
The flow has three phases:
- Key generation -- create a key pair in the Secure Enclave.
- Attestation -- Apple certifies the key belongs to a genuine Apple device running your app.
- Assertion -- sign server requests with the attested key to prove ongoing legitimacy.
Checking Support
import DeviceCheck
let attestService = DCAppAttestService.shared
guard attestService.isSupported else {
// Fall back to DCDevice token or other risk assessment.
// App Attest is not available on simulators or all device models.
return
}
For app extensions, App Attest is supported only in Action, extensible SSO, and
watchOS extensions. Treat other extension types as unsupported even if
isSupported returns true.
App Attest Key Generation
Generate one cryptographic key pair per user account on each device. The
private key stays in the Secure Enclave. The returned keyId is the only
identifier your app can later use to access the key, so record and reuse the
account/device-scoped keyId; do not share one key across users. Avoid
unnecessary regeneration because each new key affects App Attest key-count risk
metrics. Only treat the keyId as usable after your server verifies
attestation. If server verification fails, discard the keyId and generate a
new key before retrying.
import DeviceCheck
actor AppAttestManager {
private let service = DCAppAttestService.shared
private var keyId: String?
/// Generate and record a key pair for App Attest.
func generateKeyIfNeeded() async throws -> String {
if let existingKeyId = loadKeyIdFromKeychain() {
self.keyId = existingKeyId
return existingKeyId
}
let newKeyId = try await service.generateKey()
saveKeyIdToKeychain(newKeyId)
self.keyId = newKeyId
return newKeyId
}
// MARK: - Keychain helpers (simplified)
private func saveKeyIdToKeychain(_ keyId: String) {
let data = Data(keyId.utf8)
let query: [String: Any] = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrAccount as String: "app-attest-key-id-\(currentAccountID)",
kSecAttrService as String: Bundle.main.bundleIdentifier ?? "",
kSecValueData as String: data,
kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
]
SecItemDelete(query as CFDictionary) // Remove old if exists
SecItemAdd(query as CFDictionary, nil)
}
private func loadKeyIdFromKeychain() -> String? {
let query: [String: Any] = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrAccount as String: "app-attest-key-id-\(currentAccountID)",
kSecAttrService as String: Bundle.main.bundleIdentifier ?? "",
kSecReturnData as String: true,
kSecMatchLimit as String: kSecMatchLimitOne
]
var result: AnyObject?
let status = SecItemCopyMatching(query as CFDictionary, &result)
guard status == errSecSuccess, let data = result as? Data else { return nil }
return String(data: data, encoding: .utf8)
}
}
Important: Generate the key once per user account on a device, persist that
account/device keyId, and keep the key count low. Generating unnecessary keys
pollutes App Attest risk metrics.
App Attest Attestation Flow
Attestation proves that the key was generated on a genuine Apple device running
a legitimate instance of your app. You perform attestation once per key, then
store the verified public key and receipt on your server. The app stores the
keyId for future assertions after the server accepts the attestation.
Client-Side Attestation
import DeviceCheck
import CryptoKit
extension AppAttestManager {
/// Attest the key with Apple. Send the attestation object to your server.
func attestKey() async throws -> Data {
guard let keyId else {
throw DeviceIntegrityError.keyNotGenerated
}
// 1. Request a one-time challenge from your server
let challenge = try await fetchServerChallenge()
// 2. Hash the challenge (Apple requires a SHA-256 hash)
let challengeHash = Data(SHA256.hash(data: challenge))
// 3. Ask Apple to attest the key
let attestation = try await service.attestKey(keyId, clientDataHash: challengeHash)
// 4. Send the attestation object to your server for verification
try await sendAttestationToServer(
keyId: keyId,
attestation: attestation,
challenge: challenge
)
return attestation
}
private func fetchServerChallenge() async throws -> Data {
let url = serverURL.appending(path: "attest/challenge")
let (data, _) = try await URLSession.shared.data(from: url)
return data
}
private func sendAttestationToServer(
keyId: String,
attestation: Data,
challenge: Data
) async throws {
var request = URLRequest(url: serverURL.appending(path: "attest/verify"))
request.httpMethod = "POST"
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
let payload: [String: String] = [
"key_id": keyId,
"attestation": attestation.base64EncodedString(),
"challenge": challenge.base64EncodedString()
]
request.httpBody = try JSONEncoder().encode(payload)
let (_, response) = try await URLSession.shared.data(for: request)
guard let httpResponse = response as? HTTPURLResponse,
httpResponse.statusCode == 200 else {
throw DeviceIntegrityError.attestationVerificationFailed
}
}
}
Server-Side Attestation Verification
Your server validates the attestation object (CBOR), verifies the certificate
chain against Apple's App Attest root CA, checks Apple's nonce calculation, and
stores the verified public key and receipt for future assertion verification.
The attestation nonce is not SHA256(challenge) alone; it is
SHA256(authData || SHA256(challenge)) and is compared with the credential
certificate extension 1.2.840.113635.100.8.2. See
references/device-integrity-patterns.md
for the full server verification flow.
App Attest Assertion Flow
After attestation, use assertions to sign sensitive requests. Each assertion proves the request came from the attested app instance and includes a server-issued, one-time challenge to prevent replay.
Client-Side Assertion
import DeviceCheck
import CryptoKit
extension AppAttestManager {
/// Generate an assertion for encoded client data.
/// Client data should include a one-time server challenge and request context.
func generateAssertion(for clientData: Data) async throws -> Data {
guard let keyId else {
throw DeviceIntegrityError.keyNotGenerated
}
let clientDataHash = Data(SHA256.hash(data: clientData))
return try await service.generateAssertion(keyId, clientDataHash: clientDataHash)
}
}
Using Assertions in Network Requests
struct AppAttestClientData: Encodable {
let challenge: String
let method: String
let path: String
let bodySHA256: String
}
extension AppAttestManager {
/// Perform an attested API request.
func makeAttestedRequest(
to url: URL,
method: String = "POST",
body: Data
) async throws -> (Data, URLResponse) {
let challenge = try await fetchAssertionChallenge()
let bodyHash = Data(SHA256.hash(data: body)).base64EncodedString()
let clientData = try JSONEncoder().encode(
AppAttestClientData(
challenge: challenge,
method: method,
path: url.path,
bodySHA256: bodyHash
)
)
let assertion = try await generateAssertion(for: clientData)
var request = URLRequest(url: url)
request.httpMethod = method
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
request.setValue(assertion.base64EncodedString(), forHTTPHeaderField: "X-App-Attest-Assertion")
request.setValue(clientData.base64EncodedString(), forHTTPHeaderField: "X-App-Attest-Client-Data")
request.httpBody = body
return try await URLSession.shared.data(for: request)
}
private func fetchAssertionChallenge() async throws -> String {
let url = serverURL.appending(path: "assert/challenge")
let (data, _) = try await URLSession.shared.data(from: url)
return String(decoding: data, as: UTF8.self)
}
}
Server-Side Assertion Verification
Your server decodes the assertion (CBOR), verifies the authenticator data and
counter, recomputes clientDataHash from the submitted client data, verifies
the signature over SHA256(authenticatorData || clientDataHash) with the
stored public key, and confirms the embedded challenge and request context. See
references/device-integrity-patterns.md
for step-by-step server verification.
Server Verification Guidance
See references/device-integrity-patterns.md for full server architecture guidance including attestation vs. assertion comparison, recommended endpoint design, and risk assessment.
Security Boundaries
App Attest proves app-instance integrity for selected requests. It does not replace user authentication, OAuth/JWT/session handling, API token design, entitlement or subscription authorization, TLS, certificate pinning, or general networking security. Treat those as handoffs to authentication, networking, or broader security guidance, and still enforce normal authentication and authorization after App Attest passes.
Error Handling
Handle DCError codes from DeviceCheck operations. Key cases:
.serverUnavailable— retry with exponential backoff.invalidKey— the key was already attested, assertion used an unattested key, or the service rejected the key.featureUnsupported— fall back toDCDevicetokens.invalidInput— malformedclientDataHashorkeyId
For attestKey, retry .serverUnavailable later with the same keyId and the
same clientDataHash. For other attestation errors, discard the key identifier
and create a new key before retrying. See
references/device-integrity-patterns.md
for full error handling code, retry strategy, and rejected-key recovery.
Common Patterns
Environment Entitlement
Set the App Attest environment in your entitlements file. Use development
during testing and production for App Store builds:
<key>com.apple.developer.devicecheck.appattest-environment</key>
<string>production</string>
When the entitlement is omitted during development, the app uses the App Attest sandbox by default. After distribution through TestFlight, the App Store, or the Apple Developer Enterprise Program, the app ignores the entitlement value and uses production.
See references/device-integrity-patterns.md for the full integration manager pattern, gradual rollout guidance, and error type definition.
Common Mistakes
- Generating a new key on every launch. Generate once per user account on a device, persist the
keyId, and keep key counts low. - Reusing
DCDevicetokens. Treat generated tokens as single-use. Generate a new token for each server operation. - Skipping the fallback for unsupported devices or extensions. Not all devices and extension types support App Attest. Use
DCDevicetokens or other risk assessment as fallback. - Trusting attestation client-side. All verification must happen on your server.
- Signing only the raw request body. Assertion client data must include a one-time server challenge and enough request context for the server to bind the assertion to the request.
- Verifying the wrong attestation nonce. Compare the certificate extension with
SHA256(authData || SHA256(challenge)), notSHA256(challenge)alone. - Not implementing replay protection. The server must validate one-time challenges and track the assertion counter.
- Mixing development and production environments. Sandbox keys and receipts do not work in production, and production keys and receipts do not work in sandbox.
- Not handling
DCError.invalidKey. Check for repeated attestation, unattested assertion keys, or service rejection; regenerate only after the state is known bad.
Review Checklist
-
DCDevicetokens generated per server operation and never cached for reuse -
DCAppAttestService.isSupportedchecked before use; unsupported devices and extension types have a fallback - Key generated once per user account on each device and
keyIdpersisted only for that app account/device - Attestation performed once per key; server stores verified public key and receipt
- Server validates attestation certificate chain, App ID hash, environment
aaguid, credential ID, and nonceSHA256(authData || SHA256(challenge)) - Assertions include one-time challenge plus request context; server verifies signature, RP ID, counter, challenge, and request binding
- Protected endpoints still enforce normal user authentication and entitlement authorization after App Attest passes
-
DCErrorcases handled:.serverUnavailableretries attestation with the same key/hash; bad keys are discarded and regenerated - App Attest environment entitlement and sandbox/production server routing are consistent
- Gradual rollout considered; feature flag in place for enabling/disabling
References
Related skills
More from dpearson2699/swift-ios-skills and the wider catalog.

dockkit
Control motorized camera docks and enable intelligent subject tracking with DockKit for iOS.

energykit
Query grid electricity forecasts and submit load events to optimize home energy usage in iOS apps.

eventkit
Create, read, and manage calendar events and reminders using EventKit and EventKitUI.

financekit
Access Apple Wallet financial data—transactions, balances, Apple Card, Apple Cash, and Savings.

focus-engine
Implements keyboard, directional, and scene-level focus behavior across SwiftUI and UIKit. Use when managing @FocusState, defaultFocus, focused values, focusable interactions, focus sections, tvOS geometric focus and Siri Remote navigation, watchOS Digital Crown input, visionOS connected-device focus versus gaze hover/input targets, macOS key view loop and Full Keyboard Access, focus restoration after presentation changes, custom focus routing with UIFocusGuide, or debugging focus with UIFocusDebugger.

gamekit
Integrate Game Center features into iOS games with authentication, leaderboards, achievements, and multiplayer matchmaking.