5 三原語的能力邊界：第一部總整理

第一部走到這裡，工具箱裡有三個原語、一套把它們組裝起來的建築（PKI）、一個封裝好的成品（AEAD）。這一章不教新東西——它做一件更重要的事： 把每個工具「給什麼、不給什麼」的邊界畫清楚，然後把序章的六個攻擊面逐一對回來，看哪些是密碼學堵得住的、哪些根本不是密碼學的問題。

這張地圖，就是第二部走進真實供應鏈時你手上的裝備清單。

5.1 三個原語，一張表

先預測：hash、簽章、MAC——哪一個能提供「不可否認」？哪一個連「身分」都不提供？

原語	給你什麼	關鍵限制
Hash（雜湊，SHA-256）	完整性（內容沒被改）	不提供身分——任何人都能對任何內容算 hash；也不可逆
數位簽章（私鑰簽／公鑰驗）	真實性＋完整性＋不可否認	需要 PKI 分發／信任公鑰；不保密
MAC（共享金鑰）	真實性＋完整性	沒有不可否認（金鑰共享，雙方都算得出來）

三個限制各值得多咬一口：

Hash 不提供身分，這件事在供應鏈上天天被誤用。網站上擺一個下載檔＋旁邊擺它的 SHA-256——如果攻擊者能換掉檔案，他就能順手換掉旁邊的 hash。同一個網頁上的 hash 只防「傳輸壞掉」，不防「有人掉包」。hash 要有安全意義，它必須經由另一條你信任的通道 到你手上——而「另一條可信通道」講到底，通常就是簽章。
簽章需要 PKI，意思是：簽章的保證強度，上限就是你信任錨點的強度（第 3 章）。驗章成功＝「鏈通到某個錨點」，錨點錯了一切白搭。
MAC 沒有不可否認，所以它適合「雙方互信、只防外人」的通道（session 內的訊息完整性），不適合「事後要對第三方舉證」的場景（成品簽章要能拿去給稽核看——那必須是簽章）。

5.2 原語是疊起來的

第一部反覆出現一個結構，值得明說：這些原語不是並列的，是疊的。

trust anchor（人為授予）            ← 第 3 章：遞迴的終點
  └─ PKI / 憑證鏈                  ← 第 3 章：簽章的遞迴套用
       └─ 數位簽章                 ← 第 2 章：私鑰簽、公鑰驗
            └─ hash               ← 第 2 章：實務簽的是摘要

每一層都站在下一層上：簽章的完整性站在 hash 的抗碰撞上；憑證的可信站在 CA 簽章上； CA 的可信站在信任錨點上；而錨點——是人放進去的。往下追到底，你會再一次撞到全書的主線：

信任不是被算出來的，是被授予的。密碼學負責把授予的信任「保真地傳遞」—— 可驗證、防竄改、能疊加——但它無法無中生有地製造信任。

這也給你一個實用的分析習慣：看到任何「可信」的宣稱，就往下剝——它站在哪個原語上？那個原語又站在什麼上？剝到最底，找到那個「人為決定」，然後問：這個決定合理嗎？

5.3 把六個攻擊面對回來

序章那張圖（source → build → artifact → feed → deploy → production）現在可以逐格檢查了。先預測：六個攻擊面裡，你覺得哪幾個是「簽章能直接堵住」的？

攻擊面	原語能做什麼	原語做不到的（誠實邊界）
① Source	commit 簽章（如 git 的簽章機制）證明「這個 commit 是這把鑰匙的持有者做的」	擋不住帳號／鑰匙被盜，更擋不住 xz 式的「本人自願下毒」——簽章驗的是鑰匙，不是動機
② Build	對 build 產出簽 provenance（來源證明：誰、何時、從哪個 commit build 的），把「情境」綁進被簽內容——第 4 章 `To: Bob` 的教訓	build 環境本身被污染（SolarWinds），簽章只會忠實地幫毒成品背書
③ Artifact	主戰場：成品簽章＋hash 讓「掉包」必被抓——xz 那種 tarball ≠ git 內容的落差，可驗證 build 能抓出來	前提是驗章方真的驗、且錨點正確
④ Feed	簽章能驗「套件是某維護者簽的」	驗不出「維護者換人了」「typosquat 的套件也有合法簽章」——身分正確 ≠ 身分可信
⑤ Deploy	部署前驗簽章＋用 digest（hash）取代可漂移的 tag，確保「上線的＝簽核的那份」	政策要有人定：驗失敗誰擋、誰能豁免——那是治理，不是密碼學
⑥ Production	執行期持續驗（admission control 類機制）	跑起來之後的行為，簽章管不到——那是監控的領域

右欄請跟左欄一樣認真讀。這本書如果只讓你帶走一個習慣，我希望是： 每次有人（包括未來的你）說「有簽章所以安全」，你自動追問三件事—— 簽的內容涵蓋了什麼情境？驗到哪個錨點？右欄那些它管不到的，誰在管？

5.4 全書地圖：你在這裡

flowchart LR
  subgraph P1["第一部 信任的原語（你在這裡）"]
    direction LR
    A["02 數位簽章"] --> B["03 PKI 信任鏈"] --> C["04 認證加密"] --> D["05 能力邊界"]
  end
  subgraph P2["第二部 把信任套到產線"]
    direction LR
    E["06 SSDF 驗收標準"] --> F["07 成品簽章與晉級"] --> G["08 金鑰保管"]
  end
  D --> E

图 5.1: 全書地圖。第一部搭原語；第二部把原語套到產線：驗收標準、成品簽章、金鑰保管。

第二部要做的事，一句話：拿著本章這張能力邊界表，走進 NIST SSDF（SP 800-218）(National Institute of Standards and Technology 2022年) 的條文和典型銀行環境的 CI/CD，把每一條「要求」對回「哪個原語＋哪個人為決定」，然後留下真的做過一遍的實作紀錄——包括做不到、做了才發現不對的部分。

本章帶走的東西：hash 給完整性但不給身分；簽章給不可否認但上限是錨點；MAC 給不了不可否認；原語是疊的，剝到底永遠是一個人為的信任決定；六個攻擊面裡密碼學是必要條件，但每一格都有右欄——簽章管不到的部分，得靠治理和人。

第一部到此收工。工具都在手上了——第二部，我們去工地。

National Institute of Standards and Technology. 2022年. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication Nos. 800-218. National Institute of Standards; Technology. https://doi.org/10.6028/NIST.SP.800-218.

# 三原語的能力邊界：第一部總整理第一部走到這裡，工具箱裡有三個原語、一套把它們組裝起來的建築（PKI）、一個封裝好的成品（AEAD）。這一章不教新東西——它做一件更重要的事： **把每個工具「給什麼、不給什麼」的邊界畫清楚**，然後把序章的六個攻擊面逐一對回來，看哪些是密碼學堵得住的、哪些根本不是密碼學的問題。這張地圖，就是第二部走進真實供應鏈時你手上的裝備清單。 ## 三個原語，一張表先預測：hash、簽章、MAC——哪一個能提供「不可否認」？哪一個連「身分」都不提供？ | 原語 | 給你什麼 | 關鍵限制 | |---|---|---| | **Hash（雜湊，SHA-256）** | 完整性（內容沒被改） | **不提供身分**——任何人都能對任何內容算 hash；也不可逆 | | **數位簽章（私鑰簽／公鑰驗）** | 真實性＋完整性＋**不可否認** | 需要 PKI 分發／信任公鑰；**不保密** | | **MAC（共享金鑰）** | 真實性＋完整性 | **沒有不可否認**（金鑰共享，雙方都算得出來） | 三個限制各值得多咬一口： - **Hash 不提供身分**，這件事在供應鏈上天天被誤用。網站上擺一個下載檔＋旁邊擺它的 SHA-256——如果攻擊者能換掉檔案，他就能順手換掉旁邊的 hash。同一個網頁上的 hash 只防「傳輸壞掉」，不防「有人掉包」。hash 要有安全意義，它必須經由**另一條你信任的通道** 到你手上——而「另一條可信通道」講到底，通常就是簽章。 - **簽章需要 PKI**，意思是：簽章的保證強度，**上限就是你信任錨點的強度**（第 3 章）。驗章成功＝「鏈通到某個錨點」，錨點錯了一切白搭。 - **MAC 沒有不可否認**，所以它適合「雙方互信、只防外人」的通道（session 內的訊息完整性），不適合「事後要對第三方舉證」的場景（成品簽章要能拿去給稽核看——那必須是簽章）。 ## 原語是疊起來的第一部反覆出現一個結構，值得明說：**這些原語不是並列的，是疊的。** ``` trust anchor（人為授予） ← 第 3 章：遞迴的終點 └─ PKI / 憑證鏈 ← 第 3 章：簽章的遞迴套用 └─ 數位簽章 ← 第 2 章：私鑰簽、公鑰驗 └─ hash ← 第 2 章：實務簽的是摘要 ``` 每一層都站在下一層上：簽章的完整性站在 hash 的抗碰撞上；憑證的可信站在 CA 簽章上； CA 的可信站在信任錨點上；而錨點——是人放進去的。往下追到底，你會再一次撞到全書的主線： > **信任不是被算出來的，是被授予的。**密碼學負責把授予的信任「保真地傳遞」—— > 可驗證、防竄改、能疊加——但它無法無中生有地製造信任。這也給你一個實用的分析習慣：看到任何「可信」的宣稱，就往下剝——它站在哪個原語上？那個原語又站在什麼上？剝到最底，找到那個「人為決定」，然後問：**這個決定合理嗎？** ## 把六個攻擊面對回來序章那張圖（source → build → artifact → feed → deploy → production）現在可以逐格檢查了。先預測：六個攻擊面裡，你覺得哪幾個是「簽章能直接堵住」的？ | 攻擊面 | 原語能做什麼 | 原語做不到的（誠實邊界） | |---|---|---| | ① Source | commit 簽章（如 git 的簽章機制）證明「這個 commit 是這把鑰匙的持有者做的」 | 擋不住**帳號／鑰匙被盜**，更擋不住 xz 式的「本人自願下毒」——簽章驗的是鑰匙，不是動機 | | ② Build | 對 build 產出簽 provenance（來源證明：誰、何時、從哪個 commit build 的），把「情境」綁進被簽內容——第 4 章 `To: Bob` 的教訓 | build **環境本身**被污染（SolarWinds），簽章只會忠實地幫毒成品背書 | | ③ Artifact | **主戰場**：成品簽章＋hash 讓「掉包」必被抓——xz 那種 tarball ≠ git 內容的落差，可驗證 build 能抓出來 | 前提是驗章方真的驗、且錨點正確 | | ④ Feed | 簽章能驗「套件是某維護者簽的」 | 驗不出「維護者換人了」「typosquat 的套件也有合法簽章」——**身分正確 ≠ 身分可信** | | ⑤ Deploy | 部署前驗簽章＋用 digest（hash）取代可漂移的 tag，確保「上線的＝簽核的那份」 | 政策要有人定：驗失敗誰擋、誰能豁免——那是治理，不是密碼學 | | ⑥ Production | 執行期持續驗（admission control 類機制） | 跑起來**之後**的行為，簽章管不到——那是監控的領域 | 右欄請跟左欄一樣認真讀。這本書如果只讓你帶走一個習慣，我希望是： **每次有人（包括未來的你）說「有簽章所以安全」，你自動追問三件事—— 簽的內容涵蓋了什麼情境？驗到哪個錨點？右欄那些它管不到的，誰在管？** ## 全書地圖：你在這裡 ```{mermaid} %%| label: fig-bookmap %%| fig-cap: "全書地圖。第一部搭原語；第二部把原語套到產線：驗收標準、成品簽章、金鑰保管。" flowchart LR subgraph P1["第一部信任的原語（你在這裡）"] direction LR A["02 數位簽章"] --> B["03 PKI 信任鏈"] --> C["04 認證加密"] --> D["05 能力邊界"] end subgraph P2["第二部把信任套到產線"] direction LR E["06 SSDF 驗收標準"] --> F["07 成品簽章與晉級"] --> G["08 金鑰保管"] end D --> E ``` 第二部要做的事，一句話：拿著本章這張能力邊界表，走進 NIST SSDF（SP 800-218）[@nist2022ssdf] 的條文和典型銀行環境的 CI/CD，把每一條「要求」對回「哪個原語＋哪個人為決定」，然後留下真的做過一遍的實作紀錄——包括做不到、做了才發現不對的部分。 --- **本章帶走的東西**：hash 給完整性但不給身分；簽章給不可否認但上限是錨點；MAC 給不了不可否認；原語是疊的，剝到底永遠是一個人為的信任決定；六個攻擊面裡密碼學是必要條件，但每一格都有右欄——簽章管不到的部分，得靠治理和人。第一部到此收工。工具都在手上了——第二部，我們去工地。