Download HOVEDOPPGAVE (Master Thesis) - Department of Telematics

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET
FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK
HOVEDOPPGAVE
(Master Thesis)
Author name:
Hernández Suesta, Raúl
Title:
E-wallet with decentralized credential keepers
Abstract:
This project will be part of the ongoing research activity on a new
security architecture “Online e-wallet system with decentralized
credential keepers”, a generalization of the electronic wallet
system developed in the European research project CAFÉ early
1990s. Within this model you can leave most of the content of
your electronic wallet (credentials, keys and passwords) at the
security of your residential keeper, while roaming with your
favorite mobile terminals. The architecture is required to be
multiparty secure with respect to privacy and user freedom, and
expected to be fully scalable with multiple service organizations.
Another thesis project (Dep.Math) running in parallel with this,
will aim at analyzing the security of existing cryptoprotocols, such
as zeroknowledge authentication, within this new model. The
proposed thesis project here will advance the communication
protocol architecture for this distributed system, preferrably based
on web technology.
Beginning:
10th of January, 2003
Deadline:
30th of June, 2003
Department:
Institutt for Telematikk
Supervisor name:
Stig F. Mjølsnes
Trondheim, 30th of June, 2003
Stig F. Mjølsnes
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
“Los fascismos se curan leyendo y los nacionalismos viajando”
José Ortega y Gasset (1883-1955)
________________________________________
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Dedication
A mis padres y abuelos.
________________________________________
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Abstract
In February 2003 a Master thesis project was undertaken to research the development of an ewallet software architecture with decentralized credentials. The architecture proposed is a
generalization of the concept of an electronic wallet system developed in the European research
project CAFÉ [CAFE] early 1990s. Within this model you can leave most of the content of your
electronic wallet (credentials, keys and passwords) at the security of your residential keeper,
while roaming with your favourite mobile terminals.
The main aim for this work has been to design a software architecture based on PersonalJava
[PJ]
with emerging web technology through the Apache project and SOAP, the new RPC
paradigm for web services. The experiments were carried out at Futurum Lab (NTNU, Dept. of
Telematics) using WLAN and also demonstrating that the SOAP protocol shows a better
feasibility to implement this architecture for real e-commerce websites compared to other
middleware protocols (RMI, CORBA). Finally a real scenario based on an authentication protocol
was implemented in parallel with another thesis [GJ03] carried out at the Department of
Mathematics at NTNU.
Keywords : mobile commerce, e-wallet architecture, ubiquitous computing , digital credentials,
RMI, SOAP
________________________________________
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
How this thesis is organized
This thesis has been divided into 12 sections:
1 Motivation
An introduction to m-services and the new vision for mobile devices.
2 Related work
Background and some previous ideas that inspired this project.
3 The model
The description of our architecture and the problems to solve.
4 The platform
Reasons to choose Java as the platform for this thesis and an overview of J2ME and Personal
Java.
5 Middleware
Middleware options comparative to implement m-services from the point of view of mobile
devices.
6 Implementation
Architecture overview and a presentation of a general solution for any kind of m-service.
7 Protocol design
Real life situation (“open the door” service) to demonstrate the previous architecture exposed
in section 6. Zero-knowledge protocols as a solution to avoid to trust to third parties (the
verifier does not learn anything from the protocol).
8 Deployment
Guide to configure the service (keeper and server) based on SOAP (Apache SOAP).
9 Calling the service with Wingfoot SOAP
Description of the SOAP API for the mobile device (Wingfoot SOAP).
10 Performance
Performance analysis for SOAP
11 Discussion and further development
Some ideas to improve the architecture for future thesis.
12 Source code
Source code (Java) to implement the authentication protocol.
________________________________________
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
CONTENTS
1
2
3
4
5
Motivation
…………………………………………………………………………………………………………….. 1
Related work ……………………….…….………………………………………..…………………………….……. 2
The model
……………………………………………………………………………..……………………………… 3
The platform ………….……………………………………………………………………..…………………………. 4
Middleware …………………………………………………………………………..………….…………………….. 9
CORBA ……………………………………..………………………………………..……………………………. 9
RMI
…………..……………………………………………………………………….………………………. 10
SOAP ……………………………………………………………………………………………………………. 11
6 Implementation ………………………………………..………………………………………………………………. 12
7 Protocol design ..…………………………………………………………………………………….………………… 16
A crypto protocol for authentication ……………………………………………..…………………… 16
Authentication protocols (Zero-knowledge) …………………………………………..……………. 16
Authentication protocol ………………………………………………………………………..………….. 16
The authentication protocol based on SOAP …………………………………………….………… 18
Object lifetime ……………………………………………………………………………………….……….. 21
Message sequence ………………………………………………………………………………….……… 22
8 Deployment …………………………………………………………………………….……………………………… 24
SOAP implementation ………………………………………………………..…………………………... 24
SOAP service …………………………………………………………………….………………………..… 26
Create the Java class …………………………………………..………….…..………..………………. 26
Create the deployment descriptor ……………………………..…………………….……………..… 26
Publish the service ……..………………………………………………………………..….……………... 26
9 Calling the service with Wingfoot SOAP …………….………………………………………………………. 28
The target object URI ………………..……………………..…………………………………………… 28
Method name and parameters ……………………..………………………………………………….. 28
SOAP header data …………………………………………………….……………………………………. 29
10 Performance …………………………………………………………………………………………………………. 30
XML Performance …………………………………………………………………….…………………….. 30
HTTP Performance ………………………………………………………………………………………….. 31
11 Discussion and further development ………………………………………..………………..…………….. 32
12 Source code ..……….………………………………………….…………………………………………………….. 34
Mobile ..……..…………………………………………….……………………………………..……………. 34
Keeper ..……………………………………..………….…..…………………………………….…………… 37
Server ..…….………………………..……………….……………..…………………………..……………. 41
References ………………………………………………………………………………………………………………… 44
Appendixes
Appendix A. Jeode Runtime™ documentation ……………………………………………….…. 47
Appendix B. Java Virtual Machines for Personal Java
…………………………………….… 54
Appendix C. Java Security Policy
………………………………………………………….….. 55
Appendix D. Java on small devices
……………………………………………………………… 56
Appendix E. CORBA vs RMI vs SOAP
……………………………………………………………… 58
Appendix F. Wingfoot SOAP
…………………………………………………………………………. 60
Acknowledgements
………………………………………………………………………………………………… 66
________________________________________
NTNU – Department of Telematics
________________________________________
E-wallet with decentralized credential keepers
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
1 Motivation
Nowadays it seems that our society is experimenting fast changes towards a new revolution, a
revolution that many people have called Information Society: the ability to contact each other
and access information independently of time and place has a major impact in our lives. Along
side the growth of computing power, recent times have seen large advances in the area of
networking and communications, mainly fuelled by the explosion of the Internet.
These developments are now seeing smaller mobile devices such as mobile phones and PDAs
empowered with the capacity to connect to the Internet and exchange information.
Furthermore, with the continuing progress in computing and communication it is believed that
there will be a trend towards what is termed “ubiquitous computing” that is to say , making
many services available throughout the physical environment, but making them effectively
invisible to the user and many service providers try to give and answer to this need. One
significant business area is mobile commerce, that is, transactions that may involve intangible
goods, such as applications and information delivered to the mobile device in digital format, as
well as tangible goods that are purchased using the mobile device but delivered separately
(figure 1).
In most cases the underlaying technology used is Wireless Application Protocol (WAP) over a
network operator-provided bearer, like Circuit Switched Data (CSD) , General Packet Radio
Service (GPRS) or SMS (Short Message Service). ). Mobile digital content is predominantly being
paid for by operator billing, i.e. ordered by SMS and delivered via SMS or WAP downloads.
However, the natural evolution is the transition towards web services (figure 2) using eXtensible
Hypertext Markup Language (XHMTL) as the standard browser language and the switch to
using the TCP/IP stack as the transport layer to increase the number of remote transactions
because they provide a richer browsing experience as well as faster and more secure
connections (for example SSL over TCP/IP).
Figure 1. New vision for mobile devices
________________________________________
1
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Many companies and ICT industries are investing a lot of money in developing new services and
features to develop m-payment and m-wallets over these technologies. However the scenario is
quite confuse as there are many service providers but not a common standard to operate
altogether. The intention is to standardise the Application (Business logic) and Transport
(transport mechanism layer) in applications that can then communicate using the desired choice
of media. If these layers are well standardised, the media layer implementations may vary , as
long as interoperability is guaranteed. Actually, this need of standardization has produced the
joint of several companies into mobile commerce groups such as Mobey Forum [MF] , Global
Mobile Commerce Interoperability (GMCIG) [GMCIG] , Mobile Electronic Transactions (MeT)
[MeT] ,for promoting open, non-propietary technology standards.
Figure 2. Traditional (left) and new paradigm for m-services
The proposal for this project has been to achieve a decentralized m-payment system for small
devices using and open architecture based on web technology trying to give a model for this
new paradigm.
2 Related work
Some of the basic ideas for the development of this e-wallet architecture are taken from the
research project CAFÉ [CAFE]. The goal of CAFÉ was to develop innovative systems for
conditional access above all related to digital payment systems with electronic wallets, a role
that nowadays can be taken by PDAs or mobile phones. One of the key questions within this
project was not to force the user to trust other parties (not to deposit his credentials into the
hands of someone else - a very different philosophy from many credit card companies - ) and at
the same time to get an open system and guarantee interoperability among many service
providers , a characteristic also pursued by many mobile commerce groups (GMCIG [GMCIG] ,
MF [MF] , ...).
________________________________________
2
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
In addition to interoperability our architecture should operate with existing and new protocols
and payment instruments, , that is to say, it should be able to accommodate legacy and future
payment protocols. The architecture must not be fixed to a specific set of protocols and force
the user to use different wallets depending upon the payment instrument he wants to use.. This
idea is also present in some e-wallet architectures like SWAPEROO [SWAP]: it should be able to
accommodate legacy and future payment protocols. The architecture must not be fixed to a
specific set of protocols and force the user to use different wallets depending upon the payment
instrument he wants to use.
A previous thesis [ST03] at NTNU also studied an initial software architecture to achieve a
decentralized credentials software based on RMI. Our work moves towards a web architecture
based on an open standard like SOAP and introducing the idea of an extensible wallet
(SWAPEROO).
3 The model
The proposed solutions and standards for m-wallets include mobile terminals with creditcardslots , the creation of special, separate accounts on remote servers or using the SIM card in
GSM mobile phones as identification and storing of other credentials. However the provision of
a multitude of mobile services and credentials begins to produce scalabiliy problems for the
users.
This thesis is inspired in the ideas of Stig Frode Mjølsnes [SFM03] to achieve a new architecture
called an on-line e-wallet with decentralized credential keepers trying to provide a solution to
the practical problem of the multitude of cards, credentials and passwords that the user has to
carry so in this new system remembering all the different PINs will not be necessary.
The proposed architecture has three basic elements :
•
The credential keeper. It contains and protects the credentials (credit cards,
certificates, ...). This can be implemented with a PC connected to a switched network.
•
The wallet. It is the instrument that hides the complexity: once a user decides to make
a purchase / show his credentials to get access to any kind of service, the wallet drives
the protocol to transport information from the keeper to the service. The e-wallet
terminal should be a mobile phone, a PDA (Personal Digital Assistant) or a dedicated
hardware module. When a user needs his credentials, for example when paying for or
________________________________________
3
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
getting access to a service, the e-wallet terminal is responsible for retrieving the
credentials demanded for the service. Instead of having the credentials stored in the ewallet terminal, the e-wallet retrieves the credentials from its corresponding credential
keeper and presents them for the service application. This way the user can keep all his
credentials physically safe, but still have access to them anywhere and anytime, as long
as the e-wallet can get connected to its credential keeper.
The operations are performed according to a protocol interacting wih the user through
a graphical user Interface (GUI).
•
The service. The service is presented as a remote entity that may be an end-user,
vendor or bank that requieres a proof or identity from the user. The implementation of
the credential keeper and the service may be simetric (a PC connected to a switched
network too. Figure 3).
Figure 3. The model
These three elements are supposed to be physically distributed and communicated using
a wireless network (for this thesis a WLAN was chosen but the results are easily extrapolated
to Bluetooth or cellular packet switching like GPRS).
The thesis tries to give an answer to several questions to develop this architecture: Section 4
describes the platform (language programming) to implement the architecture. Section 5
explains middleware options (focusing on SOAP) to communicate keeper, mobile and server.
Section 6 describes the implementation for the keeper, mobile and server. Finally section 8 and
next expose a scenario based on this architecture.
4 The Platform
The language programming used to develop this architecture was Java. Sun Microsystems is
marketing java as an excellent platform for developing wireless applications because of three
main advantages:
________________________________________
4
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Security
Because Java applications are executed in a virtual machine architecture, they are safe from
causing harm to the host device. At worst, the applications can bring down the virtual machine
as Java VM use a security model known as the “sandbox” to prevent application from access
sensitive resources on the host.
Robustness
Features such as garbage collection and the exception mechanism improve the robustness of
application development.Additionally, the absence of direct memory manipulation and strong
typing generally means Java applications are less likely to fail.
Portability
With wireless devices varying highly in system configurations, portability is an important
advantage. Application need only be written once and then can be theoretically distributed to
any Java enabled device. Portability is more critical in embedded or mobile devices with small
footprint because unlike desktop systems no one operating environment dominates the
market.The range of processors and specialised operating systems makes the environment
across these devices much more diverse (Symbian, PalmOS, WinCE , …)
These advantages are particularly important in considering the possibility of dynamic “over-theair” deployment of wireless applications for e-wallets. When downloading applications, users will
expect to be able to have confidence that the program will not cause harm or disruption to their
device , thus the security advantages of Java become essential. Furthermore, due to the
multitude of wireless devices,it would be almost impossible to write a single application that
could be downloaded and used by everyone, especially without the need for additional
configuration. Java makes the application portable easily .The idea is simple: Java technologybased software can work just about everywhere. Java technology components don't care what
kind of computer, phone or operating system they run on (“write once run everywhere”).
There are two main platforms to program Java applications with mobile devices (figure 4):
•
Java 2 Micro Edition (J2ME) [J2ME] is Sun's version of Java aimed at machines with
limited hardware resources such as PDAs, cell phones, and other consumer electronic
and embedded devices. J2ME is aimed at machines with as little as 128KB of RAM and
with processors a lot less powerful than those used on typical desktop and server
________________________________________
5
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
machines. J2ME actually consists of a set of profiles (MIDP , PDAP , …). Each profile is
defined for a particular type of device -- cell phones, PDAs, etc. -- and consists of a
minimum set of class libraries required for the particular type of device and a
specification of a Java virtual machine required to support the device.
•
PersonalJava [PJ] is intended for a much more general application environment than
J2ME. The target devices for Personal Java have up to 2 MB of ROM and at least 1 MB
of RAM available for the Java platform itself (high end devices), with more required for
application software. Some of the larger PDAs and communicator devices, such as the
Compaq iPAQ and the Nokia 9210 cell phone, are currently using the PersonalJava
environment.PersonalJava is based on JDK 1.1.8 and includes a fully featured Java VM.
The specification designates each of the core JDK 1.1.8 packages as required, modified,
or optional. Similar designations may also be applied to individual classes and methods.
A required package must contain all of the classes from its JDK 1.1.8 counterpart, and
each class must be a full implementation. However, many developers complaint about
PersonalJava because it is not a good platform to develop secure communications
(absolutely
necessary
for
e-wallet
architectures).
The
most
popular
SOAP
implementations, Apache SOAP [ASOAP] and GLUE [GLUE] are not supported either):
Personal Java is based on JDK1.1.8 and it does not support RMI over SSL nor JSSE
(Java Secure Socket Extension) or JCE (Java Cryptography Extension) so many
developers are expected to use CDC [CDC] as a migration path to the Java 2 platform
(CDC is based on JDK1.2).
Figure 4. J2ME Stack and Personal Java Stack
The development of the application was done using a Compaq iPaq 3870 so the only option was
Personal Java although it would have been more appropiate CDC (Sun’s reference
________________________________________
6
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
implementation is not still avaiable for devices with Strong ARM processor like the iPaq) as it
supports JDK1.2.
The next step is the choice of a Java Virtual Machine that supports the Personal Java
specification. The previous thesis for this work [VS03] has demonstrated that the Jeode Virtual
Machine [JEODE] shipped together with the Compaq iPaq 3870 and therefore free of charge
works fine to run Java applications. One of the most interesting features of this virtual machine
for the aim of this new thesis was the possibility of using Java Plug-in technology to install
dynamically Java applications: in the previous thesis, the java application was launched from a
command line program so the code is static but now, using Jeode plug-in technology it is
possible to execute a different Java code depending on the type of transaction or protocol
defined by the service.
This feature is specially interesting for the development of e-wallets: many commercial efforts
deal with implementing extensible digital wallets that are capable of inter-operating with
multiple instruments and protocols so this technology lets accomodate all of the user’s different
payment instruments. This is one of the most important features for more e-wallet
specifications : as banks and vendors develop new financial instruments, a digital wallet shold
be capable of holding new financial instruments and making payments with this instruments.
For example, a digital wallet should be able to “hold” a user’s credit cards and digital coins, and
be able to make payments with either of them , for example using SET for the credit card and
using a digital coin payment protocol in the latter case.
Many existing commercial digital wallet implementations are not extensible.They support
limited, fixed sets of payment instruments and protocols, or require extra coding effort to
support each instrument and protocol combination. In this scenario, end-users may need to use
different wallets depending upon the payment instrument they want to use, and may even need
to use different wallets to make purchases from different vendors.The CyberCash wallet, for
example,only supports payments using certain credit cards and “Cybercash Coins” [CaC]
.Similarly, DigiCash’s ecash [DCE] Purse only supports ecash issued by a set of issuer banks .
They are also efforts to build digital wallets that support multiple financial instruments and
payment protocols such as the Java Wallet [JAW].
The wallet architecture we propose can interoperate with multiple existing and newly developed
instruments and protocols. It is supposed that the user has a collection of applets for different
available protocols at the keeper. Every time the user requires and e-wallet service it is possible
________________________________________
7
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
to download an ad hoc applet for the specific service through an applet dispatcher installed on
the keeper.
The application is executed as a Java applet like an interactive program written in the Java
language which run from within a Web page and it is executed bypassing the web browser in
the mobile device. The deployment of the application is similar to the Over-The-Air (OTA)
mechanims for mobile phones (now instead of downloading a Java program called “midlet”, an
applet is downloaded) so it is easy for a user to download and install it, in a process called
provisioning (figure 5).
Within this architecture (figure 6), the applet will establish two network connections (keeper
and service) so it is also important to emphasize that the security policy defined in a java.policy
file must be modified to grant permissions (this file is located in the folder $JDKROOT/jre/lib/security).
Figure 5.Over-the-air provisioning
Figure 6. Architecture overview
________________________________________
8
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Jeode has been implemented as a plug-in to various versions of Microsoft's Internet Explorer,
including Pocket IE, on Windows CE.
5 Middleware
CORBA
The Common Object Request Broker Architecture (CORBA) is a well established open standard
for distributed object computing defined by the Object Management Group [OMG] with more
than 700 members including NTNU. CORBA allows methods on remote objects to be invoked
regardless of the language the objects were written in or what operating system exists on the
server. The communication is achieved through an Object Request Broker (ORB) that exists on
both the client and the server to mediate the communication hidding the complexity of
heterogeneous services (figure 7).
Figure 7. CORBA architecture
This platform contains more advanced features than the next middleware options studied,above
all interesting for large enterprise applications including at once request fault tolerance and load
balancing but a trade off of this architecture is that CORBA requires the ORB at the client end
to have a large footprint so this makes CORBA generally unsuitable for small devices.
Although some companies like Hewlett-Packard, Lucent Technologies and Sun Microsystems
have developed minimumCORBA [MC], ( a subset of CORBA designed for devices with small
footprint like PDAs or mobile phones) and the existence of embedded ORBs (eORBs) for small
devices such as TAO [TAO], Orbacus/E [ORB/E] or ORBExpress [ORBE]) seems that CORBA has
gone quiet and everyone has gone up a level to the use of XML for system integration (by
SOAP) leaving the role of CORBA for enterprise computing.
________________________________________
9
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
RMI
Remote Method Invocation (RMI) is a Java library that allows Java programs to call certain
methods on a remote server.RMI creates the illusion that this distributed program is running on
one system with one memory space holding all the code and data used on either side of the
actual physical connection.
RMI is like CORBA in that it defines a platform-distributed, object-based computing. However,
because it is just RPC for Java, that is to say the programming language used must be only
Java (parts of a single program run in a Java virtual machine on a local client while other parts
of the same program run on a Java virtual machine on a remote server).
When using Java RMI objects act as client and server applications. The server application must
register in an RMI-registry located either on the same computer or another computer with an
address reference to be available for clients to contact it. The client contacts the RMI-registry
and obtains a reference to the server application object. With the reference obtained the client
uses a proxy object called a stub to access the distributed server object’s available methods. At
server side the server object uses a skeleton as proxy to the client.
Figure 8. RMI object model (left) and architecture (right)
Deploying services using RMI for small devices is relatively simple as it is included as a package
in the Personal Java specification. JDK1.1.x includes core support for RMI however “secure
RMI” (RMI's use of serialization leaves encryption and decryption to the lower network
transport) typically is done using SSL with JSSE API (RMI over SSL) and it is not available
within Personal Java as PJ is based on JDK1.1.8 and JSSE requires Java 2 (JDK1.2) at least
(obviously there is not a RMI implementation for MIDP profile).
An example of a “show credentials” scenario for the Compaq Ipaq using RMI can be found in
the previous work for this thesis [ST03].
________________________________________
10
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
SOAP
As the name suggests, the Simple Object Access Protocol (SOAP) was designed as a simplified
mean of making remote procedure calls across the internet. SOAP is gaining much attention in
the field of distributed systems because it also underpins the new
Microsoft’s .NET
architecture.For this simplicity and easiness of integration with web services, it was the
middleware option chosen for this thesis and it will be examined with more depth.
The protocol is primarily intended to be used over HTTP (HTTP POST), but it can also be used
with SNMP and other application layer protocols. The philosophy for sending objects between
server and service is the same as RMI (serialization). SOAP uses XML for serializing objects
between client and server (generally RMI is faster than SOAP because RMI serializes objects
into a stream of bytes instead of ASCII like XML which produces more overhead)
and for
binding the remote method (for every service you must create a deployment descriptor, which
is an XML file that contains information about the service and the remote methods that are
avaiable) so SOAP solves easily than RMI and CORBA the problem of interoperability
(everything can generate XML).See also appendix E.
One advantage of using SOAP over HTTP is that it easy for the developer to integrate it into
existing network infrastructure that is designed for allowing clients to retrieve web pages. The
developer does not need to modify the existing network and web services model to create
SOAP applications (For this thesis the keeper was implemented with a Tomcat server configured
to serve Java Server Pages and deal with SOAP requests through the same port. See figure 9)
and has the potential to create a transparent web of services and aplications which can be
accessed from anywhere by anyone on demand.
Figure 9. It ‘s easy to combine SOAP with web applications.
________________________________________
11
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Another advantage of using SOAP compared to other middleware is that it requires relatively
less resources to process a request and a response. This makes it possible to use it for devices
with small footprint even with the MIDP profile (vs RMI that requires at least Personal Java)
with some limitations.
There are two main distributions of SOAP suitables for deploying mobile applications*: ksoap,
from Enhydra and wsoap from Wingfoot.
•
Ksoap [KS]
is a subset of the SOAP 1.1 features. It is a very lightweight SOAP
implementation but it does not support datatypes such as big decimals or base 64
encoded byte arrays to respect the memory constraints of J2ME (Ksoap is focus on
MIDP profile).
•
Wsoap [WS] , based on SOAP 1.1. It is tested against major SOAP server
implementations and can be used in MIDP/CLDC (kvmwsoap_1.04.jar) , Personal
Java/CDC, J2SE and J2EE platforms (j2sewsoap_1.04.jar). This was the SOAP
implementacion chosen for this thesis (PDA) working against Apache SOAP (PCs).
* both of these SOAP versions only provide a client API. There is not a server implementation of SOAP for
small devices yet.
For the credential keeper and the service the SOAP implementation chosen to work as a SOAP
server was Apache SOAP (not available for J2ME yet as it requieres Java 1.2 at least).
6 Implementation
The implementation for the creedential keeper and the server for our e-wallet architecture is a
simply PC connected to a switched network. This implementation is almost simetric as all the
request-responses are processed by the same SOAP implementation (Apache SOAP). For these
elements a web architecture was chosen dividing the application into two logical layers : a
presentation layer and an application processing layer (figure 10).
________________________________________
12
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Figure 10. Two tier architecture (presentation and processing layers)
The presentation layer is responsible for the interaction with the user and display (for example
through a Graphical User Interface (GUI) or web pages). This layer is represented by Apache
web server in the server. Using this web server, all the services can be published and the users
can access to them through a web browser (for example Pocket Internet Explorer for the PDA)
using the e-wallet device.This layer is not necessary for the keeper as all the interaction user –
keeper is driven by SOAP only.
The application processing layer is responsible for implementing the logic of the operation. For
the credential keeper this layer is represented by Java Server Pages (JSPs) and Apache
SOAP.The goal of JSPs is the simplified creation and management of dynamic web pages. A
interesting feature of JSPs is the possibility to combine pieces of Java code with HTML in the
same document , that is to say , using JSPs it is possible to generate dinamic html code so it is
easy to implement an applet dispatcher (figure 11) for downloading dinamically the applet so
this technology lets accomodate all of the different services and user’s payment instruments
since the applets are downloaded on the fly depending on the specific service.
________________________________________
13
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Figure 11. JSPs generate dynamic HTML easily.
For integrating SOAP in this architecture we have used Apache SOAP, an ongoing project from
the Apache Software Foundation. This is a Java implementation of the SOAP specification that
can be hosted by servers that support Java servlets. There were four main factors to choose
this implementation: it supports a good deal of the specification, it has a reasonably large user
base, the source code is available, and it's free. Apache SOAP can be used as a client library to
invoke SOAP services available elsewhere or as a server-side tool to implement SOAP accessible
services. As a client library it provides an API for invoking SOAP RPC services as well as an API
for sending and receiving SOAP messages. However, we have used SOAP as a mechanism to
write new RPC accessible services or message accessible services hosted by a servlet container
as it is not possible to use it like a client (mobile) library (Apache Tomcat requires JDK1.2 and
the Jeode virtual machine is JDK1.1.8).
Apache SOAP was developed at a time when there were no standards for a SOAP API. The
SOAP specification doesn't address language bindings, so the implementors were forced to
come up with their own APIs. More recently, the Java community has been working on standards for SOAP-based messaging and RPC APIs, known as JAXM [JAXM] and JAX-RPC [JAXR] ,
respectively.
They will be implemented by Axis [AXIS], which is the next-generation Apache SOAP
implementation. It would be ideal to use JAXM and JAX-RPC for this thesis since they will
almost certainly replace the APIs developed for Apache SOAP 2.2. However, these two APIs are
________________________________________
14
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
new, and are not yet ready for the production world. The specifications for JAXM and JAX-RPC
are in public review, and therefore are expected to change before they're complete.
Although Apache SOAP can be hosted by a variety of server technologies, we have chosen
Apache Tomcat (Version 4). The use of Tomcat has no real impact on the architecture so it is
possible to select some other server technology.
Now that all the elements have been described, it is possible to give an overall view of our
architecture completing figure 6 .The applet dispatcher has been implemented with a Tomcat
JSP/Servlet engine that downloads applets to the mobile device on demand depending on the
service selected by the user. Once the applet it is downloaded in the mobile, it performs all the
necessary operations using SOAP as middleware.
Figure 12. Software Architecture.
We can describe the operation into the following steps:
[1] Service discovery: The user browses looking for a service. Once the service is found, the
user downloads the applet that “understands” the protocol for that specific service [2].
[2] Provisioning: The Tomcat engine must be able to generate dynamic HTML code through
JSPs. A JSP must process the request from the browser and get the parameters that show the
applet needed by the service.
[3] Processing : The applet drives the protocol according to the m-service demanded.
________________________________________
15
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
7 Protocol Design
A crypto protocol for authentication
Once the elements of the architecture have been presented, the scenario chosen to demonstrate this architecture using a common real life situation was the “open the door” service. This
situation is described on Mjølsnes paper [SFM03] : the user is about to enter the door to his
company carrying only his mobile on-line wallet device. The credential corresponding to the
door access has been issued in the form of a key but the user does not carry this key with him,
it is localized at the credential keeper at home so the user connects to the door access control
with his mobile device using in this case WLAN. The key distribution in this scenario it is also
very easy because it is a basic one-to-one association between credential keeper and mobile
agent.
Figure 13. “Open the door” scenario
Authentication protocols (Zero-knowledge)
Basically this scenario describes a typical authentication process: the user must be identified to
access to some service, that is, show his credential. User authentication is essential in many
networked applications, particularly in security critical applications such as the electronic
payment systems. The most popular mechanism for user authentication is the use of the
passwords but password authentication is lacking many features necessary for secure
applications as badly chosen passwords are easy to guess and in many scenarios can be
intercepted and re-used for impersonating legitimate users.
Zero-knowledge protocols, as their name says, are cryptographic protocols that do not reveal
the information or secret itself during the protocol, or to any eavesdropper. They have some
very interesting properties, e.g as the secret itself (credentials) is not transferred to the
verifying party, they cannot try to masquerade the user to any third party. The verifier does not
learn anything from the protocol. This is the central zero-knowledge concept. No knowledge
(zero amount of knowledge) is transferred.
Authentication protocol
________________________________________
16
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
The protocol implemented is a Schnorr’s modified authentication proposed by another thesis
work [GJ03] suitable for our decentralized architecture (Figure 14).
1. p is a large prime, i.e. p≈ 21024.
2. q is a large prime divisor of p – 1, i.e. q ≈ 2160.
3. g ∈ Zp* has order q.
4. t is a security parameter such that q > 2t. For most practical applications t = 40 will provide
adequate security.
We will also use two hash functions, h as ‘Message Detection Code, MDC’ and hk as ‘Message
Authentication Code , MAC’ being k a secret shared between keeper and mobile. S and P= gS
mod q represent the keeper’s private and public key respectively.
The cryptographic operations (modular arithmetic) are performed by Java Math API (core API)
that provides classes for performing arbitrary-precision integer arithmetic (BigInteger). The
hashes are calculated using the Java Cryptography Extension (JCE) [JCE] , a set of packages
that provide a framework and implementations for encryption, key generation and key
agreement, and Message Authentication Code (MAC) algorithms. The Mobile is a simple booster
between keeper and service, but it is also necessary a cryptographic API to perform the MAC
operation (β) .The option chosen was Bouncy Castle Crypto API [BC] as JCE requires JDK 1.2 at
least.
Figure 14. Proposed authentication protocol
This protocol also takes some advantages from Schnorr [HAC]:
•
The design allows pre-computation , reducing the real time computation for the
claimant to one multiplication modulo a prime q. It is thus particularly suitable for
limited computational ability like cell phones and PDAs.
________________________________________
17
NTNU – Department of Telematics
•
E-wallet with decentralized credential keepers
A further important computational efficiency results from the use of a subgroup of
order q of the multiplicative group of integers modulo p, where q | (p-1); this also
reduces the required number of transmitted bits.
•
Finally , the protocol was designed to require only three passes (witness , challenge
and response) and a low communication bandwidth (compared to other zero knowledge
protocols, e.g Fiat-Shamir).
The authentication protocol based on SOAP
All of these actions have been designed as finite state machines (specifically three finite state
machines : keeper, mobile and server). Finite State Machines (FSMs) have become a standard
model for representing object behaviour and numerous specification notations are based on the
concept of FSMs (for example UML and SDL incorporate FSM notations).
For the Schnorr protocol we have defined a finite set of states and every state has associated a
set of actions, for example calculate witness, throw a challenge , check the response …
(basically all the Schnorr operations are performed by the keeper and the server and the mobile
device is almost a booster between keeper and server although it has also been implemented
as a state machine). The events that produce transitions (inputs) and the outputs are SOAP
calls carrying the appropriate parameters.
All the Requests and Responses have a common format, a header field, showing the kind of the
packet and the data field containing the payload.
Figure 15. Packet
We have chosen the following notation for the calls : the first letter indicates if the request /
response is / comes from the keeper or the service. The second letter indicates if it is a request
or a response and the small letter indicates the state (i.e KQi and SQi indicate requests (Q) to
the keeper (K) and the server (S) respectively, analogously KRi and SRi indicate responses (R)
to the keeper and the server for the state i.
________________________________________
18
NTNU – Department of Telematics
The following figures show the specific
E-wallet with decentralized credential keepers
type for the requests and the responses (figure 16)
and the message sequence (figure 17).
Figure 16. Request and Responses
Figure 17. Message sequence for the authentication protocol based on the SOAP
primitive.
________________________________________
19
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
The state machines have been implemented as Moore FSMs:
Figure 18. Moore FSM
Figure 19. Mobile FSM
Figure 20. Keeper FSM
________________________________________
Figure 21. Service FSM
20
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Object lifetime
The lifetime of an object is an important part of any distributed system, and is referred to as
service scope or service activation.
In SOAP systems based on HTTP, there are generally three service activation models:
•
Request-level service activation
For each request made on a given service object, a new instance of the object is created
that persists only until the request is complete. This kind of service activation is useful for
service objects that don't maintain state.
•
Application-level service activation
A single instance of the service object handles every method invocation for the entire lifetime of the service application. This kind of activation can be used for services that maintain
state or that place a large burden on resources during object creation.
•
Session-level service activation
A single instance of the service object is used for all method invocations for the lifetime of
the session. It's possible to implement sessions specific to your own applications by doing
things like generating and passing tokens, or you can take advantage of existing
approaches like the use of cookies (Actually, sending transport-specific data such as a
cookie is probably not such a good idea, because it binds SOAP to a particular transport.
Some other transport-independent session data would be more appropriate).
The SOAP specification doesn't define any requirements or behaviours for service object
lifetime; there are no real requirements for SOAP implementations to support the three models
described here (these activation models are found outside of SOAP). Anyway it is easy to
implement application-level or session level service activations using SOAP as it is possible to
declare global variables that keep track of method calls during the lifetime of the object, in this
case, the global variable “state” to maintain the state among calls (just declaring it as a global
variable in Java, immediately after the class declaration. See source code). This solution is really
simple if we compare it to other choices to make the “tracking”. For example, using RMI for
every method invocation, the variables declared are beginning again to their initial values.
Another possible solution using RMI is the possibility of using callbacks from the server to the
client (it is similar to asynchronous method invocation where the invoker specifies a callback
object that will be notified when return values are ready from servers completing the
invocation. In this case the callback object would store the state ).
________________________________________
21
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
However this solution is not neither as efficient (it generates additional callback messages) nor
as simple (on the client side the roles of client and server are mixed because the client must
invoke methods and at the same time, process the callbacks).
Working with java, another interesting option to keep the state of an object independently of
the middleware is object serialization. Serialization involves saving the current state of an object
to a stream and restoring an equivalent object from that stream. The purpose of using
serialization was to achieve persistence (the stream functions as a container for the objects that
may be used to prepare an object for transmission from one computer to another (RMI) or
store it after the current session is finished. In both cases the information stored can be used
later to construct an equivalent object containing the same data as the original).For example
writing the object to a file and later restoring it. However this option was dismissed since
serialization is not an efficient mechanism working with FSMs where the variable state should
be read and overwritten over and over again taking into account the slow I/O access).
Message sequence
The whole description for the protocol is showed below (figure 22).
The Schnorr operations described in figure 15 are showed together with the appropriate state
( in brackets ). The messages in red are possible errors. Note also the three steps described
previously (section 7).
Service Discovery
First of all the user browses until finding a web service. The web service is accessed through
the use of HTTP using a web browser. For our example, the user enters the name of the door
to open using a HTML form (source code,openTheDoor.html)
Provisioning
Next, the user downloads the applet for that specific service. The user must unlock the keeper
and retrieve the identification code of the service , process it and download the java applet that
“understands” that service. At the same time it is possible to download additional java classes
using the field <PARAM> (in our implementation, the mobile device also downloads on the fly
all the necessary classes to talk SOAP - j2sewsoap_1.04.jar - , and the Bouncy Castle ‘s classes BC.jar -
since they are not included in the Jeode VM core classes). These operations are
________________________________________
22
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
performed using JSPs (source code, keeper.jsp).If needed, all this process can be easily done
over SSL if the Tomcat server is configured properly.
Processing
Finally all the operations are performed by the applet hiding the complexity for the user.
Figure 22. Message sequence diagram for the authentication protocol based on the SOAP
primitive.
________________________________________
23
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
8 Deployment
For the validation of the experiment, the keeper and the server were implemented with two PC
and Linux and Windows 2000 as operating systems respectively at Futurum lab (NTNU,
Department of Telematics).
Figure 24. Keeper and Service
SOAP implementation
The SOAP implementation chosen for the keeper and the service was Apache SOAP. Before
using the Apache SOAP project, we must acquire the necessary components to execute SOAP
services:
•
Java 1.2 or higher, and a servlet engine supporting version 2.1 or higher of the Java
Servlet API (such as Apache Tomcat, for example).
•
JAXP compatible, namespace aware XML parser
•
JavaMail (mail.jar) and the JavaBeans Activation Framework (activation.jar)
•
•
XMI encoding requires use of Java 1.2.2 and Xerces.
SSL (HTTPS) support requires Java 1.2.1 or later and the Java Secure Socket Extension
(JSSE).
Although Apache SOAP works with Java 1.2, it is advisable to work with Java 1.4 as many of
the necessary classes are already included within Java 1.4 core classes (JAXP and JSSE)..The
rest of the classes are provided by Apache Tomcat core classes:
JavaBeans Activation Framework:
Packaged with Tomcat under <TOMCAT_HOME>/common/lib/directory.activation.jar v1.0.1
Xerces:
Packaged with Tomcat under <TOMCAT_HOME>/common/lib/ directory.xerces.jar v1.4.2
________________________________________
24
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Once we have all of these items, we need to extract the SOAP archive to a local directory. We
then need to add each of the previously mentioned .jar files to the classpath, including soap.jar,
which comes packaged with the SOAP archive.
Before starting Apache SOAP we must configure the CLASSPATH environment variable to locate
all the classes. This could be easily done using two simple scripts (.bat file for the service –
Windows 2000 – and a shell script for the keeper – GNU/Linux-):
Keeper:
!#/bin/sh
# Java Environment for TOMCAT + SOAP by Raul Hernandez (GNU/Linux)
#Java Environment
JAVA_HOME="/usr/local/j2sdk1.4.1_01/"
#Tomcat & SOAP
JavaMail="/usr/local/jakarta-tomcat-4.1.18/common/lib/mail.jar"
JavaBeansActivationFramework="/usr/local/jakarta-tomcat4.1.18/common/lib/activation.jar"
SOAP="/usr/local/soap-2_2/lib"
TomcatClassesForSOAP="/usr/local/jakarta-tomcat-4.1.18/webapps/soap/WEBINF/classes"
#CLASSPATH
CLASSPATH="$JavaMail:$JavaBeansActivationFramework:$SOAP:$TomcatClassesForSOAP
:$wsoap"
export JAVA_HOME CLASSPATH
Server:
@echo off
REM Java Environment for TOMCAT + SOAP by Raul Hernandez (Windows 2000)
set JAVA_HOME=C:\jdk1.4
set SOAP_HOME=C:\thesis\tomcat
set JAVA_MAIL=%SOAP_HOME%\common\lib\mail.jar
set JAVA_BEANS_ACTIVATION_FRAMEWORK=%SOAP_HOME%\common\lib\activation.jar
set SOAP=C:\thesis\soap\lib
set TOMCAT_CLASSES_FOR_SOAP=%SOAP_HOME%\webapps\soap\WEB-INF\classes
set CLASSPATH=%JAVA_MAIL%;%JAVA_BEANS_ACTIVATION_FRAMEWORK%;%SOAP%;
%TOMCAT_CLASSES_FOR_SOAP%
________________________________________
25
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Once the environment is configured properly, there are several ways to deploy a SOAP project
to Tomcat. Of these methods, we are going to perform the easiest, which is simply to copy the
soap.war file to the <TOMCAT_HOME>/webapps/ directory.
The SOAP service
Writing an RPC-based SOAP service is a very simple process that can be broken down into three
steps.
•
Create the Java class that contains the SOAP service to publish.
•
Create a deployment descriptor that describes the service.
•
Publish the service.
Create the Java class
A SOAP service can be just about any Java class that exposes public methods for invocation.
For the keeper and server, the service is implemented by the Schnorr class (Source code,
Schnorr.java).
The class does not need to know anything about SOAP, or even that it is being executed as a
SOAP service.The only restriction is that the method parameters of a SOAP service must be
serializable.
Now,
to
make
these
classes
availables,
we
build
and
copy
them
into
the
<TOMCAT_HOME>/webapps/soap/WEB-INF/classes/keeper and <TOMCAT_HOME>/webapps/
soap/WEB-INF/classes/server respectively.
Create the deployment descriptor
The next step in creating a new SOAP service is to create a deployment descriptor describing
the SOAP service. This description is required for the service to be published as an Apache
SOAP service. The deployment descriptor is an XML file that contains information about the
service, the Java class that implements the service and method names that are exposed by the
service.
These method names have to match the corresponding methods in the Java class that
implements the service because Apache SOAP uses dynamic class loading and Java reflection in
order to make method calls.
Our deployment descriptor is an identical XML for keeper and server (see Source code, dd.xml)
Publish the service
________________________________________
26
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Next, we need to use the deployment descriptor to publish the service. At this point, it is
necessary to start Tomcat if it is not running already (using the script startup.sh under
<TOMCAT_HOME>/bin (keeper,Linux) and startup.bat under the same directory for the server
(Windows 2000).Apache SOAP includes a Java application that can be used from a command
line
to
deploy
a
service.This
application
is
called
the
Service
Manager
Client
(org.apache.soap.server.ServiceManagerClient). The Service Manager Client can deploy ,
undeploy, and list services (all these commands must be run from the directory that contains
the deployment descriptor file).
We can deploy the Schnorr service:
java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter
deploy dd.xml
(this is the deployment for the server, the keeper is identical taking into account that it listens
on port 80).
This command takes three parameters: the URL to the SOAP server, the command deploy, and
the file containing the deployment descriptor.
After deploying the service, it is possible to verify it by calling the the service manager client
again:
java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter list
The first parameter is the same as before: the URL of the Apache SOAP RPC router.If the
service has been successfully deployed, the response will be:
Deployed Services:
Urn:SchnorrAuthentication
Apache SOAP persists the information for the deployed services, so if the server that is hosting
Apache SOAP is shut down and restarted at a later time,the services will still be available.It
does not, however, persist the state of the objects that implement those services; they will start
as if for the first time, with a new lifetime.
________________________________________
27
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
9 Calling the service with Wingfoot SOAP
All the methods and calls exposed (keeper and service) follow the SOAP RPC model.Although
SOAP is not limited to a particular style of distributed computing, it lends itself to a remote
procedure call (RPC) model: according to the SOAP specification, one of SOAP's design goals is
to encapsulate and exchange RPC calls. This approach maps very nicely to Java programming
because method calls on Java objects can be easily translated to RPC calls.
Basically , FSMs (keeper and service) are just Java Methods (SchnorrFSM) called by the mobile
using Wingfoot SOAP.In general, for a RPC method call in SOAP, we need:
•
The target object URI.
•
Method name and parameters
•
SOAP header data.
Target Object URI
The target object URI (aka URL) is, essentially, the resource address of the service that we
want to use.
Both,keeper and server use an Apache SOAP server.In Apache SOAP server,the target object
for an RPC message is soap/rpcrouter.This URI represents the resource that routes SOAP RPC
messages in Apache SOAP.
The respective URIs for the keeper and the service:
Keeper:
http://localhost/soap/servlet/rpcrouter (listening at port 80)
Server:
http://localhost:8080/soap/servlet/rpcrouter (listening at port 8080)
Method Name
The method name is the name of the method to be invoked. A SOAP method is simply a
request and an optional response. Thinking in Java,the method name is like the public method
________________________________________
28
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
on an instance of a service object. The mobile device invokes these methods at keeper and
service. Using Wingfoot SOAP, the invocations are made using the Call object.
call.setMethodName(“SchnorrFSM”);
call.addParameter(“header”,Header);
call.addParameter(“parameters”,Parameters);
SOAP Header
Processing an RPC sometimes requires information that is not part of the method.
For example, the state problem (maintain the state for the FSM) could have been solved
encoding information in the SOAP header; for example, we may try to pass cookie information
as part of the HTTP header in order to maintain the state for this method invocation. This
additional data is encoded outside the bounds of the SOAP body.
A SOAP Header element is optional (we have not used it for our implementation)
Envelope customEnvelope= new Envelope();
HeaderEntry he=new HeaderEntry(“SOAPheader”,”value”);
customEnvelope.addHeader(he);
________________________________________
29
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
10 Performance analysis
Throughout this thesis, we have emphasized SOAP as a “universal” middleware: it easily solves
the problem of a reliable, universally understood data exchange format between heterogeneous
systems using XML. Also HTTP has emerged as a simple, universally supported protocol for exchanging data over the Internet. Thus moving XML data via HTTP is an good way for distributed applications to communicate with each other.
However, the same feature that makes SOAP attractive (XML+HTTP) causes
some
performance problems that we discuss next.
XML Performance
Using XML, there is an inherent performance problem, tagged data is sent as characters: XML
messages are textual and so the sizes of its messages are significantly larger than protocols
which send binary data. Since a distinguish characteristic of cryptographic applications is the
need of representing large numbers – we have used java.math.BigInteger classes - , the
performance of SOAP is relative worse than protocols that can use binary representation like
CORBA (IIOP) and RMI (JRMP). This increase in size is from the translation of binary data into
text.
For example in Java each long data type takes 8 bytes and the string representation in XML of
a long with 16 digits takes at least 16 characters (and so 16 bytes in UTF-8) in addition to the
13 bytes for the tags <long> and </long> that uses XML. More than 3 times if we compare it
to the binary encoding.If the data is transferred using Unicode, that estimate doubles.
Although this overhead produced by XML is intrinsic to the SOAP protocol and cannot be
removed, SOAP’s interoperability across heterogeneous environments makes it attractive for a
multi protocol environment and also XML encoding and thus human readability makes SOAP a
useful protocol during development and debugging (for the development of our “open the door”
service, a network analyzer - Ethereal [ETH] - was installed at the keeper and server to debug
some error messages ).
For this thesis we have only used simple types but the XML format is also a critical factor for
serialization and deserialization. Some studies ([DAV]) reveal that serializing Java objects into
SOAP encoded XML data takes approximately ten times more memory than the binary
representation.
________________________________________
30
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
For example, during deserialization, objects are converted from a stream of bytes to their
representation in memory. Deserialization using SOAP involves parsing the XML representation
of an object and after instantiating the object using reflection. On the other hand in Java RMI
deserialization the class structure of the object being deserialized is already known. Due to the
large size of the XML representation and the need of parsing, the SOAP deserialization is
considerably less efficient.
HTTP Performance
During our experiments we looked at another bottleneck in SOAP performance because of the
HTTP implementation. This problem is also commented in other papers ([DAV]) but this time
independent of the XML encoding, it could be improved through a better SOAP implementation.
Using Ethereal [ETH] to analyze the packets we found that working with Apache SOAP [ASOAP]
the HTTP POST was split into two packets (header and body) so a better implementation should
include the header and the body in the same packet. Figure 25 shows the messages exchanged
in a procedure call between mobile and server.
Figure 25 .Event trace of Apache SOAP (left ) and improved model (right).
In conclusion, SOAP performs very poorly (i.e serialization -XML- and HTML chunking can be 6
times slower for long data types) compared
to RMI or CORBA. The Apache SOAP HTTP
implementation should also be improved (not to send multiple HTTP messages to perform one
procedure call).
________________________________________
31
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
11 Discussion and further development
The main aim for this project, a decentralized and open software architecture has been
achieved: our software architecture uses SOAP, the most standardized middleware to retrieve
the credentials from the keeper and reply to the challenges by the server and it is also an
extensible architecture: the protocols are not fixed since the mobile can download the
appropriate java code (applet/midlet) according to the service. It can also get interoperability
with proprietary protocols and evolve with new services and protocols without losing
compatibility.
Studying the environment to develop mobile services, nowadays it seems to be still in its
infancy. So far , the gap between Personal Java (JDK1.1.8) and the Java 2 platform (JDK1.2)
has been traumatic for Java programmers writing applications for devices with limited memory
resources and processor power such as cell phones and PDAs as they have in common the fact
that J2SE, the standard Java platform used on desktop systems is not supported due to the
small footprint.
The situation is further aggravated when secure communication is required (designing and
implementing suitable protocols given the limited available resources is not easy) and many
developers complain because some important issues, above all related to networking security
have not been considered: the use of “secure middleware” as RMI over SSL or SOAP over
HTTPS is not a possible option working for Personal Java as in both cases it requires the Java
Secure Socket Extension (JSSE) available only for the Java 2 Platform.
Looking at the middleware options, the clear winner is SOAP: it is easy to deploy web services
and at the same time to integrate them with SOAP as middleware to perform the business logic.
SOAP is also a lightweight protocol (vs CORBA and RMI) and it is available not only for high end
PDAS like iPaq but for low end devices (MIDP/CLDC profiles) too but the main handicap is
performance: SOAP universality (XML) requires large messages due to its ASCII encoding and
some SOAP implementations also produce a high overhead in the network communication.
One particular area that could is be improved to work with SOAP is security. It is not possible to
talk about a distributed computing technology without security: CORBA and RMI rely on the
security of the hosting technology (i.e SSL) but although nowadays almost all the SOAP services
rely on that technology too, it is expected that a future version of the SOAP specification or a
separate SOAP security specification will address that issue. One interesting option to improve
SOAP security could be its integration with other initiatives based also on XML like Oasis
Consortium’ SAML [SAML] ,the Security Assertions Markup Language, an XML grammar for
________________________________________
32
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
expressing the occurrence of security events, such as an authentication events and other
standardization initiatives like XML-Dsig [XMLD], XML Digital Signatures that allow any XML
document to be digitally signed and XML-Enc [XMLE] and XML Encryption specification to allow
XML data to be encrypted and for the expression of encrypted data as XML.
Another middleware technology to investigate for m-services is JINI [JINI] , based on Java. It
offers network plug and play (a device or a software service can be connected to a network and
announce its presence, and clients that wish to use such a service can then locate it and call it
to perform tasks) and it can be used for mobile computing tasks (in fact some Pocket PC virtual
machines like Savaje [SAV] include this package) but nowadays it is only available for high end
mobile devices.
Another area to research is the service discovery: it would be interesting trying to develop mservices moving the communication from WLAN to Bluetooth as it opens new possibilities like
the Bluetooth Service Discovery Profile to discover services. Currently the JSR-82 [JSR82]
leaded by Motorola tries to hide the complexity of the Bluetooth protocol stack behind a set of
Java APIs (JABWT [JAB], Java APIs for Bluetooth) being developed through the Java
Community Process (JCP). It would be also interesting to test some proprietary solutions: some
firms like Atinav [ATV] have implemented its own Bluetooth stack and Java APIs for Windows
CE .
Further research should also test new virtual machines like NSIcom's CrE-ME VM [NVM] (beta
version) for PocketPC and the new Jeode’s VM [JVM] both including CDC compatibility (CDC is
based on CVM, “Compact Virtual Machine” , a virtual machine that supports all the features of
the full J2SE VM). Surprisingly, Sun do not provide a version of CVM for PocketPC platforms
during our study, only a reference implementation that can be compiled for Linux (strictly
speaking, only Red Hat Linux Version 6.2 is supported) and VxWorks, a real-time operating
system.
________________________________________
33
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
12 SOURCE CODE
MOBILE
[Schnorr.java]
/**
* Schnorr.java
*
* This is the applet that drives the Schnorr protocol from the iPaq
* It is modelled like a Moore FSM with five possible states (variable state).
*
* @author Raul Hernandez
* @version v1.0 10-05-03
*
*/
import
import
import
import
import
import
import
import
import
import
import
import
java.awt.*;
java.net.*;
java.io.*;
java.util.*;
java.math.BigInteger;
com.wingfoot.soap.*;
com.wingfoot.soap.transport.*;
com.wingfoot.soap.encoding.*;
org.bouncycastle.crypto.*;
org.bouncycastle.crypto.macs.*;
org.bouncycastle.crypto.digests.*;
org.bouncycastle.crypto.params.*;
public class Schnorr extends java.applet.Applet {
// Urls for keeper and service SOAP rpcrouter
String KEEPER;
String SERVER;
// key shared between keeper and mobile
final byte[] k="mySecret".getBytes();
String parameters;
int state=0;
BigInteger W;
String alpha,c,R,a2,Authorization;
String response;
StringTokenizer st;
Label label1=new Label();
public void init() {
// keeper
KEEPER="http://"+getCodeBase().getHost()+"/soap/servlet/rpcrouter";
________________________________________
34
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
// server listening on port 8080 (default Apache Tomcat port)
SERVER="http://"+getParameter("server")+":8080/soap/servlet/rpcrouter";
setLayout(null);
switch(state){
case 0:
parameters="";
response=sendData("INIT",parameters,KEEPER);
st=new StringTokenizer(response,",");
if ("OK".equals(st.nextToken())){
W=new BigInteger(st.nextToken());
alpha=st.nextToken();
state++;
}
case 1:
parameters=W.toString()+","+alpha;
response=sendData("PARAMETERS",parameters,SERVER);
st=new StringTokenizer(response,",");
if ("OK".equals(st.nextToken())){
c=st.nextToken();
state++;
}
case 2:
parameters=c+","+calculateHMAC();
response=sendData("PARAMETERS",parameters,KEEPER);
if ("OK".equals(response)){
state++;
}
case 3:
parameters="";
response=sendData("PARAMETERS",parameters,KEEPER);
st=new StringTokenizer(response,",");
if ("OK".equals(st.nextToken())){
R=st.nextToken();
a2=st.nextToken();
state++;
}
case 4:
parameters=R+","+a2;
response=sendData("PARAMETERS",parameters,SERVER);
if ("OK".equals(response))
Authorization="Authorization accepted";
else
Authorization="Authorization denied";
label1.setText(Authorization);
add(label1);
label1.setBounds(13,12,190,21);
state=0;
}
}
/**
* sendData
*
* This method sends data to a SOAP service.
*
* @param Header control header
* @param Parameters payload (data)
* @param URL (rpcrouter) where the service is listenning (keeper or server URL).
________________________________________
35
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
* @return Ok+Data / Reset
*
* @see Wingfoot SOAP (wsoap)
*
*/
public String sendData(String Header,String Parameters,String receiver){
String returnParameter="";
try {
Call call=new Call();
call.setMethodName("SchnorrFSM");
call.setTargetObjectURI("urn:SchnorrAuthentication");
call.addParameter("header",Header);
call.addParameter("parameters",Parameters);
J2SEHTTPTransport transport= new J2SEHTTPTransport (receiver,null);
transport.getResponse(true);
Envelope responseEnvelope=call.invoke(transport);
if(responseEnvelope != null){
if(responseEnvelope.isFaultGenerated()){
Fault f = responseEnvelope.getFault();
returnParameter=f.toString();
} else {
returnParameter = (responseEnvelope.getParameter(0)).toString();
}
}
} catch (Exception ex) {
label1.setText("Exception: "+ex);
add(label1);
label1.setBounds(13,12,190,21);
}
return returnParameter;
}
/**
* calculateHMAC
*
* This method calculates W (Witness) HMAC (with SHA1 as hash).
*
*
* @return W (witness) HMAC
* @see Bouncy Castle Cryptographic API
*/
public String calculateHMAC() {
String sha1Digest="";
HMac myHmac = new HMac(new SHA1Digest());
byte[] myMessage=W.toString().getBytes();
byte[] outDigest=new byte[myHmac.getMacSize()];
myHmac.init(new KeyParameter(k));
myHmac.update(myMessage, 0, myMessage.length);
myHmac.doFinal(outDigest,0);
for (int i=0;i<20;i++){sha1Digest=sha1Digest+new Byte(outDigest[i]).toString();}
return sha1Digest;
}
}
________________________________________
36
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
KEEPER
[keeper.jsp]
<%@ page contentType="text/html"%>
<%@ page language="java"%>
<%! String server,service;%>
<%
server=request.getParameter("server");
service=request.getParameter("service");
%>
<html>
<head>
<title>E-wallet</title>
</head>
<body>
<p>
<font size="-1" face="Arial, Helvetica, sans-serif"><strong>Checking Authorization</strong></font>
<br><br>
<img src="images/padlock.jpg" width="62" height="52">
<applet code="schnorr.class" width="170" height="53">
<param name="archive" value="j2sewsoap_1.04.jar,BC.jar">
<param name="server" value=<%=server%>>
<param name="service" value=<%=service%>>
</applet>
</p>
</body>
</html>
[dd.xml]
<dd:service xmlns:dd="http://xml.apache.org/xml-soap/deployment"
id="urn:SchnorrAuthentication">
<dd:provider type="java" scope="Application" methods="SchnorrFSM">
<dd:java class="keeper.Schnorr" static="false" />
</dd:provider>
<dd:faultListener>org.apache.soap.server.DOMFaultListener
</dd:faultListener>
<dd:mappings />
</dd:service>
[ Schnorr.java ]
/**
* Schnorr.java
*
* This is the Schnorr protocol implementation for the keeper.
* It is modelled like a Moore FSM with three possible states (variable state).
*
________________________________________
37
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
* @author Raul Hernandez
* @version v1.0 10-05-03
*
*/
package keeper;
import
import
import
import
import
java.util.*;
java.math.BigInteger;
java.security.*;
javax.crypto.*;
javax.crypto.spec.*;
public class Schnorr {
// primes p and q and generator g generated by openssl: $ openssl dsaparam -C 640
final byte [] pInBytes={
(byte)0x89,(byte)0xE0,(byte)0x17,(byte)0x72,(byte)0xA1,(byte)0xAD,
(byte)0xBB,(byte)0x5C,(byte)0x2C,(byte)0x68,(byte)0x7C,(byte)0xE5,
(byte)0x8E,(byte)0xCA,(byte)0x48,(byte)0x8B,(byte)0xB7,(byte)0x98,
(byte)0xD9,(byte)0x34,(byte)0x0C,(byte)0xBA,(byte)0xD6,(byte)0xB3,
(byte)0x29,(byte)0xCC,(byte)0x67,(byte)0x64,(byte)0xBF,(byte)0x26,
(byte)0xDA,(byte)0xB5,(byte)0x1F,(byte)0x23,(byte)0xEC,(byte)0x22,
(byte)0xEB,(byte)0x76,(byte)0xF2,(byte)0x98,(byte)0xBF,(byte)0x6A,
(byte)0x67,(byte)0xD9,(byte)0x92,(byte)0x06,(byte)0x33,(byte)0x15,
(byte)0xEE,(byte)0xF0,(byte)0x9F,(byte)0x35,(byte)0xCB,(byte)0xB0,
(byte)0x75,(byte)0x14,(byte)0x7D,(byte)0x6A,(byte)0xBA,(byte)0x83,
(byte)0x37,(byte)0xE6,(byte)0x80,(byte)0x82,(byte)0x0C,(byte)0x91,
(byte)0x15,(byte)0xEE,(byte)0x75,(byte)0x61,(byte)0xD6,(byte)0xF3,
(byte)0x69,(byte)0x37,(byte)0x6D,(byte)0x4B,(byte)0x04,(byte)0x00,
(byte)0x59,(byte)0xA5};
final byte [] qInBytes={
(byte)0xA3,(byte)0x64,(byte)0x01,(byte)0xAB,(byte)0x54,(byte)0x6E,
(byte)0xF7,(byte)0xFB,(byte)0x71,(byte)0xD1,(byte)0xA2,(byte)0x1E,
(byte)0x08,(byte)0x46,(byte)0xA6,(byte)0xD3,(byte)0x49,(byte)0x0C,
(byte)0xEA,(byte)0xDF};
final byte [] gInBytes={
(byte)0x7A,(byte)0xF4,(byte)0xFB,(byte)0x8F,(byte)0x70,(byte)0x25,
(byte)0x0C,(byte)0x6A,(byte)0x38,(byte)0xFC,(byte)0x3F,(byte)0x68,
(byte)0x1F,(byte)0x2C,(byte)0xA0,(byte)0x47,(byte)0x60,(byte)0x99,
(byte)0xBB,(byte)0xA2,(byte)0x40,(byte)0xC9,(byte)0x46,(byte)0x51,
(byte)0x59,(byte)0x75,(byte)0xE2,(byte)0xBC,(byte)0xAD,(byte)0xD8,
(byte)0x95,(byte)0xC1,(byte)0xEE,(byte)0x36,(byte)0xA7,(byte)0x5B,
(byte)0x1B,(byte)0xE0,(byte)0xC5,(byte)0xB7,(byte)0x77,(byte)0xA5,
(byte)0x24,(byte)0x7F,(byte)0x56,(byte)0xD5,(byte)0xC6,(byte)0x50,
(byte)0x07,(byte)0x0A,(byte)0x3C,(byte)0x04,(byte)0x6A,(byte)0xBC,
(byte)0xD5,(byte)0x3E,(byte)0xFC,(byte)0xD4,(byte)0xD3,(byte)0x14,
(byte)0x00,(byte)0x28,(byte)0x2D,(byte)0xD2,(byte)0x52,(byte)0x10,
(byte)0xEE,(byte)0x61,(byte)0x53,(byte)0x47,(byte)0x65,(byte)0xE7,
(byte)0x74,(byte)0x2B,(byte)0x9E,(byte)0x4E,(byte)0x7C,(byte)0x48,
(byte)0x34,(byte)0x6A};
final BigInteger p = new BigInteger(1,pInBytes);
final BigInteger q = new BigInteger(1,qInBytes);
final BigInteger g = new BigInteger(1,gInBytes);
// Security parameter
final int t= 160;
// Secret key shared between keeper and user
final byte[] k="mySecret".getBytes();
________________________________________
38
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
// Private and public key pair
final BigInteger SK=new BigInteger("357");
final BigInteger PK=g.modPow(SK,p);
// Other Schnorr parameters
final BigInteger n=new BigInteger("330");
final BigInteger a1=new BigInteger("430");
final BigInteger a2= new BigInteger("89");
// Global variable (It maintains the state)
int state=0;
String response;
BigInteger w,W;
BigInteger c;
StringTokenizer st;
/**
* SchnorrFSM
*
* The main and only method running the application.
* It emulates a Moore FSM.
*
* @param header control header
* @param parameters payload (data)
* @return Ok+Data / Reset
*
* @see java.math.BigInteger,JCE (Java Cryptographic Extension)
*
*/
public String SchnorrFSM (String header,String parameters) {
switch (state) {
case 0:
if ("INIT".equals(header)){
// Witness
w=g.modPow(n,p);
W=(w.mod(p).multiply(g.modPow(a1,p))).mod(p);
// SHA-Hash
String alpha="";
try {
MessageDigest md = MessageDigest.getInstance("SHA");
md.update(a2.toString().getBytes());
byte [] byteDigest=md.digest();
for (int i=0;i<20;i++){alpha=alpha+new Byte(byteDigest[i]).toString();}
} catch (Exception e ){}
response="OK"+","+W+","+alpha;
state++;
}
break;
case 1:
if ("PARAMETERS".equals(header)){
st=new StringTokenizer(parameters,",");
c=new BigInteger(st.nextToken());
________________________________________
39
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
String beta =st.nextToken();
// HMAC-SHA1
String HMacSHA1="";
try{
SecretKey sk=new SecretKeySpec(k,"HmacSHA1");
Mac mac = Mac.getInstance("HmacSHA1");
mac.init(sk);
mac.update(W.toString().getBytes());
byte [] byteHMac=mac.doFinal();
for (int i=0;i<20;i++){HMacSHA1=HMacSHA1+new Byte(byteHMac[i]).toString();}
} catch (Exception e ){}
if (beta.equals(HMacSHA1)) {
response="OK";
state++;
} else{
response="RESET";
state=0;
}
}
break;
case 2:
if ("PARAMETERS".equals(header)){
BigInteger C=c.add(a2).mod(q);
BigInteger r=(n.subtract(C.multiply(SK))).mod(q);
// Keeper checks
if (w.compareTo((g.modPow(r,p).multiply(PK.modPow(C,p))).mod(p))==0){
BigInteger R=r.add(a1).mod(p);
response="OK"+","+R+","+a2;
}else
response="RESET";
}
state=0;
}
}
}
return response;
________________________________________
40
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
SERVER
[OpenTheDoor.html]
<HTML>
<HEAD>
<TITLE>Open the door</TITLE>
<script language="JavaScript" type="text/JavaScript">
function f(w,server,s) {
location.href="http://"+w+"?"+"server="+server+"&"+"service="+s;
}
</script>
<BODY>
<form name="form1">
E-wallet <input name="wallet" type="text"><br>
Door
<input name="service" type="text"><br><br>
<input name="server" type="hidden" value="129.241.209.74">
<INPUT TYPE="button" VALUE="Go to the Keeper"
onClick="f(form1.wallet.value,form1.server.value,form1.service.value)">
</form>
</BODY>
</HTML>
[dd.xml]
<dd:service xmlns:dd="http://xml.apache.org/xml-soap/deployment"
id="urn:SchnorrAuthentication">
<dd:provider type="java" scope="Application" methods="SchnorrFSM">
<dd:java class="server.Schnorr" static="false" />
</dd:provider>
<dd:faultListener>org.apache.soap.server.DOMFaultListener
</dd:faultListener>
<dd:mappings />
</dd:service>
[Schnorr.java]
/**
* Schnorr.java
*
* This is the Schnorr protocol implementation for the server.
* It is modelled like a Moore FSM with two possible states (variable state).
*
* @author Raul Hernandez
* @version v1.0 10-05-03
*
*/
package server;
________________________________________
41
NTNU – Department of Telematics
import
import
import
import
import
E-wallet with decentralized credential keepers
java.util.*;
java.math.BigInteger;
java.security.*;
javax.crypto.*;
javax.crypto.spec.*;
public class Schnorr {
// primes p and q and generator g generated by openssl: $ openssl dsaparam -C 640 */
final byte [] pInBytes={
(byte)0x89,(byte)0xE0,(byte)0x17,(byte)0x72,(byte)0xA1,(byte)0xAD,(byte)0xBB,(byte)0x5C,
(byte)0x2C,(byte)0x68,(byte)0x7C,(byte)0xE5,(byte)0x8E,(byte)0xCA,(byte)0x48,(byte)0x8B,
(byte)0xB7,(byte)0x98,(byte)0xD9,(byte)0x34,(byte)0x0C,(byte)0xBA,(byte)0xD6,(byte)0xB3,
(byte)0x29,(byte)0xCC,(byte)0x67,(byte)0x64,(byte)0xBF,(byte)0x26,(byte)0xDA,(byte)0xB5,
(byte)0x1F,(byte)0x23,(byte)0xEC,(byte)0x22,(byte)0xEB,(byte)0x76,(byte)0xF2,(byte)0x98,
(byte)0xBF,(byte)0x6A,(byte)0x67,(byte)0xD9,(byte)0x92,(byte)0x06,(byte)0x33,(byte)0x15,
(byte)0xEE,(byte)0xF0,(byte)0x9F,(byte)0x35,(byte)0xCB,(byte)0xB0,(byte)0x75,(byte)0x14,
(byte)0x7D,(byte)0x6A,(byte)0xBA,(byte)0x83,(byte)0x37,(byte)0xE6,(byte)0x80,(byte)0x82,
(byte)0x0C,(byte)0x91,(byte)0x15,(byte)0xEE,(byte)0x75,(byte)0x61,(byte)0xD6,(byte)0xF3,
(byte)0x69,(byte)0x37,(byte)0x6D,(byte)0x4B,(byte)0x04,(byte)0x00,(byte)0x59,(byte)0xA5};
final byte [] qInBytes={
(byte)0xA3,(byte)0x64,(byte)0x01,(byte)0xAB,(byte)0x54,(byte)0x6E,(byte)0xF7,(byte)0xFB,
(byte)0x71,(byte)0xD1,(byte)0xA2,(byte)0x1E,(byte)0x08,(byte)0x46,(byte)0xA6,(byte)0xD3,
(byte)0x49,(byte)0x0C,(byte)0xEA,(byte)0xDF};
final byte [] gInBytes={
(byte)0x7A,(byte)0xF4,(byte)0xFB,(byte)0x8F,(byte)0x70,(byte)0x25,(byte)0x0C,(byte)0x6A,
(byte)0x38,(byte)0xFC,(byte)0x3F,(byte)0x68,(byte)0x1F,(byte)0x2C,(byte)0xA0,(byte)0x47,
(byte)0x60,(byte)0x99,(byte)0xBB,(byte)0xA2,(byte)0x40,(byte)0xC9,(byte)0x46,(byte)0x51,
(byte)0x59,(byte)0x75,(byte)0xE2,(byte)0xBC,(byte)0xAD,(byte)0xD8,(byte)0x95,(byte)0xC1,
(byte)0xEE,(byte)0x36,(byte)0xA7,(byte)0x5B,(byte)0x1B,(byte)0xE0,(byte)0xC5,(byte)0xB7,
(byte)0x77,(byte)0xA5,(byte)0x24,(byte)0x7F,(byte)0x56,(byte)0xD5,(byte)0xC6,(byte)0x50,
(byte)0x07,(byte)0x0A,(byte)0x3C,(byte)0x04,(byte)0x6A,(byte)0xBC,(byte)0xD5,(byte)0x3E,
(byte)0xFC,(byte)0xD4,(byte)0xD3,(byte)0x14,(byte)0x00,(byte)0x28,(byte)0x2D,(byte)0xD2,
(byte)0x52,(byte)0x10,(byte)0xEE,(byte)0x61,(byte)0x53,(byte)0x47,(byte)0x65,(byte)0xE7,
(byte)0x74,(byte)0x2B,(byte)0x9E,(byte)0x4E,(byte)0x7C,(byte)0x48,(byte)0x34,(byte)0x6A};
final BigInteger p = new BigInteger(1,pInBytes);
final BigInteger q = new BigInteger(1,qInBytes);
final BigInteger g = new BigInteger(1,gInBytes);
// user´s public key ,PK=g^SK mod p
final BigInteger PK=new BigInteger("1574132948782435393352576981342142740"+
"7324534330622807555465268096372323248"+
"9561974966494998122701023439865478368"+
"7785264126677583824352489836522147657"+
"523348878025266234821614957246592404615592");
// challenge
final BigInteger c=new BigInteger("97");
int state=0;
String response;
StringTokenizer st;
BigInteger W;
String alpha;
/**
________________________________________
42
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
* SchnorrFSM
*
* The main and only method running the application.
* It emulates a Moore FSM.
*
* @param header control header
* @param parameters payload (data)
* @return Ok+Data / Reset
*
* @see java.math.BigInteger,JCE (Java Cryptographic Extension)
*
*/
public String SchnorrFSM (String header,String parameters) {
switch (state) {
case 0:
if ("PARAMETERS".equals(header)){
/*Retrieve W and alpha */
st=new StringTokenizer (parameters,",");
W=new BigInteger(st.nextToken());
alpha=st.nextToken();
/* Challenge */
response="OK"+","+c;
/*Next state*/
state++;
}
break;
case 1:
if ("PARAMETERS".equals(header)){
st=new StringTokenizer (parameters,",");
BigInteger R=new BigInteger(st.nextToken());
BigInteger a2=new BigInteger(st.nextToken());
// Check hash(a2)
String alpha2="";
try {
MessageDigest md = MessageDigest.getInstance("SHA");
md.update(a2.toString().getBytes());
byte [] byteDigest=md.digest();
for (int i=0;i<20;i++){alpha2=alpha2+new Byte(byteDigest[i]).toString();}
} catch (Exception e ){}
// Check W
BigInteger W2=(g.modPow(R,p).multiply(PK.modPow(c.add(a2),p))).mod(p);
// Everything OK ?
if (alpha2.equals(alpha) && (W2.compareTo(W)==0))
response="OK";
else
response="RESET";
state=0;
}
}
}
}
return response;
________________________________________
43
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
REFERENCES
[ASOAP] Apache SOAP
http://ws.apache.org/soap/
[AXIS]
Apache AXIS
http://ws.apache.org/axis/
[ATV]
Atinav’s aveLink Bluetooth Protocol Stack
http://www.avelink.com/modules/bt_windowsce.htm
[BC]
Bouncy Castle Crypto APIs
http://www.bouncycastle.org/
[CAC]
Cybercash
http://www.cybercash.com
[CAFE]
Boly, S.F. Mjølsnes et al.,
The ESPRIT project CAFE – High Security Digital Payment Systems
ESORICS 94 Proceedings (Springer-Verlag, 1994)
[DAV]
Dan Davis and Manish Parashar
Latency Performance of SOAP Implementations
[CDC]
Connected Device Configuration
http://java.sun.com/products/cdc/
[DEC]
Digicash
http://www.digicash.com
[ETH]
Ethereal network analyzer
http://www.ethereal.com/
[GLUE]
GLUE
http://www.themindelectric.com/
[GMCIG] Global Mobile Commerce Interoperability Group
http://www.gmcig.org
[HAC]
[JAB]
[JAW]
Handbook of Applied Cryptography
A.Menezes, P.Van Oorschot and S.Vanstone.
http://www.cacr.math.uwaterloo.ca/hac/
Java APIs for Bluetooth
http://www.jabwt.com/
Java Wallet
http://java.sun.com/products/commerce/faq.html#javawallet
________________________________________
44
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
[JAXM]
Java API for XML messaging
http://java.sun.com/xml/jaxm/
[JAXR]
Java API for XML-based RPC
http://java.sun.com/xml/jaxrpc/
[JSR82]
Java Specification Request 82 (Java API for Bluetooth)
http://www.jcp.org/en/jsr/detail?id=082
[JCE]
Java Cryptography Extension
http://java.sun.com/products/jce/
[JINI]
JINI Network Technology
http://www.sun.com/software/jini/
[J2ME]
Java 2 Platform Micro Edition
http://java.sun.com/j2me
[JEODE] Jeode Virtual Machine
http://www.insignia.com/content/products/jvm/pda.shtml
[JSSE]
Java Secure Socket Extension
http://java.sun.com/products/jsse/
[JVM]
Jeode Virtual Machine (new)
http://www.esmertec.com/products/products_jeode.shtm
[GJER03] Marius Gjerde,
Decentralized credentials
NTNU Master thesis (June 2003).
[KS]
Ksoap
http://ksoap.enhydra.org/
[MC]
Minimum Corba
http://doc.ece.uci.edu/CORBA/formal/02-08-01.pdf
[MeT]
Mobile Electronics Transactions
http://www.mobiletransactions.org
[MF]
The Mobey Forum
http://www.mobeyforum.org
[NVM]
Nsicom Virtual Machine
http://www.nsicom.com/products/creme.asp
[OMG]
Object Management Group
http://www.omg.org/
[ORB/E]
Orbacus Embebbed
http://www.iona.com/pressroom/2001/20010515.htm
[ORBE]
ORB Express
http://www.corbadev.kiev.ua/wiki/index.php?page=ORBExpressEng
________________________________________
45
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
[OTA]
Over-the-Air
http://wireless.java.sun.com/midp/ttips/wtkota/
[PJ]
Personal Java Application Environment;
http://java.sun.com/products/personaljava/
[SAML]
Security Assertion Markup Language
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
[SAV]
Savaje OS
http://www.savaje.com/products/index.html
[SFM03] Mjølsnes, Stig Frode ; Rong,Chunning
On-Line E-Wallet System with decentralized credential keepers
Mobile networks and applications 8,2003
[ST03]
Steinsholt, Vegard
Software Architecture for on-line electronic wallet
NTNU final project thesis (February 2003)
[SWAP]
SWAPEROO: A Simple Wallet Architecture for Payments,Exchanges,Refunds,and
Other Operations
Daswani,Boneh et al.
[TAO]
TAO
http://www.theaceorb.com/
[VS03]
Steinsholt, Vegard
Software Architecture for on-line electronic wallet
[WS]
Wingfoot SOAP
http://www.wingfoot.com/products.jsp
[XMLD]
XML Digital Signatures
http://www.w3.org/TR/xmldsig-core/
[XMLE]
XML Encryption
http://www.w3.org/Encryption/2001/
________________________________________
46
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Appendix A. JeodeRuntime™ documentation
•
Introduction
•
Installation
•
Demonstrations supplied
•
Running Java applets
•
Running Java applications
•
Command-line options
•
FAQ
•
Further information
•
Disclaimer
Introduction
This document describes how to run JeodeRuntime on your Compaq iPAQ Pocket PC device.
JeodeRuntime is a fully-certified implementation of Sun's PersonalJava 1.2 specification.
JeodeRuntime can be used:
•
As a plug-in to your iPAQ's Pocket Internet Explorer, to run Java applets from a web page.
•
As a stand-alone Java VM (Virtual Machine), to run Java applications on your iPAQ.
Note: Some Java applets on web pages are not designed for the memory constraints of your iPAQ. Please
see the FAQ section for guidelines on what types of applets you can expect to run.
Installation
JeodeRuntime is provided as an executable file. After you copy JeodeRuntime onto your PC, simply click
on the executable file to install JeodeRuntime onto your iPAQ.
By default, JeodeRuntime files are installed in \Windows and subdirectories of \Windows on your iPAQ.
Notes:
________________________________________
47
NTNU – Department of Telematics
•
E-wallet with decentralized credential keepers
You must have a working ActiveSync connection between your Windows PC and your iPAQ (for
ActiveSync trouble-shooting information, please see the Microsoft web site).
•
For Windows 2000 PCs, you must have administrator privileges set.
Uninstallation
To uninstall JeodeRuntime on your iPAQ, select Start > Settings, select the System tab, select
Remove Programs, then remove Insignia Solutions JeodeRuntime.
Note: if uninstallation fails, please reset your iPAQ, then re-try.
Demonstrations supplied
We provide a Java applet and a simple Java application, to demonstrate JeodeRuntime functionality:
•
Quasar: a Java applet, invoked by opening a HTML file.
•
PrimTest: a Java application which uses the AWT graphics library to demonstrate some Java
graphics capabilities.
To run the demonstration applications or applet, select Start > Programs > Jeode > Examples, then
select the demonstration application or applet to run. For example, to run the Quasar demonstration
applet, select Start > Programs > Jeode > Examples > Quasar.
Running Java applets
The Jeode plug-in for Pocket Internet Explorer is included when you install JeodeRuntime.
When your browser next opens a web page which contains a Java applet, the plug-in runs the applet. This
all happens automatically - no user intervention is needed.
For more information about running applets (including limitations), please refer to the FAQ section.
Running Java applications
To run a Java application using JeodeRuntime, you will need to copy the application classes, libraries and
properties to your iPAQ.
You can then launch JeodeRuntime in two ways:
•
Tap on the EVM icon (Start > Programs > Jeode), then enter options at the Enter args:
prompt as follows:
________________________________________
48
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
[command-line options] class-name [class-arguments]
where:
[command-line options] are command-line options to pass to the EVM (for example, -cp).
class-name is the class name for your Java application (for example, PrimTest).
[class-arguments] are any optional arguments for the Java application to run.
For example:
-cp \Windows\lib\jeodedemos.jar PrimTest
•
Run JeodeRuntime as a shortcut.
Create then tap on a shortcut (a .lnk file) to evm.exe in the Start menu. This allows you to
store EVM arguments (class name and command-line options) in the Properties of the shortcut,
avoiding the need to re-type them every time you launch JeodeRuntime.
See the Creating a shortcut section below for more information.
Creating a shortcut
To create a shortcut, use File Explorer to go to the Mobile Devices > My Pocket PC > Windows
window, select evm.exe, select Edit menu > Copy, then select Paste Shortcut.
This creates a file Shortcut to evm.exe.lnk. Copy this file to a directory on your PC, and open it with a
text
editor
such
as
Notepad.
The
contents
of
the
file
will
look
like,
18#"\Windows\evm.exe"
You can now edit this file to add command-line parameters. For example, to run the supplied PrimTest
example, you could edit the file to be:
18#"\Windows\evm.exe" -cp \Windows\lib\jeodedemos.jar PrimTest
You can add other command-line options to the shortcut as required, up to 255 characters.
You can now copy the shortcut back to the iPAQ, then tap on it to run the Primitives Test application.
Command-line options
This section describes some common JeodeRuntime command-line options you can pass to the Jeode
EVM, when running via the command line or setting up a .lnk file.
•
-?
•
-classpath or -cp
•
-D
________________________________________
49
NTNU – Department of Telematics
•
-v or -verbose
•
-version
•
-Xnowinceconsole
E-wallet with decentralized credential keepers
-?, -h or -help
Displays help for all JeodeRuntime command-line options.
-classpath <pathnames> or -cp <pathnames>
Specify the path(s) used for loading application classes. The pathnames are separated by semi-colons.
For example, to include classes contained in jeodedemos.jar, you could use the command:
-cp \Windows\lib\jeodedemos.jar
-D<propertyName>=<value>
Supplies
For
the
value
for
to
keep
example,
JeodeRuntime
a
the
display
or
standard
console
Java
open,
use
system
the
property.
command:
-Djeode.evm.console.local.keep=TRUE
-v, -verbose
Causes messages to be displayed on the JeodeRuntime console when:
•
A class file or dynamic library is successfully loaded.
•
A garbage collection cycle is performed.
-version
Displays JeodeRuntime version information on the EVM console.
-Xnowinceconsole
Use the -Xnowinceconsole option to disable the EVM console if you do not want to see it - for example,
when running graphical applications.
FAQ
This section answers frequently-asked technical questions about JeodeRuntime.
•
Why does my applet not work?
•
Why do I get a "Failed to run applet" message?
•
Does JeodeRuntime work with JavaScript?
•
Can I discard some JeodeRuntime files to save memory?
•
How do I define classpath settings?
•
Is Swing supported?
•
How do I prevent the console from closing when the EVM terminates?
________________________________________
50
NTNU – Department of Telematics
•
E-wallet with decentralized credential keepers
Why can't my program find a data file?
Why does my applet not work?
There are two common reasons why a Java applet may not be able to run:
•
Applets in CAB files
JeodeRuntime does not currently support loading applets from Microsoft CAB files, as CAB files
are not part of standard Java technology. So if the web site makes assumptions (based on the
type of browser) about the behavior of the VM being used, this may result in problems loading
the applet.
•
Applets in JAR or ZIP files
JeodeRuntime does support use of applets contained in JAR or ZIP files.
However, because Pocket Internet Explorer is compatible with the HTML 3.2 Specification, Pocket
Internet Explorer does not support using the ARCHIVE attribute of the APPLET tag in the HTML
page calling the applet, and so Pocket Internet Explorer will not support loading applets from JAR
or ZIP files under these circumstances.
If you are able to rewrite the HTML in the web page calling the applet, you can use JAR and ZIP
files, by specifying the archive as a parameter name as well as an ARCHIVE attribute (using
<param name=archive>). For example:
<param name=archive value=myclasses.jar>
Why do I get a "Failed to run applet" message?
You may see a message of the type:
Failed to run applet. Please reload
This means that the plug-in has detected a condition that prevents the applet from being run. There are
various possibilities - one common problem is lack of memory on an iPAQ, as some applets are written
assuming unlimited amounts of memory to be available.
The Jeode plug-in has no control over the memory requirements of the applet. If there is insufficient
memory remaining for the plug-in to continue running, it will issue a message to the user and close down.
Does JeodeRuntime work with JavaScript?
JavaScript is an object scripting language for the creation and customization of applications. While Java is
used by programmers to create new objects and applets, JavaScript is designed for use by HTML page
authors to dynamically script the behavior of objects running on either the client or the server. JavaScript
and Java are completely different programming languages; therefore, Jeode is not used to run JavaScript.
________________________________________
51
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Also, the Jeode plug-in does not currently support communications between JavaScript and Java applets.
This means that applets which require this interaction will not work with JeodeRuntime.
Is Swing supported?
Unfortunately, Swing 1.1.1 is not compatible with PersonalJava 1.2, so JeodeRuntime will not support
Swing 1.1.1. The problem is due to an incorrect test in Swing 1.1.1, as described in bugID 4309057 on
Sun's? Java Developer Connection web site.
How do I define classpath settings
You can set the classpath via the command-line -cp or -classpath option. See the Running Java
applications section for more information.
Can I discard some JeodeRuntime files to save memory?
The minimum set of files depends on the application.
If your applet or application does not require internationalization support, (that is, non-US English
language support), you can discard the i18n.jar file. Similarly, if your application does not use graphics
(AWT), you can discard the evmawt.dll and awt.jar files.
Note: if you then try to run an applet or application that requires either of these pieces of functionality,
the applet or application will not run correctly, and may generate an appropriate error message.
How do I prevent the console from closing when the EVM terminates?
Use the -Djeode.evm.console.local.keep=TRUE command-line option. For example, to run the
PrimTest demo application, and stop the console from closing, you could use a command-line invocation
such
as:
-Djeode.evm.console.local.keep=TRUE -cp \Windows\lib\jeodedemos.jar PrimTest
You can also use the -Djeode.evm.console.local.paging=TRUE command-line option in a similar
manner, to enable console paging - this is useful if your application sends more than one screen of
information to the console.
Why can't my program find a data file?
Some Java applications look for files (data, preferences, and so on), in an assumed current working
directory, rather than specifying an absolute pathname. On iPAQs, the current working directory is always
assumed to be the root directory (\), so this may cause problems for some Java applications.
Further information
•
JeodeRuntime on other platforms
•
Jeode development environment
________________________________________
52
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
JeodeRuntime on other platforms
This version of JeodeRuntime is targeted at the Compaq iPAQ.
JeodeRuntime is also available on a number of other platforms - for more information, please contact
Insignia Solutions.
Jeode development environment
This version of JeodeRuntime is provided for your personal use, to run Java applications and applets.
Insignia Solutions also offers a version of the Jeode product suitable for a development environment,
which includes extra tools, enhanced documentation, premier technical support, and other variants of
JeodeRuntime. If you are interested in purchasing development seats of the Jeode platform for your
development project, please contact Insignia Solutions.
________________________________________
53
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Appendix B. Java Virtual Machines for Personal Java
Name
CrEme 3.2
Savaje XE
HP
Sun
Blackdown
Insignia
1.0
ChaiVM
PJava
J2RE1.3.1
Jeode
IBM J9
1.1
OS
WinCE
SavaJe XE
WinCE
WinCE
Linux
WinCE
WinCE
Compatibilty
PJava
JDK 1.3.1
JDK
JDK
JDK
JDK
JDK
1.1.8
1.1.8
1.3.1
1.1.8
1.1.8
Slow
Fast
Slow
Fat
Not
Speed
Fast
Very Fast
tested
Hardware
Cost
StrongARM
$1000
$100
Free
Free
Free
Contact
Free
Insignia
SavaJe XE – http://www.savaje.com/
Hewlett Packard ChaiVM Version 4.0 - http://www.hp.com/products1/embedded/index.html
Sun PersonalJava 1.1 (beta 2) - http://java.sun.com/products/personaljava/index.html
Blackdown J2RE 1.3.1 RC1 – http://www.blackdown.org/
Insignia's Jeode - http://www.insignia.com/content/products/pda.shtml
CrEme - http://www.nsicom.com/
IBM J9 - http://www.embedded.oti.com/
________________________________________
54
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Appendix C. Java Security Policy
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/" {
permission java.security.AllPermission;
};
// default permissions granted to all domains
grant {
// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission "*:1024-",
// "standard" properties that can be read by anyone
permission java.util.PropertyPermission "java.version", "read";
permission java.util.PropertyPermission "java.vendor", "read";
permission java.util.PropertyPermission "java.vendor.url", "read";
permission java.util.PropertyPermission "java.class.version", "read";
permission java.util.PropertyPermission "os.name", "read";
permission java.util.PropertyPermission "os.version", "read";
permission java.util.PropertyPermission "os.arch", "read";
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
permission java.util.PropertyPermission "java.specification.version",
"read";
permission java.util.PropertyPermission "java.specification.vendor",
"read";
permission java.util.PropertyPermission "java.specification.name",
"read";
permission java.util.PropertyPermission
"java.vm.specification.version", "read";
permission java.util.PropertyPermission
"java.vm.specification.vendor", "read";
permission java.util.PropertyPermission "java.vm.specification.name",
"read";
permission java.util.PropertyPermission "java.vm.version", "read";
permission java.util.PropertyPermission "java.vm.vendor", "read";
permission java.util.PropertyPermission "java.vm.name", "read";
};
________________________________________
55
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Appendix D. Java on small devices
J2ME is intended to be the way ahead for Java on small devices, but, there are other Java platforms already in existence (and in use) that have similar scope. The following section briefly
summarize these alternative platforms and compare them to J2ME.
JavaCard
JavaCard is a platform aimed at smart card technology. Smart cards are the smallest
environment for which a Java platform exists. The constraints of these devices are such that the
JavaCard virtual machine and the small set of Java class libraries that it supports require only
around 16 KB of non-volatile memory and 512 bytes of volatile memory. The scope of J2ME
does not extend to platforms with this little resource, so there is no J2ME configuration that is
suitable for the current generation of smart cards.
EmbeddedJava
EmbeddedJava is a JDK 1.1-based platform that is used to create software for embedded
devices. These devices typically have a 32-bit processor with 512 KB of ROM and 512 KB of
RAM available for the VM, class libraries, and embedded application. Since embedded devices
generally serve only one purpose, it is unnecessary to include parts of the Java platform that
the application does not require. In fact, EmbeddedJava allows the implementor to remove any
package or class -- or even a method within a class -- that is not required, in order to fit the
final product into the memory available.
EmbeddedJava is currently undergoing its end-of-life cycle, which means that it will no longer
be supported as of January 1, 2003. In the future, developers in embedded environments will
probably migrate to J2ME (CDLC and one of its profiles), which are targeted to devices with
similar resources.
PersonalJava
PersonalJava
is
intended
for
a
much
more
general
application
environment
than
EmbeddedJava. The target devices for Personal Java have up to 2 MB of ROM and at least 1 MB
________________________________________
56
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
of RAM available for the Java platform itself, with more required for application software. Some
of the larger PDAs and communicator devices, such as the Compaq iPAQ and the Nokia 9210
cell phone, are currently using the PersonalJava environment. The specification designates each
of the core JDK 1.1.8 packages as required, modified, or optional. Similar designations may also
be applied to individual classes and methods. A required package must contain all of the classes
from its JDK 1.1.8 counterpart, and each class must be a full implementation. An optional
package may or may not be present, but if it is present, it must be complete. A modified
package must be present, but its content may differ from its JDK 1.1.8 equivalent according to
rules laid down in the specification. PersonalJava includes user interface components in the
form of a modified java.awt package, and it also has optional support for RMI.
PersonalJava developers are expected to use J2ME (CDC) as a migration path to the Java 2
platform.
________________________________________
57
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Appendix E. CORBA vs RMI vs SOAP
Although all the middleware platforms were designed taking into account interoperability ,
nowadays there are some problems with the older protocols like CORBA IIOP and RMI. One of
the greatest problems is that these protocols are not firewall friendly. Most firewalls are
configured to allow access only traffic only through specific ports, the most popular being the
HTTP port 80 (only allowing to visit the web site). The older protocols use different ports, which
are blocked by most corporate firewalls. This means that applications residing in different
physical locations cannot talk to each other even if they have been built on the same platform.
Although it is possible to integrate CORBA with RMI (using RMI over IIOP) each one has it own
limitations. CORBA is a competing specification by the Object Management Group, but the
problem is that there are too many middleware vendors offering ORBs and not all the features
are standardised creating incompatibilities among different vendor implementations (CORBA
uses a Basic Object Adapter (BOA) as the glue between the server applications (objects) and
the ORB. The problem is that the BOA was weakly defined, vendors introduced their own valueadded services to their BOA implementations, thus creating incompatibilities). Even so, most
major middleware vendors support CORBA with the notable absence of Microsoft that is betting
for SOAP after the DCOM failure.
RMI is just a Java version of remote procedure call for Java. In fact, Sun was the first to
develop Remote Procedure Call (RPC) technology and nowadays RMI represents the next step:
RPC can send only primitive data types while RMI can send objects and RMI has also a less
overhead. In short, RMI is a good solution for communication between Java programs on
different hosts but if it is necessary to connect with programs written in other languages
probably CORBA or SOAP should be used instead.
If we look at the wire-format RMI is like CORBA as it is some proprietary binary data and it is
not as open as SOAP (based on an open standard, XML) thus they both seem to be more
appropriated for distributed intranet applications while SOAP is a perfect platform to implement
RPCs for Internet and it has the potential to create a transparent web of services and
applications which can be accessed from anywhere by anyone on demand. SOAP also mixes the
best features of both worlds: it is Internet ready as an open standard ratified by the W3C and
has also a great industrial support, Microsoft is moving towards a SOAP based environment for
________________________________________
58
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
its .NET Platform., Sun has announced something similar with its ONE platform and IBM and
the other majors have also announced broad support for SOAP.
The next table shows a comparative among these middleware platforms:
Format
Firewall friendly
Programming
Language
CORBA
Binary (IIOP)
No
Independent
RMI
Binary (JRMP)
No
Java
________________________________________
SOAP
XML
Yes
Independent
59
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
Appendix F. Wingfoot SOAP
1.
Introduction
Wingfoot SOAP 1.02 is a lightweight client implementation of SOAP 1.1 that is specifically
targeted at the MIDP/CLDC platform.
However, it can be used in J2SE and J2EE
environments.
This release of the SOAP client is an improvement over the 1.01 release. It retrieves the
Fault object instead of just throwing an Exception. If a data structure is not mapped using
TypeMappingRegistry, it is deserialized as an UntypedObject.
The rest of this appendix shows the reader how to use the API to send and receive SOAP
payload.
2.
Wingfoot SOAP Binary
Wingfoot SOAP 1.02 comes with two binaries. kvmwsoap_1.02.jar is targeted at the
CLDC/MIDP platforms. It includes a lightweight XML parser and is 35K in size.
j2sewsoap_1.02.jar targets at the CDC/Personal Java, J2SE, and J2EE platforms. It includes a lightweight XML parser and is 33.5K in size.
The API for both binaries is identical except for the Transport implementation.
kvmwsoap_1.01.jar
uses
HTTPTransport
while
j2sewsoap_1.01.jar
uses
J2SEHTTPTransport.
3.
SOAP Server
Wingfoot SOAP 1.02 does not provide a SOAP server. However, it has been successfully
tested against major SOAP implementations. Future plans call for an implementation of a
SOAP Server.
4.
Supported Style and Encoding
A SOAP message can have two kinds of payload and two mechanisms to encode the data.
This section explains the differences between them and the various combinations possible.
It concludes by documenting the combinations supported by Wingfoot SOAP 1.02.
A SOAP payload is either a RPC style or Document style. An RPC style is usually used when
there is a need to invoke a remote procedure or method. In a Document style, the SOAP
Body contains arbitrary XML. The SOAP client simply accepts the XML, appends it below the
________________________________________
60
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
<Body> element and sends the payload to the SOAP server. The SOAP server passes the
payload to an application and it is the responsibility of the application to parse the arbitrary
XML sent in the <Body> element.
Encoding refers to the rules followed by the SOAP client and the SOAP server to interpret
the contents of the <Body> element in the SOAP payload. The client and the server have to
agree on one rule to ensure that either end correctly interprets the payload sent from the
other end.
An encoded SOAP body indicates that the rules to encode and interpret a SOAP body are in
a URL specified by the encodingStyle attribute.
Wingfoot SOAP 1.02 defaults the
encodingStyle to http://schemas.xmlsoap.org/soap/encoding/.
A literal encoding indicates that the rules to encode and interpret the SOAP Body are
specified by a XML schema. Some services do not expect an encodingStyle attribute for
literal
encoding.
For
such
instances,
set
the
encodingStyle
attribute
to
null
(Envelope.setEncodingStyle(null))
Hence from the above discussion, there are four combinations of SOAP Style and SOAP
encoding:
·
RPC encoded (supported by Wingfoot SOAP 1.02)
·
RPC literal (not supported by Wingfoot SOAP 1.02)
·
Document encoded (not supported by Wingfoot SOAP 1.02)
·
Document literal (supported by Wingfoot SOAP 1.02)
Wingfoot SOAP 1.02, like most SOAP products, supports RPC encoded and Document literal
combination.
For RPC encoded, the only attribute available for encodingStyle is
http://schemas.xmlsoap.org/soap/encoding. Subsequent releases of our SOAP client will
have support for RPC literal and Document encoded along with the ability to specify custom
encodingStyle.
5.
SOAP Envelope
A SOAP XML payload consists of a mandatory Envelope element, an optional Header element
and a mandatory Body element. The first step is to create an Envelope. Wingfoot SOAP
allows the user to use a default Envelope or create a custom Envelope.
5.1 Default Envelope
A default Envelope is created by instantiating com.wingfoot.soap.Call using the default
constructor. Instances of com.Wingfoot.soap.Call are used to send a SOAP payload to the
server. A default Envelope:
________________________________________
61
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
a.
Sets the schema to http://www.w3.org/2001/XMLSchema;
b.
Sets the schema-instance to http://www.w3.org/2001/XMLSchema-instance;
c.
Does not allow the user to specify SOAP Header;
d.
Allows only RPC-encoded SOAP Body.
The following code fragment creates an instance of Call with default Envelope:
Call theCall = new Call ();
5.2 Custom Envelope
The following code fragment creates a custom Envelope and passes it to the Call object
Envelope customEnvelope = new Envelope ();
customEnvelope.setSchema ( “http://www.w3.org/1999/XMLSchema”);
customEnvelope.setSchemaInstance (“http://www.w3.org/1999/XMLSchema-instance”);
Call theCall = new Call (customEnvelope);
6.
SOAP Header
A SOAP Header element is optional, and is specified by creating a custom Envelope. A
Header element can have a number of user-defined headers each of which is encapsulated
in com.wingfoot.soap.HeaderEntry.
The following code fragment uses the custom Envelope created in the previous section to
specify two headers:
HeaderEntry he1 = new HeaderEntry (“header1”, “value1”);
HeaderEntry he2 = new HeaderEntry (“header2”, “value2”);
he2.setMustUnderstand (true); // default is false.
customEnvelope.addHeader (he1);
customEnvelope.addHeader (he2);
7.
7.1
SOAP Body
RPC encoded style
The following is a sample of RPC encoded SOAP payload
________________________________________
62
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetStockQuote xmlns:m=”urn:somens”>
<symbol>C</symbol></m:GetStockQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
This is an encoded SOAP body because the encodingStyle attribute specifies a URL with
the rules to interpret the SOAP body. Wingfoot SOAP 1.01 defaults the encodingStyle
to http://schemas.xmlsoap.org/soap/envelope/.
This is a RPC style SOAP body because the structure of the XML between <SOAPENV:Body> and </SOAP-ENV:Body> is dictated by SOAP Section 7. In the example
above, GetStockQuote is the method name.
For Java based SOAP servers, the
namespace “urn:somens” maps to a Java class which has a method named
GetStockQuote. This method expects one parameter named symbol. C is the value for
the parameter symbol.
To create a RPC encoded SOAP request, the default Envelope or a Custom Envelope
can be used. The following stub uses the default Envelope to create a RPC encoded
style SOAP Body.
Call theCall = new Call();
theCall.addParameter(“symbol”, “C”);
Using custom Envelope, the stub looks like:
Envelope custom = new Envelope();
/**
*Set alternate schema and schema instance here if necessary
**/
Call theCall = new Call(custom);
theCall.setMethodName(“GetStockQuote”);
theCall.setTargetObjectURI(“urn:somens”);
theCall.addParameter(“symbol”, “C”);
________________________________________
63
NTNU – Department of Telematics
7.2
E-wallet with decentralized credential keepers
Document literal style
In a Document literal style, the XML between <SOAP-ENV:Body> and </SOAPENV:Body> is supplied to the SOAP API by the client application. If the encodingStyle
is not required (can be determined from WSDL), it is set to null. A custom Envelope is
required for Document literal style. The stub below sends the XML stub in section 7.1
above as a Document literal.
Envelope custom = new Envelope();
/**
*Set alternate schema and schema instance here if necessary
**/
String str = “<m:GetStockQuote xmlns:m=”urn:somens”> <symbol>C</symbol>”
request.setBody(str);
request.setEncodingStyle(null);
Call theCall = new Call(custom);
This will produce a XML payload identical to the example in 7.1 above. The difference
is any response returned by the server is expected to be in Document literal style and is
not automatically deserialized; the contents between <SOAP-ENC:Body> and </SOAPENC:Body> is returned back as a string to the application; the application is responsible
to parse the XML.
7.3
RPC encoded – Primitive parameter
Wingfoot SOAP 1.01 automatically serializes and deserializes instances of:
·
java.lang.String
·
java.lang.Byte
·
java.lang.Short
·
java.lang.Integer
·
java.lang.Long
·
java.lang.Boolean
·
java.util.Date
·
com.wingfoot.soap.encoding.Float
·
com.wingfoot.soap.encoding.Base64
________________________________________
64
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
CLDC does not support java.lang.Float; hence Wingfoot SOAP 1.02 uses
com.Wingfoot.soap.encoding.Float to represent Float and Double data types. The
Base64 class is used to send binary data as a base64 encoded String. It also
encapsulates base64 data type returned by the server.
Instances of these objects are added as parameter using the Call.addParameter(String
name, String value) method.
________________________________________
65
NTNU – Department of Telematics
E-wallet with decentralized credential keepers
ACKNOLEDGEMENTS
I would like to thank all the Department of Telematics of the NTNU for welcoming and helping
me whenever I have needed it. Specially, to my supervisor Stig F. Mjølsnes for his support and
friendship during my stay at NTNU. His ideas and advices have been decisive to improve this
thesis.
I would also like to thank to the EU Socrates-Erasmus program this opportunity as it has been
one of the best experiences in my live.
Last but not least I will always have a doubt with the international students that I have met
these 6 last months in Trondheim. I will always remember you. Thank you for your friendship
and make this experience unforgettable.
________________________________________
66
NTNU – Department of Telematics
________________________________________
E-wallet with decentralized credential keepers
67