FPGA based Encryption co-processor design

Parisa RazaghiTimothy Van Ruitenbeek

Chintan Patel

What problem are we trying to solve?

• Embedded systems can be prone to hacks by malicious users who could get unauthorized access to certain important data.

• We are attempting to create an FPGA based solution that will enable systems to be secure during the power-off state.

• Today, there are solutions available that generally implement static encryption techniques. FPGA implementation allows us to have the option of dynamically changing encryption keys/algorithms if needed.

System Overview

i.MX21

Flash

SDRAM

FPGA SD card

• When the system powers up, it uses the Flash memory to load up the bootloader. • The bootloader (in this case, Umon) would then decrypt the OS image (zImage) and load into RAM, and then the ARM core would start booting from the image• Once in Linux, the SD card would be mounted as a filesystem instead of the Flash based JFFS2 filesystem available on all the boards by default• The linux drivers would direct all filesystem traffic to the SD card, via the FPGA.• The FPGA would encrypt the data, and then commit the writes to the SD Card. On read requests, the FPGA would decrypt the data in the SD card and send the data back to the ARM core.• We had to use the SD card because there wasn’t enough room on the existing Flash device to add an encrypted linux data filesystem.

Task Breakdown

• Initial feasibility and scoping – All• Encryption research/Umon changes – Chintan• Linux changes – Tim• FPGA SD Card interface – Parisa• FPGA encryption engine – All

Encryption

• There are several encryption techniques that are used in the industry today. The choice depends on the type of application, and the level of hw/sw afforded to accomplish the goal

• There are two main types of encryption algorithms– Symmetric Encryption– Asymmetric Encryption

Symmetric Encryption• Also Known As

– symmetric-key encryption– single-key encryption– one-key encryption – private key encryption

• The sender and the receiver know about the key in advance. They both share the same key.– Advantage – quicker and easier to implement– Disadvantage – not as secure

• There are two main types of Symmetric Encryption algorithms1. – Stream Ciphers – encrypt/decrypt bits or words are a time. This is less secure

as this requires the key header to be transferred a lot more often per given amount of total data transmission. These are, however, easier to implement. There aren’t too many real-world uses for this type of encryption as most encryption uses are for larger datasets (or blocks) at a time.

– Block Ciphers – encrypt/decrypt blocks of data at a time. This method is more secure but requires a more complicated implementation as well as a need to buffer the data. Common examples include AES and DES

1http://www.discretix.com/PDF/Strength%20Assessment%20of%20Encryption%20Algorithms.pdf

Asymmetric Encryption• Also Known As

– Public-key encryption• There is a unique pair of keys, one public and one

private, that is created from a singular password.• The public key is shared with anyone who wants to

send the data. • Only the user who has the private key can decrypt the

data. It is very difficult to create the private key from the public key, so this makes this algorithm quite secure

• Most common example is RSA

Why change boot loader?• Most current systems do not worry about encrypting the

OS itself, so this project is novel in that respect.• This allows us to store an operating system image (zImage)

that cannot be booted unless the right key is supplied. • The approach taken here was to augment the “tfs cp”

function in umon, to add an encrypt/decrypt option. This way, a previously encrypted zImage of Umon would be decrypted and loaded into memory to proceed with booting. For proof of concept in the umon modifications, a simple XOR based stream cipher was implemented and proven to work.

Other approaches

• The first attempt was to make a standalone binary that would implement a block level encrypt/decrypt cipher in Umon.

• Compiled newlib and uClibc to try and make it work with the bare-metal binutils.– This proved to be non trivial and seemed to

require very specific configurations to make the compile work on our specific platform using bare-metal binutils.

Testing/Validation• Modified Umon was loaded on a spare

developmental board (not physically in the lab).• Created new encrypted zImage file in the tfs

filesystem using the modified command. This uses 0xFEEDC0DE as the key to encrypt the zImage– tfs cp zImage zImage_encrypt 0xFEEDC0DE

• Modified linuxd script to make the following call– tfs cp zImage_encrypt $APPRAMBASE 0xFEEDC0DE

• This loaded linux just like normal

SD Card Connection

• System structure– Communication Interface

• FPGA - ARM• FPGA - SD Card

SD Memory

• Secure Digital (SD) card– removable flash-based storage device

• Usage– Digital cameras, small portable music devices– Embedded systems

• Features– Low power– Small & cheap– Simple interface

SD Interface (1)

• Serial data communication– Max 6 wires for communications– Data rates in the Mbps range

• Communication Protocol– SD mode

• 1-bit & 4-bit protocol

– SPI mode

SD Card Pin Assignments

Pin Name Function (SD mode) Function (SPI mode)1 DAT3/CS Data Line 3 Chip Select/Slave Select (SS)

2 CMD/DI Command Line Master Out Slave In (MOSI)

3 VSS1 Ground Ground

4 VDD Supply Voltage Supply Voltage

5 CLK Clock Clock

6 VSS2 Ground Ground

7 DAT0/DO Data Line 0 Master In Slave Out (MISO)

8 DAT1/IRQ Data Line 1 Unused or IRQ

9 DAT2/NC Data Line 2 Unused

SD Communication Structure

• Card initialization• Block read• Block Write

Communication Protocol Complexity

©Copyright 2001-2006 SD Group (Panasonic, SanDisk, Toshiba) and SD Card Association

SD Controller (1)

• IP Core # 1– spiMaster [opencores.org, Author: Steve Fielding]

• Features– Full SD/MMC memory card support

• Card initialization, block read, and block write.

– Basic SPI bus access– 512 byte receive and transmit FIFOs– 8-bit slave Wishbone interface

Implemented System for “masterSPI”

• User application (interface to FPGA)– Sends start address for read/write block– Sends start command, and checks status register

• FPGA– masterSPI controller

• A state-machine for writing Proper values into registers

– MZ_CPLD-Wishbone bridge

8-bit Wishbone

Slave IF

8-bit Wishbone

Slave IFSPI IFSPI IF

System Test for “masterSPI”

• ModelSim simulation– Abstract model of SD Card– Sending command for initialization, block read, block write– Passed all tests

• Developed on the board– Generates SPI signals on output ports– Receives command error from SD Card

• Problems and limitations– Support up to 2Gbyte card– Not sure if it changes the SD Card to SPI mode correctly

SD Controller (2)

• “sd card controller” – [http://www.opencores.org/?

do=project&who=sdcard_mass_storage_controller&page=overview 2009-05-20 ]

• Features – 32-bit Wishbone Interface – DMA Buffer Descriptor – SD 4-bit mode – Interrupt-on completion of Data and Command

transmission

Implemented System for “SD card controller”

• User application (interface to FPGA)– Needs to initialize all internal registers of SD card

controller with proper values for initializing the card or read/write command

• FPGA– MZ_CPLD-Wishbone bridge– Memory access management

32-bit Wishbone

Slave IF

32-bit Wishbone

Slave IF

4-bit SD IF4-bit SD IF

32-bit Wishbone master IF

32-bit Wishbone master IF

System Test for “SD card controller”

• ModelSim simulation– Complete model of SD Card– Sending command for initialization, block read, block write– Passed all tests

System Debugging Flow

• Developed on the board– Does not generate proper values for internal signals– No SD card communication

• Debugging mechanism– Monitoring internal signals: failed – Post-synthesis simulation : failed

• top.v and sdc_controller.v

Next Steps of Debugging

• Partition the sdc_controller into sub-components and apply post-synthesis simulation on one component at a time

• Board connection test– More reliable IP components

• Xilinx EDK tool set– Soft-core Processor– Xilinx SPI IP Core

Linux Filesystems• Two places to intercept data for software

encryption/decryption:

– Filesystem driver

– Device driver

Lecture 8, slide 47

Device Driver Encryption• Pros:

– Physical storage devices are accessed in sectors, so block encryption algorithms fit.

– Only have to modify the device driver in order to allow any filesystem type to be encrypted on that device.

– Can also encrypt inodes/metadata stored on the disk, so file sizes and locations cannot be determined from analysis.

– Modify physical address for different sectors in the same file to make access pattern analysis more difficult.

• Cons:– Couldn’t find the correct driver used by the iMX21 system– …/drivers/mtd/* for flash drivers

Filesystem Encryption

• Since we wanted to avoid modifying the JFFS2 partition, we decided to add encryption to the ramdisk used for /tmp and /382n-4.

• ‘mount’ shows /tmp is a tmpfs on /dev/shm• Kernel code is in …/mm/shmem.c• Modified the read and write functions:

– static ssize_t shmem_file_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos)

– static ssize_t shmem_file_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)

Booting a modified zImage

• Copy zImage to iMX21 for uMon to boot.– 1+ MB image, uses up flash wear cycles– Usually only need to boot each version once

before changes are made

• Solution– Modify linuxd script to replace ‘tfs cp’ with

‘xmodem -d -a $KERNEL_RAM_ADDR’– This copies the zImage over the serial port directly

to the correct RAM location to boot.

Project Changes / Extensions• Get full documentation on the system

– SD card <-> FPGA interface• Use a different system that already has SD card

support (Beagleboard?)• Use the FPGA block ram as a tmpfs to do hardware

encryption– skip the SD interface problems– still able to implement the algorithm in hardware

• Implement a real encryption protocol instead of proof-of-concept XOR– compare speed between hardware and software

implementations