Key Manager HWIP Technical Specification

Overview

This document specifies the functionality of the OpenTitan key manager.

Features

  • One-way key and identity (working) state hidden from software.
  • Version controlled identity and key generation.
  • Key generation for both software consumption and hardware sideload.
  • Support for DICE open profile

Description

The key manager implements the hardware component of the identities and root keys strategy of OpenTitan.

It enables the system to shield critical assets from software directly and provides a simple model for software to use derived key and identity outputs.

Theory of Operation

Key manager behavior can be summarized by the functional model below.

Key Manager Functional Model

In the diagram, the red boxes represent the working state and the associated internal key, the black ovals represent derivation functions, the green squares represent software inputs, and the remaining green / purple shapes represent outputs to both software and hardware.

In OpenTitan, the derivation method selected is KMAC. Each valid operation involves a KMAC invocation using the key manager working state as the “key” and other HW / SW supplied inputs as data. While KMAC can generate outputs of arbitrary length, this design fixes the size to 256b.

Effectively, the key manager behavior is divided into 3 classes of functions

  • Key manager state advancement

    • The results are never visible to software and not directly usable by any software controlled hardware
  • Output key generation

    • Results can be visible to software or consumed by hardware (sideload)
  • Identity / seed generation

    • Results are always visible to software and used for asymmetric cryptography

In general, the key generation and seed generation functions are identical. They differ only in how software chooses to deploy the outputs.

Key Manager State

The key manager working state (red boxes in the functional model) represents both the current state of the key manager as well as its related secret material. Each valid state (Initialized / CreatorRootKey / OwnerIntermediateKey / OwnerRootKey), supplies its secret material as the “key” input to a KMAC operation. Invalid states, such as Reset / Disabled on the other hand, either do not honor operation requests, or supplies random data when invoked.

The data input is dependent on each state, see below.

Reset

The key manager working state is not directly reset to any value. This ensures there is no deterministic hamming delta upon reset. Instead at reset time, the state value is simply unknown - which is expected to be some biased value the registers settle to based on silicon corner and environment conditions.

To begin operation, the state must first transition to Initialize. The advancement from Reset to Initialized is irreversible during the current power cycle. Until the initialize command is invoked, the key manager rejects all other software commands.

Initialized

When transitioning from Reset to Initialized, random values obtained from the entropy source are used to populate the working state. This ensures that the hamming delta from both the previous value and the next value are both non-deterministic. The advancement from Initialized to CreatorRootKey is irreversible during the current power cycle.

CreatorRootKey

CreatorRootKey is the first operational state of the key manager. When transitioning from Initialized to this state, a KMAC operation is invoked using the RootKey as the key (from OTP), and the remaining inputs as data.

See below:

  • DiversificationKey: Secret seed from flash
  • HealthMeasurement: Current life cycle state
    • To avoid a state value corresponding to each life cycle state, the raw life cycle value is not used.
    • Instead, certain life cycle states diversify the same way.
    • Please see the life cycle controller for more details.
  • DeviceIdentifier: Unique device identification.
  • HardwareRevisionSecret: A global design time constant.

Other than the DiversificationKey, none of the values above are considered secret.

Once the CreatorRootKey is reached, software can request key manager to advance state, generate output key or generate output identity. The key used for all 3 functions is the CreatorRootKey.

The advancement from this state to the next is irreversible during the current power cycle.

OwnerIntermediateKey

This is the second operational state of the key manager. This state is reached through another invocation of the KMAC operation using the previous working state as the key, and other inputs as data. The output of the KMAC operation replaces the previous value of the working state, and the new value becomes the OwnerIntermediateKey.

The relevant data inputs are:

  • OwnerRootSecret: Secret seed from flash.
  • SoftwareBinding: A software programmed value representing the first owner code to be run.

Once the OwnerIntermediateKey is created, software can request key manager to advance state, generate output key or generate output identity. The key used for all 3 functions is the OwnerIntermediateKey.

The advancement from this state to the next is irreversible during the current power cycle.

OwnerRootKey

This is the last operational state of the key manager. This state is reached through another invocation of the KMAC operation using the previous working state as the key, and other inputs as data. The output of the KMAC operation replaces the previous value of the working state, and the new value becomes the OwnerRootKey.

The relevant inputs are:

  • SoftwareBinding - A software programmed value representing the owner kernel code.

Once the OwnerRootKey is created, software can request key manager to advance state, generate output key or generate output identity. An advance command invoked from OwnerRootKey state simply moves the state to Disabled.

The generate output and generate identity functions use OwnerRootKey as the KMAC key. The advancement from this state to the next is irreversible during the current power cycle.

Disabled

Disabled is a state where the key manager is no longer operational. Upon Disabled entry, the working state is updated with KMAC computed random values; however, sideload keys are preserved. This allows the software to keep the last valid sideload keys while preventing the system from further advancing the valid key.

When advance and generate calls are invoked from this state, the outputs and keys are indiscriminately updated with randomly computed values. Key manager enters disabled state based on direct invocation by software:

  • Advance from OwnerRootKey
  • Disable operation

Invalid

Invalid state is entered whenever key manager is disabled through the life cycle connection or when an operation encounters a fault . Upon Invalid entry, both the working state and the sideload keys are wiped with entropy directly. Note, this is different from Disabled state entry, which updates internal key with KMAC outputs but leaves sideload and software keys intact.

Invalid Entry Wiping

Since the life cycle controller can disable the key manager at any time, the key manager attempts to gracefully handle the wiping process. When the disable is seen, the key manager immediately begins wiping all keys (internal key, hardware sideload key, software key) with entropy. However, if an operation was already ongoing, the key manager waits for the transaction to complete gracefully before transitioning to invalid state.

While waiting for the transaction to complete, the key manager continuously wipes all keys with entropy.

Invalid and Disabled State

Note that Invalid and Disabled states are functionally equivalent. The main difference between the two is “how” the state was reached.

Disabled state is reached through intentional software commands. While Invalid state is reached through life cycle disable or operational faults.

This also means that only Invalid is a terminal state. If after entering Disabled life cycle is disabled or a fault is encountered, the same invalid entry procedure is followed to bring the system to a terminal Invalid state.

If ever multiple conditions collide (a fault is detected at the same time software issues disable command), the Invalid entry path always takes precedence.

Life Cycle Connection

The function of the key manager is directly tied to the life cycle controller. During specific life cycle states, the key manager is explicitly invalidated.

When invalidated, the following key manager behavior applies:

  • If the key manager has not been initialized, it cannot be initialized until life cycle enables key manager.
  • If the key manager has been initialized and is currently in a valid state (including Disabled), it immediately wipes its key contents with entropy (working state, sideload keys and software keys) and transitions to Invalid.
    • Note, unlike a normal software requested disable, this path does not gracefully interact with KMAC, instead the secret contents are forcibly wiped.
    • If there is an ongoing transaction with KMAC, the handshake with KMAC is still completed as usual, however the results are discarded and the value sent to KMAC are also not real.
  • Once the system settles to Invalid state, the behavior is consistent with Disabled state.

Commands in Each State

During each state, there are 3 valid commands software can issue:

  • Advance state
  • Output generation
  • Identity generation

The software is able to select a command and trigger the key manager FSM to process one of the commands. If a command is valid during the current working state, it is processed and acknowledged when complete.

If a command is invalid, the behavior depends on the current state. If the current state is Reset, the invalid command is immediately rejected as the key manager FSM has not yet been initialized. If the current state is any other state, the key manager FSM processes with random, dummy data, but does not update working state or relevant output registers. For each valid command, a set of inputs are selected and sequenced to the KMAC module.

During Disable and Invalid states, working state and output registers are updated based on the input commands as with normal states. There are however a few differences:

  • Working state and output registers are updated regardless of any error status to ensure their values are further scrambled.
  • Instead of normal input data, random data is selected for KMAC processing.
  • All operations return an invalid operations error, in addition to any other error that might naturally occur.

Generating Output Key

The generate output command is composed of 2 options

  • Generate output key for software, referred to as generate-output-sw
  • Generate output key for hardware, referred to as generate-output-hw

The hardware option is meant specifically for symmetric side load use cases. When this option is issued, the output of the KMAC invocation is not stored in software visible registers, but instead in hardware registers that directly output to symmetric primitives such as AES, HMAC and KMAC.

KMAC Operations

All invoked KMAC operations expect the key in two shares. This means the working states, even though functionally 256b, are maintained as 512b.

For advance-state and generate-output commands, the KMAC emitted output are also in 2-shares. Software is responsible for determining if the key should be preserved in shares or combined, depending on the use case.

Errors, Faults and Alerts

The key manager has two overall categories of errors:

  • Recoverable errors
  • Fatal errors

Recoverable errors are those likely to have been introduced by software and not fatal to the key manager or the system. Fatal errors are logically impossible errors that have a high likelihood of being a fault and thus fatal.

Each category of error can be further divided into two:

  • Synchronous errors
  • Asynchronous errors

Synchronous errors happen only during a key manager transaction. Asynchronous errors can happen at any time.

Given the above, we have 4 total categories of errors:

  • Synchronous recoverable errors
  • Asynchronous recoverable errors
  • Synchronous fatal errors
  • Asynchronous fatal errors

All recoverable errors (synchronous and asynchronous) are captured in ERR_CODE. All fatal errors (synchronous and asynchronous) are captured in FAULT_STATUS.

Recoverable errors cause a recoverable alert to be sent from the key manager. Fatal errors cause a fatal alert to be sent from the key manager.

Below, the behavior of each category and its constituent errors are described in detail.

Synchronous Recoverable Errors

These errors can only happen when a key manager transaction is invoked and are typically associated with incorrect software programming. At the end of the transaction, key manager reports whether there was an error in ERR_CODE and sends a recoverable alert.

  • ERR_CODE.INVALID_OP Software issued an invalid operation given the current key manager state.
  • ERR_CODE.INVALID_KMAC_INPUT Software supplied invalid input (for example a key greater than the max version) for a key manager operation.

Asynchronous Recoverable Errors

These errors can happen at any time regardless of whether there is a key manager operation. The error is reported in ERR_CODE and the key manager sends a recoverable alert.

Synchronous Fatal Errors

These errors can only happen when a key manager transaction is invoked and receives malformed transaction results that are not logically possible. At the end of the transaction, key manager reports whether there was an error in FAULT_STATUS and continuously sends fatal alerts .

  • ERR_CODE.KMAC_OP KMAC reports a transaction error, this is not possible given current definitions.
  • ERR_CODE.KMAC_OUT KMAC returns all 0’s or all 1’s as a result, this is not possible given current definitions.

Note, these errors are synchronous from the perspective of the key manager, but they may be asynchronous from the perspective of another module.

Asynchronous Fatal Errors

These errors can happen at any time regardless of whether there is a key manager operation. The error is reported in FAULT_STATUS and the key manager continuously sends fatal alerts.

Faults and Operational Faults

Since fatal errors (faults) can happen at any time, their impact on the key manager depends on transaction timing.

If the fault happens while a transaction is ongoing, key manager transitions to the Invalid state.

If the fault happens while there is no transaction, an alert is first sent to the alert handler. If before the alert handler escalates an operation is run, the key manager again transitions to Invalid state. If the alert handler escalates and disables the key manager, then the key manager will also transition to Invalid state if it is not already there.

Example 1: Fault During Operation

The key manager is running a generate operation and a non-onehot command was observed by the kmac interface. Since the non-onehot condition is a fault, it will be reflected in FAULT_STATUS. Since an operation was ongoing when this fault was seen, it will also be reflected in ERR_CODE.INVALID_OP. This is considered an operational fault and begins transition to Invalid.

Example 2: Fault During Idle

The key manager is NOT running an operation and is idle. During this time, a fault was observed on the regfile (shadow storage error) and FSM (control FSM integrity error). The faults will be reflected in FAULT_STATUS.

This is not considered an operational fault and the key manager will remain in its current state until an operation is invoked or the alert handler escalates.

Example 3: Operation after Fault Detection

Continuing from the example above, assume now the key manager begins an operation. Since the key manager has previous encountered a fault, any operation now is considered an operational fault and begins transition to the Invalid state.

Additional Details on Invalid Input

What is considered invalid input changes based on current state and operation.

When an advance operation is invoked:

  • The working state key is checked for all 0’s and all 1’s.
  • During Initialized state, creator seed, device ID and health state data is checked for all 0’s and all 1’s.
  • During CreatorRootKey state, the owner seed is checked for all 0’s and all 1’s.
  • During all other states, nothing is explicitly checked.

When a generate output key operation is invoked:

  • The working state key is checked for all 0’s and all 1’s.
  • The key version is less than or equal to the max key version.

When a generate output identity is invoked:

  • The working state key is checked for all 0’s and all 1’s.

Invalid Operation

The table below enumerates the legal operations in a given state. When an illegal operation is supplied, the error code is updated and the operation is flagged as done with error.

Current State Legal Operations
Reset Advance
Initialized Disable / Advance
CreatorRootKey Disable / Advance / Generate
OwnerIntKey Disable / Advance / Generate
OwnerRootKey Disable / Advance / Generate
Invalid/Disabled None
  • All operations invoked during Invalid and Disabled states lead to invalid operation error.

Error Response

In addition to alerts and interrupts, key manager may also update the working state key and relevant outputs based on current state. See the tables below for an enumeration.

Current State Invalid States Invalid Output Invalid Input Invalid Operation
Reset Not Possible Not Possible Not possible Not updated
Initialized Updated Updated Not updated Not updated
CreatorRootKey Updated Updated Not updated Not possible
OwnerIntKey Updated Updated Not updated Not possible
OwnerRootKey Updated Updated Not updated Not possible
Invalid/Disabled Updated Updated Updated Updated
  • During Reset state, the KMAC module is never invoked, thus certain errors are not possible.
  • During Initialized, CreatorRootKey, OwnerIntermediateKey and OwnerRootKey states, a fault error causes the relevant key / outputs to be updated; however an operational error does not.
  • During Invalid and Disabled states, the relevant key / outputs are updated regardless of the error.
  • Only the relevant collateral is updated -> ie, advance / disable command leads to working key update, and generate command leads to software or sideload key update.
  • During Disabled state, if life cycle is disabled or an operational fault is encountered, the key manager transitions to Invalid state, see here

DICE Support

The key manager supports DICE open profile. Specifically, the open profile has two compound device identifiers.

  • Attestation CDI
  • Sealing CDI

The attestation CDI is used to attest hardware and software configuration and is thus expected to change between updates. The sealing CDI on the other hand, is used to attest the authority of the hardware and softawre configuration. The sealing version is thus expected to remain stable across software updates.

To support these features, the key manager maintains two versions of the working state and associated internal key. There is one version for attestation and one version for sealing.

The main difference between the two CDIs is the different usage of SW_BINDING. For the Sealing CDI, the SEALING_SW_BINDING is used, all other inputs are the same. For the Attestation CDI, the ATTEST_SW_BINDING is used, all other inputs are the same.

When invoking an advance operation, both versions are advanced, one after the other. There are thus two kmac transactions. The first trasnaction uses the Sealing CDI internal key, SEALING_SW_BINDING and other common inputs. The second transaction uses the Attestation CDI internal key, ATTEST_SW_BINDING and other common inputs.

When invoking a generate operation, the software must specify which CDI to use as the source key. This is done through CONTROL.CDI_SEL. Unlike the advance operation, there is only 1 transaction since we pick a specific CDI to operate.

When disabling, both versions are disabled together.

Block Diagram

The following is a high level block diagram of the key manager.

Key Manager Block Diagram

Design Details

Key manager is primarily composed of two components:

  • keymgr_ctrl
  • keymgr_kmac_if

Key Manager Control

The key manager control block manages the working state, sideload key updates, as well as what commands are valid in each state. It also handles the life cycle keymgr_en input, which helps disable the entire key manager function in the event of an escalation.

Key Manager Control Block Diagram

KMAC Interface Control

The KMAC interface control represents the bulk of key manager logic. Based on input from key manager control, this module selects the inputs for each given command and sequences the data to KMAC.

Key Manager KMAC Interface Block Diagram

The KMAC interafce works on a simple valid / ready protocol. When there is data to send, the KMAC interface sends out a valid and keeps it active. When the destination accepts the transaction, the ready is asserted. Note just like with any bus interface, the ready may already be asserted when valid asserts, or it may assert some time later, there are no restrictions. Since the data to be sent is always pre-buffered in key manager, the valid once asserts, never de-asserts until the entire transaction is complete.

The data interface itself is 64b wide. However, there may not always be 64b multiple aligned data to be sent. In these situations, the last transfer beat sent to KMAC has a byte mask / strobe attached. The byte mask indicates on the last beat which bytes are actually valid, and which are not. Not beats prior to the last always have fully asserted byte masks.

Once KMAC receives all the required data and the last indication, it begins processing the data into a digest. This process may take an arbitrary number of cycles. When this process is complete, a done indication pulse is sent back with the digest. Note, the acceptance of done has no back-pressure and keymgr must accept it within one cycle.

See diagram below for an example transfer:

Side Load Keys

There are three sideload keys. One for AES, one for HMAC, and one for KMAC. When a sideload key is generated successfully through the generate-output-hw command, the derived data is loaded into key storage registers. There is a set of storage registers for each destination.

The KMAC key however is further overloaded as it is the main derivation mechanism for key manager internal stage. The KMAC key thus has two possible outputs, one is the sideload key, and the other is internal state key.

When a valid operation is called, the internal state key is sent over the KMAC key. During all other times, the sideloaded value is presented. Note, there may not be a valid key in the sideload register if it has been cleared or never generated. The sideload key can be overwritten with another generate command, or cleared with entropy through SIDELOAD_CLEAR.

The clearing can be done one slot at a time, or all at once.

The following diagram illustrates an example when there is no valid key in the KMAC sideload registers and an operation is called. During the duration of the operation, the key is valid and shows the internal key state. Once the operation is complete, it falls back to the sideload key state, which is invalid in this case.

The following diagram illustrates an example when there is a valid key in the KMAC sideload registers and an operation is called. During the duration of the operation, the key is valid and shows the internal key state. Once the operation is complete, it falls back to the sideload key state, which is valid and contains a different value.

Software Binding

The identities flow employs an idea called software binding to ensure that a particular key derivation scheme is only reproducible for a given software configuration. The binding is created through the secure boot flow, where each stage sets the binding used for the next verified stage before advancing to it. The software binding is used during the following state transitions only:

  • Initialized to CreatorRootKey
  • CreatorRootKey to OwnerIntermedaiteKey
  • OwnerIntermediateKey to OwnerRootKey

In order to save on storage and not have a duplicate copy per stage, the software binding registers SOFTWARE_BINDING are shared between key manager stages.

Software sets the appropriate values and locks it by clearing SOFT_BINDING_EN. When later a successful advance call is made, the key manager then unlocks by setting SOFT_BINDING_EN to 1. An unsuccessful advance call (errors) does not unlock the binding. This allows the next stage of software to re-use the binding registers.

Hardware Interfaces

Referring to the Comportable guideline for peripheral device functionality, the module KEYMGR has the following hardware interfaces defined.

Primary Clock: clk_i

Other Clocks: clk_edn_i

Bus Device Interfaces (TL-UL): tl

Bus Host Interfaces (TL-UL): none

Peripheral Pins for Chip IO: none

Interrupts:

Interrupt NameDescription
op_done

Operation complete

Security Alerts:

Alert NameDescription
fatal_fault_err

Alert for key manager faults. These errors cannot be caused by software

recov_operation_err

Alert for key manager operation errors. These errors could have been caused by software

Programmers Guide

Initialize

Advance or Generate

Software selects a command and triggers a “start”. If the command is valid and successful, key manager indicates done and no errors. If the command is invalid or unsuccessful, key manager indicates done with error. Regardless of the validity of the command, the hardware sequences are triggered to avoid leaking timing information.

The software is able to read the current state of key manager, however it never has access to the associated internal key.

When issuing the generate-output-hw command, software must select a destination primitive (aes, hmac or kmac). At the conclusion of the command, key and valid signals are forwarded by the key manager to the selected destination primitive. The key and valid signals remain asserted to the selected destination until software explicitly disables the output via another command, or issues another generate-output-hw command with a different destination primitive.

More details to come.

Register Table

KEYMGR.INTR_STATE @ 0x0

Interrupt State Register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  op_done
BitsTypeResetNameDescription
0rw1c0x0op_done

Operation complete


KEYMGR.INTR_ENABLE @ 0x4

Interrupt Enable Register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  op_done
BitsTypeResetNameDescription
0rw0x0op_done

Enable interrupt when INTR_STATE.op_done is set.


KEYMGR.INTR_TEST @ 0x8

Interrupt Test Register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  op_done
BitsTypeResetNameDescription
0wo0x0op_done

Write 1 to force INTR_STATE.op_done to 1.


KEYMGR.ALERT_TEST @ 0xc

Alert Test Register

Reset default = 0x0, mask 0x3
31302928272625242322212019181716
 
1514131211109876543210
  recov_operation_err fatal_fault_err
BitsTypeResetNameDescription
0wo0x0fatal_fault_err

Write 1 to trigger one alert event of this kind.

1wo0x0recov_operation_err

Write 1 to trigger one alert event of this kind.


KEYMGR.CFG_REGWEN @ 0x10

Key manager configuration enable

Reset default = 0x1, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  EN
BitsTypeResetNameDescription
0ro0x1EN

key manager configuration enable. When key manager operation is started (see CONTROL), registers protected by this EN are no longer modifiable until the operation completes.

TBD This should be enhanced to support multi-bit values in the future. Should be another script change.


KEYMGR.CONTROL @ 0x14

Key manager operation controls

Reset default = 0x10, mask 0x70f1
Register enable = CFG_REGWEN
31302928272625242322212019181716
 
1514131211109876543210
  DEST_SEL   CDI_SEL OPERATION   START
BitsTypeResetNameDescription
0rw0x0START

Start key manager operations

1Valid state

To trigger a start, this value must be programmed. All other values are considered no operation start.

Other values are reserved.

3:1Reserved
6:4rw0x1OPERATION

Key manager operation selection. All values not enumerated below behave the same as disable

0Advance

Advance key manager state.

Advances key manager to the next stage. If key manager is already at last functional state, the advance operation is equivalent to the disable operation.

1Generate ID

Generates an identity seed from the current state.

2Generate SW Output

Generates a key manager output that is visible to software from the current state.

3Generate HW Output

Generates a key manager output that is visible only to hardware crypto blocks.

4Disable

Disables key manager operation and moves it to the disabled state.

Note the disabled state is terminal and cannot be recovered without a reset.

Other values are reserved.

7rw0x0CDI_SEL

When the OPERATION field is programmed to generate output, this field selects the appropriate CDI to use.

This field should be programmed for both hw / sw generation.

0Sealing CDI

Sealing CDI is selected

1Attestation CDI

Attestation CDI is selected

11:8Reserved
14:12rw0x0DEST_SEL

When the OPERATION field is programmed to generate output, this field selects the appropriate crypto cipher target.

This field should be programmed for both hw / sw generation, as this helps diverisifies the output.

0None

No target selected

1AES

AES selected

2KMAC

KMAC selected

3OTBN

OTBN selected. Note for OTBN hardware operations, the generated output is 384-bits, while for all other operations (including OTBN software), it is 256-bits.

Generating a hardware 384-bit seed directly for OTBN sideload reduces some of the OTBN code burden for entropy expansion. When generating for software, this is not a concern.

Other values are reserved.


KEYMGR.SIDELOAD_CLEAR @ 0x18

sideload key slots clear

Reset default = 0x0, mask 0x7
Register enable = CFG_REGWEN
31302928272625242322212019181716
 
1514131211109876543210
  VAL
BitsTypeResetNameDescription
2:0rw0x0VAL

Depending on the value programmed, a different side load key slot is cleared. If the value programmed is not one of the enumerated values below, ALL side load key slots are continuously cleared.

0None

No sideload keys cleared.

1AES

The AES sideload key is continuously cleared with entropy.

2KMAC

The KMAC sideload key is continuously cleared with entropy.

3OTBN

The OTBN sideload key is continuously cleared with entropy.

Other values are reserved.


KEYMGR.RESEED_INTERVAL_REGWEN @ 0x1c

regwen for reseed interval

Reset default = 0x1, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  EN
BitsTypeResetNameDescription
0rw0c0x1EN

Configuration enable for reseed interval


KEYMGR.RESEED_INTERVAL_SHADOWED @ 0x20

Reseed interval for key manager entropy reseed

Reset default = 0x100, mask 0xffff
Register enable = RESEED_INTERVAL_REGWEN
31302928272625242322212019181716
 
1514131211109876543210
VAL
BitsTypeResetNameDescription
15:0rw0x100VAL

Number of key manager cycles before the entropy is reseeded


KEYMGR.SW_BINDING_REGWEN @ 0x24

Register write enable for SOFTWARE_BINDING

Reset default = 0x1, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  EN
BitsTypeResetNameDescription
0rw0c0x1EN

Software binding register write enable. This is locked by software and unlocked by hardware upon a successful advance call.

Software binding resets to 1, and its value cannot be altered by software until advancement to Init state.


KEYMGR.SEALING_SW_BINDING_0 @ 0x28

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_0...
1514131211109876543210
...VAL_0
BitsTypeResetNameDescription
31:0rw0x0VAL_0

Software binding value


KEYMGR.SEALING_SW_BINDING_1 @ 0x2c

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_1...
1514131211109876543210
...VAL_1
BitsTypeResetNameDescription
31:0rw0x0VAL_1

For KEYMGR1


KEYMGR.SEALING_SW_BINDING_2 @ 0x30

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_2...
1514131211109876543210
...VAL_2
BitsTypeResetNameDescription
31:0rw0x0VAL_2

For KEYMGR2


KEYMGR.SEALING_SW_BINDING_3 @ 0x34

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_3...
1514131211109876543210
...VAL_3
BitsTypeResetNameDescription
31:0rw0x0VAL_3

For KEYMGR3


KEYMGR.SEALING_SW_BINDING_4 @ 0x38

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_4...
1514131211109876543210
...VAL_4
BitsTypeResetNameDescription
31:0rw0x0VAL_4

For KEYMGR4


KEYMGR.SEALING_SW_BINDING_5 @ 0x3c

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_5...
1514131211109876543210
...VAL_5
BitsTypeResetNameDescription
31:0rw0x0VAL_5

For KEYMGR5


KEYMGR.SEALING_SW_BINDING_6 @ 0x40

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_6...
1514131211109876543210
...VAL_6
BitsTypeResetNameDescription
31:0rw0x0VAL_6

For KEYMGR6


KEYMGR.SEALING_SW_BINDING_7 @ 0x44

Software binding input to sealing portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_7...
1514131211109876543210
...VAL_7
BitsTypeResetNameDescription
31:0rw0x0VAL_7

For KEYMGR7


KEYMGR.ATTEST_SW_BINDING_0 @ 0x48

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_0...
1514131211109876543210
...VAL_0
BitsTypeResetNameDescription
31:0rw0x0VAL_0

Software binding value


KEYMGR.ATTEST_SW_BINDING_1 @ 0x4c

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_1...
1514131211109876543210
...VAL_1
BitsTypeResetNameDescription
31:0rw0x0VAL_1

For KEYMGR1


KEYMGR.ATTEST_SW_BINDING_2 @ 0x50

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_2...
1514131211109876543210
...VAL_2
BitsTypeResetNameDescription
31:0rw0x0VAL_2

For KEYMGR2


KEYMGR.ATTEST_SW_BINDING_3 @ 0x54

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_3...
1514131211109876543210
...VAL_3
BitsTypeResetNameDescription
31:0rw0x0VAL_3

For KEYMGR3


KEYMGR.ATTEST_SW_BINDING_4 @ 0x58

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_4...
1514131211109876543210
...VAL_4
BitsTypeResetNameDescription
31:0rw0x0VAL_4

For KEYMGR4


KEYMGR.ATTEST_SW_BINDING_5 @ 0x5c

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_5...
1514131211109876543210
...VAL_5
BitsTypeResetNameDescription
31:0rw0x0VAL_5

For KEYMGR5


KEYMGR.ATTEST_SW_BINDING_6 @ 0x60

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_6...
1514131211109876543210
...VAL_6
BitsTypeResetNameDescription
31:0rw0x0VAL_6

For KEYMGR6


KEYMGR.ATTEST_SW_BINDING_7 @ 0x64

Software binding input to the attestation portion of the key manager. This register is lockable and shared between key manager stages. This binding value is not considered secret, however its integrity is very important.

Reset default = 0x0, mask 0xffffffff
Register enable = SW_BINDING_REGWEN

The software binding is locked by software and unlocked by hardware upon a successful advance operation.

31302928272625242322212019181716
VAL_7...
1514131211109876543210
...VAL_7
BitsTypeResetNameDescription
31:0rw0x0VAL_7

For KEYMGR7


KEYMGR.Salt_0 @ 0x68

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_0...
1514131211109876543210
...VAL_0
BitsTypeResetNameDescription
31:0rw0x0VAL_0

Salt value


KEYMGR.Salt_1 @ 0x6c

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_1...
1514131211109876543210
...VAL_1
BitsTypeResetNameDescription
31:0rw0x0VAL_1

For KEYMGR1


KEYMGR.Salt_2 @ 0x70

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_2...
1514131211109876543210
...VAL_2
BitsTypeResetNameDescription
31:0rw0x0VAL_2

For KEYMGR2


KEYMGR.Salt_3 @ 0x74

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_3...
1514131211109876543210
...VAL_3
BitsTypeResetNameDescription
31:0rw0x0VAL_3

For KEYMGR3


KEYMGR.Salt_4 @ 0x78

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_4...
1514131211109876543210
...VAL_4
BitsTypeResetNameDescription
31:0rw0x0VAL_4

For KEYMGR4


KEYMGR.Salt_5 @ 0x7c

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_5...
1514131211109876543210
...VAL_5
BitsTypeResetNameDescription
31:0rw0x0VAL_5

For KEYMGR5


KEYMGR.Salt_6 @ 0x80

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_6...
1514131211109876543210
...VAL_6
BitsTypeResetNameDescription
31:0rw0x0VAL_6

For KEYMGR6


KEYMGR.Salt_7 @ 0x84

Salt value used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_7...
1514131211109876543210
...VAL_7
BitsTypeResetNameDescription
31:0rw0x0VAL_7

For KEYMGR7


KEYMGR.KEY_VERSION @ 0x88

Version used as part of output generation

Reset default = 0x0, mask 0xffffffff
Register enable = CFG_REGWEN
31302928272625242322212019181716
VAL_0...
1514131211109876543210
...VAL_0
BitsTypeResetNameDescription
31:0rw0x0VAL_0

Salt value


KEYMGR.MAX_CREATOR_KEY_VER_REGWEN @ 0x8c

Register write enable for MAX_CREATOR_KEY_VERSION

Reset default = 0x1, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  EN
BitsTypeResetNameDescription
0rw0c0x1EN

MAX_CREATOR_KEY_VERSION configure enable. All values except for 2 are interpreted as configuration disable.


KEYMGR.MAX_CREATOR_KEY_VER_SHADOWED @ 0x90

Max creator key version

Reset default = 0x0, mask 0xffffffff
Register enable = MAX_CREATOR_KEY_VER_REGWEN
31302928272625242322212019181716
VAL...
1514131211109876543210
...VAL
BitsTypeResetNameDescription
31:0rw0x0VAL

Max key version.

Any key version up to the value specificed in this register is valid.


KEYMGR.MAX_OWNER_INT_KEY_VER_REGWEN @ 0x94

Register write enable for MAX_OWNER_INT_KEY_VERSION

Reset default = 0x1, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  EN
BitsTypeResetNameDescription
0rw0c0x1EN

MAX_OWNER_INTERMEDIATE_KEY configure enable. All values except for 2 are interpreted as configuration disable.


KEYMGR.MAX_OWNER_INT_KEY_VER_SHADOWED @ 0x98

Max owner intermediate key version

Reset default = 0x1, mask 0xffffffff
Register enable = MAX_OWNER_INT_KEY_VER_REGWEN
31302928272625242322212019181716
VAL...
1514131211109876543210
...VAL
BitsTypeResetNameDescription
31:0rw0x1VAL

Max key version.

Any key version up to the value specificed in this register is valid.


KEYMGR.MAX_OWNER_KEY_VER_REGWEN @ 0x9c

Register write enable for MAX_OWNER_KEY_VERSION

Reset default = 0x1, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  EN
BitsTypeResetNameDescription
0rw0c0x1EN

MAX_OWNER_KEY configure enable. All values except for 2 are interpreted as configuration disable.


KEYMGR.MAX_OWNER_KEY_VER_SHADOWED @ 0xa0

Max owner key version

Reset default = 0x0, mask 0xffffffff
Register enable = MAX_OWNER_KEY_VER_REGWEN
31302928272625242322212019181716
VAL...
1514131211109876543210
...VAL
BitsTypeResetNameDescription
31:0rw0x0VAL

Max key version.

Any key version up to the value specificed in this register is valid.


KEYMGR.SW_SHARE0_OUTPUT_0 @ 0xa4

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_0...
1514131211109876543210
...VAL_0
BitsTypeResetNameDescription
31:0rc0x0VAL_0

Software output value


KEYMGR.SW_SHARE0_OUTPUT_1 @ 0xa8

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_1...
1514131211109876543210
...VAL_1
BitsTypeResetNameDescription
31:0rc0x0VAL_1

For KEYMGR1


KEYMGR.SW_SHARE0_OUTPUT_2 @ 0xac

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_2...
1514131211109876543210
...VAL_2
BitsTypeResetNameDescription
31:0rc0x0VAL_2

For KEYMGR2


KEYMGR.SW_SHARE0_OUTPUT_3 @ 0xb0

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_3...
1514131211109876543210
...VAL_3
BitsTypeResetNameDescription
31:0rc0x0VAL_3

For KEYMGR3


KEYMGR.SW_SHARE0_OUTPUT_4 @ 0xb4

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_4...
1514131211109876543210
...VAL_4
BitsTypeResetNameDescription
31:0rc0x0VAL_4

For KEYMGR4


KEYMGR.SW_SHARE0_OUTPUT_5 @ 0xb8

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_5...
1514131211109876543210
...VAL_5
BitsTypeResetNameDescription
31:0rc0x0VAL_5

For KEYMGR5


KEYMGR.SW_SHARE0_OUTPUT_6 @ 0xbc

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_6...
1514131211109876543210
...VAL_6
BitsTypeResetNameDescription
31:0rc0x0VAL_6

For KEYMGR6


KEYMGR.SW_SHARE0_OUTPUT_7 @ 0xc0

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_7...
1514131211109876543210
...VAL_7
BitsTypeResetNameDescription
31:0rc0x0VAL_7

For KEYMGR7


KEYMGR.SW_SHARE1_OUTPUT_0 @ 0xc4

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_0...
1514131211109876543210
...VAL_0
BitsTypeResetNameDescription
31:0rc0x0VAL_0

Software output value


KEYMGR.SW_SHARE1_OUTPUT_1 @ 0xc8

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_1...
1514131211109876543210
...VAL_1
BitsTypeResetNameDescription
31:0rc0x0VAL_1

For KEYMGR1


KEYMGR.SW_SHARE1_OUTPUT_2 @ 0xcc

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_2...
1514131211109876543210
...VAL_2
BitsTypeResetNameDescription
31:0rc0x0VAL_2

For KEYMGR2


KEYMGR.SW_SHARE1_OUTPUT_3 @ 0xd0

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_3...
1514131211109876543210
...VAL_3
BitsTypeResetNameDescription
31:0rc0x0VAL_3

For KEYMGR3


KEYMGR.SW_SHARE1_OUTPUT_4 @ 0xd4

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_4...
1514131211109876543210
...VAL_4
BitsTypeResetNameDescription
31:0rc0x0VAL_4

For KEYMGR4


KEYMGR.SW_SHARE1_OUTPUT_5 @ 0xd8

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_5...
1514131211109876543210
...VAL_5
BitsTypeResetNameDescription
31:0rc0x0VAL_5

For KEYMGR5


KEYMGR.SW_SHARE1_OUTPUT_6 @ 0xdc

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_6...
1514131211109876543210
...VAL_6
BitsTypeResetNameDescription
31:0rc0x0VAL_6

For KEYMGR6


KEYMGR.SW_SHARE1_OUTPUT_7 @ 0xe0

Key manager software output.

Reset default = 0x0, mask 0xffffffff

When a software output operation is selected, the results of the operation are placed here.

31302928272625242322212019181716
VAL_7...
1514131211109876543210
...VAL_7
BitsTypeResetNameDescription
31:0rc0x0VAL_7

For KEYMGR7


KEYMGR.WORKING_STATE @ 0xe4

Key manager working state.

Reset default = 0x0, mask 0x7

This is a readout of the current key manager working state

31302928272625242322212019181716
 
1514131211109876543210
  STATE
BitsTypeResetNameDescription
2:0ro0x0STATE

Key manager control state

0Reset

Key manager control is still in reset. Please wait for initialization complete before issuing operations

1Init

Key manager control has finished initialization and will now accept software commands.

2Creator Root Key

Key manager control currently contains the creator root key.

3Owner Intermediate Key

Key manager control currently contains the owner intermediate key.

4Owner Key

Key manager control currently contains the owner key.

5Disabled

Key manager currently disabled. Please reset the key manager. Sideload keys are still valid.

6Invalid

Key manager currently invalid. Please reset the key manager. Sideload keys are no longer valid.

Other values are reserved.


KEYMGR.OP_STATUS @ 0xe8

Key manager status.

Reset default = 0x0, mask 0x3

Hardware sets the status based on software initiated operations. This register must be explicitly cleared by software. Software clears by writing back whatever it reads.

31302928272625242322212019181716
 
1514131211109876543210
  STATUS
BitsTypeResetNameDescription
1:0rw1c0x0STATUS

Operation status.

0Idle

Key manager is idle

1WIP

Work in progress. A key manager operation has been started and is ongoing

2DONE_SUCCESS

Operation finished without errors

3DONE_ERROR

Operation finished with errors, please see ERR_CODE register.


KEYMGR.ERR_CODE @ 0xec

Key manager error code. This register must be explicitly cleared by software.

Reset default = 0x0, mask 0x7

This register represents both synchronous and asynchronous recoverable errors.

Synchronous errors refer to those that only happen when a keymgr operation is invoked, while asynchronous refers to errors that can happen at any time.

31302928272625242322212019181716
 
1514131211109876543210
  INVALID_SHADOW_UPDATE INVALID_KMAC_INPUT INVALID_OP
BitsTypeResetNameDescription
0rw1c0x0INVALID_OP

Invalid operation issued to key manager, synchronous error

1rw1c0x0INVALID_KMAC_INPUT

Invalid data issued to kmac interface, synchronous error

2rw1c0x0INVALID_SHADOW_UPDATE

An error observed during shadow register updates, asynchronous error


KEYMGR.FAULT_STATUS @ 0xf0

This register represents both synchronous and asynchronous fatal faults.

Reset default = 0x0, mask 0x3ff

Synchronous faults refer to those that only happen when a keymgr operation is invoked, while asynchronous refers to faults that can happen at any time.

31302928272625242322212019181716
 
1514131211109876543210
  SIDE_CTRL_FSM RESEED_CNT CTRL_FSM_CNT CTRL_FSM_INTG SHADOW REGFILE_INTG KMAC_OUT KMAC_OP KMAC_FSM CMD
BitsTypeResetNameDescription
0ro0x0CMD

A non-onehot command was seen in kmac, asynchronous fault.

1ro0x0KMAC_FSM

The kmac transfer interface is in an error state, asynchronous fault.

2ro0x0KMAC_OP

KMAC reported an error during keymgr usage, this should never happen - synchronous fault.

3ro0x0KMAC_OUT

KMAC data returned as all 0's or all 1's - synchronous fault

4ro0x0REGFILE_INTG

Register file integrity error, asynchronous fault

5ro0x0SHADOW

Shadow copy storage error, asynchronous fault

6ro0x0CTRL_FSM_INTG

Control FSM integrity error, asynchronous fault

7ro0x0CTRL_FSM_CNT

Control FSM counter integrity error, asynchronous fault

8ro0x0RESEED_CNT

Reseed counter integrity error, asynchronous fault

9ro0x0SIDE_CTRL_FSM

Sideload control FSM integrity error, asynchronous fault