Mobile native Wearable native

SmartCard

Tizen enables you to use smart card functionalities, such as accessing a secure element (SE). Before using the SmartCard API, make sure you have a secure element on the device. The smart card service allow you to open a session on an SE, open a channel to the applet in the SE, send a command to the channel, and finally receive a response to the command.

The main components of the SmartCard API include:

  • SE service

    The SE Service API (in mobile and wearable applications) allows you to initialize and deinitialize the smart card features, and get the available readers. The SE service functions as a connector to the SE framework system.

  • Reader

    The Reader API (in mobile and wearable applications) allows you to access the SE connected with the selected reader. You can get the reader name and open and close sessions.

  • Session

    A session is an open connection between an application on the device and a SE. The Session API (in mobile and wearable applications) allows you to open and close basic and logical channels, and get ATR (answer to reset).

  • Channel

    A channel is an open connection between an application on the device and an applet on the SE. The Channel API (in mobile and wearable applications) allows you to close channels and transmit application protocol data units (APDU).

The following figure illustrates the smart card service architecture in Tizen. The smart card service sends and receives data through the terminal of each SE.

Figure: Smart card service architecture

Smart card service architecture

The SmartCard API is a reference implementation of the SIMalliance Open Mobile 3.0 API specification that enables Tizen applications to communicate with secure elements. For more information, see the SimAlliance. The Tizen implementation differs from the original as follows:

  • Only the transport layer is provided. There is no service layer support in Tizen.
  • The "get version" function does not exist. In Tizen, version management is not performed through a function.
  • Allocation style differs dramatically. The Open Mobile API can facilitate the memory management by calling the API twice (for an example, see section 6.3.1, Usage pattern, in the SIMalliance Open Mobile 3.0 API specification). However, Tizen SmartCard API does not follow this allocation style.
  • For the SE Service object management, Tizen provides functions for initialization and deinitialization.
Go to top