CVE-2022-0778 - Impact of ECC cipher with valid server ECC certificate

[Vipul Mehta]

Thanks.
I did some more analysis and now I understand it completely.

ECC curve equation:
y^2 = x^3 + ax + b (mod p), where p is prime

Elliptic Curve parameters are:
p, a, b, G, n, h
G = Generator Point used to generate other points
Private Key = Random Number
Public Key = Point on Curve = (Generator Point)*(Private Key)

If the public key point is (x0, y0) then the client will send (x0,y0) to
the server. But, clients can use point compression and send x0 with a sign
of y0 as y0 can have two values i.e. +ve and -ve.
Server will compute y0 using the curve equation and p.
y0 = sqrt(x0^3 + bx0 + c) (mod p)

If p is incorrect then due to a bug in calculation of modular square root
in openssl, vulnerability will get triggered.
If the server has the correct value of p then there will be no
vulnerability.



On Sat, Mar 26, 2022 at 1:01 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Sat, Mar 26, 2022 at 12:32:03PM +0530, Vipul Mehta wrote:
>
> > If we consider ECDHE_ECDSA cipher based TLS handshake, then it is
> possible
> > that the client can send invalid public session key to the server causing
> > the vulnerability. Is this assumption correct ?
>
> The CVE only affects situations in which the untrusted peer can specify
> malign "explicit" curve *parameters*, not just the public point.
>
> > If yes, then I think disabling ECC cipher suites should prevent the
> > vulnerability if we don't want to upgrade openssl considering there is no
> > other cryptographic operation except w.r.t. TLS.
>
> Unless I'm missing something, there's no need to disable ECC ciphers,
> since with TLS 1.0 through 1.2 the curve parameters are chosen by the
> server.
>
> With the TLS 1.3, the client typically sends a key share first, which
> consists of a named group and again a public point.  There is no
> mechanism for conveying "explicit" ECC parameters
>
>     https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8
>     https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8.2
>
> So either way, TLS servers are safe if they don't solicit client
> certificates, or otherwise in some form consume X.509 SPKI public keys
> (which with ECC do signal either a named group or provide explicit
> parameters).
>
> --
>     Viktor.
>


-- 
Regards,
Vipul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220327/69660daa/attachment.htm>