A survey of secure middleware for the Internet of Things

A1: Device confidentiality

Hardware devices have their own challenges for security. There are systems that can provide tamper-proofing and try to minimise attacks, but if an attacker has direct access to the hardware, they can often break it in many ways. For example, there are devices that will copy the memory from flash memory into another system (known as NAND Mirroring). Code that has been secured can often be broken with Scanning Electron Microscopes. Skorobogatov from Cambridge University has written a comprehensive study (Skorobogatov, 2005) of many semi-invasive attacks that can be done on hardware. Another common attack is called a side-channel attack (Yan, 2008; Lomne et al., 2011)where the power usage or other indirect information from the device can be used to steal information. This means that it is very difficult to protect secrets on a device from a committed attacker.

A specific outcome of this is that designers should not rely on obscurity to protect devices. A clear example of this was the Mifare card used as the London Oyster card and for many other authentication and smart-card applications. The designers created their own cryptographic approach and encryption algorithms. Security researchers used a number of techniques to break the obscurity, decode the algorithm, find flaws in it and create a hack that allowed free transport in London as well as breaking the security on a number of military installations and nuclear power plants (Garcia et al., 2008). Similarly, relying on the security of a device to protect a key that is used across many devices is a significant error. For example, the encryption keys used in DVD players and XBoX gaming consoles (Steil, 2005) were broken meaning that all devices were susceptible to attack.

A related issue to confidentiality of the data on the device is the challenges inherent in updating devices and pushing keys out to devices. The use of Public Key Infrastructure (PKI) requires devices to be updated as certificates expire. The complexity of performing updates on IoT devices is harder, especially in smaller devices where there is no user interface. For example, some devices need to be connected to a laptop in order to perform updates. Others need to be taken to a dealership or vendor. The distribution and maintenance of certificates and public-keys onto embedded devices is complex (Watro et al., 2004). In Park & Kang (2015) a novel approach to supporting mutual authentication in IoT networks is proposed. However, this model assumes that each device has a secure, shared key (called kIR) already deployed and managed into every device. As discussed above, ensuring this key is not compromised is a challenge, as the authors admit: “However, further research is required to realize the secure sharing of kIR.”

In addition, sensor networks may be connected intermittently to the network resulting in limited or no access to the Certificate Authority (CA). To address this, the use of threshold cryptographic systems that do not depend on a single central CA has been proposed (Yi & Kravets, 2002), but this technology is not widely adopted: in any given environment this would require many heterogeneous Things to support the same threshold cryptographic approach. This requires human intervention and validation, and in many cases this is another area where security falls down. For example, many situations exist where security flaws have been fixed but because devices are in homes, or remote locations, or seen as appliances rather than computing devices, updates are not installed (Hill, 2013). The Misfortune Cookie (Point, 2014) demonstrates that even when security fixes are available, some manufacturers do not make them available to customers and continue to ship insecure systems. It is clear from the number of publicised attacks (McDaniel & McLaughlin, 2009; Khurana et al., 2010; Hill, 2013) that many device designers have not adjusted to the challenges of designing devices that will be connected either directly or indirectly to the Internet.

A further security challenge for confidentiality and hardware is the fingerprinting of sensors or data from sensors. In Bojinov et al. (2014) it has been shown that microphones, accelerometers and other sensors within devices have unique “fingerprints” that can uniquely identify devices. Effectively there are small random differences in the physical devices that appear during manufacturing that can be identified and used to recognise individual devices across multiple interactions.

B1: Network confidentiality

The confidentiality of data on the network is usually protected by encryption of the data. There are a number of challenges with using encryption in small devices. Performing public key encryption on 8-bit microcontrollers has been enhanced by the use of Elliptic Curve Cryptography (ECC) (Koblitz, 1987; Miller, 1986). ECC reduces the time and power requirements for the same level of encryption as an equivalent Rivest, Shamir, and Adleman public key cryptography (RSA) public-key encryption (Rivest, Shamir & Adleman, 1978) by an order of magnitude (Gura et al., 2004; Sethi, 2012; Sethi, Arkko & Keranen, 2012): RSA encryption on constrained 8-bit microcontrollers may take minutes to complete, whereas similar ECC-based cryptography completes in seconds. However, despite the fact that ECC enables 8-bit microcontrollers to participate in public-key encryption systems, in many cases it is not used. We can speculate as to why this is: firstly, as evidenced by Sethi, Arkko & Keranen (2012), the encryption algorithms consume a large proportion of the available ROM on small controllers. Secondly, there is a lack of standard open source software. For example, a search that we carried out (on the 21st April 2015) of the popular open source site Github for the words “Arduino” and “Encryption” revealed 10 repositories compared to “Arduino” and “HTTP” which revealed 467 repositories. These 10 repositories were not limited to network level encryption. However, recently an open source library for AES on Arduino (Landman, 2015) has made the it more effective to use cryptography on Atmel-based hardware.¹

While ECC is making it possible for low-power devices to be more efficient in performing cryptography operations, in 2015 the NSA made an unprecedented warning against ECC (https://threatpost.com/nsas-divorce-from-ecc-causing-crypto-hand-wringing/115150/). We don’t yet know why, as of the time of writing. There are differing theories. One known issue with both Prime Numbers and Elliptic Curves is Quantum Computing. In Quantum computers, instead of each bit being 0 or 1, each qubit allows a superposition of both 0 and 1, allowing Quantum computers to solve problems that are very slow for classical computers in a fraction of the time. At the moment general purpose Quantum computers are very simple and confined to laboratories, but they are increasing in power and reliability. In 1994, Peter Shor identified an algorithm for Quantum Computers (Shor, 1999) that performs prime factorization in polynomial time, which effectively means that most existing Public Key Cryptography (PKC) will be broken once sufficiently powerful Quantum computers come online. Given that most Quantum Computers are as yet ineffective, there is some concern that maybe the problem with ECC is actually based on classical computing, but this is all speculation. One thing that we do know is that ECC is much easier to do on IoT devices, and especially on low-power, 8- or 16-bit systems. Therefore this warning is worrying for IoT developers.

Another key challenge in confidentiality is the complexity of the most commonly used encryption protocols. The standard Transport Layer Security (TLS) (Dierks, 2008) protocol can be configured to use ECC, but even in this case the handshake process requires a number of message flows and is sub-optimal for small devices as documented in Koschuch, Hudler & Krüger (2010). Perelman & Ersue (2012) has argued that using TLS with Pre Shared Key (PSK) improves the handshake. PSK effectively allows TLS to use traditional symmetric cryptography instead of Public Key (assymetric) cryptography. However, they fail to discuss in any detail the significant challenges with using PSK with IoT devices: the fact that either individual symmetric keys need to be deployed onto each device during the device manufacturing process, or the same key re-used. In this case there is a serious security risk that a single device will be broken and thus the key will be available.

Some IoT devices use User Datagram Protocol (UDP) instead of the more commonly used Transport Control Protocol (TCP). Both protocols are supported on the Internet. UDP is unreliable, and is typically better suited to local communications on trusted networks. It is more commonly used between IoT devices and gateways rather than directly over the Internet, although, like all generalisations there are exceptions to this rule. TLS only works with TCP, and there is an alternative protocol for UDP. Datagram Transport Layer Security (DTLS) (Rescorla & Modadugu, 2006) provides a mapping of TLS to UDP networks, by adding retransmission and sequencing which are assumed by TLS. While the combination of DTLS and UDP is lighter-weight than TLS and TCP, there is still a reasonably large RAM and ROM size required for this (Keoh, Kumar & Garcia-Morchon, 2013), and this requires that messages be sent over UDP which has significant issues with firewalls and home routers, making it a less effective protocol for IoT applications (Audet & Jennings, 2007). There is ongoing work at the IETF to produce an effective profile of both TLS and DTLS for the IoT (Tschofenig & Fossati, 2016).

A significant area of challenge for network confidentiality in IoT is the emergence of new radio protocols for networking. Previously there were equivalent challenges with Wifi networks as protocols such as Wired Equivalency Privacy (WEP) were broken (Cam-Winget et al., 2003), and there are new attacks on protocols such as Bluetooth Low Energy (BLE) (also known as Bluetooth 4.0). For example, while BLE utilises Advanced Encryption Standard (AES) encryption which has a known security profile, a new key exchange protocol was created, which turns out to be flawed, allowing any attacker present during key exchange to intercept all future communications (Ryan, 2013). One significant challenge for IoT is the length of time it takes for vulnerabilities to be addressed when hardware assets are involved. While the BLE key exchange issues are addressed in the latest revision of BLE, we can expect it to take a very long time for the devices that encode the flawed version in hardware to be replaced, due to the very large number of devices and the lack of updates for many devices. By analogy, many years after the WEP issues were uncovered, in 2011 a study showed that 25% of wifi networks were still at risk (Botezatu, 2011).

Even without concerning the confidentiality of the data, there is one further confidentiality issue around IoT devices in the network and that is confidentiality of the metadata. Many IoT systems rely on radio transmission and in many cases they can be fingerprinted or identified by the radio signature. For example, Bluetooth and Wifi systems use unique identifiers called MAC address (Media Access Control). These can be identified by scanning, and there have been a number of systems deployed to do that, including in airports and in cities (Vincent, 2013). These systems effectively can follow users geographically around. If the user then connects to a system, that fingerprint can be associated with the user and the previously collected location information can be correlated with that user. In a similar attack, security researchers recently found (Schneier, 2008) that they could fingerprint cars based on transmissions from tyre pressure monitors, and in addition that they could drive behind a car and from up to 40 feet away they could signal to the driver that the tyre pressure was dangerously low when in fact it wasn’t. Such an attack could easily be used to get a driver to stop and leave their car.

In (Radomirovic, 2010) a theoretical model of traceability of IoT devices and particularly Radio Frequency Identification Device (RFID) systems is proposed in order to prevent unauthorised data being accessible. A protocol that preserves the concept of untraceability is proposed.

Many of the same references and issues apply to section B2 where we look at the use of digital signatures with low power devices.

C1: Cloud confidentiality

In the main, the issues around Cloud confidentiality are the same as the issues in non-IoT systems. There are however, some key concerns over privacy that are unique to the Internet of Things. For example, the company Fitbit (Fitbit, 2015) made data about users sexual activity available and easily searchable online (Zee, 2011) by default. There are social and policy issues regarding the ownership of data created by IoT devices (Rendle, 2014; Murphy, 2014). We address these issues in more detail in cell C5 where we look at the access control of IoT data and systems in the cloud and on the server-side.

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

In addition, an important concern has been raised in the recent past with the details of the government sponsored attacks from the US National Security Agency (NSA) and UK Government Communications Headquarters (GCHQ) that have been revealed by Edward Snowden (Card, 2015). These bring up three specific concerns on IoT privacy and confidentiality.

The first concern is the revelations that many of the encryption and security systems have had deliberate backdoor attacks added to them so as to make them less secure (Larson, Perlroth & Shane, 2013). The second concern is the revelation that many providers of cloud hosting systems have been forced to hand over encryption keys to the securityservices (Levinson, 2014). The third major concern is the revelations on the extent to which metadata is utilised by the security services to build up a detailed picture of individual users (Ball, 2013).

The implications of these three concerns when considered in the light of the Internet of Things is clear: a significantly deeper and larger amount of data and metadata will be available to security services and to other attackers who can utilize the same weaknesses that the security services compromise.

A2: Integrity & hardware/device

The concept of integrity refers to maintaining the accuracy and consistency of data. In this cell of the matrix, the challenges are in maintaining the device’s code and stored data so that it can be trusted over the lifecycle of that device. In particular the integrity of the code is vital if we are to trust the data that comes from the device or the data that is sent to the device. The challenges here are viruses, firmware attacks and specific manipulation of hardware. For example, Goodin (2013) describes a worm attack on router and IoT firmware, where each compromised system then compromises further systems, leaving behind a slew of untrustworthy systems.

The traditional solution to such problems is attestation (Sadeghi & Stüble, 2004; Brickell, Camenisch & Chen, 2004; Seshadri et al., 2004). Attestation is important in two ways. Firstly, attestation can be used by a remote system to ensure that the firmware is unmodified and therefore the data coming from the device is accurate. Secondly, attestation is used in conjunction with hardware-based secure storage (Hardware Security Managers, as described in Deitel (1984)) to ensure that authentication keys are not misused. The model is as follows.

In order to preserve the security of authentication keys in a machine where human interaction is involved, the user is required to authenticate. Often the keys are themselves encrypted using the human’s password or a derivative of the identification parameters. However, in an unattended system, there is no human interaction. Therefore the authentication keys need to be protected in some other way. Encryption on its own is no help, because the encryption key is then needed and this becomes a circular problem. The solution to this is to store the authentication key in a dedicated hardware storage. However, if the firmware of the device is modified, then the modified firmware can read the authentication key, and offer it to a hacker or misuse it directly. The solution to this is for an attestation process to validate the firmware is unmodified before allowing the keys to be used. Then the keys must also be encrypted before sending them over any network.

These attestation models are promoted by groups such the Trusted Computing Group (TCG, 2015), and Samsung Knox (Samsung, 2015). These rely on specialized hardware chips such as the Atmel AT97SC3204 (Atmel, 2015) which implement the concept of a Trusted Platform Module (TPM) (Morris, 2011). There is research into running these for Smart Grid devices (Paverd & Martin, 2012). However, whilst there is considerable discussion of using these techniques with IoT, during our literature review we could not find evidence of any real-world devices apart from those based on mobile-phone platforms (e.g., phones and tablets) that implemented trusted computing and attestation.

B2: Network integrity

Maintaining integrity over a network is managed as part of the public-key encryption models by the use of digital signatures. The challenges for IoT are exactly those we already identified in cell B1 above where we described the challenges of using encryption from low-power IoT devices.

However, there is a further concern with IoT known as the Sybil Attack (Douceur, 2002). A Sybil attack² is where a peer-to-peer network is taken over when an attacker creates a sufficiently large number of fake identities to persuade the real systems of false data. A Sybil attack may be carried out by introducing new IoT devices into a locality or by suborning existing devices. For example, it is expected that autonomous cars may need to form local ephemeral peer-to-peer networks based on the geography of the road system. A significant threat could be provided if a Sybil attack provided those cars with incorrect data about traffic flows.

C2: Cloud integrity

The biggest concern in this area is the lack of common concepts and approaches for device identity. Integrity relies on identity—without knowing who or what created data, we cannot trust that data. We address this in A4, B4 and C4. One specific aspect of trust in cloud for IoT scenarios is where the device lacks the power to participate in trust and must therefore trust the cloud server. One key example of this is where a blockchain (Nakamoto, 2012) is being used in respect of IoT devices. Blockchains are cryptographically secure ledgers that typically require a significant amount of memory, disk space and processor power to work (Bitcoin, 2017). These requirements go beyond typical IoT devices and even beyond more powerful systems in IoT networks such as hubs. One option to address this is to use remote attestation, but as yet there is little or no work in this space.

A3: Hardware availability

One of the significant models used by attackers is to challenge the availability of a system, usually through a Denial of Service (Dos) or Distributed Denial of Service (DDos) attack. DoS attacks and availability attacks are used in several ways by attackers. Firstly, there may be some pure malicious or destructive urge (e.g., revenge, commercial harm, share price manipulation) in bringing down a system. Secondly, availability attacks are often used as a pre-cursor to an authentication or spoofing attack.

IoT devices have some different attack vectors for availability attacks. These include resource consumption attacks (overloading restricted devices), physical attacks on devices. A simple availability attack on an IoT device might be to force it to use more power (e.g., by initiating multiple key exchanges over Bluetooth) and thereby draining the battery. Another even more obvious availability challenge would be to simply physically destroy a device if it is left in a public or unprotected area.

B3: Network availability

There are clearly many aspects of this that are the same as existing network challenges. However, there are some issues that particularly affect IoT. In particular, there are a number of attacks on local radio networks that are possible. Many IoT devices use radio networking (Bluetooth, Wifi, 3G, General Packet Radio Service (GPRS), LoRa and others) and these can be susceptible to radio jamming. In Mpitziopoulos et al. (2009) there is a survey of jamming attacks and countermeasures in Wireless Sensor Network (WSN). Another clear area of attack is simply physical access. For example, even wired networks are much more susceptible to physical attacks when the devices are spread widely over large areas.

C3: Cloud availability

The challenges here are not new. Elsewhere we looked at DoS attacks and DDoS attacks. The biggest challenge here is the use of IoT devices themselves to create the DDoS attack on the server, as in the Mirai botnet.

A4: Device authentication

We will consider the authentication of the device to the rest of the world in cells B5 and C5. In this cell of the matrix we must consider the challenges of how users or other devices can securely authenticate to the device itself. These are however related: a user may bypass or fake the authentication to the device and thereby cause the device to incorrectly identify itself over the network to other parts of the Internet.

Some attacks are very simple: many devices come with default passwords which are never changed by owners. In a well-publicised example (Hill, 2013), a security researcher gained access to full controls of a number of “smart homes”. As discussed above, the Mirai attack took control of devices that used default or easily guessed passwords.

Similarly many home routers are at risk through insecure authentication (Andersson & Szewczyk, 2011). Such vulnerabilities can then spread to other devices on the same network as attackers take control of the local area network.

A key issue here is the initial registration of the device. A major issue with hardware is when the same credential, key, or password is stored on many devices. Devices are susceptible to hardware attacks (as discussed above) and the result is that the loss of a single device may compromise many or all devices. In order to prevent this, devices must either be pre-programmed with unique identifiers and credentials at manufacturing time, or must go through a registration process at setup time. In both cases this adds complexity and expense, and may compromise usability. In Fremantle, Kopecký & Aziz (2015) there is a proposal for the use of the OAuth2 Dynamic Client Registration (Sakimura, Bradley & Jones, 2015) process to create unique keys/credentials for each device. In Fremantle & Aziz (2016) there is a well-defined and secure process for device and user registration that allows users to take control of devices in scenarios where the device itself offers no User Interface (UI) or a very basic UI.

B4: Network authentication

Unlike browsers or laptops where a human has the opportunity to provide authentication information such as a userid and password, IoT devices normally run unattended and need to be able to power-cycle and reboot without human interaction. This means that any identifier for the device needs to be stored in the program memory (usually SRAM), ROM or storage of the device. This brings two distinct challenges:

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

• Another device may steal the authentication identifier and may spoof the device.

In the Sybil attack (Newsome et al., 2004) a single node or nodes may impersonate a large number of different nodes thereby taking over a whole network of sensors. In all cases, attestation is a key defence against these attacks.

Another defence is the use of reputation and reputational models to associate a trust value to devices on the network. Reputation is a general concept widely used in all aspects of knowledge ranging from humanities, arts and social sciences to digital sciences. In computing systems, reputation is considered as a measure of how trustworthy a system is. There are two approaches to trust in computer networks: the first involves a “black and white” approach based on security certificates, policies, etc. For example, SPINS (Perrig et al., 2002), develops a trusted network. The second approach is probabilistic in nature, where trust is based on reputation, which is defined as a probability that an agent is trustworthy. In fact, reputation is often seen as one measure by which trust or distrust can be built based on good or bad past experiences and observations (direct trust) (Jøsang, Ismail & Boyd, 2007) or based on collected referral information (indirect trust) (Abdul-Rahman & Hailes, 2000).

In recent years, the concept of reputation has shown itself to be useful in many areas of research in computer science, particularly in the context of distributed and collaborative systems, where interesting issues of trust and security manifest themselves. Therefore, one encounters several definitions, models and systems of reputation in distributed computing research (e.g., Fullam & Barber, 2006; Jøsang, Ismail & Boyd, 2007; Silaghi, Arenas & Silva, 2007).

There is considerable work into reputation and trust for wireless sensor networks, much of which is directly relevant to IoT trust and reputation. The Hermes and E-Hermes (Zouridaki et al., 2007; Zouridaki et al., 2009) systems utilise Bayesian statistical methods to calculate reputation based on how effectively nodes in a mesh network propogate messages including the reputation messages. Similarly, Chen et al. (2011) evaluates reputation based on the packet-forwarding trustworthiness of nodes, in this case using fuzzy logic to provide the evaluation framework. Another similar work is Michiardi & Molva (2002) which again looks at the packet forwarding reputation of nodes. In IoT, Aziz et al. (2016) utilizes the concept of a Utility Function to create a reputational model for IoT systems using the MQTT protocol.

C4: Cloud authentication

The IETF has published a draft guidance on security considerations for IoT (O. Garcia-Morchon, 2013). This draft does discuss both the bootstrapping of identity and the issues of privacy-aware identification. One key aspect is that of bootstrapping a secure conversation between the IoT device and other systems, which includes the challenge of setting-up an encrypted and/or authenticated channel such as those using TLS, Host Identity Protocol (HIP) or Diet HIP. HIP (Moskowitz, 2012b) is a protocol designed to provide a cryptographically secured endpoint to replace the use of IP addresses, which solves a significant problem—IP-address spoofing—in the Internet. Diet HIP (Moskowitz, 2012a) is a lighter-weight rendition of the same model designed specifically for IoT and Machine to Machine (M2M) interactions. While HIP and Diet HIP solve difficult problems, they have significant disadvantages to adoption. Secure device identity models that work at higher levels in the network stack, such as token-based approaches, can sit side by side with existing IP-based protocols and require no changes at lower levels of the stack. By contrast, HIP and Diet HIP require low-level changes within the IP stack to implement. As they replace traditional IP addressing they require many systems to change before a new device using HIP can successfully work. In addition, neither HIP nor Diet HIP address the issues of federated authorization and delegation.

In Fremantle (2013) and Fremantle et al. (2014) it is proposed to use federated identity protocols such as OAuth2 (Hammer-Lahav & Hardt, 2011) with IoT devices, especially around the MQTT protocol (Locke, 2010). The IOT-OAS (Cirani et al., 2015) work similarly addresses the use of OAuth2 with CoAP. Other related works include the work of Augusto et al. (Augusto & Correia, 2011) have built a secure mobile digital wallet by using OAuth together with the XMPP protocol (Saint-Andre, 2011). In Fremantle, Kopecký & Aziz (2015), the usage of OAuth2 for IoT devices is extended to include the use of Dynamic Client Registration (Sakimura, Bradley & Jones, 2013) which allows each device to have its own unique identity, which we discussed as an important point in the section about cell A1.

A contradictory aspect of IoT Authentication is the proposal to use secure Pseudonyms. A pseudonym is also sometimes referred to as an Anonymous Identity. Effectively, a secure pseudonym is a way of a user securely interacting with a system without giving away their real identity. This overlaps with cell C5 where we look at access control for cloud systems. We have seen from well-publicised cases that systems may be compromised and offer personal information, even years after that information was originally stored. In one case, two suicides have been attributed to an attack that compromised personal identities (Baraniuk, 2015). Pseudonyms are an approach that can be considered to treat the sharing of meta-data as important as sharing of data. Also see ‘Three Layer Privacy Model’ where we look at another model of privacy.

In Rotondi, Seccia & Piccione (2011) a capability-based access system is described that allows anonymous identities to be used. Bernabe et al. (2014) provides an Architecture Reference Model for an approach that supports anonymous identities. Neither of these systems separate the provision of anonymous identities from the data-sharing middleware. A concept called Zooko’s Triangle (O’Hearn, 2001) proposed that it is only possible to support two out of the following three capabilities in a system: human-readable names; decentralised infrastructure; and security. Recent papers, such as Ali et al. (2016), claim that the blockchain construct proves Zooko’s hypothesis wrong. In Hardjono, Smith & Pentland (2014) the concept of anonymous identities for blockchains is explored, which will have significant impact as blockchains become more prevalent in IoT.

A5: Device access control

There are two challenges to access control at the device level. Firstly, devices are often physically distributed and so an attacker is likely to be able to gain physical access to the device. The challenges here (hardware attacks, NAND mirroring, etc.) were already discussed in cell A1.

However, there is a further challenge: access control almost always requires a concept of identity. We cannot restrict or allow access except in the most basic ways without some form of authentication to the device. As discussed in our review of cell A4, this is a significant challenge. To give a real life example, certain mobile phones have recently started encrypting data based on the user’s own lock-screen Personal Identification Number (PIN) code (Schneier, 2014). This guarantees the data cannot be read without the user’s PIN code. However, using NAND Mirroring, it has been demonstrated that the controls that stop repeated attempts at PIN codes can be overcome (Skorobogatov, 2016), with the result that a 4 digit PIN can easily be broken within a reasonable amount of time.

Systems such as Webinos (Desruelle et al., 2012) have proposed using policy-based access control mechanisms such as XML Access Control Markup Language (XACML) (Godik et al., 2002) for IoT devices. However, XACML is relatively heavyweight and expensive to implement (Turkmen & Crispo, 2008), especially in the context of low power devices. To address this, Webinos has developed an engine which can calculate the subset of the policy that is relevant to a particular device. Despite this innovation, the storage, transmission and processing costs of XACML are still high for an IoT device. Another approach based around a standard called UMA is covered in cell C5.

B5: Network access control

There are a number of researchers looking at how to create new lightweight protocols for access control in IoT scenarios. Mahalle et al. (2012) describe a new protocol for IoT authentication and access control is proposed based on ECC with a lightweight handshake mechanism to provide an effective approach for IoT, especially in mobility cases. Hernández-Ramos et al. (2013) propose a non-centralised approach for access control that uses ECC once again and supports capability tokens in the CoAP protocol.

C5: Cloud access control

The biggest challenge for privacy is ensuring access control at the server or cloud environment of data collected from the IoT. There is some significant overlap with the area of confidentiality of data in the cloud as well (cell C1).

It is argued in Fremantle et al. (2014) that existing hierarchical models of access control are not appropriate for the scale and scope of the IoT. There are two main approaches to address this. The first is policy-based security models where roles and groups are replaces by more generic policies that capture real-world requirements such as “A doctor may view a patient’s record if they are treating that patient in the emergency room”. The second approach to support the scale of IoT is user-directed security controls, otherwise known as consent. This is the approach we take in this thesis. In Tschofenig et al. (2015) a strong case is made for ensuring that users can control access to their own resources and to the data produced by the IoT that relates to those users. The User Managed Access (UMA) from the Kantara Initiative enhances the OAuth specification to provide a rich environment for users to select their own data sharing preferences (Kantara Initiative, 2013). We would argue strongly that this overall concept of user-directed access control to IoT data is one of the most important approaches to ensuring privacy. In Tschofenig et al. (2015), an approach for using UMA together with OAuth2 is proposed for constrained devices. This approach also addresses cell A5. While this approach has a lot of capabilities and power, there is a slow uptake of UMA in real-world services and even less in IoT. We propose that the complexity of this approach is the inhibitor to widespread adoption.

Winter (2012) argues that contextual approaches must be taken to ensure privacy with the IoT. Many modern security systems use context and reputation to establish trust and to prevent data leaks. Context-based security (Montanari, Toninelli & Bradshaw, 2005) defines this approach which is now implemented by major Web systems including Google and Facebook. This is closely related to reputation-based models which we discussed above.

A6: Device non-repudiation

The biggest challenge in the non-repudiation network with IoT devices is the challenge of using attestation for small devices. Attestation is discussed in detail in cell A2. Without attestation, we cannot trust that the device system has not been modified and therefore it is not possible to trust any non-repudiation data from the device.

B6: Network non-repudiation

The same challenges apply here as discussed in cells B2 and, B3. Non-repudiation on the wire requires cryptography techniques and these are often hindered by resource restrictions on small devices. In Park, Seok & Park (2007) a non-repudiation protocol for restricted devices is proposed.

C6: Cloud non-repudiation

This area is unchanged by the IoT, so we do not discuss it any further.

In the previous eighteen sections we have outlined a significant number of threats and challenges, and used this matrix to assess the most relevant current work in each space. Before summarising this work, we look at an orthogonal model more closely focussed on user privacy. This model will be used in later sections to assess the outcomes of this thesis.

User sphere

Moving privacy and security controls back to the users inherently strengthens the User Sphere and provides greater choice, thereby allowing more secure approaches to flourish.

As discussed above, devices need to have secure identities, and currently these are either not provided, or provided by the device manufacturer.

A second, related issue, is the ownership of devices. The Mirai botnet spread because dictionary attacks allowed attackers to take ownership of devices. Some systems offer models of taking ownership securely (e.g., Bluetooth, Near Field Communication (NFC)). In Fremantle & Aziz (2016), there is a system described where a QR code is used in conjunction with a Web-based system.

A third issue within the User Sphere is updating the device firmware. A number of attacks have originated in lack of updates. One issue is that device manufacturers are incentivised to create new products but not to update old products. In Tindall (2015), a model is proposed whereby devices can pay for updates using a blockchain-based cryptocurrency such as Bitcoin. In the Fremantle & Aziz (2016) there is an approach where IoT devices are updated based on the secure identity and consent models used in OAuth2.

Joint sphere

Recall that the Joint Sphere is the parts of the system where the user has some form of control over their data and systems, but the provider also shares control. For example, a health-monitoring device may upload data to an Internet-based system and then may offer users controls on how they share data. A major change in legislation around this is the European Union’s General Data Protection Regulation (GDPR) (European Commission, 2016) which requires much stronger consent controls. Many systems offer forms of user consent for sharing data with third parties, but these lack significant requirements. For example, many users are not aware of how to revoke consent. Similarly, there is no clear place a user can identify all the consents they have approved across different devices. Consent is not just about privacy. IoT devices often include actuators that can act based on Commands, and the security of a device includes ensuring that only authorised systems can issue commands to devices. We looked at consent.

A related area is that of policies. In this meaning a policy is a computer-readable expression of rights and obligations. For example, a consent approval may refer to a policy: the user might approve sharing of data to a website based on the fact that the website promises not to share the data to any other body. Languages such as XACML (Godik et al., 2002) allow complex access control policies to be encoded in XML or JSON. We discussed this in cell C5.

Recipient sphere

The Recipient Sphere is the area where the user’s data is now out of their control. Ultimately, the user must rely on legislation or legal contracts in order to maintain control of this data. Of course, it is hard to police this recipient sphere: it is possible that the third-party website will share data following policies. In addition, many organisations have such complex and poorly worded policies that users are unaware of the rights they are giving up to their data. Spotting illicit data shares can possibly be done using a concept of a Trap Street. This is the habit that map-makers have of including incorrect data to see if others copy it. Similarly, IoT devices could deliberately share incorrect data to specific parties to see if it leaks out against the agreed policy.

Middleware review methodology

This set was identified through a combination of the existing literature reviews on IoT middleware (Bandyopadhyay et al., 2011b; Chaqfeh & Mohamed, 2012; Razzaque et al., 2016) together with our own search for middleware systems that explicitly target IoT scenarios. Some of the systems that were included in these papers we excluded from our list on the basis that they were not middleware. For example, Chaqfeh & Mohamed (2012) lists TinyREST (Luckenbach et al., 2005) as a middleware, but in fact we considered this paper to be the definition of a standard protocol and therefore we excluded it.

Our search strategy was to use a search for the terms (“IoT” OR “Internet of Things”) AND “Middleware”. We searched only in the subject terms and restricted the search to academic papers written in English. The search was carried out by the Portsmouth University Discovery system which is a metasearch engine. The list of databases that are searched is available at (University of Portsmouth Library, 2015). The search was originally issued on June 6th, 2015, identifying 152 papers. It was repeated on December 1st, 2016, and 213 papers were identified, showing a significant growth in IoT middleware papers over the intervening period.

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

In our study, we looked for the security and privacy requirements listed in ‘Summary of the Review of Security Issues’. We also identified if the middleware had a clearly defined security model and/or security implementation. Out of the 54 middleware systems identified, we found that 35 had no published discussion or architecture for security, or such a minimal description that we were not able to identify any support for the selected security requirements. We label these as non-secured systems.

Non-secured systems

We provide a brief description of each of the non-secure middleware systems:

ASIP The Arduino Service Interface Programming model (ASIP) (Barbon et al., 2016) is a middleware for Arduino hardware.

ASPIRE ASPIRE Project (Advanced Sensors and lightweight Programmable middleware for Innovative Rfid Enterprise applications) (Prasad, 2008) is a EU-funded project that created an open, royalty-free middleware for RFID-based applications.

Autonomic QoS Management Banouar et al. (2015) offers a middleware that autonomically manages Quality of Service (QoS) in IoT scenarios. While this does address some aspects related to security (i.e., accuracy and availability), there is no discussion of how security is handled.

CASCOM In Perera & Vasilakos (2016) a semantically-driven configuration model is built on top of existing middleware systems such as GSN (Aberer, Hauswirth & Salehi, 2006). The authors state their intention of addressing privacy in future work.

CIRUS CIRUS (Pham et al., 2016) is a cloud-based middleware for ubiquitous analytics of IoT data.

Cloud-based Car Parking Middleware In Ji et al. (2014) the authors describe an OSGi-based middleware for smart cities enabling IoT-based car parking.

Context Aware Gateway Anand (2015) provides a reference architecture for using context-awareness in IoT scenarios. The middleware itself does not address security or privacy and the authors plan to address this in further work.

DAMP In Agirre et al. (2016) there is a middleware—Distributed Applications Management Platform—that can configure systems based on Quality of Service characteristics (QoS). These characteristics can include security, but the system itself does not offer any security model.

Dioptase Dioptase Billet & Issarny (2014) is a RESTful stream-processing middleware for IoT. Dioptase does address one useful aspect for privacy: intermediate stream processing of data, summarisation and filtering. However, there is no detailed security architecture and description and the security model is left as an item of future work.

EDBO Eleftherakis et al. (2015) describes the Emergent Distributed Bio-Organization: a biologically-inspired platform for self-organising IoT systems.

EDSOA An Event-driven Service-oriented Architecture for the Internet of Things Service Execution (Lan et al., 2015) describes an approach that utilizes an event-driven SOA.

EMMA The Environmental Monitoring and Management Agent (EMMA) is a proposed middleware based on CoAP (Duhart, Sauvage & Bertelle, 2015). It does not offer any security architecture.

GSN The GSN framework (Aberer, Hauswirth & Salehi, 2006) (Global Sensor Networks) defines a middleware for the Internet of Things that requires little or no programming. The security architecture of the system is not described in any detail: there are diagrams of the container architecture which point to proposed places for access control and integrity checks, but unfortunately there is not sufficient discussion to be able to categorize or evaluate the approach taken.

Hi-Speed USB middleware Augustyn, Maślanka & Hamuda (2016) offers a middleware based on USB.

Hitch Hiker Hitch Hiker 2.0 (Ramachandran et al., 2015) is a prototype middleware environment built on Contiki OS.

LMTS In Mhlaba & Masinde (2015) a middleware system for asset tracking (Laptop Management and Tracking System) is described.

Middleware for Environmental Monitoring and Control Xu, Li & Liang (2016) defines a middleware for environmental monitoring and control.

Middleware for Industrial IoT Ungurean, Gaitan & Gaitan (2016) describes a middleware for Industrial IoT based on OpenDDS, which is a middleware that implements the Data Distributions Services (DDS) protocol. At the time of writing the DDS security model was in development and hence the architecture does not address security.

MIFIM Middleware for Future Internet Models (MIFIM) (Balakrishnan & Sangaiah, 2016) is a Web Service-based architecture that uses Aspect-Orientation to allow for simpler reconfiguration.

MOSDEN MOSDEN (Mobile Sensor Data Processing Engine) (Perera et al., 2014) is an extension of the GSN approach (see above) which is explicitly targeted at opportunistic sensing from restricted devices.

M-Hub Talavera et al. (2015) describes a middleware for Mobile IoT applications built on top of another middleware (Scalable Data Distribution Layer). In Gomes et al. (2015) this work is enhanced to create a middleware for Ambient Assisted Living. In Vasconcelos et al. (2015) there is another middleware based on M-Hub. There is no support for security or privacy described.

PalCom Palcom (Svensson Fors et al., 2009) is a middleware designed for pervasive computing, including IoT systems. It supports ad-hoc composition of services. There is no discussion of security beyond a statement that traditional security models may be added in future.

POBICOS Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities (POBICOS) (Tziritas et al., 2012) is a device middleware designed to run on small devices. In Tajmajer et al. (2016) there is a description of migrating aspects of the middleware to a proxy to enable support for smaller devices.

PROtEUS PROtEUS is a process manager designed to support Cyber-Physical Systems (Seiger, Huber & Schlegel, 2016). It describes a middleware for complex self-healing processes.

RemoteU¡ Carvalho & Silva (2015) offers a middleware for Remote user interfaces.

SBIOTCM In A SOA Based IOT Communication Middleware (Zhiliang et al., 2011) is a middleware based on SOAP and WS. There is no security model described.

Service Oriented access for Wireless Sensor Networks Fronimos et al. (2016) provides a service-oriented middleware for IoT and Wireless Sensor Network data.

Smart Object Middleware Hernández & Reiff-Marganiec (2015) describes a Smart Object middleware based on Java.

symbIoTe In Soursos et al. (2016) a roadmap is laid out for a new EU funded project to allow vertical IoT platforms to interoperate and federate. There is no plan for security presented.

Thingsonomy Thingsonomy (Hasan & Curry, 2015) is an event-based publish–subscribe based approach that applies semantic technology and semantic matching to the events published within the system.

UBIROAD The UBIROAD middleware (Terziyan, Kaykova & Zhovtobryukh, 2010) is a specialization of the UBIWARE project specifically targeting traffic, road management, transport management and related use-cases.

UBISOAP ubiSOAP (Caporuscio, Raverdy & Issarny, 2012) is a Service-Oriented Architecture (SOA) approach that builds a middleware for Ubiquitous Computing and IoT based on the Web Services (WS) standards and the SOAP protocol.

VEoT Alessi et al. (2016) describes a Virtual Environment of Things which is a middleware for Virtual Reality engagement with the Internet of Things.

WHEREX WhereX (Giusto et al., 2010) is an event-based middleware for the IoT.

&Cube

In Yun et al. (2015) they describe a middleware, &Cube, that is designed to offer RESTful APIs as well as MQTT connections to integrate with IoT devices. The system offers a security manager providing encryption, authentication and access control. No further details are available on the techniques used.

Device cloud

In Renner, Kliem & Kao (2014) there is a blueprint for a middleware that applies Cloud Computing concepts to IoT device middleware. A more detailed exposition is given in Kliem (2015). The approach supports OAuth2.0 to provide tokens to devices. It also supports encryption and access control. There is no support for summarisation, filtering, or consent-based access control described in the publications.

DREMS

Distributed RealTime Managed Systems (DREMS) (Levendovszky et al., 2014) is a combination of software tooling and a middleware runtime for IoT. It includes Linux Operating System extensions as well. DREMS is based on an actor (Agha, 1985) model has a well-defined security model that extends to the operating system. The security model includes the concept of multi-level security (MLS) for communications between a device and the actor. The MLS model is based on labelled communications. This ensures that data can only flow to systems that have a higher clearance than the data being transmitted. This is a very powerful security model for government and military use-cases. However, this approach does not address needs-based access control. For example, someone with Top Secret clearance may read data that is categorised as Secret even if they have no business reason to utilise that data. The weaknesses of this model have been shown with situations such as the Snowden revelations.

DropLock

In Le Vinh et al. (2015) the authors describe a middleware specifically built for IoT systems and Smart Cities. The DropLock system is designed to enable secure smartphone access to a smart locker, allowing delivery personnel secure access to drop off packages. The system uses secure tokens to allow access to devices. The tokens are passed to the secure locker using Bluetooth.

FIWARE

FIWARE (Glikson, 2011) is a middleware designed to be the basis of a Future Internet, sponsored by the European Union under the FP7 programme. FIWARE is one of the few systems that claim to have used PBD as a basis for design (Vázquez et al., 2011). FIWARE has a concept of plugins, known as Generic Enablers (GE). The security model is implemented through GEs including the Identity Management (IdM GE), the Authorization Policy Decision Point (PDP) GE, and the Policy Enforcement Point (PEP) Proxy. The standard approach within FIWARE is based on OAuth2 and XACML. It also supports interoperable standards for exchanging identities with other systems. The overall security design of FIWARE fits into modern authentication and authorization models. IoT devices are catered for in the FIWARE Architecture through a gateway model. The IoT devices connect to the gateway using IoT specific protocols. The gateway is part of the IoT Edge. This communicates via the standard FIWARE protocols into an IoT Backend where there are components supporting Device Management and Discovery. The FIWARE documentation does not describe any specific adaptation of security or support for security between devices and the gateway.

Hydra/Linksmart

Hydra (Eisenhauer, Rosengren & Antolin, 2009) was a European Union funded project which has since been extended and renamed as LinkSmart. The Hydra team published a detailed theoretical model of a policy-based security approach (Adetoye & Badii, 2009). This model is based on using lattices to define the flow of information through a system. This model provides a language-based approach to security modelling. However, whilst this paper is published as part of the Hydra funded project, there is no clear implementation of this in the context of IoT or description of how this work can benefit the IoT world. Hoever, because Hydra/Linksmart is an Open Source project (Linksmart, 2015b) with documentation beyond the scientific papers, it is possible to understand the security model in greater detail by review of this project.

The Hydra and LinkSmart architectures are both based on the Web Services (WS) specifications, building on the SOAP protocol (Gudgin, 2003), which in turn builds on the XML Language (Bray, 2004). The security model is described in some detail in the LinkSmart documentation (Linksmart, 2015a). The model utilises XML Security (Dournaee, 2002). There are significant challenges in using this model in the IoT world, as discussed above in ‘Matrix Evaluation’. The Hydra/Linksmart approach also uses symmetric keys for security which is a challenge for IoT because each key must be uniquely created, distributed and updated upon expiry into each device creating a major key management issue.

Hydra/Linksmart offers a service called the TrustManager. This is a system that uses the cryptographic capabilities to support a trusted identity for IoT devices. This works with a Public Key Infrastructure (PKI) and certificates to ensure trust. Once again there are challenges in the distribution and management of the certificates to the devices which are not addressed in this middleware.

The Hydra middleware does not offer any policy based access control for IoT data, and does not address the secure storage of data for users, nor offer any user-controlled models of access control to user’s data.

In Patti et al. (2016) there is a specific instantiation of LinkSmart applied to energy efficiency in buildings. There is no further extension to the security model.

INCOME

INCOME (Arcangeli et al., 2012) is a framework for multi-scale context management for the IoT, funded by the French National Research Agency. The aim of INCOME is to fuse together context data from multiple levels to provide a high-level set of context data from IoT systems that can be applied to decision making, including trust, privacy and security decisions. MuDebs and MuContext (Lim et al., 2016) are frameworks built on top of INCOME that add Attribute Based Access Control (ABAC) and Quality of Context (QoC) processing. MuDebs utilises XACML policies to implement ABAC. MuContext validates QoC and enables privacy filtering.

IoT-MP

The IoT Management Platform (IoT-MP) is a middleware system described in Elkhodr, Shahrestani & Cheung (2016). IoT-MP offers a security module that implements attribute-based access control (ABAC) against systems. IoT-MP has a model whereby an Agent is registered for each class of Things, creating the concept of a Managed Thing. Agents have unique secure identities. The IoT-MP does not define how devices are identified to agents.

NAPS

The Naming, Addressing and Profile Server (NAPS) (Liu, Yang & Liu, 2014) describes a heterogeneous middleware for IoT based on unifying data streams from multiple IoT approaches. Based on RESTful APIs, the NAPS approach includes a key component handling Authentication, Authorization, and Accounting (AAA). The design is based on the Network Security Capability model defined in the ETSI M2M architecture (ETSI, 2015). However, the main details of the security architecture have not yet been implemented and have been left for future work. There is no consideration of federated identity or policy based access control.

NERD

No Effort Rapid Development (NERD) (Czauski et al., 2016) is a middleware designed for human IoT interfaces, especially around Bluetooth LE systems and iBeacon discovery. It does not add any new security measures but uses the existing security models in Bluetooth and HTTP.

NOS

NetwOrked Smart objects (NOS) (Sicari et al., 2016a; Sicari et al., 2016b) takes an interesting approach to security where the aim is to provide each item of data with a reputational score based on a quality analyser and a security analyser. A machine learning algorithm is used to learn the behaviour of systems in the network and adjust the scores based on the potential attacks and the applied countermeasures. The system incorporates keys and key-based authentication, encryption and complex passwords.

OpenIoT

OpenIoT is an open cloud-based middleware for the Internet of Things, funded by the European Union FP7 programme. It also extends the GSN framework. The Security Module uses OAuth2 as the main authentication and authorization model for web-based systems. No details are given of how sensors are authenticated or authorized.

SensorAct

SensorAct (Arjunan et al., 2015) is an IoT middleware specifically aimed at providing support for Building Management Systems (BMS). It supports fine-grained access control through the use of a rules engine to implement access control policies. No details are provided of the authentication models at the device level or the web interface.

SIRENA

SIRENA (Service Infrastructure for Real-time Embedded Networked Devices) (Bohn, Bobek & Golatowski, 2006) is a SOAP/WS-based middleware for IoT and embedded devices. While there is little description of the security framework in SIRENA, it does show the use of the WS-Security specification. As previously discussed, this approach is very heavyweight, has issues with key distribution, federated identity and access control.

SMEPP

Secure Middleware for P2P (SMEPP) (Benito et al., 2009) is an IoT middleware explicitly designed to be secure, especially dealing with challenges in the peer-to-peer model. SMEPP security is based around the concept of a group. When a peer attempts to join a group, the system relies on challenge-response security to implement mutual authentication. At this point the newly joined peer is issues a shared session key which is shared by all members of the group. SMEPP utilizes elliptic key cryptography to reduce the burden of the security encryption onto smaller devices. Overall SMEPP has addressed security effectively for peer-to-peer groups, but assumes a wider PKI infrastructure for managing the key model used within each group. In addition, there is no discussion of access control or federated identity models, which are important for IoT scenarios. The model is that any member of the group can read data published to the group using the shared session key.

SOCRADES

SOCRADES (De Souza et al., 2008) is a middleware specifically designed for manufacturing shop floors and other industrial environments. Based on SOAP and the WS stack it utilizes the security models of the WS stack, in particular the WS-Security standard for encryption and message integrity. There is no special support for federation, tokens or policy-based access control (instead relying on role-based access control). The resulting XML approach is very heavyweight for IoT devices and costly in terms of network and power (Dunkels & Yazar, 2009). In addition, the lack of explicit support for tokens and federated security and identity models creates a significant challenge in key distributions and centralized identity for this approach.

UBIWARE

The UBIWARE project is a smart semantic middleware for Ubiquitous Computing (Scuturici et al., 2012). The security model for UBIWARE is not clearly described in the original paper, but an additional paper describes a model called Smart Ubiquitous Resource Privacy and Security (SURPAS) (Naumenko, Katasonov & Terziyan, 2007), which provides a security model for UBIWARE. UBIWARE is designed to utilize the semantic Web constructs, and SURPAS utilises the same model of semantic Web as the basis for the abstract and concrete security architectures that it proposes. The model is highly driven by policies and these can be stored and managed by external parties. In particular the SURPAS architecture is highly dynamic, allowing devices to take on board new roles or functions at runtime. While the SURPAS model describes a theoretical solution to the approach, there are few details on the concrete instantiation. For example, while the model defines a policy-based approach to access control, there are no clearly defined policy languages chosen. There is no clear model of identity or federation, and there is no clear guidance on how to ensure that federated policies that are stored on external servers are protected and maintain integrity. The model does not address any edge computing approaches or filtering/summarisation of IoT data. However, the overall approach of using ontologies and basing policies on those ontologies is very powerful.

WEBINOS

The Webinos (Desruelle et al., 2012) system has a well-thought through security architecture. The documentation explicitly discussed PBD. The Webinos system is based around the core concept of devices being in the personal control of users and therefore having each user having a personal zone to protect. This is a more advanced concept but in the same vein as the protected sub-domains in VIRTUS. In the Webinos model, each user has a cloud instance—known as the Personal Zone Hub (PZH) that supports their devices. The Personal Zone Hub acts as a service to collect and offer access to data and capabilities of the user’s devices. The PZH acts as a certificate authority, issuing certificates to the devices that are used for mutual authentication using TLS. User’s authenticate to the PZH using the OpenID protocol. On the device, a communications module known as the Personal Zone Proxy (PZP) handles all communications with the PZH.

The idea of the Personal Zone may have significant issues however, when a single device is used by many different people (for example, the in-car system in a taxi as opposed to a personal vehicle). These issues are not addressed in Webinos, though they are called out in the lessons learnt.

Webinos utilizes policy-based access control modelled in the XACML (Godik et al., 2002) language. The system pushes XACML policies out to devices to limit the spread of personal and contextual data.

Webinos addresses the issue of software modification using an attestation API, which can report whether the software running is the correct level. This requires the device to be utilising Trusted Platform Module (TPM) hardware that can return attestation data.

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

While the Webinos project does address many of the privacy concerns of users through the use of the Personal Zone Hub, there is clearly further work that could be done. In particular the ability for users to define what data they share with other users or other systems using a protocol such as OAuth2 (Hammer-Lahav & Hardt, 2011), and the ability to install filters or other anonymising or data reduction aggregators into the PZH are lacking. One other aspect of Webinos that is worth drawing attention to is the reliance on a certain size of device: the PZP that is needed on the device is based on the node.js framework and therefore the device needs to be of a certain size (e.g., a 32-bit processor running a Linux derivative or similar) to participate in Webinos.

VIRTUS

The VIRTUS middleware (Conzon et al., 2012) utilizes the core security features of the XMPP protocol to ensure security. This includes tunnelling communications over TLS, authentication via SASL, and access control via XMPP’s built-in mechanisms. SASL is a flexible mechanism for authentication which supports a number of different systems including token-based approaches such as OAuth2 or Kerberos, username/password, or X.509 certificates. For client-to-server based communications, it is not clear from the description which of these methods is actually implemented within VIRTUS. For server-to-server communications there is specified the use of SASL to ensure full server federation.

While the VIRTUS model does not describe the challenges of implementing a personal instance of middleware for single users or devices, there is a concept of edge computing described, where some interactions may happen within an edge domain (e.g., within a house) and lower security is required within that domain while higher security is expected when sharing that data outside. This model is fairly briefly described but provides an interesting approach. One challenge is that there are multiple assumptions to this: firstly, that security within the limited domain needs less security, when there may be attackers within that perimeter. Secondly, that the open channel to the wider Internet cannot be misused to attack the edge network. The ability to calculate, summarise and/or filter data from the edge network before sharing it is also not discussed except in very granular terms (e.g., some data are available, other data are not).

XMPP

The paper (Iivari et al., 2014) describes how the XMPP architecture can be applied to the challenges of M2M and hence the IoT, together with a proof-of-concept approach. The system relies on the set of XMPP extensions around publish/subscribe and the related XMPP security models to implement security. This includes TLS for encryption, and access control models around publish–subscribe. There is also a discussion about leakage of information such as presence from devices. The proof-of-concept model did not include any federated identity models, but did utilize a One-Time Password (OTP) model on top of XMPP to address the concepts such as temporary loans of devices.

Overall gaps in the middleware

When we look at the requirements for security and privacy of the Internet of Things we can see there are some gaps that are not provided by any of the reviewed middleware systems.

• Only two of the middleware systems explicitly applied the concept of PBD in designing a middleware directly to support privacy, although Webinos did exhibit many of the characteristics of a system that used this approach.

• Only two of the systems applied any concepts of context-based security or reputation to IoT devices.

• User consent was only supported in three of the systems.

• None of the systems supported anonymous identities or attestation.

• None of the systems satisfied all the requirements identified.

Contributions

In this paper we have taken a two-phase approach to reviewing the available literature around the security and privacy of IoT devices.

In the first part we created a matrix of security challenges that applied the existing CIA+ model to three distinct areas: device, network and cloud. This new model forms a clear contribution to the literature. In each of the cells of the matrix we identified threats, challenges and/or approaches, or in a few cells we identified that the challenges are not exacerbated by IoT concerns. We further used Spiekerman and Cranor’s three layer privacy model to analyse the privacy requirements of IoT. We used this analysis to identify seven major requirements and five subsidiary requirements.

In the second part, we used a structured search approach to identity 54 specific IoT middleware frameworks and we analysed the security models of each of those. We utilised the twelve requirements from the first phase to validate the capabilities of each system. While there are existing surveys of IoT middleware, none of them focussed on a detailed analysis of the security of the surveyed systems and therefore this has a clear contribution to the literature.

Further work

In our survey, we have identified some clear gaps. Over half the surveyed systems had either no security or no substantive discussion of security. Out of the surveyed systems we found very few that addressed a significant proportion of the major challenges that we identified in the first section. We found certain aspects that were identified in the first section that were not addressed by any of the surveyed systems. Based on this we believe there is a significant opportunity to contribute to the research by creating a middleware for IoT that addresses these gaps.

• To define a model and architecture for IoT middleware that is designed from the start to enable privacy and security (Privacy by Design).

• Secondly, to bring together the best practice into a single middleware that includes: federated identity (for users and devices), policy-based access control, user managed access to data, stream processing in the cloud.

• Thirdly, there is considerable work to be done to define a better model around the implementation challenges for the concept of a personal cloud service (e.g the Webinos PZH). This includes the hosting model, bootstrapping, discovery and usage for smaller devices.

• Finally, creating a middleware system that applies context-based security and reputation to IoT middleware.