Microsoft SDL 密碼編譯 建議

簡介

本檔包含在 Microsoft 平臺上使用加密的建議和最佳做法。 這裡的大部分內容都是從用來建立安全性開發生命週期的 Microsoft 內部安全性標準進行描述或匯總。 在設計產品以使用 Microsoft 需要自己的產品和服務相同的 API、演算法、通訊協定和密鑰長度時，其用途是做為參考。

非 Windows 平臺上的開發人員也可能受益於這些建議。 雖然 API 和連結庫名稱可能不同，但涉及演算法選擇、金鑰長度和數據保護的最佳做法在平台之間很類似。

安全性通訊協議、演算法和金鑰長度 建議

SSL/TLS 版本

產品和服務應使用以密碼編譯方式保護 SSL/TLS 版本：

• 應啟用 TLS 1.2

• TLS 1.1 和 TLS 1.0 應該只啟用回溯相容性

• SSL 3 和 SSL 2 預設應停用

對稱區塊加密、加密模式和初始化向量

封鎖密碼

對於使用對稱區塊加密的產品：

• 建議針對新程式代碼使用進階加密標準 （AES）。

• 在現有的程式代碼中，允許三鍵三重數據加密標準 （3DES） 回溯相容性。

• 所有其他區塊加密，包括 RC2、DES、2 金鑰 3DES、DESX 和 Skipjack，都只能用於解密舊數據，而且應該取代用於加密。

針對對稱區塊加密演算法，建議使用最小密鑰長度為 128 位。 針對新程式代碼建議的唯一區塊加密演算法是 AES（AES-128、AES-192 和 AES-256 都是可接受的，指出 AES-192 在某些處理器上缺乏優化）。 如果已在現有程序代碼中使用，則目前可接受三鍵 3DES;建議轉換至 AES。 DES、DESX、RC2 和 Skipjack 不再被視為安全。 為了回溯相容性，這些演算法只應該用於解密現有的數據，而應該使用建議的區塊加密來重新加密數據。

加密模式

對稱演算法可以在各種模式中運作，其中大部分會鏈接在連續純文本和加密文字區塊上的加密作業。

對稱區塊加密應該與下列其中一種加密模式搭配使用：

• 加密區塊鏈結 （CBC）

• 加密文字竊取 （CTS）

• 使用加密文字竊取 的 XEX 型調整程式代碼手冊 （XTS）

其他一些加密模式，如以下所列的加密模式有實作陷阱，使得這些模式更可能不正確使用。 特別是，應避免電子代碼簿（ECB）的運作模式。 在「串流加密模式」中使用區塊加密來重複使用相同的初始化向量 （IV），例如 CTR 可能會導致顯示加密的數據。 如果使用下列任何模式，建議進行其他安全性檢閱：

• 輸出意見反應 （OFB）

• 加密意見反應 （CFB）

• 計數器 （CTR）

• 使用 CBC-MAC 的計數器 （CCM）

• Galois/計數器模式 （GCM）

• 上述「建議」清單上沒有的任何其他專案

初始化向量 （IV）

所有對稱區塊加密也應該搭配密碼編譯強式隨機數作為初始化向量使用。 初始化向量絕對不應該是常數值。 如需產生密碼編譯強式隨機數的建議，請參閱隨機數產生器。

執行多個加密作業時，不應該重複使用初始化向量，因為這可能會顯示所加密數據的相關信息，尤其是在使用輸出回饋（OFB）或計數器（CTR）等串流加密模式時。

非對稱演算法、金鑰長度和填補模式

Rsa

• RSA 應該用於加密、金鑰交換和簽章。

• RSA 加密應該使用 OAEP 或 RSA-PSS 填補模式。 現有的程式代碼應該只使用 PKCS #1 v1.5 填補模式進行相容性。

• 不建議使用 Null 填補。

• 建議使用索引鍵 >= 2048 位

ECDSA

• 建議使用 = 256 位金鑰的 >ECDSA

• ECDSA 型簽章應使用三個 NIST 核准曲線之一（P-256、P-384 或 P521）。

ECDH

• 建議使用 = 256 位金鑰的 >ECDH

• ECDH 型密鑰交換應使用三個 NIST 核准曲線之一（P-256、P-384 或 P521）。

整數 Diffie-Hellman

• 建議使用金鑰長度 >= 2048 位

• 群組參數應該是已知的具名群組（例如 RFC 7919），或由信任方產生，並在使用之前經過驗證

金鑰存留期

• 所有非對稱密鑰都應該有最多五年的存留期，建議使用一年存留期。

• 所有對稱金鑰都應該有最多三年的存留期;建議的一年存留期。

• 您應該提供機制，或有取代密鑰的程式，以達到有限的使用中存留期。 在作用中存留期結束時，金鑰不應該用來產生新數據（例如，用於加密或簽署），但仍可能用來讀取數據（例如解密或驗證）。

隨機數產生器

當需要隨機性時，所有產品和服務都應該使用密碼編譯保護隨機數產生器。

天然氣

• 搭配BCRYPT_USE_SYSTEM_PREFERRED_RNG旗標使用 BCryptGenRandom

CAPI

• 使用 CryptGenRandom 來產生隨機值。

Win32/64

• 舊版程式代碼可以在核心模式中使用 RtlGenRandom

• 新的程式代碼應該使用 BCryptGenRandom 或 CryptGenRandom。

• C 函 式Rand_s（） 也建議使用 （在 Windows 上呼叫 CryptGenRandom）

• Rand_s（） 是蘭德（） 的安全和高效能的替代品。 Rand（） 不應用於任何密碼編譯應用程式，但僅適用於內部測試。

• 建議針對內核模式程序代碼使用 SystemPrng 函式。

.NET

• 使用 RNGCryptoServiceProvider

Windows 市集應用程式

• 市集應用程式可以使用 CryptographicBuffer.GenerateRandom 或 CryptographicBuffer.GenerateRandomNumber。

不建議使用

• 與隨機數產生相關的不安全函式包括 rand、System.Random （.NET）、GetTickCount 和 GetTickCount64

• 不建議使用雙橢圓曲線隨機數產生器 （“DUAL_EC_DRBG”） 演算法。

Windows 平台支援的 Crypto 連結庫

在 Windows 平臺上，Microsoft 建議使用作業系統內建的加密 API。 在其他平臺上，開發人員可以選擇評估非平臺密碼編譯連結庫以供使用。 一般而言，平臺密碼編譯連結庫會更頻繁地更新，因為它們會隨附於操作系統中，而不是與應用程式搭配使用。

關於平臺與非平臺密碼編譯的任何使用決策，都應該遵循下列需求：

1. 連結庫應該是目前不受已知安全性弱點支援的版本

2. 應支援最新的安全性通訊協議、演算法和金鑰長度

3. （選擇性）連結庫應該能夠支援較舊的安全性通訊協定/演算法，以取得回溯相容性

機器碼

• Crypto Primitives：如果您的版本位於 Windows 或 Windows 電話，請盡可能使用 CNG。 否則，請使用 CryptoAPI （也稱為 CAPI，從 Windows Vista 開始支援為 Windows Vista 上的舊版元件）。

• SSL/TLS/DTLS：WinINet、WinHTTP、Schannel、IXMLHTTPRequest2 或 IXMLHTTPRequest3。

  • WinHTTP 應用程式應使用 WinHttpSetOption建置，以支援 TLS 1.2

• 程式代碼簽章驗證： WinVerifyTrust 是 Windows 平台上驗證程式代碼簽章的支援 API。

• 憑證驗證（用於程式代碼簽署或 SSL/TLS/DTLS 的限制憑證驗證）：CAPI2 API;例如， CertGetCertificateChain 和 CertVerifyCertificateChainPolicy

Managed 程式代碼

• 密碼編譯基本類型：使用 System.Security.Cryptography 命名空間中定義的 API---建議使用 CNG 類別。

• 使用最新版的 .Net Framework。 這至少應該是 .Net Framework 4.6 版。 如果需要較舊的版本，請確定 「SchUseStrongCrypto」 regkey 已設定為針對有問題的應用程式啟用 TLS 1.2。

• 憑證驗證：使用 System.Security.Cryptography.X509Certificates 命名空間下定義的 API。

• SSL/TLS/DTLS：使用 System.Net 命名空間下定義的 API（例如 HttpWebRequest）。

金鑰衍生函式

金鑰衍生是從共用密碼或現有密碼編譯金鑰衍生密碼編譯密鑰數據的程式。 產品應該使用建議的金鑰衍生函式。 從使用者選擇的密碼衍生金鑰，或驗證系統中記憶體的哈希密碼是本指南未涵蓋的特殊案例：開發人員應該諮詢專家。

下列標準指定建議使用的 KDF 函式：

• NIST SP 800-108： 建議使用 Pseudorandom 函式進行密鑰衍生。 特別是計數器模式中的 KDF，以 HMAC 作為虛擬隨機函式

• NIST SP 800-56A （第 2 版）： 使用離散對數密碼編譯配對密鑰建立配置的建議。 特別是，建議使用第 5.8.1 節中的「單一步驟密鑰衍生函式」。

若要從現有的金鑰衍生密鑰，請使用 BCryptKeyDerivation API 搭配其中一種演算法：

• BCRYPT_SP800108_CTR_HMAC_ALGORITHM

• BCRYPT_SP80056A_CONCAT_ALGORITHM

若要從共享密碼衍生金鑰（金鑰協定的輸出）使用 BCryptDeriveKey API 搭配下列其中一種演算法：

• BCRYPT_KDF_SP80056A_CONCAT

• BCRYPT_KDF_HMAC

憑證驗證

使用 SSL、TLS 或 DTLS 的產品應該完整驗證其所連線實體的 X.509 憑證。 這包括驗證憑證』：

• 網域名稱。

• 有效日期（開始日期和到期日）。

• 撤銷狀態。

• 使用方式（例如伺服器的「伺服器驗證」、用戶端的「客戶端驗證」）。

• 信任鏈結。 憑證應該鏈結至平臺信任的跟證書授權單位（CA），或由系統管理員明確設定。

如果上述任何驗證測試失敗，產品應該終止與實體的連線。

信任「自我簽署」憑證的用戶端（例如，在預設設定中連線到 Exchange 伺服器的郵件用戶端）可能會忽略憑證驗證檢查。 不過，自我簽署憑證原本就不會傳達信任、支持撤銷或支援密鑰更新。 如果您已從另一個受信任的來源取得自我簽署憑證，則應該只信任自我簽署憑證（例如，透過已驗證且完整性保護的傳輸來提供憑證的受信任實體）。

密碼編譯哈希函式

產品應該使用SHA-2系列哈希演算法（SHA256、SHA384和SHA512）。 不建議基於安全性目的截斷密碼編譯哈希到小於128位。

MAC/HMAC/索引哈希演算法

郵件驗證碼 （MAC） 是附加至郵件的一部分資訊，可讓收件者使用秘密密鑰來驗證寄件者的真實性和郵件的完整性。

只要建議使用所有基礎哈希或對稱加密演算法才能使用哈希式 MAC（HMAC）或區塊加密式 MAC;目前這包括 HMAC-SHA2 函式（HMAC-SHA256、HMAC-SHA384 和 HMAC-SHA512）。

不建議將 HMAC 截斷為小於 128 位。

設計和操作考慮

• 您應該提供必要的機制來取代密碼編譯金鑰。 密鑰應在使用中存留期結束，或密碼編譯密鑰遭到入侵時取代。 每當您更新憑證時，都應該使用新的金鑰來更新憑證。

• 使用密碼編譯演算法保護數據的產品應該包含足夠的元數據，以及該內容，以支援在未來移轉至不同的演算法。 這應該包括使用的演算法、索引鍵大小、初始化向量和填補模式。

  • 如需密碼編譯靈活度的詳細資訊，請參閱 MSDN 上的密碼編譯靈活度。

• 如果可用，產品應該使用已建立的平臺提供密碼編譯通訊協定，而不是重新實作它們。 這包括簽署格式（例如使用標準、現有的格式）。

• 不應該使用 RC4 之類的對稱數據流加密。 產品應該使用區塊加密，特別是密鑰長度至少為128位的AES，而不是對稱數據流加密。

• 請勿向用戶回報密碼編譯作業失敗。 將錯誤傳回遠端呼叫端時（例如 Web 用戶端或用戶端在用戶端-伺服器案例中的用戶端），僅使用一般錯誤訊息。

  • 避免提供任何不必要的資訊，例如直接報告超出範圍或無效的長度錯誤。 只在伺服器上記錄詳細資訊錯誤，而且只有在啟用詳細信息記錄時。

• 對於包含下列專案的任何設計，強烈建議進行額外的安全性檢閱：

  • 主要著重於安全性的新通訊協定（例如驗證或授權通訊協定）

  • 以新式或非標準方式使用密碼編譯的新通訊協定 o 範例考慮包括：

    • 實作通訊協議的產品是否會呼叫任何密碼編譯 API 或方法，做為通訊協議實作的一部分？

    • 通訊協定是否相依於任何其他用於驗證或授權的通訊協定？

    • 通訊協定是否會定義密碼編譯專案的儲存格式，例如金鑰？

• 不建議在生產環境中使用自我簽署憑證。 使用自我簽署憑證，例如使用原始密碼編譯密鑰，原本就不提供使用者或系統管理員進行任何基礎來進行信任決策。

  • 相反地，使用跟在受信任證書頒發機構單位中的憑證會清楚說明依賴相關聯私鑰的基礎，並在發生安全性失敗時啟用撤銷和更新。

在 儲存體 之前加密敏感數據

DPAPI/DPAPI-NG

針對需要在系統重新啟動之間儲存的數據：

• CryptProtectData

• CryptUnprotectData

• NCryptProtectSecret （Windows 8 CNG DPAPI）

對於不需要在系統重新啟動之間保存的數據：

• CryptProtectMemory

• CryptUnprotectMemory

針對需要由多個網域帳戶和計算機保存和存取的數據：

• NCryptProtectSecret （在 CNG DPAPI 中，自 Windows 8 起提供）

• Microsoft Azure KeyVault

SQL Server TDE

您可以使用 SQL Server 透明資料加密 （TDE） 來保護敏感數據。

您應該使用符合 SDL 密碼編譯演算法和金鑰強度需求的 TDE 資料庫加密金鑰 （DEK）。 目前僅建議使用AES_128、AES_192和AES_256;不建議使用TRIPLE_DES_3KEY。

使用 SQL TDE 有一些重要考慮，您應該記住：

• SQL Server 不支援 FILESTREAM 數據的加密，即使已啟用 TDE 也一樣。

• TDE 不會自動提供傳輸至資料庫或從資料庫傳輸的數據加密;您也應該啟用 SQL Server 資料庫的加密連線。 如需啟用加密連線的指引，請參閱對 資料庫引擎 啟用加密 連線 SQL Server 組態管理員。

• 如果您將受 TDE 保護的資料庫移至不同的 SQL Server 實例，則也應該移動保護 TDE 數據加密密鑰 （DEK） 的憑證，並將它安裝在目的地 SQL Server 實例的 master 資料庫中。 如需詳細資訊，請參閱 TechNet 文章將受 TDE保護的資料庫移至另一部 SQL Server。

認證管理

使用 Windows 認證管理員 API 或 Microsoft Azure KeyVault 來保護密碼和認證數據。

Windows 市集應用程式

使用 Windows.Security.Cryptography 和 Windows.Security.Cryptography.DataProtection 命名空間中的類別來保護秘密和敏感數據。

• ProtectAsync

• ProtectStreamAsync

• UnprotectAsync

• UnprotectStreamAsync

使用 Windows.Security.Credentials 命名空間中的類別來保護密碼和認證數據。

.NET

針對需要在系統重新啟動之間儲存的數據：

• ProtectedData.Protect

• ProtectedData.Unprotect

對於不需要在系統重新啟動之間保存的數據：

• ProtectedMemory.Protect

• ProtectedMemory.Unprotect

針對組態檔，請使用

RSAProtectedConfigurationProvider 或 DPAPIProtectedConfigurationProvider 分別使用 RSA 加密或 DPAPI 保護您的設定。

RSAProtectedConfigurationProvider 可以跨叢集中的多部計算機使用。 如需詳細資訊，請參閱 使用受保護的組態加密組態 資訊。