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

Minerva attack on ARM architecture #24254

Open
GeorgePantelakis opened this issue Apr 24, 2024 · 7 comments
Open

Minerva attack on ARM architecture #24254

GeorgePantelakis opened this issue Apr 24, 2024 · 7 comments
Labels
branch: master Merge to master branch branch: 3.0 Merge to openssl-3.0 branch branch: 3.1 Merge to openssl-3.1 branch: 3.2 Merge to openssl-3.2 branch: 3.3 Merge to openssl-3.3 help wanted triaged: bug The issue/pr is/fixes a bug

Comments

@GeorgePantelakis
Copy link

GeorgePantelakis commented Apr 24, 2024

@tomato42 and I have tested OpenSSL in ARM architecture and we found that it may be vulnerable to a variant of the Minerva attack. We used statistical analysis to confirm the presence of side channels but we did not perform the Minerva attack against the implementation.

In the test scenario, we measure the time of signing of random messages using the EVP_DigestSign API (Init, Update, and Final) and then use the private key to extract the K value (nonce) from the signatures. Then based on the bit size of the extracted nonce we compare the signing time of full-sized nonces to signatures that used smaller nonces using statistical tests.

In our initial test, for ARM we tested P-256 in 3 microarchitectures (Ampere Altra Max CPU, Cavium's ThunderX2 CN99XX CPU with Vulcan microarchitecture, and Ampere's eMAG CPU with Skylark microarchitecture) and still found differences between them. Ampere Altra Max CPU doesn't show a signal while the other two microarchitectures do. In these results we can see a clear leak: there is a dependency between the bit size of K and the size of the side channel.

For Ampere Altra Max CPU:
conf_interval_plot_all_k_sizes_trim_mean_05_0-10
Results for the non-deterministic path of the code. Skilling-Mack test p-value: 6.201480e-02. The sample tested has 291,513,535 observations.

conf_interval_plot_all_k_sizes_trim_mean_05_0-10
Results for the deterministic path of the code. Skilling-Mack test p-value: 9.524591e-01. The sample tested has 161,951,709 observations.

For Cavium's ThunderX2 CN99XX CPU with Vulcan microarchitecture:
conf_interval_plot_all_k_sizes_trim_mean_45_0-10
Results for the non-deterministic path of the code. Skilling-Mack test p-value: 3.958440e-20. The sample tested has 647,808,394 observations.

conf_interval_plot_all_k_sizes_trim_mean_45_0-10
Results for the deterministic path of the code. Skilling-Mack test p-value: 1.215735e-12. The sample tested has 161,951,519 observations.

For Ampere's eMAG CPU with Skylark microarchitecture:
conf_interval_plot_all_k_sizes_trim_mean_45_0-10
Results for the non-deterministic path of the code. Skilling-Mack test p-value: 2.028643e-12. The sample tested has 647,829,103 observations.

conf_interval_plot_all_k_sizes_trim_mean_45_0-10
Results for the deterministic path of the code. Skilling-Mack test p-value: 6.354241e-59. The sample tested has 64,785,572 observations.

@GeorgePantelakis GeorgePantelakis added the issue: bug report The issue was opened to report a bug label Apr 24, 2024
@tom-cosgrove-arm
Copy link
Contributor

In the description:

OpenSSL in s390x architecture

Missing search and replace with Arm? :)

@t8m
Copy link
Member

t8m commented Apr 24, 2024

@GeorgePantelakis the signal is very small ~1ns and I would be very curious to see any real world attack scenario that could take an advantage of such small signal.

@t8m t8m added branch: master Merge to master branch triaged: bug The issue/pr is/fixes a bug branch: 3.0 Merge to openssl-3.0 branch branch: 3.1 Merge to openssl-3.1 branch: 3.2 Merge to openssl-3.2 branch: 3.3 Merge to openssl-3.3 help wanted and removed issue: bug report The issue was opened to report a bug labels Apr 24, 2024
@GeorgePantelakis
Copy link
Author

@t8m That might be true, at least for now, but as you can see for Skylark in the deterministic path the signal is ~3ns so that could be an issue.

@tomato42
Copy link
Contributor

@GeorgePantelakis the signal is very small ~1ns and I would be very curious to see any real world attack scenario that could take an advantage of such small signal.

Note that the leakage is most likely in scalar multiplication, which means ECDH is also most likely affected. So, anything that exposes a network API that uses static ECDH, for example, Json Web Encryption, can be attacked through this.

Confirming 1ns difference over the network is 100% possible, I've done that multiple times, it's just a question of persistence.

@bernd-edlinger
Copy link
Member

There is a reason why an ECDH secret is usually not used in more than one key agreement.

@davidben
Copy link
Contributor

davidben commented Apr 25, 2024

Depends on the use case. TLS doesn't because TLS uses signing keys for the long-lived credential, but there are plenty of protocols that are designed differently. HPKE, other ECIES schemes, Signal, the original QUIC handshake, etc.

Constant time ECDH isn't meaningfully harder than constant time ECDSA signing. Arguably easier. ECDSA is a point multiplication and then some. (Although they're not quite the same multiplication. ECDSA is a base point multiplication and ECDH is an arbitrary point. But that doesn't change how hard constant time is.)

@tomato42
Copy link
Contributor

There is a reason why an ECDH secret is usually not used in more than one key agreement.

that's why I wrote "static ECDH", not "ECDHE".

Yes, for ECDHE, like in TLS, IPsec or SSH, when the key is used once, or just few hundred times, a remote network timing attack is basically impossible with leakage this small.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch: master Merge to master branch branch: 3.0 Merge to openssl-3.0 branch branch: 3.1 Merge to openssl-3.1 branch: 3.2 Merge to openssl-3.2 branch: 3.3 Merge to openssl-3.3 help wanted triaged: bug The issue/pr is/fixes a bug
Projects
None yet
Development

No branches or pull requests

6 participants