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