new repository key - how to verify?

why is there no (easy) way to verify a new repository key?

currently, the java repository at Index of /repositories/Java:/packages/openSUSE_11.4 has a new key ‘F7B4039CC2C0E8D4’, and zypper asks me, if i want to continue.

but how on earth can i verify, if this new key is valid?

why can’t i find a page on opensuse.org, where all currently valid keys are listed?

just saying ‘yes’ without verifying makes keys completely useless, and you can get rid of this annoying key verification…

On 2011-10-27 09:46, hemathor wrote:
> why is there no (easy) way to verify a new repository key?

That’s a very good question, for which there is no proper answer,
unfortunately.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Well, someone asked me lately how to check the validity of my key. I told him to compare the ouptut of these 2 commands:

wget -O  - [noparse]http://download.opensuse.org/repositories/home:/please_try_again/openSUSE_11.4/repodata/repomd.xml.key[/noparse] 2>/dev/null

and

for k in $(rpm -qa gpg-pubkey*) ; do
        rpm -qi  $k | grep -q "please_try_again" && rpm -qi $k | sed -n '/BEGIN/,/END/p'
done

However the second command implies that the key has been already imported.

Re: [opensuse-buildservice] Verification of OpenPGP keys for OBS reposit

On 2011-10-27 11:36, please try again wrote:
>
> Well, someone asked me lately how to check the validity of my key. I
> told him to compare the ouptut of these 2 commands:

How about key servers, and having keys signed by peers?

A set of keys could be packaged as an rpm in the DVD, too. And be signed.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Absolutely… But you know that the days here have only 48 hours (because of our 2 suns) and we only work 35 hours … but uninterrupted.
This key was created by OBS. I didn’t really worry about it.

On 2011-10-27 13:06, please try again wrote:
>
> robin_listas;2397825 Wrote:

>> How about key servers, and having keys signed by peers?
>>
>
> Absolutely… But you know that the days here have only 48 hours
> (because of our 2 suns) and we only work 35 hours … but uninterrupted.
>
> This key was created by OBS. I didn’t really worry about it.

I read somewhere that the kernel devs that want access need to have their
key signed by someone that vouches for them. They have taken this measure
after their site was broken into - but it is something that the entire
Linux developing structure should do.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Maybe a related useful question is why/under what conditions does a key change? Should there be some notice somewhere if a key has legitimately changed? Otherwise, as the original poster suggested, people are just going to click OK all the time anyway and the purpose of the signing is defeated… or they’re never going to accept a changed key, and the packaging effort becomes useless if no one trusts it.

On 2011-10-27 21:06, duncreg wrote:
>
> Maybe a related useful question is why/under what conditions does a key
> change?

Keys expire, unless you define them not to.

> Should there be some notice somewhere if a key has legitimately
> changed? Otherwise, as the original poster suggested, people are just
> going to click OK all the time anyway and the purpose of the signing is
> defeated… or they’re never going to accept a changed key, and the
> packaging effort becomes useless if no one trusts it.

Absolutely.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Hi
On the Open Build Service the keys can be extended, but sometimes
people forget :wink:

They need to run;


osc signkey --extend <PROJECT>


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop
up 3 days 5:37, 5 users, load average: 0.27, 0.13, 0.13
GPU GeForce 8600 GTS Silent - Driver Version: 285.05.09

On 2011-10-27 21:48, malcolmlewis wrote:

> Hi
> On the Open Build Service the keys can be extended, but sometimes
> people forget :wink:

The thing is, with the current status, the keys are as good as nothing. The
users have no way to know if the keys are valid when adding a repo, or when
eventually they change. If there is an attack one day, as we are used to
accept the keys with an [enter], we will be damaged. We have no way to
differentiate a normal key change from a genuine attack.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

The thing is, with the current status, the keys are as good as nothing. The
users have no way to know if the keys are valid when adding a repo, or when
eventually they change. If there is an attack one day, as we are used to
accept the keys with an [enter], we will be damaged. We have no way to
differentiate a normal key change from a genuine attack.

I agree. This is the crux of the issue. We should really be thinking about implementing a system to provide assurance that the keys are valid.

Thanks for raising this issue. It is something that has bothered me.

If I want to add a repo, say the packman repo (to mention one example), I am required to accept the keys on blind trust. That seems wrong.

In saying that, I am not questioning whether the packman repo is a good one. I’m happy to accept the good advice of others about that. But how can I know that I am connecting to the correct packman repo? Perhaps some bogus data has been inserted in the DNS servers that I use. The keys will protect against that on future visits, but they won’t protect me during initial use when I add those repos.

On Thu, 27 Oct 2011 22:06:03 +0000, deano ferrari wrote:

> I agree. This is the crux of the issue. We should really be thinking
> about implementing a system to provide assurance that the keys are
> valid.

I think the point of the keys is that one is supposed to compare the key
received by the package manager against the one that’s actually on the
server to ensure that the server is what’s serving up the updates.

IOW, I don’t think it’s about trusting the publisher/package builder, but
about trusting that the repository that’s serving up the packages is the
repository that you intended to update from to ensure a spoofing attack
isn’t taking place.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

But then a hacker can just replace the key that’s on the server, change the packages, sign them with the new key, and before we know it after our next round of updates we’re all suddenly running Ubuntu! :open_mouth:

As I understood it, it was to be sure that no one had tampered with the packages on the server. With an attack like your describing, a hacker could be serving you old, buggy versions of legitimate, signed software or preventing you from seeing new updates, but that’s it (still a problem). A bigger problem is a hacker replacing a file on the server with a malware-infected version and that should be prevented if the private part of the key used to sign the packages remains private - preferably tatooed on the arm of the repository maintainer, or at the bottom of an aquarium tank filled with poisonous chameleons.

Here’s an excellent site that explains the vulnerabilities with Linux package management (and incidentally shows just how awesome zypper is :slight_smile: ). I need to reread it myself to understand what I’m talking about again. :shame:

Attacks on Package Managers

I think the point of the keys is that one is supposed to compare the key
received by the package manager against the one that’s actually on the
server to ensure that the server is what’s serving up the updates.

OK, but isn’t there a possibility that if one is pointed at a corrupt repo say, then the ‘spoof key’ may simply be accepted. The key servers need to be independently hosted somewhere secure, no?

On 2011-10-28 00:22, Jim Henderson wrote:
> On Thu, 27 Oct 2011 22:06:03 +0000, deano ferrari wrote:
>
>> I agree. This is the crux of the issue. We should really be thinking
>> about implementing a system to provide assurance that the keys are
>> valid.
>
> I think the point of the keys is that one is supposed to compare the key
> received by the package manager against the one that’s actually on the
> server to ensure that the server is what’s serving up the updates.
>
> IOW, I don’t think it’s about trusting the publisher/package builder, but
> about trusting that the repository that’s serving up the packages is the
> repository that you intended to update from to ensure a spoofing attack
> isn’t taking place.

Both.

Assume the second case. Then, assume a fake server in the middle attack. It
has a different key; yast says “accept?” We click accept. What else can we do?


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2011-10-28 00:06, nrickert wrote:

> In saying that, I am not questioning whether the packman repo is a good
> one. I’m happy to accept the good advice of others about that. But how
> can I know that I am connecting to the correct packman repo? Perhaps
> some bogus data has been inserted in the DNS servers that I use. The
> keys will protect against that on future visits, but they won’t protect
> me during initial use when I add those repos.

Absolutely.

Even on later connection, they can trick you into believing the key has
changed.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2011-10-28 00:56, deano ferrari wrote:
> The key servers
> need to be independently hosted somewhere secure, no?

Not only that. The keys have to be signed.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On Thu, 27 Oct 2011 22:56:03 +0000, deano ferrari wrote:

>> I think the point of the keys is that one is supposed to compare the
>> key received by the package manager against the one that’s actually on
>> the server to ensure that the server is what’s serving up the updates.
> OK, but isn’t there a possibility that if one is pointed at a corrupt
> repo say, then the ‘spoof key’ may simply be accepted. The key servers
> need to be independently hosted somewhere secure, no?

Sure, and I could see that being an enhancement to the current system.
I’m guessing it’s not intended to be foolproof, but rather just a high
level check to make sure when you connect to the site, you’re connecting
where you intended.

Kinda like having an SSL certificate that validates against a private CA.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On Thu, 27 Oct 2011 22:48:05 +0000, Carlos E. R. wrote:

> On 2011-10-28 00:22, Jim Henderson wrote:
>> On Thu, 27 Oct 2011 22:06:03 +0000, deano ferrari wrote:
>>
>>> I agree. This is the crux of the issue. We should really be thinking
>>> about implementing a system to provide assurance that the keys are
>>> valid.
>>
>> I think the point of the keys is that one is supposed to compare the
>> key received by the package manager against the one that’s actually on
>> the server to ensure that the server is what’s serving up the updates.
>>
>> IOW, I don’t think it’s about trusting the publisher/package builder,
>> but about trusting that the repository that’s serving up the packages
>> is the repository that you intended to update from to ensure a spoofing
>> attack isn’t taking place.
>
> Both.
>
> Assume the second case. Then, assume a fake server in the middle attack.
> It has a different key; yast says “accept?” We click accept. What else
> can we do?

It would help to have retrieved the keys from a known trusted server
ahead of time.

I certainly agree it could be better implemented.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C