I sent a mail about this to the internal Launchpad list on 8 February, but there's no reason for it to be private, so I'm copying it here.


I understand that this is the most immediately straightforward solution [ed: single key for all PPAs], and I'd like to have PPAs be signed too. I'd love to be able to say "go ahead and we'll fix it later". In fact, I'm not sure it's clearly the distro team's call, as we only have a tenuous ownership of PPAs. However, I do have a serious concern with this approach, which I think I can demonstrate quite easily. (This is based on a conversation I had with Celso on IRC today.)


The only real cryptographic purpose of a single-key-for-all-PPAs signature, as far as I can think of, is to guard against DNS poisoning attacks. It clearly doesn't authenticate the uploader; it just says "this came from ppa.launchpad.net". Since that has no value in itself as to a first approximation anyone can upload to a PPA, the only thing that that says in turn is that your connection to ppa.launchpad.net was not intercepted, for example by somebody who has managed to take over your local DNS server and can cause the system of their choice to claim to be ppa.launchpad.net.

The problem is that a single-key-based signature scheme doesn't actually prevent this attack at all. All you need to do to attack this system is
to sign up for a PPA yourself, and then you can upload whatever you like (provided that it is a well-formed package) and have ppa.launchpad.net sign it for you. Now you have a repository you can simply download and substitute for the one that your victim requested, and all the signatures will pass.

The usual terminology for this is that ppa.launchpad.net is allowing itself to be used as an oracle for people trying to mount chosen-message attacks. This is not generally a good idea if you can avoid it.

The result of all this is that you have a system that *looks* fairly secure to an ordinary user, in that there are signatures on every step which all pass and which can be verified automatically by apt after a small amount of initial setup, but which is actually trivial to circumvent. I think this is worse than having no key at all.

I also have some concerns that exposing a cryptosystem to a chosen-message attack might make it much easier for an attacker to either factorise the key or come up with at least a selective forgery attack (the ability to produce a signature on the message of your choice). I'm not familiar with the state of the art here, but it should be a concern. It's always better to avoid opening this door if possible.

Finally, once we deploy a key signature scheme, we need to consider migration. I think it will be more difficult to migrate to a better scheme when the flaws in this one are publicly demonstrated, because at that point there will be the additional consideration that you're breaking users who are already using those PPAs.


With regard to per-PPA keys, Celso raised a concern that storing the per-PPA private key blobs in the Launchpad database would be a security concern. I agree. The standard fix for this is to "wrap" (i.e. encrypt) each key using a "key-encryption key" (KEK) owned by whatever entity is authorised to make signatures using the per-PPA private keys. When signing the Release files at publication time, the publisher would extract the key, decrypt it using the KEK, import it into a temporary keyring, sign the Release file, and then throw away the temporary keyring.

There is quite a bit of literature on this subject. Wikipedia seems to be a reasonable starting point:

  http://en.wikipedia.org/wiki/Key_Wrap

Provided you choose a reasonable implementation, this should be at least as secure as the scheme above, and probably much better. Obviously the KEK must live only on the ppa.launchpad.net filesystem and backups, and on wherever is responsible for generating per-PPA keys if you choose a symmetric scheme, but those are basically the same conditions as you'd need to apply to the private key in a single-key scheme anyway.

But, if all of that is too much work, then just make the entries in the database be some kind of unique references that the PPA publisher can look up on its filesystem, or similar.