You'll need to include a key signature in the dialog if it's too have any security advantage at all. Everything else can be forged. Users should be instructed to compare the key fingerprint and IGNORE the other information. Otherwise you may as well get rid of the dialog completely, as it will actually make the security worse

We do include the key sig "BB7576AC", right? Is there any simple way to instruct the user to check the key id for all the repos? Thanks.

That's not a fingerprint; it's just an identifier and is way too short to be cryptographic hash.

A GPG fingerprint looks like:
Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16

(use the --fingerprint option on GPG)

To answer your other question, no, I don't think there's a simple way to instruct the user about the need to verify key signatures to avoid man-in-the-middle style attacks. It's a subtle point and you need to have a deep understanding of the crypto to really understand this. This is probably the single greatest reason why web-of-trust style PKI systems like PKI have failed to catch on.

Something like:
"The fingerprint of the key is: FINGERPRINT. You should verify this is the same as the fingerprint of the provider of the package posted on the provider's web site"

And then of course you can't use the URL from the key since that could be forged too. And of course this assumes that packagers will include the fingerprints of their GPG keys on their web sites in a way that's easy to find.

If you can solve this problem with public key infrastructure, I suggest you start a new company. You can make a lot of money.

Actually, this situation is not bad and I don't think I will be able to make much company around this: we are not flying in the vacuum here, because we know that user had to get livna-repo.rpm from somewhere. So why not text "The fingerprint of the key is: FINGERPRINT. You should verify this is the same as the fingerprint of the provider of the package posted on the web site you get this repo package from."

As I pointed out before, you can only do the "Do you trust XXXX?" if you have a signature from a trusted key that verifies the XXXX.

The bottom line is that you need some trusted keys to bootstrap from, and there's no genuine security until someone sucks it up and solves that problem. Tatil Yerleri

Its here to stop the ‘man in the middle’ attacks - a key logger, for example. Still can’t believe how narrow minded some of you are being.

To really understand why things move, you will have to understand nasty things like metric tensors and the Einstein field equations.

The only thing a "normal user" will understand from this dialog is "click 'yes' to go on". That is the sad thing, but there is no way out of it. What we need to think is, what are we wanting to protect the user from.

In my view, the problem being solved by this dialog is, the user wants to install "XYZ" codec, driver, what ever. He went on to google, or some friend and got a "cake recipe" on how to install what he want. So he followed, but due to some interference an evil hacker he got a package that has a signature the "levilna repository" instead of "livna repository" as expected.

No how can we protect the user from this? This dialog does not help much. Let's suppose that the user has access to the correct fingerprint, this is a large assumption the evil dude was able to convince this user to download and attempt to install the package he could reasonably gave this user the wrong fingerprint also. But well the user has the signature, probably in the site, the best way to be sure that he is checking it is doing our selves the check.

How, simply ask the user to copy and paste the signature into the application. Now I would say that this is very unfriendly, but it has to be done only one time, and there is no way to clickthrough.

I know this is a bit radical, and I probably think that too. But I can see no other way of doing it without it being only security theater. The point is if the user can simply click "yes" and all the complex mambo jambo will simply disappear you bet they will do it.

  Here is what the XML merge tool looks like:     In this simple example one user has hidden a member and the other has expanded a compartment in the same class.

The UI is all in Flash, but the video is in Microsoft format, handled by an extension to QuickTime on the Mac -- why should they go to the work of creating a web version if someone else can redistribute their bits without their consent.

This has the same problem as those "unknown certificate" dialog boxes that web browsers have:

http://mpt.net.nz/archive/2006/02/20/certificates

Or for the really scary shit:

http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf

The dialog box may as well say

"Click YES to install the software that you want so badly. Click NO to close this dialog."

I wonder if it would make sense to somehow leverage the social networks the user already belongs to (via the work Havoc + team is doing). For example if > 25% of all of your buddies running, say, Fedora, have decided to trust Livna (it's probably more) then it's useful information. Maybe this just moves the problem elsewhere. Food for thought.

This is just gibberish. The dialog may as well say "blah blah blah"

To be understandable, it would have to be something like:
Title: "Do you trust Livna.org?"

Content: "You are trying to install software provided by Livna.org.
If you don't trust Livna.org, then click Cancel."

Buttons: [Cancel] [Install from Livna.org]

Don't know about the exact wording, but the point is to make it understandable you must be able to say "from Livna.org" not "has fingerprint [ridiculous hex number]"

Implication: you must have a key from Livna signed by a key you already trust. More specifically the key you already trust should be used to certify that the string "Livna.org" accurately describes the new key.

If you don't have the chain of trust, then the dialog is pure programmer ass-covering bullshit, with no actual security function, because it's simply not possible to make it understandable through any kind of rewording (of course, since it's an interruption, people won't read it even if it is understandable).

Owen makes the good point that for security you want to *get the dialog out of the workflow*. That is, importing a key should not be possible "inline" when you go to install a package. It should be something you have to take explicit action to do.

The reason is that then the task you're doing is "import a key," which means you'll think about the dialog and whether a key should be imported.

If you *interrupt* the task "install a package," people will just always click yes. Any dialog that *interrupts* cannot possibly add much security, because of the way people's brains work - they are thinking about their goal, not the interruption.

All these dialogs do is allow blaming people when they get hacked, they don't genuinely keep people from getting hacked. Presumably the goal is that if I admin a bunch of systems, I'm not fixing viruses on them all the time. That means my goal is *in practice* people aren't getting hacked. It's a small comfort if I can *blame the users* when they get hacked. Maybe satisfying in a way, but not really ideal.

To truly get rid of the dialog, you need to go beyond having a trusted key certify that the new key is correctly named "Livna.org" and have the trusted key also certify that Livna.org is trustworthy. Then you don't need a dialog at all. You would of course need some political process for determining "trustworthy repos according to XYZ," but each distribution and each local site can have their own process and their own "bootstrap keys" that they install. So it isn't really centralized, it's controlled by whoever admins the system. Admins may choose to add root keys from a project like Fedora, or they may only choose to allow repos that they have personally signed with their own site-local key.

If a crappy dialog is unavoidable, do at least make it about 1/3 the amount of text in this mockup... should be maybe two lines total, not five lines of text plus a 5-line mysterious table.

I'm not sure how one verifies a key (see how useless the dialog is, even to programmers?) but if say the way you verify a key is to check that at http://rpm.livna.org you can find the number BB7576AC, you could make the dialog say:
"Does the number BB7576AC appear at http://rpm.livna.org?"
Which at least tells me what to do.

(I just went to rpm.livna.org and can't find anything about their keys, so I guess the above is wrong, but you see the point that it should just tell me what to check and where.)

(But still, the best solution is that there's no dialog if some key I already have has certified the repo I'm adding, indicating that the repo is approved by someone I trust, whether a project or a local admin.)

I fully stand corrected. Havoc, you are right, this dialog shouldn't be shown to Aunt Tilly. Ever. (for exceptions see below)

And apparently I am already too much immersed in the bug fixing and details of incompatible video drivers, that I forgot what I was preaching for a long time myself -- whole GPG/PKI/S/MIME/whatever is not primarily problem of technology, but of social organization (my former sociological me comes to the front). This is the prime example of this.

I think the correct way should go like this. When somebody installs distribution, he could be supposed to trust developers of that distribution to certify any additional repositories as being trustworthy (or he should assure identity of the distributor by other means -- certainly GPG could go here, but that should be special case, not for Aunt Tilly). Therefore, when additional repository provides special distribution key signed by the main distribution key of the main distributor (don't want to be too much Fedora specific, but to be clear -- when Livna provides key by Fedora), then I guess user could reasonably believe that packages from the additional repository are really from there.

Only when some repository which GPG key is not signed by Fedora distribution key (e.g., http://people.freedesktop.org/~hughsient/fedora/utopia.repo) we can deal with the verification of the GPG key at all. Besides, most probably ability to import new unsigned key could (should?) be limited by PolicyKit, so that only true hackers (who are supposedly able to fiddle with PK) could import uncertified repository to the system. But, that would be policy decision by the main distribution.

So, one comment to Havoc.
> Owen makes the good point that for security you want to *get the dialog out of the workflow*. That is, importing a key should not be possible "inline" when you go to install a package. It should be something you have to take explicit action to do.

That's actually how it should look like on Fedora. You have to first install package livna-release.rpm which contains all .repo files for yum (and similar files for apt-get and smart) as well as GPG key for the Livna distribution (/etc/pki/rpm-gpg/RPM-GPG-KEY-livna). Supposedly, during installation of THAT package this dialog would be inflicted upon you in PackageKit. Only then when pirut (or its PackageKit equivalent) is run, the list of packages in the Livna repository is downloaded.

However, it seems to me, that besides "that's not my fault" value, there is not much this dialog adds to already established chain of trust between Livna repository and Fedora.

>ability to import new unsigned key could (should?) be limited by PolicyKit

That was the plan, i.e. doing an auth using PolicyKit so only the admin can do the action.

Richard.

>If you *interrupt* the task "install a package," people will just always click yes.

A signature is required:

Do you trust software from "xvx-online-babes-hot-chixs.org"

[trust] [do not trust]

Now, I know what my answer would be...

People typically look at buttons before reading the text so button should, if possible, make sense out of context. "Yes/No" isn't as useful as "Cancel" and "Trust Software from Linva.org" or something. This also allows you to remove the center-aligned question before the buttons.

Rather than "Software Signature is Required" you could simplify this as "Security Check" or something.

And red/green colours are perceived as a traffic light stop/go, when you don't want the dialog to show a preference to "Yes". I think there are also cultural problems with the meaning of green/red.

Put more space above the buttons.

There's too much text and not enough variation in font size. Use smaller text for the table of data.

Use the Repository Name value as a heading (perhaps a fieldset/legend kind of layout), and remove the "Signature" prefix on every field. Use a tooltip if showing the full name is really necessary.

Rewrite the first two sentences into one. I suggest removing the first sentence entirely... if signatures aren't intended to ensure trusted sources then why are you even asking? You have to trust the signature, that's what the dialog is about -- this just seems like passing the blame for tampering onto the user when really they know as much as you do.

In summary, perhaps something like

-Security Check-
You are about to install software from NAME.
-NAMEs details-
-Address: http://somesite-
-User Identifier: ...-
-Identifier: ...-
-Date: ...-

-cancel- -Trust Software from NAME-

Actually the post above's idea of "Do you trust xxx?" is probably the best title. Ignore my idea.

Trust issues must be matched with a lot of coherent characterstics...i like the idea of the user generated trust rank.

A cross referencing idea that maybe implicated here:
TrustRank

I dont know if my comment is useful.


--
Pur Water Filter

Its counterpart PGP is a canonical example of how to create software which cannot be used by human beings in UI research.

You really want those buttons to say "trust" and "do not trust" or the like. Aside from that though, it's not really your problem; GPG is going to be unusable no matter what you do, so you just have to be as least-bad as the system lets you. You've doing okay with this one.

- Chris

>You really want those buttons to say "trust" and "do not trust"

Good plan.

Canonical example of a useless dialog. Virtually no one has the ability or inclination to make an informed decision here.

Sure, but it covers us legally. If you got this dialog with "xvxx software, free online babes, do you trust this repo", you would probably say no. If you've just installed the livna-release repo and you get this for "livna.org" then it's a pretty sure thing things are okay.

If you are going to do something like this you really should be including any trust information that you do have for the key from the web of trust; as others have said you ideally want to already have trust in the key and not need to prompt at all.

And of course the key point that many many people here seem to be missing here is that the "Do you trust XXX?" question doesn't work _either_ because the XXX is just pulled from the key and the evil hacker can simply put in whatever they want for XXX. In order to be secure the user needs to get the key fingerprint and then manually verify it through some out-of-band channel which itself must be somehow free from MITM and spoofing attacks. (1) No user would actually do that, even if they did understand why they needed to, which is itself unlikely, and (2) Even if they did, there are no channels of communication available which aren't themselves vulnerable to MITM or spoofing!

As I said earlier, this problem is basically impossible to solve, (and if you solve it, call me up, I want to join your startup). The best you can hope for is the CYA dialog. Just don't be under the illusion you're adding any real security.

>because the XXX is just pulled from the key

Yes, ugly. Is there no way we can get the User from the key id? i.e. using gpg to do the lookup.

>Just don't be under the illusion you're adding any real security.

I'm not.

No, the key can be generated in it's entirely by the attacker. Nothing you get from the key can be trusted until the key itself is trusted. You cannot, therefore, use the information from the key in order to verify the key.

It _is_ OK to display that information if they key is already inside the web of trust, but this is extremely unlikely as I have literally never seen anyone actually use the GPG web of trust.

Well, my point was that we can establish our tiny web of trust (consisting just of couple of keys) based on the Fedora distribution key. As somebody said that there is actually no difference between one strongly trusted key in the web of trust and CA. So, in this sense, Fedora distribution would function as a CA for all other repositories which would have their distribution keys signed by Fedora.

And of course the following idea, is why not to throw whole GPG out of the window and not establish full-fledged Fedora Certification Authority. But that's probably too colossal task to do, so let's forget that I've ever said that.

As I pointed out before, you can only do the "Do you trust XXXX?" if you have a signature from a trusted key that verifies the XXXX.

The bottom line is that you need some trusted keys to bootstrap from, and there's no genuine security until someone sucks it up and solves that problem.

If it works to cover you then it's OK. It seems like more of a handshake than anything else - "yes I agree to what I think this involves". It doesn't secure anything, just covers the provider and the user, so from that point of view it makes sense to me to include it.

John.

Hi John - what about if the handshake was somehow recorded - then could that be used defensively if any litigation ensued from the product that was downloaded - sort of legal protection, or does it have to be a more formal process? It's something that is becomming more relevant to me as the variety of domains we host is increasing.

Bob
Rent-a-Website

Tatil Yerleri

Actually the post above's idea of "Do you trust xxx?" is probably the best title. Ignore my idea.