Java Card

General info

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.

  • Official press statement containig general information about the impact of the vulnerabilities.
  • Frequently Asked Questions about our discovery.
  • Technical details of conducted attacks and security issues found.
  • Status of the communication with vendors of affected technologies.

Project newsroom

Java Card - Press Info no. 2
APR 2019

Java Card - Press Info no. 2

On Mar 20, 2019 Security Explorations reported a security vulnerability (Issue 19) to Gemalto [1], that made it possible to achieve read (...)

Read more
Java Card - Press Info no. 1
MAR 2019

Java Card - Press Info no. 1

Security Explorations discovered multiple security vulnerabilities in reference implementation of Java Card technology [1] from Oracle used (...)

Read more


Why did you start Java Card project?

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.

What's so special about Java Card?

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.

What companies could be affected to the reported issues?

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..

What is the Java Card reference implementation?

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.

What's your response to Oracle evaluation of the reported issues?

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.).

Does the ability to catch malicious / exploit codes by the Off-Card Bytecode Verifier matter?

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).

Could it be that Oracle is downplaying the impact of the issues

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.

Is Gemalto evaluation of the reported issue correct?

Unfortunately not. This is further explained in our press release.

What's the impact of your findings?

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.

Why did you target Gemalto SIM cards in your research?

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.

Why is SIM card so important?

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.

Would it be possible to implement a stealth and persistent backdoor for a SIM card?

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.

What is the remote Gemalto SIM card applet loading vulnerability about?

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.

What's the result of your Call for Support regarding Gemalto Java SIM cards research?

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.

What's the fixing status of USimera 3G Prime vulnerability (Issue 33)?

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:

  • vendor's policy preventing open SIM cards to be provided to companies in the security sector is a "security through obscurity"
  • this will not prevent bad actors (such as some nation states) to investigate security of the cards
  • this contradicts vendor's statements regarding cards' security posture too

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.

Oracle Vulnerability Reports

  • SE-2019-01-ORACLE, Issues #1-18, PDF file, 1630KB (download)
  • SE-2019-01-ORACLE-2, Issues #20-25, PDF file, 339KB (download)
  • SE-2019-01-ORACLE-3, Issues #26-32, PDF file, 571KB (download)

Gemalto Vulnerability Reports

  • SE-2019-01-GEMALTO, Issues #19 and #33, PDF file, 577KB (download)
  • SE-2019-01-GEMALTO-2, Issue #34, PDF file, 833KB (download)

Additional materials

  • Reverse Engineering Java SIM card, PDF file, 748KB (download)
  • SIM card vendor's questionnaire, PDF file, 219KB (download)


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.

  • "Security vulnerabilities in Java Card", Proof of Concept codes for Issues 1-18 and 20-32, ZIP file, 246KB (download)


This page presents current status of the communication process with vendors of affected technologies.

Summary of the communication process:

  • 20-Mar-2019
- Vulnerability Notices are sent to Oracle (Issues 1-18) and Gemalto (Issue 19)
- Gemalto acknowledges successful reception and decryption of the report. The company informs that relevant Business Unit was contacted in order to reach engineers team in charge of the affected technology and that it will come back as soon as it has any relevant information to communicate or need additional data.
- Oracle confirms successful reception and decryption of the report. The company informs that it will investigate based on the data provided and get back to us soon. The company will provide monthly updates for any confirmed vulnerability till the issue is addressed.
  • 21-Mar-2019
- Vulnerability Notice is sent to Oracle (Issues 20-25).
- Oracle confirms successful reception and decryption of the report.
  • 28-Mar-2019
- Oracle thanks for the reports and for sharing our concerns regarding the security of Java Card products. The company notes that the security concerns reported (Issues 1-18, 20-25, 26-32) are related to the Oracle Reference Implementation, which is only designed as an example of the functional behavior of a Java Card runtime. It is not intended to operate in a production environment (and under the threats typically associated with such an environment). These concerns are technically addressed by the use of bytecode verification. Additionally, the company informs that in response to Security Explorations email, Oracle have reminded its licensees of the need to use bytecode verification as a prerequisite to the execution of applications on a Java Card product. The company will make sure that the scenarios reported by Security Exploration continue to be tested by the Oracle Java Card Off-Card Verifier. Finally, Oracle will update the public documentation to strengthen the recommendation that bytecode verification be performed as a mandatory step.
  • 29-Mar-2019
- Security Explorations asks Oracle whether reported issues are treated by the company as security concerns rather than security vulnerabilities. The company informs Oracle that issues denied by the vendor (not treated as security vulnerabilities) are not the subject of its Disclosure Policy (their technical details and associated POCs are released, so that generic public can make the judgement). Security Explorations also asks Oracle whether company's response implies that Oracle reference implementation of Java Card VM that was shown to be vulnerable to 31 issues is not used by any licensee 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. in any real life Java Card based products ?
  • 30-Mar-2019
- Gemalto informs that its R&D Card teams and JavaCard experts have thoroughly studied the report submitted (Issue 19) as well as other technical information made public by Security Explorations. The company informs that Java Card 3.1 reference implementation from Oracle is not used by Gemalto cards and that it is not intended to be implemented as such in products. The company refers to reported Issue 19 as potentially impacting Gemalto products. In the context of the requirement for an attack to successfully load a malicious applet into a target card, Gemalto states that to the best of its knowledge there is no vulnerability in the applet loading process. Hence, the company considers that the presented scenario is not applicable to the said Gemalto products used in compliance with their user guidelines.
  • 01-Apr-2019
- Oracle responds that it believes the attack methods are not applicable to Java Card products when bytecode verification is performed. The company refers to the reported issues as concerns and states that the attacks are focused on the Oracle Reference Implementation (RI) and the use of code that does not pass a verifier. Oracle informs that the RI is not intended to operate in a production environment and its review confirmed that all issues reported by Security Explorations are caught by the Oracle Java Card Off-card verifier (the use of a verifier prevents such exploits). Oracle 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.
  • 15-Apr-2019
- Security Explorations provides Gemalto with an updated version of its report indicating USimera issue is a separate vulnerability (Issue 33). The company also provides Gemalto with another security report describing unauthenticated, over-the-air loading of arbitrary Java applet code into company's Java based SIM card (Issue 34).
- Gemalto acknowledges successful reception and decryption of both vulnerability reports. The company informs that in case of a confirmed issue it promotes the OWASP Responsible Disclosure, which provide a climate of trust. Gemalto proposes Security Explorations to have a 2 months embargo period, which should let the teams to compute the CVSS scoring, to fix the vulnerability and to draft communications to customers.
- Security Explorations informs Gemalto that it doesn't give vendors any deadline with respect to the fixing of reported issues (it may take 2 months or longer). The only obligation vendors have is to confirm or deny reported issues and provide status reports regarding the fixing process. The company refers Gemalto to its Disclosure Policy for non-commercial security research along company's FAQ on that.
  • 26-Apr-2019
- Security Explorations asks Gemalto whether the company can officially confirm an over-the-air applet loading vulnerability (Issue 34). The company also asks Gemalto whether it still considers reported Java Card issues (19 and 33) as not applicable to its products.
  • 31-Jul-2023
- Security Explorations asks Thales PSIRT whether 4 years after the disclosure Thales (Gemalto owner) is willing to provide information regarding fixing status of USimera Prime 3G vulnerability (Issue 33) ? Security Explorations also asks whether the issue could be addressed through software means or the only way to address it was to either recall vulnerable cards from the market and introduce new ones with a fixed SW version ? With respect to the "no sale policy to security companies" and information received from Smartjac company, Security Explorations asks Thales whether it indeed imposed such a policy on its sale partners.
  • 31-Jul-2023
- Thales PSIRT responds that the email has been taken into account and has been forwarded to the concerned engineering.
  • 04-Aug-2023
- Thales PSIRT informs that it successfully reached the engineering team managing this line of products. Due to the current period (vacations?), they expect to receive a feedback around week 34.
  • 23-Aug-2023
- Security Explorations informs Thales PSIRT that taking into account its response and the time passed so far, it is assuming a response is to be received this week (or not received at all).
  • 24-Aug-2023
- Thales PSIRT responds that Thales is not in position to disclose any information related to the fixing status of USimera Prime 3G issue as this information and its implementation are of confidential nature. Thales PSIRT confirms that Thales DIS has modified its commercial agreements with resellers and these commercial agreements are also of confidential nature and shall consequently not be disclosed to third parties.