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@xxxxxxxxxx> 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}