Information Technology Reference
In-Depth Information
of UICC memory is internationally certified and
storing the sensitive data there can reduce the
number of external I/O processing between the
UICC and the terminal. The details of the secure
file system and the APIs for UICC applications
to access the UICC memory are beyond the scope
of this chapter.
SCP for authentication and establishment of the
secure session between UICC and off-card entity.
The PAL is implemented to utilize the most
of APIs defined in JCP 3.0. Since JCP 3.0 sup-
ports String class, which is not supported in the
previous JCP, the PAL only needs to invoke it. To
support the parsing function, TLV package should
be provided by JCP. Since JCP 3.0 doesn't sup-
port RC2, which is required for certificate-related
operations in Korea, the PAL should implement it.
For the PKI Engine, the performance of
KeyPair class, which takes the role of public
key pair generation, is the most important factor
since its functionality is mandatory to issue the
certificate. In the case of 1024-bit RSA key, about
2 seconds are required to generate the key pair.
However, in the case of 2048-bit, the required
seconds increase drastically to about 15 seconds.
In the near future, for strong security, RSA key
pair more than 1024-bit may be necessary. For
this, hardware and software technologies for RSA
key pair generation should be enhanced.
The high-speed interface such as IC-USB
between UICC and terminal might be necessary
for the USF depending on the applications. In the
case of processing the DRM-protected multimedia
files, the high-speed interface should be supported.
However, for the certificate-related operations,
the fundamental ISO interface may be enough
for processing.
For the interoperability among different FMC
service infrastructures, the DRM, PKI and SC
Engines of the USF follow the global and de-facto
standards. In the case of Anti-Virus Engine, all
kinds of malicious codes found in the heteroge-
neous terminals have been considered to be targets
to be scanned and cured since the USF-powered
UICC can be inserted into any mobile terminal
and communicate with any kind of network in-
frastructures.
The layered and object-oriented architectures
of the USF can make it more powerful and flex-
ible. According to the use cases of the USF and
the available memory capacity of the UICC, the
Implementation
We discuss the implementation of the USF. The
USF was initially implemented as the library
package of JCP 2.2.2 using the Java Card Devel-
opment Kit 2.2.2 and tested on the PC emulation
environment using JCWDE. Currently, the USF is
installed on top of the JCP 3.0 and GlobalPlatform
2.2.1. Since not all required cryptographic APIs
are implemented in currently available UICCs, we
requested the vendors to support them.
The basic process to implement the library
package is to implement the source codes consist-
ing of several Java files and one build.xml file,
build them using Apache Ant, and install it into
the UICC.
We utilized the Eclipse IDE, SUN JDK 1.6.0,
Java Card 3.0 libraries and the UICC vendor-
specific tools for loading and installing USF into
the UICC. Java Card 3.0 libraries are the kind of
JAR file which contains all supported APIs defined
in JCP 3.0. By including it in the Eclipse IDE, we
can facilitate all the APIs supported by Java Card
3.0. After completing the USF implementation, we
utilized the Apache Ant to build the USF source
codes and build.xml file containing the invocation
of the vendor-specific tool to convert the USF Jar
files into the binary.
After this, we tried to install the USF binaries
into the UICC by the vendor-specific tool to
perform the authentication between the UICC
and the development environment based on the
GlobalPlatform. To install the software modules
into the UICC, this authentication should be
mandatory to manage the UICC securely. For
this, GlobalPlatform specification defines the
Search WWH ::




Custom Search