gilles-peskine-arm
commented
2 years ago I see the values in this, but I also see two major difficulties.
There is a technical difficulty that, for asymmetric cryptography, a lot of allocations happen at a low level, inside the bignum module. Annotating bignums as sensitive/non-sensitive would require an API change and significant effort to propagate the information. Of course, there's the easy solution of treating all bignums as sensitive. We already do that with respect to zeroization: all bignum values are zeroed out before calling free(). But for an application that uses asymmetric cryptography, most of the memory consumption is bignums, so you might as well make mbedtls_calloc always allocate to the sensitive region. Even with symmetric cryptography, when doing authentication or verification, the library has no way to know whether the data it's manipulating is supposed to be confidential, so either it must assume confidentiality or it needs an extra parameter.
And there is a conceptual difficulty, which is: what information is considered sensitive? Obviously at least long-term keys are sensitive. But so is key-equivalent information: for example, an AES context contains an expanded key schedule which is just as sensitive as the key itself. In asymmetric cryptography, it can be tricky to distinguish key-equivalent values from less sensitive values that only reveal one message but not a long-term key. Are short-term keys sensitive? Yes, but less so than long-term keys — but maybe you don't have enough high-security RAM for them. And what about data protected by the keys? There's no point in protecting short-term decryption keys better than the data they're protecting. (But there is for authentication keys.) So in order for this feature to be useful, the allocator should allow some way of distinguishing between levels of sensitivity.
Almost all the data manipulated by Mbed TLS is sensitive to some degree: confidential user data, or cryptographic material that's protecting user data. The only things that are not confidential are ciphertext (if it isn't encrypted/decrypted in place), and data which is only required to be authentic but not confidential. And so we're back to having all allocations in the high-security memory region.
We already have a solution for putting all allocations in the high-security memory region: run crypto, and possibly TLS, as a service (on a platform such as TF-M or Parsec). And there's of course the alternative of using a separate malloc (but note that sensitive values can end up on the stack, so your stack needs to be in high-security memory). So a new feature would only be useful for environments where there isn't enough high-security memory to run all crypto in it. In which case, the selection of which values are most sensitive is critical. But this depends heavily on how much high-security memory there is and on the application.
So I'm afraid I don't see a good solution. Any useful feature will be very application-specific.
DemiMarie
Suggested enhancement
provide a way to use separate allocators for separate types of memory allocation. for example, add "type" parameter to mbedtls_calloc/free.
Justification
In my platform, some (smaller) memory region is more "secure" than the rest of (larger) memory region. ("secure" here means more resistant against bus-snooping for example.) I want to avoid placing private keys and similar secrets in the insecure region.
I considered to replace mbedtls_calloc with say, my_secure_calloc. however, as such allocations are scattered across algorithm specific code (rsa etc) right now, it's difficult to replace. (and it would be a nightmare to maintain these local changes.)