Linux下一种ELF文件的代码签名验证机制

　　当入侵者在系统取得一定权限后，他们通常会在系统中植入恶意代码，并利用这些代码为日后的入侵提供方便。增加或修改 ELF 文件正是入侵者植入恶意代码的常用途径。本文将描述一种 Linux 下 ELF 文件的代码签名及验证机制的设计与实现，这种机制能有效防止基于 ELF 文件的恶意代码的入侵，并同时提供了灵活的分级验证机制，使系统在安全性与效率方面取得最佳平衡。
　　
　　1 引言
　　随着 Linux 的不断发展，已有越来越多的人开始推广和使用 Linux，其安全性也受到越来越多的挑战。ELF（Executable and Linkable Format）[1] 作为 Linux 下最主要的可执行二进制文件格式，自然成了病毒及各种恶意代码的攻击目标。事实证明，有不少 Linux 下的病毒程序就是通过直接修改 ELF 文件的方法来实现入侵的 [10]。传统的 Unix 系统（包括 Linux）并不会对执行的代码进行完整性和合法性检测，因而让很多病毒程序以及木马程序有机可乘。
　　
　　代码签名验证是一种能够有效的防止病毒以及其他恶意代码入侵的方法。对于 Linux 下的代码签名验证机制，早几年就已经有人研究。文[2]提出了在安装时进行签名验证的方法，并通过修改 chmod 系统调用控制文件的可执行属性，但这种方法无法检测程序安装后对代码的任何修改，有一定的局限性。文 [3] [4] [5] 描述的都是在执行时进行签名验证的方法，其中 [4] [5] 采用了缓存已验证文件的策略，使效率较 [3] 有很大提高。但是，它们将所有 ELF 文件 "一视同仁"，没有主次轻重之分，缺少灵活性。
　　
　　本文提出了一种改进的基于 ELF 文件格式的代码签名验证机制，通过提供更加灵活的分级验证方式，进一步提高验证效率，并且使系统在安全性与效率方面取得平衡。
　　
　　2 签名验证原理
　　我们采用完全符合 PKCS [8] 系列标准的签名验证算法，并兼容所有符合 X509 格式的证书，以 RSA [6 ][7] 非对称密钥体制为基础来完成对 ELF 文件代码的签名验证。
　　
　　2.1 签名
　　设被签名的数据为 m，其数字摘要为 h。
　　
　　h = Hash(m)
　　
　　其中，Hash 是哈希单向散列算法，如 MD5、SHA-1 等。
　　
　　设 p，q，d 为签名者的私有数据，他们都包含在签名者的私钥 SK 中；n，e 为签名者的公开数据，并且都包含在签名者的公钥 PK 中。这些数据满足以下要求：
　　n = pq 其中 p ≠ q，p q 均为大素数；e,d∈RZn 并且 e = d-1，ed ≡ 1mod(n)；这里，(n) = (p-1)(q-1)。那么，使用签名者私钥对 h进行加密即可得到签名值 s：
　　
　　s = E(x) = hdmod n
　　
　　2.2 验证
　　设被验证数据为m′，其数字摘要为h′。
　　
　　h′ = Hash(m′)
　　
　　假设我们已经取得签名者的真实公钥PK，然后我们使用PK中的公开数据e对s进行解密计算，得到还原的数字摘要h′′，这里h′′就相当于是○1式中的h。
　　
　　h′′ = D(s) = se mod n
　　
　　现在，我们比较 h′和 h′′是否完全相同。如果相同则验证通过，否则验证失败。
　　
　　3 设计与实现
　　为了便于描述，我们引入以下几个基本概念：
　　
　　1. 完全摘要值--指对 ELF 文件的所有数据以及签名相关数据计算出来的摘要值；
　　
　　2. 不完全摘要值--指对 ELF 文件的一部分重要数据（主要是 ELF 文件头）以及签名相关数据计算出来的摘要值；
　　
　　3. 完全签名值--指对完全摘要值加密所得到的签名值；
　　
　　4. 不完全签名值--指对不完全摘要值加密所得到的签名值；
　　
　　5. 系统验证级别--指系统级的验证级别，它适用于系统中所有的 ELF 文件；
　　
　　6. 文件验证级别--指单个 ELF 文件的验证级别，它只适用于指定的某个 ELF 文件。
　　
　　签名相关数据是指原始文件大小、签名者公钥标识 ID、签名算法、签名时间以及签名者基本信息等数据。
　　
　　3.1 签名策略
　　对 ELF 文件的签名是通过签名工具完成的，与操作系统核心无关，同时也和平台无关。签名过程完全遵循第二节中所描述的标准和原理。
　　
　　首先，我们通过 ○1 式计算得到两种摘要值：不完全摘要值（hpart）和完全摘要值（hcomp）。然后再通过 2 式使用签名者私钥（SKsign）加密摘要值，从而得到两种签名值：不完全签名值（spart）和完全签名值（scomp）。
　　
　　最后，我们将不完全签名值和完全签名值按照固定的格式组合在一起，并放在被签名文件的末尾。如图 3-1 所示（括号中的数字表示该字段所占字节数）。
　　
　　图 3-1 代码签名过程及签名值存放
　　　
　　3.2 验证策略
　　对被执行 ELF 文件签名值的验证是根据"系统验证级别"和该文件的 "文件验证级别" 二者进行的。"文件验证级别" 是为单个文件设置的验证级别，共分为 3 个级别，分别由 0~2 表示。"文件验证级别"保存在每个文件的 inode 节点标志中，系统管理员可以根据需要设置文件的验证级别。"文件验证级别"的具体含义如表 3-1 所示。
　　
　　表 3-1：文件验证级别
　　　
　　"系统验证级别" 分为四级，分别由 0~3 表示。"系统验证级别" 通过 PROC 文件系统来进行控制，可以由管理员根据需要进行设置。"系统验证级别" 的具体含义如表 3-2 所示。
　　
　　表 3-2：系统验证级别
　　　
　　3.3 验证算法
　　当用户请求执行某个 ELF 文件时，系统将根据图 3-2 所示的流程来判断如何验证该文件的签名值。为了提高系统效率，我们将分别为已验证过 "不完全签名值" 和 "完全签名值" 的 ELF 文件维护相应的缓存，当再次请求执行这些文件时，就可以不必重复验证其签名值了。
　　
　　图 3-2：系统级签名值验证机制
　　　
　　图 3-2 中，"验证不完全签名值" 和 "验证完全签名值" 两项都是整个验证过程的重要步骤。签名值的验证与签名值的生成相对应，验证时首先要根据相应的数据通过 3 式计算出摘要值（h′part 或 h′comp），然后再使用签名者的公钥（PKsign）通过 ○4 式解密相应的签名值，得到的对应的摘要值（h′′part或h′′comp）。最后比较 h′和h′′是否完全一致，一致则验证通过，不一致则验证失败。
　　
　　3.4 公钥管理
　　在解密签名数据时，需要用到签名者的证书公钥。由于可能存在多个签名者签发的代码，因此也就存在多个签名者的证书。为了节省系统开销，尽量减小对系统性能的影响，我们必须高效地管理这些证书公钥。为此，我们在系统核心空间中维护了一个信任公钥链表，所有被信任者的公钥都将被放在该公钥链表中。当系统验证代码的签名值时，就可以直接从公钥链表中取得相应的公钥。如果公钥链表中没有相应的公钥，则表示该代码的签名者不被信任，因而验证失败。系统中的被信任公钥是可配置的，系统在启动时将根据配置文件自动初始化核心公钥链表，系统管理员也可以随时对其刷新或者修改。
　　
　　3.5 软件结构
　　本机制的实现主要包括用户空间的签名验证工具和核心空间的签名验证机制模块两个部分。其中，用户空间的签名验证工具是本机制的辅助工具，其主要功能是对 ELF 文件进行签名和设置，同时也可对 ELF 文件的签名值进行验证，在此不再赘述；核心空间的签名验证机制模块可以分为验证策略模块以及公钥管理模块。
　　
　　3.5.1 验证策略模块
　　
　　验证策略模块负责执行签名值的验证策略，同时负责管理已验证文件的缓存链表。当用户请求执行 ELF 文件时，该模块就会执行如图 3-2 所示的验证策略。
　　
　　验证签名值时，系统将首先查询已验证文件缓存链表，如果发现被验证文件已经被验证过，那么就不必再进行重复验证，直接采用上次的验证结果。如果缓存链表中没有被执行文件，那么就向公钥管理模块请求签名者公钥，然后再验证其签名值。如果验证正确，则说明被执行文件是完整和可信的，就让其执行；否则就禁止执行。
　　
　　另外，为了保证已验证文件缓存链表和实际文件的一致性，我们必须监视 ELF 文件的修改情况，当某一 ELF 文件被修改时，我们应当立即清除已验证文件缓存链表中与该文件相关的验证结果。
　　
　　3.5.2 公钥管理模块
　　
　　公钥管理模块主要负责对信任公钥链表进行管理，如：初始化链表，获取、添加以及删除公钥节点等。
　　
　　信任公钥链表由一系列的公钥节点组成，如图 3-3 所示。
　　
　　图 3-3 核心公钥链表
　　　
　　其中 key_id 是对应公钥的 MD5 哈希值，长度为 16 个字节。从理论上说，不同公钥的 key_id 相同的概率接近于 2 128 分之一。在很大范围内，我都可以认为 key_id 和公钥是一一对应的。因此，我们将 key_id 作为每个公钥的唯一标识。
　　
　　3.6 性能测试
　　表 3-3 是一组简单的测试数据，这些数据是通过多次执行后取得的平均值。从中可以看出，通过使用分级机制和缓存机制，系统开销增加不到 5%，大大减小了对系统性能的影响。
　　
　　表 3-3 验证签名的系统开销
　　
　　
　　环境：CPU PIV 1.7G，Kernel linux-2.4.18，签名密钥长度为 1024 位。
　　
　　4 结束语