From Proof-Carrying Code to Agent Technologies

I am taking a course on "Language-Based Security" at Danish Technical University. After listening a couple of lectures on Proof-carrying code (see [Nec97]) we were given a task to devise a proof-carrying architecture (PCA) for data exchanges. The idea of the PCA is the following. The data provider specifies the security policy for the data consumer to obey, and the data consumer provides a proof that he can satisfy the defined requirements. For example, in case of a customer submitting his credit card data to the web-shop, the former might demand from the latter to use specific data encryption algorithm, say 3DES, and to check that all communication partners encrypt data before sending it on.

The problem with the above requirements is the control over the data. Even if the web-shop can provide a proof that it is capable of using 3DES on the way from the customer to the web-shop, there are no guarantees that on the way from the web-shop to the bank the same security standards will be used. While thinking over the possible implementations of the PCA, I came to the conclusion that a possible solution lays in utilization of the agent technologies.

Here is the description how this scheme can work. The customer creates an agent, sets data and specifies the security policies for the data transfer and manipulation. An example of such a security policy might be the following:

• Encrypt data before sending over the web using Triple-DES
• Allow Visa payment provider to retrieve the credit card data
• Allow web-shop to redirect the agent to the payment provider
  

Before executing operations (eg. "get data") the agent will check the caller's credentials to verify that such an operation is allowed for the given caller. The idea behind this is that the web-site does not really need to see the credit card data, all it wants is the confirmation from his bank or payment provider that money were transfered. That is why, the agent allows web-site to redirect itself to the payment provider, but not to get the actual credit card details. And of course additional data (eg. account details to which the money should be transfered) can be set upon an agent with its own security policy.

Here is the possible flow of interactions:



Well, the above approach has a lot of issues to consider.

[Edited on May 20, 2010] Below each issue there are some hints I received from Lawrie Brown :

1. How to verify caller credentials (probably the agent may consult the certification authority, like Verisign)?
   

   Lawrie: Check the certificate signature using the well known public key of the signing CA, and also contact the CA to check the Certificate Revocation List (CRL) to ensure that the certificate has not been cancelled for some reason.

2. Which encryption techniques to use? Let's say we want to allow both Visa and Mastercard payment providers to get actual card information. But we do not know in advance when we configure the agent which exactly provider will be used by the web-shop. And the web-shop should itself not be able to decrypt this data even if it obtains it from the agent's code. If we use asymmetric cryptography we will need to store two copies of encrypted data for each of the providers. But if we use symmetric cryptography, we would probably not want to send the key within the agent.
   

   Lawrie: You would store ONE copy of the data, encrypted using a block or stream cipher with a temporary randonly created session key. And then store two copies of that key, separately encrypted using the providers respective public keys. This means the agent can send the encrypted data, along with the relevant public key encrypted session key, to the desired recipient. And no-one, looking at the data carried by the agent, would be able to recover the encrypted info apart from the two providers who are the only ones with suitable private keys needed to recover the session. This process can of course be extended to more than two providers.



3. How to secure data within the agent from illegal obtaining by code inspection or disassembling?
   

   Lawrie: This to me is the really big issue, how does the sender know the agent has not been corrupted, or the actions/answer compromised? Thats the fundamental issue behind the use of agents, and I don't know the answer.

Despite the problems and immaturity of the agent-based systems, my prediction is that in some years we will use agents on a regular basis. Time will show... ;)

[Nec97] George C. Necula. Proof-carrying code. pages 106-119. ACM Press,
1997.

---

http://www.linkedin.com/in/oldbam