Black Hat 2017 USA – OpenCrypto: Unchaining the JavaCard Ecosystem

print
We have been working with University College London (UCL) for a while and one of the results is an easy to use implementation of cryptographic functions for JavaCards. We will be briefing on this at Black Hat 2017 USA.

We are still working on the implementation so we can launch a polished product. If you’re interested in using smart cards to harden your applications or servers get in touch with me at (dan @ enigmabridge.com). We also work on integration into RedHat and are always on the lookout for business cases.

Here is an abstract of our Black Hat 2017 briefing to get you interested.

JavaCards as TCP devices by Enigma Bridge Ltd

JavaCard is a subset of Java that allows applets to run securely on smartcards and has been deployed to over 15 billion devices. Its main advantage compared to competing technologies is “applet interoperability.” Unfortunately, over the years, several glitches in the ecosystem became apparent, and hindered its evolution. For instance, in practice, most applets are tailored for a specific card model, while there is at least a three-year gap between the time a JavaCard specification is released, and the time features appear in products.

We argue that these inconsistencies between the JavaCard vision and practice are due to the control card vendors have over the ecosystem. Specifically, since JavaCard relies on vendors to implement the specification, this enables them to impose barriers to protect their market share. For instance, the cryptographic coprocessor is accessible only for high-level operations (e.g., ECDSA signing method), while low-level methods (e.g., ECPoint Addition) are available only in vendor-specific, proprietary APIs. Moreover, vendors often release new features of the specification in their own APIs.

In this session, we present the OpenCrypto library that enables programmers to utilize all the capabilities of JavaCards (e.g., the cryptographic coprocessor) without being bound to a specific vendor. The library realizes classes for:

  1. mutable Integers,
  2. Elliptic Curve Points and
  3. EC Curves.

Currently, these classes are either not supported at all (even though they may be listed in the JC specification, e.g., Integers), or are available only through vendor-specific APIs (e.g., ECPoint). To overcome the vendor barriers, we use a combination of low-level byte manipulation tricks and mathematical properties to reconstruct low-level arithmetic operations (e.g., integer multiplication, ECPoint Addition) from high-level crypto methods (e.g., RSA encryption). Our final library supports all the methods found in the proprietary APIs, performs almost as fast, and eliminates vendor-specific dependencies from the ecosystem.

 

3 thoughts on “Black Hat 2017 USA – OpenCrypto: Unchaining the JavaCard Ecosystem”

  1. This sounds a lot like my Masters thesis I wrote back in 2011. One of the results of my Thesis is a side-channel attack against an implementation using the coprocessors RSA implementation for EC operations. It’s trivial to attack these schemes as it is very easy to deduce the key with a timing attack (observing the coprocessors power consumption). I also implemented a version that is resistant against side-channel attacks using a special type of curves.

    I’m really interested to hear about the details of your implementation. Is there a publication?

    1. Not yet, we plan to submit to CARDIS in a couple of months’ time. If you subscribe to this blog, I’m sure I will share updates as soon as they are published.

      Indeed, pure software implementations are pretty good for teaching students. We did some research in this area but were under an NDA – here’s a link to one of our related papers – https://www.researchgate.net/profile/Petr_Svenda/publication/228963597_Improving_resiliency_of_javacard_code_against_power_analysis/links/5627d4fe08aef25a243be6bf.pdf

Leave a Reply

Your email address will not be published. Required fields are marked *