使用Adobe Reader，您可以在本地签署文档。它是理论上比将文档传输到服务器并在服务器上签名（更特别是使用adobe技术）更安全吗？如果在服务器上完成，用户是否可以争辩文档可能在以后被篡改？如何在技术上证明他是错误的，即使在服务器上签名也是不可能的 - 要考虑法律问题。
答案 0 :(得分：2)
在前往服务器的路上，文档可能会发生任何事情。连接可能是MitM受到攻击，服务器可能已经被篡改等等。
加密签名中的第一条规则是，必须在受信任环境中的受信任计算机上进行，最好是在它到达连接的计算机之前（即离线，然后在离线媒体上传输）。
简而言之：它应该在客户端上签名而不是其他地方。
答案 1 :(得分：2)
你住在欧盟吗？我可以在这里描述一下情况。签名的法律方面受指令1999/93 / EC的管制。将会有一个更新版本，因此细节会有一些变化，但通常指令 区分基于服务器的签名和本地个人签名，只能控制过程
独立控制本地流程具有很多安全优势，其中包括：
使用指令所称的安全签名创建设备（SSCD），例如智能卡。使用防篡改设备肯定被认为是一个优点，尽管当攻击者例如它时它仍然可以被利用。控制SSCD所附带的计算机/操作系统。
“你所看到的就是你所签署的”原则在指令中含糊其词。理想情况下，您应该能够查看要在可靠设备上签名的数据。使用服务器端签名无法保证这一点。
密钥托管。如果服务器签名，则密钥很可能也存储在服务器上。并且非常非常难以实现一个解决方案，其中密钥位于服务器上，只有客户端可以访问它，更常见的情况是您需要信任操作服务器的一方。
也就是说，可以使用例如传输来保证从客户端到服务器的传输。 TLS并且仍然拥有相当安全的服务。但是，关于法律（至少在欧盟），“不可否认”签名的概念，即由个人签发的签名，只能在“地方签名”的背景下实现。此处经过认证的CA不会向法律实体颁发不可否认证书，例如，此类证书只会发给真人，通常是SSCD。
SSCD的缺点是很难推出可以利用它们的大规模软件部署，尤其是跨越公司/州界限，因为无数的硬件仍存在很多互操作性问题，成本和简单明了的事实，它不太方便。
答案 2 :(得分：1)
如果签名是由用户（操作员）进行的，那么这是对密钥所在的服务器的信任问题。
通常“用户代表用户签名”意味着用户拥有用于签名的密钥。在这种情况下，将私钥放在服务器上是没有意义的。如果您需要此方案，则签名不是由所有者签名，也不是代表制作签名的签名。
但技术上可以签署服务器上的数据（如您所述），并且在正确实现的体系结构中，用户应该能够获取签名的副本并手动验证签名的文档以确保这是他（或者代表他的服务器）打算签名。
另一个问题是服务器是否（故意或由于安全漏洞）使用用户的私钥来签署除请求文档之外的任何内容。这是非常难以确保的，除非你有一个专门为一个操作（签名的东西）而设计的服务器，在这种情况下你可能会处理专门的硬件设备（例如SafeNet提供的设备），而不是通用的Windows / Linux / ...服务器操作系统。
我们的SecureBlackbox产品中有一个分布式加密模块，它实现了与您描述的类似的方案，但角色通常是相反的：用户拥有密钥并使用它来本地签署驻留在服务器上的文档而不是转移到客户端。在该模块中，我们使用TLS来确保通道的安全性并在用户的计算机上执行签名，因此私钥保持严格保密。但是，您描述的方案也可以使用该模块实现。