Crypto SSD 加密密钥交换方法

为了执行加密/解密，需要加密密钥。在下面的讨论中，我们将其称为 DEK（设备加密密钥）。

可以通过多种方式向设备提供 DEK，我们将在下面讨论其中的几种方法。

自生成永久密钥：

在这种方法中，驱动器在内部生成一个加密密钥并将其存储在驱动器上的保留区域中。数据自动加解密，用户无法控制DEK。这种方法被用于一些宣传为具有 AES 加密的 SSD。

但是，由于 DEK 存储在驱动器本身中，因此这种密钥处理方法根本无法保护数据；任何有权访问驱动器的人都可以访问数据。这种情况下的加密引擎仅用作数据扰频器，这是 MLC/TLC NAND 闪存的要求。

用户生成的会话密钥：

在这种密钥交换方法中，用户通常通过 ATA 供应商特定命令生成 DEK 并将其发送到设备。

DEK 未存储在设备中，因此每次驱动器重启时，用户都需要将 DEK 重新发送到设备。

这种密钥交换方法优于刚才描述的自生成永久密钥方法，因为如果没有提供适当的 DEK，有权访问驱动器的第 3 方无法解密数据。

这是 Cactus Technologies CryptoSSD 产品支持的密钥交换方法之一，我们称之为 SetDEK 方法。

这种密钥交换方法的弱点是 DEK 以明文形式发送到设备，因此第 3 方有可能通过某种总线监控方法捕获此 DEK。

此外，DEK 不会改变，每次都会将相同的 DEK 发送到设备；因此，一旦第 3 方捕获了 DEK，如果它设法访问驱动器，它就可以解密数据。

Cactus Technologies 单因素身份验证 w/ HMAC：

为了解决密钥交换的安全问题，仙人掌科技与eNOVA Technology Corp.合作开发了一种使用HMAC协议的安全密钥交换方法。

HMAC全称Key Hashed Message Authentication Code，这是一种众所周知的认证协议，业界普遍使用。

这种密钥交换方法使用 eNOVA MX+ 设备中的 FIPS 140 2 级认证硬件加密模块来生成 DEK。

客户定义的 256 位共享密钥用于生成随机密钥加密密钥 (KEK)，用于将 DEK 包装在 MAC（消息验证代码）中。然后将此 MAC 发送到设备。

在设备中，此 MAC 在 MX+ 设备中进行身份验证，然后 DEK 从 MAC 中解包。MAC 是随机的并且每次都不同，并且 DEK 不会像 SetDEK 方法那样以明文形式发送；因此，这种密钥更改方法是安全的，不会受到第 3 方的窥探。

为了让第 3 方能够解密驱动器上的数据，它必须知道解锁 PIN、共享密钥和一系列用于 HMAC 交换的 ATA 命令；第 3 方不太可能访问所有这三个项目。

因此，这种密钥交换方法是高度安全的。与 SetDEK 方法的情况一样，DEK 仅在易失性寄存器中内部存储在 MX+ 设备中。

该寄存器是只写的，不能读；断电时存储的数据会丢失，因此，每次设备重启时都必须进行密钥交换。

这种密钥交换方法非常安全，但更难集成到用户的主机系统中。

涉及许多 ATA 供应商特定命令，只有在与 eNOVA Technology Corp 执行 NDA 后，才会向客户披露其详细信息。

Cactus Technologies 将提供 Windows 和 Linux HMAC 实用程序来管理密钥交换，但对于使用其他操作系统或需要编写自己的实用程序的操作环境的客户，请联系 Cactus Technologies 以获取更多信息和支持。

最后的想法：

Cactus Technologies在我们的 CryptoSSD 系列产品中设计和制造高度安全的FIPS 140-2 验证、AES256 加密 SSD 。这些产品使用经过 FIPS 140-2 和 FIPS-197 认证的加密模块。

我们的2.5 英寸 SATA 加密 SSD具有扩展（-40C 至 85C）工作温度版本，而加密外部 USB SSD 的额定温度范围为 0C 至 70C。

如果您需要 OEM 设计方面的帮助或需要特殊功能，请联系我们。