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

Don't store an HMAC key for longer than we need #10747

Closed
wants to merge 1 commit into from

Conversation

mattcaswell
Copy link
Member

The HMAC_CTX structure stores the original key in case the ctx is reused
without changing the key.

However, HMAC_Init_ex() checks its parameters such that the only code path
where the stored key is ever used is in the case where HMAC_Init_ex is
called with a NULL key and an explicit md is provided which is the same as
the md that was provided previously. But in that case we can actually reuse
the pre-digested key that we calculated last time, so we can refactor the
code not to use the stored key at all.

With that refactor done it is no longer necessary to store the key in the
ctx at all. This means that long running ctx's will not keep the key in
memory for any longer than required. Note though that the digested key
is still kept in memory for the duration of the life of the ctx.

Fixes #10743

Note: It is debatable whether this should come under the "bug" rules or not, and therefore be eligible for backport to 1.1.1. Since it provides no user visible features, and is a security hardening measure I have flagged it for 1.1.1.

The HMAC_CTX structure stores the original key in case the ctx is reused
without changing the key.

However, HMAC_Init_ex() checks its parameters such that the only code path
where the stored key is ever used is in the case where HMAC_Init_ex is
called with a NULL key and an explicit md is provided which is the same as
the md that was provided previously. But in that case we can actually reuse
the pre-digested key that we calculated last time, so we can refactor the
code not to use the stored key at all.

With that refactor done it is no longer necessary to store the key in the
ctx at all. This means that long running ctx's will not keep the key in
memory for any longer than required. Note though that the digested key
*is* still kept in memory for the duration of the life of the ctx.

Fixes openssl#10743
@lantse-cap1
Copy link

A very nice fix. Thank you!

Copy link
Member

@t8m t8m left a comment

Choose a reason for hiding this comment

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

As this provides code cleanup, security hardening and even (minor) performance improvement due to lowering the HMAC_CTX memory footprint I think it is perfectly fine for 1.1.1.

@t8m t8m added the approval: done This pull request has the required number of approvals label Jan 3, 2020
Copy link
Contributor

@paulidale paulidale left a comment

Choose a reason for hiding this comment

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

Looks fine.

I think 1.1.1 is appropriate too.

int rv = 0;
int i, j, reset = 0;
int rv = 0, reset = 0;
int i, j;
Copy link
Contributor

Choose a reason for hiding this comment

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

Kind of odd moving this up a line.

Copy link
Contributor

@mspncp mspncp Jan 4, 2020

Choose a reason for hiding this comment

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

It looked more odd before the change. Now there are two zero-initialized local variables in line 21 and two uninitialized counter variables in line 22.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not suggesting it gets changed back, I agree it's better this way. I just thought it odd to make a non-essential change.

Copy link
Member Author

Choose a reason for hiding this comment

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

At one point during developing this change I removed the reset variable altogether. I later realised I still needed it so put it back again. Inadvertently it went to a slightly different place. But since everyone seems ok with it, and even to prefer it this way, I'll leave it.

@mattcaswell mattcaswell added approval: ready to merge The 24 hour grace period has passed, ready to merge and removed approval: done This pull request has the required number of approvals labels Jan 6, 2020
openssl-machine pushed a commit that referenced this pull request Jan 6, 2020
The HMAC_CTX structure stores the original key in case the ctx is reused
without changing the key.

However, HMAC_Init_ex() checks its parameters such that the only code path
where the stored key is ever used is in the case where HMAC_Init_ex is
called with a NULL key and an explicit md is provided which is the same as
the md that was provided previously. But in that case we can actually reuse
the pre-digested key that we calculated last time, so we can refactor the
code not to use the stored key at all.

With that refactor done it is no longer necessary to store the key in the
ctx at all. This means that long running ctx's will not keep the key in
memory for any longer than required. Note though that the digested key
*is* still kept in memory for the duration of the life of the ctx.

Fixes #10743

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from #10747)
@mattcaswell
Copy link
Member Author

Pushed to master. The 1.1.1 version apparently needs a slight adjustment. I'll raise a new PR for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approval: ready to merge The 24 hour grace period has passed, ready to merge branch: master Merge to master branch branch: 1.1.1 Merge to OpenSSL_1_1_1-stable branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HMAC_Init_ex failed to clean up the key buffer, leaving the HMAC key in plaintext
5 participants