Credential 漫畫小教室：門口的人到底是誰？

先從門口驗身分開始

這篇先不要急著背 Credential、Authentication、Authorization 這些名詞。你先想像自己站在安全實驗室門口，跟守衛說：我是 MY，我可以進去。守衛真正要問的是：你有什麼證明？

Credential 就是你拿出的證明。Authentication 是系統檢查這份證明是真的。Authorization 是通過檢查之後，系統決定你可以進哪裡、能做什麼。三件事分開看，後面的密碼、Passkey、Token、Certificate 就會清楚很多。

左側目錄是閱讀地圖。先用前幾張圖把門口驗證的故事看懂，再往下看私鑰、公鑰、憑證、裝置身分與 Attestation。每張圖下面的文字會把比喻接回真正的工程設計。

Credential 這個字常被翻成「憑證」或「認證資訊」，但如果一開始就丟英文名詞，很多人會以為它只是在講密碼、Token 或證書檔。比較好懂的說法是：Credential 是你拿來支持某個主張的證明。

你說「我是 MY」、「我可以進這個實驗室」、「這台裝置是原廠出貨」，系統不會因為你開口就相信。它需要看到某種證明，接著驗證這個證明是真的，最後才決定你能做什麼。這篇用 12 張漫畫，從最直覺的密碼一路講到私鑰、公鑰、憑證、Token、裝置身分與 Attestation。

讀的時候先抓住一條主線：Credential 負責證明，Authentication 負責檢查，Authorization 負責放行範圍。 這三件事分清楚，後面的名詞會好懂很多。

P1｜Credential 是什麼：用來支持主張的證明

Credential 漫畫小教室第 1 頁：Credential 是支持身分主張的證明 — Credential 不是答案本身，而是讓系統相信某個主張的證明。

第一頁先把 Credential 放回日常情境：你站在門口，說自己是工程師、可以進安全實驗室。守衛不會只聽你說，會要求你拿出證明。這張證明可能是員工卡、手機 Passkey、安全金鑰、密碼、數位憑證，甚至是裝置內部的晶片金鑰。

所以 Credential 的重點不是「它長什麼樣子」，而是「它支撐了哪個主張」。密碼支撐「我知道這個秘密」，員工卡支撐「我持有公司發的卡」，私鑰簽章支撐「我真的握有那把私鑰」，憑證支撐「這把公鑰屬於某個人、網站或裝置」。

這也解釋了為什麼 Credential 不能只看方便性。越重要的門，系統越不能只問一句「你是誰？」就放人。它要看證明能不能被驗證、能不能被偽造、被偷走後會造成多大損失。

P2｜證明、檢查、放行，不是同一件事

Credential 漫畫小教室第 2 頁：Credential、Authentication、Authorization 的差別 — Credential 是你拿出的證明，Authentication 是系統檢查證明，Authorization 是通過後能做什麼。

很多安全問題，都是因為把三件事混在一起。Credential 是你拿出來的東西，例如密碼、Passkey、憑證或安全金鑰。Authentication 是系統檢查這個東西對不對，例如比對密碼、驗證簽章、檢查憑證是否有效。Authorization 則是通過檢查後，系統決定你能進哪裡、能不能改設定、能不能讀資料。

遊樂園的例子很直覺：票是 Credential，驗票是 Authentication，能進一般區、互動體驗區或 VIP 區，才是 Authorization。驗票成功不代表全園區都能進，只代表「這張票是真的」。你能進哪一區，還要看票種、身分、時間與權限設定。

在網站、雲端服務與裝置安全裡也是一樣。登入成功只代表身分驗證通過，不代表你應該拿到管理員權限。好的系統會把「你是誰」和「你可以做什麼」分開處理，這樣權限才不會越給越大。

P3｜說出秘密很簡單，也最容易出事

Credential 漫畫小教室第 3 頁：共享秘密的風險 — 密碼、PIN、PSK、API Key 都屬於「知道的秘密」。好懂，也好被偷聽、記錄與冒用。

最簡單的驗證方式，是你直接說出秘密。門口問通關密語，你答對就進去。密碼登入也是這個概念：系統檢查你輸入的秘密，和它保存或推導出的資料是否吻合。

問題是，只要秘密在傳輸、輸入或儲存過程被偷走，攻擊者就可能假裝成你。鍵盤側錄、釣魚網站、惡意 App、資料庫外洩、log 誤記錄，都會把「知道秘密」變成「拿到秘密的人都可以冒充」。

這也是為什麼單靠密碼越來越不夠。密碼可以作為 Credential，但它不是最安全的 Credential。越重要的系統，越需要讓使用者證明自己「知道或持有某個秘密」，同時不要把秘密本身交出去。

P4｜不交出秘密，也能證明你知道秘密

Credential 漫畫小教室第 4 頁：Challenge-Response 不交出秘密也能驗證 — Challenge-Response 的精神是：題目每次不同，你用秘密算出回應，但秘密本身不出門。

更聰明的做法是 Challenge-Response。系統每次出一道不同題目，也就是 challenge 或 nonce。你用手上的秘密算出 response，系統檢查這個 response 對不對。整個過程中，秘密本身不用送出去。

這樣有兩個好處。第一，攻擊者就算側錄到一次回應，也不能拿去重放，因為下一次題目不同。第二，系統真正檢查的是「你能不能用秘密產生正確回應」，不是「你願不願意把秘密交出來」。

這個觀念會一路延伸到私鑰簽章、Passkey、裝置認證與晶片安全。真正重要的不是每次都說出密碼，而是讓系統看到一個只可能由正確秘密產生的證據。

P5｜Password 和真正的 Key 差在哪裡

Credential 漫畫小教室第 5 頁：Password 和 Cryptographic Key 的差別 — Password 是給人記的；Cryptographic Key 是給機器安全使用的。

密碼和密碼學金鑰常被混在一起，但安全強度差很多。Password 通常短、可記憶、帶有人類習慣，所以容易被猜、被字典攻擊、被重複使用。Cryptographic Key 則應該是長、隨機、難預測，適合拿來簽章、加密或產生驗證碼。

有時候系統會用 KDF，把人類密碼加上 salt 後推導成比較適合機器使用的 Derived Key。這比直接拿 123456 當金鑰好很多，但它不能把弱密碼變成真正隨機的機器金鑰。原始密碼如果太弱，攻擊者仍然可以離線猜測。

所以工程上常見的分工是：Password 是人記得住的入口，Random Key 或硬體保護的私鑰才適合當真正的安全根基。能用 Passkey、硬體安全金鑰或裝置內私鑰時，通常比只靠密碼更穩。

P6｜私鑰留在手上，送出去的是簽章

Credential 漫畫小教室第 6 頁：Private Key、Public Key 與 Signature — 非對稱認證不是把私鑰交出去，而是用私鑰產生簽章，讓公鑰去驗證。

非對稱認證的核心很漂亮：私鑰留在自己手上，公鑰可以交給別人。當系統丟出 challenge，你用私鑰簽章，系統用公鑰驗證。驗證成功，代表簽章確實來自對應私鑰。

這比共享密碼安全，因為伺服器不需要保存你的私鑰，也不需要知道你的秘密。攻擊者就算看見公鑰，也不能反推出私鑰。就算看見某次簽章，下一次 challenge 不同，也不能直接拿舊簽章冒用。

Passkey、FIDO 安全金鑰、裝置認證、Secure Boot 的簽章驗證，都大量使用這種思路。私鑰不外流，才是整個設計的底線。

P7｜Certificate 把公鑰和身分綁在一起

Credential 漫畫小教室第 7 頁：Certificate 把 Public Key 和 Identity 綁定 — 公鑰能驗簽，但 Certificate 才說明這把公鑰到底代表誰。

有公鑰還不夠。問題是：這把公鑰到底屬於誰？如果每台伺服器都說「這是我的公鑰」，使用者仍然不知道哪一把是真的。Certificate 的角色，就是把身分資訊、公鑰、用途、有效期限與簽發者簽章綁在一起。

網站 HTTPS 憑證就是最熟悉的例子。瀏覽器不是只看到一把公鑰就相信網站，而是檢查憑證鏈、簽發者、網域名稱、有效期限與撤銷狀態。這一套機制讓「公鑰」從一把孤零零的鑰匙，變成可被信任關係支撐的身分證明。

裝置憑證也類似。製造商或 CA 可以替裝置簽發憑證，證明這把公鑰屬於某台裝置、某個型號或某個安全元件。系統因此不只驗簽，還知道這個簽章應該信到什麼程度。

P8｜Token 是短期入場券，不是永久身分證

Credential 漫畫小教室第 8 頁：Token 是短期有限制的入場券 — Token 通常是驗證通過後拿到的短期代表。誰拿到 Bearer Token，誰就可能使用它。

Token 常出現在登入後。你先用密碼、Passkey 或憑證證明自己，系統驗證通過後，發給你一張短期入場券。之後你拿這張 Token 去存取服務，不需要每次重新拿原始 Credential 出來。

Token 的好處是方便、可設定期限、可限制範圍，也比較容易撤銷或輪替。OAuth Access Token、Session Cookie、JWT 都常用在這個位置。它們不是你的永久身分證，而是「在一段時間內，代表你可以做某些事」的憑據。

但 Token 也要保護好，尤其是 Bearer Token。Bearer 的意思很直接：誰持有它，誰就能用它。這也是為什麼 Token 要走 HTTPS、期限不能太長、權限不能太大，前端儲存位置也要小心。

P9｜Credential 住在哪裡，安全等級就不同

Credential 漫畫小教室第 9 頁：Credential 的儲存位置會影響安全性 — 同樣叫 Credential，放在普通檔案、OTP、Secure Element、TPM、HSM 或 PUF，安全等級差很多。

安全不只看演算法，也看秘密住在哪裡。把金鑰放在普通檔案裡很方便，但如果檔案權限、備份、log 或惡意程式沒管好，就容易被讀走。OTP 或 eFuse 適合放固定 Root Data，但寫入後不容易改。Secure Element、TPM、HSM 則把金鑰與運算放進受保護的環境，降低外流風險。

PUF 則更特別：它不一定直接保存完整金鑰，而是利用晶片本身的物理差異，在需要時重建或導出 Root Key。這對抗「靜態金鑰被讀出」很有價值，但也需要錯誤校正、穩定性設計與安全封裝一起配合。

所以問「用了什麼演算法」還不夠。還要問：金鑰在哪裡產生？在哪裡使用？會不會離開安全邊界？有沒有被備份、複製、匯出或搬移的路徑？很多安全事故不是演算法壞掉，而是 Credential 放錯地方。

P10｜Device Identity：每台裝置都該有自己的名字

Credential 漫畫小教室第 10 頁：Device Identity 讓每台裝置能被獨立辨認 — Device Identity 的重點不是大家都有 Key，而是每台裝置都能被獨立辨認。

人需要身分，裝置也需要。Device Identity 用來回答「我是哪一台裝置」。它通常會結合唯一識別碼、裝置金鑰與裝置憑證，讓伺服器或驗證者可以分辨不同裝置。

如果一萬台裝置共用同一把秘密，只要其中一台被破解，整批裝置都可能受影響。好的 Device Credential 應該每台唯一、不容易複製、能追溯來源，出事時也能撤銷或隔離。

這在 IoT、車用、工業控制、雲端邊緣設備都很重要。系統不只要知道「有人登入」，還要知道「是哪台設備在連線」。人、裝置、服務帳號都應該有清楚邊界。

P11｜Attestation：不只問你是誰，也問你現在可不可信

Credential 漫畫小教室第 11 頁：Attestation 證明裝置目前狀態是否可信 — Identity 證明「你是誰」；Attestation 進一步證明「你現在的狀態可不可信」。

Device Identity 說明裝置是誰，但這還不夠。裝置可能是真的，韌體卻被改過；裝置可能是原廠出貨，Debug 介面卻被打開；金鑰可能還在，系統狀態卻已經不安全。

Attestation 要回答的是「這台裝置現在處於什麼狀態」。常見證據包括韌體雜湊、Secure Boot 狀態、安全版本、Debug 狀態、設定值、錯誤或健康資訊。驗證者根據這些證據，決定要不要信任這台裝置。

這也是 Zero Trust 思路裡很重要的一步。不是一次註冊後就永久相信，而是每次重要連線或敏感操作，都要重新檢查身分與狀態。真的裝置，不代表永遠安全；可信狀態，才值得放行。

P12｜總結：小小 Credential，大大保護

Credential 漫畫小教室第 12 頁：Credential 的總結與三條管理原則 — 好的 Credential 管理，要守住三件事：安全保存、定期更新、最小權限。

Credential 可以是密碼、Passkey、Token、Session、API Key、私鑰、憑證或裝置身分。它們形式不同，但都在做同一件事：幫你支持某個主張，讓系統有理由相信你。

真正的安全不是把所有東西都叫「憑證」就結束，而是分清楚它們的角色。原始 Credential 用來證明身分，Token 用來短期代表你，Certificate 用來把公鑰和身分綁在一起，Attestation 用來補上現在狀態是否可信。

最後記住三條：第一，Credential 要安全保存，不要讓別人偷走。第二，Credential 要有期限與更新機制，不要一把鑰匙用到天荒地老。第三，Credential 要最小權限，只給真正需要的存取範圍。小小 Credential，管得好就是大保護；管不好，就是攻擊者最想拿到的入場券。

Hashtags

#Credential #Authentication #Authorization #Token #Session #Passkey #Certificate #DeviceIdentity #Attestation #PublicKey #PrivateKey #KeyManagement #HardwareSecurity #Cybersecurity #ZeroTrust #身分驗證 #授權 #憑證 #裝置身分 #硬體安全 #漫畫小教室