Data Mufflers

There is an idea that has cropped up in two areas to do with limiting the bandwidth of covert channels. It has nothing to do with limiting exhaust noise from internal combustion engines. See “Billing and the Factory” in this about earlier introduction to these ideas. Also US patent 5,574,912 presents (and transcends) some of these ideas.

Engineering a Covert Channel

The basic idea is best illustrated in the billing reference above. Think of the slow data channel (SDC) as a coin slot. I use the term muffler here. The muffler is an object with one input integer stream and one output integer stream. The sum of a stream at a point in time is merely the sum of the integers in the stream up to that time. The integers of the streams of the muffler are all positive. The muffler input is made accessible to the confined object and the muffler output is made accessible to a software agent with a responsibility to pay the program owner. The muffler design goal is that the output sum track the input stream but with delay and noise added so as to limit the signal available from the output to a known small quantity, and thus trade-off payment latency with signal bandwidth.

The client is likely to want to limit his payments. The most direct way to offer this control is to enhance the muffler function by giving the client an additional facet to the muffler by which he can read and limit the flow, much as he might observe and control CPU consumption via a meter service key. From a bandwidth perspective the holder of this service key is considered as inside the confined object. Payments that he allows with the muffler service key are delayed and otherwise muffled. A invocation on the muffler input stream, signaling payment, will not return until the holder of the service key authorizes that payment. After such authorization, payment is muffled but certain, or at least beyond the control of the muffler service key.

Morphogenesis

We have described the rough function of the muffler and its facets and who should hold them; now we consider how to bring about this arrangement securely. In the scenario below B is the application builder who wishes to charge for use. Here is the chronology:

As B creates the factory F for his application he also invokes a MCC (muffler creator creator). MCC is broadly available and trusted by all these parties.
A parameter to this invocation is a deposit key to B’s account. The yield of this invocation is a MC we will call P here. B includes P as a component of F.
B distributes the factory requestor’s key and P as a pair to potential bashful clients.
Client C needs an instance of B’s application. C consults MCC to verify that P is indeed from MCC. C then invokes P (the MC) passing a withdrawal facet for C’s bank account. Two keys to a new muffler are returned: IS, the input stream; and SK, the muffler service key.
C invokes F via its requestor’s key passing in IS. C retains SK to control and limit payments.
Among the first steps taken by the new application instance is to verify that IS is indeed to B’s account. This test is performed by the instance asking P of the validity of IS.

Each player now has the correct keys and has verified this.

Remaining Design Problems

This design is not yet properly recursive. What C does to create an instance of the application cannot be done by the confined application for it must lack access to a bank withdrawal key.

Perhaps payment limitation and observation should be part of bank logic instead of muffler logic.

At the foundation of the recursion problem is the question of the payment path from the code of the sub-contractor to the sub-contractor. Are the two security latencies in series?

To throw in more problems before we solve the above, let me mention a payment scheme suitable to some applications. The application produces an answer but only then prices it in light of the answer. It might even tantalize the requestor by displaying evidence of the answer. It is no skin off the application owner’s nose if the requestor refuses to pay. Presumably the requestor has paid for the CPU cycles one way or another. If, on the other hand, the requestor has paid a sub contractor, such payment is skin off the nose.