can digitally sign transactions in an untrusted environment. We present an agent-based ..... 1p is a safe prime number if p = 2p + 1 with p also a prime number.
Secure e-commerce using mobile agents on untrusted hosts Dave Singel´ee, 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´ee 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¨ unter Karjoth, N. Asokan, and Ceki G¨ ulc¨ u. 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˜ao 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´ee. 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
