# 加密存儲備忘單 > 原文：[Cryptographic Storage Cheat Sheet](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet) > 來源：[加密存儲備忘單](http://cheatsheets.hackdig.com/?5.htm) ## 介紹 這篇文章提供了一個實現靜態數據存儲時可以遵循的簡單模型。 ### 架構決策 架構決策必須包含適當的保護數據的方法。有很多種類的產品、方法和機制用來進行加密存儲。這個備忘單是提供給實現低級別加密解決方案的開發人員和架構師的指導手冊。我們不會提供特定供應商的解決方案，也不會做加密算法的設計。 ## 提供加密功能 ### 安全的加密存儲設計 #### 規則1：只存儲你需要的敏感數據 很多電商企業借助第三方支付服務供應商服務來存儲用來重復計費的信用卡信息。這就規避了保證信用卡信息安全的麻煩。 #### 規則2：只使用強加密算法 只使用符合標準的公共加密算法，如AES、 RSA公鑰加密算法、SHA-256或更好的散列（Hash）算法。不使用弱加密算法，如MD5或SHA1。需要留意的是，一個加密算法是否屬于強加密類別會隨著時間而改變（如md5曾一度被認為是安全的加密算法）。 http://csrc.nist.gov/groups/STM/cavp/index.html 上面的鏈接是CAVP項目，可以用來驗證一個沒有AES或認證加密模式的加密算法的保密性和真實性（類似數據來源認證），如CCM, EAX, CMAC等。如果你使用Java的SunJCE，這（驗證加密算法的保密性和真實性）將會成為一個問題。JDK1.5支持的加密模式包括CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC。這些加密模式中沒有一個是進行過加密模式認證的（這就是為什么顯式的添加他們）。如果你使用另一個JCE，如Bouncy Castle（它包含RSA、JSafe、IAIK等加密模式），你可以優先選擇這些經過驗證的加密模式。 適時在加密中加鹽，加鹽的時候使盡量使用MAC（如HMAC-SHA256或HMAC-SHA512）算法。 #### 規則3：確保隨機數的健壯性 確保所有的隨機數、隨機文件名、隨機GUID和隨機字符串（從密碼學角度來看）是完全隨機的。確保隨機算法的種子有足夠的熵值。 #### 規則4：使用被廣泛接受的加密算法的實現 不要自己去實現一個已有的加密算法，無論這個算法看起來多么簡單。使用被廣泛接受的加密算法及其實現。確保至少有一個密碼學專家參與過這種實現。如有可能，使用FIPS 140-2認證的實現。 #### 規則5：確保數據的完整性和真實性 加密需要確保信息的被完整加密。否則密文容易遭受填充和數據篡改攻擊。特別是數據在不可信的通道中傳輸時（如URL或cookie）。 如果實現你自己的加密機制，請使用提供了保密性和真實性（AE）的統一的API。推薦 CCM, GCM和OCB 模式。 如果不使用AE，你可以使用帶有poest-encryption消息身份認證碼的cipher-block chaining (CBC)模式 ，如HMAC和UMAC。不要使用ECB mode。 #### 規則6：存儲密碼的散列和鹽（salt） 你可以訪問 Password Storage Cheat Sheet以獲取更多信息。 #### 規則7：確保在訪問控制失敗時密碼保護也是安全的 這條規則支持深度防御原則。訪問控制（賬號、密碼、權限等）是一層防護。強壯的加密還需要添加一個額外的防護層，從而確保即使攻擊者獲得了數據庫訪問權限，數據也能得到保護。 #### 規則8：確保未經授權的情況下無法訪問密鑰 #### 規則9：定義密鑰的生命周期 密鑰生命周期是指一個密鑰在其使用周期內狀態變化的詳情。生命周期將指定密鑰何時不再用來加密、何時不再用來解密，當有新密鑰時數據是否需要重新加密，密鑰何時應該被移除。 #### 規則10：將未加密的密鑰和加密的數據分開存放 如果密鑰和數據一起存儲，數據被泄露，密鑰也會被輕易的獲取。所以，非加密的密鑰不能和數據存放在同一機器或集群。 #### 規則11：當使用多個密鑰時，確保各個密鑰是相互獨立沒有關聯的 確保密鑰是獨立的。比如，不要讓第2個密鑰與第1個密鑰有任何關聯（最常見的錯誤就是：第2個密鑰是基于第1個密鑰生成的）。 #### 規則12：要將保護密鑰當成安全保護中重中之重 密鑰應該時刻受到十分嚴密的保護。要確保攻擊者在獲取數據到獲取密鑰之間有一個不可逾越的鴻溝。這意味著密鑰不應該被保存在應用程序或者WEB服務器上（假設應用程序攻擊者也是威脅模型的一部分）。 #### 規則13：編寫管理密鑰的生命周期的步驟文檔 這些步驟需要被記錄下來，密鑰保管者必須要訓練有素。 #### 規則14：支持定期修改密鑰的功能 密鑰旋轉是為所有可用密鑰設置過期或者撤銷的過程。所以開發者必須應對密鑰旋轉——最好是有一個可用的系統而不是手忙腳亂的做一些臨時操作。 #### 規則15：編寫處理密鑰泄露的步驟文檔 #### 規則16：密鑰至少3年重置一次 重置密鑰是解密數據并使用新密鑰重新加密的過程。定期的重置密鑰能防止數據被泄露的舊密鑰解密。密鑰重置周期取決于密鑰的安全性。存儲在專用硬件的密鑰可能只需要三年重置一次。和數據分離存儲在不同的服務器上的密鑰可能只需要每年重置一次。 #### 規則17：遵循加密的法規 #### 規則18：根據PCI DSS(<http://en.wikipedia.org/wiki/PCI_DSS>)要求的第3部分：你必須保護持卡人的數據 第三方支付行業數據安全標準是用來鼓勵和加強持卡人的數據安全和促進形成全球統一的數據安全衡量標準。標準是在2005年引入的，取代了Visa, Mastercard, Amex, JCB和Diners的個人遵從標準。當前的標準版本是2.0，從2011年1月1日開始生效。 PCI DSS第3部分覆蓋信用卡數據的安全存儲領域。這個要求涵蓋了幾方面的安全存儲，包括：你不能保存的數據。我們主要關心3.4、3.5和3.6這幾個加密存儲的章節： **3.4 Render PAN (Primary Account Number)至少要保存在無法被讀取的地方** 可以通過實現安全加密和散列數據標準的四種安全存儲類型中的一種來符合3.4的要求。下面的兩種常常是最受歡迎的選擇。標準并不指定特定的算法，但要求使用強密碼。PCI委員會定義強密碼的文檔如下： 加密應基于工業測試和公認的算法，以及強有力的密鑰長度和適當的密鑰管理實踐。密碼學是一種保護數據的包括加密（可逆）和散列（不可逆）兩種方式的方法。SHA-1是一種經過工業測試和公認的散列算法示例。AES（128位或更高）、TDES（最低雙倍長度的密鑰）、RSA（1024位或更高）、ECC（160位或更高）和EIGamal（1024位或更高）是經過工業測試和公認的加密算法示例。 如果你已經實現了本備忘單的第二條規則，你應該已經實現了符合或高于PCI DSS要求（3.4）的強加密算法。你需要確保存儲卡數據的所有位置滿足保護要求，甚至日志存儲的位置也要使用加密數據替換日志中的卡號。 這個要求也可以通過實現磁盤加密（不僅僅包括文件或列級加密）來實現。強加密的要求對于磁盤加密和備份數據加密都是相同的。卡數據不應該被明文存儲。在遵循這個備忘單的要求下，你能通過良好的滿足PCI DSS3.4要求的習慣，安全的存儲你的數據。 **3.5保護用于保障持卡人數據和信息免遭泄露和濫用的密鑰** 正如要求名所示，我們需要安全的存儲加密密鑰。這意味著為密鑰實現強大的權限控制、審計和日志記錄功能。密鑰必須存儲在一個既安全又與加密數據分離的地方。這意味著密鑰不應該存儲在WEB服務器、數據庫服務器等。 訪問密鑰的權限必須嚴格限制，盡量分配給少數幾個用戶。理想情況下，這類高權限用戶是高度可信的并且經過專業的密鑰保管訓練。顯然，系統/服務賬號訪問密鑰數據從而進行數據的加密/解密也有一些安全要求。 除非密鑰被已經被KEK（用來加密密鑰的密鑰）加密，否則密鑰本身不應被明文存儲。KEK不能喝加密密鑰保存在同一位置。 **3.6 全部密鑰管理流程、加密持卡人數據的密鑰的程序應該有完整的文檔** 3.6要求一個遵從PCI體系的公司的密鑰管理流程需要包含8個特定的密鑰生命周期步驟： **3.6.1 生成強加密密鑰** 根據我們之前在備忘單中的描述，我們需要使用提供高等級數據安全的算法。我們通過使用強密碼來保障數據免受弱密碼的威脅。一個強壯的密鑰需要使用符合你數據安全要求和PCI DSS規范的密鑰長度。僅僅通過密鑰長度不能衡量一個密鑰是否強壯。用來生成密鑰的數據必須足夠的隨機（“足夠”通常是根據你的數據來定義的）并且密鑰數據本身的熵值也必須很高。 **3.6.2 安全的加密密鑰分發** 分發密鑰的方法必須是安全的能夠在傳輸過程中防止被竊取。使用協議（如Diffie Hellman）能夠幫助進行安全的密鑰分發。使用類似于SSLv3、TLS和SSLv2也有助于安全的傳輸密鑰。 **3.6.3 安全的加密密鑰存儲** 加密密鑰（包括KEK密鑰）的安全存儲已經在安全要求3.5中談及（見上文）。 **3.6.4 周期性的修改密鑰** PCI DSS標準要求用來加密的密鑰需要至少每年重置一次。密鑰重置的關鍵是在加密/解密過程中移除就密鑰，并使用新密鑰來代替。所有進入系統的新數據必須使用新密鑰來加密。同時建議現有數據也要使用新密鑰重新加密。重新加密的數據至少1~3年重新執行上面的流程。PCI DSS標準要求沒有明確的指出如何處理這些重新加密的數據。 **3.6.5 當密鑰的完整性已經減弱或密鑰疑遭泄露時，將密鑰的失效或更換是必要的處理手段** 密鑰的管理過程必須滿足歸檔、失效和妥協的要求。安全的存儲和替換密鑰的過程需要滿足3.6.2、3.6.3、3.6.4的要求。 **3.6.6 密鑰分隔和建立對密鑰的雙重控制** 密鑰管理的密鑰分隔和/或雙重控制要求是為了防止個別用戶執行密鑰管理行為，如密鑰重置和刪除。系統需要兩個人執行一個操作（如從他們各自的OTP上輸入值組成一個密鑰），創建各自獨立的值進而生成最終的密鑰。 **3.6.7 防止未經授權的加密密鑰的更換** 如果系統實施能做到符合3.6.6，那么將進一步防止未經授權的關鍵數據替換。除了雙重控制流程之外，你還需要實現強大的用于管理密鑰數據的訪問控制、審計和日志管理，以防止未經授權的訪問和登陸。 **3.6.8 密鑰托管人需要簽署文件來表明他們理解和接受密鑰保管的責任** 我們在要求3.6中看到，為了實現強大的密碼管理功能，我們必須高度信任和訓練密鑰管理人員，讓他們懂得如何行使密鑰管理職責。密鑰管理者必須簽署一份聲明，聲明他們理解這個角色所要承擔的責任。 ## 相關文章 OWASP - Testing for SSL-TLS, and OWASP Guide to Cryptography OWASP – Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10) ## 作者和主編 Kevin Kenan - kevin[at]k2dd.com David Rook - david.a.rook[at]gmail.com Kevin Wall - kevin.w.wall[at]gmail.com Jim Manico - jim[at]owasp.org Fred Donovan - fred.donovan(at)owasp.org ## 翻譯 taogogo - <love@taogogo.info>