I am very pleased to announce that today's blog entry is from a Java Card user and developer. It is about their feedback regarding Java Card 3.1 release in IoT and connectivity spaces. Java Card 3.1 is a major release focusing on new secure hardware and IoT uses cases.
Able Device, headquartered in Raleigh, North Carolina, USA, is a global provider of embedded technology for IoT and connected devices. Their flagship offering; SIMbae, shifts IoT Security, Intelligence, and QoE to the edge by exploiting the under-utilized capabilities the standard SIM/UICC.
At Able Device, we're very bullish on the release of Java Card 3.1 and its enhanced support for IoT implementations. Our company was founded on two core principles; first, the need for a standardized IoT applications environment that is scalable from a logistics and cost perspective, and second, the Subscriber Identity Module (SIM) has not received its deserved recognition as the vehicle to accomplish addressing this need.
Able Device’s team has fairly deep experience with embedded systems and mobile communications. The combination of the standard SIM, SIM Tool Kit (STK), our knowledge of cellular modules, and Java Card 2.2 has provided us with an environment where we could develop techniques to overcome standards and / or development tool gaps to use the SIM as a secure, embedded IoT application processor. The resulting applet is known as SIMbae (SIM based application engine). We've been able to exploit SIMbae's value in three key IoT areas:
Based on what we’ve learned about Java Card 3.1, we will be able to retire some of our unique techniques while also expanding the number and scope of applications and devices that can benefit from SIMbae. This will help simplify and accelerate application development, and hopefully, increase the available pool of Java Card developers and potential ecosystem partners.
In example, JC 3.1 should enable a broader range of embedded cellular modules and modems that can work in an architecture where the SIM is being used as the IoT application processor. Pre JC 3.1, the embedded cellular module needed to support A Class B STK - specifically support for the RUN AT COMMAND proactive command. This is needed as the pre-JC 3.1 method to control a module's I/O is through device-specific AT commands. This results in the need for SIMbae to contain support for every manufacture's module specific I/O AT command in extensive lookup tables. JC 3.1 creates a standardized I/O interface that is accessible directly from a SIM applet which eliminates both the class B STK requirement as well as the modem-specific I/O AT commands.
JC 3.1 nio will also result in reduced code size that will allow it to fit on smaller SIMs. As Mobile Network Operators (MNOs) currently view SIMs as low value commodities, they typically purchase SIMs with the minimal memory and performance to meet the basic needs of authenticating on the network and managing roaming, to save costs. As noted above, the current system requires extensive command lookup tables that relate I/O control to a specific manufacturers' AT command. Using JC 3.1 (e.g. javacardx.framework.event & javacardx.framework.nio) will simplify and eliminate the need for device specific commands. Early estimates indicate a 20% reduction in SIMbae applet size for instances that support a wide range of devices. This will result in SIMbae’s value being able to be delivered in a smaller, less costly SIM.