3 ms·

The SIM card in your phone is running a Java VM. > Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java 2 bytecode run by a s

The SIM card in your phone is running a Java VM. > Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java 2 bytecode run by a standard Java Virtual Machine but with a different encoding to optimize for size. > Did you know, for example, that a SIM can run apps and communicate over the mobile network entirely independently of the host phone? Or that the SIM is arguably more in control of the phone baseband than the phone’s “main” operating system? Or that SIMs can support TCP/IP and run a web server? https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card https://mobiforge.com/news-comment/the-sim-the-tiny-computer-in-your-pocket-thats-really-in-control https://mobiforge.com/news-comment/the-sim-the-tiny-computer...

lxgr 2y ago
Your credit and debit card is too – even when using tap and pay (it's powered wirelessly through the field)! I think the fact that it's running loadable code at all is what's unexpected here, though, not really the fact that it does so using bytecode; that's mostly for compatibility across card OS vendors. Java/the JVM was what was cool at the time these high-level programmable smartcards started becoming popular. Introduced today, they'd probably be running WASM.
xenadu02 2y ago
Contactless and EMV Chip cards are the same. During provisioning the server sends a signed Java Applet to the Secure Element which validates the chain of trust then installs the applet. The EMV protocol involves "application selection" which lets the payment terminal tell the Secure Element OS which applet it wants to communicate with. ARQC (Authorization ReQuest Cryptogram) is where the applet on the card takes the payment terminal's payment request and identity info, signs it with the PK keypair unique to that provisioned card, and sends it back to the payment terminal which then hands it to the card issuer for validation and approval. A bunch of Java bytecode: the chip/SE, the payment terminal, and likely also on the server side.
- AnotherGoodName 2y ago
  The really cool part is that they are powered wirelessly, boot up cold, do the signing with their key and complete the transaction in a tap.
  - antonkochubey 2y ago
    So much can be done in so little resources when you don't need to load 4177 files from node_modules folder
- lxgr 2y ago
  Not all contactless payment cards are EMV cards (or even smartcards!), and not all EMV cards are Java cards, though. Early contactless payment protocols also started out as something adjacent to, but distinct from, EMV; they eventually got included under the EMV umbrella, but unlike for contact payments, the protocols (called "kernels") vary considerably between e.g. Visa and Mastercard. There's still a wide range of non-EMV contactless payment cards in use today, mostly for stored-value transit use cases (EMV works best when there's a network connection and doesn't handle long-term two-sided offline cases very well). NXP is an important player there (with their Mifare series of cards/chips); Felica is another (mostly in Japan).
Qem 2y ago
Wonder how many flops can one get from it. Did someone port Doom to a sim card already?
- lxgr 2y ago
  Historically, smartcard chips were very underpowered 16- or even 8-bit MCUs that couldn't even perform Java bytecode validation on-chip (which caused some security vulnerabilities in the past; there's interesting academic literature on this if you're curious, for just one example see [1]). These days, these are sometimes ARM M0 cores which are significantly more powerful. I think Doom over SAT (SIM application toolkit) is within reach :) [1] https://xavierleroy.org/publi/oncard-verifier-spe.pdf https://xavierleroy.org/publi/oncard-verifier-spe.pdf
humzashahid98 2y ago
The Java installer's installaation text "_ billion devices run Java" makes more sense after this. That's pretty amazing; thanks for the link.
samatman 2y ago
While this is true in the general case, some number of smart cards and SIMs run Java Card directly on the hardware, using the Jazelle instruction set from ARM. So a Java Actual Machine, rather than a Java Virtual Machine. https://www.design-reuse.com/news/4228/arm-securcore-supports-sun-microsystems-java-card-technology.html https://www.design-reuse.com/news/4228/arm-securcore-support...

lxgr 2y ago

Your credit and debit card is too – even when using tap and pay (it's powered wirelessly through the field)! I think the fact that it's running loadable code at all is what's unexpected here, though, not really the fact that it does so using bytecode; that's mostly for compatibility across card OS vendors. Java/the JVM was what was cool at the time these high-level programmable smartcards started becoming popular. Introduced today, they'd probably be running WASM.

xenadu02 2y ago

Contactless and EMV Chip cards are the same. During provisioning the server sends a signed Java Applet to the Secure Element which validates the chain of trust then installs the applet. The EMV protocol involves "application selection" which lets the payment terminal tell the Secure Element OS which applet it wants to communicate with. ARQC (Authorization ReQuest Cryptogram) is where the applet on the card takes the payment terminal's payment request and identity info, signs it with the PK keypair unique to that provisioned card, and sends it back to the payment terminal which then hands it to the card issuer for validation and approval. A bunch of Java bytecode: the chip/SE, the payment terminal, and likely also on the server side.

AnotherGoodName 2y ago
The really cool part is that they are powered wirelessly, boot up cold, do the signing with their key and complete the transaction in a tap.
- antonkochubey 2y ago
  So much can be done in so little resources when you don't need to load 4177 files from node_modules folder
lxgr 2y ago
Not all contactless payment cards are EMV cards (or even smartcards!), and not all EMV cards are Java cards, though. Early contactless payment protocols also started out as something adjacent to, but distinct from, EMV; they eventually got included under the EMV umbrella, but unlike for contact payments, the protocols (called "kernels") vary considerably between e.g. Visa and Mastercard. There's still a wide range of non-EMV contactless payment cards in use today, mostly for stored-value transit use cases (EMV works best when there's a network connection and doesn't handle long-term two-sided offline cases very well). NXP is an important player there (with their Mifare series of cards/chips); Felica is another (mostly in Japan).

Qem 2y ago

Wonder how many flops can one get from it. Did someone port Doom to a sim card already?

lxgr 2y ago
Historically, smartcard chips were very underpowered 16- or even 8-bit MCUs that couldn't even perform Java bytecode validation on-chip (which caused some security vulnerabilities in the past; there's interesting academic literature on this if you're curious, for just one example see [1]). These days, these are sometimes ARM M0 cores which are significantly more powerful. I think Doom over SAT (SIM application toolkit) is within reach :) [1] https://xavierleroy.org/publi/oncard-verifier-spe.pdf https://xavierleroy.org/publi/oncard-verifier-spe.pdf

humzashahid98 2y ago

The Java installer's installaation text "_ billion devices run Java" makes more sense after this. That's pretty amazing; thanks for the link.

samatman 2y ago

While this is true in the general case, some number of smart cards and SIMs run Java Card directly on the hardware, using the Jazelle instruction set from ARM. So a Java Actual Machine, rather than a Java Virtual Machine. https://www.design-reuse.com/news/4228/arm-securcore-supports-sun-microsystems-java-card-technology.html https://www.design-reuse.com/news/4228/arm-securcore-support...