security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 10:35 AM, Jeff Johnson wrote:

> 
> 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.
> 

Now for the "constructive" points relavtive to MacPorts and Mac OS X.

A non-repudiable signature as above added to a package delivery
service is what Jordan has been saying all along.

A UUIDv4 (a random nonce) is bound to files in a "package" through
an executable signature from a "trusted notary agent" (i.e. whetever
pubkey registration scheme the build system chooses to use).

The UUDv4 splits the identification from the integrity checking (in
the scheme I outlined the pubkey fingerprint is the de facto "identifier")

Note no "key management" or "delegated trust" through signing by
developers or other "central authority" other than what the build system
chooses to use, thereby simplifying the needed deployment.

And its the "build system" not the upstream sources nor the "branding"
that is the appropriate place to "trust". The build system isn't
responsible for other factors such as tampered upstream sources or
anything that happens prior to the build starting. The added non-repudiable
signature secures the contents going "forward", not "backward", in time.

73 de Jeff
> 
> 73 de Jeff_______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

-------------- 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/50ce864c/attachment.bin>