无论你在哪个领域工作,你肯定听到过不止一个“数据”如何改变世界面貌的故事。数据,是21世纪的黄金。为了使数据能够更快的传输,网卡的带宽从10Mbps一路发展到了100Gbps甚至更高。为了使数据更快的读写,介质与接口也一直在进步。介质的发展从软盘,光盘,到机械硬盘,NAND甚至3D Xpoint,;接口从USB到SATA, SAS, NVMe 。数据传输越来越快,但是只是快就够了吗?当然不是,数据安全同样不容忽视。按照正常的认知,对于安全的投入,势必会造成性能的降低和资源的损耗。但是,今天为大家介绍的NVMe Opal解决方案在几乎保持NVMe速度的同时,带来了数据加密机制。本篇文章将从以下几个方面为大家介绍:
1. 什么是Opal
2. SPDK与Opal的集成
3. Opal vbdev VS. Crypto vbdev
Opal是一系列的自加密盘 (SED, Self-Encrypting Drives) 的技术规范标准,由TCG这个联盟提出。TCG是一个由很多大公司组成的产业联盟, 主要是为可信计算制定一些标准。在可信计算领域具有非常高的权威性。自加密盘主要指的是这个盘本身具有全盘自动加密的功能。自加密盘上有专门负责加解密的硬件,所有数据在写到盘上的时候,会被自动加密,在读的时候会由盘自动去解密。所有这些加解密都依赖于盘上的硬件去完成。
接下来,我们看两个非常重要的概念,DEK和AK。这是在Opal中会用到的两个密钥。
(1)DEK,Data Encryption Key
DEK是负责加密盘上的数据的密钥,是由盘上的硬件随机生成的一个密码。这个密码始终是存在的,对上层完全透明,永远不会离开磁盘,永远不会被外部拿到。所有的数据加解密都是依赖这个密码。它在盘上只以加密了的形式保存。因此通过改变DEK,可以非常容易的去做全盘的安全擦除。
(2)AK,Authentication Key
AK是由用户提供的,作为验证盘本身所属性的一个密码。可以用来对盘加锁或者解锁。这个密码本身的作用就是用来对DEK进行解密。AK会在盘上以哈希值的形式保存。默认不配置Opal的情况下,Opal用缺省的密码对DEK进行加密。对用户完全透明。
正是这两个密钥,共同提供了两步验证的机制,带来了Opal的安全性和易用性。
那么为什么鼓励大家去使用Opal呢?
(1)它是基于硬件的加密,专用的加密芯片避免了加密成为性能的瓶颈,盘本身可以几乎满速运行。盘上自带的专用加密芯片也解放了CPU,释放了CPU的计算资源,负载对于CPU完全透明。也因此,它可以被大规模的部署而不用考虑是否可能占用过多的CPU资源。
(2)使用硬件加密无疑提升了安全性。不管用户是否配置,盘上的数据始终是加密的。并且,Opal最大的特点在于提供了两步验证,负责对数据进行加密的DEK永远只会在盘上。而用户提供的密钥(AK),只负责用来加密DEK。
(3)易用性。Opal盘在不需要任何配置的情况下,可以直接使用在任何之前使用普通磁盘的环境下,来保证盘上数据的安全性。对上层完全透明。需要注意的是,这个时候盘上数据的安全性只能够保证介质或者颗粒被窃取情况下数据的安全性。由于对上层完全透明,如果整块盘丢失,数据是依然可以读出的。如果需要独占的安全性,就需要通过配置软件对Opal盘进行初始化等操作。另外一点易用性体现在Opal支持更多的功能,比如可以非常简单的通过改变DEK来做全盘擦除,还比如用户可以非常容易的去修改密码。考虑到安全性,加密数据的密钥是需要定期修改的,对于使用软件加密的磁盘,修改密钥是复杂且费时的, 需要把数据先解密,然后重新使用新的密钥去加密。而两步验证的机制,使得修改密码只需要使用旧密码解密DEK,然后用新密码去加密DEK就可以,非常容易。
刚才我们提到,不对Opal进行配置的话,对上层完全透明,在整块盘丢失的情况下,并不能够保证安全性。要做到独占的安全性,就需要用户提供一个密码,完成授权这样的过程。图(1)就展示了这个过程。
图(1 )
首先我们看,盘上的数据始终是用DEK进行加密的。没有经过配置的Opal磁盘,使用缺省的AK来加密DEK。盘上只保存加密了的DEK,这部分是透明的。如果有用户进行了初始化, 提供了AK,那么盘上会保存AK的哈希值。
当用户需要从加锁了的Opal磁盘上读取数据的时候,他首先要提供一个密钥, 也就是AK。这个AK会和盘上保存的AK的哈希比较。如果不同,所有读写请求都会被拒绝。如果一致,就会用用户传入的AK来解密盘上存的DEK的密文。这样就获得了DEK,就可以用来解密盘上的数据。
那么我们是如何控制Opal的呢?根据SPEC,Opal内部的固件通过维护很多个表,来记录信息, 例如下面的Table 181。
这些信息,通过ATA, SCSI 或者NVME这类标准接口的一些命令来和host交互。比如ATA 的trust send/receive, SCSI 的security protocol in/out, NVMe 的security send/receive。Host把配置信息按照SPEC里面要求的方式构建,然后通过这些接口命令发给设备。Host对Opal的所有配置,都是通过SPEC中定义的一些method完成的, 比如SET, GET。而method需要在某一个session里触发,如图(2)。
图 (2)
为了帮助客户能够在数据中心中高效的使用Opal这样的设备来提升安全性, SPDK在19.04中引入了对于NVMe Opal library的支持。如图(3),SPDK的NVMe Opal library在NVMe用户态驱动之上,通过NVMe的security send/receive命令, 把构建的Opal指令发送给设备。并且负责收到的response的解析。NVMe Opal library可以通过examples/nvme/nvme_manage直接使用,来配置你的Opal设备。
图 (3)
目前支持了大多数操作,比如初始化,加锁,解锁, 多用户,多locking range ,恢复出厂等,如图(4)。
图 (4)
在19.10中, SPDK又引入了新的Opal vbdev(目前是实验性质),更方便上层用户使用Opal设备。Opal vbdev构建在NVMe bdev和bdev part之上。通过用户传入的offset和length, 把NVMe Namespace的一部分划分为Opal vbdev, 并且建立一个locking range。Locking range是Opal协议里面的一个术语。一块Opal设备,受限于硬件,可以分为有限个不同的locking range。每个locking range可以有单独的密码去做加锁和解锁操作。因此可以分给不同的用户,做到多个用户共享单个namespace。在解锁的情况下,Opal配置命令会直接通过Opal library发给磁盘, 然后普通IO直接发给NVMe bdev。在没有解锁的情况,IO会直接返回失败。目前支持`bdev_nvme_Opal_init`, `bdev_nvme_Opal_revert`, `bdev_Opal_create`, `bdev_Opal_delete`, `bdev_Opal_get_info`,
`bdev_Opal_new_user`, `bdev_Opal_set_lock_state` 等RPC命令对Opal进行配置。需要注意,在19.10的release中,这只作为一个实验性质的特性。
SPDK提供的Opal支持理论上可以用在任何支持Opal的NVMe设备上,比如英特尔的OPTANE P4800,和部分型号的P4510,P4610。
Opal vbdev VS. Crypto vbdev 3
SPDK在18.01的版本中引入了Crypto vbdev 模块的支持,也是可以用于数据加密的虚拟块设备,如图(5)。它调用了DPDK framework里的Cryptodev组件. Cryptodev由硬件和软件的PMD组成, 使用统一接口, 如果你有QAT这样的加速卡,可以直接把加解密的工作下发给QAT,如果没有的话,就默认使用CPU和Intel 的软件加速库来加进行加密。如果使用软件库加密,会带来一定的资源开销。
图 (5)
Crypto vbdev 使用起来相对比较容易,可以在不增加任何硬件的情况下, 利用现有平台,完成加解密的需求。而且可以用来对任何bdev, 比如NVMe, AIO或者virtual bdev比如split, logical volume进行加密。通过用户传入的key , crypto vbdev在IO落盘之前对数据进行加密, 保证了盘上数据的安全性。由于Crypto vbdev是在bdev 层之上构建的virtual bdev, 所以它可以对不同的bdev或者vbdev使用不同的key, 也可以通过SPDK的一些方法,把单个bdev或者namespace分成多个virtual bdev分给不同的用户, 使用不同的秘钥进行管理。
需要注意的是, 目前传入Crypto vbdev和Opal vbdev的秘钥都是没有经过哈希或者加密的,会直接用来加密数据。用户可以根据自己的实际需要,在上层实现自己的秘钥管理服务。SPDK目前还没有计划提供秘钥管理服务。
那么Crypto vbdev和Opal vbdev各自的优势和劣势又有哪些呢?下面我们总结一下。
Crypto vbdev
Opal vbdev
更多DPDK学习资料有需要的可以自行添加进入学习交流君 羊 793599096 免费获取,或自行报名学习,免费订阅,永久学习,关注我持续更新哦!!!
学习地址:http://ke.qq.com/course/5066203?flowToken=1043717
原文链接:https://blog.csdn.net/weixin_37097605/article/details/103170956