[cap-talk] Perimeter security

[Mark S. Miller]

Neal H. Walfield wrote:
> I thought I knew what perimeter security was until I tried to explain
> it.  According to:
> 
>   http://www.erights.org/elib/capability/perimeter.html
> 
> Bob must protect the Power using perimeter security when: the Power
> when:
> 
>  - 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

     Cheers,
     --MarkM