Home | History | Annotate | Download | only in doc 
      1 
      2 # ECDH
      3 
      4 [TOC]
      5 
      6 ##ECDH description:
      7 See https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman
      8 
      9 ##Bugs
     10 Some libraries do not check if the elliptic curve points received from another
     11 party are points on the curve. Encodings of public keys typically contain the
     12 curve for the public key point. If such an encoding is used in the key exchange
     13 then it is important to check that the public and secret key used to compute
     14 the shared ECDH secret are using the same curve.
     15 Some libraries fail to do this check.
     16 
     17 **Potential exploits:**
     18 The damage done depends on the protocol that uses ECDH. E.g. if ECDH is used
     19 with ephemeral keys then the damage is typically limited. If the EC keys are
     20 static, i.e. used for multiple key exchanges then a failure to verify a public
     21 point can disclose the private key used in the same protocol.
     22 (To do: add papers describing the attack).
     23 
     24 ##Libraries
     25 **Sun JCE provider:**
     26 ECDH does not check if the points are on the curve.
     27 The implementer must do this.
     28 
     29 **Bouncycastle:**
     30 The ECDH implementation does not check if the point is on the curve.
     31 Furthermore, Bouncycastle does not even check if the public and private key are
     32 on the same curve. It performs a point multiplication \\(x \cdot Y\\) over the
     33 curve specified by the public key.
     34 
     35 **OpenSSL:**
     36 Point verification is done in OpenSSL if the right functions are used.
     37 Since OpenSSL is not well documented it is a bit tricky to find the right
     38 functions.
     39 (To do: maybe add an example).
     40 
     41 ##Countermeasures
     42 TODO:
     43 * use point compression. Formats such as X509EncodedKeySpec
     44 in Java include bits that indicate whether the point is compressed or not.
     45 Hence an attacker can always choose to use uncompressed points as long as this
     46 option is incorrectly implemented.
     47 * check that public and private key use the same curve
     48 * restrict the protocol to named curves
     49 * reconstruct the public key explicitly using the parameters of the private
     50   key.
     51 
     52 **Further recommendations:**
     53 If possible I also check if the points are on the curve after point
     54 multiplications on an elliptic curve in the hope to catch implementation
     55 and hardware faults.
     56 
     57 ## Some notable bugs:
     58 * ECDHC in bouncy castle could be broken by modifying the order of the public key.
     59