[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding Bill's draft... another Bill's open issues with

> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
> Ok.  Here's an abstract overview.  If this is too abstract for you,
> I'll refine this into something more concrete.
>
No, that was good enough for me to understand that you are measuring the
wrong text-message pairs.


> Assume that there's a replicated service which we wish to attack:
>
> 	client  <---->  server A   <----->  server B
> ...
>
> As a legitimate user of this service, we can tweak its database at one
> site; that site will then "push" our changes to the other sites, and
> we can then snoop on the network traffic that results.
> ...
>
> Thus, as I said earlier, we can induce a system to create and destroy
> a large number of SPI's with a third party to provide us with a large
> number of chances to attack the hash function used to validate the
> Photuris change_message protocol.
>
Now I understand.  Clever.  But, there are several reasons why this
attack provably (P&vO) cannot succeed:

 1) The shared-secret between the other parties will be different, even
    when the target uses the same public value, as the other party will
    have a different public value.  You cannot use your SA with server A
    to influence the SAs between A and B.  No calculable relation.

 2) You have no control over the SPI used (or any other parameter,
    visible or invisible), and therefore cannot get the requisite number
    of "chosen" message pairs.

 3) Much (or most) of the material covered by the hash is hidden
    (encrypted), and therefore you cannot see the data that you want to
    measure to get the "known" message pairs.

 4) The actual hash is also hidden (encrypted), and therefore you cannot
    verify any forgery attempts.


> I'm not saying "change the bit level encoding".  I'm saying "move the
> abstraction boundary" -- at the layer within Photuris where you
> dispatch to a particular keyed hash algorithm, keep the key separate
> from the data; under the covers, it can combine it exactly as it's
> specified in photuris-09, or in a new way.
>
Aha, why didn't you say so in the first place?


> I had difficulty figuring out from photuris-09 where the
> abstraction boundary was between the various transforms and their
> uses.
>
> Here is a concrete suggested wording change to address the primary problem.
> If you accept this change (which I doubt), I'll supply wording to fix up the
> other places which use hash(concat(key,data,key))
>
Surprise!  Accepted.  Well, I won't add a separate section, and I'm not
that fond of certain phraseology, but I will rearrange the text in the
manner that you suggest.  Seems reasonable to me!


   The Validity-Method keyed cryptographic hashing function is supplied
   with two inputs:

    - the computed shared-secret,
    - the data to be hashed (as a concatenated sequence of octets).

   The resulting hash value is stored in the Verification field
   (variable precision number).

   The Validity-Method cryptographic hash is calculated over the
   following concatenated data values:

    + the Initiator Cookie,
    + the Responder Cookie,
    + the SPI Owner (receiver) Identity Verification,
    + the SPI User (sender) Identity Verification,
    + the Type, LifeTime and SPI,
    + the Attribute-Choices following the Verification field.


   Validity-Method

      When specified as a Validity-Method,
      as described in "Integrity Verification",
      an MD5 hash is calculated
      over the concatenation of

         MD5( key, data, key, md5fill )

      The leading key is not padded to any particular alignment.

      The resulting Verification field is 128-bits
      (18 octets including Size).

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2