密钥管理

**金鑰管理**（**Key management**）是一個密碼系統中加密金鑰的管理部分。它包括金鑰的生成、交換、儲存、使用、金鑰銷毀以及金鑰更替的處理，涉及到密碼學協定設計、金鑰伺服器、使用者程式，以及其他相關協定。

金鑰管理關注使用者層面或使用者與系統之間的金鑰，這與金鑰排程不同，金鑰排程通常指密碼內部輪運算中內部金鑰的生成和處理這一過程。

成功的金鑰管理對密碼系統的安全性至關重要。金鑰管理在某種意義上比純數學的密碼學更加具有挑戰，因為它涉及到系統策略、使用者培訓、組織和部門的相互作用，以及上述所有元素之間的協調，而這些過程往往和密碼學的其他元件不同，因為這些過程無法自動完成。

## 金鑰類型

加密系統可能使用多種金鑰，其中可能包括對稱金鑰與非對稱金鑰。在對稱密鑰加密演算法中，用於加密與解謎訊息的金鑰是相同的。這些金鑰必須被慎重選擇、分發和安全儲存。非對稱金鑰也稱公開金鑰加密，它的重要特點是有公鑰與私鑰這兩個金鑰，常被用於網際網路通信。

## 庫存

任何憑證和私鑰管理策略的起點都是建立所有憑證的位置和責任方的全面清單。這不是一件微不足道的事情，來自各種來源的憑據被不同個人和團隊部署在各種地點 —— 這不可能簡單依賴於單個數位憑證認證機構的列表，在到期前沒有被更新或替換的憑證可能導致嚴重的停機和中斷。以及其他考慮：
法規和強制要求，例如 PCI-DSS，要求嚴格的安全性、加密金鑰管理以及稽核員，審查日益增長的使用中的管理控制和流程。

* 用於憑證的私鑰必須安全儲存，否則未經授權的人員可能攔截機密通信或非授權地介入關鍵系統。不能確保適當的職責分離意味著生成加密金鑰的管理員可以使用它們來存取敏感、受監管的資料。
* 如果憑證頒發機構受到威脅或者加密演算法遭受破解，組織必須準備好在幾小時內替換所有的憑證和金鑰。

## 管理步驟

在金鑰被簽發後，金鑰管理一般有三個步驟：交換、儲存和使用。

### 金鑰交換

進行安全通訊之前，各使用者間需要確立加密程式的細節，尤其是密鑰。在對稱密鑰加密系統，各使用者間需要確立共同使用的單一密鑰，此步驟即密鑰交換。交換對稱密鑰必須透過另一安全的通訊管道進行；否則，如果以明文形式在網路傳送，將使竊聽者能夠立即得知密鑰以及據其加密的數據。以前，交換密對稱密鑰是非常麻煩的，可能需要使外交郵袋等安全管道。

公開金鑰加密的出現大大減輕了交換對稱密鑰的困難，公鑰可以公開（透過不安全、可被竊聽的管道）傳送，用以加密明文。不過，公鑰加密在在計算上相當複雜，效能欠佳、遠遠不比對稱加密；因此，在一般實際情況下，往往通過公鑰加密來隨機建立臨時的對稱秘鑰，亦即對話鍵，然後才通過對稱加密來傳輸大量、主體的資料。

It is possible, using something akin to a book code, to include key indicators as clear text attached to an encrypted message. The encryption technique used by Richard Sorge's code clerk was of this type, referring to a page in a statistical manual, though it was in fact a code. The German Army Enigma symmetric encryption key was a mixed type early in its use; the key was a combination of secretly distributed key schedules and a user chosen session key component for each message.

Another method of key exchange involves encapsulating one key within another. Typically a master key is generated and exchanged using some secure method. This method is usually cumbersome or expensive (breaking a master key into multiple parts and sending each with a trusted courier for example) and not suitable for use on a larger scale. Once the master key has been securely exchanged, it can then be used to securely exchange subsequent keys with ease. This technique is usually termed Key Wrap. A common technique uses Block ciphers and cryptographic hash functions.

A related method is to exchange a master key (sometimes termed a root key) and derive subsidiary keys as needed from that key and some other data (often referred to as diversification data). The most common use for this method is probably in 智慧卡 based cryptosystems, such as those found in banking cards. The bank or credit network embeds their secret key into the card's secure key storage during card production at a secured production facility. Then at the Point of sale the card and card reader are both able to derive a common set of session keys based on the shared secret key and card-specific data (such as the card serial number). This method can also be used when keys must be related to each other (i.e., departmental keys are tied to divisional keys, and individual keys tied to departmental keys). However, tying keys to each other in this way increases the damage which may result from a security breach as attackers will learn something about more than one key. This reduces entropy, with regard to an attacker, for each key involved.

### 金鑰儲存

對稱加密使用的單一密鑰會被收發雙方儲存，公開金鑰加密的私鑰由於還有數位簽章的功能，所以都必須安全儲存，以保障通信安全。業界已發展出各種各樣的技術來保障密鑰得到妥善儲存，包括定期或不定的系統檢測是否有入侵之虞、對儲存媒體或伺服器提供高強度的物理防護及監控。最常見的是加密應用程式負責管理使用者的密鑰，使用密鑰時則需要輸入認別使用者的存取密碼。對於認證機構，一旦私鑰外洩，將可能導致整個信任鏈被摧毀，影響廣及眾多客戶，所以認證機構會使用硬體安全模組，有些儲存私鑰的電腦甚至平時不會連線，只在固定的排程下，經過一系列嚴謹的行政程式重重把關，才會取出私鑰為客戶簽章憑證。在信任鏈設計中，絕大部份的根憑證都不會直接為客戶簽章，而是先簽章一個（或多個）中繼憑證，再由中繼憑證為客戶簽章，這可以加強控管能力及控制一旦簽章私鑰被洩時的損失。

### 金鑰使用

密鑰的有效期限是一個重要問題，一個密鑰應該在產生後多久被汰換呢？密鑰汰換之後，舊有的密鑰就無法再解密新產生的密文，喪失對竊聽者的價值，這會增加了攻擊者所需要投入的氣力，所以密鑰應該經常替換。同時，這也可以減低資訊一旦被破解時的損失；因為竊聽者可能在破解密鑰之前一直儲存截取到的加密訊息，等待成功破解密鑰的一刻；所以密鑰更換得越頻密，竊聽者可解讀的訊息就越少。在過去，如果可靠的密鑰交換程式非常困難或者僅僅間歇可行，對稱密鑰會被長期使用。但在理想情況下，對稱密鑰應該在每次交換訊息或會話時轉換，使得如果某一密鑰被洩（例如，被盜竊，密碼分析或社會工程化）時，只有單一訊息或會話被解讀。基於公開金鑰加密的特性，一對公鑰和私鑰的有效期一般會長於對稱加密所使用的單一密鑰，尤其是需要認證機構簽核的電子憑證，當中涉及行政及部署成本，所以可能是三個月至一、兩年不等，考慮的因素包括配合加密演算法的金鑰長度、儲存私鑰的強度、一旦外洩可能引致的風險、更換程式對運行中的服務的影響、以及執行成本。

## 挑戰

IT 組織在控制和管理他們的加密金鑰時遇到的挑戰是：

1. 擴展性：需管理大量加密金鑰。
2. 安全性：外部駭客 / 惡意內部人員造成的金鑰隱患。
3. 資料可用性：需確保授權使用者可存取資料。
4. 支援性：需支援多種資料庫、應用程式和標準。
5. 治理：定義政策驅動的存取控制和資料保護。治理包括符合資料保護要求。

### 合規

金鑰管理的合規性是指監督、保證和證明金鑰得到了妥善管理。合規領域包括：

#### 實體安全

最基本顯見的合規形式，其中包括保護系統硬體裝置的門鎖、監控攝錄、登記每一次接觸系統硬體的人員姓名及時間。這些保護措施可以防止有人未經授權使用電腦系統，以列印密鑰副本，或運行密鑰管理軟體。而需要保護的硬體裝置包括運作中及備用的機器、儲存媒體、備份媒體、以及系統使用手冊。

#### 邏輯安全

在軟體應用上保障企業免受盜竊或未經授權的資訊存取。這就是一般所說的通過密鑰來加密數據，然後這些加密數據對那些沒有密鑰進行解密的人來便是無用。即使是加密後的數據也儘可能只給擁有相關權限的人員接觸到，這可能需要在物理上硬體層面、系統上的存取權限設定各方面配合。

#### 人事安全

這涉及特定角色及權限分配，無關的員工不會分配到權限、個別權限只會根據個別需要分配、相關員工只可以存取其工作必要的相關數據。對新入職員工可能需要進行背景審查，並定期重新審視權限、檢討角色、或在各人員之間調動崗位。

## 管理和合規體系

### 金鑰管理系統

金鑰管理系統（key management system，KMS）也稱密碼學金鑰管理系統（crytographic key management system，CKMS），是用於生成、分發和管理裝置和應用程式的金鑰的一種整合手段。與術語金鑰管理相比，KMS 針對特定用例進行了客製化，例如安全軟體更新、機器對機器通信。在整體來說，它涵蓋了安全性的所有方面 —— 從通過金鑰安全交換來安全生成金鑰，到客戶端安全金鑰的處理和儲存。因此，一個 KMS 包含用於金鑰生成、分發和替換的後端功能，以及用於注入金鑰、儲存和管理裝置上的金鑰等客戶端功能。隨著物聯網的發展，金鑰管理系統已成為互聯裝置安全性的關鍵部分。

#### 類型

下列是一些開放原始碼或專有的金鑰管理系統。

##### 開源

* Barbican, the OpenStack security API.
* KeyBox - web-based SSH access and key management.
* EPKS - Echo Public Key Share, system to share encryption keys online in a p2p community.
* Kmc-Subset137 - key management system implementing UNISIG Subset-137 for ERTMS/ETCS railway application.
* privacyIDEA - two factor management with support for managing SSH keys.
* StrongKey - open source, last updated on Sourceforge in 2013.
* Vault - secret server from HashiCorp.

##### 專有

#### 金鑰管理系統安全策略

金鑰管理系統安全策略提供了用於保護金鑰管理系統支援的金鑰和元資料的規則。根據國家標準技術研究所（NIST）的定義，該政策應制定和規定將保護資訊下列方面的規則：

* 保密
* 完整
* 可用
* 來源認證

這種保護涵蓋金鑰從生成到消亡的完整生命周期。

#### 帶入自己的加密 / 金鑰

帶入自己的加密 / 金鑰（Bring your own encryption，簡稱 BYOE），也稱 called bring your own key（BYOK），是指一種雲端運算安全模型，允許公共雲服務客戶使用自己的加密軟體和管理自己的加密金鑰。

### 公開金鑰基礎建設（PKI）

透過信任數位憑證認證機構的根憑證、及其使用公開金鑰加密作數位簽章核發的公開金鑰認證，形成信任鏈架構，已在 TLS 實作並在全球資訊網的 HTTP 以 HTTPS、在電子郵件的 SMTP 以 STARTTLS 引入。

### 組播組金鑰管理

Group Key Management means managing the keys in a group communication. Most of the group communications use 多播 communication so that if the message is sent once by the sender, it will be received by all the users. The main problem in multicast group communication is its security. In order to improve the security, various keys are given to the users. Using the keys, the users can encrypt their messages and send them secretly. IETG.org released RFC 4046, entitled Multicast Security (MSEC) Group Key Management Architecture, which discusses the challenges of group key management.

## 參見

## 參考資料

## 外部連結

* _Recommendation for Key Management — Part 1: general,_ NIST Special Publication 800-57
* NIST _Cryptographic Toolkit_（頁面存檔備份，存於網際網路檔案館）
* _The IEEE Security in Storage Working Group (SISWG) that is creating the P1619.3 standard for Key Management_
* _American National Standards Institute_（頁面存檔備份，存於網際網路檔案館） - ANSI X9.24, Retail Financial Services Symmetric Key Management
* _The OASIS Key Management Interoperability Protocol (KMIP) Technical Committee_ （頁面存檔備份，存於網際網路檔案館）
* _The OASIS Enterprise Key Management Infrastructure (EKMI)Technical Committee_ （頁面存檔備份，存於網際網路檔案館）
* "Key Management with a Powerful Keystore"（頁面存檔備份，存於網際網路檔案館）
* "Intelligent Key Management System - KeyGuard | Senergy Intellution"
* IBM Security Key Lifecycle Manager, SKLM