Transaction validation : part 2 , ECDSA signatures

Electronic signatures as offered by public key cryptography have impressing capabilities , combine those with the ubiquituous mobile phone and a global validation service that can be accessed from anywhere and you start seing many of the problems that are plagging today online electronic transaction as solved.

What we will show today is the way we integrate the token ECDSA signature capabilities with relying external web application. We take the view that end users will continue to use the desktop browser for the years to come , so part of the problem is how to integrate the on desktop accessed web application with the mobile token.

The previous post has shown how the content of an online transaction can be summarized into a text. With ECDSA the signature that we need to generate is too long (say 80 characters…) to be reliably transferred manually into the web application. We therefore transport it directly from the phone to the validation service and prior to this the full content of “the text to confirm” is moved down to the phone.

The end of a sample transaction :

Let’s assume that the end user engaged into the online transaction of interest has been previously authenticated by the web application. When reaching approval stage , the web application summarizes the content of the transaction (your order nb xxx , item 1 … , item 2 …) into a “text to confirm” and this text is passed to the KerPass service together with the end user identifier. The service responds with a unique identifier that is passed to the end user…

The end user selects the token to be used for the signature and enters the message reference. The phone contacts the service over the air , enters into authentication and safely retrieve the “text to confirm”. The text is then fully displayed to the end user onto the terminal together with the approval options.

The end user review the received content , select the desired approval option and submit. The phone calculate the ECDSA electronic signature of the “text to confirm” aggregated with the select approval and authenticate again with the service to transmit the signature over the air. The service validates and stores the signature…

Performances :

The scenario detailled above is straightforward. The difficulties for us has been to implement ECDSA in a way that make it perform acceptably well on off the shelf java enabled phone.

This has been a long march , however we are now satisfied that we have what it takes :

1. Low end java phone [Nokia 3220] : msg retrieval 07 seconds | sign calc and transmission : 15 seconds
2. Middle end java phone [Nokia 6111] : msg retrieval 02 seconds | sign calc and transmission : 05 seconds

Our test server is in United States , we are located in Romania accessing the web over gprs on the Orange network. We consider we have reached usability stage.

ECDSA signature strength and weaknesses :

Strengths :

1. ECDSA signatures offers non repudiablity , they are therefore suitable for legally binding agreement
2. Compare to more traditionnal approach of smart card + desktop reader it is much more easy in the context of this system to guaranty that “What you sign is what you see“
3. Much simpler to distribute than smartcard plus related reader

Weaknesses :

1. More tedious to integrate than previous password signature [4 web service call]
2. Smart card offers safer storage than phone memory. However in future version we can probably move private key to sim card using new java apis