密碼學、PKI 與 TLS：從金鑰到可信連線
本頁為依教材與考古題整理的原創摘要；考古題答案經技術覆核，但不是官方答案。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
加密與金鑰
也會看到：encryption、symmetric key、asymmetric key、public key、private key、對稱式、非對稱式加密用金鑰把明文轉成未授權者難以讀懂的密文；對稱式共用密鑰，非對稱式使用公私鑰對。
- 生活例子：
- 對稱式像雙方共用一把房門鑰匙，非對稱式像任何人可投信但只有收件人能開信箱。
- 別搞混：
- 公鑰可以公開不代表私鑰也能公開；加密也不自動證明發送者身分。
雜湊與數位簽章
也會看到：hash、digest、digital signature、雜湊、數位簽章雜湊產生資料摘要；數位簽章用私鑰簽摘要，供他人驗證來源與完整性。
- 生活例子：
- 像先做文件指紋，再由本人蓋上只有他能使用的印章。
- 別搞混：
- 雜湊不是加密，簽章也不是把手寫簽名貼進檔案。
混合式加密
也會看到：hybrid encryption、RSA、AES用公開金鑰方式安全交換短金鑰，再用速度較快的對稱金鑰加密大量資料。
- 生活例子：
- 像用防拆保險箱寄送房門鑰匙，之後用房門鑰匙快速進出。
- 別搞混：
- 實務上通常不直接用 RSA 加密整段大量連線內容。
PKI 與 TLS
也會看到：PKI、certificate、CA、TLS、HTTPS、憑證PKI 用憑證與信任機構綁定身分和公鑰，TLS 再利用它建立受保護連線。
- 生活例子：
- CA 像核發證件的機關，TLS 像雙方查驗證件後建立安全通道。
- 別搞混：
- HTTPS 不代表網站內容一定可信，只代表連線對象與傳輸受到特定保護。
先分清對稱加密、公開金鑰、雜湊與數位簽章的用途，再以憑證、CA／RA 與 TLS 串起網站身分驗證、機密性及完整性。對應考古題答案均為非官方技術覆核。
先抓住這幾件事
- 依安全需求選擇對稱加密、非對稱加密、雜湊或數位簽章
- 說明 RSA 與 AES 的角色差異，以及混合式加密為何同時使用兩者
- 判讀 X.509 憑證的重要欄位及 CA、RA、subject 的責任
- 解釋 TLS 如何建立 HTTPS 連線，以及 server authentication 與 mutual TLS 的差異
先想像這個場景
寄送一只上鎖的大行李箱
Alice 要把 500 MB 檔案交給 Bob。她不會用昂貴的身分驗證程序逐頁處理整箱內容，而是先用一把短期行李箱鑰匙快速鎖好大量資料，再用 Bob 可公開取得、但只有 Bob 能解開的機制保護這把短期鑰匙；同時附上可驗證是 Alice 所做的簽章。
先別急著往下看，花十秒想一想：
若 Alice 只把檔案加密，Bob 是否就能確定寄件者一定是 Alice？若只附上一個任何人都能重算的 hash，又能否阻止攻擊者同時替換檔案與 hash？
把故事換成電腦語言
| 生活中的角色 | 對應到 | 技術概念 |
|---|---|---|
| Alice 與 Bob 用同一把短期行李箱鑰匙快速鎖、開大量內容 | AES session key 與 symmetric authenticated encryption 處理 bulk data | |
| 任何人都能使用 Bob 公開的投遞鎖，但只有 Bob 保管的鑰匙能取出內容 | 用 Bob 的 public-key mechanism 保護 session key，由 Bob 的 private key 解開 | |
| 對內容計算一個固定長度的指紋，內容一改指紋通常就不同 | Cryptographic hash 用於 integrity evidence，但本身沒有秘密，不能單獨驗證寄件者 | |
| Alice 加上只有她能製作、他人可核對的簽名封條 | Alice private key 產生 digital signature，Alice public key 驗證來源與內容完整性 | |
| 可信證件中心在證件上簽章，證明某姓名確實對應某把公開驗證工具 | CA-signed X.509 certificate 將 subject identity 綁到 public key；RA 可先核驗申請者 |
題目出現這些字，先想到
- 大量資料、效率：AES 等 symmetric encryption；public/private key、RSA：asymmetric role，不直接處理任意大型資料。
- 固定長度單向摘要：hash；要驗證來源與防替換：找 MAC 或 digital signature，不能只靠裸 hash。
- Subject、issuer、serial、public key：certificate；RA 核驗申請，CA 簽發與簽章，private key 不放進憑證。
- HTTPS＝HTTP over TLS；一般網站驗 server，雙方都出示 client/server certificate 才是 mutual TLS。
1.先從安全目標選工具
資訊安全的三大核心目標（CIA Triad）決定了需要哪些密碼學工具： • Confidentiality（機密性）— 確保資料只有授權的人能讀取。工具：加密（encryption）。 • Integrity（完整性）— 確保資料沒有被未授權地修改。工具：雜湊（hash）、數位簽章（digital signature）。 • Authentication（身分驗證）— 確認通訊對方的身分是真的。工具：數位憑證（digital certificate）、MAC。 另外還有 Non-repudiation（不可否認性）— 發送者事後不能否認曾發送某訊息。工具：數位簽章。 【Hash Function（雜湊函式）】把任意長度的輸入映射成固定長度的 hash value（摘要）。特性：(1) 單向 — 從 hash value 無法還原出原始資料。(2) 抗碰撞 — 極難找到兩個不同輸入產生相同 hash value。(3) 雪崩效應 — 輸入改變 1 bit，output 會大幅改變。常見演算法：MD5（128 bits，已不安全）、SHA-1（160 bits，已不推薦）、SHA-256（256 bits，目前主流）。 用途：(1) 驗證檔案完整性（下載後比對 hash）。(2) 密碼儲存（資料庫存 hash 值而非原始密碼）。(3) 數位簽章的基礎。(4) Blockchain 中的 block linkage。 【MAC（Message Authentication Code）】結合 hash 和 secret key，同時驗證 integrity 和 authentication。發送端用 key 產生 MAC，接收端用相同的 key 驗證。HMAC 是使用 hash function 實作的 MAC（如 HMAC-SHA256）。 【考試連結】(1) 先確認安全目標，再選擇工具。(2) Hash 提供 integrity 但不提供 confidentiality（任何人都能計算 hash）。(3) MD5 和 SHA-1 已被認為不安全（collision attacks），考古題可能問這個。
- Confidentiality：避免未授權者讀懂資料，典型工具是 encryption
- Integrity：偵測內容是否改變，可用帶金鑰的 MAC 或 digital signature
- Authentication：確認通訊對象或訊息來源，需要金鑰與可信身分綁定
- Hash 是單向摘要；encoding 與 compression 都不是 encryption
2.對稱、非對稱與混合式加密
加密（encryption）是把明文（plaintext）轉換成密文（ciphertext）的過程，只有持有正確金鑰（key）的人才能解密（decryption）還原明文。依據加解密使用的 key 是否相同，分為兩大類： 【Symmetric Encryption（對稱加密）】 加密和解密使用同一把 key。 特點：速度快（比非對稱快 100-1000 倍），適合大量資料加密。 問題：Key distribution — 通訊雙方需要安全地共享同一把 key。如果 key 被截獲，整個加密就破了。 常見演算法：AES（Advanced Encryption Standard, 目前主流，key 128/192/256 bits）、DES（56-bit key, 已不安全）、3DES（168-bit key, DES 的改良）。 【Asymmetric Encryption（非對稱加密 / Public Key Cryptography）】 使用一對 key：public key（公鑰）和 private key（私鑰）。Public key 公開，private key 保密。 • 用 public key 加密 → 只有 private key 能解密（confidentiality）。 • 用 private key 簽名 → 任何人用 public key 能驗證（authentication + non-repudiation）。 特點：解決了 key distribution 問題（public key 可以公開傳送），但速度慢。 常見演算法：RSA（基於大數分解困難）、ECC（Elliptic Curve Cryptography, 更短的 key 達到相同安全強度）、Diffie-Hellman（key exchange, 不直接加密）。 【Hybrid Encryption（混合式加密）】 實務上的標準做法 — 結合兩者的優點： (1) 用 asymmetric encryption 安全地交換一個臨時的 symmetric key（session key）。 (2) 用 symmetric key 加密實際的資料（速度快）。 TLS/HTTPS 就是用這種方式：handshake 階段用非對稱交換 session key，之後用對稱加密傳輸資料。 【考試連結】(1) 對稱加密快但有 key distribution 問題；非對稱加密慢但解決 key distribution。(2) AES 是對稱，RSA 是非對稱。(3) 數位簽章用 private key 簽名、public key 驗證（不是反過來！）。(4) DES 已不安全是因為 key 太短（56 bits），可被暴力破解。
- AES、DES、IDEA 與 Caesar cipher 都是對稱式；RSA 是非對稱式
- 公開金鑰可以公開，private key 必須由持有者保護
- RSA 安全性與大整數分解困難相關，但安全實作仍依賴正確 padding 與金鑰長度
- 不要直接用 textbook RSA 加密任意大型使用者資料
對稱式加密的核心問題是？
3.憑證把身分綁到公鑰
Non-symmetric encryption 解決了 key distribution 的問題，但產生了新問題：你怎麼確定拿到的 public key 真的屬於你想通訊的對象？攻擊者可能冒充對方，把自己的 public key 給你（Man-in-the-Middle attack）。 【Digital Certificate（數位憑證）】由受信任的第三方 Certificate Authority（CA）簽發，把一個 identity（如網站域名 www.ntu.edu.tw）和一個 public key 綁在一起。憑證內容包含： • Subject（持有者身分） • Subject's public key • Issuer（簽發的 CA） • Validity period（有效期限） • CA 的 digital signature（用 CA 的 private key 對上述資訊簽名） 驗證流程：(1) 你收到 www.ntu.edu.tw 的憑證。(2) 用 CA 的 public key 驗證憑證上的 digital signature。(3) 如果驗證通過 → 憑證是真的 → 裡面的 public key 確實屬於 www.ntu.edu.tw。 【PKI（Public Key Infrastructure）】 建立和管理數位憑證的完整架構： • Root CA：最頂層的 CA，其憑證（root certificate）預先安裝在 OS 和瀏覽器中（trust store）。 • Intermediate CA：由 Root CA 簽發，實際負責簽發終端憑證。形成 certificate chain。 • Certificate chain 驗證：終端憑證 → 由 intermediate CA 簽發 → intermediate CA 的憑證由 Root CA 簽發 → Root CA 在 trust store 中 → 整條鏈可信。 【Certificate Revocation】如果 private key 洩露，需要撤銷憑證。機制：CRL（Certificate Revocation List，CA 定期發布）、OCSP（Online Certificate Status Protocol，即時查詢）。 【考試連結】(1) CA 的角色是把 identity 綁定到 public key。(2) 數位簽章驗證用的是 CA 的 public key，不是 subject 的。(3) Self-signed certificate 是自己簽發給自己的，瀏覽器會顯示「不受信任」的警告。
- Certificate 證明的是身分與 public key 的受信綁定，不會公開 private key
- Issuer 欄位指出簽發者；subject 欄位指出憑證所描述的實體
- RA 驗證／註冊，CA 簽發／簽章，兩者角色不可互換
- 憑證有效期內仍可能被撤銷，因此只看日期不一定足夠
4.TLS 如何讓 HTTP 變成 HTTPS
TLS（Transport Layer Security）在 TCP 之上建立加密通道，保護應用層資料的 confidentiality 和 integrity。HTTPS = HTTP over TLS。 【TLS Handshake 流程（簡化版 TLS 1.2）】 (1) Client Hello — Client 發送支援的 TLS 版本、加密演算法清單（cipher suites）和一個 random number。 (2) Server Hello — Server 選擇 cipher suite，發送自己的 random number 和 digital certificate。 (3) Certificate Verification — Client 驗證 server 的憑證（檢查 CA 簽名、有效期、域名是否匹配）。 (4) Key Exchange — Client 產生 pre-master secret，用 server 的 public key 加密後傳送。 (5) Session Key Generation — 雙方各自用 pre-master secret + 兩個 random numbers 計算出相同的 session key（symmetric key）。 (6) Finished — 雙方用 session key 加密確認訊息，handshake 完成。 之後所有的 HTTP 通訊都用 session key 做 symmetric encryption。 【TLS 1.3 改進】 • Handshake 減少一個 round trip（1-RTT，甚至 0-RTT 重連）。 • 移除不安全的 cipher suites（如 RC4、SHA-1）。 • 所有 handshake 訊息在 Server Hello 後都加密。 【TLS 提供了什麼？】 (1) Confidentiality — 傳輸中的資料加密，竊聽者只能看到密文。 (2) Integrity — MAC 保護資料不被篡改。 (3) Authentication — 透過 certificate 驗證 server 身分。 【TLS 沒有提供什麼？】 • 不保護端點安全 — 如果 server 被入侵，攻擊者有 private key 就能解密。 • 不保護 metadata — 竊聽者仍能看到目標 IP、域名（SNI）、流量模式。 【考試連結】(1) HTTPS = HTTP + TLS，不是 HTTP + SSL（SSL 是 TLS 的前身，已棄用）。(2) TLS handshake 使用 asymmetric encryption 交換 session key，之後用 symmetric encryption 傳輸資料（hybrid encryption）。(3) TLS 工作在 transport layer 之上、application layer 之下。
- TLS 同時保護機密性、完整性，並通常驗證 server 身分
- 憑證內有 public key；private key 留在持有者端，不隨憑證傳送
- 受信第三方 CA 是公開 Web PKI 的部署慣例，不是建立 TLS 密文通道的唯一方式
- mTLS 是雙向憑證驗證，不等同一般網站的密碼登入
TLS handshake 中，pre-master secret 用誰的 key 加密？為什麼？
一起拆題目
範例 1：系統要傳送 500 MB 備份檔；Bob 已透過可信憑證取得 Alice 的 public key，Alice 也已取得 Bob 的 public key。可用 AES、RSA 與 digital signature，應如何組合，才能讓 Bob 確認檔案來自 Alice？
- 隨機產生一把短期 AES session key，用 AES authenticated encryption 加密大型備份檔。
- 用接收者 Bob 的 public key 保護 session key，使只有 Bob 的 private key 能取得它。
- Alice 對必要的檔案 metadata 與密文摘要產生 digital signature。
- Bob 解開 session key、驗證 Alice 的 signature，再解密並檢查 authenticated-encryption tag。
所以答案是：大型資料用 AES；session key 由 Bob 的公開金鑰機制保護；Alice 的數位簽章提供來源與完整性驗證。不要直接用 RSA 處理整個 500 MB 檔案。
範例 2：某憑證顯示 Subject=shop.example、Issuer=Example CA、Serial=42，申請者身分由 Example RA 核對。誰簽章？撤銷清單如何指出這張憑證？
- RA 的工作是核對與註冊申請資訊，不因參與核對就成為憑證簽章者。
- Issuer=Example CA 表示 CA 簽發並以其私鑰簽署憑證。
- Serial=42 只需在 Example CA 的簽發範圍內唯一。
- 撤銷資料以 issuer 與 serial number 的組合定位該憑證。
所以答案是：Example CA 簽章；Example RA 負責身分核對。撤銷機制以 Example CA 所簽發、serial number 42 的憑證為目標。
範例 3：內部測試站使用 self-signed certificate，管理員已把該憑證安全地安裝到所有測試裝置的 trust store；憑證的 SAN/hostname、有效期與 key usage 都符合該站。這能建立 TLS 嗎？是否等同公開網站的第三方 CA 模式？
- TLS 需要 client 能建立信任路徑或直接信任 server certificate，不必然要求公開第三方 CA。
- 裝置預先安全安裝該 self-signed certificate 後，可把它當作 trust anchor。
- 握手仍需 server 證明持有對應 private key，並建立 session keys。
- 未預先安裝信任的外部使用者不會自然信任此憑證，所以它不等同公開 Web PKI。
所以答案是：可以建立且驗證 TLS，但信任來自管理員的預先配置，不是公開第三方 CA。未配置該 trust anchor 的 client 應拒絕或警告。
這裡最容易選錯
- 把 RSA、AES 都當成可互換的大量資料加密工具，忽略非對稱運算成本與訊息長度限制
- 認為 digital certificate 內含 private key；憑證公開的是 public key 與身分資訊
- 把 RA 說成負責簽發與簽章憑證；一般角色分工是 RA 核驗、CA 簽發
- 把 hash 當成可解密的加密，或以為沒有祕密金鑰的 hash 就能驗證傳送者身分
- 認為 HTTPS 技術上只能使用公開第三方 CA，忽略 private CA 與預先信任模式
- 只檢查憑證有效日期，忽略 hostname、chain、key usage 與 revocation 等驗證條件
換你快速判斷
先在心中作答，再展開答案。答不出來時，回頭找本課的對照關係。
1AES 與 RSA 最核心的差別是什麼？
AES 是使用共享秘密金鑰的對稱式加密；RSA 使用 public/private key pair，屬非對稱式密碼。
大型資料通常用 AES 等對稱式演算法處理；公開金鑰機制常用來保護 session key 或產生／驗證簽章。
2為什麼不直接用 RSA 加密大型檔案？
RSA 運算成本高，且可安全處理的訊息長度受 modulus 與 padding 限制；實務用它保護短 session key，再以對稱加密處理資料。
這種混合式設計結合公開金鑰的 key establishment 與對稱式加密的效率。
3Digital certificate 主要把哪兩件事綁在一起？
把 subject 的身分或名稱與其 public key 建立可驗證的綁定，並由 issuer 簽章。
憑證不包含 subject private key；驗證者還要檢查信任鏈、名稱、有效期間與用途等條件。
4PKI 中 CA 與 RA 的角色有何不同？
RA 協助核驗與註冊申請者；CA 簽發並以私鑰簽署 digital certificate。
實際組織可能合併職能，但概念題不能把 registration authority 說成必然負責簽發與簽章。
5Certificate serial number 與撤銷有什麼關係？
Serial number 在 issuer 範圍內唯一識別憑證；CRL 或 OCSP 可用 issuer 與 serial number 指定被撤銷或查詢的憑證。
Serial number 的基本功能是唯一識別，不是把完整 revocation record 存在憑證裡。
6HTTPS 是否在技術上必須使用公開第三方 CA 簽發的 server certificate？
不必然。公開網站通常依賴受信 CA，但 TLS 也能使用 private CA 或由 client 預先信任的 self-signed certificate。
關鍵是 client 能建立信任並驗證 server 持有對應 private key；mTLS 還會反向驗證 client certificate。
最後用考古題驗證
本課連結的題目都已通過可重現的技術覆核，可逐題練習與判分。
開始本課考古題練習參考來源
- Network and Computer Security (6.857) — Ron Rivest
- Cryptographic Standards and Guidelines — National Institute of Standards and Technology