TPM-based protection for mobile agents

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks 2010; 4:45–60

Published online 5 January 2010 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.158

SPECIAL ISSUE PAPER

TPM-based protection for mobile agentsAntonio Munoz∗ and Antonio Mana

University of Malaga, ETSII, Campus de Teatinos, 29071 Malaga, Espana

ABSTRACT

Mobile agent is a promising paradigm for emerging ubiquitous computing and ambient intelligent scenarios. We believethat security is the most important issue for the widespread deployment of applications based on mobile agent technology.Indeed, community agrees that without the proper security mechanisms, use of mobile agent-based applications will beimpossible. From our perspective, the security problem in mobile agents is the gathering of two subproblems; the problemof the agent protection and the problem of the host protection. This paper presents a hardware-based mechanism focusedon solving the protection of the agent problem, which is a well known problem named the ‘malicious host’. The solutionpresented in this paper bases its security in the trust and the security functionalities provided by the trusted platform module(TPM). Thus, migration process of mobile agents is protected when it actually takes place. A complete description of thesecure migration can be found in the secure migration protocol section of this paper. Moreover, a validation of this protocolwas performed by means of the AVISPA tool suite. Additionally, a first study about the use of an alternative protocol as thedirect anonymous attestation protocol was done. Finally, the result of this work is the Secure Migration Library for agents(SecMiLiA), which is completely described in following sections. Copyright © 2010 John Wiley & Sons, Ltd.

KEYWORDS

Trusted Computing; mobile agents; cryptographic hardware

*Correspondence

Antonio Munoz, University of Malaga, ETSII, Campus de Teatinos, 29071 Malaga, Espana.E-mail: [email protected]

1. INTRODUCTION

Over the years computer systems have evolved from central-ized monolithic computing devices supporting static appli-cations, into sophisticated environments that allow complexforms of distributed computing. Throughout this evolutionlimited forms of code mobility have existed: the earliest be-ing remote job entry terminals used to submit programs toa central computer and the latest being Java applets down-loaded from web servers into web browsers. A new phase ofevolution is now under way that goes one step further, allow-ing complete mobility of cooperating applications amongsupporting platforms to form a large-scale, loosely coupleddistributed system. It seems that the catalyst for this evolu-tionary path is the mobile software agent role.

Along this paper we define the concepts that determinethe diverse security levels to understand the role of secu-rity in the transmission of private and critical informationthrough an open environment like Internet: (i) Confiden-tiality is the property that ensures that only those that areproperly authorized may be access the information. (ii) In-tegrity is the property that ensures that information cannot

be altered. This modification could be an insertion, deletionor replacement of data. (iii) Authentication is the propertythat refers to identification. It is the link between the infor-mation and its sender. (iv) Non-repudiation is the propertythat prevents some of the parts to negate a previous com-mitment or action.

When we are dealing with agent-based systems, theseproperties are especially important, due to the autonomyand mobility of agents. Thus non-secure agent systems aresenseless in open environment such as Internet. Especiallywhether it deals with critical data, because communicationscould be spied or even the identities of agents faked. Mobileagents are software entities that move code and data toremote hosts. Mobile agents can migrate from host tohost performing actions autonomously on behalf of a user.The last host that executes the agent sends the processedresults to the agent sender, i.e. the origin host as it is alsocalled. The use of mobile agents saves bandwidth andpermits off-line and autonomous execution in comparisonto habitual distributed systems based on message passing.Consequently, mobile agents are especially useful toperform functions automatically in almost all electronic

Copyright © 2010 John Wiley & Sons, Ltd. 45

TPM-based protection for mobile agents A. Munoz and A. Mana

services, like data mining, electronic commerce andnetwork management. Despite their benefits, massive useof mobile agents is restricted by security issues.

Agent migration consists on a mechanism to continue theexecution of an agent on another location [1]. This processincludes the transport of agent code, execution state and dataof the agent. In an agent system, the migration is initiatedon behalf of the agent and not by the system. The mainmotivation for this migration is to move the computation to adata server or a partner to reduce network load by accessinga data server a partner by local communication. Migrationis performed from a source agency where agent is runningto a destination agency, which is the next stage in agentexecution.

One key issue in agent technology is that an agent isthought to live in a society of agents; multi-agent systems(MASs). A MAS is composed of several agents collectivelycapable of reaching goals that are difficult to achieve byan individual agent of monolithic system. This represents anatural way of decentralization, where autonomous agentswork as peers or in teams, with their own behaviour andcontrol. However, in contrast to the Remote evaluation [2]and Code on demand [3] paradigms, mobile agents are ac-tive and choose to migrate between computers at any timeduring their execution. This situation makes mobile agenta powerful technology for implementing Ambient Intelli-gence environment systems and applications.

Software agents are a promising computing paradigm.Scientific community has devoted important efforts to thisfield [4]. Indeed, many current applications exist based onthis technology. Despite of their benefits, a bottleneck ex-ists for the widespread use of mobile agent technology.We aim to the lack of the appropriate security mecha-nisms for agent-based systems. Subsequently, the applica-tion of the current security techniques is not trivial for agent-based system developers, which are usually not securityexperts.

In Reference [4] two different solutions to provide agentprotection are introduced. Firstly, a software-based solu-tion built on the protected computing approach, based onthe previous work of Mana [5]. And secondly, a solution thataddresses the problem of malicious hosts is presented. Thesecond approach consists on a hardware-based solution thattakes advantage from the Trusted Computing Group (TCG)technology. Along this paper we describe in detail this so-lution based on cryptographic hardware.

The remainder of this paper is structured as follows. InSection 2, we describe the problem known as the ‘malicioushosts’. In Section 3, we review the previous work in mobileagent security. Section 4 introduces the role of the TrustedComputing technology in our solution. In Section 5, wedetail the Secure Migration Library for Agents (SecMiLiA).Section 6 deals with the core of our approach, the securemigration protocol. In Section 7, we give an overview of theimplementation of our library. Finally, Section 8 concludesand provides some ideas for ongoing research from host tohost performing actions autonomously on behalf of a user.

2. THE PROBLEM OF MALICIOUSHOSTS

The fact that the runtime environment (the host) may attackthe program (the agent) plays hardly a role in existing com-puter systems. Normally, the party that maintains the hostsalso employs the program. Nevertheless, in the area of openmobile agents systems, an agent is operated in most casesby another party, the agent owner. This environment leadsto a problem that is vital for the usage of mobile agents inopen systems: the problem of malicious hosts. A malicioushost can be defined in a general way as a party that is able toexecute an agent that belongs to another party and tries toattack the agent in some way. The question of which actionis considered to be an attack depends on the question whichassurances an agent owner needs to use a mobile agent. Weidentify the following attacks:

Spying out data: The threat of a host reading the privatedata of an agent is very severe as it leaves no trace that couldbe detected. This is not necessarily true for the consequencesof this knowledge, but they can occur a long time after thevisit of the agent on the malicious host. This is a specialproblem for the data classes such as secret keys or electroniccash, where the simple knowledge of the data results in lossof privacy or money.

Spying out control flow: As soon as the host knows theentire code of the agent and its data, it can determine the nextexecution step at any time. Even if we could protect the useddata somehow, it is rather difficult to protect the informationabout the actual control flow. This is a problem, becausetogether with the knowledge of the code, a malicious hostcan deduce more information about the state of the agent.

Manipulation of code: If the host is able to read the codeand if it has access to the code memory, it can normallymodify the program of an agent. It could exploit either by al-tering the code permanently, thus implanting a virus, wormor trojan horse. It could also temporarily alter the behaviourof the agent on that particular host only. The advantage ofthe latter approach consists in the fact, that the host to whichthe agent migrates cannot detect a manipulation of the codesince it is not modified.

Manipulation of data: If the host knows the physical lo-cation of the data in the memory and the semantics of thesingle data elements, it can modify data as well.

Manipulation of control flow: Despite of the fact that hostis not granted to access to agent data, it can conduct thebehaviour of the agent by manipulating the control flow.

Incorrect execution of code: Without changing the codeor the flow of control, a host may also alter the way it ex-ecutes the code of an agent, we can obtain the same effectas above.

Masquerade: It is the liability of a host that sends an agentto a receiver host to ensure the identity of the receiver. Athird party may intercept or copy an agent transfer and startthe agent by masking itself as the correct receiver host. Amasquerade will probably be followed by other attacks likeread attacks.

46 Security Comm. Networks 2010; 4:45–60 © 2010 John Wiley & Sons, Ltd.DOI: 10.1002/sec

A. Munoz and A. Mana TPM-based protection for mobile agents

Denial of execution: As the agent is executed by the host,i.e. passive, the host can simply not execute the agent. Thiscan be used as an attack i.e. in the case that a host knowsabout a time limited special offer of another host. The hostsimply can prevent the detection of this offer by the agentby delaying its execution until the offer expires.

Spying out interaction with other agents: The agent maybuy the flowers remotely from a shop situated on anotherhost. If the interaction between agent and the remote flowershop is not protected, the host of the agent is able to watchthe buy interaction even in the case the host cannot watchthe execution of the agent.

Manipulation of interaction with other agents: If the hostcan also manipulate the interaction of the agent it can actwith the identity of the agent or mask itself as the partnerof the agent.

Returning wrong results of system calls issued by theagent: in the case that the agent requests the name of the cur-rent location. Here the host could mask itself as the agent’shome location by returning the corresponding address. Theagent then thinks that it is at home and delivers the privateinformation to the host i.e. a variable with the best pricefound to fly to Paris.

3. BACKGROUND

Once the malicious hosts problem is described, we providea complete description in the background. Firstly, we givelist of the most relevant works in the protection of agentsand similarly in the host protection. Secondly, a descriptionof the JADE security model is provided. Finally, we presentthe Trusted Platform Module (TPM) and its main features.

Several mechanisms for secure execution of agents havebeen proposed in the literature with the objective of provid-ing protection for the execution of agents and their environ-ments. Most of these mechanisms are designed to providesome type of protection or some specific security property.In this section, we focus on solutions that are specificallytailored or especially well-suited for agent scenarios. Moreextensive reviews of the state of the art in general issues ofsoftware protection can be found in Reference [5,6].

Some mechanisms are oriented to the protection of theagencies (host) against malicious agents. Among these, wefound the Software-Based fault isolation [7] consisting onisolating application modules into distinct fault domainsenforced by software, this technique is commonly referredas SandBoxing [8]. The idea behind the Safe Code Inter-pretation [9] is that commands considered harmful can beeither made safe for or denied to an agent, the best known ofthe safe interpreters developed for agents is Agent Tcl [10].A different technique for protecting an agent system is sign-ing code or other objects with a digital signature by meansof which the authenticity of an object can be confirmed. Aclear example is the Microsoft’s Authenticode, which is aform of code signing that enables Java applets to be signed,ensuring users that the software was has not been tamperedwith or modified and the identity of the author is verified.

Other technique is known as state appraisal [11] basedon ensuring that an agent has not been somehow subverteddue to alterations of its state information. Appraisal func-tions are used to determine what privileges to grant an agent,based on both on conditional factors and whether identifiedstate invariants hold. An agent whose state violates an in-variant can be granted no privileges, while an agent whosestate fails to meet some conditional factors may be granteda restricted set of privileges. The basic idea behind the Path-Histories [12,13] is to keep an authenticable record of theprior platforms visited by an agent in such a way that anewly visited platform can determine whether to processthe agent and what the resource constraints to apply. Forthis purpose, each agent platform adds a signed entry tothe path to indicate its identity and the identity of the nextplatform to be visited. Proof-carrying code approach [14]forces to the code producer to formally prove that the pro-gram possesses safety properties, previously stipulated bythe code consumer. It is important to mention the fact thatthis is a prevention technique. One of the most importantproblems of these techniques is the difficulty of identifyingwhich operations (or sequences of them) can be permittedwithout compromising the local security policy.

Other mechanisms are oriented toward protecting agentsagainst malicious agencies (hosts). This problem was fulldetailed in the previous section. Thus, this section brieflydescribes some partial approaches oriented to solve thisproblem. Among these approaches, there is the concept ofPartial Result Encapsulation, which consist on the encap-sulation of the results of an agent’s actions, at each plat-form visited to be verified. A version of this techniqueis the presented by Yee as Partial Result AuthenticationCodes (PRAC) [15] consisting of cryptographic checksumsformed using secret key cryptography. However this tech-nique presents an important drawback when a maliciousplatform retains copies of the original keys or key generat-ing functions of an agent.

An improvement is that rather than relying on the agent toencapsulate the information, each platform can be requiredto encapsulate partial results along the way [13]. However,Yee noted that forward integrity could also be achieved us-ing a trusted third party that performs digital time-stamping.Thus, a timestamp [16] allows one to verify that the contentsof a file or document existed, as such, at a particular pointin the time. Also Yee raises the concern that the granularityof the timestamps may limit an agent’s maximum rate oftravel, since it must reside at one platform until the nexttime period. Another possible concern is the general avail-ability of a trusted time-stamping infrastructure. A variationof this technique is the named Path Histories [17], whichis a general scheme for allowing an agent’s itinerary to berecorded and tracked by another cooperating agent and viceversa. Some drawbacks of this technique include the cost ofsetting up the authenticated channel and the inability of thepeer to determine which of the two platforms is responsibleif the agent is killed.

The Itinerary Recording with Replication and Voting ap-proach is a technique for ensuring that a mobile agent ar-

Security Comm. Networks 2010; 4:45–60 © 2010 John Wiley & Sons, Ltd. 47DOI: 10.1002/sec


rives safely at its destination [18]. The idea is that ratherthan a single copy of an agent performing a computation,multiple copies of the agent are used. Although a maliciousplatform may corrupt a few copies of the agent, enoughreplicates avoid the encounter to successfully complete thecomputation. Evidently, this approach is similar to Path His-tories, but extended with fault tolerant capabilities. Thetechnique seems appropriate for specialized applicationswhere agents can be duplicated without problems, the taskcan be formulated as a multi-staged computation, and sur-vivability is a major concern. One obvious drawback isthe additional resources consumed by replicate agents. Adetection-based technique is the execution tracing [19] fordetecting unauthorized modifications of an agent throughthe faithful recording of the agent’s behaviour during itsexecution on each agent platform. Each platform involvedhas to create and retain a non-repudiatable log or trace of theoperations performed by the agent while resident there, andto submit a cryptographic hash of the trace upon conclusionas a trace summary or fingerprint. This approach has sev-eral drawbacks, the size and number of logs to be retained isthe most obvious, and the fact that the detection process istriggered occasionally, based on suspicious results or otherfactors.

The Environmental Key Generation [20] describes ascheme for allowing an agent or take predefined actionswhen some environmental condition is satisfied. The mainweakness of this approach is that a platform that completelycontrols the agent could simply modify the agent to printout the executable code upon receipt of the trigger, insteadof executing it. Another drawback is that an agent platformtypically limits the capability of an agent to execute codecreated dynamically, since it is considered an unsafe opera-tion. The objective of Computing with Encrypted functions[21] is to determine a method whereby mobile code cansafely compute cryptographic primitives. The approach isto have the agent platform execute a program embodying anenciphered function without being able to discern the orig-inal function, even though the idea is straightforward, thetrick is to find the appropriate encryption schemes that cantransform arbitrary functions as intended. This techniquecan be very powerful but does not prevent denial of service,replay, experimental extraction, and other forms of attackagainst the agent. Hohl [22] proposes the Blackbox tech-nique. The strategy behind this technique is scrambling thecode in such a way that no one is able to gain a complete un-derstanding of its function, or to modify the resulting codewithout detection. However, the main drawback is that thereis no known algorithm or approach for providing Blackboxprotection. Several techniques can be applied to an agent toverify self-integrity and avoid that the code or the data ofthe agent is inadvertently manipulated.

Anti-tamper techniques, such as encryption, checksum-ming, anti-debugging, anti-emulation and some others[23,24] share the same goal, but they are also oriented to-ward the prevention of the analysis of the function that theagent implements. Additionally, some protection schemesare based on self-modifying code, and code obfuscation

[25]. Finally there are techniques that create a two-wayprotection. Some of these are based on the aforementionedprotected computing approach [5].

Along this paper we propose a hardware-based protectioninfrastructure that takes advantage of the recent advancesin trusted hardware, especially of TCG technology to solvethe problem of ‘malicious hosts’. The basic idea behind theconcept of Trusted Computing (TC) is the creation of a chainof trust between all elements in the computing system, start-ing from the most basic ones. Consequently, platform bootprocesses are modified to allow the TPM to measure each ofthe components in the system and securely store the resultsof the measurements in Platform Configuration Registers(PCRs) within the TPM. This mechanism is used to extendthe root of trust to the different elements in the comput-ing platform. Therefore, the chain of trust starts with theTPM, which analyses whether the BIOS of the computer isto be trusted and, in that case, passes control to it. The pro-cess is repeated for the master boot record, the OS loader,the OS, the hardware devices and finally the applications.In a Trusted Computing scenario a trusted application runsexclusively on top of trusted and pre-approved supportingsoftware and hardware. Additionally theTC technology pro-vides mechanisms for the measurement (obtaining a cryp-tographic hash) of the configuration of remote platformsby means of ‘quote’ functions. If this configuration is al-tered or modified, a new hash value must be generated andsent to the requester in a certificate. These certificates attestthe current state of the remote platform, log or trace of theoperations performed by the agent.

3.1. Jade security model (JADE-S)

We define the concepts that determine the diverse securitylevels to a better understanding of the role of security inthe transmission of private and critical information throughan open environment like Internet: (i) Confidentiality is theproperty that ensures that only those that are properly au-thorized may be access the information. (ii) Integrity of theproperty that ensures that information cannot be altered.This modification could be an insertion, deletion or replace-ment of data. (iii) Authentication is the property that refersto identification. It is the link between the information andits sender. (iv) Non-repudiation is the property that preventssome of the parts to negate a previous commitment or ac-tion.

When we are dealing with MAS, these properties are es-pecially important, due to the autonomy and mobility ofagents. A MAS without security support could not be usedin an open environment such as Internet if it deals with crit-ical data, because communications could be spied or eventhe identities of agents faked. JADE-S consists on a plug-inof JADE that allows to add some security characteristicsin the development of MAS, so that they can start to beused in real environments. It is based on the Java secu-rity model and it provides the advantages of the followingtechnologies:



– JAAS (Java Authentication and Authorization Service)allows establishing access permissions to perform cer-tain operations on a set of predetermined classes, li-braries or objects.

– JCE (Java Cryptography Extension) implements a setof cryptographic functions that allow the developer todeal with the creation and management of keys and touse encryption algorithms.

– JSSE (Java Secure Socket Extension) allows to ex-change critical information through a network usinga secure data transmission such as SSL.

Several considerations might be taken into account whendealing with JADE security. A JADE platform may be lo-cated in different hosts and have different containers.JADE-S structures the agent platform as a multi-user environmentin which all components (agents, containers, etc) belongto authenticated (through a login and a password) users,who are authorized by the administrator of the system toperform certain privileged critical actions. Each platformcontains a permissions file with a set of actions that eachuser is authorized to perform. Internally, each agent provesits identity by showing an Identity Certificate signed by theCertification Authority (proved in a transparent way to theagent when their registers in the system and provides thelogin and the password of its owner). Using these digitallysigned certificates the platform may allow or deny certainactions to each agent.

We previously mentioned that each component of theplatform belongs to an authenticated user. User who bootsthe platform also owns the AMS and DF agents and the maincontainer. Then, when a user wants to join to the platform(through one of his/her agents), it has to provide his/herlogin and password. These data are checked with the pass-words file contained in the platform, which is stored in aciphered way, similar to Unix passwords. Password file isunique and is loaded with the main container. Each agentowned by this user will have an Identity Certificate thatcontains its name, its owner and the signature of the Certi-fication Authority.

However, in a JADE-S platform the permissions to accessresources are given to the different entities by following themechanism defined by the new system provided by Java(JAAS) for user-based authentication. Thus, it is possibleto assign permissions to parts of the code and to its ex-ecuters, restricting the access to certain methods, classesor libraries depending on who wants to use them. An en-tity can only perform an action (send a message, moveto another container) if the Java security manager allowsit. The set of permissions associated to each identity isstored in the access rights file of the platform (which isalso unique and is loaded when the platform is booted).Also Java provides a set of permissions (apart from thosethat may be defined by the user) on the basic elements ofthe language: AWTPermission, FilePermission, Socket Per-mission, etc. Moreover, JADE-S provides other permissionsrelated to the behaviour of the agents: AgentPermission,ContainerPermission, etc. There is a list of related actions

for every perm for every permission rule to be allowed ordenied.

Concerning certification issues, the Certification Author-ity is the entity that signs the certificates of all the elementsof the platform. To do that, it owns a couple of public/privatekeys so that, for each certificate, it creates an associated sig-nature by ciphering it with its private key (which is secret).Then, when an entity has to be identified the signature maybe decrypted using the Authority public key (which is pub-licly known) and we can check that the identity that theentity wanted to prove matches the one provided by theAuthority. The secure platform JADE-S provides a Certi-fication Authority within the main container. Each signedcertificate is only valid within the platform in which it hasbeen signed. JADE-S uses the SSL protocol (Secure SocketLayer) to provide a secure communication between agentslocated in different hosts or containers, which provides pri-vacy and integrity for all the connections established in theplatform. This is a way of being protected against networksniffers.

3.2. Introduction to trusted platformmodule

A TPM usually is implemented as a chip integrated intothe hardware of a platform (such as a PC, a laptop, a PDA,a mobile phone). A TPM owns shielded locations (i.e. noother instance but the TPM itself can access the storageinside the TPM) and protected functionality (the functionscomputed inside the TPM cannot be tampered with). TheTPM can be accessed directly via TPM commands or viahigher layer application interfaces (the TCG Software Stack,TSS).

The TPM offers two main basic mechanisms: It can beused to prove the configuration of the platform it is in-tegrated in and applications that are running on the plat-form, and it can protect data on the platform (such as cryp-tographic keys). These mechanisms can be performed bymeans of the crypto co-processor, hash and HMAC algo-rithm, key generator, etc, provided by TPM.

In order to prove a certain platform configuration, allparts that are engaged in the boot process of the platform(BIOS, master boot record, etc) are measured (i.e. someintegrity measurement hash value is computed), and the fi-nal result of the accumulated hash values is stored insidethe TPM in a so-called PCR. An entity that wants to verifythat the platform is in a certain configuration requires theTPM to sign the content of the PCR using a so-called At-testation Identity Key (AIK), a key particularly generatedfor this purpose. The verifier checks the signature and com-pares the PCR values to some reference values. Equality ofthe values proves that the platform is in the desired state.Finally to verify the trustworthiness of an AIK’s signature,the AIK has to be accompanied by a certificate issued by atrusted Certification Authority, a so-called Privacy CA (P-CA). Note that an AIK does not prove the identity of theTPM owner.



Keys generated and used by the TPM have different prop-erties: Some (so-called non-migratable keys) cannot be usedoutside the TPM that generated them; some (like AIKs) canonly be used for specific functions. We highlight the factthat keys can be tied to PCR values (by specifying PCRnumber and value in the key’s public data). This has theeffect that such a key will only be used by the TPM if theplatform (or some application) configuration is in a certainstate (i.e. if the PCRs the key is tied to contains a specificvalue). In order to prove the properties of a particular key,for example that a certain key is tied to specific PCR values,the TPM can be used to generate a certificate for this keyby signing the key properties using an AIK. For requestinga TPM to use a key (i.e. for decryption), the key’s autho-rization value has to be presented to the TPM. This togetherwith the fact that the TPM specification requires a TPM toprevent dictionary attacks provides the property that onlythose entities that know the key’s authorization value canuse that key.

Non-migratable keys are especially useful for preventingunauthorized access to some data present in a platform.Binding such a key to specific PCR values and using it toencrypt data to be protected achieves two properties: Thedata cannot be decrypted on any other platform (because thekey is non-migratable), and the data can only be decryptedwhen the specified PCRcontains the specified value (i.e.when the platform is in a specific secure configuration andis not manipulated).

4. THE ROLE OF TRUSTEDCOMPUTING IN THE SECUREMIGRATION

Sander and Tschuding [21] asked the question: ‘Can aprogram actively protect itself against its execution en-vironment that tries to divert the intended execution to-wards a malicious goal?’ By means of after a little thoughtthis seems to be a problem impossible to solve becauseit leads to an infinite recourse. The assessment routinethat would detect wrong execution of code or tamper-ing of data and that would try to counter them wouldalso be subject to diversion. For mobile code applications,more specifically for mobile software agents, which aredesigned to run on potentially arbitrary computers, thisproblem is of primordial importance. Without strong guar-antees on computation integrity and privacy, mobile pro-grams would always remain vulnerable to hijacking andbrainwashing.

Pearson [26] defines a related notion, namely that of atrusted platform as follows: ‘A Trusted Platform is a com-puting platform that has a trusted component, probably inthe form of built-in hardware, which it uses to create afoundation of trust for software processes’. The concept oftrusted computing is in surprisingly recent, although someof key ideas around have been around much longer. Trustedcomputing refers to the addition of hardware functionalityto a computer system to enable entities with which the com-

puter interacts to have some level of trust in what the systemis doing.

Agent migration consists on a mechanism to continue theexecution of an agent on another location [1]. This processincludes the transport of agent code, execution state anddata of the agent. The migration in an agent-based systemis initiated on behalf of the agent and not by the system. Themain motivation for this migration is to move the computa-tion to a data server or a communication partner to reducenetwork load by accessing a data server a communicationpartner by local communication. Then migration is donefrom a source agency where agent is running to a destina-tion agency. Migration can be performed by two differentways. Moving is the process in which the agent is removedfrom the source agency when is copied in the destinationagency. Cloning consists on the agent is copied to the desti-nation agency. From this moment on, the two copies of theagent coexist executing in different places. In the remain-der of this paper and at least stated explicitly we will usethe term migration to refer to both cloning and moving ofagents.

Our approach is addressed on achieve a secure migra-tion process. For this reason we propose a hardware-basedmechanism to provide security to agent systems. The TPMprovides mechanisms, such as cryptographic algorithms,secure key storage and remote attestation that provides im-portant tools to achieve a high level of security. Remoteattestation allows changes to the user’s computer to be de-tected by authorized parties. It works by having the hard-ware generate a certificate stating what software is currentlyrunning. The computer can then present this certificate to aremote party to show that its software has not been tamperedwith. This functionality is usually combined with public-key encryption so that the information sent can only beread by the programs that presented and requested the at-testation, and not by an eavesdropper, such as the computerowner.

Unfortunately, the TPM technology is very complex andso are the procedures and action sequences to use it. Theaccess to the device and the use of TPM functionality is notan easy task, especially for average software developers.Therefore, we have developed a library that provides accessto the TPM from software agents. The main advantage forthis approach is that developers of agent systems do notneed to become security experts, and can access the securitymechanisms without taking care of low level details of theTPM technology. Hardware-based solutions can be built onthe basis of different devices. We have selected the TPM forour solution because it provides all necessary features. Inparticular it provides cryptography capabilities, and securestorage, and intimate relation to the platform hardware, andremote attestation, etc.

Remote attestation is perhaps the most important featurefor us; it allows the computer to recognize any unautho-rized/authorized changes to software. If certain require-ments are met then the computer allows the system tocontinue its operations. This same technology that TPMutilizes can also be applied in agent-bases systems to scan



machines for changes to their environments made by anyentity before the system boots up and accesses the network.Additional reasons are the support of a wide range of in-dustries and the availability of computers equipped withTPM. In summary, this element is the cornerstone of ourapproach. Indeed the security of our system settle in thisdevice as previously described.

The use of TPM in these systems is as follows. Eachagency takes measures of system parameters while bootingto determine its security, such as BIOS, keys modules fromOperating System, active processes and services in the sys-tem. Through these parameters an estimation of the securestate of the agency can be done. Values taken are stored ina secure way inside the trusted device, preventing unautho-rized access and modification. Agencies have the ability toreport previously stored configuration values to other agen-cies to prove their security. Our system takes advantage ofthe remote attestation procedure provided by the TPM toverify the security of the agencies. In this way, agents canverify the security of the destination agency before migra-tion.

5. THE SECURE MIGRATIONPROTOCOL

In this section, we describe the main protocol involved inthe secure migration. However, firstly we analyse differentattestation protocols, as well as secure migration protocols,studying their benefits, so that we can build our own securemigration protocol. We use the migration concept both toagent cloning and agent moving, because for protocol thereis no difference between them, henceforth we use migrationuniquely.

A first approach of a secure migration protocol isin Reference [5]. This protocol provides some impor-tant ideas to take into account during the design pro-cess of the final protocol, we highlight that the agenttrusts in its platform to check the migration security.Besides, we highlight the necessity of using of TPMtechnology to obtain and report configuration measuresthrough a secure channel. This protocol describes the se-cure migration to a destination agency following thesesteps:

(1) Agent ag1 requests to the source agency S for migra-tion to the destination agency D according to a set ofrequirements (Dreq).

(2) S in collaboration with TPMs (TPM in source agencycomputer) establish a communication channel withTPMd (TPM in destination agency computer) to ob-tain the destination agency configuration (Dconf).

(3) Destination agency configuration is analyses tocheck whether destination requirements (Dreq) arefulfilled.

(4) If these requirements are fulfilled then destinationagency D is granted to ag1 migration,

This protocol contributes with some important ideas toconsider in the task of design the new version of the proto-col, thus the agent trusts in the platform to check the securityin the migration. This represents a key issue since it is nec-essary a root of trust to extend the trust boundaries. Anotherrelevant concept is the requirement of a hardware elementsuch as TPM to obtain and report configuration values se-curely. Nevertheless, the key ideas provided by this protocolsettle on; the protocol shows how an agent from the agencyrequests to TPM the signed values from PCRs. Besides thisprotocol describes how the agent obtains platform creden-tials. These credentials, together with PCRs signed values,allow calculate if destination configuration is secure.

Other protocol that provides interesting ideas to takeinto account when we develop a secure migration systemis detailed in Reference [23]. This protocol, which is in-cluded and full described in TGC Specification Architec-ture Overview [27], presents some interesting ideas to takeinto account in our task. A further description of this pro-tocol is out of the scope of this paper, a more detailed ver-sion can be found in Reference [27]. The Integrity ReportProtocol consists on ‘Roots of Trust’ for Report has twomain objectives, provide secure location to integrity reportstorage and attest the authenticity of stored values accord-ing to the identity of secure platforms. PCRs can be im-plemented in volatile or non-volatile memory and mightbe tampered against software attacks, as well as tamper-proof resistant against physic attacks. Integrity reports aredigitally signed using an Attestation Identity Key (AIK) toauthenticate PCR values. Signature includes a nonce toavoid repetition-based attacks. TPM provides a internal keynames Endorsement Key (EK). This is used to establish theTPM owner and issue AIK credentials. TPM owner is ableto generate a Storage Root Key (SRK) to wrap other keysfrom TPM. This mechanism facilitates the external andsecure storage keys of TPM. Security report can be usedto determine the configuration of a platform in a concreteinstant.

We notice the fact that this protocol is independent oftransport mechanism and data delivering. One objective ofthe attestation is allow that an entity determines whethera TPM signed a message, and even to determine whichTPM did it. Nevertheless, for this is necessary a CA thatissues AIK credentials used to attest the platform trustwor-thy. These credentials will substitute Endorsement Key (EK)public part, which is not recommended for public distribu-tion. TPM must prove that AIK’s CA is exclusively usedfor this, thus CA issues encrypted credentials with EK. Thisguarantees that only the TPM that generated that key candecrypt it. On the other side, CA must keep the private in-formation related with the TPM which signed. Once theprotocol to obtain the platform configuration information isanalysed lets study the feedback to build our protocol. Thisprotocol shows how an agent from the agency requests tothe TPM the signed values of PCRs values. The agent ob-tains platform credentials. These credentials together withPCR values signed allow determine whether the destinationagency is secure. The usage of these credentials is very in-



teresting since credentials certify that PCR signed belongsto the agency to attest carrying out the remote attestationprocess.

Finally, we describe the complete protocol for the securemigration, which is based on the usage of a CertificationAuthority (CA).The Algorithm 1 describes the steps of thisprotocol.

Algorithm 1 Secure migration protocol.

Ensure: Source Agency –> SEnsure: Destination Agency –> DEnsure: Agent –> aEnsure: Source TPM –>STPMEnsure: Destination TPM –> DTPM

1: a requests to S (migration to D).2: S sends to D attestation request.3: D accepts the request for attestation and sends a nonce

(this value is composed by random bits used to avoidrepetition attacks) and indexes of PCRs values thatneeds.

4: S requests to STPM PCR values requested by D to-gether with the nonce all signed.

5: STPM returns requested data.6: S obtains AIK credentials from its credentials reposi-

tory.7: S requests D for PCRs values requested and nonce all

signed. Then it sends AIK credentials, which containsthe public key corresponding with the private key usedto sign data. Additionally, it sends a nonce and the in-dexes of PCRs that wants to know.

8: D validates the authenticity of received key verifyingthe credentials by means of the CA public key whichwas used to generate those credentials.

9: D verifies the PCRs values signature and the nonce re-ceived using the AIK public key.

10: D verifies that PCRs values received belong to the setof accepted values and then the agent configuration isvalid.

11: D requests to Destination TPM the PCR values re-quested by D together with the signed nonce.

12: DTPM returns requested data.13: D obtains AIK credentials from its credentials reposi-

tory.14: D sends to S PCR values requested and the nonce

signed. Also it sends AIK credentials, which containsthe public key corresponding to the private key used toencrypt the data.

15: S validates the authenticity of received key verifying thecredentials by means of CA public key that generatedthose credentials.

16: S verifies the PCR values signature and the nonce re-ceived using the AIK public key.

17: S verifies that PCR values received belong to the set ofaccepted values and then the D configuration is secure.From this point trustworthy between S and D exists.

18: Then S allows to the ‘a’ migrate to D.

Then we analyse the protocol depicted in the Algo-rithm 1. More relevant ideas from this protocol are the useof an AIK to sign the PCR values, and the use of a CA thatvalidates the AIK, and the use of configurations to comparereceived results from remote agency. We designed a newprotocol based on the study of these three protocols, insuch a way that we took advantage of the appeals providedby each of them. Our protocol has some characteristics.The agency provides to the agent the capacity of securemigration. Also the agency uses a TPM that providesconfiguration values stored in PCRs. TPM signs PCRsvalues using a specific AIK for destination agency, in sucha way that data receiver knows securely TPM identitywhich signed. A Certification Authority generates neededcredentials to correctly verify the AIK identity. Togetherwith signed PCRs values the agency provides AIK creden-tials in such a way that the requester can correctly verifythat data comes from agency TPM. Following we definethe 18 steps protocol, used to perform secure migration.

Our protocol fulfils the five main characteristics we previ-ously mentioned. Then we have a clear idea of the differentcomponents of the system as well as the interaction betweenthem to provide the security in the migration.

5.1. An alternative based on the directanonymous attestation protocol

Another alternative for the development of the secure migra-tion is based on the Direct Anonymous Attestation protocol(DAA). In contrast to the previous protocol here, instead ofusing a CA a issuer certificates authority is used for DAAkeys. The Algorithm 2 depicts the protocol.

Both protocols allow to verifier entity to trust that AIKused to sign configuration values belongs to the entity thatgenerated the signature. Besides to trust that this entity hasa TPM installed and working in trusted mode used to gener-ate that AIK. On the other hand, CA-based protocol presentsseveral disadvantages: (i) A certificate for each AIK is nec-essary to be created, this becomes to CA in the bottleneck.(ii) The verification entity and CA should be confabulatedto violate the security of the system.

However DAA protocol does not present such disad-vantages but DAA protocol needs an additional protocolto verification entity can determine that verified entityposes an AIK certificate. SecMiLiA implements the CA-based protocol, since we use TPM4java library and thisis not provided to implementAnonymous Direct Attestationprotocol.

5.2. Infrastructure for the secure migrationprotocol

Some key concepts might be showed to provide to the readera full understanding of the work presented. As aforemen-tioned, a TPM is physical to prevent forgery, tamper resis-tant to prevent counterfeiting, and is provided cryptographic



Algorithm 2 Direct anonymous attestation protocol.

Ensure: Source Agency –> SEnsure: Destination Agency –> DEnsure: Agent –> aEnsure: Source TPM –>STPMEnsure: Destination TPM –> DTPM

1: S request to source STPM configuration data signed.2: STPM returns requested data.3: S sends to D configuration data signed together with

AIK public key used to sign and a cryptographic proofthat poses: (i) An AIK certificate generated using aDAA key. (ii) A certificated for DAA key generatedfor a DAA certificate issuer.

4: D verifies cryptographic proof and thus AIK validity.5: D verifies received signed data using AIK public key.6: D verifies that received configuration values belong to

the set of acceptable values and therefore source agencyconfiguration S is secure.

7: D requests to destination TPM configuration signed val-ues.

8: DTPM returns requested values.9: S sends to D configuration data signed together with

the AIK public key used in the signature, as well as acryptographic proof that poses: (i) An AIK certificatethat poses using a DAA key. (ii) A certificate for DAAkey generated by a DAA certificate issuer.

10: S verifies the cryptographic proof and therefore AIKvalidity.

11: S verifies received data signed using AIK public key.12: S verifies received configuration values belongs to the

set of accepted values and therefore source agency con-figuration is secure. Henceforth a mutual trusted rela-tionship exists between source S and destination agen-cies S.

functions to support authenticity, integrity, confidentiality,guard against replay attacks, digital signatures, and in ifrequired the use of certificates.

Attestation identities prove that all they correspond toa Trusted Platform and a specific identity always identi-fies the same platform. Then each identity is created onindividual trusted platform, with attestation from a PKICertification Authority (CA). Each identity has randomlycreated asymmetric cryptographic key and an arbitrary tex-tual string used as an identifier for the attestation identities(chosen by the platform owner). To obtain the attestationfrom the CA, the platform´s owner sends the CA infor-mation that proves that the identity was created by a gen-uine Trusted Platform. This process uses signed certificatesfrom the manufacturer of the platform and uses a secretinstalled in the TPM. That secret is known only to theTrusted Platform and only used under control of the ownerof the platform. In particular, it is not divulged to ar-bitrary third parties, unlike the cryptographic attestationvalues.

5.3. Formal verification of the protocol

Once the secure migration protocol is described our nexttarget is the validation of this protocol. Security protocolsaim to provide security guarantees between parties commu-nicating over insecure networks. These protocols are at thecore of security-sensitive ICT systems applied in a variety ofindustrial relevant domains (i.e. health-care, e-commerce,and e-government). The proper functioning of security pro-tocols is thus a crucial factor for the public acceptance ofICT systems as a security protocol failure may have criticalconsequences on the ICT system’s end-user (i.e. patients,business organizations, citizens).

This is the reason why many tool-supported approachesto security validation and verification have been applied onsecurity protocols in the last decade discovering many un-covered flaws and subtle vulnerabilities. The AVISPA Toolfor the Automated Validation of Internet Security Protocolsand Applications [28] has been quite remarkable in this re-spect by successfully analysing more than 50 protocols ofrelevance for standardization bodies and for the e-businessapplication domain.

AVISPA is an automatic push-button formal validationtool for Internet security protocols, which is a shared-costRTD (FET open) project, funded by the European Com-mission under the Information Society Technologies Pro-gramme operating within the Fifth Framework Programme.It encompasses all security protocols in the first five OSI lay-ers for more than twenty security services and mechanisms.Furthermore this tool covers (that is verifiable by it) morethan 85 of IETF security specifications. AVISPA libraryavailable on-line has in it verified with code about hundredproblems derived from more than two dozen security pro-tocols. AVISPA uses a High Level Protocol SpecificationLanguage (HLPSL) to feed a protocol in it; HLPSL is anextremely expressive and intuitive language to model a pro-tocol for AVISPA. The operational semantic of this tool isbased on the work of Lamport on Temporal logic of Actions.Communication using HLPSL is always synchronous. Oncea protocol is fed in AVISPA and modelled in HLPSL, it istranslated into Intermediate Format (IF). IF is an intermedi-ate step where re-write rules are applied in order to furtherprocess a given protocol by back-end analyser tools. A pro-tocol, written in IF, is executed over a finite number of iter-ations, or entirely if no loop is involved. Eventually, eitheran attack is found, or the protocol is considered safe overthe given number of sessions. System behaviour in HLPSLis modelled as a ‘state’. Each state has variables which areresponsible for the state transitions; that is, when variableschange, a state takes a new form. The communicating enti-ties are called ‘roles’ which own variables. These variablescan be local or global. Apart from initiator and receiver, en-vironment and session of protocol execution are also rolesin HLPSL. Roles can be basic or composed depending on ifthey are constituent of one agent or more. Each honest par-ticipant or principal has one role. It can be parallel, sequen-tial or composite. All communication between roles and theintruder are synchronous. Communication channels are also



represented by the variables carrying different properties ofa particular environment.

The language used in AVISPA is very expressive allow-ing great flexibility to express fine details. This makes it abit more complex than Hermes to convert a protocol intoHLPSL. Further, defining implementation environment ofthe protocol and user-defined intrusion model may increasethe complexity. Results in AVISPA are detailed and explic-itly given with reachable number of states. Therefore re-garding result interpretation, AVISPA requires no expertiseor skills in mathematics contrary to other tools like HER-MES [29] where a great deal of experience is at least nec-essary to get meaningful conclusions.

Of the four available AVISPA Back-Ends we chose theOFMC Model, which is the unique that uses fresh valuesto generate nonce’s. However, this alternative requires alimit value for the search. The results of our research arethe following:

Algorithm 3 AVISPA results.

SUMMARYSAFEDETAILSBOUNDED NUMBER OF SESSIONSPROTOCOL/avispa/avispa-1.1/testsuite/results/protocolo 2.txt.ifGOALas specifiedBACKENDOFMCCOMMENTSSTATISTICSparseTime: 0.00ssearchTime: 18.40svisitedNodes: 4 nodesdepth: 400 pliesenvironment()

Therefore we can observe the feedback of running ourmodel with the AVISPA tool. These results show that thesummary of the protocol validation is safe. Also somestatistics are shown among them depth line indicates 400plies, but this process has been performed for 25, 50, 75,100, 150, 200, 250, 300, 350 and 400 of depth values withsimilar results. In the verification of the Secure MigrationProtocol with AVISPA, we have checked the authenticationon the following variables pcra(pcrib), pcrb(pcria), aikaband aikba, because these are the values exchanged amongthe agents A and B.

6. SECMILIA: SECURE MIGRATIONLIBRARY FOR AGENTS

This section introduces the SecMiLiA. It aims to serve as aplatform for the agent migration on top of the JADE plat-form. This library makes use of the inherent security fea-

Figure 1. Stack packages.

tures provided by the TPM to provide a secure environment.In this way, the migrations are supported by a trusted plat-form.

Figure 1 shows how SecMiLiA is the application of theSecure Migration Protocol in a real agent platform, inthis case we implemented on JADE. We enforce the se-curity of the migration process in the TPM. To achieve afull development of Java we make use of the functional-ities of the TPM4Java library. TPM4Java facilitates theaccess to the TPM functionalities, which is completelydeveloped in Java. Nevertheless, the current version ofthis library cannot be used directly for our purposes. Forthis reason, we have extended TPM4Java, as described inSection 7.3.1.

We highlight as one of the main objectives in the designof this SecMiLiA the provision of a secure environment inwhich agents can migrate securely. Secondly, we focusedon achieving a easily usable library. Obviously, agent sys-tems developers have not a huge expertise in security. Ad-ditionally, we concentrated in achieving a versatile libraryeasily adaptable to be used in different cryptographic de-vices (i.e. smartcards), as well as to get a generic and flex-ible interface library. All these functionalities allow usersto take advantage of this library to solve a wide range ofproblems.

We previously aimed that the most important functional-ity provided by the library is the secure migration mecha-nism. This secure mechanism is based on the remote attesta-tion of the destination agency, before the migration actuallytakes place, the idea is to warrant that agents are alwaysexecuted in a secure environment. Additionally, we providea secure environment for the execution of agents, in such away that malicious agents are not able to modify the hostagency.

The library was designed according to the following set ofrequirements. Our main objective, which is directly relatedwith the functional requirements, was to provide a mecha-nism for secure agent migration in JADE platform. The goalwas to make possible to extend the trusted computing basefor agents to the next destination agency before migrating toit. It is important to mention that each agency must providelocal functionality to perform the secure migration mecha-nism, which requires the presence of the TPM for remoteattestation. Similarly each agency must provide the func-tionality to allow to other agencies to take remote integritymeasures to determine whether its configuration is secure.The library includes a protocol that allows two agenciesto exchange information about their configurations to sup-port the previous processes. This exchange establishes the



bases of the mutual trust between agencies. Concerning thenon-functional requirements, the library must seamlesslyintegrate in the JADE platform, in such a way that its usedoes not imply modifications in the platform. Additionally,the operation of the library must be transparent to the user.We decided to create an additional abstraction layer thatprovides generic services in order to facilitate the adapta-tion of the library to new devices. In this way, the genericservices remain unchanged. One final requirement has tosupport both types of migration (moving and cloning). Con-cerning the architecture, TPM plays the role of trusted el-ement of each agency, able to certify to other agencies itstrustworthiness.

7. SECMILIA IMPLEMENTATIONMAIN ISSUES

The main objective of the work presented in this paper istwo-folded: (i) to solve the problem of ‘malicious hosts’ and(ii) to provide a transparent solution to integrate securitymechanisms in agent systems. The first of these objectivesis described in next sections, while the second is followingaddressed.

To reach the second proposed objective implies on pro-viding mechanisms that are simple to use for agent-basedsystem developers, and a library easy to embed in othersecurity devices such as smartcards. Besides, to providea library with such a generic and flexible interface al-lowing users to solve some of security problems, despiteof the lack of expertise in security. Naturally, SecMiLiAis easily extensible to be included new functionalities in.As shown in Figure 1, SecMiLiA is based on the onehand on the JADE platform and on the other hand onthe TPM4Java library. TPM4Java provides access to theTPM functions from the Java programming language. How-ever, a straightforward application of TPM4Java in agent-based systems is not possible. Thus, the TPM4Java li-brary was enhanced to provide new functionalities for agentmigration.

We aimed that the most important functionality providedby the library is the secure migration mechanism. Thismechanism is based on the remote attestation of the des-tination agency, before migration actually takes place, inorder to guarantee that agents are always executed in a se-cure environment. Additionally we provide an environmentfor secure agent execution, in such a way that maliciousagents are not able to manipulate the host agency. In thelibrary design process we prepared a list of requirementsthat library might fulfils. Indeed, the library is developedfulfilling those requirements. Next the list of requirementsis presented:

– Functional requirements; we considered that our mainobjective is to provide a mechanism for secure agentmigration in JADE platform. The goal is to make pos-sible for agents to extend their trusted computing baseto the next destination agency before the migration.

Therefore every agency must provide local access tosecure migration functionality. Besides, every agencymust provide the mechanisms to allow other agen-cies to take remote integrity measures. To calculatewhether the configuration values measured match withthe trusted values and to determine its security. Oncewe presented that our system is based on the securemigration concept. Next step consists on the design ofa protocol that allows two agencies to exchange theinformation about their configurations. This exchangeestablishes the basis of the mutual trust between agen-cies.

– Non-functional requirements; SecMiLiA might be in-tegrated in the JADE platform, in such a way that itsuse does not imply modifications in the platform. Addi-tionally, the operation of the library must be transparentto the user. In order to facilitate the adaptation of the li-brary to new devices we decided to create an additionalabstraction layer that provides generic services. In thisway the generic services remain unchanged. One fi-nal requirement has to support both types of migration(moving and cloning). Figure 2 shows a class diagramconcerning the architecture, where each agency canhost different agents and is supported by TPM func-tionalities. TPM plays the role of trusted element ofeach agency, able to certify to other agencies its trust-worthiness.

In following sections, we describe the main design anddevelopment issues in the SecMiLiA creation process. Forthis purpose we study the architecture of this in details aswell as we show the components and their related function-alities. Main use case consists on a user that uses SecMiLiA

Figure 2. SecureAgent class.



to develop a regular, but secure MAS. Traditionally in thesetypes of systems, the user defines the set of agents that com-pound the system. Concretely JADE defines an agent bymeans of a class that inherits from Agent class. Throughoutthis new agent created is provided of the basic behaviourof an agent. Then user defines the specific behaviour ofthis agent. Among the basic functionality of a JADE Agentwe found the compatibility with inter-containers migra-tion. JADE security model is briefly described in Section2.1.1. Any secure migration is provided by JADE Agentclass. Thus, we created a new class that inherits from thisclass and redefines migration methods to perform themsecurely.

Concerning the main migration methods we notice; do-Move(Location1); to Move the agent from a source con-tainer to a destination one. doClone(Location1, StringnewName); to clone the agent in container1 using new-Name as the name. Inter-platform migration methods intra-platform migration methods are shared but the most rel-evant difference between them is the dynamic type ofparam1.

Two main services are provided by SecMiLiA that useAgentMobility Service to perform a secure inter-platformmigration in the same platform, and SecureInterPlatform-

Mobility service that use InterPlatformMobility service toperform the secure intra-platform migration.

7.1. Design and development

In this section we outline the most relevant issues in thedesign and development of the SecMiLiA. Therefore webriefly describe some services provided by the library andsome considerations about the involved technology.

7.2. SecMiLiA: SecureAgentMobilityservice

Along this section we deeply describe the most importantservices provided by SecMiLiA. SecureAgentMobility ser-vice wraps the secure migration functionality of SecMiLiA.Figure 3 depicts a class diagram of the service, as well asthe most relevant methods. Concretely, Helper class pro-vides two important methods secureMove that allows secureagents moving securely to destination and secureClone thatallows to secure agents to be cloned securely in destinationcontainers.

Figure 3. SecureAgentMobility service class diagram.



Algorithm 4 presents a scenario where an agent requestfor a service to move to a container (c2). This scenario iscomposed by the following stages:

Algorithm 4 The agent SA is moved to the container C2.

1: SA agent requests for S1 service to move to C2.2: Service sends a remote attestation request to S2 service.3: S2 service accepts the request.4: S1 service sends requested information to S2.5: S2 service responses to S1 sending the attestation result.6: S1 service starts agent migration to C2 container.

This protocol considers the service as a unique entity.However, only the most relevant components are sketchedin order to clarify. Other important issue is that the ser-vice invokes doMoveOld method to start the migration. Thisfunctionality is similar to doMove from Agent class, mov-ing agent to destination. Previously to this migration theservice checks the trustworthy in the destination agency.This provides a similar behaviour of doMove method fromSecureAgent and doMove method from Agent class. Con-tent of these messages is encapsulated using AttestRe-quest Interface and AttestData Interface classes AttestRe-quest Interface class provides access to data from a requestattestation message, and AttestData Interface provides ac-cess to attestation information from a concrete container.Both classes encapsulate information from attestation pro-tocol messages. Containers complete needed data using setmethods in each message, in such a way that the othercontainer continues the attestation procedure. In order todestination container continues the attestation proceduresource container completes the needed data by means ofset method. Next Figure 4 depicts SecureAgentMobility ser-vices uses AttestTool Implement class to complete data mes-sages.

AttestTool Implement class handles attestation protocolmessages, that is, it generates the messages in their sourcesand verifies them in destination. AttestTool Implementclass is provided by access to system TPM by means ofTPM Interface as well as to a CA throughout CA Interfaceinterface. This fact allows using both entity functional-ities to complete messages. Also, AttestTool Implementclass can access to system configuration through AttestCon-fig Interface interface. AttestTool Implement class managesTPM access in such a way that attestation protocol can beperformed. AttestTool Implement class behaviour is simi-lar to Key Cache Manager managing TPM keys. Attest-Tool Implement class implements AttestTool Interface in-terface where secure migration process states codes aredefined. These error codes permits to agents determinethe happened when doMoveError and doCloneError meth-ods are called. It is necessary the use of a TPM and aCA in order to generate and verify the attestation mes-sages content. Moreover TPM provides the functionalitiesto generate attestation data that is AIK generation, datasignature, nonce values generation, etc. CA provides cre-dentials generation. Credentials are used to certify AIKsobjectives in the rest of containers trust in AIK signeddata.

A relevant aspect in the use of AIK in the protocol isto sign attestation data. TPM generates AIK and this mustbe certified by a CA. Protocol 5 details how this key isgenerated and certified.

Several interfaces interact in this process.

– AIKRequestData Interface: Contains data to allowTPM generates AIK as well as creates credentials gen-eration request.

– AIKRequestData Interface: Contains data to allow CAgenerate credentials to AIK.

– AIKResponse Interface: Contains data to allow TPMobtain CA generated credentials.

Figure 4. Main classes of the service.



Algorithm 5 Key generation and certification.

1: AttestTool Implement requests for generate an AIK keyand a credentials request to TPM.

2: TPM generates AIK key as well as the request and theseare delivered to AttestTool. Request is encrypted in suchways that only CA is able to have in clear.

3: AttestTool Implement sends a CA request.4: CA decrypts the request and generates corre-

sponding credentials which are delivered to Attest-Tool Implement in such a way that only TPM have inclear.

5: AttestTool Implement sends CA response to TPM.6: TPM decrypts the request and sends key data to Attest-

Tool Implement.

At this point we briefly described more relevantclasses. AIKRequestData Interface interface providesgetIdentityLabel() method, this returns AIK identity label.Once AIK reaches corresponding destination, service cangenerate configuration attestation data as well as signthem. Finally another relevant component of the solution,these are credential. CA generates AIK credentials definedby AIKCredentials Interface interface. Thus we finishSecureAgentMobility service analysis, and then we analyseSecureInterPlatformMobilityService service design.

7.3. Technology

Along this section we briefly described some of the under-lying technology of secure migration library of agents. Thissection is organized as follows: a subsection describing theTPM4Java library and a subsection that describes some ex-tensions to TPM4Java especially requested in our solution.

7.3.1. Use of TPM4Java library.

TPM4Java consists on java library developed in theDarmstadt Technique University. TPM4Java provides anew friendly layer to access to TPM functionality. BrieflyTPM4Java architecture is deployed on three main layers.

The architecture of TPM4Java is composed of three lay-ers: (i) a high level layer that provides access to commonTPM functionality (this is defined in TssHighLevel layer).(ii) A low level layer that provides access to almost fullTPM functionality (this is defined in TssLowLevel layer).And (iii) a backend used by the library that sends com-mands to TPM. High level layer is developed in such away that uses low level layer, then all tasks that can bedone with high level layer can be performed by means oflower levels calls. Accessing high level layer user mustcode:

TssHighLevel highLevel = TssFactory.

getHighLevel();

TPM4Java provides two main functional backends andone experimental:

– Linux backend. Meaning this backend, TPM4Java pro-vides access to TPM by this file(‘/dev/tpm’). Thisfact implies that user is allowed to read and writeon that file. In the case that uses a different fileis mandatory to specify by this linux command:‘Dtss.tpm=linux./dev/myTPM’.

– Window backend, a TPM driver provided by the man-ufacturer is provided for any windows-based system.This file is usually named tpmddl.dll and can be foundat windows/system32 folder. TPM4Java provides a filenamed javaddl.dll accessible by the application thatuses TPM4Java.

– Csharp backend. This is experimental backend. Thissolution includes a demon needed to run the ap-plication. To use the demon is mandatory for theapplication specify in commands line next mes-sage:‘Dtss.tpm=cs.localhost:12321’. The applicationestablishes a communication channel with the demonrunning in localhost. Therefore localhost can be up-dated by hostname where demon is running.

Finally the most relevant classes used in the developmentof our library are: (i) The TssLowLevel interface providesaccess to high level layer. (ii) The TssHighLevel interfaceprovides access to low level layer. (iii) The PcrSelec-tion.class provides a type of data to manage the informationof a set of PCR records. (iv) The SimplePrivacyCA classprovides an implementation of basic functionality of a CA.(v) The TCPAIdentityRequest creates an AIK a class of thistype is generated with needed data by CA generates theneeded information to active the AIK. (vi) The TCPAIden-tityCredential class contains the information generated byCA to activate the AIK. Finally, (vii) the TPMKeyWrapperclass contains the information of a key, with its public partand its private one. Private part is encrypted in such a waythat is in clear only in TPM.

7.3.2. Improvements to TPM4Java.

While developing Services Provided by Library someclasses and interfaces from TPM4Java library have beenmodified. Concretely the modified classes are:

– TssLowLevel interface. TPM OwnerReadPubekmethod is added because this is not included inTPM4Java but TCG 1.2 specification includes that.

– TssHighLevel interface. GenerateAIK method is mod-ified to returns a TPMKeyWrapper class correspond-ing to generated AIK instead of key handler in TPM.Therefore AIK data are needed to store it in the harddisc.

– TssCoreService class implements TssLowLevel inter-face. TPM OwnerReadPubek method has been added.

– TssHighLevelImpl class implements TssHighLevel in-terface. GenerateAIK method has been modified in



such a way that a TPMKeyWrapper class is returned.– PrivacyCA class is added, this is an altered version of

SimplePrivacyCA class provided by TPM4Java.

8. CONCLUSIONS AND AREAS FORFUTURE RESEARCH

In this paper, we have presented a new approach for theagent-based systems protection based on specific hardware.To validates our approach we provide a proof of concept bymeans of the ‘ SecMiLiA’. Along this paper, we deeplydescribe SecMiLiA library and all protocols involved. Es-pecially we discuss the ‘secure migration protocol’ as thebasis to our library. Moreover, we provide the methodologyto validate this protocol by means of AVISPA validation tool.

Concerning the ongoing work, an important issue is theimplementation of the Anonymous Direct Attestation pro-tocol. We mentioned that our library is based on the attesta-tion protocol based on the Certification Authority protocoldescribed in Section 3.1. Our solution is based on this pro-tocol due to the fact that TPM4Java only implements this.Certification Authority protocol provides important advan-tages as previous sections described but this entails somedisadvantages. Among these disadvantages we highlight theneeded to generate a certificate for each used key in everyattestation, which implies that many requests might be per-formed to the CA and this provokes a bottleneck for thesystem. Besides, we found that whether verification author-ity and CA act together the security of the attestation pro-tocol can be violated. That is, the use of the anonymousdirect attestation protocol entails some advantages. Let ussee through an example, certify issuer entity and verifier en-tity cannot collaborate to violate the system security. There-fore, a unique entity can be verifier and issuer of certificates.Last but not least of the found advantages of this approachis that certificates only need to be issued once which solvesthe aforementioned bottleneck. These advantages prove thatthe anonymous attestation protocol is an interesting optionfor attesting.

Possible future lines of research are the improvement ofthe keys management system of the library. Our library usesRSA keys for attestation protocol that must be loaded inTPM. However the size for key storage in the TPM is verylimited, then it must be carefully managed to avoid arisenspace problems.

Our library handles the keys in such a way that onlyone key is loaded in TPM simultaneously, therefore keysare loaded when will use and downloaded when used. Thisprocedure is not very efficient due to the continuous loadingand downloading of keys. For this problem we propose thepossibility of downloading the same key that we will usein next step. Of course this entails more issues. A differentimprovement in the key management lies on caching thesekeys. Then, several keys can be loaded simultaneously inTPM and that these can be change when more availablespace is needed. This solution entails to develop a key re-place policy to determine which key delete from TPM to

load a new key in the cache, but this task is out of the scopeof this paper.

Another future work is to extend the library with newfunctionalities to secure migration services in order toprovide concurrency. Secure migration services imple-mented in the library provide secure migration to a remotecontainer. However they have capacity to handle a uniquerequest simultaneously, then migration requests arrivingwhile migration is performed are refused. This happensdue to TPM management of the problem together withthe aforementioned key management problem. A possibleimprovement of the library is to provide of secure migrationservice with the capability handle simultaneously severalrequests.

ACKNOWLEDGMENT

Work partially supported by E.U. through projects SEREN-ITY (IST-027587) and OKKAM (IST- 215032) and DE-SEOS project funded by the Regional Government of an-dalusia.

REFERENCES

1. General Magic, Inc. The Telescript Language Refer-ence. Online available at http://www.genmagic.com-Telescript/ TDE/TDEDOCS HTML/telescript.html,1996

2. Stamos JW, Gifford DK. Remote Evaluation. ACM

Transactions on Programming Languages and Systems

(TOPLAS) archive 1990; 4(4): 537–564. ISSN:0164-0925

3. Brooks RR. Mobile code paradigms and security issues.Internet Computing, IEEE 2004 8(3): 54-59.

4. Mana A, Munoz A, Serrano D. Towards Secure AgentComputing for Ubiquitous Computing and Ambient In-telligence. In Fourth International Conference, Ubiq-uitous Intelligence andComputing, Hong Kong (China)2007; LNCS.

5. Mana, A. Software Protection based on Smartcards. PhD

Thesis. University of Mlaga. 2003.6. Hachez G. A Comparative Study of Software Pro-

tection Tools Suited for E-Commerce with Contri-butions to Software Watermarking and Smart Cards.PhD Thesis, Universite Catholique de Louvain,2003.http://www.dice.ucl.ac.be/hachez/thesis gaelhachez.pdf

7. Wahbe R, Lucco S, Anderson T. Efficent Software-BasedIsolation. In Proceedings of the Fourteenth ACM Sympo-

sium on Operating Systmes Principles. ACM SIGOPSOperating Systems Review, 1993; 203–216.

8. Gosling J, Joy B, Steele G. The Java Language Specifi-cation. Addison-Wesley, 1996.



9. Ousterhout JK. Scripting: Higher-Level Programming forthe 21st Century. IEEE Computer 1998; 23–30.

10. Gray RS. Agent Tcl: A Flexible and Secure Mobile-Agent System. In Proceedings of the Fourth Annual

Tcl/Tk workshop (TCL 96), 1996; 9–23.11. Farmer W, Guttman J, Swamp V. Security for Mobile

Agents: Authentication and State Appraisal. In Proceed-

ings of the 4th European Symposium on Research in Com-

puter Security (ESORICS’96), September 1996; 118–130.

12. Ordille JJ. When agents Roam, Who can You Trust? InProceedings of the First Conference on Emerging Tech-

nologies and Applications in Communications, Portland,Oregon, May 1996.

13. Chess D, Grosof B, Harrison C, Levine D, Parris C,Tsudik G. Itinerant Agents for Mobile Computing. IEEE

Personal Communications, 1995; 2(5): 34–49.14. Necula G. Proof-CaiTying Code. In Proceedings of 24th

Annual Symposium on Principles of Programming Lan-

guages, 1997.15. Yee BS. A Sanctuary for Mobile Agents, Techni-

cal Report CS97-537, University of California in SanDiego, April 28, 1997. Online available at http://www-cse.ucsd.edu/users/bsy/index.html

16. Haber S, Stornetta S. How to Time-Stamp a Digital Doc-ument, Journal of Cryptology 1991; 3: 99–111.

17. Roth V. Secure Recording of Itineraries Through Cooper-ating Agents. In Proceedings of the ECOOP Workshop on

Distributed Object Security and 4th Workshop on Mobile

Object Systems: Secure Internet Mobile Computations,INRIA, France, 1998; 147–154.

18. Scheider FB. Towards Fault-Tolerant and Secure Agency.In Proceedings 11th International Workshop on Dis-

tributed Algorithms, Saarbucken, Germany, September1997.

19. Vigna G. Secure Recording of Itineraries ThroughCooperating Agents. In Proceedings of the ECOOP

Workshop on Distributed Object Security and 4th

Workshop on Mobile Object Systems: Secure Inter-

net Mobile Computations, INRIA, France 1998; 147–154.

20. Riordan J, Scheneider B. Environmental Key GenerationTowards Clueless Agents. Mobile Agents and Security.

Lecture Notes in Computer Science 1419 Springer, VignaG. (ed.). 1998. ISBN 3-540-64792-9.

21. Sander T, Tschudin C. Protecting Mobile Agents AgainstMalicious Hosts. In Mobile Agents and Security, Vol. of

1419 in Lecture Notes in Computer Science, Vigna G.(ed.). Springer 1998, ISBN 3-540-64792-9, 1998.

22. Hohl F. Time Limited Blackbox Security: Protecting Mo-bile Agents From MaliciousHosts. In Mobile Agents and

Security, Vol. of 1419 in Lecture Notes in Computer Sci-

ence Vigna G. (ed.), Springer-Verlag, 1998; 92–11323. Trusted Computing Group: TCG Specifications. 2005.

Online available at https://www.trustedcomputinggroup.org/specs/

24. Stem JP, Hachez G, Koeune F, Quisquater JJ. Ro-bust Object Watermarking: Application to Code. In In-

formation Hiding ’99, vol 1768 of Lectures Notes in

Computer Science (LNCS), Pfitzmann A (ed.), pages368-378, Springer-Verlag: Dresden, Germany, 2000.http://citeseer.nj.nec.com/stem00robust.html

25. Collberg C, Thomborson C. Watermarking, Tamper-Proofing, and Obfuscation—Tools for Software Protec-tion. Technical Report 170, University of Auckland,2000.

26. Pearson S. How can you trust the computer in front ofyou? Technical Report, Trusted E-Services Laboratory,HP Laboratories Bristol. HPL-2002-222, November 5th,2002.

27. Trusted Computing Group. TCG SpecificationArchitecture Overview, Revision 1.4 (2007),https://www.trustedcomputinggroup.org/groups/TCG14ArchitectureOverview.pdf

28. Armando A, Basin D, Bouallagui M, Chevalier Y, Com-pagna L, Modersheim S, Rusinowitch M, Turuani M,Vigano L, Vigneron L. The AVISS Security ProtocolAnalysis Tool. In Computer-Aided Verification CAV’02,LNCS 2404, Brinksma E, Larsen KG (eds.) Springer-Verlag, Heidelberg, 2002; 349–354. URL of the AVISSand AVISPA projects: www.avispa-proiect.org

29. Hussain M, Seret D. A Comparative study of SecurityProtocols Validation Tools: HERMES vs. AVISPA. InProceedings of International Conference on Advanced-

Communication Technology (ICACT) IEEE Communica-tion Society, 2006.


TPM-based protection for mobile agents

Documents

Transcript of TPM-based protection for mobile agents