Question

这与帖子有点相关： Perform OR on two hash outputs of sha1sum

我有一组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 || data），即“将PCR的旧值与数据连接起来，哈希连接字符串并将哈希存储在PCR中。另外，我发现的多篇论文和演示文稿都提到数据是要加载的软件的散列。

但是，当我执行echo H(PCR)||H(data) | sha1sum之类的操作时，我没有获得正确的结果值。即，当计算（使用上述哈希）：echo 1ca03ef9cca98b0a04e5b01dabe1ff825ff0280a0ea26e75253dc2fda7e4210980537d035e2fb9f8 | sha1sum时，重新计算的值不是7f36b991f8ae94141753bcb2cf78936476d82f1d。

我对TPM_Extend操作的理解是否正确？如果是这样，为什么生成的散列与样本测量文件中的散列不同？

谢谢！ / N

Answer 1

回答您的第一个问题：您对扩展操作的理解或多或少是正确的。但是你有两个问题：

你误解了你在这里复制的东西
你不能像在shell上那样计算哈希

您在此处提供的日志输出来自Linux的IMA。根据 documentation第一个哈希值为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哈希值。所以基本上你是对的，你必须连接这两个值并计算结果的SHA1 320位数据。

因此命令行的正确命令类似于

printf "\x1c\xa0\x3e\xf9\xcc\xa9\x8b\x0a\x04\xe5\xb0\x1d\xab\xe1\xff\x82\x5f\xf0\x28\x0a\x0e\xa2\x6e\x75\x25\x3d\xc2\xfd\xa7\xe4\x21\x09\x80\x53\x7d\x03\x5e\x2f\xb9\xf8" | sha1sum

printf字符串中的\xXX会将十六进制代码XX转换为一个字节二进制输出。

这将导致d14f958b2804cc930f2f5226494bd60ee5174cfa的输出，那没关系。

如何用例如PCR值复制PCR值的扩展。 SHA1SUM？

1 个答案: