AES HWIP Technical Specification

Overview

This document specifies the AES hardware IP functionality. Advanced Encryption Standard (AES) is the primary symmetric encryption and decryption mechanism used in OpenTitan protocols. The AES unit is a cryptographic accelerator that accepts requests from the processor to encrypt or decrypt 16 byte blocks of data. It is attached to the chip interconnect bus as a peripheral module and conforms to the Comportable guideline for peripheral functionality.

Features

The AES unit supports the following features:

  • Encryption/Decryption using AES-128/192/256 in the following cipher block modes:
    • Electronic Codebook (ECB) mode,
    • Cipher Block Chaining (CBC) mode,
    • Cipher Feedback (CFB) mode (fixed data segment size of 128 bits, i.e., CFB-128),
    • Output Feedback (OFB) mode, and
    • Counter (CTR) mode.
  • Support for AES-192 can be removed to save area, and is enabled/disabled using a compile-time Verilog parameter
  • First-order masking of the cipher core using domain-oriented masking (DOM) to aggravate side-channel analysis (SCA), can optionally be disabled using compile-time Verilog parameters (for more details see Security Hardening below)
  • Latency per 16 byte data block of 12/14/16 clock cycles (unmasked implementation) and 56/66/72 clock cycles (DOM) in AES-128/192/256 mode
  • Countermeasures for aggravating fault injection (FI) on the control path (for more details see Security Hardening below)
  • Register-based data and control interface
  • On-the-fly round-key generation in parallel to the actual encryption/decryption from a single initial 128/192/256-bit key provided through the register interface (for more details see Theory of Operations below)

This AES unit targets medium performance (16 parallel S-Boxes, ~1 cycle per round for the unmasked implementation, ~5 cycles per round for the DOM implementation). High-speed, single-cycle operation for high-bandwidth data streaming is not required.

Cipher modes other than ECB, CBC, CFB, OFB and CTR are beyond this version of the AES unit but might be supported in future versions.

Description

The AES unit is a cryptographic accelerator that accepts requests from the processor to encrypt or decrypt 16B blocks of data. It supports AES-128/192/256 in Electronic Codebook (ECB) mode, Cipher Block Chaining (CBC) mode, Cipher Feedback (CFB) mode (fixed data segment size of 128 bits, i.e., CFB-128), Output Feedback (OFB) mode and Counter (CTR) mode. For more information on these cipher modes, refer to Recommendation for Block Cipher Modes of Operation. Other cipher modes might be added in future versions.

The AES unit is attached to the chip interconnect bus as a peripheral module. Communication with the processor happens through a set of control and status registers (CSRs). This includes input/output data and key, as well as status and control information. Future versions of the AES unit might include a separate interface through which a possible system key manager can provide the key without exposing it to the processor or other hosts attached to the system bus interconnect.

Theory of Operations

The AES unit supports both encryption and decryption for AES-128/192/256 in ECB, CBC, CFB, OFB and CTR modes using a single, shared data path. That is, it can either do encryption or decryption but not both at the same time.

The AES unit features a key expanding mechanism to generate the required round keys on-the-fly from a single initial key provided through the register interface. This means the processor needs to provide just the initial encryption key to the AES unit via register interface. The AES unit then uses this key to generate all round keys as they are needed in parallel to the actual encryption/decryption. The benefits of this design compared to passing all round keys via register interface include:

  • Reduced storage requirements and smaller circuit area: Instead of storing 15 128-bit round keys, only 3 256-bit key registers are required for AES-256:
    • one set of registers to which the processor writes the initial key, i.e., the start key for encryption,
    • one set of registers to hold the current full key, and
    • one set of registers to hold the full key of the last encryption round, i.e., the start key for decryption.
  • Faster re-configuration and key switching: The core just needs to perform 8 write operations instead of 60 write operations for AES-256.

On-the-fly round-key generation comes however at the price of an initial delay whenever the key is changed by the processor before the AES unit can perform ECB/CBC decryption using this new key. During this phase, the key expanding mechanism iteratively computes the start key for the decryption. The duration of this delay phase corresponds to the latency required for encrypting one 16B block (i.e., 12/14/16 cycles for AES-128/192/256). Once the start key for decryption has been computed, it is stored in a dedicated internal register for later use. The AES unit can then switch between decryption and encryption without additional overhead.

For encryption or if the mode is set to CFB, OFB or CTR, there is no such initial delay upon changing the key. If the next operation after a key switch is ECB or CBC decryption, the AES unit automatically initiates a key expansion using the key schedule first (to generate the start key for decryption, the actual data path remains idle during that phase).

The AES unit uses a status register to indicate to the processor when ready to receive the next input data block via the register interface. While the AES unit is performing encryption/decryption of a data block, it is safe for the processor to provide the next input data block. The AES unit automatically starts the encryption/decryption of the next data block once the previous encryption/decryption is finished and new input data is available. The order in which the input registers are written does not matter. Every input register must be written at least once for the AES unit to automatically start encryption/decryption. This is the default behavior. It can be disabled by setting the MANUAL_OPERATION bit in CTRL_SHADOWED to 1. In this case, the AES unit only starts the encryption/decryption once the START bit in TRIGGER is set to 1 (automatically cleared to 0 once the next encryption/decryption is started).

Similarly, the AES unit indicates via a status register when having new output data available to be read by the processor. Also, there is a back-pressure mechanism for the output data. If the AES unit wants to finish the encryption/decryption of a data block but the previous output data has not yet been read by the processor, the AES unit is stalled. It hangs and does not drop data. It only continues once the previous output data has been read and the corresponding registers can be safely overwritten. The order in which the output registers are read does not matter. Every output register must be read at least once for the AES unit to continue. This is the default behavior. It can be disabled by setting the MANUAL_OPERATION bit in CTRL_SHADOWED to 1. In this case, the AES unit never stalls and just overwrites previous output data, independent of whether it has been read or not.

Block Diagram

This AES unit targets medium performance (~1 cycle per round for the unmasked implementation). High-speed, single-cycle operation for high-bandwidth data streaming is not required.

Therefore, the AES unit uses an iterative cipher core architecture with a 128-bit wide data path as shown in the figure below. Note that for the sake of simplicity, the figure shows the unmasked implementation. For details on the masked implementation of the cipher core refer to Security Hardening below). Using an iterative architecture allows for a smaller circuit area at the cost of throughput. Employing a 128-bit wide data path allows to achieve the latency requirements of 12/14/16 clock cycles per 16B data block in AES-128/192/256 mode in the unmasked implementation, respectively.

AES unit block diagram (unmasked implementation) with shared data paths for encryption and decryption (using the Equivalent Inverse Cipher).

Inside the cipher core, both the data paths for the actual cipher (left) and the round key generation (right) are shared between encryption and decryption. Consequently, the blocks shown in the diagram always implement the forward and backward (inverse) version of the corresponding operation. For example, SubBytes implements both SubBytes and InvSubBytes.

Besides the actual AES cipher core, the AES unit features a set of control and status registers (CSRs) accessible by the processor via TL-UL bus interface, and a counter module (used in CTR mode only). This counter module implements the Standard Incrementing Function according to Recommendation for Block Cipher Modes of Operation (Appendix B.1) with a fixed parameter m = 128. Note that for AES, parameter b = 128 and the counter increment is big-endian. CFB mode is supported with a fixed parameter s = 128 (CFB-128). Support for data segment sizes other than 128 bits would require a substantial amount of additional muxing resources and is thus not provided. The initialization vector (IV) register and the register to hold the previous input data are used in CBC, CFB, OFB and CTR modes only.

Hardware Interfaces

Referring to the Comportable guideline for peripheral device functionality, the module aes 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: none

Security Alerts:

Alert NameDescription
recov_ctrl_update_err

This recoverable alert is triggered upon detecting an update error in the shadowed Control Register. The content of the Control Register is not modified (See Control Register). The AES unit can be recovered from such a condition by restarting the AES operation, i.e., by re-writing the Control Register. This should be monitored by the system.

fatal_fault

This fatal alert is triggered upon detecting a fatal fault inside the AES unit. Examples for such faults include i) storage errors in the shadowed Control Register, ii) any internal FSM entering an invalid state, iii) any sparsely encoded signal taking on an invalid value, iv) errors in the internal round counter, and v) escalations triggered by the life cycle controller. The AES unit cannot recover from such an error and needs to be reset.

The table below lists other signals of the AES unit.

Signal Direction Type Description
idle_o output logic Idle indication signal for clock manager.
lc_escalate_en_i input lc_ctrl_pkg::lc_tx_t Life cycle escalation enable coming from life cycle controller. This signal moves the main controller FSM within the AES unit into the terminal error state. The AES unit needs to be reset.
edn_o output edn_pkg::edn_req_t Entropy request to entropy distribution network (EDN) for reseeding internal pseudo-random number generators (PRNGs) used for register clearing and masking.
edn_i input edn_pkg::edn_rsp_t EDN acknowledgment and entropy input for reseeding internal PRNGs.

Note that the edn_o and edn_i signals used to interface EDN follow a REQ/ACK protocol. The entropy distributed by EDN is obtained from the cryptographically secure random number generator (CSRNG).

Design Details

This section discusses different design details of the AES module.

Datapath Architecture and Operation

The AES unit implements the Equivalent Inverse Cipher described in the AES specification. This allows for more efficient cipher data path sharing between encryption/decryption as the operations are applied in the same order (less muxes, simpler control), but requires the round key during decryption to be transformed using an inverse MixColumns in all rounds except for the first and the last one.

This architectural choice targets at efficient cipher data path sharing and low area footprint. Depending on the application scenario, other architectures might offer a more suitable area/performance tradeoff. For example if only CFB, OFB or CTR modes are ever used, the inverse cipher is not used at all. Moreover, if the key is changed extremely rarely (as for example in the case of bulk decryption), it may pay off to store all round keys instead of generating them on the fly. Future versions of the AES unit might offer compile-time parameters to selectively instantiate the forward/inverse cipher part only to allow for dedicated encryption/decryption-only units.

All submodules in the data path are purely combinational. The only sequential logic in the cipher and round key generation are the State, Full Key and Decryption Key registers.

The following description explains how the AES unit operates, i.e., how the operation of the AES cipher is mapped to the datapath architecture of the AES unit. Phrases in italics apply to peculiarities of different block cipher modes. For a general introduction into these cipher modes, refer to Recommendation for Block Cipher Modes of Operation.

  1. The configuration and initial key is provided to the AES unit via a set of control and status registers (CSRs) accessible by the processor via TL-UL bus interface. The processor must first provide the configuration to the CTRL_SHADOWED register. Then follows the initial key. Each key register must be written at least once. The order in which the registers are written does not matter.

  2. The processor provides the initialization vector (IV) or initial counter value to the four IV registers via TL-UL bus interface in CBC, CFB and OFB modes, or CTR mode, respectively. Each IV register must be written at least once. The order in which the registers are written does not matter. Note that while operating, the AES unit automatically updates the IV registers after having consumed the current IV value. Whenever a new message is started, the processor must provide the corresponding IV value via TL-UL bus interface. In ECB mode, no IV needs to be provided. The content of the IV registers is ignored in ECB mode.

  3. The input data is provided to the AES unit via four CSRs. Each input register must be written at least once. The order in which the registers are written does not matter.

  4. If new input data is available, the AES unit automatically starts encryption/decryption by performing the following actions.

    1. The AES unit loads initial state into the State register inside the cipher core.

      Depending on the cipher mode, the initial state is a combination of input data as well as IV. Note, if CBC decryption is performed, or if running in CFB, OFB or CTR mode, the input data is also registered (Data In Prev in the block diagram).

    2. The initial key is loaded into the Full Key register inside the cipher core.

      Note, if the ECB/CBC decryption is performed, the Full Key register is loaded with the value stored in the Decryption Key register.

    Note, for the AES unit to automatically start in CBC, CFB, OFB or CTR mode, also the IV must be ready. The IV is ready if – since the last IV update (either done by the processor or the AES unit itself) – all IV registers have been written at least once or none of them. The AES unit will not automatically start the next encryption/decryption with a partially updated IV.

    By setting the MANUAL_OPERATION bit in CTRL_SHADOWED to 1, the AES unit can be operated in manual mode. In manual mode, the AES unit starts encryption/decryption whenever the START bit in TRIGGER is set to 1, irrespective of the status of the IV and input data registers.

  5. Once the State and Full Key registers have been loaded, the AES cipher core starts the encryption/decryption by adding the first round key to the initial state (all blocks in both data paths are bypassed). The result is stored back in the State register.

  6. Then, the AES cipher core performs 9/11/13 rounds of encryption/decryption when using a 128/192/256-bit key, respectively. In every round, the cipher data path performs the four following transformations. For more details, refer to the AES specification.

    1. SubBytes Transformation: A non-linear byte substitution that operates independently on each byte of the state using a substitution table (S-Box).
    2. ShiftRows Transformation: The bytes of the last three rows of the state are cyclically shifted over different offsets.
    3. MixColumns Transformation: Each of the four columns of the state are considered as polynomials over GF(2^8) and individually multiplied with another fixed polynomial.
    4. AddRoundKey Transformation: The round key is XORed with the output of the MixColumns operation and stored back into the State register. The 128-bit round key itself is extracted from the current value in the Full Key register.

    In parallel, the full key used for the next round is computed on the fly using the key expand module.

    If running in CTR mode, the counter module iteratively updates the IV in parallel to the cipher core performing encryption/decryption. Internally, the counter module uses one 16-bit counter, meaning it requires 8 clock cycles to increment the 128-bit counter value stored in the IV register. Since the counter value is used in the first round only, and since the encryption/decryption of a single block takes 12/14/16 cycles, the iterative counter implementation does not affect the throughput of the AES unit.

  7. Finally, the AES cipher core performs the final encryption/decryption round in which the MixColumns operation is skipped. The output is forwarded to the output register in the CSRs but not stored back into the State register. The internal State register is cleared with pseudo-random data.

    Depending on the cipher mode, the output of the final round is potentially XORed with either the value in the IV registers (CBC decryption) or the value stored in the previous input data register (CFB, OFB, CTR modes), before being forwarded to the output register in the CSRs. If running in CBC mode, the IV registers are updated with the output data (encryption) or the value stored in the previous input data register (decryption). If running in CFB or OFB mode, the IV registers are updated with the output data or the output of the final cipher round (before XORing with the previous input data), respectively.

Having separate registers for input, output and internal state prevents the extraction of intermediate state via TL-UL bus interface and allows to overlap reconfiguration with operation. While the AES unit is performing encryption/decryption, the processor can safely write the next input data block into the CSRs or read the previous output data block from the CSRs. The State register is internal to the AES unit and not exposed via the TL-UL bus interface. If the AES unit wants to finish the encryption/decryption of an output data block but the previous one has not yet been read by the processor, the AES unit is stalled. It hangs and does not drop data. It only continues once the previous output data has been read and the corresponding registers can be safely overwritten. The order in which the output registers are read does not matter. Every output register must be read at least once for the AES unit to continue. In contrast, the initial key, and control register can only be updated if the AES unit is idle, which eases design verification (DV). Similarly, the initialization vector (IV) register can only be updated by the processor if the AES unit is idle. If the AES unit is busy and running in CBC or CTR mode, the AES unit itself updates the IV register.

The cipher core architecture of the AES unit is derived from the architecture proposed by Satoh et al.: “A compact Rijndael Hardware Architecture with S-Box Optimization”. The expected circuit area in a 110nm CMOS technology is in the order of 12 - 22 kGE (unmasked implementation, AES-128 only). The expected circuit area of the entire AES unit with masking enabled is around 100 kGE. For more details, refer to the nightly OpenTitan synthesis results.

For a description of the various sub modules, see the following sections.

SubBytes / S-Box

The SubBytes operation is a non-linear byte substitution that operates independently on each byte of the state using a substitution table (S-Box). It is both used for the cipher data path and the key expand data path. In total, the AES unit instantiates 20 S-Boxes in parallel (16 for SubBytes, 4 for KeyExpand), each having 8-bit input and output. In combination with the 128-bit wide data path, this allows to perform one AES round per iteration.

The design of this S-Box and its inverse can have a big impact on circuit area, timing critical path, robustness and power leakage, and is itself its own research topic.

The S-Boxes are decoupled from the rest of the AES unit with a handshake protocol, allowing them to be easily replaced by different implementations if required. The AES unit comes with the following S-Box implementations that can be selected by a compile-time Verilog parameter:

The DOM S-Box has a latency of 5 clock cycles. All other implementations are fully combinational (one S-Box evaluation every clock cycle). See also Security Hardening below.

ShiftRows

The ShiftRows operation simply performs a cyclic shift of Rows 1, 2 and 3 of the state matrix. Consequently, it can be implemented using 3*4 32-bit 2-input muxes (encryption/decryption).

MixColumns

Each of the four columns of the state are considered as polynomials over GF(2^8) and individually multiplied with another fixed polynomial. The whole operation can be implemented using 36 2-input XORs and 16 4-input XORs (all 8-bit), 8 2-input muxes (8-bit), as well as 78 2-input and 24 3-input XOR gates.

KeyExpand

The key expand module (KEM) integrated in the AES unit is responsible for generating the various round keys from the initial key for both encryption and decryption. The KEM generates the next 128/192/256-bit full key in parallel to the actual encryption/decryption based on the current full key or the initial key (for the first encryption round). The actual 128-bit round key is then extracted from this full key.

Generating the keys on-the-fly allows for lower storage requirements and smaller circuit area but comes at the price of an initial delay before doing ECB/CBC decryption whenever the key is changed. During this phase, the KEM cycles through all full keys to obtain the start key for decryption (equals the key for final round of encryption). The duration of this delay phase corresponds to the latency required for encrypting one 16B block. During this initial phase, the cipher data path is kept idle.

The timing diagram below visualizes this process.

The AES unit is configured to do decryption (Config op = DECRYPT). Once the new key has been provided via the control and status registers (top), this new key is loaded into the Full Key register (key_full = K0-3) and the KEM starts performing encryption (KEM op=ENCRYPT). The cipher data path remains idle (AES op=IDLE). In every round, the value in key_full is updated. After 10 encryption rounds, the value in key_full equals the start key for decryption. This value is stored into the Decryption Key register (key_dec = K0-3' at the very bottom). Now the AES unit can switch between encryption/decryption without overhead as both the start key for encryption (key_init) and decryption (key_dec) can be loaded into full_key.

For details on the KeyExpand operation refer to the AES specification, Section 5.2.

Key expanding is the only operation in the AES unit for which the functionality depends on the selected key length. Having a KEM that supports 128-bit key expansion, support for the 256-bit mode can be added at low overhead. In contrast, the 192-bit mode requires much larger muxes. Support for this mode is thus optional and can be enabled/disabled via a design-time parameter.

Once we have cost estimates in terms of gate count increase for 192-bit mode, we can decide on whether or not to use it in OpenTitan. Typically, systems requiring security above AES-128 go directly for AES-256.

System Key-Manager Interface

This version of the AES unit is controlled entirely by the processor. The processor writes both input data as well as the initial key to dedicated registers via the system bus interconnect.

Future versions of the AES unit might include a separate interface through which a possible system key manager can provide the key without exposing it to the processor or other hosts attached to the system bus interconnect.

Security Hardening

The AES unit employs different means at architectural, micro-architectural and physical levels for security hardening against side-channel analysis and fault injection.

Side-Channel Analysis

To aggravate side-channel analysis (SCA), the AES unit implements the following countermeasures.

1st-order Masking of the Cipher Core

The AES unit employs 1st-order masking of the AES cipher core. More precisely, both the cipher and the key expand data path use two shares. As shown in the block diagram below, the width of all registers and data paths basically doubles.

Block diagram of the masked AES cipher core.

The initial key is provided in two shares via the register interface. The input data is provided in unmasked form and masked outside of the cipher core to obtain the two shares of the initial state. The pseudo-random data (PRD) required for masking the input data is provided by the pseudo-random number generator (PRNG) of the cipher core. Similarly, the two shares of the output state are combined outside the cipher core to obtain the output data.

The same PRNG also generates the fresh randomness required by the masked SubBytes (16 masked S-Boxes) and the masked KeyExpand (4 masked S-Boxes). The masking scheme selected for the S-Box can have a high impact on SCA resistance, circuit area, number of PRD bits consumed per cycle and per S-Box evaluation, and throughput. The selection of the masked S-Box implementation can be controlled via compile-time Verilog parameter. By default, the AES unit uses domain-oriented masking (DOM) for the S-Boxes as proposed by Gross et al.: “Domain-Oriented Masking: Compact Masked Hardware Implementations with Arbitrary Protection Order”. The provided implementation has a latency of 5 clock cycles per S-Box evaluation. As a result, the overall latency for processing a 16-byte data block increases from 12/14/16 to 56/66/72 clock cycles in AES-128/192/256 mode, respectively. Alternatively, the two original versions of the masked Canright S-Box can be chosen as proposed by Canright and Batina: “A very compact “perfectly masked” S-Box for AES (corrected)”. These are fully combinational (one S-Box evaluation every cycle) and have lower area footprint, but they are significantly less resistant to SCA. They are mainly included for reference but their usage is discouraged due to potential vulnerabilities to the correlation-enhanced collision attack as described by Moradi et al.: “Correlation-Enhanced Power Analysis Collision Attack”.

Note that the masking can be enabled/disabled via compile-time Verilog parameter. It may be acceptable to disable the masking when using the AES cipher core for random number generation e.g. inside CSRNG. When disabling the masking, also an unmasked S-Box implementation needs to be selected using the corresponding compile-time Verilog parameter. When disabling masking, it is recommended to use the unmasked Canright or LUT S-Box implementation for ASIC or FPGA targets, respectively. Both are fully combinational and allow for one S-Box evaluation every clock cycle.

It’s worth noting that since input/output data are provided/retrieved via register interface in unmasked form, the AES unit should not be used to form an identity ladder where the output of one AES operation is used to form the key for the next AES operation in the ladder. In OpenTitan, the Keccak Message Authentication Code (KMAC) unit is used for that purpose.

Fully-Parallel Data Path

Any 1st-order masking scheme primarily protects against 1st-order SCA. Vulnerabilities against higher-order SCA might still be present. A common technique to aggravate higher-order attacks is to increase the noise in the system e.g. by leveraging parallel architectures. To this end, the AES cipher core uses a 128-bit parallel data path with a total of up to 20 S-Boxes (16 inside SubBytes, 4 inside KeyExpand) that are evaluated in parallel.

Besides more noise for increased resistance against higher-order SCA, the fully-parallel architecture also enables for higher performance and flexibility. It allows users to seamlessly switch out the S-Box implementation in order to experiment with different masking schemes. To interface the data paths with the S-Boxes, a handshake protocol is used.

Note on Reset vs. Non-Reset Flip-Flops

The choice of flip-flop type for registering sensitive assets such as keys can have implications on the vulnerability against e.g. combined reset glitch attacks and SCA. Following the OpenTitan non-reset vs. reset flops rationale, the following observations can be made:

  • If masking is enabled, key and state values are stored in two shares inside the AES unit. Neither the Hamming weights of the individual shares nor the summed Hamming weight are proportional to the Hamming weight of the secret asset.
  • Input/output data and IV values are (currently) not stored in multiple shares but these are less critical as they are used only once. Further, they are stored in banks of 32 bits leaving a larger hypothesis space compared to when glitching e.g. an 8-bit register into reset. In addition, they could potentially also be extracted when being transferred over the TL-UL bus interface.

For this reason, the AES unit uses reset flops only. However, all major key and data registers are cleared with pseudo-random data upon reset.

Clearing Registers with Pseudo-Random Data

Upon reset or if initiated by software, all major key and data registers inside the AES module are cleared with pseudo-random data (PRD). This helps to reduce SCA leakage when both writing these registers for reconfiguration and when clearing the registers after use.

In addition, the state registers inside the cipher core are cleared with PRD during the last round of every encryption/decryption. This prevents Hamming distance leakage between the states of the last two rounds as well as between output and input data.

Fault Injection

Fault injection (FI) attacks can be distinguished based on the FI target.

Control Path

In cryptographic devices, fault attacks on the control path usually aim to disturb the control flow in a way to facilitate SCA or other attacks. Example targets for AES include: switch to less secure mode of operation (ECB), keep processing the same input data, reduce the number of rounds/early termination, skip particular rounds, skip individual operations in a round.

To protect against FI attacks on the control path, the AES unit implements the following countermeasures.

  • Shadowed Control Register: The main control register is implemented as a shadow register. This means software has to perform two subsequent write operations to perform an update. Internally, a shadow copy is used that is constantly compared with the actual register. For further details, refer to the Register Tool documentation.

  • Hardened round counter: To protect the round counter inside the cipher core against FI, a second copy of the counter is counting down, and the sum of the two counters is constantly compared with the number of total rounds to perform. In addition, one parity bit is used for the round counter.

  • Sparse encodings of FSM states: All FSMs inside the AES unit use sparse state encodings.

  • Sparse encodings for mux selector signals: All main muxes use sparsely encoded selector signals.

  • Sparse encodings for handshake and other important control signals.

If any of these countermeasures detects a fault, a fatal alert is triggered, the internal FSMs go into a terminal error state, the AES unit does not release further data and locks up until reset. Such a condition is reported in STATUS.ALERT_FATAL_FAULT. Details on where the fault has been detected are not provided.

Data Path

The aim of fault attacks on the data path is typically to extract information on the key by means of statistical analysis. The current version of the AES unit does not employ countermeasures against such attacks, but future versions most likely will.

Programmers Guide

This section discusses how software can interface with the AES unit.

Clear upon Reset

Upon reset, the AES unit will first reseed the internal PRNG for register clearing via EDN, and then clear all key, IV and data registers with pseudo-random data. Only after this sequence has finished, the unit becomes idle (indicated in STATUS.IDLE). The AES unit is then ready for software initialization. Note that at this point, the key, IV and data registers' values can no longer be expected to match the reset values.

Initialization

Before initialization, software must ensure that the AES unit is idle by checking STATUS.IDLE. If the AES unit is not idle, write operations to CTRL, the Initial Key registers KEY_SHARE0_0 - KEY_SHARE1_7 and initialization vector (IV) registers IV_0 - IV_3 are ignored.

To initialize the AES unit, software must first provide the configuration to the CTRL_SHADOWED register. Then software must write the initial key to the Initial Key registers KEY_SHARE0_0 - KEY_SHARE1_7. The key is provided in two shares: The first share is written to KEY_SHARE0_0 - KEY_SHARE0_7 and the second share is written to KEY_SHARE1_0 - KEY_SHARE1_7. The actual initial key used for encryption corresponds to the value obtained by XORing KEY_SHARE0_0 - KEY_SHARE0_7 with KEY_SHARE1_0 - KEY_SHARE1_7. Note that all registers are little-endian. The key length is configured using the KEY_LEN field of CTRL_SHADOWED. Independent of the selected key length, software must always write all 8 32-bit registers of both shares. Each register must be written at least once. The order in which the key registers are written does not matter. Anything can be written to the unused key registers of both shares, however, random data is preferred. For AES-128 ,the actual initial key used for encryption is formed by XORing KEY_SHARE0_0 - KEY_SHARE0_3 with KEY_SHARE1_0 - KEY_SHARE1_3. For AES-192, the actual initial key used for encryption is formed by XORing KEY_SHARE0_0 - KEY_SHARE0_5 with KEY_SHARE1_0 - KEY_SHARE1_5.

If running in CBC, CFB, OFB or CTR mode, software must also write the IV registers IV_0 - IV_3. These registers are little-endian, but the increment of the IV in CTR mode is big-endian (see Recommendation for Block Cipher Modes of Operation). Each IV register must be written at least once. The order in which these registers are written does not matter. Note that the AES unit automatically updates the IV registers when running in CBC, CFB, OFB or CTR mode (after having consumed the current IV value). To start the encryption/decryption of a new message, software must wait for the AES unit to become idle and then provide new values to the IV registers.

Block Operation

For block operation, software must initialize the AES unit as described in the previous section. In particular, the AES unit must be configured to run in normal/automatic mode. This is indicated by the MANUAL_OPERATION bit in CTRL_SHADOWED reading as 0. It ensures that the AES unit:

  1. Automatically starts encryption/decryption when new input data is available.
  2. Does not overwrite previous output data that has not yet been read by the processor.

Then, software must:

  1. Ensure that the INPUT_READY bit in STATUS is 1.
  2. Write Input Data Block 0 to the Input Data registers DATA_IN_0 - DATA_IN_3. Each register must be written at least once. The order in which these registers are written does not matter.
  3. Wait for the INPUT_READY bit in STATUS to become 1, i.e. wait for the AES unit to load Input Data Block 0 into the internal state register and start operation.
  4. Write Input Data Block 1 to the Input Data registers.

Then for every Data Block I=0,..,N-3, software must:

  1. Wait for the OUTPUT_VALID bit in STATUS to become 1, i.e., wait for the AES unit to finish encryption/decryption of Block I. The AES unit then directly starts processing the previously input block I+1
  2. Read Output Data Block I from the Output Data registers DATA_OUT_0 - DATA_OUT_3. Each register must be read at least once. The order in which these registers are read does not matter.
  3. Write Input Data Block I+2 into the Input Data register. There is no need to explicitly check INPUT_READY as in the same cycle OUTPUT_VALID becomes 1, the current input is loaded in (meaning INPUT_READY becomes 1 one cycle later).

Once all blocks have been input, the final data blocks I=N-2,N-1 must be read out:

  1. Wait for the OUTPUT_VALID bit in STATUS to become 1, i.e., wait for the AES unit to finish encryption/decryption of Block I.
  2. Read Output Data Block I from the Output Data register.

Note that interrupts are not provided, the latency of the AES unit is such that they are of little utility.

The code snippet below shows how to perform block operation.

  // Enable autostart, disable overwriting of previous output data. Note the control register is
  // shadowed and thus needs to be written twice.
  uint32_t aes_ctrl_val =
      op << AES_CTRL_SHADOWED_OPERATION |
      (key_len & AES_CTRL_SHADOWED_KEY_LEN_MASK) << AES_CTRL_SHADOWED_KEY_LEN_OFFSET |
      0x0 << AES_CTRL_SHADOWED_MANUAL_OPERATION;
  REG32(AES_CTRL_SHADOWED(0)) = aes_ctrl_val;
  REG32(AES_CTRL_SHADOWED(0)) = aes_ctrl_val;

  // Write key - Note: All registers are little-endian.
  for (int j = 0; j < 8; j++) {
    REG32(AES_KEY_SHARE0_0(0) + j * 4) = key_share0[j];
    REG32(AES_KEY_SHARE1_0(0) + j * 4) = key_share1[j];
  }

  // Write IV.
  for (int j = 0; j < 4; j++) {
    REG32(AES_IV_0(0) + j * 4) = iv[j];
  }

  // Write Input Data Block 0.
  for (int j = 0; j < 4; j++) {
    REG32(AES_DATA_IN_0(0) + j * 4) = input_data[j];
  }

  // Wait for INPUT_READY bit
  while (!((REG32(AES_STATUS(0)) >> AES_STATUS_INPUT_READY) & 0x1)) {
  }

  // Write Input Data Block 1
  for (int j = 0; j < 4; j++) {
    REG32(AES_DATA_IN_0(0) + j * 4) = input_data[j + 4];
  }

  // For Data Block I=0,...,N-1
  for (int i = 0; i < N; i++) {

    // Wait for OUTPUT_VALID bit
    while (!((REG32(AES_STATUS(0)) >> AES_STATUS_OUTPUT_VALID) & 0x1)) {
    }

    // Read Output Data Block I
    for (int j = 0; j < 4; j++) {
      output_data[j + i * 4] = REG32(AES_DATA_OUT_0(0) + j * 4);
    }

    // Write Input Data Block I+2 - For I=0,...,N-3 only.
    if (i < N - 2) {
      for (int j = 0; j < 4; j++) {
        REG32(AES_DATA_IN_0(0) + j * 4) = input_data[j + 4 * (i + 2)];
      }
    }
  }

Padding

For the AES unit to automatically start encryption/decryption of the next data block, software is required to always update all four Input Data registers DATA_IN_0 - DATA_IN_3 and read all four Output Data registers DATA_OUT_0 - DATA_OUT_3. This is also true if the AES unit is operated in OFB or CTR mode, i.e., if the plaintext/ciphertext not necessarily needs to be a multiple of the block size (for more details refer to Appendix A of Recommendation for Block Cipher Modes of Operation).

In the case that the plaintext/ciphertext is not a multiple of the block size and the AES unit is operated in OFB or CTR mode, software can employ any form of padding for the input data of the last message block as the padding bits do not have an effect on the actual message bits. It is recommended that software discards the padding bits after reading the output data.

De-Initialization

After finishing operation, software must:

  1. Disable the AES unit to no longer automatically start encryption/decryption by setting the MANUAL_OPERATION bit in CTRL_SHADOWED to 1.
  2. Clear all key registers, IV registers as well as the Input Data and the Output Data registers with pseudo-random data by setting the KEY_IV_DATA_IN_CLEAR and DATA_OUT_CLEAR bits in TRIGGER to 1.

The code snippet below shows how to perform this task.

  // Disable autostart. Note the control register is shadowed and thus needs to be written twice.
  uint32_t aes_ctrl_val = 0x1 << AES_CTRL_SHADOWED_MANUAL_OPERATION;
  REG32(AES_CTRL_SHADOWED(0)) = aes_ctrl_val;
  REG32(AES_CTRL_SHADOWED(0)) = aes_ctrl_val;

  // Clear all key, IV, Input Data and Output Data registers.
  REG32(AES_TRIGGER(0)) =
      (0x1 << AES_TRIGGER_KEY_IV_DATA_IN_CLEAR) |
      (0x1 << AES_TRIGGER_DATA_OUT_CLEAR);

Register Table

The AES unit uses 8 and 2x4 separate write-only registers for the initial key, initialization vector, and input data, as well as 4 separate read-only registers for the output data. All registers are little-endian. Compared to first-in, first-out (FIFO) interfaces, having separate registers has a couple of advantages:

  • Supported out-of-the-box by the register tool (the FIFO would have to be implemented separately).
  • Usability: critical corner cases where software updates input data or the key partially only are easier to avoid using separate registers and the hwqe-signals provided by the Register Tool.
  • Easier interaction with DMA engines

Also, using a FIFO interface for something that is not actually FIFO (internally, 16B of input/output data are consumed/produced at once) is less natural.

For a detailed overview of the register tool, please refer to the Register Tool documentation.

aes.ALERT_TEST @ 0x0

Alert Test Register

Reset default = 0x0, mask 0x3
31302928272625242322212019181716
 
1514131211109876543210
  fatal_fault recov_ctrl_update_err
BitsTypeResetNameDescription
0wo0x0recov_ctrl_update_err

Write 1 to trigger one alert event of this kind.

1wo0x0fatal_fault

Write 1 to trigger one alert event of this kind.


aes.KEY_SHARE0_0 @ 0x4

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_0...
1514131211109876543210
...key_share0_0
BitsTypeResetNameDescription
31:0wo0x0key_share0_0

Initial Key Share 0


aes.KEY_SHARE0_1 @ 0x8

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_1...
1514131211109876543210
...key_share0_1
BitsTypeResetNameDescription
31:0wo0x0key_share0_1

For KEY_SHARE01


aes.KEY_SHARE0_2 @ 0xc

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_2...
1514131211109876543210
...key_share0_2
BitsTypeResetNameDescription
31:0wo0x0key_share0_2

For KEY_SHARE02


aes.KEY_SHARE0_3 @ 0x10

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_3...
1514131211109876543210
...key_share0_3
BitsTypeResetNameDescription
31:0wo0x0key_share0_3

For KEY_SHARE03


aes.KEY_SHARE0_4 @ 0x14

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_4...
1514131211109876543210
...key_share0_4
BitsTypeResetNameDescription
31:0wo0x0key_share0_4

For KEY_SHARE04


aes.KEY_SHARE0_5 @ 0x18

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_5...
1514131211109876543210
...key_share0_5
BitsTypeResetNameDescription
31:0wo0x0key_share0_5

For KEY_SHARE05


aes.KEY_SHARE0_6 @ 0x1c

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_6...
1514131211109876543210
...key_share0_6
BitsTypeResetNameDescription
31:0wo0x0key_share0_6

For KEY_SHARE06


aes.KEY_SHARE0_7 @ 0x20

Initial Key Registers Share 0. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share0_7...
1514131211109876543210
...key_share0_7
BitsTypeResetNameDescription
31:0wo0x0key_share0_7

For KEY_SHARE07


aes.KEY_SHARE1_0 @ 0x24

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_0...
1514131211109876543210
...key_share1_0
BitsTypeResetNameDescription
31:0wo0x0key_share1_0

Initial Key Share 1


aes.KEY_SHARE1_1 @ 0x28

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_1...
1514131211109876543210
...key_share1_1
BitsTypeResetNameDescription
31:0wo0x0key_share1_1

For KEY_SHARE11


aes.KEY_SHARE1_2 @ 0x2c

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_2...
1514131211109876543210
...key_share1_2
BitsTypeResetNameDescription
31:0wo0x0key_share1_2

For KEY_SHARE12


aes.KEY_SHARE1_3 @ 0x30

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_3...
1514131211109876543210
...key_share1_3
BitsTypeResetNameDescription
31:0wo0x0key_share1_3

For KEY_SHARE13


aes.KEY_SHARE1_4 @ 0x34

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_4...
1514131211109876543210
...key_share1_4
BitsTypeResetNameDescription
31:0wo0x0key_share1_4

For KEY_SHARE14


aes.KEY_SHARE1_5 @ 0x38

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_5...
1514131211109876543210
...key_share1_5
BitsTypeResetNameDescription
31:0wo0x0key_share1_5

For KEY_SHARE15


aes.KEY_SHARE1_6 @ 0x3c

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_6...
1514131211109876543210
...key_share1_6
BitsTypeResetNameDescription
31:0wo0x0key_share1_6

For KEY_SHARE16


aes.KEY_SHARE1_7 @ 0x40

Initial Key Registers Share 1. The actual initial key corresponds to Initial Key Registers Share 0 XORed with Initial Key Registers Share 1. Loaded into the internal Full Key register upon starting encryption/decryption of the next block. All key registers (Share 0 and Share 1) must be written at least once when the key is changed, regardless of key length (write random data for unused bits). The order in which the registers are updated does not matter. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to these registers are ignored. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
key_share1_7...
1514131211109876543210
...key_share1_7
BitsTypeResetNameDescription
31:0wo0x0key_share1_7

For KEY_SHARE17


aes.IV_0 @ 0x44

Initialization Vector Registers. The initialization vector (IV) or initial counter value must be written to these registers when starting a new message in CBC or CTR mode (see Control Register), respectively. In CBC and CTR modes, the AES unit does not start encryption/decryption with a partially updated IV. Each register has to be written at least once. The order in which the registers are written does not matter. If the AES unit is non-idle, writes to these registers are ignored. Whenever starting a new message, the corresponding IV value must be provided by the processor. Once started, the AES unit automatically updates the contents of these registers. In ECB mode, the IV registers are not used and do not need to be configured. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
iv_0...
1514131211109876543210
...iv_0
BitsTypeResetNameDescription
31:0wo0x0iv_0

Initialization Vector


aes.IV_1 @ 0x48

Initialization Vector Registers. The initialization vector (IV) or initial counter value must be written to these registers when starting a new message in CBC or CTR mode (see Control Register), respectively. In CBC and CTR modes, the AES unit does not start encryption/decryption with a partially updated IV. Each register has to be written at least once. The order in which the registers are written does not matter. If the AES unit is non-idle, writes to these registers are ignored. Whenever starting a new message, the corresponding IV value must be provided by the processor. Once started, the AES unit automatically updates the contents of these registers. In ECB mode, the IV registers are not used and do not need to be configured. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
iv_1...
1514131211109876543210
...iv_1
BitsTypeResetNameDescription
31:0wo0x0iv_1

For IV1


aes.IV_2 @ 0x4c

Initialization Vector Registers. The initialization vector (IV) or initial counter value must be written to these registers when starting a new message in CBC or CTR mode (see Control Register), respectively. In CBC and CTR modes, the AES unit does not start encryption/decryption with a partially updated IV. Each register has to be written at least once. The order in which the registers are written does not matter. If the AES unit is non-idle, writes to these registers are ignored. Whenever starting a new message, the corresponding IV value must be provided by the processor. Once started, the AES unit automatically updates the contents of these registers. In ECB mode, the IV registers are not used and do not need to be configured. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
iv_2...
1514131211109876543210
...iv_2
BitsTypeResetNameDescription
31:0wo0x0iv_2

For IV2


aes.IV_3 @ 0x50

Initialization Vector Registers. The initialization vector (IV) or initial counter value must be written to these registers when starting a new message in CBC or CTR mode (see Control Register), respectively. In CBC and CTR modes, the AES unit does not start encryption/decryption with a partially updated IV. Each register has to be written at least once. The order in which the registers are written does not matter. If the AES unit is non-idle, writes to these registers are ignored. Whenever starting a new message, the corresponding IV value must be provided by the processor. Once started, the AES unit automatically updates the contents of these registers. In ECB mode, the IV registers are not used and do not need to be configured. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
iv_3...
1514131211109876543210
...iv_3
BitsTypeResetNameDescription
31:0wo0x0iv_3

For IV3


aes.DATA_IN_0 @ 0x54

Input Data Registers. If MANUAL_OPERATION=0 (see Control Register), the AES unit automatically starts encryption/decryption after all Input Data registers have been written. Each register has to be written at least once. The order in which the registers are written does not matter. Loaded into the internal State register upon starting encryption/decryption of the next block. After that, the processor can update the Input Data registers (See INPUT_READY field of Status Register). Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_in_0...
1514131211109876543210
...data_in_0
BitsTypeResetNameDescription
31:0wo0x0data_in_0

Input Data


aes.DATA_IN_1 @ 0x58

Input Data Registers. If MANUAL_OPERATION=0 (see Control Register), the AES unit automatically starts encryption/decryption after all Input Data registers have been written. Each register has to be written at least once. The order in which the registers are written does not matter. Loaded into the internal State register upon starting encryption/decryption of the next block. After that, the processor can update the Input Data registers (See INPUT_READY field of Status Register). Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_in_1...
1514131211109876543210
...data_in_1
BitsTypeResetNameDescription
31:0wo0x0data_in_1

For DATA_IN1


aes.DATA_IN_2 @ 0x5c

Input Data Registers. If MANUAL_OPERATION=0 (see Control Register), the AES unit automatically starts encryption/decryption after all Input Data registers have been written. Each register has to be written at least once. The order in which the registers are written does not matter. Loaded into the internal State register upon starting encryption/decryption of the next block. After that, the processor can update the Input Data registers (See INPUT_READY field of Status Register). Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_in_2...
1514131211109876543210
...data_in_2
BitsTypeResetNameDescription
31:0wo0x0data_in_2

For DATA_IN2


aes.DATA_IN_3 @ 0x60

Input Data Registers. If MANUAL_OPERATION=0 (see Control Register), the AES unit automatically starts encryption/decryption after all Input Data registers have been written. Each register has to be written at least once. The order in which the registers are written does not matter. Loaded into the internal State register upon starting encryption/decryption of the next block. After that, the processor can update the Input Data registers (See INPUT_READY field of Status Register). Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_in_3...
1514131211109876543210
...data_in_3
BitsTypeResetNameDescription
31:0wo0x0data_in_3

For DATA_IN3


aes.DATA_OUT_0 @ 0x64

Output Data Register. Holds the output data produced by the AES unit during the last encryption/decryption operation. If MANUAL_OPERATION=0 (see Control Register), the AES unit is stalled when the previous output data has not yet been read and is about to be overwritten. Each register has to be read at least once. The order in which the registers are read does not matter. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_out_0...
1514131211109876543210
...data_out_0
BitsTypeResetNameDescription
31:0ro0x0data_out_0

Output Data


aes.DATA_OUT_1 @ 0x68

Output Data Register. Holds the output data produced by the AES unit during the last encryption/decryption operation. If MANUAL_OPERATION=0 (see Control Register), the AES unit is stalled when the previous output data has not yet been read and is about to be overwritten. Each register has to be read at least once. The order in which the registers are read does not matter. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_out_1...
1514131211109876543210
...data_out_1
BitsTypeResetNameDescription
31:0ro0x0data_out_1

For DATA_OUT1


aes.DATA_OUT_2 @ 0x6c

Output Data Register. Holds the output data produced by the AES unit during the last encryption/decryption operation. If MANUAL_OPERATION=0 (see Control Register), the AES unit is stalled when the previous output data has not yet been read and is about to be overwritten. Each register has to be read at least once. The order in which the registers are read does not matter. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_out_2...
1514131211109876543210
...data_out_2
BitsTypeResetNameDescription
31:0ro0x0data_out_2

For DATA_OUT2


aes.DATA_OUT_3 @ 0x70

Output Data Register. Holds the output data produced by the AES unit during the last encryption/decryption operation. If MANUAL_OPERATION=0 (see Control Register), the AES unit is stalled when the previous output data has not yet been read and is about to be overwritten. Each register has to be read at least once. The order in which the registers are read does not matter. Upon reset, these registers are cleared with pseudo-random data.

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
data_out_3...
1514131211109876543210
...data_out_3
BitsTypeResetNameDescription
31:0ro0x0data_out_3

For DATA_OUT3


aes.CTRL_SHADOWED @ 0x74

Control Register. Can only be updated when the AES unit is idle. If the AES unit is non-idle, writes to this register are ignored. This register is shadowed, meaning two subsequent write operations are required to change its content. If the two write operations try to set a different value, a recoverable alert is triggered (See Status Register). A read operation clears the internal phase tracking: The next write operation is always considered a first write operation of an update sequence. Any write operation to this register will clear the status tracking required for automatic mode (See MANUAL_OPERATION field). A write to the Control Register is considered the start of a new message. Hence, software needs to provide new key, IV and input data afterwards.

Reset default = 0xc0, mask 0xfff
31302928272625242322212019181716
 
1514131211109876543210
  FORCE_ZERO_MASKS MANUAL_OPERATION KEY_LEN MODE OPERATION
BitsTypeResetNameDescription
0rw0x0OPERATION

Select encryption(0) or decryption(1) operation of AES unit.

6:1rw0x20MODE

6-bit one-hot field to select AES block cipher mode. Invalid input values, i.e., values with multiple bits set and value 6'b00_0000, are mapped to AES_NONE (6'b10_0000).

1AES_ECB

6'b00_0001: Electronic Codebook (ECB) mode.

2AES_CBC

6'b00_0010: Cipher Block Chaining (CBC) mode.

4AES_CFB

6'b00_0100: Cipher Feedback (CFB) mode.

8AES_OFB

6'b00_1000: Output Feedback (OFB) mode.

16AES_CTR

6'b01_0000: Counter (CTR) mode.

32AES_NONE

6'b10_0000: Invalid input values, i.e., value with multiple bits set and value 6'b00_0000, are mapped to AES_NONE.

Other values are reserved.

9:7rw0x1KEY_LEN

3-bit one-hot field to select AES key length. Invalid input values, i.e., values with multiple bits set, value 3'b000, and value 3'b010 in case 192-bit keys are not supported (because disabled at compile time) are mapped to AES_256 (3'b100).

1AES_128

3'b001: 128-bit key length.

2AES_192

3'b010: 192-bit key length. In case support for 192-bit keys has been disabled at compile time, setting this value results in configuring AES_256 (3'b100).

4AES_256

3'b100: 256-bit key length. Invalid input values, i.e., values with multiple bits set, value 3'b000, and value 3'b010 in case 192-bit keys are not supported (because disabled at compile time) are mapped to AES_256.

Other values are reserved.

10rw0x0MANUAL_OPERATION

Controls whether the AES unit is operated in normal/automatic mode (0) or fully manual mode (1). In automatic mode (0), the AES unit automatically i) starts to encrypt/decrypt when it receives new input data, and ii) stalls during the last encryption/decryption cycle if the previous output data has not yet been read. This is the most efficient mode to operate in. Note that the corresponding status tracking is automatically cleared upon a write to the Control Register. In manual mode (1), the AES unit i) only starts to encrypt/decrypt after receiving a start trigger (see Trigger Register), and ii) overwrites previous output data irrespective of whether it has been read out or not. This mode is useful if software needs full control over the AES unit.

11rw0x0FORCE_ZERO_MASKS

Use masks generated by internal masking PRNG (0) or force all masks constantly to zero (1). Setting all masks to constant zero can be useful when performing SCA. To completely disable the masking, the second key share (KEY_SHARE1_0 - KEY_SHARE1_7) must be zero as well. Only applicable if both the Masking parameter and the SecAllowForcingMasks parameter are set to one.


aes.TRIGGER @ 0x78

Trigger Register. Each bit is individually cleared to zero when executing the corresponding trigger. While executing any of the triggered operations, the AES unit will set the IDLE bit in the Status Register to zero. The processor must check the Status Register before triggering further actions. For example, writes to Initial Key and IV Registers are ignored while the AES unit is busy. Writes to the Input Data Registers are not ignored but the data will be cleared if a KEY_IV_DATA_IN_CLEAR operation is pending.

Reset default = 0xe, mask 0xf
31302928272625242322212019181716
 
1514131211109876543210
  PRNG_RESEED DATA_OUT_CLEAR KEY_IV_DATA_IN_CLEAR START
BitsTypeResetNameDescription
0wo0x0START

Keep AES unit paused (0) or trigger the encryption/decryption of one data block (1). This trigger is ignored if MANUAL_OPERATION=0 (see Control Register).

1wo0x1KEY_IV_DATA_IN_CLEAR

Keep current values in Initial Key, internal Full Key and Decryption Key registers, IV registers and Input Data registers (0) or clear all those registers with pseudo-random data (1).

2wo0x1DATA_OUT_CLEAR

Keep current values in Output Data registers (0) or clear those registers with pseudo-random data (1).

3wo0x1PRNG_RESEED

Keep continuing with the current internal state of the internal pseudo-random number generator used for register clearing (0) or perform a reseed of the internal state from the connected entropy source (1).


aes.STATUS @ 0x7c

Status Register

Reset default = 0x0, mask 0x7f
31302928272625242322212019181716
 
1514131211109876543210
  ALERT_FATAL_FAULT ALERT_RECOV_CTRL_UPDATE_ERR INPUT_READY OUTPUT_VALID OUTPUT_LOST STALL IDLE
BitsTypeResetNameDescription
0ro0x0IDLE

The AES unit is idle (1) or busy (0). This flag is 0 if one of the following operations is currently running: i) encryption/decryption, ii) register clearing or iii) PRNG reseeding. This flag is also 0 if an encryption/decryption is running but the AES unit is stalled.

1ro0x0STALL

The AES unit is not stalled (0) or stalled (1) because there is previous output data that must be read by the processor before the AES unit can overwrite this data. This flag is not meaningful if MANUAL_OPERATION=1 (see Control Register).

2ro0x0OUTPUT_LOST

All previous output data has been fully read by the processor (0) or at least one previous output data block has been lost (1). It has been overwritten by the AES unit before the processor could fully read it. Once set to 1, this flag remains set until AES operation is restarted by re-writing the Control Register. The primary use of this flag is for design verification. This flag is not meaningful if MANUAL_OPERATION=0 (see Control Register).

3ro0x0OUTPUT_VALID

The AES unit has no valid output (0) or has valid output data (1).

4ro0x0INPUT_READY

The AES unit is ready (1) or not ready (0) to receive new data input via the DATA_IN registers. If the present values in the DATA_IN registers have not yet been loaded into the module this flag is 0 (not ready).

5ro0x0ALERT_RECOV_CTRL_UPDATE_ERR

An update error has not occurred (0) or has occurred (1) in the shadowed Control Register. AES operation needs to be restarted by re-writing the Control Register.

6ro0x0ALERT_FATAL_FAULT

No fatal fault has occurred inside the AES unit (0). A fatal fault has occurred and the AES unit needs to be reset (1). Examples for fatal faults include i) storage errors in the Control Register, ii) if any internal FSM enters an invalid state, iii) if any sparsely encoded signal takes on an invalid value, iv) errors in the internal round counter, and v) escalations triggered by the life cycle controller.