使用 Google 的 Cloud HSM 签署可执行文件答案

【问题标题】：Using Google's Cloud HSM to sign executables使用 Google 的 Cloud HSM 签署可执行文件
【发布时间】：2019-06-26 20:09:54
【问题描述】：

我正在尝试查找一些有关使用Google's Cloud HSM 签署可执行文件的文档。我找到了一个相当 comprehensive guide for AWS CloudHSM，但 AWS 定价（> 1,000 美元/月）对于我们的用例来说似乎要贵几个数量级。

我能否将 AWS 指南（上文）应用于 Google 的 Cloud HSM 基础设施，或者我应该注意哪些显着差异？

【问题讨论】：

您可能还想查看与Azure KeyVault 一起使用的SignService。
Cloud HSM 集成到 Cloud KMS 中。使用 Cloud KMS 文档使用密钥对数据进行签名。对于一般信息，AWS HSM 是很好的信息，但您需要坚持使用 Google 文档来了解 Cloud HSM 和 Cloud KMS。 cloud.google.com/kms/docs/digital-signatures - 您能否阐明代码签名的预期目的。您的签名将不会被第三方识别。为此，您需要一个由 CA 支持的证书。
@jariq：感谢您的提示。您有服务经验吗？
@JohnHanley：我希望签署一个 Electron Windows 应用程序。我已经拥有 Digicert 的 EV 证书。
@DaveJ 我个人使用本地智能卡签名，但大多数.NET Foundation projects 都在积极使用 SignService，所以我想应该没问题。

标签： amazon-web-services google-cloud-platform code-signing electron-builder hsm

【解决方案1】：

根据您的项目和限制，您可以使用 java 的 org.bouncycaslte 进行代码签名操作。

对于 bouncycastle 有一个非常有用的 pdf：https://www.bouncycastle.org/fips-java/BCFipsIn100.pdf

根据您对可执行文件的签名方式，ContentSigner.java 提供私钥 API 签名

public class ContentSignerFactory {

    public static ContentSigner getContentSigner(Function<ByteArrayOutputStream, byte[]> lambda, String algorithm) {
        return new ContentSigner() {
            //This is to ensure that signature is created using the right data.
            ByteArrayOutputStream stream = new ByteArrayOutputStream();

            @Override
            public byte[] getSignature() {
                //Calling HSM here instead, the stream is the AttributeMap
                byte[] data = lambda.apply(stream);
                return data;
            }

            //Perhaps called by BouncyCastle library to provide the content
            @Override
            public OutputStream getOutputStream() {
                return stream;
            }

            @Override
            public AlgorithmIdentifier getAlgorithmIdentifier() {
                return new DefaultSignatureAlgorithmIdentifierFinder().find(algorithm);
            }
        };
    }
}

AWS HSM 也是每年 28000 美元，因为它们需要集群 HSM 才能允许自定义 KMS 存储

【讨论】：

【解决方案2】：

在我的工作中，我们这样做（并且由于某些技术原因，我们使用所有三个云供应商的 KMS 产品）。我们有一个专用的签名服务器，它代理 KMS 系统并根据我们尝试使用的密钥路由到适当的 KMS（即 AWS、Google 或 Azure）。我们还有加密服务提供商（例如，Windows 的 KSP、Java 的 JCE、macOS 的 CTK、Linux 的 PKCS11/OpenSSL 引擎等），它们将哈希发送到签名服务器，然后将其卸载到 KMS。最重要的是，它都可以使用我们通常使用的相同签名工具（例如，signtool、jarsigner、codesign 等），并且由于客户端散列，我们能够在亚秒级时间内登录。另一个不错的副产品是，我们能够从我们的 Active Directory 组成员中获取对密钥的权限，因为这一切都在签名服务器代理处处理。

【讨论】：

【解决方案3】：

对于 Windows 可执行文件签名 (Authenticode)，您可以使用 jsign，它支持 Google Cloud HSM 并可在 Windows 或 Linux 上运行（因为它是一个纯 Java 工具）。

【讨论】：