Re: bootstrapping a secure channel

From: Allen Pulsifer (amicrypt_at_amishare.com)
Date: 08/10/04 

Date: Mon, 09 Aug 2004 21:04:34 -0400

Michael Scott wrote:
> 2. Using any PK method they behave as if their public keys were in fact
> authenticated, and do a key exchange to agree a random 128-bit key K
>
> 3. One phones the other (via an "authenticated channel") and they swap short
> one-way hashes of their mutually agreed secret key K - the one they are
> going to bootstrap into. These should be the same. Say the hash is in hex
> AC78 098B1 CD15 EF98.
>
> 4. Now Alice is satisfied that the secret key she has is the same as the one
> Bob has, and visa versa.

An attacker might be able to first do a key exchange with Alice, then do
a key exchange with Bob, and in the process, force the mutually agreed
secrets, or the hashes of the mutually agreed secrets, to be the same.
Without specifying how the secret is negotiated, its not possible to
tell what probability this attack would have of succeeding.

This also has the effect of reducing the security of the channel to the
security of the hash, and opens up the 128-bit key to an offline brute
force attack. These are two things we wanted to avoid.

Are you aware of a paper that analyzes the security of this method?

> BTW I thought in your original protocol that Bob and Alice would make up
> different public keys for themselves every time.. why use the same ones over
> again? They are unauthenticated anyway...

Alice and Bob can use a new public key pair every time, or they can
reuse the same key pair. It makes no difference to the security of the
authentication. (I can't find where it says anything different in the
paper, but if it does that's not correct. Please let me know where it
is and I'll fix it.)

On the other hand, if they computed a new key pair every time someone
tried to execute the protocol with them, they would be vulnerable to a
denial of service attack. This is why in practice it makes sense to use
the same key pair for at least some period of time, so they don't have
to repeatedly do the work of deriving a new key pair.

> I think the reason that you have not come across protocols like these before
> is that you have been looking in the wrong place. Check out the literature
> on secure phones.

That's possible. We haven't looked at any literature on secure phones.
  Thank you for the pointer.

Best Regards,

Allen Pulsifer

Relevant Pages

  • AT_SIGNATURE and AT_KEYEXCHANGE
    ... signature and a key pair for key exchange. ... From my testing, it seems that when a smart card based CSP is used, I can ... use a key pair marked as AT_KEYEXCHANGE to do signature and key exchange. ...
    (microsoft.public.platformsdk.security)
  • Re: a CryptoAPI newbies question
    ... Note that AT_KEYEXCHANGE keys can do BOTH key exchange and signing -- it ... doesn't hurt anything to have the key imported as as an AT_KEYEXCHANGE key. ... > AT_KEYEXCHANGE key pair. ...
    (microsoft.public.platformsdk.security)
  • Name this key exchange
    ... 1st party sends his public keys to 2nd party ... My question is, what do you call this key exchange scheme, "RSA", "RSA ...
    (sci.crypt)
  • Re: Private key different; Public key same on Different Machines
    ... I generated this key pair on my machine a long time ... We use it for some assembly signing with the AssemblyKeyFileAttribute ... machine and this is why everyone can verify my signatures but can't produce ... I do understand what you about me using the key exchange and I'll ...
    (microsoft.public.dotnet.security)
Quantcast