How to transform 'toy' examples to production example ?

[anssi-fr]

How to transform 'toy' examples to production example ?

[rb-anssi]

Hi,

Do you talk about the ECDH example? If yes, you indeed will have to add DPA/SPA/CPA countermeasures. The scalar multiplication Q=dG is not blinded, so you will have to use the proper blinding primitive instead of the unsafe one (by the way, commit a8b21ff introduces such a primitive). Actually, the countermeasures you will have to add (against side-channel attacks or fault attacks) really depend on your usage context of libecc!

Regards,

[julienmoinard]

Hi,
Thank you so much for your work & feedback.

Yes I talk about the ECDH example, but I am so confused because this library seems to be used in WOOKEY project ?

https://wookey-project.github.io/tataouine/externals.html
I am suprised that library is not side channel proof ?

So the WOOKEY project is not really secure against side channel attacks ?

You introduce a blinding primitive instead of an usafe one but if I read your comment on the commit I can understand that the library is not really safe and need to be improve especially on this point and blinding secrets ? Can you confirm me ?

Except DPA/SPA/CPA I can't use this library for a production because I need to fix some security point before ?

Thank you so much.

[rb-anssi]

You are perfectly right to spot the usage of libecc in the WooKey project. However, some elements are to be noticed here:

1. The ECDH code of WooKey is not the 'toy' example used in libecc src/examples per se, and some blinding is used there as expected (and as you describe in your comment). ECDH is also performed combined to ECDSA signature verification (so that Alice checks that Bob signs the public point Q=dG sent on the line).

2. ECDH/ECDSA in WooKey are used in addition to other defense mechanisms. Namely, the ECDSA private key used for the signed ECDH is locally encrypted on the device and a side-channel attacker does not have a "direct" access to this primitive (a PIN must be provided first). So concluding that the WooKey project is not secure against side-channel attacks is a bit of a shortcut :-)

3. Apart from DPA/SPA/CPA and fault attacks, libecc core (i.e. not the toy examples in libecc/src/examples) should be OK for a usage in production (if you talk about "software" maturity). Just be aware when compiling for specific/exotic targets to turn on stack canaries where available, as well as other defense-in-depth mechanisms your toolchain/OS provides (think about PIC/PIE for ASLR randomization and so on).

4. Regardless of implemented countermeasures (such as blinding, constant time design and so on), it is very complex to "prove" that a code is indeed robust against all the SCA litterature attacks on Elliptic Curves and big numbers arithmetic, not to mention fault attacks or combined attacks. Also, since libecc is in pure C (for portability issues), it is very difficult to ensure that a piece of code, albeit thought to be constant time, won't induce a leak because of CPU caches, specific instructions and so on. Please see the discussion here: https://github.com/ANSSI-FR/libecc#libecc-side-channel-attacks-and-constant-time. Finally, the same code can prove to be robust on a given MCU, but very leaky on another one: only a proper leakage assessment/characterization on your specific target will discard attack paths or not.

5. Point 4) does not mean that you should not use libecc at all in your project, but that if you use it, you should think about the contexts/targets where it will be used as well as a quotation of the attacker level, and maybe think of complementary countermeasures (as in the WooKey project).

6. If your project can afford it and if SCA and fault attacks are critical issues in your context, we strongly advise to perform audits/leakage assessments on your final code integrating libecc (or any other library by the way) for a better control on the risks and possible countermeasures.

Hoping that this will help you :-)

Regards,

[rb-anssi]

Also, as a side note regarding blinding, if you were refering in you comment to the :
"TODO:
For now, sensitive values (private key and nonce) blinding is still a
work in progress. Some FIXMEs are left intentionally in the code to handle this
ASAP (and determine whether some operations are really considered as possibly
leaking information or not)."

of commit a8b21ff, this should be fixed in commit a44d649.

Regards,

[julienmoinard]

Awsome, thank you so much for your answer. This is a complete and very useful explaination for me. Thank you so much for your really great job. Have a nice weekend.Best regards, Le 6 sept. 2019 18:33, Ryad Benadjila <[email protected]> a écrit : You are perfectly right to spot the usage of libecc in the WooKey project. However, some elements are to be noticed here: 1) The ECDH code of WooKey is *not the 'toy' example* used in libecc src/examples per se, and some blinding is used there as expected (and as you describe in your comment). ECDH is also performed combined to ECDSA signature verification (so that Alice checks that Bob signs the public point Q=dG sent on the line). 2) ECDH/ECDSA in WooKey are used in addition to other defense mechanisms. Namely, the ECDSA private key used for the signed ECDH is locally encrypted on the device and a side-channel attacker does not have a "direct" access to this primitive (a PIN must be provided first). So concluding that the WooKey project is not secure against side-channel attacks is a bit of a shortcut :-) 3) Apart from DPA/SPA/CPA, libecc core (i.e. *not* the toy exampeles in libecc/src/examples) should be OK for a usage in production (if you talk about "software" maturity). Just be aware when compiling for specific/exotic targets to turn on stack canaries where available, as well as other defense-in-depth mechanisms your toolchain/OS provides (think about PIC/PIE for ASLR randomization and so on). 4) Regardless of implemented countermeasures (such as blinding, constant time design and so on), it is very complex to "prove" that a piece of code is indeed robust against all the SCA litterature attacks on Elliptic Curves and big numbers artihmetic, not to mention fault attacks or combined attacks. Also, since libecc is in pure C (for portability issues), it is very difficult to ensure that a piece of code, albeit thought to be constant time, won't induce a leak because of CPU caches, specific instructions and so on. Please see the discussion here: https://github.com/ANSSI-FR/libecc#libecc-side-channel-attacks-and-constant-time. Finally, the same code can prove to be robust on a given MCU, but very leaky on another one: only a proper leakage assessment/characterization on your specific target will discard attack paths or not. 5) Point 4) does not mean that you should not use libecc at all in your project, but that if you use it, you should think about the contexts/targets where it will be used as well as a quotation of the attacker level, and maybe think of complementary countermeasures (as in the WooKey project). 6) If your project can afford it and if SCA and fault attacks are critical issues in your context, we strongly advise to perform audits/leakage assessments on your final code integrating libecc (or any other library by the way) for a better control on the risks and possible countermeasures. Hoping that this will help you :-) Regards,

…

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #7 (comment)