warning to list

[Alexandre Oliva]

Rats, I promised to step out of the debate, but there are questions
directly addressed at me, so I'll have to step back in and answer
them.

On Oct 29, 2004, Nils Philippsen <nphilipp at redhat.com> wrote:

> For Rawhide, all we (that is some people including me) want to have
> is that the packages that originate in the Red Hat build system are
> signed with a short-lived key that we can be sure that the package
> is in fact the one piped through the build system. This can be made
> part of the pushing step in the process.

This is a very interesting idea.  What if we generated a key as part
of the pushing process, and signed all packages without a signature
using such a key?  We'd then publish that key somewhere in the rawhide
repository itself, such that people could refer to it directly from
download.fedora.redhat.com (i.e., not potentially-corrupted mirrors)
and, at some point of the day (hopefully not too long after the push
is completed), one of the key holders would sign that key with the
rawhide key (while at the same time signing the packages that didn't
get a signature in time for the previous push, such that they get a
stronger signature next day).

This means people might have to grab and verify a new set of keys
everyday, but this would be relatively easy to automate, and would get
people to at least think a little bit about what they're doing.  If
such keys could be downloaded from some https server whose encrypted
sessions can be verified by a Red Hat certificate (as if people would
check the certificate :-), even better, but then, we'd have security
issues securely getting the keys into the secure https server as well.

> I don't know whether pushing the packages happens manually (in which
> case it would be only very few people how could initiate it, right?) or
> whether it happens per cron job.

The latter.

> in the second you could -- for the sake of the security of the key --
> make the signing part a separate daemon.

See, that's a hole into the box holding the signing key.  Not a good
idea, no matter how secure you may think such a daemon is.

Another way to do it would be to have such a box generate the
rawhide-daily key at a specific time of the day and store it in a
location the rawhide push machinery would then be able to use.

It's still a problem that, in order to sign such a key with any of the
trusted keys, you'd need a process running holding the passphrase for
the trusted key, and with access to the key protected by the
passphrase.

> No. See above. Or in different terms: Even a signed package in FC final
> or update, RHEL final or update or whatever doesn't tell me more than
> that this particular package has been piped through the Red Hat build
> system.

Not true.  All it tells you is that it was signed with the
corresponding Red Hat signing key.  It's up to the key bearers to
ensure that the key is only used to sign packages that went through
the build system and, the more the key is exposed, the more it is
likely that someone will be able to attach a signature to a package
that didn't go through the build system.

> No, because the build system wouldn't have the keys.

If the build system or the automated pushing system has any way to
automatically get packages signed, then such a signing key is
dangerously exposed.

>> Who's forcing anyone to trust unsigned packages?

>> I haven't signed this message.  Am I forcing anyone to read it?  I
>> don't think so.

> That is not the question. This mail isn't signed as well because it
> doesn't really matter whether it's really me who wrote it, I hope the
> arguments count more than the person who's written them ;-).

Signed or not, you weren't forced to read it, and that was the point.

The fact that Red Hat publishes the packages, signed or not, doesn't
mean anyone is forced to use them.

> Exactly :-). Please show me whether there are any flaws in what I've
> outlined above.

The flaw is that signing something means access to the key.  The more
exposure a key gets, the less trustworthy it is.  No matter how many
levels of indirection and perceived security you place between the
build system and the signing system, if a signing session can be
initiated by the build system, it means the build system has access to
the keys, and this is bad by all accounts.

The one interesting idea that sprouted out is that of using a
short-lived key.  One that will start-out untrusted, for not being
signed (otherwise the rawhide push system would get access to the
important key, which it shouldn't), but that will get a signature as
soon as the other packages are signed.

Alternatively, we could have such signed, short-lived keys be
generated and signed by one of the key holders say daily (or every
time they sign packages), and installed in some location that will
grant the build and the pushing system the ability to sign packages,
such that, in the absence of a stronger signature, they could attach
this insecure signature to the packages before they make to the
rawhide repository.

>> Failing that, I'd be more than willing to live with a signed-rawhide
>> repository, that we could build the way I described in a previous
>> posting.

> At the point you (or an automated system) can sign package repository
> data, you (or it) can also sign the contained packages.

Yes, but the repository information could be signed by an actual
person, as opposed to the automated push, after mirrors have started
picking up the package content.

> Monitoring the repos for corrupt packages is reactive security which is
> nice to have but not the only thing I would want to rely on.

Agreed.

>> If any single mirror is corrupted, it's too late for people who got a
>> package from there and didn't check it before installing.  Yes,
>> checking is a pain.

> I'm sorry, but I'd say checking that a binary package which isn't signed
> at all (i.e. I can't know that it really comes from the original source)
> doesn't contain malicious changes is a bit too much to expect from
> people who aren't compiler engineers and eat assembler for
> breakfast ;-)

I was more talking about checking md5sums with some published, secure
list than actually extracting the contents and verifying them.

> When issuing announcements I used to sign them with my key, but
> ceased to do it because of the hassle when I wrote the email on a
> remote system while I have the key only locally (i.e. on a USB
> stick). I'm regularly thinking about how to avoid this without
> compromising the security of the key, but to no avail yet.

I don't think you can.  In order to sign something, you have to have
the content to be signed and the key available to the same machine,
because the signature is the result of a computation involving both.


Ok, not really; it's a hash computed from the key and the data, so, if
you can compute them separately, you could send the hash of the data
towards the host holding the key, have it compute the signature and
send it back, but you have to do so in such a way that you have little
risk of ending up with your signature attached to something other than
what you meant to sign.  Consider, for example, that a
man-in-the-middle or someone with privileged access to the signing
host could modify the hash sent to you for signing, and eavesdrop the
signature for such a hash, as means to get your signature attached to
some data they chose.

Another way to do it is to have a one-time key pair generated and
signed with your key, sent to the location where the data is, and used
to sign the data there.  Anyone holding your public key can then
verify that you signed the (public) key that goes with the signed
data, and then verify that the key was used to sign the data, but
there's always potential for such a key to be used to sign other
pieces of data you didn't mean to sign, if a man-in-the-middle or
someone with privileged access to the signing host manages to gain
access to the one-time key pair.

So it's only really secure if the data and the key are on the same
secure host.

>> backdoor into everybody's machines: any Red Hat developer can build a
>> package that makes to rawhide and, next day, he'll have an army of
>> zombies ready to launch his DoS attack against www.mycrosoft.com.  Too
>> bad there's a typo in the site name ;-)

> That is the same for non-Rawhide packages ;-).

Sshhh!  No one outside the company was supposed to know that ;-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}