在Web应用程序中对数据进行数字签名 [英] Digitally Signing Data in a web app

问题描述

我有一个Web应用程序，其中一些数据（而非文件）需要使用PKI私钥进行数字签名。 PKI证书和私钥将位于USB加密令牌中，当将其插入USB插槽时，它将在浏览器中注册证书。这减轻了使用证书进行身份验证的痛苦，因为我通过在应用程序中触发ssl重新协商来做到这一点。

但是，使用证书进行数字签名似乎是一种有点棘手。我可以想到几种方法

1. CAPICOM- http://en.wikipedia.org/wiki/CAPICOM
   这将适用于支持CAPICOM（例如IE）的浏览器。但是，似乎Microsoft已停止使用它。




2. Mozilla加密对象- https://developer.mozilla.org/en-US/docs/JavaScript_crypto




3. WebCrypto API-大多数浏览器尚不支持此功能。




4. 自定义Java Applet或一些开源的免费可用JavaApplet控件。




5. 其他选项？

我正在尝试找出在网络中执行此操作的常见，便捷和安全的方法是什么应用程序。

注意：

1. 我可以接受流行的支持浏览器。


2. 我正在签名一小段数据-例如100-200字节而不是文件。


3. 我更喜欢PKCS＃7签名。

解决方案

[披露：我为CoSign工作。]

您遇到的问题是老式PKI系统的一个常见问题，该系统将签名者的私钥存储在边界（例如，智能卡，令牌等）中。该系统是在PC（及其上运行的应用程序）成为焦点时设计的。但这不是本世纪。现在，无论是浏览器还是移动设备都是重点。

您在网络应用的本质之间存在紧张关系（它们要么在主机上运行，​​要么在JavaScript沙盒中运行）浏览器）与保护私钥的本地硬件的想法。

突破浏览器的沙箱

一个设计方向是尝试突破浏览器的沙箱以访问本地硬件私钥存储。您列出了许多选项。另一个是 Chrome USB访问库。但是所有这些解决方案都是：

• 仅限于特定的浏览器


• 硬（且昂贵）安装


• 难以维护（而且昂贵）


• 高水平的管理开销，可以帮助用户解决有关保持系统正常运行的问题。
  

回答您的问题5还有其他选择吗？

是：集中签名

更好的选择（IMHO）是集中签名。这样，密钥就可以保存在集中式FIPS安全服务器中。同时，签名者仅使用Webapp授权签名。签名者不需要保留私钥，因为它存储在安全服务器中。

要对签名者进行身份验证，可以使用应用程序需要的任何安全级别。 ： 用户名密码;一次性密码；通过短信进行两因素验证；等等。

CoSign签名API 和 CoSign签名Web代理就是为此目的而设计的。集中式PKI签名也可以从其他供应商处获得。

为回应评论而添加

< blockquote>

从答案的第二部分开始-如果证书存储在服务器中，并且通过使用uname / pwd或2FA对用户进行身份验证来进行检索，那么为什么根本没有数字签名吗？即，与仅使用uname / pwd或2FA对交易进行身份验证相比，它提供了什么优势？

A：在集中式设计中，私钥不会离开中心服务器。而是将要签名的文档或数据发送到服务器，进行签名，然后将签名的文档或数据（例如XML）返回到Web应用程序。

回复：为什么这样做？因为可以对数字签名的文档或数据集（例如XML）进行验证，以确保文档自签名以来未更改，并提供了信任链来确保签名者的身份。相比之下，即使2FA等增强了密码，也只能为 app 提供签名人身份保证，而不是第三方。

PKI数字签名使第三方可以通过验证过程向自己保证签名人的身份。而且可以根据需要通过选择不同的CA来设置保证的强度。

I have a web application where some data (not file) needs to be digitally signed using a PKI Private Key. The PKI Certificate & Private Key will be in a USB Cryptotoken which registers the certificates with the browser when inserted into the USB slot. This eases the pain of doing authentication using the certificate because I do that by trigerring ssl-renegotiation in my Application.

However, using a certificate for digital signing seems to be a bit more tricky. I can think of several ways to do this

1. CAPICOM - http://en.wikipedia.org/wiki/CAPICOM This will work for browsers which support CAPICOM (eg. IE). However it seems that Microsoft has discontinued this.

2. Mozilla Crypto Object - https://developer.mozilla.org/en-US/docs/JavaScript_crypto

3. WebCrypto API - this is not yet supported by most browsers.

4. A custom Java Applet or some opensource freely available JavaApplet control.

5. Any other options?

I am trying to figure out what is the common, convenient and secure way of doing this in a web-application.

Note:

1. I am OK with just supporting the popular browsers.
2. I am signing a small piece of data - say 100-200 bytes rather than a file.
3. I would prefer PKCS#7 signatures.

解决方案

[Disclosure: I work for CoSign.]

The problem that you're running into is a common one with old-style PKI systems that store the signer's private key at the boundary (eg in a smart card, a token, etc). This system was designed when the PC (and apps running on it) was the focus. But that isn't true this century. Now either the browser or the mobile is the focus.

You have tension between the nature of web apps (they're either running on the host or are sandboxed JavaScript on the browser) versus the idea of local hardware that "protects" the private key.

Breaking out of the browser's sandbox

One design direction is to try to break out of the browser's sandbox to access the local hardware private key store. You've listed a number of options. An additional one is the Chrome USB access library. But all of these solutions are:

• Limited to specific browsers
• Hard (and expensive) to install
• Hard (and expensive) to maintain
• High level of administrative overhead to help the users with their questions about keeping the system working.

Re your question 5 "Any other options?"

Yes: Centralized signing

A better option (IMHO) is to sign centrally. This way the keys are kept in a centralized FIPS-secure server. Meanwhile, the signers just use a webapp to authorize the signing. The signers don't need to hold the private key since it is stored in the secure server.

To authenticate the signers, you can use whatever level of security your app needs: user name/password; One Time Password; two factor authentication via SMS; etc.

The CoSign Signature API and CoSign Signature Web Agent are designed for this. Centralized PKI signing is also available from other vendors.

Added in response to comment

From the 2nd part of your answer - If the certificate is stored in the server and retrieved by authenticating the user by using uname/pwd or with 2FA, then why do digital signing at all? i.e. what advantage does it offer over just authenticating the transaction with uname/pwd or 2FA?

A: In the centralized design, the private key does not leave the central server. Rather, the document or data to be signed is sent to the server, is signed, and then the signed doc or data (e.g. XML) is returned to the webapp.

Re: why do this? Because a digitally signed document or data set (eg XML) can be verified to guarantee that the document was not changed since signed and provides a trust chain to provide assurance of the signer's identity. In contrast, passwords, even when strengthed by 2FA etc, only provide the app with signer identity assurance, not third parties.

PKI digital signing enables third parties to assure themselves of the signer's identity through the verification process. And the strength of the assurance can be set, as needed, by choosing different CAs.

这篇关于在Web应用程序中对数据进行数字签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！