Secure e-commerce using mobile agents on
untrusted hosts
Dave Singelée, Bart Preneel
COSIC Internal Report
May, 2004
Abstract
This paper investigates how mobile agents can securely collect information,
protect the collected information against untrusted hosts, and how they
can digitally sign transactions in an untrusted environment. We present
an agent-based scenario for mobile commerce and discuss techniques using
multiple agents that have been implemented to provide security in this scenario. The underlying techniques are based on existing theoretical schemes.
These schemes generally have a significant overhead which is caused by the
use of multiple agents. However, this overhead can be compensated by the
functionality offered in our proposed scenario. The schemes require no interaction of the originator once the mobile agents are sent out. They are
therefore particularly suited for situations in which a user cannot stay online
for a long time. We also address some possible security threats which lead
to new observations on using threshold signature schemes in the context of
mobile agents.
Chapter 1
Introduction
The process of buying something online can be divided in two major phases:
first one has to find the best place (host) to buy certain goods or services,
then one has to pay for the goods or services that are bought. This paper
investigates how both phases can be conducted securely and efficiently by
mobile agents using certain cryptographic techniques.
1.1
Mobile agents and e-commerce
In the modern society, information and access to information is getting more
and more important. During the last couple of years, there is a strong tendency towards mobility. This implies an increasing need for being online and
having access to information all the time. This trend is also present in the
world of e–commerce. People want to use their mobile phone, PDA or laptop
to do online shopping. These devices cannot be online all the time (without
cost). This can be a limitation for some mobile commerce applications.
Fortunately, the concept of mobile agents can potentially solve the aforementioned problem. Mobile agents are software programs that can travel
autonomously from host to host to perform one or more tasks on behalf
of a certain user. They can communicate (and even negotiate) with other
agents, with hosts, . . . Using mobile agents has some interesting advantages
[1, 2, 3, 4]: The user can go offline after the agent is sent out and can come
online again when the agent has performed his tasks. This is very useful
for situations in which the user cannot stay online for a long time. Another
important advantage is the fact that the mobile agent performs his tasks
locally (i.e., at the host). This means that the device that sends the mobile
agents (e.g., a PDA or a mobile phone) can have very limited computing
power and will not need excessive power consumption. As will become clear
1
from this paper, mobile agents may in particular be very interesting if many
goods have to be bought. If only one thing has to be purchased, then other
techniques may be more efficient.
In the discussion above, we can identify two different kinds of mobility
concepts. The first kind of mobility are the mobile devices. These devices
are usually battery fed and do not have a lot of computational power. These
two constraints place severe restrictions to the code that has to be executed
on mobile devices. The second kind of mobility is mobile code. Mobile code
is very useful for situations in which a user cannot stay online for a long time
(e.g., because of a lack of bandwidth). We will primarily focus on this last
kind of mobility in this paper. Note that mobile code is of particular interest
with respect to the first kind of mobility as well.
Taking into account the advantages of mobile agents, one could wonder
why mobile agents are not frequently used in e-commerce. One of the main
reasons is that there are some security problems which are very difficult to
solve.
1.2
Contributions of this paper
The contribution of this paper is twofold. Firstly, it presents a practical
agent-based scenario for mobile commerce which can be made secure by using
existing techniques. These techniques are used in such a way that the entire
scheme becomes efficient and feasible to be deployed. Secondly, some new
observations on using these techniques in the context of mobile agent systems
are made. These observations are both in a theoretical and in a practical
sense important because they impose some limitations on using cryptographic
threshold schemes in the context of mobile agents.
1.3
Organization of the paper
This paper consists of seven sections. In this section, we have pointed out the
advantages and disadvantages of using mobile agents in e–commerce. Section 2 proposes a mobile agent-based scenario for e–commerce, describes the
different stages in this scenario, and gives an overview of the specific security
threats in this scenario. The remainder of this paper presents techniques
which can be used to make this scenario secure. Section 3 discusses how
cryptographic hash chains can be used by a mobile agent to securely collect
information (price, name of the host, . . . ) from different hosts. A payment
protocol conducted by multiple agents is presented in section 4. This section
2
also gives a short security analysis of the payment protocol and addresses
some important observations concerning threshold schemes in the context of
mobile agent systems. An interesting extension in the scenario, environmental key generation, is discussed in section 5. Section 6 describes the practical
implementation of the scenario. Finally, section 7 concludes the paper.
3
Chapter 2
Mobile agent-based scenario
Figure 2.1 shows an overall view of a practical and secure mobile agent system. We will now illustrate the different stages in a possible agent-based
scenario [5] and motivate our choice of this specific scenario. We will also
discuss the security threats present in this scenario. The techniques that
have been implemented to provide security in this scenario will be described
in the next sections.
2.1
2.1.1
Different stages in the scenario
User sends mobile agents
The user has a PDA with which he can periodically connect to the network
for a relatively short time. He wants to organize a complete holiday trip,
including flight reservation, hotel booking, car rental, day trip arrangements,
etc. For each of these different parts of his holiday, he sends a customized
mobile agent to the network, that will find the best bargains. Obviously, the
agents will have to exchange information to be able to jointly organize the
holiday according to the overall requirements of the user. After the agents are
sent to the network, the user disconnects his PDA from the network. There is
also a semi-trusted platform which keeps track of the different mobile agents.
This platform is given (public) information needed during the signature generation process (see section 2.1.3). This platform can be administered by the
user or by a service provider.
2.1.2
Agents travel and securely collect data
The mobile agents travel securely from agent platform to platform. Only
the agent parameters and collected data are securely transferred between the
4
Figure 2.1: An agent-based scenario for mobile commerce
5
agent platforms, the actual program code of the agent is retrieved each time
from its original location (e.g., the semi-trusted platform or an agent code
provider). We assume the code is generic and can be used by many customers.
The agent parameters constitute the personalization and customization of the
code.
The mobile agents will collect offers and other information at each agent
platform.
2.1.3
Agents conduct a secure payment transaction
At some point in time, an agent will decide or need to conduct a financial
transaction. It will then ask the cooperation of the other agents in order to
generate a digital signature. Together they can generate a new signature on
(for example) a particular offer of an agent platform. A combining entity
is required to combine an appropriate set of the contributions of the agents
into the resulting signature. In particular, to select this set, the validity of
each contribution should be checked. This task can be performed by the
semi-trusted platform that keeps track of the mobile agents or by another
semi-trusted platform dedicated to handling agent transactions.
2.1.4
Verify collected data
At the end of its journey, the agent will return to the semi-trusted platform.
This platform can verify the authenticity of the collected data. The data
possibly includes transactions conducted by this agent.
When the user reconnects his PDA to the network, he can request the
status of his mobile agents and retract the returned agents from the network.
He can then disconnect again and interpret the collected data of the agents.
2.2
Motivation
The most interesting fact of our scenario is that multiple agents are used
instead of one mobile agent. As will be explained in section 4, using multiple
agents to conduct a transaction has the big advantage that the transaction
can be valid even if some mobile agents have been tampered with. This
would certainly not be the case if only one mobile agent would have been
used! So the big security advantage of using multiple agents is robustness.
The use of multiple agents has generally however also the big disadvantage of creating a significant overhead: n mobile agents have to be executed
to conduct only 1 transaction. This is certainly not very efficient at first
6
sight. Fortunately, this overhead is compensated in our proposed scenario.
Different transactions are conducted in parallel. E.g., one or more agents
can buy a plane ticket while one or more other agents can rent a car. This
means that a group of n agents can conduct an arbitrary number (i.e., more
than n) of transactions such that, in contrast to threshold schemes in traditional scenarios, all the overhead caused by the use of multiple agents is
compensated.
One could wonder why the mobile agents do not return to the host of
the user after they have collected their offers. This would be a much easier
scenario. There are however some situations in which different goods have to
purchased that are dependent of each other. A typical example is a holiday
trip. When a user goes on holiday, he has to book a hotel, rent a car, buy
airplane tickets,. . . If the mobile agents do not cooperate, then it is possible
that they book a hotel in a period in which no cheap airplane tickets are
available. This is of course not what the users wants, so the transaction
would have to start all over again. The easiest solution for this problem is to
let the different mobile agents work together without the user’s intervention.
Another reason to do this is the fact that the user is not online all the time.
That is why in our scenario the mobile agents only return to the original host
after the transaction is finished.
2.3
Security threats
2.3.1
Security problems
In general, one can distinguish four different sorts of security problems when
using mobile agents, some a lot more difficult to solve than others [6, 7].
The first challenge is to protect a mobile agent in transit. This is easy
to accomplish with standard security techniques. By using the transport
layer security protocol SSL/TLS [8], nobody (except the host that sends the
mobile agent and the host that receives it) can eavesdrop on the mobile agent
or tamper with it without this being detected. In the rest of the paper, we
assume that SSL/TLS is used every time agents or other information are sent
between different hosts.
A second security problem is to protect a host against visiting mobile
agents. This problem is similar to protecting a PC against viruses or malicious mobile code and should therefore not be very difficult to solve. Mobile
agents are run in sandboxed environments. In addition, mobile agents can
be digitally signed. An agent platform’s security policy can then determine
the privileges the platform will grant to the agent.
7
A mobile agent also has to be protected against other mobile agents. This
can be accomplished by making the mobile agent only accessible via a limited
set of (harmless) public methods.
The last and by far most difficult security problem is to protect the mobile agent against the host where it is being executed. The mobile agent is
completely under control of this host and almost any imaginable attack is
possible [9]: the host can eavesdrop on the mobile agent, it can tamper with
the agent or just refuse to execute it, etc. An overview of possible solutions
to this problem has been given in [10].
2.3.2
Threat analysis of our scenario
Our mobile-agent based scenario has some very specific security threats which
fall into the last category of general mobile agent security problems. This
section gives an overview of the most important ones.
Modification of other offers: A malicious host could try to modify or
delete offers from other hosts so that its offer would become the best
one (e.g., the one with the lowest price). This means that we have
to search for techniques which can preserve the integrity of the offers
collected by the mobile agents. Section 3 discusses a technique that
addresses this threat.
Denial of an offer: A malicious host could try to make a very good offer
(e.g., make an offer with a very low price) such that its offer would
certainly become the best offer and afterwards try to deny that it has
made that offer. To enforce non-repudiation, every host has to sign its
own offer.
Theft of the private key: A malicious host could try to steal the private
key of the mobile agents. If it succeeds, then it can sign arbitrary
documents. This attack is very threatening. To decrease the risk in
case of an eventual theft of the private key, techniques have to be used
to restrict the power of the mobile agents. E.g., the mobile agents can
only spend up to a certain amount of money. In addition, the private
key is distributed among multiple agents, as discussed in section 4.
Signing of other offers: A malicious host could try to let the mobile agents
sign another offer than they first intended to. This new offer can be
chosen by the attacker or can be an arbitrary new one. This attack is
very similar to the previous one. The only difference is that the malicious host does not know the private key in this attack. The technique
discussed in section 4 also addresses this threat.
8
Denial of service attacks: A lot of denial of service attacks are possible.
The easiest one for a malicious host is simply not to execute the mobile
agent. Fortunately, this can be easily solved by using multiple agents
(as we have done in our scenario). As long as the majority of the
mobile agents is executed correctly, the transaction will be valid. Note
however that also the semi-trusted platform has to execute everything
correctly (see also section 4.2).
In the next sections, we discuss the existing techniques that are most
suitable to address the security threats in our proposed scenario.
9
Chapter 3
Secure data collection by hash
chaining
When a user wants to purchase something online, he probably does not immediately know where to buy it. Typically, there are a lot of hosts that sell
the desired item and they do not all ask the same price or give the same
conditions. That is why the user will send a mobile agent to the different
hosts. The agent will ask the price (and other important information) and
will use that information to decide from which host the user should buy the
desired item (e.g., the host that asks the lowest price). Of course, malicious
hosts could try to change the information that a visiting agent has already
collected from other hosts (e.g., it could increase the prices of the other hosts
in such a manner that its price would become the lowest).
There are different solutions to this problem. The easiest solution is to
send as many mobile agents as there are hosts that have to be visited. In this
way, every agent only visits one host. A malicious host will have absolutely
no advantage of tampering with the agent because the mobile agent does
not contain information of other hosts. This method is secure, but it is also
the most expensive solution. Moreover, in most cases it is not known in
advance how many and which hosts have to be visited. Protocols based on
hash chaining are suitable here. We describe a specific solution of Karjoth
et al [11].
3.1
Description of the protocol
Suppose that a user (denoted by S0 ) sends a mobile agent to n hosts (denoted
by S1 to Sn ). The index in this notation indicates the order in which the
hosts are visited (i.e., the first host in the itinerary is S1 , the second is S2 ,
10
etc). To protect the data that is collected from these different hosts, the
mobile agent performs the following hash chaining protocol:
Protocol 1 (Hash Chaining).
• Encapsulated Offer:
Oi = SIGi (EN C0 (ri , oi ), hi ), 0 ≤ i ≤ n
• Chaining Relation:
h0 = H(o0 , S1 )
hi = H(Oi−1 , Si+1 ), 1 ≤ i ≤ n
• Protocol:
Si → Si+1 : {Ok | 0 ≤ k ≤ i}, 0 ≤ i ≤ n
The notation used in this protocol is explained in Tables 3.1 and 3.2.
Table 3.1: Symbols used in protocol 1
S0 = Sn+1
Si , 1 ≤ i ≤ n
o0
oi , 1 ≤ i ≤ n
Oi , 1 ≤ i ≤ n
O0 , O1 , O2 , . . . , On
Identity of the user (originator)
Identity of host i
Initial information (e.g. the identity of the agent)
Offer from host i
Encapsulated offer from host i
Chain of encapsulated offers
Table 3.2: Cryptographic notation used in protocol 1
ri
EN C0 (m)
SIGi (m)
H(m)
Si → Si+1 : m
Random number generated by host i
Message m encrypted with the public key of S0
Message m digitally signed by host i
Hash value calculated on message m
Message m is sent from host i to host i+1
Let us now have a look how this protocol works. The owner of the mobile
agent first makes a dummy offer o0 that contains initial information like
the identity of the owner, the ID of the agent, . . . Next, he computes the
11
Figure 3.1: Chaining
hash value h0 by applying H() over this dummy offer and the identity of the
first host S1 . Then he picks a random number r0 and encrypts this random
number and the dummy token with his own public key (this is equivalent
to encrypting the dummy token using randomized encryption). Finally, he
constructs the encapsulated offer O0 by signing the encryption and h0 . O0 is
then sent to host S1 .
All the hosts will perform almost exactly the same steps. First, host
Si will compute a hash value hi over the encapsulated offer Oi−1 of the
previous host (Si−1 ) and the identity of the next host (Si+1 ). This is the
chaining relation and it is illustrated in Figure 3.1. Next it will pick a random
number ri and encrypts this random number and its own offer oi with the
public key of the originator (S0 ) (this is equivalent to encrypting the offer oi
using randomized encryption). Finally, it constructs the encapsulated offer
Oi by signing the encryption and hi . Oi is then sent to the next host (Si+1 )
together with all the encapsulated offers O0 to Oi−1 from the previous hosts.
This procedure is repeated at every host. At the end of its itinerary, the
mobile agent will go back to the originator (Sn+1 = S0 ).
3.2
Discussion of the protocol
The hash chaining protocol has some interesting security properties [11]:
Confidentiality: The data collected by the mobile agent is encrypted with
12
the public key of the originator and therefore, nobody else than the
originator can read the data1 .
Non-Repudiation: Every host Si signs its encrypted offer. If the signature
scheme is secure, Si cannot repudiate Oi .
Strong Forward Integrity: Strong forward integrity means that none of
the encapsulated offers Ok can be modified by an attacker (where k is
smaller than a certain number m). The proof of this property can be
found in [11].
Publicly Verifiable Chain: Everybody is capable of verifying the chain
O0 , O1 , . . . , Oi . Each Ok is of the form Ok = SIGi (Xk , hk ) where
only Xk is an uninterpretable bit string. Thus the examiner can verify
whether the chaining relation holds and whether each signature on Ok
is valid.
Insertion Resilience: It is very difficult for an attacker to insert an encapsulated offer Oi0 into a valid chain O0 , O1 , . . . , Om .
Deletion Resilience: It is very difficult for an attacker to delete an encapsulated offer Oi from a valid chain O0 , O1 , . . . , Om (i ≤ m).
Truncation Resilience: Every truncation of a valid chain of encapsulated
offers O0 , O1 , . . . , Om at k (with k < m) will be detected unless the
attacker is able to insert simultaneously an offer in the name of Sk+1 .
Thus any shop in the chain can truncate all offers following its own.
1
We assume that the randomized encryption scheme used in the protocol is secure.
13
Chapter 4
Undetachable Threshold
Signatures
There are different methods to pay something: you can use electronic money,
you can calculate a digital signature on a specific document, . . . The protocol
explained in this paper will do the latter. It exists of 6 phases: an initialization phase, a distribution phase, a phase in which the agents are sent out,
a partial signing phase, a reconstruction phase and a finalization phase. All
these phases are discussed in Section 4.1. We also make some important observations in section 4.2 on using threshold schemes in the context of mobile
agents. Readers who are not familiar with the principles of secret sharing
should first read appendix A.
4.1
Payment Protocol
The technique of verifiable secret sharing will be used to calculate a digital
signature. More concrete, a user G will send n mobile agents Ai to different
hosts. These agents will first find the best offer. Then, they will sign this
offer using the RSA signature scheme [12]. They will do this with the help of
a semi-trusted party T . We describe the scheme of Borselius et al [13] which
is based on [14]. We include the notion of a proxy certificate [15] and fit the
protocol into our agent-based scenario. The complete protocol of finding the
best offer and signing it will be performed in 6 consecutive phases. These 6
phases will be explained in the following subsections.
14
4.1.1
Initialization Phase
The user G has to perform a lot of initialization steps. First G chooses 2 safe
prime numbers1 p en q of equal size (let’s say 512 bits each). So p = 2p0 + 1
and q = 2q 0 + 1. The RSA modulus N is then equal to N = pq. G also
calculates the secret number M = p0 q 0 . Next, G chooses a random prime
number e and calculates d = e−1 mod M .2 (d, e) is a temporary keypair
that will be used by the mobile agents Ai to sign the best offer. After
creating the temporary keypair, G formulates restrictions (denoted by R)
about the transaction that has to be performed. These restrictions contain
the maximum amount of money that can be spent, information about the
goods that have to be purchased, . . .
G now has enough information to create a proxy certificate. A proxy
certificate [15] is a certificate that is particularly designed for mobile agents.
It contains public information like the identity of the originator G, the public
key e of the agent, the modulus N , the restrictions R, . . . and it is signed
by G. A purchase will only be valid if it complies with this proxy certificate.
This is a very simple technique to delegate responsibility to the mobile agent
and at the same time decrease the risk by a possible theft of the secret key d.
A proxy certificate has a very short lifetime (the same lifetime as the public
key e) and therefore do not need be revoked. It also assures non-repudiation
to some extend because G has signed the certificate. So G cannot deny that
he has sent mobile agents for a particular acquisition. A proxy certificate is
thus a sort of procuration.
After the creation of this proxy certificate, G calculates H = h(R, G)2
(h() is a hash function with output in Z∗N ). And finally, G chooses a random
number a and calculates the number b as follows:
b = d · (1 − 4a∆2 ) mod M
(4.1)
In formula 4.1, ∆ is equal to ∆ = nA ! mod M with nA the number of mobile
agents Ai that will be sent out.
4.1.2
Distribution Phase
After the initialization phase, G uses a (kA , nA ) verifiable secret sharing
scheme (see appendix A) to divide the secret key d in nA shares si . G then
picks out a random number v (∈ QN ) and calculates the verification keys
vi = v si mod N . These verification keys will be used later in the protocol to
p is a safe prime number if p = 2p0 + 1 with p0 also a prime number.
All calculations in this protocol will be performed in the subfield of squares in Z∗N
(denoted by QN ). Z∗N is the group of integers a mod N with a coprime to N .
1
2
15
calculate a commitment. Finally, G chooses a semi trusted platform T . G
then sends the proxy certificate, the numbers a and b, H, ∆, v and all the
verification keys vi to T . Each mobile agent Ai gets H, ∆, si , v and vi .
4.1.3
Broadcasting Phase
The mobile agents Ai are now sent out to the different hosts (this means that
G can go offline now). The first task that they will perform, is to collect the
offers from the different hosts and decide which one is the best. They will
use hash chaining to accomplish this (see section 3). There is however one
modification that we have to make to this protocol. Instead of encrypting
everything with the public key of the host G (in section 3, G is called S0 ), the
public key of T is used! Another small modification is that the dummy offer
o0 will contain the identity of the originator G and the restrictions R. When
the offers have been collected, they are sent to T . T then chooses the best
offer. Note that afterwards, T can be asked to prove that it has done this
correctly (T cannot modify the chain of encapsulated offers). T calculates
the number xs = h(G, B, of f er) with of f er the best offer and B the host
that has presented this best offer. We assume that T will perform this task
correctly. Finally, T sends xs to every mobile agent Ai .
4.1.4
Partial Signing Phase
After receiving the number xs, the mobile agents Ai will construct a partial
signature (which will contain information about the best offer). They will
do this by calculating the number hi (∈ QN ):
hi = H 2∆·xs·si
(4.2)
This partial signature hi is a share of the ultimate signature (H xs )d (this value
can be considered as a contract that contains all the necessary information
(G, B, R and the of f er) and that is signed by the private key d). The mobile
agents Ai also need to calculate a commitment to prove that hi is correct
(without revealing si ). Ai will do this by making use of the hash function g()
which is known by all parties. Let us suppose that the output of g() is 128
bits. To calculate the commitment, Ai chooses a random number r of 1280
bits3 and computes the couple (ci , zi ):
ci = g(v, H 4∆·xs , vi , h2i , v r , H 4∆·xs·r )
3
(4.3)
The number r has L(N ) + 2L1 bits where L(N) is equal to the number of bits of the
modulus N and L1 is equal to the number of bits of the output of g().
16
zi = si · ci + r
(4.4)
This couple (ci , zi ) is the commitment on the partial signature hi . It looks
very complicated, but it is just a proof that the discrete log of h2i (= H 4∆·xs·si )
to the base H 4∆·xs is equal to the discrete log of vi (= v si ) to the base v.
Ai now sends the share hi with the commitment (ci , zi ) to T . T checks
all incoming shares hi by computing the values c0i (note that T possesses all
the values vi ):
i
)
c0i = g(v, H 4∆·xs , vi , h2i , v zi · vi−ci , H 4∆·xs·zi · h−2c
i
(4.5)
If this value c0i is equal to ci , then the commitment on the partial signature
hi is correct. Because there are at least kA agents Ai which are not affected
by a malicious host, T will always get at least kA correct shares hi . If
there are more than kA shares hi with correct commitment, then T picks
out (randomly) kA of them. Let us call this group of kA agents Ai the group
S. So S is a subset of the set { 0, 1, . . . , nA } .
4.1.5
Reconstruction Phase
T will now reconstruct the signature (H xs )d from the kA shares hi . We will
derive how T can do this (instead of just giving the formula).
Let us start from formula A.2. Because the prime factors of M (p0 and q 0 )
are bigger than nA , xi can be replaced by i and everything can be calculated
mod M (see also appendix A). The result is the following formula:
f (x) =
X
f (i)
i∈S
Y (x − j)
mod M
(i − j)
j∈S,j6=i
(4.6)
Let us take x = 0 and multiply both terms with ∆:
d · ∆ = f (0) · ∆ =
X
f (i) · ∆
i∈S
j
mod M
(j − i)
j∈S,j6=i
Y
(4.7)
The right part of formula 4.7 will be denoted by λSi :
λSi = ∆
j
(j − i)
j∈S,j6=i
Y
(4.8)
T computes all these kA values λSi . This cannot be done in advance because
S is only known at the end of the partial signing phase (section 4.1.4). A
very important remark is that the values λSi are not calculated mod M (T
does not know M )! Also notice that λSi = ∆ · ci,S (see formula A.3).
17
After creating the values λSi , it is very easy to construct the signature
(H ) . T first computes a value w:
Y 2λS
w=
hi i mod N
(4.9)
xs d
i∈S
If one combines formula 4.2 and formula 4.9, one gets:
Y
S
w=
H 4∆·xs·si ·λi mod N
(4.10)
i∈S
Finally, if one takes into account formula 4.7 and the fact that f (i) = si ,
formula 4.10 becomes:
w = H 4∆
2 ·xs·d
modN = (H xs )4∆
2 ·d
mod N
(4.11)
By using the numbers a and b (see formula 4.1), T computes the digital
signature (H xs )d as follows:
(H xs )d = wa (H xs )b mod N
4.1.6
(4.12)
Finalization Phase
To finalize the payment protocol, T sends the following tuple to B:
(xs, (H xs )d , proxy certif icate)
(4.13)
B sends this tuple to the bank to validate it. This will only happen if the
tuple is valid (i.e. if the signature is valid, if the offer complies with the proxy
certificate, . . . ). If the tuple is validated, the bank will transfer the specified
amount of money from G to B. Afterwards, the tuple is not destroyed but
kept as proof that the user G bought certain goods from B.
4.2
4.2.1
Short analysis
Security parameters
It would take far to many pages to completely analyze the payment protocol
of the previous section. Shoup [14] proves the security of the technique of
undetachable threshold signatures used in this protocol. There are three
important security parameters in the protocol: kA , L(N ) (the number of bits
of N ) and L1 (the size of the output of g()). The last one, L1 , determines
the difficulty of an attacker to forge a commitment. Shoup suggests that 128
bits are sufficient [14]. L(N ) depends on the lifetime of the signature. This
will probably not be very long (maximally a couple of years), so 1024 bits
are sufficient.
18
4.2.2
Upper limit on the number of mobile agents
An interesting question is if there is an upper limit on the number of mobile
agents that are used in the payment protocol. At first sight, this is a very
strange question to ask. Intuitively, one would think that the more agents
ones uses, the more secure the scheme becomes. This is however only true
until the number of agents (nA ) reaches a certain limit. If that limit is
exceeded, then the attacker can perform a so called ‘∆–attack’.
Recall that the number ∆ (which is known by all parties) used in the
payment protocol is equal to ∆ = nA ! mod M . This formula can be rewritten
to (nA ! − ∆) = m0 · M where m0 is a small number and M a very big number
(L(N ) − 2 bits). So if the number of agents (nA ) is not very big, then m0 is
zero and the attacker learns nothing. If nA increases, then nA ! will increase
very fast and will soon become larger than M . If this is the case, then m0 is
not zero anymore, but still quite small. The attacker can then just try some
m0 (he knows nA and ∆) until he finds M . If the attacker possesses M , then
he can easily determine the secret key d (d = e−1 mod M ). This means that
the following formula must always hold:
nA ! < M
(4.14)
Let us calculate the upper limit of formula 4.14 for the case that the
size of N is 1024 bits. This means that M is a 1022 bit number and thus
always smaller than 21022 (but larger than 21021 ). One can calculate that
170! < 21021 < 21022 < 171!. So the upper limit for nA is 170. Note that this
limit is probably not problematic in realistic scenarios.
4.2.3
Updating the secret key
The protocol of Borselius et al [13] is secure, but also very efficient when it is
used in our scenario. Most of the computations are done in the initialization
phase, but this phase has to be executed only once. After that the temporary
keypair (d, e) has been created and distributed among the nA mobile agents
Ai , it can be used for many purchases (for every different good that has to be
bought, the user G has to make a different proxy certificate and a different
number H). This is very important, because if the mobile agents could only
be used to make 1 acquisition, then it would be better not to use mobile
agents!
The temporary keypair (d, e) can however not be used infinitely! We
observe that problems arise when the mobile agents are travelling from host
to host, in contrast to threshold schemes in the traditional scenarios proposed
in the literature! Once a mobile agent is under control of an attacker, it can
19
not be trusted anymore. Every time the agents travel to another host, some
“benignant” agents will visit a malicious host and will fall into the hands of
the attacker. So the number of untrusted agents will continuously increase
and will eventually become larger than kA (and the assumption that there at
least kA benignant mobile agents becomes invalid). This means that secret
sharing using mobile agents is a dynamic problem instead of a static one
as assumed in traditional scenarios. The payment scheme should thus be
extended with an update mechanism. One could for example use proactive
threshold schemes [16] in which the shares si of the secret key d are updated
regularly.
4.2.4
Denial of service attacks
As already mentioned in section 2.3, a good countermeasure for denial of
service attacks is using multiple agents. The payment protocol will generate
a valid signature as long as kA mobile agents are executed correctly. This is
however only true if the semi-trusted host T executes the protocol correctly.
To be more precise, we assume that T only performs passive attacks (like
eavesdropping), but no active attacks (like modifying data). This is the only
assumption that has to be made about T and it can certainly be realized in
practice. The conclusion is that our scheme is quite robust against denial of
service attacks.
20
Chapter 5
Extension: Environmental Key
Generation
A possible extension in our scenario is the technique of environmental key
generation [17]. This technique can be used in situations where the agents
have to keep secret what they are looking for. They will only reveal it to the
hosts that sell the desired item. All the other hosts will not know what the
agents want to purchase (they will only know that they do not sell it).
The aim of environmental key generation is to encrypt the agent in such
a way that it can only be decrypted when a certain condition is fulfilled. Let
us assume, as stated above, that the condition that needs to be fulfilled is
the fact that the host sells a certain item. So the mobile agent may only
be decrypted if this condition is true. A very simple method to accomplish
this, is to encrypt the agent with the key K = h(IT EM ) where IT EM is
the string representation of the desired item (e.g., IT EM could be “plane
ticket” if the agent has to buy a plane ticket) and h() a cryptographic hash
function. The agent also carries the value X = h(h(IT EM )). When the
agent visits a host, it looks into the database of goods that the host sells and
checks for every item I if h(h(I)) = X. If this condition is true (this means
with very high probability that I = IT EM ), then the agent is decrypted
with the key h(I). If the condition is not fulfilled, then the agent cannot
be decrypted and it is impossible for the host to know what the agent was
looking for. Other, very similar methods can be found in [17].
21
Chapter 6
Practical implementation
As a proof of concept, the entire mobile agent- based e–commerce scenario
has been implemented in the scope of three Master’s theses [18, 19, 20] on
a Personal Digital Assistant (PDA) with a clock frequency of 206 MHz (32
bit RISC processor). More specifically, we have demonstrated the practical
feasability of the following mechanisms:
• hash chaining
• payments by multiple agents
• environmental key generation
First, our PDA sends mobile agents to different hosts (we used ordinary workstations). To protect the agents against hosts that do not sell
the required goods, we used environmental key generation. The encrypted
agents are executed in a sandbox on the different hosts and are only decrypted correctly if a certain string IT EM is present in a certain file (e.g.,
the file goods.txt contains the string “plane ticket”). After this decryption,
the agents collect information about the required goods. In our simulations,
we collected the name of the host, the price of the goods and the number
of goods. This means that the best offer is simply the offer with the lowest
price. This information is protected using hash chaining. After the mobile
agents have visited the different hosts, they send the collected information
to a trusted host T . We have simulated the behavior of T by another mobile
agent on a certain host. T decides which of the offers is the best one and
performs together with the mobile agents the payment protocol as described
in section 4.1.
These practical proofs of concept, which are illustrated in figure 6.1, were
made in the Aglets mobile agent framework [21], a platform based on Java
22
Figure 6.1: Simulation of the agent-based scenario
and especially designed for implementing mobile agent systems. Alternative
platforms are Telescript [22], Sumatra [23], Grashopper [24], . . . References
to other agent frameworks can be found in [25]. The advantage of Aglets is
that the code is open source and can easily be adjusted. In Aglets, an agent
execution environment is called a context. Mobile agents can travel from one
context to another context. There can be multiple contexts on one physical
host. In addition to the implementation of the three mechanisms, SSL/TLS
[8] has been incorporated into Aglets in order to secure the communication
between Aglet contexts [18]. The communication in any agent framework,
whether or not supporting mobile agents, can be secured in this way.
PDAs have less computing power and memory than a workstation. That
is why we need to use Personal Java instead of the standard Java edition.
With Personal Java, all mobile devices like a PDA, digital set-top boxes,
navigation systems, . . . have the same Java platform. This makes it very
easy to transfer software from one device to another. Most packages of Personal Java originate from version 1.1 of the Java architecture. New packages
from version 2 are not included in Personal Java. Personal Java is however
built on the same security architecture as in Java 2. This means that most
applications - in our case the Aglets platform - that are developed for version 1.1 are in principle transferable to Personal Java without any problems
and that these applications can make use of cryptographic primitives. If the
application is written for version 2, then some problems could arise if the
application uses methods which do not yet exist in version 1.1.
23
Chapter 7
Conclusion
One of the major applications of mobile agents will be e-commerce. Agents
are very mobile and can act completely autonomous and are therefore a
perfect technique to use on mobile devices. There is however one serious
drawback on using mobile agents in e-commerce and that is the problem of
protecting an agent from malicious hosts.
This paper has presented a set of possible solutions to this problem. The
scheme that has been discussed uses hash chaining to securely collect information (protection of the integrity) from different hosts. In a next phase, the
technique of undetachable threshold signatures is used to sign a contract with
the host that has presented the best offer to the agents. This scheme can be
extended with an updating mechanism and with environmental key generation. We have proposed a practical mobile agent-based scenario in which the
presented scheme can be used efficiently. We have implemented this scheme
on a PDA by using Aglets, a platform designed for mobile agents. Finally,
we have made some important observations on using threshold schemes in
the context of mobile agents.
24
Acknowledgements
Dave Singelée is funded by a research grant of the Institute for the Promotion
of Innovation by Science and Technology in Flanders (IWT). Part of this
work has appeared in [5]. For this work, Joris Claessens was funded by a
research grant of the same institute. This work was also supported in part
by the FWO-Vlaanderen project G.0358.99 on Open Security Systems for
Agent-based Applications (OSABA), and by the Concerted Research Action
(GOA) Mefisto-2000/06 of the Flemish Government. The authors would
finally like to thank Frank Piessens, Dries Indesteege, Vincent Jacobs and
Vincent Touquet for their contributions of their master thesis to this paper.
25
Bibliography
[1] David M. Chess, Benjamin Grosof, Colin G. Harrison, David Levine,
Colin Parris, and Gene Tsudik. Itinerant Agents for Mobile Computing.
IBM Research Report RC 20010, March 1995.
[2] David M. Chess, Colin G. Harrison, and Aaron Kershenbaum. Mobile
Agents: Are they a good idea? In Jan Vitek and Christian Tschudin,
editors, Proceedings of the Second International Workshop on Mobile
Object Systems: Towards the Programmable Internet, Lecture Notes
in Computer Science, LNCS 1222, pages 25–45. Springer-Verlag, April
1997.
[3] David Kotz and Robert S. Gray. Mobile Agents and the Future of the
Internet. ACM SIGOPS Operating Systems Review, 33(3):7–13, July
1999.
[4] Danny B. Lange and Mitsuru Oshima. Seven Good Reasons for Mobile
Agents. Communications of the ACM, 42(3):88–89, March 1999.
[5] Joris Claessens. Analysis and design of an advanced infrastructure for
secure and anonymous electronic payment systems on the Internet. PhD
thesis, Katholieke Universiteit Leuven, December 2002. 220 pages.
[6] William M. Farmer, Joshua D. Guttman, and Vipin Swarup. Security
for Mobile Agents: Issues and Requirements. In Proceedings of the 19th
National Information Systems Security Conference, 1996.
[7] Wayne Jansen and Tom Karygiannis. Mobile Agent Security. NIST
Special Publication 800-19, October 1999.
[8] Tim Dierks and Eric Rescorla. The TLS Protocol Version 1.1. IETF
Internet Draft, March 2003.
[9] Fritz Hohl. A Model of Attacks of Malicious Hosts Against Mobile
Agents. In Proceedings of the 4th ECOOP Workshop on Mobile Oject
Systems: Secure Internet Mobile Computation, July 1998.
26
[10] Joris Claessens, Bart Preneel, and Joos Vandewalle. (How) can mobile
agents do secure electronic transactions on untrusted hosts? – A survey
of the security issues and the current solutions. ACM Transactions on
Internet Technology, 3(1):28–48, February 2003.
[11] Günter Karjoth, N. Asokan, and Ceki Gülcü. Protecting the Computation Results of Free-Roaming Agents. In Kurt Rothermel and Fritz
Hohl, editors, Proceedings of the Second International Workshop on Mobile Agents, Lecture Notes in Computer Science, LNCS 1477, pages 195–
207. Springer-Verlag, September 1998.
[12] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbook of Applied Cryptography. CRC Press, October 1996.
[13] Niklas Borselius, Chris J. Mitchell, and Aaron Wilson. Undetachable
Threshold Signatures. In Bahram Honary, editor, Proceedings of the
8th IMA International Conference on Cryptography and Coding, Lecture
Notes in Computer Science, LNCS 2260, pages 239–244. Springer-Verlag,
December 2001.
[14] Victor Shoup. Practical Threshold Signatures. In Bart Preneel, editor,
Advances in Cryptology – EUROCRYPT 2000, Lecture Notes in Computer Science, LNCS 1807, pages 207–220. Springer-Verlag, May 2000.
[15] Artur Romão and Miguel Mira da Silva. Proxy certificates: a mechanism
for delegating digital signature power to mobile agents. In Yiming Ye and
Jiming Liu, editors, Proceedings of the Workshop on Agents in Electronic
Commerce, pages 131–140, December 1999.
[16] Amir Herzberg, Markus Jakobsson, Stanislaw Jarecki, Hugo Krawczyk,
and Moti Yung. Proactive Public Key and Signature Systems. In Proceedings of the 4th ACM Conference on Computer and Communications
Security, April 1997.
[17] James Riordan and Bruce Schneier. Environmental Key Generation
Towards Clueless Agents. In Giovanni Vigna, editor, Mobile Agents and
Security, Lecture Notes in Computer Science, LNCS 1419, pages 15–24.
Springer-Verlag, 1998.
[18] Dries Indesteege and Vincent Jacobs. Security aspects of mobile agents
and PDAs (in Dutch). Master’s thesis, K.U.Leuven, 2002.
[19] Dave Singelée. Secure digital signatures using mobile agents on untrusted platforms (in Dutch). Master’s thesis, K.U.Leuven, 2002.
27
[20] Vincent Touquet. Protecting mobile agents in hostile environments (in
Dutch). Master’s thesis, K.U.Leuven, 2002.
[21] Danny B. Lange and Mitsuru Oshima. Programming and Deploying
Java Mobile Agents with Aglets. Addison-Wesley, September 1998.
[22] J. E. White. Telescript Technology: The Foundation for the Electronic
Market Place. White paper, General Magic Inc, 1994.
[23] Anurag Acharya, M. Ranganathan, and Joel Salz. Sumatra: A Language
for Resource–aware Mobile Programs. In J. Vitek and C. Tschudin,
editors, Proceedings of the Second International Workshop on Mobile
Object Systems: Towards the Programmable Internet, Lecture Notes in
Computer Science, LNCS 1222, pages 111–130. Springer-Verlag, April
1997.
[24] IVK++ Technologies. AG Grasshopper 2. http://www.grasshopper.
de.
[25] Cetus. Mobile Agents.
agents.html.
http://www.cetus-links.org/oo_mobile_
[26] Yvo Desmedt. Society and group oriented cryptography. In C. Pomerance, editor, Advances in Cryptology Crypto ’87, Lecture Notes in Computer Science, LNCS 293, pages 120–127. Springer-Verlag, 1987.
[27] Susan K. Langford. Threshold DSS Signatures without a Trusted Party.
In Don Coppersmith, editor, Advances in Cryptology – CRYPTO’95,
Lecture Notes in Computer Science, LNCS 963, pages 397–409. SpringerVerlag, August 1995.
[28] Adi Shamir. How to share a secret?
22(11):612–613, November 1979.
28
Communications of the ACM,
Appendix A
Secret Sharing
The principle of secret sharing is to divide a secret (e.g., the private key
to calculate a digital signature) among n parties (e.g., mobile agents) such
that every group of k or more parties can reconstruct the secret, but that
every group of less than k parties has absolutely no information about the
secret. This can be accomplished by using the threshold scheme of Shamir
[26, 27, 28].
A.1
Shamir’s Threshold Scheme
The threshold scheme of Shamir is based on the interpolation of polynomials.
To construct a polynomial of degree m by interpolation, one needs at least
m+1 distinct points of that polynomial. If only m or less points are available,
one cannot uniquely determine the polynomial. This is exactly the property
that we need for secret sharing.
Suppose we have a finite field GF (q) with q a very large prime number.
The user who wants to divide a secret d among n parties chooses k − 1
random numbers ai in the field GF (q) and takes a0 = d. Then he constructs
the following polynomial in the field GF (q):
f (x) =
k−1
X
ai x i
(A.1)
i=0
Notice that f (0) = d. It follows that when one knows the function f (x), one
also knows the secret d. The function f (x) has degree k − 1, so at least k
points (xi , f (xi )) are necessary to reconstruct f (x) (and thus to determine
the secret d). If one has less than k points, one can not reconstruct f (x).
This is exactly what we need! It is quite obvious that every mobile agent will
29
get such a couple (xi , f (xi )). A group S of k mobile agents will reconstruct
f (x) by interpolation:
f (x) =
X
i∈S
f (xi )
(x − xj )
mod q
(x
i − xj )
j∈S,j6=i
Y
(A.2)
If we replace x by 0 in formula A.2, we get f (0). So we can calculate the
secret d by using formula A.3:
X
d = f (0) =
ci,S f (xi ) mod q
(A.3)
i∈S
ci,S is a constant that can be calculated in advance if one knows which group
of k agents will be used to calculate d. This constant does not depend on
the secret d.
Formula A.3 can be simplified in certain circumstances. It is sometimes
possible to calculate everything modulo m (m does not have to be a prime
number) instead of working in GF (q). This is the case when the values
(xi − xj ) have an inverse for every value of i and j. If every agent gets the
couple (i, f (i)) (so xi = i), then the aforementioned condition is completely
analogue to the requirement that m does not have prime factors smaller than
n (the number of mobile agents) [27].
A.2
Verifiable Secret Sharing
How does one know which k values have to be used to reconstruct the secret
d? An attacker could try to present a wrong value f (i) so that the secret d
won’t be reconstructed. To avoid this attack, every agent has to prove that
it gives the correct value f (i). This proof must however not reveal any information about f (i), so a special zero-knowledge proof (called commitment
in the rest of this paper) is needed. There are different methods to construct
such a commitment. If one extends Shamir’s secret sharing scheme with the
technique of commitments (which will always be done in practice), then this
extended technique is called verifiable secret sharing.
A.3
Choice of the parameter k
The previous sections have explained how a group of k mobile agents (out
of a total of n agents) can reconstruct a secret d. How does one choose the
parameter k? This is an import problem, because the security of the secret
sharing scheme depends on this choice.
30
First, one determines an upper bound on the number of mobile agents
that are under control of an attacker. Lets call this upper bound t. k certainly
has to be larger than t, because otherwise the attacker could calculate d. So
k has to be as large as possible! One can however not choose k larger than
n−t, because this would mean that there are not enough “benignant” mobile
agents to calculate d. In most cases, t is very difficult to determine, so one
chooses k larger than (or equal to) n2 .
31