security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 6:42 PM, Daniel J. Luke wrote:

> On Apr 18, 2011, at 3:11 PM, Jeff Johnson wrote:
>> 
>> On Apr 18, 2011, at 2:40 PM, Daniel J. Luke wrote:
>>> I'm asking about creepy uncle joe's skanky package build system that the local coffee shop network has been set up to make look like it's the product of the official build system.
>> 
>> Creepy uncle joe's skanky build system is detectable with limited RW access
>> to an RFC 3161 (or any other means of getting a trusted time stamp that is
>> trackable). 
> 
> Maybe I'm mis-skimming RFC 3161, but it looks like it would enable you to detect if a package had been modified, but not  verify that a package had been signed by a non-trusted key.
> 

The TSA (Time Stamping Authority) on which RFC 3161 is based takes a hash, adds a timestamp
and signature, and returns a trusted time stamp.

SO essentially you have a paintext hash signed by the TSA and don't need or care
whether the package has also been signed by other private keys. Its the time stamp
being signed by what you call the "non-trusted key" (perhaps the better term is non-repudiable signature)
that is important because the non-repudiable binds the trusted timestamp to
the plaintext.

>> I do suggest looking
>> seriously at one-time keypair generation because it mostly avoids the
>> need to protect the private key: the private key exists for only a short
>> period of time within a given execution context on TOTBS.
> 
> I like the one-time keypair idea, but I guess I don't see the value if you can't verify that the public key is a 'proper' one.
> 

So do something else. The benefit to a non-repudiable signature shcme are:
    1) nothing speshul needs to be done to protect a private key that is discarded.
    2) the infrastructure needed for a trusted timestamp and a registered pubkey
    is way simpler than a full blown "key management" infrastructure.

>>> ie, something outside of the build system that wants to look like it came from it.
>> 
>> SO the security ritual would invllve one of two means (largely identical
>> because a "trusted" 3rd party is involved):
>> 	verify that time stamp in signed package content is/was registered
>> 	verify that pubkey in signed package content is/was registered
>> The increased trust comes from limiting RW access to to the trusted registrar
>> (which is quite simple to cruft up in the TOTBS with certs and firewalls etc).
> 
> ... you have to trust your connection to the trusted 3rd party ... (one reasonable way might be to dist validation info, a public key or whatever, with MacPorts).
> 

well that's rather an oxymoron not trusting a trusted third party because its a network
connection. Find a different "trusted third party" if you don't trust the one you got.

>>> I thought the context here was that we can't trust the network to reliably send us to the official server that contains macports packages.
>> 
>> You have a far broader context. If you want to solve that problem,
>> there's nothing I'm saying that stops you from solving whatever problem
>> you wish to solve.
> 
> OK, so what problem is your suggestion (one-time keypairs) solving? People tampering with the build products after the build system has created them?
> 

The problem that is being solved with RPM is that a non-repudiable signature
can be deployed with almost no infrastructure and scarce resources.

>> Read the model, not the implementation. I'm discussing a mdel, not
>> an implementation, and claiming that binary packaging needs only
>> "origin authentication".
> 
> Isn't 'origin authentication' validating that a package really came from MacPorts (and not from some other place?). That's what you said above is a 'far broader context'.
> 

Yes. And (at least according to the "Handbook of Applied Creepy-Toe" (apolgies to the authors, I don't
doubt what is in section 13.8.2), a non-repudiable signature achieves origin authentication.

Again and again: do domething different if you feel that randomly generated
keypairs aren't the right thing to do.

I do claim that "origin authentication" (not maliciously tampered sudo) is the right problem to solve.

And afaik RFC 3161 time stamps from existing services are relatively painless compared to what is
necessary (with revocations and expiries and key rings and ...) that is needed
for other solutions.

Note that I personally think that exploding what is basically 8b of "time since epoch"
into a ~2Kb RFC 3161 packet makes my head hurt a lot. But that is what is suggested
for a non-repudiable signature to be used for "origin authentication", and really
isn't any worse than any other crypto floating about.

There are other forms of "trusted timestamp" than RFC 3161 as well, try wikipedia.
RFC 3161 is a PKI peculier RFC afaik.

73 de Jeff

> --
> Daniel J. Luke                                                                   
> +========================================================+                        
> | *---------------- dluke at geeklair.net ----------------* |                          
> | *-------------- http://www.geeklair.net -------------* |                          
> +========================================================+                        
> |   Opinions expressed are mine and do not necessarily   |                          
> |          reflect the opinions of my employer.          |                          
> +========================================================+
> 
> 
> 

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