JCOPsim: A fully featured GSM S(W)IM
The sections below provide an overview on the GSM enabled version of JCOP:
Introduction
JCOPsim is a derivation of the well-established JCOP operating system with additional support
for GSM SIM and WAP WIM functionality. The activation of the SIM and WIM features are optional
so that JCOPsim can be considerd a real multi-market Java Card, which can be used for all
smart-card application domains from financial to telecommunication applications. The system
implements the complete applicable range of open standards from various domains including Java
Card, Open Platform, WAP and ETSI specifications to ensure flexibility and interoperatbility.
Features
The first version of JCOPsim, which is available since September 2002, is called
JCOP21sim and is available on the Philips P8WE5033 and P8WE5017 platforms.
Memory Configuration (P8WE5033)
JCOP21sim offers:
- 96 KBytes ROM of which
- 40 KBytes are available for custom applications (in ROM)
- 30 KBytes persistent Java heap (EEPROM) for application code and data
- 512 bytes transaction buffer
- 615 bytes transient Java heap (RAM)
- 261 bytes APDU buffer
- 200 bytes Java stack
Communication Protocols
JCOP21sim supports ISO7816 T=0 (direct/indirect convention) with speeds between 9600 bit/sec
and 115200 bit/sec.
Java Card
Java Card version 2.1.1; Cryptographic algorithms available:
- Triple-DES (hardware)
- RSA (512-2048 bit) including
- SHA-1 and MD5
- AES
- COMP128-1/2
Open Platform
Open Platform version 2.0.1', including support for Global PIN, multiple Security Domains and
Mandated DAP verification.
WAP
The JCOP21sim system provides a built-in WAP 2.0 WIM application (WAP-260-WIM-20010712-a),
which can be optionally installed when the SIM functionality is activated. This allows to
configure JCOP21sim as SIM-only or as SWIM card. The WIM application supports application-level
signatures as well as WTLS security based on 1024 bit RSA operations including the WTLS SHA-1
pseudo-random function.
ETSI
JCOP21sim implements the GSM SIM functionality as defined in the GSM 11.11 (V 8.0.3), GSM 11.14
(V 8.5.0) and GSM 03.40 (V 7.4.0) specifications. Also it provides the SIM API for Java Card
(GSM 03.19 V 8.3.0), which allows the installation of SIM Toolkit applications written in Java.
Also, the security mechanisms defined in GSM 03.48 (V 8.8.0) are implemented allowing
over-the-air loading of Java applications as well as remote file system management.
S(W)IM Personalization
To turn the JCOP system into a SIM or SWIM card, appropriate personalization data must be
provided via an XML file. The JCOP Tools include a sample XML file defining a generic layout
for a SWIM setup. More details about the tags and data items allowed within the XML file are
provided below. The JCOP Tools properties allow to activate SIM personalization automatically
every time the simulation is restarted. Furthermore, the JCShell window offers means to
initiate the personalization explicitely, to remove the SIM functionality from the card, or to
view personalization information stored within an XML file.
<swim>
This is the root tag required for a JCOP personalization file. It includes a
<sim> tag and optionally also a <wim> tag if the WIM
functionality shall be activated.
<sim>
This tag is mandatory and includes all information concerning the JCOP SIM functionality. The
following tags must be present within the <sim> tag:
<chv1>, <chv1disabled>, <uchv1>,
<chv2>, <uchv2>, <admin>,
<ki>, <COMP128-Limit>, <COMP128-X>,
<clockstop>, <remotemanagementtar>,
<mf>.
<chv1>
This tag holds the CHV1 value to be personalized. CHV1 must be a 4-8 characters numeric value.
<chv1disabled>
This tag defines whether CHV1 shall be enabled or disabled upon personalization. The value must
be true or false.
<uchv1>
This tag holds the UCHV1 value to be personalized. UCHV1 must be a 4-8 characters numeric value.
<chv2>
This tag holds the CHV2 value to be personalized. CHV2 must be a 4-8 characters numeric value.
<uchv2>
This tag holds the UCHV2 value to be personalized. UCHV2 must be a 4-8 characters numeric value.
<admin>
This tag defines the PIN code for the administrator file access right. The value must be a 4-8
characters numeric value.
<ki>
This tag defines the cryptographic key used by the A3A8 GSM algorithm (e.g. COMP128).
<COMP128-Limit>
This tag defines the limit for the number of times the A3A8 (e.g. COMP128) algorithm can be
executed. The value represents the max. number of execution divided by 256. For instance, the
value 300 sets the limit to 300 * 356 = 76800. A value of -1
indicates that no limit is to be set.
<COMP128-X>
This tag defines the version of the A3A8 algorithm (e.g. COMP128) to be used. Currently the
version number can be 1 for COMP128-1 or 2 for COMP128-2.
<clockstop>
This tag defines whether the SIM shall indicate support for clock stop to the mobile phone or
not. Its value might be yes or no. Usually the value is set to
yes.
<remotemanagementtar>
This tag defines the TAR (Toolkit Application Reference) to be used for remote (OTA) file
management commands as defined in GSM 03.48. The TAR must be a six character HEX string
(defining 3 bytes).
<mf>
This is the root tag of the SIM file system. It is mandatory and can include an arbitrary number
of <df> and <ef> tags.
<df>
This tag defines a DF (Dedicated File) within the SIM file system. It must include a
<fid> tag defining the FID (File Identifier) of the DF. Additionally, it can
include an arbitrary number of <df> and <ef> tags.
<fid>
This tag defines a FID (File Identifier). Its value must be a 4 character HEX string describing
a 2 byte FID. Please note that FIDs must not be negative! The rules for FIDs as defined in GSM
11.11 shall be honored.
<ef>
This tag describes an EF (Elementary File) within the SIM file system. It must include the
following mandatory tags: <fid>, <structure>,
<readseek>, <update>, <increase>,
<rehabilitate>, <invalidate>,
<statusb1>, <statusb2>.
Furthermore, linear and cyclic EFs must include the tag <recordlen> and
<records>, transparent EFs must include the <size> tag
instead. Optionally, transparent files can include the <data> tag defining
the initial value of the file data as HEX string. By default all files are initialized with
xFF. In case of linear or cyclic EFs zero or more <record>
tags can be included defining the record data of record 1 to N.
<structure>
This tag defines the structure of an EF. Its value can be transparent,
linear or cyclic.
<recordlen>
This tag defines the record length of a linear or cyclic EF. The record length must be greater
than zero and less than 256.
<records>
This tag defines the number of records within a linear or cyclic EF. The number of records must
be greater than zero and less than 256.
<size>
This tag defines the size of a transparent EF. The size must be greater than zero and less than
32768.
<readseek>
This tag defines the file access condition for the READ and SEEK operation. Valid values are:
always, chv1, chv2, adm, or
never.
<update>
This tag defines the file access condition for the UPDATE operation. Valid values are:
always, chv1, chv2, adm, or
never.
<increase>
This tag defines the file access condition for the INCREASE operation. Valid values are:
always, chv1, chv2, adm,
not allowed, or never.
The access condition not allowed is only valid for cyclic files.
<rehabilitate>
This tag defines the file access condition for the REHABILITATE operation. Valid values are:
always, chv1, chv2, adm, or
never.
<invalidate>
This tag defines the file access condition for the INVALIDATE operation. Valid values are:
always, chv1, chv2, adm, or
never.
<statusb1>
This tag defines whether the file status bit 1 indicates that the EF is invalidated or not
invalidated. Its value can be invalidated or not invalidated.
<statusb3>
This tag defines whether the file status bit 3 indicates that the EF is readable when
invalidated or not readable when invalidated. Its value can be readable or
not readable.
<data>
This optional tag defines the initial data of a transparent EF. The value must be a HEX string.
<record>
This optional tag defines the initial data of a record within a linear or cyclic EF. The value
must be a HEX string defining record data from the beginning of the record. If multiple
<record> tags are present the first tag defines the initial data for record
number one, the second for record number two, etc.
<wim>
This optional tag defines the WIM initialization data. If it is present JCOP is initialized to
act as SWIM and the following tags must also be present within the <wim> tag:
<ping>, <pinnr>, <puk>,
<peers>, <sessions>, <mastersecrets>,
<cdfusefulcerts>, <usefulcerts>,
<authcert>, <nonrepudiationcert>. Optionally, one or more
<trustedcacert> tags can be included.
<ping>
This tag holds the WIM PIN-G (General PIN) value to be personalized. PIN-G must be a 4-8
characters numeric value.
<pinnr>
This tag holds the WIM PIN-NR (Non-Repudiation PIN) value to be personalized. PIN-NR must be a
4-8 characters numeric value.
<puk>
This tag holds the WIM PUK (Unblock PIN) value to be personalized. PUK must be a 4-8 characters
numeric value. The PUK can be used to unblock both PINs.
<peers>
This tag defines the size of the EF(Peers) within the WIM file system. The file size must not
be negative.
<sessions>
This tag defines the size of the EF(Sessions) within the WIM file system. The file size must
not be negative.
<mastersecrets>
This tag defines the size of the EF(Master Secrets) within the WIM file system. The file size
must not be negative.
<cdfusefulcerts>
This tag defines the size of the EF(CDF Useful Certificates) within the WIM file system. The
file size must not be negative.
<usefulcerts>
This tag defines the size of the EF(Useful Certificates) within the WIM file system. The file
size must not be negative.
<authcert>
This tag defines the authentication certificate of the WIM user. If the certificate is provided
in X.509 format stored within a PKCS#12 file the tags <pkcs12token> and
<tokenpwd> must be included. If the certificate is provided in WTLS format
the tags <cdata> and <keymat> must be present.
Alternatively, if the certificate is not available yet (e.g. if the key is to be generated
on-card) the two tags <certfile> and <keyfile> must be
present.
<nonrepudiationcert>
This tag defines the non-repudiation certificate of the WIM user. If the certificate is
provided in X.509 format stored within a PKCS#12 file, the tags <pkcs12token>
and <tokenpwd> must be included. If the certificate is provided in WTLS
format, the tags <cdata> and <keymat> must be present.
Alternatively, if the certificate is not available yet (e.g. if the key is to be generated
on-card) the two tags <certfile> and <keyfile> must be
present.
<pkcs12token>
This tag defines a PKCS#12 file holding the certificate and private key to be loaded into the
WIM. The path variable of the JCShell is evaluated to find the file specified.
<tokenpwd>
This tag defines the password for the given PKCS#12 token.
<cdata>
This tag defines WTLS certificate data. Its value can be either a WTLS encoded certificate
provided as HEX string or the name (or full path) of a binary file holding the WTLS certificate
to be loaded into the WIM. The path variable of the JCShell is evaluated to find the file
specified.
<keydata>
This tag defines an RSA private key to be loaded into the WIM. Its value can either be a HEX
string holding the key encoded in PKCS#8 format (or JCOP internal format) or the name (or full
path) of a binary file holding the PKCS#8 encoded key material. The path variable of the
JCShell is evaluated to find the file specified.
<certfile>
This tag defines the size of a user certificate file. The file size must not be negative.
<keyfile>
This tag defines the size of a user key file. The file size must not be negative.
<trustedcacert>
This optional tag defines a trusted CA certificate to be loaded into the WIM and can be present
multiple times. The two tags <clabel> and <cdata> must be
present within the tag.
<clabel>
This tag defines the label to be associated with a trusted CA certificate.
Loading Toolkit Applets
Toolkit Applets can be loaded either via the Card Manager using Global Platform commands or
over-the-air as specified in GSM 03.48. The latter means loading via SMS. The preferred method
can be defined in the applet properties dialog of the JCOP Tools.
Installing Toolkit Applets
When a Toolkit Applet is installed, the system specific install parameters (tag 0xEF) must
include additional GSM applet specific parameters (tag 0xCA). If the JCOP Tools are used to
install a Toolkit Applet, the parameters can be conveniently defined in the applet properties
dialog for each applet. The meaning of the parameters are as follows:
Access Domain:
This parameter defines the access rights of the Toolkit Applet to the GSM file system. It can
either be 0x00 (full access to the GSM file system), 0xFF (no access to the GSM file system),
or the three bytes 0x01XXXX defining the APDU access mechanism. The value XXXX can be 0x0000
(no access), 0x0001 (ALWAYS), 0x0002 (CHV1), 0x0004 (CHV2), or 0x0010 (ADM). Combinations of
these bits are allowed.
Priority Level:
This parameter defines the priority level of the Tollit Applet. The priority specifies the
order of activation of an applet compared to the other applet registered to the same event. If
two or more applets are registered to the same event and have the same priority level, the
applets are activated according to their installation date (i.e. the most recent applet is
activated first). The value of this parameter must be in the range of 0x01 (highest priority
level) to 0xFF (lowest priority level).
Max Num of Timers:
Defines the maximum number of timers allowed for the Toolkit-Applet instance. Valid values are
in the range of 0x00 to 0x08.
Max Menu Entry Length:
Defines the maximum text length for a menu entry.
Max Menu Entry Number:
Defines the maximum number of menu entries allowed for this Toolkit-Applet instance.
Menu Entry Pos./Id.:
Defines position and identifier for each menu entry each coded in one byte so that two bytes
should be present per menu entry. For example, the value 0x01010203 would indicate that the
first menu entry has identifier 0x01 associated and the second identifier 0x03. The position
value 0x00 means last position and the identifier value 0x00 means don't care.
Important Notes
Transient Memory
Tookit applets are not allowed to allocate CLEAR_ON_DESELECT transient memory. Consequently, it
is not allowed to allocate objects such as javacardx.crypto.Cipher with the
externalAccess parameter set to false within a Toolkit Applet, since
this would result in CLEAR_ON_DESELECT memory allocation internally.
S(W)IM Support vs. Toolkit Applets
It is not possible to install a Toolkit Applet as long as the S(W)IM functionality of JCOP21sim
is not activated. Vice versa, it is not possible to deactivate the S(W)IM functionality as long
as one or more Toolkit-Applet instances are present on the card. Toolkit Applet install
commands and S(W)IM initialize or re-initialize commands might fail for these reasons.
Furthermore, it is obviously not possible to load or delete a package onto the card via
GSM 03.48 (SMS) loading as long as the S(W)IM functionality is not activated.
Cryptographic Algorithms
Due to legal restrictions, the COMP128-1/2 cryptographic algorithms are not included in the
JCOP Tools distribution. Therefore the card simulation as well as engineering samples of real
cards shipped with the Toolset return the challenge input to the COMP128 algorithm unchangend
as result.
|