OpenCrypto: Unchaining the JavaCard Ecosystem | Hacker News Reader

OpenCrypto: Unchaining the JavaCard Ecosystem

dan.enigmabridge.com

90 pointsdc35212 comments

It's a pretty cool hack to reuse crypto primitives in order to implement some operations.

If you're not very familiar with JavaCard and why this would be noteworthy, JavaCard is basically a very stripped-down version of Java that only bears some similarity to regular Java SE. Amongst these limitations is a very stripped down standard library (there is no java.lang.String for example), only a few types (byte, short and arrays of bytes, support for int is optional, no support for char, long, double, float, etc.) and no garbage collection (so everything is preallocated at program start, including exceptions).

Given these limitations, implementing newer crypto algorithms is quite a feat.

I don't know very much about this field - what are the major uses of JavaCard other than in SIM cards?

Or are SIM cards where this OpenCrypto would be most useful for makers/researchers?

Yes I'm curious too.

I believe the "Secure Element" in iOS and other smartphone payment systems with the EMV wireless payment standard, all use this as their OS/ecosystem, as it's mandated by the payment industry. So it is widely used.

If you trust your smartphone then you don't necessarily need smartcards. But if you want to run own applications in a trusted environment then JavaCards are really nice. You can also use them as a portable trusted "computer", wallet, ...

In terms of use, there's an additional complexity for using JavaCards. We try to solve that a) making the code easier to port and b) providing access to smartcards via TCP/IP where it makes sense to have them in a rack.

In general, they don't run out of battery and you can print your headshot and name on them.

In terms of "hardware" - all chip debit/credit cards use the same processors (actually they are a complete computers with EEPROM, RAM, co-processors).

https://blog.saush.com/2006/09/08/getting-information-from-a...

Almost all payment chip cards (except in France) uses a worldwide standard called EMV

A quick check with the smart card list maintained by Ludovic Rousseau shows that the card I used (UOB Platinum Visa Card) is likely to an IBM JCOP (JavaCard Open Platform) 30 chip card.

The secure enclave in Intel chips uses a variant of JavaCard.

Citation, please?

The SGX enclave is totally unrelated to JavaCard.

https://libreboot.org/faq.html#intel

"Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc."

Or the remark from Joanna Rutkowska,

https://twitter.com/rootkovska/status/728150127458684931

> @AviKivity ME's "Dynamically Loaded Applications", Java-based :)

Neither of those references says anything about Java Card. It seems much more likely to me that this stuff is plain old Java or one of its normal embedded variants. Also, this stuff is barely used as a secure enclave. It's used as an almost certainly wildly insecure mess of ill-advised proprietary applications.

That being said, there's Intel Platform Trust Technology and Intel Virtual Smart Card. I'm not quite sure what's up with them.

If I recall correctly, the JavaCard standard is what's used in most PGP/GnuPG hardware tokens, e.g. Yubikeys, Nitrokeys, etc., none of which currently support EC crypto due to the limitations cited in the OP. So movement on this front could make for a real advancement in hardware crypto token functionality.

Smart Cards used for military/corporate computer authentication and facility access, some transit systems, some purpose-specific stored value cards (like bike locker rental at BART stations), then of course chip credit/debit cards.

Anywhere you want the user's credential to have some intelligence (sign challenges under specific circumstances, credit and debit a balance without any central database in the loop, etc) but be highly resistant to data tampering/exfiltration (like inflating the balance or copying the key) by its bearer.

I used to implement smart card as Personal Identity Verification for Federal employees. It was required by a regulation driven by the post 9/11 Bush era called HSPD-12 (Homeland Security Presidential Directive - 12).

It was a real boon to the DC area technology consulting business. Timed well with stimulus in the post crash crisis as well. Lots of investment in this technology (reminiscent of the Secret History of Silicon Valley) and surprised it has taken this long to get to finance and other uses.

I think one problem is smart cards were timed with the take off of mobile. They weren't very mobile friendly and seemed kind of redundant, but I prefer them to a fingerprint scanner on the iphone or galaxy.

Excited to see where this goes.

Reply on news.ycombinator.com