An effective handling of secure data stream in IoT

Accepted Manuscript Title: An Effective Handling of Secure Data Stream in IoT Author: Jaejin Jang Im.Y Jung Jong Hyuk Park PII: DOI: Reference:

S1568-4946(17)30273-9 http://dx.doi.org/doi:10.1016/j.asoc.2017.05.020 ASOC 4224

To appear in:

Applied Soft Computing

Received date: Revised date: Accepted date:

27-1-2017 20-4-2017 8-5-2017

Please cite this article as: Jaejin Jang, Im.Y Jung, Jong Hyuk Park, An Effective Handling of Secure Data Stream in IoT, (2017), http://dx.doi.org/10.1016/j.asoc.2017.05.020 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

Jaejin Janga , Im.Y Junga,∗, Jong Hyuk Parkb,∗ a School

ip t

An Effective Handling of Secure Data Stream in IoT

us

cr

of Electronics Engineering, Kyungpook National University, 80 Daehakro, Daegu 41566, South Korea b Dept. of Computer Science and Engineering, Seoul National University of Science and Technology, Seoul 01811, South Korea

Abstract

an

Internet-of-Things (IoT) applications are a primary domain for data streams, which travel through a heterogeneous network consisting of the Internet and low-speed IoT to be sent to a data collector. However, when a large data

M

stream is transmitted, overhead results from the difference between the speed and maximum transfer unit of IoT and the existing Internet. The overhead increases as data size increases. This problem is a critical factor for IoT devices

d

that are sensitive to power consumption and data streams that must be handled

te

in real time. To solve this problem, we compressed the data stream using a low-density parity check (LDPC) code. Since compression using the LDPC code can be applied even when the data stream is encrypted, the compression

Ac ce p

can be used in applications requiring privacy or confidentiality. Therefore, this study proposes a method to improve the usability of encrypted data streams in the IoT environment. We implemented IoT devices that generated data streams using Raspberry Pi, a desktop computer, and collectors that collect data streams. The results of experiments using temperature sensor data show that the communication time for data stream transmission decreased by 56.1– 75.5%. In addition, the power consumption of IoT devices for data transmission decreased by 54.8-75.3%. In order to perform compression handling by the IoT device, the maximum memory usage and CPU usage increased by 0.3% ∗ Corresponding

author Email address: [email protected], [email protected] (Jong Hyuk Park)

Preprint submitted to Applied Soft Computing

April 18, 2017

Page 1 of 37

and 10.1%, respectively. As a result of this research, it is expected that the transmission time to collectors, as well as the power consumption of IoT devices,

ip t

can be reduced while securing data streams generated by IoT devices.

cr

Keywords: Secure Data Stream, IoT, Usability

1. Introduction

us

The Internet of Things (IoT) is a key domain in which data streams are generated, and the volume of this data is expected to increase [1, 2, 3, 4, 5, 6,

5

an

7, 8, 9]. A data stream has an unbounded size, the rate at which the data is generated varies widely, and the data must be processed online or in near real– time [5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]. A data stream collector

M

collects data streams, and the collected information is processed to determine its knowledge or value [21]. When a data stream generated from an IoT device is transmitted to a collector, the data stream traverses a heterogeneous network composed of the IoT and Internet. The IoT often uses a slow network such

d

10

as Bluetooth Low Energy (BT-LE), ZigBee, or Z-wave to accommodate the

te

limited resources of IoT devices, while the Internet uses fast networks such as Ethernet or Wi-Fi [22]. In addition, since the IoT network has a small

Ac ce p

maximum transfer unit (MTU), as the size of data to be transmitted increases,

15

the number of fragmentations and reassemblies for transmission increase sharply compared to the Internet. Table 1 lists the speeds and MTUs of the Internet and IoT [23, 24, 25, 26, 27, 28, 29, 30]. Owing to this difference in network performance, when data is transmitted

from IoT devices to the Internet, most of the transmission time is consumed in

20

the IoT network.

Fig. 1 shows the proportion of transmission time consumed when various

sizes of data are transmitted from the low-speed IoT to the Internet. As seen in the figure, when transmitting to the collector, most of the time is consumed by the transmission to an IoT border router. Table 2 shows that this process 25

consumes more than 80% of the transmission time in the IoT network.

2

Page 2 of 37

Table 1: Speeds and MTUs of Internet and IoT networks

10 MB-107 GB/s

1500

802.11ac(Wi-Fi)

454 MB-7.26 GB/s

2304

Z-Wave

40-100 KB/s

ZigBee

250 KB/s

Bluetooth Low Energy

1 MB/s

ip t

802.3(Ethernet)

127

127 27

Ac ce p

te

d

M

an

IoT

MTU(bytes)

cr

Internet

Speed

us

Network

Figure 1: Specific weight of transmission time in Internet and low speed IoT

Table 2: Specific weight rates of transmission time

Data Size (KB)

Rate (%)

100

100

200

87.09

400

89.58

800

95.66

1600

90.09

3

Page 3 of 37

Table 3: CPU, RAM, and power of IoT prototype platform

CPU

RAM

Raspberry Pi

ARM BCM2835

256-512 MB

Arduino

ATMEGA8, ATMEGA168

16-32 KB

AM335x 1GHz

512 MB

ARM CoretexA8 PhidgetSBC

Udoo(Quad)

Freescale i.MX6Quad

7-12 V/USB

5V

64 MB

6-15 V

1 GB

6-15 V

an

Phidgets

us

BeagleBone Black

5 V/USB

cr

ATMEGA328, ATMEGA1280

POWER

ip t

Name

4 ARM CoretexTM–A9

Atmel SAM3X8E ARM

M

CortexM3 CPU

Increases in transmission time and fragmentation/reassembly tasks depend-

d

ing on the data size are critical to IoT devices. This is because IoT devices have

te

limited resources and are sensitive to power consumption [31]. Table 3 lists the specifications of the devices used to implement a popular IoT prototype [32]. 30

As seen in the table, the central processing unit (CPU) used is slower than a

Ac ce p

desktop or laptop, the RAM is smaller, and the power operates at a low voltage level [33].

To solve this problem, we propose a handler that can improve the usability

of the data stream. This method can be applied to an encrypted data stream,

35

as well as applications requiring security. By compressing the data stream using low-density parity check (LDPC) codes, the size of the data stream is reduced and transmission speeds up as the size decreases. A reduction in transmission time can help to satisfy the characteristics of

the data stream, which should be processed in real time and reduce the power 40

consumption of the IoT device. A variety of studies have been conducted to overcome the differences between Internet and IoT networks, but the research has focused on increasing the pay4

Page 4 of 37

load by compressing the header of each protocol. However, in this study, we solved the problem by compressing the payload itself rather than the header, even if the payload was encrypted.

ip t

45

The results of experiments with IoT devices and collectors using Raspberry

cr

Pi and a desktop computer show that the average transmission time to a col-

lector was reduced by 61.63%, while the average power consumption of an IoT

50

us

device was reduced by 61.08%. The CPU and memory usage for performing the proposed handling increased by 0.50% and 0.30%, respectively, for a data size

an

of 1600 KB, which was the largest usage.

The contributions of this study are as follows:

• Reduced transmission time to data stream collector.

The data stream has characteristics that should be processed in real time.

M

55

In order for the data stream to be processed, it must first be collected into

d

a collector. In an IoT environment, however, the data stream is delayed owing to network differences. We reduced the delay by an average of

60

te

61.63% by compressing data using an LDPC code. This can help satisfy the data stream characteristics that need to be processed quickly.

Ac ce p

• Reduced power consumption of IoT devices. Since an IoT network uses a slow network such as BT-LE, ZigBee, or Zwave, the transmission time increases significantly when the size of the transmitted data stream increases. In addition, because these slow net-

65

works have small MTUs, fragmentations and reassemblies for data transmission also increase. This increase is a critical factor in IoT devices that are resource constrained and sensitive to power consumption. We reduced the power consumption for data stream transmission by compressing the data stream to reduce its size. Thus, the power consumption for a data

70

stream that should be transmitted frequently can be reduced. In order to perform the proposed handling, the Raspberry Pi has a run time of less than 1 s, and an increase in memory and CPU usage is acceptable. 5

Page 5 of 37

• Payload compression studies of packets. Studies aimed at reducing the network performance gap between the IoT and Internet have focused on the header compression of packets. In con-

ip t

75

trast, this study investigated the payload compression of packets. This

cr

method is applicable even if the payload is encrypted. This new approach

could provide a new approach for existing research that focuses only on

80

us

header compression.

This paper is organized as follows; Section 2 explains background for our studybasic terminology and theories. In Section 3, we discuss related works.

an

In Section 4, we propose a method for effective handling of secure data stream. Section 5 presents the experiments and analysis, including implementation, ex-

85

study and discuss future work.

d

2. Background

M

perimental method, and interpretation of results. In Section 6, we conclude our

te

In order to understand related research, this section describes the IoT net-

Ac ce p

work structure and its basic terminology and theories.

90

N etwork architecture of the IoT : Fig. 2 shows an example of an IPv6

network and a 6LoWPAN network [34]. All hosts, including hosts in 6LoWPAN, have IPv6 addresses. Each router is responsible for routing between hosts in the sub network and external hosts. In this study, a device in the 6LoWPAN network in Fig. 2 generates the data stream, and the server is a collector that

95

collects the data stream.

IP v6 over Low − P ower W P AN (6LoW P AN ): 6LoWPAN is a low-power

network that supports IPv6 and is based on IEEE 802.15.4 [35]. In the case of IPv4, which is currently widely used, addresses cannot be given to IoT devices owing to a lack of address space. IPv6 is applied to solve this problem [36]. It

100

is based on IEEE 802.15.4, a standard network for low-power devices to satisfy the low-power characteristics of IoT devices. 6

Page 6 of 37

Constrained Application P rotocol(CoAP ): CoAP is a protocol for supporting the application layer in resource-limited devices such as IoT devices [37].

105

ip t

It is based on User Datagram Protocol (UDP) communication in the transport layer and optionally supports Datagram Transport Layer Security (DTLS), an

cr

IoT security protocol.

Distributed Source Coding: Distributed source coding is used to reduce

us

network traffic in applications such as sensor networks [38]. Fig. 3 shows a

Ac ce p

te

d

M

an

block diagram of distributed source coding when there are two sources [38].

Figure 2: Example of IPv6 and 6LoWPAN network

110

Each source is independently encoded, but decoding is performed at the

same time. In this figure, roles are defined for each block as follows: X: Data stream generated from the IoT device Y: Private key distributed between the IoT device and data stream collector X Encoder: IoT border router

7

Page 7 of 37

ip t cr

115

Y Encoder: IoT border router Ideal Channel: Internet (Ethernet, Wi-Fi)

us

Figure 3: Example of distributed source cording with two sources

an

Joint decoder: A data stream collector that collects data streams

In this study, it is assumed that the secret key is distributed or agreed upon in advance. Therefore, the value of Y is distributed to the IoT device and the

M

120

Ac ce p

te

d

data stream collector in advance, and the Y encoder does nothing.

Figure 4: Example of decoding with (6,3) LDPC codes

LDP C Codes: An LDPC code is an error-correction code of (n, k), where

the matrix has a size of [(n − k × n)]. Each element has a value of 0 or 1, and the

125

weight of 1 is low. Generally, LDPC codes are used as error-correction codes, but in this study, data is compressed using LDPC codes [39]. Fig. 4 shows an example of compression using LDPC codes [40]. H denotes an LDPC code, r denotes a received data bit, and z denotes a syndrome. In general use, it is determined whether the result of z is 0 to verify if decoding is performed correctly.

130

However, in this study, the LDPC code plays the role of compressing data. In this example, the data of (101011) is compressed to (000). There are values 8

Page 8 of 37

compressed to (000), such as (000000) and (001110), apart from (101011). On the receiving side, the compressed data is decompressed by selecting the correct

135

ip t

value from among the plurality of values mapped to the received syndrome using the characteristics of the IoT device and the data. This process is explained in

cr

detail in related works.

us

3. Related works

This section describes related research. Section 3.1 describes the study of data streams related to security and time delays. Section 3.2 explains a study related to IoT protocol header compression. Section 3.3 details studies related to data compression using LDPC codes.

an

140

M

3.1. Study of data streams related to security and time delay Recently, several data stream security studies have been conducted. In [41],

145

d

researchers proposed an efficient real-time security verification model that uses a variable key length for the data stream. Secret key cryptography was targeted,

te

and the key length was defined as 128, 64, and 32 bits. However, it is more reasonable to use a stream cipher if we consider the nature of the unbounded

Ac ce p

data stream and the performance of the IoT device. In this study, we consider stream ciphers that match the characteristics of data streams. In addition to

150

encryption, compression also reduces the transmission time to the data stream collector. This improves the characteristics of the data stream that need to be processed quickly.

3.2. Study to improve the difference between IoT and Internet In [42], researchers studied the compression of Internet Protocol security

155

(IPsec) protocol headers in 6LoWPAN. Since IPsec operates at the network layer, it has the advantage of ensuring the confidentiality and integrity of the transport layer header, unlike a transport layer security protocol such as TLS.

9

Page 9 of 37

IPsec consists of an Authentication Header (AH) that handles data integrity and authentication, and an Encapsulating Security Payload (ESP) that provides data confidentiality, authentication, and integrity.

ip t

160

AH using HMAC-SHA1-96 as an authentication function was compressed

cr

from 24 bytes to 16 bytes; ESP using AES-CBC as a cryptographic function was compressed from 18 bytes to 12 bytes; and ESP using AES-CBC and HMAC-

165

us

SHA1-96 was compressed from 30 bytes to 24 bytes. AH saved 8 bytes, ESP with encryption saved 6 bytes, and ESP with encryption and authentication saved 6 bytes.

an

ESP's limitation is that the header of the upper layer [Transmission Control Protocol (TCP) or UDP] is encrypted, and hence cannot be compressed. To

d

M

solve this problem, a new algorithm that can compress and encrypt is required.

170

te

Figure 5: IPsec ESP format

Fig. 5 shows the encrypted and authenticated parts when using ESP [43]. As

Ac ce p

shown in this figure, the data part and the ESP Trailer part are encrypted. The data part contains the header of the upper layer (TCP, UDP) but is encrypted and becomes impossible to compress. In [37], researchers studied the header compression of DTLS for CoAP. DTLS

175

was used as a security protocol for CoAP. DTLS was internally divided into a Record layer and a Handshake layer. The Record header was compressed from 104 bytes to 40 bytes, and the Handshake was compressed from 96 bytes to 24 bytes. This saved 64 bytes in the Record header and 72 bytes in the Handshake header. In the initial message of the DLTS connection, the ClientHello message

180

was compressed from 336 bytes to 264 bytes, and the ServerHello message was compressed from 304 bytes to 264 bytes. In [30], researchers defined a standard for compressing IPv6 packets across IEEE 802.15.4. This document detailed the contents of Section 10 of [30]. IEEE 10

Page 10 of 37

802.15.4 has 127 MTUs, whereas for IPv6 packets, the MTU has 1280 bytes. If 185

a host outside IEEE 802.15.4 sends a single IPv6 packet that is larger than 127

ip t

bytes to a host inside IEEE 802.15.4, it needs to be fragmented and reassembled within the IEEE 802.15.4 network for transmission. The study defined how

cr

to increase the size of a transmitted payload by compressing IPv6 headers in an IEEE 802.15.4 network. In addition, LOWPAN HC1 and LOWPAN HC2,

which are proposed in [30], were improved. LOWPAN IPHC defines how to

us

190

compress unique, local, and multicast IPv6 addresses and hop limit values. LOWPAN NHC is a method for compressing the Next Header. In the case of

an

link-local communications showing the greatest compression, it was possible to compress to 2 bytes. When communicating with an external network, it can be 195

compressed to 7 bytes. The size of a typical IPv6 header is 40 bytes.

M

This study also defined compression for UDP headers. The port number was compressed to 4 bits. In addition, the researchers saved 2 bytes when using tunneling by omitting the checksum value of UDP when the message integrity

In [31], researchers addressed the transmission of IPv6 packets in BT-LE

te

200

d

check value can be guessed.

communications. Section 3.2.3 defines the header compression. In the case

Ac ce p

of link-local communication, the source and destination addresses of IPv6 can be omitted because the IPv6 address can be inferred by using the neighbor cache as an entry containing the destination’s interface identifier (IID) and the

205

equipment address.

When communicating with external devices, a case was defined wherein the

source address and destination prefix can be omitted. If the context defines a prefix for the global IPv6 address of a slave Bluetooth device, then the 6LoWPAN Border Router/master relaying the communication with the external de-

210

vice assigns the prefix to the device, and the value of the address and IID can be seen from the neighbor cache. Therefore, the source address can be omitted. If the connection context is defined for an IPv6 destination address, it can be omitted because the prefix of the destination can be computed from the connection context. 11

Page 11 of 37

215

In [31, 42, 37, 30], researchers studied the compression of headers. References [42] and [37] addressed the header compression of the security protocols IPsec

ip t

and DTLS in 6LoWPAN networks, while [31] and [44] discussed IPv6 header compression in IEEE 802.15.4 networks and IPv6 header compression in BT-LE

220

cr

networks.

Unlike these studies, the present work deals with payload compression rather

us

than header compression. Compression utilities such as Gzip, bzip, 7z, and zip cannot be compressed if the data stream is encrypted for security reasons. To

an

solve this problem, we compressed the encrypted data stream using LDPC codes. 3.3. Compression with LDPC codes 225

In this section, we discuss data compression studies using LDPC codes. We

M

prove that encrypted data compression is not possible with a conventional compression utility.

d

3.3.1. Encrypted data compression using Gzip

Data compression is the reduction of redundancies in data. The encrypted data was further tested with Gzip for various data [45]. Table 4 lists the results.

te

230

We added the encryption of AES–128 in various operating modes. The

Ac ce p

original data are zero values and are compressed using the OpenSSL command [46]. The encryption key is ”EncryptedData. The compression method is the same as [45], with Gzip applying the most powerful compression option -9.

235

As seen in Table 4, it can be confirmed that the encrypted and random

data cannot be compressed except for Tarball, zipfile, and JPEG, which are already compressed and have low compression efficiency and Electronic Codebook (ECB) operation modes. Owing to the meta-information for the compression utility, the size of the data increases.

240

The ECB operation mode has good compression efficiency because it divides the data into same-sized blocks and then encrypts with the same key. Since zero values are used as the original data before the encryption, in the ECB operation mode, each divided block has the same value and is encrypted with the same

12

Page 12 of 37

ip t cr

Size(bytes)

Compressed size(bytes)

Binary zeros

1048576

1057

Wikipedia XML

1048576

H.P. Lovecraft Text

1048576

gdb ELF64

1048576

an

us

Table 4: Results of data compression on various file formats

Random ASCII Hex

1048576

607628

Base64 random data

1048576

796856

Tarball

1048576

1039974

1048576

1041544

JPEG

402926

406290

M

d te

Zipfile

359184

1048576

1047418

1048576

1048761

AES-128-CBC

1048576

1048795

AES-128-CFB

1048608

1048779

AES-128-CTR

1048592

1048779

AES-128-ECB

1048608

2149

AES-128-OFB

1048592

1049779

Ac ce p

Random binary data

13

Page 13 of 37

encryption key. Thus, the encrypted blocks all have the same value. As a result, 245

ECB operation mode has good compression efficiency. Fig. 6 shows the ECB

d

M

an

us

cr

ip t

operation mode [47].

te

Figure 6: Block cipher ECB operation mode

Whether the data can be compressed well can be easily determined by check-

Ac ce p

ing the data entropy [48]. Entropy is equal to the likelihood of guessing the data. If entropy is low, then it is easy to guess, which means that a considerable

250

amount of similar data is coming out. If the entropy is high, then the opposite is true. Eq. 1 is a formula for calculating data entropy. P(xi) denotes the probability of xi in the entire data, b denotes the number of kinds of data, and xi denotes the i-th data.

H(x) = −

n X

P (xi ) logb P (xi )

(1)

i=1

The entropy was calculated using Eq. 1 to check whether the data used in 255

Table 4 can be compressed. Table 5 shows the results. The random binary data has two outputs, so b = 2 in Eq. 1. In the case of AES128 encoded data, b = 2128, but for the reality of calculation, b = 256, which is a byte unit. 14

Page 14 of 37

Table 5: Results of entropy calculation on various file formats

Random binary data

1.00000

AES-128-CBC

7.999838

AES-128-CFB

7.999809

AES-128-CTR

7.999862

AES-128-ECB

4.000491

AES-128-OFB

7.999825

cr

0

an

us

Binary zeros

ip t

Entropy(bits)

The results confirm that the encryption (except for the random binary and

260

M

ECB) has the same entropy as the basic unit. In the case of the random binary, there are two cases with output 0 and 1. It can be seen that the entropy is 1 bit, so it is impossible to make a complete guess. Ciphers other than the ECB

d

operation mode also have uniform output with no specific pattern since they

te

have 8 bits of entropy. In the case of ECB, we can confirm that compression can be made easier by having 4-bit entropy, which is half the level of other ciphers, 265

as in the compression results in Table 4.

Ac ce p

The above results show that the encrypted data cannot be compressed by a

general compression utility. However, it is possible to compress encrypted data using LDPC codes.

3.3.2. Compression with LDPC codes

270

In [49], researchers studied the compression of binary data using LDPC

codes. The compression method coincides with the syndrome concept described in Section 2, and the data flow also has the same structure as in Fig. 3. In this study, we assume that each bit has a different probability of X and Y that is less than 50%. However, the assumption that X and Y differ by less than 50%

275

is not consistent with the assumption of our study because Y must be randomly generated as a key stream used for encryption. In addition, it is confirmed that

15

Page 15 of 37

Rx ≥ H(X|Y ) Ry ≥ H(Y |X)

ip t

(2)

Rx + Ry ≥ H(X, Y )

cr

LDPC performs better than turbo code, which is another error-correcting code. The researchers in [50] also studied compression using LDPC codes, but they

method for unattributed data has not been explicitly described.

d

M

an

280

us

focused on general data compression rather than specific data. A decompression

te

Figure 7: Example of Slepian-Wolf region

In [38], researchers proposed code generation to efficiently solve the decoding

Ac ce p

problem of distributed source encoding. In applications such as sensor networks, distributed source coding is required to eliminate unnecessary traffic in the network. They proposed block code generation that could achieve any point in

285

the SlepianWolf region for any associated sources using only a single code. The Slepian-Wolf region determines the region with the lossless compressible coding rate for two or more sources. For two sources, the coding rate is given by Eq. 2 and is shown in Fig. 7.

In [51], researchers studied the compression of encrypted data for the first

290

time. Distributed source coding was applied by considering the encrypted data and key as the respective sources. The receiver could decompress and decrypt the encrypted data by performing simultaneous decoding using the received encrypted data and key. The code used for distributed source coding was the LDPC code proposed in [38]. As a result, they encrypted a 100 × 100 binary 16

Page 16 of 37

295

image where only 706 pixels were 1, compressed to a rate of 1/2, and decompressed without loss. The encryption was performed simply on the bitwise XOR

ip t

by the random key stream. However, the data used in the simulation was not realistic.

300

cr

In [52], researchers studied the lossless compression of an encrypted grayscale

image. They proposed Resolution Progressive Compression to compress more

us

efficiently. The statistical value of the picture sampled at low resolution was used as additional information, while gradually increasing the resolution of the picture. The image was encrypted by XOR with the key stream in bit.

305

an

In [53], researchers studied the lossless compression of encrypted color and grayscale images. Unlike [51], this study considered spatial correlations between pixels in an image. For a grayscale image, it proposed compression of neighbor-

M

ing pixels by considering the association with the bit plane, and compression of the color image using the correlations between different color bands. Most of the studies have used compression with LDPC codes for picture files. A picture file is a good example because it has a spatial correlation between color

d

310

te

bands and pixels. However, in this research, it is impossible to use the resolution progressive compression used in previous studies, or the correlation between the

Ac ce p

pixel and the color band, because the IoT device compresses the generated data. We used the characteristics of IoT devices and data to select the correct values

315

for decompression.

4. Effective handling of secure data stream This section describes the proposed data stream handler to increase usability.

Section 4.1 describes the flow of the data stream. Section 4.2 explains the transmission of data streams from an Internet device. Section 4.3 explains how

320

to decompress the received data stream. 4.1. Data stream flow Fig. 8 shows the transmission flow of the data stream. The data stream arrives at the data stream collector via the IoT border router from the IoT 17

Page 17 of 37

ip t

cr

Figure 8: Data flow between IoT device and data stream collector

device. BT-LE, ZigBee, and Z-wave, which are slow and have low MTU, are used between the IoT device and IoT border router. Between the router and

us

325

collector, Ethernet and Wi–Fi–which are high speed and high MTU–are used. The IoT device transmits data on a regular basis, or by a request message such

an

as Update, or whenever data is generated [54, 55, 56, 57]. The transmitted data stream may be optionally transmitted in plaintext or encrypted using encryption to transmit the data.

Ac ce p

te

d

4.2. Transmission in IoT device

M

330

Figure 9: Data transmission mechanism in IoT end device

Fig. 9 shows the transmission of the data stream from the IoT device. It is

appropriate to use a stream cipher for the encryption algorithm because the data stream has unbounded boundaries, and the stream cipher has a faster processing

335

speed than a block cipher. In addition, since the IoT device is a resource-limited device, a stream cipher with a simple structure is more suitable than a block cipher. It is appropriate to apply lightweight stream ciphers for devices with limited resources such as Grain, Trivium, MICKEY, and WG-8 [58, 59, 60, 61]. Fig. 10 shows an example where 1 byte of data with a value of 27 (00011011

340

binary) is encrypted with a keystream and compressed using LDPC codes. 18

Page 18 of 37

ip t cr us

an

Figure 10: Example of data transmission mechanism in IoT Border Router

(00011011) is encrypted by the XOR operation with the key stream (01010000)

M

generated based on the previously distributed seed. AND is compressed using the (2,1) LDPC code. In this example, it is read in 2-bit units and processed as 1 bit. (00,11) is processed as (0), and (01,10) is processed as 1 and compressed to a value of (1010). The LDPC code for 2 bits can be sufficiently stored if it

d

345

te

has space to store the 2 × 2 matrix. Each element of the matrix can be stored as 32 bytes if stored as ASCII code, or 4 bits if matched to 1 bit. In this study, the LDPC code table was not created but embedded in program code.

Ac ce p

We can apply the above procedure to all data streams and perform zero

350

padding if necessary. The application of the encryption algorithm is optional or as needed. Compressed data that is half the size is sent. Unless the secret key is exposed, the security of the data is not compromised even when the compressed data is transmitted.

4.3. Receiving in data stream collector

355

Fig. 11 shows the process of decompressing the received 4 bits of data into

the original data. Each bit in the bitstream 1010 may have two outputs: (0) can have (00,11), and (1) can have (01,10). Since 4 bits are needed to decompress 1 byte, the following 16 bytes can be generated: 01000100, 01000111, 01001000, 01001011, 01110100, 01110111, 1111000, 01111011, 10000100, 10000111, 10001000,

19

Page 19 of 37

ip t cr us

Figure 11: Example of receiving data in data stream collector

10001011, 10110100, 10110111, 10111000, and 10111011.

an

360

The key stream is XOR the 16 outputs to perform decryption (00010100, 00010111, 00011000, 00011011, 00100100, 0100111, 00101000, 00101011, 11010100,

M

11010111, 11011000, 11011011, 10100100, 10100111, 10101000, and 10101011). Unless the encryption key is exposed, it cannot be decrypted with the correct value, so there is no hindrance to security. AND decides the value of results by

d

365

using the sensor characteristic of the IoT device and general output value.

te

As an example of the temperature data used in the experiment, the temperature sensor can measure between 40 and 125 ◦ C with SHT75 [62]. Therefore,

Ac ce p

it is possible to exclude those that fall outside the effective range (10010100,

370

11010111, 10100100, 10100111, 10101000, 10101011) falling to 40 ◦ C. At the

position where this sensor is installed, since the temperature is always in the second half of the range of 20 ◦ C, only (00011011) can be valid data. This

process decompresses the data compressed with the LDPC code. If encryption is not applied, it is performed without XOR the key stream.

375

5. Experiments and analysis 5.1. Implementation In this section, we implemented the IoT device, IoT border router, and data stream collector.

20

Page 20 of 37

Table 6: Specifications of Raspberry Pi 2 and Desktop

Desktop

OS

Raspbian Jessie

Ubuntu 16.04 LTS

CPU

4-core BCM2836

Intel i5 CPU 2.80 Ghz 4

RAM

1 GB

10 GB

Network

Bluetooth Low Energy (USB)

Wired Ethernet

cr

IoT device: The IoT device was implemented using Raspberry Pi 2. We

an

380

us

Wired Ethernet

ip t

Raspberry Pi 2

used 6LoWPAN, which utilizes BT-LE, and IoT SDK for this purpose [63]. The sending program used the modified Python example provided in [58], and the

M

compression was written in C. The LDPC code used for compression was created using the LDPC code library [64]. 385

IoT border router: The IoT border router was also implemented using Rasp-

d

berry Pi 2. We installed the [63] IoT SDK to support BT-LE and 6LoWPAN in

te

the same way as the IoT devices. The connection to the data stream collector was connected by wired Ethernet.

Data stream collector: The data stream collector used was a desktop computer running on the operating system Ubuntu 16.04 LTS. The collection pro-

Ac ce p 390

gram was created by modifying the Python example in [63]. Dataset: The dataset used data to monitor the activity of the accredited

data repository [65]. Home monitoring was one of the main applications of the IoT. This data consisted of eight gas sensors, temperature sensors, and humidity

395

sensors. We used a temperature data list.

The specifications of the Raspberry Pi 2 and desktop computer are listed in

Table 6.

21

Page 21 of 37

5.2. Measured element for experiment In order to prove the efficiency of the proposed handler, we defined the

ip t

400

following four measurement factors:

cr

• Transmission time: the time at which data is transmitted to the collector. • Data compression time: The time it takes to perform additional compres-

405

us

sion, data compression for the proposed handling.

• Resource consumption: The amount of RAM and CPU usage the IoT

an

device uses to compress data, an additional task.

• Power consumption: The measure of the power consumed for data transmission.

410

M

In order to improve the performance of these four measurement factors, the transmission time after the handling application should be faster than the

d

transmission time before the handling application. The transmission time after handling should include the compression time, and the resource and power

te

consumption of the IoT device for this task should be accommodated. Since the problem to be solved in this study depends on data size, the data set was divided into 100 KB, 200 KB, 400 KB, 800 KB, and 1600 KB.

Ac ce p

415

5.3. Transmission time

Fig. 12 shows the transfer time to the collector before and after applying

the proposed compression handler. The time after handling application does not include the compression time. As seen in this figure, the transmission time

420

decreased for all data sizes. As shown in Table 7, the reduction is 56% at 100 KB, 75% at 200 KB, 62% at 400 KB, 56% at 800 KB, and 57% at 1600 KB. Thus, it is confirmed that this reduction in transmission time can help satisfy the characteristics of the data stream that need to be processed quickly. In addition, network resources can be saved [66].

22

Page 22 of 37

ip t cr us an M

Ac ce p

te

d

Figure 12: Comparison of transmission times

Table 7: Transmission time reduction rate

Data Size (KB)

Reduction Rate (%)

100

56.09

200

75.70

400

62.38

800

56.79

1600

57.21

23

Page 23 of 37

ip t cr us an

425

M

Figure 13: Compression time

5.4. Compression Time

Fig. 13 shows the time taken to compress the data stream. The larger the

d

data size, the longer the time. However, even if the data size increases, the

te

compression time within 0.5 s for the data size was required. The compression of the largest data size of 1600 KB took 0.337 s. In addition, the transmission time result of Section 5.3 was much smaller than the time before compression,

Ac ce p

430

even if the compression time was added. Therefore, this can help satisfy the characteristics of the data stream to be processed in real time by reducing the overall transmission time. 5.5. Resource Usage

435

Table 8 shows the amount of resources consumed when compressing data.

Memory and CPU usage were monitored and measured using the Linux TOP command. VIRT refers to virtual memory usage, RES refers to physical memory usage, SHR refers to shared memory usage, MEM represents the total increase in RAM usage, and CPU represents the total increase in CPU usage.

440

The results in the table show that as the size of compressed data increased, the amount of memory, CPU, and RAM used in the compression process in24

Page 24 of 37

Table 8: Memory and CPU usage for compression task

VIRT(KB)

RES(KB)

SHR(KB)

MEM(%)

CPU(%)

100

1964

328

272

0.0

200

2020

1284

1020

0.1

400

2424

1656

1020

0.2

800

3024

2156

1060

0.2

6.3

1600

4224

2972

1080

0.3

10.5

ip t

Data Size(KB)

1.0 1.0

us

cr

3.6

(3)

an

P ower Consumption(W ) = T ransmission T ime × 1.253 + Compression T ime × 1.44

creased. However, if we compare this result to the resource usage of the basic

M

processes lxpanel, sshd, and systemd that operate in the same environment, we can confirm that the amount of resources used is not large. The memory usage 445

of the three processes are as follows: lxpanel (VIRT: 94804, RES: 24796, SHR:

d

20960), sshd (VIRT: 12208, RES: 3180, SHR: 2512), and systemd (VIRT:23884, RES:3196, SHR:2684). Compared to other processes, it is evident that the com-

te

pression process consumed less memory. CPU usage increased by 10.5% for the data size of 1600 KB. However, since the compression process took only a very short time, the effect of the increase was negligible.

Ac ce p

450

5.6. Power Consumption

IoT devices are power-sensitive devices operating at low power. Therefore,

it is meaningful to reduce the power consumption of IoT devices. Fig. 14 shows the power consumption before and after applying the protocol. It seen in this

455

figure that power consumption significantly decreased. The power consumption was calculated using the following equation: We measured the power consumption of the data stream transmission and compression process using a power meter. Power consumption was 1.253 W when the data stream was transmitted, and 1.44 W when the compression pro-

460

cess was performed.

25

Page 25 of 37

ip t cr us an M

Ac ce p

te

d

Figure 14: Comparison of power consumption

Table 9: Power consumption reduction rates

Data Size (KB)

Reduction Rate (%)

100

54.77

200

75.30

400

62.04

800

56.40

1600

56.89

26

Page 26 of 37

6. Conclusion

ip t

In this paper, we proposed a handling method that reduced transmission time in a data collector and the power consumption of IoT devices that generate data streams, while maintaining the security of the encrypted data stream.

The encryption algorithm used for security considered the stream cipher and

cr

465

compressed the data using an LDPC code to overcome the differences in perfor-

us

mance between the IoT and the Internet. Using the Raspberry Pi 2, a desktop computer, and data stream collector, we implemented an IoT device that generated a data stream. Based on the data from a temperature sensor, the average transmission time to the collector was reduced by 61.63%, and the power con-

an

470

sumption of the Iot device was reduced by an average of 61.08%. The measured

M

CPU and memory usage for performing the proposed handling showed a 0.30% and 10.50% increase in memory and CPU usage, respectively, for the largest a data size of 1600 KB. The results of this study are expected to help reduce the power consumption of IoT devices within a certain range of output, and satisfy

d

475

the characteristics of data streams in order to process them quickly. Future

te

research will explore not only the output within a certain range, but also how to apply the compression to general data.

Ac ce p

We examined the data stream of the IoT (temperature, humidity, and power

480

meter), which generated a certain range of values. However, this required knowledge of the characteristics of the data and devices, which were collected in advance. In addition, since the applications of the IoT are expected to be diverse, and more diverse data will be generated in the future, the above conditions are expected to limit the applications of this study [11]. Therefore, future work will

485

focus on how to compress and decompress general data using LDPC codes. This method will be based on the belief propagation algorithm proposed in [51]; in contrast to our method, which is based on the characteristics of the device and data stream. Future studies will be able to reduce both the transmission time to the collector and the power consumption of the IoT device, while maintaining

490

the security of the encrypted data stream for various IoT devices, by making

27

Page 27 of 37

the handling method applicable to the general data stream.

ip t

Acknowledgements

This work was supported by the National Research Foundation of Korea

References

us

495

cr

(NRF) grant funded by the Korea government (MSIP) (No 2016R1A2B4011069).

[1] M. Chen, S. Mao, Y. Liu, Big data: A survey, Mobile Networks and Ap-

an

plications 19 (2) (2014) 171–209. doi:10.1007/s11036-013-0489-0. [2] C. Liu, C. Yang, X. Zhang, J. Chen, External integrity verification for outsourced big data in cloud and iot: A big picture, Future Generation Computer Systems 49 (August 2015) (2015) 58–67. doi:10.1016/j.future.

M

500

2014.08.007.

d

[3] B. Shen, Y. Liu, X. Wang, Research on data mining models for the internet

te

of things, in: Int. Conf. Image Anal. Signal Process, 2010, pp. 127–132. [4] C. Tsai, C. Lai, M. Chiang, L. Yang, Data mining for internet of things: A survey, IEEE COMMUNICATIONS SURVEYS TUTORIALS 16 (1)

Ac ce p

505

(2014) 77–79. doi:10.1109/SURV.2013.103013.00206.

[5] F. Chen, P. Deng, J. Wan, D. Zhang, A. V. Vasilakos, X. Rong, Data mining for the internet of things: Literature review and challenges, International Journal of Distributed Sensor Networks 2015 (Article ID 431047). doi:

510

10.1155/2015/431047.

[6] W. Fan, A. Bifet, Mining big data: Current status, and forecast to the future, SIGKDD Explorations 14 (2). doi:10.1145/2481244.2481246.

[7] S. Kolozali, M. Bermudez-Edo, D. Puschmann, F. Ganz, P. Barnaghi, A knowledge-based approach for real-time iot data stream annotation and 515

processing, in: 2014 IEEE International Conference on Internet of Things

28

Page 28 of 37

(iThings 2014), Green Comp uting and Communications (GreenCom2014),

ip t

and Cyber-Physical-Social Computing (CPSCom 2014), 2014, pp. 215–212. [8] E. Baccarelli, N. Cordeschi, A. Mei, M. Panella, M. Shojafar, J. Stefa,

Energy-efficient dynamic traffic offloading and reconfiguration of networked data centers for big data stream mobile computing: Review, challenges,

cr

520

and a case study, IEEE Network March/April 2016 (2016) 54–61. doi:

us

10.1109/MNET.2016.7437025.

[9] A. Zaslavsky, C. Perera, D. Georgakopoulos, Sensing as a service and

525

an

big data, in: International Conference on Advances in Cloud Computing (ACC), 2012.

[10] B. Gedik, S. Schneider, M. Hirzel, K. Wu, Elastic scaling for data

M

stream processing, IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS 25 (6) (2014) 1447–1463. doi:10.1109/TPDS.

[11] K. P. Lakshmi, C. Reddy, A survey on different trends in data streams,

te

530

d

2013.295.

in: International Conference on Networking and Information Technology

Ac ce p

(ICNIT), 2010.

[12] J. Han, Y. Chen, G. Dong, J. Pei, B. Wah, J. Wang, Y. Cai, Stream cube: An architecture for multi-dimensional analysis of data streams, Dis-

535

tributed and Parallel Databases 18 (2) (2005) 173–197. doi:10.1007/

s10619-005-3296-1.

[13] L. Tu, Y. Chen, Stream data clustering based on grid density and attraction, ACM Transactions on Knowledge Discovery from Data (TKDD) 3 (3) (2009) 1–27. doi:10.1145/1552303.1552305.

540

[14] M. PhridviRaj, C. GuruRao, Data mining past, present and future a typical survey on data streams, Procedia Technology 12 (2014) 255–263. doi:10.1016/j.protcy.2013.12.483.

29

Page 29 of 37

[15] Y. Chen, L. Tu, Density-based clustering for real-time stream data, in: 13th ACM SIGKDD international conference on Knowledge discovery and data mining, 2007. doi:10.1145/1281192.1281210.

ip t

545

[16] G. Krempl, M. Spiliopoulou, J. Stefanowski, I. liobaite, D. Brzeziski,

cr

E. Hllermeier, M. Last, V. Lemaire, T. Noack, A. Shaker, S. Sievi, Open challenges for data stream mining research, ACM SIGKDD Explorations

550

us

Newsletter 16 (1) (2014) 1–10. doi:10.1145/2674026.2674028.

[17] A. Bifet, G. de Francisci Morales, J. Read, G. Holmes, B. Pfahringer,

an

Efficient online evaluation of big data stream classifiers, in: 21th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2015, pp. 59–68. doi:10.1145/2783258.2783372.

555

M

[18] L. Golab, M. zsu, Issues in data stream management, ACM SIGMOD Record 32 (2) (2003) 5–14. doi:10.1145/776985.776986.

d

[19] B. Babcock, S. Babu, M. Datar, R. Motwani, J. Widom, Models and issues

te

in data stream systems, in: ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, 2002, pp. 1–16. doi:10.1145/543614.

Ac ce p

543615. 560

[20] X. Wu, X. Zhu, G. Wu, W. Ding, Data mining with big data, IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING 26 (1) (2014) 97–107. doi:10.1109/TKDE.2013.109.

[21] B.-K. Yasmine-Derdour, M. Fayal-khelfi, Using mobile data collectors to enhance energy efficiency a nd reliability in delay tolerant wireless sensor

565

networks, Journal of Information Processing Systems 12 (2) (2016) 275– 294.

[22] A. Pughat, V. Sharma, A review on stochastic approach for dynamic power management in wireless sensor networks, Human-centric Computing and Information Sciences 5 (4). doi:10.1186/s13673-015-0021-6.

30

Page 30 of 37

570

[23] I. S. Association, Ieee 802.3 ’standard for ethernet’ marks 30 years of inno-

ip t

vation and global market growth (2013). [24] I. S. for Information Technology, Telecommunications and information exchange between systems - local and metropolitan area networks - specific

575

cr

requirements - part 11: Wireless lan medium access control (mac) and phys-

ical layer (phy) specificatio, ieee std 802.11-2007 (revision ieee std 802.11-

us

1999) (2007).

[25] I. S. for Information technology, Telecommunications and information ex-

an

change between systems–local and metropolitan area networks–specific requirements-part 11: Wireless lan medium access control (mac) and phys580

ical layer (phy) specifications am, ieee std 802.11ad-2012 (amendment to

M

ieee std 802.11-2012, as amend. by ieee std 802.11ae-2012 ieee std 802.11aa2012) (2013).

d

[26] Z.-W. A. R. ZAD12837, Z-wave transceivers - specification of spectrum

585

te

related components (2014).

[27] I. D. S. for Low-Rate Wireless Personal Area Networks (WPANs), Ieee

Ac ce p

p802.15.4-revc/d00(revision ieee std 802.15.4-2011) (2015). [28] C. Gomez, I. Demirkol, Modeling the maximum throughput of bluetooth low energy in an error-prone link, IEEE COMMUNICATIONS LETTERS 15 (11). doi:10.1109/LCOMM.2011.092011.111314.

590

[29] C. Hornig, Rfc 894: Standard for the transmission of ip datagrams over ethernet networks (1984).

[30] J. Melorose, R. Perroy, S. Careas, Rfc 4994: Transmission of ipv6 packets over ieee 802.15.4 networks (2015). [31] J. Nieminen, T. Savolainen, M. Isomaki, Z. Shelby, Ietf draft: Transmission

595

of ipv6 packets over bluetooth low energy (2013).

31

Page 31 of 37

[32] A. Sinha, D. Lobiyal, Performance evaluation of data aggregation for

formation Sciences 3 (13). doi:10.1186/2192-1962-3-13.

ip t

cluster-based wireless sensor network, Human-centric Computing and In-

[33] V. Vujovi, M. Maksimovi, Raspberry pi as internet of things hardware: Performances and constraints, in: International Convention on Informa-

cr

600

tion and Communication Technology, Electronics and Microelectronics

us

(MIPRO), 2014.

[34] A. Technique, Powering iot devices: A novel design and analysis technique,

605

an

Journal of Convergence 7 (2016) 1–18.

[35] N. Kushalnagar, G. Montenegro, C. Schumacher, Rfc 4919: Ipv6 over lowpower wireless personal area networks (6lowpans): overview, assumptions,

M

problem statement, and goals (2007).

[36] S. Deering, Rfc 2460: Internet protocol, version 6 (ipv6) specification

610

d

(1998).

[37] S. Raza, D. Trabalza, T. Voigt, 6lowpan compressed dtls for coap, in: IEEE

te

International Conference on Distributed Computing in Sensor Systems,

Ac ce p

2012, pp. 287–289. doi:10.1109/DCOSS.2012.55. [38] D. Schonberg, K. Ramchandran, S. Pradhan, Distributed code constructions for the entire slepian-wolf rate region for arbitrarily correlated

615

sources, in: Data Compression Conference, 2004. doi:10.1109/DCC.2004. 1281474.

[39] R. Gallager, Low-density parity-check codes, IRE TRANSACTIONS ON INFORMATION THEORY 8 (1962) 21–28.

doi:10.1109/TIT.1962.

1057683.

620

[40] Wikimedia.org, Low-density parity-check code, decoding (2017). [41] D. Puthal, R. Ranjan, J. Chen, Dlsef: A dynamic key-length-based efficient real-time security verification model for big data stream, ACM Transactions on Embedded Computing Systems (TECS) 6 (2). doi:10.1145/2937755. 32

Page 32 of 37

[42] S. Raza, S. Duquennoy, T. Voigt, U. Roedig, Securing communication 625

in 6lowpan with compressed ipsec, in: International Conference on Dis-

ip t

tributed Computing in Sensor Systems, 2011. doi:10.1109/DCOSS.2011. 5982177.

cr

[43] A. Mason, Ipsec overview part two: Modes and transforms (2002).

[44] J. Melorose, R. Perroy, S. Careas, Rfc 6282: Compression format for ipv6 datagrams over ieee 802.15.4 based networks (2015).

us

630

[45] O. Lawlor, Measuring entropy: Information theory, cS 463/480 Lecture

an

(2015).

[46] O. F. Inc., Openssl command, www.openssl.org.

635

M

[47] W. Stallings, Cryptography and network security: principles and practices, pearson Education India (2006).

d

[48] B. Forouzan, D. Mukhopadhyay, Cryptography and network security (sie),

te

mcGraw-Hill Education (2011).

[49] A. Liveris, Z. Xiong, C. Georghiades, Compression of binary sources with

Ac ce p

side information at the decoder using ldpc codes, IEEE Communications 640

Letters 6 (10). doi:10.1109/LCOMM.2002.804244.

[50] G. Caire, S. Shamai, S. Verd, Noiseless data compression with low-density parity-check codes, Advances in Network Information Theory 66 (2004) 263–284.

[51] M. Johnson, P. Ishwar, V. Prabhakaran, D. Schonberg, K. Ramchandran,

645

On compressing encrypted data, IEEE Transactions on Signal Processing 52 (10) (2004) 2992–3006. doi:10.1109/TSP.2004.833860.

[52] P. Kishore, N. Nagendra, K. Reddy, V. Murthy, Smoothing and optimal compression of encrypted gray scale images, International Journal of Engineering Research and Applications (IJERA) 2 (3) (2012) 23–28.

33

Page 33 of 37

650

[53] R. Lazzeretti, M. Barni, Lossless compression of encrypted grey-level and color images, in: European Signal Processing Conference (EUSIPCO),

ip t

2008.

[54] P. Carbone, S. Ewen, S. Haridi, A. Katsifodimos, V. Markl, K. Tzoumas,

655

cr

Apache flink: Unified stream and batch processing in a single engine, in: IEEE International Conference on Data Engineering (ICDE), 2015.

us

[55] M. Jang, H. Lee, K. Schwan, K. Bhardwaj, Soul: An edge-cloud system for mobile applications in a sensor-rich world, in: IEEE/ACM Symposium on

an

Edge Computing, 2016.

[56] D. Wang, T. Abdelzaher, B. Priyantha, J. Liu, F. Zhao, Energy-optimal 660

batching periods for asynchronous multistage data processing on sensor

M

nodes: Foundations and an mplatform case study, in: IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2010.

d

[57] X. Ning, C. Cassandras, Message batching in wireless sensor networksa per-

665

2010.

te

turbation analysis approach, in: IEEE Conference on Decision and Control,

Ac ce p

[58] M. Hell, T. Johansson, W. Meier, Grain: a stream cipher for constrained environments, International Journal of Wireless and Mobile Computing 2 (1) (2007) 86–93.

[59] C. Canniere, B. Preneel, Trivium specifications, eCRYPT Stream Cipher

670

Project (2005).

[60] S. Babbage, M. Dodd, The stream cipher mickey 2.0, eCRYPT Stream Cipher Project (2006).

[61] X. Fan, K. Mandal, G. Gong, Wg-8: A lightweight stream cipher for resource-constrained smart devices, in: International Conference on Het675

erogeneous Networking for Quality, Reliability, Security and Robustness, 2013.

34

Page 34 of 37

[62] Sht75 datasheet, http://legacy.caricoos.org.

low-energy/nRF5-SDK-for-IoT. [64] R.

Neal,

Software

for

low

density

parity

http//radfordneal.github.io/LDPC-Codes (2012).

check

codes,

cr

680

ip t

[63] N. Semiconductor, nrf5 sdk for iot, https://www.nordicsemi.com/eng/Products/Bluetooth-

us

[65] R. Huerta, T. Mosqueiro, J. Fonollosa, N. Rulkov, I. Rodriguez-Lujan, Online decorrelation of humidity and temperature in chemical sensors for continuous monitoring, chemometrics and Intelligent Laboratory Systems (2016).

an

685

[66] K. Kambatla, G. Kollias, V. Kumar, A. Grama, Trends in big data ana-

M

lytics, J. Parallel Distrib. Comput. 74 (2014) 2561–2573. doi:10.1016/j.

Ac ce p

te

d

jpdc.2014.01.003.

35

Page 35 of 37

*Highlights (for review)

Highlights for Reviewers Article entitled: Effective Handling of Secure Data Stream in IoT  In order to improve the usability of encrypted data streams in the IoT environment, a compression method using low-density parity check (LDPC) codes is proposed.

ip t

 This study, which investigates the payload compression of packets instead of the header compression of packets, is applicable even if the payload is encrypted.

Ac ce pt e

d

M

an

us

cr

 As a result of this research, it is expected that the transmission time, as well as the power consumption of IoT devices, can be reduced while securing data streams generated by IoT devices.

Page 36 of 37

*Graphical abstract (for review)

Graphical abstract for Reviewers

ip t

Article entitled: Effective Handling of Secure Data Stream in IoT

 

an

us

cr

Fig. 8. Data flow between IoT device and data stream collector

M

 

Ac ce pt e

d

Fig. 9. Data transmission mechanism in IoT end device

 

Fig. 10. Example of data transmission mechanism in IoT Border Router

  Fig. 11. Example of receiving data in data stream collector

Page 37 of 37