Skip to content

MscSmartcardService

Marc Obrador edited this page Jul 24, 2015 · 3 revisions

Introduction

Flashing the system is not supported on every device, thus using the SmartCard API is limited to development phone only.
However, access to Secure Elements does not always require flashing the system image. Also, application developers can use the SmartcardService as a quick way to develop their applications as well as end users who just want to use an application with smart card support.
MSC SmartcardService enables (any) Android phone with SD card slot to use SmartCard API without flashing the system or rooting the phone.
The APK inside the archive can be installed on the device like on any other Android application.
Note

  • The MSC SmartcardService will only support the G&D Mobile Security Card
  • The source code of MSC SmartcardService is equal to the SmartCard API provided on SEEK for system integration with the exception of libmsc.so which will not be provided Open Source.

Details

To access the SE on the MSC there are two interfaces available. The Advanced Security SD (ASSD) interface is specified by the SD Association and allows the host to access the SE over a set of standardized SD commands. If the host does not support the additional ASSD commands or it is not possible to include the ASSD (kernel) driver, there is a non-standard possibility to access the SE over special reads and writes to the file system. This requires that the card is accessible through the hosts file system or on a block-level without caching in between (O_DIRECT required). The standardized ASSD interface should be the preferred solution if the host is capable to provide ASSD functionality.

The MSC drivers uses the host operating file system calls to transfer the APDUs between card and host. It appears to the host as if standard read and write commands were performed on a specific file on the SD card.

It is required that no caching mechanism is in between that block direct file access, e.g. when a crypto layer is in between.

Installation

To test the MSC SmartcardService
  • delete older version of MSC SmartcardService.apk and OpenMobileAPISample.apk on the phone
  • ensure that USB debugging is enabled on the phone
    (Settings - Applications - Development - USB debugging)
  • execute adb install MSC_SmartcardService.apk
  • execute adb install OpenMobileAPISample.apk
  • ensure a G&D Mobile Security Card is inserted in the phone
  • on the phone, run the OpenMobileAPISample application and see the log output
  • a GlobalPlatform compliant Access Control applet is optional for the Mobile Security card. If it is installed, the MSC Smartcard Service will grant access to the Mobile Security Card based on the rules that the applet defines. When no applet is install full access for all applications is granted.
![mscsmartcardservice_screenshot](https://cloud.githubusercontent.com/assets/11645011/6866387/f2614e12-d477-11e4-94ef-ffe40f4ff61c.png)

Development

The MSC SmartcardService provides the same interface as the SmartCard API so application developers can write and test their applications with the installable version and have no migration issues later on. Note that the package names are different for the MSC SmartcardService (com.mobilesecuritycard.*) and the SmartCard API (org.simalliance.*).
Use the provided com.mobilesecuritycard.openmobileapi.jar and the sample project to develop Android applications.

Access Control

As the GlobalPlatform Secure Element Access Control is also included in the MSC SmartcardService, a corresponding Access Control application can optionally be installed in the MSC and personalized with the proper rules.
For development purposes, the dummy-ARA applet can be used that grants access to the MSC for any application.
In case no Access Control application can be selected on the MSC, Access control will be disabled.

Write permission to the MSC

Since AOSP 3.x application will not have write access to MicroSD cards out of the box which will also hinder the MSC SmartcardService to work. Most commercial device have implemented a work around for this issue but it is up to the OEM to implement such.
Background: the new WRITE_MEDIA_STORAGE permission for the MEDIA_RW gid is protected with the signatureOrSystem level hindering all user application to retrieve such. See frameworks/base/core/res/AndroidManifest.xml, frameworks/base/data/etc/platform.xml and system/vold/Volume.cpp for more details.
Clone this wiki locally