3

I'm seeking guidance on mitigating side-channel attacks in a cryptographic application where securely overwriting memory with zeros after use may not always be feasible. While I understand the importance of this practice in preventing memory disclosure vulnerabilities, I'm encountering situations where the secrets stored in memory need to persist for longer durations, making immediate zeroing out impractical.

In such cases, what alternative countermeasures can be employed to mitigate the risk of side-channel attacks? I'm aware of techniques like constant-time operations and memory protection mechanisms like libsodium's guarded heap allocations and permissions, but I'm unsure of libsodium's guarded heap allocations and permissions effectiveness in addressing side-channel vulnerabilities.

I would appreciate insights and recommendations from the community on additional strategies or best practices for protecting sensitive data in scenarios where immediate memory overwriting may not be viable.

Hern
  • 159
  • 1
  • 10
  • 1
    What is the specific case, what are the possible attack vectors, and what is the system? – kelalaka Feb 10 '24 at 13:42
  • Not sure if it's accurate but the scenario that was in my mind is something like the regular signing operations within certificate authority which may use the same keypair for multiple certificates issued within a specific timeframe. The situation can be something like the hypothetical case given or the hiding of secrets in memory like in the case of old school cd key in product or video games and in the context of DRM. – Hern Feb 10 '24 at 14:49
  • Not sure memory dumping is normally classed as a side-channel attack. I think all you can do is try to prevent the data being unintentionally written to disk and inputs being leaked (e.g., into shell history). The other approach would be to encrypt data in memory, but the key has to be stored somewhere, which means the attacker can likely access it and decrypt the data. In some programming languages you can't reliably zero data anyway, particularly for data types like strings. You can't really defend against an attacker on your machine. – samuel-lucas6 Feb 11 '24 at 09:51

1 Answers1

2

The purpose of overwriting secrets in memory once they're no longer needed is to avoid or limit information leaks if an application vulnerability leaks memory contents. This is not particularly related to side channel attacks. A side channel can leak the content of unused memory, but then typically it can also leak the content of used memory, and in fact most side channel attacks leak memory contents when that memory is used for something.

You can mitigate the risk of memory disclosure by using a language with enforced memory management (i.e. most languages other than C and C++). Those languages make it impossible to access the content of a variable except through that variable. However, there is still some risk of accidental disclosure. A logic errors in your application might expose data that you didn't intend to expose (e.g. an SQL vulnerability that allows attackers to craft arbitrary SELECT requests). Bugs in the implementation (e.g. in a JIT compiler) might allow attackers to do things that are impossible in a correct implementation of the language.

For long-lived secrets, you can mitigate the risk of exposure by isolating the secret from your main application. Make the secret accessible only to an isolated “partition” whose sole job is to do one thing with that secret. For example, if the secret is a signature key, the isolated partition's only interface is one that takes a message as input and returns the signed message. Hopefully, due to the small attack surface, attackers won't be able to leak the secret, only to make calls to use the secret. Even that is made harder because the attacker would need not just to disclose some memory of the main application, but to cause it to perform a request to the isolated partition with chosen input. Furthermore, if that happens, the isolated partition can make logs so that you'll at least know the extent of the damage after the fact. Also, once the attack is discovered and halted, you know that the attacker is no longer able to use the secret, e.g. they can't keep making more signatures forever.

The nature of the isolated partition depends on your system architecture. Even using a separate process helps (make sure to disable any debugging facilities that would allow the main application to read the other process's memory). That still leaves you at risk of a privilege escalation vulnerability in the operating system, which you can mitigate by using virtualization. For a higher level of isolation, put the isolated partition on separate hardware, to avoid leakage through side channels. (Though if the isolated partition is only doing cryptography using a high-quality library, it might be adequately protected from at least timing leakage.) For high isolation of a simple cryptographic process such as a signature, use a smart card, or a HSM for higher throughput.

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
  • "This is not particularly related to side channel attacks" - I would disagree; being able to examine memory after the operation can be considered a side channel attack (as it is exploiting information outside of what is considered in the standard cryptographic analysis, similar to what happens in timing and DPA side channel attacks) – poncho Feb 12 '24 at 04:16
  • NIST seems to use a different definition to Wikipedia. However, Crypto Dictionary suggests it is a type of side-channel attack. I think the confusion comes from nobody normally calling it one. Crypto Dictionary even says shoulder surfing is a side-channel attack. – samuel-lucas6 Feb 12 '24 at 08:23
  • @poncho You can consider it a side channel in the software environment, but in my experience that's not how cryptography implementers or security evaluators speak. It's a completely different kind of threat from leaks through timing, radio emissions, etc., with different exploits and different countermeasures. – Gilles 'SO- stop being evil' Feb 12 '24 at 10:50