I was part of the team that defined the binary format that has been in use since the end of the 1990’s. The selected solution was not my preferred one, as I preferred a pre-linked version. At the time, everybody agreed that on-card verification was too ambitious, so this was never considered for Java Card 2.1, the ancestor of today’s Java Card specification.
In the following years, we wasted a lot of time working on a much more ambitious version of Java Card, which never made it, but we never worked on addressing this issue of unverified bytecode, mostly because we had the cryptographic protections provided by GlobalPlatform. If nobody can load unverified bytecode, where is the problem?
As an evaluator, this allowed me to reverse engineer many types of Java Card, as I was allowed to download unverified (and very much illegal) bytecode into cards. Over time, most virtual machines have included runtime countermeasures, and some implementations have been difficult to attack with illegal bytecode for quite a while.
Yet, Java Card has become an industry standard. Strong implementations exist, in which loading unverified bytecode is about impossible, and then, exploiting unverified bytecode is challenging. But on the other hand, weaker platforms also exist, and recently, following a combination of mistakes from various stakeholders, one of them was broken; luckily, by a researcher, not by a criminal.
The real surprise is not that this has happened. It is that it took over 25 years for it to happen. The lack of on-card verification has always been a weakness in the Java Card story. Over the past 25 years, there have been a few attempts to address the issue, but the industry never adopted them. Isn’t a solution to this issue a bit overdue?
The smart card industry is a small industry, with few actors, and Java Card has been a great success, its interoperability providing the basis for the deployment of billions of products every year. But the industry has been complacent, and although I am not part of it any more, I bear some of this responsibility since I have headed the Java Card Forum’s Technical Committee for a few years. I defended off-card bytecode verification many times, for instance in 2011 and quite vehemently in 2013.
But that was over 10 years ago, and I would now argue that it’s time to fix this issue. Despite minor updates, the core Java Card technology is over 25 years old. The similarity between the latest version of the Java Card Virtual Machine specification with its first interoperable version is striking. There have been almost no changes. The CAP file format is antiquated, and an update could allow all vendors to ensure that no illegal bytecode is allowed to run on the any card.
From a now outsider’s viewpoint, I believe that after the recent developments and an issue impacting the security of millions of unsuspecting users, the usual denials sound really out of touch with reality, so I am asking the Java Card community a simple question: Since you are pushing for Java Card to be the basis for our personal security, and asking us to trust you with our sensitive data, including our identity, isn’t it now the right time to put this bytecode issue behind us once and for all?