Keywords

1 Introduction

IoT is all the rage nowadays, and for a good reason; it can help us out in almost every action in our lives and Businesses: from pocket-sized devices and other smart objects that we carry around or surrounding us at all times and everywhere, to smart factories, smart supply chains and Smart Cities.

In this context, data is exchanged continuously. Considering the fast and massive data exchange in IoT environments, as well as the need of getting IoT platforms highly intuitive, interactive and responsive, approaching IoT cryptography using existing solutions seems to be an expensive and rather ineffective alternative. In fact, with respect to resource limitations in IoT context, traditional cryptography solutions suffer from two major drawbacks: intensive memory and intensive computation resource usage. To cope with these drawbacks, new lightweight encryption systems have been proposed. However, up to date, no forma guide or recommendations have been issued on which one can relay to design a lightweight cryptosystem.

In this work, we will try to propose a set of recommendations which can be used to design a lightweight cryptosystem. The paper is organized as follows: in the first section, called state of the art, some popular lightweight cryptosystem are described. In Sect. 3 the different methods described in the state of the art are analyzed and evaluated in order to identify and suggest the necessary recommendations to achieve an ultra-lightweight cryptosystem adapted to IoT environment. Based on the aforementioned evaluation and analysis, in Sect. 4, we suggest a set of recommendations then, in Sect. 5, we finish by a conclusion and we describe our future work.

2 State of the Art

A cryptosystem is considered as “Lightweight” if its software occupies less than 32 KB of ROM and it uses less than 8 kb of RAM and less than 3000 logic gates [1]. Since more than ten years, a whole heap of lightweight cryptosystems have been designed and proposed. In this state of the art we will limit our description to Present [2], considered as the reference approach of Lightweight cryptosystem, and the most recent lightweight cryptosystems, i.e. those which were proposed from 2015 up-to date.

2.1 Present

Present has been considered for long time as the reference approach of lightweight cryptosystem. Present follows Substitution-Permutation Network Architecture (SPN) [3, 4] with 32 rounds. As it is shown in Fig. 1, each round composed of an addition with sub-key, a substitution function using 4 \( \times \) 4 S-box [5, 6] and permutation with bits.

Fig. 1.
figure 1

Present cryptosystem [2]

Although Present has been designed to fit for computation resources limitations, it fails to meet some of IoT constraints, namely the high energy consumption because of a large number of rounds used (32 rounds), as well as the high computation resource usage caused by bits permutation function.

To overcome Present drawbacks many evolutions of Present architecture and algorithm have been proposed resulting in many new lightweight cryptosystems which are sought to be “lighter” than Present.

Hereafter, we show a brief description of the most recent lightweight cryptosystems designed to cope with Present limitations, namely Midori [7], RaodRunner [8], Rectangle [9] and Simeck [10, 11].

2.2 Midori

Midori encrypts 64 or 128 bits message with 128 bits key. The message is realized in the form of matrix with 4 rows and 4 columns of nybbles for 64 bits size message and bytes for 128 bits size message. It follows Substitution-Permutation Network structure with 14 or 18 rounds dor Midori-64, Midori-128 respectively.

As it is shown in Fig. 2, each round containing an addition with involutive Sbox 4*4, a permutation before and after Sbox function and finally a multiplication with a binary involutive matrix.

Fig. 2.
figure 2

Midori cryptosystem [7]

Using involutive components seems to be a good choice since it allows to use the same components for both encryption and decryption and hence reduce memory and logic gates use.

Furthermore, Midori uses a simple function to generate the sub-keys. Again, this allows to reduce memory, logic gates and time usage. The function is described as follows:

$$ \begin{aligned} & {\text{For Midori128:}}\,\,{\text{RKi}} \, = \,{\text{K}} \oplus\upbeta{\text{i}} \\ & {\text{For Midori64:}}\,\,{\text{Ki}}\, = \,{\text{K }}\left( {\text{i mod 2}} \right) \oplus\upalpha{\text{i}} \,\,\,\,\,\,\,\,\,\,{\text{avec }}\upalpha{\text{i}} =\upbeta{\text{i pour }}0 \le {\text{i}} \le 1 4\\ \end{aligned} $$

2.3 RoadRunner

The main goal of RoadRunner is to reduce memory use. This is insured by a reduced code size.

RoadRunner encrypts a 64 bits message size with an 80 or a 128 key size. It follows Feistel structure [12] with 10 or 12 rounds for RR-80 and RR-128 respectively, and with SPNas a function of Feistel structure.

As shown in Fig. 3 RoadRunner uses Key Whitening method [13]. Key Whitening method allows to apply to the block an XOR with a sub-key before and after each round. This increases the security level.

Fig. 3.
figure 3

RoadRunner cryptosystem [8]

In RoadRunner each Feistel function is composed of 4 bits S-box layers and 3 linear layers (according to the formula 1) and three layers of mixing with the sub-key.

$$ \left( {\text{x} <<< \text{i}} \right) \oplus \left( {\text{x} <<< {\text{j}}} \right) \oplus \left( {\text{x} <<< \text{k}} \right) $$
(1)

To reduce memory usage the key is divided into sub-keys of 32 bits which are used one by one in a circular manner.

2.4 Rectangle

It’s based on a bit-slicing design [14]. The objective of using a bit-slicing design is to increase the system’s flexibility with regard to hardware implementation.

Rectangle encrypts 64 bits message with a 64 or 128 bits key. The message is realized in the form of matrix with 4 rows and 16 columns of bits. It follows SPN structure with 25 rounds containing an addition with sub-key and a substitution function using s-box and a rotation function which circularly shifts all the lines with a given value. The S-Box is applied simultaneously on the 16 columns. The objective is to reduce the number of clock cycle.

The keySchedule is a simple function that uses only shifts and XORs to reduce logic gates number.

2.5 Simeck

As shown in Table 1, there are 10 variants of this system. We distinguish between these method by the massage size and the size of the encryption key.

Table 1. Combination

This cryptosystem is considered as a good option in case if we are only concerned by the hardware implementation cost (in term of logic gates) and not so much by memory usage. Simeck uses a circular shift; which requires only a material wiring. It also uses bit-by-bit operations (XOR, AND) which are flexible operation. However, bit-by-bit operations are usually memory greedy. Figure 4 shows a round of Simeck.

Fig. 4.
figure 4

Simeck cryptosystem [10]

Sub-keys generation function consists of bit-by-bit circular shift operations with XOR. Subsequently, sub-keys are interdependent. However, this function reduce logic gates usage.

3 Simulations

Lightweight cryptosystems can be evaluated, with regard to software implementation, in term of RAM and ROM memory usage. In the other side and as far as the hardware implementation is evaluated, the evaluation is done in term of gates equivalent.

In the following we proceed into an evaluation of the abovementioned cryptosystems.

The evaluation is intended to analyze the studied systems in term of memory and logic gates used by each cryptosystem. As a result of the simulation, the shortcomings related to IoT constraints of the different studied cryptosystems will be identified and argued. The simulation, along with the state of the art study as well as a proper analysis, should allow us to provide some recommendations that help-up in designing ultra-light cryptosystems, i.e., cryptosystems that cope with IoT constraints.

3.1 Evaluation Software

The simulation is achieved using a personal computer with an Intel core i7 processor, with a 2.20 GHz clock speed and an 8 GB of RAM, under the operating system Ubuntu 12.4.

As shown in Fig. 5, PRESENT does not take into consideration the memory use constraint since it keeps in the RAM 8.682 KB which exceeds the aforementioned maximum value of light weight cryptosystem (KB). This drawback has been overcome by Rectangle, Midori, Simek and RoadRunner. We can notice that Rectangle maintains the lowest values of memory RAM use comparing to the studied cryptosystems and it consumes 2.2 kb, a value very near to the minimum value recorded by Simeck which is 1.9.

Fig. 5.
figure 5

Software evaluation

3.2 Hardware Evaluation

The hardware simulation was run using VHDL description language embedded in Xilinx system design, Spartan-IIE Field-Programmable Gate Array family and xc2s300e-6pq208 device.

As per the hardware experiments and as shown in Fig. 6, Simeck maintains the least value of logic gates. Although RoadRunner has perfectly respected the constraints of memory use, clearly, it does not give the same importance to hardware implementation constraints.

Fig. 6.
figure 6

Hardware evaluation

4 Recommendations

As a result of our study, we could obtain the following list of recommendations to help designing a cryptosystem that copes with IoT constraints regarding memory and logic gates use while keeping a good level of security:

  • To design an effective cryptosystem with regard to hardware cost and flexibility, we should use bitwise operations [9].

  • Based on our simulation, we can conclude that using word oriented operations (in contrast to bit oriented operations) can help reducing memory usage (by compering the unit responsible of the “addition with a subkey” in Midori which is word oriented, and this of Simeck which is bit oriented, we can notice that Simeck’s uses more memory than that of Midori (0.347 kb vs. 0.232 kb).

  • With regard to energy and memory consumption. It’s better to use 4 bits Sbox [7] .

    A 4 bits S-box allows to store 24 values ​​while an 8 bits S-box stores 28 values. This requires 16 times more memory than 4 bits Sbox and requires more energy to find a value out of 256 possibilities.

  • With Feistel architecture, the round function is applied only on the half of message. Thus, it can be implemented with low power consumption, less logic gates and easier decryption implementation (like in Simeck).

  • In order to use components that provide operation for both encryption and decryption, so that we reduce the memory logic gate use. To this end we can use involutive component (like in Midori).

  • Using Keyschedule function increases security. However, it may increase memory usageand processing time. Therefore, we can reduce memory usage by avoiding sub-keys generation function (like in RoadRunner).

5 Conclusion

In this paper we have conducted an experimental analysis of some existing and widely used lightweight cryptosystems. The analysis has been done in order to identify a set a recommendations that can be used to design the cryptosystem dedicated to IoT environments, characterized by the limited resources and the need of fast response.

As a next step, we will proceed to a more detailed analysis that involve a larger spectrum of cryptosystems and more criteria such as algorithms complexity and the adequacy of each cryptosystem to different kinds of content.