Everything else can be done on the web – why not digital signatures?

Digital signatures are not a new concept in the security world. The process is fairly simple: take some data, apply a hash algorithm to it, encrypt the hash with a private key, and then store the resulting signature somewhere. Assuming you don’t have to implement the cryptographic algorithms (which you shouldn’t), the process is very easy. So, why is it so hard to do over the web?

For one thing, most security libraries have made the problem too easy to tackle. Libraries such as CAPI for Windows, BouncyCastle for Java, and OpenSSL for C like to make creating digital signatures a one-function event. Pass in the data, certificate, key, and you get your PKCS7 signature block. This works great for desktop applications, but what about the web? What about the case where you have a big document on a server (like a PDF) to which you want a user to apply a digital signature? Adobe’s API for digital signatures provide no help here either – they’ll let you sign a PDF on the server, as long as the certificate and private key are on the server as well.

Obviously, you don’t want your users sending private keys to the server, and with pretty much all crypto devices, that’s impossible anyway. And, you don’t really want to have to send your giant file to the user, have him sign it, and then re-upload the giant file back to the server. I’ve recently worked on a project that attacks this problem. The idea is that the server takes the document and hashes it, sends just the hash to the client (less than 1K of data as opposed to a 10mb PDF), and the client applies his key to the hash and sends back the signature data, which the server then inserts into the document file. This required bypassing all of the convenience methods implemented in the server-side Java libraries and manually hashing the document and constructing the ASN structure for PKCS7 signed data from scratch. On the client side, it also required developing a custom ActiveX control because CAPICOM doesn’t support encryptring a raw chunk of data without turning it into a PKCS7 enveloped data structure.

This approach isn’t without its drawbacks, however. Such as, how can the client trust that the hash you sent is really the hash of the document he’s looking at? It does place a burden on the user to trust the application to “do the right thing”, but then again, the user has to trust desktop applications to “do the right thing” too. Issues of trust are also directly proportional to the importance of the application – i.e., do you really need ironclad authentication to sign a timesheet or a project status report? It isn’t an especially difficult technical problem to tackle for library developers…so why don’t crypto libraries make it easy to do, and then let company policy makers decide if and when it should be used?