Monday, November 04, 2013
Next Generation Digital Signature Service
Doing a from scratch is always an interesting event. As it is, in a way,
a confession that your previous attempt reached its limits. The eID DSS emerged from an idea I had in the spring of 2005, leading to the creation of e-contract.be. Although eID DSS resembles much of the original ideas, it was only during the summer of 2008 that I could start shaping it. The original eID DSS features some fairly unique properties.
Two phase signatures
The most important one is that eID DSS supports what I call a proxy signature, or two phase signature. Here the server side calculates the digest value. Next the eID Applet signs the digest value. And finally the server side magically injects the signed digest value into the to-be-signed document. The big advantage of such an architecture is that you can keep the eID Applet very lightweight as all the signature format logic lives at the server side. This is especially important for large scale deployments as we witness these at government sites (federal e-procurement is using eID DSS). It also offers the ability to make the support for different document and signature formats pluggable.DSS integration protocol
Another interesting feature is that eID DSS, compared to all the other signing boxes and tekendozen, offers a protocol to ease integration of qualified signatures into web flows. Similar to what authentication protocols offer between web applications and identity provider, the eID DSS offers a signature creation and verification protocol.
From eID DSS to DSS
The biggest problem with the architecture of eID DSS is that the two phase signature aspect, that is inherent by design of the eID Applet (and that you certainly want to keep), manifests itself throughout all layers of the eID DSS. Besides the fact that back then Java EE 5 was not powerful enough to express what I needed, I also was not able to find a clean solution to convert this two phase signature design back into the regular JCA way of doing Java crypto. Looking back now, these were two missing technological steps that had a tremendous impact on the way eID DSS shaped.
@-novation starts here
Today I can finally announce the availability of the next generation DSS technology. The end-user portal, basically a demonstrator for the capabilities of the DSS, is available at: https://www.e-contract.be/dss/
Completely written from scratch, the new DSS features a brand new DSS protocol. From a security point of view, this new protocol is just it. The old protocol, as implemented in the original eID DSS, could easily be integrated in an insecure way by the developer. For the new protocol, this is no longer possible given the design of the protocol. As we all know that protocols (and their implementation, especially authentication protocols) are very vulnerable to attacks, this new protocol is a huge step forward.
Furthermore the way signatures are handled inside the new DSS is just so much easier to maintain compared to the preSign/postSign horror. This will allow us to add other signature and document formats without having to think about the DSS architectural twists. As a matter of fact jsignatures, the new signature engine, completely lives outside the DSS code base as a separate project.
This first version acts as a demonstrator of the capabilities of this new technology stack. For the moment we only enabled PDF PAdES LTV signature support. Any feedback on the behaviour or performance of the new DSS is always welcome.
