# Hardware Considerations

# Security Challenges

Ideal for the security of this application would be to ensure that no information that can be used as an attack surface is ever present outside of the main device package. Such a configuration rules out all but the most concerted attacks, which require intricate knowledge of the target device which is generally not available, sometimes even to defenders.

Since the FPGA configuration is loaded via a secure method, the direct attack of which is forbidden by this competition, any configuration data in the FPGA can be considered secure. Careful design of the programmable logic can extend this security to transient data and programs running inside. Thus, if encrypted data enters the FPGA, is processed exclusively there, and then audio outputted, the overall design may be considered secure.

The reference design consists of a MicroBlaze soft CPU implemented in the FPGA. This CPU is effectively isolated from the hard CPU, which is considered compromised due to the attacker having root access. The MicroBlaze program is controlled via a shared area of memory inside the FPGA. Some additional fault injection isolation could be achieved by moving this functionality to a more specialized type of memory similar to a peripheral register in a microcontroller, over which the MicroBlaze would have greater authority. This feature, known as the command register, takes over some of the more important functions, and automatically issues an interrupt to the MicroBlaze when written to

An integrity monitoring system was proposed to protect the FPGA from side channel attacks. This system would monitor voltages, die temperature, detect a stopped clock or paused MicroBlaze program, and detect clock glitches. The last of these features was not implemented, due to time constrains, and partially due to the assumption that the internal PLL generated clock would be very difficult to attack with clock glitching techniques. In the present implementation, voltage and temperature are monitored by an on chip ADC alarm system, while a stopped MicroBlaze is detected via a watchdog timer.

# Microblaze Performance

Initially, efforts were made to separate the MicroBlaze into its own clock domain, which could allow it to be better implemented at higher frequencies. This was, on several occasions, enough to boost the MicroBlaze core clock to 140MHz, with the remaining IP still clocked at 100MHz. This also resulted in a significant increase in FPGA resource utilization, required for clock domain crossing logic automatically added to interconnects and miscellaneous signals. The reset scheme for the device was also significantly complicated, requiring about three times as many reset signals, as each signal had to be de-asserted in sync with its clock domain. The device would also have a high chance of failing timing requirements if significant changes were made to any part of the design, leading to numerous wasted builds.

It was ultimately determined that the reference design performance of the MicroBlaze soft CPU was sufficient for almost any decryption scheme, and thus capable of playing songs uninterrupted. Given a required throughput of 96KBps (48KHz sample rate at 2 bytes per sample) and an estimated decryption performance of 4 cycles per byte, the processor utilization for decryption alone would be approximately half a percent. The overhead from other code was assumed to be low, given input data was supplied via DMA.

# Song Datapath

Over the course of this project the term Song Datapath was unofficially coined to describe the flow of song data from the storage device to the audio codec. Several changes were made to the data-path to incorporate the MicroBlaze as the means of decryption. It was initially proposed that dedicated crypto IP be obtained for this purpose, but this became unnecessary as the MicroBlaze’s performance was more than sufficient for the chosen cryptography scheme.

The final structure of the datapath is as follows. The host program (miPod application) loads the song from the file system into a known physical location in DDR, represented by a device file which is defined in the device tree when the Linux image is built. A DMA transfer is used to fill a FIFO, known as the input FIFO, which is then readable from a dedicated stream port on the MicroBlaze. The MicroBlaze decrypts the samples using a byte-by-byte decryption scheme and outputs them to another stream port, which fills a second FIFO, known as the output FIFO. This second FIFO is then clocked into an I2S codec IP which produces the I2S signal that drives the output device.

The changes made to this datapath remove an extra step where the MicroBlaze initiates a memcpy from the initial song location in DDR to a temporary buffer in the FPGA. The purpose of this step is unknown, and it was removed because a call to memcpy would occupy the CPU for no necessary reason. All DMA transfer are issued from the MicroBlaze, no access to this feature is given to the main processor, to prevent potential DMA based attacks.

Additional GPIO IP were added to allow the fill level of each FIFO to be monitored from the MicroBlaze. The clocking IP which drove the audio codec clock domain was also modified to be configurable at runtime, allowing audio to be played at an arbitrary sample rate. Stereo output support was also added by splitting the output path into two channels. Playing mono audio in this setup simply requires that each 16-bit mono sample be output “doubled up” to fit the 32-bit width of the output stream.

Though the input FIFO is a simple solution, it may have presented challenges in the event the cryptography scheme was changed. Accessing data out of order is especially problematic, since data can only be “popped” out of the FIFO from the end. A more advanced solution might consist of a memory mapped storage scheme, which could keep track of where each run of incoming data was copied from. Such a setup would make it much easier to use the input FIFO as a general purpose interface between the MicroBlaze and main processor.

# Memory

In the chosen scheme, the entire MicroBlaze memory is implemented with internal block RAM, chosen for its resistance to board and OS level attacks as outlined in Xilinx documentation. 128KB is available which must be shared between code, such as text and rodata sections, as well as stack and heap space. When the text size is large compared to the total available memory, stack to heap collisions become extremely likely and fairly irritating to diagnose. Ultimately, the small available memory resources available in the FPGA fabric make it difficult to incorporate sufficient cryptography features.

One option to expand available memory is to utilize the on-board DDR, which is accessed through a shared memory interconnect. The MicroBlaze Reference Manual suggests that this has a significant impact on performance depending on data locality (random vs. sequential accesses, presence of cache, etc), which may not have been significant given the predicted low core utilization when a song is actually playing. More significantly is the DDR's susceptibility to attack at an operating system level. Given attackers would have root access to the host operating system, reading arbitrary data from DDR is as simple as reading from /dev/mem. An in-FPGA encryption system between the MicroBlaze and the DDR interconnect could mitigate this attack surface partially, but fault injection attacks would remain a very serious threat, since physical write access to the DDR cannot be denied. Fully incorporating any portion of the DDR into the secure portion of the design would require additional integrity monitoring which would in turn require an extreme amount of FPGA design work. The late stage at which these memory concerns arose made work into this solution impractical compared to attempts to reduce the code size.

Last Updated: 4/24/2020, 9:43:53 PM