ECE532S: Digital Hardware Group Report

Adam Kruger 990330227 Edward Lo 990221817

April 12th, 2004

Table of Contents
TABLE OF CONTENTS...............................................................................................................................2 1 OVERVIEW.................................................................................................................................................3 1.1 PROJECT GOALS..........................................................................................................................................3 1.2 FUNCTIONAL BLOCKS..................................................................................................................................3 1.3 INCORPORATION INTO THE MICROBLAZE DESIGN..............................................................................................4 2 OUTCOME..................................................................................................................................................4 2.1 RESULTS...................................................................................................................................................4 2.2 FUTURE WORK...........................................................................................................................................4 3 DESCRIPTION OF THE BLOCKS..........................................................................................................5 3.1 AES ENCRYPTION CORE............................................................................................................................5 3.2 AES DECRYPTION CORE............................................................................................................................5 3.3 AES ENCRYPTION INTERFACE.....................................................................................................................6 3.4 AES DECRYPTION INTERFACE.....................................................................................................................6 3.5 EXAMPLE OF OPERATION USING XMD.........................................................................................................6 4 DESCRIPTION OF DESIGN TREE.........................................................................................................7 5 REFERENCES............................................................................................................................................8

1 Overview
1.1 Project goals The goal of this project was to create a system for encrypting and decrypting audio streams. Sounds from the microphone would be recorded into external ZBT RAM in AES encrypted format. The sounds would then be played back from the RAM after being decrypted. The recorded stream would sound jumbled if the correct encryption key was not provided during playback. Unfortunately, due to time constraints and unforeseen difficulties in setting up the AC97 codec for recording, we were forced to change our project goal. The current goal is to create AES encryption and decryption interface cores that can easily attach encryption and decryption cores to the OPB in a Microblaze SOPC. This would allow future groups to easily add encryption and decryption capability to their designs. In order to keep the operation of the AES core simple, we aimed for a memory mapped design. All data to and from the AES cores, as well as associated control signals, were to be memory mapped to specific address locations. This made debugging the core through XMD a simple procedure. In addition, incorporating memory writes into C programs would be a similarly trivial task. 1.2 Functional blocks There are four main logic blocks in our design (Figure 1). The AES cipher block performs the actual encryption. The AES inverse cipher block decrypts the data when the correct key is loaded. The two interface modules connect the AES core to the OPB interface in memory mapped fashion. OPB

AES cipher interface

AES cipher block

AES inverse cipher interface

AES inverse cipher block

Figure 1. Connecting the AES cipher and inverse cipher blocks to the OPB via interfaces

The AES cipher blocks were downloaded from [OP04]. The interfaces were created using Lesley Shannons Snoopy core as a template which is provided through the ECE532 labs [ECE04]. The interfaces detect memory mapped accesses and pass the appropriate control and data signals to the AES cores. The interfaces also contain logic that automatically pulse control signals for a single clock cycle period when required. 1.3 Incorporation into the Microblaze design In order to use the design, the custom logic must be copied into the projects pcores directory. The connections between the AES cipher block and its OPB interface must be specified. This can be done through the Add/Edit Cores dialog box. Similarly, the same must be done for the AES inverse cipher block and its OPB interface. The interfaces must also be configured as OPB slave devices. Finally, the interfaces are configured to use address ranges 0xffffff00 to 0xffffffff for encryption and address ranges 0xfffffe00 to 0xfffffeff for decryption.

2 Outcome
2.1 Results The project was a success. We were able to create simple-to-use encryption and decryption interfaces that could, along with the encryption and decryption cores, be dropped into an existing Microblaze based design. The AES hardware is able to encrypt 128 bits of data in 12 clock cycles and to decrypt 128 bits of data in 24 clock cycles. However, the system needs extra clock cycles for reading and writing over the OPB bus. A basic Microblaze system with the AES core and interfaces utilizes 6443 slices or approximately 59% of the Xilinx 2V2000 chip. Unfortunately, we were not able to test whether or not this speed is sufficient for streaming audio decryption. However, the system can easily be used to decrypt encrypted data in external memory ahead of time, before playback. It may also be possible to buffer short sound clips for decryption before playback. 2.2 Future work Currently, the AES core is written in Verilog whereas the interface is written in VHDL. This project could be improved by rewriting the interface in Verilog and instantiating the AES core from within the interface. This would make the project easier to incorporate into existing designs. It would eliminate the need to individually connect the wires between the core and the interface in the Add/Edit cores dialog box, and increase user friendliness.

The interface could be further improved by interfacing the FSL instead of the OPB. This would provide for higher speed access to the AES encryption and decryption cores, if necessary. It should be determined whether the OPB provides sufficient throughput for this current implementation to be used in a practical implementation. There are a number of interesting projects that would incorporate the AES core. More work could be done to use the AES logic in streaming applications, similar to our original project goals. The core could also be used in conjunction with a network interface in order to send secure information over the internet. A method may be devised to make the encryption key based on the serial number of the Xilinx chip. In this fashion, secure information may be read from only one chip.

3 Description of the blocks

3.1 AES Encryption Core The AES Encryption Core was downloaded from [OP04]. It was written in Verilog. Its operation is controlled by two control signals and takes 12 clock cycles. On the first clock cycle, the 128-bit key and 128-bit data block are sent as input. At the same time, the load control signal is pulsed for 1 clock cycle. The logic block completes the encryption in 12 clock cycles. At that time, the done control signal acts as an acknowledgement and becomes asserted for 1 clock cycle. During that clock cycle (and only during that clock cycle), the 128 bit data can be read back from TEXT_OUT. This data will be the encrypted data. More information on the operation of the AES core is provided at [OP04]. 3.2 AES Decryption Core The AES Decryption Core was also downloaded from [OP04]. It was also written in Verilog. Its operation is based on 4 control signals and takes a total of 24 clock cycles. The first 12 clock cycles are used to load in the decryption key. On the first clock cycle, the 128-bit key is sent as input, and the key load control signal is pulsed for only one clock cycle. 12 clock cycles later, the key done control signal is asserted by the core as acknowledgement. After this step, the load control signal may be pulsed for one (and only one) clock cycle. On that cycle, the core reads in the 128-bit encrypted data block from TEXT_IN and begins processing. After another 12 clock cycles, the done control signal is asserted and the system can read back the decrypted data from TEXT_OUT. Please note that for correct decryption, the key that is used for decryption must match the key used for encryption.

3.3 AES Encryption Interface The encryption interface acts as a link between the OPB bus and the actual AES encryption core. The interface monitors the OPB bus for data writes to specific memory locations. This allows for memory mapped operation. The interface essentially latches data from the OPB bus and pipes it to the appropriate inputs on the AES encryption core. Similarly, it also latches outputs from the AES encryption core and saves the values inside registers. It then returns the registered values through the OPB data bus when an OPB read request is made to the appropriate memory address. In order to distinguish between the various done signals generated from sequential encryption operations, a mechanism to clear the internally registered done signal must be used. The interface will clear the done signal when a memory write is made to the same location (address 0xffffff34). The following chart summarizes the memory mapped addresses:
Memory address 0xffffff00 0xffffff0f 0xffffff10 0xffffff1f 0xffffff20 0xffffff2f 0xffffff30 0xffffff34 Function encryption key plain text input encrypted output load (write 0x00000001 to the address) done (read back as 0x00000001 on assert)

3.4 AES Decryption Interface The decryption acts as a link between the OPB bus and the actual AES decryption core. The decryption interface operates in a similar fashion to the encryption interface (see above). The following chart summarizes the memory mapped addresses:
Memory address 0xfffffe00 0xfffffe0f 0xfffffe10 0xfffffe1f 0xfffffe20 0xfffffe2f 0xfffffe30 0xfffffe34 0xfffffe38 0xfffffe3c Function decryption key encrypted input plain text output load (write 0x00000001 to the address) done (read back as 0x00000001 on assert) key load (write 0x00000001 to the address) key done (read back as 0x00000001 on assert)

3.5 Example of Operation using XMD

// load 128 bit encryption key mwr 0xffffff00 0x12341234 4 w // load 128 bit unencrypted data mwr 0xffffff10 0x88888888 4 w // pulse the load control signal (interface automatically asserts for 1 cycle) mwr 0xffffff30 0x00000001 // read the done control signal to ensure the encryption is done mrd 0xffffff34

// clear the done signal mwr 0xffffff34 0x00000001 // read the encrypted data mrd 0xffffff20 4 w // load 128 bit decryption key mwr 0xfffffe00 0x12341234 4 w // pulse the key load control signal (interface automatically asserts for 1 cycle) mwr 0xfffffe38 0x00000001 // read the key done control signal to ensure the key is finished loading mrd 0xfffffe3c // clear the key done signal mwr 0xfffffe3c 0x00000001 // load 128 bit encrypted data mwr 0xfffffe10 <first 32 bits of encrypted data> mwr 0xfffffe10 <second 32 bits of encrypted data> mwr 0xfffffe10 <third 32 bits of encrypted data> mwr 0xfffffe10 <fourth 32 bits of encrypted data> // pulse the load control signal mwr 0xfffffe30 0x00000001 // read the done control signal to ensure the encryption is done mrd 0xfffffe34 // clear the done signal mwr 0xfffffe34 0x00000001 // read the decrypted data (should be the same as the original data) mrd 0xfffffe20 4 w

4 Description of Design Tree

The design tree is essentially that of an XPS project. The AES cores and interfaces are inside the /pcores/ directory. There is an example OPB interface named led inside the /pcores/ directory as well. This was our first attempt to create a basic memory mapped interface. It allows memory access to registered inputs and outputs. The original intention was to connect one of the wires to the GPIO and onto the user_led_0 light. However, debugging using XMD provided us with sufficient evidence that the OPB interface functional. The following table relates the directory name with the logic core:
Directory Name aes_cipher_top aes_inv_cipher_top aesint_v1_00_a aesinvint_v1_00_a led_v1_00_a Logic Core AES Encryption Core AES Decryption Core AES Encryption Interface AES Decryption Interface OPB interface example (not used in this XPS project)

5 References
[ECE04] [OP04] ece532h1s, http://courses.ece.utoronto.ca/ece532h1s, 2004. OPENCORES.ORG, http://www.opencores.org/projects.cgi/web/aes_core/overview, 2004.