Document s2n's timing blinding and correct our CBC validation #179
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Manuel Barbosa from HASLab - INESC TEC, DCC FC Universidade do Porto, http://haslab.pt/mbb, contacted us to point out the finalizing a SHA or MD5 hash requires 9 bytes of space, rather than 8. The 9 bytes are the length of the data and an additional 0x80 byte. This issue means that our CBC verification isn't always running in constant time. Ocasionally an additional hash round will be required (if the size of the record is congruent to the block size mod 8). Thankfully our randomized delay on error code, which pauses for between 1ms and 10 seconds is more than adequence to ensure that any timing side channel here is not detectable or exploitable. Nevertheless, it is worth fixing the error.
Manuel Barbosa from HASLab - INESC TEC, DCC FC Universidade do Porto, http://haslab.pt/mbb, reported a correctness issue with our hmac implementation: our internal currently_in_hash_block is being set to 0 on s2n_hmac_init() but not reset to 0 during s2n_hmac_reset(). This commit corrects this bug.
Manuel Barbosa from HASLab - INESC TEC, DCC FC Universidade do Porto, http://haslab.pt/mbb, analysed our CBC verification algorithm and found that rather than checking the first $padding_length bytes of the padding, we were checking one-byte over (i.e. including the padding length byte itself). Before this commit: Byte: 0 1 2 3 4 5 Value: 5 5 5 5 5 5 Checked: X X X X X After this commit: Byte: 0 1 2 3 4 5 Value: 5 5 5 5 5 5 Checked: X X X X X With this commit, s2n correctly checks all of the padding bytes for equality with the padding length value. We no longer check that the padding length byte is equal to itself.
This commit documents our generalized handling of timing side channels.
baldwinmatt
added a commit
that referenced
this pull request
Sep 9, 2015
Document s2n's timing blinding and correct our CBC validation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Documentation change:
s2n includes a general purpose "failsafe" mitigation against certain timing side channel attacks: whenever a TLS record, or handshake message, fails to validate s2n adds a uniformly random delay of between 1 millisecond and 10 seconds. The effectiveness of this delay depends on the size of the side channel, but suppose that the leak is 1 microsecond (which would be quite large), then this delay will increase the theroritical complexity of the attack by a factor of over 8 trillion. For a smaller, more realistic, side channel the technique is exponentially more effective.
In our experiments, delays of this magnitude also incur other unpredictable sources of delay (e.g. CPU interrupt contention and network variance) that likely raise the complexity again by a similar factor. In other words: the attacker would have to derive a small signal of 1 microsecond from the noise of a delay factor that is at least 7 orders of magnitude greater in size.
Code change:
Manuel Barbosa from HASLab - INESC TEC, DCC FC Universidade do Porto, http://haslab.pt/mbb analyzed our CBC validation and found that the constant-time changes we added as part of commit 4d37298 were not entirely correct. Rather than needing 8 bytes of space to finalize a hash, SHA and MD5 hashes need 9 bytes.
Additionally Manuel noticed some other issues in the change; we were double validating the padding length byte (e.g. comparing it to itself) unnecessarily, not validating the first byte of padding (unless the maximum amount of padding was specified), and not reseting the counter we use to keep track of how many bytes have been entered into a hmac. commits for all of these issues are included in this pull request.