Re: Certificate proposal

[Hal <hfinney@shell.portal.com>]

m5@dev.tivoli.com (Mike McNally) writes:
>I'm a little confused, I guess.  What is it about certificates that
>you'll trust with such confidence?  How do you know that the guarantor
>of a certificate wasn't spoofed by an MITM attack?  How do you know
>that the certificate itself wasn't spoofed?

I believe that the certificate wasn't spoofed by an MITM attack because 
the certificate issuing process requires face to face contact with some
proof of identity, in at least one way of doing this.  The certificate
wasn't spoofed because I got the key of the signer through an out of band
mechanism, such as seeing it printed in the newspaper.

The main requirement is to have some contact between Alice and the rest
of the world which doesn't go through the MITM, and the same for Bob.  By
using certificates, this contact only has to be done once (for each of
them).  There is no need for Alice and Bob themselves to have a face to
face meeting, nor for Alice and Charlie, Alice and Dave, Bob and Charlie,
Bob and Dave, Dave and Charlie, etc.  Just the one will suffice.

>I think it's more correct to say that the MITM attack is acknowledged
>to be possible, but realistically no more of a threat than in a
>certificate model.   And note the "I think", and this warning that I
>could be wrong.  (Or I could be an MITM...  bwahahahaha!)

I'm not sure whether this is because you think MITM is so difficult as
to be almost impossible in any model, or whether you think that an MITM
attack is possible in some cases against relatively naive users, but that
certificates won't help at all in that case.

Let me make clear how I would see a MITM attack working.  There are two
main flavors, the permanent and the transitory.  Here is how the
permanent MITM could work.

Alice's ISP provides all of her email services.  She has created and
published a public key, but the ISP has detected this and replaced it
with a fake key.  Everyone who tries to send to her using that key gets
their message decrypted and read by the ISP, then re-encrypted using
Alice's real key and delivered to her mailbox.  This much would be
relatively easy.

But it is not enough.  If Alice gets hold of a good key for Bob, she will
send messages to him using that key.  The ISP can't read those messages.
If she signs them, Bob will notice that the signature doesn't check
against his copy of Alice's key (the one which the ISP has installed in
place of Alice's real one), and the ISP will be caught.

Therefore the ISP is going to have to make sure that every single key
Alice gets is a fake one, one for which the ISP has the secret key.
When Alice get's Bob's key, Charlie's, everybody's, the ISP has to
replace those with fake versions.  Then again it can do its
translate-and-replace trick on messages going in both directions.  This
is obviously a much more difficult task, but if people acquire keys in
limited, stereotyped and automated ways, it could conceivably be done.

With this, what more could trip the MITM up?  Well, if anybody ever
included any keys within the body of a message, those would have to be
detected and substituted.  Even key fragments might have to be handled,
although it is unlikely that this would be noticed.

The biggest threat would be if Alice used a different method to get
someone's keys, her own or anybody's that she communicates with.  She
could use a different ISP or use some "out of band" (off-net) method.
If she went to a key signing party the jig would be up.

Does this mean that the MITM attack is impossible?  Not necessarily.
I'll bet there are plenty of people who only use one ISP (AOL or MSN)
and who have never been to a key signing party.  Maybe they've never
even met someone in real life whom they communicate with on the net.  A
lot of people could fall into this category.

This is where the certificate comes in handy.  A certificated key from a
signer whose key Alice is able to verify out of band will not be
forgeable by the MITM.  Likewise if Alice's key distributed on the nets
is signed by a trusted certificator then other people can have confidence
that there is no MITM involved.  Basically the certificate is a way of
forcing people, at least once, to go around their ISP.  And once is
enough.

Now let me describe the other form of MITM attack, the transitory one.
In this one the attacker doesn't care if he's caught, he just wants to
peek at a few (possibly crucial) messages.  Here again his attack is to
replace Alice's public key in the databases with a bogus one, and to
intercept her communications.  Or maybe he is attacking SSL or some
other protocol where one side sends their public key to the other.
Then it is even easier to send a fake one.  People who trust and use
that key will lose their privacy.

This attack is obviously a lot easier to mount in some contexts.
Again, the use of a certificate should prevent these, and in fact SSL
does use certificated keys.  The MITM will not be able to supply a
certificated key with the name/address information for Alice.
(Netscape currently doesn't check to see whether the name in the key is
valid, so it is not getting much benefit from the use of certificates.
I hope it is clear that abandoning certificates or using ones without
any name or address information would make SSL very unsafe.)

>Oh now wait a sec here; I don't think anybody's advocated using
>"untested" keys.  It's still perfectly reasonable to establish
>networks of reliable information focused on a key.

>If I electronically "encounter" Alice and decide to begin a secure
>conversation, we initiate a key exchange.  I can then go to as many
>already-trusted entities as I like in an attempt to verify that as
>many attributes that are claimed to be associated with the key are
>really there as I desire.  If Alice wants to buy a widget from me, I
>can ask other businesses whether they've ever had problems collecting
>from that key.  If I want to buy a widget from Alice, I can ask
>friends whether they've gotten good widget from that key.  If I'm
>interested in a little e-hanky-panky, I can ask around the sleazier
>corners of the net to see whether Alice is the kiss-and-post type.

What if you just want to talk to her securely?  I asked before what
"attributes" would handle that case, and the answer that at least Tim
gave was that talking to the key is talking to Alice.  I don't buy
that, at least not yet.

(Don't get me wrong - I don't have anything against attributes.  I love
Chaum's pseudonymous credentials.  I'm just worried that unless we have a
foundation of secure communication that the rest of the edifice isn't
going to stand.)

>Somebody's going to have to explain to my thick skull how it is that a
>certificate system makes this process any different, fundamentally.  I
>mean, it may be that there's more superficial security, but I don't
>see where there's any additional risk truly introduced by using the
>key itself as a "True Name".  Maybe the real question is, how does a
>certificate system give me the confidence that there really is an
>"Alice" according to some definition of "really" that satisfies me?

OK, I wrote at length above on how certificates can help against two
forms of MITM attacks.  What do you think?  Maybe it is hard to imagine
a long-term successful MITM attack, but wouldn't you feel uncomfortable
with an SSL which used uncertificated keys?

Hal