[haiku-development] Re: Design for signed packages
- From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 26 Mar 2014 04:23:39 +0100
Am 25.03.2014 um 23:09 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
> It restricts us to a single algorithm.
Not really, as we could just increase the hpkg version to change the version.
Or do you want to use multiple algorithms at the same time so that an attacker
can chose the algorithm he can break the easiest? ;)
>> I'm trying to introduce as
>> little complexity as possible, because complexity is what makes every
>> crypto system fail eventually.
>
> Yeah, the length field adds enormous complexity. ;-)
You're not done with the length field. You need a signature type field. You
need to implement different algorithms, etc.
> Let's be realistic. Your suggestion places a tremendous burden on the user
> who would like the added security. Actually usually not just a burden, but an
> impossible task. See below.
Well, it would at least help not having remote code execution as root by
default ;).
> Yes, it is complex. And there's a library implementing it all already. And if
> I have seen it correctly, you've already stared using that library. I suppose
> some security guru has something to say about brewing your own security
> solution because you consider a standard (proven) one too
> complex/slow/insecure.
OpenSSL does not work in the kernel-space / bootloader. All we'd need to swap
is the SHA-512 implementation, which is an easy task. For now I'm just using
OpenSSL as we don't need / want it in the loader yet.
This is not brewing your own security solution as we use an available one:
Ed25519. Designed exactly for cases like this: Implement signing of messages
and making it as hard as possible to do it wrong.
>>> As written above, it is also practically useless, since most users
>>> will just accept the certificate without actually checking
>>> anything. Even if a fingerprint was shown, all the user could do is
>>> surf to the website of the supposed signer and compare the
>>> fingerprint. If that's where the package came from as well, a
>>> matching fingerprint means exactly nothing.
>>
>> He can verify with others etc.
>
> Please do expand on that. You find a package on a website and you
> call/mail/chat with others who are supposed to tell you what exactly? That
> they see the same signature? That they have installed the package already and
> it hasn't eaten their HD (yet)? That they live next to the signer, consider
> him a nice chap, and just went over to verify the fingerprint? Seriously?
No, but you can get the fingerprint by other secure channels. Multiple
possibilies:
* Publish the key via HTTPS
* Publish the key and sign it with PGP
* Exchange it via telephone
* In fact, get it via *any* other independent channel, so that an attacker
would need to control both channels
* I'm sure there are more I just can't think of now
> Well, that's a somewhat complicated topic and there are several aspects.
>
> First of all, just to get that out of the way, the SSL design is pretty
> broken. My browser comes with over 100 root certificates of CAs which I
> mostly don't know and don't really trust any farther than I can throw them
> (not even talking about that fact that many use a signing algorithm which is
> known to be broken). And yet, I (respectively my browser) automatically
> trust(s) any certificate chain anchored by one of those certificates.
>
> I actually do find Firefox' implementation useful. If I get a certificate
> warning, I do very carefully consider how to proceed. If it is just some
> forum site I found via google that uses HTTPS with a self-signed certificate,
> I might proceed or cancel depending on how interested in the content I am and
> which OS I'm using. If I get a warning for anything more critical I usually
> cancel outright.
>
> In contrast, when I get the warning you suggest for the signature check, I
> don't have and cannot realistically obtain any information that can help me
> with the decision making (at least I don't see how). IOW, it is useless.
>
> If, as I suggest, the certificate is signed, I do at least know that the
> signing entity has verified the authenticity of the signer. I can base a
> decision on that.
Well, you said it yourself: The advantage you have is that you know that
somebody who you don't trust trusts the signature. Is that really worth it? ;)
I think the problem you have is with the UI I proposed - which was only a rough
idea anyway. We could have a Firefox-like dialog. We could show the users
suggestion of what to do (e.g. look if they have a TLS-secured website, look if
they have published their fingerprint and signed that somehow, look if it's
printed on a CD or whatever). Having the possibility to see that somebody who
you don't trust trust it doesn't really mean anything.
> I'm not exactly convinced of the benefit of supporting Secure Boot. In fact
> I'm leaning toward not doing that ATM, as it appears to be a lot of work to
> get a significant benefit.
I never proposed to do that now, just to have a package signing system that
lets us keep that possibility.
--
Jonathan
Other related posts:
