In this blog entry we will be covering the Java Card I/O framework, and how implementers can use it to extend the platform and enable new use-cases for secure elements in IoT devices.
Java Card has initially been designed to run smart cards applications. These applications are using a specific command-response communication model and an encoding format called Application Protocol Data Unit (APDU) - see ISO/IEC 7816.
The increasing adoption of Java Card in secure elements, with very different form factors from the original smart card, has led to the use of various I/O interfaces and associated protocols to transport these APDU frames. In addition to typical smart-card I/O interfaces, multiple RF contactless protocols, NFC, USB and more recently SPI or I2C have been used. Support for these new physical interfaces has so far been enabled under the hood, by always keeping the APDU-based application protocol layer on top, ensuring Java Card applications remain unchanged.
New hardware capabilities have recently emerged, including the tighter integration of secure elements into host devices - either as an embedded secure element or integrated into the SoC. Those have made new use cases possible such as establishing a direct channel between the secure element and device peripherals. However supporting efficiently these scenarios often requires the use of a specialised protocol application layer.
Java Card 3.1 introduced a new I/O framework that can be extended by platform implementers to support a variety of physical layers and application protocols, allowing the logical access to device peripherals by secure element applications.
Examples of use of this I/O framework
There are several existing and well document use cases that can benefit from a generic and extensible I/O framework usable from Java Card application.
Accessing biometric sensor to implement user authentication
A first example is the use of a biometric sensor on a payment card where the fingerprint is used in replacement of the user PIN code. For contactless payment, this significantly improves the user experience as well as the security of the transaction.
Some solutions are already being deployed, but most have a tight coupling between the hardware and software layers, relying on proprietary mechanisms, or even requiring changes on host device to be able to securely transfer data from the biometric sensor to the secure processor.
The new Java Card I/O framework can be used to create an API for applications to directly read and verify fingerprint data from the biometric sensor. No need to go through the host device to transfer data from the biometric sensor to the main processor of the secure element, or no need to tunnel data into APDU commands to overcome associated constraints (bandwidth, timing, ordering, priorities, execution context…).
Accessing peripherals to implement security at the edge
In IoT solutions, the enforcement of security policies can benefit from access to peripherals and collection of their data for decision making at the edge. In devices that include secure hardware, this implies attaching multiple peripherals to the secure element and providing a mean for the application running in the secure element to use the input from these peripherals.
For example, the secure element application in a smart meter could use localization or motion sensor to detect abnormal situations and react accordingly. The application could also be used to securely perform the configuration of the attached peripherals and ensure integrity of the control plane.
In all these cases, modifying the sensors and peripherals to use smart-card specific interfaces and protocols is either not possible or not efficient. Integrating the secure element in these architectures requires the support for more generic I/O interfaces, and the availability of corresponding API for the applications to directly use the sensor specialised protocol.
Supporting new communication stack or data exchange protocols
There are also cases where the main communication stack and application protocol need to be adapted to simplify the integration into existing infrastructures without having to rely on smart card specific protocols.
This could be the case when trying to secure the device communication stack and delegate part of the security layer to a dedicated secure hardware (e.g. delegating TLS operations to a Java Card service running in secure hardware).
In some other cases it could allow a much more efficient way to use specialised data transfer protocols (e.g. CBOR, UBJSON, MessagePack…) to directly exchange, parse and process messages without the need for the application to perform costly conversion operations.
The extensible I/O framework
Java Card specification provides a minimal API and abstractions to be used by platform implementers or other vertical standardisation bodies to extend the Java Card platform with a variety of physical layers and application protocols.
This I/O framework is made of two new Java Card packages :
javacardx.framework.event
This package is the base framework that must be used by implementers to extend the platform with specialised API defining new I/O protocols, interfaces with peripherals or handling any source of event.
The central abstractions of the event framework to use to extend the platform are the following:
- Event sources that represent any external peripheral or I/O interface with the host or another device. This could also include an internal source of event (hardware or software).
These source of events could be for example: a GPIO pin or port, an UART interface, a memory-mapped I/O, an I2C bus, a watchdog timer… Once an event source is defined and the corresponding class made available by platform implementer, the application can use it to register its Event Listener to receive events data from this source. - Event listeners are the interfaces to be implemented by the application code to receive events. The specification provides the default base interface that has to be extended by implementers to offer specialized listener interfaces corresponding to the type of I/O extensions supported by the platform. This could be for example: listeners for GPIO (PinListener and PortListener), listeners for UART interface (UARTEventListener), listeners for memory-mapped I/O (MMIOEventListener) …
- Event Registry is used by applications to register its listeners for a source of events.
javacardx.framework.nio
This package contains classes to manipulate data. It defines buffers that are container providing an encapsulation of data and offering efficient methods to parse and extract structured information from raw data. These buffers can encapsulate data stored into arrays in the data heap, but can also be used to access memory out of the heap and map external memory (e.g. a peripheral).
Extending the Java Card horizon with New I/O
Java Card is being used in many different hardware platforms, in architectures that significantly differ from the secure microcontroller for smart-cards it was originally designed for. Java Card products now need to use I/O interfaces and protocols that are not smart-card specific and correspond to the diversity found in Internet of Things devices.
The Java Card I/O framework is a key step to facilitate the introduction of interoperable Java services on heterogeneous secure hardware. It is offers a toolbox that can be used towards the definition of standardised API, addressing I/O requirements for each specific markets and providing consistency across different hardware profiles.
Moving forward, the extensible I/O framework will be the basis for implementers to extend the platform with various I/O interfaces and protocols:
- Adding low level protocols to access peripherals attached to the secure element, for example adding a subset of the device I/O API (GPIO interface, UART interface, …)
- Creating APIs to directly control a set of specialized peripherals (motion sensor, temperature sensor, …)
- Supporting alternate communication stack or data exchange protocols (TLS, CBOR, UBJSON, …)
About Java Card:
Nicolas Ponsini
Consulting Product Manager