无忧启动论坛

标题: [转]x64系统启动时的数字签名检测算法和实现 [打印本页]

作者: sunsea 时间: 2013-3-30 18:03
标题: [转]x64系统启动时的数字签名检测算法和实现
数字签名想必大家都很熟悉了.就不再废话介绍了

数字签名系统中最重要的文件就是.cat后缀的文件
大家的驱动安装基本上是3种文件
第一种当然是驱动本身.sys文件
第二种就是.inf文件了
最后一种也就是数字签名使用的文件.cat文件

cat文件是一个符合ASN.1规范的文件(ASN = Abstract Syntax Notation one)
asn.1是一个描述数据的表示、编码、传输、解码的灵活的记法的规范
详细的内容大家可以google一下
这里只是简单的作个介绍

ASN.1格式是由一个一个的小元素拼接成的
每个小元素包含3个部分
(tag,length,data)

tag用来描述这个小元素是个什么类型(比如是int,是bool,是string等等)
length用来描述data部分的长度
data当然就是数据本身

微软的cat文件使用基本编码(BER = Basic Encoding Rules)规则来编码
这是比较简单的编码规则
简单介绍一下
tag:基本长度是一个字节.这个字节分成2个部分.如果[bit0,bit5) = 0x1f则这个tag要占据多个字节,否则tag就只是占据一个字节,[bit5,bit7]表示类型信息
length基本长度也是一个字节.如果这个字节的值 & 0x80 是非0的,也就是说他的最高位是1,那么这个长度也是要占多个字节.长度是这个字节的值&0x7f
接下来的数据是big-endian的长度

例子
0x06 0x01 0x78 0x02 0x81 0x03 0xa1 0xa2 0xa3

首先看第一个字节是0x06,他& 0x1f不等于0x1f,所以这个tag只是占据一个字节
接着看第二个字节是0x01,他最高位是0,所以这个长度也只是一个字节.他表示后面的数据长度是0x01
第三个0x78就是data
第一个小元素完结

接下来是0x02.同样的是单字节的tag
然后是0x81,他最高位是1,所以这个length占用多个字节..length本身数据的长度是0x81 & 0x7f也就说length本身的长度是1个字节
那么接下来的这个字节就是length,他等于0x03.所以后面的数据长度是3
接下来的0xa1,0xa2,0xa3就是数据
第二个元素完结...

如此循环流水分析就能把一个缓冲区分成若干个(tag,length,data)数组
最后要提一下的就是tag.
他有一个比较重要的特点就是如果他的bit5被设置成1,也就是说& 0x20非0
那么表示这个元素是一个容器..他包含有子元素
比如
0x30 0x06 0x02 0x04 0xd1 0xd2 0xd3 0xd4

首先第一个字节tag = 0x30.他的bit5是1,那么他是个容器
他的长度是0x06.也就是后面全部的数据都属于他
也就说他的数据是0x02 0x04 0xd1 0xd2 0xd3 0xd4
这个容器包含的数据本身仍然是BER编码的数据
继续解析tag = 0x02,length = 0x04,data = 0xd1 0xd2 0xd3 0xd4

体会这两个例子的不同
前一个例子的两个元素是平等的关系
后一个例子的两个元素是包含被包含的关系

因为有这个包含关系.asn.1格式的数据就能构成一个树状的结构

asn.1就介绍到这里..详细的信息请google

cat文件的基本格式大家了解了:他是使用BER编码的asn.1格式
那么cat文件里面究竟有些什么东西呢?

大体的讲.cat文件包含有3份重要数据
1.就是这个cat文件所签名的hash数据.如果A.cat用于签名b.sys,那么b.sys的hash数据就会保存到a.cat里面
2.就是这个cat文件签名时候使用的证书.通常的这个证书的父证书,祖父正式,也就是整个证书路径里面的全部证书数据都会放入到cat文件里面
3.就是签名者的信息

第一部分就是用来判断一个文件是否是被这个cat文件所签名的信息
第二部分是用来验证这个cat文件本身是否合法的
第三部分是签名者的信息.他提供一个线索把第一第二部分衔接起来

那么现在的问题有2个
1.如何判断一个文件是被签名的
2.如何判断某个cat文件是合法的

首先回答第一个问题
windows的cat文件都在一个目录下面
windows\system32\catroot\{F750E6C3-11D1-85E5-00C04FC295EE}\
如果一个文件是被正确签名的.
那么总是能在这个目录下面找到一个cat文件里面有那个被验证文件的hash值
注意.windows并不维护"某个文件被另外某个文件签名"这样一个一一对应的信息
而是每次都遍历全部的cat文件一一查找hash值看是否包含在cat文件里面
只要找到一个cat文件包含hash值就认为文件被签名了
同时的.windows只是检查hash值而不检查文件名..
所以你会发现同一个文件你只是修改名字而不动文件内容.他是否签名的属性是不变的

接着出现新的问题
如何计算某个文件的hash值?
这里我们只是讨论exe,sys这种可执行文件的hash计算方法.而不讨论inf文件的计算方法
首先hash算法是使用的SHA1
他的hash结果是一个20字节的数据
一个可执行文件的计算非常简单
注意这里的计算必须放在重定位之前

1.SHA_Update(ImageStart,&NtHeaders->OptionalHeader.CheckSum)
也就是从文件开始直到checksum.
2.SHA_Update(&NtHeaders->OptionalHeader.CheckSum + 1,ImageCertDataDirectory);
跳过checksum开始直到cert data dir 他的index = 4
3.SHA_Update(ImageCertDataDirectory + 1,ImageStart + FileHeaderSize);
跳过cert data dir直到文件头结束

也就说忽略checksum和cert data dir的1 + 2 个UINT32的数据

接下面SHA_Update每个section的raw data,长度也是raw的长度不要往上取2的倍数

最后SHA_Update剩下的文件数据.但是不要计算嵌入到pe文件里面的cert data
嵌入到pe文件里面的cert data总是在文件的末尾
他的大小和偏移由cert data dir指出.这部分的数据是不能hash的

这样计算出来的最终结果就是文件的hash值
详细的计算可以参考附件里面的代码

明白了可执行文件的hash计算方法和cat文件的大体情况以后
就来说一点具体的cat文件的内容
回忆cat文件最主要的3个部分
下面一个一个的来分析
首先是证书.
cat文件会打包全部使用到的证书到他里面(位于证书路径上的全部证书)
(什么是证书路径?找一个你系统里面的cat文件双击一下.出来的对话框点"显示签名"然后点"显示证书",然后切换到"证书路径"看一看)
那么每个被打包到cat文件里面的证书信息都包含什么内容呢?

大体被分成了3个部分
1.证书本身的信息.比如是哪个ca发布的这个证书.这个证书的public key是什么等等
2.验证这个证书信息使用的hash算法是什么..通常这个都是SHA1算法
3.验证这个证书是否是合法的数据.这个数据是一个RSA加密后的数据

那么一个证书是如何被验证是否合法的呢
先回答第三个部分的数据是怎么生成的
很简单
首先用第二部分的hash算法计算第一部分的hash值.然后用这个证书的父证书的private key加密这个hash值,加密的结果就是第三部分
那么验证办法就很简单了
在确保父证书合法的情况下使用父证书的public key解密这个第三部分,解密的结果跟第一部分的hash值比较,如果相同,那么就是合法的,否则就不合法

注意父证书的public key在父证书的第一部分里面.所以使用这个public key之前需要确保父证书是合法的
确保父证书的合法也就要确保父证书的父证书的public key合法.这样一直回溯到root证书.
那么如何保证root证书合法呢?root证书的public key是硬编码到bootmgr.exe和winload.exe文件里面的
保证root证书的public key就是要保证bootmgr.exe合法
这样听起来有点像先有鸡还是先有蛋的问题
不过这也是现状..并没有一个完美的确保这个验证链正确的方法.因为没有人来确保bootmgr.exe是合法的

那么你也许要问..怎么知道哪个证书才是自己的父证书呢
回答这个文件之前首先细化一下证书的第一部分数据
第一部分是证书本身的信息
这个信息里面重要的部分有
1.发行机关的名字
2.序列号
3.public key
4.自己这个证书的名字

看过上面4个部分你也许就明白了...
如果A证书是B证书的父证书
那么A证书的.4也就是A证书的名字等于B证书的.1发行机关的名字

同样的
如果一个证书的发行机关的名字等于自己的名字.那么这是一个root证书

证书信息明白了吧?
cat里面的证书信息首先他是一个数组
这个数组里面的每一个元素代表了证书路径上的一个证书信息
每个证书里面最重要的是他的public key.
证书的合法与否是要用他的父证书的public key验证的.
如果你想修改证书的内容,那么你需要父证书的private key来重新RSA加密证书信息的hash值.

证书信息是个数组
那么究竟是这个数组里面的哪个元素才是当前这个cat使用的呢?
这个cat使用的证书信息的public key是要用来验证其他数据的(比如文件的hash值).所以这个信息很重要
这个信息就是放到签名者信息里面的

签名者的信息里面都有什么呢
1.首先就是发行者的信息
2.然后就是序列号....这两个数据合起来去跟证书的.1发行机关和.2序列号比较..如果相同就表示这个cat文件是使用的这个证书来签名的(记住这个信息)
3.hash算法.这个hash算法的使用方法见下
4.签名者的属性信息,这个是可选的
5.RSA加密以后的数据.使用cat文件使用的那个证书的public key解密

要回答签名者信息的验证和使用方法需要先看看cat文件的3个重要数据里面剩下的那个没有详细介绍的部分
也就是cat文件的第一部分
我们称呼这个部分叫着签名数据
这个部分最重要的部分是一个数组
这个数组记录了许多属性数据
这些属性数据包含一些比如文件名字阿,操作系统版本号阿一类的数据
当然了被签名的exe,sys文件的hash值也是放到这个属性数据里面的
也就说这个签名数据里面有一个hash值的数组
数组里面的每个元素记录了一个hash值.这个hash值是某个文件的hash值
比如某个cat文件一共签名了5个文件
那么这个数组就有5个元素.每个元素都对应5个文件其中的某一个文件的hash值
回想签名判断的方法
就是遍历这个属性数组,一一比较数组里面的每个元素.只要找到一个相同的.就可以判断文件是被正确签名的

显然这个属性数组必须先被验证是合法的才能使用他
那个这个属性数组是如何被验证的呢?

很简单.
1.首先计算这个属性数组的hash值..hash算法使用签名者信息的第三部分记录的hash算法(往上拉看看签名者信息的内容)
2.然后看看签名者信息里面有没有属性信息(第四部分那个可选数据)
3.如果有
   那么这个签名者属性信息同样是个属性数组.其中必须有一个元素是等于前面计算的hash值的.如果没有.那么cat文件就是不合法的
   如果在签名者属性信息里面找到了刚刚计算的hash值.那么最终的hash值就是签名者属性信息的hash值.(hash算法还是使用签名者信息里面的hash算法)
4.如果没有
   那么最终的hash值就是前面计算的hash值
5.接着取出签名者信息里面的发行机关和序列号数据去证书数组里面寻找对应发行机关和序列号的证书.我们需要他的public key
6.使用上一步找的证书的public key解密签名者信息里面的第五部分数据
7.解密以后的结果跟第3或者第4步的最终hash值比较.如果相同就表示签名者信息和签名数据都是合法的.否则就是不合法的cat文件

注意这里使用了证书的public key,所以首先要保证这个证书是合法的.
如果你想修改签名数据数组里面的某个hash值.你需要对应证书的private key

回忆一下整个cat文件被验证的过程
体会一下一环扣一环的验证程序...
明确如果你要修改什么什么就需要什么什么的private key

可以看到关键的数据都经过hash然后RSA加密过.如果你要修改他们就需要private key
而从public key计算private key目前来讲是个不可能完成的任务

最后了..所谓"自签名"是什么意思呢?
自签名就是说原来放到cat文件里面的数据被放到了pe文件里面
当然有些小修改..
原来cat文件可以签名若干个文件.所以签名数据里面是个属性数组
而嵌入到pe文件里面的数据显然只是用来签名这一个pe文件
所以签名数据就不再需要是一个数组了.而是一个单独的元素

cat文件的描述就到这里了.下面是一些关于vista的背景知识
=====================================================================
Winx64的启动过程分成4个部分
第一个部分是bootmgr.exe加载运行
第二个部分是bootmgr.exe加载诸如winload.exe这样的boot application,并运行他们
第三个部分是winload.exe加载内核,hal,boot driver然后把控制权交给内核
第四个部分是内核加载其他驱动并完成启动

所以签名验证也是4个阶段
第一个阶段是bootmgr.exe验证他自己...显然这里有问题.自己验证自己.并不能保证一定是正确的
第二个阶段是bootmgr.exe验证winload.exe等等
第三个阶段是winload.exe验证内核,hal,boot driver
第四个阶段是内核验证其他驱动程序

其中第一和第二个阶段是bootmgr.exe来验证的.这个时候bootmgr不能加载cat文件.所以要求这个阶段被验证的文件都必须是自签名的
第三和第四个阶段可以加载cat文件,所以这个阶段是可以不用自签名的(微软说boot driver必须自签名?似乎不对?)
那么bootmgr都通常会加载些什么?最常见的就是winload.exe,然后就是当你从休眠中恢复的时候会是另外一个exe文件.但是不会是你的驱动

第一第二第三部分的验证都是由bootmgr.exe和winload.exe本身完成的
第四部分是由ci.dll来完成的.同时第四部分跟前三个部分有个显著的不同就是他对cat文件的解析要丰富得多
而不像前三个部分那样只是作最基本的解析..不过算法是一样的.没差别的

最后最后..Winx64限制死了root证书的发行机关必须是若干个有限的root
这个受信任的root个数是个常变化的值
比如rc1的时候是5个
到了正式版就是8个
而bootmgr和winload和ci.dll使用的受信任的root又有微小的差别

========================
不好意思...原来这里搞错了.修改一下
========================
综合我手上的各个版本的bootmgr和winload和ci收集一下一共有9个可能的root如下
Microsoft Authenticode(tm) Root Authority
Microsoft Root Authority
Microsoft Root Certificate Authority
Microsoft Test Root Authority
VeriSign Commercial Software Publishers CA                      某个beta的vista的efi版的bootmgrfw.efi和winldfw.efi使用了他.其他都没有使用过
Microsoft Code Verification Root
Microsoft Digital Media Authority 2005
MS Protected Media Test Root                                                 要求test signing
Microsoft Digital Media Authority 2005 for preview releases

如果一个驱动是被签名的.但是root证书并不是微软要求的受信赖的root的时候会是怎么样子的呢?
如果是正常启动..那么就认为这个签名是非法的
如果是是test signing..那么认为这个签名是合法的

最后最后最后
证书是被打包到cat文件里面的
所以整个证书路径上的证书都必须打包到cat文件里面....
启动时候是不会去读取注册表里面的cert store信息的.......
如果cat里面并不包含需要的全部证书...那么这个结果等同与你使用了一个不受信赖的root

所以
想不修改配置就使你没签名或乱七八糟的签名的驱动在x64下正常工作
基本是不可能的

源地址：http://bbs3.driverdevelop.com/read.php?tid-113264-ds-1.html#tpc

[ 本帖最后由 sunsea 于 2013-3-30 18:08 编辑 ]

欢迎光临无忧启动论坛 (http://wuyou.net/)