Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elliptic Curve timing leaks #869

Closed
noloader opened this issue Jul 26, 2019 · 9 comments
Closed

Elliptic Curve timing leaks #869

noloader opened this issue Jul 26, 2019 · 9 comments

Comments

@noloader
Copy link
Collaborator

noloader commented Jul 26, 2019

From a private email by Ján Jančár:

Message-ID: 93874bd8-653e-33e9-c429-93712c3f30ba@mail.muni.cz
Subject: Vulnerability disclosure
...

During our research into security of elliptic curve cryptography implementations on smart-cards and in software libraries [1], we have discovered timing leakage in the ECDSA signature generation in the Crypto++ library.

Vulnerability description

When performing ECDSA over binary field curves, Crypto++ leaks the bit-length of the nonce used in scalar multiplication. It also leaks some other currently unknown information, see the attached plots, specifically the 'msb_hist.png' plot.

This leakage can be abused if an attacker is able to measure the duration of signing of a few hundreds or thousands of known messages. The attacker can then use a lattice attack based on the Hidden Number Problem [2] to reconstruct the private key used, as demonstrated in [3] (even remotely!).

See the attached plots and heatmaps for details of the leakage on the standard sect233r1 curve. based on the level of noise present in the attacker's measurements (the lattice attack is very sensitive to noise) and willingness to trade-off computation time, the attack would require from 500 to 10k signatures.

The private key recovery itself, assuming a noise free set of just enough signatures, would then take a few minutes. The leakage is somewhat present in ECDSA over prime field curves as well, but much smaller, I do not know the cause of this.

[1]: ECTester: https://crocs-muni.github.io/ECTester/

[2]: D. Boneh, R. Venkatesan: Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes; https://crypto.stanford.edu/~dabo/abstracts/dhmsb.html

[3]: B. B. Brumley, N. Tuveri: Remote Timing Attacks are Still Practical; https://eprint.iacr.org/2011/232.pdf

It appears nearly all versions of Crypto++ are affected. Based on some research of antique Crypto++, I believe that means Crypto++ 3.2 and forward. Crypto++ 3.2 was released March 20, 2000.

Also posted to the mailing list at ECDSA timing leaks.

@denisbider
Copy link
Collaborator

Yikes. The finding about sect curves is significant enough, but I'm additionally concerned about this:

The leakage is somewhat present in ECDSA over prime field curves as well, but much smaller, I do not know the cause of this.

To my knowledge, the prime field curves are where ECDSA is more frequently used: for example, the nistp curves are standardized for use in SSH. I am curious about the significance of this "much smaller" leak and what type of addressing it might require.

@noloader
Copy link
Collaborator Author

The issue was assigned CVE-2019-14318.

@noloader
Copy link
Collaborator Author

noloader commented Jul 29, 2019

The timing attack on the ECDSA nonce length was cleared at Pull Request 870, Commit 80c59bcdb251.

Next on the hit list are the leaks in Add(), Double() and Multiply().

@noloader noloader changed the title ECDSA timing leaks Elliptic Curve timing leaks Jul 29, 2019
noloader added a commit to noloader/cryptopp that referenced this issue Aug 3, 2019
This is the initial cut-in of complete addition algorithms according to https://eprint.iacr.org/2015/1060.pdf. There are two outstanding problems. First, HMQV and FHMQV are failing self tests. We need to investigate further. Second, we cannot use the new algorithms on paths where a Montgomery representation is used. We need to investigate further.
This cut-in will allow us to proceed on evaluating the timing leaks.
noloader added a commit that referenced this issue Aug 5, 2019
This check-in provides the fix for leaks in ECP's Add() and Double(). The fixes were taken from Joost Renes, Craig Costello, and Lejla Batina's [Complete addition formulas for prime order elliptic curves](https://eprint.iacr.org/2015/1060.pdf).

The Pull Request includes two additional changes that were related to testing the primary fix. First, an `AuthenticatedKeyAgreementWithRolesValidate` interface was added. It allows us to test key agreement when roles are involved. Roles are "client", "server", "initiator", "recipient", etc.

Second, `SetGlobalSeed` was added to `test.cpp` to help with reproducible results. We had code in two different places that set the seed value for the random number generator. But it was sloppy and doing a poor job since results could not be reproduced under some circumstances.
@noloader
Copy link
Collaborator Author

noloader commented Aug 5, 2019

The timing attacks on the ECP (prime fields) were cleared at Pull Request 871, Commit c9ef9420e762.

Next on the hit list are the leaks in EC2N (binary fields).

noloader added a commit that referenced this issue Aug 7, 2019
This regains a lot of performance lost to the const-timeness (GH #869)
noloader added a commit that referenced this issue Aug 9, 2019
Placing AdditionFunction as an inner class of ECP broke the ABI. We need to maintain the ABI so distros can patch Crypto++ 8.2.
@noloader
Copy link
Collaborator Author

noloader commented Aug 10, 2019

A partial patch is available. The patch was created against the Crypto++ 8.2 and Crypto++ 5.6.4 releases. The patch fixes (1) leak in ECDSA nonce length; and (2) leak in prime fields (ECP class). Prime fields are the important one because they are ubiquitous.

The fix is incomplete because it is missing the fix for (3) leak in binary fields (EC2N class). The fix for (3) should be ready in a couple of weeks. Binary fields are less important because nearly no one (no one?) uses them. They have been discouraged for years.

The patches below were produced with diff -u. They can be applied with:

cd cryptopp
patch -p0 < cve-2019-14318.patch

Crypto++ 8.2

Partial patch: cve-2019-14318.patch.zip

Script to create patch: cve-2019-14318.sh.zip

Crypto++ 5.6.4

Partial patch: cve-2019-14318-CryptoPP564.patch.zip

Source for patch: https://github.com/noloader/cryptopp/tree/cve-2019-14318

@zorun
Copy link
Contributor

zorun commented Nov 30, 2019

If this is a serious security issue, can you make a new release with the fix?

@noloader
Copy link
Collaborator Author

@zorun,

Sorry about the late reply.

Yes, we will get a release out once we get the fixes together. We believe we have the fix for prime curves. It is in Master.

We still need to fix binary curves. I'm inclined to release without binary curves because they are not used in practice. We will get back to binary curves when time permits. However...

Philippe Antoine (@catenacyber) uncovered incorrect results in Brainpool curves. We are still working on this issue.

@xypiie
Copy link

xypiie commented Oct 9, 2020

@noloader is there any news about the fix (3) - the leak in binary fields (EC2N class)? Thanks.

@noloader
Copy link
Collaborator Author

Crypto++ 8.3 was released today. The patches are now officially released.

There's opportunity for improvement in the patches because there's some extra conversions happening. We'll speed things up eventually.

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Dec 21, 2020
- Fix CVE-2019-14318: Crypto++ 8.2.0 and earlier contains a timing side
  channel in ECDSA signature generation. This allows a local or remote
  attacker, able to measure the duration of hundreds to thousands of
  signing operations, to compute the private key used. The issue occurs
  because scalar multiplication in ecp.cpp (prime field curves, small
  leakage) and algebra.cpp (binary field curves, large leakage) is not
  constant time and leaks the bit length of the scalar among other
  information. For details, see:
  weidai11/cryptopp#869

- Update license hash due to the addition of ARM SHA1 and SHA256 asm
  implementation from Cryptogams
  weidai11/cryptopp@1a63112
  weidai11/cryptopp@4c9ca6b

https://www.cryptopp.com/release830.html

[Peter: adjust CVE info, issue is fixes in 8.3.0]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Dec 22, 2020
- Fix CVE-2019-14318: Crypto++ 8.2.0 and earlier contains a timing side
  channel in ECDSA signature generation. This allows a local or remote
  attacker, able to measure the duration of hundreds to thousands of
  signing operations, to compute the private key used. The issue occurs
  because scalar multiplication in ecp.cpp (prime field curves, small
  leakage) and algebra.cpp (binary field curves, large leakage) is not
  constant time and leaks the bit length of the scalar among other
  information. For details, see:
  weidai11/cryptopp#869

- Update license hash due to the addition of ARM SHA1 and SHA256 asm
  implementation from Cryptogams
  weidai11/cryptopp@1a63112
  weidai11/cryptopp@4c9ca6b

https://www.cryptopp.com/release830.html

[Peter: adjust CVE info, issue is fixes in 8.3.0]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e7c789d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Dec 22, 2020
- Fix CVE-2019-14318: Crypto++ 8.2.0 and earlier contains a timing side
  channel in ECDSA signature generation. This allows a local or remote
  attacker, able to measure the duration of hundreds to thousands of
  signing operations, to compute the private key used. The issue occurs
  because scalar multiplication in ecp.cpp (prime field curves, small
  leakage) and algebra.cpp (binary field curves, large leakage) is not
  constant time and leaks the bit length of the scalar among other
  information. For details, see:
  weidai11/cryptopp#869

- Update license hash due to the addition of ARM SHA1 and SHA256 asm
  implementation from Cryptogams
  weidai11/cryptopp@1a63112
  weidai11/cryptopp@4c9ca6b

https://www.cryptopp.com/release830.html

[Peter: adjust CVE info, issue is fixes in 8.3.0]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e7c789d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Dec 22, 2020
- Fix CVE-2019-14318: Crypto++ 8.2.0 and earlier contains a timing side
  channel in ECDSA signature generation. This allows a local or remote
  attacker, able to measure the duration of hundreds to thousands of
  signing operations, to compute the private key used. The issue occurs
  because scalar multiplication in ecp.cpp (prime field curves, small
  leakage) and algebra.cpp (binary field curves, large leakage) is not
  constant time and leaks the bit length of the scalar among other
  information. For details, see:
  weidai11/cryptopp#869

- Update license hash due to the addition of ARM SHA1 and SHA256 asm
  implementation from Cryptogams
  weidai11/cryptopp@1a63112
  weidai11/cryptopp@4c9ca6b

https://www.cryptopp.com/release830.html

[Peter: adjust CVE info, issue is fixes in 8.3.0]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e7c789d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants