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".
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.
>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.
There have been multiple occasions now where Oracle has outright dismissed or denied reported security vulnerabilities as being anything of note, or even existing at all.
Only to find out that nope, they were, and had been, or could be, exploited.
lxgr|7 months ago
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|7 months ago
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...
gruez|7 months ago
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.
FireBeyond|7 months ago
Only to find out that nope, they were, and had been, or could be, exploited.