[iOS/WWDC] App Attest & Device Check

WWDC: https://developer.apple.com/videos/play/wwdc2021/10244/

Apple Document: Establishing your app’s integrity

AppAttest 에서 확인하는 세가지 

1. Genuine Apple device: 실제 iOS 디바이스인지 
2. Authentic application identity: 실제 Developer가 개발한 앱이 맞는지 
3. Trustable payload: App Attest 할때 보낸 payload 가 변조된 것이 아닌게 맞는지 

 

DeviceCheck은 device unique 라서 앱을 삭제하거나, 심지어 폰 컨텐츠 리셋을 해도 남아 있는데, App Attest는 per install 이다. 

 

Steps to integrate

1. Create an App Attest Key 

appAttestService.isSupported 를 체크한 후 진행해야 하지만, 만약 이 값이  false 라면, 일단 untrusted device로 의심해봐야 하고, spike를 친다면 주시할 필요가 있음. 

 

 

2. Attest and verify key

keyId는 위 스텝에서 만든 것이고, 

clientDataHash는 서버와 클라이언트가 알수 있게 userId 같은것을 한번 hash한 값. 

그러면 AppAttest API가 알아서 Apple server에게 request를 보내서 attestationObject를 가져온다. 그럼 이걸 서버에 보내면 됨. 

참고 : https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server

Attestation Object

<실패 케이스>

다양한 이유로 App attestation이 실패할 수 있으니, 이 실패로 유저를 패널라이즈 하지는 말고, risk assesment의 지표로만 써라 

- 네트워크 실패 

- ramp up 으로 인해서 rate limit에 걸린 경우 

 

Ramp up 관련 

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.

Generating new attestations uses significant resources on the device and Apple's servers, so there's a rate limit on how often new attestation certificates can be requested, currently one new attestation every seven days. You request a fresh attestation by specifying a new nonce. Omitting a nonce indicates that freshness is not a concern, so the device can return its most recent attestation instead. And if the nonce is specified and matches that cached attestation, the cached attestation is returned. When the MDM server validates the nonce in an attestation, it should detect a mismatched nonce and determine whether that was expected due to caching or not. But don't request a new attestation every seven days just because that's the rate limit. Doing that will only delay how quickly your MDM server discovers changes in device properties, not to mention waste resources. Instead, monitor for relevant changes in the other DeviceInformation properties, such as the OS version. When one of those changes, then request a fresh attestation. This ensures the attestation is updated as quickly as possible after a change, rather than waiting for the rate limit to expire. 

 

3. Generate and verify assertion 

assertion을 만들어서 서버에 보내는 과정 

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

 

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

 

assertion은 attest 보다는 좀더 가벼운 태스크 이지만 여전히 cryptography가 들어가기 때문에 시간이 좀 걸릴 수 있다.

서버에서 Assertion data 받아서 validate 한다.