=Paper=
{{Paper
|id=Vol-2126/paper7
|storemode=property
|title=Applicability of Security Measures in a Wireless Sensor Network Use Case
|pdfUrl=https://ceur-ws.org/Vol-2126/paper7.pdf
|volume=Vol-2126
|authors=Martin Leuckert,Peter R. Mertens,Gunter Saake
|dblpUrl=https://dblp.org/rec/conf/gvd/LeuckertMS18
}}
==Applicability of Security Measures in a Wireless Sensor Network Use Case==
https://ceur-ws.org/Vol-2126/paper7.pdf
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.