文档在本地签名并加时间戳,然后上传到服务器,是否具有相同的特征?
想象一下一个 Web 应用程序,它允许您使用 Java 小程序或 Active X 对 PDF 文档进行数字签名(使用受信任的 CA 发布的个人数字证书 pkcs12)和时间戳。这显然必须发生在用户的计算机上,因为证书的私钥是存储在本地。
因此,一旦 PDF 被签名并加盖时间戳,它就会上传到服务器上。 上传的文件与本地创建的文件具有相同的功能吗?谈论“文件的原始版本”有意义吗?
我对此有点困惑。
更正: 我的意思是使用个人数字证书的私钥(应该是 pkcs7、pkcs12)对文档进行数字签名,以确保它确实是由某人而不是其他人签名的。
Immagine a web application that lets you digitally sign (with personal digital certificates pkcs12 released by trusted CAs) and timestamp PDF documents with a Java applet or Active X. This must obviously happen on the machine of the user because the private key of the certificate is stored locally.
So once the PDF is signed and timestamped it is uploaded on the server.
Does the uploaded file have the same features of the one created locally? Does it have sense to talk about "the original version of the file"?
I'm a bit confused on this.
Correction:
i mean digitally sign a document with the private key of a personal digital certificate (should be pkcs7, pkcs12) to ensure that it has really been signed by someone and not someone else.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果“文件的原始版本”意味着您打算“冻结”文档,以便任何人都无法再次对其进行更改 - 这既不可能,也不是数字签名的目的。任何人都可以简单地“剪掉”嵌入文档中的签名,没有人会注意到。
保护文档免遭后续修改涉及某种 DRM 机制。例如,涉及隐写术的“水印”用于保护照片,以便任何人都不能声称照片的所有权,即使在修改之后也是如此。但技术还不是很先进,大多数算法很容易被破解。
这意味着,在法律纠纷中,“文件的原始版本”的概念是相关各方必须一致同意的。如果没有同意或没有可证明文档完整性的可信第三方(例如,如果他们拥有该文档的独立副本),则无法证明来源。
除此之外,上传文件不应更改其内容。该文件将具有与本地文件完全相同的属性,包括在客户端添加的签名。
签名仅证明文件的真实性和完整性。如果您的应用程序能够判断收到的签名文档实际上是预期的文档至关重要,那么我建议您执行以下操作:
验证签名将确保完整性和真实性,比较哈希值将保证您您在服务器上收到的签名文档确实是先前创建的原始文档的签名版本。
关于使用本地时钟的时间戳:它们毫无价值,很容易被欺骗。您实际上应该使用的是 RFC 3161 兼容的加密安全时间戳,由受信任的机构颁发第三者。目前,这是在 PDF 签名中包含时间概念的唯一可靠方法。例如,Adobe Reader 中也对此有内置支持。由于这些服务通常不是免费提供的,因此在收到签名文档后在服务器上添加这样的时间戳是有意义的。它们作为未签名的属性添加到 CMS(Adobe 仍然使用 PKCS7)签名中,因此不会破坏签名,并且可以在签名创建后安全地添加。
If by "the original version of the file" you mean that you intend to "freeze" the document so that nobody can ever make changes to it again - that is neither possible nor the purpose of a digital signature. Anyone could simply "cut out" the a signature embedded within a document, nobody would notice.
Protecting a document from subsequent modification involves some kind of DRM mechanism. For example, "watermarking" involving steganography is used to protect photos so that noone should be able to claim ownership of a photo, even after having modified it. But the technology is not very advanced yet, most algorithms can be easily broken.
This implies that the notion of "the original version of the file" in let's say a legal dispute is something that the involved parties have to agree upon in consent. There's no way to prove origin without either consent or a trusted third party that will attest the integrity of a document, e.g. if they have an independent copy of the document.
Apart from that, uploading a file should not change its contents. The file will have the exact same properties than the local one including the signature that was added on the client side.
The signature will only attest authenticity and integrity of the document. If it is vital for your application to be able to tell that the signed document received is actually the one that was expected, then I'd advise you to do the following:
Validating the signature will ensure integrity and authenticity, comparing the hashes will guarantee you that the signed document you received on the server is indeed a signed version of the original document previously created.
Concerning timestamps using local clocks: they're worthless, it's very easy to cheat. What you actually should use there is RFC 3161-compliant cryptographically secured timestamps, issued by a trusted third party. Currently that's the only reliable way to include the notion of time in PDF signatures. There's also built-in support for this in Adobe Reader for example. As these services are generally not available for free, it would make sense to add such a timestamp on the server after receiving the signed document. They are added as an unsigned attribute to the CMS (Adobe still speaks of PKCS7) signature, so it won't break the signature and can safely be added after signature creation.
好吧,让我们尝试回答你的问题(据我所知)。
您有一些软件使用一些私钥(和时钟)向文件添加签名。
此签名取决于文件的内容,从而确保签名者在签名时知道(或可能知道)文件的内容。 (有一些方法可以实现“盲签名”,但我认为这里不是这种情况。)
将签名文件上传到任何地方不会改变任何内容。
关于时间戳:密钥持有者可以输入它想要的任何时间戳 - 因此,只有当您想在某个时间点向密钥持有者证明文档的知识时,这才有用,而不是如果您是密钥持有者并想证明这一点您是在某个时间点签署的,不早也不晚。 (另外,你确定他的时钟没有歪斜吗?)
关于这是否具有法律意义,你必须询问你的律师。这可能取决于
如果您在用户浏览器中使用某些小程序或 ActiveX 控件,我不能完全确定最后两点是否真的成立。
Okay, let's try to answer your question (as I understand it).
You have some software which uses some private key (and a clock) to add a signature to a file.
This signature is depending on the contents of the file, and thus makes sure that the signer knew (or could have known) the contents of the file at the time it signed it. (There are some ways to have "blind signatures", but I assume this is not the case here.)
Uploading the signed file anywhere does not change anything here.
About the timestamp: The key holder can put in any timestamp it wants - so this only helps if you want to prove knowledge of the document at some point in time against the key holder, not if you are the key holder and want to prove that you signed at some point in time and not earlier or later. (Also, are you sure his clock is not skewed?)
About whether this is legally relevant, you will have to ask your lawyer. It might depend on
If you use some applet or ActiveX control in the user's browser, I would not be totally sure that the last two points really hold.