Soon, the Java Card 3.0 should be widely available to developers. Looking at the list of new features and specifications I can’t help to have this déjà vu feeling, and I am not talking about the classic edition here.
Here it goes:
Multithreading
Network Communications
Access Control
…
When is the last time you saw such an announcement of combined technologies? Well in my view it is around 1993, when Microsoft decided to introduce Windows For Workgroup. At that time there were a lot of talks regarding the “peer-networking capabilities as a security risk” (http://www.byte.com/art/9402/sec10/art3.htm) and today things aren’t that different (http://javacard.vetilles.com/2007/12/17/countdown-which-security-in-java-card-3/)
The other analogy is the relatively low recognition of the importance of the multithreading feature. A Google search for “Java Card”+ security did return 259,00 hits, while the search for “Java Card”+ multithreading did only return 639 hits!
But think about it, today’s acceptance of computer applications is based on multithreading not security or brute power. Multithreading is the key, at the desktop users wouldn’t accept anymore to switch between applications, email/rss feeds running, download have to happen silently in the background; at the server side things aren't much different multithreading is key to scalability and performance. Users are willing to compromise (e.g. the internet before broadband) as long they could do simultaneous things.
So am I snubbing Java Card 3.0? Not at all, I just believe that the most powerful technology in Java Card 3.0 is multithreading, and it seems overlooked. It allows other technologies (Web Applications, Transactions, Inter Application Communications…) to deliver their full potential. We have the potential to see there a revolution similar to what was the Internet to the PC back in the mid 1990’s, then to B2C and B2B applications.
So is multithreading, communications, access control enough to make a smart card revolution? Probably not, a killer app is required, as what the web browser and search engine were to the web. And by the way such a killer app and its usage is likely to suck up most of the resources that a moment ago seems to be unlimited.
Java Card 3.0 has the potential to bring a breath of fresh air, to a confused card industry. But more efforts have to be made to make it sexy, the best new concept in the world won't make money unless people know it's interesting and become enthusiastic about it.
So what will make you say hello to Java Card ?
Subscribe to:
Post Comments (Atom)
2 comments:
I'm not sure that multithreading is a desirable (if even workable) feature for a smart card OS. Smart cards are currently only required to cheaply and securely store data, and this functionality determines the on-card resources and application environment. If new technology came out which allowed very inexpensive extension of card resources (e.g. 20+ MHz CPU, 500+ KB RAM) then a whole range of new options would appear.
A killer app would be where the smart card serves as the consumer's PC-in-a-wallet, carrying all their personal details, their cryptographic identification data (logon and authentication) as well as personal preferences and settings for configuring client services (web sites, etc). This data would be accessable via a standardised framework, independent of the system or service used by the client. Of course, this raises the spectre of standardisation again...
Extending this idea to m-commerce follows naturally: secure, transparent, over-the-air/contactless access to your securely stored personal data in your mobile device is something that (I think) would be attractive to consumers.
I like your suggestion, an identification service is a potential killer app for a java card 3.0. And I think this would use multithreading.
In that context, right now smart cards are mainly used for storing some confidential data (private key, PINs) and performing cryptographic operations but a lot of the logic remains on the PC/terminal. This could change with java card 3.0.
Surely in such a scenario, multithreading would be beneficial to handle the load (e.g. multiple external application accessing the service) and complexity of some protocols (e.g. multi-factor authentication) and monitoring what's going on (e.g. a thread to listen to external event).
I wonder if some would be interested to try this, to start with something like OpenID on java card.
Post a Comment