security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 10:11 AM, Arno Hautala wrote:

> On Mon, Apr 18, 2011 at 10:02, Bayard Bell
> <buffer.g.overflow at googlemail.com> wrote:
>> 
>> I think we need to temper how the examples are flying: an evil network operator can do egregious damage, but macports isn't exactly the thing end of the wedge for exploiting the implied level of trust.
> 
> True. Outlandish examples can be saved for extending a system once it exists.
> 
> I think my arguments at this point can boil down to looking at other
> package systems. Why do they bother with signing? Are their issues
> relevant to MacPorts? Are their solutions relevant to MacPorts?
> 

Well since I have a "package manager", and was responsible
for the implementation used by RHEL3 and since, you might
be interested in what is in use by RPM now.

"pubkey distribution" and "keyring management" involves
rational choices by informed end-users. Most end-users
are woefully under-informed and irrational in their "trust"
decisions.

There is a confusion between "branding" and "trust" that is carried by
the "official" signature and "branding" appears (to me) to be the
primary element in end-user "trust" decisions. Using "branding"
isn't necessarily the worst basis for "trust", but its based
on faith: The more you pay, the safer you are.

To ensure integrity/security and to raise the security bar, RPM
is now _ALWAYS_ adding a non-repudiable signature to all built packages.

The model (and threats to the model) of a non-repudiable signature
are described in the "Handbook of Applied Cryptography" section
13.8.2 page 582 which can be read on-line here

	http://www.cacr.math.uwaterloo.ca/hac/about/chap13.pdf

The actual implementation goes something like this:
	a keypair is generated
	just built packages are
		a) include the pubkey
		b) signed with the private key
	and the private key is discarded.

This isn't much different than "self-signed host certs" applied
to software packages.,

So the 
	1) preventing direct access to private keys
in the non-repudiable model above is dealt with by discarding the private key
in "robo-signing".

And either/both of
	2) use of a trusted timestamp agent
	3) use of trusted notary agent
can be arranged by "robo-signing" by implementing RFC 3161 (there are
several services that can/will provide trusted time stamps) or by
registering the public key in a registrar.


73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/2070760a/attachment-0001.bin>