Minerva attack on power PC architecture about openssl HOT 16 OPEN

While not an exact match, valgrind's rules for uninitialized memory are very close to the constant-time computational model. For BoringSSL, we've found it very valuable for flagging non-constant-time code. It takes a bit of work, marking the right data is "secret" (uninitialized) and then "declassifying" (marking initialized) the right data at the right points. But it may help you all pinpoint the problem.

from openssl.

Hi @t8m. Thanks to you, @tomato42, and @GeorgePantelakis for this issue. Jaroslav Reznik brought this matter to our attention. So some questions. Are you looking for help from the IBM PPC crypto team? Is this problem specific to the new P-384 implementation? Do have already have recommendations on how we should modify the ppc64/ppc64le code? How can we test for this problem in house?

from openssl.

Are you looking for help from the IBM PPC crypto team?

yes, we don't have resources to fix it ourselves

Is this problem specific to the new P-384 implementation?

Probably, George will be able to say if any particular method is being called or not if you tell him what to look for

Do have already have recommendations on how we should modify the ppc64/ppc64le code?

No. Though at this point, the most likely reason for this leakage is a short-circuit in the scalar multiplication loop

How can we test for this problem in house?

You'll need to contact George for a the test harness and instructions how to execute it.

from openssl.

Hi @GeorgePantelakis. Can you help with some of the questions above? Is the matter all contained to the new P-384 implementation? How can we obtain the test harness?

from openssl.

Hello @gcwilson. Sorry for the big delay. To answer some of the questions. I do not know if it is the new implementation, we used the code for HEAD on 2024-04-16. As @tomato42 said if you tell me a specific function, I can search if it is called. Now for the test harness, sure, we will create tomorrow a toolkit so you can easily test it yourself. If there is anything else feel free to ask.

from openssl.

@davidben could you please provide more details?

from openssl.

Sure. Just tell valgrind that the secret data is "uninitialized". Then when you intentionally branch on or otherwise reveal data that is now public, you need to mark it "initialized" first.
https://boringssl.googlesource.com/boringssl/+/6ab7c1482bf4cdc91c87bc512aaf68ffb18975ec/crypto/internal.h#568

Valgrind will then do data flow analysis and flag when you index or branch based on "uninitialized" memory.

from openssl.

from openssl.

Just tell valgrind that the secret data is "uninitialized". Then when you intentionally branch on or otherwise reveal data that is now public, you need to mark it "initialized" first.

Nice trick!

from openssl.

@gcwilson, we have created a toolkit for Minerva. For now, it has only OpenSSL in it. You can find it at https://github.com/GeorgePantelakis/minerva-toolkit. For any questions or issues feel free to reach us.

from openssl.

Thanks very much for the toolkit @GeorgePantelakis. We plan to start investigating next week. And thank you @davidben for the Valgrind tips and tricks.

from openssl.

@gcwilson to provide a bit more information about using it: see the Marvin page for other general recommendations on running those tests, and if you'll need to figure out the precise location where the leak happens, you might want to use the technique I documented in the Debugging timing side-channel leaks post on my blog.

And just like George said, if you have questions, feel free to reach out to us.

from openssl.

Hi @GeorgePantelakis and @tomato42. Thanks for your help. We've successfully built the toolkit for Linux on Power and have gotten some initial results. We aren't seeing the same P-384 graph as you and want to understand why. We're going to do more tests on a POWER10 running only a single LPAR to ensure we aren't getting noise from other LPARs. Can you please tell us more about the test environment you used for your analysis? Was it on POWER8, POWER9, or POWER10?

from openssl.

@gcwilson not sure which machines @GeorgePantelakis used, if they were POWER9, then they most likely have been physical instances, if they were POWER10, then they would have been LPARs.

to see the same kind of graphs you will need to collect significant amount of data: all of the graphs above are statistics of over 300 million signatures. That's the amount necessary to get confidence intervals (the "error bars") to be as small as in those graphs: about or smaller than 1 ns. What confidence intervals do you see?

more generally: if the LPARs don't have dedicated CPU cores (you have CPU overprovisioning), then making sure the other LPARs do nothing before you run the test is a good idea. On the other hand, we've noticed that with dedicated cores, the POWER10 LPARs in general provide higher quality data (less noise) than bare-metal POWER9 machines, even if all the LPARs are collecting data at the same time.

from openssl.

@tomato42 thanks for the test environment information. You also anticipated our next question regarding sample size. We collected far fewer samples and our confidence intervals range from around 20-90 ns. We'll run with the number you recommend and will hopefully reproduce the results with that.

from openssl.

@gcwilson as written in the tlsfuzzer documentation the confidence interval is inversely proportional to the square root of the sample size. So for example, if you got a CI of 20 ns for the 383 bit nonce with P-384 curve, you'll need to collect about 400 times more signatures to get the CI to about 1 ns. (that's why it's so important to make sure the system setup minimizes noise, it's usually much easier to setup core isolation and stuff like this than to run a test with 100 times more measurements).

from openssl.