With Mondays announcement of the Java Card 2.2.1 specification, Sun Microsystems Inc. demonstrates that the fundamental issues of next-generation IT apply across the entire spectrum of devices—from the largest server farms, to the richest desktop and portable clients, all the way down to the most minimal device that can still carry executable content. No matter where the work is being done, it has to conform to concerns about security, connectivity, standards and productive application development.
A Java Card is a form of smart card: that is, a package with the physical characteristics of a standard credit card, embedding the needed hardware for active on-board processing of stored data and for exchange of data with other devices. Specifically, a Java Card is a smart card that provides a Java run-time environment meeting certain guarantees for portability of code across all devices conforming to that specification.
A Java Card gets important capabilities by being able to execute algorithms, instead of just storing data in the manner of a magnetic stripe or other non-volatile memory. For example, it can participate in cryptographic transactions using “secret in plain sight” techniques like a Diffie-Hellman exchange. The 2.2.1 specification adds AES and elliptic curve cryptography support for high-level access by application developers.
Because Java Cards, and smart cards in general, are produced and distributed in quantity with an eye toward minimum cost, its vital that their security be designed—but not expensively overdesigned—to stand up against both logical and physical attack. The additional security of Java, as Ive noted before, derives as much from whats left out as from what the Java platform includes.
I spoke with Suns Java Card business unit director, Peter Cattaneo, just before the 2.2.1 announcement, and he put this issue in vivid perspective. “If anyone tries to tell you that other approaches to programming smart cards can also be secure,” he observed, “thats well and good—but if you explode the state space of the things that you have to prove by three orders of magnitude, it will be obsolete before you finish.” Theres a big difference between the possibility of security on the one hand, and the feasible provability of security on the other: I know which one I want.
And no IT node, however compact or resource-constrained, should fail to take (or at least attempt to take) this kind of responsibility for the protection of its data and its transactions.
The 2.2.1 specification also adds support for wireless communication standards: this reflects the momentum of wireless, in particular, and also the overwhelming importance of non-proprietary standards in general as foundations for all future IT initiatives.
Also provided in Java Card 2.2.1 are memory space optimization tools. Java Cards can be packaged as single-function devices, and the new Java Card S program thats part of the 2.2.1 update defines devices that bar the addition of new Java applets to a card; many applications of this technology benefit, though, by letting users and their service providers add code dynamically to a card already in the users possession. The new Java Card specification also continues the trend that Java arguably began toward reducing error-prone, often insecure manual management of the memory resource.
My conversation with Suns Peter Cattaneo concluded on an important note for enterprise developers. “The technical barriers are down to close to zero,” Cattaneo said, in terms of being able to use Java Cards to carry code from many different providers on a single device and to use that code for any number of different secure transactions. “The barrier, really, is which parties will trust which others.” Developing key partner relationships, and agreeing about how to establish and share trust so that customers enjoy both security and convenience, is the difference between possibility and fact: that makes Java Cards a target-rich environment for the strategically oriented enterprise development team.
Discuss This in the eWEEK Forum