New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto/helper: Add secure wipe function #10219
Conversation
What about data remanence attacks? We should either list that this isn't taken care of, or implement a more secure wipe (multiple times, random data, memory type dependent). I guess the first is the easiest option :-) |
Yeah, let's go with the first option. Most crypto libraries I know of handle a "secure" wipe this way and only protect against normal memory reads and not against other memory black magic :) |
I'm thinking of renaming it to Marking as WIP to prevent merging before the rename |
@basilfx I've added a small note to the function. I've also renamed the function to hopefully avoid naming collision. |
sys/include/crypto/helper.h
Outdated
* This wipe function zeros the supplied buffer in a way that the compiler is | ||
* not allowed to optimize. This can be used to erase secrets from memory. | ||
* | ||
* Note that this function on its owm could be insufficient. It is outside the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
sys/include/crypto/helper.h
Outdated
* This wipe function zeros the supplied buffer in a way that the compiler is | ||
* not allowed to optimize. This can be used to erase secrets from memory. | ||
* | ||
* Note that this function on its owm could be insufficient. It is outside the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe add:
.. could be insufficient against (data remanence) attacks.
This clarifies why it is insufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, thanks for the suggestion
I'm OK with the changes, looks good. Haven't tested it though. |
I can add a quick unittest for this, only issue is that verifying the result is a read operation which also prevents the compiler from optimizing the wipe away. But it would test that the memory region is zero'd out. |
Would make sense, since a unit test verifies the code, not the compiler specifics ;-) |
Added a simple test to the crypto unittest. |
It is not being optimized away (at least not now). native:
arm:
|
@jcarrano Thanks for checking. Is this with or without the test assert reading the values after the call? |
Oops! It was with the read. I commented it and dissassembled it again. The code is still there, so it is still secure. It is declared as volatile, so it should get written eventually. The user just needs to be aware of what reorderings are possible (there is a C standard for that). |
I would say yes. I fully trust @jcarrano checks! |
Adds a cryptographically secure wipe function to wipe structs with sensitive data. Works by first casting the pointer to a `volatile` pointer to ensure that the compiler doesn't optimize the "memset" away.
57fbdde
to
43b481a
Compare
squashed! |
The test added for crypto_secure_wipe wipes a buffer with a secret in it. Only the last byte is kept as it was. The last byte is used to check that the function doesn't write outside the supplied buffer.
43b481a
to
7302869
Compare
Fixed the murdock issue with an amend |
@jcarrano Mind pressing the big green button here? :) |
@jcarrano Thanks! |
Contribution description
Adds a cryptographically secure wipe function to wipe structs with
sensitive data. Works by first casting the pointer to a
volatile
pointer to ensure that the compiler doesn't optimize the "memset" away.
Testing procedure
For now it is mostly if this compiles and if the source makes sense
Issues/PRs references
None