我最近继承了一个内部构建的密钥存储系统。该公司将信用卡数据存储在两个经过 AES 加密的数据库服务器中。这些密钥位于一个单独的系统中，该系统位于其自己的 DMZ 中。当 Web 服务器需要加密某些数据时，通过 https 调用密钥服务器并请求密钥。它返回一个密钥和一个编码的序列号。应用服务器存储加密信息和序列号，然后丢弃密钥。当需要解密数据时，序列号被发送到密钥服务器，该服务器返回用于该记录的密钥。
开发这个的家伙没有使用密钥池。每个键都是唯一的随机值。密钥数据库使用由 2 个保管人提供的 2 个密码生成的密钥加密。据我所知，即使你拿到了钥匙，你也必须能够解码序列号才能使用它们，然后每把钥匙只能用于一个记录。他甚至用 c 语言编写了一个具有编码/解码功能的 php 扩展。
这似乎是一个相当不错的设计。任何人都对这种类型的事情有任何经验，可以对这种方法以及任何可能的漏洞或改进发表意见。
乍一看，它似乎很巧妙，并且具有双层安全性。进一步思考，它与信用卡的标记化非常相似，与标记化相反，有 1 个赞成和 1 个反对：
虽然两个托管设置是一个很好的机制，但王国的密钥仍然是“密钥数据库”的加密密钥。如果它们被泄露，剩下的只是查找和算法，所有信用卡号都可以逃脱。
根据初步分析，我敢冒昧地说，总的来说，代币化系统可能不太安全。一个代币不能被撤销，它只能被查找，因此被限制，从 IP 控制等。一个好的代币化系统还有其他优点，比如它可以外包，或者 CC 号码只能像支付一样发布给第三方处理器等和 CC 号码，无论是加密的还是明文的，都不会存储在业务系统中，甚至在第一次兑换代币后甚至可能不会进入业务领域。
听起来过于复杂和脆弱 - 维持这将是一种痛苦。对于一个潜在的漏洞，这个怎么样：
“通过 https 调用密钥服务器并请求密钥”
如果使用弱（例如自签名）证书保护对密钥服务器的 https 请求，则密钥交换连接可能会被欺骗（例如，通过返回已知密钥的 MITM 攻击 - 当您知道密钥后轻松解密内容。它是很有可能，因为密钥服务器不是公开的，并且创建者可能没有考虑使用商业 CA，我想知道 SSL 服务器证书是否完全经过正确验证......或者密钥请求者是否检查是否有不同的每次都收到密钥，可能很容易一遍又一遍地重播初始消息....现在我只需要破解一个密钥！哦，好吧。