A Security Architecture for Agent Communication Languages

One of the essential features of a software agent is its ability to cooperate with other software agents. This cooperation requires, in general, that software agents be able to communicate in a appropriately rich agent communication language (ACL)
of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Security Architecture forAgent Communication Language Tim Finin, James Mayfield and Chelliah Thirunavukkarasu Computer Science and Electrical EngineeringUniversity of Maryland Baltimore CountyBaltimore MD 21250 USA Abstract One of the essential features of a software agent isits ability to cooperate with other software agents.This cooperation requires, in general, that softwareagents be able to communicate in a appropriatelyrich  agent communication language (ACL) and as-sociated protocols. For an ACL to effective in anopen environment like the Internet, it must supportsecurity, privacy, the integrityof data, and authenti-cation of agent identity. We discuss some basic andextended security requirements for software agentsandan architecturetosatisfythoserequirementsforKQML-speaking agents. The proposed architec-ture is based on cryptographic techniques and al-lowagents to verifythe identityofother agents, de-tect message integrity violations, protect confiden-tial data, ensure non-repudiation of message ori-gin and take counter measures against cipher at-tacks. Many of these security features will be sup-ported by and/or implemented by transport mecha-nisms (e.g., socket-communication, HTTP, SMTP)on which the ACL will be carried. However, we ar-guethatsuchsecuritypropertiesmustbepart ofandreflected in the ACL model and can not be totallyrelegated to the lower levels of the communicationprotocol stack. 1 Introduction One of the essential features of a software agent is its abil-ity to cooperate with other software agents. This cooperationrequires, in general, that software agents be able to commu-nicate in a appropriately rich  agent communication language (ACL) and associated protocols. For an ACL to effective inan open environment like the Internet, it must support secu-rity, privacy, the integrityof data, and authentication of agentidentity. 1.1 Why agent security? Several paragraphs saying why security must be modeled inthe agent level in addition to the underlying transport levels.Mainreason isthat agentsmust beable toreason about these-curity properties of their agents. Lets us maybe do some use-ful things, like decide who to talk to and by what means andalso to selectively ask for authentication when it is needed.Introducenotionoflazy authentication. TIe intoa truthmain-tenance scenario–onlyask an agent toauthenticatewhen you*really* need to verify it is indeed the agent you think it is.etc... 1.2 KQML Knowledge Query and Manipulation Language (KQML) [1]is a communication language and protocol which enables au-tonomous and asynchronous software agents to share theirknowledge and or work towards cooperative problem solv-ing. It was developed as a part of the  Knowledge Sharing Effort   [20; 19; 13]. The KQML language can be thought of as consisting of three layers: the content layer, the messagelayer, and the communication layer. The content layer bearsthe actual content of the message, in the programs own repre-sentation language. KQML can carry expressions encoded inany representation language, including languages expressedas ASCII strings and those expressed using a binary nota-tion. Some KQML-speaking agents (e.g., routers, very gen-eral brokers, etc.) may ignore the content portionof the mes-sage, except to determine where it ends.The communicationlevel encodes aset ofmessage featureswhich describe the lower level communication parameters,such as the identity of the sender and recipient, and a uniqueidentifier associated with the communication.It is themessage layer that isused to encode a message thatone application would like to transmit to another. The mes-sage layer forms the core of the KQML language, and deter-mines the kinds of interactions one can have with a KQML–speakingagent. A primary functionof the message layer is toidentifythe protocol to be used to deliver the message and tosupplya speech act orperformative whichthe sender attachesto the content (such as that it is an assertion, a query, a com-mand, or any of a set of known performatives). In addition,since the content may be opaque to a KQML-speaking agent,this layer also includes optional features which describe thecontent language, the ontology it assumes, and some type  of description of the content, such as a descriptor naming atopic within the ontology. These features make it possiblefor KQML implementations to analyze, route and properlydeliver messages even though their content is inaccessible. 1.3 Security Requirements We arrived upon the followingrequirements for a KQML se-curity model based on the analysis of the security models forPrivacy Enhanced Mail [4], CORBA [3] and DCE [5]. Inter-ested readers are referred to [2], for a thorough treatment of security threats and mechanisms to counter them. The secu-rity capabilities that should be supported include:   Authentication of principals.  Agents should be capable of proving their identities to other agents and verifying the iden-tity of other agents.  Preservation of message integrity.  Agents should be able todetect intensional or accidental corruption of messages.  Protectionof privacy.  Thesecurityarchitectureshouldprovidefacilities for agentsto exchangeconfidentialdata.   Detection of Message duplication or replay.  A rogue agentmay record a legitimate conversation and later play it back todisguise its identity. Agents should be able to detect and pre-vent such playbacksecurity attacks.   Non-repudiation of messages.  An agent should be account-able for the messagesthat they have sent or received, i.e., theyshould not be able to deny having sent or received a message.  Prevention of messagehijacking.  A rogue agent should not beable to extract the authentication information from an authen-ticated messageanduse it to masqueradeas a legitimate agent. We also consider several additional constraints or desider-ata for the architecture. First, the security architecture shouldnot depend on the semantics of KQML performative (i.e., an ask-all  from an agent will entail a  tell  or  sorry  from the re-ceiver). The security model should be general and flexibleenough to support different models of agent interaction (e.gcontract net, electronic commerce). Neither should the archi-tecture depend on the features offered by any transport layersince we want to facilitate agents to communicate across het-erogeneous transport mechanisms and to extend the securitymodel toaccommodate embedded KQML messages. Second,we desire a model which allows light-weight agents with-out cryptographic capabilities to authenticate the sender of a message using the services of trusted  authenticator   agents.Finally, we want to allow agents the flexibility to use differ-ent cryptographic algorithms so that it should not have harddependencies on any specific cryptographic algorithm. Simi-larly, we reject systems which assume a global synchroniza-tion of time – it difficult to achieve and leads to further secu-rity issues of its own [7]. 2 Architecture Overview The proposed security architecture is based on data encryp-tion techniques [9]. In tune with the asynchronous nature of general ACLs like KQML, the model expects a secure mes-sage to be self authenticating and does not support any chal-lenge/response mechanism to authenticate a message after ithas been delivered. The architecture supports two securitymodels, basic and enhanced. The basic security model sup-ports authentication of sender, message integrity and privacyof data. The enhanced security model additionally supportsnon-repudiation of srcin (proof of sending) and protectionfrom message replay attacks. The enhanced security modelalso supports frequent change of encryption keys to protectfrom cipher attacks. 2.1 Cryptographic background The following paragraphs define the cryptographic tech-niquesused bythisarchitectureand the new performativeandtheparameters that have been introducedtoimplement the ar-chitecture. Encryption Keys.  An agent that implements the proposedsecurity architecture should have a master key, K  a  , which itwould use to communicate with other agents. This key canbe based on a symmetric or asymmetric 1  key cryptosystem.If a symmetric key mechanism is used, we suggest that theagent, inadditiontothegeneral master key, alsouse a specificmaster key, K  a 1 ;a 2  for each agent that it communicates with,for better privacy and stronger authentication. If more thantwo agents share a single master key, any of those agents canmasquerade as the otheror eavesdrop onall the conversationsbetween the agents sharing the key. If a master key is sharedby more than two agents, the strength of security is directlyrelated to the degree of trust between the agents.If an agent does not share a master key, K  a 1 ;a 2  with an-other agent, it can use its master key, K  a  , or can use the ser-vices of a central authenticationserver togenerate such a key.The agents may use different keys in either direction of mes-sage flow i.e., K  a 1 ;a 2  is created by  a1  and would be usedwhen  a1  is sending a message to  a2  and K  a 2 ;a 1  is created by a2  and wouldbe used when  a2  is sending a message to  a1 .If an asymmetric key mechanism is used, a unique key foreach pair of agents is not necessary, as the agent can use thepublic key of its peer agent to encrypt the message and pre-vent eavesdropping. It can also use its private key to sign themessage and prove its identity to its peer. We assume thatthe agents know the master key of the other agents. We alsosuggest a secure mechanism to do master key lookup. Session key.  In the enhanced model, the agents use an ad-ditional key, the session key, to ensure privacy, message in-tegrityand proofof identity. The session key can be symmet-ric or asymmetric and can be generated with the help of theauthentication server. The session keys are set up by usinga protocol explained later which requires the use of a masterkey to ensure security. 1 Public key cryptosystems are a very familiar example of anasymmetric key system.  The agents can use either the session or master key for ex-changing messages and must inform the other agent of thekey that was used for encryptionto ensure proper decryption.When agents exchange keys, they encrypt them usingthecur-rent session or master key. Keys are never exchanged in cleartext form. We recommend the use of the enhanced securitymodel 2  with an expensive master key and a cheap sessionkey which is changed frequently. Message Id.  The message ID is used in the enhanced secu-rity model to protect agents from attacks by message replay.When the two agents establish a session key, they also ex-change a message ID which the sender would use in the nextmessage. Every message from an agent would carry a mes-sage ID and a new message ID for the next message. Eachmessage ID is used only once to prevent replay and they areencrypted using the session or master key for security. Message Digest.  Each secure message generated using thisarchitecture has a message digest or signatureassociated withit. The digest is calculated using a secure hash function likeMD2, MD5 or SHS [9]. This hash function computes a dig-ital fingerprint of the message (i.e., acts as a ”checksum” forthe message). The sender then encrypts this digest using thesession or master key and attaches it to the message.This encrypted message digest forms the core of the secu-rity architecture. The receiver of a message uses this digestto verify the identity of the sender and the integrity of themessage. The digest also protects the message ID field frombeing hijacked and used in a different message. 2.2 Changes to KQML In order to implement this security architecture we proposeseveral new KQML performatives, several new parametersand some modifications to a proposed standard ontology foragents. Ontological assumptions.  We assume that KQML-speaking agents use a basic agent ontology which provides asmall set of classes, attributes and relations helpful in talkingabout agents, their propertiesand the relationshipsand eventsin which they partake. Assuming this ontology, this architec-ture introduces a new sub-class of agent named  authenticator  and a new relation,  key/5  which describes a key used by anagent: (key <sending-agent><receiving-agent><master-key?><key-type> 2 This may not alwaysbe possible. The enhancedsecurity modelcannot be used if the sender of a message does not know who theintended recipient is; i.e in the case of facilitation performativesthe facilitator determines the intended recipient and not the messagesrcinator. <encrypted-key>) An instance of this relation specifies a key that the sendingagent will use in secure communication with the receivingagent. If the third argument is true  then the key is a masterkey, else it is a session key. If the receiving agent is a vari-able (e.g., ?  ), then the key is used by the sending agents forcommunication with all agents. Note that this would typi-cally be the case for asymmetric keys. We assume that agentaddresses are represented in this ontology with the  address/3 relation: (address <agent><transport><transport-address>) Instances of this relation specify transport addresses for theagent given in the first argument, as in: (address r2d2 smtp r2d2 tcpip ( 8088)) These addresses are known to special agents, such as  agent name servers  and  authenticatoragents .Several new KQML parameters are required to implementthe security architecture. :auth-digest (    digest-type    encrypted-digest    ).  The digest-type  specifies the hashing function used (MD4, MD5,etc.) to compute the message digest. The  encrypted-digest   isthe message digest encrypted using the key specified by the :auth-key parameter. This parameter shouldbe present topre-vent message hijack, and to provide for sender authenticationand integrityassurance. :auth-msg-id (    msg-id    encrypted-msg-id    This pa-rameter is required only in the enhanced security modelwhere it is used prevent message replay. The value is a listwhosefirst element istheagreed uponrandom string,or NIL  if this is the first message. The second element specifies themessage ID for the next message and is encrypted using thekey specified by the  :auth-key  parameter. For effective pre-vention of message replay, this parameter should be presentin each message. :auth-key (    bool    key-type    encrypted-key    ). This parameter specifies the key being used to encrypt any :auth-digest  and  :auth-msg  parameters present. If the first el-ement of the triple is is true  then the master key is used 3  ,otherwise, the session key is used.The followingnew KQML performatives have been addedto implement the security architecture. auth-link.  The sender wishes to authenticate itself to thereceiver and set up a session key and message ID. 4 3 An agent would use the master key for encryption if it does notshare a session key with the receiving agent or if it does not knowthe receiverin advance. Under these circumstances,it could usethisparameterto helpthereceiverin choosingtheproperdecryptionkey. 4 Wecouldeliminate the needfor thisperformative if wearewill-ing to send an  achieve  with an embedded  auth-challenge  but this issimply a mater of protocol detail design.  auth-challenge.  The sender challenges the identity of thereceiver in response to an  auth-link  . The sender encrypts arandom string using the master key K  s;r  or K  s  and sends itas  :content  . 5 auth-private.  The sender is sending a confidential mes-sage to the receiver. The  :content   parameter contains the en-cryptedmessage and the :auth-key parameter specifies theen-cryption key. The  :auth-digest   parameter should be presentto verify the identity of the sender and the  :auth-msg-id   and :auth-key  parameters may be present if enhanced securitymodel is used. help.  We introduce a new generic performative by whichanagent canask anotherforhelpinprocessingthetheembed-ded performativegiven as the value ofthe  :content  parameter.The nature of the ”help” is determined by the embedded per-formative and the value of the  :ontology  parameter. If the :ontology  is  authentication , then a crypto-unaware agent isenlistingthe helpof a trusted friendto process a performativeit has received, which is included as the value of the :contentparameter. This embedded message can be either an  auth-link   or a generic message to be authenticated. In the case of aauth-link (i.e., a challenge), the appropriate response is a re-ply with a random challenge string. In the case of a messageto be authenticated, the response will be an error or a reply toforward. 3 Security model An implementation should support the following protocol toconform with the basic security model. This model supportsauthentication, integrity and privacy of data. If asymmetrickeys are used for session and master keys, this model alsosupports non-repudiationof srcin.When R2D2 sends a secure message to C3PO, it wouldcompute a message digest and encrypt it usingthe master key(as indicated by the value T   for the  :auth-key  parameter). <performative>:sender R2D2:receiver C3PO:auth-key T:auth-digest (<digest-type><encrypted-digest>)... Alternatively, if R2D2 needs to send a confidential messageto C3PO, it can encrypt the message and embed it in an  auth- private  performative. auth-private:sender R2D2:receiver C3PO:auth-key T:auth-digest (<digest-type> <encrypted-digest>) 5 Again, if we were motivated to decrease the number of perfor-matives at the expense of putting more in the authentication ontol-ogy, we could represent an  auth-challenge  performative as an  ask-one with  :content  of  (encrypt?sES)  whereESis theencryptedstringand the encrypt/2 relation holds between the string with respect tothe current key. :content <encrypted-KQML-message> This model can be used when R2D2 does not know the recip-ient in advance, e.g., for messages to be broadcast or routedby a facilitator agent, or if R2D2 and C3PO do not requirepreventionof message replay and can afford the cost of usingthe master key.In the above message, the  :auth-digest   parameter can beused to verify the integrity of the message, authenticate thesenderand ensure non-repudiationofsrcin(ifthe master keyis asymmetric in nature). If the message has been corrupted,the message digest will not agree with the value of the  :auth-digest   parameter. Since the message digest is encrypted withthe master key of the  :sender  , only the  :sender   or the agentswith which the  :sender   shares the encryption key could havegenerated the message. If the master key is an asymmetrickey, only the  :sender   could have generated the message, asonly the  :sender   knows the private key that has been usedfor encryption. Note that we can only verify the identity of the generator (i.e., the message was encrypted by the  :sender  agent) of the message. This message can be a replay of alegitimate message previously sent by the generator. 3.1 Enhanced security model The enhanced security model adds prevention of messagereplay, and stronger non-repudiation of message srcin (if asymmetric keys are used). Even though non-repudiationcan be achieved in the basic security model, we can only besure that the message was generated by the sender, as a rogueagent can replay a message and we will not be able to detectit.In [ ? ] we demonstrate how the new KQML performativesand parameters can be used to converse/communicate se-curely, the role of authenticator agents for key registrationand management. In the remainder of this section we givetwo small examples and show how the protocols can be cap-tured in Protolingua. Self authentication Agent R2D2 has cryptographic capabilities and wouldlike toproveitsidentitytoagent C3PO.The agents wouldfollowthefollowinghandshake protocol to achieve it. 1. auth-link 2. auth-challenge3. replyauth-private R2D2 C3PO 5. <performative>/ 4. reply/error  Figure1:  Theselfauthenticationprotocol isinitiatedbyanagent who wants to establish its identity before beginninga dialog. R2D2 sends an  auth-link  performative to C3PO.  auth-link (1):sender R2D2:receiver C3PO:reply-with <expression> If C3PO will not authenticate senders, it can respond withan  error  , otherwise it sends a  auth-challenge  with a randomstring encrypted using the master key. A random string isused to prevent message replay. auth-challenge (2):sender C3PO:receiver R2D2:in-reply-to <expression>:reply-with <expression>:content <encrypted-random-string> R2D2 responds with a  reply  performative with the  :auth-digest  ,  :auth-msg-id   and new session key (if present) en-crypted in the master key. The value of   :content   and  :auth-msg-id   is the decrypted random string. The session key pa-rameter is optional. reply (3):sender R2D2:receiver C3PO:in-reply-to <expression>:reply-with <expression>:auth-digest (<digest-type> <encrypted-digest>):auth-msg-id (<msg-id> <encrypted-msg-id>):auth-key (T <key-type> <encrypted-key>):content <random-string> Now, C3PO can verify if the sender is R2D2 by inspectingthe random string. Only R2D2 (or in the case of symmet-ric key, one of the other agents which shares the same key)could have decrypted the random string as it was encryptedusing the master key. The message digest can be used fornon-repudiationif asymmetric keys are used.C3PO responds with a  reply  or an  error   depending on thesuccess of authentication(3).Now, R2D2 can send an authenticated message to C3POby usingthe session key or master key to encrypt the messagedigest and a non replayable message by using the  :auth-msg-id   parameters. <performative> (4a):sender R2D2:receiver C3PO:auth-digest (<digest-type> <encrypted-digest>):auth-msg-id (<msg-id> <encrypted-msg-id>):auth-key (<bool> <key-type> <encrypted-key>)... Or if R2D2 needs to send a confidential message to C3PO,it can encrypt the message and embed it in an  auth-private performative. auth-private (4b):sender R2D2:receiver C3PO:auth-digest (<digest-type> <encrypted-digest>):auth-msg-id (<msg-id> <encrypted-msg-id>):auth-key (<bool> <key-type> <encrypted-key>):content <encrypted-KQML-message> Crypto un-aware agents Agent Leia may not have crypto capabilities. But it trusts itsfriend R2D2 and R2D2 is prepared to authenticate messageson behalf of Leia. Since Leia does not have crypto capabili-ties, it will not accept  auth-private  performative. The agentswould follow the handshake protocol given below to verifySkyWalker's identity. SkyWalker Leia R2D2 auth-private1. auth-link 2. auth-challenge-help4. auth-challenge5. reply6. auth-mesg-help3. reply9. <performative>/ 8. reply/error  7. reply/error  Figure2:  Using the trusted friend protocol, agent leia asksagent R2D2 for help in authenticating agent Skywalker. Agent SkyWalker begins by sending Agent Leia an  auth-link   message to initiate the process of proving its identity toLeia. auth-link (1):sender SkyWalker:receiver Leia:reply-with <expression> When Leia receives an  auth-link   message from SkyWalker,Leia requests a challenge stringfromitstrustedfriend,R2D2. help (2):sender Leia:receiver R2D2:reply-with <expression>: ontology authentication:content (auth-link:sender SkyWalker:receiver Leia:reply-with <expression>) R2D2willgenerate arandomstringonbehalfofLeia, encryptit using the master key (shared by Leia and SkyWalker orLeia's master key, which R2D2 knows) and will forward it toLeia. reply (3):sender R2D2:receiver Leia:in-reply-to <expression>:content (SkyWalker <encrypted-random-string>) Leia will construct an  auth-challenge  performative and sendit to SkyWalker. Subsequent performative from SkyWalkerwith an  :auth-digest  will be forwarded to R2D2. auth-challenge (4):sender Leia:receiver SkyWalker:reply-with <expression>:in-reply-to <expression>:content <encrypted-random-string> SkyWalker will respond with a secure  reply . reply (5):sender SkyWalker:receiver Leia
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks