Muscle applet

Table of Contents

  1. Source code
  2. Applet initialization (API version 1.3)
  3. Overview of MuscleApplet
    1. Applet components
    2. Memory manager
    3. Object manager
    4. Internal objects
    5. APDU interface
    6. Possible improvements
    7. Steps taken
    8. Known bugs

Source code

OpenSC supports the Muscle applet, available from Debian SVN: 

svn co svn://svn.debian.org/muscleplugins/trunk/MCardApplet

An updated version, targeting recent JavaCard 2.2.2 cards with extended APDUs is available from github:  http://github.com/martinpaljak/MuscleApplet

A "relatively recent" build of the 2.2.2 version is attached to this page, it can be loaded to compatible cards as instructed on the JavaCard page.

Applet initialization (API version 1.3)

Currently the applet needs to be initialized (initial PINs and ACL-s set) manually, with opensc-tool (see #219) 

opensc-tool -s 00:A4:04:00:06:A0:00:00:00:01:01 \
-s B0:2A:00:00:38:08:4D:75:73:63:6C:65:30:30:04:01:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:05:02:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:00:00:17:70:00:02:01

The two send APDU commands do the following:

The following is personal observations of MartinP.

Overview of MuscleApplet

OpenSC has historically grown into a library that incorporates drivers for different cards, both documented and standardized as well as proprietary/NDA/reverse-engineered cards. Usually the cards (or specifications and APDU manuals) are considered static, as it is usually not possible to change the COS-s (Card Operating System-s). One notable exception here is the JavaCard, which is an open platform where anyone can basically invent their own APDU protocol and implement it in a secure smart card. There are different cards with different capabilities and in fact, many current smart cards specifications (like PIV or IAS-ECC) are implemented as JavaCard applets, but the applets don't come with the source code, which makes no real difference.

MuscleApplet, the open source JavaCard applet, dates back several years (see  slides from 2003) and as a result is pretty old and outdated. From the MUSCLE movement only pcsc-lite (and the accompanying CCID driver) has proven to be viable while the libmuscle/muscleframewor/plugins can be considered as stagnated and outdated software. The MuscleApplet has seen some sporadic updates during the last few yers (Karsten Ohme, Joao Poupino, others as well .. ?) but the evolution seems to continue separately from the rest of "the stack". For the applet to be useful, the host side software (tools to create objects and tools and libraries to use them afterwards) need to match the applet on the card. OpenSC also gained support for a version of MuscleApplet (FIXME: insert link to changeset).

The JavaCard world has also evolved a lot, with the JC 2.1.1 specification from 2000 (which the applet still primarily targets and can be used with) to JC 2.2.2 in 2006 with important and modern additions like extended APDU-s, which is supported by several recent cards. Memory sizes and the capabilities of the Java runtimes on cards have improved as well, with cards commonly having 72K or more of EEPROM and often real garbage collection. Some parts of the MuscleApplet have seen updates (like rudimentary extended APDU support) whereas some parts of it have not. There is a fork of MuscleApplet (CoolkeyApplet?) which builds upon MuscleApplet and adds several interesting features like secure messaging, but is also outdated and the APDU interface is different from MuscleApplet. Most importantly, the applet that has been circulating can be compiled with different options whereas there is no testing for features on the host side.

Applet components

MuscleApplet could be layered as follows:

Memory manager

Memory manager has probably been created because JavaCard-s did not use to have garbage collection capabilities. It allocates a huge block of memory for storing the objects created by object manager.

Object manager

Object manager deals with creating, locating, reading, writing, iterating and controlling access to the objects that are exposed to the outside world. Internally it uses the memory manager for allocating the EEPROM for objects. Objects consist of identifiers, ACL-s and content. Objects are identified with two short-s. Some identifiers are reserved for special purposes (like I/O objects (0xFFFF:FFFE and 0xFFFF:0xFFFF) or semantics for representing DF-s in OpenSC ISO7816 filesystem emulation (like 0x3F00:0x3F00 for the MF)).

Internal objects

In addition to data objects, MuscleApplet manages the following internal objects:

MuscleApplet has ACL-s for reading, writing and using (crypto objects) and ACL-s are associated with keys and data objects. Internally each ACL is a short, which is a bit map of required identities (for example, to use a specific key you need to specify two PIN codes). The current mapping of Key objects and KeyPair? objects is somewhat messy and broken (both arrays have the same size but there are 2x more Key objects than there are KeyPair? objects in real life). The ACL system needs careful review and possibly upgrading, as a well functioning ACLS system is the core of the applet functionality.

APDU interface

Balancing the approach of simplicity (as in a simple, self-defined card interface definition) vs compatibility (the related ISO7816-* standards are pretty complex and arguably also historic) is not easy. Nor is it easy to please a variety of cards (old JavaCard 2.0.1 vs newer 2.2.2 cards, features like extended APDU-s, garbage collection etc). Upgrading the applet requires upgrading the OpenSC driver and without a new host driver, older cards become unusable or at least unstable. MuscleApplet has a GetStatus? APDU which can be used to fetch the applet version from the card, so that a driver version could be frozen and another one, "Muscle 2" be created alongside the old implementation.

Possible improvements

The following could be made to make the applet more compatible with PKCS#15 and ISO world:

In addition to changing the APDU interface for a "generic cryptographic token" the capabilities of programmable JavaCard-s can do more, like:

Steps taken

Known bugs

Attachments

Back to Index