Computerworld’s revelations of doubts about the security model of the Mondex electronic cash system have led to stirrings amongst the New Zealand bank consortium which has franchised Mondex.
One member bank, the Bank of New Zealand, is understood to have scaled down its involvement with Mondex, at least for the time being, and Computerworld believes it has rejected one proposal for future developments from Mondex New Zealand. Mondex New Zealand chairman Jeremy Deane was unavailable for comment, but a BNZ spokesperson says the bank will continue to work with Mondex.
Meanwhile, Westpac, the most proactive of the Mondex banks, has apparently replaced its representative on the security sub-committee of Mondex New Zealand. Lindsay Stonehouse has gone and Owen Gibbens has taken his place. The other Mondex member banks are the ANZ, ASB, and National banks.
It appears that those banks and organisations which do proceed with Mondex trials will be using an operating system which may now struggle to become an industry standard.
Mondex International announced this month the formation of MAOSCO, a consortium aimed at establishing its “new” smartcard OS, MULTOS (formerly MAOS, or Multiple Application Operating System) as an industry standard.
This is an important part of the Mondex business model presented to Australasian banks. Mondex foresaw a large potential market for MAOS on non-Mondex cards and even the incorporation of GSM services.
But of the “eight major smartcard companies” Mondex says have signed up to MAOSCO, one is Mondex itself, one is Mondex’s 51% owner, Mastercard, and the third is Mondex’s long-term manufacturing partner, Hitachi. And two more —Motorola and Gemplus — would appear to have somewhat divided loyalties, given that they are also associated with Sun Microsystems’ Java Card API. The others are Dai Nippon Printing, Siemens and Keycorp.
Notably absent from MAOSCO is Schlumberger Electronic Transactions, the largest manufacturer of smartcards, terminals and systems, although Mondex approved Schlumberger as a manufacturer of its cards and terminals in February.
So far, Schlumberger, Gemplus and Bull — representing about 85% of the smartcard manufacturing market — have signed up to the Java Card API.
Sun’s marketing director, David Spenhoff, says the company is talking to “other manufacturers — but the key thing now for us is to move on and work with the manufacturers we have and with the card-issuing community, to get the bank and credit card consortia, the phone companies and so on. There will be a number of announcements related to that over the coming months.”
These would presumably involve Cyberflex, the implementation of the Java Card API demonstrated last month by Schlumberger. The first Cyberflex cards use a chip developed by Motorola, which has not been shy about boasting of its leadership. Schlumberger is promising “full commercialisation in a few short months” for the technology. Mondex says MULTOS will go commercial in the first quarter of next year.
The Australian banks’ due diligence report obtained by Computerworld describes MAOS as “an ambitious project with a high risk of failing to meet [then] scheduled delivery” in January 1998 and notes the “risk that Mondex will not become the industry standard as espoused by Mondex”.
Cyberflex provides for secure multiple application support, allowing “non-cooperating” applications to co-exist on a card, and for third-party applications (such as loyalty schemes) to be added after release. In other words, pretty much what MULTOS is intended to achieve.
The support of Schlumberger and other Java partners — plus the fact that Java Card is accessible to existing Java developers, who already have a dedicated application development and loading tool in Strategic Analysis’s EZ Formatter, and can test applications against a formal mathematical model of the Schlumberger interpreter — would seem to confirm that Cyberflex is well placed to become the industry standard.
Mondex has espoused the prospect of MAOS or MULTOS becoming the standard to its franchising banks, and Spenhoff says he believes “that Mondex will take a run at that still. But I think that at the end of all that MAOS will have the Java Card API sitting on top of it. That’s my prediction.”
Mondex in fact announced this month that “a limited number of industry-standard APIs, including Java Card, will be supported by MULTOS in future”, but gave no date for the addition. In the meantime, it is faced with the unappealing prospect of trying to get developers to work in either its proprietary MEL (MULTOS Executable Programming Language) or to program in C to the same API.
Microcontroller programming in C is regarded as particularly onerous, in part because some of the more useful programming tools have been ruled out as a potential security risk, and thus there are relatively few able smartcard programmers in the world.
Scott Guthery, a scientific adviser to Schlumberger, says a MAOS port to Java, and its wider developer base, might not be an easy job.
“MAOS is an application-specific operating system. It does Mondex real well but probably doesn’t support general-purpose computing,” says Guthery. “MEL is kind of a macro langauge that sits on top of MAOS. Assembly language macro languages can start to look a lot like C, so it’s not just a one-for-one translation into MAOS calls. Furthermore, it is probably implemented as MAOS-specific bytecodes, so that what you have is a Forth-link MEL interpreter on the card running MAOS/MEL bytecodes.
“All done, you say. Just translate MEL bytecodes into Java bytecodes and, presto chango, I’ve got a Java card. The buzz is that they tried and it didn’t work -— at least well enough that you’d want to run with it. It will be very interesting to see how they put the Java Card API 2.0 on top of MULTOS. I suspect it will be as much a marketing exercise as a technical one.”
Mondex will also still have to prove the worth of MULTOS’s applications security — the ability for applications from different vendors to co-exist on a card without interfering with each other or seeing each other’s data.
Guthery says the Schlumberger team which began working with Java did so because it recognised that application security was exactly the problem that loading code into World Wide Web browsers had posed and that Java had solved. “Conceptually at least, Java on a smart card was a no-brainer.”
Java’s processor independence, was another plus, says Guthery, along with the fact that “Java interpreters were being hammered on by thousands if not millions of Internet warriors every day. Holes had been found and fixed. Java security — as all security must be — was as good in practice as it was in theory. Every indication was that Java would allow smart-card security to be preserved in the face of open programming.”
Mondex security spokesman John Beric says Mondex will be “reponsive to the needs of its members” over Java.
“There are clearly some benefits to the Java language, and there are clearly some benefits in using chip-cards, otherwise Mondex would not exist. It’s an open question of when the marriage will take place — when the Java technology will be mature enough, when the Mondex business opportunity will require it. But we certainly don’t want to go against our members’ interests.
“It’s entirely driven by commercial pressure —we’re not precious at all about anything. Well, I guess we are precious about the integrity of our purse and the purse and so on. We develop it to the highest level, but that’s not incompatible at all with Java.”