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

Bellovin's attack

Hi, Steve,

1. PROBLEM

 I've read your note and the foils you made available.  Your attack is good.
 If I understand, the following typifies the problem you've found:

                             - $M_i^a$ is machine $i$ with secret key $a$; 
                             - $U_i$ is user $i$;  
                             - $E$ is the adversary.
                        E
                        |
           a           \|/               a
        M_1      ----------------->   M_2
      /   \                          /    \
E = U_1   U_2                   E = U_3   U_4              
 
 Now obviously if $E$ breaks open the boundary of host $M_1$ or $M_2$,
 then there is nothing we can do; $E$ has $a$.  So the goal is that, 
 if $M_1$ and $M_2$ have NOT been compromised, then the privacy (for ESP) 
 and authenticity (for AH) should NOT be compromised (by $E$) in communications
 between $U_2$ and $U_4$.

 Now even the "ideal" encryption (a one-time pad $a$) effectively gives 
 $E$ an encryption/decryption oracle, $E_a(.), D_a(.)$.
 Thus your attack does NOT represent a problem with the encryption mechanism; 
 it's a problem with the way it's (proposed to be) used.  Now
 you might try to deny $E$ access to an $(E_a(.), D_a(.))$-oracle -- e.g., 
 you could say that the ciphertext produced by $U_i$ for $U_j$ is
                        _______________________
                       /                      \|/
        E'_aa' (x) = E_a(x) . MAC_a'(U_i. U_j  +   ).

 But such a thing doesn't work: the adversary still has her encryption oracle 
 (and therefore a decryption oracle for perfectly-good encryption mechanisms).  
 Inherently, if $M_i$ encrypts all $M_1 -> $M_2$ traffic with a the same key, 
 there will be no reason to believe that $E$ can not recover plaintext 
 $U_2 -> U_4$ traffic.


2. SOLUTION: Proper key-separation

 $M_k$ should NOT be using the same key to to protect the communications 
 between distinct $(U_i, U_j)$'s.  Instead, for host-pair keying, you have a 
 SINGLE host-pair SESSION key $a$ between hosts $M_1$ and $M_2$; but then 
 the OPERATIONAL key used for communication from $U_i$ to $U_j$ should be 
 a KEY VARIANT $h(U_1,U_2)$ -- not the session key $a$.

 Actually, to ensure proper mechanism independence, the operational 
 key for transform $T$ used for communication from $U_1$ to $U_2$ should be 
 key variant $h(T,U_1,U_2)$.  Here, $T$ is a registered identifier associated to
 the transform (and also including parameter values for the transform); and
 $h$ is something like a cryptographic hash function (e.g., MD5).  The key 
 distribution mechanism should not worry about its users, and the transforms should 
 not worry about theirs.  This simplify is accomplished with key separation.



Regards,
Phil Rogaway