Applicability of Security Measures in a Wireless Sensor Network Use Case Martin Leuckert Peter R. Mertens Gunter Saake University of Magdeburg University of Magdeburg University of Magdeburg Clinic of Nephrology Clinic of Nephrology Department of Computer Science martin.leuckert@ovgu.de peter.mertens@med.ovgu.de saake@iti.cs.uni-magdeburg.de ABSTRACT streams throughput should not be slowed down significantly by Wireless Sensor Networks (WSN) are used widely and can be heavy encryption processing, but it probably has higher found in a growing number of heterogeneous applications. computational power and does not necessarily rely on battery Consequently, the amount of data produced by these systems power. increases tremendously. Most data produced by sensor networks is Until now, there have been few real applications for homomorphic confidential and needs corresponding security measurements. encryption due to the high demand in computational effort, space There are many different approaches to maintain data requirements, and noise [12]. However, recent advances in the confidentiality; homomorphic cryptosystems, for instance, became field of homomorphic encryption show that it is becoming a a popular research topic for WSN and Body Area Network (BAN) viable solution to achieve end-to-end confidentiality in wireless even though they were deemed too costly a few years ago. In the sensor networks [7, 11]. This paper will start a discussion on present paper, a selection of homomorphic encryption approaches whether this is still a long way off or an applicable option. will be compared to each other as well as to other current standard security measurements. The objective is to evaluate the data security, computational effort, memory requirements, key 2. USE CASE distribution (if necessary), energy consumption, and usability - Saxony-Anhalt has approximately 14,9% diabetics [1]. Diabetes from sensor to final storage. amplifies the probability and intensity of developing nerve damage, especially in extremities. Since this is an iterative process, affected people are not aware of the nerve damages and General Terms lack bodily responses like pain. As a result, they tend to stress Measurement, Performance, Design, Experimentation, Security, their feet incorrectly, which can cause the common secondary Human Factors, Legal Aspects. disease called ‘diabetic foot syndrome’. A diabetic foot syndrome leads to inflammations (called ulcer) and oftentimes to Keywords amputations. Data Confidentiality, Homomorphic Encryption, Wireless Sensor Network, Body Area Network. 2.1 Smart Prevent Diabetic Feet Armstrong et al. identified temperature increase in the respective foot regions up to five weeks before an inflammation occurs [3]. 1. INTRODUCTION Based on these findings, the “Smart Prevent Diabetic Feet” study Sensor Data are collected in very heterogeneous environments. intends to monitor foot temperature. For this purpose, a specially Landscape observing systems or military applications of Wireless manufactured insole with six temperature sensors distributed over Sensor Networks (WSN) are by nearly all accounts different from the insole at the positions shown in Figure 1 is used. The insoles sensor systems in a Smarter Home environment. However, they all are given out to 150 test persons who will be measuring twice a produce confidential data. Particularly if the sensors are recording day for two years. The signals sent by the insoles are then biometric traits or medical data in a Body Area Network (BAN), transferred to a smart device using the Bluetooth V4.1 interface. confidentiality, integrity and privacy need to be addressed. Due to The smart device running an Android App will use the data to the diversity of the systems, the possibilities for security evaluate whether an ulceration is about to develop. For this measurements are not identical. Battery powered sensors of evaluation of the data, several threshold-based algorithms are neither WSN nor BAN are deemed able to implement a highly used. For instance, opposing sensor values are compared. To sophisticated asynchronous cryptosystem as, for example, a improve the results, abnormal influences like a heater are filtered modern ‘IoT-device’ in a medical application can. Medical data out by including historic progression as well as performing ‘sanity checks’ on the data. As this is medical data, it is very valuable and can reveal a patient’s diseases like diabetes. Therefore, the sensor data produced in this setup needs to be protected. In the state of the art section the de facto standard for this kind of study as well as other security measures will be introduced. 30th GI-Workshop on Foundations of Databases (Grundlagen von Datenbanken), 22.05.2018-25.05.2018, Wuppertal, Germany. Copyright is held by the author/owner(s). areas of application [5]. However, all of them are considered suitable for the use of embedded systems with limited resources, whereas asymmetric approaches, for instance the 1024-bit RSA, are less suitable for a very small sensor device running on battery power. 4. Problem Formulation Acquisition Wireless Sensor Networks and Medical Applications produce tremendous amounts of confidential data. However, many of these applications open up severe security loopholes [13]. Especially on the sensors’ side, data security is sometimes non-existent. Due to Figure 1. Sensor layout of Smart Insole. their differences in cost efficiency, there are not many security measures that can be applied. Apart from computational While this example only considers foot temperature, it represents limitations, there are RAM constraints as well, which require an entrance into the topic. Many more health-monitoring block ciphers optimization of memory consumption. Energy applications, e-Health or “Ambient Assisted Living” systems consumption also remains an issue that concerns most produce or work with a patient’s data. However, many of them autonomous sensors, because renewable energy is absent. rely on an intermediate system – often called ‘aggregator’ or ‘IoT- device’ – like a smartphone or a tablet that gives meaning to the The most likely attacks are impersonation or denial-of-service collected sensor values. attacks [2, 4]. Usually, there are no backups for a sensor in a BAN; the denial-of-service attack may prevent that vital life 3. STATE OF THE ART signals are monitored. The impersonation attack on weak Previous research discusses both symmetric as well as asymmetric encrypted or even plain signals may disclose personal encryption. However, it was rather common to decline asymmetric information. In Wireless Sensor Networks, if a node is encryption due to high computational effort and energy compromised, it usually will be excluded from the cluster in case consumption [12]. Especially Clinical studies like Smart Prevent a malicious intent can be detected. BAN do not have these Diabetic Feet are obligated to comply with data security laws. To possibilities since they do not have any redundancy. This means meet this requirement, this study is performed as a blinded study. either that a compromised node leads to a data breach or even a Accordingly, all personal data are pseudonymized and shutdown of the compromised system. transportation of the data is protected from eavesdropping or man- in-the-middle attacks by implementing the standard encryption Communication protocol AES-128/256 for both the Bluetooth V4.1 interface and the HTTPS data transfer. For saving resources, communication protocols like Bluetooth Security Level 1 could be used, which do not implement any One could argue that personal data encrypted with AES-256 is security measures at all. In the context of highly confidential data, secure; however, the implementation of the cryptosystem may as in the use case described above, this cannot be used. To prevent have flaws. On the other hand, a major issue is the security on the attacks like ‘Man-in-the Middle’ or ‘Eavesdropping’, Bluetooth smart device, which is vulnerable to social engineering. Therefore, Security Level 4 (“Authenticated LE Secure Connections pairing to assure that the data is always protected, the data should never with encryption”) is used. This level requires a connection that be available as plain data. To prevent the access of plain data, the must be encrypted using the Secure Connection Pairing, which capturing devices are required to encrypt the data, or the mobile was introduced in Bluetooth LE version 4.2. However, this does device immediately encrypts the incoming data. This paper will not address already encrypted communications. If, for instance, a propose different setups and usages of encryption approaches. homomorphic encryption approach is applied, the additional effort This will include expectations regarding advantages, flaws and to encrypt the data again through the Bluetooth protocol produces feasibility of each setup. unnecessary overhead. Going back to Bluetooth Security Level 1 There is a broad variety of studies looking into node distribution makes sense in that case; however, the authentication issue and as well as the path and connectivity between nodes, but this is out impersonation still need to be addressed. of the scope of this paper. Instead, the research presented in this paper is based on previous studies on encryption approaches and security investigations. One of the main issues regarding security Storage in wireless sensor networks is the key distribution. Chen and There are major differences in terms of storing and working with Chao’s survey of key distribution schemes in WSN [9] are a encrypted data and plain data. While the assumption used to be valuable introduction into the topic. that a server will be compromised at some point, it is not There is a variety of (lightweight) encryption algorithms that can recommendable to trust a cloud system to begin with. The be used in BAN to protect the confidentiality of the data. Next to confidentiality and integrity of data is at risk at all times as long as the AES, which was mentioned before, there are the ‘Tiny no proper security measurements have been implemented. As each Encryption Algorithm’ (TEA) as well as lightweight block ciphers system faces individual threats, a fitting security scheme requires like HIGHT, PRESENT, Prince and KLEIN to name a few. Each a threat analysis. If the outcome is, for instance, that a certain of them has different advantages and disadvantages and different encryption shall be used, the question arises what this means for the database and the performance. Furthermore, if the data in a examples target different levels and stages of a system. Some database stays always encrypted, how does this affect the query attacks target the encryption process and others try to exploit performance, the storage requirements, and the design of the vulnerabilities of the communication. This means that the database? The different setups described in the following chapter selection of a ‘strong cryptosystem’ will not necessarily result in a shed light on the impact on usability, security, and performance. secure system. Even if an attacker would not be able to decrypt ciphertext, just 5. APPROACHES AND IDEAS listening to when a communication is established could result in Security investigations usually compare different cryptosystems the exposure of habits, like, for instance, when a patient is at against each other and look at the code length, block size, and the home. Vice versa: If an attacker knows when a patient is at home, number of rounds, etcetera. This paper will take the setup as a they could use this information to identify which dataset can be whole into account in order to identify additional parameters that associated with a patient. might influence the data security and performance. On the one hand, different cryptographic algorithms will be used; on the other Resource efficiency hand, the setups will encrypt and decrypt at different stages of the process. Because of the differences, each setup is expected to have Encryption and key management should not have a huge impact in different security and performance properties. Next to analyzing cases of limited resources. Usually, asymmetric approaches are possible attacks on the systems, the applicability for each involved not even considered, because they are deemed too expensive. device will be examined: This starts at the sensor device that Furthermore, the communication is rather cost heavy, which records data, continues at the aggregator, and finished at the means that fewer messages exchanged with as few packages as database. This also includes factors like the utilization of possible should be aimed at. resources (for instance computational effort or memory while computing), key distribution, the required time until data is Advantages & disadvantages available, and maintainability. Are there side effects brought along by the security measures? One of the setups will not use encryption and instead implement What operations can be performed on each stage of the process? the current data security requirements, which can be fulfilled by What are the side effects: e.g. searching in encrypted space is pseudonymization of the data. This setup is expected to be the much slower, takes more space etc. best in terms of computation times, time until availability and energy consumption. However, it is also likely that it poses the 5.1 Setup description greatest risk to the data. Some setups will implement symmetric This section describes the considered scenarios, their pros and encryption algorithm AES and lightweight encryption algorithms cons, security, and applicability. from section 3. For the asymmetric encryption, the additive homomorphic Paillier 5.1.1 Scenario 1: solution of use case The first setup corresponds to the current solution, which means cryptosystem and an elliptic curve algorithm as well as the fully that only the data transfer is encrypted. The transfer protocols homomorphic encryption ‘THFE’ from [7] are considered. The implement state-of-the-art encryption, which significantly Paillier is a good example of homomorphic encryption as it can be hampers eavesdropping. However, each device can potentially be utilized for Similarity Verification without decrypting the data [8, compromised in a way. The sensors may face imposter attacks, the 10]. However, it is expected to be too expensive compared to smart device could be compromised by malware and the server lightweight symmetric cryptographic algorithms. The paper and hosting the database may have an ill-intending administrator. The the open-source implementation in [7] raise high expectations and data is still pseudonymized, but both the sensors and the IoT- will therefore be compared to the performance, security and device can easily be linked to a single person as they always carry advantages and disadvantages of the Paillier cryptosystem as well it. as the lightweight symmetric cryptosystems. Expected outcomes are statements to each investigated approach regarding the resilience against compromises, the resource efficiency, and further advantages and disadvantages. Resilience against compromises While the intention is not to guarantee that a node is not compromised, the key distribution (where applicable) must be Figure 2. Scenario 1 – standard communication protocols. secure at all times. There is a variety of standard cryptanalysis that could be used to 5.1.2 Scenario 2: encryption on IoT-device compromise the system. A few exemplary attacks are ‘Brute The imposter attacks described in scenario 1, see Figure 2, require Force’, ‘Ciphertext-Only Attack’, and ‘Man-in-the-Middle exchanging the sensor devices, flashing the device’s firmware, or Attack’. The authors of [4] categorize the following examples as getting very close with an impersonating device due to the low ‘Modern Attacks’: An attacker could exploit ‘Operating System range of the Bluetooth signal. At least for this use case an Flaws’ or ‘Memory Residues’, ‘Temporary Files’, ‘Differential imposter attack is rather unlikely; therefore, the following two Power Analysis’, ‘RSA-155 (512-bit) Factorization’. The scenarios are considered: The sensor transfers encrypted data to the smart device, the data will be decrypted and immediately be 5.1.4 Scenario 4: always encrypted re-encrypted using a homomorphic encryption approach. A fourth scenario, see Figure 5, could be a mixture of 2 and 3; the data will be encrypted as soon as possible using a homomorphic public key cryptosystem and never decrypted. This appears to be the strongest solution in terms of resilience against compromises because the data is almost never available as plain data. On the other hand, encrypted data may still be vulnerable to key leakage, brute force attacks, timing attacks, loopholes in the cryptosystem or implementation and many other threats. Additionally, in scenario 4 all analysis of the data must be performed on the encrypted data, which is very time and resource consuming. Then Figure 3. Scenario 2 – encryption on IoT-device. again, the additional computation is performed on the backend The unencrypted data will never be stored on the device and is system, which has more available resources than the IoT-device. only available in memory for a short duration – just long enough to perform the pre-analysis of the data from Section 2. The device has more computational power and energy available than the sensor device and is expected to be able to perform the required calculations in reasonable time. The data will not be decrypted before the transfer to the database server and therefore stays secure. 5.1.3 Scenario 3: immediate encryption In scenario 3, see Figure 4, the sensor device already encrypts the Figure 5. Scenario 4 – always encrypted. data using a public-key cryptosystem (PK). A major difference The fourth scenario is different from Scenario 3, see Figure 4, between approach 2 and 3 can be found on the server side: In because the received data is not searchable and not indexed. approach 2, the data stays encrypted as is. This prevents most Therefore, working and analyzing with the data is hardly possible attacks if the data never gets decrypted and the key is not if it stays encrypted, because only limited operations like, for compromised. A disadvantage lies in the usability of the data, as it instance, a predefined set of threshold-based operations are is not searchable or indexable. This is different in approach 3a / possible, whereas other scenarios allow data mining processes to 3b, where the data will be decrypted on arrival. In 3a, the data will improve the ulcer detection algorithms from Section 2. immediately be re-encrypted on arrival using a searchable Assuming the corresponding private key is stored at a trusted third encryption scheme. For comparison, the data will stay party instead of the backend that stores the encrypted data, this unencrypted in approach 3b. approach prevents data leakage at server-side, because even if an attacker could gain access to the data, they cannot decrypt it. 5.2 COMPARISON This section summarizes the expected results of a security and performance analysis of the different setups. Various parameters can influence the results. For instance, increasing the key length will improve the security of a cipher but has negative side effects like reducing the possible throughput and increasing memory Figure 4. Scenario 3a/b – immediate encryption. consumption. In the use case from Section 2 the IoT-device is expected to perform a pre-analysis of the data based on thresholds. This Table 1. Expected performance of the scenarios (-- equals very operation can only be performed on the homomorphically bad / non-existent, ++ equals very good). encrypted data. Most of the known homomorphic encryption Resilience Resource schemes are asymmetric. For use cases that do not require the Scenario against efficiency Utility aggregator to work with the encrypted data, a symmetric approach compromises (collectively) could be used, but this is out of the scope of this paper. 1 -- o ++ As was mentioned before, the device is required to perform a pre- analysis of the data and decide whether the user’s temperature 2 o + + data is within a certain range or not. This can be done due the 3a + o + homomorphic encryption approach. Some homomorphic cryptosystems can be exploited in order to implement a 3b o + ++ “Similarity Search” [8], which allows the device to decide about the user’s health status without decrypting the data. 4 + - o Table 1 does not necessarily reflect the properties of each applied cryptosystem, but the investigated system it is used in. For example, the cipher produced by AES256 can be assumed to be where applicable); on sensor device side the encryption effort is resilient against brute force attacks, but there could still be an looked at. The limiting resource factors for each component can imposter sending the cipher. The possibility of an imposter attack vary depending on the performed operations, the selected is a security flaw of the system rather than of the applied encryption (function and key length) and the available resources cryptosystem. per component. Due to this, there can be different limiting factors It is not possible to just eavesdrop the communication in approach like, for instance, CPU, RAM or network adapters (esp. 1 because the messages are encrypted, but, on every other Bluetooth). Hardware accelerations are not used. component, the data is available as plain text. For this reason, it is If a similar threshold-based verification like Rane et al. introduced very prone to compromises of many kinds. This is different in all in [8] is used, the verification takes place on a trusted third party. other setups; however, each has its own advantages and However, this does reduce the required effort for the aggregator or disadvantages and no setup is expected to be perfectly secure. backend because there are still homomorphic operations prior to Furthermore, as stated in the introduction of this section, there are the verification itself, which have a similar effort. different requirements to different use cases. For example, a The tables should be understood as a hypothesis of this work. It sensor network with very high throughput and near real-time changes depending on requirements of use cases, availability of availability requirements must not be delayed by too much resources, and applied cryptosystems. Furthermore, it can be because of computational overhead. extended by additional setups and requires analyzing each The databases stay unencrypted in approaches 1, 2, and 3b. component (sensor device, IoT-device, backend, and Medical data protection for clinical studies require the communication channels) individually. implementation of proper access control and implementing pseudonymization and a locally secured room for the servers. 6. CONCLUSION When these requirements are accomplished the data is somewhat All proposed setups have different properties and their suitability secure because it is hard to gain unauthorized access. Assuming does not only depend on the computational power of the nodes an attacker managed to get access to the study database from the but also the quantity of collected data, expected real-time use case of Section 2, they cannot immediately tie data sets to a availability, data security requirements and many more. There are person because the datasets are pseudonymized. This is different vital parameters recording applications, which require special if the attacker already has background information about the safety and security precautions, while, on the other hand, a forest probands because they could use their knowledge to look for fire detection application, probably is not as demanding. habits or patterns of the patients, e.g. when they usually go to The next step will be to implement the proposed setups and vary church, to identify their pseudonym and therefore their datasets. the parameters. This includes sensor signals and different Nevertheless, it would leak information about the study, or, in encryption approaches with varying key length. An expected different use cases, other meta information. Here again, this is a outcome of the investigation is a collection of statements question for risk assessment and applicable law, which can play regarding the requirements of a setup as discussed in section 1, different roles for each use case. In Table 1, this is reflected by the data security including possible attacks, as well as usability of decreasing the security score compared to encrypted databases, the data (can it easily be queried, etc.). because it is less secure. On the other hand, the usability of plain data or searchable encryption schemes are better: Queries, Another important step would be to retrieve more general indexes, transactions and stored procedures are easily processed statements about the applicability of the proposed setups. Where because information about the data is given or obtainable. else can they be applied? What if the database is not located in a Table 2 gives more in-depth information about the resource trusted environment, e.g. in a cloud system? consumption per component. The first scenario only uses standard protocol exchanges, which is why it is not affected by the 7. ACKNOWLEDGEMENTS selection of cryptographic function. All other scenarios are This work was funded by the project „Smart Prevent Diabetic affected by this. Feet“ (DRKS00013798) - EFRE (2016 - 2018): Forschungsverbund “Autonomie im Alter”. Table 2. Resource consumption per component. 8. REFERENCES Scenario Sensor Aggregator Backend [1] Heidemann, C., Kuhnert, R., Born, S., Nave, C. “12-Month device prevalence of known diabetes mellitus in Germany”, Journal 1 Medium Low Low of Health Monitoring, 2017. 2 Medium High Medium [2] Al Ameen, M., Liu, J. & Kwak, K. “Security and Privacy Issues in Wireless Sensor Networks for Healthcare 3a Very high High Medium Applications”, Journal of Medical Systems, 2012. 3b Very high High Low [3] Armstrong, DG., Holtz-Neiderer, K., Wendel, C., Mohler, Jane, M., Kimbriel, Heather R., Lavery, Lawrence A. “Skin 4 Very high High Medium temperature monitoring reduces the risk for diabetic foot ulceration in high-risk patients”, The American journal of medicine, 2007. The values for the aggregator and backend include encryption, decryption and homomorphic operations for the pre-analysis (each [4] O'Hanley, R., Tiller, J. S., “Methods of Attacking and [8] Rane, S., Sun, W., Vetro, A. “Secure similarity verification Defending Cryptosystems” Information Security between homomorphically encrypted signals”, U.S. Patent Management Handbook, Sixth Edition, Volume 7, 2013. 8249250 B2, 2012. [5] Singh, S., Sharma, P.K., Moon, S.Y. et al. “Advanced [9] Chi-Yuan Chen, Han-Chieh, Chao. “A survey of key lightweight encryption algorithms for IoT devices: survey, distribution in wireless sensor networks”, 2011. challenges and solutions”, Journal of Ambient Intell. Human [10] Dargad, A., & Sutar, S. “Enhanced Data Leakage Detection Comput, 2017. in IoT Network Backup with Cloud Using Paillier [6] Castelluccia, C., Chan, A. C-F., Mykletun, E., Tsudik, G. Homomorphic Cryptosystem”, Asian Journal of Convergence “Efficient and provably secure aggregation of encrypted data in Technology, 2018. in wireless sensor networks”, ACM Trans. Sen. Netw. 5, 3, [11] Brakerski, Z., Gentry, C., Vaikuntanathan V. “(Leveled) Article 20, 2009. Fully Homomorphic Encryption without Bootstrapping”, [7] Chillotti, I., Gama, N., Georgieva, M., Izabachène, M. ACM Trans. Comput. Theory 6, 3, Article 13., 2014. “Faster Fully Homomorphic Encryption: Bootstrapping in [12] Lauter, K., Naehrig, M., Vaikuntanathan, V. “Can Less Than 0.1 Seconds”, Advances in Cryptology – homomorphic encryption be practical?”, Proceedings of the Asiacrypt 2016, 2016. 3rd ACM workshop on Cloud computing security workshop, 2011.