盡管“密碼機制”長期以來始終是一個頗具技術性的話語表達，但如果從政策決策的角度觀察，符合特定管理目標及價值訴求的“密碼機制”仍然構成了整個密碼規范體系的基石，其決定了密碼體制的分層結構（例如我國的分類分級管理）、目的、對象和方法。“密碼機制”的基本思想是對機密信息進行“偽裝”，阻卻未經授權的訪問、篡改和披露。
2016年8月，美國國家標準與技術研究院（NIST）發布《聯邦政府使用密碼標準指南：密碼機制》（Guideline for Using Cryptographic Standards in the Federal Government:Cryptographic Mechanisms，SP800-175B），正式取代2005年發布的SP800-21第二版《聯邦政府實施密碼術指南》（SP 800-21 Second edition，Guideline for Implementing Cryptography in the Federal Government）。
SP800-175B是為解決密碼算法和密鑰的安全性，以及相對分散的密碼標準給密碼使用帶來的巨大挑戰。該標準旨在將聯邦機構所使用的加密方法限制為符合聯邦信息處理標準（FIPS）和NIST特殊出版物（SPs）的加密方法，為聯邦政府在傳輸和存儲期間使用加密技術保護其“敏感非涉密”的數字化信息提供指導。同時，NIST特別指明，該標準不適用國家安全系統，這也體現了“國家安全例外”的原則和理念。2020年3月，為了適應密碼技術的快速發展，NIST對SP800-175B進行修訂。在新版本中，NIST旗幟鮮明地指出，在當今日益開放和互連的系統、網絡和移動設備的環境中，密碼的正確、有效、合規使用對于維護網絡和數據安全至關重要。
SP800-175B是SP800-175系列標準中的一部分，在第24期簡報《NIST SP800-175A：美國聯邦政府使用相關法律指引概述》中，我們對SP800-175A進行了概述，提供了有關確定使用密碼要求的指導，包括保護聯邦政府敏感信息的法律法規、風險評估指南，以確定需要保護的內容以及如何更好地保護該信息。作為其“姐妹篇”，SP800-175B更為側重討論可用于保護聯邦政府敏感信息的加密方法和服務，并概覽了NIST的加密標準。本簡報針對NIST所闡明的“密碼機制”基本要素，著重對SP800-175B第4部分“密碼服務”和第5部分“密鑰管理”進行梳理概述。基本內容如下：
4.密碼服務
4.1數據保密
以下文件規定了批準的加密操作模式：
1）適用于AES和TDEA的SP800-38A，包括電子碼本（ECB），密碼塊鏈接（CBC）、密碼反饋（CFB）等模式。
2）適用于AES的SP 800-38E，包括XTS-AES模式。
3）適用于AES的SP 800-38G，包括用于保存格式加密的FF1和FF3模式。
4.2數據完整性、身份認證和來源認證
4.2.2.1基于分組密碼算法的MAC
1）SP800-38系列出版物包括生成MAC的模式。
2）SP800-38B定義了使用AES和TDEA分組密碼算法計算MAC的CMAC模式；有關不推薦使用的TDEA，請參見第3.2.1.2節。
3）SP800-38D定義了使用AES計算MAC的GMAC模式。
4.2.2.2基于哈希函數的MAC
1）FIPS198定義了一種結合使用加密散列函數和密鑰的MAC（HMAC）。HMAC必須與經批準的加密散列函數一起使用（參閱第4.2.1節）。
2）SP800-107討論了與使用HMAC相關的安全性問題。
3）SP800-185定義了一種基于FIPS202中指定的可擴展輸出函數的MAC算法（KMAC），并詳細說明了KMAC的兩種變體KMAC128和KMAC256的安全性問題。
4.3在分組密碼操作模式中結合保密和認證
AES定義了兩種經過身份驗證的加密模式，SP800-38C規定了CCM模式，SP800-38D規定了GCM模式。
4.4隨機位生成
1）SP800-90A規定了基于使用散列函數和分組密碼算法的經批準的DRBG算法，DRBG必須從隨機性源（例如熵源或NRBG）初始化。
2）SP800-90B討論熵源，包括確定熵源未失效所需的健康測試以及由認證實驗室驗證熵源的測試。
3）SP800-90C根據SP800-90A中的算法和根據SP800-90B設計的熵源，為NRBGs和DRBGs的設計和實施提供構造。NRBG的構造包括來自SP800-90A的DRBG算法。
4）SP800-22討論了選擇和測試隨機數和偽隨機數生成器的一些問題。對于聯邦申請，必須驗證RBG是否符合FIPS140和SP800-90的要求。
5.密鑰管理
5.1一般密鑰管理指南
SP800-57、FIPS140以及SP800-131A等出版物均為密鑰管理提供指引。
5.1.1密鑰管理建議
SP800-57為密鑰和相關信息管理提供一般性指南，涵蓋密鑰和相關信息的生成、使用與銷毀等階段，主要探討算法選擇、適當密鑰長度和加密政策等問題，由三部分組成。
1）SP800-57，一般性指南，包含基本密鑰管理指引，包括：
密鑰材料所需保護；
密鑰生命周期職責；
密鑰備份、歸檔和恢復；
密鑰變更；
加密周期（即使用密鑰的適當時間長度）；
問責制與審計；
密鑰庫；
應急計劃；
密鑰泄露恢復（例如，通過生成新密鑰）。
聯邦機構擁有大量需要加密保護的信息，不同信息的敏感程度和保護期限也各不相同。為此，NIST分別設立112位、128位、192位和256位的四級安全強度以滿足不同信息的安全保護需求，使其與已獲批準的加密算法和密鑰尺寸相匹配，并預測安全的使用日期。詳情請參閱SP800-131A。
在選擇具有適當安全強度的算法和密鑰尺寸之前，聯邦機構應首先明確數據加密保護期限。
請注意，SP800-57內容是根據其指引之時效性不斷更新的。
2）SP800-57，密鑰管理組織最佳實踐，包括：
確定對稱和非對稱密鑰管理有效系統的共有概念、功能和元素；
確定有效機構密鑰管理所需的安全規劃要求和文件；
描述密鑰管理規范要求；
描述使用加密的組織所需的加密密鑰管理策略文檔；
描述密鑰管理實踐聲明要求。
3）SP800-57，應用程序密鑰管理指南，解決與當前可用的密碼機制相關的密鑰管理問題，涉及公鑰基礎設施（PKI）、互聯網協議安全（IPsec）、安全/多部分Internet郵件擴展（S/MIME）、Kerberos、無線密鑰更新（OTAR）、域名系統安全擴展（DNSSEC）、加密文件系統和安全殼（SSH）協議等領域，并提供以下方面的具體指導：
推薦和/或允許的算法套件以及密鑰尺寸；
使用當前機制進行聯邦政府信息保護的相關建議；
影響密鑰管理過程有效性及加密機制的安全考量。
需要注意的是，傳輸層安全（TLS）協議包含在文檔的原始版本中，但是，第3部分現在僅引用了討論TLS的單獨文檔（參見SP800-52）。
伴隨新的密鑰管理技術和機制的持續性發展，現有密鑰管理機制和技術也在不斷完善。雖然第3部分中包含的安全指導信息將隨著機制和技術的發展而不斷更新，但可預期的是新產品和技術規范不會反映在當前版本的文檔中。因此，本文可能會包含一些狀態信息，例如版本編號或實施狀態。
5.1.2 密碼模塊的安全要求
FIPS140為在聯邦信息系統中包含或支持密碼術的密碼模塊提供最低安全要求。密碼模塊為保護敏感信息的安全系統執行實際的密碼計算。安全要求涵蓋與密碼模塊的安全設計與實施相關的領域，包括模塊規范；密碼模塊端口和接口；角色、服務和身份驗證；有限狀態模型；人身安全；操作環境；加密密鑰管理；電磁干擾/電磁兼容性（EMI/EMC）；自測；設計保證；減輕攻擊等內容。
FIPS140適用于所有使用密碼術來保護計算機和電信系統中敏感信息的聯邦機構。
5.1.3新的密碼算法和密鑰長度的過渡
隨著SP800-57的開發與發布，由于算法中斷或可用于有效搜索加密密鑰的更強大計算機的可用性，NIST提供了過渡到新加密算法和密鑰長度的建議。
SP800-131A旨在為此類轉換提供更具體的指導。每個算法和服務都可在SP800-131A中得到解決，指出其使用是否可接受、已棄用、僅允許用于遺留應用程序，或不允許使用。
請注意，SP800-131A會在必要時更新（例如，為不再提供足夠安全性的算法提供轉換時間表）。
5.2密鑰管理系統
當前一系列出版物為密鑰管理系統的開發提供指南，例如SP800-130（參見第5.2.1節）、SP800-152（參見第5.2.2節），與用于非對稱密鑰加密的公鑰基礎設施相關的文件（參見第5.2.3節）。
加密密鑰管理系統（CKMS）包括用于保護、管理和分發密鑰信息的策略、程序、組件和設備。CKMS包括可以訪問密鑰或與其關聯的其他信息的所有設備或子系統。這些設備可以是計算機、手機、平板電腦或其他智能設備，例如汽車、警報系統甚至冰箱。
5.2.1密鑰管理框架
SP800-130包含CKMS設計人員在開發CKMS設計規范時應考慮的主題，涵蓋安全策略、加密密鑰和元數據、互操作性和轉換、安全控制、測試和系統保證、災難恢復和安全評估等內容。
對于每個主題，SP800-130都明確一個或多個需要由設計人員解決的文檔要求。SP800-130旨在幫助：
通過要求重要的CKMS功能規范，來定義CKMS設計；
鼓勵CKMS設計者考慮綜合CKMS所需的因素；
從邏輯上比較不同的CKMS及其功能；
通過要求實施和支持的CKMS功能的規范，來執行安全評估，以及為開發配置文件奠定基礎，這些配置文件規定了組織要使用的CKMS具體要求。
5.2.2 密鑰管理系統簡介
SP800-152包含美國聯邦組織及其承包商對CKMS的設計、實施、采購、安裝、配置、管理、操作和使用的要求。該配置文件是基于SP800-130（參見上第5.2.1節）。SP800-152明確一系列要求，為具有特殊安全需求并希望增強基本安全和密鑰管理服務的聯邦組織提出建議。
在提供需納入CKMS設計的要求之外，SP800-152還規定了針對由服務提供商運營的聯邦CKMS（FCKMS）的要求，該服務提供商可能是聯邦機構或根據合同運營FCKMS第三方一個或多個聯邦機構及其承包商。
此配置文件旨在：
協助CKMS設計者和實施者支持適當的密碼算法和密鑰，選擇與密鑰關聯的元數據，以及選擇用于保護敏感的美國聯邦計算應用程序和數據的協議；
建立對FCKMS的測試、采購、安裝、配置、管理、操作、維護和使用的要求；
通過分析一個CKMS的設計和實現，促進一個CKMS與另一個CKMS的簡易比較，以了解每個CKMS如何滿足框架（即SP800-130）和概要（例如，SP800-152）要求；
協助了解評估、采購、安裝、配置、管理、操作和使用FCKMS所需的內容，該FCKMS管理用于保護美國聯邦組織獲取、處理、存儲和使用敏感和有價值數據的關鍵信息，以及他們的承包商。
5.2.3公鑰基礎設施
PKI（Public Key Infrastructure，公鑰基礎設施）是一種安全基礎設施，通過創建和管理公鑰證書以促進公鑰（即非對稱密鑰）密碼術的使用。為了實現這個目標，PKI需要執行兩個基本任務：
生成并提供公鑰證書，在驗證要綁定的信息的準確性后，將公鑰綁定到與相應私鑰的所有者相關聯的標識符和其他所需信息；
維護和提供未過期和吊銷證書的證書狀態信息。
通常需使用兩種類型的證書：用于提供用于驗證數字簽名的公鑰的證書，和用于提供用于密鑰建立的公鑰的證書。每個與數字簽名相關的證書都提供FIPS186中批準的數字簽名算法之一的公鑰：DSA、ECDSA、EdDSA或RSA。傳遞用于密鑰建立的公鑰的證書可能有兩種類型：提供密鑰協議公鑰的證書（參見第5.3.3節）和提供密鑰傳輸公鑰的證書（參見第5.3.4節）。證書中的密鑰使用位指示公鑰的使用目的。
任何人都可以使用公鑰，但是，私鑰必須保密，并且只能由擁有并被授權使用私鑰的實體使用。實體可以是個人、組織、設備或過程，包括網絡服務器。對于非人類實體（例如，設備或流程），指派一名或多名人員作為該實體的代表或發起人，以管理其關鍵信息；一旦進入系統，代表或贊助商不應訪問任何密鑰信息。在這種情況下，私鑰的所有者（例如，設備或進程）與證書的所有者（即人類代表或發起人）不同。
依賴方是依賴證書和頒發證書的CA來驗證證書所有者的身份和證書中公鑰、相關算法和任何相關參數以及私鑰的有效性的實體，且私鑰所有者擁有相應的私鑰。
私鑰丟失或泄露有以下影響：
如果用于生成數字簽名的私鑰丟失，所有者將無法再生成數字簽名。某些策略可能允許維護私鑰的備份副本以保持操作的連續性，但不鼓勵這樣做，因此替代方法是簡單地生成新的密鑰對和證書；
如果用于生成數字簽名的私鑰被泄露，依賴方將無法再信任使用該私鑰生成的數字簽名（例如，有人可能使用該簽名提供虛假信息）；
如果用于密鑰建立的私鑰丟失（例如，用于密鑰傳輸或密鑰協商的密鑰），則在恢復或替換密鑰之前無法完成進一步的密鑰建立過程。如果需要使用密鑰來恢復受密鑰保護的數據，則除非可以恢復密鑰，否則該數據將丟失。例如，如果密鑰用于傳輸加密數據的解密密鑰，并且密鑰丟失，則無法解密加密的數據。為了確保對關鍵數據的訪問不會丟失，PKI通常會備份私鑰建立密鑰以備可能的恢復；
如果用于密鑰建立的私鑰被泄露，則任何涉及該密鑰的交易都不能被信任（例如，除私鑰真正所有者之外的其他人可能會為了某些非法目的而試圖進入一個所謂的“安全”交易）。
5.3 密鑰建立
密鑰建立是一種生成密鑰并將其提供給被授權實體的方式。密鑰建立相關的實施場景包括以下內容：
單個實體可生成（參見第5.3.1節）并使用密鑰，而無需將其提供給其他實體（例如，用于保護本地存儲的數據）；
密鑰可以從已經在兩個或多個實體之間共享的密鑰再派生出來（參見第5.3.2節）；
兩個實體可以使用每個實體的輸入（即數據）生成一個密鑰，使用包含密鑰協議方案的自動化協議（參見第5.3.3節）；
單個實體可以生成密鑰并將其提供給一個或多個其他實體，無論是通過手動方式（例如，快遞或以印刷或電子形式與密鑰面對面會面，例如在閃光燈上驅動器）或使用包含密鑰傳輸方案的自動化協議（參見第5.3.4和5.3.5節）；
單個實體可以生成密鑰并將其提供給一個或多個其他實體，以通過人工方式（例如快遞或者紙質或電子形式面對面會面，比如使用閃存驅動），或使用包含密鑰傳輸方案的自動化協議（參見第5.3.4和第5.3.5節）。
5.3.1密鑰生成
大多數加密算法都需要使用密鑰，但哈希函數不用作另一個加密過程（例如HMAC）組件的情況除外。SP800-133討論了與批準的加密算法一起使用的密鑰生成相關問題。
所有密鑰必須直接或間接地基于經批準的隨機位生成器（RBG）的輸出在FIPS140驗證的密碼模塊中生成（參閱FIPS140）。模塊所需的所有隨機值都必須在密碼模塊中生成。
SP800-133提供了直接從RBG生成密鑰的指南，并參考了其他出版物以獲取為特定算法生成密鑰所需的附加信息：
FIPS186提供了用于生成數字簽名的密鑰對規則；
SP800-108提供了通過預共享密鑰生成（新）密鑰的方法途徑（另見第5.3.2節）；
SP800-56A規定了生成Diffie-Hellman和MQV（Menezes?Qu?Vanstone）密鑰協議方案的密鑰對的規則（另見第5.3.3節）；
SP800-56B規定了為RSA密鑰協商和密鑰傳輸方案生成密鑰對的規則（另見第5.3.3和第5.3.4節）；
SP800-132指定了從密碼生成密鑰的規則。
5.3.2密鑰導出
密鑰導出與從秘密信息生成密鑰有關，盡管在生成過程中除了秘密信息之外還可以使用非秘密信息。通常，秘密信息在需要為后續交互導出相同密鑰的實體之間共享。秘密信息可以是實體之間已經共享的密鑰（即，預共享密鑰）或在密鑰協商方案期間導出的共享秘密（參見第5.3.3節）。
SP800-108指定了幾個使用預共享密鑰的密鑰導出函數。預共享密鑰可能是：
由一個實體生成并通過某種手動方式（例如，快遞或面對面會議）提供給一個或多個其他實體；
由實體使用自動密鑰協商方案達成一致（參見第5.3.3節）；
由一個實體生成并使用自動密鑰傳輸方案提供給另一個實體（參見第5.3.4節和第5.3.5節）；
SP800-56C和SP800-13584提供了從密鑰協商期間生成的共享秘密中導出密鑰的方法（參見第5.3.3節）。
5.3.3密鑰協議
密鑰協商是一個密鑰建立過程，其中生成的密鑰材料是密鑰協商過程中所有參與者貢獻的信息的函數，因此任何參與者都不能獨立于其他參與者的貢獻預先確定生成的密鑰材料的價值。密鑰協商通常使用自動協議執行。
SP800-56A和SP800-56B提供了幾種自動化的成對密鑰協商方案（即涉及兩方的密鑰協商方案）。對于每個方案，都會生成一個共享機密，并使用SP 800-56C中指定或批準的密鑰導出方法從共享機密中導出密鑰材料。
SP800-56A和SP800-56B包含不同的密鑰協商方案，在密鑰數量、密鑰狀態（長期的還是短暫的）等方面有所不同。密鑰協商方案有兩個參與實體：發起者和響應者。
5.3.4密鑰傳輸/密鑰分發
密鑰傳輸是一種一方（發送方）生成密鑰并將其分發給一個或多個其他方（接收方）的方法。這里可以使用手動方法（例如，使用快遞）或使用自動協議來完成密鑰傳輸。SP800-56B提供了使用RSA的自動成對密鑰傳輸方案以及對每個密鑰傳輸方案提供的安全屬性的分析。SP800-7185提供了分發受對稱密鑰分組密碼算法（例如AES）保護的密鑰材料的方案。
5.4密鑰管理問題
選擇和使用CKMS需要解決一系列問題。
5.4.1手動密鑰建立與自動密鑰建立
如第5.3節所述，可以使用手動或自動方法在實體之間建立密鑰。在很多情況下，使用混合方法，其中一個實體生成一個或多個密鑰并將其手動分發給其他實體，然后這些密鑰用于建立其他密鑰（見SP800-56A、SP800-56B和SP800-71）。
要手動分發的密鑰數量取決于要使用的密碼術類型（即對稱或非對稱方法），并且在選擇CKMS所需的功能時必須考慮。
5.4.2 CKMS的選擇和操作
CKMS可以由將使用它的組織設計、實施和運行。組織可以運行從供應商處采購的CKMS，或者組織可以采購從供應商處采購CKMS的第三方的服務。無論做出何種選擇，組織都需要確保使用的CKMS提供組織信息所需的保護。SP800-130和SP800-152討論了聯邦組織需要解決的注意事項，包括CKMS的可擴展性和與密鑰關聯的元數據。
5.4.3 存儲和保護密鑰
密鑰可以存儲在多個位置并以多種方式進行保護。密鑰可以存放在保險箱中；可出現在經過驗證的密碼模塊中，其中模塊本身可以根據其設計充分保護密鑰；也可存儲在電子媒體上，例如閃存驅動器，在這種情況下，可能需要對密鑰進行包裝（即加密并對其完整性進行保護）或將其拆分為密鑰組件，以確保其機密性。
某些密鑰可能需要備份，以便在操作密鑰無意中丟失或修改時，可以恢復它并恢復操作。某些密鑰可能還需要存檔以進行長期存儲（例如，由于法律要求或解密存檔數據）。每當備份或存檔密鑰時，都需要密鑰恢復功能。需要設計此功能，以便可以在可接受的時間內恢復密鑰，并且只能由獲得授權的實體進行恢復；有關密鑰備份、密鑰歸檔以及備份和歸檔密鑰恢復的更多信息，請參閱SP800-57，第1部分。
5.4.4加密周期
加密周期是授權使用特定密鑰的時間長度。為密鑰制定、分配加密周期的原因有很多，例如在密鑰被泄露時限制加密數據的暴露量。加密周期通常是根據經過周密考慮的時間段或密鑰保護的最大數據量來分配的。與確定加密周期相關的考量涉及數據暴露的風險和后果。SP800-57的第5.3節更詳細地討論了建立加密周期的必要性、決定合適的加密周期時要考慮的因素，以及有關加密周期長度的一些建議。
5.4.5使用經過驗證的算法和密碼模塊
必須在FIPS 140驗證的密碼模塊中驗證和實施加密算法。大多數具有加密功能的IT產品都聲稱其產品的功能和/或提供的安全性。在保護敏感數據時，在這些產品中使用FIPS140驗證的密碼模塊可提供最低級別的保證，即產品聲明的安全聲明是有效的。
聯邦機構、私營企業和公眾依靠密碼術來保護電子商務、關鍵基礎設施和其他應用領域中使用的信息和通信。提供加密服務的所有產品的核心是密碼模塊。包含加密算法的密碼模塊用于產品和系統中，以提供機密性、完整性和身份驗證等安全服務。盡管使用密碼術來提供安全性，但設計不佳或算法薄弱等弱點可能會使產品不安全并使高度敏感的信息處于危險之中。根據既定標準對密碼模塊及其底層加密算法進行充分測試和驗證對于提供安全保證至關重要。
NIST已制定程序來驗證已批準的密碼算法和使用它們的密碼模塊的實施：密碼算法驗證程序（CAVP）和密碼模塊驗證程序（CMVP）。
有關密碼模塊的安全要求的討論，請參閱第5.1.2節。
5.4.6密鑰材料控制
對密鑰的訪問需要被控制。密鑰只能由授權實體訪問，并且只能用于授權的目的。例如，指定用于密鑰傳輸的密鑰不得用于生成或驗證數字簽名。
還需要控制密鑰的擴散。雖然制作密鑰的副本通常很方便，但需要考慮這些額外的副本控制。如果密鑰被泄露，則可能需要銷毀該密鑰及其所有副本，以防止后續未經授權的使用。例如，如果用于生成數字簽名的私鑰被泄露，并且在原始副本銷毀后該密鑰的副本仍然存在，則該副本在之后有可能被用于生成未經授權的數字簽名。
應向用戶提供一份責任和義務清單，每個用戶在收到密鑰之前應簽署一份聲明承認這些問題。必須讓用戶意識到他們的獨特責任，尤其是關于密鑰泄露或丟失的重要性。用戶必須能夠安全地存儲他們的秘密和私有密鑰，這樣任何入侵者都不能訪問它們，而且這些密鑰必須易于合法使用。
5.4.7泄露
必須制定計劃來處理密鑰的泄露或可疑泄露風險，特別是那些在中央站點使用和管理的密鑰（例如CA用于簽署證書的密鑰）。應在系統投入運行之前制定受損恢復計劃，并應說明對受損系統軟件和硬件、CA密鑰、用戶密鑰、先前生成的簽名、加密數據等將采取的措施。SP800-57第1部分包括對密鑰泄露的影響的討論，如何將密鑰泄露的可能性或后果降至最低的措施，以及在制定泄露恢復計劃時應考慮的因素。
如果某人的私鑰或秘密密鑰丟失或泄露，則必須讓其他用戶意識到這一點，以便他們不再使用已泄露的密鑰啟動數據保護或接受用泄露的密鑰保護的數據，而無需評估和接受這樣做的風險。此通知通常使用證書吊銷列表（CRL）或受損密鑰列表（CKL）來完成。有關討論參見SP800-57第1部分。
在某些情況下，應在檢測到密鑰泄露后立即銷毀密鑰和密鑰的所有副本。例如，用于生成數字簽名的私鑰應立即銷毀。然而，相應的公鑰可能需要保持可用以驗證先前使用泄露的私鑰生成的簽名。并且需要注意，接受這些簽名會存在相關風險。
5.4.8問責制和庫存管理
問責制涉及識別那些在整個生命周期中有權訪問或控制加密密鑰或證書的實體。問責制可以成為幫助防止密鑰泄露的有效工具，在檢測到泄露時減少泄露的影響，確定發生泄露時可能涉及的個人，以阻止密鑰泄露，因為用戶知道他們對密鑰的訪問是已知的，以及確定在何處使用密鑰，以及哪些數據或其他密鑰受到泄露密鑰的保護，因此也可能被泄露。當使用公鑰證書時，問責制用于確定誰負責證書維護（例如，證書過期或私鑰被泄露時的證書更換）。
使用密鑰或證書清單可以成為協助問責的工具。庫存管理涉及建立和維護密鑰和/或證書的庫存；分配和跟蹤他們的所有者、代表或發起人（例如，他們是誰或他們是什么，他們在哪里，以及如何聯系他們）；自動將密鑰和證書輸入庫存；監控密鑰和證書狀態（例如，到期日期和密鑰是否已被泄露）；并在需要時將狀態報告給適當的官員以采取補救措施。SP800-57，第1部分提供了有關密鑰和證書庫存管理的討論。
5.4.9審計
審計是一種用于密鑰泄露預防、檢測和恢復的機制。需要執行下列類型的審計以確保正確的密鑰管理：
合規審計是對組織遵守監管準則的全面審查。合規審計員審查安全政策（例如，密鑰管理政策）以及用戶訪問控制和風險管理程序，以確定這些控制和程序支持這些政策；
需要對所采用的保護機制（例如，使用的密碼算法和密鑰長度）進行審核，以重新評估當前提供的，以及預期需要和將來提供的安全級別。這需要確定保護機制正確有效地支持適當的政策（例如，密鑰管理政策）。同時也需要考慮新技術的發展和攻擊；
需要對使用、操作和維護密鑰管理系統的人員的行為進行審核，以驗證人員繼續遵循既定的安全程序。高度不尋常的事件被記錄并審查，作為對系統嘗試攻擊的可能預測。
