这与以下帖子有些关系:对 sha1sum 的两个哈希输出执行 OR
。我有一组 TPM 测量示例,例如:
10 1ca03ef9cca98b0a04e5b01dabe1ff825ff0280a ima 0ea26e75253dc2fda7e4210980537d035e2fb9f8 boot_aggregate
10 7f36b991f8ae94141753bcb2cf78936476d82f1d ima d0eee5a3d35f0a6912b5c6e51d00a360e859a668 /init
10 8bc0209c604fd4d3b54b6089eac786a4e0cb1fbf ima cc57839b8e5c4c58612daaf6fff48abd4bac1bd7 /init
10 d30b96ced261df085c800968fe34abe5fa0e3f4d ima 1712b5017baec2d24c8165dfc1b98168cdf6aa25 ld-linux-x86-64.so.2
根据TPM规范,在上面的帖子中也提到,PCR扩展操作是:PCR := SHA1(PCR |||数据),即"将PCR的旧值与数据连接起来,对连接的字符串进行哈希处理并将哈希存储在PCR中"。此外,我发现的规范多篇论文和演示文稿都提到数据是要加载的软件的哈希值。
但是,当我执行类似 echo H(PCR)||H(data) | sha1sum
的操作时,我没有获得正确的结果值。 即,当计算(使用上述哈希): echo 1ca03ef9cca98b0a04e5b01dabe1ff825ff0280a0ea26e75253dc2fda7e4210980537d035e2fb9f8 | sha1sum
时,恢复值不7f36b991f8ae94141753bcb2cf78936476d82f1d
。
我对TPM_Extend操作的理解是否正确? 如果是这样,为什么生成的哈希与样本测量文件中的哈希不同?
谢谢!/n
回答你的第一个问题:你对扩展操作的理解或多或少是正确的。但是您有 2 个问题:
- 你
- 误解了你在这里复制的东西
- 你不能像在外壳上那样计算哈希
您在此处提供的日志输出来自 Linux 的 IMA。根据文档 第一个哈希template-hash
并定义为
template-hash: SHA1(filedata-hash | filename-hint)
filedata-hash: SHA1(filedata)
所以对于第一行:SHA1(0ea26e75253dc2fda7e4210980537d035e2fb9f8 | "boot_aggregate")
结果1ca03ef9cca98b0a04e5b01dabe1ff825ff0280a
.
请注意,文件名提示的长度为 256 字节 - 末尾填充为 0。(为从内核源代码中挖掘出这个竖起大拇指;))
所以要明确一点:在你的日志中没有PCR值。
我用Ruby写了一些东西来验证我的发现:
require 'digest/sha1'
filedata_hash = ["0ea26e75253dc2fda7e4210980537d035e2fb9f8"].pack('H*')
filename_hint = "boot_aggregate".ljust(256, "x00")
puts Digest::SHA1.hexdigest(filedata_hash + filename_hint)
现在来看你的命令:
您在此处使用它的方式是将哈希解释为 ASCII 字符串。另请注意,echo 将在输出中添加额外的新行字符。字符序列1ca03ef9cca98b0a04e5b01dabe1ff825ff0280a
为十六进制160 位二进制数据的编码 - SHA1 哈希值。所以基本上你是对的,您必须连接这两个值并计算结果的 SHA1320 位数据。
因此,命令行的正确命令类似于
printf "x1cxa0x3exf9xccxa9x8bx0ax04xe5xb0x1dxabxe1xffx82x5fxf0x28x0ax0exa2x6ex75x25x3dxc2xfdxa7xe4x21x09x80x53x7dx03x5ex2fxb9xf8" | sha1sum
printf 字符串中的xXX
会将十六进制代码XX
转换为一个字节二进制输出。
这将导致输出 d14f958b2804cc930f2f5226494bd60ee5174cfa
,这很好。