先把 FIPS 140-3 想成密碼模組的安檢制度
FIPS 140-3 不是在說某個演算法夠不夠強，而是在檢查一個密碼模組到底有沒有被正確設計、實作、保護與操作。你可以把它想成密碼產品進場前的安檢。
這篇會用漫畫把驗證流程與 Level 1 到 Level 3 的差異講清楚：有些等級重視演算法與文件，有些等級進一步要求防拆、金鑰保護與角色權限。
如果你是硬體或晶片設計者，重點不是只問『有沒有 AES』，而是問：金鑰怎麼進來、怎麼存、怎麼清除、誰能操作、被拆或被攻擊時系統會怎麼反應。
FIPS 140-3 常被客戶、稽核、採購合約用一句話帶過：「你的 crypto module 要有 FIPS。」但對 RD 來說，真正麻煩的不是把 AES、SHA、RSA 放進晶片或軟體，而是要把模組邊界、角色權限、金鑰生命週期、環境防護、測試證據全部講清楚，最後還要通過 CSTL 實驗室與 CMVP 審查。
這篇小教室依照 8 張漫畫順序，把 FIPS 140-3 當成一個工程專案來看：先知道驗證對象是「模組」不是整台產品，再理解流程、11 個安全領域、Level 1 到 Level 3 的差異，最後回到專案決策：該選哪個等級，才不會花錯錢又卡在驗證。
1. FIPS 140-3 是什麼：驗的是模組，不是口號
第一頁先把最大觀念釐清：FIPS 140-3 驗證的對象是 cryptographic module，不是整個產品。模組可以是硬體 IC、軟體 library、firmware，或硬體加軟體的混合邊界；重點是它在明確邊界內執行密碼功能，並保護 CSP（Critical Security Parameters，例如金鑰、seed、internal secret）。
所以「我們用了 AES」不等於 FIPS validated。「我們的演算法有 CAVP 測試」也還不等於模組 validated。演算法測試只是前置條件，真正上榜要看 CMVP certificate。這對晶片公司很重要：客戶採購常問的是證書編號、module version、operational environment，而不是你內部 block diagram 多漂亮。
另外，NIST CMVP 已公告 FIPS 140-2 轉換時程：FIPS 140-2 模組在 2026 年 9 月 21 日後已移到 Historical List。新系統規劃應以 FIPS 140-3 為主；既有系統能否繼續使用，還要核對官方政策、個別證書狀態與採購要求。Historical 與 Revoked 不同，不能一律解讀成可用或不可用。這代表現在做新 SoC、HSM、secure element、firmware crypto library，規格與文件一開始就要用 140-3 思維設計。
2. 驗證怎麼跑：它是一場馬拉松專案
FIPS 140-3 的流程比較像產品認證加設計稽核。廠商先準備 Security Policy、有限狀態模型、設計文件、測試計畫、CAVP algorithm certificate 等材料，接著送到 CSTL 認可實驗室測試，再由 CMVP 審查報告與文件。最後拿到 certificate 並被列在 validated modules list，才是客戶可以引用的正式結果。
Security Policy 是最核心的公開文件。它會說明 module boundary、approved mode、角色與服務、金鑰輸入輸出、self-test、zeroization、operational environment 等。寫得不清楚，後面測試和審查都會反覆補件。
時程上不要太樂觀。圖上的 12 到 24 個月是專案估算，並非 CMVP 承諾。文件成熟度、模組變更、實驗室排程與審查補件都會影響時程。對 RD director 來說，這應該在產品規格階段就拉進 schedule，而不是 tape-out 後才補一句「順便做 FIPS」。
3. 全局地圖：四個等級與 11 個安全領域
第三頁是整套 FIPS 140-3 的地圖。Level 1 到 Level 4 不是單一開關，而是跨 11 個安全領域逐項評分，例如 module specification、interfaces、roles and services、software/firmware security、operational environment、physical security、non-invasive security、SSP management、self-tests、life-cycle assurance、mitigation of other attacks。
最容易被低估的是「短板決定等級」。如果 10 個領域都做到 Level 3，但 physical security 只有 Level 2，整體證書就只能是 Level 2。這對硬體安全 IC 很關鍵，因為你不能只把 crypto engine 做強，卻讓封裝、防拆、側通道、金鑰歸零或 SSP 管理拖後腿。
實務上，Level 1 常見於軟體 crypto library 或 SoC 內部 crypto engine；Level 2 開始要有拆封留痕與角色分離；Level 3 則要面對物理入侵、身份認證、trusted channel、環境防護與更嚴格的金鑰保護。
4. Level 1：做對演算法，開機先自檢
Level 1 可以把它想成「密碼學與基本工程紀律要做對」。演算法要是 approved algorithm，並通過 CAVP；元件要是 production-grade；模組啟動後要先做 pre-operational self-test，確認關鍵功能沒有壞掉，通過後才提供密碼服務。
這裡沒有要求 tamper-evident seal、tamper sensor 或特殊防拆封裝，所以很多軟體 library、手機作業系統內建 crypto module、一般 SoC crypto engine 會從 Level 1 開始。但「不要求防拆」不代表隨便做：approved mode、錯誤狀態、known-answer test、金鑰管理、文件一致性仍然會被檢查。
對 IC 設計來說，Level 1 是最常被拿來當 baseline 的等級。它適合軟體或一般晶片內建加密引擎，但若客戶威脅模型包含實體接觸、拆機、維修場域或攻擊者拿得到設備，就要往 Level 2 或 Level 3 評估。
5. Level 2：拆過要留痕，角色要分開
Level 2 的重點是 tamper-evidence 與 role-based authentication。Tamper-evidence 不是要讓攻擊者完全拆不開，而是拆過會留下肉眼可見或可檢查的痕跡，例如防拆封條、不透明外殼、防拆塗層或防拆漆。這讓營運者能在維修、盤點、稽核時發現設備被動過。
角色分離則要求至少區分 Crypto Officer 與 User。Crypto Officer 可以做設定、管理金鑰、調整模組參數；User 則只能使用被允許的密碼服務。這個要求看起來像軟體權限管理，但硬體產品也要反映在命令集、debug port、管理介面、factory mode 與 secure boot policy 上。
Level 2 很適合企業級防火牆、VPN 設備、入門 HSM、網通設備等。它提供比 Level 1 更好的稽核可信度，但還不是「抗物理入侵」等級。換句話說，LV2 的證據是「你拆過我知道」，不是「你拆我也拿不到」。
6. Level 3：依封裝與適用條款保護秘密
Level 3 的實體要求依模組封裝與適用條款而定。NIST CMVP IG 7.A Table 2 區分外殼硬度、孔洞探測防護，以及門蓋或維修存取的反應要求；不能一律解讀為所有攻擊都有主動偵測與反應。設計可用偵測與反應保護 CSP；需要 zeroization 時，要驗證方法、範圍、觸發與完成指示。刪除軟體引用不證明所有副本不可恢復，也不能從 Level 3 推論能抵擋每種實體攻擊。
身份認證也從角色提升到個人。不是只知道「你是 User 還是 Crypto Officer」，而是要知道「你是哪一個被授權的人」。因此可能用密碼、token、憑證、生物辨識或 2FA，搭配權限與 audit trail。
Trusted channel 是另一個硬體 RD 要特別注意的地方：明文 CSP 進出不能走一般資料通道，要走專用、可信、實體隔離或受保護的通道。這會影響 pin mux、debug interface、secure provisioning、factory personalization、HSM key injection port 的設計。
EFP 或 EFT 處理適用範圍內的溫度與電壓條件。EFP 是環境失效保護，EFT 是環境失效測試。不要把這兩項直接擴張成所有 clock glitch、雷射或電磁故障注入都已被測試或阻擋。其他故障仍要依條款、模組 Security Policy 與威脅模型逐項判讀。
7. Level 1/2/3 對照：LV3 不是貼貼紙，是從設計開始
第七頁把 Level 1、Level 2、Level 3 放在同一張表上看，最重要的是不要把 LV3 誤會成 LV2 加一張防拆貼紙。tamper mesh、感測器、PUF／OTP、secure boot、zeroization 與 self-test 都可能是設計選項。這些元件不是所有 Level 3 模組必備的固定清單。選了哪些措施，要看模組類型、邊界、適用要求與威脅。元件之間的觸發、錯誤狀態和 SSP 處理也要有測試證據。
FIPS 140-3 的架構包含 non-invasive security，但不能只看章名推論已強制進行每種側通道測試。依 2026-08-19 CMVP IG，相關要求在 SP 800-140F 定義前尚不適用；非侵入式防護主張目前依「其他攻擊緩解」等適用指引處理。SP 800-140F 現行版仍未列出新增測試要求。
功耗、電磁與 timing 洩漏仍是設計風險。封裝防拆不會自動阻止外部量測。團隊要說明防護主張、測試方法與限制，並核對現行指引和 Security Policy。取得 Level 3 或 Level 4 證書，不代表已證明能抵擋所有側通道。
若目標是 Level 3，先由 threat model、模組封裝與適用要求決定設計，再評估 sensor placement、shielding、routing、randomization、masking、secure erase path、debug disable 與 test mode lock。EFP 或 EFT 應依所採路徑提供證據；EFT 不等於必須持續主動監測環境。後期補救通常昂貴，而且常常補不到 certification 需要的證據鏈。
8. 避坑指南：等級不是軍備競賽，而是威脅模型的最佳解
最後一頁整理四個大坑。第一，「用了 AES」不等於 FIPS；第二，「改一行 code」或改 BOM、硬體版本、韌體版本，都可能牽動重新評估；第三，「三個月拿證」通常不現實；第四，「等級越高越好」也不一定對，因為成本、時程與風險要平衡。
正確決策流程應該從合約與威脅模型開始。如果客戶或法規指定等級，就照指定等級規劃。如果沒有指定，就問攻擊者拿不拿得到設備：純軟體或攻擊者碰不到內部模組，Level 1 可能足夠；設備在機房、網路或管理場域，且需要角色分離與留痕，Level 2 常是合理選項；設備會落入攻擊者手中，例如支付終端、智慧卡、邊緣設備、軍規或國防安全晶片，Level 3 才值得投入。
對半導體團隊來說，最實用的結論是：FIPS 140-3 不是驗功能，而是驗整個密碼模組在生命週期內是否可信。越早把模組邊界、SSP 管理、測試模式、debug port、production provisioning、secure boot、side-channel countermeasure、文件證據一起設計好，後面越不會被認證流程反咬。
如果模組內使用 PUF、OTP、secure NVM 或硬體 root of trust，也要注意「primitive」和「validated module」的差別。以 eMemory NeoPUF 為例，它可以支援晶片唯一身分、不可預測回應、authentication、security key generation 等安全用途；但放進 FIPS 140-3 專案時，驗證重點會變成：NeoPUF 產生或保護的 secret 是否在模組邊界內？helper data 或 enrollment data 是否暴露敏感資訊？key 如何被 derive、使用、zeroize？self-test 或 health check 如何定義？這些才是 FIPS 會追問的工程證據。
所以，把 NeoPUF、TRNG、OTP、AES、SHA、secure boot ROM 都列在 block diagram 上還不夠。FIPS 140-3 會要求團隊把這些元件串成一個可被驗證的生命週期：製造、enrollment、personalization、field operation、firmware update、tamper response、error state、退役與金鑰清除。這也是硬體安全 IP 和認證工程真正交會的地方。
一句話收斂
FIPS 140-3 驗證有明確邊界與版本的密碼模組。採購時要查證書狀態、Security Policy、操作環境與 approved mode。選等級則要看合約、部署場景與攻擊者能力；一句「用了 AES」或一張演算法證書，都不足以支持模組驗證的主張。
官方文件與參考連結
這篇文章是工程解讀；正式規格、驗證要求與清單仍以 NIST / CMVP 官方文件為準。做產品規劃或客戶回覆時，建議直接引用以下來源：
- NIST SP 800-140F：non-invasive test metrics 的現行文件，須與最新 CMVP IG 一起讀。
- CMVP Implementation Guidance（2026-08-19）：包括 1.B、3.4.A、7.A、9.7.B 與 12.A 的適用範圍。
- FIPS 140-3 Standards, Implementation Guidance, Derived Test Requirements：NIST CMVP 彙整的 FIPS 140-3 標準、Implementation Guidance 與測試要求入口。
- Cryptographic Module Validation Program, CMVP：NIST 的密碼模組驗證計畫首頁，說明 CMVP 驗證框架與相關資源。
- FIPS 140-3 Transition Effort：FIPS 140-2 到 FIPS 140-3 的轉換時程與政策說明。
- Validated Modules：已驗證密碼模組清單，可查 certificate、vendor、module name、standard 與 validation status。
- CMVP Module Validation Lists：包含 modules in process、validated modules、historical modules 等清單入口。
- Cryptographic Algorithm Validation Program, CAVP：演算法驗證計畫。CAVP 是演算法層級，CMVP 是模組層級，兩者不要混在一起看。
- eMemory NeoPUF：eMemory 官方 NeoPUF 產品頁，說明 NeoPUF 基於矽製程中的 physically unclonable variations，並可用於 identification、authentication、security key generation 等安全應用。
- PUFsecurity, NeoPUF, A Reliable and Non-traceable Quantum Tunneling PUF：補充 NeoPUF 與 SRAM PUF 在可靠度、traceability 與讀取機制上的技術差異。
互動練習：AES 算對了，服務就能放行嗎？
用一張明確虛構的模組紀錄，分開檢查證書狀態、版本、操作環境、邊界、approved mode 和自檢。自檢失敗會進入 ERROR_LATCHED，即使其他條件通過，也不提供模型中的服務。
此頁與瀏覽器密碼運算沒有 CMVP 驗證。本表只呈現採購核對與服務閘門；不是 FIPS 140-3 完整測試、正式 Security Policy 或真實 certificate lookup。Historical 在此保守的新系統案例中拒絕；既有系統用途須依官方政策與採購要求另判。不把演算法證書當成模組證書。
學習指南
安全保證與產品生命週期
查看課程大綱 → · 進度只計入已發布課程
先備知識
- 密碼服務與模組邊界
我學會了什麼
- 說明驗證涵蓋範圍
- 比較安全等級
- 辨識邊界與金鑰管理風險