[lxgr]

Without knowing the exact details, it seems to me like Oracle has a point here:

Java Card supports, broadly speaking, two types of bytecode verification: "On-card" and "off-card". On-card is secure against even malicious applets; off-card assumes that a trustworthy entity vets all applets before they are installed, and only signs them if they are deemed well-formed.

The off-card model just seems like a complete architectural mismatch for the eSIM use case, since there is no single trustworthy entity. SAT applets are not presented to the eUICC vendor for bytecode verification, so the entire security model breaks down if verification doesn't happen on-card.

Unfortunately, the GSMA eSIM specifications seem to be so generic that they don't even mandate Java as a bytecode technology, and accordingly don't impose any specific Java requirements, such as "all eUICC implementations supporting SAT via Java Card must not rely on off-card bytecode verification".

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

[gruez]

>The off-card model just seems like a complete architectural mismatch for the eSIM use case, since there is no single trustworthy entity. SAT applets are not presented to the eUICC vendor for bytecode verification, so the entire security model breaks down if verification doesn't happen on-card.

I thought the whole esim provisioning process required a chain of trust all the way to GSMA? Maybe the applet isn't verified by the eUICC vendor, but it's not like you can run whatever code either.

[ACCount36]

Seems like you actually could "run whatever code".

Apparently, GSMA recalled their universal eSIM test profiles. Prior to recall, those could be installed on ANY eSIM, and those profiles had applet updates enabled.

By installing a profile to eSIM and issuing your own update to it, you could run arbitrary applets.

[lxgr]

If the set of actors that can deploy bytecode to eUICCs includes all operators issuing eSIMs worldwide, arguably it might as well be everybody.

[ACCount36]

Nah, it's only "everybody" when I'm on the list.

My major gripe with eSIM as a technology is that you can't just issue your own profiles to it.