7

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.
user93353
  • 13,733
  • 8
  • 60
  • 122
  • Please check this answer of mine to the question similar to yours: http://stackoverflow.com/a/10656679/47961 – Eugene Mayevski 'Callback Jul 14 '13 at 17:08
  • You may consider using Browser Extension. One such browser extension is freely provided by my Company. You may refer [Signer.Digital](https://signer.digital/SignerDigitalBrowserExtensions) for more details. – Bharat Vasant May 24 '19 at 06:40

1 Answers1

2

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

user93353
  • 13,733
  • 8
  • 60
  • 122
Larry K
  • 47,808
  • 15
  • 87
  • 140
  • 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? – user93353 Jul 17 '13 at 08:56
  • The place where the cert is stored is a USB Cryptoken and just a regular USB drive - will chrome.usb really help accessing a Cryptodevice? Also, I think there is really no need to access the Cryptotoken or smartcard. If the certificate is registered with the browser/OS keystore, then whichever method you are using to sign may be able to access the private key from the store rather than through the device directly? – user93353 Jul 17 '13 at 09:01
  • Re the comment about USB--I have not yet used the USCB library, but the docs say it can be used to access the USB device's functions. Re key store vs device--I don't have info on that issue. – Larry K Jul 17 '13 at 12:16
  • My original comment had a mistake - I wanted to say the cert is stored in a USB Cryptoken & *NOT* a regular USB drive - that's why I think Usb.chrome will not be able to access it. – user93353 Jul 17 '13 at 12:32
  • `Because a digitally signed document or data set (eg XML) can be verified to guarantee that the document was not changed since signed ` - this satisfies only one of the reasons to use transaction signing. One more reason to use transaction signing to prevent transaction tampering by a M-I-T-M attack - keeping the private key at the server doesn't prevent this tampering. – user93353 Jul 17 '13 at 15:51
  • Re MITM attacks: These days, a MITM attack is just as likely to be from within the boundary device (the PC) as to be someone intercepting/relaying the comms. Eg see Stuxnet and many other OS attacks. So don't be fooled into thinking that a boundary SSCD prevents MITM, it only helps with a certain class of MITM attack. Plus, you can prevent/detect a comms MITM attack by using secure comms channels: https, vpn, etc. – Larry K Jul 18 '13 at 07:20
  • I have no idea what SSCD is. Anyway, preventing MITM with https relies on user 'not ignoring' the certificate warning - most users just click through and ignore the certificate warning. OTOH, transaction signing done at the user's end can prevent MITM from tampering with signed data which server side signing won't. Also look at this - http://www.schneier.com/blog/archives/2013/01/man-in-the-midd_6.html – user93353 Jul 18 '13 at 07:32
  • SSCD: Secure Signature Creation Device. Examples: SmartCard, CryptoUSBKey, Centralized Signing servers. Also, once you posit a system that is a viable attack target AND has users that ignore FULLPAGE RED warning screens (use Chrome) then you've already created a problematic situation: good luck! – Larry K Jul 18 '13 at 07:41
  • Users are users, you cannot force them to use chrome, not can you teach all of them to not ignore cert warnings especially since lots and lots of legitimate sites have self signed certs which trigger warnings and they have to routinely ignore the warnings to get to the site. That's why I think signing on client side adds an extra layer of security - it prevents transaction tampering by MITM. – user93353 Jul 18 '13 at 08:05