小白眼中的可信计算-石器篇

菜鸟语录

    文章中有不当之处，还望嘴上轻喷，手下留情。工作中偶然学习到可信计算的一些东西，觉得有趣，萌生了做笔记的念头，接下来让我们从工程研发的角度来了解一下可信计算吧。

---

可信？what's that?

    聊可信计算之前先想象一下什么是可信与信任，我相信博客平台，于是注册账号写下了这篇文章，这个过程，博客平台对于我和我们而言就是可以信任的。   
    如果现在有一个未知的博客网站让我们注册、翻阅和分享，我们还会不会这么坦然的吹水，我们就会有无限的遐想，手机号会不会泄漏，蒙面的键盘侠会不会顺着网线瞄着IP过来撬了我家的门锁。  
    现在，我们对可信有了初步模糊的概念，我们会觉得，在日常生活中，信任的前提就是了解。我们认识并了解了某个事物，我们才可能去选择信任他。那到底该相信谁，怎么相信呢？  
    举个例子，小黑向小白借钱，小白相信他，借了1毛钱，小黑相信小红，借给了红红1毛钱，这时候小红找到小白要借1块钱巨款，虽囊中羞涩，可小白还是借给了她。我们可以看到，在这个套路朋友的过程中，一方面信任产生了传递，另一方面“小黑正直的人品”成为了整个信任的起点。
    这时候有个叫TCG的组织对可信进行了描述：“如果一个实体的行为总是按照预期的方式和目标进行，那它就是可信的”。TCG没听过？他的曾用名好像叫TCPA，也没听过？不要紧，如果还有后续我们再介绍他。

    重点来了，发散一下我们的思维，人与人之间有信任关系，经济、金融、贸易等一切有交换关系的场景也存在信任关系，那传统的计算机体系中是否也存在信任关系？

---

美妙的信任初体验

小白之前写了一个很nice的程序，特效吊炸天的那种。有一天，在正常演示nice的时候，出现了一些只可意会的紧急状况。leader，leader的leader,leader的上上级leader（公司领导栈空间充足，此处可递归），经过各方势力角逐（甩锅），最终发现nice调用的A.so被一个小哥哥错误升级了。

./nice
业务404！
数据库被损坏！
系统死机啦!

    喂喂，我只是一个业务程序而已，死机了，过分了哈！小白很苦恼，很无奈。咋办呢？？？  

    机智的小白想到了一种方法，他修改了自己珍爱的nice，采用了dlopen的方式调用A.so。并在调用之前，使用sm3（注意！这是国密哈希杂凑值算法）对A.so进行了真爱判别。简单的判别流程就是：

• 对原配A.so的文件内容进行哈希杂凑址计算
• 修改nice的ELF文件结构（忘记说了，小白是个linux菜菜），在段表中加入真爱段,真爱段保存着之前计算的杂凑值
• 当nice加载A.so的时候，计算当前A.so的哈希杂凑值并与真爱段中的原配杂凑值进行比较。一致则调用dlopen，dlsym进行加载，不一致则抛出告警。

echo "541b456e541b45541b456ea2653abae3eb6ea2653abae312eba2653abae3eb" > ./sm3hash.txt
objcopy --add-section .love=sm3hash.txt --set-section-flags .love=contents,readonly nice
./nice
A.so已被破坏，安全部速来排查！！！

    完美的解决方案，小白给全公司做了汇报。汇报会上，小黑犯愁了。黑黑是凋库小能手，一个程序一堆依赖库，升级任意一个库都得来回改程序结构，太麻烦了。最主要的是nice程序本身被篡改了怎么办呢？  
    嗯，非常有道理，校验动态库合法性的代码是放置在nice程序里面的，谁来保证我们这部分校验代码的安全，证明其自身的可信？

---

内核来帮忙

    某天，小白发现了一个叫digsig的东西，他是一种可装载的内核驱动模块，利用hook技术进行应用程序启动度量、动态库加载度量等。简单来说就是事先利用签名机制将ELF格式的可执行程序和动态库进行标记，然后在内核驱动层进行验签。  
    让我们捋一下这个过程：

    首先对我们想相信的程序进行签名，签过名的就是我们所信任的。所以这个过程我们称之为信任数据收集，也可以叫可信基准值收集。
那这时候要是电脑已经被破坏了怎么办？有没有不用收集的方法呢？大哥，请看这只是石器篇，升级的事交给青铜吧！简单粗暴一点，我就是信任你，没商量。好了，我们发现可信基准值已经有了。

    然后就天真的把digsig_verif.ko装载到内核中。
    于是在系统运行期间，digsig_verif.ko就开始了他的信任度量生涯，也就是可信度量。

签名工作

    上面我们简单提到了对程序进行签名，我们在这里主要使用了bsign命令来完成可执行程序和动态库的签名。签名的本质是使用gpg命令对可执行文件进行签名（先sha1算个哈希值，然后祭出RSA的私钥加个密），在ELF可执行文件里面加入了512字节的签名段。好了，下面有一副小白珍藏已久的美人图，大家随意欣赏：

    小白在查阅bsign代码的时候，发现bsign在遍历目录的时候使用了fts_open、fts_read等函数，虽不在POSIX标准里面，相比较小白常用的opendir来说，非常好用。以后再有遍历目录的需求，就可以直接白嫖了。对了，如果这些函数坑过你，请一定转告小白。

度量工作

    接下来轮到digsig了，好家伙，100多个文件，代码中提到的sys文件系统的节点创建，还有签名值缓存的创建（使用了kmalloc，为啥不用kmem_cache_create呢）和各种处理代码，验签部分的代码，一行一行分析，写到升天篇也完结不了。文章开头小白就开诚布公了菜是原罪，只能管中窥豹、走马观花一番，还是粗略看下hook点吧，毕竟这才是信任验证的地方。当然了，有兴趣的牛牛们还是可以去读一下的，读完后再狠狠的嘲笑他，侮辱他。  

    digsig主要利用了linux的lsm框架，分别在file_mmap, file_free_security, inode_permission, inode_free_security和inode_unlink等地方进行了注入。小白发现，这里直接就进行了register_security，好像忘记了关闭写保护，想尝试的朋友们不可以这么粗心哦，自行关掉cr0的WP bit即可（第20位）。  是时候再献出我的美人图了，请欣赏：

尾记

    小白汇报给了领导，大家一致认为相较之前野蛮的objcopy，digsig的方式还是挺柔和而优雅的，像极了三月的雨、四月的风......。  

    喂喂，小白，思绪快回来，这是一场严肃而认真的技术分享。好吧，我承认刚刚跑题了，下面让我们简单做个致谢，哦，不，是总结！  

    以上的废话连篇中，我们找出来了一种度量手段，依靠这种手段我们拥有了可以信赖的基准值和判定方法。系统运行过程中，应用程序的启动、动态库的加载，同时包括驱动的装载（本文未提及）是无时无刻不在进行的，当系统运行并与磁盘文件，如可执行程序、动态库等产生交社的瞬间，我们的digsig开始了信任甄别，符合信任标准放行，不符合信任标准的话，那就只能say抱歉。  

    现在，计算机体系下的可信，好像更近了一点。那这就是可信计算了吗，不要天真了，少年，这远远不是。充其量只是开胃小菜，与可信计算相比的话，可能连砖头都算不上。婆娑盘踞在荧光屏里面的是一个缩影，如果非要给一个称呼的话，我们可以叫他糙汉子TEE。

    小白会继续不遗余力的学习可信方面的知识，下次再和大家交流。