裝置認證用硬體金鑰加密證明裝置真實性：Play Integrity、App Attest 的原理與隱私代價。
核心要點
- 裝置認證是密碼學證明，而不是統計猜測。 硬體層級的信任根會對一份聲明簽章，斷言裝置、作業系統與應用程式未被竄改，伺服器再用廠商的金鑰驗證這個簽章。
- 目前有兩套方案已經上線： Android 上的 Play Integrity API（取代了舊版 SafetyNet Attestation），以及 iOS 上的 App Attest / DeviceCheck。
- 瀏覽器版本的方案已被撤回。 Google 針對開放網頁提出的 Web Environment Integrity 從未上線——但 Google 在 Android 上更新的遠端認證方案，又重新點燃了同樣的爭議，參見電子前哨基金會（EFF）2026 年 7 月的批評文章。
- 裝置認證和瀏覽器指紋回答的是同一個問題——「這是真的嗎？」——但方式完全不同。 指紋辨識是從大量弱訊號中推斷，而裝置認證是斷言一個經過密碼學簽章的強訊號。
- 代價是平台把關權的集中。 一套能攔截被竄改裝置的方案，同樣可能連帶排除掉被 root 過的手機、替代瀏覽器和從未打算作惡的隱私工具。
新聞由頭：EFF 對 Google 新一輪遠端認證方案的警告
2026 年 7 月，EFF 發表了《Google 的新遠端認證方案和舊方案一樣糟糕》一文，認為 Google 針對 Android 推出的最新裝置認證方案，重蹈了先前提案的覆轍：它讓認證結果成為存取應用程式和服務的門檻，判斷依據是裝置的軟體堆疊是否符合「已核准、未經修改」的設定——這在擋下真正惡意流量的同時，也把自訂 ROM、被 root 過的裝置和替代瀏覽器一併排除在外。
這篇批評文章鎖定的是 Google 的某一項具體舉措，但裝置認證這套底層機制要廣泛得多：它已經在行動平台上大規模部署，也曾一度被提議（後又撤回）用於網頁本身。真正持久有價值的部分，是理解它到底如何運作——某個具體方案的新聞熱度終會過去。
裝置認證到底是什麼
指紋辨識是一種推斷。網站會蒐集數十種個別都可能被偽造的弱訊號——canvas 渲染結果、字型清單、螢幕尺寸、GPU 渲染器字串，再用統計方法判斷這些訊號組合起來是否像一台真實、一致的裝置。我們的瀏覽器指紋指南詳細介紹了這種推斷是如何建立的。
裝置認證則完全跳過了推斷這一步。它依賴裝置晶片內建的硬體信任根——可信任執行環境（TEE）或安全隔區——用一把任何軟體都無法取出的私鑰對聲明簽章。這份簽章聲明（「認證權杖」）斷言的是具體、可核驗的事實：Bootloader 是否已解鎖、作業系統是否符合已知的正版映像、發出請求的應用程式簽章是否與發佈版本一致。遠端伺服器用硬體廠商的公鑰驗證這個簽章，藉此決定信任或拒絕這枚權杖。
差異的關鍵在於：指紋可以被任何能令人信服地偽造執行環境的腳本騙過；而認證權杖若不破解硬體私鑰或攻破驗證方的密碼學方案，就無法偽造——這比修改幾個 navigator 屬性要困難得多。
真正存在的方案有哪些
「認證」這個詞很容易把三種不同的東西混為一談，因此有必要釐清哪些是真的已經上線，哪些只是被提議、後來又夭折的。
Android——Play Integrity API。 這是 Google 目前用於 Android 應用程式的機制，取代了更早的 SafetyNet Attestation。應用程式呼叫此 API 後會得到一份判定結果，涵蓋裝置完整性（這是不是一台正版、未被竄改的 Android 裝置）、應用程式完整性（這個應用程式是否透過 Google Play 安裝、且未被竄改）以及帳號資訊。銀行類應用程式、有反作弊需求的遊戲、依賴 DRM 的影音應用程式是最典型的使用方。
iOS——App Attest 與 DeviceCheck。 Apple 對應的一對機制：App Attest 讓應用程式能向伺服器證明某次請求確實來自該應用程式在正版 Apple 硬體上執行的一個實例，依據的是安全隔區（Secure Enclave）產生的硬體金鑰。DeviceCheck 是更早、更粗粒度的版本，主要用於裝置層級的詐騙訊號，例如「這台裝置是否已經領過免費試用」。
網頁——Web Environment Integrity（已撤回）。 Google 曾提議把同樣的想法帶進瀏覽器：一個 JavaScript 介面，讓網站能請求一枚認證權杖，證明瀏覽器本身未被修改、執行在受信任的作業系統之上。反對聲浪幾乎立刻出現，瀏覽器廠商和隱私倡議者都表示反對——這不只會擋下機器人，還會讓網站拒絕為廣告攔截器、替代瀏覽器或自動化無障礙工具提供服務。該提案已從積極開發中撤回。這裡有必要說清楚：WEI 從未上線，而 Play Integrity 和 App Attest 卻已在正式環境的應用程式中真實生效。EFF 在 2026 年這篇文章中認為，Google 在 Android 一側的新一輪認證舉措，是在另一個場景下重提了同樣的核心爭議。
這對機器人與真人的判定意味著什麼
裝置認證比典型的機器人偵測方案要強得多，因為它完全不依賴推斷。一台被 root 過的 Android 模擬器可以偽造 User-Agent 字串，甚至修改 navigator.webdriver，但在沒有真機硬體金鑰的情況下，通常無法產生一枚有效的 Play Integrity 權杖——這也是為什麼無頭瀏覽器偵測這類技術會去捕捉網頁端指紋偽造遺漏的那些破綻，因為網頁目前還沒有對應的硬體認證方案。正因如此，詐騙風險高的行動應用程式——銀行、博弈、票務——才更傾向依賴 Play Integrity 和 App Attest，而非瀏覽器式的指紋評分：密碼學證明比統計畫像更難被大規模偽造。
隱私代價
EFF 批評的核心，也是裝置認證充滿爭議、而非「顯然正確」的原因在於：能擋下作弊遊戲用戶端或詐騙機器人的同一套機制，同樣也會擋下那些執行自訂 ROM、自行解鎖 Bootloader，或使用注重隱私之替代瀏覽器的合法使用者。裝置認證無法區分「為了作弊而修改」和「為了加裝廣告攔截或無障礙功能而修改」——它只能證明軟體堆疊是否符合平台廠商核准的某個設定，而這個把關權集中在 Google 或 Apple 手中，而非站台營運者或使用者自己。
這恰好是「如何證明這是一個真人」這個問題的另一種正在興起的解法的鏡像：匿名憑證讓使用者能夠證明某個狹窄的屬性（例如「不是機器人」），卻完全不透露裝置身分。裝置認證和匿名憑證是對相近問題的兩種相反回答——一個證明「這是這台經核准的特定裝置」，另一個證明「這是某個合法使用者，但不說是誰」。兩者並無絕對優劣，只是在可驗證性與使用者自主權、平台開放性之間做出了方向相反的取捨。
現在這一切對你意味著什麼
對網頁使用者來說，眼下什麼都不會改變——Web Environment Integrity 已被撤回，目前也沒有任何瀏覽器提供裝置認證介面。而行動應用程式使用者其實早已頻繁地、往往是無感地與 Play Integrity 和 App Attest 打交道，只要開啟一次銀行或遊戲類應用程式就會觸發。真正值得了解的是基準情況：在完全沒有硬體認證參與的前提下，網站眼下究竟能觀察到你裝置的哪些資訊。
常見問題
裝置認證和瀏覽器指紋是同一回事嗎？
不是。指紋辨識是從 JavaScript 蒐集的大量弱訊號、可被偽造的訊號中推斷裝置一致性；裝置認證則是硬體信任根給出的單一密碼學簽章聲明，只要底層密碼學沒被攻破，就無法偽造。
網站現在能使用裝置認證嗎？
瀏覽器端目前不行——本可以讓這一切實現的 Web Environment Integrity 提案已被撤回。裝置認證如今只在原生行動應用程式內真實生效，依靠的是 Android 的 Play Integrity 和 iOS 的 App Attest / DeviceCheck。
root 或越獄裝置會讓認證失效嗎？
一般來說會，而且這正是設計使然——這恰恰是裝置認證要回報的訊號，因為被修改的 Bootloader 或作業系統本身就是硬體信任根要斷言的「事實」之一。這也正是 EFF 批評的核心：擋下被竄改詐騙裝置的同一道關卡，也會擋下那些出於正當理由修改了自己硬體的機主。
現在就看看網站能觀察到你的哪些資訊
裝置認證是行動平台已經在強制執行、而網頁幾乎要採納的一種硬體層級證明；指紋辨識與行為評分才是網站今天真正用來評估你瀏覽器的手段。在 BrowserInsight 上同時看看這兩面：機器人偵測工具會展示偵測系統能評分的自動化與一致性訊號，指紋檢測則會展示在完全沒有裝置認證參與的情況下，網站能取得的完整裝置訊號集合。
