Integrating Lorenz Hyperchaotic Encryption with Ring Oscillator Physically Unclonable Functions (RO-PUFs) for High-Throughput Internet of Things (IoT) Applications

Abstract

With the combined call for increased network throughput and security comes the need for high-bandwidth, unconditionally secure systems. Through the combination of true random number generators (TRNGs) for unique seed values, and four-dimensional Lorenz hyperchaotic systems implemented on a Stratix 10 Intel FPGA, we are able to implement 60 MB/s encryption/decryption schemes with 0% data loss on an unconditionally secure system with the NIST standard using less than 400 mW. Further, the TRNG implementation allows for unique encryption outputs for similar images while still enabling proper decryption. Histogram and adjacent pixel analysis on sample images demonstrate that without the key, it is not possible to extract the plain text from the encrypted image. This encryption scheme was implemented via PCIe for testing and analysis.

1. Introduction

The Internet of Things (IoT) is the ever-growing collection of devices with access to the Internet for means of communication, data acquisition, data transmission, and system monitoring. Devices integrated with the IoT are not always devices that first come to mind, such as wearables and cell phones, but also include vehicles, food monitoring systems within restaurants, security systems, pet monitoring devices, and even agricultural systems. These devices are constantly evolving, with calls for lower power consumption, decreased form factors, improved security, and increased throughput, with unique requirements depending on the device application [1].

One major issue for IoT devices is high-throughput security that could potentially be used for applications such as image and video encryption while maintaining a low power profile. Meeting this need is non-trivial, as trade-offs must be made between power management and security. Often, when increasing the security of a system, there comes the innate need for more power. This is a difficult decision for IoT device engineers and is often application-specific. Meeting these privacy needs comes with a few obstacles:

• Processing power: The power of on-board processing within IoT devices is often reduced to save power. Many IoT devices do not have a constant power source and instead rely on a battery to increase the mobility of the device. In fact, many IoT devices do not have a central CPU at all and instead rely on a Field-Programmable Gate Array (FPGA) or Application-Specific Integrated-Circuit (ASIC).
• Power consumption: Increased complexity in cryptographic algorithms will draw more power. For example, the use of Digital Signal Processors (DSPs) for complex mathematical functions on ASICs or FPGAs, such as ordinary differential equations or transforms, will require additional power.
• Easy access: With the wide range of IoT applications and the growing array of connected devices, it has become easier than ever for an attacker to get inside a network. A single device’s vulnerability can expose the entire network that is otherwise secure [2]. Further, with the mobility of IoT devices such as wearables and remote sensing units, new vulnerabilities are constantly being discovered outside the security of traditional, local networks.

This work focuses on implementing multiple techniques for IoT encryption with an emphasis on increasing throughput, encrypting plain text security, and reducing power consumption. We are able to utilize a Lorenz hyperchaotic encryption system on an Intel Stratix 10 FPGA using Physically Unclonable Functions (PUFs) for random seed generation. The motivation for this work is as follows:

• Providing a secure, hyperchaotic method for high-speed image encryption.
• Securing the private key from hardware-replication methods and side-channel attacks.
• Allowing for a configurable key refresh rate.
• Providing a small power and resource footprint for resource-constrained devices.

Besides of the low power and high throughput of our system, our implementation is unique in two ways. First, it provides a unique encrypted key for every 24 bits. This makes the system significantly harder to crack, as breaking even a single key will only allow the attacker access to less than four bytes of data. This is critical for high-security systems, as methods have been introduced that can break a single-seed Lorenz system using synchronization methods [3], machine learning detection of initial conditions [4], or various other crypt-analysis techniques such as plaintext attacks [5,6,7]. With our implementation of frequently refreshed keys, our system is immune to plaintext and side-channel attacks that the predecessors fell victim to. Second, we use PUFs to generate these keys, which prevents device synchronization for cloning attacks due to the unique PUF output relative to the device it is implemented on.

Further, we demonstrate an implementation of this system via Peripheral Component Interconnect Express (PCIe), which allows for data and power analysis. Via this implementation, we can stress the system with a variety of images from the Signal and Image Processing Institute, including black-and-white images, high-definition images, and low-resolution images. Our results will demonstrate that through the use of PUFs, encrypted variations of identical images are dissimilar to the point of complete uniqueness. Further, our results yield that images of varying resolutions and color quality do not have an adverse effect on the encryption results.

Our work for the Lorenz hyperchaotic encryption system is organized as follows: Section 2 provides a brief background on the topics of PUFs, Lorenz Encryption, and their integration methods with FPGAs. Section 3 discusses how we went about implementing the system on an FPGA, in addition to computer simulations that demonstrate the volatility (and therefore security) of our system. Section 4 covers the output of our system, including power usage, the responses to different image types, and the statistical analysis of ciphers. Section 5 discusses the potential for improving the system and where it could be utilized. Finally, Section 6 concludes the paper.

2. Research Background

This work relies on two major components, which can be considered separately: a true random number generator (TRNG) that relies on noise from hardware internal to the FPGA, and a Lorenz hyperchaotic encryption system that relies on the output of the TRNG for seed generation. For this reason, we explore research on the two topics individually.

2.1. Building a True Random Number Generator

Random number generators have a wide array of applications, ranging from lottery drawings, research involving probability and statistics, cryptography, and seeding for sequential systems. For this reason, it is imperative that TRNGs meet strict metrics regarding the lack of reproducibility and unpredictability.

There are also many pseudo-random number generators (PRNGs) which can generate seemingly random results, although these results are often the output of mathematical equations that can be replicated. For example, pseudo-random binary sequence (PRBS) patterns are often used for hardware validation, as these patterns have a random output that can be replicated. Outlined in the Built-In Self Test (BIST) checker by Bhandari et al., a PRBS pattern is input into individual components, such as DSPs. Since the output of these components can be calculated before the PRBS pattern is input to these components, thanks to the reproducibility of the PRBS pattern, the actual output from the components can be compared against the expected output, thereby determining if a device is functional or not.

The PRBS pattern is used to specifically stress the component with a large variety of testing inputs. Bhandari’s implementation, specifically, utilizes Linear Feedback Shift Registers (LFSRs), which are known to have configurations that produce maximum $2^n-1$ bit streams before repeating numbers. LFSRs, by definition, are a vector of bits where the leading (most significant or least significant bit, depending on implementation) is a linear function of the previous vector state. Further, due to the simplicity of the structure of LFSRs, which include shift registers and a series of strategically placed logic gates, a user can see extremely high data rates from an individual LFSR. In Bhandari’s case, they achieved data rates of more than 12 Gbps [8].

With respect to PRNGs utilizing LFSRs, there are two primary modifications that are typically utilized within the state-of-the-art technology: the Galois configuration and the Fibonacci configuration. A configurable version of each configuration is described in a work by Li et al., and we refer the reader to this work for a more detailed background on the subject [9].

We cover the basics of the Galois and Fibonacci configurations here. The two rely on various types of logic gates for sampling the $n-1$ state, referred to as taps, while the XOR gate is the most common. Fibonacci LFSRs use cascaded logic gates from multiple taps, while Galois LFSRs utilize exclusively noncascaded logic gates [10]. Due to the lack of cascading in the Galois configurations, the Galois configuration will have a higher throughput, as there is a reduced propagation delay relative to the Fibonacci configuration. Fibonacci LFSRs, on the other hand, have the benefit that the $n+1$ sequence is immediately available from the n sequence: only the MSB uses the output of the taps, where the remainder bits are the outcome of a simple shift chain.

The two are compared in Figure 1 with a feedback polynomial of $x^8+x^6+x^5+x^4$. It is important to note that while both of these LFSRs have a period of 255, they are not equal, as the PRBS produced is dissimilar between the two. Also note that the Fibonacci LFSR in Figure 1a is labeled backward according to the taps in the feedback equation for easy comparison with the Galois LFSR.

The primary issue with PRNGs, especially in relation to cryptography, is that their output is predictable when a subset of sequential samples is given. For cryptographic purposes, a TRNG is required; that is not to say that we should discard the use of PRNGs. By the end of the section, we will have introduced how we can combine the principles for PRNGs and TRNGs into a robust TRNG for cryptographic purposes. First, let us explore some common architectures for TRNGs. Most digital TRNGs rely on metastability, the period where a signal has yet to stabilize between clock cycles, to generate their random numbers. While typical digital applications seek to eliminate metastability, TRNGs opt for maximizing metastability—resulting in the breaking of rules that most designs abide by, such as reducing clock skew, avoiding clock-crossing boundaries, decreasing propagation delays, and avoiding latches.

The most basic TRNG is a ring oscillator, which utilizes an odd number of inverters to produce an oscillatory signal that will be gated to a periodic clock signal. By using manual placement in an FPGA, the propagation delay can be extended for the ring oscillator, intentionally violating setup and hold times for the clock. These violations lead to the aforementioned metastability, which can have random outputs. When placed in stages, with registers between sets of ring oscillators of varying lengths, one can achieve random vectors of bits [11,12,13].

Another TRNG architecture that maximizes oscillatory metastability is the Transition Effect Ring Oscillator (TERO). Similar to a classic ring oscillator, a TERO uses a coupling of two AND gates and two XOR gates to produce a constant metastable state, which is then clocked into a flip-flop [14,15]. These TRNG principles can be combined with the Fibonacci and Galois LFSRs to create Fibonacci Ring Oscillators (FiROs) and Galois Ring Oscillators (GaROs). By utilizing a series of TEROs instead of basic flops for the Fibonacci and Galois configurations, one can have a suitable TRNG that can be implemented on hardware. Further, one can perform an XOR on the outputs of a FiRO with that of a GaRO to produce a further randomized number. This configuration is referred to as a NLFiGaRO [16].

A work by Tao et al. sought to increase the entropy of the NLFiGaRO system. To further reduce the stability of the system, and thereby increase the randomness of the output, one can introduce a free-running clock as an enable signal that is phase-shifted 90° from the clock signal that is used to sample the registers [17]. Thermal noise is further introduced by switching the NLFiGaRO system between the NLFiGaRO layout and that of a typical ring oscillator: when the system is disabled via the phase-shifted clock, the ring oscillators are running with a feedback loop internal to their respective stage in the NLFiGaRO system. This leads to an increase in temperature between the ring oscillators, further increasing the entropy of the system. While we modify this model for our purposes, we utilize the core structure of this work for seed generation. The NLFiGaRO system is displayed in Figure 2.

2.2. Physically Unclonable Functions

Physically Unclonable Functions (PUFs) utilize components that can have varying properties between devices that are caused by variations in manufacturing processes. Specific to FPGAs, PUFs often take advantage of variations in propagation delay between components within the fabric. These unique systems allow for protection against device cloning, which can quickly break a cryptographic system if the keys are known [18]. There are two primary categories of PUFs:

• Silicon: These rely on the uncontrollable differences in manufacturing between devices and do not require extra components outside of an FPGA. This category can further be broken up into delay-based PUFs, such as Arbiter PUFs [19,20] and RO PUFs [21,22,23,24], and memory-based PUFs, which utilize the entropy from volatile memory cells [25,26].
• Non-silicon: These PUFs are constructed using peripherals besides FPGA silicon for sources of entropy. This is a broad topic and may include the use of acoustics, optical fibers [27], and magnetics [28].

PUFs can and should be utilized within cryptographic systems to ensure that uniquely generated key-generation methods cannot be copied between devices. There are many low-power PUF examples that can be used to further enhance the security of IoT systems [29,30].

2.3. Lorenz Hyperchaotic Systems

Chaos can be described as a seemingly random output that can be modeled and replicated with some system of equations given that the initial conditions are known. Outputs of chaotic systems, such as the Lorenz system, are highly sensitive to the initial conditions of the system, with minor variations causing drastic changes to the output model.

Chaotic systems are formally defined as having at least one positive Lyapunov exponent. A Lyapunov exponent quantifies the rate of separation of infinitesimally close trajectories. In other words, a chaotic system will deviate between multiple iterations with small perturbations. Hyperchaos takes this concept one step further, requiring that the system of equations have a minimum of two Lyapunov exponents [31,32].

One such system that we used to implement secure encryption is the Lorenz hyperchaotic system (LHCS). The LHCS has been used in a variety of works and has proven useful for encryption [33,34,35,36]. A number of these methods, however, rely on software for encryption and therefore fail to realize a large data-throughput rate. By integrating these systems on hardware, such as FPGAs, one can maximize the data throughput, seeing encryption speeds increase by multiple orders of magnitude over similar software implementations.

In a work by Zou et al., a three-dimensional Lorenz chaotic system was used to encrypt and decrypt images [37]. This system modifies the classic Lorenz system by adding delay coupling and the modulo function to increase the complexity and frequency distribution of the system. Further, Zou implements a method to increase the size of the plaintext image, further increasing the complexity required to decrypt the output. This implementation is also resistant to data loss and noise attacks. The work implemented by Zou could be improved upon by utilizing a higher dimensionality of the chaotic system, further increasing the complexity required to break the key. However, because the system was not implemented on hardware, it had a relatively low data throughput.

Another work, by Ilyas et al., sought to implement an LHCS on an FPGA [38]. This work uses a 4D LHCS with a built-in self-security test module to ensure that generated keys are secure. Ilyas’ design manages to use less than 100 mW power for their implementation of the LHCS; however, their system has one primary shortcoming. The initial condition of their system is always a constant, which is stored in hardware. With this knowledge, it is possible to extract the keys from the FPGA and recreate the system for attack and decryption on a predatory device via either bitstream extraction or side-channel attacks [39,40,41]. For this reason, Ilyas’ system is not unconditionally secure. The system could be improved by introducing PUFs that are unique to the FPGA that the system is implemented on to increase the viability of their system.

A four-dimensional system was chosen based on previous works that evaluated three-, four-, and five-dimensional systems [42]. This work, by Bouteghrine et al., while evaluating chaotic systems (rather than hyperchaotic systems), demonstrates the trade offs behind implementing higher-dimensionality systems. Higher dimensions inherently lead to larger required resource utilization and therefore power consumption, so they may not be ideal for applications that require low power utilization. However, Bouteghrine’s work showed that a higher dimensionality leads to both a larger keyspace and larger reactions to perturbations, as demonstrated by an increase in Kolmogorov entropy relative to dimensionality. From the work, it can be determined that a five-dimensional system offers the most security, while a three-dimensional system offers the lowest power consumption. We opted for a four-dimensional system, which is a balance between the two.

3. System Design

Our background research of Lorenz systems shows that there is still work to be done so that the LHCS can be utilized to its full potential on hardware. Building off of the previous works, we seek to introduce the aforementioned PUFs into the chaotic system to further the entropy of the system, while still allowing for the decryption of the encrypted data. Our implementation method followed a three-step process. First, we designed and modeled the system via Python. Second, we constructed the LHCS on an FPGA and verified the model’s ability to encrypt and decrypt plaintext. Third, we inserted the design into a PCIe wrapper on a Stratix 10 FPGA from Intel and stressed the design via a custom Linux kernel and C++ programming on an Intel Sandy Bridge processor.

3.1. Lorenz Hyperchaotic System

The Lorenz hyperchaotic system (LHCS) that is explored within this paper can be described using the following four functions in Equations (1)–(4), where x, y, z, and w are initial conditions:

$$\dot{x}=F(t,x,y)$$

(1)

$$\dot{y}=G(t,x,y,z,w)$$

(2)

$$\dot{z}=Q(t,x,y,z)$$

(3)

$$\dot{w}=U(t,x)$$

(4)

The full mathematical model of the systems is described by Equations (5)–(8), where a, b, c, and d are constants that control the behavior of the Lorenz attractor.

$$\dot{x}=a(y-x)$$

(5)

$$\dot{y}=x(b-z)+w-y$$

(6)

$$\dot{z}=xy-cz$$

(7)

$$\dot{w}=-dx$$

(8)

3.2. Runge–Kutta 4 Method

The Runge–Kutta 4 (RK4) method is an iterative method used for temporal discretization for approximate solutions for simultaneous nonlinear equations, such as LHCS. The RK4 method calculates weighted averages across some step size h to estimate the next iteration within a system. The RK4 method has applications in hardware for power electronics [43], RNGs [44,45], and evaluating chaotic systems [46]. Iteration $n+1$ is the weighted average of four outputs through a time step h shown in Equation (9).

$$x_{n+1}=x_n+\frac{h(k_0+2k_1+2k_2+k_3)}{6}$$

(9)

For this equation, the functional outputs $k_n$ are required and can be determined from Equations (10)–(13). For the purposes of our Hyper-Chaotic Encryptor, $F(t_n,x_n)$ in Equations (10)–(13) is applied to Equations (1)–(4).

$$k_0=F(t_n,x_n)$$

(10)

$$k_1=F(t_n+\frac{h}{2},x_n+\frac{h\ast k_0}{2})$$

(11)

$$k_2=F(t_n+\frac{h}{2},x_n+\frac{h\ast k_1}{2})$$

(12)

$$k_3=F(t_n+h,x_n+h\ast k_2)$$

(13)

3.3. Computer Simulation

Prior to implementing our work on an FPGA, we verified both the stability of the LHCS and the perceived entropy of the system via computer simulations in Python. Our primary concern was the move from a continuous system, such as the ordinary differential equations of the LHCS, to a digital system, such as the FPGA logic environment. We began by implementing the Equations (1)–(8) via Python and modeling their output. For simulation, we used constants $a=5,b=20,c=1,d=0.1$, with a step size of $h=0.001$, and ran the model for 5000 iterations with various initial conditions.

Using floating point numbers, we observed the output of the system in Figure 3. We can see that the systems for the different initial conditions (IC), −91 and 55, exhibit unique outputs, as expected. We tested this model for our initial conditions, which are not shown here, all with uniquely varied outputs. One clear observation, however, is the settling of the output toward a final point. This is an anticipated behavior of the LHCS, as it is an attractor by definition. For this reason, we determined that we would have to periodically refresh key initial conditions. This does not become an issue until approximately 5000 iterations of key generation.

Another concern was the loss of entropy when moving from floating-point to fixed-point numbers, which were to be used in the digital implementation of the LHCS. Using publicly available Python packages, we reduced the computer simulation precision to 32 bit, 8Q24 fixed point notation. The output of the fixed point model, with the same parameters used in Figure 3, is shown in Figure 4.

We can see from Figure 4 that our prediction was correct: while the randomized output of the system differs relative to the initial conditions, the entropy of the system is significantly reduced. We modified this system by taking advantage of the inherent modulo function resulting from overflowing the 8Q24 format of the number. We increased the step size to 1.51 and further changed the initial conditions to $a=10,b=-28,c=-8/3$ and $d=-5$. While these parameters quickly force a continuous system to infinity, we are able to see a non-infinite system with the fixed-point format.

As we can see from Figure 5, there is significantly more entropy from the first two experiments. This is due to the constant overflow of the LHCS with the large step from the RK4 equations. This system of equations fails to converge on a single point, like the first system, and fails to follow a consistent trajectory, like the second system. It continues to exhibit unique output that is sensitive to the initial conditions.

Because of these uniquely chaotic properties, this is an ideal method for encryption, where one key can be systemically generated from the previous key, allowing for a high key-refresh rate with low predictability.

3.4. Dynamical Analysis of the Lorenz System

We evaluated the influence of the parameters a, b, c, and d on the Lorenz system to determine the proper hyperchaotic behavior in our final model. Two of the modified Lorenz systems we experimented with, systems (a) and (b), are shown in Figure 6. Their values are a = 7, b = 20, c = 4, d = 0.1 and a = 0.1, b = 0.2, c = 1, and d = 2, respectively.

For the final values used in our system, a = 5, b = 20, c = 8/3, and d = −20, we observe coexisting attractors from Equations (1)–(4). The Lyapunov exponents of this system are 6.4, 1.2, −2.7, and −13.6. With two positive Lyapunov exponents, this system can be defined as hyperchaotic [47]. The exponents integrated over time are shown in Figure 7. We can see from Figure 8 and Figure 9 that this system exhibits multiple attractors, indicating the non-uniqueness of the final state relative to the initial conditions [48].

3.5. FPGA Implementation

There are two primary components of the LHCS that we integrated: the PUF and the LHCS/RK4 system itself. The PUF is used for unique, 24-bit key generation, which serves as the initial condition for the LHCS encryptor/decryptor. We describe those two subsystems individually in Section 3.5.1 and Section 3.5.2

3.5.1. RO PUF

Our PUF is loosely based on the NLFiGaRO implementation of Tao et al. [17]. We use only five stage-delay cells to reduce power consumption, but extend the system to a full 24 bits, as our key is 24 bits in length. We opted for the NLFiGaRO system in Tao’s work due to the improved entropy over the NLFiRO and NLGaRO systems. This system is able to run off a single PLL, with a 100 MHz clock system for clk_s, and a 90° phase-shifted clk_e. This construction of the NLFiRO and NLGaro is shown in Figure 10.

NLFiRO recognizes the equation $x^{23}+x^{18}+1$, and NLGaRO recognizes the equation $x^{24}+x^{23}+x^{22}+x^{17}+1$. The full combination of the system is shown in Figure 11.

We opted to use a 23-bit NLFiRO combined with a 24 bit NLGaRO system to construct our NLFiGaRO system. By using the two ROs with differing periods, we are able to realize a maximum period of $2^{23+24}$. With the induced entropy from the phase difference in clk_e and clk_s and the delay cells, we expect a sufficient amount of randomness from our TRNG system. The results of the RO PUF are described in Section 4.2.

3.5.2. Lorenz Hyperchaotic System

Our LHCS relies on 32-bit, fixed point arithmetic, with 24 bits for the decimal and 8 bits for the integer. Specifically, we used exclusively multiplication and addition for the LHCS. Multiplication for 8Q24 fixed point numbers a and b is described in Equation (14).

$$Produc{t}_{8Q24}=\frac{(a\ast b)mod\left(2^{31}\right)}{2^{24}}$$

(14)

Fixed-point arithmetic is preferred due to the simplicity, and therefore lower propagation delay, over floating point arithmetic. Fixed point multiplication, as shown in Equation (14), can be calculated via an integer multiplier followed by a bit shift. This is the core principle that allows us to utilize a high clock frequency for increasing the throughput of our encryptor.

The Lorenz equation FPGA black box is shown in Figure 12. By utilizing a state machine for the RK4 method, we are able to reduce the amount of DSPs for multiplication by 75%. Further, by using asynchronous functions as opposed to registering the input and output, we are able to reduce the latency by two clock cycles. The constant values used within the system are a = 5, b = 20, c = 8/3, and d = −20. We utilized a step parameter of h = 1.51 in the final implementation. It is important to note that, since the system encrypts on a per-pixel basis, the step size h does not affect the final resolution of the ciphertext, nor does input resolution affect the dynamics of the system.

We use a similar approach to the RK-4 implementation. Each variable (x, y, z, and w) has its own multiplier for calculating the step h output at each respective state. Thanks to the reliance on asynchronous functions, we are able to complete an entire RK4 stage in one 100 MHz clock cycle. The RK4 state machine is replicated for each variable of the LHCS and is shown in Figure 13. This produces the encryption key, which is the lower 24 bits of the final x variable. These 24 bits can be either XOR’d against the plaintext to receive the cipher or XOR’d against the ciphertext to receive the plaintext. These two concepts are illustrated in Figure 14 and Figure 15, respectively.

The output of the system is fed back into the input of the system to generate another key. This continues for each packet fed into the system so that each plaintext has its own unique key determined by the LHCS.

Each LHCS is configured to work as both an encryptor and decryptor. The encryption algorithms used to implement the key refresh processes are described below:

• If set to encrypt, the LHCE will first capture an RNG and generate an output, with the input to the system being the hard-coded initial conditions.
• The plain-text RNG seed is encrypted with the output of the LHCE.
• The LHCE will reconfigure itself with the RNG as its initial condition.
• The LHCE will calculate its next key, with its input being its previous output, encrypting the plaintext with the generated key.
• This continues until the LHCE is reset, at which point a new initial condition will be determined via the TRNG, or the system is set to the decrypt mode.

The total time cost for an encryption step requiring the RK4 state machine in Figure 13 is five clock cycles, or 50 ns at 100 MHz. This includes both the encryption of the public key and the encryption of pixel data.

The following algorithm is used for decrypting:

• If set to decrypt, the LHCE will wait for data to be input, expecting the first 24 bits of data to be the encrypted initial condition for the system.
• Once data are received, the generated output (with the hard-coded initial conditions being the input) of the LHCE is used to decrypt the ciphertext.
• These received data are the initial conditions used by the encryptor, so the decryptor reconfigures itself with this first packet as the initial condition.
• The LHCE will calculate its next key with its input being its previous output, decrypting the ciphertext along the way with the generated key.
• This continues until the LHCE is reset, at which point a new initial condition will be determined via the incoming data stream, or the system is set to encrypt mode.

For the RK4 state machine in Figure 13, the total time cost for decryption is five clock cycles. This amounts to 50 ns at the 100 MHz clock rate and covers both the decryption of the public key and pixel data.

3.6. PCIe Wrapper

The PCIe wrapper, while not explicitly for an IoT system integration, allows for stressing the LHCS and represents a potential integration method for the system. Further, thanks to the high throughput potential of the LHCS, the LHCS also has the potential for non-IoT applications, such as high-speed data encrypting/decrypting from a computer processor. The PCIe wrapper is an example of such a system and is described in detail here.

We used an Intel Sandy Bridge processor to communicate with the Stratix 10 FPGA development kit that the LHCS is built on. A Linux kernel, provided by Intel, was modified for our purposes. The PCIe read/write capability was expanded to 256-bit word length, and a software Application Programming Interface (API) was developed in C++ for communicating with the PCIe kernel. The API allows for reading/writing memory from user space and was designed to seamlessly integrate with the PCIe hardware wrapper. The API was programmed with functions such as direct memory read/write, control register read/write (described later in this section), image encryption and decryption, and continuous read/write for PCIe stress testing, which was useful for power analysis.

The full PCIe hardware wrapper utilizes a multitude of components to fully utilize the LHCS system and is shown in Figure 16. The primary interface with the PCIe IV is a parallel I/O that reads and writes into a 512 bit × 32 word DRAM. The base IP for this is publicly made available by Intel and is modified for our purposes. We utilized a dual-port DRAM, where one port manages reads and writes from the processor via PCIe, and the other port manages reads/writes from the memory arbiter. To increase the maximum throughput of the system, non-LHCS components operate on a 200 MHz clock.

The PCIe interface is relatively simple: reads and writes go directly to the DRAM, with one exception. We have one 512-bit register, located at address 0 × 20, that maintains the encryption status of each word. Bits [287:256] act as status registers, where a “1” indicates that the respective address has been written into DRAM via PCIe and has yet to be encrypted. Once the Lorenz controller encrypts that data and writes them back into the same corresponding address space in DRAM, that bit in the address control space will be deasserted, indicating that the address is ready. It is up to the software to maintain responsibility for reading this register before writing in new data, or else data will potentially be overwritten. The lower bits of the control register also control the reset status of the Lorenz controller, the encrypt/decrypt enable bits, and how many valid 24-bit words there are per 256-bit Transaction Layer Packet (TLP) payload (if less than the maximum 10).

Another primary component of the wrapper is the memory arbiter. Since the LHCS system relies on sequential data, it is important that data arrive strictly ordered. Further, since the software interfacing with the PCIe controller on the motherboard has limited control of the transmission of TLPs, it is not possible to guarantee that data arrive at the physical address that they were destined for in the DRAM. This is the reason why the memory arbiter is necessary.

The memory arbiter, with the assistance of a FIFO, manages both the data alignment and ordering of data being fed to the LHCS. It is possible that data are not right-aligned when intercepted from the PCIe interface. The memory arbiter aligns the data, based on byte-enable bits, and feeds the lower 24 bits of the word to the LHCS while continuously shifting the 24-bit data to the right to keep the LHCS busy. Further, it shifts completed encrypted or decrypted data into a new word. Once the arbiter determines that all the data for a given word have been encrypted or decrypted, it writes the data back to the DRAM and deasserts the corresponding bit in the memory controller. Due to the limited maximum clock frequency of the LHCS, a clock crossing FIFO is necessary between the memory arbiter and the LHCS.

4. Results

4.1. Resource Usage

To calculate resource usage, we evaluate our design against the base PCIe memory read/write example available from Intel. This is because we expect our primary system, the LHCS and LHCS controller, to be used without the PCIe implementation. To measure net resource usage of the core LHCS and controller system, we take the difference between the resource usage of the entire design and the original, base PCIe PIO design. This results in resource utilization of the full LHCS system with control functions such as the memory arbiter, control register, and clock-crossing FIFO. This excludes the resources from the DRAM, Parallel I/O controller, and Intel PCIe P-Tile IP. The resource usage for the three designs (base PCIe, full system, and full system minus the PCIe design) are outlined in

Table 1. Resource usage for the entire system relative to the base PCIe/memory design.

Components	Base PCIe	Full System	LHCS w/ Controller	Net Utilization
ALMs	10.7 k	23.4 k	12.7 k	2%
ALUTs	11.2 k	26.1 k	14.9 k	<1%
M20Ks	89	177	86	2%
DSPs	0	14	14	<1%
PLLs	1	2	1	<1%

.

We used a similar approach for evaluating the power usage of the system. The Stratix 10 development kit that we used has an onboard Max10 FPGA that can be used to record active power consumption from the Stratix 10. To measure the power, we stressed the PCIe/LHCS system by running an infinite amount of memory reads and writes via the Linux kernel. We measured the average power consumption over a ten-minute period. The average power for both the PCIe base design and the full LHCS/control/PCIe system was recorded, and the difference between these two measurements indicated the power consumption of the LHCS and LHCS controller. These results are summarized in

Table 2. Total power usage for the entire system relative to the base PCIe/memory design.

System	Power Usage
PCIe Base Design	5948 mW
Full System	6328 mW
LHCS/Controller	380 mW

.

4.2. Random Number Generation

To evaluate our RO-PUF RNG, we used the NIST Statistical Test Suite for Random Number Generators [49]. With RNGs, it can be difficult to determine if a set of numbers is truly random, and no amount of testing can certify an RNG as certainly random. Further, it is unlikely for an RNG to pass all the NIST tests, as some of the test outcomes contradict others. Therefore, it is up to the user to evaluate the outcome of the tests for their uses in cryptography [49]. Furthermore, as the NLFiGaRO system has a period (in the non-RO, PRNG configuration) of 2²³⁺²⁴, it would take a substantially large amount of processing power to evaluate an entire period’s worth of data. To test RNGs, we ran the RO-PUF for 50,000 iterations five times. We share the worst-case results in

Table 3. A summary of the worst-case NIST test suite results.

Test Type	p Value	Required Value	Result
Frequency (Monobit)	0	>0.01	Non-Random
Frequency within a Block	0	>0.01	Non-Random
Run	0	>0.01	Non-Random
Longest run of ones	0	>0.01	Non-Random
Binary Matrix Rank	−1	>0.01	Non-Random
Discrete Fourier Transform	0.43	>0.01	Random
Maurer’s Universal Test	−1	>0.01	Non-Random
Non-overlapping Template	1	>0.01	Random
Overlapping Template	0	>0.01	Non-Random
Linear Complexity	0.50	>0.01	Random
Serial	0.50	>0.01	Random
Approximate Entropy	1.0	>0.01	Random
Cummulative Sums	1.0	>0.01	Random
Reverse Cummulative Sums	1.0	>0.01	Random
Random Excursions	0.22	>0.01	Random
Random Excursions Varient	1.0	>0.01	Random

.

4.3. Image Encryption and Decryption

The image encryption process was run via the software API described in Section 3.6 and evaluated against the results of encrypted/decrypted .bmp files. Since the encrypted public key, also referred to as the randomly generated LHCS initial condition, is three extra bytes on top of the encrypted image data, the key had to be stored outside of the encrypted data section of the .bmp. This is an application-specific decision, but we chose to store the key in the header section of the .bmp, since there is a four-byte partition reserved for program use. While most applications would require full encryption of the image header data, we chose to not encrypt the header data so that we could evaluate the image-encryption results. Our final implementation uses values a = 5, b = 20, c = 8/3, and d = −20 for the LHCE, with 8.1 for $x_0$, $y_0$, $z_0$, and $w_0$ as the hardcoded initial values for the private key. We ran our LHCS system against the entire publicly available SIPI library [50], and some of those results are displayed in Figure 17.

Further, our system sought to deliver multiple unique encryptions of the same data. We encrypted and decrypted each image four separate times. While the decryption results remain similar, the encrypted results are entirely unique with respect to each other. To prove this, we evaluated the RGB histogram of the plaintext image as well as three different encryptions of the same image. This is displayed in Figure 18. More examples of this are displayed in Figure 19.

4.4. Statistical Analysis

Potential attackers can evaluate color ranges from histograms and leverage inconsistencies in the pixel distributions to potentially break the key for a given encryption system. For this reason, it is important to mask the pixel distribution in the final ciphertext of an image. The strength of the distribution within a histogram, such as that in Figure 18, can be evaluated with a $X^2$ test. The $X^2$ test determines homogeneity with a sample and is calculated with Equation (15).

$$X^2=\sum _{i=1}^{256}\frac{{(V_i-g)}^2}{g}$$

(15)

In Equation (15), $V_i$ represents the recurrence of i (whether the channel being tested is red, blue, green, or grey) and $g=\frac{V}{256}$. The $X^2$ values for various images are displayed in

Table 4. The ${\chi }^2$ values for five different images using the LHCE.

Image Cipher	Red	Green	Blue	Average
Ruler	251	228	229	236
Babboon	265	265	217	249
Plane	286	259	232	259
Peppers	291	259	270	274
House	272	265	288	275

. For a degree of freedom value 255 (for an eight-bit image), the maximum value to determine goodness of fit from an $X^2$ test is 293 for a 0.05 significance level [51].

Another test used to determine a system’s strength against histogram-based attacks is Shannon’s entropy, which measures “disorder” within an image by relating an amount of uncertainty to a given probability distribution. A component with low entropy means that it has a more homogeneous distribution [52]. For protection against histogram-based attacks, the ideal entropy value is 8. Shannon’s entropy is defined in Equation (16). Entropy values for various image ciphers are shown in

Table 5. The calculated entropy values for five different images using the LHCE.

Image Cipher	Red	Green	Blue	Average
Ruler	7.9972	7.9975	7.9975	7.9974
Babboon	7.9993	7.9993	7.9994	7.9993
Plane	7.9992	7.9993	7.9994	7.9992
Peppers	7.9992	7.9993	7.9993	7.9992
House	7.9970	7.9971	7.9968	7.9970

. Further, we compare the $X^2$ and entropy values to other works in

Table 6. A comparison of different worst-case statistics with other chaotic encryption systems.

Test Type	Proposed	[53]	[54]	[55]	[56]	[51]
$X^2$	275	241	287	N/A	N/A	260
Entropy	7.9970	7.9990	7.994	7.9985	7.9890	7.9971

.

$$H\left(s_m\right)=-\sum _{i=1}^{256}{p}_n\left(s_m\right)·lo{g}_2(p_n\left(s_m\right)),m=1,\cdots ,M$$

(16)

4.5. Differential Attack Analysis

To further prove the viability of our encryptor, we evaluated common metrics for evaluating the performance of the encryption process against differential attacks. Specifically, we evaluated our LHCS ciphertexts for their Unified Average Change Intensity (UACI) and Number of Pixel Change Rates (NPCRs). UACI measures the average absolute difference between two images, while an NPCR measures how different two images’ pixel intensities are at all locations [57]. An image is considered secure against these differential attacks if it has a UACI value of more than 33% and an NPCR value of more than 99% [58]. UACI is defined in Equation (17), and NPCR is defined in Equation (18).

$$UACI=\frac{1}{255\times MN}\sum _{i=1}^M\sum _{j=1}^N|C_1(i,j)-C_2(i,j)|\times 100$$

(17)

Typically, in Equation (17), $C_1$ and $C_2$ refer to two images with a single pixels difference. However, since our application uses different keys based on the output of an RO-PUF, we are able to run UACI for the exact same image.

$$NPCR=\frac{1}{MN}\sum _{i=1}^M\sum _{j=1}^{N}dist(i,j)\times 100$$

(18)

In Equation (18), $dist(i,j)$ is expressed by Equation (19).

$$dist(i,j)=\left\{\begin{array}{cc}0\hfill & \mathrm{if}{C}_1(i,j)=C_2(i,j)\hfill \\ 1\hfill & \mathrm{if}{C}_1(i,j)\ne C_2(i,j)\hfill \end{array}\right.$$

(19)

M and N in both equations refer to the number of rows and columns of pixels in an image.

Further, we calculated the Pearson correlation coefficient (PCC) to measure the correlation between two ciphers of the same image. For this calculation, the public key was changed for two ciphers of the same plaintext image, x and y. The PCC can range from 1 (perfect correlation) to 0 (no correlation) to −1 (perfect negative correlation). An encryptor should reduce this correlation to zero, indicating that two ciphers are entirely unique. Equation (20) shows how the PCC is calculated, where M is the total number of pixels, $x_i$ represents a pixel value on image x at index m, $y_i$ represents a pixel from a similar image tested against image x at index m, and $\overline{x}$ and $\overline{y}$ represent the mean values of pixel intensities in images x and y, respectively.

$$PCC=\frac{1}{M}\frac{{\sum }_{i=1}^M(x_i-\overline{x})(y_i-\overline{y})}{\sqrt{{\sum }_{i=1}^M{(x_i-\overline{x})}^2{\sum }_{i=1}^M{(y_i-\overline{y})}^2}}$$

(20)

The worst-case results for PCC, UACI and NPCR are shown in

Table 7. A summary of the differential attack resistance statistics for multiple images.

Image Name	PCC	UACI	NPCR
Mandrill	0.001	33.4%	99.6%
Peppers	0.003	33.5%	99.6%
Resolution Chart	0.010	33.4%	99.6%
Boat	0.001	33.5%	99.6%
House	0.002	33.5%	99.6%
Plane	0.002	33.5%	99.6%

. It can be seen from the tables that our proposed LHCE passes all tests, even when the same image is compared against itself when it is encrypted with different keys. This is unique with respect to other implementations, as similar images will produce similar ciphers.

Finally, we compared our results against other works in chaotic encryption. While our work shows similar results for these tests, it is important to note that our implementation tested ciphers of the exact same image with different keys. Typically, PCC, UACI, and NPCR are carried out on ciphers where a single pixel is changed between plaintext images. Despite this, it can be determined from the comparison that our work has similar levels of resistance to differential attacks as shown in

Table 8. A comparison against differential-attack-resistance statistics.

Test Type	Proposed	[53]	[54]	[55]	[56]	[51]
UACI	33.5%	33.4%	33.3%	33.4%	33.6%	33.6%
NPCR	99.6%	99.6%	99.6%	99.6%	99.0%	99.6%
PCC	0.01	0.0009	0.0048	0.0059	0.01	0.0016

.

4.6. Keyspace Analysis

Brute force attacks, in which every possible key is used in an effort to break and decrypt a ciphertext, can be launched on any encryption scheme. To protect against this, a system needs a keyspace large enough so that the system can not be easily broken via brute force. The system relies on eight 24-bit values for key generation: a, b, c, d, $x_0,y_0,z_0$, and $w_0$. Further, the private key is again encrypted using a randomly generated key, which is again generated based on a, b, c, d, $x_0,y_0,z_0$ and $w_0$. Before the attacker can utilize the private key, they must break the randomly generated public key. Thus, the full key space is $2^{2\ast (4\ast 28)}=2^{224}$. This places the keyspace in the middle of similar works. A comparison is shown in

Table 9. A comparison of different keyspaces in similar works.

Scheme	Proposed	[53]	[54]	[55]	[56]	[51]
Keyspace	$2^{224}$	$2^{128}$	$2^{219}$	$2^{448}$	$2^{470}$	$2^{478}$

.

5. Discussion

We sought out the objective of providing an unconditionally secure, low-power, high-throughput encryption system. While it may be reasonably impossible to build a truly 100% secure system, one can make it practically impossible to crack. Our system is immune to a variety of common attacks, such as plain-text, side-channel, and differential attacks.

While the entropy used for encrypting the system is generated via the LHCS, we believe that the truly significant factor for our system being superior to prior results is the use of the RO-PUF as a TRNG for the generation of public keys. This PUF will prevent an attacker from being able to extract the bitstream and replicate the design for decrypting a victim’s data, as the TRNG public-seed generator is unique to each FPGA that it is implemented on. Further, the TRNG PUF is what makes our system immune to differential attacks. For someone to break our encryption system, they would need to

• Extract and decrypt the bitstream from the FPGA to steal the hard-coded initial values to the LHCS (the private key).
• Replicate the system on an aggressor device.
• Intercept the victim’s data.
• Using the stolen private key, decode the incoming public key.
• Synchronize the public key refresh rate with the victim.

Each one of the aforementioned steps makes the LHCS an extra magnitude more difficult to crack. It can be determined, from our results, that it is practically impossible to crack our LHCS.

Outside just high security, our system provides other benefits. It allows for high throughput, with each 24-bit key being generated once every 50 ns. This allows for a maximum throughput of 60 MB/s, which is more than enough to encrypt and decrypt compressed high-definition video. Further, one could introduce frequent initial key refresh, incurring a latency of only six additional clock cycles, or 60 ns. That means that one could add 100 key refreshes per frame of a 30-frame-per-second video and still achieve a video throughput of just under 60 MB/s. This means that even if an attacker was able to analyze a portion of the data and somehow extract the key, they would only have one percent of a video frame.

Further, our system showed a low power utilization that allows it to be integrated into IoT systems. We would not consider the LHCS system to be ultra-low-power, though. We would expect it to be used in devices that have access to a decently large battery, as our system is ideal for high-bandwidth applications that are most likely already drawing power that can be considered to be on the high end of the IoT spectrum. Similarly, we also demonstrated via our application that the LHCS has a place in high-bandwidth applications (such as PCIe) where power consumption is less of a concern.

We do think that our system has some areas for improvement. First, we would like to continue to optimize the power usage. Ideally, for a security system destined for the IoT, such as the LHCS, we would like to see power usage less than 150 mW. Further, implementing a native, variable-sized key may benefit developers seeking to encrypt varying sizes of data where it may be practical to reduce the key size.

6. Conclusions

The current state-of-the-art Lorenz encryption implementations are not suitable for video applications. Our solution allows for high-throughput, low-power encryption that provides unique ciphertexts for equivalent plaintexts. This will prevent a man-in-the-middle attack from being able to tell if a video is changing from frame to frame; in other words, an attacker will not be able to discern if a live feed is changing. This can be a significant perk in security systems, such as those in a bank, where there may or may not be a static environment.

We constructed a four-dimensional, Lorenz hyperchaotic encryptor/decryptor and implemented a PCIe hardware wrapper for stress-testing the system. Further, we integrated an RO-PUF that allows us to generate unique keys for seeding our LHCS system, which deviates from current state-of-the-art encryption on FPGAs. Our implementation with an RO-PUF allows us to have multiple different ciphertexts for identical images, which eliminates the vulnerability to differential attacks.

Our implementation showed a power requirement of only 380 mW, while giving a unique key to each 24-bit data packet. This extremely high key refresh rate with a reliance on a PUF TRNG for a public-facing key not only prevents plaintext attacks but also makes deciphering an entire data stream almost entirely impossible. On top of the low power usage of our system and ultra-high security, we see an extremely high throughput of 60 MB/s, which will allow for encrypting and decrypting live, high-definition video streams. The power consumption is the main shortcoming of our work; at 380 mW, it is not low enough for extremely resource-constrained devices, such as some IoT edge nodes. A possible solution includes the elimination of multipliers in the LHCE by finding powers of two for the values a, b, c, and d. This will allow for the multipliers to be replaced by a bit shift, which is a more power- and resource-efficient option.