[Fethbita]

In this case if you read the last few sections, they reported several issues to Oracle regarding their JavaCard Reference Implementation, but these have not been fixed stating that they are not supposed to be used in production. Oracle has the responsibility to fix these issues as they are the primary source for everything related to JavaCard’s and other vendors take their reference implementation as a reference.

Also see their previous reply[1] to the findings this company had from 2019 and I can’t help but agree with the article that if those issues were fixed back then, there is a chance that this wouldn’t have happened today.

[1]: https://www.securityweek.com/oracle-gemalto-downplay-java-ca...

[lxgr]

Definitely, no reference implementation should have security bugs.

But do you know if Oracle's reference implementation for Java Card is one using on-card or off-card verification, or more generally is assuming installs from only trusted sources?

There are many Java Card applications where the assumption of all bytecode being trusted is reasonable, especially if all bytecode comes from the issuer and post-issuance application loading isn't possible. Of course, that would be a complete mismatch for an eUICC.

[Fethbita]

It does not use on-card verification, because if it would have, the problem would not be present. You can check out their FAQ on the 2019 report[1].

[1]: https://security-explorations.com/java-card.html#faq

[lxgr]

Thank you!

Then I’d say this just points to a concerning lack of understanding of the security model on the implementer’s side.

In an ideal world, there would of course only be on-card verification, but resource constraints on smart card chips are still a factor.

In the second best of all worlds, Oracle would have one reference implementation each for trusted and for untrusted byte code, and a big bold disclaimer on when to use which, but I’m not convinced even that would prevent against all possible implementation mistakes.