ot_keymgr: Implement KMAC offloading, advance operations & all main FSM states
#185
Conversation
This file contains hidden or 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
|
Progresses lowRISC/opentitan#27894 |
AlexJones0
force-pushed
the
eg-keymgr-advancement
branch
5 times, most recently
from
b25e8af to
3af96d3
Compare
This was referenced Sep 17, 2025
|
Also see #188 which is the final keymgr PR - this shows all the new passing keymgr tests. |
AlexJones0
force-pushed
the
eg-keymgr-advancement
branch
2 times, most recently
from
e9b34a5 to
677077b
Compare
These device links will be needed for retrieving values used in the KDF (key derivation function) for keymgr advance operations. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
This commit introduces the logic relevant to computing the KDF `AdvData` input for the `Advance` operation, which depends on both the current keymgr stage and the CDI. This logic is adapted from the keymgr_dpe, but with many differences: - `keymgr` has no slots, and encodes stages in its main FSM states. - `keymgr` has 2 CDIs: one for sealing and one for attestation. Normally, you can select the CDI, but advance operations advance both (sealing, then attestation). - `keymgr` uses different KDF inputs to `keymgr_dpe`. It only has 1 ROM digest, uses creator/owner seeds in different phases, and concatenates its inputs in a different order. - `keymgr` gets creator/owner seeds from flash, instead of OTP. - `keymgr` chooses to use either sealing or attestation SW bindings based on the CDI, `keymgr_dpe` only has 1 SW binding. For now, many parts are still stubbed out - we do not yet send the KDF request to KMAC, and we do not properly handle wiping data on disablement, or invalid inputs. This commit also adds minimal handling for the `disable` operation. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
AlexJones0
force-pushed
the
eg-keymgr-advancement
branch
from
677077b to
5411c5e
Compare
This is mostly based on the equivalent keymgr_dpe implementation. Adds a connection from the keymgr to the KMAC via the KMAC app interface, and add logic for sending a KMAC request containing the contents of the KDF buffer. Also stub out a function for handling the KMAC response - the resulting logic will depend on the current operation, but for now is stubbed. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
AlexJones0
force-pushed
the
eg-keymgr-advancement
branch
from
5411c5e to
1c2e69e
Compare
jwnrt
approved these changes
Sep 18, 2025
Connect sideloading key sinks for AES, KMAC and OTBN to allow the keymgr to send keys to these blocks. This commit only introduces logic to push keys to the key sink interfaces, and does not yet implement any sideloading behaviour or related software register interfaces. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
Finishes the implementation of the keymgr's `Advance` operation, with logic for all key stages (still pending FSM key states). When an `Advance` operation is issued, the current key state is sideloaded to the KMAC, and the contents of the computed KDF buffer are processed to derive the next key state. One key difference from `keymgr_dpe` is that both CDIs must be advanced in a single advance operation, and so after receiving the KMAC response and storing the key state, we send another KMAC app request to advance the sealing key also. This continues for all CDIs (currently only 2). One other key difference to note is that `keymgr` does not unlock the max key version REGWENs on advancement, whereas the `keymgr_dpe` does (see the `keymgr.sv` and `keymgr_dpe.sv` RTL). Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
This commit implements all remaining `keymgr` FSM states, almost all of which are unique to `keymgr` and not in `keymgr_dpe`. Advancing and disabling is now supported for all key stage states. To reduce duplication, the different key FSM states are abstracted into a generic `ot_keymgr_fsm_key_stage(...)` function. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
Now that the `keymgr` is partially implemented, with the option to advance through all of its main FSM states (but no ability to generate output keys or sideload keys), this is sufficient to get the `keymgr_functest` passing. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
AlexJones0
force-pushed
the
eg-keymgr-advancement
branch
from
1c2e69e to
e2265b4
Compare
jwnrt
approved these changes
Sep 18, 2025
11 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR is the third of a series of 4 PRs to implement OpenTitan's
keymgrIP, as used in Earlgrey, split to ease review. You can see all the relevantkeymgrcommits in #188.This PR implements the main advancement logic for the keymgr, allowing it to progress from its initial state through the different keymgr key stages (
CREATOR,OWNER_INTERMEDIATEandOWNER). To support this, KMAC connectivity is added to offload cryptographic KDF operations to KMAC and advancement for all CDIs (in all stages) is implemented. The remainder of the main keymgr FSM states are also implemented, but a future PR will implement the stubbed generate operations that are currently missing.As seen in the last commit, this is now enough functionality to at least see the
keymgr_functestpassing.See the commit messages for more details about each change.