In a result of its research investigation efforts, Security Explorations discovered multiple security vulnerabilities in Java Card technology.
This section of our website presents the most crucial information regarding the project that lead to this discovery.
In the past, we demonstrated successful hacks against Java for mobile phones, set-top-boxes, desktop computers, Weblogic server, database and a cloud. Java card was the last standing piece of a Java ecosystem that hasn't been the subject of our security investigation. So, trying our skills against Java Card was pretty natural.
According to Oracle [1], Java Card is deployed to nearly 6 billion devices each year. It is a leading software platform to run security services on smart cards and secure elements, which are chips used to protect smartphones, banking cards and government services.
Software and hardware companies that rely on a reference implementation of Java Card technology from Oracle. Java Card vulnerabilities should be of a particular concern for Oracle Java Card licensees such as Goldpac, KONA@I, Setec Oy, STMicroelectronics, Toppan Printing, Smart Card Laboratory Inc, HiSmarTech, Giesecke & Devrient GmbH, Athena, Sermepa, Plastic Card Enterprise, Newcom Pte, Hengbao Co., Eastcompeace Smart Card Co., Shanghai COS Software Co. and Datang Microelectronics Technology Co..
This is the reference implementation of Java Card runtime environment developed by Oracle. It is available to general public as part of Java Card Development Kit [2] in a form of a simulator.
Oracle claims that the discovered issues were reported for a Java Card Reference Implementation (RI), which is not intended to operate in a production environment.
We asked Oracle whether their response means that Java Card licensees do not rely on RI in any real life products. Oracle did not answer directly. Instead, the company stated that it is not in a position to assess the security of the implementation of Java Card in 3rd party products. Those third party vendors would need to validate whether Security Explorations' findings apply to their deployment of the Java Card technology.
Oracle's response does not seem to be consistent with the usual Java technology's licensing process.
When a given vendor licenses a Java technology from Oracle, along the license, it is likely given all the tech including reference implementation of a target Java VM.
This approach has been used for Java ME. As a consequence, security issues found in a Java runtime used by mobile phones did affect a reference implementation of Java ME (and vice-versa).
Oracle's claim that its Java Card RI is not intended to be used in a real life product implicates that the licensee is either supposed to go to some other vendor for a reference implementation of Java Card VM or to build its own VM in order to implement and deploy Java Card code for its products. And this doesn't make sense as the licensing is usually about acquiring both permission to use a given tech along the tech itself.
In that context, it would be natural for major hardware vendors such as STMicroelectronics (with dozens of various Java card chips in its product portfolio), Giesecke & Devrient, NXP and Infineon or a printing company such as Dai Nippon Printing to take a reference implementation from Oracle, customize it a little bit to fit its needs and then put it into its products (chips, smartcards, SIMs, government IDs, passports, etc.).
In our opinion the ability to detect malicious applets by Oracle Off-Card Verifier does not matter much. The Off-Card Verifier is unable to prevent an attack against the vulnerable card as it is used off-card (as the name implies). What's most important is that it's use can be simply omitted by an attacker. Malicious code can be loaded and executed on a target card regardless of whether it successfully passed the verification process or not. The exploit scenario simply does not rely on Oracle Off-Card Bytecode Verifier.
Our findings are about vulnerable runtime that is missing some key security checks (memory and type safety).
In that context the Bytecode Verifier does not seem to matter. It's the security of the runtime (or its lack of) that matters.
Finally, it's worth to mention that a remote applet loading vulnerability affecting Gemalto SIM card could be exploited regardless of the bytecode verification in place (unverified code could be directly loaded into the card).
It could be taking into account the nature of the flaws and potential liabilities (billions of Java Card based devices deployed in the field, security sensitive sectors such as financial and government along the inability to fix the issues found due to their hardware nature - Java Card VM is usualy part of the ROM mask). We are however not in a position to asses that.
Unfortunately not. This is further explained in our press release.
A malicious Java application might achieve unauthorized access to target cards (such as to code and data memory of other applications or STK keys). It can modify target card operation (banking, telecom or identity) in such a way, so that a stealth and persistent backdoor could be installed into the card. Our analysis of selected SIM cards from Gemalto indicate that development of such a backdoor should be possible.
For banking cards / transportation cards, there is a potential for a malicious applet to interfere with payments conducted with the use of a card or to get access to secret keys deployed into it.
Finally, found vulnerabilities itself constitute a solid starting point for an in-depth security analysis and reverse engineering of Java card world. They pave a way for a discovery of far more serious issues such as the remote over-the-air applet loading vulnerability we found in a Gemalto Java SIM card.
Gemalto is just one of the vendors of which Java / SIM cards we have in our repository. It includes cards from Gemalto, Giesecke & Devrient and Oberthur among others.
In that context, Gemalto should be perceived more in terms of a flagship example of our research and its thesis, rather than its actual target.
SIM card is an extremely powerful (in terms of a functionality and data access), hidden microcomputer embedded inside the mobile phone (or tablet). It is usually not taken into account when enumerating a security threat surface for a target mobile device (the SIM is assumed to be a secure and trusted component, which is under a sole control of a mobile operator).
Beside a possibility to control all mobile phone's communication (calls, SMS and MMS messaging, data channels), SIM card has the ability to control the mobile phone as well. All by the means of the so called proactive commands (3GPP TS 31.111 [3]), which among other things make it possible for the SIM to send SMS messages, set-up calls or even launch a web browser.
The above, makes the SIM a perfect location for a stealth and persistent backdoor.
Upon learning some Gemalto SIM card internals [4], we conclude that it should be possible to install a hidden (invisible to the operator and an end user) and persistent backdoor code into vulnerable SIMs. Such a backdoor code could for example intercept or install custom APDU handlers in a global Security Domain (Card Manager), interfere with over-the-air / SIM Toolkit processing or change content of preinstalled Java packages and applications.
This vulnerability (Issue 34) makes it possible to upload arbitrary Java application into vulnerable SIM cards. The actual loading mechanism makes use of SMS messaging and can be invisible to the user of a target phone.
The vulnerability is also a perfect illustration of the impact and potential of Java Card weaknesses as a Java Card weakness made it possible to discover it.
The target of the call hasn't been reached as only one company responded to it. This was ISEC from Poland.
We take the opportunity to thank ISEC for their trust and willingness to support our security research. We feel truly privileged to learn that a company formed by members of a well known Polish security research group (iSEC Security Research) was ready to put a considerable amount of money into our project. This earns our highest respect.
While USimera Prime 3G card has been previously acquired from and is still listed by Smartjac company in its web store, we could not make the purchase of this (and some other 5G cards) for security evaluation / vulnerability fixing status verification purposes.
Smartjac based its inability to sell the cards to our company as following (25 Jul 2023):
"Our relationship with our SIM card suppliers is grounded in the principle of ensuring maximum security and protection for all parties involved. As such, our agreements have certain restrictions, including provisions that prevent us from providing open SIM cards to companies in the security sector".
We indicated to Smartjac that:
We asked Smartjac if USimera 3G Prime that is available for purchase in the company web store has fixed firmware for a security vulnerability published 4 years ago (the vulnerability making it possible to achieve full access to smartcard memory, bypass applet firewall or gain native code execution).
We also asked Smartjac if the policy of "no sale" to security companies is enforced by both Idemia (Oberthur) and Thales.
No response was received from Smartjac.
Due to the above, we are not able to verify fixing status of a vulnerability affecting USimera Prime 3G card that is still available for purchase from Smartjac (and that could be present in the cards in the field).
This page presents details of security vulnerabilities and attack techniques discovered as a result of our Java Card security research project. These details are provided in a form of original vulnerability reports and accompanying Proof of Concept Codes.
Please, note that a separate web page has been set up where we share information based on the experiences gained in the SIM / USIM card security space.
Proof of Concept Codes below are provided purely for educational purposes only. It is expressly forbidden to use them for any purposes that would violate any domestic or international laws. If you do not agree with this policy, please leave this page.
This page presents current status of the communication process with vendors of affected technologies.
