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.

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.