T R A N S A C TI O N S ON N E T WO R KS A N D C O M M U N I C A TI O NS TNC Merging Securely M2M Protocols, Internet of Things and Cloud Computing

The Internet of Things provides new ways for communication through the Web world using object-enabled networks. At the same time, M2M devices intercommunication and their communication through the web if they were connected to the Internet, presents new challenges, especially in security, that traditional communication models have not yet fully solved. Because of their inborn un-watched, minimal effort and mass-sent nature, M2M devices, and remote communication architectures and solutions for these devices, would encapsulate new dangers in security. These threats are not fully faced by use of security technologies and methods implemented in existing wireless devices, cellular networks or WLANs. The use of cloud computing gives a convenient, on demand and scalable network access to a shared pool of configurable computing resources and devices. This paper concentrates on a secure method to integrate the M2M protocols with the Internet of Things (IoT) and Cloud Computing under the name of Secure Machine-to-Internet Clouding (SM2IC) architecture. The secure design for integrating M2M protocols, along with IoT and cloud computing is proposed. To apply this design, an IoT enabled smart home scenario was examined to analyze secure communication between M2M devices and IoT applications. Also, the cloud computing is used to include different cloud applications, such as, IaaS, PaaS, and SaaS for monitoring the quality of service of M2M devices through IoT applications. Then, simulations were performed to test the proposed security technique, followed by conclusions and future work.


Introduction
Internet of Things (IoT) is considered as a technology aimed at providing customers with smarter services by linking different devices to the Internet and enabling these devices to exchange information with each other. IoT has been distinguished as a developing technology in numerous IT trend reports [1], and the number of IoT devices is proposed to increase [2,3]. It is suggested by some IT trend reports that the worldwide IoT market will be worth billions of dollars by 2022 [4]. The interconnection between the different kinds of IoT devices is a key issue for the achievement of IoT, in light of the fact that the numbers of IoT devices is developing ceaselessly. IoT standardization bodies have completed several endeavors to understand the interconnection issue. Numerous Web of Things (IoT) platforms were outlined and In this paper, a secure approach for integrating M2M protocols with the internet of things through cloud computing, namely secure machine-to-internet clouding (SM2IC) is proposed, and tested using the appropriate software tools. In section 2, a background on work done in cloud computing, Internet of Things and M2M communication was presented as well as the need for their integration. In section 3, description of current M2M protocols adopted by ETSI. In section 4, a detailed description of the proposed secure machine-to-internet clouding architecture is given. In section 5, description of simulation environment was made. In section 6, description of parameters used during simulation was done. In For this reason, many researchers have suggested complementary characteristics of cloud and IoT, and have proposed integration, generally to obtain benefits in specific application scenarios [16,17]. Generally, IoT can benefit from the virtually unlimited capabilities and resources of Cloud to compensate its technological limitations (such as, storage, processing, communication). Cloud can provide an efficient solution for IoT service management and composition as well as for applying applications and services that benefit from the things or the data generated by them. Also, cloud can exploit IoT by expanding its scope to manage real world things in a more distributed and dynamic manner, and for presenting new services in a large number of real life cases. Cloud can deliver the intermediate layer between the things and the applications, preventing all the complexity and functionalities necessary to use the latter. This has impact on future application design, because information collecting, executing, and transmission will create new challenges, especially in a multi-cloud environment. It is believed that Cloud fills some gaps of IoT (such as, the limited storage). And, some see IoT filling gaps of Cloud (such as, the limited scope). Most of these drivers pushing cloud and IoT integration fall in three categories that are communication, storage, and computation, while there exist other basic traversal drivers. IoT is characterized by a very high heterogeneity of devices, technologies, and protocols, but, it lacks different important characteristics such as scalability, interoperability, flexibility, reliability, efficiency, availability, and security. On the other hand, Cloud has proved to deliver them [18,19], then, they can be identified as some of the main transversal drivers for cloud and IoT integration. There are two other transversal drivers, which are the ease of use and the reduced cost delivered by both users and providers of applications and services [19].

Background on M2M communication
M2M communication tries to reach the vision of connected things, or what is meant by Internet of Things (IoT) [20] [4], through a variety of possible uses in a world where intelligent applications provide a better and safer world. Also, the number of connected devices is rapidly increasing. International Data Corporation expects there will exist around 15 billion devices communicating over the network by the year 2015 [21], while Cisco Internet Business Solutions Group (IBSG) expects 25 billion devices connected to the Internet by 2015 and 50 billion by 2020 [22]. Machina Research white paper mentioned that by 2022, there will exist around 18 billion M2M connections in the world, up from approximately 2 billion today [23]. Ericsson claims that their vision of more than 50 billion connected devices by 2020 may appear realizable and within reach using the right approach [24]. Due to this rapid expansion, the concept of M2M communication is having more and more significance. Interoperability, between devices based on various access network technologies (e.g. mobile (2G/3G/4G), Wi-Fi, Bluetooth), with different platforms and data models is still very limited.
M2M (Machine-to-Machine) communication is initiated between two or more entities without any direct human intervention [25]. Actors in this environment are broad range of communication capable devices, such as, computers, mobile phones, tablets, a variety of sensors, actuators, pieces of industrial and medical equipment, and other everyday devices [26].

M2M high level architecture defined by ETSI
ETSI's work determined a high-level architecture view describing all constituents of M2M systems, their roles, and relationships. The high-level architecture of M2M system is composed of two main parts, which are Device and Gateway Domain, and a Network Domain, as shown in Figure 1 [27]. The device and gateway domain is consisting of the following elements: • M2M Device: executes M2M Device Applications (DA) using M2M Device Service Capabilities Layer (DSCL).

Communication process in the proposed security technique
The idea proposed in this paper is based on presenting secure smart home connections between the user and his home devices. So, any user can open, shut down and monitor his home devices from outside his home using his smartphone or any similar device, besides, monitoring and controlling the quality of service delivered from his home devices from abroad.
The proposed technique provides a detailed description of how to initiate a secure connection from a user's device, such as, PC or tablet and so on to a central controller home device. This central controller device then sends signals to other desired home devices (e.g. microwave, TV, Lighting system and so on.) to control the status of these devices. The user's request communicates with the Internet using the hypertext transfer protocol, known as HTTP, then, the internet passes this request to the central device using the Https (or secure hypertext transfer protocol), also, the central controller device's hardware is Raspberry pi enabled, and this device can exchange data with the internet using Get and Post commands through Https. In its turn, the central controller device communicates in both directions with home devices previously mentioned using M2M network through one of the following technologies (Bluetooth, ZigBee, radio waves, Wi-fi ……. and so on).
The user's holding his device with cloud applications (such as, PaaS, IaaS and SaaS) receives a feedback from the home devices to the central device then to the Internet to his device about the completion of the secure connection and about the status of his home devices. The cloud applications residing in the user's device allow the user to monitor the quality of service (QoS) delivered through the whole process at the end home devices through giving precise measurements about the different parameters relating to the connection, internet, central device and controlled home devices, and this enables the user to control and modify the desired parameters according to what he expects.
The whole process starting from the connection initiation to the connection completion, must be secure and uncompromised. How security is achieved through this proposed security protocol, will be discussed in details through the following subsections. Fig.2 shows the whole connection process of the proposed security technique from the beginning to the end.
In Fig.3, the connection process of the proposed security technique is demonstrated focusing on the type of networks supporting M2M communication used and at the same time showing the different layers of the Internet of things. First, the user sends a request from his device containing cloud applications to change the status of his home devices. In this case, the user carrying his device represents the IoT application layer. The request traverses the Internet using Http protocol, then, the Internet forwards the user's request to M2M core network, which is responsible of connectivity with other networks, and includes both M2M applications and M2M service capabilities. Then, the request passes to the access network. The Internet, the M2M core network and the access network compose the IoT network layer. The request goes then to the M2M gateway, which contains both M2M applications and M2M service capabilities.
The M2M gateway represents the IoT service and application support layer. The user's request then reaches the M2M controller device, which contains M2M applications and M2M service capabilities. This M2M controller device sends the user's request to the M2M Area Network, which works according to one of the following technologies (such as, Bluetooth, ZigBee, radio waves, Wi-fi …). In turn, the M2M Area Network forwards the user's request to the desired M2M devices, which include M2M applications and M2M service capabilities. The M2M controller device, M2M Area Network and M2M devices constitute the IoT device layer. Then, the feedback carrying the devices status is sent to the direction of the user, traversing all the preceding layers. The user can monitor and modify the home devices state using cloud applications according to his will. Then, the communication process in this technique occurs in both directions (indicated by lines with arrows in both directions, in Fig.3).
In the following subsections, the proposed security technique is going to be described in details. Fig.4 illustrates the proposed security technique for M2M communication through steps. In the first step, the user initiate a secure connection from his device, which contains cloud applications to monitor or modify the parameters of the whole process. The encryption and decryption processes are performed according to a proposed security technique in this paper, named Double Key Secure Internet (DKSI), and this new security technique is going to be explained in section 4.2.
The user's device must generate a connetion request number, composed of the user's device ID encrypted using the proposed Double Key Secure Internet (DKSI) tehnique and the key used to encrypt it, as well as, an authentication setting number, containing the user's password encrypted using the DKSI technique by the same key used to encrypt the user's device ID. The user's connection request traverses the Internet, the M2M core network, access network and M2M gateway to reach the M2M controller.
In the second step, the M2M controller checks the connection request number and the authentication setting number by decrypting the device's ID and the user's password using DSA or RSA technique with the first encryption key sent by the user. If the user's device ID and the user's password are verified, then, the controlller device can transport the requested tasks to the desired devices.
In the third step, the M2M controller device generates a temporary conection key, containing the controller device ID encrypted using the DKSI encryption technique by a new generated key from the M2M controller, then, the temporary connection key is encrypted for the second time using the user's first key generated at the beginning of the connection with the DKSI encryption technique. Then, the user's request containing connection keys passes from the M2M controller device to the M2M required devices through M2M area network.
In the fourth step, the required M2M devices have to check the temporary connection key containing the controller device ID and the second encryption key generated by the controller device, as well as the first encryption key sent from the user's device. First, the connection key is decrypted using the user's device generated key, then, it is decrypted for the second time using the second key generated by the controller device. Once, the controller device's ID is checked and verified, then, the desired devices status can be changed.
Also, each connected device has to create a new connection key, containing its ID encrypted with the DKSI technique using the second key, which was generated by the controller device, then, this connection key is encrypted for the second time using the user's device generated key. Then, the new connection key has to reach the controller device. 9 In the fifth step, the controller device checks the connected M2M devices IDs by decrypting the connected devices IDs using firstly the user's device generated key, then, secondly using the controller's device generated key with the DKSI technique. Once, their IDs are verified, then, the controller device encrypt its own ID and the connected M2M devices IDs separately using the user's device generated key with the DKSI technique forming two new connection keys, and then relay them to the user's device.
In the sixth step, the user decrypts the controller device's ID and the connected M2M devices IDs, using the key generated from his device with the DKSI technique to be verified. Then, the user can monitor the connected devices from his device and send a feedback through his device to change connected devices status. Apart from the different steps of the security technique, the desired devices status are sent from the user at the connection initiation, to the M2M controller device by passing through the Internet, the M2M core network, the access network, and the M2M gateway. Then, the M2M controller device retransmits the desired devices required status to the requested devices by passing through the M2M area network. Then, the requested devices resend back their encrypted IDs and their modified status to the M2M controller device again through the M2M area netwok. Finally, the M2M controller device resends the desired devices encrypted IDs and their modified status back to the user's device by traversing the M2M gateway, access network, M2M core network and the Internet. And, the user can modify the home devices status again as desired.

Hash Function Used in the Proposed Security Technique
Most known cryptography techniques, such as RSA [28], DSA [29] or elliptic curve [30] encryption techniques utilize hash functions to ensure security of the user's data. Hash functions are created in oneway and can not be reversed or decrypted. In the proposed security technique (DKSI), the hash function SHA-2 was used. The SHA-2 is going to be described in the following section.
SHA-2 (Secure Hash Algorithm 2) [31] comprises of a set of cryptographic hash functions made by the United States National Security Agency (NSA). Cryptographic hash functions are considered as mathematical tasks that process digital data; by looking at the processed "hash" to a known and evaluated hash value, a person can estimate the data's integrity.
Also, evaluating the hash of a downloaded document and contrasting the outcome with a formerly created hash result can identify whether the download has been changed or altered. A key property of cryptographic hash functions is their resistance against collision; no one is capable of discovering two distinctive input values that deliver the same hash output. SHA-2 has huge changes from its antecedent, SHA-1.  Based on its characteristics, Sha-256 was chosen to be used as a hash function in the proposed technique, due to its relative proven strength against attacks and collisions.

Proposed DKSI (named double key secure internet) encryption technique
In this paper, a new encryption technique to ensure security of data transactions is proposed. This technique implements SHA-2 (as a hash function) instead of SHA-1, because SHA-2 provides better security as explained in previous section 4.2.2. The proposed DKSI technique is performed on the user's ID, password and generated key. It depends on transforming the user's device ID into binary representation, then performing some transformations and logical operations on it, and retransforming it using a hash function along with some mathematical operations. The steps of the proposed DKSI encryption technique are described below as follows: 1. Take the user's device ID in combined representation using letters and numbers, for example, EAT56TYUI 2. Transform each letter or number to its ASCII code, then to its binary representation, composed of 8 bits; 0's and 1's 3. Generate the first user's key of a random 0's and 1's, but it must be the same length of the Device ID binary representation using Key = rand(1, len), where len is the length of the Device ID binary representation 4. ANDing the binary representation of the Device ID and the generated key 5. Shift to the left twice the output result and the generated key and put 2 0's at the left of both of them 6. The first two bits shifted from the left, can be: 00, 01, 10 and 11, and put them at the end of the right of both of the result and the key Note: the output result represents the Device ID primary encryption. Steps 5 and 6 is performed for both the result from step 4 and the user generated key. The output length from step 6 is equal to the length of the binary representation of the Device ID plus two bits, and the length of the key in binary is increased by two bits. 7. Transform the primary encrypted device_id (Device ID') to numerical representation 8. Make hash function of the primary encrypted device_ID using SHA-2/256(Device ID') 9. Apply mathematical operations to the to the hashed primary encrypted device_ID after transforming it to hexadecimal format and using the logarithmic function, as follows, Final encrypted Device_id = [ (numerical (hashed Device_ID'))*log (len)] K 10. Transform the user generated shifted key from its binary representation to numerical representation to become (key') 11. Apply some modifications on the user generated key before sending it, by New_Key = (K*key')/(M*P) Then, at the home devices, once the central device _ID is verified after decrypting it, the home devices status are changed as required by the user, and the home devices IDs are encrypted using the same steps to 9 mentioned above using key2. Then, the encrypted home devices IDs are sent with key 2 back to the central controller device. Then, the central controller device checks the home devices IDs by decrypting them and comparing them to the IDs stored inside it, once, the home devices IDs are verified, the central controller device Id and the home devices IDs are encrypted by key 1 using the proposed DKSI technique steps to 9, and then, sent along with key 1 to the user's device to be verified. Finally, at the user's device, the received central controller device ID and home devices IDs are decrypted using key 1 to be checked and compared to the ones stored inside the user's device, once they are verified, a monitoring feedback can propagate easily from the user to the central controller device and the connected backend home devices to enable the user easily to monitor the status of these devices. The decryption process is going to be described in the following section.

Proposed DKSI (named double key secure internet) decryption technique
The inverse of the steps explained in the encryption is done in the decryption to recover the original user Device_ID and password, to check them against saved ones in the central device. The following decryption steps are reapplied every time there is a need for decryption in the proposed security DKSI technique. The decryption steps of the proposed DKSI security technique are described below: Recover first the key by using these steps; 1. Apply reverse mathematical operations to that performed in encryption on the received key such as, Key'' = (M*P)*received_key /K; 2. Transform the received modified key (key'') from numerical representation to 8 bit binary representation. 3. Remove the leftmost two bits in the binary representation that were added during the encryption process. 4. Bring the rightmost two bits that were shifted during the encryption to the leftmost two bit locations, then, the original key was restored and the original Device_ID need to be found. Recover second the original Device_ID by implementing these steps; 1. Apply the steps to 9 mentioned in the encryption above using the recovered key on the user's Device_ID, which is stored inside the central controller device to encrypt it, the result of the encryption is a vector. 2. Compare the newly encrypted user's Device_ID by the central controller device with the received encrypted user's Device_ID from the user's device, because the hash function SHA-2 cannot be reversed, so we have to repeat the DKSI encryption steps on the stored user's Device_ID. If the newly encrypted user's Device_ID matched the received encrypted user's Device_ID, then, the user's Device_ID is verified, and same steps of encryption to 9 are applied on the user's password stored inside the central device using the recovered key, then, the newly encrypted password is compared to the received encrypted user's password to be verified. Once both the user's Device_ID and password are verified, then, encrypt the central controller device ID using key2 generated by it, then, by using the recovered key 1, and send them to the home devices for verification, and so on as explained earlier in the DKSI technique. Note: the decryption steps are repeated every time there is a need during the DKSI security technique.   With Simulink, the user can develop algorithms and models, and process them on low-cost embedded hardware including Arduino, LEGO MINDSTORMS NXT and EV3, and Raspberry Pi. Development for a range of embedded hardware applications such as control systems, robotics, audio processing, and computer vision can be performed. Simulink support for low-cost embedded hardware is existing in student and home-use versions.

Raspberry pi 3 general specifications
The Raspberry Pi [33] is composed of a series of small single-board computers developed in the United Kingdom by the Raspberry Pi Foundation to be used in teaching of basic computer science in schools and in developing countries. The original model became far more popular than expected, selling outside of its target market for uses such as robotics. Peripherals (including keyboards, mice and cases) are not included with the Raspberry Pi. A few accessories anyway have been incorporated into several official and informal bundles. A few generations of Raspberry Pis have been discharged. Raspberry Pi 3 Model B was discharged in February 2016 and was packaged with on-board WiFi, Bluetooth and USB boot capacities. As of January 2017, Raspberry Pi 3 Show B was the freshest mainline Raspberry Pi.
All Raspberry Pi models possess a Broadcom system on a chip (SoC), which includes an ARM compatible central processing unit (CPU) and an on-chip graphics processing unit (GPU, a VideoCore IV). CPU speed varies from 700 MHz to 1.2 GHz for the Pi 3, and on board memory varies from 256 MB to 1 GB RAM. Secure Digital(SD) cards are utilized to store the operating system and program memory in either the SDHC or MicroSDHC sizes. Most boards possess between one and four USB slots, HDMI and composite video output, and a 3.5 mm phono jack for audio. Lower level output is provided by a number of GPIO pins which support common protocols like I²C. The B-models have an 8P8C Ethernet port, and the Pi 3 has on board Wi-Fi 802.11n and Bluetooth. The Raspberry Pi 3, has a quad-core Cortex-A53 processor. This model was expected to be highly dependent upon task threading and instruction set use. The Raspberry Pi 3 is equipped with 2.4 GHz WiFi 802.11n (150 Mbit/s) and Bluetooth 4.1 (24 Mbit/s) based on Broadcom BCM43438 FullMAC chip with no official support for Monitor mode but used through unofficial firmware patching and also has a 10/100 Ethernet port.
The Raspberry Pi Foundation recommends the use of Raspbian, a Debian-based Linux operating system. Other third party operating systems available via the official website are Ubuntu MATE, Snappy Ubuntu Core, Windows 10 IoT Core, RISC OS and specialised distributions for the Kodi media center and classroom management. It presents Python and Scratch as the main programming language, with support for many other languages. The default firmware is closed source, while an unofficial open source is available. Many other operating systems can also execute on the Raspberry Pi.

Simulink Support Package for Raspberry pi capabilities and features
Simulink Support Package for Raspberry Pi empowers you to create algorithms in Simulink, a block diagram environment for designing dynamic systems and creating algorithms, and execute them independently on your Raspberry Pi. The support package broadens Simulink with blocks for adjusting your Raspberry Pi, sending and accepting UDP packets, and reading and writing information from sensors. This includes writing information to the free ThingSpeak information aggregation service for Internet of Things applications.
In the wake of making your Simulink demonstrate, you can simulate it, tune algorithm parameters until you get it just right, and download the finished algorithm for independent execution on the device. With the MATLAB Function block, you can incorporate MATLAB code into your Simulink model. Using Simulink support package for Raspberry Pi, you compose the algorithm in Simulink and implement it to the Raspberry Pi utilizing automatic code generation. Execution is then performed on the Raspberry Pi. Utilizing Simulink for Raspberry Pi programming empowers you: • Create and mimic your algorithms in Simulink and utilize automatic code generation to execute them on the device • Incorporate signal processing, control configuration, state logic, and other advanced math and engineering schedules in your Raspberry Pi programming projects • Intelligently tune and advance parameters as your algorithm runs on your Raspberry Pi Notwithstanding utilizing Simulink Support Package for Raspberry Pi, you can deliver clear and convenient C code from MATLAB algorithms and actualize it on a Raspberry Pi utilizing Raspberry Pi support from MATLAB Coder. Simulink Support Package for Raspberry Pi influences you to create algorithms that execute independent on your Raspberry Pi. The support package broadens Simulink with blocks to guide Raspberry Pi digital I/O and read and write information from them. In the wake of building up your Simulink model, you can mimic it and download the finished algorithm for independent execution on the device. One particularly useful (and unique) capability provided by Simulink is the ability to tune parameters live from your Simulink model while the algorithm executes on the hardware.

Laptop specifications
Simulation of the smart home scenario was accomplished on a Dell laptop model Inspiron 15500 series, having the following specifications illustrated in table m below. A 64-bit operating system was used in simulation, because Matlab R2017a must be installed on 64-bit operating system machine. The Laptop used in simulation has 8 GB RAM and 2.40 GHz speed, since Matlab R2017a requires a computer with good speed and acceptable RAM. The rest of the Dell Laptop specifications is mentioned in the following table 3.

Smart home scenario to be implemented using MATLAB
The proposed security technique to be implemented in a smart home scenario can be built using MATLAB R207a Simulink Raspberry pi toolbox. The scenario begins when the user clicks from his android mobile phone a button to request the change of home devices status or switching them ON using android toolbox blocks; which provides blocks enabling user interaction inside his android enabled smartphone. Raspberry pi toolbox provides blocks to simulate a Wi-Fi UDP send and receive blocks for wireless communication. So, the proposed security technique is composed of three main parts; the first part represents the user clicking on his smartphone button to switch on/off home devices, then the request is sent wirelessly to the Raspberry pi enabled controller device. The second part represents the raspberry pi enabled controller device sending wirelessly the user request to the raspberry pi enabled home devices, after verifying the coming data. The third part represents the raspberry pi enabled home devices after verifying received data, change the status of home devices; here switching Raspberry pi LED ON/OFF. Figure 6 represents the main blocks of the smart home scenario to be implemented using MATLAB Simulink illustrating how they exchange data wirelessly. The figures of three parts constituting the proposed security technique are provided in the experimental results section. Fig.6 Real life scenario to be implemented using MATLAB Simulink blocks and Raspberry pi toolbox 17

Description of parameters used in simulation
The parameters evaluated during simulations are going to be described in the following subsections.

Response time
Real-time systems exist in the world around us. A modern car is considered as an example of a real-time system. Any person using the car will most likely want to have guarantees about the car's behavior. If the brakes need to be replaced in a nearby future, a lamp should indicate this, and not by the user who declares that there no longer exists any braking effect. A task is a program that performs some service or functionality in the system, like checking the brakes. A task's reaction time can be portrayed as the required time for checking the brakes. To be fit for giving ensures in continuous real-time systems, one must know the response times of tasks. If a message is sent from a source to a destination, the response time can be calculated as the time the message takes from the source to the destination. The factors are considered for evaluating the response time are the bandwidth of the network and the message size, and both are determined by symbols as follows: M: the message size Bwireless: the bandwidth of the wireless network

Memory consumption
To calculate the total memory consumed [34], it is necessary to calculate the number of concurrent users, the domain of the system, the amount of memory required per user, the buffer cache compensation, the number of virtual machines allocated and the system excess rate to estimate the memory size based on the data obtained through the investigation. Also, the system domain contains spaces for the OS, DMBS, engine, middleware engine, and other utilities. The result of the estimation of the memory amount can be expressed as follows.

Total Consumed Memory =(T1+M * q ) * p * o
T1= The total memory for the system domain M = The number of the virtual machines allocated q = The amount of the required memory per user p = Buffer cache compensation o = system excess rate By using the formula above, the result can be calculated as (384 + 959 * 2) * 1. 2 * 1. 3 = 3,591 MB. In consideration of the unit of memory expansion, the amount will be estimated as to b be 8,192MB.

Power consumption of transmitted signals
There exist cell phone base station tower networks across many nations globally, but there are still many areas within those nations that do not have good reception. Some provincial regions are probably not going to be successfully covered, in light of the fact that the cost of raising a cell tower is too high for just a couple of clients. In high reception zones, it is discovered that basements and the insides of vast buildings have poor reception. Weak signal strength can likewise be caused by damaging interference of the signals from nearby towers in urban territories, or by the construction materials used in few buildings, bringing about fast weakening of signal strength. Vast buildings for example warehouses, hospitals and manufacturing plants regularly have no usable signal more distant than a couple of meters from the outside walls. This is especially valid for the networks, which work at higher frequency, in light of the fact that these signals are lessened quickly by mediating obstacles, despite the fact that they can utilize reflection and diffraction to go around obstacles. The estimated received signal strength [35] in a mobile device can be calculated as follows: More general, you can take the path loss exponent into consideration: If the mobile device exists at cell radius distance from the cell tower, the received power is calculated as −113 dBm. The effective path loss is based on the frequency, the topography, and the environmental conditions. Actually, one could use any known signal power dBm0 at any distance r0 as a reference: Table 4 ilustrates the parameters of the received power signal.

Bit error rate
In digital transmission, the number of bit errors [36] is considered as the number of received bits of an information flow over a communication channel that have been altered because of noise, interference, distortion or bit synchronization errors. The bit error rate (BER) is the number of bit errors per unit time.
The bit error ratio (also BER) is the number of bit errors partitioned by the total number of exchanged bits amid an examined time interval. Bit error ratio is a unitless performance measure, frequently introduced as a percentage. The bit error probability pp is the normal estimation of the bit error ratio. The bit error ratio can be resolved as a rough estimate of the bit error probability. This estimate is precise for quite a long time interval and a high number of bit errors.
Estimating the bit error ratio empowers individuals to choose the convenient forward error rectification codes. Since most such codes rectify just bit-flips, but not bit-inclusions or bit-erasures, the Hamming distance metric is considered as the proper technique to gauge the number of bit errors. Numerous FEC coders additionally constantly measure the current BER. A more broad technique for estimating the 19 number of bit errors is the Levenshtein distance. The Levenshtein distance measurement is more appropriate for estimating raw channel performance before frame synchronization, and when utilizing error correction codes created to amend bit-inclusions and bit-erasures, such as Marker Codes and Watermark Codes. The BER is depicted as the likelihood of a bit distortion due to electrical noise . On the account of a bipolar NRZ transmission, we have for a "1" and for a "0". Every one of and has a period of . Realizing that the noise has a bilateral spectral density , is and is .
Coming back to BER, we have the likelihood of a bit distortion . and where is considered as the threshold of choice, set to 0 when . We can use the average energy of the signal to suggest the last expression:

Password Cracking
In cryptanalysis and computer security, password cracking [37] is considered as the way toward recuperating passwords from information that have been stored or transferred by a computer system. A common technique (brute-force attack) is to attempt surmises over and again for the password and check them against an accessible cryptographic hash of the password. The objective of password cracking can be to enable a client to recoup a forgotten password (introducing a totally new password is to a lesser degree a security hazard, but it needs System Administration privileges), to get unauthorized access to a system, or as a preventive measure by system executives to check for easily crackable passwords. On a file-by-file premise, password cracking is made to gain access to digital evidence, for which a judge has empowered access however the specific file's access is confined. The best cracking password techniques are; dictionary attack, brute force attack, rainbow table attack, blogs, phishing, social engineering, malware, offline cracking, shoulder surfing, spidering, guess, and port scan attack.

Password Strength
Password strength [38] is depicted as the measure of a password's ability to resist password cracking attacks. In its typical shape, it estimates how many attempts an assailant who does not have direct access to the password would need, overall, to get it accurately. The strength of a password is considered a function of length, complexity, and unpredictability. Utilizing strong passwords diminishes large danger of a security break, yet strong passwords do not eliminate the requirement for other viable security controls.The strength of a password is defined by; • Length: the number of characters the password incorporates.
• Complexity: does it utilize a blend of letters, numbers, and symbols? • Unpredictability: is it something that can be speculated effectively by an assailant?
Let's now look at a practical example. We will use three passwords namely 1. password 2. password1 3. #password1$ The higher the strength number, better the password. Let's suggest that we have to save our above passwords using md5 encryption. We will use an online md5convertor to convert our passwords into md5 hashes. The table 5 below shows the password hashes. We will now use http://www.md5this.com/ to crack the above hashes. The images below illustrate the password cracking results for the above passwords. Fig.7 illustrates passwords' hashes.

Fig.7 passwords' hashes
From the above outcomes, we figured out how to break the first and second passwords. We didn't figure out how to break the third password which is longer, perplexing and unexpected.

Collision attack
In cryptography, a collision attack [39] on a cryptographic hash tries to find two inputs generating the same hash value, i.e. a hash collision. This is different than a preimage attack where a specific target hash value is determined. There are briefly two types of collision attacks:

Preimage Attack
In cryptography, a preimage attack [40] on cryptographic hash functions attempts to discover a message, that has a specific hash esteem (value). A cryptographic hash function should resist attacks on its preimage. With regards to attack, there exist two kinds of preimage resistance: • preimage resistance: for basically all pre-determined outputs, it is considered as computationally infeasible to discover any input that hashes to that output, i.e., given y, it is hard to discover an x to such an extent that h(x) = y. • second-preimage resistance: it is considered computationally infeasible to discover any second input which has an indistinguishable output as that of a predetermined input, i.e., given x, it is hard to discover a second preimage x′ ≠ x with the end goal that h(x) = h(x′).

Collision resistance
Collision resistance [41] is considered as a property of cryptographic hash functions: a hash function H is collision resistant, if it is hard to find two inputs that hash to the same output; that is, two inputs a and b such that H(a) = H(b), and a ≠ b.
Collision resistance is an even harder property, which we still need for most usages of hash functions: It is hard to find a pair of messages x1≠x2x1≠x2 with H(x1)=H(x2)H(x1)=H(x2).
Each hash function with bigger number of inputs than outputs will essentially cause collisions. Considering a hash function for example SHA-256, that produces 256 bits of output from an (discretionarily) arbitrarily extensive input. It must produce one of 2 256 outputs for every member of a much bigger set of inputs. Collision resistance does not imply that no collisions exist; essentially that they are elusive.

Preimage resistance
Preimage resistance [42] is considered as the most fundamental characteristic of a hash function, which can be thought. It implies: For a given h in the output space of the hash function, it is difficult to discover any message x with H(x)=h. Hard means takes additional time/costs than any (speculative aggressor) hypothetical attacker can contribute. In practice, uniqueness is not characterized by the (dynamic) abstract theoretical nonpresence of collisions, but by the (pragmatic) practical non-presence of collisions. So as to discover a collision in SHA-256, you would (presumably) probably need to run the algorithm somewhere in the range of 2 128 times. It is far-fetched that this will happen at any point in the near future, regardless of whether you check the total number of times SHA-256 will ever be processed by anybody in the whole universe combined. SHA-256 is thought to be practically difficult to "crack", that is, to recover the original plaintext from the hash.

Experimental Results
In the following subsections, the main parts of the security proposed technique are described. Then, each parameter of the five parameters described in the previous section 6 resulting from simulation is explained below. In part 1, the user's sends the device id and password and key used for encryption to the controller device during simulation. Part 1 is represented in Fig.8. Main blocks of part 1 are: Android control button (from android toolbox and used for turning on/off remote devices through the controller device), double block (used to convert data to double), Level 2 MATLAB s-function (used for performing encryption), the To workspace block (carries yout1 3D array; which results after encryption data as mentioned in the proposed technique and represents the encrypted signal,and its role is to output the encrypted signal in the workspace), the rate transition block (to transform data in way that it can appear in the spectrum analyzer), the spectrum analyzer 1 block (to show signal), the android UDP send block (to send encrypted signal wirelessly to the controller device).

Proposed security technique main parts
Part 2: controller device sending the controller device id and encryption keys to home devices Fig.9. Process of controller device sending data to home devices during simulation Part 2 represents the process of controller device sending data to home devices wirelessly during simulation. Part 2 is illustrated in Fig.9. Main blocks of part 2 are: the raspberry pi UDP receive block inside the controller device (from the raspberry pi toolbox (raspberry pi 3 model B); used to receive wirelessly the signal coming from the android device), the level-2 MATLAB function block (used for verifying the encrypted received signal and then sending encrypted device id and encryption keys to raspberry pi enabled home devices after verification), the rate transition block (used to enable encrypted signal that results from the level-2 MATLAB function to be displayed in the spectrum analyzer 2), the to workspace block (carries yout2 3D array; which results after encryption data and represents the second encrypted signal,and its role is to output the second encrypted signal in the workspace to be displayed), the raspberry pi UDP send block (from the raspberry pi toolbox (raspberry pi 3 model B), used to send data wirelessly to the raspberry pi enabled home device/s).
Part 3: the home devices verify the coming data and turn on/off connected device/s

Fig.10 Process of homes devices verifying data and turning device LED ON/OFF during simulation
Part 3 represents the process of home devices verifying data and turning device LED ON/OFF during simulation. Fig.10. illustrates part 3. The main blocks of part 3 are: raspberry pi UDP receive block (from the raspberry pi toolbox (raspberry pi 3 model B); and shows the raspberry pi home enabled device receiving data wirelessly from the raspberry pi controller device), the Level-2 MATLAB s-function block (verify the received encrypted controller device id, after verification, send signals to next checkFCn block), the checkFCn MATLAB block (used to change the home device status if received data are true), the to workspace block yout3 (outputs 3D array resulting from the Level-2 s-function to the workspace), the to workspace block yout4 (outputs 3D array resulting from thr checkFcn block to the workspace), the rate transition block (allows received signal to be displayed in the spectrum analyzer 3), the spectrum analyzer 3 (displays received signals), the display block (display the received signal as a numerical array), the relational operator block (checks if the signal is greater than 0, its outputs 1 and then turns on the LED conncted to the device; else if the the signal is smaller than 0; it outputs 0 then turn off the LED device), the submatrix block (changes the size of the array to fit the LED input), the raspberry pi LED block (from the raspberry pi toolbox (raspberry pi 3 model B), represents the LED of the raspberry pi connected enabled home device).
Let's look at signals as they appeared in the spectrum analyzer. Signals appear as a line means devices receiving 0's or no data sent or received. The below two figures show the signal carrying the encrypted data as well as the keys when sent and received. Fig.11 shows spectrum analyzer 1 & 2 when receiving signal carrying encrypted data in parts 1 & 2. Fig.12 illustrates spectrum analyzer 3 upon receiption of signal carrying encrypted data in part 3.
The received signal in part 3 named yout 3 as appearing in the MATLAB interface in numerical representation is shown in Fig.13 below. The sent signals gives 1's after sending the encrypted data and keys during simulation. the home device's LED. There are two display blocks; one display to show the signal after transforming it to fit the LED size to 1's, the other display to show the final encrypted signal received in numerical representation; which is connected to the stop block. After stopping the simulation, the response time is given, with analysis on the time partitioning across different tasks; in other words, how each task takes time during simulation obtained from report analyzer tool inside MATLAB. A stop block is added in part 3 to stop simulation when the received encrypted data are verified and the LED is turned ON to measure the response time. The response time here from the beginning to the end of the simulation is 24.24 s, but it is organized across many tasks, it means that each task takes an amount of time to be executed during simulation. So that, the compile and link task takes approximately more than 80% of the total response time, but some other tasks; such as display.outputs.major task takes a very small percentage of the response time not increasing than 1% of it. Also, Fig.14 shows the response time; as explained in section 6, organized across different tasks as obtained from the report analyzer tool in MATLAB. Table 6 illlustrates the tasks composing the total simulation time, and the percentage of each task from simulation time.

Memory consumption
During the simulation, when the simulation time increases from 100 s to 1000 s, memory consumed increases gradually from below 5 MB to near 35 MB as shown in Fig.15. The experimental results proved that increasing the simulation time, increases the amount of memory consumed in Megabytes. Fig.15 shows memory consumption in Megabytes when the simulation time increases from 100, 200, 300, 400, 500, 600, 700, 800, 900 to 1000 seconds. But the amount of memory consumed expressed in Megabytes in general is good, and not very large. Table 7 shows memory consumption in (MB) versus simulation time.

Power of signals consumed
The experimental results showed that increasing the simulation time gradually from 100, 200, 300, 400, 500, 600, 700, 800, 900 to 1000 s, increases slightly by small portions the amount of power consumed in decibels of signals sent; either at the android device, the raspberry pi enabled controller device or the the raspberry pi enabled home device, and in some cases, the consumed power can decrease a little and increase again; for example at a simulation time of 600 seconds in the android device. In general, the power of signals consumed during simulation proved to be good and reasonable at the android device, the controller device and the home device, and ranges from 152 dB to 156 dB. Fig.16, Fig.17, Fig.18 and Fig.19 illustrates the power of signals consumed expressed in Megabytes in the android device, controller device, the home device and all the mentioned three graphs are added in the last graph respectively. Table 8 shows power consumed in (dB) versus simulation time.

Bit error rate during simulation
To measure bit error rate, it is required to make some adjustments on the three main parts of the proposed security technique blocks. First, a packet Output block is added at part 1 before the android UDP send block ( from the android toolbox), the block has three outputs; number of ticks, data_ready and data_error; which represents the third output of the packet output block and is used to measure errors that occurred during sending data wirelessly from the android device to the raspberry pi enabled controller device. Also in part 1, a packet input block is added; which has four outputs, captured data at the controller device, the data_ready, the data_error and the number of ticks. Also, the data_error in packet input block is used to measure errors in data received wirelessly at the IP address of the controller device. The spectrum analyzer shows signal at the android device, and the scope shows signal data at the controller device. In part 2, a packet input block is added, with four outputs; which are captured data at the controller device, data_ready, data_error and number of ticks. The data error output of the packet input block represents errors in data sent wirelessly from the controller device. Also in part 2, a packet output block is added, which has three outputs, number of ticks, data_ready and data_error. The data error represents errors in data received wirelessly at the IP address of the home device. The error of data sent from the android device and errors of data received at the controller device are measured. The error of data sent from the controller and errors of data received at the home device are measured. Fig.20, Fig.21, Fig.22, Fig.23, Fig.24 illustrate the percentage of data errors that occurred versus a simulation time of 100, 200, 300, 400, 500, 600, 700, 800, 900 and 1000 s, at the android device (sender), the controller device (receiver), the controller device (sender), the home device (receiver), and all the preceding graphs grouped in one graph respectively. The experimental results showed that the errors that occurred during transmission wirelessly is in general good, since it ranges from 0.5% to 20%. Table 9 shows data error percentage versus simulation time.

Password strength checking
In the final parameter, it is required to test the strength of the device id for example, using mathematics once, and using the simulation inside the MATLAB R2017a. To find the possible combinations of finding a device id (for example). The basic formula used for finding a given combination is given by:

C(n,k) = n!/(k!(n-k)!)
Here, n is the total number of items and k is the number of members or items chosen from total number of given n. This can also be written as the binomial coefficient (n k) as below: (n(n-1)(n-2)…(n-k+2)(n-k+1))(k(k-1)(k-2)…2.1)(n(n-1)(n-2)…(n-k+2)(n-k+1))(k(k-1)(k-2)…2.1) So, in our case the total number of possible combinations is calculated as follows, we have 127 (n) characters at the computer keyboard, and the device id is composed of 10 (k) items (numbers and letters; capital or small), we have: After 209 trillion trials 209123798385425/5100290 = 20501167.42238432 hours of trials/24= 854215.3092660131 days of trials/365 = 2340.315915797296 years of trials. On an ordinary computer it means it is very difficult to regenerate the device_id in an ordinary computer using trials due to the huge number of possible combinations. Generating a code inside MATLAB R2017a to try to find the device id, and giving the number of trials or iterations during the simulation, gives us the below figures. Fig.25 shows the total number of trials to find the device id (in this case) versus the total number of hours of simulation. After all these trials, the device id was not found. Table 10 shows number of trials versus number of simulation hours.  a n s a c t i o n s o n N e t w o r k s a n d C o m m u n i c a t i o n s ; V o l u m e 7 , N o . 1 , F e b r u a r y 2 0 1 9   C o p y r i g h t © S o c i e t y f o r S c i e n c e a n d E d u c a t i o n , U n i t e d K i n g d

Conclusion and Future Work
From the results obtained from experimental simulations, it is concluded that the proposed security technique (SMI2C) provides good response time, reasonable amount of memory consumed, and power consumed during simulation, good bit error rate and strong technique for protecting passwords without any additional overheads on the proposed system. So, the proposed technique is useful in encryption as it protects user data during transmission between different devices and has many benefits.
In the Future work, a secure technique for internet could be developed taking into consideration reducing energy consumed during transmission; also, reducing memory consumed during signals transmissions could be studied. There are a lot of other parameters that can be considered as areas of research while designing a secure technique for online data transmissions in the future; such as speed of transmission, bit error rate and so on.