As a part of JSR 248 Mobile Service Architecture (MSA) the JSR 177 Security and Trust Services API (SATSA) is finally getting implemented in more and more handsets.

(Image from JSR 248 specification)

SATSA consists of four optional and independent APIs:

• SATSA-APDU
• SATSA-JCRMI
• SATSA-PKI
• SATSA-CRYPTO

The two first are communication APIs for smart card communication. The latter two are security APIs. SATSA is providing security and trust services by integrating a security element. SATSA is optimized for using smart cards as the security element, like the SIM card in GSM devices, but the specification opens for other types of security elements.

Even though the SATSA specification was released in 2004 I haven’t seen it widely implemented in handsets. To be MSA compliant the implementation must include the CRYPTO API. The APDU and PKI APIs must be included if the device supports an applicable security element (such as a smart card). The JCRMI API is not required at all.

I’ve tried to find out which phones supports SATSA, but it’s still hard to get the full picture in the mobile jungle.

According to this page no Nokia devises implements the full MSA specification (only MSA subset), thus SATSA is not required. Still Nokia have implemented parts of the SATSA specification on some of their platforms: Nokia Series 40 3^rd edition supports the APDU API while the 5^th edition supports APDU and CRYPTO. Series 60 supports CRYPTO and PKI from the 3^rd edition.

When it comes to Sony Ericsson they have support for the full MSA specification in their Java Platform 8 (JP-8).

According to their homepage Motorola have one device that supports the MSA-subset and 15 that supports SATSA. I haven’t been able to find out which of the SATSA APIs Motorola have implemented.

For Samsung I didn’t find any devices that support SATSA searching at their developer site. Maybe I missed some?

You should have a look at the new device matrix provided by Sun: http://developers.sun.com/mobility/device/device to find what devices supports different JSRs.

So, the big question: How can we use the features JSR 177 provides?

The PKI API makes it possible to:

• Sign messages
• Create certificate requests
• Add a certificate or certificate URI to a certificate store
• Remove a certificate or certificate URI from a certificate store

The CRYTO API provides:

• Classes for creating message digests
• Classes for verifying digital signatures
• Ciphers to encrypt and decrypt data

The APDU API makes it possible to:

• Communicate with a Smart Card Application

The JCRMI API will most likely not be implemented in any handsets because it’s not a part of the MSA requirement.

An alternative to using the SATSA APIs is to use a 3^rd party library like Bouncy Castle. Bouncy Castle is a lightweight cryptography API that can be used with Java Me. So what’s the need for SATSA?

The biggest advantage is that you can store certificates securely in the security element by the use of the PKI API. Since the signing is done inside the security element, the certificates never leave the security element. It also makes the certificates easily portable if the user switches handset. Using Bouncy Castle you have to store certificates in non secure memory like the RMS, even though it’s possible to encrypt the certificates stored in the RMS they have to be decrypted into memory before using them.

The CRYPTO API does not introduce anything we can’t do today with a 3^rd party crypto API. It does not interact with the security element at all. Hopefully the cryptographic operations are faster when they are implemented natively on the device. You’ll also get a smaller JAR footprint when all the crypto packages are included in the device.

Unfortunately the SATSA APIs does not include methods for accessing randomness. This is extremely important for creating good cryptographic keys. The access to a good random source is one of the biggest lacks in Java Me security. I think SATSA would have been the right place to include such functionality.

I’m still a little confused about the APDU API. I have no previous experience with smart card communication. As far as I can see the MIDlet has to be signed to the operator domain to be able to communicate with the SIM Application Toolkit. Other applications on the smart card can be accessed by MIDlets that are in the 3^rd party domain.

What I haven’t been able to find out is if it’s possible to add my own smart card application on my GSM SIM card. If you know, please leave a comment!

It’s also possible to communicate with other Smart Card slots on the device, but I haven’t seen any devices with a free Smart Card slot.

Almost 4 years after the release of the SATSA API it’s not widely implemented in the handsets. To create secure commercial applications that run on common handsets you still have to rely on 3^rd party cryptography libraries (or create your own). Hopefully we’ll see more MSA full stack phones in the future!

References:

http://jcp.org/en/jsr/detail?id=177

http://developers.sun.com/mobility/apis/articles/satsa1/

http://developers.sun.com/mobility/apis/articles/satsa2/

http://developer.sonyericsson.com

http://developer.motorola.com/

http://wiki.forum.nokia.com

“Opening the ERP application on the mobile phone should be a pleasure. That is our only criteria for success.” So says Christer Rehn, Product Director of the Agresso Group, a publicly traded company delivering Enterprise Resource Planning (ERP) systems to thousands of customers around the world.Up to now, however, Agresso’s customers have only had access to the ERP application on their work PC. During the second half of 2008, Agresso will be implementing the mBricks platform, and this will enable customers to get ERP applications directly onto their mobile phones.

“Companies and employees alike expect people to be available,” says Rehn.

“Everyone is looking to make gains in efficiency wherever possible. Easy access to company tools allows for more control, and the workforce is utilised more efficiently. With mBricks, customers will be able to maximise their use of the mobile phone and the Internet in a comprehensive way.”

Agresso’s mobile solution will allow users to plan better and to make more efficient use of their time.

“There will be no need to go back to the office or to turn on the PC in order to get an update,” says Rehn.

mBricks is delivering the foundation for Agresso’s mobile solution, and makes it very easy for customers to start using it. For Agresso, the mBricks solution is an important additional service that can be used on all types of mobile phones, without requiring any form of hardware upgrade.

“This platform is very easy to use. You completely avoid having difficult discussions about correct technology and big investments. It is inexpensive and easy to get started, and the solution works on all types of mobile phones. That’s the beauty of it,” says the Product Director.

If a fit of enthusiasm following the iPhone SDK announcement last thursday, Sun annouced Java ME on the iPhone

“We’re very excited,” saud Eric Klein, Sun’s vice president of Java marketing. “We’ve spent the last 24 hours furiously looking through what information was made publicly available, and we feel comfortable enough at this point on the information we have to commit the engineering resources to bring the JVM over to the iPhone and the iTouch as fast as our schedules and Apple’s release schedule will allow.”

This spur-of-the-moment announcement caused some confusion in the developer community, as Apple clearly states “no runtimes allowed” in the SDK EULA:

Apple iPhone SDK Agreement: “No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and builtin interpreter(s)… An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.

This limitation does not only affect Java ME, but a wide range of software like for example Firefox browser. It has caused quite a bit of frustration-venting, like this one from Mozilla’s Rob Sayre:

Apple Bans Firefox, SpiderMonkey, Lisp, Lua, Ruby, Python, Rhino, Java, Opera, .NET, Squeak, Quake, Unreal, Second Life, GCC, GDB, GNOME, KDE, Photoshop, Word, Excel, Flash, Freetype and Zork (read)

Of course, any terms are subject to both negotiation and change. After contemplating this fact, Sun issued a more carefully-worded statement:

“After Sun announced our intent to create a JVM for iPhone and iTouch last Friday, there were questions raised in some blogs & forum posts about whether Apple’s iPhone license agreement allows us to deploy the JVM.

Our announcement was based on our excitement to build a JVM for the iPhone and the iTouch, as well as our assessment of Apple’s publicly available information on the SDK and related business terms. If there are clauses in the iPhone beta SDK license agreement that potentially limit third party application distribution, then these are items that we want to have a positive discussion with Apple about.

Sun and Apple have an ongoing relationship around Java SE on Mac OS X and we look forward to further discussions with Apple about a JVM for iPhone and iTouch. Sun definitely plans to deliver a JVM for iPhone and iTouch if at all possible!”

“Our customers want the CRM application on their mobile phone. And it should be easy to use, regardless of the type of mobile you are using. mBricks solves this in a way that will give customers a positive user experience.”

So says Guttorm Nielsen, Director of Product Development at SuperOffice, a supplier of CRM solutions. His main focus is that the application should be easy to use on a mobile phone, despite the small size of the screen and the keypad compared to a PC.

“We have a vision that every customer who buys SuperOffice will get the mobile application. It will be like a twin - or an extension - of the application they have on their PC.”

It is the Norwegian company, mBricks, that will enable all SuperOffice customers to get the CRM application directly onto their mobile phone. This will happen in the second half of 2008. mBricks is delivering the technology used by SuperOffice to build a great, user-friendly CRM application.

It is Nielsen’s objective to turn the mobile phone into a sophisticated tool for all CRM customers. It will make them as effective as if they were in the office.

The next mobile trend
“The next mobile trend will see phones loaded with good quality, admin applications,” says Nielsen, “and we in SuperOffice - with mBricks as a subcontractor - will ensure that our customers can bring their office functions along when they are away from their desk or their PC, and still be as effective.”

“We have been waiting for a technology that will enable us to use one single application on all types of mobile phones. Now mBricks is delivering this technology, and they are also ensuring efficient Internet speed. This won’t be slow as molasses - just a great user experience,” finishes Nielsen from SuperOffice.

Michael Mace wrote an excellent post named “Mobile Applications, RIP” on his blog. You have probably read it if you “follow the mobile space”. A lot of people has added their points, I’ll add some links at the end of this post.

The end is nigh!

The gist of Michael Maces post is: Downloadable mobile applications is dead, crushed by a fragmented market and restrictive business practices. The problems are now so bad that even the mobile web looks like a better way to deliver new functionality to mobiles.

Much of the discussion following the post has focused on the choice of technology and not on what I believe Michael Mace really is pointing to, the broken business model. Selling standalone mobile apps to end users does not work. Hardware bundling is gone, web storefronts are gone and the carriers don’t care about you. You are left with Handango who wants 50-70% of your revenue.

The web is supposed to save you, but the troublesome part is: What are you going to do between now and 2010 or so when AJAX capable browsers and browser APIs have reached mass market penetration?

All may not be lost. Before you put on a robe and join the choir chanting: “The next big platform will surely save us all”, check out this emerging trend:

Manufacturer storefronts

Handago and scattered web storefronts is out. Carrier portals is out. Software will be sold through on-device + web storefronts operated by the manufacturers.

• Software for the iPhone (and iPod touch) will be sold through iTunes.
• Software for Nokia devices will be sold through Ovi.
• Microsoft has just bought Danger who runs a an application storefront for Danger devices.

Manufacturers will act as a gatekeepers, deciding which are worthy of release, and publishing only approved applications.

“So what”, you may ask. “How is this different from the operators controlling/selling applications?” Well, you might end up on the short end of the stick again of course, but there is a couple of pretty significant differences from operator portals:

Per device instead of per operator

The operator will ask you to support all devices they have sold over the last 2-3 years regardless of whether they align with your target audience or not. You are forced to create a lowest-common-denominator solution, when instead you probably want to create an amazing service targeted to music phones, phones with GPS or whatever.

Kristian Segerstråle (Glu) to MocoNews:

“It’s time to go from defining the product based on the carriers’ desires to doing something completely new.”

“Who says you have to support 1,000 handsets from the start? How about 10 and see what the uptake is?”

Besides, forcing developers to support sub-standard devices is unhealthy for the mobile ecosystem. These devices needs to die.

Marketing

One of the main problems with the operator portals was that there is no way for the consumer to separate the wheat from the chaff. Operators treat everything like another SKU because this kind of content is low priority. Depending on the operator, you may not even be allowed to publish your company name. And either you pay the operator out of your nose to get exposure or you get zero exposure (my experience, anyway).

Developers on the other hand want to build their brand and the manufacturer storefront might be better than the operator portal. At least it can’t be worse.

Meanwhile, back on earth…

In contrast to the highly speculative prose above, here are a couple of statements from people developing mobile applications and services right now:
Barbara Ballard: “This quarter is not particularly different from other quarters: we get far more work designing applications than designing web sites.”
Simon Judge: “From my angle, there has never been a time when there are more companies looking for someone to create their native application.”

And from where I sit, I see mobile applications being developed like never before. It used to be garage operations that made mobile apps, now large companies are entering in a big way.
We see a lot of activity from ISVs that build mobile “companions” to their desktop-based software.

A couple of years ago everything was strictly vertical (and ran on Windows Mobile only). Now we see mainly horizontal applications like CRM systems, project management etc. for feature and smartphones in general. The clients sit in meetings waving their jailbreaked iPhones and demanding their software be “as easy to use as the iPhone”. Its a joy to be an Interaction designer these days!!

The mobile applications I’m involved with are typically sold directly to enterprise customers (not end-users), installed and maintained by the IT department and the business model is the same as desktop software. A hefty per-user fee.

More on the conversation here:

Michael Mace: Mobile applications, RIP
Mike Rowehl: Native Mobile Apps vs Mobile Web Apps
David Beers: Have mobile apps had their moment?
Rafe Blandford: The future of mobile development?
Dean Bubley: Standalone Mobile Apps vs Web Apps on Mobile