[cap-talk] Perimeter security
Mark S. Miller
markm at cs.jhu.edu
Sun Jan 14 18:03:57 CST 2007
Neal H. Walfield wrote:
> I thought I knew what perimeter security was until I tried to explain
> it. According to:
> Bob must protect the Power using perimeter security when: the Power
> - Alice has given Bob access to Power
> - Mallet wants access to Power
> - Bob does not want to give him access
> - Bob and Mallet are not in communication
> Bob needs to protect his perimeter from Mallet. What can Mallet do to
> violate the perimeter which is Bob's fault, i.e., not the fault of his
> reliance set (e.g., decrypting the channel or sifting through the hard
> drive) and isn't a confused deputy?
> Or do I understand perimeter security incorrectly?
From the way you state your question, I'd say you do understand perimeter
security correctly, and my writing on that web page could use some clarification.
To answer your question, mostly yes. The perimeter security issue here is
indeed mostly the responsibility of Bob's reliance set, not Bob's responsibility.
Within an object-capability framework, the one remaining issue which is best
seen as Bob's responsibility is side channels. Also, let me acknowledge up
front that it's an issue that I've assumed away in almost all my writings to
date on these topics -- by restricting consideration to "overt causality".
Overt channels are communications channels guaranteed by the semantics of the
underlying platform. Since correct programs must only rely on the spec of
their reliance set, and not on the happenstance of a given implementation of
this spec, correct programs may only rely on overt channels to work. However,
correct secure programs should of course not assume their adversaries are
likewise constraining themselves.
Ideally, in an object-capability system, only capabilities provide overt
causal paths, so overt communications only happens on permitted pathways. I
like using visual metaphor words for overt communications -- like "see",
"show", "reveal", etc -- since sight often requires line of sight or some
explicit mechanism, and it is often possible to be confident that something is
hidden from sight.
For non-overt channels, I like auditory metaphor words, which works well with
established terms like "wall banging", etc.
Non-overt channels may be divided into side channels and covert channels
depending on the assumed intentions of the signaler (Bob). For both side
channels and covert channels, the signaler encodes information within the
degrees of freedom allowed by the non-determinism of the underlying platform's
spec. The listener (Mallet) on a non-overt channel listens by sensing patterns
in the non-determinism (like timing variations), and, perhaps based on
assumptions about the underlying implementation, inferring information
from/about the signaler.
For both side channels and covert channels, the listener is assumed to be a
potential adversary, since a correct program will avoid depending on
unspecified behavior. The defining difference between side channels and covert
channels is whether we assume the signaler is assumed to be a potential
adversary or not.
In order for crypto to be able to provide security, it must be possible to
write non-adversarial code (Bob, our crypto library) which employs secrets
without enabling a potential adversary (Mallet) to hear them. In a system in
which we believe this to be possible, but in which we have not prevented
covert channels, we must consider it the responsibility of this friendly
secret-handling code (Bob) to avoid encoding these secrets into
non-determinism which might be heard by a potential adversary (Mallet).
Text by me above is hereby placed in the public domain
More information about the cap-talk