導覽本系列 18 篇文章與導讀，適用於 HackMD/Markdown 瀏覽。

前言：風險指標的取得方式 Receipt 提供 風險評估指標（Risk Metric），幫助判斷裝置是否可疑。 本文重點： Receipt 的取得流程（attestation receipt → API → 新 receipt） PKCS#7 Receipt 結構規格 Receipt Fields 欄位定義（type 編號對應） Risk Metric 解讀

前言：每次請求的身份證明 完成 Attestation 註冊後，每次 API 請求都需要附上 Assertion：證明「這個請求確實來自註冊過的裝置」。 本文重點： Assertion 的資料結構（signature + authenticatorData） 6 個驗證步驟的詳細解析 Counter 防重放機制 與 Attestation 的差異

前言：裝置註冊的關鍵 Apple App Attest 的第一步是 Attestation（認證註冊）：裝置向伺服器證明「我是真實的 iOS 裝置」，並建立一組專屬金鑰對。 本文重點： Attestation Object 的完整結構（CBOR + X.509 + PKCS#7） 9 個驗證步驟的詳細解析 每個格式在實際驗證中的角色 前置知識整合：

前言:從密碼到裝置的信任轉換 經過前面文章的深入學習,我們已經掌握了密碼學的理論基礎和資料格式。現在我們要理解:為什麼 Apple App Attest 要基於 WebAuthn 設計?這個協定如何重新定義了現代身分驗證的信任模型。 傳統身分驗證的困境 密碼驗證的根本問題 傳統驗證流程: 使用者 → [密碼] → 服務器 問題: ├── 密碼可被竊取 ├── 密碼可被猜測

前言：為什麼需要學 JWT？ 在實作 App Attest 或 Play Integrity 驗證時，你會遇到一個共同的問題：如何呼叫 Apple 或 Google 的 API？ 🔑 實際場景 驗證 App Store Receipt： 你的伺服器：「Apple，請幫我驗證這個 receipt」 Apple API：「你是誰？證明你有權限呼叫這個 API」 你的伺服器：「這是我的 JWT token（auth token）」 Apple API：「驗證通過，這是 receipt 的內容」

前言：什麼是 PKCS#7？ 為什麼需要 PKCS#7？ 當你需要傳遞帶有數位簽章的資料時，會遇到一些問題： 問題情境： 你要傳送一份重要文件給對方： ├── 文件本身（資料） ├── 你的數位簽章（證明是你簽的） └── 你的憑證（讓對方能驗證簽章）

前言: 從 App Attest 公鑰提取說起 在實作 Apple App Attest 時,你會遇到橢圓曲線公鑰。這些公鑰需要用標準格式表示和傳輸，X9.62 就是定義橢圓曲線點（公鑰）編碼方式的標準。 本文重點： X9.62 格式：橢圓曲線點如何表示成二進位（04 || X || Y） SPKI 結構：X9.62 點如何包裝成完整的公鑰（加上演算法資訊） 在 App Attest 中的應用：憑證裡的公鑰如何組織 什麼是 X9.62?

🎯 本系列的學習目標 當你學完系列二的密碼學演算法（ECC、ECDSA、數位簽章）後，下一個問題是： 這些演算法產生的資料，如何儲存和傳輸？ 你會遇到各種陌生的術語： 📦 CBOR：二進位資料序列化格式 🪪 X.509：數位憑證的標準格式 🔤 ASN.1：定義資料結構的語言

前言：解開憑證「亂碼」的謎團 在第 10 篇，我們了解了 X.509 憑證的邏輯結構：它包含哪些欄位（version、subject、issuer、publicKey 等）、每個欄位的用途、憑證鏈如何透過 subject 和 issuer 配對。 這些概念很清楚。但當你實際查看憑證檔案時，會看到這樣的東西： 30 82 02 cc 30 82 02 34 a0 03 02 01 02 02 10 1a 2b 3c 4d... 或是這樣： -----BEGIN CERTIFICATE----- MIICzDCCAbSgAwIBAgIQGis8TTBAQEBAQEBAQEBAQEBAQDANBgkqhkiG9w0BAQUF

前言：憑證到底是什麼？ 還記得我們在系列二學到的「信任鏈」嗎？當時我們說：裝置有一組公私鑰對，但伺服器怎麼知道這個公鑰真的屬於這個裝置？答案就是：數位憑證。 在第 6 篇，我們看到 CBOR 可以包裝資料，而在實際應用中（例如 App Attest），CBOR 裡面會有個欄位叫 x5c，裡面裝的就是「憑證鏈」。 這些憑證用 X.509 格式儲存，它實現了我們之前學過的所有概念： 用 數位簽章來保證真實性 實現了 信任鏈的架構 包含 公鑰和身份資訊

前言：當你第一次看到 App Attest 的回應資料 經過前面五篇文章，我們已經理解了密碼學的核心概念： ECDSA 讓 iPhone 可以產生數位簽章 信任鏈 讓我們相信公鑰的真實性 數位簽章 在各種系統中的應用 現在有個實際問題：當 iPhone 要把這些密碼學資料（公鑰、簽章、憑證）傳給伺服器時，要用什麼格式包裝？ 你可能會想：「用 JSON 不就好了嗎？」但當你看到 Apple App Attest 的回應時，會發現它用的是一種叫 CBOR 的格式。為什麼？