# 加密存储备忘单 > 原文：[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>