Kirmo Hovinmaa, technical writer
The Internet has forced us humans to rethink communication on a fundamental level. The convenience of being able to exchange ideas without necessarily seeing each other face to face or even being on the same continent has brought with it a challenge of trust. In an age where the success of electronic communication is simply assumed and physical print media is being phased out, verifying your identity with a passport or by signing on a dotted line is relatively cumbersome.
Luckily, however, inconvenience is the mother of invention. There now exist technologies that serve as the proverbial ink for signatures in the electronic domain. The signature algorithm used in Alauda Applet allows just about anyone with a cell phone to sign documents in a way that is as secure as flashing your passport and as convenient as typing a few digits on your phone regardless of distances.
These miraculous claims should not go without substantiation, and therein, as they say, lies the rub. The engineers working on this piece of kit absolutely know how the signature algorithm works and can even lay it out in writing, but to someone who lacks their frame of reference, making any sense of all the technical terms and conventions can be overwhelming. I should know, as I don’t have a degree in technology, and in fact lack any form of programming experience whatsoever. Wait, don’t leave just yet! My inexperience presents with it an opportunity.
By explaining how Alauda Applet’s signature algorithm works in a way that I myself can understand, I attempt to build a bridge between the engineers’ and the laymen’s frames of reference. We’re going to be buffeted with some pretty intimidating terminology here, but I’ll be with you all the way. Let’s see if we can’t weather the storm together.
Let’s say I want to sign a contract. Both parties of the contract agree that merely clicking OK on a web browser leaves too large a possibility for identity fraud, but signing wirelessly would still be the most convenient option for all. So I make use of a Mobile Signature Service (MSS), likely provided to me by my mobile operator. The service provider has a whole infrastructure to support signature operations, but what’s relevant for me is that as an MSS user, the SIM card in my phone contains a little program called Alauda Applet.
By verifying my identity once at the mobile store, I have aquired a means to use my phone to receive and open what are essentially padlocks in my image. These locks don’t necessarily make the contents of documents inaccessible; although technically these locks can be used to contain documents in “boxes” that only I could open, this is not done when I want to sign a document. The locks are connected to a key that resides in the Applet. This key does not travel anywhere from the Applet; it merely opens padlocks in my image on documents the Applet has received. Access to that key is protected with a PIN-number of my choosing, similar to but separate from how my whole cell phone is protected.
The connection between my identity and my lock and key allows me to express consent to contracts by opening locks on documents. An open lock in my image can be traced back to my actual identity, since only I have the key to that particular kind of lock. The signature creation process in Alauda Applet can work in a couple of different ways, but let’s reach a basic understanding by covering the most intuitive case, What You See Is What You Sign.
The document I am signing reaches me through my Mobile Signature Service Provider (MSSP). The MSSP sends my phone a signature request, which contains all the text in the document as well as instructions for how the Applet should process it.
Once the Applet receives the request, it calculates a digest of the document’s contents. Digests are essentially (relatively) short, unique series of numbers and letters that from then on can be used to refer to the whole document, and they can be calculated for any text by using various algorithms.
The Applet uses this digest a bit later, but first it lets me view the text I am about to sign on the screen of my phone. Once I confirm that I have read the document, the Applet uses the digest it just calculated to create an entity known as SignedAttributes. This entity contains some objects that help with the signature process and auditing in addition to the digest. The Applet then creates another digest, this time of the SignedAttributes entity.
The second digest that the Applet created is an entity that can be signed by me, so the Applet slaps a padlock in my image on the document and prompts me with the PIN that I protect my key with. Once again, this doesn’t make the contents of the document inaccessible, but rather tasks me with opening a lock only I can open to confirm my identity.
Once I have entered my PIN, the Applet uses my key to open the lock and sends the entity back to the MSSP along with the opened padlock. The MSSP can verify that it is indeed my opened lock on the document, and then send further data to the contract holder.
I am abstracting the process quite a bit here, but even now some of that may have seemed a bit complicated to someone less technically inclined. Let’s recap what just happened in simpler terms: A program in my phone receives a document that I want to sign along with instructions that say: ”This piece of text needs a signature, do your thing.” I see the contents of the document on the screen of my phone, and the program converts the text into a form that’s easy for it to process and that contains important information for auditing the event. In place of a conventional penned signature, the program asks me to confirm my identity and consent by having me do something only I can do: open a padlock in my image. The converted document, along with important auditing information and my signature, goes back where it came, and the contract holder is informed that the signing took place.
And that’s basically it. There are variations to this process on a case-by-case basis – for example, instead of reading the whole text on the screen of my phone, I could receive just a representation of the document on the screen of my phone, and I could read the document on a computer screen with the knowledge that I am signing a representation of precisely that document. (This is useful for longer documents that would otherwise take up a lot of memory; in fact, the What You See Is What You Sign process can only display very short texts.) However, the idea of me confirming my consent wirelessly with an action that only I can make remains constant.