Java Card

Back to research

{ FAQ }

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

  • Did Gemalto confirm reported over-the-air applet loading vulnerability ?

    Unfortunately not. We haven't heard from the company since the reporting of Issue 34.

  • What Gemalto SIM cards could be affected to this flaw ?

    The cards with preinstalled A00000001810A30000000000424950 SIM Toolkit application could be affected by it. This in particular concerns GemXplore 3G V3.0 (confirmed), GemXplore 3G V3.1 and GemXplore Expresso V3.3 SIM cards.

  • Could Issue 34 constitute a backdoor ?

    Taking into account the hidden and system nature of Gemalto's proxyinstaller application along its privileged functionality that could be reached over-the-air, Issue 34 could be perceived in terms of a backdoor. We are however not in a position to asses that. Thus, a security vulnerability term.