Live from JavaOne: Java Card and Smart Meters

The funny thing about this presentation is that I have first been invited to attend the e-Smart version of it (this week as well, in Sophia Antipolis). When I declined, they told me that the same talk was given at JavaOne, so here I am.

From Onzo’s Tim Holley and Oracle’s Jean-Yves Bitterlich, this is about Project Hydra. The project starts by healthcare issues caused by an aging population. The problem is to figure out what we can do at the infrastructure level to help addressing tomorrow’s growing helath issues of our elderly. This basically means being proactive.

Telehealth is possible, but the data needs to get out of the home. And since we are not talking about highly connected people, smart meters seem to be a solution. Smart meters bring a communication path into every home, and telehealth only transfers little data. The idea is to integrate new sensors (health sensors, like a scale or blood pressure) into the devices accessible from the smart meter infrastructure.

The idea is to add value-added services into smart meters, making it possible to get a better return on investment on the deployment of smart meters. This is the goal of Project Hydra in the UK. The idea is to integrate telehealth services of weight and blood pressure. The project combines a local Zigbee network to an external GPRS connection at the communication gateway shared by all the meters.

So, why smart cards in this project? The platform need to be able to evolve over time, with remote software updates, or added support for new devices over time. Of course, security is important as well, and isolating the applications from each other sounds like a good idea (the utility company doesn’t need to know about your blood pressure). All of this sounds good for Java Card:

  • Protecting valuable assets. Yes, smart cards do that.
  • Devices distributed in uncontrolled environment. Yes, we know how to handle that.
  • Personalisation during deployment. GlobalPlatform has everything it takes to do that.
  • Protecting assets of multiple stakeholders. Easy with a good firewall and a few Security Domains.
  • Remote software updates. This one is trickier, but why not …
  • High volume, low cost. Yes, we know how to do that.

All these issues have already been addressed by the smart card industry. An interesting bonus is here that smart cards also address some basic smart meter issues, (security in tariff upgrades, management of pre-paid accounts, protection against hacking, etc.)

Naturally, combining Java Card applets and GlobalPlatform security domains, every application gets its own little home in the home gateway. One interesting remark is that the smart card becomes a one-stop shop for people who want to deploy new applications into the smart meters. But then, this raises the question: who controls the smart card in the smart meter? In a deregulated market like in the UK, this question may not be as simple as it seems.

An important point is that applets may address some privacy issues by performing some basic processing directly in the home, and to only transfer select information (for instance, when blood pressure is over a given threshold).

In the architecture, the smart card is pretty much in control, and they have defined a SIM Toolkit-like way of working, in which the smart card provides the terminal with instructions about things to do, like send this data to the outside, or wake me up for the next measurement 24 hours from now.

Java Card 3 Connected would also allow the user to access its own data directly from a Web browser. This provides a partial answer to one of my favorite questions: Would the (younger) family members be allowed to get the information? They have more incentives than clinicians to actually use the information, and such a use raises very interesting security issues, and even more interesting privacy issues, because the elderly have a right to privacy, even with respect to their children.

Surprisingly, the main problem is here to be ready on time, because in many countries, the deployments are scheduled before 2020, which is awfully close when you don’t even have a specification.

Good luck to this project!

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *