Future areas of application for mobile agents technology are open, distributed and decentralized networks, where Mobile Agents autonomously perform tasks on behalf of their principals . In this paper, we address the conceptual design of payments for and between Mobile Agents, particularly against the background of the Malicious Host Problem. We analyze the requirements on payment systems for Mobile Agents and give a survey on existing technical solutions partially matching these requirements. We then discuss a new concept that does not require Mobile Agents to hold secrets and that allows allocations of digital coins and agents even in an environment that contains Malicious Hosts. The concept is based on the principles of accounting systems.
Mobile Agents (MoA) are software entities able to migrate autonomously from one host to another (cf.
[
Setting up payment systems for Mobile Agents (PSMA) is one possible solution to meet these needs. When designing PSMA, the Malicious Host Problem (MHP) has to be taken into account. The MHP refers to the inability of MoA to use as well as hide information from hosts executing them (cf. Section 2). For (secure and tamper-proof) PSMA, this raises questions about their technical feasibility, since existing electronic payment systems are based on the usage of specific secrets, e.g., private keys.
In this paper, we deal with the design of (secure and tamper-proof) PSMA. According to
requirements on PSMA not complied by other solutions we develop a PSMA subsystem for allocating2
MoA and digital coins. Assuming that the MHP is not adequately solvable yet (cf. [
The paper is structured as follows. In Section 2 we discuss PSMA taking into account the MHP. In Section 3 we analyze the requirements for a PSMA by deducing them from the goals of the principals (3.1). We give a survey on existing technical concepts possibly suitable for PSMA and discuss them in view of the requirements that have been identified (3.2). Section 4 describes our allocation concept. Starting with the assumptions we made in 4.1, we give a rough draft of our concept in 4.2. Section 4.3 1 Within this paper, owners of Mobile Agents or hosts are named principals. Except for the term, there are no relations to the concept of principals used in the principal-agency theory. 2 With the allocation of MoA and coins, we address the concept of linking at least one coin to one MoA in a way that only this agent can dispose of the coin. gives a simple example of the double-spent detection mechanism. We discuss unsolved questions, next steps of our research and the evaluation of future results in Section 5.
A PSMA is a system enabling MoA to balance debt and credit. Debt and credit are generated when
agents access resources provided by other agents or hosts, both owned by principals different from
theirs. We assume that principals have economic interests, which they link to the agents or hosts
administrated and owned by them. Thus, PSMA can be seen as systems supporting the (price/market
based) coordination of (economic) interests of principals – MoA pay for access to resources using
digital money provided by their principals. The resource-owning principals receive the money and are
able to either deposit it in their bank accounts or to use it otherwise (cf. Figure 1). Like any kind of
money, the digital information MoA use for payment has to fulfil three functionalities: medium of
exchange, storage of value, and measurement of value. (cf. [
Conventional electronic payment systems generally can be grouped into two classes – token/cashbased or account/check-based electronic payment systems (cf. [1]). Account/check-based systems use orders signed by the payer and sent to a central clearing institution in order to transfer the specified amount of money to the payee’s account. Since a clearing institution is involved in each financial transaction, one of their characteristics are high minimum transaction costs (considering both the involvement of a third party and high security costs of the clearing server), compared with token/cashbased systems. Thus, they are unsuitable for nano- and micropayments, which will primarily take place in future PSMA. Token/cash-based payment systems incur lower transaction costs, especially when realized as multistage and offline systems (assuming that tampering can be prevented). Thus, they may be better suited for nano- and micropayments between MoA.
For our work, we focus on PSMA defined as systems consisting of token/cash-based electronic
money (cf. [
The fact that MoA can be executed by hosts not owned by the same principals leads to the MHP. It
refers to the ability of any agent-executing host to attack the MoA, for example by spying out or
manipulating code, data or execution state (cp. [
Conventional electronic payment systems use cryptographic methods for generating electronic
money. They rely on secrets held by the payer, the payee and other involved actors. These secrets can
either be private keys used for signature generation and authentication or digital coins (cp. [
Conventional electronic payment systems can be described by means of a generic (financial) transfer
and role model (cf. [
The names of agent roles have been selected to reflect their position within the payment circuit. Additionally, we defined a virtual currency area that represents an arbitrary set of (connected) MoA execution platforms. Agents’ payments are restricted to this currency area.
According to the roles and their specific position in the financial circuit, we assigned superordinate goals to each principal’s role. We then decomposed and consolidated these goals from a MoA oriented perspective, i.e., the principals’ goals were transferred to the MoA as possible. As a result, we obtained high-level requirements on PSMA.
Among high-level requirements that are, e.g., related to the general functionality of MoA and platforms, we identified two groups of high-level requirements important for our work: requirements related to electronic money per se and requirements related to the allocation of electronic money to MoA.
The requirements related to electronic money are identical with those defined in literature for
conventional electronic money: identification of counterfeit and double-spent money, non-linkability of
payment and withdrawal, traceability of transactions for the payer and the payee, ex post integrity of
payments, adequate transaction costs, etc. (cf. [
The high-level requirements we identified on an allocation system providing one-to-one allocations are: • consistency of allocations even by migrations of agents, • verifiability of allocations, i.e., the ability to identify tampered allocations by MoA, hosts and principals, • interchangeability of allocations, i.e., the transfer of allocations from payers to payees, • robustness of allocations, e.g., their restorability in case of host or connection breakdown, • divisibility of allocations, unless the allocations are not related to an atomic finance unit.
These requirements overlap with requirements for electronic money. For instance, while implementing all required allocation functionalities the requirement “identification of double-spent money” could also be met as long as verifiability of one-to-one allocations is granted.
A final and complete technical solution for the MHP would enable MoA to hide and use secrets. In this case, conventional electronic payment technology could be used for PSMA. Thus, a literature review has to consider both explicit work on payment technologies for MoA and implicit work addressing the MHP directly.
The implicit research on PSMA can be divided into six groups: research on Mobile Cryptography, Code Obfuscation, Environmental Key Generation, Internal Hardware Extensions, Reference States and Signature Delegation techniques for MoA. Explicit research is based upon distributed threshold schemes (which are also used by some implicit solutions).
The conceptual idea of Mobile Cryptography is to encipher the code and all data of a MoA in a
way so that the agent is still executable in its encoded form. Ideally, the encoded MoA is still able to
handle inputs and outputs without loosing its cryptographic protection. [
Research on Code Obfuscation for MoA has been done by [
[
[
The family of Reference States address approaches based on the ex-post comparison of MoA
execution states. Two subclasses can be identified: approaches that deal with the ex-post comparison
by hosts next in the migration route of MoA (cf. [
The Signature Delegation group consists of undetachable signature (cf. [
An explicit approach to enable MoA to pay for, e.g., service access is presented by [
Examining the five high-level requirements related to allocation subsystems, we have to note that, with the exception of Hardware Extensions, none of the outlined concepts is suited to serve as a basis for a PSMA yet. Either further development and evaluation is needed or the characteristics of the technology concepts themselves are not suitable for adaptation. For Hardware Extensions, their practical applicability is questionable.
The development of an allocation subsystem for PSMA should take into account general conditions of
MoAs’ environments. By making following assumptions we tried to capture these conditions:
• Within MoAs’ environments, two types of actors can be identified: MoA and (executing)
hosts. Both are able to join and leave the network.
• When a MoA is located on a host, it is not possible to detect what happens to it (e.g., if it is
being copied or analyzed). Hosts have to be interpreted as black boxes, only revealing
information about their internal processes when something leaves the box (cf. [
As basic requirements we assume the existence of the following infrastructure and hosts’ properties: • Each host joining the environment has a (published) unique identifier (uid). • A Public Key Infrastructure (PKI) exists, which enables (a) hosts to create and validate digital signatures (related to their uid), (b) principals to sign their MoA and (c) MoA to transport secrets for their principals (without using them). • An anonymization service exists that decouples MoA from their principals. As a result, everyone can trace MoA and their financial transfers without identifying the principal. • There is a clearing infrastructure acting as an institution that withdraws and accepts electronic coins. The clearing infrastructure always knows how much money circulates by balancing deposited and issued coins.
As far as the last assumption is concerned, we decided to use digital coins according to the
MicroMint micropayment scheme as it has been proposed by [
Our basic idea for an allocation subsystem is twofold, addressing both the position of the allocation subsystem and its openness. As far as position is concerned, the subsystem has to be managed not at the MoA level, but at the host level. That is, hosts manage the allocations between MoA and digital coins – they change allocations if MoA pay, verify allocations and manage valid transfer between each other if MoA migrate. Hosts, i.e., principals operating hosts, have to be responsible for a valid allocation management. To prevent tampering, hosts have to be real time controlled by other hosts, for instance, a group of hosts that cooperate for allocation management. MoAs are integrated in this allocation subsystem only passively for documentation and control. They carry information about allocations in a way that is not modifiable ex-post. In terms of openness, the idea is to restrict the PSMA and thus the allocation subsystem so that it is open to MoA and hosts, but 4 This assumtion bases on proposition 1 given in [2]. “closed” to digital coins and allocations. Thus a currency area has to be created. Digital coins have to be valid only if they are located permanently inside this area. Once they leave the area, coins are not restorable. As a consequence, the overall amount of money in circulation is constant (or decreasing). Detection mechanisms are needed to give alert when the amount rises. Double spent coins and the use of counterfeit coins can thus be avoided.
Using accounting techniques for a PSMA allocation system, an accounting web for hosts and MoA has to be created. Normally, accounting systems are kept by one central institution. For PSMA, the accounting web needs to be both distributed and decentralized, since a centralized design would lead to higher transaction costs (cf. Section 2). It would also raise the question of (secure) authentication and it does not comply with the offline characteristics of digital money given in Section 2.
Our concept uses files representing accounts. These account files are made forward secure by
cryptographic methods, i.e., they are designed to enable writing and reading to everyone, but inhibit
(unnoticeable) deletion and manipulation of previously stored information (cf. [
Structure of the accounting web: In addition to the account !I related to the clearing infrastructure, an accounting web is build on the basis of three kinds of account rows5: rows of accounts !MA related to MoA, rows of accounts !H related to hosts and rows of accounts !G related to groups of hosts.
Within an accounting web consisting of only one group G=1 of n hosts and m MoA, n,m " N, located on these hosts, the following accounts exist: • ! 1I , the clearing infrastructure account, where all withdrawals and deposits are recorded, • • • ! 1G , the group account, where all input and output transactions of the group G=1 are recorded, ! 1H , ...,! kH , ...,! nH , the hosts’ accounts, where all transaction between hosts (i.e., agents located at these hosts) are recorded. Each account ! kH is located on and managed by one host. The set of all hosts’ accounts ! kH that belong to group G=1 is named TGH=1 , ! 1MA , ...,! iMA , ...,! mMA , the MoA accounts where all transaction between agents are recorded. Each account ! iMA is related to and located at a MoA and managed by the hosts executing this agent. The set of all MoA accounts of group G=1 is named TGM=A1 , while the set of all MoA related to host k is THM=Ak
Within a group of hosts, the sum of the MoA account row, and the sum the hosts account row and the group account represent the same value: the total amount of money that exists within this group.
n m (1) ! 1G = " ! kH = " ! iMA , where |!| is the sum of all entries of an account ! ,
k=1 i=1
Within the accounting web, the sum of all group accounts has to be equal to the sum of the clearing infrastructure account. For a given one-group accounting web, that is ! 1I = ! 1G . For accounting webs consisting of o groups, o " N, it has the form:
o (2) ! 1I = " ! G
p p=1
As mentioned above, the accounting web has to be open for hosts and MoA. MoA can enter the accounting web by migrating to a host that is already member of the accounting web and by receiving an empty or credited account from the clearing infrastructure. When receiving a credited account, the MoA also receives digital coins (of the same value) from the issuer. It is not possible for MoA to bring 5 An account row is a set of accounts structuring a datum in a specific way. Multiple account rows addressing the same datum allow different perspectives on this datum, e.g. source and disposition of funds. money with them into the accounting web. Hosts can enter the accounting web when enough new hosts are available for a new group (in our specification: n hosts). They are also not allowed to bring money with them and receive their accounts from the clearing infrastructure. Both MoA and hosts are able to leave the web. Since money cannot re-enter the accounting web, they need to be cleared by transferring all money to other hosts/agents staying inside the web. Otherwise the money is lost.
Transactions within the accounting web: Within the accounting web, each financial transaction, i.e., transfers of coins from one MoA to another or MoA migration, generates entries to the accounts. We describe transactions by accounting functions ef , f = 1,…,h , h " N. An accounting function ef links specific debit and credit accounts and a set of coin IDs to a value. For all ef applies: (3) ef : T D ! T C ! ID " V , where TD gives all accounts being debited, TC gives all accounts being credited, ID is the set of all coins (coin id) and V is the set of all values composable of the elements of ID. • • • • • • • Thus, within a specific group of hosts three archetypes of transactions can be identified: payments between two MoA located at the same host: ef ({! iMA } , {! MjA } , {idr }) = vijr , payments between MoA located at different hosts: ef ({! kH ,! iMA } , {! lH ,! MjA } , {idr }) = vkiljr migrations of a MoA between hosts: ef ({! kH } ; {! lH } , {idr }) = vxyr With more than one group, two additional archetypes can be identified: migrations of MoA between groups of hosts: ef ({! Gp ,! kH } , {! qG ,! lH } , {idr }) = vpkqlr payments between MoA located in different groups of hosts: ef ({! Gp ,! kH ,! iMA } , {! qG ,! lH ,! MjA } , {idr }) = vpkiqljr
Considering the clearing infrastructure, another two archetypes of financial transactions can be identified: withdrawal of digital coins: ef ({! I } , {! qG ,! lH ,! MjA } , {idr }) = vIqljr and deposit of digital coins: ef ({! Gp ,! kH ,! iMA } , {! I } , {idr }) = vpkiIr
Each accounting function is related to entries in at least two accounts. These entries include the receiving/spending account, the value v that is being transferred, the IDs of the coins used for the transfer, a time stamp, the host recorded the entry and a description of the service/resource paid/sold.
Characteristics: The accounting web described above allows controlling the integrity of the system as it allocates digital coins to MoA. The allocation is realized by recording transfer of ownership to MoA, hosts and group accounts. The presented accounting based allocation concept addresses all five requirements shown in Section 3.1. Fraud allocations can be detected in two ways: by ex post examination of the payments a MoA has made and by checking the account balance.
The ex-post examination of MoA payments is still comparable to conventional logging. Each
principal is able to check the income and the payments of its MoA either after the task fulfillment or
after a specific time period. He can thus identify payments that do not correspond to the agent’s task or,
when for instance cryptographic tracing according to [
With the account balance, we describe the validity of equation (1) for all groups r of hosts and the equation (2) for the whole accounting web at any time of a PSMA lifecycle. The validity of equation (1) is checked by a group r of n hosts each time a MoA enters or leaves the hosts that belong to group r. Each host has to cast the MoA accounts located on it and publish the balance for the other group members. All hosts within the group are able to check if the overall balance is equal to the balance of the group account ! Gp. If
m ! Gp " # ! iMA
i=1 an error or fraud is detected and further steps have to be taken, e.g., the check of equation (2) and the concrete analysis of the group’s activities.
As long as (1) and (2) are true, the amount of money withdrawn (and not yet deposited) is equal to the amount of money circulating within the accounting web. It is not possible to double spent digital coins, since with the (second) entry this balance is lost and the double-spending is detected by the next balance check. Also, when coins are stolen, e.g., by a malicious host executing a MoA, the stolen money is worthless, as its reintegration into the accounting web would either lead to a discrepancy or, when kept outside the accounting web, cannot be deposited back in the clearing infrastructure. No payee will accept it.
The simple example of an accounting web supported PSMA addresses the prevention of double spending coins by detecting account unbalances. Thus, we make no use of the option to compare coin IDs as they are stored within the agents’, hosts’ and groups’ accounts. Also, we abstain from an explicit integration of the clearing infrastructure, i.e., the amount of circulating money is constant.
The accounting web consists of two groups with n=2 hosts. At each host, one MoA is located. Each MoA carries two digital coins already recorded in the agents’, the hosts’ and the groups’ accounts. One coin is fixed to the agent, i.e., the agent is not allowed to spend the coin. According to this structure illustrated in figure 2, we have the following accounts: • • • • ! I , where ! I is constant and ! I = 8 , ! 1G ,! 2G , where ! 1G = ! 2G = 4 , ! 1H ,! 2H ,! 3H ,! 4H , where ! 1H = ! 2H = ! 3H = ! 4H = 2 ! 1MA ,! 2MA ,! 3MA ,! 4MA , where ! 1MA = ! 2MA = ! 3MA = ! 4MA = 2 transaction " ! iMA = 5 , i = 1,1*,2 .
e1 (! 1H ;! 2H ; id (coin1* )) = 1 e2 (! 1H ;! 2H ; id (coin1, coin2 )) = 2
Assume that host1 is malicious and generates coin1* by copying coin1 of agent1. When host1 is the only malicious or corrupt actor (hosts and MoA) within the web and only MoA are allowed to use money, host1 is able to spend coin1* in two ways only: (1) to generate agent1* that migrates (away from host1) and spends coin1* ; (2) to disguise itself as agent1 and spend coin1* to e.g. agent4 . Generating an agent1’: With the migration of agent1* from host1 to, e.g., host2, the transaction is recorded within ! 1H and ! 2H . Assume now that agent1 has to migrate too, e.g. to host2, the would lead to an unbalance within group1, as ! 1G = 4 (nothing has entered or left the group) and e3(! 1G ,! 1H ,! 1MA ; ! 2G ,! 4H ,! 4MA ; id(coin1*)) = 1 .
Masquerating as agent1 : Using this second option, host1 would initiate a transaction e4 (! 1H ; ! 2H ; id(coin1,coin2)) = 2 Also, when agent1 migrates to, e.g., host2 and thus a transaction is needed, an unbalance occurs within group1, as ! 1G = 3 (e3 was recorded to ! 1G ) and " ! iMA = 4 .
For the detection of double spending, a transfer of both coin1 and coin1* is needed. One option to achieve this is by imposing time restrictions on MoA stopovers on hosts or group internal agent rotation directives. There are also additional options for malicious hosts when more than one corrupt actor exists, but at least they all will be detected when reintegrating double spent money into the accounting web (at least when depositing the false coins).
In this paper we addressed the design of a PSMA. We identified requirements on PSMA and discussed the suitability of existing technical concepts for an implementation of a coin-MoA allocation system. We presented an account-based solution giving a rough concept of a distributed and decentralized accounting web. The web is managed by all hosts executing MoA. Malicious behavior of one host is controlled by the hosts’ community. The accounting web is designed to be open for MoA and hosts, but closed for (electronic) money.
As a result, continuous allocation of (digital) coins and MoA can be achieved. The accounting web also prevents double-spending and theft of coins as it allows an ex-post detection of cheating hosts. The detection is possible both for MoA principals after the agents have fulfilled their task as well as for other hosts according to an unbalance arising when, e.g., double-spent coins are used. Even MoA brainwashing (according to financial transactions) by malicious hosts may possibly be preventable by combining our concept with cryptographic trace methods.
Our research on accounting based allocation systems and PSMA is still in progress. Therefore some aspects/questions related to the application of accounting webs for MoA-coin allocation are not discussed within this paper. These include: • The need for digital coins when the accounting web is finalized: is it possible to expand the allocation subsystem to a full PSMA without coins? • The systems’ behavior when hosts or groups of hosts crash: is the money also lost when a host disconnects due to a malfunction? What happens with the group if one host disappears? • Malicious groups of hosts: how can we avoid groups consisting of only malicious hosts? And what happens if a malicious host is detected? • The economic transaction recorded by the accounting web: actually only financial transactions are recorded. Are there any advantages when, e.g., the service executions are also journalized? As next steps in the implementation of an account-based allocation system we will address concrete realization of both (1) accounts and (2) protocols for hosts and MoA interaction. While the first step has to take cryptographic methods and the data of the recorded entries into account, the second has to include specifications for hosts’ and MoA entrance and exit of the accounting web, protocols ensuring consistent entries to accounts as well as for checking the accounting balance and rules about the consequences of detected unbalance.
In our future research, we will use the axiomatic-based accounting theory as a method to address these aspects and to advance the given rough concept to a more detailed one. For a final evaluation we plan to use a game theoretic analysis of the principals’ behaviors affected by our concept.
[1] Abrazhevich, D.: Classification and Characteristics of Electronic Payment Systems. In Proceedings of the 2nd International Conference on Electronic Commerce and Web Technologies (EC-Web’01). Springer, Heidelberg, LNCS 2115, 2001, 81-90. [2] Algesheimer, J.; Cachin, C.; Camenisch, J.; Karjoth, G.: Cryptographic Security for Mobile Code.
In Proceedings of the 2001 IEEE Symposium on Security and Privacy (S&P’01). IEEE Computer Society, 2001, 2-11. [3] Al-Jaljouli, R.: Boosting m-Business Using a Truly Secured Protocol for Data Gathering Mobile
Agents. In Proceedings of the International Conference on Mobile Business (ICMoA’05). 2005. [4] Athanassios, B.: Programming Sensor Networks with Mobile Agents. In Chrysanthis, P.; Samaras, G. (eds.): Proceedings of the 6th International Conference on Mobile data management. ACM Press, New York, 2005, 252-256.