Skip to content
Implementation of the CMAC keyed hash function using AES as block cipher.
Verilog Python Makefile
Branch: master
Clone or download

Latest commit

Fetching latest commit…
Cannot retrieve the latest commit at this time.

Files

Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
src
toolruns
.gitattributes
LICENSE
README.md

README.md

cmac

Introduction

Verilog implementation of the block cipher based keyed hash function CMAC. CMAC is specified in the NIST document SP 800-38 B and used in RFC 4493. Wikipedia has a good summary of CMAC too.

This implementation uses the AES block cipher with support for 128 and 256 bit keys. The ICV generated is 128 bit.

Status

The core has been implemented and verified againt test vectors from IETF and NIST using testbench for testcases with zero, single and multiple block messages. Padding has been verified. The CMAC ICV generation works with 128 or 256 bit keys.

The Core has been implemented in hardware (Altera and Xilinx FPGAs).

Functionality

The core accepts a key and a message divided into zero, one or more 128 bit blocks. After processing the core provides a result, the Integrity Check Vector (ICV) for the message. The ICV can be communicated to a recipient. By recalculating the ICV for the received message and comparing to the received ICV, the recipient can verify the message integrity and that it is from a sender that share the secret key with the recipient.

Performance wise, the cost of processing a message requires one initial AES operation (for internal subkey generation) and then one AES operation for each message block.

Usage

The core is used by first writing the key into the key registers and then asserting the init control signal. When the core signals ready the cmac has been initialized. Note that valid will be deasserted by the core, signalling that the ICV result is no longer valid.

The message can then be processed as a sequence of 128 bit blocks. For each block the next control signal shall be asserted. Note that ready signal must be set by the core for the core to accept new blocks.

Note that the core expects information about number of bits in the final message block [1..128]. The core performs padding and tweak based on this information. The final block and the lenght shall be written to the core and then the finalize signal shall be asserted. The core will process the final block and then raise ready and valid signalling that the ICV result is ready and valid.

Note that the core does not provide verification of a given ICV. The caller is expected to perform this comparison after generating the ICV for a received message.

Implementation Results

Altera Cyclone V

  • Device: 5CGXFC7C7F23C8
  • Logic utilization (ALMs): 2285
  • Registers: 3171
  • Clock speed: 91 MHz

Xilinx Artix-7

  • Device: xc7a200t-3fbg484
  • Slices: 2721
  • Registers: 2996
  • Clock speed: 91 MHz

Xilinx Spartan-6

  • Device: xc6slx45-3fgg484
  • Slices: 2385
  • Registers: 3002
  • Clock speed: 100 MHz
You can’t perform that action at this time.