赛前热身第3期|「第十六届全国大学生信息安全竞赛」安全可信赛题

第二阶段练习指导

1 环境部署

本次练习开始阶段部署、密钥创建与分发过程比较复杂，这部分不列入考察内容，但如果想熟悉可信密码机制，这部分内容还是有学习价值的。想直接了解题目要求的可以使用镜像，直接进入tcm_quote.sh的运行状态，想深入学习的可以试着挑战一下环境重建。

如果代码完全按照预设目录进行部署，那么只要按照说明按部就班地进行，也不会遇到什么问题，但如果想通过gitee上下载源码来开发，选定的目录与缺省目录不同，配置过程中就会遇到不少问题。这里我们为有兴趣挑战环境重建的同学介绍一下系统几个源码间的关联关系。熟悉linux环境的同学从关联关系入手，能自主掌控环境部署。

建立可信密码模块练习环境总共需要下面五个软件包：

cube-1.3
gm_sm2_master
cube-tcm
cube_tcmplugin
tcmenv_exec

cube-1.3是通用可信软件基的框架，是可信计算功能实现以及赛题模拟的基础，它提供系统的基本库、基本数据格式定义、基础头文件、基本模块集合和主执行程序。因此，我们无论编译还是运行，都需要在环境变量里配置cube-1.3相关的内容（在cube-1.3下执行source set_env.sh)。

gm_sm2_master提供开源sm2算法库，这个编译后复制到cube-tcm相关位置上就不用管了。

cube-tcm既提供可信密码模块模拟器(vtcm_netlink_emulator)，也提供其驱动(vtcmd_dev)和外部访问库(locallib/bin/libtcm.so)，同时提供它的手动管理工具(vtcm_utils),编译cube-tcm和运行模拟器/管理工具时，需要cube-1.3的环境变量和在cube-tcm下的环境变量（在cube-tcm下执行source set_env.sh)。

cube_tcmplugin是本环境的精华部分，它将复杂的tcm访问功能封装成了一个个模块（src目录下为源码，plugin目录下为二进制模块）。编译这些模块时，需要设置cube-1.3环境变量后再设置自己的环境变量（在cube_tcmplugin下执行source set_env.sh)，另外cube_tcmplugin模块编译时，需要调用cube-tcm中的库，因此其set_env.sh脚本中有一行用来定义cube-tcm包的位置，这一定义需要与下载的cube-tcm路径一致才可以正确编译。

tcmenv_exec作为测试环境，其既需要编译也需要运行。编译时，同样需要设置cube-1.3环境变量后再设置自己的环境变量。设置自己环境变量有两种方法：所有功能模块和事件触发管理模块key_event不需要密码功能支持，因此可以用普通的环境设置（tcmenv_exec下执行source set_env.sh),key_manage有可信密码功能需求，需要在set_tcmenv.sh脚本中设置cube-tcm和cube_tcmplugin路径与当前路径一致，再执行source set_tcmenv.sh，即可到key_manage目录下进行编译。也可以都用set_tcmenv.sh支持编译。

tcmenv_exec下各实例运行时，可以类似编译程序完成环境变量设置后到实例目录下(instance下的最底层目录），运行cube-1.3/proc/main/main_proc程序，但这样由于实例较多，操作起来很复杂。因此我们提供了脚本执行方式，由脚本（如tcm_quote.sh)按次序驱动所要运行的实例，这种驱动方法使用的是cube-1.3/proc/main/envset_proc程序，可从配置文件中读入环境配置信息。但这些程序无法从命令行读入LD_LIBRARY_PATH指定的动态库位置。因此，需要run_cube.sh/run_cubetcm.sh分别对普通实例/访问tcm实例完成LD_LIBRARY_PATH配置库的路径设置，再运行envset_proc程序，该程序从exec_def下的各执行实例配置文件中读取实例运行位置和环境设置，并切换到对应实例运行位置进行运行。因此，为了让这些脚本能够正常运行，run_cube.sh中应有cube-1.3的正确路径，run_cubetcm.sh中应有cube-1.3，cube-tcm和cube_tcmplugin的正确路径，而exec_def中的文件，其cube-1.3,执行目录，实例目录，cube-tcm和cube-tcmplugin相关的路径都需要改成与实际一致。

2 可信报告实现流程

这里我们简单介绍一下在cube-1.3架构下，可信报告的自动化实现过程。可信报告机制运行之前，系统的tcm初始化以及用户密钥初始化过程应均已完成，参与可信报告操作的实例角色有五个，如下所列：

可信报告过程可以分为两个阶段，第一阶段如下图所示,user实例发送的可信报告命令在term实例接收前，被拦截后转到了server端，并被再次拦截后转给crypt_user，由其key_manage模块生成随机数作为防重放攻击数据返回term实例，然后term实例将消息交给key_event模块，准备正式进行可信报告过程。

第二阶段接续第一阶段，如下图所示：

该阶段消息key_event为报告添加了节点和用户信息(在（MESSAGE,INSTANCE_INFO)数据记录，然后消息被拦截到crypt_user,由其中的key_manage根据相关信息配成可信报告模板（TCM_PIK_DESC,PCRQUOTE),然后由pcr_multirw模块将pcr值读出后写入报告模板中，由quote_report模块完成报告生成。生成后的报告回到term实例，被转发给server端，由该端key_event模块接收后发送，被拦截到crypt_hub实例，由其的Key_manage完成报告内容存储，并提交给quote_report。quote_report完成验证，删去报告内容，将验证结果发给key_manage，key_manage解析报告内容，得到结论并将其经term实例返回給user。

通过观察各实例的message.log，我们可以追踪到上述处理过程。以第二阶段crypt_hub的key_manage最后接收信息位置为例，我们在运行成功后，打开crypt_hub的message.log,在最后一段可以找到如下信息：

这里蓝色框表示发送模块和接收模块，黄色框表示消息所在的路由（图中线路上标注），红色框表示消息的格式，绿色框表示扩展项的格式，均与上面消息路由图对应。

再看下一个消息的截图：

这里receiver_uuid后面接收端为一个uuid值，表示接收者为与本实例网络连接的另一个实例，下面红框部分则是解析结果，目前尚无实际数据，需要我们添加的代码把解析结果放在return_value这项中。

另外，这里的quote_report仅能根据用户信息获取密钥并验证报告完整性，其并不具备其它可信验证功能。因此，需要key_manage补全其它功能，并进行命令解析。

初始状况下,pcr取值为零，为了设置pcr取值，我们可以执行pcr_set.sh脚本，该脚本清零pcr后调用pcr_set实例向14号pcr寄存器写入数据。写入内容为crypt_hub/policy_list中列出的某几项数据的摘要值（return_value部分）：

修改写入内容可以通过修改instance/node/pcr_set/policy_write.msg来实现，下面为该文件的内容：

下面一行”return_value”取值含义为：14是指写入第十四个寄存器，后面两项则是我们选择写入摘要值的名称。可以替换、增加或减少摘要值名称以改变pcr写入内容。Crypt_hub端的Key_manage模块最终需要的也是验证可信后，确定寄存器值是由哪些策略组成，并产生类似的字符串通知上层。这里产生的结果应当与policy_write写入内容一致。