For example the Go package memguard.
Couldn't a devoted attacker just find the encryption key in memory? Is it that some forms of attacks can't expose all of memory but only adjacent memory/memory in a certain location?
2
- 2"Couldn't a devoted attacker just find the encryption key in memory?" - The package you reference does not claim to protect against all attacks, it is instead about reducing the attack surface. I doubt that it tries to protect the case where the attacker has full access to the memory of the running process, but it for example cares about not swapping sensitive parts of the memory to disk, protecting against some side channels, ...– Steffen UllrichCommentedFeb 16 at 11:32
- 2" Is it that some forms of attacks can't expose all of memory but only adjacent memory/memory in a certain location?" - information leackage attacks (like the famous Heartbleed) usually only expose smaller parts of the memory. Also the sensitive data are in this package specifically protected against some attacks - see the Features section for the details.– Steffen UllrichCommentedFeb 16 at 11:35
Add a comment |
1 Answer
If an attacker is able to dump the entire memory content, then, yes, they can get the key and defeat the encryption. However, many attacks aren't that far-reaching and can actually be addressed with encryption. Also note that the package doesn't rely on encryption alone but uses other mechanisms like prevent memory swapping and core dumps. In that sense, the Rust package seems similar to the “key shielding” which OpenSSH uses to protect keys at rest.
There are several benefits:
- As Steffen Ullrich already pointed out in the comments, memory encryption helps against side-channel attacks like Spectre or Rowhammer which only reveal part of the memory or introduce bit errors.
- Application bugs are less likely to leak secrets, because those remain encrypted most of the time and have to be explicitly “unshielded”.
- All secrets can be centrally managed. Instead of having to worry about individual pieces of data scattered across memory, you only have to worry about the key. For example, you can safely delete all secrets at once by clearing the key.
It's generally a good idea to address the problem of memory protection with a single reusable package rather than let every developer figure this out all by themself for each application.
- 1I think you a reading too much into that Go package: it's a simple package to get around the limit on the amount of pinned pages with handwaved encryption. The key material is kept pinned while the swappable memory is encrypted when not used. This doesn't really add much to the table. An attacker will use Spectre/MDS on the secrets first, these attacks a very tailored anyway, so this protection doesn't add anything to their complexity. Ditto for rowhammer, which can still mess up malleable encryption. Also, the data is unencrypted when in use, so leaks are just as likely (maybe a little lessCommentedFeb 17 at 9:14
- 1for uncontrolled leaks à là heartbleed but it really depends on the heap state at the time of the leak). Note also that the OpenSSH commit says that the key-shielding works for side channel attacks because they use a very large (16KiB) pre-key, the Go package uses 32B keys. The idea is to make the full recovery of the pre-key improbable.CommentedFeb 17 at 9:14
