KerPass will make a presentation at e-Smart conference on the 18th of September 2008. We will present advanced solutions for delivering reliable software tokens on networked devices.

Version 1.31 of our KerPass UST mobile client has just completed “Java Verified” certification. Such quality certification that focus mainly on usability will allow us to simplify the dialog with mobile operators, as we realized that the lake of it was complicating discussions.
When first approached, “Java Verified” is no picnic. Thanks to Orange partners and NSTL for making this easier to achieve.

Right from the inception of the KerPass system, we considered “transaction validation” to be part of our roadmap. We took some time to develop a portable digital signature system based on elliptic curve cryptography and proposed additionally to it something we call “Password signature” which is a digital signature that you can use like a password. We received comments that the usability of our initial “password signature” system could be improved, main reported drawback was the need to manually input the message to be signed. In the meantime it also appeared valuable to let the “Password Signature” benefits from the progress of both our mobile digital signature system (automation of document transfer) and the KerPass one time password system. Our new SignCode system integrates those progress and offers a valuable solution to counter “Man in the middle” attack on in browser delivered web applications.

SignCode at work

SignCode is a type of “one time password” that is also depending upon the content of a certain transaction. A SignCode allows to validate that a certain user agrees with a certain transaction at a certain time. Let’s see how a user who is interacting with a web application can use a mobile to reliably deliver his agreement.

transaction initiation

This is not detailled here but typically happens on the web interacting with one of your favorite application. Let’ say that the required transaction is a payment (everybody those days appear to be chasing payment securisation…), the web application will call the KerPass grid and forward a message summarizing the transaction.

	Phone message retrieval Prior to the transfert of the transaction summary to the KerPass grid, the web application has authenticated the phone bearer . The KerPass grid responds to the web application with a message key. The end user enters such key into its phone, which results in phone/grid mutual authentication and delivery of the transaction summary if the phone has been recognized by KerPass as the intended destinary.
	On phone transaction review The message is now on the phone for secure review by the end user. The system offers some interesting guaranties : The message comes from the legitimate web application The end user has been strongly authenticated prior to transfer
	On phone approval This is it, the end user has made up his mind. He chooses whether he wants to approve or reject the submitted message.
	On Phone SignCode The SignCode is calculated from a secret key, the reviewed message , the chosen approval and the current time… It is valid for atmost 5 minutes. User uses it as a password and enters it into web application.

A man in the middle and your SignCode

“Man in the Middle” attacks are currently a non solved problem for in browser web application. The well known “Phishing” attack is a type of “Man in the Middle”. For more information the interested reader may read this post.

SignCode do not prevent “MITM” attacks to take place, however they render them uninteresting as after a SignCode has been captured it may be only used for the purpose that the end user has assigned to it. Public key digital signature may be a stronger tool for this purpose, however it is more complicated/costly to integrate. SignCode a close relative of the well known password is the simplest thing that can possibly help in solving the security risk associated to “MITM” attacks. A KerPass extended mobile phone delivers those easily.

The maths behind SignCode

SignCode are really a variation on the well known idea of one time password. For more on one time password you may refer to this post.

Some possible algorithms for delivering SignCode are described here.

KerPass delivers time synchronous SignCode for enhanced security.

We are following carefully what is going on on this side for obvious reason, so the news that Arcot technology was selected to optionally deliver strong authentication to business customers accessing google apps is certainly something to watch.

How does it work ?

The Arcot solution primarily consists in an in browser Flash client application which takes the place of standard login/password form. The flash application allows end user password to be entered in the same way as it would in “normal” web application, but instead of forwarding such password to the server hosting the web app, it is used on the client machine to decrypt an RSA private key, which is then used to sign a challenge, the signature serving as a proof of end user identity.

The file holding the private key is stored in a flash shared object, so this system is normally resistent against phishing as code not originating from the same domain as the one which issued the application having stored the key will never be in a position to make use of it. Unless there are things we don’t get, we doubt however that such a system provide meaningfull resistance against other type of Man in the Middle attacks, as after dns highjacking mobile code will probably have full access to such key. Browser end user warning panel in case of certificate problem provide very brittle protection in such circonstances.

Software smart card

Arcot has probably coined the term software smartcard, their realisation provide some improvement over PKCS 5 password encryption of the private key file. This approach has some drawbacks, mainly the fact that the public key is not anymore public as it can help in retrieving the private key value and loss of the password probably necessitates changing the private key.

The solution is elegant in its attend to only depends of widely available browser technology and in leveraging same origin policy to at least prevent phishing to take place. Expect more from us on this side

There is an overall perception that 2008 is the year where mobile will take off as a platform widely open to innovation. Until now, the majority of those exposed to mobile application development have been stuck at the entry of so called operators walled garden, and/or are busy fixing fragmentation problems accross a wide variety of not so similar handset … Recent initiatives from Apple and Google (both newcomers in the mobile arena) suggest that what until recently was looking a distant future is about to happen. There will probably be resistances on the way towards “new mobile” (you may call it mobile 2.0), and to understand what may go wrong it helps to review what the much needed reorganization imply.

What are we heading for ?

In mobile 2.0, end users have in hand terminals which in addition to ubiquituous voice access deliver always on internet. Additionally the processing power of those devices allow them to be used with success for tasks that are nowadays in the realm of personal computer, and interfaces are available that allow efficient human/device interaction and to some extend (expect many unexpected development here) end user personal environment interaction (eg today mobile phone camera …).

Those new mobiles will probably be prefered to today personal computer, to host any applications which continuous availability is important for the end user , the endless list of such applications will have to be written in the years to come …

This may appear as a natural evolution of the current state of things, it is but there is an overall perception that something has to change in the mobile ecosystem to allow the full potential of those technologies to be realized.

Mobile 2.0 operators

The main question here is whether the mobile operators of today will want to transform themselves in the kind of operators that mobile 2.0 requires. So far the control of the network has also implied the control of the applications and services which are accessible from the end user terminal. Even the less paranoid mobile operator will not have any difficulty in perceiving the threat that a platform like the one drafted by Google (Android) constitutes for their established position. For example, what would be the impact on the revenues that operators derive from sms text messaging of an ubiquituous instant messaging client ?

We shall see how things will evolute, but chance are high that today mobile operators will not be exactly enthousiastic supporting “mobile 2.0 business models” which transfers a fair percentage of value to companies developing applications at the other end of the cloud. Mobile 2.0 take off imply an easier access to network and end user terminal than what is currently allowed, opening such doors currently depend upon operators good will. They need to be convinced that they have more to win than to loose in doing so…

Winning the hearth and mind of the developers

It is clearly perceived that innovations coming from applications developers will be key in developping the attractivness of new mobile platforms. The recent release of the iphone sdk is a significant step forward as it suggests two things :

1. Native development are required to allow those new devices to deliver their full potential
2. There need to be a clear path for application to be sold and delivered to end user. The iTune way will probably be duplicated …

What about Nokia

Tough Nokia currently appears as a follower, in our opinion they are capable to have a meaningfull impact on what is currently going on. Their marketing message does not appear to be as efficiently delivered as the one of Apple and Google, however Nokia has a few assets that suggest that the real Android may eventually arrive from the North of Europe. Their recent take over of Trolltech suggests that they have understood that mobile 2.0 is about quality applications which benefits from solid platform tools.

KerPass will be making a presentation (including various demo of UST phone token) at mobile monday Paris on the 07th of January 2008.

This will take place at :

BETC Euro RSCG,
85-87 rue du faubourg Saint Martin,
75010 Paris.

It is too early to be sure that Google and its followers of the open handset alliance will really deliver every promises that the mobile Android platform imply , however it looks to us that this project take a refreshing approach on what a mobile platform shall deliver.

The emergence of Android could be much more disruptive than say the release of the Iphone, as it can reach everybody phone …

Linux as the base OS

Linux as an operating system for mobile handset is nothing new. A rapid look to projects like Palm access linux platform or community projects like open Moko may give the false impression that it has yet to take a meaningful market share.

Hybrid flavors of Linux are already used in a wide number of mobile handset, as an example of this Linux is said to power 40% of china mobile phone (see here for details). Overall some reports estimates that Linux already powers 25% of the mobile phone crowd.

There is an important consequence of this, it is that on the average it probably requires very little software development to ship a Linux powered handset out of today existing hardware. The OS drivers for the different component that needs to interplay are probably already here.

Java on Dalvik virtual machine

This is where Android innovates the most, and where we are eager to see how things are performing on real handsets. Currently people are familiarizing themselves with the concepts in Android by making analogy with Linux on the one hand and J2ME on the other hand. In our view there is more in Android than the reunion of those 2. Taking a few shortcuts on what Google has not yet clarify this is our reading of what stands out.

All applications are equals …

We anticipate that this will not be exactly true for security reasons (more on this in a future post), however we understand that all applications will use the same libraries accessible from “Java Dalvik” (some being proxies of Linux libraries, some others being developed in Java). This put at the disposal of mobile applications installed on the handset much the same resources (eg GUI libraries …) as the application originally on the device.

This is to be contrasted with a Java mobile application installed over the air onto a Java handset. Such application is a second class citizen on the device and run inside a container known as the AMS which is implemented by the device manufacturer. This is one the thing that hurt the most with J2ME as the quality of the implementation of this container vary widely across devices, this resulting in one of the nightmare of the seasoned J2ME developers known as device fragmentation sometimes summarized as write once, debug anywhere. There is a second problem with the approach currently taken on Java mobile devices and that you will discover after having courageously solved the issues that results from “platform” fragmentation. On many handsets, the container just sucks, you have down the best you could but for example the end users of your applications will have to interact with several menus before being in a position to start your app, or your app will have to be further customized to look good on a specific handset.

Android takes a different road, you install onto a device a well defined operating system (Android Linux ?) which provides a uniform container inside which to run all devices application. As every application are equals chances are high that fragmentation issues will have been addressed before they hurt you as for example you use exactly the same widgets as the applications central to the operation of the phone…

A framework to develop mobile application

One of the first thing you have to learn with J2ME is to forget about everything you know about Object Oriented programming. To limit the size of executables you generally end up embedding all the code in few classes that at most act as code container. Dalvik Java on the other hand proposes well structured construction (Activity, Intent…) that fits nicely onto what is a mobile application. Our engineers find the classes proposed by the framework quite intuitive to use, and a good help to efficiently code the application.

Focus on what you do best

Say you are constructing a mobile email application, after going through the basics you will rapidly be in need of viewer for pdf documents , images … On Android you will need to do very little to marshall the data to an application dedicated to this. An object bus is available to allow smooth collaboration/context switching in between different application each specialized on a single task.

Show us the devices

The explanations given by Google on how Dalvik on Android Linux can deliver good performance Java on low resources processor are sound but rather sketchy at this stage. The main questions are, how long will it takes before manufacturer starts shipping workable Android devices, and looking to the full spectra of mobile phones available today at which end of the scale will be the minimal android device (a 50 box mobile phone or several hundred box smart phone ?).

Given the pragmatic approach taken by Google it could be that we are very close from meaningful devices release, but many different factors can delay this. The fight for the conquest of the mobile world will be interesting to follow in the coming months…

One question KerPass often receive relates to how safe is using a phone to store software token ? A mobile token like the one part of the KerPass UST system, requires storing several cryptographic keys. Security specialists generally consider that software token are not reliable because nearby malicious software can read and duplicate the private information it contains. Common sense certainly suggests that a secure storage system (eg smart card) is a better location to store private keys than say disk storage. That said the complete analogy that most are making in between the modern open and insecure pc and the mobile phone is not accurate. They are reasons beyond “It is nice to have that there…” that make the mobile phone well suited to be a token container.

Propagating mobile malware

If you want to construct a malware for mobile phone today, you ‘ve got to decide on what technology you want to use. Though there is currently not such a thing as a unified mobile platform, you roughly have 2 choices :

1. Java
2. Native code

The Java mobile malware

If reaching a large number of handset with a single development effort is your goal (electronic criminals like being efficient), mobile Java is a tool of choice giving you access to more than one billion of handset today …

It is certainly possible to construct mobile software in Java that create problems (eg send costly sms …), that said the security model of mobile Java has an interesting feature. Two applications that are part of different “suite” can not share storage, hence a mobile Java malware is not technically in a position to read/copy data that pertain to another application be this application your personal agenda or a mobile token …

Security is one of such domain where less is more. It is interesting to observe that meanwhile mobile Java settled on this simple and efficient rule (data will not be shared in between application), recent developments are aiming at offering shared access to on phone security elements (the SIM and future NFC on board smart card). No doubt that efficient solution will be proposed to accurately restrict the access to those sensitive resources , that said if you are evaluating immunity against external malware you shall note that simple java storage file (aka “record store” …) are more immune than security application inside phone security elements …

The “native” mobile malware

Given current biodiversity of the mobile ecosystem, it is difficult to paint an accurate picture of the situation. As long as a mobile phone allow to install third party native applications, a knowledgeable outsider will be in position to take advantages of device operating system vulnerabilities…

Though some mobile OS vulnerabilities have been documented, mobile phones have so far remained untouched by “native” mobile virus … The main reason for that is the difficulty to develop malware that are portable across a large number of handsets. There is no long term guarantee provided by this. The good news is that some mobile OS are pro actively addressing this issue.

A recent development of Symbian OS is allowing to enforce efficient privacy policy at the level of the operating system. Starting with Symbian 9, every application can store data in a private area that is not accessible to any other application on the handset. This feature known as “data caging” allows to efficiently protect the phone against unwanted information duplication by external malware. This interesting development (which other OS can easily replicate…) paves the way for the mobile OS to be the system of choice to protect personal information.

Beyond “data caging”

In the case of a networked device there are efficient solution to render the private keys file not usable by a third party even after it has been duplicated. This goes far beyond what PKCS #5 password based encryption allows to do, and form the basis of what KerPass calls a Software smart card. More on this in a future post …

KerPass is making a presentation at the Ip convergence expo in Paris on the 3,4,5 October 2007. Our presentation (in French but speakers can attend you in English…) will be on the 3rd of October at 17:10 hrs , as part of the European telecom startup event.

Thanks to CEFT (Club des entrepreneurs francais des telecom) for their invitation.

If you want to have a hand on demo on how to make full use of the UST token system, or get to know the new SMS token system this is the place.

We took quite a while to come here, but the new API is finally operational :
Time synchronous one time password and ECDSA digital signatures can be used in the context of any web application, after installing KerPass onto end user mobile phone.

• The demo as usual allows an efficient hand on introduction to the complete system
• At https://realm.kerpass.com/ you find a web application for creating and administering security realm to support your own applications
• The url https://api.kerpass.com/ provide full access to the api.
• All KerPass documentation can be found here.

Don’t hesitate to contact us to obtain the necessary applications to install onto end user mobile phone.