RF Simulator for Cryptographic Protocol

2014 IEEE International Conference on Control System, Computing and Engineering, 28 - 30 November 2014, Penang, Malaysia

RF Simulator for Cryptographic Protocol Mohd Anuar Mat Isa1, Habibah Hashim2, Jamalul-lail Ab Manan3, Syed Farid Syed Adnan4, Ramlan Mahmod5 Faculty of Electrical Engineering, 40450 UiTM Shah Alam, Selangor, Malaysia. 1 [email protected], [email protected], 4 [email protected] 2

MIMOS Berhad, Technology Park Malaysia, 57000 Kuala Lumpur, Malaysia. 3

[email protected]

5

[email protected]

communication between smart devices and base station. There is a dire need for a secure TFTP protocol particularly in carrying out various network administrative tasks such as monitoring and upgrading of remote embedded device’s firmware. We emphasized concerns regarding man-in-themiddle attack such as attackers intercept and modify unencrypted TFTP communication. A new cryptographic protocol [4] was proposed for a secure key exchange and a security reduction proofs of security in “Simplex Stop and Wait with Automatic Repeat reQuest” (SSW-ARQ) for the TFTP communication protocol [3]. Both publications covered the secure TFTP theoretical security proofs and its implementation. Our motivation in this publication is to continue the previous research work on cryptographic protocol with rapid implementation and testing as the ultimate goal. Based on our previous experiences in developing and testing new cryptographic protocol such as in [2], [4] it was found that, difficulties in debugging source codes and device configurations (specifically for embedded platform and sensor nodes) which involve time consuming processes. For example, it took a long time (e.g. a few days or weeks) to discover even a small flaw/bug in the source codes that was causing the entire protocol experiment to fail. Certainly this is impractical and frustrating for rapid product development and testing of cryptographic protocol in embedded devices. Another concern is that we want to have a flexible simulator that can be reconfigured for a few specific cryptographic protocols. Such capability will enable researcher to quickly develop and test a few protocols without major changes in the simulator. This entails that the simulator should be capable of doing different cryptographic protocols by transforming protocols into C source codes. This simulator focuses on quick trial and debugging process of the new cryptographic protocol during the experiment phase (using hardware) because from previous experience, many flaws are found during simulation process. In this research work, the we used a simulator which is specific for RF communication using RaspberryPi board with Slice of Radio (SRF B023 - Texas Instruments’ CC1110) wireless RF transceiver [5].

Abstract— Advances in embedded RF devices and sensor nodes have witnessed major expansion of end user services such as Internet of Things (IoT) and Cloud Computing. These prospective smart embedded and sensor devices normally interconnect to the internet using wireless technology (e.g. radio frequency, Wi-Fi) and run on top of CoAP and TFTP protocols. In this paper, we present a RF Simulator v1.1 which simulates lightweight security protocols for RF devices communications using Stop and Wait Automatic Repeat Request (SW-ARQ) protocol. The RF Simulator can be used for a quick trial and debugging for any new cryptography protocol in the simulator before actual implementation or experiment of the protocol in the physical embedded devices. We believe that the RF Simulator may provide an alternate way for a computer scientist, cryptographer or engineer to do a rapid product research and development of any cryptographic protocol for smart devices. The major advantage of the RF Simulator is that the source codes in the simulator can be used directly into its physical implementation of the embedded RF devices communication. We also presented simulation results of DHKE and AES encryption schemes using SW-ARQ protocol as a use case of the RF Simulator. The simulation was executed in ARM Raspberry Pi board and HP DC7800 PC as hardware platforms for the simulator setup. Index Terms—Simulator, Simulation, Radio Frequency, Cryptography, RF, TFTP, Stop and Wait ARQ, Trivial File Transfer Protocol, DHKE, Diffie-Hellman, AES, Raspberry Pi, Wi-Fi AP, Security, Trust, Privacy, UBOOT, IOT, Access Point, AP, Base Station, BS, WIFI, UDP, Lightweight, Asymmetric, Symmetric.

I. INTRODUCTION Various simulation tools [1] (e.g. NS2/3, MATLAB, GloMoSim, OPNET, SensorSim, J-Sim, SENSE, OMNeT++) were used to model and simulate network protocols. However, these simulation tools cannot be used for a rapid development and testing of cryptographic protocols for RF in the embedded devices in the constrained environment. The main objective of this research work is to develop a specific RF simulator for simulating cryptographic communication in Wireless Sensor Nodes (WSN) network. We have confine a research scope to the RF simulator that enables cryptographic protocol simulation with typical parameters such as bits errors (e.g. checksum, frame sequence number and data frame), frame delay and frame waiting timeout. In the our prior works [2]–[4], we have discussed an implementation of a new secure TFTP protocol for securing

978-1-4799-5686-9/14/$31.00 ©2014 IEEE

Faculty of Computer Science & Information Technology, 43400 UPM Serdang, Selangor, Malaysia.

II. RELATED WORK A. Stop and Wait Automatic Repeat Request (SW-ARQ) SW-ARQ is a simple network protocol used by network applications (e.g. TFTP) to enable stop and wait flow control in frame transmission when using unreliable UDP/IP stacks

518


[6], [7]. It allows retransmission of frames in the event of frame loss or corrupted frame [8], [7]. Figure 1 shows an example of frame transmission using SW-ARQ. We can incorporate security in this protocol using an example of a cryptographic scheme taken from a cryptographic textbook. We do this to make it easy for a non-cryptography practitioner to understand and grasp our ideas.

receiving a correct ACK from A. At this stage, all transmitted frame must verify that it is free from data corruption (e.g. biterror) using the checksum function. After all frames have been successfully transmitted, A will assemble all frame segments into the complete B’s public parameters string. A will use B’s public parameters and computes with A’s privates parameters to generates DHKE’s secret keys. Therefore, both parties will share the same DHKE’s secret keys base on Computational Diffie-Hellman mathematical hard problem [11], [12].

From fig. 1 and 2, A wants to transmit data or file to B in a secure manner. Therefore, both parties need to establish a secure key exchange for symmetric encryption (e.g. share AES256’s secret keys). Before that, the AES256’s secret keys must be shared using a secure communication protocol over unsecure communication channel (e.g. SW-ARQ) and this can be accomplished using Diffie-Hellman Key Exchange (DHKE) protocol [9]. In this communication setup, both parties need to establish the DHKE protocol using SW-ARQ protocol. Latter, the key generated by the DHKE protocol will be used by the AES256 as secret keys for data encryption in the SW-ARQ protocol.

Fig. 2 Usage of DHKE and AES encryption schemes. Finally, A will encrypt the file using the AES256’s secret keys (that is derived from DHKE’s secret keys) and send the encrypted file using standard TFTP protocol1 [3], [7]. B will decrypt the file using the shared AES256’s secret keys. However, in this paper, we will not discuss the usage and computation of the performance of DHKE and AES encryption schemes and its security. Rather, we focus on using the RF simulator for simulating cryptographic communication using SW-ARQ protocol wherein the DHKE and AES encryption schemes. We use this example as a sample case study of network data for simulation the SW-ARQ’s frame transmission.

Fig. 1 SW-ARQ protocol [10]

The communication begins with A who generates the DHKE’s public parameters. Due to limitation of SW-ARQ’s frame size, the DHKE’s public parameters generated by A’s must be divided into chunks that are fit into the frame. After that, A will transmit multiple frame segments containing the chunks of A’s public parameters. However, the SW-ARQ communication protocol allows only one frame to be sent at one time. The next frame will be transmitted after receiving a correct acknowledgement (ACK) from B. At this stage, all transmitted frame must verify that it is free from data corruption (e.g. bit-error) using a checksum function. After all frames have been successfully transmitted, B will assemble all frame segments into the complete A’s public parameters string. B will use A’s public parameters and computes with B’s privates parameters to generates DHKE’s secret keys. At the same time, B needs also to generate the DHKE’s public parameters (this is B publics). Due to limitation of SWARQ’s frame size, the DHKE’s public parameters generated by B’s must be divided into chunks that are fit into the frame. After that, B will transmit multiple frame segments containing the chunks of B’s public parameters. Again, the SW-ARQ communication protocol allows only one frame to be sent at one time. The next B’s frame will be transmitted after

B. Simulator In this section we will discuss a few major research works that are related to simulator for simulating a cryptographic protocol, sensor nodes and SW-ARQ protocol. C. McNear et al. (2005) [13] developed a simulator for teaching an encryption algorithms using C# language. The simulator can be used to simulate Data Encryption Standard (DES) and Riverse, Shamir and Alderman (RSA) algorithms in a Windows operating system. X. Yuan et al. (2006) designed an animated simulator for network packet sniffer. The animated simulator was developed using Macromedia Flash MX. This simulator was used as a tool for teaching undergraduate student in networking related courses. M. Omar et al. (2007) [14] performed a simulation using MATLAB to simulate a trust model for Public Key Infrastructure (PKI) based on threshold in a cryptography. S. 1

519

TFTP uses SW-ARQ protocol to transmit file.


D. Vuyst et al. (2008) [15] provided a study on the behavior of SW-ARQ protocol in a wireless network. In the model, the authors have performed an analysis for network communication in the unreliable wireless network with transmission errors. The outcome of the study was an error correlation effect between SW-ARQ’s frame buffer, transmission error and packet delay. M. Singh et al. (2008) [1] consolidated a simulation tool that was used by previous research works in simulating a sensor node communication. The authors also provided a comparison of the different simulation tools such as NS2, GloMoSim, OPNET, SensorSim, J-Sim, SENSE, OMNeT++, Sidh, SENS, TOSSIM, ATEMU, Arvora and EmStar. M. Lahdenmäki (2010) [16] developed a software simulator for simulation of network protocol. His simulator used GUI for ease of use in teaching security in networking protocol such DHKE protocol. D. Karaoglan et al. (2010) [17] used Network Simulator 2 (NS2) to simulate identity-based cryptography key distribution for wireless mesh network. W. Colitti et al. (2011) [18] evaluated the usage of Constrained Application Protocol (CoAP) over the HTTP protocol in WSN. The authors used Wireshark tool to analyze bytes transmitted using CoAP and HTTP protocols. The result shows that CoAP overwhelmed the HTTP with about 10%-25% better performance in a client-server communication. A. A. Alsebae et al. (2013) [19] provided a simulation of SW-ARQ using SimEvents and MATLAB. The authors claimed that the SimEvents can provide a better understanding of queuing, throughput and delaying studies for the SW-ARQ protocol. M. Yoshikawa et al. (2013) [20] proposed a simulator for fault analysis in a design of cryptographic circuits. However, the authors did not mention anything regarding the simulator that they developed but only showed the result of the simulation. Based on the above related works, it can summarize that various simulation tools were used to model and simulate network protocols. However, these simulation tools cannot be used for a rapid development and testing of cryptographic protocols for the following reasons. Firstly, the simulated protocol cannot be directly converted into C language in bare metal source codes for implementation in the firmware (e.g. DENX UBOOT [21]). Secondly, the existing simulation protocol is meant for general networking and communication protocol, but not for cryptographic protocol. Therefore, existing simulation tools for protocol (open source simulation tools) are difficult to be modified for cryptographic primitive computation (in simulated mode) and frame transmission. Thirdly, researcher cannot capture and measure the “actual system time” or “CPU clock cycles” (in bare metal) for performance measurement of the simulated protocol. To overcome these limitations in the existing simulation tools, we have developed a new simulation tool the “RF Simulator v1.1”. In previous version, we have tested RF Simulator v1.0 in a physical implementation whereby the source codes can be used directly into real implementation of the embedded RF communication. In the previous version of the simulator , it was added extra source codes for interfacing with RF module [5] (e.g. RS232) to make it work. A

comparison between simulations codes (RF Simulator) and implementation codes (RF for Raspberry Pi) is that the simulation needs to has a simulator for transmission medium and its environment modules such as delay, error rate and etc. For the actual implementation, it is simply remove the simulator of transmission medium and environment modules and replace it with the interfacing module with the embedded RF device. As far as the our knowledge goes, it was believed that RF Simulator is the swiftest simulator2 that can be used for simulation and deployment in a rapid research and development of cryptographic protocol. III. EXPERIMENTAL SETUP A. RF Simulator We have implemented RF Simulator using GNU C language. The simulator is divided into two parts; 1) client (sensor node) and 2) server (base station). Simulation begins with the client sending a request (SW-ARQ’s frame in fig. 3) to the server. The server will return back with ACK whether the client’s frame is correct or with error. The server will check the frame’s data (9 Bytes) payload and compares it with frame’s checksum (1 Byte) payload. If the frame’s data is correct, the server will send ACK with correct the frame’s checksum. But if an error happens in data or checksum’s value, the server will send ACK with the error checksum’s value.

Fig. 3 SW-ARQ’s frame.

The client will wait for the server’s ACK after transmitting one SW-ARQ’s frame. We have implemented a frame timeout (e.g. 1 millisecond) to ensure that the client do not hang-up waiting for the server’s ACK. If the timeout was reached, the client will retransmit again the same frame until the maximum allow-retry (e.g. 15 times). When the client receives the server’s ACK, it will check the frame’s sequence number and frame’s checksum. If it matches with the transmitted frame, then the client will transmit a next frame. However, if it does no, the client will retransmit again the same frame. This situation will increment a counter of maximum allow-retry. B. Test Cases We have conducted an experiment to test the RF Simulator based on “one-group pretest-posttest” [22], [23] experimental design to evaluate the performance measurement of RF Simulator v1.1 with three test cases in two different CPU architectures (ARM and x86). The first test group was conducted in application layer (user space) through Linux Debian 7 “Wheezy” i386 Kernel in 2

One may observe that, our binary file of RF Simulator is named “.._emu” (fig. 5) to represent an emulator but not just a simulator because that is our final product when the entire project is complete.

520


HPDC 7800 Workstation, Intel 2 Core 2.3 GHz, 3GB RAM. The second test group was conducted in application layer (user space) through Linux Raspbian “Wheezy” Kernel using precompiled image “2014-06-20-wheezy-raspbian.zip” [24] in Raspberry Pi Board v2 ARM 700 MHz, 512MB RAM. We summary the three test cases as below (fig. 4):

with label “Session 1” means that the entire frame from client to server was transmitted and received with a proper ACK. A graph with “Session 2” means that the entire frame from server to client was transmitted and received with a proper ACK. When the both sessions were accomplished, we consider that the DHKE protocol was successfully implemented within a given simulation parameters. However, AES communication protocol does not need a two way communication protocol for implementation because it is a symmetric encryption scheme. A. X86 CPU: HPDC7800 Computer

Fig. 4 A snapshot of header file in rf_snw_arq_emu.h

For every test cases, we have implemented there types of errors that are can be used in the simulation. The first error is a wrong sequence number; second error is an alteration data payload; and third error is an alteration checksum value. A non-error type was also implemented, for example, frame transmission delay that will cause frame timeout event to happen. Figure 5 shows that these parameters can be used as input into the simulator.

Fig. 6 A simulation result of DHKE1024’s Session 1 in x86 CPU


Fig. 5 A snapshot of program RF Simulator v1.1

We have conducted the simulation using the following parameters: a. Frame timeout = 10,000 microseconds b. Random frame transmission delay = 1,000 – 15,000 microseconds. c. Maximum frame allow-retry = 15 times d. Number of frame = size of frame (DHKE1024, DHKE2048, AES) e. The three error rates as mentioned above are the same value. A variance of error rates as shown below: i. DHKE_EXP1_ and AES_EXP1_ = 50% ii. DHKE_EXP2_ and AES_EXP2_ = 25% iii. DHKE_EXP3_ and AES_EXP3_ = 10% iv. DHKE_EXP4_ and AES_EXP4_ = 1% v. DHKE_EXP5_ and AES_EXP5_ = 0.1%


IV. RESULT Fig. 9 A simulation result of DHKE2048’s Session 2 in x86 CPU

The simulations was performed using the parameters stated in the last section, and the result of DHKE1024 and DHKE2048 are divided into two categories of graphs. A graph

521


Fig. 15 A simulation result of AES in ARM7 CPU

Fig. 10 A simulation result of AES in x86 CPU

V. DISCUSSION

B. ARM7 CPU: Raspberry Pi Board

Results of the entire simulations performed on the cryptographic protocol for embedded devices (in this case sensor nodes) are as shown in Figures 6 through 15. Figures 6, 7, 8, 9, 13, and 14 show that there are only a few frames that can be transmitted before counter exceeds “maximum frame allow-retry”. Figures 11 and 12 show that a whole failure in transmission for any frame. We present a summary of AES simulation for DHKE1024/2048 performance in fig. 16. From the graph, it can safely conclude that in every test case for error rate equal to 50% will definitely cause a failure in the DHKE frame transmission. This result is expected because error rate of 50% or more will certainly cause a failure in frame transmission.

Fig. 11 A simulation result of DHKE1024’s Session 1 in ARM7 CPU


Fig. 16 A summary of time to complete frame transmission in DHKE1024/2048

For AES simulation on every test case that is equal to 25% of error rates; this is when probability of transmission failure is growing, that is, when the number of frames to be transmitted is increasing. This type of failure (when error rate is 25%) happens in cases which are shown in graphs, “x86 DHKE2048_S2”, “ARM DHKE2048_S1”, “x86 DHKE1024_S1” and “x86 DHKE1024_S2”. We also observe that, “x86 DHKE2048_S1” and “ARM DHKE1024_S1” results that show long frame transmission delay and the frame counter was almost near to the “maximum frame allow-retry”. We conclude that for the simulation for an error rates equal to 25% will cause a failure in the DHKE frame transmission. Again this result is expected because error rates of 25% or more will usually fail the frame transmission. The AES simulation for error rates equal or less than 10%, the probability of frame transmission failure is less likely to happen. It is expect that the frame transmissions with less or



522

2014 IEEE International Conference on Control System, Computing and Engineering, 28 - 30 November 2014, Penang, Malaysia [4]

equal to 10% error rate, will have more successful transmissions. With successful frame transmissions, DHKE AES can work for the implementation of secure communication between sensor nodes and base station. However, it should be noted that these simulation results may be slightly be different from the actual implementation in SRF B023 transceiver. It can be observed that for AES simulation, the simulator uses a very minimal amount of SW-ARQ’s frame to transmit one AES block cipher. Referring to fig. 10 and fig. 15, the frame transmission failure is likely to happen with an error rates of 50%. We hope to observe a more convincing result when we do an experimental work based on this simulation results in our future research work.

[5]

[6] [7] [8] [9] [10]

VI. CONCLUSION

[11]

We have presented the RF Simulator v1.1 which simulates lightweight security protocols for RF devices communications using Stop and Wait Automatic Repeat Request (SW-ARQ) protocol. We have also presented simulation results of DHKE and AES encryption schemes using SW-ARQ protocol as a use case of the RF Simulator. The RF Simulator has a flexibility to transform the simulated cryptographic protocol into C source codes that can be used for a rapid development and implementation of the cryptographic protocol in the embedded devices. We believe that the RF Simulator may provide an alternate way for various stake holders to do a rapid product research and development of any cryptographic protocol for smart devices. Lastly, we have published these simulation results, data and executable files in the website (http://stpengineering.wordpress.com/). For the future work, a reader of this paper can be prepared to find out for our next publication regarding a result of an implementation of this simulation in the real embedded RF devices.

[12] [13] [14]

[15] [16] [17]

[18]

ACKNOWLEDGMENT

[19]

The authors would like to acknowledge the Ministry of Education (MOE) Malaysia for providing the grant 600RMI/ERGS 5/3 (12/2013), 600-RMI/FRGS 5/3 (160/2013), 600-RMI/NRGS 5/3 (5/2013) and Universiti Teknologi MARA (UiTM) for supporting this research work.

[20] [21]

REFERENCES [1] [2]

[3]

[22]

M. K. T. Singh, Chandresh Pratap, O. P. Vyas, “A survey of simulation in sensor networks,” in 2008 International Conference on Computational Intelligence for Modelling Control & Automation, 2008. Mohd Anuar Mat Isa, Nur Nabila Mohamed, Habibah Hashim and R. M. Syed Farid Syed Adnan, Jamalul-lail Ab Manan, “A Lightweight and Secure TFTP Protocol in the Embedded System,” in 2012 IEEE Symposium on Computer Applications and Industrial Electronics (ISCAIE 2012), 2012. Mohd Anuar Mat Isa, Habibah Hashim, Syed Farid Syed Adnan, Jamalul-lail Ab Manan, and Ramlan Mahmod, “A Secure TFTP Protocol with Security Proofs,” in Lecture Notes in Engineering and Computer Science: Proceedings of The World Congress on Engineering 2014, (WCE 2014), 2014, vol. 1.

[23]

[24]

523

Mohd Anuar Mat Isa, Habibah Hashim, Syed Farid Syed Adnan, Jamalul-lail Ab Manan, and Ramlan Mahmod, “An Experimental study of Cryptography Capability using Chained Key Exchange Scheme for Embedded Devices,” in Lecture Notes in Engineering and Computer Science: Proceedings of The World Congress on Engineering 2014, (WCE 2014), 2014. Premier Farnell UK Limited, “CISECO - B023 - SLICE OF RADIO, RASPI RF BOARD,” 2014. [Online]. Available: http://cpc.farnell.com/ciseco/b023/slice-of-radio-raspi-rfboard/dp/SC13019. G. Malkin and A. Harkin, “TFTP Option Extension (RFC 2347),” in The Internet Society, 1998, pp. 1–7. K. R. Sollins, “THE TFTP PROTOCOL (REVISION 2) RFC 1350,” in IAB Official Protocol Standards, 1992, pp. 1–11. G. Fairhurst and L. Wood, “Advice to link designers on link Automatic Repeat reQuest (ARQ),” in RFC 3366, 2002, pp. 1–28. W. Diffie and M. E. Hellman, “New Directions in Cryptography,” in IEEE Transactions on Information Theory, 1976, pp. 644–654. S. Chen, “Simplex Stop and Wait with ARQ,” 2007. [Online]. Available: http://users.ecs.soton.ac.uk/sqc/EL336/CNL-5.pdf. E. Rescorla, “Diffie-Hellman Key Agreement Method (RFC 2631),” in The Internet Society, 1999. E. Yoon and K. Yoo, “An Efficient Diffie-Hellman-MAC Key Exchange Scheme.” pp. 398–400, 2009. C. McNear and C. Pettey, “A free, readily upgradeable, interactive tool for teaching encryption algorithms,” Proc. 43rd Annu. Southeast Reg. Conf., vol. 1, p. 280, 2005. M. Omar, Y. Challal, and A. Bouabdallah, “NetTRUST: mixed networks trust infrastructure based on threshold cryptography,” in Proceedings of the 3rd International Conference on Security and Privacy in Communication Networks, SecureComm (2007), 2007, pp. 2–10. H. B. De Vuyst, Stijn, Krzysztof Tworus, Sabine Wittevrongel, “Analysis of Stop-and-Wait ARQ for a wireless channel,” 4or, vol. 7, no. 1, pp. 61–78, Aug. 2008. M. Lahdenmäki, “Software Visualization for Teaching Network Protocols,” Aalto University, 2010. D. Karaoglan, A. Levi, and E. Savas, “A distributed key establishment scheme for wireless mesh networks using identity-based cryptography,” in Proceedings of the 6th ACM workshop on QoS and security for wireless and mobile networks - Q2SWinet ’10, 2010, p. 11. V. D. Colitti, Walter, Kris Steenhaut, Niccolò De Caro, Bogdan Buta, “Evaluation of constrained application protocol for wireless sensor networks,” in Local & Metropolitan Area Networks (LANMAN), 2011, no. 7. R. J. G. Alsebae, Alaa A., Mark S. Leeson, “SimEvents-based modeling and simulation study of Stop-and-Wait protocol,” in 2013 Proceedings of International Conference on Modelling, Identification & Control (ICMIC), 2013. M. Yoshikawa and H. Goto, “Security Verification Simulator for Fault Analysis Attacks,” Int. J. Soft Comput. Softw. Eng. [JSCSE], vol. 3, no. 3, 2013. DENX Software Engineering, “DENX U-Boot,” 2014. [Online]. Available: http://www.denx.de/wiki/U-Boot/WebHome. D. R. Brogan and M. H. Kutner, “Comparative Analyses of PretestPosttest Research Designs,” Am. Stat., vol. 34, no. 4, pp. 229–232, 1980. Mohd Anuar Mat Isa, Habibah Hashim, Jamalul-lail Ab Manan, Ramlan Mahmod, and Hanunah Othman, “Integrity Verification Architecture ( IVA ) Based Security Framework for Windows Operating System,” in International Symposium on Advances in Trusted and Secure Information Systems (TSIS-2012), 2012. Raspberry Pi Foundation, “Raspberry Pi,” 2014. [Online]. Available: http://www.raspberrypi.org/downloads.