CBE SB control: don't encrypt invalid keys #72
Comments
m-stein
pushed a commit
to m-stein/cbe
that referenced
this issue
Dec 16, 2021
The CBE superblock control used to encrypt both the current and the previous
key when synchronizing the superblock to the block back-end, regardless of
whether the previous key was valid or not (indeed it is only valid while
rekeying). This led to problems with hardware implementations of the Trust
Anchor that have not accepted these keys.
With this commit, the superblock control always checks for the superblock state
and leaves the previous key untouched when not in the rekeying state. This
ignorance of the field doesn't lead to leakage of former keys in plaintext as
rekeying always clears the previous key slot in the superblock before switching
back to the non-rekeying ("Normal") state.
Ref cbe-project#72
m-stein
pushed a commit
to m-stein/cbe
that referenced
this issue
Dec 16, 2021
The CBE superblock control used to encrypt both the current and the previous
key when synchronizing the superblock to the block back-end, regardless of
whether the previous key was valid or not (indeed it is only valid while
rekeying). This led to problems with hardware implementations of the Trust
Anchor that have not accepted these keys.
With this commit, the superblock control always checks for the superblock state
and leaves the previous key untouched when not in the rekeying state. This
ignorance of the field doesn't lead to leakage of former keys in plaintext as
rekeying always clears the previous key slot in the superblock before switching
back to the non-rekeying ("Normal") state.
Fixes cbe-project#72
|
Fixed by 805b094 . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks to @throwException we discovered that the CBE driver often requests the encryption of keys that are all zeroes. This is caused by the superblock control module that always encrypts both the slot for the current key and the slot for the previous key when writing out a superblock to the block back-end. But the latter contains a valid key only while the CBE is rekeying. When not in rekeying, the latter encryption step should be spared out not only because of efficiency but also because it led to certain hardware Trust Anchors not accepting the zero key material and fail on the corresponding requests.
The text was updated successfully, but these errors were encountered: