Simple AEAD Hardware Interface (SÆHI) in a SoC: Implementing an On-Chip Keyak/WhirlBob Coprocessor

Simple AEAD Hardware Interface (SÆHI) is a hardware cryptographic interface aimed at CAESAR Authenticated Encryption with Associated Data (AEAD) algorithms. Cryptographic acceleration is typically achieved either with a coprocessor or via instruction set extensions. ISA modifications require re-engineering the CPU core, making the approach inapplicable outside the realm of open source processor cores. At minimum, we suggest implementing CAESAR AEADs as universal memory-mapped cryptographic coprocessors, synthesizable even on low end FPGA platforms. AEADs complying to SÆHI must also include C language API drivers targeting low-end MCUs that directly utilize the memory mapping in a ``bare metal\u27\u27 fashion. This can also be accommodated on MMU-equipped mid-range CPUs. Extended battery life and bandwidth resulting from dedicated cryptographic hardware is vital for currently dominant computing and communication devices: mobile phones, tablets, and Internet-of-Things (IoT) applications. We argue that these should be priority hardware optimization targets for AEAD algorithms with realistic payload profiles. We demonstrate a fully integrated implementation of WhirlBob and Keyak AEADs on the FPGA fabric of Xilinx Zynq 7010. This low-cost System-on-Chip (SoC) also houses a dual-core Cortex-A9 CPU, closely matching the architecture of many embedded devices. The on-chip coprocessor is accessible from user space with a Linux kernel driver. An integration path exists all the way to end-user applications

Implementation and Benchmarking of Round 2 Candidates in the NIST Post-Quantum Cryptography Standardization Process Using Hardware and Software/Hardware Co-design Approaches

Performance in hardware has typically played a major role in differentiating among leading candidates in cryptographic standardization efforts. Winners of two past NIST cryptographic contests (Rijndael in case of AES and Keccak in case of SHA-3) were ranked consistently among the two fastest candidates when implemented using FPGAs and ASICs. Hardware implementations of cryptographic operations may quite easily outperform software implementations for at least a subset of major performance metrics, such as speed, power consumption, and energy usage, as well as in terms of security against physical attacks, including side-channel analysis. Using hardware also permits much higher flexibility in trading one subset of these properties for another. A large number of candidates at the early stages of the standardization process makes the accurate and fair comparison very challenging. Nevertheless, in all major past cryptographic standardization efforts, future winners were identified quite early in the evaluation process and held their lead until the standard was selected. Additionally, identifying some candidates as either inherently slow or costly in hardware helped to eliminate a subset of candidates, saving countless hours of cryptanalysis. Finally, early implementations provided a baseline for future design space explorations, paving a way to more comprehensive and fairer benchmarking at the later stages of a given cryptographic competition. In this paper, we first summarize, compare, and analyze results reported by other groups until mid-May 2020, i.e., until the end of Round 2 of the NIST PQC process. We then outline our own methodology for implementing and benchmarking PQC candidates using both hardware and software/hardware co-design approaches. We apply our hardware approach to 6 lattice-based CCA-secure Key Encapsulation Mechanisms (KEMs), representing 4 NIST PQC submissions. We then apply a software-hardware co-design approach to 12 lattice-based CCA-secure KEMs, representing 8 Round 2 submissions. We hope that, combined with results reported by other groups, our study will provide NIST with helpful information regarding the relative performance of a significant subset of Round 2 PQC candidates, assuming that at least their major operations, and possibly the entire algorithms, are off-loaded to hardware

Type-Safe Data Plane Programming

Since the mid-1990s, there have been efforts to enable more flexible processing of network packets by making packet processing programmable. With the advent of software-defined networking (SDN), this idea has now become a reality. Early approaches initially focused on control plane programming, with the goal of implementing centralized network policies at a high level of abstraction without having to use low-level, device-specific configuration mechanisms. For this purpose, various network programming languages have been developed, which provide correctness guarantees and make the formal verification of network policies possible. More recently, it is also possible to program the network data plane. Being able to define the structure of network packet headers freely, opens up a whole new range of applications, from implementing new network protocols up to moving application logic directly into the network. Until today, the P4 language has become the de facto standard for programming data planes. While P4 provides declarative abstractions for programming data planes, P4 lacks basic safety guarantees to help avoid errors and implement correct applications for the data plane. Modern programming languages use static type systems to provide languages with basic safety guarantees that completely eliminate the occurrence of entire categories of errors. Surprisingly, however, the use of type systems in the field of network programming has hardly been investigated. This dissertation investigates what appropriate type systems must look like in order to provide data plane programming languages—in particular, P4—with static correctness guarantees. As a first step, we present SafeP4, a domain-specific language for programmable data planes that is equipped with a static type system that guarantees that all headers that are read or written are valid, which is a common cause of errors. We then present Π4, whose type system is based on dependent types and is thus able to bridge the gap in terms of expressiveness between SafeP4 and full-fledged verification tools. At the same time, Π4 enables modular verification of programs. Our evaluation using open source programs confirms that accessing invalid packet headers is a common source of errors in practice and that the SafeP4’s type system is capable of identifying buggy programs. Using case studies, we show that Π4’s type system is capable of expressing and verifying a variety of real-world correctness properties