Skip to content

Home

Jump to bottom
Martin Paljak edited this page Jun 26, 2019 · 11 revisions

APDU for Java

apdu4j helps to work with smart cards in a Java coding environment. It intends to generalize some archaic concepts and provide re-usable platform-independent components for real life apps.

  • apdu4j-core
    • Generic interfaces for a BIBO (think: reader) and utilities constructing and parsing APDU-s (think: byte arrays). This should work anywhere where Java runs - desktop, Android, server environment. No external dependencies.
  • apdu4j-pcsc
    • Makes apdu4j-core and apdu4j-plugins work on javax.smartcardio and underlying PC/SC access to smart card readers (terminals). Utility functions that should make reader selection, logging, PC/SC pinpads etc more convenient to use. Only makes sense in a desktop or embedded (think: raspberry pi) environment.
  • apdu4j-remote (to be released)
    • JSON + HTTP/WS based remoting utilities. Unlike "yes we can bridge a remote reader"-style project, it is a "this is how to make cloud-based smart card services"-style framework (sometimes called a TSM)
  • apdu4j-plugins (to be released)
    • bunch of plugins and services for apdu4j
  • apdu4j-tool
    • CLI interface to the above.
  • apdu4j-android (N/A currently)
    • Android utilities to make apdu4j-core and apdu4j-remote work with Android NFC interface

BIBO

Bytes In, Bytes Out

Interface that allows to send a bag of bytes and receive a bag of bytes (or an exception) as a reply. Command-response.

byte[] transceive(byte[] bytes) throws IOException;

Implementations could be a UNIX pipe, a UDP message, JSON over HTTP, PC/SC API or anything similar.

APDUBIBO

APDU is an ancient convention of formatting bags of bytes. Keywords like CLA, INS, P1, P2, LC, LE, SW etc. CommandAPDU and ResponseAPDU provide convenience methods for constructing and parsing those byte arrays. Some ancient formatting, but still a bag of bytes.

ResponseAPDU transmit(CommandAPDU apdu) throws IOException;

is equivalent to

new ResponseAPDU(transceive(new CommandAPDU(...).toBytes()) throws IOException;

Sessions and channels

A session is a series of APDU transmits. A technical session can be considered broken if IOException is thrown. A logical session is responsibility of the application (interpretation of APDU-s)

A channel is a logical multiplexing on top of the physical BIBO (like a logical session is based on APDU-s). SE access is still serialized to a single command-response channel.

BIBO providers

  • PC/SC (provided by apdu4j with the help of jnasmartcardio)
  • Android NFC
  • OpenMobileAPI
  • RemoteEMV (provided by apdu4j)
  • Raspi i2c
  • ...

PC/SC, Terminals and javax.smartcardio

PC/SC is the ages-old desktop oriented C API to enumerate smart card readers and talk to cards in those readers. Not required to have a BIBO to a secure element (can use direct USB CCID like GnuPG or some other USB framing than CCID). But it is the default protocol stacking layer present in desktop environments. javax.smartcardio is the Java-adaption of the PC/SC API. jnasmartcardio is the JNA re-implementation of the PC/SC API in Java, in javax.smartcardio-compatible way.

Modern environments like Android NFC have no notion of PC/SC (but the "reader" concept carries on to API-s like OpenMobileAPI) https://developer.android.com/reference/android/se/omapi/package-summary.html

apdu4j-core will be renamed to apdu4j. Current apdu4j will be renamed to apdu4j-pcsc. apdu4j-android will be created.

Other software

  • OCF - OpenCard Framework
  • scuba
Clone this wiki locally