[opensuse-buildservice] Verification of OpenPGP keys for OBS repositories (and packages)
Dear List, repository metadata and packages on OBS are OpenPGP signed. That is a good thing in general to prevent malicious packages getting installed in case of server compromisation or a man-in-the-middle attack. However, signatures are only as good as the signing key can be trusted. At the moment after adding a buildservice repository, YaST prompts to accept the corresponding key. How can I verify that this key is genuine? Just blindly accepting the presented key will make the entire use of OpenPGP signatures worthless. If an attacker manages to compromise the server or manages to be the man-in-the-middle, he can just easily put his own key on the server (and I don't have much choice but to accept it blindly). For instance, today the key of the KDE4 community repository appears to have changed. How can I verify that this change is genuine and not the result of an attack? I can think of two possible solutions for this issue: 1) Sign the OBS repository keys with a trusted master key. This master key could become trusted either by being included in the openSUSE distribution or by being offered from a seperate SSL-secured web server. The advantage would be that the user does not have to check fingerprints of repository keys after the master key has been successfully imported. The disadvantage would be that it wouldn't really work for user repositories on OBS, since the level of trustworthiness can't possibly be determined for each and every OBS user. 2) Set up a seperate SSL-secured web server, where key fingerprints are listed for verification purposes. After YaST prompts me to accept a new key, I would then go to this website and check if the key fingerprint matches. The advantage would be that it would be quite easy to implement and that the user can decide which teams/persons he wants to trust. The disadvantage would be that most users would still just blindly import the keys, because they are lazy. :) Personally I prefer 2) for reasons of simplicity and flexibility. Both approaches could also be fit for managing the genuiness of not just repository keys (as outlined above) but also package signing keys (with the exception that package signing keys need to be provided first, since they are not available in the repositories themselves). What I fail to understand: Is package signing only useful when installing packages by hand? Because the repository metadata contains checksums for every package (and these checksums are hopefully checked during software installation), so trusted repository metadata should be enough to prevent the installation of malicious packages. If I am right, the possibility to verify package signing keys would be a nice service for people installing packages by hand, but not necessary for people installing packages from repositories. Regards, Stefan -- OpenPGP encrypted mail strongly preferred (key ID: 952559A9) Homepage: http://www.stefan-tittel.de
Am Mittwoch, 17. Februar 2010 17:28:49 schrieb Stefan Tittel:
Dear List,
repository metadata and packages on OBS are OpenPGP signed. That is a good thing in general to prevent malicious packages getting installed in case of server compromisation or a man-in-the-middle attack.
However, signatures are only as good as the signing key can be trusted. At the moment after adding a buildservice repository, YaST prompts to accept the corresponding key. How can I verify that this key is genuine?
Currently only by checking who owns the project, think about to trust them or not and check if they have signed the public key with their own private gpg keys. Yes, that is not nice and not practicable. There is a project http://en.opensuse.org/Build_Service/Concepts/Trust to improve that. Base work has been done, however currently it stalls due to lack of man power. If someone want to continue on that it would be greatly welcome.
Just blindly accepting the presented key will make the entire use of OpenPGP signatures worthless. If an attacker manages to compromise the server or manages to be the man-in-the-middle, he can just easily put his own key on the server (and I don't have much choice but to accept it blindly).
For instance, today the key of the KDE4 community repository appears to have changed. How can I verify that this change is genuine and not the result of an attack?
Only via checking the people owning KDE:Community. If they publish at a trusted place the new finger prints and you trust this place and these people you should be fine.
I can think of two possible solutions for this issue:
1) Sign the OBS repository keys with a trusted master key. This master key could become trusted either by being included in the openSUSE distribution or by being offered from a seperate SSL-secured web server. The advantage would be that the user does not have to check fingerprints of repository keys after the master key has been successfully imported. The disadvantage would be that it wouldn't really work for user repositories on OBS, since the level of trustworthiness can't possibly be determined for each and every OBS user.
While we can do this (actually it should be the case already, if not it is a bug) this has zero value here. Everybody can create an OBS account and build all kind of packages, good or evil. The server can not check if they contain attack code. All what we can verify is that the binary packages are indeed built by the submitted sources.
2) Set up a seperate SSL-secured web server, where key fingerprints are listed for verification purposes. After YaST prompts me to accept a new key, I would then go to this website and check if the key fingerprint matches. The advantage would be that it would be quite easy to implement and that the user can decide which teams/persons he wants to trust. The disadvantage would be that most users would still just blindly import the keys, because they are lazy. :)
This is more or less (a bit more sophisticated) suggest in the Concept I pasted in the beginning. if someone has some time to work on that it would be great and we can help to some degree. Some code is already existing.
Personally I prefer 2) for reasons of simplicity and flexibility.
Both approaches could also be fit for managing the genuiness of not just repository keys (as outlined above) but also package signing keys (with the exception that package signing keys need to be provided first, since they are not available in the repositories themselves).
What I fail to understand: Is package signing only useful when installing packages by hand? Because the repository metadata contains checksums for every package (and these checksums are hopefully checked during software installation), so trusted repository metadata should be enough to prevent the installation of malicious packages. If I am right, the possibility to verify package signing keys would be a nice service for people installing packages by hand, but not necessary for people installing packages from repositories.
yes, signed repo data should be enough. But you might want to pick an rpm manually and check if this is valid as well (ignoring the repo data). So it is signed as well. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wednesday 17 February 2010 17:48:34 Adrian Schröter wrote:
Yes, that is not nice and not practicable. There is a project
http://en.opensuse.org/Build_Service/Concepts/Trust
to improve that. Base work has been done, however currently it stalls due to lack of man power. If someone want to continue on that it would be greatly welcome.
I really like this concept, but it is probably too elaborate to be implemented in the foreseeable future.
For instance, today the key of the KDE4 community repository appears to have changed. How can I verify that this change is genuine and not the result of an attack? Only via checking the people owning KDE:Community. If they publish at a trusted place the new finger prints and you trust this place and these people you should be fine.
That involves tracking down who is responsible for this repository and if and where the fingerprint of the new key is published and making sure that the publishing location is genuine. I think we agree that this is not very practical.
I can think of two possible solutions for this issue:
1) Sign the OBS repository keys with a trusted master key. [...] While we can do this (actually it should be the case already, if not it is a bug) this has zero value here.
Everybody can create an OBS account and build all kind of packages, good or evil. The server can not check if they contain attack code. All what we can verify is that the binary packages are indeed built by the submitted sources.
I think we have a different understanding of "master key" here. I was thinking about some authority manually verifying and signing the keys of at least the semi-official repositories, so the user can opt to trust that authority instead of verifying the keys of semi-official repositories by himself.
2) Set up a seperate SSL-secured web server, where key fingerprints are listed for verification purposes. [...] This is more or less (a bit more sophisticated) suggest in the Concept I pasted in the beginning.
That's a bit of an understatement. :)
if someone has some time to work on that it would be great and we can help to some degree.
Some code is already existing.
How much? More like 10% of what is needed or more like 80% of what is needed? Personally I would prefer a "do it simple and usuable first, do the sophisticated stuff later" approach. I totally agree that trust is an individual measure being build from a variety of components. However, I also believe that having the most basic components convered soon is better than not having anything soon, but a very flexible system in the distant future (or not at all). Having an SSL-enabled web server listing repositories, fingerprints, the persons responsible for a repository and some information about these persons is easy per se. The big question is: How do people authenticate for updating their fingerprints? The most convenient way would be to use build service login data for updating the fingerprints. Of course this is pretty insecure if build service login data get compromised; build service login data would be a common point of failure. Also (and this is my main complaint) this approch would not identify a build service user as the person he claims to be, but just as the person who has access to the build service account in question. A more secure solution could involve establishing identity by OpenPGP keys or X.509 certificates that have been signed by an accepted CA. X.509 client certificates seem more fit here, because they could be used directly for authentication against the web server. Of course this identity would also need to be established in the build service account, because a) we need a link between web server access and build service access and b) we need to make sure that the actual build service user has a confirmed identity. All that's left now is a way to handle fingerprint updating permissions for repositories which belong to multiple users. And a way to make the web server tell which roles a person has within the openSUSE project (if any), because, for instance, a KDE repository maintained by one of the openSUSE KDE maintainers makes it a lot more trustworthy. All of a sudden my "simple proposal" has gotten a lot more complexity to it than I would wish for, at least in the properly safe variant. Especially the need to aquire a CA-assured X.509 certificate would probably be too much effort for many build service users. Also implementing the necessary logic for the web server and changes to build service authentication infrastructure would mean more than a negligible amount of work. So maybe as a really simple solution we should concentrate on just the semi- official repositories? We could do that either by using a special master key as described earlier or with a fingerprint webserver, where key changes would be propagated by OpenPGP (or S/MIME) signed mails on a mailing list and then updated manually by a small group of persons having write access to the web server. From an engineering perspective manual updating is lame, but really: How often do we have key changes in the semi-official repositories? Maybe I am aiming too low here, but unless somebody declares himself able and willing to dedicate a lot of work into this, just concentrating on the semi- official repositories and doing manual updates in case of key changes seems like something that a) would still improve upon the current situation quite a lot and b) is not a lot of work. Also I'd welcome to hear the thoughts of people thinking about all of this for a longer time than I am. I just started to think about it myself two days ago, so probably I am missing things. :) Regards, Stefan -- OpenPGP encrypted mail strongly preferred (key ID: 952559A9) Homepage: http://www.stefan-tittel.de
Stefan Tittel wrote:
However, signatures are only as good as the signing key can be trusted. At the moment after adding a buildservice repository, YaST prompts to accept the corresponding key. How can I verify that this key is genuine?
There's no good user interface. You could retrieve it from the api though. e.g. for my home project it would be curl https://api.opensuse.org/public/source/home:lnussel/_pubkey
Just blindly accepting the presented key will make the entire use of OpenPGP signatures worthless. If an attacker manages to compromise the server or
While the lack of ways to actually verify the key is annoying I wouldn't call the entire use of signed repos useless. Once the initial step to import the key is passed a MITM or hostile mirror has no way to tamper with repository data or packages anymore.
For instance, today the key of the KDE4 community repository appears to have changed. How can I verify that this change is genuine and not the result of an attack?
What did the error message look like? Does YaST/zypper actually detect that a key has changed and warn that such a sudden change is potentially hostile?
2) Set up a seperate SSL-secured web server, where key fingerprints are listed for verification purposes. After YaST prompts me to accept a new key, I would then go to this website and check if the key fingerprint matches. The advantage would be that it would be quite easy to implement and that the user can decide which teams/persons he wants to trust. The disadvantage would be that most users would still just blindly import the keys, because they are lazy. :)
I'd like to see such a public interface on build.opensuse.org too :-) The more elaborate part is probably to parse the pubkey to display it in a human readable format. I don't know if there are any libraries for doing that.
Both approaches could also be fit for managing the genuiness of not just repository keys (as outlined above) but also package signing keys (with the exception that package signing keys need to be provided first, since they are not available in the repositories themselves).
In OBS the repository key is the project key and a package is signed with the key of the project it comes from. So for OBS one only needs to look at project keys.
What I fail to understand: Is package signing only useful when installing packages by hand? Because the repository metadata contains checksums for every package (and these checksums are hopefully checked during software installation), so trusted repository metadata should be enough to prevent the installation of malicious packages. If I am right, the possibility to verify package signing keys would be a nice service for people installing packages by hand, but not necessary for people installing packages from repositories.
Exactly. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
Adrian Schröter -
Ludwig Nussel -
Stefan Tittel