Skip to content
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

Merged
merged 2 commits into from Nov 30, 2018

Conversation

bergzand
Copy link
Member

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

@bergzand bergzand added Type: new feature The issue requests / The PR implemements a new feature for RIOT CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Area: crypto Area: Cryptographic libraries labels Oct 21, 2018
@bergzand bergzand added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Oct 21, 2018
@basilfx
Copy link
Member

basilfx commented Oct 22, 2018

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 :-)

@bergzand
Copy link
Member Author

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 :)

@bergzand
Copy link
Member Author

I'm thinking of renaming it to crypto_secure_wipe to prevent name collisions with at least Monocypher. Other suggestions are welcome

Marking as WIP to prevent merging before the rename

@bergzand bergzand added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 22, 2018
@bergzand
Copy link
Member Author

@basilfx I've added a small note to the function. I've also renamed the function to hopefully avoid naming collision.

* 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo ;-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

* 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
Copy link
Member

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.

Copy link
Member Author

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

@bergzand bergzand removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 23, 2018
@basilfx basilfx added Reviewed: 1-fundamentals The fundamentals of the PR were reviewed according to the maintainer guidelines Reviewed: 2-code-design The code design of the PR was reviewed according to the maintainer guidelines Reviewed: 4-code-style The adherence to coding conventions by the PR were reviewed according to the maintainer guidelines Reviewed: 5-documentation The documentation details of the PR were reviewed according to the maintainer guidelines labels Oct 23, 2018
@basilfx
Copy link
Member

basilfx commented Oct 23, 2018

I'm OK with the changes, looks good. Haven't tested it though.

@bergzand
Copy link
Member Author

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.

@basilfx
Copy link
Member

basilfx commented Oct 23, 2018

Would make sense, since a unit test verifies the code, not the compiler specifics ;-)

@bergzand
Copy link
Member Author

Added a simple test to the crypto unittest.

@jcarrano
Copy link
Contributor

It is not being optimized away (at least not now).

native:

00005233 <test_crypto_wipe>:
    5233:       55                      push   ebp
    5234:       89 e5                   mov    ebp,esp
    5236:       53                      push   ebx
    5237:       83 ec 34                sub    esp,0x34
    523a:       e8 01 c3 ff ff          call   1540 <__x86.get_pc_thunk.bx>
    523f:       81 c3 c1 cd 00 00       add    ebx,0xcdc1
    5245:       83 ec 04                sub    esp,0x4
    5248:       6a 14                   push   0x14
    524a:       68 aa 00 00 00          push   0xaa
    524f:       8d 83 34 bf 00 00       lea    eax,[ebx+0xbf34]
    5255:       50                      push   eax
    5256:       e8 d5 be ff ff          call   1130 <memset@plt>
    525b:       83 c4 10                add    esp,0x10
    525e:       83 ec 08                sub    esp,0x8
    5261:       6a 13                   push   0x13
    5263:       8d 83 34 bf 00 00       lea    eax,[ebx+0xbf34]
    5269:       50                      push   eax
    526a:       e8 3f 2e 00 00          call   80ae <crypto_secure_wipe>
    526f:       83 c4 10                add    esp,0x10
..............

arm:

{
    13dc:       b513            push    {r0, r1, r4, lr}
    memset(secret, VALUE, sizeof(secret));
    13de:       4c12            ldr     r4, [pc, #72]   ; (1428 <test_crypto_wipe+0x4c>)
    13e0:       2214            movs    r2, #20
    13e2:       21aa            movs    r1, #170        ; 0xaa
    13e4:       0020            movs    r0, r4
    13e6:       f001 ff4d       bl      3284 <memset>
    /* Wipe everything except the last byte */
    crypto_secure_wipe(secret, sizeof(secret) - 1);
    13ea:       2113            movs    r1, #19
    13ec:       0020            movs    r0, r4
    13ee:       f001 f83d       bl      246c <crypto_secure_wipe>
.....

@bergzand
Copy link
Member Author

It is not being optimized away (at least not now).

@jcarrano Thanks for checking. Is this with or without the test assert reading the values after the call?

@jcarrano
Copy link
Contributor

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).

@bergzand
Copy link
Member Author

bergzand commented Nov 7, 2018

@basilfx @jcarrano Ready to squash here?

@basilfx
Copy link
Member

basilfx commented Nov 7, 2018

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.
@bergzand
Copy link
Member Author

bergzand commented Nov 7, 2018

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.
@bergzand
Copy link
Member Author

bergzand commented Nov 7, 2018

Fixed the murdock issue with an amend

@bergzand
Copy link
Member Author

@jcarrano Mind pressing the big green button here? :)

@jcarrano jcarrano merged commit 77c9cc4 into RIOT-OS:master Nov 30, 2018
@bergzand
Copy link
Member Author

@jcarrano Thanks!

@bergzand bergzand deleted the pr/crypt/helper_add_wipe branch November 30, 2018 10:38
@aabadie aabadie added this to the Release 2019.01 milestone Dec 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: crypto Area: Cryptographic libraries CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Reviewed: 1-fundamentals The fundamentals of the PR were reviewed according to the maintainer guidelines Reviewed: 2-code-design The code design of the PR was reviewed according to the maintainer guidelines Reviewed: 4-code-style The adherence to coding conventions by the PR were reviewed according to the maintainer guidelines Reviewed: 5-documentation The documentation details of the PR were reviewed according to the maintainer guidelines Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants