Transaction validation : part 1 , password signatures

The current KerPass token only provide for end user authentication using OATH one time passwords. The new KerPass token (code name “universal security token”) will additionnaly provide solutions for transaction validation using two differents technologies : password signatures and ECDSA electronic signatures. In this post we will discuss how password signatures are working and what are the benefits of using them.

A few words first on what is meant by transaction validation. The idea here is to allow a end user in control of a workable token to proove that he really agree with the content of a transaction , he is supposed to have been engaged… A simple example of transaction is an online payment , how do you reinsurre your bank and/or the seller that you are really the initiator of such transaction ? It is well known that this is a problem not reliably solved in current Internet. Our new mobile token will allow the end user to give a strong proof of his approval of such transaction. Let’s see how this can be simply achieved with password signatures:

A simple example :

To help testing our new token , our engineers have constructed a proof of concept application that illustrate the intended scenario of usage for password signature. You have probably heard that PayPal allow money transfert recipient to be designated by their email address.

This is what this proof of concept application is about…

The end user enters the required information and submit :

The end user enters this text snippet into its mobile , and such text is combined with some token private data to generate a unique time synchronous one time password that will be entered into the signature field. Such password is 9 characters long , uniquely corresponds to the entered text snippet and end user and is valid for 3 minutes only …

What happens next ?

This new feature is fully compatible with the KerPass web service infrastructure , when the new token will be made available our service grid will offer a new method that relying web application will call to validate received password signatures. The parameters for this method will be text_to_confirm , end_user_identifier , password … The service as usual will validate the received credentials on behalf of the relying application.

Password signatures strength and weaknesses

The main advantages of the method are :

1. Ease of integration into the relying application (single web service call …)
2. Even if captured (phishing …) , a password signature can not be used for another purpose than the one explicitly allowed by the end user.

The drawback are :

1. Only applicable to transactions which content may be summarized meaningfully into a short text snippet
2. If used heavily maybe tedious for the end user , lot of phone inputs …

A password signature is a strong proof (the math here are pretty impressive) of end user agreement with the content of a transaction. It is an easy to integrate basic form of electronic signature , such electronic signature however is not legally binding.

In a prochain post , we will show the principe of integration of elliptic curve digital signature into relying web applications.