On 01/09/2020 16:46, CODERE Carl-Eric wrote: > Greetings, > Thanks for the quick reply, actually from the perspective of mobile > security, once the platform sandbox has been compromised, it is much > easier for an attacker to replace a shared library with another one he has > programmed than statically analyzing a properly stripped application to discover > its cryptographic entry points and then patching it and/or hooking it (In the > shared library the entry point names are clearly visible)... Hence final asset > loss is the same, but the actual time to do the attack would be different. > The goal is to add extra complexity for the attack, not to avoid it completely. Slowing down an attack on an already compromised system is simply not a design goal for OpenSSL 3.0. Nor was it for the FIPS Object Module 2.0 AFAIK although it might have been an accidental by-product. Once your system is compromised there are so many ways to attack it that I severely doubt whether the difference between static vs dynamic linking is going to make much difference to the overall result. But ultimately you know your application context better than I do. From an OpenSSL perspective the decision to use dynamic linking for the FIPS provider was fundamental and meant that we could avoid a whole heap of problems that plagued the FOM 2.0. This isn't a design decision that is likely to be reversed - and certainly could not be in the 3.0 timescale. You will have to weigh the security pros and cons of this for your context. Matt
