金鑰管理

金鑰管理Key management)是一個密碼系統英語Cryptosystem加密金鑰的管理部分。它包括金鑰的生成、交換、儲存、使用、金鑰銷毀英語Crypto-shredding以及金鑰更替的處理,涉及到密碼學協定設計、金鑰伺服器英語Key server (cryptographic)、用戶程式,以及其他相關協定。[1]

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

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

金鑰類型

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

庫存

任何證書和私鑰管理策略的起點都是建立所有憑證的位置和責任方的全面清單。這不是一件微不足道的事情,來自各種來源的憑據被不同個人和團隊部署在各種地點——這不可能簡單依賴於單個數碼證書認證機構的列表,在到期前沒有被更新或替換的證書可能導致嚴重的停機和中斷。以及其他考慮: 法規和強制要求,例如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.[2]

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.

金鑰儲存

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

金鑰使用

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

挑戰

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

  1. 擴展性:需管理大量加密金鑰。
  2. 安全性:外部黑客/惡意內部人員造成的金鑰隱患。
  3. 數據可用性:需確保授權用戶可訪問數據。
  4. 支援性:需支援多種資料庫、應用程式和標準。
  5. 治理:定義政策驅動的訪問控制和數據保護。[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.[6]
  • EPKS - Echo Public Key Share, system to share encryption keys online in a p2p community.[7]
  • Kmc-Subset137[8] - key management system implementing UNISIG Subset-137 [9] for ERTMS英語ERTMS/ETCS railway application.
  • privacyIDEA英語privacyIDEA - two factor management with support for managing SSH keys.[10]
  • StrongKey - open source, last updated on Sourceforge in 2013.[11]
  • Vault - secret server from HashiCorp英語HashiCorp.[12]
專有
  • Bloombase KeyCastle
  • 金鑰管理系統安全策略

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

    • 保密
    • 完整
    • 可用
    • 來源認證[39]

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

    帶入自己的加密/金鑰

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

    透過信任數碼證書認證機構根證書、及其使用公開金鑰加密數碼簽章核發的公開金鑰認證,形成信任鏈架構,已在TLS實作並在萬維網HTTPHTTPS、在電子郵件SMTPSTARTTLS引入。

    組播組金鑰管理

    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.[40]

    參見

    參考資料

    1. ^ Turner, Dawn M. What Is Key Management? A CISO Perspective. Cryptomathic. [30 May 2016]. (原始內容存檔於2017-10-20). 
    2. ^ Pressestelle Ruhr-Universität Bochum - Online-Redaktion. Startseite - Ruhr-Universität Bochum. Crypto.rub.de. [2013-08-06] (德語). [永久失效連結]
    3. ^ An ancient technology gets a key makeover. Crain's New York Business. Crain's New York. [19 May 2015]. (原始內容存檔於2014-10-03). 
    4. ^ Security Policy and Key Management: Centrally Manage Encryption Key. Slideshare.net. 2012-08-13 [2013-08-06]. (原始內容存檔於2016-03-04). 
    5. ^ Reinholm, James H. Simplifying the Complex Process of Auditing a Key Management System for Compliance. Cryptomathic. [30 May 2016]. (原始內容存檔於2016-07-01). 
    6. ^ 存档副本. [2017-06-18]. (原始內容存檔於2017-06-15). 
    7. ^ 存档副本. [2017-06-18]. (原始內容存檔於2016-08-09). 
    8. ^ 存档副本. [2017-06-18]. (原始內容存檔於2017-06-30). 
    9. ^ 存档副本 (PDF). [2017-06-18]. (原始內容存檔 (PDF)於2017-05-10). 
    10. ^ 存档副本. [2020-10-07]. (原始內容存檔於2020-09-17). 
    11. ^ 存档副本. [2017-06-18]. (原始內容存檔於2016-10-11). 
    12. ^ 存档副本. [2017-06-18]. (原始內容存檔於2017-06-03). 
    13. ^ 存档副本. [2017-06-18]. (原始內容存檔於2017-05-24). 
    14. ^ AppViewX Announces Major Software Upgrade with Version 11.0 Release. www.businesswire.com. [2017-05-15]. (原始內容存檔於2016-10-20) (英語). 
    15. ^ AppViewX Announces Secure Shell Management. www.businesswire.com. [2017-05-15]. (原始內容存檔於2016-10-21) (英語). 
    16. ^ Key Management System. Bell ID. [2014-01-17]. (原始內容存檔於2016-03-23). 
    17. ^ Landrock, Peter. Cryptomathic Key Management System. cryptomathic.com/. Cryptomathic. [April 20, 2015]. (原始內容存檔於2016-03-25). 
    18. ^ Cryptsoft. Cryptsoft. [2013-08-06]. (原始內容存檔於2016-03-20). 
    19. ^ =http://fornetix.com/products/頁面存檔備份,存於互聯網檔案館
    20. ^ Futurex Key Management Servers. Futurex.com. [2016-08-18]. (原始內容存檔於2016-10-11). 
    21. ^ Gazzang zTrustee. Gazzang.com. 1970-01-01 [2013-08-06]. (原始內容存檔於2014-08-07). 
    22. ^ United States. Data Encryption - Enterprise Secure Key Manager | HP® Official Site. H17007.www1.hp.com. [2013-08-06]. (原始內容存檔於2012-07-10). 
    23. ^ IBM Enterprise Key Management Foundation (EKMF). 03.ibm.com. [2013-08-06]. (原始內容存檔於2011-12-19). 
    24. ^ Archived copy (PDF). [2013-02-08]. (原始內容 (PDF)存檔於2014-12-29). 
    25. ^ Data-at-rest Encryption for the IBM Spectrum Accelerate Famil. google.com. [2017-06-12]. 
    26. ^ KeyNexus. keynexus.net. [2017-06-02]. (原始內容存檔於2017-04-10). 
    27. ^ 存档副本. [2017-06-18]. (原始內容存檔於2016-10-19). 
    28. ^ Key Manager | Storage. Oracle. [2013-08-06]. (原始內容存檔於2016-03-26). 
    29. ^ P6R. P6R. [2015-05-11]. (原始內容存檔於2016-03-04). 
    30. ^ About Virtual Private Data. Porticor.com. [2013-08-06]. (原始內容存檔於2016-03-15). 
    31. ^ qCrypt. Quintessencelabs.com. [2016-04-01]. (原始內容存檔於2015-10-02). 
    32. ^ RSA Data Protection Manager - Data Encryption, Key Management. EMC. 2013-04-18 [2013-08-06]. (原始內容存檔於2015-10-11). 
    33. ^ Key Management Solutions by SafeNet: Protect & Manage Cryptographic Keys. Safenet-inc.com. [2013-08-06]. (原始內容存檔於2014-04-08). 
    34. ^ 存档副本. [2017-06-18]. (原始內容存檔於2017-07-05). 
    35. ^ Key Management: keyAuthority - a proven solution for centralizing key management. Thales-esecurity.com. [2013-08-06]. (原始內容存檔於2012-09-10). 
    36. ^ Encryption Key Management | Encryption Key Management, Cloud Security, Data Protection. Townsendsecurity.com. [2013-08-06]. (原始內容存檔於2016-03-04). 
    37. ^ 存档副本. [2014-09-27]. (原始內容存檔於2014-07-11). 
    38. ^ Vormetric Data Security Platform. Vormetric.com. [2015-12-15]. (原始內容存檔於2016-04-10). 
    39. ^ Barker, Elaine. NIST Special Publication 800 -130: A Framework for Designing Cryptographic Key Management Systems (PDF). National Institute of Standards and Technology. [30 May 2016]. (原始內容存檔 (PDF)於2017-05-18). 
    40. ^ Multicast Security (MSEC) Group Key Management Architecture. 2005-04-01 [2017-06-12]. (原始內容存檔於2017-06-16). 

    外部連結