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
