【问题标题】:Method to verify a signed archive's X.509 CoT验证签名档案的 X.509 CoT 的方法
【发布时间】:2017-01-28 23:34:05
【问题描述】:

我试图了解下载档案时验证信任背后的关键高级细节。

这是我对如何完成的理解:

在软件开发者方面:

  1. 从威瑞信等公共 CA 获取证书

  2. 生成存档的哈希,然后使用证书中的私钥加密此字符串,这就是“签名”

  3. 托管存档以供下载,以及一个单独的文件,其中包含证书中的公钥 + 步骤 2 中生成的签名。

在(用户)客户端:

  1. 下载解压压缩包,下载签名+公钥文件

  2. 使用下载的公钥解密下载的签名,保存这个值

  3. 遍历操作系统中嵌入的公共根证书。对于每个根证书,解密签名值并将结果与​​步骤 5 中的结果进行比较。

  4. 一旦在 6 中找到匹配项,您已验证作者的私钥来自您在步骤 6 中找到匹配的 CA 的信任链。

    • 这一切都假设软件开发人员使用了我们在客户操作系统中嵌入根证书的 CA。

问题:

  1. 上述方法是否合理,还是我忽略了关键细节?
  2. 给定一个您控制的空白客户端,如果我想将公钥 + 签名 + 存档组合成一个文件,我可以让客户端理解和解析,是否有任何广泛支持的格式可用于组织这些数据?

【问题讨论】:

    标签: security certificate x509 truststore


    【解决方案1】:

    除了对开发人员 (2) 过于具体(描述了 RSA 签名的工作原理,但 ECDSA 非常适合此任务)之外,这听起来更像是 Authenticode 减去了一些 EKU 限制。这让我问“为什么不使用 Authenticode 签名?”。

    我考虑的结构是PKCS#7/CMS SignedData 格式。它可以描述来自多个证书的多个签名(为任何可以阅读它的人签名 ECDSA-brainpoolP320t1-SHA-3-512 以及为我们大多数人签名 RSA-2048-SHA-2-256 和 DSA-1024-SHA- 1 适用于 2001 年制造的计算机)。

    对于数据文件,您可以正常使用 SignedData,对于可执行文件,由于存在语义部分,因此比较困难(因此您必须将其隐藏在某个地方并使用间接签名)。

    如果您使用 .NET 进行签名,PKCS#7/CMS SignedData 可用于通过 System.Security.Cryptography.Pkcs.SignedCms 进行签名和验证(尽管您可能必须在此之外定义自己的链信任规则类)。

    【讨论】:

    • 感谢回复,Authenticode 不是 Microsoft 操作系统特有的吗?客户端是运行 Linux 的 MIPS 架构板。
    • 嗯,这将是不使用 Authenticode 的一个很好的理由 :)。 SignedData 格式可能仍然是赢家。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-05
    • 2014-09-30
    • 2013-09-13
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多