Cryptography Reference
In-Depth Information
logarithm problem thwarts an attacker's attempt to look at the starting point
and the result to try to work backward and discover one of the secret numbers.
ECDH works the same way; both sides agree to a starting point, in this case
a point on an elliptic curve whose parameters are negotiated in the clear. Each
side then multiplies that point by a secret number, shares the resulting point
with the other, and completes the shared multiplication with its own secret
number. Because ECC point multiplication is distributive, they both arrive at
the same shared point, and because ECC division is a diffi cult problem to which
no effi cient solution is known, an attacker can't work backward to uncover the
secret number.
As discussed in Chapter 8, this is actually good enough for a key exchange
in plain view of a passive eavesdropper. However, in order to guard against
man-in-the-middle attacks, at least one side must authenticate the other, and
the key exchange parameters must be digitally signed. Digital signatures imply
public keys, and public keys imply certifi cates. Therefore, a complete ECC key
exchange solution additionally involves the exchange of a certifi cate bearing
an ECDSA public key, which is then used to sign the ECDH parameters verifi -
ably. As long as the client trusts the signer of the certifi cate (or the signer of the
signer, and so on), the key exchange is authentic.
ECDSA is, of course, analogous to DSA. A DSA public/private keypair is just
two numbers
x
and
y
, along with a set of parameters
p
,
g
, and
q
. The signature is
computed over a hash of the message and produces two numbers
r
and
s
— the
verifi er takes
p
,
g
,
q
, and
y
and verifi es that
r
is correct for
s
according to
y
.
An ECDSA public key is a point, and the private key is an integer. Of course,
everything is relative to a curve that is defi ned in terms of two numbers
a
and
b
, and a starting point
G
. The signer computes an
r
and
s
pair from the private
key point; the verifi er checks to see if
r
and
s
match according to the public key
point. So, to support ECC, you must implement ECDH for key exchange and
ECDSA for signature verifi cation.
Note that there's no reason at all why you must use ECDH and ECDSA together.
It's perfectly permissible — and even preferable, in some cases — for a server to
present an RSA certifi cate and use the RSA key to sign a set of parameters for
ECDH key exchange. Just like using an RSA key to sign a set of DH keys, this
enables you to present an RSA certifi cate but still achieve perfect forward secrecy.
Most of the heavy lifting surrounding the ECC implementation is done in
Chapter 4. However, to actually put it in practice, there are a couple of practical
considerations. The fi rst is the elliptic curve itself. Chapter 4 glossed over the
selection of the
a
and
b
parameters that defi ned the curve, the generator point
G
, the prime fi eld
p
, and the order
n
. As it turns out, it's not easy to create a
correct set, and it's even harder to do so securely. Fortunately, you don't have
to. The NIST has created a set of “named curves” that you can use. There's no
particular danger in letting everybody share the same set of curves as long as
everyone randomly chooses the secret parameters.
Search WWH ::
Custom Search