Tractis technical decisions: Signature Creation Component

In the previous post, we started to describe the architecture and design decisions that we took in the development of Tractis. We talked about our experience in confronting the challenge of creating an infrastructure such as ours, in which diverse components (in function and technology) are united to form a single service.

As we explained, we could have opted to employ a single technology to solve all the problems. This way, we would have used a single language, a single paradigm and a single platform to meet all the challenges that we would encounter.

We discarded the idea because a single, optimal technology that would cover all the functional requirements didn’t exist.

So, we opted to use Ruby on Rails for the front end web applications, given it’s enormous potential for the development of such applications.

But it wasn’t just because it’s fast, but also for it’s robustness and excellent capacity to evolve and grow. But the frond end, although most visible to the users, is only a part of our infrastructure.

We encountered a series of technical and architectural decisions that were outside of what Ruby On Rails could offer us in the area of one of the most valuable functions we offer: the signing of contracts.

The signing process

The people who use Tractis should be able to sign documents but not any old way, but with the necessary guarantees. These statements may seem obvious and vague but if we stop to analyse the technical consequences of them, we will see that they are not so trivial.

Our users are people who use different signature technologies such as tokens, identity cards or software certificates that are issued by different agencies, are in different countries and are running different browsers and operating systems.

In addition, the signatures should be reliable so therefore we should give the maximum guarantees such that the signer is able to use the signature, validating it later to avoid fraud.

Afterwards, we should archive it in a secure manner, applying electronic means of long-term preservation so that in the case of future disputes, we can provide the necessary evidence.

These conditions clearly delimit diverse complementary components of our infrastructure: a signature creation application, a validation application and a signed documents custodian application.

Talking about all the components would be too much for a single post so I will spread it out into various to make each less dense in content.

I will start by explaining our signature creation component to see with a bit more detail all that is involved in the act of ‘pushing the sign button’.

Signature creation component

The signing process is different from the commonly used process on the internet in that it inverts the producer/consumer paradigm. Normally browsers request content from the servers and once received they take charge of rendering it to the client. In the case of signing, the server requires an action from the client (that they do the signature) and once realised, it will validate it and store it.

The process is like this because the keys with which the client will sign are in the cryptographic device, hardware or software, and these don’t ever leave the client machine at any moment, with the result that the custody of the keys is performed wholly by the user.

As we’ve stated previously, the client does not have a concrete technological profile from the point of view of the scenario in which they perform the signature.

So we can have a client that signs with Internet Explorer using certificates stored in their electronic ID card (in Spain this could be the DNIe electronic national ID card) while another might sign using Linux with a cryptographic token from Firefox and in both the experience and result should be the equivalent.

The scenario gets more complicated as we try to cover more variations, given that the complexity is multiplied with each new actor that we introduce. So we couldn’t opt for a solution tied to a specific technology.

There are many good signing components tied to specific technologies or browsers such as the Active X signing components from Microsoft for Internet Explorer or Mozilla signing libraries that can be used via JavaScript.

The problem is that these components are tied to the technology on which they run and this implies that they try to introduce new browsers/operating systems into the mix, with the result that the development and maintenance costs are terrible.

And then Java arrived

One of the main benefits of Java – or at last at it’s inception was one of the most lauded – is that you only have to develop once, compile once and the result can be distributed and run on any machine.

However, the fact that you need a Java virtual machine to run the code is rarely mentioned.

Even so, the fact that you can develop once and run on whatever platform, above all in the Internet world, is amazing. Unfortunately, client-side Java on the Internet is something that began strongly when the Applet was a respected component but it has fallen to an undeserved state of disuse.

In our judgement, one of the most common mistakes with Applets is that they are used for tasks for which they are not well suited such as for a visual component – a task for which exists superior technologies such as Flash.

Nevertheless, Applets have a massive potential in fields closer to business logic, away from the presentation of content given that you can run Java applications inside the browser. If we can say anything about Java it’s that it makes available an incredibly well designed system of cryptographic libraries that can be fully used inside Applets.

Java and the digital signature

One of the things that made us opt for Java as the technology for implementing the signature creation infrastructure was the excellent support that it has for cryptography, and in particular, for digital signatures.

It not only makes available different cryptographic providers so that you don’t have to limit yourself to those in the provider that Sun supplies – you can employ providers from different manufacturers and even from different natures and all this without altering the logic of your application.

This means that we can have, by means of a single code base, a component that performs cryptographic operations that support different types of cryptographic devices and on different platforms.

So, the complexity of dealing with different devices is assumed by the virtual machine and we can see their management at a much higher level, avoiding adapting our code to ad-hoc functionality provided by each digital signature technology.

In this way we then work with the keys, certificates and signatures according to defined interfaces and at a very high level, without the need to descend to details about how or where certficates and keys are stored.

This abstraction also results in simplicity, robustness and the reduction in size of the applet, a big advantage if it is a component that the user should download to their browser before signing.

To dive into the topic of Cryptography in Java and for anyone who has interest in the area, I recommend that you consult one of the wide document bases about cryptographic architecture in Java such as that edited by Sun or from dedicated groups such as Bouncy Castle.

Using Java 1.6

One of the most complicated decisions to take in the area of applications that require the use of Applets and Java in general is which should be the minimum version of virtual machine supported. Here, if you choose a version too new, your users have to update their virtual machine whereas if you choose to support obsolete virtual machines you miss out on the functionality offered by later versions.

In our case we opted to use the latest version of Java Virtual Machine available right now – 1.6 (or 6.0). This version brings a large number of improvements in the area of cryptography above all in the field of support for different technologies for storing certificates.

Using this version we can support signing using certificates shored in certain types of repositories that were not previously available in the virtual machine – only in additional libraries – like, for example, those that Windows exposes via it’s Crypto API.

Supporting this type of technology is vital to comply with the requirement to try to bring Tractis signing to the largest number of users possible given that a large percentage of the current market for certificates are stored using this technology.

Conclusions

In this first post on the signature components we have briefly outlined some of the reasons that led us to adopt Java as the technology for the development of our signature creation component. We have also described why this component is local and how it is possible for us to support multiple browsers/operating systems.

In the subsequent posts we’ll discuss similar design decisions in the validation system and the custody of signatures that we employ as part of our digital signature back end, closing the circle of components that we employ to insure the contracts in Tractis.

By David García
Saved in: Announcements | No comments » | 4 February 2008