Secrecy and user trust

[Todd Denniston]

Aldo Foot wrote, On 09/04/2008 12:10 PM:
> On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen <davidsen at tmr.com> wrote:
>> Patrick O'Callaghan wrote:
>>> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>>>> hardest of all find a secure way to provide the public part of the
>>>> signing key
>>> The whole point about asymmetric encryption is that you don't need a
>>> secure distribution channel. The worst that can happen is that some fake
>>> public key gets distributed, which won't match the private key and hence
>>> will be instantly detectable.
>>>
>> NAK - if a fake public key were distributed then packages signed with the
>> fake key would be matched, allowing full access to install crap in your
>> machine. And packages signed with any valid redhat key would be rejected.
>>
>> The public key really must be distributed in a secure manner.
> 
> 
> Isn't the point of a Public Key to be publicly distributed?

Only part of the point.
Yes, you can give your Public Key to me, and I can give it to Jim, and Jim can 
give it to Jane, and it is still good for it's purpose, which is to validate 
that the packet of data sent on the net has not been messed with between being 
signed with the private key and arriving at the destination.

But, should Jane be trusting a key given to her by that shady guy Jim to 
install random bits of software?

Now if some time earlier Jane and I had met, and exchanged public keys and she 
felt that my signature was worthy of trust[1], and I had signed your key 
before giving it to Jim, then Jane would have SOME reason to trust that the 
key came from _WHO_ it claims to come from instead of some key that Jim 
generated to do a MITM attack[2].

The underlying thing Bill was getting at with "The public key really must be 
distributed in a secure manner" is security from an INTEGRITY perspective[3].

Unfortunately, currently most of us only have a very tenuous web of trust back 
to any key that that could vouch for the fact that any new key is actually 
from the Fedora crew.  Many folks will trust the key because the old key 
(which has a shadow of doubt over it) will sign it, i.e., they will get it 
with yum and because the old key's sig passes what is on their system it will 
be installed. Some may trust it because they have a substantial web of trust 
to Paul Frields or other Fedora community members who may sign a version of 
the public key. Others may trust it because they trust a person who gives it 
to them and know that person got it physically from a person at the red hat 
building who the second person trusts.

See the suggestion I made a while back[4] for further information about our 
current use of cobwebs of trust.  My suggestion then was not to take care of 
the current situation, it is too late for using it for the current situation, 
but it would make any later situations easier to deal with.  I still think 
Fedora needs a master key made (soon after the current situation is resolved) 
so that we can start building at least a cobweb for it.

> The Private Key is what you closely guard against all tampering.
> 
> ~af
> 

[1] http://en.wikipedia.org/wiki/Web_of_trust

[2] 
http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Example_of_a_successful_MITM_attack_against_public-key_encryption

[3] http://en.wikipedia.org/wiki/Data_integrity

[4] https://www.redhat.com/archives/fedora-list/2008-August/msg03255.html
  {something seems bonkers with the way the html is showing the foot notes at 
the end of the message, as it looks like foot note 2 is referencing 3-7, but 
those seem to have been concatenated onto the same line with foot note 2.}

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter