Digitally Signing Data in a web app

Question

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.

Answer 1

[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.