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

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

 



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@xxxxxxxxxxxx> 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

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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux