Future

It is always difficult and risky to gaze into the future and predict what is coming down the line, but it is also necessary to make educated assessments of the current technology and what is likely to be addressed in the near future. I will now attempt to do just that.

WTLS

WTLS, being based on an established and stable standard, is unlikely to change significantly or fundamentally for the foreseeable future. I expect that most of the changes in the next few releases will be oriented towards clarifying some issues in the specification and general 'housekeeping'. The 1.2 specifications did this, and added some advice about guarding against certain types of attacks. All of this information is only of relevance to people who are developing their own WTLS implementation, and also much of the information dates very quickly, so I would expect it to be refreshed in just about every release. I do not, however, anticipate any major changes unless a major security exposure in one of the ciphers is identified.

End-to-End Security

The WAP Forum has made it clear that they are aware of the issues around the security gap at the WAP gateway. They have also make it clear that they intend to plug the gap by providing an end-to-end security standard in a subsequent release. There have been hints that they would attempt to address this through changes to WTLS, but I think that this is marketing rather than technology speaking. The issue does not arise because of any weakness in WTLS and is caused solely by the position that the gateway fulfils in the WAP communications chain. In order to address the issue, either the gateway has to be eliminated or some other solution has to be implemented, probably at a higher level in the protocol stack. The WAP Forum has also indicated that the WMLScript Crypto library may be extended in the future to include cryptographic functions. At this point in time there is only a function that supports signing data. To my mind, it seems logical that the way to implement end-to-end security is by means of encryption functionality at the application level. A necessary prerequisite for this, however, will be the capability of mobile devices to deal with the processing loads associated with encryption functions. Part of the solution to this problem may actually lie in the WIM.

WIM

The Wireless Identity Module specification is new in the WAP 1.2 specification. It provides a means to offload the storage of keys and of cryptographic functions onto what is described as a tamper proof device. This is basically a smart card, although it could also be a SIM. The specification covers only the low level capabilities of a WIM in the current specification, and doesn't present an API for making use of a WIM when present, although I expect that an API and framework will be provided in a future release. The introduction of the WIM could help to address the issues around authenticating the device as opposed to the user.