AES UVC – A UVM Implementation

7 min reading

Cryptography is no longer just a mechanism used by the military or government officials to secure sensitive information. Over the years, it has evolved into a mandatory mechanism to protect individuals and their information regardless of their objective importance. From securing high quantities of data to validating a person’s identity or whether a file’s integrity has not been compromised, cryptographic algorithms come in multiple forms due to their high computational complexity and purpose:

  • Symmetric
  • Asymmetric
  • Hashing


Due to their widespread use in modern systems, efficiency is crucial. As a result, engineers increasingly adopt hardware implementations for both pre-quantum and post-quantum algorithms [1]. Because they process large data volumes efficiently, symmetric encryption algorithms have gained popularity in hardware implementations [2].

This paper presents a UVM-based UVC providing the functionalities of the Advanced Encryption Standard (i.e., AES), currently considered the most secure and widely used symmetric encryption algorithm [3]. It also includes multiple National Institute of Standards and Technology (i.e., NIST) approved block modes of operation.

The official documentation for the AES may be found in FIPS 197 [4].
The official documentation for the block modes of operation implemented may be found in SP 800-38A [5].

Table of Contents

  1. Introduction
  2. Package Structure
  3. Proposed use cases
  4. Conclusion
  5. Acknowledgements
  6. Download
  7. Bibliography

Introduction

A block mode AES transaction requires the following elements:

  • Input block as multiple of 128 bits.
  • Secret key of 128, 192 or 256 bits.
  • Initialization Vector (IV) of 128 bits.


The block mode operations are described as wrappers around the standard AES Encryption and Decryption functions, as shown in the figure below.

Figure 1: General configuration of a block mode transaction

Package Structure

The AES UVC resides within a UVM-based package containing transaction level components and objects illustrated in the following figure:

Figure 2: AES-UVC package structure

The amiq_aes_uvc_pkg package includes the following elements:

  • Utils Library
  • Miscellaneous Library
  • Input Item
  • Output Item
  • Configuration Object
  • Core
  • Coverage Collector
  • Communication Component

: amiq_aes_uvc_utils_lib;
: amiq_aes_uvc_misc_lib;
: amiq_aes_uvc_input_item;
: amiq_aes_uvc_output_item;
: amiq_aes_uvc_config_obj;
: amiq_aes_uvc_core;
: amiq_aes_uvc_coverage_collector;
: amiq_aes_uvc;

Core

The Core component performs AES transactions using three levels of public methods that accept progressively more parameters:

  • Level 1: Individual encrypt() / decrypt() functions defined for each block mode.
  • Level 2: xcrypt() functions that wrap Level 1 functions to combine encryption and decryption into a single operation.
  • Level 3: aes_main() function with multiple input parameters wrapping over Level 2 functions.
Figure 3: AES-UVC Core

In order to reduce the number of parameters required for a transaction in the UVC and encourage the use of AES for its intended purpose (encrypting high volumes of data), the user can set the secret key and initialization vector separately using the set_key and set_iv methods.

Those setters check the size of the key and IV , assess their validity and issue  a `uvm_info if the user set an incorrectly sized parameter.

function void set_key(byte unsigned new_key[], amiq_aes_key_size_e size);

    valid_key = 0;
    new_setup = AES_TRUE;

    if ((size == AES_128) || (size == AES_192) || (size == AES_256)) begin
      if (new_key.size() >= (`AES_UVC_MIN_KEY_BYTE_LENGTH + (8 * (size - 1)))) begin
        valid_key = 1;
      end
    end

    if (valid_key == 1) begin
      nk           = 2 * (size + 1);
      nr           = nk + unsigned'(6);
      key_exp_size = `AES_UVC_MIN_KEY_BYTE_LENGTH * (nr + 1);

      for (int i = 0; i < ((size + 1) * `AES_UVC_BYTE); i++) begin
        key[i] = new_key[i];
      end

      key_expansion();
    end
    else begin
      `uvm_info(this.get_full_name(), $sformatf(
          "Incorrect key length, needed:128/192/256bits(16/24/32bytes), actual:%dbits(%d bytes)", new_key.size * 8,
          new_key.size), UVM_NONE)
    end

endfunction

If the user attempts to run an AES operation with an invalid key and/or IV, the guards inside the Level 1 and Level 2 functions invoke call_failure(). This function alerts the user through a `uvm_info, `uvm_warning or `uvm_error depending on the verbosity_level and the toggle_setup_info_warning_error flags inside the amiq_aes_config_obj.

function void call_failure( 
     string        ctx, 
     string        message, 
     uvm_verbosity verbosity = m_aes_config_obj.verbosity_level 
   ); 
   case (m_aes_config_obj.toggle_setup_info_warning_error) 
     `AES_INFO    : `uvm_info(ctx, message, verbosity) 
     `AES_WARNING : `uvm_warning(ctx, message) 
     `AES_ERROR   : `uvm_error(ctx, message) 
     default      : `uvm_error(this.get_full_name(), "received an illegal parameter") 
   endcase; 
 endfunction 

Currently the Core supports transactions for the ECB, CTR, CBC, OFB and CFB (with offsets of 1, 8 and 128 bits), all AES key sizes, and padding for incomplete data blocks [4].

Communication Component

The communication component, symbolically named UVC, integrates all required components within a single package, eliminating the need for additional instantiations. It wraps the Core and provides the user with an implementation port specialized for an amiq_aes_uvc_input_item. Its associated _write() function extracts the required parameters from the item and executes a Core transaction. The resulting data is then wrapped in an amiq_aes_uvc_output_item and sent through the analysis port inside the component.

Figure 4: Communication component port connections

This component also contains the Coverage Collector, which connects to the Core through TLM ports. While using it is optional, it offers alternative access to the same functionalities. Users can independently instantiate and connect the Core and Coverage Collector without relying on the communication component or items.

Input & Output Items

The transactions defined inside the amiq_aes_uvc are driven using the input and output items. The amiq_aes_uvc_input_item contains the data, key, IV and a transaction setup with the necessary fields to configure a transaction (new_setup, key_size, block_mode, operation) as shown in the figure below:

Figure 5: UVC Input Item

As mentioned earlier, the output is encapsulated in an amiq_aes_uvc_output_item which can be observed in the figure below:

Figure 6: UVC Output Item

The items can also serve primary input and output agent items in AES-based verification environments.

Coverage Collector

In order to validate the versatility and capability of the UVC to manage all possible transactions, the Coverage Collector implements three categories of coverage described in the verification plan:

  • Data based: Ensures each byte in the data, key and IV achieves every power 2 up to 255, verifying full 8-bit toggling.
  • Configuration based: Covers all possible configurations of new setup / block mode / key size / operation, including transitions between 3 successive transactions.
  • Statistics based: Collects general metrics such as:
    • Counting how many transactions use the same key and IV, and information about their occurrence.
    • Counting how many transactions still have the same configuration even if the new_setup parameter has been set to true.
    • Counting how many concurrent transactions use the same key after they reach a certain threshold defined in the Configuration Object.

Utils & Misc 

The amiq_aes_uvc_utils_lib defines custom enum types, the transaction_setup class used in the Input Item, and the data structures for coverage statistics. The amiq_aes_uvc_misc_lib provides debugging functions to print hex arrays and UVC items.

Configuration Object

The configuration object manages parameters related to the Coverage Collector, including: enabling the coverage, enabling the storage of statistics coverage, the maximum number of transactions using the same key and setting up the uvm info / warning / error and the verbosity regarding invalid key / IV messages.

Proposed use cases

Since the UVC is defined as a transaction-level component, it can be integrated and used in any scenario where its encryption/decryption functionality is relevant, as shown in the figure below.

Figure 7: Hierarchy of a Verification Environment

This article proposes two basic use cases of the AES-UVC.

Reference model for checks

Users can instantiate the UVC inside the environment and connect it to the scoreboard using TLM ports. In this scenario, the UVC acts as a reference model for verifying whether an AES RTL produces the correct output.

Figure 8: Using the UVC as a reference model for checks

Stimulus generation

Similarly, the users can instantiate the UVC inside the environment and access it through its public methods from the input sequence. In this scenario, the generated input is encrypted before being sent to the driver. The RTL is used in CTR mode which means the scoreboard will compare the original data instead of the encrypted data.

Figure 9: Using the UVC as a stimulus generator in the Input Sequence

Conclusion

The UVC has been functionally validated through the Annexes presented in FIPS 197 and SP 800-38A to guarantee that the output is correct.

Through the 100% test passing rate and 100% coverage rate obtained from the implementation of the verification plan, the UVC handles all possible configurations reliably.

This paper presents the implementation of an AES-based UVC in a modular and extensible manner supporting multiple block modes of operation. As it is a transaction level package of components, it may be used with minimal effort inside verification environments, both through public methods and analysis ports.

Acknowledgements

I would like to express my gratitude to Amiq Consulting, especially Tiberiu, Eda and Marius, for guiding me throughout the elaboration of my bachelor’s thesis as well as this article which is based on it.

Download

This project’s source code may be accessed at AMIQ’s Github Repository.

Bibliography

[1] Favin Fernandes, Gauravi Dungarwal, Aishwariya Gaikwad, Ishan Kareliya, & Swati Shilaskar. (2021). VLSI Implementation of Cryptographic Algorithms & Techniques: A Literature Review.

[2] Coppolino, L., D’Antonio, S., & Mazzeo, G. (2019). A Comprehensive Survey of Hardware-assisted Security: from the Edge to the Cloud. Internet of Things, 6, 100055.

[3] Maharaj, A. (2020). A Review on Advanced Encryption Standards (AES). University of Naples ’Parthenope’ Centro Direzionale, Isola C4, 80133 Napoli

[4] Announcing the Advanced Encryption Standard (AES), Federal Information Processing Standards Publication (FIPS) 197, National Institute of Standards and Technology (NIST), Nov. 2001.

[5] Morris Dworkin, Recommendation for Block Cipher Modes of Operation: Methodsand Techniques, NIST Special Publication 800-38A, National Institute of Standards and Technology (NIST), Dec. 2001.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter

Do you want to be up to date with our latest articles?