SEC: object security

[Mike Prince]

On Tue, 1 Nov 1994, Cybernaut wrote:

>  
>     I'm wondering if there wouldn't be some kind of CRC possible when sending
> an agent out and getting its report back. Some kind of code that is set when
> the agent is dispatched and checked against an encrypted key on the agent upon
> its return. If they don't match, the agent has been compromised and has to be
> executed (non-computer definition). You're right, mike, these analogies are
> fun.
>     This CRC, could be on a stack for travelling through multiple systems. 
> Really good analogy coming up. You send an agent out to buy the best, yet ch
> cheapest tickets to an upcoming concert. It travels from your system to a
> system that keeps track of all companies that sell tickets and compares all the
> prices of the kind of ticket you want. Choosing the ticket and company it wantss
> to buy from, it proceeds to your bank's system where it withdraws the needed
> funds. From there, it proceeds to the ticket company, buys the ticket and 
> returns home the same way it went out. At each return, the agent can be checked
> for the CRC that was stacked upon the previous CRC. If the CRC fromthe ticket
> company back to the bank doesn't match, the agent was compromised with some ae
> amount of your funds and may require a criminal investigatation to determine
> exactly where it was compromised. And so, all the way back home, the agent tr
> travels until it arrives back at your system with the digital tickets, if all l
> CRCs checked out.

Here's my solution.  Every time an agent leaves a Tool Box it is vectored 
through a "gate" tool.  That tool may decide to simply pass the agent 
along, thus providing no security.  Whenever an Agent re-enters the tool box 
it is again passed through another gate tool.

To provide security, the exit gate may simply shove a big number on the 
return (path) stack of the agent, essentially a key.  Upon any agent 
returning to that tool box, the gatekeeper tool would require that key to 
get in.  Otherwise it might banish the incoming agent to a kernel punishment 
function, whos job is to track down and clean up misbehaving tools.

Going one step further, the exit gate might encrypt EVERYTHING about the 
agent (Data, return Path) and just leave the next destination on top of 
the Path to get the agent to its recipient.

The recipient would know how to decode the agent, process it, re-encode 
it, and return it.  Again the re-entry gate decrypts it.  All is well and 
happy.

I'd like to keep as much of the implementation of the security out the 
the kernel, and delegate it to the tools.  What I want built in at the 
low level is the ability to implement it.

Mike