A survey of secure middleware for the Internet of Things

The rapid growth of small Internet connected devices, known as the Internet of Things (IoT), is creating a new set of challenges to create secure, private infrastructures. This paper reviews the current literature on the challenges and approaches to security and privacy in the Internet of Things, with a strong focus on how these aspects are handled in IoT middleware. We focus on IoT middleware because many systems are built from existing middleware and these inherit the underlying security properties of the middleware framework. The paper is composed of three main sections. Firstly, we propose a matrix of security and privacy threats for IoT. This matrix is used as the basis of a widespread literature review aimed at identifying requirements on IoT platforms and middleware. Secondly, we present a structured literature review of the available middleware and how security is handled in these middleware approaches. We utilise the requirements from the first phase to evaluate. Finally, we draw a set of conclusions and identify further work in this area. ABSTRACT 5 The rapid growth of small Internet connected devices, known as the Internet of Things (IoT), is creating a new set of challenges to create secure, private infrastructures. This paper reviews the current literature on the challenges and approaches to security and privacy in the Internet of Things, with a strong focus on how these aspects are handled in IoT middleware. We focus on IoT middleware because many systems are built from existing middleware and these inherit the underlying security properties of the middleware framework. The paper is composed of three main sections. Firstly, we propose a matrix of security and privacy threats for IoT. This matrix is used as the basis of a widespread literature review aimed at identifying requirements on IoT platforms and middleware. Secondly, we present a structured literature review of the available middleware and how security is handled in these middleware approaches. We utilise the requirements from the ﬁrst phase to evaluate. Finally, we draw a set of conclusions and identify further work in this area.


17
The Internet of Things (IoT) was originally coined as a phrase by Kevin Ashton in 1990 (Ashton, 2009), 18 with reference to "taggable" items that used Radio Frequency Identification Devices (RFID) to become  There are a number of definitions of IoT. For the purposes of this work, we will define it in the 25 following way. An IoT device is a system that contains either sensors or actuators or both and supports 26 connection to the Internet either directly or via some intermediary. A sensor is a subcomponent of a 27 device that measures some part of the world, allowing the device to update Internet and Cloud systems 28 with this information. A sensor may be as simple as a button (e.g. Amazon Dash Button), but more 29 complex sensors widely deployed include weather sensors (barometers, anemometers, thermometers),   Table 1 shows the matrix we will use for evaluating security challenges. In each cell we summarise 103 (XML) parsing with binary alternatives. The processing time on a constrained device is more than a 126 magnitude slower using XML, and that the heap memory used by XML is more than 10Kb greater Security needs a process known as XML Canonicalisation (XML C14N). XML Canonicalisation is 131 a costly process in both time and memory. (Binna, 2008) shows that the memory usage is more 132 than 10× the size of the message in memory (and XML messages are already large for IoT devices). 133 We looked for any work on implementing WS-Security on Arduino IoT devices may use much lower power, lower bandwidth networks than existing Internet systems.

139
Cellular networks often have much higher latency and more "dropouts" than fixed networks (Chakra- While many of the existing challenges apply here, there are some aspects that are exacerbated 155 by the IoT for the server-side or cloud infrastructure. These include: the often highly personal 156 nature of data that is being collected and the requirement to manage privacy; the need to provide break it in many ways. For example, there are devices that will copy the memory from flash memory 163 into another system (known as NAND Mirroring). Code that has been secured can often be broken with 164 Scanning Electron Microscopes. Skorobogatov from Cambridge University has written a comprehensive 165 study (Skorobogatov, 2005) of many semi-invasive attacks that can be done on hardware. Another 166 common attack is called a side-channel attack (Yan, 2008;Lomne et al., 2011) where the power usage or 167 other indirect information from the device can be used to steal information. This means that it is very 168 difficult to protect secrets on a device from a committed attacker. 169 A specific outcome of this is that designers should not rely on obscurity to protect devices. A clear security of a device to protect a key that is used across many devices is a significant error. For example, 176 the encryption keys used in DVD players and XBoX gaming consoles (Steil, 2005) were broken meaning 177 that all devices were susceptible to attack. networks is proposed. However, this model assumes that each device has a secure, shared key (called 186 kIR) already deployed and managed into every device. Quantum Computers are as yet ineffective, there is some concern that maybe the problem with ECC is 235 actually based on classical computing, but this is all speculation. One thing that we do know is that ECC 236 is much easier to do on IoT devices, and especially on low-power, 8-or 16-bit systems. Therefore this 237 warning is worrying for IoT developers.

238
Another key challenge in confidentiality is the complexity of the most commonly used encryption 239 protocols. The standard Transport Layer Security (TLS) (Dierks, 2008) protocol can be configured to use 240 ECC, but even in this case the handshake process requires a number of message flows and is sub-optimal 241 for small devices as documented in (Koschuch et al., 2010). ( during key exchange to intercept all future communications (Ryan, 2013). One significant challenge for 267 IoT is the length of time it takes for vulnerabilities to be addressed when hardware assets are involved.

268
2 The same search was repeated on the 10th Feb 2017. The number of repositories for "Arduino" and "Encryption" had grown to 21, while for "Arduino" and "HTTP" had reached 941, demonstrating that support for encryption is growing slowly.
3 https://threatpost.com/nsas-divorce-from-ecc-causing-crypto-hand-wringing/115150/ we look at the access control of IoT data and systems in the cloud and on the server-side.

297
A second concern that is exacerbated by the Internet of Things are concerns with correlation of data 298 and metadata, especially around de-anonymisation. In Narayanan and Shmatikov (2008) it was shown 299 that anonymous metadata could be de-anonymized by correlating it with other publicly available social 300 metadata. This is a significant concern with IoT data. This is also closely related to the fingerprinting 301 of sensors within devices as discussed in cell A1. An important model for addressing these issues in the 302 cloud are systems that filter, summarise and use stream-processing technologies to the data coming from 303 IoT devices before this data is more widely published. For example, if we only publish a summarised co-304 ordinate rather than the raw accelerometer data we can potentially avoid fingerprinting de-anonymisation 305 attacks.

306
In addition, an important concern has been raised in the recent past with the details of the government  The first concern is the revelations that many of the encryption and security systems have had deliberate 311 backdoor attacks added to them so as to make them less secure (Larson et al., 2013). The second concern 312 is the revelation that many providers of cloud hosting systems have been forced to hand over encryption 313 keys to the security services (Levinson, 2014). The third major concern is the revelations on the extent to 314 which metadata is utilised by the security services to build up a detailed picture of individual users (Ball,315 2013).

316
The implications of these three concerns when considered in the light of the Internet of Things is clear: 317 a significantly deeper and larger amount of data and metadata will be available to security services and to 318 other attackers who can utilize the same weaknesses that the security services compromise.  remote system to ensure that the firmware is unmodified and therefore the data coming from the device 330 is accurate. Secondly, attestation is used in conjunction with hardware-based secure storage (Hardware 331 Security Managers, as described in (Deitel, 1984)) to ensure that authentication keys are not misused. The 332 model is as follows.

333
In order to preserve the security of authentication keys in a machine where human interaction is 334 involved, the user is required to authenticate. Often the keys are themselves encrypted using the human's 335 password or a derivative of the identification parameters. However, in an unattended system, there is no 336 human interaction. Therefore the authentication keys need to be protected in some other way. Encryption 337 on its own is no help, because the encryption key is then needed and this becomes a circular problem.

338
The solution to this is to store the authentication key in a dedicated hardware storage. However, if the 339 firmware of the device is modified, then the modified firmware can read the authentication key, and offer 340 it to a hacker or misuse it directly. The solution to this is for an attestation process to validate the firmware 341 is unmodified before allowing the keys to be used. Then the keys must also be encrypted before sending 342 them over any network. whilst there is considerable discussion of using these techniques with IoT, during our literature review we 348 could not find evidence of any real-world devices apart from those based on mobile-phone platforms (e.g.

349
phones and tablets) that implemented trusted computing and attestation. The biggest concern in this area is the lack of common concepts and approaches for device identity.

363
Integrity relies on identity -without knowing who or what created data, we cannot trust that data. We 364 address this in cells A4, B4 and C4. One specific aspect of trust in cloud for IoT scenarios is where the 365 device lacks the power to participate in trust and must therefore trust the cloud server. One key example 366 of this is where a blockchain (Nakamoto, 2008) is being used in respect of IoT devices. Blockchains are 367 cryptographically secure ledgers that typically require a significant amount of memory, disk space and 368 processor power to work (Bitcoin, 2017). These requirements go beyond typical IoT devices and even 369 beyond more powerful systems in IoT networks such as hubs. One option to address this is to use remote 370 attestation, but as yet there is little or no work in this space.  There are clearly many aspects of this that are the same as existing network challenges. However, there are 384 some issues that particularly affect IoT. In particular, there are a number of attacks on local radio networks

406
A key issue here is the initial registration of the device. A major issue with hardware is when the 407 same credential, key, or password is stored on many devices. Devices are susceptible to hardware attacks 408 (as discussed above) and the result is that the loss of a single device may compromise many or all devices.

409
In order to prevent this, devices must either be pre-programmed with unique identifiers and credentials  Unlike browsers or laptops where a human has the opportunity to provide authentication information such 418 as a userid and password, IoT devices normally run unattended and need to be able to power-cycle and 419 reboot without human interaction. This means that any identifier for the device needs to be stored in the 420 program memory (usually SRAM), ROM or storage of the device. This brings two distinct challenges:

421
• The device may validly authenticate, but the program code may have been changed, and therefore it 422 may behave incorrectly.

423
• Another device may steal the authentication identifier and may spoof the device.  where trust is based on reputation, which is defined as a probability that an agent is trustworthy. In fact, 434 reputation is often seen as one measure by which trust or distrust can be built based on good or bad past

452
This draft does discuss both the bootstrapping of identity and the issues of privacy-aware identification.

453
One key aspect is that of bootstrapping a secure conversation between the IoT device and other systems,    Manuscript to be reviewed

Computer Science
This approach also addresses Cell A5. While this approach has a lot of capabilities and power, there is a 532 slow uptake of UMA in real-world services and even less in IoT. We propose that the complexity of this 533 approach is the inhibitor to widespread adoption. 534 (Winter, 2012) argues that contextual approaches must be taken to ensure privacy with the IoT. Many 535 modern security systems use context and reputation to establish trust and to prevent data leaks. Context-536 based security (Montanari et al., 2005) defines this approach which is now implemented by major Web 537 systems including Google and Facebook. This is closely related to reputation-based models which we 538 discussed above. The biggest challenge in the non-repudiation network with IoT devices is the challenge of using attestation 541 for small devices. Attestation is discussed in detail in Cell A2. Without attestation, we cannot trust that 542 the device system has not been modified and therefore it is not possible to trust any non-repudiation data 543 from the device. Manuscript to be reviewed

Computer Science
User Sphere: Device Iden*ty Device Ownership and Registra*on Device Updates Joint Sphere:

Consent Management Policies
Recipient Sphere:

Consent Tracking Policy Enforcement
Data Revoca*on

596
Recall that the Joint Sphere is the parts of the system where the user has some form of control over their 597 data and systems, but the provider also shares control. For example, a health-monitoring device may 598 upload data to an Internet-based system and then may offer users controls on how they share data. A

Recipient Sphere 612
The Recipient Sphere is the area where the user's data is now out of their control. Ultimately, the user 613 must rely on legislation or legal contracts in order to maintain control of this data. Of course, it is hard to 614 police this recipient sphere: it is possible that the third-party website will share data following policies. In  In reviewing these areas, we identified a list of security properties and capabilities that are important 627 for the security and privacy of IoT. We will use this list in the second part of this paper as columns in a 628 new table where we evaluate a set of middleware on their provision of these capabilities.

630
The requirement to provide integrity and confidentiality is an important aspect in any network and 631 as discussed in cells A1-B2 there are a number of challenges in this space for IoT.

633
Maintaining access control to data that is personal or can be used to extract personal data is a 634 key aspect of privacy. In addition, it is of prime importance with actuators that we do not allow 635 unauthorised access to control aspects of our world. Manuscript to be reviewed

654
In order to guard against de-anonymisation and other leakages of personally identifiable information, 655 anonymous identities/pseudonyms can offer individuals clearer consent as to when they wish to 656 actively share their identity, as discussed in A4.

658
Attestation is an important technique to prevent tampering with physical devices (as discussed in 659 cells in column A) and hence issues with integrity of data as well as confidentiality in IoT.

661
The need to prevent de-anonymisation is a clear driver for systems to provide summarisation and 662 filtering technologies such as stream processing. IoT privacy as discussed above.

669
While we consider PBD an important aspect, we argue that it is a meta-requirement: it effectively 670 covers the need to implement the major security and privacy requirements from the initial design outwards.

671
There are of course many other aspects to IoT security and privacy as we have demonstrated in the 672 matrix table and accompanying description of each cell. However, these specific aspects form an effective 673 set of criteria by which to analyse different systems, as we show below in the next section.

675
Middleware has been defined as computer software that has an intermediary function between the various 676 applications of a computer and its operating system (Hanks, 1986). In our case, we are interested in IoT middleware that provides a simple analysis of whether the surveyed systems have any support for 685 security or privacy, but does not address detailed requirements.

686
It is clear then, that a detailed evaluation of security in IoT middleware is a useful contribution to the 687 literature. We therefore identified a set of middleware systems to study. considered this paper to be the definition of a standard protocol and therefore we excluded it.

695
Our search strategy was to use a search for the terms ("IoT" OR "Internet of Things") AND "Mid- Manuscript to be reviewed

Computer Science
We then manually reviewed the abstracts of the 213 papers to identify a list of functioning middleware 703 systems as opposed to papers that describe other aspects of IoT without describing a middleware system.

704
This produced a list of 55 middleware systems.

705
In our study, we looked for the security and privacy requirements listed in section 4. We also identified 706 if the middleware had a clearly defined security model and/or security implementation. Out of the 54 707 middleware systems identified, we found that 35 had no published discussion or architecture for security, 708 or such a minimal description that we were not able to identify any support for the selected security 709 requirements. We label these as non-secured systems. IoT platforms to interoperate and federate. There is no plan for security presented. We identified 19 middleware systems that implement or describe sufficient security architecture that we 798 could evaluate them against the requirements that were identified in section 4. We describe these systems 799 as secured. In addition to the requirements identified above, we also identified whether the systems had 800 explicit support or adaptation for IoT specific protocols: MQTT, CoAP, DDS, Bluetooth or Zigbee. As 801 discussed above, in section 2, these protocols have been specifically designed for low-power devices. We 802 label this requirement REQ7.  IoT device middleware. A more detailed exposition is given in (Kliem, 2015). The approach supports 812 OAuth2.0 to provide tokens to devices. It also supports encryption and access control. There is no support 813 for summarisation, filtering, or consent-based access control described in the publications.

855
The security model is described in some detail in the LinkSmart documentation (Linksmart, 2015 The IoT Management Platform (IoT-MP) is a middleware system described in (Elkhodr et al., 2016).

879
IoT-MP offers a security module that implements attribute-based access control (ABAC) against systems.    does not address any edge computing approaches or filtering/summarisation of IoT data. However, the 951 overall approach of using ontologies and basing policies on those ontologies is very powerful.  The idea of the Personal Zone may have significant issues however, when a single device is used by 964 many different people (for example, the in-car system in a taxi as opposed to a personal vehicle). These 965 issues are not addressed in Webinos, though they are called out in the lessons learnt.

967
The system pushes XACML policies out to devices to limit the spread of personal and contextual data.

968
Webinos addresses the issue of software modification using an attestation API, which can report 969 whether the software running is the correct level. This requires the device to be utilising Trusted Platform Manuscript to be reviewed

Computer Science
Module (TPM) hardware that can return attestation data.

971
Webinos also addresses the issue of using secure storage on devices where the device has such storage.

972
While the Webinos project does address many of the privacy concerns of users through the use of the 973 Personal Zone Hub, there is clearly further work that could be done. In particular the ability for users to 974 define what data they share with other users or other systems using a protocol such as OAuth2 (Hammer-975 Lahav and Hardt, 2011), and the ability to install filters or other anonymising or data reduction aggregators 976 into the PZH are lacking. One other aspect of Webinos that is worth drawing attention to is the reliance 977 on a certain size of device: the PZP that is needed on the device is based on the node.js framework and 978 therefore the device needs to be of a certain size (e.g. a 32-bit processor running a Linux derivative or 979 similar) to participate in Webinos. network. The ability to calculate, summarise and/or filter data from the edge network before sharing it is 996 also not discussed except in very granular terms (e.g. some data are available, other data are not). In reviewing both the security and privacy challenges of the wider IoT and a structured review of more 1007 than fifty middleware platforms, we have identified some key categories that can be applied across these 1008 areas.

1009
Firstly, we identified the significant proportion of the systems that did not address security, left it for 1010 further work, or did not describe the security approach in any meaningful detail. There were other systems 1011 (such as UBIWARE and NAPS) that offer theoretical models but did not demonstrate any real-world 1012 implementation or concrete approach.

1013
The next clear category are those middlewares that apply the SOAP/Web Services model of security.

1014
This includes SOCRADES, SIRENA, and Hydra/Linksmart. As we have discussed in the previous . XMPP also has the complexity of XML, but avoids the major performance 1019 overheads by using TLS instead of XML Encryption and XML Security. In addition, recent work on 1020 XMPP using EXI makes this approach more effective for IoT.

1021
This finally leaves a few unique approaches, each of which brings their own unique benefits.

Manuscript to be reviewed
Computer Science