Java Card

Back to research

{ Vendors status }

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.