Home

Introduction

SecureMark®-V2 is a benchmark created by EEMBC® to help glean insight into the performance and power costs associated with implementing cryptography in an embedded product. It does this by providing several pre-defined cryptographic suites running on top of a portable API. The API facilitates the use of any type of cryptographic acceleration, from external hardware peripherals, to specific ISA instructions, to even different cryptographic libraries. On top of the API, each suite is based on the analysis of a real-world scenario, but presented in way that isolates the compute portion while avoiding the need to worry about other application related middleware, such as the TCP stack, or hardware drivers. Instead, it focuses specifically on the cryptographic primitives.

The three suites SecureMark-V2 focuses on are the TLSv1.3 and TLSv1.2 handshakes, and secure boot. Each suite, when run, produces a single score consisting of a weighted combination of the primitive time and/or energy cost. The suites can be configured to use different strengths: light, medium and heavy. These strengths reflect common design choices based on what type of hardware is available in the product’s budget. In addition to the suites, SecureMark-V2 also provides a sandbox for exploring the characteristics of the primitives as well.

Through these capabilities, SecureMark-V2 enables all aspects of a project design, from marketing, to engineering, to validation, and software verification. These capabilities make SecureMark-V2 a highly functional analysis tool.

SecureMark-V2 is the second version of our security suite that started with SecureMark-TLS.

Overview

The benchmark consists of a core firmware that acts as the primary application once the DUT setup has completed. The application enters a UART Rx polling loop waiting for instructions from a host that tell it what suites to run, and how to configure them. The host application is a GUI that runs on Windows, Mac or Linux, and connects to the DUT two different ways: directly via a UART, or through the energy framework. The first mode of connection is called “performance mode”, and the latter is referred to as “energy mode”. Performance mode has fewer hardware components in the framework, but as the name suggests, you can only measure performance. To measure energy, additional hardware is required. The same host GUI can run both modes, only the connectivity to the DUT changes.

Theory of Operation

Each of the suites executes a set of primitives that reflect the cryptographic compute load of a particular application. The size of the inputs and the weighted contribution of the results were all determined by profiling libraries. For example, the TLSv1.3 light handshake suite was extracted from an OpenSSL handshake using the WolfSSL library. GDB was used to extract the function calls at each handshake stage. From this matrix of data, we could extract each primitive’s context, how long it persisted, and each call to it including the size of the input data per call. Since the cryptographic functions are >99% of the runtime, the intermediate buffering has no impact on the score, so we can discard this and instead create a benchmark based on just the extracted profiling data, reducing it to cryptographic calls. The same was done for Secure Boot using MCUboot. We refer to these suites as “Synthetic Secure Boot” because the energy & performance cost of actually booting are not counted, just the crypto load.