在 Java 中对 web-http 响应进行数字签名（使用 pgp）答案

【问题标题】：Digitally signing a web-http response in Java (using pgp)在 Java 中对 web-http 响应进行数字签名（使用 pgp）
【发布时间】：2010-12-23 20:40:10
【问题描述】：

我正在尝试对 http - Web 响应进行数字签名。本质上，我创建了 HTML 和多部分内容类型的响应，对响应进行签名，然后将数字签名附加到响应中。我想我已经接近但走了几步，因为这不是真正的 PGP 签名，因为附加的签名实际上是 HEXtoString。重要的是能够正确表示签名，以便可以正确解释响应。可以在这里使用一些建议，因为我对此很满意。在此先感谢.. 下面是我现在正在使用的代码的 sn-ps。

    StringBuffer myResponse = new StringBuffer("");
            myResponse.append(getHttpHeader());
            KeyPair pair2 = loadKeyPair();//loads a key pair from generated files

    if (signer==null)
        signer = Signature.getInstance("MD5withRSA");
    signer.initSign(pair2.getPrivate());
    signer.update(message.getBytes());
    byte[] b = signer.sign();
    FileOutputStream sigfos = new FileOutputStream(getFileLocation(0,localTest));
    sigfos.write(b);
    sigfos.close();
    //verify
    signer.initVerify(pair2.getPublic());//pubKey);
    signer.update(message.getBytes());
    if (signer.verify(b)){
        myResponse.append(message);
    }

    StringBuffer signed= new StringBuffer("");
    signed.append(boundary);
    signed.append(CRLF);
    signed.append("content-type: application/pgp-signature");
    signed.append(CRLF);
    signed.append("-----BEGIN PGP MESSAGE-----");
    signed.append(CRLF);
    signed.append("Version: 1");//update this
    signed.append(CRLF);
    signed.append(CRLF);

    signed.append(digSignature);//generated as HexString representation of signed file from above
    signed.append(CRLF);

    signed.append("-----END PGP MESSAGE-----");
    signed.append(CRLF);
    signed.append(boundary+"--");

            myResponse.append (signed);
            ServletOutputStream.println(myResponse);

传输的结果“签名”是签名文件的字节散列 hexToString 表示。我正在使用标准的 java 类，但不确定其他库是否会给我一个真正的 PGP 表示，其中包含 0-9a-f 表示之外的字符。想法？？

【问题讨论】：

这将成为标准的一部分。我也提出了同样的观点，但无法控制这一要求。这会迫使 Web 服务器在请求-响应中执行大量操作。

标签： java digital-signature pgp jce

【解决方案1】：

验证码是如何下载到客户端的？有关相关应用程序的更多详细信息？如果它是通过 HTTP 下载的验证脚本，那么该方案从根本上被破坏了。您可能需要使用 SSL，尤其是在您已经这样争论的情况下。

在不了解您的系统的情况下，听起来像是中间人攻击中的对手只需要：

将验证码中的公钥替换为自己的。
用自己的签名退出所有“安全”通信。
您的脚本没有发现任何问题，因为它检查的公钥已被攻击者修改。

更不用说所有通信都是纯文本的（所以希望没有个人/敏感信息被传输？）

SSL 解决了这个问题，因为所有证书都必须由 Web 浏览器信任的 / 安装的根证书颁发机构签署。 CA 应该只向控制/拥有它们的人颁发域证书；因此，之前的攻击将不起作用。

现在，如果您的客户端以受信任的方式安装，这样攻击者就无法篡改它，那么您可以继续您的计划并且仍然是安全的。例如，如果客户端手动安装在客户端 PC 上，或者以其他方式安全交付（例如通过 SSL 和/或使用代码签名）。

（我确实注意到了对 MD5 散列的引用。不要使用 MD5 散列；MD5 已被破坏。）

【讨论】：

SSL 用于通过 http 进行传输，但响应需要进行数字签名。因此，已经在请求中验证了用户，然后发送带有 PGP 签名的明确的多部分文本/html 响应。我了解您的 cmets，这应该是作为标准的一部分的另一种安全机制..耸耸肩..爱标准..我确实意识到我没有在 base 64（而不是十六进制）中编码签名。跨度>
关于 MD5 的使用，您可能需要查看schneier.com/blog/archives/2008/12/forging_ssl_cer.html
只要您的验证码和公钥安全地传递给客户端，那么我认为没有问题。正如您已经发现的那样，PGP 签名采用 base 64 编码。我假设您只需要对其进行签名，以便以后可以验证内容的作者，以防用户决定将内容保存到他们的硬盘驱动器？（如果内容不需要在 SSL 网络浏览器之外进行验证和显示，那么这个方案就没有意义了）。

【解决方案2】：

此问题是由 NAESB-EDI 标准引起的。如果文件已在 http 请求中提交，我们需要产生特定的响应。我们正在使用 SSL，原始有效负载应该是加密的。响应是纯 html（4 项），带有响应的附加数字签名。我想做的是创建响应，让现有的 pgp 软件根据生成的响应创建签名，然后将签名附加到响应中。因此，我不再使用 MD5，也不会将密钥公开给公众使用（我们专门交易的密钥除外）。所以詹姆斯的回答是部分正确的并且没有 SSL，由于响应是明文，因此几乎没有提供任何防止嗅探的保护。然而，如果请求中没有所需的信息，他们甚至不会得到适当的响应。可能不会得到回应（更不用说适当的回应了）。

【讨论】：