[e-lang] On the Value of Covert Channel Analysis

[Mark S. Miller]

At 01:49 PM 5/30/2002 Thursday, David Chizmadia wrote:


>> >The objective of covert channel analysis is (a) to *understand* the rate
>> >of such leakage, and (b) to reduce it insofar as reduction is possible.
>>
>> Can we substitute for #b "to reduce it insofar as reduction is practical"?
>> Admittedly, this makes it vacuous as an evaluation criteria.  However, the
>> original statement is almost surely impractical to achieve.
>
>As interpreted by the US evaluation community (which is the only one that
>occassionally shows an interest in this subject), this is the substitution
>used.
>
>It is important to note Jonathan's point (a): as a matter of practicality,
>the existence of covert channels is accepted as an unpleasant side effect of
>sharing computing resources. The goal is to be aware of their existence in
>order to make the use of static analysis a viable approach to managing them.
>Said another way, if you're worried about wallbanging, knowing which walls
>are connected allows you to keep evil people - who might be inclined to
>cooperate to share secrets that shouldn't be shared - away from those walls.

If you can truly keep evil people (or rather, their objects within your 
system) away from the wall they'd need to communicate, then you would have 
reduced the bandwidth between them to zero, which no one is asserting is 
possible.  If you're not reducing the bandwidth to zero, then I still ask, 
why bother?


>> >Nonsense. As I say above, covert channels and deterministic execution
>> >are different problems.
>>
>> Different problems?  I agree that we need to make the distinction that
>> you're trying to make here, but covert channel analysis that traffics in
>> non-zero bandwidth limits and determinism that gives a bandwidth limit of
>> zero are both attempts to address the covert channel problem.  Did I miss
>> something?
>
>I'm pretty well convinced that I'm missing something here. Listening to this
>argument, my impression is that "covert channel analysis" finds
>unintentional channels, while "determinism" ensures that existing channels
>(whether overt or covert) aren't used. To me, the two concepts appear to be
>complementary - but very distinct.

Maybe we're all agreeing but for terminology again.  Allow me to restate my 
above statement:

covert channel analysis and determinism are different approaches to 
addressing the covert channel problem.


>>[...] In security, except for key
>> size, I generally use the counting sequence "zero, many".  I have yet to
>> hear an argument as to why it's useful to distinguish among some of the
>> numbers above zero.
>
>Given that the real goal of security is risk management, the reason is to
>provide the foundations for computing risk in the face of the channels. E.g,
>if the data that you don't want leaked is a private key of length 4096bits
>and the key is expected to endure for 2 years, then any system with a CoCh
>bandwidth of more than 5.5 bits/day would present too great of a risk.
>(Obviously, the number would be lower since some smaller number of key bits
>would probably reduce the search space sufficiently to work out the key
>sooner, but bear with me:-).

As I said, key size is the exception.  I'll go ahead and include 
cryptohashes, cryptographically-strong random numbers (whether pseudo or 
real), and cyphertexts in this category.  Why?  An uncracked cyphertext is 
statistically random to all tests, and therefore fully incompressible.  
Therefore, we have some basis for assessing risk per bit Bob leaks out to 
Mallet.  Since uncracked cyphertexts usually aren't dangerous to leak, let's 
restrict this part of the discussion to the other crypto cases.  All of these 
are small, ranging from 128 bits to 4096 bits.  Does anyone imagine they can 
achieve bit rates small enough that they'd be willing to hand secret crypto 
bits to Bob? 

As shown on http://www.erights.org/elib/capability/dist-confine.html , don't 
give actual cryptographic bits to entities you fear might try to leak them.  
Instead, give them opaque objects that represent abstract data types over 
the crypto operations you'd like them to perform, where these ADTs can 
encapsulate the cryptographic bits from their clients.  This would actually 
solve a problem, rather than saying "but that's the best that was practical".

As to other kinds of secret bits Bob might try to leak to Mallet, before you 
can do a risk assessment, you have to estimate Bob's ability to compress 
those bits. Bob's ability to compress depends on Mallet's priors.  For 
secrets that matter, we're now reasoning about Mallet's possible knowledge 
of the world, and Mallet's probability distribution functions over his 
ignorance.  If you have this much information about the thinking of your 
adversary, you've probably already won the war.  I'd rather take on 
something easy, like Unified Field Theory or the Turning Test. ;)


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM