Download 2.3 Open Mobile API - Amazon Web Services

Table of Contents
1
INTRODUCTION ........................................................................................................................ 4
1.1
Motivation.......................................................................................................................................... 4
1.2
Solution Idea ...................................................................................................................................... 4
1.3
Overview ............................................................................................................................................ 5
2
FOUNDATION TECHNOLOGIES ............................................................................................ 6
2.1
UICC.................................................................................................................................................... 6
2.1.1
Smart Card ........................................................................................................................................... 6
2.1.2
ISO/IEC 7816 Standard ......................................................................................................................... 6
2.1.3
Smart Card Operating System .............................................................................................................. 7
2.1.4
Basic Encoding Rules ............................................................................................................................ 7
2.1.5
PIN ........................................................................................................................................................ 7
2.1.6
File System ........................................................................................................................................... 7
2.1.7
File Access Conditions .......................................................................................................................... 9
2.1.8
Commands ......................................................................................................................................... 10
2.1.9
Application Protocol Data Unit .......................................................................................................... 11
2.1.10
Applications in UICC ...................................................................................................................... 11
2.1.11
Logical Channels ............................................................................................................................ 11
2.1.12
Cryptography ................................................................................................................................. 12
2.1.13
Over-The-Air .................................................................................................................................. 13
2.1.14
Lifecycle of a UICC ......................................................................................................................... 13
2.2
Java Card .......................................................................................................................................... 14
2.2.1
Java Card Language ............................................................................................................................ 14
2.2.2
Java Card Virtual Machine.................................................................................................................. 14
2.2.3
Java Card Runtime Environment ........................................................................................................ 15
2.2.4
Java Card APIs .................................................................................................................................... 15
2.2.5
Java Card Memory Model .................................................................................................................. 16
2.2.6
Transaction Integrity .......................................................................................................................... 17
2.2.7
Java Card Applets ............................................................................................................................... 17
2.2.8
APDUs in Java Card ............................................................................................................................ 18
2.2.9
Java Card Cryptography APIs.............................................................................................................. 18
2.2.10
ETSI TS 102.241 ............................................................................................................................. 19
2.2.11
Global Platform API ....................................................................................................................... 19
2.3
Open Mobile API .............................................................................................................................. 19
2.3.1
Overview ............................................................................................................................................ 19
2.3.2
Transport Layer API ............................................................................................................................ 20
2.3.3
Service Layer API ................................................................................................................................ 20
2.3.4
Usage Pattern ..................................................................................................................................... 21
2.3.5
Dual Application Architecture ............................................................................................................ 21
2.3.6
Access Control Mechanism ................................................................................................................ 22
2.4
Android OS ....................................................................................................................................... 23
2.4.1
Overview ............................................................................................................................................ 23
2.4.2
Application Model .............................................................................................................................. 23
2.4.3
Intent.................................................................................................................................................. 23
2.4.4
Security Management ........................................................................................................................ 23
3
STATE OF THE ART ............................................................................................................... 24
3.1
Identity Management ....................................................................................................................... 24
3.1.1
Overview ............................................................................................................................................ 24
3.1.2
Identity Management Models ........................................................................................................... 24
3.1.3
Authentication ................................................................................................................................... 24
3.2
HTTP Authentication ........................................................................................................................ 25
3.2.1
Basic Authentication .......................................................................................................................... 25
3.2.2
Digest Authentication ........................................................................................................................ 25
3.2.3
Security Analysis ................................................................................................................................ 26
3.3
OpenID ............................................................................................................................................. 27
3.4
Public Key Infrastructure .................................................................................................................. 27
3.4.1
Overview ............................................................................................................................................ 27
3.4.2
Root-of-Trust ...................................................................................................................................... 27
3.4.3
Usage Scenarios ................................................................................................................................. 27
3.4.4
Mobile PKI .......................................................................................................................................... 27
3.4.5
Security Analysis ................................................................................................................................ 27
4
MOBILE SECURITY WITH UICC ......................................................................................... 28
4.1
Role of UICC in Mobile Applications ................................................................................................. 28
4.1.1
Overview ............................................................................................................................................ 28
4.1.2
Security Channel ................................................................................................................................ 28
4.1.3
Certificate Authority .......................................................................................................................... 28
4.2
UICC-Based HTTP Digest Access Authentication................................................................................ 28
4.2.1
System Overview................................................................................................................................ 28
4.2.2
Security Analysis ................................................................................................................................ 30
4.2.3
Usage Scenarios ................................................................................................................................. 30
4.3
Smart OpenID ................................................................................................................................... 31
4.3.1
System Overview................................................................................................................................ 31
4.3.2
Privacy Extension ............................................................................................................................... 32
4.3.3
Security Analysis ................................................................................................................................ 33
4.3.4
Threats Modeling ............................................................................................................................... 34
4.4
UICC-Based PKI ................................................................................................................................. 38
4.4.1
Overview ............................................................................................................................................ 38
4.4.2
Usage Scenarios ................................................................................................................................. 38
4.4.3
Security Analysis ................................................................................................................................ 38
4.5
5
5.1
Conclusion ........................................................................................................................................ 38
IMPLEMENTATION OF SMART OPENID ......................................................................... 39
Overview .......................................................................................................................................... 39
5.2
Applet on UICC ................................................................................................................................. 39
5.2.1
Functional Description ....................................................................................................................... 39
5.2.2
Configuration ..................................................................................................................................... 39
5.2.3
Implementation ................................................................................................................................. 39
5.3
App on Android ................................................................................................................................ 39
5.3.1
Functional Description ....................................................................................................................... 39
5.3.2
5.3.3
Open Mobile API in Android .............................................................................................................. 39
Implementation ................................................................................................................................. 39
5.4
PKCS15 ............................................................................................................................................. 39
5.4.1
Architecture ....................................................................................................................................... 39
5.4.2
Configuration ..................................................................................................................................... 39
5.5
Test .................................................................................................................................................. 39
5.5.1
Test Environment ............................................................................................................................... 39
5.5.2
Test Procedure ................................................................................................................................... 39
5.5.3
Test Result .......................................................................................................................................... 39
5.6
Recommended Improvement ........................................................................................................... 39
5.7
Conclusion ........................................................................................................................................ 39
6
SUMMARY AND FUTURE WORK ....................................................................................... 39
6.1
Summary .......................................................................................................................................... 39
6.2
Future Work ..................................................................................................................................... 39
1 Introduction
1.1
Motivation
According to the statistics from International Telecommunication Union, at the end of 2011,
there were 5, 9 billion mobile-cellular subscriptions, which is equivalent to 87 percent of the
world population [1]. The Universal Integrated Circuit Card (UICC) serves as the trusted
operator anchor in mobile telecom network to authenticate the subscriber. Java Card
technology enables programs written in the Java programming language to run on UICC and
enhances the security features. Therefore the GSM Association has stated that the UICC is the
strategically best alternative as a secure element for mobile devices, which can be used in
payment or other secure services [2].
Nowadays the Smartphone becomes as the cornerstone of the mobile information society.
They allow traditional Personal Information Manager (PIM) usage and new applications (apps)
to access the enterprise applications at anytime and anywhere. Moreover, the transactionbased applications, such as the new ID card (nPA) or non-contract electronic payment (NFC)
etc., would also be served [3].
The growing market has strongly attracted hackers to make the potential for serious security
threats on Smartphone a reality [4]. The 2011 Mobile Treats Report from Juniper Networks
Mobile Threat Center (MTC) shows evidence of a significant increase of mobile malware and
other attacks [5]. Hundreds kinds of malware: among them worms, Trojan horses and other
viruses have been unleashed against the mobile devices [6], and this number increases rapidly
according to the report from McAfee’s Lab [7]. Besides these the Smartphone also suffers
from SMS spams, phishing and unexpected items on the bills [8].
Although the Smartphone contains a lot of sensitive information, the user always
underestimates the importance of security software on mobile devices, according to the survey
from Kaspersky Labs [9]. In the meantime another survey reveals that the Smartphone users
are three times more vulnerable to phishing attacks [10]. Since more people tend to use
Smartphone to handle the business issues and banking transactions, these security threats need
to be solved properly. Similar as the desktop Anti-Virus program, the mobile version can also
detect and isolate the malwares and even block the SMS-Spams, Emails from unknown
senders. However the traditional Anti-Virus software cannot tackle phishing or provide a
secure authentication and transferring of sensitive data. Furthermore the Smartphone may
connect to the unsafe wireless network in the public place and expose the user’s personal data
to the hackers.
1.2
Solution Idea
Until now the mobile application developers and today’s operating system providers have
largely ignored the potential of the UICC or other secure elements within the connected
mobile devices. The security features of UICC, e.g., secure storage, cryptographic and secure
update with OTA (Over-The-Air) make it a suitable element to enhance the security levels of
mobile applications and mobile services [11].
Before the appearance of Smartphone, the feature phones only provide the basic telephony.
For the historical reason and secure concern, it is not possible for customer applications to
communicate with the UICC. To fill the gap between mobile applications and secure elements,
e.g. UICC, SIMalliance has proposed and standardized the Open Mobile API. Using this open
API, the mobile application developers can send and receive APDU (Application Protocol
Data Unit) between UICC and mobile applications.
With the ability to communicate with UICC and access to its security features, several
security solutions could be realized and applied on the Smartphone:
 Two-Factor-Authentication [12]
 Public-Key-Infrastructure for Digital Signature[13]
 Secure Mobile Wallet [14]
The Two-Factor-Authentication can increase the security of the authentication. The password
will not be sent to the unsafe network.
The PKI can be used to provide the secure email and other information transmission’s service,
even in the unsafe network.
Secure Mobile Wallet is special for the banking transaction, from online-banking to NFC.
For the unmanaged application store, like Android App store, maybe the white list/blacklist of
apps can be used.
1.3
Overview
Firstly the security threats on Smartphone platforms and current status of solutions will be
introduced and analyzed. To solve the open issues like phishing, secure transactions and
services, the use of UICC together with the mobile applications will be described in the
second section of chapter 2.
Chapter 3 is the introduction of the operating system for UICC: Java Card. The current
version Java Card 2.2 will be used as the implementation platform while the new features in
the next version of Java Card 3 will then be introduced.
As a new technology and the focus point of this master thesis, the Open Mobile API will be
described in chapter 4. The first two sections introduce the API’s 3-layers structure together
with the fundamental use pattern. To protect the UICC, an access control mechanisms comes
in the next section. The usage of the Open Mobile API in the scenarios from chapter 2 will be
described in the last section of this chapter.
Local OpenID protocol is an improvement of the OpenID protocol with the idea of TwoFactor-Authentication. The possession of the UICC and a PIN represent the two factors in this
protocol. The implementation of this protocol will be divided into 2 parts: UICC applet and
mobile application. As the mobile platform the Android OS 2.3.5 is chosen while UICC bases
on the Java Card 2.2.2. The chapter 5 introduces the Local OpenID protocol and the relevant
knowledge like ID management and OpenID. The details of implementation and testing are
chapter 6. To show the limit of the use of UICC together with mobile application, an analysis
of this infrastructure will be carried out in the last section of this chapter. Following are the
summary and the suggestion of future works.
2 Foundation Technologies
2.1
UICC
The UICC (Universal Integrated Circuit Card) is a smart card with an operating system that is
compliant with ISO/IEC 7816 specifications and optimized for applications in the
telecommunication sector [Rankl2010].
2.1.1 Smart Card
The characteristic feature of the smart card is an integrated circuit embedded in the card,
which has components for transmitting, storing and processing data [Rankl2010]. Depending
on the components and functionalities, smart cards can be divided into different groups. The
memory card, which contains EEPROM, ROM and a security logic module, is optimized for
prepaid telephone card and health insurance card. The microprocessor card, which contains
EEPROM, ROM, RAM, I/O interface and a microprocessor, is optimized for hosting a single
or multi applications.
For the microprocessor smart card, the data can only be accessed via a serial interface which
is controlled by the operating system. Therefore the confidential data can be written and
stored on the card preventing from being accessed by unauthorized parties. The computation
of cryptographic algorithms is also supported on the smart card either with hardware or
software. These security features allow the smart card to be implemented as a security
element.
The UICC is a microprocessor smart card supporting multiple applications. It is the basis for
the Network Access Applications, for example, SIM, USIM. The physical and logic
characteristics of the UICC are specified in the ETSI TS 102.221 specification.
2.1.2 ISO/IEC 7816 Standard
ISO/IEC 7816 is an international standard for the Integrated Circuit Cards (ICC) with 14 parts
that specify different aspects and characteristics of the smart cards. Table 1 shows the parts of
the whole standard.
Part
Title
1
Cards with contacts: Physical characteristics
2
Cards with contacts: Dimensions and location of the contacts
3
Cards with contacts: Electrical interface and transmission protocols
4
Organization, security and commands for interchange
5
Registration of application providers
6
Interindustry data elements for interchange
7
Interindustry commands for Structured Card Query Language (SCQL)
8
Commands for security operations
9
Commands for card management
10
Cards with contacts: Electronic signals and answer to reset for synchronous cards
11
Personal verification through biometric methods
12
Cards with contacts: USB electrical interface and operating procedures
13
Commands for application management in multi-application environment
15
Cryptographic information application
2.1.3 Smart Card Operating System
The initial usage of the smart card war for special applications, therefore there was no actual
operating system on these cards. The smart card used in the C-Netz (the German precursor of
the GSM system) starting in 1987 had an operating system that was optimized for this
application and included a specific transmission protocol, special commands, a file system
tailored to the application [Rankl2010]. This is the start of the evolution of smart card
operating system.
The modern smart card operating system is not tailored for the special applications but
supports multi applications, file management, memory management and also third-party
program. Such operating systems are called “open platform”. Java Card is one of these
operating systems and is compatible of ISO/IEC 7816-4 standard. Therefor Java Card
supports the access of the usual smart card file system as well as the commands.
2.1.4 Basic Encoding Rules
Although the smart card has a much bigger memory capacity compared to the magnetic strip
card, it is still never enough. A good data encoding mechanism can help saving the memory
space and improving the data transmission. One popular data encoding rule used in smart card
is called Basic Encoding Rules (BER) as part of the Abstract Syntax Notation One (ASN.1)
standard [ITU-T2002].
The data object, which is created according to these rules, is called BER-TLV-coded data
object. TLV is the abbreviation for Tag-Length-Value structure, where “T” defines the type of
the object, “L” is the length of the data and “V” represents the actual data. An End-of-Content
part can be included and placed after the data, when the length requires it. The BER-TLVcoded data object should be encoded in octets (one 8-bits unit). Figure 2 depicts the structures
of the two possible encodings.
Type octets
Type octets
Length octets
Length octets
Contents octets
Contents octets
End-of-Contents octets
Figure 2 Structures of BER Encoding
2.1.5 PIN
A Personal Identification Number (PIN) is a secret number used to identify the user.
Regarding the UICC, ETSI TS 102.221 defines the types of PIN that shall exist, namely the
universal PIN, application PIN, local PIN and administrative PIN.
2.1.6 File System
The files are stored and managed hierarchically in the smart card. The modern smart card file
management system uses an object-oriented file structure, in which the file stores all the
relevant information in the file itself [Rankl2010]. The information are organized as the File
Control Parameters (FCP) template and stored in the file header, while the file body, which is
linked to the file header using a pointer, stores the actual data. Each FCP template is a BERTLV object contains a list of TLVs.
The smart card file system contains two categories of files: the Dedicated File (DF), which
can be considered as the directory file, and the Elementary File (EF) holding the actual user
data. The Master File (MF) is a special type of the DF as the root of a file system. Instead of
using physical addresses, files are identified with 2-byte file identifiers (hexadecimal) as
logical names. Some file identifiers can be reserved by the standards. For historical reason the
MF has always the identifier “3F00”. Figure 3 depicts an example of the tree-like file system.
MF
DF
...
EF
DF
DF
...
...
...
EF
EF
...
Figure 3 File System in Smart Card
Regarding the UICC, ETSI TS 102.221 specifies the Application Dedicated File (ADF) as a
special DF that contains all the DFs and EFs for an application. The ADF can be referenced
either with the 2-byte file identifier or with the Application Identifier (AID). In contrast to the
DF, the ADF cannot be placed under the MF, which makes ADFs similar to the MF. Figure 4
depicts an example of the file system in a UICC.
MF
...
EF
...
EFDIR
DF
DF
...
...
...
EF
ADF
...
EF
DF
...
EF
...
Figure 3 File System in UICC
2.1.7 File Access Conditions
ISO/IEC 7816 File access conditions can be grouped into state-oriented and commandoriented access conditions in smart cards [Rankel2010]. For state-oriented conditions, the
access condition of the file is compared with the current security state using the logical
comparison operation. With command-oriented conditions, the particular commands, which
are normally authentication and identification commands, must be previously executed in
order to grant the access.
The second variant is used for the UICC. The access conditions are not defined directly for
the file itself but for the commands operated on it. Each file (EF, DF or ADF) has a security
attribute stored in the file’s FCP template. The security attribute includes a set of access rules
that consists the access mode and one or more security conditions. The access modes indicate
the applicable operations on the file, and the security conditions contain references to the
applicable key references (PINs). Table 1 depicts the security attribute of the EFIMSI
(International Mobile Subscriber Identity) [51011-500].
Access Mode
READ
UPDATE
INVALIDATE
REHABILITATE
Security Condition
ALW
CHV1
ADM
ADM
2.1.8 Commands
ISO/IEC 7816-4 standard defines the commands for the smart card in general. For the UICC,
the commands are specified for GSM (TS 51.011 and TS 51.014) and USIM (TS 102.221 and
TS 102.222). The classifications of smart card commands are shown in Figure 4 and Figure 5.
Figure 4 Classification of Commands for Card Usage [Rankl2003]
Figure 5 Classification of Commands for Administrative Functions [Rankl2003]
2.1.9 Application Protocol Data Unit
To exchange commands and data between the terminal and the smart card, the Application
Protocol Data Unit (APDU) is used. APDUs can be divided into two categories: command
APDU being sent to the smart card and response APDU being returned from the smart card.
The structure of APDU is defined in ISO/IEC 7816-4 standard. Table 2 shows the structure of
the command-response pair APDUs.
Field
Command header
Description
Class byte denoted CLA
Instruction byte denoted INS
Parameter bytes denoted P1-P2
Lc field
Command data field
Le field
Response data field
Response trailer
Absent for encoding Nc = 0, present
for encoding Nc > 0
Absent if Nc = 0, present as a string
of Nc bytes if Nc > 0
Absent for encoding Ne = 0, present
for encoding Ne > 0
Absent if Nr = 0, present as a string
of Nr bytes if Nr > 0
Status bytes denoted SW1-SW2
Number of bytes
1
1
2
0, 1 or 3
Nc
0, 1, 2 or 3
Nr (at most Ne)
2
Table 2 Structure of Command-Response APDUs [ISO/IEC 7816-4]
The coding of the fields for the UICC is compliant of the above mentioned standard. The
concrete definition of the CLA, INS and SW bytes is specified in the TS 102.221 specification.
2.1.10 Applications in UICC
Before the introduction of UICC, the SIM is a smart card with the specialized applications
designed for the GSM network. By contrast, the UICC supports multi applications that enable
the telephony devices to be identified and authenticated not only in the GSM network but also
in the UMTS or CDMA network. To enable the authentication in the GSM network, a SIM
application must be present on the UICC, while the USIM application is used for the UMTS
network. The SIM and USIM applications are called Network Access Applications (NAA),
and they must never be activated at the same time, the selection of them depends on the
capabilities of the device.
Besides these NAAs, other types of applications can also be present on the UICC. For
example, the network operator can provide its value added services with the applications
based on the toolkit technology [TODO]. The Near Field Communication (NFC) applications
are developed and deployed on the UICC to provide the contactless payment. The Smart Card
Web Server (SCWS) enables that the resources in xHTML format stored on the UICC can be
browsed by the user with the browser of the handset [TODO]. More applications from the
third party can also be installed on the UICC to extend its usability.
2.1.11 Logical Channels
On the microprocessor smart card, multiple applications can be present and accessed. Logical
channels make the exchange of command as well as data between the terminal and multiple
applications possible. The channel number is encoded in the CLA byte of the SELECT
command. Once the application is selected, the subsequent APDUs will be dispatched to the
application inside the assigned logical channel. The smart card that supports logical channels
must have one basic channel (channel number is zero), which must be permanently available,
and at least one additional logical channel. The interleaving of command-response pairs is
prohibited, which means that only one channel can be active at a time.
Regarding the UICC, the basic channel is occupied by the SIM or USIM application while the
logical channels can be obtained by the other applications.
2.1.12 Cryptography
The cryptographic techniques have a big significance in smart cards for two motivations
[Chen2000]:
 To ensure application security and to ensure data transmission security between the
smart card and the terminal
 To function as a security module through which the security of other systems can be
enhanced
The four objectives of cryptography are: authenticity, confidentiality, integrity and nonreputation [Rankl2010]. Consider the first motivation of using cryptographic regarding these
objectives:
 Authenticity refers that the involved parties must be validated to be who they claim
they are. For example, the mobile payment applet stores the currency of the
cardholder. Before a payment is actually made, a mutual authentication must be
carried out to confirm that the merchant and the customer are genuine.
 Confidentiality refers that the message or data must be stored and transferred securely
to prevent the disclosure. For example, after the mutual authentication the mobile
payment applet can make a payment by sending the sum of money, the bank account
number and the TAN code. To ensure the privacy of the customer, the data must be
encrypted before transmitting.
 Integrity refers that the data cannot be modified undetectably. Regarding the mobile
payment applet, the transferred amount of money must be kept unmodified, otherwise
the merchant and the customer will suffer from loss. To ensure the integrity of data,
the MAC (message authentication code) can be used. The client applet calculates the
MAC of the encrypted message and includes it in the APDU. Upon receiving the
APDU message, the merchant server must calculate the MAC itself and compare it
with the one supplied by the customer.
 Non-Reputation refers that the involved parties of a transaction cannot deny its
participation. Regarding the mobile payment example, the customer cannot deny
her/his confirmed payment, while the merchant cannot deny the received payment
from the customer. Public key encryption can be used to ensure this property as well
as the confidentiality. In case of sending files or Emails, the digital signature can be
used to establish non-reputation.
Since the smart card can store the secret credential of the cardholder, it can also be used as a
secure module, for example, the UICC in the handset or the smart card in the TV top box.
Such application scenarios include a network server that provides the required services and a
client. To get access to these services, the user must be authenticated with the corresponding
smart card.
For example, the UICC contains the International Mobile Subscriber Identity (IMSI) and an
authentication key (Ki) for the 2G network. After the handset is powered on, it obtains the
IMSI from the UICC and sends it to the Mobile Network Operator (MNO). The MNO
searches for the associated Ki for this IMSI and generates a challenge in the form of a random
number, and then it signs this random number with the found Ki, the result is called Signed
Response 1. Upon receiving the challenge random number, the UICC signs it with its Ki to get
the Signed Response 2, and then sends it to the MNO. Then the MNO compares the received
response with the Signed Response 1, if they are identical, then this UICC is authenticated.
Figure 5 depicts a general classification of cryptographic techniques used in the smart card.
Figure 5 Classification for Cryptographic Techniques in Smart Card [Rankel2003]
2.1.13 Over-The-Air
Over-The-Air (OTA) is a technology that manages or updates the data and applications in
smart cards after they are issued. Figure 6 shows the OTA infrastructure. The back-end
system includes the Mobile Network Operator, content provider or billing system etc. They
use OTA to maintain the user’s smart card, provide subscribed information or value-added
services. The OTA gateway receives the service data from the back-end system, transforms
the service data into the secured packet format, and transports it using the corresponding
bearer (SMS or GPRS etc.), which is determined by the ability of the receiving smart card and
the network.
The GSM 03.48 specification defines the secured packet structure in the SMS for the SIM.
The ETSI TS 102.225 specification generalizes this secured packet structure for the UICC,
and extends the bearer from the SMS to the HTTPS. The contents of the secured packets are
the encrypted commands for the UICC. After the mobile equipment has received and
recognized the secured packages, it sends them to the UICC. The UICC stores the packets in a
particular buffer and restores them to the correct sequence, and then extracts the commands
from the decrypted messages. The commands can be divided into two groups:
 Remote file management (RFM)
 Remote applet management (RAM)
2.1.14 Lifecycle of a UICC
2.2
Java Card
Java Card stands for an open operating system for the smart card, in contrast to the proprietary
platform. As an ISO/IES 7816 compatible platform, Java Card provides the access to the
common smart card file system. Furthermore, Global Platform specification defines the
standard for loading and managing Java-based applications in Java Card.
2.2.1 Java Card Language
Due to the limitation of the memory capacity, the Java Card language is a subset of the Java
language. All the supported features in Java Card also exist in Java and have the same
behaviors. Table 1 depicts the overview of the Java Card language subset.
Supported Java Features
 Small primitive data types: boolean,
byte, short, One-dimensional arrays,
Java packages, classes, interfaces,
and exceptions,
 Java object-oriented features:
inheritance, virtual methods,
overloading and dynamic object
creation, access scope, and binding
rules,
 The int keyword and 32-bit integer
data type support are optional.

The Garbage Collector
Unsupported Java Features
 Large primitive data types: long,
double, float
 Characters and strings
 Multidimensional arrays
 Dynamic class loading
 Security manager
 Threads
 Object serialization
 Object cloning
Table 1 Overview of the Java Card Language Subset [SteppingStonesR7]
2.2.2 Java Card Virtual Machine
The Java Card Virtual Machine (JCVM) is a split model (Figure 1) of the normal Java Virtual
Machine, due to the system resource limitation of the smart card. The code, which is written
in the Java Card language, should be firstly converted using the off-card converter on a PC or
a workstation. During the converting, the static check is performed. At the end, a CAP
(Converted Applet) file is generated. After being sent to the smart card and loaded, the
executable bytecodes are stored on the smart card. Then the on-card interpreter can interpret
and execute the Java Card bytecodes.
Figure 1 Java Card Virtual Machine [chen2000]
2.2.3 Java Card Runtime Environment
The Java Card platform Runtime Environment contains the Java Card virtual machine (VM),
the Java Card Application Programming Interface (API) classes (and industry-specific
extensions), and support services [JCREspec]. Therefore it can be considered essentially as
the smart card’s operating system. Figure 1 shows the JCRE in the smart card.
Figure 1 On-card System Architecture [Chen2000]
The system classes are on the basis of the JCVM and native methods, they are analogues to
the core of the operating system. The Java Card framework classes define the APIs for the
development of Java Card applets. The industry-specific extensions are used to provide
additional services or interface for the specific domains. For example, the UICC Java Card
should supply the APIs defined in the TS 102.241 specification and the Global platform
specification. The installer is provided to make the download and install of applets onto the
issued smart card possible.
2.2.4 Java Card APIs
The Java Card APIs contain the mandatory core packages and optional extension packages
(with an “x”). The packages for specific domains can also be included for the application
developers. For example, the file access API in the UICC is defined in the TS 102.241
specification. Figure 1 to Figure 3 describes the Java Card API packages.
Package
java.io
java.lang
java.rmi
Description
Java Card I/O exception class: IOException
Java Card classes: Object, Throwable, Exception
Remote interface: Remote and Remote exception class: RemoteException
Figure 1 Java Card API Packages (Part 1)
Package
javacard.framework
Description
This package contains the interfaces, classes and exceptions for
the Java Card Framework:
 Interfaces ISO7816, MultiSelectable, PIN, Shareable
 Classes AID, APDU, Applet, JCSystem, OwnerPIN, Util
 Exceptions APDUException, CardException,
CardRuntimeException, ISOException, PINException,
SystemException, TransactionException, UserException
javacard.framework.service This package contains the interfaces, classes and exceptions for
services:
 Interfaces service, RemoteService, SecurityService
 Classes BasicService, Dispatcher, CardRemoteObject,
RMIService
 Exception ServiceException
javacard.security
This package contains the interfaces, classes and exceptions for
the Java Card security framework:
 Interfaces Key, PrivateKey, PublicKey, SecretKey,
SignatureMessageRecovery
 Classes Checksum, KeyAgreement, KeyBuilder,
KeyPair, MessageDigest, InitializedMessageDigest,
RandomData, Signature
 Exception CryptoException
Figure 2 Java Card API Packages (Part 2)
Package
Description
javacardx.crypto This is an extension package that defines the interface KeyEncryption and
the class Cipher.
Figure 3 Java Card API Packages (Part 3)
2.2.5 Java Card Memory Model
The memory of the smart card contains three types: ROM, EEPROM and RAM. ROM is used
to store the operating system and relevant data during the manufacture process, and then it
cannot be modified anymore. EEPROM and RAM are both rewriteable, the most significant
difference is: EEPROM does not lose the content by the power loss (nonvolatile).
Additionally, EEPROM is low priced compared to RAM, but RAM is 1,000 times faster by
write operations. For these reasons, EEPROM typically has a greater capacity than RAM on
the smart card. EEPROM is normally used to save the downloaded applets and data, while
RAM is for the intermediate results of different applets.
According to this memory model of the smart card, Java Card supports two types of objects:
persistent objects and transient objects. The persistent objects stored in EEPROM are able to
exist beyond the execution time of a process. The transient objects contain essentially two
parts: the data fields in RAM and object reference in EEPROM. The transient objects must be
created in the applet, the space for the data fields are allocated and reserved in RAM for its
lifetime. Once the smart card restarts, the applet uses the same object reference to access the
transient object’s data fields, which lose the contents from the last session. Usually the
transient objects are used for the objects that need frequently write operations. Figure 1 shows
the transient objects in Java Card.
transient
object 1
RAM
EEPROM
object
reference 1
transient
object 2
object
reference 2
Figure 1 Transient Objects in Java card [Chen2000]
2.2.6 Transaction Integrity
The data integrity is essential for the smart card, sine it stores the confidential data of the
cardholder. A sudden power loss may cause the integrity problem during a transaction. Thus
JCRE provides the atomic operation mechanism to ensure the transaction integrity.
The transaction model in Java Card is similar to the data base transaction, which uses begins,
commit and rollback routines to ensure the atomicity. The class JCSystem from package
javacard.framework provides the methods to build the Java Card transaction routine:
// Starts a transaction
JCSystem.beginTransaction();
...
// Commits a transaction
JCSystem.commitTransaction();
Only when the JCSystem.commitTransaction() is reached, then all the changes to the data can
be committed. Otherwise all the changes will be aborted, and the TransactionException will
be thrown.
2.2.7 Java Card Applets
The Java Card applet must extend the class Applet from the package javacard.framework, and
implement the install, process, select and deselect methods. Table 1 depicts the most
important methods of a Java Card applet defined in the Java Card 2.2 API specification
[JavaCard22APISpec].
static void
install (byte[] bArray) install(byte[] bArray, short bOffset, byte bLength)
protected void
To create an instance of the Applet subclass, the JCRE will call this
static method first.
register()
protected void
This method is used by the applet to register this applet instance with the
JCRE and to assign the Java Card platform name of the applet as its
instance AID bytes.
register(byte[] bArray, short bOffset, byte bLength)
boolean
This method is used by the applet to register this applet instance with the
JCRE and assign the specified AID bytes as its instance AID bytes.
select()
abstract void
Called by the JCRE to inform this applet that it has been selected when
no applet from the same package is active on any other logical channel.
process(APDU apdu)
void
Called by the JCRE to process an incoming APDU command.
deselect()
Called by the JCRE to inform that this currently selected applet is being
deselected on this logical channel and no applet from the same package
is still active on any other logical channel.
Table 1 Methods in the Java Card Applet [JavaCard22APISpec]
2.2.8 APDUs in Java Card
The Application Protocol Data Unit, which is used in the smart card to transmit data between
the terminal and the card, is supported in Java Card with the class javacard.framework.APDU.
The JCRE creates an APDU object, when the smart card I/O interface receives the APDU
from the terminal, and then it dispatches the APDU object to the current selected applet. Upon
receiving the APDU, the process method in the applet will handle it and create the response to
the terminal. The structure of the APDU must conform to the ISO/IEC 7816-4 standard. An
example of processing APDU is:
/**
* Processes an incoming APDU.
* @see APDU
* @param apdu the incoming APDU
* @exception ISOException with the response bytes per ISO 7816-4
*/
public void process(APDU apdu)
{
// Returns the APDU buffer byte array
byte buffer[] = apdu.getBuffer();
// Reads the data into the APDU buffer
short bytesRead = apdu.setIncomingAndReceive();
...
// Sets the data transfer direction to terminal
apdu.setOutgoing();
// Sets the length of the response data
apdu.setOutgoingLength((byte)2);
// Sends the data from the offset with the given length
apdu.sendBytes((short)0, (short)2);
}
2.2.9 Java Card Cryptography APIs
The Java Card cryptography APIs is designed according to the Java Cryptography
Architecture [JCA], and is aligned with the Java Platform. This architecture is designed to
separate the interface and the implementation. In this way, the JCRE provider could tailor the
implementation and only provide the necessary code to save the memory of the smart card.
The jacacard.security package provides the definitions of algorithms and factory for building
cryptographic keys. The most important classes are shown in Table 1.
Class
Description
KeyBuilder
MessageDigest
RandomData
Signature
KeyAgreement
This class is a key object factory.
This class is the base class for hashing algorithms such as MD5, SHA.
This class is the base class for random number generation.
This class is the base class for signature algorithms such as HMAC, RSA.
This class is the base class for key agreement algorithms such as DiffieHellman and EC Diffie-Hellman.
Table 1 Classes of Java Card Cryptography APIs
2.2.10 ETSI TS 102.241
Java Card does not have its own file system. As an ISO/IEC 7861-4 operating system, Java
Card access and manage the file system with MF, DF, EF and ADF. The file management
API is not directly provided by Java Card, but relies on the specification of the concrete
application sector, for example: UICC. ETSI TS 102.241 defines the UICC API for Java Card
including file access API, Toolkit API and file system management API.
2.2.11 Global Platform API
2.3
Open Mobile API
Open Mobile API is a software interface between the application on the phone and the secure
element, for example, UICC or Secure Memory Card. This open API is established and
specified by the SIMalliance [Open Mobile API paper].
2.3.1 Overview
The SIMalliance Open Mobile API has a three layer architecture (Figure 1):
 Transport Layer is the foundation of the other layers. The mobile application can
access the secure element through this layer, and the format of the messages is APDU.
 Service Layer abstracts the functionalities of the secure element such as cryptography,
authentication. This will ease the use of secure element for the mobile application
developers, because they do not need to take care of all the details of APDUs.
 Application Layer refers to the applications using Open Mobile API.
Figure 1 Architecture of SIMalliance Open Mobile API
2.3.2 Transport Layer API
As the interface between the secure element and the mobile application, the transport layer is
responsible to transmit the command and get the response. Table 1 depicts the classes of the
transport layer and the Figure 1 shows the class diagram.
Class
SEService
SEService: CallBack
Reader
Session
Channel
Description
This class is the entry point of the Open Mobile API.
This class receives call-backs when the service is connected.
This class represents the available secure element readers
connected to the mobile device.
This class represents a session with one secure element.
This class represents a channel (ISO/IEC 7816-4) opened with one
secure element.
Table 1 Classes of Transport Layer
Figure 1 Class Diagram of Transport Layer
2.3.3 Service Layer API
The service layer abstracts the available services and functionalities provided on the secure
element. Since different types of secure element exist and can be used with Open Mobile API,
this layer depends on the concrete type of the secure element, and should be specified by the
corresponding organization. The Open Mobile API 2.0 specification [] defines 4 services as
shown in Figure 1.
Figure 1 Service API Overview
Besides these services, the cryptographic API should be included as a component of the
service layer. The Crypto API relies on the existing operating system and the native API. For
this reason, the Crypto API is not defined in this specification.
2.3.4 Usage Pattern
To access the secure element via the Open Mobile API, the transport layer API should be used.
Figure 1 shows a general usage pattern of this API.
1. In the mobile application, an object of the SEService class should be created to
represent the connection between the application and the secure element. An
implementing of the SEService.Callback should be passed as the parameter to the
SEService object, and this callback method will be called when the connection to the
secure element is established.
2. Using the SEService object, all the available secure element reader can be enumerated.
The mobile application should choose the correct reader for its following operations.
3. With the chosen reader, the mobile application can open a session with the secure
element inside the reader.
4. When the session is opened, the mobile application can retrieve the Answer-To-Reset
(ATR), which contains various parameters related to the smart card, and check if the
ATR matches with one of the known ATRs.
5. After a validation of the ATR, the mobile application can open a channel with the
applet on the secure element. The channel used in Open Mobile API is compliant to
the specification of ISO/IEC 7816-4 standard.
6. Within the channel, the mobile application can transmit and receive APDUs with the
applet. The APDU used in Open Mobile API is compliant to the specification of
ISO/IEC 7816-4 standard.
7. When the mobile application finishes its task, then it should close the opened channel
and session.
2.3.5 Dual Application Architecture
The dual-application architecture with Open Mobile API is promoted by the GSMA
[gsmanfcspec] for the NFC (Near Field Communication) service with UICC. However this
architecture can be generally used for various applications with Open Mobile API. Figure 1
depicts this architecture.
Secure Element Platform
Application logic
Mobile Device Platform
Communication Channel
(Open Mobile API)
Application UI
Figure 1 Dual Application Architecture
The application user interface is provided by the mobile application as the consumer facing
component, while the application logic resides in the secure element to enhance the security
of the whole application. The communication channel between these two components can be
Open Mobile API.
2.3.6 Access Control Mechanism
With the dual-application architecture, the applications like NFC Payment with mobile device
are developed and increase rapidly. Since the most application with the support of secure
element relate to the financial or personal confidential information, a security mechanism
between the secure element and the mobile application is needed.
The signature-based access control mechanism is proposed by the GSMA in [gsmanfcspec].
This mechanism relies on the ability of the mobile device to retrieve the signatures of the
mobile application. The secure element can manage a white list of the signatures to validate
the mobile application. There are three entities within this mechanism, they are: the mobile
application, the secure element applet and the secure element access API (e.g. Open Mobile
API). The access control module should contain three sub-modules (Figure 1):
 The Access Control Filtering in the secure element access API
 The Access Control Rules Database & Engine in the secure element access API
 The Access Control Data stored in the secure element
Figure 1 Access Control Mechanism [gsmnfcspec]
The access control filtering receives the access request of the mobile application from the
transport layer. Within the access request, there should be the signature of the mobile
application and the Application Identifier (AID) of the applet on the secure element. Once
retrieved this information, the filtering sends them to the access rules engine to validate. If the
required information is not available, then the access request will be denied.
The access control engine is responsible to process the received access request from the
filtering. After extracting the signature of the mobile application and the AID of the applet,
the engine should check the access control rules database. The access control rules are built
with the target applet, the mobile application signature and the access condition. If a rule is
not found, then the engine should check the access control data inside the secure element to
decide, whether to build a new rule or deny the access request.
The access control data stores all the relevant information for building access control rules.
This information includes the AIDs, the signatures of the mobile application and the access
condition. The format of the access control data depends on the used file structure in the smart
card. For example, the PKCS#15 file structure is one choice for the UICC as the secure
element.
2.4
Android OS
2.4.1 Overview
2.4.2 Application Model
2.4.3 Intent
2.4.4 Security Management
3 State of the Art
3.1
Identity Management
3.1.1 Overview
The core element of the computing security begins with the identity, which is the computer
representation of users, programming agents, hosts or network devices. The management of
the identity is the precondition of the other security elements, for example, resource access
control, data and message security, non-repudiation or service availability [Benantar2006].
Identity management includes [COMP522Identification]:
 Identification: associates an identity with a subject (“Who are you?”)
 Authentication: establishes the validity of an identity (“Are you indeed the entity you
claim you are?”)
 Authorization: associates rights or capabilities with a subject (“What rights (authority)
do you have?”)
Identification forms a unique identity for authentication and authorization. Authentication
validates the identity. Authorization, which depends on the authentication, verifies the
associated permissions of the identity.
3.1.2 Identity Management Models
In [Josang2005], the identity management is classified into the following models:
 Isolated identity management: the service provider acts also as the identifier and
credential provider. The user can only use the assigned identifier to access the specific
service domain.
 Federated identity management: the user’s identifiers from different service
providers are linked and associated. Once the user authenticates herself with a single
identifier by one of these service providers, and then she can be considered identified
and authenticated by other associated providers as well.
 Centralized identity management: there is an independent identifier and credential
provider that is used by all the service providers (for example, single sign-on).
Among these models, the first one is simple from the service provider’s point of view, but the
increased number of identifiers for various service domains is a heavy burden for the users.
The federated approach requires the service provider to establish additional trust relationship
with the other parties, thus becomes complex and causes additional costs. The last model
moves the management of identity from the service provider itself to the third party, in this
way the service provider can save the costs, and the user can access various services with a
single identifier.
3.1.3 Authentication
Users get identities from the different identity management models. Each identity is
associated with an authentication credential that can be verified by the authentication system.
The premise that an entity maintains secrecy of its credential except sharing it with a
designated computing system yields authenticity of the identity associated with that entity
[Benantar2006]. The methods to present a secret to a computing system, which are called
authentication factors, include:
 something the user knows: password, personal identification number (PIN)
 something the user has: secret token (for example, smart card)
 something the user is: biometric
The most authentication systems use one of these authentication factors to verify the identities.
The combination of multi factors can be used in the services that are under stringent security
constraints, for example, the automatic teller machines (ATM) use the PIN together with the
card for a 2-factor-authentication.
3.2
HTTP Authentication
3.2.1 Basic Authentication
The first authentication factor, which requires the knowledge of the user, forms the basic
authentication scheme in the HTTP protocol [RFC1945]. HTTP uses the challenge-response
authentication mechanism. A server challenges a client with the “401 unauthorized” message,
and then the client provides the authentication information, which is a user-ID and a password
in an unencrypted form. This mechanism is considered to be non-secure, because it’s based on
the assumption that the connection between the server and the client can be regarded as
trusted, which is not generally true on an open network.
3.2.2 Digest Authentication
The digest authentication is specified in [RFC2069] as an authentication mechanism for the
HTTP protocol. Like the basic authentication, this scheme is also based on the challengeresponse paradigm. Instead of the simple “401 unauthorized” message, the server challenges
the user with a nonce value. A valid response contains a checksum of the user-ID, the
password, the nonce value, the HTTP method and the requested URI. In this way, the
password is never sent in the plaintext. As the algorithm to generate the digest, MD5 is
chosen default.
[RFC2617] improves this digest authentication mechanism by introducing several optional
security enhancements, for example, quality of protection (qop), nonce counter and clientgenerated nonce. The authentication response without any additional security options is
formed:
A1 = username-value ":" realm-value ":" password
where
- realm is a string to be displayed to users so they know which username and password
to use
A2 = method ":" digest-uri-value
where
- method is defined in [RFC2616] as the token to indicate the method to be performed
on the resource identified by the request URI, for example, GET, POST or PUT etc.
- digest-uri-value is the value of the request-uri.
Response = KD( H(A1), nonce-value || H(A2) )
= MD5(MD5(A1), nonce-value ":" MD5(A2))
where
- H(data) is the string obtained by applying the checksum algorithm to the data
- KD(secret, data) is the string obtained by applying the digest algorithm to the data
with secret.
If the “qop” directive’s value is “auth-int” (with integrity protection), then A2 and response
are:
A2 = method ":" digest-uri-value ":" H(entity-body)
Response = KD(H(A1), nonce-value ":" nc-value ":" cnonce-value ":" qop-value ":"
H(A2))
= MD5(MD5(A1), nonce-value ":" nc-value ":" cnonce-value ":" qop-value ":"
MD5(A2))
where
- nc-value is the hexadecimal count of the number of responses that the client has sent
with this nonce value.
- cnonce-value is the string value provided by the client and used by both client and
server to avoid chosen plaintext attacks.
Upon receiving the authentication response from the user, the server should calculate the
value itself with the same process, and then check it against the response from the user. If this
verification succeeds, then the user is authenticated; otherwise, the user will receive the “401
Unauthorized” message.
3.2.3 Security Analysis of Digest Authentication
The digest authentication is intended to replace the weak basic authentication. Beyond
protecting the actual password, the digest mechanism does not provide the confidentiality
protection, which depends on the transport layer security (TLS).
The strength of the digest authentication is that, the eavesdropper can not directly obtain the
password from the user. In this way, the password is protected from the network sniffing. The
other possible attacks against digest mechanism are:
Replay attack
The attacker eavesdrops on the conversation between the victim and the server to intercept the
transmitted data, which includes the hashed password from the user. After the user finishes
the session with the server, the attacker uses the hash value repeated to get authorized by the
server.
The nonce value from the server protects against this attack. The server maintains a list of the
nonce values. Upon receiving the hash value of the password and the nonce from the user, the
server looks up the list and marks this nonce value as used. In this way, the repeated use of the
nonce is avoided.
Man-in-the- middle attack
As described in [RFC4169], the digest authentication is vulnerable to Man-in-the-middle
attack, even when it runs insides the TLS. Consider the proxy is compromised by the attacker,
and the attacker masquerades the server to the client. Then the MITM attacker could
challenge the user with the basic authentication mechanism, in order to get the credential from
the user in the plaintext.
The compound of the digest authentication with the TLS is indented to make the
authentication mechanism more secure and reliable. In this protocol, the client authenticates
the server with TLS, and the server authenticates the client with digest authentication. Since
the hash value will be transferred inside the secure tunnel, the password is protected from any
eavesdroppers. However, this compound authentication protocol is still vulnerable to the
MITM attack, as discussed in [ANN05], because:
- The legacy client authentication protocol is used in other environments.
-
The client cannot or does not properly authenticate the server.
The MITM attack against the tunneled digest authentication protocol proceeds as:
1. The attacker compromises the proxy and waits for the client to start a session. As a
legacy client, an untunnelled authentication protocol can be used; otherwise a tunnel
with the attacker’s server certificate can be established.
2. If the client fails to authenticate the server, and considers the attacker as valid, then the
attacker contacts the real server using TLS and forwards the authentication challenge
to the victim.
3. In case of digest authentication, the client sends the hash value of the password and
the nonce from the real server to the attacker. If the base authentication is used, then
the attacker obtains the password directly.
4. Upon receiving the authentication response form the victim, the attacker can use it to
authenticate itself by the real server.
The root cause of this vulnerability is due to the fact that the client cannot verify the server,
which established the tunnel with it, is the one, which initialized the authentication request;
while the server is not able to validate the client, which established the tunnel with it, is the
one, which sends the authentication response. To enable this mutual verification, a
cryptographic bind should be used, as suggested in [ANN05].
Chosen plaintext attack
Consider there is
3.3
OpenID
3.4
Public Key Infrastructure
3.4.1 Overview
3.4.2 Root-of-Trust
3.4.3 Usage Scenarios
3.4.4 Mobile PKI
3.4.5 Security Analysis
4 Mobile Security with UICC
4.1
Role of UICC in Mobile Applications
4.1.1 Overview
4.1.2 Security Channel
SCP80: OTA
4.1.3 Certificate Authority
4.2
UICC-Based HTTP Digest Access Authentication
The man-in-the-middle attack described in the section 3.5.3 is caused by the inability of the
authentication server to validate that the client authentication occurring inside a tunnel
originated at the same endpoint as the tunnel itself [JosePuthenkulam2003]. Using
cryptographic binding the authentication server can distinguish the real peer from the MITM
attacker [Asokan2005].
4.2.1 System Overview
Client is a mobile application running on the Smartphone with a partner applet on the UICC.
The applet should be only accessible from the mobile application, which certificate is signed
by the applet issuer and the hashed value should be stored in the UICC’s access control table.
A long-term secret (LTS) will be saved in the applet, which can be carried out with the OTA
operation. This secret is a shared key between the client and the server.
Server is an authentication server or the service provider self, which can process the
authentication procedure. In each case the server should have the same shared keys of the
clients. The distribution and update of the long-term secrets can be delegated to a network
operator.
This UICC-Based HTTP Digest Access Authentication is a compound authentication method,
which involves the authenticated tunnel and the encapsulated modified HTTP Digest Access
Authentication. The both parties are principally obliged to firstly establish the secure tunnel
and then process the authentication as well as the session key exchange within the tunnel. To
prevent the MITM attack, a cryptographic binding is added. Figure x depicts the compound
authentication procedure.
Client
Server
Tunnel establishment request
Tunnel established
Authentication Request (user identity)
Cryptographic Binding Request (Handle, S_MAC)
Cryptograhic Binding Response (C_MAC)
Authenticated, Key Exchange
After receiving the authentication request, the server will generate a shared key (DK) with the
key derivation function (PBKDF2):
DK = PBKDF2(HMAC-SHA1, LTS, AH, dkLen)
where
- HMAC-SHA1 is the pseudorandom function
- LTS: long-term secret as the master password
- AH: association handle (a random generated string) as the salt
- dkLen: length of the DK
Using the generated secret key and association handle, a S_MAC can be calculated with the
HMAC-SHA:
S_MAC = HMAC(DK, AH)
where
- DK as the secret key
- AH as the message
Upon Receiving the cryptographic binding request, the client generates the DK’ with the same
function:
DK’ = PBKDF2(HMAC-SHA1, LTS, AH, dkLen)
By a successful verification of the S_MAC with DK’, the client signs the authentication
assertion with DK’ and sent it back to the server. The server will check the signed assertion
with DK and verify if the client is the legitimated one. After this mutual authentication the
key exchange can be processed for the following secure data transfer.
To start this compound authentication procedure, the user should be firstly local authenticated.
As the client software is a mobile application installed on the Smartphone, a traditional PIN
verification can be used. To prevent the PIN from Brute-force attack, a limitation of retry
should be set.
4.2.2 Security Analysis
Assuming the cryptographic binding process is processed by the two endpoints of the secure
tunnel, which actually established it, the generated session key will be securely exchanged
within the two participants. However under the MITM attacks, the client may be fooled to
start an authentication process with the attacker, which will retrieve the request from the
victim and continue the authentication with the server [Asokan2005]. Figure x is a variation
of the attack scenario in [JosePuthenkulam2003] and depicts the MITM attack in our protocol:
Client
MITM
Server
Auth Request (user identity)
Tunnel establishment request
Tunnel established
Cryptographic Binding Request (Handle, S_MAC)
Cryptograhic Binding Response (C_MAC)
Attack detected: Authentication failed
After receiving the cryptographic binding request, the MITM attacker cannot provide the
correct S_MAC which the client will validate against. On the other hand, the attacker cannot
send the valid cryptographic binding response with C_MAC to sever, which implies the
authentication process is under attack. Therefore this compound authentication protocol is
proved to be immune to the MITM attack.
4.2.3 Usage Scenarios
This local PIN verification and the compound authentication protocol construct a Two-FactorAuthentication, which can be used for the services that require a strong authentication. In the
Dual-Application-Architecture, the UICC stores the long-term secret and deals with the
security logic. According to the type of the applications, the mobile application may provide
the corresponding functionalities. Example of possible usage scenarios include:
-
Cloud storage
Online-Banking
4.3
Smart OpenID
The UICC-Based HTTP Digest Access Authentication utilizes the UICC’s basic
functionalities with the MNO’s infrastructure and provides a high secure authentication,
which is immune to the MITM attacks. However due to the limitation of the UICC’s memory
space, only restricted number of applets could be installed on it. A combination of this
compound authentication with the existing OpenID protocol leads to a more secure Single
Sign-On mechanisms, which is introduced in [Leicher2012] as Smart OpenID.
4.3.1 System Overview
Phishing is the well-known vulnerability of the OpenID, which causes the user identity or
personal information theft. To prevent this attack, the user should be capable to decide
whether the opened web page is the legitimated one. The central idea of the Smart OpenID is
to setup a local OpenID server on the Smartphone, which acts as a delegate of the network
OpenID server. Instead of using the browser to do the authentication on the OpenID
provider’s web page, an application UI should be used. The local OpenID server follows the
Dual-Application-Architecture, which includes the UICC applet to handle the secure logic
and the mobile application to supply the UI. The same access control should be applied to
protect the UICC against malicious mobile applications. Figure x depicts the general
workflow of the Smart OpenID protocol:
Local OP = UICC App + Mobile App
UICC App
Mobile App
Browser
Net OP
RP
Auth Request(OpenID identifier)
Discovery and Association
Asscociation Response(S, assoc_handle)
Redirect to local OP (assoc_handle)
Auth Request (assoc_handle, parameters)
Open Channal Request (AID, PIN)
Open Channel Response
APDU (assoc_handle)
APDU (OK)
APDU (parameters)
APDU (signed Assertion)
Auth Response (signed assertion)
HTTP Request (signed assertion)
RP verifies signed assertion with S
Browser refers to the web browser on the Smartphone, which is able to retrieve, present the
resources on the WWW via HTTP.
Relying Party (RP) refers to the Smart OpenID acceptor.
Network OpenID Provider (NetOP) refers to the OpenID provider, which has a HTTP
interface for the relying parties. The NetOP shares a long-term secret with the local OpenID
provider (LOP) and can be operated by the mobile network operator (MNO).
Local OpenID Provider (LOP) refers to a delegate of the network OpenID provider (NetOP).
It is constructed with the Dual-Application-Architecture and stores the long-term secret on the
UICC part.
Mobile Application (MA) refers to the user interface of the LOP, which also provides the
HTTP interface to the browser.
UICC Applet (UA) refers to the applet, which performs the crypto operations and storage of
shared secret.
1. The user browses the RP with the Browser and the RP accepts the Smart OpenID as
authentication’s mechanism. The Smart OpenID identifier is in form of URL such as
user.id.example.
2. After receiving the identifier the RP discovers the NetOP and send the association
request with the user’s identifier to the address id.example. The NetOP looks up the
shared long-term secret (LTS) for the received identifier and creates an association
handle (AH) in form of an ASCII string of 250 chars. With the key derivation function
(PBKDF2), an association secret Sn for this session will be generated:
Sn = PBKDF2((HMAC-SHA1/HMAC-SHA256, LTS, AH, dkLen))
where
- HMAC-SHA1 or HMAC-SHA256 is the pseudorandom function
- LTS: long-term secret as the master password
- AH: association handle (an ASCII string of 250 chars) as the salt
- dkLen: length of the Sn
3. The NetOP returns the association secret Sn and association handle AH to the RP
inside the pre-established secure tunnel (SSL/TSL).
4. The RP receives the Sn with AH and then sends a HTTP redirect with the AH and
assertion parameters (AP) to the local OpenID provider.
5. The LOP is activated and the user interface appears. The user identifier, RP address
and other information are shown and the user will be prompted to input the PIN. After
the successful local verification the mobile application tries to open a logical channel
with the UICC applet. Using the opened channel the MA sends the AH and AP to the
UA.
6. The UA calculates the association secret Sn’ with the AH and LTS:
Sn’ = PBKDF2(HMAC-SHA1/HMAC-SHA256, LTS, AH, dkLen)
Then it signs the AP with the Sn’:
S_MAC = HMAC(Sn’, AP)
and sent it back to MA in APDU.
7. MA receives the signed assertion and sent to the Browser with the HTTP interface.
8. RP receives the signed assertion and verifies it with the Sn. After a successful
verification the user is logged on.
4.3.2 Privacy Extension
1. Using Group Secret (user obtains from the MNO) to log in the forum, this keeps the
user’s privacy from the RP
2. Using Group Secret (Age > 18, watch game, movie trailer) to log in RP, which keeps
the user’s privacy from both RP and OP?
4.3.3 Security Analysis
Since the Smart OpenID uses the Digest Access Authentication plus a local PIN verification,
no plan-text password will be sent. In case of loss or theft the user can contract the MNO to
forbid the lost UICC as the secure anchor for Smart OpenID. As a Two-Factor-Authentication,
the security could be even increased with other methods including biometrics.
The phishing is possible by a malicious RP, which address is intended designed to be very
similar as the correct one. The attacker RP can be invoked by either clicking the hyperlink in
an Email from the attacker or typing mistake. The RP forwards the users instead to the real
NetOP but to an imitation. On one hand the user should be aware that the mobile application
UI is not opened, which indicates the phishing attacks. On the other hand, the Smat OpenID
does not use the username and password authentication mechanisms. Therefore the
eavesdropping of password can be avoided, which prevents the phishing attacks. The attack
scenario is depicted in the Figure x.
In addition to the phishing attack, MITM attack is another serious issue for OpenID. Suppose
the network DNS is compromised and the MITM attacker can impersonate the network
OpenID provider. Assume the attacker knows the identifier of the victim but does not possess
the UICC, which contains the credential belongs to the identifier. The attacker tries to log in
the RP with the victim’s identifier and tampers the discovery process of the RP. Then the
MITIM attacker has two options:
1. It forwards the association request to the real NetOP in order to get the association
secret with association handle. Then it passes the association response back to the RP
and waits for the RP to send the authentication request. However the RP in the Smart
OpenID protocol should always send the authentication request to the local OpenID
provider instead of the network one. Since the attacker does not have the correct UICC,
the authentication process fails.
2. Attacker generates the association secret and association handle itself and redirects the
association response to the RP. Instead of waiting for the authentication request the
attacker composes the authentication request itself and signs it with the association
secret. Although the RP can verify this signed assertion with the association secret, the
authentication response lacks the session id, which is generated by the RP and should
be sent to the LocalOP.
Therefore the Smart OpenID is immune to the MITM attacks. Figure x depicts the MITM
attack for Smart OpenID which is similar to the situation in section xxx.
Local OP = UICC App + Mobile App
UICC App
Mobile App
Browser
MITM
RP
Net OP
Auth Request(OpenID identifier)
Discovery and Association
Association
Response(S, assoc_handle)
Signed Assertion
MITM attack detected
Regarding the Session Swapping protection the main countermeasure is to bind the RP’s
session to the browser, which replies on the implementation of the RP. Since all the complete
authentication processes with Smart OpenID should invoke the mobile application UI to
verify the user locally, it’s easier for the user to identify that if a Session Swapping attack
happens, when she is not prompted to do the local authentication with the PIN input and the
RP redirects to the logged web page automatically.
4.3.4 Threats Modeling
a. Assets
Smart OpenID Identifier:
 Authenticity (AS01): it refers that the identifier and relevant credential (longterm secret, local PIN) must be created by the claimed issuer and assigned to
the claimed user
 Integrity(AS02): the credential for the identifier must be kept unchanged and
secret from unauthorized party
User:
 Identity(AU01): the credential must not be stolen or disclosed to unauthorized
parties
 Privacy(AU02): it refers that the private data (birthday, credit card number etc.)
must not be stolen or disclosed to unauthorized parties
LocalOP:
 Availability(AL01): the authentication service must be assured for and only for
the authorized user
NetOP:
 Availability(AN01): the authentication service must be assured for and only for
the authorized user (Replay Attacks ?, DoS)
RP:
 Availability(AR01): the authentication service must be assured for and only for
the authenticated user (Replay Attacks ?, DoS)
 Authenticity(AR02): it refers that the RP and the user must be who they claim
they are
b. Threats
Smart OpenID Identifier:
 TS01: Fake identifier and credential from the unauthorized issuer
 TS02: Compromise of the credential by the attacker (attack UICC)
User:
 TU01: Phishing of credential
 TU02: Loss or theft of the credential (UICC)
 TU03: Privacy violation (Group identification)
LocalOP:
 TL01: Denial of Service
NetOP:
 TN01: Denial of Service
 TN02: Man-in-the-middle
 TN03: CSRF?
RP:
 TR01: Session Swapping
 TR02: Replay
 TR03: MITM
 TR04: Malicious URL
c. Vulnerabilities
V01:
 Related Threat: TS01 (Fake identifier and credential from the unauthorized
issuer)
 Affected Asset: AS01 (Authenticity)
 Description: The Smart OpenID must be issued from the authority party and
thus is bound to the claimed user. Attacker tries to issue a fake identifier to
cheat the RP and make it believe that the user with the fake identifier is the
claimed one.
 Countermeasure: The identifier and credential must be stored on the UICC of
the user. It can be executed either in the pre-personalization process before the
user receives the UICC or using the Over-The-Air framework to transfer onto
the UICC. In this way the unauthorized issuing of identifier can be avoided.
V02:
 Related Threat: TS02 (Compromise of the credential by the attacker)
 Affected Asset: AS02(Integrity)
 Description: The credential for the identifier in Smart OpenID contains two
parts: long-term secret and local PIN. The attacker may compromise the UICC
or intercepting the communication to explore this.
 Countermeasure: The UICC security mechanism ensures that the unauthorized
party cannot read the stored information directly from it [TODO]. Since the
Smart OpenID uses the Digest Access Authentication, the long-term secret will
never be sent directly. The association secret is derived from the long-term
secret the association handle using PBKDF2, which is not guessable [TODO].
Additionally only the authorized mobile application, which must be signed by
the Smart OpenID provider, is able to transmit APDU with UICC applet.
V03:
 Related Threat: TU01 (Phishing of credential)
 Affected Asset: AU01 (Identity)
 Description: If the RP is the attacker and redirects the user to the malicious OP,
then the user’s credential can be stolen.
 Countermeasure: The user does not need to input the credential on the NetOP,
instead it is required that the user needs to do a local verification, which PIN
will not be sent to the outside.
V04:
 Related Threat: TU02 (Loss or theft of the credential)
 Affected Asset: AU01 (Identity)
 Description: In case of loss or theft of the Smartphone, then the UICC may be
occupied by the attacker. Since the long-term secret and local PIN is stored in
the UICC, the attacker may violate the identity of the user.
 Countermeasure: In addition to the countermeasure in V02, the UICC can be
protected with the Two-Factor-Authentication. The length of local PIN is 4
digits to 6 digits and should have a limit of retry, which is recommended to be
3. This makes the guess of PIN very difficult [TODO]. After losing the UICC
the user can contract the MNO to forbid this UICC further as the security
anchor for the identifier, which also protects the identity.
V05:
 Related Threat: TU03 (Privacy violation)
 Affected Asset: AU02 (Privacy)
 Description: This is the common is threat for Internet service. By transmit of
private information without secure tunnel (SSL/TSL) or malicious replying
parties, the user’s private data may be disclosed or stolen.
 Countermeasure: The Smart OpenID does not provide the additional security
for transmitting of private information. But the privacy extension, which is
introduced in last section, can provide a method for the group identification.
With this feature the user is able to do the anonymous login or property (age,
language etc.) verification without the expose of private data.
V06:
 Related Threat: TL01 (Denial of Service)
 Affected Asset: AL01 (Availability)
 Description: A malicious mobile application can pretend to be the mobile part
of the LocalOP and repeatedly send the authentication requests to the UICC
part. This threat is harmful because the UICC may lose its availability to
authenticate user to login the other RPs. In addition the other UICC applets
may also be affected thus cannot provide their services.
 Countermeasure: The Open Mobile API provides the access control enforcer,
which checks the certification of the mobile application. Only the mobile
application, whose certification is signed by the Smart OpenID provider, can
be granted to access the UICC applet.
V07:
 Related Threat: TN01 (Denial of Service)
 Affected Asset: AN01 (Availability)
 Description: Different to the V06, the availability of the NetOP could be
threatened by the rogue RP, which repeatedly requests the association,
authentication.
 Countermeasure: The NetOP faces the same threat of DoS as the normal
OpenID provider [TODO]. The banning techniques or blacklist could be used
[TODO].
V08:
 Related Threat: TN02, TR03 (Man-in-the-middle)
 Affected Asset: AU01 (Identity), AR02 (Authenticity)
 Description: The MITM attacks could happen between the RP and the NetOP.
By compromising the network DNS the MITM attacker can impersonate the
network OpenID provider. The attacker could then compromise the
authenticity of the RP by violating the identity of the user.
 Countermeasure: The separation of the association and authentication and the
session id prevent the MITM attacks. The details of this countermeasure are in
section xxx.
V09:
 Related Threat: TR01(Session Swapping)
 Affected Asset: AR02(Authenticity), AU02 (Privacy)
 Description: The attacker can force the user to log in the RP with the account
controlled by the attacker. The user may not realize that the account is
controlled by the malicious party and send the private information to the RP,
which can be logged later by the attacker. This attack affects the authenticity of
the RP, since the claimed user changes. In addition the privacy of the user can
also be affected, when the user is not aware of the attack and gives the
information to the RP.
 Countermeasure: The root cause of this attack is the lack of binding between
the RP and the browser, which initialized the authentication process. The
implementation of the RP is responsible to save the nonce for this session in
the cookie of the browser, which can be checked after the RP receives the
positive authentication response. If the nonce in the cookie is identical, then
the session happens in the same browser and the user is the claimed one.
V10:
 Related Threat: TR02(Replay Attack)
 Affected Asset: AR02(Authenticity), AU01(Identity)
 Description: The attacker can sniff the positive assertion from the OP and
replay it against the same RP and log in as the victim [TODO].
 Countermeasure: To protect this attack, the RP is required to include the nonce
value in the authentication request. After receiving the positive assertion, the
nonce value in the response should be compared and only accepted once
[TODO OpenID spec].
V11:
 Related Threat: TR04 (Malicious URL)
 Affected Asset: AR01 (Availability)
 Description: Since the user’s identifier is in form of URL and RP needs to
download the URL and discovery the address of OP, an attacker could input
the malicious URL and lead to harmful attacks [TODO]. Examples from
[TODO]: exploit of internal scripts:
https://192.168.1.15/internal/auth?ip=1.1.1.1; third site scan:
http://www.target.gov:1/, http://www.target.gov:2/; and DoS attacks:
http://www.somesite.com/largemovie.flv.
 Countermeasure: RP should assume all the input is malicious until proven and
perform the validation against it. The techniques can be: black listing, white
listing, data type conversion, regular expression and XML validation
[JOGINIPALLY2007].
4.4
UICC-Based PKI
4.4.1 Overview
4.4.2 Usage Scenarios
4.4.3 Security Analysis
4.5
Conclusion
5 Implementation of Smart OpenID
5.1
Overview
5.2
Applet on UICC
5.2.1 Functional Description
5.2.2 Configuration
5.2.3 Implementation
5.3
App on Android
5.3.1 Functional Description
5.3.2 Open Mobile API in Android
5.3.3 Implementation
5.4
PKCS15
5.4.1 Architecture
5.4.2 Configuration
5.5
Test
5.5.1 Test Environment
5.5.2 Test Procedure
5.5.3 Test Result
5.6
Recommended Improvement
5.7
Conclusion
6 Summary and Future Work
6.1
Summary
6.2
Future Work
Literature
1. Union, I. T. (2011), 'The World in 2011 - ICT Facts and Figures'.
2. SmartTrust (2009), 'The role of SIM OTA and the Mobile Operator in the NFC
environment'.
3.
Ammar Alkassar, Steffen Schulz, C. S. (2012), 'Sicherheitskern(e) für Smartphones:
Ansätze und Lösungen', Datenschutz und Datensicherheit, 175.
4. Leavitt, N. (2011), 'Mobile Security: Finally a Serious Problem?', Computer 44, 11-14.
5. Networks, J. (2011), '2011 Mobile Threats Report', Technical report, Juniper Networks
Mobile Threat Center.
6. Hypponen, M. (2006), 'Malware Goes Mobile', Scientific American, 70 - 77.
7. McAfee (2011), 'McAfee Threats Report: Third Quarter 2011'.
8. Higgins, K. J. (2011), 'Smartphone Attacks Under Way',
http://www.darkreading.com/databasesecurity/167901020/security/news/231601965/smartphone-attacks-under-way.html.
9. Kaspersky (2011), 'Mobile Security Software – What It Must Do',
http://newsroom.kaspersky.eu/en/texts/detail/article/mobile-security-software-what-itmust-do.
10.
Boodaei, M. (2011), 'Mobile Users Three Times More Vulnerable to Phishing
Attacks', http://www.trusteer.com/blog/mobile-users-three-times-more-vulnerablephishing-attacks.
11.
SIMalliance (2011), 'SIMalliance Open Mobile API An Introduction'.
12.
SIMalliance (2011), 'Secure Authentication for Mobile Internet Services:
Critical Considerations'.
13.
Whitehead, M. (2011), 'GSMA Europe response to European Commission
consultation on eSignatures and eIdentification', Technical report, GSMA.
14.
Hao Zhao, S. M. (2011), 'Design and Implementation of a Mobile Transactions
Client System: Secure UICC Mobile Wallet', International Journal for Information
Security Research 1, 113-120.