Live data from Hacker News

OpenCrypto: Unchaining the JavaCard Ecosystem

dan.enigmabridge.com

11–13 of 13 posts

Re: OpenCrypto: Unchaining the JavaCard Ecosystem

#11
post #2

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?

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) b…

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.

Re: OpenCrypto: Unchaining the JavaCard Ecosystem

#12
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.

Re: OpenCrypto: Unchaining the JavaCard Ecosystem

#13
post #10
post #8

Earlier quoted context omitted.

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.

Post reply on HN