1 Introduction

Multimedia communications play a pivotal role in Internet of Things (IoT) based applications like environmental monitoring, healthcare, home automation and surveillance. Multimedia-IoT is presently receiving huge attention from research community round the globe. Since Internet of Things (IoT) is supposed to play an effective role in supporting the everywhere computing, permitting different devices and machines to communicate and interact, and to facilitate exchange of data; a multi-pronged research mechanism is globally underway to improve various aspects of IoT devices and networks. One of the main areas that needs attention is the security of data in IoT driven multimedia networks. Network architecture of the IoT has three basic layers: perception layer, network layer, and application layer [46]. The perception layer can be defined as the source of information collection. The network layer is used to connect the perception layer to the user application layer. Finally, the application layer is used to involve users into the scenario. Implementing IoT play increasing role impacting different fields such as smart transport, energy, cities, and healthcare applications [23]. Today, the spread of many small devices forces publicizing the internet of things (IoT). In fact, IoT devices are manufactured by large number of companies and are being used for important and critical objectives. In other words, the most important advantage of Internet of Things (IoT) is achieving full communication between heterogeneous devices, heterogeneous networks and heterogeneous processing bandwidths. Thus, if the IoT can’t merge the multimedia in an organized way, it will not be able to benefit from multimedia-based services and applications. In other words, involving multimedia in IoT is an important research direction that will develop new architectures, protocols as well as scenarios such as adapting security in health monitoring environment. The presence of remote healthcare monitoring systems has led to reduction in the cost of treatment while enhancing the quality of services. Studies show that the number of elderly people is steadily growing [49]. Thus, the need for more hospitals to tackle the health care issues is increasing and so is the treatment costs. In such a scenario, electronic healthcare can reduce the burden and share an ample workload of the conventional care. However, successful deployment of healthcare systems depends on having the adequate security and privacy of the patient’s data [22].

In the case of transmitting medical data also referred to as Electronic patient record (EPR), IoT security and privacy are very important to make people trust these systems. Encryption is the proven solution to be efficient in data security and effective retention [1]. However, it is still considered as major challenge for IoT raising valid research questions especially in the case of determining the appropriate algorithm to be used [4]. A common solution is to secure data via trusted cryptography, i.e. symmetric-key or public-key cryptography [26]. Many research works have been presented earlier to secure data via RSA or more advanced elliptic curve cryptography [27]. However, when it comes to the highly constrained portable devices, these traditional cryptographic algorithms needs significant high resources in order to execute [20]. Some research proposed constrained solution via hardware special arithmetic implementation involving efficient extraordinary adders [28] or redesigning SRAM sub-threshold crypto hardware for low-power utilizations [25]. Others even further presented investigation slightly modifying the crypto algorithm by merging its arithmetic on pipelined VLSI cryptographic ASIC architecture [21], which is found currently unpractical for healthcare mobile devices demanding more innovative research. In fact, many proposed cryptographic algorithms have appeared for this purpose, but found to have disadvantages like, high computational cost, increased implementation time and computation resources [18]. In order to take care of the discussed disadvantages, light-weight-cryptography (LWC) is being used now-a-days. This approach of LWC algorithms are found more suitable to help secure information wherever portable systems like those requires in healthcare are used [1]. Light-weight cryptography (LWC) algorithms take the IoT device limitations in full consideration. It puts priority for available ROM and RAM memory, computation limitations and energy consumption [38]. As a matter of fact, the software implementation is depending on the evaluation metrics that are distinct than hardware. The software implementation is mainly based on memory requirements and the number of clock cycles. Optimizing or designing a particular lightweight encryption algorithm requires the researcher to pay attention to the point of balance between the competing objectives, i.e. security, cost and performance [37]. The execution time, memory consumption and speed for the algorithms SIMON, SPECK and AES are implemented and evaluated previously [8] showing interesting features. Multimedia IoT, connects devices to medical equipment and service networks with an aim to provide effective services in the health sector. The critical nature of data being transferred over such networks requires that it should be secured before its transit. A number of security approaches for such a data could be found in [13, 15,16,17, 33, 39, 40, 42]. However most of the literature does only talk about securing the data without taking various constraints of IoT scenario in consideration [35, 43]. In this work we intend to improve the original SIMON algorithm to work better with regard to the software performance. Indeed, a large number of reported works have been focused on the challenges of modifying an algorithm based on a specific platform. But, the critical issue here is that, the same algorithm may work on two different IoT devices and give different performance. Thus, it was better to look for algorithms that works well and is easy to implement on different platforms, such as SIMON and SPECK. Both they were flexible, secure and perform efficiently in multiple platforms rather than single one.

The structure of the rest of the paper is as follows: Section 2 discusses the security scenario and the remote healthcare monitoring system in the IoT. It further discusses the importance of the IoT architecture. Section 3 describes the data confidentiality in IoT medical sensors. Section 4 provides a brief description of AES, and original SIMON followed by our improvement prospective to gain the enhancement version of SIMON in Section 5. Section 6 evaluates the performance comparing the three encryption algorithms: AES, original SIMON and our optimized version of SIMON expressing the results in terms of execution time, memory occupation, and the speed performance. Finally, Section 7 concludes the work.

2 Security within IoT remote healthcare monitoring system

The integral architecture of IoT allows the easy connectivity, communication, control and useful applications to be developed. The architecture of IoT has three basic layers, as shown in Fig. 1. The perception layer has a different nature belongs to the heterogeneous equipment’s and the collecting way. Especially, with the existence of resource-constrained nature found in IoT devices, like the sensors, radio frequency identification (RFID), barcode etc. The security solutions must achieve practical performance regarding energy consumption, i.e. number of round trips, bandwidth requirements, memory and computing needs. As clarified in Fig. 1, there is no direct communication between the outmost layer (perceptual layer) and the human (application layer). Also, the number of constrained devices surpasses any other number. With this consideration, the IoT structure outer layer (perceptual layer) is covered by billions of controlled devices, which is a feature that can’t be skipped easily, making medical doctors and IoT devices are not able to communicate directly and that because the limitations in networks and devices within the perceptual layer despite the fact that the IoT devices e.g. sensors can communicate with the network directly.

Fig. 1
figure 1

IoT architecture

Full size image

A typical IoT architecture showing massive deployment of machine to machine communication has been depicted in Fig. 1. It could be seen that the IoT setup works utilising a huge deployment of sensing and controlling capabilities. The IoT is considered as the large-scale deployment of machine type communication (MTC) devices that implement sensing actuation operations through minimal human interaction. The number of objects connected to the internet is supposed to exceed the number of people in the world.

This is due to the fact that IoT is based on rationale of connecting various physical devices through internet, e.g. the number of medical devices being connected to internet is rapidly increasing with each passing day [2]. Actually, the healthcare systems are considered as the biggest potential market for IoT with the heart rate monitoring determined as the top benefit [41]. The IoT devices used to apply emergency notification system and remote health care monitoring system by using simple devices such as blood pressure heart rate monitors accessing data into more sophisticated devices. These particular devices can monitor specialized implants used for “pacemakers”, as a known example [24]. Creating such a system will be very useful especially for the elderly people and whomever with chronic disease. Medical data will be sent via the Smartphone to the hospital system for testing, evaluation and analysis as shown in Fig. 2.

Fig. 2
figure 2

Remote healthcare monitoring system (RHCMS)

Full size image

In order, for these systems to be reliable and successful they must maintain high performance, work quickly, monitor the patient’s condition immediately and respond correctly safely accordingly [36]. In addition, these systems must earn the patient confidence in maintaining his medical information and privacy.

The sensors, smart phone, smart-home network, public communication network and the hospital network are exposed to different security threats and most of the time the main reason was the inherited vulnerabilities from the wireless communication. There are a various vulnerabilities, threats and attacks that help to determine the security requirements to the chosen RHCMS scenario shown in Fig. 3.

Fig. 3
figure 3

Remote healthcare monitoring system scenario

Full size image

Some of the prominent areas where these vulnerabilities occur are presented as follows:

  1. A.

    Collecting the patient’s data by sensors

Sensors are a core part in IoT. It is important to realize that communication links within the sensors are built around various technologies including the many wireless technologies so the security requirements are important to discuss. The data confidentiality must go on even in case of a security breach related to the nodes or in transmitting between nodes. Any data leak may tell about the patient disease information. Thus, determining the limitations, threats and the appropriate security requirements are important to improve a trustworthy system. In fact, different scenarios may create different challenges in terms of security and performance that need to be solved by adaptive and the appropriate security methods.

In conclusion, data security, integrity and availability and authenticity are important in IoT. Security will prevent the private information to be intercepted by an attacker. The route of the message from source to destination contains a lot of intermediate entities that can be attacked to release the private information. This could be prevented if the message in these intermediate entities were encrypted [45]. Integrity will prevent the data alteration by attacker in either the transmission route or the storage nodes, which would lead to incorrect diagnosis results. Finally, availability of data to the hospital would support continuous treatment procedures for the patient.

  1. B.

    Transmitting patient’s data through communication networks

The data confidentiality is a must to prevent the data from being revealed if the interception happened in the communication session. Moreover, the data integrity is required to protect the data from modification when transmit from the sensors into the hospital. Data reliability is needed to guarantee that the collected data from sensors will receive no matter if there is a node or link failure. The data accuracy will guarantee the freshness of data and that the data is not replayed by an attacker.

C. Analyzing the data in hospital.

The medical records of patients must be surrounded by physical security that will restrict the access of the medical servers. At the same time using a weak physical security may permit and cause the system or records altered by unauthorized people. Data confidentiality would be used to limit the access of data monitoring at the system servers into authorized people. Also, data integrity is needed to protect the data from change by unauthorized persons. Data availability must be guaranteed to the hospital personnel even if any system failure occurs. The authentication is needed for two reasons. First, to authenticate the hospital personnel. Second, to ensure the data was received from the intended patient.

D. Using smart home environment.

The authentication process is indispensable and it’s important to adapt the suitable authentication process to prevent the adversary from getting an access to the network operations. The functionality of the smart-home must be separated into public and private in order to prohibit the functionality exposure. Also, the availability is important to provide the direct connection between the smart-home and the hospital.

As discussed earlier, this paper focus is mainly involving the perceptual layer. We are discussing the data confidentiality of the medical data residing in sensors of the perceptual layer, as illustrated within interesting RHCMS classification overview of Fig. 4. Thus, the discussion would be on the nature of the medical sensors in IoT as it is believed to consider encrypting the data from the starting point-sensors, which is main factor to overcome lot of damages [37].

Fig. 4
figure 4

the RHCMS needs from a security point of view

Full size image

Usually, the performance of the application would be affected by involving cryptography [21]. In the case of medical applications, the response to the patient’s condition is essential in order to maintain patient’s lives and health. Hence, the speed of encryption of the medical data and its transmission to the hospital is a very important point [22]. The longer the time of encryption the longer the treatment gets delayed, causing catastrophic outcomes [23]. Based on our case of study, there are four important speed parameters, namely: 1. Speed of data collection and encryption, 2. Speed of data transfer, 3. Speed of data analysis to determine the appropriate action, and 4. Speed of implementing the taken decision, as declared in Fig. 5.

Fig. 5
figure 5

Remote healthcare system

Full size image

In the proposed work, we target the speed of data encryption after collection. In fact, LWC uses fewer resources and saves time conserving the necessary security measures. Also, from a practical point of view, reducing the encryption time is essential to maintain the patient’s life knowing his/her condition in a measurable acceptable time [42]. On the other hand, increasing the crypto-computation time may lead to disastrous and opposite results such as complications of the health status which maybe leading to the undesired worst case scenario as death of the patient.This has been our motivation and fuel to study the SIMON encryption algorithm in more depth, i.e. in a way that focuses on reducing execution time, speeding up the algorithm while maintaining the same security level of the algorithm.

3 Data confidentiality in IoT medical sensors: Requirements

Most of the practical IoT devices and applications are suffering low computing power, limited memory, restricted batteries and little operating frequency range [12]. Due to these constraints many important factors must be considered before adapting the security algorithms [5]. In short, the hardware limitations specifically involve the energy, computational constraints, and ROM-RAM memory restrictions [34]. Also, the software limitations include the embedded software boundaries as well as the dynamic security as discussed below.

3.1 Energy and computational constraints

Most of the IoT medical sensors have been developed based on portable battery driven requiring special attention [20]. Those devices are also using low power CPU which has a degraded clock rate [25] on top of this energy limitation. As a practical study, complex computations or expensive encryption cannot be realistic to involve in everyday handy low powered devices [30].

3.2 Memory limitations

Adapting a strong and long encryption algorithm may lead to a negative impact on the battery consumption or the implementation performance i.e. ROM and RAM sizes. In general, the medical sensors suffer from a limitation of memory sizes. In sensors RAM as well as its small flash memory can’t be compared with other traditional digital systems, i.e. laptop, iPad, mobile phones, etc. [29]. For these reasons, security schemes on IoT medical devices must be memory efficient. The traditional security algorithms are proven not preferable and may not be taking the memory efficiency in mind [12].

3.3 Embedded software restrictions

The medical IoT operating system, which is embedded in applicable devices, is having small network protocol stacks [30]. Beside that the security model must be thin. It should also be robust considering fault tolerance, at the same time, to reduce error rate in human health treatments [49].

3.4 Dynamic security patch

The remote reprogramming for the IoT devices is currently believed to be impossible considering the available operating systems [29]. In fact, the protocol stack may not be able to receive and modify the code or the library while in operation, causing systems update to be a real challenge [49], i.e., to be addressed besides all other restrictions.

3.5 Mobility

Nowadays, supporting the mobility feature for the healthcare services is a must. But, pervasive mobility and security at the same time is a challenge. That belongs to the fact that different networks may need different security requirements [14].

The focus of the work carried out in this paper work is to improve the SIMON algorithm with respect to three primary metrics: execution time, memory occupation and speed. In our medical case study, the point of preference for performance is security, but it must consider the practical speed of the implementation because the task is to ensure patient safety and survival. However, increasing security may increase the implementation time, thus putting the patient’s life at risk, which is the realistic performance-efficiency base for our software implementation of the cipher IoT medical system.

4 Studied block ciphers

The shift of focus from the PC or desktop computing system into the resource constrained devices has led this investigation for research in LWC. Adapting normal, i.e. heavy-weight, encryption algorithm increases the overhead making the process completely unpractical. However, adapting lightweight crypto algorithms will achieve acceptable balance between the security and practical overhead [1]. Despite the large number of lightweight algorithms currently present or proposed they are lack of flexibility. We have used SIMON for this study because of various advantages associated with it: flexibility, simplicity, efficiency, besides security and that kind of balance is hard to get in many LWC algorithms [7]. In contrast, a large number of researches have continued for years targeting the AES algorithm in order to reshape it for the lightweight applications. From the other side, there are a number of researches that have found that SIMON algorithm may be an alternative for the AES algorithm under the circumstances of resource constrained platforms, as SIMON offers more options of blocks and key sizes [19]. In fact, having this feature may allow a tradeoff between security, performance and risks. Choosing a 32 bit block or 128 bit block depending on the application needs, where reducing the security level can maintain energy and save computation time. As a result, improving the node’s life time.

Furthermore, these targeted encryption algorithms have different architecture base where as SIMON is dependent on the Feistel structure; which uses a simple logic and arithmetic operations such XOR, AND, and shifting. On the other hand, AES depends on the Substitution Permutation Network (SPN) structure with S-box based design where each bit in the intermediate cipher-text is changed for each round. And it’s to be mentioned that the software platform performance is out of the scope of this work, considering it is not important to be discussed at this stage. Thus, comparing the focus algorithms is to check how fast, efficient and simple they are in order to conclude the optimal algorithm for the Remote Healthcare Monitoring System.

4.1 AES

The Advanced Encryption Standard (AES) is one of the most famous algorithms in the cryptographic field. It is involved in a lot of research as it is, as well as tuned to make it more practical or lightweight. Also, it can allow flexibility, i.e. it can integrate the SPN structure of the AES with the ARX based structure instead of the S-box based structure, to gain more simplicity design for future work. The size of the cipher block is 128 bits allowing three optional key lengths. In fact, the key length determines the number of rounds in the algorithm. It is known that128 key length AES needs 10 rounds, 192 key length requires 12 rounds, and 256 key length necessitates 14 rounds [10]. Furthermore, according to [11] AES has new block and key size called 512-AES which requires 22 rounds. In this work, the 128 bits key length AES model is used and is presented by 4*4 matrix. AES requests four basic operations that must be applied to the cipher state, namely Sub Bytes, Shift Rows, mix columns, and add round key. These four operation functions are repeated ten times in ten rounds, based on key length, except the Mix column that would not be executed in round ten. The reader is directed to reference [10] for more in depth description.

4.2 SPECK

SPECK was proposed by Ray Beaulieu [6], as family of ciphers designed with flexibility allowing some different key and block sizes. The cipher was developed to achieve higher performance especially optimized for execution on microcontrollers. SPECK is similar to SIMON, i.e. it is also Feistel structure cipher. It runs with two branches which develop every round by using crucial shifts in both directions, modular addition and bitwise XOR [6].

The Round function of SPECK depends on the Feistel structure as illustrated in Equation (1).

$$ Rk\left(x,y\right)=\left[\left({S}^{-a}x+y\right)\oplus k,{S}^{-b}y\oplus \left({S}^{-a}x+y\right)\oplus k\right] $$
(1)

In this section, we discussed SPECK algorithm, because the optimization on SIMON was based on SPECK. Also, SIMON and SPECK are very related. Recall that SIMON is originally built for hardware utilization where SPECK built for the software.

4.3 SIMON

Original SIMON algorithm is considered as a Feistel block cipher which is designed by National Security Agency (NSA). Its cipher operations consist of simple round functions that uses bitwise AND, bitwise OR and left circular shifts. It has been developed to improve the performance of hardware and at the same time to achieve good computation crypto results [36].

The round function in SIMON is depends on two stage of the Feistel map just as illustrated in Equation (2):

$$ Rk\left(x,y\right)=\left(y\oplus f(x)\oplus k,x\right) $$
(2)

Where k is the round key and

$$ f(x)=\left( Sx\&{S}^8x\right)\oplus {S}^2x $$
(3)

SIMON basic operations are:

  • Bitwise AND: Bitwise AND between two random bits of n bits words which can be described as: (x &y)

  • Left and circular shifts: (x < < y) is the cyclic shift of x to the left by y bits, where as (x> > y) is the cyclic shift of x to the right by y bits.

  • Bitwise XOR: is the exclusive-or (XOR) which is represented like x ⊕ y.

In general, the speed performance and security strength running the crypto-algorithms are considered challenging conflicting goals [28]. To focus our discussion, SIMON is typically not preferred when it comes to software performance in comparison with SPECK [1] because SIMON requires more rounds to execute, as its main dedication is for hardware rather than software. In this regards, we are trying to benefit improving SIMON benefitting from features of another algorithm known as SPECK giving us room for improvement and speeding up, as clarified in the next section.

5 Proposed SIMON LWC improvement

As mentioned earlier, the light weight crypto algorithms considered in this work are AES, and SIMON. This section discusses improvements to original features of SIMON, benefiting from the understanding of another algorithm, namely SPECK. Recall the scope prospective to enhance SIMON speed.

To benefit this work, consider that both SIMON and SPECK lightweight block ciphers are designs relayed on the ARX philosophy [6].This means that the ARX philosophy is based on avoiding the use of the look-up tables related to the S-box based designs. Also, it benefits from the decrease of the number of operations that are used to perform the encryption. Thus, helps to improve the software performance providing its normality of the code to be acceptable for small medical devices as IoT inspiration [41]; where both SIMON and SPECK belongs to the same family of lightweight block ciphers [8]. Both block ciphers contain twenty variants which supports range of key sizes. The key sizes can be from 64-bits to 256-bits. Each block size can vary, starting from 32-bit and ending at 128-bit block size.

As declared earlier, SPECK algorithm is considered as pure ARX design and can be described as an algorithm that combines two Feistel structures [7]. The round function of SPECK, as shown earlier in Equation 1 and Fig. 6, noting a is 8 and b is 3 for all the block sizes except for the 32-bit size holding special condition of a as 7 and b as 2.

Fig. 6
figure 6

a SPECK round function for 32 block size b SPECK round function the all the block sizes of SPECK except 32

Full size image

The value parameters of Rk(x,y) is affected by a and b, if n = 16 then a is 7 and b is 2, otherwise a is 8 and b is 3. Note interestingly that within describing the SPECK round functions, the SPECK2n/mn can be described as a SPECK with the 2*n bit block size and m*n bit as the key size. For example, SPECK32/64, means the word size is 16 bits which is called (n), and the 32 bit is the 2*n; while the number of words is 4 which is noted as m. As a result, the total key is m*n which equals to 64. For more details on SPECK, the reader is referred to reference [7].

From the other side, any algorithm needs to be scheduled for the key where a master key can generate a group of keys for each round as illustrated in Fig. 7.

Fig. 7
figure 7

Composition of the algorithm

Full size image

The key schedule of SPECK depends on the idea of re-using the SPECK round function. As m = (2, 3 and 4), representing the number of words of the master key schedule such that (lm-2, ….., l0, k0), all the round key n are extracted as declared in the code shown in Fig. 8. In other words, The key schedule of SPECK use its own round function in order to generate the round keys Ki. Note that the round keys Ki are generated to be used in the SPECK round function. The round keys can be written such that (li + m − 1,…., li, ki) where m is in (2,3, 4), representing the number of words of the master key schedule.

Fig. 8
figure 8

Key schedule of SPECK where RF is the round function

Full size image

The counter i in SPECK is issued to eliminate the slide properties. However, SIMON’s key schedule is independent of its round function. Assume m is the number of key words, the key rounds functions can be written as clarified in the three following equations.

$$ {K}_{i+2}={K}_i\oplus \left(I\oplus {S}^{-1}\right){S}^{-3}{K}_{i+1}\oplus C\oplus \left({Z}_{j\ i}\right) $$
(4)

illustrated in Fig. 9 section a.

$$ {K}_{i+3}={K}_i\oplus \left(I\oplus {S}^{-1}\right){S}^{-3}{K}_{i+2}\oplus C\oplus \left({Z}_{j\ i}\right) $$
(5)

illustrated in Fig. 9 section b.

$$ {K}_{i+4}={K}_i\oplus \left(I\oplus {S}^{-1}\right){S}^{-3}{K}_{i+3}\oplus C\oplus \left({Z}_{j\ i}\right) $$
(6)

illustrated in Fig. 9 section c.

Fig. 9
figure 9

SIMON’s key schedule

Full size image

As illustrated in Figure 9, Round key ki is derived from the master key (K). Where the master key K is divided into different lengths of words which is (2, 3 or 4) as illustrated in Table 1. The C ⊕ (Zji) are used to eliminate the slide properties and the circular shift similarities at the same time. Thus, this explains the benefit of adding it to the key expansion process. The following Table describes the SIMON’s basic parameters.

Table 1 SIMON’s basic parameter
Full size table

The performance and security are considered as a competing goals in regard to cryptography [28]. SPECK overcomes SIMON, when it comes to software performance [1].This is because SIMON requires more rounds to execute due to its use of weaker non-linear function of bitwise AND operation, which is found preferred for hardware more than software. On the other hand, SPECK gets its non-linearity from the complex modular addition operation that is preferred for software. It is to be noted that both SPECK and SIMON operations work functionally acceptable in hardware and software.

Usually the software implementation of encryption algorithm is concerned with bit permutation. The bit permutation of SPECK and SIMON are both depending on the circular shifts [8]. In this research work, we are targeting the software performance of the SIMON algorithm since it is found appropriate for enhancement. Specifically, we try to reduce the execution time and the speed cost of the algorithm means reach to a high performance while preserving an optimal trade-off between the security and the speed. Thus, we are highlighting the design decisions that may affect the SIMON’s software performance.

In general, the execution time is the amount of processing time that is required to perform the security mechanism. In order to improve the software performance, we need to take some points into consideration like word size, byte ordering. Also, the point that can’t be ignored is the quality of the compiler, which may affect the performance in software simulations, i.e. implementing the encryption algorithm in C language is normally slower than implementing it in Assembly. The reason is related to the existence of processor instructor such as operation: ‘rotate’. Note that our work is dedicated as proof of concept for academic interest, all the simulation codes were written in C programming language. Each implementation based on assembly would be expressed as a processor dependent and thus will miss the probability feature. Although, there is no doubt about the importance of implementation in Assembly language but the nature of IoT programming is mainly flexible having no specific hardware platform dominated. This has made the IoT devices make C a valid priority for acceptance. In other words, IoT contains a huge number of distinctive devices, different processors and different operating systems. Thus, relying on assembly is unpractical causing a lot of codes variations to be written, tested, debugged and maintained separately and so a lot of errors will appear to be debugged.

Indeed, in order to improve the speed performance of SIMON algorithm, it was necessary to study the optimization in the number of rounds, the rounds is function and the key extension function. Reducing the number of rounds considered as the easiest and most effective solution to reduce the execution time and thus improve the speed and energy. But, at the same time, it can directly impact the security of the algorithm, where the adequate number of rotation will help to protect against several traditional attacks [45]. It was attempted to avoid changing the number of rounds to maintain the same level of security of the original SIMON, however, some attacks affected algorithm successfully due to the reduction of number of rounds. Also, in regard to the round function process, we found that it was necessary to study the basic operations that formed the round function of the algorithm to determine the optimal changes. In fact, changing the logical or arithmetic operations, re-change the order of execution, or change the number of rotation, without taking into account the software performance lead to a negative impact in the software implementation and complicated our situation.

To clarify our modification, consider the SIMON digital round operations. SIMON’s round function depends on some basic logical operations namely: AND bitwise operation, XOR operation, and three shift left circular operations (shift by one, shift by eight and shift by two). The problem is that the shift operation may be easy and cheap for hardware than software, which is really expensive highly dependent on the targeted platform. The number of shifts affect the speed so accuracy in the optimization is needed to determine the appropriate efficient shift numbers. As an illustration, the shift 32-bit on 8-bit microcontroller or 16-bit microcontroller will slower the implementation of the algorithm. Indeed, in SIMON’s software performance there is a penalty due to the execution of all shift operations on a single word. Unlike SPECK where there is some balance in its round function design. Unfortunately, we could not be able to remove this SIMON penalty because it maintains the encrypt and decrypt symmetry [7]. But in return, we could reduce its impact by changing the shift numbers from ({1,8}, 2) to ({0,8}, 2) so the first rotation is removed. Where this rotation by 8 is almost considered free on 8-bit microcontroller and inexpensive in 16-bit or 32-bit microcontroller, as noticed in SPECK. Also, the rotation by 2 is inexpensive too, since the digital number is multiplied by power of 2’s, i.e. 8, 16 or 32, which are just shifting of binary bits.

Our new version of the algorithm will follow the standard Feistel structure. The plaintext is splitting into two words x0, y0 where zero refers to the first number of round. The x0, y0 will enter the round function procedure for a specific number of rounds until the last round number appeared, then xround number, yround number are extracted and finally concatenated in a cipher-text format, as illustrated in Figure 10.

Fig. 10
figure 10

a Original SIMON round function, and b the optimized round function

Full size image

In addition, our case of study is using SIMON 64/96 reducing the number of iterations of the round function loop into 21 times to handle the 42 rounds of SIMON 64/96 by partially unrolling 2 rounds of the code. Thus, the speed and the execution time will be optimized and the space-time trade off would appear too, but in unnoticeable manner. Furthermore, we can simplify the SIMON key schedule process by using the idea of re-using our modified round function to generate the key schedule like SPECK did. In other words, the optimized SIMON Key schedule use its own round function and the C ⊕ (Zji) to generate the round keys. Indeed, The master key will be divided into different number of words depending on the number of registers similar to the case of the original SIMON which shown in Figure 11.

Fig. 11
figure 11

a Original key schedule of SIMON b Optimized key schedule of SIMON

Full size image

Doing that change in the key schedule will not lead to weakness so far, according to a similar idea presented in [47]. Also, making this choice will keep the code size smaller using optimized ROM and nothing from RAM, which is an extra benefit. This optimized key schedule of SIMON is illustrated in Figure 9.

6 Comparison and analysis

This section presents the output of the simulation that has been carried out using Cooja simulator with Contiki Operating System. Cooja emulation tool is considered as most used one for the sensors/IoT domain. IoT normally uses multiple mode of communication networks besides it supports many platforms and flexibility options [43]. As a matter of fact, the development of non-intrusive sensing, open source, wireless and wire-able solutions are still considered as an open issue [35]. From the other side, one of the most important challenges facing the medical applications is the conditional time data flow. Considering the IoT concept, where processing a huge amount of data is required to allow a large communication between different devices. In this case, the traditional simulators do not fit. Sensor nodes need an operating system, routing protocol and simulation for the purpose of operating in the appropriate way. The problem that is encountered in the sensor networks is the absence of the hardware standardization architecture. Further, the normal simulation tools don’t pay attention for the need of on-node processing algorithm like Cooja does. It is pertinent to mention that many state of art medical monitoring system shave been simulated using Cooja [9, 32, 44]. This work simulation utilizes T-mote sky platform, defined as MSP430 based board involving IEEE802.15.4 wireless module. The radio chip CC2420 is used to enable less power, with wakeup-fast from sleep feature. The platform affords a reliable wireless interesting communication that run smoothly for all simulation. The basic parameters for simulation have been depicted in Table 2. The implementation board contains MSP430 F1611 microcontroller that involves 48 KB ROM and 10 KB RAM. This T-mote sky hardware requires similar to real life portable battery of type AA solid batteries, with the additional feature to be attached to the computer to run using the USB port.

Table 2 Basic parameters for simulation
Full size table

Two t-mote sensors are included where the first sensor encrypts the medical data and send it to the second sensor while considering an area of 50*50 mm2.

In order to measure the CPU cycles, we used the MSP-cycle-watcher built as a quality checking tool to count the CPU cycles of each encryption code. The measurement of the number of cycles within the code of the encryption part is extracted by subtracting it out of the complete cycles of the normal entire code, i.e. involving setup and post computation overhead. It is assumed that comparing the exact encryption cycles is leading to fair comparison study of power consumption. Also, this step (execution encryption cycles) have been performed precisely by adding a check point to determine the start and end point of counting the encryption cycles. In this work, we measure the ROM use by a “size A” command present in the used MSP430-gcc compiler. This “size A” measure calculates the memory consumption automatically from the compiled code file. Typically, the ROM consumption of the program is the considered collection of text and data bytes adopted to determine the ROM consumption used for the dedicated encryption part only. In fact, the RAM includes data consumption and stack consumption. The data consumption is computed using the “size A” command and the implementation information file; but for the stack usage during the execution, we used the MSP stack watcher, i.e. to check the stack usage.

This study has been performed to compare and evaluate the optimized version of SIMON with the performance of the original encryption algorithms, i.e. SIMON, and AES all on software platform. The evaluation focus is on two aspects namely: execution time and the memory usage. The comparison results of execution time are shown in Figure 12.

Fig. 12
figure 12

Comparison of execution time for the original SIMON algorithms, optimized SIMON algorithms and AES

Full size image

Note that SIMON is flexible, offers a range of block and key sizes and as mentioned earlier that is the reason that makes SIMON an attractive solution for IoT and for different multimedia applications. However, AES supports only two block sizes 128 bits and 512 bits. Obviously, the second option is too big to consider for the lightweight algorithms. Additionally, AES-128 guarantees a sufficient data protection for a small IoT/healthcare devices. The comparison results of execution time and, ROM consumption are shown in Table 3.

Table 3 Execution time and memory comparison results
Full size table

Figure 12 shows the comparison of speed with regard to the execution time of the original SIMON, optimized SIMON with respect to all the block size versions of the algorithm and the AES (128/128). It shows that AES consumes clock cycles less than SIMON with block size 64, 96 and 128 bits. It indicates that the presented optimization allows the SIMON’s algorithm, which originally well suited to hardware implementation more than software, to overcome AES. The original SIMON speed lower than AES is justifying its normal avoidance to be chosen which is resolved in this work, i.e. software implementation of LWC algorithms.

In regard to the optimized SIMON, to quantify the execution time comparison, the difference percentages were calculated. The values presented interesting feedbacks on how much the optimized SIMON had been enhanced in comparison with the original SIMON; the two versions are presented in Figure 7. The optimized SIMON (32/64) and the optimized SIMON(48/72) consumes clock cycles less than the original SIMON(32/64) and the original SIMON (48/72) by about 20%. Also, the number of execution cycles of optimized SIMON (64/96) is less than SIMON(64/96) by 13%.

Moreover, the execution cycles of the SIMON (96/96) is enhanced by22% where SIMON (128/128) is enhanced by 26%. As a result, the optimized versions of SIMON with 32, 48, 64 and 96 do overcome the speed of the AES algorithm.

The memory consumption for the AES (128/128), original SIMON and the optimized SIMON with respect to the different block sizes has been evaluated by measuring the number of bytes in both RAM and ROM, and the results have been shown in Figure 13 and 14.

Fig. 13
figure 13

Comparison of ROM memory occupation for algorithms

Full size image
Fig. 14
figure 14

RAM occupation of SIMON, the optimized version of SIMON and AES

Full size image

SIMON and the optimized SIMON achieved higher performances than AES. Note that some blocks of the optimized SIMON shows different usage of ROM and that because the manual optimization of each code separately. In fact the improved SIMON, with block 32, 48 and 96, are using slightly less ROM than the original SIMON. This is due to the reuse of the same round function on the key schedule that clearly emerged for the small block size versions as well as the unrolling of the round function is reducing the number of jumps inside the code by reducing the calculation of the indices number inside the loop. However, the optimized SIMON with block 64 appeared to have more four bytes and that because using both the functioning in lining with the unrolling process of the round function leads to a little increase in the ROM. The optimized SIMON 128 appeared to use slightly more ROM. This can be a normal acceptable negligible cost considering the improvement made to the algorithm and specifically due to the memory moves. In other words, copying the data from location to another by using the (memcpy) function.

Finally, both original SIMON and the optimized SIMON are at the same level when it comes to RAM use, where the number of measured bytes are ranged from 64 to 96 bytes. In other words, the requirements of RAM consumption between original SIMON and the optimized SIMON are very small as well as very similar and that belongs to the fact that the ARX algorithms tend to avoid the adaption of the tables in their design.

7 Security analysis

In general, the lightweight cryptography may suffer from four type of attacks which involve eavesdropping, saturation, differential attacks and masquerading. In fact, the simplicity of the design of SIMON made it attractive target for lots of cryptanalysis goals. However, to the best of our knowledge, all the published attacks were related to the reduced number of rounds features. Also, the sort of analysis found is to specify the number of rounds that are susceptible to theoretical attack, making security measures by the number of rounds needed to be attacked. In fact, publications emphasise that no attack exceeds 70% of any version of SIMON. Also, the SIMON’s best attack related specifically to SIMON 128/128 with 48 out of 69 rounds [6]. As a matter of fact, increasing the number of rounds for both will increase the strength, but unfortunately it affects the performance. In regard to AES, the side channel attacks can be considered as the highest security threat to AES. Actually, this type of attack is not related to specific vulnerabilities, i.e. of the cipher algorithm, instead they depend on exploiting the lack of information related to physical implementation of the algorithm. For instance, the timing attack can reveal the secret key from the number of consumed clock cycles through the encryption process of the targeted device. Additionally, the brute force attack depends on the size of the key. In general, if the key length is equal to n bits, then the size of key space is 2 to the power of n. In our case of AES 128/128, needs 2128 alternative keys to be tried, which is equal to the delay of 1038 *3.4. In other words, if the computer calculates 106 decryption/ms, thus the worst case will demand more than 5.4*1018 years to extract the correct key to break the cipher, as security of AES is reported in 2014. In general, increasing the key length increases the number of rounds, which increase the complexity of the algorithm to resist attacks.

From the other side, the security analysis of the optimized version of SIMON. The analysis is carried out based on the similarity between the optimized version of SIMON, original SIMON and SPECK. As mentioned earlier, security measures are related to the number of rounds that have been attacked. Thus, due to the sufficient number of rounds, we believe that the encryption strength of the optimized version of SIMON is comparable to the original SIMON. In addition, choosing the shift parameters of the algorithm with regard to the linear and differential characteristics and having at least one byte length rotation are desirable for better performance [31].

Considering differential linear attacks, as has been noted the behavior of the optimized SIMON is related to the original SIMON so it makes sense to use the best known differential and linear attacks of the original SIMON. Thus, optimized SIMON 32/64 can be attacked on 19 rounds in time complexity234. As well as, the optimized SIMON 128/128 can be attacked by 49 rounds out of 68 and with time complexity near to 2128 which is equal to 70%, and denoted as the highest percentage that could happen to that algorithm according to [8]. Also, for more details about the cryptanalytic results please refer to [3].

Additionally with respect to the impossible differential attacks, SIMON by default has a large number of rounds compared to SPECK. This type of attack was more successful with the reduced rounds version of the original SIMON, so optimizing SIMON with reducing number of rounds will result in suspicion for such attack. Moreover, to the best of our knowledge SIMON is not a candidate for the Meet in the Middle Attack (MIMT). We believe our optimized version of SIMON is more protective against this attack. This is because of re-using the round function in the key schedule allowed many key bits from the master key stream to works quickly in the round function, based on a similar idea presented by [47]. Also, the equation solving attacks/ algebraic are considered hard to be classified for the original SIMON and SPECK. Indeed, this type of attack can work successfully to break the small number of rounds according to [48], where authors were able to break around 10 rounds of the ciphers. As a result, we think the same works here, but it may reach to 13 rounds no matter of the block size with respect to a similar scenario shown in [47].

Furthermore, in the case of related key differential attacks, SPECK and SIMON have been criticized from the time of their inception. Until now according to the literature there was no issue about key-related attacks. Thus, the optimized SIMON which follows the scheduling idea of SPECK has good cryptographic properties. As a result, it can contribute to maintain the required balance between security and the healthcare scenarios. For instance, the patient’s data can be encrypted in measurable time, then sent to the hospital to be analyzed and evaluated. This will help the hospital to determine if there is an emergency or a need to send feedback.

Using the optimized SIMON (32/64) causes trade-offs between security and normal application needs. Usually, it is not an acceptable solution due to the small size of block and key sizes. However, optimized SIMON (48/72) gives the best balance between memory usage and the responsiveness of health system. Indeed, the speed of execution time for the encryption algorithm puts best priority on patient’s life. Where, optimized SIMON (96/96) is considered faster than optimized SIMON (64/96) but there is trade-off between speed and the memory use which is still an acceptable solution. On the other hand, the optimized SIMON 128/128 gives the worst performance making it as unpleasant solution to be used.

8 Conclusion

This paper presented a speedup version of SIMON algorithm with respect to software implementations. The improvement benefitted from interesting features found in a different algorithm named SPECK to modify SIMON original work gaining attractive results. The modification preserved the main structure of SIMON but performed slight reordering within the procedure. The modification has resulted in gain pf interesting performance measures, making SIMON with block sizes 32, 48, 64, 96 bits win among AES 128/128. The modified SIMON with block sizes 32, 48, 64, 96 bits showed interesting speedup compared to the original SIMON, where some of them were originally found slower than AES. The optimized SIMON with all the block versions shows an enhancement percentage range from 20% to 26% except the block size 64 which show an enhancement percentage close to 13%. The implementation study examined both sides of running the algorithm on software, i.e. execution time as well as memory consumption.

The research contribution enhanced the encryption performance of the modified SIMON while preserving an optimal tradeoff between security, performance and memory cost. The paper showed its work results presenting a comparison with the original SIMON with respect to all the block size variants and AES in regard to the speed (execution time measured by the clock cycles) as well as ROM and RAM memory consumption to give the performance overall view. Given the results obtained, the proposed low weight cryptographic algorithm, could find a wide range of applications in IoT based setups. The future research to follow this work is to consider SPECK algorithm, which was used for modification to original SIMON, for comparison and further improvement study hoping interesting attractive outcomes.