[Cryptech Tech] Aes keywrap core ready for test and benchmarking

[Joachim Strömbergson]

Aloha!

Rob, list:

I have now completed a first implementation of AES Key Wrap in hardware.

https://trac.cryptech.is/browser/user/js/keywrap

The core implements the block processing part of wrap as specified in chapter 2.2.1 of RFC 3394 (and unwrap as specified in 2.2.2 of RFC 3394). The object to be wrapped/unwrapped is stored and updated in a local memory. The maximum size of an object is 32 kbit.

The core has been simulated with objects of up to 4096 bits. The core has been tested with both the aes core and the aes_speed core. The core has been implemented for Xilinx Artix-7 and meet timing at 100+ MHz.

The resources used including resources for aes_speed is:

Regs:    2906 (1%)
Slices:  1991 (5%)
RamB36E: 32 (8%)
Clock:   100+ MHz

In terms of performance, for wrap operation of 4096 bit object the core takes 6800 cycles. This includes reading and writing to the registers including writing the object and reading the result.


Limitations and API
The core is still a work in progress. This is the first version and has a bit kludgy interface. But it should allow us to perform benchmarking on the Alpha board. Some of the limitations are:

The core does not implement the magic value calculation as specified in RFC 5649. Nor does it do any padding of object to a complete 8 byte block. The caller needs to calculate the 64-bit magic value and store it in the A registers. The caller also needs to pad the object. After this has happened the caller needs to write the object to the DATA words in the core. The caller also needs to write the length in 64-bit blocks of the object to be processed. This length does not include the A-block.

Due to address space limitations in the cryptech cores, the core implements bank switching (with four banks). The caller must write to the BANK register to ensure that subsequent writes to the DATA addresses ends up in the correct bank. And similarly, the caller needs to set the bank as needed when reading the wrapped/unwrapped object from the core. Basically the first 128 words of the object is stored in bank 0, the next 128 in bank 1 etc.

The caller must also help the core perform initialisation of the AES core by writing to the CTRL_INIT_BIT after the key has been set. This will make the AES core perform key expansion. Note that it is possible to for example write object words to the keywrap core while the AES core is performing the initialisation. But changing contents of the object memory, changing the endec bit (corresponding to wrap or unwrap) after setting CTRL_NEXT_BIT and before ready has been set again will probably cause all kinds of problems.

I think the easiest thing to do is probably to look at the test cases in the python model and the test cases in the tb_keywrap.v to see how the core is to be operated. Also, I will of course answer questions.

https://trac.cryptech.is/browser/user/js/keywrap/src/model/aes_keywrap.py
https://trac.cryptech.is/browser/user/js/keywrap/src/tb/tb_keywrap.v

(test test_kwp_ae_128_1 in tb_keywrap.v is probably a good starting point)


Possible problems
One thing that might cause problems is read access to the memory. The memory is implemented using the FPGA block RAM. The read out from these are synchronous. This adds one delay cycle. It might be that this delay results in the wrong value being read. Reading the same address twice should mean that the value is accessible directly on the second read.

Write operations is handled internally by the core and should not have this problem.

Please try and modify the SW implementing the key wrap to use this core to perform the main processing. And then benchmark. This core should eliminate a huge amount of data transfer between MCU and FPGA during processing. And also stall cycles in between AES operations.


Test it and let me what is broken. ;-)


Cheers!

—
Med vänlig hälsning, Regards,

Joachim Strömbergson - Assured AB
=================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cryptech.is/archives/tech/attachments/20180706/6f94cc74/attachment.sig>