在 Java 中对 Web-http 响应进行数字签名（使用 pgp）
我正在尝试对 http 网络响应进行数字签名。本质上，我创建 HTML 和多部分内容类型响应，对响应进行签名，然后将数字签名附加到响应中。我想我已经很接近了，但还差几步，因为这不是真正的 PGP 签名，因为附加的签名实际上是 HEXtoString。最重要的是能够正确表示签名，以便正确解释响应。可以在这里使用一些建议，因为我对此相当陌生。预先感谢..下面是我现在使用的代码片段。
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 表示之外的字符。想法？？
I am trying to digitally sign an http - web response. Essentially, I create the HTML and multipart content-type response, sign the response then append the digital signature to the response. I think I am close but off a few steps as this is not a true PGP signature since the appended signature is actually HEXtoString. Big thing is to be able to represent the signature correctly so that response can be interpreted correctly. Could use some suggestions here as I am fairly green with this. Thanks in advance.. below is snippets of code I am using now.
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);
The resulting "signature" that is transmitted is a byte-hashing hexToString representation of the signed files. I am using standard java classes, but not sure if other libraries would give me a true PGP representation with characters outside of the 0-9a-f representation. ideas??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
验证码是如何下载到客户端的？有关相关应用程序的更多详细信息？如果它是通过 HTTP 下载的验证脚本，那么该方案就从根本上被破坏了。您可能需要使用 SSL，尤其是如果您已经这样争论的话。
在不了解有关您的系统的更多信息的情况下，听起来中间人攻击的对手只需：
更不用说所有通信都是纯文本形式（所以希望没有传输个人/敏感信息？）
SSL 可以解决这个问题，因为所有证书都必须由受 Web 浏览器信任/随 Web 浏览器安装的根证书颁发机构签名。 CA 应该只向控制/拥有域的人颁发域证书；因此，之前的攻击不会起作用。
现在，如果您的客户端以可信方式安装，使得对手无法篡改它，那么您可以继续您的方案并且仍然安全。例如，如果客户端手动安装在客户端 PC 上，或者以某种其他方式安全地交付（例如通过 SSL 和/或使用代码签名）。
（我确实注意到对 MD5 散列的引用。不要使用 MD5 散列；MD5 已被破坏。）
How is the verification code downloaded to the client? More details about the application in question? If it's a verification script downloaded via HTTP then the scheme is fundamentally broken. You probably need to use SSL, especially if you already argued as such.
Without knowing more about your system, it sounds like an adversary in a man-in-the-middle attack need only to:
Not to mention all communication is in plain-text (so hopefully no personal/sensitive information being transmitted?)
SSL works around this problem because all the certificates have to be signed by a root certificate authority trusted by / installed with the web browser. CAs are supposed to only issue certificates for domains to people that control/own them; therefore, the previous attack would not work.
Now, if your client is installed in a trusted fashion such that an adversary cannot tamper with it, then you can continue with your scheme and still be secure. For example, if the client is installed on a client PC by hand, or delivered securely some other way (like via SSL, and/or using code signing).
(I did notice a reference to MD5 hashing. Do not use MD5 hashes; MD5 has been broken.)
此问题是由 NAESB-EDI 标准引起的。当文件在 http 请求中提交时，我们需要生成特定的响应。我们使用的是 SSL，原始有效负载应该是加密的。响应是纯 html（共 4 项），带有响应的附加数字签名。我想做的是创建响应，让现有的 pgp 软件根据生成的响应创建签名，然后将签名附加到响应中。因此，我不再使用 MD5，也不会将密钥公开给公众使用（除了我们专门交易的密钥）。所以 James 的回答是部分正确的，并且没有 SSL，这几乎无法提供针对嗅探的保护，因为响应是明文。然而，如果请求中没有所需的信息，他们甚至无法得到适当的答复。可能不会得到回应（更不用说适当的回应了）。
This issue is due to a NAESB-EDI standard. Where a file has been submitted in an http request and we are required to produce a particular response. We are using SSL and the original payload is supposed to be encrypted. The response is plain html (of 4 items) with an additional digital signature of the response. What I have figured to do is to create the response, have existing pgp software create the signature based upon the generated response and then append the signature to the response. Thus I am not using MD5 anymore and I am not exposing keys to public use (except to those that we specifically trade). So James answer is partially correct and without SSL, this offers little if any protection against sniffing since the response is clear text. Yet without the required information in the request, they would not even get a proper response. Likely wouldnt get a response (let alone a proper one).