An Ethereum-Based, Integrity-First Communication Protocol for Iot
Total Page：16
File Type：pdf, Size：1020Kb
An Ethereum-Based, Integrity-First Communication Protocol for IoT Devices by Elizabeth Reilly Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Science in Computer Science and Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY June 2019 c Massachusetts Institute of Technology 2019. All rights reserved. Author.............................................................. Department of Electrical Engineering and Computer Science May 24, 2019 Certified by. Michael Siegel Principal Research Scientist Thesis Supervisor Accepted by . Katrina LaCurts Chairwoman, Department Committee on Graduate Theses 2 An Ethereum-Based, Integrity-First Communication Protocol for IoT Devices by Elizabeth Reilly Submitted to the Department of Electrical Engineering and Computer Science on May 24, 2019, in partial fulfillment of the requirements for the degree of Master of Science in Computer Science and Engineering Abstract The use of IoT devices in smart cities, advanced energy delivery systems, manufactur- ing plants and transportation systems is rapidly increasing. These systems are often responsible for communicating critical data about infrastructure and system state. Despite the significance of IoT devices, many of these devices lack communication protocols with data integrity as a priority. Without data integrity, these systems become reliant on compromised data, and ultimately fail. Attackers can use these vulnerabilities to wage cyber-physical attacks. The light client is an integrity-first communication protocol for IoT devices based on the Ethereum blockchain. This light client ensures that data is not compromised and is lightweight, at a total mem- ory consumption size of 1.2 MB. Therefore, this light client is distributed, secure, and light enough to fit on many IoT devices and ensure that integrity is maintained where it is needed most [24]. Thesis Supervisor: Michael Siegel Title: Principal Research Scientist 3 4 Acknowledgments First and foremost I would like to thank my supervisor Michael Siegel, for continually supporting and encouraging my research. I would also like to thank my colleagues Gregory Falco and Matthew Maloney. Their technical guidance was instrumental in helping me complete this research. I would further like to thank the Cyber Resilient Energy Delivery Consortium (CREDC)1 for all of the support and resources they have given me and for welcoming me into their research group. Finally, I would like to thank my friends and family. Specifically, my Mother and Father, for helping me set up and run all of my tests on their home Wifi system. They have supported me endlessly in both my undergraduate and graduate degree and this thesis would not have been possible without them. 1This material is based in part on work supported by the Department of Energy under Award Number DE-OE0000780. The views and opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. 5 6 Contents 1 Introduction 15 2 Related Works 17 2.1 Legacy Communication Protocols . 17 2.1.1 Modbus . 17 2.1.2 DNP3 . 18 2.2 Modern IoT Communication Protocols . 18 2.2.1 DTLS and CoAP . 18 2.2.2 MQTT . 19 2.3 IoT Blockchains . 19 2.3.1 Tangle . 20 2.3.2 IoT Chain . 20 2.3.3 IoTex . 21 2.3.4 NeuroMesh . 21 3 Light Client Implementation 23 3.1 Using Ethereum as a Base . 23 3.2 Avoiding Storing Chain Data . 24 3.2.1 Nonce . 24 3.2.2 Gas Price and Gas Limit . 25 3.3 Reducing Code Size . 25 3.3.1 Code Removed . 26 3.3.2 Compiler Flags . 26 7 3.3.3 UPX and Code Compression . 26 3.4 Architecture and Communication . 26 4 Testing Environment 29 4.1 Ropsten Network Constraints . 29 4.2 Testing Dashboard . 30 4.3 Devices . 31 4.3.1 Mac OS and Unix . 31 4.3.2 ThinkPad and Linux . 31 4.3.3 64 bit ARM . 32 4.4 Parameters . 32 5 Preliminary Testing 35 5.1 Transaction Approval and Removal Time . 35 5.2 Peer Count Over Time . 37 5.3 Transaction Size . 38 5.4 Stress Testing . 39 5.4.1 Maximum Queue Size . 39 5.5 Device Comparisons . 40 6 Discussion 43 6.1 Comparison to other Blockchains . 43 6.2 Evaluation as a Communication Protocol . 44 6.3 Applications . 45 6.3.1 Smart Cities . 45 6.3.2 Energy Delivery Systems . 45 6.3.3 Device Updates . 45 6.4 Limitations . 46 7 Conclusion 47 7.1 Summary of Contributions . 47 7.2 Future Work . 48 8 A Tables 51 B Figures 53 9 10 List of Figures 3-1 Distributed node architecture . 27 4-1 The GL iNet router, a sample 64 bit ARM device, on the left. The GL iNet plugged into a Verizon ethernet port on the right. 32 5-1 A graph of transaction approval times over a 100 minute period. 35 5-2 A graph of the time it takes for transactions to be removed from the local queue when using a peer limit. 36 5-3 A graph of the peer count over time. 37 5-4 A graph of how the transaction times change with data size. 38 5-5 A graph of how the transaction cost changes with the data size. 39 5-6 The number of transactions sent within various time ranges for each device. 40 B-1 Sample output from the testing dashboard when testing for transaction time. Output is human-readable. Testing dashboard also includes a regrex file to strip this output file into a dataset. 53 B-2 Sample output from the testing dashboard when testing for peer count. Output is human-readable. Testing dashboard also includes a regrex file to strip this output file into a dataset. 54 11 12 List of Tables 3.1 The impact of each code reduction method. 25 3.2 A comparison of the original Ethereum source code to the light client implementation. 25 4.1 Statistics about the average performance of the Ethereum network [8]. 29 4.2 Size of each cross-compiled binary. 31 5.1 The average time to send a transaction per operating system. Taken across 4096 transactions. 40 6.1 Comparison of different Blockchain algorithms [5][6][13][29]. 43 6.2 Comparison of different IoT communication protocols [12]. 44 A.1 Sizes of the cross-compiled light client for operating systems and ar- chitectures that were not explicitly tested in this thesis. 51 13 14 Chapter 1 Introduction Although the use and prevelance of IoT devices is on the rise in homes and in cities, many of these devices lack proper security [14]. There are hundreds of videos ded- icated to demonstrating how to hack into IoT devices in minutes [7][24]. There are currently few communication protocols and the variation in manufacturers makes standardizing communicaiton difficult. Furthermore, communication becomes even more difficult on memory and processing power-constrained devices such as smart me- ters and CCTV security cameras [13]. This research focuses specifically on improving the communication integrity of critical infrastructure IoT. Integrity-first communication, otherwise known as prioritizing correct communi- cations, is important for many IoT devices. IoT devices such as smart meters and electronic appliances can be found in the home [14]. They can also play a large role in transportation systems such as subways and traffic control [16]. Furthermore, IoT devices can be found in energy delivery systems or smart cities, where lack of integrity of data can have cyber-physical consequences [24]. The integrity of these devices is critical. It can be hard to determine a single universal communication protocol for IoT de- vices because these devices often have different operating systems and configurations [11]. This is even more difficult for IoT devices with limited memory and compu- tational resources as they often lack the space to be able to host a communication protocol at all [18]. Many integrity-first IoT communication protocols have been 15 suggested, but they are often not scalable to large networks of devices [22]. Given the scale and distributed nature of IoT devices, a suitable integrity-first communication protocol is needed [24]. Blockchain is therefore a good candidate. Blockchain is a distributed ledger in which different nodes in the system can send transactions and also verify the transactions of other participants. The global blockchain is comprised of the overall series of approved transactions, in order of when they were approved. This global blockchain is determined by consensus among the nodes. Es- sentially, the majority of nodes in the system will agree about which transactions should be approved and these transactions then go into the blockchain so that the majority of nodes will always have the same blockchain. This blockchain is therefore immutable and secure. Blockchain provides a scalable, distributed record that en- forces consensus across all participating nodes [23][24]. Once a transaction has been approved by the majority of nodes, it cannot be altered or deleted unless an attacker controls over 51% of the nodes. If an attacker does gain control over 51% of the nodes, that attacker could control which direction the chain grows, essentially choos- ing which transactions to verify. This is known as a '51% attack'. However, the risk of such an attack in a large network is very low as the attacker would need to gain control over a massive number of nodes. Therefore, large blockchains are effective at guaranteeing the integrity of IoT communications [23][24]. In general, hosting a blockchain node on an IoT device has been difficult because each node must store the entire chain of transactions. Many IoT devices have mem- ory and computational limits which keep them from being able to store entire chain data.