Hacker News Reader

Comment by frankjr | Hacker News Reader

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://mobiforge.com/news-comment/the-sim-the-tiny-computer...

View on HN

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.

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.

So much can be done in so little resources when you don't need to load 4177 files from node_modules folder

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

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.

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

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

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

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

Reply on news.ycombinator.com