security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 1:15 PM, Arno Hautala wrote:

> 
>> There are no XSS threats in most cases for "package management"
>> because the delivery is usually from static content on mirrors,
>> not from some dynamic store. Even if "packages" are delivered from
>> a "web server" the attack is against the server, not the
>> sausages delivered by the server. The sausages (in the scheme I described)
>> WILL continue to have a public key and a signature that can be verified
>> no matter what other exploits there are. So I'm not sure the analogy
>> to a "web server" is meaningful or useful to "package management".
> 
> I didn't bring XSS or anything else in to the picture.

You did bring up "web servers" and XSS is a commonly known threat
on "web servers" that doesn't apply to "package management". I'm
merely illustration the difference.

> You mentioned "self-signed host certs" as an analogy for the RPM
> signing method. I took, and still take, this as an analogy to self
> signed certificates as used by SSL for a web server. I was pointing
> out that single use key pairs were less useful than a self signed web
> cert because at least the web cert would be reused from day to day and
> convey some sense of identity between visits.
> 

The analogy to "self signed certs" starts to break down because
the generated keypair is used exactly once and never again. That
too is an added benefit because you don't need to do anything
particularly speshul to protect a keypair that is used exactly once
in a non-repudiable signature model used for origin authentication
(other ways to make a non-repudiable signature more secure are
listed in the "Handbook of Applied Cryptograpy" reference I gave.

> If the RPM single use key pairs are actually signed by another
> authority, that analogy breaks down.
> 

There's nothing preventing the non-repudiable signature from being
signed by any/all of the public keys currently resident in SKS
keyservers.: the rsultant binary packages will be a bit fat and
verifying all the binding signatures will take more time than the
install will take. I see very little additional benefit to having
additional "trust" signatures on a one-time use of a generated
keypair that is indeed discarded. But you could in fact gunk up
a non-repudiable signature with whatever else one deems necessary.

> Did you have something else in mind in mentioning "self-signed host
> certs" that I'm still misunderstanding?
> 

See above.

>>>> Not even close to the point if you think more bits in a hash
>>>> is more "secure".
>>> 
>>> It's at least part of the goal (re: larger hash space, lower chance of
>>> collision).
>> 
>> I do not read your thoughts. Say what you mean as precisely as possible.
> 
> I mean that a longer hash probably isn't longer just for the sake of
> being harder to type.

There are many attacks on signature schemes, the probability
of collision isn't the only criteria, nor is number of bits always
more secure (but yes more bits == less probability of collision in
most cases).

But if you're interested in avoiding collisions, then use a HMAC
as the sigest to be signed, that adds far more security than
adding more bits.

> It's using more bits in order to increase the range of hash values. If
> the hash is implemented correctly, this means accidental collisions
> are less likely than they are in a shorter hash.
> 

Not exatly, but more or less correct.

> In other words, an 8 bit hash can securely verify the alphabet, but
> will start running into collisions when you start hashing phone
> numbers. MD5 should be fine for either, but starts to break down when
> you use it for documents.
> 

FYI: RPM carries >100 hashes, and HMAC's, any of which can be used
as needs change. I'm so so so tired of being told
	MD5 is insecure!

>>>> A trusted 3rd party registrar for pubkeys as well as including the pubkey
>>>> in signed content (to avoid DoS attacks preventing pubkey retrieval) is
>>>> the basis for the "trust".
>>> 
>>> I fail to see how trust is achieved from using single use key pairs.
>>> Also, you hadn't previously mention anything about a 3rd party
>>> registrar. If the single use keys are also signed by that 3rd party,
>>> you're back to the issue of who to trust.
>> 
>> I'm not responsible for your, or anyone else's, opinion of
>> how trust is achieved. I have described a mechansim only.
>> Don't do that if you don't "trust" what is implemented in RPM.
> 
> I never asked you to be responsible for my opinion. And no one ever
> asked you to be the one to implement the features that are being
> discussed here. This isn't a place where you're expected to implement
> or shut up.

Lest we drift off into "violent agreement", I am in fact attempting
to suggest a "origin authentication" model for MacPorts, not anything else.

> You offered an example of what RPM does. I can see some merit to what
> they do, but there are also some decisions that are questionable or of
> dubious benefit. I'm discussing those.

So discuss. If you like/want a "central authority", then someone
needs to step up to the plate and offer to do that infrastructure
deployment and signing.

If there's no interest in that thankless "central authority" model, then
non-repudiable signatures and "robo-signing" might be substituted.

> And I don't need you to defend RPM, I understand that it's just one
> system, with one set of goals, and one set of decisions. It might not
> be perfect for MacPorts, or it may just not be perfect for me. Either
> way, it's an interesting case to look at and has contributed to the
> discussion.
> 

Good. By George, I think he's got it!

>>> These are critiques of the system as presented to be in use by RedHat
>>> and how that might direct MacPorts.
>> 
>> Again, I have _NOT_ been associated with Red Hat for years, and I
>> described what is implemented in RPM, not what Red Hat does:
>>        Pay more for increased security.
>> based on faith is one of you available "trust" choices always.
> 
> That was meant to be a disclaimer to reiterate that I was discussing
> the system as presented. I was stating that I understood that the
> person who presented the system didn't necessarily need to defend it.
> 
>>> Personally, for trusting the build system, I'm leaning towards
>>> supporting a system that robo-signs packages as they're built.
>> 
>> What do you think I just described if not a system that "rob-signs"
>> packages as they are built, exactly what Jordan has said.
> 
> It's what you might call "conceding the point".
> I still have reservations about how RPM is doing things:
> What's the point of using a single-use key pair over a hash?
> Why bother with a 3rd party notarizer? (If they are doing so.)
> 

Digital signatures with appendix _ALWAYS_ sign a hash. See section
11.2.1 "Basic definitions" in the "Handbook of Applied Cryptography".

> Overall, robo-signing is probably the best solution.
> 

Good. We are in "violent agreement", nothing more. The "central authority"
model is equally feasible, but there have been no volunteers to take on
that responsibility (smart guys imho, it is a thankless chore perfroming
the appropriate security rituals).


> I also don't think it's what Jordan was describing. That seems to be
> regarding controlling package impact within a chroot. You don't
> necessarily have to trust the source of the package if the contents
> can't do anything to your system.
> 

Jorndan is describing a means of "origin authentication". The dteails,
but not the intent of the security model, do indeed differ.

> Robo-signing says you can trust the generation and content of the
> package. The function of the contents still might not be safe if the
> original source has been compromised, but you at least know that a few
> more legs in the process are secure.
> 

No. Robo-signing means you can trust the origin and sez nothing
about whether you can trust the content. For binary package
distribution ist the origin, not the content, that needs to be trusted.

> A side note here is that packages could be additionally signed by
> developers who HAVE performed the code auditing. If you trust those
> developers you may have a bit more trust in the content of the
> package.
> 

Nothing in "robo-signing" precludes other signatures, or other forms
of developing "trust". Go ahead and run your builds with clang static
analysis, where you WILL find exactly what FreeBSD has found, that 3Gb
of clang spewage simply cannot be processed with finite resources.
Whether the audits are done automatically or manually, and how the
audit is validated have little to do with binary package distribution
and non-repudiable signatures for origin authentication.

By all means do whatever else is deemed necessary to secure "trust".

>>> It might be nice to track ports back to their submitters with key
>>> signing, but it's probably more trouble than it's worth right now. And
>>> there's still the VCS history and Trac.
>> 
>> Binary "package management" (and by inference projects
>> like MacPorts) cannot be responsible for all possible exploits.
>> That simply isn't feasible.
> 
> I never said it was. That doesn't mean they shouldn't try to handle
> the exploits that are within their reach.
> 

See above.

>>> A leaked robo-key can always be revoked and nothing in effective
>>> security is ever ideal.
>> 
>> And a generated keypair with the private key discarded and
>> the public key registered with time stamp differs ... how?
> 
> Why should I trust a single use key pair? I'd have to verify the
> identify of every single key independently. Unless it is also signed
> by a parent key that has greater longevity and can be individually
> verified? At which point, why bother with the single use key in the
> first place? You could just use the one parent key and nothing has
> been lost.
> 

See the model. A registered pubkey and a trusted time stamp are the
means to make a non-repudiable signature more secure.

>>> Even PGP key signing could be improved by tracing DNA back to most
>>> recent common ancestor.
>> 
>> Improved how? [...]
> 
> It was a joke.
> 

;-) I do -- unlike most security trolls -- have a healthy sense of humor.

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