設備證明 Level 3：伺服器端統一驗證兩個平台

前三站講的是「每個平台怎麼運作」：L0 的骨架（平台在保險箱裡蓋章，伺服器端驗章）、L1 的 Apple App Attest、L2 的 Google Play Integrity。這一站是最後一站，講你的伺服器要怎麼設計，才能同時接住兩邊。

這站學完，你要能：
① 畫出一套伺服器驗證架構：發 challenge → 綁請求內容 → 分流驗證 → 正規化 → 依策略回應。
② 說出 Apple 和 Google 各要存什麼、各要呼叫什麼。
③ 說出「附了證明但驗不過」和「根本拿不到證明」各該怎麼處理，以及理由。
④ 說出設備證明在整體防線裡的位置。

怎麼看這站的標記：官方文件寫的內容，會在句尾附上出處。官方沒有要求、是設計上的選擇，會標 設計建議（非官方），你可以依自己的情況調整。

起點：L2 的對照表，伺服器要吸收的四個差異

先認得這站的新名詞

角色不變：App 遞件、平台蓋章、你的伺服器驗章（或請 Google 的驗件窗口代驗，就是 L2 說的拿去窗口拆封）並做決定。這站所有新東西都在「你的伺服器」裡。

統一流程的骨架

圖 A：統一驗證架構。橘框的註冊入口只有 Apple 用；Google 那一路要呼叫 Google 伺服器。編號對應下面五步（點圖可放大）

1. 發 challenge：
   • Apple：伺服器要提供隨機、一次性的 challenge，並記住它（Apple：Validating 頁）。WWDC26 也說，註冊（attestation）要由伺服器控制何時發起，理由是讓 App 維持在安全的每秒請求量以內。
   • Google standard 請求不需要伺服器發 challenge（Android：standard 頁）。
   • 兩個平台共用同一個發 challenge 入口，給 challenge 很短的有效時間，並綁定發給哪個使用者或 session 設計建議（非官方）。
2. 綁定請求內容：本系列把 Apple 的 clientDataHash（assertion 時）和 Google 的 requestHash 對照來看，它們都是「把這次請求的內容做成雜湊，交給平台一起簽進去」，所以可以用同一套程式產生。這個對照是本系列的整理，官方沒有這樣並列。
3. 按平台分流驗證：看請求來自哪個平台，交給對應的驗證器，檢查項目照 L1、L2 的官方清單。
4. 正規化成共同判定：兩個驗證器都輸出同一種格式 設計建議（非官方）。
5. 依策略回應：用分級回應，而不是只有放行和拒絕（Android：Overview 頁）。兩個平台共用同一張策略表 設計建議（非官方）。

註冊入口（只有 Apple）：App 送來 attestation object → Apple 驗證器驗過 → 寫入註冊表；寫入前確認這把公鑰沒有綁在別的使用者身上（Apple：Validating 頁）。

Google 那一路要不要也自己發 challenge？

• 官方怎麼說：standard 請求由 Google 阻止同一個 token 被大量重複使用（原文 reused many times），不是保證只能用一次（Android：standard 頁）。
• 設計建議：Google 那一路也發 challenge，放進 requestHash 要雜湊的內容裡，就多一道「只能用一次」的檢查，兩個平台也能共用同一段程式 設計建議（非官方）。
• 代價：多一趟往返（先要 challenge 再送請求），而且伺服器要存發出去的 challenge。
• 為什麼值得：因為 Google 擋的是「大量」重複使用，所以少量重送仍要靠你自己的一次性檢查擋下；對敏感操作來說，多一趟往返換這道檢查通常划算。

一句話：一個入口發 challenge，兩個驗證器各驗各的，翻成同一種判定，再用同一張策略表回應；只有 Apple 多一條註冊入口。

平台差異怎麼吸收：各存什麼、各呼叫什麼

• Google 不用存每台裝置的資料：官方的 standard 流程裡沒有「伺服器存裝置資料」這一步，所以你的伺服器不必為每台 Android 裝置建檔。
• 另外有 device recall：Google 提供替每台裝置存少量自訂資料的功能，資料存在 Google 伺服器，App 重裝後仍在（Android：Overview 頁）。

位元組層級的驗證步驟（OID、X9.62 等），照 L1 收合區塊的逐步對照表做，這裡不重講。

兩道一次性檢查都要原子化

原子化＝「讀出舊值、比較、寫入新值」一次做完，中間不讓別的請求插隊。Apple 那一路有兩道一次性檢查：challenge 的消耗和 counter 的更新。

1. 攻擊者把同一個 assertion 同時送兩次。
2. 如果兩個請求都先讀到「challenge 還沒用過」、「counter 是 7」，就都會通過，重送成功。
3. 所以兩道檢查都要一次完成 設計建議（非官方）：
   • 第一道防線是 challenge：只有當這個 challenge 還沒被用過，才把它標成已用。
   • counter：只有當註冊表裡存的 counter 小於這次收到的 counter，才寫入。

一句話：Apple 那一路存註冊表、自己驗；Google 那一路幾乎不存東西、每次請 Google 解密；challenge 和 counter 兩道一次性檢查都要原子化。

正規化：共同判定長什麼樣

下面是一種共同判定的格式，欄位名稱是本系列自訂的 設計建議（非官方）。

• 被清空的判定：Google 重複解密同一個 token 時，裝置判定會變空、App 判定變成 UNEVALUATED（Android：standard 頁），所以在這張表裡自然會落到最低一級，不必另外處理。
• Apple 通過後算哪一級：視同 MEETS_DEVICE_INTEGRITY，再依 receipt 的風險指標偏高、或 counter 異常往下調 設計建議（非官方）。
• 為什麼不能硬畫成完全對等：Apple 驗過，代表 Apple 替「這把金鑰在 Apple 硬體上、跑在沒被改過的 App 裡」作證；但 Apple 自己也說，App Attest 無法百分之百找出作業系統被改過的裝置（Apple：DeviceCheck 頁）。

從判定到回應：決策圖

圖 B：從共同判定到分級回應。整張決策圖是設計建議（非官方）；分級回應的想法來自 Google 官方建議（點圖可放大）

• 附了證明但驗不過：一律當成「請求不乾淨」，直接拒絕，不走降級 設計建議（非官方）。
• 沒附證明，或拿不到結果（不支援、故障、配額用完、重試後仍失敗）：當成「不可信」那一級，交給策略表決定 設計建議（非官方）。這個模型來自 Google：它的錯誤處理指引說，重試三次仍失敗，就當作沒通過所有檢查（Android：Error codes 頁）；本系列把這個模型套用到所有「拿不到結果」的情況。
• 加驗＝不直接放行，多要求一步驗證，例如再輸入密碼、做「我不是機器人」驗證，或請使用者自己補救（L2 的補救對話框）。
• 分級回應：Google 官方舉的例子是 Allow、Allow with limits、Allow with limits after CAPTCHA completion、Deny（Android：Overview 頁）。「高／中／低／不可信」怎麼切，要看你的業務 設計建議（非官方）。
• 高等級的裝置比較少：只認最高等級會擋掉很多人（Android：Overview 頁）。

一句話：附了證明但驗不過就拒絕；拿不到證明就當「不可信」那一級；驗過了再看可信到哪一級。

拿不到證明時：各種情況怎麼處理

拿不到證明時：fail-open 還是 fail-closed

• fail-open＝拿不到證明時，先放行（但限制）；fail-closed＝拿不到證明時，先擋下（加驗或拒絕）。
• 低風險操作（例如領每日簽到獎勵）：fail-open，放行但限制，靠其他訊號補 設計建議（非官方）。
• 高風險操作（例如轉出點數）：fail-closed，改成加驗，而不是直接拒絕。Google 官方建議：遇到高價值或敏感功能，"instead of denying access outright. When possible, challenge risky traffic before allowing high-value actions to proceed"（Android：Overview 頁「Challenge risky traffic when accessing high value or sensitive features」）。
• 理由：fail-closed 會讓平台一出問題就擋到所有正常使用者；fail-open 會讓攻擊者故意製造「拿不到證明」來繞過：Google 也說，拿不到結果的原因可能包括 "an attempt by an attacker"（Android：Error codes 頁）。依敏感度分開處理，是在這兩個風險之間取捨。

一句話：拿不到證明時，當成「不可信」那一級；低風險放行但限制，高風險加驗或擋下。

上線策略

先只收集、不擋人：Google 官方建議先接上 API、不執行，了解現有使用者會拿到什麼判定，再估算影響（Android：Overview 頁）。Apple 那一路也照樣做，觀察一段時間後再從最敏感的操作開始逐步收緊 設計建議（非官方）。

一句話：先觀察再收緊；Apple 真正的上限是每秒 100 次，Google 的配額要在上線前申請好。

設備證明在整體防線裡的位置

• 它只是一層訊號：Google 說 Play Integrity 最好搭配其他訊號，不該是唯一的防濫用機制（Android：Overview 頁）；Apple 說沒有任何單一政策能消除所有詐騙，App Attest 提供的是可以整合進整體風險評估的資訊（Apple：DeviceCheck 頁）。
• OWASP 的定位：MASVS 把「驗證平台的完整性」（MASVS-RESILIENCE-1）和「防竄改機制」（MASVS-RESILIENCE-2）歸在韌性控制裡。韌性控制是額外的保護，原文說 "The absence of these measures does not in itself constitute a vulnerability"；App 仍然要依自己的威脅模型（according to their threat model），滿足 MASVS 其他所有控制項（OWASP MASVS-RESILIENCE）。
• 所以它不能取代：登入驗證、權限檢查、伺服器端的業務規則（例如一個帳號一天能兌換幾次）。設備證明回答的是「是不是正版 App、真裝置」，不是「這個人有沒有權限做這件事」。

一句話：設備證明讓攻擊變貴，但登入、權限和業務規則還是得在伺服器端做好。

全系列回顧

• L0：伺服器不能相信 App 自己說的話；設備證明靠三塊積木撐著：簽章與憑證鏈、硬體保護的金鑰、challenge。
• L1：Apple 先註冊一次（印鑑登記），之後每次請求蓋章，你的伺服器自己驗章。
• L2：Google 把判定結果裝進密封信封，拿去 Google 的驗件窗口代驗。
• L3：你的伺服器用一套流程統一接住兩邊，再依策略分級回應。

✔ 過關標準

能不看筆記回答下面 5 題，這條 roadmap 就走完了。

1. 畫出統一驗證的五個步驟，以及 Apple 多出來的那條路。看答案收合

   發 challenge → 綁定請求內容（clientDataHash／requestHash）→ 按平台分流給 Apple 或 Google 驗證器 → 正規化成共同判定 → 依策略分級回應。Apple 另有註冊入口：驗 attestation、寫入註冊表，並確認公鑰沒綁在別的使用者上。
2. Apple 和 Google 驗證器各要存什麼、各要呼叫什麼？看答案收合

   Apple：存註冊表（公鑰、counter、receipt）和發出去的 challenge；驗證時不用呼叫 Apple。Google standard：存 service account 憑證，不必存每台裝置的資料（若自己發 challenge 就要存 challenge），每次呼叫 decodeIntegrityToken 請 Google 解密。
3. 為什麼 challenge 和 counter 都要原子化？看答案收合

   同一個 assertion 同時送兩次時，兩個請求可能都讀到「challenge 沒用過、counter 是舊值」，都通過，重送就成功了。第一道防線是 challenge 的消耗，第二道是 counter 的更新，兩道都要一次做完。（這是設計建議，官方只要求 challenge 一次性、counter 大於上次。）
4. 「附了證明但驗不過」和「拿不到證明」各怎麼處理？fail-open 和 fail-closed 是什麼？看答案收合

   驗不過：直接拒絕。拿不到證明：當成「不可信」那一級，交給策略表。fail-open＝拿不到證明時先放行但限制，適合低風險操作；fail-closed＝拿不到證明時先加驗或擋下，適合高風險操作。
5. 設備證明能取代登入驗證嗎？為什麼？看答案收合

   不能。它只回答「是不是正版 App、真裝置」。Google、Apple、OWASP 都說它只是整體防線的一部分；登入、權限和業務規則仍要在伺服器端做。

延伸閱讀

• 想把 Apple 那一路做完整：Apple 的「Validating apps that connect to your server」和「Attestation Object Validation Guide」。
• 想把 Google 那一路做完整：Android 的「Integrity verdicts」和 Overview 頁的安全建議段落。
• 想從威脅模型看整體防線：OWASP MASVS 的 MASVS-RESILIENCE，以及 MASTG 的對應測試。

參考來源

• Apple Developer — DeviceCheck（沒有單一政策能消除所有詐騙、無法百分之百找出被改過的作業系統）
• Apple Developer — Validating apps that connect to your server（伺服器發 challenge 並記住、要存什麼、公鑰不可綁在別的使用者、counter 要大於上次）
• Apple Developer — Establishing your app's integrity（不支援時優雅略過、can no longer require assertions、assertion 留給敏感時刻、重裝後重來）
• Apple Developer — Preparing to use the App Attest service（分批上線的經驗法則、每秒呼叫量建議、被限流時要能降量）
• Apple Developer — Assessing fraud risk（receipt 與風險指標）
• Apple Developer — DCError.serverUnavailable（attestation 時連不到 Apple、用同樣輸入重試）
• WWDC26 — Secure your apps with App Attest（伺服器控制何時發起 attestation、assertion 在本機產生、counter strictly increasing 與異常訊號、不要直接拒絕新金鑰）
• Android Developers — Overview of the Play Integrity API（搭配其他訊號、先收集再執行、分級與一系列回應、適當時機要求判定、看得懂的錯誤訊息、規劃故障、device recall）
• Android Developers — Make a standard API request（decodeIntegrityToken、service account、reused many times、清空規則）
• Android Developers — Make a classic API request（nonce 紀錄、需要 Google Play Store 與 Google Play services）
• Android Developers — Set up Play Integrity API（每日配額、申請提高最多一週、用量警報、逐步上線）
• Android Developers — Play Integrity API error codes（背景操作的重試策略、三次仍失敗視為未通過）
• OWASP MASVS — MASVS-RESILIENCE（RESILIENCE-1／-2、韌性控制是額外保護、依威脅模型滿足其他控制項）
• OWASP MASVS — Platform Lock-in（依賴平台服務可能排除正常使用者）