Abstract

Protecting the intellectual property of software that is distributed to third-party devices which are not under full control of the software author is difficult to achieve on commodity hardware today. Modern techniques of reverse engineering such as static and dynamic program analysis with system privileges are increasingly powerful, and despite possibilities of encryption, software eventually needs to be processed in clear by the CPU. To anyhow be able to protect software on these devices, a small part of the hardware must be considered trusted. In the past, general purpose trusted computing bases added to desktop computers resulted in costly and rather heavyweight solutions. In contrast, we present Soteria, a lightweight solution for low-cost embedded systems. At its heart, Soteria is a program-counter based memory access control extension for the TI MSP430 microprocessor. Based on our open implementation of Soteria as an openMSP430 extension, and our FPGA-based evaluation, we show that the proposed solution has a minimal performance, size and cost overhead while effectively protecting the confidentiality and integrity of an application’s code against all kinds of software attacks including attacks from the system level.

Paper: Soteria (by Johannes Götzfried, Tilo Müller, Ruan de Clercq, Pieter Maene, Felix Freiling, and Ingrid Verbauwhede)
Slides: Soteria Slides (presented at ACSAC’15, Los Angeles, California, USA)

Installation

Soteria builds on top of Sancus and therefore installation and usage is very similar to Sancus as well. To install Soteria proceed as described on the Sancus installation page but instead of using the sancus-core and sancus-compiler sources from the Sancus installation page use our patched and extended sources below. Note that you need to build everything from source and we currently do not provide ready-to-use packages for your distribution. The patched version of LLVM can simply be installed by following the instructions on the Sancus installation page with the original patches provided there. For a first start, it is safe to skip all FPGA-related stuff!

Usage

Toolchain

In addition to the tools that are installed by plain Sancus and described in detail on the Sancus documentation page, Soteria installs a tool for code encryption sancus-crypt:
usage: sancus-crypt [-h] [--verbose] [--debug] [--loader SPM] [--cryptkey SPM] --key key [-o file] [file]
The tool expects the vendor key to be given as key and operates in one of two modes: If cryptkey and the name of an SPM is specified, sancus-crypt derives the loader key and calculates the encryption key for the target module by the name of the module specified with cryptkey. If cryptkey is not given, sancus-crypt derives the loader key and transparently encrypts all SMs that are found within an image by first deriving the encryption key from their name. SMs that need to be encrypted are identified by starting with crypt_. If the name of the loader module is not specified by the loader argument, the default name sm_loader is assumed.

FPGA: Xilinx Virtex6 ML605

Our design has been successfully tested on a Xilinx Virtex6 ML605 FPGA evaluation board. We provide the working implementation for this board in $SOURCE_ROOT/fpga/xilinx_virtex6_ml605_spm. The implementation supports UART, GPIO and Debugging. We use the default user clock with 60Mhz, but the openMSP430 is running at 20Mhz and therefore the coregen files to provide the correct clock frequency but also block RAM are included. The USB UART interface is used for debugging and serial I/O and DIP switch 8 can be used to switch between debugging mode and usual operation. The south switch of the 4-way joystick-like switches has been used as reset button and should be triggered after switching with DIP switch 8. DIP switch 1 – 3 can be used for GPIO.

Example Applications

We provide an example application that demonstrates the proposed software protection functionality in simulation and on the FPGA. The application loads an encrypted software module which contains a secret string and calls routines of the encrypted module from unprotected code and a second software module. The second software module also generates a signature for this secret string. The software module can only be loaded and outputs the secret string, if there was no manipulation of the loader module or the encrypted module. Furthermore, software in unprotected memory tries to access code of the encrypted module after it has been loaded and fails such that finally a reset is triggered and all confidential code is wiped from memory.

The applications are shipped with Makefiles that demonstrate how the whole toolchain works together. Please check also the documentation of the original Sancus toolchain and our paper for more information!

Get the Code

Implementation:
soteria-core.tar.bz2: Patched openMSP430 processor implementation in Verilog (FPGA implementation included)
soteria-compiler.tar.bz2: Host toolchain for building and encrypting software modules
soteria-test.tar.bz2: Test applications to demonstrate software protection functionality (Simulation and FPGA)