STEP 1

深度探秘

想分享，才需要安全

安全需求從哪裡來

課本給了一個很反直覺的起點：

在分散式系統中需要安全機制，根本原因是『想要分享資源』。

如果一個資源完全不分享，把它鎖在隔離的房間裡、不連網路就好，根本不需要花俏的密碼學。麻煩就出在：我們想讓某些人用、卻不想讓另一些人用。一旦資源透過網路開放給外界存取，攻擊者就有機會插手。

要把『誰能用、用到什麼程度』講清楚，要分成兩個層次：

• 安全政策 (security policy)：規定要保護什麼、誰可以做什麼。例如『只有員工能進大樓』『只有帳戶持有人能轉帳』。政策和技術無關。
• 安全機制 (security mechanism)：負責把政策落實。例如門口的警衛、電子門鎖、加密、簽章。

這兩者一定要分開。就像門上裝了鎖（機制），但如果沒人規定『沒人看守時要鎖門』（政策），這把鎖也保護不了大樓。光有機制、沒有政策，你根本說不清一個系統到底安不安全。

威脅的三大類

安全的主要目標是：只讓被授權的主體存取資訊與資源。威脅分成三大類：

• 洩漏 (Leakage)：資訊被未授權者取得。
• 竄改 (Tampering)：資訊被未授權地修改。
• 破壞 (Vandalism)：干擾系統正常運作，但攻擊者自己沒得到好處（純搞破壞）。

STEP 2

生活妙喻

公司大樓的門禁制度

把安全想成一棟公司大樓

想像你管理一棟公司大樓，這就是一個活生生的安全系統：

• 想分享才需要安全：如果這是一棟空屋、沒人進出，你不需要門禁。正是因為要讓員工進、不讓陌生人進，麻煩才來。
• 安全政策＝公司白紙黑字的規定：『只有員工和登記過的訪客能進大樓』『機密文件只有特定部門能看』。這是規則，跟用什麼鎖無關。
• 安全機制＝實際的執行手段：櫃台發訪客證、保全站崗、電子門鎖。

再看威脅三大類，對應大樓裡的三種壞事：

威脅	大樓裡的對應	攻擊者得到什麼
洩漏	有人偷看了機密文件	拿到資訊
竄改	有人偷改了合約上的金額	改掉內容圖利
破壞	有人把消防警報亂按一通	純粹搞亂，自己沒好處

關鍵體會：裝了鎖不等於安全。如果沒人規定『離開要鎖門』，再好的鎖也是擺設。政策和機制，缺一不可。

STEP 3

實用超能力

用『政策 vs 機制』診斷安全設計

學會分辨政策與機制

很多安全討論之所以講不清楚，就是把政策和機制混為一談。學會分開談，你就能更精準地設計與檢視系統。

試著對任何一句安全敘述，問自己：『這是在說要保護什麼（政策），還是在說用什麼手段保護（機制）？』

敘述	屬於
只有 HR 部門能看薪資資料	政策
薪資資料用 AES 加密儲存	機制
登入失敗五次要鎖帳號	政策
用 bcrypt 雜湊存密碼	機制

為什麼這個區分這麼重要

1. 可換機制不動政策：政策說『資料要保密』，今天用某加密法、明天換更強的，政策不變。
2. 可稽核：有了明確政策，你才能逐條檢查機制有沒有達成它。
3. 避免假安全：如果只堆機制（裝了一堆鎖）卻沒寫清楚政策，沒人說得出系統到底防住了什麼。

下次做安全設計，先把政策一條條列清楚（要防洩漏、竄改還是破壞？防誰？），再去挑機制。順序對了，設計就清楚了。

STEP 1

深度探秘

攻擊都從濫用通訊通道開始

攻擊者怎麼下手

課本把『通道 (channel)』定義為任何處理程序之間的通訊機制。對分散式系統的攻擊，幾乎都來自取得既有通道的存取權，或建立假冒授權連線的新通道。依照通道被濫用的方式，攻擊分成五種：

• 竊聽 (Eavesdropping)：未經授權取得訊息的副本。攻擊者只是『偷聽』，不改任何東西。
• 假冒 (Masquerading)：用別人的身分收發訊息。假裝成 Alice 去騙 Bob。
• 訊息竄改 (Message tampering)：攔下訊息、改掉內容、再送給原本的收件者。其中最厲害的是中間人攻擊 (man-in-the-middle)：攻擊者攔截金鑰交換的第一則訊息，偷偷塞進自己的金鑰，之後就能先解密、看完、再重新加密轉送，兩端都不知情。
• 重放 (Replaying)：把攔截到的訊息存起來，稍後再送一次。可怕的是，即使訊息是加密又經過認證的，重放照樣可能奏效——攻擊者根本不需要金鑰，只要原封不動複製那串位元再送出。例如一筆『付錢給某人』的請求被重放，就可能害你付兩次。
• 阻斷服務 (Denial of service, DoS)：用大量訊息淹沒通道或資源，讓其他人無法存取。

設計時要假設最壞情況

因為攻擊者能力強，課本要求設計時抱持悲觀假設：介面是暴露的（任何人都能送訊息進來）、網路是不安全的（來源可被偽造、位址可被冒名）、演算法與程式碼攻擊者都看得到（所以安全只能依賴金鑰的秘密，不能靠演算法保密）、攻擊者有龐大運算資源。

STEP 2

生活妙喻

郵差路上的五種壞事

把通道想成寄信的郵路

你 (Alice) 寫信給朋友 (Bob)，信要經過一段郵路。壞人 Mallory 能在路上動哪些手腳？正好對應五種攻擊：

• 竊聽：Mallory 偷拆信、影印一份、再原封不動放回去。你和 Bob 都不知道信被看過。
• 假冒：Mallory 用你的名義寫信給 Bob，Bob 以為是你寄的。
• 訊息竄改：Mallory 攔下你的信，把『匯款給張三』改成『匯款給我』，再封好送出。
  • 中間人更狡猾：你和 Bob 第一次想交換『只有彼此看得懂的暗號』，Mallory 在這第一封信就偷換成自己的暗號，從此你倆所有信他都能讀、能改，還能無縫轉送。
• 重放：你上週寄了一封『請幫我付這個月房租』的信，Mallory 影印起來，下個月再寄一次，房東就收了你兩次房租——他根本不用看懂信的內容。
• 阻斷服務：Mallory 灌爆 Bob 的信箱，塞滿幾千封垃圾信，讓 Bob 找不到也收不到你真正的信。

關鍵體會：重放最陰險——壞人不需要看懂內容，只要『複製一份原樣再送』就能造成傷害。

STEP 3

實用超能力

用攻擊清單為系統做威脅體檢

用五種攻擊掃描你的系統

設計或檢視任何網路服務時，逐一拿這五種攻擊去問『我擋得住嗎？』，就能快速找出弱點與對應的防禦工具。

攻擊	防禦的核心工具
竊聽	加密 (讓偷看到的也讀不懂)
假冒	認證 (證明對方真的是他)
訊息竄改	訊息完整性檢查 (摘要/MAC/簽章)
中間人	用可信通道取得的公鑰驗證憑證
重放	nonce 或時戳 (證明訊息是新鮮的)
DoS	流量限制、上游過濾、服務品質機制

攻擊流程示意

中間人攻擊之所以致命，是因為它卡在『建立信任』的最起點：

flowchart TD
  A[Alice 想取得 Bob 的公鑰] --> M[Mallory 攔截第一則訊息]
  M --> F[Mallory 回傳自己的公鑰冒充 Bob]
  F --> R[之後所有訊息 Mallory 先解密再轉送]
  R --> D[Alice 與 Bob 都以為通道安全]

下次設計登入或金鑰交換流程，特別留意第一則訊息怎麼建立信任——那往往是中間人攻擊的突破口。

STEP 1

深度探秘

從網購與網路銀行導出安全需求

電子交易要保護什麼

網路上的交易——email、買賣商品、銀行業務、微型付款——都極度依賴安全。課本用網購情境，整理出幾項具體的安全需求：

1. 認證賣方 (Authenticate the vendor)：買家要能確信自己連到的真的是那個賣家的伺服器，而不是冒牌貨。
2. 保護付款資訊：買家的信用卡號等資料不能落入第三方手裡，而且要原封不動地從買家傳到賣家（同時保密與完整）。
3. 保護下載內容：若商品是可下載的數位產品，要確保內容不被竄改、不外洩地交到買家手上。

有趣的是：賣方通常不需要知道買家的真實身分（除非要寄送實體商品）。賣家在意的是『買家有沒有錢付』，而這通常是透過向買家的銀行請款來確認，而不是查買家身分。

銀行情境的額外需求

網路銀行的安全需求和網購類似（買家＝帳戶持有人、銀行＝賣家），但多了第四項：

4. 認證帳戶持有人：在給予帳戶存取權之前，銀行要確認對方真的是帳戶持有人。

而且銀行還很在意一件事：帳戶持有人事後不能否認自己參與過交易。這個需求有個專有名詞叫 不可否認 (non-repudiation)。

大規模帶來的系統需求

Internet 太大了，不可能要求每個買家事先和每個賣家建立特殊關係（例如先註冊金鑰）。所以還有個系統需求：買賣雙方即使素未謀面、也沒有第三方介入，也要能完成一筆安全交易。

STEP 2

生活妙喻

在陌生市集買東西

把網購想成在陌生市集買東西

想像你到一個從沒去過的市集，向一個素未謀面的攤販買東西。你會擔心什麼？正好對應電子交易的安全需求：

• 認證賣方：你得確認這個攤位真的是『某某名店』，而不是掛羊頭賣狗肉的山寨攤。
• 保護付款資訊：你掏錢包時，不希望旁邊的扒手看到你的卡號，也不希望付款金額被人偷偷改大。
• 保護下載內容：如果你買的是『數位音樂下載券』，你要拿到完整、沒被掉包的檔案。
• 賣家不需要知道你是誰：攤販只關心你『付得出錢』，並不在意你叫什麼名字（除非要宅配到你家）。

再看銀行情境，多了兩件事：

• 認證帳戶持有人：銀行櫃員要先確認『你真的是這個帳戶的主人』才讓你領錢。
• 不可否認：你領完錢，不能事後翻臉說『我從來沒來領過』。所以銀行請你簽名留底——這正是數位簽章要做的事。

體會：陌生市集最棒的一點是——你和攤販第一次見面就能成交，不需要事先註冊會員。Internet 規模太大，安全機制也必須支援這種『陌生人也能安全交易』。

STEP 3

實用超能力

用需求清單檢視你用過的線上服務

把需求清單套到真實服務上

學會這套需求，你就能看穿任何線上交易服務在保護什麼、漏了什麼。以一個網路購物結帳流程為例：

安全需求	真實世界對應的技術
認證賣方	瀏覽器網址列的 https 與憑證、鎖頭圖示
付款資訊保密與完整	TLS 加密通道
保護下載內容	加密下載 + 完整性檢查
認證帳戶持有人 (銀行)	密碼、OTP、雙因素認證
不可否認	數位簽章、交易紀錄

為什麼『不可否認』對銀行特別重要

課本提到一個經典案例：提款機的『幽靈提款 (phantom withdrawal)』爭議——客戶聲稱『我沒領這筆錢』。銀行最好的回應，是拿出一份由帳戶持有人數位簽署、第三方無法偽造的交易紀錄。這就是不可否認的價值：它讓爭議有客觀證據可循。

一個容易踩的雷：cookie

課本特別點名：把過往交易紀錄存在使用者端的 cookie 有明顯安全弱點，因為桌機與行動裝置常處於不安全的實體環境。下次設計需要記住使用者狀態的功能，別把敏感憑證直接塞進 cookie。

STEP 1

深度探秘

加密的核心是一個叫金鑰的秘密

加密與金鑰

加密 (encryption) 就是把訊息編碼成『藏起內容』的形式。現代密碼學的加解密都建立在一個秘密——金鑰 (key) 之上。金鑰是加密演算法裡的一個參數，特性是：沒有金鑰，就無法逆轉加密。

常用的加密演算法分成兩大類：

對稱式 (Symmetric) — 共享秘密金鑰

寄件者和收件者共用同一把秘密金鑰，而且不能讓別人知道。同一把金鑰既用來加密，也用來解密。因為加解密用同一把鑰匙，所以又叫對稱式 (symmetric)。

非對稱式 (Asymmetric) — 公開/私密金鑰對

用的是一對金鑰：

• 公鑰 (public key)：收件者事先公開，任何人都能拿到，用來加密。
• 私鑰 (private key)：只有收件者自己知道，用來解密。

雖然很多人都看得到公鑰，但只有持有私鑰的收件者能解密。因為加解密用不同的鑰匙，所以叫非對稱式 (asymmetric)。

兩者的關鍵取捨

非對稱加密方便分發金鑰（公鑰隨便公開都沒關係），但它的運算成本通常是對稱式的 100 到 1000 倍！所以：

• 大量資料 → 用對稱式（快）。
• 安全地交換那把對稱金鑰 → 用非對稱式（方便）。

這就引出後面會講的混合協定 (hybrid protocol)：先用公鑰交換一把對稱金鑰，再用對稱式加密大量資料，兩者的優點都吃到。

STEP 2

生活妙喻

同一把鑰匙 vs 公開的投信口

兩種上鎖方式

對稱式＝共用一把保險箱鑰匙

你和好友各有一把一模一樣的鑰匙，可以開同一個保險箱。你把東西鎖進去 (加密)，朋友用相同鑰匙打開 (解密)。

• 優點：開鎖很快。
• 麻煩：你要怎麼安全地把這把鑰匙交給朋友？這正是對稱式最頭痛的『金鑰分發』難題。

非對稱式＝公開的投信口 + 私人開箱鑰匙

想像 Bob 在門口裝了一個投信口 (公鑰)：任何人都能把信投進去（用公鑰加密），但只有 Bob 手上那把開箱鑰匙 (私鑰) 能把信取出來看。

• 優點：投信口可以公告周知，誰都能寄密信給 Bob，不必事先交換秘密。
• 代價：這種『投信口機關』做工複雜，開關一次很費力（運算貴上百倍）。

聰明的混合做法

所以真實系統這樣做：

用 Bob 公開的投信口 (公鑰)，先寄一把共用保險箱鑰匙 (對稱金鑰) 給他；之後兩人就用這把又快又便宜的保險箱鑰匙來回傳大量資料。

用慢但方便的投信口解決『怎麼安全交鑰匙』，再用快的保險箱處理大量內容——這就是 TLS、HTTPS 背後的核心思路。

STEP 3

實用超能力

看懂為什麼 HTTPS 要混用兩種加密

為什麼不全用非對稱就好

既然非對稱式不用交換秘密、這麼方便，為什麼不全程用它？答案是效能：它比對稱式慢 100 到 1000 倍。一個網頁可能上百 KB，全用非對稱加密會慢到無法接受。所以實務上的分工是：

工作	用哪種	原因
安全交換那把對稱金鑰	非對稱	方便、不必事先共享秘密
加密實際的大量資料	對稱	快、成本低

混合協定流程

flowchart TD
  A[Alice 取得 Bob 的公鑰] --> B[Alice 產生一把對稱金鑰 KAB]
  B --> C[用 Bob 公鑰加密 KAB 傳給 Bob]
  C --> D[Bob 用私鑰解出 KAB]
  D --> E[雙方改用 KAB 對稱加密大量資料]

動手判斷

下次看到任何加密系統，問兩個問題就能看穿它的設計：

1. 大量資料是用哪種加密？ 幾乎一定是對稱式（為了速度）。
2. 那把對稱金鑰是怎麼安全送到對方手上的？ 答案常是『用對方的公鑰加密後送過去』。

理解這個分工，你就抓到了現代安全通訊（TLS/HTTPS）的骨架。

STEP 1

深度探秘

解密成功，就等於認證

密碼學的前兩個用途

密碼學在安全系統裡扮演三個主要角色，這一節先看前兩個：保密與完整、以及認證。

保密與完整

用一把金鑰加密的訊息，只有知道對應解密金鑰的人能解開。只要解密金鑰不外洩、演算法夠強，訊息就能保密。若再附上一個檢查碼 (checksum) 之類的冗餘資訊並加以檢查，就也能維護完整性（內容沒被竄改）。

但用共享金鑰做保密，會冒出兩個問題：

• 問題 1：Alice 要怎麼安全地把共享金鑰 KAB 送給 Bob？
• 問題 2：Bob 怎麼知道收到的訊息不是 Mallory 早先攔截、稍後重放的舊訊息？（重放不需要金鑰！）

認證：解密成功＝身分證明

這是個關鍵洞見：如果一把金鑰只有兩方知道，那麼一則訊息能被某把金鑰成功解密（且含正確檢查碼），就能推論發送者擁有對應的金鑰，於是推斷出發送者的身分。

換句話說：成功解密，就認證了訊息來自特定的發送者。

工作階段金鑰。">票證與挑戰

課本用一個認證伺服器 Sara 的場景說明。Sara 安全地保管所有人的秘密金鑰（由密碼推導而來）。它會發票證 (ticket)：一個加密過的憑據，裡面裝著主體的身分和一把為這次通訊新產生的工作階段金鑰 (session key)。

最巧妙的是挑戰 (challenge) 的概念：Sara 把回應用 Alice 的金鑰 KA 加密。這就是一個挑戰——Alice 只有能算出 KA（從她的密碼推導）才解得開。冒名者解不開，當場被擋下。重點是：Alice 的密碼根本不必傳上網路！

STEP 2

生活妙喻

只有你能打開的上鎖盒子

用上鎖盒子理解認證與挑戰

解密成功＝認證

假設世界上只有你和我有一把相同的鎖。今天我收到一個用這把鎖鎖住的盒子，而我能打開它——我就可以合理推論：這盒子一定是你鎖的，因為除了你沒有別人有這把鎖。這就是『成功解密＝認證身分』的精髓。

票證＝活動專用手環

想像你去音樂節，售票處 (Sara) 給你一個手環 (ticket)：上面寫著你的身分和一組『今晚專用通行碼 (session key)』。你戴著它去找各攤位 (Bob)，攤位驗過手環就知道你是誰、該用哪組通行碼跟你互動。

挑戰＝只有真本人解得開的謎題

最聰明的是：售票處不是直接問你『密碼是多少』（那樣密碼就會在空氣中被偷聽），而是把手環鎖進一個只有你密碼能打開的盒子裡交給你。

• 真的你：用密碼打開盒子，拿到手環，開心入場。
• 冒名者：拿到盒子卻打不開，當場破功。

妙處：你的密碼從頭到尾沒說出口，只是被你『用來開盒子』，所以偷聽的人什麼都偷不到。

STEP 3

實用超能力

看懂登入系統為何不直接傳密碼

為什麼好的登入系統不把密碼丟上網

菜鳥設計會這樣做：『使用者輸入密碼 → 把密碼送到伺服器比對』。問題是密碼在網路上跑，可能被竊聽。

挑戰機制提供更聰明的做法：伺服器丟出一個『只有真本人 (知道密碼) 才能正確處理』的挑戰，使用者在本機用密碼處理它、回傳結果。密碼本身從不離開使用者的電腦。

flowchart TD
  A[Alice 向 Sara 表明身分並請求票證] --> B[Sara 用 Alice 金鑰 KA 加密回應]
  B --> C[回應內含票證與工作階段金鑰 KAB]
  C --> D[Alice 用密碼推導出 KA 解開回應]
  D --> E[冒名者沒有正確密碼便解不開 當場被擋]

對應現實技術

觀念	真實世界
票證 (ticket)	Kerberos 的 ticket、登入後的 session token
工作階段金鑰	一次連線專用的臨時金鑰
挑戰 (challenge)	challenge-response 登入、密碼不上網

別忘了那兩個未解問題

單靠共享金鑰加密，還沒解決『金鑰怎麼安全分發』和『怎麼防重放』。前者靠公鑰密碼學（下一節），後者靠 nonce 或時戳（案例研究會看到 Kerberos 的做法）。看登入流程時，特別留意它怎麼防止舊訊息被重放。

STEP 1

深度探秘

把只有你知道的秘密綁到文件上

數位簽章要做什麼

數位簽章 (digital signature) 模擬傳統親筆簽名的角色：向第三方證明一份文件確實出自簽署者、且未被竄改。一個好的簽名要滿足三件事：

• 真實 (Authentic)：讓收件者相信簽署者是刻意簽了這份文件，且內容沒被別人改過。
• 不可偽造 (Unforgeable)：證明是簽署者本人簽的，簽名不能被複製到另一份文件上。
• 不可否認 (Non-repudiable)：簽署者事後無法可信地否認自己簽過。

數位簽章的技術核心是：把只有簽署者知道的秘密，不可逆地綁定到文件上。

摘要：文件的指紋

直接加密整份文件當簽名太貴。更好的做法是先壓出一個摘要 (digest)——一個固定長度的值，由安全摘要函式 (secure digest function) 算出。它類似檢查碼，但有個關鍵性質：

極不可能讓兩份不同的文件得出相同的摘要值。

摘要又叫安全雜湊 (secure hash)，記為 H(M)。

公鑰簽章的步驟

通常用公鑰密碼學來做：簽署者用私鑰產生簽章，任何收件者用對應的公鑰驗證。注意方向和加密剛好相反——加密是用收件者的公鑰，簽章是用簽署者的私鑰。

以 Alice 簽、Bob 驗為例：

1. Alice 算出文件摘要 H(M)。
2. Alice 用私鑰加密摘要，產生簽章 S = {H(M)}KApriv，附在 M 後面。
3. Bob 收到後，自己算一次 H(M)。
4. Bob 用 Alice 的公鑰解開 S，得到原摘要，和自己算的比對。相符就代表簽章有效。

還有一個前提：驗證者要確定那把公鑰真的是簽署者的——這由公鑰憑證解決（下一節）。

STEP 2

生活妙喻

蠟封印章與文件指紋

用蠟封印章理解數位簽章

古時候重要信件會用蠟封印章：把熱蠟滴在信封上，用只有你有的私章壓出花紋。

• 只有你有那枚私章 (私鑰) → 別人偽造不出來（不可偽造）。
• 印章花紋跟這封信綁在一起 → 換一封信印章就對不上（真實）。
• 你壓了就賴不掉 → 大家都認得你的印章（不可否認）。

別人驗證時，拿你公開展示過的印章樣本 (公鑰) 比對信上的花紋。

摘要＝文件的指紋

但如果文件很長，把整份都『加印』太費事。聰明的做法：先幫文件採一枚指紋 (摘要)——不管文件多長，指紋都是固定短短一串。

• 同一份文件 → 永遠同一枚指紋。
• 改動一個字 → 指紋就完全不同。
• 幾乎不可能找到兩份不同文件有相同指紋。

然後你只要對這枚指紋蓋章 (用私鑰加密摘要) 就好，又快又安全。

驗證流程

收件者怎麼確認沒被掉包？

1. 自己幫收到的文件重採一次指紋。
2. 用你的公開印章樣本，解開你蓋章的那枚指紋。
3. 兩枚指紋一樣 → 文件是你簽的、而且一字未改。

體會：只要文件被改過哪怕一個字，重採的指紋就對不上，掉包立刻現形。

STEP 3

實用超能力

分清楚加密與簽章的金鑰用法

最容易搞混的一點：金鑰方向相反

很多初學者會把『加密』和『簽章』的金鑰用法搞混。記住這張表就不會錯：

目的	用誰的什麼金鑰	誰能還原
保密傳訊 (加密)	收件者的公鑰加密	只有收件者用私鑰解
數位簽章	簽署者的私鑰加密摘要	任何人用簽署者公鑰驗

直覺記法：

• 加密是『只想讓某一個人看懂』→ 用那個人的公鑰鎖，只有他私鑰能開。
• 簽章是『想讓所有人都驗得出是我簽的』→ 用我的私鑰簽，全世界用我公鑰驗。

簽章驗證流程

flowchart TD
  A[Alice 算文件摘要 HM] --> B[用私鑰加密摘要產生簽章 S]
  B --> C[把 M 與 S 一起送給 Bob]
  C --> D[Bob 自己算一次摘要 HM]
  D --> E[Bob 用 Alice 公鑰解開 S 得到原摘要]
  E --> F[兩個摘要相符則簽章有效]

動手判斷

看到任何用到金鑰的安全動作，先問：『目的是保密還是證明來源？』

• 保密 → 該用收件者公鑰。
• 證明來源 (簽章) → 該用簽署者私鑰。

搞懂這個方向，你就不會再把 PGP、JWT、程式碼簽章這些東西的金鑰用反了。

STEP 1

深度探秘

被簽過名的一句聲明

憑證是什麼

數位憑證 (digital certificate) 就是一份被某主體簽過名的聲明（通常很短）。最重要的一種是公鑰憑證 (public-key certificate)：它把一把公鑰綁定到一個名字上，並由一個受信任的權威簽名。

課本用 Bob 是一家銀行的場景說明。客戶要確認自己面對的真的是『Bob 銀行』。問題來了：客戶 Carol 要驗證 Bob 的簽名，就需要 Bob 的公鑰，而且要確定這把公鑰是真的——否則 Alice 大可自己生一對假金鑰，偽造一張冒充 Bob 銀行的憑證。

信任鏈：遞迴的問題

Carol 需要的，是一張載明 Bob 公鑰、且由一個眾所周知且受信任的權威簽名的憑證。假設 Fred 代表銀行公會，負責替各銀行的公鑰背書，他就能替 Bob 發一張公鑰憑證。

但這張憑證又依賴 Fred 的公鑰是真的……於是我們陷入遞迴的真實性問題！這條鏈要怎麼收尾？

解法：必須有一個可信的起點——Carol 透過某種她有信心的管道（例如 Fred 的代表親手交給她，或她信任的人轉交）取得 Fred 的真實公鑰。

這就形成一條憑證鏈 (certification chain)。鏈愈長，出現薄弱環節的風險愈大；信任也很少是絕對的，選哪個權威當起點，要看憑證的用途。

撤銷的難題

有時需要撤銷 (revoke) 憑證——例如 Alice 退出了某社團，但她和別人手上可能還留著舊憑證。要追回並刪除所有副本幾乎不可能，通知所有可能的收件者也很麻煩。

常見解法：在憑證裡放一個到期日 (expiry date)。收到過期憑證就拒收，當事人需重新申請更新。若需要更快撤銷，才動用那些較笨重的機制。

STEP 2

生活妙喻

公證與推薦信的連鎖

用推薦信理解憑證鏈

想像你要和一個陌生人 Bob 做生意，但你不認識他。怎麼確認他真的是『Bob 銀行的人』？

• Bob 拿出一封推薦信 (憑證)：『此人是 Bob 銀行，由銀行公會 Fred 背書』，下面有 Fred 的簽名。
• 但你怎麼知道 Fred 的簽名是真的？你需要認得 Fred 的筆跡 (Fred 的公鑰)。
• 你怎麼確定那真是 Fred 的筆跡？也許是你信任的朋友親手把 Fred 的簽名樣本交給你的……

這就是信任鏈：一封信背書另一封信，一路往上，直到你親自信任的某個起點。

鏈愈長愈危險

就像『朋友的朋友的朋友說他可靠』——傳的人愈多，中間有人不可靠的風險就愈大。所以憑證鏈愈長，薄弱環節愈多。

到期日：最省事的撤銷

假設你不再是某俱樂部會員，但你的會員卡還在你皮夾、甚至在別人手上影印了一份。俱樂部要一張張追回不可能。最簡單的做法是：會員卡印上有效期限。

• 過期了？守門員一律不認，請你重新辦卡。

體會：與其費力『收回』所有舊憑證，不如一開始就讓它們『自動過期』，這就是到期日的智慧。

STEP 3

實用超能力

看懂瀏覽器網址列那把鎖

你每天都在用憑證鏈

當你打開一個 https 網站，瀏覽器就在背後驗證一條憑證鏈：

flowchart TD
  R[根憑證權威 內建於瀏覽器 可信起點] --> I[中介憑證權威]
  I --> S[網站的公鑰憑證]
  S --> B[瀏覽器驗證整條鏈通過才顯示安全鎖頭]

• 可信起點＝瀏覽器/作業系統內建的『根憑證 (root CA)』，相當於 Carol 親手拿到的 Fred 公鑰。
• 一層層往下驗，直到網站自己的憑證。任何一環驗不過，瀏覽器就跳警告。

看穿真實機制

課本觀念	真實世界
受信任權威	憑證權威 CA，如 Verisign
可信起點	內建的根憑證
憑證鏈	root → intermediate → 網站憑證
到期日	憑證的有效期間 (Not Before / Not After)
撤銷	CRL 撤銷清單 / OCSP

動手體會

下次看到網址列的鎖頭，點開『憑證』，你會看到一條鏈：最上面是根、中間是中介、最下面是這個網站。你親眼看到的，正是課本講的『一路往上到可信起點』。也別忘了憑證有到期日——這就是為什麼網站管理員每隔一段時間要更新憑證。

STEP 1

深度探秘

誰能對什麼資源做什麼

存取控制要回答的問題

認證解決了『你是誰』，存取控制 (access control) 接著解決『你能對這個資源做什麼』。伺服器收到形如 <op, principal, resource> 的請求（操作、主體、資源），會先認證請求與主體的憑據，再套用存取控制：拒絕任何主體沒有足夠權限的操作。

保護領域

保護領域 (protection domain) 是一個抽象：它是一組 <資源, 權限> 配對，列出某執行環境裡的處理程序能存取哪些資源、能做哪些操作。通常一個保護領域對應一個主體——使用者登入、身分被認證後，系統就為他要跑的程式建立一個保護領域，裡面包含他擁有的全部存取權（含透過群組取得的）。例如 UNIX 用使用者與群組 ID 決定處理程序的保護領域。

保護領域只是抽象，分散式系統常用兩種實作：

能力 (Capabilities)

能力是一個不可偽造的二進位值，像一把存取鑰匙，讓持有者能對特定資源做特定操作。它通常包含：資源識別碼、允許的操作清單、以及一個讓它不可偽造的認證碼 (數位簽章)。請求形如 <op, userid, capability>。最大優點是自帶權限——伺服器只要驗證能力本身即可，就像實體鑰匙一樣。但它也有實體鑰匙的兩個毛病：

• 遭竊：誰拿到鑰匙誰就能用，不管是不是合法持有者。
• 難撤銷：持有者狀態改變了 (例如離職)，卻可能還留著鑰匙繼續用。

存取控制清單 (ACL)

ACL 反過來：每個資源旁存一份清單，每筆是 <領域, 操作>，列出哪些領域能對它做哪些操作。請求形如 <op, principal, resource>，伺服器認證主體後，到該資源的 ACL 裡查主體有沒有這項操作的權限。UNIX、Windows NT 檔案系統的權限位元就是這種做法。

STEP 2

生活妙喻

門禁卡 vs 門口的訪客名單

兩種進門方式

要控制誰能進一棟大樓的各個房間，有兩種截然不同的做法，正好對應能力與 ACL。

能力＝你手上的門禁卡

你被發了一張門禁卡 (capability)，卡片本身就記載著你能開哪些門。走到門口，門鎖只要驗『這張卡有沒有開這扇門的權限』就放行——不需要去查你是誰。

• 優點：很快，門鎖不必維護一大本名單。
• 麻煩：
  • 遭竊：卡片掉了被人撿走，撿到的人就能進門。
  • 難撤銷：你離職了卻沒交回卡片，門鎖根本不知道，你還能進。

ACL＝門口貼的訪客名單

反過來，每扇門口貼一張名單 (ACL)：列出『誰能進、能做什麼』。你來了，警衛先確認你是誰，再到名單上查你有沒有資格。

• 優點：要取消某人權限，直接從名單劃掉就好（撤銷容易）。
• 代價：每次都要先認證你、再翻名單，比較費工。

一句話對比

	能力 (鑰匙在你手上)	ACL (名單在門口)
權限存在哪	持有者身上	資源旁邊
驗證方式	驗鑰匙本身	認證身分再查名單
撤銷	難	容易 (劃掉名字)
遭竊風險	高	較低

STEP 3

實用超能力

辨認你身邊的能力與 ACL

你天天在用這兩種機制

學會分辨能力與 ACL，你就能看穿各種授權系統的本質。判斷訣竅：權限資訊是『跟著持有者跑』，還是『存在資源那一端』？

真實例子	屬於	為什麼
演唱會門票、飯店房卡	能力	票/卡本身帶著權限，驗票就放行
雲端分享連結 (持連結即可看)	能力	連結就是鑰匙，誰拿到誰能看
UNIX 檔案的 rwx 權限	ACL	權限存在檔案旁，依使用者查
Google 文件指定某人可編輯	ACL	權限掛在文件上，依身分授權
OAuth access token / JWT	能力	token 自帶權限，難即時撤銷

看穿『難撤銷』的痛點

為什麼『持連結即可存取』的雲端分享、或 JWT，都有難以立即撤銷的老問題？因為它們本質是能力——權限跟著那串東西跑，一旦外流，系統很難馬上作廢它。這正是課本講的能力兩大缺點：遭竊與難撤銷。

動手判斷

下次遇到任何授權設計，先問：

1. 權限資訊在哪一端？ 在持有者手上（能力）還是資源旁（ACL）？
2. 要取消某人的權限容易嗎？ 若很難，多半是能力型，要特別設計時限或撤銷清單。

課本也提到，兩者可以搭配使用：用 ACL 做主控、再用能力快取結果以加速重複存取。

STEP 1

深度探秘

憑據如何代言一個主體

憑據是什麼

憑據 (credentials) 是主體在請求存取資源時提出的一組證據。最簡單的情況：一張載明身分的憑證就夠了，用它去查 ACL 裡的權限。但這個概念可以推廣，處理更細緻的需求。

代言 (speaks for)

每次操作都要使用者親自互動、重新認證太麻煩。於是引入一個關鍵概念：憑據『代言 (speaks for)』一個主體。例如使用者的公鑰憑證代言該使用者——任何收到以該使用者私鑰認證之請求的處理程序，都可以認定請求是該使用者發出的。

『代言』可以延伸得很遠：

• 雙人核可：某些敏感動作要求兩位團隊成員的授權，請求者就同時提交自己的憑據和另一位成員的背書憑據，註明兩者要合起來檢查。
• 投票：投票請求要附上『選民憑證』加『身分憑證』。
• 一般而言，存取控制檢查＝對所提交憑證組合出的邏輯式求值。

角色式憑據

角色式憑據 (role-based credentials) 在實務上特別好用：先為組織或協作任務定義一組角色，把應用層的存取權綁到角色上；再透過發角色憑證把角色指派給特定主體。這樣權限管理就從『管每個人』變成『管角色』，乾淨許多。

委派

委派 (delegation) 是一種特別有用的憑據：它讓一個主體（或代表主體的處理程序）能以另一個主體的權限去執行動作。經典例子是列印伺服器：把要印的檔名交給它，它代你去讀取檔案。如果檔案是讀取保護的，除非列印伺服器能暫時取得讀取權，否則印不出來。

委派可用委派憑證（由請求者簽名、授權另一主體存取指定資源）或能力達成。委派時通常會把權限限縮成原本的子集、並加時限，避免被委派者濫用——例如限制列印伺服器的權限只在短時間內有效，降低它日後被入侵而洩漏檔案的風險。

STEP 2

生活妙喻

代辦、職位章與授權書

用日常授權理解這三個概念

代言＝出示證件就代表你

你不可能每辦一件事就被警察重新查一次身分。你的身分證 (憑據) 會『代言』你——出示它，對方就認定是你本人在辦事。這正是『憑據代言主體』。

雙人核可就像公司大額支票要兩位主管共同簽名：一個人的章不夠，兩張背書合起來才算數。

角色式憑據＝職位而非個人

公司不會說『這份報表只有王小明能看』，而是說『會計才能看』。誰被指派為會計（拿到角色憑證），誰就有這個權限。

• 好處：王小明調職了，只要收回他的會計角色，不必去改一大堆『王小明能不能看 A、能不能看 B』的設定。

委派＝給代辦人一張限定授權書

你請人代你去銀行辦一件事，會給他一張授權書 (委派憑證)：

• 只授權這一件事（限縮成子集）——不會把你整個帳戶的權限都給他。
• 只在某段時間有效（加時限）——辦完就失效。

這跟『列印伺服器代你讀檔案』一模一樣：給它剛好夠用的權限、短時間有效，就算它之後被入侵，損害也有限。

STEP 3

實用超能力

用角色與最小委派設計乾淨的權限

為什麼現代系統都用角色

直接『每個人對每個資源逐一設權限』會爆炸：100 人 × 50 個資源就是 5000 條規則，人員異動就要逐條改。角色式存取控制 (RBAC) 把它拆成兩段，乾淨太多：

flowchart TD
  P[主體 使用者] --> R[角色 如會計 主管]
  R --> Q[權限 對哪些資源能做什麼]
  P2[新進員工] --> R
  P3[離職員工 收回角色] -.-> R

• 改一個角色的權限 → 所有該角色的人一次同步。
• 人員異動 → 只要指派或收回角色，不必動權限本身。

委派的黃金守則：最小權限 + 時限

當一個服務需要代客戶存取資源時，務必記住課本的兩條原則：

1. 限縮成子集：只給它完成這件事剛好夠用的權限，不要把客戶的全部權限都交出去。
2. 加上時限：權限只在短時間內有效，降低它日後被攻破時的損害。

對應現實技術

課本觀念	真實世界
代言 (speaks for)	session token、公鑰憑證代表使用者
角色式憑據	RBAC、IAM role
委派 + 限縮 + 時限	OAuth 的 scope 與短期 access token

下次設計『服務 A 要替使用者去呼叫服務 B』時，別把使用者的完整權限交出去——只給這次任務需要的最小範圍、並設短效期。

STEP 1

深度探秘

在邊界攔截所有外部通訊

防火牆做什麼

防火牆 (firewall) 保護內部網路 (intranet)，對進出的通訊執行過濾動作。它的核心做法是：

在組織網路邊界建立一個環境，攔截所有外部通訊；只有明確被授權的通訊，才會被轉送給內部的預期收件者。

為什麼需要它？在理想世界裡，通訊永遠發生在互信的處理程序之間、永遠走安全通道。但現實中做不到——很多伺服器沒有為抵抗惡意攻擊而設計，軟體也常有錯誤。任何人都能輕易對任何伺服器送請求，於是機密資訊容易從組織伺服器外洩，蠕蟲、病毒等也容易滲透進來。防火牆就是在邊界設一道關卡。

防火牆的限制

防火牆很有用，但課本明確指出它有不少限制，不能當成唯一防線：

• 防不了內部攻擊：防火牆只管『內 vs 外』。來自組織內部的攻擊，它完全使不上力。
• 控制粒度太粗：它對外部存取的控制很粗糙。對外公開的服務本來就要開放給廣大使用者，無法細到『讓個別使用者只與選定的對象分享資訊而不犧牲隱私與完整性』。因此仍需要更細粒度的端到端安全機制。
• 對 DoS 幾乎無效：面對阻斷服務洪水攻擊（例如 IP 偽造的洪水），防火牆這個單一防禦點會被流量淹沒。任何對付來襲洪水的補救，都必須在離目標更上游處施行——例如用服務品質機制把流入流量限制在目標能處理的水準。

課本也提到一種折衷：可以用結合防火牆的 web tunnel 機制（基於 HTTPS 的安全代理），讓受信任且通過認證的外部使用者安全存取內部 web 資料。

STEP 2

生活妙喻

社區大門的警衛

把防火牆想成社區大門的警衛

你的社區門口有個警衛 (防火牆)，負責攔下所有從外面來的人，只放行有登記、被授權的訪客進來。這很有用——擋掉了大部分閒雜人等。但警衛有幾個管不到的死角：

防不了內部攻擊

警衛只盯外面進來的人。如果社區裡面已經住著一個壞鄰居，他在社區裡搞破壞，警衛站在大門口根本看不到、管不著。這正是『防火牆防不了內部攻擊』。

控制粒度太粗

警衛只能判斷『這個人能不能進社區』，但管不到『進來後，他能不能進某一戶人家的客廳』。要保護到每一戶、每一個房間，還是得靠各家自己的門鎖（端到端的細粒度安全）。

對洪水無效

如果有上萬人同時擠到大門口故意造成堵塞（DoS 洪水），一個警衛根本擋不住——大門被人潮淹沒，連正當住戶都進不來。要解決，得在更上游（例如社區外的道路）就開始疏導車流人流，而不是指望門口那一個警衛。

體會：警衛 (防火牆) 是必要的第一道關卡，但它管不到內部、管不到每一戶細節、也擋不住人潮洪水——你還需要各家門鎖和上游的交通管制。

STEP 3

實用超能力

別把防火牆當成唯一的安全

一個常見的錯誤心態

『我們有防火牆，所以很安全』——這是危險的錯覺。防火牆只是邊界防線，它擋不住的東西，課本講得很清楚。要建構真正安全的系統，得搭配多層防護：

flowchart TD
  E[外部攻擊] --> FW[防火牆 邊界過濾]
  FW --> I[內部網路]
  INS[內部攻擊] --> I
  I --> R[資源]
  R --> ETE[端到端加密與存取控制 保護每個資源]

注意圖中的內部攻擊那條線——它繞過了防火牆，直接打進內部。這就是為什麼還需要端到端的加密與細粒度存取控制。

把限制變成設計檢查表

防火牆擋不住的	你還需要什麼
內部攻擊	內部也要認證、最小權限、零信任思維
細粒度存取	每個資源自己的存取控制與端到端加密
DoS 洪水	上游流量限制、服務品質機制、CDN/清洗
安全的外部存取	基於 HTTPS 的安全代理 (web tunnel)

動手判斷

下次有人說『我們加了防火牆就安全了』，你可以追問三件事：

1. 內部若有人作惡，防得住嗎？
2. 每個敏感資源自己有沒有存取控制與加密？
3. 遇到大流量 DoS，補救是放在邊界還是更上游？

這三題正好對應防火牆的三大限制，幫你揪出『假安全』。

STEP 1

深度探秘

好算難逆的數學魔法

加密的數學骨架

加密就是寄件者把明文 (plaintext) 用某規則轉成密文 (ciphertext)，收件者用反向規則還原。加密由兩部分定義：一個函式 E 和一把金鑰 K，把訊息 M 加密寫成 {M}K。對稱式加密，解密用的金鑰和加密相同。

單向函式：對稱加密的根基

如果我們把金鑰固定下來，定義 FK(M) = E(K, M)，那麼強加密函式有一個性質：FK 正向很好算，但它的逆函式 FK⁻¹ 難算到不可行。這種函式叫單向函式 (one-way function)。正是這個『好算難逆』的性質，保護我們對抗『拿到 {M}K 就想反推 M』的攻擊。

暴力破解與金鑰長度

對設計良好的對稱演算法，攻擊者就算同時握有明文 M 和對應密文，要找出金鑰 K 的最有效辦法竟是最笨的——暴力破解 (brute-force attack)：把所有可能的 K 一個個試，算出結果直到符合已知密文。

若 K 有 N 個位元，平均要試 2^(N-1) 次、最多 2^N 次。破解時間隨金鑰位元數呈指數成長。

這就是為什麼 56 位元的 DES 早已不安全，而 128 位元金鑰目前安全：每多一個位元，難度就翻倍。

陷門函式：非對稱加密的根基

公鑰系統用單向函式的另一種變化——陷門函式 (trap-door function)：它是一個帶秘密出口的單向函式，正向易算、逆向不可行，除非你知道那個秘密。

以 RSA 為例：取兩個極大的質數相乘只要幾秒（正向易算），但要從乘積反推回原本的兩個質因數 (因數分解) 卻幾乎不可能（逆向不可行）。那個『秘密出口』就是私鑰持有者掌握的資訊。所以 RSA 的安全不靠暴力破解的困難，而靠大數因數分解的困難。

STEP 2

生活妙喻

打碎的盤子與相乘的質數

單向函式＝打碎一個盤子

把盤子摔到地上碎掉 (正向) 超級簡單，但要把碎片完美拼回原狀 (逆向) 幾乎不可能。這就是單向函式『好算難逆』的精神——加密容易，沒金鑰想還原難如登天。

暴力破解＝試開密碼鎖

面對一個數字密碼鎖，最笨但最可靠的破法就是一個個號碼試過去。

• 3 位數的鎖：最多 1000 種組合，一下就試完。
• 多一位數 → 組合數乘以 10。

金鑰也一樣：每多一個位元，組合數就翻倍。所以 56 位元的鎖（DES）今天的電腦幾天就試完，128 位元的鎖則要試到天荒地老。長度每加一點，難度就指數爆炸——這就是金鑰要夠長的原因。

陷門函式＝相乘容易、拆開難

想像我給你兩個大質數，請你相乘：拿計算機按一按，幾秒就好（正向易算）。

但我反過來只給你那個乘積，請你找出『原本是哪兩個質數相乘的』——這叫因數分解。當數字大到上百位，就算動用全世界的電腦也算不出來（逆向不可行）。

那『秘密出口 (陷門)』是什麼？就是原本那兩個質數——知道它的人（私鑰持有者）輕鬆還原，不知道的人卡死。RSA 正是建在這個『乘起來容易、拆開來難』的不對稱上。

STEP 3

實用超能力

看懂金鑰長度與兩種安全來源

為什麼對稱與非對稱的『安全金鑰長度』差很多

常有人疑惑：『為什麼 AES 128 位元就夠，RSA 卻要 1024、2048 位元？』因為兩者的安全來源不同：

	對稱式 (如 AES)	非對稱式 (如 RSA)
安全來源	抵抗暴力試遍金鑰	抵抗大數因數分解
破解最佳法	暴力破解 (試 2^N 種)	因數分解 (有比暴力快的數學法)
安全金鑰長度	較短 (128 位元已很強)	較長 (要 1024 位元以上)

因為因數分解有比『純暴力』更聰明的數學方法，所以 RSA 的數字 N 必須做得遠大於對稱金鑰，才能讓分解一樣不可行。

安全強度的直覺

flowchart TD
  K[金鑰每多一個位元] --> D[暴力破解組合數翻倍]
  D --> T[破解時間指數成長]
  T --> S[足夠長就實務上不可破]

動手判斷

看到任何加密設定，可以這樣思考：

1. 這是對稱還是非對稱？ 對稱看『金鑰夠不夠長以抵抗暴力破解』；非對稱看『底層難題 (如因數分解) 夠不夠難』。
2. 金鑰太短嗎？ 像 56 位元 DES、40 位元金鑰，今天都算不安全——因為硬體進步讓暴力破解變可行。

記住一句話：對稱靠長度、非對稱靠難題，兩者的『安全』建在不同的數學基礎上。

STEP 1

深度探秘

一塊塊加密還是一位元位元加密

區塊加密

大多數加密演算法以固定大小的區塊 (block) 處理資料，64 位元是常見的區塊大小。訊息被切成一塊塊，最後一塊不足就補足 (padding)，每塊獨立加密。

但簡單的區塊加密有弱點：每塊密文不依賴前面的區塊，於是相同的明文塊會產生相同的密文塊。攻擊者就能認出重複樣式、推測它與明文的關係。為克服這個弱點，多數區塊加密採用密碼區塊鏈結 (Cipher Block Chaining, CBC)。

CBC 怎麼運作

CBC 模式下，每塊明文在加密前，先和前一塊密文做 XOR，再加密。解密時反過來：先解密、再和前一塊密文 XOR 還原。這行得通是因為 XOR 是自身的逆運算（做兩次就回到原值）。CBC 讓相同的明文片段不再加密成相同的密文。

但 CBC 在每段序列的開頭仍有弱點：如果對兩個目的地送出相同訊息，加密後的區塊序列會一樣，竊聽者可能得到有用資訊。解法是在每則訊息前插入一段不同的明文，稱為初始向量 (Initialization Vector, IV)——用時戳當 IV 是個好選擇，能逼每則訊息以不同的明文塊開頭。

注意：CBC 只適合在可靠連線上用。若有密文塊遺失，後續區塊就解不出來，因此不適合可容忍資料遺失的應用（那要用串流加密）。

串流加密

有些應用（如加密電話通話）的資料是即時、一小塊一小塊產生的，可能只有 8 位元甚至 1 位元，補成 64 位元再加密太浪費。串流加密 (stream cipher) 能逐位元地把明文轉成密文。

做法很巧妙：建一個金鑰流產生器 (keystream generator)，產生一段任意長度的位元序列 (金鑰流)，再把金鑰流和資料流逐位元 XOR。只要金鑰流是安全的，加密出的資料流也安全。這就像情報界用『白噪音』蓋住對話：分別錄下噪音與對話，事後相減就能還原乾淨對話。

混淆與擴散

好的加密演算法靠 Shannon 的兩大原則隱藏內容：

• 混淆 (Confusion)：用 XOR、循環位移等非破壞性運算，把明文和金鑰結合，打亂明文與密文之間的關係，讓基於字元頻率的分析失效。
• 擴散 (Diffusion)：明文裡常有重複與冗餘，擴散把每塊明文的部分移位、分散，把規律打散；搭配 CBC 還能把冗餘分散到更長的文字裡。串流加密因為沒有區塊，無法使用擴散。

STEP 2

生活妙喻

蓋章的連環扣與逐字遮蔽

簡單區塊加密的破綻

想像你用同一個印章把文件每一格蓋上花紋。問題是：內容相同的格子，蓋出來的花紋也一模一樣。別人雖看不懂花紋，卻能看出『這兩格內容相同』——這就洩漏了資訊。

CBC＝把每一格和前一格鎖在一起

CBC 的妙招是：蓋每一格之前，先把它和前一格已經蓋好的花紋疊在一起，再蓋。這樣一來，就算兩格原始內容相同，因為它們前面那格不同，蓋出來的花紋也會不同——重複樣式消失了。

那為什麼還需要初始向量 (IV)？因為第一格前面沒有東西可疊。如果兩份文件第一格內容相同、開頭就會一樣。解法：在最前面塞一段每次都不同的引子（例如當下的時戳），整串就從頭到尾都不一樣了。

串流加密＝白噪音蓋住對話

間諜片裡常見：談機密時放白噪音蓋住對話，讓竊聽者只聽到沙沙聲。但如果你另外單獨錄了一份白噪音，事後把『噪音+對話』減掉『純噪音』，乾淨對話就回來了。

串流加密就是這招的數位版：

• 白噪音＝金鑰流（雙方都能產生的同一串隨機位元）。
• 加密＝把明文和金鑰流逐位元 XOR（蓋上噪音）。
• 解密＝再 XOR 一次同樣的金鑰流（減掉噪音）。

因為它一位元一位元處理，特別適合即時的電話、語音這種小塊串流資料。

STEP 3

實用超能力

為不同情境挑對的加密模式

區塊 vs 串流：什麼時候用哪個

	區塊加密 + CBC	串流加密
處理單位	一塊塊 (如 64 位元)	一位元 / 一小塊
適合	可靠連線上的批次資料 (檔案、網頁)	即時小塊資料 (電話、語音)
怕什麼	密文塊遺失就解不出後續	金鑰流重複就會被破
能否用擴散	可以	不行 (沒有區塊)

兩個務必記住的設計重點

1. CBC 一定要配 IV：沒有 IV，相同開頭的訊息會洩漏資訊；IV 要每次都不同（時戳是常見選擇）。
2. 串流加密最怕金鑰流重複：同一段金鑰流絕不能拿來加密兩份不同資料——這正是下一章 WiFi WEP 慘敗的核心原因（IV 太短導致金鑰流數小時就重複）。

加密強度的兩大支柱

flowchart TD
  M[明文 含重複與規律] --> C[混淆 打亂明文與密文關係]
  M --> D[擴散 把規律移位分散]
  C --> S[密文 看不出原樣也難回推金鑰]
  D --> S

動手判斷

下次看到一個加密應用，問三題：

1. 資料是批次的還是即時串流？ → 決定用區塊還是串流。
2. 用 CBC 嗎？有沒有每次不同的 IV？
3. 若是串流，金鑰流會不會重複？ 這往往是真實系統最致命的破口。

STEP 1

深度探秘

好的指紋函式要滿足三個性質

安全摘要函式的三個性質

摘要函式 (又叫安全雜湊函式 secure hash function) 記為 h = H(M)，把任意長度的訊息壓成固定長度的指紋。一個安全的摘要函式要滿足三個性質：

1. 給定 M，容易算出 h。
2. 給定 h，難以反推出 M（單向）。
3. 給定 M，難以找到另一個 M'，使 H(M) = H(M')（抗碰撞）。

第 3 個性質最關鍵：我們知道摘要一定會有碰撞（因為它是把資訊壓縮），但必須確保攻擊者無法針對某個 M 找出另一個產生相同 h 的 M'。否則他就能把 M 的合法簽章，移花接木到偽造的 M' 上——不需要簽署金鑰就偽造了簽名文件。這種函式也叫單向雜湊函式。

MAC：用共享秘密做低成本簽章

當一個安全通道用來傳未加密訊息、但需要驗證真實性時，可以用共享秘密金鑰做出低成本的簽章，稱為訊息認證碼 (Message Authentication Code, MAC)：

1. A 產生一把隨機金鑰 K，透過安全通道分發給需要驗證 A 訊息的人（這些人被信任不洩漏 K）。
2. 對任何要簽的文件 M，A 把 M 和 K 串接、算出摘要 h = H(M + K)，把 (M, h) 送出。h 就是 MAC。因為雜湊已徹底遮蔽 K，公開 h 不會洩漏 K。
3. 接收者 B 把自己的 K 和收到的 M 串接、算出 h' = H(M + K)，若 h' = h 即驗證通過。

MAC 的優點：完全不用加密，所以快（安全雜湊通常比對稱加密快 3 到 10 倍）。缺點是需要先安全分發共享金鑰。TLS 支援多種 MAC。

生日攻擊

摘要長度為什麼至少要 128 位元？因為生日攻擊 (birthday attack)。它利用『生日悖論』：一群人裡找到『任兩人生日相同』的機率，遠高於找到『某人和特定某天同生日』。

攻擊手法：Alice 準備一份對 Bob 有利的合約 M 和一份不利的 M'，各自做出許多『視覺上難以分辨』的版本（例如在行尾加空格），比對兩堆的雜湊，直到找到一對相同。她讓 Bob 簽有利的 M，再把簽章移植到不利的 M' 上。若雜湊只有 64 位元，平均只要約 2^32 個版本就能配出一對——太少了。所以摘要至少要 128 位元（如 SHA-1 用 160 位元，更安全）。

STEP 2

生活妙喻

指紋、共享暗號與同班同生日

安全摘要＝可靠的指紋鑑定

一枚好的指紋鑑定要做到：

• 採指紋很容易（給人就能採）→ 性質 1。
• 光看指紋猜不出長相（不能反推本人）→ 性質 2。
• 幾乎不可能找到另一個人指紋一模一樣（抗碰撞）→ 性質 3。

如果『抗碰撞』失守——竟然找得到另一個人指紋跟你完全相同——那壞人就能拿你簽過名的文件，把指紋一樣的偽造文件偷天換日。

MAC＝兩人之間的共享暗號

你和朋友約定一個只有你倆知道的暗號 (共享金鑰 K)。你寄明信片 (未加密的 M) 時，在角落寫上『內容 + 暗號一起算出來的一串記號 (MAC)』。

• 朋友收到，用同樣的暗號重算一遍，記號對得上 → 確認是你寄的、沒被改過。
• 路人看得到明信片內容，但算不出那串記號（因為不知道暗號），也無法從記號反推暗號。
• 好處：你只是『算一串記號』，沒有加密，所以又快又省事。

生日攻擊＝同班同生日

你以為『班上有人和我同一天生日』很難？其實只要 23 個人，班上任兩人同生日的機率就過半了！『任兩人』比『跟我同天』容易太多。

壞人正是利用這點：他不必找『跟某份文件雜湊相同』的文件，而是大量製造兩堆只差空格的版本，去湊『任兩份雜湊相同』——這比你想的容易得多。對策很簡單：把指紋做長一點（至少 128 位元），讓可能的指紋多到湊不出碰撞。

STEP 3

實用超能力

選對雜湊、看懂 MAC 與簽章的差別

MAC vs 數位簽章：別搞混

兩者都能驗證『訊息沒被改、來自預期對象』，但機制與適用情境不同：

	MAC	數位簽章 (公鑰)
用什麼金鑰	共享的對稱秘密 K	簽署者私鑰簽、公鑰驗
速度	快 (純雜湊、不加密)	較慢
不可否認	否 (雙方都有 K，誰都能產生)	是 (只有簽署者有私鑰)
適合	已建立安全通道的雙方驗真	對第三方證明來源

關鍵差別：MAC 無法提供不可否認，因為雙方共享同一把 K，B 也能偽造一個看似 A 簽的 MAC；要對第三方證明『就是 A 簽的』，得用公鑰簽章。

雜湊長度的實務判斷

flowchart TD
  S[摘要長度太短 如 64 位元] --> B[生日攻擊只需約 2 的 32 次方個版本]
  B --> F[攻擊者湊出碰撞 移植簽章偽造文件]
  L[摘要至少 128 位元] --> P[碰撞數量大到實務上湊不出]

• MD5：128 位元（已被發現弱點，新系統避免用）。
• SHA-1：160 位元（後來也被指出脆弱，NIST 建議改用更長的 SHA 版本）。
• 課本結論：摘要至少 128 位元才擋得住生日攻擊，越長越安全但成本越高。

動手判斷

設計或檢視系統時：

1. 需要對第三方證明來源 (不可否認)？ → 用數位簽章，別只用 MAC。
2. 只是已連線的兩方互相驗真、又要快？ → MAC 很划算。
3. 雜湊夠長嗎？ → 至少 128 位元，老舊的短雜湊要警惕生日攻擊。

STEP 1

深度探秘

用認證伺服器與票證發放金鑰

Needham–Schroeder 協定

1978 年 Needham 和 Schroeder 提出的認證協定，是許多安全技術的核心。它的目標是：在網路上安全地讓兩個處理程序取得一把共享金鑰。靠的是一個認證伺服器 S，它保管每個主體的秘密金鑰。

它引入一個關鍵元件——nonce：一個只用一次的整數，加進訊息裡用來證明訊息是新鮮的（不是被重放的舊訊息）。流程簡述（A 想和 B 安全通訊）：

1. A → S：A、B、N_A（A 請 S 給一把和 B 通訊用的金鑰，附上 nonce N_A）。
2. S → A：用 A 的金鑰加密的回應，內含新金鑰 K_AB 和一張用 B 金鑰加密的票證。nonce N_A 證明這是針對上一則的回應；只有 S 知道 A 的金鑰，所以 A 相信是 S 發的。
3. A → B：A 把票證 {K_AB, A}K_B 轉給 B。
4. B → A：B 解開票證、用新金鑰 K_AB 加密另一個 nonce N_B 送回。
5. A → B：A 回傳 N_B 的約定變換（如 N_B − 1），向 B 證明自己就是上一則的發送者。

一個著名的弱點

這個協定有個破綻：B 沒有理由相信訊息 3 是新鮮的。若攻擊者設法取得舊的 K_AB 和票證（例如被粗心的程式遺留在暴露的儲存空間），就能用它們重啟與 B 的交談、冒充 A。修補方法：在訊息 3 加上 nonce 或時戳，讓 B 能檢查它是否新近——這正是 Kerberos 採用的解法。

Kerberos

Kerberos 由 MIT 開發，緊密遵循 Needham–Schroeder，並用時戳當 nonce，達成兩個目的：防重放、並給票證一個有效期限 (lifetime) 以便撤銷權限。它處理三種安全物件：

• 票證 (Ticket)：發給客戶、向特定伺服器出示的權杖，含到期時間和新的工作階段金鑰。
• 認證符 (Authenticator)：客戶建立、用來證明身分與通訊新鮮度，含客戶名與時戳，用工作階段金鑰加密，只能用一次。
• 工作階段金鑰 (Session key)：Kerberos 隨機產生、發給客戶與特定伺服器通訊用。

Kerberos 伺服器叫 KDC (Key Distribution Centre)，提供兩種服務：AS (Authentication Service) 在登入時認證使用者、發給一張票證授予票證 (TGT)；之後客戶用 TGT 向 TGS (Ticket-Granting Service) 取得存取各個伺服器的票證，不必每次重輸密碼。

STEP 2

生活妙喻

遊樂園的售票亭與通行手環

把 Kerberos 想成一座大型遊樂園

遊樂園 (KDC) 有兩個櫃台和很多遊樂設施 (各伺服器)：

入口售票亭＝AS (認證服務)

你一進園 (登入)，先到入口售票亭 (AS) 出示證件。它確認你是誰後，給你一條萬用手環 (TGT，票證授予票證)。重點是：之後你逛整個園區，不必再掏證件——手環就是你的身分證明。

設施換票處＝TGS (票證授予服務)

想玩雲霄飛車？你拿萬用手環去換票處 (TGS)，它驗過手環後，給你一張這項設施專用的票 (server ticket) 和一組專用通行碼 (session key)。想玩別的設施，再來換一張就好。

nonce / 時戳＝防止舊票被重用

每張票和你每次出示的認證符上，都印著時間戳記。

• 設施驗票時會看：『這張票還在有效期內嗎？這個認證符是剛剛產生的、還是有人撿了舊的來重放？』
• 認證符只能用一次，就像一次性的入場條碼，掃過就作廢。

為什麼這樣設計很聰明

• 密碼只在入口用一次：手環一拿到，你的密碼就從記憶體抹掉，整天逛園都不再暴露密碼。
• 手環有期限：通常十幾小時，逛完一天剛好；若你被取消資格，過期後手環自動失效。

STEP 3

實用超能力

看懂企業單一登入的骨架

Kerberos 就在你身邊

Kerberos 是 Windows 網域、許多企業內網的預設認證服務，也是『單一登入 (SSO)』的經典骨架。理解它，你就懂了『為什麼登入一次就能用一整天、存取很多服務』。

flowchart TD
  U[使用者登入] --> AS[AS 認證服務 驗證身分]
  AS --> TGT[發給票證授予票證 TGT 與工作階段金鑰]
  TGT --> TGS[拿 TGT 向 TGS 請求某服務的票]
  TGS --> ST[發給該服務專用票與工作階段金鑰]
  ST --> SRV[向伺服器出示票與認證符 取得服務]

三種物件的角色對照

物件	作用	類比
票證 (Ticket)	向特定伺服器證明已被認證，含到期時間	設施專用票
認證符 (Authenticator)	證明身分與新鮮度，只用一次	一次性入場條碼
工作階段金鑰 (Session key)	雙方該次通訊加密用	設施專用通行碼

設計啟示

1. nonce / 時戳是防重放的命脈：Needham–Schroeder 的弱點正是訊息 3 缺新鮮度標記；任何認證協定都要問『舊訊息能不能被重放？』
2. 票證有期限是雙刃：期限長＝方便但難即時撤銷；期限短＝安全但可能打斷使用者。Kerberos 取十幾小時的折衷。
3. 密碼只在登入用一次：之後靠票證，密碼不再上網——這是好登入系統的共同特徵。

STEP 1

深度探秘

可協商、自我啟動的安全通道

TLS 是什麼

SSL 由 Netscape 開發，其延伸版被採納為 Internet 標準，名為 TLS (Transport Layer Security)。當你在網址用 https:，就會在瀏覽器與伺服器之間建立一條 TLS 安全通道。TLS 是電子交易的事實標準。它有幾個關鍵特性：

演算法可協商

在開放網路上，不能假設大家用相同軟體或都支援某個加密演算法（有些國家還限制特定演算法）。所以 TLS 把加密與認證的演算法設計成在初始握手時協商。雙方支援的演算法集合稱為 cipher suite；伺服器列出它有的選項，客戶挑一個。若找不到共同的演算法，連線就失敗。

自我啟動的安全通訊

TLS 不需事先協商或第三方幫忙就能建立安全通道：先用未加密通訊做初始交換，接著用公鑰密碼學，最後在建立共享秘密金鑰後改用對稱式——這正是前面學過的混合協定！每次切換都是可選的、且先經協商。所以通道是完全可設定的：可選擇是否加密、是否認證每個方向，不浪費運算資源在不必要的加密上。

兩層架構

TLS 由兩層組成：

• 握手協定 (Handshake Protocol)：在現有連線上、以明文開始，協商選項與參數，建立 TLS 工作階段。
• 紀錄協定 (Record Protocol)：實作安全通道本身，對通過的訊息加密與認證，提供保密、完整、真實——正是安全通道的三大性質。

握手流程要點

1. 協商版本、工作階段 ID、cipher suite、壓縮方法，交換隨機值。
2. (可選) 雙方交換 X.509 格式的公鑰憑證互相認證。
3. 一方產生一個 pre-master secret（大隨機值），用對方公鑰加密後送出。雙方據此導出兩把對稱工作階段金鑰（每個方向各一）與訊息認證秘密。
4. 互換 ChangeCipherSpec 與 Finished 訊息後，之後所有通訊都依協商的 cipher suite 加密與簽署。

防中間人：初始握手可能受中間人攻擊，故驗證第一張憑證的公鑰可經另一管道取得（例如瀏覽器內建知名憑證權威的公鑰）。

STEP 2

生活妙喻

兩位談判代表先對暗號再密談

把 TLS 握手想成兩位代表碰面密談

兩位互不相識的談判代表，要在一個可能有人偷聽的房間談機密。他們會怎麼做？這正是 TLS 握手：

先公開地『對規則』(可協商)

他們先大聲地（明文）確認：『我們都會說中文和英文嗎？用哪種？』『用哪套暗號規則？』——這就是協商 cipher suite。如果連一種共同語言都沒有，談判就告吹（連線失敗）。

互相驗明正身 (憑證)

各自出示由公會背書的名片 (X.509 憑證)，確認對面真的是對方本人，不是冒牌貨。

用公開信箱傳一把共用鑰匙 (pre-master secret)

其中一位產生一把只有兩人會用的密談鑰匙 (pre-master secret)，用對方的公開投信口 (公鑰) 安全地傳過去。從此兩人就用這把又快又便宜的共用鑰匙密談（對稱加密）。

換暗號、確認、開始 (ChangeCipherSpec / Finished)

兩人說好『從現在起，全部用密語』，互相確認無誤，正式進入加密密談。

為什麼要『先公鑰、後對稱』

• 公鑰像公開信箱：方便傳第一把鑰匙給陌生人，但開關費力（慢）。
• 對稱像共用保險箱鑰匙：開鎖快，適合接下來大量的密談內容。

體會：TLS 就是把『方便交鑰匙（公鑰）』和『快速跑資料（對稱）』兩者的優點，用一場精心設計的握手串起來。

STEP 3

實用超能力

看懂每一次 https 連線背後發生什麼

你每天都在跑 TLS 握手

每次打開 https 網站、用網路銀行、登入 App，背後都在跑這場握手。看懂它，你就理解了現代網路安全的骨幹。

flowchart TD
  A[客戶送 ClientHello 列出支援的演算法] --> B[伺服器選定 cipher suite 並送憑證]
  B --> C[客戶驗證 X509 憑證鏈]
  C --> D[客戶產生 pre-master secret 用伺服器公鑰加密送出]
  D --> E[雙方各自導出對稱工作階段金鑰]
  E --> F[互換 Finished 後 全程對稱加密通訊]

TLS 把整章觀念串起來

前面學的觀念	在 TLS 的角色
混合協定	公鑰交換 + 對稱加密大量資料
公鑰憑證 (X.509)	握手時互相認證、防中間人
安全通道三性質	紀錄協定提供保密、完整、真實
MAC	紀錄協定用它做訊息認證
演算法協商	cipher suite 不綁死特定演算法

設計啟示

1. 不綁死演算法：TLS 能協商 cipher suite，所以某個演算法被攻破時，可改用別的而不必重做整個系統——這是它長壽的關鍵（對照下一節 WEP 把 RC4 寫死的慘劇）。
2. 可選擇加密哪個方向：不需要的方向就不加密，省運算。
3. 可信起點防中間人：第一張憑證的信任，要靠另一管道（內建根憑證）取得，否則握手可能被中間人攻破。

下次看到網址列鎖頭，你已經能完整說出它背後這場握手的每一步。

STEP 1

深度探秘

一個幾乎全錯的安全設計

為什麼 WiFi 特別需要安全

1999 年發布的 IEEE 802.11 無線網路標準，內含一套安全規格叫 WEP (Wired Equivalent Privacy)。無線網路天生比有線更容易被攻擊——任何在範圍內有收發器的裝置都能竊聽、假冒。WEP 想用兩招提供保護：

• 存取控制：用挑戰-回應協定，加入的節點要證明自己有正確的共享金鑰 K。
• 隱私與完整：用 RC4 串流加密（同一把 K），並在每個封包加密文檢查碼保護完整性。

但 WEP 的設計被發現嚴重不足，幾乎每個環節都有問題。它是『安全設計有多難』的經典反面教材。

WEP 的核心缺陷

1. 全網共用單一金鑰：一把 K 由管理員指定、給所有授權裝置共用。後果：金鑰常經不安全通道發給新使用者；而一個粗心或惡意的人（如心懷不滿的離職員工）拿到 K，就能讓整個網路淪陷，還可能無人察覺。解法：像 TLS 那樣用公鑰協定協商個別金鑰。

2. 基地台從不被認證：攻擊者若知道共享金鑰，可架一個假基地台竊聽、插入或竄改流量。解法：基地台應提供可被第三方公鑰認證的憑證。

3. 誤用串流加密 + IV 太短（最致命）：每個封包用 RC4 金鑰流 XOR 加密。為避免封包遺失造成同步錯誤，RC4 用『24 位元的初始值 (IV) + 共享金鑰』重啟，IV 以明文附在每個封包。問題是共享金鑰幾乎不變，所以起始值只有 2^24（約 10^7）種，傳約 10^7 個封包後金鑰流就重複——實務上可能幾小時內就發生。攻擊者若知道某封包明文 P_i，就能算出金鑰流 K_i；金鑰流重複後，他就能用 K_i 解密新封包。而且 IV 是明文，攻擊者一眼就能看出重複。解法：在重複的最壞時間前協商新金鑰（如 TLS 有明確終止機制）。

4. 金鑰長度過短：40 位元（甚至 64 位元）金鑰是為配合美國早期出口管制而設，但 40 位元極易被暴力破解。解法：只用 128 位元金鑰。

5. RC4 本身有弱點：標準發布後，RC4 被發現可在觀察大量流量後推算出金鑰，即使金鑰流不重複也能破，連 128 位元也不保險。解法：像 TLS 般可協商加密演算法；但 WEP 把 RC4 寫死，無從更換。

STEP 2

生活妙喻

全公司共用一把門鎖密碼的災難

把 WEP 想成一間管理超爛的公司

全公司共用一個門鎖密碼

公司門禁只有一組密碼 (單一共享金鑰)，發給每個員工。問題來了：

• 新人報到，密碼常是用 LINE 隨手傳的（不安全通道）。
• 任何一個離職員工只要記得這組密碼，就能進出整棟公司，公司還不會發現。一人外洩，全公司淪陷。

正確做法：每人一張獨立門禁卡（個別協商的金鑰），離職就停掉那一張。

大門不驗『這是不是真公司』

員工只證明『我知道密碼』，卻沒人確認門後真的是自家公司。壞人可以架一個假的公司門面 (假基地台)，騙員工把機密交出來。

一次性密語只有 1000 萬種、還寫在門口

最致命的：公司用『一次性密語』加密通訊，但密語的變化只有約 1000 萬種，而且每天用量超大——幾小時就把所有密語用完、開始重複。更扯的是，他們把當前密語的編號大剌剌貼在門口 (IV 明文)，偷聽者一看就知道『啊，這個密語又重複了』，於是一句句破解。

一次性密語的鐵律就是『絕不重複』，WEP 卻把它用到重複——這是它崩潰的核心。

密碼太短 + 鎖頭本身有暗門

門鎖密碼短到（40 位元）幾下就試出來；而且這款鎖（RC4）後來被發現本身就有暗門，看久了就能撬開——偏偏公司把這款爛鎖焊死了，想換都換不了。

STEP 3

實用超能力

從 WEP 慘案提煉安全設計原則

WEP 是最好的反面教材

它把這一章講過的原則幾乎全部違反。把每個錯對照正確原則，就是一份珍貴的安全設計檢查表：

WEP 的錯	違反的原則	正確做法 (常見於 TLS)
全網共用單一金鑰	限制秘密的散布範圍	協商個別金鑰
基地台不被認證	雙向認證、防中間人	基地台出示可驗證的憑證
串流金鑰流會重複	串流加密絕不可重複金鑰流	重複前協商新金鑰
金鑰只有 40 位元	金鑰要夠長抵抗暴力破解	只用 128 位元
RC4 寫死無法更換	演算法應可協商	cipher suite 協商

三個帶得走的設計原則

flowchart TD
  W[WEP 的失敗] --> A[原則一 別讓秘密共享太廣 個別金鑰勝過全網共用]
  W --> B[原則二 串流加密的金鑰流絕不能重複]
  W --> C[原則三 別把演算法寫死 要能協商更換]

動手判斷

下次評估任何加密系統，用 WEP 的教訓當體檢題：

1. 金鑰是大家共用一把，還是各自獨立？ 共用一把就是大警訊。
2. 若用串流加密，金鑰流會不會重複？ IV 夠長嗎？
3. 演算法被攻破時換得掉嗎？ 寫死的設計遲早出事。
4. 金鑰夠長嗎？基地台/伺服器有被認證嗎？

最大的啟示：安全設計極難，一個環節錯就可能讓整套崩潰。最好站在 TLS 這種經充分檢驗的標準肩膀上，而不是自己土法煉鋼。