原创基于区块链的容器图像真实性分布式认证

34.3 技术介绍

Docker是一种新兴的容器技术，其目标是提供一种解决方案，在称为容器的自包含环境中自动部署应用程序和依赖项。它是一个轻量级应用程序，允许快速部署容器。容器彼此隔离，并提供单独的网络接口。隔离提供了一个类似于虚拟机(VM)的解决方案，但是没有在主机操作系统之上运行客户操作系统(OS)的开销。Docker通过与主机操作系统共享内核来实现最小的开销，这与在管理程序上运行客户操作系统内核的VM不同。Docker容器是运行多媒体应用程序的有效工具，它比虚拟机更好地运行多媒体应用程序。Docker容器对于构建多媒体云至关重要。容器化是通过Linux内核名称空间和控制组实现的，允许进程被隔离，资源被限制，开销可以忽略不计。在容器中运行的进程被认为是在一个单独的操作系统中运行，而不是在主机上运行，主机有自己分配的资源，比如CPU和内存。

当Docker提取签名图像时，它会与Notary服务器进行检查，以确保图像的完整性并验证图像的发布者。如果无法验证这些，Docker命令将产生硬故障。但是，需要注意的是，默认情况下，DCT在第一次使用时采用信任。因此，如果用户第一次提取图像，并对其进行了篡改，并指向另一个根元数据，该命令仍然会成功。当攻击者不能篡改文件时，可能尝试的另一种攻击是发送一个以前有效的有效负载，以欺骗客户端不更新到最新的映像，该映像有针对已知漏洞的补丁。同样，也可能尝试将映像降级到包含漏洞的旧版本。

在Notary实现中，Notary服务器负责对每次生成的时间戳元数据文件进行签名。当提取Docker映像时，需要验证文件的完整性。时间戳元数据包含一个表示元数据有效性的expires字段。因此，攻击者无法重播以前的有效负载，因为数据新鲜度也是在数据文件完整性的基础上验证的。尽管可以进行键旋转，但它是一种机制，用于在服务器受到攻击而不是受到保护的情况下从攻击中恢复。如果服务器受到威胁，现有用户将受到保护，如果他们已经在本地拥有公钥，而新用户试图建立到服务器的连接将成功连接，假设用户在第一次使用时没有关闭trust，认为它是可信的。成功攻击和恢复之间的窗口仍然可能导致大量用户盲目信任和接受攻击者的流氓密钥和元数据。一个适当协调的有针对性的攻击仍然可能是致命的。

原型实现需要安装并运行比特币软件，DDT才能正常运行。比特币区块链提供了一个RPC(远程过程调用)API，允许其他软件与它通信。例如，软件可以查询块或事务细节。不幸的是，当网络接收到一个新块时，RPC API不会执行实时通知，这对解决方案的实现至关重要。此外，与访问原始块文件相比，使用RPC API要慢一些。基于这些原因，我们构建了一个简单的块解析器供Carbonchain组件使用。在block文件中，通过扫描比特币区块链中的MagicId字段，可以找到block的开始。然后，通过研究比特币的源代码，解析器可以解析以下数据结构。

区块链解析器还公开了一些比特币区块链RPC接口。库中只包含了基本的RPC命令。原型只使用将事务发送到比特币区块链所需的RPC命令。区块链解析器还可以读取由比特币软件创建的LevelDB1数据库。该功能在第一个原型迭代中使用，但后来发现并不有用，因为读取的数据已经过期，因为只有当比特币区块链退出时，数据库才由比特币软件更新。为了弥补这一点，Carbonchain还负责维护一个功能类似于Bitcoin的LevelDB数据库的元数据数据库，以便有效地遍历块文件中的块。

Carbonchain主要负责完成以下任务:1)检测网络中添加的新块；2)记录块和事务在块文件中的位置(存入元数据数据库)；3)对块体进行验证，并将其连接在一起形成链；4)检测链叉并解决(如果可能)；5)提取OP返回数据(数据包)，如果数据包在添加到块之前被拆分，则进行合并；6)将组装好的数据包提供给程序(即DDT)。此外，Carbonchain还提供了将数据格式化为数据包并将其存储在区块链上的方法。使用这个库，使用它的程序将不必直接与区块链接口。它抽象出区块链概念，只公开接收和使用组装包的方法。如果需要，程序仍然可以访问底层的区块链以及通过Carbonchain生成的元数据。整个过程如图34-1所示。

Carbonchain的主要任务之一是不断地扫描到达的新区块。当块到达时，它将处理这些块。我们使用多个流程图来提高工作的质量。使用库时的主要流程如图34-3所示。该过程循环，直到用户退出程序。如果存在未处理的块，则在处理新块的步骤中处理这些块，包括1)扫描新块，2)读取块数据，3)保存到数据库中。

图34-1 区块链数据使用可视化

Carbonchain扫描块中的每个事务。然后，它记录下块的位置和引用块文件的每个事务，以便以后高效地查找。在这一步中，它还在OP返回脚本中查找用户可定义的前缀。这个前缀在库中称为包Id。如果找到了这个，并且校验和是有效的，这意味着在OP返回脚本中存储了一个包。它通过查看包Id来检查相关的负载。在包中，Id是包标识符。使用碳链库的程序需要指定这个Id，并确保它是惟一的。版本用于确定如何解析包。数据包的序列号从0开始。字段校验和是包中所有字段的CRC-64校验和，该字段设置为零字节。字段nextChecksum是下一个包的CRC-64校验和(如果没有下一个包，则设置为零字节)。字段数据是数据包的有效载荷。

当所有新块都被处理完后，Carbonchain将在存储到区块链之前被拆分的包组装成一个包，并将其缓存到其数据库中。然后，Carbonchain宣布这些新包对程序的可用性，然后程序可以对这些包做它想做的任何事情。Carbonchain不会从缓存中删除已组装好的数据包，而是让程序在使用时删除。需要注意的是，这些包是按照区块链中最后一个包的高度排序的。它确保以后以正确的顺序执行命令。包11在包34之后，因为它的底层事务属于区块链中较高位置的一个块。

基于TUF的分散实现具有防止单点故障和DoS攻击的优点。在某种程度上，它还消除了中央管理机构管理信任的需要，因此用户将不需要信任单个中央管理机构，而是将管理信任的任务留给分布式系统。分布式系统不仅可以用于验证Docker图像和任何其他数据类型。本文提出了一种基于区块链的分布式Docker信任模型。建议的解决方案包括基于区块链的分布式信任。该解决方案大大降低了DoS的风险，并为Docker图像提供了签名验证服务。通过大量的跟踪驱动仿真进行性能评估，实验结果表明了基于区块链的解决方案的可扩展性和效率。此外，还实现了分布式Docker信任(DDT)系统原型，并对其进行了性能评估。